From owner-freebsd-i386@FreeBSD.ORG Fri Oct 7 18:00:28 2005 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26D7B16A420 for ; Fri, 7 Oct 2005 18:00:28 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5AD543D49 for ; Fri, 7 Oct 2005 18:00:27 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j97I0RrD098937 for ; Fri, 7 Oct 2005 18:00:27 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j97I0QYw098936; Fri, 7 Oct 2005 18:00:26 GMT (envelope-from gnats) Date: Fri, 7 Oct 2005 18:00:26 GMT Message-Id: <200510071800.j97I0QYw098936@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Nick Evans Cc: Subject: Re: i386/87026: Bootup hang on atkbdc on Compaq 1850R between 6.0-CURRENT-SNAP004 and 6.0-BETA5 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Nick Evans List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2005 18:00:28 -0000 The following reply was made to PR i386/87026; it has been noted by GNATS. From: Nick Evans To: bug-followup@FreeBSD.org Cc: Subject: Re: i386/87026: Bootup hang on atkbdc on Compaq 1850R between 6.0-CURRENT-SNAP004 and 6.0-BETA5 Date: Fri, 7 Oct 2005 13:50:33 -0400 Received the following from Marius Strobl: -------------- On Thu, Oct 06, 2005 at 06:29:44PM -0400, Nick Evans wrote: > > I've got a Compaq 1850R (dual 600Mhz P3, 512MB) that I tried upgrading to > 6.0- BETA5 from 4.9-RELEASE today, but she hangs on: > > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > > I used an older 6.0-CURRENT-SNAP004 disc whose kernel was compiled on Jun > 02, 2005 and the system boots up just fine. With the following: > > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > ... > > I noticed on June 10th you committed changes to atkbdc and was wondering if > it's possible there was a bug or regression introduced with them. I'm leary > about building world until I'm sure I can get past the keyboard driver hang. Hi, the commit on June 10th mainly moved all files related to atkbdc(4) and its children to sys/dev/atkbdc and reshuffled some code but had next to no functional changes on architectures other than sparc64. So far there where no reports that these changes actually broke one of these drivers, only false ones. One was that on some machines the fact that the malloc-type atkbdc(4) defines no longer is static happend to exhaust UMA_BOOT_PAGES on some machines which were already close the edge due to other changes. UMA_BOOT_PAGES was increased accordingly. There was another report of keyboard problems since then but which turned out to be triggered by ehci(4): http://lists.freebsd.org/pipermail/freebsd-current/2005-August/053957.html I have look at my changes to atkbdc(4) etc. over and over again due to these and still can't think of why the changes could have a negative impact on these drivers. Therefore I think that other changes since June 2nd are causing you problems. The ever ongoing changes to interrupt handling and routing on i386 come to my mind (probing and attaching the keyboards triggers interrupts and I've seen hangs during device configuration caused by problems with interrupts before). But generally I unfortunately can't think of a particular change. It sounds like you already installed a 6.0 kernel on the hard disk. If that's the case you could try some things in order to avoid the hang. In particular you could try to add hint.atkbd.0.flags="0x1" to /boot/device.hints and also try with hint.atkbd.0.flags="0x8". You could also try to remove the hint.atkb* lines there entirely, that way the keyboard controller and its children should be probed somewhat later in that game through PnP rather than as legacy ISA devices. If your board supports ACPI you could also try whether enabling it makes a difference. > Is there anything I can try on the BETA5 disc to either get more information > about the hang to pass on to you or bypass the issue entirely? > Well, you could do a verbose boot but I don't think that won't yield relevant information. If you build a custom kernel with options DDB and KDB enabled or have a 6.0 BETA3 disk which still had these enabled in the GENERIC kernel (I think BETA 4.0, too, but certainly not BETA5) you could try to press CTRL-ALT-ESC in oder to break into the debugger and check with the 'where' command where the machine hangs. Whether breaking into the debugger via that key sequence works however depends on whether the keyboard works at that time (either due to being sufficiently attached for high-level console support or still working through low-level console support before it is reinitialized). If that doesn't work you'll need to use a serial console together with a kernel that is built with options BREAK_TO_DEBUGGER in addition to DDB and KDB and send a break signal on the serial line. Marius ------------------------ It appears there is some sort of interrupt problem as he mentions. I took another 1850R server without any additional PCI cards installed and 6.0-BETA5 boots fine. The original server contained two fxp cards and a hifn crypto accelerator. I will test a few additional things to isolate the problem further.