Success: Haiku b5 on a MediaForum GN34

(First-time poster here! @admins: “Feedback / Hardware” seems like the most applicable subforum - please feel free to relocate it if that’s not the best match.)

After months of wanting to run Haiku on a spare computer, but it not recognizing the built-in network adapters on my spare machine, i remembered that a 22±year-old USB2 10/100 ethernet adapter was laying around in my “random cables” box…

Haiku actually supports it! Unsurprisingly, the network is slow as molasses (right at 1mb/sec in the LAN, which was plenty fast back when i got that adapter) but it works. The OS, of course, is as snappy as ever.

The computer is a MediaForum GN34, a machine i’ve had for 4-5 years and absolutely love. i’ve had less success/more grief with the couple of other MediaForum models i’ve tried, but the GN34 is a solid box which idles at only a couple of watts.

Pic or it didn’t happen:

8 Likes

Seems like the right place to me :slight_smile:

Welcome here, enjoy your new Haiku install!

Can you share the output of listdev for these network adapters? Maybe one of the developers could then do something about it.

The relevant pieces are:

device Network controller (Ethernet controller) [2|0|0]
  vendor 10ec: Realtek Semiconductor Co., Ltd.
  device 8168: RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller

device Network controller [2|80|0]
  vendor 8086: Intel Corporation
  device 3165: Wireless 3165

The wifi device shows up in the network config but it has a MAC of 0, which a post i read earlier suggests means a driver limitation or compatibility issue. eth0, OTOH, does not show up at all:

/dev/net/pegasus/0
	Hardware type: Ethernet, Address: 00:05:1b:00:7a:99
	Media type: Auto-select
	inet addr: 192.168.178.40, Bcast: 192.168.178.255, Mask: 255.255.255.0
	MTU: 1500, Metric: 0, up broadcast link auto-configured
	Receive: 1715 packets, 0 errors, 163545 bytes, 0 mcasts, 0 dropped
	Transmit: 1527 packets, 0 errors, 176884 bytes, 0 mcasts, 0 dropped
	Collisions: 0

loop	Hardware type: Local Loopback, Address: none
	inet addr: 127.0.0.1, Mask: 255.0.0.0
	inet6 addr: ::1, Prefix Length: 128
	MTU: 65536, Metric: 0, up loopback link
	Receive: 0 packets, 0 errors, 0 bytes, 0 mcasts, 0 dropped
	Transmit: 0 packets, 0 errors, 0 bytes, 0 mcasts, 0 dropped
	Collisions: 0

/dev/net/idualwifi7260/0
	Hardware type: Ethernet, Address: 00:00:00:00:00:00
	inet addr: --, Bcast: --, Mask: --
	MTU: 1500, Metric: 0, up broadcast
	Receive: 0 packets, 0 errors, 0 bytes, 0 mcasts, 0 dropped
	Transmit: 0 packets, 0 errors, 0 bytes, 0 mcasts, 0 dropped
	Collisions: 0

“pegasus” is my ancient, but apparently reliable, USB2 10/100 ethernet adapter.

There’s another (much newer) USB ethernet adapter which is currently in use on another device, but Haiku can’t see that one, either. Edit: just tried that one, a combo USB hub/ethernet adapter, and listdev doesn’t see it up at all. Linux is listing it as a ethernet interface from vendor ASIX, product ID AX88179A.

i was thrilled to be able to move away from a VM onto real hardware, though, even if the download speeds are currently capped at a meg a second. Swapping between a Haiku VM and its Linux host plays painful havoc with my muscle memory because of Haiku’s practice of “swapping” the ctrl and alt in so many places. i understand that’s a divisive topic with a long history and won’t beat that dead horse here.

In case you don’t know,you can switch the CTRL and ALT keys in the Keymap preferences.
That can have some surprising side effects (combinations that worked like everywhere else before are now swapped),but for the big majority of shortcuts you get a Windows-like behaviour with it.

For USB devices in beta 5 you have to look in listusb instead of listdev. We have changed that in the current nightly builds so listdev now also includes USB devices.

For the built-in wired ethernet, this device should be handled by the rtl81xx driver. There have not been any changes to that one since beta5 and it is synchronized with FreeBSD 14. I assume some other part of the hardware is not compatible with the driver, and in that case, we should find some clues if you share the syslog (found in /boot/system/var/log/syslog).

Likewise for the wifi, the syslog may tell us what the driver is unhappy with.

1 Like

Great, thank you - i’ll try that out later, but first…

Indeed, syslog is seeing as an rtl81xx. Its messages are a bit intertwined with the wifi device:

KERN: pci_reserve_device(2, 0, 0, idualwifi7260)
KERN: [idualwifi7260] (iwm) bus_alloc_resource(3, [16], 0x0, 0xffffffffffffffff, 0x1,0x2)
KERN: set MTRRs to:
KERN:   mtrr:  0: base:        0x0, size:     0x2000, type: 0
KERN:   mtrr:  1: base: 0x79800000, size:   0x400000, type: 0
KERN:   mtrr:  2: base: 0x80000000, size: 0x10000000, type: 0
KERN:   mtrr:  3: base: 0xc0000000, size: 0x40000000, type: 0
KERN:   mtrr:  4: base: 0x80000000, size: 0x80000000, type: 1
KERN: allocate_io_interrupt_vectors: allocated 1 vectors starting from 66
KERN: msi_allocate_vectors: allocated 1 vectors starting from 66
KERN: [idualwifi7260] (iwm) bus_alloc_resource(1, [1], 0x0, 0xffffffffffffffff, 0x1,0x2)
KERN: msi enabled: 0x0081
KERN: , <NULL>
KERN: if_attach 0xffffffffa2e6bcf0
KERN: if_attach 0xffffffffa29a82f0
KERN: idualwifi7260: timeout waiting for clock stabilization
KERN: idualwifi7260: apm init error -2147483639
KERN: idualwifi7260: could not initialize hardware
KERN: if_initname(0xffffffff8268e008, iwm, 0)
KERN: [idualwifi7260] idualwifi7260: /dev/net/idualwifi7260/0
KERN: start_wlan: wlan started.
KERN: idualwifi7260: init_driver(0xffffffffa0fa8930)
KERN: loaded driver /boot/system/add-ons/kernel/drivers/dev/net/idualwifi7260
KERN: loaded driver /boot/system/add-ons/kernel/drivers/dev/net/usb_rndis
KERN: usb_davicom:00.06.792:init_driver::ver.0.9.5
KERN: loaded driver /boot/system/add-ons/kernel/drivers/dev/net/usb_davicom
KERN: usb_asix:00.06.793:init_driver::ver.0.10.1
KERN: loaded driver /boot/system/add-ons/kernel/drivers/dev/net/usb_asix
KERN: loaded driver /boot/system/add-ons/kernel/drivers/dev/net/pegasus
KERN: etherpci: init_driver init_driver: etherpci not found
KERN: pci_reserve_device(1, 0, 0, rtl81xx)
KERN: [rtl81xx] (re) bus_alloc_resource(3, [24], 0x0, 0xffffffffffffffff, 0x1,0x2)
KERN: set MTRRs to:
KERN:   mtrr:  0: base:        0x0, size:     0x2000, type: 0
KERN:   mtrr:  1: base: 0x79800000, size:   0x400000, type: 0
KERN:   mtrr:  2: base: 0x80000000, size: 0x10000000, type: 0
KERN:   mtrr:  3: base: 0xc0000000, size: 0x40000000, type: 0
KERN:   mtrr:  4: base: 0x80000000, size: 0x80000000, type: 1
KERN: [rtl81xx] (re) MSI count : 1
KERN: [rtl81xx] (re) MSI-X count : 4
KERN: [rtl81xx] (re) bus_alloc_resource(3, [32], 0x0, 0xffffffffffffffff, 0x1,0x2)
KERN: set MTRRs to:
KERN:   mtrr:  0: base:        0x0, size:     0x4000, type: 0
KERN:   mtrr:  1: base: 0x79800000, size:   0x400000, type: 0
KERN:   mtrr:  2: base: 0x80000000, size: 0x10000000, type: 0
KERN:   mtrr:  3: base: 0xc0000000, size: 0x40000000, type: 0
KERN:   mtrr:  4: base: 0x80000000, size: 0x80000000, type: 1
KERN: set MTRRs to:
KERN:   mtrr:  0: base:        0x0, size:     0x4000, type: 0
KERN:   mtrr:  1: base: 0x79800000, size:   0x400000, type: 0
KERN:   mtrr:  2: base: 0x80000000, size: 0x10000000, type: 0
KERN:   mtrr:  3: base: 0xc0000000, size: 0x40000000, type: 0
KERN:   mtrr:  4: base: 0x80000000, size: 0x80000000, type: 1
KERN: allocate_io_interrupt_vectors: allocated 1 vectors starting from 67
KERN: msi_allocate_vectors: allocated 1 vectors starting from 67
KERN: msix configured for 1 vectors
KERN: [rtl81xx] (re) Using 1 MSI-X message
KERN: [rtl81xx] (re) bus_alloc_resource(1, [1], 0x0, 0xffffffffffffffff, 0x1,0x2)
KERN: [rtl81xx] (re) Chip rev. 0x00000000
KERN: [rtl81xx] (re) MAC rev. 0x00000000
KERN: [rtl81xx] (re) reset never completed!
KERN: if_initname(0xffffffff80cc6800, re, 33)
KERN: [rtl81xx] rtl81xx: /dev/net/rtl81xx/0
KERN: package_daemon: [6945888:    87] The latest volume state is also the currently active one
KERN: package_daemon: [6945996:    87] Volume::InitialVerify((nil), (nil))
KERN: package_daemon: [6960966:    87] Volume::InitialVerify(): volume at "/boot/system" is consistent
KERN: package_daemon: [6962814:    87] Failed to open packages activation file /boot/home/config/packages/administrative/activated-packages: No such file or directory
KERN: package_daemon: [6962850:    87] Failed to get activated packages info from activated packages file. Assuming all package files in package directory are activated.
KERN: package_daemon: [6962864:    87] The latest volume state is also the currently active one
KERN: package_daemon: [6962913:    87] Volume::InitialVerify(0x120e347def40, (nil))
KERN: package_daemon: [6968767:    87] Volume::InitialVerify(): volume at "/boot/home/config" is consistent
KERN: [rtl81xx] (re) PHY read failed
KERN: [rtl81xx] (re) attaching PHYs failed
KERN: msi_free_vectors: freeing 1 vectors starting from 67
KERN: free_io_interrupt_vectors: freeing 1 vectors starting from 67
KERN: set MTRRs to:
KERN:   mtrr:  0: base:        0x0, size:     0x4000, type: 0
KERN:   mtrr:  1: base: 0x79800000, size:   0x400000, type: 0
KERN:   mtrr:  2: base: 0x80000000, size: 0x10000000, type: 0
KERN:   mtrr:  3: base: 0xc0000000, size: 0x40000000, type: 0
KERN:   mtrr:  4: base: 0x80000000, size: 0x80000000, type: 1
KERN: set MTRRs to:
KERN:   mtrr:  0: base:        0x0, size:     0x2000, type: 0
KERN:   mtrr:  1: base: 0x79800000, size:   0x400000, type: 0
KERN:   mtrr:  2: base: 0x80000000, size: 0x10000000, type: 0
KERN:   mtrr:  3: base: 0xc0000000, size: 0x40000000, type: 0
KERN:   mtrr:  4: base: 0x80000000, size: 0x80000000, type: 1
KERN: set MTRRs to:
KERN:   mtrr:  0: base:        0x0, size:     0x2000, type: 0
KERN:   mtrr:  1: base: 0x79800000, size:   0x400000, type: 0
KERN:   mtrr:  2: base: 0x80000000, size: 0x10000000, type: 0
KERN:   mtrr:  3: base: 0xc0000000, size: 0x40000000, type: 0
KERN:   mtrr:  4: base: 0x80000000, size: 0x80000000, type: 1
KERN: pci_unreserve_device(1, 0, 0, rtl81xx)
KERN: register_domain(5, internet6)
DAEMON 'DHCP': /dev/net/pegasus/0: Send DHCP_DISCOVER to 255.255.255.255:67
KERN: [net/idualwifi7260/0] compat_open(0x2)
KERN: idualwifi7260: timeout waiting for clock stabilization
KERN: idualwifi7260: apm init error -2147483639
KERN: idualwifi7260: could not initialize hardware
KERN: /dev/net/idualwifi7260/0: link down, media 0x80 quality 1000 speed 0

Sidebar: also tons of “pegasus: ERROR read: bad frame size 1522” (“last message repeated 2872 times”…) for the working pegasus adapter, which may (he vaguely speculates) have something to do with its apparent speed of 10mbit instead of 100mbit, but i’m not truly not concerned about that adapter’s speed.

Interesting. Both drivers seem to fail quite early in the initialization. Either this is an unlikely case of two broken drivers, or there is a common cause.

In this case, maybe some problem with the PCI bus not working correctly, and all reads returning 0. I say that because these two should probably not be all zeros:

KERN: [rtl81xx] (re) Chip rev. 0x00000000
KERN: [rtl81xx] (re) MAC rev. 0x00000000

Unfortunately, debugging this without access to the machine would be pretty difficult. Unless there are some known problems with workarounds in other OS that we could copy in our driver for the PCI bus?

1 Like

The “pegasus” driver itself is an old port of a driver from FreeBSD, but from before our FreeBSD compatibility layer gained support for USB devices. I should see about replacing it with a newer port. (And maybe also replacing our homegrown ASIX driver with the FreeBSD one, too…)