Skip to contentSkip to conversation

2.6.2-rc1-mm1 oops with X

DISCUSSION Glenn Johnson 4 participants 12 messages Jan 23, 2004 – Jan 27, 2004

lore
Share & tools
lore
#0 lore raw

I am getting the oops pasted below. It only happens when the X server is restarting. I do not see it all of the time but frequently enough that I can call it reproducible. I started seeing it with 2.6.1-mm4 and can trigger it fairly regularly with 2.6.2-rc1-mm1. However, I do not see it with 2.6.1-mm3 nor with 2.6.2-rc1. Hopefully, that narrows the field as to what may be the culprit.

Some relevant hardware and kernel configuration information:

- 2.4GHz P4c with HyperThreading (I do have CONFIG_SMT set)
- Radeon 9100 graphics card (DRI enabled)

---begin oops---

Unable to handle kernel NULL pointer dereference at virtual address 00000000
 printing eip:
c02a2c56
*pde = 00000000
Oops: 0000 [#1]
PREEMPT SMP 
CPU:    0
EIP:    0060:[<c02a2c56>]    Not tainted VLI
EFLAGS: 00010286

EIP is at vt_ioctl+0x1e/0x1f4b
eax: 00000000 ebx: daf10000 ecx: 00000007 edx: 00000007
esi: 00005607 edi: daf10000 ebp: daf48080 esp: dc6d7ea0
ds: 007b es: 007b ss: 0068
Process X (pid: 6100, threadinfo=dc6d6000 task=dbe56d00)

Stack: 00000006 df8e6005 00000003 df8e6005 dc6d7f70 dffd8f00 00000000 dfda1480 
       df963b00 c01746e1 dfda1480 c0526e80 00000000 dfbaf780 df963b00 c016b982 
       00021480 00000000 00000000 00000001 df4f9200 c01668e6 c0579800 daf48280 
Call Trace:
 [<c01746e1>] dput+0x22/0x2b1
 [<c016b982>] link_path_walk+0x690/0x9ea
 [<c01668e6>] cdev_put+0x17/0x69
 [<c0166503>] chrdev_open+0x160/0x291
 [<c011dfaa>] recalc_task_prio+0x90/0x1aa
 [<c012082d>] schedule+0x39b/0x6d7
 [<c02a2c38>] vt_ioctl+0x0/0x1f4b
 [<c029d8dd>] tty_ioctl+0x472/0x570
 [<c016fb3a>] sys_ioctl+0x119/0x2a3
 [<c041b3da>] sysenter_past_esp+0x43/0x65

Code: ff e8 5f 77 e6 ff e9 6d ff ff ff 90 90 55 57 56 53 81 ec b8 00 00 00 8b bc 24 cc 00 00 00 8b b4 24 d4 00 00 00 8b 87 78 09 00 00 <8b> 18 8b 04 9d 00 9e 57 c0 89 1c 24 89 44 24 50 e8 4e 6a 00 00 
 <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
 printing eip:
c02a2c56
*pde = 00000000
Oops: 0000 [#2]
PREEMPT SMP 
CPU:    0
EIP:    0060:[<c02a2c56>]    Not tainted VLI
EFLAGS: 00010286

EIP is at vt_ioctl+0x1e/0x1f4b
eax: 00000000 ebx: d1ec7000 ecx: 00000008 edx: 00000008
esi: 00005607 edi: d1ec7000 ebp: daf48180 esp: d0927ea0
ds: 007b es: 007b ss: 0068
Process X (pid: 6117, threadinfo=d0926000 task=dbe56080)

Stack: 00000007 df9df005 00000003 df9df005 d0927f70 dffd8f00 00000000 dfda1480 
       df963b00 c01746e1 dfda1480 c0526e80 00000000 dfbaf780 df963b00 c016b982 
       00021480 00000000 00000000 00000001 dee34a00 c01668e6 c0579800 daeab180 
Call Trace:
 [<c01746e1>] dput+0x22/0x2b1
 [<c016b982>] link_path_walk+0x690/0x9ea
 [<c01668e6>] cdev_put+0x17/0x69
 [<c0166503>] chrdev_open+0x160/0x291
 [<c011dfaa>] recalc_task_prio+0x90/0x1aa
 [<c012082d>] schedule+0x39b/0x6d7
 [<c02a2c38>] vt_ioctl+0x0/0x1f4b
 [<c029d8dd>] tty_ioctl+0x472/0x570
 [<c016fb3a>] sys_ioctl+0x119/0x2a3
 [<c041b3da>] sysenter_past_esp+0x43/0x65

Code: ff e8 5f 77 e6 ff e9 6d ff ff ff 90 90 55 57 56 53 81 ec b8 00 00 00 8b bc 24 cc 00 00 00 8b b4 24 d4 00 00 00 8b 87 78 09 00 00 <8b> 18 8b 04 9d 00 9e 57 c0 89 1c 24 89 44 24 50 e8 4e 6a 00 00 
 <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
 printing eip:
c02a2c56
*pde = 00000000
Oops: 0000 [#3]
PREEMPT SMP 
CPU:    0
EIP:    0060:[<c02a2c56>]    Not tainted VLI
EFLAGS: 00010286

EIP is at vt_ioctl+0x1e/0x1f4b
eax: 00000000 ebx: d1ec6000 ecx: 00000009 edx: 00000009
esi: 00005607 edi: d1ec6000 ebp: ce675380 esp: cd0f9ea0
ds: 007b es: 007b ss: 0068
Process X (pid: 6134, threadinfo=cd0f8000 task=df4c8d00)

Stack: 00000008 c1738005 00000003 c1738005 cd0f9f70 dffd8f00 00000000 dfda1480 
       df963b00 c01746e1 dfda1480 c0526e80 00000000 dfbaf780 df963b00 c016b982 
       00021480 00000000 00000000 00000001 dee34800 c01668e6 c0579800 cd177e80 
Call Trace:
 [<c01746e1>] dput+0x22/0x2b1
 [<c016b982>] link_path_walk+0x690/0x9ea
 [<c01668e6>] cdev_put+0x17/0x69
 [<c0166503>] chrdev_open+0x160/0x291
 [<c011dfaa>] recalc_task_prio+0x90/0x1aa
 [<c012082d>] schedule+0x39b/0x6d7
 [<c02a2c38>] vt_ioctl+0x0/0x1f4b
 [<c029d8dd>] tty_ioctl+0x472/0x570
 [<c016fb3a>] sys_ioctl+0x119/0x2a3
 [<c041b3da>] sysenter_past_esp+0x43/0x65

Code: ff e8 5f 77 e6 ff e9 6d ff ff ff 90 90 55 57 56 53 81 ec b8 00 00 00 8b bc 24 cc 00 00 00 8b b4 24 d4 00 00 00 8b 87 78 09 00 00 <8b> 18 8b 04 9d 00 9e 57 c0 89 1c 24 89 44 24 50 e8 4e 6a 00 00 
 <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
 printing eip:
c02a2c56
*pde = 00000000
Oops: 0000 [#4]
PREEMPT SMP 
CPU:    1
EIP:    0060:[<c02a2c56>]    Not tainted VLI
EFLAGS: 00010286

EIP is at vt_ioctl+0x1e/0x1f4b
eax: 00000000 ebx: c7f3a000 ecx: 0000000a edx: 0000000a
esi: 00005607 edi: c7f3a000 ebp: d089a980 esp: cd0f9ea0
ds: 007b es: 007b ss: 0068
Process X (pid: 6151, threadinfo=cd0f8000 task=df4c8d00)

Stack: 00000009 df069005 00000003 df069005 cd0f9f70 dffd8f00 00000000 dfda1480 
       df963b00 c01746e1 dfda1480 c0526e80 00000000 dfbaf780 df963b00 c016b982 
       00021480 00000000 00000000 00000001 df4f9000 c01668e6 c0579800 daeab180 
Call Trace:
 [<c01746e1>] dput+0x22/0x2b1
 [<c016b982>] link_path_walk+0x690/0x9ea
 [<c01668e6>] cdev_put+0x17/0x69
 [<c0166503>] chrdev_open+0x160/0x291
 [<c011dfaa>] recalc_task_prio+0x90/0x1aa
 [<c012082d>] schedule+0x39b/0x6d7
 [<c02a2c38>] vt_ioctl+0x0/0x1f4b
 [<c029d8dd>] tty_ioctl+0x472/0x570
 [<c016fb3a>] sys_ioctl+0x119/0x2a3
 [<c041b3da>] sysenter_past_esp+0x43/0x65

Code: ff e8 5f 77 e6 ff e9 6d ff ff ff 90 90 55 57 56 53 81 ec b8 00 00 00 8b bc 24 cc 00 00 00 8b b4 24 d4 00 00 00 8b 87 78 09 00 00 <8b> 18 8b 04 9d 00 9e 57 c0 89 1c 24 89 44 24 50 e8 4e 6a 00 00 

---end oops---

Regards,

Glenn

#1 lore raw
Quoted 34 lines · [email protected] (Glenn Johnson) wrote:

I am getting the oops pasted below. It only happens when the X server is restarting. I do not see it all of the time but frequently enough that I can call it reproducible. I started seeing it with 2.6.1-mm4 and can trigger it fairly regularly with 2.6.2-rc1-mm1. However, I do not see it with 2.6.1-mm3 nor with 2.6.2-rc1. Hopefully, that narrows the field as to what may be the culprit.

Some relevant hardware and kernel configuration information:

- 2.4GHz P4c with HyperThreading (I do have CONFIG_SMT set)
- Radeon 9100 graphics card (DRI enabled)

---begin oops---

 Unable to handle kernel NULL pointer dereference at virtual address 00000000
  printing eip:
 c02a2c56
 *pde = 00000000
 Oops: 0000 [#1]
 PREEMPT SMP 
 CPU:    0
 EIP:    0060:[<c02a2c56>]    Not tainted VLI
 EFLAGS: 00010286
 EIP is at vt_ioctl+0x1e/0x1f4b
 eax: 00000000   ebx: daf10000   ecx: 00000007   edx: 00000007
 esi: 00005607   edi: daf10000   ebp: daf48080   esp: dc6d7ea0
 ds: 007b   es: 007b   ss: 0068
 Process X (pid: 6100, threadinfo=dc6d6000 task=dbe56d00)
 Stack: 00000006 df8e6005 00000003 df8e6005 dc6d7f70 dffd8f00 00000000 dfda1480 
        df963b00 c01746e1 dfda1480 c0526e80 00000000 dfbaf780 df963b00 c016b982 
        00021480 00000000 00000000 00000001 df4f9200 c01668e6 c0579800 daf48280 
 Call Trace:
  [<c01746e1>] dput+0x22/0x2b1
  [<c016b982>] link_path_walk+0x690/0x9ea
Quoted 8 lines
  [<c01668e6>] cdev_put+0x17/0x69
  [<c0166503>] chrdev_open+0x160/0x291
  [<c011dfaa>] recalc_task_prio+0x90/0x1aa
  [<c012082d>] schedule+0x39b/0x6d7
  [<c02a2c38>] vt_ioctl+0x0/0x1f4b
  [<c029d8dd>] tty_ioctl+0x472/0x570
  [<c016fb3a>] sys_ioctl+0x119/0x2a3
  [<c041b3da>] sysenter_past_esp+0x43/0x65

Sorry, this is the mysterious tty close race. We end up setting tty->driver_data to zero somewhere, somehow, when someone else is still using the tty.

If you revert

	ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1-rc1/2.6.1-rc1-mm1/broken-out/sysfs-add-vc-class.patch

does it go away?

It is maddeningly hard to debug even when you can reproduce it, which I can no longer do.

#2 lore raw
Quoted 2 lines · Andrew Morton

It is maddeningly hard to debug even when you can reproduce it, which I can no longer do.

This is what GDB watchpoints were invented for, surely?

Signature · 1 line
dwmw2
#3 lore raw
Quoted 7 lines · David Woodhouse
Quoted 2 lines · Andrew Morton

It is maddeningly hard to debug even when you can reproduce it, which I can no longer do.

This is what GDB watchpoints were invented for, surely?

I suppose that might help. But for me the bug triggered towards the end of initscripts (it moves around) after we've been through that code path a zillion times. It probably needs to be solved by inspection. If one can get it to happen reliably.

I found that sysfs-class-10-vc.patch caused it to happen and use-kthread-primitives.patch made it go away again. Neither patch has anything to do with tty refcounting and locking.

#4 lore raw
Quoted 6 lines · Andrew Morton
Quoted 1 line

This is what GDB watchpoints were invented for, surely?

I suppose that might help. But for me the bug triggered towards the end of initscripts (it moves around) after we've been through that code path a zillion times. It probably needs to be solved by inspection. If one can get it to happen reliably.

Can't you script it just to automatically show a backtrace and continue, then peruse the logs later?

Signature · 1 line
dwmw2
#5 lore raw
Quoted 11 lines · David Woodhouse
Quoted 6 lines · Andrew Morton
Quoted 1 line

This is what GDB watchpoints were invented for, surely?

I suppose that might help. But for me the bug triggered towards the end of initscripts (it moves around) after we've been through that code path a zillion times. It probably needs to be solved by inspection. If one can get it to happen reliably.

Can't you script it just to automatically show a backtrace and continue, then peruse the logs later?

I can't make it happen any more! I suspect Heisenberg would get in the way anyway.

#6 lore raw
Quoted 7 lines · Andrew Morton
Quoted 2 lines · David Woodhouse

Can't you script it just to automatically show a backtrace and continue, then peruse the logs later?

I can't make it happen any more! I suspect Heisenberg would get in the way anyway.

Signature · 5 lines
Glenn Johnson
U.S. Department of Agriculture
Agricultural Research Service
Southern Regional Research Center
New Orleans, LA
#7 lore raw
In reply to Andrew Morton

I have no idea what happened to the body of the message in my previous reply. Let me try again.

Quoted 7 lines · Andrew Morton
Quoted 2 lines · David Woodhouse

Can't you script it just to automatically show a backtrace and continue, then peruse the logs later?

I can't make it happen any more! I suspect Heisenberg would get in the way anyway.

I can make it happen fairly regularly. Let me know if there is something I can do to provide more useful output.

Signature · 1 line
Glenn Johnson
#8 lore raw
Quoted 6 lines · Glenn Johnson
Quoted 2 lines · Andrew Morton

I can't make it happen any more! I suspect Heisenberg would get in the way anyway.

I can make it happen fairly regularly. Let me know if there is something I can do to provide more useful output.

How, starting X?

How far does it get through, and at what point in X startup does the kernel oops?

#9 lore raw
Quoted 11 lines · Mike Fedyk
Quoted 7 lines · Glenn Johnson
Quoted 2 lines · Andrew Morton

I can't make it happen any more! I suspect Heisenberg would get in the way anyway.

I can make it happen fairly regularly. Let me know if there is something I can do to provide more useful output.

How, starting X?

Yes.

Quoted 2 lines

How far does it get through, and at what point in X startup does the kernel oops?

I would say fairly early on but I do not know how to quantify that.

Signature · 1 line
Glenn Johnson
#10 lore raw
Quoted 4 lines · Glenn Johnson
Quoted 3 lines · Mike Fedyk
Quoted 2 lines

I can make it happen fairly regularly. Let me know if there is something I can do to provide more useful output.

Quoted 8 lines
Quoted 1 line

How, starting X?

Yes.

Quoted 2 lines

How far does it get through, and at what point in X startup does the kernel oops?

I would say fairly early on but I do not know how to quantify that.

Post your log file, and show where in the log the oops occours...

#11 lore raw
Quoted 10 lines · Mike Fedyk
Quoted 6 lines · Glenn Johnson
Quoted 2 lines · Mike Fedyk

How far does it get through, and at what point in X startup does the kernel oops?

I would say fairly early on but I do not know how to quantify that.

Post your log file, and show where in the log the oops occours...

Okay, below is the XFree log file. It is truncated at the point where the oops occurs. I sent an e-mail to Andrew confirming that backing out sysfs-class-10-vc.patch fixes the problem for me.

---begin X log for kernel oops---

XFree86 Version 4.3.0
Release Date: 27 February 2003
X Protocol Version 11, Revision 0, Release 6.6
Build Operating System: Linux 2.6.1-mm5 i686 [ELF]
Build Date: 20 January 2004
Before reporting problems, check http://www.XFree86.Org/
to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/XFree86.0.log", Time: Mon Jan 26 22:33:10 2004 (==) Using config file: "/etc/X11/XF86Config"
(==) ServerLayout "XFree86 Configured"

(**) |-->Screen "Screen0" (0)
(**) |   |-->Monitor "Monitor0"
(**) |   |-->Device "Card0"
(**) |-->Input Device "Mouse0"
(**) |-->Input Device "Keyboard0"

(==) Keyboard: CustomKeycode disabled
(**) FontPath set to "unix/:-1"
(**) RgbPath set to "/usr/X11R6/lib/X11/rgb"
(**) ModulePath set to "/usr/X11R6/lib/modules"
(++) using VT number 8

---end X log for kernel oops

The VT number it tries to use jumps around. Sometimes it is VT10, VT11, etc. It should be using VT7 however.

Cheers,

Glenn