hi,
one of the changes introduced from 2.5.2 to 2.5.3 in uhci.c broke
the ipaq usb driver. I'm not very sure what's happening, but it seems to
"lose" packets. I've narrowed it down to the following patchlet:
--- /usr/src/linux-2.5/drivers/usb/uhci.c Tue Jan 15 17:40:16 2002
+++ usb-
On Sun, Feb 03, 2002 at 03:42:19PM +0100, Oliver Neukum wrote:
> Hi,
>
> this is a tested patch which introduces a gfp field to usb_submit_urb
> and usb_alloc_urb. The changes to hcd.c are incomplete. They just
> allow it to compile. I've tested on UP and OHCI.
Hm, let's do just one thing at a t
> > > >> int usb_revoke_urb_sync(struct urb *urb);
> > > >> int usb_revoke_urb_async(struct urb *urb);
> > > >
> > > >Are you trying to split up the current usb_unlink_urb() case? Do you
> > > >think this is really necessary?
> >
> > I'm not sure why it'd be necessary. The API might be a
> > smi
> > For your case (c/b URBs queued to one endpoint) I think it must be.
> > After all, it's a queue ... queue jumpers not permitted! :)
>
> Right, that's exactly the point. Do I understand you correctly, you are
> saying USB_QUEUE_BULK does not only deal with urbs being queued to the
> schedule
GFP_* is excessively cryptic, and it doesn't account for
the slightly more meaningful SLAB_* synonyms ... :)
Actually, since td_alloc() is always SLAB_ATOMIC
(artifact of locking structure) it won't need to change
in these patches -- though if that locking ever gets
improved, that should change.
What's to complain about? :)
Yes, that looks like it does the right thing.
- Dave
- Original Message -
From: "Oliver Neukum" <[EMAIL PROTECTED]>
To: "David Brownell" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Sunday, February 03, 2002 3:11 PM
Subject: Re: [linu
On Sunday 03 February 2002 20:46, David Brownell wrote:
> > >> int usb_revoke_urb_sync(struct urb *urb);
> > >> int usb_revoke_urb_async(struct urb *urb);
> > >
> > >Are you trying to split up the current usb_unlink_urb() case? Do you
> > >think this is really necessary?
>
> I'm not sure why it'd
On Sunday 03 February 2002 20:29, David Brownell wrote:
> > For this case, I'd argue that a driver shouldn't be allocating a urb
> > within an interrupt at all :)
>
> I'll argue otherwise ... and be glad that in this case Oliver
> and I agree, and that he's already started 2.5 API fixes! :)
It d
On Sunday 03 February 2002 20:17, David Brownell wrote:
> Roman --
>
> > hm, I think the allocation of the TDs has to be changed too.
>
> Yes. And I'd rather see a more mnemonic name than "gfp",
> perhaps "mem_flags" since that's their role.
Doesn't gfp remind you of GFP_KERNEL, GFP_ATOMIC ... ?
On Sat, 2 Feb 2002, David Brownell wrote:
> > My concern is what (if any) assumptions a driver might take about the
> > order in which the corresponding completion callbacks are invoked. Would
> > it be valid to rely on a fifo-like operation, i.e. the urb which was
> > submitted first get complet
On Sunday 03 February 2002 20:03, David Brownell wrote:
> This is missing one hcd.c update ... hcd_submit_urb()
> should be taking a "mem_flags" argument. Then, delete
> the FIXME comment above the current mem_flags init,
> and the mem_flags init itself.
>
> Passing mem_flags (like GFP_NOIO) down
On Sunday 03 February 2002 18:19, Roman Weissgaerber wrote:
> Hi,
>
> hm, I think the allocation of the TDs has to be changed too.
I am overlooking something. Could you point me at a function ?
Regards
Oliver
___
[EMAIL PROTECT
The official specification is available for purchase from the ANSI
standards group.
Matthew Dharm
On Sun, Feb 03, 2002 at 03:51:57PM -0200, Raphael Derosso Pereira - DephiNit wrote:
> On Sat 02 Feb 2002 20:09, Matthew Dharm wrote:
> > The string you are asking about is the SCSI-II CCS definition
> >> int usb_revoke_urb_sync(struct urb *urb);
> >> int usb_revoke_urb_async(struct urb *urb);
> >
> >Are you trying to split up the current usb_unlink_urb() case? Do you
> >think this is really necessary?
I'm not sure why it'd be necessary. The API might be a
smidgeon cleaner (I prefer to avoi
> For this case, I'd argue that a driver shouldn't be allocating a urb
> within an interrupt at all :)
I'll argue otherwise ... and be glad that in this case Oliver
and I agree, and that he's already started 2.5 API fixes! :)
- Dave
___
[EMAIL PRO
Roman --
> hm, I think the allocation of the TDs has to be changed too.
Yes. And I'd rather see a more mnemonic name than "gfp",
perhaps "mem_flags" since that's their role.
- Dave
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
This is missing one hcd.c update ... hcd_submit_urb()
should be taking a "mem_flags" argument. Then, delete
the FIXME comment above the current mem_flags init,
and the mem_flags init itself.
Passing mem_flags (like GFP_NOIO) down through the
HCD layer (to ehci-hcd and ohci-hcd) will then work as
On Sat 02 Feb 2002 20:09, Matthew Dharm wrote:
> The string you are asking about is the SCSI-II CCS definition of that
> particular set of key, ASC, and ASCQ values returned by the REQUEST_SENSE
> command.
Where can I find this definition?
> Generally, a device reports that as it's spinning up.
Hi,
hm, I think the allocation of the TDs has to be changed too.
regards
Roman
Oliver Neukum wrote:
>Hi,
>
>this is for usb-ohci.c
>
> Regards
> Oliver
>
>--- drivers/usb/usb-ohci.c.pre Sun Feb 3 10:28:31 2002
>+++ drivers/usb/usb-ohci.c Sun Feb 3 10:39:56 2002
>@@ -
-- Forwarded Message --
Subject: Mail delivery failed: returning message to sender
Date: Sun, 03 Feb 2002 17:23:57 +0100
From: Mail Delivery System <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
This message was created automatically by mail delivery software (Exim).
A message th
> > unsigned long count, int noblock) @@ -1633,6 +1630,7 @@
> > }
> >
> > static struct usb_driver stv680_driver = {
> > + owner: THIS_MODULE,
> > name: "stv680",
> > probe: stv680_probe,
> > disconnect: stv680_disconnect,
> >
This
>
> Message: 13
> From: [EMAIL PROTECTED] (Oliver Neukum)
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Date: Sun, 3 Feb 2002 00:07:01 +0100
> Cc: [EMAIL PROTECTED]
> Subject: [linux-usb-devel] 2.5 module usage count for stv680
>
> Hi,
>
> this cleans up module usage counting for stv6
On Sunday 03 February 2002 16:06, Vojtech Pavlik wrote:
> On Sun, Feb 03, 2002 at 03:47:23PM +0100, Oliver Neukum wrote:
> > Hi,
> >
> > this makes the changes to the hid driver.
> > My mouse works with this.
> > I am not sure whether the allocations need to be atomic.
> >
> > Regards
> >
On Sun, Feb 03, 2002 at 03:47:23PM +0100, Oliver Neukum wrote:
> Hi,
>
> this makes the changes to the hid driver.
> My mouse works with this.
> I am not sure whether the allocations need to be atomic.
>
> Regards
> Oliver
What kernel version?
>
> --- drivers/usb/hid-core
Here it is.
Regards
Oliver
--- drivers/usb/hpusbscsi.c.pre Sun Feb 3 15:49:30 2002
+++ drivers/usb/hpusbscsi.c Sun Feb 3 15:51:49 2002
@@ -56,12 +56,12 @@
return NULL;
DEBUG ("Allocated memory\n");
memset (new, 0, sizeof (struct hpusb
Hi,
this makes the changes to the hid driver.
My mouse works with this.
I am not sure whether the allocations need to be atomic.
Regards
Oliver
--- drivers/usb/hid-core.c.alt Sun Feb 3 13:49:05 2002
+++ drivers/usb/hid-core.c Sun Feb 3 13:51:46 2002
@@ -992,7 +99
Hi,
this is for usb-ohci.c
Regards
Oliver
--- drivers/usb/usb-ohci.c.pre Sun Feb 3 10:28:31 2002
+++ drivers/usb/usb-ohci.c Sun Feb 3 10:39:56 2002
@@ -532,7 +532,7 @@
/* get a transfer request */
-static int sohci_submit_urb (struct urb * urb)
+static int
--- drivers/usb/microtek.c.alt Sun Feb 3 10:41:01 2002
+++ drivers/usb/microtek.c Sun Feb 3 10:43:08 2002
@@ -499,7 +499,7 @@
transfer->status = 0;
- res = usb_submit_urb( transfer );
+ res = usb_submit_urb( transfer, GFP_ATOMIC );
if ( unlikely(res) ) {
Hi,
this is a tested patch which introduces a gfp field to usb_submit_urb
and usb_alloc_urb. The changes to hcd.c are incomplete. They just
allow it to compile. I've tested on UP and OHCI.
Regards
Oliver
--- drivers/usb/hub.c.alt Fri Feb 1 16:41:16 2002
+++ driver
This converts microtek.c
Regards
Oliver
--- drivers/usb/microtek.c.alt Sun Feb 3 10:41:01 2002
+++ drivers/usb/microtek.c Sun Feb 3 10:43:08 2002
@@ -499,7 +499,7 @@
transfer->status = 0;
- res = usb_submit_urb( transfer );
+ res = usb_submi
This converts usb-ohci.
Regards
Oliver
--- drivers/usb/usb-ohci.c.pre Sun Feb 3 10:28:31 2002
+++ drivers/usb/usb-ohci.c Sun Feb 3 10:39:56 2002
@@ -532,7 +532,7 @@
/* get a transfer request */
-static int sohci_submit_urb (struct urb * urb)
+static int sohc
Hi,
this is just fyi. It has not enough functionality to work for me, but it compiles.
This is the patchset against core functions.
Regards
Oliver
--- drivers/usb/hub.c.alt Fri Feb 1 16:41:16 2002
+++ drivers/usb/hub.c Sun Feb 3 10:58:01 2002
@@ -303,7 +303,7 @@
On Sun, Feb 03, 2002 at 10:16:29AM +0100, Oliver Neukum wrote:
>
> >> > For this case, I'd argue that a driver shouldn't be allocating a urb
> >> > within an interrupt at all :)
> >>
> >> In this case that can be done. But it's not an answer to all such problems.
> >
> >Why not? Are there other
On Sun, Feb 03, 2002 at 10:08:03AM +0100, Oliver Neukum wrote:
> Hi,
>
> this fixes
> a memory allocation bug,
> an SMP deadlock,
> synchronous unlink with a spinlock held,
> a memory leak without firmware,
> freeing urbs without unlinking
>
> It's against 2.4.18-pre7.
Looks good, applied.
gre
Hi,
Here's a patch against 2.5.3 for the USB ohci-hcd driver that does the
following:
- doesn't assume CONFIG_DEBUG_SLAB
- unlink from interrupt completions now work
- doesn't force debugging on
- updated copyright / license statements
- slightly smaller o
On Sun, Feb 03, 2002 at 01:00:08AM +0100, Oliver Neukum wrote:
> On Sunday 03 February 2002 00:51, Oliver Neukum wrote:
> > Hi,
> >
> > catc seems to suffer from the same race as pegasus.
> > timeout unlinks asynchronously, but xmit does not check.
>
> Sorry. The upper layer protects you. Please
Hi,
Here's a patch against 2.5.3 for the USB core that fixes a possible
initialization bug for some platforms when allocating a new usb, and
changes the warning level on a message (it isn't an error.) This patch
was done by Oliver Neukum and David Brownell.
thanks,
greg k-h
diff -Nru a/driv
Hi,
Here's a patch against 2.5.3 for the USB vicam driver that removes the
use of interruptible_sleep_on() in the driver. This patch was done by
Oliver Neukum.
thanks,
greg k-h
diff -Nru a/drivers/usb/vicam.c b/drivers/usb/vicam.c
--- a/drivers/usb/vicam.c
Hi,
Here's a patch against 2.5.3 for the USB stv680 driver that fixes two
bugs in the existing driver. This patch was done by Kevin Sisson.
thanks,
greg k-h
diff -Nru a/drivers/usb/stv680.c b/drivers/usb/stv680.c
--- a/drivers/usb/stv680.c Sun Feb 3 00:53:04 2002
+++ b/drivers/usb/stv
Hi,
Here's a patch against 2.5.3 for the USB pegasus driver that does the
following:
- fixes __FUNCTION__ warnings on gcc-3.0.3 and up
- added 3 more devices
- fixed memory leak
This patch was done by Petko Manolov and Oliver Neukum.
thanks,
greg k-h
Hi,
Here's a patch against 2.5.3 for the USB kaweth driver that does the
following:
- removes SMP deadlock
- removes nfs deadlock
- fixes a memory leak when the firmware is not loaded.
- few other minor cleanups.
This patch was done by Oliver Neukum.
thanks,
gr
Hi,
Here's a patch against 2.5.3 for the USB printer driver that does the
following:
- removes the races inherent in sleep_on
- uses 2.5 style of module usage counting
- kills a lockup on failure of usb_submit_urb
This patch was done by Oliver Neukum.
thanks,
greg k-h
Hi,
Here's a patch against 2.5.3 that updates the Config.help entries for
the USB microtek and hpusbscsi drivers.
This patch was done by Oliver Neukum.
thanks,
greg k-h
diff -Nru a/drivers/usb/Config.help b/drivers/usb/Config.help
--- a/drivers/usb/Config.help Sun Feb 3 00:53:03 2002
++
Hi,
Here's a patch against 2.5.3 that changes the maintainer of the USB
Kawasaki driver to Oliver Neukum.
thanks,
greg k-h
diff -Nru a/MAINTAINERS b/MAINTAINERS
--- a/MAINTAINERS Sun Feb 3 00:53:03 2002
+++ b/MAINTAINERS Sun Feb 3 00:53:03 2002
@@ -1581,8 +1581,8 @@
S: M
>> > For this case, I'd argue that a driver shouldn't be allocating a urb
>> > within an interrupt at all :)
>>
>> In this case that can be done. But it's not an answer to all such problems.
>
>Why not? Are there other times we need to allocate an urb in this
>manner (where we can't call schedu
Hi,
this fixes
a memory allocation bug,
an SMP deadlock,
synchronous unlink with a spinlock held,
a memory leak without firmware,
freeing urbs without unlinking
It's against 2.4.18-pre7.
Regards
Oliver
--- kaweth.c.altSun Feb 3 09:22:52 2002
+++ kaweth.cSun
On Sun, Feb 03, 2002 at 09:20:10AM +0100, Oliver Neukum wrote:
>
> > For this case, I'd argue that a driver shouldn't be allocating a urb
> > within an interrupt at all :)
>
> In this case that can be done. But it's not an answer to all such problems.
Why not? Are there other times we need to
> For this case, I'd argue that a driver shouldn't be allocating a urb
> within an interrupt at all :)
In this case that can be done. But it's not an answer to all such problems.
[..]
> Now the comments about the HCD drivers needing to know about this, and
> their API being changed, I understan
48 matches
Mail list logo
