On Wed, Dec 11, 2002 at 01:34:58PM -0700, Douglas Roberts wrote:
> Yes, they would have needed the spec to build the device. There is may
> be some kind of power play going on between the Chinese manufacturer of
> the device, and the American company who wants to supply us with the
> device. T
I noticed that after "rmmod usb-storage", one of its threads
hangs around long after it should have exited. This is with
"sd_mod" also loaded, and fwiw the system seemed to lock up
for a couple seconds after "rmmod usb-storage" returned.
I don't remember this happening before 2.5.51, but I might
Am Mittwoch, 11. Dezember 2002 02:15 schrieb Greg KH:
> On Wed, Dec 11, 2002 at 01:26:53AM +0100, Oliver Neukum wrote:
> > > > Doesn't sound easy to me.
> > >
> > > Ick, that's even messier :(
> > > In looking at your match, I think we only need the last bit, right?
> > > The other stuff was forma
Yes, they would have needed the spec to build the device. There is may
be some kind of power play going on between the Chinese manufacturer of
the device, and the American company who wants to supply us with the
device. The Chinese perhaps see some kind of risk (lost software driver
developme
Quick question. How did they built the device? They would have to
understand the specs?
Dwaine.
Douglas Roberts
<[EMAIL PROTECTED]>
Hi, all.
I have an odd situation here: we have in our hands a prototype of a
digital radio that uses a USB HID controller to interface it to the
computer. The Chinese manufacturer of this device professes to not
understand us when we have (repeatedly) requested the USB interface
specificatio
On Tue, Dec 10, 2002 at 06:55:00PM -0800, David Brownell wrote:
>
> >>>Yeah, that suggests that either usb-storage needs to handle this
> >>>somehow, right?
> >>
> >>Like by recognizing this case and reporting USB_STOR_XFER_SHORT?
> >>Likely that's so. It doesn't ... that "catch short read" logic
Hi there,
Is anybody out there have made isp1161 working with StrongARM stable and fast?
I've modified host controller driver from RIO audio for our project, it only works at
smaller packet size (maxpacketsize of endpoint). We will see lots "TD_DATAOVERRUN" and
"TD_PIDCHECKFAIL" errors if packe
Alan Stern wrote:
On Tue, 10 Dec 2002, David Brownell wrote:
Hm, this patch doesn't solve anything :(
As in, "no effect" or "the big issue didn't go away"?
If "no effect", then I wonder why storage is distinguishing that
case at all. But it seems like it ought to handle the -EREMOTEIO
short
Hi Greg,
this patch will disable the bluetty.o driver for 2.5.x if
the Bluetooth subsystem is selected, like it is now done
in 2.4.21-pre1.
Regards
Marcel
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
===
On Tue, 10 Dec 2002, David Brownell wrote:
> > Hm, this patch doesn't solve anything :(
>
> As in, "no effect" or "the big issue didn't go away"?
>
> If "no effect", then I wonder why storage is distinguishing that
> case at all. But it seems like it ought to handle the -EREMOTEIO
> short read ca
Yeah, that suggests that either usb-storage needs to handle this
somehow, right?
Like by recognizing this case and reporting USB_STOR_XFER_SHORT?
Likely that's so. It doesn't ... that "catch short read" logic
(after that "catch-all") won't kick in.
Hm, this patch doesn't solve anything :(
Hi,
Linux 2.4.18-4GB Suse distribution ( i checked also redhat and mandrake
latest kernels)
I'm writing some driver that inside attach routine i perform a lot of
transfers to control pipe
So far so good and all works fine, but some times i get an error :
line 1662 usb-uhci: err("ENXIO %08x,
13 matches
Mail list logo
