PS/2 IRQ not firing + spurious IRQ (real hardware)

[Magyar57]

I was thinking of the APIC implementation, and then I thought: isn't the i8259 PIC on the CPU die on modern processors (just like the APIC) ?
If it's the case, how could there be a bug in the PIC ? Intel/ADM would reuse their old design for this part of the dies, and that's it (so old circuitry which is well tested, no bug in sight)...

[Octocontrabass]

isn't the i8259 PIC on the CPU die on modern processors (just like the APIC) ?

It might be. You can try checking your CPU's datasheet.

If it's the case, how could there be a bug in the PIC ?

Who would notice a bug in the PIC? Modern OSes don't use it, they have APIC.

[Magyar57]

It might be. You can try checking your CPU's datasheet.

I've tried numerous times, but every time I just end up with the poor Intel or AMD marketing pdf with stuff like number of cores, frequency and that's it. Do you know where to find it ? (say, for the r7 7840hs)

Who would notice a bug in the PIC? Modern OSes don't use it, they have APIC.

What I meant is, it has been well used and tested back in the days, and now since it's not used anymore (but for backward compatibility), they have no reasons to change the circuit and therefore introduce bugs: "if it works, don't touch it"

[nullplan]

What I meant is, it has been well used and tested back in the days, and now since it's not used anymore (but for backward compatibility), they have no reasons to change the circuit and therefore introduce bugs: "if it works, don't touch it"

Possibly, but the system design might have introduced a regression somewhere, or maybe the thing is wired up wrong internally, and that wouldn't be noticed.

[Octocontrabass]

(say, for the r7 7840hs)

Processor Programming Reference (PPR) for AMD Family 19h Model 70h, Revision A0 Processors

[Magyar57]

Sorry I missed you message, thank you ! How did you find this ?
Btw I'm working on the APIC, but I need to setup paging first to read some memory address, so it will take a while x)

[Octocontrabass]

How did you find this ?

I searched the AMD documentation hub for your CPU's family and model.

[Magyar57]

Hi. It's been a long time ! I implemented a lot of stuff, including APIC & IOAPIC drivers.
Sadly, it didn't solve my problem, everything is just like before.

I'll make a summary of my setup here:
- Mask ISA IRQ 1 and 12 in the APIC (keyboard & mouse)
- Initialize the 8042 PS/2 controller by using polling (using simple counter timeout):
• disable both ports
• flush output buffer
• setup controller configuration byte
• test presence of port 2 by enabling it, and disabling it again
• perform ports self test
• re-enable ports
• enable devices IRQ in the config byte
- Setup irq handler for PS/2 mouse & keyboard IRQs
- Unmask said IRQs
- Flush any data (there's none)
- Test PS/2 keyboard
• Send 'disable scanning' command
• No IRQ fires, timeout reached, initialization fails

I tried some stuff as debugging. (Note that this is NOT supposed to be the actual final code, just debug checks !) Here's what I learned:
- Added a check for PS/2 controller status register's "output buffer full" bit set in my timer IRQ ; this highlighted that the keyboard responds to the scanning command during my timeout loop ! but the keyboard IRQ doesn't fire
- If I read the output buffer when it's full (polling), THEN NOW the IRQ fires, after the buffer is emptied (???)
- If I use the byte I got by polling, it 'works', until there are several bytes of response, things get out of order and fail (as it should). This highlights that the "irq firing after the data has been read" goes on and on
- I went back to using polling (I know @Octocontrabass said I should use IRQs), and initialization fails, one byte seems to disappear in the void somehow ; plus, IRQs still don't fire afterwards

What could be wrong in my setup ?

[Octocontrabass]

- If I read the output buffer when it's full (polling), THEN NOW the IRQ fires, after the buffer is emptied (???)

Did you program the IOAPIC with the correct polarity and trigger mode?

one byte seems to disappear in the void somehow

Did you initialize the USB HCIs? USB legacy support can interfere with PS/2. It might also be misbehaving because you're not supposed to poll, or maybe just a bug in your code, though I'm not sure why you would lose only one byte in those cases.

[Magyar57]

Did you program the IOAPIC with the correct polarity and trigger mode?

Yes, afaik. I'm getting exactly the same behaviour whatever IRQ chip I'm using (PIC or APIC)

Did you initialize the USB HCIs? USB legacy support can interfere with PS/2. It might also be misbehaving because you're not supposed to poll, or maybe just a bug in your code, though I'm not sure why you would lose only one byte in those cases.

I did not touch USB. If I'm being honest, I don't plan to, I'd rather not bother implementing this hell. I'm getting my buggy behaviour exactly the same way on two machines, one Intel cpu, one AMD ; I reckon it means that my bug is not a problem with USB (?)

As I said, if I don't poll at all (which is what I do on the commit code, cause that's what you told me to do), and only use IRQs, just nothing happens (the first irq never fires, timeout, and that's it)

I'm guessing it's 'just' a bug in my code, but I've been searching it for literal weeks now. Maybe I'm getting the "polling" thing wrong: what is considered polling ? Only reading from the data port, or is reading the status register already considered polling ?

[Octocontrabass]

Yes, afaik. I'm getting exactly the same behaviour whatever IRQ chip I'm using (PIC or APIC)

Which polarity and trigger mode? Is there an interrupt source override in the MADT?

I did not touch USB. If I'm being honest, I don't plan to, I'd rather not bother implementing this hell.

I'm not sure you can properly initialize PS/2 without touching USB. Does the keyboard work properly if you don't initialize the PS/2 controller at all? Just flush the output buffer, enable IRQ1, and move on to whatever keyboard initialization you like.

I'm getting my buggy behaviour exactly the same way on two machines, one Intel cpu, one AMD ; I reckon it means that my bug is not a problem with USB (?)

It could still be a problem with USB if both machines have the same buggy USB legacy support module from the same BIOS vendor.

Maybe I'm getting the "polling" thing wrong: what is considered polling ? Only reading from the data port, or is reading the status register already considered polling ?

Polling is when you have a loop that reads the status register waiting for it to change. Like this.

[sandras]

Octocontrabass, I'm curious, is the OS you've linked to your own?

[Magyar57]

Octocontrabass, I'm curious, is the OS you've linked to your own?

No it's mine

Which polarity and trigger mode? Is there an interrupt source override in the MADT?

Yes there are 2 overrides iirc. Default polarity is high (0) and default trigger mode is edge (0). For the overrides I use the MADT-provided configuration

I'm not sure you can properly initialize PS/2 without touching USB. Does the keyboard work properly if you don't initialize the PS/2 controller at all? Just flush the output buffer, enable IRQ1, and move on to whatever keyboard initialization you like.

I think I tried this already, but I don't remember. I'll test again when I have a little time

Polling is when you have a loop that reads the status register waiting for it to change. Like this.

Yeah, I changed this without committing (removed the waitUntilBitValueOrTimeout call). That's what I mean when I say I don't use polling.
However, I think it's wrong not to wait for input buffer empty before sending command, is it ? Is it considered polling, and what's the best way of sending commands (for initializing PS/2 devices), with or without the wait loop ?

[sandras]

Octocontrabass, I'm curious, is the OS you've linked to your own?

No it's mine

Well, I can not pinpoint what I liked, but I can say that to me the code seems overall well written. Something to learn from. I did try v0.2-tetris, too.

Anyway, I'll try not to hijack the thread and shut up now. : )

[Magyar57]

Thank you sandras, that's genuinely heartwarming and motivating to read !

I'm not sure you can properly initialize PS/2 without touching USB. Does the keyboard work properly if you don't initialize the PS/2 controller at all? Just flush the output buffer, enable IRQ1, and move on to whatever keyboard initialization you like.

I think I tried this already, but I don't remember. I'll test again when I have a little time

I can confirm, it get the same behaviour as previously

However, I think it's wrong not to wait for input buffer empty before sending command, is it ? Is it considered polling, and what's the best way of sending commands (for initializing PS/2 devices), with or without the wait loop ?

I'll reiterate that question

What could I try ? Try to write a USB stub to deactivate the controller.s that might get in the way ? (I really don't want to end up like i did with the APIC, write tons of stuff for in the end figuring out that the problem is still here and taunting me)