Red Hat Bugzilla – Bug 867068
kernel 3.6.1-1 breaks Epson V500 USB scanner initialization
Last modified: 2012-11-15 21:03:37 EST
Description of problem: kernel 3.6.1-1 fails to communicate with Epson V500 USB 2.0 scanner when scanner is powered up after boot. No problems when prior kernel used. Version-Release number of selected component (if applicable): Failure occurs with kernel 3.6.1-1, works normally with kernel 3.5.4-2. How reproducible: 100% failure if scanner is powered up while running on 3.6.1-1. If scanner power-up occurs on kernel 3.5.4-2 and get scanner initialized, leave scanner powered up across boot of 3.6.1-1, then application (Win2K virtual machine under VirtualBox has no problem seeing and driving scanner. Some initial power-up handshake with the device appears to be broken. Steps to Reproduce: 1. Boot kernel 3.6.1-1, and logon as user when ready 2. Power up Epson V500 Scanner 3. Bring up virtual system under VirtualBox that works with the scanner, at which point get flashing error indicator on scanner indicating failure in the USB communications link to PC (other possible interpretations are eliminated by fact that scanner with no physical changes works when Fedora is booted with different kernel) Actual results: At power up of scanner with kernel 3.6.1-1 get in message log: Oct 16 11:32:18 ins530 kernel: [ 1701.790038] usb 1-4: new high-speed USB device number 6 using ehci_hcd Oct 16 11:32:18 ins530 kernel: [ 1701.906719] usb 1-4: New USB device found, idVendor=04b8, idProduct=0130 Oct 16 11:32:18 ins530 kernel: [ 1701.906726] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Oct 16 11:32:18 ins530 kernel: [ 1701.906731] usb 1-4: Product: EPSON Scanner Oct 16 11:32:18 ins530 kernel: [ 1701.906735] usb 1-4: Manufacturer: EPSON When bringing up a Win2K system with scanner attached under VirtualBox (V4.1.22), when Win2K attempts to initialize the scanner connection and the scanner error indication occurs, get one additional log message: Oct 16 11:35:30 ins530 kernel: [ 1893.531035] usb 1-4: reset high-speed USB device number 6 using ehci_hcd Expected results: With the functional 3.5.4-2 kernel, at the point the 3.6.1-1 failure occurs during the virtual system initialization the scanner normally goes through an audible (self test?) sequence that lasts 5 seconds or more before becoming "ready". Additional info: I notice that after booting kernel 3.6.1-1 neither Simple Scan nor GIMP seems to be able to see the V500 scanner. I know I have used GIMP directly with the scanner in the past, but I'm not sure I have done so since going to f17, so this may or may not be a related symptom.
See if you can get things working with the machine directly, and open a bug if not, but if 3.6 broke Virtual Box passthrough, you will have to get support from them to fix that. We cannot do anything with it.
Tried installing several additional different packages on f17: From Fedora: iscan-firmware-2.26.4 From Epson: iscan-2.29.1-5.usb0.ltd7.x86_64.rpm iscan-data-1.18.0-1.noarch.rpm iscan-plugin-gt-x770-2.1.2-1.x86_64.rpm Not sure which resolved most of problem, but for sure the last plugin-gt pkg was needed. Now both SimpleScan and Epson Imagescan recognize and properly initialize Epson V500 scanner after scanner power-up with both 3.5.4-2 kernel and 3.6.1-1 kernel. Once scanner has been initialized, can start Win2K virtual machine under VirtualBox 4.1.22 and successfully use the scanner; but if scanner has not yet been initialized after scanner power-on and virtual machine is started, then with kernel 3.6.1-1 the scanner fails and is unable to initialize from the virtual machine. It appears that kernel 3.6.1-1 introduced some incompatibility with VirtualBox 4.1.22 that is adversely affecting USB support in this case.
Just as a follow-up, this issue appears to have been fixed with kernel 3.6.6-1 install, which strongly suggests the problem was with the kernel and not VirtualBox. Hopefully someone has some idea what questionable thing was done with USB support in 3.6.1-1 that was fixed by 3.6.6-1 so it doesn't get unfixed again. I updated to VirtualBox 4.2.4 at the same time as the latest kernel, but under VirtualBox 4.2.4 my Win2K virtual machine still sees the failure with kernel 3.6.1-1, and does not see any failure with kernel 3.6.6-1, which I would take to indicate the fix was not part of VirtualBox 4.2.4 but part of the kernel. Also the problem was more subtle than previously thought: even when the the scanner appeared to be functioning under VirtualBox after initialization outside VirtualBox with kernel 3.6.1-1, there was some subtle data corruption occurring in the USB image data from the scanner.