From owner-freebsd-mobile Mon Jan 19 18:49:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA19050 for freebsd-mobile-outgoing; Mon, 19 Jan 1998 18:49:38 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA19042 for ; Mon, 19 Jan 1998 18:49:30 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id TAA16799; Mon, 19 Jan 1998 19:49:29 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id TAA07257; Mon, 19 Jan 1998 19:49:27 -0700 Date: Mon, 19 Jan 1998 19:49:27 -0700 Message-Id: <199801200249.TAA07257@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Ugo Paternostro Cc: Nate Williams , freebsd-mobile@FreeBSD.ORG Subject: Re: Cirrus Logic PD6729 In-Reply-To: References: <199801181911.MAA00697@mt.sri.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >> reboot, it boots ok once more, and so on (all the even boots end with a > >> panic, > >> but the odd ones work perfectly). > > > > Interesting. Any chance of getting a crash dump to see exactly where > > the fault is occurring? > > How do I obtain that? I wrote down the information that the kernel prints, if > you like I can send them to you. In /etc/rc.conf, add a swap partition which contains enough space to dump out your entire memory to: ############################################################## ### Miscellaneous administrative options ################### ############################################################## ... dumpdev="/dev/sd0s1b" # Device name to crashdump to (if enabled). Which is my primary swap partition and has more than enough space. Then, if the kernel crashes, it dumps out the contents of memory to the swap partition, and at the next reboot it will save this crash dump in /var/dump (you may need to symlink that to a spot that has more disk space). Then, you can run gdb -k kernel.0 vmcore.0 and get a stack trace of the crash. > > It's possible that the 'poll' is causing the panic. Try disabling the > > poll of the PCCARD controller in /sys/pccard/pcic.c. A cut-paste > > uni-diff is appended below (don't apply it, it won't work). ..> > It seems that I (still) have a problem. Don't you think I should disable the > interrupts generated from the chip? Yes, the above comment was implied that both the interrupts *and* the poll should both be disabled. Nate