Re: [Bug 269133] bnxt(4): BCM57416 - HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error

On Tue, Jun 4, 2024 at 8:17 AM Gerrit Kühn wrote: > Am Tue, 28 May 2024 11:19:42 +0200 > schrieb Gerrit Kühn : > > > > Not sure if it will break your setup, but this already happened with > > > 13.2 (I cant recall the exact release). > > > I have two machines with onboard NICs (Supermicro

Re: [Bug 269133] bnxt(4): BCM57416 - HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error

Am Tue, 28 May 2024 11:19:42 +0200 schrieb Gerrit Kühn : > > Not sure if it will break your setup, but this already happened with > > 13.2 (I cant recall the exact release). > I have two machines with onboard NICs (Supermicro H12SSL-CT mainboards) > running just fine. One is 13.3, the other

Re: [Bug 269133] bnxt(4): BCM57416 - HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error

Hi everyone, just to follow up. I have found something interesting, at the moment I'm focusing on the issue related to the creation and deletion of sub-interfaces that trigger ALLOC/MASK errors and bricks the NIC ( not completely as the other port keeps working, this card has 2x10G). I have

Re: [Bug 269133] bnxt(4): BCM57416 - HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error

Am Tue, 28 May 2024 11:25:09 +0200 schrieb Santiago Martinez : > *"The latest I have is 214.0.286.18"* > Indeed, the firmware on my box is older, I cannot upgrade it right now, > but it is on my to-do list. Same here, I guess (pkgver). It says dev.bnxt.0.ver.fw_ver: 214.4.9.10/pkg 214.0.286.18

Re: [Bug 269133] bnxt(4): BCM57416 - HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error

Hi! *"The latest I have is 214.0.286.18"* Indeed, the firmware on my box is older, I cannot upgrade it right now, but it is on my to-do list. I'm also trying to apply the patch recommended by @Warner. I will keep you posted. Santi On 5/28/24 11:19, Gerrit Kühn wrote: Am Tue, 28 May 2024

Re: [Bug 269133] bnxt(4): BCM57416 - HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error

Am Tue, 28 May 2024 10:59:00 +0200 schrieb Santiago Martinez : > Not sure if it will break your setup, but this already happened with > 13.2 (I cant recall the exact release). I have two machines with onboard NICs (Supermicro H12SSL-CT mainboards) running just fine. One is 13.3, the other is

Re: [Bug 269133] bnxt(4): BCM57416 - HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error

Hi Gerrit, Not sure if it will break your setup, but this already happened with 13.2 (I cant recall the exact release). Drivers used to be ok, before 13.X and then I started to see many errors. That's why I was suggesting to have a pkg with if_bnxt to get releases as required without

Re: [Bug 269133] bnxt(4): BCM57416 - HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error

Am Mon, 27 May 2024 15:05:31 -0600 schrieb Warner Losh : > I'd like it there, but I think this will need to be a EN to get it into > 14.1 given the late date of this commit Unless we slip 14.1 for > other reasons... I have systems running 14.0 that use onboard bnxt chipsets, seen no issues

Re: [Bug 269133] bnxt(4): BCM57416 - HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error

On Mon, May 27, 2024 at 3:01 PM Colin Percival wrote: > On 5/27/24 13:51, Warner Losh wrote: > > On Mon, May 27, 2024 at 10:16 AM Santiago Martinez > > wrote: > > Just wondering if anyone has any contact at broadcom. > > > > The bnxt drivers on 14.1BETA1

Re: [Bug 269133] bnxt(4): BCM57416 - HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error

On Mon, May 27, 2024 at 10:16 AM Santiago Martinez wrote: > Hi Everyone, > > Just wondering if anyone has any contact at broadcom. > > The bnxt drivers on 14.1BETA1 are unusable. > > Cards stop working randomly, LRO cannot be disable (fail FILTER_ALLOT), > even chaining mtu renders the card

Re: [Bug 269133] bnxt(4): BCM57416 - HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error

Hi Everyone, Just wondering if anyone has any contact at broadcom. The bnxt drivers on 14.1BETA1 are unusable. Cards stop working randomly, LRO cannot be disable (fail FILTER_ALLOT), even chaining mtu renders the card unusable. The cards, is the same it was used to open the original PR.

Chromium can't be compiled because a bug with webrtc.

Hello. On FreeBSD 13.3 I'm trying to install Chromium,but the compilation stopped because a bug : . /usr/local/include -c ../../third_party/webrtc/api/candidate.cc -o obj/third_party/webrtc/api/candi date/candidate.o In file included from ../../third_party/webrtc/api/candidate.cc:11

[Bug 197921] scheduler: Allow non-migratable threads to bind to their current CPU

g the KASSERT after the `if (PCPU_GET(cpuid) == > cpu)` test? I think that is much simpler. -- You are receiving this mail because: You are on the CC list for the bug.

[Bug 197921] scheduler: Allow non-migratable threads to bind to their current CPU

? | --- Comment #2 from Mark Linimon --- ^Triage: remove OBE flags. -- You are receiving this mail because: You are on the CC list for the bug.

[Bug 267671] Unnecessary printf to stderr in stdlib/cxa_thread_atexit_impl.c

Could someone please take a look at bug 267671 [1]? Numerous 'printf to stderr' make it difficult to read terminal output important for ports like graphics/qgis ... Thanks for an assessment! Regards, Rainer Hurling [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267671

Re: grep(1) bug - duplicate output lines

Kyle Evans wrote: > Alright, fine, be that way. :-) Try this on top of the existing patch: Sorry! I have this knack of (accidentally) stumbling upon weird-case bugs that usually don't affect anyone! :-) > https://people.freebsd.org/~kevans/grep-color-addition.diff Brilliant That all seems

Re: grep(1) bug - duplicate output lines

On 9/29/23 15:37, Kyle Evans wrote: On 9/29/23 13:25, Jamie Landeg-Jones wrote: Jamie Landeg-Jones wrote: Brilliant! Thanks for the quick response and fix. It works fine for me - I've not managed to break it again :-) Famous last words "grep -v" now produces duplicate lines! e.g. :

Re: grep(1) bug - duplicate output lines

On 9/29/23 13:25, Jamie Landeg-Jones wrote: Jamie Landeg-Jones wrote: Brilliant! Thanks for the quick response and fix. It works fine for me - I've not managed to break it again :-) Famous last words "grep -v" now produces duplicate lines! e.g. : Alright, fine, be that way. :-) Try

Re: grep(1) bug - duplicate output lines

Jamie Landeg-Jones wrote: > Brilliant! Thanks for the quick response and fix. It works fine for me - > I've not managed to break it again :-) Famous last words "grep -v" now produces duplicate lines! e.g. : | % grep -v sdjdjdjd /COPYRIGHT|head | # @(#)COPYRIGHT 8.2 (Berkeley)

Re: grep(1) bug - duplicate output lines

Kyle Evans wrote: > I think this is what we want: > > https://people.freebsd.org/~kevans/grep-color.diff Brilliant! Thanks for the quick response and fix. It works fine for me - I've not managed to break it again :-) > Basically, for --color with . we actually get each individual character >

Re: grep(1) bug - duplicate output lines

) 2.6.0-FreeBSD E.G.: $ grep --color=always . /etc/fstab I think this is what we want: https://people.freebsd.org/~kevans/grep-color.diff That looks surprisingly complicated. FWIW, this issue didn't occur with older versions of grep. I added the bug sometime before we went live

Re: grep(1) bug - duplicate output lines

On Wednesday, 27 September 2023 at 22:30:43 -0500, Kyle Evans wrote: > On 9/27/23 21:40, Jamie Landeg-Jones wrote: >> When using color=always and a regex of '.' (for example), output lines >> are duplicated. >> >> $ grep --version >> grep (BSD grep, GNU compatible) 2.6.0-FreeBSD >> >> E.G.: >> >>

Re: grep(1) bug - duplicate output lines

On 9/27/23 21:40, Jamie Landeg-Jones wrote: When using color=always and a regex of '.' (for example), output lines are duplicated. $ grep --version grep (BSD grep, GNU compatible) 2.6.0-FreeBSD E.G.: $ grep --color=always . /etc/fstab Cheers, Jamie I think this is what we want:

grep(1) bug - duplicate output lines

When using color=always and a regex of '.' (for example), output lines are duplicated. $ grep --version grep (BSD grep, GNU compatible) 2.6.0-FreeBSD E.G.: $ grep --color=always . /etc/fstab Cheers, Jamie

Re: [Bug 273506] main [so: 15] aarch64 kyua python use fails with: . . . and dlerror is reporting "/usr/lib/ossl-modules/legacy.so: Undefined symbol \"MD4_Update\"", '\000' [crude

On Sep 2, 2023, at 09:37, Mark Millard wrote: > On Sep 2, 2023, at 00:35, Mark Millard wrote: > >> For: >> >>> Date: Sat, 02 Sep 2023 00:58:29 UTC >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273506 >>> >>> Bug ID: 273506 &g

Re: [Bug 273506] main [so: 15] aarch64 kyua python use fails with: . . . and dlerror is reporting "/usr/lib/ossl-modules/legacy.so: Undefined symbol \"MD4_Update\"", '\000'

On Sep 2, 2023, at 00:35, Mark Millard wrote: > For: > >> Date: Sat, 02 Sep 2023 00:58:29 UTC >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273506 >> >> Bug ID: 273506 >> Summary: main [so: 15] aarch64 kyua python use fails with: >> "Run

Re: [Bug 273506] main [so: 15] aarch64 kyua python use fails with: . . . and dlerror is reporting "/usr/lib/ossl-modules/legacy.so: Undefined symbol \"MD4_Update\"", '\000'

For: > Date: Sat, 02 Sep 2023 00:58:29 UTC > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273506 > > Bug ID: 273506 > Summary: main [so: 15] aarch64 kyua python use fails with: > "RuntimeError: OpenSSL 3.0's legacy provider failed to > load" > Produ

Re: Fwd: [Bug 270041] www/qt5-webengine: Poudriere build fails for 5.15.8

.org - > > > > Date: Sun, 13 Aug 2023 15:08:04 + > > From: bugzilla-nore...@freebsd.org > > To: k...@freebsd.org > > Subject: [Bug 270041] www/qt5-webengine: Poudriere build fails for 5.15.8 > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id

Re: Fwd: [Bug 270041] www/qt5-webengine: Poudriere build fails for 5.15.8

e...@freebsd.org > To: k...@freebsd.org > Subject: [Bug 270041] www/qt5-webengine: Poudriere build fails for 5.15.8 > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270041 Oh nice! How I have missed this BZ report, this will get my 14-CURRENT hosts up to date, thanks for sharing.

Re: Fwd: [Bug 270041] www/qt5-webengine: Poudriere build fails for 5.15.8

> From: bugzilla-nore...@freebsd.org > To: k...@freebsd.org > Subject: [Bug 270041] www/qt5-webengine: Poudriere build fails for 5.15.8 > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270041 > > --- Comment #11 from Matthias Apitz --- > I stumbled across the bug in mid August a

Fwd: [Bug 270041] www/qt5-webengine: Poudriere build fails for 5.15.8

fwd to freebsd-current@ because I don't know if kde@ is read by someone; matthias - Forwarded message from bugzilla-nore...@freebsd.org - Date: Sun, 13 Aug 2023 15:08:04 + From: bugzilla-nore...@freebsd.org To: k...@freebsd.org Subject: [Bug 270041] www/qt5-webengine

[Bug 272536] 'make buildworld -j 8' fails: pid 79018 (clang), jid 0, uid 0, was killed: a thread waiting too long to allocate a page

ing HD with the UFS file system. The host OS is FreeBSD 13.2 amd64. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 272536] 'make buildworld -j 8' fails: pid 79018 (clang), jid 0, uid 0, was killed: a thread waiting too long to allocate a page

are the assignee for the bug.

[Bug 272536] 'make buildworld -j 8' fails: pid 79018 (clang), jid 0, uid 0, was killed: a thread waiting too long to allocate a page

You are receiving this mail because: You are the assignee for the bug.

[Bug 272536] 'make buildworld -j 8' fails: pid 79018 (clang), jid 0, uid 0, was killed: a thread waiting too long to allocate a page

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272536 --- Comment #2 from Yuri Victorovich --- (In reply to Mark Millard from comment #1) Swap is on /dev/ada0p2. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 272536] 'make buildworld -j 8' fails: pid 79018 (clang), jid 0, uid 0, was killed: a thread waiting too long to allocate a page

various forms of time handling. So that might be another direction involved for this issue. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 272536] 'make buildworld -j 8' fails: pid 79018 (clang), jid 0, uid 0, was killed: a thread waiting too long to allocate a page

/ ||~yuri/screenshot-clang-kill ||ed-on-FreeBSD-14.png Assignee|b...@freebsd.org|curr...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.

Re: Possible PEBKAC bug for fwget(8)?

: Possible PEBKAC bug for fwget(8)? Hi Kenneth, On Thu, 6 Jul 2023 23:58:06 + Kenneth Raplee wrote: > Hi folks, > > I was made aware of the fwget(8) utility on IRC after mentioning how I > supplemented a missing amdgpu firmware from the gpu-firmware-kmod package for > my

Re: Possible PEBKAC bug for fwget(8)?

On 2023-Jul-07 08:03:40 +0100, Graham Perrin wrote: >PCI pictured at >, somehow I >don't imagine finding that type of slot inside the HP EliteBook where I ran >the command ;-) Whilst you probably don't have a full-size PCI or PCIe

Re: Possible PEBKAC bug for fwget(8)?

> Options: > -n-- Do not install package, only print the results > -v-- More verbose > ``` > > I tried running the command other ways, outputs the same thing. > > I didn't think this was worth reporting as a bug since it seems like a minor > fi

Re: Possible PEBKAC bug for fwget(8)?

On 07/07/2023 00:58, Kenneth Raplee wrote: … `fwget -vn pci`, it only prints out the following usage info: … I made what might have been the same mistake, . PCI pictured at , somehow I

Possible PEBKAC bug for fwget(8)?

, outputs the same thing. I didn't think this was worth reporting as a bug since it seems like a minor fix. % uname -aKU FreeBSD freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n263946-ac40021c935d: Tue Jul 4 09:10:17 PDT 2023 root@freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64

BUG: chflags(1) fails to remove uarch flag with hardlinked files (ZFS)

mod -R". Further details are in the bug report I just raised: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271925 Cheers, Jamie

Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) [code level bug evidence]

Mark Millard wrote: > So with -ddM why do I see lots of "cached_realpath:" > notices for the same path? For example: how many separate bmake instances are in that log? > > # grep "tmp/legacy/usr/sbin/ln\>" >

Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) [code level bug evidence]

On Feb 23, 2023, at 11:53, Mark Millard wrote: > cached_realpath only reports its "cached_realpath:" notice > (not the purging one) when it does not find the value via > HashTable_FindValue and so does a HashTable_Set : > > const char * > cached_realpath(const char *pathname, char *resolved) >

Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) [code level bug evidence]

cached_realpath only reports its "cached_realpath:" notice (not the purging one) when it does not find the value via HashTable_FindValue and so does a HashTable_Set : const char * cached_realpath(const char *pathname, char *resolved) { const char *rp; if (pathname == NULL ||

Re: [Bug 269133] bnxt(4): BCM57416 - HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error

Hi everyone, Seems that commit "2db35273502b3c35aa653effc5c97618567367ab" brakes bnxt driver for BCM57416 based cards. I have tried reverting the commit and the servers are now back online. if anyone has some spare time and energy, can please take a look at the commit, as I´m not sure what

Bug 206165 - resolv.conf(5) is missing documentation on options (i.e. EDNS0)

Hello folks, I ran today into a problem, that the reolveer option "edns0" isn't documented (as well as some others). Searching the net reveals, that there is a PR open with exactly that issue since January 2016, since then, code has changed I presume. Could someone please take care of that

Bug 264282 / Unable to boot from GELI encrypted UFS in 13.1 and -CURRENT

Hi, can someone have a look at Bug 264282 [0]? Booting from GELI encrypted / on UFS has been broken since bc9154a208248 from August 2021. That very annoying, especially when the system is unable to boot after an upgrade from 13.0 to 13.1. The bug report contains an analysis of the problem

[Bug 261018] An online manual page for FreeBSD 13.0-RELEASE misrepresents features that are in stable/13 – not released

On 07/01/2022 23:33, Graham Perrin wrote: Before I open a website bug report, someone please check my interpretation: * <621b5090487de9fed1b503769702a9a2a27cc7bb> (Refactor configuration management in bhyve) was committed 2021-03-18, MFC after three months, however (for whatever

Re: Potential bug in the dynamic linker?

On Fri, Nov 05, 2021 at 06:27:33PM +0100, obiwac wrote: > Let me preface this by saying that I am in no way knowledgeable enough > regarding the FreeBSD dynamic linker to know whether or not this is > infact a bug or intended behaviour. > > This program I'm working on, when compi

Potential bug in the dynamic linker?

Let me preface this by saying that I am in no way knowledgeable enough regarding the FreeBSD dynamic linker to know whether or not this is infact a bug or intended behaviour. This program I'm working on, when compiled for FreeBSD, calls fdlopen(3) to load a dynamic library from memory

Potential bug in the dynamic linker?

Let me preface this by saying that I am in no way knowledgeable enough regarding the FreeBSD dynamic linker to know whether or not this is infact a bug or intended behaviour. This program I'm working on, when compiled for FreeBSD, calls fdlopen(3) to load a dynamic library from memory

AMD64 UEFI loader: staging area: seeking a summary overview of D31121 and related bug reports

<https://reviews.freebsd.org/D31121> Amongst the related bug reports, <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209821#c48>: * suspects some kind of "special behaviour" with ASUS UEFI * also observes a regression in FreeBSD. Given other related bugs,

Re: BUG in libm's powf

-- >>>> steve >>>> >>>> On Mon, Sep 06, 2021 at 06:45:11PM +0100, Mark Murray wrote: >>>>> Hi >>>>> >>>>> I've opened a Phab ticket for this. I hope that's OK? >>>>> >>>>> https:/

Re: BUG in libm's powf

Hi! > > > On Mon, Sep 06, 2021 at 10:22:02PM +0200, Gordon Bergling wrote: > > > > could you turn to test program into an AFT test to prevent further > > > > regressions? > > > > > > I cannot tell if you are addressing Mark or me. > > > For me, I know nothing about ATF. > > > > man 7 atf > >

Re: BUG in libm's powf

On Mon, Sep 06, 2021 at 10:40:21PM +0200, Kurt Jaeger wrote: > Hi! > > > On Mon, Sep 06, 2021 at 10:22:02PM +0200, Gordon Bergling wrote: > > > could you turn to test program into an AFT test to prevent further > > > regressions? > > > > I cannot tell if you are addressing Mark or me. > > For

Re: BUG in libm's powf

Hi! > On Mon, Sep 06, 2021 at 10:22:02PM +0200, Gordon Bergling wrote: > > could you turn to test program into an AFT test to prevent further > > regressions? > > I cannot tell if you are addressing Mark or me. > For me, I know nothing about ATF. man 7 atf has more details. -- p...@opsec.eu

Re: BUG in libm's powf

On Mon, Sep 06, 2021 at 10:22:02PM +0200, Gordon Bergling wrote: > could you turn to test program into an AFT test to prevent further > regressions? > > —Gordon > I cannot tell if you are addressing Mark or me. For me, I know nothing about ATF. I do, however, suspect that this won't regress

Re: BUG in libm's powf

gt; >> I've opened a Phab ticket for this. I hope that's OK? > >> > >> https://reviews.freebsd.org/D31865 > >> > >> M > >> > >>> On 6 Sep 2021, at 16:28, Steve Kargl > >>> wrote: > >>> >

Re: BUG in libm's powf

urray wrote: >> Hi >> >> I've opened a Phab ticket for this. I hope that's OK? >> >> https://reviews.freebsd.org/D31865 >> >> M >> >>> On 6 Sep 2021, at 16:28, Steve Kargl >>> wrote: >>> >>> Paul Zimmermann has ide

Re: BUG in libm's powf

; > M > > > On 6 Sep 2021, at 16:28, Steve Kargl > > wrote: > > > > Paul Zimmermann has identified a bug in Openlibm's powf(), > > which is identical to FreeBSD's libm. Both derived from > > fdlibm. https://github.com/JuliaMath/openlibm/issues/212. >

Re: BUG in libm's powf

Hi I've opened a Phab ticket for this. I hope that's OK? https://reviews.freebsd.org/D31865 M > On 6 Sep 2021, at 16:28, Steve Kargl > wrote: > > Paul Zimmermann has identified a bug in Openlibm's powf(), > which is identical to FreeBSD's libm. Both derived from

BUG in libm's powf

Paul Zimmermann has identified a bug in Openlibm's powf(), which is identical to FreeBSD's libm. Both derived from fdlibm. https://github.com/JuliaMath/openlibm/issues/212. Consider % cat h.c #include #include int main(void) { float x, y, z; x = 0x1.ecp-1F; y = -0x1.02p+27F

FreeBSD service bug 256182 (was: What happen to mailing list archives?)

On 06/06/2021 00:28, Steve Kargl wrote: Hundreds of emails from me are now gone or sufficiently hidden that I cannot find them. More importantly, Bruce Evans often replied with reviews of libm patch's I sent the list. Those reviews and his detailed analysis of the libm code are now gone or

Re: Undefined compiler behaviour or a compiler bug?

On 4/30/21 12:13 AM, Dimitry Andric wrote: % clang -fsanitize=undefined test.c -o test Thank you! Didn't know about that flag. --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To

Re: Undefined compiler behaviour or a compiler bug?

On Fri, Apr 30, 2021 at 12:08 AM Hans Petter Selasky wrote: > Hi, > > Can someone please explain what C-compiler flag I'm missing, to make > this simple C-program terminate? > > I have a function _abs() which at some point is equal to one, but the > compiler thinks it is not required to emit the

Re: Undefined compiler behaviour or a compiler bug?

On 29 Apr 2021, at 23:11, Hans Petter Selasky wrote: > > On 4/29/21 11:06 PM, Hans Petter Selasky wrote: >> Hi, >> Can someone please explain what C-compiler flag I'm missing, to make this >> simple C-program terminate? >> I have a function _abs() which at some point is equal to one, but the

Re: Undefined compiler behaviour or a compiler bug?

On 4/29/21 11:06 PM, Hans Petter Selasky wrote: Hi, Can someone please explain what C-compiler flag I'm missing, to make this simple C-program terminate? I have a function _abs() which at some point is equal to one, but the compiler thinks it is not required to emit the test for the while()

Undefined compiler behaviour or a compiler bug?

Hi, Can someone please explain what C-compiler flag I'm missing, to make this simple C-program terminate? I have a function _abs() which at some point is equal to one, but the compiler thinks it is not required to emit the test for the while() at all, looking at the assembly code! A

[Bug 254698] RC4 from RC3 shutdown/reboot regression

|--- |Not A Bug --- Comment #4 from Andrey Fesenko --- Sorry, broken CentOS host Package edk2.git-ovmf-x64, search old version, work fine -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-current

[Bug 254698] RC4 from RC3 shutdown/reboot regression

hutdown: It does not look like a power down and your wording says it was a reboot. If a power down was actually requested instead of a "final reboot", you may want to add some notes to clarify how to interpret the report's intent. -- You are receiving this mail bec

[Bug 254698] RC4 from RC3 shutdown/reboot regression

-kvm but process not ended, vnc console live PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 127494 root 20 0 2532744 1.0g 18732 S 100.3 53.8 2:50.26 qemu-kvm -- You are receiving this mail because: You are on the CC list for the bug

[Bug 254698] RC4 from RC3 shutdown/reboot regression

one. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-uns

[Bug 254698] RC4 from RC3 shutdown/reboot regression

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254698 Bug ID: 254698 Summary: RC4 from RC3 shutdown/reboot regression Product: Base System Version: 13.0-STABLE Hardware: Any OS: Any Status: New

[Bug 254395] bsdinstall: fail script install after BETA3

|Closed -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "fr

[Bug 254395] bsdinstall: fail script install after BETA3

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395 --- Comment #15 from commit-h...@freebsd.org --- A commit in branch releng/13.0 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3ef46634cd5a6ba0e156d5da095bbee5f63ec1cd commit 3ef46634cd5a6ba0e156d5da095bbee5f63ec1cd

[Bug 254395] bsdinstall: fail script install after BETA3

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395 --- Comment #14 from commit-h...@freebsd.org --- A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=4601382e1362352f17a33e4ed38db5dcfe3f6be5 commit 4601382e1362352f17a33e4ed38db5dcfe3f6be5

[Bug 254395] bsdinstall: fail script install after BETA3

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395 --- Comment #13 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=c2f16c595eb51c6e0cb6ece3f6f078d738019059 commit c2f16c595eb51c6e0cb6ece3f6f078d738019059 Author

[Bug 254395] bsdinstall: fail script install after BETA3

ecause: You are on the CC list for the bug. ___ 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: [Bug 254395] bsdinstall: fail script install after BETA3

>>> such, any > >> >>> file in the release tarballs can't be extracted to FAT32. For > >> interactive > >> >>> installations, the bsdinstall distextract tool, a CURSES-y frontend > to > >> >>> libarchive, solves this by igno

Re: [Bug 254395] bsdinstall: fail script install after BETA3

frontend to >>> libarchive, solves this by ignoring ctime/mtime errors. >>> >>> Some extra commentary on solutions, so it can be in one place. >>> Possibilities >>> are: >>> >>> 1. We drop /boot/efi from mtree. That will result in it not existin

Re: [Bug 254395] bsdinstall: fail script install after BETA3

AT32. For > interactive > >>> installations, the bsdinstall distextract tool, a CURSES-y frontend to > >>> libarchive, solves this by ignoring ctime/mtime errors. > >>> > >>> Some extra commentary on solutions, so it can be in one place. > >

Re: [Bug 254395] bsdinstall: fail script install after BETA3

be in one place. >>> Possibilities >>> are: >>> >>> 1. We drop /boot/efi from mtree. That will result in it not existing in >>> base.txz, solving this issue, but will result in it not being in >>> mtree. It will >>> also leave in place an

Re: [Bug 254395] bsdinstall: fail script install after BETA3

;> libarchive, solves this by ignoring ctime/mtime errors. >> >> Some extra commentary on solutions, so it can be in one place. >> Possibilities >> are: >> >> 1. We drop /boot/efi from mtree. That will result in it not existing in >> base.txz, solving this issu

Re: [Bug 254395] bsdinstall: fail script install after BETA3

, solving this issue, but will result in it not being in mtree. It will also leave in place an identical bug that will break scripted installation on bare-metal POWER8 and POWER9 systems, although that is a tier-2 platform. 2. We add an option to tar to ignore failure in setting ctime/mtime, like

[Bug 254395] bsdinstall: fail script install after BETA3

because it is pretty invasive. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "fr

[Bug 254395] bsdinstall: fail script install after BETA3

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395 --- Comment #10 from Warner Losh --- (In reply to Ryan Moeller from comment #8) Oh! I like this idea better, I think, but I don't know how hard it is to do. -- You are receiving this mail because: You are on the CC list for the bug

[Bug 254395] bsdinstall: fail script install after BETA3

-ESP boot partions. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-cu

[Bug 254395] bsdinstall: fail script install after BETA3

there to ensure the mountpoint exists. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "fr

[Bug 254395] bsdinstall: fail script install after BETA3

he's been touching that code most recently. Or delphij@ as he has too... -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current

[Bug 254395] bsdinstall: fail script install after BETA3

. It will also leave in place an identical bug that will break scripted installation on bare-metal POWER8 and POWER9 systems, although that is a tier-2 platform. 2. We add an option to tar to ignore failure in setting ctime/mtime, like the interactive installer uses. This has the difficulty that the patch

[Bug 254395] bsdinstall: fail script install after BETA3

://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231027 [Bug 231027] [META] FreeBSD-Foundation sponsored issues for FreeBSD 13-CURRENT -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-current@freebsd.org mailing list

[Bug 254395] bsdinstall: fail script install after BETA3

the efi partition smaller, since 260M is a lot for a virtual machine, where there will be only 1 system -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org

[Bug 254395] bsdinstall: fail script install after BETA3

rror -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"

[Bug 254395] bsdinstall: fail script install after BETA3

is mail because: You are on the CC list for the bug. ___ 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"

[Bug 254395] bsdinstall: fail script install after BETA3

templatep2 / ufs rw 1 1 /dev/zvol/storage/bhyve/14.0-CURRENT/a771bf748f9/templatep3 none swapsw 0 0 -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-current@f

[Bug 254395] bsdinstall: fail script install after BETA3

script? What are you untarring? -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "fr

[Bug 254395] bsdinstall: fail script install after BETA3

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395 Bug ID: 254395 Summary: bsdinstall: fail script install after BETA3 Product: Base System Version: 13.0-STABLE Hardware: Any OS: Any Status: New

UFS Resize Not Working Bug 253754

Hello long time not work growfs root 13.0-BETA4 and Current, bhyve and vmware check. Bump https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253754 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current

  1   2   3   4   5   6   7   8   9   10   >