Kernel Panics when EXT3 formatted pendrive is removed from system.
Hi,
I have Linux PC with Lenny a debian flavour with version 2.6.36.When I plug and Unplugg any USB Data traveller which is FAT32 formatted it works fine.But when I plugin a EXT3 formatted USB Datatraveller,it works fine when i copy and transfer the data without any error.But when I Unplug(remove) it My system gets hanged by displaying an Kernel Panic message.This happens only with EXT3 and EXT2. Regards, Vishnu |
Member Response
Hi,
My first question is: How do umount the device? |
I have unplugged it by first clicking safely removing the hard drive.Then after a second it get crashed.butit works fine for fat32 formatted datatraveller but throws kernel panic for only EXT3 formatted datatravellers...
Regards, vishnu. |
Till now I have not yet solved this issue .can any body help mee..
|
Hello,
As onebuck said check umount. please post the output of mount command df command. cheers |
If i give umount it umounts successfully.But I dont want to do umount.If I remove the device(pendrive) directly then Iam facing kernel hang.Iam using MIPS Processor with Debian-lenny with linux version 2.6.36.
|
Member Response
Hi,
Quote:
You could damage both the filesysteem and device if you do not remove properly. |
Before to umount the USB drive, type the following line on the terminal:
Code:
tail -f /var/log/messages |
My problem is not with x_86 arch.Its in MIPS.When i remove directly from the device which is mips arch and linux with 2.6.36 the device gets hanged with kernel panic.....
Please find the kernel oops message........... EXT3-fs: barriers not enabled kjournald starting. Commit interval 5 seconds EXT3-fs (sdb5): using internal journal EXT3-fs (sdb5): recovery complete EXT3-fs (sdb5): mounted filesystem with writeback data mode usb 3-1: USB disconnect, device number 4 Kernel bug detected[#1]: Cpu 0 $ 0 : 00000000 00962b34 00000001 92c6371c $ 4 : 906c1214 9e4901e4 0000af01 0000af00 $ 8 : 532f2303 00000020 00000000 00000000 $12 : 00000005 90650000 90549afc 00000001 $16 : 00000018 9e68fe68 906c1200 fffffffe $20 : 0000002f 906c1a0c 906c1c0c 906c1e0c $24 : 90549b04 90052aec $28 : 9e68c000 9e68fe58 00200200 900781e0 Hi : 0019e616 Lo : 9846da7e epc : 900781d0 cascade+0x7c/0xbc Tainted: P ra : 900781e0 cascade+0x8c/0xbc Status: 1100f802 KERNEL EXL Cause : 00800034 PrId : 0001974c (MIPS 74Kc) Modules linked in: xcode4drv ufsd(P) hw_ctrl [last unloaded: xcode4drv] Process afpd (pid: 2455, threadinfo=9e68c000, task=98641850, tls=2ba8b470) Stack : 9e68fe78 9e37ec90 00000000 00000000 986d3e68 9e1181e4 906c1200 00000000 9e68fea0 00000001 90650000 9007872c 00000040 00000000 00000000 00000003 00000001 00000002 905beaf8 00962f38 906c200c 900520c8 00000000 906c10a8 00000004 00000001 00000100 0000000a 906c0000 9064a1f0 906c10a4 90072ebc 9064c394 00000003 00962f4c 00962f68 00000008 00962dd0 00000000 00962de0 ... Call Trace: [<900781d0>] cascade+0x7c/0xbc [<9007872c>] run_timer_softirq+0x188/0x210 [<90072ebc>] __do_softirq+0xb0/0x15c [<90072fd4>] do_softirq+0x6c/0x74 [<9004002c>] ret_from_irq+0x0/0x4 Code: 00531024 02421026 0002102b <00028036> 00602821 0c01df93 02402021 02001821 1611fff5 Kernel panic - not syncing: Fatal exception in interrupt |
It looks like whatever is handling your automounting is mounting the drive asynchronously and not syncing before unmounting.
Onebuck, is right. You will corrupt your file system if you continue to do that. |
Ummm... what kernel are you using?
It shouldn't crash the system anyway - corrupt the filesystem on the device, possibly yes. Crash the system, no. Ext3 usually uses a journal that will minimize the corruption, ext2 does not... BUT ext2 will definitely report problems, and have problems with improperly removing the device before dismounting it. And on dismount, you need to wait a bit afterwards (sometimes the final buffer flush takes a few seconds). You do HAVE to dismount the device before it is removed. One purpose of the "eject" is to tell the automounting software to not immediately remount it... |
Iam using Debians lenny with 2.6.36 on Mips architechture.
|
The only suggestion I have right now is to try an earlier kernel if it is available. Removing a drive should never cause a crash, even if it is mounted (LOTS of bug problems though, might cause a hang if it is root...), though not absolutely impossible.
The only time I've seen real crashes through an ext2 mount happened due to it also holding a swap file when it was removed - and that was a long time ago. |
The only reason I could think of for a kernel crash on a usb removal is some process or application is actually running on the usb.
|
I think it would have to be a kernel task... meaning a bug in the USB code then.
A full traceback should indicate that, rather than the abbreviated one shown. And the leading timestamps on the other messages. |
All times are GMT -5. The time now is 12:50 AM. |