From [EMAIL PROTECTED] Sun Dec 7 16:04:37 2003
From: Eduard Hasenleithner <[EMAIL PROTECTED]>
The lun detection relies (maybe non-intentional) on the fact that a CF
card is inserted. If no CF is inserted no LUN is detected.
Please find attached only the commands which were issued when doing
"modprobe sd-mod" with usb-storage already loaded. First I thought the
"insmod" whill never return, but after 25 minutes (!) insmod was ready.
Yes.
On the one hand, I have never seen SCSI error recovery do something useful.
On the other hand, in this case, it is mostly our fault.
If we return errors with the meaning "don't retry, that is meaningless"
that would stop the SCSI layer from doing its nonsense.
I tried your suggestion - insmod without CF card inserted and found
that it took 13 minutes in my case. Then polished the error returns
a bit and got it down to 2 seconds instead.
Now you want to see the improved code, but just a moment ago my
ethernet hub broke down - never had that happen before - so my
development machine is out of reach for the moment.
The changes are easy to describe.
In the routine *determine_lun() there are three possible results:
*GOOD / *FAILED / *ERROR. The two cases where a lun is discovered
were and remain *GOOD. The cases where we cannot send a command
at all (the write fails) were and remain *ERROR.
The remaining cases (we do not try because of beenhere, or we try
but do not find a lun) return *FAILED.
When FAILED is returned, the sense code for Unit Attention, No Media is set.
Clear the beenhere when we return *FAILED after trying in vain,
so that we can try later.
(In fact I made beenhere the condition info->lun == -2,
and changed all tests elsewhere from "if (info->lun == -1)"
to "if (info->lun < 0)".)
The result of this change was the following:
After a fresh reboot, insmod with CF card already inserted works.
Also, insmod without CF card inserted works (after two-second delay),
and if the card is inserted later, a "blockdev --rereadpt" causes the
lun to be determined later, and again access is fine.
So, all is well so far.
However, rmmod followed by a second insmod does not work here.
Was just wondering what initialization insmod usb-storage did
to disturb the peace of this device when this hub broke.
Andries
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
