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.

Sign up for GitHub

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

Jump to bottom

: 0x00000080[drm:gen8_de_irq_handler] Fault errors on pipe A #39

Closed
dirkx opened this issue Mar 9, 2018 · 12 comments
Closed

: 0x00000080[drm:gen8_de_irq_handler] Fault errors on pipe A #39

dirkx opened this issue Mar 9, 2018 · 12 comments
Labels
4.11 bug suspend/resume

Comments

@dirkx
Copy link

dirkx commented Mar 9, 2018

Akin to the reports on:

trueos/trueos-core#387
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226002

Corrupted screen upon wakeup from suspend; with 1000's of messages in dmesg as per below. Recent FreeBSD12, drm-next-kmod-4.11.g20180224 , gpu-firmware-kmod-g20180206_1.


Mar  9 14:02:43 water kernel: : 0x00000080[drm:gen8_de_irq_handler] Fault errors on pipe A
Mar  9 14:02:43 water kernel: : 0x00000080[drm:gen8_de_irq_handler] Fault errors on pipe A
Mar  9 14:02:43 water kernel: : 0x00000080
Mar  9 14:02:43 water kernel: [drm:gen8_de_irq_handler] Fault errors on pipe A
Mar  9 14:02:43 water kernel: : 0x00000080[drm:gen8_de_irq_handler] Fault errors on pipe A
@dirkx
Copy link
Author

dirkx commented Mar 9, 2018

It seems there is a slight variation; when suspending very soon after boot or when just running just X (and nothing else; gray screem with the cursor) -- one can see in dmsg below. With obviously the X server going south wih a ```(EE) no screens found(EE)'''.

Timeout initializing vt_vga
Timeout initializing vt_vga
Timeout initializing vt_vga
Timeout initializing vt_vga
Timeout initializing vt_vga

@johalun
Copy link
Member

johalun commented Mar 9, 2018

revision=330236 has a fix for resume. What is your revision?

@dirkx
Copy link
Author

dirkx commented Mar 9, 2018 via email

@dirkx
Copy link
Author

dirkx commented Mar 9, 2018 via email

@johalun
Copy link
Member

johalun commented Mar 9, 2018

What hardware is this?
A fix might be a while so until the drm-stable-kmod (4.9) package is out, you can revert by building from source
https://github.com/FreeBSDDesktop/kms-drm/tree/drm-v4.9

Or, if you're feeling adventurous, you can try the v4.12 branch. It's more or less as stable as 4.11 at this point but you'll need kernel revision>=330689 (which you have).
https://github.com/FreeBSDDesktop/kms-drm/tree/drm-v4.12

@dirkx
Copy link
Author

dirkx commented Mar 9, 2018 via email

@johalun
Copy link
Member

johalun commented Mar 9, 2018

Here FreeBSDDesktop/DEPRECATED-freebsd-base-graphics#149 is an old discussion about the latest firmware causing issues. Can you try uninstalling the firmware package and try? This will make it fall back to the built-in default firmware.

@johalun
Copy link
Member

johalun commented Mar 9, 2018

And don't forget to try with sysctl hw.acpi.reset_video=1 if you don't have it.

@dirkx
Copy link
Author

dirkx commented Mar 9, 2018

To add to above - i915 kernel was loaded by the kld_list in rc.conf (as opposed to boot/loader) as per the wiki instructions.

Removed with a pkg '-f' as to ensure that its upstream dependency `drm-next-kmod-4.11.g20180224' is not also removed (i.e. that was overwritten by my build from git of drm-v4.12).

Checked that the files are gone from /boot/kernel (oddly enough some rademonkmsfw seems to be left behind). but for the drm-v4.12 build i915.ko.

dmesg shows during boot (just):

info: [drm] Initialized drm 1.1.0 20060810

so I am wondering if it actually activates and takes over the framebuffer. Post suspend the screen does not come back - but a reset_video=1 at that time now turns on the backlight and brings the vertical lines backup. The kernel messages are now a slow handlful of

Timeout initializing vt_vga

as opposed to the fast ' [drm:gen8_de_irq_handler] Fault errors on pipe A: 0x00000080'.

Reinstalling the firmware and trying just the reset=1 did not make any difference.

As an aside - I noticed upon re-installing with 'pkg install gpu-firmware-kmod-g20180206_1' against the i195.ko build by the drm-v4.12 several errors as per below:

kldxref: error while reading //boot/modules/i915_kbl_huc_ver02_00_1810_bin.ko: Bad address

@dirkx
Copy link
Author

dirkx commented Mar 9, 2018 via email

@johalun
Copy link
Member

johalun commented Mar 9, 2018 •
edited
Loading

info: [drm] Initialized drm 1.1.0 20060810

Make sure i915kms does not load /boot/kernel/drm.ko as a dependency. In my custom kernels I never even build drm that's in kernel.

To be extra sure, use
kld_list="/boot/modules/drm.ko /boot/modules/i915kms.ko"

Or just delete drm.ko and graphics drivers that are in /boot/kernel/....

@dirkx
Copy link
Author

dirkx commented Mar 9, 2018 via email

@johalun johalun closed this as completed May 14, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
4.11 bug suspend/resume
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@dirkx @johalun