Re: Laptop exhibits erratic responsiveness

2020-11-29 Thread David Wolfskill 
On Sun, Nov 29, 2020 at 08:16:22AM -0800, David Wolfskill wrote:
> On Sun, Nov 29, 2020 at 11:04:46AM -0500, Ryan Stone wrote:
> ...
> > I believe that if you run lockstat with the additional "-x
> > destructive" option, it will disable the responsiveness test (the
> > option does sound scary but it will not have any other potentially
> > destructive effect)
> 
> Thanks; the laptop is presently running head @r368143, building
> head @r367410 (which is gthe last point before the issues were
> observed, I think), so I have fired that up.
> 

And that attempt completed; the reulting typescript may be found at
http://www.catwhisker.org/~david/FreeBSD/head/lockstat/lockstat_head_new

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Make America Great Again," he said -- and THIS is what he did??!?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Laptop exhibits erratic responsiveness

2020-11-29 Thread David Wolfskill 
On Sun, Nov 29, 2020 at 11:04:46AM -0500, Ryan Stone wrote:
> On Sun, Nov 29, 2020 at 9:12 AM David Wolfskill  wrote:
> > OK, and demonstrated some long RTTs about every 11 packets or so, but we
> > see thing come to a screeching halt with:
> >
> > ...
> > 64 bytes from 172.16.8.13: icmp_seq=534 ttl=63 time=0.664 ms
> > lockstat: dtrace_status(): Abort due to systemic unresponsiveness
> > 64 bytes from 172.16.8.13: icmp_seq=535 ttl=63 time=9404.383 ms
> >
> > and we get no lockstat output. :-/
> 
> I believe that if you run lockstat with the additional "-x
> destructive" option, it will disable the responsiveness test (the
> option does sound scary but it will not have any other potentially
> destructive effect)

Thanks; the laptop is presently running head @r368143, building
head @r367410 (which is gthe last point before the issues were
observed, I think), so I have fired that up.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Make America Great Again," he said -- and THIS is what he did??!?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Laptop exhibits erratic responsiveness

2020-11-29 Thread Ryan Stone 
On Sun, Nov 29, 2020 at 9:12 AM David Wolfskill  wrote:
> OK, and demonstrated some long RTTs about every 11 packets or so, but we
> see thing come to a screeching halt with:
>
> ...
> 64 bytes from 172.16.8.13: icmp_seq=534 ttl=63 time=0.664 ms
> lockstat: dtrace_status(): Abort due to systemic unresponsiveness
> 64 bytes from 172.16.8.13: icmp_seq=535 ttl=63 time=9404.383 ms
>
> and we get no lockstat output. :-/

I believe that if you run lockstat with the additional "-x
destructive" option, it will disable the responsiveness test (the
option does sound scary but it will not have any other potentially
destructive effect)
___
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: Laptop exhibits erratic responsiveness

2020-11-29 Thread David Wolfskill 
On Sun, Nov 29, 2020 at 03:20:15PM +0100, Mateusz Guzik wrote:
> ...
> According to the data you got the entire kernel "freezes" every 11-12
> seconds. So something way off is going on there.

I'm (quite) prepared to believe that. :-}

> Given that the bug seems to be reproducible I think it would be best
> if you just bisected to the offending commit.

Hmm  OK; thanks, Mateusz.

> -- 
> Mateusz Guzik 

I'll see what I can do.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Make America Great Again," he said -- and THIS is what he did??!?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Laptop exhibits erratic responsiveness

2020-11-29 Thread Mateusz Guzik 
On 11/29/20, David Wolfskill  wrote:
> On Sat, Nov 28, 2020 at 10:47:57AM -0500, Jonathan Looney wrote:
>> FWIW, I would try running lockstat on the box. (My supposition is that
>> the
>> delay is due to a lock. That could be incorrect.  Lockstat may provide
>> some
>> clue as to whether this is a line of inquiry worth pursuing.)
>> 
>
> Thanks (again), Jonathan.
>
> So... I did that (during this morning's daily upgrade cycle); the
> results may be "of interest" to some.
>
> I have placed copies of the typescripts in:
>
> http://www.catwhisker.org/~david/FreeBSD/head/lockstat/
>
> I also scribbled a "README" in that same directory (though it doesn't
> seem to show up in the listing); it may be accessed via
>
> http://www.catwhisker.org/~david/FreeBSD/head/lockstat/README
>
> My prior message in this thread showed what I saw during a "ping albert"
> from the laptop while it was running head -- most RTTs were around 0.600
> ms, but some were notably longer, with at least one that was over 68
> seconds.
>
> So I did a "lockstat ping -c 64 albert" while the laptop was running
> stable/12@r368123 (as a reference point); it is probably boring. :-}
>
> Then (this morning), I tried a simple "lockstat sleep 600" on the laptop
> while it was running head@r368119 (and building head@r368143); we see
> the "lockstat" output in the "lockstat_head" file.
>
> It then occurred to me that trying a "lockstat ping albert" might be
> useful, so I fired up "lockstat ping -c 600 albert" -- which started up
> OK, and demonstrated some long RTTs about every 11 packets or so, but we
> see thing come to a screeching halt with:
>
> ...
> 64 bytes from 172.16.8.13: icmp_seq=534 ttl=63 time=0.664 ms
> lockstat: dtrace_status(): Abort due to systemic unresponsiveness
> 64 bytes from 172.16.8.13: icmp_seq=535 ttl=63 time=9404.383 ms
>
> and we get no lockstat output. :-/
>
>
> Finally, as another "control," I ran similar commands from freebeast,
> while it was running head@r368119 (and building head@r368143).  Those
> results are in the "lockstat_freebeast" file.
>

According to the data you got the entire kernel "freezes" every 11-12
seconds. So something way off is going on there.

Given that the bug seems to be reproducible I think it would be best
if you just bisected to the offending commit.

-- 
Mateusz Guzik 
___
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: Laptop exhibits erratic responsiveness

2020-11-29 Thread David Wolfskill 
On Sat, Nov 28, 2020 at 10:47:57AM -0500, Jonathan Looney wrote:
> FWIW, I would try running lockstat on the box. (My supposition is that the
> delay is due to a lock. That could be incorrect.  Lockstat may provide some
> clue as to whether this is a line of inquiry worth pursuing.)
> 

Thanks (again), Jonathan.

So... I did that (during this morning's daily upgrade cycle); the
results may be "of interest" to some.

I have placed copies of the typescripts in:

http://www.catwhisker.org/~david/FreeBSD/head/lockstat/

I also scribbled a "README" in that same directory (though it doesn't
seem to show up in the listing); it may be accessed via

http://www.catwhisker.org/~david/FreeBSD/head/lockstat/README

My prior message in this thread showed what I saw during a "ping albert"
from the laptop while it was running head -- most RTTs were around 0.600
ms, but some were notably longer, with at least one that was over 68
seconds.

So I did a "lockstat ping -c 64 albert" while the laptop was running
stable/12@r368123 (as a reference point); it is probably boring. :-}

Then (this morning), I tried a simple "lockstat sleep 600" on the laptop
while it was running head@r368119 (and building head@r368143); we see
the "lockstat" output in the "lockstat_head" file.

It then occurred to me that trying a "lockstat ping albert" might be
useful, so I fired up "lockstat ping -c 600 albert" -- which started up
OK, and demonstrated some long RTTs about every 11 packets or so, but we
see thing come to a screeching halt with:

...
64 bytes from 172.16.8.13: icmp_seq=534 ttl=63 time=0.664 ms
lockstat: dtrace_status(): Abort due to systemic unresponsiveness
64 bytes from 172.16.8.13: icmp_seq=535 ttl=63 time=9404.383 ms

and we get no lockstat output. :-/


Finally, as another "control," I ran similar commands from freebeast,
while it was running head@r368119 (and building head@r368143).  Those
results are in the "lockstat_freebeast" file.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Make America Great Again," he said -- and THIS is what he did??!?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Thames [Radeon HD 7550M/7570M/7650M]: drm.ko in lieu of radeonkms, with xf86-video-ati (was: need some advice for video output)

2020-11-29 Thread Graham Perrin 
At 
 
Antonio Olivares wrote:

Restarting the machine fixed the problem.  I removed the line from rc.conf
and installed xf86-video-ati
pkg and now have a good working desktop.
Sorry for the noise.

Best Regards,


Antonio


I don't mind the noise :-)

With Thames [Radeon HD 7550M/7570M/7650M] on -CURRENT, I benefit from 
/boot/modules/drm.ko (specifically _not_ radeonkms) specified in rc.conf:


root@mowa219-gjp4-8570p:~ # grep -v \# /etc/rc.conf | grep kld
kldxref_enable="NO"
kldxref_clobber="NO"
kld_list="fusefs"
kld_list="/boot/modules/drm.ko"
root@mowa219-gjp4-8570p:~ # pkg query '%o %v %R' drm-kmod 
drm-current-kmod xf86-video-ati xf86-video-amdgpu

graphics/drm-kmod g20190710 poudriere
graphics/drm-current-kmod 5.4.62.g20201109_1 poudriere
x11-drivers/xf86-video-ati 19.1.0_3,1 FreeBSD
root@mowa219-gjp4-8570p:~ # date ; uname -v
Sun Nov 29 09:07:34 GMT 2020
FreeBSD 13.0-CURRENT #72 r367936: Sun Nov 22 21:46:00 GMT 2020 
root@mowa219-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG

root@mowa219-gjp4-8570p:~ #

Peculiar.

Background:

 
a suggestion to try not having |xf86-video-| anything.


 
success after ceasing use of kld_list="radeonkms" in rc.conf.


HW probe of HP EliteBook 8570p #1f3fa432dc


___
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"

zpool export: umount fails due to gvfsd-trash (Thunar wrongly opened by Firefox)

2020-11-29 Thread Graham Perrin 

On 26/11/2020 10:07, Kurt Jaeger wrote:

Use fstat -- this is part of the base system.

Maybe lsof does not catch every corner case ?

On 26/11/2020 17:34, Gary Palmer wrote:

does "fuser -c" show anything?

the -m option may also be interesting (Search through mmapped files too)

Regards,

Gary


Thanks.

As far as I can tell the problem occurs only when Thunar, which I rarely 
use, is wrongly opened by Firefox.


KDE Plasma here. I can't recall how to force applications such as 
Firefox to respect my preference for Dolphin.


gvfsd-trash considered harmful
 



From htop:

…

  PID USER  PRI  NI  VIRT   RES S CPU% MEM%   TIME+  Command

 4484 grahamper  21   0 39168 12692 S  0.0  0.1  0:00.17    ├─ 
gvfsd-metadata
 4206 grahamper  20   0 37768  8564 S  0.0  0.1  0:00.12    ├─ 
gvfs-gphoto2-volume-monitor
 4201 grahamper  20   0 36548  8188 S  0.0  0.0  0:00.11    ├─ 
gvfs-mtp-volume-monitor
 4184 grahamper  20   0 48072 13168 S  0.0  0.1  0:00.63    ├─ 
gvfs-udisks2-volume-monitor

 4179 grahamper  20   0 40660  8748 S  0.0  0.1  0:00.17    ├─ gvfsd
 7288 grahamper  20   0 45140 10476 S  0.0  0.1  0:00.06    │  ├─ 
gvfsd-dnssd --spawner :1.34 /org/gtk/gvfs/exec_spaw/5
 7285 grahamper  20   0 53520 10016 S  0.0  0.1  0:00.09    │  ├─ 
gvfsd-network --spawner :1.34 /org/gtk/gvfs/exec_spaw/3
 5883 grahamper  20   0 47608  9640 S  0.0  0.1  0:01.07    │  └─ 
gvfsd-trash --spawner :1.34 /org/gtk/gvfs/exec_spaw/2




root@mowa219-gjp4-8570p:~ # zpool export Transcend
cannot unmount '/Volumes/t500/VirtualBox': umount failed
root@mowa219-gjp4-8570p:~ # fstat -f /Volumes/t500/VirtualBox
USER CMD  PID   FD MOUNT  INUM MODE SZ|DV R/W
grahampe gvfsd-trash  5883   19 /Volumes/t500/VirtualBox 34 
drwxr-xr-x   7  r
grahampe gvfsd-trash  5883   20 /Volumes/t500/VirtualBox 34 
drwxr-xr-x   7  r
grahampe gvfsd-trash  5883   21 /Volumes/t500/VirtualBox    401 
drwx--   4  r
grahampe gvfsd-trash  5883   22 /Volumes/t500/VirtualBox    403 
drwxr-xr-x   3  r

root@mowa219-gjp4-8570p:~ # fuser -c /Volumes/t500/VirtualBox
/Volumes/t500/VirtualBox:
root@mowa219-gjp4-8570p:~ # find /Volumes/t500/VirtualBox \( -inum 34 
-or -inum 401 -or -inum 403 \) -print

/Volumes/t500/VirtualBox
/Volumes/t500/VirtualBox/.Trash-1002
/Volumes/t500/VirtualBox/.Trash-1002/files
root@mowa219-gjp4-8570p:~ # zfs list /Volumes/t500 /Volumes/t500/VirtualBox
NAME   USED  AVAIL REFER  MOUNTPOINT
Transcend  115G   335G   96K  /Volumes/t500
Transcend/VirtualBox   114G   335G  114G /Volumes/t500/VirtualBox
root@mowa219-gjp4-8570p:~ #

(My previous over-reliance upon lsof stemmed from familiarity with the 
command on Mac OS X with HFS Plus.)


___
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"