Hi all,
Is there any code related to FSTN support in
Linux-2.6.9 kernel EHCI code.I have gone through the
code & found only a datastructure for FSTN.There is no
code like adding save place FSTN , restore FSTN.
Is there any patch available for this.If not how the
Linux Host Controller Driver will
Jonatan Antoni wrote:
Hello,
we are using an AT91RM9200 microcomputer as a usb-gadget.
If our target is connected to a host and the usb-link is in use by e.g.
g_ether, it goes into a kernel oops in some
cases.
I have reconstructed the following case:
- establish the usb-connection between the
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)
Here is a patch that adds a new routine to usbcore:
usb_reset_composite_device(). The routine is a wrapper around
usb_reset_device(), but before doing the reset it warns all drivers bound
to the affected device, and after the reset it lets them know that the
reset is finished.
These notificat
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
Wait for the scheduled work to finish before freeing memory, prevent oops.
http://bugzilla.kernel.org/show_bug.cgi?id=6596
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
--- linux-2.6.17-rc2/drivers/usb/serial/usb-serial.c2006-04-23
21:06:18.0 -0700
+++ linux-2.6.17-rc2-lem/drivers/
Looks good to me. Greg, please apply.
Matt
Signed-off-by: Matthew Dharm <[EMAIL PROTECTED]>
On Wed, May 24, 2006 at 04:57:28PM +0200, Franck Bui-Huu wrote:
>
> This patch uses completion timeout instead of a timer to implement
> a timeout when submitting an URB.
>
> It also put the task in in
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
This is Dan Streetman's patch to improve TT scheduling; it's EHCI-specific
for now (though other high speed host controllers will need some of the
same logic). I merged Dan's three patches into one. It works for me in
light usage.
Dan, many thanks for this work!
- Dave
From [EMAIL PROTECTED]
On Tuesday 23 May 2006 12:27 pm, Christopher Montgomery wrote:
> Oh, a quick question that's been bugging me...
>
> I assume that intr_submit() in ehci-sched.c also handles high-speed
> endpoints (not just fs/ls endpoints).
Yes ...
> If so, why does
> check_intr_schedule() not only blindly alwa
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, Daniel Drake wrote:
> Alan Stern wrote:
> > The idea is that the kernel now keeps track of USB power budgets. When a
> > bus-powered device requires more current than its upstream hub is capable
> > of providing, the kernel will not configure it.
>
> Thanks for the explana
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:
Alan Stern wrote:
The idea is that the kernel now keeps track of USB power budgets. When a
bus-powered device requires more current than its upstream hub is capable
of providing, the kernel will not configure it.
Thanks for the explanation. I wrote a quick patch to make the reasoning
visible
This patch uses completion timeout instead of a timer to implement
a timeout when submitting an URB.
It also put the task in interruptible state instead of an
uninterruptible one while waiting for the completion.
Signed-off-by: Franck Bui-Huu <[EMAIL PROTECTED]>
---
drivers/usb/storage/trans
Alan Stern wrote:
> On Wed, 24 May 2006, Franck Bui-Huu wrote:
>
>> and use completion timeout instead. It also put the task
>> in interruptible state instead of an uninterruptible one
>> while waiting for the completion.
>
> Don't make the email content a continuation of the subject line. When
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 Wed, 24 May 2006, Franck Bui-Huu wrote:
> and use completion timeout instead. It also put the task
> in interruptible state instead of an uninterruptible one
> while waiting for the completion.
Don't make the email content a continuation of the subject line. When
your patch is accepted the co
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
On Wednesday 24 May 2006 12:50 am, Jonatan Antoni wrote:
> I have reconstructed the following case:
> - establish the usb-connection between the target and a windows host
> - do "modprobe g_ether" on the target
> - do "ifconfig usb0 192.168.1.2 up" on the target
> - test the connection with e.g. pi
On Tuesday 23 May 2006 10:52 pm, Oliver Neukum wrote:
> Am Mittwoch, 24. Mai 2006 07:35 schrieb Xu Nakajima:
> > to kmalloc; Any
> > idea what is the advantage of using a DMA buffer
>
> 1. The buffer is mapped only once, upon allocation, not every submission.
With the disadvantage that it's prob
On Tuesday 23 May 2006 11:32 am, Christopher Montgomery wrote:
> Second: Why were his patches not accepted? I've not yet reviewed them
> in exhaustive detail myself, only skimmed over the strategy.
Takes time to investigate the issues, review, test. I'll be forwarding
the latest version of his
and use completion timeout instead. It also put the task
in interruptible state instead of an uninterruptible one
while waiting for the completion.
Signed-off-by: Franck Bui-Huu <[EMAIL PROTECTED]>
---
drivers/usb/storage/transport.c | 38 ++
1 files chan
Hello,
we are using an AT91RM9200 microcomputer as a usb-gadget.
If our target is connected to a host and the usb-link is in use by e.g.
g_ether, it goes into a kernel oops in some
cases.
I have reconstructed the following case:
- establish the usb-connection between the target and a windows hos
31 matches
Mail list logo
