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: HEADS-UP: Linker issues building amd64 kernels with config & make

[Dimitry Andric]

On 15 May 2018, at 00:58, Ed Maste  wrote:
> 
> On 14 May 2018 at 18:05, Julian H. Stacey  wrote:
>> 
>> I guess this explains :
>> Date: Sun, 13 May 2018 20:26:38 +0200
>> Subject: cd /sys/amd64/compile/GENERIC;make cleandepend; make cleandepend
>>.svn_revision 333575
>>linking kernel.full
>>iflib.o:(.rodata+0x178): undefined reference to `noop_attach'
>>iflib.o:(.rodata+0x188): undefined reference to `iflib_pseudo_detach'
> 
> No, that's something else; I haven't seen that problem before.
> 
> Note that we've been using lld as the default bootstrap linker (i.e.,
> the linker used to link the world and kernel via 'make buildworld' and
> 'make buildkernel') since Jan 10 (r327783).
> 
>> PS Bloat factor > 20: 2M static V 40M dynamic,
> 
> Keep in mind that the in-tree ld.bfd was released over a decade ago,
> and has been obsolete for years now; a dynamically-linked contemporary
> ld.bfd 12MB. lld is much faster than any of them (more than 20x
> compared to in-tree ld.bfd on some operations) and all of the target
> architectures are supported by a single binary.

Not just that: since lld can do link time optimization (LTO), it also
contains large parts of LLVM, e.g. the backend of the compiler.

We could maybe save some space by putting all the LLVM stuff into a
separate dynamic library, and re-using that from both clang and lld, but
such a dynamic library has its own issues.  (Takes a long time and lots
of memory to link, and probably takes quite some time to dynamically
load at runtime too.)

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: HEADS-UP: Linker issues building amd64 kernels with config & make

[Julian H. Stacey]

Hi, Reference:
> From: Ed Maste 
> Date: Mon, 14 May 2018 18:58:25 -0400

Ed Maste wrote:
> On 14 May 2018 at 18:05, Julian H. Stacey  wrote:
> >
> > I guess this explains :
> > Date: Sun, 13 May 2018 20:26:38 +0200
> > Subject: cd /sys/amd64/compile/GENERIC;make cleandepend; make cleandepend
> > .svn_revision 333575
> > linking kernel.full
> > iflib.o:(.rodata+0x178): undefined reference to `noop_attach'
> > iflib.o:(.rodata+0x188): undefined reference to 
> > `iflib_pseudo_detach'
> 
> No, that's something else; I haven't seen that problem before.

Ah ! Thanks

> Note that we've been using lld as the default bootstrap linker (i.e.,
> the linker used to link the world and kernel via 'make buildworld' and
> 'make buildkernel') since Jan 10 (r327783).
> 
> > PS Bloat factor > 20: 2M static V 40M dynamic,
> 
> Keep in mind that the in-tree ld.bfd was released over a decade ago,
> and has been obsolete for years now; a dynamically-linked contemporary
> ld.bfd 12MB. lld is much faster than any of them (more than 20x
> compared to in-tree ld.bfd on some operations) and all of the target
> architectures are supported by a single binary.

OK Thanks.

Cheers,
Julian
-- 
Julian Stacey, Computer Consultant, Systems Engineer, BSD Linux Unix, Munich
 Brexit Referendum stole 3,700,000 votes, inc. 700,000 from British in EU.
 UK Govt. lied it's "democratic" in Article 50 letter to EU paragraph 3.
Petition for votes: http://berklix.eu/queen/
___
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: HEADS-UP: Linker issues building amd64 kernels with config & make

[Ed Maste]

On 14 May 2018 at 18:05, Julian H. Stacey  wrote:
>
> I guess this explains :
> Date: Sun, 13 May 2018 20:26:38 +0200
> Subject: cd /sys/amd64/compile/GENERIC;make cleandepend; make cleandepend
> .svn_revision 333575
> linking kernel.full
> iflib.o:(.rodata+0x178): undefined reference to `noop_attach'
> iflib.o:(.rodata+0x188): undefined reference to `iflib_pseudo_detach'

No, that's something else; I haven't seen that problem before.

Note that we've been using lld as the default bootstrap linker (i.e.,
the linker used to link the world and kernel via 'make buildworld' and
'make buildkernel') since Jan 10 (r327783).

> PS Bloat factor > 20: 2M static V 40M dynamic,

Keep in mind that the in-tree ld.bfd was released over a decade ago,
and has been obsolete for years now; a dynamically-linked contemporary
ld.bfd 12MB. lld is much faster than any of them (more than 20x
compared to in-tree ld.bfd on some operations) and all of the target
architectures are supported by a single binary.
___
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: HEADS-UP: Linker issues building amd64 kernels with config & make

[Julian H. Stacey]

Ed Maste wrote:
> As of r333461 the amd64 kernel makes use of ifuncs, and requires
> support in the linker. A safety belt added in r333470 enforces this,
> and will produce an explicit error if the linker does not support
> ifuncs.
> 
> lld is the default bootstrap linker for amd64 and has ifunc support.
> The typical 'make buildworld' (or kernel-toolchain) followed by 'make
> buildkernel' process will use lld and successfully link a working
> kernel.
> 
> The old-style kernel build (using 'config' followed by a 'make' in the
> kernel directory) uses the host linker (/usr/bin/ld). This still
> defaults to GNU ld 2.17.50, which does not support ifuncs. This can be
> worked around in one of two ways:
> 
> 1. Install lld as the system linker (/usr/bin/ld), by adding
> WITH_LLD_IS_LD to /etc/src.conf and building and install world.
> WITH_LLD_IS_LD will become the default on amd64 in the near future -
> I'm just waiting on updates to the lang/ghc port and another exp-run.
> 
> 2. Override LD when you build the kernel:
> $ LD=ld.lld make
> 
> These tool chain components will undergo additional changes for the next 
> while.

I guess this explains :
Date: Sun, 13 May 2018 20:26:38 +0200
Subject: cd /sys/amd64/compile/GENERIC;make cleandepend; make cleandepend
.svn_revision 333575
linking kernel.full
iflib.o:(.rodata+0x178): undefined reference to `noop_attach'
iflib.o:(.rodata+0x188): undefined reference to `iflib_pseudo_detach'

PS Bloat factor > 20: 2M static V 40M dynamic, 
(normaly dynamics are smaller, not larger).
cd /usr/bin; ls -l *ld*
-r-xr-xr-x  2 root  wheel   1935992 May 13 12:48 ld*
-r-xr-xr-x  1 root  wheel  40449288 May 13 12:54 ld.lld*
file ld ld.lld
ld: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD),
 statically linked,
 for FreeBSD 12.0 (1200063), FreeBSD-style, stripped
ld.lld: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD),
 dynamically linked, interpreter /libexec/ld-elf.so.1,
 for FreeBSD 12.0 (1200063), FreeBSD-style, stripped

Cheers,
Julian
-- 
Julian Stacey, Computer Consultant, Systems Engineer, BSD Linux Unix, Munich
 Brexit Referendum stole 3,700,000 votes, inc. 700,000 from British in EU.
 UK Govt. lied it's "democratic" in Article 50 letter to EU paragraph 3.
Petition for votes: http://berklix.eu/queen/
___
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"

HEADS-UP: Linker issues building amd64 kernels with config & make

[Ed Maste]

As of r333461 the amd64 kernel makes use of ifuncs, and requires
support in the linker. A safety belt added in r333470 enforces this,
and will produce an explicit error if the linker does not support
ifuncs.

lld is the default bootstrap linker for amd64 and has ifunc support.
The typical 'make buildworld' (or kernel-toolchain) followed by 'make
buildkernel' process will use lld and successfully link a working
kernel.

The old-style kernel build (using 'config' followed by a 'make' in the
kernel directory) uses the host linker (/usr/bin/ld). This still
defaults to GNU ld 2.17.50, which does not support ifuncs. This can be
worked around in one of two ways:

1. Install lld as the system linker (/usr/bin/ld), by adding
WITH_LLD_IS_LD to /etc/src.conf and building and install world.
WITH_LLD_IS_LD will become the default on amd64 in the near future -
I'm just waiting on updates to the lang/ghc port and another exp-run.

2. Override LD when you build the kernel:
$ LD=ld.lld make

These tool chain components will undergo additional changes for the next while.
___
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: cd /sys/amd64/compile/GENERIC;make cleandepend; make cleandepend

[Julian H. Stacey]

Hi, Reference:
> From: "Julian H. Stacey" 
> Date: Mon, 14 May 2018 14:21:14 +0200

> In case there's more tool dependency checking/ auto update done,
> I'm now running 'script' & within that 'cd /usr/src; make buildkernel'

That worked ! 
(Although looking at my template script I've run that before recently)

===> zlib (all)
[Creating objdir 
/data/release/s4/usr/obj/usr/src/amd64.amd64/sys/GENERIC/modules/usr/src/sys/modules/zlib...]
machine -> /usr/src/sys/amd64/include
x86 -> /usr/src/sys/x86/include
cc -target x86_64-unknown-freebsd12.0 
--sysroot=/data/release/s4/usr/obj/usr/src/amd64.amd64/tmp 
-B/data/release/s4/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe  
-fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   
-DHAVE_KERNEL_OPTION_HEADERS -include 
/data/release/s4/usr/obj/usr/src/amd64.amd64/sys/GENERIC/opt_global.h -I. 
-I/usr/src/sys -I/usr/src/sys/contrib/ck/include -fno-common -g 
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
-I/data/release/s4/usr/obj/usr/src/amd64.amd64/sys/GENERIC   -MD  
-MF.depend.zlib.o -MTzlib.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse 
-msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv 
-fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef 
-Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs 
-fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare 
-Wno-error-empty-b!
 ody -Wno-error-parentheses-equality -Wno-error-unused-function 
-Wno-error-pointer-sign -Wno-error-shift-negative-value 
-Wno-error-address-of-packed-member  -mno-aes -mno-avx  -std=iso9899:1999 -c 
/usr/src/sys/libkern/zlib.c -o zlib.o
ctfconvert -L VERSION -g zlib.o
ld -m elf_x86_64_fbsd -d -warn-common --build-id=sha1 -r -d -o zlib.ko.full 
zlib.o
ctfmerge -L VERSION -g -o zlib.ko.full zlib.o
:> export_syms
awk -f /usr/src/sys/conf/kmod_syms.awk zlib.ko.full  export_syms | xargs -J% 
objcopy % zlib.ko.full
objcopy --only-keep-debug zlib.ko.full zlib.ko.debug
objcopy --strip-debug --add-gnu-debuglink=zlib.ko.debug  zlib.ko.full zlib.ko
--
>>> Kernel build for GENERIC completed on Mon May 14 15:07:43 CEST 2018

make installkernel ; reboot # OK!

Sorry, I can't pin it down, at least yet, now trying a custom kernel.

Cheers,
Julian
-- 
Julian Stacey, Computer Consultant, Systems Engineer, BSD Linux Unix, Munich
 Brexit Referendum stole 3,700,000 votes, inc. 700,000 from British in EU.
 UK Govt. lied it's "democratic" in Article 50 letter to EU paragraph 3.
Petition for votes: http://berklix.eu/queen/
___
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: cd /sys/amd64/compile/GENERIC;make cleandepend; make cleandepend

[Julian H. Stacey]

Hi, Reference my
> linking kernel.full
> iflib.o:(.rodata+0x178): undefined reference to `noop_attach'
> iflib.o:(.rodata+0x188): undefined reference to `iflib_pseudo_detach'

[ Thanks for call Gary, I have: ]

ls -l /usr/bin/ld*
-r-xr-xr-x  2 root  wheel   1935992 May 13 12:48 /usr/bin/ld*
-r-xr-xr-x  2 root  wheel   1935992 May 13 12:48 /usr/bin/ld.bfd*
-r-xr-xr-x  1 root  wheel  40449288 May 13 12:54 /usr/bin/ld.lld*
-r-xr-xr-x  1 root  wheel 19352 May 13 12:52 /usr/bin/ldd*
-r-xr-xr-x  1 root  wheel 26872 May 13 08:59 /usr/bin/ldd32*

uname -a
FreeBSD lapr.js.berklix.net 12.0-CURRENT FreeBSD 12.0-CURRENT #0: Sat May 12 
13:37:23 CEST 2018 
j...@lapr.js.berklix.net:/data/release/s4/usr/obj/usr/src/amd64.amd64/sys/GENERIC
  amd64

cat .svn_revision # 333575
cat .ctm_status  # src-cur 13520

In case there's more tool dependency checking/ auto update done,
I'm now running 'script' & within that 'cd /usr/src; make buildkernel'

(Instead of my previous 
cd /sys/amd64/conf; make links; make# (makes my host conf.)
config `hostname -s | dd conv=ucase`.small
cd ../compile/`hostname -s | dd conv=ucase`.small
make obj; make cleandepend && make depend && make all && make install
)

Cheers,
Julian
-- 
Julian Stacey, Computer Consultant, Systems Engineer, BSD Linux Unix, Munich
 Brexit Referendum stole 3,700,000 votes, inc. 700,000 from British in EU.
 UK Govt. lied it's "democratic" in Article 50 letter to EU paragraph 3.
Petition for votes: http://berklix.eu/queen/
___
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: cd /sys/amd64/compile/GENERIC;make cleandepend; make cleandepend

[Julian H. Stacey]

"Julian H. Stacey" wrote:
> Hi, Reference:
> > From:   Ryan Stone 
> > Date:   Sun, 13 May 2018 17:00:50 -0400
> 
> Thanks for reply :-)
> 
> Ryan Stone wrote:
> > Are you building with WITH_LD_IS_LLD=no?
> 
> Not that I've set anywhere. Unless it comes from make world ?
> 
> >  -CURRENT can no longer be
> > built with a GPLv2 ld.  You either have to use ldd or install a newer
> 
> -r-xr-xr-x  1 root  wheel  19352 May 13 12:52 /usr/bin/ldd*
> 
> > (GPLv3) binutils package.
> 
> pkg info | grep binutils
> binutils-2.30_3,1  GNU binary tools
> gnatdroid-binutils-2.27_1  Infrastructure for C/Ada Android 
> cross-compiler (ARMv7)
> 
> pkg upgrade
> The process will require 132 MiB more space.
> 569 MiB to be downloaded.
> 
> I'll leave it running & report back later, Thanks

/sys/amd64/compile/LAPR.small xs !!
xs make
cc -c -O2 -pipe -fno-strict-aliasing  -g -nostdinc  -I. -I../../.. 
-I../../../contrib/ck/include -I../../../contrib/libfdt -D_KERNEL 
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  -fno-omit-frame-pointer 
-mno-omit-leaf-frame-pointer -MD  -MF.depend.iflib.o -MTiflib.o -mcmodel=kernel 
-mno-red-zone -mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables 
-ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ 
-Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas 
-Wno-error-tautological-compare -Wno-error-empty-body 
-Wno-error-parentheses-equality -Wno-error-unused-function 
-Wno-error-pointer-sign -Wno-error-shift-negative-value 
-Wno-error-address-of-packed-member  -mno-aes -mno-avx  -std=iso9899:1999 
-Werror  ../../../net/iflib.c
ctfconvert -L VERSION -g iflib.o
MAKE="make" sh ../../../conf/newvers.sh  JHS_Lapr
cc -c -O2 -pipe -fno-strict-aliasing  -g -nostdinc  -I. -I../../.. 
-I../../../contrib/ck/include -I../../../contrib/libfdt -D_KERNEL 
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  -fno-omit-frame-pointer 
-mno-omit-leaf-frame-pointer  -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse 
-msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv 
-fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef 
-Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs 
-fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare 
-Wno-error-empty-body -Wno-error-parentheses-equality 
-Wno-error-unused-function -Wno-error-pointer-sign 
-Wno-error-shift-negative-value -Wno-error-address-of-packed-member  -mno-aes 
-mno-avx  -std=iso9899:1999 -Werror  vers.c
ctfconvert -L VERSION -g vers.o
linking kernel.full
iflib.o:(.rodata+0x178): undefined reference to `noop_attach'
iflib.o:(.rodata+0x188): undefined reference to `iflib_pseudo_detach'
*** Error code 1

pkg info | grep binutils

l `which ldd`
-r-xr-xr-x  1 root  wheel  19352 May 13 12:52 /usr/bin/ldd*

l /usr/bin/ld
-r-xr-xr-x  2 root  wheel  1935992 May 13 12:48 /usr/bin/ld*

cd /usr;mv local localMV;rehash
cd /sys/amd64/conf;cd ../compile/`hostname -s | dd conv=ucase`.small
make
iflib.o:(.rodata+0x178): undefined reference to `noop_attach'
iflib.o:(.rodata+0x188): undefined reference to `iflib_pseudo_detach'

so nothing to do with packages & local.
For decades it been policy that src/ must be able to build itself
without needing ports/ So what's wrong ? Anyone else see this ?

Cheers,
Julian
-- 
Julian Stacey, Computer Consultant, Systems Engineer, BSD Linux Unix, Munich
 Brexit Referendum stole 3,700,000 votes, inc. 700,000 from British in EU.
 UK Govt. lied it's "democratic" in Article 50 letter to EU paragraph 3.
Petition for votes: http://berklix.eu/queen/
___
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"