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 [EMAIL PROTECTED]@localdomain at Fri Apr 13 13:21:23 2007 ... > [EMAIL PROTECTED] kernel: Oops: 0000 [#1] > [EMAIL PROTECTED] kernel: PREEMPT SMP > [EMAIL PROTECTED] kernel: CPU: 1 > [EMAIL PROTECTED] kernel: EIP is at find_get_pages+0x65/0x71 > [EMAIL PROTECTED] kernel: eax: 80000868 ebx: 00000001 ecx: > cb605ec8 edx: 00000001 > [EMAIL PROTECTED] kernel: esi: 00000002 edi: dc7c85c8 ebp: > cb605ec4 esp: cb605e68 > [EMAIL PROTECTED] kernel: ds: 007b es: 007b ss: 0068 > [EMAIL PROTECTED] kernel: Process rm (pid: 8273, threadinfo=cb604000 > task=c1a71030) > [EMAIL PROTECTED] kernel: Stack: <0>dc7c85bc cb605ec4 00000000 0000000e > cb605ebc 00000000 ffffffff ffffffff > [EMAIL PROTECTED] kernel: c0149ff5 dc7c85b8 00000000 0000000e > cb605ec4 00000000 c014ab26 cb605ebc > [EMAIL PROTECTED] kernel: dc7c85b8 00000000 0000000e 00000000 > 00000000 00000000 00000000 c1279300 > [EMAIL PROTECTED] kernel: Call Trace: > [EMAIL PROTECTED] kernel: [pagevec_lookup+43/50] > pagevec_lookup+0x2b/0x32 > [EMAIL PROTECTED] kernel: [truncate_inode_pages_range+257/748] > truncate_inode_pages_range+0x101/0x2ec > [EMAIL PROTECTED] kernel: [inotify_dentry_parent_queue_event+58/162] > inotify_dentry_parent_queue_event+0x3a/0xa2 > [EMAIL PROTECTED] kernel: [truncate_inode_pages+47/51] > truncate_inode_pages+0x2f/0x33 > [EMAIL PROTECTED] kernel: [ext3_delete_inode+39/281] > ext3_delete_inode+0x27/0x119 > [EMAIL PROTECTED] kernel: [ext3_delete_inode+0/281] > ext3_delete_inode+0x0/0x119 > [EMAIL PROTECTED] kernel: [generic_delete_inode+110/302] > generic_delete_inode+0x6e/0x12e > [EMAIL PROTECTED] kernel: [iput+68/128] iput+0x44/0x80 > [EMAIL PROTECTED] kernel: [do_unlinkat+224/309] do_unlinkat+0xe0/0x135 > [EMAIL PROTECTED] kernel: [sysenter_past_esp+84/117] > sysenter_past_esp+0x54/0x75 > [EMAIL PROTECTED] 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 -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
