[haiku-bugs] Re: [Haiku] #5551: ATI/AMD SB700/SB800/SBx00 USB Interrupt Issues

#5551: ATI/AMD SB700/SB800/SBx00 USB Interrupt Issues
--------------------------+------------------------------------------------
   Reporter:  MrSunshine  |      Owner:  mmlr
       Type:  bug         |     Status:  new
   Priority:  normal      |  Milestone:  R1
  Component:              |    Version:  R1/Development
  Drivers/USB             |   Keywords:  ati_via_dropped_interrupts
 Resolution:              |   Blocking:  6026, 6191, 6222, 6223, 6527, 7477
 Blocked By:              |   Platform:  All
Has a Patch:  1           |
--------------------------+------------------------------------------------

Comment (by mmlr):

 Replying to [comment:41 stargatefan]:
 > syslog.12 is with the attched patch from this ticket. Still no
 resolution on the high speed usb,

 You are still missing the ACPI module:

 {{{
 KERN: module: Search for bus_managers/acpi/v1 failed.
 KERN: acpi module not available, not configuring io-apics
 }}}

 If this is a general interrupt issue then it's really important to check
 if it'll work with IO-APICs. Please check what happened to your
 "/boot/system/add-ons/kernel/bus_managers/acpi" file. Is it missing or is
 it from an incompatible install?

 > added new log, this time I removed the  ohci driver, I was thinking the
 usb lines might be internally multiplexed inside the sb and by th elooks
 of the last log report in the last boot cycles that may very well be the
 case. So the question becomes, how to determine the adress changes.

 Not really sure what you're saying here. The USB lines as in the actual
 USB connector are obviously shared among the EHCI and companion host
 controller (OHCI in this case). They are routed to one or the other by
 means of EHCI config (that's what happens on "low-speed device connected,
 giving up port ownership"). It doesn't have an effect on this issue
 though. The problem is that interrupts from the EHCI controller don't
 arrive for whatever reason. This can be the controller being programmed
 incorrectly by the driver and therefore not generating interrupts at all,
 the controller being broken and needing a workaround or the interrupt
 routing being broken and not actually routing the interrupt to the legacy
 PIC or not at the vector indicated by the BIOS. If the latter then it's
 quite likely that using the IO-APIC would solve the issue, as then the
 legacy PIC routing wouldn't be used anymore.

 > hope this log sheds a bit of light. BTW no matter how you slice it, the
 linux patch doesn't work. Is there a linux usb driver for the 600/700
 chipsets that work ?

 You mean the patch attached here? Or you mean it doesn't work for you
 under linux either?

 > I also found this older ticket on a similar bsd issue especially with
 hubs.
 >
 > http://gnats.netbsd.org/40056

 Yes I know. That, and by extension the linux patches that are linked to,
 are the basis for the patch attached here. Some versions of these chipsets
 are simply broken (AMD errata documents the issues) and need such
 workarounds, however those are almost always edge cases. In the case of
 the attached patch it'd require multiple devices being plugged in and
 heavily used to trigger that issue at all. So the early error in
 initialization seen by most people in this ticket (and its duplicates)
 most certainly are just an interrupt generation or routing issue, not a
 well hidden chipset bug. That's why I'm so eager to check the situation
 with IO-APICs on.

-- 
Ticket URL: <http://dev.haiku-os.org/ticket/5551#comment:42>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.

Other related posts: