Re: Xorg in swwrt
On Sun, Feb 06, 2011 at 03:19:12PM +1030, Daniel O'Connor wrote: I updated ports (portmaster -a basically) on this 8.2-PRE box and now I find X takes a long, long time to start up and uses lots of CPU. It shows the wchan as swwrt. eg.. last pid: 21791; load averages: 0.12, 0.29, 0.23 up 0+16:09:07 15:16:15 496 processes: 2 running, 494 sleeping CPU: 0.0% user, 0.0% nice, 46.7% system, 0.0% interrupt, 53.3% idle Mem: 190M Active, 33M Inact, 3217M Wired, 198M Cache, 15M Buf, 171M Free Swap: 4096M Total, 621M Used, 3475M Free, 15% Inuse, 212K Out PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 21787 fiona 1 760 168M 134M swwrt 0 0:04 32.37% Xorg 21788 darius1 760 31860K 4868K pause 1 0:00 1.17% zsh 2081 darius4 440 113M 11620K ucond 1 9:45 0.10% python2.6 656 root 1 440 24392K 1096K select 1 3:44 0.00% ppp 1881 darius 32 520 135M 8804K uwait 0 2:24 0.00% python2.6 Does anyone else see this? I don't use X, but: The swwrt state is induced by function swap_pager_putpages() in src/sys/vm/swap_pager.c. It seems to imply that there's a certain degree of swapping going on in/out of the process, but the code is beyond my understanding. I see 621MB of swap used on that machine, so it doesn't sound that far-fetched. It would also help to know when your kernel was built (uname -a), since there have been changed during the 8.2-PRERELEASE lifetime to the above code file. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/vm/swap_pager.c procstat -kk and procstat -v on PID 21787 might also be helpful. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Xorg in swwrt
On Sun, Feb 06, 2011 at 03:19:12PM +1030, Daniel O'Connor wrote: I updated ports (portmaster -a basically) on this 8.2-PRE box and now I find X takes a long, long time to start up and uses lots of CPU. It shows the wchan as swwrt. eg.. last pid: 21791; load averages: 0.12, 0.29, 0.23 up 0+16:09:07 15:16:15 496 processes: 2 running, 494 sleeping CPU: 0.0% user, 0.0% nice, 46.7% system, 0.0% interrupt, 53.3% idle Mem: 190M Active, 33M Inact, 3217M Wired, 198M Cache, 15M Buf, 171M Free Swap: 4096M Total, 621M Used, 3475M Free, 15% Inuse, 212K Out PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 21787 fiona 1 760 168M 134M swwrt 0 0:04 32.37% Xorg swwrt means waiting for the syncronous swap-out to finish. This is consistent with the top indicating the non-trivial amount of swap space used and swapout happen right now. Look at the working set of the application you are starting. Another thing that is standing out is huge wired count. 21788 darius1 760 31860K 4868K pause 1 0:00 1.17% zsh 2081 darius4 440 113M 11620K ucond 1 9:45 0.10% python2.6 656 root 1 440 24392K 1096K select 1 3:44 0.00% ppp 1881 darius 32 520 135M 8804K uwait 0 2:24 0.00% python2.6 Does anyone else see this? If it matters I am using the xf86-video-ati driver (II) RADEON(0): vgaHWGetIOBase: hwp-IOBase is 0x03d0, hwp-PIOOffset is 0x (==) RADEON(0): RGB weight 888 (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) (--) RADEON(0): Chipset: ATI Radeon HD 4200 (ChipID = 0x9710) (--) RADEON(0): Linear framebuffer at 0xd800 (II) RADEON(0): PCI card detected [snip] (II) RADEON(0): MC_AGP_LOCATION : 0x003f (II) RADEON(0): Depth moves disabled by default (II) RADEON(0): Allocating from a screen of 131008 kb (II) RADEON(0): Will use 32 kb for hardware cursor 0 at offset 0x00b7c000 (II) RADEON(0): Will use 32 kb for hardware cursor 1 at offset 0x00b8 (II) RADEON(0): Will use 11760 kb for front buffer at offset 0x (II) RADEON(0): Will use 64 kb for PCI GART at offset 0x07ff (II) RADEON(0): Will use 11760 kb for back buffer at offset 0x00b84000 (II) RADEON(0): Will use 11760 kb for depth buffer at offset 0x0170 (II) RADEON(0): Will use 47616 kb for textures at offset 0x0227c000 (II) RADEON(0): Will use 48080 kb for X Server offscreen at offset 0x050fc000 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: Searching for BusID pci::01:05.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: drmOpenMinor returns 10 drmOpenByBusid: drmGetBusid reports pci::01:05.0 (II) [drm] DRM interface version 1.2 (II) [drm] DRM open master succeeded. (II) RADEON(0): [drm] Using the DRM lock SAREA also for drawables. (II) RADEON(0): [drm] framebuffer handle = 0xd800 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): X context handle = 0x3 (II) RADEON(0): [drm] installed DRM signal handler [in swwrt] Does anyone else see this? Thanks. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org pgpyZWLQ7q6ud.pgp Description: PGP signature
Re: FreeBSD 8.2-RC3/7.4-RC3 Available...
On 03.02.2011 23:38, Jan Henrik Sylvester wrote: On 01/-10/-28163 20:59, Ken Smith wrote: The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 8.0-RELEASE, 8.1-RELEASE, 8.2-BETA1, 8.2-RC1 or 8.2-RC2 can upgrade as follows: # freebsd-update upgrade -r 8.2-RC3 While it does work on i386, it fails on amd64: Fetching metadata signature for 8.2-RC3 from update5.FreeBSD.org... failed. Fetching metadata signature for 8.2-RC3 from update4.FreeBSD.org... failed. Fetching metadata signature for 8.2-RC3 from update2.FreeBSD.org... failed. Fetching metadata signature for 8.2-RC3 from update3.FreeBSD.org... failed. In contrast to the other releases, betas, and candidates, there is no amd64 directory listed for 8.2-RC3, only i386: http://update4.freebsd.org/8.2-RC3/ (It has been this way for a few days now, but since there was no announcement, I thought it was still being worked on.) Hello, For what it's worth, I am still seeing the same thing on an AMD64 8.2-RC2 system: $ sudo freebsd-update -v debug upgrade -r 8.2-RC3 Looking up update.FreeBSD.org mirrors... 4 mirrors found. Fetching public key from update4.FreeBSD.org... fetch: http://update4.FreeBSD.org/8.2-PRERELEASE/amd64/pub.ssl: Not Found failed. Fetching public key from update5.FreeBSD.org... fetch: http://update5.FreeBSD.org/8.2-PRERELEASE/amd64/pub.ssl: Not Found failed. Fetching public key from update2.FreeBSD.org... fetch: http://update2.FreeBSD.org/8.2-PRERELEASE/amd64/pub.ssl: Not Found failed. Fetching public key from update3.FreeBSD.org... fetch: http://update3.FreeBSD.org/8.2-PRERELEASE/amd64/pub.ssl: Not Found failed. No mirrors remaining, giving up. Best regards Thomas Steen Rasmussen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Xorg in swwrt
On Sun, Feb 06, 2011 at 11:27:32AM +0200, Kostik Belousov wrote: On Sun, Feb 06, 2011 at 03:19:12PM +1030, Daniel O'Connor wrote: I updated ports (portmaster -a basically) on this 8.2-PRE box and now I find X takes a long, long time to start up and uses lots of CPU. It shows the wchan as swwrt. eg.. last pid: 21791; load averages: 0.12, 0.29, 0.23 up 0+16:09:07 15:16:15 496 processes: 2 running, 494 sleeping CPU: 0.0% user, 0.0% nice, 46.7% system, 0.0% interrupt, 53.3% idle Mem: 190M Active, 33M Inact, 3217M Wired, 198M Cache, 15M Buf, 171M Free Swap: 4096M Total, 621M Used, 3475M Free, 15% Inuse, 212K Out PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 21787 fiona 1 760 168M 134M swwrt 0 0:04 32.37% Xorg swwrt means waiting for the syncronous swap-out to finish. This is consistent with the top indicating the non-trivial amount of swap space used and swapout happen right now. Look at the working set of the application you are starting. Another thing that is standing out is huge wired count. Regarding the large wired count: I'm willing to bet ZFS is in use on the machine, which would explain this (specifically ARC usage). -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 8.2-RC3/7.4-RC3 Available...
On 02/06/2011 10:30, Thomas Steen Rasmussen wrote: On 03.02.2011 23:38, Jan Henrik Sylvester wrote: On 01/-10/-28163 20:59, Ken Smith wrote: The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 8.0-RELEASE, 8.1-RELEASE, 8.2-BETA1, 8.2-RC1 or 8.2-RC2 can upgrade as follows: # freebsd-update upgrade -r 8.2-RC3 While it does work on i386, it fails on amd64: Fetching metadata signature for 8.2-RC3 from update5.FreeBSD.org... failed. Fetching metadata signature for 8.2-RC3 from update4.FreeBSD.org... failed. Fetching metadata signature for 8.2-RC3 from update2.FreeBSD.org... failed. Fetching metadata signature for 8.2-RC3 from update3.FreeBSD.org... failed. In contrast to the other releases, betas, and candidates, there is no amd64 directory listed for 8.2-RC3, only i386: http://update4.freebsd.org/8.2-RC3/ (It has been this way for a few days now, but since there was no announcement, I thought it was still being worked on.) Hello, For what it's worth, I am still seeing the same thing on an AMD64 8.2-RC2 system: $ sudo freebsd-update -v debug upgrade -r 8.2-RC3 Looking up update.FreeBSD.org mirrors... 4 mirrors found. Fetching public key from update4.FreeBSD.org... fetch: http://update4.FreeBSD.org/8.2-PRERELEASE/amd64/pub.ssl: Not Found failed. Fetching public key from update5.FreeBSD.org... fetch: http://update5.FreeBSD.org/8.2-PRERELEASE/amd64/pub.ssl: Not Found failed. Fetching public key from update2.FreeBSD.org... fetch: http://update2.FreeBSD.org/8.2-PRERELEASE/amd64/pub.ssl: Not Found failed. Fetching public key from update3.FreeBSD.org... fetch: http://update3.FreeBSD.org/8.2-PRERELEASE/amd64/pub.ssl: Not Found failed. No mirrors remaining, giving up. That is not the same thing. It is looking for 8.2-PRERELEASE: Your system is not on a binary release (a RELEASE, a BETA, or a RC) and cannot (regularly) be updated by freebsd-update. I have done freebsd-updates 8.1-RELEASE - 8.2-BETA1 - 8.2-RC1 - 8.2-RC2 on amd64 successfully (as well as 8.2-RC1 - 8.2-RC2 on i386). The bits are all there. For 8.2-RC3 and 7.4-RC3 the amd64 signatures are missing while the i386 ones are there: http://update4.freebsd.org/8.2-RC3/ Both amd64 and i386 are there for 8.2-RC2 (and every other RELEASE, BETA, and RC): http://update4.freebsd.org/8.2-RC2/ Interestingly, while the signature is missing, the binary patches are there for amd64 (and i386): http://update4.freebsd.org/to-8.2-RC3/ Cheers, Jan Henrik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Xorg in swwrt
On 06/02/2011, at 19:57, Kostik Belousov wrote: PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 21787 fiona 1 760 168M 134M swwrt 0 0:04 32.37% Xorg swwrt means waiting for the syncronous swap-out to finish. This is consistent with the top indicating the non-trivial amount of swap space used and swapout happen right now. OK. There are a lot of daemons running, however it does the swwrt thing even on a fresh boot, and even when there is a lot of free space. I wonder if it is doing something silly like trying to get some contiguous memory or similar.. Look at the working set of the application you are starting. Another thing that is standing out is huge wired count. Yep, it's running ZFS :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
bridge, ipv6 and rtadvd
Hi All, Don't know if this is expected behaviour. My LAN (bge0) and WLAN (wlan0) are bridged in bridge0. I tried to run rtadvd on bridge0 but that didn't result in ipv6 addresses on my network. Tried running rtadvd directly /usr/sbin/rtadvd -c /etc/rtadvd.conf -f -D and saw the requests coming in from the client but that didn't result in a working ipv6 network. Wild guessing I tried loading it with /usr/sbin/rtadvd -f -D bge0 and I had a functional ipv6 network. Is this intended behaviour? Am I doing something wrong? One of the other quirks I found was that the example rtadvd.conf line from http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-ipv6.html does not work, the :addrs#1: makes rtadvd report getconfig bridge0 isn't defined in the configuration file or the configuration file doesn't exist. Kind regards, Spil. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: bridge, ipv6 and rtadvd
Am 06.02.2011 um 13:23 schrieb Spil Oss: Hi All, Don't know if this is expected behaviour. My LAN (bge0) and WLAN (wlan0) are bridged in bridge0. I tried to run rtadvd on bridge0 but that didn't result in ipv6 addresses on my network. Tried running rtadvd directly /usr/sbin/rtadvd -c /etc/rtadvd.conf -f -D and saw the requests coming in from the client but that didn't result in a working ipv6 network. Wild guessing I tried loading it with /usr/sbin/rtadvd -f -D bge0 and I had a functional ipv6 network. Is this intended behaviour? Am I doing something wrong? It appears to be intentional; there was some discussion a couple years back, and the current behavior is for virtual interfaces to not receive link-local addresses. Since I prefer to have bridge0 as the main interface, I simply manually configured a link local address: ipv6_enable=YES ipv6_gateway_enable=YES ipv6_network_interfaces=bridge0 gif0 ipv6_ifconfig_bridge0=fe80::21c:c0ff:fe7d:8c50%bridge0 ipv6_ifconfig_bridge0_alias0=2001:470:1f0b:::1 prefixlen 64 ipv6_ifconfig_gif0=2001:470:1f0a:::2 2001:470:1f0a:::1 prefixlen 128 $ cat /etc/rtadvd.conf bridge0:\ :addrs#1:addr=2001:470:1f0b::::raflags#64: The IPv4 side of gif0 is brought up through a linkup script triggered by mpd when my DSL connection comes up; that also updates the endpoint address for the HE tunnel. Oh, this is on -stable from Dec 4. HTH, Stefan -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
(8.2|7.4)-RC3 amd64 bits in place now
Hi all, I forgot to upload some of the amd64 RC3 bits to the mirrors earlier. They should be in place now. -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
8.1 amd64 lockup (maybe zfs or disk related)
Hi all, I am experiencing hard lockup when running 8.1-RELEASE amd64. The last two times it has happened I was running a zpool scrub (high cpu and io load). /var/log/messages has some errors looking like: kernel: ad0: FAILURE - READ_DMA4 but these didn't seem to correspond to the exact time of the lockup. any suggestions? Thanks, Greg ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
em0 hangs without any messages like Watchdog timeout, only down/up reset it.
Hello, Freebsd-stable. My em0 (the same, copy'n'paste hardware info from previous mnessage): em0@pci0:0:25:0:class=0x02 card=0x82681043 chip=0x10bd8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82566DM Gigabit Ethernet Adapter (82566DM)' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xfea4, size 131072, enabled bar [14] = type Memory, range 32, base 0xfea79000, size 4096, enabled bar [18] = type I/O Port, range 32, base 0xdc00, size 32, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 09[e0] = vendor (length 6) Intel cap 2 version 0 It is on-board LAN on Q35-based MoBo (ASUS P5E-VM DO) It hangs under load without any output. When it works with POLLING, it prints Watchdog timeout and reset automatically several times a day, but without POLLING it simply hangs with same frequency. It is 8.2-PRERELEASE (from RELENG_8), cvsupped AFTER 22 Jan (last commit to e1000 drivers family). Locally system works, but mbufs are overfilled. ifconfig em0 down ifconfig em0 up solves problem. Output of different diagnostic tools (vmstat, netstat, ifconfig, sysctl of dev.em.0 tree, top -S) are attached in one file. Early (about half year ago) this sytem works without any problems with net. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org net.hangup.log Description: Binary data ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
bind 9.6.2 dnssec validation bug
I haven't seen any mention of this anywhere. Are there any plans to update BIND in the 8.1/8.2 branches? https://www.isc.org/announcement/bind-9-dnssec-validation-fails-new-ds-record -- Russell A. Jackson r...@csub.edu Network Analyst California State University, Bakersfield ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.1 amd64 lockup (maybe zfs or disk related)
On Sun, Feb 06, 2011 at 01:01:14PM -0800, Greg Bonett wrote: Hi all, I am experiencing hard lockup when running 8.1-RELEASE amd64. The last two times it has happened I was running a zpool scrub (high cpu and io load). /var/log/messages has some errors looking like: kernel: ad0: FAILURE - READ_DMA4 but these didn't seem to correspond to the exact time of the lockup. any suggestions? Given that you're running 8.1-RELEASE, what sort of ZFS tunings are you using in /boot/loader.conf? Tuning is required on this version. The ad0 READ_DMA48 errors could indicate you have a hard disk with bad blocks or is going bad in a different manner. Please install ports/sysutils/smartmontools and provide output of smartctl -a /dev/ad0 here and I can help you determine that. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: bind 9.6.2 dnssec validation bug
On Sun, Feb 06, 2011 at 05:05:08PM -0800, Russell Jackson wrote: I haven't seen any mention of this anywhere. Are there any plans to update BIND in the 8.1/8.2 branches? https://www.isc.org/announcement/bind-9-dnssec-validation-fails-new-ds-record This was discussed vehemently in December 2010: http://lists.freebsd.org/pipermail/freebsd-stable/2010-December/thread.html#60640 RELENG_8 (8.2-PRERELEASE as of the time of this writing) now has the official 9.6.3 as of a commit done by Doug Barton only a few hours ago: http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/bind9/ http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/bind9/README As for whether or not this will be backported to the RELENG_8_1 tag, I would say probably, but Doug would be authoritative on that. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: bind 9.6.2 dnssec validation bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/06/2011 20:58, Jeremy Chadwick wrote: | On Sun, Feb 06, 2011 at 05:05:08PM -0800, Russell Jackson wrote: | I haven't seen any mention of this anywhere. Are there any plans to | update BIND in the 8.1/8.2 branches? | | https://www.isc.org/announcement/bind-9-dnssec-validation-fails-new-ds-record | | This was discussed vehemently in December 2010: | | http://lists.freebsd.org/pipermail/freebsd-stable/2010-December/thread.html#60640 Different issue. :) | RELENG_8 (8.2-PRERELEASE as of the time of this writing) now has the | official 9.6.3 as of a commit done by Doug Barton only a few hours ago: | | http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/bind9/ | http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/bind9/README The 9.6.3 update was in ports the same day it was released, and is now in HEAD and RELENG_8. It's not relevant to RELENG_7, which is the issue that Jeremy posted above. I've sent the information about this problem to the release engineers, whether or not it makes it into 8.2-RELEASE is completely in their hands. However, the material that I sent them about this problem boiled down to the following: 1. This IS a significant bug for those who have DNSSEC validation enabled, however 2. Only a minority of our users have it enabled, and the named.conf in the base does not. 3. The bug can be worked around by restarting the affected name server _after_ it sees the new DS record, however 4. The only way to detect this problem is to wait for it to break. There are also the additional long-standing points that the latest releases of BIND are always in the ports, and anyone doing serious DNSSEC at this stage will want to be running 9.7.x (or the upcoming 9.8.x) because it supports RFC 5011 trust anchor rollover, among other nice DNSSEC features. | As for whether or not this will be backported to the RELENG_8_1 tag, I | would say probably, but Doug would be authoritative on that. Back-porting it that far is definitely not being considered at the moment, and is unlikely to happen. hth, Doug - -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBCAAGBQJNT440AAoJEFzGhvEaGryED28IAJfW8yLH1YngzaKCMvopeZXq HQ5DstQpg9X9vSsqGABh/2A1rtFQsyUOIEK9Af/Rsc1X9w9MNgkEDDNfrJdk0JRK NiJuemPgZGaunhXcXZTyUOuHJOAtJJds/Tcabw2nZv/bagM9KGApOCSuBzbWpam/ 90pOttSKoMs5gxHn75BcSjxRiu4mYiEo7wgkdxF8OwEedHSI6y6SQoMXMgmYkjXS mpOR8AOtrHxN17an7yn26o6Sh3gUW5BSbsIHW921yiDv+lf0N8cT5+T+Livbso/k tciZMZbMExWt02gAzotOjdMX5npkDz4/dMT9L6R6rrPecsDnvdxWE+2gf73a0Lc= =n/On -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: bind 9.6.2 dnssec validation bug
On 02/06/2011 10:16 PM, Doug Barton wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/06/2011 20:58, Jeremy Chadwick wrote: | On Sun, Feb 06, 2011 at 05:05:08PM -0800, Russell Jackson wrote: | I haven't seen any mention of this anywhere. Are there any plans to | update BIND in the 8.1/8.2 branches? | | https://www.isc.org/announcement/bind-9-dnssec-validation-fails-new-ds-record | | This was discussed vehemently in December 2010: | | http://lists.freebsd.org/pipermail/freebsd-stable/2010-December/thread.html#60640 Different issue. :) | RELENG_8 (8.2-PRERELEASE as of the time of this writing) now has the | official 9.6.3 as of a commit done by Doug Barton only a few hours ago: | | http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/bind9/ | http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/bind9/README The 9.6.3 update was in ports the same day it was released, and is now in HEAD and RELENG_8. It's not relevant to RELENG_7, which is the issue that Jeremy posted above. I've sent the information about this problem to the release engineers, whether or not it makes it into 8.2-RELEASE is completely in their hands. However, the material that I sent them about this problem boiled down to the following: 1. This IS a significant bug for those who have DNSSEC validation enabled, however 2. Only a minority of our users have it enabled, and the named.conf in the base does not. 3. The bug can be worked around by restarting the affected name server _after_ it sees the new DS record, however 4. The only way to detect this problem is to wait for it to break. There are also the additional long-standing points that the latest releases of BIND are always in the ports, and anyone doing serious DNSSEC at this stage will want to be running 9.7.x (or the upcoming 9.8.x) because it supports RFC 5011 trust anchor rollover, among other nice DNSSEC features. | As for whether or not this will be backported to the RELENG_8_1 tag, I | would say probably, but Doug would be authoritative on that. Back-porting it that far is definitely not being considered at the moment, and is unlikely to happen. Looks like I should just suck it up and start using the bind97 port. Thanks. -- Russell A. Jackson r...@csub.edu Network Analyst California State University, Bakersfield ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.1 amd64 lockup (maybe zfs or disk related)
Thanks for the response. I have no tunings in /boot/loader.conf according to http://wiki.freebsd.org/ZFSTuningGuide for amd64 FreeBSD 7.2+ has improved kernel memory allocation strategy and no tuning may be necessary on systems with more than 2 GB of RAM. I have 8GB of ram. do you think this is wrong? Handbook recommends these (but says their test system has 1gb ram): vm.kmem_size=330M vm.kmem_size_max=330M vfs.zfs.arc_max=40M vfs.zfs.vdev.cache.size=5M what do you recommend? I think the ad0: FAILURE - READ_DMA4 errors may be from a bad sata cable (or rather, a 12in sata cable connecting a drive that is one inch away) I'm ordering a new drive bay to improve this, but should a bad cable cause lockups? Thanks for your help. Here's my smartctl output: #smartctl -a /dev/ad0 smartctl 5.40 2010-10-16 r3189 [FreeBSD 8.1-RELEASE amd64] (local build) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Model Family: Western Digital Caviar Green (Adv. Format) family Device Model: WDC WD10EARS-00Y5B1 Serial Number:WD-WCAV55616522 Firmware Version: 80.00A80 User Capacity:1,000,204,886,016 bytes Device is:In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: Exact ATA specification draft version not indicated Local Time is:Sun Feb 6 23:42:17 2011 PST SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x84) Offline data collection activity was suspended by an interrupting command from host. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (20460) seconds. Offline data collection capabilities:(0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities:(0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability:(0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time:( 2) minutes. Extended self-test routine recommended polling time:( 236) minutes. Conveyance self-test routine recommended polling time:( 5) minutes. SCT capabilities: (0x3031) SCT Status supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051Pre-fail Always - 0 3 Spin_Up_Time0x0027 121 121 021Pre-fail Always - 6933 4 Start_Stop_Count0x0032 100 100 000Old_age Always - 30 5 Reallocated_Sector_Ct 0x0033 200 200 140Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 200 200 000Old_age Always - 0 9 Power_On_Hours 0x0032 097 097 000Old_age Always - 2664 10 Spin_Retry_Count0x0032 100 253 000Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 253 000Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000Old_age Always - 28 192 Power-Off_Retract_Count 0x0032 200 200 000Old_age Always - 27 193 Load_Cycle_Count0x0032 135 135 000Old_age Always - 196151 194 Temperature_Celsius 0x0022 125 114 000Old_age Always - 22 196 Reallocated_Event_Count 0x0032 200 200 000Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000Old_age Always - 0 198 Offline_Uncorrectable 0x0030 200 200 000Old_age Offline - 0 199 UDMA_CRC_Error_Count0x0032 200 200
