[Letux-kernel] New LetuxOS Kernels - strcmp(NULL)

[Andreas Kemnade]

On Sun, 24 Jun 2018 11:38:30 +0200
Andreas Kemnade <andreas at kemnade.info> wrote:

> On Sun, 24 Jun 2018 09:52:53 +0200
> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
> 
> > Hi,
> >   
> > > Am 24.06.2018 um 09:11 schrieb Andreas Kemnade <andreas at kemnade.info>:
> > > 
> > > On Sat, 23 Jun 2018 12:13:11 +0200
> > > "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
> > > 
> > >     
> > >> 
> > >> So the issue is that "backlight_pins_pinmux" are searched for a NULL record before they
> > >> are properly stored. Or someone punches a NULL into the radix_tree.
> > >> 
> > >> Hope this sheds some new light on the problem.
> > >>     
> > > hmm, the next question is whether the NULL is *always* there, so even
> > > in the successful boots. Is that still with mainline  sources + minimal
> > > set of things?
> > > 
> > > Can we infer any bad order of module loading from that output?
> > > Probably the thing that inserts the NULL should be loaded last for
> > > successful boots or first for failed boots
> > > 
> > > Or should we remove stuff from dtb piece by piece to see if that helps?    
> > 
> > The problem is that you can remove almost anything and "it helps". So
> > it is very fragile to have a system that runs into this bug. If
> > you change a little piece, the problem disappears but you don't know if
> > it is really the reason or just a factor that enables/disables the real
> > problem to appear/disappear.  
> 
> I think we can do it the other way round. Removing drivers stuff which
> does not disable the problem and consider them not guilty. 
> 
Hmm, so the list of probably not guilty list is initially the stuff not
common to all the failing platforms.

> > 
> > And not to forget: they may still be innocent (if my latest theory is wrong)...
> > 
> > So I'd suggest to play around with the generic-adc-battery module/driver/dtb.
> >   
> ok, module blacklisted. Will boot that setup the whole afternoon.
> 
while having/preparing lunch, I had 54 boots
without Oopses:

andi at aktux:~/kerneltest$ ls *.log | wc -l
54
andi at aktux:~/kerneltest$ grep  'Oops' *.log
andi at aktux:~/kerneltest$ 

so if the problem is triggered by gab, we have all its dependencies
also on the verdict list (iio, twl4030-madc, something else for pyra?,
what are the common things here). But as you said, I cannot rule out
that there is just a printk which needs to be disabled to reenable the
problem.

But what I remember: if you disable pwm_bl, the problem moves into the
sound system. Maybe we should check that log again.

BTW: with my setup I am almost ready for linux-next nightly testing.

Regards,
Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20180624/edc3f266/attachment.asc>