No root filesystem
Pascal Hofstee
caelian at gmail.com
Mon Sep 1 07:21:20 UTC 2008
On Sat, Aug 30, 2008 at 3:05 AM, Christian Weisgerber
<naddy at mips.inka.de> wrote:
> John Baldwin:
>
>> So the reports I've seen of this all involve the Nvidia MCP55 ATA chipset, and
>> only the ata controller loses its marbles (so to speak).
>
> I also observe that k8temp doesn't attach. Maybe Pascal can check this.
> It's not part of GENERIC, so k8temp.ko needs to be explicitly loaded
> by the loader for this.
>
> k8temp0: <AMD K8 Thermal Sensors> on hostb3
Ok .. this morning i went ahead and collected two boot -v logs. One
for the old (working) kernel and one for the new (broken) kernel. For
this i made sure not to load the snd_hda module as that tended to
bloat the verbose boot output beyond the limit that i could still get
to the interesting data at the next boot. The two verbose bootlogs can
be found at:
http://shadowrun.homeunix.net/boot.verbose.working for the old kernel
http://shadowrun.homeunix.net/boot.verbose.broken for the new kernel
http://shadowrun.homeunix.net/boot.verbose.diff for the differences
between the two.
The part that really stood out for me is the section of found devices
on pcib0: slot 8 INTA routed to irq 22 via \\_SB_.LMAC
The working kernel shows several devices there that do Not show up on
the new kernel, according to http://www.pcidatabase.com this concerns
the following devices all by"Advanced Micro Devices"
-found-> vendor=0x1022, dev=0x1100, revid=0x00
0x1100 HyperTransport Technology Configuration
-found-> vendor=0x1022, dev=0x1101, revid=0x00
0x1101 Address Map
-found-> vendor=0x1022, dev=0x1102, revid=0x00
0x1102 DRAM Controller
-found-> vendor=0x1022, dev=0x1103, revid=0x00
0x1103 Miscellaneous Control
I believe this to be rather significant especially because of the way
the old kernel hooks up my SATA disks:
(ata2-master -> ata2 | ata3-master -> ata3) -> atapci1 -> pci0 -> pcib0
Also i can confirm that indeed k8temp for me also does not even probe
with the new kernel.
Beyond that i do not see anything majorly different between the two
verbose boot logs.
I hope this information will provide enough insight into the observed problem :)
--
Pascal Hofstee
More information about the freebsd-current
mailing list