Re: [PATCH v6 44/80] docs: gpu: i915.rst: Fix several C duplication warnings

[Lionel Landwerlin]

On 13/10/2020 14:53, Mauro Carvalho Chehab wrote:

As reported by Sphinx:

./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1147: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_oa_wait_unlocked'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1169: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_oa_poll_wait'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1189: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_oa_read'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:2669: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_oa_stream_enable'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:2734: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_oa_stream_disable'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:2820: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_oa_stream_init'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3010: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_read'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3098: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_poll_locked'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3129: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_poll'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3152: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_enable_locked'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3181: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_disable_locked'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3273: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_ioctl'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3296: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_destroy_locked'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3321: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_release'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3379: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_open_ioctl_locked'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3534: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'read_properties_unlocked'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3717: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_open_ioctl'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3760: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_register'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3789: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_unregister'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:4009: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_add_config_ioctl'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:4162: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_remove_config_ioctl'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:4260: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_init'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:4423: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_perf_fini'.

With Sphinx 3, C declarations can't be duplicated anymore,
so let's exclude those from the other internals found on
i915_perf.c file.

Signed-off-by: Mauro Carvalho Chehab 

Reviewed-by: Lionel Landwerlin 

---
  Documentation/gpu/i915.rst | 29 +
  1 file changed, 25 insertions(+), 4 deletions(-)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 33cc6ddf8f64..cff1f154b473 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -636,15 +636,36 @@ i915 Perf Observation Architecture Stream
  .. kernel

Re: [PATCH v6 44/80] docs: gpu: i915.rst: Fix several C duplication warnings

[Lionel Landwerlin]

On 16/10/2020 14:50, Jani Nikula wrote:

On Fri, 16 Oct 2020, Lionel Landwerlin  wrote:

On 16/10/2020 14:37, Mauro Carvalho Chehab wrote:

Em Fri, 16 Oct 2020 14:01:07 +0300
Joonas Lahtinen  escreveu:


+ Lionel

Can you please take a look at best resolving the below problem.

Maybe we should eliminate the duplicate declarations? Updating such
a list manually seems error prone to me.

For Kernel 5.10, IMO the best is to apply this patch as-is, as any
other thing would need to be postponed, and we want 5.10 free of
doc warnings.


That's odd... Most of the functions are documented. Is it that we're
missing the "()" after the function name maybe?

The problem is we first include named functions, and then go on to
include everything again, duplicating the documentation for the named
functions.

BR,
Jani.



Thanks, now the patch makes sense.


-Lionel







-Lionel



Yet, when I wrote this one, I almost took a different approach:
to implement something like @*group (or \*group) directives that
exists on doxygen:

https://www.doxygen.nl/manual/grouping.html

If something like that gets added to kernel-doc syntax, then
one could do something like:

/**
 * DOC: some foo description
 * @group foo
 */
   
	/**

 * foo1 - do some foo things
 * @group foo
...
 */

/**
 * foo2 - do some other foo things
 * @group foo
...
 */

/**
 * bar - do bar things
 * @group bar
...
 */


And then, at kernel-doc markup:

FOO
===

.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
:group: foo


BAR
===
.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
:group: bar


I suspect that something like that would be a lot easier to maintain.

Once having someone like that implemented, it should be easy to also
have something like this:

OTHERS
==
.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
:export:
:not-grouped:

in order to pick other functions that aren't grouped.

I suspect that implementing something like that at kernel-doc.pl
won't be hard.

Regards,
Mauro


Regards, Joonas

Quoting Mauro Carvalho Chehab (2020-10-13 14:53:59)

As reported by Sphinx:

  ./Documentation/gpu/i915:646: 
./drivers/gpu/drm/i915/i915_perf.c:1147: WARNING: Duplicate C declaration, also 
defined in 'gpu/i915'.
  Declaration is 'i915_oa_wait_unlocked'.
  ./Documentation/gpu/i915:646: 
./drivers/gpu/drm/i915/i915_perf.c:1169: WARNING: Duplicate C declaration, also 
defined in 'gpu/i915'.
  Declaration is 'i915_oa_poll_wait'.
  ./Documentation/gpu/i915:646: 
./drivers/gpu/drm/i915/i915_perf.c:1189: WARNING: Duplicate C declaration, also 
defined in 'gpu/i915'.
  Declaration is 'i915_oa_read'.
  ./Documentation/gpu/i915:646: 
./drivers/gpu/drm/i915/i915_perf.c:2669: WARNING: Duplicate C declaration, also 
defined in 'gpu/i915'.
  Declaration is 'i915_oa_stream_enable'.
  ./Documentation/gpu/i915:646: 
./drivers/gpu/drm/i915/i915_perf.c:2734: WARNING: Duplicate C declaration, also 
defined in 'gpu/i915'.
  Declaration is 'i915_oa_stream_disable'.
  ./Documentation/gpu/i915:646: 
./drivers/gpu/drm/i915/i915_perf.c:2820: WARNING: Duplicate C declaration, also 
defined in 'gpu/i915'.
  Declaration is 'i915_oa_stream_init'.
  ./Documentation/gpu/i915:646: 
./drivers/gpu/drm/i915/i915_perf.c:3010: WARNING: Duplicate C declaration, also 
defined in 'gpu/i915'.
  Declaration is 'i915_perf_read'.
  ./Documentation/gpu/i915:646: 
./drivers/gpu/drm/i915/i915_perf.c:3098: WARNING: Duplicate C declaration, also 
defined in 'gpu/i915'.
  Declaration is 'i915_perf_poll_locked'.
  ./Documentation/gpu/i915:646: 
./drivers/gpu/drm/i915/i915_perf.c:3129: WARNING: Duplicate C declaration, also 
defined in 'gpu/i915'.
  Declaration is 'i915_perf_poll'.
  ./Documentation/gpu/i915:646: 
./drivers/gpu/drm/i915/i915_perf.c:3152: WARNING: Duplicate C declaration, also 
defined in 'gpu/i915'.
  Declaration is 'i915_perf_enable_locked'.
  ./Documentation/gpu/i915:646: 
./drivers/gpu/drm/i915/i915_perf.c:3181: WARNING: Duplicate C declaration, also 
defined in 'gpu/i915'.
  Declaration is 'i915_perf_disable_locked'.
  ./Documentation/gpu/i915:646: 
./drivers/gpu/drm/i915/i915_perf.c:3273: WARNING: Duplicate C declaration, also 
defined in 'gpu/i915'.
  Declaration is 'i915_perf_ioctl'.
  ./Documentation/gpu/i915:646: 
./drivers/gpu/drm/i915/i915_perf.c:3296: WARNING: Duplicate C declaration, also 
defined in 'gpu/i915'.
  Declaration is 'i915_perf_destroy_locked'.
  ./Documentation/gpu/i915:646: 
./drivers/gpu/drm/i915/i915_perf.c:3321: WARNING: Duplicate C declaration, als

Re: [PATCH v6 44/80] docs: gpu: i915.rst: Fix several C duplication warnings

[Lionel Landwerlin]

On 16/10/2020 14:37, Mauro Carvalho Chehab wrote:

Em Fri, 16 Oct 2020 14:01:07 +0300
Joonas Lahtinen  escreveu:


+ Lionel

Can you please take a look at best resolving the below problem.

Maybe we should eliminate the duplicate declarations? Updating such
a list manually seems error prone to me.

For Kernel 5.10, IMO the best is to apply this patch as-is, as any
other thing would need to be postponed, and we want 5.10 free of
doc warnings.



That's odd... Most of the functions are documented. Is it that we're 
missing the "()" after the function name maybe?



-Lionel




Yet, when I wrote this one, I almost took a different approach:
to implement something like @*group (or \*group) directives that
exists on doxygen:

https://www.doxygen.nl/manual/grouping.html

If something like that gets added to kernel-doc syntax, then
one could do something like:

/**
 * DOC: some foo description
 * @group foo
 */
  
	/**

 * foo1 - do some foo things
 * @group foo
...
 */

/**
 * foo2 - do some other foo things
 * @group foo
...
 */

/**
 * bar - do bar things
 * @group bar
...
 */


And then, at kernel-doc markup:

FOO
===

.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
:group: foo


BAR
===
.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
:group: bar


I suspect that something like that would be a lot easier to maintain.

Once having someone like that implemented, it should be easy to also
have something like this:

OTHERS
==
.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
:export:
:not-grouped:

in order to pick other functions that aren't grouped.

I suspect that implementing something like that at kernel-doc.pl
won't be hard.

Regards,
Mauro


Regards, Joonas

Quoting Mauro Carvalho Chehab (2020-10-13 14:53:59)

As reported by Sphinx:

 ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1147: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
 Declaration is 'i915_oa_wait_unlocked'.
 ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1169: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
 Declaration is 'i915_oa_poll_wait'.
 ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1189: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
 Declaration is 'i915_oa_read'.
 ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:2669: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
 Declaration is 'i915_oa_stream_enable'.
 ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:2734: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
 Declaration is 'i915_oa_stream_disable'.
 ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:2820: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
 Declaration is 'i915_oa_stream_init'.
 ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3010: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
 Declaration is 'i915_perf_read'.
 ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3098: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
 Declaration is 'i915_perf_poll_locked'.
 ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3129: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
 Declaration is 'i915_perf_poll'.
 ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3152: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
 Declaration is 'i915_perf_enable_locked'.
 ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3181: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
 Declaration is 'i915_perf_disable_locked'.
 ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3273: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
 Declaration is 'i915_perf_ioctl'.
 ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3296: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
 Declaration is 'i915_perf_destroy_locked'.
 ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3321: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
 Declaration is 'i915_perf_release'.
 ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3379: 
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
 Declaration is 'i915_perf_open_ioctl_locked'.
 ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3534: 

Re: [PATCH 25/44] tools headers UAPI: Sync drm/drm.h with the kernel

[Lionel Landwerlin]

On 27/05/2019 23:37, Arnaldo Carvalho de Melo wrote:

From: Arnaldo Carvalho de Melo 

To pick up the changes in these csets:

   060cebb20cdb ("drm: introduce a capability flag for syncobj timeline 
support")
   50d1ebef79ef ("drm/syncobj: add timeline signal ioctl for syncobj v5")
   ea569910cbab ("drm/syncobj: add transition iotcls between binary and timeline 
v2")
   27b575a9aa2f ("drm/syncobj: add timeline payload query ioctl v6")
   01d6c3578379 ("drm/syncobj: add support for timeline point wait v8")
   783195ec1cad ("drm/syncobj: disable the timeline UAPI for now v2")
   48197bc564c7 ("drm: add syncobj timeline support v9")

Which automagically results in the following new ioctls being recognized
by the 'perf trace' ioctl cmd arg beautifier:

   $ tools/perf/trace/beauty/drm_ioctl.sh > /tmp/before
   $ cp include/uapi/drm/drm.h tools/include/uapi/drm/drm.h
   $ tools/perf/trace/beauty/drm_ioctl.sh > /tmp/after
   $ diff -u /tmp/before /tmp/after
   --- /tmp/before  2019-05-22 10:25:31.443151182 -0300
   +++ /tmp/after   2019-05-22 10:25:46.449354819 -0300
   @@ -103,6 +103,10 @@
[0xC7] = "MODE_LIST_LESSEES",
[0xC8] = "MODE_GET_LEASE",
[0xC9] = "MODE_REVOKE_LEASE",
   +[0xCA] = "SYNCOBJ_TIMELINE_WAIT",
   +[0xCB] = "SYNCOBJ_QUERY",
   +[0xCC] = "SYNCOBJ_TRANSFER",
   +[0xCD] = "SYNCOBJ_TIMELINE_SIGNAL",
[DRM_COMMAND_BASE + 0x00] = "I915_INIT",
[DRM_COMMAND_BASE + 0x01] = "I915_FLUSH",
[DRM_COMMAND_BASE + 0x02] = "I915_FLIP",
 $

I.e. the strace like raw_tracepoint:sys_enter handler in 'perf trace'
will get the cmd integer value and map it to the string.

At some point it should be possible to translate from string to integer
and use to filter using expressions such as:

# perf trace -e ioctl/cmd==DRM_IOCTL_SYNCOBJ*/

Or some more suitable syntax to express that only these ioctls when
acting on DRM fds should be shown.

Cc: Adrian Hunter 
Cc: Brendan Gregg 
Cc: Christian König 
Cc: Chunming Zhou 
Cc: Dave Airlie 
Cc: Jiri Olsa 
Cc: Lionel Landwerlin 
Cc: Luis Cláudio Gonçalves 
Cc: Namhyung Kim 
Link: https://lkml.kernel.org/n/tip-jrc9ogw33w4zgqc3pu7o1...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 



Acked-by: Lionel Landwerlin 



---
  tools/include/uapi/drm/drm.h | 37 
  1 file changed, 37 insertions(+)

diff --git a/tools/include/uapi/drm/drm.h b/tools/include/uapi/drm/drm.h
index 300f336633f2..661d73f9a919 100644
--- a/tools/include/uapi/drm/drm.h
+++ b/tools/include/uapi/drm/drm.h
@@ -649,6 +649,7 @@ struct drm_gem_open {
  #define DRM_CAP_PAGE_FLIP_TARGET  0x11
  #define DRM_CAP_CRTC_IN_VBLANK_EVENT  0x12
  #define DRM_CAP_SYNCOBJ   0x13
+#define DRM_CAP_SYNCOBJ_TIMELINE   0x14
  
  /** DRM_IOCTL_GET_CAP ioctl argument type */

  struct drm_get_cap {
@@ -735,8 +736,18 @@ struct drm_syncobj_handle {
__u32 pad;
  };
  
+struct drm_syncobj_transfer {

+   __u32 src_handle;
+   __u32 dst_handle;
+   __u64 src_point;
+   __u64 dst_point;
+   __u32 flags;
+   __u32 pad;
+};
+
  #define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL (1 << 0)
  #define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT (1 << 1)
+#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE (1 << 2) /* wait for time point 
to become available */
  struct drm_syncobj_wait {
__u64 handles;
/* absolute timeout */
@@ -747,12 +758,33 @@ struct drm_syncobj_wait {
__u32 pad;
  };
  
+struct drm_syncobj_timeline_wait {

+   __u64 handles;
+   /* wait on specific timeline point for every handles*/
+   __u64 points;
+   /* absolute timeout */
+   __s64 timeout_nsec;
+   __u32 count_handles;
+   __u32 flags;
+   __u32 first_signaled; /* only valid when not waiting all */
+   __u32 pad;
+};
+
+
  struct drm_syncobj_array {
__u64 handles;
__u32 count_handles;
__u32 pad;
  };
  
+struct drm_syncobj_timeline_array {

+   __u64 handles;
+   __u64 points;
+   __u32 count_handles;
+   __u32 pad;
+};
+
+
  /* Query current scanout sequence number */
  struct drm_crtc_get_sequence {
__u32 crtc_id;  /* requested crtc_id */
@@ -909,6 +941,11 @@ extern "C" {
  #define DRM_IOCTL_MODE_GET_LEASE  DRM_IOWR(0xC8, struct 
drm_mode_get_lease)
  #define DRM_IOCTL_MODE_REVOKE_LEASE   DRM_IOWR(0xC9, struct 
drm_mode_revoke_lease)
  
+#define DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT	DRM_IOWR(0xCA, struct drm_syncobj_timeline_wait)

+#define DRM_IOCTL_SYNCOBJ_QUERYDRM_IOWR(0xCB, struct 
drm_syncobj_timeline_array)
+#define DRM_IOCTL_SYNCOBJ_TRANSFER DRM_IOWR(0xCC, struct 
drm_syncobj_transfer)
+#define DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNAL  DRM_IOWR(0xCD, struct 
drm_syncobj_timeline_array)
+
  /**
   * Device specific ioctls should only be in their respective headers
   * The device specific ioctl range is from 0x40 to 0x9f.

Re: [Intel-gfx] [PATCH 00/11] constify i915 attribute_group structures.

[Lionel Landwerlin]

On 04/08/17 11:22, Arvind Yadav wrote:

Hi Lionel,


On Friday 04 August 2017 02:33 PM, Lionel Landwerlin wrote:

Hi Arwind,

These files were generated by a script maintained in this repository 
: 
https://github.com/rib/gputop/blob/master/scripts/i915-perf-kernelgen.py
It would best to update this script first to make sure future 
platforms get the fixes too.


Some changes have just been merged, deleted most configs but the test 
ones.

You'll need to update your series.

I have done the changes. Please review it. :) Shared patch is 
0001-i915-perf-kernelgen.py-constify-attribute_group-stru.patch.


Hm... Where is it? (I can't see it on the mailing list nor attached)
The best would be to submit a PR on the github project directly.





Otherwise it looks like a good change.

Thanks,

-
Lionel

On 04/08/17 06:03, Arvind Yadav wrote:

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by  work with
const attribute_group. So mark the non-const structs as const.

Arvind Yadav (11):
   [PATCH 01/11] drm: i915: i915_oa_kblgt2: constify attribute_group 
structures.
   [PATCH 02/11] drm: i915: i915_oa_bdw: constify attribute_group 
structures.
   [PATCH 03/11] drm: i915: i915_oa_bxt: constify attribute_group 
structures.
   [PATCH 04/11] drm: i915: i915_oa_chv: constify attribute_group 
structures.
   [PATCH 05/11] drm: i915: i915_oa_glk: constify attribute_group 
structures.
   [PATCH 06/11] drm: i915: i915_oa_hsw: constify attribute_group 
structures.
   [PATCH 07/11] drm: i915: i915_oa_kblgt3: constify attribute_group 
structures.
   [PATCH 08/11] drm: i915: i915_oa_sklgt2: constify attribute_group 
structures.
   [PATCH 09/11] drm: i915: i915_oa_sklgt3: constify attribute_group 
structures.
   [PATCH 10/11] drm: i915: i915_oa_sklgt4: constify attribute_group 
structures.
   [PATCH 11/11] drm: i915: i915_sysfs: constify attribute_group 
structures.


  drivers/gpu/drm/i915/i915_oa_bdw.c| 44 
+--

  drivers/gpu/drm/i915/i915_oa_bxt.c| 30 
  drivers/gpu/drm/i915/i915_oa_chv.c| 28 +++---
  drivers/gpu/drm/i915/i915_oa_glk.c| 30 
  drivers/gpu/drm/i915/i915_oa_hsw.c| 12 +-
  drivers/gpu/drm/i915/i915_oa_kblgt2.c | 36 
++--
  drivers/gpu/drm/i915/i915_oa_kblgt3.c | 36 
++--
  drivers/gpu/drm/i915/i915_oa_sklgt2.c | 36 
++--
  drivers/gpu/drm/i915/i915_oa_sklgt3.c | 36 
++--
  drivers/gpu/drm/i915/i915_oa_sklgt4.c | 36 
++--

  drivers/gpu/drm/i915/i915_sysfs.c |  6 ++---
  11 files changed, 165 insertions(+), 165 deletions(-)




~arvind

Re: [Intel-gfx] [PATCH 00/11] constify i915 attribute_group structures.

[Lionel Landwerlin]

On 04/08/17 11:22, Arvind Yadav wrote:

Hi Lionel,


On Friday 04 August 2017 02:33 PM, Lionel Landwerlin wrote:

Hi Arwind,

These files were generated by a script maintained in this repository 
: 
https://github.com/rib/gputop/blob/master/scripts/i915-perf-kernelgen.py
It would best to update this script first to make sure future 
platforms get the fixes too.


Some changes have just been merged, deleted most configs but the test 
ones.

You'll need to update your series.

I have done the changes. Please review it. :) Shared patch is 
0001-i915-perf-kernelgen.py-constify-attribute_group-stru.patch.


Hm... Where is it? (I can't see it on the mailing list nor attached)
The best would be to submit a PR on the github project directly.





Otherwise it looks like a good change.

Thanks,

-
Lionel

On 04/08/17 06:03, Arvind Yadav wrote:

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by  work with
const attribute_group. So mark the non-const structs as const.

Arvind Yadav (11):
   [PATCH 01/11] drm: i915: i915_oa_kblgt2: constify attribute_group 
structures.
   [PATCH 02/11] drm: i915: i915_oa_bdw: constify attribute_group 
structures.
   [PATCH 03/11] drm: i915: i915_oa_bxt: constify attribute_group 
structures.
   [PATCH 04/11] drm: i915: i915_oa_chv: constify attribute_group 
structures.
   [PATCH 05/11] drm: i915: i915_oa_glk: constify attribute_group 
structures.
   [PATCH 06/11] drm: i915: i915_oa_hsw: constify attribute_group 
structures.
   [PATCH 07/11] drm: i915: i915_oa_kblgt3: constify attribute_group 
structures.
   [PATCH 08/11] drm: i915: i915_oa_sklgt2: constify attribute_group 
structures.
   [PATCH 09/11] drm: i915: i915_oa_sklgt3: constify attribute_group 
structures.
   [PATCH 10/11] drm: i915: i915_oa_sklgt4: constify attribute_group 
structures.
   [PATCH 11/11] drm: i915: i915_sysfs: constify attribute_group 
structures.


  drivers/gpu/drm/i915/i915_oa_bdw.c| 44 
+--

  drivers/gpu/drm/i915/i915_oa_bxt.c| 30 
  drivers/gpu/drm/i915/i915_oa_chv.c| 28 +++---
  drivers/gpu/drm/i915/i915_oa_glk.c| 30 
  drivers/gpu/drm/i915/i915_oa_hsw.c| 12 +-
  drivers/gpu/drm/i915/i915_oa_kblgt2.c | 36 
++--
  drivers/gpu/drm/i915/i915_oa_kblgt3.c | 36 
++--
  drivers/gpu/drm/i915/i915_oa_sklgt2.c | 36 
++--
  drivers/gpu/drm/i915/i915_oa_sklgt3.c | 36 
++--
  drivers/gpu/drm/i915/i915_oa_sklgt4.c | 36 
++--

  drivers/gpu/drm/i915/i915_sysfs.c |  6 ++---
  11 files changed, 165 insertions(+), 165 deletions(-)




~arvind

Re: [Intel-gfx] [PATCH 00/11] constify i915 attribute_group structures.

[Lionel Landwerlin]

Hi Arwind,

These files were generated by a script maintained in this repository : 
https://github.com/rib/gputop/blob/master/scripts/i915-perf-kernelgen.py
It would best to update this script first to make sure future platforms 
get the fixes too.


Some changes have just been merged, deleted most configs but the test ones.
You'll need to update your series.

Otherwise it looks like a good change.

Thanks,

-
Lionel

On 04/08/17 06:03, Arvind Yadav wrote:

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by  work with
const attribute_group. So mark the non-const structs as const.

Arvind Yadav (11):
   [PATCH 01/11] drm: i915: i915_oa_kblgt2: constify attribute_group structures.
   [PATCH 02/11] drm: i915: i915_oa_bdw: constify attribute_group structures.
   [PATCH 03/11] drm: i915: i915_oa_bxt: constify attribute_group structures.
   [PATCH 04/11] drm: i915: i915_oa_chv: constify attribute_group structures.
   [PATCH 05/11] drm: i915: i915_oa_glk: constify attribute_group structures.
   [PATCH 06/11] drm: i915: i915_oa_hsw: constify attribute_group structures.
   [PATCH 07/11] drm: i915: i915_oa_kblgt3: constify attribute_group structures.
   [PATCH 08/11] drm: i915: i915_oa_sklgt2: constify attribute_group structures.
   [PATCH 09/11] drm: i915: i915_oa_sklgt3: constify attribute_group structures.
   [PATCH 10/11] drm: i915: i915_oa_sklgt4: constify attribute_group structures.
   [PATCH 11/11] drm: i915: i915_sysfs: constify attribute_group structures.

  drivers/gpu/drm/i915/i915_oa_bdw.c| 44 +--
  drivers/gpu/drm/i915/i915_oa_bxt.c| 30 
  drivers/gpu/drm/i915/i915_oa_chv.c| 28 +++---
  drivers/gpu/drm/i915/i915_oa_glk.c| 30 
  drivers/gpu/drm/i915/i915_oa_hsw.c| 12 +-
  drivers/gpu/drm/i915/i915_oa_kblgt2.c | 36 ++--
  drivers/gpu/drm/i915/i915_oa_kblgt3.c | 36 ++--
  drivers/gpu/drm/i915/i915_oa_sklgt2.c | 36 ++--
  drivers/gpu/drm/i915/i915_oa_sklgt3.c | 36 ++--
  drivers/gpu/drm/i915/i915_oa_sklgt4.c | 36 ++--
  drivers/gpu/drm/i915/i915_sysfs.c |  6 ++---
  11 files changed, 165 insertions(+), 165 deletions(-)

Re: [Intel-gfx] [PATCH 00/11] constify i915 attribute_group structures.

[Lionel Landwerlin]

Hi Arwind,

These files were generated by a script maintained in this repository : 
https://github.com/rib/gputop/blob/master/scripts/i915-perf-kernelgen.py
It would best to update this script first to make sure future platforms 
get the fixes too.


Some changes have just been merged, deleted most configs but the test ones.
You'll need to update your series.

Otherwise it looks like a good change.

Thanks,

-
Lionel

On 04/08/17 06:03, Arvind Yadav wrote:

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by  work with
const attribute_group. So mark the non-const structs as const.

Arvind Yadav (11):
   [PATCH 01/11] drm: i915: i915_oa_kblgt2: constify attribute_group structures.
   [PATCH 02/11] drm: i915: i915_oa_bdw: constify attribute_group structures.
   [PATCH 03/11] drm: i915: i915_oa_bxt: constify attribute_group structures.
   [PATCH 04/11] drm: i915: i915_oa_chv: constify attribute_group structures.
   [PATCH 05/11] drm: i915: i915_oa_glk: constify attribute_group structures.
   [PATCH 06/11] drm: i915: i915_oa_hsw: constify attribute_group structures.
   [PATCH 07/11] drm: i915: i915_oa_kblgt3: constify attribute_group structures.
   [PATCH 08/11] drm: i915: i915_oa_sklgt2: constify attribute_group structures.
   [PATCH 09/11] drm: i915: i915_oa_sklgt3: constify attribute_group structures.
   [PATCH 10/11] drm: i915: i915_oa_sklgt4: constify attribute_group structures.
   [PATCH 11/11] drm: i915: i915_sysfs: constify attribute_group structures.

  drivers/gpu/drm/i915/i915_oa_bdw.c| 44 +--
  drivers/gpu/drm/i915/i915_oa_bxt.c| 30 
  drivers/gpu/drm/i915/i915_oa_chv.c| 28 +++---
  drivers/gpu/drm/i915/i915_oa_glk.c| 30 
  drivers/gpu/drm/i915/i915_oa_hsw.c| 12 +-
  drivers/gpu/drm/i915/i915_oa_kblgt2.c | 36 ++--
  drivers/gpu/drm/i915/i915_oa_kblgt3.c | 36 ++--
  drivers/gpu/drm/i915/i915_oa_sklgt2.c | 36 ++--
  drivers/gpu/drm/i915/i915_oa_sklgt3.c | 36 ++--
  drivers/gpu/drm/i915/i915_oa_sklgt4.c | 36 ++--
  drivers/gpu/drm/i915/i915_sysfs.c |  6 ++---
  11 files changed, 165 insertions(+), 165 deletions(-)

Re: [PATCH v2] drm/color: Document CTM eqations

[Lionel Landwerlin]

On 17/02/17 14:56, Ville Syrjälä wrote:

On Fri, Feb 17, 2017 at 02:42:26PM +, Lionel Landwerlin wrote:

On 17/02/17 13:54, Brian Starkey wrote:

What's the verdict? We've got [1] which is about to become another
(driver) implementation - better to change before that merges than
after I guess.

-Brian

[1] https://lkml.org/lkml/2017/2/13/304

On Wed, Feb 15, 2017 at 11:56:55AM +, Daniel Stone wrote:

Hi,

On 15 February 2017 at 11:39, Ville Syrjälä
<ville.syrj...@linux.intel.com> wrote:

On Tue, Jan 31, 2017 at 06:46:39PM +0100, Daniel Vetter wrote:

On Tue, Jan 31, 2017 at 6:22 PM, Ville Syrjälä
<ville.syrj...@linux.intel.com> wrote:

Hmm. Two's complement is what I was thinking it is. Which shows that
I never managed to read the code in any detail. Definitely needs to
be documented properly.

That sounds supremely backwards. I guess we can't fix this anymore?

I have no idea. Anyone else?

I don't know of any implementation using this; maybe closed Intel
Android stuff? Certainly GitHub showed no-one using it, and neither X
nor Weston/Mutter are using it yet.

Cheers,
Daniel

If we're talking fixed point reprsentation, ChromeOS is using this :

https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_device.cc?q=DrmDevice=209

So it's already using the sign+magnitude stuff. Which presumably
means we can't change it to two's complement anymore :( Maybe we add a
CTM2 property ;)

Using sign+magnitude definitely looks rather inefficient since there's
a branch inside the loop. With two's complement you wouldn't need that
thing slowing you down.

If you're seriously considering that, you might also want to bump struct 
drm_color_lut to use 32bits fields.

It seems some people have concerned about HDR.

Re: [PATCH v2] drm/color: Document CTM eqations

[Lionel Landwerlin]

On 17/02/17 14:56, Ville Syrjälä wrote:

On Fri, Feb 17, 2017 at 02:42:26PM +, Lionel Landwerlin wrote:

On 17/02/17 13:54, Brian Starkey wrote:

What's the verdict? We've got [1] which is about to become another
(driver) implementation - better to change before that merges than
after I guess.

-Brian

[1] https://lkml.org/lkml/2017/2/13/304

On Wed, Feb 15, 2017 at 11:56:55AM +, Daniel Stone wrote:

Hi,

On 15 February 2017 at 11:39, Ville Syrjälä
 wrote:

On Tue, Jan 31, 2017 at 06:46:39PM +0100, Daniel Vetter wrote:

On Tue, Jan 31, 2017 at 6:22 PM, Ville Syrjälä
 wrote:

Hmm. Two's complement is what I was thinking it is. Which shows that
I never managed to read the code in any detail. Definitely needs to
be documented properly.

That sounds supremely backwards. I guess we can't fix this anymore?

I have no idea. Anyone else?

I don't know of any implementation using this; maybe closed Intel
Android stuff? Certainly GitHub showed no-one using it, and neither X
nor Weston/Mutter are using it yet.

Cheers,
Daniel

If we're talking fixed point reprsentation, ChromeOS is using this :

https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_device.cc?q=DrmDevice=209

So it's already using the sign+magnitude stuff. Which presumably
means we can't change it to two's complement anymore :( Maybe we add a
CTM2 property ;)

Using sign+magnitude definitely looks rather inefficient since there's
a branch inside the loop. With two's complement you wouldn't need that
thing slowing you down.

If you're seriously considering that, you might also want to bump struct 
drm_color_lut to use 32bits fields.

It seems some people have concerned about HDR.

Re: [PATCH v2] drm/color: Document CTM eqations

[Lionel Landwerlin]

On 17/02/17 13:54, Brian Starkey wrote:

What's the verdict? We've got [1] which is about to become another
(driver) implementation - better to change before that merges than
after I guess.

-Brian

[1] https://lkml.org/lkml/2017/2/13/304

On Wed, Feb 15, 2017 at 11:56:55AM +, Daniel Stone wrote:

Hi,

On 15 February 2017 at 11:39, Ville Syrjälä
 wrote:

On Tue, Jan 31, 2017 at 06:46:39PM +0100, Daniel Vetter wrote:

On Tue, Jan 31, 2017 at 6:22 PM, Ville Syrjälä
 wrote:
> Hmm. Two's complement is what I was thinking it is. Which shows that
> I never managed to read the code in any detail. Definitely needs to
> be documented properly.

That sounds supremely backwards. I guess we can't fix this anymore?


I have no idea. Anyone else?


I don't know of any implementation using this; maybe closed Intel
Android stuff? Certainly GitHub showed no-one using it, and neither X
nor Weston/Mutter are using it yet.

Cheers,
Daniel



If we're talking fixed point reprsentation, ChromeOS is using this :

https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_device.cc?q=DrmDevice=209

-
Lionel

Re: [PATCH v2] drm/color: Document CTM eqations

[Lionel Landwerlin]

On 17/02/17 13:54, Brian Starkey wrote:

What's the verdict? We've got [1] which is about to become another
(driver) implementation - better to change before that merges than
after I guess.

-Brian

[1] https://lkml.org/lkml/2017/2/13/304

On Wed, Feb 15, 2017 at 11:56:55AM +, Daniel Stone wrote:

Hi,

On 15 February 2017 at 11:39, Ville Syrjälä
 wrote:

On Tue, Jan 31, 2017 at 06:46:39PM +0100, Daniel Vetter wrote:

On Tue, Jan 31, 2017 at 6:22 PM, Ville Syrjälä
 wrote:
> Hmm. Two's complement is what I was thinking it is. Which shows that
> I never managed to read the code in any detail. Definitely needs to
> be documented properly.

That sounds supremely backwards. I guess we can't fix this anymore?


I have no idea. Anyone else?


I don't know of any implementation using this; maybe closed Intel
Android stuff? Certainly GitHub showed no-one using it, and neither X
nor Weston/Mutter are using it yet.

Cheers,
Daniel



If we're talking fixed point reprsentation, ChromeOS is using this :

https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_device.cc?q=DrmDevice=209

-
Lionel

Re: [PATCH] drm/i915: Fix legacy gamma lut updates in Linux 4.7-rc6

[Lionel Landwerlin]

On 12/07/16 13:11, Mario Kleiner wrote:

On 07/12/2016 12:50 PM, Lionel Landwerlin wrote:

Hi Mario,



Hi Lionel,


There was a couple of patch to fix this issue :

https://patchwork.freedesktop.org/series/5467/
https://patchwork.freedesktop.org/series/5466/



Looking at them they should fix the issue, but they seem to be stuck 
in review?



I tested this late last week on drm-intel-nightly, it seems a series of
revert fixed most of the issues.



You mean something else has fixed legacy gamma updates, as i can't 
find above patches applied on drm-intel-nightly?


This revert on drm-intel-nightly seems to have fixed the problem :

https://cgit.freedesktop.org/drm-intel/commit/drivers/gpu/drm/i915?id=e42aeef1237b7c969a77b7f726c50f6cb832185f



Are those fixes supposed to be already part of 4.7-rc7, the final rc 
afaik?


I haven't seen it on 4.7-rc7.



thanks,
-mario



Cheers,

-
Lionel

On 12/07/16 11:33, Mario Kleiner wrote:

Updating legacy gamma tables, e.g., via RandR doesn't work at all
as of Linux 4.7-rc6.

Reason seems to be that the required call to
drm_atomic_helper_commit_planes_on_crtc is skipped in
intel_atomic_commit after userspace set new gamma tables,
because neither crtc->state->planes_changed nor
update_pipe (= pipe_config->update_pipe) are true.

Removing the check for planes_changed || update_pipe fixes
gamma table updates.

The code for Linux 4.8 drm-next has changed a lot in that area
wrt. 4.7, but the new code for 4.8 also removed those checks
and calls drm_atomic_helper_commit_planes_on_crtc unconditionally,
and legacy gamma lut updates work on drm-next, so this seems to be
the right solution.

Tested also shutdown/reboot, suspend/resume, (un-)plugging displays,
mode switches for resolution/refresh rate, display rotation, and
page-flipping/pageflip timing on Intel HD Ironlake to confirm the
fix apparently doesn't break anything under X11.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Cc: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
Cc: Lionel Landwerlin <lionel.g.landwer...@intel.com>
Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
---
  drivers/gpu/drm/i915/intel_display.c | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 04452cf..eb8fb36 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13685,7 +13685,6 @@ static int intel_atomic_commit(struct
drm_device *dev,
  bool modeset = needs_modeset(crtc->state);
  struct intel_crtc_state *pipe_config =
  to_intel_crtc_state(crtc->state);
-bool update_pipe = !modeset && pipe_config->update_pipe;
  if (modeset && crtc->state->active) {
  update_scanline_offset(to_intel_crtc(crtc));
@@ -13699,8 +13698,7 @@ static int intel_atomic_commit(struct
drm_device *dev,
  drm_atomic_get_existing_plane_state(state, 
crtc->primary))

  intel_fbc_enable(intel_crtc);
-if (crtc->state->active &&
-(crtc->state->planes_changed || update_pipe))
+if (crtc->state->active)
drm_atomic_helper_commit_planes_on_crtc(old_crtc_state);
  if (pipe_config->base.active && 
needs_vblank_wait(pipe_config))

Re: [PATCH] drm/i915: Fix legacy gamma lut updates in Linux 4.7-rc6

[Lionel Landwerlin]

On 12/07/16 13:11, Mario Kleiner wrote:

On 07/12/2016 12:50 PM, Lionel Landwerlin wrote:

Hi Mario,



Hi Lionel,


There was a couple of patch to fix this issue :

https://patchwork.freedesktop.org/series/5467/
https://patchwork.freedesktop.org/series/5466/



Looking at them they should fix the issue, but they seem to be stuck 
in review?



I tested this late last week on drm-intel-nightly, it seems a series of
revert fixed most of the issues.



You mean something else has fixed legacy gamma updates, as i can't 
find above patches applied on drm-intel-nightly?


This revert on drm-intel-nightly seems to have fixed the problem :

https://cgit.freedesktop.org/drm-intel/commit/drivers/gpu/drm/i915?id=e42aeef1237b7c969a77b7f726c50f6cb832185f



Are those fixes supposed to be already part of 4.7-rc7, the final rc 
afaik?


I haven't seen it on 4.7-rc7.



thanks,
-mario



Cheers,

-
Lionel

On 12/07/16 11:33, Mario Kleiner wrote:

Updating legacy gamma tables, e.g., via RandR doesn't work at all
as of Linux 4.7-rc6.

Reason seems to be that the required call to
drm_atomic_helper_commit_planes_on_crtc is skipped in
intel_atomic_commit after userspace set new gamma tables,
because neither crtc->state->planes_changed nor
update_pipe (= pipe_config->update_pipe) are true.

Removing the check for planes_changed || update_pipe fixes
gamma table updates.

The code for Linux 4.8 drm-next has changed a lot in that area
wrt. 4.7, but the new code for 4.8 also removed those checks
and calls drm_atomic_helper_commit_planes_on_crtc unconditionally,
and legacy gamma lut updates work on drm-next, so this seems to be
the right solution.

Tested also shutdown/reboot, suspend/resume, (un-)plugging displays,
mode switches for resolution/refresh rate, display rotation, and
page-flipping/pageflip timing on Intel HD Ironlake to confirm the
fix apparently doesn't break anything under X11.

Signed-off-by: Mario Kleiner 
Cc: Maarten Lankhorst 
Cc: Lionel Landwerlin 
Cc: Daniel Vetter 
---
  drivers/gpu/drm/i915/intel_display.c | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 04452cf..eb8fb36 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13685,7 +13685,6 @@ static int intel_atomic_commit(struct
drm_device *dev,
  bool modeset = needs_modeset(crtc->state);
  struct intel_crtc_state *pipe_config =
  to_intel_crtc_state(crtc->state);
-bool update_pipe = !modeset && pipe_config->update_pipe;
  if (modeset && crtc->state->active) {
  update_scanline_offset(to_intel_crtc(crtc));
@@ -13699,8 +13698,7 @@ static int intel_atomic_commit(struct
drm_device *dev,
  drm_atomic_get_existing_plane_state(state, 
crtc->primary))

  intel_fbc_enable(intel_crtc);
-if (crtc->state->active &&
-(crtc->state->planes_changed || update_pipe))
+if (crtc->state->active)
drm_atomic_helper_commit_planes_on_crtc(old_crtc_state);
  if (pipe_config->base.active && 
needs_vblank_wait(pipe_config))

Re: [PATCH] drm/i915: Fix legacy gamma lut updates in Linux 4.7-rc6

[Lionel Landwerlin]

Hi Mario,

There was a couple of patch to fix this issue :

https://patchwork.freedesktop.org/series/5467/
https://patchwork.freedesktop.org/series/5466/

I tested this late last week on drm-intel-nightly, it seems a series of 
revert fixed most of the issues.


Cheers,

-
Lionel

On 12/07/16 11:33, Mario Kleiner wrote:

Updating legacy gamma tables, e.g., via RandR doesn't work at all
as of Linux 4.7-rc6.

Reason seems to be that the required call to
drm_atomic_helper_commit_planes_on_crtc is skipped in
intel_atomic_commit after userspace set new gamma tables,
because neither crtc->state->planes_changed nor
update_pipe (= pipe_config->update_pipe) are true.

Removing the check for planes_changed || update_pipe fixes
gamma table updates.

The code for Linux 4.8 drm-next has changed a lot in that area
wrt. 4.7, but the new code for 4.8 also removed those checks
and calls drm_atomic_helper_commit_planes_on_crtc unconditionally,
and legacy gamma lut updates work on drm-next, so this seems to be
the right solution.

Tested also shutdown/reboot, suspend/resume, (un-)plugging displays,
mode switches for resolution/refresh rate, display rotation, and
page-flipping/pageflip timing on Intel HD Ironlake to confirm the
fix apparently doesn't break anything under X11.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Cc: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
Cc: Lionel Landwerlin <lionel.g.landwer...@intel.com>
Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
---
  drivers/gpu/drm/i915/intel_display.c | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 04452cf..eb8fb36 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13685,7 +13685,6 @@ static int intel_atomic_commit(struct drm_device *dev,
bool modeset = needs_modeset(crtc->state);
struct intel_crtc_state *pipe_config =
to_intel_crtc_state(crtc->state);
-   bool update_pipe = !modeset && pipe_config->update_pipe;
  
  		if (modeset && crtc->state->active) {

update_scanline_offset(to_intel_crtc(crtc));
@@ -13699,8 +13698,7 @@ static int intel_atomic_commit(struct drm_device *dev,
drm_atomic_get_existing_plane_state(state, crtc->primary))
intel_fbc_enable(intel_crtc);
  
-		if (crtc->state->active &&

-   (crtc->state->planes_changed || update_pipe))
+   if (crtc->state->active)
drm_atomic_helper_commit_planes_on_crtc(old_crtc_state);
  
  		if (pipe_config->base.active && needs_vblank_wait(pipe_config))

Re: [PATCH] drm/i915: Fix legacy gamma lut updates in Linux 4.7-rc6

[Lionel Landwerlin]

Hi Mario,

There was a couple of patch to fix this issue :

https://patchwork.freedesktop.org/series/5467/
https://patchwork.freedesktop.org/series/5466/

I tested this late last week on drm-intel-nightly, it seems a series of 
revert fixed most of the issues.


Cheers,

-
Lionel

On 12/07/16 11:33, Mario Kleiner wrote:

Updating legacy gamma tables, e.g., via RandR doesn't work at all
as of Linux 4.7-rc6.

Reason seems to be that the required call to
drm_atomic_helper_commit_planes_on_crtc is skipped in
intel_atomic_commit after userspace set new gamma tables,
because neither crtc->state->planes_changed nor
update_pipe (= pipe_config->update_pipe) are true.

Removing the check for planes_changed || update_pipe fixes
gamma table updates.

The code for Linux 4.8 drm-next has changed a lot in that area
wrt. 4.7, but the new code for 4.8 also removed those checks
and calls drm_atomic_helper_commit_planes_on_crtc unconditionally,
and legacy gamma lut updates work on drm-next, so this seems to be
the right solution.

Tested also shutdown/reboot, suspend/resume, (un-)plugging displays,
mode switches for resolution/refresh rate, display rotation, and
page-flipping/pageflip timing on Intel HD Ironlake to confirm the
fix apparently doesn't break anything under X11.

Signed-off-by: Mario Kleiner 
Cc: Maarten Lankhorst 
Cc: Lionel Landwerlin 
Cc: Daniel Vetter 
---
  drivers/gpu/drm/i915/intel_display.c | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 04452cf..eb8fb36 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13685,7 +13685,6 @@ static int intel_atomic_commit(struct drm_device *dev,
bool modeset = needs_modeset(crtc->state);
struct intel_crtc_state *pipe_config =
to_intel_crtc_state(crtc->state);
-   bool update_pipe = !modeset && pipe_config->update_pipe;
  
  		if (modeset && crtc->state->active) {

update_scanline_offset(to_intel_crtc(crtc));
@@ -13699,8 +13698,7 @@ static int intel_atomic_commit(struct drm_device *dev,
drm_atomic_get_existing_plane_state(state, crtc->primary))
intel_fbc_enable(intel_crtc);
  
-		if (crtc->state->active &&

-   (crtc->state->planes_changed || update_pipe))
+   if (crtc->state->active)
drm_atomic_helper_commit_planes_on_crtc(old_crtc_state);
  
  		if (pipe_config->base.active && needs_vblank_wait(pipe_config))

Re: issue when applying ICC profile to display after drm/i915 change

[Lionel Landwerlin]

This 2 patches should fix the issue :

https://patchwork.freedesktop.org/series/5467/
https://patchwork.freedesktop.org/series/5466/

Still waiting for review though.

-
Lionel

On 29/05/16 19:20, Kui Zhang wrote:

Hello,

this used to work.

xcalib D6200MTX.icc


After this it stopped working

commit 20a34e78f0d71cab058a943b2e9601b97b761227
drm/i915: Update color management during vblank evasion.


Color profile only take effect after the screen if back on.

xcalib D6200MTX.icc
xrandr --output eDP1 --off
xrandr --output eDP1 --auto


thanks
Kui.Z

Re: issue when applying ICC profile to display after drm/i915 change

[Lionel Landwerlin]

This 2 patches should fix the issue :

https://patchwork.freedesktop.org/series/5467/
https://patchwork.freedesktop.org/series/5466/

Still waiting for review though.

-
Lionel

On 29/05/16 19:20, Kui Zhang wrote:

Hello,

this used to work.

xcalib D6200MTX.icc


After this it stopped working

commit 20a34e78f0d71cab058a943b2e9601b97b761227
drm/i915: Update color management during vblank evasion.


Color profile only take effect after the screen if back on.

xcalib D6200MTX.icc
xrandr --output eDP1 --off
xrandr --output eDP1 --auto


thanks
Kui.Z

Macbook bug after suspend to disk

[Lionel Landwerlin]

I'm using 2.6.22.1 on my macbook (32bits). I had got this trace a few
hours after a suspend to disk. I never got this kind of trace without
suspend. I will try to reproduce with 2.6.22.3.

Here is the trace :

Aug 20 14:14:23 cocoduo kernel: kernel BUG at mm/slab.c:2980!
Aug 20 14:14:23 cocoduo kernel: invalid opcode:  [#1]
Aug 20 14:14:23 cocoduo kernel: SMP 
Aug 20 14:14:23 cocoduo kernel: Modules linked in: wlan_tkip wlan_ccmp usbkbd 
ath_pci button nfs lockd nfs_acl sunrpc ac battery cpufreq_ondemand 
cpufreq_powersave i915 drm binfmt_misc hci_usb rfcomm l2cap bluetooth ppdev lp 
parport ipv6 dm_snapshot dm_mirror dm_mod cpufreq_userspace acpi_cpufreq 
freq_table firewire_sbp2 loop joydev usbmouse appletouch snd_hda_intel tsdev 
sky2 rtc_cmos rtc_core intelfb i2c_i801 wlan_scan_sta iTCO_wdt snd_pcm 
snd_timer snd soundcore rtc_lib i2c_algo_bit ath_rate_sample intel_agp agpgart 
i2c_core snd_page_alloc wlan ath_hal(P) evdev ext3 jbd mbcache usbhid hid 
sd_mod ide_cd cdrom ata_piix ata_generic libata scsi_mod piix firewire_ohci 
firewire_core crc_itu_t ehci_hcd generic ide_core uhci_hcd usbcore thermal 
processor fan
Aug 20 14:14:23 cocoduo kernel: CPU:0
Aug 20 14:14:23 cocoduo kernel: EIP:0060:[]Tainted: P   
VLI
Aug 20 14:14:23 cocoduo kernel: EFLAGS: 00210092   (2.6.22-1-686 #1)
Aug 20 14:14:23 cocoduo kernel: EIP is at cache_alloc_refill+0xe9/0x451
Aug 20 14:14:23 cocoduo kernel: eax: 007f   ebx: c20bf800   ecx: df9e8d40   
edx: 
Aug 20 14:14:23 cocoduo kernel: esi: db91c000   edi: 0010   ebp: dfff1600   
esp: eecdddbc
Aug 20 14:14:23 cocoduo kernel: ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 
0068
Aug 20 14:14:23 cocoduo kernel: Process hald (pid: 5167, ti=eecdc000 
task=ef3a8a50 task.ti=eecdc000)
Aug 20 14:14:23 cocoduo kernel: Stack:   00d0 df9e8d40 
df9e0c00  c0152f3b 0044 
Aug 20 14:14:23 cocoduo kernel:00d0 c0327ff4 ef3a8a50  
00a4 df9e8d40 00200202 c210ac24 
Aug 20 14:14:23 cocoduo kernel:c0167553 00a4 0001 00a4 
c02017f4 0004 c210ac00  
Aug 20 14:14:23 cocoduo kernel: Call Trace:
Aug 20 14:14:23 cocoduo kernel:  [] __alloc_pages+0x52/0x294
Aug 20 14:14:23 cocoduo kernel:  [] kmem_cache_zalloc+0x42/0x79
Aug 20 14:14:23 cocoduo kernel:  [] acpi_ps_alloc_op+0x5d/0x9e
Aug 20 14:14:23 cocoduo kernel:  [] acpi_ps_parse_loop+0x6f6/0x737
Aug 20 14:14:23 cocoduo kernel:  [] acpi_ps_parse_aml+0x60/0x237
Aug 20 14:14:23 cocoduo kernel:  [] acpi_ds_init_aml_walk+0xb4/0xfe
Aug 20 14:14:23 cocoduo kernel:  [] acpi_ps_execute_method+0x11b/0x1bb
Aug 20 14:14:23 cocoduo kernel:  [] acpi_ns_evaluate+0x99/0xf0
Aug 20 14:14:23 cocoduo kernel:  [] acpi_evaluate_object+0x139/0x1dc
Aug 20 14:14:23 cocoduo kernel:  [] acpi_evaluate_integer+0x80/0xb3
Aug 20 14:14:23 cocoduo kernel:  [] acpi_ac_get_state+0x26/0x61 [ac]
Aug 20 14:14:23 cocoduo kernel:  [] vma_link+0x54/0xc9
Aug 20 14:14:23 cocoduo kernel:  [] acpi_ac_seq_show+0x12/0x4e [ac]
Aug 20 14:14:23 cocoduo kernel:  [] seq_read+0xe7/0x274
Aug 20 14:14:23 cocoduo kernel:  [] seq_read+0x0/0x274
Aug 20 14:14:23 cocoduo kernel:  [] vfs_read+0xa6/0x128
Aug 20 14:14:23 cocoduo kernel:  [] sys_read+0x41/0x67
Aug 20 14:14:23 cocoduo kernel:  [] sysenter_past_esp+0x6b/0xa1
Aug 20 14:14:23 cocoduo kernel:  ===
Aug 20 14:14:23 cocoduo kernel: Code: 00 00 00 8b 75 00 39 ee 75 15 8b 75 10 8d 
45 10 c7 45 34 01 00 00 00 39 c6 0f 84 9c 00 00 00 8b 4c 24 0c 8b 41 38 39 46 
10 72 34 <0f> 0b eb fe 8b 44 24 10 8b 5e 14 8b 08 8b 44 24 0c 8b 50 2c 8b 
Aug 20 14:14:23 cocoduo kernel: EIP: [] cache_alloc_refill+0xe9/0x451 
SS:ESP 0068:eecdddbc


-- 
Lionel Landwerlin

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Macbook bug after suspend to disk

[Lionel Landwerlin]

I'm using 2.6.22.1 on my macbook (32bits). I had got this trace a few
hours after a suspend to disk. I never got this kind of trace without
suspend. I will try to reproduce with 2.6.22.3.

Here is the trace :

Aug 20 14:14:23 cocoduo kernel: kernel BUG at mm/slab.c:2980!
Aug 20 14:14:23 cocoduo kernel: invalid opcode:  [#1]
Aug 20 14:14:23 cocoduo kernel: SMP 
Aug 20 14:14:23 cocoduo kernel: Modules linked in: wlan_tkip wlan_ccmp usbkbd 
ath_pci button nfs lockd nfs_acl sunrpc ac battery cpufreq_ondemand 
cpufreq_powersave i915 drm binfmt_misc hci_usb rfcomm l2cap bluetooth ppdev lp 
parport ipv6 dm_snapshot dm_mirror dm_mod cpufreq_userspace acpi_cpufreq 
freq_table firewire_sbp2 loop joydev usbmouse appletouch snd_hda_intel tsdev 
sky2 rtc_cmos rtc_core intelfb i2c_i801 wlan_scan_sta iTCO_wdt snd_pcm 
snd_timer snd soundcore rtc_lib i2c_algo_bit ath_rate_sample intel_agp agpgart 
i2c_core snd_page_alloc wlan ath_hal(P) evdev ext3 jbd mbcache usbhid hid 
sd_mod ide_cd cdrom ata_piix ata_generic libata scsi_mod piix firewire_ohci 
firewire_core crc_itu_t ehci_hcd generic ide_core uhci_hcd usbcore thermal 
processor fan
Aug 20 14:14:23 cocoduo kernel: CPU:0
Aug 20 14:14:23 cocoduo kernel: EIP:0060:[c016706a]Tainted: P   
VLI
Aug 20 14:14:23 cocoduo kernel: EFLAGS: 00210092   (2.6.22-1-686 #1)
Aug 20 14:14:23 cocoduo kernel: EIP is at cache_alloc_refill+0xe9/0x451
Aug 20 14:14:23 cocoduo kernel: eax: 007f   ebx: c20bf800   ecx: df9e8d40   
edx: 
Aug 20 14:14:23 cocoduo kernel: esi: db91c000   edi: 0010   ebp: dfff1600   
esp: eecdddbc
Aug 20 14:14:23 cocoduo kernel: ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 
0068
Aug 20 14:14:23 cocoduo kernel: Process hald (pid: 5167, ti=eecdc000 
task=ef3a8a50 task.ti=eecdc000)
Aug 20 14:14:23 cocoduo kernel: Stack:   00d0 df9e8d40 
df9e0c00  c0152f3b 0044 
Aug 20 14:14:23 cocoduo kernel:00d0 c0327ff4 ef3a8a50  
00a4 df9e8d40 00200202 c210ac24 
Aug 20 14:14:23 cocoduo kernel:c0167553 00a4 0001 00a4 
c02017f4 0004 c210ac00  
Aug 20 14:14:23 cocoduo kernel: Call Trace:
Aug 20 14:14:23 cocoduo kernel:  [c0152f3b] __alloc_pages+0x52/0x294
Aug 20 14:14:23 cocoduo kernel:  [c0167553] kmem_cache_zalloc+0x42/0x79
Aug 20 14:14:23 cocoduo kernel:  [c02017f4] acpi_ps_alloc_op+0x5d/0x9e
Aug 20 14:14:23 cocoduo kernel:  [c02014a7] acpi_ps_parse_loop+0x6f6/0x737
Aug 20 14:14:23 cocoduo kernel:  [c02007b2] acpi_ps_parse_aml+0x60/0x237
Aug 20 14:14:23 cocoduo kernel:  [c01f444c] acpi_ds_init_aml_walk+0xb4/0xfe
Aug 20 14:14:23 cocoduo kernel:  [c02019f0] acpi_ps_execute_method+0x11b/0x1bb
Aug 20 14:14:23 cocoduo kernel:  [c01fed59] acpi_ns_evaluate+0x99/0xf0
Aug 20 14:14:23 cocoduo kernel:  [c01fe9c1] acpi_evaluate_object+0x139/0x1dc
Aug 20 14:14:23 cocoduo kernel:  [c01f0a6d] acpi_evaluate_integer+0x80/0xb3
Aug 20 14:14:23 cocoduo kernel:  [f8e01096] acpi_ac_get_state+0x26/0x61 [ac]
Aug 20 14:14:23 cocoduo kernel:  [c015d3ed] vma_link+0x54/0xc9
Aug 20 14:14:23 cocoduo kernel:  [f8e01130] acpi_ac_seq_show+0x12/0x4e [ac]
Aug 20 14:14:23 cocoduo kernel:  [c017fc87] seq_read+0xe7/0x274
Aug 20 14:14:23 cocoduo kernel:  [c017fba0] seq_read+0x0/0x274
Aug 20 14:14:23 cocoduo kernel:  [c016a5b9] vfs_read+0xa6/0x128
Aug 20 14:14:23 cocoduo kernel:  [c016a9b5] sys_read+0x41/0x67
Aug 20 14:14:23 cocoduo kernel:  [c0103d0e] sysenter_past_esp+0x6b/0xa1
Aug 20 14:14:23 cocoduo kernel:  ===
Aug 20 14:14:23 cocoduo kernel: Code: 00 00 00 8b 75 00 39 ee 75 15 8b 75 10 8d 
45 10 c7 45 34 01 00 00 00 39 c6 0f 84 9c 00 00 00 8b 4c 24 0c 8b 41 38 39 46 
10 72 34 0f 0b eb fe 8b 44 24 10 8b 5e 14 8b 08 8b 44 24 0c 8b 50 2c 8b 
Aug 20 14:14:23 cocoduo kernel: EIP: [c016706a] cache_alloc_refill+0xe9/0x451 
SS:ESP 0068:eecdddbc


-- 
Lionel Landwerlin

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.20 [drm:i915_wait_irq] *ERROR*

[Lionel Landwerlin]

Hi all,

I'm running a 2.6.20 kernel on my macbook. When running an openGL
application, if the opengl window's region is moved somewhere outside
the screen limits, then keyboard locks, I can only move the mouse,
nothing response. I can only reboot the box by pressing the power button
5 seconds. /var/log/syslog contains that :

kernel: [drm:i915_wait_irq] *ERROR* i915_wait_irq: EBUSY -- rec: 730561 
emitted: 730570

The macbook uses an intel card :

00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT 
Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML 
Express Integrated Graphics Controller (rev 03)

Xorg version 7.1.1

-- 
Lionel Landwerlin <[EMAIL PROTECTED]>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.20 [drm:i915_wait_irq] *ERROR*

[Lionel Landwerlin]

Hi all,

I'm running a 2.6.20 kernel on my macbook. When running an openGL
application, if the opengl window's region is moved somewhere outside
the screen limits, then keyboard locks, I can only move the mouse,
nothing response. I can only reboot the box by pressing the power button
5 seconds. /var/log/syslog contains that :

kernel: [drm:i915_wait_irq] *ERROR* i915_wait_irq: EBUSY -- rec: 730561 
emitted: 730570

The macbook uses an intel card :

00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT 
Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML 
Express Integrated Graphics Controller (rev 03)

Xorg version 7.1.1

-- 
Lionel Landwerlin [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

bug at startup after freeze

[Lionel Landwerlin]

nel: [   22.42]  [__link_path_walk+2514/3760] 
__link_path_walk+0x9d2/0xeb0
Feb  4 03:28:46 cocoduo kernel: [   22.42]  
[__do_page_cache_readahead+121/608] __do_page_cache_readahead+0x79/0x260
Feb  4 03:28:46 cocoduo kernel: [   22.42]  
[__do_page_cache_readahead+216/608] __do_page_cache_readahead+0xd8/0x260
Feb  4 03:28:46 cocoduo kernel: [   22.42]  [do_page_fault+1068/1504] 
do_page_fault+0x42c/0x5e0
Feb  4 03:28:46 cocoduo kernel: [   22.42]  [do_page_fault+0/1504] 
do_page_fault+0x0/0x5e0
Feb  4 03:28:46 cocoduo kernel: [   22.42]  [error_code+57/64] 
error_code+0x39/0x40
Feb  4 03:28:46 cocoduo kernel: [   22.42]  [file_read_actor+55/256] 
file_read_actor+0x37/0x100
Feb  4 03:28:46 cocoduo kernel: [   22.42]  
[do_generic_mapping_read+727/1408] do_generic_mapping_read+0x2d7/0x580
Feb  4 03:28:46 cocoduo kernel: [   22.42]  [generic_file_aio_read+257/624] 
generic_file_aio_read+0x101/0x270
Feb  4 03:28:46 cocoduo kernel: [   22.42]  [file_read_actor+0/256] 
file_read_actor+0x0/0x100
Feb  4 03:28:46 cocoduo kernel: [   22.42]  [do_sync_read+213/288] 
do_sync_read+0xd5/0x120
Feb  4 03:28:46 cocoduo kernel: [   22.42]  [autoremove_wake_function+0/80] 
autoremove_wake_function+0x0/0x50
Feb  4 03:28:46 cocoduo kernel: [   22.42]  [do_mmap_pgoff+1339/1952] 
do_mmap_pgoff+0x53b/0x7a0
Feb  4 03:28:46 cocoduo kernel: [   22.42]  [vfs_read+188/400] 
vfs_read+0xbc/0x190
Feb  4 03:28:46 cocoduo kernel: [   22.42]  [do_sync_read+0/288] 
do_sync_read+0x0/0x120
Feb  4 03:28:46 cocoduo kernel: [   22.42]  [sys_read+65/112] 
sys_read+0x41/0x70
Feb  4 03:28:46 cocoduo kernel: [   22.42]  [sysenter_past_esp+86/121] 
sysenter_past_esp+0x56/0x79
Feb  4 03:28:46 cocoduo kernel: [   22.42]  ===
Feb  4 03:28:46 cocoduo kernel: [   22.42] Code: 24 10 85 db 7e 47 89 f3 31 
ed c7 44 24 30 00 00 00 00 ba 03 00 00 00 89 d8 e8 0e 30 fc ff b9 00 04 00 00 
89 44 24 08 89 c7 89 e8  ab 8b 44 24 08 ba 03 00 00 00 83 c3 20 e8 7e 30 fc 
ff 83 44 
Feb  4 03:28:46 cocoduo kernel: [   22.42] EIP: 
[get_page_from_freelist+623/832] get_page_from_freelist+0x26f/0x340 SS:ESP 
0068:f2f35c90
Feb  4 03:28:46 cocoduo kernel: [   22.42]  <6>note: modprobe[2858] exited 
with preempt_count 1
Feb  4 03:28:46 cocoduo kernel: [   23.00] tpm_inf_pnp 00:03: Found TPM 
with ID IFX0101
Feb  4 03:28:46 cocoduo kernel: [   23.00] tpm_inf_pnp 00:03: TPM found: 
config base 0x4e, io base 0x4700, chip version 0x000b, vendor id 0x15d1 
(Infineon), product id 0x000b (SLB 9635 TT 1.2)
Feb  4 03:28:46 cocoduo kernel: [   23.04] Linux agpgart interface v0.101 
(c) Dave Jones
Feb  4 03:28:46 cocoduo kernel: [   23.044000] agpgart: Detected an Intel 945GM 
Chipset.
Feb  4 03:28:46 cocoduo kernel: [   23.044000] agpgart: Detected 16124K stolen 
memory.
Feb  4 03:28:46 cocoduo kernel: [   23.06] agpgart: AGP aperture is 256M @ 
0x8000
-- 
Lionel Landwerlin <[EMAIL PROTECTED]>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

bug at startup after freeze

[Lionel Landwerlin]

]  
[__do_page_cache_readahead+121/608] __do_page_cache_readahead+0x79/0x260
Feb  4 03:28:46 cocoduo kernel: [   22.42]  
[__do_page_cache_readahead+216/608] __do_page_cache_readahead+0xd8/0x260
Feb  4 03:28:46 cocoduo kernel: [   22.42]  [do_page_fault+1068/1504] 
do_page_fault+0x42c/0x5e0
Feb  4 03:28:46 cocoduo kernel: [   22.42]  [do_page_fault+0/1504] 
do_page_fault+0x0/0x5e0
Feb  4 03:28:46 cocoduo kernel: [   22.42]  [error_code+57/64] 
error_code+0x39/0x40
Feb  4 03:28:46 cocoduo kernel: [   22.42]  [file_read_actor+55/256] 
file_read_actor+0x37/0x100
Feb  4 03:28:46 cocoduo kernel: [   22.42]  
[do_generic_mapping_read+727/1408] do_generic_mapping_read+0x2d7/0x580
Feb  4 03:28:46 cocoduo kernel: [   22.42]  [generic_file_aio_read+257/624] 
generic_file_aio_read+0x101/0x270
Feb  4 03:28:46 cocoduo kernel: [   22.42]  [file_read_actor+0/256] 
file_read_actor+0x0/0x100
Feb  4 03:28:46 cocoduo kernel: [   22.42]  [do_sync_read+213/288] 
do_sync_read+0xd5/0x120
Feb  4 03:28:46 cocoduo kernel: [   22.42]  [autoremove_wake_function+0/80] 
autoremove_wake_function+0x0/0x50
Feb  4 03:28:46 cocoduo kernel: [   22.42]  [do_mmap_pgoff+1339/1952] 
do_mmap_pgoff+0x53b/0x7a0
Feb  4 03:28:46 cocoduo kernel: [   22.42]  [vfs_read+188/400] 
vfs_read+0xbc/0x190
Feb  4 03:28:46 cocoduo kernel: [   22.42]  [do_sync_read+0/288] 
do_sync_read+0x0/0x120
Feb  4 03:28:46 cocoduo kernel: [   22.42]  [sys_read+65/112] 
sys_read+0x41/0x70
Feb  4 03:28:46 cocoduo kernel: [   22.42]  [sysenter_past_esp+86/121] 
sysenter_past_esp+0x56/0x79
Feb  4 03:28:46 cocoduo kernel: [   22.42]  ===
Feb  4 03:28:46 cocoduo kernel: [   22.42] Code: 24 10 85 db 7e 47 89 f3 31 
ed c7 44 24 30 00 00 00 00 ba 03 00 00 00 89 d8 e8 0e 30 fc ff b9 00 04 00 00 
89 44 24 08 89 c7 89 e8 f3 ab 8b 44 24 08 ba 03 00 00 00 83 c3 20 e8 7e 30 fc 
ff 83 44 
Feb  4 03:28:46 cocoduo kernel: [   22.42] EIP: 
[get_page_from_freelist+623/832] get_page_from_freelist+0x26f/0x340 SS:ESP 
0068:f2f35c90
Feb  4 03:28:46 cocoduo kernel: [   22.42]  6note: modprobe[2858] exited 
with preempt_count 1
Feb  4 03:28:46 cocoduo kernel: [   23.00] tpm_inf_pnp 00:03: Found TPM 
with ID IFX0101
Feb  4 03:28:46 cocoduo kernel: [   23.00] tpm_inf_pnp 00:03: TPM found: 
config base 0x4e, io base 0x4700, chip version 0x000b, vendor id 0x15d1 
(Infineon), product id 0x000b (SLB 9635 TT 1.2)
Feb  4 03:28:46 cocoduo kernel: [   23.04] Linux agpgart interface v0.101 
(c) Dave Jones
Feb  4 03:28:46 cocoduo kernel: [   23.044000] agpgart: Detected an Intel 945GM 
Chipset.
Feb  4 03:28:46 cocoduo kernel: [   23.044000] agpgart: Detected 16124K stolen 
memory.
Feb  4 03:28:46 cocoduo kernel: [   23.06] agpgart: AGP aperture is 256M @ 
0x8000
-- 
Lionel Landwerlin [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: sky2 or acpi problem ?

[Lionel Landwerlin]

Le jeudi 01 février 2007 à 19:20 +0100, Fagyal Csongor a écrit :
> Lionel Landwerlin wrote:

> I have idle=poll now, according to this thread:
> 
> http://www.gossamer-threads.com/lists/linux/kernel/725399
> 
> 
> No lockup so far, but I only have this setting since yesterday...
> 

I tried idle=poll too, same effect than disable_msi=1, tested a couple
of hours only, maybe this leads to crash too. But anyway this is simply
unusable on a laptop (macbook), fan is running almost at full speed...


-- 
Lionel Landwerlin <[EMAIL PROTECTED]>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

sky2 or acpi problem ?

[Lionel Landwerlin]

Hi,
we already had words on lkml about this bug with sky2 driver.

I was having problems, and you told me to use the disable_msi=1
parameter to see what happens. After a couple of hours of testing with
heavly ethernet load, I answered you it had fixed the problem. I was
wrong. Now, it takes much more time to crash. Most of time, I can't even
see what happens beacause the box is completly frozen. But after several
crashs, I only had my keyboard locked, usb unpowered, and ethernet
interface down, I finally had the possibility see that :

Feb  1 18:35:06 cocoduo kernel: [59723.468000] NETDEV WATCHDOG: eth0: transmit 
timed out
Feb  1 18:35:07 cocoduo kernel: [59723.468000] sky2 eth0: tx timeout
Feb  1 18:35:07 cocoduo kernel: [59723.468000] sky2 eth0: transmit ring 64 .. 
41 report=65 done=65
Feb  1 18:35:07 cocoduo kernel: [59723.468000] sky2 status report lost?
Feb  1 18:35:16 cocoduo kernel: [59733.20] BUG: soft lockup detected on 
CPU#0!
Feb  1 18:35:16 cocoduo kernel: [59733.20]  [softlockup_tick+155/208] 
softlockup_tick+0x9b/0xd0
Feb  1 18:35:16 cocoduo kernel: [59733.20]  [update_process_times+49/128] 
update_process_times+0x31/0x80
Feb  1 18:35:16 cocoduo kernel: [59733.20]  
[smp_apic_timer_interrupt+145/176] smp_apic_timer_interrupt+0x91/0xb0
Feb  1 18:35:16 cocoduo kernel: [59733.20]  [apic_timer_interrupt+31/36] 
apic_timer_interrupt+0x1f/0x24
Feb  1 18:35:16 cocoduo kernel: [59733.20]  [_spin_lock_bh+15/32] 
_spin_lock_bh+0xf/0x20
Feb  1 18:35:16 cocoduo kernel: [59733.20]  [pg0+945481365/1068803072] 
sky2_tx_timeout+0xf5/0x1d0 [sky2]
Feb  1 18:35:16 cocoduo kernel: [59733.20]  [dev_watchdog+0/208] 
dev_watchdog+0x0/0xd0
Feb  1 18:35:16 cocoduo kernel: [59733.20]  [dev_watchdog+192/208] 
dev_watchdog+0xc0/0xd0
Feb  1 18:35:16 cocoduo kernel: [59733.20]  [run_timer_softirq+273/400] 
run_timer_softirq+0x111/0x190
Feb  1 18:35:16 cocoduo kernel: [59733.20]  [__do_softirq+116/240] 
__do_softirq+0x74/0xf0
Feb  1 18:35:16 cocoduo kernel: [59733.20]  [do_softirq+59/80] 
do_softirq+0x3b/0x50
Feb  1 18:35:16 cocoduo kernel: [59733.20]  
[smp_apic_timer_interrupt+150/176] smp_apic_timer_interrupt+0x96/0xb0
Feb  1 18:35:16 cocoduo kernel: [59733.20]  [apic_timer_interrupt+31/36] 
apic_timer_interrupt+0x1f/0x24
Feb  1 18:35:16 cocoduo kernel: [59733.20]  [pg0+943208348/1068803072] 
acpi_processor_idle+0x1fd/0x3b9 [processor]
Feb  1 18:35:16 cocoduo kernel: [59733.20]  [cpu_idle+116/208] 
cpu_idle+0x74/0xd0
Feb  1 18:35:16 cocoduo kernel: [59733.20]  [start_kernel+872/1072] 
start_kernel+0x368/0x430
Feb  1 18:35:16 cocoduo kernel: [59733.20]  [unknown_bootoption+0/624] 
unknown_bootoption+0x0/0x270

It's exactly the same error than before. What do you think of this
trace ? Is it related to sky2 driver or acpi ? Did you add debug output
since 2.6.19.2 (version of the kernel I'm using) that would help to fix
that bug ? What can I do to help to fix the bug ?

Regards,

-- 
Lionel Landwerlin <[EMAIL PROTECTED]>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

sky2 or acpi problem ?

[Lionel Landwerlin]

Hi,
we already had words on lkml about this bug with sky2 driver.

I was having problems, and you told me to use the disable_msi=1
parameter to see what happens. After a couple of hours of testing with
heavly ethernet load, I answered you it had fixed the problem. I was
wrong. Now, it takes much more time to crash. Most of time, I can't even
see what happens beacause the box is completly frozen. But after several
crashs, I only had my keyboard locked, usb unpowered, and ethernet
interface down, I finally had the possibility see that :

Feb  1 18:35:06 cocoduo kernel: [59723.468000] NETDEV WATCHDOG: eth0: transmit 
timed out
Feb  1 18:35:07 cocoduo kernel: [59723.468000] sky2 eth0: tx timeout
Feb  1 18:35:07 cocoduo kernel: [59723.468000] sky2 eth0: transmit ring 64 .. 
41 report=65 done=65
Feb  1 18:35:07 cocoduo kernel: [59723.468000] sky2 status report lost?
Feb  1 18:35:16 cocoduo kernel: [59733.20] BUG: soft lockup detected on 
CPU#0!
Feb  1 18:35:16 cocoduo kernel: [59733.20]  [softlockup_tick+155/208] 
softlockup_tick+0x9b/0xd0
Feb  1 18:35:16 cocoduo kernel: [59733.20]  [update_process_times+49/128] 
update_process_times+0x31/0x80
Feb  1 18:35:16 cocoduo kernel: [59733.20]  
[smp_apic_timer_interrupt+145/176] smp_apic_timer_interrupt+0x91/0xb0
Feb  1 18:35:16 cocoduo kernel: [59733.20]  [apic_timer_interrupt+31/36] 
apic_timer_interrupt+0x1f/0x24
Feb  1 18:35:16 cocoduo kernel: [59733.20]  [_spin_lock_bh+15/32] 
_spin_lock_bh+0xf/0x20
Feb  1 18:35:16 cocoduo kernel: [59733.20]  [pg0+945481365/1068803072] 
sky2_tx_timeout+0xf5/0x1d0 [sky2]
Feb  1 18:35:16 cocoduo kernel: [59733.20]  [dev_watchdog+0/208] 
dev_watchdog+0x0/0xd0
Feb  1 18:35:16 cocoduo kernel: [59733.20]  [dev_watchdog+192/208] 
dev_watchdog+0xc0/0xd0
Feb  1 18:35:16 cocoduo kernel: [59733.20]  [run_timer_softirq+273/400] 
run_timer_softirq+0x111/0x190
Feb  1 18:35:16 cocoduo kernel: [59733.20]  [__do_softirq+116/240] 
__do_softirq+0x74/0xf0
Feb  1 18:35:16 cocoduo kernel: [59733.20]  [do_softirq+59/80] 
do_softirq+0x3b/0x50
Feb  1 18:35:16 cocoduo kernel: [59733.20]  
[smp_apic_timer_interrupt+150/176] smp_apic_timer_interrupt+0x96/0xb0
Feb  1 18:35:16 cocoduo kernel: [59733.20]  [apic_timer_interrupt+31/36] 
apic_timer_interrupt+0x1f/0x24
Feb  1 18:35:16 cocoduo kernel: [59733.20]  [pg0+943208348/1068803072] 
acpi_processor_idle+0x1fd/0x3b9 [processor]
Feb  1 18:35:16 cocoduo kernel: [59733.20]  [cpu_idle+116/208] 
cpu_idle+0x74/0xd0
Feb  1 18:35:16 cocoduo kernel: [59733.20]  [start_kernel+872/1072] 
start_kernel+0x368/0x430
Feb  1 18:35:16 cocoduo kernel: [59733.20]  [unknown_bootoption+0/624] 
unknown_bootoption+0x0/0x270

It's exactly the same error than before. What do you think of this
trace ? Is it related to sky2 driver or acpi ? Did you add debug output
since 2.6.19.2 (version of the kernel I'm using) that would help to fix
that bug ? What can I do to help to fix the bug ?

Regards,

-- 
Lionel Landwerlin [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: sky2 or acpi problem ?

[Lionel Landwerlin]

Le jeudi 01 février 2007 à 19:20 +0100, Fagyal Csongor a écrit :
 Lionel Landwerlin wrote:

 I have idle=poll now, according to this thread:
 
 http://www.gossamer-threads.com/lists/linux/kernel/725399
 
 
 No lockup so far, but I only have this setting since yesterday...
 

I tried idle=poll too, same effect than disable_msi=1, tested a couple
of hours only, maybe this leads to crash too. But anyway this is simply
unusable on a laptop (macbook), fan is running almost at full speed...


-- 
Lionel Landwerlin [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.19.2 sky2/acpi crashes

[Lionel Landwerlin]

Le mardi 23 janvier 2007 à 21:36 -0500, Len Brown a écrit :
> > > > Apple Macbook 2GHz (x86, not amd64)
> 
> > > > > > Please try to remove processor module.
> > > > >
> > > > > Ok, that's done. Same problem.
> > > >
> > > > any difference with "idle=poll"?
> > > > if yes, how about "idle=halt"?
> > >
> > > idle=poll seems to fix the problem (cpu fan is running almost at full
> > > speed). Maybe I should run a longer test... For now it consists to run
> > > about 15 torrents and watching HDTV through ethernet device.
> > >
> > > idle=halt does not :
> > 
> > It sounds like issues relative to Processor C state.
> > Please enter a bug in ACPI category on bugzilla.kernel.org
> 
> Actually, the test above with the processor module removed proved
> that it isn't ACPI C-states -- as they will not be available.
> You should be able to observe that /proc/acpi/processor/*/power
> does not indicate any C-state use when processor is unloaded.
> 
> My guess was that some deep C-state with long exit latency
> was interfering with the device.  booting w/o the processor
> module should have left you running the native mwait idle.
> booting with idle=halt should have left you running the HLT idle.
> booting with idle=poll is a busy spin loop that never enters
> any hardware power saving state.
> 
> I'm quite puzzled that idle=halt was not sufficient to solve the issue,
> because that should be the lowest exit latency idle loop.
> So maybe I'm wrong about the cause -- though I can't then
> explain why idle=poll helps...
> 
> All of the idle selection options cause the kernel to print
> a line with the word "idle" in it.  Perhaps you could search
> your dmesg for "idle" to verify that it is running what we
> think it is?

Here I join the complete log for idle=halt

I'm running idle=poll for more 1 hour now with heavy ethernet load, no
crash. It usualy happens in 10~15mn with idle=halt and 4~5mn with no
idle option.

-- 
Lionel Landwerlin <[EMAIL PROTECTED]>
Jan 24 01:11:21 cocoduo syslogd 1.4.1#18ubuntu6: restart.
Jan 24 01:11:21 cocoduo kernel: Inspecting /boot/System.map-2.6.19.2-mactel
Jan 24 01:11:21 cocoduo kernel: Loaded 24013 symbols from 
/boot/System.map-2.6.19.2-mactel.
Jan 24 01:11:21 cocoduo kernel: Symbols match kernel version 2.6.19.
Jan 24 01:11:21 cocoduo kernel: No module symbols loaded - kernel modules not 
enabled. 
Jan 24 01:11:21 cocoduo kernel: [0.00] Linux version 2.6.19.2-mactel 
([EMAIL PROTECTED]) (gcc version 4.1.2 20060928 (prerelease) (Ubuntu 
4.1.1-13ubuntu5)) #2 SMP Mon Jan 22 11:08:41 CET 2007
Jan 24 01:11:21 cocoduo kernel: [0.00] BIOS-provided physical RAM map:
Jan 24 01:11:21 cocoduo kernel: [0.00]  BIOS-e820:  - 
0009fc00 (usable)
Jan 24 01:11:21 cocoduo kernel: [0.00]  BIOS-e820: 0009fc00 - 
000a (reserved)
Jan 24 01:11:21 cocoduo kernel: [0.00]  BIOS-e820: 000ede00 - 
0010 (reserved)
Jan 24 01:11:21 cocoduo kernel: [0.00]  BIOS-e820: 0010 - 
7dfdc000 (usable)
Jan 24 01:11:21 cocoduo kernel: [0.00]  BIOS-e820: 7dfdc000 - 
7e1dd000 (ACPI NVS)
Jan 24 01:11:21 cocoduo kernel: [0.00]  BIOS-e820: 7e1dd000 - 
7eebf000 (ACPI data)
Jan 24 01:11:21 cocoduo kernel: [0.00]  BIOS-e820: 7eebf000 - 
7eeef000 (ACPI NVS)
Jan 24 01:11:21 cocoduo kernel: [0.00]  BIOS-e820: 7eeef000 - 
7ef0 (ACPI data)
Jan 24 01:11:21 cocoduo kernel: [0.00]  BIOS-e820: 7ef0 - 
8000 (reserved)
Jan 24 01:11:21 cocoduo kernel: [0.00]  BIOS-e820: e000 - 
f000 (reserved)
Jan 24 01:11:21 cocoduo kernel: [0.00]  BIOS-e820: fec0 - 
fec01000 (reserved)
Jan 24 01:11:21 cocoduo kernel: [0.00]  BIOS-e820: fed14000 - 
fed1a000 (reserved)
Jan 24 01:11:21 cocoduo kernel: [0.00]  BIOS-e820: fed1c000 - 
fed2 (reserved)
Jan 24 01:11:21 cocoduo kernel: [0.00]  BIOS-e820: fee0 - 
fee01000 (reserved)
Jan 24 01:11:21 cocoduo kernel: [0.00]  BIOS-e820: ffe0 - 
0001 (reserved)
Jan 24 01:11:21 cocoduo kernel: [0.00] 1119MB HIGHMEM available.
Jan 24 01:11:21 cocoduo kernel: [0.00] 896MB LOWMEM available.
Jan 24 01:11:21 cocoduo kernel: [0.00] Entering add_active_range(0, 0, 
516060) 0 entries of 256 used
Jan 24 01:11:21 cocoduo kernel: [0.00] Zone PFN ranges:
Jan 24 01:11:21 cocoduo kernel: [0.00]   DMA 0 -> 4096
Jan 24 01:11:21 cocoduo kernel: [0.00]   Normal  

Re: 2.6.19.2 sky2/acpi crashes

[Lionel Landwerlin]

Le mardi 23 janvier 2007 à 21:36 -0500, Len Brown a écrit :
Apple Macbook 2GHz (x86, not amd64)
 
  Please try to remove processor module.

 Ok, that's done. Same problem.
   
any difference with idle=poll?
if yes, how about idle=halt?
  
   idle=poll seems to fix the problem (cpu fan is running almost at full
   speed). Maybe I should run a longer test... For now it consists to run
   about 15 torrents and watching HDTV through ethernet device.
  
   idle=halt does not :
  
  It sounds like issues relative to Processor C state.
  Please enter a bug in ACPI category on bugzilla.kernel.org
 
 Actually, the test above with the processor module removed proved
 that it isn't ACPI C-states -- as they will not be available.
 You should be able to observe that /proc/acpi/processor/*/power
 does not indicate any C-state use when processor is unloaded.
 
 My guess was that some deep C-state with long exit latency
 was interfering with the device.  booting w/o the processor
 module should have left you running the native mwait idle.
 booting with idle=halt should have left you running the HLT idle.
 booting with idle=poll is a busy spin loop that never enters
 any hardware power saving state.
 
 I'm quite puzzled that idle=halt was not sufficient to solve the issue,
 because that should be the lowest exit latency idle loop.
 So maybe I'm wrong about the cause -- though I can't then
 explain why idle=poll helps...
 
 All of the idle selection options cause the kernel to print
 a line with the word idle in it.  Perhaps you could search
 your dmesg for idle to verify that it is running what we
 think it is?

Here I join the complete log for idle=halt

I'm running idle=poll for more 1 hour now with heavy ethernet load, no
crash. It usualy happens in 10~15mn with idle=halt and 4~5mn with no
idle option.

-- 
Lionel Landwerlin [EMAIL PROTECTED]
Jan 24 01:11:21 cocoduo syslogd 1.4.1#18ubuntu6: restart.
Jan 24 01:11:21 cocoduo kernel: Inspecting /boot/System.map-2.6.19.2-mactel
Jan 24 01:11:21 cocoduo kernel: Loaded 24013 symbols from 
/boot/System.map-2.6.19.2-mactel.
Jan 24 01:11:21 cocoduo kernel: Symbols match kernel version 2.6.19.
Jan 24 01:11:21 cocoduo kernel: No module symbols loaded - kernel modules not 
enabled. 
Jan 24 01:11:21 cocoduo kernel: [0.00] Linux version 2.6.19.2-mactel 
([EMAIL PROTECTED]) (gcc version 4.1.2 20060928 (prerelease) (Ubuntu 
4.1.1-13ubuntu5)) #2 SMP Mon Jan 22 11:08:41 CET 2007
Jan 24 01:11:21 cocoduo kernel: [0.00] BIOS-provided physical RAM map:
Jan 24 01:11:21 cocoduo kernel: [0.00]  BIOS-e820:  - 
0009fc00 (usable)
Jan 24 01:11:21 cocoduo kernel: [0.00]  BIOS-e820: 0009fc00 - 
000a (reserved)
Jan 24 01:11:21 cocoduo kernel: [0.00]  BIOS-e820: 000ede00 - 
0010 (reserved)
Jan 24 01:11:21 cocoduo kernel: [0.00]  BIOS-e820: 0010 - 
7dfdc000 (usable)
Jan 24 01:11:21 cocoduo kernel: [0.00]  BIOS-e820: 7dfdc000 - 
7e1dd000 (ACPI NVS)
Jan 24 01:11:21 cocoduo kernel: [0.00]  BIOS-e820: 7e1dd000 - 
7eebf000 (ACPI data)
Jan 24 01:11:21 cocoduo kernel: [0.00]  BIOS-e820: 7eebf000 - 
7eeef000 (ACPI NVS)
Jan 24 01:11:21 cocoduo kernel: [0.00]  BIOS-e820: 7eeef000 - 
7ef0 (ACPI data)
Jan 24 01:11:21 cocoduo kernel: [0.00]  BIOS-e820: 7ef0 - 
8000 (reserved)
Jan 24 01:11:21 cocoduo kernel: [0.00]  BIOS-e820: e000 - 
f000 (reserved)
Jan 24 01:11:21 cocoduo kernel: [0.00]  BIOS-e820: fec0 - 
fec01000 (reserved)
Jan 24 01:11:21 cocoduo kernel: [0.00]  BIOS-e820: fed14000 - 
fed1a000 (reserved)
Jan 24 01:11:21 cocoduo kernel: [0.00]  BIOS-e820: fed1c000 - 
fed2 (reserved)
Jan 24 01:11:21 cocoduo kernel: [0.00]  BIOS-e820: fee0 - 
fee01000 (reserved)
Jan 24 01:11:21 cocoduo kernel: [0.00]  BIOS-e820: ffe0 - 
0001 (reserved)
Jan 24 01:11:21 cocoduo kernel: [0.00] 1119MB HIGHMEM available.
Jan 24 01:11:21 cocoduo kernel: [0.00] 896MB LOWMEM available.
Jan 24 01:11:21 cocoduo kernel: [0.00] Entering add_active_range(0, 0, 
516060) 0 entries of 256 used
Jan 24 01:11:21 cocoduo kernel: [0.00] Zone PFN ranges:
Jan 24 01:11:21 cocoduo kernel: [0.00]   DMA 0 - 4096
Jan 24 01:11:21 cocoduo kernel: [0.00]   Normal   4096 -   229376
Jan 24 01:11:21 cocoduo kernel: [0.00]   HighMem229376 -   516060
Jan 24 01:11:21 cocoduo kernel: [0.00] early_node_map[1] active PFN 
ranges
Jan 24 01:11:21 cocoduo kernel: [0.00] 0:0 -   516060
Jan 24 01:11:21 cocoduo kernel: [0.00] On node 0 totalpages: 516060
Jan 24 01:11:21 cocoduo kernel: [0.00]   DMA zone

Re: 2.6.19.2 sky2/acpi crashes

[Lionel Landwerlin]

Le mardi 23 janvier 2007 à 16:30 -0500, Len Brown a écrit : 
> On Tuesday 23 January 2007 07:27, Lionel Landwerlin wrote:
> > Le mardi 23 janvier 2007 à 17:22 +0800, Luming Yu a écrit :
> > > Please try to remove processor module.
> > 
> > Ok, that's done. Same problem.
> 
> any difference with "idle=poll"?
> if yes, how about "idle=halt"?

idle=poll seems to fix the problem (cpu fan is running almost at full
speed). Maybe I should run a longer test... For now it consists to run
about 15 torrents and watching HDTV through ethernet device.

idle=halt does not : 

Jan 24 01:37:02 cocoduo kernel: [ 1562.672639] NETDEV WATCHDOG: eth0: transmit 
timed out
Jan 24 01:37:02 cocoduo kernel: [ 1562.672648] sky2 eth0: tx timeout
Jan 24 01:37:02 cocoduo kernel: [ 1562.672656] sky2 eth0: transmit ring 243 .. 
222 report=244 done=244
Jan 24 01:37:02 cocoduo kernel: [ 1562.672660] sky2 status report lost?
Jan 24 01:37:11 cocoduo kernel: [ 1571.787958] BUG: soft lockup detected on 
CPU#0!
Jan 24 01:37:11 cocoduo kernel: [ 1571.787989]  [softlockup_tick+155/208] 
softlockup_tick+0x9b/0xd0
Jan 24 01:37:11 cocoduo kernel: [ 1571.788007]  [update_process_times+49/128] 
update_process_times+0x31/0x80
Jan 24 01:37:11 cocoduo kernel: [ 1571.788020]  
[smp_apic_timer_interrupt+145/176] smp_apic_timer_interrupt+0x91/0xb0
Jan 24 01:37:11 cocoduo kernel: [ 1571.788032]  [apic_timer_interrupt+31/36] 
apic_timer_interrupt+0x1f/0x24
Jan 24 01:37:11 cocoduo kernel: [ 1571.788048]  [_spin_lock_bh+15/32] 
_spin_lock_bh+0xf/0x20
Jan 24 01:37:11 cocoduo kernel: [ 1571.788061]  [pg0+946730645/1068803072] 
sky2_tx_timeout+0xf5/0x1d0 [sky2]
Jan 24 01:37:11 cocoduo kernel: [ 1571.788083]  [dev_watchdog+0/208] 
dev_watchdog+0x0/0xd0
Jan 24 01:37:11 cocoduo kernel: [ 1571.788090]  [dev_watchdog+192/208] 
dev_watchdog+0xc0/0xd0
Jan 24 01:37:11 cocoduo kernel: [ 1571.788099]  [run_timer_softirq+273/400] 
run_timer_softirq+0x111/0x190
Jan 24 01:37:11 cocoduo kernel: [ 1571.788114]  [__do_softirq+116/240] 
__do_softirq+0x74/0xf0
Jan 24 01:37:11 cocoduo kernel: [ 1571.788125]  [do_softirq+59/80] 
do_softirq+0x3b/0x50
Jan 24 01:37:11 cocoduo kernel: [ 1571.788134]  
[smp_apic_timer_interrupt+150/176] smp_apic_timer_interrupt+0x96/0xb0
Jan 24 01:37:11 cocoduo kernel: [ 1571.788143]  [apic_timer_interrupt+31/36] 
apic_timer_interrupt+0x1f/0x24
Jan 24 01:37:11 cocoduo kernel: [ 1571.788153]  [default_idle+0/112] 
default_idle+0x0/0x70
Jan 24 01:37:11 cocoduo kernel: [ 1571.788166]  [default_idle+54/112] 
default_idle+0x36/0x70
Jan 24 01:37:11 cocoduo kernel: [ 1571.788175]  [cpu_idle+116/208] 
cpu_idle+0x74/0xd0
Jan 24 01:37:11 cocoduo kernel: [ 1571.788184]  [start_kernel+872/1072] 
start_kernel+0x368/0x430
Jan 24 01:37:11 cocoduo kernel: [ 1571.788194]  [unknown_bootoption+0/624] 
unknown_bootoption+0x0/0x270
Jan 24 01:37:11 cocoduo kernel: [ 1571.788208]  ===

-- 
Lionel Landwerlin <[EMAIL PROTECTED]>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.19.2 sky2/acpi crashes

[Lionel Landwerlin]

Le mardi 23 janvier 2007 à 17:22 +0800, Luming Yu a écrit :
> Please try to remove processor module.

Ok, that's done. Same problem.

Just to show you I did not forget to remove processor.ko from initrd
image, I tried to load speedstep_centrino :

Jan 23 13:09:58 cocoduo kernel: [  105.697279] speedstep_centrino:
Unknown symbol acpi_processor_notify_smm
Jan 23 13:09:58 cocoduo kernel: [  105.697324] speedstep_centrino:
Unknown symbol acpi_processor_unregister_performance
Jan 23 13:09:58 cocoduo kernel: [  105.697411] speedstep_centrino:
Unknown symbol acpi_processor_preregister_performance
Jan 23 13:09:58 cocoduo kernel: [  105.697464] speedstep_centrino:
Unknown symbol acpi_processor_register_performance
Jan 23 13:15:51 cocoduo kernel: [  458.267151] NETDEV WATCHDOG: eth0:
transmit timed out
Jan 23 13:15:51 cocoduo kernel: [  458.267157] sky2 eth0: tx timeout
Jan 23 13:15:51 cocoduo kernel: [  458.267164] sky2 eth0: transmit ring
421 .. 398 report=422 done=422
Jan 23 13:15:51 cocoduo kernel: [  458.267166] sky2 status report lost?
Jan 23 13:16:00 cocoduo kernel: [  466.730622] BUG: soft lockup detected
on CPU#0!
Jan 23 13:16:00 cocoduo kernel: [  466.730644]  [softlockup_tick
+155/208] softlockup_tick+0x9b/0xd0
Jan 23 13:16:00 cocoduo kernel: [  466.730656]  [update_process_times
+49/128] update_process_times+0x31/0x80
Jan 23 13:16:00 cocoduo kernel: [  466.730666]
[smp_apic_timer_interrupt+145/176] smp_apic_timer_interrupt+0x91/0xb0
Jan 23 13:16:00 cocoduo kernel: [  466.730674]  [apic_timer_interrupt
+31/36] apic_timer_interrupt+0x1f/0x24
Jan 23 13:16:00 cocoduo kernel: [  466.730684]  [_spin_lock_bh+18/32]
_spin_lock_bh+0x12/0x20
Jan 23 13:16:00 cocoduo kernel: [  466.730693]  [pg0
+945944213/1068803072] sky2_tx_timeout+0xf5/0x1d0 [sky2]
Jan 23 13:16:00 cocoduo kernel: [  466.730707]  [dev_watchdog+0/208]
dev_watchdog+0x0/0xd0
Jan 23 13:16:00 cocoduo kernel: [  466.730712]  [dev_watchdog+192/208]
dev_watchdog+0xc0/0xd0
Jan 23 13:16:00 cocoduo kernel: [  466.730718]  [run_timer_softirq
+273/400] run_timer_softirq+0x111/0x190
Jan 23 13:16:00 cocoduo kernel: [  466.730728]  [__do_softirq+116/240]
__do_softirq+0x74/0xf0
Jan 23 13:16:00 cocoduo kernel: [  466.730734]  [do_softirq+59/80]
do_softirq+0x3b/0x50
Jan 23 13:16:00 cocoduo kernel: [  466.730739]
[smp_apic_timer_interrupt+150/176] smp_apic_timer_interrupt+0x96/0xb0
Jan 23 13:16:00 cocoduo kernel: [  466.730746]  [apic_timer_interrupt
+31/36] apic_timer_interrupt+0x1f/0x24
Jan 23 13:16:00 cocoduo kernel: [  466.730756]  [mwait_idle_with_hints
+70/96] mwait_idle_with_hints+0x46/0x60
Jan 23 13:16:00 cocoduo kernel: [  466.730762]  [mwait_idle+12/32]
mwait_idle+0xc/0x20
Jan 23 13:16:00 cocoduo kernel: [  466.730766]  [cpu_idle+116/208]
cpu_idle+0x74/0xd0
Jan 23 13:16:00 cocoduo kernel: [  466.730773]  [start_kernel+872/1072]
start_kernel+0x368/0x430
Jan 23 13:16:00 cocoduo kernel: [  466.730780]  [unknown_bootoption
+0/624] unknown_bootoption+0x0/0x270
Jan 23 13:16:00 cocoduo kernel: [  466.730790]  ===


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.19.2 sky2/acpi crashes

[Lionel Landwerlin]

Hi,

I'm running a macbook with a Marvell ethernet controller, and I have a
lots of freezes when using the ethernet controller under a load of
~100K/s. Since I'm running a 2.6.19.2 kernel, I'm able to get some
report from the kernel. Here they are :

Jan 23 09:30:57 cocoduo kernel: [  662.92] NETDEV WATCHDOG: eth0:
transmit timed out
Jan 23 09:30:57 cocoduo kernel: [  662.92] sky2 eth0: tx timeout
Jan 23 09:30:57 cocoduo kernel: [  662.92] sky2 eth0: transmit ring
493 .. 471 report=494 done=494
Jan 23 09:30:57 cocoduo kernel: [  662.92] sky2 status report lost?
Jan 23 09:31:06 cocoduo kernel: [  672.832000] BUG: soft lockup detected
on CPU#0!
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [softlockup_tick
+155/208] softlockup_tick+0x9b/0xd0
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [update_process_times
+49/128] update_process_times+0x31/0x80
Jan 23 09:31:06 cocoduo kernel: [  672.832000]
[smp_apic_timer_interrupt+145/176] smp_apic_timer_interrupt+0x91/0xb0
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [apic_timer_interrupt
+31/36] apic_timer_interrupt+0x1f/0x24
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [_spin_lock_bh+18/32]
_spin_lock_bh+0x12/0x20
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [pg0
+946878101/1068803072] sky2_tx_timeout+0xf5/0x1d0 [sky2]
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [dev_watchdog+0/208]
dev_watchdog+0x0/0xd0
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [dev_watchdog+192/208]
dev_watchdog+0xc0/0xd0
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [run_timer_softirq
+273/400] run_timer_softirq+0x111/0x190
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [__do_softirq+116/240]
__do_softirq+0x74/0xf0
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [do_softirq+59/80]
do_softirq+0x3b/0x50
Jan 23 09:31:06 cocoduo kernel: [  672.832000]
[smp_apic_timer_interrupt+150/176] smp_apic_timer_interrupt+0x96/0xb0
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [apic_timer_interrupt
+31/36] apic_timer_interrupt+0x1f/0x24
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [pg0
+943208348/1068803072] acpi_processor_idle+0x1fd/0x3b9 [processor]
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [cpu_idle+116/208]
cpu_idle+0x74/0xd0
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [start_kernel+872/1072]
start_kernel+0x368/0x430
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [unknown_bootoption
+0/624] unknown_bootoption+0x0/0x270
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  ===

As most of the time, the keyboard gets locked and the network driver is
down, I can get more informations.

Here my hardware configuration :

Apple Macbook 2GHz (x86, not amd64)
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and
945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile
945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML
Express Integrated Graphics Controller (rev 03)
00:07.0 Performance counters: Intel Corporation Unknown device 27a3 (rev
03)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High
Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express
Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express
Port 2 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
#1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
#2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
#3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
#4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI
Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface
Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE
Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family)
Serial ATA Storage Controller IDE (rev 02)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller
(rev 02)
01:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E
Gigabit Ethernet Controller (rev 22)
02:00.0 Ethernet controller: Atheros Communications, Inc. Unknown device
001c (rev 01)
03:03.0 FireWire (IEEE 1394): Agere Systems FW323 (rev 61)

I hope some fix could be released soon.

-- 
Lionel Landwerlin <[EMAIL PROTECTED]>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.19.2 sky2/acpi crashes

[Lionel Landwerlin]

Le mardi 23 janvier 2007 à 16:30 -0500, Len Brown a écrit : 
 On Tuesday 23 January 2007 07:27, Lionel Landwerlin wrote:
  Le mardi 23 janvier 2007 à 17:22 +0800, Luming Yu a écrit :
   Please try to remove processor module.
  
  Ok, that's done. Same problem.
 
 any difference with idle=poll?
 if yes, how about idle=halt?

idle=poll seems to fix the problem (cpu fan is running almost at full
speed). Maybe I should run a longer test... For now it consists to run
about 15 torrents and watching HDTV through ethernet device.

idle=halt does not : 

Jan 24 01:37:02 cocoduo kernel: [ 1562.672639] NETDEV WATCHDOG: eth0: transmit 
timed out
Jan 24 01:37:02 cocoduo kernel: [ 1562.672648] sky2 eth0: tx timeout
Jan 24 01:37:02 cocoduo kernel: [ 1562.672656] sky2 eth0: transmit ring 243 .. 
222 report=244 done=244
Jan 24 01:37:02 cocoduo kernel: [ 1562.672660] sky2 status report lost?
Jan 24 01:37:11 cocoduo kernel: [ 1571.787958] BUG: soft lockup detected on 
CPU#0!
Jan 24 01:37:11 cocoduo kernel: [ 1571.787989]  [softlockup_tick+155/208] 
softlockup_tick+0x9b/0xd0
Jan 24 01:37:11 cocoduo kernel: [ 1571.788007]  [update_process_times+49/128] 
update_process_times+0x31/0x80
Jan 24 01:37:11 cocoduo kernel: [ 1571.788020]  
[smp_apic_timer_interrupt+145/176] smp_apic_timer_interrupt+0x91/0xb0
Jan 24 01:37:11 cocoduo kernel: [ 1571.788032]  [apic_timer_interrupt+31/36] 
apic_timer_interrupt+0x1f/0x24
Jan 24 01:37:11 cocoduo kernel: [ 1571.788048]  [_spin_lock_bh+15/32] 
_spin_lock_bh+0xf/0x20
Jan 24 01:37:11 cocoduo kernel: [ 1571.788061]  [pg0+946730645/1068803072] 
sky2_tx_timeout+0xf5/0x1d0 [sky2]
Jan 24 01:37:11 cocoduo kernel: [ 1571.788083]  [dev_watchdog+0/208] 
dev_watchdog+0x0/0xd0
Jan 24 01:37:11 cocoduo kernel: [ 1571.788090]  [dev_watchdog+192/208] 
dev_watchdog+0xc0/0xd0
Jan 24 01:37:11 cocoduo kernel: [ 1571.788099]  [run_timer_softirq+273/400] 
run_timer_softirq+0x111/0x190
Jan 24 01:37:11 cocoduo kernel: [ 1571.788114]  [__do_softirq+116/240] 
__do_softirq+0x74/0xf0
Jan 24 01:37:11 cocoduo kernel: [ 1571.788125]  [do_softirq+59/80] 
do_softirq+0x3b/0x50
Jan 24 01:37:11 cocoduo kernel: [ 1571.788134]  
[smp_apic_timer_interrupt+150/176] smp_apic_timer_interrupt+0x96/0xb0
Jan 24 01:37:11 cocoduo kernel: [ 1571.788143]  [apic_timer_interrupt+31/36] 
apic_timer_interrupt+0x1f/0x24
Jan 24 01:37:11 cocoduo kernel: [ 1571.788153]  [default_idle+0/112] 
default_idle+0x0/0x70
Jan 24 01:37:11 cocoduo kernel: [ 1571.788166]  [default_idle+54/112] 
default_idle+0x36/0x70
Jan 24 01:37:11 cocoduo kernel: [ 1571.788175]  [cpu_idle+116/208] 
cpu_idle+0x74/0xd0
Jan 24 01:37:11 cocoduo kernel: [ 1571.788184]  [start_kernel+872/1072] 
start_kernel+0x368/0x430
Jan 24 01:37:11 cocoduo kernel: [ 1571.788194]  [unknown_bootoption+0/624] 
unknown_bootoption+0x0/0x270
Jan 24 01:37:11 cocoduo kernel: [ 1571.788208]  ===

-- 
Lionel Landwerlin [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.19.2 sky2/acpi crashes

[Lionel Landwerlin]

Hi,

I'm running a macbook with a Marvell ethernet controller, and I have a
lots of freezes when using the ethernet controller under a load of
~100K/s. Since I'm running a 2.6.19.2 kernel, I'm able to get some
report from the kernel. Here they are :

Jan 23 09:30:57 cocoduo kernel: [  662.92] NETDEV WATCHDOG: eth0:
transmit timed out
Jan 23 09:30:57 cocoduo kernel: [  662.92] sky2 eth0: tx timeout
Jan 23 09:30:57 cocoduo kernel: [  662.92] sky2 eth0: transmit ring
493 .. 471 report=494 done=494
Jan 23 09:30:57 cocoduo kernel: [  662.92] sky2 status report lost?
Jan 23 09:31:06 cocoduo kernel: [  672.832000] BUG: soft lockup detected
on CPU#0!
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [softlockup_tick
+155/208] softlockup_tick+0x9b/0xd0
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [update_process_times
+49/128] update_process_times+0x31/0x80
Jan 23 09:31:06 cocoduo kernel: [  672.832000]
[smp_apic_timer_interrupt+145/176] smp_apic_timer_interrupt+0x91/0xb0
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [apic_timer_interrupt
+31/36] apic_timer_interrupt+0x1f/0x24
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [_spin_lock_bh+18/32]
_spin_lock_bh+0x12/0x20
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [pg0
+946878101/1068803072] sky2_tx_timeout+0xf5/0x1d0 [sky2]
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [dev_watchdog+0/208]
dev_watchdog+0x0/0xd0
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [dev_watchdog+192/208]
dev_watchdog+0xc0/0xd0
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [run_timer_softirq
+273/400] run_timer_softirq+0x111/0x190
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [__do_softirq+116/240]
__do_softirq+0x74/0xf0
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [do_softirq+59/80]
do_softirq+0x3b/0x50
Jan 23 09:31:06 cocoduo kernel: [  672.832000]
[smp_apic_timer_interrupt+150/176] smp_apic_timer_interrupt+0x96/0xb0
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [apic_timer_interrupt
+31/36] apic_timer_interrupt+0x1f/0x24
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [pg0
+943208348/1068803072] acpi_processor_idle+0x1fd/0x3b9 [processor]
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [cpu_idle+116/208]
cpu_idle+0x74/0xd0
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [start_kernel+872/1072]
start_kernel+0x368/0x430
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [unknown_bootoption
+0/624] unknown_bootoption+0x0/0x270
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  ===

As most of the time, the keyboard gets locked and the network driver is
down, I can get more informations.

Here my hardware configuration :

Apple Macbook 2GHz (x86, not amd64)
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and
945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile
945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML
Express Integrated Graphics Controller (rev 03)
00:07.0 Performance counters: Intel Corporation Unknown device 27a3 (rev
03)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High
Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express
Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express
Port 2 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
#1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
#2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
#3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
#4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI
Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface
Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE
Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family)
Serial ATA Storage Controller IDE (rev 02)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller
(rev 02)
01:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E
Gigabit Ethernet Controller (rev 22)
02:00.0 Ethernet controller: Atheros Communications, Inc. Unknown device
001c (rev 01)
03:03.0 FireWire (IEEE 1394): Agere Systems FW323 (rev 61)

I hope some fix could be released soon.

-- 
Lionel Landwerlin [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.19.2 sky2/acpi crashes

[Lionel Landwerlin]

Le mardi 23 janvier 2007 à 17:22 +0800, Luming Yu a écrit :
 Please try to remove processor module.

Ok, that's done. Same problem.

Just to show you I did not forget to remove processor.ko from initrd
image, I tried to load speedstep_centrino :

Jan 23 13:09:58 cocoduo kernel: [  105.697279] speedstep_centrino:
Unknown symbol acpi_processor_notify_smm
Jan 23 13:09:58 cocoduo kernel: [  105.697324] speedstep_centrino:
Unknown symbol acpi_processor_unregister_performance
Jan 23 13:09:58 cocoduo kernel: [  105.697411] speedstep_centrino:
Unknown symbol acpi_processor_preregister_performance
Jan 23 13:09:58 cocoduo kernel: [  105.697464] speedstep_centrino:
Unknown symbol acpi_processor_register_performance
Jan 23 13:15:51 cocoduo kernel: [  458.267151] NETDEV WATCHDOG: eth0:
transmit timed out
Jan 23 13:15:51 cocoduo kernel: [  458.267157] sky2 eth0: tx timeout
Jan 23 13:15:51 cocoduo kernel: [  458.267164] sky2 eth0: transmit ring
421 .. 398 report=422 done=422
Jan 23 13:15:51 cocoduo kernel: [  458.267166] sky2 status report lost?
Jan 23 13:16:00 cocoduo kernel: [  466.730622] BUG: soft lockup detected
on CPU#0!
Jan 23 13:16:00 cocoduo kernel: [  466.730644]  [softlockup_tick
+155/208] softlockup_tick+0x9b/0xd0
Jan 23 13:16:00 cocoduo kernel: [  466.730656]  [update_process_times
+49/128] update_process_times+0x31/0x80
Jan 23 13:16:00 cocoduo kernel: [  466.730666]
[smp_apic_timer_interrupt+145/176] smp_apic_timer_interrupt+0x91/0xb0
Jan 23 13:16:00 cocoduo kernel: [  466.730674]  [apic_timer_interrupt
+31/36] apic_timer_interrupt+0x1f/0x24
Jan 23 13:16:00 cocoduo kernel: [  466.730684]  [_spin_lock_bh+18/32]
_spin_lock_bh+0x12/0x20
Jan 23 13:16:00 cocoduo kernel: [  466.730693]  [pg0
+945944213/1068803072] sky2_tx_timeout+0xf5/0x1d0 [sky2]
Jan 23 13:16:00 cocoduo kernel: [  466.730707]  [dev_watchdog+0/208]
dev_watchdog+0x0/0xd0
Jan 23 13:16:00 cocoduo kernel: [  466.730712]  [dev_watchdog+192/208]
dev_watchdog+0xc0/0xd0
Jan 23 13:16:00 cocoduo kernel: [  466.730718]  [run_timer_softirq
+273/400] run_timer_softirq+0x111/0x190
Jan 23 13:16:00 cocoduo kernel: [  466.730728]  [__do_softirq+116/240]
__do_softirq+0x74/0xf0
Jan 23 13:16:00 cocoduo kernel: [  466.730734]  [do_softirq+59/80]
do_softirq+0x3b/0x50
Jan 23 13:16:00 cocoduo kernel: [  466.730739]
[smp_apic_timer_interrupt+150/176] smp_apic_timer_interrupt+0x96/0xb0
Jan 23 13:16:00 cocoduo kernel: [  466.730746]  [apic_timer_interrupt
+31/36] apic_timer_interrupt+0x1f/0x24
Jan 23 13:16:00 cocoduo kernel: [  466.730756]  [mwait_idle_with_hints
+70/96] mwait_idle_with_hints+0x46/0x60
Jan 23 13:16:00 cocoduo kernel: [  466.730762]  [mwait_idle+12/32]
mwait_idle+0xc/0x20
Jan 23 13:16:00 cocoduo kernel: [  466.730766]  [cpu_idle+116/208]
cpu_idle+0x74/0xd0
Jan 23 13:16:00 cocoduo kernel: [  466.730773]  [start_kernel+872/1072]
start_kernel+0x368/0x430
Jan 23 13:16:00 cocoduo kernel: [  466.730780]  [unknown_bootoption
+0/624] unknown_bootoption+0x0/0x270
Jan 23 13:16:00 cocoduo kernel: [  466.730790]  ===


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/