Date: Thu, 19 Nov 1998 12:57:26 +1030 From: Greg Lehey <grog@lemis.com> To: Harold Gutch <logix@foobar.franken.de>, freebsd-current@FreeBSD.ORG Subject: Re: page fault when rm'ing on ccd-partition Message-ID: <19981119125726.I467@freebie.lemis.com> In-Reply-To: <19981118113805.A5521@foobar.franken.de>; from Harold Gutch on Wed, Nov 18, 1998 at 11:38:05AM %2B0100 References: <19981118113805.A5521@foobar.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, 18 November 1998 at 11:38:05 +0100, Harold Gutch wrote: > 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 You really need a little more information than this. Build a debug kernel and use gdb to show the lines that correspond to the IP where it fails. You can use /dev/mem as the dump file. > 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. What happens before the boot, when it's supposed to be dumping? > 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 ? No, that should work. It's liable to be a painful way of doing things, though. You'd be better off with a FreeBSD box with a copy of the sources and kernel gdb, which you could then use to debug the system relatively well. > If i got the kernel do dump to the IDE-disk, that too would of > course help... any ideas why this is failing ? I could only guess, and guesswork doesn't help in this kind of situation. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981119125726.I467>