Re: [linux-usb-devel] Re: [BK PATCH] USB changes for 2.4.21-pre6
On Mon, 31 Mar 2003, John Goerzen wrote:
Matthew Dharm [EMAIL PROTECTED] writes:
Can you use 'dd' to read data from the device?
No, it gives an I/O error as well.
However, I have good news. The following simple patch fixes it for
me:
--- transport.c~ 2003-03-29 10:00:48.0 -0600
+++ transport.c 2003-03-31 17:03:51.0 -0600
@@ -631,6 +631,7 @@
*/
if (result == USB_STOR_TRANSPORT_ABORTED) {
US_DEBUGP(-- transport indicates command was aborted\n);
+ us-transport_reset(us);
srb-result = DID_ABORT 16;
return;
}
Now, this may well totally ruin things for everyone else. I have no
other USB storage devices to test, so for me, it's very nice :-)
I stumbled across this after noticing the 2.5.x resets when
it gets an error, but 2.4.x does not.
You shouldn't use that patch; it's not correct. The driver isn't supposed
to reset the device after an abort, only after an error (and an abort
doesn't count as an error).
Based on the kernel log you posted earlier, it looks like your problem may
stem from the use of a START-STOP command. The patch below removes that
command; it's a backport from 2.5. Try installing this and let us know if
it helps.
Alan Stern
--- linux-2.4.21/drivers/scsi/sd.c.orig Mon Mar 31 16:27:31 2003
+++ linux-2.4.21/drivers/scsi/sd.c Mon Mar 31 16:56:20 2003
@@ -731,15 +731,17 @@
* check_disk_change */
}
- /* Using Start/Stop enables differentiation between drive with
+ /*
+* Using TEST_UNIT_READY enables differentiation between drive with
* no cartridge loaded - NOT READY, drive with changed cartridge -
* UNIT ATTENTION, or with same cartridge - GOOD STATUS.
-* This also handles drives that auto spin down. eg iomega jaz 1GB
-* as this will spin up the drive.
+*
+* Drives that auto spin down. eg iomega jaz 1G, will be started
+* by sd_init_onedisk(), whenever revalidate_scsidisk() is called.
*/
retval = -ENODEV;
if (scsi_block_when_processing_errors(SDev))
- retval = scsi_ioctl(SDev, SCSI_IOCTL_START_UNIT, NULL);
+ retval = scsi_ioctl(SDev, SCSI_IOCTL_TEST_UNIT_READY, NULL);
if (retval) { /* Unable to test, unit probably not ready.
* This usually means there is no disc in the
---
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
re: [linux-usb-devel] problem with Ego technology music disk MD100USB storage device (add PowerColor MUSICDISK too)
(Unfortunately the sourceforge mail archive doesn't include complete
sender addresses, so I can't copy this message to Peter De Schrijver.)
On 31 Mar 2003, Chris Worley wrote:
[I didn't see this in the archives from Sunday; I apologize if this is a
repost; if there is a more appropriate place to post, please tell me]
On 2003-02-05 21:23:43 Peter 'p2' De Schrijver wrote:
Hi,
I'm trying to get the Ego Technology MD100 to work under linux. It's
small MP3 player gadget which has 128MB of flash and a USB interface.
It
identifies itself as a USB storage device. When I try to read from it
under linux, the process doing the read just hangs. The device works
under windows 2000 with the default windows USB storage driver.
I'm running the stock 2.4.20 linux kernel.
attached is the dmesg output, the output of /proc/bus/usb/devices and
.config of the kernel.
...snip a few thousand lines...
Peter,
Did you ever get an answer? Were you able to get this working?
I have the same device, although it's marketed differently (claiming
Linux 2.4.x compatibility!) as a PowerColor MD100 128MB Portable
Storage/Music DISK USB MP3 Player:
http://www.ateck.com/viewItem.asp?idProduct=453055232
From the vendor power-color.com:
http://www.power-color.com/html/md100.html
But, it has the same USB device/product ID's as yours (0x8341/0x2000).
Furthermore, I have the exact same problem. I've tried it on 5
different Linux Boxes, ranging from SuSE 7.3 to 8.1 and RedHat 7.2 to
7.3. The kernels range from 2.4.9 to 2.4.20; all have USB properly
installed and working for other devices, including other pen drives.
The SuSE based machines hang tight (need to power cycle) about a minute
after installation of the device. On the RedHat machines, they see the
device, but any attempt to read the device (i.e. fdisk -l, dd
if=/dev/sda of=/dev/null, mount /dev/sda ...) locks up the process
and either the usb-storage or the sd_mod driver (I don't know which).
Peter's information, at:
http://sourceforge.net/mailarchive/message.php?msg_id=3737890
...was much more in-depth, but I'll add:
Judging from the information in Peter's message, it looks like the problem
stems from the use of a START-STOP command. The patch below removes that
command; it's a backport from 2.5. It applies to 2.4.21-pre6. Try it and
let me know if it helps.
Alan Stern
--- linux-2.4.21/drivers/scsi/sd.c.orig Mon Mar 31 16:27:31 2003
+++ linux-2.4.21/drivers/scsi/sd.c Mon Mar 31 16:56:20 2003
@@ -731,15 +731,17 @@
* check_disk_change */
}
- /* Using Start/Stop enables differentiation between drive with
+ /*
+* Using TEST_UNIT_READY enables differentiation between drive with
* no cartridge loaded - NOT READY, drive with changed cartridge -
* UNIT ATTENTION, or with same cartridge - GOOD STATUS.
-* This also handles drives that auto spin down. eg iomega jaz 1GB
-* as this will spin up the drive.
+*
+* Drives that auto spin down. eg iomega jaz 1G, will be started
+* by sd_init_onedisk(), whenever revalidate_scsidisk() is called.
*/
retval = -ENODEV;
if (scsi_block_when_processing_errors(SDev))
- retval = scsi_ioctl(SDev, SCSI_IOCTL_START_UNIT, NULL);
+ retval = scsi_ioctl(SDev, SCSI_IOCTL_TEST_UNIT_READY, NULL);
if (retval) { /* Unable to test, unit probably not ready.
* This usually means there is no disc in the
---
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [BK PATCH] USB changes for 2.4.21-pre6
On Tue, Apr 01, 2003 at 09:50:54AM -0500, Alan Stern wrote: + us-transport_reset(us); srb-result = DID_ABORT 16; return; } You shouldn't use that patch; it's not correct. The driver isn't supposed to reset the device after an abort, only after an error (and an abort doesn't count as an error). The interesting thing is that in 2.5.x this same condition does trigger a reset, and the device then works. There seems to be some difference in definition of abort between 2.4.x and 2.5.x, though. Based on the kernel log you posted earlier, it looks like your problem may stem from the use of a START-STOP command. The patch below removes that command; it's a backport from 2.5. Try installing this and let us know if it helps. I will try this evening and let you know. -- John --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: Keyspan 49W/49WLC Panic with 2.4.21-pre5 bk latest
On Tue, Apr 01, 2003 at 05:24:11PM +0100, Nick Craig-Wood wrote: On Fri, Mar 21, 2003 at 05:29:45PM -0800, Greg KH wrote: On Fri, Mar 21, 2003 at 12:51:15PM +, Nick Craig-Wood wrote: I first noticed this problem in the 2.4.20 kernel. I checked out the latest bk kernel from bk://linuxusb.bkbits.net/usb-2.4 to test if the problem was still there. In a nutshell the problem seems to be that a panic happens if the keyspan driver is receiving data when the port is closed. Yeah, a lot of people have this problem right now :( It should be fixed in 2.5, can you grab 2.5.65 and let me know if you still have the same problem there? I tried 2.5.66 and yes it no longer Oopses on close! I tried it 100 times on USA-49W and USA-49WLC just to be sure. Good :) Is it easy to break out a patch for this for 2.4? I'd willingly test it for you. Heh, it isn't a simple patch, sorry. I'll try to get some time to work on it, but help is appreciated. Also, sometimes switching host controller drivers seems to fix the problem for some people (from uhci.o to usb-uhci.o or the other way around), if you have a UHCI controller. I tried moving from usb-uhci to uchi with no improvement :-( This testing turned up another problem though... Bad :( While testing on 2.5 I tried to use multiple ports at once with cambert. The problem is that only the first port transfers data properly - the second and subsequent ports transfer very little data. mostly. (I did see it once transfer an outrageously large amount like 100MB in a second but I haven't managed to reproduce this!) Once cambert has got going it just does non-blocking reads and writes into all the sockets it has open. Eg from strace... What is cambert doing? Any chance to see the source? Could we just be flooding the first port and not getting a chance to send any data out the second? What causes the test to end, one port finishing? Does slower baud rates work ok? thanks, greg k-h --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: Keyspan 49W/49WLC Panic with 2.4.21-pre5 bk latest
On Tue, Apr 01, 2003 at 09:05:16AM -0800, Greg KH wrote: On Tue, Apr 01, 2003 at 05:24:11PM +0100, Nick Craig-Wood wrote: I tried 2.5.66 and yes it no longer Oopses on close! I tried it 100 times on USA-49W and USA-49WLC just to be sure. Good :) Is it easy to break out a patch for this for 2.4? I'd willingly test it for you. Heh, it isn't a simple patch, sorry. I'll try to get some time to work on it, but help is appreciated. Great! Whenever you are ready! While testing on 2.5 I tried to use multiple ports at once with cambert. The problem is that only the first port transfers data properly - the second and subsequent ports transfer very little data. mostly. (I did see it once transfer an outrageously large amount like 100MB in a second but I haven't managed to reproduce this!) Once cambert has got going it just does non-blocking reads and writes into all the sockets it has open. Eg from strace... What is cambert doing? It sets up the ttys into the mode suggested on the command line, sets them non-blocking then launches into an infinite read() and write() loop. For each port... It generates some random data if it hasn't got any It attempts to write() that data to the port. If the write() succeeds it decrements the amount of random data its got It then attempts to read data from the port. If it gets some and it is already synced up then it continues. Any chance to see the source? I can send you the source I expect, but I don't think I can send it to the world! I'll try tonight to write a simple test prog which demonstrates the problem. Could we just be flooding the first port and not getting a chance to send any data out the second? Do you mean user space or kernel space here? cambert itself just tries to write() stuff to each port in turn and when that succeeds it generates a little more random data and write()s that in turn. What causes the test to end, one port finishing? The test runs until CTRL-C Does slower baud rates work ok? It still goes wrong at 1200 baud, so no. -- Nick Craig-Wood [EMAIL PROTECTED] --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: Keyspan 49W/49WLC Panic with 2.4.21-pre5 bk latest
On Tue, Apr 01, 2003 at 06:52:44PM +0100, Nick Craig-Wood wrote: It sets up the ttys into the mode suggested on the command line, sets them non-blocking then launches into an infinite read() and write() loop. For each port... It generates some random data if it hasn't got any It attempts to write() that data to the port. If the write() succeeds it decrements the amount of random data its got It then attempts to read data from the port. If it gets some and it is already synced up then it continues. Ah, sounds like a good serial driver test :) Could we just be flooding the first port and not getting a chance to send any data out the second? Do you mean user space or kernel space here? cambert itself just tries to write() stuff to each port in turn and when that succeeds it generates a little more random data and write()s that in turn. I mean within the kernel driver, sorry. I'd like to test this with some other adapters I have here, to try to see if it's a userspace or kernel problem. I only have one loopback connector on me at the moment, but have a bunch more at home. thanks, greg k-h --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] (no subject)
Hello I try to make a MP3 driver base on Usb-skeleton file for the Mpgio mp3 player actually me and a friend have sniffed the mp3 player on Windows with usb snoopy pro, it work fine , having a good log (I can send you if you want) but the big problem is about the reverse engine when we send control msg with my C program the usb mpgio doesn't respond and we don't know where is the problem 1/ must i reset the usb port before sending a request and how ?? 2/ must i take the request (usb_control_msg) orderer of snoopy pro for initialise my player and use it. 3/ have you tips for translating an usbsnoopy log for linux program (such as the lego tower project) 4/in my program I think all is good (hehe, sometimes I dream.. ;-)) but the Mpgio hardware doesn't respond to the driver : perhaps the problem is due to : -hardware initilisation failed -order of request (C2 00 00 00 00 00 03 ...) if you can sending me doc or informations about making this special usb control msg or other usb initialisation :) Best Regards, Olivier and Remy ps : his midi project : www.sf.net/projects/portmanlinux (ok, totally O/T, but he insist..) Please CC : [EMAIL PROTECTED] [EMAIL PROTECTED] PS : a part of the log 16:25:51 0001 16:25:51 URB 1201 coming back... 0002 16:25:51 -- URB_FUNCTION_CONTROL_TRANSFER: 0003 16:25:51PipeHandle = 815d0fb4 0004 16:25:51TransferFlags= 0002 (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANSFER_OK) 0005 16:25:51TransferBufferLength = 0006 16:25:51TransferBuffer = 81371351 0007 16:25:51TransferBufferMDL= 0008 16:25:51UrbLink = 0009 16:25:51SetupPacket : 42 04 06 01 00 00 00 00 0010 16:25:51 UsbSnoop - IRP_MJ_INTERNAL_DEVICE_CONTROL, IOCTL_INTERNAL_USB_SUBMIT_URB 0011 16:25:51 0012 16:25:51 URB 1202 going down... 0013 16:25:51 -- URB_FUNCTION_VENDOR_ENDPOINT: 0014 16:25:51TransferFlags = (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TRANSFER_OK) 0015 16:25:51TransferBufferLength = 0016 16:25:51TransferBuffer = 81371351 0017 16:25:51TransferBufferMDL= 0018 16:25:51 0019 16:25:51UrbLink = 0020 16:25:51RequestTypeReservedBits = 00 0021 16:25:51Request = 04 0022 16:25:51Value = 0104 0023 16:25:51Index = 0024 16:25:51 0025 16:25:51 URB 1202 coming back... 0026 16:25:51 -- URB_FUNCTION_CONTROL_TRANSFER: 0027 16:25:51PipeHandle = 815d0fb4 0028 16:25:51TransferFlags= 0002 (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANSFER_OK) 0029 16:25:51TransferBufferLength = 0030 16:25:51TransferBuffer = 81371351 0031 16:25:51TransferBufferMDL= 0032 16:25:51UrbLink = 0033 16:25:51SetupPacket : 42 04 04 01 00 00 00 00 0034 16:25:51 UsbSnoop - IRP_MJ_INTERNAL_DEVICE_CONTROL, IOCTL_INTERNAL_USB_SUBMIT_URB 0035 16:25:51 0036 16:25:51 URB 1203 going down... 0037 16:25:51 -- URB_FUNCTION_VENDOR_ENDPOINT: 0038 16:25:51TransferFlags = (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TRANSFER_OK) 0039 16:25:51TransferBufferLength = 0040 16:25:51TransferBuffer = 81371351 0041 16:25:51TransferBufferMDL= 0042 16:25:51 0043 16:25:51UrbLink = 0044 16:25:51RequestTypeReservedBits = 00 0045 16:25:51Request = 04 0046 16:25:51Value = 0103 0047 16:25:51Index = 0048 16:25:51 0049 16:25:51 URB 1203 coming back... 0050 16:25:51 -- URB_FUNCTION_CONTROL_TRANSFER: 0051 16:25:51PipeHandle = 815d0fb4 0052 16:25:51TransferFlags= 0002 (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANSFER_OK) 0053 16:25:51TransferBufferLength = 0054 16:25:51TransferBuffer = 81371351 0055 16:25:51TransferBufferMDL= 0056 16:25:51UrbLink = 0057 16:25:51SetupPacket : 42 04 03 01 00 00 00 00 0058 16:25:51 UsbSnoop - IRP_MJ_INTERNAL_DEVICE_CONTROL, IOCTL_INTERNAL_USB_SUBMIT_URB 0059 16:25:51 0060 16:25:51 URB 1204 going down... 0061 16:25:51 -- URB_FUNCTION_VENDOR_ENDPOINT: 0062 16:25:51TransferFlags = (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TRANSFER_OK) 0063 16:25:51TransferBufferLength = 0064 16:25:51TransferBuffer = 81371351 0065 16:25:51TransferBufferMDL= 0066 16:25:51 0067 16:25:51UrbLink =
Re: [linux-usb-devel] Re: Keyspan 49W/49WLC Panic with 2.4.21-pre5 bk latest
Speaking of Keyspan, one gentleman complains of serial stream corruption with a 2.4.21-pre4 based kernel and 49W. RH bz#86590. I have no idea what to do about it, perhaps I should buy myself one of those things. -- Pete --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] report ID in HID SET_REPORT (APC BackUPS CS)
Hello!
I am trying to get the UPS shutdown working on APC BackUPS CS 500. Its
HID report descriptor has many report IDs; the full dump from hid-core.c
is at the end of message. The value which needs to be set is:
FEATURE(64)[FEATURE]
Field(0)
Physical(ff86.0005)
Usage(1)
ff86.007c
Logical Minimum(0)
Logical Maximum(1)
Report Size(8)
Report Count(1)
Report Offset(0)
Flags( Variable Absolute Volatile )
I am using kernel 2.4.20 (with selected -ac and -pre3 patches - there
are some changes to hid-core.c, but they only add some USB IDs, which do
not match my device).
The first problem I have found was that hid_write_report() did not set
the proper report type in the high byte of wValue (0x200 was hardcoded,
which identifies the output report - but the feature report is needed).
Fixing this was easy - replacing 0x200 by ((report-type + 1) 8) (I
see this is already in the 2.5 tree); however, this still was not
enough:
Mar 31 20:02:41 center4 apctest: Attempting to kill the UPS power!
Mar 31 20:02:41 center4 kernel: usb-uhci.c: interrupt, status 3, frame# 241
Mar 31 20:02:41 center4 kernel: hid-debug: input 0084.0030 = 1304
Mar 31 20:02:41 center4 kernel: hid-debug: input 0085.008c = 50
Mar 31 20:02:41 center4 kernel: hid-debug: input 0085.0029 = 10
Mar 31 20:02:41 center4 kernel: hid-debug: input ff86.007c = 0
Mar 31 20:02:41 center4 kernel: usb-uhci.c: ENXIO 84000280, flags 0, urb c1be0d60,
burb c3d44cf8
Mar 31 20:02:41 center4 kernel: usb-uhci.c: ENXIO 84000280, flags 0, urb c1be0d60,
burb c3d44cf8
Mar 31 20:02:41 center4 kernel: hid-core.c: ctrl urb status -32 received
Mar 31 20:02:41 center4 last message repeated 2 times
I have started to look for another reason why the UPS does not accept
the command. In the USB HID specification I have found the following
text (section 5.6 Reports):
If a device has multiple report structures, all data transfers
start with a 1-byte identifier prefix that indicates which
report structure applies to the transfer. This allows the class
driver to distinguish incoming pointer data from keyboard data
by examining the transfer prefix.
There is no indication whether this applies only to the data received
from the Interrupt In pipe, or also to the Interrupt Out pipe and
Control pipe.
I have tried to add the report ID byte to the request - and it worked!
The UPS started flashing alternately On Line and Overload, and about
45 seconds later turned itself off. The ENXIO log messages went away.
So it looks that at least this UPS wants to see the report ID inside the
data packet in the HID_SET_REPORT control transfer - even if the same
information is available in the low byte of wValue.
Is this the correct reading of the USB HID specification? If it is,
hid-core.c in 2.5 is also wrong - it does not add an extra byte with
report ID in output requests:
vojtech 1.12| if (dir == USB_DIR_OUT)
vojtech 1.12| hid_output_report(report, hid-ctrlbuf);
vojtech 1.12|
vojtech 1.12| hid-urbctrl-transfer_buffer_length = ((report-size
- 1) 3) + 1 + ((report-id 0) (dir != USB_DIR_OUT));
vojtech 1.12| hid-urbctrl-pipe = (dir == USB_DIR_OUT) ?
usb_sndctrlpipe(hid-dev, 0) : usb_rcvctrlpipe(hid-dev, 0);
vojtech 1.12| hid-urbctrl-dev = hid-dev;
Does anyone know any other HID devices which have settable
features/output values and also use report IDs? Do they have similar
behavior?
I have made the following changes (WARNING: this is incomplete and will
break other devices!!! Need to check if report ids are really used):
--- linux-2.4.20/drivers/usb/hid-core.c.alt-hid Tue Mar 18 17:09:28 2003
+++ linux-2.4.20/drivers/usb/hid-core.c Tue Apr 1 16:17:13 2003
@@ -41,8 +41,8 @@
#include asm/unaligned.h
#include linux/input.h
-#undef DEBUG
-#undef DEBUG_DATA
+#define DEBUG
+#define DEBUG_DATA
#include linux/usb.h
@@ -993,6 +993,23 @@
hid-urbout.setup_packet = (void *) (hid-out[hid-outtail].dr);
hid-urbout.dev = hid-dev;
+#ifdef DEBUG_DATA
+ {
+ unsigned size = hid-urbout.transfer_buffer_length;
+ unsigned n;
+ const u8 *buf = (const u8 *) hid-urbout.transfer_buffer;
+
+ printk(KERN_DEBUG __FILE__ : submit_out (size %u, wValue=0x%04x,
wIndex=0x%04x) = ,
+ size,
+ le16_to_cpup(hid-out[hid-outtail].dr.wValue),
+ le16_to_cpup(hid-out[hid-outtail].dr.wIndex)
+ );
+ for (n = 0; n size; n++)
+ printk( %02x, (unsigned) buf[n]);
+ printk(\n);
+ }
+#endif
+
if (usb_submit_urb(hid-urbout)) {
err(usb_submit_urb(out) failed);
return -1;
@@ -1016,10 +1033,11 @@
void hid_write_report(struct hid_device *hid, struct
[linux-usb-devel] Re: [BK PATCH] USB changes for 2.4.21-pre6
Alan Stern [EMAIL PROTECTED] writes:
Based on the kernel log you posted earlier, it looks like your problem may
stem from the use of a START-STOP command. The patch below removes that
command; it's a backport from 2.5. Try installing this and let us know if
it helps.
Indeed it does! Things seem to work fine with your patch.
--- linux-2.4.21/drivers/scsi/sd.c.orig Mon Mar 31 16:27:31 2003
+++ linux-2.4.21/drivers/scsi/sd.cMon Mar 31 16:56:20 2003
@@ -731,15 +731,17 @@
* check_disk_change */
}
- /* Using Start/Stop enables differentiation between drive with
+ /*
+ * Using TEST_UNIT_READY enables differentiation between drive with
* no cartridge loaded - NOT READY, drive with changed cartridge -
* UNIT ATTENTION, or with same cartridge - GOOD STATUS.
- * This also handles drives that auto spin down. eg iomega jaz 1GB
- * as this will spin up the drive.
+ *
+ * Drives that auto spin down. eg iomega jaz 1G, will be started
+ * by sd_init_onedisk(), whenever revalidate_scsidisk() is called.
*/
retval = -ENODEV;
if (scsi_block_when_processing_errors(SDev))
- retval = scsi_ioctl(SDev, SCSI_IOCTL_START_UNIT, NULL);
+ retval = scsi_ioctl(SDev, SCSI_IOCTL_TEST_UNIT_READY, NULL);
if (retval) { /* Unable to test, unit probably not ready.
* This usually means there is no disc in the
---
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
---
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
re: [linux-usb-devel] problem with Ego technology music disk MD100USB storage device (add PowerColor MUSICDISK too)
Bingo.
This worked great. There was a little tweak on the sd.c patch for the
2.4.19 kernel, but it was apparent.
Thanks!
Chris
On Tue, 2003-04-01 at 07:59, Alan Stern wrote:
(Unfortunately the sourceforge mail archive doesn't include complete
sender addresses, so I can't copy this message to Peter De Schrijver.)
On 31 Mar 2003, Chris Worley wrote:
[I didn't see this in the archives from Sunday; I apologize if this is a
repost; if there is a more appropriate place to post, please tell me]
On 2003-02-05 21:23:43 Peter 'p2' De Schrijver wrote:
Hi,
I'm trying to get the Ego Technology MD100 to work under linux. It's
small MP3 player gadget which has 128MB of flash and a USB interface.
It
identifies itself as a USB storage device. When I try to read from it
under linux, the process doing the read just hangs. The device works
under windows 2000 with the default windows USB storage driver.
I'm running the stock 2.4.20 linux kernel.
attached is the dmesg output, the output of /proc/bus/usb/devices and
.config of the kernel.
...snip a few thousand lines...
Peter,
Did you ever get an answer? Were you able to get this working?
I have the same device, although it's marketed differently (claiming
Linux 2.4.x compatibility!) as a PowerColor MD100 128MB Portable
Storage/Music DISK USB MP3 Player:
http://www.ateck.com/viewItem.asp?idProduct=453055232
From the vendor power-color.com:
http://www.power-color.com/html/md100.html
But, it has the same USB device/product ID's as yours (0x8341/0x2000).
Furthermore, I have the exact same problem. I've tried it on 5
different Linux Boxes, ranging from SuSE 7.3 to 8.1 and RedHat 7.2 to
7.3. The kernels range from 2.4.9 to 2.4.20; all have USB properly
installed and working for other devices, including other pen drives.
The SuSE based machines hang tight (need to power cycle) about a minute
after installation of the device. On the RedHat machines, they see the
device, but any attempt to read the device (i.e. fdisk -l, dd
if=/dev/sda of=/dev/null, mount /dev/sda ...) locks up the process
and either the usb-storage or the sd_mod driver (I don't know which).
Peter's information, at:
http://sourceforge.net/mailarchive/message.php?msg_id=3737890
...was much more in-depth, but I'll add:
Judging from the information in Peter's message, it looks like the problem
stems from the use of a START-STOP command. The patch below removes that
command; it's a backport from 2.5. It applies to 2.4.21-pre6. Try it and
let me know if it helps.
Alan Stern
--- linux-2.4.21/drivers/scsi/sd.c.orig Mon Mar 31 16:27:31 2003
+++ linux-2.4.21/drivers/scsi/sd.cMon Mar 31 16:56:20 2003
@@ -731,15 +731,17 @@
* check_disk_change */
}
- /* Using Start/Stop enables differentiation between drive with
+ /*
+ * Using TEST_UNIT_READY enables differentiation between drive with
* no cartridge loaded - NOT READY, drive with changed cartridge -
* UNIT ATTENTION, or with same cartridge - GOOD STATUS.
- * This also handles drives that auto spin down. eg iomega jaz 1GB
- * as this will spin up the drive.
+ *
+ * Drives that auto spin down. eg iomega jaz 1G, will be started
+ * by sd_init_onedisk(), whenever revalidate_scsidisk() is called.
*/
retval = -ENODEV;
if (scsi_block_when_processing_errors(SDev))
- retval = scsi_ioctl(SDev, SCSI_IOCTL_START_UNIT, NULL);
+ retval = scsi_ioctl(SDev, SCSI_IOCTL_TEST_UNIT_READY, NULL);
if (retval) { /* Unable to test, unit probably not ready.
* This usually means there is no disc in the
---
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
---
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
