Re: 12.0-CURRENT missing timezones

[Julian Elischer]

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, David Boyd  wrote:


On Fri, 2018-02-09 at 10:16 -0700, Warner Losh wrote:



On Fri, Feb 9, 2018 at 10:13 AM, Warner Losh  wrote:



On Fri, Feb 9, 2018 at 9:56 AM, David Boyd  wrote:

In the most recent images for 12.0-CURRENT

 FreeBSD-12.0-CURRENT-amd64-20180208-r329009.vmdk.xz

 FreeBSD-12.0-CURRENT-amd64-20180208-r329009-disc1.iso

 FreeBSD-12.0-CURRENT-amd64-20180131-r328637-memstick.img

the /usr/share/zoneinfo directory is sparsely populated with
directories. The only file present is "zone.tab".


I think that may be my fault for changing find -s to find | sort, but I
think I neglected to add sort to ITOOLS to fix it. Building a test now.


I am surprised the 0131 is empty, though My change was after that.

Warner


Oops. My mistake (cut and paste error). All dates should be 20180208.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Julian Elischer]

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 documented KPI is 
"enough"
A> for any optimization.

I don't see a sense in making this KPI so sacred. This is something used 
internally
in kernel, and not used outside. The KPI has changed several times in the past.

A> > If you can't suggest a more elegant way of doing that improvement, then all
A> > I can suggest is to document it and add its support to ZFS.
A>
A> In return I can only suggest that (1) you run your suggestion by arch@ -- 
unless
A> that's already been done and you can point me to the discussion,  (2) 
document
A> it and (3) double-check that all implementations confirm to it.

I can provide a patch for ZFS.



If any module outside of the code that implements it needs to know 
about it,

then it is in the KPI and should be documented in the KPI documentation
(e.g. man 9)


Since the Filesystems need to know about this, it must be an externally
visible feature and therefore needs to be documented.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Mark Millard]

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)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Mateusz Guzik]

 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:
>
>> 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 when compiling r329451 while running r329449.
>> > > I've now booted the r329422 ZFS BE and I'm attempting to build
>> > > r329529.
>> > >
>> >
>> > Looking around strongly suggests r329448 is the culprit. If you can
>> verify
>> > 329447 works fine we are mostly done here.
>>
>> I noticed no errors in r329447. When r329529 is built and installed,
>> I'll try to incrementally build and install r329531.
>>
>
> Can you grab a panicking kernel and apply this:
> https://people.freebsd.org/~mjg/wait_unlocked.diff
>
> there may be debug printfs signifying the problem condition was hit,
> however the patch should fix the panic
>
> --
> Mateusz Guzik 
>



-- 
Mateusz Guzik 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r329501 devd doesn't find USB devices

[Ian FREISLICH]

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
>> > > wrote:
>>
>> 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"
 > wrote:

 Hi

 Since devmatch some of my USB devices no longer get
 their drivers
 loaded.  It's not clear from UPDATING whether I
 needed to do anything
 beyond building and installing kernel and world as
 well as updating
 /etc.  There was reference to removing
 /etc/devd/usb.conf in another
 thread but its presence or lack thereof makes no
 difference.


 I assume you've fully updated including /etc.
>>>
>>> In as much as 'mergemaster -Ui' fully updates /etc
>>>
 If you can uncomment the devd lines in syslog.conf,
 touch /var/log/devd.log and reboot. Once you are up
 again, please send me /var/log/devd.conf.
>>>
>>> Assuming you mean these lines:
>>>
>>> !devd
>>> *.>=notice 
>>> /var/log/devd.log
>>>
>>> devd produced zero logs on reboot and restart.
>>>
>>>
>>> There should be a lot of output... one line per device
>>> that's attached...  Did you create /var/log/devd.log before
>>> reboot? Is your /dev/log persistent across boots?
>>
>> Lots of output after I changed the priority from 'notice' to
>> 'debug' in syslogd.conf.  Might want to fix that in
>> src/etc/syslogd.conf.
>>
>> 1. Startup:
>>
>> Feb 18 17:43:44 zen devd: Pushing table
>> Feb 18 17:43:44 zen devd: Parsing /etc/devd.conf
>> Feb 18 17:43:44 zen devd: Parsing files in /etc/devd
>> Feb 18 17:43:44 zen devd: Parsing /etc/devd/devmatch.conf
>> Feb 18 17:43:44 zen devd: Parsing /etc/devd/asus.conf
>> Feb 18 17:43:44 zen devd: Parsing /etc/devd/hyperv.conf
>> Feb 18 17:43:44 zen devd: Parsing /etc/devd/uath.conf
>> Feb 18 17:43:44 zen devd: Parsing /etc/devd/ulpt.conf
>> Feb 18 17:43:44 zen devd: Parsing /etc/devd/usb.conf
>> Feb 18 17:43:44 zen devd: Parsing /etc/devd/zfs.conf
>> Feb 18 17:43:44 zen devd: Parsing files in /usr/local/etc/devd
>> Feb 18 17:43:44 zen devd: Parsing /usr/local/etc/devd/cups.conf
>> Feb 18 17:43:44 zen devd: Parsing
>> /usr/local/etc/devd/webcamd.co nf
>> Feb 18 17:43:44 zen devd: Calling daemon
>>
>>
>> 2. Inserting the USB-C NIC:
>>
>> Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS
>> subsystem=CDEV type=CREATE cdev=usb/0.6.0'
>> Feb 18 18:05:53 zen devd: Pushing table
>> Feb 18 18:05:53 zen devd: Processing notify event
>> Feb 18 18:05:53 zen devd: Popping table
>> Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS
>> subsystem=CDEV type=CREATE cdev=ugen0.6'
>> Feb 18 18:05:53 zen devd: Pushing table
>> Feb 18 18:05:53 zen devd: Processing notify event
>> Feb 18 18:05:53 zen devd: Popping table
>> Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS
>> subsystem=CDEV type=CREATE cdev=usb/0.6.1'
>> Feb 18 18:05:53 zen devd: Pushing table
>> Feb 18 18:05:53 zen devd: Processing notify event
>> Feb 18 18:05:53 zen devd: Popping table
>> Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS
>> subsystem=CDEV type=CREATE cdev=usb/0.6.2'
>> Feb 18 18:05:53 zen devd: Pushing table
>> Feb 18 18:05:53 zen devd: Processing notify event
>> Feb 18 18:05:53 zen devd: Popping table
>> Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS
>> subsystem=CDEV type=CREATE cdev=usb/0.6.3'
>> Feb 18 18:05:53 zen devd: Pushing table
>> Feb 18 18:05:53 zen devd: Processing notify event
>> Feb 18 18:05:53 zen devd: Popping table
>> Feb 18 18:05:53 zen devd: Processing event '!system=USB
>> subsystem=DEVICE type=ATTACH ugen=ugen0.6 cdev=ugen0.6
>> vendor=0x0bda product=0x8153 devclass=0x00 

Re: r329501 devd doesn't find USB devices

[Warner Losh]

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 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 FREISLICH" 
>>> wrote:
>>>
>>> Hi
>>>
>>> Since devmatch some of my USB devices no longer get their drivers
>>> loaded.  It's not clear from UPDATING whether I needed to do anything
>>> beyond building and installing kernel and world as well as updating
>>> /etc.  There was reference to removing /etc/devd/usb.conf in another
>>> thread but its presence or lack thereof makes no difference.
>>>
>>>
>>> I assume you've fully updated including /etc.
>>>
>>>
>>> In as much as 'mergemaster -Ui' fully updates /etc
>>>
>>> If you can uncomment the devd lines in syslog.conf, touch
>>> /var/log/devd.log and reboot. Once you are up again, please send me
>>> /var/log/devd.conf.
>>>
>>>
>>> Assuming you mean these lines:
>>>
>>> !devd
>>> *.>=notice  /var/log/devd.log
>>>
>>> devd produced zero logs on reboot and restart.
>>>
>>
>> There should be a lot of output... one line per device that's
>> attached...  Did you create /var/log/devd.log before reboot? Is your
>> /dev/log persistent across boots?
>>
>>
>> Lots of output after I changed the priority from 'notice' to 'debug' in
>> syslogd.conf.  Might want to fix that in src/etc/syslogd.conf.
>>
>> 1. Startup:
>>
>> Feb 18 17:43:44 zen devd: Pushing table
>> Feb 18 17:43:44 zen devd: Parsing /etc/devd.conf
>> Feb 18 17:43:44 zen devd: Parsing files in /etc/devd
>> Feb 18 17:43:44 zen devd: Parsing /etc/devd/devmatch.conf
>> Feb 18 17:43:44 zen devd: Parsing /etc/devd/asus.conf
>> Feb 18 17:43:44 zen devd: Parsing /etc/devd/hyperv.conf
>> Feb 18 17:43:44 zen devd: Parsing /etc/devd/uath.conf
>> Feb 18 17:43:44 zen devd: Parsing /etc/devd/ulpt.conf
>> Feb 18 17:43:44 zen devd: Parsing /etc/devd/usb.conf
>> Feb 18 17:43:44 zen devd: Parsing /etc/devd/zfs.conf
>> Feb 18 17:43:44 zen devd: Parsing files in /usr/local/etc/devd
>> Feb 18 17:43:44 zen devd: Parsing /usr/local/etc/devd/cups.conf
>> Feb 18 17:43:44 zen devd: Parsing /usr/local/etc/devd/webcamd.conf
>> Feb 18 17:43:44 zen devd: Calling daemon
>>
>>
>> 2. Inserting the USB-C NIC:
>>
>> Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS subsystem=CDEV
>> type=CREATE cdev=usb/0.6.0'
>> Feb 18 18:05:53 zen devd: Pushing table
>> Feb 18 18:05:53 zen devd: Processing notify event
>> Feb 18 18:05:53 zen devd: Popping table
>> Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS subsystem=CDEV
>> type=CREATE cdev=ugen0.6'
>> Feb 18 18:05:53 zen devd: Pushing table
>> Feb 18 18:05:53 zen devd: Processing notify event
>> Feb 18 18:05:53 zen devd: Popping table
>> Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS subsystem=CDEV
>> type=CREATE cdev=usb/0.6.1'
>> Feb 18 18:05:53 zen devd: Pushing table
>> Feb 18 18:05:53 zen devd: Processing notify event
>> Feb 18 18:05:53 zen devd: Popping table
>> Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS subsystem=CDEV
>> type=CREATE cdev=usb/0.6.2'
>> Feb 18 18:05:53 zen devd: Pushing table
>> Feb 18 18:05:53 zen devd: Processing notify event
>> Feb 18 18:05:53 zen devd: Popping table
>> Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS subsystem=CDEV
>> type=CREATE cdev=usb/0.6.3'
>> Feb 18 18:05:53 zen devd: Pushing table
>> Feb 18 18:05:53 zen devd: Processing notify event
>> Feb 18 18:05:53 zen devd: Popping table
>> Feb 18 18:05:53 zen devd: Processing event '!system=USB subsystem=DEVICE
>> type=ATTACH ugen=ugen0.6 cdev=ugen0.6 vendor=0x0bda product=0x8153
>> devclass=0x00 devsubclass=0x00 sernum="01" release=0x3000 mode=host
>> port=13 parent=ugen0.1'
>> Feb 18 18:05:53 zen devd: Pushing table
>> Feb 18 18:05:53 zen devd: Processing notify event
>> Feb 18 18:05:53 zen devd: Popping table
>> Feb 18 18:05:53 zen devd: Processing event '!system=USB
>> subsystem=INTERFACE type=ATTACH ugen=ugen0.6 cdev=ugen0.6 vendor=0x0bda
>> product=0x8153 devclass=0x00 devsubclass=0x00 sernum="01"
>> release=0x3000 mode=host interface=0 endpoints=3 intclass=0xff
>> intsubclass=0xff intprotocol=0x00'
>> Feb 18 18:05:53 zen devd: Pushing table
>> Feb 18 18:05:53 zen devd: Processing notify event
>> Feb 18 18:05:53 zen devd: Executing '/usr/local/etc/rc.d/webcamd start
>> ugen0.6'
>> Feb 18 18:05:53 zen devd: Popping table
>> Feb 18 18:05:53 zen devd: Processing event '? at bus=0 hubaddr=1 port=13
>> devaddr=6 interface=0 ugen=ugen0.6 vendor=0x0bda product=0x8153
>> devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="01" release=0x3000
>> mode=host intclass=0xff 

Re: r329501 devd doesn't find USB devices

[Ian FREISLICH]

-- 
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, Ian FREISLICH
>> > > 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 whether I needed
>>> to do anything
>>> beyond building and installing kernel and world as well
>>> as updating
>>> /etc.  There was reference to removing
>>> /etc/devd/usb.conf in another
>>> thread but its presence or lack thereof makes no difference.
>>>
>>>
>>> I assume you've fully updated including /etc.
>>
>> In as much as 'mergemaster -Ui' fully updates /etc
>>
>>> If you can uncomment the devd lines in syslog.conf, touch
>>> /var/log/devd.log and reboot. Once you are up again, please
>>> send me /var/log/devd.conf.
>>
>> Assuming you mean these lines:
>>
>> !devd
>> *.>=notice  /var/log/devd.log
>>
>> devd produced zero logs on reboot and restart.
>>
>>
>> There should be a lot of output... one line per device that's
>> attached...  Did you create /var/log/devd.log before reboot? Is
>> your /dev/log persistent across boots?
>
> Lots of output after I changed the priority from 'notice' to
> 'debug' in syslogd.conf.  Might want to fix that in
> src/etc/syslogd.conf.
>
> 1. Startup:
>
> Feb 18 17:43:44 zen devd: Pushing table
> Feb 18 17:43:44 zen devd: Parsing /etc/devd.conf
> Feb 18 17:43:44 zen devd: Parsing files in /etc/devd
> Feb 18 17:43:44 zen devd: Parsing /etc/devd/devmatch.conf
> Feb 18 17:43:44 zen devd: Parsing /etc/devd/asus.conf
> Feb 18 17:43:44 zen devd: Parsing /etc/devd/hyperv.conf
> Feb 18 17:43:44 zen devd: Parsing /etc/devd/uath.conf
> Feb 18 17:43:44 zen devd: Parsing /etc/devd/ulpt.conf
> Feb 18 17:43:44 zen devd: Parsing /etc/devd/usb.conf
> Feb 18 17:43:44 zen devd: Parsing /etc/devd/zfs.conf
> Feb 18 17:43:44 zen devd: Parsing files in /usr/local/etc/devd
> Feb 18 17:43:44 zen devd: Parsing /usr/local/etc/devd/cups.conf
> Feb 18 17:43:44 zen devd: Parsing /usr/local/etc/devd/webcamd.conf
> Feb 18 17:43:44 zen devd: Calling daemon
>
>
> 2. Inserting the USB-C NIC:
>
> Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS
> subsystem=CDEV type=CREATE cdev=usb/0.6.0'
> Feb 18 18:05:53 zen devd: Pushing table
> Feb 18 18:05:53 zen devd: Processing notify event
> Feb 18 18:05:53 zen devd: Popping table
> Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS
> subsystem=CDEV type=CREATE cdev=ugen0.6'
> Feb 18 18:05:53 zen devd: Pushing table
> Feb 18 18:05:53 zen devd: Processing notify event
> Feb 18 18:05:53 zen devd: Popping table
> Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS
> subsystem=CDEV type=CREATE cdev=usb/0.6.1'
> Feb 18 18:05:53 zen devd: Pushing table
> Feb 18 18:05:53 zen devd: Processing notify event
> Feb 18 18:05:53 zen devd: Popping table
> Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS
> subsystem=CDEV type=CREATE cdev=usb/0.6.2'
> Feb 18 18:05:53 zen devd: Pushing table
> Feb 18 18:05:53 zen devd: Processing notify event
> Feb 18 18:05:53 zen devd: Popping table
> Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS
> subsystem=CDEV type=CREATE cdev=usb/0.6.3'
> Feb 18 18:05:53 zen devd: Pushing table
> Feb 18 18:05:53 zen devd: Processing notify event
> Feb 18 18:05:53 zen devd: Popping table
> Feb 18 18:05:53 zen devd: Processing event '!system=USB
> subsystem=DEVICE type=ATTACH ugen=ugen0.6 cdev=ugen0.6
> vendor=0x0bda product=0x8153 devclass=0x00 devsubclass=0x00
> sernum="01" release=0x3000 mode=host port=13 parent=ugen0.1'
> Feb 18 18:05:53 zen devd: Pushing table
> Feb 18 18:05:53 zen devd: Processing notify event
> Feb 18 18:05:53 zen devd: Popping table
> Feb 18 18:05:53 zen devd: Processing event '!system=USB
> subsystem=INTERFACE type=ATTACH ugen=ugen0.6 cdev=ugen0.6
> vendor=0x0bda product=0x8153 devclass=0x00 devsubclass=0x00
> sernum="01" release=0x3000 mode=host interface=0 endpoints=3
> intclass=0xff intsubclass=0xff intprotocol=0x00'
> Feb 18 18:05:53 zen devd: Pushing table
> Feb 18 18:05:53 zen devd: 

Re: r329501 devd doesn't find USB devices

[Ian FREISLICH]

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, 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 whether I needed to do
> >>> anything
> >>>  beyond building and installing kernel and world as well as
> >>> updating
> >>>  /etc.  There was reference to removing /etc/devd/usb.conf in
> >>> another
> >>>  thread but its presence or lack thereof makes no difference.
> >>>
> >>>
> >>> I assume you've fully updated including /etc.
> >>
> >> In as much as 'mergemaster -Ui' fully updates /etc
> >>
> >>> If you can uncomment the devd lines in syslog.conf, touch
> >>> /var/log/devd.log and reboot. Once you are up again, please
> send me
> >>> /var/log/devd.conf.
> >>
> >> Assuming you mean these lines:
> >>
> >> !devd
> >> *.>=notice  /var/log/devd.log
> >>
> >> devd produced zero logs on reboot and restart.
> >
> > Can you run:
> >
> > usbconfig show_ifdrv
> >
> > Maybe the wrong driver captured your device?
>
> ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER
> (5.0Gbps) pwr=SAVE (0mA)
> ugen0.1.0: uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00,
> addr 1>
> ugen0.2:  at usbus0, cfg=0 md=HOST
> spd=HIGH (480Mbps) pwr=ON (500mA)
> ugen0.3:  at usbus0, cfg=0 md=HOST
> spd=FULL (12Mbps) pwr=ON (100mA)
> ugen0.3.0: ubt0:  2.00/0.10, addr 2>
> ugen0.4:  at usbus0, cfg=0 md=HOST spd=FULL
> (12Mbps) pwr=ON (100mA)
> ugen0.5:  at usbus0, cfg=0 md=HOST
> spd=FULL (12Mbps) pwr=ON (100mA)
> ugen0.6:  at usbus0, cfg=0 md=HOST spd=SUPER
> (5.0Gbps) pwr=ON (72mA)
>
> After loading ums and ukbd:
>
> ugen0.5:  at usbus0, cfg=0 md=HOST
> spd=FULL (12Mbps) pwr=ON (100mA)
> ugen0.5.0: ukbd0:  1.10/10.01, addr 5>
> ugen0.5.1: ums0:  1.10/10.01, addr 5>
>
>
> So what happens if you build these drivers into the kernel vs loading
> them?
>
> Warner 


-- 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r329501 devd doesn't find USB devices

[Warner Losh]

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 FREISLICH" 
>> wrote:
>>
>> Hi
>>
>> Since devmatch some of my USB devices no longer get their drivers
>> loaded.  It's not clear from UPDATING whether I needed to do anything
>> beyond building and installing kernel and world as well as updating
>> /etc.  There was reference to removing /etc/devd/usb.conf in another
>> thread but its presence or lack thereof makes no difference.
>>
>>
>> I assume you've fully updated including /etc.
>>
>>
>> In as much as 'mergemaster -Ui' fully updates /etc
>>
>> If you can uncomment the devd lines in syslog.conf, touch
>> /var/log/devd.log and reboot. Once you are up again, please send me
>> /var/log/devd.conf.
>>
>>
>> Assuming you mean these lines:
>>
>> !devd
>> *.>=notice  /var/log/devd.log
>>
>> devd produced zero logs on reboot and restart.
>>
>
> There should be a lot of output... one line per device that's attached...
> Did you create /var/log/devd.log before reboot? Is your /dev/log persistent
> across boots?
>
>
> Lots of output after I changed the priority from 'notice' to 'debug' in
> syslogd.conf.  Might want to fix that in src/etc/syslogd.conf.
>
> 1. Startup:
>
> Feb 18 17:43:44 zen devd: Pushing table
> Feb 18 17:43:44 zen devd: Parsing /etc/devd.conf
> Feb 18 17:43:44 zen devd: Parsing files in /etc/devd
> Feb 18 17:43:44 zen devd: Parsing /etc/devd/devmatch.conf
> Feb 18 17:43:44 zen devd: Parsing /etc/devd/asus.conf
> Feb 18 17:43:44 zen devd: Parsing /etc/devd/hyperv.conf
> Feb 18 17:43:44 zen devd: Parsing /etc/devd/uath.conf
> Feb 18 17:43:44 zen devd: Parsing /etc/devd/ulpt.conf
> Feb 18 17:43:44 zen devd: Parsing /etc/devd/usb.conf
> Feb 18 17:43:44 zen devd: Parsing /etc/devd/zfs.conf
> Feb 18 17:43:44 zen devd: Parsing files in /usr/local/etc/devd
> Feb 18 17:43:44 zen devd: Parsing /usr/local/etc/devd/cups.conf
> Feb 18 17:43:44 zen devd: Parsing /usr/local/etc/devd/webcamd.conf
> Feb 18 17:43:44 zen devd: Calling daemon
>
>
> 2. Inserting the USB-C NIC:
>
> Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS subsystem=CDEV
> type=CREATE cdev=usb/0.6.0'
> Feb 18 18:05:53 zen devd: Pushing table
> Feb 18 18:05:53 zen devd: Processing notify event
> Feb 18 18:05:53 zen devd: Popping table
> Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS subsystem=CDEV
> type=CREATE cdev=ugen0.6'
> Feb 18 18:05:53 zen devd: Pushing table
> Feb 18 18:05:53 zen devd: Processing notify event
> Feb 18 18:05:53 zen devd: Popping table
> Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS subsystem=CDEV
> type=CREATE cdev=usb/0.6.1'
> Feb 18 18:05:53 zen devd: Pushing table
> Feb 18 18:05:53 zen devd: Processing notify event
> Feb 18 18:05:53 zen devd: Popping table
> Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS subsystem=CDEV
> type=CREATE cdev=usb/0.6.2'
> Feb 18 18:05:53 zen devd: Pushing table
> Feb 18 18:05:53 zen devd: Processing notify event
> Feb 18 18:05:53 zen devd: Popping table
> Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS subsystem=CDEV
> type=CREATE cdev=usb/0.6.3'
> Feb 18 18:05:53 zen devd: Pushing table
> Feb 18 18:05:53 zen devd: Processing notify event
> Feb 18 18:05:53 zen devd: Popping table
> Feb 18 18:05:53 zen devd: Processing event '!system=USB subsystem=DEVICE
> type=ATTACH ugen=ugen0.6 cdev=ugen0.6 vendor=0x0bda product=0x8153
> devclass=0x00 devsubclass=0x00 sernum="01" release=0x3000 mode=host
> port=13 parent=ugen0.1'
> Feb 18 18:05:53 zen devd: Pushing table
> Feb 18 18:05:53 zen devd: Processing notify event
> Feb 18 18:05:53 zen devd: Popping table
> Feb 18 18:05:53 zen devd: Processing event '!system=USB
> subsystem=INTERFACE type=ATTACH ugen=ugen0.6 cdev=ugen0.6 vendor=0x0bda
> product=0x8153 devclass=0x00 devsubclass=0x00 sernum="01"
> release=0x3000 mode=host interface=0 endpoints=3 intclass=0xff
> intsubclass=0xff intprotocol=0x00'
> Feb 18 18:05:53 zen devd: Pushing table
> Feb 18 18:05:53 zen devd: Processing notify event
> Feb 18 18:05:53 zen devd: Executing '/usr/local/etc/rc.d/webcamd start
> ugen0.6'
> Feb 18 18:05:53 zen devd: Popping table
> Feb 18 18:05:53 zen devd: Processing event '? at bus=0 hubaddr=1 port=13
> devaddr=6 interface=0 ugen=ugen0.6 vendor=0x0bda product=0x8153
> devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="01" release=0x3000
> mode=host intclass=0xff intsubclass=0xff intprotocol=0x00 on uhub0'
> Feb 18 18:05:53 zen devd: Pushing table
> Feb 18 18:05:53 zen devd: Processing nomatch event
> Feb 18 18:05:53 zen devd: Executing '/etc/rc.d/devmatch start '? at bus=0
> hubaddr=1 port=13 devaddr=6 interface=0 ugen=ugen0.6 vendor=0x0bda
> product=0x8153 devclass=0x00 devsubclass=0x00 

Re: r329501 devd doesn't find USB devices

[Ian FREISLICH]

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 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 whether I needed to do
>> >>> anything
>> >>>  beyond building and installing kernel and world as well as
>> >>> updating
>> >>>  /etc.  There was reference to removing /etc/devd/usb.conf in
>> >>> another
>> >>>  thread but its presence or lack thereof makes no difference.
>> >>>
>> >>>
>> >>> I assume you've fully updated including /etc.
>> >>
>> >> In as much as 'mergemaster -Ui' fully updates /etc
>> >>
>> >>> If you can uncomment the devd lines in syslog.conf, touch
>> >>> /var/log/devd.log and reboot. Once you are up again, please
>> send me
>> >>> /var/log/devd.conf.
>> >>
>> >> Assuming you mean these lines:
>> >>
>> >> !devd
>> >> *.>=notice  /var/log/devd.log
>> >>
>> >> devd produced zero logs on reboot and restart.
>> >
>> > Can you run:
>> >
>> > usbconfig show_ifdrv
>> >
>> > Maybe the wrong driver captured your device?
>>
>> ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER
>> (5.0Gbps) pwr=SAVE (0mA)
>> ugen0.1.0: uhub0: <0x8086 XHCI root HUB, class 9/0, rev
>> 3.00/1.00, addr 1>
>> ugen0.2:  at usbus0, cfg=0 md=HOST
>> spd=HIGH (480Mbps) pwr=ON (500mA)
>> ugen0.3:  at usbus0, cfg=0 md=HOST
>> spd=FULL (12Mbps) pwr=ON (100mA)
>> ugen0.3.0: ubt0: > 2.00/0.10, addr 2>
>> ugen0.4:  at usbus0, cfg=0 md=HOST spd=FULL
>> (12Mbps) pwr=ON (100mA)
>> ugen0.5:  at usbus0, cfg=0 md=HOST
>> spd=FULL (12Mbps) pwr=ON (100mA)
>> ugen0.6:  at usbus0, cfg=0 md=HOST spd=SUPER
>> (5.0Gbps) pwr=ON (72mA)
>>
>> After loading ums and ukbd:
>>
>> ugen0.5:  at usbus0, cfg=0 md=HOST
>> spd=FULL (12Mbps) pwr=ON (100mA)
>> ugen0.5.0: ukbd0: > 1.10/10.01, addr 5>
>> ugen0.5.1: ums0: > 1.10/10.01, addr 5>
>>
>>
>> So what happens if you build these drivers into the kernel vs loading
>> them?

It just works, which is the fix I'm using for now.

Ian

-- 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r329501 devd doesn't find USB devices

[Ian FREISLICH]

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"
>> > > wrote:
>>
>> Hi
>>
>> Since devmatch some of my USB devices no longer get their drivers
>> loaded.  It's not clear from UPDATING whether I needed to do
>> anything
>> beyond building and installing kernel and world as well as
>> updating
>> /etc.  There was reference to removing /etc/devd/usb.conf in
>> another
>> thread but its presence or lack thereof makes no difference.
>>
>>
>> I assume you've fully updated including /etc.
>
> In as much as 'mergemaster -Ui' fully updates /etc
>
>> If you can uncomment the devd lines in syslog.conf, touch
>> /var/log/devd.log and reboot. Once you are up again, please send
>> me /var/log/devd.conf.
>
> Assuming you mean these lines:
>
> !devd
> *.>=notice  /var/log/devd.log
>
> devd produced zero logs on reboot and restart.
>
>
> There should be a lot of output... one line per device that's
> attached...  Did you create /var/log/devd.log before reboot? Is your
> /dev/log persistent across boots?

Lots of output after I changed the priority from 'notice' to 'debug' in
syslogd.conf.  Might want to fix that in src/etc/syslogd.conf.

1. Startup:

Feb 18 17:43:44 zen devd: Pushing table
Feb 18 17:43:44 zen devd: Parsing /etc/devd.conf
Feb 18 17:43:44 zen devd: Parsing files in /etc/devd
Feb 18 17:43:44 zen devd: Parsing /etc/devd/devmatch.conf
Feb 18 17:43:44 zen devd: Parsing /etc/devd/asus.conf
Feb 18 17:43:44 zen devd: Parsing /etc/devd/hyperv.conf
Feb 18 17:43:44 zen devd: Parsing /etc/devd/uath.conf
Feb 18 17:43:44 zen devd: Parsing /etc/devd/ulpt.conf
Feb 18 17:43:44 zen devd: Parsing /etc/devd/usb.conf
Feb 18 17:43:44 zen devd: Parsing /etc/devd/zfs.conf
Feb 18 17:43:44 zen devd: Parsing files in /usr/local/etc/devd
Feb 18 17:43:44 zen devd: Parsing /usr/local/etc/devd/cups.conf
Feb 18 17:43:44 zen devd: Parsing /usr/local/etc/devd/webcamd.conf
Feb 18 17:43:44 zen devd: Calling daemon


2. Inserting the USB-C NIC:

Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS subsystem=CDEV
type=CREATE cdev=usb/0.6.0'
Feb 18 18:05:53 zen devd: Pushing table
Feb 18 18:05:53 zen devd: Processing notify event
Feb 18 18:05:53 zen devd: Popping table
Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS subsystem=CDEV
type=CREATE cdev=ugen0.6'
Feb 18 18:05:53 zen devd: Pushing table
Feb 18 18:05:53 zen devd: Processing notify event
Feb 18 18:05:53 zen devd: Popping table
Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS subsystem=CDEV
type=CREATE cdev=usb/0.6.1'
Feb 18 18:05:53 zen devd: Pushing table
Feb 18 18:05:53 zen devd: Processing notify event
Feb 18 18:05:53 zen devd: Popping table
Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS subsystem=CDEV
type=CREATE cdev=usb/0.6.2'
Feb 18 18:05:53 zen devd: Pushing table
Feb 18 18:05:53 zen devd: Processing notify event
Feb 18 18:05:53 zen devd: Popping table
Feb 18 18:05:53 zen devd: Processing event '!system=DEVFS subsystem=CDEV
type=CREATE cdev=usb/0.6.3'
Feb 18 18:05:53 zen devd: Pushing table
Feb 18 18:05:53 zen devd: Processing notify event
Feb 18 18:05:53 zen devd: Popping table
Feb 18 18:05:53 zen devd: Processing event '!system=USB subsystem=DEVICE
type=ATTACH ugen=ugen0.6 cdev=ugen0.6 vendor=0x0bda product=0x8153
devclass=0x00 devsubclass=0x00 sernum="01" release=0x3000 mode=host
port=13 parent=ugen0.1'
Feb 18 18:05:53 zen devd: Pushing table
Feb 18 18:05:53 zen devd: Processing notify event
Feb 18 18:05:53 zen devd: Popping table
Feb 18 18:05:53 zen devd: Processing event '!system=USB
subsystem=INTERFACE type=ATTACH ugen=ugen0.6 cdev=ugen0.6 vendor=0x0bda
product=0x8153 devclass=0x00 devsubclass=0x00 sernum="01"
release=0x3000 mode=host interface=0 endpoints=3 intclass=0xff
intsubclass=0xff intprotocol=0x00'
Feb 18 18:05:53 zen devd: Pushing table
Feb 18 18:05:53 zen devd: Processing notify event
Feb 18 18:05:53 zen devd: Executing '/usr/local/etc/rc.d/webcamd start
ugen0.6'
Feb 18 18:05:53 zen devd: Popping table
Feb 18 18:05:53 zen devd: Processing event '? at bus=0 hubaddr=1 port=13
devaddr=6 interface=0 ugen=ugen0.6 vendor=0x0bda product=0x8153
devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="01"
release=0x3000 mode=host intclass=0xff intsubclass=0xff intprotocol=0x00
on uhub0'
Feb 18 18:05:53 zen devd: Pushing table
Feb 18 18:05:53 zen devd: Processing nomatch event
Feb 18 18:05:53 zen devd: Executing '/etc/rc.d/devmatch start '? at
bus=0 hubaddr=1 port=13 devaddr=6 interface=0 ugen=ugen0.6 vendor=0x0bda
product=0x8153 devclass=0x00 devsubclass=0x00 devproto=0x00
sernum="01" 

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

[Mateusz Guzik]

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, 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.
> > >
> >
> > Looking around strongly suggests r329448 is the culprit. If you can
> verify
> > 329447 works fine we are mostly done here.
>
> I noticed no errors in r329447. When r329529 is built and installed,
> I'll try to incrementally build and install r329531.
>

Can you grab a panicking kernel and apply this:
https://people.freebsd.org/~mjg/wait_unlocked.diff

there may be debug printfs signifying the problem condition was hit,
however the patch should fix the panic

-- 
Mateusz Guzik 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Andriy Gapon]

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 to a documented KPI is 
> "enough"
> A> for any optimization.
> 
> I don't see a sense in making this KPI so sacred. This is something used 
> internally
> in kernel, and not used outside. The KPI has changed several times in the 
> past.

I don't have anything against changing KPI.
At the same time think that it should be well-defined at all times.

> A> > If you can't suggest a more elegant way of doing that improvement, then 
> all
> A> > I can suggest is to document it and add its support to ZFS.
> A> 
> A> In return I can only suggest that (1) you run your suggestion by arch@ -- 
> unless
> A> that's already been done and you can point me to the discussion,  (2) 
> document
> A> it and (3) double-check that all implementations confirm to it.
> 
> I can provide a patch for ZFS.

Thank you.  But I think that the documentation update will be much more 
valuable.


-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Trond Endrestøl]

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 when compiling r329451 while running r329449.
> > I've now booted the r329422 ZFS BE and I'm attempting to build
> > r329529.
> >
> 
> Looking around strongly suggests r329448 is the culprit. If you can verify
> 329447 works fine we are mostly done here.

I noticed no errors in r329447. When r329529 is built and installed, 
I'll try to incrementally build and install r329531.

> Note the revision got reverted and different variant got in in r329531.
> 
> That said, if r329447 works then the issue should be already fixed and in
> particular fresh head should work fine.

-- 
Trond.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Mateusz Guzik]

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 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.
> >>>
> >>
> >> Looking around strongly suggests r329448 is the culprit. If you can
> verify
> >> 329447 works fine we are mostly done here.
> >>
> >> Note the revision got reverted and different variant got in in r329531.
> >>
> >> That said, if r329447 works then the issue should be already fixed and
> in
> >> particular fresh head should work fine.
> >
> > My initial problem was with -r329465, which is after -r329461 reverted
> > -r329488 . Trond reported in one note that he had problems with
> > -r329464 , also after -r329488 was reverted. Trond has also reported
> > -r329449 failed.
>
> Dumb typos above: I meant -r329448 instead of -r329488 both times.
>
>
Ok, I think I see the bug:

exit1 does:
PROC_SLOCK(p);
p->p_state = PRS_ZOMBIE;
/* work continues */

pre-patch proc_to_reap does an equivalent of:
   if (p->p_state == PRS_ZOMBIE) {
PROC_SLOCK(p);
PROC_SUNLOCK(p);
 reap;
  }

It is possible the exiting thread will be caught just after setting the
state to PRS_ZOMBIE.

With the slock/sunlock cycle we guarantee the reaping thread will
wait for it to finish.

Without the cycle we can end up reaping the still exiting thread.

I'll fix it soon(tm).

-- 
Mateusz Guzik 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Mark Millard]

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 compiling r329451 while running r329449.
>> I've now booted the r329422 ZFS BE and I'm attempting to build
>> r329529.
>> 
> 
> Looking around strongly suggests r329448 is the culprit. If you can verify
> 329447 works fine we are mostly done here.
> 
> Note the revision got reverted and different variant got in in r329531.
> 
> That said, if r329447 works then the issue should be already fixed and in
> particular fresh head should work fine.

My initial problem was with -r329465, which is after -r329461 reverted
-r329488 . Trond reported in one note that he had problems with
-r329464 , also after -r329488 was reverted. Trond has also reported
-r329449 failed.

I did manage to revert to -r329447 earlier and so far the results
suggests that it works.

From this I get that -r329449 is the the one that is common to
all the so--far failing combinations. -r329448 is not common to
all of them.


===
Mark Millard
marklmi at yahoo.com
( markmi at dsl-only.net is
going away in 2018-Feb, late)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Mark Millard]

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 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.
>>> 
>> 
>> Looking around strongly suggests r329448 is the culprit. If you can verify
>> 329447 works fine we are mostly done here.
>> 
>> Note the revision got reverted and different variant got in in r329531.
>> 
>> That said, if r329447 works then the issue should be already fixed and in
>> particular fresh head should work fine.
> 
> My initial problem was with -r329465, which is after -r329461 reverted
> -r329488 . Trond reported in one note that he had problems with
> -r329464 , also after -r329488 was reverted. Trond has also reported
> -r329449 failed.

Dumb typos above: I meant -r329448 instead of -r329488 both times.

> I did manage to revert to -r329447 earlier and so far the results
> suggests that it works.
> 
> From this I get that -r329449 is the the one that is common to
> all the so--far failing combinations. -r329448 is not common to
> all of them.


===
Mark Millard
marklmi at yahoo.com
( markmi at dsl-only.net is
going away in 2018-Feb, late)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Mateusz Guzik]

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 r329422 ZFS BE and I'm attempting to build
> r329529.
>

Looking around strongly suggests r329448 is the culprit. If you can verify
329447 works fine we are mostly done here.

Note the revision got reverted and different variant got in in r329531.

That said, if r329447 works then the issue should be already fixed and in
particular fresh head should work fine.

-- 
Mateusz Guzik 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Trond Endrestøl]

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.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Gleb Smirnoff]

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 optimization.

I don't see a sense in making this KPI so sacred. This is something used 
internally
in kernel, and not used outside. The KPI has changed several times in the past.

A> > If you can't suggest a more elegant way of doing that improvement, then all
A> > I can suggest is to document it and add its support to ZFS.
A> 
A> In return I can only suggest that (1) you run your suggestion by arch@ -- 
unless
A> that's already been done and you can point me to the discussion,  (2) 
document
A> it and (3) double-check that all implementations confirm to it.

I can provide a patch for ZFS.

-- 
Gleb Smirnoff
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: How to find CPU microcode version ?

[Cy Schubert]

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

-Original Message-
From: Kurt Jaeger
Sent: 18/02/2018 10:50
To: Andrea Venturoli
Cc: freebsd-current@freebsd.org
Subject: 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 have some other issue, because my problems were ongoing after
reboots.

> Unless of course you set up rc.conf to repeat it at every start...

-- 
p...@opsec.eu+49 171 3101372 2 years to go !
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Andriy Gapon]

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 all
> I can suggest is to document it and add its support to ZFS.

In return I can only suggest that (1) you run your suggestion by arch@ -- unless
that's already been done and you can point me to the discussion,  (2) document
it and (3) double-check that all implementations confirm to it.


-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Mark Millard]

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 its status. But I can assume -r329418 is good if you
want.

Bisecting is likely going to be problematical for self-updates: builds
and installs and such can crash, making the installs risky. I do not
have an alternate builder for amd64 set up.

Even without that, it is not clear how many hours of build-related activity
it takes to have a high probability that the problem is gone. (I've seen
widely variable amounts of activity between failures in -r329465 .) It is
obvious to try an earlier version after failure but not obvious when to
try a later version.

My FreeBSD time is also rather limited (compared to historically over the
last few years), so the activity could be spread over parts of various
weekends, depending on how it goes.

>> 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, 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 Hyper-V use.
>> 
>> Trond's report seems to be for a "4 core" Intel i7 context (as seen
>> by FreeBSD in virtual box). So Ryzen seems to be non-essential for
>> reproduction.
>> 
>> Both of our reports are from some form of using FreeBSD in a virtual
>> machine (Hyper-V and VirtualBox). I do not know if that is a required
>> type of context or not.
>> 
>> >> This happened during:
>> >>
>> >> # 
>> >> ~/sys_build_scripts.amd64-host/make_powerpc64vtsc_nodebug_clang_altbinutils-amd64-host.sh
>> >>  check-old 
>> >> DESTDIR=/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils
>> >> Script started, output file is 
>> >> /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_clang_altbinutils-amd64-host-2018-02-17:15:56:20
>> > Checking for old files
>> >>
>> 
>> I got another example but during a buildworld:
>> 
>> >>> Deleting stale files in build tree...
>> cd /usr/src; MACHINE_ARCH=powerpc64  MACHINE=powerpc  CPUTYPE= 
>> BUILD_TOOLS_META=.NOMETA CC="cc -target powerpc64-unknown-freebsd12.0 
>> --sysroot=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp
>>  -B/usr/local/powerpc64-unknown-freebsd12.0/bin/" CXX="c++  -target 
>> powerpc64-unknown-freebsd12.0 
>> --sysroot=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp
>>  -B/usr/local/powerpc64-unknown-freebsd12.0/bin/"  CPP="cpp -target 
>> powerpc64-unknown-freebsd12.0 
>> --sysroot=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp
>>  -B/usr/local/powerpc64-unknown-freebsd12.0/bin/"  
>> AS="/usr/local/powerpc64-unknown-freebsd12.0/bin/as" 
>> AR="/usr/local/powerpc64-unknown-freebsd12.0/bin/ar" 
>> LD="/usr/local/powerpc64-unknown-freebsd12.0/bin/ld" LLVM_LINK=""  
>> NM=/usr/local/powerpc64-unknown-freebsd12.0/bin/nm 
>> OBJCOPY="/usr/local/powerpc64-unknown-freebsd12.0/bin/objcopy"  
>> RANLIB=/usr/local/powerpc64-unkno
 wn-
>>  freebsd12.0/bin/ranlib 
>> STRINGS=/usr/local/bin/powerpc64-unknown-freebsd12.0-strings  
>> SIZE="/usr/local/powerpc64-unknown-freebsd12.0/bin/size"  INSTALL="sh 
>> /usr/src/tools/install.sh"  
>> PATH=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/legacy/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/legacy/usr/bin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/legacy/bin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin
>>   
>> SYSROOT=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp
>>  make  -f Makefile.inc1  BWPHASE=worldtmp  
>> DESTDIR=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp
>>  -DBATCH_DELETE_OLD_FILES  delete-ol
 d d
>>  elete-old-libs >/dev/null
>> 
>> load: 0.68  cmd: make 62180 [select] 25.15r 0.00u 0.00s 0% 1468k
>> make: Working in: 
>> /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64
>> packet_write_wait: Connection to 192.168.1.165 port 22: Broken pipe
>> 
>> 
>> (I noticed the long pause and got the ^T in before the panic.)
>> 
>> Yet again it is xargs related fork activity that gets the problem (from 
>> core.txt.1 ):
>> 

Re: r329501 devd doesn't find USB devices

[Warner Losh]

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 whether I needed to do anything
> beyond building and installing kernel and world as well as updating
> /etc.  There was reference to removing /etc/devd/usb.conf in another
> thread but its presence or lack thereof makes no difference.
>
>
> I assume you've fully updated including /etc.
>
>
> In as much as 'mergemaster -Ui' fully updates /etc
>
> If you can uncomment the devd lines in syslog.conf, touch
> /var/log/devd.log and reboot. Once you are up again, please send me
> /var/log/devd.conf.
>
>
> Assuming you mean these lines:
>
> !devd
> *.>=notice  /var/log/devd.log
>
> devd produced zero logs on reboot and restart.
>

There should be a lot of output... one line per device that's attached...
Did you create /var/log/devd.log before reboot? Is your /dev/log persistent
across boots?

Warner


> Ian
>
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r329501 devd doesn't find USB devices

[Warner Losh]

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"
> >>> >
> >>> wrote:
> >>>
> >>>  Hi
> >>>
> >>>  Since devmatch some of my USB devices no longer get their drivers
> >>>  loaded.  It's not clear from UPDATING whether I needed to do
> >>> anything
> >>>  beyond building and installing kernel and world as well as
> >>> updating
> >>>  /etc.  There was reference to removing /etc/devd/usb.conf in
> >>> another
> >>>  thread but its presence or lack thereof makes no difference.
> >>>
> >>>
> >>> I assume you've fully updated including /etc.
> >>
> >> In as much as 'mergemaster -Ui' fully updates /etc
> >>
> >>> If you can uncomment the devd lines in syslog.conf, touch
> >>> /var/log/devd.log and reboot. Once you are up again, please send me
> >>> /var/log/devd.conf.
> >>
> >> Assuming you mean these lines:
> >>
> >> !devd
> >> *.>=notice  /var/log/devd.log
> >>
> >> devd produced zero logs on reboot and restart.
> >
> > Can you run:
> >
> > usbconfig show_ifdrv
> >
> > Maybe the wrong driver captured your device?
>
> ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER
> (5.0Gbps) pwr=SAVE (0mA)
> ugen0.1.0: uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1>
> ugen0.2:  at usbus0, cfg=0 md=HOST
> spd=HIGH (480Mbps) pwr=ON (500mA)
> ugen0.3:  at usbus0, cfg=0 md=HOST
> spd=FULL (12Mbps) pwr=ON (100mA)
> ugen0.3.0: ubt0:  2.00/0.10, addr 2>
> ugen0.4:  at usbus0, cfg=0 md=HOST spd=FULL
> (12Mbps) pwr=ON (100mA)
> ugen0.5:  at usbus0, cfg=0 md=HOST
> spd=FULL (12Mbps) pwr=ON (100mA)
> ugen0.6:  at usbus0, cfg=0 md=HOST spd=SUPER
> (5.0Gbps) pwr=ON (72mA)
>
> After loading ums and ukbd:
>
> ugen0.5:  at usbus0, cfg=0 md=HOST
> spd=FULL (12Mbps) pwr=ON (100mA)
> ugen0.5.0: ukbd0:  1.10/10.01, addr 5>
> ugen0.5.1: ums0:  1.10/10.01, addr 5>
>

So what happens if you build these drivers into the kernel vs loading them?

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Mark Millard]

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), update the source tree, move forward to the latest 
> revision, and so on. I even emptied /usr/obj and /var/cache/ccache and 
> set WITHOUT_SYSTEM_COMPILER=yes in /etc/src.conf to get rid of any 
> bias.
> 
> I have tried with success r329418, r329419, r329420, and r329422.
> 
> I'm now at r329448 and have not seen any spin lock problems so far.

Note: -r329448 was reverted in -r329461 : racy.

> Sooner or later I'll reach r329464 and by then it should be clear 
> which revision is the likely culprit.

===
Mark Millard
marklmi at yahoo.com
( markmi at dsl-only.net is
going away in 2018-Feb, late)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Trond Endrestøl]

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 on. I even emptied /usr/obj and /var/cache/ccache and 
set WITHOUT_SYSTEM_COMPILER=yes in /etc/src.conf to get rid of any 
bias.

I have tried with success r329418, r329419, r329420, and r329422.

I'm now at r329448 and have not seen any spin lock problems so far.

Sooner or later I'll reach r329464 and by then it should be clear 
which revision is the likely culprit.

-- 
Trond.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: How to find CPU microcode version ?

[Kurt Jaeger]

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 have some other issue, because my problems were ongoing after
reboots.

> Unless of course you set up rc.conf to repeat it at every start...

-- 
p...@opsec.eu+49 171 3101372 2 years to go !
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: How to find CPU microcode version ?

[Andrea Venturoli]

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.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Mateusz Guzik]

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, 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 Hyper-V use.
>
> Trond's report seems to be for a "4 core" Intel i7 context (as seen
> by FreeBSD in virtual box). So Ryzen seems to be non-essential for
> reproduction.
>
> Both of our reports are from some form of using FreeBSD in a virtual
> machine (Hyper-V and VirtualBox). I do not know if that is a required
> type of context or not.
>
> >> This happened during:
> >>
> >> # ~/sys_build_scripts.amd64-host/make_powerpc64vtsc_
> nodebug_clang_altbinutils-amd64-host.sh check-old
> DESTDIR=/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils
> >> Script started, output file is /root/sys_typescripts/
> typescript_make_powerpc64vtsc_nodebug_clang_altbinutils-
> amd64-host-2018-02-17:15:56:20
> > Checking for old files
> >>
>
> I got another example but during a buildworld:
>
> >>> Deleting stale files in build tree...
> cd /usr/src; MACHINE_ARCH=powerpc64  MACHINE=powerpc  CPUTYPE=
> BUILD_TOOLS_META=.NOMETA CC="cc -target powerpc64-unknown-freebsd12.0
> --sysroot=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp
> -B/usr/local/powerpc64-unknown-freebsd12.0/bin/" CXX="c++  -target
> powerpc64-unknown-freebsd12.0 --sysroot=/usr/obj/powerpc64vtsc_clang_
> altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp
> -B/usr/local/powerpc64-unknown-freebsd12.0/bin/"  CPP="cpp -target
> powerpc64-unknown-freebsd12.0 --sysroot=/usr/obj/powerpc64vtsc_clang_
> altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp
> -B/usr/local/powerpc64-unknown-freebsd12.0/bin/"
> AS="/usr/local/powerpc64-unknown-freebsd12.0/bin/as"
> AR="/usr/local/powerpc64-unknown-freebsd12.0/bin/ar"
> LD="/usr/local/powerpc64-unknown-freebsd12.0/bin/ld" LLVM_LINK=""
> NM=/usr/local/powerpc64-unknown-freebsd12.0/bin/nm
> OBJCOPY="/usr/local/powerpc64-unknown-freebsd12.0/bin/objcopy"
> RANLIB=/usr/local/powerpc64-unknown-
>  freebsd12.0/bin/ranlib STRINGS=/usr/local/bin/
> powerpc64-unknown-freebsd12.0-strings  
> SIZE="/usr/local/powerpc64-unknown-freebsd12.0/bin/size"
> INSTALL="sh /usr/src/tools/install.sh"  PATH=/usr/obj/powerpc64vtsc_
> clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.
> powerpc64/tmp/legacy/usr/sbin:/usr/obj/powerpc64vtsc_clang_
> altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/
> legacy/usr/bin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/
> usr/src/powerpc.powerpc64/tmp/legacy/bin:/usr/obj/powerpc64vtsc_clang_
> altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/
> usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/
> usr/src/powerpc.powerpc64/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin
> SYSROOT=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp
> make  -f Makefile.inc1  BWPHASE=worldtmp  DESTDIR=/usr/obj/
> powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp
> -DBATCH_DELETE_OLD_FILES  delete-old d
>  elete-old-libs >/dev/null
>
> load: 0.68  cmd: make 62180 [select] 25.15r 0.00u 0.00s 0% 1468k
> make: Working in: /usr/obj/powerpc64vtsc_clang_
> altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64
> packet_write_wait: Connection to 192.168.1.165 port 22: Broken pipe
>
>
> (I noticed the long pause and got the ^T in before the panic.)
>
> Yet again it is xargs related fork activity that gets the problem (from
> core.txt.1 ):
>
>   561 Thread 100836 (PID=69982: xargs)  fork_trampoline () at
> /usr/src/sys/amd64/amd64/exception.S:840
> . . .
> * 559 Thread 100811 (PID=62304: xargs)  doadump (textdump=-2122191464) at
> pcpu.h:230
>
> spin lock 0x81b3cf00 (sched lock 24) held by 0xf806aa6d5000
> (tid 100836) too long
> panic: spin lock held too long
> cpuid = 24
> time = 1518974055
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfe00f11304d0
> vpanic() at vpanic+0x18d/frame 0xfe00f1130530
> panic() at panic+0x43/frame 0xfe00f1130590
> _mtx_lock_indefinite_check() at _mtx_lock_indefinite_check+0x71/frame
> 0xfe00f11305a0
> thread_lock_flags_() at thread_lock_flags_+0xdb/frame 0xfe00f1130610
> statclock_cnt() at statclock_cnt+0xdc/frame 0xfe00f1130650
> handleevents() at handleevents+0x113/frame 0xfe00f11306a0
> timercb() at timercb+0xa9/frame 0xfe00f11306f0
> lapic_handle_timer() at lapic_handle_timer+0xa7/frame 0xfe00f1130730
> timerint_u() at timerint_u+0x96/frame 

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

[Mark Millard]

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 insides of NTFS files.
>> 29 logical processors assigned to FreeBSD (on a 32-thread Ryzen
>> Threadripper 1950X). No other Hyper-V use.

Trond's report seems to be for a "4 core" Intel i7 context (as seen
by FreeBSD in virtual box). So Ryzen seems to be non-essential for
reproduction.

Both of our reports are from some form of using FreeBSD in a virtual
machine (Hyper-V and VirtualBox). I do not know if that is a required
type of context or not.

>> This happened during:
>> 
>> # 
>> ~/sys_build_scripts.amd64-host/make_powerpc64vtsc_nodebug_clang_altbinutils-amd64-host.sh
>>  check-old DESTDIR=/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils
>> Script started, output file is 
>> /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_clang_altbinutils-amd64-host-2018-02-17:15:56:20
> Checking for old files
>> 

I got another example but during a buildworld:

>>> Deleting stale files in build tree...
cd /usr/src; MACHINE_ARCH=powerpc64  MACHINE=powerpc  CPUTYPE= 
BUILD_TOOLS_META=.NOMETA CC="cc -target powerpc64-unknown-freebsd12.0 
--sysroot=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp
 -B/usr/local/powerpc64-unknown-freebsd12.0/bin/" CXX="c++  -target 
powerpc64-unknown-freebsd12.0 
--sysroot=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp
 -B/usr/local/powerpc64-unknown-freebsd12.0/bin/"  CPP="cpp -target 
powerpc64-unknown-freebsd12.0 
--sysroot=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp
 -B/usr/local/powerpc64-unknown-freebsd12.0/bin/"  
AS="/usr/local/powerpc64-unknown-freebsd12.0/bin/as" 
AR="/usr/local/powerpc64-unknown-freebsd12.0/bin/ar" 
LD="/usr/local/powerpc64-unknown-freebsd12.0/bin/ld" LLVM_LINK=""  
NM=/usr/local/powerpc64-unknown-freebsd12.0/bin/nm 
OBJCOPY="/usr/local/powerpc64-unknown-freebsd12.0/bin/objcopy"  
RANLIB=/usr/local/powerpc64-unknown-
 freebsd12.0/bin/ranlib 
STRINGS=/usr/local/bin/powerpc64-unknown-freebsd12.0-strings  
SIZE="/usr/local/powerpc64-unknown-freebsd12.0/bin/size"  INSTALL="sh 
/usr/src/tools/install.sh"  
PATH=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/legacy/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/legacy/usr/bin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/legacy/bin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin
  
SYSROOT=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp
 make  -f Makefile.inc1  BWPHASE=worldtmp  
DESTDIR=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp
 -DBATCH_DELETE_OLD_FILES  delete-old d
 elete-old-libs >/dev/null

load: 0.68  cmd: make 62180 [select] 25.15r 0.00u 0.00s 0% 1468k
make: Working in: 
/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64
packet_write_wait: Connection to 192.168.1.165 port 22: Broken pipe


(I noticed the long pause and got the ^T in before the panic.)

Yet again it is xargs related fork activity that gets the problem (from 
core.txt.1 ):

  561 Thread 100836 (PID=69982: xargs)  fork_trampoline () at 
/usr/src/sys/amd64/amd64/exception.S:840
. . .
* 559 Thread 100811 (PID=62304: xargs)  doadump (textdump=-2122191464) at 
pcpu.h:230

spin lock 0x81b3cf00 (sched lock 24) held by 0xf806aa6d5000 (tid 
100836) too long
panic: spin lock held too long
cpuid = 24
time = 1518974055
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00f11304d0
vpanic() at vpanic+0x18d/frame 0xfe00f1130530
panic() at panic+0x43/frame 0xfe00f1130590
_mtx_lock_indefinite_check() at _mtx_lock_indefinite_check+0x71/frame 
0xfe00f11305a0
thread_lock_flags_() at thread_lock_flags_+0xdb/frame 0xfe00f1130610
statclock_cnt() at statclock_cnt+0xdc/frame 0xfe00f1130650
handleevents() at handleevents+0x113/frame 0xfe00f11306a0
timercb() at timercb+0xa9/frame 0xfe00f11306f0
lapic_handle_timer() at lapic_handle_timer+0xa7/frame 0xfe00f1130730
timerint_u() at timerint_u+0x96/frame 0xfe00f1130810
thread_lock_flags_() at thread_lock_flags_+0xc1/frame 0xfe00f1130880
fork1() at fork1+0x1b9f/frame 0xfe00f1130930
sys_vfork() at sys_vfork+0x4c/frame 0xfe00f1130980
amd64_syscall() at amd64_syscall+0xa48/frame 0xfe00f1130ab0
fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffc5a0

Re: Buildworld failing during llvm

[Dimitry Andric]

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 related:
> https://svnweb.freebsd.org/base?view=revision=329410
> 
> 
> --- clang.full ---
> c++ -O2 -pipe
> -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang
> -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm
> -I/usr/src/contrib/llvm/tools/clang/include -I/usr/src/lib/clang/include
> -I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL
> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
> -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\"
> -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\"
> -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/amd64.amd64/tmp\" -ffunction-sections
> -fdata-sections -g -O0 -Qunused-arguments
> -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -std=c++11
> -fno-exceptions -fno-rtti -g -O0 -stdlib=libc++ -Wno-c++11-extensions
> -Wl,--gc-sections -static -L/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/lib
> -o clang.full  cc1_main.o cc1as_main.o driver.o
> /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang/libclang.a
> /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a
> -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libz -lz
> -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/ncurses/ncursesw
> -lncursesw -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libthr
> -lpthread -legacy
> /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a:
> could not read symbols: Malformed archive

Hi Ben,

This is most likely because you are setting CFLAGS to "-g -O0", which
causes libllvm.a and libclang.a to become too big (>2GiB) for ar to
handle.  Then the linker finds the archive malformed.

John Baldwin added some special handling for libraries under lib/clang,
so they emit smaller debug information, so just leave out -g from your
CFLAGS, buildworld will automatically take care of applying the right
-g flags in all the various places.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: How to find CPU microcode version ?

[Kurt Jaeger]

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 which showed problems, I had:

-> CPUID: 306a9  Family: 06  Model: 3A  Stepping: 09  uCodeRev: 0012

Update done with 

pkg install devcpu-data

service microcode_update start

Now I have:

-> CPUID: 306a9  Family: 06  Model: 3A  Stepping: 09  uCodeRev: 001C

On the spare box that shows no sign of trouble:

-> CPUID: 306a9  Family: 06  Model: 3A  Stepping: 09  uCodeRev: 0019

Hmm.

-- 
p...@opsec.eu+49 171 3101372 2 years to go !
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: How to find CPU microcode version ?

[Kurt Jaeger]

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 3101372 2 years to go !
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r329501 devd doesn't find USB devices

[Ian FREISLICH]

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 devmatch some of my USB devices no longer get their drivers
>>>  loaded.  It's not clear from UPDATING whether I needed to do
>>> anything
>>>  beyond building and installing kernel and world as well as
>>> updating
>>>  /etc.  There was reference to removing /etc/devd/usb.conf in
>>> another
>>>  thread but its presence or lack thereof makes no difference.
>>>
>>>
>>> I assume you've fully updated including /etc.
>>
>> In as much as 'mergemaster -Ui' fully updates /etc
>>
>>> If you can uncomment the devd lines in syslog.conf, touch
>>> /var/log/devd.log and reboot. Once you are up again, please send me
>>> /var/log/devd.conf.
>>
>> Assuming you mean these lines:
>>
>> !devd
>> *.>=notice  /var/log/devd.log
>>
>> devd produced zero logs on reboot and restart.
>
> Can you run:
>
> usbconfig show_ifdrv
>
> Maybe the wrong driver captured your device?

ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER
(5.0Gbps) pwr=SAVE (0mA)
ugen0.1.0: uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1>
ugen0.2:  at usbus0, cfg=0 md=HOST
spd=HIGH (480Mbps) pwr=ON (500mA)
ugen0.3:  at usbus0, cfg=0 md=HOST
spd=FULL (12Mbps) pwr=ON (100mA)
ugen0.3.0: ubt0: 
ugen0.4:  at usbus0, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=ON (100mA)
ugen0.5:  at usbus0, cfg=0 md=HOST
spd=FULL (12Mbps) pwr=ON (100mA)
ugen0.6:  at usbus0, cfg=0 md=HOST spd=SUPER
(5.0Gbps) pwr=ON (72mA)

After loading ums and ukbd:

ugen0.5:  at usbus0, cfg=0 md=HOST
spd=FULL (12Mbps) pwr=ON (100mA)
ugen0.5.0: ukbd0: 
ugen0.5.1: ums0: 

> Try running:
>
> usbconfig -d X.Y reset

This produces no kernel messages, no difference to drivers.


-- 

ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) 
pwr=SAVE (0mA)

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0300 
  bDeviceClass = 0x0009  
  bDeviceSubClass = 0x 
  bDeviceProtocol = 0x0003 
  bMaxPacketSize0 = 0x0009 
  idVendor = 0x 
  idProduct = 0x 
  bcdDevice = 0x0100 
  iManufacturer = 0x0001  <0x8086>
  iProduct = 0x0002  
  iSerialNumber = 0x  
  bNumConfigurations = 0x0001 

ugen0.2:  at usbus0, cfg=0 md=HOST spd=HIGH 
(480Mbps) pwr=ON (500mA)

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0200 
  bDeviceClass = 0x00ef  
  bDeviceSubClass = 0x0002 
  bDeviceProtocol = 0x0001 
  bMaxPacketSize0 = 0x0040 
  idVendor = 0x13d3 
  idProduct = 0x5755 
  bcdDevice = 0x1612 
  iManufacturer = 0x0003  
  iProduct = 0x0001  
  iSerialNumber = 0x0002  <0001>
  bNumConfigurations = 0x0001 

ugen0.3:  at usbus0, cfg=0 md=HOST spd=FULL 
(12Mbps) pwr=ON (100mA)

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0200 
  bDeviceClass = 0x00e0  
  bDeviceSubClass = 0x0001 
  bDeviceProtocol = 0x0001 
  bMaxPacketSize0 = 0x0040 
  idVendor = 0x8087 
  idProduct = 0x0a2b 
  bcdDevice = 0x0010 
  iManufacturer = 0x  
  iProduct = 0x  
  iSerialNumber = 0x  
  bNumConfigurations = 0x0001 

ugen0.4:  at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) 
pwr=ON (100mA)

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0200 
  bDeviceClass = 0x  
  bDeviceSubClass = 0x 
  bDeviceProtocol = 0x 
  bMaxPacketSize0 = 0x0008 
  idVendor = 0x04f3 
  idProduct = 0x0903 
  bcdDevice = 0x0135 
  iManufacturer = 0x0001  
  iProduct = 0x0002  
  iSerialNumber = 0x  
  bNumConfigurations = 0x0001 

ugen0.5:  at usbus0, cfg=0 md=HOST spd=FULL 
(12Mbps) pwr=ON (100mA)

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0110 
  bDeviceClass = 0x  
  bDeviceSubClass = 0x 
  bDeviceProtocol = 0x 
  bMaxPacketSize0 = 0x0040 
  idVendor = 0x24ae 
  idProduct = 0x2000 
  bcdDevice = 0x1001 
  iManufacturer = 0x0001  
  iProduct = 0x0002  
  iSerialNumber = 0x  
  bNumConfigurations = 0x0001 

ugen0.6:  at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) 
pwr=ON (72mA)

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0300 
  bDeviceClass = 0x  
  bDeviceSubClass = 0x 
  bDeviceProtocol = 0x 
  bMaxPacketSize0 = 0x0009 
  idVendor = 0x0bda 
  idProduct = 0x8153 
  bcdDevice = 0x3000 
  iManufacturer = 0x0001  
  iProduct = 0x0002  
  iSerialNumber = 0x0006  <01>
  bNumConfigurations = 0x0002 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: How to find CPU microcode version ?

[Rainer Duffner]

> 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 
„fixing" the various Spectre-variants.



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Gleb Smirnoff]

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> > A> amd64_syscall() at amd64_syscall+0x79b/frame 0xfe00b3c36ab0
A> > A> fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffdb00
A> > A> 
A> > A> I looked at sendfile_swapin() code and it seems that it uses the pager 
API in an
A> > A> undocumented way.  Specifically, it inserts bogus_page into the array of
A> > A> requested pages.  For starters, bogus_page is not busied and 
VOP_GETPAGES is
A> > A> documented to have all requested pages exclusively busied.  Second, I 
always had
A> > A> an impression that bogus_page is an implementation detail of the 
unified buffer
A> > A> / page cache and that other code need not be aware of it.
A> > A> 
A> > A> So, my opinion is that the sendfile code uses a "clever hack" that 
happens to
A> > A> work with the buffer cache based filesystems, but that that hack is a 
bug.
A> > A> So, I'd prefer that the problem is fixed in that code.
A> > A> But I am open to being convinced that all VOP_GETPAGES implementations,
A> > A> including that in ZFS, must be made aware of bogus_page.  Or, at least, 
that
A> > A> they should not verify that the requested pages are busied.
A> > 
A> > This is optimization that improves throughput when file memory cache is
A> > fragmented. Why don't you like adding the code to zfs_freebsd_getpages()?
A> 
A> I cited two reasons above and expected to hear some counter-points rather 
than
A> them being ignored :-)
A> If we settle upon allowing bogus_page to be used in ma[], then that will
A> obviously need to be documented.

My only point is that it is a performance improvement. IMHO that's enough :)
If you can't suggest a more elegant way of doing that improvement, then all
I can suggest is to document it and add its support to ZFS.

-- 
Gleb Smirnoff
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Trond Endrestøl]

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 Hyper-V use.
> 
> This happened during:
> 
> # 
> ~/sys_build_scripts.amd64-host/make_powerpc64vtsc_nodebug_clang_altbinutils-amd64-host.sh
>  check-old DESTDIR=/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils
> Script started, output file is 
> /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_clang_altbinutils-amd64-host-2018-02-17:15:56:20
> >>> Checking for old files
> 
> 
> (Hand typed from a picture of a window's content
> at slighly different times, expect typos:)
> 
> KDB: enter: panic
> [thread pid 42170 tid 100752 ]
> Stopped at kdb_enter+0x3b: movq $0,kdb_why
> db> call doadump
> Dumping 4825 out of 110559 MB: ... (omitted) ...
> Dump complete
> = 0
> 
> 
> (The "pid 42170" identification as the process reporting the
> issue does not seem to appear in the core.txt.0 file.)
> 
> 
> # ls -lTdt /var/crash/*
> -rw-r--r--  1 root  wheel  100792 Feb 17 16:09:18 2018 
> /var/crash/core.txt.0
> lrwxr-xr-x  1 root  wheel   8 Feb 17 16:09:08 2018 
> /var/crash/vmcore.last -> vmcore.0
> lrwxr-xr-x  1 root  wheel   6 Feb 17 16:09:08 2018 
> /var/crash/info.last -> info.0
> -rw---  1 root  wheel  5060296704 Feb 17 16:09:08 2018 /var/crash/vmcore.0
> -rw---  1 root  wheel 392 Feb 17 16:08:59 2018 /var/crash/info.0
> -rw-r--r--  1 root  wheel   2 Feb 17 16:08:59 2018 /var/crash/bounds
> -rw-r--r--  1 root  wheel   5 Nov 22 04:34:36 2017 /var/crash/minfree
> 
> >From /var/crash/core.txt.0 :
> 
> Unread portion of the kernel message buffer:
> spin lock 0x81b2dcc0 (sched lock 5) held by 0xf8011d936560 (tid 
> 100691) too long
> panic: spin lock held too long
> cpuid = 5
> time = 1518911834
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00f10094d0
> vpanic() at vpanic+0x18d/frame 0xfe00f1009530
> panic() at panic+0x43/frame 0xfe00f1009590
> _mtx_lock_indefinite_check() at _mtx_lock_indefinite_check+0x71/frame 
> 0xfe00f10095a0
> thread_lock_flags_() at thread_lock_flags_+0xdb/frame 0xfe00f1009610
> statclock_cnt() at statclock_cnt+0xdc/frame 0xfe00f1009650
> handleevents() at handleevents+0x113/frame 0xfe00f10096a0
> timercb() at timercb+0xa9/frame 0xfe00f10096f0
> lapic_handle_timer() at lapic_handle_timer+0xa7/frame 0xfe00f1009730
> timerint_u() at timerint_u+0x96/frame 0xfe00f1009810
> thread_lock_flags_() at thread_lock_flags_+0xc1/frame 0xfe00f1009880
> fork1() at fork1+0x1b9f/frame 0xfe00f1009930
> sys_vfork() at sys_vfork+0x4c/frame 0xfe00f1009980
> amd64_syscall() at amd64_syscall+0xa48/frame 0xfe00f1009ab0
> fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffcfc0
> KDB: enter: panic
> 
> __curthread () at ./machine/pcpu.h:230
> 230 __asm("movq %%gs:%1,%0" : "=r" (td)
> (kgdb) #0  __curthread () at ./machine/pcpu.h:230
> #1  doadump (textdump=-2122191464) at /usr/src/sys/kern/kern_shutdown.c:347
> #2  0x8040b42c in db_fncall_generic (addr=, 
>rv=, nargs=, args=)
>at /usr/src/sys/ddb/db_command.c:609
> #3  db_fncall (dummy1=, dummy2=, 
>dummy3=, dummy4=)
>at /usr/src/sys/ddb/db_command.c:657
> #4  0x8040af79 in db_command (last_cmdp=, 
>cmd_table=, dopager=)
>at /usr/src/sys/ddb/db_command.c:481
> #5  0x8040acf4 in db_command_loop ()
>at /usr/src/sys/ddb/db_command.c:534
> #6  0x8040df9f in db_trap (type=, code=)
>at /usr/src/sys/ddb/db_main.c:250
> #7  0x80b370e3 in kdb_trap (type=3, code=-61456, tf=)
>at /usr/src/sys/kern/subr_kdb.c:697
> #8  0x80fa2c5c in trap (frame=0xfe00f1009400)
>at /usr/src/sys/amd64/amd64/trap.c:547
> #9  
> #10 kdb_enter (why=0x811f280b "panic", msg=)
>at /usr/src/sys/kern/subr_kdb.c:479
> #11 0x80aef17a in vpanic (fmt=, ap=0xfe00f1009570)
>at /usr/src/sys/kern/kern_shutdown.c:801
> #12 0x80aeefc3 in panic (fmt=0x0)
>at /usr/src/sys/kern/kern_shutdown.c:739
> #13 0x80acfa31 in _mtx_lock_indefinite_check (m=, 
>ldap=) at /usr/src/sys/kern/kern_mutex.c:1224
> #14 0x80acfb9b in thread_lock_flags_ (td=0xf818719d1000, 
>opts=, file=, line=)
>at /usr/src/sys/kern/kern_mutex.c:913
> #15 0x80a89d6c in statclock_cnt (cnt=1, usermode=)
>at /usr/src/sys/kern/kern_clock.c:768
> #16 0x810d0003 in handleevents (now=43230207690178, fake=0)
>at /usr/src/sys/kern/kern_clocksource.c:196
> #17 0x810d0709 in timercb (et=0x81c528e8 , 
>arg=) at /usr/src/sys/kern/kern_clocksource.c:353
> #18 0x8110dad7 in lapic_handle_timer (frame=0xfe00f1009740)
>at 

How to find CPU microcode version ?

[Kurt Jaeger]

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 issues approx. since 14th of Februar.

It had two updates since 8th of January, to r328013 on the 16th of Jan.
and to r328899 on the 6th of February.

Around the 14th, processes started to be killed for out of swapspace,
even if the box had almost no load at all.

pid 1056 (mutt), uid 104, was killed: out of swap space
pid 536 (devd), uid 0, was killed: out of swap space
pid 15093 (exim), uid 26, was killed: out of swap space
pid 91868 (mutt), uid 104, was killed: out of swap space
pid 1086 (sshd), uid 104, was killed: out of swap space

Reboot of the box and waiting a few hours and the problem re-occured.

The box has 32 GB RAM and 34 GB swap, which never was utilized
beyond a few hundred MBs.

Moving the two disks involved to a very similar hardware and
the 'dying' stopped.

The 'strange box' runs a debian version now for 24 hours, no problems.

-- 
p...@opsec.eu+49 171 3101372 2 years to go !
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"