Re: suspend/resume regression

[Andriy Gapon]

On 17/05/2018 21:14, Pete Wright wrote:
> 
> 
> On 05/12/2018 19:25, Pete Wright wrote:
>> hi there - i have an amd64 laptop that's been running CURRENT for a while
>> using both drm-next and drm-stable for graphics. during the past week or so
>> i've run into issues with suspend resume...well technically resume has 
>> stopped
>> working.  i've tested a couple configurations and none have allowed my system
>> to resume successfully:
>>
>> - drm-next installed with DMC firmware loaded
>> - drm-next installed without DMC firmware loaded (worked previously)
>> - drm-stable with DMC
>> - drm-stable without DMC
>> - no drm modules loaded.
>>
>> I've also tested these configs with the following sysctl set to 0 and 1:
>> hw.acpi.reset_video
>>
>> at this point i'd like to help find what the regression i'm running into is,
>> so any pointers on how i can help? the system seems to boot and i'm pretty
>> sure i can ssh into it most times, just not sure what info i should grab to
>> help.  nothing of interest in messages or dmesg buffer either.
>>
> 
> Closing the loop on this thread.  Git commit
> 4e99d4e797ba9cea01897b6909b061db841f855a fixes this issue on my end.  For more
> info there is a thread on this list named "Lag after resume culprit found" 
> that
> has details.

Thank you for confirming that it was the same issue and that (or, rather,
because) it's fixed now.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: suspend/resume regression

[Pete Wright]

On 05/12/2018 19:25, Pete Wright wrote:
hi there - i have an amd64 laptop that's been running CURRENT for a 
while using both drm-next and drm-stable for graphics. during the past 
week or so i've run into issues with suspend resume...well technically 
resume has stopped working.  i've tested a couple configurations and 
none have allowed my system to resume successfully:


- drm-next installed with DMC firmware loaded
- drm-next installed without DMC firmware loaded (worked previously)
- drm-stable with DMC
- drm-stable without DMC
- no drm modules loaded.

I've also tested these configs with the following sysctl set to 0 and 1:
hw.acpi.reset_video

at this point i'd like to help find what the regression i'm running 
into is, so any pointers on how i can help? the system seems to boot 
and i'm pretty sure i can ssh into it most times, just not sure what 
info i should grab to help.  nothing of interest in messages or dmesg 
buffer either.




Closing the loop on this thread.  Git commit 
4e99d4e797ba9cea01897b6909b061db841f855a fixes this issue on my end.  
For more info there is a thread on this list named "Lag after resume 
culprit found" that has details.


-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: suspend/resume regression

[Niclas Zeising]

On 05/15/18 16:48, Pete Wright wrote:



On 05/14/2018 20:35, Theron wrote:

On 05/13/18 15:44, Pete Wright wrote:
so i've done a bit more debugging on my end.  i've even installed 
the 11.2-BETA branch last night since 11-STABLE worked without 
issues about a month or so ago.


i've set "debug.acpi.resume_beep=1" and when resuming after entering 
an S3 sleep state the bell rings and does not stop until i do a hard 
reset (both with i915kms loaded and unloaded).


kinda at a loss as to how this could break both CURRENT and 
basically 11-STABLE.  i'm going to make a ubuntu live image and test 
that, my laptop is a System76 laptop that shipped with ubuntu 
originally.  if that is broken as well then i guess this could be a 
hardware issue.


ubuntu live image suspends/resumes without issue so this certainly 
seems to be a freebsd issue unfortunately.  i guess next step is to 
attempt to find a working CURRENT snapshot that does suspend/resume 
without issue then start looking at commits?


-pete

Returning to the original issue: complete failure to resume, rather 
than slowness: I am affected as well.  CURRENT r333093 worked, but 
r333582 fails in a manner consistent with what Pete has described, 
with or without drm loaded.  There have been a few commit messages 
mentioning ACPI in that window of history, which I will use to help me 
bisect when I have time.




do you think it may be due to r333150

"Merge ACPICA 20180427."

not sure if that's been merged into 11-STABLE, but it seems to touch a 
lot of bits that could effect suspend/resume.




I tried to revert that, but if I remember correctly, it didn't matter. 
I have to do a new test though, when I have more time.

Regards
--
Niclas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: suspend/resume regression

[Pete Wright]

On 05/14/2018 20:35, Theron wrote:

On 05/13/18 15:44, Pete Wright wrote:
so i've done a bit more debugging on my end.  i've even installed 
the 11.2-BETA branch last night since 11-STABLE worked without 
issues about a month or so ago.


i've set "debug.acpi.resume_beep=1" and when resuming after entering 
an S3 sleep state the bell rings and does not stop until i do a hard 
reset (both with i915kms loaded and unloaded).


kinda at a loss as to how this could break both CURRENT and 
basically 11-STABLE.  i'm going to make a ubuntu live image and test 
that, my laptop is a System76 laptop that shipped with ubuntu 
originally.  if that is broken as well then i guess this could be a 
hardware issue.


ubuntu live image suspends/resumes without issue so this certainly 
seems to be a freebsd issue unfortunately.  i guess next step is to 
attempt to find a working CURRENT snapshot that does suspend/resume 
without issue then start looking at commits?


-pete

Returning to the original issue: complete failure to resume, rather 
than slowness: I am affected as well.  CURRENT r333093 worked, but 
r333582 fails in a manner consistent with what Pete has described, 
with or without drm loaded.  There have been a few commit messages 
mentioning ACPI in that window of history, which I will use to help me 
bisect when I have time.




do you think it may be due to r333150

"Merge ACPICA 20180427."

not sure if that's been merged into 11-STABLE, but it seems to touch a 
lot of bits that could effect suspend/resume.


-p

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: suspend/resume regression

[Edward Tomasz Napierała]

On 0514T1158, Andriy Gapon wrote:
> On 14/05/2018 11:44, Mikaël Urankar wrote:
> > Could it be the same problem described here?
> > https://lists.freebsd.org/pipermail/freebsd-hackers/2018-May/052778.html
> 
> That problem is _not_ a regression.

FWIW, this machine (the one affected by the sluggishness) uses TSC-low
by default, not HPET.  Changing the kern.timecounter.hardware to eg HPET
or ACPI-fast doesn't change the symptoms.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: suspend/resume regression

[Theron]

On 05/13/18 15:44, Pete Wright wrote:
so i've done a bit more debugging on my end.  i've even installed the 
11.2-BETA branch last night since 11-STABLE worked without issues 
about a month or so ago.


i've set "debug.acpi.resume_beep=1" and when resuming after entering 
an S3 sleep state the bell rings and does not stop until i do a hard 
reset (both with i915kms loaded and unloaded).


kinda at a loss as to how this could break both CURRENT and basically 
11-STABLE.  i'm going to make a ubuntu live image and test that, my 
laptop is a System76 laptop that shipped with ubuntu originally.  if 
that is broken as well then i guess this could be a hardware issue.


ubuntu live image suspends/resumes without issue so this certainly 
seems to be a freebsd issue unfortunately.  i guess next step is to 
attempt to find a working CURRENT snapshot that does suspend/resume 
without issue then start looking at commits?


-pete

Returning to the original issue: complete failure to resume, rather than 
slowness: I am affected as well.  CURRENT r333093 worked, but r333582 
fails in a manner consistent with what Pete has described, with or 
without drm loaded.  There have been a few commit messages mentioning 
ACPI in that window of history, which I will use to help me bisect when 
I have time.


Theron
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: suspend/resume regression

[Pete Wright]

On 05/14/2018 01:18, Niclas Zeising wrote:

On 05/13/18 21:44, Pete Wright wrote:



On 05/13/2018 10:27, Pete Wright wrote:



On 05/13/2018 08:58, Theron wrote:

Hi!
I'm also seeing issues, not as severe as Pete, but after I resume 
(which works, with drm-next and DMC firmware), the system becomes 
sluggish.  It feels like I/O takes more time, and graphics are 
sluggish (very sientific, I know, but for instance git operations 
are much slower after a resume).  I know there's been an update to 
acpica between my system updates, when this started to happen, but 
I haven't had time to revert that update and test again.  I will 
try to do that and report back.

Regards

Hi Niclas,
I used drm-next on Skylake with issues which sound similar. 
Resuming from suspend, or simply switching the laptop display 
output off and on from xrandr, resulted in graphics sluggishness 
(drop to 30fps in glxgears) and graphical corruption in Xorg apps, 
which persisted even after restarting these apps. Switching to 
drm-stable made the problems go away; I haven't had time to figure 
out what -next is doing differently to cause them.


Pete's issue sounds more severe, and unrelated as it happens 
without drm loaded.  My kernel is two weeks out of date (r333093), 
so I need to check whether the more recent changes affect my system 
as well.


so i've done a bit more debugging on my end.  i've even installed 
the 11.2-BETA branch last night since 11-STABLE worked without 
issues about a month or so ago.


i've set "debug.acpi.resume_beep=1" and when resuming after entering 
an S3 sleep state the bell rings and does not stop until i do a hard 
reset (both with i915kms loaded and unloaded).


kinda at a loss as to how this could break both CURRENT and 
basically 11-STABLE.  i'm going to make a ubuntu live image and test 
that, my laptop is a System76 laptop that shipped with ubuntu 
originally.  if that is broken as well then i guess this could be a 
hardware issue.


ubuntu live image suspends/resumes without issue so this certainly 
seems to be a freebsd issue unfortunately.  i guess next step is to 
attempt to find a working CURRENT snapshot that does suspend/resume 
without issue then start looking at commits?




Hi!
It's a bit worrisome that your regression occurs both on CURRENT and 
STABLE.  There was an update to both drm-next-kmod and drm-stable-kmod 
last week, but both are very minor.  One question, did you install 
from pkg or compile from ports?


i create a package directly from the github mirror of the ports tree 
(i.e. make package; pkg install...).


-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: suspend/resume regression

[Andriy Gapon]

On 14/05/2018 11:44, Mikaël Urankar wrote:
> Could it be the same problem described here?
> https://lists.freebsd.org/pipermail/freebsd-hackers/2018-May/052778.html

That problem is _not_ a regression.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: suspend/resume regression

[Mikaël Urankar]

2018-05-14 10:27 GMT+02:00 Niclas Zeising :

> On 05/14/18 10:06, Edward Tomasz Napierała wrote:
>
>> On 0513T1244, Pete Wright wrote:
>>
>>>
>>>
>>> On 05/13/2018 10:27, Pete Wright wrote:
>>>


 On 05/13/2018 08:58, Theron wrote:

> Hi!
>> I'm also seeing issues, not as severe as Pete, but after I resume
>> (which works, with drm-next and DMC firmware), the system becomes
>> sluggish.  It feels like I/O takes more time, and graphics are
>> sluggish (very sientific, I know, but for instance git operations
>> are much slower after a resume).  I know there's been an update to
>> acpica between my system updates, when this started to happen, but I
>> haven't had time to revert that update and test again.  I will try
>> to do that and report back.
>> Regards
>>
> Hi Niclas,
> I used drm-next on Skylake with issues which sound similar. Resuming
> from suspend, or simply switching the laptop display output off and
> on from xrandr, resulted in graphics sluggishness (drop to 30fps in
> glxgears) and graphical corruption in Xorg apps, which persisted even
> after restarting these apps. Switching to drm-stable made the
> problems go away; I haven't had time to figure out what -next is
> doing differently to cause them.
>
> Pete's issue sounds more severe, and unrelated as it happens without
> drm loaded.  My kernel is two weeks out of date (r333093), so I need
> to check whether the more recent changes affect my system as well.
>
> so i've done a bit more debugging on my end.  i've even installed the
 11.2-BETA branch last night since 11-STABLE worked without issues
 about a month or so ago.

 i've set "debug.acpi.resume_beep=1" and when resuming after entering
 an S3 sleep state the bell rings and does not stop until i do a hard
 reset (both with i915kms loaded and unloaded).

 kinda at a loss as to how this could break both CURRENT and basically
 11-STABLE.  i'm going to make a ubuntu live image and test that, my
 laptop is a System76 laptop that shipped with ubuntu originally.  if
 that is broken as well then i guess this could be a hardware issue.

 ubuntu live image suspends/resumes without issue so this certainly seems
>>> to be a freebsd issue unfortunately.  i guess next step is to attempt to
>>> find a working CURRENT snapshot that does suspend/resume without issue
>>> then start looking at commits?
>>>
>>
>> FWIW, I'm seeing the same - sluggishness after resume - with stock
>> 12-CURRENT, without drm-next, just vanilla i915kms.ko, on T420.
>>
>> TBH I'm not entirely sure it's X11 problem - as I'm writing it now,
>> under vt(4), it seems somewhat slow too.
>>
>>
> It's not impossible that there are two different regressions, one causing
> sluggishness and one causing graphics corruption, or that they are
> intertwined. I have a Kaby Lake system which I run these tests on. I also
> have a window where the regression seem to have happened. r333269 to
> r40, so once I have time I'll start bisecting.
>
> Hopefully I can test on older systems as well.


Could it be the same problem described here?
https://lists.freebsd.org/pipermail/freebsd-hackers/2018-May/052778.html
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: suspend/resume regression

[Niclas Zeising]

On 05/14/18 10:06, Edward Tomasz Napierała wrote:

On 0513T1244, Pete Wright wrote:



On 05/13/2018 10:27, Pete Wright wrote:



On 05/13/2018 08:58, Theron wrote:

Hi!
I'm also seeing issues, not as severe as Pete, but after I resume
(which works, with drm-next and DMC firmware), the system becomes
sluggish.  It feels like I/O takes more time, and graphics are
sluggish (very sientific, I know, but for instance git operations
are much slower after a resume).  I know there's been an update to
acpica between my system updates, when this started to happen, but I
haven't had time to revert that update and test again.  I will try
to do that and report back.
Regards

Hi Niclas,
I used drm-next on Skylake with issues which sound similar. Resuming
from suspend, or simply switching the laptop display output off and
on from xrandr, resulted in graphics sluggishness (drop to 30fps in
glxgears) and graphical corruption in Xorg apps, which persisted even
after restarting these apps. Switching to drm-stable made the
problems go away; I haven't had time to figure out what -next is
doing differently to cause them.

Pete's issue sounds more severe, and unrelated as it happens without
drm loaded.  My kernel is two weeks out of date (r333093), so I need
to check whether the more recent changes affect my system as well.


so i've done a bit more debugging on my end.  i've even installed the
11.2-BETA branch last night since 11-STABLE worked without issues
about a month or so ago.

i've set "debug.acpi.resume_beep=1" and when resuming after entering
an S3 sleep state the bell rings and does not stop until i do a hard
reset (both with i915kms loaded and unloaded).

kinda at a loss as to how this could break both CURRENT and basically
11-STABLE.  i'm going to make a ubuntu live image and test that, my
laptop is a System76 laptop that shipped with ubuntu originally.  if
that is broken as well then i guess this could be a hardware issue.


ubuntu live image suspends/resumes without issue so this certainly seems
to be a freebsd issue unfortunately.  i guess next step is to attempt to
find a working CURRENT snapshot that does suspend/resume without issue
then start looking at commits?


FWIW, I'm seeing the same - sluggishness after resume - with stock
12-CURRENT, without drm-next, just vanilla i915kms.ko, on T420.

TBH I'm not entirely sure it's X11 problem - as I'm writing it now,
under vt(4), it seems somewhat slow too.



It's not impossible that there are two different regressions, one 
causing sluggishness and one causing graphics corruption, or that they 
are intertwined. I have a Kaby Lake system which I run these tests on. 
I also have a window where the regression seem to have happened. 
r333269 to r40, so once I have time I'll start bisecting.


Hopefully I can test on older systems as well.
Regards
--
Niclas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: suspend/resume regression

[Niclas Zeising]

On 05/13/18 17:58, Theron wrote:

Hi!
I'm also seeing issues, not as severe as Pete, but after I resume 
(which works, with drm-next and DMC firmware), the system becomes 
sluggish.  It feels like I/O takes more time, and graphics are 
sluggish (very sientific, I know, but for instance git operations are 
much slower after a resume).  I know there's been an update to acpica 
between my system updates, when this started to happen, but I haven't 
had time to revert that update and test again.  I will try to do that 
and report back.

Regards

Hi Niclas,
I used drm-next on Skylake with issues which sound similar. Resuming 
from suspend, or simply switching the laptop display output off and on 
from xrandr, resulted in graphics sluggishness (drop to 30fps in 
glxgears) and graphical corruption in Xorg apps, which persisted even 
after restarting these apps.  Switching to drm-stable made the problems 
go away; I haven't had time to figure out what -next is doing 
differently to cause them.


Pete's issue sounds more severe, and unrelated as it happens without drm 
loaded.  My kernel is two weeks out of date (r333093), so I need to 
check whether the more recent changes affect my system as well.




I have a Kaby Lake system.  I haven't tried switching outputs with 
xrandr, I have to do that as well.  What versions of drm-next and 
drm-stable have you tested?

Regards
--
Niclas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: suspend/resume regression

[Niclas Zeising]

On 05/13/18 18:16, Michael Gmelin wrote:




On 13. May 2018, at 11:54, Niclas Zeising  wrote:


On 05/13/18 09:48, Andriy Gapon wrote:

On 13/05/2018 05:25, Pete Wright wrote:
hi there - i have an amd64 laptop that's been running CURRENT for a while using
both drm-next and drm-stable for graphics. during the past week or so i've run
into issues with suspend resume...well technically resume has stopped working.
i've tested a couple configurations and none have allowed my system to resume
successfully:

- drm-next installed with DMC firmware loaded
- drm-next installed without DMC firmware loaded (worked previously)
- drm-stable with DMC
- drm-stable without DMC
- no drm modules loaded.

I've also tested these configs with the following sysctl set to 0 and 1:
hw.acpi.reset_video

at this point i'd like to help find what the regression i'm running into is, so
any pointers on how i can help? the system seems to boot and i'm pretty sure i
can ssh into it most times, just not sure what info i should grab to help.
nothing of interest in messages or dmesg buffer either.

Did you do any OS upgrades what was last working version and what is the current
version (svn revision number)?
Or any other notable changes before resume stopped working...


Hi!
I'm also seeing issues, not as severe as Pete, but after I resume (which works, 
with drm-next and DMC firmware), the system becomes sluggish.  It feels like 
I/O takes more time, and graphics are sluggish (very sientific, I know, but for 
instance git operations are much slower after a resume).  I know there's been 
an update to acpica between my system updates, when this started to happen, but 
I haven't had time to revert that update and test again.  I will try to do that 
and report back.


Maybe a stupid question, but did you check the cpu frequency before and after 
suspend/resume? (sysctl dev.cpu)


As far as I can tell, the frequency remains the same.  I looked at 
dev.cpu.0.freq, if there's any other sysctl to look at as well, please 
let me know.

Regards
--
Niclas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: suspend/resume regression

[Niclas Zeising]

On 05/13/18 21:44, Pete Wright wrote:



On 05/13/2018 10:27, Pete Wright wrote:



On 05/13/2018 08:58, Theron wrote:

Hi!
I'm also seeing issues, not as severe as Pete, but after I resume 
(which works, with drm-next and DMC firmware), the system becomes 
sluggish.  It feels like I/O takes more time, and graphics are 
sluggish (very sientific, I know, but for instance git operations 
are much slower after a resume).  I know there's been an update to 
acpica between my system updates, when this started to happen, but I 
haven't had time to revert that update and test again.  I will try 
to do that and report back.

Regards

Hi Niclas,
I used drm-next on Skylake with issues which sound similar. Resuming 
from suspend, or simply switching the laptop display output off and 
on from xrandr, resulted in graphics sluggishness (drop to 30fps in 
glxgears) and graphical corruption in Xorg apps, which persisted even 
after restarting these apps. Switching to drm-stable made the 
problems go away; I haven't had time to figure out what -next is 
doing differently to cause them.


Pete's issue sounds more severe, and unrelated as it happens without 
drm loaded.  My kernel is two weeks out of date (r333093), so I need 
to check whether the more recent changes affect my system as well.


so i've done a bit more debugging on my end.  i've even installed the 
11.2-BETA branch last night since 11-STABLE worked without issues 
about a month or so ago.


i've set "debug.acpi.resume_beep=1" and when resuming after entering 
an S3 sleep state the bell rings and does not stop until i do a hard 
reset (both with i915kms loaded and unloaded).


kinda at a loss as to how this could break both CURRENT and basically 
11-STABLE.  i'm going to make a ubuntu live image and test that, my 
laptop is a System76 laptop that shipped with ubuntu originally.  if 
that is broken as well then i guess this could be a hardware issue.


ubuntu live image suspends/resumes without issue so this certainly seems 
to be a freebsd issue unfortunately.  i guess next step is to attempt to 
find a working CURRENT snapshot that does suspend/resume without issue 
then start looking at commits?




Hi!
It's a bit worrisome that your regression occurs both on CURRENT and 
STABLE.  There was an update to both drm-next-kmod and drm-stable-kmod 
last week, but both are very minor.  One question, did you install from 
pkg or compile from ports?


Wrt. my own issues, I'm not entirely sure what's going on.  I tried a 
kernel from r333269 and that worked fine, however, r40 did not. 
I'll need to bisect exactly which revision causes my regression, with 
slowness and lag after resume from sleep.


Regards
--
Niclas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: suspend/resume regression

[Edward Tomasz Napierała]

On 0513T1244, Pete Wright wrote:
> 
> 
> On 05/13/2018 10:27, Pete Wright wrote:
> >
> >
> > On 05/13/2018 08:58, Theron wrote:
> >>> Hi!
> >>> I'm also seeing issues, not as severe as Pete, but after I resume 
> >>> (which works, with drm-next and DMC firmware), the system becomes 
> >>> sluggish.  It feels like I/O takes more time, and graphics are 
> >>> sluggish (very sientific, I know, but for instance git operations 
> >>> are much slower after a resume).  I know there's been an update to 
> >>> acpica between my system updates, when this started to happen, but I 
> >>> haven't had time to revert that update and test again.  I will try 
> >>> to do that and report back.
> >>> Regards
> >> Hi Niclas,
> >> I used drm-next on Skylake with issues which sound similar. Resuming 
> >> from suspend, or simply switching the laptop display output off and 
> >> on from xrandr, resulted in graphics sluggishness (drop to 30fps in 
> >> glxgears) and graphical corruption in Xorg apps, which persisted even 
> >> after restarting these apps. Switching to drm-stable made the 
> >> problems go away; I haven't had time to figure out what -next is 
> >> doing differently to cause them.
> >>
> >> Pete's issue sounds more severe, and unrelated as it happens without 
> >> drm loaded.  My kernel is two weeks out of date (r333093), so I need 
> >> to check whether the more recent changes affect my system as well.
> >>
> > so i've done a bit more debugging on my end.  i've even installed the 
> > 11.2-BETA branch last night since 11-STABLE worked without issues 
> > about a month or so ago.
> >
> > i've set "debug.acpi.resume_beep=1" and when resuming after entering 
> > an S3 sleep state the bell rings and does not stop until i do a hard 
> > reset (both with i915kms loaded and unloaded).
> >
> > kinda at a loss as to how this could break both CURRENT and basically 
> > 11-STABLE.  i'm going to make a ubuntu live image and test that, my 
> > laptop is a System76 laptop that shipped with ubuntu originally.  if 
> > that is broken as well then i guess this could be a hardware issue.
> >
> ubuntu live image suspends/resumes without issue so this certainly seems 
> to be a freebsd issue unfortunately.  i guess next step is to attempt to 
> find a working CURRENT snapshot that does suspend/resume without issue 
> then start looking at commits?

FWIW, I'm seeing the same - sluggishness after resume - with stock
12-CURRENT, without drm-next, just vanilla i915kms.ko, on T420.

TBH I'm not entirely sure it's X11 problem - as I'm writing it now,
under vt(4), it seems somewhat slow too.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: suspend/resume regression

[Pete Wright]

On 05/13/2018 10:27, Pete Wright wrote:



On 05/13/2018 08:58, Theron wrote:

Hi!
I'm also seeing issues, not as severe as Pete, but after I resume 
(which works, with drm-next and DMC firmware), the system becomes 
sluggish.  It feels like I/O takes more time, and graphics are 
sluggish (very sientific, I know, but for instance git operations 
are much slower after a resume).  I know there's been an update to 
acpica between my system updates, when this started to happen, but I 
haven't had time to revert that update and test again.  I will try 
to do that and report back.

Regards

Hi Niclas,
I used drm-next on Skylake with issues which sound similar. Resuming 
from suspend, or simply switching the laptop display output off and 
on from xrandr, resulted in graphics sluggishness (drop to 30fps in 
glxgears) and graphical corruption in Xorg apps, which persisted even 
after restarting these apps. Switching to drm-stable made the 
problems go away; I haven't had time to figure out what -next is 
doing differently to cause them.


Pete's issue sounds more severe, and unrelated as it happens without 
drm loaded.  My kernel is two weeks out of date (r333093), so I need 
to check whether the more recent changes affect my system as well.


so i've done a bit more debugging on my end.  i've even installed the 
11.2-BETA branch last night since 11-STABLE worked without issues 
about a month or so ago.


i've set "debug.acpi.resume_beep=1" and when resuming after entering 
an S3 sleep state the bell rings and does not stop until i do a hard 
reset (both with i915kms loaded and unloaded).


kinda at a loss as to how this could break both CURRENT and basically 
11-STABLE.  i'm going to make a ubuntu live image and test that, my 
laptop is a System76 laptop that shipped with ubuntu originally.  if 
that is broken as well then i guess this could be a hardware issue.


ubuntu live image suspends/resumes without issue so this certainly seems 
to be a freebsd issue unfortunately.  i guess next step is to attempt to 
find a working CURRENT snapshot that does suspend/resume without issue 
then start looking at commits?


-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: suspend/resume regression

[Michael Gmelin]

> On 13. May 2018, at 11:54, Niclas Zeising  wrote:
> 
>> On 05/13/18 09:48, Andriy Gapon wrote:
>>> On 13/05/2018 05:25, Pete Wright wrote:
>>> hi there - i have an amd64 laptop that's been running CURRENT for a while 
>>> using
>>> both drm-next and drm-stable for graphics. during the past week or so i've 
>>> run
>>> into issues with suspend resume...well technically resume has stopped 
>>> working.
>>> i've tested a couple configurations and none have allowed my system to 
>>> resume
>>> successfully:
>>> 
>>> - drm-next installed with DMC firmware loaded
>>> - drm-next installed without DMC firmware loaded (worked previously)
>>> - drm-stable with DMC
>>> - drm-stable without DMC
>>> - no drm modules loaded.
>>> 
>>> I've also tested these configs with the following sysctl set to 0 and 1:
>>> hw.acpi.reset_video
>>> 
>>> at this point i'd like to help find what the regression i'm running into 
>>> is, so
>>> any pointers on how i can help? the system seems to boot and i'm pretty 
>>> sure i
>>> can ssh into it most times, just not sure what info i should grab to help.
>>> nothing of interest in messages or dmesg buffer either.
>> Did you do any OS upgrades what was last working version and what is the 
>> current
>> version (svn revision number)?
>> Or any other notable changes before resume stopped working...
> 
> Hi!
> I'm also seeing issues, not as severe as Pete, but after I resume (which 
> works, with drm-next and DMC firmware), the system becomes sluggish.  It 
> feels like I/O takes more time, and graphics are sluggish (very sientific, I 
> know, but for instance git operations are much slower after a resume).  I 
> know there's been an update to acpica between my system updates, when this 
> started to happen, but I haven't had time to revert that update and test 
> again.  I will try to do that and report back.

Maybe a stupid question, but did you check the cpu frequency before and after 
suspend/resume? (sysctl dev.cpu)

Best,
Michael


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: suspend/resume regression

[Pete Wright]

On 05/13/2018 08:58, Theron wrote:

Hi!
I'm also seeing issues, not as severe as Pete, but after I resume 
(which works, with drm-next and DMC firmware), the system becomes 
sluggish.  It feels like I/O takes more time, and graphics are 
sluggish (very sientific, I know, but for instance git operations are 
much slower after a resume).  I know there's been an update to acpica 
between my system updates, when this started to happen, but I haven't 
had time to revert that update and test again.  I will try to do that 
and report back.

Regards

Hi Niclas,
I used drm-next on Skylake with issues which sound similar. Resuming 
from suspend, or simply switching the laptop display output off and on 
from xrandr, resulted in graphics sluggishness (drop to 30fps in 
glxgears) and graphical corruption in Xorg apps, which persisted even 
after restarting these apps.  Switching to drm-stable made the 
problems go away; I haven't had time to figure out what -next is doing 
differently to cause them.


Pete's issue sounds more severe, and unrelated as it happens without 
drm loaded.  My kernel is two weeks out of date (r333093), so I need 
to check whether the more recent changes affect my system as well.


so i've done a bit more debugging on my end.  i've even installed the 
11.2-BETA branch last night since 11-STABLE worked without issues about 
a month or so ago.


i've set "debug.acpi.resume_beep=1" and when resuming after entering an 
S3 sleep state the bell rings and does not stop until i do a hard reset 
(both with i915kms loaded and unloaded).


kinda at a loss as to how this could break both CURRENT and basically 
11-STABLE.  i'm going to make a ubuntu live image and test that, my 
laptop is a System76 laptop that shipped with ubuntu originally.  if 
that is broken as well then i guess this could be a hardware issue.


the good news is that 11.2-BETA and drm-next works great (aside from 
suspend/resume) :)


-p

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: suspend/resume regression

[Theron]

Hi!
I'm also seeing issues, not as severe as Pete, but after I resume 
(which works, with drm-next and DMC firmware), the system becomes 
sluggish.  It feels like I/O takes more time, and graphics are 
sluggish (very sientific, I know, but for instance git operations are 
much slower after a resume).  I know there's been an update to acpica 
between my system updates, when this started to happen, but I haven't 
had time to revert that update and test again.  I will try to do that 
and report back.

Regards

Hi Niclas,
I used drm-next on Skylake with issues which sound similar. Resuming 
from suspend, or simply switching the laptop display output off and on 
from xrandr, resulted in graphics sluggishness (drop to 30fps in 
glxgears) and graphical corruption in Xorg apps, which persisted even 
after restarting these apps.  Switching to drm-stable made the problems 
go away; I haven't had time to figure out what -next is doing 
differently to cause them.


Pete's issue sounds more severe, and unrelated as it happens without drm 
loaded.  My kernel is two weeks out of date (r333093), so I need to 
check whether the more recent changes affect my system as well.


Theron
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: suspend/resume regression

[Niclas Zeising]

On 05/13/18 09:48, Andriy Gapon wrote:

On 13/05/2018 05:25, Pete Wright wrote:

hi there - i have an amd64 laptop that's been running CURRENT for a while using
both drm-next and drm-stable for graphics. during the past week or so i've run
into issues with suspend resume...well technically resume has stopped working.
i've tested a couple configurations and none have allowed my system to resume
successfully:

- drm-next installed with DMC firmware loaded
- drm-next installed without DMC firmware loaded (worked previously)
- drm-stable with DMC
- drm-stable without DMC
- no drm modules loaded.

I've also tested these configs with the following sysctl set to 0 and 1:
hw.acpi.reset_video

at this point i'd like to help find what the regression i'm running into is, so
any pointers on how i can help? the system seems to boot and i'm pretty sure i
can ssh into it most times, just not sure what info i should grab to help.
nothing of interest in messages or dmesg buffer either.


Did you do any OS upgrades what was last working version and what is the current
version (svn revision number)?
Or any other notable changes before resume stopped working...



Hi!
I'm also seeing issues, not as severe as Pete, but after I resume (which 
works, with drm-next and DMC firmware), the system becomes sluggish.  It 
feels like I/O takes more time, and graphics are sluggish (very 
sientific, I know, but for instance git operations are much slower after 
a resume).  I know there's been an update to acpica between my system 
updates, when this started to happen, but I haven't had time to revert 
that update and test again.  I will try to do that and report back.

Regards
--
Niclas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: suspend/resume regression

[Andriy Gapon]

On 13/05/2018 05:25, Pete Wright wrote:
> hi there - i have an amd64 laptop that's been running CURRENT for a while 
> using
> both drm-next and drm-stable for graphics. during the past week or so i've run
> into issues with suspend resume...well technically resume has stopped 
> working. 
> i've tested a couple configurations and none have allowed my system to resume
> successfully:
> 
> - drm-next installed with DMC firmware loaded
> - drm-next installed without DMC firmware loaded (worked previously)
> - drm-stable with DMC
> - drm-stable without DMC
> - no drm modules loaded.
> 
> I've also tested these configs with the following sysctl set to 0 and 1:
> hw.acpi.reset_video
> 
> at this point i'd like to help find what the regression i'm running into is, 
> so
> any pointers on how i can help? the system seems to boot and i'm pretty sure i
> can ssh into it most times, just not sure what info i should grab to help. 
> nothing of interest in messages or dmesg buffer either.

Did you do any OS upgrades what was last working version and what is the current
version (svn revision number)?
Or any other notable changes before resume stopped working...


-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

suspend/resume regression

[Pete Wright]

hi there - i have an amd64 laptop that's been running CURRENT for a 
while using both drm-next and drm-stable for graphics. during the past 
week or so i've run into issues with suspend resume...well technically 
resume has stopped working.  i've tested a couple configurations and 
none have allowed my system to resume successfully:


- drm-next installed with DMC firmware loaded
- drm-next installed without DMC firmware loaded (worked previously)
- drm-stable with DMC
- drm-stable without DMC
- no drm modules loaded.

I've also tested these configs with the following sysctl set to 0 and 1:
hw.acpi.reset_video

at this point i'd like to help find what the regression i'm running into 
is, so any pointers on how i can help? the system seems to boot and i'm 
pretty sure i can ssh into it most times, just not sure what info i 
should grab to help.  nothing of interest in messages or dmesg buffer 
either.


cheers,
-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"