New lead
As I already wrote the other -non-IP28 - systems I have available for testing are unaffected by the bad commits, so there must be some difference between them. Which is especially irritating because Indy and Indigo² are not so different actually. When comparing the kernel configuration files for IP22 and IP28 I found the difference: Like all other systems I have except for IP28, the IP22 kernel uses a "clock0" for the clock interrupts (the "and scheduling clock" in the "int0" line might be a remnant of an older code state or reflect that things are different for IP20 (also handled by IP22 kernel) as well, see further below):
from https://github.com/the-machine-hall/open...NERIC-IP22
...but the R10000 Indigo² does not:
from https://github.com/the-machine-hall/open...NERIC-IP28
...and instead uses "int0" for that. Originally both Indy and R10000 Indigo² used a "clock0" instead, but this was changed with:
from https://github.com/the-machine-hall/open...ebff13c665
...but soon after changed back for the Indy with:
from https://github.com/the-machine-hall/open...2f3335eac5
Hence I will "bring back a clock0" to IP28 as well and make adaptations as needed as I am unsure how to fix the 8254 related code to work correctly with the two commits from my last post. Afterwards only IP20 systems will use those timers instead of a "clock0", but as my R4000 Indigo is incomplete I can't test this anyhow.
As I already wrote the other -non-IP28 - systems I have available for testing are unaffected by the bad commits, so there must be some difference between them. Which is especially irritating because Indy and Indigo² are not so different actually. When comparing the kernel configuration files for IP22 and IP28 I found the difference: Like all other systems I have except for IP28, the IP22 kernel uses a "clock0" for the clock interrupts (the "and scheduling clock" in the "int0" line might be a remnant of an older code state or reflect that things are different for IP20 (also handled by IP22 kernel) as well, see further below):
Code:
[...]
#
# Definition of system
#
mainbus0 at root
cpu* at mainbus0
clock0 at mainbus0 # scheduling clock on Indy
int0 at mainbus0 # Interrupt Controller and scheduling clock
imc0 at mainbus0 # Memory Controller
gio0 at imc0
eisa0 at imc0
[...]
...but the R10000 Indigo² does not:
Code:
[...]
#
# Definition of system
#
mainbus0 at root
cpu* at mainbus0
int0 at mainbus0 # Interrupt Controller and scheduling clock
imc0 at mainbus0 # Memory Controller
gio0 at imc0
eisa0 at imc0
[...]
...and instead uses "int0" for that. Originally both Indy and R10000 Indigo² used a "clock0" instead, but this was changed with:
Code:
commit 64ac1c5a7e13fbe4130b9b53f956c4ebff13c665
Author: miod <miod@openbsd.org>
Date: Sat Jul 14 19:53:27 2012 +0000
A known errata of R4000 and R4400 processors, is that reading the internal
counter register close to a trigger of the counter interrupt, may cause the
interrupt not to be generated. This makes it a bad idea to use the internal
counter both for the scheduling clock and for delay().
Therefore, on IP22 systems (and IP28 because it makes my life easier), use
one of the two 8254 timers connected to the onboard interrupt controller as
the scheduling clock source.
Adapted from NetBSD.
...but soon after changed back for the Indy with:
Code:
commit 833ab59f79f5195f7dcd0b5b888b8d2f3335eac5
Author: miod <miod@openbsd.org>
Date: Wed Jul 18 19:56:02 2012 +0000
According to Linux, and just verified the hard way, the 8254 timer does not
interrupt on Indy; do not use it on such systems. Then, bring back a clock0 at
mainbus attachment to IP22 kernels, and attach it late in the autoconf process
if no other device has claimed the clock yet.
This means R4000 and R4400 based Indy may experience the lost clock interrupt
processor errata again, until a better way to skirt it is found.
Hence I will "bring back a clock0" to IP28 as well and make adaptations as needed as I am unsure how to fix the 8254 related code to work correctly with the two commits from my last post. Afterwards only IP20 systems will use those timers instead of a "clock0", but as my R4000 Indigo is incomplete I can't test this anyhow.