01:46 <Mutabah> Hmm... Anyone here had success with the IOAPIC on real hardware? I'm testing with the classic 16550 serial controller, and looks like none of the 120 IOAPIC lines on this machine is seeing the interrupt (same code works on qemu, but that doesn't mean much)

05:53 <araxestroy> I think the last time I experimented with the IOAPIC I ended up so frustrated I just gave up on it entirely and decided that anything that didn't support MSI/MSI-X would be serviced by cpu0

05:54 <araxestroy> it is a particularly obnoxious pile of half-assed solutions to a few problems

06:20 <geist> hmmm i've been meaning to really tackle it some day but havne't

08:51 <Mutabah> araxestroy: Acceptable workaround :)

09:09 <heat> Mutabah: yes

09:09 <heat> careful about the IRQ redirections... they can suddenly change irq numbers or polarity

09:10 <Mutabah> yeah, none of those seem to matter for the serial controller - and no IOAPIC register changes state when the serial "irq pending" flag is set

09:10 <heat> is it possible you're poking the wrong IO ports, or poking them wrongly?

09:10 <heat> how did you check if it's there? ACPI hopefully?

09:10 <Mutabah> yep.

09:11 <Mutabah> ACPI, and although there's funky things in the registers (claims a verison of 0x20), linux on the same machine agrees

09:11 <Mutabah> and since it's a register pair, either it's a different device with a similar interface - or it's the actual IOAPIC

09:12 <heat> does sending work _without_ IRQs?

09:13 <Mutabah> LAPIC timer works, haven't tried an IPI

09:13 <heat> i mean serial

09:13 <Mutabah> (or forcing an IOAPIC interrupt)

09:13 <Mutabah> Oh, it should. IRR changes on the controller

09:14 <heat> i'm inclined to believe you just don't drive this 16550 variant properly

09:14 <heat> unless you disable the IO APIC and somehow get magically working things :)

09:15 <Mutabah> Well, I'll try the PIC next time I'm near that machine

09:19 <Mutabah> More fun: The XHCI controller hard-locks the machine when it's enabled :)

09:20 <zid> enabled how?

09:20 <zid> proper full driver init?

09:20 <zid> did you remember to take back control from legacy usb?

09:21 <zid> there's a release command that you *really* wanna do before you fiddle the controller, else you'll be fighting your SMM code and possibly crashing/looping inside your firmware

09:23 <Mutabah> Might be that... hmm... upon starting the command engine, everything stops - even the LAPIC timer (... iirc)

09:24 <Mutabah> (Playing Pathfinder right now, but taking notes for when I get back to dev)

23:45 <Ameisen> So, based upon my reading of agner fog's stuff, x86 will generally assume that a forward branch is not taken when there is no prediction data. A Zen 3 chip like myself will statically first assume not taken, then taken, and then switch to branch prediction. However, it's ideal to have the 'not taken' branch be the hot path for purposes of instruction fetching and decoding

23:46 <zid> most backwards jumps are loops and thus expected to go 11110 and most forward jumps (or at least ones that aren't merely slightly backwards) tend to be if(!p) return;

23:46 <zid> and thus normally 0

23:46 <zid> so it makes sense how they've done it

23:47 <zid> (which is why I also said that hints aren't very important)

23:48 <zid> They work great *in place of* a branch predictor, but x86 has one