Em 04-07-2011 17:58, Németh Márton escreveu: > Hi, > > I'm running Debian with Linux 2.6.38-2-486 on a computer. I have a hama AC-150 webcam > attached to this computer. The webcam works continouosly and I use mencoder to do some > cropping and transformation and to encode the video stream to a file. > > When I plug the device the following appears in the dmesg: > > [439884.692090] usb 3-1: new full speed USB device using uhci_hcd and address 6 > [439884.841721] usb 3-1: New USB device found, idVendor=0c45, idProduct=6142 > [439884.841958] usb 3-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 > [439884.842153] usb 3-1: Product: USB camera > [439884.851327] gspca: probing 0c45:6142 > [439884.856694] sonixj: Sonix chip id: 12 > [439884.942767] sonixj: Sensor po2030n > [439884.947226] input: sonixj as /devices/pci0000:00/0000:00:0b.0/usb3/3-1/input/input4 > [439884.968553] gspca: video0 created > > The camera works and sometimes the following messages appear in dmesg: > > [2992914.118137] gspca: ISOC data error: [3] len=0, status=-84 > [3020511.187726] gspca: ISOC data error: [16] len=0, status=-84 > [3071235.051448] gspca: ISOC data error: [22] len=0, status=-84 > [3178268.392602] gspca: ISOC data error: [11] len=0, status=-84 > [3195506.149353] gspca: ISOC data error: [14] len=0, status=-84 > [3200576.757068] gspca: ISOC data error: [13] len=0, status=-84 > [3242983.446235] gspca: ISOC data error: [20] len=0, status=-84 > [3242983.446406] gspca: ISOC data error: [21] len=0, status=-84 > [3242983.446526] gspca: ISOC data error: [22] len=0, status=-84 > [3242983.446638] gspca: ISOC data error: [23] len=0, status=-84 > [3242983.468410] gspca: ISOC data error: [0] len=0, status=-84 > [3242983.468578] gspca: ISOC data error: [1] len=0, status=-84 > [3242983.468709] gspca: ISOC data error: [2] len=0, status=-84 > [3242983.468827] gspca: ISOC data error: [3] len=0, status=-84 > ... > [3242983.579375] gspca: ISOC data error: [22] len=0, status=-84 > [3242983.579375] gspca: ISOC data error: [23] len=0, status=-84 > [3242983.588379] gspca: URB error -84, resubmitting > [3242983.591697] usb 3-1: USB disconnect, address 6 > [3242983.592489] gspca: ISOC data error: [0] len=0, status=-84 > [3242983.592630] gspca: ISOC data error: [1] len=0, status=-84 > [3242983.592744] gspca: ISOC data error: [2] len=0, status=-84 > [3242983.592856] gspca: ISOC data error: [3] len=0, status=-84 > ... > [3242983.594935] gspca: ISOC data error: [22] len=0, status=-84 > [3242983.595044] gspca: ISOC data error: [23] len=0, status=-84 > [3242983.595149] gspca: usb_submit_urb() ret -19 > [3242983.602605] gspca: video0 disconnect > [3242983.899568] usb 3-1: new full speed USB device using uhci_hcd and address 7 > [3242984.077146] usb 3-1: New USB device found, idVendor=0c45, idProduct=6142 > [3242984.077375] usb 3-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 > [3242984.077563] usb 3-1: Product: USB camera > [3242984.096020] gspca: probing 0c45:6142 > [3242984.117655] sonixj: Sonix chip id: 12 > [3242984.221778] sonixj: Sensor po2030n > [3242984.249883] input: sonixj as /devices/pci0000:00/0000:00:0b.0/usb3/3-1/input/input5 > [3242984.258533] gspca: video1 created > > At this point the user space application (mencoder) still have the /dev/video0 device open > but the video0 device is no longer there. Instead the video1 is created. > > I already saw similar behaviour in case of suspend-resume cycle, see > Bug 13419 - gspca: /dev/video0 changes to /dev/video1 after suspend > https://bugzilla.kernel.org/show_bug.cgi?id=13419 In suspend/resume, it seems a driver bug to me. > > The error code -84 refers to EILSEQ (Illegal byte sequence) according to include/asm-generic/errno.h . > What could be the reason for "ISO data error"? > > I guess the video0 is disconnected as part of error recovery. In this case, however > the video1 device is created so the user space application looses the original > video streaming device. Is this how it shall work? It seems a bug that mencoder didn't stopped streaming with EILSEQ. Maybe this erros is not properly propagated? In any case, if the userspace application keeps a device opened, the Kernel needs to get the next available major/minor, as, otherwise, an OOPS or panic will happen, as the kernel can't free the major/minor while it is in usage. The alternative for that would be to create an alias, via udev, for example, calling it as /dev/webcam0, and keeping the value permanent, for the same device. This way, the name of the device won't change (but the minor will keep changing). This won't solve the issue, except if the application would close and re-open the devnode, when such error occurs. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
