Opened 7 years ago

Closed 6 years ago

#550 closed defect (wontfix)

ACPI Disables Legacy-mode USB Keyboard/Mouse

Reported by: rlwalsh Owned by: dazarewicz
Priority: major Milestone: Feedback pending
Component: ACPI PSD Version: 3.20.03
Keywords: Cc: ggamba@…, acpi@…, rlwalsh

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 rlwalsh 7 years ago.
rwalsh.acpi-tree (51.9 KB) - added by rlwalsh 7 years ago.
rwalsh.pci (61.0 KB) - added by rlwalsh 7 years ago.
FONG-20120724-acpi-3.20.04.zip (53.2 KB) - added by rlwalsh 7 years ago.

Download all attachments as: .zip

Change History (14)

Changed 7 years ago by rlwalsh

Changed 7 years ago by rlwalsh

Changed 7 years ago by rlwalsh

comment:1 Changed 7 years ago by ggamba

  • Cc ggamba@… added

comment:2 Changed 7 years ago by dazarewicz

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 7 years ago by dazarewicz

  • Milestone changed from Release Version 4.0.0 to Feedback pending

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

comment:4 Changed 7 years ago by yoda

  • Cc acpi@… added

Changed 7 years ago by rlwalsh

comment:5 follow-up: Changed 7 years ago by 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.

comment:6 Changed 7 years ago by rlwalsh

  • Cc rlwalsh added

comment:7 in reply to: ↑ 5 Changed 7 years ago by dazarewicz

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 6 years ago by dazarewicz

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 6 years ago by landb

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 6 years ago by dazarewicz

  • Resolution set to wontfix
  • Status changed from new to closed

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.