Re: Panic with "Unrecoverable machine check exception"

n Fri, Jun 27, 2025 at 04:52:53PM -0400, Alexander Motin wrote: > Hi. > > It is likely a hardware failure, unless a false positive. Check last > console logs or better BMC logs for detail. > > On Fri, Jun 27, 2025, 16:26 Steve Kargl > wrote: > > > Never see

Re: drm panic after new world

On Fri, Jun 06, 2025 at 07:29:27PM -0700, Steve Kargl wrote: > > I've narrowed the range to > > Good: 2025-04-24 9b2a503a1179 - main - e6000sw: add support for 88E6190X > Bad: 2025-04-29 6c3a4b5f9b7b - main - alloca.3: move to share/man/man3 > > Good means boots

Re: drm panic after new world

On 6/5/25 17:18, Bjoern A. Zeeb wrote: On Thu, 5 Jun 2025, Steve Kargl wrote: On Thu, Jun 05, 2025 at 08:22:45AM +, Bjoern A. Zeeb wrote: Sorting away wireless changes from sys/compat/..  here's what's left: % git log --oneline adc33d3288..8d136fb027 sys/compat/ | grep -v 802

Re: drm panic after new world

On Thu, Jun 05, 2025 at 08:22:45AM +, Bjoern A. Zeeb wrote: > > Sorting away wireless changes from sys/compat/.. here's what's left: > > % git log --oneline adc33d3288..8d136fb027 sys/compat/ | grep -v 802.11 | > grep -v skbuff | grep -v wsum | grep -v ASMEDIA > 325aa4dbd10d linuxkpi: Intro

Re: drm panic after new world

On 6/5/25 01:22, Bjoern A. Zeeb wrote: On Wed, 4 Jun 2025, Steve Kargl wrote: On 6/4/25 13:11, Steve Kargl wrote: On Tue, Jun 03, 2025 at 06:45:31PM -0700, Steve Kargl wrote: I was able to rebuild world/kernel for a 2025-04-15 src/ (aka adc33d3288) and rebuilt drm-515-kmod and gpu-firmware

Re: drm panic after new world

On 6/4/25 13:11, Steve Kargl wrote: On Tue, Jun 03, 2025 at 06:45:31PM -0700, Steve Kargl wrote: I was able to rebuild world/kernel for a 2025-04-15 src/ (aka adc33d3288) and rebuilt drm-515-kmod and gpu-firmware. The system boots and I can kldload radeonkmd.ko. startx brings up the expected

Re: drm panic after new world

On Tue, Jun 03, 2025 at 06:45:31PM -0700, Steve Kargl wrote: > > Well, out of the frying pan and into the fire... > > Apparently, building world with old src/ on a system > running a newer world and installing that old world > over the new world is bad. To start install(1) is

Re: drm panic after new world

On 6/4/25 00:44, Mark Millard wrote: Steve Kargl wrote on Date: Wed, 04 Jun 2025 01:45:31 UTC : Well, out of the frying pan and into the fire... Apparently, building world with old src/ on a system running a newer world and installing that old world over the new world is bad. To start

Re: drm panic after new world

On 6/3/25 16:36, Steve Kargl wrote: On Tue, Jun 03, 2025 at 08:00:00AM -0700, Steve Kargl wrote: On 6/3/25 02:56, Matthew Seaman wrote: On 02/06/2025 23:35, Steve Kargl wrote: How does one use dates to checkout a particular head? If I'm at the top of HEAD and need to got back to mid-feb

Re: drm panic after new world

On Tue, Jun 03, 2025 at 08:00:00AM -0700, Steve Kargl wrote: > On 6/3/25 02:56, Matthew Seaman wrote: > > On 02/06/2025 23:35, Steve Kargl wrote: > > > How does one use dates to checkout a particular head? > > > If I'm at the top of HEAD and need to got back t

Re: drm panic after new world

On 6/3/25 02:56, Matthew Seaman wrote: On 02/06/2025 23:35, Steve Kargl wrote: How does one use dates to checkout a particular head? If I'm at the top of HEAD and need to got back to mid-february, what's the easiest option for performing a bisection by hand? Something like:   gi

Re: drm panic after new world

On Mon, Jun 02, 2025 at 03:44:37PM -0700, David Wolfskill wrote: > On Mon, Jun 02, 2025 at 03:35:50PM -0700, Steve Kargl wrote: > > ... > > How does one use dates to checkout a particular head? > > If I'm at the top of HEAD and need to got back to > > mid-februar

Re: drm panic after new world

On Thu, May 29, 2025 at 02:37:08PM -0700, Steve Kargl wrote: > On Thu, May 29, 2025 at 01:06:22PM -0700, Steve Kargl wrote: > > __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57 > > 57 __asm("movq %%gs:%c1,%0" : "=r" (td) > > (kgdb)

Re: drm panic after new world

On Thu, May 29, 2025 at 01:06:22PM -0700, Steve Kargl wrote: > __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57 > 57__asm("movq %%gs:%c1,%0" : "=r" (td) > (kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57 > td =

Re: drm panic after new world

On Thu, May 29, 2025 at 01:06:22PM -0700, Steve Kargl wrote: > > After rebuilding world and installing, I rebuilt the drm-515 > port and the accompanying gpu-firmware. This port has worked > upto this update. Upon running xinit to load Xorg, I am > greeted with the panic followin

Re: Samsung T7 external SSD support?

On 4/4/25 19:44, Steve Kargl wrote: On 4/4/25 19:28, Alexander Motin wrote: On 04.04.2025 21:45, Steve Kargl wrote: Anyone using a Samsung T7 external SSD with FreeBSD current? If I plug the drive into a USB 2.0 port, I see usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage

Re: Samsung T7 external SSD support?

On 4/4/25 19:28, Alexander Motin wrote: On 04.04.2025 21:45, Steve Kargl wrote: Anyone using a Samsung T7 external SSD with FreeBSD current? If I plug the drive into a USB 2.0 port, I see usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device Samsung PSSD T7 Shield (0x04e8

Samsung T7 external SSD support?

Anyone using a Samsung T7 external SSD with FreeBSD current? If I plug the drive into a USB 2.0 port, I see usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device Samsung PSSD T7 Shield (0x04e8:0x61fb) ugen0.2: at usbus0 umass0 on uhub1 umass0: on usbus0 umass0: SCSI over

Re: llvm ld vs binutils ld

On Fri, Feb 02, 2024 at 10:48:54PM +0200, Konstantin Belousov wrote: > On Fri, Feb 02, 2024 at 12:07:35PM -0800, Steve Kargl wrote: > > > > Thanks for the explanation, but I think I now have a conundrum. > > Suppose I have two shared libraries libfoo.so and libbar.so, and >

Re: llvm ld vs binutils ld

On Sun, Jan 28, 2024 at 12:04:48PM +0200, Konstantin Belousov wrote: > On Sat, Jan 27, 2024 at 09:22:59PM -0800, Steve Kargl wrote: > > On Sat, Jan 27, 2024 at 10:29:34PM +0100, Dimitry Andric wrote: > > > On 27 Jan 2024, at 18:08, Steve Kargl > > > wrote: > &

Re: llvm ld vs binutils ld

On Sat, Jan 27, 2024 at 10:29:34PM +0100, Dimitry Andric wrote: > On 27 Jan 2024, at 18:08, Steve Kargl > wrote: > > > > In an attempt to cleanup a bit of src/lib/msun, I ran into > > a small issue that I cannot explain at the moment. If I have > > /usr/bin/ld

llvm ld vs binutils ld

In an attempt to cleanup a bit of src/lib/msun, I ran into a small issue that I cannot explain at the moment. If I have /usr/bin/ld in my path prior to /usr/local/bin/ld everything works % which ld /usr/bin/ld % make clean && make cleandepend % make and I have a libm.so.5. But if /usr/local/bin

RCS and $FreeBSD$ purge

I'm currently syncing src/lib/msun with my private libm repository where I do much of my hacking on libm issues. In looking at diffs, I see a few lingering RCS and $FreeBSD$ tags. For example, lib/msun/amd64/s_scalbnl.S contains /* RCSID("$NetBSD: s_scalbnf.S,v 1.4 1999/01/02 05:15:40 kristerw E

Re: Proposal: Disable compression of newsyslog by default

On Sat, Dec 23, 2023 at 11:13:23AM -0800, Xin Li wrote: > > I appreciate your perspective on this issue. However, I believe there are > additional benefits to modifying the newsyslog code (which is already done > in commit 906748d208d3, by the way) beyond what can be achieved by simply > adjusting

Re: panic in cypto code

On Thu, Oct 05, 2023 at 03:11:02PM -0700, Steve Kargl wrote: > > I'll ping you off list when it's available. > Well, this is interesting. I cannot upload the files to a location from which I can then put them up on freefall. :( % scp -P1234 kernel.debug 10.95.

Re: panic in cypto code

On Thu, Oct 05, 2023 at 11:33:46PM +0200, Kristof Provost wrote: > On 5 Oct 2023, at 19:34, Steve Kargl wrote: > > On Thu, Oct 05, 2023 at 06:05:37PM +0200, Kristof Provost wrote: > >> > >> On 5 Oct 2023, at 17:36, Steve Kargl wrote: > >>> In case anyone else

Re: panic in cypto code

On Thu, Oct 05, 2023 at 06:05:37PM +0200, Kristof Provost wrote: > Hi Steve, > > On 5 Oct 2023, at 17:36, Steve Kargl wrote: > > In case anyone else is using openvpn. > > > > % pkg info openvpn > > openvpn-2.6.6 > > Name : openvpn > > Versio

panic in cypto code

In case anyone else is using openvpn. % pkg info openvpn openvpn-2.6.6 Name : openvpn Version: 2.6.6 Installed on : Tue Sep 19 08:48:55 2023 PDT Origin : security/openvpn Architecture : FreeBSD:15:amd64 % uname -a FreeBSD hotrats 15.0-CURRENT #1 main-n265325-9c30461

Re: 14.0-CURRENT boots fine but keyboard does not work

On Tue, Sep 05, 2023 at 01:29:34PM -0600, Warner Losh wrote: > +/* > + * Some Chromebooks don't confirm to the google comment above so do the s/confirm/conform ? > + * Chromebook workaround for all <= 2018 coreboot systems that have a > + * 'blank' version. At least once Acer "

Re: core dump in ld during buildworld

On Sun, Feb 19, 2023 at 07:21:54PM +0100, Dimitry Andric wrote: > On 19 Feb 2023, at 06:15, Steve Kargl > wrote: > > > > On Sat, Feb 18, 2023 at 04:57:45PM -0800, Steve Kargl wrote: > >>> > >>> At that point it is still using the system compiler and

Re: core dump in ld during buildworld

On Sat, Feb 18, 2023 at 04:57:45PM -0800, Steve Kargl wrote: > > > > At that point it is still using the system compiler and linker, and it > > seems that the latter is lld. Do you know which version it is? > > > > Good question. Unfortunate ident(1) is useless

Re: core dump in ld during buildworld

On Sun, Feb 19, 2023 at 01:50:07AM +0100, Dimitry Andric wrote: > On 19 Feb 2023, at 01:33, Steve Kargl > wrote: > > > > During biuldworld, > > > > ==> usr.bin/nm (obj,all,install) > > cc -O2 -pipe -g -fno-common -I/usr/src/contrib/elftoolchain/libelf

core dump in ld during buildworld

During biuldworld, ==> usr.bin/nm (obj,all,install) cc -O2 -pipe -g -fno-common -I/usr/src/contrib/elftoolchain/libelftc -I/usr/src/contrib/elftoolchain/common -std=gnu99 -Wno-format-zero-length -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-proto

Re: buildworld failure

On Sat, Feb 18, 2023 at 12:33:11AM -0800, Jeffrey Bouquet wrote: > Building /usr/obj/usr/src/amd64.amd64/tools/build/test-includes/sys_bitcount.c > Building /usr/obj/usr/src/amd64.amd64/tools/build/test-includes/sys_bitcount.o > sys_bitcount.c:1:10: fatal error: 'sys/bitcount.h' file not found > #i

Re: The dma mess

On Mon, Dec 05, 2022 at 05:30:50PM +0100, Baptiste Daroussin wrote: > On Mon, Dec 05, 2022 at 07:42:29AM -0800, Steve Kargl wrote: > > If one has not seen Mike Karel's email, here's the URL. > > > > https://lists.freebsd.org/archives/dev-commits-src-main/2022-De

The dma mess

If one has not seen Mike Karel's email, here's the URL. https://lists.freebsd.org/archives/dev-commits-src-main/2022-December/011300.html The upshot is 1) No entry in src/UPDATING about dma replacing sendmail, and thereby breaking a function system on upgrade. 2) Having sendmail_enable="YES

Re: CA's TLS Certificate Bundle in base = BAD

On Sat, Dec 03, 2022 at 08:26:16PM -0500, grarpamp wrote: > there or for some other reason. That's all bad news :( But can be fixed :) > It looks like the FreeBSD mailing list software stripped your attachment with your patch. Can you try sending it again with the patch in-line? -- steve

Re: A panic a day

On Thu, Sep 22, 2022 at 03:00:53PM -0400, Mark Johnston wrote: > > I think this untested patch will address the panics. The bug was there > for a long time but some recent restructuring added an assertion which > caught it. > > diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c > index 9

Re: A panic a day

On Thu, Sep 22, 2022 at 09:07:08PM +0200, Mateusz Guzik wrote: > On 9/22/22, Steve Kargl wrote: > > On Thu, Sep 22, 2022 at 03:00:53PM -0400, Mark Johnston wrote: > >> On Thu, Sep 22, 2022 at 11:31:40AM -0700, Steve Kargl wrote: > >> > All, > >> > >

Re: A panic a day

On Thu, Sep 22, 2022 at 03:00:53PM -0400, Mark Johnston wrote: > On Thu, Sep 22, 2022 at 11:31:40AM -0700, Steve Kargl wrote: > > All, > > > > I updated my kernel/world/all ports on Sept 19 2022. > > Since then, I have had daily panics and hard lock-up > > (n

A panic a day

All, I updated my kernel/world/all ports on Sept 19 2022. Since then, I have had daily panics and hard lock-up (no panic, keyboard, mouse, network, ...). The one panic I did witness sent text scolling off the screen. There is no dump, or at least, I haven't figured out a way to get a dump. Using

Re: buildkernel is broken

On Thu, Jul 07, 2022 at 07:59:29PM +0200, Kristof Provost wrote: > On 7 Jul 2022, at 19:00, Steve Kargl wrote: > > > The fix in > > 37f604b49d4a seems rather questionable especially given > > that there is no comment about why the macro is expanded > > to a zero-trip

Re: buildkernel is broken

On Thu, Jul 07, 2022 at 10:37:40AM -0600, Warner Losh wrote: > On Thu, Jul 7, 2022 at 10:37 AM Steve Kargl < > s...@troutmask.apl.washington.edu> wrote: > > > Thanks, but > > > > root[216] git cherry-pick -n 37f604b49d4a > > fatal: bad revision '

Re: buildkernel is broken

; to apply the fix to your local tree without committing > it or leaving it staged for commit. > > On Thu, Jul 7, 2022 at 10:50 AM Steve Kargl > wrote: > > > > On Thu, Jul 07, 2022 at 10:38:43AM -0400, Ryan Stone wrote: > > > Okay, update your tree and it should be f

Re: buildkernel is broken

On Thu, Jul 07, 2022 at 10:38:43AM -0400, Ryan Stone wrote: > Okay, update your tree and it should be fixed then. Is it possible to pull just that fix? I spent part of yesterday building world, and contrary to popular belief, not all hardware contain a 32-core uber-fast ryzen cpu. Can people ple

Re: buildkernel is broken

Yes, I do. Deleting the line allows to code to compile. -- steve On Thu, Jul 07, 2022 at 08:24:47AM -0400, Ryan Stone wrote: > Do you have VNET disabled in your kernel config? I believe that this > was fixed by 37f604b49d4a. > > On Thu, Jul 7, 2022 at 1:07 AM Steve Ka

buildkernel is broken

-std=iso9899:1999 -Werror /usr/src/sys/netinet/tcp_input.c --- modules-all --- /usr/src/sys/netpfil/ipfw/ip_dn_io.c:674:4: error: 'continue' statement not in loop statement continue; ^ 1 error generated. *** [ip_dn_io.o] Error code 1 make[4]: stoppe

Re: Profiled libraries on freebsd-current

On Wed, May 04, 2022 at 01:22:57PM -0700, John Baldwin wrote: > On 5/4/22 12:53 PM, Steve Kargl wrote: > > On Wed, May 04, 2022 at 11:12:55AM -0700, John Baldwin wrote: > > > > I don't know the entire FreeBSD ecosystem. Do people > > use FreeBSD on embedd

Re: Profiled libraries on freebsd-current

On Wed, May 04, 2022 at 11:12:55AM -0700, John Baldwin wrote: > On 5/2/22 10:37 AM, Steve Kargl wrote: > > On Mon, May 02, 2022 at 12:32:25PM -0400, Ed Maste wrote: > > > On Sun, 1 May 2022 at 11:54, Steve Kargl > > > wrote: > > > > > > > >

Re: Profiled libraries on freebsd-current

On Mon, May 02, 2022 at 10:37:00AM -0700, Steve Kargl wrote: > On Mon, May 02, 2022 at 12:32:25PM -0400, Ed Maste wrote: > > On Sun, 1 May 2022 at 11:54, Steve Kargl > > wrote: > > > > > > diff --git a/gcc/config/freebsd-spec.h b/gcc/config/freebsd-spec.h >

Re: Profiled libraries on freebsd-current

On Mon, May 02, 2022 at 12:32:25PM -0400, Ed Maste wrote: > On Sun, 1 May 2022 at 11:54, Steve Kargl > wrote: > > > > diff --git a/gcc/config/freebsd-spec.h b/gcc/config/freebsd-spec.h > > index 594487829b5..1e8ab2e1827 100644 > > --- a/gcc/config/freebsd-spec.

Re: Profiled libraries on freebsd-current

On Sat, Apr 30, 2022 at 04:07:48PM -0400, Ed Maste wrote: > On Sat, 30 Apr 2022 at 11:34, Steve Kargl > wrote: > > > > On Sat, Apr 30, 2022 at 09:39:32AM -0400, Ed Maste wrote: > > > On Fri, 29 Apr 2022 at 01:58, Steve Kargl > > > wrote: > > > >

Re: Profiled libraries on freebsd-current

On Sat, Apr 30, 2022 at 09:39:32AM -0400, Ed Maste wrote: > On Fri, 29 Apr 2022 at 01:58, Steve Kargl > wrote: > > > > If one looks at src.conf(5), one finds > > > >WITH_PROFILE > > Build profiled libraries for use with gprof(8). This option i

Re: Profiled libraries on freebsd-current

On Fri, Apr 29, 2022 at 02:54:17PM -0700, Mark Millard wrote: > On 2022-Apr-29, at 13:12, Steve Kargl > wrote: > > > The evenual absence of libc_p.a and libm_p.a will break GCC's > > -pg option in GCC. One will then need to know how to change the > > GCC source

Re: Profiled libraries on freebsd-current

On Fri, Apr 29, 2022 at 12:51:12PM -0700, Mark Millard wrote: > On 2022-Apr-29, at 12:38, Mark Millard wrote: > > > https://cgit.freebsd.org/src/commit/?id=175841285e289edebb6603da39f02549521ce950 > > says the following (later), but first I quote the part tbat dirves the > > interpretation: > >

Re: Profiled libraries on freebsd-current

On Thu, Apr 28, 2022 at 10:56:48PM -0700, Steve Kargl wrote: > If one looks at src.conf(5), one finds > >WITH_PROFILE > Build profiled libraries for use with gprof(8). This option is > deprecated and is not present in FreeBSD 14. > > I assume that the

Profiled libraries on freebsd-current

If one looks at src.conf(5), one finds WITH_PROFILE Build profiled libraries for use with gprof(8). This option is deprecated and is not present in FreeBSD 14. I assume that the *_p.a libraries will no longer be built and installed on FreeBSD 14 and later. Is this correct?

Re: Daily black screen of death

On Thu, Apr 21, 2022 at 09:44:04AM +0200, Emmanuel Vadot wrote: > > Hello Steve, > > On Tue, 19 Apr 2022 11:32:32 -0700 > Steve Kargl wrote: > > > FYI, > > > > I'm experiencing an almost daily black screen of death panic. > > Kernel, worl

Daily black screen of death

FYI, I'm experiencing an almost daily black screen of death panic. Kernel, world, drm-current-kmod, and gpu-firmware-kmod were all rebuilt and installed at the same time. Uname shows FreeBSD 14.0-CURRENT #0 main-n254360-eb9d205fa69: Tue Apr 5 13:49:47 PDT 2022 So, April 5th sources. The panic

Re: What to do about tgammal?

On Tue, Dec 21, 2021 at 03:46:40PM +0100, Marc Fonvieille wrote: > Le 20.12.2021 16:48, Steve Kargl a écrit : > > On Mon, Dec 20, 2021 at 11:15:53AM +0100, Marc Fonvieille wrote: > > > > > > I assume what Steve is talking about is the corresponding value in > &g

Re: What to do about tgammal?

On Mon, Dec 20, 2021 at 11:15:53AM +0100, Marc Fonvieille wrote: > > I assume what Steve is talking about is the corresponding value in > decimal of the number of ULP. > Bad assumption. Please read Goldberg's paper. I am talking about ULP in the underlying floating point format. -- Steve

Re: What to do about tgammal?

On Sat, Dec 18, 2021 at 10:41:14AM +, Mark Murray wrote: > > Hmm. I think my understanding of ULP is missing something? > > I thought that ULP could not be greater than the mantissa size > in bits? > > I.e., I thought it represents average rounding error (compared with > "perfect rounding"),

Re: What to do about tgammal?

On Tue, Dec 14, 2021 at 10:21:55PM +, Mark Murray wrote: > On 14 Dec 2021, at 21:51, Steve Kargl > wrote: > > Interval max ULP x at Max ULP > > [6,1755.1]0.873414 at 1.480588145237629047468e+03 > > [1.0662,6]0.861508 at 1.999467927053

Re: What to do about tgammal?

On Tue, Dec 14, 2021 at 03:47:17PM -0700, Warner Losh wrote: > On Tue, Dec 14, 2021 at 3:23 PM Mark Murray wrote: > > > On 14 Dec 2021, at 21:51, Steve Kargl > > wrote: > > > Interval max ULP x at Max ULP > > > [6,1755.1]0.8

Re: What to do about tgammal?

On Tue, Dec 14, 2021 at 06:26:13PM +, Mark Murray wrote: > > This is now visible for review at > https://reviews.freebsd.org/D33444 > I see imp lamented that that fact that he is not sufficiently versed in the numerical methods used (neither am I!). bde

Re: What to do about tgammal?

On Tue, Dec 14, 2021 at 06:26:13PM +, Mark Murray wrote: > > This is now visible for review at > https://reviews.freebsd.org/D33444 > Just looked at this again. I cannot tell from the diff whether you've 'git mv' src/imprecise.c to ld128/b_tgammal.c. T

Re: What to do about tgammal?

On Tue, Dec 14, 2021 at 06:26:13PM +, Mark Murray wrote: > > This is now visible for review at > https://reviews.freebsd.org/D33444 > Thanks! I looks okay to me (but, of course, I wrote the patch ;-) BTW, I'll probably take a shot at ld128 tgammal(x) th

Re: What to do about tgammal?

On Sat, Dec 04, 2021 at 11:48:13PM +, Mark Murray wrote: > > > > On 4 Dec 2021, at 18:53, Steve Kargl > > wrote: > > > > > > So, is anyone interested in seeing a massive patch? > > Me, please! > So, I have the ld80 case working. I

Re: What to do about tgammal?

On Sat, Dec 04, 2021 at 11:48:13PM +, Mark Murray wrote: > > > > On 4 Dec 2021, at 18:53, Steve Kargl > > wrote: > > > > > > So, is anyone interested in seeing a massive patch? > > Me, please! > It is ld80 only. ld128 is still broken. I&

Re: What to do about tgammal?

On Sat, Dec 04, 2021 at 08:40:56PM +0100, Hans Petter Selasky wrote: > On 12/4/21 19:53, Steve Kargl wrote: > > What to do about tgammal? (trim some history) > > > >Interval | Max ULP > > ---+ > > [6,171]

What to do about tgammal?

What to do about tgammal? A long time ago (2013-09-06), theraven@ committed a kludge that mapped several missing long double math functions to double math functions (e.g., tanhl(x) was mapped to tanh(x)). Over the next few years, I (along with bde and das reviews) provided Intel 80-bit (ld80) and

Re: WHY? commit ac76bc1145dd7f4476e5d982ce8f355f71015713

On Fri, Nov 05, 2021 at 03:14:46PM -0700, Steve Kargl wrote: > On Fri, Nov 05, 2021 at 10:32:26PM +0100, Dimitry Andric wrote: > > On 5 Nov 2021, at 21:13, Steve Kargl > > wrote: > > > > > > Why was this committed? > > > > > > commit ac

Re: WHY? commit ac76bc1145dd7f4476e5d982ce8f355f71015713

On Fri, Nov 05, 2021 at 10:32:26PM +0100, Dimitry Andric wrote: > On 5 Nov 2021, at 21:13, Steve Kargl > wrote: > > > > Why was this committed? > > > > commit ac76bc1145dd7f4476e5d982ce8f355f71015713 > > Author: Dimitry Andric > > Date: Tue Feb

WHY? commit ac76bc1145dd7f4476e5d982ce8f355f71015713

Why was this committed? commit ac76bc1145dd7f4476e5d982ce8f355f71015713 Author: Dimitry Andric Date: Tue Feb 9 22:06:51 2021 +0100 Fix lib/msun's ctrig_test/test_inf_inputs test case with clang >= 10 This sprinkles a few strategic volatiles in an attempt to defeat clang's opti

Re: [LIBM] One step closer to C99 conformance

On Fri, Nov 05, 2021 at 01:25:42PM -0400, Ed Maste wrote: > On Thu, 4 Nov 2021 at 21:09, Steve Kargl > wrote: > > > > A patch has been attached to > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216862 > > > > which implements cexpl(). >

[LIBM] One step closer to C99 conformance

A patch has been attached to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216862 which implements cexpl(). Note, the patch includes some bug fixes for libm on ld128 hardware. -- Steve

Re: access to ld128 system

On Thu, Oct 28, 2021 at 03:28:51PM -0700, Steve Kargl wrote: > kib@ recently committed my implementations of cospi[fl], > sinpi[fl], and tanpi[fl]. These functions have been > extensively tested for float, double, and long double > where long double is the Intel 80-bit long double (

access to ld128 system

kib@ recently committed my implementations of cospi[fl], sinpi[fl], and tanpi[fl]. These functions have been extensively tested for float, double, and long double where long double is the Intel 80-bit long double (e.g., msun/ld80/s_sinpil.c). The 128-bit versions of these routines have not been t

Re: Missing Copyright?

freebsd.org/src/commit/?id=3550a49f6814af38c21b0033ef8746953451dade > > Since the license is a verbatim copy of the standard SPDX license, I tagged > it using our draft license policy's > suggested SPDX-License-Identifier: tag. > > Warner > > On Fri, O

Missing Copyright?

It seems that git commit f5542795b99206a2b4e5a57429d18b9478264e24 replaced the fdlibm implementations of s_scalbn.c, s_scalbnf.c, and s_scalbnl.c by those in MUSL. There are no Copyright notices in these files. There is no statement to the originals of these files within the files. If one looks

Re: Future of ident(1)

On Fri, Oct 22, 2021 at 03:51:15PM -0600, Warner Losh wrote: > On Fri, Oct 22, 2021 at 3:30 PM Steve Kargl < > s...@troutmask.apl.washington.edu> wrote: > > > All, > > > > With the new world order, what is the future of ident(1)? > > Should it be removed fro

Future of ident(1)

All, With the new world order, what is the future of ident(1)? Should it be removed from base? Given a compiled binary in base, how does one find the equivalent git info that ident(1) used to perform? Having a few minutes to dust off old patchs for libm, should I remove $FreeBSD$ tags in files I

Re: killall, symlinks, and signal delivery?

On Wed, Sep 08, 2021 at 02:10:47AM +0100, Jamie Landeg-Jones wrote: > Steve Kargl wrote: > > > Yes, that's likely. So, it could be a change in behavior > > for ImageMagick. Your suggested ps command doesn't provide > > I don't know when the chan

Re: killall, symlinks, and signal delivery?

On Tue, Sep 07, 2021 at 04:20:30PM -0700, Cy Schubert wrote: > On September 7, 2021 3:42:53 PM PDT, Steve Kargl > wrote: > >I have stumbled about a quandry, which I hope someone > >can shed some light upon. In my day job, I often > >generate a sequence of images and disp

killall, symlinks, and signal delivery?

I have stumbled about a quandry, which I hope someone can shed some light upon. In my day job, I often generate a sequence of images and display these images with ImageMagick's display command. From my csh prompt, a quick and dirty foreach() loop % foreach i (*.png) > display $i & > sleep 3 > en

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 me

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 as

Re: BUG in libm's powf

No, thank you for the quick response. Of course, a one character diff might be easier to review. :-) -- steve On Mon, Sep 06, 2021 at 06:55:07PM +0100, Mark Murray wrote: > Thanks! > > And it's committed! > > M > > > On 6 Sep 2021, at 18:53, Steve Kargl >

Re: BUG in libm's powf

.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 > > fdlibm. https://github.com/JuliaMath

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;

Re: Fwd: Information for freebsd-current@FreeBSD.org

The mailing lists are migrating from mailman to Mlmmj. I suspect, but haven't verified, that this is the new norm for the monthly notice about mailing list subscriptions. I would suggesting reading the mailing list archives, but needs to guess where the relevent discussion might be found. If you

Re: panic: vm_domainset_iter_first: Unknown policy 15168

On Tue, Jul 20, 2021 at 02:36:39PM -0400, Mark Johnston wrote: > > I see, it looks like there is some generic memory corruption triggered > by the UDF implementation. Our implementation is fairly stale, > unfortunately, but it shouldn't trigger a panic. >` > If you don't already have INVARIANTS c

Re: panic: vm_domainset_iter_first: Unknown policy 15168

On Tue, Jul 20, 2021 at 12:15:58PM -0400, Mark Johnston wrote: > On Tue, Jul 20, 2021 at 09:07:04AM -0700, Steve Kargl wrote: > > On Mon, Jul 19, 2021 at 07:05:03PM -0700, Steve Kargl wrote: > > > On Mon, Jul 19, 2021 at 07:55:07PM -0400, Mark Johnston wrote: > > > >

Re: panic: vm_domainset_iter_first: Unknown policy 15168

On Mon, Jul 19, 2021 at 07:05:03PM -0700, Steve Kargl wrote: > On Mon, Jul 19, 2021 at 07:55:07PM -0400, Mark Johnston wrote: > > On Mon, Jul 19, 2021 at 03:02:19PM -0700, Steve Kargl wrote: > > > > > > (kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu

Re: panic: vm_domainset_iter_first: Unknown policy 15168

On Mon, Jul 19, 2021 at 07:55:07PM -0400, Mark Johnston wrote: > On Mon, Jul 19, 2021 at 03:02:19PM -0700, Steve Kargl wrote: > > > > (kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 > > #1 doadump (textdump=textdump@entry=1) > > at /usr/src/s

panic: vm_domainset_iter_first: Unknown policy 15168

While reading files from a UDF filesystem, I received the following panic. I have the core file and kernel if anyone is interested. Unread portion of the kernel message buffer: panic: vm_domainset_iter_first: Unknown policy 15168 cpuid = 2 time = 1626730195 KDB: stack backtrace: db_trace_self_w

Re: Files in /etc containing empty VCSId header

On Thu, Jun 10, 2021 at 03:26:58PM -0700, Kevin Oberman wrote: > On Wed, Jun 9, 2021 at 2:02 AM Michael Gmelin wrote: > > > > > On 9. Jun 2021, at 01:15, Ian Lepore wrote: > > > > > > On Tue, 2021-06-08 at 15:11 -0700, Rodney W. Grimes wrote: > > >>> On Tue, 8 Jun 2021 09:41:34 + > > >>> Mar

Re: What happen to mailing list archives?

On Sun, Jun 06, 2021 at 01:04:46AM +0200, Michael Gmelin wrote: > > p.s. If you go to https://lists.freebsd.org/mailman/listinfo, click > FreeBSD-net and then "Archives from mailman’s time", you get to a list that > brings you to https://lists.freebsd.org/pipermail/freebsd-net/. So the old > ar

Re: What happen to mailing list archives?

On Sun, Jun 06, 2021 at 01:00:40AM +0200, Michael Gmelin wrote: > > > > On 6. Jun 2021, at 00:53, Steve Kargl > > wrote: > > > > It seems someone has tried to migrate the mailing list archives > > from mailman to some new fangle code. This has broken t

What happen to mailing list archives?

It seems someone has tried to migrate the mailing list archives from mailman to some new fangle code. This has broken the archives for at least freebsd-numerics@, freebsd-office@, freebsd-net@ As a comparison, simply go to https://lists.freebsd.org/mailman/listinfo and follow the links to freeb

  1   2   3   4   5   6   7   8   9   10   >