From owner-freebsd-hackers Mon Aug 28 14:32: 4 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from fbsd01.granitepost.com (fbsd01.granitepost.com [209.150.104.131]) by hub.freebsd.org (Postfix) with ESMTP id 0B2F237B422 for ; Mon, 28 Aug 2000 14:31:59 -0700 (PDT) Received: from thunder (thunder.granitepost.com [209.150.104.140]) by fbsd01.granitepost.com (8.8.5/8.8.5) with SMTP id SAA12616; Mon, 28 Aug 2000 18:16:38 -0400 (EDT) From: "Clarence Brown" To: "'Alfred Perlstein'" , Subject: RE: 4.1 lockup at isa0: on reboot Date: Mon, 28 Aug 2000 17:33:30 -0400 Message-ID: <005e01c01137$9cf2b880$8c6896d1@granitepost.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <20000828133415.I1209@fw.wintelcom.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > -----Original Message----- > From: 'Alfred Perlstein' [mailto:bright@wintelcom.net] > Sent: Monday, August 28, 2000 4:34 PM snip > > like your patch just comments out the whole for loop, right? > > Yes > I must admit that being a C coder I just couldn't resist modifying pnp.c a little differently instead of using the patch. I modified the for line to stop after 383 and before 3c3 by changing the comparison in the for statement from "< 0xff" to "< 0xf0". This did indeed do what I expected, stopping the for loop at 383 instead of 3c3, but the machine still locked up and the last line displayed was "Trying Read_Port at 383" instead of 3c3. So, what ever is going awry doesn't seem to involve the 3c3 port specifically. This make was relatively painless since the only change was to pnp.c, so I'll try commenting the whole loop out, and/or adding a printf after the for loop to see if it gets there. > > that's cool, being able to get a traceback from the hang would be > good. > I don't know how to get a trace back from the hang. When I tried what you suggested before, hitting Ctrl-Alt-Esc at the hang, there was no response. It was apparently REALLY hung... I'm used to using a symbolic debugger, where you can set breakpoints based on lines in a source file. The Debug Page seemed to say that wasn't available in DDB. What mechanism can I use in DDB to get close to the error and start single stepping, or what ever? Cla. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message