I have a Nvidia motherboard with an nvidia usb controller.
According to them I should load the usb-ohci module for the chip.
The module loads and detects the chip , evything ok.
But when I plug in the usb mouse the module says: new device found and
then the system hangs. :-(
This is very irritat
On Sun, Jan 26, 2003 at 07:37:42PM -0800, David Brownell wrote:
> Have you ruled out actually receiving a babble error from the
> hardware? Like by switching cables or ports? Or best by seeing
> on a CATC that all is fine. Strictly speaking, I don't think any
> of the HCDs (can) handle that corr
Matthew Dharm wrote:
What I get back is an error code of -75 (which means babble, IIRC) and 512
bytes of data received.
You mean "-EOVERFLOW"? Yes that's what it means. (Error code
values are arch-specific, though often is
used and that says EOVERFLOW == 75 ... like on x86.)
Have you ruled
On Fri, Jan 24, 2003 at 10:09:32AM -0800, Matthew Jacob wrote:
> > It's like when I pull the power plug because my system is totally hosed and
> > I want to start over. I know I can cause damage by doing that, but I would
> > be upset if the new system booted back to the broken state it was in wh
Am Sonntag, 26. Januar 2003 22:45 schrieb David Brownell:
> Oliver Neukum wrote:
> > Hi,
> >
> > this is the first version of the updated and improved patch.
> > It fails for me in an utterly bizarre way. It breaks some shared
> > libraries.
>
> Just thought I'd mean to say "thanks for updating" th
I've been testing 2.5.59 more... I think I've found a problem with
scatter-gather transfers.
Specifically, I'm trying to read in 32K of data from a device. I send a
32K scatter-gather chain to receive the data.
What I get back is an error code of -75 (which means babble, IIRC) and 512
bytes of d
Oliver Neukum wrote:
Hi,
this is the first version of the updated and improved patch.
It fails for me in an utterly bizarre way. It breaks some shared
libraries.
Just thought I'd mean to say "thanks for updating" this, it's an
important step towards making config changes work well under Linux.
Hello David,
On Sunday 26 January 2003 20:38, David Brownell wrote:
> Wolfgang Mües wrote:
> > There are more workarounds in this driver: there was a requirement
> > of one-shot INT OUT urbs, with individual byte counts. Manage this
> > to work with 3 different core drivers was difficult.
>
> Than
Wolfgang Mües wrote:
There are more workarounds in this driver: there was a requirement
of one-shot INT OUT urbs, with individual byte counts. Manage this
to work with 3 different core drivers was difficult.
Thankfully, Benjamin Herrenschmidt has taken the lead and will
be merging a usb-ohci pa
On Sun, 2003-01-26 at 20:38, David Brownell wrote:
> Wolfgang Mües wrote:
> >
> > There are more workarounds in this driver: there was a requirement
> > of one-shot INT OUT urbs, with individual byte counts. Manage this
> > to work with 3 different core drivers was difficult.
>
> Thankfully, Ben
There have been several patches around "fixing" one-shot interrupt URBs
lately. With the help of David Brownell, I've made a "fixed" version of
the fix and included it in the PowerMac stable tree (2.4.20-ben3). I'm
about to push it to the main PPC bk trees as well.
For those interested, here I cop
David Brownell wrote:
> +{ USB_DEVICE(0x0547, 0x2131) }, /* BayCom DABUSB prototype
I agree, there is a problem - so I would suggest to remove the ID 0x0547
from the driver.
Deti
---
This SF.NET email is sponsored by:
SourceFor
> + { USB_DEVICE(0x0547, 0x2131) }, /* BayCom DABUSB prototype (4 keys)(dumb) */
This isn't the vendor ID for _anything_ from BayCom;
It's the ID for the original EZ-USB chip: the An2131.
So it should be deleted from "dabusb".
We periodically get complaints from people (including
Cypress
13 matches
Mail list logo
