James Cook writes:
> On Mon, Apr 22, 2024 at 11:21:36AM GMT, Greg Steuck wrote:
>> James, if you'd like to play with this on -current, please remove both
>> patch-libraries_text_simdutf_simdutf_h and
>> patch-libraries_text_cbits_measure_off_c
>>
>> This should make the offending check disappea
On Mon, Apr 22, 2024 at 11:21:36AM GMT, Greg Steuck wrote:
> Stuart Henderson writes:
>
> > On 2024/04/22 10:30, Greg Steuck wrote:
> >> > If it would help, I could update my old AMD machine to -current
> >> > and check ghc works with the two patches removed, once I've finished
> >> > trying out
Stuart Henderson writes:
> On 2024/04/22 10:30, Greg Steuck wrote:
>> > If it would help, I could update my old AMD machine to -current
>> > and check ghc works with the two patches removed, once I've finished
>> > trying out the patch I just sent for 7.5.
>>
>> Thanks James for working through
On 2024/04/22 10:30, Greg Steuck wrote:
> > If it would help, I could update my old AMD machine to -current
> > and check ghc works with the two patches removed, once I've finished
> > trying out the patch I just sent for 7.5.
>
> Thanks James for working through this. Yes, we need the new develop
James Cook writes:
> The line you linked to comes after a check for cpuid_bit::osxsave,
> so I don't think it would get reached on machines that don't have
> xgetbv, i.e. it should be fine.
Cool, so maybe we need a patch which does this? I also just noticed
that you patched libraries/text/cbits/
On Sun, Apr 21, 2024 at 09:03:30PM +, James Cook wrote:
> On Sun, Apr 21, 2024 at 11:49:46AM -0700, Greg Steuck wrote:
> > Stuart Henderson writes:
> >
> > > This is in the avx512 checks in the text library again, I think it must
> > > be patch-libraries_text_cbits_measure_off_c (the simdutf
On Sun, Apr 21, 2024 at 11:49:46AM -0700, Greg Steuck wrote:
> Stuart Henderson writes:
>
> > This is in the avx512 checks in the text library again, I think it must
> > be patch-libraries_text_cbits_measure_off_c (the simdutf one doesn't
> > explicitly check for xgetbv but it does check for osxs
On Sun, Apr 21, 2024 at 11:49:46AM -0700, Greg Steuck wrote:
> Stuart Henderson writes:
>
> > This is in the avx512 checks in the text library again, I think it must
> > be patch-libraries_text_cbits_measure_off_c (the simdutf one doesn't
> > explicitly check for xgetbv but it does check for osxs
Stuart Henderson writes:
> This is in the avx512 checks in the text library again, I think it must
> be patch-libraries_text_cbits_measure_off_c (the simdutf one doesn't
> explicitly check for xgetbv but it does check for osxsave so I think
> wouldn't have executed the xgetbv opcode on this cpu).
On 2024/04/19 17:58, Greg Steuck wrote:
> James Cook writes:
>
> > Here are some results of debugging with lldb.
> >
> >
> > With cabal-bundler and pandoc, it seems to be the xgetbv instruction
> > itself:
> >
> >
> > $ lldb /usr/local/bin/cabal-bundler
> > (lldb) target create "/usr/local/bin/ca
James Cook writes:
> Here are some results of debugging with lldb.
>
>
> With cabal-bundler and pandoc, it seems to be the xgetbv instruction
> itself:
>
>
> $ lldb /usr/local/bin/cabal-bundler
> (lldb) target create "/usr/local/bin/cabal-bundler"
> Current executable set to '/usr/local/bin/cabal
On Fri, Apr 19, 2024 at 12:04:54AM +, James Cook wrote:
> On Sun, Feb 18, 2024 at 08:35:26AM -0800, Evan Silberman wrote:
> > Stuart Henderson wrote:
> > > On 2024/02/18 09:02, Stuart Henderson wrote:
> > > > On 2024/02/17 22:08, Greg Steuck wrote:
> > > > > Oh wow, this is becoming eerily sim
On Sun, Feb 18, 2024 at 08:35:26AM -0800, Evan Silberman wrote:
> Stuart Henderson wrote:
> > On 2024/02/18 09:02, Stuart Henderson wrote:
> > > On 2024/02/17 22:08, Greg Steuck wrote:
> > > > Oh wow, this is becoming eerily similar to the failures aja@ is
> > > > getting. Do
> > > > dig more int
oops, thanks - fix committed.
On 2024/02/23 11:35, Evan Silberman wrote:
> Stuart Henderson wrote:
> > Index: patches/patch-libraries_text_cbits_measure_off_c
> > ===
> > RCS file: patches/patch-libraries_text_cbits_measure_off_c
> >
Stuart Henderson wrote:
> Index: patches/patch-libraries_text_cbits_measure_off_c
> ===
> RCS file: patches/patch-libraries_text_cbits_measure_off_c
> diff -N patches/patch-libraries_text_cbits_measure_off_c
> --- /dev/null 1 Jan 1970
> Evan, if you have abundant time, could you try to run `make test` with
> and without the patches? `make clean` in the middle is probably the
> easiest way to ensure the patches get applied as expected.
Did `make test` in lang/ghc with and without the patches and got the
same three failed tests i
Stuart Henderson writes:
> On 2024/02/18 16:56, Evan Silberman wrote:
>> Something like this? I'm out of my depth and heavily pattern-matching
>> against the fix to simdutf and other references. Genuinely no idea if
>> I'm using inline asm correctly, etc. Works on my machine, however.
>
> That se
Stuart Henderson wrote:
> On 2024/02/18 16:56, Evan Silberman wrote:
> > Something like this? I'm out of my depth and heavily pattern-matching
> > against the fix to simdutf and other references. Genuinely no idea if
> > I'm using inline asm correctly, etc. Works on my machine, however.
>
> That
On 2024/02/18 16:56, Evan Silberman wrote:
> Something like this? I'm out of my depth and heavily pattern-matching
> against the fix to simdutf and other references. Genuinely no idea if
> I'm using inline asm correctly, etc. Works on my machine, however.
That seems right to me. I don't have an AV
Stuart Henderson wrote:
> On 2024/02/18 13:58, Evan Silberman wrote:
> > Stuart Henderson wrote:
> > > This is probably worth a try. I've asked if upstream can update it
> >
> > Hi Stuart,
> >
> > Unclear if necessary, but not sufficient. Turns out there's one more
> > unconditional AVX512 chec
On 2024/02/18 13:58, Evan Silberman wrote:
> Stuart Henderson wrote:
> > This is probably worth a try. I've asked if upstream can update it
>
> Hi Stuart,
>
> Unclear if necessary, but not sufficient. Turns out there's one more
> unconditional AVX512 check in text's own C code, cbits/measure_off
Stuart Henderson wrote:
> This is probably worth a try. I've asked if upstream can update it
Hi Stuart,
Unclear if necessary, but not sufficient. Turns out there's one more
unconditional AVX512 check in text's own C code, cbits/measure_off.c:
#if !((defined(__apple_build_version__) && __apple_b
This is probably worth a try. I've asked if upstream can update it:
https://github.com/haskell/text/issues/563
Index: Makefile
===
RCS file: /cvs/ports/lang/ghc/Makefile,v
retrieving revision 1.220
diff -u -p -r1.220 Makefile
--- Make
Stuart Henderson wrote:
> On 2024/02/18 09:02, Stuart Henderson wrote:
> > On 2024/02/17 22:08, Greg Steuck wrote:
> > > Oh wow, this is becoming eerily similar to the failures aja@ is getting.
> > > Do
> > > dig more into this!
> >
> > Antoine, can you send a dmesg from one of the exopi VMs, pl
On Sun, Feb 18, 2024 at 09:02:16AM +, Stuart Henderson wrote:
> On 2024/02/17 22:08, Greg Steuck wrote:
> > Oh wow, this is becoming eerily similar to the failures aja@ is getting. Do
> > dig more into this!
>
> Antoine, can you send a dmesg from one of the exopi VMs, please?
Sure.
OpenBSD 7
On 2024/02/18 09:02, Stuart Henderson wrote:
> On 2024/02/17 22:08, Greg Steuck wrote:
> > Oh wow, this is becoming eerily similar to the failures aja@ is getting. Do
> > dig more into this!
>
> Antoine, can you send a dmesg from one of the exopi VMs, please?
- specifically I am wondering if it c
On 2024/02/17 22:08, Greg Steuck wrote:
> Oh wow, this is becoming eerily similar to the failures aja@ is getting. Do
> dig more into this!
Antoine, can you send a dmesg from one of the exopi VMs, please?
> On Sat, Feb 17, 2024, 21:34 Evan Silberman wrote:
>
> > Evan Silberman wrote:
> > > Th
Greg Steuck wrote:
> Oh wow, this is becoming eerily similar to the failures aja@ is getting. Do
> dig more into this!
I did, and now it's bedtime. Attached tarball contains a reasonably
minimized reproduction of the crash on my machine with a short readme.
It builds with GHC 9.2.7 and fails with
Oh wow, this is becoming eerily similar to the failures aja@ is getting. Do
dig more into this!
On Sat, Feb 17, 2024, 21:34 Evan Silberman wrote:
> Evan Silberman wrote:
> > Thanks to the amd64 snapshot package archives I was able to bisect to a
> > working pandoc package on my machine. OK on 2
Evan Silberman wrote:
> Thanks to the amd64 snapshot package archives I was able to bisect to a
> working pandoc package on my machine. OK on 2024-01-16, NG on
> 2024-01-17.
I guess what this means is my problem is traceable to the ghc 9.6.4
bump. I have determined I can elicit a SIGILL reproduci
Stuart Henderson wrote:
> On 2024/02/16 13:41, Evan Silberman wrote:
> > Greg back to your question about when this worked, I wish I could tell
> > you something meaningful. I think I had a pre-7.4 snap on this laptop
> > vintage September, whenever I last updated the Pandoc port, and then I
> > d
On 2024/02/16 20:45, Stuart Henderson wrote:
> It runs ok on ryzen. 11th gen intel + SIGILL - looks like an IBT issue.
I've tried cargo-bundler and pandoc on my IBT machine now, they seem to
run OK there too.
On 2024/02/16 13:41, Evan Silberman wrote:
> Greg back to your question about when this
Greg Steuck wrote:
> Same here. That's intentional as the underlying problem got fixed
> upstream a while ago. We removed WXNEEDED then:
>
> Date: Fri Jun 3 02:48:07 2022 +
>
> Remove USE_WXNEEDED from lang/ghc as it's no longer needed
>
> Thanks
> Greg
OK. I'm out of my depth a bit at
Evan Silberman writes:
> Can you repeat for OPENBSD_WXNEED? On my syspatched 7.4-release VPS, pandoc
> from packages has wxneeded:
>
> ~$ uname -rsv
> OpenBSD 7.4 GENERIC#1336
> ~$ readelf -Wl $(which pandoc) | grep OPENBSD_WXNEED
> OPENBSD_WXNEED 0x00 0x 0x
Greg Steuck wrote:
> Evan Silberman writes:
>
> > I should've figured out how to use readelf before I bothered with this,
> > the NOBTCFI elf segment is already present in the ports in question.
> > Above diff is irrelevant. It does seem significant that the ports that
> > work fine (ghc and cab
Evan Silberman writes:
> I should've figured out how to use readelf before I bothered with this,
> the NOBTCFI elf segment is already present in the ports in question.
> Above diff is irrelevant. It does seem significant that the ports that
> work fine (ghc and cabal-install) are, naturally, the
Evan Silberman wrote:
> I'm trying with this:
>
> diff /usr/ports
> commit - 5fdc9dbcebbd57477b047430dfc2cc4e987537ef
> path + /usr/ports
> blob - a51e834910b7ee582f3be8d92a4e137a0cb46ad1
> file + devel/cabal/cabal.port.mk
> --- devel/cabal/cabal.port.mk
> +++ devel/cabal/cabal.port.mk
> @@ -85,7
Greg Steuck wrote:
> Stuart Henderson writes:
>
> > It runs ok on ryzen. 11th gen intel + SIGILL - looks like an IBT
> > issue.
>
> Isn't -Wl,-z,nobtcfi supposed to have disabled this?
>
> https://codeberg.org/OpenBSD/ports/src/branch/master/lang/ghc/Makefile#L123
>
> Thanks
> Greg
I'm tryin
Stuart Henderson writes:
> It runs ok on ryzen. 11th gen intel + SIGILL - looks like an IBT
> issue.
Isn't -Wl,-z,nobtcfi supposed to have disabled this?
https://codeberg.org/OpenBSD/ports/src/branch/master/lang/ghc/Makefile#L123
Thanks
Greg
Evan Silberman writes:
> Hi ports@ and Greg,
>
> On -current (yesterday's amd64 snap, this morning's amd64 packages),
> ports built with ghc are all getting SIGILL early in execution on my
> laptop.
Interesting, when was the last time it worked for you?
> I'm not totally positive what is helpfu
It runs ok on ryzen. 11th gen intel + SIGILL - looks like an IBT issue.
On 2024/02/16 11:48, Evan Silberman wrote:
> Hi ports@ and Greg,
>
> On -current (yesterday's amd64 snap, this morning's amd64 packages),
> ports built with ghc are all getting SIGILL early in execution on my
> laptop. I'm no
41 matches
Mail list logo
