On Sun, 2 Jan 2005, Tilman Schmidt wrote:
> > In general, a non-running isochronous pipe shouldn't generate CRC errors.
>
> From past discussions on this list, I get the impression that -EILSEQ
> can also signal a timeout condition.
I just checked the source code, and you're right. The error-
Alan,
thanks for your reply.
On 02.01.2005 05:05, Alan Stern wrote:
> Which host controller driver are you using?
On my own test machines, uhci_hcd. So far I am under the impression that
every installation produces those errors but I don't have positive
knowledge about an installation not using
On Sat, 1 Jan 2005, Tilman Schmidt wrote:
> Working on a driver for an ISDN device[1] designed to transfer the
> actual B channel data of an established ISDN connection over a pair of
> isochronous pipes, one for each direction.
>
> I am setting these up by first submitting three URBs for each pi
Working on a driver for an ISDN device[1] designed to transfer the
actual B channel data of an established ISDN connection over a pair of
isochronous pipes, one for each direction.
I am setting these up by first submitting three URBs for each pipe,
before sending the command for actually establish
Sergij Kolisnyk wrote:
>
> - Original Message -
> From: "Roman Weissgaerber" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, May 09, 2001 8:34 PM
> Subject: Re: [linux-usb-devel] EILSEQ - FAQ ??
>
> >
- Original Message -
From: "Roman Weissgaerber" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 09, 2001 8:34 PM
Subject: Re: [linux-usb-devel] EILSEQ - FAQ ??
> > > Sergij Kolisnyk wrote:
> > > >
> > > > Hi!
>
> > >
> > > - Original Message -
> > > From: "Roman Weissgaerber" <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Wednesday, May 09, 2001 4:54 PM
> > > Subject: Re: [linux-usb-devel] EILSEQ - FAQ ??
&
ED]>
> > Sent: Wednesday, May 09, 2001 4:54 PM
> > Subject: Re: [linux-usb-devel] EILSEQ - FAQ ??
> >
> > > Sergij Kolisnyk wrote:
> > > >
> > > > Hi!
> > > >
> > > > All we know the problem.
> > > >
> > >
Sergij Kolisnyk wrote:
>
> - Original Message -
> From: "Roman Weissgaerber" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, May 09, 2001 4:54 PM
> Subject: Re: [linux-usb-devel] EILSEQ - FAQ ??
>
> > Sergij Kolisnyk w
- Original Message -
From: "Roman Weissgaerber" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 09, 2001 4:54 PM
Subject: Re: [linux-usb-devel] EILSEQ - FAQ ??
> Sergij Kolisnyk wrote:
> >
> > Hi!
> >
> > All we know
Sergij Kolisnyk wrote:
>
> Hi!
>
> All we know the problem.
>
> On _some_ motherboards when doing USB bulk read at full speed,
> URB completes with "-84" error code...
>
-84 (EILSEQ) means CRC Error of the packet sent by the device.
So I think this is a problem of the device and not of the HC
Hi!
All we know the problem.
On _some_ motherboards when doing USB bulk read at full speed,
URB completes with "-84" error code...
That happens only when device is fast enough to really utilyze
throughput of USB 1.1 full speed.
IMHO, this error may depend on BIOS, VGA and having X running...
E
> > > > Driver disconnect() routines need to unlink ALL urbs as well as
> > > > make sure that no other driver entries (file operations, say) will
> > > > ever try to use that device again (even while unlinking proceeds).
> > >
> > > Then I hope that disconnect() is not called on an irq!
> >
> >
Johannes Erdfelt wrote:
> On Fri, May 04, 2001, David Brownell <[EMAIL PROTECTED]> wrote:
> > > > Driver disconnect() routines need to unlink ALL urbs as well as
> > > > make sure that no other driver entries (file operations, say) will
> > > > ever try to use that device again (even while unlink
On Fri, May 04, 2001, David Brownell <[EMAIL PROTECTED]> wrote:
> > > Driver disconnect() routines need to unlink ALL urbs as well as
> > > make sure that no other driver entries (file operations, say) will
> > > ever try to use that device again (even while unlinking proceeds).
> >
> > Then I ho
> > Driver disconnect() routines need to unlink ALL urbs as well as
> > make sure that no other driver entries (file operations, say) will
> > ever try to use that device again (even while unlinking proceeds).
>
> Then I hope that disconnect() is not called on an irq!
Only in uncommon error reco
David Brownell wrote:
> > Incidentally, my tty driver's close routine unlinks urbs, my disconnect
> > routine frees the urbs. Is it dangerous to unlink urb's after they're
> > freed?
>
> Only if you dislike oopses! :)
>
Oh, I do dislike those.
> Driver disconnect() routines need to unlink ALL
> Incidentally, my tty driver's close routine unlinks urbs, my disconnect
> routine frees the urbs. Is it dangerous to unlink urb's after they're
> freed?
Only if you dislike oopses! :)
Driver disconnect() routines need to unlink ALL urbs as well as
make sure that no other driver entries (fil
Hi,
I'm working on both the f/w and host s/w for a custom driver (I need a
tty talking to a bootloader running on an embedded device). I've gotten
to the point where the f/w sends a continous stream of 'x' to a bulk-in
endpoint (as a test), and the s/w submits read URBs for that endpoint.
The s/
19 matches
Mail list logo
