bin/166404: [patch (resubmission)] src/usr.sbin/mptutil/mpt_show.c
Number: 166404
Category: bin
Synopsis: [patch (resubmission)] src/usr.sbin/mptutil/mpt_show.c
Confidential: no
Severity: serious
Priority: medium
Responsible:freebsd-bugs
State: open
Quarter:
Keywords:
Date-Required:
Class: change-request
Submitter-Id: current-users
Arrival-Date: Mon Mar 26 06:20:08 UTC 2012
Closed-Date:
Last-Modified:
Originator: Conrad J. Sabatier
Release:FreeBSD 10.0-CURRENT amd64
Organization:
Environment:
System: FreeBSD serene.no-ip.org 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Sun Feb
12 19:15:46 CST 2012 conr...@serene.no-ip.org:/usr/obj/usr/src/sys/CUSTOM amd64
Description:
When building world with DEBUG defined, the build fails in the file
usr.sbin/mptutil/mpt_show.c in function show_physdisks(). This
function is wrapped in an #idfef DEBUG conditional and so will not cause
any problems when DEBUG is not defined, but when it is, an 'undefined
identifier' error occurs due to there being no declaration for the
variable 'error' (which *is* declared in other, similar functions which
aren't DEBUG-dependent).
I originally submitted this patch back in late January, but it seems to
have somehow simply fallen through the cracks.
How-To-Repeat:
Define DEBUG on a buildworld. Sit back and wait for the inevitable.
Fix:
patch below
--- mptutil.diff begins here ---
Index: src/usr.sbin/mptutil/mpt_show.c
===
RCS file: /home/ncvs/src/usr.sbin/mptutil/mpt_show.c,v
retrieving revision 1.3
diff -u -r1.3 mpt_show.c
--- src/usr.sbin/mptutil/mpt_show.c 9 Nov 2010 19:28:06 - 1.3
+++ src/usr.sbin/mptutil/mpt_show.c 31 Jan 2012 19:22:16 -
@@ -538,7 +538,7 @@
{
CONFIG_PAGE_RAID_PHYS_DISK_0 *pinfo;
U16 IOCStatus;
- int fd, i;
+ int error, fd, i;
if (ac != 1) {
warnx(show drives: extra arguments);
--- mptutil.diff ends here ---
Release-Note:
Audit-Trail:
Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
misc/166406: ipfw does not set ALTQ identifier for ipv6 traffic
Number: 166406 Category: misc Synopsis: ipfw does not set ALTQ identifier for ipv6 traffic Confidential: no Severity: non-critical Priority: medium Responsible:freebsd-bugs State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Mon Mar 26 07:40:10 UTC 2012 Closed-Date: Last-Modified: Originator: Oleksandr Martsyniuk Release:8.3 Organization: Environment: FreeBSD border.campus-rv.net 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #2: Sat Mar 24 12:48:53 EET 2012 sa...@border.campus-rv.net:/usr/obj/usr/src/sys/ROUTER amd64 Description: ipfw does not set ALTQ identifier for ipv6 traffic. How-To-Repeat: pf.conf: queue ui_ip6_q on lagg2 bandwidth 35Mb ipfw.rules: #ui_ip6_q ipfw add 10351 count altq ui_ip6_q ipv6 from any to any via gre0 in Counters for rule 10351 are increasing, but no traffic passes the ui_ip6_q queue. The pf rule pass in quick on gre0 all no state queue ui_ip6_q makes it pass. Fix: Release-Note: Audit-Trail: Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Your message to freebsd-doc awaits moderator approval
Your mail to 'freebsd-doc' with the subject Career opportunity inside Is being held until the list moderator can review it for approval. The reason it is being held: SpamAssassin identified this message as possible spam Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://lists.freebsd.org/mailman/confirm/freebsd-doc/ee3bc52e4af0699833c526e69183d5f71a5ee18f PLEASE NOTE! If you would like to post freely to the list, please subscribe first. If you post from multiple addresses, you can subscribe each address and go into the options page and select 'no mail' for all but one address. This will allow you to post without delay in the future. Sorry for the hassle, but certain immature people made this necessary. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Your message to freebsd-questions awaits moderator approval
Your mail to 'freebsd-questions' with the subject Career opportunity inside Is being held until the list moderator can review it for approval. The reason it is being held: SpamAssassin identified this message as possible spam Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://lists.freebsd.org/mailman/confirm/freebsd-questions/e01b886b1a0771b925ebac98be4a4fc80513a3d0 PLEASE NOTE! If you would like to post freely to the list, please subscribe first. If you post from multiple addresses, you can subscribe each address and go into the options page and select 'no mail' for all but one address. This will allow you to post without delay in the future. Sorry for the hassle, but certain immature people made this necessary. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: misc/166340: Process under FreeBSD 9.0 hangs in uninterruptable sleep with apparently no syscall (empty wchan)
The following reply was made to PR kern/166340; it has been noted by GNATS.
From: Christian Esken christian.es...@trivago.com
To: Kostik Belousov kostik...@gmail.com
Cc: bug-follo...@freebsd.org, a...@freebsd.org
Subject: Re: misc/166340: Process under FreeBSD 9.0 hangs in uninterruptable
sleep with apparently no syscall (empty wchan)
Date: Mon, 26 Mar 2012 11:58:12 +0200
Am Samstag, den 24.03.2012, 00:54 +0200 schrieb Kostik Belousov:
Please, attach the kgdb to the running system when the process hang
with the '-' wchan.
Use the command like kgdb /boot/kernel/kernel.symbols /dev/mem.
Then, run the shell command ps -o pid,paddr | grep pid where pid is
the pid of the hung
process. Take the printed address A and, from kgdb, do:
p *(struct proc *)A
p/x *(((struct proc *)A)-p_threads.tqh_first)
and show us the output.
Thanks for the quick response. Requested information can be found below.
I am also showing signal status, as signals seem to be relevant in
the kernel code section shown by Andriy.
Christian
# ps -o user,pid,ppid,pending,caught,ignored,blocked,stat,wchan 1780
USER PID PPID PENDING CAUGHT IGNORED BLOCKED STAT WCHAN
nobody 1780 17760 80005006 79fa80110 D-
# ps wwwaux -o pid,paddr | grep 1780
nobody 1780 0.0 0.0 55252 6040 ?? D12:11PM
0:01.09 /usr/local/bin/s 1780 fe003eb71488
(kgdb) p *(struct proc *)0xfe003eb71488
$1 = {p_list = {le_next = 0xfe003eb71910, le_prev = 0xfe003e20f488},
p_threads = {
tqh_first = 0xfe000bcf7460, tqh_last = 0xfe000bcf7470}, p_slock =
{lock_object = {
lo_name = 0x80ccb0fc process slock, lo_flags = 720896, lo_data
= 0,
lo_witness = 0xff8000689f80}, mtx_lock = 4}, p_ucred =
0xfe003e850200,
p_fd = 0xfe003ec9aa00, p_fdtol = 0x0, p_stats = 0xfe003eca3400,
p_limit = 0xfe0008372500, p_limco = {c_links = {sle = {sle_next = 0x0},
tqe = {
tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0, c_arg = 0x0, c_func = 0,
c_lock = 0xfe003eb71580, c_flags = 0, c_cpu = 0}, p_sigacts =
0xfe003e9de000,
p_flag = 268452096, p_state = PRS_NORMAL, p_pid = 1780, p_hash = {le_next =
0x0,
le_prev = 0xfe03889e00b8}, p_pglist = {le_next = 0xfe003eb71910,
le_prev = 0xfe01936a39d8}, p_pptr = 0xfe003e99b488, p_sibling = {
le_next = 0xfe003eb71910, le_prev = 0xfe01936a39f0}, p_children = {
lh_first = 0x0}, p_mtx = {lock_object = {lo_name = 0x80ccb0ef
process lock,
lo_flags = 21168128, lo_data = 0, lo_witness = 0xff8000688400},
mtx_lock = 4},
p_ksi = 0xfe000b0a6380, p_sigqueue = {sq_signals = {__bits = {0, 0, 0,
0}}, sq_kill = {
__bits = {0, 0, 0, 0}}, sq_list = {tqh_first = 0x0, tqh_last =
0xfe003eb715c8},
sq_proc = 0xfe003eb71488, sq_flags = 1}, p_oppid = 0, p_dbg_child = 0,
p_vmspace = 0xfe000b1e7620, p_swtick = 249340, p_realtimer =
{it_interval = {
tv_sec = 0, tv_usec = 0}, it_value = {tv_sec = 0, tv_usec = 0}}, p_ru =
{ru_utime = {
tv_sec = 0, tv_usec = 0}, ru_stime = {tv_sec = 0, tv_usec = 0},
ru_maxrss = 0,
ru_ixrss = 0, ru_idrss = 0, ru_isrss = 0, ru_minflt = 0, ru_majflt = 0,
ru_nswap = 0,
ru_inblock = 0, ru_oublock = 0, ru_msgsnd = 0, ru_msgrcv = 0, ru_nsignals
= 0,
ru_nvcsw = 0, ru_nivcsw = 0}, p_rux = {rux_runtime = 2178328093,
rux_uticks = 77,
rux_sticks = 39, rux_iticks = 0, rux_uu = 722939, rux_su = 366163, rux_tu
= 1089103},
p_crux = {rux_runtime = 0, rux_uticks = 0, rux_sticks = 0, rux_iticks = 0,
rux_uu = 0,
rux_su = 0, rux_tu = 0}, p_profthreads = 0, p_exitthreads = 0, p_traceflag
= 0,
p_tracevp = 0x0, p_tracecred = 0x0, p_textvp = 0xfe003ebdfb40, p_lock =
0,
p_sigiolst = {slh_first = 0x0}, p_sigparent = 20, p_sig = 0, p_code = 0,
p_stops = 0,
p_stype = 0, p_step = 0 '\0', p_pfsflags = 0 '\0', p_nlminfo = 0x0,
p_aioinfo = 0x0,
p_singlethread = 0x0, p_suspcount = 0, p_xthread = 0x0, p_boundary_count =
0,
p_pendingcnt = 0, p_itimers = 0x0, p_procdesc = 0x0, p_magic = 3203398350,
p_osrel = 900044, p_comm = serelog, '\0' repeats 12 times, p_pgrp =
0xfe003e76a200,
p_sysent = 0x81066440, p_args = 0xfe003e77f700,
p_cpulimit = 9223372036854775807, p_nice = 0 '\0', p_fibnum = 0, p_xstat =
0, p_klist = {
kl_list = {slh_first = 0x0}, kl_lock = 0x807d4880
knlist_mtx_lock,
kl_unlock = 0x807d48a0 knlist_mtx_unlock,
kl_assert_locked = 0x807d4700 knlist_mtx_assert_locked,
kl_assert_unlocked = 0x807d4710 knlist_mtx_assert_unlocked,
kl_lockarg = 0xfe003eb71580}, p_numthreads = 1, p_md = {md_ldt = 0x0,
md_ldt_sd = {
sd_lolimit = 0, sd_lobase = 0, sd_type = 0, sd_dpl = 0, sd_p = 0,
sd_hilimit = 0,
sd_xx0 = 0, sd_gran = 0, sd_hibase = 0, sd_xx1 = 0, sd_mbz = 0, sd_xx2 =
0}},
p_itcallout = {c_links
kern/166411: simply enabling pf makes udpxy not to work
Number: 166411 Category: kern Synopsis: simply enabling pf makes udpxy not to work Confidential: no Severity: non-critical Priority: low Responsible:freebsd-bugs State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Mon Mar 26 12:50:01 UTC 2012 Closed-Date: Last-Modified: Originator: Stefan BALU Release:FreeBSD 9.0-RELEASE Organization: - Environment: FreeBSD **.*.** 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Sun Mar 25 02:27:31 EET 2012 r...@fw.llldental.ro:/usr/obj/usr/src/sys/FW amd64 Description: I have an issue with pf and udpxy. I have a gateway machine with 3 ethernet cards: re0 - wan re1 - lan re2 - tv The tv interface connects to my isp's IPTV network where multicast udp and igmp packets come and go. In order for my computers and tvs to get the IPTV stream, i use an HTTP to UDP proxy (udpxy). This little application takes HTTP requests in the form of: http://udpxy-server:port/udp/CHANNEL_IP:CHANNEL_PORT from lan clients and registers to these multicast streams on the tv interface. However, the problem appears when i simply enable pf. With no rule in pf.conf, running /etc/rc.d/pf start simply makes udpxy to stop working throwing: read_buf: read: Resource temporary unavailable After spending lots of hours figuring this out, i disabled pf and everything suddenly worked. Using ipfilter, the problem is totally gone. How-To-Repeat: Fix: Release-Note: Audit-Trail: Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: misc/166340: Process under FreeBSD 9.0 hangs in uninterruptable sleep with apparently no syscall (empty wchan)
The following reply was made to PR kern/166340; it has been noted by GNATS. From: Konstantin Belousov kostik...@gmail.com To: Christian Esken christian.es...@trivago.com Cc: bug-follo...@freebsd.org, a...@freebsd.org Subject: Re: misc/166340: Process under FreeBSD 9.0 hangs in uninterruptable sleep with apparently no syscall (empty wchan) Date: Mon, 26 Mar 2012 16:51:42 +0300 Thank you for the data. Semi-obviously, the callout_stop() call in sleepq_check_timeout() have to return 0, otherwise we would not call mi_switch() there. But I do not see how this can happen, because the callout state, printed from kgdb, still indicates that callout is pending. Callout cannot be reset while in sleepq code. So there are two possible routes to go forward: preferrable is for you to extract the self-contained C program that would illustrate the issue and send this sample to me. Second is to recompile your kernel with INVARIANTS/WITNESS and possibly KTR and see what happen. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
