[haiku-bugs] Re: [Haiku] #7498: [IO-APIC] KDL when booting

  • From: "mmlr" <trac@xxxxxxxxxxxx>
  • Date: Wed, 11 May 2011 22:22:15 -0000

#7498: [IO-APIC] KDL when booting
-----------------------------+----------------------------
   Reporter:  luroh          |      Owner:  mmlr
       Type:  bug            |     Status:  new
   Priority:  normal         |  Milestone:  R1
  Component:  System/Kernel  |    Version:  R1/Development
 Resolution:                 |   Keywords:
 Blocked By:                 |   Blocking:
Has a Patch:  0              |   Platform:  All
-----------------------------+----------------------------

Comment (by mmlr):

 Replying to [comment:23 anevilyak]:
 > Something looks very wrong while retrieving the routing table... the
 addresses should not all be 0xffff like that.

 Not really. The address field in this case denotes a bridge relative PCI
 device:function address. The 0xffff is a wildcard meaning "all functions".
 This is correct (and actually mandatory) because the devices aren't
 resolved by their function number but by their interrupt pin (multiple
 functions can match a single _PRT entry because functions can share
 interrupt pins). A single 0xffff just means device 0. Since there are many
 bridges involved in that setup (PCIe ports included) there are so many of
 those device 0 entries. The output looks a bit blown out of proportion of
 course, but that's just because of the enabled debug output.

 The resulting routing table that is actually put to use looks fine. So I'm
 starting to suspect some logic error on my side while implementing mutli
 IO-APIC support, as so far 2 of 2 such systems have failed like this where
 all the single IO-APIC configurations I was able to test worked just fine.

 The KDL isn't really surprising BTW. Since you're booting off a USB
 device, the inability to receive interrupts for USB resulting in
 addressing errors, makes the boot drive unavailable. While you'd get the
 same result (i.e. USB addressing failing) it would look different when
 booting from internal disks (and that is mostly just due to our ATA
 drivers really not giving up, recovering the lost interrupts, even though
 it's of course pretty hopeless in such a situation).

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

Other related posts: