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): kernel-2.6.22.4-65.fc7 How reproducible: Not sure. This is not mine machine; but a communication with a scanner is "weird".
Created attachment 174321 [details] oops trace for 2.6.22.4-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 (matthias).
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.
Hello, I'm reviewing this bug as part of the kernel bug triage project, an attempt to isolate current bugs in the fedora kernel. http://fedoraproject.org/wiki/KernelBugTriage 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. Cheers Chris
> 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 2.6.22.4-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.
Hello, (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 as in: # 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. Cheers Chris
Hello Michal, 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.