mergemaster annoyance or not?
Hello! As long time FreeBSD user I am concerned about RELEASE and STABLE configuration files inconsistency. No big deal but really annoying if you want to upgrade systems occassionally. The problem is that there is huge amount of old files between RELEASE and STABLE config files- more precisely lots of older config files in STABLE that is really strange considered that it should be much newer than RELEASE. FE: -# $FreeBSD: src/etc/rc.d/network_ipv6,v 1.37.18.1 2008/11/25 02:59:29 kensmith Exp $ +# $FreeBSD: src/etc/rc.d/network_ipv6,v 1.37 2004/10/07 13:55:26 mtm Exp $ -# $FreeBSD: src/etc/rc.d/newsyslog,v 1.5.2.1.2.1 2008/11/25 02:59:29 kensmith Exp $ +# $FreeBSD: src/etc/rc.d/newsyslog,v 1.5.2.1 2008/01/28 07:55:44 dougb Exp $ -# $FreeBSD: src/etc/rc.d/nfsclient,v 1.6.6.1 2008/11/25 02:59:29 kensmith Exp $ +# $FreeBSD: src/etc/rc.d/nfsclient,v 1.6 2006/12/31 10:37:18 yar Exp $ -# $FreeBSD: src/etc/rc.d/nfsd,v 1.13.10.1.2.1 2008/11/25 02:59:29 kensmith Exp $ +# $FreeBSD: src/etc/rc.d/nfsd,v 1.13.10.1 2008/01/28 07:55:44 dougb Exp $ -# $FreeBSD: src/etc/crontab,v 1.32.32.1 2008/11/25 02:59:29 kensmith Exp $ +# $FreeBSD: src/etc/crontab,v 1.32 2002/11/22 16:13:39 tom Exp $ Oh, and why I have to remove myself from the system? I don't get it. Same problem with master.password file- why the hell I have to change that? -# $FreeBSD: src/etc/group,v 1.35.6.1 2008/11/25 02:59:29 kensmith Exp $ +# $FreeBSD: src/etc/group,v 1.35 2007/06/11 18:36:39 ceri Exp $ # -wheel:*:0:root,antik +wheel:*:0:root daemon:*:1: kmem:*:2: sys:*:3: @@ -29,4 +29,3 @@ www:*:80: nogroup:*:65533: nobody:*:65534: -antik:*:1001: How comes that difference is 4 years? Of course files are identical but this is annoying to go through files that is not changed at all. Some files are newer- that's expected BTW. Please syncronize your cvs between releases. ___ 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: mergemaster annoyance or not?
On Thu, 12 Mar 2009, Andrei Kolu wrote: Hello! As long time FreeBSD user I am concerned about RELEASE and STABLE configuration files inconsistency. This topic was covered recently, you might want to check the archives. -# $FreeBSD: src/etc/rc.d/network_ipv6,v 1.37.18.1 2008/11/25 02:59:29 kensmith Exp $ +# $FreeBSD: src/etc/rc.d/network_ipv6,v 1.37 2004/10/07 13:55:26 mtm Exp $ What you're seeing is an artifact of the way that CVS deals with cutting a release. Even though the content of the files is the same, the CVS Id is updated in the release branch so that you can track revisions to that file that occur within that branch (e.g., RELENG_6_4), as opposed to the changes that occur in the parent branch (RELENG_6). This is a feature. You can easily deal with this in mergemaster by using the -U option (please see the man page). If you're dealing with the problem of a clean installation from a -RELEASE CD (or similar) upgrading to the stable branch for the first time, -U won't help you unfortunately. But it will help you on each successive update. For that first update what I usually do is 'rm -r /etc/rc.d/* /etc/periodic/* /etc/defaults/*' and then use mergemaster's -i option. That will cover the majority of the problem. hope this helps, Doug -- This .signature sanitized for your protection ___ 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: mergemaster annoyance or not?
Doug Barton wrote: On Thu, 12 Mar 2009, Andrei Kolu wrote: Hello! As long time FreeBSD user I am concerned about RELEASE and STABLE configuration files inconsistency. This topic was covered recently, you might want to check the archives. -# $FreeBSD: src/etc/rc.d/network_ipv6,v 1.37.18.1 2008/11/25 02:59:29 kensmith Exp $ +# $FreeBSD: src/etc/rc.d/network_ipv6,v 1.37 2004/10/07 13:55:26 mtm Exp $ What you're seeing is an artifact of the way that CVS deals with cutting a release. Even though the content of the files is the same, the CVS Id is updated in the release branch so that you can track revisions to that file that occur within that branch (e.g., RELENG_6_4), as opposed to the changes that occur in the parent branch (RELENG_6). This is a feature. You can easily deal with this in mergemaster by using the -U option (please see the man page). If you're dealing with the problem of a clean installation from a -RELEASE CD (or similar) upgrading to the stable branch for the first time, -U won't help you unfortunately. But it will help you on each successive update. For that first update what I usually do is 'rm -r /etc/rc.d/* /etc/periodic/* /etc/defaults/*' and then use mergemaster's -i option. That will cover the majority of the problem. I am upgrading from 7.1-RELEASE (cd) to 7.1-STABLE, anyway it does not make any sense to upgrade to older version of config files. I hope this issue will be resolved. FreeBSD 7.1-STABLE #0: Wed Mar 11 22:29:33 EET 2009 amd64 ___ 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: Tester wanted for multipath failover iSCSI target software
Daisuke Aoyama wrote: I am interested in giving this a try, though not immediately as I am away from the office at the moment. Do I need to apply a patch to iscontrol to make it work though ? I can't work it out from your statement above. Yes, you need. Than ks. Is the intent to integrate with the base system eventually rather than have it in ports ? It would be nice to have a native implementation which could then be integrated with ZFS. istgt is still under development. so I don't think integration. before thinking, I should work to fix more bugs. I have tested net/istgt for couple of days with Windows XP and it works more reliable than NetBSD net/iscsi-target. With NetBSD implementation sometimes I lost partition filesystem information after disconnecting server from network or rebooting my computer. Is there any particular testcases you want to perform? Tested on FreeBSD 7.1-STABLE #0: Wed Mar 11 22:29:33 EET 2009 P.S. Strange, but I can't find istgt in ports anymore... ___ 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: mergemaster annoyance or not?
Andrei Kolu wrote: Doug Barton wrote: -# $FreeBSD: src/etc/rc.d/network_ipv6,v 1.37.18.1 2008/11/25 02:59:29 kensmith Exp $ +# $FreeBSD: src/etc/rc.d/network_ipv6,v 1.37 2004/10/07 13:55:26 mtm Exp $ What you're seeing is an artifact of the way that CVS deals with cutting a release. Even though the content of the files is the same, I am upgrading from 7.1-RELEASE (cd) to 7.1-STABLE, anyway it does not make any sense to upgrade to older version of config files. Please read what I said above more carefully, especially the bit about the content of the files being the same. I hope this issue will be resolved. What you're seeing is a mildly annoying side effect of how CVS works. There is nothing to resolve. On the other hand, if we follow through with cutting releases on the 8.x branch with subversion we won't have this problem. So perhaps that will help in your situation. Doug -- This .signature sanitized for your protection ___ 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: mergemaster annoyance or not?
On Thu, Mar 12, 2009 at 12:22:19AM -0700, Doug Barton wrote: What you're seeing is an artifact of the way that CVS deals with cutting a release. Even though the content of the files is the same, the CVS Id is updated in the release branch so that you can track revisions to that file that occur within that branch (e.g., RELENG_6_4), as opposed to the changes that occur in the parent branch (RELENG_6). This is a feature. I think these days we need (by default) /etc/mergemaster.rc filled in with something like this: DIFF_OPTIONS='-I$FreeBSD:.*[$] -I$NetBSD:.*[$]' IGNORE_FILES='/etc/motd' Else there is lots of annoyance running mergemaster first time and after each release and there will be lots of questions/complains about this. Eugene Grosbein ___ 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: Performance with hundreds of nullfs mounts?
Russell Jackson wrote: Ivan Voras wrote: hi, I seem to remember hearing an anecdote somewhere that using hundreds (or thousands?) nullfs mounts for jails results in unreasonably bad file system access performance. Does somebody have this kind of setup / is it true? I was doing this with jails --before we moved to VMware ESX (for better or worse)-- and didn't see any noticeable performance degradation at the time (6.x series). Thanks, everyone. I've tracked it down and I heard it from a collegue, only he was talking about unionfs not nullfs. For those interested, the biggest plus for going to the ESX model is that it decoupled low utilization Windows boxes from over-spec'ed hardware and made it available for FreeBSD to use ;-). The downsides are that it's proprietary, it's expensive, it's inefficient (e.g. duplicated files and kernel instances everywhere), and you need freak'in Windows boxes to manage it. Yes, ESX is nice. I've also tried XenServer (the official Xen) and it's been terrible - both slow and clunky. Any other experiences? signature.asc Description: OpenPGP digital signature
Re: mergemaster annoyance or not?
On Thursday 12 March 2009 18:17:53 Doug Barton wrote: I hope this issue will be resolved. What you're seeing is a mildly annoying side effect of how CVS works. There is nothing to resolve. I wouldn't classify it as mildly annoying that you need to manually intervene in every single file.. Eugene's idea for the default diff options makes a lot of sense to me - I don't think any normal user gives a hoot about the CVS Id of a file. (even devs!) -- 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 signature.asc Description: This is a digitally signed message part.
Re: Tester wanted for multipath failover iSCSI target software
I have tested net/istgt for couple of days with Windows XP and it works more reliable than NetBSD net/iscsi-target. With NetBSD implementation sometimes I lost partition filesystem information after disconnecting server from network or rebooting my computer. I am just trying it against the latest FreeBSD initiator. One thing I have noticed compared to the netbsd target is that it appears to have somewhat higer performance. cerrainly the speed that gstat says data is comming off the disc during a scrub is faster than with iscsi_target. On the other hand I have got some errors that I am trying to get to the bottom of. I set up a zpool laast night on a remote disc using the netbsd initiator and copied about 50 gig of data to it as lots of small files. I then switched to the istgt initiator this morning and am running a scrub on the pool. But it is telling me that there are a sigificant number of errors on the disc, which I wasnt expecting. I am now trying to find out if that is due to write errors using the taret last night, or read errors with the new target this morning. BTW, is there any way to get istgt to accept connections without needing to specify the initator string ? I am new to all these options for iSCSI having only used the simple netbsd one before. cheers, -pete. ___ 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: Tester wanted for multipath failover iSCSI target software
Hi, Thank you for reporting. I have tested net/istgt for couple of days with Windows XP and it works more reliable than NetBSD net/iscsi-target. With NetBSD implementation sometimes I lost partition filesystem information after disconnecting server from network or rebooting my computer. Yes, it is one of differences. istgt reports connected information such as SCSI port to the initiator for discriminating multipath and failover path. As a side effect, perhaps more accurate identification is possible. Is there any particular testcases you want to perform? If you use it as usual, it is tested enough. If I had to say, I want to know how much a CPU usage on the target machine. Because istgt is more complicated than iscsi-target. Tested on FreeBSD 7.1-STABLE #0: Wed Mar 11 22:29:33 EET 2009 Did you use the target with ZFS? or UFS? Did you use MCS feature? Thanks, -- Daisuke Aoyama ___ 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: Tester wanted for multipath failover iSCSI target software
Thank you for reporting. On the other hand I have got some errors that I am trying to get to the bottom of. I set up a zpool laast night on a remote disc using the netbsd initiator and copied about 50 gig of data to it as lots of small files. I then switched to the istgt initiator this morning and am running a scrub on the pool. But it is telling me that there are a sigificant number of errors on the disc, which I wasnt expecting. I am now trying to find out if that is due to write errors using the taret last night, or read errors with the new target this morning. I'm very interested in this case. BTW, is there any way to get istgt to accept connections without needing to specify the initator string ? I am new to all these options for iSCSI having only used the simple netbsd one before. sorry for no documents. special word ALL matches any initiator name/IPs. you can find more sample in istgt.large.conf.sample. [InitiatorGroup256] Comment ALL initiators from ALL IP InitiatorName ALL Netmask ALL Thanks, -- Daisuke Aoyama ___ 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: Tester wanted for multipath failover iSCSI target software
Thank you for reporting. ... I'm very interested in this case. Well, I just finihsed doing a 'zpool scrub' on the disc image mounted locally on the machine which was running istgt. That still shows some errors - but only 36 of them, compares to the 9000+ I get when running the scrub mounted remotely! I am going to do the whole test again just using istgt this time to see what happens. Some more information about my setup: Both machines are amd64 - running kernels from March 9th. The client has the latest version of iscsi_initiator on it as well. The server is using a file as the disc image, and the file is stored on a pair of terrabyte SATA drives in a mirrored zpool. special word ALL matches any initiator name/IPs. you can find more sample in istgt.large.conf.sample. Ah, thanks, thats helps a lot :-) I will let you know what happens witha new test. -pete. ___ 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: 7.1 panic vm_page_startup: inconsistent page counts
On Thursday 12 March 2009 12:36:46 am Peter Jeremy wrote: I'm trying to upgrade an 11 month old FreeBSD 7 image in a VMware 4.5.2 guest to an up-to-date -stable and it panics as above. I've added a printf to report the two counts and there's a difference of one page. I don't have any problems with the old 7-stable image or up-to-date 6-stable or -current using the same VMware version. A screendump for a verbose boot can be found at http://imagebin.ca/img/wahNNw.gif Can I safely delete the assert? I don't think so, I would report it to Alan. The one earlier report of this didn't include the detail that it was only off by one page. -- John Baldwin ___ 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: mergemaster annoyance or not?
On Thursday 12 March 2009 3:22:19 am Doug Barton wrote: On Thu, 12 Mar 2009, Andrei Kolu wrote: Hello! As long time FreeBSD user I am concerned about RELEASE and STABLE configuration files inconsistency. This topic was covered recently, you might want to check the archives. -# $FreeBSD: src/etc/rc.d/network_ipv6,v 1.37.18.1 2008/11/25 02:59:29 kensmith Exp $ +# $FreeBSD: src/etc/rc.d/network_ipv6,v 1.37 2004/10/07 13:55:26 mtm Exp $ What you're seeing is an artifact of the way that CVS deals with cutting a release. Even though the content of the files is the same, the CVS Id is updated in the release branch so that you can track revisions to that file that occur within that branch (e.g., RELENG_6_4), as opposed to the changes that occur in the parent branch (RELENG_6). This is a feature. No, it's a bug in our SVN - CVS importer that when the branch is created in SVN, all the files get forced checkins on the CVS branch which gratuitously bumps all the CVS IDs. Go compare RELENG_6_3 and RELENG_6 (at the time of the branch) IDs vs what happened with 6.4 and 7.1. It does create a _lot_ of noise for later /etc merges. Probably our SVN - CVS importer could simply ignore commits that create a new branch to avoid this problem. -- John Baldwin ___ 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: Tester wanted for multipath failover iSCSI target software
Oh dear doing the test again caused the client machine to panic, with the following message: panic: solaris assert: 0 == dmu_buf_hold(os, lr-lr_foid, boff, zgd, db), file /usr/src/sys/modules/zfs/../../cddl/controb/opensolaris/uts/common/fs/zfs/zfs_nops.c, line: 955 (that was copied out by hand so there might be typos). Since that was on the client side it makes me think there is a mproblem with the initiator. But the same test to the netbsd-target works fine, so it's some interaction between the two bits of software I guess. -pete. ___ 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: mergemaster annoyance or not?
This is what I have in my /etc/mergemaster.rc; it will probably help in your case: DIFF_FLAG='-Bub' DIFF_OPTIONS='-I$FreeBSD:.*[$]' IGNORE_MOTD=yes The first line causes diff to not display changes that only affect whitespace. The second line ignores the CVS id lines, so that files will compare equal that only differ in the CVS ids. The third line lets me keep my motd file without being asked for it every time. There are options to keep other files, too, so you might want to add the master.passwd and group files to that list. However, sometines a new group or user needs to be created for proper operation -- that's why I prefer to see those files whenever they change. Please refer to the mergemaster(8) manual page for details. You might also want so set AUTO_INSTALL and AUTO_UPGRADE. Best regards Oliver PS: I think the above options should _not_ be on by default, because that would be a POLA violation. Those people who want them can easily add them to their mergemaster.rc file. -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Perl will consistently give you what you want, unless what you want is consistency. -- Larry Wall ___ 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
HEADS UP: Atheros HAL merged to RELENG_7
Hello all, This is just a note to let you all know that the open source Atheros HAL has been merged from HEAD to -STABLE. I tested it out OK on an IBM/Lenovo ThinkPad T43 with an AR5212 in HostAP and STA mode, and on an ASUS EeePC 701 with AH5424 (PCI-express) in STA mode. The ath_rate* modules have been removed as kernel modules, however the options remain, as these are now knobs for the HAL as it gets built into if_ath.ko itself. Furthermore, the ath_hal module should no longer be required. regards, BMS ___ 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: Atheros HAL merged to RELENG_7
Wondering . . . did you mean 'AR5424', not 'AH5424'? I'm asking because I have an atheros AR5424 and am (patiently) waiting for support and can't find info on an atheros AH5424. Thanks. On Thu, Mar 12, 2009 at 11:31 AM, Bruce Simpson b...@incunabulum.net wrote: Hello all, This is just a note to let you all know that the open source Atheros HAL has been merged from HEAD to -STABLE. I tested it out OK on an IBM/Lenovo ThinkPad T43 with an AR5212 in HostAP and STA mode, and on an ASUS EeePC 701 with AH5424 (PCI-express) in STA mode. The ath_rate* modules have been removed as kernel modules, however the options remain, as these are now knobs for the HAL as it gets built into if_ath.ko itself. Furthermore, the ath_hal module should no longer be required. regards, BMS ___ 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 -- www.nealhogan.net www.lambdaserver.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
vpn1411 in Laptop (Thinkpad T31)
Hi, this might seem like a strange question, but I wonder if there would be any benefit by using a vpn1411 minipci card to encrypt/decrypt geli encrypted partitions on the fly. I'm using a Thinkpad T31 with a P4 at 2GHz and playing back HD Videos doesn't work flawlessly from the encrypted partition. I might use a 2nd HDD connected to the media bay, but this would mean that I need to copy the data to this disk. Using a vpn1411 seems like a good option. I don't use the minipci slot for WLAN (I've a PCMCIA card that I only insert if I need to use it), so it's free. But I wonder if the traffic to and from the card would saturate the PCI bus and lead to other problems. What do you think? Cheers Christian Walther ___ 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: mergemaster annoyance or not?
On Friday 13 March 2009 01:35:27 Oliver Fromme wrote: PS: I think the above options should _not_ be on by default, because that would be a POLA violation. Those people who want them can easily add them to their mergemaster.rc file. Perhaps they should be suggested in the man page.. I agree it's a POLA violation, but it is rather annoying they can't be made the default as it is very much more pleasant to use with those options - the defaults can be a recipe for either extreme tedium, or errors depending on how patient you are :) I wonder how hard it would be to add 3 way merging (like sysutils/etcmerge) to mergemaster.. -- 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 signature.asc Description: This is a digitally signed message part.
Re: mergemaster annoyance or not?
On Thu, Mar 12, 2009 at 04:05:27PM +0100, Oliver Fromme wrote: This is what I have in my /etc/mergemaster.rc; it will probably help in your case: DIFF_FLAG='-Bub' DIFF_OPTIONS='-I$FreeBSD:.*[$]' IGNORE_MOTD=yes Yes, it helps and I like it. But I'm forced to put it to each and every box I install; that does not annoy me so much but other people are annoyed. PS: I think the above options should _not_ be on by default, because that would be a POLA violation. Those people who want them can easily add them to their mergemaster.rc file. I see this as POLA recovery because there where no such problem with mergemaster before switch to SVN. Eugene Grosbein ___ 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: mergemaster annoyance or not?
Eugene Grosbein wrote: On Thu, Mar 12, 2009 at 04:05:27PM +0100, Oliver Fromme wrote: This is what I have in my /etc/mergemaster.rc; it will probably help in your case: DIFF_FLAG='-Bub' DIFF_OPTIONS='-I$FreeBSD:.*[$]' IGNORE_MOTD=yes Newer versions of mergemaster prefer the following: IGNORE_FILES='/etc/motd' Other files can be added to that list as desired. Yes, it helps and I like it. But I'm forced to put it to each and every box I install; that does not annoy me so much but other people are annoyed. There is no reason to install this permanently. You can use this option the first time you upgrade, then use the -U option subsequently. PS: I think the above options should _not_ be on by default, because that would be a POLA violation. Those people who want them can easily add them to their mergemaster.rc file. I see this as POLA recovery because there where no such problem with mergemaster before switch to SVN. IMO this should be fixed at the CVS importer level personally. However there are workarounds available for the time being. Doug -- This .signature sanitized for your protection ___ 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
NICs locking up, *tcp_sc_h
Hello all, I recently installed my first amd64 system (currently running RELENG_7 from 2009-03-11) to replace an aged ppc box and have been having dramas with the network locking up. Breaking into the debugger manually and ps-ing shows the network card (e.g., [irq20: fxp0+]) in state LL in *tcp_sc_h. It seems the process(es) trying to access the card at the time is / are in state L in *tcp. I thought this may have been something-or-other in the fxp driver, so installed an rl card and sadly ran into the issue again. The console appears unresponsive, but I can get into the debugger (and as soon as I have, input I'd sent seems to go through, e.g., if I hit Enter a couple o' times, nothing happens; when I Ctrl+Alt+Esc into the debugger a few login prompts pop up before the debugger output). A where on the fxp / rl process (thread?) gives (transcribed from the console): Tracing PID 31 tid 100030 td 0xff00012016e0 sched_switch() at sched_switch+0xf1 mi_switch() at mi_switch+0x18f turnstile_wait() at turnstile_wait+0x1cf _mtx_lock_sleep() at _mtx_lock_sleep+0x76 syncache_lookup() at syncache_lookup+0x176 syncache_expand() at syncache_expand+0x38 tcp_input() at tcp_input+0xa7d ip_input() at ip_input+0xa8 ether_demux() at ether_demux+0x1b9 ether_input() at ether_input+0x1bb fxp_intr() at fxp_intr+0x233 ithread_loop() at ithread_loop+0x17f fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe A where on a process stuck in *tcp, in this case [swi4: clock], gave the somewhat similar: sched_switch() at sched_switch+0xf1 mi_switch() at mi_switch+0x18f turnstile_wait() at turnstile_wait+0x1cf _rw_rlock() at _rw_rlock+0x8c ipfw_chk() at ipfw_chk+0x3ab2 ipfw_check_out() at ipfw_check_out+0xb1 pfil_run_hooks() at pfil_run_hooks+0x9c ip_output() at ip_output+0x367 syncache_respond() at syncache_respond+0x2fd syncache_timer() at syncache_timer+0x15a (...) In this particular case, the fxp0 card is in a lagg with rl0, but this problem can be triggered with either card on their own... The scheduler is SCHED_ULE. I'm not too sure how to give more useful information that this, I'm afraid. It's a custom kernel, too... Do I need to supply information on what code actually exists at the relevant addresses (I'm not at all clued in on how to do this... Sorry!)? Should I chuck WITNESS, INVARIANTS et al. in? I *think* every time this has been triggered there's been a python2.5 process in the *tcp state. This machine runs net-p2p/deluge and generally has at least 100 TCP connections on the go at any given time. Can anyone give me a clue as to what I might do to track this down? Appreciate any pointers. -- Nick Withers email: n...@nickwithers.com Web: http://www.nickwithers.com Mobile: +61 414 397 446 signature.asc Description: This is a digitally signed message part
