Re: USB OHCI problems...
[drop me from any replies, and I'll catch up from the archives, thanx] On Wed, 1 Dec 2004 10:48:42 +1030, Daniel O'Connor wrote: In addition, I've connected a uaudio sound device, which works to play audio for between 10 and 13 minutes, before bombing out with an error in ohci_device_isoc_enter(), On a side note.. How are you testing it? ``waveplay -S 48000 -f /dev/dsp[0-2]'' (when part of a pipeline that cuts off the WAV header info), or via a wrapper that invokes `ogg123' with the appropriate /dev/dsp? audio device. Into a pair of headphones. I haven't done a serious comprehensive test to try recording or anything; that comes later. Last time I tried my USB audio device I got pretty reliable panics trying to get KDE to use it :( Which FreeBSD and what sort of device? My FreeBSD-4.x is using as much USB code from -current as possible, which might make some difference. The uaudio device I have is one that I inquired about some months back in either the -multimedia or -hardware list -- I need to dig out that post, and make a followup to it with potentially useful info sometime later today. There are, um, ``interesting'' things I've observed, which I'll mention in my followup to whichever list, that I need to verify are independent of UHCI/OHCI controller, and also whether afflict NetBSD as well. NetBSD also gives me more access to the device. FreeBSD finds it as uaudio and uhid, and (my module source) plays back at a fixed volume level (apparently samplerate too). The (usual) worst I experience is the `isoc TD' message followed by a `pcmX:play: timeout, channel dead' type of message, after which the device no longer works. While I've had panics from other causes, I don't think any of mine could be pinned on the uaudio/uhid device -- but I haven't done much in the way of connect/disconnecting and stuff. thanks barry bouwsma ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB OHCI problems...
On Tue, Nov 30, 2004 at 06:16:03PM +0100, Hans Petter Selasky wrote: Hi, http://home.c2i.net/hselasky/isdn4bsd/privat/usb/Makefile http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.diff.bz2 http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.tar.bz2 I fixed a small bug in the code that prevented isoc. from working. You might want to re-download the files. Yours -HPS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB OHCI problems...
Just to add to what I wrote at the end of October:
Anyway, under FreeBSD-4 with kernel modules built 10.August
from source that I believe is based on FreeBSD-5-current of
that era, I'm seeing corruption of data read from umass
devices attached to an OHCI controller card. Use of a UHCI
controller card instead seems mostly free of problems.
In addition, I've connected a uaudio sound device, which
works to play audio for between 10 and 13 minutes, before
bombing out with an error in ohci_device_isoc_enter(),
tripping over one of the two
/* Allocate next ITD */
nsitd = ohci_alloc_sitd(sc);
if (nsitd == NULL) {
/* XXX what now? */
printf(%s: isoc TD alloc failed\n,
USBDEVNAME(sc-sc_bus.bdev));
return;
}
Connecting this uaudio device to a UHCI card results in
problem-free playback for at least a couple hours. And,
I'm rather sure that I was able to play through this OHCI
controller under NetBSD for an extended time. This device
does not attach to EHCI.
For this, I used kernel modules on my FreeBSD 4.x box,
recently built from as much of the -current USB code as
I could get to compile with minimal hackery, but this time
without merging in the work in P4 from Ian Dowse, or the
patchsets based on these. Source code date at least a
couple weeks to a month old.
I'll try updating to the most recent code I can lay me
grubby mitts on (stop with all these updates while I'm
offline, eh) as well as the above patchsets, to see if
things are changed in the OHCI world.
Also, I'm about to the point of readiness to acquire another
card with OHCI to see if any chipset-specific problems could
be tickling my problems -- though NetBSD appears to work
mostly fine. This OHCI chipset is on a combi-card in a
machine with a severe lack of PCI slots, while my UHCI card
is devoted to USB and fit better into a machine with a lack
(but not quite so severe) of PCI slots. Perhaps there's a
PCI-PCI bridge on the card in the way, but there's a firewire
controller on the card sharing the interrupt with OHCI, and
I have no problems with the firewire.
thanks
barry bouwsma
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB OHCI problems...
Hi,
I've got a new USB driver (with OHCI isoc fixed). You need FreeBSD 5.2/5.3 to
get it compiled.
You might be able to get it compiled on FreeBSD 4.x, but you will need to to
some hacking.
For example you need to add to dev/usb2/usb_port.h :
#ifndef MTX
#define MTX
struct mtx { int s; u_int8_t locked; u_int8_t mtx_recurse; }
#define mtx_init(args...)
#define mtx_lock(mtx) { (mtx)-s = splnet(); if((mtx)-locked) {
(mtx)-mtx_recurse++; } else { (mtx)-locked = 1; } }
#define mtx_unlock(mtx) { splx((mtx)-s); if((mtx)-mtx_recurse) {
(mtx)-mtx_recurse--; } else { (mtx)-locked = 0; } }
int
msleep(void *ident, struct mtx *mtx, int priority, const char *wmesg,
int timo);
#endif
and to dev/usb2/_usb.c:
int
msleep(void *ident, struct mtx *mtx, int priority, const char *wmesg,
int timo)
{
tsleep(ident,priority,wmesg,timo);
}
Create a new directory and download the following files and type make
install (to uninstall type make deinstall)
http://home.c2i.net/hselasky/isdn4bsd/privat/usb/Makefile
http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.diff.bz2
http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.tar.bz2
Maybe this thread should be moved to [EMAIL PROTECTED] ?
Yours
-HPS
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB OHCI problems...
On Tue, 30 Nov 2004 23:40, Barry Bouwsma wrote: In addition, I've connected a uaudio sound device, which works to play audio for between 10 and 13 minutes, before bombing out with an error in ohci_device_isoc_enter(), tripping over one of the two On a side note.. How are you testing it? Last time I tried my USB audio device I got pretty reliable panics trying to get KDE to use it :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpgjIvJBJvSV.pgp Description: PGP signature
USB OHCI problems...
Apologies for this posting, as so far as I know it's a known issue that the USB OHCI code has some problems, or perhaps that there have been code commits in the last weeks so this is no longer a problem... Anyway, under FreeBSD-4 with kernel modules built 10.August from source that I believe is based on FreeBSD-5-current of that era, I'm seeing corruption of data read from umass devices attached to an OHCI controller card. Use of a UHCI controller card instead seems mostly free of problems. In comparison, I accessed the data with NetBSD-current of similar vintage, and in the files copied with the identical hardware, the data is intact. The point at which the corruption begins is at some multiple of 16384 bytes into the file. The corruption is not consistent, as it is less likely to occur when the machine is somewhat idle, and as the below shows, also occurs at different points into the same file. I haven't looked to see for how long this corruption is present (it's more than a few hundred bytes, at least) or how the file appears after this, or whether this corruption follows any particular pattern of the rest of the file. The below is `cmp' output under my FreeBSD, compared against the files previously downloaded with NetBSD (and verified that all the images are intact). /cdrom/dcim/100dscim/pict0681.jpg pict0681.jpg differ: char 524289, line 2284 /cdrom/dcim/100dscim/pict0683.jpg pict0683.jpg differ: char 507905, line 2116 /cdrom/dcim/100dscim/pict0684.jpg pict0684.jpg differ: char 1163265, line 3323 /cdrom/dcim/100dscim/pict0685.jpg pict0685.jpg differ: char 294913, line 1402 /cdrom/dcim/100dscim/pict0686.jpg pict0686.jpg differ: char 393217, line 1716 /cdrom/dcim/100dscim/pict0687.jpg pict0687.jpg differ: char 753665, line 2606 /cdrom/dcim/100dscim/pict0686.jpg pict0686.jpg differ: char 983041, line 3648 This is just a sample -- note that the last line is the same file that I had previously `cmp'ed two lines above. In fairness, the files copied from NetBSD were done with the machine mostly idle, so I don't know if NetBSD suffers the same if I were pounding the machine. If this issue hasn't been handled, perhaps the fact that NetBSD doesn't seem to have problems might give someone some ideas as to where the problem might lie. As usual, apologies for the untimeliness of this, as well as my lack of detailed testing with fresh -current or with code fresher than two months ago. thanks barry bouwsma ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
