Hi FreeBSD/main users & developers,
this stabilization week [likely final] status update:
* Netflix testing didn't discover any stability issues with
main-n269602-dd03eafacba9.
* Netflix testing didn't discover any substantial performance
degradations. The data is still being analyzed
On Apr 19, 2024, at 07:16, Philip Paeps wrote:
> On 2024-04-18 23:02:30 (+0800), Mark Millard wrote:
>
>> void wrote on
>> Date: Thu, 18 Apr 2024 14:08:36 UTC :
>>
>>> Not sure where to post this..
>>>
>>> The last bulk build for arm64 appears to have happened around
>>> mid-March on
Hi FreeBSD/main users & developers,
On Mon, Apr 22, 2024 at 01:00:50AM -0700, Gleb Smirnoff wrote:
T> This is an automated email to inform you that the April 2024 stabilization
week
T> started with FreeBSD/main at main-n269602-dd03eafacba9, which was tagged as
T> main-stabweek-2024-Apr.
T>
T>
Thank you.
I updated my current to recent current and confirmed that julia
1.11.0 beta1 builds and runs with the system clang (18.1.4).
On Thu, 18 Apr 2024 00:36:28 +0200
Dimitry Andric wrote:
> On 11 Apr 2024, at 15:07, Hiroo Ono wrote:
> >
> > Hello,
> >
> > I am trying to update the
Alexander,
On Mon, Apr 22, 2024 at 09:26:59AM +0200, Alexander Leidinger wrote:
A> I see a higher failure rate of socket/network related stuff since a while.
A> Those failures are transient. Directly executing the same thing again may
A> or may not result in success/failure. I'm not able to
g a few weeks ago, it has reverted to the behaviour you describe above.
It is not as bad right now as it got when I quit using it. Now, sometimes it
will fail, but it will succeed when re-running a "poudriere bulk" run.
I'd love it to go back to when it was working 100% of the time.
Cheers,
Paul.
On Sun, Apr 21, 2024 at 10:16:55PM +0200, Dag-Erling Smørgrav wrote:
> bob prohaska writes:
> > Apr 20 22:14:37 www su[30398]: in prompt_tty(): caught signal 2
>
> This means someone ran `su` and pressed Ctrl-C instead of entering a
> password when prompted.
Ahh, that would have been me. Thank
bob prohaska writes:
> Apr 20 22:14:37 www su[30398]: in prompt_tty(): caught signal 2
This means someone ran `su` and pressed Ctrl-C instead of entering a
password when prompted.
DES
--
Dag-Erling Smørgrav - d...@freebsd.org
On 2024-04-18 23:02:30 (+0800), Mark Millard wrote:
void wrote on
Date: Thu, 18 Apr 2024 14:08:36 UTC :
Not sure where to post this..
The last bulk build for arm64 appears to have happened around
mid-March on ampere2. Is it broken?
main-armv7 building is broken and the last completed
On Thu, Apr 18, 2024 at 08:02:30AM -0700, Mark Millard wrote:
void wrote on
Date: Thu, 18 Apr 2024 14:08:36 UTC :
Not sure where to post this..
The last bulk build for arm64 appears to have happened around
mid-March on ampere2. Is it broken?
main-armv7 building is broken and the last
On Apr 18, 2024, at 08:02, Mark Millard wrote:
> void wrote on
> Date: Thu, 18 Apr 2024 14:08:36 UTC :
>
>> Not sure where to post this..
>>
>> The last bulk build for arm64 appears to have happened around
>> mid-March on ampere2. Is it broken?
>
> main-armv7 building is broken and the
On 11 Apr 2024, at 15:07, Hiroo Ono wrote:
>
> Hello,
>
> I am trying to update the lang/julia port to 1.11.0 (currently still in beta
> 1).
> I seem to ran across this problem initially reported on MacOS.
> https://github.com/JuliaLang/julia/issues/52067
>
> The llvm team seems to have
(...)
Backup server is https://www.rsync.net/ (free 500GB for FreeBSD
developers).
Nuno Teixeira escreveu (quarta, 10/04/2024 à(s)
13:39):
> With base stack I can complete restic check successfully
> downloading/reading/checking all files from a "big" remote compressed
> backup.
> Changing it
With base stack I can complete restic check successfully
downloading/reading/checking all files from a "big" remote compressed
backup.
Changing it to RACK stack, it fails.
I run this command often because in the past, compression corruption
occured and this is the equivalent of restoring backup
> On 10. Apr 2024, at 13:40, Nuno Teixeira wrote:
>
> Hello all,
>
> @ current 1500018 and fetching torrents with net-p2p/qbittorrent finished
> ~2GB download and connection UP until the end:
>
> ---
> Apr 10 11:26:46 leg kernel: re0: watchdog timeout
> Apr 10 11:26:46 leg kernel: re0:
Hello all,
@ current 1500018 and fetching torrents with net-p2p/qbittorrent finished
~2GB download and connection UP until the end:
---
Apr 10 11:26:46 leg kernel: re0: watchdog timeout
Apr 10 11:26:46 leg kernel: re0: link state changed to DOWN
Apr 10 11:26:49 leg dhclient[58810]: New IP
Le 9 avril 2024 18:06:12 GMT+02:00, FreeBSD User a
écrit :
>Am Tue, 9 Apr 2024 17:10:52 +0200
>Rainer Hurling schrieb:
>
>> Am 09.04.24 um 09:20 schrieb Baptiste Daroussin:
>> > On Sat 06 Apr 09:23, Rainer Hurling wrote:
>> >> Am 06.04.24 um 09:05 schrieb FreeBSD User:
>> >>> Hello,
>> >>>
Cy Schubert writes:
> In message , Gleb Smirnoff writes:
> > On Tue, Apr 09, 2024 at 07:02:11PM +0200, FreeBSD User wrote:
> > F> The crash is still present on the most recent checked out sources as of
> mi
> > nutes ago.
> > F> I just checked out on HEAD the latest commits (see below, just for
On Tue, Apr 09, 2024 at 07:02:11PM +0200, FreeBSD User wrote:
F> The crash is still present on the most recent checked out sources as of
minutes ago.
F> I just checked out on HEAD the latest commits (see below, just for the
record and to prevent
F> being wrong here).
F>
F> [...]
F> commit
Am Tue, 9 Apr 2024 09:18:49 -0700
Gleb Smirnoff schrieb:
> On Tue, Apr 09, 2024 at 04:47:07AM -0700, David Wolfskill wrote:
> D> --- trap 0xc, rip = 0x80b208c5, rsp = 0xfe048c204920, rbp =
> 0xfe
> D> 048c204960 ---
> D> __mtx_lock_flags() at __mtx_lock_flags+0x45/frame
On Tue, Apr 09, 2024 at 09:18:49AM -0700, Gleb Smirnoff wrote:
> ...
> D> db>
>
> This should be fixed by just pushed e205fd318a296ffdb7392486cdcec7f660fcffcf.
Thanks! :-)
> Sorry for that!
>
Glad it's idenitfied & addressed.
[Sorry for delay; commute this morning was a bit more
On Tue, Apr 09, 2024 at 04:47:07AM -0700, David Wolfskill wrote:
D> --- trap 0xc, rip = 0x80b208c5, rsp = 0xfe048c204920, rbp =
0xfe
D> 048c204960 ---
D> __mtx_lock_flags() at __mtx_lock_flags+0x45/frame 0xfe048c204960
D> clnt_vc_create() at clnt_vc_create+0x4f4/frame
Am Tue, 9 Apr 2024 17:10:52 +0200
Rainer Hurling schrieb:
> Am 09.04.24 um 09:20 schrieb Baptiste Daroussin:
> > On Sat 06 Apr 09:23, Rainer Hurling wrote:
> >> Am 06.04.24 um 09:05 schrieb FreeBSD User:
> >>> Hello,
> >>>
> >>> after updating (portmaster and make) ports-mgmt/ports from
On Tue, Apr 9, 2024 at 8:04 AM Rick Macklem wrote:
>
> On Tue, Apr 9, 2024 at 7:46 AM Rick Macklem wrote:
> >
> > On Tue, Apr 9, 2024 at 4:47 AM David Wolfskill wrote:
> > >
> > > Machine had been running:
> > >
> > > FreeBSD 15.0-CURRENT #43 main-n269202-4e7aa03b7076: Mon Apr 8 11:19:58
> >
Am 09.04.24 um 09:20 schrieb Baptiste Daroussin:
On Sat 06 Apr 09:23, Rainer Hurling wrote:
Am 06.04.24 um 09:05 schrieb FreeBSD User:
Hello,
after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> 1.21.0
on CURRENT and
14-STABLE, I can't update several ports:
www/apache24
Am 06.04.24 um 09:56 schrieb FreeBSD User:
Am Sat, 6 Apr 2024 09:23:30 +0200
Rainer Hurling schrieb:
Am 06.04.24 um 09:05 schrieb FreeBSD User:
Hello,
after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> 1.21.0
on CURRENT
and 14-STABLE, I can't update several ports:
On Tue, Apr 9, 2024 at 7:46 AM Rick Macklem wrote:
>
> On Tue, Apr 9, 2024 at 4:47 AM David Wolfskill wrote:
> >
> > Machine had been running:
> >
> > FreeBSD 15.0-CURRENT #43 main-n269202-4e7aa03b7076: Mon Apr 8 11:19:58 UTC
> > 2024
> >
On Tue, Apr 9, 2024 at 4:47 AM David Wolfskill wrote:
>
> Machine had been running:
>
> FreeBSD 15.0-CURRENT #43 main-n269202-4e7aa03b7076: Mon Apr 8 11:19:58 UTC
> 2024
> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC
> amd64 1500018 1500018
>
> This was an
On Sat 06 Apr 09:23, Rainer Hurling wrote:
> Am 06.04.24 um 09:05 schrieb FreeBSD User:
> > Hello,
> >
> > after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 ->
> > 1.21.0 on CURRENT and
> > 14-STABLE, I can't update several ports:
> >
> > www/apache24
> > databases/redis
> >
On Sat 06 Apr 09:05, FreeBSD User wrote:
> Hello,
>
> after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> 1.21.0
> on CURRENT and
> 14-STABLE, I can't update several ports:
>
> www/apache24
> databases/redis
>
> pkg core dumps while performing installation. apache24 and
Mark Millard:
> On Mar 30, 2024, at 12:44, Lexi Winter wrote:
> > when the problem happens, with USB_DEBUG enabled, the kernel logs:
> >
> > uhub_reattach_port: port 2 reset failed, error=USB_ERR_TIMEOUT
> > uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 2
>
> Here is my
Am Sat, 6 Apr 2024 09:05:00 +0200
FreeBSD User schrieb:
> Hello,
>
> after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> 1.21.0
> on CURRENT and
> 14-STABLE, I can't update several ports:
>
> www/apache24
> databases/redis
>
> pkg core dumps while performing installation.
Am Thu, 4 Apr 2024 01:14:52 -0500
Kyle Evans schrieb:
> On 4/4/24 00:49, FreeBSD User wrote:
> > Hello,
> >
> > I just stumbled over this CVE regarding xz 5.6.0 and 5.6.1:
> >
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-3094
> >
> > FreeBSD starting with 14-STABLE seems to use
Am 06.04.24 um 09:05 schrieb FreeBSD User:
Hello,
after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> 1.21.0
on CURRENT and
14-STABLE, I can't update several ports:
www/apache24
databases/redis
pkg core dumps while performing installation. apache24 and redis are ports I
On April 4, 2024 07:50:55 FreeBSD User wrote:
Hello,
I just stumbled over this CVE regarding xz 5.6.0 and 5.6.1:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-3094
FreeBSD starting with 14-STABLE seems to use xz 5.6.0, but my limited
skills do not allow me
to judge wether the
On 4/4/24 00:49, FreeBSD User wrote:
Hello,
I just stumbled over this CVE regarding xz 5.6.0 and 5.6.1:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-3094
FreeBSD starting with 14-STABLE seems to use xz 5.6.0, but my limited skills do
not allow me
to judge wether the described
Am Thu, 04 Apr 2024 08:06:26 +0200 (CEST)
sth...@nethelp.no schrieb:
> >> I have to report to my superiors (we're using 14-STABLE and CURRENT
> >> and I do so in private),
> >> so I would like to welcome any comment on that.
> >
> > No it does not affect FreeBSD.
> >
> > The autoconf script
>> I have to report to my superiors (we're using 14-STABLE and CURRENT
>> and I do so in private),
>> so I would like to welcome any comment on that.
>
> No it does not affect FreeBSD.
>
> The autoconf script checks that it is running in a RedHat or Debian
> package build environment before
On 04-04-24 05:49, FreeBSD User wrote:
Hello,
I just stumbled over this CVE regarding xz 5.6.0 and 5.6.1:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-3094
FreeBSD starting with 14-STABLE seems to use xz 5.6.0, but my limited skills do
not allow me
to judge whether the
Shouldn't be a problem. The socket used for lookup is
AF_UNIX (uses unp_connectat) and the NFS socket
will always be UDP or TCP.
Different sockets imply different socket locks.
At least that's my interpretation, rick
On Wed, Apr 3, 2024 at 11:33 AM Bjoern A. Zeeb
wrote:
>
>
> NFS root boot of
On Tue, Apr 2, 2024 at 11:53 AM Tomoaki AOKI
wrote:
> On Tue, 02 Apr 2024 08:53:15 -0700
> Chris wrote:
>
> > On 2024-04-02 04:32, Tomoaki AOKI wrote:
> > > On Tue, 02 Apr 2024 00:42:23 -0700
> > > Chris wrote:
> > >
> > >> On 2024-04-01 22:51, Kevin Oberman wrote:
> > >> > On Mon, Apr 1, 2024
On Tue, 02 Apr 2024 08:53:15 -0700
Chris wrote:
> On 2024-04-02 04:32, Tomoaki AOKI wrote:
> > On Tue, 02 Apr 2024 00:42:23 -0700
> > Chris wrote:
> >
> >> On 2024-04-01 22:51, Kevin Oberman wrote:
> >> > On Mon, Apr 1, 2024 at 3:05 PM Chris wrote:
> >> >
> >> >> I experience challenges
On 2024-04-02 04:32, Tomoaki AOKI wrote:
On Tue, 02 Apr 2024 00:42:23 -0700
Chris wrote:
On 2024-04-01 22:51, Kevin Oberman wrote:
> On Mon, Apr 1, 2024 at 3:05 PM Chris wrote:
>
>> I experience challenges running FreeBSD on my Alder Lake laptop.
>> With some help on the list and Bugzilla, I
On Tue, 02 Apr 2024 00:42:23 -0700
Chris wrote:
> On 2024-04-01 22:51, Kevin Oberman wrote:
> > On Mon, Apr 1, 2024 at 3:05 PM Chris wrote:
> >
> >> I experience challenges running FreeBSD on my Alder Lake laptop.
> >> With some help on the list and Bugzilla, I was able to get Graphics
> >>
On Mon, Apr 01, 2024 at 10:51:10PM -0700, Kevin Oberman wrote:
>
> I have a T16 and ran into that issue. It may be that BIOS changes have
> broken things, but I found that, by default, the F keys control volume,
> screen brightness, and many other things. I can use Fn+F[1-12] to perform
>
On 2024-04-01 22:51, Kevin Oberman wrote:
On Mon, Apr 1, 2024 at 3:05 PM Chris wrote:
I experience challenges running FreeBSD on my Alder Lake laptop.
With some help on the list and Bugzilla, I was able to get Graphics
WiFi at least working. But still wasn't as stable as running on
more dated
On Mon, Apr 1, 2024 at 3:05 PM Chris wrote:
> I experience challenges running FreeBSD on my Alder Lake laptop.
> With some help on the list and Bugzilla, I was able to get Graphics
> WiFi at least working. But still wasn't as stable as running on
> more dated CPU's. As it is; I'm only able to
On 2024-04-01 14:57, Michael Gmelin wrote:
You never responded to my (and T’s) message - so I assume the suggestions
made no
difference?
Right, and thank you for the reply. I (indirectly) answered it here
when I indicated that I had no references to "keyboard settings in
my rc.conf(5)". :) Any
On Mar 30, 2024, at 12:44, Lexi Winter wrote:
> i'm using 15.0 (f66a994d59) on an 4GB RPi4 with a USB<>SATA adapter for
> the root disk:
>
> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device
> ASM1153USB3.0TOSATA ASM1153USB3.0TOSATA (0x174c:0x55aa)
> ugen0.3: at usbus0
>
(...)
initial_turbo
https://www.raspberrypi.com/documentation/computers/config_txt.html#overclocking
Nuno Teixeira escreveu (domingo, 31/03/2024 à(s)
19:59):
> Hello,
>
> If you got a fan in your rpi4 box, you could try to overclock it.
> If not, there is a funcionality in config.txt to
Hello,
If you got a fan in your rpi4 box, you could try to overclock it.
If not, there is a funcionality in config.txt to overclock it just for a
few seconds at boot time.
I can't remember the funtion but I'm looking at:
https://www.raspberrypi.com/documentation/computers/config_txt.html
Am 2024-03-29 18:21, schrieb Alexander Leidinger:
Am 2024-03-29 18:13, schrieb Mark Johnston:
On Fri, Mar 29, 2024 at 04:52:55PM +0100, Alexander Leidinger wrote:
Hi,
sources from 2024-03-11 work. Sources from 2024-03-25 and today don't
work
(see below for the issue). As the monthly
(For the not working Wifi chip, I use at the moment an USB-Wifi dongle,
Realtek RTL8191S WLAN Adapter, which works fine).
I also can't get Xorg plus twm up; it says in /var/log/Xorg.0.log at the end:
..
REDWOOD, ATI Mobility Radeon Graphics, CEDAR, ATI FirePro 2270,
ATI Radeon
On Fri, 29 Mar 2024 19:02:37 -0700
Chris wrote:
> I just poured the dist files onto an earlier 15 (after removing
> the earlier version). After booting into the new install, I no longer
> had any other tty's other than ttyv0. Alt+Fn has no affect, I'm only
> getting ttyv0. getty(8) is running,
> On 30. Mar 2024, at 07:30, Chris wrote:
>
> On 2024-03-29 23:06, Michael Schuster wrote:
>> Two ideas:
>> - does CTL-ALT-Fn work?
> Thanks. But no, I tried that.
>
>> - perhaps the number of predefined ttys was overwritten/set to 0 somewhere?
> I'm only aware of /etc/ttys, and they're all
On 2024-03-29 23:06, Michael Schuster wrote:
Two ideas:
- does CTL-ALT-Fn work?
Thanks. But no, I tried that.
- perhaps the number of predefined ttys was overwritten/set to 0 somewhere?
I'm only aware of /etc/ttys, and they're all available (uncommented) and
ps(1) indicates getty(8) is
On 3/29/24 16:52, Alexander Leidinger wrote:
Hi,
sources from 2024-03-11 work. Sources from 2024-03-25 and today don't
work (see below for the issue). As the monthly stabilisation pass
didn't find obvious issues, it is something related to my setup:
- not a generic kernel
- very modular
Am 2024-03-29 18:13, schrieb Mark Johnston:
On Fri, Mar 29, 2024 at 04:52:55PM +0100, Alexander Leidinger wrote:
Hi,
sources from 2024-03-11 work. Sources from 2024-03-25 and today don't
work
(see below for the issue). As the monthly stabilisation pass didn't
find
obvious issues, it is
On Fri, Mar 29, 2024 at 04:52:55PM +0100, Alexander Leidinger wrote:
> Hi,
>
> sources from 2024-03-11 work. Sources from 2024-03-25 and today don't work
> (see below for the issue). As the monthly stabilisation pass didn't find
> obvious issues, it is something related to my setup:
> - not a
> On 28. Mar 2024, at 15:00, Nuno Teixeira wrote:
>
> Hello all!
>
> Running rack @b7b78c1c169 "Optimize HPTS..." very happy on my laptop (amd64)!
>
> Thanks all!
Thanks for the feedback!
Best regards
Michael
>
> Drew Gallatin escreveu (quinta, 21/03/2024 à(s) 12:58):
> The entire point is
Hello all!
Running rack @b7b78c1c169 "Optimize HPTS..." very happy on my laptop
(amd64)!
Thanks all!
Drew Gallatin escreveu (quinta, 21/03/2024 à(s)
12:58):
> The entire point is to *NOT* go through the overhead of scheduling
> something asynchronously, but to take advantage of the fact that
El día miércoles, marzo 27, 2024 a las 03:51:33p. m. +0100, Matthias Apitz
escribió:
> The WLAN card seems to be:
>
> none2@pci0:1:0:0: class=0x028000 rev=0x00 hdr=0x00 vendor=0x14c3
> device=0x7961 subvendor=0x1a3b subdevice=0x4680
> vendor = 'MEDIATEK Corp.'
> device =
On Wed, Mar 27, 2024 at 05:55:20PM +0200, Konstantin Belousov wrote:
> On Wed, Mar 27, 2024 at 03:01:11AM +0100, Bernd Walter wrote:
> > Same Problem with current:
> > reeBSD 15.0-CURRENT #0 main-n268793-220ee18f1964: Thu Mar 14 02:58:39 UTC
> > 2024
> >
> > real memory = 1649265344512
On Wed, Mar 27, 2024 at 03:01:11AM +0100, Bernd Walter wrote:
> Same Problem with current:
> reeBSD 15.0-CURRENT #0 main-n268793-220ee18f1964: Thu Mar 14 02:58:39 UTC 2024
>
> real memory = 1649265344512 (1572862 MB)
> avail memory = 1057118396416 (1008146 MB)
Real memory is really the max
El día miércoles, marzo 27, 2024 a las 10:37:48a. m. +0100, Matthias Apitz
escribió:
>
> Hello,
>
> I bought the laptop ASUS VivoBook Pro 14 90NB0VZ2-M01230 and managed to
> boot FreeBSD with boot verbose messages from an USB key and I'm able to
> login. The /var/log/messages are here
>
On Wed, Mar 27, 2024 at 01:00:07PM +0100, Mateusz Guzik wrote:
> Top of main, but I reproduced it on stable/14-e64d827d3 as well.
>
> Mere "timeout 2 sleep 10" correctly times out.
>
> Running "truss -f timeout 2 sleep 10" prevents timeout from killing
> sleep and the entire thing refuses to
Mateusz Guzik writes:
> Top of main, but I reproduced it on stable/14-e64d827d3 as well.
Confirmed on 14.0-RELEASE-p5.
> Mere "timeout 2 sleep 10" correctly times out.
>
> Running "truss -f timeout 2 sleep 10" prevents timeout from killing
> sleep
This is sort of expected as truss(1) uses
On Wed, Mar 27, 2024 at 12:38 PM Matthias Apitz wrote:
>
>
> Hello,
>
> I bought the laptop ASUS VivoBook Pro 14 90NB0VZ2-M01230 and managed to
> boot FreeBSD with boot verbose messages from an USB key and I'm able to
> login. The /var/log/messages are here
>
Same Problem with current:
reeBSD 15.0-CURRENT #0 main-n268793-220ee18f1964: Thu Mar 14 02:58:39 UTC 2024
real memory = 1649265344512 (1572862 MB)
avail memory = 1057118396416 (1008146 MB)
On Fri, Mar 22, 2024 at 07:54:06PM +0100, Bernd Walter wrote:
> ..
> real memory = 1649265344512
Hi,
On Mon, Mar 25, 2024 at 01:00:07AM -0700, Gleb Smirnoff wrote:
T> This is an automated email to inform you that the March 2024 stabilization
week
T> started with FreeBSD/main at main-n268989-caccf6d3c008, which was tagged as
T> main-stabweek-2024-Mar.
A quick status update:
* Netflix
On Mar 25, 2024, at 00:51, Lexi Winter wrote:
> Lexi Winter:
>> . . .
>
> . . .
>
> - even with the working keyboard, ctrl+alt+esc doesn't seem to work to
> break into kdb when the problem occurs. i'm not sure if i'm doing
> something wrong here or that key sequence doesn't work over USB,
Lexi Winter:
> i am not really an expert on either ARM64 in general or on the RPi
> hardware in particular. could anyone suggest how i could debug this
> problem, e.g. to get more information about why the system won't finish
> booting?
i dug into this a bit more, and to answer my own question:
> On 21. Mar 2024, at 18:12, Dimitry Andric wrote:
>
> On 21 Mar 2024, at 01:12, tue...@freebsd.org wrote:
>>
>>> On 21. Mar 2024, at 00:27, Dimitry Andric wrote:
>>>
>>> On 20 Mar 2024, at 21:44, tue...@freebsd.org wrote:
I'm trying to run make buildworld / make installworld on a
On 21 Mar 2024, at 01:12, tue...@freebsd.org wrote:
>
>> On 21. Mar 2024, at 00:27, Dimitry Andric wrote:
>>
>> On 20 Mar 2024, at 21:44, tue...@freebsd.org wrote:
>>>
>>> I'm trying to run make buildworld / make installworld on a recent main
>>> branch
>>> (some days old).
>>>
>>> The
The entire point is to *NOT* go through the overhead of scheduling something
asynchronously, but to take advantage of the fact that a user/kernel transition
is going to trash the cache anyway.
In the common case of a system which has less than the threshold number of
connections , we access
On Tue, Mar 19, 2024 at 06:19:52AM -0400, rrs wrote:
> Ok I have created
>
> https://reviews.freebsd.org/D44420
>
>
> To address the issue. I also attach a short version of the patch that Nuno
> can try and validate
>
> it works. Drew you may want to try this and validate the optimization does
> On 21. Mar 2024, at 00:27, Dimitry Andric wrote:
>
> On 20 Mar 2024, at 21:44, tue...@freebsd.org wrote:
>>
>> I'm trying to run make buildworld / make installworld on a recent main branch
>> (some days old).
>>
>> The problem is related to lib/libc/tests/ssp/Makefile
>> which contains:
>>
On 20 Mar 2024, at 21:44, tue...@freebsd.org wrote:
>
> I'm trying to run make buildworld / make installworld on a recent main branch
> (some days old).
>
> The problem is related to lib/libc/tests/ssp/Makefile
> which contains:
> _libclang_rt_ubsan=
>
On 2024-03-19 16:02, Emmanuel Vadot wrote:
> On Tue, 19 Mar 2024 07:55:15 +
> Alastair Hogge wrote:
>
>> On 2024-03-19 15:23, Emmanuel Vadot wrote:
>> > Hi,
>>
>> Hey Emmanuel,
>>
>> > On Tue, 19 Mar 2024 06:54:27 +
>> > Alastair Hogge wrote:
>> >
>> >> Hello,
>> >>
>> >> Recently a
On Tue, 19 Mar 2024 07:55:15 +
Alastair Hogge wrote:
> On 2024-03-19 15:23, Emmanuel Vadot wrote:
> > Hi,
>
> Hey Emmanuel,
>
> > On Tue, 19 Mar 2024 06:54:27 +
> > Alastair Hogge wrote:
> >
> >> Hello,
> >>
> >> Recently a similar module (PAM) mentioned in the subject was committed
On 2024-03-19 15:23, Emmanuel Vadot wrote:
> Hi,
Hey Emmanuel,
> On Tue, 19 Mar 2024 06:54:27 +
> Alastair Hogge wrote:
>
>> Hello,
>>
>> Recently a similar module (PAM) mentioned in the subject was committed
>> to base[1]. The module in base masks the currently installed Port, the
>> man
Hi,
On Tue, 19 Mar 2024 06:54:27 +
Alastair Hogge wrote:
> Hello,
>
> Recently a similar module (PAM) mentioned in the subject was committed
> to base[1]. The module in base masks the currently installed Port, the
> man page can be accessed with man -M /usr/local/share/man 8 pam_xdg,
>
Hi!
This commit is supposed to fix a problem we do not have a reproducer for.
The problem was that sometimes a TCP connection enters tcp_discardcb()
with a scheduled timer. A temporary patch 57e27ff07aff was committed
to mask the problem. This patch is supposed to fix the root cause.
No. The goal is to run on every return to userspace for every thread.
Drew
On Mon, Mar 18, 2024, at 3:41 PM, Konstantin Belousov wrote:
> On Mon, Mar 18, 2024 at 03:13:11PM -0400, Drew Gallatin wrote:
> > I got the idea from
> >
On Mon, Mar 18, 2024 at 03:13:11PM -0400, Drew Gallatin wrote:
> I got the idea from
> https://people.mpi-sws.org/~druschel/publications/soft-timers-tocs.pdf
> The gist is that the TCP pacing stuff needs to run frequently, and
> rather than run it out of a clock interrupt, its more efficient to
I got the idea from
https://people.mpi-sws.org/~druschel/publications/soft-timers-tocs.pdf The
gist is that the TCP pacing stuff needs to run frequently, and rather than run
it out of a clock interrupt, its more efficient to run it out of a system call
context at just the point where we
On Mon, Mar 18, 2024 at 07:26:10AM -0500, Mike Karels wrote:
> On 18 Mar 2024, at 7:04, tue...@freebsd.org wrote:
>
> >> On 18. Mar 2024, at 12:42, Nuno Teixeira wrote:
> >>
> >> Hello all!
> >>
> >> It works just fine!
> >> System performance is OK.
> >> Using patch on
On Mon, Mar 18, 2024 at 07:26:10AM -0500, Mike Karels wrote:
> ...
> >> It would be so nice that we can have a sysctl tunnable for this patch
> >> so we could do more tests without recompiling kernel.
> > Thanks for testing!
> >
> > @gallatin: can you come up with a patch that is acceptable for
On 18 Mar 2024, at 7:04, tue...@freebsd.org wrote:
>> On 18. Mar 2024, at 12:42, Nuno Teixeira wrote:
>>
>> Hello all!
>>
>> It works just fine!
>> System performance is OK.
>> Using patch on main-n268841-b0aaf8beb126(-dirty).
>>
>> ---
>> net.inet.tcp.functions_available:
>> Stack
> On 18. Mar 2024, at 12:42, Nuno Teixeira wrote:
>
> Hello all!
>
> It works just fine!
> System performance is OK.
> Using patch on main-n268841-b0aaf8beb126(-dirty).
>
> ---
> net.inet.tcp.functions_available:
> Stack D AliasPCB count
>
Hello all!
It works just fine!
System performance is OK.
Using patch on main-n268841-b0aaf8beb126(-dirty).
---
net.inet.tcp.functions_available:
Stack D AliasPCB count
freebsd freebsd 0
rack
Hello,
> I don't have the full context, but it seems like the complaint is a
> performance regression in bonnie++ and perhaps other things when tcp_hpts is
> loaded, even when it is not used. Is that correct?
>
> If so, I suspect its because we drive the tcp_hpts_softclock() routine from
>
> On 17. Mar 2024, at 16:39, Drew Gallatin wrote:
>
> I don't have the full context, but it seems like the complaint is a
> performance regression in bonnie++ and perhaps other things when tcp_hpts is
> loaded, even when it is not used. Is that correct?
Correct.
>
> If so, I suspect its
On Sun, 17 Mar 2024 11:40:54 -0400
"Drew Gallatin" wrote:
> Resending with the patch as an attachment.
>
> Drew
>
> On Sun, Mar 17, 2024, at 11:39 AM, Drew Gallatin wrote:
> > I don't have the full context, but it seems like the complaint is a
> > performance regression in bonnie++ and
Resending with the patch as an attachment.
Drew
On Sun, Mar 17, 2024, at 11:39 AM, Drew Gallatin wrote:
> I don't have the full context, but it seems like the complaint is a
> performance regression in bonnie++ and perhaps other things when tcp_hpts is
> loaded, even when it is not used. Is
I don't have the full context, but it seems like the complaint is a performance
regression in bonnie++ and perhaps other things when tcp_hpts is loaded, even
when it is not used. Is that correct?
If so, I suspect its because we drive the tcp_hpts_softclock() routine from
userret(), in order
Hello,
> > - I can't remember better tests to do as I can feel the entire OS is
> > being slow, without errors, just slow.
> This is interesting. It seems a consequence on loading TCPHPTS, not actually
> using it.
Exactly, just loading module and not using it by setting sysctl.
> I have CCed
> On 16. Mar 2024, at 21:29, Nuno Teixeira wrote:
>
>> Just to double check: you only load the tcp_rack. You don't run
>> sysctl net.inet.tcp.functions_default=rack
>
> I'm not using sysctl, just loading module.
And you also don't have
net.inet.tcp.functions_default=rack
in /etc/sysctl.conf
On Sun, 19 Nov 2023 04:01:01 +0900
Tomoaki AOKI wrote:
> On Sat, 18 Nov 2023 09:50:43 +0100
> tue...@freebsd.org wrote:
>
> > > On Nov 18, 2023, at 00:37, Tomoaki AOKI wrote:
> > >
> > > On Fri, 17 Nov 2023 18:51:05 +0100
> > > tue...@freebsd.org wrote:
> > >
> > >>> On Nov 17, 2023, at
> Just to double check: you only load the tcp_rack. You don't run
> sysctl net.inet.tcp.functions_default=rack
I'm not using sysctl, just loading module.
> What does "poudriere testport net/gitup" do? Only build stuff or does is
> also download something?
>
> What does bonnie++ do?
poudriere is
1 - 100 of 105779 matches
Mail list logo
