Hi,
after resuming from suspend nouveau starts writing Failed to idle
channel x (where x is 2 or 3) to the log and X appears to stop and then
restart only to stop again. Starting Firefox after resuming triggers the
bugs every time, and bisecting leads to 03bd6efa ("drm/nv50/fifo: use
hardware channel kickoff functionality").
$ grep -i nouveau .config
CONFIG_DRM_NOUVEAU=y
CONFIG_DRM_NOUVEAU_BACKLIGHT=y
# CONFIG_DRM_NOUVEAU_DEBUG is not set
Relevant part of the log (running v3.5-rc2-15-g4e3c8a1):
[ 79.040710] PM: resume of devices complete after 1952.375 msecs
[ 79.041735] PM: Finishing wakeup.
[ 79.064052] Restarting tasks ... done.
[ 79.064064] video LNXVIDEO:00: Restoring backlight state
[ 79.645442] tg3 0000:09:00.0: irq 47 for MSI/MSI-X
[ 79.707851] IPv6: ADDRCONF(NETDEV_UP): p3p1: link is not ready
[ 81.288510] tg3 0000:09:00.0: p3p1: Link is up at 100 Mbps, full duplex
[ 81.288510] tg3 0000:09:00.0: p3p1: Flow control is on for TX and on for RX
[ 81.289824] IPv6: ADDRCONF(NETDEV_CHANGE): p3p1: link becomes ready
[ 376.646417] [drm] nouveau 0000:01:00.0: PFIFO: channel 4 unload timeout
[ 378.649010] [sched_delayed] sched: RT throttling activated
[ 384.677024] [drm] nouveau 0000:01:00.0: Failed to idle channel 2.
[ 384.678012] [drm] nouveau 0000:01:00.0: PFIFO: channel 2 unload timeout
[ 389.685024] [drm] nouveau 0000:01:00.0: Failed to idle channel 3.
[ 389.686012] [drm] nouveau 0000:01:00.0: PFIFO: channel 3 unload timeout
[ 401.534024] [drm] nouveau 0000:01:00.0: Failed to idle channel 2.
[ 401.535012] [drm] nouveau 0000:01:00.0: PFIFO: channel 2 unload timeout
...
[ 456.688024] [drm] nouveau 0000:01:00.0: Failed to idle channel 3.
[ 456.689013] [drm] nouveau 0000:01:00.0: PFIFO: channel 3 unload timeout
[ 468.372025] [drm] nouveau 0000:01:00.0: Failed to idle channel 2.
[ 468.373013] [drm] nouveau 0000:01:00.0: PFIFO: channel 2 unload timeout
On Mon, 2012-07-23 at 18:25 +0300, Aioanei Rares wrote:
> On Thu, Jul 5, 2012 at 11:24 PM, Martin Nyhus <[email protected]> wrote:
> >
> > On Mon, 11 Jun 2012 23:18:42 +0200 Martin Nyhus wrote:
> > > after resuming from suspend nouveau starts writing Failed to idle
> > > channel x (where x is 2 or 3) to the log and X appears to stop and
> > > then restart only to stop again. Starting Firefox after resuming
> > > triggers the bugs every time, and bisecting leads to 03bd6efa
> > > ("drm/nv50/fifo: use hardware channel kickoff functionality").
> >
> > Hi Ben,
> > I'm still seeing this bug with the latest from Linus
> > (v3.5-rc5-98-g9e85a6f) and linux-next (next-20120705).
> >
> > lspci output:
> > 01:00.0 VGA compatible controller: nVidia Corporation G86 [GeForce
> > 8400M GS] (rev a1)
> >
> > Sorry I haven't followed up on this earlier,
> > Martin
>
> I can confirm this with 3.5.0, Chromium and Arch Linux. It's a HP
> Pavilion laptop with a G86 [GeForce 8400 M GS] video card .
> Seems related to this bug:
> http://lists.freedesktop.org/archives/nouveau/2011-January/007358.html
> . If I can do anything else
> to help, I will be glad to.
Added [email protected]>
I confirm the same issue here.
will try to do dig it.
Best regards,
Maxim Levitsky
On Sat, 2012-08-04 at 17:41 +0300, Maxim Levitsky wrote:
> On Mon, 2012-07-23 at 18:25 +0300, Aioanei Rares wrote:
> > On Thu, Jul 5, 2012 at 11:24 PM, Martin Nyhus <[email protected]> wrote:
> > >
> > > On Mon, 11 Jun 2012 23:18:42 +0200 Martin Nyhus wrote:
> > > > after resuming from suspend nouveau starts writing Failed to idle
> > > > channel x (where x is 2 or 3) to the log and X appears to stop and
> > > > then restart only to stop again. Starting Firefox after resuming
> > > > triggers the bugs every time, and bisecting leads to 03bd6efa
> > > > ("drm/nv50/fifo: use hardware channel kickoff functionality").
> > >
> > > Hi Ben,
> > > I'm still seeing this bug with the latest from Linus
> > > (v3.5-rc5-98-g9e85a6f) and linux-next (next-20120705).
> > >
> > > lspci output:
> > > 01:00.0 VGA compatible controller: nVidia Corporation G86 [GeForce
> > > 8400M GS] (rev a1)
> > >
> > > Sorry I haven't followed up on this earlier,
> > > Martin
> >
> > I can confirm this with 3.5.0, Chromium and Arch Linux. It's a HP
> > Pavilion laptop with a G86 [GeForce 8400 M GS] video card .
> > Seems related to this bug:
> > http://lists.freedesktop.org/archives/nouveau/2011-January/007358.html
> > . If I can do anything else
> > to help, I will be glad to.
> Added [email protected]>
>
> I confirm the same issue here.
> will try to do dig it.
Nope,can't dig this :-(
--
Best regards,
Maxim Levitsky
On Mon, Aug 06, 2012 at 11:38:04PM +0300, Maxim Levitsky wrote:
> On Sat, 2012-08-04 at 17:41 +0300, Maxim Levitsky wrote:
> > On Mon, 2012-07-23 at 18:25 +0300, Aioanei Rares wrote:
> > > On Thu, Jul 5, 2012 at 11:24 PM, Martin Nyhus <[email protected]> wrote:
> > > >
> > > > On Mon, 11 Jun 2012 23:18:42 +0200 Martin Nyhus wrote:
> > > > > after resuming from suspend nouveau starts writing Failed to idle
> > > > > channel x (where x is 2 or 3) to the log and X appears to stop and
> > > > > then restart only to stop again. Starting Firefox after resuming
> > > > > triggers the bugs every time, and bisecting leads to 03bd6efa
> > > > > ("drm/nv50/fifo: use hardware channel kickoff functionality").
> > > >
> > > > Hi Ben,
> > > > I'm still seeing this bug with the latest from Linus
> > > > (v3.5-rc5-98-g9e85a6f) and linux-next (next-20120705).
> > > >
> > > > lspci output:
> > > > 01:00.0 VGA compatible controller: nVidia Corporation G86 [GeForce
> > > > 8400M GS] (rev a1)
> > > >
> > > > Sorry I haven't followed up on this earlier,
> > > > Martin
> > >
> > > I can confirm this with 3.5.0, Chromium and Arch Linux. It's a HP
> > > Pavilion laptop with a G86 [GeForce 8400 M GS] video card .
> > > Seems related to this bug:
> > > http://lists.freedesktop.org/archives/nouveau/2011-January/007358.html
> > > . If I can do anything else
> > > to help, I will be glad to.
> > Added [email protected]>
> >
> > I confirm the same issue here.
> > will try to do dig it.
> Nope,can't dig this :-(
Interestingly, this works just fine for me after the driver rework.
I can confirm issues on G86 with 3.5/3.6-rc1 stock though. I'll
attempt to find a fix suitable for the non-reworked driver.
Ben.
>
>
>
> --
> Best regards,
> Maxim Levitsky
>
>
>
> _______________________________________________
> dri-devel mailing list
> [email protected]
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
On 2012-08-08 07:37 +0200, Ben Skeggs wrote:
> On Mon, Aug 06, 2012 at 11:38:04PM +0300, Maxim Levitsky wrote:
>> On Sat, 2012-08-04 at 17:41 +0300, Maxim Levitsky wrote:
>> > On Mon, 2012-07-23 at 18:25 +0300, Aioanei Rares wrote:
>> > > On Thu, Jul 5, 2012 at 11:24 PM, Martin Nyhus <[email protected]> wrote:
>> > > >
>> > > > On Mon, 11 Jun 2012 23:18:42 +0200 Martin Nyhus wrote:
>> > > > > after resuming from suspend nouveau starts writing Failed to idle
>> > > > > channel x (where x is 2 or 3) to the log and X appears to stop and
>> > > > > then restart only to stop again. Starting Firefox after resuming
>> > > > > triggers the bugs every time, and bisecting leads to 03bd6efa
>> > > > > ("drm/nv50/fifo: use hardware channel kickoff functionality").
>> > > >
>> > > > Hi Ben,
>> > > > I'm still seeing this bug with the latest from Linus
>> > > > (v3.5-rc5-98-g9e85a6f) and linux-next (next-20120705).
>> > > >
>> > > > lspci output:
>> > > > 01:00.0 VGA compatible controller: nVidia Corporation G86 [GeForce
>> > > > 8400M GS] (rev a1)
>> > > >
>> > > > Sorry I haven't followed up on this earlier,
>> > > > Martin
>> > >
>> > > I can confirm this with 3.5.0, Chromium and Arch Linux. It's a HP
>> > > Pavilion laptop with a G86 [GeForce 8400 M GS] video card .
>> > > Seems related to this bug:
>> > > http://lists.freedesktop.org/archives/nouveau/2011-January/007358.html
>> > > . If I can do anything else
>> > > to help, I will be glad to.
>> > Added [email protected]>
>> >
>> > I confirm the same issue here.
>> > will try to do dig it.
>> Nope,can't dig this :-(
> Interestingly, this works just fine for me after the driver rework.
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][0000:01:00.0][0x0200502d][ffff880037be1d40] parent failed suspend, -16
| Aug 8 07:49:16 turtle kernel: [ 91.697078] nouveau [ DRM][0000:01:00.0] resuming display...
`----
> I can confirm issues on G86 with 3.5/3.6-rc1 stock though. I'll
> attempt to find a fix suitable for the non-reworked driver.
Thanks. I'm currently stuck on 3.4 because of this problem.
Cheers,
Sven
On Wed, Aug 08, 2012 at 08:00:21AM +0200, Sven Joachim wrote:
> On 2012-08-08 07:37 +0200, Ben Skeggs wrote:
>
> > On Mon, Aug 06, 2012 at 11:38:04PM +0300, Maxim Levitsky wrote:
> >> On Sat, 2012-08-04 at 17:41 +0300, Maxim Levitsky wrote:
> >> > On Mon, 2012-07-23 at 18:25 +0300, Aioanei Rares wrote:
> >> > > On Thu, Jul 5, 2012 at 11:24 PM, Martin Nyhus <[email protected]> wrote:
> >> > > >
> >> > > > On Mon, 11 Jun 2012 23:18:42 +0200 Martin Nyhus wrote:
> >> > > > > after resuming from suspend nouveau starts writing Failed to idle
> >> > > > > channel x (where x is 2 or 3) to the log and X appears to stop and
> >> > > > > then restart only to stop again. Starting Firefox after resuming
> >> > > > > triggers the bugs every time, and bisecting leads to 03bd6efa
> >> > > > > ("drm/nv50/fifo: use hardware channel kickoff functionality").
> >> > > >
> >> > > > Hi Ben,
> >> > > > I'm still seeing this bug with the latest from Linus
> >> > > > (v3.5-rc5-98-g9e85a6f) and linux-next (next-20120705).
> >> > > >
> >> > > > lspci output:
> >> > > > 01:00.0 VGA compatible controller: nVidia Corporation G86 [GeForce
> >> > > > 8400M GS] (rev a1)
> >> > > >
> >> > > > Sorry I haven't followed up on this earlier,
> >> > > > Martin
> >> > >
> >> > > I can confirm this with 3.5.0, Chromium and Arch Linux. It's a HP
> >> > > Pavilion laptop with a G86 [GeForce 8400 M GS] video card .
> >> > > Seems related to this bug:
> >> > > http://lists.freedesktop.org/archives/nouveau/2011-January/007358.html
> >> > > . If I can do anything else
> >> > > to help, I will be glad to.
> >> > Added [email protected]>
> >> >
> >> > I confirm the same issue here.
> >> > will try to do dig it.
> >> Nope,can't dig this :-(
> > Interestingly, this works just fine for me after the driver rework.
>
> 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][0000:01:00.0][0x0200502d][ffff880037be1d40] parent failed suspend, -16
> | Aug 8 07:49:16 turtle kernel: [ 91.697078] nouveau [ DRM][0000:01:00.0] resuming display...
> `----
Interesting. Were there any messages prior to that? 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.
>
> > I can confirm issues on G86 with 3.5/3.6-rc1 stock though. I'll
> > attempt to find a fix suitable for the non-reworked driver.
>
> Thanks. I'm currently stuck on 3.4 because of this problem.
Sorry about that!
Ben.
>
> Cheers,
> Sven
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][0000:01:00.0][0x0200502d][ffff880037be1d40] parent failed
>> | suspend, -16
>> | Aug 8 07:49:16 turtle kernel: [ 91.697078] nouveau [ DRM][0000: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][0000:01:00.0] suspending fbcon...
| Aug 8 07:49:16 turtle kernel: [ 89.655367] nouveau [ DRM][0000:01:00.0] suspending display...
| Aug 8 07:49:16 turtle kernel: [ 89.696888] nouveau [ DRM][0000:01:00.0] unpinning framebuffer(s)...
| Aug 8 07:49:16 turtle kernel: [ 89.696909] nouveau [ DRM][0000:01:00.0] evicting buffers...
| Aug 8 07:49:16 turtle kernel: [ 89.696913] nouveau [ DRM][0000: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.
Cheers,
Sven
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][0000:01:00.0][0x0200502d][ffff880037be1d40] parent failed
>>> | suspend, -16
>>> | Aug 8 07:49:16 turtle kernel: [ 91.697078] nouveau [ DRM][0000: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][0000:01:00.0] suspending fbcon...
> | Aug 8 07:49:16 turtle kernel: [ 89.655367] nouveau [ DRM][0000:01:00.0] suspending display...
> | Aug 8 07:49:16 turtle kernel: [ 89.696888] nouveau [ DRM][0000:01:00.0] unpinning framebuffer(s)...
> | Aug 8 07:49:16 turtle kernel: [ 89.696909] nouveau [ DRM][0000:01:00.0] evicting buffers...
> | Aug 8 07:49:16 turtle kernel: [ 89.696913] nouveau [ DRM][0000: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][0000:01:00.0] suspending fbcon...
| Aug 13 18:18:09 turtle kernel: [ 678.695239] nouveau [ DRM][0000:01:00.0] suspending display...
| Aug 13 18:18:09 turtle kernel: [ 678.742111] nouveau [ DRM][0000:01:00.0] unpinning framebuffer(s)...
| Aug 13 18:18:09 turtle kernel: [ 678.742189] nouveau [ DRM][0000:01:00.0] evicting buffers...
| Aug 13 18:18:09 turtle kernel: [ 682.357319] nouveau [ DRM][0000: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
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][0000:01:00.0][0x0200502d][ffff880037be1d40] parent failed
> >>> | suspend, -16
> >>> | Aug 8 07:49:16 turtle kernel: [ 91.697078] nouveau [ DRM][0000: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][0000:01:00.0] suspending fbcon...
> > | Aug 8 07:49:16 turtle kernel: [ 89.655367] nouveau [ DRM][0000:01:00.0] suspending display...
> > | Aug 8 07:49:16 turtle kernel: [ 89.696888] nouveau [ DRM][0000:01:00.0] unpinning framebuffer(s)...
> > | Aug 8 07:49:16 turtle kernel: [ 89.696909] nouveau [ DRM][0000:01:00.0] evicting buffers...
> > | Aug 8 07:49:16 turtle kernel: [ 89.696913] nouveau [ DRM][0000: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][0000:01:00.0] suspending fbcon...
> | Aug 13 18:18:09 turtle kernel: [ 678.695239] nouveau [ DRM][0000:01:00.0] suspending display...
> | Aug 13 18:18:09 turtle kernel: [ 678.742111] nouveau [ DRM][0000:01:00.0] unpinning framebuffer(s)...
> | Aug 13 18:18:09 turtle kernel: [ 678.742189] nouveau [ DRM][0000:01:00.0] evicting buffers...
> | Aug 13 18:18:09 turtle kernel: [ 682.357319] nouveau [ DRM][0000: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][0000:01:00.0] suspending fbcon...
[ 2165.363885] nouveau [ DRM][0000:01:00.0] suspending display...
[ 2165.475791] sd 0:0:0:0: [sda] Stopping disk
[ 2166.396877] nouveau [ DRM][0000:01:00.0] unpinning
framebuffer(s)...
[ 2166.396926] nouveau [ DRM][0000:01:00.0] evicting buffers...
[ 2174.809084] nouveau [ DRM][0000:01:00.0] suspending client
object trees...
[ 2177.950222] nouveau 0000:01:00.0: power state changed by ACPI to D3
Best regards,
Maxim Levitsky
On Mon, Aug 13, 2012 at 9:49 PM, Maxim Levitsky <[email protected]> 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][0000:01:00.0][0x0200502d][ffff880037be1d40] parent failed
>> >>> | suspend, -16
>> >>> | Aug 8 07:49:16 turtle kernel: [ 91.697078] nouveau [ DRM][0000: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][0000:01:00.0] suspending fbcon...
>> > | Aug 8 07:49:16 turtle kernel: [ 89.655367] nouveau [ DRM][0000:01:00.0] suspending display...
>> > | Aug 8 07:49:16 turtle kernel: [ 89.696888] nouveau [ DRM][0000:01:00.0] unpinning framebuffer(s)...
>> > | Aug 8 07:49:16 turtle kernel: [ 89.696909] nouveau [ DRM][0000:01:00.0] evicting buffers...
>> > | Aug 8 07:49:16 turtle kernel: [ 89.696913] nouveau [ DRM][0000: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][0000:01:00.0] suspending fbcon...
>> | Aug 13 18:18:09 turtle kernel: [ 678.695239] nouveau [ DRM][0000:01:00.0] suspending display...
>> | Aug 13 18:18:09 turtle kernel: [ 678.742111] nouveau [ DRM][0000:01:00.0] unpinning framebuffer(s)...
>> | Aug 13 18:18:09 turtle kernel: [ 678.742189] nouveau [ DRM][0000:01:00.0] evicting buffers...
>> | Aug 13 18:18:09 turtle kernel: [ 682.357319] nouveau [ DRM][0000: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][0000:01:00.0] suspending fbcon...
> [ 2165.363885] nouveau [ DRM][0000:01:00.0] suspending display...
> [ 2165.475791] sd 0:0:0:0: [sda] Stopping disk
> [ 2166.396877] nouveau [ DRM][0000:01:00.0] unpinning
> framebuffer(s)...
> [ 2166.396926] nouveau [ DRM][0000:01:00.0] evicting buffers...
> [ 2174.809084] nouveau [ DRM][0000:01:00.0] suspending client
> object trees...
> [ 2177.950222] nouveau 0000:01:00.0: power state changed by ACPI to D3
>
>
> Best regards,
> Maxim Levitsky
>
> _______________________________________________
> Nouveau mailing list
> [email protected]
> 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.