From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: Bug reports on 830MG patches (thanks, but more trouble) Date: Sat, 7 Jun 2014 00:41:42 +0300 Message-ID: <20140606214142.GI27580@intel.com> References: <1401984964-25441-1-git-send-email-ville.syrjala@linux.intel.com> <1401984964-25441-2-git-send-email-ville.syrjala@linux.intel.com> <20140605204312.GA15324@nuc-i3427.alporthouse.com> <5390E243.2040100@rus.uni-stuttgart.de> <20140606084621.GF27580@intel.com> <5391F932.8010404@rus.uni-stuttgart.de> <20140606200814.GH27580@intel.com> <53922E21.1060704@rus.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by gabe.freedesktop.org (Postfix) with ESMTP id E8AF46E400 for ; Fri, 6 Jun 2014 14:41:46 -0700 (PDT) Content-Disposition: inline In-Reply-To: <53922E21.1060704@rus.uni-stuttgart.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Thomas Richter Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Fri, Jun 06, 2014 at 11:09:53PM +0200, Thomas Richter wrote: > Am 06.06.2014 22:08, schrieb Ville Syrj=E4l=E4: > >> 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=3Ds3_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=3D792 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=3D for me as well. alm_fixes5 should fare better. -- = Ville Syrj=E4l=E4 Intel OTC