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

From: Greg Oster <oster@cs.usask.ca>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/36871: Starting X takes very long with kernel 4.99.30, worked with 4.99.4 
Date: Fri, 31 Aug 2007 07:26:37 -0600

 rillig@NetBSD.org writes:
 > >Number:         36871
 > >Category:       kern
 > >Synopsis:       Starting X takes very long with kernel 4.99.30, worked with 
 > 4.99.4
 > >Confidential:   no
 > >Severity:       serious
 > >Priority:       medium
 > >Responsible:    kern-bug-people
 > >State:          open
 > >Class:          sw-bug
 > >Submitter-Id:   net
 > >Arrival-Date:   Fri Aug 31 08:40:00 +0000 2007
 > >Originator:     Roland Illig
 > >Release:        4.99.30
 > >Organization:
 > >Environment:
 > NetBSD bacc.roland-illig.de 4.99.30 NetBSD 4.99.30 (GENERIC) #1: Fri Aug 31 0
 > 9:23:06 CEST 2007  build@bacc.roland-illig.de:/home/scratch/build/NetBSD/2007
 > -08/work/sys/arch/i386/compile/GENERIC i386
 > 
 > >Description:
 > When starting the X server, the screen gets black and stays so for a while. F
 > or some times (four or five), the keyboard LEDs turn on and off, in intervals
 >  of more than ten seconds. After all that, X is started as usual, but the `dm
 > esg' command tells me:
 > 
 > ...
 > pckbport: command timeout
 > pms_enable: command error 35
 > pckbport: command timeout
 > pckbport: command timeout
 > pms_disable: command error
 > pckbport: command timeout
 > pms_enable: command error 35
 > 
 > $ dmesg | grep pck
 > pckbc1 at acpi0 (PS2K, PNP0303): kbd port
 > pckbc1: io 0x60,0x64 irq 1
 > pckbd0 at pckbc1 (kbd slot)
 > pckbc1: using irq 1 for kbd slot
 > wskbd0 at pckbd0: console keyboard
 > pms0 at pckbc1 (aux slot)
 > pckbc1: unable to establish interrupt for aux slot
 > pckbport: command timeout
 > pckbport: command timeout
 > pckbport: command timeout
 > pckbport: command timeout
 
 I think there is another PR open about this, but I don't recall the 
 number off-hand...  I do know that removing these two lines:
 
 pms*            at pckbc?               # PS/2 mouse for wsmouse
 wsmouse*        at pms? mux 0
 
 from the kernel config means things run normally again... 
 
 It's also the case that if you mash keys on the keyboard during the 
 "10 second pauses" that you can significantly reduce the pause...
 
 The issue came in with the addition of ACPI to GENERIC... for some 
 reason things can't distinguish between a PS/2 mouse and PS/2 
 keyboard, and so if you have a PS/2 keyboard the kernel is still 
 expecting to hear from a PS/2 mouse that isn't there... (In all cases 
 where I've seen this problem, the machine has a PS/2 keyboard but USB 
 mouse..)
 
 Later...
 
 Greg Oster