[Letux-kernel] Letux 4.13-rc1

Wed Jul 19 21:07:48 CEST 2017

> Am 19.07.2017 um 18:52 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> 
>> Am 18.07.2017 um 12:29 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>> 
>>> 
>>> Am 18.07.2017 um 11:02 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>>> 
>>> Hi,
>>> I did run the scripts to move forwards to 4.13-rc1.
>>> There wasn't much to be manually fixed.
>>> Only the TILER branch has become significantly incompatible so that I have removed it from merging.
>>> This is something to check later.
>>> And I reestablished the alternate ov9655 driver we had in 3.12 and did some modernization.
>>> 
>>> A really nice new feature is that the bq27xxx drivers now can query the DT for nominal
>>> battery capacity. So I have added battery-nodes to the DTs.
>>> 
>>> Unfortunately for testing, the kernel does not boot very stable on the GTA04.
>>> It reports 3 or 4 oops, not all modules are loaded (modprobe hangs).
>>> And I have to press ctrl-C to kill some blocked process before boot continues and login: appears
>>> and X11/LXDE starts.
>> 
>> I should add:
>> * there are errors from the MMC subsystem (mmcblk0: error -5 sending stop command, original cmd response 0x900, card status 0x900)
>> * there are very similar problems on the Pyra
>> 
>>> 
>>> Maybe someone can also look on it in parallel to me:
>>> 
>>> http://git.goldelico.com/?p=gta04-kernel.git;a=heads
> 
> More detailed look into the logs shows: I get 3 warnings and issues around __setup_irq.
> The first one comes from the pinctrl subsystem. Two others come from the BMA180 driver - but
> that may just be the trigger and not the reason.
> 
> And the mmc error seen may be a followup bug.
> 
> Sebastian Reichel already has tested:
> 
> https://lkml.org/lkml/2017/7/10/311
> 
> The discussion is lengthy and includes Linus...
> 
> And it seems to be a problem of all omap devices (haven't tried on i.MX6 yet).
> 
> There seem to be approx. 3 different "solutions" but people are not sure if
> it is a problem in irq handling, general omap or pinctrl.
> 
> It is difficult to find out if they already came to a solution for patching
> our -rc1 or if we have to wait for -rc2 or -rc3 for something to appear.
> 
> It seems that there is some irq related patch I will try:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=935acd3f5ebc34984bd4de075e0f83e6ea10c28d

Well, that only solved the critical pinctrl problem. The other __setup_irq stayed there
and the mmc error as well.

Because I am not sure if there are more patches hidden in pull-requests, I
have merged the most current linus/master (still 4.13-rc1 :).

With that, it is a little better.

Just this remains:

[    1.854431] io scheduler noop registered
[    1.854461] io scheduler deadline registered
[    1.854614] io scheduler cfq registered (default)
[    1.854644] io scheduler mq-deadline registered
[    1.854675] io scheduler kyber registered
[    1.866455] ------------[ cut here ]------------
[    1.866577] WARNING: CPU: 0 PID: 1 at kernel/irq/manage.c:1360 __setup_irq+0x494/0x7d8
[    1.866607] Modules linked in:
[    1.866638] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.13.0-rc1-letux+ #1245
[    1.866668] Hardware name: Generic OMAP36xx (Flattened Device Tree)
[    1.866729] [<c010f698>] (unwind_backtrace) from [<c010bba8>] (show_stack+0x10/0x14)
[    1.866760] [<c010bba8>] (show_stack) from [<c075d5a8>] (dump_stack+0x98/0xd0)
[    1.866821] [<c075d5a8>] (dump_stack) from [<c012f4e0>] (__warn+0xd0/0x100)
[    1.866851] [<c012f4e0>] (__warn) from [<c012f5b4>] (warn_slowpath_null+0x1c/0x24)
[    1.866882] [<c012f5b4>] (warn_slowpath_null) from [<c01964f8>] (__setup_irq+0x494/0x7d8)
[    1.866912] [<c01964f8>] (__setup_irq) from [<c0196ab4>] (request_threaded_irq+0x1fc/0x28c)
[    1.866973] [<c0196ab4>] (request_threaded_irq) from [<c0474928>] (pcs_probe+0x660/0x7b8)
[    1.867004] [<c0474928>] (pcs_probe) from [<c04ec454>] (platform_drv_probe+0x50/0xa0)
[    1.867034] [<c04ec454>] (platform_drv_probe) from [<c04ea550>] (driver_probe_device+0x150/0x2d0)
[    1.867095] [<c04ea550>] (driver_probe_device) from [<c04ea758>] (__driver_attach+0x88/0xac)
[    1.867126] [<c04ea758>] (__driver_attach) from [<c04e8d6c>] (bus_for_each_dev+0x6c/0x90)
[    1.867156] [<c04e8d6c>] (bus_for_each_dev) from [<c04e9c3c>] (bus_add_driver+0xcc/0x1e8)
[    1.867187] [<c04e9c3c>] (bus_add_driver) from [<c04eb6fc>] (driver_register+0x9c/0xe0)
[    1.867248] [<c04eb6fc>] (driver_register) from [<c0101938>] (do_one_initcall+0xa8/0x150)
[    1.867279] [<c0101938>] (do_one_initcall) from [<c0b00d70>] (kernel_init_freeable+0x110/0x1d4)
[    1.867340] [<c0b00d70>] (kernel_init_freeable) from [<c076eab8>] (kernel_init+0x8/0x10c)
[    1.867370] [<c076eab8>] (kernel_init) from [<c01070f0>] (ret_from_fork+0x14/0x24)
[    1.867462] ---[ end trace 68411a648c7a2fe7 ]---
[    1.867706] pinctrl-single 48002030.pinmux: 284 pins at pa fa002030 size 568
[    1.869293] pinctrl-single 48002a00.pinmux: 46 pins at pa fa002a00 size 92
[    1.871124] pinctrl-single 480025a0.pinmux: 46 pins at pa fa0025a0 size 92
[    1.872192] pinctrl-single 480022d8.pinmux: please update dts to use #pinctrl-cells = <2>
[

And:

[   12.300262] mmcblk0: error -5 sending stop command, original cmd response 0x900, card status 0x900
[   12.300262] mmcblk0: error -5 transferring data, sector 15759352, nr 8, cmd response 0x900, card status 0x80000b00
[   12.300292] mmcblk0: retrying using single block read

coming several times. But not during normal operation. And not during ls -l / >/dev/null.

So I assume these bugs will be fixed by others soon...

Now we can start to focus on "our" things.

BR,
Nikolaus