Re: Review D28062 of /usr/src/UPDATING with regard to upgrading FreeBSD and inconsistency with the FreeBSD Handbook

work fine on the next upgrade. However, I'm curious how you didn't get the etcupdate bootstrap when you initially installed. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscr

Re: Review D28062 of /usr/src/UPDATING with regard to upgrading FreeBSD and inconsistency with the FreeBSD Handbook

normally. The actual tree comparison isn't affected. -- John Baldwin ___ 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: Getting started with ktls

'ktls_enable_tx' and 'ktls_enable_rx' are failing, or barring that printf. For example, does ktls_create_session() fail, or does ktls_try_sw() fail? It is probably easiest to debug this using a userland application using openssl than trying NFS over TLS. -- John Baldwin

Re: On 14-CURRENT: no ports options anymore?

, the 12.x dialog4ports was still going to fail as the 12.x version of those libraries were already broken. I haven't checked to see if the affected libraries have been added to misc/compat12x. -- John Baldwin ___ freebsd-current@freebsd.org mailing list ht

Re: Getting started with ktls

in both directions (or if you use TLS 1.1 with TOE offload on a Chelsio T6). -- John Baldwin ___ 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: Rationalizing sed -i/-I (in-place editing) argument handling

I really dislike a command line argument having an optional argument. It can cause parsing confusion and possibly security issues... Copying this behavior, IMO, is not good... So my vote is against this misfeature.. How is the program suppose to tell when the extension is "-e", or -e is

Re: URL for stable/13

On Tue, Mar 02, 2021 at 08:18:23AM -0800, bob prohaska wrote: > A while back I obtained a buildable source tree for stable/13 > but it hasn't been updated in the last few days. Running > git remote show origin > reports in part > . > Local branch configured for 'git pull': > stable/13

Re: HEADS-UP: PIE enabled by default on main

On Sun, Feb 28, 2021 at 09:40:54AM -0500, Shawn Webb wrote: > ... The point of ASLR is to combine it with W^X. Without W^X, ASLR makes > no sense. FreeBSD recently gained a W^X implementation that requires > opt-in. ... I'm not plugged into the right places to catch some of these things up

Re: HEADS-UP: PIE enabled by default on main

On Fri, Feb 26, 2021 at 10:10:28AM +1100, Greg 'groggy' Lehey wrote: > On Thursday, 25 February 2021 at 15:58:07 -0500, Ed Maste wrote: > > As of 9a227a2fd642 (main-n245052) base system binaries are now built > > as position-independent executable (PIE) by default, for 64-bit > > architectures.

Re: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?

On 2/11/21 9:59 AM, Hartmann, O. wrote: On Wed, 10 Feb 2021 07:21:20 +0100 "Hartmann, O." wrote: On Tue, 9 Feb 2021 15:15:38 -0800 John Baldwin wrote: On 2/9/21 2:16 PM, Hartmann, O. wrote: On Wed, 3 Feb 2021 17:34:24 +0100 Guido Falsi via freebsd-current wrote: On 03/0

Re: zpool upgrade can't enable new features

On Thu, Feb 25, 2021 at 11:09:17AM -0300, Renato Botelho wrote: > I recently upgraded a CURRENT system to main-n244932-248a47a4c2f and > zpool status shows: > >pool: zroot > state: ONLINE > status: Some supported and requested features are not enabled on the pool. > The pool can

Re: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?

On 2/9/21 2:16 PM, Hartmann, O. wrote: On Wed, 3 Feb 2021 17:34:24 +0100 Guido Falsi via freebsd-current wrote: On 03/02/21 17:02, John Baldwin wrote: On 2/2/21 10:16 PM, Hartmann, O. wrote: On Mon, 1 Feb 2021 03:24:45 + Rick Macklem wrote: Rick Macklem wrote: Guido Falsi wrote

Re: gib/em driver problems?

On Wed, Feb 03, 2021 at 08:23:49PM -0800, John Kennedy wrote: > On Wed, Feb 03, 2021 at 06:40:50PM -0800, joe mcguckin wrote: > > I went out and purchased a PCIe ethernet card - it uses the em driver. The > > system > > boots and it is em0. > > > > It works f

Re: gib/em driver problems?

On Wed, Feb 03, 2021 at 06:40:50PM -0800, joe mcguckin wrote: > I went out and purchased a PCIe ethernet card - it uses the em driver. The > system > boots and it is em0. > > It works fine in 100Mb mode, but in gigabit mode, it does not pass any > traffic although ifconfig reports > the card

Re: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?

in serf (an Apache library used by subversion). It would also affect any other software using serf. The serf in ports will also have to be patched. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo

Re: ZFS feature compatibility?

ead I had a while ago: Date: Thu, 9 Jul 2020 14:18:54 -0700 From: John Kennedy To: Kyle Evans Cc: FreeBSD-STABLE Mailing List Subject: Re: 12.1p7 no longer boots after doing zpool upgrade -a The "new" documentation was here: https://wiki.free

Re: ZFS feature compatibility?

On Mon, Jan 25, 2021 at 04:17:18PM -0500, mike tancsa wrote: > Is there a way to check from the bin if its the right version ? strings > of the file doesnt seem to show anything useful.  I wonder if its the > UEFI boot that got missed ?  Just > > gpart bootcode -p /boot/boot1.efifat -i 1ada8 >

Re: Can In-Kernel TLS (kTLS) work with any OpenSSL Application?

t;knew" it was using KTLS and would use direct read/write after letting OpenSSL (or a similar library) handle the handshake. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscr

Re: service -e doesn't really sort does it? the cool tip is slightly off

issing detail, maybe: If you want to get a list of all services started when FreeBSD boots in the order they are started, enter "service-e". ? -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/

Re: 13-alpha2 libncurses removal breaks ports build

On Sun, Jan 24, 2021 at 02:53:41PM +, Kostya Berger wrote: > OK, building ports against a clean installation of 13.0-ALPHA2 has no problem > with ncurses. > But devel/glib20 fails for no obvious reason closer to the end of building > process... I just wonder: do I need to report this to

Re: Which branch in git is 13.0-current?

On Sat, Jan 23, 2021 at 06:34:58PM -0700, Russell L. Carter wrote: > So has anyone tracking stable/12 and ports successfully completed the > git checkout stable/13; make buildworld; make installworld; mergemaster > drill? I see I can checkout stable/13. > > Do make.conf | src.conf | GENERIC have

Re: 13-alpha2 libncurses removal breaks ports build

On Sat, Jan 23, 2021 at 10:40:57PM +, Kostya Berger wrote: > Hi everyone,I don't seem to find any mentioning in the /usr/ports/UPDATING > about how one should handle the removal of libncurses.so.9 from base. > Source UPDATING only says:ncurses installation has been modified to only keep >

Re: boot loader blank screen

On Fri, Jan 15, 2021 at 03:51:38PM +0200, Toomas Soome wrote: > Could you please check latest current now?:) Success! With main-c255999-g0bc776f3da70, I've been able to comment out the screen.textmode=0 (so, back to the default like I originally was).

Re: boot loader blank screen

On Wed, Jan 06, 2021 at 02:19:12PM -0800, John Kennedy wrote: > I saw your commit of 99870c70bac7 (loader: rewrite vidc_install_font), > 31c2bcad7e44 (loader: remove left over call to unsetenv()), and belatedly > babda0952f8355a89b3241d5e8943c7da0fa4f6b (hw.vga.textmode -> scr

Re: boot loader blank screen

On Wed, Jan 06, 2021 at 02:40:32PM -0800, Mark Millard wrote: > ... screen.textmode="0" works, including with screen.font="8x16" . There > is a difference, in that it displays some material at the very beginning > that it was not displaying since the recent problems started (until now > or so).

Re: boot loader blank screen

On Tue, Jan 05, 2021 at 07:09:22PM -0800, John Kennedy wrote: > On Wed, Jan 06, 2021 at 12:46:08AM +0200, Toomas Soome wrote: > > I think, I got it fixed (at least idwer did confirm for his system, > > thanks). If you can test this patch: > > http://148-52-235-80.sta.

Re: boot loader blank screen

On Wed, Jan 06, 2021 at 12:46:08AM +0200, Toomas Soome wrote: > I think, I got it fixed (at least idwer did confirm for his system, thanks). > If you can test this patch: > http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch >

Re: git non-time-sequential logs

On 1/4/21 8:52 AM, John Kennedy wrote: > On Mon, Jan 04, 2021 at 08:22:56AM -0800, John Kennedy wrote: >> The git logs in /usr/src aren't time-sequential, so maybe I shouldn't trust >> those dates above (I pulled it ~Jan 3rd and let it compile overnight), but >> I'm going to r

Re: boot loader blank screen

Op ma 4 jan. 2021 om 23:59 schreef Toomas Soome : > the 58661b3ba9eb should hopefully fix the loader text mode issue, it would be > cool if you can verify:) No, sorry... On Tue, Jan 05, 2021 at 02:58:02AM +0100, Idwer Vollering wrote: > I had more success with this patch, applied on top of

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

r-Collision_Attack_%E2%80%93_first_practical_chosen-prefix_attack [3] https://en.wikipedia.org/wiki/Collision_attack#Chosen-prefix_collision_attack -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." __

Re: git non-time-sequential logs

On Mon, Jan 04, 2021 at 07:59:12PM +0100, Franco Fichtner wrote: > The author date stays the same, the committer date is sequential except > that it indicates the local time of the committer doing the cherry-pick > instead of the central server as opposed to svn: > > # git log --format=fuller

Re: boot loader blank screen

On Mon, Jan 04, 2021 at 11:39:08AM -0700, Warner Losh wrote: > Yea, this is a feature that needs to be fixed since black on black text is > a show stopper :( Ah, this is part of the "Terminal colours in current" thread? I saw that, but didn't correlate it with default black-on-black text. It

Re: boot loader blank screen

On Mon, Jan 04, 2021 at 06:30:38PM +0200, Toomas Soome wrote: > Yes, it is known defect, and I???m searching for cause; the issue is with > /boot/loader and BIOS text mode (unfortunately I have the usual ???but it is > working for me??? case). For workaround, you can try to either: 1 (blind) >

git non-time-sequential logs

On Mon, Jan 04, 2021 at 08:22:56AM -0800, John Kennedy wrote: > The git logs in /usr/src aren't time-sequential, so maybe I shouldn't trust > those dates above (I pulled it ~Jan 3rd and let it compile overnight), but > I'm going to repull all the sources and recompile, just in case.

boot loader blank screen

This is a little weird. Somewhere between 13.0-g2ff66a915526 (Dec 30th) and -gd03fd8ede2c4 (Dec 29th), I've lost the screen in the boot loader. This is really weird because I didn't update the boot loader (in quite a while, actually), but I suppose it might drag some stuff off of the disk and

Re: Enabling AESNI by default

8crypto(4)) at that point, but aesni in GENERIC makes sense right now (and I'd say to MFC it to 12). armv8crypto in arm64 GENERIC will make sense once AES-XTS support (currently in a review) lands. -- John Baldwin ___ freebsd-current@freebsd.org mailing

Re: Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch

ess region for config register read/write as this code does: https://github.com/torvalds/linux/blob/master/drivers/pci/controller/vmd.c#L339 Also, that means the vm_bus.c can't hardcode reading from bus 0. Instead, vmd(4) might need to export an IVAR to vmd_bus(4) that is the starting

Re: Enabling AESNI by default

tting a bug in a NIC driver for example. I think netstat -s would be a better place to start to try to debug this. > https://github.com/opnsense/core/issues/4415 -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/ma

Re: PCIe Root Port/Bus Not Detected in VMD

config() is correct. -- -- John Baldwin ___ 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: FreeBSD src repo transitioning to git this weekend

> > One cannot sign or verify anything without knowing gpg first :) snapaid was designed to make it even easier... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." _

Re: # Fssh_packet_write_wait: Connection to 77.183.250.3 port 22: Broken pipe

On Wed, Dec 30, 2020 at 08:04:03AM +0100, Hartmann, O. wrote: > On recent 12-STABLE, 12.1-RELENG and 12.2-RELENG I face a very nasty problem > which > occured a while ago after it seemed to have vanished for a while: running ssh > in a xterm > on FreeBSD boxes as mentioned at the beginning ends

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

better security like this IS because of the actions of the NSA... I used to get lunch on a weekly basis across the street from one of the early revealed NSA wiretap rooms. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I wil

Re: git and the loss of revision numbers

each time you update. Then you can easily go back to that tag by name instead of having to look up the hash. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send a

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

so, the cost of the attack is not great ($45k), considering the recent SolarWinds supply chain attack, being able to smuggle a modified file into a git repo, say an OS's build server, such that the tools don't know the tree is modified is a real problem... -- John-Mark Gurney

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

hen you have the job of verifying the doc repo to make sure that the keys you have is valid, where does the root of trust come from there? Not saying it isn't possible, it's just a LOT of work to make it useful... -- John-Mark Gurney Voi

Re: git and the loss of revision numbers

> >\ \ \ local modifications > > \ \hash > > \ commit count > >branch -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." __

Re: panic: Assertion pgrp->pg_jobc > 0 failed at kern_proc.c:816

On 12/28/20 12:24 PM, John Baldwin wrote: > I got this panic again today in a VM when quitting a gdb > session after killing a child process via 'kill'. > > panic: Assertion pgrp->pg_jobc > 0 failed at > /git/bhyve/sys/kern/kern_proc.c:816 > cpuid = 1 > time = 160918

panic: Assertion pgrp->pg_jobc > 0 failed at kern_proc.c:816

094001a00, frame=0xfe0094671b00) at /git/bhyve/sys/kern/kern_fork.c:1069 #6 #7 0x0008007b71aa in ?? () kgdb can't find the panicking process due to the zombproc removal, so I will have to go work on kgdb to recover from that change. :( -- Joh

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

On Mon, Dec 21, 2020 at 12:47:38PM -0800, John Kennedy wrote: > On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote: > > The FreeBSD project will be moving it's source repo from subversion to git > > starting this this weekend. The docs repo was moved 2 weeks ago. The

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

w you need to know what time period each key was valid for, otherwise a compromised key could be used to insert malicious changes into your/the tree... Then there's also the point that the repo is (looks like it) using SHA-1 hashes, which are effectively broken, so depending upon them to validate t

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

Attributions are really confusing at this point... On 2020-Dec-22, at 13:06, bob prohaska wrote: > bob@www:/usr % git clone cgit.freebsd.org -b stable/12 freebsd-src On 2020-Dec-22, at 13:31, Mark Millard wrote: > I cloned FreeBSD's src.git via: > git clone -o freebsd --config >

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote: > The FreeBSD project will be moving it's source repo from subversion to git > starting this this weekend. The docs repo was moved 2 weeks ago. The ports > repo will move at the end of March, 2021 due to timing issues. ... I filed Bug

Re: (239489) buildkernel fails if PORTS_MODULES= includes openzfs-kmod

On Sun, Dec 13, 2020 at 06:49:07PM +, Graham Perrin wrote: > Not entirely moot; for > the description for > the most recent commit refers to building on 13-CURRENT Well, it's a port, so they'll want it to compile if nothing else. It just

Re: (239489) buildkernel fails if PORTS_MODULES= includes openzfs-kmod

On Sun, Dec 13, 2020 at 08:19:30AM +, Graham Perrin wrote: > Please: is there some way to include openzfs-kmod at buildkernel time? > > To work around > I habitually > remove openzfs-kmod from /etc/src.conf _and_ modify

Re: AMNESIA:33 and FreeBSD TCP/IP stack involvement

On Wed, Dec 09, 2020 at 06:58:49AM +0100, Hartmann, O. wrote: > Hello, > I've got a question about recently discovered serious vulnerabilities > in certain TCP stack implementations, designated as AMNESIA:33 (as far > as I could follow the recently made announcements and statements, > please see,

Re: AMNESIA:33 and FreeBSD TCP/IP stack involvement

s in that report as well, so it isn't like the report found security vulnerability in every TCP/IP stack they tested. The best way to have confidence is to pay people to analyize and verify that the FreeBSD TCP/IP stack is secure, just as it is w/ any critical code th

Re: KLD zfs.ko: depends on kernel - not available or version mismatch

On Tue, Dec 08, 2020 at 07:10:26PM +0100, Alban Hertroys wrote: > > You didn't say that you've installed the new kernel, which at least starts > > you down the road towards a driver/kernel mismatch. You presumably have a > > non-ZFS boot+root. > > I???m fairly sure I did, actually. > > Last

Re: KLD zfs.ko: depends on kernel - not available or version mismatch

On Tue, Dec 08, 2020 at 08:56:25AM +0100, Alban Hertroys wrote: > This seems to have gotten lost in the moderate queue, but after a week I am > no closer to a solution, so here???s a resend: > > I???ve been trying to get a fresh world running (for the eventual purpose of > running amdgpu

Re: immediate panic after nvidia load

On Tue, Nov 10, 2020 at 05:58:15AM -0800, David Wolfskill wrote: > What I do on my laptop is build FreeBSD from source, with he directive > in /etc/src.conf so the x11/nvidia0driver kmod is rebuilt during "make > buildkernel" (and installed during "make installkernel"). > > That's simple and

Re: r367415: can't load linuxulator, link_elf_obj: symbol sdt_provider_linuxulator undefined

On Fri, Nov 06, 2020 at 08:35:41AM -0800, John Kennedy wrote: > Trying a run against r367420 with the LIN_SDT_PROVIDER_DECLARE() commented > out. Not the solution. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/m

Re: r367415: can't load linuxulator, link_elf_obj: symbol sdt_provider_linuxulator undefined

On Fri, Nov 06, 2020 at 08:35:41AM -0800, John Kennedy wrote: > I had this crop up this morning r367410, while yesterdays build against > r367379 seemed fine. I think this is an issue because of r367395: > > linux(4): Deduplicate unimpl/dummy syscall handlers > > If

r367415: can't load linuxulator, link_elf_obj: symbol sdt_provider_linuxulator undefined

I had this crop up this morning r367410, while yesterdays build against r367379 seemed fine. I think this is an issue because of r367395: linux(4): Deduplicate unimpl/dummy syscall handlers If I tracked it down correctly, the LIN_SDT_PROVIDER_DECLARE(LINUX_DTRACE) in

Re: DISTDIR name collision...

John-Mark Gurney wrote this message on Thu, Nov 05, 2020 at 16:13 -0800: > I just discovered that we have a variable name colission between the > FreeBSD base repo, and the ports tree. DISTDIR is used by the ports > repo for: > # DISTDIR - Where to search for and

DISTDIR name collision...

someone figure out what we should do in this case? This was discovered because ezjail-admin sets DISTDIR for ports, but it was breaking my -DNO_ROOT installworld by putting the METALOG in an incorrectly documented place (since fixed)... -- John-Mark Gurney Voice: +1

Re: copyright notice question

same > terms as the extant one, but if that is what is appropriate for the project..) I'd add both the above notice, but also your own copyright at the top... You don't need to add your own copyright, but if you do, the by Rick Macklem isn't needed in the modified from notice (and IMO, an unne

RFC: allow first boot config from msdos partition

are in here: https://reviews.freebsd.org/D26713 Thanks! -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing

Re: Deprecating ftpd in the FreeBSD base system?

Rodney W. Grimes wrote this message on Thu, Sep 17, 2020 at 10:53 -0700: > > FTP is firewall unfriendly. > > Passive mode solved that decades ago. Requires that the server not be behind a firewall or port forwarding as well.. -- John-Mark Gurney Voice

Re: Deprecating ftpd in the FreeBSD base system?

> threats. And I really dislike when people want to make sure that their unique case that less than a percent of people would every hit blocks the security improvements for the majority of people... I've given up on a number of security improvements in FreeBSD because of this attitude..

Re: Deprecating ftpd in the FreeBSD base system?

onnection (or that can > tolerate an insecure one). Do we have a way for the admin/root to set fetch's policy to block FTP and HTTP? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." _

Re: CFT: major update to if_ure

John-Mark Gurney wrote this message on Sat, Jul 25, 2020 at 16:13 -0700: > Hello, > > I'd like people who have ure (RealTek) based USB devices to test > review D25809[0]. > > This update adds support for: > - HW VLAN tagging > - HW checksum offload for IPv4 and IPv6 &g

Re: OpenZFS and L2ARC

e any output, I'm not >> likely to use it too often ... > > Update: I have created a fork of zfs-stats to work on: > > https://github.com/stesser/zfs-stats > > Initial change is to work around the long delay mentioned above and to > use the correct name for the vd

Re: rfc: should extant TLS connections be closed when a CRL is updated?

user may want to turn that off if it's disruptive to their server. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailin

Re: CFT: major update to if_ure

Ganbold Tsagaankhuu wrote this message on Wed, Aug 19, 2020 at 16:27 +0800: > On Tue, Jul 28, 2020 at 2:35 AM John-Mark Gurney wrote: > > > Ganbold Tsagaankhuu wrote this message on Mon, Jul 27, 2020 at 18:29 +0800: > > > On Mon, Jul 27, 2020 at 5:14 AM John-M

Re: Problem compiling chromium

8, in abspath >     path = os.fspath(path) > TypeError: expected str, bytes or os.PathLike object, not NoneType > ninja: build stopped: subcommand failed. > *** Error code 1 > > Stop. > make[1]: stopped in /usr/ports/www/chromium Are you sure that chromium is Python 3 cle

Re: CFT: major update to if_ure (patch did not apply cleanly for head -r363510) (example PowerMac problem?)

Mark Millard wrote this message on Mon, Jul 27, 2020 at 17:15 -0700: > On 2020-Jul-27, at 16:43, Mark Millard wrote: > > > On 2020-Jul-26, at 18:20, John-Mark Gurney wrote: > > > >> Mark Millard wrote this message on Sat, Jul 25, 2020 at 19:13 -0700: > >&

Re: CFT: major update to if_ure

Ganbold Tsagaankhuu wrote this message on Mon, Jul 27, 2020 at 18:29 +0800: > On Mon, Jul 27, 2020 at 5:14 AM John-Mark Gurney wrote: > > > Ganbold Tsagaankhuu wrote this message on Sun, Jul 26, 2020 at 11:05 +0800: > > > On Sun, Jul 26, 2020 at 7:13 AM John-M

Re: CFT: major update to if_ure (patch did not apply cleanly for head -r363510)

should work now.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/

Re: CFT: major update to if_ure

Ganbold Tsagaankhuu wrote this message on Sun, Jul 26, 2020 at 11:05 +0800: > On Sun, Jul 26, 2020 at 7:13 AM John-Mark Gurney wrote: > > > Hello, > > > > I'd like people who have ure (RealTek) based USB devices to test > > review D25809[0]. > > > > T

CFT: major update to if_ure

depending upon TCP or UDP, which is a significant improvement over the previous 91Mbps (~8kint/sec*1500bytes/packet*1packet/int). Thanks. [0] https://reviews.freebsd.org/D25809 -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done

Re: somewhat reproducable vimage panic

John-Mark Gurney wrote this message on Thu, Jul 23, 2020 at 16:49 -0700: > Kristof Provost wrote this message on Thu, Jul 23, 2020 at 11:02 +0200: > > On 23 Jul 2020, at 11:00, Bjoern A. Zeeb wrote: > > > On 23 Jul 2020, at 8:09, Kristof Provost wrote: > > > > > &g

Re: somewhat reproducable vimage panic

Kristof Provost wrote this message on Thu, Jul 23, 2020 at 11:02 +0200: > On 23 Jul 2020, at 11:00, Bjoern A. Zeeb wrote: > > On 23 Jul 2020, at 8:09, Kristof Provost wrote: > > > >> On 23 Jul 2020, at 9:19, Kristof Provost wrote: > >>> On 23 Jul 2020, at 0:1

Re: somewhat reproducable vimage panic

Bjoern A. Zeeb wrote this message on Wed, Jul 22, 2020 at 20:43 +: > On 22 Jul 2020, at 19:34, John-Mark Gurney wrote: > > > John-Mark Gurney wrote this message on Tue, Jul 21, 2020 at 23:05 > > -0700: > >> Peter Libassi wrote this message on Wed,

Re: somewhat reproducable vimage panic

John-Mark Gurney wrote this message on Tue, Jul 21, 2020 at 23:05 -0700: > Peter Libassi wrote this message on Wed, Jul 22, 2020 at 06:54 +0200: > > Is this related to > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234985 > > <https://bugs.freebsd.org/b

Re: somewhat reproducable vimage panic

ks like in_multi isn't holding an interface or address lock waiting for things to free up... > > 21 juli 2020 kl. 22:23 skrev John-Mark Gurney : > > > > Marko Zec wrote this message on Tue, Jul 21, 2020 at 11:31 +0200: > >> On Tue, 21 Jul 2020 02:16:55 -0700 > >> John-Ma

Re: somewhat reproducable vimage panic

Marko Zec wrote this message on Tue, Jul 21, 2020 at 11:31 +0200: > On Tue, 21 Jul 2020 02:16:55 -0700 > John-Mark Gurney wrote: > > > I'm running: > > FreeBSD test 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r362596: Thu Jun 25 > > 05:02:51 UTC 2020 > > r...@releng1

somewhat reproducable vimage panic

in fork_exit ( callout=0x80c26200 , arg=0x81cf4f70 , frame=0xfe0049e99b80) at /usr/src/sys/kern/kern_fork.c:1052 #10 (kgdb) I have the core files so I can get additional information. Let me know if you need any additional information. -- John-Mark Gurney

test suite for NIC features...

Has anyone compiled a script/test suite for testing various NIC features to make sure they work/function properly? That is, being able to run a couple interfaces back to back, and turn off the features off on one, and make sure things like checksum offload and the like work properly? -- John

Re: slow USB 3.0 on -current

Hans Petter Selasky wrote this message on Mon, Jul 13, 2020 at 10:50 +0200: > On 2020-07-13 03:02, John-Mark Gurney wrote: > > MB means megabytes.. I would use Mbps for bits... so, on Win10 and > > NetBSD, I'm able to get 100 MBytes/sec on Win10/NetBSD, and FreeBSD, > > I'm

Re: slow USB 3.0 on -current

Mark Millard wrote this message on Mon, Jul 13, 2020 at 00:44 -0700: > On 2020-Jul-12, at 21:51, John-Mark Gurney wrote: > > > Mark Millard wrote this message on Sun, Jul 12, 2020 at 18:26 -0700: > >> John-Mark Gurney jmg at funkthat.com wrote on > >>

Re: slow USB 3.0 on -current

Mark Millard wrote this message on Sun, Jul 12, 2020 at 18:26 -0700: > John-Mark Gurney jmg at funkthat.com wrote on > Sat Jul 11 22:44:36 UTC 2020 : > > > I'm having issues getting good ethernet performance from a USB ethernet > > adapter (ure) under FreeBSD on an HP El

Re: Is there any error checking on swap?

Xin Li wrote this message on Sun, Jul 12, 2020 at 15:06 -0700: > > > On 7/12/20 12:29 AM, John-Mark Gurney wrote: > > bob prohaska wrote this message on Sat, Jul 11, 2020 at 20:33 -0700: > >> Is there any error checking on swap traffic, along the lines of > &

Re: slow USB 3.0 on -current

Kevin Oberman wrote this message on Sun, Jul 12, 2020 at 16:24 -0700: > On Sun, Jul 12, 2020 at 2:55 PM John-Mark Gurney wrote: > > > Hans Petter Selasky wrote this message on Sun, Jul 12, 2020 at 09:57 +0200: > > > On 2020-07-12 00:44, John-Mark Gurney wrote: > > >

Re: slow USB 3.0 on -current

Hans Petter Selasky wrote this message on Sun, Jul 12, 2020 at 09:57 +0200: > On 2020-07-12 00:44, John-Mark Gurney wrote: > > Hello, > > > > I'm having issues getting good ethernet performance from a USB ethernet > > adapter (ure) under FreeBSD on an HP EliteDesk 705 G

Re: Is there any error checking on swap?

bob prohaska wrote this message on Sun, Jul 12, 2020 at 08:37 -0700: > On Sun, Jul 12, 2020 at 12:29:12AM -0700, John-Mark Gurney wrote: > > bob prohaska wrote this message on Sat, Jul 11, 2020 at 20:33 -0700: > > > Is there any error checking on swap traffic, along the lines o

Re: Is there any error checking on swap?

doesn't: https://svnweb.freebsd.org/base/head/sys/vm/swap_pager.c?annotate=361965#l1389 -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freeb

slow USB 3.0 on -current

that happening. Has anyone else seen this issue? Ideas or thoughts on how to resolve the performance issues? Thanks. [1] https://support.hp.com/us-en/document/c04834953 -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have

Re: weird Ctrl-T debug messages

personally, e.g., while running commands like dd[0], cp, mv, > poudriere etc.), not for getting debug output. I agree with this. > Question: Speaking of discovering the feature, wouldn't it make sense > to document this tunable on the stack(9) and/or tty(4) man page(s)? This sounds l

Re: acpi timer reads all ones [Was: efirtc + atrtc at the same time]

On 5/27/20 2:05 PM, Hans Petter Selasky wrote: > On 2020-05-27 15:41, Justin Hibbits wrote: >> On Wed, 27 May 2020 06:27:16 -0700 >> John Baldwin wrote: >> >>> On 5/27/20 2:39 AM, Andriy Gapon wrote: >>>> On 27/05/2020 11:13, Andriy Gapon wrote: &

Re: acpi timer reads all ones [Was: efirtc + atrtc at the same time]

multi-pass and to resume all the bridges first before trying to resume leaf devices (including timers), but that's a fair bit of work. It might be that we just need to resume timer interrupts later after the new-bus resume (I think we currently do it before?), though the reason for that

Re: acpi timer reads all ones [Was: efirtc + atrtc at the same time]

fffe00a7a19ad0 >> amd64_syscall() at amd64_syscall+0x140/frame 0xfe00a7a19bf0 >> fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe00a7a19bf0 >> >> I am not sure if this is just a coincidence but it appears as if a write to >> some >> PCI configuratio

<    1   2   3   4   5   6   7   8   9   10   >