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

[Karl Denninger]

On 3/25/2019 12:05, Ian Lepore wrote:
> On Mon, 2019-03-25 at 11:58 -0500, Karl Denninger wrote:
>> 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.
>>
> Is the interrupt rate consistent from second to second?  Running
> 'vmstat 1' for a while might be useful to see that.  That many
> interrupts almost sounds like a line is floating, but if that were the
> case I'd expect a widely varying number of int/sec.
>
> If you build custom kernels, it might be helpful to apply r345475
> locally... it will display partial device names instead of just '+'
> when the name doesn't fit in the vmstat output.
>
> -- Ian

No, but it's in the same general range -- around 500k although it does
flop around some, and occasionally by a lot (e.g. if I sit and watch it
it'll occasionally put up VERY different numbers -- e.g. a ~730k number,
then it goes back, etc.)

I don't generally build custom kernels on these but I CAN put this into
the STABLE tree I'm building that from since I keep a separate one for
Crochet builds on these boxes.  Where do I find that specific delta?  (I
usually just svn things and I don't want to roll it all the way back to
there, right -- or do I?)

-- 
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/5ed0dac3/attachment.bin>