[johnnym]

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):

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
[...]

from https://github.com/the-machine-hall/open...NERIC-IP22

...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
[...]

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:

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.

from https://github.com/the-machine-hall/open...ebff13c665

...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.

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.