Bug 39111 - use of the ibmcam (usb) causes oops
Summary: use of the ibmcam (usb) causes oops
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 7.1
Hardware: alpha
OS: Linux
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2001-05-04 15:48 UTC by Phil Copeland
Modified: 2007-04-18 16:33 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-06-12 00:51:44 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Phil Copeland 2001-05-04 15:48:52 UTC
Description of Problem:
Usage of the ibmcam on usb cases an oops in the current 2.4.3-2.14.17smp

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
 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)

        .stabn 68,0,93,$LM1118
        s4addq $1,$3,$1
        .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


Comment 1 Pete Zaitcev 2001-05-07 17:08:25 UTC
Is there a way to see a call backtrace?

Comment 2 Phil Copeland 2001-05-29 23:06:13 UTC
Still seeing this stuff

I've made a better attempt at reporting it here



Comment 3 Phil Copeland 2001-06-04 20:04:34 UTC
Zaitcev, did any of the above help at all?

Comment 4 Pete Zaitcev 2001-06-04 20:22:55 UTC
My love with Dmitry's driver is not very smooth, more the pity.

Comment 5 Pete Zaitcev 2001-06-06 19:28:43 UTC
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?

Comment 6 Phil Copeland 2001-06-06 19:46:56 UTC
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

Comment 7 Pete Zaitcev 2001-06-09 05:26:11 UTC
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.

Comment 8 Phil Copeland 2001-06-12 00:51:40 UTC
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
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

Comment 9 Pete Zaitcev 2001-08-16 16:58:07 UTC
Sorry about this, Bryce. I am kinda too busy, so
moving this out of the way with WONTFIX.

Note You need to log in before you can comment on or make changes to this bug.