Relevant part of klogd output:
Jun 2 14:17:21 ganesh-pc kernel: EIP: 0010:[ret_from_sys_call+133/136]
And if I run the same /home/linux/vmlinux from gdb it faults with :
Jun 2 14:17:29 ganesh-pc kernel: general protection: 0000
Jun 2 14:17:29 ganesh-pc kernel: CPU: 0
Jun 2 14:17:29 ganesh-pc kernel: EIP: 0010:[signal_return+55/56]
Jun 2 14:17:29 ganesh-pc kernel: EFLAGS: 00010202
Jun 2 14:17:29 ganesh-pc kernel: eax: 00000000 ebx: 08097818 ecx: 080977f0
edx: 00000000
Jun 2 14:17:29 ganesh-pc kernel: esi: 080977f0 edi: 08096f28 ebp: bffffa94
esp: 01218fec
Jun 2 14:17:29 ganesh-pc kernel: ds: 002b es: 002b fs: 002b gs: 002b ss: 0018
Jun 2 14:17:29 ganesh-pc kernel: Process vmlinux (pid: 728, process nr: 34, stackpage=01218000)
Jun 2 14:17:29 ganesh-pc kernel: Stack: c0100000 00000023 00000206 bffffe5c 0000002b
Jun 2 14:17:29 ganesh-pc kernel: Call Trace:
Jun 2 14:17:29 ganesh-pc kernel: Code: cf e8 3f 26 00 00 89 c4 50 53 e8 aa fb ff ff 5b 5b 66 83 7c
In both cases, the offending opcode is an iret.
Running the pre34 vmlinux gives the expected SEGV. Ditto for 2.1.103 running
any vmlinux.
It is 100% reproducible. I also tried it on a P-II running 2.0.32 with
a 2.1.101 vmlinux and it gave exactly the same behaviour down to the
faulting point. So I guess it is a fairly old bug.
-- ganesh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu