On Fri, 15 Jul 2005, Matthias Urlichs wrote:
> I just had a full disk.
>
> Jul 15 00:37:25 kiste kernel: hub 1-1:1.0: state 5 ports 7 chg evt
> Jul 15 00:37:25 kiste kernel: usb 1-2: gnome-volume-co timed out on ep0in
> len=0/2
> Jul 15 00:37:25 kiste kernel: uhci_hcd :00:10.0: uhc
On Thu, 2 Jun 2005, Matthias Urlichs wrote:
> Hi,
>
> This happened with 2.6.12-rc5-mm1.
> One side effect was that eth0 locked up..?
>
>
> scheduling while atomic: khubd/0x0001/4258
> [] schedule+0x5cc/0x5e0
> [] invalidate_inode_buffers+0xc/0x70
> [] __wake_up+0x14/0x20
> [] __down+0x7b/0
On Thu, 19 May 2005 14:31:17 -0400, "Stuart MacDonald" <[EMAIL PROTECTED]>
wrote:
> I suppose I should have specified that I'm using uhci.c ATM, and am
> aware that QUEUEing is UHCI specific (according to the code). I'll try
> the alternate driver and see what happens.
Even if it works, I'd pref
On Thu, 19 May 2005, Stuart MacDonald wrote:
> I've been having problems with the WhiteHEAT driver update and getting
> bulk queueing to work. Then I noticed that not one of the other serial
> drivers does bulk queueing on the read side. I changed my driver to
> also not do queueing on the read (I
From: Alan Stern [mailto:[EMAIL PROTECTED]
> I can't answer your questions directly. However you should
> note that 2.4
> has _two_ UHCI drivers: uhci.c and usb-uhci.c. Maybe one of
> them works
> with bulk queuing and the other doesn't.
I suppose I should have specified that I'm using uhci
On Fri, 11 Mar 2005, peng peng wrote:
> HI,
>
> I use the following code to enable portsc of uhci
> under DOS,but the port enable failed (set the bit but
> it doesn`t take effect) , I don't know why . Is there
> anyone know what's the problem ? Thanks :)
>
>
> static void uhci_reset_por
On Thu, 2 Dec 2004 11:54:31 -0500 (EST), Alan Stern
<[EMAIL PROTECTED]> wrote:
> On Wed, 1 Dec 2004, Karl Bongers wrote:
>
>
>
> > Hi,
> >
> > So somehow I found myself here despite trying to avoid kernel hacking by
> > using libusb. libusb has this concept of submit a read/write with a
> > ti
On Wed, 1 Dec 2004, Karl Bongers wrote:
> Hi,
>
> So somehow I found myself here despite trying to avoid kernel hacking by
> using libusb. libusb has this concept of submit a read/write with a timeout.
> So I submit a read, and just pick a random timeout, say 1 second.
> Lib usb then sits in a p
On Tue, 9 Nov 2004, Jan Hegner wrote:
> > The driver may be trying to transfer too much data in a single URB, or
> > trying to queue too many URBs at once. But it seems odd that you get a
> > stall even when trying to receive a single frame. Shouldn't that take
> > less than 50 ms? So increa
>
> The driver may be trying to transfer too much data in a single URB, or
> trying to queue too many URBs at once. But it seems odd that you get a
> stall even when trying to receive a single frame. Shouldn't that take
> less than 50 ms? So increasing FSBR_DELAY from 50 to 1000 shouldn't m
On Mon, 8 Nov 2004, Jan Hegner wrote:
> Hi,
>
> our camera device works fine with EHCI controllers. For USB 1.x the device
> is slowed down a little bit. This causes no problems at all under windows.
> Using Linux 2.6.x kernels the device causes pipe stalls. Not a single frame
> can be transmitte
Hi,
i test also today suspend to disk.
echo 4 > /proc/acpi/sleep
there are some errors.
atached log may be helpfull.
bye
pavel kysilka
Information from NOD32
This message was checked by NOD32 Antivirus System for Linux Mail Server.
http://www.nod32.com
Oct
On Sunday 24 October 2004 07:28, Pavel Kysilka wrote:
>
>Hi,
>
> i was testing acpi in my computer. i found problem with suspending usb
> device.
>
> i test:
>
> echo 1 > /proc/acpi/sleep
Or better yet, the new-school approach:
echo standby > /sys/power/state
> and i get this output
On Thu, 2 Sep 2004, Patrick Agrain wrote:
> Hi everybody,
>
> I'm trying to decode the start sequence of an UHCI controler in a 2.4.x
> kernel version. Yes, I know, but we have to work with it ;-)
>
> All the reset and registers programming are clear in my mind, but there are
> several thing o
>> Hi all.
>>
>> I'm testing kernel 2.6.8.1 on my Laptop.
>> It is an Asus L5860G.
>>
>> P4 3.0 GHx (Ht)
>> 512 MB Ram
>> Intel 865G + Geforce2
>> Intel ICH5/ICH5R for USB.
>>
>> I build al drivers as modules.
>
>> If I startup the machine with an USB device plugged then the usb core
>> detect it (
On Wed, 31 Mar 2004, Malcolm Blaney wrote:
> Got it working! Turns out to be related to the timing code after all. I
> narrowed it down to the function: mark_offset_tsc() in
> arch/i386/kernel/timers/timer_tsc.c. I removed the call to it in
> timer_interrupt() in time.c, and then usb didn't han
Alan Stern wrote:
The computer hangs in some timing code not too far down the track, so
maybe this isn't (directly) a problem with usb?
That's certainly possible. On the other hand, it's not clear why it
should happen only when you have FSBR turned on.
Got it working! Turns out to be related
On Tue, 30 Mar 2004, Malcolm Blaney wrote:
> After reading the uhci paper, I decided I couldn't do much more if the
> controller isn't sending out an interrupt at all. So I tried to trace
> back the call to uhci_irq(), which should happen if the controller is
> reponding at all. I found that ha
Alan Stern wrote:
To learn more about how UHCI devices work, go to this page:
http://developer.intel.com/design/USB/UHCI11D.htm
Thanks for that it was very helpful.
The interrupts generally get sent to indicate that the controller has
finished doing its work on the URB. When that happens it's
On Wed, 24 Mar 2004, Malcolm Blaney wrote:
> Alan Stern wrote:
> > Interesting. This weighs against the hypothesis of a hardware problem
> > (device monopolizing the PCI bus, for example). Even 3 ms after FSBR was
> > turned on the system was still operational.
>
> This might be a stupid ques
Alan Stern wrote:
Interesting. This weighs against the hypothesis of a hardware problem
(device monopolizing the PCI bus, for example). Even 3 ms after FSBR was
turned on the system was still operational.
This might be a stupid question, but what else can happen during this
time? Now that yo
On Tue, 23 Mar 2004, Malcolm Blaney wrote:
> FWIW, the new patch gives:
> uhci irq status: 0x24
> usb 1-1: new full speed USB device using address 2
> uhci enqueue: cdb1a2a0
> Before enabling uhci fsbr
> Immediately after enabling uhci fsbr
> 3 ms after enabling uhci fsbr
Interesting. This weigh
Alan Stern wrote:
All right. The patch below might help track down even more precisely
where the problem starts.
FWIW, the new patch gives:
uhci irq status: 0x24
usb 1-1: new full speed USB device using address 2
uhci enqueue: cdb1a2a0
Before enabling uhci fsbr
Immediately after enabling uhci fsb
On Thu, 18 Mar 2004, Malcolm Blaney wrote:
> I changed the console log level, and checked the output from 2.6.2
> again. It prints more than I managed to get from dmesg before, so
> thought I better make the correction. On plugging in a usb device,
> before it hangs I actually get:
> drivers/usb/h
Thanks for your help Alan, it's much appreciated.
I'll report if I get any further.
Malcolm.
Alan Stern wrote:
That certainly looks like things go wrong just at the time the full-speed
bandwidth reclamation gets turned on. Why should FSBR cause any problems?
The only thing that occurs to me n
On Thu, 18 Mar 2004, Malcolm Blaney wrote:
> Alan Stern wrote:
> > There's nothing obviously wrong here. You can try using the patch for
> > Linux 2.6.4 below, which will print out information to the system log when
> > certain key events occur. Also, you should make sure the log is echoed to
>
Alan Stern wrote:
There's nothing obviously wrong here. You can try using the patch for
Linux 2.6.4 below, which will print out information to the system log when
certain key events occur. Also, you should make sure the log is echoed to
your console so you don't lose anything when the system ha
On Mon, 15 Mar 2004, Malcolm Blaney wrote:
> Alan Stern wrote:
> > I wonder if the USB hardware on that computer is faulty. I can't think of
> > any other reason why changing uhci->fsbr would make a difference.
>
> It could be, but we have the same problem on another board we have with
> the s
Hi all,
Sorry Alan, I only sent this to you instead of CC'ing to the list...
--- Begin Message ---
Alan Stern wrote:
I wonder if the USB hardware on that computer is faulty. I can't think of
any other reason why changing uhci->fsbr would make a difference.
It could be, but we have the same pro
On Fri, 12 Mar 2004, Malcolm Blaney wrote:
> Using 2.6.2 I get one line from dmesg when plugging in a device:
> drivers/usb/host/uhci-hcd.c: c400: wakeup_hc
> Nothing gets added to /proc/bus/usb/devices besides the uhci host
> controller info.
>
> After modprobing usbcore and uhci-hcd (but befor
Alan Stern wrote:
Setting uhci->fsbr to 1 has the effect of turning off full-speed bandwidth
reclamation, which will drastically reduce the USB throughput as you saw.
It shouldn't be necessary though. I can't speak for the 2.4 kernel, but
what happens with 2.6 when you leave the driver alone? At
On Thu, 11 Mar 2004, Andrew Zabolotny wrote:
> On Thu, 11 Mar 2004 10:33:17 -0500 (EST)
> Alan Stern <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 11 Mar 2004, Malcolm Blaney wrote:
> > > Without this change, the system hangs while detecting the new device.
> > > With the change though, the usb on the
On Thu, 11 Mar 2004 10:33:17 -0500 (EST)
Alan Stern <[EMAIL PROTECTED]> wrote:
> On Thu, 11 Mar 2004, Malcolm Blaney wrote:
> > Without this change, the system hangs while detecting the new device.
> > With the change though, the usb on the board is very slow, I've been
> > timing it at about 560
On Thu, 11 Mar 2004, Malcolm Blaney wrote:
> Hi all,
>
> I have been writing to the users list about usb not working on a Boser
> single board computer, but have got around the problem by removing the
> line: uhci->fsbr = 0;
> in uhci.c: alloc_uhci() in the 2.4.23 kernel.
>
> Removing the line
On Sat, 28 Feb 2004, Jan Rychter wrote:
> uhci seemed to be able to suspend itself after all USB devices have been
> unplugged. However, I've recently noticed that it doesn't do that for me
> anymore.
>
> I cannot really point to a specific change that caused it, because I
> have changed the hard
On Fri, Jan 30, 2004, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Thu, 29 Jan 2004, Stephen Hemminger wrote:
>
> > Still tracking down the repeatable OOPS in uhci when an receive interrupt
> > transfer is aborted.
> >
> > I noticed that either the comment or the code is wrong about locking
> > ur
On Thu, 29 Jan 2004, Stephen Hemminger wrote:
> Still tracking down the repeatable OOPS in uhci when an receive interrupt
> transfer is aborted.
>
> I noticed that either the comment or the code is wrong about locking
> urb->lock. uhci_add_td_to_urb is *not* called with urb locked, but
> the co
Greg KH wrote:
On Fri, Dec 19, 2003 at 08:38:32PM +0100, David Mittelstädt wrote:
The nvidia module doesnt change anything. But am i right, if i asume,
the UHCI driver is the cause of the error?
No, it looks like it's a driver error. The host driver is returning
-EINVAL, which if you look in t
On Fri, Dec 19, 2003 at 08:38:32PM +0100, David Mittelstädt wrote:
>
> The nvidia module doesnt change anything. But am i right, if i asume,
> the UHCI driver is the cause of the error?
No, it looks like it's a driver error. The host driver is returning
-EINVAL, which if you look in the Documen
Greg KH wrote:
On Fri, Dec 19, 2003 at 05:42:37PM +0100, David Mittelstädt wrote:
ttusb_start_feed
usb 3-1: hcd_unlink_urb d654de80 fail -22
usb 3-1: hcd_unlink_urb d654dd80 fail -22
usb 3-1: hcd_unlink_urb d654dc80 fail -22
usb 3-1: hcd_unlink_urb d654db80 fail -22
These can usually be ju
On Fri, Dec 19, 2003 at 05:42:37PM +0100, David Mittelstädt wrote:
> ttusb_start_feed
> usb 3-1: hcd_unlink_urb d654de80 fail -22
> usb 3-1: hcd_unlink_urb d654dd80 fail -22
> usb 3-1: hcd_unlink_urb d654dc80 fail -22
> usb 3-1: hcd_unlink_urb d654db80 fail -22
These can usually be just ignored.
Matthias:
After re-reading the USB protocol description, it became clear that the
problem you've been having with lost interrupt packets really must be a
data toggle issue.
Here's how it works. In one of your bus traces you showed the device
sending a DATA1 token with interrupt data that the HCD
On Mon, 8 Dec 2003, Herbert Xu wrote:
> Hi:
>
> The UHCI driver only cleans up removed QH/TD/URB entries in the interrupt
> routine. This means that if the interrupts aren't working for whatever
> reason (in my case it's a bug in suspend/resume), these entries will never
> be cleaned up. This c
Alan,
> > There is only one device connected to the host and it has only control
> > endpoint. This is not to intermix different control messages, see there
> > are some 10 TDs containing data from one control message, If the UHCI is
> > scheduling them vertically, every second TD in the frame cau
On Mon, 27 Oct 2003, Manoj Sharma wrote:
> > Although you didn't say, it looks like you are running under Linux 2.4.
> > Try using 2.6 and see if that makes any difference. So far as I know, the
> > 2.6 version of the UHCI driver _will_ schedule other TDs in the same frame
> > as a NAKed data p
> On Fri, 24 Oct 2003, Manoj Sharma wrote:
>
> > I have a low speed display device with just a control endpoint. When some
> > large data is sent on the control endpoint, it is able to ACK for first
> > data packet in a frame, but it NAKs for the next data packet so the rest
> > of the frame goes w
On Fri, 24 Oct 2003, Manoj Sharma wrote:
> Hi,
>
> I have a low speed display device with just a control endpoint. When some
> large data is sent on the control endpoint, it is able to ACK for first
> data packet in a frame, but it NAKs for the next data packet so the rest
> of the frame goes wa
Hello,
The freezing no longer occurs in -test5-mm3.
Cheers,
Gorik
Alan Stern wrote:
> On Sun, 14 Sep 2003, Gorik Van Steenberge wrote:
>
>
>>Hello,
>>
>>
>>This problem occurs to me in -test4-mm5, -test4-mm6 and -test5. It does
>>not occur in -test4-mm4.
>>
>>When booting up my system freezes a
On Sun, 14 Sep 2003, Gorik Van Steenberge wrote:
> Hello,
>
>
> This problem occurs to me in -test4-mm5, -test4-mm6 and -test5. It does
> not occur in -test4-mm4.
>
> When booting up my system freezes and requires a reset after the
> following messages appear:
>
> hub 1-0:0: USB hub found
> hu
On Wed, 20 Aug 2003, Rob Miller wrote:
>
> I've done some further work on the problem I reported earlier involving
> the Sharp Zaurus and the uhci and usbnet modules. I'm currently running
> 2.4.22-rc2 with ACPI (20030813) and swsusp (1.1-rc5) patches. I can
> reproduce the problem with only uh
On Thu, 21 Aug 2003, Matthias Bruestle wrote:
> Mahlzeit
>
>
> On Thu, Aug 21, 2003 at 03:01:42PM -0400, Alan Stern wrote:
> > I'm stumped. And there is no open/close handling in UHCI. Could it be
> > that your program does something different before the first request and
> > between the fir
Mahlzeit
On Thu, Aug 21, 2003 at 03:01:42PM -0400, Alan Stern wrote:
> I'm stumped. And there is no open/close handling in UHCI. Could it be
> that your program does something different before the first request and
> between the first & second?
The program is run twice and does nothing diffe
On Wed, 20 Aug 2003, Matthias Bruestle wrote:
> > > I have not log here, which shows the first and second run. It works in 2.4
> > > and the driver does stop just the Int IN URB between runs, which is the same
> > > it does in 2.4 and therefore I don't think, that anything can go wrong with
> > >
Mahlzeit
On Wed, Aug 20, 2003 at 11:51:20AM -0400, Alan Stern wrote:
> On Tue, 19 Aug 2003, Matthias Bruestle wrote:
> > 1322: IN (>> 0x69) ADDR (0x3) EP (0x1)
> > 1323: DATA1 (<< 0x4b) DATA(1 02 04 00)
> > **
> >
> > This is the data I see with the US
On Tue, 19 Aug 2003, Matthias Bruestle wrote:
> Mahlzeit
>
>
> On Mon, Aug 18, 2003 at 03:38:01PM -0400, Alan Stern wrote:
> > Without knowing your situation it's hard to say anything definite. But
> > probably what's wrong is that your device isn't sending any data, and
> > that's why you're n
Mahlzeit
On Mon, Aug 18, 2003 at 03:38:01PM -0400, Alan Stern wrote:
> Without knowing your situation it's hard to say anything definite. But
> probably what's wrong is that your device isn't sending any data, and
> that's why you're not receiving any. You haven't said what Interrupt
> response
On Mon, 18 Aug 2003, Matthias Bruestle wrote:
> The Int IN is issued from the PC every 4 or 8 ms (can't remember). In an
> unsuccessful run, the device does allways response with NAK with one exception,
> where it sends data to the PC. I want to get this data, which I do correctly
> on the first r
On Mon, Aug 18, 2003 at 02:14:24PM -0400, Alan Stern wrote:
> On Mon, 18 Aug 2003, Matthias Bruestle wrote:
>
> > Somewhere inside a program run, when waiting for the interrupt data:
> >
> > HC status
> > usbcmd= 00c1 Maxp64 CF RS
> > usbstat =
> > usbint= 000f
On Mon, 18 Aug 2003, Matthias Bruestle wrote:
> Somewhere inside a program run, when waiting for the interrupt data:
>
> HC status
> usbcmd= 00c1 Maxp64 CF RS
> usbstat =
> usbint= 000f
> usbfrnum = (0)194
> flbaseadd = 03848194
> sof = 40
>
Mahlzeit
On Mon, Aug 18, 2003 at 09:53:26AM -0400, Alan Stern wrote:
> On Mon, 18 Aug 2003, Matthias Bruestle wrote:
> > I'm currently testing the cyberJack smart card reader under 2.6.0-t2
> > using a patched cyberJack driver (added locking) together with a UHCI
> > host controller.
> >
> > The
On Mon, 18 Aug 2003, Matthias Bruestle wrote:
> On Mon, Aug 18, 2003 at 09:53:26AM -0400, Alan Stern wrote:
> > It's curious that you see a USB interrupt transfer occur but the
> > controller does not end the request. Can you post the contents of
> > /proc/driver/uhci? That might have some clu
Mahlzeit
On Mon, Aug 18, 2003 at 09:53:26AM -0400, Alan Stern wrote:
> It's curious that you see a USB interrupt transfer occur but the
> controller does not end the request. Can you post the contents of
> /proc/driver/uhci? That might have some clues.
In a certain condition or just after lo
On Mon, 18 Aug 2003, Matthias Bruestle wrote:
> Mahlzeit
>
>
> I'm currently testing the cyberJack smart card reader under 2.6.0-t2
> using a patched cyberJack driver (added locking) together with a UHCI
> host controller.
>
> The problem is, that it works the first open/io/io/.../close sequenc
Alan Stern wrote:
Is there any reason why the status couldn't be changed if the low-level HC
driver detects that the hardware did manage to complete the transfer
before it could be dequeued? When that happens, why not report that the
URB succeeded and the unlink failed -- which is what really did
I'll make this short, since most of the issues in this thread involve
questions originally asked by Oliver that by now have been answered.
I'm not aware of any drivers that check to see whether a call to
usb_unlink_urb() failed because the URB had already completed. That makes
all this pretty t
Alan Stern wrote:
David:
I think you misunderstood some of what I wrote (and I'm probably
misunderstanding some of what you wrote too). A large part of the problem
seems to be that Oliver and I used "unlink" to mean "remove from the
hardware schedule before the hardware is through with it" -- may
David:
I think you misunderstood some of what I wrote (and I'm probably
misunderstanding some of what you wrote too). A large part of the problem
seems to be that Oliver and I used "unlink" to mean "remove from the
hardware schedule before the hardware is through with it" -- maybe you say
"dequeu
Alan Stern wrote:
On Fri, 18 Jul 2003, Oliver Neukum wrote:
It seems to me that you are racing against HC hardware.
Yes, certainly.
But not at that level, and URBs aren't hardware
data structures either.
You cannot unlink an URB that is being executed, can you?
With UHCI you can. What will
On Thu, 17 Jul 2003, Pete Zaitcev wrote:
> > Date: Thu, 17 Jul 2003 23:01:42 -0400 (EDT)
> > From: Alan Stern <[EMAIL PROTECTED]>
>
> > [...] But a properly-written driver won't
> > touch the URB _at all_ once it has been submitted until the completion
> > callback.
>
> I said the same. It cann
On Fri, 18 Jul 2003, Oliver Neukum wrote:
> It seems to me that you are racing against HC hardware.
Yes, certainly.
> You cannot unlink an URB that is being executed, can you?
With UHCI you can. What will happen is that the HCD will finish executing
the current TD, but on its next loop through
> This really makes no sense to me. There's a field, with
> an SMP-safe lock. The protocol between one layer and
> the next involves holding that lock before changing that
> field. And you're saying that's racey. How?
It seems to me that you are racing against HC hardware.
You cannot unlink a
Pete Zaitcev wrote:
Date: Thu, 17 Jul 2003 18:39:38 -0700
From: David Brownell <[EMAIL PROTECTED]>
So the completion uses an extra field to indicate that
urb was released by HC driver to the uppper level.
It's not an explicit field, it's an extra field.
This really makes no sense to me. There's
> Date: Thu, 17 Jul 2003 23:01:42 -0400 (EDT)
> From: Alan Stern <[EMAIL PROTECTED]>
> [...] But a properly-written driver won't
> touch the URB _at all_ once it has been submitted until the completion
> callback.
I said the same. It cannot look at the urb->status.
-- Pete
---
On Thu, 17 Jul 2003, Pete Zaitcev wrote:
> The urb->lock is situated in the same chunk of storage
> as the urb->status, so it only can protect the status if
> there is no hazard of deallocation of the urb. However, our
> API makes no such guarantees across the call to the ->complete.
> Therefore,
On Thu, 17 Jul 2003, David Brownell wrote:
> Oliver responded:
>
> > Right, it holds information about the status of the io operation the URB
> > describes. It doesn't hold information about the status of the URB itself,
> > such as unlinkable, ununlinkable, running completion handler, unlinked
>
> Date: Thu, 17 Jul 2003 18:39:38 -0700
> From: David Brownell <[EMAIL PROTECTED]>
> > So the completion uses an extra field to indicate that
> > urb was released by HC driver to the uppper level.
> > It's not an explicit field, it's an extra field.
>
> This really makes no sense to me. There's
However, the hcd glue layer uses urb->status == -EINPROGRESS as a test for
It shouldn't use it. The clean way to fix this issue is to have an explicit
state field.
But urb->status ** IS ** an explicit state field.
It holds the first fault experienced by that request. One of
those fault codes is
> From: David Brownell <[EMAIL PROTECTED]>
> Date: Thu, 17 Jul 2003 15:38:11 -0700
> >>A bug has turned up in the UHCI driver. Briefly, when an URB completes,
> >>uhci_transfer_result() doesn't store the status in urb->status but only in
> >>urbp->status. urb->status is set just before calling h
Am Freitag, 18. Juli 2003 00:38 schrieb David Brownell:
> Oliver Neukum wrote:
> > Am Donnerstag, 17. Juli 2003 23:09 schrieb Alan Stern:
> >
> >>Johannes:
> >>
> >>A bug has turned up in the UHCI driver. Briefly, when an URB completes,
> >>uhci_transfer_result() doesn't store the status in urb->
Oliver Neukum wrote:
Am Donnerstag, 17. Juli 2003 23:09 schrieb Alan Stern:
Johannes:
A bug has turned up in the UHCI driver. Briefly, when an URB completes,
uhci_transfer_result() doesn't store the status in urb->status but only in
urbp->status. urb->status is set just before calling hcd_giveb
Am Donnerstag, 17. Juli 2003 23:09 schrieb Alan Stern:
> Johannes:
>
> A bug has turned up in the UHCI driver. Briefly, when an URB completes,
> uhci_transfer_result() doesn't store the status in urb->status but only in
> urbp->status. urb->status is set just before calling hcd_giveback_urb().
>
hi there
i'm working on the same project- usb support for one BIOS, so i'm
writing in ASM.
i've got same errors sometimes when tried to send TD's with wron
device-speed bit set. are you sure, your device isn't low-speed?
also- try to set "configured" bit in USBCMD
I didn't set this bit because
On Wed, Jan 29, 2003, Oliver Kurth <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 29, 2003 at 11:44:16AM -0500, Johannes Erdfelt wrote:
> > On Wed, Jan 29, 2003, Oliver Kurth <[EMAIL PROTECTED]> wrote:
> > > With my at76c503 driver, I get this error:
>
> > > This happens just after the usbdfu module (in
Sorry, this should go to the list as well (I just sent to Johannes Erdfelt):
On Wed, Jan 29, 2003 at 07:31:31PM +0100, okurth wrote:
> On Wed, Jan 29, 2003 at 11:44:16AM -0500, Johannes Erdfelt wrote:
> > On Wed, Jan 29, 2003, Oliver Kurth <[EMAIL PROTECTED]> wrote:
> > > With my at76c503 driver,
On Wed, Jan 29, 2003, Oliver Kurth <[EMAIL PROTECTED]> wrote:
> With my at76c503 driver, I get this error:
>
> usb.c: usbdfu driver claimed interface d917c740
> usb.c: registered new driver at76c503
> at76c503.c: driver registered
> uhci.c: uhci_result_control() failed with status 44
> [df5a70
The problem density for the cyberjack seams to depend on used PC hardware.
Known systems have a timeout desity of 1 per 5 minutes, another 1 per
1 hour. The P4 I tested today had no problem in 3 hours.
So are there known unreliabilites/bugs regarding USB host controllers?
Someone posted some VI
You sholud probably try a more modern kernel, that one is a year and a
half old.
On Sat, 13 Jul 2002, Avinash natarajan wrote:
> Hi...
> i've written a driver for USB modem.it uses bulk transfers.I am facing a problem
>when i stress
> it with UHCI host controller.when i run multuiple ftp s
Johannes Erdfelt wrote:
>
> On Mon, Jul 01, 2002, Clemens Ladisch <[EMAIL PROTECTED]> wrote:
> > The submit call before the unlink will toggle the D0/D1 bit in
> > dev->toggle[]. The call after the unlink will then use the toggled bit
> > although the TD of the unlinked URB hasn't been completed
On Mon, Jul 01, 2002, Clemens Ladisch <[EMAIL PROTECTED]> wrote:
> In Linux 2.4.18 with usb-uhci (v1.275), the following code will create
> a TD with wrong toggle bit:
>
> urb->pipe = rcvbulkpipe( ... );
> urb->dev = dev;
> usb_submit_urb(urb);
>
> /* optionally:
Pedro Lopez-Cabanillas wrote:
> El Lun 01 Jul 2002 19:24, Clemens Ladisch escribió:
> > The submit call before the unlink will toggle the D0/D1 bit in
> > dev->toggle[]. The call after the unlink will then use the toggled bit
> > although the TD of the unlinked URB hasn't been completed successful
David Brownell wrote:
> > The submit call before the unlink will toggle the D0/D1 bit in
> > dev->toggle[]. The call after the unlink will then use the toggled bit
> > although the TD of the unlinked URB hasn't been completed successfully.
> > Consequently, the next packet to be received will be l
> The submit call before the unlink will toggle the D0/D1 bit in
> dev->toggle[]. The call after the unlink will then use the toggled bit
> although the TD of the unlinked URB hasn't been completed successfully.
> Consequently, the next packet to be received will be lost.
Presumably that bug is s
El Lun 01 Jul 2002 19:24, Clemens Ladisch escribió:
> In Linux 2.4.18 with usb-uhci (v1.275), the following code will create
> a TD with wrong toggle bit:
>
> urb->pipe = rcvbulkpipe( ... );
> urb->dev = dev;
> usb_submit_urb(urb);
>
> /* optionally: receive some da
On Thu, Jun 20, 2002 at 04:22:37PM -0400, Dan Streetman wrote:
> That'd be great! If you can point out which changes you suspect I'll
> try them out. I'm still suspicious though, since it's happening in
> both uhci and usb-uhci...I didn't think they shared queueing code...?
Maybe it's something
On Thu, Jun 20, 2002, Dan Streetman <[EMAIL PROTECTED]> wrote:
>
> On Thu, 20 Jun 2002, Johannes Erdfelt wrote:
>
> >Ok, I think you can probably backport the necessary fixes to get it to
> >work.
> >
> >The PCI DMA stuff is pretty easy to seperate out logically from the
> >other changes.
> >
>
On Thu, 20 Jun 2002, Johannes Erdfelt wrote:
>Ok, I think you can probably backport the necessary fixes to get it to
>work.
>
>The PCI DMA stuff is pretty easy to seperate out logically from the
>other changes.
>
>I'll have to take a look at the diff.
That'd be great! If you can point out whic
On Thu, Jun 20, 2002, Dan Streetman <[EMAIL PROTECTED]> wrote:
>
> On Thu, 20 Jun 2002, Johannes Erdfelt wrote:
>
> >Well, 2.4.2 is known buggy. Why do you have to use that? Can you just
> >use the driver from a more recent kernel?
>
> Testing, support, and a binary module...so I'm stuck at 2.4
On Thu, 20 Jun 2002, Johannes Erdfelt wrote:
>Well, 2.4.2 is known buggy. Why do you have to use that? Can you just
>use the driver from a more recent kernel?
Testing, support, and a binary module...so I'm stuck at 2.4.2-2. I
can't backport a newer uhci.o or usb-uhci.o since DMA, pci_pool, etc
On Thu, Jun 20, 2002, Dan Streetman <[EMAIL PROTECTED]> wrote:
> Ok, I'm completely stumped on a problem and thought I'd see if anyone
> has seen this or might have an idea why it's happening.
>
> I (unfortunately) have to use an older kernel (2.4.2-2, i.e. Redhat
> 7.1) and on both UHCI drivers
On Mon, May 13, 2002, Nemosoft Unv. <[EMAIL PROTECTED]> wrote:
> I tried to jump to kernel 2.5.15 today, but with not much success... After
> the usual boot I load the USB modules. The attached webcams are detected, but
> when I try to get a picture, the program hangs. I can ^C it, but a second
1 - 100 of 133 matches
Mail list logo
