From owner-freebsd-current@FreeBSD.ORG Tue Dec 2 11:18:45 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40C5316A4CE; Tue, 2 Dec 2003 11:18:45 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13E6C43FFB; Tue, 2 Dec 2003 11:18:27 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) hB2JIQiF029347; Tue, 2 Dec 2003 11:18:26 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id hB2JIQHX029346; Tue, 2 Dec 2003 11:18:26 -0800 (PST) (envelope-from dillon) Date: Tue, 2 Dec 2003 11:18:26 -0800 (PST) From: Matthew Dillon Message-Id: <200312021918.hB2JIQHX029346@apollo.backplane.com> To: John Baldwin References: cc: Greg 'groggy' Lehey cc: re@freebsd.org cc: current@freebsd.org Subject: Re: 5.2-RELEASE TODO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2003 19:18:45 -0000 :> This argument is exactly why I added the 'disable acpi' option in the boot :> loader menu. Of course, we STILL need to get good debugging information :> from you as to why you get a Trap 9 when ACPI is disabled. This is the :> more important issue. : :This is actually a known issue on Intel motherboards. Somehow we broke :something in our bios32 code. 4.x works fine using the BIOS to enumerate :PNP BIOS devices, but 5.x (including 5.0 and 5.1) get a GPF (Trap 9) :with the code segment set to 0x58 trying to enumerate the last PNPBIOS :device. Somehow the BIOS routine jumps off into lala land where it :eventually traps. I dumped the BIOS and dissassembled and tried to walk :it to figure out how it was breaking but couldn't see anything obvious. : :-- : :John Baldwin <>< http://www.FreeBSD.org/~jhb/ I have a motherboard that even 4.x doesn't work on... same deal, GPF while enumerating PNP devices. It died on the 6th device or something like that. I went so far as to 'fix' DDB's disassembler (in DFly) to properly decode the code segment (instead of double faulting on a 'bad' EIP in DDB) and properly show 16 bit instructions, and I set break points and single-stepped through. It died in the same place every time, during an attempt to issue a write to a CS: prefixed memory address. But I suspect a bad branch or indirect-jump table lookup. I finally gave up but if I were to do it again I would attach a serial console and record the single-step session all the way through two device number iterations... the one prior to the one that failed, and the one that failed, then I'd compare the output for the successful device iteration verses the failure to figure out where they diverge. That's what I suggest... don't play around, just connect the serial console, fix DDB's disassembler (you can pop the changes that I made in DFly, they should be the same), single step through two iterations, and compare. If you figure out what is causing the problem I'd love an email. I suspect it is a mapping overlap somewhere due to the page 0 map. I just can't think of anything else it might be. -Matt Matthew Dillon