[Bug 207048] kernel panic at sleepq_add+0x1d0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207048
Bug ID: 207048
Summary: kernel panic at sleepq_add+0x1d0
Product: Base System
Version: 11.0-CURRENT
Hardware: amd64
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs@FreeBSD.org
Reporter: ekr...@gmail.com
CC: freebsd-am...@freebsd.org
CC: freebsd-am...@freebsd.org
Stack trace:
--
panic: sleepq_add: td 0xf8002adb24f0 to sleep on wchan 0x82541b08
with sleeping prohibited
cpuid = 2
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2c/frame 0xfe0094a43120
kdb_backtrace() at kdb_backtrace+0x53/frame 0xfe0094a431f0
vpanic() at vpanic+0x249/frame 0xfe0094a432c0
kassert_panic() at kassert_panic+0xc7/frame 0xfe0094a43350
sleepq_add() at sleepq_add+0x1d0/frame 0xfe0094a433c0
_sx_slock_hard() at _sx_slock_hard+0x714/frame 0xfe0094a435a0
__sx_slock() at __sx_slock+0x76/frame 0xfe0094a43600
_sx_slock() at _sx_slock+0x14d/frame 0xfe0094a43660
vtprintf() at vtprintf+0x4b/frame 0xfe0094a43710
krping_printf() at krping_printf+0x54/frame 0xfe0094a43780
krping_cq_event_handler() at krping_cq_event_handler+0x390/frame
0xfe0094a43860
c4iw_ev_handler() at c4iw_ev_handler+0xa0/frame 0xfe0094a438e0
service_iq() at service_iq+0x3b6/frame 0xfe0094a43a30
t4_intr() at t4_intr+0x54/frame 0xfe0094a43a70
intr_event_execute_handlers() at intr_event_execute_handlers+0x252/frame
0xfe0094a43ac0
ithread_execute_handlers() at ithread_execute_handlers+0x47/frame
0xfe0094a43af0
ithread_loop() at ithread_loop+0x106/frame 0xfe0094a43b70
fork_exit() at fork_exit+0x145/frame 0xfe0094a43bf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe0094a43bf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
Location where the panic has hit:
sleepq_add(void *wchan, struct lock_object *lock, const char *wmesg, int flags,
int queue)
{
struct sleepqueue_chain *sc;
struct sleepqueue *sq;
struct thread *td;
td = curthread;
sc = SC_LOOKUP(wchan);
mtx_assert(&sc->sc_lock, MA_OWNED);
MPASS(td->td_sleepqueue != NULL);
MPASS(wchan != NULL);
MPASS((queue >= 0) && (queue < NR_SLEEPQS));
/* If this thread is not allowed to sleep, die a horrible death. */
===>KASSERT(td->td_no_sleeping == 0,
("%s: td %p to sleep on wchan %p with sleeping prohibited",
__func__, td, wchan));
The panic is occuring when I am running krping kernel tool in a loop(and not
through manual attempts)
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 207055] ipv6 pmtu discovery not working with pf active
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207055
Bug ID: 207055
Summary: ipv6 pmtu discovery not working with pf active
Product: Base System
Version: 10.2-STABLE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: freebsd-bugs@FreeBSD.org
Reporter: h...@hellmuth-michaelis.de
CC: freebsd-am...@freebsd.org
CC: freebsd-am...@freebsd.org
IPv6 path mtu discovery is not working when pf is enabled and active.
OS Version is 10.3 BETA1
A very similar bug was reported in 115413, and i see that the there mentioned
patch is applied, but v6 pmtu is still not working.
There was already a mail sent to freebsd-net some time ago with a detailed
description of what is happening and things i tried, it can be found at
https://lists.freebsd.org/pipermail/freebsd-net/2014-May/038590.html
The problem is, that the machine in question sends out an (obviously) too large
packet. The router (which is also a FreeBSD machine being the gateway to sixxs)
detects this and sends an ICMP Packet too big back.
In case pf is disabled, all is fine and you can see the updated mtu in
net.inet.tcp.hostcache.list.
As soon as you enable pf, this does not take place anymore and the router sends
the ICMP too big messages 4 or 5 times and the connection hangs and no update
to net.inet.tcp.hostcache.list is taking place.
At the first time i saw this, it was a 2014 FreeBSD 10, now i upgraded the
machine to 10.3 BETA1 and the effect is still the same.
I made a patch to /usr/src/sys/netpfil/pf/pf.c with a shortcircuit and some
printfs and then pmtu functions again with pf enabled (you see it in
net.inet.tcp.hostcache.list) - i think this is not a fix but at least a
workaround:
*** pf.c-DIST Thu Jan 14 12:06:14 2016
--- pf.cMon Feb 8 16:23:41 2016
***
*** 4759,4766
pf_print_state(*state);
printf(" seq=%u\n", seq);
}
! REASON_SET(reason, PFRES_BADSTATE);
! return (PF_DROP);
} else {
if (V_pf_status.debug >= PF_DEBUG_MISC) {
printf("pf: OK ICMP %d:%d ",
--- 4759,4780
pf_print_state(*state);
printf(" seq=%u\n", seq);
}
! if(icmptype != ICMP6_PACKET_TOO_BIG)
! {
! REASON_SET(reason, PFRES_BADSTATE);
! return (PF_DROP);
! }
! else
! {
! printf("pf: suspicious ICMP %d:%d ",
! icmptype, pd->hdr.icmp->icmp_code);
! pf_print_host(pd->src, 0, pd->af);
! printf(" -> ");
! pf_print_host(pd->dst, 0, pd->af);
! printf(" state: ");
! pf_print_state(*state);
! printf(" seq=%u\n", seq);
! }
} else {
if (V_pf_status.debug >= PF_DEBUG_MISC) {
printf("pf: OK ICMP %d:%d ",
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 207056] Changing the MAC address on the lagg interface doesn't get retained after lagg port delete operation.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207056 Bug ID: 207056 Summary: Changing the MAC address on the lagg interface doesn't get retained after lagg port delete operation. Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: gopu.0...@gmail.com Changing the MAC address on the lagg interface does not get retained after lagg port delete operation. How to reproduce: -> Create a lagg interface -> Add 2 ports to a lagg interface -> Set the NEW MAC address on the lagg interface, which in-turn change the MAC of the 2 physical ports. -> Remove a lagg port from the lagg interface. (It should be the first interface of LAGG / Master port) Buggy part: -> The NEWLY ADDED MAC address will be lost, the lagg interface will have the other members physical interface MAC interface. Fix Proposal: -> At first place, why the MAC change is allowed on the lagg interface. -> If allowed then the MAC shall be the generic MAC, that shall not be affinity to a phyiscal port. Hence add / delete port operations on the lagg interface should not affect the lagg interface MAC address (Unless all the ports were deleted). -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 206467] 520.pfdenied does not reset counters every day
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206467 --- Comment #1 from commit-h...@freebsd.org --- A commit references this bug: Author: lidl Date: Tue Feb 9 21:00:39 UTC 2016 New revision: 295452 URL: https://svnweb.freebsd.org/changeset/base/295452 Log: Zero pf rule counters so daily reports make sense Zero pf rule counters so that each daily report lists an absolute number of rejected packets, not the total since the last time the machine rebooted (or the counters were manually cleared). PR: 206467 Submitted by: Rick Adams Approved by: rpaulo (mentor) Differential Revision:https://reviews.freebsd.org/D5172 Changes: head/etc/periodic/security/520.pfdenied -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 202069] FreeBSD 11-CURRENT r285794 on Dell Inspiron 13 7352: ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECRD] Namespace lookup failure, AE_NOT_FOUND (20150619/psargs-391)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202069 Gunnar Frenzel changed: What|Removed |Added CC||Gunnar.Frenzel@frenzelsoft. ||de --- Comment #2 from Gunnar Frenzel --- I got the exact same error: ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECRD] NAMESPACE lookup failure, AE_NOT_FOUND (20150515/psargs-391) ACPI Error: Method parse/execution failed [\_TZ_.TZ00._TMP] (Node 0xf80005423540), AE_NOT_FOUND (20150515/psparse-552) ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECRD] Namespace lookup failure, AE_NOT_FOUND (20150515/psargs-391) ACPI Error: Method parse/execution failed [\_TZ_.TZ01._TMP] (Node 0xf80005423400), AE_NOT_FOUND (20150515/psparse-552) on a Lenovo U41-70 Laptop with FreeBSD 10.2 Release. I'm using Legacy BIOS mode (no UEFI) with Secure Boot disabled. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 202069] FreeBSD 11-CURRENT r285794 on Dell Inspiron 13 7352: ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECRD] Namespace lookup failure, AE_NOT_FOUND (20150619/psargs-391)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202069 --- Comment #3 from Gunnar Frenzel --- Created attachment 166815 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=166815&action=edit dmesg.boot on Lenovo U41-70 Laptop Here's my dmesg.boot. Regards, Gunnar -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 206845] Change the newsyslog.conf to be alphabetical D5160
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206845 Chris Petrik changed: What|Removed |Added Status|New |Closed Resolution|--- |Feedback Timeout -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 207055] ipv6 pmtu discovery not working with pf active
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207055 Kristof Provost changed: What|Removed |Added CC||k...@freebsd.org --- Comment #1 from Kristof Provost --- I can't seem to immediately reproduce this. Can you attach your pf.conf? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 207068] hwpmc wrap around/sign extension
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207068 Bug ID: 207068 Summary: hwpmc wrap around/sign extension Product: Base System Version: 10.2-STABLE Hardware: amd64 OS: Any Status: New Keywords: hwpmc Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: joss.up...@yahoo.com CC: freebsd-am...@freebsd.org, joss.up...@yahoo.com CC: freebsd-am...@freebsd.org hwpmc_intel writes the old value of a counter back to the counter value register during a context switch in. However, those registers ignore the upper 32 bits (EDX) and instead sign extended to the register width based on EAX[31]. This is the behavior on all machines not supporting "full width writes" (indicated by CPUID2_PDCM being set && and IA32_PERF_CAPABILITIES(0x345) & FW_WRITE(bit 13) being set). If full width writes are supported, full-width aliases for IA32_PMCn exist 0x400 MSRs higher (e.g. IA32_PMC0 == 0xC1 and IA32_A_PMC0 = 0x4C1). This affects processes monitoring CPU_CLK for processes running more than a second or two. Using this counter quickly runs into a "negative increment" assertion in hwpmc_mod.c because of the sign extension. Attached is the least invasive patch I could come up with and it's against 10.2-R. It also fixes a few debugging PMCDBGs and adjusts the size of PMC_DEFAULT_DEBUG_FLAGS to match the size of the structure. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 207069] setting loader password crashes boot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207069 Bug ID: 207069 Summary: setting loader password crashes boot Product: Base System Version: 10.2-STABLE Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: da...@dcrosstech.com setting a password in loader.conf on 10.2-RELEASE+ machines, including 10.3-BETA1 causes loader to crash the boot with the following error message: Loading /boot/defaults/loader.conf can't load 'kernel' no valid kernel found -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 207070] gptboot not zeroing memory while reading from boot.config
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207070
Bug ID: 207070
Summary: gptboot not zeroing memory while reading from
boot.config
Product: Base System
Version: 10.2-STABLE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: freebsd-bugs@FreeBSD.org
Reporter: da...@dcrosstech.com
CC: freebsd-am...@freebsd.org
CC: freebsd-am...@freebsd.org
This should effect both i386 and amd64.. but I can only pick one.
gptboot does not zero the read buffer around line 162, the result is a
nondeterminstic, apparently hardware/bios specific condition where parsing
fails on the unterminated boot.config file.
Patch is:
--- /usr/src/sys/boot/i386/gptboot/gptboot.c2015-08-12 10:22:09.0
-0400
+++ gptboot.c 2016-02-05 21:09:12.0 -0500
@@ -159,9 +159,9 @@
return (-1);
autoboot = 1;
- *cmd = '\0';
for (;;) {
+ bzero(cmd, sizeof(cmd));
*kname = '\0';
if ((ino = lookup(PATH_CONFIG)) ||
(ino = lookup(PATH_DOTCONFIG)))
Pretty straighforwaed, eliminate the single null terminationa and replace with
a bzero of the entire buffer. single byte termination handled the case where
here was no boot.config file, but not the case where there was something read
it.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 207070] gptboot not zeroing memory while reading from boot.config
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207070 da...@dcrosstech.com changed: What|Removed |Added CC||da...@dcrosstech.com --- Comment #1 from da...@dcrosstech.com --- Created attachment 166823 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=166823&action=edit The patch Patch -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
