drm/ast something ate high-res modes (5.3->5.6 regression)

[Ilpo Järvinen]

On Wed, 14 Oct 2020, Thomas Zimmermann wrote:
> On Wed, 14 Oct 2020 09:58:37 +0300 (EEST) "Ilpo Järvinen"
> <ilpo.jarvinen at cs.helsinki.fi> wrote:
> 
> > The high-res mode works, however, I wasn't expecting it to be this slow 
> > though as I can see the slowish sweeps to redraw the screen or large parts 
> > of it. Maybe you meant all along this slow (I was expecting something like 
> > memcpy slow and this looks definitely much slower)?
> 
> First of all, thanks for testing. I didn't expect it to be that slow either.
> 
> > 
> > While a large redrawing operation is going on, mouse cursor stops moving 
> > normally until it is over and it then jumps to catch up. When the mouse is 
> > over something that doesn't require large redraw, it seems to work quite 
> > normally.
> > 
> 
> That sounds bad. The cursor is drawn by hardware, so I'd expect it to move
> smoothly across the screen. Maybe the position update is blocked from the
> framebuffer's memcpy within the kernel code.
> 
> I was hoping the performance would be acceptable, but this sounds like a
> dealbreaker to me. I can look a bit closer if there are issues/bugs in the
> code that make it run slow. Not holding my breath for it though...

Yeah, with like 5fps with full redraw it's not really acceptable (it's a 
bit hard to estimate exactly but certainly less than 10fps). Writing to 
video mem / normally working memcpy itself really cannot be this slow as 
it would impact fps in non-shmem case too I think.

Also, there's more into this. I noticed that after using this kernel,
I cannot boot normally neither warm nor even cold boot after poweroff 
(POST is slower than usual, beeps one less and gets stuck, I didn't 
manage to switch into textual POST messages to see if there's any info as 
the tab key for swithing got also broken). Sadly those beeps don't match 
to the motherboard manual in ok nor broken case so I've no idea what they 
mean and whether the beeps really related to POST or e.g. from graphics 
init.

Only after cutting power entirely from the machine, the boot again 
succeeds. To me those symptoms sounds like it somehow managed to break 
something related to IPMI because IPMI is reinitialized only if I remove 
the power. If I've understood correctly IPMI is somehow connected to 
graphics side within the AST.

I haven't yet tested with the plain 5.9-rc5 to rule out it breaking 
the boot (but I find it less likely to be case here).


-- 
 i.