Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

kernel BUG at kernel/sched/deadline ? #233

Open
MagnaboscoL opened this issue May 21, 2020 · 5 comments
Open

kernel BUG at kernel/sched/deadline ? #233

MagnaboscoL opened this issue May 21, 2020 · 5 comments
Labels

Comments

@MagnaboscoL
Copy link

MagnaboscoL commented May 21, 2020

Hi,

I am just starting to test a "custom distro" I have made using this kernel and Yocto.
I am facing a "kernel BUG" I cannot understand.

Using:

Hardware:

When I start Weston touch screen calibration I get:

[   63.286156] 000: kernel BUG at kernel/sched/deadline.c:1495!
[   63.291842] 000: Internal error: Oops - BUG: 0 [#1] PREEMPT_RT SMP ARM
[   63.298400] 000: Modules linked in:
[   63.301902] 000:  pvrsrvkm(O)
[   63.304877] 000:  joydev
[   63.307415] 000:  evdev
[   63.309866] 000:
[   63.311798] 000: CPU: 0 PID: 644 Comm: weston Tainted: G           O      5.4.20 #1
[   63.319491] 000: Hardware name: Generic AM33XX (Flattened Device Tree)
[   63.326044] 000: PC is at enqueue_task_dl+0x90/0xd8c
[   63.331054] 000: LR is at rt_mutex_setprio+0x358/0x568
[   63.336223] 000: pc : [<c018c014>]    lr : [<c01754d4>]    psr: 20000093
[   63.342950] 000: sp : da4afa58  ip : da4afb20  fp : da4afb1c
[   63.348630] 000: r10: df926140  r9 : dc32c420  r8 : 00000001
...

Pleased find attached the entire log
bug_log.txt

Note: attached log has been captured when starting the touch screen calibration, but I got the very same bug with an image without Weston at the end of ts_calibrate from tslib.

Considerations

  1. if I use the kernel linux-ti-staging-rt-5.4 from TI it seems that the issue disappears. Therefore I suppose that I am not configuring this kernel properly.

  2. I suppose that the issue is independent form the applications I was runnig and maybe related to some wrong compilation settings (that probably influenced the module pvrsrvkm.ko), but for the moment I am quite clueless.

  3. I am not sure that this is worth mentioning but, since the DRM seems to be involved the details about libdrm I am using are:

Any hint would be very appreciated.

Regards
Luca

@pdp7
Copy link
Contributor

pdp7 commented Jun 10, 2020

@jadonk @RobertCNelson do you have the Seeed LCD cape? Maybe we could ask one of the Seeed engineers to check?

@RobertCNelson
Copy link
Member

This needs to be retested, early 5.4 versions where not being tested.

@pdp7
Copy link
Contributor

pdp7 commented Jun 10, 2020

@Pillar1989 are you able to test the Seeed BeagleBone Green LCD Cape mentioned in this issue?

@pdp7 pdp7 added the green BeagleBone Green label Jun 10, 2020
@Pillar1989
Copy link

@pdp7 not yet. we tested it on version 4.19.

@MagnaboscoL
Copy link
Author

MagnaboscoL commented Jun 12, 2020

Hi @pdp7,

I have a Yocto setup that seems to work* with this LCD Cape.
At the moment I am using TI kernel and I could switch kernel for testing.
Please let me know if you think I could do something to speed up the testing.

*Just to give complete info: It seems to work but I am still facing a color issue when using the GPU for QT apps as described in e2e.ti.com. Anyway that could probably be unrelated to the tests needed for this issue.

Regards

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants