Skip to contentSkip to conversation

UVC-webcam: kernel panic when starting capturing

Regression 3.1->3.2, bisected Frank Schäfer 2 participants 5 messages Jul 12, 2012 – Jul 16, 2012 Media (V4L/DVB)

lore
Share & tools
lore
#0 lore raw

Hi,

when I start capturing from the UVC-webcam 2232:1005 ("WebCam SCB-0385N") of my netbook, I get a kernel panic. You can find a screenshot of the backtrace here:

http://imageshack.us/photo/my-images/9/img125km.jpg/

This is a regression which has been introduced between kernel 3.2-rc2 and 3.2-rc3 with the following commit:

3afedb95858bcc117b207a7c0a6767fe891bdfe9 is the first bad commit commit 3afedb95858bcc117b207a7c0a6767fe891bdfe9

Author: Laurent Pinchart <[email protected]>
Date:   Thu Nov 3 07:24:34 2011 -0300

[media] uvcvideo: Don't skip erroneous payloads

Instead of skipping the payload completely, which would make the resulting image corrupted anyway, store the payload normally and mark the buffer as erroneous. If the no_drop module parameter is set to 1 the buffer will then be passed to userspace, and tt will then be up to the application to decide what to do with the buffer.

Regards,
Frank Schäfer

Output of lsusb -vvv:

device 2232:1005 ("WebCam SCB-0385N")

Bus 001 Device 004: ID 2232:1005
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x2232
idProduct 0x1005
bcdDevice 0.07

  iManufacturer           1 Image Processor
  iProduct                2 WebCam SCB-0385N
  iSerial                 0
  bNumConfigurations      1

Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 445
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 14 Video
bFunctionSubClass 3 Video Interface Collection
bFunctionProtocol 0
iFunction 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 1 Video Control
bInterfaceProtocol 0
iInterface 0
VideoControl Interface Descriptor:
bLength 13
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdUVC 1.00
wTotalLength 77
dwClockFrequency 30.000000MHz
bInCollection 1
baInterfaceNr( 0) 1
VideoControl Interface Descriptor:
bLength 18
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType 0x0201 Camera Sensor
bAssocTerminal 0
iTerminal 0
wObjectiveFocalLengthMin 0
wObjectiveFocalLengthMax 0
wOcularFocalLength 0
bControlSize 3
bmControls 0x00000000
VideoControl Interface Descriptor:
bLength 26
bDescriptorType 36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 2
guidExtensionCode {92423946-d10c-e34a-8783-3133f9eaaa3b}
bNumControl 3
bNrPins 1
baSourceID( 0) 1
bControlSize 1
bmControls( 0) 0xff
iExtension 0
VideoControl Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 5 (PROCESSING_UNIT)
Warning: Descriptor too short
bUnitID 3
bSourceID 2
wMaxMultiplier 0
bControlSize 2
bmControls 0x0000043f
Brightness
Contrast
Hue
Saturation
Sharpness
Gamma
Power Line Frequency
iProcessing 0
bmVideoStandards 0x 9
None
SECAM - 625/50
VideoControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 4
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bSourceID 3
iTerminal 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 16
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bInterfaceProtocol 0
iInterface 0
VideoStreaming Interface Descriptor:
bLength 14
bDescriptorType 36
bDescriptorSubtype 1 (INPUT_HEADER)
bNumFormats 1
wTotalLength 257
bEndPointAddress 129
bmInfo 0
bTerminalLink 4
bStillCaptureMethod 1
bTriggerSupport 0
bTriggerUsage 0
bControlSize 1
bmaControls( 0) 27
VideoStreaming Interface Descriptor:
bLength 27
bDescriptorType 36
bDescriptorSubtype 4 (FORMAT_UNCOMPRESSED)
bFormatIndex 1
bNumFrameDescriptors 5
guidFormat
{59555932-0000-1000-8000-00aa00389b71}
bBitsPerPixel 16
bDefaultFrameIndex 1
bAspectRatioX 0
bAspectRatioY 0
bmInterlaceFlags 0x00
Interlaced stream or variable: No
Fields per frame: 2 fields
Field 1 first: No
Field pattern: Field 1 only
bCopyProtect 0
VideoStreaming Interface Descriptor:
bLength 42
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 1
bmCapabilities 0x00
Still image unsupported
wWidth 640
wHeight 480
dwMinBitRate 912384
dwMaxBitRate 912384
dwMaxVideoFrameBufferSize 614400
dwDefaultFrameInterval 333333
bFrameIntervalType 4
dwFrameInterval( 0) 333333
dwFrameInterval( 1) 333334
dwFrameInterval( 2) 333335
dwFrameInterval( 3) 333336
VideoStreaming Interface Descriptor:
bLength 42
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 2
bmCapabilities 0x00
Still image unsupported
wWidth 352
wHeight 288
dwMinBitRate 912384
dwMaxBitRate 912384
dwMaxVideoFrameBufferSize 202752
dwDefaultFrameInterval 333333
bFrameIntervalType 4
dwFrameInterval( 0) 333333
dwFrameInterval( 1) 333334
dwFrameInterval( 2) 333335
dwFrameInterval( 3) 333336
VideoStreaming Interface Descriptor:
bLength 42
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 3
bmCapabilities 0x01
Still image supported
wWidth 320
wHeight 240
dwMinBitRate 912384
dwMaxBitRate 912384
dwMaxVideoFrameBufferSize 153600
dwDefaultFrameInterval 333333
bFrameIntervalType 4
dwFrameInterval( 0) 333333
dwFrameInterval( 1) 333334
dwFrameInterval( 2) 333335
dwFrameInterval( 3) 333336
VideoStreaming Interface Descriptor:
bLength 42
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 4
bmCapabilities 0x01
Still image supported
wWidth 176
wHeight 144
dwMinBitRate 912384
dwMaxBitRate 912384
dwMaxVideoFrameBufferSize 50688
dwDefaultFrameInterval 333333
bFrameIntervalType 4
dwFrameInterval( 0) 333333
dwFrameInterval( 1) 333334
dwFrameInterval( 2) 333335
dwFrameInterval( 3) 333336
VideoStreaming Interface Descriptor:
bLength 42
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 5
bmCapabilities 0x01
Still image supported
wWidth 160
wHeight 120
dwMinBitRate 912384
dwMaxBitRate 912384
dwMaxVideoFrameBufferSize 38400
dwDefaultFrameInterval 333333
bFrameIntervalType 4
dwFrameInterval( 0) 333333
dwFrameInterval( 1) 333334
dwFrameInterval( 2) 333335
dwFrameInterval( 3) 333336
VideoStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 13 (COLORFORMAT)
bColorPrimaries 0 (Unspecified)
bTransferCharacteristics 0 (Unspecified)
bMatrixCoefficients 0 (Unspecified)
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x1400 3x 1024 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 2
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x1340 3x 832 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 3
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x1300 3x 768 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 4
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x1400 3x 1024 bytes
bInterval 1
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)

#1 lore raw

Hi Frank,

Thanks for the report.

Quoted 20 lines · On Thursday 12 July 2012 21:07:56 Frank Schäfer wrote:

Hi,

when I start capturing from the UVC-webcam 2232:1005 ("WebCam SCB-0385N") of my netbook, I get a kernel panic. You can find a screenshot of the backtrace here:

http://imageshack.us/photo/my-images/9/img125km.jpg/

This is a regression which has been introduced between kernel 3.2-rc2 and 3.2-rc3 with the following commit:

3afedb95858bcc117b207a7c0a6767fe891bdfe9 is the first bad commit commit 3afedb95858bcc117b207a7c0a6767fe891bdfe9

Author: Laurent Pinchart <[email protected]>
Date:   Thu Nov 3 07:24:34 2011 -0300

[media] uvcvideo: Don't skip erroneous payloads

Quoted 8 lines

Instead of skipping the payload completely, which would make the resulting image corrupted anyway, store the payload normally and mark the buffer as erroneous. If the no_drop module parameter is set to 1 the
buffer will then be passed to userspace, and tt will then be up to the application to decide what to do with the buffer.

I'm puzzled. Your screenshot shows the uvc_video_stats_decode() function in the stack trace, but that function wasn't present in 3afedb95858bcc117b207a7c0a6767fe891bdfe9. Could you please send me a stack trace corresponding to 3afedb95858bcc117b207a7c0a6767fe891bdfe9 ?

Your stack trace looks similar to the problem reported in
https://bugzilla.redhat.com/show_bug.cgi?id=836742.
3afedb95858bcc117b207a7c0a6767fe891bdfe9 might have introduced a different bug, possibly fixed in a later commit.

Signature · 3 lines
Regards,

Laurent Pinchart
#2 lore raw

Am 15.07.2012 14:07, schrieb Laurent Pinchart:

Quoted 38 lines

Hi Frank,

Thanks for the report.

Quoted 20 lines · On Thursday 12 July 2012 21:07:56 Frank Schäfer wrote:

Hi,

when I start capturing from the UVC-webcam 2232:1005 ("WebCam SCB-0385N") of my netbook, I get a kernel panic. You can find a screenshot of the backtrace here:

http://imageshack.us/photo/my-images/9/img125km.jpg/

This is a regression which has been introduced between kernel 3.2-rc2 and 3.2-rc3 with the following commit:

3afedb95858bcc117b207a7c0a6767fe891bdfe9 is the first bad commit commit 3afedb95858bcc117b207a7c0a6767fe891bdfe9

Author: Laurent Pinchart <[email protected]>
Date:   Thu Nov 3 07:24:34 2011 -0300

[media] uvcvideo: Don't skip erroneous payloads

Quoted 8 lines

Instead of skipping the payload completely, which would make the resulting image corrupted anyway, store the payload normally and mark the buffer as erroneous. If the no_drop module parameter is set to 1 the
buffer will then be passed to userspace, and tt will then be up to the application to decide what to do with the buffer.

I'm puzzled. Your screenshot shows the uvc_video_stats_decode() function in the stack trace, but that function wasn't present in 3afedb95858bcc117b207a7c0a6767fe891bdfe9. Could you please send me a stack trace corresponding to 3afedb95858bcc117b207a7c0a6767fe891bdfe9 ?

Quoted 4 lines

Your stack trace looks similar to the problem reported in
https://bugzilla.redhat.com/show_bug.cgi?id=836742.
3afedb95858bcc117b207a7c0a6767fe891bdfe9 might have introduced a different bug, possibly fixed in a later commit.

Hmm... you're right.
The screenshot I've sent to you was made during the bisection process at a commit somewhere between 3.2-rc7 and 3.2-rc8.
It seems that this one is slightly different from the others.

This one is made at commit 3afedb95858bcc117b207a7c0a6767fe891bdfe9 (the first bad commit):

http://imageshack.us/photo/my-images/811/img130hv.jpg

and this one is made at 3.5.rc6+:

http://imageshack.us/photo/my-images/440/img127u.jpg

Regards,
Frank Schäfer

#3 lore raw

Hi Frank,

Quoted 44 lines · On Sunday 15 July 2012 21:39:47 Frank Schäfer wrote:

Am 15.07.2012 14:07, schrieb Laurent Pinchart:

Quoted 33 lines · On Thursday 12 July 2012 21:07:56 Frank Schäfer wrote:
Quoted 18 lines

Hi,

when I start capturing from the UVC-webcam 2232:1005 ("WebCam SCB-0385N") of my netbook, I get a kernel panic. You can find a screenshot of the backtrace here:

http://imageshack.us/photo/my-images/9/img125km.jpg/

This is a regression which has been introduced between kernel 3.2-rc2 and 3.2-rc3 with the following commit:

3afedb95858bcc117b207a7c0a6767fe891bdfe9 is the first bad commit commit 3afedb95858bcc117b207a7c0a6767fe891bdfe9

Author: Laurent Pinchart <[email protected]>
Date:   Thu Nov 3 07:24:34 2011 -0300

[media] uvcvideo: Don't skip erroneous payloads

Quoted 8 lines

Instead of skipping the payload completely, which would make the resulting image corrupted anyway, store the payload normally and mark the buffer as erroneous. If the no_drop module parameter is set to 1 the buffer will then be passed to userspace, and tt will then be up to the application to decide what to do with the buffer.

I'm puzzled. Your screenshot shows the uvc_video_stats_decode() function in the stack trace, but that function wasn't present in 3afedb95858bcc117b207a7c0a6767fe891bdfe9. Could you please send me a stack trace corresponding to 3afedb95858bcc117b207a7c0a6767fe891bdfe9 ?

Quoted 4 lines

Your stack trace looks similar to the problem reported in
https://bugzilla.redhat.com/show_bug.cgi?id=836742.
3afedb95858bcc117b207a7c0a6767fe891bdfe9 might have introduced a different bug, possibly fixed in a later commit.

Hmm... you're right.
The screenshot I've sent to you was made during the bisection process at a commit somewhere between 3.2-rc7 and 3.2-rc8.
It seems that this one is slightly different from the others.

Quoted 8 lines

This one is made at commit 3afedb95858bcc117b207a7c0a6767fe891bdfe9 (the first bad commit):

http://imageshack.us/photo/my-images/811/img130hv.jpg

and this one is made at 3.5.rc6+:

http://imageshack.us/photo/my-images/440/img127u.jpg

Thank you. Could you please try the patch I've attached to
https://bugzilla.redhat.com/show_bug.cgi?id=836742 ?

Signature · 3 lines
Regards,

Laurent Pinchart
#4 lore raw

Am 16.07.2012 01:24, schrieb Laurent Pinchart:

Quoted 48 lines

Hi Frank,

Quoted 45 lines · On Sunday 15 July 2012 21:39:47 Frank Schäfer wrote:

Am 15.07.2012 14:07, schrieb Laurent Pinchart:

Quoted 32 lines · On Thursday 12 July 2012 21:07:56 Frank Schäfer wrote:
Quoted 18 lines

Hi,

when I start capturing from the UVC-webcam 2232:1005 ("WebCam SCB-0385N") of my netbook, I get a kernel panic. You can find a screenshot of the backtrace here:

http://imageshack.us/photo/my-images/9/img125km.jpg/

This is a regression which has been introduced between kernel 3.2-rc2 and 3.2-rc3 with the following commit:

3afedb95858bcc117b207a7c0a6767fe891bdfe9 is the first bad commit commit 3afedb95858bcc117b207a7c0a6767fe891bdfe9

Author: Laurent Pinchart <[email protected]>
Date:   Thu Nov 3 07:24:34 2011 -0300

[media] uvcvideo: Don't skip erroneous payloads

Quoted 8 lines

Instead of skipping the payload completely, which would make the resulting image corrupted anyway, store the payload normally and mark the buffer as erroneous. If the no_drop module parameter is set to 1 the buffer will then be passed to userspace, and tt will then be up to the application to decide what to do with the buffer.

I'm puzzled. Your screenshot shows the uvc_video_stats_decode() function in the stack trace, but that function wasn't present in 3afedb95858bcc117b207a7c0a6767fe891bdfe9. Could you please send me a stack trace corresponding to 3afedb95858bcc117b207a7c0a6767fe891bdfe9 ?

Quoted 4 lines

Your stack trace looks similar to the problem reported in
https://bugzilla.redhat.com/show_bug.cgi?id=836742.
3afedb95858bcc117b207a7c0a6767fe891bdfe9 might have introduced a different bug, possibly fixed in a later commit.

Hmm... you're right.
The screenshot I've sent to you was made during the bisection process at a commit somewhere between 3.2-rc7 and 3.2-rc8.
It seems that this one is slightly different from the others.

This one is made at commit 3afedb95858bcc117b207a7c0a6767fe891bdfe9 (the first bad commit):

Quoted 8 lines
Quoted 5 lines

http://imageshack.us/photo/my-images/811/img130hv.jpg

and this one is made at 3.5.rc6+:

http://imageshack.us/photo/my-images/440/img127u.jpg

Thank you. Could you please try the patch I've attached to
https://bugzilla.redhat.com/show_bug.cgi?id=836742 ?

Thank you Laurent, I can confirm that this patch fixes the bug ! Don't forget to add CC-stable (and a comment that this should be applied to all kernels >=3.2 ?).

Regards,
Frank Schäfer