Re: about thumper aka sun fire x4500
On Tue, Jan 17, 2012 at 03:12:19PM -0800, Chuck Swiger wrote: > On Jan 17, 2012, at 2:09 PM, Jeremy Chadwick wrote: > > I do not have one of these boxes / am not familiar with them, but > > HyperTransport is an AMD thing. The concept is that it's a bus that > > interconnects different pieces of a system to the CPU (and thus the > > memory bus). > > While that was a nice picture, it's not related to the bus > architecture of a Sun 4500. :-) > > An X or E 4500 is a highly fault-tolerant parallel minicomputer with 8 > slots-- one was I/O, and you could put up to 7 CPU boards with dual > UltraSPARC processors-- you could hot-plug CPU boards and memory in > the event of a failure and keep the rest of the system up. They cost > a significant fraction of a million dollars circa y2k. You're thinking E4500, which is as you describe. The X4500 is described here: http://en.wikipedia.org/wiki/Sun_Fire_X4500 Marcus ___ 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: SCHED_ULE should not be the default
On Wed, Dec 14, 2011 at 05:54:15PM +, Tom Evans wrote: > brought forward more complaints about interactivity in X (I've never > noticed this, and use a FreeBSD desktop daily). .. that was me, but I forgot to add that it almost never happens, and it can only be triggered when there are processes that want to take up 100% of the CPU running on the system along with X and friends. Don't want to spread FUD, I've been happily using FreeBSD on the desktop for a decade and ULE seems to work great. Marcus ___ 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: SCHED_ULE should not be the default
On Mon, Dec 12, 2011 at 04:29:14PM -0800, Doug Barton wrote: > On 12/12/2011 05:47, O. Hartmann wrote: > > Do we have any proof at hand for such cases where SCHED_ULE performs > > much better than SCHED_4BSD? > > I complained about poor interactive performance of ULE in a desktop > environment for years. I had numerous people try to help, including > Jeff, with various tunables, dtrace'ing, etc. The cause of the problem > was never found. The issues that I've seen with ULE on the desktop seem to be caused by X taking up a steady amount of CPU, and being demoted from being an "interactive" process. X then becomes the bottleneck for other processes that would otherwise be "interactive". Try 'renice -20 ' and see if that makes your problems go away. Marcus ___ 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: New ZFSv28 patchset for 8-STABLE
On Mon, Jan 10, 2011 at 06:30:39PM +0100, Attila Nagy wrote: > >why and we can't ask him now, I'm afraid. I just sent an e-mail to > > What happened to him? Oops, I was thinking of something else. http://valleywag.gawker.com/383763/freebsd-developer-kip-macy-arrested-for-tormenting-tenants Marcus ___ 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"
ZFS root pool backup and recovery
Hi, The process of creating a backup of the ZFS root pool on Solaris is simple and straightforward: http://docs.sun.com/app/docs/doc/819-5461/ghzwu?l=en&a=view So is restoring it on bare metal: http://docs.sun.com/app/docs/doc/819-5461/ghzur?a=view Has anybody done something similar on FreeBSD with ZFS root? What are the main differences? Thanks, Marcus ___ 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: dtrace problem?
On Sun, May 23, 2010 at 08:08:54PM +0200, Alexander Leidinger wrote: > On Fri, 21 May 2010 20:31:17 -0700 Marcus Reid > wrote: > > > On Fri, May 21, 2010 at 07:54:44PM -0700, Kevin Oberman wrote: > > > I believe WITH_CTF=1 would probably be placed in /etc/src.conf. > > > > Ah, right you are. That is, if world could be built with > > 'WITH_CTF=1'. That appears to be where my breakage was; you have to > > build kernel with it set but world without it. > > Correct. And additionally: you have to specify it at the command line. > Putting it into src.conf or into the kernel config only works on a > recent 9-current. Unfortunately, after rebuilding I'm having the problem described in PR 141452: http://www.freebsd.org/cgi/query-pr.cgi?pr=141452&cat= I haven't found a way around this yet. Marcus ___ 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: dtrace problem?
On Fri, May 21, 2010 at 07:54:44PM -0700, Kevin Oberman wrote: > > Date: Fri, 21 May 2010 18:48:17 -0700 > > From: Marcus Reid > > Sender: owner-freebsd-sta...@freebsd.org > > > > On Fri, May 21, 2010 at 09:22:17AM +0300, Nikolay Denev wrote: > > > On May 21, 2010, at 9:03 AM, Marcus Reid wrote: > > > > > > > Hi, > > > > > > > > Running a recent RELENG_8 (FreeBSD 8.1-PRERELEASE #0: Tue May 18 > > > > 23:37:37 > > > > PDT 2010), I'm having a problem using dtrace. For every .d file I > > > > attempt > > > > to compile, I get: > > > > > > > > dtrace: failed to compile script test.d: "/usr/lib/dtrace/psinfo.d", > > > > line 37: syntax error near "uid_t" > > > > > > > > This is my first attempt to use dtrace, so I can't be sure if it worked > > > > before. It happens with some scripts that can be assumed to be valid, > > > > so it's not just me. Is it broken for anyone else? > > > > > > > > Thanks, > > > > > > > > Marcus > > > > > > Hi, > > > > > > Have you rebuilt your kernel as described here : > > > http://wiki.freebsd.org/DTrace > > > > > > I was once getting "uid_t" errors when my kernel was not compiled with > > > "WITH_CTF" option. > > > > Yes, that would probably be it. The handbook is explicit about > > building with WITH_CTF=1, so I put it in make.conf. > > > > http://www.freebsd.org/doc/en/books/handbook/dtrace-enable.html > > > > Thanks, I'll rebuild without it. > > I believe WITH_CTF=1 would probably be placed in /etc/src.conf. Ah, right you are. That is, if world could be built with 'WITH_CTF=1'. That appears to be where my breakage was; you have to build kernel with it set but world without it. Marcus ___ 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: dtrace problem?
On Fri, May 21, 2010 at 09:22:17AM +0300, Nikolay Denev wrote: > On May 21, 2010, at 9:03 AM, Marcus Reid wrote: > > > Hi, > > > > Running a recent RELENG_8 (FreeBSD 8.1-PRERELEASE #0: Tue May 18 23:37:37 > > PDT 2010), I'm having a problem using dtrace. For every .d file I attempt > > to compile, I get: > > > > dtrace: failed to compile script test.d: "/usr/lib/dtrace/psinfo.d", line > > 37: syntax error near "uid_t" > > > > This is my first attempt to use dtrace, so I can't be sure if it worked > > before. It happens with some scripts that can be assumed to be valid, > > so it's not just me. Is it broken for anyone else? > > > > Thanks, > > > > Marcus > > Hi, > > Have you rebuilt your kernel as described here : > http://wiki.freebsd.org/DTrace > > I was once getting "uid_t" errors when my kernel was not compiled with > "WITH_CTF" option. Yes, that would probably be it. The handbook is explicit about building with WITH_CTF=1, so I put it in make.conf. http://www.freebsd.org/doc/en/books/handbook/dtrace-enable.html Thanks, I'll rebuild without it. Marcus > Regards, > Niki ___ 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"
dtrace problem?
Hi, Running a recent RELENG_8 (FreeBSD 8.1-PRERELEASE #0: Tue May 18 23:37:37 PDT 2010), I'm having a problem using dtrace. For every .d file I attempt to compile, I get: dtrace: failed to compile script test.d: "/usr/lib/dtrace/psinfo.d", line 37: syntax error near "uid_t" This is my first attempt to use dtrace, so I can't be sure if it worked before. It happens with some scripts that can be assumed to be valid, so it's not just me. Is it broken for anyone else? Thanks, Marcus ___ 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"
New devices appear in all devfs mounts
Hi, I have devfs mounted in a chroot jail, with just the basic device nodes visible: fstab:/dev/null /usr/data/home/scp/dev devfs rw 0 0 rc.conf: devfs_set_rulesets="/usr/data/home/scp/dev=devfsrules_hide_all /usr/data/home/scp/dev=devfsrules_unhide_basic" When a new device is created, such as when adding a new scsi device or having enough concurrent logins to instantiate new ttys, the new devices appear in both /dev and /usr/data/home/scp/dev, which is not the intent for the stripped-down chrooted dev dir. Is there a way to work around this? Thanks, Marcus ___ 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"
msync() differences between Linux and FreeBSD
Hi, I recently had a patch accepted to the ports collection that took out an msync() call that seriously detrimented performance for rrdtool updates. It seems that in FreeBSD, msync() waits for bits to be committed to disk even when MS_ASYNC is specified. Under Linux, there is not such a wait for msync(). First off, I don't know how frequently msync() is used, and whether changing its behavior would impact the performance of many things. It's possible that FreeBSD msync() behavior is more correct in some ways. From a message from Matt Dillon on this same list: It used to be that msync() only synced VM pages to the underlying file, making them consistent with read()'s and write()'s against the underlying file. Since FreeBSD uses a unified VM page cache this is always true. However, the Open Group specification now requires that the dirty pages actually be written out to the underlying media... i.e. issue real I/O. So msync() can't be a NOP if you go by the OpenGroup specification. Is there a spec that FreeBSD is adhering to that prevents msync() with MS_ASYNC from being a NOP, seeing as munmap() does the job? And does this really matter for the real-world performance of some apps? Thanks, Marcus ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of madvise / msync
On Thu, Jun 26, 2008 at 05:48:13PM -0700, Matthew Dillon wrote: > : 65074 python 0.06 CALL madvise(0x287c5000,0x70,_MADV_WILLNEED) > : 65074 python 0.027455 RET madvise 0 > : 65074 python 0.58 CALL madvise(0x287c5000,0x1c20,_MADV_WILLNEED) > : 65074 python 0.016904 RET madvise 0 > : 65074 python 0.000179 CALL madvise(0x287c6000,0x1950,_MADV_WILLNEED) > : 65074 python 0.008629 RET madvise 0 > : 65074 python 0.40 CALL madvise(0x287c8000,0x8,_MADV_WILLNEED) > : 65074 python 0.004173 RET madvise 0 > :... > : 65074 python 0.006084 CALL msync(0x287c5000,0x453b7618,MS_ASYNC) > : 65074 python 0.106284 RET msync 0 > :... > :As you can see, it's quite a bit faster. > : > :I know that msync is necessary under Linux but obsolete under FreeBSD, but > :it's still funny that it takes a tenth of a second to return even with > :MS_ASYNC specified. > : > :Also, why is it that the madvise() calls take so much longer when the > :program does a couple of its own madvise() calls? Was madvise() never > :intended to be run so frequently and is therefore a little slower than > :it could be? > : > :Here's the diff between the code for the first kdump above and the > :second one. > > Those times are way way too large, even with other running threads > in the system. madvise() should not take that long unless it is > being forced to wait on a busied page, and neither should msync(). > madvise() doesn't even do any I/O (or shouldn't anyhow). > > Try removing just the msync() but keep the madvise() calls and see > if the madvise() calls continue to take horrendous amounts of time. > Then try the vise-versa. Ok, first off, I'm noticing that of the 4 other files that this is doing the same operations on, sized 569, 940, 116 and 116mB, all of the msync() and madvise() calls are nice and fast. It's only with the 1161524760 byte file that msync is much, much slower. It's not linear -- it hits a wall somewhere between 940 and 1161 million bytes. With madvise() and without msync(), there are high numbers of faults, which matches the number of disk io operations. It goes through cycles, every once in a while stalling while about 60MB of data is dumped to disk at 20MB/s or so (buffers flushing?) At the beginning of each cycle it's fast, with 140 faults/s or so, and slows as the number of faults climbs to 180/s or so before stalling and flusing again. It never gets _really_ slow though. 36286 python 0.16 NAMI "rg2.rrd" 36286 python 0.25 RET open 7 36286 python 0.09 CALL fstat(0x7,0xbfbfe428) 36286 python 0.14 RET fstat 0 36286 python 0.10 CALL mmap(0,0x453b7618,PROT_READ|PROT_WRITE,MAP_SHARED,0x7,0,0) 36286 python 0.20 RET mmap 679235584/0x287c5000 36286 python 0.10 CALL madvise(0x287c5000,0x453b7618,_MADV_RANDOM) 36286 python 0.10 RET madvise 0 36286 python 0.09 CALL madvise(0x287c5000,0x70,_MADV_WILLNEED) 36286 python 0.67 RET madvise 0 36286 python 0.16 CALL madvise(0x287c5000,0x1c20,_MADV_WILLNEED) 36286 python 0.15 RET madvise 0 36286 python 0.19 CALL madvise(0x287c6000,0x1950,_MADV_WILLNEED) 36286 python 0.13 RET madvise 0 36286 python 0.10 CALL madvise(0x287c8000,0x8,_MADV_WILLNEED) 36286 python 0.10 RET madvise 0 36286 python 0.12 CALL gettimeofday(0xbfbfe554,0) 36286 python 0.10 RET gettimeofday 0 36286 python 0.14 CALL fcntl(0x7,,0xbfbfe478) 36286 python 0.21 RET fcntl 0 36286 python 0.040061 CALL munmap(0x287c5000,0x453b7618) 36286 python 0.000324 RET munmap 0 36286 python 0.16 CALL close(0x7) 36286 python 0.44 RET close 0 36286 python 0.000113 CALL __sysctl(0xbfbfe388,0x2,0xbfbfe394,0xbfbfe398,0,0) 36286 python 0.18 RET __sysctl 0 With msync() and without madvise(), things are very slow, and there are no faults, just writes. 61609 python 0.16 NAMI "rg2.rrd" 61609 python 0.24 RET open 7 61609 python 0.10 CALL fstat(0x7,0xbfbfe428) 61609 python 0.13 RET fstat 0 61609 python 0.10 CALL mmap(0,0x453b7618,PROT_READ|PROT_WRITE,MAP_SHARED,0x7,0,0) 61609 python 0.21 RET mmap 679235584/0x287c5000 61609 python 0.066603 CALL madvise(0x287c5000,0x1c20,_MADV_WILLNEED) 61609 python 0.57 RET madvise 0 61609 python 0.09 CALL madvise(0x287c6000,0x1950,_MADV_WILLNEED) 61609 python 0.10 RET madvise 0 61609 python 0.09 CALL madvise(0x287c8000,0x8,_MADV_WILLNEED) 61609 python 0.09 RET madvise 0 61609 python 0.10 CALL gettimeofday(0xbfbfe554,0) 61609 python 0.18 RET gettimeofday 0 61609 python 0.14 CALL fcntl(0x7,,0xbfbfe478) 61609 python 0.26 RET fcntl 0 61609 python 0.004044 CALL msync(0x287c5000,0x453b7618,MS_ASYNC
Performance of madvise / msync
Hi,
I'm using py-rrdtool 0.2.1 with rrdtool 1.3.0 under 7.0-STABLE, and
there's a couple of things about this new version of rrdtool that
hurt performance under FreeBSD, but apparently help on whatever they
tested on.
For every update, the database file is opened, mapped into memory,
madvise() is called, contents are modified, msync() is called, and
the file is unmapped and closed:
65074 python 0.09 CALL open(0x831a1b4,O_RDWR,0)
65074 python 0.13 NAMI "rg2.rrd"
65074 python 0.24 RET open 7
65074 python 0.07 CALL fstat(0x7,0xbfbfe428)
65074 python 0.11 RET fstat 0
65074 python 0.08 CALL
mmap(0,0x453b7618,PROT_READ|PROT_WRITE,MAP_SHARED,0x7,0,0)
65074 python 0.18 RET mmap 679235584/0x287c5000
65074 python 0.07 CALL madvise(0x287c5000,0x453b7618,_MADV_RANDOM)
65074 python 0.08 RET madvise 0
65074 python 0.06 CALL madvise(0x287c5000,0x70,_MADV_WILLNEED)
65074 python 0.027455 RET madvise 0
65074 python 0.58 CALL madvise(0x287c5000,0x1c20,_MADV_WILLNEED)
65074 python 0.016904 RET madvise 0
65074 python 0.000179 CALL madvise(0x287c6000,0x1950,_MADV_WILLNEED)
65074 python 0.008629 RET madvise 0
65074 python 0.40 CALL madvise(0x287c8000,0x8,_MADV_WILLNEED)
65074 python 0.004173 RET madvise 0
65074 python 0.48 CALL gettimeofday(0xbfbfe554,0)
65074 python 0.09 RET gettimeofday 0
65074 python 0.12 CALL fcntl(0x7,,0xbfbfe478)
65074 python 0.24 RET fcntl 0
65074 python 0.006084 CALL msync(0x287c5000,0x453b7618,MS_ASYNC)
65074 python 0.106284 RET msync 0
65074 python 0.000483 CALL munmap(0x287c5000,0x453b7618)
65074 python 0.000356 RET munmap 0
65074 python 0.12 CALL close(0x7)
65074 python 0.46 RET close 0
65074 python 0.000173 CALL
__sysctl(0xbfbfe388,0x2,0xbfbfe394,0xbfbfe398,0,0)
65074 python 0.16 RET __sysctl 0
Here's a similar update without the calls to madvise and msync:
96372 python 0.11 CALL open(0x831aa34,O_RDWR,0)
96372 python 0.16 NAMI "rg2.rrd"
96372 python 0.25 RET open 7
96372 python 0.09 CALL fstat(0x7,0xbfbfe428)
96372 python 0.14 RET fstat 0
96372 python 0.10 CALL
mmap(0,0x453b7618,PROT_READ|PROT_WRITE,MAP_SHARED,0x7,0,0)
96372 python 0.21 RET mmap 679235584/0x287c5000
96372 python 0.000101 CALL madvise(0x287c5000,0x1c20,_MADV_WILLNEED)
96372 python 0.13 RET madvise 0
96372 python 0.10 CALL madvise(0x287c6000,0x1950,_MADV_WILLNEED)
96372 python 0.10 RET madvise 0
96372 python 0.09 CALL madvise(0x287c8000,0x8,_MADV_WILLNEED)
96372 python 0.09 RET madvise 0
96372 python 0.10 CALL gettimeofday(0xbfbfe554,0)
96372 python 0.09 RET gettimeofday 0
96372 python 0.11 CALL fcntl(0x7,,0xbfbfe478)
96372 python 0.16 RET fcntl 0
96372 python 0.002024 CALL munmap(0x287c5000,0x453b7618)
96372 python 0.000366 RET munmap 0
96372 python 0.16 CALL close(0x7)
96372 python 0.46 RET close 0
96372 python 0.000108 CALL
__sysctl(0xbfbfe388,0x2,0xbfbfe394,0xbfbfe398,0,0)
96372 python 0.17 RET __sysctl 0
As you can see, it's quite a bit faster.
I know that msync is necessary under Linux but obsolete under FreeBSD, but
it's still funny that it takes a tenth of a second to return even with
MS_ASYNC specified.
Also, why is it that the madvise() calls take so much longer when the
program does a couple of its own madvise() calls? Was madvise() never
intended to be run so frequently and is therefore a little slower than
it could be?
Here's the diff between the code for the first kdump above and the
second one.
*** src/rrd_open.c.orig Tue Jun 10 23:12:55 2008
--- src/rrd_open.c Wed Jun 25 21:43:54 2008
***
*** 175,191
#endif
if (rdwr & RRD_CREAT)
goto out_done;
- #ifdef USE_MADVISE
- if (rdwr & RRD_COPY) {
- /* We will read everything in a moment (copying) */
- madvise(data, rrd_file->file_len, MADV_WILLNEED | MADV_SEQUENTIAL);
- } else {
- /* We do not need to read anything in for the moment */
- madvise(data, rrd_file->file_len, MADV_RANDOM);
- /* the stat_head will be needed soonish, so hint accordingly */
- madvise(data, sizeof(stat_head_t), MADV_WILLNEED | MADV_RANDOM);
- }
- #endif
__rrd_read(rrd->stat_head, stat_head_t,
1);
--- 175,180
***
*** 388,396
int ret;
#ifdef HAVE_MMAP
- ret = msync(rrd_file->file_start, rrd_file->file_len, MS_ASYNC);
- if (ret != 0)
- rrd_set_error("msync rrd_file: %s", rrd_strerror(errno));
ret = munmap(rrd_file->file_start, rrd_file->file_len);
if (ret != 0)
rrd_set_error("munmap rrd_file: %s", rrd_strerror(errno
Re: RELENG_7 jerky mouse and skipping sound (still a problem -BETA3)
On Sun, Dec 30, 2007 at 03:30:40PM -0800, David E. Thiel wrote: > I've tried a lot of stuff in between, and all I've been able to narrow > it down to is that it's not a display driver issue, and that none of > my swap partition is getting used, so that's not the problem. During > compiles, my UP system with ULE still gets very unresponsive when > compiling, sometimes taking up to 10 seconds just to draw a new terminal > window. Even changing focus with the window manager can take several > seconds. I'd like to provide more info, but I'm not sure what stats > are useful for this particular issue. Please let me know. I get the same type of thing, and have brought it up on the lists at some point in the past. Basically, if the x server process consumes enough CPU that it is not regarded by ULE to be an "interactive" process anymore, then it doesn't fair very well against other processes that are contending for CPU. I use Windowmaker, which normally treads pretty lightly, but I can imagine that the problem would be much easier to trigger on some other window managers. I can easily trigger it by starting xlockmore with a pretty busy screenhack with a compile running in the background. Marcus ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: strange NFS failure
On Wed, Jun 08, 2005 at 09:00:38AM -0400, Robin P. Blanchard wrote: > > > just upgraded two systems to RELENG_5 this evening and NFS > > client has collapsed. is this known issue? apologies -- i > > realise i should really be tracking stable list. > > > > the error is > > > > [udp] 10.12.12.66:/usr/cabinet: RPCPROG_NFS: RPC: Port > > mapper failure - > > RPC: Unable to recieve > > > > and yes rpcbind is running OK. rpcinfo of the system > > produces normal output. > > > > thanks for any pointers. > > Sounds related to: > http://lists.freebsd.org/mailman/htdig/freebsd-stable/2005-June/015726.html > > Using "broken" kernel also yields "broken" nfs... I'm having this problem as well, and the culprit last time was sys/kern/uipc_socket.c which has been recently changed. mount_nfs closes the socket before the server can send a packet back. Hope this kdump output helps track it down. Marcus 1380 mount_nfs 0.041369 CALL socket(0x2,0x2,0x11) 1380 mount_nfs 0.041389 RET socket 4 1380 mount_nfs 0.041417 CALL getsockname(0x4,0xbfbfe2f0,0xbfbfe2ec) 1380 mount_nfs 0.041425 RET getsockname 0 1380 mount_nfs 0.041449 CALL getsockopt(0x4,0x,0x1008,0xbfbfe2e8,0xbfbfe2ec) 1380 mount_nfs 0.041455 RET getsockopt 0 1380 mount_nfs 0.041481 CALL getsockname(0x4,0xbfbfe2d0,0xbfbfe2cc) 1380 mount_nfs 0.041486 RET getsockname 0 1380 mount_nfs 0.041506 CALL getsockopt(0x4,0,0x13,0xbfbfe2c4,0xbfbfe2c8) 1380 mount_nfs 0.041510 RET getsockopt 0 1380 mount_nfs 0.041532 CALL setsockopt(0x4,0,0x13,0xbfbfe2c0,0x4) 1380 mount_nfs 0.041537 RET setsockopt 0 1380 mount_nfs 0.041558 CALL bind(0x4,0xbfbfe2d0,0x10) 1380 mount_nfs 0.041572 RET bind 0 1380 mount_nfs 0.041609 CALL getrlimit(0x8,0xbfbfe2c0) 1380 mount_nfs 0.041613 RET getrlimit 0 1380 mount_nfs 0.041806 CALL getsockname(0x4,0xbfbfe240,0xbfbfe23c) 1380 mount_nfs 0.041812 RET getsockname 0 1380 mount_nfs 0.041833 CALL getsockopt(0x4,0x,0x1008,0xbfbfe238,0xbfbfe23c) 1380 mount_nfs 0.041837 RET getsockopt 0 1380 mount_nfs 0.041914 CALL gettimeofday(0xbfbfe308,0) 1380 mount_nfs 0.041918 RET gettimeofday 0 1380 mount_nfs 0.041939 CALL getpid 1380 mount_nfs 0.041942 RET getpid 1380/0x564 1380 mount_nfs 0.042007 CALL ioctl(0x4,FIONBIO,0xbfbfe304) 1380 mount_nfs 0.042016 RET ioctl 0 1380 mount_nfs 0.042108 CALL gettimeofday(0xbfbfe440,0) 1380 mount_nfs 0.042112 RET gettimeofday 0 1380 mount_nfs 0.042132 CALL kqueue 1380 mount_nfs 0.042142 RET kqueue 5 1380 mount_nfs 0.042166 CALL sendto(0x4,0x805f354,0x38,0,0x805d008,0x10) 1380 mount_nfs 0.042284 GIO fd 4 wrote 56 bytes 0x 42a1 77fc 0002 0001 86a0 |B.w.| 0x0010 0002 0003 || 0x0020 0001 86a3 0003 || 0x0030 0011 || 1380 mount_nfs 0.042286 RET sendto 56/0x38 1380 mount_nfs 0.042317 CALL kevent(0x5,0x805d0dc,0x1,0xbfbfe470,0x1,0xbfbfe418) 1380 mount_nfs 0.042339 RET kevent 1 1380 mount_nfs 0.042359 CALL close(0x5) 1380 mount_nfs 0.042372 RET close 0 1380 mount_nfs 0.042398 CALL close(0x4) 1380 mount_nfs 0.042418 RET close 0 1380 mount_nfs 0.042499 CALL write(0x2,0xbfbfe010,0x53) 1380 mount_nfs 0.042537 GIO fd 2 wrote 83 bytes "[udp] ops:/usr/src: RPCPROG_NFS: RPC: Port mapper failure - RPC: Unabl\ e to receive " ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
