On Sun, 24 Jun 2018 11:38:30 +0200 Andreas Kemnade andreas@kemnade.info wrote:
On Sun, 24 Jun 2018 09:52:53 +0200 "H. Nikolaus Schaller" hns@goldelico.com wrote:
Hi,
Am 24.06.2018 um 09:11 schrieb Andreas Kemnade andreas@kemnade.info:
On Sat, 23 Jun 2018 12:13:11 +0200 "H. Nikolaus Schaller" hns@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@aktux:~/kerneltest$ ls *.log | wc -l 54 andi@aktux:~/kerneltest$ grep 'Oops' *.log andi@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