From owner-freebsd-hardware Thu Nov 8 5: 4:43 2001 Delivered-To: freebsd-hardware@freebsd.org Received: from mailhost2.dircon.co.uk (mailhost2.dircon.co.uk [194.112.32.66]) by hub.freebsd.org (Postfix) with ESMTP id 6FB2E37B418 for ; Thu, 8 Nov 2001 05:04:39 -0800 (PST) Received: from localhost (desk43.ch.dircon.net [195.157.3.43]) by mailhost2.dircon.co.uk (8.9.3/8.9.3) with ESMTP id NAA77699 for ; Thu, 8 Nov 2001 13:04:37 GMT Message-Id: <200111081304.NAA77699@mailhost2.dircon.co.uk> From: "Mark Blackman" To: freebsd-hardware@freebsd.org Subject: FreeBSD won't reboot this motherboard. Date: Thu, 08 Nov 2001 13:04:44 +0000 Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I've got a GA-6VTXDR-C motherboard with 1GHz pentium and 1Gig of RAM. (http://networking.gigabyte.com.tw/Products/Products_ServerBoard_Spec.asp?ProductID=20) This uses the Via Apollo Pro Family AGP Set (North Bridge VT82C694T, South Bridge VT82C686B) I've been attempting to reboot this machine via the "/sbin/reboot" executable. In all the cases I've tried, the full shutdown messages occur, followed by the "Rebooting" output. After putting this line to the screen, the machine fails to do anything (for 30 seconds and more). Reboot is then achieved only with a hard reset or power cycle. I've tried CURRENT (cvsup today) and STABLE (cvsup yesterday) and they both have this behaviour. 4.4-STABLE-yesterday (GENERIC without BROKEN_KEYBOARD_RESET) - hangs after "Rebooting" 4.4-STABLE-yesterday (GENERICE with BROKEN_KEYBOARD_RESET) - hangs after "Rebooting" 5.0-CURRENT-today (without BROKEN_KEYBOARD_RESET) - hangs after "Rebooting" 5.0-CURRENT-today (with BROKEN_KEYBOARD_RESET) - drops into debugger with double panic after ~5 sec. FWIW, Redhat 7.2 does reboot the machine. My reading of the Linux kernel code suggests that Linux puts the machine into 8086 emulation mode (real mode) and then calls the BIOS reboot. I have 3 identical spec. machines which all exhibit this behaviour. Can anyone suggest any other options for forcing a reboot and what does this imply about the way this hardware works? - Mark To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message