Re: kern/166406: [ipfw] ipfw does not set ALTQ identifier for ipv6 traffic
Old Synopsis: ipfw does not set ALTQ identifier for ipv6 traffic New Synopsis: [ipfw] ipfw does not set ALTQ identifier for ipv6 traffic Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Wed Mar 28 08:53:25 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=166406 ___ 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: kern/166411: [pf] simply enabling pf makes udpxy not to work
Old Synopsis: simply enabling pf makes udpxy not to work New Synopsis: [pf] simply enabling pf makes udpxy not to work Responsible-Changed-From-To: freebsd-bugs->freebsd-pf Responsible-Changed-By: linimon Responsible-Changed-When: Wed Mar 28 08:54:35 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=166411 ___ 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: kern/166458: [libc] bind(2) incorrectly interprets SO_REUSEADDR option as also implying SO_REUSEPORT on FreeBSD
Synopsis: [libc] bind(2) incorrectly interprets SO_REUSEADDR option as also implying SO_REUSEPORT on FreeBSD State-Changed-From-To: open->analyzed State-Changed-By: glebius State-Changed-When: Wed Mar 28 09:02:08 UTC 2012 State-Changed-Why: This PR needs discussion. http://www.freebsd.org/cgi/query-pr.cgi?pr=166458 ___ 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: kern/166458: bind() incorrectly interprets SO_REUSEADDR option as also implying SO_REUSEPORT on FreeBSD
The following reply was made to PR kern/166458; it has been noted by GNATS. From: Gleb Smirnoff To: Sean Bruno Cc: freebsd-gnats-sub...@freebsd.org Subject: Re: kern/166458: bind() incorrectly interprets SO_REUSEADDR option as also implying SO_REUSEPORT on FreeBSD Date: Wed, 28 Mar 2012 13:01:40 +0400 Sean, On Wed, Mar 28, 2012 at 12:53:03AM +, Sean Bruno wrote: S> ... seems to be a bug in FreeBSD when specifying port number 0 in the S> socket address passed to the bind system call in order to let the kernel S> select a free port number. S> S> The semantics of SO_REUSEADDR is inconsistently implemented on FreeBSD. S> S> FreeBSD 4 jail environment (on a FreeBSD 4 host): S> S> dev-tegge:~$ ./bindbug S> serversock addr is 10.76.250.174:40328 S> dup bind: Address already in use S> This error was expected, tried to bind to used addr/port S> dup2 bind: Address already in use S> This error was expected, tried to bind to used port without SO_REUSEPORT S> autosock addr is 10.76.250.174:40328 S> bug triggered, port number conflict on sockets without SO_REUSEPORT S> listen succeded after implicitly overlapping port bind S> S> FreeBSD 6 host enironment: S> S> tegge-store1:~:$ ./bindbug S> serversock addr is 127.0.0.1:59073 S> dup bind: Address already in use S> This error was expected, tried to bind to used addr/port S> BUG: binding duplicate socket to server port succeeded S> dup2sock addr is 0.0.0.0:59073 S> overlapping explicit bind to same port number succeeded without SO_REUSEPORT S> listen succeeded after explicitly overlapping port bind S> autosock addr is 0.0.0.0:59073 S> bug triggered, port number conflict on sockets without SO_REUSEPORT S> listen succeded after implicitly overlapping port bind S> S> RHEL4 host environment: S> S> [tegge@dell-bl1s3 ~]$ time ./bindbug S> serversock addr is 127.0.0.1:43270 S> dup bind: Address already in use S> This error was expected, tried to bind to used addr/port S> dup2 bind: Address already in use S> This error was expected, tried to bind to used port without SO_REUSEPORT S> bug not triggered after 16777216 iterations I don't see a bug in FreeBSD 6 behavior. To speak about bug we need to have a clear description of correct behavior. Unfortunately the SO_REUSEADDR option is tersely documented in our manuals, as well as in POSIX. Thus I will advocate to the TCP/IP Book by Stevens as documentation, quoting it, page 720: SO_REUSEADDR Allows the process to bind to a port number that is already in use, but the IP address being bound (including the wildcard) must not already be bound to that same port. For example, if an attached interface has the IP address 140.252.1.29 then one socket can be bound to 140.252.1.29, port ; another socket can be bound to 127.0.0.1, port ; and another socket can be bound to the wildcard IP address, port . The call to bind for the second and third cases must be preceeded by a call to setsockopt, setting the SO_REUSEADDR option. http://books.google.ru/books?id=ESM3CWY5xRYC&pg=PA720&hl=ru&source=gbs_toc_r&cad=4#v=onepage&q&f=false -- Totus tuus, Glebius. ___ 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
To: bug-follo...@freebsd.org
Cc: Konstantin Belousov , a...@freebsd.org
Subject: Re: misc/166340: Process under FreeBSD 9.0 hangs in uninterruptable
sleep with apparently no syscall (empty wchan)
Date: Wed, 28 Mar 2012 15:30:29 +0200
--=-KhwYlamRji7Rmc2IYneE
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Yes. It sounds like a good idea to get a consistent "snapshot" of
everything. So here it is. pid = 2527
# ps -o user,pid,ppid,pending,caught,ignored,blocked,stat,wchan 2527
USER PID PPID PENDING CAUGHT IGNORED BLOCKED STAT WCHAN
nobody 2527 25250 80005006 79f880100 D-
# ps -o pid,paddr 2527
PID PADDR
2527 fe025a476488
# procstat -kk 2527
PIDTID COMM TDNAME KSTACK
2527 101206 serelog -mi_switch+0x2eb
sleepq_check_timeout+0x9f sleepq_timedwait_sig+0x20 _sleep+0x2a1
soreceive_generic+0xea9 kern_recvit+0x1c4 recvit+0x21 sys_recvfrom+0x82
amd64_syscall+0x478 Xfast_syscall+0xf7
The kgdb data is attached.
The smallest ktr trace I could produce is approximately 200MB. It's
still rather big, so if you want a filtered version I would need to know
how exactly this should be done (I haven't found a way to filter for a
pid).
Posting the full 200MB as followup is surely not appreciated, so I can
either upload/send it somewhere or will find a place where you can
download it. Any favored solution for you, Konstantin? We can use direct
mail if preferred for discussing the details.
Christian
--=-KhwYlamRji7Rmc2IYneE
Content-Disposition: attachment; filename="kgdb.2527.txt"
Content-Type: text/plain; name="kgdb.2527.txt"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
(kgdb) p *(struct proc *)0xfe025a476488
$1 = {p_list = {le_next = 0xfe01a3f44910, le_prev = 0xfe02c73f8488},
p_threads = {tqh_first = 0xfe004edc0480, tqh_last = 0xfe004edc0490},
p_slock = {lock_object = {
lo_name = 0x80d3f62c "process slock", lo_flags = 720896, lo_data
= 0, lo_witness = 0xff8000689f80}, mtx_lock = 4}, p_ucred =
0xfe021f48d000, p_fd = 0xfe026f3bc600, p_fdtol = 0x0,
p_stats = 0xfe018e9c6a00, p_limit = 0xfe004ed0fb00, 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 = 0xfe025a476580,
c_flags = 0, c_cpu = 0}, p_sigacts = 0xfe035ebe5000, p_flag =
268452096, p_state = PRS_NORMAL, p_pid = 2527, p_hash = {le_next = 0x0, le_prev
= 0xff80006aaef8}, p_pglist = {le_next = 0x0,
le_prev = 0xfe01a3827790}, p_pptr = 0xfe0008353910, p_sibling =
{le_next = 0xfe004e8a6910, le_prev = 0xfe01b9f639f0}, p_children =
{lh_first = 0x0}, p_mtx = {lock_object = {
lo_name = 0x80d3f61f "process lock", lo_flags = 21168128,
lo_data = 0, lo_witness = 0xff8000688400}, mtx_lock = 4}, p_ksi =
0xfe004e0f10e0, p_sigqueue = {sq_signals = {__bits = {16384, 0, 0, 0}},
sq_kill = {__bits = {0, 0, 0, 0}}, sq_list = {tqh_first =
0xfe02f5841540, tqh_last = 0xfe0287f372a0}, sq_proc =
0xfe025a476488, sq_flags = 1}, p_oppid = 0, p_dbg_child = 0, p_vmspace =
0xfe018e5d7000,
p_swtick = 340601, 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 = 798780190, rux_uticks = 12, rux_sticks = 45, rux_iticks = 0,
rux_uu = 84077, rux_su = 315289, rux_tu = 399367}, 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 = 0xfe007d9de000, 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 = 2,
p_itimers = 0x0, p_procdesc = 0x0, p_magic = 3203398350, p_osrel = 900044,
p_comm = "serelog", '\0' , p_pgrp = 0xfe01a3827780,
p_sysent = 0x810f1380, p_args = 0xfe020cf38300,
p_cpulimit = 9223372036854775807, p_nice = 0 '\0', p_fibnum = 0, p_xstat =
0, p_klist = {kl_list = {slh_first = 0x0}, kl_lock = 0x807f6ce0
, kl_unlock = 0x807f6d00 ,
kl_assert_locked = 0x807f6fe0 ,
kl_assert_unlocked = 0x807f6fc0 ,
kl_lockarg = 0xfe025a476580}, p_numthreads = 1, p_md = {md
Re: kern/166459: [atkbdc] [patch] other id for atkbdc
Synopsis: [atkbdc] [patch] other id for atkbdc Responsible-Changed-From-To: freebsd-bugs->jkim Responsible-Changed-By: jkim Responsible-Changed-When: Wed Mar 28 17:53:08 UTC 2012 Responsible-Changed-Why: I'll take it. Actually, the PNP ID is PNP0320 (little-endian). http://www.freebsd.org/cgi/query-pr.cgi?pr=166459 ___ 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/166477: NFS data corruption.
>Number: 166477 >Category: misc >Synopsis: NFS data corruption. >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Mar 28 21:20:11 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Paul Mezzanini >Release:9.0-RELEASE >Organization: Rochester Institute of Technology >Environment: FreeBSD tardis.rc.rit.edu 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >Description: Environment: NFS Client - clean FreeBSD 9 amd64 install NFS Server - BlueArc Mercury 110 NAS MTU 9000 Specifying default mount options will cause the data corruption to occur. It is consistent on which files are corrupted. Not all files become corrupt. I have not found what triggers the error within a file. File type (binary/text) does not seem to be a factor. I am still gathering data to try and isolate exactly where this error is being introduced. >How-To-Repeat: copy a file from the bluearc to local disk via nfs. "Copy" can be either cp, rsync or any other read method. >Fix: Force mount to use oldnfs OR force rsize/wsize to 32768 >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: kern/166382: [patch] snd_hda(4) is in a bad state after suspend/resume cycle
On Sat, Mar 24, 2012 at 11:22 PM, wrote: > Synopsis: [patch] snd_hda(4) is in a bad state after suspend/resume cycle > > Responsible-Changed-From-To: freebsd-bugs->mav > Responsible-Changed-By: eadler > Responsible-Changed-When: Sun Mar 25 04:22:54 UTC 2012 > Responsible-Changed-Why: > over to maintainer > > http://www.freebsd.org/cgi/query-pr.cgi?pr=166382 Hey mav, thanks for taking a look and providing a patch! Unfortunately, it doesn't fix the suspend/resume issue The headphone jack sense polling doesn't work after resume unless the callback is reinitialized. Does it hurt to reinit the callback in the case of both polling and non-polling configuartions? -Brandon ___ 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"
