I just sent a patch to Linus to fix this. Here it is for your testing:
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#
Hi Matthew,
Using 2.5.41 or 2.5.42, I'm getting lots of these messages:
midway kernel: drivers/usb/core/hcd.c: giveback urb f75c1400 status -32 len 0
midway kernel: USB len=128, request_bufflen=24
plus dump_stack() output.
I tracked it down to usb/storage/transport.c::usb_stor_transfer_length()
This patch generalizes the transfer functions. This is in preparation for
consolidating all sub-drivers to use a common set of functions.
Oh, and this patch makes the residue field be initialized. Making this the
correct value is still on the TODO list.
Greg, please apply.
Matt
# This is a Bi
This patch makes all sub-drivers use the same data-moving functions. It
also eliminates the duplicate functions from raw_bulk.c
Greg, please apply.
Matt
# This is a BitKeeper generated patch for the following project:
# Project Name: greg k-h's linux 2.5 USB kernel tree
# This patch format is i
This patch fixes the bulk transport data stage to use the correct pipe for
data exchange, based on the transfer direction.
Greg, please apply.
Matt
# This is a BitKeeper generated patch for the following project:
# Project Name: greg k-h's linux 2.5 USB kernel tree
# This patch format is intende
This patch to usb-storage makes all pipe values used by the driver an
unsigned int (like they should be), and caches them in the device data
structure.
Greg, please apply.
Matt
# This is a BitKeeper generated patch for the following project:
# Project Name: greg k-h's linux 2.5 USB kernel tree
#
On Fri, Oct 11, 2002 at 09:56:02PM +0200, Oliver Neukum wrote:
> + * Caller must make sure that disconnect processing waits for this to
> complete
Line wrap, can't apply :)
> + usb_reap_interfaces(dev); /* get rid of all interfaces */
> +
> + if ((ret = usb_physical_set_conf(dev, configu
On Sat, Oct 12, 2002 at 04:14:38PM -0400, Dan Streetman wrote:
>
> Ok, I'm breaking up the big patch into smaller ones, at least for the
> simple(r) stuff.
I'll wait for Johannes to ack any of these before applying them.
> This one fixes a bug where different names were being used for creation
On Sat, Oct 12, 2002 at 02:07:03PM +0300, Kari Hameenaho wrote:
>
> With this patch using Epson 1240U works for me in both USB2.0 (NEC) and
> USB1.1 (AMD OCHI). I am not using CONFIG_USB_DYNAMIC_MINORS
> or devfs.
>
> Now the scn_minor is not manged at all, separate scn_index variable used.
>
On Sat, 2002-10-12 at 01:09, Stephan Feder wrote:
> Asking for more
> than one scanline (= one logical transfer) in one call to read_scanner
> _must_ fail (as you found out). So simply fix your application and
> everything should work fine.
I shall notify the author of the app.
It still seems th
Johannes Erdfelt wrote:
>
> On Fri, Oct 11, 2002, Dan Streetman <[EMAIL PROTECTED]> wrote:
> > On Fri, 11 Oct 2002, Johannes Erdfelt wrote:
> > >On Fri, Oct 11, 2002, Dan Streetman <[EMAIL PROTECTED]> wrote:
...
> > >> -changed lowspeed control TDs from depth to breadth.
> > >
> > >Why for? This
Pieter Nagel wrote:
>
> On Sat, 2002-10-05 at 09:26, Stephan Feder wrote:
>
> > The scanner module does blocking IO. You cannot change it to any kind of
> > nonblocking IO without breaking applications.
>
> The intent of the patch was not to do nonblocking IO. The issue is that,
> as man read(2)
Dan Streetman wrote:
...
> diff -ur usb-2.5/drivers/usb/host/uhci-hcd.c linux/drivers/usb/host/uhci-hcd.c
> --- usb-2.5/drivers/usb/host/uhci-hcd.c Fri Oct 11 16:52:49 2002
> +++ linux/drivers/usb/host/uhci-hcd.c Fri Oct 11 16:59:53 2002
...
> @@ -545,9 +529,16 @@
> urbp->qh->link = eurbp
Pieter Nagel wrote:
>
> Here is the syslog of what happens (produced with scanner.c compiled
> with DEBUG on):
>
> Oct 1 01:31:35 basilisk kernel: scanner.c: read stats(0): result:0 this_read:32768
>partial:22960 count:45920
> Oct 1 01:31:35 basilisk kernel: usb-uhci.c: interrupt, status 3, fr
I have to agree with JE, there should be a common API for drivers to
reserve bandwidth on a per-ep basis, and then any URBs submitted are
guaranteed not to fail from a shortage of bandwidth.
However, I don't think BW can be calculated effectively by common code, it
is dependent on the HCD.
Ok, I'm a moron - the first patch I sent was corrupted - when I diff'ed
the trees, I sent the patch through "grep -v Only" to remove Only in ...
lines. I forgot that would remove source code lines with Only also!
anyway, this is the first patch, that really applies this time. Tested it
myse
Oliver Neukum wrote:
Hi,
this is a real case of mail interleave. I've just sent a new version to the
list. Could you look through that, too ?
Later.
The stuff below should only be available to other usbcore
components; no device driver should ever call this stuff.
It belongs in "hcd.h" not "
So it's a Good Thing that Linux allocates bandwidth only on demand ... :)
You mean at open() time right? :)
That's the driver's business. If they post URBs on open, that
would be how it works. If they post URBs on read/write, it'd be
a bit different.
It needs to be as early as possible
a) It depends on queuing
b) It doesn't reserve the bandwidth
Each in itself make it unacceptable.
On the other hand, neither of those is true either. Which is
part of why I don't see any problem ... :)
With a move to non automagic resubmit, the HCD *MUST* release any
bandwidth when it's done
On Fri, Oct 11, 2002, Johannes Erdfelt <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 11, 2002, Dan Streetman <[EMAIL PROTECTED]> wrote:
> > On Fri, 11 Oct 2002, Johannes Erdfelt wrote:
> > >On Fri, Oct 11, 2002, Dan Streetman <[EMAIL PROTECTED]> wrote:
> > >> -for places where a td->link was written, ad
Ok, this removes a failed urbp from uhci->urb_list. Otherwise bad things
happen.
diff -ur usb-2.5/drivers/usb/host/uhci-hcd.c linux/drivers/usb/host/uhci-hcd.c
--- usb-2.5/drivers/usb/host/uhci-hcd.c Fri Oct 11 16:52:49 2002
+++ linux/drivers/usb/host/uhci-hcd.c Fri Oct 11 16:59:53 2002
@@
This just adds outputting of the 2 uhci lists (urb_list, urb_remove_list,
and complete_list) to the /proc/driver/uhci/ file read.
It also doubles the buffer size used.
This info was just useful to me.
diff -ur usb-2.5/drivers/usb/host/uhci-debug.c linux/drivers/usb/host/uhci-debug.c
--- usb-
Ok, I'm breaking up the big patch into smaller ones, at least for the
simple(r) stuff.
This one fixes a bug where different names were being used for creation
and removal of the /proc/ entry.
diff -ur usb-2.5/drivers/usb/host/uhci-hcd.c linux/drivers/usb/host/uhci-hcd.c
--- usb-2.5/drivers/u
Hi,
this is a real case of mail interleave. I've just sent a new version to the
list. Could you look through that, too ?
Am Samstag, 12. Oktober 2002 21:56 schrieb David Brownell:
> The stuff below should only be available to other usbcore
> components; no device driver should ever call this stuf
Hi,
here's the version which should be correct and incorporates Greg's
suggestions. Now, does anybody on this list actually have a device with
multiple configurations ?
Regards
Oliver
--- usb-2.5/drivers/usb/core/hub.c 2002-10-12 14:49:17.0 +0200
+++ con25/d
The stuff below should only be available to other usbcore
components; no device driver should ever call this stuff.
It belongs in "hcd.h" not "usb.h".
It'd be good if we could set config to zero ... that's the
same state as a device is in after set_address is called.
We don't need it yet ... but i
On Sat, 12 Oct 2002, David Brownell wrote:
>Having browsed Dan's patch, I see his looked a lot like mine.
>Even down to having picked some of the same new names!
I cracked your home system and copied your patch. I 0wn j0u! Kidding. ;-)
--
Dan Streetman
[EMAIL PROTECTED]
-
On Fri, 11 Oct 2002, Greg KH wrote:
>It looks like you are using a buggy version of pine that strips the
>whitespace off of the ends of lines, so this patch didn't apply.
Ok, I managed to fixup pine...strange offtopic item, even the latest
version of pine strips trailing whitepace, I had to hand
Here's another UHCI patch, that's a bit less involved than
what Dan posted yesterday ... it only tries to make the
interrupt code handle queueing. (Except for doc updates
and a bit of gratuitous code shrinkage.) The goal being
to get to the point, quickly, where we can get rid of
the interrupt au
On Sat, Oct 12, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
>
> >>But again, I'd really rather see that kind of patch be independent of
> >>the rest of these UHCI-only changes.
>
> My original suggestion, just to repeat, was to split out the
> interrupts-can-queue patch to enable such a separ
But again, I'd really rather see that kind of patch be independent of
the rest of these UHCI-only changes.
My original suggestion, just to repeat, was to split out the
interrupts-can-queue patch to enable such a separate "remove
automagic" patch.
Maybe we should work at getting all of this m
On Sat, Oct 12, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
>
> >>So it's a Good Thing that Linux allocates bandwidth only on demand ... :)
> >
> > You mean at open() time right? :)
>
> That's the driver's business. If they post URBs on open, that
> would be how it works. If they post URB
On Sat, Oct 12, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
>
> > The problem with all of this is:
> >
> > a) It depends on queuing
> > b) It doesn't reserve the bandwidth
> >
> > Each in itself make it unacceptable.
>
> On the other hand, neither of those is true either. Which is
> part o
On Fri, Oct 11, 2002, Mark McClelland <[EMAIL PROTECTED]> wrote:
> David Brownell wrote:
>
> >> Right now, there is nothing in the standard hotplug userspace that makes
> >> this easy for anyone. It encourages applications to do the hideous thing
> >> and do whatever they think is best.
> >>
> >>
So it's a Good Thing that Linux allocates bandwidth only on demand ... :)
You mean at open() time right? :)
That's the driver's business. If they post URBs on open, that
would be how it works. If they post URBs on read/write, it'd be
a bit different.
Seriously, the way OHCI and EHCI do
The problem with all of this is:
a) It depends on queuing
b) It doesn't reserve the bandwidth
Each in itself make it unacceptable.
On the other hand, neither of those is true either. Which is
part of why I don't see any problem ... :)
Although a per frame bandwidth measurement might not b
On Sat, Oct 12, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> Dan Streetman wrote:
> > On Fri, 11 Oct 2002, David Brownell wrote:
> >
> >>All drivers using isochronous transfers _must_ set an altsetting,
> >>since it's illegal for a default config to have ISO endpoints.
> >>That's part of the
On Fri, Oct 11, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
>
> > yep, that's the major problem with removing interrupt queueing...but it
> > should happen at some point...
>
> removing "automagic resubmit", not "removing interrupt queuing" ... ;)
>
> > If noone's looked yet, I can look thro
Dan Streetman wrote:
On Fri, 11 Oct 2002, David Brownell wrote:
All drivers using isochronous transfers _must_ set an altsetting,
since it's illegal for a default config to have ISO endpoints.
That's part of the USB spec.
I have a device with iso endpoints as part of the default (only) confi
On Fri, 11 Oct 2002, David Brownell wrote:
>All drivers using isochronous transfers _must_ set an altsetting,
>since it's illegal for a default config to have ISO endpoints.
>That's part of the USB spec.
I have a device with iso endpoints as part of the default (only) config.
The iso endpoint be
On Fri, 11 Oct 2002, David Brownell wrote:
>The tricky bit is that the usb_{claim,release}_bandwidth() calls work
>on urbs, not endpoints. So I think those calls need to vanish, and
>HCDs need to switch to more precise math.
After reading that I realized my patch doesn't pass the BW reservation
Hi,
replying to myself:
On Fri, Oct 11, 2002 at 07:07:52PM +0200, Henning Meier-Geinitz wrote:
> My question is about the USB scanner driver and its maintainance. If I
> understood correctly, the maintainer is now Brian Beattie. Should
> patches and bug reports be send to him only, this list or b
Am Samstag, 12. Oktober 2002 13:07 schrieb Kari Hameenaho:
> With this patch using Epson 1240U works for me in both USB2.0 (NEC) and
> USB1.1 (AMD OCHI). I am not using CONFIG_USB_DYNAMIC_MINORS
> or devfs.
>
> Now the scn_minor is not manged at all, separate scn_index variable used.
> This one eve
With this patch using Epson 1240U works for me in both USB2.0 (NEC) and
USB1.1 (AMD OCHI). I am not using CONFIG_USB_DYNAMIC_MINORS
or devfs.
Now the scn_minor is not manged at all, separate scn_index variable used.
This one even survives taking the scanner offline and back on.
Should I real
44 matches
Mail list logo
