Hello, all.
As some of you know, I've been pounding at getting the Cyrix MediaGX +
Kernel 2.4.x series + ov511 camera to play nicely together.
A couple notes first, and a little history -
This is a Cyrix MediaGX 233 system, 8GB hard disk (DMA turned off,
wierd/bad things happen with it enabled), 64MB RAM, and a D-Link C300 USB
camera. It's running a custom/stripped down version of RedHat 6.2,
updated at the appropriate places for Kernel 2.4. I'm trying to grab
simple 640x480 frames from the ov511 based camera about every 15-30
seconds.
After my initial post about 5 days ago about random oopses in both 2.4.2
and 2.4.3, several replies were sent, one by David Brownell about
reverting to kernel 2.4.2, with Alan Cox's last pre-patch (ac28), and
apply pci-pool and ohci patches from 03/23, and enable kernel debugging
and slab poisoning, one from Pete Zaitcev pointing to a patch dealing with
device initialization, and another from Mark McClelland about ov511 v1.35
being available.
I took David's approach first, and it did two things, not the least of
which *seemed* to be eliminating the oopses, as it ran for a solid 24
hours before I started the experiment. But, it also seemed to result in
total garbage from the camera, with mostly green, pink, and blue
"compression squares" the entire JPEG image (from vidcat 0.62). I then
quick upgraded to ov511 v1.35 with the same results.
I should also add that I'm compiling the kernel on an identically
configured (software and kernel config wise) Intel P5-233 machine and
FTP'ing the resultant files over to the Cyrix MediaGX to save me a whole
bunch of time in compilation. (I don't think that should have *any*
adverse effect here, should it?)
So, I decided to backtrack a little, approach it scientifically and
incrementally, and try to see where things went wrong. I'll apologize if
this is all old news, I didn't see anything obvious from the mailing list,
and I'm no kernel or driver wizard, so it is possible that I killed a
bunch of my time for nothing :)
First, I reverted all the way back to vanilla Kernel 2.4.2 .
Kernel 2.4.2 will load the needed modules fine, and grab good frames from
the camera for awhile, but how long it runs is sort of gamble, and then
will mysteriously oops, and die.
Kernel 2.4.2-ac28 with the same kernel options (and no
CONFIG_DEBUG_KERNEL=y, CONFIG_DEBUG_SLAB=y yet as David Brownell
suggested) does about the same as vanilla 2.4.2. Good frames, but will
eventually oops.
However, with Kernel 2.4.2-ac28 and enabling kernel debugging and slab
poisoning (CONFIG_DEBUG_KERNEL=y, CONFIG_DEBUG_SLAB=y), I load usbcore
first, and then get an immediate oops when loading the usb-ohci module.
The oops is:
invalid operand: 0000
CPU: 0
EIP: 0010:[<c01242ea>]
EFLAGS: 00010082
eax: a55a5a5a ebx: c3b6d000 ecx: c3b6d3f4 edx: 124c0000
esi: c3b6d3cc edi: c3b6d40c ebp: c110d0a0 esp: c3855c18
ds: 0018 es: 0018 ss: 0018
Process syslogd (pid: 318, stackpage=c3855000)
Stack: 00000000 c3b6d3fc c3b6d40c c3b6d3fc 00000007 c0117445 c3854000
00000082
c481a083 c3b6d3d0 c3812764 c3b6d3fc 00000000 c481a0ef c3e7ea94
c3b6d3fc
00000297 c3b6d3fc c481a116 c3812764 c3812764 c481a21c c3812764
00000000
Call Trace: [<c0117445>] [<c481a083>] [<c481a0ef>] [<c481a116>]
[<c481a21c>] [<c481bbbf>] [<c481f000>]
[<c481c7a7>] [<c0107fdd>] [<c0108147>] [<c0106e50>] [<c01e82cf>]
[<c0190018>] [<c016e2a9>] [<c0160010>]
[<c011450c>] [<c012bba1>] [<c012c7ef>] [<c0114368>] [<c0124346>]
[<c01aa903>] [<c01aa917>] [<c01aaa83>]
[<c01ac3c0>] [<c01db9fb>] [<c0126b86>] [<c012da71>] [<c0121627>]
[<c01216b7>] [<c012b14f>] [<c01211f4>]
[<c01499b4>] [<c01499a2>] [<c012bedb>] [<c0106d93>]
Code: 0f 0b 8b 4d 10 f6 c5 08 74 4a 89 74 24 10 8b 55 0c 89 54 24
<0>Kernel panic: Aiee, killing interrupt handler!
And, when run through ksymoops (with usbcore loaded), I get:
ksymoops 2.4.1 on i586 2.4.2-ac28. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.2-ac28/ (default)
-m /boot/System.map (specified)
invalid operand: 0000
CPU: 0
EIP: 0010:[<c01242ea>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010082
eax: a55a5a5a ebx: c3b6d000 ecx: c3b6d3f4 edx: 124c0000
esi: c3b6d3cc edi: c3b6d40c ebp: c110d0a0 esp: c3855c18
ds: 0018 es: 0018 ss: 0018
Process syslogd (pid: 318, stackpage=c3855000)
Stack: 00000000 c3b6d3fc c3b6d40c c3b6d3fc 00000007 c0117445 c3854000
00000082
c481a083 c3b6d3d0 c3812764 c3b6d3fc 00000000 c481a0ef c3e7ea94
c3b6d3fc
00000297 c3b6d3fc c481a116 c3812764 c3812764 c481a21c c3812764
00000000
Call Trace: [<c0117445>] [<c481a083>] [<c481a0ef>] [<c481a116>]
[<c481a21c>] [<c481bbbf>] [<c481f000>]
[<c481c7a7>] [<c0107fdd>] [<c0108147>] [<c0106e50>] [<c01e82cf>]
[<c0190018>] [<c016e2a9>] [<c0160010>]
[<c011450c>] [<c012bba1>] [<c012c7ef>] [<c0114368>] [<c0124346>]
[<c01aa903>] [<c01aa917>] [<c01aaa83>]
[<c01ac3c0>] [<c01db9fb>] [<c0126b86>] [<c012da71>] [<c0121627>]
[<c01216b7>] [<c012b14f>] [<c01211f4>]
[<c01499b4>] [<c01499a2>] [<c012bedb>] [<c0106d93>]
Code: 0f 0b 8b 4d 10 f6 c5 08 74 4a 89 74 24 10 8b 55 0c 89 54 24
>>EIP; c01242ea <kfree+132/220> <=====
Trace; c0117445 <update_process_times+1d/94>
Trace; c481a083 <__kstrtab_usb_devfs_handle+12ca/????>
Trace; c481a0ef <__kstrtab_usb_devfs_handle+1336/????>
Trace; c481a116 <__kstrtab_usb_devfs_handle+135d/????>
Trace; c481a21c <__kstrtab_usb_devfs_handle+1463/????>
Trace; c481bbbf <__kstrtab_usb_devfs_handle+2e06/????>
Trace; c481f000 <__kstrtab_usb_devfs_handle+6247/????>
Trace; c481c7a7 <__kstrtab_usb_devfs_handle+39ee/????>
Trace; c0107fdd <handle_IRQ_event+31/5c>
Trace; c0108147 <do_IRQ+6b/ac>
Trace; c0106e50 <ret_from_intr+0/20>
Trace; c01e82cf <__const_udelay+1b/2c>
Trace; c0190018 <ide_stall_queue+18/24>
Trace; c016e2a9 <generic_unplug_device+25/28>
Trace; c0160010 <exp_procfs_exports+64/2d4>
Trace; c011450c <__run_task_queue+50/64>
Trace; c012bba1 <__wait_on_buffer+71/9c>
Trace; c012c7ef <fsync_inode_buffers+db/11c>
Trace; c0114368 <tasklet_hi_action+3c/60>
Trace; c0124346 <kfree+18e/220>
Trace; c01aa903 <skb_release_data+67/70>
Trace; c01aa917 <kfree_skbmem+b/58>
Trace; c01aaa83 <__kfree_skb+11f/128>
Trace; c01ac3c0 <skb_free_datagram+1c/20>
Trace; c01db9fb <unix_dgram_recvmsg+10b/118>
Trace; c0126b86 <nr_free_buffer_pages+e/58>
Trace; c012da71 <generic_commit_write+55/60>
Trace; c0121627 <generic_file_write+433/604>
Trace; c01216b7 <generic_file_write+4c3/604>
Trace; c012b14f <do_readv_writev+1cb/250>
Trace; c01211f4 <generic_file_write+0/604>
Trace; c01499b4 <ext2_fsync_inode+c/48>
Trace; c01499a2 <ext2_sync_file+12/18>
Trace; c012bedb <sys_fsync+5b/88>
Trace; c0106d93 <system_call+33/40>
Code; c01242ea <kfree+132/220>
00000000 <_EIP>:
Code; c01242ea <kfree+132/220> <=====
0: 0f 0b ud2a <=====
Code; c01242ec <kfree+134/220>
2: 8b 4d 10 mov 0x10(%ebp),%ecx
Code; c01242ef <kfree+137/220>
5: f6 c5 08 test $0x8,%ch
Code; c01242f2 <kfree+13a/220>
8: 74 4a je 54 <_EIP+0x54> c012433e
<kfree+186/220>
Code; c01242f4 <kfree+13c/220>
a: 89 74 24 10 mov %esi,0x10(%esp,1)
Code; c01242f8 <kfree+140/220>
e: 8b 55 0c mov 0xc(%ebp),%edx
Code; c01242fb <kfree+143/220>
11: 89 54 24 00 mov %edx,0x0(%esp,1)
<0>Kernel panic: Aiee, killing interrupt handler!
Now, I haven't a clue where that puts me :) I did check, and it's
perfectly repeatable. (BTW, thanks Pete, I knew about serial consoles a
long time ago, just never bothered to set one up before - never needed to.
Now I do, I did, and it saved about 15 minutes of typing the oops in by
hand.)
I'm planning on continuing my magic journey, applying the pci-pool patch
next, seeing if that oops goes away and if good grabs can be had. Then
ohci patch, and so on.
Also, taking that same compiled kernel (2.4.2-ac28 with kernel debugging
and slab poisoning enabled) it doesn't work correctly either (but doesn't
oops), with this in the message log:
Apr 7 17:04:31 devel-uhci kernel: usb.c: registered new driver usbdevfs
Apr 7 17:04:31 devel-uhci kernel: usb.c: registered new driver hub
Apr 7 17:04:31 devel-uhci kernel: usb-uhci.c: $Revision: 1.251 $ time 15:56:36 Apr 7
2001
Apr 7 17:04:31 devel-uhci kernel: usb-uhci.c: High bandwidth mode enabled
Apr 7 17:04:31 devel-uhci kernel: PCI: Found IRQ 12 for device 00:01.2
Apr 7 17:04:31 devel-uhci kernel: usb-uhci.c: USB UHCI at I/O 0xd800, IRQ 12
Apr 7 17:04:31 devel-uhci kernel: usb-uhci.c: Detected 2 ports
Apr 7 17:04:31 devel-uhci kernel: usb.c: new USB bus registered, assigned bus number 1
Apr 7 17:04:31 devel-uhci kernel: usb-uhci.c: interrupt, status 30, frame# 0
Apr 7 17:04:31 devel-uhci kernel: hub.c: USB hub found
Apr 7 17:04:31 devel-uhci kernel: hub.c: 2 ports detected
Apr 7 17:04:31 devel-uhci kernel: Linux video capture interface: v1.00
Apr 7 17:04:31 devel-uhci kernel: hub.c: USB new device connect on bus1/2, assigned
device number 2
Apr 7 17:04:31 devel-uhci kernel: usb.c: registered new driver ov511
Apr 7 17:04:31 devel-uhci kernel: ov511.c: ov511 driver version 1.28 registered
Apr 7 17:04:34 devel-uhci kernel: usb_control/bulk_msg: timeout
Apr 7 17:04:34 devel-uhci kernel: usb.c: USB device not accepting new address=2
(error=-110)
Apr 7 17:04:34 devel-uhci kernel: hub.c: USB new device connect on bus1/2, assigned
device number 3
Apr 7 17:04:37 devel-uhci kernel: usb_control/bulk_msg: timeout
Apr 7 17:04:37 devel-uhci kernel: usb.c: USB device not accepting new address=3
(error=-110)
As always, any and all help, suggestions, whatever, are more than welcome.
So close, but yet so far it seems...
Brad
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
