Re: Bug reports on 830MG patches (thanks, but more trouble)

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Fri, Jun 06, 2014 at 07:24:02PM +0200, Thomas Richter wrote:
> Hi Ville, hi others,
> 
> >> As Ville already said, resume from "suspend-to-ram" is broken. No
> >> surprise, old broken bios. However, there is a big difference between
> >> the kernel with the pipe-A quirk disabled, and the one with pipe-a and
> >> pipe-b quirks enabled: If resumed without the quirk, the display is
> >> dead, but you can at least re-initiate it with vbetool post, then
> >> restart the X server. So at least, the kernel is working.
> >>
> >> With the pipe A quirk enabled, something dies immediately when
> >> attempting to resume from suspend. The machine is completely
> >> unresponsive, also not reachable over the network. The kernel dies away.
> >
> > For me resume gets stuck even w/o i915. So something is different
> > clearly between our machines. Might be some driver, or might the BIOS.
> > Do you have the latest BIOS on that thing?
> 
> 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.

> 
> There is a difference between "freeze" and "freeze". Yes, w/o the pipe-A 
> quirk, the screen goes black, but you can reach it over the network, and 
> you can even type into the console and submit the video restart from 
> there. So, it's not frozen, only the display is "off", though it looks 
> the same for the untrained eye.

My eye is well trained, sir.

> 
> Maybe the bios configuration between yours and mine is different?

I tried disabling everything extra from the BIOS. No dice.

> 
> >> This is *probably* related to the dying kernel when booting with vga=792
> >> (or vga=791 or vga=790, all cause the same problem, no working machine.)
> >
> > I must admit I didn't try the vga= options. I'll give them a go and see
> > what happens.
> 
> Please do. I have narrowed it down to the case where text mode vs. 
> graphics mode makes a difference. That is, a frame buffer console alone 
> is sufficient for the machine to get stuck when loading i915.

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

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.

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.
Although the fact that you don't need to do it makes it even stranger. 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.
Otherwise the machine works pretty decently for me now.

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

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

-- 
Ville Syrjälä
Intel OTC