From owner-freebsd-questions Tue Nov 21 11: 3:47 2000 Delivered-To: freebsd-questions@freebsd.org Received: from freesurfmail.sunrise.ch (freesurfmta01.sunrise.ch [194.230.0.16]) by hub.freebsd.org (Postfix) with ESMTP id 5EDAA37B4C5 for ; Tue, 21 Nov 2000 11:03:43 -0800 (PST) Received: from manuel.bluewin.ch (194.230.142.186) by freesurfmail.sunrise.ch (5.1.053) id 39F7FFC8001C198C for questions@freebsd.org; Tue, 21 Nov 2000 20:03:41 +0100 Message-Id: <5.0.0.25.2.20001121192525.00bd7098@pop.bluewin.ch> X-Sender: manuelk@pop.bluewin.ch X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 21 Nov 2000 20:03:34 +0100 To: questions@freebsd.org From: Manuel Kasper Subject: Kernel panic when mounting CD-ROM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all, I've got yet another question. When I try to mount a CD-ROM in FreeBSD 4.1.1-RELEASE on a Compaq ML370 server AND the drive is not yet ready, I get a kernel panic, like this: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc139d000 fault code = supervisor write, page not present instruction pointer = 0x8:0xc02c0e92 stack pointer = 0x10:0xc0356eb0 frame pointer = 0x10:0xc0356ec0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = bio trap number = 12 panic: page fault syncing disks... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x964cabf fault code = supervisor read, page not present instruction pointer = 0x8:0xc02833b5 stack pointer = 0x10:0xc0356d1c frame pointer = 0x10:0xc0356d34 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = bio trap number = 12 panic: page fault --- I've provocated the panic several times now, and every time the trace looks the same: --- #0 boot (howto=260) at ../../kern/kern_shutdown.c:302 #1 0xc0193ad8 in poweroff_wait (junk=0xc034d88f, howto=0) at ../../kern/kern_shutdown.c:552 #2 0xc02edec5 in trap_fatal (frame=0xc0356cdc, eva=157600447) at ../../i386/i386/trap.c:951 #3 0xc02edb9d in trap_pfault (frame=0xc0356cdc, usermode=0, eva=157600447) at ../../i386/i386/trap.c:844 #4 0xc02ed757 in trap (frame={tf_fs = 16, tf_es = -1070268400, tf_ds = -1072103408, tf_edi = -855041856, tf_esi = -1053181184, tf_ebp = -1070240460, tf_isp = -1070240504, tf_ebx = 157599123, tf_edx = -855042048, tf_ecx = -855042048, tf_eax = -1054914048, tf_trapno = 12, tf_err = 0, tf_eip = -1071107147, tf_cs = 8, tf_eflags = 66118, tf_esp = -855042048, tf_ss = -1069941536}) at ../../i386/i386/trap.c:443 #5 0xc02833b5 in ffs_update (vp=0xcd091800, waitfor=0) at ../../ufs/ffs/ffs_inode.c:89 #6 0xc028b044 in ffs_sync (mp=0xc11f4a00, waitfor=2, cred=0xc0e2b880, p=0xc039fce0) at ../../ufs/ffs/ffs_vfsops.c:987 #7 0xc01c052f in sync (p=0xc039fce0, uap=0x0) at ../../kern/vfs_syscalls.c:544 #8 0xc0193527 in boot (howto=256) at ../../kern/kern_shutdown.c:224 #9 0xc0193ad8 in poweroff_wait (junk=0xc034d88f, howto=0) at ../../kern/kern_shutdown.c:552 #10 0xc02edec5 in trap_fatal (frame=0xc0356e70, eva=3241791488) at ../../i386/i386/trap.c:951 #11 0xc02edb9d in trap_pfault (frame=0xc0356e70, usermode=0, eva=3241791488) at ../../i386/i386/trap.c:844 #12 0xc02ed757 in trap (frame={tf_fs = -1072103408, tf_es = -65520, tf_ds = -969015280, tf_edi = -1053175808, tf_esi = 32768, tf_ebp = -1070240064, tf_isp = -1070240100, tf_ebx = -1053191552, tf_edx = 496, tf_ecx = 1024, tf_eax = -1055651200, tf_trapno = 12, tf_err = 2, tf_eip = -1070854510, tf_cs = 8, tf_eflags = 66054, tf_esp = -1055517056, tf_ss = -1053191552}) at ../../i386/i386/trap.c:443 #13 0xc02c0e92 in atapi_read (request=0xc1399280, length=32768) at machine/cpufunc.h:222 #14 0xc02c09c7 in atapi_interrupt (request=0xc1399280) at ../../dev/ata/atapi-all.c:362 #15 0xc02bc472 in ata_intr (data=0xc1140a80) at ../../dev/ata/ata-all.c:1125 --- If I understand this right, there are two traps here - the first one in atapi_read(), and the second one in ffs_update(). If I wait a while to make sure the drive is ready, everything works well. However I don't like the idea of having a system like FreeBSD crash just because the CD-ROM drive is still spinning up. ;) I reinstalled the whole system, recompiled the kernel, cvsup'ed and made world - still the same thing. I first suspected a hardware problem but the same thing works fine in Linux. I'm not sure if this has anything to do with my problem, but here's what the kernel says during boot: --- atapci0: port 0x3040-0x304f at device 15.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ata1: unable to allocate interrupt device_probe_and_attach: ata1 attach returned 6 --- ...it's no surprise since there's no device attached to ata1 and Compaq provides no provision in their setup to disable the second IDE controller. Hmm I'm starting to hate that ML370 beast... However I can't really blame it yet since it works fine in Linux... :( Did anybody ever experience the same kind of problem or can I safely assume that this issue will not affect the system in normal operation? Any suggestions would be greatly appreciated. Thanks, Manuel To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message