Surprisingly though, when I tried just a simple
kexec -e today (having loaded the kernel earlier on),
I ran into the following Oops, consistently:
I'm using kexec-tools-1.8, and this has worked for me
earlier. The test system is a 4way SMP machine.
Has anyone seen this as well ? (I'd already issued init 1
and unmounted filesystems by this point)
sh-2.05a# /sbin/kexec -e
Synchronizing SCSI caches:
Shutting down devices
Starting new kernel
Unable to handle kernel paging request at virtual address 361ae000
printing eip:
c011470a
*pde = 00000000
Oops: 0002
CPU: 0
EIP: 0060:[<c011470a>] Not tainted
EFLAGS: 00010003
EIP is at machine_kexec+0x14a/0x190
eax: 00000097 ebx: f7742260 ecx: 00000025 edx: 361ac000
esi: c0114750 edi: 361ae000 ebp: f7365e94 esp: f7365e80
ds: 007b es: 007b ss: 0068
Process kexec (pid: 1685, threadinfo=f7364000 task=f6290060)
Stack: 361ae000 361ac000 f7742260 f7364000 00000000 f7365fbc
c0126903 f7742260 c02a71af c03a9aa8 00000001 00000000 f7fe1640
f7793ec0 c1b3b120 f7364000 00000001 f7365edc c014dbef f7fe1668
f7fe1668 00000286 f7ff51e0 f7365efc
Call Trace:
[<c0126903>] sys_reboot+0x363/0x400
[<c014dbef>] invalidate_inode_buffers+0xf/0x90
[<c01633b0>] clear_inode+0x10/0xb0
[<c0238276>] sock_destroy_inode+0x16/0x20
[<c016149e>] dput+0x1e/0x170 i
[<c014cb56>] __fput+0x116/0x140 i
[<c014b38f>] filp_close+0xcf/0xe0 i
[<c014b43e>] sys_close+0x9e/0xd0 i
[<c01091c7>] syscall_call+0x7/0xb i
Code: f3 a5 a8 02 74 02 66 a5 a8 01 74 01 a4 e8 84 fe ff ff 6a 00
Regards
Suparna
-- Suparna Bhattacharya (suparna@in.ibm.com) Linux Technology Center IBM Software Labs, India
-- Suparna Bhattacharya (suparna@in.ibm.com) Linux Technology Center IBM Software Labs, India- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/