Re: USB Mass Storage problems/5.0
From: KM (konstmor_at_nospam_yahoo.com)
Date: 10/14/04
- Next message: Steve B: "Kernel Tracker Thread Migrate???"
- Previous message: Robert Magyar: "RE: USB Transimssion is slow"
- In reply to: Thats me: "Re: USB Mass Storage problems/5.0"
- Next in thread: KM: "Re: USB Mass Storage problems/5.0"
- Reply: KM: "Re: USB Mass Storage problems/5.0"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 14 Oct 2004 10:30:45 -0700
Peter,
Thanks a lot for sharing your results with me and community. I think many people who are going to struggle with the MS USB code will
appreciate your input.
I have tried similar fix a few days ago and it did not work for me. I mean it only partially worked. The reason I have not mentioned
it was that it was a dirty fix and I would not want to go with it in production. This was actually the reason why I started this
thread hoping to get a better answer from MS.
Anyway, here is what I did that time and here is my results.
I have got about 10 keys with different brands. 4 of them do not work. CE does not recognize them and from the debug output I saw
different problems with each of them.
First things I fixed was the Unit Test Ready command that I mentioned in earlier post. That allowed me to get through the Unit Test
command with a pretty good stable solution.
However, then, of course, I saw the Command Block failures (again, we discussed that earlier). So I started commenting out the error
handling code (pretty much the same way you did).
My "line 615" fix was just changing ERROR_GEN_FAILURE to ERROR_SUCCESS. Well.. it helped me to repair only 2 flash keys. Other 2
broken keys still showed various problems.
So, what I've been doing here since that fix - removing the error handling code from various places. I couldn't yet fix other 2
broken keys but your results encourage me to continue on this route.
This will come to much testing after all. Removing the CBW error handling we may unstabilize the USBMSC driver so that some
inconsistencies may appear later.
In case you see them already, please let us know here. The same for me - I will report how the testing goes.
Thanks again.
--
Regards,
KM
> Thanks for all your help.
> I found a sollution for my problem. It was something different from what you
> tried.
> It might work for you aswell.
>
> I always got the message: "Command Block Status: Command Failed"
> I looked in the code to just disable the error return value on this error
> and guess what, it works fine now.
>
>
> These are the steps I took:
> - First take all the original USB\CLASS\Storage driver from microsoft.
> - In the file
> C:\WINCE420\PUBLIC\COMMON\OAK\DRIVERS\USB\CLASS\STORAGE\CLASS\bot.c
> - In the line 615 I commented out the following code:
>
> Line 613: if (1 == Csw.bCSWStatus ) {
> Line 614: DEBUGMSG( ZONE_WARN, (TEXT("[USB_PD]: Command Block
> Status: Command Failed - IGNORE ---\n")));
> Line 615: //*PD*+++* dwErr = ERROR_GEN_FAILURE;
> Line 616: }
>
> when the status is 1, I always return ERROR_SUCCESS, and this works
> fine now.
>
> I don't know if I should do this, maybe I ignore an important error that can
> give strange behaviour later.
> But for now, It looks OK to me.
>
>
> Lets hope this works for you too. Please let me know ;-)
>
> Cheers,
> Peter.
>
>
>
>
> "KM" <konstmor@nospam_yahoo.com> wrote in message
> news:%232RznfYsEHA.2660@TK2MSFTNGP12.phx.gbl...
> > Peter,
> >
> > > Can you tell me where you added this ScsiStartStopUnit() function?
> > > I don't think this would work in my case, since the device is already
> > > restarted in ScsiUnitAttention() every 300ms.
> >
> >
> > Look at the ScsiUnitAttention (scsi2.c). If the ScsiTestUnitReady call's
> failing there, you may want to add the ScsiStartStopUnit
> > call if it is not already there.
> > Another thing to play with - "UnitAttnRepeat" registry value. It defines a
> number of attempts to send Unit Attention command before
> > it decides the device is not responding. (I think by default it is 1). Or
> just increase UNIT_ATTENTION_REPEAT (scsi2.h) and see if
> > it helps you to get through the Test Unit command.
> >
> > > I don't find anything usefull in the debug information, I enabled all
> > > debuging, but the error codes that are set, are not very usefull.
> >
> > Look at \PUBLIC\COMMON\DDK\INC\usbtypes.h. Most of these "undocumented"
> usb errors listed there. At least thier names make some
> > sense.
> >
> > > It is like the USB camera itself does not recognize the commands that
> the driver is sending.
> >
> > The same here.. My impression from the debug log is that my devices
> failing to some SCSI commands. but why? And why this does not
> > happen with XP? Does the XP code has some hardware specific fixes
> (hard-coded)? I don't get it yet.
> >
> > > So where is the problem?
> > > Is the USB camera not compatible with the driver?
> > > Or is it a timing issue ?
> >
> > I played with verious timeouts in the code (SCSI command timeouts, USB
> bulk transfer timeouts - no luck :-(
> >
> > > Are there any developers that have any experience in this?
> >
> > I am also hoping to hear any comment from MS...
> >
> > --
> > Regards,
> > KM
> >
> >
> > > > ....
> > > >
> > > > > Command Block Status: Command Failed
> > > > > ScsiGetSenseData - SenseKey:0x6 ASC:0x28 ASCQ:0x0
> > > > > SENSE_UNIT_ATTENTION : ASC_MEDIA_CHANGED
> > > > > ScsiTestUnitReady ERROR:20
> > > > > ScsiUnitAttention:20
> > > > > Command Block Status: Command Failed
> > > > > ScsiGetSenseData - SenseKey:0x2 ASC:0x3a ASCQ:0x0
> > > > > SENSE_NOT_READY : ASC_MEDIUM_NOT_PRESENT
> > > > > ScsiTestUnitReady ERROR:20
> > > > > ScsiUnitAttention:20
> > > > > Command Block Status: Command Failed
> > > > > ScsiGetSenseData - SenseKey:0x2 ASC:0x3a ASCQ:0x0
> > > > > SENSE_NOT_READY : ASC_MEDIUM_NOT_PRESENT
> > > > > ScsiTestUnitReady ERROR:20
> > > > > ScsiUnitAttention:20
> > > > > Command Block Status: Command Failed
> > > > > ScsiGetSenseData - SenseKey:0x2 ASC:0x3a ASCQ:0x0
> > > > > SENSE_NOT_READY : ASC_MEDIUM_NOT_PRESENT
> > > > > ScsiTestUnitReady ERROR:20
> > > > > ScsiUnitAttention:20
> > > >
> > > > I did see similar debug errors.
> > > > Although, with the Lexar Falsh key I could get through the MODE_SENSE
> > > problems (SENSE_UNIT_ATTENTION : ASC_MEDIA_CHANGED) by
> > > > additional stop and start unit call (ScsiStartStopUnit). Basically
> > > (according to MS note), some devices require a (re)start. It
> > > > helped me to pass the ScsiTestUnitReady and ScsiUnitAttention.
> > > >
> > > > However, then the following error I see:
> > > > IssueBulkTransfer ERROR(5, BytesTransferred:0, Win32Err:31,
> > > UsbError:0x5)
> > > >
> > > >
> > > > > And these errors keep coming...
> > > > > As you can see my device has the same interface as yours (Mass
> Storage
> > > > > Device Class with interfaceSubClass = 6 (SCSI))
> > > > >
> > > > > My guess is that there is NO support in windows CE 4.2 and 5.0 for
> this
> > > SCSI interface.
> > > >
> > > > Yes, there is (on 4.2 and 5.0). Check out
> > > PUBLIC\COMMON\OAK\DRIVERS\USB\CLASS\STORAGE\DISK\SCSI2\disk.c and
> scsi2.c.
> > > Look there for
> > > > USBMSC_SUBCLASS_SCSI.
> > > >
> > > > > With the interfaceSubClass = 2 (= ATAPI) interface I have no
> problems,
> > > the
> > > > > USBDisk6.dll starts the FAT file system driver and my drive appears
> in
> > > > > explorer, but with the SCSI interface I get only errors.
> > > >
> > > > Well... this is why USB CD works fine for me here (ATAPI interface).
> > > >
> > > > > Does any one have a solution for this?
> > > > > Where can we find the SCSI driver for CE 4.2 and 5.0 to support our
> USB
> > > drives?
> > > >
> > > > It is there. And according to the documentation it should be a
> production
> > > quality code. But it is not! :-(
> > > >
> > > > I'd appreciate any MS comment on this issue. Knowing that MS works on
> it
> > > now or it would be only availabl in future release would
> > > > also help.
> > > >
> > > > --
> > > > Thanks,
> > > > KM
> > > >
> > > >
> > > > > >
> > > > > > I am having various issues with a number of USB Flash Key disks
> under
> > > CE
> > > > > 4.2/5.0. Please let me narrow the list down to 5.0 only
> > > > > > here.
> > > > > >
> > > > > > Some device are not recognized by CE USB Mass Storage Driver. I
> know
> > > it is
> > > > > not a firmware problem as the devices work properly on my
> > > > > > XP machine (or, at least, XP has some fixes for such devices which
> CE
> > > does
> > > > > not).
> > > > > > The Usbmsc driver however works properly with some other USB keys.
> > > > > >
> > > > > > I am talking about devices that comply with the USB specification
> > > > > (bInterfaceSubClass=6, bInterfaceProtocol=80).
> > > > > > I turned on debug messages in the USB stack (and particularly in
> the
> > > USB
> > > > > Storage class driver). All of the "bad" devices show
> > > > > > different failures but here is one of them: "Command Block Status:
> > > Command
> > > > > Failed. Error: 0" (as you can imagine, this happens right
> > > > > > after "5.3.3 CSW") (if interested, feel free to request a full
> debug
> > > > > output log from me, I can email it over).
> > > > > >
> > > > > > Just to avoid question on what interface descriptor for those
> devices,
> > > > > here is the debug output:
> > > > > > USB_INTERFACE_DESCRIPTOR[0]:
> > > > > > -------------------------
> > > > > > bLength: 0x9
> > > > > > bDescriptorType: 0x4
> > > > > > bInterfaceNumber: 0x0
> > > > > > bAlternateSetting: 0x0
> > > > > > bNumEndpoints: 0x2
> > > > > > bInterfaceClass: 0x8
> > > > > > bInterfaceSubClass: 0x6
> > > > > > bInterfaceProtocol: 0x50
> > > > > > iInterface: 0x0
> > > > > >
> > > > > > Basically what happens when I plug-in one of the "bad" devices it
> that
> > > > > after some recognition process and failures on Command Block
> > > > > > transfer for a few tries, it ends up by disk access error
> ("DSK_Open:
> > > > > ERROR_ACCESS_DENIED") and then removing the device
> > > > > > ("USBMSC<RemoveDeviceContext").
> > > > > >
> > > > > > The fact that all the USB keys I am playing with here (e.g., Lexar
> > > Media
> > > > > 256M Jumpdrive) are not "new" devices and have been on the
> > > > > > market for a while, tells me that it is most likely a CE problem
> > > rather
> > > > > than particular hardware failures. And again, the keys work
> > > > > > perfectly with XP.
> > > > > >
> > > > > > I am really wondering why CE 5.0 USB MSC driver is under
> > > > > Production-Quality group of drivers then?
> > > > > >
> > > > > > So, my question would be:
> > > > > > 1) Has anyone seen similar USB Mass Storage Driver problems
> > > recognizing
> > > > > some brands?
> > > > > >
> > > > > > 2) Any ideas on where me better start exploring the USB stack
> code?
> > > What
> > > > > to look for?
> > > > > > Maybe it is the protocol implementation issues or etc.? Do I
> need
> > > to
> > > > > trace all the commands being sent to the failed device?
> > > > > >
> > > > > > 3) Sometimes I see that Lexar, for instance, fails to pass the
> TEST
> > > UNIT
> > > > > READY USB command. Has anybody seen this sort of problems?
> > > > > > I could fix it by restarting (stop and start again) the device
> within
> > > the
> > > > > ScsiUnitAttention function and then send the command
> > > > > > second time. Then the firmware returned a successful code.
> > > > > >
> > > > > > 4) On the Lexar 256MB key hot plug-in, right after the TEST UNIT
> > > READY is
> > > > > done, the GetTransferStatus starts failing with UsbError
> > > > > > code 0x5. (Did I mention this is all undocumented? :-( ). The
> error
> > > code
> > > > > from a system header file matches to
> > > > > > USB_DEVICE_NOT_RESPONDING_ERROR, which does not say much to me.
> Does
> > > > > anybody know what this error means?
> > > > > >
> > > > > > 5) If I use Lexar 128Mb, I am getting USB_STALL_ERROR (0x4) error
> code
> > > > > there but it finally gets through with some cleaning USB
> > > > > > command procedure (my guess was it was one of the fixes in 5.0).
> > > > > >
> > > > > > Just to mention.. The USB debug output is huge and hard to follow.
> I
> > > am
> > > > > not good with USB drivers' implementation and don't know yet
> > > > > > where the best to start. I'd appreciate it very much for pointing
> out
> > > a
> > > > > good debug or workaround directions.
> > > > > >
> > > > > > Thank you in advance for any valuable input.
> > > > > >
> > > > > > --
> > > > > > Regards,
> > > > > > KM
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
- Next message: Steve B: "Kernel Tracker Thread Migrate???"
- Previous message: Robert Magyar: "RE: USB Transimssion is slow"
- In reply to: Thats me: "Re: USB Mass Storage problems/5.0"
- Next in thread: KM: "Re: USB Mass Storage problems/5.0"
- Reply: KM: "Re: USB Mass Storage problems/5.0"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
