[Letux-kernel] Kernel v5.1-rc1 (was: LetuxOS Kernel v5.0-rc1)

H. Nikolaus Schaller hns at goldelico.com
Thu Mar 21 07:05:18 CET 2019


HI,

> Am 20.03.2019 um 16:31 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> Hi,
> 
>> Am 20.03.2019 um 08:30 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>> 
>> Hi,
>> 
>>> Am 20.03.2019 um 08:19 schrieb Andreas Kemnade <andreas at kemnade.info>:
>>> 
>>> Hi,
>>> 
>>> 
>>> On Tue, 19 Mar 2019 13:30:17 +0100
>>> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
>>> 
>>>>> Am 19.03.2019 um 13:16 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>> 
>>>>>>> * GTA04A4:	backlight ok, display shows white pixels only  
>>>>>> 
>>>>>> hmm, did a quick test with mainline: older dtb + 5.1-rc1 kernel = display ok
>>>>>> 5.1-rc1 kernel + dtb-5-1-rc1 (both mainline) = black screen  
>> 
>> Ah, I didn't read precisely: "black screen". I get this as well if I eliminate
>> most Letux patch sets.
>> 
>> This means that one or two hacks are not yet upstream...
>> 
>>>>> 
>>> well,
>>> echo 0 >/sys/class/backlight/backlight/bl_power
>>> resolved that. Then I had a working display with mainline 5.1-rc1 + dtb-5.1-rc1
>>> 
>>> I think we are talking about different problems.
>> 
>> Looks so...
>> 
>> My main symptom is that I get a /dev/fb0, X server process is running, backlight
>> is on, but the screen is completely white. And xset dpms force on/off can
>> turn backlight on&off. But still only white pixels.

I have now checked and the symptoms are two facets of the same problem.

When doing my git bisect of linus/master plus adding only 4 of our letux patches,
I get a black display in the error case which goes completely white when echoing to
bp_power.

I never had the backlight staying black but display working.

But there remains some difference by adding the full letux patch set. I.e. some
piece of code does have the same side effect as echo 0 >/sys/class/backlight/backlight/bl_power

So we could probably check

	cat /sys/class/backlight/backlight/bl_power

after boot to automate the bisect (1 = bad, 0 = good).

>> 
>> I guess the problem is either the SPI interface to the panel or the pixel
>> clock/pixel data.
>> 
>> I am currently running a bisect to find out more.
> 
> First result:

Here is a new result after repeating with git bisect start '--no-checkout' '--' 'arch/arm' 'include/' 'drivers/'

	f90d64483ebd394958841f67f8794ab203b319a7 is the first bad commit 
	https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f90d64483ebd394958841f67f8794ab203b319a7

> 
> 	67e79a6dc2664a3ef85113440e60f7aaca3c7815 is the first bad commit
> 
> i.e.
> 
> 	https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=67e79a6dc2664a3ef85113440e60f7aaca3c7815
> 
> But what does this have to do with the GTA04 display and backlight power???

Same question for the new result... This time it is a different merge.
In both cases a merge of subsystem updates and not a single patch. Strange.

> 
> I fear a side-effect of an array out of bounds write like we did have a while ago.
> 
> Or I did make a mistake in reporting good/bad to git bisect. Maybe I should repeat.
> 
> Note this is using mainline linux (bisected) + letux/compile-fixes + letux/arm_defconfig + letux/Letux + letux/ubi-fs and nothing else.
> So it does not include many of the Letux hacks.

So at the moment I have no good idea how to debug it. Maybe we should wait
until v5.1-rc2 is out. Someone else might have a similar issue or a late
fix is provided that is missing in v5.1-rc1.

BR,
Nikolaus



More information about the Letux-kernel mailing list