Re: [PATCH] platform/x86/intel-vbtn: add volume up and down

[Maarten Maathuis]

On Tue, Apr 25, 2017 at 4:43 AM, AceLan Kao <acelan@canonical.com> wrote:
> According the spec. I have, the values are correct.
> Please merge it, thanks.
>

Is there a reason the whole spec isn't implemented?
Is it under NDA?

> 2017-04-25 5:41 GMT+08:00 Maarten Maathuis <madman2...@gmail.com>:
>> On Mon, Apr 24, 2017 at 11:37 PM, Andy Shevchenko
>> <andy.shevche...@gmail.com> wrote:
>>> On Tue, Apr 25, 2017 at 12:29 AM, Maarten Maathuis <madman2...@gmail.com> 
>>> wrote:
>>>> Tested on HP Elite X2 1012 G1.
>>>> Matches event report of Lenovo Helix 2
>>>> (https://www.spinics.net/lists/ibm-acpi-devel/msg03982.html).
>>>>
>>>
>>> Much better!
>>>
>>>> V2: Fix indent and add sign-off
>>>
>>> Usually this line goes after --- (body delimiter).
>>> No need to resend this time. I would wait a bit for actual
>>> author/driver maintainer to comment. Otherwise patch looks good enough
>>> to me.
>>
>> The intent is not have this in the commit message?
>> I'll keep an eye out if i can place it below "---" next time.
>> Although i suspect the message would end in the actual code diff,
>> which seems odd.
>>
>>>
>>>>
>>>> Signed-off-by: Maarten Maathuis <madman2...@shikahr.net>
>>>> ---
>>>>  drivers/platform/x86/intel-vbtn.c | 4 
>>>>  1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/drivers/platform/x86/intel-vbtn.c 
>>>> b/drivers/platform/x86/intel-vbtn.c
>>>> index 554e82ebe83c..1616cb9c4ae5 100644
>>>> --- a/drivers/platform/x86/intel-vbtn.c
>>>> +++ b/drivers/platform/x86/intel-vbtn.c
>>>> @@ -37,6 +37,10 @@ static const struct acpi_device_id intel_vbtn_ids[] = {
>>>>  static const struct key_entry intel_vbtn_keymap[] = {
>>>> { KE_IGNORE, 0xC0, { KEY_POWER } }, /* power key press */
>>>> { KE_KEY, 0xC1, { KEY_POWER } },/* power key release */
>>>> +   { KE_KEY, 0xC4, { KEY_VOLUMEUP} },  /* volume-up key press */
>>>> +   { KE_IGNORE, 0xC5, { KEY_VOLUMEUP } },  /* volume-up key release */
>>>> +   { KE_KEY, 0xC6, { KEY_VOLUMEDOWN } },   /* volume-down key press */
>>>> +   { KE_IGNORE, 0xC7, { KEY_VOLUMEDOWN } },/* volume-down key 
>>>> release */
>>>> { KE_END },
>>>>  };
>>>>
>>>> --
>>>> 2.12.2
>>>>
>>>
>>>
>>>
>>> --
>>> With Best Regards,
>>> Andy Shevchenko
>>
>>
>>
>> --
>> Far away from the primal instinct, the song seems to fade away, the
>> river get wider between your thoughts and the things we do and say.



-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

Re: [PATCH] platform/x86/intel-vbtn: add volume up and down

[Maarten Maathuis]

On Tue, Apr 25, 2017 at 4:43 AM, AceLan Kao  wrote:
> According the spec. I have, the values are correct.
> Please merge it, thanks.
>

Is there a reason the whole spec isn't implemented?
Is it under NDA?

> 2017-04-25 5:41 GMT+08:00 Maarten Maathuis :
>> On Mon, Apr 24, 2017 at 11:37 PM, Andy Shevchenko
>>  wrote:
>>> On Tue, Apr 25, 2017 at 12:29 AM, Maarten Maathuis  
>>> wrote:
>>>> Tested on HP Elite X2 1012 G1.
>>>> Matches event report of Lenovo Helix 2
>>>> (https://www.spinics.net/lists/ibm-acpi-devel/msg03982.html).
>>>>
>>>
>>> Much better!
>>>
>>>> V2: Fix indent and add sign-off
>>>
>>> Usually this line goes after --- (body delimiter).
>>> No need to resend this time. I would wait a bit for actual
>>> author/driver maintainer to comment. Otherwise patch looks good enough
>>> to me.
>>
>> The intent is not have this in the commit message?
>> I'll keep an eye out if i can place it below "---" next time.
>> Although i suspect the message would end in the actual code diff,
>> which seems odd.
>>
>>>
>>>>
>>>> Signed-off-by: Maarten Maathuis 
>>>> ---
>>>>  drivers/platform/x86/intel-vbtn.c | 4 
>>>>  1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/drivers/platform/x86/intel-vbtn.c 
>>>> b/drivers/platform/x86/intel-vbtn.c
>>>> index 554e82ebe83c..1616cb9c4ae5 100644
>>>> --- a/drivers/platform/x86/intel-vbtn.c
>>>> +++ b/drivers/platform/x86/intel-vbtn.c
>>>> @@ -37,6 +37,10 @@ static const struct acpi_device_id intel_vbtn_ids[] = {
>>>>  static const struct key_entry intel_vbtn_keymap[] = {
>>>> { KE_IGNORE, 0xC0, { KEY_POWER } }, /* power key press */
>>>> { KE_KEY, 0xC1, { KEY_POWER } },/* power key release */
>>>> +   { KE_KEY, 0xC4, { KEY_VOLUMEUP} },  /* volume-up key press */
>>>> +   { KE_IGNORE, 0xC5, { KEY_VOLUMEUP } },  /* volume-up key release */
>>>> +   { KE_KEY, 0xC6, { KEY_VOLUMEDOWN } },   /* volume-down key press */
>>>> +   { KE_IGNORE, 0xC7, { KEY_VOLUMEDOWN } },/* volume-down key 
>>>> release */
>>>> { KE_END },
>>>>  };
>>>>
>>>> --
>>>> 2.12.2
>>>>
>>>
>>>
>>>
>>> --
>>> With Best Regards,
>>> Andy Shevchenko
>>
>>
>>
>> --
>> Far away from the primal instinct, the song seems to fade away, the
>> river get wider between your thoughts and the things we do and say.



-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

Re: [PATCH] platform/x86/intel-vbtn: add volume up and down

[Maarten Maathuis]

On Mon, Apr 24, 2017 at 11:37 PM, Andy Shevchenko
<andy.shevche...@gmail.com> wrote:
> On Tue, Apr 25, 2017 at 12:29 AM, Maarten Maathuis <madman2...@gmail.com> 
> wrote:
>> Tested on HP Elite X2 1012 G1.
>> Matches event report of Lenovo Helix 2
>> (https://www.spinics.net/lists/ibm-acpi-devel/msg03982.html).
>>
>
> Much better!
>
>> V2: Fix indent and add sign-off
>
> Usually this line goes after --- (body delimiter).
> No need to resend this time. I would wait a bit for actual
> author/driver maintainer to comment. Otherwise patch looks good enough
> to me.

The intent is not have this in the commit message?
I'll keep an eye out if i can place it below "---" next time.
Although i suspect the message would end in the actual code diff,
which seems odd.

>
>>
>> Signed-off-by: Maarten Maathuis <madman2...@shikahr.net>
>> ---
>>  drivers/platform/x86/intel-vbtn.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/platform/x86/intel-vbtn.c 
>> b/drivers/platform/x86/intel-vbtn.c
>> index 554e82ebe83c..1616cb9c4ae5 100644
>> --- a/drivers/platform/x86/intel-vbtn.c
>> +++ b/drivers/platform/x86/intel-vbtn.c
>> @@ -37,6 +37,10 @@ static const struct acpi_device_id intel_vbtn_ids[] = {
>>  static const struct key_entry intel_vbtn_keymap[] = {
>> { KE_IGNORE, 0xC0, { KEY_POWER } }, /* power key press */
>> { KE_KEY, 0xC1, { KEY_POWER } },/* power key release */
>> +   { KE_KEY, 0xC4, { KEY_VOLUMEUP} },  /* volume-up key press */
>> +   { KE_IGNORE, 0xC5, { KEY_VOLUMEUP } },  /* volume-up key release */
>> +   { KE_KEY, 0xC6, { KEY_VOLUMEDOWN } },   /* volume-down key press */
>> +   { KE_IGNORE, 0xC7, { KEY_VOLUMEDOWN } },/* volume-down key 
>> release */
>> { KE_END },
>>  };
>>
>> --
>> 2.12.2
>>
>
>
>
> --
> With Best Regards,
> Andy Shevchenko



-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

Re: [PATCH] platform/x86/intel-vbtn: add volume up and down

[Maarten Maathuis]

On Mon, Apr 24, 2017 at 11:37 PM, Andy Shevchenko
 wrote:
> On Tue, Apr 25, 2017 at 12:29 AM, Maarten Maathuis  
> wrote:
>> Tested on HP Elite X2 1012 G1.
>> Matches event report of Lenovo Helix 2
>> (https://www.spinics.net/lists/ibm-acpi-devel/msg03982.html).
>>
>
> Much better!
>
>> V2: Fix indent and add sign-off
>
> Usually this line goes after --- (body delimiter).
> No need to resend this time. I would wait a bit for actual
> author/driver maintainer to comment. Otherwise patch looks good enough
> to me.

The intent is not have this in the commit message?
I'll keep an eye out if i can place it below "---" next time.
Although i suspect the message would end in the actual code diff,
which seems odd.

>
>>
>> Signed-off-by: Maarten Maathuis 
>> ---
>>  drivers/platform/x86/intel-vbtn.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/platform/x86/intel-vbtn.c 
>> b/drivers/platform/x86/intel-vbtn.c
>> index 554e82ebe83c..1616cb9c4ae5 100644
>> --- a/drivers/platform/x86/intel-vbtn.c
>> +++ b/drivers/platform/x86/intel-vbtn.c
>> @@ -37,6 +37,10 @@ static const struct acpi_device_id intel_vbtn_ids[] = {
>>  static const struct key_entry intel_vbtn_keymap[] = {
>> { KE_IGNORE, 0xC0, { KEY_POWER } }, /* power key press */
>> { KE_KEY, 0xC1, { KEY_POWER } },/* power key release */
>> +   { KE_KEY, 0xC4, { KEY_VOLUMEUP} },  /* volume-up key press */
>> +   { KE_IGNORE, 0xC5, { KEY_VOLUMEUP } },  /* volume-up key release */
>> +   { KE_KEY, 0xC6, { KEY_VOLUMEDOWN } },   /* volume-down key press */
>> +   { KE_IGNORE, 0xC7, { KEY_VOLUMEDOWN } },/* volume-down key 
>> release */
>> { KE_END },
>>  };
>>
>> --
>> 2.12.2
>>
>
>
>
> --
> With Best Regards,
> Andy Shevchenko



-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

[PATCH] platform/x86/intel-vbtn: add volume up and down

[Maarten Maathuis]

Tested on HP Elite X2 1012 G1.
Matches event report of Lenovo Helix 2
(https://www.spinics.net/lists/ibm-acpi-devel/msg03982.html).

V2: Fix indent and add sign-off
V3: Missing whitespace correction

Signed-off-by: Maarten Maathuis <madman2...@shikahr.net>
---
 drivers/platform/x86/intel-vbtn.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/platform/x86/intel-vbtn.c 
b/drivers/platform/x86/intel-vbtn.c
index 554e82ebe83c..dc270fe793a1 100644
--- a/drivers/platform/x86/intel-vbtn.c
+++ b/drivers/platform/x86/intel-vbtn.c
@@ -37,6 +37,10 @@ static const struct acpi_device_id intel_vbtn_ids[] = {
 static const struct key_entry intel_vbtn_keymap[] = {
{ KE_IGNORE, 0xC0, { KEY_POWER } }, /* power key press */
{ KE_KEY, 0xC1, { KEY_POWER } },/* power key release */
+   { KE_KEY, 0xC4, { KEY_VOLUMEUP } }, /* volume-up key press */
+   { KE_IGNORE, 0xC5, { KEY_VOLUMEUP } },  /* volume-up key release */
+   { KE_KEY, 0xC6, { KEY_VOLUMEDOWN } },   /* volume-down key press */
+   { KE_IGNORE, 0xC7, { KEY_VOLUMEDOWN } },/* volume-down key 
release */
{ KE_END },
 };
 
-- 
2.12.2

[PATCH] platform/x86/intel-vbtn: add volume up and down

[Maarten Maathuis]

Tested on HP Elite X2 1012 G1.
Matches event report of Lenovo Helix 2
(https://www.spinics.net/lists/ibm-acpi-devel/msg03982.html).

V2: Fix indent and add sign-off
V3: Missing whitespace correction

Signed-off-by: Maarten Maathuis 
---
 drivers/platform/x86/intel-vbtn.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/platform/x86/intel-vbtn.c 
b/drivers/platform/x86/intel-vbtn.c
index 554e82ebe83c..dc270fe793a1 100644
--- a/drivers/platform/x86/intel-vbtn.c
+++ b/drivers/platform/x86/intel-vbtn.c
@@ -37,6 +37,10 @@ static const struct acpi_device_id intel_vbtn_ids[] = {
 static const struct key_entry intel_vbtn_keymap[] = {
{ KE_IGNORE, 0xC0, { KEY_POWER } }, /* power key press */
{ KE_KEY, 0xC1, { KEY_POWER } },/* power key release */
+   { KE_KEY, 0xC4, { KEY_VOLUMEUP } }, /* volume-up key press */
+   { KE_IGNORE, 0xC5, { KEY_VOLUMEUP } },  /* volume-up key release */
+   { KE_KEY, 0xC6, { KEY_VOLUMEDOWN } },   /* volume-down key press */
+   { KE_IGNORE, 0xC7, { KEY_VOLUMEDOWN } },/* volume-down key 
release */
{ KE_END },
 };
 
-- 
2.12.2

Re: [PATCH] platform/x86/intel-vbtn: add volume up and down

[Maarten Maathuis]

On Mon, Apr 24, 2017 at 10:55 PM, Andy Shevchenko
<andy.shevche...@gmail.com> wrote:
> On Mon, Apr 24, 2017 at 11:47 PM, Maarten Maathuis <madman2...@gmail.com> 
> wrote:
>> Tested on HP Elite X2 1012 G1.
>> Matches event report of Lenovo Helix 2
>> (https://www.spinics.net/lists/ibm-acpi-devel/msg03982.html).
>
> Thanks for the patch.
>
> A bit of work still required.
>
> According to Submitting Patches document [1] we need your Signed-off-by tag.
>
> Besides that see my comment below.
>
> [1] https://www.kernel.org/doc/Documentation/process/submitting-patches.rst
>
>
>> ---
>>  drivers/platform/x86/intel-vbtn.c | 8 ++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/platform/x86/intel-vbtn.c 
>> b/drivers/platform/x86/intel-vbtn.c
>> index 554e82ebe83c..1fbebbad350d 100644
>> --- a/drivers/platform/x86/intel-vbtn.c
>> +++ b/drivers/platform/x86/intel-vbtn.c
>> @@ -35,8 +35,12 @@ static const struct acpi_device_id intel_vbtn_ids[] = {
>>
>>  /* In theory, these are HID usages. */
>>  static const struct key_entry intel_vbtn_keymap[] = {
>
>> -   { KE_IGNORE, 0xC0, { KEY_POWER } }, /* power key press */
>> -   { KE_KEY, 0xC1, { KEY_POWER } },/* power key release */
>> +   { KE_IGNORE, 0xC0, { KEY_POWER } },  /* power key press */
>> +   { KE_KEY, 0xC1, { KEY_POWER } }, /* power key release */
>
> As far as I can see nothing should happen on these lines. I think your
> editor (or maybe email setup) is configured somehow wrongly. We expect
> TAB as an indentation starter.
>
> We also encourage to use git send-email tool instead of manual
> submitting patches through some (broken) MUAs.

I fell back to an other SMTP server, until i can find a structural
long term solution.
The difference in the other two lines was due to a misunderstanding
about indenting
policy. hopefully it's better now.

>
>> +   { KE_KEY, 0xC4, { KEY_VOLUMEUP} },   /* volume-up key press */
>> +   { KE_IGNORE, 0xC5, { KEY_VOLUMEUP } },   /* volume-up key release */
>> +   { KE_KEY, 0xC6, { KEY_VOLUMEDOWN} }, /* volume-down key press */
>> +   { KE_IGNORE, 0xC7, { KEY_VOLUMEDOWN } }, /* volume-down key release 
>> */
>> { KE_END },
>
> --
> With Best Regards,
> Andy Shevchenko



-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

Re: [PATCH] platform/x86/intel-vbtn: add volume up and down

[Maarten Maathuis]

On Mon, Apr 24, 2017 at 10:55 PM, Andy Shevchenko
 wrote:
> On Mon, Apr 24, 2017 at 11:47 PM, Maarten Maathuis  
> wrote:
>> Tested on HP Elite X2 1012 G1.
>> Matches event report of Lenovo Helix 2
>> (https://www.spinics.net/lists/ibm-acpi-devel/msg03982.html).
>
> Thanks for the patch.
>
> A bit of work still required.
>
> According to Submitting Patches document [1] we need your Signed-off-by tag.
>
> Besides that see my comment below.
>
> [1] https://www.kernel.org/doc/Documentation/process/submitting-patches.rst
>
>
>> ---
>>  drivers/platform/x86/intel-vbtn.c | 8 ++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/platform/x86/intel-vbtn.c 
>> b/drivers/platform/x86/intel-vbtn.c
>> index 554e82ebe83c..1fbebbad350d 100644
>> --- a/drivers/platform/x86/intel-vbtn.c
>> +++ b/drivers/platform/x86/intel-vbtn.c
>> @@ -35,8 +35,12 @@ static const struct acpi_device_id intel_vbtn_ids[] = {
>>
>>  /* In theory, these are HID usages. */
>>  static const struct key_entry intel_vbtn_keymap[] = {
>
>> -   { KE_IGNORE, 0xC0, { KEY_POWER } }, /* power key press */
>> -   { KE_KEY, 0xC1, { KEY_POWER } },/* power key release */
>> +   { KE_IGNORE, 0xC0, { KEY_POWER } },  /* power key press */
>> +   { KE_KEY, 0xC1, { KEY_POWER } }, /* power key release */
>
> As far as I can see nothing should happen on these lines. I think your
> editor (or maybe email setup) is configured somehow wrongly. We expect
> TAB as an indentation starter.
>
> We also encourage to use git send-email tool instead of manual
> submitting patches through some (broken) MUAs.

I fell back to an other SMTP server, until i can find a structural
long term solution.
The difference in the other two lines was due to a misunderstanding
about indenting
policy. hopefully it's better now.

>
>> +   { KE_KEY, 0xC4, { KEY_VOLUMEUP} },   /* volume-up key press */
>> +   { KE_IGNORE, 0xC5, { KEY_VOLUMEUP } },   /* volume-up key release */
>> +   { KE_KEY, 0xC6, { KEY_VOLUMEDOWN} }, /* volume-down key press */
>> +   { KE_IGNORE, 0xC7, { KEY_VOLUMEDOWN } }, /* volume-down key release 
>> */
>> { KE_END },
>
> --
> With Best Regards,
> Andy Shevchenko



-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

[PATCH] platform/x86/intel-vbtn: add volume up and down

[Maarten Maathuis]

Tested on HP Elite X2 1012 G1.
Matches event report of Lenovo Helix 2
(https://www.spinics.net/lists/ibm-acpi-devel/msg03982.html).

V2: Fix indent and add sign-off

Signed-off-by: Maarten Maathuis <madman2...@shikahr.net>
---
 drivers/platform/x86/intel-vbtn.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/platform/x86/intel-vbtn.c 
b/drivers/platform/x86/intel-vbtn.c
index 554e82ebe83c..1616cb9c4ae5 100644
--- a/drivers/platform/x86/intel-vbtn.c
+++ b/drivers/platform/x86/intel-vbtn.c
@@ -37,6 +37,10 @@ static const struct acpi_device_id intel_vbtn_ids[] = {
 static const struct key_entry intel_vbtn_keymap[] = {
{ KE_IGNORE, 0xC0, { KEY_POWER } }, /* power key press */
{ KE_KEY, 0xC1, { KEY_POWER } },/* power key release */
+   { KE_KEY, 0xC4, { KEY_VOLUMEUP} },  /* volume-up key press */
+   { KE_IGNORE, 0xC5, { KEY_VOLUMEUP } },  /* volume-up key release */
+   { KE_KEY, 0xC6, { KEY_VOLUMEDOWN } },   /* volume-down key press */
+   { KE_IGNORE, 0xC7, { KEY_VOLUMEDOWN } },/* volume-down key 
release */
{ KE_END },
 };
 
-- 
2.12.2

[PATCH] platform/x86/intel-vbtn: add volume up and down

[Maarten Maathuis]

Tested on HP Elite X2 1012 G1.
Matches event report of Lenovo Helix 2
(https://www.spinics.net/lists/ibm-acpi-devel/msg03982.html).

V2: Fix indent and add sign-off

Signed-off-by: Maarten Maathuis 
---
 drivers/platform/x86/intel-vbtn.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/platform/x86/intel-vbtn.c 
b/drivers/platform/x86/intel-vbtn.c
index 554e82ebe83c..1616cb9c4ae5 100644
--- a/drivers/platform/x86/intel-vbtn.c
+++ b/drivers/platform/x86/intel-vbtn.c
@@ -37,6 +37,10 @@ static const struct acpi_device_id intel_vbtn_ids[] = {
 static const struct key_entry intel_vbtn_keymap[] = {
{ KE_IGNORE, 0xC0, { KEY_POWER } }, /* power key press */
{ KE_KEY, 0xC1, { KEY_POWER } },/* power key release */
+   { KE_KEY, 0xC4, { KEY_VOLUMEUP} },  /* volume-up key press */
+   { KE_IGNORE, 0xC5, { KEY_VOLUMEUP } },  /* volume-up key release */
+   { KE_KEY, 0xC6, { KEY_VOLUMEDOWN } },   /* volume-down key press */
+   { KE_IGNORE, 0xC7, { KEY_VOLUMEDOWN } },/* volume-down key 
release */
{ KE_END },
 };
 
-- 
2.12.2

[PATCH] platform/x86/intel-vbtn: add volume up and down

[Maarten Maathuis]

Tested on HP Elite X2 1012 G1.
Matches event report of Lenovo Helix 2
(https://www.spinics.net/lists/ibm-acpi-devel/msg03982.html).
---
 drivers/platform/x86/intel-vbtn.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/x86/intel-vbtn.c 
b/drivers/platform/x86/intel-vbtn.c
index 554e82ebe83c..1fbebbad350d 100644
--- a/drivers/platform/x86/intel-vbtn.c
+++ b/drivers/platform/x86/intel-vbtn.c
@@ -35,8 +35,12 @@ static const struct acpi_device_id intel_vbtn_ids[] = {
 
 /* In theory, these are HID usages. */
 static const struct key_entry intel_vbtn_keymap[] = {
-   { KE_IGNORE, 0xC0, { KEY_POWER } }, /* power key press */
-   { KE_KEY, 0xC1, { KEY_POWER } },/* power key release */
+   { KE_IGNORE, 0xC0, { KEY_POWER } },  /* power key press */
+   { KE_KEY, 0xC1, { KEY_POWER } }, /* power key release */
+   { KE_KEY, 0xC4, { KEY_VOLUMEUP} },   /* volume-up key press */
+   { KE_IGNORE, 0xC5, { KEY_VOLUMEUP } },   /* volume-up key release */
+   { KE_KEY, 0xC6, { KEY_VOLUMEDOWN} }, /* volume-down key press */
+   { KE_IGNORE, 0xC7, { KEY_VOLUMEDOWN } }, /* volume-down key release */
{ KE_END },
 };
 
-- 
2.12.2

[PATCH] platform/x86/intel-vbtn: add volume up and down

[Maarten Maathuis]

Tested on HP Elite X2 1012 G1.
Matches event report of Lenovo Helix 2
(https://www.spinics.net/lists/ibm-acpi-devel/msg03982.html).
---
 drivers/platform/x86/intel-vbtn.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/x86/intel-vbtn.c 
b/drivers/platform/x86/intel-vbtn.c
index 554e82ebe83c..1fbebbad350d 100644
--- a/drivers/platform/x86/intel-vbtn.c
+++ b/drivers/platform/x86/intel-vbtn.c
@@ -35,8 +35,12 @@ static const struct acpi_device_id intel_vbtn_ids[] = {
 
 /* In theory, these are HID usages. */
 static const struct key_entry intel_vbtn_keymap[] = {
-   { KE_IGNORE, 0xC0, { KEY_POWER } }, /* power key press */
-   { KE_KEY, 0xC1, { KEY_POWER } },/* power key release */
+   { KE_IGNORE, 0xC0, { KEY_POWER } },  /* power key press */
+   { KE_KEY, 0xC1, { KEY_POWER } }, /* power key release */
+   { KE_KEY, 0xC4, { KEY_VOLUMEUP} },   /* volume-up key press */
+   { KE_IGNORE, 0xC5, { KEY_VOLUMEUP } },   /* volume-up key release */
+   { KE_KEY, 0xC6, { KEY_VOLUMEDOWN} }, /* volume-down key press */
+   { KE_IGNORE, 0xC7, { KEY_VOLUMEDOWN } }, /* volume-down key release */
{ KE_END },
 };
 
-- 
2.12.2

Re: [PATCH 4.8 118/138] drm/i915: Clean up DDI DDC/AUX CH sanitation

[Maarten Maathuis]

Hi,

I'm merely curious why this patch isn't also included:
https://cgit.freedesktop.org/drm-intel/commit/?id=e4ab73a13291fc844c9e24d5c347bd95818544d2

When i checked it, it's also not in 4.9-rc git tree.
This patch affects HDMI, and the HDMI connector was "my problem".

@Ville: Is it intentional this one was left out?

Maarten.

On Wed, Nov 9, 2016 at 11:46 AM, Greg Kroah-Hartman
<gre...@linuxfoundation.org> wrote:
> 4.8-stable review patch.  If anyone has any objections, please let me know.
>
> --
>
> From: Ville Syrjälä <ville.syrj...@linux.intel.com>
>
> commit 0ce140d45a8398b501934ac289aef0eb7f47c596 upstream.
>
> Now that we use the AUX and GMBUS assignment from VBT for all ports,
> let's clean up the sanitization of the port information a bit.
> Previosuly we only did this for port E, and only complained about a
> non-standard assignment for the other ports. But as we know that
> non-standard assignments are a fact of life, let's expand the
> sanitization to all the ports.
>
> v2: Include a commit message, fix up the comments a bit
> v3: Don't clobber other ports if the current port has no alternate aux ch/ddc 
> pin
>
> Cc: Maarten Maathuis <madman2...@gmail.com>
> Tested-by: Maarten Maathuis <madman2...@gmail.com>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=97877
> Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
> Link: 
> http://patchwork.freedesktop.org/patch/msgid/1476208368-5710-4-git-send-email-ville.syrj...@linux.intel.com
> Reviewed-by: Jim Bride <jim.br...@linux.intel.com> (v2)
> (cherry picked from commit 9454fa871edf15c20a0371548b3ec0d6d944a498)
> Signed-off-by: Jani Nikula <jani.nik...@intel.com>
> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
>
> ---
>  drivers/gpu/drm/i915/intel_bios.c |  122 
> +++---
>  1 file changed, 77 insertions(+), 45 deletions(-)
>
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1031,6 +1031,77 @@ static u8 translate_iboost(u8 val)
> return mapping[val];
>  }
>
> +static void sanitize_ddc_pin(struct drm_i915_private *dev_priv,
> +enum port port)
> +{
> +   const struct ddi_vbt_port_info *info =
> +   _priv->vbt.ddi_port_info[port];
> +   enum port p;
> +
> +   if (!info->alternate_ddc_pin)
> +   return;
> +
> +   for_each_port_masked(p, (1 << port) - 1) {
> +   struct ddi_vbt_port_info *i = _priv->vbt.ddi_port_info[p];
> +
> +   if (info->alternate_ddc_pin != i->alternate_ddc_pin)
> +   continue;
> +
> +   DRM_DEBUG_KMS("port %c trying to use the same DDC pin (0x%x) 
> as port %c, "
> + "disabling port %c DVI/HDMI support\n",
> + port_name(p), i->alternate_ddc_pin,
> + port_name(port), port_name(p));
> +
> +   /*
> +* If we have multiple ports supposedly sharing the
> +* pin, then dvi/hdmi couldn't exist on the shared
> +* port. Otherwise they share the same ddc bin and
> +* system couldn't communicate with them separately.
> +*
> +* Due to parsing the ports in alphabetical order,
> +* a higher port will always clobber a lower one.
> +*/
> +   i->supports_dvi = false;
> +   i->supports_hdmi = false;
> +   i->alternate_ddc_pin = 0;
> +   }
> +}
> +
> +static void sanitize_aux_ch(struct drm_i915_private *dev_priv,
> +   enum port port)
> +{
> +   const struct ddi_vbt_port_info *info =
> +   _priv->vbt.ddi_port_info[port];
> +   enum port p;
> +
> +   if (!info->alternate_aux_channel)
> +   return;
> +
> +   for_each_port_masked(p, (1 << port) - 1) {
> +   struct ddi_vbt_port_info *i = _priv->vbt.ddi_port_info[p];
> +
> +   if (info->alternate_aux_channel != i->alternate_aux_channel)
> +   continue;
> +
> +   DRM_DEBUG_KMS("port %c trying to use the same AUX CH (0x%x) 
> as port %c, "
> + "disabling port %c DP support\n",
> + port_name(p), i->alternate_aux_channel,
> + port_name(port), port_name(p));
> +
> +   /*
> +* If we have multiple ports supposedlt sharing

Re: [PATCH 4.8 118/138] drm/i915: Clean up DDI DDC/AUX CH sanitation

[Maarten Maathuis]

Hi,

I'm merely curious why this patch isn't also included:
https://cgit.freedesktop.org/drm-intel/commit/?id=e4ab73a13291fc844c9e24d5c347bd95818544d2

When i checked it, it's also not in 4.9-rc git tree.
This patch affects HDMI, and the HDMI connector was "my problem".

@Ville: Is it intentional this one was left out?

Maarten.

On Wed, Nov 9, 2016 at 11:46 AM, Greg Kroah-Hartman
 wrote:
> 4.8-stable review patch.  If anyone has any objections, please let me know.
>
> --
>
> From: Ville Syrjälä 
>
> commit 0ce140d45a8398b501934ac289aef0eb7f47c596 upstream.
>
> Now that we use the AUX and GMBUS assignment from VBT for all ports,
> let's clean up the sanitization of the port information a bit.
> Previosuly we only did this for port E, and only complained about a
> non-standard assignment for the other ports. But as we know that
> non-standard assignments are a fact of life, let's expand the
> sanitization to all the ports.
>
> v2: Include a commit message, fix up the comments a bit
> v3: Don't clobber other ports if the current port has no alternate aux ch/ddc 
> pin
>
> Cc: Maarten Maathuis 
> Tested-by: Maarten Maathuis 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=97877
> Signed-off-by: Ville Syrjälä 
> Link: 
> http://patchwork.freedesktop.org/patch/msgid/1476208368-5710-4-git-send-email-ville.syrj...@linux.intel.com
> Reviewed-by: Jim Bride  (v2)
> (cherry picked from commit 9454fa871edf15c20a0371548b3ec0d6d944a498)
> Signed-off-by: Jani Nikula 
> Signed-off-by: Greg Kroah-Hartman 
>
> ---
>  drivers/gpu/drm/i915/intel_bios.c |  122 
> +++---
>  1 file changed, 77 insertions(+), 45 deletions(-)
>
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1031,6 +1031,77 @@ static u8 translate_iboost(u8 val)
> return mapping[val];
>  }
>
> +static void sanitize_ddc_pin(struct drm_i915_private *dev_priv,
> +enum port port)
> +{
> +   const struct ddi_vbt_port_info *info =
> +   _priv->vbt.ddi_port_info[port];
> +   enum port p;
> +
> +   if (!info->alternate_ddc_pin)
> +   return;
> +
> +   for_each_port_masked(p, (1 << port) - 1) {
> +   struct ddi_vbt_port_info *i = _priv->vbt.ddi_port_info[p];
> +
> +   if (info->alternate_ddc_pin != i->alternate_ddc_pin)
> +   continue;
> +
> +   DRM_DEBUG_KMS("port %c trying to use the same DDC pin (0x%x) 
> as port %c, "
> + "disabling port %c DVI/HDMI support\n",
> + port_name(p), i->alternate_ddc_pin,
> + port_name(port), port_name(p));
> +
> +   /*
> +* If we have multiple ports supposedly sharing the
> +* pin, then dvi/hdmi couldn't exist on the shared
> +* port. Otherwise they share the same ddc bin and
> +* system couldn't communicate with them separately.
> +*
> +* Due to parsing the ports in alphabetical order,
> +* a higher port will always clobber a lower one.
> +*/
> +   i->supports_dvi = false;
> +   i->supports_hdmi = false;
> +   i->alternate_ddc_pin = 0;
> +   }
> +}
> +
> +static void sanitize_aux_ch(struct drm_i915_private *dev_priv,
> +   enum port port)
> +{
> +   const struct ddi_vbt_port_info *info =
> +   _priv->vbt.ddi_port_info[port];
> +   enum port p;
> +
> +   if (!info->alternate_aux_channel)
> +   return;
> +
> +   for_each_port_masked(p, (1 << port) - 1) {
> +   struct ddi_vbt_port_info *i = _priv->vbt.ddi_port_info[p];
> +
> +   if (info->alternate_aux_channel != i->alternate_aux_channel)
> +   continue;
> +
> +   DRM_DEBUG_KMS("port %c trying to use the same AUX CH (0x%x) 
> as port %c, "
> + "disabling port %c DP support\n",
> + port_name(p), i->alternate_aux_channel,
> + port_name(port), port_name(p));
> +
> +   /*
> +* If we have multiple ports supposedlt sharing the
> +* aux channel, then DP couldn't exist on the shared
> +* port. Otherwise they share the same aux channel
> +* and system couldn't communicate with them separately.
> +*
>

Re: How to debug DEBUG_TEST_DRIVER_REMOVE hang during loading of kernel?

[Maarten Maathuis]

Anyone have advice where else I can ask?

On Sat, Oct 29, 2016 at 1:07 PM, Maarten Maathuis <madman2...@gmail.com> wrote:
> Anyone have suggestions?
>
> On Thu, Oct 27, 2016 at 8:42 PM, Maarten Maathuis <madman2...@gmail.com> 
> wrote:
>> Hi,
>>
>> I recently had trouble with loading a 4.9rcX kernel, which was hanging
>> after loading the initial kernel ramdisk. After some painful bisecting
>> I found this:
>>
>> bea5b158ff0da9c7246ff391f754f5f38e34577a is the first bad commit
>> commit bea5b158ff0da9c7246ff391f754f5f38e34577a
>> Author: Rob Herring <r...@kernel.org>
>> Date:   Thu Aug 11 10:20:58 2016 -0500
>>
>> driver core: add test of driver remove calls during probe
>>
>> In recent discussions on ksummit-discuss[1], it was suggested to do a
>> sequence of probe, remove, probe for testing driver remove paths. This
>> adds a kconfig option for said test.
>>
>> [1] 
>> https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003459.html
>>
>> Suggested-by: Arnd Bergmann <a...@arndb.de>
>> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
>> Signed-off-by: Rob Herring <r...@kernel.org>
>> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
>>
>> It turns out that the package i was using to build the kernel had
>> DEBUG_TEST_DRIVER_REMOVE enabled.
>>
>> How do I actually figure out why this test causes a hang. I don't have
>> a COM port available to use as serial console, and i don't know if it
>> would even help.
>>
>> Please CC me as i'm not a member of this mailinglist.
>>
>> Maarten.
>>
>> --
>> Far away from the primal instinct, the song seems to fade away, the
>> river get wider between your thoughts and the things we do and say.
>
>
>
> --
> Far away from the primal instinct, the song seems to fade away, the
> river get wider between your thoughts and the things we do and say.



-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

Re: How to debug DEBUG_TEST_DRIVER_REMOVE hang during loading of kernel?

[Maarten Maathuis]

Anyone have advice where else I can ask?

On Sat, Oct 29, 2016 at 1:07 PM, Maarten Maathuis  wrote:
> Anyone have suggestions?
>
> On Thu, Oct 27, 2016 at 8:42 PM, Maarten Maathuis  
> wrote:
>> Hi,
>>
>> I recently had trouble with loading a 4.9rcX kernel, which was hanging
>> after loading the initial kernel ramdisk. After some painful bisecting
>> I found this:
>>
>> bea5b158ff0da9c7246ff391f754f5f38e34577a is the first bad commit
>> commit bea5b158ff0da9c7246ff391f754f5f38e34577a
>> Author: Rob Herring 
>> Date:   Thu Aug 11 10:20:58 2016 -0500
>>
>> driver core: add test of driver remove calls during probe
>>
>> In recent discussions on ksummit-discuss[1], it was suggested to do a
>> sequence of probe, remove, probe for testing driver remove paths. This
>> adds a kconfig option for said test.
>>
>> [1] 
>> https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003459.html
>>
>> Suggested-by: Arnd Bergmann 
>> Cc: Greg Kroah-Hartman 
>> Signed-off-by: Rob Herring 
>> Signed-off-by: Greg Kroah-Hartman 
>>
>> It turns out that the package i was using to build the kernel had
>> DEBUG_TEST_DRIVER_REMOVE enabled.
>>
>> How do I actually figure out why this test causes a hang. I don't have
>> a COM port available to use as serial console, and i don't know if it
>> would even help.
>>
>> Please CC me as i'm not a member of this mailinglist.
>>
>> Maarten.
>>
>> --
>> Far away from the primal instinct, the song seems to fade away, the
>> river get wider between your thoughts and the things we do and say.
>
>
>
> --
> Far away from the primal instinct, the song seems to fade away, the
> river get wider between your thoughts and the things we do and say.



-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

Re: How to debug DEBUG_TEST_DRIVER_REMOVE hang during loading of kernel?

[Maarten Maathuis]

Anyone have suggestions?

On Thu, Oct 27, 2016 at 8:42 PM, Maarten Maathuis <madman2...@gmail.com> wrote:
> Hi,
>
> I recently had trouble with loading a 4.9rcX kernel, which was hanging
> after loading the initial kernel ramdisk. After some painful bisecting
> I found this:
>
> bea5b158ff0da9c7246ff391f754f5f38e34577a is the first bad commit
> commit bea5b158ff0da9c7246ff391f754f5f38e34577a
> Author: Rob Herring <r...@kernel.org>
> Date:   Thu Aug 11 10:20:58 2016 -0500
>
> driver core: add test of driver remove calls during probe
>
> In recent discussions on ksummit-discuss[1], it was suggested to do a
> sequence of probe, remove, probe for testing driver remove paths. This
> adds a kconfig option for said test.
>
> [1] 
> https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003459.html
>
> Suggested-by: Arnd Bergmann <a...@arndb.de>
> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> Signed-off-by: Rob Herring <r...@kernel.org>
> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
>
> It turns out that the package i was using to build the kernel had
> DEBUG_TEST_DRIVER_REMOVE enabled.
>
> How do I actually figure out why this test causes a hang. I don't have
> a COM port available to use as serial console, and i don't know if it
> would even help.
>
> Please CC me as i'm not a member of this mailinglist.
>
> Maarten.
>
> --
> Far away from the primal instinct, the song seems to fade away, the
> river get wider between your thoughts and the things we do and say.



-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

Re: How to debug DEBUG_TEST_DRIVER_REMOVE hang during loading of kernel?

[Maarten Maathuis]

Anyone have suggestions?

On Thu, Oct 27, 2016 at 8:42 PM, Maarten Maathuis  wrote:
> Hi,
>
> I recently had trouble with loading a 4.9rcX kernel, which was hanging
> after loading the initial kernel ramdisk. After some painful bisecting
> I found this:
>
> bea5b158ff0da9c7246ff391f754f5f38e34577a is the first bad commit
> commit bea5b158ff0da9c7246ff391f754f5f38e34577a
> Author: Rob Herring 
> Date:   Thu Aug 11 10:20:58 2016 -0500
>
> driver core: add test of driver remove calls during probe
>
> In recent discussions on ksummit-discuss[1], it was suggested to do a
> sequence of probe, remove, probe for testing driver remove paths. This
> adds a kconfig option for said test.
>
> [1] 
> https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003459.html
>
> Suggested-by: Arnd Bergmann 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Rob Herring 
> Signed-off-by: Greg Kroah-Hartman 
>
> It turns out that the package i was using to build the kernel had
> DEBUG_TEST_DRIVER_REMOVE enabled.
>
> How do I actually figure out why this test causes a hang. I don't have
> a COM port available to use as serial console, and i don't know if it
> would even help.
>
> Please CC me as i'm not a member of this mailinglist.
>
> Maarten.
>
> --
> Far away from the primal instinct, the song seems to fade away, the
> river get wider between your thoughts and the things we do and say.



-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

How to debug DEBUG_TEST_DRIVER_REMOVE hang during loading of kernel?

[Maarten Maathuis]

Hi,

I recently had trouble with loading a 4.9rcX kernel, which was hanging
after loading the initial kernel ramdisk. After some painful bisecting
I found this:

bea5b158ff0da9c7246ff391f754f5f38e34577a is the first bad commit
commit bea5b158ff0da9c7246ff391f754f5f38e34577a
Author: Rob Herring 
Date:   Thu Aug 11 10:20:58 2016 -0500

driver core: add test of driver remove calls during probe

In recent discussions on ksummit-discuss[1], it was suggested to do a
sequence of probe, remove, probe for testing driver remove paths. This
adds a kconfig option for said test.

[1] 
https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003459.html

Suggested-by: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Signed-off-by: Rob Herring 
Signed-off-by: Greg Kroah-Hartman 

It turns out that the package i was using to build the kernel had
DEBUG_TEST_DRIVER_REMOVE enabled.

How do I actually figure out why this test causes a hang. I don't have
a COM port available to use as serial console, and i don't know if it
would even help.

Please CC me as i'm not a member of this mailinglist.

Maarten.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

How to debug DEBUG_TEST_DRIVER_REMOVE hang during loading of kernel?

[Maarten Maathuis]

Hi,

I recently had trouble with loading a 4.9rcX kernel, which was hanging
after loading the initial kernel ramdisk. After some painful bisecting
I found this:

bea5b158ff0da9c7246ff391f754f5f38e34577a is the first bad commit
commit bea5b158ff0da9c7246ff391f754f5f38e34577a
Author: Rob Herring 
Date:   Thu Aug 11 10:20:58 2016 -0500

driver core: add test of driver remove calls during probe

In recent discussions on ksummit-discuss[1], it was suggested to do a
sequence of probe, remove, probe for testing driver remove paths. This
adds a kconfig option for said test.

[1] 
https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003459.html

Suggested-by: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Signed-off-by: Rob Herring 
Signed-off-by: Greg Kroah-Hartman 

It turns out that the package i was using to build the kernel had
DEBUG_TEST_DRIVER_REMOVE enabled.

How do I actually figure out why this test causes a hang. I don't have
a COM port available to use as serial console, and i don't know if it
would even help.

Please CC me as i'm not a member of this mailinglist.

Maarten.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

Re: [PATCH 2/2] Add 2-level GPUVM pagetables support to radeon driver. v2

[Maarten Maathuis]

On Fri, Sep 14, 2012 at 7:49 PM, Dmitry Cherkasov  wrote:
> +#define RADEON_PT_OFFSET(_rdev) \
> +   (RADEON_GPU_PAGE_ALIGN(RADEON_TOTAL_PDE_COUNT(rdev) * 
> RADEON_PDE_SIZE))

Shouldn't that be _rdev too?

Also a few lines above that you use rdev instead of _rdev.

I didn't check the whole thing, just noticed that when i was staring
at it for no reason :-)

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] Add 2-level GPUVM pagetables support to radeon driver. v2

[Maarten Maathuis]

On Fri, Sep 14, 2012 at 7:49 PM, Dmitry Cherkasov dcherkas...@gmail.com wrote:
 +#define RADEON_PT_OFFSET(_rdev) \
 +   (RADEON_GPU_PAGE_ALIGN(RADEON_TOTAL_PDE_COUNT(rdev) * 
 RADEON_PDE_SIZE))

Shouldn't that be _rdev too?

Also a few lines above that you use rdev instead of _rdev.

I didn't check the whole thing, just noticed that when i was staring
at it for no reason :-)

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Nouveau] [bisected] nouveau: "Failed to idle channel x" after resume

[Maarten Maathuis]

On Mon, Aug 13, 2012 at 9:49 PM, Maxim Levitsky  wrote:
> On Mon, 2012-08-13 at 18:22 +0200, Sven Joachim wrote:
>> On 2012-08-08 08:18 +0200, Sven Joachim wrote:
>>
>> > On 2012-08-08 08:08 +0200, Ben Skeggs wrote:
>> >
>> >> On Wed, Aug 08, 2012 at 08:00:21AM +0200, Sven Joachim wrote:
>> >>> Not for me on my GeForce 8500 GT, and I still cannot suspend more than
>> >>> once, subsequent attempts fail:
>> >>>
>> >>> ,
>> >>> | Aug 8 07:49:16 turtle kernel: [ 91.697068] nouveau W[
>> >>> | PGRAPH][:01:00.0][0x0200502d][880037be1d40] parent failed
>> >>> | suspend, -16
>> >>> | Aug  8 07:49:16 turtle kernel: [   91.697078] nouveau  [ 
>> >>> DRM][:01:00.0] resuming display...
>> >>> `
>> >> Interesting.  Were there any messages prior to that?
>> >
>> > Nothing interesting:
>> >
>> > ,
>> > | Aug  8 07:49:16 turtle kernel: [   89.655362] nouveau  [ 
>> > DRM][:01:00.0] suspending fbcon...
>> > | Aug  8 07:49:16 turtle kernel: [   89.655367] nouveau  [ 
>> > DRM][:01:00.0] suspending display...
>> > | Aug  8 07:49:16 turtle kernel: [   89.696888] nouveau  [ 
>> > DRM][:01:00.0] unpinning framebuffer(s)...
>> > | Aug  8 07:49:16 turtle kernel: [   89.696909] nouveau  [ 
>> > DRM][:01:00.0] evicting buffers...
>> > | Aug  8 07:49:16 turtle kernel: [   89.696913] nouveau  [ 
>> > DRM][:01:00.0] suspending client object trees...
>> > `
>> >
>> >> I guess the the fifo
>> >> code detected a timeout when trying to save the graphics context, I have
>> >> I have other patches in my tree (I'll push them soon, tied up with other
>> >> work atm) that might help here.
>> >
>> > Thanks, I'll try them when they are available.
>>
>> With current nouveau master ("drm/nouveau: fix find/replace bug in
>> license header") suspending works again, thanks!  However, it is a bit
>> slow, taking between two and five seconds:
>>
>> ,
>> | Aug 13 18:17:56 turtle kernel: [  678.524814] PM: Syncing filesystems ... 
>> done.
>> | Aug 13 18:18:09 turtle kernel: [  678.639202] Freezing user space 
>> processes ... (elapsed 0.01 seconds) done.
>> | Aug 13 18:18:09 turtle kernel: [  678.649954] Freezing remaining freezable 
>> tasks ... (elapsed 0.01 seconds) done.
>> | Aug 13 18:18:09 turtle kernel: [  678.663298] Suspending console(s) (use 
>> no_console_suspend to debug)
>> | Aug 13 18:18:09 turtle kernel: [  678.680884] sd 0:0:0:0: [sda] 
>> Synchronizing SCSI cache
>> | Aug 13 18:18:09 turtle kernel: [  678.681000] sd 0:0:0:0: [sda] Stopping 
>> disk
>> | Aug 13 18:18:09 turtle kernel: [  678.695141] parport_pc 00:07: disabled
>> | Aug 13 18:18:09 turtle kernel: [  678.695204] serial 00:06: disabled
>> | Aug 13 18:18:09 turtle kernel: [  678.695209] serial 00:06: wake-up 
>> capability disabled by ACPI
>> | Aug 13 18:18:09 turtle kernel: [  678.695235] nouveau  [ 
>> DRM][:01:00.0] suspending fbcon...
>> | Aug 13 18:18:09 turtle kernel: [  678.695239] nouveau  [ 
>> DRM][:01:00.0] suspending display...
>> | Aug 13 18:18:09 turtle kernel: [  678.742111] nouveau  [ 
>> DRM][:01:00.0] unpinning framebuffer(s)...
>> | Aug 13 18:18:09 turtle kernel: [  678.742189] nouveau  [ 
>> DRM][:01:00.0] evicting buffers...
>> | Aug 13 18:18:09 turtle kernel: [  682.357319] nouveau  [ 
>> DRM][:01:00.0] suspending client object trees...
>> | Aug 13 18:18:09 turtle kernel: [  683.526646] PM: suspend of devices 
>> complete after 4863.181 msecs
>> `
>>
>> With the 3.4.8 kernel, suspending takes little more than one second.
>>
>> Cheers,
>>Sven
> I confirm exactly the same thing.
>
> Here suspend takes more that 10 seconds:
>
> [ 2165.363878] nouveau  [ DRM][:01:00.0] suspending fbcon...
> [ 2165.363885] nouveau  [ DRM][:01:00.0] suspending display...
> [ 2165.475791] sd 0:0:0:0: [sda] Stopping disk
> [ 2166.396877] nouveau  [ DRM][:01:00.0] unpinning
> framebuffer(s)...
> [ 2166.396926] nouveau  [ DRM][:01:00.0] evicting buffers...
> [ 2174.809084] nouveau  [ DRM][:01:00.0] suspending client
> object trees...
> [ 2177.950222] nouveau :01:00.0: power state changed by ACPI to D3
>
>
> Best regards,
> Maxim Levitsky
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau

In my case suspend also takes longer than usual, in the order of 10 seconds.

@Ben: Have you been able to reproduce this?

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Nouveau] [bisected] nouveau: Failed to idle channel x after resume

[Maarten Maathuis]

On Mon, Aug 13, 2012 at 9:49 PM, Maxim Levitsky maximlevit...@gmail.com wrote:
 On Mon, 2012-08-13 at 18:22 +0200, Sven Joachim wrote:
 On 2012-08-08 08:18 +0200, Sven Joachim wrote:

  On 2012-08-08 08:08 +0200, Ben Skeggs wrote:
 
  On Wed, Aug 08, 2012 at 08:00:21AM +0200, Sven Joachim wrote:
  Not for me on my GeForce 8500 GT, and I still cannot suspend more than
  once, subsequent attempts fail:
 
  ,
  | Aug 8 07:49:16 turtle kernel: [ 91.697068] nouveau W[
  | PGRAPH][:01:00.0][0x0200502d][880037be1d40] parent failed
  | suspend, -16
  | Aug  8 07:49:16 turtle kernel: [   91.697078] nouveau  [ 
  DRM][:01:00.0] resuming display...
  `
  Interesting.  Were there any messages prior to that?
 
  Nothing interesting:
 
  ,
  | Aug  8 07:49:16 turtle kernel: [   89.655362] nouveau  [ 
  DRM][:01:00.0] suspending fbcon...
  | Aug  8 07:49:16 turtle kernel: [   89.655367] nouveau  [ 
  DRM][:01:00.0] suspending display...
  | Aug  8 07:49:16 turtle kernel: [   89.696888] nouveau  [ 
  DRM][:01:00.0] unpinning framebuffer(s)...
  | Aug  8 07:49:16 turtle kernel: [   89.696909] nouveau  [ 
  DRM][:01:00.0] evicting buffers...
  | Aug  8 07:49:16 turtle kernel: [   89.696913] nouveau  [ 
  DRM][:01:00.0] suspending client object trees...
  `
 
  I guess the the fifo
  code detected a timeout when trying to save the graphics context, I have
  I have other patches in my tree (I'll push them soon, tied up with other
  work atm) that might help here.
 
  Thanks, I'll try them when they are available.

 With current nouveau master (drm/nouveau: fix find/replace bug in
 license header) suspending works again, thanks!  However, it is a bit
 slow, taking between two and five seconds:

 ,
 | Aug 13 18:17:56 turtle kernel: [  678.524814] PM: Syncing filesystems ... 
 done.
 | Aug 13 18:18:09 turtle kernel: [  678.639202] Freezing user space 
 processes ... (elapsed 0.01 seconds) done.
 | Aug 13 18:18:09 turtle kernel: [  678.649954] Freezing remaining freezable 
 tasks ... (elapsed 0.01 seconds) done.
 | Aug 13 18:18:09 turtle kernel: [  678.663298] Suspending console(s) (use 
 no_console_suspend to debug)
 | Aug 13 18:18:09 turtle kernel: [  678.680884] sd 0:0:0:0: [sda] 
 Synchronizing SCSI cache
 | Aug 13 18:18:09 turtle kernel: [  678.681000] sd 0:0:0:0: [sda] Stopping 
 disk
 | Aug 13 18:18:09 turtle kernel: [  678.695141] parport_pc 00:07: disabled
 | Aug 13 18:18:09 turtle kernel: [  678.695204] serial 00:06: disabled
 | Aug 13 18:18:09 turtle kernel: [  678.695209] serial 00:06: wake-up 
 capability disabled by ACPI
 | Aug 13 18:18:09 turtle kernel: [  678.695235] nouveau  [ 
 DRM][:01:00.0] suspending fbcon...
 | Aug 13 18:18:09 turtle kernel: [  678.695239] nouveau  [ 
 DRM][:01:00.0] suspending display...
 | Aug 13 18:18:09 turtle kernel: [  678.742111] nouveau  [ 
 DRM][:01:00.0] unpinning framebuffer(s)...
 | Aug 13 18:18:09 turtle kernel: [  678.742189] nouveau  [ 
 DRM][:01:00.0] evicting buffers...
 | Aug 13 18:18:09 turtle kernel: [  682.357319] nouveau  [ 
 DRM][:01:00.0] suspending client object trees...
 | Aug 13 18:18:09 turtle kernel: [  683.526646] PM: suspend of devices 
 complete after 4863.181 msecs
 `

 With the 3.4.8 kernel, suspending takes little more than one second.

 Cheers,
Sven
 I confirm exactly the same thing.

 Here suspend takes more that 10 seconds:

 [ 2165.363878] nouveau  [ DRM][:01:00.0] suspending fbcon...
 [ 2165.363885] nouveau  [ DRM][:01:00.0] suspending display...
 [ 2165.475791] sd 0:0:0:0: [sda] Stopping disk
 [ 2166.396877] nouveau  [ DRM][:01:00.0] unpinning
 framebuffer(s)...
 [ 2166.396926] nouveau  [ DRM][:01:00.0] evicting buffers...
 [ 2174.809084] nouveau  [ DRM][:01:00.0] suspending client
 object trees...
 [ 2177.950222] nouveau :01:00.0: power state changed by ACPI to D3


 Best regards,
 Maxim Levitsky

 ___
 Nouveau mailing list
 nouv...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/nouveau

In my case suspend also takes longer than usual, in the order of 10 seconds.

@Ben: Have you been able to reproduce this?

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[x86_64] Cannot get the NMI watchdog to work

[Maarten Maathuis]

Please CC me when replying.

Kernel is a 2.6.24-rt1.

Summary:
- 0 NMI interrupts occur by default (this remains true for any
situation encountered).
- nmi_watchdog=1 disables lapic for some reason.
- I have no hpet it seems, hpet=force doesn't do any good (the oposite
actually).
- I never get any reference of hpet in my dmesg.
- oprofile module is not loaded.
- My interrupts seem to have IO-APIC-* mode.
- My chipset is a nvidia CK804.

Can anyone shed some light on what is needed to get a working NMI watchdog?

Sincerely,

Maarten Maathuis.
--
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/

[x86_64] Cannot get the NMI watchdog to work

[Maarten Maathuis]

Please CC me when replying.

Kernel is a 2.6.24-rt1.

Summary:
- 0 NMI interrupts occur by default (this remains true for any
situation encountered).
- nmi_watchdog=1 disables lapic for some reason.
- I have no hpet it seems, hpet=force doesn't do any good (the oposite
actually).
- I never get any reference of hpet in my dmesg.
- oprofile module is not loaded.
- My interrupts seem to have IO-APIC-* mode.
- My chipset is a nvidia CK804.

Can anyone shed some light on what is needed to get a working NMI watchdog?

Sincerely,

Maarten Maathuis.
--
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: [sata_nv] timeout waiting for ADMA IDLE, stat=0x440

[Maarten Maathuis]

At this point it safe to say that it was a cable related issue.

I swapped it to be sure and i haven't had issues since.

Sincerely,

Maarten Maathuis.

On 9/5/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Tue, 28 Aug 2007 16:06:41 +0200 "Maarten Maathuis" <[EMAIL PROTECTED]> 
> > wrote:
> > I have not had any issues, i swapped the cable because a while ago i
> > had to check the connection of the drive after the bios failed to
> > detect the drive. That is why i considered that a posibility. Kernel
> > 2.6.18 does not have NCQ support for nvidia chipsets, so that cannot
> > be it.
> >
> > Maarten.
> >
> > On 8/28/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> > >
> > > On Aug 25 2007 15:37, Maarten Maathuis wrote:
> > > >
> > > >A broken cable seems like a realistic possibility, so i swapped it for
> > > >another cable. I will try if that solves the problem.
> > >
> > > Hi, did you have any success/failure, other updates?
> > > I am facing a similar problem (just posted to [EMAIL PROTECTED]),
> > > but also with 2.6.18, and it does not look like an NCQ or loose cable 
> > > problem (got a
> > > backplane, and sda is working normal).
> > >
>
> This is a rather comedic email thread, with people top-posting, others
> leaving others off the cc list, Robert's MUA reliably and inexplicably
> mangling both In-Reply-To: and References: thus breaking threading, no
> visible sign of how Jan got involved and no linux-ide cc's.
>
> Enough time has passed for everyone to forget all about this.  So Maarten,
> if you still believe that this is still a kernel bug then please update us
> on its status and provide a full description for linux-ide..  Please use
> reply-to-all for that.
>
> Thanks.
>
-
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: [sata_nv] timeout waiting for ADMA IDLE, stat=0x440

[Maarten Maathuis]

At this point it safe to say that it was a cable related issue.

I swapped it to be sure and i haven't had issues since.

Sincerely,

Maarten Maathuis.

On 9/5/07, Andrew Morton [EMAIL PROTECTED] wrote:
  On Tue, 28 Aug 2007 16:06:41 +0200 Maarten Maathuis [EMAIL PROTECTED] 
  wrote:
  I have not had any issues, i swapped the cable because a while ago i
  had to check the connection of the drive after the bios failed to
  detect the drive. That is why i considered that a posibility. Kernel
  2.6.18 does not have NCQ support for nvidia chipsets, so that cannot
  be it.
 
  Maarten.
 
  On 8/28/07, Jan Engelhardt [EMAIL PROTECTED] wrote:
  
   On Aug 25 2007 15:37, Maarten Maathuis wrote:
   
   A broken cable seems like a realistic possibility, so i swapped it for
   another cable. I will try if that solves the problem.
  
   Hi, did you have any success/failure, other updates?
   I am facing a similar problem (just posted to [EMAIL PROTECTED]),
   but also with 2.6.18, and it does not look like an NCQ or loose cable 
   problem (got a
   backplane, and sda is working normal).
  

 This is a rather comedic email thread, with people top-posting, others
 leaving others off the cc list, Robert's MUA reliably and inexplicably
 mangling both In-Reply-To: and References: thus breaking threading, no
 visible sign of how Jan got involved and no linux-ide cc's.

 Enough time has passed for everyone to forget all about this.  So Maarten,
 if you still believe that this is still a kernel bug then please update us
 on its status and provide a full description for linux-ide..  Please use
 reply-to-all for that.

 Thanks.

-
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.22.1-rt4] very strange oops in the kernel, which made the system very slow to respond

[Maarten Maathuis]

Can anyone make sense of this?

I have not encountered something like this, nor do i know what this trace means.

Please CC me if you reply.

Sincerely,

Maarten Maathuis.

log snippet:

Aug 29 21:15:15 localhost Unable to handle kernel paging request at
81003a2c6518 RIP:
Aug 29 21:15:15 localhost []
Aug 29 21:15:15 localhost PGD 8063 PUD 9063 PMD 80003a2001e3 PTE
cb7794f74fd27497
Aug 29 21:15:15 localhost Oops: 0011 [1] PREEMPT
Aug 29 21:15:15 localhost CPU 0
Aug 29 21:15:15 localhost Modules linked in: sch_sfq cls_fw sch_htb
ip6table_filter iptable_raw xt_comment xt_policy xt_multiport ipt_ULOG
ipt_TTL ipt_ttl ipt_TOS ipt_tos ipt_SAME ipt_REJECT ipt_REDIRECT
ipt_recent ipt_owner ipt_NETMAP ipt_MASQUERADE ipt_LOG ipt_iprange
ipt_ECN ipt_ecn ipt_CLUSTERIP ipt_ah ipt_addrtype nf_nat_tftp
nf_nat_snmp_basic nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc
nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda
nf_conntrack_tftp nf_conntrack_sip nf_conntrack_proto_sctp
nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink
nf_conntrack_netbios_ns nf_conntrack_irc nf_conntrack_h323 xt_tcpmss
xt_pkttype xt_NFQUEUE xt_NFLOG xt_MARK xt_mark xt_mac xt_limit
xt_length xt_helper xt_hashlimit ip6_tables xt_dccp xt_conntrack
xt_connmark xt_CLASSIFY xt_tcpudp xt_state iptable_nat nf_nat
nf_conntrack_ipv4 iptable_mangle iptable_filter ip_tables x_tables
nf_conntrack_ftp nf_conntrack nfnetlink it87 hwmon_vid i2c_isa
i2c_nforce2 ivtv cx25840 wm8775 tuner cx2341x tveeprom videodev
v4l2_common v4l1_compat nouveau drm snd_ice1724 snd_ice17xx_ak4xxx
snd_ac97_codec ac97_bus snd_ak4114 snd_pcm snd_page_alloc snd_pt2258
snd_i2c snd_ak4xxx_adda snd_mpu401_uart snd_rawmidi k8temp
Aug 29 21:15:15 localhost Pid: 12, comm: softirq-rcu/0 Not tainted
2.6.22.1-rt4 #1
Aug 29 21:15:15 localhost RIP: 0010:[]  []
Aug 29 21:15:15 localhost RSP: :81003ffa9ed8  EFLAGS: 00010282
Aug 29 21:15:15 localhost RAX: feff RBX: 810006803500
RCX: 027c
Aug 29 21:15:15 localhost RDX: 81003ffa0100 RSI: 810038160240
RDI: 81002d613c80
Aug 29 21:15:15 localhost RBP: 81002d613c80 R08: 81003ffa8000
R09: 807116e0
Aug 29 21:15:15 localhost R10:  R11: 007a1200
R12: 0100
Aug 29 21:15:15 localhost R13:  R14: 806a6be0
R15: 
Aug 29 21:15:15 localhost FS:  2ba7c91da6f0()
GS:80676000() knlGS:f738d6d0
Aug 29 21:15:15 localhost CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
Aug 29 21:15:15 localhost CR2: 81003a2c6518 CR3: 18fce000
CR4: 06e0
Aug 29 21:15:15 localhost Process softirq-rcu/0 (pid: 12, threadinfo
81003ffa8000, task 81003ffa0100)
Aug 29 21:15:15 localhost Stack:  80251fed 81003ffa9ef0
feff 8070d9c0
Aug 29 21:15:15 localhost 8022e7ce 0032
 8070d9c0
Aug 29 21:15:15 localhost 8022e6b8 81003ff83d00
8023aae3 
Aug 29 21:15:15 localhost Call Trace:
Aug 29 21:15:15 localhost [] rcu_process_callbacks+0x96/0xb1
Aug 29 21:15:15 localhost [] ksoftirqd+0x116/0x1b0
Aug 29 21:15:15 localhost [] ksoftirqd+0x0/0x1b0
Aug 29 21:15:15 localhost [] kthread+0x47/0x74
Aug 29 21:15:15 localhost [] child_rip+0xa/0x12
Aug 29 21:15:15 localhost [] kthread+0x0/0x74
Aug 29 21:15:15 localhost [] child_rip+0x0/0x12
Aug 29 21:15:15 localhost
Aug 29 21:15:15 localhost ---
Aug 29 21:15:15 localhost | preempt count:  ]
Aug 29 21:15:15 localhost | 0-level deep critical section nesting:
Aug 29 21:15:15 localhost 
Aug 29 21:15:15 localhost
Aug 29 21:15:15 localhost
Aug 29 21:15:15 localhost Code: 80 3c 61 2d 00 81 ff ff 00 ce b6 39 00
81 ff ff 28 65 2c 3a
Aug 29 21:15:15 localhost RIP  []
Aug 29 21:15:15 localhost RSP 
Aug 29 21:15:15 localhost CR2: 81003a2c6518
Aug 29 21:15:15 localhost BUG: sleeping function called from invalid
context softirq-rcu/0(12) at kernel/rtmutex.c:636
Aug 29 21:15:15 localhost in_atomic():0 [], irqs_disabled():1
Aug 29 21:15:15 localhost
Aug 29 21:15:15 localhost Call Trace:
Aug 29 21:15:15 localhost [] __rt_spin_lock+0x27/0x47
Aug 29 21:15:15 localhost [] __wake_up+0x1c/0x63
Aug 29 21:15:15 localhost [] oops_end+0x15/0x54
Aug 29 21:15:15 localhost [] do_page_fault+0x694/0x75f
Aug 29 21:15:15 localhost [] dequeue_task+0x16/0x24
Aug 29 21:15:15 localhost [] __switch_to+0x21/0x270
Aug 29 21:15:15 localhost [] enqueue_task+0x16/0x24
Aug 29 21:15:15 localhost [] activate_task+0x6f/0x8b
Aug 29 21:15:15 localhost [] try_to_wake_up+0xea/0x114
Aug 29 21:15:15 localhost [] error_exit+0x0/0x84
Aug 29 21:15:15 localhost [] rcu_process_callbacks+0x96/0xb1
Aug 29 21:15:15 localhost [] ksoftirqd+0x116/0x1b0
Aug 29 21:15:15 localhost [] ksoftirqd+0x0/0x1b0
Aug 29 21:15:15 localhost [] kthread+0x47/0x74
Aug 29 21:15:15 localhost [] child_rip+0xa/0x12
Aug 29 21:15:15

[2.6.22.1-rt4] very strange oops in the kernel, which made the system very slow to respond

[Maarten Maathuis]

Can anyone make sense of this?

I have not encountered something like this, nor do i know what this trace means.

Please CC me if you reply.

Sincerely,

Maarten Maathuis.

log snippet:

Aug 29 21:15:15 localhost Unable to handle kernel paging request at
81003a2c6518 RIP:
Aug 29 21:15:15 localhost [81003a2c6518]
Aug 29 21:15:15 localhost PGD 8063 PUD 9063 PMD 80003a2001e3 PTE
cb7794f74fd27497
Aug 29 21:15:15 localhost Oops: 0011 [1] PREEMPT
Aug 29 21:15:15 localhost CPU 0
Aug 29 21:15:15 localhost Modules linked in: sch_sfq cls_fw sch_htb
ip6table_filter iptable_raw xt_comment xt_policy xt_multiport ipt_ULOG
ipt_TTL ipt_ttl ipt_TOS ipt_tos ipt_SAME ipt_REJECT ipt_REDIRECT
ipt_recent ipt_owner ipt_NETMAP ipt_MASQUERADE ipt_LOG ipt_iprange
ipt_ECN ipt_ecn ipt_CLUSTERIP ipt_ah ipt_addrtype nf_nat_tftp
nf_nat_snmp_basic nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc
nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda
nf_conntrack_tftp nf_conntrack_sip nf_conntrack_proto_sctp
nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink
nf_conntrack_netbios_ns nf_conntrack_irc nf_conntrack_h323 xt_tcpmss
xt_pkttype xt_NFQUEUE xt_NFLOG xt_MARK xt_mark xt_mac xt_limit
xt_length xt_helper xt_hashlimit ip6_tables xt_dccp xt_conntrack
xt_connmark xt_CLASSIFY xt_tcpudp xt_state iptable_nat nf_nat
nf_conntrack_ipv4 iptable_mangle iptable_filter ip_tables x_tables
nf_conntrack_ftp nf_conntrack nfnetlink it87 hwmon_vid i2c_isa
i2c_nforce2 ivtv cx25840 wm8775 tuner cx2341x tveeprom videodev
v4l2_common v4l1_compat nouveau drm snd_ice1724 snd_ice17xx_ak4xxx
snd_ac97_codec ac97_bus snd_ak4114 snd_pcm snd_page_alloc snd_pt2258
snd_i2c snd_ak4xxx_adda snd_mpu401_uart snd_rawmidi k8temp
Aug 29 21:15:15 localhost Pid: 12, comm: softirq-rcu/0 Not tainted
2.6.22.1-rt4 #1
Aug 29 21:15:15 localhost RIP: 0010:[81003a2c6518]  [81003a2c6518]
Aug 29 21:15:15 localhost RSP: :81003ffa9ed8  EFLAGS: 00010282
Aug 29 21:15:15 localhost RAX: feff RBX: 810006803500
RCX: 027c
Aug 29 21:15:15 localhost RDX: 81003ffa0100 RSI: 810038160240
RDI: 81002d613c80
Aug 29 21:15:15 localhost RBP: 81002d613c80 R08: 81003ffa8000
R09: 807116e0
Aug 29 21:15:15 localhost R10:  R11: 007a1200
R12: 0100
Aug 29 21:15:15 localhost R13:  R14: 806a6be0
R15: 
Aug 29 21:15:15 localhost FS:  2ba7c91da6f0()
GS:80676000() knlGS:f738d6d0
Aug 29 21:15:15 localhost CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
Aug 29 21:15:15 localhost CR2: 81003a2c6518 CR3: 18fce000
CR4: 06e0
Aug 29 21:15:15 localhost Process softirq-rcu/0 (pid: 12, threadinfo
81003ffa8000, task 81003ffa0100)
Aug 29 21:15:15 localhost Stack:  80251fed 81003ffa9ef0
feff 8070d9c0
Aug 29 21:15:15 localhost 8022e7ce 0032
 8070d9c0
Aug 29 21:15:15 localhost 8022e6b8 81003ff83d00
8023aae3 
Aug 29 21:15:15 localhost Call Trace:
Aug 29 21:15:15 localhost [80251fed] rcu_process_callbacks+0x96/0xb1
Aug 29 21:15:15 localhost [8022e7ce] ksoftirqd+0x116/0x1b0
Aug 29 21:15:15 localhost [8022e6b8] ksoftirqd+0x0/0x1b0
Aug 29 21:15:15 localhost [8023aae3] kthread+0x47/0x74
Aug 29 21:15:15 localhost [80209cc8] child_rip+0xa/0x12
Aug 29 21:15:15 localhost [8023aa9c] kthread+0x0/0x74
Aug 29 21:15:15 localhost [80209cbe] child_rip+0x0/0x12
Aug 29 21:15:15 localhost
Aug 29 21:15:15 localhost ---
Aug 29 21:15:15 localhost | preempt count:  ]
Aug 29 21:15:15 localhost | 0-level deep critical section nesting:
Aug 29 21:15:15 localhost 
Aug 29 21:15:15 localhost
Aug 29 21:15:15 localhost
Aug 29 21:15:15 localhost Code: 80 3c 61 2d 00 81 ff ff 00 ce b6 39 00
81 ff ff 28 65 2c 3a
Aug 29 21:15:15 localhost RIP  [81003a2c6518]
Aug 29 21:15:15 localhost RSP 81003ffa9ed8
Aug 29 21:15:15 localhost CR2: 81003a2c6518
Aug 29 21:15:15 localhost BUG: sleeping function called from invalid
context softirq-rcu/0(12) at kernel/rtmutex.c:636
Aug 29 21:15:15 localhost in_atomic():0 [], irqs_disabled():1
Aug 29 21:15:15 localhost
Aug 29 21:15:15 localhost Call Trace:
Aug 29 21:15:15 localhost [804d99a8] __rt_spin_lock+0x27/0x47
Aug 29 21:15:15 localhost [80226863] __wake_up+0x1c/0x63
Aug 29 21:15:15 localhost [804da2ec] oops_end+0x15/0x54
Aug 29 21:15:15 localhost [804dbbdf] do_page_fault+0x694/0x75f
Aug 29 21:15:15 localhost [80222e9d] dequeue_task+0x16/0x24
Aug 29 21:15:15 localhost [804d9c91] __switch_to+0x21/0x270
Aug 29 21:15:15 localhost [80222e79] enqueue_task+0x16/0x24
Aug 29 21:15:15 localhost [8022386f] activate_task+0x6f/0x8b
Aug 29 21:15:15 localhost [80225c50] try_to_wake_up

Re: [sata_nv] timeout waiting for ADMA IDLE, stat=0x440

[Maarten Maathuis]

I have not had any issues, i swapped the cable because a while ago i
had to check the connection of the drive after the bios failed to
detect the drive. That is why i considered that a posibility. Kernel
2.6.18 does not have NCQ support for nvidia chipsets, so that cannot
be it.

Maarten.

On 8/28/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
> On Aug 25 2007 15:37, Maarten Maathuis wrote:
> >
> >A broken cable seems like a realistic possibility, so i swapped it for
> >another cable. I will try if that solves the problem.
>
> Hi, did you have any success/failure, other updates?
> I am facing a similar problem (just posted to [EMAIL PROTECTED]),
> but also with 2.6.18, and it does not look like an NCQ or loose cable problem 
> (got a
> backplane, and sda is working normal).
>
> Jan
> --
>
-
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: [sata_nv] timeout waiting for ADMA IDLE, stat=0x440

[Maarten Maathuis]

I have not had any issues, i swapped the cable because a while ago i
had to check the connection of the drive after the bios failed to
detect the drive. That is why i considered that a posibility. Kernel
2.6.18 does not have NCQ support for nvidia chipsets, so that cannot
be it.

Maarten.

On 8/28/07, Jan Engelhardt [EMAIL PROTECTED] wrote:

 On Aug 25 2007 15:37, Maarten Maathuis wrote:
 
 A broken cable seems like a realistic possibility, so i swapped it for
 another cable. I will try if that solves the problem.

 Hi, did you have any success/failure, other updates?
 I am facing a similar problem (just posted to [EMAIL PROTECTED]),
 but also with 2.6.18, and it does not look like an NCQ or loose cable problem 
 (got a
 backplane, and sda is working normal).

 Jan
 --

-
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: [sata_nv] timeout waiting for ADMA IDLE, stat=0x440

[Maarten Maathuis]

A broken cable seems like a realistic possibility, so i swapped it for
another cable. I will try if that solves the problem.

Maarten.

On 8/25/07, Robert Hancock <[EMAIL PROTECTED]> wrote:
> Maarten Maathuis wrote:
> > I have this problem several times, always with the same harddrive, a
> > samsung sp2004c. My samsung hd161hj and hd321kj don't seem to suffer
> > from this problem. I do not know when exactly it happened for the
> > first, but it has happened twice on a 2.6.22 kernel.
> >
> > Is there anything that can be done about this (besides disabling adma
> > for all drives), or any information i can provide to help?
> >
> > Please CC me, as i am not a member of this mailinglist.
> >
> > Sincerely,
> >
> > Maarten Maathuis.
> >
> > dmesg snippet:
> >
> > ata4: timeout waiting for ADMA IDLE, stat=0x440
> > ata4.00: qc timeout (cmd 0x2f)
> > ata4: failed to read log page 10h (errno=-5)
> > ata4.00: exception Emask 0x1 SAct 0x1 SErr 0x38 action 0x2 frozen
> > ata4.00: (CPB resp_flags 0x11: CMD error)
> > ata4.00: cmd 60/80:00:89:b0:30/00:00:02:00:00/40 tag 0 cdb 0x0 data 65536 in
> >  res 51/84:00:02:00:00/84:00:02:00:00/40 Emask 0x10 (ATA bus error)
>
> Sounds like the drive has gotten into a really hosed state after this
> point. The SError register is showing a CRC error, disparity error, and
> 10b to 8b decode error, which indicates that there are some major SATA
> communication problems happening.
>
> It could be a hardware problem (bad drive, bad SATA cable, insufficient
> power, etc.) or maybe this is another drive with broken NCQ..
>
> --
> Robert Hancock  Saskatoon, SK, Canada
> To email, remove "nospam" from [EMAIL PROTECTED]
> Home Page: http://www.roberthancock.com/
>
>
-
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: [sata_nv] timeout waiting for ADMA IDLE, stat=0x440

[Maarten Maathuis]

A broken cable seems like a realistic possibility, so i swapped it for
another cable. I will try if that solves the problem.

Maarten.

On 8/25/07, Robert Hancock [EMAIL PROTECTED] wrote:
 Maarten Maathuis wrote:
  I have this problem several times, always with the same harddrive, a
  samsung sp2004c. My samsung hd161hj and hd321kj don't seem to suffer
  from this problem. I do not know when exactly it happened for the
  first, but it has happened twice on a 2.6.22 kernel.
 
  Is there anything that can be done about this (besides disabling adma
  for all drives), or any information i can provide to help?
 
  Please CC me, as i am not a member of this mailinglist.
 
  Sincerely,
 
  Maarten Maathuis.
 
  dmesg snippet:
 
  ata4: timeout waiting for ADMA IDLE, stat=0x440
  ata4.00: qc timeout (cmd 0x2f)
  ata4: failed to read log page 10h (errno=-5)
  ata4.00: exception Emask 0x1 SAct 0x1 SErr 0x38 action 0x2 frozen
  ata4.00: (CPB resp_flags 0x11: CMD error)
  ata4.00: cmd 60/80:00:89:b0:30/00:00:02:00:00/40 tag 0 cdb 0x0 data 65536 in
   res 51/84:00:02:00:00/84:00:02:00:00/40 Emask 0x10 (ATA bus error)

 Sounds like the drive has gotten into a really hosed state after this
 point. The SError register is showing a CRC error, disparity error, and
 10b to 8b decode error, which indicates that there are some major SATA
 communication problems happening.

 It could be a hardware problem (bad drive, bad SATA cable, insufficient
 power, etc.) or maybe this is another drive with broken NCQ..

 --
 Robert Hancock  Saskatoon, SK, Canada
 To email, remove nospam from [EMAIL PROTECTED]
 Home Page: http://www.roberthancock.com/


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

[sata_nv] timeout waiting for ADMA IDLE, stat=0x440

[Maarten Maathuis]

I have this problem several times, always with the same harddrive, a
samsung sp2004c. My samsung hd161hj and hd321kj don't seem to suffer
from this problem. I do not know when exactly it happened for the
first, but it has happened twice on a 2.6.22 kernel.

Is there anything that can be done about this (besides disabling adma
for all drives), or any information i can provide to help?

Please CC me, as i am not a member of this mailinglist.

Sincerely,

Maarten Maathuis.

dmesg snippet:

ata4: timeout waiting for ADMA IDLE, stat=0x440
ata4.00: qc timeout (cmd 0x2f)
ata4: failed to read log page 10h (errno=-5)
ata4.00: exception Emask 0x1 SAct 0x1 SErr 0x38 action 0x2 frozen
ata4.00: (CPB resp_flags 0x11: CMD error)
ata4.00: cmd 60/80:00:89:b0:30/00:00:02:00:00/40 tag 0 cdb 0x0 data 65536 in
 res 51/84:00:02:00:00/84:00:02:00:00/40 Emask 0x10 (ATA bus error)
ata4: port is slow to respond, please be patient (Status 0xd1)
ata4: device not ready (errno=-16), forcing hardreset
ata4: hard resetting port
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting port
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting port
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting port
ata4: COMRESET failed (errno=-16)
ata4: reset failed, giving up
ata4.00: disabled
ata4: EH pending after completion, repeating EH (cnt=4)
ata4: exception Emask 0x10 SAct 0x0 SErr 0x3d action 0x2 frozen
ata4: hard resetting port
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting port
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting port
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting port
ata4: COMRESET failed (errno=-16)
ata4: reset failed, giving up
ata4: EH pending after completion, repeating EH (cnt=3)
ata4: exception Emask 0x10 SAct 0x0 SErr 0x3d action 0x2 frozen
ata4: hard resetting port
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting port
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting port
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting port
ata4: COMRESET failed (errno=-16)
ata4: reset failed, giving up
ata4: EH pending after completion, repeating EH (cnt=2)
ata4: exception Emask 0x10 SAct 0x0 SErr 0x3d action 0x2 frozen
ata4: hard resetting port
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting port
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting port
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting port
ata4: COMRESET failed (errno=-16)
ata4: reset failed, giving up
ata4: EH pending after completion, repeating EH (cnt=1)
ata4: exception Emask 0x10 SAct 0x0 SErr 0x3d action 0x2 frozen
ata4: hard resetting port
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting port
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting port
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting port
ata4: COMRESET failed (errno=-16)
ata4: reset failed, giving up
ata4: EH pending after 5 tries, giving up
sd 3:0:0:0: [sdc] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sd 3:0:0:0: [sdc] Sense Key : Aborted Command [current] [descriptor]
Descriptor sense data with sense descriptors (in hex):
72 0b 47 00 00 00 00 0c 00 0a 80 00 00 00 00 00
02 00 00 02
sd 3:0:0:0: [sdc] Add. Sense: Scsi parity error
end_request: I/O error, dev sdc, sector 36745353
ata4: EH complete
ata4.00: detaching (SCSI 3:0:0:0)
sd 3:0:0:0: [sdc] Synchronizing SCSI cache
sd 3:0:0:0: [sdc] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
sd 3:0:0:0: [sdc] Stopping disk
sd 3:0:0:0: [sdc] START_STOP FAILED
sd 3:0:0:0: [sdc] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
scsi 3:0:0:0: rejecting I/O to dead device
scsi 3:0:0:0: rejecting I/O to dead device
scsi 3:0:0:0: rejecting I/O to dead device
scsi 3:0:0:0: rejecting I/O to dead device
scsi 3:0:0:0: rejecting I/O to dead device
-
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://w

[sata_nv] timeout waiting for ADMA IDLE, stat=0x440

[Maarten Maathuis]

I have this problem several times, always with the same harddrive, a
samsung sp2004c. My samsung hd161hj and hd321kj don't seem to suffer
from this problem. I do not know when exactly it happened for the
first, but it has happened twice on a 2.6.22 kernel.

Is there anything that can be done about this (besides disabling adma
for all drives), or any information i can provide to help?

Please CC me, as i am not a member of this mailinglist.

Sincerely,

Maarten Maathuis.

dmesg snippet:

ata4: timeout waiting for ADMA IDLE, stat=0x440
ata4.00: qc timeout (cmd 0x2f)
ata4: failed to read log page 10h (errno=-5)
ata4.00: exception Emask 0x1 SAct 0x1 SErr 0x38 action 0x2 frozen
ata4.00: (CPB resp_flags 0x11: CMD error)
ata4.00: cmd 60/80:00:89:b0:30/00:00:02:00:00/40 tag 0 cdb 0x0 data 65536 in
 res 51/84:00:02:00:00/84:00:02:00:00/40 Emask 0x10 (ATA bus error)
ata4: port is slow to respond, please be patient (Status 0xd1)
ata4: device not ready (errno=-16), forcing hardreset
ata4: hard resetting port
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting port
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting port
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting port
ata4: COMRESET failed (errno=-16)
ata4: reset failed, giving up
ata4.00: disabled
ata4: EH pending after completion, repeating EH (cnt=4)
ata4: exception Emask 0x10 SAct 0x0 SErr 0x3d action 0x2 frozen
ata4: hard resetting port
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting port
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting port
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting port
ata4: COMRESET failed (errno=-16)
ata4: reset failed, giving up
ata4: EH pending after completion, repeating EH (cnt=3)
ata4: exception Emask 0x10 SAct 0x0 SErr 0x3d action 0x2 frozen
ata4: hard resetting port
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting port
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting port
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting port
ata4: COMRESET failed (errno=-16)
ata4: reset failed, giving up
ata4: EH pending after completion, repeating EH (cnt=2)
ata4: exception Emask 0x10 SAct 0x0 SErr 0x3d action 0x2 frozen
ata4: hard resetting port
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting port
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting port
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting port
ata4: COMRESET failed (errno=-16)
ata4: reset failed, giving up
ata4: EH pending after completion, repeating EH (cnt=1)
ata4: exception Emask 0x10 SAct 0x0 SErr 0x3d action 0x2 frozen
ata4: hard resetting port
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting port
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting port
ata4: port is slow to respond, please be patient (Status 0x80)
ata4: COMRESET failed (errno=-16)
ata4: hard resetting port
ata4: COMRESET failed (errno=-16)
ata4: reset failed, giving up
ata4: EH pending after 5 tries, giving up
sd 3:0:0:0: [sdc] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sd 3:0:0:0: [sdc] Sense Key : Aborted Command [current] [descriptor]
Descriptor sense data with sense descriptors (in hex):
72 0b 47 00 00 00 00 0c 00 0a 80 00 00 00 00 00
02 00 00 02
sd 3:0:0:0: [sdc] Add. Sense: Scsi parity error
end_request: I/O error, dev sdc, sector 36745353
ata4: EH complete
ata4.00: detaching (SCSI 3:0:0:0)
sd 3:0:0:0: [sdc] Synchronizing SCSI cache
sd 3:0:0:0: [sdc] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
sd 3:0:0:0: [sdc] Stopping disk
sd 3:0:0:0: [sdc] START_STOP FAILED
sd 3:0:0:0: [sdc] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
scsi 3:0:0:0: rejecting I/O to dead device
scsi 3:0:0:0: rejecting I/O to dead device
scsi 3:0:0:0: rejecting I/O to dead device
scsi 3:0:0:0: rejecting I/O to dead device
scsi 3:0:0:0: rejecting I/O to dead device
-
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: [realtime-preempt] [x86_64] HR_TIMER and/or DYNTICKS cause an early boot freeze

[Maarten Maathuis]

Were can -rt3 be found?

On 7/13/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:

On Fri, 2007-07-13 at 16:02 +0200, Maarten Maathuis wrote:
> I have determined that version 2.6.22.1-rt2 freeze after:
>
> NET: Register protocol family 2
>
> This is very early in the boot stage, and i cannot determine what
> exactly causes it.
>
> It happens if either high resolution timers or dynamic ticks are active.
>
> I have included the config file that does work (so dynticks and
> hr_timers are disabled).
>
> Please CC any replies, as i am not a member of this mailinglist.

Try -rt3, that solved this issue for me.



-
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: [realtime-preempt] [x86_64] HR_TIMER and/or DYNTICKS cause an early boot freeze

[Maarten Maathuis]

Were can -rt3 be found?

On 7/13/07, Peter Zijlstra [EMAIL PROTECTED] wrote:

On Fri, 2007-07-13 at 16:02 +0200, Maarten Maathuis wrote:
 I have determined that version 2.6.22.1-rt2 freeze after:

 NET: Register protocol family 2

 This is very early in the boot stage, and i cannot determine what
 exactly causes it.

 It happens if either high resolution timers or dynamic ticks are active.

 I have included the config file that does work (so dynticks and
 hr_timers are disabled).

 Please CC any replies, as i am not a member of this mailinglist.

Try -rt3, that solved this issue for me.



-
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: [realtime kernel 2.6.21-rt2 and up] Extremely slow bootup for x86_64

[Maarten Maathuis]

2.6.21-rt6 is working normally as far as i can see.

Maarten.

On 5/21/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:

On Mon, 2007-05-21 at 10:11 -0500, Frank Sorenson wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Thomas Gleixner wrote:
> > On Mon, 2007-05-21 at 00:00 -0500, Frank Sorenson wrote:
> >
> >> I see the slow bootup as well, even with 2.6.22-rc2-hrt1.  It takes at
> >> least 5 times as long to boot, for X to start, to login, etc.
> >
> > Can you provide me your .config and a boot log (please enable
> > CONFIG_PRINTK_TIME and add "apic=verbose" to the kernel command line).
> >
> > Can you also try with "hpet=disable" ?
>
> All attached.  With "hpet=disable", it's still slow (clocksource becomes
> acpi_pm).

> [   23.159166] Bluetooth: HCI device and connection manager initialized
> [   23.159170] Bluetooth: HCI socket layer initialized
> [   23.159179] BUG: at mm/slab.c:777 __find_general_cachep()
> [   23.159181]
> [   23.159182] Call Trace:
> [   23.159190]  [] __kmalloc+0xa7/0xe0
> [   23.159195]  [] cache_k8_northbridges+0x9d/0x120
> [   23.159200]  [] gart_iommu_init+0x33/0x5b0
> [   23.159205]  [] class_register+0x177/0x180
> [   23.159210]  [] pci_iommu_init+0x9/0x20
> [   23.159214]  [] kernel_init+0x14c/0x320
> [   23.159218]  [] child_rip+0xa/0x12
> [   23.159223]  [] acpi_ds_init_one_object+0x0/0x7c
> [   23.159227]  [] kernel_init+0x0/0x320
> [   23.159230]  [] child_rip+0x0/0x12

Hmm, other than this gem there is nothing obvious in the boot log. Does
the box boot normal with 2.6.22-rc2 ?

Where does the slowness start ? Right from the beginning or later in the
boot process ?

tglx




-
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: [realtime kernel 2.6.21-rt2 and up] Extremely slow bootup for x86_64

[Maarten Maathuis]

2.6.21-rt6 is working normally as far as i can see.

Maarten.

On 5/21/07, Thomas Gleixner [EMAIL PROTECTED] wrote:

On Mon, 2007-05-21 at 10:11 -0500, Frank Sorenson wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Thomas Gleixner wrote:
  On Mon, 2007-05-21 at 00:00 -0500, Frank Sorenson wrote:
 
  I see the slow bootup as well, even with 2.6.22-rc2-hrt1.  It takes at
  least 5 times as long to boot, for X to start, to login, etc.
 
  Can you provide me your .config and a boot log (please enable
  CONFIG_PRINTK_TIME and add apic=verbose to the kernel command line).
 
  Can you also try with hpet=disable ?

 All attached.  With hpet=disable, it's still slow (clocksource becomes
 acpi_pm).

 [   23.159166] Bluetooth: HCI device and connection manager initialized
 [   23.159170] Bluetooth: HCI socket layer initialized
 [   23.159179] BUG: at mm/slab.c:777 __find_general_cachep()
 [   23.159181]
 [   23.159182] Call Trace:
 [   23.159190]  [81097a67] __kmalloc+0xa7/0xe0
 [   23.159195]  [810238dd] cache_k8_northbridges+0x9d/0x120
 [   23.159200]  [814ddce3] gart_iommu_init+0x33/0x5b0
 [   23.159205]  [811d4027] class_register+0x177/0x180
 [   23.159210]  [814d8379] pci_iommu_init+0x9/0x20
 [   23.159214]  [814cf6cc] kernel_init+0x14c/0x320
 [   23.159218]  [8100b1b8] child_rip+0xa/0x12
 [   23.159223]  [81184150] acpi_ds_init_one_object+0x0/0x7c
 [   23.159227]  [814cf580] kernel_init+0x0/0x320
 [   23.159230]  [8100b1ae] child_rip+0x0/0x12

Hmm, other than this gem there is nothing obvious in the boot log. Does
the box boot normal with 2.6.22-rc2 ?

Where does the slowness start ? Right from the beginning or later in the
boot process ?

tglx




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