i386/87026: Bootup hang on atkbdc on Compaq 1850R between 6.0-CURRENT-SNAP004 and 6.0-BETA5

[Nick Evans]

The following reply was made to PR i386/87026; it has been noted by GNATS.

From: Nick Evans <nevans at talkpoint.com>
To: bug-followup at 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: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
 > atkbd0: <AT Keyboard> 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: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
 > atkbd0: <AT Keyboard> 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.