Re: FYI: main (bad9fa56620e based): some unexpected SIGSEGV's are tied to interrupted system calls for armv7 poudriere target (cortex-a53/a57/a72 fail, cortex-a7 works(?))

2021-03-09 Thread Mark Millard via freebsd-current
On 2021-Mar-9, at 22:00, Mark Millard wrote: [Trying to be timely about reporting new information because of 13.0 not having much time left.] > On 2021-Mar-9, at 21:11, Mark Millard wrote: > >> On 2021-Mar-9, at 19:17, Mark Millard wrote: >> >> [My only testing context for this has been

Re: FYI: main (bad9fa56620e based): some unexpected SIGSEGV's are tied to interrupted system calls (cortex-a57/a72 fail, cortex-a53/cortex-a7 work)

2021-03-09 Thread Mark Millard via freebsd-current
On 2021-Mar-9, at 21:11, Mark Millard wrote: > On 2021-Mar-9, at 19:17, Mark Millard wrote: > > [My only testing context for this has been main, not 13.0. > But it might be a 13.0 worry.] > >> Using the quickest to so-far-reliably-fail type of example from >> another thread I used truss to

Re: FYI: main (bad9fa56620e based): some unexpected SIGSEGV's are tied to interrupted system calls (cortex-a57/a72 fail, cortex-a53/cortex-a7 work)

2021-03-09 Thread Mark Millard via freebsd-current
On 2021-Mar-9, at 19:17, Mark Millard wrote: [My only testing context for this has been main, not 13.0. But it might be a 13.0 worry.] > Using the quickest to so-far-reliably-fail type of example from > another thread I used truss to see what happens, here filtered > down to two processes that

FYI: main (bad9fa56620e based): some unexpected SIGSEGV's are tied to interrupted system calls while using poudriere-devel to build armv7 ports on aarch64

2021-03-09 Thread Mark Millard via freebsd-current
Using the quickest to so-far-reliably-fail type of example from another thread I used truss to see what happens, here filtered down to two processes that appear to be involved and only near the failure. (The overall truss output is huge from the prior activity in the poudriere bulk relatated

Re: FYI: main (bad9fa56620e based): some unexpected SIGSEGV's using poudriere-devel to build armv7 ports on aarch64 (cortex-a72) system

2021-03-09 Thread Mark Millard via freebsd-current
On 2021-Mar-9, at 17:18, Mark Millard wrote: > On 2021-Mar-9, at 15:39, Mark Millard wrote: > >> After using poudriere to build ports for native cortex-a72 >> on the MACCHIATObin Double Shot (and similarly for >> cortex-a57 on the OverDrive 1000) I attempted to do my >> usual bulk build

Re: FYI: main (bad9fa56620e based): some unexpected SIGSEGV's using poudriere-devel to build armv7 ports on aarch64 (cortex-a72) system

2021-03-09 Thread Mark Millard via freebsd-current
On 2021-Mar-9, at 15:39, Mark Millard wrote: > After using poudriere to build ports for native cortex-a72 > on the MACCHIATObin Double Shot (and similarly for > cortex-a57 on the OverDrive 1000) I attempted to do my > usual bulk build targeting cortex-a7 via poudriere-devel: > > # poudriere

FYI: main (bad9fa56620e based): some unexpected SIGSEGV's using poudriere-devel to build armv7 ports on aarch64 (cortex-a72) system

2021-03-09 Thread Mark Millard via freebsd-current
After using poudriere to build ports for native cortex-a72 on the MACCHIATObin Double Shot (and similarly for cortex-a57 on the OverDrive 1000) I attempted to do my usual bulk build targeting cortex-a7 via poudriere-devel: # poudriere jail -i -jFBSDFSSDjailArmV7 Jail name:

Re: "panic: malloc(M_WAITOK) with sleeping prohibited" at main-n245363-b3dac3913dc9

2021-03-09 Thread David Wolfskill
On Tue, Mar 09, 2021 at 04:04:56PM -0700, Warner Losh wrote: > ... > > The build nmachine (still?) panics: > > ... > I'm willing to "poke at it" a bit, given a hint or two... > > OK. I know what's happening here. disk_create() posts an event and also > expects to sleep to get memory. I can fix

Re: "panic: malloc(M_WAITOK) with sleeping prohibited" at main-n245363-b3dac3913dc9

2021-03-09 Thread Warner Losh
On Tue, Mar 9, 2021 at 2:46 PM David Wolfskill wrote: > On Tue, Mar 09, 2021 at 01:23:16PM -0800, David Wolfskill wrote: > > On Tue, Mar 09, 2021 at 01:53:37PM -0700, Warner Losh wrote: > > > ... > > > The following reviews should fix this. It introduces a no-wait variant > for > > >

Re: "panic: malloc(M_WAITOK) with sleeping prohibited" at main-n245363-b3dac3913dc9

2021-03-09 Thread David Wolfskill
On Tue, Mar 09, 2021 at 01:23:16PM -0800, David Wolfskill wrote: > On Tue, Mar 09, 2021 at 01:53:37PM -0700, Warner Losh wrote: > > ... > > The following reviews should fix this. It introduces a no-wait variant for > > disk_alloc(), provides a way to free allocated, but not created, disks and > >

Re: "panic: malloc(M_WAITOK) with sleeping prohibited" at main-n245363-b3dac3913dc9

2021-03-09 Thread David Wolfskill
On Tue, Mar 09, 2021 at 01:53:37PM -0700, Warner Losh wrote: > ... > The following reviews should fix this. It introduces a no-wait variant for > disk_alloc(), provides a way to free allocated, but not created, disks and > changes CAM to use the new routines and take some care for not leaking

Re: "panic: malloc(M_WAITOK) with sleeping prohibited" at main-n245363-b3dac3913dc9

2021-03-09 Thread Warner Losh
On Tue, Mar 9, 2021 at 5:09 AM David Wolfskill wrote: > Just did a source-based update from: > > FreeBSD 14.0-CURRENT #1205 main-n245338-221622ec0c8e: Mon Mar 8 03:49:58 > PST 2021 > r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC > amd64 145 145 > >

Re: RC1 builds

2021-03-09 Thread Ronald Klop
See https://lists.freebsd.org/pipermail/freebsd-stable/2021-March/093272.html Regards, Ronald. Van: Mitidzi Racerex Datum: maandag, 8 maart 2021 11:33 Aan: freebsd-current@freebsd.org Onderwerp: RC1 builds Please give a link to RC1 builds. ___

Re: "panic: malloc(M_WAITOK) with sleeping prohibited" at main-n245363-b3dac3913dc9

2021-03-09 Thread David Wolfskill
On Tue, Mar 09, 2021 at 04:09:18AM -0800, David Wolfskill wrote: > ... > I can afford to leave it that way for a bit, in case anyone has > suggestions for poking at it to get more information. I expect to > be attempting the same upgrade on a couple of laptops -- after they > finish building

"panic: malloc(M_WAITOK) with sleeping prohibited" at main-n245363-b3dac3913dc9

2021-03-09 Thread David Wolfskill
Just did a source-based update from: FreeBSD 14.0-CURRENT #1205 main-n245338-221622ec0c8e: Mon Mar 8 03:49:58 PST 2021 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 145 145 to: FreeBSD 14.0-CURRENT #1206 main-n245363-b3dac3913dc9: Tue Mar

Re: panic in drm or vt or deadlock on mutex or ...

2021-03-09 Thread Alastair Hogge
On 2021-02-09 02:20, Emmanuel Vadot wrote: > Alastair: Can you report a bug there : > https://github.com/freebsd/drm-kmod/issues https://github.com/freebsd/drm-kmod/issues/64 ___ freebsd-current@freebsd.org mailing list

Re: panic in drm or vt or deadlock on mutex or ...

2021-03-09 Thread Hans Petter Selasky
On 3/9/21 9:31 AM, Alastair Hogge wrote: On 2021-02-08 21:01, Hans Petter Selasky wrote: On 2/8/21 1:53 PM, Alastair Hogge wrote: Boot to multi-user; login (getty): $ doas kldload /boot/modules/amdgpu.ko $ sysctl [panic] ..is a guaranteed way to panic my system. Hi, Maybe you could do a

Re: panic in drm or vt or deadlock on mutex or ...

2021-03-09 Thread Alastair Hogge
On 2021-02-08 21:01, Hans Petter Selasky wrote: > On 2/8/21 1:53 PM, Alastair Hogge wrote: >> Boot to multi-user; login (getty): >> $ doas kldload /boot/modules/amdgpu.ko >> $ sysctl >> [panic] >> >> ..is a guaranteed way to panic my system. > > Hi, > > Maybe you could do a hack and edit the