Re: Freebsd 8.1 + xorg + radeonhd hang
On 2010-Sep-15 22:29:46 +0200, Eivind E eivi...@terraplane.org wrote: That has crossed my mind aswell, the only thing which makes me doubt it is that after updating X number of months ago (probably about a year and a half), it started to work with no problems whatsoever. Now, after upgrading again, it has stopped working. Can I suggest adding a Virtual 1280 1024 (or similar) to the 'SubSection Display' of 'Section Screen'. I ran into some wierd problems with multiple screens and found that the virtual size isn't correctly initialised unless it's explicitly specified. Also, specifying EXA acceleration is fairly mandatory: The default XAA acceleration is broken. -- Peter Jeremy pgpuqhaZGDnMJ.pgp Description: PGP signature
Re: Freebsd 8.1 + xorg + radeonhd hang
On 09/19/10 08:20, Peter Jeremy wrote: On 2010-Sep-15 22:29:46 +0200, Eivind Eeivi...@terraplane.org wrote: That has crossed my mind aswell, the only thing which makes me doubt it is that after updating X number of months ago (probably about a year and a half), it started to work with no problems whatsoever. Now, after upgrading again, it has stopped working. In my case, this is exactly the other way around. There was atime when radeonhd and radeon both worked with radeon boards, even with DRI set to on. I recall the the time, whe radeonhd was ugraded to semthing like 1.2.8 or so the problems started occuring (in my case) There is also an issue with SMP. On my private UP box I used a radeon HD4830, both with radeonhd and radeon (tend to use radeonhd because it was faster). Since this box got an hardware exchange (same FBSD 8.1 but with SMP kernel due to dual core, 4GB RAM etc.), both driver, radeon and radeonhd crashes when leaving a X11 session or sending a 'killall -HUP X'. The box simply freezes. My lab's box has now a HD4770 board. The box is also FreeBSD 8.1, SMP kernel, 8GB RAM. No matter what radeon driver, enabling DRI results in a immediate crash of the box when X comes up. Leaving a X11 session also results in a freeze (my crashes are always freezes, there is no coredump, just a black screen).The same happens with a HD4670 board. More interesting is the usage of DBUS and HALD. With both enabled, the box dies immediately when X comes up. No matter whether radeon or radeonhd is used. Well, without X, dbus and hald work well. with X. ... Regards, Oliver ___ 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
em nic getting wedged under high load
At first we thought it might be the NIC, but we have since changed out the nic, motherboard and power supply. Under high loads, we are seeing the nic become wedged to the point where we have to reboot the box to unwedge it This is an intel board (S3420GPX) from Intel with 8G of RAM, and i5, amd64 running RELENG_8. We first noticed it when we upgraded to an i7 board. Thinking it was hardware, we changed it out to the i5 and are still seeing the nic wedging under high nfs load. e...@pci0:0:25:0:class=0x02 card=0x34ec8086 chip=0x10ef8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 13[e0] = PCI Advanced Features: FLR TP e...@pci0:9:0:0: class=0x02 card=0x34ec8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c vmstat -i interrupt total rate irq16: siis0 510107228 irq18: arcmsr0479177214 irq19: twa016297 7 irq21: ehci03390 1 irq23: ehci14628 2 cpu0: timer 4469679 1999 irq256: em0 1183006529 irq257: em1 6120960 2738 irq258: ahci0 507884227 cpu1: timer 4461694 1996 cpu2: timer 4461618 1996 cpu3: timer 4461832 1996 Total 26680272 11937 In its wedged state, the nic's stats show dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.0.5 dev.em.1.%driver: em dev.em.1.%location: slot=0 function=0 handle=\_SB_.PCI0.PEX4.HART dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x8086 subdevice=0x34ec class=0x02 dev.em.1.%parent: pci9 dev.em.1.nvm: -1 dev.em.1.rx_int_delay: 0 dev.em.1.tx_int_delay: 66 dev.em.1.rx_abs_int_delay: 66 dev.em.1.tx_abs_int_delay: 66 dev.em.1.rx_processing_limit: 100 dev.em.1.link_irq: 0 dev.em.1.mbuf_alloc_fail: 0 dev.em.1.cluster_alloc_fail: 0 dev.em.1.dropped: 0 dev.em.1.tx_dma_fail: 0 dev.em.1.fc_high_water: 18432 dev.em.1.fc_low_water: 16932 dev.em.1.mac_stats.excess_coll: 0 dev.em.1.mac_stats.symbol_errors: 0 dev.em.1.mac_stats.sequence_errors: 0 dev.em.1.mac_stats.defer_count: 0 dev.em.1.mac_stats.missed_packets: 41522 dev.em.1.mac_stats.recv_no_buff: 19 dev.em.1.mac_stats.recv_errs: 0 dev.em.1.mac_stats.crc_errs: 0 dev.em.1.mac_stats.alignment_errs: 0 dev.em.1.mac_stats.coll_ext_errs: 0 dev.em.1.mac_stats.rx_overruns: 41398 dev.em.1.mac_stats.watchdog_timeouts: 0 dev.em.1.mac_stats.xon_recvd: 0 dev.em.1.mac_stats.xon_txd: 0 dev.em.1.mac_stats.xoff_recvd: 0 dev.em.1.mac_stats.xoff_txd: 0 dev.em.1.mac_stats.total_pkts_recvd: 95229129 dev.em.1.mac_stats.good_pkts_recvd: 95187607 dev.em.1.mac_stats.bcast_pkts_recvd: 79244 dev.em.1.mac_stats.mcast_pkts_recvd: 0 dev.em.1.mac_stats.rx_frames_64: 93680 dev.em.1.mac_stats.rx_frames_65_127: 1516349 dev.em.1.mac_stats.rx_frames_128_255: 4464941 dev.em.1.mac_stats.rx_frames_256_511: 4024 dev.em.1.mac_stats.rx_frames_512_1023: 2096067 dev.em.1.mac_stats.rx_frames_1024_1522: 87012546 dev.em.1.mac_stats.good_octets_recvd: 0 dev.em.1.mac_stats.good_octest_txd: 0 dev.em.1.mac_stats.total_pkts_txd: 66775098 dev.em.1.mac_stats.good_pkts_txd: 66775098 dev.em.1.mac_stats.bcast_pkts_txd: 509 dev.em.1.mac_stats.mcast_pkts_txd: 7 dev.em.1.mac_stats.tx_frames_64: 48038472 dev.em.1.mac_stats.tx_frames_65_127: 13402833 dev.em.1.mac_stats.tx_frames_128_255: 5324413 dev.em.1.mac_stats.tx_frames_256_511: 957 dev.em.1.mac_stats.tx_frames_512_1023: 319 dev.em.1.mac_stats.tx_frames_1024_1522: 8104 dev.em.1.mac_stats.tso_txd: 1069 dev.em.1.mac_stats.tso_ctx_fail: 0 dev.em.1.interrupts.asserts: 0 dev.em.1.interrupts.rx_pkt_timer: 0 dev.em.1.interrupts.rx_abs_timer: 0 dev.em.1.interrupts.tx_pkt_timer: 0 dev.em.1.interrupts.tx_abs_timer: 0 dev.em.1.interrupts.tx_queue_empty: 0 dev.em.1.interrupts.tx_queue_min_thresh: 0 dev.em.1.interrupts.rx_desc_min_thresh: 0 dev.em.1.interrupts.rx_overrun: 0 dev.em.1.host.breaker_tx_pkt: 0 dev.em.1.host.host_tx_pkt_discard: 0 dev.em.1.host.rx_pkt: 0 dev.em.1.host.breaker_rx_pkts: 0 dev.em.1.host.breaker_rx_pkt_drop: 0 dev.em.1.host.tx_good_pkt: 0 dev.em.1.host.breaker_tx_pkt_drop: 0 dev.em.1.host.rx_good_bytes: 0 dev.em.1.host.tx_good_bytes: 0 dev.em.1.host.length_errors: 0
Re: Serial console problems with stable/8
On Mon, Sep 13, 2010 at 09:19:54PM -0700, Jeremy Chadwick wrote: On Mon, Sep 13, 2010 at 08:44:02PM +0200, Ed Schouten wrote: Maybe we should just implement /dev/console in such a way that it can never get stuck on dcd. I've seen this break too many times. Below is an untested patch. Anyone willing to test it for me? I'll test this out on our RELENG_8 system tonight. RELENG_8 system in question rebuilt with patch; works fine! (Tested both single-user, and multi-user with getty) If solves Oliver's issue, I'd say commit it. :-) -- | 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: MFC of ZFSv15
But I should be able to boot my ZFSv14 root pool using the ZFSv15 build of FreeBSD, correct? But the problem scenario would be when I've upgraded my root pool to v15 and I attempt to boot it with v14 boot loader. At least that is what I think ... I guess what I'm getting at is ... you should be able to buildworld, installkernel, reboot, installworld, reboot without worry. But after your run 'zpool upgrade', you will need to re-write the bootcode using gpart on each of your root pool ZFS disks. Am I understanding this correctly ? Thanks for all the work on ZFS BTW, it's great! Dan On Sep 16, 2010, at 10:59 AM, Martin Matuska wrote: Dont forget to read the general ZFS notes section in UPDATING: ZFS notes - When upgrading the boot ZFS pool to a new version, always follow these two steps: 1.) recompile and reinstall the ZFS boot loader and boot block (this is part of make buildworld and make installworld) 2.) update the ZFS boot block on your boot drive The following example updates the ZFS boot block on the first partition (freebsd-boot) of a GPT partitioned drive ad0: gpart bootcode -p /boot/gptzfsboot -i 1 ad0 Non-boot pools do not need these updates. Dňa 16. 9. 2010 17:43, Mike Tancsa wrote / napísal(a): At 11:18 AM 9/16/2010, jhell wrote: On 09/16/2010 09:55, Mike Tancsa wrote: Thanks again for all the ZFS fixes and enhancements! Are there any caveats to upgrading ? Do I just do zpool upgrade -a zfs upgrade -a or are there any extra steps ? Hi Mike, No-one knows your bootcode better than you. So if you are upgrading don't forget if you are on a ZFS root then your bootcode might need updating. Hi, I am booting off UFS right now so no bootcode updates for me :) I did look at UPDATING which does mention 20100915: A new version of ZFS (version 15) has been merged. This version uses a python library for the following subcommands: zfs allow, zfs unallow, zfs groupspace, zfs userspace. For full functionality of these commands the following port must be installed: sysutils/py-zfs ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ 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 Dan -- Dan Mack m...@macktronics.com ___ 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: MFC of ZFSv15
But I should be able to boot my ZFSv14 root pool using the ZFSv15 build of FreeBSD, correct? But the problem scenario would be when I've upgraded by root pool to v15 and I attempt to boot it with v14 boot loader. At least that is what I think ... I guess what I'm getting at is ... you should be able to buildworld, installkernel, reboot, installworld, reboot without worry. But when after your run 'zpool upgrade', you will need to re-write the bootcode using gpart on each of your root pool ZFS disks. Am I understanding this correctly ? Thanks for all the work on ZFS BTW, it's great! Dan On Sep 16, 2010, at 2:03 PM, Henri Hennebert wrote: On 09/16/2010 17:18, jhell wrote: On 09/16/2010 09:55, Mike Tancsa wrote: Thanks again for all the ZFS fixes and enhancements! Are there any caveats to upgrading ? Do I just do zpool upgrade -a zfs upgrade -a or are there any extra steps ? Hi Mike, No-one knows your bootcode better than you. So if you are upgrading don't forget if you are on a ZFS root then your bootcode might need updating. I was bitten by this problem in a previous ZFS upgrade. To be sure, I have added this patch to zfsimpl.c so, at boot I know if zpool/zfs upgrade will be OK. Henri Regards, UPDATING should have anything else. sys_boot_zfs.patch___ 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 Dan -- Dan Mack m...@macktronics.com ___ 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: MFC of ZFSv15
On 19/09/2010 17:36:01, Dan Mack wrote: But I should be able to boot my ZFSv14 root pool using the ZFSv15 build of FreeBSD, correct? But the problem scenario would be when I've upgraded my root pool to v15 and I attempt to boot it with v14 boot loader. At least that is what I think ... Yes. The bootloader is not prescient, so bootloader compiled against v14 can't cope with a zpool using v15. It's only the on-disk format that counts in this: zfs software will operate perfectly well with older on-disk data formats. I guess what I'm getting at is ... you should be able to buildworld, installkernel, reboot, installworld, reboot without worry. But after your run 'zpool upgrade', you will need to re-write the bootcode using gpart on each of your root pool ZFS disks. If you want to be completely paranoid, you could update the bootcode on your boot drive (or one out of a mirror pair, if that's what you're using) at the point of running installkernel and way before you run 'zpool upgrade'. In theory, should this go horribly wrong and you end up with an unbootable system, you can recover by booting the 8.0 install media into FIXIT mode and reinstalling the bootblocks from there (or booting from the other disk in your mirror set). Once you've got a system you know will reboot with the new bootblocks, then go ahead and with installworld and updating the zpool version. Am I understanding this correctly ? Yep. That's quite right. Running 'zpool upgrade -a' is one of those operations you can't easily reverse, so designing an upgrade plan where you can stop and back-out at any point is quite tricky. Fortunately, the risk of things going wrong at the point of running zpool upgrade is really very small, so for most purposes, just ploughing ahead and accepting the really very small risk is going to be acceptable. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: MFC of ZFSv15
Thanks for the confirmation. This worked fine and I did notice that zpool upgrade zroot was nice enough to emit the reminder: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 which is slightly different than the recipe given in /usr/src/UPDATING: gpart bootcode -p /boot/gptzfsboot -i 1 ad0 Since the recipe for my root/zfs system included pmbr and gptzfsboot, I used the example emitted from the zpool command instead of the one from UPDATING. e.g. pool: zroot state: ONLINE status: The pool is formatted using an older on-disk format. The pool can still be used, but some features are unavailable. action: Upgrade the pool using 'zpool upgrade'. Once this is done, the pool will no longer be accessible on older software versions. scrub: none requested config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 mirror ONLINE 0 0 0 gpt/disk0 ONLINE 0 0 0 gpt/disk1 ONLINE 0 0 0 errors: No known data errors (zfs) ~ # zpool upgrade zroot This system is currently running ZFS pool version 15. Successfully upgraded 'zroot' from version 14 to version 15 If you boot from pool 'zroot', don't forget to update boot code. Assuming you use GPT partitioning and da0 is your boot disk the following command will do it: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 (zfs) ~/zfs # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad4 ad4 has bootcode (zfs) ~/zfs # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad5 ad5 has bootcode (zfs) ~/zfs # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad6 ad6 has bootcode (zfs) ~/zfs # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad7 ad7 has bootcode (zfs) ~/zfs # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad8 ad8 has bootcode (zfs) ~/zfs # reboot Dan On Sep 19, 2010, at 12:41 PM, Matthew Seaman wrote: On 19/09/2010 17:36:01, Dan Mack wrote: But I should be able to boot my ZFSv14 root pool using the ZFSv15 build of FreeBSD, correct? But the problem scenario would be when I've upgraded my root pool to v15 and I attempt to boot it with v14 boot loader. At least that is what I think ... Yes. The bootloader is not prescient, so bootloader compiled against v14 can't cope with a zpool using v15. It's only the on-disk format that counts in this: zfs software will operate perfectly well with older on-disk data formats. I guess what I'm getting at is ... you should be able to buildworld, installkernel, reboot, installworld, reboot without worry. But after your run 'zpool upgrade', you will need to re-write the bootcode using gpart on each of your root pool ZFS disks. If you want to be completely paranoid, you could update the bootcode on your boot drive (or one out of a mirror pair, if that's what you're using) at the point of running installkernel and way before you run 'zpool upgrade'. In theory, should this go horribly wrong and you end up with an unbootable system, you can recover by booting the 8.0 install media into FIXIT mode and reinstalling the bootblocks from there (or booting from the other disk in your mirror set). Once you've got a system you know will reboot with the new bootblocks, then go ahead and with installworld and updating the zpool version. Am I understanding this correctly ? Yep. That's quite right. Running 'zpool upgrade -a' is one of those operations you can't easily reverse, so designing an upgrade plan where you can stop and back-out at any point is quite tricky. Fortunately, the risk of things going wrong at the point of running zpool upgrade is really very small, so for most purposes, just ploughing ahead and accepting the really very small risk is going to be acceptable. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW Dan -- Dan Mack m...@macktronics.com ___ 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: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon
On Wed, 8 Sep 2010, Vadim Goncharov wrote: Which part of support for the Giant lock *over the network stack* was removed [emphasis mine] do you not understand? No, component removed was (1), I've underlined. The reason is performance for overall network stack, not ideology. For a practical reasons, it works but slow is better than doesn't work at all (due to absence of code in the src tree). Make it work. Make it right. Make it fast. In that order, know this? Sacrificing work for fast?.. Hmm, if it is not ideology, then what is it?.. Doug has already clarified, but just to follow up with some detail: Moving to a parallel network stack required that all portions of the stack code be updated to operate without the Giant lock present -- the Giant lock was a fundamental assumption in all kernel code in FreeBSD 4.x and earlier. This decade-long project was highly successful, and relied on members of the community stepping forward to adapt a very large code base by adding fine-grained locking to each component. The results have been extremely impressive, allowing our network stack to scale to 8+ CPUs (I'm actually testing with 32-thread systems as part of some network stack work I'm doing right now). Towards the end of the project, it was clear that a few components in the stack had attracted no interest from the community, and as such, were not going to get updated. As such, we went through a public deprecation and removal process, in which we appealed repeatedly for community members to update the code. This included i4b, one of our three ATM implementations, and one of our two IPSEC implementations. I've attached the i4b schedule below (a three-year process), but you can find information on the full process here: http://wiki.freebsd.org/NONMPSAFE_DEORBIT This was not an issue of i4b operating more slowly than the rest of the stack: it was that the code required fundamental architectural changes without which it couldn't compile, let alone run. We're all happy to have ISDN support come back in the tree if there's an owner for doing it! In the end, any significant code base in the kernel requires ownership -- it can continue through many minor changes without an owner, but major retrofits, such as moving to fine-grained locking, need the attention of someone who understands the code, is able to test the code, and has the time to invest in the code. We do a pretty good job at arranging this with a multi-million line code base, all told. Robert DateDoneEvent 18 July 2005yes Post MPSAFE network stack plan to a...@. 04 July 2007yes Disconnect parts of I4B from the build. HEADS-UP to i...@. 17 July 2007yes Post NET_NEEDS_GIANT() reminder to a...@. 27 July 2007yes Remove NET_NEEDS_GIANT(). 22 March 2008 yes Last call to seek for help rewriting I4B to keep it alive. 15 May 2008 yes Final announcement on isdn@ that I4B will be removed from 8/7. 26 May 2008 yes Remove i4b from HEAD. ___ 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
BIND9 built w/--disable-ipv6 on 8.1-STABLE
Hi - I just noticed (well, via a discussion in #ipv6 on freenode) that the default configure arguments for BIND9 on 8.1 include '--disable-ipv6'. % grep CONFIGARGS /usr/src/usr.sbin/named/Makefile CONFIGARGS='--prefix=/usr' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--enable-threads' '--disable-ipv6' '--enable-getifaddrs' '--disable-linux-caps' '--with-openssl=/usr' '--with-randomdev=/dev/random' This results in BIND9 not listening on IPv6 sockets, even if the listen-on-v6 directive is explicitly configured in the configuration file. Even worse, and why I didn't pick up on it until now, is that no warnings or errors are emitted about this during startup, although I suppose that is more of a BIND problem than a FreeBSD one. Strangely enough, the control socket still listens on ::1 in addition to 127.0.0.1. Does anyone know why this was done, or if there's any harm in reenabling it and rebuilding? - Mark -- Mark Kamichoff p...@prolixium.com http://www.prolixium.com/ signature.asc Description: Digital signature
Re: BIND9 built w/--disable-ipv6 on 8.1-STABLE
On Sun, Sep 19, 2010 at 02:37:21PM -0400, Mark Kamichoff wrote: I just noticed (well, via a discussion in #ipv6 on freenode) that the default configure arguments for BIND9 on 8.1 include '--disable-ipv6'. % grep CONFIGARGS /usr/src/usr.sbin/named/Makefile CONFIGARGS='--prefix=/usr' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--enable-threads' '--disable-ipv6' '--enable-getifaddrs' '--disable-linux-caps' '--with-openssl=/usr' '--with-randomdev=/dev/random' This results in BIND9 not listening on IPv6 sockets, even if the listen-on-v6 directive is explicitly configured in the configuration file. Even worse, and why I didn't pick up on it until now, is that no warnings or errors are emitted about this during startup, although I suppose that is more of a BIND problem than a FreeBSD one. Strangely enough, the control socket still listens on ::1 in addition to 127.0.0.1. Does anyone know why this was done, or if there's any harm in reenabling it and rebuilding? Well, you can safely ignore this! I realized afterwards that '--disable-ipv6' just disables the default use of IPv6 in BIND, it doesn't completely disable the protocol. Turns out I was querying the wrong address with DIG when testing this, too. listen-on-v6 certainly works as expected, and enables IPv6 like it should. Although, that still does beg the question, why don't we want IPv6 enabled by default on new BIND installations? - Mark -- Mark Kamichoff p...@prolixium.com http://www.prolixium.com/ signature.asc Description: Digital signature
Re: MFC of ZFSv15
On 09/19/2010 18:33, Dan Mack wrote: But I should be able to boot my ZFSv14 root pool using the ZFSv15 build of FreeBSD, correct? Yes But the problem scenario would be when I've upgraded by root pool to v15 and I attempt to boot it with v14 boot loader. At least that is what I think ... You are right I guess what I'm getting at is ... you should be able to buildworld, installkernel, reboot, installworld, reboot without worry. It is the case But when after your run 'zpool upgrade', you will need to re-write the bootcode using gpart on each of your root pool ZFS disks. I prefer to install bootcode BEFORE. Then reboot and check it with the printf of my simple patch. Then you can zpool/zfs upgrade without problem. Am I understanding this correctly ? Thanks for all the work on ZFS BTW, it's great! Dan On Sep 16, 2010, at 2:03 PM, Henri Hennebert wrote: On 09/16/2010 17:18, jhell wrote: On 09/16/2010 09:55, Mike Tancsa wrote: Thanks again for all the ZFS fixes and enhancements! Are there any caveats to upgrading ? Do I just do zpool upgrade -a zfs upgrade -a or are there any extra steps ? Hi Mike, No-one knows your bootcode better than you. So if you are upgrading don't forget if you are on a ZFS root then your bootcode might need updating. I was bitten by this problem in a previous ZFS upgrade. To be sure, I have added this patch to zfsimpl.c so, at boot I know if zpool/zfs upgrade will be OK. Henri Regards, UPDATING should have anything else. sys_boot_zfs.patch___ 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 Dan -- Dan Mack m...@macktronics.com ___ 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
Panic with chromium and 8.1-STABLE (Thu Sep 16 09:52:17 BRT 2010)
Hi, I've just began trying chrome web browser from http://chromium.hybridsource.org/ but it triggered 2 panics on my 8.1-STABLE system. $ uname -a FreeBSD exxodus.fedaykin.here 8.1-STABLE FreeBSD 8.1-STABLE #26: Thu Sep 16 09:52:17 BRT 2010 li...@exxodus:/usr/obj/usr/src/sys/LIOUX amd64 The panic information is: panic: vm_page_unwire: invalid wire count: 0 cpuid = 0 KDB: enter: panic 0xff006ecce000: tag ufs, type VREG usecount 1, writecount 1, refcount 4 mountedhere 0 flags () v_object 0xff0151489870 ref 0 pages 8 lock type ufs: EXCL by thread 0xff00200947c0 (pid 25025) ino 119526591, on dev ufs/fsusr 0xff011107f938: tag ufs, type VREG usecount 0, writecount 0, refcount 4 mountedhere 0 flags (VV_NOSYNC|VI_DOINGINACT) v_object 0xff0151f7f870 ref 0 pages 1284 lock type ufs: EXCL by thread 0xff01882cc7c0 (pid 26689) ino 263, on dev md0 I've made available 2 ddb textdumps at: http://people.freebsd.org/~lioux/panic/2010091900/textdump.tar.0 http://people.freebsd.org/~lioux/panic/2010091900/textdump.tar.1 I was able to use chrome prior to this latest kernel update. Now, I can reproduce a kernel panic even browsing www.google.com Please, let me know if I can provide any further information. Regards, -- Mario S F Ferreira - DF - Brazil - I guess this is a signature. feature, n: a documented bug | bug, n: an undocumented feature ___ 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
