Kernel oops on large tar

[trich]

Hello,

Operating System: Mandrake 10.0
File System: reiserfs
Hardware:
AMD K6-2 450MHz (64k cache)
192MB PC133 DIMMs
Software Versions:
tar: 1.13.25
kernel: 2.6.3-4mdk
gcc: 3.3.2
Useful Mount Information:
/dev/ide/host0/bus0/target0/lun0/part1 on / type ext3 (rw)
/dev/ide/host0/bus0/target1/lun0/part3 on /public type reiserfs (rw,notail)

I attempted to tar up about 19.5GB worth of binary data (mp3s, jpegs, etc) on a reiserfs partition (around 80GB of free space) and I received a seg fault. The command I issued was:

[trich@amon /]$ tar -cf backup.tar /public/

When I attempted to do an ls in the affected directory (or anywhere on that partition), my cursor just blinks and I never get output, nor do I return to a prompt at any point. This is also the case if I try to do a 'du' or anthing else that would touch that partition.

According to a dmesg, I had a kernel oops, and I'm not sure what to do from here. I have not rebooted yet, as I don't want to make matters worse. The pertenent information from dmesg is as follows:

49136 pages of RAM
0 pages of HIGHMEM
1352 reserved pages
16535 pages shared
11051 pages swap cached
Unable to handle kernel NULL pointer dereference at virtual address 00000008
printing eip:
cc9aec87
*pde = 00000000
Oops: 0000 [#1]
CPU: 0
EIP: 0060:[<cc9aec87>] Not tainted VLI
EFLAGS: 00010246
EIP is at 0xcc9aec87
eax: 00000000 ebx: c8d3f75c ecx: 00000000 edx: 0000019d
esi: cc8f8ce8 edi: 00003ae0 ebp: c1fd9ba0 esp: c1fd9b84
ds: 007b es: 007b ss: 0068
Process tar (pid: 5232, threadinfo=c1fd8000 task=c5f66040)
Stack: 00000001 c1fd9c24 cc9aa044 ca6f3b00 c8d3f75c cc8f8ce8 00003ae0 c1fd9bf4
cc98f180 c80afe00 0000019d 00003ae0 00000001 c1fd9be4 00000000 00003ae0
00000000 c68e9018 00000000 00000000 c8d3f000 00003adf c80afe00 c1fd9bfc
Call Trace:
[<cc9aa044>] 0xcc9aa044
[<cc98f180>] 0xcc98f180
[<cc98f626>] 0xcc98f626
[<cc9900af>] 0xcc9900af
[<cc99ad3a>] 0xcc99ad3a
[<cc9aa7e8>] 0xcc9aa7e8
[<cc9aa8e4>] 0xcc9aa8e4
[<cc9961c3>] 0xcc9961c3
[<cc9a949f>] 0xcc9a949f
[<cc99ce90>] 0xcc99ce90
[<c013b200>] file_read_actor+0x0/0x110
[<c013b5a0>] generic_file_read+0x80/0xa0
[<c011ae4d>] smp_local_timer_interrupt+0xd/0xa0
[<c011f1cd>] scheduler_tick+0x1d/0x560
[<c0129d7c>] update_process_times+0x2c/0x40
[<c01237e3>] profile_hook+0x13/0x18
[<c011ae4d>] smp_local_timer_interrupt+0xd/0xa0
[<c0110ff6>] timer_interrupt+0xb6/0xe0
[<c0153cde>] vfs_write+0x8e/0xe0
[<c0153dae>] sys_write+0x2e/0x50
[<c010b007>] syscall_call+0x7/0xb

Code: 81 fb ff 01 00 00 7e dd 8b 5d fc 31 c0 c9 c3 90 8d 74 26 00 55 89 e5 57 56 53 83 ec 10 8b 45 18 8b 55 0c c7 00 00 00 00 0b 31 c0 <8b> 50 08 8b 8b 6b 01 00 00 f0 41 1c 10 0b 85 f6 00 00 00 8b 81



Any help or suggestions anyone may have would be very welcome. Many thanks in advance!


Tony

[fingal]

That looks hard to work out! Are you using the same file system right across the entire hdd? I know it says somewhere in the tar manual that errors are not uncommon from time to time. I would skim through that manual (don't read it all it's boring) and see if there are any more clues.

If you get to that blinking cursor you mentioned, can you get back to a normal prompt by hitting Ctrl.+C ?

If you can get to a prompt, it might be worth checking out /var/log to see if there are any further clues.

[trich]

That looks hard to work out! Are you using the same file system right across the entire hdd?

Nope, / is on the same drive, too (ext2)

I know it says somewhere in the tar manual that errors are not uncommon from time to time. I would skim through that manual (don't read it all it's boring) and see if there are any more clues.

I'll check it out again, but I didn't see anything useful when I looked earlier.

If you get to that blinking cursor you mentioned, can you get back to a normal prompt by hitting Ctrl.+C ?

Nope. No control sequence will break it (I've tried CTRL-Z, CTRL-C, CTRL-\, etc). The only thing I can do is log on via a new virtual terminal and kill the bash shell process from the other term.

If you can get to a prompt, it might be worth checking out /var/log to see if there are any further clues.

I've checked /var/log/errors and /var/log/kernel/errors (the only pertinent log files) and there is no additional information - just the stuff that showed up in the dmesg.

I guess I'll try a reboot and see if that helps... Cross your fingers!

Thanks,
Tony

[fingal]

I notice you said in your first post that you are using reiserfs. If you have a different file system on / then I think that might be the cause of your oops.

It's a theory. Filesystems have different design philosophies behind them. You can't mix and match. You'll need the same fs throughout.

<edit> Obviously changing file systems will create issues for you. You want to backup your data, but this is a problem. I think overall reiserfs is the better fs and the one you should use.

[trich]

I ended up rebooting the box last night and running an fsck on it a few times. Fsck found a few bad inodes and repared them. I crossed my fingers, rebooted again, and everything worked great! I am able to access the partition completely.

The surprising thing was that, I thought if fsck repared a partition, entries would be placed in Lost&Found for the damage inodes. However, I didn't have anything in Lost&Found. Does this mean that there were no damaged inodes, or that I don't understand what's going on?

As a side note, I have had this computer set up this way for a while now (since Mandrake 10 was new) with no problems. You can have two different file systems (partitions) on the same drive. If I remember correctly, / can't be a reiserfs partition, so you have to do ext2/ext3 or something for that partition. Likewise, swap space is usually on the same drive as / and is a different file system.

Now, I have done (before the oops and since) small tars where I tar up information from one partition and store the tar on another - that works fine. It appears that if you either have a) a lot of data to tar, or b) a deep file structure (many sub directories), tar freaks out. Maybe I'll set up a test environment and see if I can replicate the behavior.

Thank you all for your help... I really appreciate it!

Thanks,
Tony

[fingal]

Hello - Pleased that worked out. I learned a lot from your comments too, so thanks!