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

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

On Fri, Jun 06, 2014 at 11:09:53PM +0200, Thomas Richter wrote:
> Am 06.06.2014 22:08, schrieb Ville Syrjälä:
> >> 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.

Hmm. I don't think I tried the pnp os option. I'll give it a go next
week in case it has some effect.

> 
> > 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.

Just restarting X has some risk in case the vbetool POST clobbered some
state that i915 only sets up at init or resume.

> Did you notice that intel_reg_snapshot just dies when you try?

No, in fact never tried that tool.

> 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.

Oh, great.

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

Daniel was threatening to resurrect his watermark branch. But I don't
really see a problem with going with a temporary fix in the meantime
maybe even only for 830.

> > 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?

I pushed just before sending the email. I think what you have is
alm_fixes4, which indeed did blow up with vga= for me as well.
alm_fixes5 should fare better.

-- 
Ville Syrjälä
Intel OTC