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)

by Rich Walsh, 12 years ago

Attachment: rwalsh.acpi-stat added

by Rich Walsh, 12 years ago

Attachment: rwalsh.acpi-tree added

by Rich Walsh, 12 years ago

Attachment: rwalsh.pci added

comment:1 by Gabriele Gamba, 12 years ago

Cc: ggamba@… added

comment:2 by David Azarewicz, 12 years ago

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 by David Azarewicz, 12 years ago

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 by yoda, 12 years ago

Cc: acpi@… added

by Rich Walsh, 12 years ago

comment:5 by Rich Walsh, 12 years ago

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 by Rich Walsh, 12 years ago

Cc: Rich Walsh added

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

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 by David Azarewicz, 12 years ago

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 by barry landy, 12 years ago

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 by David Azarewicz, 11 years ago

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.