Bug 1494138
Summary: | crashes in wayland/Xorg on vc4 with 4.13 with the Raspberry Pi | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Peter Robinson <pbrobinson> | ||||||
Component: | kernel | Assignee: | Peter Robinson <pbrobinson> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | unspecified | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 27 | CC: | airlied, ajax, bskeggs, eparis, esandeen, fzatlouk, hdegoede, ichavero, itamar, jarodwilson, jforbes, jglisse, jonathan, josef, jwboyer, kernel-maint, kparal, labbott, linville, mchehab, mjg59, nhorman, pbrobinson, quintela, robatino, steved, sumukher | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | AcceptedBlocker | ||||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2017-09-27 16:29:52 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 245418, 1396702 | ||||||||
Attachments: |
|
Description
Peter Robinson
2017-09-21 14:15:31 UTC
Proposed as a Blocker for 27-beta by Fedora user pbrobinson using the blocker tracking app because: Raspberry Pi is an ARMv7 (and aarch64, but that arch isn't currently blocking) blocking device. Discussed during blocker review [1]: AcceptedBlocker (beta) - This bug can prevent initial-setup to finish. This violates the Alpha criterion: "A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system." [1] https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2017-09-21/ Finishes initial setup and boots into wayland with 4.13-300. Sumantro, please note that the previous kernel /occasionally/ crashed. The difference will be only visible after a longer time using it, I believe. Kparal , I have used this for more than a day now , It doesnt crash . Maybe , I will test it for couple of ore days I've experienced crashes in drm during boot to DE (no graphical output). kernel 4.13.3-300 Created attachment 1331023 [details]
Boot log
Created attachment 1331024 [details]
drm crash log
Same issue happens with kernel-4.13.3-301.fc27 . I am not able to boot into DE. Video output stops working around: [ 57.087946] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 57.088274] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 57.088609] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops [vc4]) Activating swap /dev/disk/by-uuid/5…63d-17e2-4f7c-9518-2bbc8e8b0bf1... [ 57.175147] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops [vc4]) [ 57.175168] checking generic (3e8f1000 10a800) vs hw (0 ffffffff) [ 57.175178] fb: switching to vc4drmfb from simple [ 57.213103] Console: switching to colour dummy device 80x30 [ 57.226446] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0 [ 57.233374] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 57.240219] [drm] Driver supports precise vblank timestamp query. [ 57.314057] alloc_contig_range: [33100, 338e9) PFNs busy Following with errors posted previously. Tested with https://kojipkgs.fedoraproject.org/compose/27/Fedora-27-20170925.0/compose/Spins/armhfp/images/Fedora-Xfce-armhfp-27_Beta-1.3-sda.raw.xz Please do NOT change the status of the bug not assigned to you František the crash you're seeing is completely unrelated to this bug, it's due to problematic monitors and is covered in RHBZ 1387733 Ok, sorry for the noise here. Peter, we need some confirmation that this is fixed. Sumantro so far said he didn't see any errors, I'd like to see more. Can you please confirm the new kernel fixed this particular problem on your system? Especially since we can't confirm this on our hardware. Thanks. (In reply to Peter Robinson from comment #12) > Please do NOT change the status of the bug not assigned to you I told Frantisek to change the status. It's a standard QA (and development) practice to switch the status back to assigned when the fix seems to be not working. I've never heard of the notion that status field can't be touched by someone else than the assignee. That would quite complicate QA processes. (In reply to Kamil Páral from comment #15) > Peter, we need some confirmation that this is fixed. Sumantro so far said he > didn't see any errors, I'd like to see more. Can you please confirm the new > kernel fixed this particular problem on your system? Especially since we > can't confirm this on our hardware. Thanks. Yes, I can report/confirm that it fixes the problems I saw, I basically had confirmed that it fixed the problem when I requested it as a blocker. > (In reply to Peter Robinson from comment #12) > > Please do NOT change the status of the bug not assigned to you > > I told Frantisek to change the status. It's a standard QA (and development) > practice to switch the status back to assigned when the fix seems to be not > working. I've never heard of the notion that status field can't be touched > by someone else than the assignee. That would quite complicate QA processes. The problem he reported was completely unrelated to this bug, it shouldn't be changed by the person until it is actually *confirmed* that it's related. (In reply to Peter Robinson from comment #16) > Yes, I can report/confirm that it fixes the problems I saw, I basically had > confirmed that it fixed the problem when I requested it as a blocker. Thanks. Actually, the kernel is already stable, so closing this. |