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)
Change History (14)
by , 12 years ago
Attachment: | rwalsh.acpi-stat added |
---|
by , 12 years ago
Attachment: | rwalsh.acpi-tree added |
---|
by , 12 years ago
Attachment: | rwalsh.pci added |
---|
comment:1 by , 12 years ago
Cc: | added |
---|
comment:2 by , 12 years ago
comment:3 by , 12 years ago
Milestone: | Release Version 4.0.0 → Feedback pending |
---|
Can you please install the debug PSD and attach a normal testlog to this ticket? Thanks.
comment:4 by , 12 years ago
Cc: | added |
---|
by , 12 years ago
Attachment: | FONG-20120724-acpi-3.20.04.zip added |
---|
follow-up: 7 comment:5 by , 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 , 12 years ago
Cc: | added |
---|
comment:7 by , 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 , 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 , 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 , 11 years ago
Resolution: | → wontfix |
---|---|
Status: | new → 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.
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.