Re: Weird mouse behaviour
In message <6dfad31c-68f2-c38f-28ac-0696e73b4...@daemonic.se>, Niclas Zeising writes: >On 2020-04-27 08:03, Malcolm Matalka wrote: >> I saw that there was another thread on this and I wanted to throw my >> experience in: my mouse was sluggish and tap-to-click did not work. I >> set the evdev mask back to 3 and it worked. >> >> I am on a Dell XPS 13. > >Hi! >Is this on CURRENT? When using X? >Can you verify that you have xf86-input-libinput installed? In my case yes, this is CURRENt and I have xf86-input-libinput-0.29.0 In my case, with the default sysctl kern.evdev.rcpt_mask=12 CTRL + middle button would not activate the menu in xterm. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: Weird mouse behaviour
On 2020-04-27 08:03, Malcolm Matalka wrote: I saw that there was another thread on this and I wanted to throw my experience in: my mouse was sluggish and tap-to-click did not work. I set the evdev mask back to 3 and it worked. I am on a Dell XPS 13. Hi! Is this on CURRENT? When using X? Can you verify that you have xf86-input-libinput installed? You can change sensitivity and enable tap to click using xinput. 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: Weird mouse behaviour
In message <86imhlv518@gmail.com>, Malcolm Matalka writes: >I saw that there was another thread on this and I wanted to throw my >experience in: my mouse was sluggish and tap-to-click did not work. I >set the evdev mask back to 3 and it worked. Thanks! That helped a lot with my sanity on my T480 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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"
Weird mouse behaviour
I saw that there was another thread on this and I wanted to throw my experience in: my mouse was sluggish and tap-to-click did not work. I set the evdev mask back to 3 and it worked. I am on a Dell XPS 13. ___ 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: PCIe NVME drives not detected on Dell R6515
I don't know what is with Scott. I hope he is well. Is there somebody else who can help me with this issue? Scott wrote there are hotplug PCIe buses not probed during boot process. I am not a developer so I cannot move forward alone. Kind regards Miroslav Lachman On 2020-04-17 23:30, Scott Long wrote: On Apr 17, 2020, at 3:07 PM, Miroslav Lachman <000.f...@quip.cz> wrote: Scott Long wrote on 04/17/2020 23:04: On Apr 17, 2020, at 2:45 PM, Miroslav Lachman <000.f...@quip.cz> wrote: Scott Long wrote on 04/17/2020 22:17: On Apr 17, 2020, at 1:47 PM, Miroslav Lachman <000.f...@quip.cz> wrote: Kurt Jaeger wrote on 04/17/2020 21:44: Hi! pciconf -lBc pcib12 pciconf -lBc pcib13 Printscreen attached. Attachments are stripped from the list -- can you put them somewhere online ? Here it is https://ibb.co/c1dZrTf Miroslav Lachman Ok, the bridges know about their downstream bus numbers, but I see nothing that suggests that they’re being probed. The next step would be bootverbose, but that’s going to be a lot of output to collect in screen captures. Over 3000 lines long but I finally managed to make SOL work so I have it as text! https://pastebin.pl/view/90fdaafb This helped a lot, thanks. It looks like these PCIe buses are marked as being hotplug, and for some reason we’re not probing them. At this point, I’d need to feed you some kernel patches that will dump out more info, but you’d have to compile them and get them onto your boot media. Is that a possibility? Currently I have all machines on 11.3 (where I can rebuild kernel without problem) If CURRENT is required I would need to setup some CURRENT VM in VirtualBox. Can you send me some link to documentation who should I create new ISO after rebuild? I don’t know of any docs for doing custom releases, and it looks like it’s harder than it used to be to insert custom patches. That said, I recommend doing the following on your 11.x build system: 1. Do a clean `make buildworld` with an up-to-date tree 2. change into the `release` directory that you just did the buildworld from 3. `sudo make release NOPORTS= NODOC= CHROOTDIR=/usr/tmp/release SRCBRANCH="base/stable/11@rHEAD”` You can set CHROOTDIR to whatever you want that has a few GB of space, but remember where you’ve set it for later steps. This will build a release with stock sources. Let it complete, both to prepare for the next step and to ensure that it works. It’ll take an hour or two depending on your machine speed 4. Take the patch that I’ll send you shortly and apply it to $CHROOTDIR/usr/src 5. `sudo make memstick NOPORTS= NODOC= SRC_UPDATE_SKIP= CHROOTDIR=/usr/tmp/release` Scott ___ 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: r358503 breaks reroot
On 2020-04-26 18:16, Ross Gohlke wrote: As of r358503, *reboot -r* no longer works for me. This is only tested on amd64. I produced a vanilla mini-memstick image each for r358502 and r358503. I booted each in bhyve in single user mode and ran *reboot -r*. The first works as expected, the second halts with: kern_symlink /dev -> / returns 20 Images (to be deleted when this is resolved): * https://club.bisd.ro/site/uv/FreeBSD-13.0-CURRENT-amd64-r358502.img * https://club.bisd.ro/site/uv/FreeBSD-13.0-CURRENT-amd64-r358503.img SHA1 checksums (via https://club.bisd.ro/site/uvlist): * r358502 - c968c4a71c270561c1b0a02e2b2281cbbf8787d7 * r358503 - b5d1abd6b3f3e009c2b54198d76d71a8640807a6 External bhyve commands: * sh /usr/share/examples/bhyve/vmrun.sh -c 1 -m 1024M -d /mnt/FreeBSD-13.0-CURRENT-amd64-r358502.img reroot * sh /usr/share/examples/bhyve/vmrun.sh -c 1 -m 1024M -d /mnt/FreeBSD-13.0-CURRENT-amd64-r358503.img reroot Internal bhyve commands: 1. Press 2 for single user mode. 2. When prompted, press Return. 3. Issue command: reboot -r To exit the first case: 1. Press Return. 2. Select Shell. 3. Issue command: shutdown -p now To exit the second case, issue the following command in a second terminal: bhyvectl --destroy --vm=reroot Any suggested workarounds besides reverting to r358502? Any help appreciated, Ross Forgot to refresh server and image links above were unavailable, sorry. They should work now. ___ 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"
r358503 breaks reroot
As of r358503, *reboot -r* no longer works for me. This is only tested on amd64. I produced a vanilla mini-memstick image each for r358502 and r358503. I booted each in bhyve in single user mode and ran *reboot -r*. The first works as expected, the second halts with: kern_symlink /dev -> / returns 20 Images (to be deleted when this is resolved): * https://club.bisd.ro/site/uv/FreeBSD-13.0-CURRENT-amd64-r358502.img * https://club.bisd.ro/site/uv/FreeBSD-13.0-CURRENT-amd64-r358503.img SHA1 checksums (via https://club.bisd.ro/site/uvlist): * r358502 - c968c4a71c270561c1b0a02e2b2281cbbf8787d7 * r358503 - b5d1abd6b3f3e009c2b54198d76d71a8640807a6 External bhyve commands: * sh /usr/share/examples/bhyve/vmrun.sh -c 1 -m 1024M -d /mnt/FreeBSD-13.0-CURRENT-amd64-r358502.img reroot * sh /usr/share/examples/bhyve/vmrun.sh -c 1 -m 1024M -d /mnt/FreeBSD-13.0-CURRENT-amd64-r358503.img reroot Internal bhyve commands: 1. Press 2 for single user mode. 2. When prompted, press Return. 3. Issue command: reboot -r To exit the first case: 1. Press Return. 2. Select Shell. 3. Issue command: shutdown -p now To exit the second case, issue the following command in a second terminal: bhyvectl --destroy --vm=reroot Any suggested workarounds besides reverting to r358502? Any help appreciated, Ross ___ 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: Compiling MOD_CC into kernel (TCP congestion control)?
On Sat, 25 Apr 2020 22:13:08 +0200 Michael Tuexen wrote: > > On 25. Apr 2020, at 19:28, Hartmann, O. > > wrote: > > > > On a firewall/router project of ours I try to experiment with > > several options/algorithms for mod_cc(4). The kernel is compiled > > statically, so that no kernel module can be loaded at runtime, > > therefor I need to compile the different modules mod_cc into the > > kernel. > > > > The manpage mod_cc(4) states: " ... Algorithm modules can be > > compiled into the kernel or loaded as kernel modules ..." > > > > Trying to figure out which manpage could hold the necessary > > information how to proceed with compiling those modules statically > > into the kernel, I tried tcp(4), mod_cc(4) and tried to get some > > informations from /usr/src/sys/conf/NOTES - without any succes. > > > > Can someone point me to the correct manpage to perform the desired > > task? > Hi, > > I can't point you to a man page, but do you get what you want if you > add lines like the existing one > netinet/cc/cc_newreno.c optional inet | inet6 > to sys/conf/files for the CC modules you would like to get compiled > in your kernel? > > Best regards > Michael > > > > Thanks in advance, > > kind regards > > > > O. Hartmann > Hello. Thank you very much for the hint. Doing like suggested make me feel back in the times of "config" for BSD kernel configurations ;-) Well, as I stated in the original question, the subject is a littel project where we'd like to compile those modules into the kernel. That is a requirement given by higher order (no modules available, everything needed needs to be static in the kernel, no loading/unloading of modules allowed for security purposes). oh pgpAzP0j2iJYM.pgp Description: OpenPGP digital signature
Bridge project update (Week of April 21st)
Hi, This is likely the last update. The main change (and the final test case) has been committed: https://svnweb.freebsd.org/changeset/base/360345 (And https://svnweb.freebsd.org/changeset/base/360346) I intend to MFC this to stable/12 in due course, but it will do no hard to let it get a bit more testing in CURRENT first. The Foundation wrote about this project here: https://www.freebsdfoundation.org/blog/500-if_bridge-performance-improvement/ There will be an in-depth article on this work in the upcoming May/June issue of FreeBSD Journal. Best regards, Kristof Provost ___ 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: How to enable tcp bbr in FreeBSD???
> On 26. Apr 2020, at 15:09, Randall Stewart wrote: > > I am thinking that this really needs to have > a deeper support in the transport. > > I see that OOB is even in socket_dgram process and there > are comments in there that indicate it may be a problem.. I > know UDP does not support it. > > So I think what is needed here is > > 1) a new pru_method that at send/rcv it can query if PRUS_EOF PRUS_OOB > is supported. Not sure what you need to check for PRUS_EOF? > 2) For UDP either query would return false. > 3) For TCP this would resolve to a stack specific query. For the > freebsd stack, it would return true for both, for Rack or BBR > you would get True for PRUS_EOF and False for PRUS_OOB. This way > you could capture an error in any case by adding a check at the > top of send/recv and immediately return an error as appropriate. > 4) I would also think like all pru methods, you get a default of true/true > so that way I guess unix domain sockets would continue as they are (not > sure if they support these or not I should probably look) Hmm. Thinking about this: I guess we want to focus on TCP, since my understanding is that the problem is that some TCP stacks do support OOB, some don't. So you can't query that right now via a TCP value. So couldn't we check in tcp_usr_send() if the stack currently being used for the socket support OOB? It would be a stack specific value. Such a change should fix this issue and does not impact other protocols. Best regards Michael > > > R > >> On Apr 26, 2020, at 8:55 AM, Randall Stewart wrote: >> >> Sure.. >> >> I will take a look at it. >> >> R >> >>> On Apr 26, 2020, at 8:51 AM, Michael Tuexen >>> wrote: >>> >>> >>> On 26. Apr 2020, at 13:34, Randall Stewart via freebsd-transport wrote: I have pulled down the reproducers.. one thing to note is they are all rack (though it could be that the problems are also in BBR). And of course FreeBSD is behind NF in rack at least. I need to work on getting things updated.. one thing Michael, both Rack and BBR in NF have lost the OOB handling. Please do not commit any more changes to Rack .. since that work has already been done. >>> I understand that the support of MSG_OOB is gone, but if you want >>> to return an error to the user when he uses MSG_OOB, you need to >>> trigger this error in the protocol specific code. >>> >>> I don't think we can return an error in all cases (also for the >>> default stack), since that would change existing behaviour. >>> >>> I leave this up to you. >>> >>> Best regards >>> Michael R > On Apr 26, 2020, at 7:28 AM, Randall Stewart wrote: > > This is actually the first I have heard of these bugs… > > I will have look at them Mark. > > R > >> On Apr 24, 2020, at 10:23 AM, Mark Johnston wrote: >> >> On Fri, Apr 24, 2020 at 03:15:08PM +0100, Tom Jones wrote: >>> r...@freebsd.org >>> Bcc: >>> Subject: Re: How to enable tcp bbr in FreeBSD??? >>> Reply-To: >>> In-Reply-To: <6042155a-297b-d85e-1d64-24d93da32...@gmail.com> >>> >>> >>> ... snip ... Maybe it is not ready for prime time, i do not know why it is not in the default build. Maybe ask the committer. >>> >>> I have added rrs@ in cc and the freebsd-transport list. >>> >>> Does anyone know if there are plans to enable alternate TCP stacks in >>> generic? >>> >>> Is there a stability point we need to hit first? >> >> There are a couple of open bugs found by syzkaller (complete with >> reproducers) that appeared when I enabled the alternate TCP stacks: >> >> https://syzkaller.appspot.com/bug?id=986b4cecd84439df9794bda1a45d9cf0f50356fe >> https://syzkaller.appspot.com/bug?id=048f650e99696f881872a285cef0e3b9bd4f4e25 >> >> I'd expect these to be fixed before providing the alternate stacks in >> GENERIC. >> ___ >> freebsd-transp...@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-transport >> To unsubscribe, send any mail to >> "freebsd-transport-unsubscr...@freebsd.org" > > -- > Randall Stewart > r...@netflix.com > > > -- Randall Stewart r...@netflix.com ___ freebsd-transp...@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-transport To unsubscribe, send any mail to "freebsd-transport-unsubscr...@freebsd.org" >> >> -- >> Randall Stewart >> r...@netflix.com >> >> >> > > -- > Randall Stewart > r...@netflix.com > > > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/li
