OOPS: USB and/or devicefs

OOPS: USB and/or devicefs

[Nicholas Miell]

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.

Re: OOPS: USB and/or devicefs

[Patrick Mochel]

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;
 }
 

Re: OOPS: USB and/or devicefs

[Nicholas Miell]

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.

Re: OOPS: USB and/or devicefs

[Greg KH]

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

Re: OOPS: USB and/or devicefs

[Nicholas Miell]

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.

Re: OOPS: USB and/or devicefs

[Russell King]

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 (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: OOPS: USB and/or devicefs

[Nicholas Miell]

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?