Port-amd64 archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
HP ProLiant BL460c G1 boot failure
Hi,
I recently tried to boot a recent 4.99.72/amd64 bootable ISO
image on a HP ProLiant BL460c G1 "blade" in a blade server
chassis.
This failed as follows:
...
bnx0 at pci4 dev 0 function 0: Broadcom NetXtreme II BCM5708 1000Base-SX
bnx0: SerDes controllers are not supported!
uvm_fault(0xffffffff811089a0, 0x0, 1) -> e
fatal page fault in supervisor mode
trap type 6 code 0 rip ffffffff804cb1d4 cs 8 rflags 10202 cr2 30 cpl 8 rsp
ffffffff81157c30
kernel: page fault trap, code=0
Stopped in pid 0.1 (system) at 0xffffffff804cb1d4: movq 0x30(%rax),%r11
db{0}> tra
?() at 0xffffffff804cb1d4 (bus_dmamap_load_mbuf)
?() at 0xffffffff805ac260 (bnx_attach)
?() at 0xffffffff8042554a (config_attach_loc)
?() at 0xffffffff8050f764 (pci_probe_device)
?() at 0xffffffff8050f8fb (pci_enumerate_bus)
?() at 0xffffffff8050f9e0 (pcirescan)
?() at 0xffffffff8050fd87 (pciattach)
?() at 0xffffffff8042554a (config_attach_loc)
?() at 0xffffffff8054853c (ppbattach)
?() at 0xffffffff8042554a (config_attach_loc)
?() at 0xffffffff8050f764 (pci_probe_device)
?() at 0xffffffff8050f8fb (pci_enumerate_bus)
?() at 0xffffffff8050f9e0 (pcirescan)
?() at 0xffffffff8050fd87 (pciattach)
...
One: I assume "SerDes controllers are not supported!" means that
the driver doesn't support fibre-optic versions of this device.
Is there a particular reason this isn't supported in our driver? It
appears that FreeBSD's bce(4) driver supports these variants; it even
supports the non-standard "2.5Gbit/s" mode.
Two: I've decoded the stack trace by hand using the sorted output of
netbsd-INSTALL.symbols.gz. The crash may be related to the "SerDes
controllers are not supported!" message -- but it's still definately a
bug. (%rax == 0 in "show reg" output, so this is a null pointer de-
reference.)
Three: This is booted from the .iso image created during a normal
release build. Is there a good reason why DDB is unable to decode the
addresses in the traceback into symbols, so that manual methods are
required for doing the decoding?!? I would have thought that typical
amd64 systems have enough memory that "save some memory" would be more
or less invalid as an argument for leaving out the symbols.
Regards,
- Håvard
Home |
Main Index |
Thread Index |
Old Index