HP NetServer boot trouble
der Mouse
which the donor tells me contains a dual Pentium III.
I got it home and looked for a handy install CD; the first one I found
was 4.0.1. Since the machine is old enough to be HP-branded, I figured
4.0.1 should handle it OK (besides, I think it's the most recent CD I
actually have a burnt copy of on hand).
Well...it sort of does. Sort of.
When I first booted (no special options), it exploded early in the boot
process. I have a ten-finger copy of what was visible then, but I
suspect it doesn't matter (see below); I can provide it if it would
help. A backtrace in ddb made me suspect ACPI. So I booted with -c
and told it to "disable acpi"; then it boots, but finds only one of the
two CPUs the with-ACPI boot messages show. (I can also supply dmesg
from this boot, including a ten-finger copy of stuff that was printed
too early to make it into dmesg.)
I'd rather use both cores if I can. I did some Web searching (ugh) and
it appears the penguin prints a similar message but doesn't actually do
anything for it. Looking at the (NetBSD) code gives me the feeling
this is some kind of debugging facility and I could "fix" it by just
having AcpiOsSignal handle ACPI_SIGNAL_BREAKPOINT by silently returning
without doing anything.
Right? Wrong? Am I missing something? (Okay, I'm surely missing lots
of things. Am I missing something _relevant_? :) I'll be getting it
started building a kernel (running uniprocessor) with that change made,
in the interim....
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Joerg Sonnenberger
> I'd rather use both cores if I can. I did some Web searching (ugh) and
> it appears the penguin prints a similar message but doesn't actually do
> anything for it. Looking at the (NetBSD) code gives me the feeling
> this is some kind of debugging facility and I could "fix" it by just
> having AcpiOsSignal handle ACPI_SIGNAL_BREAKPOINT by silently returning
> without doing anything.
There were some ACPI tables in productive BIOSes that contained ACPI
break points. Those are skipped now (since 5.0 or so?), so if that
really is the problem, try a 5.x kernel first.
Joerg
der Mouse
>> Looking at the (NetBSD) code gives me the feeling this is some kind
>> of debugging facility and I could "fix" it by just having
>> AcpiOsSignal handle ACPI_SIGNAL_BREAKPOINT by silently returning
>> without doing anything.
> There were some ACPI tables in productive BIOSes that contained ACPI
> break points. Those are skipped now (since 5.0 or so?), so if that
> really is the problem, try a 5.x kernel first.
No joy. (It also appears they're not as skipped as you think.)
I found and burnt the 5.1 i386 ISO to a CD. Booting this the default
way, ie, with ACPI enabled, gives me (ten-finger copy)
Loading /miniroot.kmod
Copyright ...blah blah...
NetBSD 5.1 (GENERIC) #0: Sun Nov 7 14:39:56 UTC 2010
bui...@b6.netbsd.org:/home/builds/ab/netbsd-5-1-RELEASE/i386/20101106194
32-obj/home/builds/ab/netbsd-5-1-RELEASE/src/sys/arch/i386/compile/GENERIC
total memory = 1024 MB
avail memory = 989 MB
Hewlett-Packard HP NetServer (LP 1000r)
mainbus0 (root)
cpu0 at mainbus0 apid 3: Intel 686-class, 1266MHz, id 0x6b1
cpu1 at mainbus0 apid 0: Intel 686-class, 1266MHz, id 0x6b1
ioapic0 at mainbus0 apid 1
ioapic1 at mainbus0 apid 2
acpi0 at mainbus0: Intel ACPICA 20080321
LNKU: BIOS IRQ 10 for 0.15.INTA is invalid
Executed AML Breakpoint opcode
fatal breakpoint trap in supervisor mode
trap type 1 code 0 eip c057a54c cs 8 eflags 282 cr2 0 ilevel 8
Stopped in pid 0.1 (system) at netbsd:breakpoint+0x4: popl %ebp
db{0}>
If I "c" here, it carries on with autoconf but wedges later (more
ten-finger copying):
scsibus0: waiting 2 seconds for devices to settle...
scsibus1: waiting 2 seconds for devices to settle...
cpu1: failed to start
fd0 at fdc0 drive 0: 1.44MB, 80 cyl, 2 head, 18 sec
uhub0 at usb0: vendor 0x1166 OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
sd0 at scsibus0 target 0 lun 0: <DEC, RZ1CF-AF (C) DEC, 1614> disk fixed
sd0: 4091 MB, 3708 cyl, 20 head, 113 sec, 512 bytes/sect x 8380080 sectors
sd0: sync (100.00ns offset 31), 8-bit (10.000MB/s) transfers
ses0 at scsibus0 target 11 lun 0: <SDR, GEM318, 0> processor fixed
ses0: SAF-TE Compliant Device
ses0: async, 8-bit transfers
atapibus0 at atabus0: 2 targets
cd0 at atapibus0 drive 0: <CD-224E, , 1.5A> cdrom removable
If I instead pick the "no ACPI" option (ie, without also suppressing
SMP), it boots apparently normally - it comes up far enough for me to
NFS-mount another machine and dump dmesg output to it.
I also have reason to suspect that just disabling
ACPI_SIGNAL_BREAKPOINT won't fix 4.0.1; I tried just "c"ing from the
ddb prompt, and it appears to come up but gets errors trying to probe
the SCSI bus, then more errors trying to talk to the CD. If I boot -c
and "disable acpi" these errors go away.
I guess I need to figure out whether MP support on this hardware is
worth trying to rebase all my changes atop 5.1. Ugh. :( I think I'll
try disabling ACPI_SIGNAL_BREAKPOINT in 4.0.1 in the (admittedly faint)
hope that that is relevantly different from continuing from ddb....
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
--
Joerg Sonnenberger
> >> [ACPI breakpoint opcode in NetServer LP 1000r]
> >> of debugging facility and I could "fix" it by just having
> >> AcpiOsSignal handle ACPI_SIGNAL_BREAKPOINT by silently returning
> >> without doing anything.
> > break points. Those are skipped now (since 5.0 or so?), so if that
> > really is the problem, try a 5.x kernel first.
>
Ah, looks like my memory is at fault. It's dev/acpi/acpica/OsdMisc.c,
revision 1.6. netbsd-5 was branched from 1.5...
> If I "c" here, it carries on with autoconf but wedges later (more
> ten-finger copying):
What's your problem -- the cpu1: failed to start?
>
> scsibus0: waiting 2 seconds for devices to settle...
> scsibus1: waiting 2 seconds for devices to settle...
> cpu1: failed to start
> fd0 at fdc0 drive 0: 1.44MB, 80 cyl, 2 head, 18 sec
> uhub0 at usb0: vendor 0x1166 OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
> sd0 at scsibus0 target 0 lun 0: <DEC, RZ1CF-AF (C) DEC, 1614> disk fixed
> sd0: 4091 MB, 3708 cyl, 20 head, 113 sec, 512 bytes/sect x 8380080 sectors
> sd0: sync (100.00ns offset 31), 8-bit (10.000MB/s) transfers
> ses0 at scsibus0 target 11 lun 0: <SDR, GEM318, 0> processor fixed
> ses0: SAF-TE Compliant Device
> ses0: async, 8-bit transfers
> atapibus0 at atabus0: 2 targets
> cd0 at atapibus0 drive 0: <CD-224E, , 1.5A> cdrom removable
Joerg
der Mouse
> revision 1.6. netbsd-5 was branched from 1.5...
That would explain it. I should look at the diffs and see if I can use
1.6 directly or if I need to tweak the diff....
>> If I "c" here, it carries on with autoconf but wedges later (more
>> ten-finger copying):
> What's your problem -- the cpu1: failed to start?
Well, that's part of it, but probably more significant, and certainly
more usefulness-impairing, is that it hangs right after the "cd0 at
atapibus0" line - the point where I stopped quoting messages. I quoted
all the way back to "cpu1: failed to start" because it struck me as
probably significant.