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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2011-08-15 at 15:18 +0200, Paul Menzel wrote:
> Dear folks,
> 
> 
> Am Montag, den 15.08.2011, 15:00 +0200 schrieb Paul Menzel:
> 
> > Am Donnerstag, den 14.07.2011, 23:35 +0200 schrieb Svante Signell:
> > > On Thu, 2011-07-14 at 13:27 -0500, Jonathan Nieder wrote:
> > 
> > > > 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.
> > 
> > thanks to Jonathan’s help I was able to perform the bisection.
> > 
> >         $ git bisect start 0f2cc4ecd81dc1917a041dc93db0ada28f8356fa 8724fdb53d27d7b59b60c8a399cc67f9abfabb33
> >         […]
> >         $ git bisect log
> >         # bad: [0f2cc4ecd81dc1917a041dc93db0ada28f8356fa] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6
> >         # good: [8724fdb53d27d7b59b60c8a399cc67f9abfabb33] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
> >         git bisect start '0f2cc4ecd81dc1917a041dc93db0ada28f8356fa' '8724fdb53d27d7b59b60c8a399cc67f9abfabb33'
> >         # good: [14f3ad6f4a12495b32b0dd743bc7179f36658208] ipv6: Use 1280 as min MTU for ipv6 forwarding
> >         git bisect good 14f3ad6f4a12495b32b0dd743bc7179f36658208
> >         # good: [60f8a8d4c6c46bb080e8e65d30be31b172a39a78] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse
> >         git bisect good 60f8a8d4c6c46bb080e8e65d30be31b172a39a78
> >         # bad: [7f5b09c15ab989ed5ce4adda0be42c1302df70b7] Merge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6
> >         git bisect bad 7f5b09c15ab989ed5ce4adda0be42c1302df70b7
> >         # good: [9f445cb29918dc488b7a9a92ef018599cce33df7] USB: musb: disable double buffering for older RTL versions
> >         git bisect good 9f445cb29918dc488b7a9a92ef018599cce33df7
> >         # bad: [fb7b096d949fa852442ed9d8f982bce526ccfe7e] Merge branch 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
> >         git bisect bad fb7b096d949fa852442ed9d8f982bce526ccfe7e
> >         # bad: [dce46a04d55d6358d2d4ab44a4946a19f9425fe2] early_res: Need to save the allocation name in drop_range_partial()
> >         git bisect bad dce46a04d55d6358d2d4ab44a4946a19f9425fe2
> >         # bad: [c252a5bb1f57afb1e336d68085217727ca7b2134] x86: Only call dma32_reserve_bootmem 64bit !CONFIG_NUMA
> >         git bisect bad c252a5bb1f57afb1e336d68085217727ca7b2134
> >         # bad: [9ad3f2c7c69659c343843393944d739fec1f2e73] x86/pci: Add cap_resource()
> >         git bisect bad 9ad3f2c7c69659c343843393944d739fec1f2e73
> >         # good: [27811d8cabe56e0c3622251b049086f49face4ff] x86: Move range related operation to one file
> >         git bisect good 27811d8cabe56e0c3622251b049086f49face4ff
> >         # bad: [3e3da00c01d050307e753fb7b3e84aefc16da0d0] x86/pci: AMD one chain system to use pci read out res
> >         git bisect bad 3e3da00c01d050307e753fb7b3e84aefc16da0d0
> > 
> > and `git bisect` showed me the same faulty commit as Svante found out:
> > b74fd238 [2].
> > 
> >         commit b74fd238a9cf39a81d94152f375b756bf795b4af
> >         Author: Yinghai Lu <yinghai@xxxxxxxxxx>
> >         Date:   Wed Feb 10 01:20:08 2010 -0800
> >         
> >             x86/pci: Use resource_size_t in update_res
> > 
> > (Is there a command to show that summary again? I could not find it in
> > the help.)
> > 
> > But I before started with the bisection I tried what Jonathan asked
> > Svante to do and b74fd238a9cf and b74fd238a9cf^ did not show these
> > problems. Additionally it is weird that I never had to test that commit
> > b74fd238 in that bisection run.
> > 
> > I will test it again¹ and rebuild it and report back. But I would
> > suspect 3e3da00c [2] as the culprit.
> > 
> >         commit 3e3da00c01d050307e753fb7b3e84aefc16da0d0
> >         Author: Yinghai Lu <yinghai@xxxxxxxxxx>
> >         Date:   Wed Feb 10 01:20:09 2010 -0800
> >         
> >             x86/pci: AMD one chain system to use pci read out res
> > 
> > `make` should take care of all necessary recompilations I guess, so no
> > `make clean`(?) is required.
> 
> So from my perspective I would say `git bisect` has a bug.
> 
>         $ git --version
>         git version 1.7.5.4
> 
> Here is the new result.
> 
>         $ git bisect good b74fd238a9cf39a81d94152f375b756bf795b4af
>         3e3da00c01d050307e753fb7b3e84aefc16da0d0 is the first bad commit
>         commit 3e3da00c01d050307e753fb7b3e84aefc16da0d0
>         Author: Yinghai Lu <yinghai@xxxxxxxxxx>
>         Date:   Wed Feb 10 01:20:09 2010 -0800
>         
>             x86/pci: AMD one chain system to use pci read out res
>             
>             Found MSI amd k8 based laptops is hiding [0x70000000, 0x80000000) RAM
>             from e820.
>             
>             enable amd one chain even for all.
>             
>             -v2: use bool for found, according to Andrew
>             
>             Signed-off-by: Yinghai Lu <yinghai@xxxxxxxxxx>
>             LKML-Reference: <1265793639-15071-6-git-send-email-yinghai@xxxxxxxxxx>
>             Acked-by: Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx>
>             Signed-off-by: H. Peter Anvin <hpa@xxxxxxxxx>
>         
>         :040000 040000 44e134ff22492c50d49c5e66880cfbf0b6738e50 f3e9511913b613c2f98e96136927b5ed44736e4e M	arch
> 
> Please notice that with this patch also the following messages seem to
> start to be written to the Linux kernel ring buffer (`dmesg`).
> 
>         [    0.227319] pnp 00:0e: disabling [mem 0x00000000-0x0009ffff] because it overlaps 0000:00:00.0 BAR 0 [mem 0x00000000-0x07ffffff pref]
>         [    0.227324] pnp 00:0e: disabling [mem 0x000c0000-0x000bffff disabled] because it overlaps 0000:00:00.0 BAR 0 [mem 0x00000000-0x07ffffff pref]
>         [    0.227330] pnp 00:0e: disabling [mem 0x000e0000-0x000fffff] because it overlaps 0000:00:00.0 BAR 0 [mem 0x00000000-0x07ffffff pref]
>         [    0.227334] pnp 00:0e: disabling [mem 0x00100000-0x77ffffff] because it overlaps 0000:00:00.0 BAR 0 [mem 0x00000000-0x07ffffff pref]
> 
> 
> Thanks,
> 
> Paul
> 
> 
> > ¹ It would be nice if the SHA1 checksum of the commit could be
> > incorporated in the Debian package somehow.
> > 
> > 
> > [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b74fd238a9cf39a81d94152f375b756bf795b4af
> > [2] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3e3da00c01d050307e753fb7b3e84aefc16da0d0


I'm back now and have physical access to the computer. How can I confirm
the commit causing the problems?

--
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


[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux