Re: kern/166866: [build] [cy] cy(4) driver breaks kernel build in 8.3
The following reply was made to PR kern/166866; it has been noted by GNATS. From: Eugene To: bug-follo...@freebsd.org, eugene...@mail.ru Cc: Subject: Re: kern/166866: [build] [cy] cy(4) driver breaks kernel build in 8.3 Date: Fri, 13 Apr 2012 12:42:13 +0400 In fact, this problem is described in UPDATING: 20080820: The TTY subsystem of the kernel has been replaced by a new implementation, which provides better scalability and an improved driver model. Most common drivers have been migrated to the new TTY subsystem, while others have not. The following drivers have not yet been ported to the new TTY layer: PCI/ISA: cy, digi, rc, rp, sio USB: ubser, ucycom Line disciplines: ng_h4, ng_tty, ppp, sl, snp Adding these drivers to your kernel configuration file shall cause compilation to fail. But "Hardware Notes" has all this devices listed as supported. Probably, this devices (except for ng_tty, which was updated in 20081225) must be marked as temporary unsupported until their drivers were fixed. Eugene mailto:eugene...@mail.ru ___ 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/147226: read(fd, buffer, len) returns -1 immediately, if len >=2147483648
>Number: 147226
>Category: kern
>Synopsis: read(fd, buffer, len) returns -1 immediately, if len
>>=2147483648
>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: Sun May 30 17:10:06 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Eugene
>Release:r200984M
>Organization:
>Environment:
FreeBSD lala.ru 7.2-STABLE FreeBSD 7.2-STABLE #0 r200984M: Fri Apr 23 16:54:24
MSD 2010
r...@lala.ru:/place/tmp/mk_pkg.2r1fojOn/obj/place/GIT-repos/FreeBSD-7-r11/sys/PRODUCTION
amd64
>Description:
read(3) returns -1 immediately, if we are trying to read more than 2Gb from
file.
>How-To-Repeat:
This code demonstrates the bug:
=
#include
#include
#include
#include
#include
#include
int main() {
const size_t bufferSize = 2L * (1 << 30L);
//works
//const size_t toRead = 2L * (1 << 30L) - 1 ;
//do not work
const size_t toRead = 2L * (1 << 30L) ;
fprintf(stderr, "%lu\n", bufferSize);
fprintf(stderr, "%lu\n", sizeof(size_t));
int fd = open("hostlog.dat", O_RDONLY);
char * buffer = (char*) malloc(bufferSize);
if(NULL == buffer) {
fprintf(stderr, "Cannot allocate\n");
abort();
};
ssize_t res = read(fd, buffer, toRead);
fprintf(stderr, "res = %ld\n", res);
free(buffer);
close(fd);
return res;
}
[kharito...@lala ~/bugfind]$ gcc44 -m64 -Wall ./do.c
[kharito...@lala ~/bugfind]$ ./a.out
2147483648
8
res = -1
[kharito...@lala ~/bugfind]$ ls -l ./hostlog.dat
-rw-rw-r-- 1 kharitonov dev 2346274816 28 May 21:14 ./hostlog.dat
>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: bin/61355: login(1) does not restore terminal ownership on exit
The following reply was made to PR bin/61355; it has been noted by GNATS. From: Eugene Grosbein To: bug-follo...@freebsd.org Cc: Subject: Re: bin/61355: login(1) does not restore terminal ownership on exit Date: Sun, 28 Apr 2013 19:56:57 +0700 Hi! Please note that this problem was first reported over 9 years ago. The problem is still here with 9.1-STABLE. However, visual effects has changed again. That's what do we have now. First, login via ssh as user "eugen": $ tty /dev/pts/1 $ w | grep pts/1 eugen pts/1eg.sd.rdtc.ru19:44 - grep pts/1 Than, use /usr/bin/login to become user "support": $ login support Password: FreeBSD 9.1-STABLE (K-45-MONITOR) #7: Thu Mar 28 16:18:06 NOVT 2013 ... Edit /etc/motd to change this login announcement. $ tty /dev/pts/1 $ w | grep pts/1 eugen pts/1eg.sd.rdtc.ru19:44 - grep pts/1 supportpts/1-19:46 - grep pts/1 In this version, login just added another record to utmp. That's just fine. Now leave nested session: $ exit logout $ w|grep pts/1 eugen pts/1eg.sd.rdtc.ru19:44 - grep pts/1 $ ls -l `tty` crw--w 1 support tty 0x96 28 ÁÐÒ 19:47 /dev/pts/1 $ screen Cannot open your terminal '/dev/pts/1' - please check. As you can see, original problem is still here: terminal ownership has not been restored. Eugene Grosbein ___ 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/180052: www/squid3x ports: some helpers are not built/installed
>Number: 180052 >Category: misc >Synopsis: www/squid3x ports: some helpers are not built/installed >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: Fri Jun 28 10:50:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Eugene Zheganin >Release:10.x-CURRENT >Organization: Vivat-Trade LLC >Environment: FreeBSD taiga 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r247150M: Mon Mar 4 17:57:07 YEKT 2013 emz@taiga:/usr/obj/usr/src/sys/TAIGADBG amd64 >Description: Selecting both [x] AUTH_KERB [x] AUTH_LDAP should add the "kerberos_ldap_group" helper to the "--enable-external-acl-helpers=" configure option, and the port should build/install this helper. This "a reference implementation that supports SASL/GSSAPI authentication to an ldap server. It is mainly intended to connect to Active Directory or Openldap based ldap servers." Thi is a very popular helper nowadays, it has a killer feature - it supports nested LDAP groups up to given nesting level, which is crucial in Windows/AD environment, where most of groups are usually nested". >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"
kern/180462: [lor] system freezes when I close something that is using lots of memory (?)
>Number: 180462 >Category: kern >Synopsis: [lor] system freezes when I close something that is using lots >of memory (?) >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: Thu Jul 11 12:00:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Eugene Zheganin >Release:10.0-CURRENT >Organization: Vivat-Trade LLC >Environment: FreeBSD bsdrookie.norma.com. 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r251990: Thu Jun 20 11:50:23 YEKT 2013 emz@:/usr/obj/usr/src/sys/GENERIC amd64 >Description: I'm using FreeBSD as a desktop in office. When I'm closing chrome web browser with lots of tabs, there's a probability that everything will hang (system becomes unresponsive via network, X freezes). Actually I did this like a dozen times for now, and only once I got a LOR (with a freeze for like 2 seconds) instead of a freeze. I think may be this LOR can be the place that's causing the freeze. here's what I got: lock order reversal: 1st 0xfe004635e4b0 vm object (vm object) @ /usr/src/sys/vm/vm_object.c:511 2nd 0xfe0003000180 vm map (system) (vm map (system)) @ /usr/src/sys/vm/vm_map.c:2871 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xff823943c310 kdb_backtrace() at kdb_backtrace+0x39/frame 0xff823943c3c0 witness_checkorder() at witness_checkorder+0xd4f/frame 0xff823943c450 __mtx_lock_flags() at __mtx_lock_flags+0x96/frame 0xff823943c490 vm_map_remove() at vm_map_remove+0x36/frame 0xff823943c4c0 uma_large_free() at uma_large_free+0x55/frame 0xff823943c4e0 free() at free+0x6f/frame 0xff823943c520 vm_object_terminate() at vm_object_terminate+0x1f8/frame 0xff823943c560 vm_object_deallocate() at vm_object_deallocate+0x462/frame 0xff823943c5c0 vm_map_process_deferred() at vm_map_process_deferred+0x89/frame 0xff823943c5f0 vm_map_remove() at vm_map_remove+0xc5/frame 0xff823943c620 vmspace_exit() at vmspace_exit+0xcd/frame 0xff823943c660 exit1() at exit1+0x52e/frame 0xff823943c6d0 sigexit() at sigexit+0xbb6/frame 0xff823943c970 postsig() at postsig+0x399/frame 0xff823943ca70 ast() at ast+0x337/frame 0xff823943cab0 doreti_ast() at doreti_ast+0x1f/frame 0x7f9fc8f0 >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"
misc/180916: [regression] jail startup is broken for 8.4 without INET6
>Number: 180916
>Category: misc
>Synopsis: [regression] jail startup is broken for 8.4 without INET6
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Mon Jul 29 04:20:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator: Eugene Grosbein
>Release:FreeBSD 8.4-STABLE i386
>Organization:
RDTC JSC
>Environment:
System: FreeBSD gw.delikates-nk.ru 8.4-STABLE FreeBSD 8.4-STABLE #2 r253704:
Sat Jul 27 23:15:32 NOVT 2013
r...@gw.delikates-nk.ru:/usr/local/obj/usr/local/src/sys/GW i386
>Description:
Upgrade from 8.3 to 8.4 breaks start of jails when kernel has not INET6
option.
>How-To-Repeat:
Build 8.4 with custom kernel without INET6, create and configure a jail
and run "service jail start", it fails to start it without descriptive
message.
The reason is that now it needs ip6.addr attribute missing for
INET4-only kernels.
This bug is fixed for 9-STABLE but not for 8.4
>Fix:
The patch made by Chris Rees helps:
http://lists.freebsd.org/pipermail/freebsd-jail/2012-November/001984.html
I've adjusted it for stable/8:
--- etc/rc.d/jail.orig 2013-07-27 22:37:03.0 +0700
+++ etc/rc.d/jail 2013-07-29 10:32:33.0 +0700
@@ -654,7 +654,8 @@
done
eval ${_setfib} jail -n ${_jail} ${_flags} -i -c
path=${_rootdir} host.hostname=${_hostname} \
- ip4.addr=\"${_addrl}\" ip6.addr=\"${_addr6l}\"
${_parameters} command=${_exec_start} > ${_tmp_jail} 2>&1
+ ${_addrl:+ip4.addr=\"${_addrl}\"}
${_addr6l:+ip6.addr=\"${_addr6l}\"} \
+ ${_parameters} command=${_exec_start} > ${_tmp_jail}
2>&1 \
if [ "$?" -eq 0 ] ; then
_jail_id=$(head -1 ${_tmp_jail})
>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/180918: [patch] [modules] stable/9 buildworld is broken with MODULES_WITH_WORLD=yes
>Number: 180918
>Category: misc
>Synopsis: [patch] [modules] stable/9 buildworld is broken with
>MODULES_WITH_WORLD=yes
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Mon Jul 29 05:50:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator: Eugene Grosbein
>Release:FreeBSD 9.1-STABLE amd64
>Organization:
RDTC JSC
>Environment:
System: FreeBSD k-45-monitor 9.1-STABLE FreeBSD 9.1-STABLE #9 r252026M: Thu Jun
20 20:09:10 NOVT 2013 root@k-45-monitor:/usr/obj/usr/local/src/sys/K-45-MONITOR
amd64
>Description:
make MODULES_WITH_WORLD=yes buildworld is broken for 9-STABLE:
===> sys/modules/ixgbe (depend)
machine -> /usr/local/src/sys/amd64/include
@ -> /usr/local/src/sys
x86 -> /usr/local/src/sys/x86/include
awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h
awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h
awk -f @/tools/makeobjops.awk @/kern/device_if.m -h
rm -f .depend
mkdep -f .depend -a -nostdinc -DSMP -DIXGBE_FDIR -D_KERNEL -DKLD_MODULE
-I/usr/local/src/sys/modules/ixgbe/../../dev/ixgbe -I
. -I@ -I@/contrib/altq -std=iso9899:1999
/usr/local/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c
/usr/local/src/sys/modules/
ixgbe/../../dev/ixgbe/ixv.c
/usr/local/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe_common.c
/usr/local/src/sys/modules/ixgbe/..
/../dev/ixgbe/ixgbe_api.c
/usr/local/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe_phy.c
/usr/local/src/sys/modules/ixgbe/../../d
ev/ixgbe/ixgbe_mbx.c
/usr/local/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe_vf.c
/usr/local/src/sys/modules/ixgbe/../../dev/ixg
be/ixgbe_dcb.c
/usr/local/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe_dcb_82598.c
/usr/local/src/sys/modules/ixgbe/../../dev/ix
gbe/ixgbe_dcb_82599.c
/usr/local/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe_82599.c
/usr/local/src/sys/modules/ixgbe/../../dev
/ixgbe/ixgbe_82598.c
/usr/local/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe_x540.c
/usr/local/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c:36:22: error:
opt_inet.h: No such file or directory
/usr/local/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c:37:23: error:
opt_inet6.h: No such file or directory
/usr/local/src/sys/modules/ixgbe/../../dev/ixgbe/ixv.c:35:22: error:
opt_inet.h: No such file or directory
/usr/local/src/sys/modules/ixgbe/../../dev/ixgbe/ixv.c:36:23: error:
opt_inet6.h: No such file or directory
mkdep: compile failed
*** [.depend] Error code 1
1 error
*** [depend] Error code 2
1 error
*** [depend] Error code 2
1 error
*** [sys.depend__D] Error code 2
Same for sys/modules/rdma/krping and sys/modules/toecore.
>How-To-Repeat:
See above.
>Fix:
--- sys/modules/ixgbe/Makefile.orig 2013-07-29 11:27:57.0 +0700
+++ sys/modules/ixgbe/Makefile 2013-07-29 11:58:20.0 +0700
@@ -7,6 +7,15 @@
SRCS+= ixgbe_common.c ixgbe_api.c ixgbe_phy.c ixgbe_mbx.c ixgbe_vf.c
SRCS+= ixgbe_dcb.c ixgbe_dcb_82598.c ixgbe_dcb_82599.c
SRCS+= ixgbe_82599.c ixgbe_82598.c ixgbe_x540.c
+SRCS += opt_inet.h opt_inet6.h
CFLAGS+= -I${.CURDIR}/../../dev/ixgbe -DSMP -DIXGBE_FDIR
+.if !defined(KERNBUILDDIR)
+opt_inet.h:
+ echo "#define INET 1" >> ${.TARGET}
+
+opt_inet6.h:
+ echo "#define INET6 1" >> ${.TARGET}
+.endif
+
.include
--- sys/modules/rdma/krping/Makefile.orig 2013-07-29 10:49:55.0
+0700
+++ sys/modules/rdma/krping/Makefile2013-07-29 12:05:47.0 +0700
@@ -5,8 +5,16 @@
KMOD= krping
SRCS= krping.c krping_dev.c getopt.c
-SRCS+= bus_if.h device_if.h opt_sched.h pci_if.h pcib_if.h
+SRCS+= bus_if.h device_if.h opt_inet.h opt_inet6.h opt_sched.h pci_if.h
pcib_if.h
SRCS+= vnode_if.h
CFLAGS+= -I${.CURDIR}/../../../ofed/include
+.if !defined(KERNBUILDDIR)
+opt_inet.h:
+ echo "#define INET 1" >> ${.TARGET}
+
+opt_inet6.h:
+ echo "#define INET6 1" >> ${.TARGET}
+.endif
+
.include
--- sys/modules/toecore/Makefile.orig 2013-07-29 12:09:18.0 +0700
+++ sys/modules/toecore/Makefile2013-07-29 12:09:57.0 +0700
@@ -4,6 +4,14 @@
KMOD= toecore
SRCS= toecore.c
-SRCS+= opt_ofed.h
+SRCS+= opt_inet.h opt_inet6.h opt_ofed.h
+
+.if !defined(KERNBUILDDIR)
+opt_inet.h:
+ echo "#define INET 1" >> ${.TARGET}
+
+opt_inet6.h:
+ echo "#define INET6 1" >> ${.TARGET}
+.endif
.include
>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/180966: snd_envy24: recording broken
>Number: 180966 >Category: kern >Synopsis: snd_envy24: recording broken >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 Jul 31 11:40:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Eugene Zheganin >Release:10.0-CURRENT >Organization: Vivat-Trade LLC >Environment: FreeBSD icecast.bolid.fm 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r253444: Thu Jul 18 17:25:07 YEKT 2013 emz@:/usr/obj/usr/src/sys/GENERIC amd64 >Description: I have an M-Audio Audiophile 24/96 board. While everything is fine while playing the sound, recording sound from the line-in gives distorted sound (like in VoIP when some frames are dropping, only in this case no clean sound can be heard at all). Attempted measures to resolve: - changing HZ from 1000 to 100 - changing HZ from 100 to 4000 - disabling virtual channels - changing dev.pcm.1.play.vchanrate/dev.pcm.1.play.vchanrate from 48000 to 41000 and back - enabling dev.pcm.0.bitperfect This didn't help, after some struggling I enabled the onboard hda card and got clean sound ot it's line-in. >How-To-Repeat: Try to record sound from snd_envy24(4) card. >Fix: Use snd_hda(4) for the purpose of sound recording. >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"
bin/181157: [ftpd] [patch] New login.conf(5) capability "ftp-chdir" for ftpd(8)
>Number: 181157 >Category: bin >Synopsis: [ftpd] [patch] New login.conf(5) capability "ftp-chdir" for >ftpd(8) >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Fri Aug 09 07:20:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Eugene Grosbein >Release:FreeBSD 9.2-BETA2 amd64 >Organization: RDTC JSC >Environment: System: FreeBSD k-45-monitor 9.2-BETA2 FreeBSD 9.2-BETA2 #10 r253755M: Mon Jul 29 12:39:55 NOVT 2013 root@k-45-monitor:/usr/obj/usr/local/src/sys/K-45-MONITOR amd64 >Description: ftpd(8) allows us to have chrooted users having initial working directory distinct from its home directory with "/home/user/./subdir" syntax in the passwd(5) file. This way changes notion of user's home directory for all other system utilities and may be undesirable. Let's make it possible for ftpd(8) to change user's initial working directory without messing with its home directory. The following patch introduces new string "ftp-chdir" capability in login.conf(5). For users having this capability ftpd(8) will change current directory to it instead of user's home directory upon successful authorization (and chroot(8), if needed). Thus, user's home directory may be kept intact in passwd(5), without "/./" hack. >How-To-Repeat: See above. >Fix: --- libexec/ftpd/ftpd.8.orig2013-06-18 14:52:20.0 +0700 +++ libexec/ftpd/ftpd.8 2013-08-09 13:35:24.0 +0700 @@ -472,6 +472,13 @@ can fill the drive with unwanted files. .El .Pp +Initial working directory may be automatically changed from user's +home directory to another one with the string "ftp-chdir" capability +in login.conf(5), unless user's home directory pathname contains the +.Pa /./ +separator, as described above (that setting has higher priority). +For chrooted users, "ftp-chdir" points to the directory below new root. +.Pp If the system has multiple IP addresses, .Nm supports the idea of virtual hosts, which provides the ability to --- libexec/ftpd/ftpd.c.orig2013-06-18 14:52:20.0 +0700 +++ libexec/ftpd/ftpd.c 2013-08-08 14:25:12.0 +0700 @@ -1553,7 +1553,11 @@ skip: * the old current directory will be accessible as "." * outside the new root! */ +#ifdef LOGIN_CAP + homedir = (char *) login_getcapstr(lc, "ftp-chdir", "/", "/"); +#else homedir = "/"; +#endif } /* * Finally, do chroot() --- lib/libutil/login.conf.5.orig 2013-08-09 13:36:01.0 +0700 +++ lib/libutil/login.conf.52013-08-09 13:37:33.0 +0700 @@ -225,6 +225,9 @@ See .Xr ftpd 8 for details. +.It "ftp-chdir string Initial working directory for FTP user. See +.Xr ftpd 8 +for details. .It "label string Default MAC policy; see .Xr maclabel 7 . .It "lang string Set $LANG environment variable to the specified value. >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/182212: [patch] [ng_mppc] ng_mppc(4) blocks on network errors unconditionaly
>Number: 182212
>Category: kern
>Synopsis: [patch] [ng_mppc] ng_mppc(4) blocks on network errors
>unconditionaly
>Confidential: no
>Severity: serious
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Wed Sep 18 19:30:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator: Eugene Grosbein
>Release:FreeBSD 8.4-STABLE amd64
>Organization:
RDTC JSC
>Environment:
System: FreeBSD eg.sd.rdtc.ru 8.4-STABLE FreeBSD 8.4-STABLE #2 r251830M: Mon
Jun 17 18:05:24 NOVT 2013
r...@eg.sd.rdtc.ru:/usr/local/obj/usr/local/src/sys/EG amd64
>Description:
Netgraph node ng_mppc(4) is used by mpd daemon to implement
MPPC/MPPE for Compression Control Protocol (CCP) used with various
PPP tunnels (pptp/l2tp/etc.)
This node blocks itself when "too many" packets got dropped in between
PPP peers and MPPE should do "re-keying". The threshold is hardcoded
in its code. The code considers "re-keying" as too CPU intensive task.
Thus, it tries to protect the box from DoS.
This code dates back to year 2000.
When such event occcurs, PPP tunnel hangs: CCP does not get reset,
IP packets cannot pass tunnel anymore but system interface "looks fine".
These days mpd runs on multi-MHZ and GHZ boxes and may be used
not for BRAS'es with lots of tunnels but to form VPN between a pair
of routers. In the latter case, manual reset of mpd link is required
to revive VPN tunnel.
>How-To-Repeat:
Run PPtP or L2TP tunnel between two mpd servers over WAN link
with non-zero amount of packet drops and/or packet rearrangements
having MPPC/MPPE enabled. Soon, you will get a message in the dmesg
buffer similar to:
ng_mppc_decompress: too many (4094) packets dropped, disabling node 0xc7020900!
Then tunnel just hangs until manually restarted as LCP echos
cannot detect this problem.
>Fix:
Let's system administrator decides if such behavour is needed.
The following patch introduces new sysctl subtree "net.graph.mppe"
with three read/write sysctls (each one is loader tunnable too):
net.graph.mppe.block_on_max_rekey - non-zero value means current behavour,
zero disables node block;
net.graph.mppe.mppe_log_max_rekey - non-zero value permits to write messages
to the log to notify of described event;
net.graph.mppe.max_rekey - allows to change the threshold.
By default, node block is prohibited and mpd just resets CCP
and tunnel continues to work. Mpd writes a line like this to its log:
CCP: SendResetReq #3 link 0 (Opened)
At the another side, next line is written to mpd log:
CCP: rec'd Reset Request #3 (Opened)
--- sys/netgraph/ng_mppc.c.orig 2013-04-07 01:07:27.0 +0700
+++ sys/netgraph/ng_mppc.c 2013-09-19 01:54:54.0 +0700
@@ -55,6 +55,7 @@
#include
#include
#include
+#include
#include
#include
@@ -107,6 +108,23 @@
*/
#define MPPE_MAX_REKEY 1000
+SYSCTL_NODE(_net_graph, OID_AUTO, mppe, CTLFLAG_RW, 0, "MPPE");
+
+static int mppe_block_on_max_rekey = 0;
+TUNABLE_INT("net.graph.mppe.block_on_max_rekey", &mppe_block_on_max_rekey);
+SYSCTL_INT(_net_graph_mppe, OID_AUTO, block_on_max_rekey, CTLFLAG_RW,
+&mppe_block_on_max_rekey, 0, "Block node on max MPPE key re-calculations");
+
+static int mppe_log_max_rekey = 1;
+TUNABLE_INT("net.graph.mppe.log_max_rekey", &mppe_log_max_rekey);
+SYSCTL_INT(_net_graph_mppe, OID_AUTO, log_max_rekey, CTLFLAG_RW,
+&mppe_log_max_rekey, 0, "Log max MPPE key re-calculations event");
+
+static int mppe_max_rekey = MPPE_MAX_REKEY;
+TUNABLE_INT("net.graph.mppe.max_rekey", &mppe_max_rekey);
+SYSCTL_INT(_net_graph_mppe, OID_AUTO, max_rekey, CTLFLAG_RW,
+&mppe_max_rekey, 0, "Maximum number of MPPE key re-calculations");
+
/* MPPC packet header bits */
#define MPPC_FLAG_FLUSHED 0x8000 /* xmitter reset state */
#define MPPC_FLAG_RESTART 0x4000 /* compress history restart */
@@ -651,12 +669,23 @@
/* How many times are we going to have to re-key? */
rekey = ((d->cfg.bits & MPPE_STATELESS) != 0) ?
numLost : (numLost / (MPPE_UPDATE_MASK + 1));
- if (rekey > MPPE_MAX_REKEY) {
- log(LOG_ERR, "%s: too many (%d) packets"
- " dropped, disabling node %p!",
- __func__, n
kern/182828: [patch] [igb] Revision 247430 broke outgoing interface stats for stable/8
>Number: 182828
>Category: kern
>Synopsis: [patch] [igb] Revision 247430 broke outgoing interface stats
>for stable/8
>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 Oct 08 12:40:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator: Eugene Grosbein
>Release:FreeBSD 8.4-STABLE amd64
>Organization:
RDTC JSC
>Environment:
System: FreeBSD eg.sd.rdtc.ru 8.4-STABLE FreeBSD 8.4-STABLE #3 r251830M: Mon
Sep 30 18:01:03 NOVT 2013
r...@eg.sd.rdtc.ru:/usr/local/obj/usr/local/src/sys/EG amd64
>Description:
There was r241037 commit by glebius@ to head fixing
"inaccurate overrated if_obytes accounting" in the HEAD:
http://svnweb.freebsd.org/base?view=revision&revision=241037
And there was _incomplete_ MFC to stable/8 r247430:
http://svnweb.freebsd.org/base?view=revision&revision=247430
r247430 contained some parts of r241037 but missed others vital
parts, so it introduced "inaccurate overrated if_obytes accounting"
to stable/8. For example, igb(4) now suffers from same problem.
>How-To-Repeat:
Run recent 8.4-STABLE with igb(4), make lots of outgoing traffic
and see that interface statistics is overrated.
>Fix:
Make mentioned MFC more complete. At least, merge
changes to sys/net/if_var.h to delete extra increase of if_obytes
and to sys/dev/oce/oce_if.c to fix last consumer
of drbr_stats_update() in stable/8:
--- sys/net/if_var.h2012/09/28 17:36:00 241036
+++ sys/net/if_var.h2012/09/28 18:28:27 241037
@@ -590,22 +590,10 @@
} while (0)
#ifdef _KERNEL
-static __inline void
-drbr_stats_update(struct ifnet *ifp, int len, int mflags)
-{
-#ifndef NO_SLOW_STATS
- ifp->if_obytes += len;
- if (mflags & M_MCAST)
- ifp->if_omcasts++;
-#endif
-}
-
static __inline int
drbr_enqueue(struct ifnet *ifp, struct buf_ring *br, struct mbuf *m)
{
int error = 0;
- int len = m->m_pkthdr.len;
- int mflags = m->m_flags;
#ifdef ALTQ
if (ALTQ_IS_ENABLED(&ifp->if_snd)) {
@@ -613,12 +601,10 @@
return (error);
}
#endif
- if ((error = buf_ring_enqueue_bytes(br, m, len)) == ENOBUFS) {
- br->br_drops++;
+ error = buf_ring_enqueue(br, m);
+ if (error)
m_freem(m);
- } else
- drbr_stats_update(ifp, len, mflags);
-
+
return (error);
}
--- sys/dev/oce/oce_if.c2012/09/28 17:36:00 241036
+++ sys/dev/oce/oce_if.c2012/09/28 18:28:27 241037
@@ -1183,7 +1183,9 @@
}
break;
}
- drbr_stats_update(ifp, next->m_pkthdr.len, next->m_flags);
+ ifp->if_obytes += next->m_pkthdr.len;
+ if (next->m_flags & M_MCAST)
+ ifp->if_omcasts++;
ETHER_BPF_MTAP(ifp, next);
next = drbr_dequeue(ifp, br);
}
Eugene Grosbein
>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/183817: [patch] [mac] [panic] kernel compiled with options INVARIANTS and MAC_PORTACL panices if loader loads mac_portacl.ko too
>Number: 183817 >Category: kern >Synopsis: [patch] [mac] [panic] kernel compiled with options INVARIANTS >and MAC_PORTACL panices if loader loads mac_portacl.ko too >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: Sat Nov 09 18:20:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Eugene Grosbein >Release:FreeBSD 9.2-STABLE amd64 >Organization: RDTC JSC >Environment: System: FreeBSD grosbein.net 9.2-STABLE FreeBSD 9.2-STABLE #5 r256953M: Sun Nov 10 00:52:12 NOVT 2013 r...@grosbein.net:/usr/obj/usr/local/src/sys/DADV amd64 >Description: If the kernel is compiled with options INVARIANTS and options MAC_PORTACL and /boot/loader.conf has "mac_portacl_load=YES" then kernel panices as soon as /etc/rc.d/initrandom script runs "sysctl -a" at boot time: http://www.grosbein.net/files/portacl.jpg >How-To-Repeat: Build custom kernel with options INVARIANTS and options MAC_PORTACL, have "mac_portacl_load=YES" in /boot/loader.conf and try to boot. >Fix: --- sys/security/mac/mac_policy.h.orig 2013-10-21 21:11:02.0 +0700 +++ sys/security/mac/mac_policy.h 2013-11-10 00:49:50.0 +0700 @@ -1021,6 +1021,7 @@ }; \ MODULE_DEPEND(mpname, kernel_mac_support, MAC_VERSION, \ MAC_VERSION, MAC_VERSION); \ + MODULE_VERSION(mpname, 1); \ DECLARE_MODULE(mpname, mpname##_mod, SI_SUB_MAC_POLICY, \ SI_ORDER_MIDDLE) >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/184176: [patch] [vimage] [kern] introduce new src.conf knob WITH_VIMAGE
>Number: 184176
>Category: kern
>Synopsis: [patch] [vimage] [kern] introduce new src.conf knob WITH_VIMAGE
>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: Fri Nov 22 19:40:02 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator: Eugene Grosbein
>Release:FreeBSD 9.2-STABLE amd64
>Organization:
RDTC JSC
>Environment:
System: FreeBSD grosbein.net 9.2-STABLE FreeBSD 9.2-STABLE #8 r256953M: Sat Nov
23 01:01:28 NOVT 2013 r...@grosbein.net:/usr/obj/usr/local/src/sys/DADV amd64
>Description:
Kernel modules ng_ether.ko and ng_gif.ko cannot be loaded
if kernel is built with options VIMAGE and modules are built
outside of kernel build enviroment (e.g. nanobsd & MODULES_WITH_WORLD):
# kldload ng_ether
kldload: can't load ng_ether: Exec format error
kernel: link_elf_obj: symbol ifnet undefined
kernel: linker_load_file: Unsupported file type
>How-To-Repeat:
See above.
>Fix:
Introduce new src.conf knob WITH_VIMAGE so modules can be built
for such kernel and loaded successfully.
--- tools/build/options/WITH_VIMAGE.orig2013-11-23 01:35:41.0
+0700
+++ tools/build/options/WITH_VIMAGE 2013-11-23 01:35:14.0 +0700
@@ -0,0 +1,2 @@
+.\" $FreeBSD$
+Set to build with the VIMAGE support.
--- share/mk/bsd.own.mk.orig2013-10-21 21:02:06.0 +0700
+++ share/mk/bsd.own.mk 2013-11-23 02:08:02.0 +0700
@@ -450,7 +450,8 @@
NMTREE \
OFED \
OPENSSH_NONE_CIPHER \
-SHARED_TOOLCHAIN
+SHARED_TOOLCHAIN \
+VIMAGE
#
# Default behaviour of some options depends on the architecture. Unfortunately
--- sys/modules/netgraph/ether/Makefile.orig2013-11-23 01:22:58.0
+0700
+++ sys/modules/netgraph/ether/Makefile 2013-11-23 02:18:37.0 +0700
@@ -4,3 +4,9 @@
SRCS= ng_ether.c
.include
+
+.if !defined(KERNBUILDDIR)
+.if ${MK_VIMAGE} != "no"
+CFLAGS+= -DVIMAGE
+.endif
+.endif
--- modules/netgraph/gif/Makefile.orig 2013-04-07 01:07:05.0 +0700
+++ modules/netgraph/gif/Makefile 2013-11-23 02:30:26.0 +0700
@@ -12,3 +12,9 @@
.endif
.include
+
+.if !defined(KERNBUILDDIR)
+.if ${MK_VIMAGE} != "no"
+CFLAGS+= -DVIMAGE
+.endif
+.endif
>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/184176: [patch] [vimage] [kern] introduce new src.conf knob WITH_VIMAGE
Forgot to note that tools/build/options/WITH_VIMAGE should be created also, containing two following lines: .\" $FreeBSD$ Set to build with the VIMAGE support. And regenerate src.conf(5) ___ 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/184176: [patch] [vimage] [kern] introduce new src.conf knob WITH_VIMAGE
The following reply was made to PR kern/184176; it has been noted by GNATS. From: Eugene Grosbein To: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org Cc: Subject: Re: kern/184176: [patch] [vimage] [kern] introduce new src.conf knob WITH_VIMAGE Date: Sat, 23 Nov 2013 03:02:08 +0700 Forgot to note that tools/build/options/WITH_VIMAGE should be created also, containing two following lines: .\" $FreeBSD$ Set to build with the VIMAGE support. And regenerate src.conf(5) ___ 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"
bin/186333: route(8) fails to return correct exit status in quiet mode
>Number: 186333
>Category: bin
>Synopsis: route(8) fails to return correct exit status in quiet mode
>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: Sat Feb 01 08:30:00 UTC 2014
>Closed-Date:
>Last-Modified:
>Originator: Eugene Grosbein
>Release:FreeBSD 9.2-STABLE amd64
>Organization:
RDTC JSC
>Environment:
System: FreeBSD grosbein.net 9.2-STABLE FreeBSD 9.2-STABLE #8 r256953M: Sat Nov
23 01:01:28 NOVT 2013 r...@grosbein.net:/usr/obj/usr/local/src/sys/DADV amd64
>Description:
Exit status of route(8) command in case of failure
depends of presence of '-q' flags: exit status is always 0 with '-q'.
>How-To-Repeat:
# route delete default
delete net default fib 0
# route -q change default 10.58.0.1; echo $?
route: writing to routing socket: No such process
0
# route change default 10.58.0.1; echo $?
route: writing to routing socket: No such process
change net default: gateway 10.58.0.1 fib 0: not in table
1
>Fix:
--- sbin/route/route.c.orig 2013-10-21 20:58:24.0 +0700
+++ sbin/route/route.c 2014-02-01 15:05:00.0 +0700
@@ -994,8 +994,8 @@ newroute(int argc, char **argv)
if (*cmd == 'g' || *cmd == 's')
exit(error);
- error = 0;
if (!qflag) {
+ error = 0;
fibnum = 0;
TAILQ_FOREACH(fl, &fibl_head, fl_next) {
if (fl->fl_error == 0)
@@ -1066,6 +1066,8 @@ newroute(int argc, char **argv)
}
}
}
+ else
+ error = -error;
exit(error);
}
>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/186362: [panic] _mtx_lock_sleep() misses check for NULL
>Number: 186362
>Category: kern
>Synopsis: [panic] _mtx_lock_sleep() misses check for NULL
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sun Feb 02 05:30:00 UTC 2014
>Closed-Date:
>Last-Modified:
>Originator: Eugene Grosbein
>Release:FreeBSD 9.2-STABLE amd64
>Organization:
RDTC JSC
>Environment:
System: FreeBSD grosbein.net 9.2-STABLE FreeBSD 9.2-STABLE #10 r256953M: Sat
Feb 1 17:35:38 NOVT 2014 r...@grosbein.net:/usr/obj/usr/local/src/sys/DADV amd64
>Description:
A function _mtx_lock_sleep() (sys/kern/kern_mutex.c) has a code:
#ifdef ADAPTIVE_MUTEXES
/*
* If the owner is running on another CPU, spin until the
* owner stops running or the state of the lock changes.
*/
v = m->mtx_lock;
if (v != MTX_UNOWNED) {
owner = (struct thread *)(v & ~MTX_FLAGMASK);
if (TD_IS_RUNNING(owner)) {
A macros TD_IS_RUNNING(owner) dereferences "owner" pointer
and there is no check for NULL. There is 100% repeatable test case
in which "owner" is always null, so this code panices kernel.
Kernel config file and crashdump info follow.
>How-To-Repeat:
1. Use kernel with options MAC (default in GENERIC) and
options ADAPTIVE_MUTEXES (not present in GENERIC).
2. Add mac_portacl_load="YES" to /boot/loader.conf
3. Run shell command security.mac.portacl.rules=uid:88:tcp:80
4. Observe a panic.
Here comes kgdb backtrace.
Script started on Sun Feb 2 12:04:59 2014
command: kgdb kernel.debug /var/crash/vmcore.7
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
Unread portion of the kernel message buffer:
Copyright (c) 1992-2013 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.2-STABLE #10 r256953M: Sat Feb 1 17:35:38 NOVT 2014
r...@grosbein.net:/usr/obj/usr/local/src/sys/DADV amd64
gcc version 4.2.1 20070831 patched [FreeBSD]
can't re-use a leaf (geom_cache)!
can't re-use a leaf (hwpstate_verbose)!
module_register: module cpu/ichss already exists!
Module cpu/ichss failed to register: 17
module_register: module g_cache already exists!
Module g_cache failed to register: 17
module_register: module mac_portacl already exists!
Module mac_portacl failed to register: 17
module_register: module cpu/coretemp already exists!
Module cpu/coretemp failed to register: 17
module_register: module cpu/powernow already exists!
Module cpu/powernow failed to register: 17
module_register: module cpu/est already exists!
Module cpu/est failed to register: 17
module_register: module cpu/hwpstate already exists!
Module cpu/hwpstate failed to register: 17
module_register: module cpu/p4tcc already exists!
Module cpu/p4tcc failed to register: 17
CPU: Intel(R) Pentium(R) D CPU 2.80GHz (2800.16-MHz K8-class CPU)
Origin = "GenuineIntel" Id = 0xf62 Family = 0xf Model = 0x6 Stepping = 2
Features=0xbfebfbff
Features2=0xe43d
AMD Features=0x20100800
AMD Features2=0x1
TSC: P-state invariant
real memory = 6442450944 (6144 MB)
avail memory = 6152839168 (5867 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table:
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
cpu0 (BSP): APIC ID: 0
cpu1 (AP): APIC ID: 1
Security policy loaded: TrustedBSD MAC/portacl (mac_portacl)
Security policy unload: TrustedBSD MAC/portacl (mac_portacl)
module_register_init: MOD_LOAD (mac_portacl, 0x8079c889,
0x80c074c0) error 17
WARNING: VIMAGE (virtualized network stack) is a highly experimental feature.
ioapic0: Changing APIC ID to 2
ioapic0 irqs 0-23 on motherboard
kbd1 at kbdmux0
cryptosoft0: on motherboard
acpi0: on motherboard
acpi0: Power Button (fixed)
cpu0: on acpi0
cpu1: on acpi0
atrtc0: port 0x70-0x71,0x74-0x77 irq 8 on acpi0
Event timer "RTC" frequency 32768 Hz quality 0
attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality
Re: kern/186362: [panic] _mtx_lock_sleep() misses check for NULL
The following reply was made to PR kern/186362; it has been noted by GNATS. From: Eugene Grosbein To: bug-follo...@freebsd.org Cc: Subject: Re: kern/186362: [panic] _mtx_lock_sleep() misses check for NULL Date: Sun, 02 Feb 2014 13:36:57 +0700 "How-To-Repeat" sequence, step 3 should be: 3. Run shell command "sysctl security.mac.portacl.rules=uid:88:tcp:80" ___ 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/186362: [panic] _mtx_lock_sleep() misses check for NULL
The following reply was made to PR kern/186362; it has been noted by GNATS. From: Eugene Grosbein To: Andriy Gapon Cc: bug-follo...@freebsd.org Subject: Re: kern/186362: [panic] _mtx_lock_sleep() misses check for NULL Date: Sun, 02 Feb 2014 20:54:24 +0700 On 02.02.2014 19:55, Andriy Gapon wrote: > > NULL check would be redundant there as it is already established that the > lock > is owned and thus must have an owner. > What seems to be happening that is that the thread is trying to acquire a > lock > that has been corrupted somehow. E.g. never initialized or its memory > location > overwritten. > > Better diagnostics for that case when INVARIANTS are enabled is warranted > though. > > Returning to the main issue, I wonder if the following message are related to > the problem: > > module_register: module mac_portacl already exists! > Module mac_portacl failed to register: 17 > > I seem to recall that in some cases our kernel module loading infrastructure > may > refuse to load a duplicate module, bu nevertheless re-resolve a symbol name > to > point to a symbol in the duplicate module rather than in the original. > Which is > a bug, of course. I've disabled loading of mac_portacl in loader.conf keeping options MAC_PORTACL in my kernel and panic is no more. Do you still need additional INVARIANTS-enabled debug info? Eugene Grosbein ___ 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/159345: [if_lagg] [panic] kernel with if_lagg compiled in panices at start if if_lagg.ko is loaded
>Number: 159345 >Category: kern >Synopsis: [if_lagg] [panic] kernel with if_lagg compiled in panices at >start if if_lagg.ko is loaded >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 Aug 01 06:40:04 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Eugene Grosbein >Release:FreeBSD 8.2-STABLE amd64 >Organization: RDTC JSC >Environment: FreeBSD 8.2-STABLE amd64 >Description: If kernel has both 'device lagg' compiled in and if_lagg_load="YES" in /boot/loader.conf, it panices before crashdump device configured: atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 Timecounters tick every 1.000 msec panic: lock "if_lagg list" 0x808d6e00 already initialized cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at 0x801a91da = db_trace_self_wrapper+0x2a kdb_backtrace() at 0x8031e117 = kdb_backtrace+0x37 panic() at 0x802ec48e = panic+0x27e lock_init() at 0x8031e99d = lock_init+0x5d lagg_modevent() at 0x808d225f = lagg_modevent+0x1f module_register_init() at 0x802dcb8d = module_register_init+0x7d mi_startup() at 0x802a7fc7 = mi_startup+0x77 btext() at 0x801631fc = btext+0x2c Uptime: 1s Cannot dump. Device not defined or unavailable. Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... >How-To-Repeat: Boot kernel with device lagg compiled in and have if_lagg_load="YES" in /boot/loader.conf >Fix: Unknown. Other modules do now behave so and instead of panic they just issue a warning. >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/159780: make sys/vfs_subr.c more jail-friendly (userland calling deprecated sysctl)
>Number: 159780
>Category: kern
>Synopsis: make sys/vfs_subr.c more jail-friendly (userland calling
>deprecated sysctl)
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Mon Aug 15 04:30:09 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator: Eugene Grosbein
>Release:FreeBSD 8.2-STABLE i386
>Organization:
RDTC JSC
>Environment:
System: FreeBSD eg.sd.rdtc.ru 8.2-STABLE FreeBSD 8.2-STABLE #30: Thu Aug 4
20:02:17 NOVST 2011 r...@eg.sd.rdtc.ru:/usr/local/obj/usr/local/src/sys/EG i386
>Description:
I run legacy setup of FreeBSD 4.11 inside jail under 7.4-STABLE,
it runs just fine but kernel spams dmesg buffer with prints:
WARNING: userland calling deprecated sysctl, please rebuild world
It should use log() and not printf() so the message may be filtered out.
Perhaps, this message may be skipped altogether if options COMPAT_4X is
used.
>How-To-Repeat:
I do not know what 4.11 binary calls old sysctl.
>Fix:
--- sys/kern/vfs_subr.c.orig2011-08-15 11:13:00.0 +0700
+++ sys/kern/vfs_subr.c 2011-08-15 11:14:21.0 +0700
@@ -3021,7 +3021,7 @@
struct vfsconf *vfsp;
struct xvfsconf xvfsp;
- printf("WARNING: userland calling deprecated sysctl, "
+ log(LOG_WARNING, "userland calling deprecated sysctl, "
"please rebuild world\n");
#if 1 || defined(COMPAT_PRELITE2)
>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"
bin/160339: [patch] fsck_ffs needs to check d_namlen for zero
>Number: 160339 >Category: bin >Synopsis: [patch] fsck_ffs needs to check d_namlen for zero >Confidential: no >Severity: serious >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Aug 31 16:50:06 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Eugene Grosbein >Release:FreeBSD 8.2-STABLE amd64 >Organization: RDTC JSC >Environment: System: FreeBSD grosbein.pp.ru 8.2-STABLE FreeBSD 8.2-STABLE #1: Fri Jul 1 18:08:55 NOVST 2011 r...@grosbein.pp.ru:/usr/local/obj/usr/local/src/sys/DADV amd64 >Description: fsck_ffs checks for directory entry is incomplete: it does not check if d_namlen is zero. OTOH, it checks if namlen > MAXNAMLEN while MAXNAMLEN is 255 and namlen is 8-bit quantity so this check is always false. This check is commented out in NetBSD's fsck_ffs and does not exists in OpenBSD's. But they both do not check for zero value. >How-To-Repeat: My /usr/local filesystem somehow got corrupted, one of subdirectories has a file with zero name length and fsck -y did not find this error. I was forced to apply the following patch and only then the error was corrected: ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames DIRECTORY CORRUPTED I=1531227 OWNER=root MODE=40755 SIZE=4608 MTIME=Aug 30 01:28 2011 DIR=/obj/usr/local/src/secure/lib/libssh SALVAGE? [yn] ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts LINK COUNT FILE I=24 OWNER=root MODE=100644 SIZE=892 MTIME=Sep 17 11:10 2010 COUNT 2 SHOULD BE 1 ADJUST? [yn] ** Phase 5 - Check Cyl groups 459580 files, 7411823 used, 7819495 free (105503 frags, 964249 blocks, 0.7% fragmentation) * FILE SYSTEM IS CLEAN * * FILE SYSTEM WAS MODIFIED * >Fix: --- sbin/fsck_ffs/dir.c.orig2011-08-31 22:54:23.0 +0700 +++ sbin/fsck_ffs/dir.c 2011-08-31 23:38:33.0 +0700 @@ -225,7 +225,7 @@ type = dp->d_type; if (dp->d_reclen < size || idesc->id_filesize < size || - namlen > MAXNAMLEN || + namlen == 0 || type > 15) goto bad; for (cp = dp->d_name, size = 0; size < namlen; size++) >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/160811: Cannot change gmirror provider priority in RELENG_7 (r196879)
>Number: 160811 >Category: kern >Synopsis: Cannot change gmirror provider priority in RELENG_7 (r196879) >Confidential: no >Severity: serious >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Sun Sep 18 21:30:10 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Eugene Grosbein >Release:FreeBSD 7 >Organization: RDTC JSC >Environment: System: FreeBSD 7.2-RELEASE >Description: When first of gmirror's drives in some old server started dying (read errors, SMART offline read test fails) I was forced to prepare new hardware to replace this 2-drive PATA system. But, it appears this is not possible to make final dumps of its file systems as dump(8) hangs the whole box while reading failing drive. I was going to switch gmirror to 'prefer' balance algorithm to disable reads from first drive. I could not achieve this as /sbin/gmirror in RELENG_7 does not allow to change provider priorities (both drives priorities are zeroes). >How-To-Repeat: gmirror(8) manual page shows no support for "gmirror -p" as in 8.x and 9.x branches due to missed SVN r196879 merge. >Fix: Please perform merge of r196879 to RELENG_7. I've did it manually, it applies cleanly and works just fine, I was able to make second drive more preferable with this change. Eugene Grosbein >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/161805: [panic] [arp] Repeatable panic in ARP code
>Number: 161805 >Category: kern >Synopsis: [panic] [arp] Repeatable panic in ARP code >Confidential: no >Severity: serious >Priority: high >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Oct 19 12:30:10 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Eugene Grosbein >Release:FreeBSD 8.2-STABLE i386 >Organization: RDTC JSC >Environment: System: FreeBSD gate.zonov.ru 8.2-STABLE FreeBSD 8.2-STABLE #0: Mon Oct 17 20:10:46 MSD 2011 r...@gate.zonov.ru:/data/obj/data/src/sys/Office-8 i386 >Description: This FreeBSD 8.2-STABLE/i386 system was built from RELENG_8 sources of 17 October 2011. It runs mpd-5.3 accepting PPtP connections with proxyarp enabled. It panices instantly when an user establishes PPtP connection and generates crashdump. >How-To-Repeat: Full rc.conf/mpd.conf/etc. are available on request. kgdb shows: Script started on Wed Oct 19 16:01:10 2011 kgdb /usr/obj/data/src/sys/Office-8/kernel.debug vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc09d7df9 stack pointer = 0x28:0xe80d09d4 frame pointer = 0x28:0xe80d0a04 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 2820 (arp) trap number = 12 panic: page fault cpuid = 1 Uptime: 52s Physical memory: 2031 MB Dumping 191 MB: 176 160 144 128 112 96 80 64 48 32 16 Reading symbols from /boot/kernel/dummynet.ko...Reading symbols from /boot/kernel/dummynet.ko.symbols...done. done. Loaded symbols for /boot/kernel/dummynet.ko Reading symbols from /boot/kernel/ng_socket.ko...Reading symbols from /boot/kernel/ng_socket.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_socket.ko Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /boot/kernel/netgraph.ko.symbols...done. done. Loaded symbols for /boot/kernel/netgraph.ko Reading symbols from /boot/kernel/ng_mppc.ko...Reading symbols from /boot/kernel/ng_mppc.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_mppc.ko Reading symbols from /boot/kernel/rc4.ko...Reading symbols from /boot/kernel/rc4.ko.symbols...done. done. Loaded symbols for /boot/kernel/rc4.ko Reading symbols from /boot/kernel/ng_ether.ko...Reading symbols from /boot/kernel/ng_ether.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_ether.ko Reading symbols from /boot/modules/ng_ipacct.ko...done. Loaded symbols for /boot/modules/ng_ipacct.ko Reading symbols from /boot/kernel/ng_tee.ko...Reading symbols from /boot/kernel/ng_tee.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_tee.ko Reading symbols from /boot/kernel/ng_pptpgre.ko...Reading symbols from /boot/kernel/ng_pptpgre.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_pptpgre.ko Reading symbols from /boot/kernel/ng_ksocket.ko...Reading symbols from /boot/kernel/ng_ksocket.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_ksocket.ko Reading symbols from /boot/kernel/ng_iface.ko...Reading symbols from /boot/kernel/ng_iface.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_iface.ko Reading symbols from /boot/kernel/ng_ppp.ko...Reading symbols from /boot/kernel/ng_ppp.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_ppp.ko Reading symbols from /boot/kernel/ng_tcpmss.ko...Reading symbols from /boot/kernel/ng_tcpmss.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_tcpmss.ko #0 doadump () at pcpu.h:231 231 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:231 #1 0xc08cd7a3 in boot (howto=260) at /data/src/sys/kern/kern_shutdown.c:441 #2 0xc08cda07 in panic (fmt=Variable "fmt" is not available. ) at /data/src/sys/kern/kern_shutdown.c:614 #3 0xc0c3aadc in trap_fatal (frame=0xe80d0994, eva=0) at /data/src/sys/i386/i386/trap.c:978 #4 0xc0c3ab79 in trap_pfault (frame=0xe80d0994, usermode=0, eva=0) at /data/src/sys/i386/i386/trap.c:840 #5 0xc0c3b859 in trap (frame=0xe80d0994) at /data/src/sys/i386/i386/trap.c:559 #6 0xc0c2216c in calltra
Re: kern/161805: [panic] [arp] Repeatable panic in ARP code
The following reply was made to PR kern/161805; it has been noted by GNATS. From: Eugene Grosbein To: bug-follo...@freebsd.org Cc: qin...@freebsd.org Subject: Re: kern/161805: [panic] [arp] Repeatable panic in ARP code Date: Wed, 19 Oct 2011 20:14:30 +0700 Hi! I've downgraded my kernel to tag=RELENG_8 date=2011.10.10.19.00.00, just before recent MFC to ARP code and panic disappeared. Eugene Grosbein ___ 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"
bin/162332: bsdlabel destroys partitions with indexes over 8
>Number: 162332 >Category: bin >Synopsis: bsdlabel destroys partitions with indexes over 8 >Confidential: no >Severity: serious >Priority: high >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Nov 06 14:10:05 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Eugene Grosbein >Release:FreeBSD 8.2-STABLE amd64 >Organization: RDTC JSC >Environment: System: FreeBSD grosbein.pp.ru 8.2-STABLE FreeBSD 8.2-STABLE #13: Sat Oct 22 20:07:08 NOVT 2011 r...@grosbein.pp.ru:/usr/local/obj/usr/local/src/sys/DADV amd64 >Description: GEOM now support upto 20 partitions within single BSD label. To raise default limit (8) one have to create label as such: gpart create -s BSD -n 20 ad0s1 But, "bsdlabel -e ad0s1" silently lowers limit down to 8 and destroys partitions numbered 9 (i) and more even if one exits an editor without saving the label. >How-To-Repeat: 1. Create BSD label with command mentioned above: gpart create -s BSD -n 20 ad0s1 2. Use gpart to create 9 partitions within a slice: gpart add -t freebsd-ufs -s 1G ad0s1 ... gpart add -t freebsd-ufs -s 1G ad0s1 3. Use "gpart show" to make sure they are all created 4. Use "bsdlabel -e ad0s1", don't change anything and exit your editor. 5. Use "gpart show" to see that partition 9 has disappeared. 6. "gpart add" not refuses to recreate partition 9 as limit is 8 now. >Fix: Unknown. Silent partition deletion in not acceptable, as well as changing of limit. >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"
bin/162468: expr(1) false syntax errors
>Number: 162468 >Category: bin >Synopsis: expr(1) false syntax errors >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: Fri Nov 11 09:10:06 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Eugene Grosbein >Release:FreeBSD 8.2-STABLE i386 >Organization: RDTC JSC >Environment: System: FreeBSD eg.sd.rdtc.ru 8.2-STABLE FreeBSD 8.2-STABLE #35: Thu Sep 29 14:35:55 NOVT 2011 r...@eg.sd.rdtc.ru:/usr/local/obj/usr/local/src/sys/EG i386 >Description: The following command fails: # expr '>' : '.*' expr: syntax error It should return 1 (the length of the string '>') instead. Note that Linux's expr does right thing. >How-To-Repeat: See above. >Fix: Unknown. It seems our expr threats '>' and operator and not as operand for ':' operator. >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: bin/162468: expr(1) false syntax errors
The following reply was made to PR bin/162468; it has been noted by GNATS.
From: Eugene Grosbein
To: Jilles Tjoelker
Cc: bug-follo...@freebsd.org
Subject: Re: bin/162468: expr(1) false syntax errors
Date: Sat, 12 Nov 2011 01:58:55 +0700
11.11.2011 22:44, Jilles Tjoelker ÐÉÛÅÔ:
>> [expr treats any string that looks like an operator as an operator,
>> for example, expr '>' : '.*' fails]
>
> The current behaviour of expr is allowed by POSIX (SUSv4, XCU 4
> Utilities, expr). If the application passes '>', this is not a string
> operand but an operator, even if that results in an invalid expression.
> This is also documented in the man page.
Yes. But I have reports that that NetBSD's and Linux's expr(1)
both work as expected.
> It would be a valid extension to allow such expressions but it is not
> immediately clear how it would work. For example, should
> expr \( = \)
> compare two strings ("0") or return a single string ("=")? And should
> expr \( + \)
> return "+" or raise an error?
It would be wise to take a look at more robust expr(1) implementations
and try to keep compatibility.
> The test utility is different in that POSIX specifies how a similar
> ambiguity shall be resolved (for a limited set of cases).
>
> Oh, and if you want to find a string length in a shell script, why don't
> you just use
> ${#VAR}
> (given that the string is in $VAR)? If you must use expr(1), do
> expr \( "x$VAR" : '.*' \) - 1
> as described in the man page.
That's just a simple test case. In fact, I need not string length
but evaluate regexp that has ()'s:
read string < file
expr -- "$string" : 'Key: \(.*\)'
Then $string starts with '>' this fails (and $string may start with '>').
I've found a workaround: expr -- "x$string" : 'xKey: \(.*\)'
But that's only workaround, not good solution.
Eugene Grosbein
___
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/162558: [panic] seldom dummynet panics
>Number: 162558 >Category: kern >Synopsis: [panic] seldom dummynet panics >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Nov 14 10:00:23 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Eugene Grosbein >Release:FreeBSD 8.2-STABLE amd64 >Organization: RDTC JSC >Environment: System: FreeBSD k-45-pc-2.sd.rdtc.ru 8.2-STABLE FreeBSD 8.2-STABLE #2: Tue Oct 18 16:20:05 NOVT 2011 r...@k-45-pc-1.sd.rdtc.ru:/usr/local/obj/nanobsd.pppoe/home/src/sys/PPPOE8 amd64 >Description: My high loaded PPPoE servers (mpd-5.5) panic seldom in dummynet code. Last time they were updated to 8.2-STABLE/amd64 18 October 2011 and today I've got another panic. These panic generate crashdumps but kgdb just cannot read them for unknown reason: # kgdb kernel.debug /path/to/vmcore.1 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Cannot access memory at address 0x746c75616620 (kgdb) bt #0 0x in ?? () Cannot access memory at address 0x0 I've remote console also and at the moment of panic it shows: ipfw: pullup failed ipfw: pullup failed ipfw: pullup failed ipfw: pullup failed ipfw: pullup failed ipfw: pullup failed Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x308 fault code = supervisor read data, page not present instruction pointer = 0x20:0x802e7657 stack pointer = 0x28:0xff81229e1970 frame pointer = 0x28:0xff81229e1990 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (dummynet) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at 0x801ab1ca = db_trace_self_wrapper+0x2a kdb_backtrace() at 0x803294a7 = kdb_backtrace+0x37 panic() at 0x802f69ee = panic+0x27e trap_fatal() at 0x804ddc00 = trap_fatal+0x290 trap_pfault() at 0x804ddfdf = trap_pfault+0x28f trap() at 0x804de4bf = trap+0x3df calltrap() at 0x804c5b74 = calltrap+0x8 --- trap 0xc, rip = 0x802e7657, rsp = 0xff81229e1970, rbp = 0xff81229e1990 --- _mtx_lock_sleep() at 0x802e7657 = _mtx_lock_sleep+0x67 igmp_input() at 0x803dbc2d = igmp_input+0xf8d ip_input() at 0x803fca3d = ip_input+0xad netisr_dispatch_src() at 0x803bab7e = netisr_dispatch_src+0x7e dummynet_send() at 0x803ee18e = dummynet_send+0x14e dummynet_task() at 0x803ee386 = dummynet_task+0x1c6 taskqueue_run_locked() at 0x80335885 = taskqueue_run_locked+0x85 taskqueue_thread_loop() at 0x80335a1e = taskqueue_thread_loop+0x4e fork_exit() at 0x802cab0f = fork_exit+0x11f fork_trampoline() at 0x804c60be = fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff81229e1d00, rbp = 0 --- Uptime: 27d16h2m57s Dumping 871 out of 4079 MB:..2%..12%..21%..32%..41%..52%..61%..72%..81%..92% Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... >How-To-Repeat: Panics occur seldom, about 6 weeks between them. This panic occured in a hour of least load. I use dummynet actively to rate-limits users: every user get its own pair of dynamic dummynet pipes for local traffic and another pair for external traffic: ipfw add 1010 pipe tablarg ip from $mynets to 'table(13)' in recv $uplink ipfw add 1020 pipe tablarg ip from 'table(14)' to $mynets in recv 'ng*' ipfw add 1022 pipe 1 ip from $mynets to any in recv $uplink ipfw add 1024 pipe 3 ip from any to $mynets in recv 'ng*' ipfw add 5000 pipe tablearg ip from any to 'table(11)' in ipfw add 5010 pipe tablearg ip from 'table(12)' to any in Here is my /etc/sysctl.conf tuning for dummynet: net.inet.ip.dummynet.pipe_slot_limit=1000 net.inet.ip.dummynet.io_fast=1 net.inet.ip.fw.one_pass: 1 All my pipes have queue length 1000 and 64 buckets and distinct bandwidth and burst values. >Fix: Unknown. >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/163464: Invalid compiler flag in /sys/conf/kern.mk
>Number: 163464
>Category: kern
>Synopsis: Invalid compiler flag in /sys/conf/kern.mk
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Mon Dec 19 23:30:12 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator: Eugene Varnavsky
>Release:8.2
>Organization:
>Environment:
8.2-RELEASE-p3 FreeBSD 8.2-RELEASE-p3 #0: Tue Sep 27 18:45:57 UTC 2011
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
>Description:
/sys/conf/kern.mk:
CWARNFLAGS?= -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes \
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
\
${_wundef} ${_Wno_pointer_sign} -fformat-extensions
-fformat-extensions parameter is invalid, does not present in GCC 4.2 docs and
is not accepted (with error) by GCC 4.6
>How-To-Repeat:
Install custom GCC as described in handbook:
http://www.freebsd.org/doc/en/articles/custom-gcc/article.html
try to compile one of the ports that uses kernel sources:
# cd /usr/ports/emulators/open-vm-tools
# make
>Fix:
Remove the '-fformat-extensions' from string 15 of /sys/conf/kern.mk
>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/163525: 8.2-STABLE buildworld broken due to non-existing MK_INET_SUPPORT
>Number: 163525
>Category: misc
>Synopsis: 8.2-STABLE buildworld broken due to non-existing
>MK_INET_SUPPORT
>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: Thu Dec 22 09:50:09 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator: Eugene Grosbein
>Release:FreeBSD 8.2-STABLE i386
>Organization:
RDTC JSC
>Environment:
System: FreeBSD eg.sd.rdtc.ru 8.2-STABLE FreeBSD 8.2-STABLE #35: Thu Sep 29
14:35:55 NOVT 2011 r...@eg.sd.rdtc.ru:/usr/local/obj/usr/local/src/sys/EG i386
>Description:
For 8.2-STABLE, "make MODULES_WITH_WORLD=yes buildworld" fails:
===> sys/modules/netgraph/ipfw (cleandir)
"/usr/local/src/sys/modules/netgraph/ipfw/Makefile", line 10: Malformed
conditional (${MK_INET_SUPPORT} ! = "no")
"/usr/local/src/sys/modules/netgraph/ipfw/Makefile", line 18: if-less endif
make: fatal errors encountered -- cannot continue
This is because MK_INET_SUPPORT was not MFC'd to RELENG_8.
>How-To-Repeat:
See above.
>Fix:
Either perform MFC for MK_INET_SUPPORT to RELENG_8
or fix sys/modules/netgraph/ipfw/Makefile to not use it.
Eugene Grosbein
>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/163623: [kern] sysctl net.inet.icmp.icmplim_output description is misleading
>Number: 163623 >Category: kern >Synopsis: [kern] sysctl net.inet.icmp.icmplim_output description is >misleading >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 Dec 26 05:40:12 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Eugene Grosbein >Release:FreeBSD 8.2-STABLE i386 >Organization: RDTC JSC >Environment: System: FreeBSD eg.sd.rdtc.ru 8.2-STABLE FreeBSD 8.2-STABLE #36: Fri Dec 23 15:04:05 NOVT 2011 r...@eg.sd.rdtc.ru:/usr/local/obj/usr/local/src/sys/EG i386 >Description: "sysctl -d net.inet.icmp.icmplim_output" says: net.inet.icmp.icmplim_output: Enable rate limiting of ICMP responses In fact, this setting does not control rate limiting of ICMP responses. Instead, it controls whether kernel writes log messages about this limiting or not. >How-To-Repeat: See above. >Fix: Change wording in src/sys/netinet/ip_icmp.c for this setting. >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/163525: 8.2-STABLE buildworld broken due to non-existing MK_INET_SUPPORT
16.01.2012 08:30, lini...@freebsd.org пишет: > Synopsis: 8.2-STABLE buildworld broken due to non-existing MK_INET_SUPPORT > > State-Changed-From-To: open->feedback > State-Changed-By: linimon > State-Changed-When: Mon Jan 16 01:30:37 UTC 2012 > State-Changed-Why: > Has this problem been resolved? > > http://www.freebsd.org/cgi/query-pr.cgi?pr=163525 Yes, it has been resolved, world builds just fine in this mode. Thank you, the PR should be closed. Eugene Grosbein ___ 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/139271: [pci] [patch] sysutils/hpacucli does not work on the amd64 kernel
The following reply was made to PR kern/139271; it has been noted by GNATS.
From: Eugene Grosbein
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/139271: [pci] [patch] sysutils/hpacucli does not work on
the amd64 kernel
Date: Mon, 06 Feb 2012 12:36:29 +0700
This is a multi-part message in MIME format.
--050604090701010107000907
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi!
Here is same patch modified for 8.2-STABLE/amd64:
COMPAT_IA32 replaced with COMPAT_FREEBSD32, no other changes.
Work just fine with my HP SmartArray P400i.
Please commit.
Eugene Grosbein
--050604090701010107000907
Content-Type: text/plain;
name="pci_user.c.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="pci_user.c.diff"
--- sys/dev/pci/pci_user.c.orig2009-09-19 16:13:10.0 +0800
+++ sys/dev/pci/pci_user.c 2012-02-04 01:52:50.0 +0700
@@ -225,6 +225,49 @@
u_int32_t pi_data;/* data to write or result of read */
};
+#ifdef COMPAT_FREEBSD32
+struct pci_conf_old32 {
+ struct pcisel_old pc_sel; /* bus+slot+function */
+ u_int8_tpc_hdr; /* PCI header type */
+ u_int16_t pc_subvendor; /* card vendor ID */
+ u_int16_t pc_subdevice; /* card device ID, assigned by
+ card vendor */
+ u_int16_t pc_vendor; /* chip vendor ID */
+ u_int16_t pc_device; /* chip device ID, assigned by
+ chip vendor */
+ u_int8_tpc_class; /* chip PCI class */
+ u_int8_tpc_subclass;/* chip PCI subclass */
+ u_int8_tpc_progif; /* chip PCI programming interface */
+ u_int8_tpc_revid; /* chip revision ID */
+ charpd_name[PCI_MAXNAMELEN + 1]; /* device name */
+ u_int32_t pd_unit;/* device unit number (u_long) */
+};
+
+struct pci_match_conf_old32 {
+ struct pcisel_old pc_sel; /* bus+slot+function */
+ charpd_name[PCI_MAXNAMELEN + 1]; /* device name */
+ u_int32_t pd_unit;/* Unit number (u_long) */
+ u_int16_t pc_vendor; /* PCI Vendor ID */
+ u_int16_t pc_device; /* PCI Device ID */
+ u_int8_tpc_class; /* PCI class */
+ pci_getconf_flags_old flags; /* Matching expression */
+};
+
+struct pci_conf_io32 {
+ u_int32_t pat_buf_len;/* pattern buffer length */
+ u_int32_t num_patterns; /* number of patterns */
+ u_int32_t patterns; /* pattern buffer (struct
pci_match_conf_old32 *) */
+ u_int32_t match_buf_len; /* match buffer length */
+ u_int32_t num_matches;/* number of matches returned
*/
+ u_int32_t matches;/* match buffer (struct
pci_conf_old32 *) */
+ u_int32_t offset; /* offset into device list */
+ u_int32_t generation; /* device list generation */
+ pci_getconf_status status; /* request status */
+};
+
+#definePCIOCGETCONF_OLD32 _IOWR('p', 1, struct pci_conf_io32)
+#endif
+
#define PCIOCGETCONF_OLD_IOWR('p', 1, struct pci_conf_io)
#define PCIOCREAD_OLD _IOWR('p', 2, struct pci_io_old)
#define PCIOCWRITE_OLD _IOWR('p', 3, struct pci_io_old)
@@ -295,6 +338,69 @@
return(1);
}
+static int
+pci_conf_match_old32(struct pci_match_conf_old32 *matches, int num_matches,
+struct pci_conf *match_buf)
+{
+ int i;
+
+ if ((matches == NULL) || (match_buf == NULL) || (num_matches <= 0))
+ return(1);
+
+ for (i = 0; i < num_matches; i++) {
+ if (match_buf->pc_sel.pc_domain != 0)
+ continue;
+
+ /*
+* I'm not sure why someone would do this...but...
+*/
+ if (matches[i].flags == PCI_GETCONF_NO_MATCH_OLD)
+ continue;
+
+ /*
+* Look at each of the match flags. If it's set, do the
+* comparison. If the comparison fails, we don't have a
+* match, go on to the next item if there is one.
+*/
+ if (((matches[i].flags & PCI_GETCONF_MATCH_BUS_OLD) != 0)
+&& (match_buf->pc_sel.pc_bus != matches[i].pc_sel.pc_bus))
+ continue;
+
+ if (((matches[i].flags & PCI_GETCONF_MATCH_DEV_OLD) != 0)
+
kern/164901: [regression] [patch] [lagg] igb/lagg poor traffic distribution
>Number: 164901
>Category: kern
>Synopsis: [regression] [patch] [lagg] igb/lagg poor traffic distribution
>Confidential: no
>Severity: serious
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Wed Feb 08 09:00:20 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Eugene Grosbein
>Release:FreeBSD 8.2-STABLE i386
>Organization:
RDTC JSC
>Environment:
System: FreeBSD eg.sd.rdtc.ru 8.2-STABLE FreeBSD 8.2-STABLE #36: Fri Dec 23
15:04:05 NOVT 2011 r...@eg.sd.rdtc.ru:/usr/local/obj/usr/local/src/sys/EG i386
>Description:
Suppose, we have a router (BRAS) using two lagg(4) interfaces in LACP
mode.
Two-port lagg0 has IP address and its ports carry untagged IPoE frames.
lagg1 has no IP address and has two ports (82576-based igb0 and igb1)
that carry 1000 dot-q vlans with PPPoE frames only.
In RELENG_7, lagg(4) evenly distributes traffic going from lagg1 to
lagg0.
Since 8.0-RELEASE all this traffic goes out through one of lagg0's
ports only.
82576-based NICs and igb(4) support Microsoft Receive-Side Scaling
(RSS),
see
http://download.intel.com/design/network/datashts/82576_Datasheet.pdf
RSS states that queue number for non-IP frames (PPPoE/GRE/etc.)
is not computed with hash. So, all these frames get same (zero)
queue number and igb(4) assigns tag M_FLOWID=0 to mbufs.
Since 8.0-RELEASE, lagg(4) skips its own hash computation for mbuts
having M_FLOWID tag attached. Hence, it directs all such traffic
to its first port only in this setup.
>How-To-Repeat:
See above.
>Fix:
The following patch fixes the regression by introducing new sysctls
that disable usage of M_FLOWID per lagg interface:
net.link.lagg.0.use_flowid
net.link.lagg.1.use_flowid
Default value is 1 that corresponds to current behaviour of lagg(4).
To fix our issue, we set net.link.lagg.0.use_flowid=0
that restores pre-8 behaviour for lagg0 only, so it ignores misleading
M_FLOWID assigned to mbufs by lagg1's ports.
--- sys/net/if_lagg.h.orig 2010-12-27 12:59:59.0 +0600
+++ sys/net/if_lagg.h 2012-01-23 16:34:15.0 +0700
@@ -21,6 +21,8 @@
#ifndef _NET_LAGG_H
#define _NET_LAGG_H
+#include
+
/*
* Global definitions
*/
@@ -202,6 +204,8 @@ struct lagg_softc {
eventhandler_tag vlan_attach;
eventhandler_tag vlan_detach;
#endif
+ struct sysctl_ctx_list ctx;/* sysctl variables */
+ int use_flowid; /* use M_FLOWID */
};
struct lagg_port {
--- sys/net/if_lagg.c.orig 2011-08-08 19:16:42.0 +0700
+++ sys/net/if_lagg.c 2012-01-23 16:33:04.0 +0700
@@ -257,6 +257,8 @@ lagg_clone_create(struct if_clone *ifc,
struct ifnet *ifp;
int i, error = 0;
static const u_char eaddr[6]; /* 00:00:00:00:00:00 */
+ struct sysctl_oid *oid;
+ char num[14]; /* sufficient for 32 bits */
sc = malloc(sizeof(*sc), M_DEVBUF, M_WAITOK|M_ZERO);
ifp = sc->sc_ifp = if_alloc(IFT_ETHER);
@@ -265,6 +267,15 @@ lagg_clone_create(struct if_clone *ifc,
return (ENOSPC);
}
+ sysctl_ctx_init(&sc->ctx);
+ snprintf(num, sizeof(num), "%u", unit);
+ sc->use_flowid = 1;
+ oid = SYSCTL_ADD_NODE(&sc->ctx, &SYSCTL_NODE_CHILDREN(_net_link, lagg),
+ OID_AUTO, num, CTLFLAG_RD, NULL, "");
+ SYSCTL_ADD_INT(&sc->ctx, SYSCTL_CHILDREN(oid), OID_AUTO,
+ "use_flowid", CTLTYPE_INT|CTLFLAG_RW, &sc->use_flowid,
sc->use_flowid,
+ "Use flow id for load sharing");
+
sc->sc_proto = LAGG_PROTO_NONE;
for (i = 0; lagg_protos[i].ti_proto != LAGG_PROTO_NONE; i++) {
if (lagg_protos[i].ti_proto == LAGG_PROTO_DEFAULT) {
@@ -344,6 +355,7 @@ lagg_clone_destroy(struct ifnet *ifp)
LAGG_WUNLOCK(sc);
+ sysctl_ctx_free(&sc->ctx);
ifmedia_removeall(&sc->sc_media);
ether_ifdetach(ifp);
if_free_type(ifp, IFT_ETHER);
@@ -1668,7 +1680,7 @@ lagg_lb_start(struct lagg_softc *sc, str
struct lagg_port *lp = NULL;
uint32_t p = 0;
- if (m->m_flags & M_FLOWID)
+ if (sc->use_flowid && (m->m_flags & M_FLOWID))
p = m->m_pkthdr.flowid;
else
p = lagg_hashmbuf(m, lb->lb_key);
--- sys/net/ieee8023ad_lacp.c.orig 2009-08-03 16:13:06.0 +0800
+++ sys/net/ieee8023ad_lacp.c 2012-01-23 13:44:00.0 +0700
@@ -812,7
Re: misc/165085: nanobsd building broken
The following reply was made to PR misc/165085; it has been noted by GNATS. From: Eugene Grosbein To: bug-follo...@freebsd.org Cc: Subject: Re: misc/165085: nanobsd building broken Date: Mon, 13 Feb 2012 16:00:07 +0700 Hi! The first nanobsd build should be done without '-b' or '-w' options, so it can populate its obj directory for installworld/installkernel. This PR should be closed as case of pilot error. Eugene Grosbein ___ 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/165174: [patch] [tap] allow tap(4) to keep its address on close
>Number: 165174
>Category: kern
>Synopsis: [patch] [tap] allow tap(4) to keep its address on close
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Wed Feb 15 12:00:20 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Eugene Grosbein
>Release:FreeBSD 8.2-STABLE i386
>Organization:
RDTC JSC
>Environment:
System: FreeBSD eg.sd.rdtc.ru 8.2-STABLE FreeBSD 8.2-STABLE #37: Wed Feb 15
14:22:03 NOVT 2012 r...@eg.sd.rdtc.ru:/usr/local/obj/usr/local/src/sys/EG i386
>Description:
I routinely start, run and close several VirtualBox-controlled
virtual machines within FreeBSD. These machines use tap(4)-based
networking. tap interfaces are configured in /etc/rc.conf
just like all other interfaces:
cloned_interfaces="tap0 tap1 tap2"
ifconfig_tap0="inet 192.168.254.1/29"
ifconfig_tap1="inet 192.168.254.17/28"
ifconfig_tap2="inet 192.168.254.9/29"
Each machine uses its own tapX. VirtualBox runs as non-root user
with help of /etc/sysctl.conf:
net.link.tap.user_open=1
net.link.tap.up_on_open=1
This works for first start of each VM only as tap(4) driver
removes interface addresses of tapX on close. Very inconvinient.
>How-To-Repeat:
Create tap0 with ifconfig, run an application working with tap0,
restart the application and its networking fails.
>Fix:
The following patch introduces new per-interface sysctls
that may be used to keep addresses of tap interfaces
and interfaces itself up on close:
net.link.tap.0.keep_up=1
net.link.tap.1.keep_up=1
net.link.tap.2.keep_up=1
Default value is 0 and corresponds to current behaviour.
The patch updates manual page too.
--- sys/net/if_tapvar.h.orig2012-02-15 13:35:31.0 +0700
+++ sys/net/if_tapvar.h 2012-02-15 14:06:40.0 +0700
@@ -41,6 +41,8 @@
#ifndef _NET_IF_TAPVAR_H_
#define _NET_IF_TAPVAR_H_
+#include
+
/*
* tap_mtx locks tap_flags, tap_pid. tap_next locked with global tapmtx.
* Other fields locked by owning subsystems.
@@ -64,6 +66,9 @@ struct tap_softc {
SLIST_ENTRY(tap_softc) tap_next; /* next device in chain */
struct cdev *tap_dev;
struct mtx tap_mtx; /* per-softc mutex */
+
+ struct sysctl_ctx_list ctx;/* sysctl variables */
+ int keep_up;
};
#endif /* !_NET_IF_TAPVAR_H_ */
--- sys/net/if_tap.c.orig 2012-02-15 13:24:10.0 +0700
+++ sys/net/if_tap.c2012-02-15 16:28:15.0 +0700
@@ -229,6 +229,7 @@ tap_clone_destroy(struct ifnet *ifp)
{
struct tap_softc *tp = ifp->if_softc;
+ sysctl_ctx_free(&tp->ctx);
mtx_lock(&tapmtx);
SLIST_REMOVE(&taphead, tp, tap_softc, tap_next);
mtx_unlock(&tapmtx);
@@ -399,6 +400,8 @@ tapcreate(struct cdev *dev)
int unit;
char*name = NULL;
u_char eaddr[6];
+ char num[14]; /* sufficient for 32 bits */
+ struct sysctl_oid *oid;
dev->si_flags &= ~SI_CHEAPCLONE;
@@ -433,6 +436,16 @@ tapcreate(struct cdev *dev)
ifp = tp->tap_ifp = if_alloc(IFT_ETHER);
if (ifp == NULL)
panic("%s%d: can not if_alloc()", name, unit);
+
+ sysctl_ctx_init(&tp->ctx);
+ snprintf(num, sizeof(num), "%u", unit);
+ tp->keep_up = 0;
+ oid = SYSCTL_ADD_NODE(&tp->ctx, &SYSCTL_NODE_CHILDREN(_net_link, tap),
+ OID_AUTO, num, CTLFLAG_RD, NULL, "");
+ SYSCTL_ADD_INT(&tp->ctx, SYSCTL_CHILDREN(oid), OID_AUTO,
+ "keep_up", CTLTYPE_INT|CTLFLAG_RW, &tp->keep_up, tp->keep_up,
+ "Keep interface up on close");
+
ifp->if_softc = tp;
if_initname(ifp, name, unit);
ifp->if_init = tapifinit;
@@ -528,7 +541,8 @@ tapclose(struct cdev *dev, int foo, int
* interface, if we are in VMnet mode. just close the device.
*/
- if (((tp->tap_flags & TAP_VMNET) == 0) && (ifp->if_flags & IFF_UP)) {
+ if (!tp->keep_up &&
+ ((tp->tap_flags & TAP_VMNET) == 0) && (ifp->if_flags & IFF_UP)) {
mtx_unlock(&tp->tap_mtx);
if_down(ifp);
mtx_lock(&tp->tap_mtx);
--- share/man/man4/tap.4.orig 2012-02-15 14:37:59.0 +0700
+++ share/man/man4/tap.42012-02-15 16:25:50.0 +0700
@@ -268,7 +268,9
kern/165444: [netisr] [patch] incorrect processing of net.isr.bindthreads=0
>Number: 165444
>Category: kern
>Synopsis: [netisr] [patch] incorrect processing of net.isr.bindthreads=0
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Fri Feb 24 11:10:04 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Eugene Grosbein
>Release:FreeBSD 8.2-STABLE i386
>Organization:
RDTC JSC
>Environment:
System: FreeBSD eg.sd.rdtc.ru 8.2-STABLE FreeBSD 8.2-STABLE #37: Wed Feb 15
14:22:03 NOVT 2012 r...@eg.sd.rdtc.ru:/usr/local/obj/usr/local/src/sys/EG i386
>Description:
I've tried to use loader tunnable 'net.isr.bindthreads=0'
for 4-core router. Sometimes each of 4 NETISR kernel threads get
full cpu mask 0,1,2,3 but sometimes some NETISR threads get bound
to CPU3 only.
See also:
http://lists.freebsd.org/pipermail/freebsd-hackers/2012-January/037597.html
>How-To-Repeat:
See above. The effect is random.
>Fix:
To ensure correct processing of tunnable, small correction is needed,
something like this:
--- sys/net/netisr.c.orig 2012-02-24 17:45:37.0 +0700
+++ sys/net/netisr.c2012-02-24 17:47:52.0 +0700
@@ -980,12 +980,10 @@
if (error)
panic("%s: swi_add %d", __func__, error);
pc->pc_netisr = nwsp->nws_intr_event;
- if (netisr_bindthreads) {
- error = intr_event_bind(nwsp->nws_intr_event, cpuid);
+ error = intr_event_bind(nwsp->nws_intr_event,
netisr_bindthreads ? cpuid : NOCPU);
if (error != 0)
printf("%s: cpu %u: intr_event_bind: %d", __func__,
cpuid, error);
- }
NETISR_WLOCK();
nws_array[nws_count] = nwsp->nws_cpu;
nws_count++;
>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/165804: [uart] [patch] Add support for MosChip MCS9904 PCIe x1 four serial ports controller
>Number: 165804
>Category: kern
>Synopsis: [uart] [patch] Add support for MosChip MCS9904 PCIe x1 four
>serial ports controller
>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 07 06:10:08 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Eugene Grosbein
>Release:FreeBSD 8.3-PRERELEASE i386
>Organization:
RDTC JSC
>Environment:
System: FreeBSD eg.sd.rdtc.ru 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #39: Wed
Mar 7 12:16:36 NOVT 2012 r...@eg.sd.rdtc.ru:/usr/local/obj/usr/local/src/sys/EG
i386
>Description:
uart(4) supports MosChip MCS9900/MCS9901 based controllers
but not MCS9904.
With following patch applied, all four serial ports are attached
and work just find.
>How-To-Repeat:
Use MosChip MCS9904-based PCIe x1 4-port serial card,
ports do not attach:
pcib2: irq 16 at device 28.0 on pci0
pci2: on pcib2
pci2: at device 0.0 (no driver attached)
pci2: at device 0.1 (no driver attached)
pci2: at device 0.2 (no driver attached)
pci2: at device 0.3 (no driver attached)
>Fix:
Add card's PCI ID to uart(4) driver:
--- sys/dev/uart/uart_bus_pci.c.orig2012-03-07 12:12:41.0 +0700
+++ sys/dev/uart/uart_bus_pci.c 2012-03-07 12:13:44.0 +0700
@@ -122,6 +122,8 @@
"MosChip MCS9900 PCIe to Peripheral Controller", 0x10 },
{ 0x9710, 0x9901, 0xa000, 0x1000,
"MosChip MCS9901 PCIe to Peripheral Controller", 0x10 },
+{ 0x9710, 0x9904, 0xa000, 0x1000,
+ "MosChip MCS9904 PCIe to Peripheral Controller", 0x10 },
{ 0xdeaf, 0x9051, 0x, 0, "Middle Digital PC Weasel Serial Port", 0x10 },
{ 0x, 0, 0x, 0, NULL, 0, 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"
kern/166255: [net] [patch] It should be possible to disable "promiscuous mode enabled" messages
>Number: 166255 >Category: kern >Synopsis: [net] [patch] It should be possible to disable "promiscuous >mode enabled" messages >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Mon Mar 19 21:00:27 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Eugene Grosbein >Release:FreeBSD 8.3-PRERELEASE amd64 >Organization: RDTC JSC >Environment: System: FreeBSD grosbein.pp.ru 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #17: Tue Mar 20 01:42:57 NOVT 2012 r...@grosbein.pp.ru:/usr/local/obj/usr/local/src/sys/DADV amd64 >Description: We run large network providing local users with Internet access using DHCP service. While we block malice DHCP servers in our net using switches' layer 2 ACLs, configuration errors sometimes happen. So, we also run network monitoring server based on FreeBSD that periodically sends DHCP requests and waits for answers to detect malice DHCP servers and warn us timely. We use net-mgmt/dhcdrop to perform this task. dhcdrop utilizes BPF and takes each of several thousands vlan interfaces to promiscous mode on at start and take it back at finish. This cycle runs several times per minute producing tons of LOG_NOTICE kernel messages: vlan1: promiscuous mode enabled vlan2: promiscuous mode enabled ... vlan1: promiscuous mode disabled vlan2: promiscuous mode disabled And so on. The server is diskless so it fills RAM-based /var/log with these messages and floods our remote syslog collector. It is not possible to filter those messages out with means of syslog.conf only. It should be possible to disable these messages in setups like ours where they are excessive. >How-To-Repeat: See above. >Fix: The following patch introduces new sysctl named net.link.log_promisc_mode_change with default value 1. One may change it to 0 to disable mentioned warnings. --- sys/net/if.c.orig 2012-03-20 03:13:12.0 +0700 +++ sys/net/if.c2012-03-20 03:22:10.0 +0700 @@ -120,6 +120,12 @@ &ifdescr_maxlen, 0, "administrative maximum length for interface description"); +static int log_promisc_mode_change = 1; + +SYSCTL_INT(_net_link, OID_AUTO, log_promisc_mode_change, CTLFLAG_RW, + &log_promisc_mode_change, 1, + "log promiscuous mode change events"); + MALLOC_DEFINE(M_IFDESCR, "ifdescr", "ifnet descriptions"); /* global sx for non-critical path ifdescr */ @@ -2240,7 +2246,8 @@ ifp->if_flags |= IFF_PROMISC; else if (ifp->if_pcount == 0) ifp->if_flags &= ~IFF_PROMISC; - log(LOG_INFO, "%s: permanently promiscuous mode %s\n", + if (log_promisc_mode_change) + log(LOG_INFO, "%s: permanently promiscuous mode %s\n", ifp->if_xname, (new_flags & IFF_PPROMISC) ? "enabled" : "disabled"); } @@ -2770,7 +2777,8 @@ error = if_setflag(ifp, IFF_PROMISC, IFF_PPROMISC, &ifp->if_pcount, pswitch); /* If promiscuous mode status has changed, log a message */ - if (error == 0 && ((ifp->if_flags ^ oldflags) & IFF_PROMISC)) + if (error == 0 && log_promisc_mode_change && + ((ifp->if_flags ^ oldflags) & IFF_PROMISC)) log(LOG_INFO, "%s: promiscuous mode %s\n", ifp->if_xname, (ifp->if_flags & IFF_PROMISC) ? "enabled" : "disabled"); >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"
bin/166448: [patch] newsyslog -t fails to find previous rotated log
>Number: 166448
>Category: bin
>Synopsis: [patch] newsyslog -t fails to find previous rotated log
>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 18:10:11 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Eugene Grosbein
>Release:FreeBSD 8.3-PRERELEASE amd64
>Organization:
RDTC JSC
>Environment:
System: FreeBSD grosbein.pp.ru 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #19: Tue
Mar 20 03:24:04 NOVT 2012
r...@grosbein.pp.ru:/usr/local/obj/usr/local/src/sys/DADV amd64
>Description:
newsyslog.conf(5) has "when" field instructing newsyslog to find
previous rotated copy of log and look if it is older than "when" hours.
newsyslog always looks for "file.0" and this is wrong when -t flag is
used.
>How-To-Repeat:
Use newsyslog -t and non-zero value in "when" field:
/var/log/cron 600 3 * 8@T C
This should rotate log three times a day starting from midnight.
>Fix:
--- usr.sbin/newsyslog/newsyslog.c.orig 2012-03-27 22:43:06.0 +0700
+++ usr.sbin/newsyslog/newsyslog.c 2012-03-28 00:53:21.0 +0700
@@ -2206,6 +2206,77 @@
return (kbytes(dbtob(sb.st_blocks)));
}
+/* Return the age of previous old log file, when using time based filenames. */
+static time_t
+find_oldest_timelog(const char *dir, const char *logfname)
+{
+ struct stat sb;
+ int c, valid;
+ size_t logfname_len;
+ struct tm tm;
+ time_t oldt;
+ struct dirent *dp;
+ DIR *dirp;
+ char *s;
+
+ if ((dirp = opendir(dir)) == NULL)
+ err(1, "Cannot open log directory '%s'", dir);
+
+ oldt = -1;
+ logfname_len = strlen(logfname);
+ while ((dp = readdir(dirp)) != NULL) {
+ if (dp->d_type != DT_REG)
+ continue;
+ /* Ignore everything but files with our logfile prefix */
+ if (strncmp(dp->d_name, logfname, logfname_len) != 0)
+ continue;
+ /* Ignore the actual non-rotated logfile */
+ if (dp->d_namlen == logfname_len)
+ continue;
+ /*
+* Make sure we have found a logfile, so the
+* postfix is valid, IE format is: '.(.[bg]z)?'.
+*/
+ if (dp->d_name[logfname_len] != '.') {
+ if (verbose)
+ printf("Ignoring %s which has unexpected "
+ "extension '%s'\n", dp->d_name,
+ &dp->d_name[logfname_len]);
+ continue;
+ }
+ if ((s = strptime(&dp->d_name[logfname_len + 1],
+ timefnamefmt, &tm)) == NULL) {
+ if (verbose)
+ printf("Ignoring %s which does not "
+ "match time format\n", dp->d_name);
+ continue;
+ }
+
+ valid = 0;
+ c = 0;
+ while (!valid && c < COMPRESS_TYPES)
+ if (strcmp(s, compress_type[c++].suffix) == 0)
+ valid = 1;
+
+ if (valid != 1) {
+ if (verbose)
+ printf("Ignoring %s which has unexpected "
+ "extension '%s'\n", dp->d_name, s);
+ continue;
+ }
+ if (stat(dp->d_name, &sb) < 0)
+ err(1, "Cannot stat '%s'", dp->d_name);
+
+ /* We have found more recent old logfile */
+ if (oldt < sb.st_mtime)
+ oldt = sb.st_mtime;
+ }
+ closedir(dirp);
+
+ /* Return -1 if nothing found */
+ return oldt;
+}
+
/* Return the age of old log file (file.0) */
static int
age_old_log(char *file)
@@ -2241,6 +2312,17 @@
(void) strlcpy(tmp, file, sizeof(tmp));
}
+ if (timefnamefmt != NULL) {
+char *bd;
+time_t t;
+
+ if ((bd = dirname(tmp)) == NULL)
+err(1, "'%s'", tmp);
+if ((t = find_oldest_timelog(bd, basename(tmp))) == -1)
+return (-1);
+return ((int)(ptimeget_secs(timenow) - t + 1800) / 3600);
+ }
+
strlcat(tmp, ".0&quo
Re: bin/166448: [patch] newsyslog -t fails to find previous rotated log
The following reply was made to PR bin/166448; it has been noted by GNATS.
From: Eugene Grosbein
To: bug-follo...@freebsd.org
Cc:
Subject: Re: bin/166448: [patch] newsyslog -t fails to find previous rotated
log
Date: Wed, 28 Mar 2012 02:10:50 +0700
Sorry, I've sent buggy patch (does stat() on wrong filename). Here is
corrected one.
--- usr.sbin/newsyslog/newsyslog.c.orig2012-02-13 17:02:03.0
+0400
+++ usr.sbin/newsyslog/newsyslog.c 2012-03-27 22:53:46.0 +0400
@@ -2206,6 +2206,79 @@
return (kbytes(dbtob(sb.st_blocks)));
}
+/* Return the age of previous old log file, when using time based filenames.
*/
+static time_t
+find_oldest_timelog(const char *dir, const char *logfname)
+{
+ struct stat sb;
+ int c, valid;
+ size_t logfname_len;
+ struct tm tm;
+ time_t oldt;
+ struct dirent *dp;
+ DIR *dirp;
+ char *s;
+ char tmp[MAXPATHLEN];
+
+ if ((dirp = opendir(dir)) == NULL)
+ err(1, "Cannot open log directory '%s'", dir);
+
+ oldt = -1;
+ logfname_len = strlen(logfname);
+ while ((dp = readdir(dirp)) != NULL) {
+ if (dp->d_type != DT_REG)
+ continue;
+ /* Ignore everything but files with our logfile prefix */
+ if (strncmp(dp->d_name, logfname, logfname_len) != 0)
+ continue;
+ /* Ignore the actual non-rotated logfile */
+ if (dp->d_namlen == logfname_len)
+ continue;
+ /*
+ * Make sure we have found a logfile, so the
+ * postfix is valid, IE format is: '.(.[bg]z)?'.
+ */
+ if (dp->d_name[logfname_len] != '.') {
+ if (verbose)
+ printf("Ignoring %s which has unexpected "
+ "extension '%s'\n", dp->d_name,
+ &dp->d_name[logfname_len]);
+ continue;
+ }
+ if ((s = strptime(&dp->d_name[logfname_len + 1],
+ timefnamefmt, &tm)) == NULL) {
+ if (verbose)
+ printf("Ignoring %s which does not "
+ "match time format\n", dp->d_name);
+ continue;
+ }
+
+ valid = 0;
+ c = 0;
+ while (!valid && c < COMPRESS_TYPES)
+ if (strcmp(s, compress_type[c++].suffix) == 0)
+ valid = 1;
+
+ if (valid != 1) {
+ if (verbose)
+ printf("Ignoring %s which has unexpected "
+ "extension '%s'\n", dp->d_name, s);
+ continue;
+ }
+ snprintf(tmp, sizeof(tmp), "%s/%s", dir, dp->d_name);
+ if (stat(tmp, &sb) < 0)
+ err(1, "Cannot stat '%s'", tmp);
+
+ /* We have found more recent old logfile */
+ if (oldt < sb.st_mtime)
+ oldt = sb.st_mtime;
+ }
+ closedir(dirp);
+
+ /* Return -1 if nothing found */
+ return oldt;
+}
+
/* Return the age of old log file (file.0) */
static int
age_old_log(char *file)
@@ -2241,6 +2314,17 @@
(void) strlcpy(tmp, file, sizeof(tmp));
}
+ if (timefnamefmt != NULL) {
+char *bd;
+time_t t;
+
+ if ((bd = dirname(tmp)) == NULL)
+err(1, "'%s'", tmp);
+if ((t = find_oldest_timelog(bd, basename(tmp))) == -1)
+return (-1);
+return ((int)(ptimeget_secs(timenow) - t + 1800) / 3600);
+ }
+
strlcat(tmp, ".0", sizeof(tmp));
logfile_suffix = get_logfile_suffix(tmp);
if (logfile_suffix == NULL)
___
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/166866: [build] [cy] cy(4) driver breaks kernel build in 8.3
>Number: 166866 >Category: kern >Synopsis: [build] [cy] cy(4) driver breaks kernel build in 8.3 >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Apr 12 08:40:13 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Eugene Shouleshov >Release:FreeBSD 8.3-RELEASE >Organization: >Environment: FreeBSD 8.3-RELEASE i386 >Description: Unable to compile kernel when cy(4) device driver included in GENERIC config file. cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I../../.. -I../../../contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror ../../../dev/cy/cy.c ./../../dev/cy/cy.c:251: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cybreak' ./../../dev/cy/cy.c:252: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cymodem' ./../../dev/cy/cy.c:253: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cyopen' ./../../dev/cy/cy.c:254: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cyclose' cc1: warnings being treated as errors ./../../dev/cy/cy.c: In function 'cyattach_common': ./../../dev/cy/cy.c:411: warning: implicit declaration of function 'ttyalloc' ./../../dev/cy/cy.c:411: warning: nested extern declaration of 'ttyalloc' ./../../dev/cy/cy.c:411: warning: assignment makes pointer from integer without a cast ./../../dev/cy/cy.c:412: error: 'struct tty' has no member named 't_open' ./../../dev/cy/cy.c:412: error: 'cyopen' undeclared (first use in this function) ./../../dev/cy/cy.c:412: error: (Each undeclared identifier is reported only once ./../../dev/cy/cy.c:412: error: for each function it appears in.) ./../../dev/cy/cy.c:413: error: 'struct tty' has no member named 't_close' ./../../dev/cy/cy.c:413: error: 'cyclose' undeclared (first use in this function) ./../../dev/cy/cy.c:414: error: 'struct tty' has no member named 't_oproc' ./../../dev/cy/cy.c:415: error: 'struct tty' has no member named 't_stop' ./../../dev/cy/cy.c:416: error: 'struct tty' has no member named 't_param' ./../../dev/cy/cy.c:417: error: 'struct tty' has no member named 't_break' ./../../dev/cy/cy.c:417: error: 'cybreak' undeclared (first use in this function) ./../../dev/cy/cy.c:418: error: 'struct tty' has no member named 't_modem' ./../../dev/cy/cy.c:418: error: 'cymodem' undeclared (first use in this function) ./../../dev/cy/cy.c:419: error: 'struct tty' has no member named 't_sc' ./../../dev/cy/cy.c:421: error: 'struct tty' has no member named 't_init_in' ./../../dev/cy/cy.c:436: warning: implicit declaration of function 'ttycreate' ./../../dev/cy/cy.c:436: warning: nested extern declaration of 'ttycreate' ./../../dev/cy/cy.c:436: error: 'TS_CALLOUT' undeclared (first use in this function) ./../../dev/cy/cy.c: In function 'cyopen': ./../../dev/cy/cy.c:453: error: 'struct tty' has no member named 't_sc' ./../../dev/cy/cy.c: In function 'cyclose': ./../../dev/cy/cy.c:495: error: 'struct tty' has no member named 't_sc' ./../../dev/cy/cy.c:516: error: 'struct tty' has no member named 't_cflag' ./../../dev/cy/cy.c:524: error: 'struct tty' has no member named 't_actout' ./../../dev/cy/cy.c:526: error: 'struct tty' has no member named 't_init_in' ./../../dev/cy/cy.c:527: error: 'struct tty' has no member named 't_state' ./../../dev/cy/cy.c:527: error: 'TS_ISOPEN' undeclared (first use in this function) ./../../dev/cy/cy.c:528: warning: implicit declaration of function 'cymodem' ./../../dev/cy/cy.c:528: warning: nested extern declaration of 'cymodem' ./../../dev/cy/cy.c:536: warning: implicit declaration of function 'ttydtrwaitstart' ./../../dev/cy/cy.c:536: warning: nest
misc/167200: source upgrade from RELENG_7 to RELENG_8 broken for no reason
>Number: 167200
>Category: misc
>Synopsis: source upgrade from RELENG_7 to RELENG_8 broken for no reason
>Confidential: no
>Severity: serious
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Sun Apr 22 13:00:26 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Eugene Grosbein
>Release:FreeBSD 8.3-PRERELEASE amd64
>Organization:
RDTC JSC
>Environment:
System: FreeBSD grosbein.pp.ru 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #19: Tue
Mar 20 03:24:04 NOVT 2012
r...@grosbein.pp.ru:/usr/local/obj/usr/local/src/sys/DADV amd64
>Description:
src/lib/libc/stdlib/Makefile.inc use '.sinclude' directive
that's not supported by make(1) of RELENG_7, so make buildworld
fails while one performs source upgrade from 7.4-STABLE to 8.3-STABLE.
This breakage is easily fixed by applying to RELENG_8 reversed
version of patch:
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdlib/Makefile.inc.diff?r1=1.56;r2=1.57
Please make this 'no-op' change to save users from extra cycle
in the chain 7.4-STABLE -> 8.0-RELEASE -> 8-STABLE.
Or, perform MFC to RELENG_8 of recent make(1) sources that supporrt
'.sinclude' directive.
>How-To-Repeat:
Try to make buildworld of RELENG_8 sources using 7.4 machine.
>Fix:
Apply this to RELENG_8:
--- lib/libc/stdlib/Makefile.inc.orig 2012-04-22 17:56:26.0 +0700
+++ lib/libc/stdlib/Makefile.inc2012-04-22 17:56:26.0 +0700
@@ -16,7 +16,9 @@
SYM_MAPS+= ${.CURDIR}/stdlib/Symbol.map
# machine-dependent stdlib sources
-.sinclude "${.CURDIR}/${MACHINE_ARCH}/stdlib/Makefile.inc"
+.if exists(${.CURDIR}/${MACHINE_ARCH}/stdlib/Makefile.inc)
+.include "${.CURDIR}/${MACHINE_ARCH}/stdlib/Makefile.inc"
+.endif
MAN+= a64l.3 abort.3 abs.3 alloca.3 atexit.3 atof.3 atoi.3 atol.3 bsearch.3 \
div.3 exit.3 getenv.3 getopt.3 getopt_long.3 getsubopt.3 \
>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/167204: terrible "netstat -rn" performance due to slow kvm_nlist()
>Number: 167204 >Category: kern >Synopsis: terrible "netstat -rn" performance due to slow kvm_nlist() >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: Sun Apr 22 14:10:10 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Eugene Grosbein >Release:FreeBSD 8.3-PRERELEASE i386 >Organization: RDTC JSC >Environment: System: FreeBSD grosbein.pp.ru 8.3-PRERELEASE >Description: My home router runs FreeBSD/i386 on AMD Geode: %uname -a FreeBSD gw.grosbein.pp.ru 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #1: Tue Mar 6 23:11:20 NOVT 2012 r...@grosbein.pp.ru:/usr/local/obj/nanobsd.gw/i386/usr/local/src/sys/GW i386 %grep CPU /var/run/dmesg.boot CPU: Geode(TM) Integrated Processor by AMD PCS (499.91-MHz 586-class CPU) It has no IPv6 in the kernel config and pretty small routing table: %sh -c 'time netstat -rn | wc -l' 1.47 real 0.00 user 1.06 sys 30 As you can see, it takes more than a second for 'netstat -rn' to complete. Most of time it spends calling kldsym() system call from kvm_nlist() function: %kdump | fgrep -c 'CALL kldsym(0,KLDSYM_LOOKUP' 347 For some unknown reason, the performace of this syscall is way too bad. >How-To-Repeat: Run "time netstat -rn" >Fix: Unknown >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/158023: Binaries have no SUID bits in FreeBSD-8.2-RELEASE-amd64-livefs.iso
The following reply was made to PR misc/158023; it has been noted by GNATS. From: Eugene Grosbein To: bug-follo...@freebsd.org Cc: Subject: Re: misc/158023: Binaries have no SUID bits in FreeBSD-8.2-RELEASE-amd64-livefs.iso Date: Mon, 23 Apr 2012 21:46:58 +0700 Hi! The problem is fixed in FreeBSD-8.3-RELEASE-amd64-livefs.iso Please close this PR. Eugene Grosbein ___ 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: bin/65961: ipfw2 memory corruption inside add()
The following reply was made to PR bin/65961; it has been noted by GNATS. From: Eugene Grosbein To: bug-follo...@freebsd.org Cc: Subject: Re: bin/65961: ipfw2 memory corruption inside add() Date: Wed, 02 May 2012 11:37:09 +0700 Hi! Please reopen this PR because the problem is still here for 8.3-STABLE and test script in the PR segfaults ipfw still. This PR was closed as duplicate of i386/60154 but that PR was also closed without fix. Eugene Grosbein ___ 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: bin/65961: [ipfw] ipfw2 memory corruption inside add()
02.05.2012 11:44, lini...@freebsd.org пишет: > Old Synopsis: ipfw2 memory corruption inside add() > New Synopsis: [ipfw] ipfw2 memory corruption inside add() > > State-Changed-From-To: closed->open > State-Changed-By: linimon > State-Changed-When: Wed May 2 04:43:06 UTC 2012 > State-Changed-Why: > submitter claims that this problem still persists with 8.3. > > > Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw > Responsible-Changed-By: linimon > Responsible-Changed-When: Wed May 2 04:43:06 UTC 2012 > Responsible-Changed-Why: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=65961 More tests show that for 8.3/i386 this is possible to make /sbin/ipfw eat all CPU cycles and run in R state infinitely despite of kill -9. Just run mentioned script: ./test 122 Eugene Grosbein ___ 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/167603: IP fragment reassembly's broken: file transfer over NFSv3/UDP fails for default NFS packet size
>Number: 167603 >Category: kern >Synopsis: IP fragment reassembly's broken: file transfer over NFSv3/UDP >fails for default NFS packet size >Confidential: no >Severity: serious >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat May 05 04:10:11 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Eugene Grosbein >Release:FreeBSD 8.3-STABLE i386 >Organization: RDTC JSC >Environment: System: FreeBSD eg.sd.rdtc.ru 8.3-STABLE FreeBSD 8.3-STABLE #44: Fri May 4 14:05:29 NOVT 2012 r...@eg.sd.rdtc.ru:/usr/local/obj/usr/local/src/sys/EG i386 >Description: I have FreeBSD 8.3-STABLE/i386 as NFS UDP client and FreeBSD 8.3-STABLE/amd64 as NFS server. In /etc/fstab I have: syslog:/backup /backup nfs rw,soft,intr,mntudp,noauto 0 0 With these options, I can get small and medium files from NFS server but transfer of large files using rsync always fails: # rsync -av --delete /backup /data/write sending incremental file list backup/system/20120429/ backup/system/20120429/rddtool-20120429.tbz rsync: read errors mapping "/backup/system/20120429/rddtool-20120429.tbz": Operation timed out (60) A workaround is to use '-r=1024,-w=1024' mount options, then files transfer just fine. Meantime, ping -D -s 1472 runs just fine withous a loss. When this error occures, "netstat -ss -p ip" shows that 'fragments dropped (dup or out of space)' increases with tens and hundreds packets. Both servers and client were upgraded top 8.3-STABLE using RELENG_8 sources of 4 May 2012. The same for NFS server based on 7.4-STABLE/i386. >How-To-Repeat: See above. >Fix: Unknown. >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/112707: [panic] 6.2-STABLE panic: spoiling cp->ace = 3
On 12.12.2010 15:49, j...@freebsd.org wrote: > Synopsis: [panic] 6.2-STABLE panic: spoiling cp->ace = 3 > > State-Changed-From-To: open->feedback > State-Changed-By: jh > State-Changed-When: Sun Dec 12 09:49:27 UTC 2010 > State-Changed-Why: > Can you still reproduce this on a supported release? > > http://www.freebsd.org/cgi/query-pr.cgi?pr=112707 I've just checked it with RELENG_8 updated yesterday and found no problems. It seems the issue is fixed with RELENG_8 because of changes in CURRENT made before RELENG_8 was branched. I have no RELENG_7 based system handy to test, though. I suspect it may still have problems because there were no MFC for fix: http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/boot0cfg/boot0cfg.c#rev1.21 ___ 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/153255: 8.2-PRERELEASE repeatable kernel panic under heavy network load
>Number: 153255
>Category: kern
>Synopsis: 8.2-PRERELEASE repeatable kernel panic under heavy network load
>Confidential: no
>Severity: serious
>Priority: high
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Fri Dec 17 18:10:11 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Eugene Grosbein
>Release:FreeBSD 8.2-PRERELEASE amd64
>Organization:
RDTC JSC
>Environment:
System: FreeBSD k-45-pc-1.sd.rdtc.ru 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0:
Mon Dec 13 14:49:37 NOVT 2010
r...@k-45-pc-1.sd.rdtc.ru:/usr/local/obj/home/src/sys/PPPOE amd64
>Description:
I run four PPPoE network access servers based on
FreeBSD 8.2-PRERELEASE/amd64 and mpd-5.5 (/usr/ports/net/mpd5)
that extensively use NETGRAPH. Machines use very different hardware
but same software: they are NanoBSD-based and loaded with same disk
image
and nearly same configuration (just distinct IP addresses).
All servers panic under heavy load when they have 900-1800 PPPoE clients
connected and more than 500Mbps going from uplink to clients
and more than 500Mbps going from clients to uplink same time.
All panics are pretty similar: that's GPF when mpd is active process.
I've got full crashdump for total 4GB of router memory.
Here comes gdb backtrace. Then dmesg output, kernel config file,
boot.conf and sysctl.conf.
Script started on Fri Dec 17 23:32:55 2010
kgdb kernel.debug /home/crash/vmcore.0
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
Unread portion of the kernel message buffer:
Fatal trap 9: general protection fault while in kernel mode
cpuid = 2; apic id = 04
instruction pointer = 0x20:0x803df4e6
stack pointer = 0x28:0xff80eb5fc8d0
frame pointer = 0x28:0xff80eb5fc900
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1951 (mpd5)
trap number = 9
panic: general protection fault
cpuid = 2
Uptime: 1d1h36m42s
Dumping 4087 MB (3 chunks)
chunk 0: 1MB (155 pages) (CTRL-C to abort) ... ok
chunk 1: 3831MB (980592 pages) 3815 3799 3783 3767 3751 3735 3719 3703 3687
3671 3655 3639 3623 3607 3591 3575 3559 3543 3527 3511 3495 3479 3463 3447 3431
3415 3399 3383 3367 3351 3335 3319 3303 3287 3271 3255 3239 3223 3207 3191 3175
3159 3143 3127 3111 3095 3079 3063 3047 3031 3015 2999 2983 2967 2951 2935 2919
2903 2887 2871 2855 2839 2823 2807 2791 2775 2759 2743 2727 2711 2695 2679 2663
2647 2631 2615 2599 2583 2567 2551 2535 2519 2503 2487 2471 2455 2439 2423 2407
2391 2375 2359 2343 2327 2311 2295 2279 2263 2247 2231 2215 2199 2183 2167 2151
2135 2119 2103 2087 2071 2055 2039 2023 2007 1991 1975 1959 1943 1927 1911 1895
1879 1863 1847 1831 1815 1799 1783 1767 1751 1735 1719 1703 1687 1671 1655 1639
1623 1607 1591 1575 1559 1543 1527 1511 1495 1479 1463 1447 1431 1415 1399 1383
1367 1351 1335 1319 1303 1287 1271 1255 1239 1223 1207 1191 1175 1159 1143 1127
1095 1079 1063 1047 1031 1015 999 983 967 951 935 919 903 887 871 855 839
823 807 791 775 759 743 727 711 !
695 679 663 647 631 615 599 583 567 551 535 519 503 487 471 455 439 423 407
391 375 359 343 327 311 295 279 263 247 231 215 199 183 167 151 135 119 103 87
71 55 39 23 7 ... ok
chunk 2: 256MB (65536 pages) 241 225 209 193 177 161 145 129 113 97 81 65 49
33 17 1
Reading symbols from /boot/kernel/if_lagg.ko...done.
Loaded symbols for /boot/kernel/if_lagg.ko
Reading symbols from /boot/kernel/ipmi.ko...done.
Loaded symbols for /boot/kernel/ipmi.ko
#0 doadump () at pcpu.h:224
224 __asm("movq %%gs:0,%0" : "=r" (td));
(kgdb) bt
#0 doadump () at pcpu.h:224
#1 0x802feb0e in boot (howto=260) at
/home/src/sys/kern/kern_shutdown.c:419
#2 0x802fef23 in panic (fmt=0x0) at
/home/src/sys/kern/kern_shutdown.c:592
#3 0x8049ff4d in trap_fatal (frame=0xff0012f12000, eva=Variable
"eva" is not available.
) at /home/src/sys/amd64/amd64/trap.c:783
#4 0x804a04ba in trap (frame=0xff80eb5fc820) at
/home/src/sys/amd64/amd64/trap.c:592
#5 0x80488a24 in calltrap () at
/home/src/sys/amd64/amd64/exception.S:224
#6 0x803df4e6 in in_pcbrele (inp=0xff0012c7b930) at
Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent call of "/etc/rc.d/ipfw start"
The following reply was made to PR bin/153252; it has been noted by GNATS. From: Eugene Grosbein To: bug-follo...@freebsd.org Cc: al...@freebsd.forum Subject: Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent call of "/etc/rc.d/ipfw start" Date: Sat, 18 Dec 2010 02:38:45 +0600 1. > # check if firewall already running to prevent subsequent start calls One should not unconditionally disable ability of reloading ipfw rules using "/etc/rc.d/ipfw start" command. For example, it's used extensively in my systems and does not lead to "lock-down". One should learn ipfw(8) manual page including CHECKLIST paragraph and make oneself familiar with proper ways of reloading ipfw over network. 2. Nice catch. However, that's only one of reasons why it is very bad habit to have "./" in PATH. 3. Please use "diff -u" to make unified diffs, they are much easier to read. Eugene Grosbein ___ 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/153454: [patch] [wlan] [urtw] Support ad-hoc and hostap modes in if_urtw(4)
>Number: 153454 >Category: kern >Synopsis: [patch] [wlan] [urtw] Support ad-hoc and hostap modes in >if_urtw(4) >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Sun Dec 26 18:40:08 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Eugene Grosbein >Release:FreeBSD 8.2-PRERELEASE i386 >Organization: RDTC JSC >Environment: System: FreeBSD grosbein.pp.ru 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #17: Sat Dec 11 23:58:55 NOVT 2010 r...@grosbein.pp.ru:/usr/local/obj/usr/local/src/sys/DADV i386 >Description: Currently, if_urtw(4) driver for Realtek wireless NICs supports only station and monitor modes. I have a notebook with embedded USB wireless NIC supported with this driver and was able to successfully setup it in ad-hoc mode and in hostap mode (with and without hostapd) and connect my Nokia E72 smartphone to the Internet over wifi using this notebook after applying the following patch to the driver. usbconfig shows me: ugen7.2: at usbus7, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON I've used standard instructions from the Handbook (never dealt with Wifi devices before) and found no problems with one exception: "ifconfig wlan0 scan" does not work but "ifconfig wlan0 list scan" does. >How-To-Repeat: Try to enable hostap/ad-hoc modes with if_urtw, it won't. >Fix: --- sys/dev/usb/wlan/if_urtw.c.orig 2010-12-26 21:04:47.0 +0600 +++ sys/dev/usb/wlan/if_urtw.c 2010-12-26 21:05:32.0 +0600 @@ -880,6 +880,8 @@ ic->ic_caps = IEEE80211_C_STA | /* station mode */ IEEE80211_C_MONITOR | /* monitor mode supported */ + IEEE80211_C_IBSS | /* ad-hoc mode supported */ + IEEE80211_C_HOSTAP |/* access point mode supported */ IEEE80211_C_TXPMGT |/* tx power management */ IEEE80211_C_SHPREAMBLE |/* short preamble supported */ IEEE80211_C_SHSLOT |/* short slot time supported */ --- share/man/man4/urtw.4.orig 2010-12-27 00:02:10.0 +0600 +++ share/man/man4/urtw.4 2010-12-27 00:06:40.0 +0600 @@ -56,7 +56,9 @@ .Pp .Nm supports -.Cm station +.Cm station , +.Cm adhoc , +.Cm hostap , and .Cm monitor mode operation. >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/153671: [em] [panic] 8.2-PRERELEASE repeatable kernel in if_em(4)
The following reply was made to PR kern/153671; it has been noted by GNATS. From: Eugene Grosbein To: bug-follo...@freebsd.org Cc: Subject: Re: kern/153671: [em] [panic] 8.2-PRERELEASE repeatable kernel in if_em(4) Date: Tue, 04 Jan 2011 11:47:58 +0600 Sorry, I have not fixed 'From:' header before sending PR out. That's my PR. ___ 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: bin/61355: login(1) does not restore terminal ownership on exit
The following reply was made to PR bin/61355; it has been noted by GNATS. From: Eugene Grosbein To: bug-follo...@freebsd.org Cc: Subject: Re: bin/61355: login(1) does not restore terminal ownership on exit Date: Tue, 04 Jan 2011 15:32:50 +0600 This is still the problem for 8.2-PRERELEASE, in a way similar to 6.2: exiting 'nested' login session clears wtmp, so original session becomes 'invisible' with wrong tty ownership. Eugene Grosbein ___ 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/138341: [nanobsd] [patch] 8.0-BETA3: nanobsd build broken due to sysipc kernel module
The following reply was made to PR kern/138341; it has been noted by GNATS.
From: Eugene Grosbein
To: bug-follo...@freebsd.org
Cc: sta...@freebsd.org
Subject: Re: kern/138341: [nanobsd] [patch] 8.0-BETA3: nanobsd build broken
due to sysipc kernel module
Date: Sat, 15 Jan 2011 23:01:38 +0600
'make MODULES_WITH_WORLD=yes buildworld' is still broken for 8.2-PRERELEASE.
Here is a patch for RELENG_8 sources updated today:
--- sys/modules/cryptodev/Makefile.orig2010-08-23 12:13:44.0
+0700
+++ sys/modules/cryptodev/Makefile 2010-08-23 12:13:52.0 +0700
@@ -3,6 +3,6 @@
.PATH:${.CURDIR}/../../opencrypto
KMOD = cryptodev
SRCS = cryptodev.c
-SRCS += bus_if.h device_if.h
+SRCS += bus_if.h device_if.h opt_compat.h
.include
--- sys/modules/dtrace/lockstat/Makefile.orig 2009-09-16 23:05:25.0
+0800
+++ sys/modules/dtrace/lockstat/Makefile 2009-09-16 23:05:45.0
+0800
@@ -5,7 +5,7 @@
KMOD= lockstat
SRCS= lockstat.c
-SRCS+=vnode_if.h
+SRCS+=vnode_if.h opt_kdtrace.h
CFLAGS+= -I${.CURDIR}/../../../cddl/compat/opensolaris \
-I${.CURDIR}/../../../cddl/contrib/opensolaris/uts/common \
--- sys/modules/mqueue/Makefile.orig 2010-04-24 17:47:03.0 +0700
+++ sys/modules/mqueue/Makefile2010-04-24 17:47:14.0 +0700
@@ -5,6 +5,6 @@
KMOD= mqueuefs
SRCS= uipc_mqueue.c \
vnode_if.h \
- opt_posix.h
+ opt_posix.h opt_compat.h
.include
--- sys/modules/sysvipc/sysvmsg/Makefile.orig 2009-08-30 19:12:16.0
+0800
+++ sys/modules/sysvipc/sysvmsg/Makefile 2009-09-19 01:12:18.0
+0800
@@ -3,6 +3,6 @@
.PATH: ${.CURDIR}/../../../kern
KMOD= sysvmsg
-SRCS= sysv_msg.c opt_sysvipc.h
+SRCS= sysv_msg.c opt_sysvipc.h opt_compat.h
.include
--- sys/modules/sysvipc/sysvsem/Makefile.orig 2009-08-30 19:52:13.0
+0800
+++ sys/modules/sysvipc/sysvsem/Makefile 2009-08-30 19:52:33.0
+0800
@@ -3,6 +3,6 @@
.PATH: ${.CURDIR}/../../../kern
KMOD= sysvsem
-SRCS= sysv_sem.c opt_sysvipc.h
+SRCS= sysv_sem.c opt_sysvipc.h opt_compat.h
.include
___
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/154860: [gmirror] [panic] geom_mirror panices system on specific sector contents
>Number: 154860 >Category: kern >Synopsis: [gmirror] [panic] geom_mirror panices system on specific >sector contents >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Feb 18 09:20:10 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Eugene Grosbein >Release:FreeBSD 8.2-PRERELEASE amd64 >Organization: RDTC JSC >Environment: System: FreeBSD k-45-pc-1.sd.rdtc.ru 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #20: Fri Feb 18 13:08:00 NOVT 2011 r...@k-45-pc-1.sd.rdtc.ru:/usr/local/obj/home/src/sys/PPPOE amd64 >Description: My 8.2-PRERELEASE/amd64 system has two HDDs: ad8 and ad14 having equal sector number: # atacontrol cap ad8 Protocol SATA revision 2.x device model WDC WD3200AAJS-00L7A0 serial number WD-WMAV2DP22862 firmware revision 01.03E01 cylinders 16383 heads 16 sectors/track 63 lba supported 268435455 sectors lba48 supported 625142448 sectors Both disks were combined to one gmirror /dev/mirror/gm0. After unclean system shutdown this mirror became dirty and started rebuilding process from ad8 to ad14. Meantime, background fsck started to repair /usr/local and /home simultaneously (they are mounted in fstab by UFS labels). I/O contention was high so I decided to remove ad14 from the mirror to speedup fsck hoping reinsert ad14 to the mirror later: gmirror remove gm0 ad14 Immediately I've got kernel panic and system rebooted at once. Then it paniced again just at the moment of gmirror initialization. And again, and again... So I was forced to use loader to disable loading of geom_mirror.ko and go to single user mode mounting root from ad14. I've attempted to load geom_mirror.ko from single user mode and it panices the system at once. So I've saved contents of last sector of ad8 and ad14 to files. Last sector of ad14 contained only zero bytes. Last sector of ad8 comes here gzipped and uuencoded. begin 644 sector.gz M'XL(`&8G7DT``W-W]?>ULO+U#`KR#V+X__\_"P,#0WJN`4,QIV$#D/L_8=>A M!;_E+R\I/!>6S@B48P`3#`(,#$P,<5=;O4`<)A!1=H6%`0&8&'"`!(B>RR^8 How-To-Repeat: 1. Perform unclean shutdown of system booting from gmirror to make it dirty. 2. After reboot, remove dirty component of gmirror (this paniced my system). 3. Then geom_mirror panices all the time until its signature erased from HDD. >Fix: Unknown. >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/138341: [nanobsd] [patch] 8.0-BETA3: nanobsd build broken due to sysipc kernel module
The following reply was made to PR kern/138341; it has been noted by GNATS. From: Eugene Grosbein To: bug-follo...@freebsd.org Cc: Subject: Re: kern/138341: [nanobsd] [patch] 8.0-BETA3: nanobsd build broken due to sysipc kernel module Date: Sat, 26 Feb 2011 16:09:07 +0600 Hi! This is still the problem for 8.2-RELEASE. ___ 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/156427: rcNG may start disabled service
>Number: 156427
>Category: misc
>Synopsis: rcNG may start disabled service
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Fri Apr 15 18:20:08 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator: Eugene Grosbein
>Release:FreeBSD 8.2-STABLE i386
>Organization:
RDTC JSC
>Environment:
System: FreeBSD grosbein.pp.ru 8.2-STABLE FreeBSD 8.2-STABLE #21: Sat Apr 9
16:26:00 NOVST 2011 r...@grosbein.pp.ru:/usr/local/obj/usr/local/src/sys/DADV
i386
>Description:
For some services I prefer using service_enable="NO" in /etc/rc.conf
and start them by other means when needed using "forcestart" feature.
SVN r206686 and MFC r207797 broke this: now rc.subr at boot time
starts disabled service if it is already started by other means
($rc_pid is not empty).
So, the service sometimes get started twice that's not good for me.
>How-To-Repeat:
1. Disable any installed service using servicename="NO" in /etc/rc.conf
2. Run it at boot time by another script (I need service be started
or not depending on results of some local tests).
3. See it's started twice.
>Fix:
Mentioned change occured to make 'stop' work even if ${name}_enable
is not set. The code should check whether it's started to 'stop'.
>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/156545: mv could break UFS on SMP systems
The following reply was made to PR kern/156545; it has been noted by GNATS. From: Eugene Roginsky To: Cc: Subject: Re: kern/156545: mv could break UFS on SMP systems Date: Thu, 21 Apr 2011 14:53:18 +0400 Hello. Submit me plz on this bug. -- С Ñважением, Ðвгений РогинÑкий ___ 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/117973: [panic] [lpt] 7.0-BETA2: repeatable panic while printing to /dev/lpt0
23.05.2011 22:20, j...@freebsd.org пишет: > Synopsis: [panic] [lpt] 7.0-BETA2: repeatable panic while printing to > /dev/lpt0 > > State-Changed-From-To: open->feedback > State-Changed-By: jh > State-Changed-When: Mon May 23 15:20:56 UTC 2011 > State-Changed-Why: > Is this still a problem for you? > > http://www.freebsd.org/cgi/query-pr.cgi?pr=117973 I do not have parallel printer anymore nor am I interested in this PR. Eugene ___ 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/158023: Binaries have no SUID bits in FreeBSD-8.2-RELEASE-amd64-livefs.iso
>Number: 158023 >Category: misc >Synopsis: Binaries have no SUID bits in >FreeBSD-8.2-RELEASE-amd64-livefs.iso >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: Sun Jun 19 10:50:07 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Eugene Grosbein >Release:FreeBSD 8.2-STABLE amd64 >Organization: RDTC JSC >Environment: System: FreeBSD grosbein.pp.ru 8.2-STABLE FreeBSD 8.2-STABLE #0: Tue Jun 14 01:59:32 NOVST 2011 r...@grosbein.pp.ru:/usr/local/obj/usr/local/src/sys/DADV i386 >Description: I'm trying to use FreeBSD-8.2-RELEASE-amd64-livefs.iso with additional configs (rc.conf etc.) to boot remote system from. Then I login using ssh and try to 'su' to root but it fails: /usr/bin/su in the image has no SUID bit. >How-To-Repeat: # md=`mdconfig -af FreeBSD-8.2-RELEASE-amd64-livefs.iso` # mount_cd9660 /dev/$md /mnt/tmp # ls -l /mnt/tmp/usr/bin/su -r-xr-xr-x 1 root wheel 16904 Feb 17 08:19 /mnt/tmp/usr/bin/su All other binaries that should normally have SUID/SGID do not have them too. >Fix: Unknown. It would be nice if next release have this problem fixed. >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/158023: Binaries have no SUID bits in FreeBSD-8.2-RELEASE-amd64-livefs.iso
The following reply was made to PR misc/158023; it has been noted by GNATS. From: Eugene Grosbein To: bug-follo...@freebsd.org Cc: Patrick Lamaiziere Subject: Re: misc/158023: Binaries have no SUID bits in FreeBSD-8.2-RELEASE-amd64-livefs.iso Date: Sat, 2 Jul 2011 05:42:33 +0700 > This is not a bug (it's a feature!). A cd9660 file system does not know > anything about suid/sgid bits (and even group or owner). It is not a > "unix like" file system. > You can't avoid this behavior. Incorrect. Indeed, cd9660 does not know about files permissions but Rockridge extention to cd9660 does. And our mount_cd9660 uses Rockridge by default, so this bug is avoidable by using right permissions and Rockridge while generating image (mkisofs -R, not mkisofs -r). Eugene Grosbein ___ 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/144732: [patch] geom_cache erroneously decodes its on-disk label
>Number: 144732
>Category: kern
>Synopsis: [patch] geom_cache erroneously decodes its on-disk label
>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: Sun Mar 14 11:30:05 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Eugene Grosbein
>Release:FreeBSD 8.0-STABLE i386
>Organization:
RDTC JSC
>Environment:
System: FreeBSD grosbein.pp.ru 8.0-STABLE FreeBSD 8.0-STABLE #11: Sat Feb 6
21:23:34 KRAT 2010 r...@grosbein.pp.ru:/usr/local/obj/usr/local/src/sys/DADV
i386
>Description:
Let's take a look at struct g_cache_metadata definition in
/usr/src/sys/geom/cache/g_cache.h:
struct g_cache_metadata {
charmd_magic[16]; /* Magic value. */
uint32_tmd_version; /* Version number. */
charmd_name[16];/* Cache value. */
uint32_tmd_bsize; /* Cache block size. */
uint32_tmd_size;/* Cache size. */
uint64_tmd_provsize;/* Provider's size. */
};
Note that md_size is 32-bit unsigned value. Next lines present
cache_metadata_encode() funtion that uses le32enc() to encode
this value, that's right.
Now look at cache_metadata_decode() below: it uses le16dec()
function to decode stored label. This error effectively limits
cache size to 16-bit quantity (and limits stripe/block size too).
>How-To-Repeat:
kldload geom_cache
gcache label -v -b 32768 -s 65536
Label is written successfully but gem_cache compains to kernel log:
GEOM_CACHE: Invalid size for device ca0.
That's because le16dec() decodes 65536 as zero cache size.
>Fix:
--- sys/geom/cache/g_cache.h.orig 2010-03-14 17:36:16.0 +0700
+++ sys/geom/cache/g_cache.h2010-03-14 17:35:25.0 +0700
@@ -139,7 +139,7 @@
md->md_version = le32dec(data + 16);
bcopy(data + 20, md->md_name, sizeof(md->md_name));
md->md_bsize = le32dec(data + 36);
- md->md_size = le16dec(data + 40);
+ md->md_size = le32dec(data + 40);
md->md_provsize = le64dec(data + 44);
}
>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/107439: 6.2-PRE repeatable panic: userret: Returning with 1 locks held
The following reply was made to PR kern/107439; it has been noted by GNATS. From: Eugene Grosbein To: Mikolaj Golub Cc: bug-follo...@freebsd.org Subject: Re: kern/107439: 6.2-PRE repeatable panic: userret: Returning with 1 locks held Date: Fri, 02 Apr 2010 17:20:58 +0700 Mikolaj Golub wrote: > I have tested the patch and it works for me. It works for me too. Thank you very much! I'll continue to run kernel compiled with this patch to check if it will be so stable as it was without the patch. Eugene Grosbein ___ 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/107439: 6.2-PRE repeatable panic: userret: Returning with 1 locks held
The following reply was made to PR kern/107439; it has been noted by GNATS.
From: Eugene Grosbein
To: Mikolaj Golub
Cc: bug-follo...@freebsd.org, Kostik Belousov
Subject: Re: kern/107439: 6.2-PRE repeatable panic: userret: Returning with
1 locks held
Date: Fri, 02 Apr 2010 18:16:49 +0700
Mikolaj Golub wrote:
> I have tested the patch and it works for me.
I've also found and tested another patch
sent to freebsd-fs@ by Kostik Belousov.
It works for me too. I'll run it for some time.
Of course, I do not apply both patches same time.
I'm copying it here for completeness.
--- sys/kern/vfs_default.c.orig
+++ sys/kern/vfs_default.c
@@ -67,6 +67,7 @@ __FBSDID("$FreeBSD$");
#include
static intvop_nolookup(struct vop_lookup_args *);
+static intvop_norename(struct vop_rename_args *);
static intvop_nostrategy(struct vop_strategy_args *);
static intget_next_dirent(struct vnode *vp, struct dirent **dpp,
char *dirbuf, int dirbuflen, off_t *off,
@@ -113,6 +114,7 @@ struct vop_vector default_vnodeops = {
.vop_poll = vop_nopoll,
.vop_putpages = vop_stdputpages,
.vop_readlink = VOP_EINVAL,
+ .vop_rename = vop_norename,
.vop_revoke = VOP_PANIC,
.vop_strategy = vop_nostrategy,
.vop_unlock = vop_stdunlock,
@@ -206,6 +208,27 @@ vop_nolookup(ap)
}
/*
+ * vop_norename:
+ *
+ * Handle unlock and reference counting for arguments of vop_rename
+ * for filesystems that do not implement rename operation.
+ */
+static int
+vop_norename(struct vop_rename_args *ap)
+{
+
+ if (ap->a_tvp != NULL)
+ vput(ap->a_tvp);
+ if (ap->a_tdvp == ap->a_tvp)
+ vrele(ap->a_tdvp);
+ else
+ vput(ap->a_tdvp);
+ vrele(ap->a_fdvp);
+ vrele(ap->a_fvp);
+ return (EOPNOTSUPP);
+}
+
+/*
*vop_nostrategy:
*
*Strategy routine for VFS devices that have none.
Eugene Grosbein
___
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/138341: [nanobsd] [patch] 8.0-BETA3: nanobsd build broken due to sysipc kernel module
The following reply was made to PR kern/138341; it has been noted by GNATS.
From: Eugene Grosbein
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/138341: [nanobsd] [patch] 8.0-BETA3: nanobsd build broken due
to sysipc kernel module
Date: Sun, 25 Apr 2010 23:07:22 +0700
Hi!
'make MODULES_WITH_WORLD=yes buildworld' is still broken
and now even more modules prevent such build from success.
Here is the patch fixing all of them. Please commit this,
'MODULES_WITH_WORLD=yes' is really useful for NanoBSD builds.
--- sys/modules/dtrace/lockstat/Makefile.orig 2009-09-16 23:05:25.0
+0800
+++ sys/modules/dtrace/lockstat/Makefile 2009-09-16 23:05:45.0
+0800
@@ -5,7 +5,7 @@
KMOD= lockstat
SRCS= lockstat.c
-SRCS+=vnode_if.h
+SRCS+=vnode_if.h opt_kdtrace.h
CFLAGS+= -I${.CURDIR}/../../../cddl/compat/opensolaris \
-I${.CURDIR}/../../../cddl/contrib/opensolaris/uts/common \
--- mqueue/Makefile.orig 2010-04-24 17:47:03.0 +0700
+++ mqueue/Makefile2010-04-24 17:47:14.0 +0700
@@ -5,6 +5,6 @@
KMOD= mqueuefs
SRCS= uipc_mqueue.c \
vnode_if.h \
- opt_posix.h
+ opt_posix.h opt_compat.h
.include
--- sys/modules/sem/Makefile.orig 2010-04-24 18:07:32.0 +0700
+++ sys/modules/sem/Makefile 2010-04-24 18:07:08.0 +0700
@@ -3,6 +3,6 @@
.PATH: ${.CURDIR}/../../kern
KMOD= sem
-SRCS= uipc_sem.c opt_posix.h vnode_if.h
+SRCS= uipc_sem.c opt_posix.h opt_compat.h vnode_if.h
.include
--- sys/modules/sysvipc/sysvmsg/Makefile.orig 2009-08-30 19:12:16.0
+0800
+++ sys/modules/sysvipc/sysvmsg/Makefile 2009-09-19 01:12:18.0
+0800
@@ -3,6 +3,6 @@
.PATH: ${.CURDIR}/../../../kern
KMOD= sysvmsg
-SRCS= sysv_msg.c opt_sysvipc.h
+SRCS= sysv_msg.c opt_sysvipc.h opt_compat.h
.include
--- sys/modules/sysvipc/sysvsem/Makefile.orig 2009-08-30 19:52:13.0
+0800
+++ sys/modules/sysvipc/sysvsem/Makefile 2009-08-30 19:52:33.0
+0800
@@ -3,6 +3,6 @@
.PATH: ${.CURDIR}/../../../kern
KMOD= sysvsem
-SRCS= sysv_sem.c opt_sysvipc.h
+SRCS= sysv_sem.c opt_sysvipc.h opt_compat.h
.include
--- sys/modules/usb/usb/Makefile.orig 2010-04-24 18:27:52.0 +0700
+++ sys/modules/usb/usb/Makefile 2010-04-24 18:28:56.0 +0700
@@ -31,7 +31,7 @@
KMOD= usb
SRCS= bus_if.h device_if.h usb_if.h usb_if.c vnode_if.h \
- opt_usb.h opt_bus.h \
+ opt_usb.h opt_bus.h opt_ddb.h \
usbdevs.h usbdevs_data.h \
usb_busdma.c usb_controller.c usb_compat_linux.c usb_core.c usb_debug.c
\
usb_dev.c usb_device.c usb_dynamic.c usb_error.c usb_generic.c \
___
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/138347: [patch] [nanobsd] nanobsd build is broken due to mdconfig(8) change
The following reply was made to PR misc/138347; it has been noted by GNATS. From: Eugene Grosbein To: bug-follo...@freebsd.org Cc: Subject: Re: misc/138347: [patch] [nanobsd] nanobsd build is broken due to mdconfig(8) change Date: Mon, 26 Apr 2010 00:40:02 +0700 Hi! The problem was solved in RELENG_8 with the revision 1.51.2.2 of src/tools/tools/nanobsd/nanobsd.sh (it now removes trap handler so double mdconfig call is avoided). Please close this PR. Eugene Grosbein ___ 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/146871: [patch] provide descriprive string for D-Link DUB-7H USB hub
>Number: 146871 >Category: kern >Synopsis: [patch] provide descriprive string for D-Link DUB-7H USB hub >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Sun May 23 22:06:51 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Eugene Grosbein >Release:FreeBSD 8.0-STABLE i386 >Organization: RDTC JSC >Environment: System: FreeBSD grosbein.pp.ru 8.0-STABLE FreeBSD 8.0-STABLE #14: Thu Apr 29 21:06:57 NOVST 2010 r...@grosbein.pp.ru:/usr/local/obj/usr/local/src/sys/DADV i386 >Description: D-Link DUB-H7 is 7-Port USB 2.0 Hub with active power supply. Recently I've bought one and noticed it does not provide a descriptive string. It is attached as: uhub6: on usbus4 uhub6: 7 ports with 7 removable, self powered >How-To-Repeat: Plug DUB-H7 into FreeBSD 8 system >Fix: The patch provides description to kernels compiled with "options USB_VERBOSE". The string follows the style for similar BELKIN F5U23 USB2.0 7-Port Hub that is already in usbdevs. --- sys/dev/usb/usbdevs.orig2010-05-22 18:41:20.0 +0700 +++ sys/dev/usb/usbdevs 2010-05-22 19:02:29.0 +0700 @@ -1345,6 +1345,7 @@ product DLINK DSB650TX30x400b 10/100 Ethernet product DLINK DSB650TX20x4102 10/100 Ethernet product DLINK DSB650 0xabc1 10/100 Ethernet +product DLINK DUBH70xf103 DUB-H7 USB 2.0 7-Port Hub product DLINK2 DWA120 0x3a0c DWA-120 product DLINK2 DWA120_NF 0x3a0d DWA-120 (no firmware) product DLINK2 DWLG122C1 0x3c03 DWL-G122 c1 Eugene Grosbein >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/147352: [net] [patch] replace printf() with log() for "Limiting ..."
>Number: 147352
>Category: kern
>Synopsis: [net] [patch] replace printf() with log() for "Limiting ..."
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Thu Jun 03 03:00:13 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Eugene Grosbein
>Release:FreeBSD 8.0-STABLE i386
>Organization:
RDTC JSC
>Environment:
System: FreeBSD eg.sd.rdtc.ru 8.0-STABLE FreeBSD 8.0-STABLE #13: Fri Apr 30
11:44:37 NOVST 2010 r...@eg.sd.rdtc.ru:/usr/local/obj/usr/local/src/sys/EG i386
>Description:
Lots of messages 'Limiting open port RST response from 114 to 100
packets/sec'
flood dmesg buffer when FreeBSD server is attached or portscanned often.
Such diagnostics should be manageble with syslog.conf and not printed
with kernel printf.
>How-To-Repeat:
See above.
>Fix:
--- sys/netinet/ip_icmp.c.orig 2010-06-03 09:26:47.0 +0700
+++ sys/netinet/ip_icmp.c 2010-06-03 09:31:24.0 +0700
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
#include
@@ -994,7 +995,7 @@
* the previous behaviour at the expense of added complexity.
*/
if (V_icmplim_output && opps > V_icmplim)
- printf("Limiting %s from %d to %d packets/sec\n",
+ log(LOG_WARNING, "Limiting %s from %d to %d
packets/sec\n",
r->type, opps, V_icmplim);
}
return 0; /* okay to send packet */
>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: [Bug 205398] [regression] [tty] tty_drain() kernel function lacks timeout support it had before
18.12.2015 23:05, Bruce Evans пишет:
On Fri, 18 Dec 2015 a bug system that doesn't want replies wrote:
Revision 181905 by e...@freebsd.org brought the new MPSAFE TTY layer and removed
"drainwain" timeout support. Now applications working with serial port can hang
forever on close() system call:
It brought many other bugs. About 20 more related to draining.
Some of the other bugs accidentally ameliorate this one. The tty layer
never waits long enough for the last few characters to drain (though
I finished fixing this for sio in 1996). So it takes a large buffer
to possibly give an endless wait. Flow control must be on for the
wait to be endless. Flow control is also broken...
There is a hack for last-close that is supposed to give a hard-coded timeout
of 1 second. Not sure why this doesn't work for you. My quick fix that
restores the timeout uses slightly different logic where this hack was.
I've made a mistake (now corrected) while filling PR: my system is 9.3-STABLE
and not 10.2-STABLE. It has no "leaving" case hack.
The timeout is also a hack (breaks POSIX conformance), but at least the
user can control it and it doesn't default to a too small value. The
old default of 300 seconds was a bit too large, but I kept it. My systems
have always changed this to 180 seconds in /etc/rc.d. I set it to 1
second per-device only transiently.
- an application opens /dev/cuau0 in non-blocing i/o mode and tries to detect
GSM gateway there writing commands like ATZ, ATE1 etc. to the device;
- the device may be dead (lost power, broken, disconnected etc.) and does not
answer back;
Old versions also had a hack by me that breaks waiting in last-close if
the device is in non-blocking mode.
If the device is really disconnected, then the tty should be in a zombie
state and should not wait. I think this still works. CLOCAL or lack of
modem signals may break detection of last-close.
The device does not get disconnected in process, it was not connected
from the moment of open().
Did you have CRTSCTS flow control enabled? This is probably the main
source of hangs. The RTS and CTS signals are not ignored in CLOCAL mode,
flow control should be invoked when they go away when th device goes
away.
It has both of CRTSCTS flow control and CLOCAL enabled and
I'd like to keep them both enabled and working.
- application timeouts waiting for answer and closes device with close()
- tty layer tries to drain output "forever", until a signal arrives.
Perhaps the hard-coded 1 second timeout only works for close() in exit().
So it helps more for sloppy applications that exit without waiting for
their data to go out.
Applications that do the above are still sloppy. POSIX specifies waiting
"forever" again to drain in close(). A non-buggy application would do:
write();
// set up timeout for draining
tcdrain();
// when timeout expires, try to recover
// when recovery is impossible, clean up and exit
tcflush();// this is a critical step in the cleanup
// set up timeout for closing, just in case there is a kernel bug
close();// now it can't block unless there was a kernel bug
gnokii (comms/gnokii) suffers from this problem.
Please re-implement tunable timeout and TIOCSDRAINWAIT syscall kernel has
before.
This is mostly fixed in my version. I started to cut out the patches,
but they were too entwined with other fixes. Here is the part that
replaces the hard-coded 1 second timeout:
X diff -c2 ./kern/tty.c~ ./kern/tty.c
X *** ./kern/tty.c~Thu Mar 19 18:23:08 2015
X --- ./kern/tty.cSat Aug 8 11:40:23 2015
X ***
X *** 133,155
X return (0);
X X ! while (ttyoutq_bytesused(&tp->t_outq) > 0) {
X ttydevsw_outwakeup(tp);
X /* Could be handled synchronously. */
X bytesused = ttyoutq_bytesused(&tp->t_outq);
X ! if (bytesused == 0)
X return (0);
X X /* Wait for data to be drained. */
X ! if (leaving) {
X revokecnt = tp->t_revokecnt;
X ! error = tty_timedwait(tp, &tp->t_outwait, hz);
X switch (error) {
X case ERESTART:
X if (revokecnt != tp->t_revokecnt)
X error = 0;
X break;
X case EWOULDBLOCK:
X ! if (ttyoutq_bytesused(&tp->t_outq) < bytesused)
X error = 0;
X break;
X }
X --- 196,225
X return (0);
X X ! while (ttyoutq_bytesused(&tp->t_outq) != 0 || tp->t_flags & TS_BUSY) {
Strange diff format... Should patch(1) apply this with all those X'es ?
Thank you for answer, anyway! I'll try to understand and test patches next week.
For a quick fix, try turning off flow control (both hardware and software)
in last-close. This should limit the wait. Only large buffers or small
speeds take very long to drain if draining is not blocked
Re: kern/184176: [patch] [vimage] introduce new src.conf knob WITH_VIMAGE
The following reply was made to PR kern/184176; it has been noted by GNATS. From: Eugene Grosbein To: bug-follo...@freebsd.org Cc: Andriy Gapon , emulat...@freebsd.org Subject: Re: kern/184176: [patch] [vimage] introduce new src.conf knob WITH_VIMAGE Date: Sat, 01 Mar 2014 22:59:22 +0700 Hi! virtualbox-ose-4.3.6 built with virtualbox-ose-kmod-4.3.6 panices kernel at the moment of vboxnet initialization if kernel is built with options VIMAGE. We need WITH_VIMAGE make.conf knob at least for ports but several stock kernel modules like ng_ether.ko, if_gif.ko must be built with respect to VIMAGE and will benefit from new knob too. Please commit the patch from http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/184176 Eugene Grosbein ___ 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/184176: [patch] [vimage] introduce new src.conf knob WITH_VIMAGE
The following reply was made to PR kern/184176; it has been noted by GNATS. From: Eugene Grosbein To: bug-follo...@freebsd.org Cc: Andriy Gapon , emulat...@freebsd.org Subject: Re: kern/184176: [patch] [vimage] introduce new src.conf knob WITH_VIMAGE Date: Sat, 01 Mar 2014 22:59:28 +0700 Hi! virtualbox-ose-4.3.6 built with virtualbox-ose-kmod-4.3.6 panices kernel at the moment of vboxnet initialization if kernel is built with options VIMAGE. We need WITH_VIMAGE make.conf knob at least for ports but several stock kernel modules like ng_ether.ko, if_gif.ko must be built with respect to VIMAGE and will benefit from new knob too. Please commit the patch from http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/184176 Eugene Grosbein ___ 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"
bin/187526: [patch] traceroute -a breaks of "whois" socket timeout
>Number: 187526
>Category: bin
>Synopsis: [patch] traceroute -a breaks of "whois" socket timeout
>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: Thu Mar 13 11:00:00 UTC 2014
>Closed-Date:
>Last-Modified:
>Originator: Eugene Grosbein
>Release:FreeBSD 8.4-STABLE amd64
>Organization:
RDTC JSC
>Environment:
System: FreeBSD eg.sd.rdtc.ru 8.4-STABLE FreeBSD 8.4-STABLE #3 r251830M: Mon
Sep 30 18:01:03 NOVT 2013
r...@eg.sd.rdtc.ru:/usr/local/obj/usr/local/src/sys/EG amd64
>Description:
"traceroute -a" opens TCP socket to whois server and fails to check
if this socket stays valid during (sometimes long) runtime.
If whois server closes this connection, traceroute gets EOF at next
hop (and shows AS0) and is killed with SIGPIPE later.
>How-To-Repeat:
$ traceroute -Ia 194.150.149.239
traceroute to 194.150.149.239 (194.150.149.239), 64 hops max, 72 byte packets
1 [AS29072] 62.231.161.217 (62.231.161.217) 0.276 ms 0.268 ms 0.189 ms
2 [AS29072] k-45.rdtc.ru (62.231.160.42) 1.169 ms 0.496 ms 0.706 ms
3 [AS29072] asbr.rdtc.ru (62.231.191.137) 0.467 ms 0.548 ms 0.498 ms
4 [AS31133] 37.29.3.49 (37.29.3.49) 1.423 ms 1.650 ms 1.374 ms
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 [AS0] 37.29.107.202 (37.29.107.202) 70.641 ms 70.599 ms 70.525 ms
Here traceroute is killed. Instead, it should show complete trace:
11 [AS31133] 37.29.107.202 (37.29.107.202) 104.550 ms 70.603 ms 72.888 ms
12 [AS12389] 95.167.91.93 (95.167.91.93) 166.594 ms 65.702 ms 65.790 ms
13 [AS12389] customer-as41440.xe-0-2-0.brnl-rgr3.sib.ip.rostelecom.ru
(188.254.36.146) 68.412 ms 68.322 ms 68.287 ms
14 [AS41440] ge-0-0-0-v501.bar-csr1.ncc.sibirtelecom.ru (213.228.118.6)
85.369 ms 101.501 ms 85.300 ms
15 [AS12846] 212.94.98.54 (212.94.98.54) 85.021 ms 85.116 ms 85.004 ms
16 [AS12846] Bsk-ATS24-c7301.mss.ab.ru (212.94.101.129) 74.240 ms 74.504 ms
74.214 ms
17 [AS12846] adsl-149-239.biysk.ru (194.150.149.239) 103.236 ms 103.358 ms
103.013 ms
>Fix:
A workaround is to lower wait time for proble timeout using '-w 1'
option.
The following patch fixes the problem introducing proper error checking
while reading/writing "whois" connection. In case of error it
reconnects.
--- as.h.orig 2013-06-17 11:18:23.0 +0700
+++ as.h2014-03-13 17:13:48.0 +0700
@@ -31,5 +31,5 @@
*/
void *as_setup(const char *);
-unsigned int as_lookup(void *, char *, sa_family_t);
+unsigned int as_lookup(void *, char *, sa_family_t, int *);
void as_shutdown(void *);
--- as.c.orig 2013-06-17 11:18:23.0 +0700
+++ as.c2014-03-13 17:37:51.0 +0700
@@ -119,7 +119,7 @@ as_setup(const char *server)
}
unsigned int
-as_lookup(void *_asn, char *addr, sa_family_t family)
+as_lookup(void *_asn, char *addr, sa_family_t family, int *status)
{
struct aslookup *asn = _asn;
char buf[1024];
@@ -129,8 +129,17 @@ as_lookup(void *_asn, char *addr, sa_fam
as = 0;
rc = dlen = 0;
plen = (family == AF_INET6) ? 128 : 32;
- (void)fprintf(asn->as_f, "!r%s/%d,l\n", addr, plen);
- (void)fflush(asn->as_f);
+ *status = fprintf(asn->as_f, "!r%s/%d,l\n", addr, plen);
+ if (*status < 0) {
+ *status = errno;
+ return 0;
+ }
+ *status = fflush(asn->as_f);
+ if (*status == EOF) {
+ *status = errno;
+ return 0;
+ }
+ *status = 0;
#ifdef AS_DEBUG_FILE
if (asn->as_debug) {
@@ -139,7 +148,14 @@ as_lookup(void *_asn, char *addr, sa_fam
}
#endif /* AS_DEBUG_FILE */
- while (fgets(buf, sizeof(buf), asn->as_f) != NULL) {
+ while (1) {
+ if (fgets(buf, sizeof(buf), asn->as_f) == NULL) {
+ if(feof(asn->as_f) || ferror(asn->as_f)) {
+ *status = EIO;
+ return 0;
+ }
+ break;
+ }
buf[sizeof(buf) - 1] = '\0';
#ifdef AS_DEBUG_FILE
--- traceroute.c.orig 2013-06-17 11:18:23.0 +0700
+++ traceroute.c2014-03-13 17:27:14.0 +0700
@@ -931,6 +931,8 @@
as_path = 0;
}
}
+ if (as_path)
+ signal(SIGPIPE, SIG_IGN);
#ifdefined(IPSEC) && defined(IPSEC_POLICY_IPSEC)
if (setpolicy(sndsock, "in bypass") < 0)
@@ -1471,6 +1473,7 @@
{
register struct ip *ip;
register
kern/188092: [patch] icmp_error() fails to clear "fragmented" flag in the IP header
>Number: 188092 >Category: kern >Synopsis: [patch] icmp_error() fails to clear "fragmented" flag in the >IP header >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: Sun Mar 30 18:30:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Eugene Grosbein >Release:FreeBSD 9.2-STABLE amd64 >Organization: RDTC JSC >Environment: System: FreeBSD grosbein.net 9.2-STABLE FreeBSD 9.2-STABLE #3 r261670M: Sat Mar 1 22:38:42 NOVT 2014 r...@grosbein.net:/usr/obj/usr/local/src/sys/DADV amd64 >Description: icmp_error() function copies "more fragments" flag from original IP header. This may generate "fragmented" ICMP error packet if original IP packed was fragmented. >How-To-Repeat: Run "traceroute -I outerhost 1501" when your mtu is 1500 or less and next hop is FreeBSD router. You will see only "stars" for the first hop because of this error. >Fix: --- sys/netinet/ip_icmp.c.orig 2013-10-21 21:07:06.0 +0700 +++ sys/netinet/ip_icmp.c 2014-03-31 00:06:48.0 +0700 @@ -332,6 +332,7 @@ stdreply: icmpelen = max(8, min(V_icmp_q * reply should bypass as well. */ m->m_flags |= n->m_flags & M_SKIP_FIREWALL; + m->m_flags &= ~(M_FRAG | M_FIRSTFRAG | M_LASTFRAG); m->m_data -= sizeof(struct ip); m->m_len += sizeof(struct ip); m->m_pkthdr.len = m->m_len; @@ -343,6 +344,7 @@ stdreply: icmpelen = max(8, min(V_icmp_q nip->ip_hl = 5; nip->ip_p = IPPROTO_ICMP; nip->ip_tos = 0; + nip->ip_off = 0; icmp_reflect(m); freeit: >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: bin/187526: [patch] traceroute -a breaks of "whois" socket timeout
The following reply was made to PR bin/187526; it has been noted by GNATS.
From: Eugene Grosbein
To: bug-follo...@freebsd.org
Cc:
Subject: Re: bin/187526: [patch] traceroute -a breaks of "whois" socket timeout
Date: Mon, 31 Mar 2014 23:53:22 +0700
This is a multi-part message in MIME format.
--040008040404060404030001
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Here comes corrected version of patch that fixes traceroute6 too
(and unbreaks world building).
--040008040404060404030001
Content-Type: text/plain; charset=KOI8-R;
name="traceroute.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="traceroute.diff"
--- contrib/traceroute/as.h.orig 2013-06-17 11:18:23.0 +0700
+++ contrib/traceroute/as.h2014-03-13 17:13:48.0 +0700
@@ -31,5 +31,5 @@
*/
void *as_setup(const char *);
-unsigned int as_lookup(void *, char *, sa_family_t);
+unsigned int as_lookup(void *, char *, sa_family_t, int *);
void as_shutdown(void *);
--- contrib/traceroute/as.c.orig 2013-06-17 11:18:23.0 +0700
+++ contrib/traceroute/as.c2014-03-13 17:37:51.0 +0700
@@ -119,7 +119,7 @@ as_setup(const char *server)
}
unsigned int
-as_lookup(void *_asn, char *addr, sa_family_t family)
+as_lookup(void *_asn, char *addr, sa_family_t family, int *status)
{
struct aslookup *asn = _asn;
char buf[1024];
@@ -129,8 +129,17 @@ as_lookup(void *_asn, char *addr, sa_fam
as = 0;
rc = dlen = 0;
plen = (family == AF_INET6) ? 128 : 32;
- (void)fprintf(asn->as_f, "!r%s/%d,l\n", addr, plen);
- (void)fflush(asn->as_f);
+ *status = fprintf(asn->as_f, "!r%s/%d,l\n", addr, plen);
+ if (*status < 0) {
+ *status = errno;
+ return 0;
+ }
+ *status = fflush(asn->as_f);
+ if (*status == EOF) {
+ *status = errno;
+ return 0;
+ }
+ *status = 0;
#ifdef AS_DEBUG_FILE
if (asn->as_debug) {
@@ -139,7 +148,14 @@ as_lookup(void *_asn, char *addr, sa_fam
}
#endif /* AS_DEBUG_FILE */
- while (fgets(buf, sizeof(buf), asn->as_f) != NULL) {
+ while (1) {
+ if (fgets(buf, sizeof(buf), asn->as_f) == NULL) {
+ if(feof(asn->as_f) || ferror(asn->as_f)) {
+ *status = EIO;
+ return 0;
+ }
+ break;
+ }
buf[sizeof(buf) - 1] = '\0';
#ifdef AS_DEBUG_FILE
--- contrib/traceroute/traceroute.c.orig 2013-06-17 11:18:23.0
+0700
+++ contrib/traceroute/traceroute.c2014-03-13 17:27:14.0 +0700
@@ -931,6 +931,8 @@
as_path = 0;
}
}
+ if (as_path)
+ signal(SIGPIPE, SIG_IGN);
#if defined(IPSEC) && defined(IPSEC_POLICY_IPSEC)
if (setpolicy(sndsock, "in bypass") < 0)
@@ -1471,6 +1473,7 @@
{
register struct ip *ip;
register int hlen;
+ int as, status;
char addr[INET_ADDRSTRLEN];
ip = (struct ip *) buf;
@@ -1479,8 +1482,24 @@
strlcpy(addr, inet_ntoa(from->sin_addr), sizeof(addr));
- if (as_path)
- Printf(" [AS%u]", as_lookup(asn, addr, AF_INET));
+ while(as_path) {
+ as = as_lookup(asn, addr, AF_INET, &status);
+ if (status) {
+ as_shutdown(asn);
+ asn = as_setup(as_server);
+ if (asn == NULL) {
+ Fprintf(stderr, "%s: as_setup failed, AS#
lookups"
+ " disabled\n", prog);
+ (void)fflush(stderr);
+ as_path = 0;
+ break;
+ }
+ else
+ continue;
+ }
+ Printf(" [AS%u]", as);
+ break;
+ }
if (nflag)
Printf(" %s", addr);
--- usr.sbin/traceroute6/traceroute6.c.orig2013-10-21 21:03:06.0
+0700
+++ usr.sbin/traceroute6/traceroute6.c 2014-03-24 00:25:21.0 +0700
@@ -885,6 +885,8 @@ main(argc, argv)
as_path = 0;
}
}
+ if (as_path)
+ signal(SIGPIPE, SIG_IGN);
/*
* Message to users
@@ -1376,13 +1378,30 @@ print(mhdr, cc)
int cc;
{
struct sockaddr_in6 *from = (struct sockaddr_in6 *)mhdr->msg_name;
+ int as, status;
char hbuf[NI_MAXHOST];
if (getnameinfo((struct
bin/190133: [patch] last(1) still mentiones non-existing wtmp
>Number: 190133
>Category: bin
>Synopsis: [patch] last(1) still mentiones non-existing wtmp
>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: Fri May 23 06:40:00 UTC 2014
>Closed-Date:
>Last-Modified:
>Originator: Eugene Grosbein
>Release:FreeBSD 9.2-STABLE amd64
>Organization:
RDTC JSC
>Environment:
System: FreeBSD k-45-monitor 9.2-STABLE FreeBSD 9.2-STABLE #24 r265054M: Mon
May 5 20:04:48 NOVT 2014
root@k-45-monitor:/usr/obj/usr/local/src/sys/K-45-MONITOR amd64
>Description:
Modern versions of FreeBSD moved from wtmp to utx.log
and last(1) deals with utx.log but still prints "wtmp begins ..."
at the end of output.
Also, "last -f filename" does not affect this output but it should.
>How-To-Repeat:
Run "last".
>Fix:
--- usr.bin/last/last.c.orig2013-06-18 14:52:57.0 +0700
+++ usr.bin/last/last.c 2014-05-23 13:29:24.0 +0700
@@ -229,8 +229,8 @@ wtmp(void)
doentry(&buf[--amount]);
tm = localtime(&t);
- (void) strftime(ct, sizeof(ct), "\nwtmp begins %+\n", tm);
- printf("%s", ct);
+ (void) strftime(ct, sizeof(ct), "\n%%s begins %+\n", tm);
+ printf(ct, file);
}
/*
>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/169236: [regression] [net] 8.3-STABLE panices on "ifconfig bridgeN destroy"
>Number: 169236 >Category: kern >Synopsis: [regression] [net] 8.3-STABLE panices on "ifconfig bridgeN >destroy" >Confidential: no >Severity: serious >Priority: high >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Jun 19 09:40:15 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Eugene Grosbein >Release:FreeBSD 8.3-STABLE amd64 >Organization: RDTC JSC >Environment: System: FreeBSD k-45-pc-1.sd.rdtc.ru 8.3-STABLE FreeBSD 8.3-STABLE #37: Wed Jun 13 12:25:17 NOVT 2012 r...@k-45-pc-1.sd.rdtc.ru:/usr/local/obj/home/src/sys/PPPOE amd64 >Description: vlan2127 is created on lagg1 and added as member to bridge2127 (no other members). lagg1, vlan2127 and bridge2127 are UP. For 8.2-STABLE, the command "ifconfig bridge2127 destroy" works just fine. For 8.3-STABLE, it panices the kernel. >How-To-Repeat: See above. Here is kgdb output for crashdump obtained after panic: Script started on Tue Jun 19 16:25:19 2012 kgdb kernel /home/crash/k-45-pc-3/vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 02 fault virtual address = 0x30 fault code = supervisor write data, page not present instruction pointer = 0x20:0x803bb077 stack pointer = 0x28:0xff81254f4800 frame pointer = 0x28:0xff81254f4830 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 13897 (ifconfig) trap number = 12 panic: page fault cpuid = 3 KDB: stack backtrace: db_trace_self_wrapper() at 0x801adcca = db_trace_self_wrapper+0x2a kdb_backtrace() at 0x803305d7 = kdb_backtrace+0x37 panic() at 0x802fd22e = panic+0x1ce trap_fatal() at 0x804f3150 = trap_fatal+0x290 trap_pfault() at 0x804f34de = trap_pfault+0x23e trap() at 0x804f39ae = trap+0x3ce calltrap() at 0x804da774 = calltrap+0x8 --- trap 0xc, rip = 0x803bb077, rsp = 0xff81254f4800, rbp = 0xff81254f4830 --- bridge_linkstate() at 0x803bb077 = bridge_linkstate+0x27 bridge_delete_member() at 0x803bb2f1 = bridge_delete_member+0x141 bridge_clone_destroy() at 0x803bdbaa = bridge_clone_destroy+0x6a ifc_simple_destroy() at 0x803c03aa = ifc_simple_destroy+0x2a if_clone_destroyif() at 0x803c05ad = if_clone_destroyif+0xbd if_clone_destroy() at 0x803c095d = if_clone_destroy+0xcd ifioctl() at 0x803b9329 = ifioctl+0x2c9 kern_ioctl() at 0x80341722 = kern_ioctl+0x102 ioctl() at 0x80341950 = ioctl+0xf0 amd64_syscall() at 0x804f2724 = amd64_syscall+0x1f4 Xfast_syscall() at 0x804daa6c = Xfast_syscall+0xfc --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800a74c9c, rsp = 0x7fffe328, rbp = 0x7fffee34 --- Uptime: 52s Dumping 354 out of 4079 MB:..5%..14%..23%..32%..41%..55%..64%..73%..82%..91% Reading symbols from /boot/kernel/ipmi.ko...done. Loaded symbols for /boot/kernel/ipmi.ko #0 doadump () at /home/src/sys/kern/kern_shutdown.c:268 268 if (textdump_pending) (kgdb) bt #0 doadump () at /home/src/sys/kern/kern_shutdown.c:268 #1 0x802fcd2a in boot (howto=260) at /home/src/sys/kern/kern_shutdown.c:448 #2 0x802fd207 in panic (fmt=0x1 ) at /home/src/sys/kern/kern_shutdown.c:639 #3 0x804f3150 in trap_fatal (frame=0xc, eva=Variable "eva" is not available. ) at /home/src/sys/amd64/amd64/trap.c:848 #4 0x804f34de in trap_pfault (frame=0xff81254f4750, usermode=0) at /home/src/sys/amd64/amd64/trap.c:764 #5 0x804f39ae in trap (frame=0xff81254f4750) at /home/src/sys/amd64/amd64/trap.c:457 #6 0x804da774 in calltrap () at /home/src/sys/amd64/amd64/exception.S:228 #7 0x803bb077 in bridge_linkstate (ifp=0xff000576e960) at pcpu.h:224 #8 0x803bb2f1 in bridge_delete_member (sc=0xff01030ea000, bif=0xff0103143600, gone=0) at /home/src/sys/net/if_bridge.c:996 #9 0x803bdbaa in bridge_clone_destroy (ifp=0xff01030a3960) at /home/src/sys/net/if_bridge.c:675 #10 0x803c03aa in ifc_simple_destroy (ifc=0x806ee1
Re: kern/169236: [regression] [net] 8.3-STABLE panices on "ifconfig bridgeN destroy"
The following reply was made to PR kern/169236; it has been noted by GNATS. From: Eugene Grosbein To: bug-follo...@freebsd.org Cc: Subject: Re: kern/169236: [regression] [net] 8.3-STABLE panices on "ifconfig bridgeN destroy" Date: Tue, 19 Jun 2012 18:13:49 +0700 Hi! Sorry, I should have checked more recent STABLE first. The problem has been fixed 4 days ago with SVN revision 237104. This PR should be closed. Eugene Grosbein ___ 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"
bin/169439: [patch] Stock ntpd segfaults when used with GPS pps source
>Number: 169439 >Category: bin >Synopsis: [patch] Stock ntpd segfaults when used with GPS pps source >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 Jun 26 09:50:03 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Eugene Grosbein >Release:FreeBSD 8.3-STABLE amd64 >Organization: RDTC JSC >Environment: System: FreeBSD syslog.sd.rdtc.ru 8.3-STABLE FreeBSD 8.3-STABLE #4: Wed Jun 20 01:33:15 NOVT 2012 r...@syslog.sd.rdtc.ru:/usr/local/obj/usr/local/src/sys/SYSLOG amd64 >Description: From my /etc/ntp.conf: # The GPS receiver on cuau3 at 4800 baud # # mode 1 = use $GPRMC statements # time1 = trimming offset # flag3 1 = enable Kernel PPS discipline # server 127.127.20.1 mode 1 iburst maxpoll 9 prefer fudge 127.127.20.1 time1 0.000 flag3 1 refid PPS ntpd segfaults while parsing configuration due to missing check for NULL pointer. >How-To-Repeat: See above >Fix: --- contrib/ntp/ntpd/refclock_nmea.c.orig 2012-06-26 16:10:46.0 +0700 +++ contrib/ntp/ntpd/refclock_nmea.c2012-06-26 16:11:12.0 +0700 @@ -257,7 +257,7 @@ pp = peer->procptr; up = (struct nmeaunit *)pp->unitptr; #ifdef HAVE_PPSAPI - if (up->handle != 0) + if (up && up->handle != 0) time_pps_destroy(up->handle); #endif /* HAVE_PPSAPI */ io_closeclock(&pp->io); >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/171711: [dummynet] [panic] Kernel panic in dummynet
>Number: 171711 >Category: kern >Synopsis: [dummynet] [panic] Kernel panic in dummynet >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Sep 17 14:50:11 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Eugene Grosbein >Release:FreeBSD 8.3-STABLE amd64 >Organization: RDTC JSC >Environment: System: FreeBSD k-45-pc-1.sd.rdtc.ru 8.3-STABLE FreeBSD 8.3-STABLE #37: Wed Jun 13 12:25:17 NOVT 2012 r...@k-45-pc-1.sd.rdtc.ru:/usr/local/obj/home/src/sys/PPPOE amd64 >Description: I run pretty busy mpd-5.6 based PPPoE access server (about 1700 simultaneous connections at most loaded hours). It uses dummynet extensively: each connecting user obtains its own dynamic dummynet pipes. Some time ago this server has crashed. Crashdump points to some dummynet-related code: GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: 0 (dummynet) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at 0x801adf1a = db_trace_self_wrapper+0x2a kdb_backtrace() at 0x80330827 = kdb_backtrace+0x37 panic() at 0x802fd48e = panic+0x1ce trap_fatal() at 0x804f3f80 = trap_fatal+0x290 trap_pfault() at 0x804f430e = trap_pfault+0x23e trap() at 0x804f47de = trap+0x3ce calltrap() at 0x804dac04 = calltrap+0x8 --- trap 0xc, rip = 0x1, rsp = 0xff8122a9ea20, rbp = 0xff8122a9ea40 --- uart_z8530_class() at 0x1 uma_zfree_arg() at 0x804b53da = uma_zfree_arg+0x3a m_freem() at 0x8035c4a7 = m_freem+0x37 dummynet_send() at 0x8040017d = dummynet_send+0x2d dummynet_task() at 0x80400496 = dummynet_task+0x1c6 taskqueue_run_locked() at 0x8033cdf5 = taskqueue_run_locked+0x85 taskqueue_thread_loop() at 0x8033cf8e = taskqueue_thread_loop+0x4e fork_exit() at 0x802d13cf = fork_exit+0x11f fork_trampoline() at 0x804db14e = fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8122a9ecf0, rbp = 0 --- Uptime: 14d8h5m59s Dumping 754 out of 4079 MB:..3%..11%..22%..32%..41%..51%..62%..73%..81%..92% Reading symbols from /boot/kernel/ipmi.ko...done. Loaded symbols for /boot/kernel/ipmi.ko #0 doadump () at /home/src/sys/kern/kern_shutdown.c:268 268 if (textdump_pending) (kgdb) bt #0 doadump () at /home/src/sys/kern/kern_shutdown.c:268 #1 0x802fcf8a in boot (howto=260) at /home/src/sys/kern/kern_shutdown.c:448 #2 0x802fd467 in panic (fmt=0x1 ) at /home/src/sys/kern/kern_shutdown.c:639 #3 0x804f3f80 in trap_fatal (frame=0xc, eva=Variable "eva" is not available. ) at /home/src/sys/amd64/amd64/trap.c:848 #4 0x804f430e in trap_pfault (frame=0xff8122a9e970, usermode=0) at /home/src/sys/amd64/amd64/trap.c:764 #5 0x804f47de in trap (frame=0xff8122a9e970) at /home/src/sys/amd64/amd64/trap.c:457 #6 0x804dac04 in calltrap () at /home/src/sys/amd64/amd64/exception.S:228 #7 0x0001 in ?? () #8 0x802eb967 in mb_dtor_pack (mem=Variable "mem" is not available. ) at /home/src/sys/kern/kern_mbuf.c:453 #9 0x804b53da in uma_zfree_arg (zone=0xff00df773780, item=0xff0054691b00, udata=0x0) at /home/src/sys/vm/uma_core.c:2543 #10 0x8035c4a7 in m_freem (mb=0x0) at mbuf.h:562 #11 0x8040017d in dummynet_send (m=0xff0054691b00) at /home/src/sys/netinet/ipfw/ip_dn_io.c:705 #12 0x80400496 in dummynet_task (context=Variable "context" is not available. ) at /home/src/sys/netinet/ipfw/ip_dn_io.c:615 #13 0x8033cdf5 in taskqueue_run_locked (queue=0xff0003a09380) at /home/src/sys/kern/subr_taskqueue.c:250 #14 0x8033cf8e in taskqueue_thread_loop (arg=Variable "arg" is not available. ) at /home/src/sys/kern/subr_taskqueue.c:387 #15 0x802d13cf in fork_exit (callout=0x8033cf40 , arg=0x80769e80, frame=0xff8122a9ec40) at /home/src/sys/kern/kern_fork.c:876 #16 0x804db14e in fork_trampoline () at /home/src/sys/amd64/amd64/exception.S:602 #17 0x in ?? () #18 0x in ?? () #19 0x in ?? () #20 0x in ?? () #21 0x in ?? () #22 0x in ?? (
kern/172113: [panic] [igb] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type
>Number: 172113
>Category: kern
>Synopsis: [panic] [igb] [patch] 9.1-RC1/amd64 panices in igb(4):
>m_getjcl: invalid cluster type
>Confidential: no
>Severity: critical
>Priority: high
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Thu Sep 27 11:10:09 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Eugene Grosbein
>Release:FreeBSD 9.1-RC1 amd64
>Organization:
RDTC JSC
>Environment:
System: FreeBSD 9.1-RC1
>Description:
We have got SuperMicro-based server (X8DTU-6+ motherboard),
with CPU having 12 cores (with hyperthreadng that's 24 CPUs).
We downloaded 9.1-RC1 installation CD and tried to boot it.
It panices during igb(4) driver init:
http://www.grosbein.net/img/crash-91rc.png
This is 100% repeatable.
>How-To-Repeat:
See above.
>Fix:
Workaround is to disable MSI-X in /boot/loader.conf:
hw.pci.enable_msix=0
This allows us to boot installation CD and install the system.
I've found this problem is pretty old and should have been fixed
over a year ago in 9.0 but it wasn't.
I've found patch by David G. Lawrence in that thread:
http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063963.html
The patch needed some corrections to be applied to 9.1-RC1,
so I've corrected it and it solved the problem.
Here is version for 9.1-RC1:
--- sys/dev/e1000/if_igb.c.orig 2012-09-27 14:57:22.0 +0700
+++ sys/dev/e1000/if_igb.c 2012-09-27 15:04:35.0 +0700
@@ -1328,9 +1328,6 @@
/* Don't lose promiscuous settings */
igb_set_promisc(adapter);
- ifp->if_drv_flags |= IFF_DRV_RUNNING;
- ifp->if_drv_flags &= ~IFF_DRV_OACTIVE;
-
callout_reset(&adapter->timer, hz, igb_local_timer, adapter);
e1000_clear_hw_cntrs_base_generic(&adapter->hw);
@@ -1356,6 +1353,9 @@
/* Set Energy Efficient Ethernet */
if (adapter->hw.phy.media_type == e1000_media_type_copper)
e1000_set_eee_i350(&adapter->hw);
+
+ ifp->if_drv_flags |= IFF_DRV_RUNNING;
+ ifp->if_drv_flags &= ~IFF_DRV_OACTIVE;
}
static void
@@ -1570,6 +1570,11 @@
E1000_WRITE_REG(&adapter->hw, E1000_EIMC, que->eims);
++que->irqs;
+ if (!(adapter->ifp->if_drv_flags & IFF_DRV_RUNNING)) {
+ return;
+ }
+ more_rx = igb_rxeof(que, adapter->rx_process_limit, NULL);
+
IGB_TX_LOCK(txr);
igb_txeof(txr);
#if __FreeBSD_version >= 80
@@ -1583,8 +1588,6 @@
#endif
IGB_TX_UNLOCK(txr);
- more_rx = igb_rxeof(que, adapter->rx_process_limit, NULL);
-
if (adapter->enable_aim == FALSE)
goto no_calc;
/*
>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/172166: Deadlock in the networking code, possible due to a bug in the SCHED_ULE
>Number: 172166 >Category: kern >Synopsis: Deadlock in the networking code, possible due to a bug in the >SCHED_ULE >Confidential: no >Severity: serious >Priority: high >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Sep 29 17:30:01 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Eugene Grosbein >Release:FreeBSD 8.3-STABLE amd64 >Organization: RDTC JSC >Environment: System: FreeBSD 8.3-STABLE/amd64, six-core Intel X5675 CPU (hyperthreading disabled). >Description: I run pretty busy FreeBSD 8.3-STABLE/amd64 based mpd-5.6 PPPoE server that serves hundreds (and sometimes over a thousand) simultaneous connections with high connect/disconnect rate. Also, it sends its logs to remote syslog collector over the net. It also heavily uses ipfw tables for dummynet shaping: every new connected client obtains its IP and this IP is added by mpd to some of ipfw tables. Upon disconnection, mpd removes that IP from tables. Today, my server deadlocked second time in two months: all of its network activity got blocked, even lagg's LACP frames. The kernel and userland were fine, I managed to login using IP KVM console. I have invoked KDB, did 'call doadump', obtained crashdump and rebooted the box. I've digged it a little; it seems syslogd(8) was preempted by the scheduler in the middle of ipfw_lookup_table()/rn_match() sequence while holding reader-lock of "IPFW static rules" rwlock and newer got back. Hence, all network activity broke as ipfw needs writer-lock of "IPFW static rules". Here comes backtrace of syslogd's kernel thread: GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: KDB: enter: Break to debugger Dumping 1135 out of 4079 MB:..2%..12%..22%..32%..41%..51%..61%..71%..81%..91% Error while mapping shared library sections: /boot/kernel/nfsclient.ko: îÅÔ ÔÁËÏÇÏ ÆÁÊÌÁ ÉÌÉ ËÁÔÁÌÏÇÁ. Error while mapping shared library sections: /boot/kernel/nfslock.ko: îÅÔ ÔÁËÏÇÏ ÆÁÊÌÁ ÉÌÉ ËÁÔÁÌÏÇÁ. Error while mapping shared library sections: /boot/kernel/nfs_common.ko: îÅÔ ÔÁËÏÇÏ ÆÁÊÌÁ ÉÌÉ ËÁÔÁÌÏÇÁ. Error while mapping shared library sections: /boot/kernel/krpc.ko: îÅÔ ÔÁËÏÇÏ ÆÁÊÌÁ ÉÌÉ ËÁÔÁÌÏÇÁ. Reading symbols from /boot/kernel/ipmi.ko...done. Loaded symbols for /boot/kernel/ipmi.ko Error while reading shared library symbols: /boot/kernel/nfsclient.ko: îÅÔ ÔÁËÏÇÏ ÆÁÊÌÁ ÉÌÉ ËÁÔÁÌÏÇÁ. Error while reading shared library symbols: /boot/kernel/nfslock.ko: îÅÔ ÔÁËÏÇÏ ÆÁÊÌÁ ÉÌÉ ËÁÔÁÌÏÇÁ. Error while reading shared library symbols: /boot/kernel/nfs_common.ko: îÅÔ ÔÁËÏÇÏ ÆÁÊÌÁ ÉÌÉ ËÁÔÁÌÏÇÁ. Error while reading shared library symbols: /boot/kernel/krpc.ko: îÅÔ ÔÁËÏÇÏ ÆÁÊÌÁ ÉÌÉ ËÁÔÁÌÏÇÁ. #0 doadump () at /home/src/sys/kern/kern_shutdown.c:268 268 if (textdump_pending) (kgdb) thread 134 [Switching to thread 134 (Thread 100201)]#0 sched_switch ( td=0xff0004e00470, newtd=0xff0001b96470, flags=Variable "flags" is not available. ) at /home/src/sys/kern/sched_ule.c:1892 1892cpuid = PCPU_GET(cpuid); (kgdb) bt #0 sched_switch (td=0xff0004e00470, newtd=0xff0001b96470, flags=Variable "flags" is not available. ) at /home/src/sys/kern/sched_ule.c:1892 #1 0x80305c96 in mi_switch (flags=1538, newtd=0x0) at /home/src/sys/kern/kern_synch.c:466 #2 0x803048f5 in critical_exit () at /home/src/sys/kern/kern_switch.c:212 #3 0x802d5733 in intr_event_handle (ie=0xff0001b61100, frame=0xff81254122c0) at /home/src/sys/kern/kern_intr.c:1424 #4 0x804de4ff in intr_execute_handlers (isrc=0xff0001b82a00, frame=0xff81254122c0) at /home/src/sys/amd64/amd64/intr_machdep.c:260 #5 0x804e2287 in lapic_handle_intr (vector=Variable "vector" is not available. ) at /home/src/sys/x86/x86/local_apic.c:771 #6 0x804db2b5 in Xapic_isr1 () at apic_vector.S:86 #7 0x803cdab3 in rn_match (v_arg=0xff81254123d0, head=Variable "head" is not available. ) at /home/src/sys/net/radix.c:352 #8 0x8040c03b in ipfw_lookup_table (ch=Variable "ch" is not available. ) at /home/src/sys/netinet/ipfw/ip_fw_table.c:538 #9 0xff
Re: kern/172166: Deadlock in the networking code, possible due to a bug in the SCHED_ULE
The following reply was made to PR kern/172166; it has been noted by GNATS. From: Eugene Grosbein To: Alexander Motin Cc: bug-follo...@freebsd.org, eu...@eg.sd.rdtc.ru, Andriy Gapon Subject: Re: kern/172166: Deadlock in the networking code, possible due to a bug in the SCHED_ULE Date: Tue, 02 Oct 2012 14:48:04 +0700 02.10.2012 13:58, Alexander Motin ÐÉÛÅÔ: > About rw_lock priority propagation locking(9) tells: > The rw_lock locks have priority propagation like mutexes, but priority > can be propagated only to an exclusive holder. This limitation comes > from the fact that shared owners are anonymous. > > What's about idle stealing threshold, it was fixed in HEAD at r239194, > but wasn't merged yet. It should be trivial to merge it. Would it fix my problem with 6-CPU box? Your commit log talks about "8 or more cores". Eugene Grosbein ___ 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/172166: Deadlock in the networking code, possible due to a bug in the SCHED_ULE
The following reply was made to PR kern/172166; it has been noted by GNATS. From: Eugene Grosbein To: Alexander Motin Cc: bug-follo...@freebsd.org, eu...@eg.sd.rdtc.ru, Andriy Gapon Subject: Re: kern/172166: Deadlock in the networking code, possible due to a bug in the SCHED_ULE Date: Tue, 02 Oct 2012 14:59:31 +0700 02.10.2012 14:53, Alexander Motin ÐÉÛÅÔ: > On 02.10.2012 10:48, Eugene Grosbein wrote: >> 02.10.2012 13:58, Alexander Motin ÐÉÛÅÔ: >>> About rw_lock priority propagation locking(9) tells: >>> The rw_lock locks have priority propagation like mutexes, but priority >>> can be propagated only to an exclusive holder. This limitation comes >>> from the fact that shared owners are anonymous. >>> >>> What's about idle stealing threshold, it was fixed in HEAD at r239194, >>> but wasn't merged yet. It should be trivial to merge it. >> >> Would it fix my problem with 6-CPU box? >> Your commit log talks about "8 or more cores". > > Hmm. Then I see no reason why threads were not stolen, unless they are > bound to specific CPU. Check `sysctl kern.sched.steal_thresh` output to > be sure. All NIC's threads and dummynet are bound in my boxes. igb(4) in RELENG_8 bounds its threads by default in very wrong way, so I rebound them. dummynet(8) in RELENG_8 goes wild under severe load unless bound to single or two cores. kern.sched.steal_thresh: 2 ___ 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/172166: Deadlock in the networking code, possible due to a bug in the SCHED_ULE
The following reply was made to PR kern/172166; it has been noted by GNATS. From: Eugene Grosbein To: Andriy Gapon Cc: bug-follo...@freebsd.org, Alexander Motin Subject: Re: kern/172166: Deadlock in the networking code, possible due to a bug in the SCHED_ULE Date: Thu, 04 Oct 2012 13:12:22 +0700 03.10.2012 21:56, Andriy Gapon ÐÉÛÅÔ: > on 02/10/2012 09:58 Alexander Motin said the following: >> About rw_lock priority propagation locking(9) tells: >> The rw_lock locks have priority propagation like mutexes, but priority can >> be >> propagated only to an exclusive holder. This limitation comes from the >> fact that >> shared owners are anonymous. > > Yeah... and as we see it has a potential to result in priority inversion. > >> What's about idle stealing threshold, it was fixed in HEAD at r239194, but >> wasn't >> merged yet. It should be trivial to merge it. > > And I've also misread the code, confused 6 CPUs case with 8 CPUs case. > > Can I have any advice/workaround/bugfix on how to reconfigure my routers to prevent them from locking this way? ___ 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/172166: Deadlock in the networking code, possible due to a bug in the SCHED_ULE
The following reply was made to PR kern/172166; it has been noted by GNATS. From: Eugene Grosbein To: Andriy Gapon Cc: bug-follo...@freebsd.org, Alexander Motin Subject: Re: kern/172166: Deadlock in the networking code, possible due to a bug in the SCHED_ULE Date: Thu, 04 Oct 2012 13:12:22 +0700 03.10.2012 21:56, Andriy Gapon ÐÉÛÅÔ: > on 02/10/2012 09:58 Alexander Motin said the following: >> About rw_lock priority propagation locking(9) tells: >> The rw_lock locks have priority propagation like mutexes, but priority can >> be >> propagated only to an exclusive holder. This limitation comes from the >> fact that >> shared owners are anonymous. > > Yeah... and as we see it has a potential to result in priority inversion. > >> What's about idle stealing threshold, it was fixed in HEAD at r239194, but >> wasn't >> merged yet. It should be trivial to merge it. > > And I've also misread the code, confused 6 CPUs case with 8 CPUs case. > > Can I have any advice/workaround/bugfix on how to reconfigure my routers to prevent them from locking this way? ___ 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/172166: Deadlock in the networking code, possible due to a bug in the SCHED_ULE
The following reply was made to PR kern/172166; it has been noted by GNATS. From: Eugene Grosbein To: Andriy Gapon Cc: bug-follo...@freebsd.org, Alexander Motin Subject: Re: kern/172166: Deadlock in the networking code, possible due to a bug in the SCHED_ULE Date: Fri, 05 Oct 2012 15:39:58 +0700 04.10.2012 17:23, Andriy Gapon ÐÉÛÅÔ: >> Can I have any advice/workaround/bugfix on how to reconfigure my routers >> to prevent them from locking this way? > > As I said, the primary problem here is the ipmi thread going insane. > You can try to remove ipmi driver, if you can afford that. > Or you can try to hack on it, so that > (1) it voluntary yields even when it thinks that it always has work to do > (2) there is some diagnostic on what keeps it running > > You may also try to set the thread's priority to PUSER (using sched_prio), > but I > am not sure what bad side-effects may happen because of that. > > No magic bullet here, sorry. Thank you. As workaround, I've unloaded ipmi.ko and edited my scripts to access IPMI sensors over IP instead of local interface. Eugene Grosbein ___ 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/176857: [panic] [suj] 9.1-RELEASE/amd64/GENERIC panic in softdepflush/remove_from_journal
>Number: 176857 >Category: kern >Synopsis: [panic] [suj] 9.1-RELEASE/amd64/GENERIC panic in >softdepflush/remove_from_journal >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Mar 11 16:20:01 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Eugene Grosbein >Release:FreeBSD 9.1-RELEASE amd64 >Organization: RDTC JSC >Environment: System: FreeBSD mx.money-easy.ru 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >Description: I've just installed new server located at hoster's site and hardware. I've used hoster's "rescue mode" running custom variant of 9.1-RELEASE/amd64. I need "stock" 9.1-RELEASE, so I've downloaded FreeBSD-9.1-RELEASE-amd64-disc1.iso, manually partitioned disks with "gpart" and made UFS2+SUJ file systems using "newfs -U -j" command. Then I've extracted base and kernel there and created fstab and rc.conf. After reboot to newly installed system I've got: # mount /dev/ufs/root on / (ufs, local, journaled soft-updates) devfs on /dev (devfs, local, multilabel) /dev/ufs/usr on /usr (ufs, local, read-only) /dev/ufs/var on /var (ufs, local, journaled soft-updates) /dev/ufs/usrl on /usr/local (ufs, local, journaled soft-updates) devfs on /var/named/dev (devfs, local, multilabel) I ran "tar xf ports.txz" and "csup stable-supfile" in parallel, both working with same file system /usr/local and got kernel panic soon. After another reboot, I've got crashdump: Script started on Mon Mar 11 15:27:41 2013 kgdb kernel.symbols /var/crash/vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xd0 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80b05c84 stack pointer = 0x28:0xff811256ea60 frame pointer = 0x28:0xff811256ea80 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 17 (softdepflush) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0x809208a6 at kdb_backtrace+0x66 #1 0x808ea8be at panic+0x1ce #2 0x80bd8240 at trap_fatal+0x290 #3 0x80bd857d at trap_pfault+0x1ed #4 0x80bd8b9e at trap+0x3ce #5 0x80bc315f at calltrap+0x8 #6 0x80b0b8ba at softdep_process_journal+0x3da #7 0x80b0d1d4 at softdep_process_worklist+0x64 #8 0x80b0f817 at softdep_flush+0x197 #9 0x808bb9ef at fork_exit+0x11f #10 0x80bc368e at fork_trampoline+0xe Uptime: 11m53s Dumping 662 out of 3947 MB:..3%..13%..22%..32%..42%..51%..61%..71%..83%..92% Reading symbols from /boot/kernel/geom_cache.ko...done. Loaded symbols for /boot/kernel/geom_cache.ko Reading symbols from /boot/kernel/cc_chd.ko...Reading symbols from /boot/kernel/cc_chd.ko.symbols...done. done. Loaded symbols for /boot/kernel/cc_chd.ko Reading symbols from /boot/kernel/h_ertt.ko...Reading symbols from /boot/kernel/h_ertt.ko.symbols...done. done. Loaded symbols for /boot/kernel/h_ertt.ko Reading symbols from /boot/kernel/mac_portacl.ko...Reading symbols from /boot/kernel/mac_portacl.ko.symbols...done. done. Loaded symbols for /boot/kernel/mac_portacl.ko Reading symbols from /boot/kernel/ipfw.ko...Reading symbols from /boot/kernel/ipfw.ko.symbols...done. done. Loaded symbols for /boot/kernel/ipfw.ko #0 doadump (textdump=Variable "textdump" is not available. ) at pcpu.h:224 224 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump (textdump=Variable "textdump" is not available. ) at pcpu.h:224 #1 0x808ea3a1 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:448 #2 0x808ea897 in panic (fmt=0x1 ) at /usr/src/sys/kern/kern_shutdown.c:636 #3 0x80bd8240 in trap_fatal (frame=0xc, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/a
Re: kern/170604: [ipfw] ipv6 reass broken
The following reply was made to PR kern/170604; it has been noted by GNATS. From: Eugene Grosbein To: bug-follo...@freebsd.org Cc: Subject: Re: kern/170604: [ipfw] ipv6 reass broken Date: Wed, 20 Mar 2013 12:51:03 +0700 Hi! The problem is here in 8.3-STABLE too, the following rule drops all incoming IPv6 packets (but reassembles and passes IPv4): ipfw add reass ip from any to any in recv em0 Eugene Grosbein ___ 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/170604: [ipfw] ipv6 reass broken
The following reply was made to PR kern/170604; it has been noted by GNATS. From: Eugene Grosbein To: bug-follo...@freebsd.org Cc: Subject: Re: kern/170604: [ipfw] ipv6 reass broken Date: Wed, 20 Mar 2013 13:45:15 +0700 20.03.2013 12:51, Eugene Grosbein ÐÉÛÅÔ: > Hi! > > The problem is here in 8.3-STABLE too, the following rule drops all incoming > IPv6 packets > (but reassembles and passes IPv4): > > ipfw add reass ip from any to any in recv em0 Btw, obvious workaround is to replace 'ip' with 'ip4', so that the rule does not match IPv6 packets and does not block them. ___ 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"
bin/177183: [bsnmpd] [patch] snmp_hostres modules does not support FS over 1TB
>Number: 177183
>Category: bin
>Synopsis: [bsnmpd] [patch] snmp_hostres modules does not support FS over
>1TB
>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: Thu Mar 21 09:40:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator: Eugene Grosbein
>Release:FreeBSD 8.3-STABLE i386
>Organization:
RDTC JSC
>Environment:
System: FreeBSD eg.sd.rdtc.ru 8.3-STABLE FreeBSD 8.3-STABLE #53: Wed Feb 13
18:22:34 NOVT 2013 r...@eg.sd.rdtc.ru:/usr/local/obj/usr/local/src/sys/EG i386
>Description:
bsnmp(1) has snmp_hostres module to support HOSTRES MIB.
This SNMP MIB's hrStorageTable limits hrStorageSize and hrStorageUsed
parameters to 32 bit integer values, so file systems having more
than 2^31 allocation units cannot be shown correctly.
Let us follow net-snmp behaviour that (since 2011) translates
hrStorageSize/hrStorageUsed/hrStorageAllocationUnits triples
so that hrStorageAllocationUnits get bigger and other fit
under INT_MAX by default.
>How-To-Repeat:
This demonstrates the problem using holey file to mimic
3TB file system (this needs 18GB free in real fs):
# truncate -s 3T f
# mdconfig -af f
md0
# newfs -O2 -b 4096 -f 512 -i $((1024*1024*1024)) /dev/md0 >/dev/null
# mount /dev/md0 /mnt/tmp
# rmdir /mnt/tmp/.snap; dd if=/dev/zero bs=2048 count=1000 of=/mnt/tmp/f2
# df -k /mnt/tmp
Filesystem 1024-blocks Used Avail Capacity Mounted on
/dev/md03217454200 2004 2960055860 0%/mnt/tmp
Then look at snmpwalk's output and see hrStorageAllocationUnits
equals to 512 (fsize) and hrStorageSize is truncated to 2^31-1.
With the following patch you get result consistent with net-snmp:
HOST-RESOURCES-MIB::hrStorageType.393 = OID:
HOST-RESOURCES-TYPES::hrFSBerkeleyFFS
HOST-RESOURCES-MIB::hrStorageDescr.393 = STRING: /mnt/tmp, type: ufs, dev:
/dev/md0
HOST-RESOURCES-MIB::hrStorageAllocationUnits.393 = INTEGER: 2048 Bytes
HOST-RESOURCES-MIB::hrStorageSize.393 = INTEGER: 1608727100
HOST-RESOURCES-MIB::hrStorageUsed.393 = INTEGER: 1002
SNMP's data 2048*1608727100=3294673100800 equals to df's data:
1024*3217454200=3294673100800
>Fix:
--- usr.sbin/bsnmpd/modules/snmp_hostres/hostres_storage_tbl.c.orig
2013-03-21 13:42:16.0 +0700
+++ usr.sbin/bsnmpd/modules/snmp_hostres/hostres_storage_tbl.c 2013-03-21
14:15:51.0 +0700
@@ -442,7 +442,9 @@
storage_OS_get_fs(void)
{
struct storage_entry *entry;
- uint64_t used_blocks_count = 0;
+ uint64_t block_size = 0;
+ uint64_t free_blocks_count = 0;
+ uint64_t total_blocks_count = 0;
char fs_string[SE_DESC_MLEN];
int mounted_fs_count;
int i = 0;
@@ -473,6 +475,8 @@
fs_tbl_pre_refresh();
for (i = 0; i < mounted_fs_count; i++) {
+ int shift = 0;
+
snprintf(fs_string, sizeof(fs_string),
"%s, type: %s, dev: %s", fs_buf[i].f_mntonname,
fs_buf[i].f_fstypename, fs_buf[i].f_mntfromname);
@@ -488,23 +492,22 @@
entry->flags |= HR_STORAGE_FOUND;
entry->type = fs_get_type(&fs_buf[i]); /*XXX - This is wrong*/
- if (fs_buf[i].f_bsize > INT_MAX)
- entry->allocationUnits = INT_MAX;
- else
- entry->allocationUnits = fs_buf[i].f_bsize;
-
- if (fs_buf[i].f_blocks > INT_MAX)
- entry->size = INT_MAX;
- else
- entry->size = fs_buf[i].f_blocks;
-
- used_blocks_count = fs_buf[i].f_blocks - fs_buf[i].f_bfree;
-
- if (used_blocks_count > INT_MAX)
- entry->used = INT_MAX;
- else
- entry->used = used_blocks_count;
+ total_blocks_count = fs_buf[i].f_blocks;
+ block_size = fs_buf[i].f_bsize;
+ free_blocks_count = fs_buf[i].f_bfree;
+
+ while (total_blocks_count > INT_MAX) {
+ total_blocks_count >>= 1;
+ shift++;
+ }
+ if (shift) {
+ block_size <<= shift;
+ free_blocks_count >>= shift;
+ }
+ entry->size = total_blocks_count;
+ entry->allocationUnits = block_size;
+ entry->used = total_blocks_count - free_blocks_count;
entry->allocationFailures = 0;
/* take care of hrFSTable */
>Rele
Re: misc/180052: www/squid3x ports: some helpers are not built/installed
Yup, my mistake. I figured out that selecting AUTH_LDAP and AUTH_SASL gives the squid_kerb_group helper (which not that obvious, but OK). ___ 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/180462: [lor] system freezes when I close something that is using lots of memory (?)
The following reply was made to PR kern/180462; it has been noted by GNATS. From: "Eugene M. Zheganin" To: bug-follo...@freebsd.org Cc: Subject: Re: kern/180462: [lor] system freezes when I close something that is using lots of memory (?) Date: Tue, 16 Jul 2013 10:15:10 +0600 It was a bug discussed in current@ about chrome and uipc, it was not a freeze, it was panic, and it's fixed in HEAD and can now be closed. ___ 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/167204: [kernel] terrible "netstat -rn" performance due to slow kvm_nlist()
The following reply was made to PR kern/167204; it has been noted by GNATS. From: "Eugene M. Zheganin" To: bug-follo...@freebsd.org Cc: Subject: Re: kern/167204: [kernel] terrible "netstat -rn" performance due to slow kvm_nlist() Date: Thu, 10 Oct 2013 14:12:43 +0600 Still there, on 9.1 and same equipment. ___ 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/184071: cannot build security/p11-kit: /usr/bin/ld: cannot find -lintl
>Number: 184071 >Category: misc >Synopsis: cannot build security/p11-kit: /usr/bin/ld: cannot find -lintl >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 Nov 19 07:00:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Eugene M. Zheganin >Release:10.0-BETA1 >Organization: Norma LLC >Environment: FreeBSD wizard.hq.norma.perm.ru 10.0-BETA1 FreeBSD 10.0-BETA1 #1 r257042: Tue Oct 29 11:02:45 YEKT 2013 emz@ravenholm:/usr/obj/usr/src/sys/WIZARD amd64 >Description: Cannot build security/p11-kit, in the middle of the building process I get: [...] Making all in tests gmake[4]: Entering directory `/usr/ports/security/p11-kit/work/p11-kit-0.20.1/p11-kit/tests' CCLD mock-one.la CCLD mock-two.la /usr/bin/ld: cannot find -lintl /usr/bin/ld: cannot find -lintl cc: error: linker command failed with exit code 1 (use -v to see invocation) gmake[4]: *** [mock-two.la] Error 1 gmake[4]: *** Waiting for unfinished jobs cc: error: linker command failed with exit code 1 (use -v to see invocation) gmake[4]: *** [mock-one.la] Error 1 gmake[4]: Leaving directory `/usr/ports/security/p11-kit/work/p11-kit-0.20.1/p11-kit/tests' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/usr/ports/security/p11-kit/work/p11-kit-0.20.1/p11-kit' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/ports/security/p11-kit/work/p11-kit-0.20.1' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/usr/ports/security/p11-kit/work/p11-kit-0.20.1' ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Stop. make: stopped in /usr/ports/security/p11-kit >How-To-Repeat: Install security/p11-kit from ports. >Fix: Edit the /usr/ports/security/p11-kit/work/p11-kit-0.20.1/p11-kit/tests/Makefile, find the line LDFLAGS = and make it look LDFLAGS = -L/usr/local/lib then rerun make in the port's directory. >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/185619: [VNET] Name conflict not checked when a child vnet goes away and returns its interface(s) back to the parent
>Number: 185619 >Category: kern >Synopsis: [VNET] Name conflict not checked when a child vnet goes away >and returns its interface(s) back to the parent >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: Thu Jan 09 22:30:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Eugene M. Kim >Release:11-CURRENT >Organization: AstralBlue >Environment: FreeBSD hydrogen.astralblue.net 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r260314: Sun Jan 5 17:53:02 UTC 2014 r...@hydrogen.astralblue.net:/usr/obj/usr/src/sys/GENERIC-IPSEC-VIMAGE amd64 >Description: Each vnet has its own namespace for network interfaces. As a result, two network interfaces may have the same name if they belong to distinct vnets. When one of these interfaces tries to move into the other's vnet, the name conflict should - and does - block the operation, except in one case: When a child vnet goes away and returns its interfaces to its parent vnet, the name conflict is not checked and the parent vnet ends up having both interfaces of the same name. This confuses various tools such as ifconfig(8). >How-To-Repeat: The first scenario shown below renames two epair(4) interfaces as "jnet" (one renamed in a parent vnet, another renamed in a child vnet), then destroys the child vnet to bring its jnet interface back to the parent. ifconfig(8) output merges these two interfaces into one block (shown by two MAC addresses). root@hydrogen:~ # jail -c name=test vnet persist root@hydrogen:~ # ifconfig epair create epair0a root@hydrogen:~ # ifconfig epair0a epair0a: flags=8842 metric 0 mtu 1500 options=8 ether 02:ff:40:00:04:0a nd6 options=29 media: Ethernet 10Gbase-T (10Gbase-T ) status: active root@hydrogen:~ # ifconfig epair0b epair0b: flags=8842 metric 0 mtu 1500 options=8 ether 02:ff:90:00:05:0b nd6 options=29 media: Ethernet 10Gbase-T (10Gbase-T ) status: active root@hydrogen:~ # ifconfig epair0a name jnet root@hydrogen:~ # ifconfig epair0b vnet test root@hydrogen:~ # jexec test ifconfig epair0b name jnet root@hydrogen:~ # jail -r test root@hydrogen:~ # ifconfig lo0: flags=8049 metric 0 mtu 16384 options=63 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff00 nd6 options=21 jnet: flags=8842 metric 0 mtu 1500 options=8 ether 02:ff:40:00:04:0a ether 02:ff:90:00:05:0b nd6 options=29 media: Ethernet 10Gbase-T (10Gbase-T ) status: active root@hydrogen:~ # ifconfig jnet destroy root@hydrogen:~ # The second scenario shown below creates two vnets and two epair(4) pairs (one pair for each vnet), injects the "b" end of each pair into the corresponding vnet then renames it as "jnet", then destroys the two vnets, showing the parent vnet ending up with both jnet interfaces. At the end, "ifconfig jnet destroy" can be done twice: The first command picks and destroys one of the two pairs. root@hydrogen:~ # ifconfig epair create epair0a root@hydrogen:~ # ifconfig epair create epair1a root@hydrogen:~ # jail -c name=test1 vnet persist root@hydrogen:~ # jail -c name=test2 vnet persist root@hydrogen:~ # ifconfig epair0b vnet test1 root@hydrogen:~ # jexec test1 ifconfig epair0b name jnet root@hydrogen:~ # ifconfig epair1b vnet test2 root@hydrogen:~ # jexec test2 ifconfig epair1b name jnet root@hydrogen:~ # jail -r test1 root@hydrogen:~ # jail -r test2 root@hydrogen:~ # ifconfig em0: flags=8843 metric 0 mtu 1500 options=4219b ether 74:d0:2b:13:66:fc inet 10.0.0.11 netmask 0xff00 broadcast 10.0.0.255 inet6 fe80::76d0:2bff:fe13:66fc%em0 prefixlen 64 scopeid 0x1 inet6 2001:470:1f05:155:76d0:2bff:fe13:66fc prefixlen 64 autoconf inet6 2002:43bc:72e6:1:76d0:2bff:fe13:66fc prefixlen 64 autoconf nd6 options=23 media: Ethernet autoselect (1000baseT ) status: active em1: flags=8c02 metric 0 mtu 1500 options=4219b ether 74:d0:2b:13:6b:43 nd6 options=29 media: Ethernet autoselect status: no carrier lo0: flags=8049 metric 0 mtu 16384 options=63 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff00 nd6 options=21 epair0a: flags=8842 metric 0 mtu 1500 options=8 ether 02:ff:40:00:04:0a nd6 options=29 media: Ethernet 10Gbase-T (10Gbase-T ) status: active epair1a: flags=8842 metric 0 mtu 1500 options=8 ether 02:ff:40:00:06:0a nd6 o
misc/186859: security/libgpg-error: pkg-plist mistype
>Number: 186859 >Category: misc >Synopsis: security/libgpg-error: pkg-plist mistype >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 Feb 18 08:40:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Eugene M. Zheganin >Release:10.0-RELEASE >Organization: Norma LLC >Environment: FreeBSD 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 22:34:59 UTC 2014 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 >Description: security/libgpg-error tries to build and install libgpg-error.so.10 library, but pkg-plist mentions libgpg-error.so.0, so installation fails, regardless of the NO_STAGE variable. No libgpg-error.so.0 library exists after the binaries are built. >How-To-Repeat: install security/libgpg-error from fresh ports >Fix: Edit the pkg-plist, so it references the correct libgpg-error.so.10 file name. >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/159006: net/quagga - multicast broken in ripd
>Number: 159006 >Category: misc >Synopsis: net/quagga - multicast broken in ripd >Confidential: no >Severity: serious >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Jul 18 04:20:07 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Eugene M. Zheganin >Release:8.2-RELEASE >Organization: RealService LLC >Environment: FreeBSD wizard.hq.norma.perm.ru 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Fri Mar 25 13:08:09 YEKT 2011 e...@ns.hq.norma.perm.ru:/usr/obj/usr/src/sys/WIZARD i386 >Description: Multicast not working in ripd. I recieve tonns of messages like: Jul 1 15:35:24 wizard ripd[68677]: Can't setsockopt IP_MULTICAST_IF on fd 11 to source address 172.16.0.7 for interface gre14 gre14 (like any other gre interface) may look like: # ifconfig gre14 gre14: flags=b051 metric 0 mtu 1476 tunnel inet 89.250.210.69 --> 89.250.210.142 inet 172.16.0.6 --> 172.16.0.7 netmask 0x Packets sent to 224.0.0.9:520 cannot traverse gre interface, and they go using default route. However, multicast works just fine on gre interfaces in ospfd. I use unicast and direct neighbor defining as a temporary solution. Unfortunately, I'm stuck with the RIP as it's the only routing protocol on the Cisco routers series 85[, 86x and I have lots of these. I have filled a bug in quagga's bugzilla, but noone reacted so far. >How-To-Repeat: Install FreeBSD net/quagga port, get one of the low-end Cisco routers, confugure RIP, see the logs. >Fix: None known. >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/157534: [mpt] freeze when disk is removed/died from geom_mirror/zfs raid
The following reply was made to PR kern/157534; it has been noted by GNATS. From: "Eugene M. Zheganin" To: Marius Strobl Cc: bug-follo...@freebsd.org Subject: Re: kern/157534: [mpt] freeze when disk is removed/died from geom_mirror/zfs raid Date: Mon, 25 Jul 2011 21:05:14 +0600 Exactly, I received these messages in seconds after disk removal, then I got freeze around 4-5 minutes (during which I thought that this was no success, and went to my office). When I came there I saw messages like 'Invalidating pack' and 'Removing device entry' and the system was unfrozen. I didn't test the device reinsertion; but I can, if you like. ___ 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"
