Description of problem: Some 2GB SD cards/SD card readers combination are unusable past the 1GB limit. Version-Release number of selected component (if applicable): kernel-2.6.25.11-60.fc8 kernel-xen-2.6.21.7-3.fc8 How reproducible: Always with 2GB SD card. No problem with 256MB SD card Steps to Reproduce: 1. Plug the TrueWin/Neodio 7-in-1 USB card reader 2. Plug the 2GB SD card 3. Watch the error message Actual results: lspci -v Bus 002 Device 003: ID 0aec:3260 Neodio Technologies Corp. 7-in-1 Card Reader Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0aec Neodio Technologies Corp. idProduct 0x3260 7-in-1 Card Reader bcdDevice 1.00 iManufacturer 1 Generic iProduct 2 USB Storage Device iSerial 3 2004060411145504 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 MaxPower 98mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk (Zip) iInterface 0 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 ... SD card tested: - SD SanDisk Ultra II 2.0GB cat /sys/block/sdf/size 1985024 - SD Polaroid 2.0GB cat /sys/block/sdf/size 1966080 dmesg|tail sdf: rw=0, want=3932149, limit=1966080 attempt to access beyond end of device sdf: rw=0, want=3932150, limit=1966080 attempt to access beyond end of device sdf: rw=0, want=3932151, limit=1966080 attempt to access beyond end of device sdf: rw=0, want=3932160, limit=1966080 attempt to access beyond end of device sdf: rw=0, want=3932160, limit=1966080 SELinux: initialized (dev sdf1, type vfat), uses genfs_contexts The files past the middle of the device can't be read under Linux. Expected results: To be able to access data after the ~1Go limit Additional info: All files from these SD cards using this card reader can be read under Windows 2000 SP4.
Please attach a complete dmesg.
Created attachment 312783 [details] dmesg output
I see this: sd 8:0:0:2: [sdf] 1985024 512-byte hardware sectors (1016 MB) sd 8:0:0:2: [sdf] Write Protect is off sdf: sdf1 sdf: p1 exceeds device capacity Now, what to do? There's nothing we can do right away if the device lies about the capacity of its media. It may be possible to initiate a serious discussion on linux-scsi & linux-kernel about it.
I agree the line "sd 8:0:0:2: [sdf] 1985024 512-byte hardware sectors (1016 MB)" is wrong. Because device capacity as reported by the kernel is too small, the partition using the "whole" sd card exceeds the device capacity. It may be a bug in the card reader for which Windows 2000 driver has a work around.
Yes, this is a bug in the cardreader, somehow this discussion sounds really familiar, probably because this issue has been discussed many times before. The problem is that some cardreaders do not work well with cards > 1GB \, they return a wrong capacity, but strange enough do accept read and write commands for sectors beyond the reported capacity. Windows seems to look at the partition table and believe that when a valid table is found no matter what what the device says. An interesting (and dangerours) experiment would be to under linux do: dd if=/dev/sdf of=card-bootsect.bak bs=512 count=1 Backing uo the bootsector (which also contains the partition table). And then do: dd if=/dev/zero of=/dev/sdf bs=512 count=1 Clearing the partition table and then feed the card to windows using the problems giving cardreader. Chances are windows will now too see only 1GB, proving that windows is letting the partition table reported size prevail over the hardware reported size. Once we know for sure this is really happening we can try to make plans howto cope with this under Linux. Once you've done the experiment you can get the additional 1GB back either by using a non broken cardreader or by restoring your bootsector backup.
It's pretty much as Hans said above. They key is, Windows uses the data on the media for the size, not what the device says about the media. We (in Linux) keep addressing this by adding little flags for off-by-one sizes. But in this case, more is needed. I just don't know what. I thought about writing a tool that reads partition and force-sets the device size through sysfs. It would at least get Christophe on the road if not fixing the issue completely.
(In reply to comment #6) > It's pretty much as Hans said above. They key is, Windows uses the data > on the media for the size, not what the device says about the media. > We (in Linux) keep addressing this by adding little flags for off-by-one > sizes. But in this case, more is needed. I just don't know what. > I thought about writing a tool that reads partition and force-sets > the device size through sysfs. It would at least get Christophe on > the road if not fixing the issue completely. > I was thinking about the same line, create a blacklist of devices which are known to misreport the size for large cards, together with a userspace tool which after a number of sanity checks forces the size as een by the kernel to that as reported by the partition table, this tool + list would then become a part of hal in my vision of howto fix this, or rather howto work around the broken hardware. <offtopic / rant> A better way might be to tell all people with such readers to return it to the store preferably when the store is full of customers and to complain loudly about the garbage the store is selling while returning the item. I can even see a kernel warning being printed advising users to do this when a broken reader gets inserted.</rant>
Hans, you are right: after deleting the partition table, Windows is reporting only 1GB as Linux does ! Is it possible to have a module parameter so "/sys/block/sdf/size" created by usb_storage becomes writable ? This way it will be possible to get an estimated media size from its partition table and overwrites the media size.
(In reply to comment #8) > Hans, you are right: after deleting the partition table, Windows is reporting > only 1GB as Linux does ! > Usually I'm happy when I see a sentence starting with: "Hans, you are right" but in this case its kinda sad, as that means the hardware probably really is broken and we will need to kludge around it. Have you tried complaining about this to the cardreader manufacturer, who knows it might lead to them fixing this in their next generation. Don't mention Linux just say it doesn't work with unformated cards :) > Is it possible to have a module parameter so "/sys/block/sdf/size" created by > usb_storage becomes writable ? This way it will be possible to get an estimated > media size from its partition table and overwrites the media size. > I'll leave answering this to Pete Zaitcev who is much more familiar with this then I am.
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. 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 '8'. 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 8'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 8 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 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 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.