Just a pair of no-urgency questions...

[Jeffrey Bouquet]

I check freshports.org and freshsource.org daily,  so I can read new features, 
UPDATING etc
without svn usage, and would have been maybe dealt problematic buildworlds etc 
without such.
...
Additionally, I learn the bits and pieces of developer skills, very slowly.

Not a developer here, ever, but for others and here convenience
...
1...   could freshports.org and freshsource.org be officially part of FreeBSD 
so their continued 
existence is assured as the OS progresses?
2...  [the reason primary for this email]  It would be less distracting if 
while I browsed the
pages, a bar [set by cookies, probably] in a unique color, would notify me if I 
had read the
subsequent text, like a forum ' the posts by here are not net' line, and would 
save
time daily.  Can that be easily backported to each of the two sites???  I'd 
even value that
to be an annual fee product I would pay for...
Not a webcoder, obviously...  out of time.

Thanks.
___
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: Intel ac8260 and wpa_supplicant

[Andreas Nilsson]

Hello,

thanks, that explains it.

Best regards
Andreas

On Tue, Sep 6, 2016 at 10:26 PM, Adrian Chadd 
wrote:

> hi,
>
> There's some interesting issues with the scan logic in -HEAD where we
> abort/finish a scan if there's active traffic, but there's no way to
> say "the scan was interrupted by active traffic and will continue"
> versus "the scan was aborted" or "the scan is finished". So sometimes
> the scan results list in wpa_supplicant returns prematurely and it
> doesn't know to fetch an updated one.
>
>
>
> -adrian
>
>
> On 6 September 2016 at 13:17, Andreas Nilsson  wrote:
> > Hello,
> >
> > I installed 12-CURRENT from a few days ago on my laptop ( thinkpad x1
> yoga
> > ). The wireless cards was detected and I could create a wlan0 device and
> > scan for networks.
> >
> > Upon starting wpa_supplicant things go awry, running scan_results in
> > wpa_cli times out  and returns empty list while ifconfig wlan0 list scan
> > returns expected list. Any ideas on what to try?
> >
> > Seems to be dependent on the number of networks found.
> >
> > Best regards
> > Andreas Nilsson
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
> 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"

kldload intpm

[Andriy Gapon]

Has kldload intpm ever worked?
Ditto for other smbus drivers.

The reason I am asking is that it doesn't work for me on the latest head.
And it doesn't work because device_probe_and_attach(sc->smbus) fails in
intsmb_attach().

With a little help from DTrace I obtained the following output:
CPU IDFUNCTION:NAME
  0  41924devclass_add_driver:entry devclass = 0xf8000675b700, name
= pci, driver = 0x832ed058, name = intsmb

  0  32121 device_probe_child:entry
parent = 0xf8000af78100, nameunit = intsmb0, devclass = 0xf8001d955880,
name = intsmb, driver = 0x0, name = 
child = 0xf8001d933500, nameunit = smbus1, devclass = 0xf8001d955780,
name = smbus

  kernel`device_probe+0x9d
  kernel`device_probe_and_attach+0x2e
  intpm.ko`intsmb_attach+0x651
  kernel`device_attach+0x41d
  kernel`pci_driver_added+0xed
  kernel`devclass_driver_added+0x7d
  kernel`devclass_add_driver+0x144
  kernel`module_register_init+0xb0
  kernel`linker_load_module+0xc88
  kernel`kern_kldload+0xa7
  kernel`sys_kldload+0x5b
  kernel`amd64_syscall+0x2db
  kernel`0x80e918ab

  1  41924devclass_add_driver:entry devclass = 0xf8001d955880, name
= intsmb, driver = 0x832ee930, name = smbus

My interpretation is that intsmb_attach() is called before the smbus driver is
associated with the intsmb devclass.  That means that the devclass does not have
any drivers at all when intsmb_attach() calls device_probe_and_attach() on its
smbus child.  It's too late when the smbus driver is added to the intsmb 
devclass.

Okay, writing the above gave me an idea to try to change the order of
DRIVER_MODULE() lines in intpm.c and that fixed the problem.

But I seem to recall that some years ago kldload intpm worked without the
change.  Perhaps the order has changed in the module loading code.
Anyway, this seems to be very subtle and error prone.  I wonder if we could make
it more robust.

-- 
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: 11.0-RC2 suspend/resume on thinkpad x201 kills poweroff

[Glen Barber]

On Thu, Sep 08, 2016 at 12:48:28AM +0200, Philip Homburg wrote:
> Hi,
> 
> I found out that playing with suspend/resume (using acpiconf -s 3) on a
> thinkpad x201 running 11.0-RC2 changes something in CMOS that prevents
> poweroff from working.
> 
> I managed to trigger the problem om two x201 laptops (though from the
> a single 11.0-RC2 installation).
> 
> Opening up the laptops to clear the CMOS solved the problem.
> 
> If I can find some time, I'll try to see if there is an interaction with
> for example the wifi driver.
> 
> When in this state, it also prevents suspend or poweroff from Linux (I tried
> a Ubuntu live CD). 
> 

Any chance you can try this with 10.3-RELEASE?

Glen



signature.asc
Description: PGP signature

11.0-RC2 suspend/resume on thinkpad x201 kills poweroff

[Philip Homburg]

Hi,

I found out that playing with suspend/resume (using acpiconf -s 3) on a
thinkpad x201 running 11.0-RC2 changes something in CMOS that prevents
poweroff from working.

I managed to trigger the problem om two x201 laptops (though from the
a single 11.0-RC2 installation).

Opening up the laptops to clear the CMOS solved the problem.

If I can find some time, I'll try to see if there is an interaction with
for example the wifi driver.

When in this state, it also prevents suspend or poweroff from Linux (I tried
a Ubuntu live CD). 


___
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"

Call for 2016Q3 quarterly status reports

[Benjamin Kaduk]

Dear FreeBSD Community,

The deadline for the next FreeBSD Quarterly Status update is October 7,
2016, for work done in July through September.

Status report submissions do not have to be very long.  They may be about
anything happening in the FreeBSD project and community, and provide a
great way to inform FreeBSD users and developers about what you're working
on.  Submission of reports is not restricted to committers.  Anyone doing
anything interesting and FreeBSD-related can -- and should -- write one!

The preferred and easiest submission method is to use the XML generator
[1] with the results emailed to the status report team at monthly at
FreeBSD.org .  There is also an XML template [2] which can be filled out
manually and attached if preferred.  For the expected content and style,
please study our guidelines on how to write a good status report [3].
You can also review previous issues [4][5] for ideas on the style and
format.

We are looking forward to all of your 2016Q3 reports!

Thanks,

Ben (on behalf of monthly@)

[1] https://www.FreeBSD.org/cgi/monthly.cgi
[2] https://www.FreeBSD.org/news/status/report-sample.xml
[3] https://www.FreeBSD.org/news/status/howto.html
[4] https://www.FreeBSD.org/news/status/report-2016-01-2016-03.html
[4] https://www.FreeBSD.org/news/status/report-2016-04-2016-06.html

___
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"

Jenkins build is back to normal : FreeBSD_HEAD #611

[jenkins-admin]

See 

___
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"

Build failed in Jenkins: FreeBSD_HEAD #610

[jenkins-admin]

See 

--
[...truncated 352326 lines...]
[192.168.10.2] out: lib/libc/c063/utimensat_test:utimensat_fderr1  ->  passed  
[0.014s]
[192.168.10.2] out: lib/libc/c063/utimensat_test:utimensat_fderr2  ->  passed  
[0.016s]
[192.168.10.2] out: lib/libc/c063/utimensat_test:utimensat_fderr3  ->  passed  
[0.050s]
[192.168.10.2] out: lib/libc/c063/utimensat_test:utimensat_fdlink  ->  passed  
[0.017s]
[192.168.10.2] out: lib/libc/db/db_hash_seq_test:test_hash_del_all  ->  passed  
[0.008s]
[192.168.10.2] out: lib/libc/db/db_hash_seq_test:test_hash_del_alt  ->  passed  
[0.024s]
[192.168.10.2] out: lib/libc/db/db_hash_seq_test:test_hash_del_every_7  ->  
passed  [0.009s]
[192.168.10.2] out: lib/libc/db/db_hash_seq_test:test_hash_del_none  ->  passed 
 [0.006s]
[192.168.10.2] out: lib/libc/db/db_test:alternate_recno  ->  passed  [0.184s]
[192.168.10.2] out: lib/libc/db/db_test:big_btree  ->  passed  [1.179s]
[192.168.10.2] out: lib/libc/db/db_test:big_hash  ->  passed  [2.628s]
[192.168.10.2] out: lib/libc/db/db_test:big_recno  ->  passed  [0.579s]
[192.168.10.2] out: lib/libc/db/db_test:bsize_ffactor  ->  passed  [7.749s]
[192.168.10.2] out: lib/libc/db/db_test:bsize_torture  ->  passed  [16.462s]
[192.168.10.2] out: lib/libc/db/db_test:byte_orders_btree  ->  passed  [0.208s]
[192.168.10.2] out: lib/libc/db/db_test:byte_orders_hash  ->  passed  [0.163s]
[192.168.10.2] out: lib/libc/db/db_test:cursor_flags_btree  ->  passed  [0.144s]
[192.168.10.2] out: lib/libc/db/db_test:cursor_flags_recno  ->  passed  [0.132s]
[192.168.10.2] out: lib/libc/db/db_test:delete_btree  ->  passed  [0.529s]
[192.168.10.2] out: lib/libc/db/db_test:delete_recno  ->  passed  [0.101s]
[192.168.10.2] out: lib/libc/db/db_test:duplicate_btree  ->  passed  [0.084s]
[192.168.10.2] out: lib/libc/db/db_test:four_char_hash  ->  passed  [0.092s]
[192.168.10.2] out: lib/libc/db/db_test:medium_btree  ->  passed  [0.082s]
[192.168.10.2] out: lib/libc/db/db_test:medium_hash  ->  passed  [0.076s]
[192.168.10.2] out: lib/libc/db/db_test:medium_recno  ->  passed  [0.070s]
[192.168.10.2] out: lib/libc/db/db_test:random_recno  ->  passed  [0.172s]
[192.168.10.2] out: lib/libc/db/db_test:repeated_btree  ->  passed  [0.054s]
[192.168.10.2] out: lib/libc/db/db_test:repeated_hash  ->  passed  [0.060s]
[192.168.10.2] out: lib/libc/db/db_test:reverse_order_recno  ->  passed  
[0.091s]
[192.168.10.2] out: lib/libc/db/db_test:reverse_recno  ->  passed  [0.109s]
[192.168.10.2] out: lib/libc/db/db_test:small_btree  ->  passed  [0.081s]
[192.168.10.2] out: lib/libc/db/db_test:small_hash  ->  passed  [0.074s]
[192.168.10.2] out: lib/libc/db/db_test:small_page_btree  ->  passed  [2.230s]
[192.168.10.2] out: lib/libc/db/db_test:small_recno  ->  passed  [0.079s]
[192.168.10.2] out: lib/libc/gen/arc4random_test:test_arc4random  ->  passed  
[0.007s]
[192.168.10.2] out: lib/libc/gen/fmtcheck2_test:fmtcheck_test  ->  passed  
[0.007s]
[192.168.10.2] out: lib/libc/gen/fmtmsg_test:fmtmsg_test  ->  passed  [0.020s]
[192.168.10.2] out: lib/libc/gen/fnmatch2_test:fnmatch_test  ->  passed  
[0.006s]
[192.168.10.2] out: lib/libc/gen/fpclassify2_test:test_fpclassify  ->  passed  
[0.007s]
[192.168.10.2] out: lib/libc/gen/ftw_test:ftw_test  ->  passed  [0.016s]
[192.168.10.2] out: lib/libc/gen/popen_test:popen_all_modes_test  ->  passed  
[0.017s]
[192.168.10.2] out: lib/libc/gen/popen_test:popen_rmodes_test  ->  passed  
[0.025s]
[192.168.10.2] out: lib/libc/gen/popen_test:popen_rwmodes_test  ->  passed  
[0.013s]
[192.168.10.2] out: lib/libc/gen/popen_test:popen_wmodes_test  ->  passed  
[0.097s]
[192.168.10.2] out: 
lib/libc/gen/posix_spawn_test:posix_spawn_no_such_command_negative_test  ->  
passed  [0.016s]
[192.168.10.2] out: lib/libc/gen/posix_spawn_test:posix_spawn_simple_test  ->  
passed  [0.008s]
[192.168.10.2] out: lib/libc/gen/wordexp_test:WRDE_APPEND_test  ->  passed  
[0.022s]
[192.168.10.2] out: lib/libc/gen/wordexp_test:WRDE_BADCHAR_test  ->  passed  
[0.014s]
[192.168.10.2] out: lib/libc/gen/wordexp_test:WRDE_DOOFFS__WRDE_APPEND_test  -> 
 passed  [0.013s]
[192.168.10.2] out: lib/libc/gen/wordexp_test:WRDE_DOOFFS_test  ->  passed  
[0.009s]
[192.168.10.2] out: lib/libc/gen/wordexp_test:WRDE_NOCMD_test  ->  passed  
[0.025s]
[192.168.10.2] out: lib/libc/gen/wordexp_test:WRDE_REUSE_test  ->  passed  
[0.011s]
[192.168.10.2] out: lib/libc/gen/wordexp_test:WRDE_SYNTAX_test  ->  passed  
[0.013s]
[192.168.10.2] out: lib/libc/gen/wordexp_test:WRDE_UNDEF_test  ->  passed  
[0.009s]
[192.168.10.2] out: lib/libc/gen/wordexp_test:long_output_test  ->  passed  
[0.019s]
[192.168.10.2] out: lib/libc/gen/wordexp_test:simple_test  ->  passed  [0.009s]
[192.168.10.2] out: lib/libc/gen/wordexp_test:with_SIGCHILD_handler_test  ->  
passed  [0.027s]
[192.168.10.2] out: lib/libc/gen/wordexp_test:with_unused_non_default_IFS_test  
->  passed  [0.009s]
[192.168.10.2] out: 

Re: Just a pair of no-urgency questions...

[Ronald Klop]

On Wed, 07 Sep 2016 13:52:48 +0200, Jeffrey Bouquet  
 wrote:


I check freshports.org and freshsource.org daily,  so I can read new  
features, UPDATING etc
without svn usage, and would have been maybe dealt problematic  
buildworlds etc without such.

...
Additionally, I learn the bits and pieces of developer skills, very  
slowly.


Not a developer here, ever, but for others and here convenience
...
1...   could freshports.org and freshsource.org be officially part of  
FreeBSD so their continued

existence is assured as the OS progresses?
2...  [the reason primary for this email]  It would be less distracting  
if while I browsed the
pages, a bar [set by cookies, probably] in a unique color, would notify  
me if I had read the
subsequent text, like a forum ' the posts by here are not net' line, and  
would save
time daily.  Can that be easily backported to each of the two sites???   
I'd even value that

to be an annual fee product I would pay for...
Not a webcoder, obviously...  out of time.

Thanks.



Hi, two tips.
1. Your subject does not reflect the content of your mail. It might not  
attract the right people to read it.
2. See http://www.freshports.org/contact.php and contact the site owner or  
use the Forums link there. In my experience Dan Langille is quite  
responsive.


NB: I also like this changelog site:  
http://www.secnetix.de/olli/FreeBSD/svnews/


Regards,
Ronald.
___
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_HEAD_i386 - Build #3873 - Fixed

[jenkins-admin]

FreeBSD_HEAD_i386 - Build #3873 - Fixed:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3873/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3873/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3873/console

Change summaries:

305520 by jhibbits:
Disable the qoriq errata fix for now

It hangs more often than it actually works it seems.  Further debugging is
needed to determine why, but for now the system needs to be able to boot.

305517 by jhibbits:
Allow pmap_early_io_unmap() to reclaim memory

pmap_early_io_map()/pmap_early_io_unmap(), if used in pairs, should be used in
the form:

pmap_early_io_map()
..do stuff..
pmap_early_io_unmap()

Without other allocations in the middle.  Without reclaiming memory this can
leave large holes in the device space.

While here, make a simple change to the unmap loop which now permits it to unmap
multiple TLB entries in the range.

___
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: kldload intpm

[John Baldwin]

On Wednesday, September 07, 2016 01:40:56 PM Andriy Gapon wrote:
> 
> Has kldload intpm ever worked?
> Ditto for other smbus drivers.
> 
> The reason I am asking is that it doesn't work for me on the latest head.
> And it doesn't work because device_probe_and_attach(sc->smbus) fails in
> intsmb_attach().
> 
> With a little help from DTrace I obtained the following output:
> CPU IDFUNCTION:NAME
>   0  41924devclass_add_driver:entry devclass = 0xf8000675b700, 
> name
> = pci, driver = 0x832ed058, name = intsmb
> 
>   0  32121 device_probe_child:entry
> parent = 0xf8000af78100, nameunit = intsmb0, devclass = 
> 0xf8001d955880,
> name = intsmb, driver = 0x0, name = 
> child = 0xf8001d933500, nameunit = smbus1, devclass = 0xf8001d955780,
> name = smbus
> 
>   kernel`device_probe+0x9d
>   kernel`device_probe_and_attach+0x2e
>   intpm.ko`intsmb_attach+0x651
>   kernel`device_attach+0x41d
>   kernel`pci_driver_added+0xed
>   kernel`devclass_driver_added+0x7d
>   kernel`devclass_add_driver+0x144
>   kernel`module_register_init+0xb0
>   kernel`linker_load_module+0xc88
>   kernel`kern_kldload+0xa7
>   kernel`sys_kldload+0x5b
>   kernel`amd64_syscall+0x2db
>   kernel`0x80e918ab
> 
>   1  41924devclass_add_driver:entry devclass = 0xf8001d955880, 
> name
> = intsmb, driver = 0x832ee930, name = smbus
> 
> My interpretation is that intsmb_attach() is called before the smbus driver is
> associated with the intsmb devclass.  That means that the devclass does not 
> have
> any drivers at all when intsmb_attach() calls device_probe_and_attach() on its
> smbus child.  It's too late when the smbus driver is added to the intsmb 
> devclass.
> 
> Okay, writing the above gave me an idea to try to change the order of
> DRIVER_MODULE() lines in intpm.c and that fixed the problem.
> 
> But I seem to recall that some years ago kldload intpm worked without the
> change.  Perhaps the order has changed in the module loading code.
> Anyway, this seems to be very subtle and error prone.  I wonder if we could 
> make
> it more robust.

You can request a specific ordering via DRIVER_MODULE_ORDERED (you can specify 
the
SI_ORDER to use as an extra argument).  The typical practice is to load the 
"base"
driver (the one that attaches highest up the device hierarchy) "last" so that 
all
other drivers are registered once it tries to attach.  For example, in xl(4) 
this
is used to to have the PCI attachment register last so that the miibus driver is
registered when xl0 attaches:

DRIVER_MODULE_ORDERED(xl, pci, xl_driver, xl_devclass, NULL, NULL,
SI_ORDER_ANY);
DRIVER_MODULE(miibus, xl, miibus_driver, miibus_devclass, NULL, NULL);

DRIVER_MODULE() uses SI_ORDER_MIDDLE by default.

This probably needs to be fixed in all of the smbus controller drivers.

-- 
John Baldwin
___
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"

Build failed in Jenkins: FreeBSD_HEAD #609

[jenkins-admin]

s]
[192.168.10.2] out: bin/pkill/pgrep-_g_test:main  ->  passed  [0.652s]
[192.168.10.2] out: bin/pkill/pgrep-_s_test:main  ->  passed  [0.440s]
[192.168.10.2] out: bin/pkill/pgrep-g_test:main  ->  passed  [0.706s]
[192.168.10.2] out: bin/pkill/pgrep-i_test:main  ->  passed  [0.337s]
[192.168.10.2] out: bin/pkill/pgrep-j_test:main  ->  passed  [8.364s]
[192.168.10.2] out: bin/pkill/pgrep-l_test:main  ->  passed  [0.364s]
[192.168.10.2] out: bin/pkill/pgrep-n_test:main  ->  passed  [0.346s]
[192.168.10.2] out: bin/pkill/pgrep-o_test:main  ->  passed  [0.344s]
[192.168.10.2] out: bin/pkill/pgrep-q_test:main  ->  passed  [0.369s]
[192.168.10.2] out: bin/pkill/pgrep-s_test:main  ->  passed  [0.786s]
[192.168.10.2] out: bin/pkill/pgrep-t_test:main  ->  passed  [0.337s]
[192.168.10.2] out: bin/pkill/pgrep-v_test:main  ->  passed  [0.351s]
[192.168.10.2] out: bin/pkill/pgrep-x_test:main  ->  passed  [0.363s]
[192.168.10.2] out: bin/pkill/pkill-F_test:main  ->  passed  [0.513s]
[192.168.10.2] out: bin/pkill/pkill-LF_test:main  ->  passed  [0.690s]
[192.168.10.2] out: bin/pkill/pkill-P_test:main  ->  passed  [0.342s]
[192.168.10.2] out: bin/pkill/pkill-U_test:main  ->  passed  [0.674s]
[192.168.10.2] out: bin/pkill/pkill-_g_test:main  ->  passed  [0.716s]
[192.168.10.2] out: bin/pkill/pkill-g_test:main  ->  passed  [0.955s]
[192.168.10.2] out: bin/pkill/pkill-i_test:main  ->  passed  [0.355s]
[192.168.10.2] out: bin/pkill/pkill-j_test:main  ->  passed  [20.651s]
[192.168.10.2] out: bin/pkill/pkill-s_test:main  ->  passed  [0.746s]
[192.168.10.2] out: bin/pkill/pkill-t_test:main  ->  passed  [1.019s]
[192.168.10.2] out: bin/pkill/pkill-x_test:main  ->  passed  [0.858s]
[192.168.10.2] out: bin/pax/legacy_test:main  ->  passed  [7.692s]
[192.168.10.2] out: 
[192.168.10.2] out: Results file id is usr_tests.20160907-024952-909906
[192.168.10.2] out: Results saved to 
/root/.kyua/store/results.usr_tests.20160907-024952-909906.db
[192.168.10.2] out: 
[192.168.10.2] out: 5852/5854 passed (2 failed)
[192.168.10.2] out: 

Warning: run() received nonzero return code 1 while executing 'kyua test'!


[192.168.10.2] run: kyua report --verbose --results-filter 
passed,skipped,xfail,broken,failed  --output test-report.txt
[192.168.10.2] run: kyua report-junit --output=test-report.xml
[192.168.10.2] run: shutdown -p now
[192.168.10.2] out: Shutdown NOW!
[192.168.10.2] out: shutdown: [pid 72226]
[192.168.10.2] out: 

kyuatestprompt # lock order reversal:
 1st 0xf80006d4fb78 ufs (ufs) @ 
/builds/workspace/FreeBSD_HEAD/src/sys/kern/vfs_mount.c:1244
 2nd 0xf80006d4e240 devfs (devfs) @ 
/builds/workspace/FreeBSD_HEAD/src/sys/kern/vfs_subr.c:2661
stack backtrace:
#0 0x80aacb80 at witness_debugger+0x70
#1 0x80aaca74 at witness_checkorder+0xe54
#2 0x80a24da2 at __lockmgr_args+0x4c2
#3 0x80afca4c at vop_stdlock+0x3c
#4 0x81025ab0 at VOP_LOCK1_APV+0xe0
#5 0x80b1db7a at _vn_lock+0x9a
#6 0x80b0e559 at vputx+0x169
#7 0x809e0368 at cd9660_unmount+0xb8
#8 0x80b065e4 at dounmount+0x6f4
#9 0x80b05e5d at sys_unmount+0x35d
#10 0x80ec2c6b at amd64_syscall+0x2db
#11 0x80ea235b at Xfast_syscall+0xfb
lock order reversal:
 1st 0xfe007b022648 bufwait (bufwait) @ 
/builds/workspace/FreeBSD_HEAD/src/sys/vm/vm_pager.c:378
 2nd 0xf80006d57d50 ufs (ufs) @ 
/builds/workspace/FreeBSD_HEAD/src/sys/dev/md/md.c:942
stack backtrace:
#0 0x80aacb80 at witness_debugger+0x70
#1 0x80aaca74 at witness_checkorder+0xe54
#2 0x80a24da2 at __lockmgr_args+0x4c2
#3 0x80d13166 at ffs_lock+0xa6
#4 0x81025ab0 at VOP_LOCK1_APV+0xe0
#5 0x80b1db7a at _vn_lock+0x9a
#6 0x80611749 at mdstart_vnode+0x4a9
#7 0x8060fced at md_kthread+0x18d
#8 0x80a10de4 at fork_exit+0x84
#9 0x80ea25ae at fork_trampoline+0xe
GEOM_CONCAT: Device concat.1kizqn created (id=3471647862).
GEOM_CONCAT: Disk md0 attached to concat.1kizqn.
GEOM_CONCAT: Disk md1 attached to concat.1kizqn.
GEOM_CONCAT: Disk md2 attached to concat.1kizqn.
GEOM_CONCAT: Device concat/concat.1kizqn activated.
GEOM_CONCAT: Disk md2 removed from concat.1kizqn.
GEOM_CONCAT: Device concat/concat.1kizqn deactivated.
GEOM_CONCAT: Disk md1 removed from concat.1kizqn.
GEOM_CONCAT: Disk md0 removed from concat.1kizqn.
GEOM_CONCAT: Device concat.1kizqn destr 
  

*** FINAL System shutdown message from root@ *** 



System going down IMMEDIATELY  



   

Sep  7 04:15:50  shutdown: power-down by root: 

Stopping cron.
Waiting for PIDS: 587.
Stopping sshd.
Waiting for PIDS: 552.
Stopping devd.
Waiting for PIDS: 286.
Writing entropy file:.
Writing early boot entropy file:.
.