From owner-freebsd-current@FreeBSD.ORG Sun Aug 7 17:04:57 2005 Return-Path: X-Original-To: current@freebsd.org 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 B11E916A44C for ; Sun, 7 Aug 2005 17:04:57 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0721943F60 for ; Sun, 7 Aug 2005 16:36:19 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from [192.168.1.254] (really [70.32.199.60]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with ESMTP id <20050807163619.ZPBV14360.mta13.adelphia.net@[192.168.1.254]>; Sun, 7 Aug 2005 12:36:19 -0400 Message-ID: <42F6388A.9000208@savvis.net> Date: Sun, 07 Aug 2005 09:36:26 -0700 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Marcus Clarke References: <1123369733.852.12.camel@shumai.marcuscom.com> <1123390349.852.21.camel@shumai.marcuscom.com> <42F631F9.8030607@savvis.net> In-Reply-To: <42F631F9.8030607@savvis.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: No keyboard in sysinstall in 6.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 07 Aug 2005 17:04:58 -0000 > Joe Marcus Clarke wrote: > >> On Sat, 2005-08-06 at 19:08 -0400, Joe Marcus Clarke wrote: >> >>> I'm trying to install FreeBSD 6.0-BETA2 from CD on Dell Precision 380. >>> The machine has a PS/2 keyboard on it. The keyboard works fine in the >>> BIOS, and at the Booting... prompt. However, once sysinstall comes up, >>> the keyboard is dead. Nothing I type will be accepted. The machine >>> does not appear to be panicked or hung. >>> >>> I switched from vidconsole to comconsole, and sysinstall works, so >>> perhaps this has something to do with the new keyboard mux? >>> >>> Dmesg is at http://www.marcuscom.com/downloads/NEW-SHUMAI.dmesg >> >> >> >> More news on this. After getting 6.0-BETA2 installed from the serial >> console, I found that _any_ input on the PS/2 port causes the machine to >> lock up hard. I can break into the debugger, but as soon as I hit any >> key on the PS/2 keyboard, the machine locks up. I can't type anything >> (even from the serial console). The only way out is to do a hard reset. >> >> I've tried building a custom kernel and disabling apic and acpi. >> Nothing will get 6.0 to work with any locally attached keyboard. >> >> I also found a CD of 5.4-RC3, which boots perfectly on this machine with >> working PS/2 and USB keyboards. So, I thought maybe the kbdmux was the >> problem. I reverted the kbd code to original RELENG_6 version (kbd.c >> rev. 1.43 and kbdreg.h rev. 1.17), and the keyboard works once again. >> Anything else I can try to debug this problem with kbdmux further? > > > i doubt kbdmux(4) is your problem. according to the dmesg you have > posted you dont seem to use/load kbdmux(4) driver. it is highly unlikely > that my changes in /sys/dev/kbd/ cause this. kbdmux(4) is not default > keyboard and, at this point, one must configure/load it by hand. my > guess would be that you, perhaps, have some sort of interrupt routing > problem or something like it. actually, now i'm confused. as you stated you have reverted /sys/dev/kbd/kbd.c and /sys/dev/kbd/kbdreg.h. are these only files you have reverted? i think, i can rule out /sys/dev/kbd/kbdreg.h - this just add a prototype for kbd_find_keyboard2(). so this leaves only /sys/dev/kbd/kbd.c. the only change here was new kbd_find_keyboard2() function and change to the original kbd_find_keyboard() function. kbd_find_keyboard2() function is almost the same as the original kbd_find_keyboard() function. the only difference is that kbd_find_keyboard2() accepts one extra parameter that specifies starting index for search. it also checks the index to make sure it is within valid bounds. naturally, kbd_find_keyboard() can just call kbd_find_keyboard2() with starting index of 0 to emulate old behavior. unless i screwed up here, i do not see how this would break anything. also, one thing i noticed in your dmesg output atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: flags 0x3 irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0xffffffff (1) kbd0 at atkbd0 kbd0: atkbd0, AT 84 (1), config:0x3, flags:0x3d0000 atkbd0: [GIANT-LOCKED] just wanted to clarify - do you really have 84-keys at keyboard? thanks, max