From owner-freebsd-current@FreeBSD.ORG Wed Dec 31 21:13:25 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 8605616A4CF for ; Wed, 31 Dec 2003 21:13:25 -0800 (PST) Received: from ms-smtp-02-eri0.socal.rr.com (ms-smtp-02-qfe0.socal.rr.com [66.75.162.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D7C643D55 for ; Wed, 31 Dec 2003 21:13:24 -0800 (PST) (envelope-from jsg@san.rr.com) Received: from [159.62.32.249] (66-75-228-39.san.rr.com [66.75.228.39]) i015DNNS011984; Wed, 31 Dec 2003 21:13:23 -0800 (PST) Mime-Version: 1.0 X-Sender: jsg@pop-server.san.rr.com Message-Id: Date: Wed, 31 Dec 2003 21:11:02 -0800 To: freebsd-current@freebsd.org From: J S Goldberg Content-Type: text/plain; charset="us-ascii" cc: jsg-rr Subject: RC2 hangs on ACPI boot (ASUS a7n8x, nvidia) 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: Thu, 01 Jan 2004 05:13:25 -0000 I installed both 4.9 and 5.1 ok on my ASUS A7N8X (nvidia chipset) with AMD 2500 cpu. After I cvsup'd to 5.2 a few days ago, the kernel would no longer boot, hanging after: Timecounters tick every 10.000 msec Being new to the cvsup routine, I thought perhaps that I'd made an error in following the notes in UPDATING about installing the kernel and booting that before doing the installworld. So I downloaded the RC2 iso, made a CD and booted from that. It hung on boot in the same place. Booting with verbose logging gives one more line: procfs registered Timecounter "TSC:" frequency 1837513615 Hz quality 800 Timecounters tick every 10.000 msec lo0: bpf attached Having seen other comments about nvidia and ACPI, I tried booting the CD with acpi disabled - and it worked. I also tried booting my cvsup'd disk image without ACPI and it also worked ok. That leaves me with a system which requires manual interaction to boot. One workaround that seems to work was to rename /boot/kernel/acpi.ko. Not a good solution, as I expect that future cvsup/build cycles will eventually restore the acpi.ko file (and problem). So... the point of the post: 1. The observation of this ACPI problem (might be related to others I've seen mentioned recently). 2. A request for a (cleaner) workaround to booting. E.g., a way to disable acpi by default. thanks for your help! j