[Bug 227654] [panic] repeatable crash with IPv6+lagg+vlan+em

2018-04-20 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227654

--- Comment #2 from Eugene Grosbein  ---
Created attachment 192690
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=192690=edit
debugging patch for single user only

Forgot to note that my kernel has VIMAGE too.

I've reproduced this with my home desktop that has serial console, so I've
digged this a bit deeper suspecting that curvnet may be not initialized.
I've added some debugging output, the diff is attached.

KASSERT did not catch this for unknown reason, so it's commented out.

Anyway, curvnet occured to be zero, so any attempt to use V_link_pfil_hook
dereferences NULL producing this panic:

ether_output_frame: vlan61: curvnet 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0453d37780
ether_output() at ether_output+0x64c/frame 0xfe0453d37820
arprequest() at arprequest+0x443/frame 0xfe0453d37920
arp_ifinit() at arp_ifinit+0x58/frame 0xfe0453d37960
arp_handle_ifllchange() at arp_handle_ifllchange+0x3d/frame 0xfe0453d37980
if_setlladdr() at if_setlladdr+0x21e/frame 0xfe0453d379e0
taskqueue_run_locked() at taskqueue_run_locked+0x14c/frame 0xfe0453d37a40
taskqueue_thread_loop() at taskqueue_thread_loop+0x88/frame 0xfe0453d37a70
fork_exit() at fork_exit+0x84/frame 0xfe0453d37ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe0453d37ab0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---


Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 03
fault virtual address   = 0x28
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80aca683
stack pointer   = 0x28:0xfe0453d37790
frame pointer   = 0x28:0xfe0453d37820
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (thread taskq)
trap number = 12
p

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

A little oddity with mlx4en

2018-04-20 Thread Pete French 
This amsued me. If I run 'sysctl -a' on a box with a ConnectX-2 card in
it then I get this message on console:

"mlx4_core0: port level mtu is only used for IB ports"

Quite surprised that listing sysctls results in messages to console!

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

HEADS-UP: Deprecation of legacy (v3) password database support

2018-04-20 Thread Ed Maste 
FreeBSD password databases (/etc/pwd.db, /etc/spwd.db) can contain
records in one or both of two versions:
 * v3, a legacy architecture-dependent format
 * v4, the current architecture- and endian-independent format

When v4 support was added in 2003 (r113596) pwd_mkdb emitted both v3 and
v4 records in the output database.  In 2015 r283981 added a -l option to
control the emission of legacy v3 records; by default only v4 records
are emitted.

r283981's commit message states:

The -l, -B and -L options are considered deprecated and will be
removed in FreeBSD 12.0 release.

I'd expect little impact if the -l, -B and -L options are removed, as
r113596 is included in FreeBSD 5.1 and later.  If legacy support is
removed then software built on FreeBSD 5.0 or earlier will no longer be
able to make use of password file data (via getpwent, getpwnam, etc.).
Such software would still function inside of a jail that has a v3
password database, of course.

Is anyone using pwd_mkdb's -l option and relying on legacy password
database files in a non-jailed context?
___
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"

[Bug 227654] [panic] repeatable crash with IPv6+lagg+vlan+em

2018-04-20 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227654

--- Comment #1 from Eugene Grosbein  ---
$ addr2line -e kernel.debug -i -f -C  806fe6ac
ether_output_frame
/data2/src/sys/net/if_ethersubr.c:449
ether_output
/data2/src/sys/net/if_ethersubr.c:435


(kgdb) l /data2/src/sys/net/if_ethersubr.c:449
444 int
445 ether_output_frame(struct ifnet *ifp, struct mbuf *m)
446 {
447 int i;
448 
449 if (PFIL_HOOKED(_link_pfil_hook)) {
450 i = pfil_run_hooks(_link_pfil_hook, , ifp,
PFIL_OUT, NULL);
451 
452 if (i != 0)
453 return (EACCES);

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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-20 Thread George Mitchell 
On 04/17/18 19:01, George Mitchell wrote:
> On 04/17/18 17:20, EBFE via freebsd-stable wrote:
>> [...]
>> 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
> 
I've now done SCHED_ULE runs with preempt_thresh set to 0, 1, 5, 80,
and 224.  The wall clock time is uniformly in the vicinity of 10 hours.
The "time" output is consistent with SCHED_4BSD, but the wall clock
time is really what I care about.

Now I have set kern.sched.preempt_thresh back to the default of 80 and
I am experimenting with kern.sched.interact.  I'm pretty sure that
setting kern.sched.preempt_thresh is not the answer to my problem.
-- George



signature.asc
Description: OpenPGP digital signature

MSP Globally Targeted Marketing Campaigns.

2018-04-20 Thread valerie . ross 
class="gmail-m-2425094833965102802gmail-msonospacing">style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,78,121)">Hi,


Hope this  
note finds you well!


style="margin-bottom:0.0001pt;line-height:normal">style="color:rgb(31,78,121)">I think there is an opportunity for us to help  
you run some

amazing campaigns that can increase sales, generate buzz, and enhance brand
awareness through our updated and Globally targeted list of style="color:rgb(31,78,121)">Manage

Service
Providers for Q2-2018  
marketing Campaigns


style="margin-bottom:0.0001pt;line-height:normal">style="color:rgb(31,56,100)"> 


style="margin-bottom:0.0001pt;line-height:normal">style="color:rgb(31,78,121)">List Contains:style="color:rgb(31,78,121)"> 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)"> 


style="margin-bottom:0.0001pt;line-height:normal">style="color:rgb(31,78,121)">You may also acquire database  
of:


style="margin-bottom:0.0001pt;line-height:normal">style="color:rgb(31,78,121)"> 


style="margin-bottom:0.0001pt;line-height:normal">style="color:rgb(31,78,121)">1.  Managed Security Service
providers- MSSPsstyle="color:rgb(31,78,121)">


style="margin-bottom:0.0001pt;line-height:normal">style="color:rgb(31,78,121)">2.  Value Added Resellers-

VARs

style="margin-bottom:0.0001pt;line-height:normal">style="color:rgb(31,78,121)">3.  Independent Software Vendors-

ISVs

style="margin-bottom:0.0001pt;line-height:normal">style="color:rgb(31,78,121)">4.  System Integrators-  
SIs


style="margin-bottom:0.0001pt;line-height:normal">style="color:rgb(31,78,121)">5.  VoIP Service Providers and
many more.style="color:rgb(31,78,121)">


style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,78,121)">Please  
let us know your interest to provide you with

detailed information.

style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,78,121)">Await  
your response!


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

Marketing Executive 
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"

Re: Ryzen issues on FreeBSD ? (with sort of workaround)

2018-04-20 Thread Mike Tancsa 
Its not just the Ryzen, I can lock up Epyc CPUs as well. They take a bit
longer, but its not that hard to repeat. Unfortunately, I had to
allocate this hardware over the Linux where it works reliably under all
workloads without any such lock ups with all the default BIOS settings :(

Here is a test case.
https://lists.freebsd.org/pipermail/freebsd-stable/2018-February/088433.html

Peter was able to recreate it as well.

https://lists.freebsd.org/pipermail/freebsd-virtualization/2018-March/006187.html

I dont think its VM / virtualization per se.  I think Peter mentioned
something about IPIs

---Mike



On 4/20/2018 8:39 AM, Nimrod Levy wrote:
> To be honest, I can't remember for certain what's set in the BIOS right
> now. The last post I made was from 3/17 and it says I have the memory clock
> lowered and c-states disabled. I don't think I've changed anything but the
> build of stable since then.
> 
> --
> Nimrod
> 
> On Fri, Apr 20, 2018 at 7:55 AM Pete French 
> wrote:
> 
>>
>>
>> On 20/04/2018 12:48, Nimrod Levy wrote:
>>> I'm really glad to see that I'm not the only one still interested in
>>> this thread.  I don't really have anything new to contribute. I've been
>>> getting about a week or so uptime out of my box. My habit has been to
>>> see if it hangs, then reboot and rebuild latest stable and reboot and
>>> run that for a while. Although now that this thread pops back up, I just
>>> realized it's been 2 weeks since the last cycle. I don't trust it yet,
>>> but I've seen clear improvement since this started.
>>
>> What setting sdo you have - just the ones I listed or some in the BSD
>> setup itself ? I am surprised that the operson who said they were
>> getting an actual Epyc server hasn't commented again on the thread.
>> Hopefully that means it works fine on the server hardware :-)
>>
>> I have seen a few commits go through in STABLE related to VM which
>> interest me, and which might cause hangs, so we shall see how it goes.
>> Possibly looking at the Ryzen issue has flushed out a few VM problems
>> anyway, which would be good, as more stbaility is always good (and I
>> have a vague hope it might fix the mysetrious Go hangs too).
>>
>> -pete.
>>


-- 
---
Mike Tancsa, tel +1 519 651 3400 x203
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada
___
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"

[Bug 227654] [panic] repeatable crash with IPv6+lagg+vlan+em

2018-04-20 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227654

Bug ID: 227654
   Summary: [panic] repeatable crash with IPv6+lagg+vlan+em
   Product: Base System
   Version: 11.1-STABLE
  Hardware: Any
OS: Any
Status: New
  Keywords: crash
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: n...@freebsd.org
  Reporter: eu...@freebsd.org
CC: sta...@freebsd.org

Created attachment 192681
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=192681=edit
panic screenshot

Hi!

I run my workstation under FreeBSD 11.1-STABLE/amd64 r331249 with custom kernel
including IPv6 support, options DDB, KDB, INVARIANTS and WITNESS.

The following sequence of commands produces a panic reliably, including
cold-booted single user mode:

ifconfig tap0 create up
ifconfig lagg0 create up
ifconfig lagg0 laggport tap0
ifconfig em0 up
ifconfig vlan61 create vlan 61 vlandev em0
ifconfig vlan61 inet 192.168.0.1/24
ifconfig lagg0 laggport em0 # instant panic

Panic messages sometimes printed in bright-white and then system jumps to BIOS
POST within a second or so. Sometimes they are pronted in gray then system just
hangs solid without any reaction on Ctrl-Alt-ESC to enter KDB and no crashdump
generated.

Screenshot is attached.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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: Ryzen issues on FreeBSD ? (with sort of workaround)

2018-04-20 Thread Nimrod Levy 
To be honest, I can't remember for certain what's set in the BIOS right
now. The last post I made was from 3/17 and it says I have the memory clock
lowered and c-states disabled. I don't think I've changed anything but the
build of stable since then.

--
Nimrod

On Fri, Apr 20, 2018 at 7:55 AM Pete French 
wrote:

>
>
> On 20/04/2018 12:48, Nimrod Levy wrote:
> > I'm really glad to see that I'm not the only one still interested in
> > this thread.  I don't really have anything new to contribute. I've been
> > getting about a week or so uptime out of my box. My habit has been to
> > see if it hangs, then reboot and rebuild latest stable and reboot and
> > run that for a while. Although now that this thread pops back up, I just
> > realized it's been 2 weeks since the last cycle. I don't trust it yet,
> > but I've seen clear improvement since this started.
>
> What setting sdo you have - just the ones I listed or some in the BSD
> setup itself ? I am surprised that the operson who said they were
> getting an actual Epyc server hasn't commented again on the thread.
> Hopefully that means it works fine on the server hardware :-)
>
> I have seen a few commits go through in STABLE related to VM which
> interest me, and which might cause hangs, so we shall see how it goes.
> Possibly looking at the Ryzen issue has flushed out a few VM problems
> anyway, which would be good, as more stbaility is always good (and I
> have a vague hope it might fix the mysetrious Go hangs too).
>
> -pete.
>
-- 

--
Nimrod
___
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: Ryzen issues on FreeBSD ? (with sort of workaround)

2018-04-20 Thread Pete French 



On 20/04/2018 12:48, Nimrod Levy wrote:
I'm really glad to see that I'm not the only one still interested in 
this thread.  I don't really have anything new to contribute. I've been 
getting about a week or so uptime out of my box. My habit has been to 
see if it hangs, then reboot and rebuild latest stable and reboot and 
run that for a while. Although now that this thread pops back up, I just 
realized it's been 2 weeks since the last cycle. I don't trust it yet, 
but I've seen clear improvement since this started.


What setting sdo you have - just the ones I listed or some in the BSD 
setup itself ? I am surprised that the operson who said they were 
getting an actual Epyc server hasn't commented again on the thread. 
Hopefully that means it works fine on the server hardware :-)


I have seen a few commits go through in STABLE related to VM which 
interest me, and which might cause hangs, so we shall see how it goes. 
Possibly looking at the Ryzen issue has flushed out a few VM problems 
anyway, which would be good, as more stbaility is always good (and I 
have a vague hope it might fix the mysetrious Go hangs too).


-pete.
___
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: Ryzen issues on FreeBSD ? (with sort of workaround)

2018-04-20 Thread Nimrod Levy 
I'm really glad to see that I'm not the only one still interested in this
thread.  I don't really have anything new to contribute. I've been getting
about a week or so uptime out of my box. My habit has been to see if it
hangs, then reboot and rebuild latest stable and reboot and run that for a
while. Although now that this thread pops back up, I just realized it's
been 2 weeks since the last cycle. I don't trust it yet, but I've seen
clear improvement since this started.


On Fri, Apr 20, 2018 at 7:18 AM Pete French 
wrote:

> So, resurrecting the thread from a few weeks ago, as I finally found
> time yesterday to out together the Ryzen machine I bought the parts for in
> Jaunary (busy year at work). All went smoothl;y, checked it
> booted up, used it for 15 minutes, was impressed by the speed and went
> home.
>
> ...and by the time I got home, an hour or so later, it had locked up hard.
>
> I was somewhat dissapointed, as I had seen various fixes go in,. and had
> hoped
> the issues were fixed. This morning I have booted the machine back up,
> tweaking the BIOPS to do things mentioned in this thread, viz:
>
> Disable Turbo Boost
> Disable SMT
> Disable global C-states
>
> The memory was already ruunning correctly at 2133 (though I have locked
> that
> in the BIOS too) and I was already using kern.eventtimer.periodic=1, so
> the lockup was not related to those. Its the latest BIOS, and a -STABLE
> build from yesterday.
>
> I suspect it will now be stable, but I was wondering if anyone was any
> further
> forward on working out which of the settings above are the ones which 'fix'
> the issue - or indeed if its really fixed, by them or just made far less
> likely
> to happen.
>
> Anyone got any more comments on this ?
>
> cheers,
>
> -pete.
> ___
> 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"
>
-- 

--
Nimrod
___
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: Ryzen issues on FreeBSD ? (with sort of workaround)

2018-04-20 Thread Pete French 
So, resurrecting the thread from a few weeks ago, as I finally found
time yesterday to out together the Ryzen machine I bought the parts for in
Jaunary (busy year at work). All went smoothl;y, checked it
booted up, used it for 15 minutes, was impressed by the speed and went home.

...and by the time I got home, an hour or so later, it had locked up hard.

I was somewhat dissapointed, as I had seen various fixes go in,. and had hoped
the issues were fixed. This morning I have booted the machine back up,
tweaking the BIOPS to do things mentioned in this thread, viz:

Disable Turbo Boost
Disable SMT
Disable global C-states

The memory was already ruunning correctly at 2133 (though I have locked that
in the BIOS too) and I was already using kern.eventtimer.periodic=1, so
the lockup was not related to those. Its the latest BIOS, and a -STABLE
build from yesterday.

I suspect it will now be stable, but I was wondering if anyone was any further
forward on working out which of the settings above are the ones which 'fix'
the issue - or indeed if its really fixed, by them or just made far less likely
to happen.

Anyone got any more comments on this ?

cheers,

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