Options for FBSD support with LCD device - new project [[Maybe related: I2c issues on the Pi2]]

[Karl Denninger]

On 3/25/2019 11:48, Bernd Walter wrote:
> On Mon, Mar 25, 2019 at 11:33:32AM -0500, Karl Denninger wrote:
>>> What do you mean by an insane rate?  It's normal for the usb controller
>>> to be showing around thousands of int/sec.  Despite what seems like a
>>> high rate, even on an on rpi-b it uses under 2% cpu to service that.
>>>
>>> root at rpi:~ # vmstat -i
>>> interrupt                        total       rate
>>> intc0,2: vchiq0                      2          0
>>> intc0,11: systimer0           10103206       1110
>>> intc0,17:-x_dwcotg0          218596055      24007
>>> intc0,28: bcm_dma0                 834          0
>>> intc0,61: iichb0                  5778          1
>>> intc0,65: uart0                   1817          0
>>> intc0,70:-dhci_bcm0                172          0
>>> Total                        228707864      25118
>>>
>>> -- Ian
>> The story gets more odd.
>>
>> The same *physical* unit that I saw this on last night with no I2c
>> device connected I restarted this morning -- changing NOTHING -- and it
>> disappeared.
>>
>> But -- on another unit it's still there (I haven't shut down, pulled
>> power and restarted that one.)
>>
>> vmstat -i on both doesn't show anything all that odd:
>> misbehaving that's not there, and neither are the missed interrupt
>> complaints.
>>
>> But again, last night the one that this morning is NOT misbehaving WAS,
>> and was showing the exact same thing.
>>
>> So this looks like something that is not being initialized property at
>> boot time, and sometimes however it comes up causes trouble, and other
>> times it does not -- which is likely to make it a "lot" of fun to find.
> By causing trouble - do you mean it doesn't work?
> I noticed that my system has this message:
> nxprtc0: RTC clock not running
> Warning: bad time from time-of-day clock, system time will not be set accurately
> This shouldn't happen, but I wonder if the iic communication works at all.
> I likely wouldn't notice if the rtc failed.
> Maybe there was an initial problem at start as you said.
> Will reboot it and see what happens.
> After a reboot the message about the rtc is gone.
> Have to wait at least a day to see if the Spurious are gone too.

In both cases on my boxes everything is working, but that's not
unexpected because of the way my code works (it dynamically detects a
change in configuration in that if it tries to open the I2c bus when
there's a configuration file for devices on it, and it fails, it will
try again in a few seconds -- and if you remove the config then it will
shut down the I/O path in a short while and stop.)

On the units that exhibit the problem the load average is 1.0 + whatever
is real *and* the crazy interrupt rate is present.  On the ones that are
not neither is the case; the native and real load average is present and
the interrupt rate is normal.

In the case of the unit that the problem showed up on and then
disappeared, however, while there's an I2c config defined there's no
device connected to it on my bench.

But I suspect this is something banging the interrupts on the CPU that
is not attached to anything in the code, and the reason I suspect that
is that on a given boot it either happens or not, and if it does then
nothing I can do will make it stop -- and likewise, nothing I can do
will make it start if it doesn't on boot.  That implies that whatever it
is it's not code-specific nor .ko-loaded specific either, in that if it
was related specifically to an I2c device being talked to actively then
when I killed the code that was using I2c or booted without the device
connected (or never started the code that attempted to probe the bus and
attach to the device in question) it wouldn't do it at all -- but that's
not true.

The one that stopped doing it I then attached both an I2c device that it
was looking for and also connected a "modem-style" device (which caused
umodem.ko to autoload, as expected) and it came up as well, without a
problem -- and without triggering the mad interrupt storm.

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20190325/f9c5e2e0/attachment.bin>