On Thu, 2011-07-14 at 13:27 -0500, Jonathan Nieder wrote: > Hi, > > Takashi Iwai wrote: > >>> On Wed, 2011-03-30 at 15:13 +0200, Clemens Ladisch wrote: > >>>>>>>>> Svante Signell wrote: > > >>>>>>>>>> During boot of kernel 2.6.38 (and 2.6.37) udev bugs out: > >>>>>>>>>> Waiting for /dev to be fully populated > >>>>>>>>>> BUG: Unable to handle kernel paging request at ffffc90013cd8000 > >>>>>>>>>> axz_probe+ ... [snd_hda_intel] > >>>>>>>>>> ...lots of output lost... > >>>>>>>>>> udevadm timeout 180 sec ... > >>>>>>>>>> udevd[390]: worker [439] failed while handling > >>>>>>>>>> '/devices/pci0000:80/0000:80:01.0' > >>>>>>>>>> > >>>>>>>>>> After the timeout the boot continues! Have not yet tested if sound is > >>>>>>>>>> functional. > [...] > >>>> This is the azx_readw(chip, GCAP) in azx_create(); chip->remap_addr is > >>>> 0xffffc90011c08000 which does look like a valid pointer, but isn't. > [...] > > The point where it Oops implies that the problem isn't in the sound > > driver but rather in a breakage in a deeper level, either PCI core, > > x86 mm or ACPI/BIOS. > > > > Any chance to bisect the kernel? > > Svante bisected it to v2.6.34-rc1~218^2~27 (x86/pci: Use > resource_size_t in update_res, 2010-02-10) --- thanks. Which is > pretty weird, since I think phys_addr_t on an amd64 machine (and hence > resource_size_t) would be 64 bits, making that commit a no-op. > > Svante, more questions (sorry): > > - could you try booting b74fd238a9cf and b74fd238a9cf^ again > (to make sure we haven't hit a heisenbug) and send the > corresponding full dmesg and .config files? I am very sorry but I don't have physical access to that box for a month from now. However, something that might be more interesting is the output of the second-to last message that was concerning x86/pci/amd/.... I might get help to find that message in a few days. -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
