Re: 60+% ping packet loss on Pi3 under -current and stable-13

On Mon, May 02, 2022 at 11:45:21AM -0700, Mark Millard wrote: > I just saw something odd when trying to test again. > > I did not manage to capture the earlier display updates > but when it first connected it had a list of "(waiting > for reply)" lines from 17. to 27. with www.zefox.org > at 28. T

Re: 60+% ping packet loss on Pi3 under -current and stable-13

On Mon, May 02, 2022 at 06:48:58PM +0200, Hans Petter Selasky wrote: > > You may also want to correlate: > > usbconfig dump_stats > On the -current Pi3 I see in part: ugen1.4: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) { UE_CONTROL_OK : 83 UE_ISOCHRONOUS_OK : 0

[Bug 263721] BCM5720 fails to work on Dell PowerEdge R6515

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263721 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org -- You are receiv

Re: 60+% ping packet loss on Pi3 under -current and stable-13

I just saw something odd when trying to test again. I did not manage to capture the earlier display updates but when it first connected it had a list of "(waiting for reply)" lines from 17. to 27. with www.zefox.org at 28. That range got shorter in steps but fairly rapidly. Before the 18. to 28. s

Re: 60+% ping packet loss on Pi3 under -current and stable-13

On 2022-May-2, at 08:53, bob prohaska wrote: > On Mon, May 02, 2022 at 08:56:12AM +0200, Hans Petter Selasky wrote: > [reply at end] >> On 5/2/22 03:13, bob prohaska wrote: >>> On Sun, May 01, 2022 at 05:10:59PM -0700, Mark Millard wrote: >>> [reply at end] On 2022-May-1, at 16:27, bob proha

Re: 60+% ping packet loss on Pi3 under -current and stable-13

On 5/2/22 18:43, Bakul Shah wrote: This is due to tcpdump. On May 2, 2022, at 8:53 AM, bob prohaska wrote: One new oddity is seeing in the daily security report the lines www.zefox.org kernel log messages: +ue0: promiscuous mode enabled +ue0: promiscuous mode disabled

Re: 60+% ping packet loss on Pi3 under -current and stable-13

This is due to tcpdump. > On May 2, 2022, at 8:53 AM, bob prohaska wrote: > > One new oddity is seeing in the daily security report the lines > www.zefox.org kernel log messages: > +ue0: promiscuous mode enabled > +ue0: promiscuous mode disabled > +ue0: promiscuous mode e

Re: 60+% ping packet loss on Pi3 under -current and stable-13

On Mon, May 02, 2022 at 08:56:12AM +0200, Hans Petter Selasky wrote: [reply at end] > On 5/2/22 03:13, bob prohaska wrote: > > On Sun, May 01, 2022 at 05:10:59PM -0700, Mark Millard wrote: > > [reply at end] > > > On 2022-May-1, at 16:27, bob prohaska wrote: > > > > > > > On Sun, May 01, 2022 at

Re: 60+% ping packet loss on Pi3 under -current and stable-13

On 2022-05-01 12:58, Mark Millard wrote: On 2022-May-1, at 12:15, Mark Millard wrote: On 2022-May-1, at 11:12, bob prohaska wrote: On Sat, Apr 30, 2022 at 06:39:57PM -0700, Bakul Shah wrote: On Apr 29, 2022, at 7:12 PM, bob prohaska wrote: Since about December of 2021 I've been noticin

[Bug 206168] Broadcom 57xx fails on any version of FreeBSD

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206168 --- Comment #15 from Eugene Grosbein --- (In reply to ferdinand.goldmann from comment #13) Please create new PR, specify your FreeBSD version, kernel type (GENERIC or custom), describe hardware and do not disable msi, use defaults to show

[Bug 206168] Broadcom 57xx fails on any version of FreeBSD

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206168 --- Comment #14 from ferdinand.goldm...@jku.at --- Created attachment 233662 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=233662&action=edit console output for bge0 interface -- You are receiving this mail because: You are on

[Bug 206168] Broadcom 57xx fails on any version of FreeBSD

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206168 ferdinand.goldm...@jku.at changed: What|Removed |Added CC||ferdinand.goldm...@jku.a

Re: 60+% ping packet loss on Pi3 under -current and stable-13

On May 1, 2022, at 11:12 AM, bob prohaska wrote: > The "oui unknown" looks like some sort of failure. Just ignore. tcpdump couldn't identify the vendor. Your tcpdump trace didn't give me anything useful. One suggestion is to use -n flag so that tcpdump doesn't do DNS resolution! Better, just