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

Karl Denninger karl at denninger.net
Mon Mar 25 17:19:11 UTC 2019


On 3/25/2019 12:09, Bernd Walter wrote:
> On Mon, Mar 25, 2019 at 06:05:35PM +0100, Bernd Walter wrote:
>> On Mon, Mar 25, 2019 at 10:52:26AM -0600, Ian Lepore wrote:
>>> On Mon, 2019-03-25 at 17:48 +0100, 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.
>>>>
>>> That's not a symptom of i2c comms failure, it's a symptom of a dead rtc
>>> battery.  The driver has to communicate with the rtc chip to determine
>>> that the oscillator was stopped.  After a reboot all is well, because
>>> the rtc oscillator gets started when the time is written to the chip,
>>> and it keeps running through a reboot and only stops on a power cycle.
>> Agreed, but there is a story behind.
>> The board had a design flaw in that it drained the battery over the
>> pullups into the Pi when the Pi was powered down.
>> I fixed that circuit and did power down tests as well.
>> Don't know if the previous boot was after power down, but it is
>> unlikely that the battery is dead again and if it was a power down then
>> it was a rather short one.
>> It is not a test system, I run it 24/7 as a local ntp server since about
>> only 1-2 months.
> Well - lets reveal another point.
> I have removed the pull ups completely, in the assumption that the Pi itself
> has propper pull ups for at least short wiring.
> It did work, so I left it that way.
> So it could indeed be transfer errors by inadequate pull ups causing it.
Not in my case - the board that was doing it, I power-cycled it and it
disappeared has NOTHING on any of the header/GPIO pins except for the
three wires connected to the USB/Serial interface for the console.
-- 
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/cf4906c9/attachment.bin>


More information about the freebsd-arm mailing list