On Wed, Jan 02, 2002 at 06:42:38PM -0500, Michael H. Warfield wrote: > Hello all, > > The reader that I have is not immediately recognized. It has > vendor code 0x07c4 and product code 0xa109. As a first order experiment, > I "cloned" the 0x07c4:0xa005 PNY/Datafab entry in unusual_devs.h. > This seem to be productive and do the right thing with some "side effects" > which may or may not be peculiar to this particular product ID. There > seem to be problems in that code which simply should NOT work. The > CF reader seems to work but the SmartMedia slot does not. That is > even mentioned in some of the archives and some other things I've read > on the net. I think I know part of why not, now.
I submitted a patch to the kernel list a few days ago which added a109 to unusual_devs.h after I decided that those people with working a109's outnumbered those who still have non-working a109's. Also it contains a first attempt at handling media removal/insertion. I have not yet sent the patch to the CVS repository yet, however. > > The other thing I noticed (and that someone reported months ago > as a rare random anomoly) is that I got TWO SCSI drives that mapped to > the same slot (the CF Slot). Amusing and somewhat disturbing... > > Trying to debug some of this I noticed some interesting remarks > in reading datafab.c about the slots and the LUN. Ok... The max lun > for this transport gets set to 1, which should be good for a two slot > reader. For shits and giggles, I bumped it to two and I then had THREE > drives mapped to the same slot! Hmmm... Clue alert... Some of these Datafab chipsets (like yours) appear to report multiple endpoints when queried by the lower level USB routines. Whether or not these endpoints correspond to the physical slots is an open question. I haven't received any information from these companies explaining the nuances of their chipsets. So my assumption the the LUN (bit 4, byte 5 of most ATA commands) corresponds to the slot number might be entirely wrong. It's possible that each reported endpoint merely offers a different way to access the media (maybe one offering standard block/sector access, another offering some form of LBA access, etc). The fact that your device seems to be reporting 3 or more seems to suggest they might not map to the slots. > > I added some additional debugging to the datafab.c code and > discovered that while datafab_transport is being called with srb->lun > set to 0 or 1 as appropriate, the code in datafab_read_data uses a > DIFFERENT lun (the one out of the "extra" private info blob) and that > LUN never gets mapped to the LUN of the calling srb. > > Well... That explains the multiple devices mapped to the same slot. > The USB storage code is calling that transport with srb->lun set to zero, > then one, but the read code only ever sends requests to info->lun == 0. > So, of course, both lun's look the same from the higher levels and the > second physical slot can never actually be accessed. Which then also > explains why the second slot, the Smart Media slot, doesn't stand a > snowball's chance in hell. Okay. This is possibly a bug in the driver. Let me know how things work out. The current LUN determination code was a hack that I wrote to help someone get their reader working. It basically assumes that the first LUN that responds to the IDENTIFY_DEVICE query is the LUN that we should be using. This is actually how the Windows driver appears to work...you can watch it repeatedly trying LUN 0 and 1 until one responds without an error. It then uses that LUN for operations. I had not thought to use the srb->lun value to set the LUN bit of the command. In the case of your device reporting 3 or more endpoints, I'm not sure how to treat the 3rd LUN. ATA only allows for a single bit to specify the device. This is why I'm not convinced that the endpoints map directly to slots. > Simply setting info->lun = srb->lun in datafab_transport seems > to do extremely vicious ugly things (like cause fdisk to hang as soon > as I touch the device and it can't be killed - have to reboot the box) > so I guess that's not the answer either. The fdisk hanging trick is > similar to what happens when I have the reader plugged in with no cards > and try and run fdisk. Definitely a no-no. That's something ELSE > that needs some debugging. There are a couple things that could be causing the hang. First, SmartMedia and CompactFlash are generally accessed using very different protocols (even using dual-slot readers judging from the Windows logs people have sent me). The only exception seems to be a006-based readers which for one reason or another (chipset is translating between ATA and SM on the fly?) seems to work with this driver. Trying to send an ATA command to a SM device that's not expecting it might do all sorts of nasty things. Second, datafab_determine_lun() has a hard-coded delay of 20ms per loop iteration (with a maximum of 10 iterations or 200ms delay total) instead of a wait_queue. This is a somewhat arbitrary value. I tried to keep it small so as to not interfere with IRQ handling but yet allow the device time to reset and/or whatever else it does before it responds with a non-error. Possible this delay is interfering with your system? I just tried fdisk with no media present using my reader and the kernel remained happy. There was a few second delay but eventually complained that it was unable to open the device. As it should. This, in fact, was a problem up until the recent patch because when the SCSI layer initially issues a READ_CAPACITY command, the driver would return an error and the SCSI layer would invalidate the device. The problem was without the START_STOP stuff, there was no way to inform the SCSI layer that a media change or insertion had taken place. The net effect was that you'd have to reload the driver to be able to access the device. > Finally, if I remove the CF card and the reinstall the same card, > fdisk comes back with bogus numbers to the first time (and the debug > prints indicate errors in the USB subsystems) and I have to quit it > and reenter it. Second time in, the numbers are correct. Same thing > if I try using mount. Remove a card and reinstall it and the mount fails > the first time and works the second time. The debugging messages indicate > that a command ALLOW_MEDIUM_REMOVAL is being issued but I see absolutely > no indication of a medial removal or insertion event taking place. I don't > know how that is suppose to work, but it's obvious that the usb-storage > and SCSI subsystems have no clue that the media was changed and are not > handling the resulting error cleanly. The latest patch should take care of this. Basically the driver needs to handle START_STOP messages coming from the SCSI layer. Jimmie -- Jimmie Mayfield http://www.sackheads.org/mayfield email: [EMAIL PROTECTED] My mail provider does not welcome UCE -- http://www.sackheads.org/uce _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
