misc/166440: fix depends
Number: 166440
Category: misc
Synopsis: fix depends
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: Tue Mar 27 11:40:11 UTC 2012
Closed-Date:
Last-Modified:
Originator: Vasiliy P. Melnik
Release:9.0-RELEASE
Organization:
na
Environment:
FreeBSD monkey.home 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Sat Jan 7 02:31:55 EET
2012 r...@monkey.home:/usr/obj/usr/src/sys/monkey i386
Description:
fix depends
How-To-Repeat:
Fix:
Diff mode was set to CVS, but there's no CVS subdirectory
Trying /usr/ports ... found
Warning: current directory name differs from Makefile header:
ldap-account-manager !=
=== Generating patch
=== Viewing diff with more
diff -ruN --exclude=CVS /usr/ports/sysutils/ldap-account-manager/Makefile
./Makefile
--- /usr/ports/sysutils/ldap-account-manager/Makefile 2012-03-26
21:54:15.0 +0300
+++ ./Makefile 2012-03-27 14:27:44.0 +0300
@@ -7,6 +7,7 @@
PORTNAME= ldap-account-manager
PORTVERSION= 3.7
+PORTREVISION= 1
CATEGORIES=sysutils www
MASTER_SITES= SF/${SHORTNAME}/LAM/${PORTVERSION}
@@ -21,7 +22,7 @@
NO_BUILD= yes
USE_GETTEXT= yes
USE_PERL5= yes
-USE_PHP= gettext hash iconv ldap mcrypt pcre session simplexml spl xml
json
+USE_PHP= gettext hash iconv ldap mcrypt pcre session simplexml spl xml
json zip
WANT_PHP_WEB= yes
DEFAULT_PHP_VER= 5
=== Done
Patch attached with submission follows:
Diff mode was set to CVS, but there's no CVS subdirectory
Trying /usr/ports ... found
Warning: current directory name differs from Makefile header:
ldap-account-manager !=
=== Generating patch
=== Viewing diff with more
diff -ruN --exclude=CVS /usr/ports/sysutils/ldap-account-manager/Makefile
./Makefile
--- /usr/ports/sysutils/ldap-account-manager/Makefile 2012-03-26
21:54:15.0 +0300
+++ ./Makefile 2012-03-27 14:27:44.0 +0300
@@ -7,6 +7,7 @@
PORTNAME= ldap-account-manager
PORTVERSION= 3.7
+PORTREVISION= 1
CATEGORIES=sysutils www
MASTER_SITES= SF/${SHORTNAME}/LAM/${PORTVERSION}
@@ -21,7 +22,7 @@
NO_BUILD= yes
USE_GETTEXT= yes
USE_PERL5= yes
-USE_PHP= gettext hash iconv ldap mcrypt pcre session simplexml spl xml
json
+USE_PHP= gettext hash iconv ldap mcrypt pcre session simplexml spl xml
json zip
WANT_PHP_WEB= yes
DEFAULT_PHP_VER= 5
=== Done
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: ports/166440: sysutils/ldap-account-manager: fix depends
Old Synopsis: fix depends New Synopsis: sysutils/ldap-account-manager: fix depends Responsible-Changed-From-To: freebsd-bugs-freebsd-ports-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Tue Mar 27 11:43:00 UTC 2012 Responsible-Changed-Why: ports PR http://www.freebsd.org/cgi/query-pr.cgi?pr=166440 ___ 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
kern/166441: bktr.ko does not exist
Number: 166441 Category: kern Synopsis: bktr.ko does not exist 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: Tue Mar 27 11:50:07 UTC 2012 Closed-Date: Last-Modified: Originator: Joe Stroud Release:8.2 Organization: Cubesoft Communications, Inc. Environment: FreeBSD elkab 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Sun Dec 18 03:36:49 UTC 2011 root@elkab:/usr/obj/usr/src/sys/GENERIC amd64 Description: There is no kernel support for Brooktree 8x8 capture devices, although the bktr manpage exists, and the Hardware Notes indicate support for such devices. There is speculation about that it was removed because it is unmaintained or that a commit clobbered the code. Nor will bktr compile during a custom kernel build. Where did it go? http://www.freebsd.org/releases/8.2R/hardware.html#CAMERA ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/8.2-RELEASE/kernels/generic.mtree 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: Christian Esken christian.es...@trivago.com To: bug-follo...@freebsd.org Cc: Konstantin Belousov kostik...@gmail.com, a...@freebsd.org Subject: Re: misc/166340: Process under FreeBSD 9.0 hangs in uninterruptable sleep with apparently no syscall (empty wchan) Date: Tue, 27 Mar 2012 17:30:27 +0200 --=-0r5Lk3awdhxqDAjyo6lR Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Konstantin Belousov wrote: 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. I repeated the test with INVARIANTS/WITNESS and KTR compiled in (actually WITNESS was already included during the last test). I ran KTR with nothing filtered out, and formatted the dump with ktrdump -cftH -i ktr.out. The whole log is excessive (1GB), so I have extrated two short sections (see attachment). The first section shows the last action of the application, namely a succselful sendto() to a TCP socket, and then waiting for an answer via recvfrom(). The second section illustrates the lock/unlock sequence of the sleep mutex for the recfrom(). It goes like LOCK, LOCK, UNLOCK. This time the signal status is different. We have a pending signal: USER PID PPID PENDING CAUGHT IGNORED BLOCKED STAT WCHAN nobody 9163 1 4000 80005006 79f880100 D- Looks like SIGPROF (27). Just wondering where it comes from. By the way: I evaluated the possibility to implement a standalone test case. It would be extremely complicated, as the issue is while writing to the socket, and thus it would require extracting the socket code from the Thrift procect (http://thrift.apache.org/ ). Christian --=-0r5Lk3awdhxqDAjyo6lR Content-Disposition: attachment; filename=wait_recvfrom.txt Content-Type: text/plain; name=wait_recvfrom.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit Last actions of pid 9163 (serelog): sendto() succesful recvfrom() waits for data, uisng sleep mutex 7463551 55644560314159 /usr/src/sys/kern/kern_sx.c:352 0xfe01972b2480 XUNLOCK (sx) so_snd_sx 0xfe0344b07490 r = 0 at /usr/src/sys/kern/uipc_sockbuf.c:160 7463552 15644560316280 /usr/src/sys/kern/kern_mutex.c:205 0xfe01bcf4d000 LOCK (sleep mutex) kqueue 0xfe03eef5eb00 r = 0 at /usr/src/sys/kern/kern_event.c:1779 7463553 55644560319107 /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:149 0xfe01972b2480 syscall: p=0xfe01bc1b0910 error=0 return 0x77d 0x77d 7463557 55644560329931 /usr/src/sys/kern/subr_trap.c:101 0xfe01972b2480 userret: thread 0xfe01972b2480 (pid 9163, serelog) 7463559 45644560336733 /usr/src/sys/vm/uma_core.c:1975 0xfe0008364480 uma_zalloc_arg thread 8364480 zone mbuf flags 1 7463561 65644560344432 /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:84 0xfe01972ae900 syscall: td=0xfe01972ae900 pid 9767 gettimeofday (0x7fffac40, 0, 0x43fd18) 7463562 15644560347528 /usr/src/sys/kern/kern_mutex.c:222 0xfe01bcf4d000 UNLOCK (sleep mutex) kqueue 0xfe03eef5eb00 r = 0 at /usr/src/sys/kern/kern_event.c:1796 7463563 65644560348788 /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:149 0xfe01972ae900 syscall: p=0xfe01bc1ad000 error=0 return 0 0x43fd18 7463564 55644560351047 /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:187 0xfe01972b2480 syscall sendto exit thread 0xfe01972b2480 pid 9163 proc serelog 7463565 15644560354848 /usr/src/sys/kern/kern_mutex.c:205 0xfe01bcf4d000 LOCK (sleep mutex) kqueue 0xfe02f7525700 r = 0 at /usr/src/sys/kern/kern_event.c:1779 7463567 55644560360499 /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:84 0xfe01972b2480 syscall: td=0xfe01972b2480 pid 9163 gettimeofday (0x7fffc600, 0, 0x ) 7463568 25644560364617 /usr/src/sys/kern/kern_mutex.c:356 0xfe004e384000 _mtx_lock_sleep: taskqueue contested (lock=0xfe0008375000) at /usr/src/sys/kern/kern_mutex.c :147 7463569 55644560366559 /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:149 0xfe01972b2480 syscall: p=0xfe01bc1b0910 error=0 return 0 0x 7463570 35644560369374 /usr/src/sys/kern/kern_mutex.c:222 0xfe0008375000 UNLOCK (sleep mutex) taskqueue 0xfe004e2604b0 r = 0 at
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: bug-follo...@freebsd.org Cc: Konstantin Belousov kostik...@gmail.com, a...@freebsd.org Subject: Re: misc/166340: Process under FreeBSD 9.0 hangs in uninterruptable sleep with apparently no syscall (empty wchan) Date: Tue, 27 Mar 2012 17:30:48 +0200 --=-3sl93MaMYlu/dkvvUUBe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Konstantin Belousov wrote: 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. I repeated the test with INVARIANTS/WITNESS and KTR compiled in (actually WITNESS was already included during the last test). I ran KTR with nothing filtered out, and formatted the dump with ktrdump -cftH -i ktr.out. The whole log is excessive (1GB), so I have extrated two short sections (see attachment). The first section shows the last action of the application, namely a succselful sendto() to a TCP socket, and then waiting for an answer via recvfrom(). The second section illustrates the lock/unlock sequence of the sleep mutex for the recfrom(). It goes like LOCK, LOCK, UNLOCK. This time the signal status is different. We have a pending signal: USER PID PPID PENDING CAUGHT IGNORED BLOCKED STAT WCHAN nobody 9163 1 4000 80005006 79f880100 D- Looks like SIGPROF (27). Just wondering where it comes from. By the way: I evaluated the possibility to implement a standalone test case. It would be extremely complicated, as the issue is while writing to the socket, and thus it would require extracting the socket code from the Thrift procect (http://thrift.apache.org/ ). Christian --=-3sl93MaMYlu/dkvvUUBe Content-Disposition: attachment; filename=wait_recvfrom.txt Content-Type: text/plain; name=wait_recvfrom.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit Last actions of pid 9163 (serelog): sendto() succesful recvfrom() waits for data, uisng sleep mutex 7463551 55644560314159 /usr/src/sys/kern/kern_sx.c:352 0xfe01972b2480 XUNLOCK (sx) so_snd_sx 0xfe0344b07490 r = 0 at /usr/src/sys/kern/uipc_sockbuf.c:160 7463552 15644560316280 /usr/src/sys/kern/kern_mutex.c:205 0xfe01bcf4d000 LOCK (sleep mutex) kqueue 0xfe03eef5eb00 r = 0 at /usr/src/sys/kern/kern_event.c:1779 7463553 55644560319107 /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:149 0xfe01972b2480 syscall: p=0xfe01bc1b0910 error=0 return 0x77d 0x77d 7463557 55644560329931 /usr/src/sys/kern/subr_trap.c:101 0xfe01972b2480 userret: thread 0xfe01972b2480 (pid 9163, serelog) 7463559 45644560336733 /usr/src/sys/vm/uma_core.c:1975 0xfe0008364480 uma_zalloc_arg thread 8364480 zone mbuf flags 1 7463561 65644560344432 /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:84 0xfe01972ae900 syscall: td=0xfe01972ae900 pid 9767 gettimeofday (0x7fffac40, 0, 0x43fd18) 7463562 15644560347528 /usr/src/sys/kern/kern_mutex.c:222 0xfe01bcf4d000 UNLOCK (sleep mutex) kqueue 0xfe03eef5eb00 r = 0 at /usr/src/sys/kern/kern_event.c:1796 7463563 65644560348788 /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:149 0xfe01972ae900 syscall: p=0xfe01bc1ad000 error=0 return 0 0x43fd18 7463564 55644560351047 /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:187 0xfe01972b2480 syscall sendto exit thread 0xfe01972b2480 pid 9163 proc serelog 7463565 15644560354848 /usr/src/sys/kern/kern_mutex.c:205 0xfe01bcf4d000 LOCK (sleep mutex) kqueue 0xfe02f7525700 r = 0 at /usr/src/sys/kern/kern_event.c:1779 7463567 55644560360499 /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:84 0xfe01972b2480 syscall: td=0xfe01972b2480 pid 9163 gettimeofday (0x7fffc600, 0, 0x ) 7463568 25644560364617 /usr/src/sys/kern/kern_mutex.c:356 0xfe004e384000 _mtx_lock_sleep: taskqueue contested (lock=0xfe0008375000) at /usr/src/sys/kern/kern_mutex.c :147 7463569 55644560366559 /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:149 0xfe01972b2480 syscall: p=0xfe01bc1b0910 error=0 return 0 0x 7463570 35644560369374 /usr/src/sys/kern/kern_mutex.c:222 0xfe0008375000 UNLOCK (sleep mutex) taskqueue 0xfe004e2604b0 r = 0 at
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: Tue, 27 Mar 2012 20:46:26 +0300 --KldKAdupQSLqpq2E Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 27, 2012 at 05:30:48PM +0200, Christian Esken wrote: Konstantin Belousov wrote: 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. =20 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. =20 I repeated the test with INVARIANTS/WITNESS and KTR compiled in (actually WITNESS was already included during the last test). =20 I ran KTR with nothing filtered out, and formatted the dump with ktrdump -cftH -i ktr.out. The whole log is excessive (1GB), so I have extrated two short sections (see attachment). =20 The first section shows the last action of the application, namely a succselful sendto() to a TCP socket, and then waiting for an answer via recvfrom(). The second section illustrates the lock/unlock sequence of the sleep mutex for the recfrom(). It goes like LOCK, LOCK, UNLOCK. =20 This time the signal status is different. We have a pending signal: USER PID PPID PENDING CAUGHT IGNORED BLOCKED STAT WCHAN nobody 9163 1 4000 80005006 79f880100 D-=20 =20 Looks like SIGPROF (27). Just wondering where it comes from. =20 This is irrelevant, and probably red-herring. The issue there is failing callout_stop() while callout seems to be still pending. Also, mask 0x4000 of the pending signals indicates that SIGTERM is pending, not SIGPROF. I probably want the data from your ktr dump, either all entries for the stuck process and all entries for facility CALLOUT, or just the whole dump. Last entries of your log shred do not make much sense, since the process must enter _sleep() function which logs this fact right after locking sleepq. But log ends on so_rcv mutex lock. Please, when collecting the data, collect the whole set, i.e. include procstat -kk pid output together with the ktr, as well as kgdb output, so that I can be sure that we chasing one, and not N bugs. --KldKAdupQSLqpq2E Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk9x/PIACgkQC3+MBN1Mb4hbeACfYyUTEE5GV/SeDO4fNf4ErfHY 27oAoIGj2TMOBtQRi5P+q/v+nrKOFhFb =0tFs -END PGP SIGNATURE- --KldKAdupQSLqpq2E-- ___ 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
kern/166458: bind() incorrectly interprets SO_REUSEADDR option as also implying SO_REUSEPORT on FreeBSD
Number: 166458 Category: kern Synopsis: bind() incorrectly interprets SO_REUSEADDR option as also implying SO_REUSEPORT on FreeBSD 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: Wed Mar 28 01:00:25 UTC 2012 Closed-Date: Last-Modified: Originator: Sean Bruno Release:9.0 Organization: Yahoo! Inc Environment: FreeBSD x 9.0-RELEASE FreeBSD 9.0-RELEASE #3: Tue Dec 27 14:14:29 PST 2011 r...@build9x64.pcbsd.org:/usr/obj/builds/amd64/pcbsd-build90/fbsd-source/9.0/sys/GENERIC amd64 Description: attempting to duplicate internal bug and loop in submitter There ... seems to be a bug in FreeBSD when specifying port number 0 in the socket address passed to the bind system call in order to let the kernel select a free port number. The semantics of SO_REUSEADDR is inconsistently implemented on FreeBSD. FreeBSD 4 jail environment (on a FreeBSD 4 host): dev-tegge:~$ ./bindbug serversock addr is 10.76.250.174:40328 dup bind: Address already in use This error was expected, tried to bind to used addr/port dup2 bind: Address already in use This error was expected, tried to bind to used port without SO_REUSEPORT autosock addr is 10.76.250.174:40328 bug triggered, port number conflict on sockets without SO_REUSEPORT listen succeded after implicitly overlapping port bind FreeBSD 6 host enironment: tegge-store1:~:$ ./bindbug serversock addr is 127.0.0.1:59073 dup bind: Address already in use This error was expected, tried to bind to used addr/port BUG: binding duplicate socket to server port succeeded dup2sock addr is 0.0.0.0:59073 overlapping explicit bind to same port number succeeded without SO_REUSEPORT listen succeeded after explicitly overlapping port bind autosock addr is 0.0.0.0:59073 bug triggered, port number conflict on sockets without SO_REUSEPORT listen succeded after implicitly overlapping port bind RHEL4 host environment: [tegge@dell-bl1s3 ~]$ time ./bindbug serversock addr is 127.0.0.1:43270 dup bind: Address already in use This error was expected, tried to bind to used addr/port dup2 bind: Address already in use This error was expected, tried to bind to used port without SO_REUSEPORT bug not triggered after 16777216 iterations real1m12.753s user0m4.695s sys 1m8.037s How-To-Repeat: Use test code that is attached, compile and run on a fbsd box vs a linux box. test case is at http://people.freebsd.org/~sbruno/bind_test.c 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
kern/166459: other id for atkbdc
Number: 166459
Category: kern
Synopsis: other id for atkbdc
Confidential: no
Severity: non-critical
Priority: medium
Responsible:freebsd-bugs
State: open
Quarter:
Keywords:
Date-Required:
Class: update
Submitter-Id: current-users
Arrival-Date: Wed Mar 28 01:40:08 UTC 2012
Closed-Date:
Last-Modified:
Originator: Kaho Toshikazu
Release:10-CURRENT
Organization:
Environment:
FreeBSD catsidhe.pf2.ed.niigata-u.ac.jp 10.0-CURRENT FreeBSD 10.0-CURRENT #4
r233525M: Tue Mar 27 12:48:27 UTC 2012
k...@pf2.ed.niigata-u.ac.jp:/usr/obj/usr/src/sys/SOIL i386
Description:
atkbdc_isa.c dosen't have a KBC id which is reported from acpi table on some
machines, and PS2 keyboard and mouse are not probed/attached.
`acpidump -dt` showed about KBC is :
Device (KBC)
{
Name (R101, 0x0303D041)
Name (R106, 0x2003D041)
Method (_HID, 0, NotSerialized)
{
If (SIDF)
{
Return (R101)
}
Else
{
Return (R106)
}
}
How-To-Repeat:
Boot FreeBSD 9/10 on some machines, PS2 keyboard and mouse do not do any jobs.
Fujitsu FMV-BIBLO LOOX T70S/V and Sharp PC-CV50 have the problem here, and
google shows some machines have similar acpi table.
Fix:
Add id.
Index: sys/dev/atkbdc/atkbdc_isa.c
===
--- sys/dev/atkbdc/atkbdc_isa.c (revision 233525)
+++ sys/dev/atkbdc/atkbdc_isa.c (working copy)
@@ -87,6 +87,7 @@
static struct isa_pnp_id atkbdc_ids[] = {
{ 0x0303d041, Keyboard controller (i8042) }, /* PNP0303 */
+ { 0x2003d041, Keyboard controller (i8042) }, /* PNP2003 */
{ 0 }
};
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
conf/166460: WITHOUT_IPFILTER does not remove ipfstat-reliant periodic scripts
Number: 166460
Category: conf
Synopsis: WITHOUT_IPFILTER does not remove ipfstat-reliant periodic
scripts
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: Wed Mar 28 02:00:22 UTC 2012
Closed-Date:
Last-Modified:
Originator: Jeremy Chadwick
Release:FreeBSD 8.2-STABLE amd64
Organization:
Environment:
System: FreeBSD icarus.home.lan 8.2-STABLE FreeBSD 8.2-STABLE #0: Fri Feb 10
17:43:50 PST 2012
r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64
Description:
First: not sure if I got the right Category. This might be kern
or misc.
Issue was discussed on freebsd-stable here:
http://lists.freebsd.org/pipermail/freebsd-stable/2012-March/066962.html
http://lists.freebsd.org/pipermail/freebsd-stable/2012-March/066978.html (root
cause)
When ipfilter is removed from the system via src.conf knob
WITHOUT_IPFILTER, periodic scripts which rely on ipfstat(8) do not
get removed during make delete-old. This results in errors
like the following during periodic security phase:
ipfstat: not found
Root cause appears to be lack of OLD_FILES entries for the two
periodic scripts in question. Patch should fix this. Only tested on
RELENG_8; other adjustments may be needed for RELENG_7 or RELENG_9.
Note that etc/periodic/security/610.ipf6denied is a tricky one: it's
both
IPFILTER-related *and* IPv6. So I'm not sure if this removal should go
under the MK_IPFILTER check or the MK_INET6 check.
How-To-Repeat:
1. Add WITHOUT_IPFILTER=true to /etc/src.conf
2. Rebuild system (world/kernel), mergemaster, etc... -- the usual
3. Run periodic security and watch for ipfstat: not found messages
Fix:
Apply below patch:
--- src/tools/build/mk/OptionalObsoleteFiles.inc.orig 2010-11-22
17:39:30.0 -0800
+++ src/tools/build/mk/OptionalObsoleteFiles.inc2012-03-27
18:56:15.167308202 -0700
@@ -605,6 +605,8 @@
OLD_FILES+=usr/share/man/man8/ipmon.8.gz
OLD_FILES+=usr/share/man/man8/ipnat.8.gz
OLD_FILES+=usr/share/man/man8/ippool.8.gz
+OLD_FILES+=etc/periodic/security/510.ipfdenied
+OLD_FILES+=etc/periodic/security/610.ipf6denied
.endif
.if ${MK_IPX} == no
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: conf/166460: WITHOUT_IPFILTER does not remove ipfstat-reliant periodic scripts
Synopsis: WITHOUT_IPFILTER does not remove ipfstat-reliant periodic scripts Responsible-Changed-From-To: freebsd-bugs-eadler Responsible-Changed-By: eadler Responsible-Changed-When: Wed Mar 28 02:41:43 UTC 2012 Responsible-Changed-Why: I'll take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=166460 ___ 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
kern/166462: gre(4) when using a tunnel source address from carp(4) doesn't honor the MASTER/BACKUP state
Number: 166462 Category: kern Synopsis: gre(4) when using a tunnel source address from carp(4) doesn't honor the MASTER/BACKUP state 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: Wed Mar 28 05:40:09 UTC 2012 Closed-Date: Last-Modified: Originator: Eugene M. Zheganin Release:8.2-RELEASE Organization: RealService LLC Environment: FreeBSD moscow-omega 8.2-RELEASE FreeBSD 8.2-RELEASE #5: Sat Mar 10 14:15:00 MSK 2012 emz@moscow-omega:/usr/obj/usr/src/sys/MOSCOW amd64 Description: When using a HA system of two nodes for corporate VPN I encountered a problem: Imagine node A and B share the same public ip address on their carp(4) interface. Imagine A and B have a gre(4) interface, and its tunnel source address is the carp(4) address. Imagine there is an ospf daemon running on those gre(4) interfaces. Then the OSPF neiborship will be constantly reestablished, because A and B will interfere with OSPF sessions of each other. This happens because both nodes will send a HELO packet, and the backup node isn't honoring its BACKUP state properly. How-To-Repeat: Build a setup mentioned above. Use OSPF or just try to send icmp packets via the tunnel from the BACKUP node. Fix: Use IPSEC with 'required' policies. This will prevent the backup node from establishing SA, thus preventing the tunnel from working. 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/166462: [gre] gre(4) when using a tunnel source address from carp(4) doesn't honor the MASTER/BACKUP state
Old Synopsis: gre(4) when using a tunnel source address from carp(4) doesn't honor the MASTER/BACKUP state New Synopsis: [gre] gre(4) when using a tunnel source address from carp(4) doesn't honor the MASTER/BACKUP state Responsible-Changed-From-To: freebsd-bugs-freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Mar 28 05:58:53 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=166462 ___ 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
