Red Hat Bugzilla – Bug 257981
kernel 126.96.36.199-65.fc7 oopses in module_put+0xf/0x27
Last modified: 2008-01-13 13:40:58 EST
Description of problem:
Turning on an USB scanner (Epson Perfection 3490 with an USB id
04b8:0122, 'snapscan' sane driver) resulted in "BUG: unable to
handle kernel paging request at virtual address 70646fe5" apparently
on an attempt to access sysfs.
After that the system is still operational and even scanner works
although from time to time is annouces that it has to "warm-up"
and it will be gone for 18 seconds. Resulting "access gaps" are
actually shorter. That was not the issue in the past.
lsusb shows now:
Bus 002 Device 002: ID 058f:9254 Alcor Micro Corp. Hub
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 005: ID 3538:0042 Power Quotient International Co., Ltd Cool
Drive U339 Flash Disk
Bus 001 Device 003: ID 0424:2504 Standard Microsystems Corp.
Bus 001 Device 002: ID 04b8:0122 Seiko Epson Corp.
Bus 001 Device 001: ID 0000:0000
Version-Release number of selected component (if applicable):
Not sure. This is not mine machine; but a communication with
a scanner is "weird".
Created attachment 174321 [details]
oops trace for 188.8.131.52-65.fc7 (i686)
Maybe a silly question, but... why have you assigned this bug to me?
> why have you assigned this bug to me?
I did not. That is a bugzilla doing after I picked up a "kernel"
component. I was scratching my head when I have seen this but
do I even have an option to pick up asignee? Let's see ...
I filed this bug yesterday (an oops on likely sysfs access from USB)
and for some really unclear reasons bugzilla originally assigned this
bug to Matthias Saou (email@example.com).
This is fixed in 2.6.23, but it took a rewrite of that whole area to do it. It's
not really possible to backport that.
I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.
I'm setting this as NEEDINFO as Chuck has indicated this problem may be resolved
in the 2.6.23 kernel - could you test with that either from rawhide or on
release and if the problem no longer exists then please close this bug as
CURRENTRELEASE indicating what resolved it for you.
> I'm setting this as NEEDINFO as Chuck has indicated this problem
> may be resolved in the 2.6.23 kernel
There is no released 2.6.23 kernel for F7. There is not even
such candidate in koji.
> could you test with that either from rawhide or on release
As I wrote in the original report - "This is not mine machine"!!!
I have to tread there very lightly. At this moment I can only
tell for sure that the problem was showing up consistenly but
I do not see any record of this happening later than September 10th
and 184.108.40.206-65.fc7 kernel. That may depend on patterns of
a scanner usage over which I have a zilch control.
Comment #5 from Chuck indicates that one should not expect
a definite resolution before 2.6.23. Oopses are recorded but
to my knowledge this still works.
(In reply to comment #7)
> > I'm setting this as NEEDINFO as Chuck has indicated this problem
> > may be resolved in the 2.6.23 kernel
> There is no released 2.6.23 kernel for F7. There is not even
> such candidate in koji.
which is why I said:
> > could you test with that either from rawhide or on release
# yum update kernel --enablerepo=development
however as you said:
> As I wrote in the original report - "This is not mine machine"!!!
though I was not aware from that that you had little or no control over the
machine in question. I'll wait for you to test with a 2.6.23 kernel.
I am closing this CURRENTRELEASE as one of the kernel team have indicated this
was resolved in 2.6.23 and there has been no update since release. If this is
incorrect and the problem still occurs for you please do not hesitate to re-open
this bug. Thank you for filing.