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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
