Hey again,
First: my hardware, motherboard is VIA KT-400 based Epox 8K9A series. My mouse
(the one not working under 2.6.0-*) is (according to 2.4.21-pre6) Logitech
USB-PS/2 Mouse. This mouse works under linux 2.4-series and Windows XP
flawlessly.
But under 2.6.0-series it doesnt work. More:
Aug 9 14:27:00 localhost kernel: drivers/usb/core/usb.c: registered new
driver hid
Aug 9 14:27:00 localhost kernel: drivers/usb/input/hid-core.c: v2.0:USB HID
core driver
Aug 9 14:27:00 localhost kernel: mice: PS/2 mouse device common for all mice
Aug 9 14:27:00 localhost kernel: hub 2-0:0: new USB device on port 1,
assigned address 2
Aug 9 14:27:00 localhost kernel: drivers/usb/host/uhci-hcd.c: d000:
suspend_hc
Aug 9 14:27:00 localhost kernel: drivers/usb/host/uhci-hcd.c: d400:
suspend_hc
Aug 9 14:27:02 localhost kernel: drivers/usb/core/message.c:
usb_control/bulk_msg: timeout
So it seems that it timeouts. I don't have a clue about USB kernel code, so I
really don't know where to go from here. I'm attaching the whole kernel log
where you can see all the verbose USB messages.
-rzei
Seems that all this was caused because of ACPI. With boot-time acpi=off, mouse
works.
-rzei
On Saturday 09 August 2003 17:08, Joonas Koivunen wrote:
> Seems that all this was caused because of ACPI. With boot-time acpi=off,
> mouse works.
I've got the same mainboard and the same problems...
It's not a problem with ACPI, it's more a problem with the interrupt routing
based on the ACPI tables. These tables seem to be not correctly implemented
in the BIOS and, as the german EPOX support admits, are not really tested. To
change this you may contact the EPOX support and describe your problems,
too....
If you want to use ACPI while this BIOS bug is not fixed you may use the
attached patch and boot with pci=noacpi. Without the patch this doesn't work
for me here...
Best regards
Thomas Schlichter
On Saturday 09 August 2003 19:02, Thomas Schlichter wrote:
> It's not a problem with ACPI, it's more a problem with the interrupt
> routing based on the ACPI tables. These tables seem to be not correctly
> implemented in the BIOS and, as the german EPOX support admits, are not
> really tested. To change this you may contact the EPOX support and describe
> your problems, too....
Thanks for letting me know.. I had a image of EPOX being pretty good with
motherboards.. Guess not then.
> If you want to use ACPI while this BIOS bug is not fixed you may use the
> attached patch and boot with pci=noacpi. Without the patch this doesn't
> work for me here...
Why isn't this patch in the mainstream kernel? There are many other
chipset/bios fixes in the kernel.. This would save many
reboot/recompilings/worries until or if ever epox does something with the
bios.
The patch works nicely. Though I did apply it manually to -test3 :) But it
works.
> Best regards
> Thomas Schlichter
Thanks again
-rzei
On Sunday 10 August 2003 01:24, Joonas Koivunen wrote:
> On Saturday 09 August 2003 19:02, Thomas Schlichter wrote:
~~ snip ~~
> > If you want to use ACPI while this BIOS bug is not fixed you may use the
> > attached patch and boot with pci=noacpi. Without the patch this doesn't
> > work for me here...
>
> Why isn't this patch in the mainstream kernel? There are many other
> chipset/bios fixes in the kernel.. This would save many
> reboot/recompilings/worries until or if ever epox does something with the
> bios.
Well, I didn't push it to Andrew or Linus yet, because it changes parts of the
semantics of 'pci=noacpi'. But currently I do think the changed way is more
correct, so perhaps Andrew may give it a try in the next -mm ??
If so, people who had problems with 'pci=noacpi' and use 'acpi=off' instead
should give it a try again...
> The patch works nicely. Though I did apply it manually to -test3 :) But it
> works.
I attached the patch again, now it also changes the indentation correctly and
simplifies the final setting of smp_found_config and the call of
clustered_apic_check(). It applies to 2.6.0-test3-mm1.
Best regards
Thomas Schlichter