Re: kern.sched.quantum: Creepy, sadistic scheduler

2018-04-17 Thread George Mitchell 
On 04/17/18 17:20, EBFE via freebsd-stable wrote:
> On Tue, 17 Apr 2018 09:05:48 -0700
> Freddie Cash  wrote:
> 
>> # Tune for desktop usage
>> kern.sched.preempt_thresh=224
>>
>> ​Works quite nicely on a 4-core AMD Phenom-II X4 960T Processor
>> (3010.09-MHz K8-class CPU) running KDE4 using an Nvidia 210 GPU.
> 
> For interactive tasks, there is a "special" tunable:
> % sysctl kern.sched.interact
> kern.sched.interact: 10 # default is 30
> % sysctl -d kern.sched.interact
> kern.sched.interact: Interactivity score threshold
> 
> reducing the value from 30 to 10-15 keeps your gui/system responsive,
> even under high load.
> [...]

I suspect my case (make buildworld while running misc/dnetc) doesn't
qualify.  However, I just completed a SCHED_ULE run with
preempt_thresh set to 5, and "time make buildworld" reports:
7336.748u 677.085s 9:25:19.86 23.6% 27482+473k 42147+431581io 38010pf+0w
Much closer to SCHED_4BSD!  I'll try preempt_thresh=0 next, and I
guess I'll at least try preempt_thresh=224 to see how that works
for me. -- George



signature.asc
Description: OpenPGP digital signature

Re: kern.sched.quantum: Creepy, sadistic scheduler

2018-04-17 Thread EBFE via freebsd-stable 
On Tue, 17 Apr 2018 09:05:48 -0700
Freddie Cash  wrote:

> # Tune for desktop usage
> kern.sched.preempt_thresh=224
> 
> ​Works quite nicely on a 4-core AMD Phenom-II X4 960T Processor
> (3010.09-MHz K8-class CPU) running KDE4 using an Nvidia 210 GPU.

For interactive tasks, there is a "special" tunable:
% sysctl kern.sched.interact
kern.sched.interact: 10 # default is 30
% sysctl -d kern.sched.interact
kern.sched.interact: Interactivity score threshold

reducing the value from 30 to 10-15 keeps your gui/system responsive,
even under high load.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: kern.sched.quantum: Creepy, sadistic scheduler

2018-04-17 Thread Freddie Cash 
On Tue, Apr 17, 2018 at 8:49 AM, Kevin Oberman  wrote:

> On Mon, Apr 16, 2018 at 11:56 PM, Eivind Nicolay Evensen <
> eivi...@terraplane.org> wrote:
>
> > On Wed, Apr 04, 2018 at 09:32:58AM -0400, George Mitchell wrote:
> > > On 04/04/18 06:39, Alban Hertroys wrote:
> > > > [...]
> > > > That said, SCHED_ULE (the default scheduler for quite a while now)
> was
> > designed with multi-CPU configurations in mind and there are claims that
> > SCHED_4BSD works better for single-CPU configurations. You may give that
> a
> > try, if you're not already on SCHED_4BSD.
> > > > [...]
> > >
> > > A small, disgruntled community of FreeBSD users who have never seen
> > > proof that SCHED_ULE is better than SCHED_4BSD in any environment
> > > continue to regularly recompile with SCHED_4BSD.  I dread the day when
> > > that becomes impossible, but at least it isn't here yet.  -- George
> >
> > Indeed 4bsd is better in my case aswell. While for some unknown to me
> > reason ule performed a bit better in the 10.x series than before, in 11.x
> > it again is in my case not usable.
> >
> > Mouse freezes for around half a second with even frequency by just moving
> > it around in x11. Using 4bsd instead makes the problem go away.
> > I'm actually very happy that ule became worse again because going
> > back to 4bsd yet again also gave improved performance from other
> > dreadfully slow but (to me) still useful programs, like darktable.
> >
> > With 4bsd, when adjusting shadows and highlights it is possible to see
> > what I do when moving sliders. With ule it has never been better than
> waiting
> > 10-20-30 seconds to see where it was able to read a slider position
> > and update display, when working on images around 10500x10500 greyscale.
> >
> > It's not single cpu/single core either:
> > CPU: AMD FX(tm)-6300 Six-Core Processor  (3817.45-MHz
> K8-class
> > CPU)
>
> My experience has long been that 4BSD works far better for interactive, X
> based systems than ULE. Even on 10 I saw long, annoying pauses with ULE and
> I don't se those with 4BSD. I'd really like to see it better known that
> this is often the case. BTW, my system is 2 core/4 thread Sandybridge.
> ​
>

​The following has been suggested multiple times over the years on various
mailing lists as the "solution" to making ULE work well for interactive
tasks like running X-based desktops (in /etc/sysctl.conf):​

# Tune for desktop usage
kern.sched.preempt_thresh=224

​Works quite nicely on a 4-core AMD Phenom-II X4 960T Processor
(3010.09-MHz K8-class CPU) running KDE4 using an Nvidia 210 GPU.

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: amd64 kernel crash introduced between 20180329 & 20180408

2018-04-17 Thread Dan Allen 


> On 17 Apr 2018, at 9:24 AM, Kyle Evans  wrote:
> 
> Can you set vm.pmap.pti=0 at the loader prompt and see if
> this affects your situation at all, just to rule that out?

I redid everything from the start, did set vm.pmap.pti=0, and it behaves 
exactly the same: kernel panic.

Thanks for your help!

Do I have any other takers?  ;-)

Dan

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

Re: kern.sched.quantum: Creepy, sadistic scheduler

2018-04-17 Thread Kevin Oberman 
On Mon, Apr 16, 2018 at 11:56 PM, Eivind Nicolay Evensen <
eivi...@terraplane.org> wrote:

> On Wed, Apr 04, 2018 at 09:32:58AM -0400, George Mitchell wrote:
> > On 04/04/18 06:39, Alban Hertroys wrote:
> > > [...]
> > > That said, SCHED_ULE (the default scheduler for quite a while now) was
> designed with multi-CPU configurations in mind and there are claims that
> SCHED_4BSD works better for single-CPU configurations. You may give that a
> try, if you're not already on SCHED_4BSD.
> > > [...]
> >
> > A small, disgruntled community of FreeBSD users who have never seen
> > proof that SCHED_ULE is better than SCHED_4BSD in any environment
> > continue to regularly recompile with SCHED_4BSD.  I dread the day when
> > that becomes impossible, but at least it isn't here yet.  -- George
>
> Indeed 4bsd is better in my case aswell. While for some unknown to me
> reason
> ule performed a bit better in the 10.x series than before, in 11.x
> it again is in my case not usable.
>
> Mouse freezes for around half a second with even frequency by just moving
> it around in x11. Using 4bsd instead makes the problem go away.
> I'm actually very happy that ule became worse again because going
> back to 4bsd yet again also gave improved performance from other
> dreadfully slow but (to me) still useful programs, like darktable.
>
> With 4bsd, when adjusting shadows and highlights it is possible to see
> what I
> do when moving sliders. With ule it has never been better than waiting
> 10-20-30 seconds to see where it was able to read a slider position
> and update display, when working on images around 10500x10500 greyscale.
>
> It's not single cpu/single core either:
> CPU: AMD FX(tm)-6300 Six-Core Processor  (3817.45-MHz K8-class
> CPU)
>
>
>
>
> --
> Eivind
>

My experience has long been that 4BSD works far better for interactive, X
based systems than ULE. Even on 10 I saw long, annoying pauses with ULE and
I don't se those with 4BSD. I'd really like to see it better known that
this is often the case. BTW, my system is 2 core/4 thread Sandybridge.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: amd64 kernel crash introduced between 20180329 & 20180408

2018-04-17 Thread Kyle Evans 
On Tue, Apr 17, 2018 at 10:18 AM, Dan Allen  wrote:
>
>
>> On 17 Apr 2018, at 8:49 AM, Kyle Evans  wrote:
>>
>> As "the guy most likely to have broken boot code in stable," may I ask
>> what leads you specifically to amd64 boot code? Mostly curious if
>> there's something beyond "i386 works well" that lead you to this
>> conclusion.
>
> It is partly just a hunch.
>
> I installed 11.0 for use with qemu a while ago.  I did binary upgrades for 
> patches using
> freebsd-update.  When 11.1 came out, it would not work correctly, again with 
> the same
> kind of behavior.  Then, I got some later snapshots that worked again, 
> notably the 20180329
> build.  When the next snapshot came out, things broke.  I also tried my own 
> builds, same story.
>
> I even got both source trees together - 20180329 and 20180408 - and did a 
> diff on the entire
> trees, and I noticed activity in the boot & kernel code.  It could just as 
> likely be something in the
> kernel as well, but none of this happens with the i386 build.
>
>> When you say it crashes and does a kernel dump- you're landing at a
>> ddb prompt, yeah? What does executing bt at that prompt look like?
>
> No, I am not ever given a prompt.  I get to watch a mini-dump happen and then 
> an automatic
> reboot.  It is a kernel panic.  Here is what I see:
>

Ahh, fun. =)

I'm inclined to think it's probably not a boot code problem, but it is
suspicious. Can you set vm.pmap.pti=0 at the loader prompt and see if
this affects your situation at all, just to rule that out?
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: amd64 kernel crash introduced between 20180329 & 20180408

2018-04-17 Thread Dan Allen 


> On 17 Apr 2018, at 8:49 AM, Kyle Evans  wrote:
> 
> As "the guy most likely to have broken boot code in stable," may I ask
> what leads you specifically to amd64 boot code? Mostly curious if
> there's something beyond "i386 works well" that lead you to this
> conclusion.

It is partly just a hunch.

I installed 11.0 for use with qemu a while ago.  I did binary upgrades for 
patches using
freebsd-update.  When 11.1 came out, it would not work correctly, again with 
the same
kind of behavior.  Then, I got some later snapshots that worked again, notably 
the 20180329
build.  When the next snapshot came out, things broke.  I also tried my own 
builds, same story.

I even got both source trees together - 20180329 and 20180408 - and did a diff 
on the entire
trees, and I noticed activity in the boot & kernel code.  It could just as 
likely be something in the
kernel as well, but none of this happens with the i386 build.

> When you say it crashes and does a kernel dump- you're landing at a
> ddb prompt, yeah? What does executing bt at that prompt look like?

No, I am not ever given a prompt.  I get to watch a mini-dump happen and then 
an automatic
reboot.  It is a kernel panic.  Here is what I see:

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

Re: amd64 kernel crash introduced between 20180329 & 20180408

2018-04-17 Thread Kyle Evans 
On Tue, Apr 17, 2018 at 9:44 AM, Dan Allen  wrote:
> I run FreeBSD 11-STABLE on actual machines, and I build the system every few 
> days.  Things have been fine.
>
> However, I also run FreeBSD 11 via the qemu emulator on my Mac.  I run lots 
> of different BSD & Linux OSes here to test them out.  I have been running the 
> same binary of qemu-system-x86_64 v1.2 for six years.  It runs great.
>
> Then recently this happened:
>
> This snapshot dated 20180329, after doing a fresh install, runs fine:
>
>   
> https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/11.1/FreeBSD-11.1-STABLE-amd64-20180329-r331742-disc1.iso
>
> I can run pkg install and begin adding stuff to the system and life is good.
>
> BUT
>
> This snapshot dated 20180408, after doing a fresh install, will crash when 
> running pkg install:
>
>   
> https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/11.1/FreeBSD-11.1-STABLE-amd64-20180408-r332308-disc1.iso
>
> It crashes about 90% of the way through updating the pkg snapshot.  It does 
> not matter what pkg you try and install.
>
> However, the latest release in the i386 flavor works fine on qemu:
>
>   
> https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/11.1/FreeBSD-11.1-STABLE-i386-20180412-r332428-disc1.iso
>
> So sometime between March 29th & April 8th, in amd64 boot code, I believe the 
> problem was introduced.

As "the guy most likely to have broken boot code in stable," may I ask
what leads you specifically to amd64 boot code? Mostly curious if
there's something beyond "i386 works well" that lead you to this
conclusion.

> I cannot debug the crash, because it does a kernel dump, and then when the 
> system reboots, almost anything again triggers a kernel crash and it reboots 
> again and again: no chance to inspect a mini dump or whatever.

When you say it crashes and does a kernel dump- you're landing at a
ddb prompt, yeah? What does executing bt at that prompt look like>?

> I wish I had more to go on, but I am happy to off list work with anyone that 
> wants to pursue this, by testing out stuff or answering more questions.
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

amd64 kernel crash introduced between 20180329 & 20180408

2018-04-17 Thread Dan Allen 
I run FreeBSD 11-STABLE on actual machines, and I build the system every few 
days.  Things have been fine.

However, I also run FreeBSD 11 via the qemu emulator on my Mac.  I run lots of 
different BSD & Linux OSes here to test them out.  I have been running the same 
binary of qemu-system-x86_64 v1.2 for six years.  It runs great.

Then recently this happened:

This snapshot dated 20180329, after doing a fresh install, runs fine:

  
https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/11.1/FreeBSD-11.1-STABLE-amd64-20180329-r331742-disc1.iso

I can run pkg install and begin adding stuff to the system and life is good.

BUT

This snapshot dated 20180408, after doing a fresh install, will crash when 
running pkg install:

  
https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/11.1/FreeBSD-11.1-STABLE-amd64-20180408-r332308-disc1.iso

It crashes about 90% of the way through updating the pkg snapshot.  It does not 
matter what pkg you try and install.

However, the latest release in the i386 flavor works fine on qemu:

  
https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/11.1/FreeBSD-11.1-STABLE-i386-20180412-r332428-disc1.iso

So sometime between March 29th & April 8th, in amd64 boot code, I believe the 
problem was introduced.

I cannot debug the crash, because it does a kernel dump, and then when the 
system reboots, almost anything again triggers a kernel crash and it reboots 
again and again: no chance to inspect a mini dump or whatever.

I wish I had more to go on, but I am happy to off list work with anyone that 
wants to pursue this, by testing out stuff or answering more questions.

Dan Allen
Running FreeBSD since 2.2.8
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

CentOs Competitors Users Contact List.

2018-04-17 Thread gemma . white 
style="color:rgb(31,78,121)">Hello,


Would you
be interested in CentOS (Linux) Users
List? We are a Global Technology User’s List Provider’s with 90 Million
Plus data and counting.

You may  
also acquire the
alternatives such as: Windows  
Server users List, Oracle Linux users List, style="color:rgb(31,78,121)">Ubuntu

Linux users List, Suse Linux users List, Oracle Solaris users List and many
more.

List
Contains: Name,
Companys Name, Phone Number, Fax Number, Job Title, Email address,  
Complete

Mailing Address, SIC code, Company revenue, size, Web address etc. All
Technology / Companies Partners and Users List, IT decision Makers from  
Fortune

500 Companies, IT Decision Makers from SME as well.

style="margin-bottom:0.0001pt;line-height:normal">style="color:rgb(31,78,121)">We provide data across the globe - North  
America, EMEA, Asia Pacific and LATAM.


Please let
us know your targeted criteria and geography to provide you with detailed
information for your review.

Let me
know your thoughts!

style="color:rgb(31,78,121)">Thanks,


Gemma  
White


Senior  
Database Executive


style="color:rgb(31,78,121)"> 

To “opt
out” response not interestedstyle="color:rgb(31,78,121)">
powered by GSM. Free mail merge and  
email marketing software for Gmail.

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

more data: SCHED_ULE+PREEMPTION is the problem

2018-04-17 Thread George Mitchell 
On 04/07/18 10:18, Peter wrote:
> Hi all,
> [...]
Thanks for all the investigation!
> 3. kern.sched.preempt_thresh
> 
> I could make the problem disappear by changing kern.sched.preempt_thresh
>  from the default 80 to either 11 (i5-3570T) or 7 (p3) or smaller. This
> seems to correspond to the disk interrupt threads, which run at intr:12
> (i5-3570T) or intr:8 (p3).
> [...]

More data.  With SCHED_4BSD at FreeBSD 10.4-RELEASE-p8 #0 r331984:
kern.sched.runq_fuzz: 1
kern.sched.ipiwakeup.useloop: 0
kern.sched.ipiwakeup.usemask: 1
kern.sched.ipiwakeup.delivered: 376139898
kern.sched.ipiwakeup.requested: 376137875
kern.sched.ipiwakeup.enabled: 1
kern.sched.slice: 12
kern.sched.quantum: 94488
kern.sched.name: 4BSD
kern.sched.preemption: 1
kern.sched.cpusetsize: 8
With dnetc running on a 6-core AMD CPU from a few years back,
"time make buildworld" yields:

6640.224u 828.874s 2:14:37.73 92.4% 28525+494k 31633+431554io 33192pf+0w

I shifted to a GENERIC kernel, FreeBSD 10.4-RELEASE-p8 #0 r332560:
kern.sched.topology_spec: 
 
  0, 1, 2, 3, 4, 5
  
   
0, 1, 2, 3, 4, 5
   
  
 


kern.sched.steal_thresh: 2
kern.sched.steal_idle: 1
kern.sched.balance_interval: 127
kern.sched.balance: 1
kern.sched.affinity: 1
kern.sched.idlespinthresh: 157
kern.sched.idlespins: 1
kern.sched.static_boost: 152
kern.sched.preempt_thresh: 80
kern.sched.interact: 30
kern.sched.slice: 12
kern.sched.quantum: 94488
kern.sched.name: ULE
kern.sched.preemption: 1
kern.sched.cpusetsize: 8

I stupidly typed "make buildworld" without the "time" command, but the
build log started at Mon Apr 16 13:49:12 EDT 2018 and completed at
Tue Apr 17 00:22:23 EDT 2018.  You read that right: 2+ hours vs 10 1/2!
So I set "sysctl kern.sched.preempt_thresh=5" (a wild guess on my part)
and started another "time make buildworld".  It's still going now, but
subjectively it's still running like molasses.  I'll post more results
later after trying sysctl kern.sched.preempt_thresh=0.

By the way, over the years that this discussion has been going on, I've
*never* had a response to my question: "What is the workload for which
SCHED_ULE outperforms SCHED_4BSD?"-- George




signature.asc
Description: OpenPGP digital signature

11.1 stable r321309 loader.efi boot faile

2018-04-17 Thread 吴叔坤 

>> freebsd 11.1 stable r321309 boot failed 
>> loader.efi recognize efipart as new disk on MacBook pro mid 2015
>> 
>> 
>> 
>> 
> 
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: stable/11 r332356 started panicing in bpf_dtor/__mtx_lock_sleep

2018-04-17 Thread Eugene Grosbein 
On 17.04.2018 16:30, Eugene Grosbein wrote:

CCing mjoras@ as author of suspicious change 
https://svnweb.freebsd.org/base?view=revision=323477

> I have a server that was running stable/11 rock-stable for many months.

It was running stable/11 r314043 before last update.

> A week ago I've updates it to 11.1-STABLE r332356 and today it paniced and I 
> have crashdump.
> Any thoughts?
> 
> Unread portion of the kernel message buffer:
> Sleeping thread (tid 100444, pid 28400) owns a non-sleepable lock
> KDB: stack backtrace of thread 100444:
> sched_switch() at sched_switch+0x626/frame 0xfe03550f9740
> mi_switch() at mi_switch+0xc5/frame 0xfe03550f9770
> sleepq_wait() at sleepq_wait+0x2c/frame 0xfe03550f97a0
> _sx_xlock_hard() at _sx_xlock_hard+0x2f0/frame 0xfe03550f9830
> vlan_ioctl() at vlan_ioctl+0x53f/frame 0xfe03550f98b0
> ifpromisc() at ifpromisc+0x106/frame 0xfe03550f9910
> bpf_detachd_locked() at bpf_detachd_locked+0x1b4/frame 0xfe03550f9960
> bpf_dtor() at bpf_dtor+0x9a/frame 0xfe03550f9990
> devfs_fpdrop() at devfs_fpdrop+0x9c/frame 0xfe03550f99b0
> devfs_close_f() at devfs_close_f+0x45/frame 0xfe03550f99e0
> closef() at closef+0x209/frame 0xfe03550f9a70
> closefp() at closefp+0x8b/frame 0xfe03550f9ab0
> amd64_syscall() at amd64_syscall+0x25c/frame 0xfe03550f9bf0
> fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe03550f9bf0
> --- syscall (6, FreeBSD ELF64, sys_close), rip = 0x4a317a, rsp = 
> 0x7fffe3d8, rbp = 0x7fffe3f0 ---
> panic: sleeping thread
> cpuid = 1
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0354c6d7c0
> vpanic() at vpanic+0x177/frame 0xfe0354c6d820
> panic() at panic+0x43/frame 0xfe0354c6d880
> propagate_priority() at propagate_priority+0x183/frame 0xfe0354c6d8b0
> turnstile_wait() at turnstile_wait+0x2bc/frame 0xfe0354c6d900
> __mtx_lock_sleep() at __mtx_lock_sleep+0x151/frame 0xfe0354c6d960
> bpf_dtor() at bpf_dtor+0x191/frame 0xfe0354c6d990
> devfs_fpdrop() at devfs_fpdrop+0x9c/frame 0xfe0354c6d9b0
> devfs_close_f() at devfs_close_f+0x45/frame 0xfe0354c6d9e0
> closef() at closef+0x209/frame 0xfe0354c6da70
> closefp() at closefp+0x8b/frame 0xfe0354c6dab0
> amd64_syscall() at amd64_syscall+0x25c/frame 0xfe0354c6dbf0
> fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe0354c6dbf0
> --- syscall (6, FreeBSD ELF64, sys_close), rip = 0x4a317a, rsp = 
> 0x7fffe3d8, rbp = 0x7fffe3f0 ---
> Uptime: 6d2h0m17s
> Dumping 1414 out of 12265 MB:..2%..11%..21%..31%..41%..51%..62%..71%..81%..91%
> 
> 
> (kgdb) bt
> #0  doadump (textdump=1) at pcpu.h:229
> #1  0x804f3b9a in kern_reboot (howto=260) at 
> /usr/local/src/sys/kern/kern_shutdown.c:383
> #2  0x804f3f81 in vpanic (fmt=, ap= optimized out>)
> at /usr/local/src/sys/kern/kern_shutdown.c:776
> #3  0x804f3dc3 in panic (fmt=) at 
> /usr/local/src/sys/kern/kern_shutdown.c:707
> #4  0x80546b33 in propagate_priority (td=) at 
> /usr/local/src/sys/kern/subr_turnstile.c:226
> #5  0x8054720c in turnstile_wait (ts=0xf80151ac4180, owner= optimized out>, queue=)
> at /usr/local/src/sys/kern/subr_turnstile.c:742
> #6  0x804dda81 in __mtx_lock_sleep (c=0x80c9c910, v= optimized out>)
> at /usr/local/src/sys/kern/kern_mutex.c:627
> #7  0x805cd061 in bpf_dtor (data=0xf801512df800) at 
> /usr/local/src/sys/net/bpf.c:778
> #8  0x80455e5c in devfs_fpdrop (fp=) at 
> /usr/local/src/sys/fs/devfs/devfs_vnops.c:193
> #9  0x804595d5 in devfs_close_f (fp=0xf802af2fe6e0, td= optimized out>)
> at /usr/local/src/sys/fs/devfs/devfs_vnops.c:675
> #10 0x804b1549 in closef (fp=0xf802af2fe6e0, 
> td=0xf8000cf75000) at file.h:346
> #11 0x804af00b in closefp (fdp=0xf80083b48000, fd= optimized out>, fp=0xf802af2fe6e0,
> td=0xf8000cf75000, holdleaders=0) at 
> /usr/local/src/sys/kern/kern_descrip.c:1191
> #12 0x807afb6c in amd64_syscall (td=0xf8000cf75000, traced=0) at 
> subr_syscall.c:132
> #13 0x80791c3d in fast_syscall_common () at 
> /usr/local/src/sys/amd64/amd64/exception.S:480
> #14 0x004a317a in ?? ()
> Previous frame inner to this frame (corrupt stack?)

Some more details: this monitoring server has many vlans over em1.

It runs some custom perl code utilizing Net::Pcap over bpf.
Many times per minute it opens/closes bpf to send/receive custom PPPoE frames
using vlans (sends over multiple if_vlan and receives using their parent em1).

This server also multiple times per minute starts and stops receiving IPTV 
multicast traffic
using another em0 interface as part of another monitoring job.

Again, r314043 was pretty stable.

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

stable/11 r332356 started panicing in bpf_dtor/__mtx_lock_sleep

2018-04-17 Thread Eugene Grosbein 
Hi!

I have a server that was running stable/11 rock-stable for many months.
A week ago I've updates it to 11.1-STABLE r332356 and today it paniced and I 
have crashdump.
Any thoughts?

Unread portion of the kernel message buffer:
Sleeping thread (tid 100444, pid 28400) owns a non-sleepable lock
KDB: stack backtrace of thread 100444:
sched_switch() at sched_switch+0x626/frame 0xfe03550f9740
mi_switch() at mi_switch+0xc5/frame 0xfe03550f9770
sleepq_wait() at sleepq_wait+0x2c/frame 0xfe03550f97a0
_sx_xlock_hard() at _sx_xlock_hard+0x2f0/frame 0xfe03550f9830
vlan_ioctl() at vlan_ioctl+0x53f/frame 0xfe03550f98b0
ifpromisc() at ifpromisc+0x106/frame 0xfe03550f9910
bpf_detachd_locked() at bpf_detachd_locked+0x1b4/frame 0xfe03550f9960
bpf_dtor() at bpf_dtor+0x9a/frame 0xfe03550f9990
devfs_fpdrop() at devfs_fpdrop+0x9c/frame 0xfe03550f99b0
devfs_close_f() at devfs_close_f+0x45/frame 0xfe03550f99e0
closef() at closef+0x209/frame 0xfe03550f9a70
closefp() at closefp+0x8b/frame 0xfe03550f9ab0
amd64_syscall() at amd64_syscall+0x25c/frame 0xfe03550f9bf0
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe03550f9bf0
--- syscall (6, FreeBSD ELF64, sys_close), rip = 0x4a317a, rsp = 
0x7fffe3d8, rbp = 0x7fffe3f0 ---
panic: sleeping thread
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0354c6d7c0
vpanic() at vpanic+0x177/frame 0xfe0354c6d820
panic() at panic+0x43/frame 0xfe0354c6d880
propagate_priority() at propagate_priority+0x183/frame 0xfe0354c6d8b0
turnstile_wait() at turnstile_wait+0x2bc/frame 0xfe0354c6d900
__mtx_lock_sleep() at __mtx_lock_sleep+0x151/frame 0xfe0354c6d960
bpf_dtor() at bpf_dtor+0x191/frame 0xfe0354c6d990
devfs_fpdrop() at devfs_fpdrop+0x9c/frame 0xfe0354c6d9b0
devfs_close_f() at devfs_close_f+0x45/frame 0xfe0354c6d9e0
closef() at closef+0x209/frame 0xfe0354c6da70
closefp() at closefp+0x8b/frame 0xfe0354c6dab0
amd64_syscall() at amd64_syscall+0x25c/frame 0xfe0354c6dbf0
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe0354c6dbf0
--- syscall (6, FreeBSD ELF64, sys_close), rip = 0x4a317a, rsp = 
0x7fffe3d8, rbp = 0x7fffe3f0 ---
Uptime: 6d2h0m17s
Dumping 1414 out of 12265 MB:..2%..11%..21%..31%..41%..51%..62%..71%..81%..91%


(kgdb) bt
#0  doadump (textdump=1) at pcpu.h:229
#1  0x804f3b9a in kern_reboot (howto=260) at 
/usr/local/src/sys/kern/kern_shutdown.c:383
#2  0x804f3f81 in vpanic (fmt=, ap=)
at /usr/local/src/sys/kern/kern_shutdown.c:776
#3  0x804f3dc3 in panic (fmt=) at 
/usr/local/src/sys/kern/kern_shutdown.c:707
#4  0x80546b33 in propagate_priority (td=) at 
/usr/local/src/sys/kern/subr_turnstile.c:226
#5  0x8054720c in turnstile_wait (ts=0xf80151ac4180, owner=, queue=)
at /usr/local/src/sys/kern/subr_turnstile.c:742
#6  0x804dda81 in __mtx_lock_sleep (c=0x80c9c910, v=)
at /usr/local/src/sys/kern/kern_mutex.c:627
#7  0x805cd061 in bpf_dtor (data=0xf801512df800) at 
/usr/local/src/sys/net/bpf.c:778
#8  0x80455e5c in devfs_fpdrop (fp=) at 
/usr/local/src/sys/fs/devfs/devfs_vnops.c:193
#9  0x804595d5 in devfs_close_f (fp=0xf802af2fe6e0, td=)
at /usr/local/src/sys/fs/devfs/devfs_vnops.c:675
#10 0x804b1549 in closef (fp=0xf802af2fe6e0, td=0xf8000cf75000) 
at file.h:346
#11 0x804af00b in closefp (fdp=0xf80083b48000, fd=, fp=0xf802af2fe6e0,
td=0xf8000cf75000, holdleaders=0) at 
/usr/local/src/sys/kern/kern_descrip.c:1191
#12 0x807afb6c in amd64_syscall (td=0xf8000cf75000, traced=0) at 
subr_syscall.c:132
#13 0x80791c3d in fast_syscall_common () at 
/usr/local/src/sys/amd64/amd64/exception.S:480
#14 0x004a317a in ?? ()
Previous frame inner to this frame (corrupt stack?)
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: kern.sched.quantum: Creepy, sadistic scheduler

2018-04-17 Thread Eivind Nicolay Evensen 
On Wed, Apr 04, 2018 at 09:32:58AM -0400, George Mitchell wrote:
> On 04/04/18 06:39, Alban Hertroys wrote:
> > [...]
> > That said, SCHED_ULE (the default scheduler for quite a while now) was 
> > designed with multi-CPU configurations in mind and there are claims that 
> > SCHED_4BSD works better for single-CPU configurations. You may give that a 
> > try, if you're not already on SCHED_4BSD.
> > [...]
> 
> A small, disgruntled community of FreeBSD users who have never seen
> proof that SCHED_ULE is better than SCHED_4BSD in any environment
> continue to regularly recompile with SCHED_4BSD.  I dread the day when
> that becomes impossible, but at least it isn't here yet.  -- George

Indeed 4bsd is better in my case aswell. While for some unknown to me reason
ule performed a bit better in the 10.x series than before, in 11.x
it again is in my case not usable.

Mouse freezes for around half a second with even frequency by just moving
it around in x11. Using 4bsd instead makes the problem go away.
I'm actually very happy that ule became worse again because going
back to 4bsd yet again also gave improved performance from other
dreadfully slow but (to me) still useful programs, like darktable.

With 4bsd, when adjusting shadows and highlights it is possible to see what I
do when moving sliders. With ule it has never been better than waiting
10-20-30 seconds to see where it was able to read a slider position
and update display, when working on images around 10500x10500 greyscale.

It's not single cpu/single core either:
CPU: AMD FX(tm)-6300 Six-Core Processor  (3817.45-MHz K8-class CPU)




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