Hello, Greg & All:
So I tested two patches on freshly downloaded 2.4.11-pre2. All tests
were done on dual P-III 750 MHz box, with SMP kernel, on two ports of a
four-port OHCI PCI card (each port is a separate 12 Mbps controller).
A. Testing of ibmcam modules.
============================
All four out of four supported cameras were tested; however I didn't
have a *working* flavor of Model 4, so that camera was only tested on
recognition of the device and on production of "compressed", noise-like
image.
Models 1, 2 and 3 all work as they should. Model 4 is recognized and
produces the incorrect picture (because nobody knows how to decompress
its datastream without going to jail for a {DMCA,SSSCA,*} violation).
Fortunately, plenty of people bought "working" varieties of Model 4 IBM
cameras.
No defects were found, whatsoever. I also tested "surprise removal"
safeguards, when the USB cable is pulled while the camera is streaming
and the application (xawtv) is receiving the data. Everything worked as
it should: the application receives errors and the driver postpones
device cleanup until the file handle gets released.
So the new IBM camera driver works. Greg, thanks for merging!
One thing, though: the patch broke the previously working hotplugging. I
attach the tiny patch to be applied in linux/drivers/usb directory -
hopefully this will fix it (and that's how it was before the merge!) I
can't test it, though, because hotplugging doesn't work for me
tonight... /lib/.../*.usbmap file has all the loaded drivers but none of
*compiled* ones :-( and it's too late to battle that.
B. USB Audio
============
The USB audio module (should it be renamed in 2.5 to "usbaudio.o"?) is
loaded on my box automatically, by the /etc/rc.d/rc.local script. On
boot-up I had as many as 3 audio class devices connected. All devices
were detected, and no failures occurred at that point.
Then I disconnected these 3 devices. All went well.
Then I connected the USB Audio speakers (Philips DSS330). They were
recognized. I configured xmms for OSS mode and played a song. It worked,
and I added more songs to the playlist.
While being entertained, I connected another audio class device (based
on Philips UDA1325 chip). This device is programmed to have input and
output terminals, but no mixer units. The device was recognized, and the
music playback was not interrupted. Good.
Then I executed command
# od -t x2 < /dev/dspW1
to read 16-bit samples from the newly connected device. A stream of data
showed up, correctly centered around zero (being a signed short). The
music continued to play.
Then I pressed ^C in the 'od' window to stop the dump. That's when the
same old, well-known [to me, at least] bug kicked in. The 'od' process
locked up in 'D' state, in the audio driver:
# ps -lx
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
...
504 0 1096 1088 9 0 0 0 end DW pts/2 0:00 [od]
The music continued to play, UNTIL THE SONG ENDED. Apparently at this
moment xmms tried to reopen the device. It promptly locked up:
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
...
100 0 1049 1 9 0 41008 25624 down D ? 0:06 xmms %u
040 0 1050 1049 9 0 41008 25624 do_pol S ? 0:00 xmms %u
040 0 1051 1050 9 0 41008 25624 do_sel S ? 0:00 xmms %u
040 0 1052 1050 9 0 41008 25624 nanosl S ? 0:00 xmms %u
140 0 1078 1050 9 0 41008 25624 nanosl S ? 0:11 xmms %u
040 0 1079 1050 9 0 41008 25624 nanosl S ? 0:01 xmms %u
End of story. I rebooted the box after that. Of course, the forced
reboot caused lots of [potential] grief because xmms was reading files
off of the Samba share, and it held it forever - the shutdown scripts
could not unmount it; then, the mixer settings could not be read, so I
had to press the "Reset" button, and so on.
This issue is in my todo list, but the list is just growing :-( This is
a *serious* issue because I plan to release server versions of our
software only for Linux and Solaris - but our software heavily reads and
writes from several audio devices... and apparently the bug above is
related to both SMP (it never happens on UP builds) *and* simultaneous
reading and writing. Note that in my test above I wrote into one device
but read from another, and the lock-up occurred on close() - and xmms
also locked up on close(), apparently...
Anyway, this all has nothing to do with the patch :-) The patch is OK,
and the audio.o works *not worse* than it did before - as far as I can
tell. I guess I will be playing more music now, at least to test it :)
Thanks,
Dmitri
--- ibmcam.c.greg Tue Oct 2 22:04:40 2001
+++ ibmcam.c Tue Oct 2 22:18:09 2001
@@ -3911,10 +3911,10 @@
#if defined(usb_device_id_ver)
static __devinitdata struct usb_device_id id_table[] = {
- { USB_DEVICE_VER(IBMCAM_VENDOR_ID, IBMCAM_PRODUCT_ID, 0x00, 0x02) }, /*
Model 1 */
- { USB_DEVICE_VER(IBMCAM_VENDOR_ID, IBMCAM_PRODUCT_ID, 0x03, 0x0a) }, /*
Model 2 */
- { USB_DEVICE_VER(IBMCAM_VENDOR_ID, IBMCAM_PRODUCT_ID, 0x03, 0x01) }, /*
Model 3 */
- { USB_DEVICE_VER(IBMCAM_VENDOR_ID, NETCAM_PRODUCT_ID, 0x03, 0x0a) }, /*
Model 4 */
+ { USB_DEVICE_VER(IBMCAM_VENDOR_ID, IBMCAM_PRODUCT_ID, 0x0002, 0x0002) },
+ /* Model 1 */
+ { USB_DEVICE_VER(IBMCAM_VENDOR_ID, IBMCAM_PRODUCT_ID, 0x030a, 0x030a) },
+ /* Model 2 */
+ { USB_DEVICE_VER(IBMCAM_VENDOR_ID, IBMCAM_PRODUCT_ID, 0x0301, 0x0301) },
+ /* Model 3 */
+ { USB_DEVICE_VER(IBMCAM_VENDOR_ID, NETCAM_PRODUCT_ID, 0x030a, 0x030a) },
+ /* Model 4 */
{ } /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, id_table);
PGP signature
