Bug 10711 - BUG: unable to handle kernel paging request - scsi_bus_uevent
BUG: unable to handle kernel paging request - scsi_bus_uevent
Status: CLOSED CODE_FIX
Product: IO/Storage
Classification: Unclassified
Component: SCSI
All Linux
: P1 normal
Assigned To: linux-scsi@vger.kernel.org
:
Depends on:
Blocks: 10492
  Show dependency treegraph
 
Reported: 2008-05-15 15:42 UTC by Rafael J. Wysocki
Modified: 2008-06-16 14:49 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.26-rc2
Tree: Mainline
Regression: Yes


Attachments

Description Rafael J. Wysocki 2008-05-15 15:42:25 UTC
Subject    : BUG: unable to handle kernel paging request - scsi_bus_uevent
Submitter  : "Zdenek Kabelac" <zdenek.kabelac@gmail.com>
Date       : 2008-05-14 11:23
References : http://lkml.org/lkml/2008/5/14/111

This entry is being used for tracking a regression from 2.6.25.  Please don't
close it until the problem is fixed in the mainline.
Comment 1 Zdenek Kabelac 2008-05-20 05:19:57 UTC
Bug happend at least twice on my desktop with 2.6.26-rc3 - thought now I do not have such a backtrace as this deadlock now kills the machine -  I just know that RIP was from scsi_bus_uevent. If it would be worth to add - I could try to add a camera snapshost - but the trace is far from complete (just some bottom lines :( ).

The error happens once per couple reboots - but it is unpredicteble and hard to check. But it is definitely present in -rc3
Comment 2 Sitsofe Wheeler 2008-05-20 14:19:48 UTC
Yes I still see it too despite the patches mentioned in http://groups.google.com/group/fa.linux.kernel/browse_frm/thread/b64dbe94dea882cb/a8f1d83328fcbdc3?#a8f1d83328fcbdc3 . I bisected it down in http://groups.google.com/group/fa.linux.kernel/msg/c36e78f19fc4aaa3 and reverting the commit [dc16f5f2ede8cc2acf8ac22857a7fecf3a4296c2] PNP: make generic pnp_add_dma_resource() semmed to make the problem go away.
Comment 3 Sitsofe Wheeler 2008-05-23 12:45:22 UTC
This seems to have been resolved by James's patch in http://groups.google.com/group/fa.linux.kernel/browse_frm/thread/b64dbe94dea882cb/c60bafa089f89c6b?#c60bafa089f89c6b for me...
Comment 4 Zdenek Kabelac 2008-05-23 14:25:23 UTC
Is this the bugfix - or just the patch hides the real problem ?
I would have assumed that scsi_bus_uevent should not have been called at all for the non-scsi device
Comment 5 Sitsofe Wheeler 2008-05-24 03:26:34 UTC
Many subsystems (like the new PATA/SATA layer and USB block devices) also utilise the SCSI layer.
Comment 6 Sitsofe Wheeler 2008-05-31 12:24:11 UTC
This doesn't happen in the latest -next kernels for me.
Comment 7 Rafael J. Wysocki 2008-05-31 12:28:51 UTC
Does it happen with 2.6.26-rc4-git4?
Comment 8 Zdenek Kabelac 2008-06-02 06:15:33 UTC
I'll had to make more test boots to see if the bug is still present - but I do not have a good testcase where I could easily replicate the bug - it happens randomly during the boot - I think no patch solving this issue was committed to the mainline so far ?
Comment 9 Rafael J. Wysocki 2008-06-16 08:41:03 UTC
On Monday, 16 of June 2008, Zdenek Kabelac wrote:
> Hi
> 
> I've not see this bug over quite a few recent reboots - so I'd would
> have considered this bug also fixed for  me - if the problem reapers
> I'll reopen this bug.
> 
> (Well if there was no commit fixing this bug directly - it's hard to
> be sure the bug is fixed)
> 
> Zdenek

Comment 10 Sitsofe Wheeler 2008-06-16 14:49:31 UTC
There WAS a commit fixing this bug directly - it was carried in the SCSI fixes tree and was commit [1f42ea7bc0ddfadebd9e1c5362b41b53902dbcb1] and started turned up first in the next-20080526 tree and was committed to v2.6.26-rc5 (if gitk is right).

Note You need to log in before you can comment on or make changes to this bug.