RPI3, serial consoles, gpio interrupts and -current

[Brad Spencer <brad%anduin.eldar.org@localhost>]

A couple of questions that I wanted to toss out...

Given a RPI3, model B and a -current from 2020-05-05..

1) It appears that if you try to use a full serial console, i.e. remove
fb=console from the cmdline.txt it appears that the baud rate of the
serial console floats with the processor speed.  That is, if you set
machdep.cpu.frequency.target to anything other than 600 the baud rate of
115200 isn't true any more.  This appears to happen with earmv6hf,
earmv7hf and ebarm64.  This is new behavior since 9.0... known problem??

2) Something is different with the ability to handle gpio interrupts, at
least when there are tons of them.  I have a interrupt source that can
feed to a gpio pin something like 150,000+ interrupts a second according
to vmstat -i.  With 9.0 and prior this was handled mostly just fine by a
RPI3.  With -current it appears as soon as the source is attached the
system locks up completely trying to deal with the number of gpio
interrupts.  You can test this pretty simply with the gpioirq
driver.. The gpio interrupts appear to dominate everything including
talking to the USB for network, and the serial console.  This is
different behavior since 9.0.  It is, of course, entirely possible the
gpioirq is doing something it should not, but I was wondering if anyone
may have some idea what this may be about.  Smaller numbers of interrupts
a second seem to be ok, but not large numbers.  This also happens with
earmv6hf, earmv7hf and evbarm64.



-- 
Brad Spencer - brad%anduin.eldar.org@localhost - KC8VKS - http://anduin.eldar.org