Options for FBSD support with LCD device - new project

classic Classic list List threaded Threaded
67 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

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

Karl Denninger
On 3/19/2019 09:26, Jedi Tek'Unum wrote:

> On Mar 18, 2019, at 2:57 PM, Ian Lepore <[hidden email]> wrote:
>> On Mon, 2019-03-18 at 14:51 -0500, Jedi Tek'Unum wrote:
>>> My impression wasn’t that support wasn’t there - but “out of the box”
>>> configuration wasn’t there. In comparison, I didn’t have to do
>>> anything to get I2C enabled in the binary distribution of Linux that
>>> comes through the manufacturer.
>>>
>>> Its the enabling part that isn’t obvious to most people IMO.
>>>
>>> Documentation/wiki is great. But even better would be all the
>>> enabling overlays already in place and the entries in loader.conf
>>> already there and commented out. It would be so much easier to go to
>>> a “common place” (loader.conf), skim through the notes, find the
>>> thing that one wants, and then just uncomment the referenced line!
>>> (Or any other similarly easy method.)
>>>
>>>
>>> For FBSD to get a better foothold in this space it needs to be better
>>> documented. For example, the wiki for NEO2 <
>>> http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO2> is a step-by-
>>> step guide for how to acquire and configure Linux for it.
>>>
>>>
>> On one of my imx6 boards I have 5 SPI devices.  Each device can use 3
>> or 4 different sets of pins for clock, data-in, and data-out.  Plus,
>> each can use literally any number of whatever gpio pins they want as
>> chip selects.  Even limiting the chipsels to a handfull, there would
>> literally be thousands of possible combinations of devices and pin
>> configurations, each one needing to be a separate overlay.
>>
>> Maybe you have experience primarily with rpi or some similarly crippled
>> devices that only offer one or two choices?
> If memory serves correctly, there are only 2 I2C devices on the H3/H5 and the NanoPi NEO/2 implementations only externalize 1. There is only 1 SPI AFAIK.
>
> I wouldn’t call that crippled. I chose this platform exactly because of its characteristics - small, fast, cheap. It fits the project I’m using it for perfectly. In fact, I can see uses for even smaller (see Giant Board <https://groboards.com/giant-board/>). I understand other projects may have different requirements and would drive one towards different solutions - and require more of the various interfaces. But they aren’t going to be typical of hobbyist projects.
>
> Maybe I should pose the question in another way. What is the philosophy for choosing GPIO as default for all the pins? These boards have a very limited number of pins and my preference would be that the broadest range of interface types would be the default. There are 2 UARTs exposed so I would have picked 1 to be enabled by default. After that, with I2C and SPI enabled, there are still 6 GPIO available. For a tiny board like this that seems to be reasonable. If people have a need for slightly more GPIO then I would expect they would be the ones configuring overlays.
>
> Apparently the developers of the Linux packages for these boards have chosen the diverse approach (“FriendlyCore” based on UbuntuCore Xenial).
>
> IMHO, most “hobbyists” would prefer the diversity approach. I’m completely capable of becoming an expert in FBSD and this sort of configuration stuff yet it isn’t a priority for me - I just want to use it like any other hobbyist. The way things are now pushes this type of user away from FBSD.
>
> If there is some philosophical perspective against the diversity approach then the next best thing is to have documentation that clearly and simply tells people how to enable the other functionality.
>
> Finally, I think there is an opportunity to grow FBSD in the hobbyist world of these small products. We are past the point where people can have a real operating system running on systems at Arduino size and cost. Linux has been aggressively deployed there but I can say from experience that it ain’t pretty - I won’t say more as everyone reading this has a clear understanding of why that is.
I'm currently working an issue similar to this, but one that rates
"highly annoying" right now rather than "catastrophically bad."

The environment is a RPI2 which has GPIO and I2c configured; GPIO to
drive outputs, I2c is used to read analog channels.

On 11.0 this code ran perfectly well.

On 12-STABLE )FreeBSD 12.0-STABLE r344818 GENERIC)
 it also runs well *BUT* generates a huge number of console messages
about spurious interrupts:

intc0: Spurious interrupt detected
local_intc0: Spurious interrupt detected
intc0: Spurious interrupt detected
intc0: Spurious interrupt detected
local_intc0: Spurious interrupt detected
local_intc0: Spurious interrupt detected

....

The issue is coming from the i2c side as I have another one of these
that has no I2c defined in the configuration (but is running identical
code) and no messages.

Something is indeed generating an /insane /number of interrupts on one
of the channels:

Interrupts
530k total
 1159 local_intc
494k local_intc
 8047 local_intc

For obvious reasons I'd like to track this down (it's also generating a
load average of 1.0, where it should be 0.1 or thereabouts) but I'm not
sure where to start looking.

config.txt looks like this:

root@Pool-MCP:/mnt # cat config.txt
init_uart_clock=3000000
enable_uart=1
kernel=u-boot.bin
kernel7=u-boot.bin
dtoverlay=mmc
#audio_pwm_mode=2
dtparam=i2c_arm=on

The only "change" from what is in the default is the i2c_arm=on line.

The "something" appears to be the i2c code, *or* it's something that's
gone wrong in the DTS changes that are in the newer way of building the
boot area (where the grab is of the "standard" versions from ports and
then just copied over.)

I suspect this would bite you equally hard if you had a RTC configured
on I2c as well.....

Killing the process that has the I2c interface open (so the I2c
interface is not in active use, but is configured of course) does *not*
stop the insane interrupt storm.

--
Karl Denninger
[hidden email] <mailto:[hidden email]>
/The Market Ticker/
/[S/MIME encrypted email preferred]/

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Bernd Walter-4
On Tue, Mar 19, 2019 at 09:55:12AM -0500, Karl Denninger wrote:

> On 3/19/2019 09:26, Jedi Tek'Unum wrote:
> > On Mar 18, 2019, at 2:57 PM, Ian Lepore <[hidden email]> wrote:
> >> On Mon, 2019-03-18 at 14:51 -0500, Jedi Tek'Unum wrote:
> >>> My impression wasn???t that support wasn???t there - but ???out of the box???
> >>> configuration wasn???t there. In comparison, I didn???t have to do
> >>> anything to get I2C enabled in the binary distribution of Linux that
> >>> comes through the manufacturer.
> >>>
> >>> Its the enabling part that isn???t obvious to most people IMO.
> >>>
> >>> Documentation/wiki is great. But even better would be all the
> >>> enabling overlays already in place and the entries in loader.conf
> >>> already there and commented out. It would be so much easier to go to
> >>> a ???common place??? (loader.conf), skim through the notes, find the
> >>> thing that one wants, and then just uncomment the referenced line!
> >>> (Or any other similarly easy method.)
> >>>
> >>>
> >>> For FBSD to get a better foothold in this space it needs to be better
> >>> documented. For example, the wiki for NEO2 <
> >>> http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO2> is a step-by-
> >>> step guide for how to acquire and configure Linux for it.
> >>>
> >>>
> >> On one of my imx6 boards I have 5 SPI devices.  Each device can use 3
> >> or 4 different sets of pins for clock, data-in, and data-out.  Plus,
> >> each can use literally any number of whatever gpio pins they want as
> >> chip selects.  Even limiting the chipsels to a handfull, there would
> >> literally be thousands of possible combinations of devices and pin
> >> configurations, each one needing to be a separate overlay.
> >>
> >> Maybe you have experience primarily with rpi or some similarly crippled
> >> devices that only offer one or two choices?
> > If memory serves correctly, there are only 2 I2C devices on the H3/H5 and the NanoPi NEO/2 implementations only externalize 1. There is only 1 SPI AFAIK.
> >
> > I wouldn???t call that crippled. I chose this platform exactly because of its characteristics - small, fast, cheap. It fits the project I???m using it for perfectly. In fact, I can see uses for even smaller (see Giant Board <https://groboards.com/giant-board/>). I understand other projects may have different requirements and would drive one towards different solutions - and require more of the various interfaces. But they aren???t going to be typical of hobbyist projects.
> >
> > Maybe I should pose the question in another way. What is the philosophy for choosing GPIO as default for all the pins? These boards have a very limited number of pins and my preference would be that the broadest range of interface types would be the default. There are 2 UARTs exposed so I would have picked 1 to be enabled by default. After that, with I2C and SPI enabled, there are still 6 GPIO available. For a tiny board like this that seems to be reasonable. If people have a need for slightly more GPIO then I would expect they would be the ones configuring overlays.
> >
> > Apparently the developers of the Linux packages for these boards have chosen the diverse approach (???FriendlyCore??? based on UbuntuCore Xenial).
> >
> > IMHO, most ???hobbyists??? would prefer the diversity approach. I???m completely capable of becoming an expert in FBSD and this sort of configuration stuff yet it isn???t a priority for me - I just want to use it like any other hobbyist. The way things are now pushes this type of user away from FBSD.
> >
> > If there is some philosophical perspective against the diversity approach then the next best thing is to have documentation that clearly and simply tells people how to enable the other functionality.
> >
> > Finally, I think there is an opportunity to grow FBSD in the hobbyist world of these small products. We are past the point where people can have a real operating system running on systems at Arduino size and cost. Linux has been aggressively deployed there but I can say from experience that it ain???t pretty - I won???t say more as everyone reading this has a clear understanding of why that is.
>
> I'm currently working an issue similar to this, but one that rates
> "highly annoying" right now rather than "catastrophically bad."
>
> The environment is a RPI2 which has GPIO and I2c configured; GPIO to
> drive outputs, I2c is used to read analog channels.
>
> On 11.0 this code ran perfectly well.
>
> On 12-STABLE )FreeBSD 12.0-STABLE r344818 GENERIC)
>  it also runs well *BUT* generates a huge number of console messages
> about spurious interrupts:
>
> intc0: Spurious interrupt detected
> local_intc0: Spurious interrupt detected
> intc0: Spurious interrupt detected
> intc0: Spurious interrupt detected
> local_intc0: Spurious interrupt detected
> local_intc0: Spurious interrupt detected
>
> ....
>
> The issue is coming from the i2c side as I have another one of these
> that has no I2c defined in the configuration (but is running identical
> code) and no messages.

Interesting.
A local Pi1 running 12-RELEASE has the same messages:
intc0: Spurious interrupt detected
intc0: Spurious interrupt detected
intc0: Spurious interrupt detected
intc0: Spurious interrupt detected
intc0: Spurious interrupt detected
intc0: Spurious interrupt detected
intc0: Spurious interrupt detected
I have an I2C RTC on this machine.

--
B.Walter <[hidden email]> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Options for FBSD support with LCD device - new project

Ian Lepore-3
In reply to this post by Jedi Tek'Unum-2
On Tue, 2019-03-19 at 09:26 -0500, Jedi Tek'Unum wrote:

> On Mar 18, 2019, at 2:57 PM, Ian Lepore <[hidden email]> wrote:
> >
> > On Mon, 2019-03-18 at 14:51 -0500, Jedi Tek'Unum wrote:
> > > My impression wasn’t that support wasn’t there - but “out of the
> > > box”
> > > configuration wasn’t there. In comparison, I didn’t have to do
> > > anything to get I2C enabled in the binary distribution of Linux
> > > that
> > > comes through the manufacturer.
> > >
> > > Its the enabling part that isn’t obvious to most people IMO.
> > >
> > > Documentation/wiki is great. But even better would be all the
> > > enabling overlays already in place and the entries in loader.conf
> > > already there and commented out. It would be so much easier to go
> > > to
> > > a “common place” (loader.conf), skim through the notes, find the
> > > thing that one wants, and then just uncomment the referenced
> > > line!
> > > (Or any other similarly easy method.)
> > >
> > >
> > > For FBSD to get a better foothold in this space it needs to be
> > > better
> > > documented. For example, the wiki for NEO2 <
> > > http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO2>; is a
> > > step-by-
> > > step guide for how to acquire and configure Linux for it.
> > >
> > >
> >
> > On one of my imx6 boards I have 5 SPI devices.  Each device can use
> > 3
> > or 4 different sets of pins for clock, data-in, and data-
> > out.  Plus,
> > each can use literally any number of whatever gpio pins they want
> > as
> > chip selects.  Even limiting the chipsels to a handfull, there
> > would
> > literally be thousands of possible combinations of devices and pin
> > configurations, each one needing to be a separate overlay.
> >
> > Maybe you have experience primarily with rpi or some similarly
> > crippled
> > devices that only offer one or two choices?
>
> If memory serves correctly, there are only 2 I2C devices on the H3/H5
> and the NanoPi NEO/2 implementations only externalize 1. There is
> only 1 SPI AFAIK.
>
> I wouldn’t call that crippled. I chose this platform exactly because
> of its characteristics - small, fast, cheap. It fits the project I’m
> using it for perfectly. In fact, I can see uses for even smaller (see
> Giant Board <https://groboards.com/giant-board/>). I understand other
> projects may have different requirements and would drive one towards
> different solutions - and require more of the various interfaces. But
> they aren’t going to be typical of hobbyist projects.
>
> Maybe I should pose the question in another way. What is the
> philosophy for choosing GPIO as default for all the pins? These
> boards have a very limited number of pins and my preference would be
> that the broadest range of interface types would be the default.
> There are 2 UARTs exposed so I would have picked 1 to be enabled by
> default. After that, with I2C and SPI enabled, there are still 6 GPIO
> available. For a tiny board like this that seems to be reasonable. If
> people have a need for slightly more GPIO then I would expect they
> would be the ones configuring overlays.
>
> Apparently the developers of the Linux packages for these boards have
> chosen the diverse approach (“FriendlyCore” based on UbuntuCore
> Xenial).
>
> IMHO, most “hobbyists” would prefer the diversity approach. I’m
> completely capable of becoming an expert in FBSD and this sort of
> configuration stuff yet it isn’t a priority for me - I just want to
> use it like any other hobbyist. The way things are now pushes this
> type of user away from FBSD.
>
> If there is some philosophical perspective against the diversity
> approach then the next best thing is to have documentation that
> clearly and simply tells people how to enable the other
> functionality.
>
> Finally, I think there is an opportunity to grow FBSD in the hobbyist
> world of these small products. We are past the point where people can
> have a real operating system running on systems at Arduino size and
> cost. Linux has been aggressively deployed there but I can say from
> experience that it ain’t pretty - I won’t say more as everyone
> reading this has a clear understanding of why that is.
>

The default pin assignments in the dts are completely controlled by
linux, and I think effectively by the actual board vendors who create
the dts and submit it to linux.  We (freebsd) are just a consumer of
the dts info, we have to work with whatever they shove down our
throats, and continually re-adapt ourselves whenever they change their
minds and make arbitrary incompatible changes from one release to the
next (which they definitely do).

-- Ian

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Ian Lepore-3
In reply to this post by Karl Denninger
On Tue, 2019-03-19 at 09:55 -0500, Karl Denninger wrote:

> On 3/19/2019 09:26, Jedi Tek'Unum wrote:
> > On Mar 18, 2019, at 2:57 PM, Ian Lepore <[hidden email]> wrote:
> > > On Mon, 2019-03-18 at 14:51 -0500, Jedi Tek'Unum wrote:
> > > > My impression wasn’t that support wasn’t there - but “out of
> > > > the box”
> > > > configuration wasn’t there. In comparison, I didn’t have to do
> > > > anything to get I2C enabled in the binary distribution of Linux
> > > > that
> > > > comes through the manufacturer.
> > > >
> > > > Its the enabling part that isn’t obvious to most people IMO.
> > > >
> > > > Documentation/wiki is great. But even better would be all the
> > > > enabling overlays already in place and the entries in
> > > > loader.conf
> > > > already there and commented out. It would be so much easier to
> > > > go to
> > > > a “common place” (loader.conf), skim through the notes, find
> > > > the
> > > > thing that one wants, and then just uncomment the referenced
> > > > line!
> > > > (Or any other similarly easy method.)
> > > >
> > > >
> > > > For FBSD to get a better foothold in this space it needs to be
> > > > better
> > > > documented. For example, the wiki for NEO2 <
> > > > http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO2>; is a
> > > > step-by-
> > > > step guide for how to acquire and configure Linux for it.
> > > >
> > > >
> > >
> > > On one of my imx6 boards I have 5 SPI devices.  Each device can
> > > use 3
> > > or 4 different sets of pins for clock, data-in, and data-
> > > out.  Plus,
> > > each can use literally any number of whatever gpio pins they want
> > > as
> > > chip selects.  Even limiting the chipsels to a handfull, there
> > > would
> > > literally be thousands of possible combinations of devices and
> > > pin
> > > configurations, each one needing to be a separate overlay.
> > >
> > > Maybe you have experience primarily with rpi or some similarly
> > > crippled
> > > devices that only offer one or two choices?
> >
> > If memory serves correctly, there are only 2 I2C devices on the
> > H3/H5 and the NanoPi NEO/2 implementations only externalize 1.
> > There is only 1 SPI AFAIK.
> >
> > I wouldn’t call that crippled. I chose this platform exactly
> > because of its characteristics - small, fast, cheap. It fits the
> > project I’m using it for perfectly. In fact, I can see uses for
> > even smaller (see Giant Board <https://groboards.com/giant-board/>)
> > . I understand other projects may have different requirements and
> > would drive one towards different solutions - and require more of
> > the various interfaces. But they aren’t going to be typical of
> > hobbyist projects.
> >
> > Maybe I should pose the question in another way. What is the
> > philosophy for choosing GPIO as default for all the pins? These
> > boards have a very limited number of pins and my preference would
> > be that the broadest range of interface types would be the default.
> > There are 2 UARTs exposed so I would have picked 1 to be enabled by
> > default. After that, with I2C and SPI enabled, there are still 6
> > GPIO available. For a tiny board like this that seems to be
> > reasonable. If people have a need for slightly more GPIO then I
> > would expect they would be the ones configuring overlays.
> >
> > Apparently the developers of the Linux packages for these boards
> > have chosen the diverse approach (“FriendlyCore” based on
> > UbuntuCore Xenial).
> >
> > IMHO, most “hobbyists” would prefer the diversity approach. I’m
> > completely capable of becoming an expert in FBSD and this sort of
> > configuration stuff yet it isn’t a priority for me - I just want to
> > use it like any other hobbyist. The way things are now pushes this
> > type of user away from FBSD.
> >
> > If there is some philosophical perspective against the diversity
> > approach then the next best thing is to have documentation that
> > clearly and simply tells people how to enable the other
> > functionality.
> >
> > Finally, I think there is an opportunity to grow FBSD in the
> > hobbyist world of these small products. We are past the point where
> > people can have a real operating system running on systems at
> > Arduino size and cost. Linux has been aggressively deployed there
> > but I can say from experience that it ain’t pretty - I won’t say
> > more as everyone reading this has a clear understanding of why that
> > is.
>
> I'm currently working an issue similar to this, but one that rates
> "highly annoying" right now rather than "catastrophically bad."
>
> The environment is a RPI2 which has GPIO and I2c configured; GPIO to
> drive outputs, I2c is used to read analog channels.
>
> On 11.0 this code ran perfectly well.
>
> On 12-STABLE )FreeBSD 12.0-STABLE r344818 GENERIC)
>  it also runs well *BUT* generates a huge number of console messages
> about spurious interrupts:
>
> intc0: Spurious interrupt detected
> local_intc0: Spurious interrupt detected
> intc0: Spurious interrupt detected
> intc0: Spurious interrupt detected
> local_intc0: Spurious interrupt detected
> local_intc0: Spurious interrupt detected
>
> ....
>
> The issue is coming from the i2c side as I have another one of these
> that has no I2c defined in the configuration (but is running
> identical
> code) and no messages.
>
> Something is indeed generating an /insane /number of interrupts on
> one
> of the channels:
>
> Interrupts
> 530k total
>  1159 local_intc
> 494k local_intc
>  8047 local_intc
>
> For obvious reasons I'd like to track this down (it's also generating
> a
> load average of 1.0, where it should be 0.1 or thereabouts) but I'm
> not
> sure where to start looking.
>
> config.txt looks like this:
>
> root@Pool-MCP:/mnt # cat config.txt
> init_uart_clock=3000000
> enable_uart=1
> kernel=u-boot.bin
> kernel7=u-boot.bin
> dtoverlay=mmc
> #audio_pwm_mode=2
> dtparam=i2c_arm=on
>
> The only "change" from what is in the default is the i2c_arm=on line.
>
> The "something" appears to be the i2c code, *or* it's something
> that's
> gone wrong in the DTS changes that are in the newer way of building
> the
> boot area (where the grab is of the "standard" versions from ports
> and
> then just copied over.)
>
> I suspect this would bite you equally hard if you had a RTC
> configured
> on I2c as well.....
>
> Killing the process that has the I2c interface open (so the I2c
> interface is not in active use, but is configured of course) does
> *not*
> stop the insane interrupt storm.
>

I'm aware of this (haven't forgotten that you reported it), but I
haven't had time to look into it, because of a crazy $work schedule
right now.  I did some work on the rpi i2c driver last year, so there's
a chance I caused this problem.  I only have an ancient rpi-b to test
with, I wonder if this is a problem that only happens on rpi2 models?

-- Ian

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: allwinner i2c [was: Options for FBSD support with LCD device - new project]

Ian Lepore-3
In reply to this post by Daniel Braniss-2
On Tue, 2019-03-19 at 08:28 +0200, Daniel Braniss wrote:
> I have several allwinner SoC, mainly from FriendlyArm, and neither i2c or SPI work.
> I have a hacked i2c that mostly works, but hangs sometimes :-), mainly
> timing issues of which I have no idea how to fix.
> I’m willing to help here but my knowledge of the twsi tends to zero.
> hint hint …
>
> cheers,
>         danny

Iirc, allwinner requires working i2c even to boot, because the boards
have i2c PMIC chips on them.  I wonder if it's a case where a few small
commands to the pmic work fine but bigger transfers fail?  I dunno,
anything more you can say about the problem would help.

-- Ian

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Karl Denninger
In reply to this post by Ian Lepore-3
On 3/20/2019 10:00, Ian Lepore wrote:

> On Tue, 2019-03-19 at 09:55 -0500, Karl Denninger wrote:
>> On 3/19/2019 09:26, Jedi Tek'Unum wrote:
>>> On Mar 18, 2019, at 2:57 PM, Ian Lepore <[hidden email]> wrote:
>>>> On Mon, 2019-03-18 at 14:51 -0500, Jedi Tek'Unum wrote:
>>>>> My impression wasn’t that support wasn’t there - but “out of
>>>>> the box”
>>>>> configuration wasn’t there. In comparison, I didn’t have to do
>>>>> anything to get I2C enabled in the binary distribution of Linux
>>>>> that
>>>>> comes through the manufacturer.
>>>>>
>>>>> Its the enabling part that isn’t obvious to most people IMO.
>>>>>
>>>>> Documentation/wiki is great. But even better would be all the
>>>>> enabling overlays already in place and the entries in
>>>>> loader.conf
>>>>> already there and commented out. It would be so much easier to
>>>>> go to
>>>>> a “common place” (loader.conf), skim through the notes, find
>>>>> the
>>>>> thing that one wants, and then just uncomment the referenced
>>>>> line!
>>>>> (Or any other similarly easy method.)
>>>>>
>>>>>
>>>>> For FBSD to get a better foothold in this space it needs to be
>>>>> better
>>>>> documented. For example, the wiki for NEO2 <
>>>>> http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO2>; is a
>>>>> step-by-
>>>>> step guide for how to acquire and configure Linux for it.
>>>>>
>>>>>
>>>> On one of my imx6 boards I have 5 SPI devices.  Each device can
>>>> use 3
>>>> or 4 different sets of pins for clock, data-in, and data-
>>>> out.  Plus,
>>>> each can use literally any number of whatever gpio pins they want
>>>> as
>>>> chip selects.  Even limiting the chipsels to a handfull, there
>>>> would
>>>> literally be thousands of possible combinations of devices and
>>>> pin
>>>> configurations, each one needing to be a separate overlay.
>>>>
>>>> Maybe you have experience primarily with rpi or some similarly
>>>> crippled
>>>> devices that only offer one or two choices?
>>> If memory serves correctly, there are only 2 I2C devices on the
>>> H3/H5 and the NanoPi NEO/2 implementations only externalize 1.
>>> There is only 1 SPI AFAIK.
>>>
>>> I wouldn’t call that crippled. I chose this platform exactly
>>> because of its characteristics - small, fast, cheap. It fits the
>>> project I’m using it for perfectly. In fact, I can see uses for
>>> even smaller (see Giant Board <https://groboards.com/giant-board/>)
>>> . I understand other projects may have different requirements and
>>> would drive one towards different solutions - and require more of
>>> the various interfaces. But they aren’t going to be typical of
>>> hobbyist projects.
>>>
>>> Maybe I should pose the question in another way. What is the
>>> philosophy for choosing GPIO as default for all the pins? These
>>> boards have a very limited number of pins and my preference would
>>> be that the broadest range of interface types would be the default.
>>> There are 2 UARTs exposed so I would have picked 1 to be enabled by
>>> default. After that, with I2C and SPI enabled, there are still 6
>>> GPIO available. For a tiny board like this that seems to be
>>> reasonable. If people have a need for slightly more GPIO then I
>>> would expect they would be the ones configuring overlays.
>>>
>>> Apparently the developers of the Linux packages for these boards
>>> have chosen the diverse approach (“FriendlyCore” based on
>>> UbuntuCore Xenial).
>>>
>>> IMHO, most “hobbyists” would prefer the diversity approach. I’m
>>> completely capable of becoming an expert in FBSD and this sort of
>>> configuration stuff yet it isn’t a priority for me - I just want to
>>> use it like any other hobbyist. The way things are now pushes this
>>> type of user away from FBSD.
>>>
>>> If there is some philosophical perspective against the diversity
>>> approach then the next best thing is to have documentation that
>>> clearly and simply tells people how to enable the other
>>> functionality.
>>>
>>> Finally, I think there is an opportunity to grow FBSD in the
>>> hobbyist world of these small products. We are past the point where
>>> people can have a real operating system running on systems at
>>> Arduino size and cost. Linux has been aggressively deployed there
>>> but I can say from experience that it ain’t pretty - I won’t say
>>> more as everyone reading this has a clear understanding of why that
>>> is.
>> I'm currently working an issue similar to this, but one that rates
>> "highly annoying" right now rather than "catastrophically bad."
>>
>> The environment is a RPI2 which has GPIO and I2c configured; GPIO to
>> drive outputs, I2c is used to read analog channels.
>>
>> On 11.0 this code ran perfectly well.
>>
>> On 12-STABLE )FreeBSD 12.0-STABLE r344818 GENERIC)
>>  it also runs well *BUT* generates a huge number of console messages
>> about spurious interrupts:
>>
>> intc0: Spurious interrupt detected
>> local_intc0: Spurious interrupt detected
>> intc0: Spurious interrupt detected
>> intc0: Spurious interrupt detected
>> local_intc0: Spurious interrupt detected
>> local_intc0: Spurious interrupt detected
>>
>> ....
>>
>> The issue is coming from the i2c side as I have another one of these
>> that has no I2c defined in the configuration (but is running
>> identical
>> code) and no messages.
>>
>> Something is indeed generating an /insane /number of interrupts on
>> one
>> of the channels:
>>
>> Interrupts
>> 530k total
>>  1159 local_intc
>> 494k local_intc
>>  8047 local_intc
>>
>> For obvious reasons I'd like to track this down (it's also generating
>> a
>> load average of 1.0, where it should be 0.1 or thereabouts) but I'm
>> not
>> sure where to start looking.
>>
>> config.txt looks like this:
>>
>> root@Pool-MCP:/mnt # cat config.txt
>> init_uart_clock=3000000
>> enable_uart=1
>> kernel=u-boot.bin
>> kernel7=u-boot.bin
>> dtoverlay=mmc
>> #audio_pwm_mode=2
>> dtparam=i2c_arm=on
>>
>> The only "change" from what is in the default is the i2c_arm=on line.
>>
>> The "something" appears to be the i2c code, *or* it's something
>> that's
>> gone wrong in the DTS changes that are in the newer way of building
>> the
>> boot area (where the grab is of the "standard" versions from ports
>> and
>> then just copied over.)
>>
>> I suspect this would bite you equally hard if you had a RTC
>> configured
>> on I2c as well.....
>>
>> Killing the process that has the I2c interface open (so the I2c
>> interface is not in active use, but is configured of course) does
>> *not*
>> stop the insane interrupt storm.
>>
> I'm aware of this (haven't forgotten that you reported it), but I
> haven't had time to look into it, because of a crazy $work schedule
> right now.  I did some work on the rpi i2c driver last year, so there's
> a chance I caused this problem.  I only have an ancient rpi-b to test
> with, I wonder if this is a problem that only happens on rpi2 models?
>
> -- Ian
I don't think so -- there's another report (Bernd Walter on this list)
with a Pi1 running 12-Release and an I2c RTC on it getting the same
messages (and, I assume, the same insane interrupt counts.)

--
Karl Denninger
[hidden email] <mailto:[hidden email]>
/The Market Ticker/
/[S/MIME encrypted email preferred]/

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: allwinner i2c [was: Options for FBSD support with LCD device - new project]

Jedi Tek'Unum-2
In reply to this post by Ian Lepore-3
On Mar 20, 2019, at 10:31 AM, Ian Lepore <[hidden email]> wrote:

>
> On Tue, 2019-03-19 at 08:28 +0200, Daniel Braniss wrote:
>> I have several allwinner SoC, mainly from FriendlyArm, and neither i2c or SPI work.
>> I have a hacked i2c that mostly works, but hangs sometimes :-), mainly
>> timing issues of which I have no idea how to fix.
>> I’m willing to help here but my knowledge of the twsi tends to zero.
>> hint hint …
>>
>> cheers,
>>        danny
>
> Iirc, allwinner requires working i2c even to boot, because the boards
> have i2c PMIC chips on them.  I wonder if it's a case where a few small
> commands to the pmic work fine but bigger transfers fail?  I dunno,
> anything more you can say about the problem would help.

My H5 board, a NanoPi NEO 2, running vendor supplied Linux has /dev/i2c-0 through i2c-3.

Only i2c0 is available externally. Detect shows

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- 3c -- 3e 3f
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: 70 71 -- 73 -- -- -- --                        

3c is the OLED Hat. The rest are all my boards (73 is mux and the rest are SX1509s).

The only other scan that shows anything is i2c3 device 30. Maybe that is the PMIC?

i2c1 and i2c2 scan very slowly and eventually show nothing. I suppose they aren’t pulled up.


Daniel, I haven’t had any problems with hangs (Linux) but I do have intermittent troubles that could be due to a variety of things. I’ve yet to see anything “rock solid” about these boards.

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Options for FBSD support with LCD device - new project

Jedi Tek'Unum-2
In reply to this post by Ian Lepore-3
On Mar 20, 2019, at 9:56 AM, Ian Lepore <[hidden email]> wrote:
>
> The default pin assignments in the dts are completely controlled by
> linux, and I think effectively by the actual board vendors who create
> the dts and submit it to linux.  We (freebsd) are just a consumer of
> the dts info, we have to work with whatever they shove down our
> throats, and continually re-adapt ourselves whenever they change their
> minds and make arbitrary incompatible changes from one release to the
> next (which they definitely do).

The problem is “linux” - which one?!

As far as I’ve been able to figure out, these boards have not been propagated into mainline linux. So if you are saying FBSD draws from mainline linux then you might not be getting the good stuff.

There is friendlyarm’s distribution /boot/sun50i-h5-nanopi-neo2.dtb that decompiled doesn’t look remotely like anything I’ve seen elsewhere. There is https://linux-sunxi.org/Main_Page <https://linux-sunxi.org/Main_Page>. There is armbian - some sun50i-h5-i2c*.dts overlays here: https://github.com/armbian/sunxi-DT-overlays/tree/master/sun50i-h5 <https://github.com/armbian/sunxi-DT-overlays/tree/master/sun50i-h5>. Given the moving target of what FDT is, who knows whether these are remotely useful.

Bottom line is we non-experts have next to zero chance getting these boards working for us with FBSD.

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Ian Lepore-3
In reply to this post by Bernd Walter-4
On Tue, 2019-03-19 at 17:14 +0100, Bernd Walter wrote:

> On Tue, Mar 19, 2019 at 09:55:12AM -0500, Karl Denninger wrote:
> > On 3/19/2019 09:26, Jedi Tek'Unum wrote:
> > > On Mar 18, 2019, at 2:57 PM, Ian Lepore <[hidden email]> wrote:
> > > > On Mon, 2019-03-18 at 14:51 -0500, Jedi Tek'Unum wrote:
> > > > > My impression wasn???t that support wasn???t there - but
> > > > > ???out of the box???
> > > > > configuration wasn???t there. In comparison, I didn???t have
> > > > > to do
> > > > > anything to get I2C enabled in the binary distribution of
> > > > > Linux that
> > > > > comes through the manufacturer.
> > > > >
> > > > > Its the enabling part that isn???t obvious to most people
> > > > > IMO.
> > > > >
> > > > > Documentation/wiki is great. But even better would be all the
> > > > > enabling overlays already in place and the entries in
> > > > > loader.conf
> > > > > already there and commented out. It would be so much easier
> > > > > to go to
> > > > > a ???common place??? (loader.conf), skim through the notes,
> > > > > find the
> > > > > thing that one wants, and then just uncomment the referenced
> > > > > line!
> > > > > (Or any other similarly easy method.)
> > > > >
> > > > >
> > > > > For FBSD to get a better foothold in this space it needs to
> > > > > be better
> > > > > documented. For example, the wiki for NEO2 <
> > > > > http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO2>; is a
> > > > > step-by-
> > > > > step guide for how to acquire and configure Linux for it.
> > > > >
> > > > >
> > > >
> > > > On one of my imx6 boards I have 5 SPI devices.  Each device can
> > > > use 3
> > > > or 4 different sets of pins for clock, data-in, and data-
> > > > out.  Plus,
> > > > each can use literally any number of whatever gpio pins they
> > > > want as
> > > > chip selects.  Even limiting the chipsels to a handfull, there
> > > > would
> > > > literally be thousands of possible combinations of devices and
> > > > pin
> > > > configurations, each one needing to be a separate overlay.
> > > >
> > > > Maybe you have experience primarily with rpi or some similarly
> > > > crippled
> > > > devices that only offer one or two choices?
> > >
> > > If memory serves correctly, there are only 2 I2C devices on the
> > > H3/H5 and the NanoPi NEO/2 implementations only externalize 1.
> > > There is only 1 SPI AFAIK.
> > >
> > > I wouldn???t call that crippled. I chose this platform exactly
> > > because of its characteristics - small, fast, cheap. It fits the
> > > project I???m using it for perfectly. In fact, I can see uses for
> > > even smaller (see Giant Board <https://groboards.com/giant-board/
> > > >). I understand other projects may have different requirements
> > > and would drive one towards different solutions - and require
> > > more of the various interfaces. But they aren???t going to be
> > > typical of hobbyist projects.
> > >
> > > Maybe I should pose the question in another way. What is the
> > > philosophy for choosing GPIO as default for all the pins? These
> > > boards have a very limited number of pins and my preference would
> > > be that the broadest range of interface types would be the
> > > default. There are 2 UARTs exposed so I would have picked 1 to be
> > > enabled by default. After that, with I2C and SPI enabled, there
> > > are still 6 GPIO available. For a tiny board like this that seems
> > > to be reasonable. If people have a need for slightly more GPIO
> > > then I would expect they would be the ones configuring overlays.
> > >
> > > Apparently the developers of the Linux packages for these boards
> > > have chosen the diverse approach (???FriendlyCore??? based on
> > > UbuntuCore Xenial).
> > >
> > > IMHO, most ???hobbyists??? would prefer the diversity approach.
> > > I???m completely capable of becoming an expert in FBSD and this
> > > sort of configuration stuff yet it isn???t a priority for me - I
> > > just want to use it like any other hobbyist. The way things are
> > > now pushes this type of user away from FBSD.
> > >
> > > If there is some philosophical perspective against the diversity
> > > approach then the next best thing is to have documentation that
> > > clearly and simply tells people how to enable the other
> > > functionality.
> > >
> > > Finally, I think there is an opportunity to grow FBSD in the
> > > hobbyist world of these small products. We are past the point
> > > where people can have a real operating system running on systems
> > > at Arduino size and cost. Linux has been aggressively deployed
> > > there but I can say from experience that it ain???t pretty - I
> > > won???t say more as everyone reading this has a clear
> > > understanding of why that is.
> >
> > I'm currently working an issue similar to this, but one that rates
> > "highly annoying" right now rather than "catastrophically bad."
> >
> > The environment is a RPI2 which has GPIO and I2c configured; GPIO
> > to
> > drive outputs, I2c is used to read analog channels.
> >
> > On 11.0 this code ran perfectly well.
> >
> > On 12-STABLE )FreeBSD 12.0-STABLE r344818 GENERIC)
> >  it also runs well *BUT* generates a huge number of console
> > messages
> > about spurious interrupts:
> >
> > intc0: Spurious interrupt detected
> > local_intc0: Spurious interrupt detected
> > intc0: Spurious interrupt detected
> > intc0: Spurious interrupt detected
> > local_intc0: Spurious interrupt detected
> > local_intc0: Spurious interrupt detected
> >
> > ....
> >
> > The issue is coming from the i2c side as I have another one of
> > these
> > that has no I2c defined in the configuration (but is running
> > identical
> > code) and no messages.
>
> Interesting.
> A local Pi1 running 12-RELEASE has the same messages:
> intc0: Spurious interrupt detected
> intc0: Spurious interrupt detected
> intc0: Spurious interrupt detected
> intc0: Spurious interrupt detected
> intc0: Spurious interrupt detected
> intc0: Spurious interrupt detected
> intc0: Spurious interrupt detected
> I have an I2C RTC on this machine.
>

Hmmm, I can't reproduce this.  I've got an rpi-b rev2 and I tried 13-
current and the official 12.0-RELEASE image and I have no problems with
interrupts while using an i2c RTC.  I also connected an at24c512 eeprom
and did a bunch of reading and writing to it.  No spurious interrupts,
and vmstat -i showed a completely reasonable number:

intc0,61: iichb0                                       5652         23

I don't know what to try next.

-- Ian

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Ralf Wenk-5
On 2019-03-24 at 17:55 -0600 Ian Lepore wrote:

> On Tue, 2019-03-19 at 17:14 +0100, Bernd Walter wrote:
> > On Tue, Mar 19, 2019 at 09:55:12AM -0500, Karl Denninger wrote:
> > > On 3/19/2019 09:26, Jedi Tek'Unum wrote:
> > > > On Mar 18, 2019, at 2:57 PM, Ian Lepore <[hidden email]> wrote:
> > > > > On Mon, 2019-03-18 at 14:51 -0500, Jedi Tek'Unum wrote:
> > > > > > My impression wasn???t that support wasn???t there - but
> > > > > > ???out of the box???
> > > > > > configuration wasn???t there. In comparison, I didn???t have
> > > > > > to do
> > > > > > anything to get I2C enabled in the binary distribution of
> > > > > > Linux that
> > > > > > comes through the manufacturer.
> > > > > >
> > > > > > Its the enabling part that isn???t obvious to most people
> > > > > > IMO.
> > > > > >
> > > > > > Documentation/wiki is great. But even better would be all the
> > > > > > enabling overlays already in place and the entries in
> > > > > > loader.conf
> > > > > > already there and commented out. It would be so much easier
> > > > > > to go to
> > > > > > a ???common place??? (loader.conf), skim through the notes,
> > > > > > find the
> > > > > > thing that one wants, and then just uncomment the referenced
> > > > > > line!
> > > > > > (Or any other similarly easy method.)
> > > > > >
> > > > > >
> > > > > > For FBSD to get a better foothold in this space it needs to
> > > > > > be better
> > > > > > documented. For example, the wiki for NEO2 <
> > > > > > http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO2>; is a
> > > > > > step-by-
> > > > > > step guide for how to acquire and configure Linux for it.
> > > > > >
> > > > > >
> > > > >
> > > > > On one of my imx6 boards I have 5 SPI devices.  Each device can
> > > > > use 3
> > > > > or 4 different sets of pins for clock, data-in, and data-
> > > > > out.  Plus,
> > > > > each can use literally any number of whatever gpio pins they
> > > > > want as
> > > > > chip selects.  Even limiting the chipsels to a handfull, there
> > > > > would
> > > > > literally be thousands of possible combinations of devices and
> > > > > pin
> > > > > configurations, each one needing to be a separate overlay.
> > > > >
> > > > > Maybe you have experience primarily with rpi or some similarly
> > > > > crippled
> > > > > devices that only offer one or two choices?
> > > >
> > > > If memory serves correctly, there are only 2 I2C devices on the
> > > > H3/H5 and the NanoPi NEO/2 implementations only externalize 1.
> > > > There is only 1 SPI AFAIK.
> > > >
> > > > I wouldn???t call that crippled. I chose this platform exactly
> > > > because of its characteristics - small, fast, cheap. It fits the
> > > > project I???m using it for perfectly. In fact, I can see uses for
> > > > even smaller (see Giant Board <https://groboards.com/giant-board/
> > > > >). I understand other projects may have different requirements
> > > > and would drive one towards different solutions - and require
> > > > more of the various interfaces. But they aren???t going to be
> > > > typical of hobbyist projects.
> > > >
> > > > Maybe I should pose the question in another way. What is the
> > > > philosophy for choosing GPIO as default for all the pins? These
> > > > boards have a very limited number of pins and my preference would
> > > > be that the broadest range of interface types would be the
> > > > default. There are 2 UARTs exposed so I would have picked 1 to be
> > > > enabled by default. After that, with I2C and SPI enabled, there
> > > > are still 6 GPIO available. For a tiny board like this that seems
> > > > to be reasonable. If people have a need for slightly more GPIO
> > > > then I would expect they would be the ones configuring overlays.
> > > >
> > > > Apparently the developers of the Linux packages for these boards
> > > > have chosen the diverse approach (???FriendlyCore??? based on
> > > > UbuntuCore Xenial).
> > > >
> > > > IMHO, most ???hobbyists??? would prefer the diversity approach.
> > > > I???m completely capable of becoming an expert in FBSD and this
> > > > sort of configuration stuff yet it isn???t a priority for me - I
> > > > just want to use it like any other hobbyist. The way things are
> > > > now pushes this type of user away from FBSD.
> > > >
> > > > If there is some philosophical perspective against the diversity
> > > > approach then the next best thing is to have documentation that
> > > > clearly and simply tells people how to enable the other
> > > > functionality.
> > > >
> > > > Finally, I think there is an opportunity to grow FBSD in the
> > > > hobbyist world of these small products. We are past the point
> > > > where people can have a real operating system running on systems
> > > > at Arduino size and cost. Linux has been aggressively deployed
> > > > there but I can say from experience that it ain???t pretty - I
> > > > won???t say more as everyone reading this has a clear
> > > > understanding of why that is.
> > >
> > > I'm currently working an issue similar to this, but one that rates
> > > "highly annoying" right now rather than "catastrophically bad."
> > >
> > > The environment is a RPI2 which has GPIO and I2c configured; GPIO
> > > to
> > > drive outputs, I2c is used to read analog channels.
> > >
> > > On 11.0 this code ran perfectly well.
> > >
> > > On 12-STABLE )FreeBSD 12.0-STABLE r344818 GENERIC)
> > >  it also runs well *BUT* generates a huge number of console
> > > messages
> > > about spurious interrupts:
> > >
> > > intc0: Spurious interrupt detected
> > > local_intc0: Spurious interrupt detected
> > > intc0: Spurious interrupt detected
> > > intc0: Spurious interrupt detected
> > > local_intc0: Spurious interrupt detected
> > > local_intc0: Spurious interrupt detected
> > >
> > > ....
> > >
> > > The issue is coming from the i2c side as I have another one of
> > > these
> > > that has no I2c defined in the configuration (but is running
> > > identical
> > > code) and no messages.
> >
> > Interesting.
> > A local Pi1 running 12-RELEASE has the same messages:
> > intc0: Spurious interrupt detected
> > intc0: Spurious interrupt detected
> > intc0: Spurious interrupt detected
> > intc0: Spurious interrupt detected
> > intc0: Spurious interrupt detected
> > intc0: Spurious interrupt detected
> > intc0: Spurious interrupt detected
> > I have an I2C RTC on this machine.
> >
>
> Hmmm, I can't reproduce this.  I've got an rpi-b rev2 and I tried 13-
> current and the official 12.0-RELEASE image and I have no problems with
> interrupts while using an i2c RTC.  I also connected an at24c512 eeprom
> and did a bunch of reading and writing to it.  No spurious interrupts,
> and vmstat -i showed a completely reasonable number:
>
> intc0,61: iichb0                                       5652         23
>
> I don't know what to try next.

I see those messages on an RPi B+, an RPi 3 B and RPi 3 B+.
All running a GENERIC-NONDEBUG CURRENT up to four weeks old.
Those RPi's are directly connected to different monitors via HDMI.
There are no (additional?) i2c devices connected.

I have got the impression that changing the monitors input to DVI
and back triggers the "intc0: Spurious interrupt detected" message
here.

Some data from today from the RPi 3 B+:

$ grep Spuri /var/log/messages
Mar 29 09:27:38 IZ-193 kernel: local_intc0: Spurious interrupt detected
Mar 29 09:27:38 IZ-193 kernel: intc0: Spurious interrupt detected
Mar 29 09:40:36 IZ-193 kernel: intc0: Spurious interrupt detected
Mar 29 10:56:29 IZ-193 kernel: intc0: Spurious interrupt detected
Mar 29 10:56:29 IZ-193 kernel: local_intc0: Spurious interrupt detected
Mar 29 14:50:20 IZ-193 kernel: intc0: Spurious interrupt detected
Mar 29 14:50:20 IZ-193 kernel: local_intc0: Spurious interrupt detected
Mar 29 14:50:20 IZ-193 kernel: intc0: Spurious interrupt detected
$ vmstat -i | grep ichb
intc0,61: iichb0                                       131         0
$

Hmm, changing the monitors input several times while writing this mail
causes the message almost every time while this RPi is building a new
kernel with make -j4.

An remote PRi 2 with 14 days uptime and no monitor input switching
did not log any "Spurious interrupt detected" message.
It is the same on an RPi 3 B with 24 days uptime and no monitor at all.

Ralf

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Bernd Walter-4
In reply to this post by Ian Lepore-3
On Sun, Mar 24, 2019 at 05:55:33PM -0600, Ian Lepore wrote:

> On Tue, 2019-03-19 at 17:14 +0100, Bernd Walter wrote:
> > On Tue, Mar 19, 2019 at 09:55:12AM -0500, Karl Denninger wrote:
> > > On 3/19/2019 09:26, Jedi Tek'Unum wrote:
> > > > On Mar 18, 2019, at 2:57 PM, Ian Lepore <[hidden email]> wrote:
> > > > > On Mon, 2019-03-18 at 14:51 -0500, Jedi Tek'Unum wrote:
> > > > > > My impression wasn???t that support wasn???t there - but
> > > > > > ???out of the box???
> > > > > > configuration wasn???t there. In comparison, I didn???t have
> > > > > > to do
> > > > > > anything to get I2C enabled in the binary distribution of
> > > > > > Linux that
> > > > > > comes through the manufacturer.
> > > > > >
> > > > > > Its the enabling part that isn???t obvious to most people
> > > > > > IMO.
> > > > > >
> > > > > > Documentation/wiki is great. But even better would be all the
> > > > > > enabling overlays already in place and the entries in
> > > > > > loader.conf
> > > > > > already there and commented out. It would be so much easier
> > > > > > to go to
> > > > > > a ???common place??? (loader.conf), skim through the notes,
> > > > > > find the
> > > > > > thing that one wants, and then just uncomment the referenced
> > > > > > line!
> > > > > > (Or any other similarly easy method.)
> > > > > >
> > > > > >
> > > > > > For FBSD to get a better foothold in this space it needs to
> > > > > > be better
> > > > > > documented. For example, the wiki for NEO2 <
> > > > > > http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO2>; is a
> > > > > > step-by-
> > > > > > step guide for how to acquire and configure Linux for it.
> > > > > >
> > > > > >
> > > > >
> > > > > On one of my imx6 boards I have 5 SPI devices.  Each device can
> > > > > use 3
> > > > > or 4 different sets of pins for clock, data-in, and data-
> > > > > out.  Plus,
> > > > > each can use literally any number of whatever gpio pins they
> > > > > want as
> > > > > chip selects.  Even limiting the chipsels to a handfull, there
> > > > > would
> > > > > literally be thousands of possible combinations of devices and
> > > > > pin
> > > > > configurations, each one needing to be a separate overlay.
> > > > >
> > > > > Maybe you have experience primarily with rpi or some similarly
> > > > > crippled
> > > > > devices that only offer one or two choices?
> > > >
> > > > If memory serves correctly, there are only 2 I2C devices on the
> > > > H3/H5 and the NanoPi NEO/2 implementations only externalize 1.
> > > > There is only 1 SPI AFAIK.
> > > >
> > > > I wouldn???t call that crippled. I chose this platform exactly
> > > > because of its characteristics - small, fast, cheap. It fits the
> > > > project I???m using it for perfectly. In fact, I can see uses for
> > > > even smaller (see Giant Board <https://groboards.com/giant-board/
> > > > >). I understand other projects may have different requirements
> > > > and would drive one towards different solutions - and require
> > > > more of the various interfaces. But they aren???t going to be
> > > > typical of hobbyist projects.
> > > >
> > > > Maybe I should pose the question in another way. What is the
> > > > philosophy for choosing GPIO as default for all the pins? These
> > > > boards have a very limited number of pins and my preference would
> > > > be that the broadest range of interface types would be the
> > > > default. There are 2 UARTs exposed so I would have picked 1 to be
> > > > enabled by default. After that, with I2C and SPI enabled, there
> > > > are still 6 GPIO available. For a tiny board like this that seems
> > > > to be reasonable. If people have a need for slightly more GPIO
> > > > then I would expect they would be the ones configuring overlays.
> > > >
> > > > Apparently the developers of the Linux packages for these boards
> > > > have chosen the diverse approach (???FriendlyCore??? based on
> > > > UbuntuCore Xenial).
> > > >
> > > > IMHO, most ???hobbyists??? would prefer the diversity approach.
> > > > I???m completely capable of becoming an expert in FBSD and this
> > > > sort of configuration stuff yet it isn???t a priority for me - I
> > > > just want to use it like any other hobbyist. The way things are
> > > > now pushes this type of user away from FBSD.
> > > >
> > > > If there is some philosophical perspective against the diversity
> > > > approach then the next best thing is to have documentation that
> > > > clearly and simply tells people how to enable the other
> > > > functionality.
> > > >
> > > > Finally, I think there is an opportunity to grow FBSD in the
> > > > hobbyist world of these small products. We are past the point
> > > > where people can have a real operating system running on systems
> > > > at Arduino size and cost. Linux has been aggressively deployed
> > > > there but I can say from experience that it ain???t pretty - I
> > > > won???t say more as everyone reading this has a clear
> > > > understanding of why that is.
> > >
> > > I'm currently working an issue similar to this, but one that rates
> > > "highly annoying" right now rather than "catastrophically bad."
> > >
> > > The environment is a RPI2 which has GPIO and I2c configured; GPIO
> > > to
> > > drive outputs, I2c is used to read analog channels.
> > >
> > > On 11.0 this code ran perfectly well.
> > >
> > > On 12-STABLE )FreeBSD 12.0-STABLE r344818 GENERIC)
> > >  it also runs well *BUT* generates a huge number of console
> > > messages
> > > about spurious interrupts:
> > >
> > > intc0: Spurious interrupt detected
> > > local_intc0: Spurious interrupt detected
> > > intc0: Spurious interrupt detected
> > > intc0: Spurious interrupt detected
> > > local_intc0: Spurious interrupt detected
> > > local_intc0: Spurious interrupt detected
> > >
> > > ....
> > >
> > > The issue is coming from the i2c side as I have another one of
> > > these
> > > that has no I2c defined in the configuration (but is running
> > > identical
> > > code) and no messages.
> >
> > Interesting.
> > A local Pi1 running 12-RELEASE has the same messages:
> > intc0: Spurious interrupt detected
> > intc0: Spurious interrupt detected
> > intc0: Spurious interrupt detected
> > intc0: Spurious interrupt detected
> > intc0: Spurious interrupt detected
> > intc0: Spurious interrupt detected
> > intc0: Spurious interrupt detected
> > I have an I2C RTC on this machine.
> >
>
> Hmmm, I can't reproduce this.  I've got an rpi-b rev2 and I tried 13-
> current and the official 12.0-RELEASE image and I have no problems with
> interrupts while using an i2c RTC.  I also connected an at24c512 eeprom
> and did a bunch of reading and writing to it.  No spurious interrupts,
> and vmstat -i showed a completely reasonable number:
>
> intc0,61: iichb0                                       5652         23
>
> I don't know what to try next.

This is on my system:
[9]time1# vmstat -i
interrupt                                             total       rate
intc0,2: vchiq0                                           2          0
intc0,11: systimer0                              2811547017       1119
intc0,17: +                                       288731204        115
intc0,28: bcm_dma0                                 25127004         10
intc0,61: iichb0                                       8384          0
intc0,65: uart0                                         249          0
intc0,70: +                                         4650145          2
Total                                            3130064005       1246

nxprtc0: <NXP PCF8563 RTC> at addr 0xa2 on iicbus0

It seems it doesn't happen very often:
[19]time1# bzgrep Spuri /var/log/all.log.*.bz2
/var/log/all.log.0.bz2:Mar 24 03:12:04 time1 kernel: intc0: Spurious interrupt detected
/var/log/all.log.0.bz2:Mar 24 07:12:04 time1 kernel: intc0: Spurious interrupt detected
/var/log/all.log.0.bz2:Mar 24 14:42:04 time1 kernel: intc0: Spurious interrupt detected
/var/log/all.log.0.bz2:Mar 24 15:42:04 time1 kernel: intc0: Spurious interrupt detected
/var/log/all.log.0.bz2:Mar 24 17:42:04 time1 kernel: intc0: Spurious interrupt detected
/var/log/all.log.1.bz2:Mar 23 02:12:04 time1 kernel: intc0: Spurious interrupt detected
/var/log/all.log.1.bz2:Mar 23 09:12:04 time1 kernel: intc0: Spurious interrupt detected
/var/log/all.log.2.bz2:Mar 22 02:12:03 time1 kernel: intc0: Spurious interrupt detected
/var/log/all.log.2.bz2:Mar 22 17:12:04 time1 kernel: intc0: Spurious interrupt detected
/var/log/all.log.2.bz2:Mar 22 18:12:04 time1 kernel: intc0: Spurious interrupt detected
/var/log/all.log.2.bz2:Mar 22 22:42:04 time1 kernel: intc0: Spurious interrupt detected
/var/log/all.log.3.bz2:Mar 21 01:12:03 time1 kernel: intc0: Spurious interrupt detected
/var/log/all.log.3.bz2:Mar 21 02:42:03 time1 kernel: intc0: Spurious interrupt detected
/var/log/all.log.3.bz2:Mar 21 10:12:03 time1 kernel: intc0: Spurious interrupt detected
/var/log/all.log.3.bz2:Mar 21 13:42:03 time1 kernel: intc0: Spurious interrupt detected
/var/log/all.log.3.bz2:Mar 21 14:12:03 time1 kernel: intc0: Spurious interrupt detected
/var/log/all.log.3.bz2:Mar 21 19:42:03 time1 kernel: intc0: Spurious interrupt detected
/var/log/all.log.4.bz2:Mar 20 08:42:03 time1 kernel: intc0: Spurious interrupt detected
/var/log/all.log.4.bz2:Mar 20 19:42:03 time1 kernel: intc0: Spurious interrupt detected
/var/log/all.log.5.bz2:Mar 19 04:42:03 time1 kernel: intc0: Spurious interrupt detected
/var/log/all.log.5.bz2:Mar 19 10:12:03 time1 kernel: intc0: Spurious interrupt detected
/var/log/all.log.5.bz2:Mar 19 11:12:03 time1 kernel: intc0: Spurious interrupt detected
/var/log/all.log.5.bz2:Mar 19 13:42:03 time1 kernel: intc0: Spurious interrupt detected
/var/log/all.log.6.bz2:Mar 18 05:12:02 time1 kernel: intc0: Spurious interrupt detected
/var/log/all.log.6.bz2:Mar 18 13:12:03 time1 kernel: intc0: Spurious interrupt detected
[20]time1# grep Spuri /var/log/all.log
Mar 25 03:42:04 time1 kernel: intc0: Spurious interrupt detected

Maybe the iic is a red hering.
It is just that we both use it.
But they all are within a 30min grid and it is aligned to boottime.
I don't see the local_intc0 messages on my system.
Mine is a stock FreeBSD-12, just rearranged the image data for zroot and
modules/dtbo loaded for zroot and rtc.

--
B.Walter <[hidden email]> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Bernd Walter-4
In reply to this post by Ian Lepore-3
On Wed, Mar 20, 2019 at 09:00:17AM -0600, Ian Lepore wrote:

> On Tue, 2019-03-19 at 09:55 -0500, Karl Denninger wrote:
> > On 3/19/2019 09:26, Jedi Tek'Unum wrote:
> > > On Mar 18, 2019, at 2:57 PM, Ian Lepore <[hidden email]> wrote:
> > > > On Mon, 2019-03-18 at 14:51 -0500, Jedi Tek'Unum wrote:
> > > > > My impression wasn???t that support wasn???t there - but ???out of
> > > > > the box???
> > > > > configuration wasn???t there. In comparison, I didn???t have to do
> > > > > anything to get I2C enabled in the binary distribution of Linux
> > > > > that
> > > > > comes through the manufacturer.
> > > > >
> > > > > Its the enabling part that isn???t obvious to most people IMO.
> > > > >
> > > > > Documentation/wiki is great. But even better would be all the
> > > > > enabling overlays already in place and the entries in
> > > > > loader.conf
> > > > > already there and commented out. It would be so much easier to
> > > > > go to
> > > > > a ???common place??? (loader.conf), skim through the notes, find
> > > > > the
> > > > > thing that one wants, and then just uncomment the referenced
> > > > > line!
> > > > > (Or any other similarly easy method.)
> > > > >
> > > > >
> > > > > For FBSD to get a better foothold in this space it needs to be
> > > > > better
> > > > > documented. For example, the wiki for NEO2 <
> > > > > http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO2>; is a
> > > > > step-by-
> > > > > step guide for how to acquire and configure Linux for it.
> > > > >
> > > > >
> > > >
> > > > On one of my imx6 boards I have 5 SPI devices.  Each device can
> > > > use 3
> > > > or 4 different sets of pins for clock, data-in, and data-
> > > > out.  Plus,
> > > > each can use literally any number of whatever gpio pins they want
> > > > as
> > > > chip selects.  Even limiting the chipsels to a handfull, there
> > > > would
> > > > literally be thousands of possible combinations of devices and
> > > > pin
> > > > configurations, each one needing to be a separate overlay.
> > > >
> > > > Maybe you have experience primarily with rpi or some similarly
> > > > crippled
> > > > devices that only offer one or two choices?
> > >
> > > If memory serves correctly, there are only 2 I2C devices on the
> > > H3/H5 and the NanoPi NEO/2 implementations only externalize 1.
> > > There is only 1 SPI AFAIK.
> > >
> > > I wouldn???t call that crippled. I chose this platform exactly
> > > because of its characteristics - small, fast, cheap. It fits the
> > > project I???m using it for perfectly. In fact, I can see uses for
> > > even smaller (see Giant Board <https://groboards.com/giant-board/>)
> > > . I understand other projects may have different requirements and
> > > would drive one towards different solutions - and require more of
> > > the various interfaces. But they aren???t going to be typical of
> > > hobbyist projects.
> > >
> > > Maybe I should pose the question in another way. What is the
> > > philosophy for choosing GPIO as default for all the pins? These
> > > boards have a very limited number of pins and my preference would
> > > be that the broadest range of interface types would be the default.
> > > There are 2 UARTs exposed so I would have picked 1 to be enabled by
> > > default. After that, with I2C and SPI enabled, there are still 6
> > > GPIO available. For a tiny board like this that seems to be
> > > reasonable. If people have a need for slightly more GPIO then I
> > > would expect they would be the ones configuring overlays.
> > >
> > > Apparently the developers of the Linux packages for these boards
> > > have chosen the diverse approach (???FriendlyCore??? based on
> > > UbuntuCore Xenial).
> > >
> > > IMHO, most ???hobbyists??? would prefer the diversity approach. I???m
> > > completely capable of becoming an expert in FBSD and this sort of
> > > configuration stuff yet it isn???t a priority for me - I just want to
> > > use it like any other hobbyist. The way things are now pushes this
> > > type of user away from FBSD.
> > >
> > > If there is some philosophical perspective against the diversity
> > > approach then the next best thing is to have documentation that
> > > clearly and simply tells people how to enable the other
> > > functionality.
> > >
> > > Finally, I think there is an opportunity to grow FBSD in the
> > > hobbyist world of these small products. We are past the point where
> > > people can have a real operating system running on systems at
> > > Arduino size and cost. Linux has been aggressively deployed there
> > > but I can say from experience that it ain???t pretty - I won???t say
> > > more as everyone reading this has a clear understanding of why that
> > > is.
> >
> > I'm currently working an issue similar to this, but one that rates
> > "highly annoying" right now rather than "catastrophically bad."
> >
> > The environment is a RPI2 which has GPIO and I2c configured; GPIO to
> > drive outputs, I2c is used to read analog channels.
> >
> > On 11.0 this code ran perfectly well.
> >
> > On 12-STABLE )FreeBSD 12.0-STABLE r344818 GENERIC)
> >  it also runs well *BUT* generates a huge number of console messages
> > about spurious interrupts:
> >
> > intc0: Spurious interrupt detected
> > local_intc0: Spurious interrupt detected
> > intc0: Spurious interrupt detected
> > intc0: Spurious interrupt detected
> > local_intc0: Spurious interrupt detected
> > local_intc0: Spurious interrupt detected
> >
> > ....
> >
> > The issue is coming from the i2c side as I have another one of these
> > that has no I2c defined in the configuration (but is running
> > identical
> > code) and no messages.
> >
> > Something is indeed generating an /insane /number of interrupts on
> > one
> > of the channels:
> >
> > Interrupts
> > 530k total
> >  1159 local_intc
> > 494k local_intc
> >  8047 local_intc
> >
> > For obvious reasons I'd like to track this down (it's also generating
> > a
> > load average of 1.0, where it should be 0.1 or thereabouts) but I'm
> > not
> > sure where to start looking.
> >
> > config.txt looks like this:
> >
> > root@Pool-MCP:/mnt # cat config.txt
> > init_uart_clock=3000000
> > enable_uart=1
> > kernel=u-boot.bin
> > kernel7=u-boot.bin
> > dtoverlay=mmc
> > #audio_pwm_mode=2
> > dtparam=i2c_arm=on
> >
> > The only "change" from what is in the default is the i2c_arm=on line.
> >
> > The "something" appears to be the i2c code, *or* it's something
> > that's
> > gone wrong in the DTS changes that are in the newer way of building
> > the
> > boot area (where the grab is of the "standard" versions from ports
> > and
> > then just copied over.)
> >
> > I suspect this would bite you equally hard if you had a RTC
> > configured
> > on I2c as well.....
> >
> > Killing the process that has the I2c interface open (so the I2c
> > interface is not in active use, but is configured of course) does
> > *not*
> > stop the insane interrupt storm.
> >
>
> I'm aware of this (haven't forgotten that you reported it), but I
> haven't had time to look into it, because of a crazy $work schedule
> right now.  I did some work on the rpi i2c driver last year, so there's
> a chance I caused this problem.  I only have an ancient rpi-b to test
> with, I wonder if this is a problem that only happens on rpi2 models?

My system is a Pi1 - one of the later models with 512MB RAM and 4-port USB.

--
B.Walter <[hidden email]> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Karl Denninger
In reply to this post by Ian Lepore-3

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

root@Pool-MCP:~ # vmstat -i
interrupt                                             total       rate
local_intc0,1: +                                    6007812       1143
local_intc0,8: +                                   82834082      15754
local_intc0,9: pmu0                                      86          0
intc0,1: mbox0                                          268          0
intc0,2: vchiq0                                           2          0
intc0,17: +                                       126693883      24096
intc0,28: bcm_dma0                                    89696         17
intc0,61: iichb0                                          1          0
intc0,65: uart0                                        4362          1
intc0,70: +                                           15620          3
cpu0:rendezvous                                          47          0
cpu1:rendezvous                                          28          0
cpu2:rendezvous                                          48          0
cpu3:rendezvous                                          53          0
cpu0:preempt                                          34447          7
cpu1:preempt                                         177488         34
cpu2:preempt                                         164474         31
cpu3:preempt                                         172970         33
cpu0:hardclock                                            3          0
Total                                             216195370      41119

This is the instance that is *not* doing it.

The one that is:

root@Pool-MCP:/data/karl # vmstat -i
interrupt                                             total       rate
local_intc0,1: +                                  117213190       1160
local_intc0,3: +                                 2775590966      27463
local_intc0,8: +                                  818346159       8097
local_intc0,9: pmu0                                    1888          0
intc0,1: mbox0                                         1876          0
intc0,2: vchiq0                                           2          0
intc0,17: +                                      2658685185      26306
intc0,28: bcm_dma0                                   141881          1
intc0,61: iichb0                                     432618          4
intc0,65: uart0                                         415          0
intc0,70: +                                           20556          0
cpu0:rendezvous                                          80          0
cpu1:rendezvous                                          94          0
cpu2:rendezvous                                          62          0
cpu3:rendezvous                                          62          0
cpu0:ast                                                  1          0
cpu2:ast                                                  4          0
cpu3:ast                                                  2          0
cpu0:preempt                                        1618359         16
cpu2:preempt                                        9797849         97
cpu3:preempt                                        9853072         97
cpu0:hardclock                                            6          0
Total                                            6391704327      63243

Both running identical copies of the code (same build, same everything.)

Now, here's the thing -- on the one that's doing it the load average is
1.04 -- only .04 is real as the code running on that box is extremely
efficient (it reads analog I2c inputs and acts on them by flipping
GPIOs, plus reporting status.)  The rest is the interrupts but vmstat -i
doesn't show it.  "systat -vm", however, DOES:

    1 users    Load  1.01  1.02  1.00                  Mar 25 11:24
   Mem usage:  14%Phy 14%Kmem
Mem: KB    REAL            VIRTUAL                      VN PAGER   SWAP
PAGER
        Tot   Share      Tot    Share    Free           in   out    
in   out
Act   29656    9132   138288    10092  804344  count
All   30308    9768   140020    11808          pages
Proc:                                                            Interrupts
  r   p   d   s   w   Csw  Trp  Sys  Int  Sof  Flt        ioflt  530k total
             27       948   44  279 9462  103             cow    1166
local_intc
                                                          zfod   495k
local_intc
 0.2%Sys   0.0%Intr  0.2%User  0.0%Nice 99.6%Idle         ozfod  8099
local_intc
|    |    |    |    |    |    |    |    |    |           %ozfod      
local_intc
                                                          daefr      
intc0,1: m
                                           dtbuf          prcfr      
intc0,2: v
Namei     Name-cache   Dir-cache     30805 desvn          totfr 26205
intc0,17:
   Calls    hits   %    hits   %     30805 numvn          react      
intc0,28:
    2556    2556 100                 28399 frevn          pdwak     4
intc0,61:
                                                        2 pdpgs      
intc0,65:
Disks mmcsd                                               intrn      
intc0,70:
KB/t   0.00                                        109716 wire       
cpu0:rende
tps       0                                          6256 act        
cpu1:rende
MB/s   0.00                                         18172 inact      
cpu2:rende
%busy     0                                               laund      
cpu3:rende
                                                   804344 free       
cpu0:ast
                                                    55168 buf        
cpu2:ast
                                                                     
cpu3:ast
                                                                   12
cpu0:preem
                                                                  136
cpu2:preem
                                                                   91
cpu3:preem
                                                                     
cpu0:hardc

Note the "495k" number.  That's real; on the unit that is NOT
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.

Specifically, if I had to guess its that there's an interrupt source
that is attached to the CPU but there's no handler for it, and if it
triggers and is not acknowledged it KEEPS triggering.  The question is
-- what is it and why is it "on"?

The uboot (and thus implied DTS) package that gets included here on the
build machine is:

u-boot-rpi2-2019.01            Cross-build das u-boot for model rpi2

if that matters -- and it might.....

I'm going to leave both running; if anyone has ideas of things I can
poke to try to figure out why the one that is doing it is, or the other
way around, let me know and I'll dump/poke/whatever to try to find the
answer to this.  I'd specifically like to know why "vmstat -i" doesn't
show the source of that ridiculous rate interrupt storm (which IS real,
as the CPU load is real) but "systat -vm" does.

--
Karl Denninger
[hidden email] <mailto:[hidden email]>
/The Market Ticker/
/[S/MIME encrypted email preferred]/

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Bernd Walter-4
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@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.

--
B.Walter <[hidden email]> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Ian Lepore-3
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@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.

-- Ian

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Karl Denninger
In reply to this post by Bernd Walter-4
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@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
[hidden email] <mailto:[hidden email]>
/The Market Ticker/
/[S/MIME encrypted email preferred]/

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Bernd Walter-4
In reply to this post by Ian Lepore-3
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@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.

--
B.Walter <[hidden email]> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Ian Lepore-3
In reply to this post by Karl Denninger
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@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

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Bernd Walter-4
In reply to this post by Bernd Walter-4
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@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.

--
B.Walter <[hidden email]> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Karl Denninger
In reply to this post by Ian Lepore-3
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@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
[hidden email] <mailto:[hidden email]>
/The Market Ticker/
/[S/MIME encrypted email preferred]/

smime.p7s (6K) Download Attachment
1234