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"
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"
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 20:44:24 +0600 I tested it on today's STABLE (looks like the patch is against CURRENT, but I managed to apply it to STABLE, there was just some extra spaces in a couple of places). Seems to be working (do you need screens ?). At least I can say - the freeze timeout is now around 5 minutes (unfortunately, I didn't measure the exact amount of time), against one hour before the patch. Hop I will be able to diminish it even more by tuning the kern.cam.da.default_timeout. Thanks for the great work. ___ 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: Wed, 27 Jul 2011 17:09:16 +0600 Reinsertion is also working just fine. Drive was detected in seconds after pushing in, without any additional iteraction from me. Thanks again for the great work. ___ 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/164400: immediate crash after the start of ipsec processing
>Number: 164400 >Category: kern >Synopsis: immediate crash after the start of ipsec processing >Confidential: no >Severity: critical >Priority: high >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Jan 23 08:10:13 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Eugene M. Zheganin >Release:9.0-RELEASE >Organization: RealService LLC >Environment: FreeBSD 9.0-RELEASE FreeBSD 9.0-RELEASE #1: Sun Jan 22 21:59:51 MSK 2012 emz@moscow-alpha:/usr/obj/usr/src/sys/MOSCOW amd64 >Description: There's a HA-cluster of 2 freebsd running ipsec+gre and a butch of tunnels to branch offices with OSPF. Both were running 8.2-RELEASE and/or different versions of 8.2-STABLE. Since this setup wasn't that stable I was constantly upgrading one of the nodes to a recent -STABLE. After a December -STABLE first node was crashing every hour, so I decided to test it with the memtest86+ (4.20). One week of running memtest gave no errors. So I upgraded to 9.0 and built a debug kernel with WITNESS/INVARIANTS and stuff. OSPF is served by quagga. ISAKMP is served by security/ipsec-tools. Now I have an immediate crash after a carp(4) with public address for gre tunnels and ipsec processing is switching to MASTER. Without it it runs fine. The crash is reproduceable (at least I tested 3 times and got 3 craches). BTs are identical ( I compared each screen first and last line, so only first set of screens is referenced here). This host has an ipkvm (and YES, I can give access to it if needed, it lives on a public address, you will need a working java browser plugin to use it), so here are the screens of this trap happening: http://tech.norma.perm.ru/files/screen01.jpeg http://tech.norma.perm.ru/files/screen02.jpeg http://tech.norma.perm.ru/files/screen03.jpeg http://tech.norma.perm.ru/files/screen04.jpeg http://tech.norma.perm.ru/files/screen05.jpeg Furthermore, when running with WITNESS on this node produces the following output immediately after loading a set of pf rules: http://tech.hq.norma.perm.ru/files/lor.txt This output is always the same too. ipsec.conf: [emz@:~]> cat /etc/ipsec.conf spdflush; # # Moscow, Schelkovskoye, Megaton # spdadd 94.159.37.114 89.250.210.69 gre -P out ipsec esp/transport/94.159.37.114-89.250.210.69/require ah/transport/94.159.37.114-89.250.210.69/require; spdadd 89.250.210.69 94.159.37.114 gre -P in ipsec esp/transport/89.250.210.69-94.159.37.114/require ah/transport/89.250.210.69-94.159.37.114/require; # # Moscow, Pervomayskaya, MGTS # spdadd 109.252.242.9 94.159.37.114 gre -P in ipsec esp/transport/109.252.242.9-94.159.37.114/require ah/transport/109.252.242.9-94.159.37.114/require; spdadd 94.159.37.114 109.252.242.9 gre -P out ipsec esp/transport/94.159.37.114-109.252.242.9/require ah/transport/94.159.37.114-109.252.242.9/require; # # Moscow, Privolnaya, 70 # spdadd 82.142.171.58 94.159.37.114 gre -P in ipsec esp/transport/82.142.171.58-94.159.37.114/require ah/transport/82.142.171.58-94.159.37.114/require; spdadd 94.159.37.114 82.142.171.58 gre -P out ipsec esp/transport/94.159.37.114-82.142.171.58/require ah/transport/94.159.37.114-82.142.171.58/require; # # Moscow, Lermontovsky, 2 # spdadd 79.120.78.118 94.159.37.114 gre -P in ipsec esp/transport/79.120.78.118-94.159.37.114/require ah/transport/79.120.78.118-94.159.37.114/require; spdadd 94.159.37.114 79.120.78.118 gre -P out ipsec esp/transport/94.159.37.114-79.120.78.118/require ah/transport/94.159.37.114-79.120.78.118/require; # # Moscow, Tashkentskaya 12-20 # spdadd 79.120.80.66 94.159.37.114 gre -P in ipsec esp/transport/79.120.80.66-94.159.37.114/require ah/transport/79.120.80.66-94.159.37.114/require; spdadd 94.159.37.114 79.120.80.66 gre -P out ipsec esp/transport/94.159.37.114-79.120.80.66/require ah/transport/94.159.37.114-79.120.80.66/require; # # Moscow, Baykalskaya 50/7 # spdadd 213.33.223.158 94.159.37.114 gre -P in ipsec esp/transport/213.33.223.158-94.159.37.114/require ah/transport/213.33.223.158-94.159.37.114/require; spdadd 94.159.37.114 213.33.223.158 gre -P out ipsec esp/transport/94.159.37.114-213.33.223.158/require ah/transport/94.159.37.114-213.33.223.158/require; # # Moscow, Bratyslavskaya 15-1 # #spdadd 212.46.203.106 94.159.37.114 gre -P in ipsec esp/transport/212.46.203.106-94.159.37.114/require ah/transport/212.46.203.106-94.159.37.114/r
kern/164402: pf crashes with a particular set of rules when first matching packet arrives
>Number: 164402
>Category: kern
>Synopsis: pf crashes with a particular set of rules when first matching
>packet arrives
>Confidential: no
>Severity: critical
>Priority: medium
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Mon Jan 23 10:40:06 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Eugene M. Zheganin
>Release:9.0-RELEASE
>Organization:
RealService LLC
>Environment:
FreeBSD taiga 9.0-RELEASE FreeBSD 9.0-RELEASE #1: Mon Jan 23 13:36:16 YEKT 2012
emz@taiga:/usr/obj/usr/src/sys/TAIGA amd64
>Description:
This is a router with numerous ISPs connected.
This router is running pf with a set of rules and some kind of
route-to/reply-to rules to make it answer from each ISP source address via
corresponding ISP channel.
This router is known to hang quite frequently. It's previous incarnation
running on another machine used to hang too (8.2-R, 8.2-S), I was suspecting
the hardware, so I moved it here and installed a 9.0. This is an IBM x3560
machine, with all last firmware/BIOS fixes from IBM applied.
Eventually I managed to figure the exact set of rules which makes it to hang.
Set of rules is attached below. This router is running INVARIANTS/WITNESS/stuff
kernel, but still it hangs, not traps. Sometimes though, it may eventually show
a very large amount of kernel messages at enormous speed, after that it remains
unresponsive to keyboard, to DDB entering and stuff until rebooted.
Now I should mention the exact place in the set of rules which makes it hang.
This is the place:
===Cut===
1. # http, server
2. # outer world
3. pass in on $oif reply-to ($oif $picgw) proto tcp from !$picnet to $oip port
{ 80, 443 }
4. #pass in on $oif proto tcp from any to $oip port { 80, 443 } no state
5. #pass out on $asif route-to ($oif $picgw) proto tcp from $oip port { 80, 443
} to any no state
6. #pass out on $oif proto tcp from $oip port { 80, 443 } to any no state
7. # our servers on this link
8. pass in on $oif proto tcp from $picnet to $oip port { 80, 443 }
9. pass in on $oif2 reply-to ($oif2 $syngw) proto tcp from any to $oip2 port {
80, 443 }
10. pass in on $asif proto tcp from any to $asip port { 80, 443 }
===Cut===
If I comment out line 3, and uncomment lines 4,5,6 (ofc with pfctl -f
/etc/pf.myrules) the system will hang on first matching packets. This
reproduceable (I tried 6 to 8 times, got the exact behaviour).
By the way, the reason of initiate line no.3 commenting was the fact that
running with reply-to rule diminishes the speed from 100Mbit to average
6Kbytes/sec (and this is weird, as you can see there are no queues).
A reference to a screen capture of these messages is attached below:
http://tech.norma.perm.ru/files/pf-panic03.jpeg
This server is equipped with an ipkvm, I can give access to it if needed.
Also I can provide further information if needed/any possible help.
pf set of rules:
[emz@taiga:/etc]# cat pf.taiga
iifs = "{" vlan1 vlan2 vlan5 vlan9 vlan10 vlan12 vlan15 vlan19 "}"
oif = "vlan104"
oip = "89.250.210.67"
oif2 = "vlan818"
oip2 = "86.109.196.3"
oip3 = "86.109.196.5"
asif = "vlan23"
asip = "128.127.144.3"
picgw = "89.250.210.65"
picnet = "89.250.210.64/28"
syngw = "86.109.196.1"
defgw = "128.127.144.5"
localpubwifiifs = "{" vlan11 vlan21 "}"
table { 192.168.8.192/26, 192.168.9.0/26 }
rdpip = "192.168.3.16"
oip6if = "gif0"
oip6ip = "2001:470:1f08:14c0::2"
tunbroker = "216.66.80.26"
iip6if = "vlan22"
vpnpool = "192.168.248.0/26"
hqmbxip = "192.168.3.32"
table { 192.168.8.192/26, 192.168.93.32/27, 192.168.93.64/27,
192.168.93.128/27, 192.168.93.96/27, 192.168.9.0/26, 192.168.93.192/27,
192.168.93.224/27, 192.168.93.160/27 }
table { 192.168.0.0/16, 172.16.0.0/16, 10.0.0.0/8, 224.0.0.0/8,
fd00::/16, fe80::16 }
table { 94.159.37.117, 94.159.37.118 }
no rdr on $oif proto tcp from 192.168.0.0/16 to port { 80, 443 }
rdr on $oif2 proto tcp from ! to $oip3 port 443 -> $hqmbxip port 443
rdr on $oif proto tcp from ! to $oip port 3389 -> $rdpip port 3389
rdr on $asif proto tcp from ! to $asip port 3389 -> $rdpip port 3389
rdr on $iifs proto tcp from 192.168.0.0/16 to !192.168.0.0/16 port { 80, 443 }
-> 127.0.0.1 port 3129
no nat on $asif proto gre all
nat on $oif proto { tcp, udp, icmp } from 192.168.0.0/16 to !192.168.0.0/16 ->
$oif
nat on $oif2 proto { tcp, udp, icmp } from 192.168.0.0/16 to !192.168.0.0/16 ->
$oif2
nat on $asif proto { tcp, udp, icmp } from 192.168.0.0/16 to !192.168.0.0/16 ->
$asif
# default blocking
block log a
misc/164472: fsck -B panics on particular data inconsistency
>Number: 164472 >Category: misc >Synopsis: fsck -B panics on particular data inconsistency >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 Jan 25 09:00:29 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Eugene M. Zheganin >Release:8.2-RELEASE >Organization: RealService LLC >Environment: FreeBSD elf.hq.norma.perm.ru 8.2-RELEASE FreeBSD 8.2-RELEASE #1: Thu May 5 19:14:23 YEKST 2011 e...@ns.hq.norma.perm.ru:/usr/obj/usr/src/sys/ELF i386 >Description: fsck -B panics on particular inconsistencies. I got one machine that sometimes locks up (probably die to some other bug), and after reset when it runs fsck -B it leads to panic. Since this happens quite often last time I created an image on a partition that makes FreeBSD panic. Unfortunately this machine doesn't run a debug kernel, and, due to a bug when FreeBSD reboots immidiately upon a key press from a screen where it says 'Automatic reboot in 15 seconds, press any key to abort' (which is still unreported for some reason, while lots of people confirm its existance) I was (and I am) unable to capture a panic screen. But, since I have an image, everyone can easily reproduce this panic. This is 100% reproduceable, at least I've done it 5 times on a test machine and got a panic each time. Unfortunately, this machine is too old to build debug kernel in some reasonable amount of time (I really think anyone will download this image faster than I will build a debug kernel). So... here comes the image in case someone is interested. Attention, FreeBSD panics only when fsck is run with -B. Ordinary fsck run doesn't panic and is able to successfully resolve all the filesystem errors. >How-To-Repeat: Get an image from http://tech.norma.perm.ru/files/var.dsk (sorry, this link is about a couple of megabits, my really broadband link is served by a server from my previous report with a buggy pf route-to/reply-to, so I'm using this old server). Mount it read-write (I didn't test it on an unmounted or read-only image). Like this: mdconfig -a -t vnode -f var.dsk mount /dev/md0 /mnt/panic Run an fsck (since it's a partition image you need to manually specify the fsck of the type needed): fsck_4.2bsd -B /dev/md0 >Fix: Run fsck without -B. >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/164472: fsck -B panics on particular data inconsistency
The following reply was made to PR misc/164472; it has been noted by GNATS. From: "Eugene M. Zheganin" To: bug-follo...@freebsd.org, eug...@zhegan.in Cc: Subject: Re: misc/164472: fsck -B panics on particular data inconsistency Date: Wed, 25 Jan 2012 15:21:48 +0600 P.S . I forgot to mention that this image size in 2048 megs, so I'm sorry if you cannot afford its downloading. ___ 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/164472: fsck -B panics on particular data inconsistency
The following reply was made to PR misc/164472; it has been noted by GNATS. From: "Eugene M. Zheganin" To: bug-follo...@freebsd.org, eug...@zhegan.in Cc: Subject: Re: misc/164472: fsck -B panics on particular data inconsistency Date: Wed, 25 Jan 2012 15:48:16 +0600 Yeah, my bad, I compressed it with xz and redirected web-server to it. Now it's about 400 megs. Old URL still works. ___ 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/164475: gre misses RUNNING flag after a reboot
>Number: 164475
>Category: kern
>Synopsis: gre misses RUNNING flag after a reboot
>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 Jan 25 10:20:10 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Eugene M. Zheganin
>Release:8.2-RELEASE
>Organization:
RealService LLC
>Environment:
FreeBSD moscow-omega 8.2-RELEASE FreeBSD 8.2-RELEASE #1: Tue Aug 23 16:30:54
YEKST 2011 emz@moscow-omega:/usr/obj/usr/src/sys/MOSCOW amd64
>Description:
gre misses RUNNING flag after a reboot and thus cannot function. I have to 'up'
it manually.
>How-To-Repeat:
Create a gre interface and reboot.
>Fix:
Place this script in /usr/local/etc/rc.d/
#!/bin/sh
#
# PROVIDE: fixgre
# REQUIRE: LOGIN NETWORKING
. /etc/rc.subr
name="fixgre"
rcvar=`set_rcvar`
start_cmd="start_cmd"
start_cmd () {
for i in `ifconfig | grep gre | awk -F: '{print $1}'`
do
ifconfig $i up
done
}
load_rc_config $name
run_rc_command "$1"
>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/164705: inability to terminate process in D state
>Number: 164705 >Category: kern >Synopsis: inability to terminate process in D state >Confidential: no >Severity: critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Feb 02 08:20:11 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Eugene M. Zheganin >Release:8.2-STABLE >Organization: RealService LLC >Environment: FreeBSD bsdrookie.norma.com. 8.2-STABLE FreeBSD 8.2-STABLE #0: Mon Jul 25 14:13:03 YEKST 2011 emz@:/usr/obj/usr/src/sys/GENERIC amd64 >Description: There's only two holy grails in FreeBSD: one, nowadays patched but sometimes still haunting FreeBSD, is the panic (livelock, hangup, name it yourself) when the mounted media is physically removed (a diskette, a flash-disk etc). And the second - this is inability to terminate a process when it hangs in D state. Of course, kill -9 didn't work (as always. I'm guessing thi isn't a 'uncatchable uniterruptable signal' as it's man page says, It looks more like 'no big deal, safe to ignore signal, just for a process knows that something is up') Last time I plugged the USB-mouse out of its port to hadle the mess with the cord, and when I plugged it back - hald hanged in the D state, so did all of the usbconfigs and so on. I had to reboot the FreeBSD just to get my mouse back. Like we're back in 1996 with an non-OSR Windows 95. It's completely ridiculous. >How-To-Repeat: I'm pretty sure that if you're actually using FreeBSD, then at least once in a lifetime you got the need to kill something, you realise you cannot, and then when trying to understand what the hell is going on you see the magical D letter in ps's output, which means you're doomed. >Fix: There's always an answer. Reboot loves you. >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/164705: inability to terminate process in D state
On 02.02.2012 16:00, Andriy Gapon wrote: on 02/02/2012 11:37 Коньков Евгений said the following: why close? keep the problem open until resolve. Resolve exactly what? Yeah, someone's enormous ego is not exactly a FreeBSD problem. I can see it's grown up to an unresolvable size. ___ 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/165085: nanobsd building broken
>Number: 165085 >Category: misc >Synopsis: nanobsd building broken >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 Feb 13 06:50:12 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Eugene M. Zheganin >Release:9.0-RELEASE >Organization: RealService LLC >Environment: FreeBSD zombie.hq.norma.perm.ru 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Fri Feb 10 01:44:44 YEKT 2012 e...@zombie.hq.norma.perm.ru:/usr/obj/usr/src/sys/GENERIC i386 >Description: nanobsd building broken. install is missing from the PATH, PATH looks weird. Console log: [emz@zombie:/usr/local/etc/nanobsd]# sh -x /usr/src/tools/tools/nanobsd/nanobsd.sh -b -c /usr/local/etc/nanobsd/nanobsd.conf + set -e + NANO_NAME=full + NANO_SRC=/usr/src + NANO_TOOLS=tools/tools/nanobsd + NANO_PACKAGE_DIR=/usr/src/tools/tools/nanobsd/Pkg + NANO_PACKAGE_LIST='*' + NANO_PMAKE='make -j 3' + NANO_IMGNAME=_.disk.full + CONF_BUILD=' ' + CONF_INSTALL=' ' + CONF_WORLD=' ' + NANO_KERNEL=GENERIC + NANO_MODULES='' + NANO_CUSTOMIZE='' + NANO_LATE_CUSTOMIZE='' + NANO_NEWFS='-b 4096 -f 512 -i 8192 -O1 -U' + NANO_DRIVE=ad0 + NANO_MEDIASIZE=150 + NANO_IMAGES=2 + NANO_INIT_IMG2=1 + NANO_CODESIZE=0 + NANO_CONFSIZE=2048 + NANO_DATASIZE=0 + NANO_RAM_ETCSIZE=10240 + NANO_RAM_TMPVARSIZE=10240 + NANO_SECTS=63 + NANO_HEADS=16 + NANO_BOOT0CFG='-o packet -s 1 -m 3' + NANO_BOOTLOADER=boot/boot0sio + NANO_BOOT2CFG=-h + NANO_MD_BACKING=file + PPLEVEL=3 + NANO_LABEL='' + uname -p + NANO_ARCH=i386 + NANO_CFGDIR='' + NANO_DATADIR='' + do_clean=true + do_kernel=true + do_world=true + do_image=true + do_copyout_partition=true + set +e + getopt bc:fhiknqvw -b -c /usr/local/etc/nanobsd/nanobsd.conf + args=' -b -c /usr/local/etc/nanobsd/nanobsd.conf --' + [ 0 -ne 0 ] + set -e + set -- -b -c /usr/local/etc/nanobsd/nanobsd.conf -- + do_world=false + do_kernel=false + shift + . /usr/local/etc/nanobsd/nanobsd.conf + NANO_NAME=alix + NANO_KERNEL=ALIX + NANO_BOOTLOADER=boot/boot0 + NANO_PMAKE='make -j 3' + CONF_WORLD='MODULES_OVERRIDE=if_vlan if_bridge if_carp if_gif if_gre if_tun' + NANO_MEDIASIZE=7372512 + NANO_HEADS=255 + NANO_SECTS=63 + customize_cmd install_packages + NANO_CUSTOMIZE=' install_packages' + customize_cmd cust_comconsole + NANO_CUSTOMIZE=' install_packages cust_comconsole' + shift + shift + shift + break + [ 0 -gt 0 ] + test -n '' + NANO_OBJ=/usr/obj/nanobsd.alix/ + test -n '' + MAKEOBJDIRPREFIX=/usr/obj/nanobsd.alix/ + test -n '' + NANO_DISKIMGDIR=/usr/obj/nanobsd.alix/ + NANO_WORLDDIR=/usr/obj/nanobsd.alix//_.w + NANO_MAKE_CONF_BUILD=/usr/obj/nanobsd.alix//make.conf.build + NANO_MAKE_CONF_INSTALL=/usr/obj/nanobsd.alix//make.conf.install + [ -d tools/tools/nanobsd ] + [ -d /usr/src/tools/tools/nanobsd ] + NANO_TOOLS=/usr/src/tools/tools/nanobsd + true + true + [ ! -z '' ] + export MAKEOBJDIRPREFIX + export NANO_ARCH + export NANO_CODESIZE + export NANO_CONFSIZE + export NANO_CUSTOMIZE + export NANO_DATASIZE + export NANO_DRIVE + export NANO_HEADS + export NANO_IMAGES + export NANO_IMGNAME + export NANO_MAKE_CONF_BUILD + export NANO_MAKE_CONF_INSTALL + export NANO_MEDIASIZE + export NANO_NAME + export NANO_NEWFS + export NANO_OBJ + export NANO_PMAKE + export NANO_SECTS + export NANO_SRC + export NANO_TOOLS + export NANO_WORLDDIR + export NANO_BOOT0CFG + export NANO_BOOTLOADER + export NANO_LABEL + exec + date +%s + NANO_STARTTIME=1329083392 + pprint 1 'NanoBSD image alix build starting' + [ 1 -le 3 ] + date +%s + runtime=0 + date -u -r 0 +%H:%M:%S + printf '%s %.1s %s\n' 00:00:00 '#' 'NanoBSD image alix build starting' 00:00:00 # NanoBSD image alix build starting + false + pprint 2 'Skipping buildworld (as instructed)' + [ 2 -le 3 ] + date +%s + runtime=0 + date -u -r 0 +%H:%M:%S + printf '%s %.2s %s\n' 00:00:00 '#' 'Skipping buildworld (as instructed)' 00:00:00 ## Skipping buildworld (as instructed) + false + pprint 2 'Skipping buildkernel (as instructed)' + [ 2 -le 3 ] + date +%s + runtime=1 + date -u -r 1 +%H:%M:%S + printf '%s %.2s %s\n' 00:00:01 '#' 'Skipping buildkernel (as instructed)' 00:00:01 ## Skipping buildkernel (as instructed) + clean_world + [ /usr/obj/nanobsd.alix/ != /usr/obj/nanobsd.alix/ ] + pprint 2 'Clean and create world directory (/usr/obj/nanobsd.alix//_.w)' + [ 2 -le 3 ] + date +%s + runtime=1 + date -u -r 1 +%H:%M:%S + printf '%s %.2s %s\n' 00:00:01 '#' 'Clean and create worl
Re: misc/165085: nanobsd building broken
The following reply was made to PR misc/165085; it has been noted by GNATS.
From: "Eugene M. Zheganin"
To: bug-follo...@freebsd.org, eug...@zhegan.in
Cc:
Subject: Re: misc/165085: nanobsd building broken
Date: Mon, 13 Feb 2012 13:11:14 +0600
This is a multi-part message in MIME format.
--01050708060402050203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
The following diff make the installworld stage find the install binary
and pass past first error.
But the building crashes on the next issue:
--
>>> Installing everything
--
cd /usr/src; make -f Makefile.inc1 install
===> share/info (install)
install -o root -g wheel -m 444 dir-tmpl
/usr/obj/nanobsd.alix//_.w/usr/share/info/dir
===> lib (install)
===> lib/csu/i386-elf (install)
install -o root -g wheel -m 444 crti.o crtn.o gcrt1.o crt1.o Scrt1.o
/usr/obj/nanobsd.alix//_.w/usr/lib
===> lib/libc (install)
install -C -o root -g wheel -m 444 libc.a
/usr/obj/nanobsd.alix//_.w/usr/lib
install: libc.a: No such file or directory
*** Error code 71
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
--01050708060402050203
Content-Type: text/plain;
name="diff.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="diff.txt"
--- Makefile.inc1.old 2012-02-13 04:10:40.776381435 +0600
+++ Makefile.inc1 2012-02-13 04:08:57.490391177 +0600
@@ -321,12 +321,12 @@
IMAKEENV= ${CROSSENV}
IMAKE=${IMAKEENV} ${MAKE} -f Makefile.inc1
.if empty(.MAKEFLAGS:M-n)
-IMAKEENV+=PATH=${STRICTTMPPATH}:${INSTALLTMP} \
+IMAKEENV+=PATH=${PATH}:${STRICTTMPPATH}:${INSTALLTMP} \
LD_LIBRARY_PATH=${INSTALLTMP} \
PATH_LOCALE=${INSTALLTMP}/locale
IMAKE+= __MAKE_SHELL=${INSTALLTMP}/sh
.else
-IMAKEENV+=PATH=${TMPPATH}:${INSTALLTMP}
+IMAKEENV+=PATH=${PATH}:${TMPPATH}:${INSTALLTMP}
.endif
# kernel stage
--01050708060402050203--
___
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/165085: nanobsd building broken
The following reply was made to PR misc/165085; it has been noted by GNATS. From: "Eugene M. Zheganin" To: bug-follo...@freebsd.org, eug...@zhegan.in Cc: Subject: Re: misc/165085: nanobsd building broken Date: Tue, 14 Feb 2012 00:44:16 +0600 Please close this pr, looks like I forgot completely to build a nanossd binary tree. I'm sorry. ___ 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/165521: livelock on 1 Gig of RAM with zfs when 310.locate is run
>Number: 165521 >Category: misc >Synopsis: livelock on 1 Gig of RAM with zfs when 310.locate is run >Confidential: no >Severity: serious >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Feb 28 04:50:08 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Eugene M. Zheganin >Release:8.2-RELEASE >Organization: RealService LLC >Environment: FreeBSD moscow-omega 8.2-RELEASE FreeBSD 8.2-RELEASE #2: Wed Jan 25 11:30:58 YEKT 2012 emz@moscow-omega:/usr/obj/usr/src/sys/MOSCOW amd64 >Description: Every saturday this server hangs around 4:15 in the morning. 4:15 in the morning is the time when periodic weekly is run. After some investigations it looks like 310.locate is the critical script. This is reproduceable. Simply launching this script also makes server hang. Other servers with similar hardware configuraton and use also hang. loader.conf: zfs_load="YES" vfs.root.mountfrom="zfs:zfsroot" ng_iface_load="YES" ng_ether_load="YES" vm.kmem_size="330M" vm.kmem_size_max="330M" vfs.zfs.arc_max="30M" Console is responsive, but the machine doesn't allow to log in and doesn't respond to network. >How-To-Repeat: Get a FreeBSD, use zfs for system, use 1 Gig of RAM, run 310.locate from weekly set of periodic scripts. >Fix: Turn of periodic runs. Add more RAM (problem disappears on 4 Gigs of RAM with the same config set). >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: conf/163798: [nsswitch.conf] nsswitch.conf with nss_ldap ignore [success=return]
The following reply was made to PR conf/163798; it has been noted by GNATS. From: "Eugene M. Zheganin" To: bug-follo...@freebsd.org, stephane.d...@insa-lyon.fr Cc: Subject: Re: conf/163798: [nsswitch.conf] nsswitch.conf with nss_ldap ignore [success=return] Date: Tue, 06 Mar 2012 10:40:18 +0600 This isuue is like thousand years old. And it concerns every available backend, not just ldap. The same thing is with nss_winbind, for example. Furthermore, [success=return] is the default status/action pair. Plus, first I saw this issue on like 7.x. So I can say - 7.x and 8.x are affected too. And I can say, this leads up to even more weird situation. Imagine OpenLDAP server running on a FreeBSD. After successful test we configure the same FreeBSD as LDAP client - from now on slapd will stuck on start, as it waits for itself. ___ 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/165903: mbuf leak
>Number: 165903
>Category: kern
>Synopsis: mbuf leak
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sat Mar 10 16:30:12 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Eugene M. Zheganin
>Release:9.0-RELEASE
>Organization:
RealService LLC
>Environment:
FreeBSD taiga 9.0-RELEASE FreeBSD 9.0-RELEASE #1: Mon Jan 23 13:36:16 YEKT 2012
emz@taiga:/usr/obj/usr/src/sys/TAIGA amd64
>Description:
# netstat -m
4776674/1561/4778235 mbufs in use (current/cache/total)
2040/1536/3576/25600 mbuf clusters in use (current/cache/total/max)
2040/758 mbuf+clusters out of packet secondary zone in use (current/cache)
1/599/600/12800 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/6400 9k jumbo clusters in use (current/cache/total/max)
0/0/0/3200 16k jumbo clusters in use (current/cache/total/max)
1198264K/5858K/1204123K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/0/0 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
7172 requests for I/O initiated by sendfile
0 calls to protocol drain routines
# uptime
22:19 up 31 days, 5:59, 5 users, load averages: 0,16 0,16 0,17
and continues to grow over time.
This is a router; also it runs SMTP/Squid. Nothing unusual. Not intensely
loaded. Network load is about 10-15 Megabit/sec most of the time, with bursts
to 50-80 Megabits/sec.
There's an archive with a lots of reports taken every hour from the boot, with
the script:
#!/bin/sh
reporttimestamp=`date +%d-%m-%Y-%H-%M`
reportname=${reporttimestamp}.txt
cd /home/emz/memory-mon
top -b > $reportname
echo "" >> $reportname
vmstat -m >> $reportname
echo "" >> $reportname
vmstat -z >> $reportname
echo "" >> $reportname
/usr/bin/perl /usr/local/bin/zfs-stats -a >> $reportname
They can be found here: http://tech.norma.perm.ru/files/memory-reports.tar.gz
>How-To-Repeat:
Install 9.0-RELEASE I guess. I don't know whats triggering the leak.
>Fix:
Reboot.
>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/166462: gre(4) when using a tunnel source address from carp(4) doesn't honor the MASTER/BACKUP state
>Number: 166462 >Category: kern >Synopsis: gre(4) when using a tunnel source address from carp(4) doesn't >honor the MASTER/BACKUP state >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Mar 28 05:40:09 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Eugene M. Zheganin >Release:8.2-RELEASE >Organization: RealService LLC >Environment: FreeBSD moscow-omega 8.2-RELEASE FreeBSD 8.2-RELEASE #5: Sat Mar 10 14:15:00 MSK 2012 emz@moscow-omega:/usr/obj/usr/src/sys/MOSCOW amd64 >Description: When using a HA system of two nodes for corporate VPN I encountered a problem: Imagine node A and B share the same public ip address on their carp(4) interface. Imagine A and B have a gre(4) interface, and its tunnel source address is the carp(4) address. Imagine there is an ospf daemon running on those gre(4) interfaces. Then the OSPF neiborship will be constantly reestablished, because A and B will interfere with OSPF sessions of each other. This happens because both nodes will send a HELO packet, and the backup node isn't honoring its BACKUP state properly. >How-To-Repeat: Build a setup mentioned above. Use OSPF or just try to send icmp packets via the tunnel from the BACKUP node. >Fix: Use IPSEC with 'required' policies. This will prevent the backup node from establishing SA, thus preventing the tunnel from working. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/155945: pf match engine is broken with ipv6
>Number: 155945 >Category: kern >Synopsis: pf match engine is broken with ipv6 >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 Mar 26 10:40:10 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: pf match engine is broken when using ipv6. ipv6 packets are matching to some random (?) matching rule in the list, not the last matching rule. For example (sorry for the long list, but I encountered the problem on the production router. I have to show all of my rules, or I may get blamed for contructing a lame rule list and skipping the lame part of it) ospf packets in this setup are dropped and filter references the rule no. 107 as the source, however, last rule to match is the last rule in the list which passes all of the ipv6 traffic (no. 127 and 128). Rule no. 107 would be the matching rule only if there's no matching rules below it. It's clearly that 128 is the last: %pfctl -vvvs rules @0 scrub in on vlan1 inet proto icmp from 192.168.3.7 to any no-df fragment reassemble [ Evaluations: 26070 Packets: 285 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 18960 ] @1 scrub in on vlan18 inet proto icmp from 192.168.3.7 to any no-df fragment reassemble [ Evaluations: 19526 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 18960 ] @2 scrub in on vlan20 inet proto icmp from 192.168.3.7 to any no-df fragment reassemble [ Evaluations: 19286 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 18960 ] @0 block drop log all [ Evaluations: 20708 Packets: 6 Bytes: 628 States: 0 ] [ Inserted: uid 0 pid 18960 ] @1 pass on lo0 all no state [ Evaluations: 20708 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 18960 ] @2 pass on vlan1 all no state [ Evaluations: 20708 Packets: 1596 Bytes: 283586 States: 0 ] [ Inserted: uid 0 pid 18960 ] @3 pass on vlan18 all no state [ Evaluations: 20708 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 18960 ] @4 pass on vlan20 all no state [ Evaluations: 20708 Packets: 32Bytes: 6250States: 0 ] [ Inserted: uid 0 pid 18960 ] @5 pass proto gre all no state [ Evaluations: 20708 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 18960 ] @6 pass proto esp all no state [ Evaluations: 20708 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 18960 ] @7 pass proto ah all no state [ Evaluations: 20708 Packets: 9245 Bytes: 4256848 States: 2 ] [ Inserted: uid 0 pid 18960 ] @8 pass proto udp from any to any port = isakmp keep state [ Evaluations: 20709 Packets: 17Bytes: 1848States: 6 ] [ Inserted: uid 0 pid 18960 ] @9 pass on gre0 all no state [ Evaluations: 20711 Packets: 4 Bytes: 304 States: 0 ] [ Inserted: uid 0 pid 18960 ] @10 pass on gre1 all no state [ Evaluations: 20711 Packets: 225 Bytes: 23066 States: 0 ] [ Inserted: uid 0 pid 18960 ] @11 pass on gre2 all no state [ Evaluations: 20712 Packets: 315 Bytes: 64076 States: 0 ] [ Inserted: uid 0 pid 18960 ] @12 pass on gre3 all no state [ Evaluations: 20712 Packets: 22Bytes: 11564 States: 0 ] [ Inserted: uid 0 pid 18960 ] @13 pass on gre4 all no state [ Evaluations: 20712 Packets: 5764 Bytes: 3024528 States: 0 ] [ Inserted: uid 0 pid 18960 ] @14 pass on gre5 all no state [ Evaluations: 20712 Packets: 24Bytes: 11692 States: 0 ] [ Inserted: uid 0 pid 18960 ] @15 pass on gre6 all no state [ Evaluations: 20712 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 18960 ] @16 pass on gre7 all no state [ Evaluations: 20712 Packets: 2 Bytes: 128 States: 0 ] [ Inserted: uid 0 pid 18960 ] @17 pass on gre8 all no state [ Evaluations: 20712 Packets: 25Bytes: 1982States: 0 ] [ Inserted: uid 0 pid 18960 ] @18 pass on gre9 all no state [ Evaluations: 20712 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 18960 ] @19 pass on gre10 all no state [ Evaluations: 20712 Packets: 8 Bytes: 626 States: 0 ] [ Inserted: uid 0 pid 18960 ] @20 pass on gre11 all no state
misc/157365: [nfs] cannot umount an nfs from dead server
>Number: 157365 >Category: misc >Synopsis: [nfs] cannot umount an nfs from dead server >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 27 08:10:09 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Eugene M. Zheganin >Release:8.2-RELEASE >Organization: Norma LLC. >Environment: FreeBSD omega.norman-neva.spb.ru 8.2-RELEASE FreeBSD 8.2-RELEASE #2: Fri Apr 22 10:40:22 MSD 2011 e...@omega.norman-neva.spb.ru:/usr/obj/usr/src/sys/SPB-HA amd64 >Description: cannot umount an nfs from dead server. umount hangs indefinitely. so does umount -f. >How-To-Repeat: Mount an FNS resource, disconnect the server from the network, try to umount resource. >Fix: Bring the server back from the dead or simply go back in time. Or reboot. Sometimes going back in time is more likely since reboot is not even possible. >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/157534: [mpt] freeze when disk is removed/died from geom_mirror/zfs raid
>Number: 157534 >Category: misc >Synopsis: [mpt] freeze when disk is removed/died from geom_mirror/zfs >raid >Confidential: no >Severity: serious >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jun 02 17:50:07 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Eugene M. Zheganin >Release:FreeBSD 8.2-RELEASE >Organization: Norma LLC. >Environment: FreeBSD asterisk-alpha 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >Description: I'm using geom_mirror/zfs on IBM System X 3250 servers, which have LSI 1064e controller. When drive dies or when it's removed from the server the system freezes on disk operations, until reboot or until same (or new) drive is inserted. After that the system runs normally. This is reproduceable and I encountered this on i386/amd64. This cannot be helped by upgrading the controller firmware (I downloaded and upgraded to the latest available from IBM support site). ps in debugger shows a great amount of processes in D state. >How-To-Repeat: Get an IBM System X server. Install FreeBSD onto a geom_mirror or zfs mirrored pool. Pull out one drive. Issue some disk i/o related command. >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: 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: bug-follo...@freebsd.org, eug...@zhegan.in Cc: Subject: Re: kern/157534: [mpt] freeze when disk is removed/died from geom_mirror/zfs raid Date: Mon, 06 Jun 2011 14:20:09 +0600 Fix: use integrated mirroring on controller. When using IR all is fine when disk is pulled out. ___ 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: bug-follo...@freebsd.org, eug...@zhegan.in Cc: Subject: Re: kern/157534: [mpt] freeze when disk is removed/died from geom_mirror/zfs raid Date: Tue, 07 Jun 2011 19:00:19 +0600 Seems like its more zfs-related freeze. geom_mirror(4) seems to be able to detect that one of the providers is gone in about a minute. When dealing with a zfs mirrored pool, the console is constantly updated with these messages: [...] mpt0: completing timedout/aborted req 0xff80002be9c0:2484 mpt0: completing timedout/aborted req 0xff80002be6f0:2483 mpt0: completing timedout/aborted req 0xff80002be810:2482 mpt0: completing timedout/aborted req 0xff80002bde80:2481 mpt0: abort of req 0xff80002bde80:0 completed mpt0: request 0xff80002be660:2486 timed out for ccb 0xff00035ea800 (req>ccb 0xff00035ea800) mpt0: request 0xff80002be930:2487 timed out for ccb 0xff00035da000 (req>ccb 0xff00035da000) mpt0: completing timedout/aborted req 0xff80002aff30:2582 mpt0: abort of req 0xff80002aff30:0 completed2486 function 0 mpt0: request 0xff80002afb40:2584 timed out for ccb 0xff00035c (req>ccb 0xff00035c) mpt0: attempting to abort req 0xff80002afb40:2584 function 0 mpt0: completing timedout/aborted req 0xff80002afb40:2584 [...] This is 100% reproduceable. Unfortunately, I got like 11 of these servers. I can provide root ssh and local console (vie IP KVM) to one of them, along with my help in any destructive testing. ___ 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: bug-follo...@freebsd.org, eug...@zhegan.in Cc: Subject: Re: kern/157534: [mpt] freeze when disk is removed/died from geom_mirror/zfs raid Date: Tue, 07 Jun 2011 19:45:52 +0600 Having enough time on panicbox, I can say that 8.2-RELEASE zfs mirror pool can detect that one of the disks from LSI 1064e controller is gone in about an hour. Without issuing 'camcontrol rescan' or other commands. ___ 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: bug-follo...@freebsd.org, eug...@zhegan.in Cc: Subject: Re: kern/157534: [mpt] freeze when disk is removed/died from geom_mirror/zfs raid Date: Wed, 08 Jun 2011 17:51:55 +0600 Persists on today's STABLE with v28. ___ 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: bug-follo...@freebsd.org, eug...@zhegan.in Cc: Subject: Re: kern/157534: [mpt] freeze when disk is removed/died from geom_mirror/zfs raid Date: Thu, 23 Jun 2011 17:42:12 +0600 The thing is, that after disk removal the controller sends two types of events: 0x12 and 0x16. According to the mpi_ioc.h the first is MPI_EVENT_SAS_PHY_LINK_STATUS and the second is MPI_EVENT_SAS_DISCOVERY. Furthermore, according to the kernel messages on the console during the drive removal/attaching, and the code in mpt_cam.c, mpt_cam_event() does nothing to handle these events (they both are handled by 'default:' section). I think this leads to freezing. Comparing to the linux mpt code, I can say that Linux kernel does nothing about MPI_EVENT_SAS_PHY_LINK_STATUS, but it definitely does something (which my skills are to low to understand to) about MPI_EVENT_SAS_DISCOVERY. Anyway, my skills are to low to correct this. IPKVM screenshots of drive removal and insertion (shot 1 - removal, shot 3 - insertion): http://unix.zhegan.in/files/mpt_cam_event01.jpeg http://unix.zhegan.in/files/mpt_cam_event02.jpeg http://unix.zhegan.in/files/mpt_cam_event03.jpeg ___ 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: bug-follo...@freebsd.org, eug...@zhegan.in Cc: Subject: Re: kern/157534: [mpt] freeze when disk is removed/died from geom_mirror/zfs raid Date: Tue, 12 Jul 2011 14:06:38 +0600 Reflashing the IT firmware doesn't help either - controller behaves identically. ___ 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/144572: CARP preemption mode traffic partially goes to backup node
>Number: 144572 >Category: bin >Synopsis: CARP preemption mode traffic partially goes to backup node >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Mar 09 10:30:01 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Eugene M. Zheganin >Release:8.0-RELEASE-p2 >Organization: Norma JSC. >Environment: FreeBSD asterisk-omega 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #4: Thu Feb 18 15:37:02 YEKT 2010 e...@ns.hq.norma.perm.ru:/usr/obj/usr/src/sys/ASTERISK i386 >Description: I have net/asterisk16 setup on two nodes: one main and one backup. I use carp for redundancy. After upgrade to 8.0 I noticed that voice traffic partially goes to backup node. I've checked packet loss (none found) and packet count in tcpdump running on both hosts. Packet count seems to be identical. I would be glad to help locate the exact source of the problem, but right now I have no idea about what other information I should supply. >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/146964: New port: net/asterisk162
>Number: 146964 >Category: misc >Synopsis: New port: net/asterisk162 >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 May 25 10:30:01 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Eugene M. Zheganin >Release:8.0-RELEASE-p2 >Organization: Norma JSC. >Environment: FreeBSD elm.hq.norma.perm.ru 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Sat Feb 27 15:34:41 YEKT 2010 e...@ns.hq.norma.perm.ru:/usr/obj/usr/src/sys/GENERIC i386 >Description: As Digium stated that asterisk 1.6.0.x and 1.6.1.x branches are moving to security-fixes-only support model, and the 1.4.x branch remains in long-term-support 'til the end of 2010, the new 1.6.2.x port should be added to obtain new bugfixes and probably new features. This shar adds the asterisk162 port with version 1.6.2.7, made from pr ports/144065, with one additional patch that fixes redundant console logging when working with Realtime/pgsql. Along with this new port, I supposed that asterisk12 support should be suspended from FreeBSD ports, and the net portstree should be modified as: asterisk12 -> suspended asterisk -> asterisk14 asterisk16 -> asterisk160 asterisk162 (this port) -> asterisk Port is tested on FreeBSD 7.2/8.0, port is working in production for one month. As the attach is too long for gnats, I stored the port on the URL in 'known fixes'. >How-To-Repeat: >Fix: http://zhegan.in/files/asterisk162.txt >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/147307: gre(4) interface is created with flag RUNNING missing during the boot
>Number: 147307 >Category: misc >Synopsis: gre(4) interface is created with flag RUNNING missing during >the boot >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 Jun 02 05:00:08 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Eugene M. Zheganin >Release:8.0-RELEASE-p2 >Organization: Norma JSC. >Environment: FreeBSD ural85-gw0 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:02:08 UTC 2009 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >Description: gre(4) interface is created with flag RUNNING missing during the boot. I have to initialize it with the 'ifconfig greX down; ifconfig greX up;' command. Problem first appeared on 7.2, on 6.x things were fine. Problem persist across i386/amd64 architectures. >How-To-Repeat: Create gre(4) interface, reboot. >Fix: I had to write my own rc-scripts to initialize the interfaces on my routers. >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/169676: system hangs, fully or partially after receiving watchdog timeouts on bge
>Number: 169676 >Category: kern >Synopsis: system hangs, fully or partially after receiving watchdog >timeouts on bge >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 Jul 06 06:00:22 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Eugene M. Zheganin >Release:8.3-STABLE >Organization: RealService LLC >Environment: FreeBSD ural85-gw0-alpha 8.3-STABLE FreeBSD 8.3-STABLE #0: Fri Jul 6 01:59:46 YEKT 2012 emz@ural85-gw0-alpha:/usr/obj/usr/src/sys/CRYSTAL amd64 >Description: IBM x3250m2, running FreeBSD from 8.2-STABLE to 8.3-STABLE periodically hangs. When observing it's console, last message/messages are usually 'bge0 watchdog timeout - resetting'. These messages appear randomly, I cannot reproduce them on purpose. When these messages arrear the system may hang completely (8.3-STABLE), or partially - I can type on console but cannot login, system partrially procecces the traffic (8.2-STABLE, september 2011). Last time on 8.3-STABLE systme hanged completely, even Ctrl-Alt-Escaping to the kernel debugger did nothing. But in /var/log/messages it logged 'bge0: link state changed to DOWN'. the bge0 is: bge0@pci0:2:0:0:class=0x02 card=0x03781014 chip=0x165a14e4 rev=0x00 hdr=0x00 vendor = 'Broadcom Corporation' device = 'Broadcom NetXtreme BCM5722 Gigabit (94309)' class = network subclass = ethernet It's running one of rthe recent 2011 firmware, I updated it using IBM utilities in order to solve the problem; it didn't help though. >How-To-Repeat: >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"
kern/170689: cannot build custom kernel with DDB
>Number: 170689 >Category: kern >Synopsis: cannot build custom kernel with DDB >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 Aug 17 04:00:20 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Eugene M. Zheganin >Release:9.1-PRERELEASE >Organization: Vivat-Trade LLC >Environment: FreeBSD zombie.hq.norma.perm.ru 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0 r238525: Tue Jul 17 10:09:03 YEKT 2012 emz@necromancer:/usr/obj/usr/src/sys/ZOMBIE i386 >Description: Cannot build custom kernel with DDB on a recent -STABLE. I'm able to build GENERIC, I'm able to build some DDB kernel, but I'm unable to build this particular. I recieve an error: :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=make sh /usr/src/sys/conf/newvers.sh ZOMBIE 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 -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/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-sse -msoft-float -ffreestanding -fstack-protector -Werror vers.c linking kernel.debug db_main.o: In function `X_db_lookup': /usr/src/sys/ddb/db_main.c:75: undefined reference to `linker_ddb_lookup' *** [kernel.debug] Error code 1 Stop in /usr/obj/usr/src/sys/ZOMBIE. *** [buildkernel] Error code 1 Stop in /usr/src. *** [buildkernel] Error code 1 Stop in /usr/src. Config: # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the config(5) manual page, # and/or the handbook section on Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: stable/9/sys/i386/conf/GENERIC 235877 2012-05-24 03:45:13Z mav $ cpu I586_CPU cpu I686_CPU ident ZOMBIE makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options INET6 # IPv6 communications protocols options SCTP# Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL# Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCL # New Network Filesystem Client options NFSD# New Network Filesystem Server options NFSLOCKD# Network Lock Manager options NFS_ROOT# NFS usable as /, requires NFSCL options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared me
misc/170690: x11-servers/xorg-server eats memory
>Number: 170690 >Category: misc >Synopsis: x11-servers/xorg-server eats 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: Fri Aug 17 04:20:09 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Eugene M. Zheganin >Release:9.1-PRERELEASE >Organization: Vivat-Trade LLC >Environment: FreeBSD bsdrookie.norma.com. 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #2: Tue Aug 7 11:34:52 YEKT 2012 e...@bsdrookie.norma.com.:/usr/obj/usr/src/sys/BSDROOKIE amd64 >Description: x11-servers/xorg-server eats memory > pkg_info | grep xorg linux-f10-xorg-libs-7.4_1 Xorg libraries (Linux Fedora 10) xorg-7.5.2 X.Org complete distribution metaport xorg-apps-7.5.2 X.org apps meta-port xorg-docs-1.6,1 X.org documentation files xorg-drivers-7.5.2 X.org drivers meta-port xorg-fonts-100dpi-7.5.1 X.Org 100dpi bitmap fonts xorg-fonts-7.5.1X.org fonts meta-port xorg-fonts-75dpi-7.5.1 X.Org 75dpi bitmap fonts xorg-fonts-cyrillic-7.5.1 X.Org Cyrillic bitmap fonts xorg-fonts-miscbitmaps-7.5.1 X.Org miscellaneous bitmap fonts xorg-fonts-truetype-7.5.1 X.Org TrueType fonts xorg-fonts-type1-7.5.1 X.Org Type1 fonts xorg-libraries-7.5.1 X.org libraries meta-port xorg-macros-1.16.1 X.Org development aclocal macros xorg-server-1.7.7_5,1 X.Org X server and related programs xorg-vfbserver-1.7.7_1,1 X virtual framebuffer server from X.Org > pkg_info | grep nvidia nvidia-driver-285.05.09 NVidia graphics card binary drivers for hardware OpenGL ren nvidia-settings-295.59 Display Control Panel for X NVidia driver 10 seconds ps snapshots on X: > ./watch.sh UID PID PPID CPU PRI NI VSZRSS MWCHAN STAT TT TIME COMMAND 0 95316 1662 0 28 0 965576 58472 select S?? 2:50,92 /usr/local/bin/X -br -quiet :0 -nolisten tcp UID PID PPID CPU PRI NI VSZRSS MWCHAN STAT TT TIME COMMAND 0 95316 1662 0 27 0 965576 58616 select S?? 2:52,13 /usr/local/bin/X -br -quiet :0 -nolisten tcp UID PID PPID CPU PRI NI VSZRSS MWCHAN STAT TT TIME COMMAND 0 95316 1662 0 27 0 965576 58788 -R?? 2:53,33 /usr/local/bin/X -br -quiet :0 -nolisten tcp UID PID PPID CPU PRI NI VSZRSS MWCHAN STAT TT TIME COMMAND 0 95316 1662 0 37 0 965576 58932 select S?? 2:55,28 /usr/local/bin/X -br -quiet :0 -nolisten tcp UID PID PPID CPU PRI NI VSZRSS MWCHAN STAT TT TIME COMMAND 0 95316 1662 0 30 0 965576 58936 select S?? 2:56,85 /usr/local/bin/X -br -quiet :0 -nolisten tcp UID PID PPID CPU PRI NI VSZRSS MWCHAN STAT TT TIME COMMAND 0 95316 1662 0 36 0 965576 59056 -R?? 2:58,75 /usr/local/bin/X -br -quiet :0 -nolisten tcp UID PID PPID CPU PRI NI VSZRSS MWCHAN STAT TT TIME COMMAND 0 95316 1662 0 39 0 965576 59316 -R?? 3:01,46 /usr/local/bin/X -br -quiet :0 -nolisten tcp UID PID PPID CPU PRI NI VSZRSS MWCHAN STAT TT TIME COMMAND 0 95316 1662 0 30 0 965576 59308 select S?? 3:03,21 /usr/local/bin/X -br -quiet :0 -nolisten tcp UID PID PPID CPU PRI NI VSZRSS MWCHAN STAT TT TIME COMMAND 0 95316 1662 0 35 0 965576 59308 -R?? 3:04,98 /usr/local/bin/X -br -quiet :0 -nolisten tcp UID PID PPID CPU PRI NI VSZRSS MWCHAN STAT TT TIME COMMAND 0 95316 1662 0 26 0 965576 59308 -R?? 3:06,05 /usr/local/bin/X -br -quiet :0 -nolisten tcp UID PID PPID CPU PRI NI VSZRSS MWCHAN STAT TT TIME COMMAND 0 95316 1662 0 27 0 965888 59620 select S?? 3:07,12 /usr/local/bin/X -br -quiet :0 -nolisten tcp UID PID PPID CPU PRI NI VSZRSS MWCHAN STAT TT TIME COMMAND 0 95316 1662 0 28 0 965888 59620 select S?? 3:08,92 /usr/local/bin/X -br -quiet :0 -nolisten tcp UID PID PPID CPU PRI NI VSZRSS MWCHAN STAT TT TIME COMMAND 0 95316 1662 0 31 0 965576 59424 select S?? 3:10,71 /usr/local/bin/X -br -quiet :0 -nolisten tcp UID PID PPID CPU PRI NI VSZRSS MWCHAN STAT TT TIME COMMAND 0 95316 1662 0 30 0 965888 59736 select S?? 3:12,35 /usr/local/bin/X -br -quiet :0 -nolisten tcp UID PID PPID CPU PRI NI VSZRSS MWCHAN STAT TT TIME COMMAND 0 95316 1662 0 35 0 965888 59796 select S?? 3:14,42 /usr/local/bin/X -br -quiet :0 -nolisten tcp UID PID PPID CPU PRI NI VSZRSS MWCHAN STAT TT
bin/170778: [zfs] FreeBSD panics randomly
>Number: 170778 >Category: bin >Synopsis: [zfs] FreeBSD panics randomly >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 20 07:30:08 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Eugene M. Zheganin >Release:9.1-PRERELEASE >Organization: Vivat-Trade LLC >Environment: FreeBSD taiga 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0: Fri Aug 17 13:55:19 YEKT 2012 emz@taiga:/usr/obj/usr/src/sys/TAIGADBG amd64 >Description: FreeBSD hangs at a random point in time, silentlty. Booting a kernel with INVARIANTS/WITNESS gives a panic (sorry for the image instead of just text, I have only kvm working at this time): http://unix.zhegan.in/files/bt0.jpg >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/171202: [lor] multiple LOR's during the startup
>Number: 171202 >Category: kern >Synopsis: [lor] multiple LOR's during the startup >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 Aug 31 11:30:02 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Eugene M. Zheganin >Release:9.1-PRERELEASE >Organization: Vivat-Trade LLC >Environment: FreeBSD taiga 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0: Fri Aug 17 13:55:19 YEKT 2012 emz@taiga:/usr/obj/usr/src/sys/TAIGADBG amd64 >Description: During the investigation of the possible reasons of periodic hangups of the server, I build the WITNESS/INVARIANTS kernel. I receive multiple LORs during the startup of the server. bz@ kindly told me it's worth to report. So I'm doing this. I'm not aware if these LOR's actually are connected with my server's hangups. Target machine is a IBM x3650 server. It runs IPv4, IPV6 via gif tunnel to the tunnelbroker, pf with a hundred of rules, pf nat, OSPFv6 with net/bird6, OSPFv4 with net/quagga, zfs. # dmesg Copyright (c) 1992-2012 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.1-PRERELEASE #0: Fri Aug 17 13:55:19 YEKT 2012 emz@taiga:/usr/obj/usr/src/sys/TAIGADBG amd64 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Xeon(R) CPU E5405 @ 2.00GHz (1995.04-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Family = 6 Model = 17 Stepping = 6 Features=0xbfebfbff Features2=0xce33d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 4089982976 (3900 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) ipmi0: KCS mode found at io 0xca8 on acpi cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x73 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x588-0x58b on acpi0 pcib0: on acpi0 pcib0: Length mismatch for 3 range: c000 vs c000 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci26: on pcib1 pcib2: at device 0.0 on pci26 pci27: on pcib2 pcib3: at device 0.0 on pci27 pci28: on pcib3 pcib4: irq 17 at device 1.0 on pci27 pci36: on pcib4 pcib5: at device 0.3 on pci26 pci37: on pcib5 pcib6: at device 3.0 on pci0 pci4: on pcib6 aac0: port 0x5000-0x50ff mem 0xc9e0-0xc9ff,0xc7fe-0xc7ff irq 17 at device 0.0 on pci4 aac0: Enabling 64-bit address support aac0: Enable Raw I/O aac0: Enable 64-bit array aac0: New comm. interface enabled aac0: ServeRAID 8k, aac driver 2.1.9-1 pcib7: at device 4.0 on pci0 pci16: on pcib7 pcib8: at device 5.0 on pci0 pci69: on pcib8 pcib9: at device 6.0 on pci0 pci7: on pcib9 pcib10: at device 7.0 on pci0 pci68: on pcib10 pci0: at device 8.0 (no driver attached) pcib11: at device 28.0 on pci0 pci2: on pcib11 pcib12: at device 0.0 on pci2 pci3: on pcib12 bce0: mem 0xce00-0xcfff irq 16 at device 0.0 on pci3 miibus0: on bce0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bce0: Ethernet address: 00:1a:64:c6:a8:7c bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (4.6.1); Bufs (RX:2;TX:2;PG:0); Flags (MFW); MFW (ipms 1.6.0) Coal (RX:6,6,18,18; TX:20,20,80,80) pcib13: at device 28.1 on pci0 pci5: on pcib13 pcib14: at device 0.0 on pci5 pci6: on pcib14 bce1: mem 0xca00-0xcbff irq 17 at device 0.0 on pci6 miibus1: on bce1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000
Re: bin/168848: mptutil not functional
The following reply was made to PR bin/168848; it has been noted by GNATS. From: "Eugene M. Zheganin" To: bug-follo...@freebsd.org, eug...@zhegan.in Cc: Subject: Re: bin/168848: mptutil not functional Date: Thu, 06 Sep 2012 23:48:58 +0600 Please close this pr, I misread the manual page. :( ___ 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/171697: [ip6] [ndp] panic when changing routes
>Number: 171697 >Category: kern >Synopsis: [ip6] [ndp] panic when changing routes >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 Sep 17 07:20:07 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Eugene M. Zheganin >Release:9.1-PRERELEASE >Organization: Vivat-Trade LLC >Environment: FreeBSD taiga 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0: Fri Aug 17 13:55:19 YEKT 2012 emz@taiga:/usr/obj/usr/src/sys/TAIGADBG amd64 >Description: I changed the route after it was incorrectly changed by net/bind6 and got panic: [emz@taiga:~]# route change -inet6 2001:470:1f09:14c0::/120 -iface vlan22 change net 2001:470:1f09:14c0::/120: gateway vlan22 [emz@taiga:~]# Write failed: Broken pipe panic: sin_family 18 cpuid = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x1d8 in6_lltable_lookup() at in6_lltable_lookup+0x44d nd6_output_lle() at nd6_output_lle+0x349 nd6_output() at nd6_output+0x18 ip6_output() at ip6_output+0x122f nd6_na_output_fib() at nd6_na_output_fib+0x4fa nd6_ns_input() at nd6_ns_input+0x992 icmp6_input() at icmp6_input+0xb06 ip6_input() at ip6_input+0x8f4 netisr_dispatch_src() at netisr_dispatch_src+0x152 ether_demux() at ether_demux+0x17d ether_nh_input() at ether_nh_input+0x20e netisr_dispatch_src() at netisr_dispatch_src+0x152 ether_demux() at ether_demux+0x86 ether_nh_input() at ether_nh_input+0x20e netisr_dispatch_src() at netisr_dispatch_src+0x152 bce_intr() at bce_intr+0x46a intr_event_execute_handlers() at intr_event_execute_handlers+0x6a ithread_loop() at ithread_loop+0xb4 fork_exit() at fork_exit+0x135 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff811a901cf0, rbp = 0 --- Uptime: 19d0h34m11s Dumping 1472 out of 4079 MB:panic: Bad tailq NEXT(0xfe0002a74160->tqh_last) != NULL cpuid = 2 Uptime: 19d0h34m11s aac0: shutting down controller Got a routing table snapshot just before the route was changed: Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRSlo0 => default 2001:470:1f08:14c0::1 UGSgif0 ::1 link#10 UH lo0 :::0.0.0.0/96 ::1 UGRSlo0 2001:470:1f08:14c0::1 link#30 UH gif0 2001:470:1f08:14c0::2 link#30 UHS lo0 2001:470:1f09:14c0::/120 fe80::21a:64ff:fe21:8e80%vlan1 UG1 vlan1 2001:470:1f09:14c0::1 link#20 UHS lo0 fd00::/120fe80::21a:64ff:fe21:8e80%vlan1 UG1 vlan1 fd00::300/120 link#11 U vlan1 fd00::301 link#31 UHS lo0 fd00::316 link#11 UHS lo0 fd00::700/120 link#18 Uvlan15 fd00::701 link#32 UHS lo0 fd00::702 link#18 UHS lo0 fd00::d00/120 fe80::21a:64ff:fe21:8e80%vlan1 UG1 vlan1 fd00::b400/120fe80::21a:64ff:fe21:8e80%vlan1 UG1 vlan1 fd00::b401fe80::21a:64ff:fe21:8e80%vlan1 UGH1 vlan1 fd00::b40afe80::21a:64ff:fe21:8e80%vlan1 UGH1 vlan1 fe80::/10 ::1 UGRSlo0 fe80::%bce0/64link#1U bce0 fe80::21a:64ff:fec6:a87c%bce0 link#1UHS lo0 fe80::%lo0/64 link#10 U lo0 fe80::1%lo0 link#10 UHS lo0 fe80::%vlan1/64 link#11 U vlan1 fe80::21a:64ff:fec6:a87c%vlan1link#11 UHS lo0 fe80::%vlan2/64 link#12 U vlan2 fe80::21a:64ff:fec6:a87c%vlan2link#12 UHS lo0 fe80::%vlan5/64 link#13 U vlan5 fe80::21a:64ff:fec6:a87c%vlan5link#13 UHS lo0 fe80::%vlan9/64 link#14 U vlan9 fe80::21a:64ff:fec6:a87c%vlan9link#14 UHS lo0 fe80::%vlan10/64 link#15
kern/171700: cannot record a crashdump whan FreeBSD panics, it panics while doing this again
>Number: 171700 >Category: kern >Synopsis: cannot record a crashdump whan FreeBSD panics, it panics while >doing this again >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 Sep 17 08:40:07 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Eugene M. Zheganin >Release:9.1-PRERELEASE >Organization: Vivat-Trade LLC >Environment: >Description: I got a panic in ndp. I have a configured crashdump device: # grep dump /etc/rc.conf dumpdev="AUTO" # ls -l /dev/dump* lrwxr-xr-x 1 root wheel 12 17 сен 19:48 /dev/dumpdev -> /dev/aacd0p2 I have enough space: # grep -i memory /var/run/dmesg.boot real memory = 4294967296 (4096 MB) avail memory = 4089982976 (3900 MB) # swapinfo Device 1K-blocks UsedAvail Capacity /dev/aacd0p2 83886080 8388608 0% Each time FreeBSd panics and tries to do a dump, it panics again: panic: sin_family 18 cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x1d8 in6_lltable_lookup() at in6_lltable_lookup+0x44d nd6_output_lle() at nd6_output_lle+0x349 nd6_output() at nd6_output+0x18 ip6_output() at ip6_output+0x122f tcp_output() at tcp_output+0x12c7 tcp_usr_shutdown() at tcp_usr_shutdown+0xf8 sys_shutdown() at sys_shutdown+0x75 amd64_syscall() at amd64_syscall+0x2fa Xfast_syscall() at Xfast_syscall+0xf7 --- syscall (134, FreeBSD ELF64, sys_shutdown), rip = 0x801fee65c, rsp = 0x7fffd728, rbp = 0x7fffd970 --- Uptime: 43m28s Dumping 545 out of 4079 MB:panic: Bad tailq NEXT(0xfe0002a74160->tqh_last) != NULL cpuid = 1 Uptime: 43m28s aac0: shutting down controller... Another one: panic: sin_family 18 cpuid = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x1d8 in6_lltable_lookup() at in6_lltable_lookup+0x44d nd6_output_lle() at nd6_output_lle+0x349 nd6_output() at nd6_output+0x18 ip6_output() at ip6_output+0x122f nd6_na_output_fib() at nd6_na_output_fib+0x4fa nd6_ns_input() at nd6_ns_input+0x992 icmp6_input() at icmp6_input+0xb06 ip6_input() at ip6_input+0x8f4 netisr_dispatch_src() at netisr_dispatch_src+0x152 ether_demux() at ether_demux+0x17d ether_nh_input() at ether_nh_input+0x20e netisr_dispatch_src() at netisr_dispatch_src+0x152 ether_demux() at ether_demux+0x86 ether_nh_input() at ether_nh_input+0x20e netisr_dispatch_src() at netisr_dispatch_src+0x152 bce_intr() at bce_intr+0x46a intr_event_execute_handlers() at intr_event_execute_handlers+0x6a ithread_loop() at ithread_loop+0xb4 fork_exit() at fork_exit+0x135 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff811a901cf0, rbp = 0 --- Uptime: 19d0h34m11s Dumping 1472 out of 4079 MB:panic: Bad tailq NEXT(0xfe0002a74160->tqh_last) != NULL cpuid = 2 Uptime: 19d0h34m11s aac0: shutting down controller... >How-To-Repeat: Configure a dump device in FreeBSD, make it panic. >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"
