Red Hat Bugzilla – Bug 39111
use of the ibmcam (usb) causes oops
Last modified: 2007-04-18 12:33:03 EDT
Description of Problem: Usage of the ibmcam on usb cases an oops in the current 2.4.3-2.14.17smp kernel How Reproducible: modprobe -v ibmcam vidcat > /tmp/test.jpg (vidcat is part of the w3cam package found on http://www.hdk-berlin.de/~rasca/w3cam/ it's primary purpose is to open /dev/video0 stream the raw data from the device and re-encode it as a png,jpg etc..) ..... Linux video capture interface: v1.00 usb.c: registered new driver ibmcam ibmcam.c: IBM USB camera found (model 3, rev. 0x0301) ibmcam.c: IBM camera: using 320x240 usbvideo.c: ibmcam on /dev/video0: canvas=320x240 videosize=320x240 Unable to handle kernel paging request at virtual address 1ffffc00017e1e9c vidcat(976): Oops 0 pc = [<fffffc000097a9d4>] ra = [<fffffffc0030aa58>] ps = 0007 v0 = 0000000000000000 t0 = 1ffffc00017e1e9c t1 = ffffffff7fffffff t2 = fffffc00017e1ea0 t3 = ffffffffffffffff t4 = 0000000000000000 t5 = 0000000000000000 t6 = fffffc00017e1ea0 t7 = fffffc00197a8000 s0 = fffffc001faa0950 s1 = fffffc0000584740 s2 = 0000000000000007 s3 = 0000000000000000 s4 = fffffc00197abd58 s5 = fffffc001fb05ac0 s6 = 000000000000001e a0 = 0000000000000007 a1 = 0000000000000007 a2 = fffffc00197abd58 a3 = 0000000000000001 a4 = 0000000000000001 a5 = 0000000000000080 t8 = fffffc00017e1e80 t9 = fffffc00017e1e80 t10= 0000000000000000 t11= 0000000000000080 pv = fffffc000097a7d0 at = 0000000000000000 gp = fffffc0000b77658 sp = fffffc00197abcc8 Code: 205f0001 lda t1,1(zero) 48410722 sll t1,t0,t1 20630020 lda t2,32(t2) 4880b681 srl t3,5,t0 47e20502 ornot zero,t1,t1 40230441 s4addq t0,t2,t0 *a8a10000 ldl_l t4,0(t0) 44a20005 and t4,t1,t4 Trace:fffffc0000857d20 fffffc0000856428 fffffc0000856574 fffffc0000856450 fffffc0000856960 fffffc0000856948 fffffc0000810b90 a quick gdb disassemble of where the program counter was shows that the oops is spawned out from pci_pool_alloc 0xfffffc000097a9c4 <pci_pool_alloc+500>: lda t2,32(t2) 0xfffffc000097a9c8 <pci_pool_alloc+504>: srl t3,0x5,t0 0xfffffc000097a9cc <pci_pool_alloc+508>: not t1,t1 0xfffffc000097a9d0 <pci_pool_alloc+512>: s4addq t0,t2,t0 -------- 0xfffffc000097a9d4 <pci_pool_alloc+516>: ldl_l t4,0(t0) 0xfffffc000097a9d8 <pci_pool_alloc+520>: and t4,t1,t4 -------- 0xfffffc000097a9dc <pci_pool_alloc+524>: stl_c t4,0(t0) 0xfffffc000097a9e0 <pci_pool_alloc+528>: beq t4,0xfffffc000097acb8 <pci_pool_free+472> 0xfffffc000097a9e4 <pci_pool_alloc+532>: sll at,0x6,t2 pci_pool_alloc is found in drivers/pci/pci.c so I rebuilt the kernel again making sure to compile the pci.c file with debugging enabled and creating the .s file After a reboot and oops on this newer kernel, I see this assembler fragment again 40230441 s4addq t0,t2,t0 *a8a10000 ldl_l t4,0(t0) 44a20005 and t4,t1,t4 which in pci.s is seen as (you have to use /usr/include/alpha/regdefs.h to translate from Tru64isms to GNUisms) $LM1118: .stabn 68,0,93,$LM1118 s4addq $1,$3,$1 $LM1119: .stabn 68,0,110,$LM1119 1: ldl_l $5,0($1) and $5,$2,$5 stl_c $5,0($1) beq $5,2f .subsection 2 2: br 1b Which indicates that the oops is afallout from line 110 (.stabn 68,0,110,$LM1119) in pci.c Going to line 110 on pci.c shows ---> struct pci_dev * pci_find_device(unsigned int vendor, unsigned int device, const struct pci_dev \*from) { return pci_find_subsys(vendor, device, PCI_ANY_ID, PCI_ANY_ID, from); } which indicates that the structure is somehow munched. I'm sorry that I can't progress this any further than what I describe above.. Phil =--=
Is there a way to see a call backtrace?
Still seeing this stuff I've made a better attempt at reporting it here http://ftp.uk.linux.org/pub/linux/redhat/alpha/Decodeing-oops-on-alpha.howto.html Phil =--=
Zaitcev, did any of the above help at all?
My love with Dmitry's driver is not very smooth, more the pity.
A few questions: 1. May we have some printk's inserted into ibmcam_model2_setup and such places to pinpoint the problem? 2. Did LED come on before the crash? 3. What does ra register point?
1. I'll respond in a moment or two when I get a chance to rebuild,.. 2. the LED does come on, the kernel oops's and the LED stays on thereafter 3. RA = return address, ie where do I jump back to after I branch
Before we start with divide and conquer by printks, please re-run the whole shebang with "debug=3" for ibmcam. This also turns debugging in usbvideo, which is I am after. Another thing - I would appreciate you switching to a more current kernel. Remember the discrepancy in pci_pool_alloc that we identified online.
None of the 2.4.5 kernels currently compile for the alpha,.. I'm kinda stuck with this one for the moment,... usb.c: registered new driver ibmcam ibmcam.c: ibmcam_probe(fffffc0000a9dd00,0.) ibmcam.c: IBM USB camera found (model 3, rev. 0x0301) ibmcam.c: Number of alternate settings=2. ibmcam.c: Active setting=1. maxPS=1022. ibmcam.c: IBM camera: using 320x240 usbvideo.c: usbvideo_RegisterVideoDevice: iface=0. endpoint=$81 paletteBits=$00000010 usbvideo.c: usbvideo_RegisterVideoDevice: video_register_device() successful usbvideo.c: ibmcam on /dev/video0: canvas=320x240 videosize=320x240 Executing vidcat and the extra lines are.... ------------------------------ usbvideo.c: usbvideo_v4l_open($fffffc001163d1f8,$00000000 usbvideo.c: usbvideo_StartDataPump($fffffc001163d1f8) ibmcam.c: ibmcam_change_lighting_conditions: Set lighting to 1. Unable to handle kernel paging request at virtual address 1ffffc000060b0dc CPU 0 vidcat(674): Oops 0 <blah..>
Sorry about this, Bryce. I am kinda too busy, so moving this out of the way with WONTFIX.