strange error on "sudo rm -r "

Ken Moffat ken at linuxfromscratch.org
Fri Apr 13 09:44:39 PDT 2007


On Fri, Apr 13, 2007 at 01:24:31PM +0530, anirudh vij wrote:
> hi,
> i just built scilab .but on deleting the source tree i got this message:
> 
> /home/hackman/to-be-built  sudo rm -r scilab-4.1
> Segmentation fault
> /home/hackman/to-be-built
> Message from syslogd at localhost@localdomain at Fri Apr 13 13:21:23 2007 ...
> localhost at localdomain kernel: Oops: 0000 [#1]
> localhost at localdomain kernel: PREEMPT SMP
> localhost at localdomain kernel: CPU:    1
> localhost at localdomain kernel: EIP is at find_get_pages+0x65/0x71
> localhost at localdomain kernel: eax: 80000868   ebx: 00000001   ecx:
> cb605ec8   edx: 00000001
> localhost at localdomain kernel: esi: 00000002   edi: dc7c85c8   ebp:
> cb605ec4   esp: cb605e68
> localhost at localdomain kernel: ds: 007b   es: 007b   ss: 0068
> localhost at localdomain kernel: Process rm (pid: 8273, threadinfo=cb604000
> task=c1a71030)
> localhost at localdomain kernel: Stack: <0>dc7c85bc cb605ec4 00000000 0000000e
> cb605ebc 00000000 ffffffff ffffffff
> localhost at localdomain kernel:        c0149ff5 dc7c85b8 00000000 0000000e
> cb605ec4 00000000 c014ab26 cb605ebc
> localhost at localdomain kernel:        dc7c85b8 00000000 0000000e 00000000
> 00000000 00000000 00000000 c1279300
> localhost at localdomain kernel: Call Trace:
> localhost at localdomain kernel:  [pagevec_lookup+43/50]
> pagevec_lookup+0x2b/0x32
> localhost at localdomain kernel:  [truncate_inode_pages_range+257/748]
> truncate_inode_pages_range+0x101/0x2ec
> localhost at localdomain kernel:  [inotify_dentry_parent_queue_event+58/162]
> inotify_dentry_parent_queue_event+0x3a/0xa2
> localhost at localdomain kernel:  [truncate_inode_pages+47/51]
> truncate_inode_pages+0x2f/0x33
> localhost at localdomain kernel:  [ext3_delete_inode+39/281]
> ext3_delete_inode+0x27/0x119
> localhost at localdomain kernel:  [ext3_delete_inode+0/281]
> ext3_delete_inode+0x0/0x119
> localhost at localdomain kernel:  [generic_delete_inode+110/302]
> generic_delete_inode+0x6e/0x12e
> localhost at localdomain kernel:  [iput+68/128] iput+0x44/0x80
> localhost at localdomain kernel:  [do_unlinkat+224/309] do_unlinkat+0xe0/0x135
> localhost at localdomain kernel:  [sysenter_past_esp+84/117]
> sysenter_past_esp+0x54/0x75
> localhost at localdomain kernel: Code: 85 c0 75 11 89 f8 e8 ee 24 3d 00 89 f0
> 83 c4 10 5b 5e 5f 5d c3 89 e9 31 db eb 0e f0 ff 42 04 83 c3 01 83 c1 04 39
> de 74 db 8b 11 <8b> 02 f6 c4 40 74 e9 8b 52 0c eb e4 55 57 56 53 83 ec 14 8b
> 5c
> 
> what does this mean?has a section of the disk drive been corrupted(the inode
> errors?).nothing seems working awkwardly just yet.

 (Reformatted to bring the information together again).  It means
the kernel oopsed (that initial 'kernel: Oops: 0000 [#1]' -
something unexpected happened in the kernel.  After that, all bets
are off - the machine might *appear* to work, or it might immediately
grind to a halt, but in either case you *need* to reboot it as soon as
you can.  Ideally, start in runlevel 1 and force an fsck (journal
replay isn't really adequate in this case) to find out if the
filesystem was damaged or not.

 After that, check the log to see if anything unusual happened
before the oops.

 The call trace shows it was unlinking, so it appears to be the 'rm'
that triggered it.  The likely cause is that one of the kernel
datastructures had become corrupted.

 Maybe this oops information made it to the log, maybe it didn't.  I
would expect to see information about modules loaded, and whether or
not the kernel was tainted (taint primarily means you loaded non-open
binary modules, e.g. for video or wifi, and nobody can reliably debug
the oops).  If this is a recent untainted kernel from kernel.org,
without additional patches, and the problem persists, you could try
asking on the kernel mailing list if you feel up to it (with full
oops output, if available, and certainly with your .config).

 Out of interest: what platform, which kernel version, any extra
patches, any tainting modules, and which toolchain versions ?

 If this is _not_ an up-to-date kernel, now is probably a good time
to upgrade it (if the box is working after reboot - on one occasion
an old box of mine oopsed when a stick of memory went bad, and then
started to oops fairly quickly after each reboot).

 I'd also be wary of choosing PREEMPT with SMP, but maybe I'm
excessively cautious;)

HTH
ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce



More information about the blfs-support mailing list