[Intel-gfx] Bug reports on 830MG patches (thanks, but more trouble)

[Thomas Richter]

Am 06.06.2014 22:08, schrieb Ville Syrjälä:

>> Yup, I flashed the bios last week with version 1.07, the latest I could
>> find on the Fujitsu pages. It was 1.06 before, though I did not observe
>> any difference between 1.06 and 1.07 with respect to the broken resume
>> operation.
>
> 1.07 is what have as well.

Ok, great.

>> Maybe the bios configuration between yours and mine is different?
>
> I tried disabling everything extra from the BIOS. No dice.

As said, only with the pipe a quirk removed... I had "plug & play os" 
enabled, and the "security screen on resume" disabled.

> OK, so I posted a few revised patches, and three new ones. With these my
> S6010 can resume from S3 if and only if:
> 1. pass acpi_sleep=s3_bios to the kernel command line
> 2. unload i915 before suspending

This is as good as I had it without the pipe A quirk as well. Unloading 
i915 worked as well: I had to post the GPU, then either reload i915 or 
restart X.

> 1. I guess is expected since you also had to use vbetool to post the
> GPU. Having the kernel do it is better since then you can't clobber the
> state while i915 is already doing stuff.

Yes.

> 2. is more strange. I assume there must be some magic difference between
> our suspend vs. unload and/or resume vs. init codepaths that cause problems.

Likely.

> Although the fact that you don't need to do it makes it even stranger.

Not exactly, see above. Reloading i915 works as well, but otherwise you 
had to stop X, then restart X, then re-set the resolution to ensure that 
everything is configured correctly.

> I tried to use the pm_trace facility a bit bit didn't really get anywhere.
> So given that this thing is a dinosaur I think I'll now leave it and either
> let someone else figure it out or come back to it when I'm really bored.

resume from suspend is not really much an issue. suspend to disk works 
fine, and there is likely a bios problem.

Did you notice that intel_reg_snapshot just dies when you try? Also, if 
you check the bootlogs, some I/O regions seem to overlay. Probably 
resume tries to reload the same I/O addresses intel_reg_snapshot tries 
to save? vbetool vbestate save also hangs the machine...

> Otherwise the machine works pretty decently for me now.

Yes, with the watermark settings in place - from your repository - 
everything is as good as it gets.

Could you please create a patch for intel_calculate_wm() that adjusts 
wm_size, probably depending on GEN2?


> I think the reason why killing the pipe A quirk might have made a
> difference for you was the fact that i915 no longer registered the VGA
> port and so the DVO port always stayed assigned to pipe A. But if you'd
> just applied the "ignore VBT" patch and gotten the VGA port back, things
> would have failed again rather nicely especially when trying to use both
> pipes.
>
> I pushed the new patches to [1] and I still included the watermark hack,
> and there's an additional locking fix you'll want as well.
>
> [1] git://gitorious.org/vsyrjala/linux.git alm_fixes5

That is what I pulled probably two hours ago. It still has the issue 
with dying with vga=792 as boot parameter. When did you submit?


> So apart from the remaining S3 resume mystery the minimum watermark
> problem is still to be solved. I think Chris's idea of converting
> the .default_wm parameter to a minimum watermark level is sane. But in
> order to do that I think we should do these things:
> - s/.default_wm/.min_wm/
> - Replace the current .default_wm values with "burst size" (maybe with +1)
>    Some of the current .default_wm values make absolutely no sense as a
>    minimum value (pnv at least has 0x3f there!)
> - Someone should maybe figure out why we use a larger burst size on
>    845/865 than on the other platforms

I guess I do have a couple of additional intel based machines here if 
that is of help. A 945 based board is here, and some later machines.

Thanks!

Greetings,
	Thomas