Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

On 2018-Feb-18, at 10:08 AM, Mateusz Guzik wrote: > Can you please bisect this? There is another report stating that r329418 > works fine. I saw that Trond indicated an intent to test -r329418 but I've not seen any reports about -r329418 or how much activity was used to make any judgment about

Re: 12.0-CURRENT missing timezones

On 10/2/18 2:48 am, Warner Losh wrote: OK. That makes sense again. I've pushed two changes (r329064 and r329075) which should correct this. thanks.. I was just about to go investigate this as I noticed my build last week had no timezone info. Warner On Fri, Feb 9, 2018 at 10:28 AM,

Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

On Sun, 18 Feb 2018 22:33+0100, Mateusz Guzik wrote: > On Sun, Feb 18, 2018 at 9:38 PM, Trond Endrestøl < > trond.endres...@fagskolen.gjovik.no> wrote: > > > On Sun, 18 Feb 2018 11:51-0800, Mark Millard wrote: > > > > > Note: -r329448 was reverted in -r329461 : racy. > > > > True. I got a crash

Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

On Sun, Feb 18, 2018 at 10:50 PM, Mark Millard wrote: > > > On 2018-Feb-18, at 1:46 PM, Mark Millard wrote: > > > On 2018-Feb-18, at 1:33 PM, Mateusz Guzik wrote: > > > >> On Sun, Feb 18, 2018 at 9:38 PM, Trond Endrestøl <

Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

On 2018-Feb-18, at 4:55 PM, Mateusz Guzik wrote: > I committed the fix in > https://svnweb.freebsd.org/base?view=revision=329542 > > i.e. should be stable from this point on. Thanks! === Mark Millard marklmi at yahoo.com ( markmi at dsl-only.net is going away in 2018-Feb, late)

RE: How to find CPU microcode version ?

Yes. Intel and AMD docs describe this. CPU reset clears any microcode update. --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many

Re: r329501 devd doesn't find USB devices

-- Ian Freislich (M) +1 404 574 0228 On 02/18/18 18:17, Warner Losh wrote: > > > On Sun, Feb 18, 2018 at 4:12 PM, Ian FREISLICH > > > wrote: > > On 02/18/18 15:09, Warner Losh wrote: >> On Sat, Feb 17, 2018 at 9:14 PM,

Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

On 2018-Feb-18, at 11:30 AM, Trond Endrestøl wrote: > On Sun, 18 Feb 2018 19:08+0100, Mateusz Guzik wrote: > >> Can you please bisect this? There is another report stating that r329418 >> works fine. > > My problems started yesterday with r329464. I decided to go back to > r329101 (ZFS BE),

Re: r329501 devd doesn't find USB devices

On Sat, Feb 17, 2018 at 9:14 PM, Ian FREISLICH < ian.freisl...@capeaugusta.com> wrote: > On 02/17/18 22:48, Warner Losh wrote: > > On Feb 17, 2018 8:24 PM, "Ian FREISLICH" > wrote: > > Hi > > Since devmatch some of my USB devices no longer get their drivers >

Re: Since last week (today) current on my Ryzen box is unstable

On 18/02/2018 22:33, Gleb Smirnoff wrote: > On Sun, Feb 18, 2018 at 10:15:24PM +0200, Andriy Gapon wrote: > A> On 18/02/2018 15:26, Gleb Smirnoff wrote: > A> > My only point is that it is a performance improvement. IMHO that's > enough :) > A> > A> I don't think that passing an invalid argument

Re: r329501 devd doesn't find USB devices

On 02/18/18 14:59, Warner Losh wrote: > On Sun, Feb 18, 2018 at 6:32 AM, Ian FREISLICH > > > wrote: > > On 02/18/18 02:23, Hans Petter Selasky wrote: > > On 02/18/18 05:14, Ian FREISLICH wrote: > >> On 02/17/18 22:48,

Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

On Sun, 18 Feb 2018 11:51-0800, Mark Millard wrote: > Note: -r329448 was reverted in -r329461 : racy. True. I got a crash when compiling r329451 while running r329449. I've now booted the r329422 ZFS BE and I'm attempting to build r329529. -- Trond.

Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

On Sun, 18 Feb 2018 19:08+0100, Mateusz Guzik wrote: > Can you please bisect this? There is another report stating that r329418 > works fine. My problems started yesterday with r329464. I decided to go back to r329101 (ZFS BE), update the source tree, move forward to the latest revision, and

Re: Since last week (today) current on my Ryzen box is unstable

On Sun, Feb 18, 2018 at 10:15:24PM +0200, Andriy Gapon wrote: A> On 18/02/2018 15:26, Gleb Smirnoff wrote: A> > My only point is that it is a performance improvement. IMHO that's enough :) A> A> I don't think that passing an invalid argument to a documented KPI is "enough" A> for any

Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

On Sun, Feb 18, 2018 at 11:24 PM, Trond Endrestøl < trond.endres...@fagskolen.gjovik.no> wrote: > On Sun, 18 Feb 2018 22:33+0100, Mateusz Guzik wrote: > > > On Sun, Feb 18, 2018 at 9:38 PM, Trond Endrestøl < > > trond.endres...@fagskolen.gjovik.no> wrote: > > > > > On Sun, 18 Feb 2018 11:51-0800,

Re: r329501 devd doesn't find USB devices

On Sun, Feb 18, 2018 at 4:12 PM, Ian FREISLICH < ian.freisl...@capeaugusta.com> wrote: > On 02/18/18 15:09, Warner Losh wrote: > > On Sat, Feb 17, 2018 at 9:14 PM, Ian FREISLICH < > ian.freisl...@capeaugusta.com> wrote: > >> On 02/17/18 22:48, Warner Losh wrote: >> >> On Feb 17, 2018 8:24 PM,

Re: r329501 devd doesn't find USB devices

On 02/18/18 18:01, Ian FREISLICH wrote: > On 02/18/18 14:59, Warner Losh wrote: >> On Sun, Feb 18, 2018 at 6:32 AM, Ian FREISLICH >> > > wrote: >> >> On 02/18/18 02:23, Hans Petter Selasky wrote: >> > On 02/18/18 05:14,

Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

On 2018-Feb-18, at 1:46 PM, Mark Millard wrote: > On 2018-Feb-18, at 1:33 PM, Mateusz Guzik wrote: > >> On Sun, Feb 18, 2018 at 9:38 PM, Trond Endrestøl < >> trond.endres...@fagskolen.gjovik.no> wrote: >> >>> On Sun, 18 Feb 2018 11:51-0800, Mark

Re: r329501 devd doesn't find USB devices

On Sun, Feb 18, 2018 at 4:45 PM, Ian FREISLICH < ian.freisl...@capeaugusta.com> wrote: > > -- > Ian Freislich > (M) +1 404 574 0228 <(404)%20574-0228> > > On 02/18/18 18:17, Warner Losh wrote: > > > > On Sun, Feb 18, 2018 at 4:12 PM, Ian FREISLICH < > ian.freisl...@capeaugusta.com> wrote: > >> On

Re: r329501 devd doesn't find USB devices

On Sun, Feb 18, 2018 at 6:32 AM, Ian FREISLICH < ian.freisl...@capeaugusta.com> wrote: > On 02/18/18 02:23, Hans Petter Selasky wrote: > > On 02/18/18 05:14, Ian FREISLICH wrote: > >> On 02/17/18 22:48, Warner Losh wrote: > >>> On Feb 17, 2018 8:24 PM, "Ian FREISLICH" > >>>

Re: r329501 devd doesn't find USB devices

On 02/18/18 15:09, Warner Losh wrote: > On Sat, Feb 17, 2018 at 9:14 PM, Ian FREISLICH > > > wrote: > > On 02/17/18 22:48, Warner Losh wrote: >> On Feb 17, 2018 8:24 PM, "Ian FREISLICH" >>

Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

I committed the fix in https://svnweb.freebsd.org/base?view=revision=329542 i.e. should be stable from this point on. On Sun, Feb 18, 2018 at 11:55 PM, Mateusz Guzik wrote: > On Sun, Feb 18, 2018 at 11:24 PM, Trond Endrestøl < > trond.endres...@fagskolen.gjovik.no> wrote: >

Re: How to find CPU microcode version ?

Hi! > On 02/18/18 11:41, Kurt Jaeger wrote: > > > Reboot of the box and waiting a few hours and the problem re-occured. > > Doesn't the work of microcode_update vanish after a reboot? Thanks. I was not sure and tested this. Indeed, yes, the microcode update is reverted by rebooting. Then I

Re: Since last week (today) current on my Ryzen box is unstable

On 18/02/2018 15:26, Gleb Smirnoff wrote: > My only point is that it is a performance improvement. IMHO that's enough :) I don't think that passing an invalid argument to a documented KPI is "enough" for any optimization. > If you can't suggest a more elegant way of doing that improvement, then

Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

On Sun, Feb 18, 2018 at 9:38 PM, Trond Endrestøl < trond.endres...@fagskolen.gjovik.no> wrote: > On Sun, 18 Feb 2018 11:51-0800, Mark Millard wrote: > > > Note: -r329448 was reverted in -r329461 : racy. > > True. I got a crash when compiling r329451 while running r329449. > I've now booted the

Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

On 2018-Feb-18, at 1:33 PM, Mateusz Guzik wrote: > On Sun, Feb 18, 2018 at 9:38 PM, Trond Endrestøl < > trond.endres...@fagskolen.gjovik.no> wrote: > >> On Sun, 18 Feb 2018 11:51-0800, Mark Millard wrote: >> >>> Note: -r329448 was reverted in -r329461 : racy. >> >> True. I

Re: r329501 devd doesn't find USB devices

On 02/18/18 18:49, Warner Losh wrote: > On Sun, Feb 18, 2018 at 4:45 PM, Ian FREISLICH > > > wrote: > > On 02/18/18 18:17, Warner Losh wrote: >> On Sun, Feb 18, 2018 at 4:12 PM, Ian FREISLICH >>

Re: Since last week (today) current on my Ryzen box is unstable

On 19/2/18 4:33 am, Gleb Smirnoff wrote: On Sun, Feb 18, 2018 at 10:15:24PM +0200, Andriy Gapon wrote: A> On 18/02/2018 15:26, Gleb Smirnoff wrote: A> > My only point is that it is a performance improvement. IMHO that's enough :) A> A> I don't think that passing an invalid argument to a

How to find CPU microcode version ?

Hi! How do I find the microcode version a Intel CPU is currently using ? Background: When Spectre/Meltdown hit, Intel released new microcode around 20180108. I've used the devcpu-data port at that time to update the microcode at that time, and the box in question developed strange instability

Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

Can you please bisect this? There is another report stating that r329418 works fine. On Sun, Feb 18, 2018 at 6:35 PM, Mark Millard wrote: > > On 2018-Feb-17, at 6:10 PM, Mark Millard > wrote: > > > [Some more information added, from /usr/libexec/kgdb use.] > > > > On

Re: How to find CPU microcode version ?

On 02/18/18 11:41, Kurt Jaeger wrote: Reboot of the box and waiting a few hours and the problem re-occured. Doesn't the work of microcode_update vanish after a reboot? Unless of course you set up rc.conf to repeat it at every start... bye av.

Re: How to find CPU microcode version ?

Hi! > > How do I find the microcode version a Intel CPU is currently using ? > > I was pointed to > > https://forums.freebsd.org/threads/introducing-cpupdate-a-microcode-tool-for-freebsd.64588/ > > which points to: > > https://github.com/kernschmelze/cpupdate > > Works! So: On the box

Re: Buildworld failing during llvm

On 18 Feb 2018, at 02:52, Ben Woods wrote: > > My attempts to build FreeBSD 12-current have been failing as of yesterday > with the error below. This problem persists with current at the time of > writing this email (r329497). > > Given llvm was updated to 6.0 around that

Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

On 2018-Feb-17, at 6:10 PM, Mark Millard wrote: > [Some more information added, from /usr/libexec/kgdb use.] > > On 2018-Feb-17, at 5:39 PM, Mark Millard wrote: > >> This is for FreeBSD running under Hyper-V on a Windows 10 Pro machine. >> The FreeBSD "disk" bindings are to SSDs, not the

Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

On Sat, 17 Feb 2018 17:39-0800, Mark Millard wrote: > This is for FreeBSD running under Hyper-V on a Windows 10 Pro machine. > The FreeBSD "disk" bindings are to SSDs, not the insides of NTFS files. > 29 logical processors assigned to FreeBSD (on a 32-thread Ryzen > Threadripper 1950X). No other

Re: How to find CPU microcode version ?

> Am 18.02.2018 um 11:41 schrieb Kurt Jaeger : > > Hi! > > How do I find the microcode version a Intel CPU is currently using ? > AFAIK: All Linux-vendors have retracted their microcode-updates, for the time being. If your BIOS-vendor didn’t provide you an updated BIOS,

Re: r329501 devd doesn't find USB devices

On 02/18/18 02:23, Hans Petter Selasky wrote: > On 02/18/18 05:14, Ian FREISLICH wrote: >> On 02/17/18 22:48, Warner Losh wrote: >>> On Feb 17, 2018 8:24 PM, "Ian FREISLICH" >>> > >>> wrote: >>> >>> Hi >>> >>> Since

Re: Since last week (today) current on my Ryzen box is unstable

On Sun, Feb 18, 2018 at 09:28:30AM +0200, Andriy Gapon wrote: A> > A> vnode_pager_getpages_async() at vnode_pager_getpages_async+0x81/frame A> > A> 0xfe00b3c36650 A> > A> vn_sendfile() at vn_sendfile+0xe70/frame 0xfe00b3c368e0 A> > A> sendfile() at sendfile+0x149/frame 0xfe00b3c36980

Re: How to find CPU microcode version ?

Hi! > How do I find the microcode version a Intel CPU is currently using ? I was pointed to https://forums.freebsd.org/threads/introducing-cpupdate-a-microcode-tool-for-freebsd.64588/ which points to: https://github.com/kernschmelze/cpupdate Works! -- p...@opsec.eu+49 171