On Wed, 17 Sep 2003, Tomita, Haruo wrote:
> Hi Alan,
>
> Alan> The system sent commands, but the device didn't respond to them.
> Alan> However, it's possible that this patch will help.
> Alan> Try it out and see what happens.
>
> Using 2.4.22-bk15,
> It was adapted in the following patche and
Hi Alan,
Alan> The system sent commands, but the device didn't respond to them.
Alan> However, it's possible that this patch will help.
Alan> Try it out and see what happens.
Using 2.4.22-bk15,
It was adapted in the following patche and I tested.
= your patch =
--- 2.4.22/drivers/usb/
On Sat, 13 Sep 2003, Tomita, Haruo wrote:
> Alan> This makes it look like the device isn't probed again after
> Alan> usbdevfs does the port reset.
>
> Is it that a problem is in a device?
No, it's a problem in Linux. The port-reset code is not fully developed.
> Alan> Yet another thing to w
Hi Alan
Alan wrote:
Haruo> hub.c: port 1, portstatus 110, change 3, 12 Mb/s
Haruo> hub.c: port 1 connection change
Haruo> hub.c: port 1, portstatus 110, change 3, 12 Mb/s
Haruo> usb.c: USB disconnect on device 00:07.2-1 address 2
Haruo> usb-storage: storage_disconnect() called
Haruo> usb-storage
On Fri, 12 Sep 2003, Tomita, Haruo wrote:
> hub.c: port 1, portstatus 110, change 3, 12 Mb/s
> hub.c: port 1 connection change
> hub.c: port 1, portstatus 110, change 3, 12 Mb/s
> usb.c: USB disconnect on device 00:07.2-1 address 2
> usb-storage: storage_disconnect() called
> usb-storage: -- relea
Alan,
Thank you for your help!!
Alan wrote;
Alan> What did the system log show? Try turning on verbose usb
Alan> debugging and run your test again.
Alan> This time post a copy of the system log.
USB DEBUG was not confirmed. The log is as follows.
Sep 12 12:53:44 Andromeda syslogd 1.4.1: re
Hi Alan,
Haruo> Using ioctl (fd, USBDEVFS_RESET, 0), I tested reset.
Haruo> usb-storage of USB2.0 was successful.
Haruo> When FDD was used in the case of USB1.1,
Haruo> mount became impossible after reset.
Alan> What do you mean? What does the log show?
I'm sorry. I wrote the following progr
On Thu, 11 Sep 2003, Tomita, Haruo wrote:
> Hi Alan,
>
> Haruo> Using ioctl (fd, USBDEVFS_RESET, 0), I tested reset.
> Haruo> usb-storage of USB2.0 was successful.
> Haruo> When FDD was used in the case of USB1.1,
> Haruo> mount became impossible after reset.
>
> Alan> What do you mean? What
On Wed, 10 Sep 2003, Tomita, Haruo wrote:
> Using ioctl (fd, USBDEVFS_RESET, 0), I tested reset.
> usb-storage of USB2.0 was successful.
> When FDD was used in the case of USB1.1,
> mount became impossible after reset.
What do you mean? What does the log show?
Alan Stern
--
Hi Alan,
Thank you for your help.
Alan> This time the bus_reset() routine worked, which is an
Alan> improvement over
Alan> what you were seeing before. But the device still didn't respond:
Haruo> If a device becomes an error, it seems that reset is not effective.
Haruo> Using ioctl (fd, USBD
Alan Stern wrote:
On Mon, 8 Sep 2003, David Brownell wrote:
When a device stops responding, it's hard to think the
problem is anything other than with the device. (Though
I still don't see where the storage class-specific reset
gets sent by usb-storage, maybe that'd clean up better.)
The reset
On Mon, 8 Sep 2003, David Brownell wrote:
> > It seems that a device does not answer in the case of kernel 2.4.
> > However, when operating by kernel 2.6 and two or more devices
> > are connected simultaneously, it operates.
> > I cannot think the error of a device.
>
> I'd almost agree, except
On Sun, 7 Sep 2003, Tomita, Haruo wrote:
> I am also looking at this pattern repeatedly.
> It seems that a device does not answer in the case of kernel 2.4.
> However, when operating by kernel 2.6 and two or more devices
> are connected simultaneously, it operates.
> I cannot think the error of a
Tomita, Haruo wrote:
It is because it is hard to generate an error in testing
two simultaneously. When testing simultaneously,
much time is required by the time it generates an error.
This is basically a good thing: the root causes are
getting fixed one by one, so it needs more time before
one of
Hi Alan,
Thank you for your help and useful comment.
Alan wrote:
Haruo> I tested using kernel 2.4.22-bk6. It failed by the
Haruo> following two patterns.
Haruo> 1. Bulk command transfer result=-104
Haruo> 2. usb_stor_bulk_msg() returned -32
Alan> This was two different failures on two separa
15 matches
Mail list logo
