Kernel Panics when EXT3 formatted pendrive is removed from system.
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.
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...
Till now I have not yet solved this issue .can any body help mee..
As onebuck said check umount.
please post the output of mount command
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.
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:
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]:
$ 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
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
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 10:19 AM.|