Very weird NFS-related hang in 6-beta5.
I mount my /usr/ports, /usr/src, et al from an NFS server. Everything seems to work fine except on one system where I've been seeing repeated hangs. Of course the system in question is my main desktop one, sigh. At first I was using gigabit Ethernet (Intel Pro/1000, 82545GM chipset) but the interface kept wedging hard, also on this system (and _not_ on the server, just on this one). I upgrading the system to 6.0-beta5 to see if the interface hangs went away. (I upgraded by NFS-mounting /usr/src over my parallel 100BaseTX network rather than the Gigabit network.) The upgrade worked fine but the hangs didn't disappear. I planned to swap out the gigabit card to see if it was the hardware that was the problem, but in the interim (not having a spare card lying around) I decided to do a complete portupgrade using the 100BaseTX network. This is where it gets weird. Because of all the hangs I've run into, at some point I made all the NFS mounts soft mounts. I've been watching these port builds, and from time to time, with no obvious pattern that can discern, NFS hangs. The server seems perfectly healthy and in fact the _interface_ seems healthy, but the particular I/O in question just hangs until it eventually times out due to the soft-mount. After it finally times out, things pick up and keep going again. NFS works fine for a while, then it hangs again. I captured one of the hangs; this is from the client machine: 16:17:53.642822 IP realtime.exit.com.560259720 > jill.exit.com.nfs: 132 read fh 1070,983185/1114384 8192 bytes @ 1925120 16:17:53.643541 IP jill.exit.com.nfs > realtime.exit.com.560259720: reply ok 1472 read 16:18:11.679433 IP realtime.exit.com.560259720 > jill.exit.com.nfs: 132 read fh 1070,983185/1114384 8192 bytes @ 1925120 16:18:11.680142 IP jill.exit.com.nfs > realtime.exit.com.560259720: reply ok 1472 read So the server gets the read and replies, but the client apparently never sees the reply (despite the fact that it is coming in on the interface and gets picked up by tcpdump). I've attached the dmesg from the client, if it helps, but I doubt it will. I can't imagine that this is hardware, although I guess it _might_ be. It's just very weird. Any hints as to cause or further steps I can take to diagnose it would be appreciated. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [Hackers] Re: A smarter mergemaster
On Fri, 30 Sep 2005, Yar Tikhiy wrote: Obviously, in order to do a 3-way merge, we need information about the old versions of original files as well. However, currently we have only the new versions in /usr/src and local versions in /etc for mergemaster to work with. I'll be glad to hear how etcmerge approaches this issue. In any case, we cannot offer the users to access the CVS repo when merging /etc. Personally, I'd like to see a complete copy of current unmodified /etc files installed to /usr/share/examples/etc. They could serve as the old original versions for the 3-way merge then. Alas, now the copy installed there is rather incomplete, motivation of which is unknown to me yet. Any ideas? To look outside of mergemaster for a moment, on our systems (FreeBSD and otherwise), we've traditionally used RCS to maintain system configuration files. We keep the system-distributed files on branch 1.1.1 (known as the "vendor branch" in CVS speak), and these increase 1.1.1.1 ... 1.1.1.2 ... 1.1.1.3 with each OS release (we update these manually). The trunk is used for our local changes, and we merge the changes from the vendor branch onto it. Using RCS, it's easy to see the local changes that have been made to the vendor release, and to see the changes that have been made between OS releases. For instance, to see the differences between a file and its distributed version, we'd use something like this: rcsdiff -r1.1.1 /etc/services Since CVS is based on RCS (and it seems more appropriate here), perhaps there could be a system CVS directory for /etc configuration files. Using your idea of /usr/share/examples/etc containing the most recent vendor files, there could be a tool which automatically merges the files there onto the vendor branch in the system CVS directory. That way, there would be no need for access to the main CVS repository each time someone upgrades a server. Just an idea. -- Even if you're one in a million, there are still 5,000 of you on the planet. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A smarter mergemaster
> : cd > : make etc-diff # ensure your workspace reflects what is in /etc > : > : > : make import # import the latest /usr/src/etc into etc workspace > : make diff # look over the changes > : > : make install# install to /etc; do mkdb etc. > : > : > : Finally: > : make commit # commit changes to local repo > : OR > : make undo # if things didn't quite work, restore /etc to old state. > : > : Roughly, the current mergemaster does the work of make > : import, make diff, repairs and install. > : > : Comments? > > I implemented something very similar to this for maintaining all the > etc files at Timing Solutions. We have a tree that gets installed > over the base OS. > > However, it doesn't easily allow for a mergemaster step since it > installs all the files with schg set, and doesn't have three way merge > in potential. mergemaster just has to do a merge in a temp workspace (initially a copy of /etc). Makefile can do all the schg magic when it installs to /etc. But this can get messy and I don't have a clean model One would have to keep Freebsd's /usr/src/etc in a vendor branch and do a checkout -j or something. When there is no conflict, an update goes very fast. In case of conflicts perhaps one can use the interactive merge feature from mergemaster. For files of same name but with entirely different content, merge with the vendor branch needs to be avoided. Basically anything we can do to make it easy to use this "best practice" would be nice even nicer if it covers /usr/local/etc! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd-5.4-stable panics
On 30 Sep, John Baldwin wrote:
> On Friday 30 September 2005 11:25 am, Antoine Pelisse wrote:
>> On 9/30/05, John Baldwin <[EMAIL PROTECTED]> wrote:
>> > On Friday 30 September 2005 05:24 am, Antoine Pelisse wrote:
>> > > Hi Robert,
>> > > I don't think your patch is correct, the total linked list can be
>> > > broken
>> > >
>> > > while the lock is released, thus just passing the link may not be
>> > > enough I have submitted a PR[1] for this a month ago but nobody took
>> > > care of it yet Regards,
>> > > Antoine Pelisse
>> > >
>> > > [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/84684
>> >
>> > I think this patch looks ok. Robert, can you get the original panic on
>> > this
>> > thread tested against this patch?
>>
>> I had a small program which could reproduce this panic in 10 seconds, it
>> was basically creating empty threads and calling kvm_getprocs() in the same
>> time. Anyway the patch was able to stop the program from panicing.
>> The panic is also reproducible in RELENG_6 and HEAD IIRC.
>
> It turns out that the sysctl buffer is already wired in one of the two cases
> that this function is called, so I moved the wiring up to the upper layer in
> the other case and cut out a bunch of the locking gymnastics as a result.
> Can you try this patch?
>
> Index: kern_proc.c
> ===
> RCS file: /usr/cvs/src/sys/kern/kern_proc.c,v
> retrieving revision 1.231
> diff -u -r1.231 kern_proc.c
> --- kern_proc.c 27 Sep 2005 18:03:15 - 1.231
> +++ kern_proc.c 30 Sep 2005 17:04:57 -
> @@ -875,22 +875,16 @@
>
> if (flags & KERN_PROC_NOTHREADS) {
> fill_kinfo_proc(p, &kinfo_proc);
> - PROC_UNLOCK(p);
> error = SYSCTL_OUT(req, (caddr_t)&kinfo_proc,
> sizeof(kinfo_proc));
> - PROC_LOCK(p);
> } else {
> - _PHOLD(p);
> FOREACH_THREAD_IN_PROC(p, td) {
> fill_kinfo_thread(td, &kinfo_proc);
> - PROC_UNLOCK(p);
> error = SYSCTL_OUT(req, (caddr_t)&kinfo_proc,
> sizeof(kinfo_proc));
> - PROC_LOCK(p);
> if (error)
> break;
> }
> - _PRELE(p);
> }
> PROC_UNLOCK(p);
> if (error)
> @@ -932,6 +926,9 @@
> if (oid_number == KERN_PROC_PID) {
> if (namelen != 1)
> return (EINVAL);
> + error = sysctl_wire_old_buffer(req, 0);
> + if (error)
> + return (error);
> p = pfind((pid_t)name[0]);
> if (!p)
> return (ESRCH);
>
sched_lock needs to be grabbed before the FOREACH_THREAD_IN_PROC loop.
Can _PHOLD()/_PRELE() be dropped?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd-5.4-stable panics
On 30 Sep, Antoine Pelisse wrote: > Hi Robert, > I don't think your patch is correct, the total linked list can be broken > while the lock is released, thus just passing the link may not be enough > I have submitted a PR[1] for this a month ago but nobody took care of it yet There are two problems with your patch: sched_lock needs to be held while iterating over the threads sysctl_kern_proc() calls sysctl_out_proc() multiple times in a loop in the !KERN_PROC_PID case, so the buffer needs to be wired before calling sysctl_out_proc(). Is _PHOLD()/_PRELE() needed if we don't drop PROC_LOCK? Passing a size estimate to sysctl_wire_old_buffer() is desirable, but sysctl_out_proc() would need some restructuring to do this correctly. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A smarter mergemaster
In <[EMAIL PROTECTED]>, Bakul Shah <[EMAIL PROTECTED]> typed: > Here is an idea for the mergemaster hackers' consideration! > > By keeping /etc files in a source repository one can archive > and document all local changes. This is useful for some of > the same reasons for which we keep sources in a repo: > recovery from mistakes, reuse of old code, checking who did > what, more than one person can make changes, tracking > history, debugging etc. Yup. I've been doing that for about a decade. It also makes a nice tool for disaster recovery. Rather than backing up all the FreeBSD-supplied softare, I back up the repository. After a disk loss, I pull the original install disks, reinstall, then check out the config files from the repository. > If mergemaster handled or worked with a local cvs /etc repo > that'd be very nice! The idea is to make changes and test > them in a temp workspace and commit them *only if they do the > right thing*! I envision a workflow something like this > (using make for illustration purposes): It really ought to provide hooks of some kind for dealing with the repository, rather than having CVS wired into it, as some of us prefer newer tools to CVS. But that's a minor detail. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A smarter mergemaster
In message: <[EMAIL PROTECTED]> Bakul Shah <[EMAIL PROTECTED]> writes: : Here is an idea for the mergemaster hackers' consideration! : : By keeping /etc files in a source repository one can archive : and document all local changes. This is useful for some of : the same reasons for which we keep sources in a repo: : recovery from mistakes, reuse of old code, checking who did : what, more than one person can make changes, tracking : history, debugging etc. : : If mergemaster handled or worked with a local cvs /etc repo : that'd be very nice! The idea is to make changes and test : them in a temp workspace and commit them *only if they do the : right thing*! I envision a workflow something like this : (using make for illustration purposes): : : cd : make etc-diff # ensure your workspace reflects what is in /etc : : : make import # import the latest /usr/src/etc into etc workspace : make diff # look over the changes : : make install # install to /etc; do mkdb etc. : : : Finally: : make commit # commit changes to local repo : OR : make undo # if things didn't quite work, restore /etc to old state. : : Roughly, the current mergemaster does the work of make : import, make diff, repairs and install. : : Comments? I implemented something very similar to this for maintaining all the etc files at Timing Solutions. We have a tree that gets installed over the base OS. However, it doesn't easily allow for a mergemaster step since it installs all the files with schg set, and doesn't have three way merge in potential. Doing the makefile goo is relatively easy, but the merging was much harder. Wanrer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A smarter mergemaster
Here is an idea for the mergemaster hackers' consideration! By keeping /etc files in a source repository one can archive and document all local changes. This is useful for some of the same reasons for which we keep sources in a repo: recovery from mistakes, reuse of old code, checking who did what, more than one person can make changes, tracking history, debugging etc. If mergemaster handled or worked with a local cvs /etc repo that'd be very nice! The idea is to make changes and test them in a temp workspace and commit them *only if they do the right thing*! I envision a workflow something like this (using make for illustration purposes): cd make etc-diff # ensure your workspace reflects what is in /etc make import # import the latest /usr/src/etc into etc workspace make diff # look over the changes make install# install to /etc; do mkdb etc. Finally: make commit # commit changes to local repo OR make undo # if things didn't quite work, restore /etc to old state. Roughly, the current mergemaster does the work of make import, make diff, repairs and install. Comments? -- bakul ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A smarter mergemaster
Kevin Oberman wrote: >>Date: Thu, 29 Sep 2005 23:41:57 -0700 >>From: Doug Barton <[EMAIL PROTECTED]> >>Sender: [EMAIL PROTECTED] >> >>One of the design decisions that you need to be aware of for this project >>since day one was to try and balance intelligent behavior and configuration >>options that would be useful for the very small percentage of the FreeBSD >>user community that constitutes our developers, versus the needs of the vast >>majority of "regular" users who need to be able to use the tool without >>becoming experts in either our build system, or the tool itself. That is why >>every single default for mergemaster is to do nothing. It was a purposeful >>decision to require the user to examine change requests, and make an >>affirmative choice to approve them. > > > Doug, > > You just hit on one of my pet peeves with mergemaster! Contrary to what > you say: "every single default for mergemaster is to do nothing", when a > file is found in /etc/rc.d that is not in /usr/src/etc/rc.d, the default > is to delete the file in etc. I think that this is a bad thing(tm). Agreed, The only thing I can think of as a reason for the anomaly is that at the time I wrote that code, the problems being reported with stale rc files were pretty numerous, and perhaps I was being overzealous. I've already said that I like Yar's idea of offering options to delete files or not, so I'll look at bringing at least that code in ASAP with the change that you requested, and possibly seek an MFC before 6 release. > By the way, having run FreeBSD before mergemaster, it's a huge > improvement on those ugly days. Thanks for the kind words, they are always appreciated. :) I should also take this opportunity to say that I appreciate all the interesting ideas on this thread, and I am paying attention to what's said even if I don't comment on it. Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A smarter mergemaster
On Fri, Sep 30, 2005 at 02:37:05PM -0700, Kevin Oberman wrote: > > You just hit on one of my pet peeves with mergemaster! Contrary to what > you say: "every single default for mergemaster is to do nothing", when a > file is found in /etc/rc.d that is not in /usr/src/etc/rc.d, the default > is to delete the file in etc. I think that this is a bad thing(tm). I > have to restore my profile.sh (which MUST be in /etc/rc.d as it needs to > be run before /usr is mounted). > > I do have an open PR on this (conf/85449), but it does not seem to have > gone anywhere other than being assigned to you last Friday. (No, I > didn't expect anything to happen this quickly. You just gave me such a > perfect opportunity to gripe!) FWIW, I wondered if my version of mergemaster in p4 was affected by this issue and found to my surprise that I had already addressed it in my changes. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd-5.4-stable panics
On 9/30/05, John Baldwin <[EMAIL PROTECTED]> wrote:
>
> On Friday 30 September 2005 11:25 am, Antoine Pelisse wrote:
> > On 9/30/05, John Baldwin <[EMAIL PROTECTED]> wrote:
> > > On Friday 30 September 2005 05:24 am, Antoine Pelisse wrote:
> > > > Hi Robert,
> > > > I don't think your patch is correct, the total linked list can be
> > > > broken
> > > >
> > > > while the lock is released, thus just passing the link may not be
> > > > enough I have submitted a PR[1] for this a month ago but nobody took
> > > > care of it yet Regards,
> > > > Antoine Pelisse
> > > >
> > > > [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/84684
> > >
> > > I think this patch looks ok. Robert, can you get the original panic on
> > > this
> > > thread tested against this patch?
> >
> > I had a small program which could reproduce this panic in 10 seconds, it
> > was basically creating empty threads and calling kvm_getprocs() in the
> same
> > time. Anyway the patch was able to stop the program from panicing.
> > The panic is also reproducible in RELENG_6 and HEAD IIRC.
>
> It turns out that the sysctl buffer is already wired in one of the two
> cases
> that this function is called, so I moved the wiring up to the upper layer
> in
> the other case and cut out a bunch of the locking gymnastics as a result.
> Can you try this patch?
>
> Index: kern_proc.c
> ===
> RCS file: /usr/cvs/src/sys/kern/kern_proc.c,v
> retrieving revision 1.231
> diff -u -r1.231 kern_proc.c
> --- kern_proc.c 27 Sep 2005 18:03:15 - 1.231
> +++ kern_proc.c 30 Sep 2005 17:04:57 -
> @@ -875,22 +875,16 @@
>
> if (flags & KERN_PROC_NOTHREADS) {
> fill_kinfo_proc(p, &kinfo_proc);
> - PROC_UNLOCK(p);
> error = SYSCTL_OUT(req, (caddr_t)&kinfo_proc,
> sizeof(kinfo_proc));
> - PROC_LOCK(p);
> } else {
> - _PHOLD(p);
> FOREACH_THREAD_IN_PROC(p, td) {
> fill_kinfo_thread(td, &kinfo_proc);
> - PROC_UNLOCK(p);
> error = SYSCTL_OUT(req, (caddr_t)&kinfo_proc,
> sizeof(kinfo_proc));
> - PROC_LOCK(p);
> if (error)
> break;
> }
> - _PRELE(p);
> }
> PROC_UNLOCK(p);
> if (error)
> @@ -932,6 +926,9 @@
> if (oid_number == KERN_PROC_PID) {
> if (namelen != 1)
> return (EINVAL);
> + error = sysctl_wire_old_buffer(req, 0);
> + if (error)
> + return (error);
> p = pfind((pid_t)name[0]);
> if (!p)
> return (ESRCH);
>
> --
> John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
> "Power Users Use the Power to Serve" = http://www.FreeBSD.org
>
Hi John,
I'm sorry I can't test it right now, I'm in a foreign country for three
months and can only connect to the internet through the university
connection.
I'll be back home mid-december. Maybe Rob should take care of testing it.
Regards,
Antoine Pelisse
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A smarter mergemaster
> Date: Thu, 29 Sep 2005 23:41:57 -0700 > From: Doug Barton <[EMAIL PROTECTED]> > Sender: [EMAIL PROTECTED] > > One of the design decisions that you need to be aware of for this project > since day one was to try and balance intelligent behavior and configuration > options that would be useful for the very small percentage of the FreeBSD > user community that constitutes our developers, versus the needs of the vast > majority of "regular" users who need to be able to use the tool without > becoming experts in either our build system, or the tool itself. That is why > every single default for mergemaster is to do nothing. It was a purposeful > decision to require the user to examine change requests, and make an > affirmative choice to approve them. Doug, You just hit on one of my pet peeves with mergemaster! Contrary to what you say: "every single default for mergemaster is to do nothing", when a file is found in /etc/rc.d that is not in /usr/src/etc/rc.d, the default is to delete the file in etc. I think that this is a bad thing(tm). I have to restore my profile.sh (which MUST be in /etc/rc.d as it needs to be run before /usr is mounted). I do have an open PR on this (conf/85449), but it does not seem to have gone anywhere other than being assigned to you last Friday. (No, I didn't expect anything to happen this quickly. You just gave me such a perfect opportunity to gripe!) By the way, having run FreeBSD before mergemaster, it's a huge improvement on those ugly days. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: serial login to SBC
>From: "M. Warner Losh" <[EMAIL PROTECTED]> >In message: <[EMAIL PROTECTED]> >Brian Reichert <[EMAIL PROTECTED]> writes: >: On Fri, Sep 30, 2005 at 05:14:01PM +0200, [EMAIL PROTECTED] wrote: >: > >: > Hello list, >: > I am trying to use a FreeBSD box to log into a Single Board Computer. I >: > have a null modem and it's plugged to both serial >: > ports. The SBC runs openbsd ( /dev/cua00). >: > When I run "cu -l /dev/cuaa0" from FreeBSD, I don't get any login >: > prompt. >: >: Do you have getty running on that port on the SBC? > >Do you have all the modem pins connected for this cable? Also, is the cable pin-out correct even for the Rx and Tx pins? There are weird recombinations of male-female and DCE-DTE pin-out used by different manufacturers. The easiest way to check is to get a port tester (a pass-through BOX with LEDs) from some place like Radioshack. The correct Unix cable connection is Tx - Rx DTR - DSR, CD CTS - RTS (and the other side symmetric). Many cable manufacturers use different (wrong) connections. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: serial login to SBC
Reference: > From: <[EMAIL PROTECTED]> > Date: Fri, 30 Sep 2005 17:14:01 +0200 > Message-id: <[EMAIL PROTECTED]> [EMAIL PROTECTED] wrote: > > Hello list, > I am trying to use a FreeBSD box to log into a Single Board Computer. I > have a null modem and it's plugged to both serial > ports. The SBC runs openbsd ( /dev/cua00). > When I run "cu -l /dev/cuaa0" from FreeBSD, I don't get any login > prompt. > > What I am doing wrong? Use a break out box, look at the LEDs, see if all the CTS RTS DTR DCE tedious stuff is set right. > > I've already read the FBSD handbook. > I have an OpenBSD box to experiment with first, and can't serial login > either. > I really need help on this one. -- Julian Stacey. Consultant Unix Net & Sys. Eng., Munich. http://berklix.com Mail Ascii not HTML. Ihr Rauch = meine allergischen Kopfschmerzen. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
