On Sun, 28 May 2006, Norbert Preining wrote:
> > Try reverting all the patches you have made except the one that adds
> > msleep() after the line setting srb->result. Instead of calling msleep,
> > have it goto Handle_Errors.
>
> Yup done. Nice ... I still get a lot of resets, but the copying
Hi Alan!
On Sam, 27 Mai 2006, Alan Stern wrote:
> > - the usb control interface works, lsusb -v does work all the time
> > and the stuff is seen in usbmon
>
> It's not uncommon for one part of a USB interface (the part that handles
It was only for your info, someone asked me about this.
> >
On Fri, 26 May 2006, Norbert Preining wrote:
> Dear Alan!
>
> On Fre, 26 Mai 2006, Alan Stern wrote:
> > UNUSUAL_DEV( 0x1006, 0x3003, 0x0100, 0x0100,
> > "iRiver",
> > "H300 Series",
> > US_SC_DEVICE, US_PR_DEVICE, NULL,
> > US_FL_GO_SLOW ),
>
> O
Dear Alan!
On Fre, 26 Mai 2006, Alan Stern wrote:
> UNUSUAL_DEV( 0x1006, 0x3003, 0x0100, 0x0100,
> "iRiver",
> "H300 Series",
> US_SC_DEVICE, US_PR_DEVICE, NULL,
> US_FL_GO_SLOW ),
Ok, didn't change anything. But I have some more obervation
On Fri, 26 May 2006, Norbert Preining wrote:
> > Your symptoms remind me a little of what used to happen with the Genesys
> > chips. Maybe the same solution will help. Do you know how to add an
> > entry for your drive into the unusual_devs.h file? It should contain the
> > US_FL_GO_SLOW fla
Hi Alan!
On Don, 25 Mai 2006, Alan Stern wrote:
> Well, don't be in too big a hurry to give up. If you're having these
> problems, the chances are reasonably good that other people with similar
> hardware are too. They just don't notice or complain about it. But we
> would like the driver to wo
On Thursday 25 May 2006 7:27 pm, Alan Stern wrote:
> > So I guess we close this chapter, I can live with the resets (shouldn't
> > look so much into the log files, or?).
>
> Well, don't be in too big a hurry to give up. If you're having these
> problems, the chances are reasonably good that othe
On Thu, 25 May 2006, Norbert Preining wrote:
> Hi Alan!
>
> On Don, 25 Mai 2006, Alan Stern wrote:
> > I don't know whether such a change would be acceptable in general.
> > Perhaps it would, especially if we jump to Handle_Errors only for data-OUT
> > transfers.
>
> Please keep in mind that I
Hi Alan!
On Don, 25 Mai 2006, Alan Stern wrote:
> I don't know whether such a change would be acceptable in general.
> Perhaps it would, especially if we jump to Handle_Errors only for data-OUT
> transfers.
Please keep in mind that I am *NOT* searching for a hand-made solution
for me! I just wa
On Thu, 25 May 2006, Norbert Preining wrote:
> Hi all!
>
> On Mit, 24 Mai 2006, Alan Stern wrote:
> > It might not be a bad idea to follow Pete's advice and use usbmon.
>
> Done.
>
> On Mit, 24 Mai 2006, Pete Zaitcev wrote:
> > I suggest looking for -104 (unlink). It can be done with grep. Us
Hi Alan!
On Don, 25 Mai 2006, Alan Stern wrote:
> If you want to try an interesting test, go back to the
> usb_stor_invoke_transport() routine in transport.c, just above the
> Handle_Errors line. Where it says:
>
> /* Did we transfer less than the minimum amount required? */
> if (sr
On Thu, 25 May 2006, Norbert Preining wrote:
> Hi Alan!
>
> On Don, 25 Mai 2006, Alan Stern wrote:
> > If you want to try an interesting test, go back to the
> > usb_stor_invoke_transport() routine in transport.c, just above the
> > Handle_Errors line. Where it says:
> >
> > /* Did we trans
On Thu, 25 May 2006, Norbert Preining wrote:
> Hi all!
>
> On Don, 25 Mai 2006, Alan Stern wrote:
> > If you want to try an interesting test, go back to the
> > usb_stor_invoke_transport() routine in transport.c, just above the
> > Handle_Errors line. Where it says:
>
> Ok, I did this:
>
> >
Hi all!
On Don, 25 Mai 2006, Alan Stern wrote:
> If you want to try an interesting test, go back to the
> usb_stor_invoke_transport() routine in transport.c, just above the
> Handle_Errors line. Where it says:
Ok, I did this:
> /* Did we transfer less than the minimum amount required? */
Hi all!
On Mit, 24 Mai 2006, Alan Stern wrote:
> It might not be a bad idea to follow Pete's advice and use usbmon.
Done.
On Mit, 24 Mai 2006, Pete Zaitcev wrote:
> I suggest looking for -104 (unlink). It can be done with grep. Use
Attached is the region around the first -104, I hope I didn't
On Wed, 24 May 2006 21:32:46 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote:
> output, not very easy to interpret. But it shouldn't be hard to find the
> sections where the 29 timeouts and resets occur, just by searching for
> large jumps in the timestamps.
I suggest looking for -104 (unlink)
On Wed, 24 May 2006, Norbert Preining wrote:
> On Mit, 24 Mai 2006, Alan Stern wrote:
> > Or maybe the disk's firmware crashes and stops responding, but the driver
> > waits for the current command to time out before doing a reset. I guess
> > there's no easy way to tell the difference between a
On Wednesday 24 May 2006 2:58 pm, Norbert Preining wrote:
> Hi all!
>
> On Mit, 24 Mai 2006, David Brownell wrote:
> > One way to see if the drive itself has locked up is to run "lsusb -v",
>
> I copied the same amount, and in another window I had a
> while true ; do
> date
>
On Mit, 24 Mai 2006, David Brownell wrote:
> "lsusb" will time out and thus seem to succeed ... what you need to do is
> notice whether it's getting errors when trying to access that device.
Hmm, I thought it will block for some time. Ok, what would be the error,
do you have an error text I can ea
Hi all!
On Mit, 24 Mai 2006, David Brownell wrote:
> One way to see if the drive itself has locked up is to run "lsusb -v",
I copied the same amount, and in another window I had a
while true ; do
date
lsusb -v -D /proc/bus/usb (my device)
On Wed, 24 May 2006, Norbert Preining wrote:
> Hi Alan!
>
> On Mit, 24 Mai 2006, Alan Stern wrote:
> > The normal usb-storage debugging isn't very good for tracking down
> > intermittent problems like this. However if you want, you can add your
> > own printk statements to the driver to find o
On Wed, 24 May 2006, Pete Zaitcev wrote:
> I'm so sad that nobody uses usbmon. It has timestamps which you can
> copy-paste into bc(1) and get time differentials.
Now Pete, that's not fair. I have advised people to use usbmon on
numerous occasions and it has been very helpful.
It just wasn't a
On Wed, 24 May 2006 11:26:37 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote:
> > Nup, here it sometimes takes 1min to get it going again.
>
> How can you tell? By watching an LED?
> The place you should modify is in drivers/usb/storage/transport.c. Near
> the end of the usb_stor_invoke_tran
On Wednesday 24 May 2006 10:26 am, Norbert Preining wrote:
>
> Maybe it is only that the hard disk needs so much time to actually safe
> the data and while this time it is blocking. Possible?
My theory is that some drives have problems when lots of data gets written
to them (too quickly?), and so
Hi Alan!
On Mit, 24 Mai 2006, Alan Stern wrote:
> The normal usb-storage debugging isn't very good for tracking down
> intermittent problems like this. However if you want, you can add your
> own printk statements to the driver to find out exactly when each reset
> starts and ends.
Ok, I retr
Hi Alan!
On Mit, 24 Mai 2006, Alan Stern wrote:
> Definitely not good. Perhaps the problem is in the USB interface of your
> hard drive.
Umpf, hard to track down this. Ok.
> > (and I checked that it was all from the same instance of copying, not
> > from an older one). It seems that the reset
On Wed, 24 May 2006, Norbert Preining wrote:
> I changed computer *AND* cable and got an even worse result:
> $ grep "reset high speed" syslog | awk '{print$3}'
> 11:45:26
> 11:46:00
> 11:48:55
> 11:49:46
> 11:52:29
> 11:53:01
> 11:53:32
> 11:54:15
> 11:55:15
> 11:55:50
> 12:02:12
> 12:04:39
> 12:
Hi Alan!
On Mit, 24 Mai 2006, Alan Stern wrote:
> > > It's not expected but it's also not uncommon. Although 25 times in 5.4
> > > GB
> > > (how many minutes was that?) sounds like a lot.
> >
> > at least 26min, the first reset was at 18:11 (syslog), the last at
> > 18:37. Is this a normal tim
On Tue, 23 May 2006, Norbert Preining wrote:
> Dear Alan,
>
> On Die, 23 Mai 2006, Alan Stern wrote:
> > It's not expected but it's also not uncommon. Although 25 times in 5.4 GB
> > (how many minutes was that?) sounds like a lot.
>
> at least 26min, the first reset was at 18:11 (syslog), the
Dear Alan,
On Die, 23 Mai 2006, Alan Stern wrote:
> It's not expected but it's also not uncommon. Although 25 times in 5.4 GB
> (how many minutes was that?) sounds like a lot.
at least 26min, the first reset was at 18:11 (syslog), the last at
18:37. Is this a normal time? I had the feeling that
On Tue, 23 May 2006, Norbert Preining wrote:
> Hi all!
>
> I own an iriver H300, ie an external hard disk. When I connect it via
> usb2 to my laptop or desktop pc I often get
> usb 2-2: reset high speed USB device using ehci_hcd and address 2
> This happens often, although it does not ruin
Hi all!
I own an iriver H300, ie an external hard disk. When I connect it via
usb2 to my laptop or desktop pc I often get
usb 2-2: reset high speed USB device using ehci_hcd and address 2
This happens often, although it does not ruin the files nor creates
other problems (besides the time u
32 matches
Mail list logo
