Comment 66 for bug 91966

Revision history for this message
Jamie Lokier (jamie-shareable) wrote :

Phi wrote:
> This works for me as far as suspend/resume goes (yay!), but oddly I
> still get the artefact if I let GRUB time out when booting. It makes me
> wonder what's different between booting normally, and having a timer run
> out, then booting. Perhaps it's a separate issue from this bug.

Amazingly, I've just noticed the same thing.

All my tests when I wrote that long post were from cold boot, after
power cycling, but I always booted from GRUB without waiting for the
timout.

It's hard to think of any difference that may cause.

Today, I happened to do a power cycle again (battery flat), and this
time I let GRUB boot timeout out and... now I have the corrupt
row of pixels on my screen, from a fresh boot without suspending.

I've attached the register dump. This is after booting from GRUB with timeout, (then some probably irrelevant distractions involving single user mode), then to X. X started showing the same picture on internal and external displays. Then I did xrandr to start dual head, and saw the corrupt half-row of pixels. Previously xrandr hasn't changed the page table entries, so I'd guess it hasn't this time.

The register dump shows the usual anomaly at page table 1537, set to 0x83ffbe001, the same as entry 1982 (where it's the end of a series and looks normal).

Interestingly, unlike the state after suspend/resume/POST, entries 1537 and 1982 are the _only_ places where this value appears. Whereas suspend/resume/POST causes that value to appear in lots of entries.

Before I was beginning to suspect the VESA BIOS, but now I'm beginning to suspect the kernel again...

Phi, would you care to do some more tests to see if GRUB timeout _repeatably_ makes the difference?