Date: Fri, 19 May 2000 20:56:34 -0400 (EDT) From: grafe@lab12.ie.pitt.edu (Gary Rafe) To: freebsd-mobile@freebsd.org Subject: Kernel (4.0R) panic when USB Zip attached at boot Message-ID: <200005200056.e4K0uYe06519@lab12.ie.pitt.edu>
next in thread | raw e-mail | index | archive | help
Synopsis: Kernel panic when USB Zip drive is attached at boot time. Hardware: Toshiba Satellite 4030CDT, Iomega USB Zip 100 drive. OS: 4.0-Release After running 3.3-R/PAO for months successfully on this notebook, I had some spare time recently to upgrade to 4.0-R via CDROMs. Just about everything went well with the upgrade, until I discovered that support for external Zip drives on non-EPP parallel ports is broken in 4.0-R. The 4030CDT appears only to support ECP/PS2/NIBBLE and COMPATIBLE modes. Having access to a Zip drive (however slow it might be) means I don't need to bring the notebook to the office daily, so I located a USB Zip drive, built a new kernel, fired up usbd, and after a few false starts (e.g., a disk needs to be installed in the drive for "camcontrol rescan bus 0" to succeed), I am able to read/write MSDOS Zip disks (and much faster than the 3.3-R PS/2-mode parallel port setup). And this is very good. I find now, however, that leaving the drive connected to the system when it is re-booted causes the kernel to panic. Relevant output from dmesg follows: ... /kernel: ata0: at 0x1f0 irq 14 on atapci0 /kernel: ata1: at 0x170 irq 15 on atapci0 toshnik /kernel: uhci0: <Intel 82371AB/EB (PIIX4) USB controller> port 0xffe0-0xffff irq 11 at device 5.2 on pci0 /kernel: usb0: <Intel 82371AB/EB (PIIX4) USB controller> on uhci0 /kernel: usb0: USB revision 1.0 /kernel: uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 /kernel: uhub0: 2 ports with 2 removable, self powered /kernel: umass0: Iomega USB Zip 100, rev 1.10/1.00, addr 2, iclass 8/6/80 /kernel: chip1: <Intel 82371AB Power management controller> port 0xfe70-0xfe7f at device 5.3 on pci0 ... /kernel: ad0: 4126MB <IBM-DKLA-24320> [8944/15/63] at ata0-master using UDMA33 /kernel: acd0: CDROM <CD-224E> at ata1-master using WDMA2 /kernel: /kernel: /kernel: Fatal trap 12: page fault while in kernel mode /kernel: fault virtual address = 0x70 /kernel: fault code = supervisor read, page not present /kernel: instruction pointer = 0x8:0xc01437b0 /kernel: stack pointer = 0x10:0xc0243278 /kernel: frame pointer = 0x10:0xc02432a8 /kernel: code segment = base 0x0, limit 0xfffff, type 0x1b /kernel: = DPL 0, pres 1, def32 1, gran 1 /kernel: processor eflags = interrupt enabled, resume, IOPL = 0 /kernel: current process = Idle /kernel: interrupt mask = net tty bio cam /kernel: trap number = 12 /kernel: panic: page fault /kernel: /kernel: syncing disks... /kernel: done /kernel: Uptime: 14s /kernel: Automatic reboot in 15 seconds - press a key on the console to abort /kernel: --> Press a key on the console to reboot <-- at which point, I detach the USB Zip drive, reboot the system, and re-attach the drive after usbd is started. I should note that APM suspend/resume appears to work OK, apart from the complaint about this panicking the system: /kernel: sio1: unloaded /kernel: pccard: card disabled, slot 0 /kernel: resumed from suspended mode (slept 00:01:04) /kernel: pccard: card inserted, slot 0 /kernel: ata0: resetting devices .. done /kernel: ata1: resetting devices .. done /kernel: usb0: resume detect /kernel: umass0: at uhub0 port 1 (addr 2) disconnected /kernel: umass0: Woops! This will panic your system. /kernel: Detachment of the drive is not supported currently. /kernel: (da0:umass0:0:1:0): lost device /kernel: (da0:umass0:0:1:0): removing device entry /kernel: umass0: Iomega USB Zip 100, rev 1.10/1.00, addr 2, iclass 8/6/80 apmd[138]: apmevent 0003 index 1 A subsequent "camcontrol rescan bus 0" with a disk inserted lets me mount the drive again without difficulty. Fortunately, my experience has been that system re-boots are somewhat rare events when APM suspend/resume work properly. So, is this kernel panic with a USB Zip drive attached worthy of a bug report ? Or is this a configuration problem that I haven't addressed properly. All-in-all, I continue to marvel at the robustness of FreeBSD. My apologies for the long-ish post. -- Gary Rafe gerst4+@pitt.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005200056.e4K0uYe06519>