The tweaked AMD64 GENERIC works like a charm.  The compiled-in ddb
support wasn't necessary.  I had to comment out ioapic support too.
I'm going to check if GENERIC.MP turns out alright as well.
Interestingly though, I loaded 3.1 onto a twa-driven logical disk,
disabled the satalink device in BIOS, and netbsd {GENERIC |
GENERIC.MP | Custom MP with ACPI and linux emulation} crashed upon
finishing the init routines...  I went out and bought a serial cable
and will report back with more information...

<<carlos>>
<<nvllvmmagnvmingenivmsinemixtvradementiae>>

On Jan 14, 2007, at 2:27 PM, Manuel Bouyer wrote:

> On Sun, Jan 14, 2007 at 12:47:35AM -0500, the carlos wrote:
>> lapic_delay() at netbsd:lapic_delay+0x36
>> bge_miibus_readreg() at netbsd:bge_miibus_readreg+0x7b
>> brgphy_status() at netbsd:brgphy_status+0x46
>> mii_phy_status() at netbsd:mii_phy_status+0xe
>> brgphy_service() at netbsd:brgphy_service+0x40
>> mii_phy_auto_timeout() at netbsd:mii_phy_auto_timeout+0x48
>> softclock() at netbsd:softclock+0x2c9
>> softintr_dispatch() at netbsd:softintr_dispatch+0x99
>> DDB lost frame for netbsd:Xsoftclock+0x2d, trying 0xffffffff80a2cd00
>> Xsoftclock() at netbsd:Xsoftclock+0x2d
>> --- interrupt ---
>> 0x246:
>>
>> That trace came out of the 3.1 recently patched DEBUG kernel...
>
> panic in lapic_delay ... what happens if you use a kernel without
> MPBIOS or acpi (like a GENERIC kernel with options MPBIOS commented
> out) ?
> But I see no reasons for this to happens ...
>
>> What
>> does ddb.onpanic do?
>
> It causes the box to reboot instead of droping to ddb in
> case of panic.
>
> --
> Manuel Bouyer <bouyer@antioche.eu.org>
>      NetBSD: 26 ans d'experience feront toujours la difference
> --