Re: Danish FreeBSD Developer hates jews collectively
On Thu, 09 May 2019 18:03:04 + ossobser...@redchan.it wrote: > Background: Apparently a FreeBSD developer, a viking looking fellow, > has been hiding a secret: just as many of his predecessors in the > Danish cities during WWII (collaborators); He has a disdain for "the > jews" collectively. > Who cares!? ___ 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: Danish FreeBSD Developer hates jews collectively
On May 9, 2019 10:16:35 PM GMT+03:00, Enji Cooper wrote: > >> On May 9, 2019, at 11:03 AM, ossobser...@redchan.it wrote: > >This is the only reply I’m going to give to this thread that seems like >obvious troll bait. Oh yeah, if you see anything mentioning "GPL revocation", it's most likely the work of That Guy: https://redd.it/b8wwhk https://redd.it/antkt3 Looks like low-effort spamming of Reddit was so unsatisfying that he went back to high-effort trolling. ___ 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: Danish FreeBSD Developer hates jews collectively
In message <49cfcff55fe21d5d01df916e9f953...@redchan.it>, ossobserver@redchan.i t writes: You forgot to include this link: http://phk.freebsd.dk/sagas/israel/ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: Panic in fbt_provide_module_function() on head amd64 r347403
On 05/09/2019 5:19 pm, Trond Endrestøl wrote:
Host is Windows 7 x64 SP1.
CPU is Core i7 960.
Hypervisor is VirtualBox 6.0.6.
VM is using UEFI.
Kernel config is
https://ximalas.info/~trond/create-zfs/canmount/VBOXGUEST-amd64-head
Crash happens early during boot, right after launching the APs.
fault virtual address = 0x0
[...]
KDB backtrace:
db_trace_self_wrapper() at
vpanic() at
panic() at
trap_fatal() at
trap_pfault() at
trap() at
calltrap() at
-- trap 0xc, rip = 0x8196d63a, rsp = 0x8198d730, rbp =
0x8198d790 ---
fbt_provide_module_function() at 0x8196d63a =
fbt_provide_module_function+0x7a/frame 0x8198d790
link_elf_each_function_nameval() at 0x80822ae5 =
link_elf_each_function_nameval+0x115/frame 0x8198d7e0
fbt_provide_module() at 0x8196c33e =
fbt_provide_module+0xde/frame 0x8198dc10
fbt_linker_file_cb() at 0x8196c242 =
fbt_linker_file_cb+0x12/frame 0x8198dc20
linker_file_foreach() at 0x807c47b7 =
linker_file_foreach+0x67/frame 0x8198dc60
mi_startup() at 0x80786de6 = mi_startup+0x216/frame
0x8198dcb0
btext() at 0x8030da2c = btext+0x2c
Uptime: 1s
Previous BE is r346969 and works flawlessly.
No dumpdev is enabled to capture the details this early during boot.
Suggestions are welcome.
There is a patch:
From: ma...@freebsd.org (on my Crash loading dtraceall thread):
I see, my theory above is not the real problem here. The resolver for
x86_rng_store() may return NULL, which we do not expect. Can you show
the CPU info and features lines from the dmesg to confirm?
Also see if this patch helps:
diff --git a/sys/dev/random/ivy.c b/sys/dev/random/ivy.c
index 57f3d0a1d80b..71065d788cf9 100644
--- a/sys/dev/random/ivy.c
+++ b/sys/dev/random/ivy.c
@@ -97,6 +97,13 @@ x86_rdseed_store(u_long *buf)
return (retry);
}
+static int
+x86_dead_store(u_long *buf __unused)
+{
+
+panic("missing hardware PRNG support");
+}
+
DEFINE_IFUNC(static, int, x86_rng_store, (u_long *buf), static)
{
has_rdrand = (cpu_feature2 & CPUID2_RDRAND);
@@ -107,7 +114,7 @@ DEFINE_IFUNC(static, int, x86_rng_store, (u_long
*buf), static)
else if (has_rdrand)
return (x86_rdrand_store);
else
-return (NULL);
+return (x86_dead_store);
}
/* It is required that buf length is a multiple of sizeof(u_long). */
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
___
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"
Panic in fbt_provide_module_function() on head amd64 r347403
Host is Windows 7 x64 SP1. CPU is Core i7 960. Hypervisor is VirtualBox 6.0.6. VM is using UEFI. Kernel config is https://ximalas.info/~trond/create-zfs/canmount/VBOXGUEST-amd64-head Crash happens early during boot, right after launching the APs. fault virtual address = 0x0 [...] KDB backtrace: db_trace_self_wrapper() at vpanic() at panic() at trap_fatal() at trap_pfault() at trap() at calltrap() at -- trap 0xc, rip = 0x8196d63a, rsp = 0x8198d730, rbp = 0x8198d790 --- fbt_provide_module_function() at 0x8196d63a = fbt_provide_module_function+0x7a/frame 0x8198d790 link_elf_each_function_nameval() at 0x80822ae5 = link_elf_each_function_nameval+0x115/frame 0x8198d7e0 fbt_provide_module() at 0x8196c33e = fbt_provide_module+0xde/frame 0x8198dc10 fbt_linker_file_cb() at 0x8196c242 = fbt_linker_file_cb+0x12/frame 0x8198dc20 linker_file_foreach() at 0x807c47b7 = linker_file_foreach+0x67/frame 0x8198dc60 mi_startup() at 0x80786de6 = mi_startup+0x216/frame 0x8198dcb0 btext() at 0x8030da2c = btext+0x2c Uptime: 1s Previous BE is r346969 and works flawlessly. No dumpdev is enabled to capture the details this early during boot. Suggestions are welcome. -- 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: Danish FreeBSD Developer hates jews collectively
And this subject is on the -CURRENT (FreeBSD development) mail list because... On Thu, May 09, 2019 at 06:03:04PM +, ossobser...@redchan.it wrote: > Background: Apparently a FreeBSD developer, a viking looking fellow, has > been hiding a secret: just as many of his predecessors in the Danish cities > during WWII (collaborators); He has a disdain for "the jews" collectively. > > (No great surprise: he is a european, and past actions speak louder than any > present words.) > > Thus he blaims them collectively for the modern military slaughter of > innocents we see from all modern militaries (Usually it's the USA however) > > Apparently there was a debate, you can see it here: > https://twitter.com/bsdphk/status/1126199508449341440 > > He also seems to lament the Danish uprisings against the nazis of the past > (which he sees as not the finest thing). > > So he's clearly a white who hates the jews. > He probably has no problem with white women ruling over him, ofcourse: > that's "the way it should be". > > Then someone decided to attempt to "CoC" him (report him and get him thrown > out of FreeBSD). > > No man should be thrown out of a code project for their beliefs regarding > endless slaughter. Slaughter is the "work" of men: and it is right for them > to have an opinion regarding it - it is only natural. The blacksmith has an > opinion on the qualities of various sourced iron, the thresher: his grain, > and the man: in what ways and quantities blood should be shed. > > (Women should be thrown out of code projects before they utter a word, > naturally, for banning men from marrying young girls, ofcourse (YHWH allows > men to marry young girls: Devarim chapter 22 verse 28 (na'ar (hebrew > masoretic text: child)) (padia (greek septuagint: child)) (puella (latin > vulgate: young girl))) > > So, in furtherance of the principal that men, who are murderous by blood, > should be free to discuss their ancestral occupation: Poul-Henning Kamp has > been sent this message regarding license revocation and gratis non-exclusive > license: https://lkml.org/lkml/2019/5/9/434 > > "No slaughter" is a ... valid ... view. At least for a time. It is his right > to hold it, Though not a realistic view > ___ > 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" -- Best Regards, Alexandre C. Guimarães. https://bitbucket.org/rigoletto-freebsd/ signature.asc Description: PGP signature
Re: Danish FreeBSD Developer hates jews collectively
On Thu, 9 May 2019 at 19:07, wrote: > > Background: Apparently a FreeBSD developer, a viking looking fellow, > has been hiding a secret: just as many of his predecessors in the Danish > cities during WWII (collaborators); He has a disdain for "the jews" > collectively. Freedom of expression exists to protect the rights of others to express views one might find distasteful; for a likeable/favourable expression needs no protection---it's axiomatically welcome. When opposing views are oppressed through gross generalisation and appeal to emotion, it is a clear sign that those who oppose a particular unpalatable expression lack logical argument to oppose it. For that reason, while I might (or might not) disagree with any particular expression, I would defend their right to express their views without fear, and implore others to do same while pointing big fingers of shame at those who actively suppress or oppress fundamental human freedoms! -- Igor M. ___ 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: Danish FreeBSD Developer hates jews collectively
> On May 9, 2019, at 11:03 AM, ossobser...@redchan.it wrote: This is the only reply I’m going to give to this thread that seems like obvious troll bait. As a native English speaker who often gets into debates about controversial issues with respect to concepts like classism, LGBTIQ issues, race issues, etc, the argument phk@ made wasn’t necessary in favor of anti-semitism from the perspective of hating Jewish people or their culture/religion; it was more or less commentary about policy issues with Israelis vs Palestine, apartheid, the Gaza strip occupation and the fact that some of the Israeli people aren’t acting out against the issues between both parties in an attempt to end the conflict. With this in mind, it was a poorly worded response which led to a slippery slope in a discussion, done on a social medium (Twitter) that seems to get blown out of proportion really quickly (trolls and misinterpretation abound). This kind of reasoning presented sounds a lot like cognitive dissonance employed by the far-right in America vs individuals like Rep. Ilhan Omar, etc, where they play the victim in order to make leftist groups look like they tolerate hate against certain groups (in this case Jewish people). Does that mean that the left has anti-Semites? Yes, it can happen, regardless of one’s political allegiance if one is to believe the left vs right dichotomy (which I think is largely poppycock, meant to separate groups via tribalism, etc). However, I think a number of people are reading between the tea leaves in this thread. Do I think phk@ and others should potentially take a step back from the discussion and avoid digging a larger hole than has already been dug? Yes. It’s not my business to make people do that though, since I’m not in a leadership/policy making position. Please leave this discussion on Twitter instead of flooding these mailing lists. Linux/OpenBSD should not be exposed to this unnecessary drama, and FreeBSD-CURRENT is the wrong mailing list for this (try freebsd-chat@ if you are so inclined). -Enji PS I am not representing the FreeBSD project; I am only representing my personal opinion. ___ 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: at SVN r347375, terminating/restarting openvpn on tap causes panic
On Thu, May 09, 2019 at 02:32:44PM -0400, Michael Butler wrote: M> (kgdb) frame 8 M> #8 0x80a15377 in ip_output (m=, opt= optimized out>, ro=0x0, flags=0, imo=0xfe0072b14780, inp=0x0) at M> /usr/src/sys/netinet/ip_output.c:362 M> 362 IFP_TO_IA(ifp, ia, _ifa_tracker); M> (kgdb) print imo M> $1 = (struct ip_moptions *) 0xfe0072b14780 M> (kgdb) print ifp M> $2 = (struct ifnet *) 0xf8000411 M> (kgdb) print ia M> $3 = ... This all looks good. Can you please traverse the 'in_ifaddrhead' linked list? -- 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: at SVN r347375, terminating/restarting openvpn on tap causes panic
On 2019-05-09 14:22, Gleb Smirnoff wrote:
> Michael,
>
> On Thu, May 09, 2019 at 10:25:37AM -0500, Kyle Evans wrote:
> K> > #0 doadump () at src/sys/amd64/include/pcpu.h:241
> K> > #1 0x808393c8 in kern_reboot (howto=260) at
> K> > /usr/src/sys/kern/kern_shutdown.c:470
> K> > #2 0x80839826 in vpanic (fmt=, ap= K> > optimized out>) at /usr/src/sys/kern/kern_shutdown.c:896
> K> > #3 0x80839663 in panic (fmt=) at
> K> > /usr/src/sys/kern/kern_shutdown.c:823
> K> > #4 0x80c318a6 in trap_fatal (frame=0xfe0072b14510, eva=156)
> K> > at /usr/src/sys/amd64/amd64/trap.c:946
> K> > #5 0x80c31c59 in trap_pfault (frame=0xfe0072b14510,
> K> > usermode=0) at src/sys/amd64/include/cpufunc.h:423
> K> > #6 0x80c30fde in trap (frame=0xfe0072b14510) at
> K> > /usr/src/sys/amd64/amd64/trap.c:441
> K> > #7 0x80c0d4b5 in calltrap () at
> K> > /usr/src/sys/amd64/amd64/exception.S:232
> K> > #8 0x80a15377 in ip_output (m=, opt= K> > optimized out>, ro=0x0, flags=0, imo=0xfe0072b14780, inp=0x0) at
> K> > /usr/src/sys/netinet/ip_output.c:362
> K> > #9 0x809ffea4 in igmp_intr (m=) at
> K> > /usr/src/sys/netinet/igmp.c:3455
> K> > #10 0x80975a0f in netisr_dispatch_src (proto=2, source= K> > optimized out>, m=) at
> /usr/src/sys/net/netisr.c:1122
> K> > #11 0x809fe07a in igmp_fasttimo () at
> K> > /usr/src/sys/netinet/igmp.c:496
> K> > #12 0x808c5854 in pffasttimo (arg=) at
> K> > /usr/src/sys/kern/uipc_domain.c:521
> K> > #13 0x80853df3 in softclock_call_cc (c=0x813f7f48,
> K> > cc=0x814c9ac0, direct=0) at /usr/src/sys/kern/kern_timeout.c:731
> K> > #14 0x808542b9 in softclock (arg=0x814c9ac0) at
> K> > /usr/src/sys/kern/kern_timeout.c:869
> K> > #15 0x807fd0c4 in ithread_loop (arg=) at
> K> > /usr/src/sys/kern/kern_intr.c:1129
> K> > #16 0x807f9f33 in fork_exit (callout=0x807fcef0
> K> > , arg=0xf800025f10a0, frame=0xfe0072b14ac0) at
> K> > /usr/src/sys/kern/kern_fork.c:1058
> K> > #17 0x80c0e4ae in fork_trampoline () at
> K> > /usr/src/sys/amd64/amd64/exception.S:995
> K> > #18 0x in ?? ()
> K> >
> K>
> K> Ah, I misread your backtrace (and forgot the proper tap detachment
> K> from my previous patch, so that's fixed/committed anyways). CC'ing
> K> Gleb for further triage as committer of r347375 that touched things in
> K> this path.
>
> Michael, can you please dump a core and look at it in kgdb? Line 362 in
> ip_output() really belongs to part that had minimal change with r347375.
> So I need more details. Can you please print out in kgdb the following
> variables: imo, ifp, ia?
>
This was a backtrace from kgdb. From frame 8, I see ..
(kgdb) frame 8
#8 0x80a15377 in ip_output (m=, opt=, ro=0x0, flags=0, imo=0xfe0072b14780, inp=0x0) at
/usr/src/sys/netinet/ip_output.c:362
362 IFP_TO_IA(ifp, ia, _ifa_tracker);
(kgdb) print imo
$1 = (struct ip_moptions *) 0xfe0072b14780
(kgdb) print ifp
$2 = (struct ifnet *) 0xf8000411
(kgdb) print ia
$3 =
(kgdb) print *imo
$4 = {imo_multicast_ifp = 0xf8000411, imo_multicast_addr =
{s_addr = 1924220944}, imo_multicast_vif = 18446744073709551615,
imo_multicast_ttl = 1 '\001', imo_multicast_loop = 0 '\0',
imo_num_memberships = 15350, imo_max_memberships = 63489,
imo_membership = 0xf80002c10d00, imo_mfilters = 0xf80002c10d00,
imo_epoch_ctx = {data = 0xfe0072b147b0}}
(kgdb) print *ifp
$5 = {if_link = {cstqe_next = 0x0}, if_clones = {le_next = 0x0, le_prev
= 0xf800040f9728}, if_groups = {cstqh_first = 0xf80002878d60,
cstqh_last = 0xf80002878d38},
if_alloctype = 6 '\006', if_numa_domain = 255 '�', if_softc =
0xf80004197300, if_llsoftc = 0x0, if_l2com = 0xf800040fe800,
if_dname = 0x80e0bd14 "tap", if_dunit = 0,
if_index = 4, if_index_reserved = 0, if_xname = 0xf80004110058
"tap0", if_description = 0x0, if_flags = 34818, if_drv_flags = 0,
if_capabilities = 524288, if_capenable = 524288,
if_linkmib = 0x0, if_linkmiblen = 0, if_refcount = 1, if_type = 6
'\006', if_addrlen = 6 '\006', if_hdrlen = 14 '\016', if_link_state = 1
'\001', if_mtu = 1500, if_metric = 0,
if_baudrate = 1000, if_hwassist = 0, if_epoch = 10, if_lastchange
= {tv_sec = 1557408022, tv_usec = 929504}, if_snd = {ifq_head = 0x0,
ifq_tail = 0x0, ifq_len = 0, ifq_maxlen = 50,
ifq_mtx = {lock_object = {lo_name = 0xf80004110058 "tap0",
lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 0},
ifq_drv_head = 0x0, ifq_drv_tail = 0x0,
ifq_drv_len = 0, ifq_drv_maxlen = 0, altq_type = 0, altq_flags = 0,
altq_disc = 0x0, altq_ifp = 0xf8000411, altq_enqueue = 0,
altq_dequeue = 0, altq_request = 0,
altq_clfier = 0x0, altq_classify = 0, altq_tbr = 0x0, altq_cdnr =
0x0}, if_linktask = {ta_link = {stqe_next = 0x0}, ta_pending = 0,
ta_priority = 0,
ta_func = 0x809494e0 , ta_context
Re: Danish FreeBSD Developer hates jews collectively
On 2019-05-09 14:03, ossobser...@redchan.it wrote: > Background: Apparently a FreeBSD developer, a viking looking fellow, Further miscellaneous dribble elided .. This has no place on this mailing list. Take your hate someplace else, imb ___ 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: at SVN r347375, terminating/restarting openvpn on tap causes panic
Michael, On Thu, May 09, 2019 at 10:25:37AM -0500, Kyle Evans wrote: K> > #0 doadump () at src/sys/amd64/include/pcpu.h:241 K> > #1 0x808393c8 in kern_reboot (howto=260) at K> > /usr/src/sys/kern/kern_shutdown.c:470 K> > #2 0x80839826 in vpanic (fmt=, ap= > optimized out>) at /usr/src/sys/kern/kern_shutdown.c:896 K> > #3 0x80839663 in panic (fmt=) at K> > /usr/src/sys/kern/kern_shutdown.c:823 K> > #4 0x80c318a6 in trap_fatal (frame=0xfe0072b14510, eva=156) K> > at /usr/src/sys/amd64/amd64/trap.c:946 K> > #5 0x80c31c59 in trap_pfault (frame=0xfe0072b14510, K> > usermode=0) at src/sys/amd64/include/cpufunc.h:423 K> > #6 0x80c30fde in trap (frame=0xfe0072b14510) at K> > /usr/src/sys/amd64/amd64/trap.c:441 K> > #7 0x80c0d4b5 in calltrap () at K> > /usr/src/sys/amd64/amd64/exception.S:232 K> > #8 0x80a15377 in ip_output (m=, opt= > optimized out>, ro=0x0, flags=0, imo=0xfe0072b14780, inp=0x0) at K> > /usr/src/sys/netinet/ip_output.c:362 K> > #9 0x809ffea4 in igmp_intr (m=) at K> > /usr/src/sys/netinet/igmp.c:3455 K> > #10 0x80975a0f in netisr_dispatch_src (proto=2, source= > optimized out>, m=) at /usr/src/sys/net/netisr.c:1122 K> > #11 0x809fe07a in igmp_fasttimo () at K> > /usr/src/sys/netinet/igmp.c:496 K> > #12 0x808c5854 in pffasttimo (arg=) at K> > /usr/src/sys/kern/uipc_domain.c:521 K> > #13 0x80853df3 in softclock_call_cc (c=0x813f7f48, K> > cc=0x814c9ac0, direct=0) at /usr/src/sys/kern/kern_timeout.c:731 K> > #14 0x808542b9 in softclock (arg=0x814c9ac0) at K> > /usr/src/sys/kern/kern_timeout.c:869 K> > #15 0x807fd0c4 in ithread_loop (arg=) at K> > /usr/src/sys/kern/kern_intr.c:1129 K> > #16 0x807f9f33 in fork_exit (callout=0x807fcef0 K> > , arg=0xf800025f10a0, frame=0xfe0072b14ac0) at K> > /usr/src/sys/kern/kern_fork.c:1058 K> > #17 0x80c0e4ae in fork_trampoline () at K> > /usr/src/sys/amd64/amd64/exception.S:995 K> > #18 0x in ?? () K> > K> K> Ah, I misread your backtrace (and forgot the proper tap detachment K> from my previous patch, so that's fixed/committed anyways). CC'ing K> Gleb for further triage as committer of r347375 that touched things in K> this path. Michael, can you please dump a core and look at it in kgdb? Line 362 in ip_output() really belongs to part that had minimal change with r347375. So I need more details. Can you please print out in kgdb the following variables: imo, ifp, ia? -- 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"
Danish FreeBSD Developer hates jews collectively
Background: Apparently a FreeBSD developer, a viking looking fellow, has been hiding a secret: just as many of his predecessors in the Danish cities during WWII (collaborators); He has a disdain for "the jews" collectively. (No great surprise: he is a european, and past actions speak louder than any present words.) Thus he blaims them collectively for the modern military slaughter of innocents we see from all modern militaries (Usually it's the USA however) Apparently there was a debate, you can see it here: https://twitter.com/bsdphk/status/1126199508449341440 He also seems to lament the Danish uprisings against the nazis of the past (which he sees as not the finest thing). So he's clearly a white who hates the jews. He probably has no problem with white women ruling over him, ofcourse: that's "the way it should be". Then someone decided to attempt to "CoC" him (report him and get him thrown out of FreeBSD). No man should be thrown out of a code project for their beliefs regarding endless slaughter. Slaughter is the "work" of men: and it is right for them to have an opinion regarding it - it is only natural. The blacksmith has an opinion on the qualities of various sourced iron, the thresher: his grain, and the man: in what ways and quantities blood should be shed. (Women should be thrown out of code projects before they utter a word, naturally, for banning men from marrying young girls, ofcourse (YHWH allows men to marry young girls: Devarim chapter 22 verse 28 (na'ar (hebrew masoretic text: child)) (padia (greek septuagint: child)) (puella (latin vulgate: young girl))) So, in furtherance of the principal that men, who are murderous by blood, should be free to discuss their ancestral occupation: Poul-Henning Kamp has been sent this message regarding license revocation and gratis non-exclusive license: https://lkml.org/lkml/2019/5/9/434 "No slaughter" is a ... valid ... view. At least for a time. It is his right to hold it, Though not a realistic view ___ 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: at SVN r347375, terminating/restarting openvpn on tap causes panic
On Thu, May 9, 2019 at 8:27 AM Michael Butler wrote: > > On 2019-05-09 09:07, Kyle Evans wrote: > > On Thu, May 9, 2019 at 7:24 AM Michael Butler > > wrote: > >> > >> Seems there's a lock or tuntap issue after recent changes. Restarting > >> openvpn (configured to use /dev/tap) yields a panic as follows: > >> > > > > Ah, I knew I was forgetting something. =( Give this a shot: > > https://people.freebsd.org/~kevans/etherdetach.diff > > Sorry - same result, > > (kgdb) bt > #0 doadump () at src/sys/amd64/include/pcpu.h:241 > #1 0x808393c8 in kern_reboot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:470 > #2 0x80839826 in vpanic (fmt=, ap= optimized out>) at /usr/src/sys/kern/kern_shutdown.c:896 > #3 0x80839663 in panic (fmt=) at > /usr/src/sys/kern/kern_shutdown.c:823 > #4 0x80c318a6 in trap_fatal (frame=0xfe0072b14510, eva=156) > at /usr/src/sys/amd64/amd64/trap.c:946 > #5 0x80c31c59 in trap_pfault (frame=0xfe0072b14510, > usermode=0) at src/sys/amd64/include/cpufunc.h:423 > #6 0x80c30fde in trap (frame=0xfe0072b14510) at > /usr/src/sys/amd64/amd64/trap.c:441 > #7 0x80c0d4b5 in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:232 > #8 0x80a15377 in ip_output (m=, opt= optimized out>, ro=0x0, flags=0, imo=0xfe0072b14780, inp=0x0) at > /usr/src/sys/netinet/ip_output.c:362 > #9 0x809ffea4 in igmp_intr (m=) at > /usr/src/sys/netinet/igmp.c:3455 > #10 0x80975a0f in netisr_dispatch_src (proto=2, source= optimized out>, m=) at /usr/src/sys/net/netisr.c:1122 > #11 0x809fe07a in igmp_fasttimo () at > /usr/src/sys/netinet/igmp.c:496 > #12 0x808c5854 in pffasttimo (arg=) at > /usr/src/sys/kern/uipc_domain.c:521 > #13 0x80853df3 in softclock_call_cc (c=0x813f7f48, > cc=0x814c9ac0, direct=0) at /usr/src/sys/kern/kern_timeout.c:731 > #14 0x808542b9 in softclock (arg=0x814c9ac0) at > /usr/src/sys/kern/kern_timeout.c:869 > #15 0x807fd0c4 in ithread_loop (arg=) at > /usr/src/sys/kern/kern_intr.c:1129 > #16 0x807f9f33 in fork_exit (callout=0x807fcef0 > , arg=0xf800025f10a0, frame=0xfe0072b14ac0) at > /usr/src/sys/kern/kern_fork.c:1058 > #17 0x80c0e4ae in fork_trampoline () at > /usr/src/sys/amd64/amd64/exception.S:995 > #18 0x in ?? () > Ah, I misread your backtrace (and forgot the proper tap detachment from my previous patch, so that's fixed/committed anyways). CC'ing Gleb for further triage as committer of r347375 that touched things in this path. ___ 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: at SVN r347375, terminating/restarting openvpn on tap causes panic
On 2019-05-09 09:07, Kyle Evans wrote: > On Thu, May 9, 2019 at 7:24 AM Michael Butler > wrote: >> >> Seems there's a lock or tuntap issue after recent changes. Restarting >> openvpn (configured to use /dev/tap) yields a panic as follows: >> > > Ah, I knew I was forgetting something. =( Give this a shot: > https://people.freebsd.org/~kevans/etherdetach.diff Sorry - same result, (kgdb) bt #0 doadump () at src/sys/amd64/include/pcpu.h:241 #1 0x808393c8 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:470 #2 0x80839826 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:896 #3 0x80839663 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:823 #4 0x80c318a6 in trap_fatal (frame=0xfe0072b14510, eva=156) at /usr/src/sys/amd64/amd64/trap.c:946 #5 0x80c31c59 in trap_pfault (frame=0xfe0072b14510, usermode=0) at src/sys/amd64/include/cpufunc.h:423 #6 0x80c30fde in trap (frame=0xfe0072b14510) at /usr/src/sys/amd64/amd64/trap.c:441 #7 0x80c0d4b5 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #8 0x80a15377 in ip_output (m=, opt=, ro=0x0, flags=0, imo=0xfe0072b14780, inp=0x0) at /usr/src/sys/netinet/ip_output.c:362 #9 0x809ffea4 in igmp_intr (m=) at /usr/src/sys/netinet/igmp.c:3455 #10 0x80975a0f in netisr_dispatch_src (proto=2, source=, m=) at /usr/src/sys/net/netisr.c:1122 #11 0x809fe07a in igmp_fasttimo () at /usr/src/sys/netinet/igmp.c:496 #12 0x808c5854 in pffasttimo (arg=) at /usr/src/sys/kern/uipc_domain.c:521 #13 0x80853df3 in softclock_call_cc (c=0x813f7f48, cc=0x814c9ac0, direct=0) at /usr/src/sys/kern/kern_timeout.c:731 #14 0x808542b9 in softclock (arg=0x814c9ac0) at /usr/src/sys/kern/kern_timeout.c:869 #15 0x807fd0c4 in ithread_loop (arg=) at /usr/src/sys/kern/kern_intr.c:1129 #16 0x807f9f33 in fork_exit (callout=0x807fcef0 , arg=0xf800025f10a0, frame=0xfe0072b14ac0) at /usr/src/sys/kern/kern_fork.c:1058 #17 0x80c0e4ae in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:995 #18 0x in ?? () imb ___ 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: Loading DRM kills computer
Should be fixed by: https://svnweb.freebsd.org/changeset/base/347385 Thank you! --HPS ___ 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: at SVN r347375, terminating/restarting openvpn on tap causes panic
On Thu, May 9, 2019 at 7:24 AM Michael Butler wrote: > > Seems there's a lock or tuntap issue after recent changes. Restarting > openvpn (configured to use /dev/tap) yields a panic as follows: > Ah, I knew I was forgetting something. =( Give this a shot: https://people.freebsd.org/~kevans/etherdetach.diff Thanks, Kyle Evans ___ 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"
at SVN r347375, terminating/restarting openvpn on tap causes panic
Seems there's a lock or tuntap issue after recent changes. Restarting openvpn (configured to use /dev/tap) yields a panic as follows: (kgdb) bt #0 doadump () at src/sys/amd64/include/pcpu.h:241 #1 0x808393c8 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:470 #2 0x80839826 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:896 #3 0x80839663 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:823 #4 0x80c31686 in trap_fatal (frame=0xfe0072b14510, eva=156) at /usr/src/sys/amd64/amd64/trap.c:946 #5 0x80c31a39 in trap_pfault (frame=0xfe0072b14510, usermode=0) at src/sys/amd64/include/cpufunc.h:423 #6 0x80c30dbe in trap (frame=0xfe0072b14510) at /usr/src/sys/amd64/amd64/trap.c:441 #7 0x80c0d295 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #8 0x80a15387 in ip_output (m=, opt=, ro=0x0, flags=0, imo=0xfe0072b14780, inp=0x0) at /usr/src/sys/netinet/ip_output.c:362 #9 0x809ffeb4 in igmp_intr (m=) at /usr/src/sys/netinet/igmp.c:3455 #10 0x80975a1f in netisr_dispatch_src (proto=2, source=, m=) at /usr/src/sys/net/netisr.c:1122 #11 0x809fe08a in igmp_fasttimo () at /usr/src/sys/netinet/igmp.c:496 #12 0x808c5854 in pffasttimo (arg=) at /usr/src/sys/kern/uipc_domain.c:521 #13 0x80853df3 in softclock_call_cc (c=0x813f7f48, cc=0x814c9ac0, direct=0) at /usr/src/sys/kern/kern_timeout.c:731 #14 0x808542b9 in softclock (arg=0x814c9ac0) at /usr/src/sys/kern/kern_timeout.c:869 #15 0x807fd0c4 in ithread_loop (arg=) at /usr/src/sys/kern/kern_intr.c:1129 #16 0x807f9f33 in fork_exit (callout=0x807fcef0 , arg=0xf80002620100, frame=0xfe0072b14ac0) at /usr/src/sys/kern/kern_fork.c:1058 #17 0x80c0e28e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:995 #18 0x in ?? () imb ___ 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: Crash loading dtraceall
On 05/08/2019 11:31 pm, Mark Johnston wrote:
On Wed, May 08, 2019 at 11:01:58PM -0500, Larry Rosenman wrote:
On 05/08/2019 10:32 pm, Mark Johnston wrote:
> On Wed, May 08, 2019 at 05:57:18PM -0500, Larry Rosenman wrote:
>> On 05/08/2019 5:55 pm, Mark Johnston wrote:
>> > On Wed, May 08, 2019 at 05:47:08PM -0500, Larry Rosenman wrote:
>> >> On 05/08/2019 5:29 pm, Mark Johnston wrote:
>> >> > On Wed, May 08, 2019 at 03:52:45PM -0500, Larry Rosenman wrote:
>> >> >> Greetings,
>> >> >>
>> >> >> Somewhere between r346483 and r347241 loading dtraceall causes a
>> >> >> crash. I have the cores and kernels.
>> >> >>
>> >> >> It's hard for me to bisect more than this, as the box is remote.
>> >> >>
>> >> >> What more do you need? (this dump is fropm r347355).
>> >> >
> The problem is with the kernel linker's handling of ifuncs. When
> enumerating symbols, it replaces ifunc symbol values with the return
> value of the resolver but preserves the original symbol size, which is
> that of the resolver. I believe this patch will address the panic
> you're seeing:
>
It does *NOT*.
I see, my theory above is not the real problem here. The resolver for
x86_rng_store() may return NULL, which we do not expect. Can you show
the CPU info and features lines from the dmesg to confirm?
Also see if this patch helps:
diff --git a/sys/dev/random/ivy.c b/sys/dev/random/ivy.c
index 57f3d0a1d80b..71065d788cf9 100644
--- a/sys/dev/random/ivy.c
+++ b/sys/dev/random/ivy.c
@@ -97,6 +97,13 @@ x86_rdseed_store(u_long *buf)
return (retry);
}
+static int
+x86_dead_store(u_long *buf __unused)
+{
+
+ panic("missing hardware PRNG support");
+}
+
DEFINE_IFUNC(static, int, x86_rng_store, (u_long *buf), static)
{
has_rdrand = (cpu_feature2 & CPUID2_RDRAND);
@@ -107,7 +114,7 @@ DEFINE_IFUNC(static, int, x86_rng_store, (u_long
*buf), static)
else if (has_rdrand)
return (x86_rdrand_store);
else
- return (NULL);
+ return (x86_dead_store);
}
/* It is required that buf length is a multiple of sizeof(u_long). */
The above patch (on top of the previous one) fixes the crash.
flags/features as requested:
CPU: Intel(R) Xeon(R) CPU E5440 @ 2.83GHz (2826.30-MHz
K8-class CPU)
Origin="GenuineIntel" Id=0x1067a Family=0x6 Model=0x17 Stepping=10
Features=0xbfebfbff
Features2=0xc0ce3bd
AMD Features=0x20100800
AMD Features2=0x1
VT-x: HLT,PAUSE
TSC: P-state invariant, performance statistics
--
Larry Rosenman http://people.freebsd.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@freebsd.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
___
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"
