> > Hi Dave, my main gripe was that usb_unlink_urb seems quite fragile.
>
> I can't see that at all.
Hi Dave,
> > Thinking more about it, what I really want is a function that cancels
> > usb_submit_urb (lets call it usb_retire_urb): that reliably removes an
> > urb from the USB subsystem. I tho
> I've still got a bunch of messages in my inbox, maybe one of them
> will persuade me that (2) needs solving. I can't yet see why though;
> particularly the "... and its handler has exited" part, since that's
> easily guaranteed by calling synchronize_kernel().
Excellent remark, but only applica
On Tue, Jan 28, 2003 at 08:18:03PM -0800, David Brownell wrote:
>
> >>block = kmalloc(EXT_FW_BLOCK_SIZE, GFP_KERNEL|GFP_DMA);
> >>if(block == NULL) return -ENOMEM;
> >>
> >>Wrong. Use GFP_KERNEL only.
> >
> >
> >Alright. I just wanted to be sure it's DMA.
>
> And why is that? Remember th
Hi,
Then what would you return to a driver that passed something like
a null or otherwise garbage pointer, instead of the correct urb?
BUG?
If every subsystem used BUG() instead of the recovery philosophy
I was describing, where would we get multi-year uptimes?
Check out recent discussions
Duncan Sands wrote:
I've still got a bunch of messages in my inbox, maybe one of them
will persuade me that (2) needs solving. I can't yet see why though;
particularly the "... and its handler has exited" part, since that's
easily guaranteed by calling synchronize_kernel().
Excellent remark, b
Hi,
Calls to usb_unlink_urb() while the completion handler is running
won't do anything until the handler has returned.
It still violates the API spec: there's no completion callback with
an unlink status (-ECONNRESET, -ENOENT). It shouldn't masquerade as
a call that behaved correctly (unli
Greg: I hope this will deal with your objection. It applies on top of all the
previous patches (including the one that puts the sk_buff on the stack in
the first place). If you like, I can rediff them.
speedtouch: don't allocate a struct sk_buff on the stack anymore:
use two pointers and a t
On Tue, 28 Jan 2003, David Brownell wrote:
> Oliver Neukum wrote:
> >>>-EBUSY: usb_retire_urb would wait until the completion handler has
> >>>finished;
> >>
> >>Completely impossible for asynchronous unlinks. They don't wait.
> >>And not necessary for drivers that are already written so the
On Wed, 29 Jan 2003, David Brownell wrote:
> > Actually, I was talking about the mythical usb_retire_urb here (and
> > everywhere) which would of course be synchronous. By the way,
> > maybe one of the reasons for the whole "Discussing the URB lifecycle, again"
> > disagreements over usb_unlink_u
speedtouch: add a new encoding function, atmsar_encode. Calling it amounts to doing
atmsar_encode_aal5 followed by atmsar_encode_rawcell in one fell swoop. It
eliminates
the need for intermediate buffers and reduces memory movement. The following patches
use it to simplify the send logi
On Wed, 29 Jan 2003, David Brownell wrote:
> > I don't think I understand your objection. Are you saying that if a
> > driver calls usb_unlink_urb() while the urb's completion handler is
> > running, then back when the handler was originally called the value of
> > urb->status wasn't -ECONNRESET
Hello!
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
[df5a70c0] link (1f5a7062) element (19127030)
Element != First TD
0: [d9
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
On Wed, 29 Jan 2003, Heinrich du Toit wrote:
| Acording to www.kernel.org bugzilla is only for kernel 2.5.x
That's correct.
| So I guess there's not much hope for me. :-(
|
| Jon Smirl wrote:
|
| >Try putting it into the kernel bug tracker:
| >http://bugzilla.kernel.org/
| >
| >Then post a refer
Hi,
Even worse is the fact that -EBUSY has a dual meaning: along with
indicating that the urb has already started to finish up, it also can mean
that the urb was not active in the first place -- i.e., had already
completed by the time usb_unlink_urb was called, or had never been
submitted at
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,
Hello everyone,
This is the first patch I ever try to submit, so please forgive me if I'm
doing something terribly wrong. :-) Anyway, I have a 128 MB USB Memory Key
by IBM, and without my patch it doesn't work at all. It was telling about
"usb_control/bulk_msg: timeout" all the time.
Then I did f
On Wed, 29 Jan 2003, David Brownell wrote:
> Hi,
>
> > Even worse is the fact that -EBUSY has a dual meaning: along with
> > indicating that the urb has already started to finish up, it also can mean
> > that the urb was not active in the first place -- i.e., had already
> > completed by the t
> From: "Janne Pikkarainen" <[EMAIL PROTECTED]>
> Date: Wed, 29 Jan 2003 21:19:43 +0200 (EET)
> This is the first patch I ever try to submit, so please forgive me if I'm
> doing something terribly wrong. :-) Anyway, I have a 128 MB USB Memory Key
> by IBM, and without my patch it doesn't work at a
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
>> +UNUSUAL_DEV( 0x0a16, 0x9989, 0x0100, 0x0100,
>> + "IBM",
>> + "IBM USB Memory Key",
>> + US_SC_SCSI, US_PR_BULK, NULL,
>> + US_FL_FIX_INQUIRY ),
>
>> bInterfaceClass 8 Mass Storage
>> bInterfaceSubClass 6 SCSI
>>
It's a case of the 2.4 SCSI code issuing INQUIRY commands to devices that
they don't like. This is fixed in the SCSI layer for 2.5
Matt
On Wed, Jan 29, 2003 at 02:45:01PM -0500, Pete Zaitcev wrote:
> > From: "Janne Pikkarainen" <[EMAIL PROTECTED]>
> > Date: Wed, 29 Jan 2003 21:19:43 +0200 (EET)
On Wed, 29 Jan 2003, Janne Pikkarainen wrote:
> >> +UNUSUAL_DEV( 0x0a16, 0x9989, 0x0100, 0x0100,
> >> + "IBM",
> >> + "IBM USB Memory Key",
> >> + US_SC_SCSI, US_PR_BULK, NULL,
> >> + US_FL_FIX_INQUIRY ),
> >
> >> bInterfaceClass
On Wed, Jan 29, 2003 at 08:40:43AM +0100, Duncan Sands wrote:
> > Ick, no, I will not take this patch, sorry. That's just too much data
> > on the stack. Try using skb_clone() or friends if you need a temp copy
> > of the skb.
>
> Hi Greg, I guess I didn't make it clear that this was a temporary
On Sat, Jan 25, 2003 at 11:59:26AM +0100, Vojtech Pavlik wrote:
> On Wed, Jan 22, 2003 at 04:50:00PM -0500, John Homppi wrote:
> > See my prior message for background.
> >
> > Additions for hid-core.c blacklist.
> > Diffs for kernel 2.4.20 and 2.5.54 follow.
> >
> > Thanks to all for their assist
On Sat, Jan 25, 2003 at 02:55:22PM +0100, Vojtech Pavlik wrote:
> Hi!
>
> Normally the CDC ACM devices have an subclass of 0, and the ACM subclass is
> only applied to their first interface. But some have the subclass set on
> the device itself, namely Motorola mobile phones. This patch takes thos
On Sat, Jan 25, 2003 at 11:59:26AM +0100, Vojtech Pavlik wrote:
> On Wed, Jan 22, 2003 at 04:50:00PM -0500, John Homppi wrote:
> > See my prior message for background.
> >
> > Additions for hid-core.c blacklist.
> > Diffs for kernel 2.4.20 and 2.5.54 follow.
> >
> > Thanks to all for their assist
On Mon, Jan 27, 2003 at 06:32:11PM -0800, Matthew Dharm wrote:
> They should go on top of what I sent you before.
>
> Didn't you get the patch I sent which should make things work for you?
Oops, forgot that one. Ok, this is better, but I still have problems.
> You need (in order):
> (o) clean 2
On Fri, Jan 24, 2003 at 02:11:10PM +0100, Steve Purcell wrote:
> If there is a more official channel through which to submit patches, I am not
> aware of it, so I hope nobody will mind if I post this patch here.
Try sending this to the usb-storage author and maintainer, he's the best
person to te
On Mon, Jan 20, 2003 at 08:14:23PM +0100, Oliver Neukum wrote:
> Am Montag, 20. Januar 2003 19:21 schrieb David Brownell:
> >
> > - Someone just emailed me for help on that classic, and still
> > unresolved, issue of associating a device from 'lsusb' (etc)
> > with the right /dev/... prin
On Wed, Jan 29, 2003 at 03:32:35PM -0800, Greg KH wrote:
> After this, my device does not oops the box anymore, but the partition
> table can't be read, so I can't mount the device. Backing the patches
> out fixes everything.
Odd... can you dd from the device?
This isn't a failure mode I'm seei
31 matches
Mail list logo
