> Try this. I haven't got a patch for you, but you can easily make the
> change by hand.
>
> In the kernel source file drivers/usb/storage/scsiglue.c, somewhere around
> lines 315 to 330, you'll see a couple of lines that say:
>
> /* limit the total size of a transfer to 120 KB */
> .m
On Tue, 16 Dec 2003, Cornelius Claussen wrote:
> >It may be that slowing down the transfer rate will help prevent those I/O
> >errors; that's worked for some people in the past.
>
>
> How can I do that?
On Wed, 17 Dec 2003, David Brownell wrote:
> Those changes to make SCSI use smaller I/O req
Alan Stern <[EMAIL PROTECTED]> schrieb am 16.12.03 23:04:32:
>
> On Tue, 16 Dec 2003, Cornelius Claussen wrote:
>
> > > As for eliminating the I/O errors, well, there's no way to do it. It's
> > > not a fault of the driver or of Linux; it's the fault of your DVD drive or
> > > disc. They just s
On Tue, 16 Dec 2003, Cornelius Claussen wrote:
> > As for eliminating the I/O errors, well, there's no way to do it. It's
> > not a fault of the driver or of Linux; it's the fault of your DVD drive or
> > disc. They just sometimes get transient errors. The best we can hope to
> > do is recover
Am Dienstag, 16. Dezember 2003 20:49 schrieben Sie:
> Actually this is quite different from what you posted before. In the old
> log you got multiple errors in multiple sectors. In this log there's just
> a single error, and the read operation gets retried so in the end the
> error doesn't matter
On Tue, 16 Dec 2003, Cornelius Claussen wrote:
> Hi Alan,
>
> thank you for the patch, but unfortunately it doesn't solve the problem.
> There are still I/O errors from time to time, see attached log file.
Actually this is quite different from what you posted before. In the old
log you got mult
Am Dienstag, 16. Dezember 2003 18:13 schrieb Alan Stern:
> This patch does what James Bottomley suggested. Try using it instead of
> the one I sent to Matthias Geissert (that one is included in here). Let
> me know if it helps solve your problems.
>
> Alan Stern
Hi Alan,
thank you for the patch
I've been thinking some more about this. Although the driver is
apparently at fault here by issuing a reset without telling the
mid-layer, it might be useful to filter out other common ASC/ASCQ codes
in scsi_io_completion() we retry on "in the process of becoming ready",
then for any other UNIT_AT
On 15 Dec 2003, James Bottomley wrote:
> It looks like the driver sent a reset to the device on its own without
> reporting it to the mid-layer.
>
> There's an expecting_cc_ua flag in the scsi_device. It gets set on
> error recovery actions, or if the device does something to detect or
> trigger
On Mon, 2003-12-15 at 15:49, Alan Stern wrote:
> Cornelius Claussen reported the following problem with error recovery in
> 2.6.0-test11. His device is one of those problem-prone Genesys Logic
> units, a USB DVD drive. The complete message and log can be found at
It looks like the driver sent a
Patrick:
Cornelius Claussen reported the following problem with error recovery in
2.6.0-test11. His device is one of those problem-prone Genesys Logic
units, a USB DVD drive. The complete message and log can be found at
http://marc.theaimsgroup.com/?l=linux-usb-devel&m=107134787817252&w=2
Here
Hi,
there was a thread about problems with the LG GSA 4040-B dvd-writer in an
extermal USB 2.0 case from Genesys Logic, Inc. a few days ago.
I have the same combination and the same problems and tried the second patch
from the thread with 2.6.0-test11.
It works way better than before, but if I c
Hi Alan,
it tried your patch. It looks quite good. Reading CD and playing DVD movies works now.
The 3nd attempt of reading CSW works. Therefore, the USB bus is not be reseted.
I will do more tests (writing) at the weekend.
Thanks a lot
matthias
__
On Sat, 6 Dec 2003, matthias geissert wrote:
> Hello,
>
> I applied the patch. Unfortunately, results are the same. The output of
> dmesg is attached.
All right. Here's another try, which might not be any better. See what
happens with the patch below instead.
> BTW what does CSW mean? Can th
CSW is the Command Status Wrapper -- it's how the device returns the status
of a completed command to the host.
Matt
On Sat, Dec 06, 2003 at 02:04:49AM +0100, matthias geissert wrote:
> Hello,
>
> I applied the patch. Unfortunately, results are the same. The output of dmesg is
> attached.
>
>
Hello,
I applied the patch. Unfortunately, results are the same. The output of dmesg is
attached.
BTW what does CSW mean? Can the speed of the USB controller be reduced? I know that
this question sounds quite strange, but if the external case has problems with the
speed of the host controller
On Mon, 1 Dec 2003, David Brownell wrote:
> > The CSW transfer returned 0 bytes, not 13. Another Genesyslogic bug?
>
> That one sounds somewhat familiar. Like "hardware terminated
> write with ZLP" ... I wonder if maybe just re-reading the CSW
> might show better results. "Device bug" does see
From the log it's easy to see why the transfer took so long. There were 6
occurrences of this sort of thing:
Nov 30 13:29:10 nb09 kernel: usb-storage: queuecommand called
Nov 30 13:29:10 nb09 kernel: usb-storage: *** thread awakened.
Nov 30 13:29:11 nb09 kernel: usb-storage: Command READ_10 (1
On Sun, 30 Nov 2003, matthias geissert wrote:
> > Looks like what you forwarded was a log from 2.4.something. Can you
> Yes, that's right.
> > forward the corresponding output from 2.6.0-test11 after enabling both
> > USB mass storage verbose debug (to show the higher level protocol), and
> > USB
matthias geissert wrote:
Hi there,
I just joint the list and I have a question about my DVD burner. I tried several kernels and hardware with the following success (??):
1. If I replace the DVD burner by a harddisk everything works (on all testet hardware & kernels)
The usb-storage protocol is di
20 matches
Mail list logo
