Patchwork 2.6.37-rc2-git4: Reported regressions 2.6.35 -> 2.6.36

login
register
mail settings
Submitter Mark Lord
Date Nov. 19, 2010, 10:55 p.m.
Message ID <4CE7006E.4040102@teksavvy.com>
Download mbox | patch
Permalink /patch/72324/
State Not Applicable
Delegated to: David Miller
Headers show

Comments

Mark Lord - Nov. 19, 2010, 10:55 p.m.
On 10-11-19 11:39 AM, Alex Deucher wrote:
> On Thu, Nov 18, 2010 at 7:47 PM, Mark Lord<kernel@teksavvy.com>  wrote:
>
>> My non-Intel graphics notebook (has ATI X1400 graphics) also has a resume
>> regression with 2.6.36.  But it does work fine with 2.6.35 (and earlier,
>> back many years).  As a result, I'm stuck with 2.6.35 for the time being,
>> and lack the time for a concerted debug effort on 2.6.36+ right now.
>>
>
> Can you bisect?  Does this patch help?
>
> diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
> index 8e421f6..05efb5b 100644
> --- a/drivers/gpu/drm/radeon/atom.c
> +++ b/drivers/gpu/drm/radeon/atom.c
> @@ -112,6 +112,7 @@ static uint32_t atom_iio_execute(struct
> atom_context *ctx, int base,
>                          base += 3;
>                          break;
>                  case ATOM_IIO_WRITE:
> +                       (void)ctx->card->ioreg_read(ctx->card, CU16(base + 1));
>                          ctx->card->ioreg_write(ctx->card, CU16(base + 1), temp);
>                          base += 3;
>                          break;

It now comes back at resume time.

But suffers long delays (also sometimes with 2.6.35) doing this:

[drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting
[drm:atom_execute_table_locked] *ERROR* atombios stuck executing E576 (len 105, 
WS 12, PS 8) @ 0xE5C4
[drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting
[drm:atom_execute_table_locked] *ERROR* atombios stuck executing ECD2 (len 86, 
WS 4, PS 0) @ 0xED05
[drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting
[drm:atom_execute_table_locked] *ERROR* atombios stuck executing E576 (len 105, 
WS 12, PS 8) @ 0xE5C4
PM: resume of devices complete after 15718.253 msecs

So I did this (local hack only, obviously NOT for mainline) to work around that 
issue:

         ws = CU8(base + ATOM_CT_WS_PTR);
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Alex Deucher - Nov. 19, 2010, 10:58 p.m.
On Fri, Nov 19, 2010 at 5:55 PM, Mark Lord <kernel@teksavvy.com> wrote:
> On 10-11-19 11:39 AM, Alex Deucher wrote:
>>
>> On Thu, Nov 18, 2010 at 7:47 PM, Mark Lord<kernel@teksavvy.com>  wrote:
>>
>>> My non-Intel graphics notebook (has ATI X1400 graphics) also has a resume
>>> regression with 2.6.36.  But it does work fine with 2.6.35 (and earlier,
>>> back many years).  As a result, I'm stuck with 2.6.35 for the time being,
>>> and lack the time for a concerted debug effort on 2.6.36+ right now.
>>>
>>
>> Can you bisect?  Does this patch help?
>>
>> diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
>> index 8e421f6..05efb5b 100644
>> --- a/drivers/gpu/drm/radeon/atom.c
>> +++ b/drivers/gpu/drm/radeon/atom.c
>> @@ -112,6 +112,7 @@ static uint32_t atom_iio_execute(struct
>> atom_context *ctx, int base,
>>                         base += 3;
>>                         break;
>>                 case ATOM_IIO_WRITE:
>> +                       (void)ctx->card->ioreg_read(ctx->card, CU16(base +
>> 1));
>>                         ctx->card->ioreg_write(ctx->card, CU16(base + 1),
>> temp);
>>                         base += 3;
>>                         break;
>
> It now comes back at resume time.

So that patch helped?

>
> But suffers long delays (also sometimes with 2.6.35) doing this:
>
> [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs
> aborting
> [drm:atom_execute_table_locked] *ERROR* atombios stuck executing E576 (len
> 105, WS 12, PS 8) @ 0xE5C4
> [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs
> aborting
> [drm:atom_execute_table_locked] *ERROR* atombios stuck executing ECD2 (len
> 86, WS 4, PS 0) @ 0xED05
> [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs
> aborting
> [drm:atom_execute_table_locked] *ERROR* atombios stuck executing E576 (len
> 105, WS 12, PS 8) @ 0xE5C4
> PM: resume of devices complete after 15718.253 msecs
>

It's be nice if you could bisect to track down when those started.

> So I did this (local hack only, obviously NOT for mainline) to work around
> that issue:
>
> --- linux-2.6.36/drivers/gpu/drm/radeon/atom.c  2010-10-20
> 16:30:22.000000000 -0400
> +++ linux/drivers/gpu/drm/radeon/atom.c 2010-11-19 17:14:21.141807003 -0500
> @@ -1150,6 +1151,7 @@
>
>        if (!base)
>                return -EINVAL;
> +       if (base == 0xe576 || base == 0xecd2) return 0;  /* prevent freezes
> on Dell i9400 w/X1400 */
>
>        len = CU16(base + ATOM_CT_SIZE_PTR);
>        ws = CU8(base + ATOM_CT_WS_PTR);
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mark Lord - Nov. 19, 2010, 11:16 p.m.
On 10-11-19 05:58 PM, Alex Deucher wrote:
> On Fri, Nov 19, 2010 at 5:55 PM, Mark Lord<kernel@teksavvy.com>  wrote:
>
>> It now comes back at resume time.
>
> So that patch helped?

I think so.  It didn't used to resume from suspend with 2.6.36, and now it does.

>> But suffers long delays (also sometimes with 2.6.35) doing this:
>>
>> [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs
>> aborting
>> [drm:atom_execute_table_locked] *ERROR* atombios stuck executing E576 (len
>> 105, WS 12, PS 8) @ 0xE5C4
>> [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs
>> aborting
>> [drm:atom_execute_table_locked] *ERROR* atombios stuck executing ECD2 (len
>> 86, WS 4, PS 0) @ 0xED05
>> [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs
>> aborting
>> [drm:atom_execute_table_locked] *ERROR* atombios stuck executing E576 (len
>> 105, WS 12, PS 8) @ 0xE5C4
>> PM: resume of devices complete after 15718.253 msecs
>>
>
> It's be nice if you could bisect to track down when those started.

It'd be even nicer if they hadn't started.  :)

What kernel release first had that atom/ops table in it?  I'll try that.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Alex Deucher - Nov. 19, 2010, 11:17 p.m.
On Fri, Nov 19, 2010 at 6:16 PM, Mark Lord <kernel@teksavvy.com> wrote:
> On 10-11-19 05:58 PM, Alex Deucher wrote:
>>
>> On Fri, Nov 19, 2010 at 5:55 PM, Mark Lord<kernel@teksavvy.com>  wrote:
>>
>>> It now comes back at resume time.
>>
>> So that patch helped?
>
> I think so.  It didn't used to resume from suspend with 2.6.36, and now it
> does.
>
>>> But suffers long delays (also sometimes with 2.6.35) doing this:
>>>
>>> [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs
>>> aborting
>>> [drm:atom_execute_table_locked] *ERROR* atombios stuck executing E576
>>> (len
>>> 105, WS 12, PS 8) @ 0xE5C4
>>> [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs
>>> aborting
>>> [drm:atom_execute_table_locked] *ERROR* atombios stuck executing ECD2
>>> (len
>>> 86, WS 4, PS 0) @ 0xED05
>>> [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs
>>> aborting
>>> [drm:atom_execute_table_locked] *ERROR* atombios stuck executing E576
>>> (len
>>> 105, WS 12, PS 8) @ 0xE5C4
>>> PM: resume of devices complete after 15718.253 msecs
>>>
>>
>> It's be nice if you could bisect to track down when those started.
>
> It'd be even nicer if they hadn't started.  :)
>
> What kernel release first had that atom/ops table in it?  I'll try that.
>

2.6.31 or 32 was when radeon kms got merged IIRC.

Alex
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

--- linux-2.6.36/drivers/gpu/drm/radeon/atom.c  2010-10-20 16:30:22.000000000 -0400
+++ linux/drivers/gpu/drm/radeon/atom.c 2010-11-19 17:14:21.141807003 -0500
@@ -1150,6 +1151,7 @@ 

         if (!base)
                 return -EINVAL;
+       if (base == 0xe576 || base == 0xecd2) return 0;  /* prevent freezes on 
Dell i9400 w/X1400 */

         len = CU16(base + ATOM_CT_SIZE_PTR);