FINAL CALL for 2017Q1 quarterly status reports

[Benjamin Kaduk]

Dear FreeBSD Community,

The deadline for the next FreeBSD Quarterly Status update is April 7,
2017, for work done in January through March.

Status report submissions do not need 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 work that is underway and
completed.  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 mont...@freebsd.org .
(Do be sure, though, to save the form output and not the form itself!)  There
is also an XML template [2] that 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.

Please let us know if you are interested in submitting an entry, but are
worried about being able to make the deadline.

We look forward to seeing your 2017Q1 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-07-2016-09.html
[5] https://www.FreeBSD.org/news/status/report-2016-10-2016-12.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"

Re: increased power consumption lately?

[Adrian Chadd]

hiya,

looks like yeah, you're going to have to do a bit more debugging. Can you
see what args are being passed to AcpiNsLookup() ?



-adrian


On 3 April 2017 at 03:24, Johannes Lundberg  wrote:

> Hi Adrian
>
> The three threads are kernel(acpi_task_{0-2}) and they use ~30% each so
> total 100% of one core.
>
> Machine is 2013 MBP
>
> pmcstat screenshot attached.
>
>
>
> On Thu, 30 Mar 2017 at 21:16, Adrian Chadd  wrote:
>
>> I don't /think/ so - which thread is it on your end? Can you run
>> pmcstat -S instructions -T to see what's taking your CPU?
>>
>>
>>
>> -adrian
>>
>>
>> On 28 March 2017 at 13:36, Johannes Lundberg  wrote:
>> > Hi
>> >
>> > Personally I got some acpi-something kernel thread at 100% CPU constant
>> > usage. Need to lock CPU freq at lower value otherwise it runs with
>> > turboboost all the time.
>> >
>> > Could it be the same for you?
>> >
>> > On Tue, 28 Mar 2017 at 20:58, Adrian Chadd  wrote:
>> >>
>> >> hiya,
>> >>
>> >> I've noticed that my battery life on my haswell laptop (T540p) seems
>> >> to have taken a nosedive lately. I could've /sworn/ it was getting
>> >> better than 15-16W at idle.
>> >>
>> >> Has anyone noticed any massive decrease in battery life lately?
>> >>
>> >>
>> >>
>> >> -adrian
>> >> ___
>> >> 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"

Re: bt full - included... kgdb 'script' output vmcore.8

[John Baldwin]

On Saturday, March 25, 2017 01:24:06 PM Jeffrey Bouquet wrote:
> I asked the var to bt full
> it laid the symbols down
> I asked it current, list, the cymbals.
> not newly newbie, clown
> 
> And xclip pasted, below, the rhyme
> the symbollish list stuff
> And I send it off to list-wise men
> to make Xorg not so gruff.
> 
> ...
> ...
> 
> 
> Script started on Sat Mar 25 13:11:34 2017
> Command: kgdb7121 /boot/test/kernel /var/crash/VMCORE.8
> GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD]
> Copyright (C) 2017 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i386-portbld-freebsd12.0".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /boot/test/kernel...Reading symbols from 
> /usr/lib/debug//boot/test/kernel.debug...done.
> done.
> 
> Unread portion of the kernel message buffer:
> Waiting (max 60 seconds) for system process `vnlru' to stop... done
> Waiting (max 60 seconds) for system process `bufdaemon' to stop... done
> Waiting (max 60 seconds) for system process `syncer' to stop... 
> Syncing disks, vnodes remaining... 5 1 0 0 done
> All buffers synced.
> lock order reversal:
>  1st 0xbf8ce26c ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1277
>  2nd 0xbfb90150 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2762
> stack backtrace:
> #0 0xb5c22421 at witness_debugger+0x81
> #1 0xb5c22342 at witness_checkorder+0xd12
> #2 0xb5b9b5d4 at __lockmgr_args+0xa64
> #3 0xb5c784ad at vop_stdlock+0x4d
> #4 0xb618e7f7 at VOP_LOCK1_APV+0xd7
> #5 0xb5c9c137 at _vn_lock+0xb7
> #6 0xb5c8b00a at vputx+0x16a
> #7 0xb5c8286c at dounmount+0x5dc
> #8 0xb5c8c8e8 at vfs_unmountall+0x68
> #9 0xb5c68333 at bufshutdown+0x3f3
> #10 0xb5bbfca7 at kern_reboot+0x1b7
> #11 0xb5bbfa88 at sys_reboot+0x3e8
> #12 0xb6155fa5 at syscall+0x3b5
> #13 0xb6140ede at Xint0x80_syscall+0x2e
> lock order reversal:
>  1st 0xbf8ce26c ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1277
>  2nd 0xbfa28034 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1404
> stack backtrace:
> #0 0xb5c22421 at witness_debugger+0x81
> #1 0xb5c22342 at witness_checkorder+0xd12
> #2 0xb5b9b5d4 at __lockmgr_args+0xa64
> #3 0xb5c784ad at vop_stdlock+0x4d
> #4 0xb618e7f7 at VOP_LOCK1_APV+0xd7
> #5 0xb5c9c137 at _vn_lock+0xb7
> #6 0xb5eb9617 at ffs_flushfiles+0x157
> #7 0xb5e9d9aa at softdep_flushfiles+0x17a
> #8 0xb5ebc04c at ffs_unmount+0x7c
> #9 0xb5c8299b at dounmount+0x70b
> #10 0xb5c8c8e8 at vfs_unmountall+0x68
> #11 0xb5c68333 at bufshutdown+0x3f3
> #12 0xb5bbfca7 at kern_reboot+0x1b7
> #13 0xb5bbfa88 at sys_reboot+0x3e8
> #14 0xb6155fa5 at syscall+0x3b5
> #15 0xb6140ede at Xint0x80_syscall+0x2e
> lock order reversal:
>  1st 0xbf69ab4c ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1277
>  2nd 0xb6b6f8b0 allproc (allproc) @ /usr/src/sys/kern/kern_descrip.c:3104
> stack backtrace:
> #0 0xb5c22421 at witness_debugger+0x81
> #1 0xb5c22342 at witness_checkorder+0xd12
> #2 0xb5bc976a at _sx_slock+0x5a
> #3 0xb5b743f1 at mountcheckdirs+0x41
> #4 0xb5c828ea at dounmount+0x65a
> #5 0xb5c8c93b at vfs_unmountall+0xbb
> #6 0xb5c68333 at bufshutdown+0x3f3
> #7 0xb5bbfca7 at kern_reboot+0x1b7
> #8 0xb5bbfa88 at sys_reboot+0x3e8
> #9 0xb6155fa5 at syscall+0x3b5
> #10 0xb6140ede at Xint0x80_syscall+0x2e
> Uptime: 3h49m18s
> GEOM_SCHED: Modevent 2.
> uhub11: detached
> uhub9: detached
> uhub10: detached
> ums0: detached
> <5>ue0: link state changed to DOWN
> <5>Accounting disabled
> panic: vm_fault: fault on nofault entry, addr: deadc000
> cpuid = 2
> KDB: stack backtrace:
> db_trace_self_wrapper(b632dee0,b65ec9b0,0,b63057cc,20c,...) at 
> db_trace_self_wrapper+0x2a/frame 0xeaa10428
> kdb_backtrace(b653d063,2,b6378ae5,eaa104e4,fb,...) at 
> kdb_backtrace+0x2d/frame 0xeaa10490
> vpanic(b6378ae5,eaa104e4,eaa104e4,eaa105c0,b5edffb1,...) at 
> vpanic+0x115/frame 0xeaa104c4
> panic(b6378ae5,deadc000,1,eaa1052c,eaa1051c,...) at panic+0x1b/frame 
> 0xeaa104d8
> vm_fault_hold(b8172000,deadc000,1,0,0,...) at vm_fault_hold+0x2051/frame 
> 0xeaa105c0
> vm_fault(b8172000,deadc000,1,0,c2d0bfa8,...) at vm_fault+0x88/frame 0xeaa105e8
> trap_pfault(deadc348,b6ae70ec,b6600504,bdda8d00,b6ae70f0,...) at 
> trap_pfault+0x116/frame 0xeaa10630
> trap(eaa10778) at trap+0x2d6/frame 0xeaa1076c
> calltrap() at calltrap+0x6/frame 0xeaa1076c
> --- trap 0xc, eip = 0xb5bbaf19, esp = 0xeaa107b8, ebp = 0xeaa10828 ---
> 

Re: r315684 panic: sleepq_add: td 0xfffff80003c01a40 to sleep on wchan 0xfffff80006f0873c with sleeping prohibited

[Gleb Smirnoff]

On Mon, Apr 03, 2017 at 03:39:56PM +, Darren wrote:
D> I have not experienced the crash after updating with Glebs patch. Consider 
the issue solved. 

I really don't want to put ACCEPT_LOCK() on to the sendfile() path.

However, once I commit my listening sockets rewrite patch, there
will be no ACCEPT_LOCK(). I'll see how it goes. Will be fixed in
next month.

-- 
Totus tuus, Glebius.
___
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"