I'm not sure what caused this exactly -- I unplugged a USB hub and then
did a ls in the hub's directory in the devicefs. The ls died (in D
state), and I found this in my logs.
ksymoops 2.4.4 on i586 2.5.31. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.5.31/ (default)
-m /boot/System.map-2.5.31 (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Aug 25 02:44:59 entropy kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000005c
Aug 25 02:44:59 entropy kernel: c015b40f
Aug 25 02:44:59 entropy kernel: *pde = 00000000
Aug 25 02:44:59 entropy kernel: Oops: 0002
Aug 25 02:44:59 entropy kernel: CPU: 0
Aug 25 02:44:59 entropy kernel: EIP: 0060:[<c015b40f>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
Aug 25 02:44:59 entropy kernel: EFLAGS: 00010206
Aug 25 02:44:59 entropy kernel: eax: c49537d4 ebx: 0000005c ecx: 0000005c edx: 00000000
Aug 25 02:44:59 entropy kernel: esi: c39c2688 edi: 00000000 ebp: c056dd48 esp: c4841ef4
Aug 25 02:44:59 entropy kernel: ds: 0068 es: 0068 ss: 0068
Aug 25 02:44:59 entropy kernel: Stack: c39c2688 c056de28 c056dd20 c015bbff c49537d4 c39c2688 c33eb0d0 c33eb210
Aug 25 02:44:59 entropy kernel: ffffffff c33eb000 c016d910 c33eb168 c33eb0d0 c33eb0d0 c33eb000 c581616a
Aug 25 02:44:59 entropy kernel: c33eb0d0 c33eb000 000000d8 00000100 c3b27400 00000002 00000001 c5817edf
Aug 25 02:44:59 entropy kernel: Call Trace: [<c015bbff>] [<c016d910>] [<c581616a>] [<c5817edf>] [<c58181df>]
Aug 25 02:44:59 entropy kernel: [<c58233ee>] [<c5818360>] [<c581838b>] [<c5818360>] [<c0110820>] [<c01055a5>]
Aug 25 02:44:59 entropy kernel: Code: ff 4f 5c 0f 88 39 08 00 00 8b 46 08 66 ff 48 24 56 e8 fb ab
>>EIP; c015b40f <driverfs_unlink+f/40> <=====
Trace; c015bbff <driverfs_remove_dir+4f/a1>
Trace; c016d910 <put_device+80/b0>
Trace; c581616a <[usbcore]usb_disconnect+ea/110>
Trace; c5817edf <[usbcore]usb_hub_port_connect_change+4f/250>
Trace; c58181df <[usbcore]usb_hub_events+ff/280>
Trace; c58233ee <[usbcore].rodata.end+3673/8125>
Trace; c5818360 <[usbcore]usb_hub_thread+0/e0>
Trace; c581838b <[usbcore]usb_hub_thread+2b/e0>
Trace; c5818360 <[usbcore]usb_hub_thread+0/e0>
Trace; c0110820 <default_wake_function+0/40>
Trace; c01055a5 <kernel_thread_helper+5/10>
Code; c015b40f <driverfs_unlink+f/40>
00000000 <_EIP>:
Code; c015b40f <driverfs_unlink+f/40> <=====
0: ff 4f 5c decl 0x5c(%edi) <=====
Code; c015b412 <driverfs_unlink+12/40>
3: 0f 88 39 08 00 00 js 842 <_EIP+0x842> c015bc51 <.text.lock.inode+0/bf>
Code; c015b418 <driverfs_unlink+18/40>
9: 8b 46 08 mov 0x8(%esi),%eax
Code; c015b41b <driverfs_unlink+1b/40>
c: 66 ff 48 24 decw 0x24(%eax)
Code; c015b41f <driverfs_unlink+1f/40>
10: 56 push %esi
Code; c015b420 <driverfs_unlink+20/40>
11: e8 fb ab 00 00 call ac11 <_EIP+0xac11> c0166020 <sys_shmctl+170/880>
1 warning issued. Results may not be reliable.
On 25 Aug 2002, Nicholas Miell wrote:
> I'm not sure what caused this exactly -- I unplugged a USB hub and then
> did a ls in the hub's directory in the devicefs. The ls died (in D
> state), and I found this in my logs.
> 00000000 <_EIP>:
> Code; c015b40f <driverfs_unlink+f/40> <=====
> 0: ff 4f 5c decl 0x5c(%edi) <=====
> Code; c015b412 <driverfs_unlink+12/40>
> 3: 0f 88 39 08 00 00 js 842 <_EIP+0x842> c015bc51 <.text.lock.inode+0/bf>
> Code; c015b418 <driverfs_unlink+18/40>
> 9: 8b 46 08 mov 0x8(%esi),%eax
> Code; c015b41b <driverfs_unlink+1b/40>
> c: 66 ff 48 24 decw 0x24(%eax)
> Code; c015b41f <driverfs_unlink+1f/40>
> 10: 56 push %esi
> Code; c015b420 <driverfs_unlink+20/40>
> 11: e8 fb ab 00 00 call ac11 <_EIP+0xac11> c0166020 <sys_shmctl+170/880>
A dentry has been created with no inode associated with it, and
driverfs_unlink() attempts to access it without checking it.
Could you please try the attached patch and let me know if it helps?
Thanks,
-pat
===== fs/driverfs/inode.c 1.48 vs edited =====
--- 1.48/fs/driverfs/inode.c Mon Aug 5 11:13:07 2002
+++ edited/fs/driverfs/inode.c Sun Aug 25 15:13:51 2002
@@ -211,11 +211,13 @@
static int driverfs_unlink(struct inode *dir, struct dentry *dentry)
{
struct inode *inode = dentry->d_inode;
- down(&inode->i_sem);
- dentry->d_inode->i_nlink--;
- dput(dentry);
- up(&inode->i_sem);
- d_delete(dentry);
+ if (inode) {
+ down(&inode->i_sem);
+ dentry->d_inode->i_nlink--;
+ dput(dentry);
+ up(&inode->i_sem);
+ d_delete(dentry);
+ }
return 0;
}
On Sun, 2002-08-25 at 15:22, Patrick Mochel wrote:
>
> A dentry has been created with no inode associated with it, and
> driverfs_unlink() attempts to access it without checking it.
>
> Could you please try the attached patch and let me know if it helps?
>
> Thanks,
>
> -pat
No help.
The first oops occurred immediately when the hub was unplugged (I was on
a console this time, not X, so I could see the oops live).
The second oops was caused by execing "ls" in
/devices/root/pci0/00:08.0/usb_bus
Both appear to be caused by slab poisoning.
(btw, this isn't straight 2.5.31, it is the BK tree as of about 15:25
PST yesterday)
ksymoops 2.4.4 on i586 2.5.31. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.5.31/ (default)
-m /boot/System.map-2.5.31 (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Aug 25 15:42:48 entropy kernel: Unable to handle kernel paging request at virtual address 5a5a5a5e
Aug 25 15:42:48 entropy kernel: c0146d79
Aug 25 15:42:48 entropy kernel: *pde = 00000000
Aug 25 15:42:48 entropy kernel: Oops: 0002
Aug 25 15:42:48 entropy kernel: CPU: 0
Aug 25 15:42:48 entropy kernel: EIP: 0060:[<c0146d79>] Not tainted
Aug 25 15:42:48 entropy kernel: EFLAGS: 00010206
Aug 25 15:42:48 entropy kernel: eax: c49b47f4 ebx: c49b47e4 ecx: 5a5a5a5a edx: 5a5a5a5a
Aug 25 15:42:48 entropy kernel: esi: c1bb0314 edi: c49b47e4 ebp: c49b4c20 esp: c4843ed4
Aug 25 15:42:48 entropy kernel: ds: 0068 es: 0068 ss: 0068
Aug 25 15:42:48 entropy kernel: Stack: 00000286 00070fd0 00000282 c10cb280 c1bb0370 c1bb0314 c015b43b c49b47e4
Aug 25 15:42:48 entropy kernel: c49b47e4 c49b4c8c c49b4bf8 c015bc0f c1b63a44 c49b47e4 c4b824d0 c4b82610
Aug 25 15:42:48 entropy kernel: ffffffff c4b82400 c016d920 c4b82568 c4b824d0 c4b824d0 c4b82400 c581616a
Aug 25 15:42:48 entropy kernel: Call Trace: [<c015b43b>] [<c015bc0f>] [<c016d920>] [<c581616a>] [<c5817edf>]
Aug 25 15:42:48 entropy kernel: [<c58181df>] [<c58233ee>] [<c5818360>] [<c581838b>] [<c5818360>] [<c0110820>]
Aug 25 15:42:48 entropy kernel: [<c01055a5>]
Aug 25 15:42:48 entropy kernel: Code: 89 4a 04 89 11 c7 43 10 00 00 00 00 c7 40 04 00 00 00 00 89
>>EIP; c0146d79 <d_delete+59/80> <=====
Trace; c015b43b <driverfs_unlink+3b/50>
Trace; c015bc0f <driverfs_remove_dir+4f/a1>
Trace; c016d920 <put_device+80/b0>
Trace; c581616a <[usbcore]usb_disconnect+ea/110>
Trace; c5817edf <[usbcore]usb_hub_port_connect_change+4f/250>
Trace; c58181df <[usbcore]usb_hub_events+ff/280>
Trace; c58233ee <[usbcore].rodata.end+3673/8125>
Trace; c5818360 <[usbcore]usb_hub_thread+0/e0>
Trace; c581838b <[usbcore]usb_hub_thread+2b/e0>
Trace; c5818360 <[usbcore]usb_hub_thread+0/e0>
Trace; c0110820 <default_wake_function+0/40>
Trace; c01055a5 <kernel_thread_helper+5/10>
Code; c0146d79 <d_delete+59/80>
00000000 <_EIP>:
Code; c0146d79 <d_delete+59/80> <=====
0: 89 4a 04 mov %ecx,0x4(%edx) <=====
Code; c0146d7c <d_delete+5c/80>
3: 89 11 mov %edx,(%ecx)
Code; c0146d7e <d_delete+5e/80>
5: c7 43 10 00 00 00 00 movl $0x0,0x10(%ebx)
Code; c0146d85 <d_delete+65/80>
c: c7 40 04 00 00 00 00 movl $0x0,0x4(%eax)
Code; c0146d8c <d_delete+6c/80>
13: 89 00 mov %eax,(%eax)
Aug 25 15:43:08 entropy kernel: <1>Unable to handle kernel paging request at virtual address 5a5a5aca
Aug 25 15:43:08 entropy kernel: c013e6ef
Aug 25 15:43:08 entropy kernel: *pde = 00000000
Aug 25 15:43:08 entropy kernel: Oops: 0000
Aug 25 15:43:08 entropy kernel: CPU: 0
Aug 25 15:43:08 entropy kernel: EIP: 0060:[<c013e6ef>] Not tainted
Aug 25 15:43:08 entropy kernel: EFLAGS: 00010246
Aug 25 15:43:08 entropy kernel: eax: c4b40080 ebx: 00000003 ecx: c1bfbf70 edx: c1bfbed4
Aug 25 15:43:08 entropy kernel: esi: 00000003 edi: c1bfbf70 ebp: 5a5a5a5a esp: c1bfbec0
Aug 25 15:43:08 entropy kernel: ds: 0068 es: 0068 ss: 0068
Aug 25 15:43:08 entropy kernel: Stack: c1bfbed4 00000003 c474c000 c10dd368 c488ef44 00000000 00000000 00000000
Aug 25 15:43:08 entropy kernel: 0000201b 00000a03 00002503 0000201b 00000003 c1bfbf60 c0122c8d c474c005
Aug 25 15:43:08 entropy kernel: 00000004 01b42f73 c1d061c8 00000003 00000003 c1bfbf70 00018801 c013f6ec
Aug 25 15:43:08 entropy kernel: Call Trace: [<c0122c8d>] [<c013f6ec>] [<c010f190>] [<c010757d>] [<c01343d4>]
Aug 25 15:43:08 entropy kernel: [<c0134755>] [<c0107347>]
Aug 25 15:43:08 entropy kernel: Code: 8b 45 70 89 14 24 eb 09 8b 45 70 8d b6 00 00 00 00 66 8b 5d
>>EIP; c013e6ef <link_path_walk+6f/880> <=====
Trace; c0122c8d <vm_enough_memory+2d/c0>
Trace; c013f6ec <open_namei+7c/3d0>
Trace; c010f190 <do_page_fault+0/48f>
Trace; c010757d <error_code+2d/40>
Trace; c01343d4 <filp_open+34/60>
Trace; c0134755 <sys_open+35/70>
Trace; c0107347 <syscall_call+7/b>
Code; c013e6ef <link_path_walk+6f/880>
00000000 <_EIP>:
Code; c013e6ef <link_path_walk+6f/880> <=====
0: 8b 45 70 mov 0x70(%ebp),%eax <=====
Code; c013e6f2 <link_path_walk+72/880>
3: 89 14 24 mov %edx,(%esp,1)
Code; c013e6f5 <link_path_walk+75/880>
6: eb 09 jmp 11 <_EIP+0x11> c013e700 <link_path_walk+80/880>
Code; c013e6f7 <link_path_walk+77/880>
8: 8b 45 70 mov 0x70(%ebp),%eax
Code; c013e6fa <link_path_walk+7a/880>
b: 8d b6 00 00 00 00 lea 0x0(%esi),%esi
Code; c013e700 <link_path_walk+80/880>
11: 66 8b 5d 00 mov 0x0(%ebp),%bx
1 warning issued. Results may not be reliable.
On Sun, Aug 25, 2002 at 03:08:12AM -0700, Nicholas Miell wrote:
> I'm not sure what caused this exactly -- I unplugged a USB hub and then
> did a ls in the hub's directory in the devicefs. The ls died (in D
> state), and I found this in my logs.
Does this still happen on 2.5.32? I was unable to reproduce it on
either 2.5.31, 2.5.31-bk, or 2.5.32.
thanks,
greg k-h
On Tue, 2002-08-27 at 22:46, Greg KH wrote:
> Does this still happen on 2.5.32? I was unable to reproduce it on
> either 2.5.31, 2.5.31-bk, or 2.5.32.
>
I can reproduce the oops reliably -- but you have to enable slab
poisoning to do it.
I just did it again with pure 2.5.33 (plus some minor patches to get it
to compile -- nothing USB related)
This is my device tree before I do anything:
root/
root/pci0
root/pci0/00:0f.1
root/pci0/00:0f.0
root/pci0/00:0b.0
root/pci0/00:0a.0
root/pci0/00:08.0
root/pci0/00:08.0/usb_bus
root/pci0/00:08.0/usb_bus/1
root/pci0/00:08.0/usb_bus/1/00:08.0-1:0
root/pci0/00:08.0/usb_bus/00:08.0-0:0
root/isapnp1
root/isapnp1/0
root/sys
root/sys/03?0
root/sys/0040
root/sys/0020
In a term, chdir to root/pci0/00:08.0/usb_bus/1/00:08.0-1:0, and then
unplug the hub. The following oops occurs:
Sep 1 11:55:14 entropy kernel: usb.c: USB disconnect on device 2
Sep 1 11:55:14 entropy kernel: Unable to handle kernel paging request at virtual address 5a5a5a5e
Sep 1 11:55:14 entropy kernel: printing eip:
Sep 1 11:55:14 entropy kernel: c0148f99
Sep 1 11:55:14 entropy kernel: *pde = 00000000
Sep 1 11:55:14 entropy kernel: Oops: 0002
Sep 1 11:55:14 entropy kernel: CPU: 0
Sep 1 11:55:14 entropy kernel: EIP: 0060:[<c0148f99>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
Sep 1 11:55:14 entropy kernel: EFLAGS: 00010206
Sep 1 11:55:14 entropy kernel: eax: c33afcf0 ebx: c33afce0 ecx: 5a5a5a5a edx: 5a5a5a5a
Sep 1 11:55:14 entropy kernel: esi: c33afce0 edi: c24b5a64 ebp: c33afa50 esp: c4df5ed4
Sep 1 11:55:14 entropy kernel: ds: 0068 es: 0068 ss: 0068
Sep 1 11:55:14 entropy kernel: Process khubd (pid: 93, threadinfo=c4df4000 task=c487cb80)
Sep 1 11:55:15 entropy kernel: Stack: 00000286 000b5400 00000286 c10cb280 c24b5ac0 c33afce0 c015f027 c33afce0
Sep 1 11:55:15 entropy kernel: c33afce0 c33afba4 c33afa28 c015f7ef c24b5314 c33afce0 c3da3cd0 c3da3e1c
Sep 1 11:55:15 entropy kernel: c58422a4 c3da3c00 c0171a50 c3da3d70 c3da3cd0 c3da3cd0 c3da3c40 c583509a
Sep 1 11:55:15 entropy kernel: Call Trace: [<c015f027>] [<c015f7ef>] [<c58422a4>] [<c0171a50>] [<c583509a>]
Sep 1 11:55:15 entropy kernel: [<c5836f2f>] [<c583722f>] [<c58426bb>] [<c58373b0>] [<c58373db>] [<c58373b0>]
Sep 1 11:55:15 entropy kernel: [<c01123d0>] [<c0107145>]
Sep 1 11:55:15 entropy kernel: Code: 89 4a 04 89 11 c7 43 10 00 00 00 00 c7 40 04 00 00 00 00 89
>>EIP; c0148f99 <d_delete+59/80> <=====
Trace; c015f027 <driverfs_unlink+37/40>
Trace; c015f7ef <driverfs_remove_dir+4f/a1>
Trace; c58422a4 <[usbcore].rodata.end+3429/84c5>
Trace; c0171a50 <put_device+80/b0>
Trace; c583509a <[usbcore]usb_disconnect+ea/110>
Trace; c5836f2f <[usbcore]usb_hub_port_connect_change+4f/250>
Trace; c583722f <[usbcore]usb_hub_events+ff/280>
Trace; c58426bb <[usbcore].rodata.end+3840/84c5>
Trace; c58373b0 <[usbcore]usb_hub_thread+0/e0>
Trace; c58373db <[usbcore]usb_hub_thread+2b/e0>
Trace; c58373b0 <[usbcore]usb_hub_thread+0/e0>
Trace; c01123d0 <default_wake_function+0/40>
Trace; c0107145 <kernel_thread_helper+5/10>
Code; c0148f99 <d_delete+59/80>
00000000 <_EIP>:
Code; c0148f99 <d_delete+59/80> <=====
0: 89 4a 04 mov %ecx,0x4(%edx) <=====
Code; c0148f9c <d_delete+5c/80>
3: 89 11 mov %edx,(%ecx)
Code; c0148f9e <d_delete+5e/80>
5: c7 43 10 00 00 00 00 movl $0x0,0x10(%ebx)
Code; c0148fa5 <d_delete+65/80>
c: c7 40 04 00 00 00 00 movl $0x0,0x4(%eax)
Code; c0148fac <d_delete+6c/80>
13: 89 00 mov %eax,(%eax)
Then do a ls in the term that was left in
root/pci0/00:08.0/usb_bus/1/00:08.0-1:0, which produces the following
oops:
Sep 1 11:55:33 entropy kernel: <1>Unable to handle kernel paging request at virtual address 5a5a5aca
Sep 1 11:55:33 entropy kernel: printing eip:
Sep 1 11:55:33 entropy kernel: c014089f
Sep 1 11:55:33 entropy kernel: *pde = 00000000
Sep 1 11:55:33 entropy kernel: Oops: 0000
Sep 1 11:55:33 entropy kernel: CPU: 0
Sep 1 11:55:33 entropy kernel: EIP: 0060:[<c014089f>] Not tainted
Sep 1 11:55:33 entropy kernel: EFLAGS: 00010246
Sep 1 11:55:33 entropy kernel: eax: c487cb80 ebx: 00000003 ecx: c0e3ff70 edx: c0e3fed4
Sep 1 11:55:33 entropy kernel: esi: 00000003 edi: c0e3ff70 ebp: 5a5a5a5a esp: c0e3fec0
Sep 1 11:55:33 entropy kernel: ds: 0068 es: 0068 ss: 0068
Sep 1 11:55:33 entropy kernel: Process ls (pid: 1887, threadinfo=c0e3e000 task=c487cb80)
Sep 1 11:55:33 entropy kernel: Stack: c0e3fed4 00000003 c204c000 c4ffd3f0 c1111c8c 00000000 00000000 00000000
Sep 1 11:55:33 entropy kernel: 00001e91 000000d2 0000a3d6 00001e91 00000003 c0e3ff60 c012498d c204c005
Sep 1 11:55:33 entropy kernel: 00000004 01b42f73 c39e26d4 00000003 00000003 c0e3ff70 00018801 c014189c
Sep 1 11:55:33 entropy kernel: Call Trace: [<c012498d>] [<c014189c>] [<c0110d40>] [<c01090bd>] [<c0136474>]
Sep 1 11:55:33 entropy kernel: [<c01367f5>] [<c0108e87>]
Sep 1 11:55:33 entropy kernel: Code: 8b 45 70 89 14 24 eb 09 8b 45 70 8d b6 00 00 00 00 66 8b 5d
>>EIP; c014089f <link_path_walk+6f/880> <=====
Trace; c012498d <vm_enough_memory+2d/c0>
Trace; c014189c <open_namei+7c/3d0>
Trace; c0110d40 <do_page_fault+0/48f>
Trace; c01090bd <error_code+2d/40>
Trace; c0136474 <filp_open+34/60>
Trace; c01367f5 <sys_open+35/70>
Trace; c0108e87 <syscall_call+7/b>
Code; c014089f <link_path_walk+6f/880>
00000000 <_EIP>:
Code; c014089f <link_path_walk+6f/880> <=====
0: 8b 45 70 mov 0x70(%ebp),%eax <=====
Code; c01408a2 <link_path_walk+72/880>
3: 89 14 24 mov %edx,(%esp,1)
Code; c01408a5 <link_path_walk+75/880>
6: eb 09 jmp 11 <_EIP+0x11> c01408b0 <link_path_walk+80/880>
Code; c01408a7 <link_path_walk+77/880>
8: 8b 45 70 mov 0x70(%ebp),%eax
Code; c01408aa <link_path_walk+7a/880>
b: 8d b6 00 00 00 00 lea 0x0(%esi),%esi
Code; c01408b0 <link_path_walk+80/880>
11: 66 8b 5d 00 mov 0x0(%ebp),%bx
Afterwards, "find root/ -type d" produces this, with find dying in
down() (probably because khubd died).
root/
root/pci0
root/pci0/00:0f.1
root/pci0/00:0f.0
root/pci0/00:0b.0
root/pci0/00:0a.0
root/pci0/00:08.0
root/pci0/00:08.0/usb_bus
Again, there are lots of 0x5a bytes in the oops, indicating that
something is being used after it is freed and slab poisoning is catching
that error.
On Sun, Sep 01, 2002 at 12:28:30PM -0700, Nicholas Miell wrote:
> On Tue, 2002-08-27 at 22:46, Greg KH wrote:
> > Does this still happen on 2.5.32? I was unable to reproduce it on
> > either 2.5.31, 2.5.31-bk, or 2.5.32.
> >
>
> I can reproduce the oops reliably -- but you have to enable slab
> poisoning to do it.
You want to apply zwane's USB patch, and my 2.5.32-usb.diff patch.
Both appeared on lkml today. It should fix this precise problem.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Sun, 2002-09-01 at 12:58, Russell King wrote:
> On Sun, Sep 01, 2002 at 12:28:30PM -0700, Nicholas Miell wrote:
> > On Tue, 2002-08-27 at 22:46, Greg KH wrote:
> > > Does this still happen on 2.5.32? I was unable to reproduce it on
> > > either 2.5.31, 2.5.31-bk, or 2.5.32.
> > >
> >
> > I can reproduce the oops reliably -- but you have to enable slab
> > poisoning to do it.
>
> You want to apply zwane's USB patch, and my 2.5.32-usb.diff patch.
> Both appeared on lkml today. It should fix this precise problem.
>
2.5.33 + my minor compilation fixes + "[PATCH] 2.5.32-usb" +
"[PATCH][2.5] pci_free_consistent on ohci initialisation failure" +
"[PATCH][2.5] set pci dma mask for ohci-hcd" still results in the same
oops.
Was there another USB patch today from Zwane that I missed?