From owner-freebsd-hackers Mon Aug 28 17:25:56 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 655E737B42C for ; Mon, 28 Aug 2000 17:25:48 -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 VAA13128; Mon, 28 Aug 2000 21:10:31 -0400 (EDT) From: "Clarence Brown" To: "'Alfred Perlstein'" , Subject: RE: 4.1 lockup at isa0: on reboot Date: Mon, 28 Aug 2000 20:27:03 -0400 Message-ID: <006601c0114f$db1eeee0$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: <005e01c01137$9cf2b880$8c6896d1@granitepost.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. Next I added another verbose mode printf at the bottom of the loop to print "Done Read_Port at XXX" to see if it was completing that function call. It did printf the "Done" message, so it locked up after this loop. Next, just to be sure I commented out the whole for loop like your suggested patch would have done. This prevented any of the verbose mode messages about Read_Port from being displayed, but the system still locked up after the isa0: message. I tried to figure out where the pnp_identify routine was being called from using grep, but only found it in what looked like a structure definition. I don't know where it's being called from... The system seems to be locking up sometime after pnp_identify but before the line "isa_probe_children: disabling PnP devices" is printed. Any ideas? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message