From owner-freebsd-current Wed Nov 18 02:39:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA15193 for freebsd-current-outgoing; Wed, 18 Nov 1998 02:39:20 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from foobar.franken.de (foobar.franken.de [194.94.249.81]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA15185 for ; Wed, 18 Nov 1998 02:39:02 -0800 (PST) (envelope-from logix@foobar.franken.de) Received: (from logix@localhost) by foobar.franken.de (8.8.8/8.8.5) id LAA05550 for freebsd-current@FreeBSD.ORG; Wed, 18 Nov 1998 11:38:05 +0100 (CET) Message-ID: <19981118113805.A5521@foobar.franken.de> Date: Wed, 18 Nov 1998 11:38:05 +0100 From: Harold Gutch To: freebsd-current@FreeBSD.ORG Subject: page fault when rm'ing on ccd-partition Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i X-Organisation: BatmanSystemDistribution X-Mission: To free the world from the Penguin Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I'm experiencing problems on a (non-local) 3.0-19980916-SNAP non-SMP System. When rm'ing certain files from a ccd'd disk the machine panics. I can't really localize the problem any further as: - I don't know which files exactly cause the problem, or what they have in common, find -mtime 7 | xargs rm over one of the ccd-partitions reproducebly panics the machine though. - A person local to the machine wrote down the following panic-output: Fatal Trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xf01152c7 stack pointer = 0x10:0xf0211f7c frame pointer = 0x10:0xf0211f94 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL0, pres 1, def32 1, gran 1 processor flags = interrupt enabled, resume, IOPL=0 current process = Idle interrupt mask = cam trap number = 12 panic: page fault $ nm -aout /kernel | grep f01152 f0115288 t _ahc_handle_target_cmd from /etc/ccd.conf: ccd1 65536 0 /dev/sd4g /dev/sd5g /dev/sd6g /dev/sd7g So if it's the SCSI-driver which causes the panics, trying to dump to a SCSI-disk isn't very likely to succeed :). - The kernel even refuses to dump to a newly plugged in IDE-disk, a partition of which is configured as swap- and dumpdevice, but after booting the output "savecore: no core dump" can be seen. As the machine is about an hour's ride away from me, I'd rather be able to debug the problem remotely. I asked for a serial cable to a linux-box standing next to the FreeBSD-machine, I guess I then could use it as console, get it to fall to ddb when panicing and then get a stacktrace - or am I missing something that wouldn't work ? If i got the kernel do dump to the IDE-disk, that too would of course help... any ideas why this is failing ? -- bye, logix Sleep is an abstinence syndrome wich occurs due to lack of caffein. ed Mar 4 04:53:33 CET 1998 #unix, ircnet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message