syncing disks... panic: kernel diagnostic assertion "mp->tm_bytes_used == 0" failed: file "../../../../tmpfs/tmpfs_mem.c", line 66
Stopped at Debugger+0x5: popq %rbp
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
IF RUNNING SMP, USE 'mach ddbcpu <#>' AND 'trace' ON OTHER PROCESSORS, TOO.
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb{0}> trace
Debugger() at Debugger+0x5
panic() at panic+0x131
__assert() at __assert+0x24
tmpfs_mntmem_destroy() at tmpfs_mntmem_destroy+0x2c
tmpfs_unmount() at tmpfs_unmount+0xb3
dounmount() at dounmount+0x83
vfs_unmountall() at vfs_unmountall+0x9e
vfs_shutdown() at vfs_shutdown+0x41
boot() at boot+0x73
sys_reboot() at sys_reboot+0x59
syscall() at syscall+0x225
--- syscall (number 55) ---
end of kernel
end trace frame: 0x7f7ffffc4470, count: -11
acpi_pdirpa+0x3fc7fa:
acpi_pdirpa+0x3fc7fa:
ddb{0}> ps
PID PPID PGRP UID S FLAGS WAIT COMMAND
*31142 1 31142 31539 7 0x22 reboot
21 0 0 0 3 0x100200 aiodoned aiodoned
20 0 0 0 2 0x100200 update
19 0 0 0 3 0x100200 cleaner cleaner
18 0 0 0 3 0x100200 reaper reaper
17 0 0 0 3 0x100200 pgdaemon pagedaemon

anyone?

What's probably needed:

• EFI (FAT32) partition for (boot)loaders
• UEFI-compatible bootloader
• cdrom-image with EFI partition and loader(?)
• GPT support in the MBR bootloader for older systems
• GPT support for partition table parsing
• some kernel internals we don't know yet

Some links:

• https://wiki.freebsd.org/UEFI
• http://svnweb.freebsd.org/base/projects/uefi/sys/boot/efi/

I got hands on the Banana Pi R1, which essentially is a Banana Pi (or Cubieboard) with a Broadcom Ethernet switch. Basically the Ethernet phy is the switch instead of an actual port. This means that it got 5 ethernet ports which you can use!

The device is based on the Allwinner A20, so it's something that we support a little bit. To improve it even further, we should include sunxi into the clock framework by properly parsing and handling the clocks from the FDT.

• Attach sunxi to fdtbus.
• Write support for all clocks. (FDT + clock framework)
• Adjust AHCI to clock framework and fdtbus.
• Implement GMAC support, only EMAC so far.
• Support broadcom switch.
• Update u-boot/SPL for Allwinner A20. Probably multiple miniroots, one per board.

Freescale has released a few new SoCs in their QorIQ portfolio.

One of them is the LS1021A. That SoC is a dual-core Cortex-A7 and has 3x SerDes connections, which you can connect 2x GigE, 2x PCIe and 1x AHCI. Especially the 2x GigE + 1x AHCI combination would be great. Additionally a third GigE interface is connected via RGMII.

I got hands on the TWR-LS1021A rev 1.0 board. Unfortunately it's still in a rather prototype-y stage. So far I have made it boot into a ramdisk and use all three ethernets. Unfortunately the ethernet is not completely stable yet.

Furthermore AHCI/SATA controller is not yet working. As of the time of this issue there is no support for it in Freescale's Linux SDK. I have neither worked on the SDHCI, nor the IFC/flash. There is support for the USB 3.0 controller, but it doesn't seem stable either.

Means, as of now there's no support for persistent storage.

Things to do:

• Rebase branch.
• Move code to another directory other than armv7/fdt?
• Evaluate fixing persistant storage. (SATA, USB 3.0)
• Debug ethernet.
• Putting it into the tree.
• PCIe
• Audio/Video
• Many more.

Scaleway provides cloud machines based on ARMv7 chips. Those are based on the Marvell Armada 370. They have 18 SoCs per blade, 16 blades per chassis. Thus 288 SoCs / 1152 cores per chassis. The modules themselves do not have integrated storage, but instead get / via a network block device (NBD).

• Support the Marvell SoC (#64) (in progess)
• Kernel support for NBD
• xNBD client port
  • port compiles
  • remove Linux-ism
• pivot_root
• initrd that takes care of bootup, dhcp, / attachment

Add kernel and user space changes to support KVM.

Maybe bhyve?

When cross-compiling for ARM, llvm can create EABI objects, but ld and gas don't.
Binutils should be bumped to 2.22 to support it.

Setting $HISTFILE in ksh (from latest git revision) to any value seems to give a weird error message:
ksh: internal error: afree: 8843c8 not present in area 88d3c0

I've tried setting it to "$HOME/.ksh_history", files that don't exist, /dev/null, files that do exist, etc. and they all give that error.

i've booted recent snapshots in xen as a domU, i.e. guest OS, and the most recent one i can get to boot without the vm dying is 20140714. bsd.rd from 20140915 and later, including version 1.0, dies immediately after the message "root on tmpfsrd0a ....".

this last message that displays is one of the last messages that should display before the installer prompt appears. in the cases where the boot is successful, there are messages printed to the console about detaching tmpfsrd0, which are absent when the boot fails.

when attempting to boot with xen in debug mode, there are a couple logfiles that have potentially useful information in them.

/var/log/qubes/guid.bitrig-10-amd64.log

Icon size: 128x128
Created 0x3a00003(0x1) parent 0x0(0x0) ovr=0 x/y 0/0 w/h 720/400
invalid PResizeInc for 0x3a00003 (0/35180432)
invalid PBaseSize for 0x3a00003 (32/400)
pacat exited with 256 status
event channel disconnected
xs_read domainname: No such file or directory

/var/log/xen/console/guest-bitrig-10-amd64-dm.log

Xen Minimal OS!
start_info: 0x56e000(VA)
nr_pages: 0x2000
shared_inf: 0x43855000(MA)
pt_base: 0x571000(VA)
nr_pt_frames: 0x7
mfn_list: 0x55e000(VA)
mod_start: 0x0(VA)
mod_len: 0
flags: 0x0
cmd_line: -d 73
stack: 0x51ce60-0x53ce60
MM: Init
_text: 0x0(VA)
_etext: 0x1086b3(VA)
_erodata: 0x15b000(VA)
_edata: 0x164108(VA)
stack start: 0x51ce60(VA)
_end: 0x55d768(VA)
start_pfn: 57b
max_pfn: 2000
Mapping memory range 0x800000 - 0x2000000
setting 0x0-0x15b000 readonly
skipped 0x1000
MM: Initialise page allocator for 587000(587000)-2000000(2000000)
MM: done
Demand map pfns at 2001000-2002001000.
Heap resides at 2002002000-4002002000.
Initialising timer interface
Initialising console ... done.
gnttab_table mapped at 0x2001000.
Initialising scheduler
Thread "Idle": pointer: 0x2002002050, stack: 0x5a0000
Thread "xenstore": pointer: 0x2002002800, stack: 0x5b0000
xenbus initialised on irq 1 mfn 0x52cc8
Dummy main: start_info=0x53cf60
Thread "main": pointer: 0x2002002fb0, stack: 0x5c0000
Thread "pcifront": pointer: 0x2002003760, stack: 0x5d0000
pcifront_watches: waiting for backend path to appear device/pci/0/backend
dom vm is at /vm/4564d37a-d1d7-40ec-967f-99c6c923c23f
"main" "-d" "73" "-d" "73" "-domain-name" "bitrig-10-amd64" "-vnc" "127.0.0.1:0" "-vncunused" "-videoram" "8" "-std-vga" "-boot" "dca" "-usb" "-usbdevice" "tablet" "-acpi" "-vcpus" "4" "-vcpu_avail" "0xf" "-net" "nic,vlan=0,macaddr=00:16:3e:5e:6c:09,model=rtl8139" "-net" "tap,vlan=0,ifname=tap73.0,bridge=xenbr0,script=no" "-net" "lwip,client_ip=10.137.2.11,server_ip=10.137.2.254,dns=10.137.2.1,gw=10.137.2.1,netmask=255.255.255.0"
domid: 73
domid: 73
************************ NETFRONT for device/vif/0 **********

net TX ring size 256
net RX ring size 256
backend at /local/domain/2/backend/vif/74/0
mac is 00:16:3e:5e:6c:09

tap_open((null)) -> 3
Waiting for network.
IP a8902fe netmask ffffff00 gateway a890201.
TCP/IP bringup begins.
Thread "tcpip_thread": pointer: 0x2002007570, stack: 0x6f0000
TCP/IP bringup ends.
registering DHCP server
Network is ready.
xs_daemon_open -> 5, 0x1603b8
Using xvda for guest's hda
******************* BLKFRONT for /local/domain/74/device/vbd/51712 **********

backend at /local/domain/0/backend/vbd/74/51712
41943040 sectors of 512 bytes

blk_open(/local/domain/74/device/vbd/51712) -> 6
Using xvdb for guest's hdb
******************* BLKFRONT for /local/domain/74/device/vbd/51728 **********

backend at /local/domain/0/backend/vbd/74/51728
4194304 sectors of 512 bytes

blk_open(/local/domain/74/device/vbd/51728) -> 7
Using xvdc for guest's hdc
xs_watch(/local/domain/0/backend/vbd/74/51744/params, xvdc)
******************* BLKFRONT for /local/domain/74/device/vbd/51744 **********

backend at /local/domain/0/backend/vbd/74/51744
33008 sectors of 2048 bytes

blk_open(/local/domain/74/device/vbd/51744) -> 8
xs_directory(/local/domain/74/device/vkbd): ENOENT
xs_directory(/local/domain/74/device/vfb): ENOENT
xs_watch(/local/domain/0/device-model/73/logdirty/cmd, logdirty)
Watching /local/domain/0/device-model/73/logdirty/cmd
xs_watch(/local/domain/0/device-model/73/command, dm-command)
Watching /local/domain/0/device-model/73/command
xs_watch(/local/domain/73/cpu, vcpu-set)
Watching /local/domain/73/cpu
xs_read(/local/domain/0/backend/pci/73/0/msitranslate): EACCES
xs_read(/local/domain/0/backend/pci/73/0/power_mgmt): EACCES
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 4564d37a-d1d7-40ec-967f-99c6c923c23f
xs_watch(/local/domain/0/backend/console/73, be:0x144ed0:73:0x15b3e0)
evtchn_open() -> 9
fcntl(9, 2, 1/1)
gntmap_init(map=0x160b88)
xs_watch(/local/domain/73/console, fe:0x200200c400)
xs_write(/local/domain/0/backend/console/73/0/state): EACCES
xs_read(/local/domain/73/console/state): ENOENT
xs_read(/local/domain/73/console/protocol): ENOENT
xs_watch(/local/domain/73/console, fe:0x200200c400)
xen be: console-0: xen be: console-0: watching frontend path (/local/domain/73/console) failed
watching frontend path (/local/domain/73/console) failed
evtchn_open() -> 11
xc_evtchn_bind_interdomain(73, 7) = 0
xc_evtchn_bind_interdomain(73, 1) = 0
xc_evtchn_bind_interdomain(73, 2) = 0
xc_evtchn_bind_interdomain(73, 3) = 0
populating video RAM at ff000000
mapping video RAM from ff000000
xs_read(/local/domain/0/device-model/73/disable_pf): ENOENT
Register xen platform.
Done register platform.
xs_watch(/local/domain/73/log-throttling, /local/domain/73/log-throttling)
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state.
qubes_gui/init: 660
qubes_gui/init: 669
qubes_gui/init: 672
qubes_gui/init: 681
xs_daemon_open -> 12, 0x160ea8
evtchn_open() -> 13
xc_evtchn_bind_unbound_port(0) = 0
qubes gui initialized
resize to 640x480@32, 2560 required
can't store dev vc:80Cx24C name for domid 73 in /serial/0 from a stub domain
xs_read_watch() -> /local/domain/73/log-throttling /local/domain/73/log-throttling
xs_read(/local/domain/73/log-throttling): ENOENT
xs_read(/local/domain/73/log-throttling): read error
qemu: ignoring not-understood drive /local/domain/73/log-throttling' medium change watch on/local/domain/73/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
resize to 720x400@32, 2880 required
xs_read_watch() -> /local/domain/73/cpu vcpu-set
vcpu-set: watch node error.
[xenstore_process_vcpu_set_event]: /local/domain/73/cpu has no CPU!
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read_watch() -> /local/domain/0/device-model/73/command dm-command
xs_read(/local/domain/0/device-model/73/command): ENOENT
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read_watch() -> /local/domain/0/device-model/73/logdirty/cmd logdirty
xs_read(/local/domain/0/device-model/73/logdirty/cmd): ENOENT
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read_watch() -> /local/domain/0/backend/vbd/74/51744/params xvdc
Using xvdc for guest's hdc
medium change watch on `xvdc' (index: 2): /dev/cdrom
pcifront_watches: waiting for backend to get into the right state /local/domain/0/backend/pci/74/0
******************* PCIFRONT for device/pci/0 **********

backend at /local/domain/0/backend/pci/74/0

pcifront_watches: waiting for backend events /local/domain/0/backend/pci/74/0/state
xs_daemon_open -> 12, 0x160ea8
qubes_gui/init[710]: version sent, waiting for xorg conf
vga s->lfb_addr = f1000000 s->lfb_end = f1800000
qubes_gui/init[721]: got xorg conf, creating window
qubes_gui/init: 728
dumping mfns: n=282, w=720, h=400, bpp=32
configure msg, x/y 0 252 (was 0 0), w/h 720 400
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro state.
vga s->lfb_addr = f1000000 s->lfb_end = f1800000
vga s->lfb_addr = f1000000 s->lfb_end = f1800000
vga s->lfb_addr = f1000000 s->lfb_end = f1800000
vga s->lfb_addr = f1000000 s->lfb_end = f1800000
vga s->lfb_addr = f1000000 s->lfb_end = f1800000
vga s->lfb_addr = f1000000 s->lfb_end = f1800000
vga s->lfb_addr = f1000000 s->lfb_end = f1800000
vga s->lfb_addr = f1000000 s->lfb_end = f1800000
vga s->lfb_addr = f1000000 s->lfb_end = f1800000
vga s->lfb_addr = f1000000 s->lfb_end = f1800000
vga s->lfb_addr = f1000000 s->lfb_end = f1800000
vga s->lfb_addr = f1000000 s->lfb_end = f1800000
vga s->lfb_addr = f1000000 s->lfb_end = f1800000
vga s->lfb_addr = f1000000 s->lfb_end = f1800000

We really want to use more than one core on the newer ARM processors.

• mplock implementation
• Code to spin up processors (Partly, not clean enough yet)
• Fix cache coherency problems
• Heavy tests

The Raspberry Pi 2 has a quad-core Cortex-A7, so it's based on the ARMv7 architecture. As we stopped supporting everything lower than ARMv7 we can actually try to support this new SoC.

I have spent a bit of time to make it run, trying to be FDT-only instead of using the board. There's a small list of things that I should work on before proper implementation can work.

• Implement a bit of ASM code to boot the kernel from the correct place. Maybe there's another way? Setting kernel_address to 0x0030000?
• Move fdtbus into MI arm tree.
• Attach cortex devices to fdtbus in FDT case.
• Don't attach FDT nodes twice, needed for interrupt-controller scan.
• Scan for "interrupt-controller" and attach them before other devices.
• Create a list of interrupt-controller nodes, so that an arm_intr_establish can call establish on the correct interrupt controller.
• Write interrupt controller driver.
• Write SoC peripheral drivers. Probably can be copied from FreeBSD.
  • Improve SDMMC stack
  • Write SDHC driver for PIO mode.
  • Support SDHC DMA.
  • Support USB DWC. (In Progress)
  • Watchdog (99%)
  • GPIO (99%)
• Find out how to load symbols/ramdisk. Load ELF directly? Tiny "bootloader" in the kernel?

Does Bitrig define a preprocessor macro to help detect the operating system in C or C++ source files? I am writing cross-platform C library and I would like to be able to detect if my code is being compiled on Bitrig. I couldn't find any documentation for this online unfortunately.

I have been using the following resource for figuring out how to detect operating systems: https://sourceforge.net/p/predef/wiki/OperatingSystems/

With a debian netinstall iso, it is possible to write the iso to a usb stick with dd and boot off of that or burn it to a cd/dvd. Currently the bitrig cd01.iso can only be written to cd and will not work on a usb stick. We should probably fix that.

We need a xhci driver, newer haswell laptops mostly have usb3 ports only and won't work.

Is it possible to include HPN-ssh patches?
Just like FreeBSD does?

Due to the change to the better-licensed libc++ and libc++abi library we have lost c++ exception support on arm.

There are three ways to make C++ exceptions work:

• Itanium-ABI: Works as x86 using the eh_frame. Doesn't seem to work ootb on clang 3.4, might work with clang 3.4.1 and patches. clang 3.5 will have support for it, as NetBSD does it that way.
• ARM EHABI: "Similar" to Itanium, but different. There's initial support in libc++abi, but it seems to need stuff from libgcc.
• SJLJ: OSX uses SJLJ, clang seems to be able to do that, but I haven't gotten it to work yet. As this method inserts calls into every function, it's a tiny bit slower than the others if no exceptions occur.

In my opinion, we should use the Itanium-ABI. This is what I'll work on, after the clang 3.4.1 update?

Get rid of big lock.

This is being worked on in the branch "smpns" by haesbaert@.

Short to-do list:

• Critical sections instead of interrupt priority levels
• Interrupt handlers as threads
• Convert big-lock to a rrwlock
• Turn on kernel preemption
• Convert mutexes->spinlock Renaming mutexes to spinlock has been deferred.
• Implement real mutexes, akin freebsd. (bmtx)
• Fake tokens with mutexes ?
• Introduce subsystem locks.

Works fine on Arch Linux, and latest OpenBSD-stable, however. Fails on Bitrig with the most recent snapshot as of writing.

Marvell 88E8040 PCI-E Fast Ethernet Controller.

We should update our clang to 3.4.1 to get a few fixes in. Also, I have seen FDE changes, which might be helpful for #23.

Edit: update to clang 3.5 instead

I don't know if this will get looked at, because I know it's a tall order.

I would like the rtl8723be driver to be added, if possible.
My laptop comes with NGFF wifi cards (unfortunately), so i can't switch to something that's supported, like an atheros.

• boot fails with ERR R (read error).
• Forcing CHS works.
• The problem could be related to the file system's fragment size being too small (< 1024).
• Apparently the problem happens when trying to read the first block from disk.

This works:

newfs -b 4096 -f 2048 sd1a

/dev/rsd1a: 2047.3MB in 4192896 sectors of 512 bytes
42 cylinder groups of 48.97MB, 12536 blocks, 6272 inodes each
(...)

./installboot -v boot biosboot sd1

boot: boot proto: biosboot device: /dev/rsd1c
installboot: looking for superblock at 65536
installboot: bad superblock magic 0x0
installboot: looking for superblock at 8192
installboot: found valid ffs1 superblock
boot is 20 blocks x 4096 bytes
fs block shift 2; part offset 64; inode block 14, offset 1064
expecting 32-bit fs blocks (skew 0)
master boot record (MBR) at sector 0
partition 3: type 0xA6 offset 64 size 4192901
biosboot will be written at sector 64

This works:

newfs -b 4096 -f 1024 sd1a

/dev/rsd1a: 2047.3MB in 4192896 sectors of 512 bytes
84 cylinder groups of 24.48MB, 6268 blocks, 6272 inodes each
(...)

./installboot -v boot biosboot sd1

boot: boot proto: biosboot device: /dev/rsd1c
installboot: looking for superblock at 65536
installboot: bad superblock magic 0x0
installboot: looking for superblock at 8192
installboot: found valid ffs1 superblock
boot is 20 blocks x 4096 bytes
fs block shift 1; part offset 64; inode block 28, offset 1064
expecting 32-bit fs blocks (skew 0)
master boot record (MBR) at sector 0
partition 3: type 0xA6 offset 64 size 4192901
biosboot will be written at sector 64

This doesn't work:

newfs -b 4096 -f 512 sd1a

/dev/rsd1a: 2047.3MB in 4192896 sectors of 512 bytes
168 cylinder groups of 12.24MB, 3134 blocks, 6272 inodes each
(...)

./installboot -v boot biosboot sd1

boot: boot proto: biosboot device: /dev/rsd1c
installboot: looking for superblock at 65536
installboot: bad superblock magic 0x0
installboot: looking for superblock at 8192
installboot: found valid ffs1 superblock
boot is 20 blocks x 4096 bytes
fs block shift 0; part offset 64; inode block 56, offset 1064
expecting 32-bit fs blocks (skew 0)
master boot record (MBR) at sector 0
partition 3: type 0xA6 offset 64 size 4192901
biosboot will be written at sector 64

I have a Trim-Slice that I would like to try bitrig on:

https://en.wikipedia.org/wiki/Trim-Slice

Is that considered a supported platform? Please let me know if I can help test things on this platform, too.

I've found that there are some files in sys/dev/microcode/ that have one of the following problems:

• There is little to no licensing information, causing the files to be potentially undistributable
• While distributable, there are other restrictions, such as preventing modification or allowing usage only with certain devices
• While distribution and modification are legally allowed, no source code is provided, making modification practically impossible

I understand that these files are required to make some devices work, but would it be possible to have an option in the installer to not include the sourceless firmware?

Folders with files which may not be distributable:

• sys/dev/microcode/cirruslogic (It is uncertain what the license is)
• sys/dev/microcode/tigon (It is uncertain what the license is)
• sys/dev/microcode/typhoon (No license seems to have been provided)

Folders with files that place legal restrictions:

• sys/dev/microcode/atmel (Modification not permitted)
• sys/dev/microcode/tusb3410 (Can't be used in devices not made by TI, can't reverse engineer)
• sys/dev/microcode/yds (Modification not permitted)

Folders with files that do not place legal restrictions, but are not in source code form

• sys/dev/microcode/adw
• sys/dev/microcode/afb
• sys/dev/microcode/bnx
• sys/dev/microcode/cyclades
• sys/dev/microcode/esa
• sys/dev/microcode/fxp
• sys/dev/microcode/isp
• sys/dev/microcode/kue
• sys/dev/microcode/myx
• sys/dev/microcode/neomagic
• sys/dev/microcode/ral
• sys/dev/microcode/rum
• sys/dev/microcode/symbol
• sys/dev/microcode/tht
• sys/dev/microcode/uyap
• sys/dev/microcode/zydas

Scaleway's C1 is based on a Marvell Armada 370 SoC. To support this, some code needs to be written. This is needed for #65.

• FDT-based clock support
• Clocks
• Timer
• Interrupt controller
• UART
• MBus
• Gigabit Ethernet controller
• MDIO bus (for pbox, not c1)
• SD-card
  • SDMMC DMA + high speed + more
• L2 Cache
• Watchdog (needs testing)
• extract console speed from bootargs
• compare and check cache functions with Net- and FreeBSD
• Putting it into the tree
• ...

Dmesg: http://ix.io/ieW

No way to install from latest iso (install10.iso) as packages are broken
xshare10.tgz / xfont10.tgz / xserv10.tgz . error: 'gzip stdin: unrecognised file format

This is a bit far-fetched and extremely difficult for a whole OS, but what do you guys think about test cases and maybe even automated build/CI in the future?

At a minimum, could maybe have Travis running some C syntax and basic build checking, along with shellcheck for shellscripts. Eventually, would be neat to test individual parts of the system and the system as a whole, emulating different kinds of hardware and validating the behavior.

I installed using http://mirror2.us.bitrig.org/pub/bitrig/snapshots/amd64/20150929/cd10.iso but PKG_PATH isn't set:

# echo $PKG_PATH

# uname -a
Bitrig bitrig.my.domain 1.0 GENERIC#0 amd64

# echo $SHELL
/bin/ksh

I assume this hasn't been implemented yet since it doesn't appear on the feature list, on the roadmap or in these issues. OpenBSD does not yet have this, but there are several drivers for Wireless N devices.

Each of the drivers that currently exist say that changes need to be made in ieee80211(9) (e.g. the iwn driver).

I don't know much about drivers or kernel development, but can work in C. Let me know if there's anything I can do to help out.

• SMP fix from OpenBSD
• paravirtualized network
• paravirtualized disk

I would like to help write a document that helps "on board" devs that want to help/hack on bitrig, guiding people on how we want them to contribute and what we need help with.

Would you prefer a markdown file in the repo, a wiki page, something on the main www site, or maybe something else?

Currently the installer does not fetch a mirror list and therefore the user has to manually add the mirror url. Code can be backported from OpenBSD to have this behaviour.

The MAC address for this interface is stored in the on-board EEPROM (i2c_bus:0x0, i2c_addr:0x50, offset 0x4).
Please refer to "arch/arm/mach-mx6/board-cm-fx6.c".
The code below reads the MAC from the EEPROM, stores into the private data and passes to the GBE driver.

static void cm_fx6_eeprom_setup(struct memory_accessor *mem_acc, void *context)
{
eeprom_read_mac_address(mem_acc, cm_fx6_fec_data.mac);
imx6_init_fec(cm_fx6_fec_data);
}

My mouse and keyboard don't work.

http://6xq.net/git/lars/lshidpp.git/plain/doc/logitech_hidpp_2.0_specification_draft_2012-06-04.pdf
https://drive.google.com/?tab=mo&pli=1&authuser=0#folders/0BxbRzx7vEV7eWmgwazJ3NUFfQ28