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, Dav

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 document

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&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: 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&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: > >> On Sun,

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 > mailto:ian.freisl...@capeaugusta.com>> > wrote: > > On 02/18/18 18:17, Warner Losh wrote: >> On Sun, Feb 18, 2018 at 4:12 PM, Ian FREISLICH >> > > wrote: >>

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

-- 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 > mailto: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 >> >

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 > mailto: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

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, "Ian

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, Ian FREISLICH wrote: >> >> On

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 > mailto:ian.freisl...@capeaugusta.com>> > wrote: > > On 02/17/18 22:48, Warner Losh wrote: >> On Feb 17, 2018 8:24 PM, "Ian FREISLICH" >> > > wrote: >> >>

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: 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 t

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 w

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 < > >> trond.endres...@fagskolen.gjovik.no> wrote: > >> > >>> On Sun, 18 F

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 got a crash when com

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 Millard wrote: >>> Note: -r329448 was re

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 r32

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: 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 optimizatio

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 outweighs the greed of the few. --- -Orig

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 a

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: 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 > loaded. It's not clear from UPDATING

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" > >>> mailto:ian.freisl...@ca

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), up

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 so

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 hav

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: 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 2018-Feb-17, at 5:39 PM, Ma

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 insi

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 time, I suspect it is r

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 whic

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 31013

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" >>> mailto:ian.freisl...@capeaugusta.com>> >>> wrote: >>> >>> Hi >>> >>> Since devmatch some of my USB devices no l

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, just forget about

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 A>

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 H

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