Opened 12 years ago

Closed 11 years ago

#550 closed defect (wontfix)

ACPI Disables Legacy-mode USB Keyboard/Mouse

Reported by: Rich Walsh Owned by: David Azarewicz
Priority: major Milestone: Feedback pending
Component: ACPI PSD Version: 3.20.03
Keywords: Cc: ggamba@…, acpi@…, Rich Walsh

Description

Several eCS users reported their USB keyboards were dysfunctional during config.sys processing (see bugs 3233 and 3229 at http://bugs.ecomstation.nl/). It was assumed the problem was with the USB drivers. However, my testing suggests that ACPI.PSD disables legacy-mode operation for keyboard and mouse.

Environment:
Intel Core2 Quad CPU, Intel "Classic" mobo with ICH10
USBUHCD, USBEHCD, USBD - v10.162, 10.182, 10.183ga, 10.183-voyage_2012_06_20
USBHID - v10.162, 10.959 (from Rudi Ihle)
ACPI - v3.20.03, no switches
USB v1.1 keyboard and v2.0 mouse, plus PS/2 keyboard (having both keyboards attached did not affect results)

Methodology: On line 1 of config.sys, I put DEVICE=F:\OS2\BOOT\PAUSE.SYS so a keypress would be required immediately after the BASEDEVs had been loaded but before any other drivers loaded. For many tests, I changed this to "PAWSE.SYS" to get the kernel's error message instead. The results were the same either way.

Test 1: I tried each of the driver versions above. In every case, the USB keyboard failed to generate a keypress.

Test2: I REM'd-out every USB-related driver. By rights, Legacy Mode should have remained enabled and usable on the Desktop. Instead, the keyboard was dead for pause.sys and on the Desktop.

Test3: With all the USB drivers disabled, I also REM'd-out ACPI.PSD. The USB keyboard worked for pause.sys and on the Desktop. The mouse pointer moved but the buttons didn't work.

Test4: I reenabled all USB drivers but left ACPI disabled. The keyboard was usable in Legacy mode during config.sys processing and in full-featured mode after the USB drivers were loaded and initialized.

Since my original tests, I've also tried the /VW and/or /PIC switches with no change in result. Attached are the outputs from acpistat, acpitree, and pci.exe.

Attachments (4)

rwalsh.acpi-stat (1.3 KB) - added by Rich Walsh 12 years ago.
rwalsh.acpi-tree (51.9 KB) - added by Rich Walsh 12 years ago.
rwalsh.pci (61.0 KB) - added by Rich Walsh 12 years ago.
FONG-20120724-acpi-3.20.04.zip (53.2 KB) - added by Rich Walsh 12 years ago.

Download all attachments as: .zip

Change History (14)

Changed 12 years ago by Rich Walsh

Attachment: rwalsh.acpi-stat added

Changed 12 years ago by Rich Walsh

Attachment: rwalsh.acpi-tree added

Changed 12 years ago by Rich Walsh

Attachment: rwalsh.pci added

comment:1 Changed 12 years ago by Gabriele Gamba

Cc: ggamba@… added

comment:2 Changed 12 years ago by David Azarewicz

I cannot reproduce this problem on any of my systems. To me it looks like a BIOS feature or a BIOS defect. I cannot think of any log you could provide, or test you could do that would help indicate why your BIOS is no longer providing the USB service. Without having a system with a BIOS that contains this feature/defect in my lab to experiment on, I have no way to troubleshoot the problems of that specific BIOS.

comment:3 Changed 12 years ago by David Azarewicz

Milestone: Release Version 4.0.0Feedback pending

Can you please install the debug PSD and attach a normal testlog to this ticket? Thanks.

comment:4 Changed 12 years ago by yoda

Cc: acpi@… added

Changed 12 years ago by Rich Walsh

comment:5 Changed 12 years ago by Rich Walsh

I'm now aware of 4 motherboards that have this issue: 3 are Intel boards with either an Intel or AMI BIOS; the 4th is a Gigabyte board with an Award BIOS. While this may not be a common problem, it's clearly neither rare nor limited to a specific defective implementation.

comment:6 Changed 12 years ago by Rich Walsh

Cc: Rich Walsh added

comment:7 in reply to:  5 Changed 12 years ago by David Azarewicz

Replying to rlwalsh:

I'm now aware of 4 motherboards that have this issue: 3 are Intel boards with either an Intel or AMI BIOS; the 4th is a Gigabyte board with an Award BIOS. While this may not be a common problem, it's clearly neither rare nor limited to a specific defective implementation.

That's great. More of a sample set to work from. I got the testlog from FONG. I would like a testlog from as many of those other systems as possible.

comment:8 Changed 11 years ago by David Azarewicz

No response in 9 months. Still waiting for feedback. There is nothing for me to do until I get more testlog data from more systems.

comment:9 Changed 11 years ago by barry landy

I presume this is precisely the problem I have also with an Intel mobo. I am at this minute trying to change to a mobo with a PS2 port to sidestep this problem. or else I would volunteer to run the trace for you. When it comes back from the shop.

comment:10 Changed 11 years ago by David Azarewicz

Resolution: wontfix
Status: newclosed

Further investigation reveals that this is an intentional feature designed into the BIOS by some manufacturers. This is not a defect -- it is an intentional BIOS feature. The BIOS writers intentionally stop providing USB keyboard services when they detect that ACPI has been enabled. In some rare cases the BIOS writers use AML methods to do this. If so, there may be workarounds but a detailed analysis of each individual system would be necessary to determine if a workaround is possible. In most cases the feature is in the BIOS code so nothing can be done about it. The better solution is to find alternate ways of providing USB keyboard support during the boot process.

Investigation is ongoing regarding alternate ways to provide USB keyboard support during the boot process. None of this investigation is related to the ACPI software since the ACPI software is not involved in this issue.

Note: See TracTickets for help on using tickets.