The oops:
Unable to handle kernel NULL pointer dereference at virtual address
00000020
current->tss.cr3 = 00694000,
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c0145cb4>]
EFLAGS: 00010282
eax: 00000000 ebx: 00000000 ecx: c05b4000 edx: c01c4dd0
esi: c078f01c edi: c0c88c30 ebp: c0c88bf0 esp: c06b7ef0
ds: 0018 es: 0018 ss: 0018
Process bash (pid: 2233, process nr: 48, stackpage=c06b7000)
Stack: c0145ce0 00000000 fffffffe 00000000 c0146a6e c078f01c 00000000
00000000
c06299d8 c06299d8 00000001 c0146aeb c0c88bf0 c01e894c c078f000
c0629a24
c0c88bf0 c0146bda c0c88bf0 c0c88bf0 c06b7f88 c012c527 c06299d8
c0c88bf0
Call Trace: [<c0145ce0>] [<c0146a6e>] [<c0146aeb>] [<c0146bda>]
[<c012c527>] [<c012c744>] [<c012c288>]
[<c012c80d>] [<c0123fde>] [<c0109ade>]
Code: 8b 48 20 8b 50 1c 89 51 1c 8b 50 1c 8b 40 20 89 42 20 c3 89
And ksymoops results:
Using `/root/map' to map addresses to symbols.
>>EIP: c0145cb4 <autofs_delete_usage+4/20>
Trace: c0145ce0 <autofs_update_usage+10/20>
Trace: c0146a6e <try_to_fill_dentry+ee/120>
Trace: c0146aeb <autofs_revalidate+4b/f0>
Trace: c0146bda <autofs_root_lookup+4a/90>
Trace: c012c527 <real_lookup+47/70>
Trace: c012c744 <lookup_dentry+164/200>
Trace: c012c288 <getname+a8/110>
Trace: c012c80d <__namei+2d/90>
Trace: c0123fde <sys_chdir+e/70>
Trace: c0109ade <system_call+3a/40>
Code: c0145cb4 <autofs_delete_usage+4/20>
Code: c0145cb4 <autofs_delete_usage+4/20> 8b 48 20 movl
0x20(%eax),%ecx
Code: c0145cb7 <autofs_delete_usage+7/20> 8b 50 1c movl
0x1c(%eax),%edx
Code: c0145cba <autofs_delete_usage+a/20> 89 51 1c movl
%edx,0x1c(%ecx)
Code: c0145cbd <autofs_delete_usage+d/20> 8b 50 1c movl
0x1c(%eax),%edx
Code: c0145cc6 <autofs_delete_usage+16/20> 8b 40 20 movl
0x20(%eax),%eax
Code: c0145cc9 <autofs_delete_usage+19/20> 89 42 20 movl
%eax,0x20(%edx)
Code: c0145ccc <autofs_delete_usage+1c/20> c3 ret
Code: c0145ccd <autofs_delete_usage+1d/20> 89 00 movl
%eax,(%eax)
Code: c0145cd5 <autofs_update_usage+5/20> 90 nop
Code: c0145cd6 <autofs_update_usage+6/20> 90 nop
Code: c0145cd7 <autofs_update_usage+7/20> 90 nop
Autofs was built in, not a module.
I logged in again, and again tried cd /mnt/dos:
autofs: lookup failure on existing dentry, status = -2, name = dos
autofs: trying to recover, but prepare for Armageddon
I then did /etc/rc.d/init.d/autofs stop, which seemed to work. However,
ls /mnt gave no files
~# cat /proc/mounts:
/dev/root / ext2 rw 0 0
/proc /proc proc rw 0 0
automount(pid249) /mnt autofs rw 0 0
/dev/hda1 /mnt/dos vfat rw 0 0
There is no pid 249 or any automount daemon (they got killed) when I
stopped autofs
umount /mnt gives: umount: /mnt: device is busy
~# fuser -mv /mnt
/mnt/dos: No such file or directory
The logs do, however, show:
Mar 27 17:33:55 onion automount[249]: shutting down, path = /mnt
Mar 27 17:33:56 onion automount[249]: >> umount: /mnt: device is busy
umount /mnt/dos works, but umount /mnt gives me umount: /mnt: device is
busy,
even though fuser -mv /mnt gives no result.
Trying to start the automount daemon again gives:
automount[3742]: starting automounter version 0.3.14, path = /mnt,
maptype = file, mapname = /etc/auto.mnt
automount[3742]: >> mount: automount(pid3742) already mounted or /mnt
busy
automount[3742]: >> mount: according to mtab, automount(pid249) is
already mounted on /mnt
automount[3742]: /mnt: mount failed!
I've been using autofs for a while, and this hasn't happened before.
Nothing else would have been trying to access the dos partition at the
time.
Hope this helps,
Bradley
PS I only get the digest, so please cc any other questions direct to me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu