On Sat, Jun 27, 2015 at 04:09:08PM +0300, Andrey Korolyov wrote:
Hello,
can anyone please provide a solid pointer for a 'patch' mentioned in http://www.coreboot.org/NetBSD#Interrupt_routing? It looks like that the even recent MPBIOS code in NetBSD kernel is not able to place all interrupts correctly if coreboot is used with SeaBIOS payload, my 82577 does not work exactly because of that under this OS. The target hardware is a well-supported X201 platform, if this can add more sense.
The patch is unnecessary if the payload is SeaBIOS, which is the payload you want to use to boot NetBSD anyway. I barely remember the details of the patch at this point, and I have no idea if I still have it laying around.
Anyway, you almost certainly don't want to be relying on anything other than the DSDT for interrupt routing on a modern machine with a modern OS.
Jonathan Kollasch
On Sat, Jun 27, 2015 at 4:28 PM, Jonathan A. Kollasch jakllsch@kollasch.net wrote:
On Sat, Jun 27, 2015 at 04:09:08PM +0300, Andrey Korolyov wrote:
Hello,
can anyone please provide a solid pointer for a 'patch' mentioned in http://www.coreboot.org/NetBSD#Interrupt_routing? It looks like that the even recent MPBIOS code in NetBSD kernel is not able to place all interrupts correctly if coreboot is used with SeaBIOS payload, my 82577 does not work exactly because of that under this OS. The target hardware is a well-supported X201 platform, if this can add more sense.
The patch is unnecessary if the payload is SeaBIOS, which is the payload you want to use to boot NetBSD anyway. I barely remember the details of the patch at this point, and I have no idea if I still have it laying around.
Anyway, you almost certainly don't want to be relying on anything other than the DSDT for interrupt routing on a modern machine with a modern OS.
Thanks, disabling MPBIOS and therefore relying purely on what was populated by ACPI didn`t help with issue. Just to mention - Linux kernel works just fine with same device numbers, so the nature of the problem is a bit unclear to me (driver`s code for 'unable to map interrupt' suggests that there was no interrupt number provided at all). Sadly the wireless driver behaves very poorly with 6250, leaving no alternative for remote connection than a temporarily broken ethernet link:
64 bytes from 192.168.1.36: icmp_seq=2 ttl=255 time=14.0 ms 64 bytes from 192.168.1.36: icmp_seq=5 ttl=255 time=3.50 ms 64 bytes from 192.168.1.36: icmp_seq=7 ttl=255 time=13.5 ms
-
Andrey Korolyov -
Jonathan A. Kollasch