Opened 9 years ago

Closed 8 years ago

#6026 closed bug (duplicate)

no usb mass storage device with ASUS M2A-VM

Reported by: Matthias Owned by: mmlr
Priority: normal Milestone: R1
Component: Drivers/USB Version: R1/alpha2
Keywords: Cc:
Blocked By: #5551 Blocking:
Has a Patch: no Platform: All

Description

When I run Haiku R1/Alpha2 on my system with ASUS M2A-VM (AMD 690G chipset), then I cannot use any mass storage device. I tested with two card readers and one usb stick. The USB mouse is working without any problems. The interesting part in /var/log/syslog is:

KERN: usb hub 27: port 4: new device connected KERN: usb error control pipe 31: timeout waiting for queued request to complete Last message repeated 1 time KERN: usb error ehci -1: qtd (0x05eac080) error: 0x00080248 KERN: usb error control pipe 31: timeout waiting for queued request to complete KERN: usb error ehci -1: qtd (0x05eac280) error: 0x00080248 KERN: usb error ehci -1: error while setting device address KERN: usb error control pipe 31: timeout waiting for queued request to complete Last message repeated 1 time KERN: usb error ehci -1: KERN: qtd (0x05eac680) error: 0x00080248 KERN: usb error control pipe 31: timeout waiting for queued request to complete KERN: usb error ehci -1: qtd (0x05eac880) error: 0x00080248 KERN: usb error ehci -1: error while setting device address

If I want to boot from USB it does not work of course. The bootup hands stopping in the kernel debugger complaining about missing boot device.

The same USB hardware is successfully recognized and used by Haiku on my Thinkpad T61 with intel chipset.

Attached is the listusb -v with the hardware connected to port 4.

Attachments (2)

listusb (7.1 KB ) - added by Matthias 9 years ago.
listusb -v
syslog (100.9 KB ) - added by Matthias 9 years ago.

Download all attachments as: .zip

Change History (7)

by Matthias, 9 years ago

Attachment: listusb added

listusb -v

comment:1 by mmlr, 9 years ago

Sounds like no interrupts are received. The mouse is likely just working because it is a low speed device and uses a different controller therefore. You could check the ints output in KDL which'd confirm that. In the end though it'd be another issue with interrupt routing though. You could try disabling ACPI and see if that makes it work, if so then it's another victim of missing IO-APIC support.

comment:2 by Matthias, 9 years ago

Disabling ACPI doesn't help. Disabling ACPI, IO-APIC, LOCAL APIC, APM, SMP doesn't help. I attach the syslog file.

by Matthias, 9 years ago

Attachment: syslog added

comment:3 by Matthias, 9 years ago

Has a Patch: set

comment:4 by stippi, 9 years ago

Has a Patch: unset

comment:5 by mmlr, 8 years ago

Blocked By: 5551 added
Resolution: duplicate
Status: newclosed

It's a SB600 chipset and therefore a duplicate of #5551.

Note: See TracTickets for help on using tickets.