On Fri, Nov 19, 2010 at 6:16 PM, Mark Lord <kernel@xxxxxxxxxxxx> wrote: > On 10-11-19 05:58 PM, Alex Deucher wrote: >> >> On Fri, Nov 19, 2010 at 5:55 PM, Mark Lord<kernel@xxxxxxxxxxxx> 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 linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
