Re: No root filesystem

From: Pascal Hofstee <caelian_at_gmail.com>
Date: Mon, 1 Sep 2008 09:21:16 +0200
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
Received on Mon Sep 01 2008 - 05:21:20 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:34 UTC