Greetings,
I'm having problems getting Sony DCR-TRV17E (with 4MB memory stick)
working with 2.6.0-test6. The driver reports babble and then
everything goes downhill. I'm keen to investigate it further,
just not sure where to look. Any advice appreciated.
Regards,
Dmitri
[Plugging it in. BTW
Sometimes when I try to reload the uhci-hcd module (because my USB mouse
cursor is stuck (might be a related problem)) I get the following error:
# rmmod uhci-hcd
# modprobe uhci-hcd
Speicherzugriffsfehler [memory access error]
# rmmod uhci-hcd
device is in use [or something like that]
# rmmod
Dave, Greg --
Here is a little patch for gserial.c to fix the timeout
while waiting for a condition (used to wait for data
to drain on close). This patch applies to the gserial.c
file I sent Tuesday night.
I sent out a patch last night to add g_serial to
On Wed, 1 Oct 2003, Richard Stover wrote:
I just tested bulk transactions. On the 3GHz P4 on which
I'm doing the development I can maintain one transaction
per microframe. Of course packet size is reduced to 512 bytes
from the (nominal) 1024 interrupt transactions packet size.
This gets me
Moe Wibble wrote:
http://mbox.bz/pub/lsusb-v-before.txt [17k, before timeout]
http://mbox.bz/pub/lsusb-v-after.txt [16k, after timeout]
After the device went bad lsusb announces protocol errors
while querying it. That's not surprising but I put the after-
output there too, for completeness.
That
On Thu, 2 Oct 2003, Andreas Schwarz wrote:
Sometimes when I try to reload the uhci-hcd module (because my USB mouse
cursor is stuck (might be a related problem)) I get the following error:
# rmmod uhci-hcd
# modprobe uhci-hcd
Speicherzugriffsfehler [memory access error]
# rmmod uhci-hcd
You say you can maintain one transaction per microframe -- what's the
bottleneck?
How big are the buffer sizes in the URBs that you queue for your
transfers? There's no reason for them to be limited to 512 bytes.
Alan Stern
Thanks for pointing that out Alan. I just tested it and I can
get
Richard Stover wrote:
It would still be nice to have high-bandwidth interrupt
packets (24Mb/sec guaranteed bandwidth) eventually. But for now
I'm happy with 12Mb/sec bulk transactions.
I'm dusting off a patch that will do that as a side effect
of more significant periodic scheduling updates. You
On Thu, 2 Oct 2003, Richard Stover wrote:
What do you think determines this current limit of 3 transactions
per microframe? Is it primarily cpu speed that sets the amount
of time it takes to get another transaction going? I suspect it
is not the FX2 chip, but I haven't verified that yet.
Hello,
I have project called lineak http://lineak.sourceforge.net which is a user
configurable daemon to run commands when a user presses a multimedia key on
their keyboard. However, some people who have USB keyboards, have a problem
that some keys do not get keycodes, or generate events. In
add laptop keyboards to that as well:)
--- Sheldon Lee-Wen [EMAIL PROTECTED] wrote:
Hello,
I have project called lineak
http://lineak.sourceforge.net which is a user
configurable daemon to run commands when a user
presses a multimedia key on
their keyboard. However, some people who
This is a might crash, be careful patch that updates the
scheduling of interrupt transfers.
* The interrupt chedule is now a sparse tree of QH, much
like OHCI does with EDs. This lets ehci-hcd support
many more hubs, mice, keyboards, etc ... by lifting the
long-standing
Kevin Owen wrote:
Has anyone out there had any success using lots of USB 1.1 devices
through USB 2.0 hub transaction translators ?
Probably not, given the known restriction in the interrupt
scheduling code: one interrupt transaction per frame.
(A handy implementation shortcut, avoiding the need
13 matches
Mail list logo
