Bug#619034: [regression] "BUG: Unable to handle kernel paging request at ffffc90013cd8000" and no sound card recognized

[Jonathan Nieder <jrnieder@gmail.com>]

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?

Puzzled,
Jonathan