Description of problem: the card reader included on my laptop start to fail with Fedora 12, when i change the memory this fails and stop to work until i restart my machine, suspend or hibernate, this works very well on Fedora 11, i remove the memory and the device who appear on terminal, like Realtek disappear from lsusb. Version-Release number of selected component (if applicable): Linux gateway 2.6.31.9-174.fc12.i686.PAE #1 SMP Mon Dec 21 06:04:56 UTC 2009 i686 athlon i386 GNU/Linux How reproducible: always happen Steps to Reproduce: 1.remove memory card 2.put another or the same, nothing happen, because the device disappear from lsusb 3. Actual results: Bus 002 Device 003: ID 0bda:0159 Realtek Semiconductor Corp. [maximi89@gateway Cifrados]$ sudo lsusb -vvd 0bda:0159 [sudo] password for maximi89: Bus 002 Device 003: ID 0bda:0159 Realtek Semiconductor Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0bda Realtek Semiconductor Corp. idProduct 0x0159 bcdDevice 58.88 iManufacturer 1 Generic iProduct 2 USB2.0-CRW iSerial 3 20071114173400000 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 CARD READER bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk (Zip) iInterface 5 Bulk-In, Bulk-Out, Interface Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0000 (Bus Powered) Expected results: Additional info:
Please attach the complete output of dmesg (but do not drop it into the comments box, attach as an uncompressed file).
Created attachment 382868 [details] /var/log/messages what i get when i remove the memory is: Jan 10 17:00:24 localhost kernel: usb 2-6: USB disconnect, address 3 Jan 10 17:00:24 localhost kernel: FAT: bread failed in fat_clusters_flush Jan 10 17:00:24 localhost kernel: FAT: bread failed in fat_clusters_flush Jan 10 17:00:24 localhost kernel: FAT: bread failed in fat_clusters_flush Jan 10 17:00:24 localhost kernel: FAT: bread failed in fat_clusters_flush Jan 10 17:00:25 localhost gnome-keyring-daemon[1639]: removing removable location: /media/FC30-3DA9 Jan 10 17:00:25 localhost gnome-keyring-daemon[1639]: no volume registered at: /media/FC30-3DA9
The messages fail does not necesserily retain all kernel messages, which is why I asked for output of dmesg, not /var/log/messages. Still, this looks like a sudden disconnect. Let's go to the next step and obtain the usbmon trace. Plese do the following: - yum install usbmon - start usbmon with usbmon > run1.mon - insert the first card - remove card at this point the disconnect should be registered, please verify with dmesg | tail - if disconnect occured, interrupt usbmon and upload run1.mon
[maximi89@gateway ~]$ lsusb Bus 002 Device 002: ID 064e:a103 Suyin Corp. Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub [maximi89@gateway ~]$ lsusb Bus 002 Device 004: ID 0bda:0159 Realtek Semiconductor Corp. Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub how you can see, the first lsusb show me the Realtek doesn't exist, then i put the memory in the card reader, and then i suspend, so i resume, and the Realtek card reader appear... now i run usbmon > usb1.mon and i remove the memory, dmesg|tail show me when i remove the memory the Webcam start to work... if you check the first time the webcam was working, then the webcam disappear when i suspend... and the card reader start to work. This is what show dmesg|tail [maximi89@gateway ~]$ dmesg|tail usb 2-5: configuration #1 chosen from 1 choice uvcvideo: Found UVC 1.00 device Video WebCam (064e:a103) uvcvideo: Forcing device quirks 0x2 by module parameter for testing purpose. uvcvideo: Please report required quirks to the linux-uvc-devel mailing list. input: Video WebCam as /devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/input/input12 usb 2-6: USB disconnect, address 4 FAT: bread failed in fat_clusters_flush FAT: bread failed in fat_clusters_flush FAT: bread failed in fat_clusters_flush FAT: bread failed in fat_clusters_flush
Created attachment 382880 [details] usbmon log
well, seems to be failing when i connect the memory of my handycam video.. i going to attach you others usbmon logs
well, the webcam seems to be a normal delay of 5 to 10 seconds and it start to work, about the card reader, seems to be failing when i connect the memory of my handycam video.. i going to attach you others usbmon logs
i have made the test starting the system with the memory of the handycam video recorder, so, the memory works greats, and the card reader seems to be reading only when you start the system with the memory inside the card reader... i'm impossible to change the type of memory, when i start the system using SD memory, i can remove and put the memory the times i want, but if i change the memory from SD to SDHC the card reader break himself and fail, i have test puting SDHC and change to SD or SD and change to SDHC, both brokes the system... i guess this bug only fail when you change the memory type.
Created attachment 382891 [details] usbmon log this log is when i remove the memory SDHC and i put the SD memory, i hope this help.
Thanks, these are correct logs, although it is difficult to corellate them with the disconnect since there's no reconnect. It may be the card type confuses the firmware, but usually the reader reboots itself and proceeds. Is this an internal reader (so you cannot unplug it)?
impossible, i have an internal card reader, my laptop is the "Gateway NV5214u"
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.