Date:	Sat, 27 Dec 2014 09:19:49 +0100
From:	Pali Rohár <pali.rohar@...il.com>
To:	nick <xerofoify@...il.com>
Cc:	Daniel Vetter <daniel.vetter@...el.com>,
	Jani Nikula <jani.nikula@...ux.intel.com>,
	David Airlie <airlied@...ux.ie>,
	intel-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
	linux-kernel@...r.kernel.org,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Len Brown <lenb@...nel.org>, linux-acpi@...r.kernel.org,
	Bjorn Helgaas <bhelgaas@...gle.com>, linux-pci@...r.kernel.org,
	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Subject: Re: [Intel-gfx] 3.19-rc1 errors when opening LID

Hello,

in attachment is output of ls -l /sys/bus/acpi/devices from both 
3.13 and 3.19 kernels.
 
Anyway Gabriele Mazzotta wrote me that new acpi devices could be 
created after commit faae404ebdc6bba (ACPICA: Add "Windows 2013" 
string to _OSI support).

Maybe this another output could help you:

$ cat /sys/bus/acpi/devices/INT33C5\:00/status
0
$ cat /sys/bus/acpi/devices/INT33C5\:00/power_state
(unknown)

Device INT33C5 is in that dmesg log:
acpi INT33C5:00: Cannot transition to non-D0 state from D3

And status 0 in sysnode could indicate that acpi device is not 
present right?

On Thursday 25 December 2014 17:59:36 nick wrote:
> Pali,
> This was probably to either add better power management or
> enable some new features related to acpi. Can you send me the
> files they created in kernel 3.19 r1 as I can probably trace
> it back to the bad commit. Regards Nick
> 
> On 2014-12-25 03:48 AM, Pali Rohár wrote:
> > I know how to use git... first I wanted to report errors
> > because maybe it could be known problem or somebody else
> > can come with quick patch even without bisetcing (like for
> > other problems which I reported).
> > 
> > Anyway those acpi devices which are mentioned in log do not
> > exist in 3.13 kernel (I do not see them in /sys/devices)
> > 
> > Any idea why 3.19 kernel create new acpi devices which 3.13
> > kernel did not?
> > 
> > On Thursday 25 December 2014 05:28:27 nick wrote:
> >> Pali,
> >> Do you known how to run git bisect as this is probably the
> >> best way to continue. Otherwise, I can teach you how it's
> >> not hard if your willing to learn :). Cheers Nick
> >> 
> >> On 2014-12-24 01:51 PM, Pali Rohár wrote:
> >>> Hello!
> >>> 
> >>> With new 3.19-rc1 kernel every time when I open LID on my
> >>> laptop, kernel prints these error lines to dmesg:
> >>> 
> >>> [25566.368133] [drm:hsw_unclaimed_reg_detect.isra.6
> >>> [i915]] *ERROR* Unclaimed register detected. Please use
> >>> the i915.mmio_debug=1 to debug this problem.
> >>> [25566.368134] [drm:intel_uncore_check_errors [i915]]
> >>> *ERROR* Unclaimed register before interrupt
> >>> [25566.368192]
> >>> [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR*
> >>> Unclaimed register detected. Please use the
> >>> i915.mmio_debug=1 to debug this problem. [25566.368232]
> >>> [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR*
> >>> Unclaimed register detected. Please use the
> >>> i915.mmio_debug=1 to debug this problem.<4>[25568.446011]
> >>> i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has
> >>> bogus alignment
> >>> [25568.447018] pci_bus 0000:02: Allocating resources
> >>> [25568.447055] pci_bus 0000:03: Allocating resources
> >>> [25568.447135] pci_bus 0000:04: Allocating resources
> >>> [25568.447168] pci_bus 0000:05: Allocating resources
> >>> [25568.447195] pci_bus 0000:06: Allocating resources
> >>> [25568.447228] pci_bus 0000:0e: Allocating resources
> >>> [25568.447323] i915 0000:00:02.0: BAR 6: [??? 0x00000000
> >>> flags 0x2] has bogus alignment [25568.447557] i915
> >>> 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus
> >>> alignment [25568.447735] i915 0000:00:02.0: BAR 6: [???
> >>> 0x00000000 flags 0x2] has bogus alignment [25568.447847]
> >>> i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has
> >>> bogus alignment [25568.448399] i915 0000:00:02.0: BAR 6:
> >>> [??? 0x00000000 flags 0x2] has bogus alignment
> >>> [25568.448438] i915 0000:00:02.0: BAR 6: [??? 0x00000000
> >>> flags 0x2] has bogus alignment [25568.448566] acpi
> >>> MSFT1111:00: Cannot transition to power state D3cold for
> >>> parent in (unknown) [25568.448572] acpi INT33C2:00: Cannot
> >>> transition to non-D0 state from D3 [25568.448577] acpi
> >>> MSFT0002:00: Cannot transition to power state D3cold for
> >>> parent in (unknown) [25568.448581] acpi ELAN1010:00:
> >>> Cannot transition to power state D3cold for parent in
> >>> (unknown) [25568.448587] acpi INT33C3:00: Cannot
> >>> transition to non-D0 state from D3 [25568.448590] acpi
> >>> INT33C0:00: Cannot transition to non-D0 state from D3
> >>> [25568.448594] acpi INT33C1:00: Cannot transition to
> >>> non-D0 state from D3 [25568.448598] acpi INT33C4:00:
> >>> Cannot transition to non-D0 state from D3 [25568.448602]
> >>> acpi INT33C5:00: Cannot transition to non-D0 state from
> >>> D3 [25568.448623] acpi device:41: Cannot transition to
> >>> power state D3cold for parent in (unknown) [25568.448627]
> >>> acpi INT33C6:00: Cannot transition to non-D0 state from
> >>> D3 [25568.448890] pci_bus 0000:01: Allocating resources
> >>> [25568.448905] i915 0000:00:02.0: BAR 6: [??? 0x00000000
> >>> flags 0x2] has bogus alignment [25568.449064] i915
> >>> 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus
> >>> alignment [25568.449472] i915 0000:00:02.0: BAR 6: [???
> >>> 0x00000000 flags 0x2] has bogus alignment
> >>> 
> >>> With older kernel (3.13) I do not see these errors, so it
> >>> is regression. Can you look at it? If it is needed, I can
> >>> provide other logs, ACPI/DSTD dumps, etc.
> >>> 
> >>> 
> >>> 
> >>> _______________________________________________
> >>> Intel-gfx mailing list
> >>> Intel-gfx@...ts.freedesktop.org
> >>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Pali Rohár
pali.rohar@...il.com

View attachment "acpi_devices_3.13.0-44-generic" of type "text/plain" (16199 bytes)

View attachment "acpi_devices_3.19-rc1-generic" of type "text/plain" (22082 bytes)

Download attachment "signature.asc " of type "application/pgp-signature" (199 bytes)

Powered by blists - more mailing lists