[EMAIL PROTECTED] writes:
> Quoting Stefan Neuwirth <[EMAIL PROTECTED]>:
>
> > when loading usb-uhci (2.4.21-rc7-ac1) my 6in1 cardreader (bcm 3230,
> > Vendor-ID 0x0aec,
> > Produkt-ID 0x3050) is present. It's listed in /proc/bus/ucb/devices:
>
> This is how the device presented itself for iden
On Sun, Jun 08, Olaf Hering wrote:
> touch "${REMOVER}.queue.$$"
It should be '> "${REMOVER}.queue.$$"' to avoid yet another process.
Gruss Olaf
--
USB is for mice, FireWire is for men!
---
This SF.net email is sponsored by: Etnu
On Sun, 8 Jun 2003, Matthew Dharm wrote:
> This patch introduces some handling for babble conditions.
>
> Basically, once a babble is detected, we return sense data saying the
> command was invalid. We also go on to transfer the CSW (for BBB transport)
> so we stay in phase with the device.
I w
Olaf Hering wrote:
> We could improve things alot if /proc/bus/usb/devices had a better
> design :(
Well, that was a first version. Nobody's really done
much with that kernel code other than fix bugs.
> It is updated dynamically, reading it can take an unknown amount of time
> and it triggers bus
Olaf Hering wrote:
>>>there is a hardcoded sleep 3 in the usb.agent. But this is wrong,
>>>because the kernel runs all hotplug events at once for a new hub. The
>>>result is that every event still runs in parallel, just 3 seconds later.
>>
>>That "sleep" is a workaround for "uhci" and "usb-uhci" bu
Major A wrote:
> Alan, David, everyone else who might be able to help,
>
> I've just caught an oops that seems to come from the EHCI code. This
> happened while trying to communicate with my own USB 2.0 device (based
> on the Cypress EZ-USB FX2), under vanilla 2.4.20. ..
>
> ...
>>
>>kernel BUG at
Major A wrote:
Make sure you're running a kernel with the kernel hacking "debug memory
allocations" option enabled. Then when it pauses, copy the "async"
file for that controller and send it to me. In fact, just make a
copy of every file in the relevant sysfs directory (it'll be something
like /
Stefan Neuwirth wrote:
>
> 2.4.21-rc7-ac1...
Yes, some very important EHCI patches never made it into
the 2.4.21 tree. I've reposted them a few times, and
they're in Greg's USB tree, ready to appear as soon
as 2.4.22-pre starts.
- Dave
-
Olaf Hering wrote:
Hi,
the are are currently 3 kind of maps for device drivers
That is, the user-mode driver databases are built by combining
several categories of usbmap entries, for use by different kinds
of install processes. The most significant are the "depmod"
style installations (/lib/modu
On Fri, 6 Jun 2003, Duncan Sands wrote:
> Here's the schedule. It finishes like this:
>
> [dee6e2d0] link (1ee6e212) element (18f33a50)
> 0: [d8f33a50] link (1ee6e302) e3 SPD IOC Active Length=0 MaxLen=34 DT1 EndPt=7
> Dev=2, PID=e1(OUT) (buf=193cd000)
> -- Queued QH's:
> [dee6e3
On Sun, Jun 08, David Brownell wrote:
> Seems to me this syntax is weaker than the current
> one (no versioning or class support), so you could
> solve your USR modem problem without new syntax
> (and all the support code + training).
look again, the old syntax is still there.
*.usermap + *.simp
On Sun, Jun 08, David Brownell wrote:
> Olaf Hering wrote:
> >>>there is a hardcoded sleep 3 in the usb.agent. But this is wrong,
> >>>because the kernel runs all hotplug events at once for a new hub. The
> >>>result is that every event still runs in parallel, just 3 seconds later.
> >>
> >>That
Olaf Hering wrote:
Running parallel isn't a bug, doesn't need to be changed.
Typically the agents just finish faster that way.
You could drop the sleep 3 at all if you argue that way.
No, that works around (partially) that bug in the 2.4
(and older) UHCI drivers. It's often seen with usbfs,
but
On Sun, 8 Jun 2003, David Brownell wrote:
> * The second problem was at 38:42, where something called some
>usbcore code which complains "control/bulk timeout".
>
>This is curious; it doesn't seem to be associated with an EHCI
>device (no such request in the async schedule snapshots).
This patch makes the hub status irq DMA-aware, by pre-allocating the
transfer buffer in consistent memory. Unfortunately, there doesn't seem
to be an easy way to do the same for the status report buffers.
Alan Stern
# This is a BitKeeper generated patch for the following project:
# Project Na
David:
The following patch addresses the problem the Paul raised, concerning
whether the root hub status irq timer should be allowed to run during a
suspend.
I'm not sure that this does exactly what you would like. My reasoning is
that the timer should run as long as the URB is linked. Just a
Alan Stern wrote:
David:
The following patch addresses the problem the Paul raised, concerning
whether the root hub status irq timer should be allowed to run during a
suspend.
Looks fair to me. Paul, is it working for you?
- Dave
---
Thi
Some folk wanted a user mode API, so their drivers could
be written by developers without kernel skillz. (And
making it easier to have non-GPL drivers.)
So I thought I'd mention that there _is_ such an API in
bk://kernel.bkbits.net/db/linux/gadget-2.[45] repositories,
called "gadgetfs".
It's not l
> Hi,
>
> I have been trying to solve this problem for a long time and any help
> would be greatly appreciated.
>
> Problem: I am having difficulty trying to connect a USB
> SMARTBoard(digital whiteboard) to my Linux machine.
> Specifically: HID/HIDDEV is not claiming the device.
>
> I am u
On Mon, Jun 09, 2003 at 10:45:20AM -0400, Alan Stern wrote:
> On Sun, 8 Jun 2003, Matthew Dharm wrote:
>
> > This patch introduces some handling for babble conditions.
> >
> > Basically, once a babble is detected, we return sense data saying the
> > command was invalid. We also go on to transfer
> From: Jackson Chan <[EMAIL PROTECTED]>
> Date: Mon, 9 Jun 2003 11:57:36 -0600
> > I have been trying to solve this problem for a long time and any help
> > would be greatly appreciated.
In such case you would be well advised to stop being a jerk
and cross-post the same stupid question everywher
Here's a patch that resolves a regression I've been chasing
for a while ... it may address other issues too, which is
why there's a CC list.
The significant change is some updates to how completed qTDs
get processed.
Less significant changes include updates to the debug output,
a version change, re
This patch implements separate flag bits to indicate which of transfer_dma
and setup_dma are already valid. It provides greater flexibility to
device drivers by allowing for control transfers in which only one of the
two buffers has been mapped.
The new flag bits are URB_NO_TRANSFER_DMA_MAP and
David,
> Here's a patch that resolves a regression I've been chasing
> for a while ... it may address other issues too, which is
> why there's a CC list.
I've applied this to 2.5.70-bk8 and see no change in the behaviour at
all. I haven't looked closely, so please let me know if you want
another
David Brownell <[EMAIL PROTECTED]> writes:
>
> [SNIP]
>
I've tried it quickly, and the problem of a rapidly rising load is
back in 2.5.70-mm6, and writes from network to my USB-drive (Maxtor
5000XT) hangs pretty quickly (~100Mb into the transfer).
Recompiling with debug now, more info in a while
Alexander Hoogerhuis wrote:
David Brownell <[EMAIL PROTECTED]> writes:
[SNIP]
I've tried it quickly, and the problem of a rapidly rising load is
back in 2.5.70-mm6, and writes from network to my USB-drive (Maxtor
5000XT) hangs pretty quickly (~100Mb into the transfer).
Well, the "rapidly rising
David Brownell <[EMAIL PROTECTED]> writes:
>
> Well, the "rapidly rising load" symptom seems to be
> unrelated to USB ... it's shown up with both UHCI
> and EHCI drivers (both full and low speeds). So I'm
> unsurprised that a USB change doesn't affect it.
>
I had no more than typed up my last r
David Brownell <[EMAIL PROTECTED]> writes:
> Alexander Hoogerhuis wrote:
> > David Brownell <[EMAIL PROTECTED]> writes:
> >
> >>[SNIP]
> >>
> > I've tried it quickly, and the problem of a rapidly rising load is
> > back in 2.5.70-mm6, and writes from network to my USB-drive (Maxtor
> > 5000XT) han
Hi,
The main thing this fixes is making the control-OUT path work.
Drivers like RNDIS and DFU need it; this should resolve one
bug report. It also has some minor cleanups.
Please merge to Linus' latest.
- Dave
--- a/drivers/usb/gadget/net2280.c Mon Jun 9 18:18:58 2003
+++ b/drivers/usb/ga
Alexander Hoogerhuis wrote:
The patch *WITHOUT* debugging enabled fell over real fast. Now *WITH*
debugging the skyrocketin load symptom is gone, and it's chugging
along nicely at line speed with FTP and also with CPU maxed out with
scp about 20% udner line speed (i.e. saturated CPU). SO far I've m
Alan Stern wrote:
This patch implements separate flag bits to indicate which of transfer_dma
and setup_dma are already valid. It provides greater flexibility to
device drivers by allowing for control transfers in which only one of the
two buffers has been mapped.
Looks good, minor comments below
Hi, I am running kernel 2.4.21-rc7 and am still having trouble with this
device after reading the original thread [1]. At storage/usb.c:937, the
case for the US_SC_8020 subclass sets max_lun to zero:
case US_SC_8020:
ss->protocol_name = "8020i";
David Brownell <[EMAIL PROTECTED]> writes:
> Alexander Hoogerhuis wrote:
> > The patch *WITHOUT* debugging enabled fell over real fast. Now *WITH*
> > debugging the skyrocketin load symptom is gone, and it's chugging
> > along nicely at line speed with FTP and also with CPU maxed out with
> > scp
33 matches
Mail list logo
