[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 identification,
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: Etnus,
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 want
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 bugs:
you can
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
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:
[dee6e300]
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 +
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 sleep is a
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). If
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
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
---
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
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,
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
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 reply
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) hangs pretty quickly
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
+++
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
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
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 about 20%
29 matches
Mail list logo
