On Fri, 17 Sep 2004, Nix N. Nix wrote: > Just before the computer is about to start over, there's a crash. The > last message is: > INIT: No more processes left in this runlevel > > > For that matter, how did the kernel panic before when the system > > was going down? > > Before the patch: > scsi0 (0:0): rejecting I/O to dead device > FAT bread failed in fat_clusters_flush > slab error in kmem_cache_destroy(): cache `scsi_cmd_cache': Can't free > all objects > [<c01349c6>] kmem_cache_destroy+0x78/0xd9 > [<e09b433f>] scsi_destroy_command_freelist+0x4e/0x75 [scsi_mod] > [<e09b4dc3>] scsi_host_dev_release+0x22/0x75 [scsi_mod] > [<c01be05d>] device_release+0x53/0x57 > [<c0182cf7>] kobject_cleanup+0x8c/0x8e > [<e0a5810b>] scsi_disk_put+0x2a/0x4a [sd_mod] > [<e0a584ab>] sd_release+0x36/0x59 [sd_mod] > [<c014bee5>] blkdev_put+0x100/0x11b > [<c014bebb>] blkdev_put+0xd6/0x11b > [<c014a548>] deactivate_super+0x43/0x58 > [<c015b85e>] sys_umount+0x3b/0x84 > [<c013c2c7>] do_munmap+0xed/0x119 > [<c015b8be>] sys_oldumount+0x17/0x1b > [<c0105c0f>] syscall_call+0x7/0xb
I'm not sure about that -- it looks like a bug in the SCSI layer. > Unable to handle kernel paging request at virtual address e0a1a348 > printing eip: > e0a3decd > *pde = 1fe38067 > *pte = 00000000 > Oops: 0000 [#1] > Modules linked in: nls_iso8859_1 nls_cp437 vfat fat sg floppy sch_cbq > ipt_REJECT ipt_mark ipt_state ipt_MASQUERADE iptable_mangle > iptable_filter ip_nat_ftp iptable_nat ip_tables ip_conntrack_ftp > ip_conntrack nfsd exportfs lockd sunrpc intel_agp agpgart sd_mod > usb_storage loop 3c59x usbhid usblp usbcore parport_pc evdev rtc lp > parport nvram fan button thermal processor ac isofs nls_base > zlib_inflate af_packet non_fatal ide_cd sr_mod scsi_mod cdrom unix > reiserfs raid0 md ide_disk pdc202xx_new piix ide_core > CPU: 0 > EIP: 0060:[<e0a3decd>] Not tainted > EFLAGS: 00010282 (2.6.8.1) > EIP is at hcd_pci_release+0xd/0x11 [usbcore] > eax: dec2c464 ebx: dec2c4b8 ecx: dec2c4b0 edx: e0a1a320 > esi: c028c4dc edi: c028c500 ebp: e0a4f234 esp: dde9feb4 > ds: 007b es: 007b ss: 0068 > Process umount (pid: 12933, threadinfo=dde9f000 task=de3512e0) > Stack: e0a39b73 c01bfb44 00000001 dfe24400 dface400 e0a3d006 dec2c4b8 > c0182cf7 > dface400 c028c2a8 c028c2c0 dfca6c68 e0a366c9 dface4f0 c01be05d > 00000000 > 00000000 00000000 00000000 c0182cf7 de05ab88 e0a5b360 dee4b78c > dfe12480 > Call Trace: > [<e0a39b73>] usb_host_release+0x10/0x12 [usbcore] > [<c01bfb44>] class_dev_release+0x5d/0x65 > [<e0a3d006>] usb_destroy_configuration+0xcd/0xed [usbcore] > [<c0182cf7>] kobject_cleanup+0x8c/0x8e > [<e0a366c9>] usb_release_dev+0x31/0x3f [usbcore] > [<c01be05d>] device_release+0x53/0x57 > [<c0182cf7>] kobject_cleanup+0x8c/0x8e > [<e0a5810b>] scsi_disk_put+0x2a/0x4a [sd_mod] > [<e0a584ab>] sd_release+0x36/0x59 [sd_mod] > [<c014bee5>] blkdev_put+0x100/0x11b > [<c014bebb>] blkdev_put+0xd6/0x11b > [<c014a548>] deactivate_super+0x43/0x58 > [<c015b85e>] sys_umount+0x3b/0x84 > [<c013c2c7>] do_munmap+0xed/0x119 > [<c015b8be>] sys_oldumount+0x17/0x1b > [<c0105c0f>] syscall_call+0x7/0xb > Code: ff 52 28 c3 55 57 89 c7 56 53 89 d3 83 ec 34 e8 19 8d ff ff This is a known bug. See below. > After the patch: > scsi0 (0:): rejecting I/O to dead device > FAT bread failed in fat_clusters_flush > Unable to handle kernel paging request at virtual address e0a1a348 > printing eip: > e0a3decd <...> This is the same as the oops above. In each case, the cause is probably the shutdown scripts on your system. The ehci-hcd driver isn't loaded, so something must have removed it early on during the shutdown procedure. That's not such a good idea, especially if (as in your case) there's still a mounted filesystem on a USB disk. Among other things, it means the disk won't be unmounted cleanly and I/O buffers won't get flushed, since the computer won't be able to communicate with the disk drive. At any rate, this oops occurs whenever a USB host controller driver is unloaded while one of the devices it controls is still open. Your drive was still open because it was mounted, and when the shutdown scripts unmounted it the oops was triggered. The solution is simple: Don't rmmod a USB controller driver until after you have unmounted the USB disk connected to it. In your case, that means don't rmmod ehci-hcd until after the unmount step of the shutdown -- or better yet, don't rmmod it at all. > > You also didn't provide any information that would help anyone trying to > > figure out what the problem is. > > I have now - I hope. Yes, this is a lot better. > These panics do not show up in any logs (that I know of) because they > happen after the loggers are shut down. Well, even if that's not the > reason, I just couldn't find them anywhere ... *shrug* No doubt that was the reason. > On a related note: On a PPC (Apple 14" iBook G4) there are no garbled > kernel messages in the syslog when I attempt to write large files to the > drive (the files copy successfully both with and without your > recommended patch), however, the kernel crashes upon reboot just like on > a x86, regardless of the presence of the patch. I was unable to capture > the PPC crash, however, because the crash doesn't prevent a reboot as it > does on a x86. Maybe with a digital camera ... Don't worry about it, just be sure to unmount your disks before (logically) disconnecting them. That failure mechanism is independent of computer architecture, so it showed up on both the PPC and x86 systems. The earlier problem, about not being able to write large files, is related to timing issues in the Genesys USB chip. Since the two computers run at different clock speeds, one was able to hit the timing bug and the other wasn't. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
