Bug 6081
Summary: | Pendrive (Pentadrive 256MB) not working | ||
---|---|---|---|
Product: | Drivers | Reporter: | nissarin |
Component: | USB | Assignee: | Matthew Dharm (mdharm-usb) |
Status: | REJECTED WILL_NOT_FIX | ||
Severity: | normal | CC: | greg, stern |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.x | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Bug Depends on: | |||
Bug Blocks: | 5089 | ||
Attachments: |
debug log
messages... kernel debug log manual kernel debug log (the right one...) Device information (Advanced USB Port Monitor @ Win2K SP4) Log in xml format Binary... yet another log... /proc/kmsg; device plugged in - waiting 10 sec.. - unplugged unusual_devs entry for the Pentadrive kmsg.log |
Description
nissarin
2006-02-15 14:18:17 UTC
Can you compile with CONFIG_USB_STORAGE_VERBOSE_DEBUG turned on and send those logs? Created attachment 7361 [details]
debug log
Created attachment 7362 [details]
messages...
You need to configure syslogd to send kern.debug messages to a specific file. The USB storage debug messages are lost otherwise. In /etc/syslog.conf, add kern.=debug /var/log/kernel That will put the debug messages into the file /var/log/kernel. Also, is this device supposed to report 2 LUNs? One about 512MB and the other about 2MB... Created attachment 7370 [details]
kernel debug log
Compiled with CONFIG_USB_DEBUG & CONFIG_USB_STORAGE_DEBUG
(CONFIG_USB_STORAGE_VERBOSE_DEBUG is not recognized).
Created attachment 7371 [details] manual Here is one of manuals shipped with pendrive (http://pentagram.pl/produkty_new/szczegoly.php?id_grupy=31&grupa=pentagram_pendrive&id_produktu=7&lang=en), descibing using one of it's features (which actualy could cause this problems), this model has also other functions and their manuals says that to work they need "Phison's hardware solutions" so this is probably real manufacturer of this product. About those LUNs - probably yes (unfortunatelly I'm not familar with SCSI 'terminology"), there should be 2 "disks", from what I know - first one is "protected", second is "public" (whole device size is splitted between those two in specified ratio). Also, I tried today (one my cousin's PC running WinXP) remove that protected partition but it's minimal size is 1MB. Good news (or bad ;)) is that Win2k have similar problems - I can't access it if I plug in when os is running but if I insert it before system starts, I can access first device ("protected" one) - read-only. However it was fresh Win2k install (on my old PC), maybe SP3/4 would fix it. If you wish I will send you program which is described in attachment. @Pete Zaitcev I didn't checked ub so far. I'm still not seeing the right debug messages in your log. Are you sure you rebuild and reloaded the new version of the module? If the device is having problems under Windows, then I am suspicious that the device is bad. I definately would like to know if SP3/4 fixes that. Based on what I can see, the device is, actually, reporting that it's read-only. It's not a communication error; the device is responding correctly but with an indication that it is read-only. The verbose debug log will be truly telling. Created attachment 7374 [details]
kernel debug log (the right one...)
Sorry for that.. I have small mess here
PS:
Installed SP4, both drives visible and accessible (rw).
Matt, any thoughts? This is definately strange. The fact that SP3/4 fixes things makes me believe that the device is, simply, reporting bogus information when asked for write-protect status. I'm guessing SP3/4 just ignores the request. It might be useful to get Alan Stern involved with this -- get the file-storage-gadget attached to an SP1 and SP4 system and look for a command behavior difference. We may need to change our detection code yet again to try to be compatible with the "popular" OS. But, the command/data/status transport over USB mechnism itself isn't reporting any errors. So quite a lot is working... Maybe the thing to do is to try a USB sniffer program under Windows. Perhaps some funny command has to get sent to "unlock" the device. Created attachment 7548 [details] Device information (Advanced USB Port Monitor @ Win2K SP4) Here is link to program I have used (30 days trial): http://www.shareup.com/Advanced_USB_Port_Monitor-download-45032.html I'll post below log file in xml format and binary. Small info about my 'tests' - I just opened 'wainting' monitor window, set program to log all traffic and replug device (by using one of program options). I hope it will help you. Created attachment 7549 [details]
Log in xml format
Created attachment 7550 [details]
Binary...
I didn't notice anything of interest in the AUSB log. On the other hand, it doesn't show you trying to write anything to the drive; the only I/O commands in the log are reads. On the third hand, it does show that device is reporting that it isn't write-protected. Of course, your Linux debugging logs also showed the device wasn't write-protected when you first plugged it in. It didn't become write-protected until later, perhaps when you restarted the USB subsystem. What you should do is a fresh test. Plug in the drive, let the errors occur, and don't restart anything. Then post the output from the dmesg command instead of the contents of the system logfile. Created attachment 7558 [details]
yet another log...
Everything like before but this time I created new file on device and write
something to it.
About 'fresh test' - I did that at first but usb monitor didn't (auto)start, so
I replugged device using program and this time monitor start working. I tried
also monitoring external usb hub, in hope that it will show all traffic but
that program show only one specified device (which must be connected). Maybe
you know some better program ?
I meant that you should do a fresh test under Linux. Created attachment 7559 [details]
/proc/kmsg; device plugged in - waiting 10 sec.. - unplugged
Created attachment 7561 [details]
unusual_devs entry for the Pentadrive
It's possible that this patch will help. It will stop Linux from issuing a
"Prevent Medium Removal" command, which I don't recall seeing in the Windows
log.
By the way, are you sure that the device's password is disabled?
I applied that patch to 2.6.16-rc5 but unfortunatelly it didn't help. And yes - password protection is disabled, however afaik when password is set, then protected drive is reported as removed and public one is accessible (on windows). On linux, after inserting device second drive is accessible - I can see sdb, sdc and sdc1 (looks like password protection on ?) but restarting hotplug allow me to mount both drives (now there is also sdb1). Is it possible to force that device to be rw (using unusual devs table) ? The problem here isn't just that the device reports itself as write-protected. In fact, it doesn't report itself as write-protected at first. The problem is that it responds to READ commands with an error (Medium Error: Unrecovered read error). You'll see those errors if you read through your log in comment #18. But then when you restart the USB system, the device obeys READ commands and does say that it is write-protected. I don't know why it changes its behavior or what Windows does differently. I'll have to go through your sniffer log more thoroughly to try and find out; at the moment I remember only that those Medium Errors did not occur. You can force Linux to skip the write-protect determination step by modifying the patch I sent. Where it says US_FL_NOT_LOCKABLE, change it to US_FL_NOT_LOCKABLE | US_FL_NO_WP_DETECT ), Looking again at your sniffer log, I see these differences between Windows and Linux: Windows sends a Set-Interface request for altsetting 0 and Linux doesn't. I doubt this makes any difference because 0 is the only altsetting the device has. Windows sends a READ FORMAT CAPACITIES command for both LUNs and Linux doesn't. Again I doubt this makes any difference. Windows sends INQUIRY and READ FORMAT CAPACITIES for LUN 0 and then INQUIRY and READ FORMAT CAPACITIES for LUN 1, before trying to read from LUN 0. Linux sends an INQUIRY to LUN 0 and then tries to read it before sending an INQUIRY to LUN 1. This could be significant. You might be able to get Linux to behave more like Windows if you do this before plugging in the device: modprobe usb-storage rmmod sd-mod Post the dmesg log showing what happens when you try this. Created attachment 7585 [details]
kmsg.log
- usb-storage loaded
- inserting pendrive
- waiting...
- sd-mod loaded
- waiting...
- pendrive removed
Kernel with both US_FL_NOT_LOCKABLE and US_FL_NO_WP_DETECT.
Okay, that didn't help. I don't know what the problem is. Almost exactly the same READ(10) command succeeded in Windows and failed in Linux. The only difference (which might be an important one) is that Linux asked for 8 sectors to be transferred and Windows asked for only 1. It was the very first sector on the device, the sector containing the partition table. I don't know any way to force Linux to transfer just a single sector. I think we're all stumped on this one. Unless someone has a brainwave, let's close this. The problem might very well be the same as the problem reported by Vaclav Barta in this thread: http://marc.theaimsgroup.com/?l=linux-usb-users&m=116602219816 You can read the messages in the email archive to see all the different things we tried. In the end it turned out there was no way to change the kernel to make the device work. But there was a solution involving the plscsi program. It is described in the last few messages of the thread: http://marc.theaimsgroup.com/?l=linux-usb-users&m=117027568924140&w=2 Well, it looks pretty much the same and yes, plscsi also works in my case. To bad that there is apparently no way to make it work 'out of box'. |