| Message ID | 4CE7006E.4040102@teksavvy.com |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | David Miller |
| Headers | show |
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
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
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
--- 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);