| Summary: | [ivb] memory corruption after kexec | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Jiri Slaby <jirislaby> | ||||||
| Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||
| Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||
| Severity: | normal | ||||||||
| Priority: | medium | ||||||||
| Version: | unspecified | ||||||||
| Hardware: | Other | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | ||||||||
| Attachments: |
|
||||||||
We probably need to restore the GTT PTEs to the values the BIOS expects - otherwise vesafb will scribble all over memory ... For fun, can you please attach the complete dmesg of the kexec'ed kernel? Just to figure out whether it really might be vesafb/efifb scribbling all over main memory ... Created attachment 74636 [details]
dmesg from kexec run
Sorry for the long delay here, but I still don't have an idea. Can you please retest on latest upstream drm-intel-nightly or linux-next trees please? I wonder if we need to do a TLB flush for the PDE as well. Is there such a beast, or maybe it is just part of the ring TLBs? I would certainly retest with https://patchwork.kernel.org/patch/2839512/ Ping for test results. Note that the patch Chris referenced is merged already. (In reply to comment #6) > Ping for test results. Note that the patch Chris referenced is merged > already. Ok, I'm running 3.11 already. I will try if it works... (In reply to comment #7) > (In reply to comment #6) > > Ping for test results. Note that the patch Chris referenced is merged > > already. > > Ok, I'm running 3.11 already. I will try if it works... It seems so... |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 73071 [details] lspci -vvnnxxxs 2.0 Using KMS, when I kexec from kernel 3.7.2 (to the same one), memory gets corrupted. I see 0x0720 (white space on a black background) all over the structures. I do not start X at all. This is a pure fb console. My IOMMU also complains in the kexec'ed kernel: dmar: DRHD: handling fault status reg 3 dmar: DMAR:[DMA Read] Request device [00:02.0] fault addr fffff000 DMAR:[fault reason 06] PTE Read access is not set This happens until i915 is loaded in the new kernel: dmar: DRHD: handling fault status reg 3 dmar: DMAR:[DMA Read] Request device [00:02.0] fault addr ff34c000 DMAR:[fault reason 06] PTE Read access is not set [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5 fbcon: inteldrmfb (fb0) is primary device <here it stops to access invalid memory> There is no pci_driver->shutdown method and there apparently should be one that stops the card in some manner. I tried to add the .shutdown hook which did the same as .remove, but it had no effect. It was a shot in the dark though.