On Tue, 11 Nov 2003, cosmin wrote:
> I'm getting the following message when transfering data to a
> freebsd-current server via an nfs mount from another fbsd client.
>
> malloc() of "64" with the following non-sleepable locks held: exclusive
> sleep mutex inp r = 0 (0xc1d250ac) locked @
> /usr
I'm getting the following message when transfering data to a freebsd-current server
via an nfs mount from another fbsd client.
malloc() of "64" with the following non-sleepable locks held:
exclusive sleep mutex inp r = 0 (0xc1d250ac) locked @
/usr/src/sys/netinet/udp_usrreq.c:378
The message
S³awek ¯ak wrote:
> Now I guess it's Solaris specific. If you want some more details, let me know.
Wish you'd said "Solaris" first; but of course, we probably would
have told you "Go ask on the Solaris-current mailing list at
Solaris.org -- oops, sorry, Sun charges for support" 8-).
As someone el
Peter Edwards <[EMAIL PROTECTED]> writes:
> Hi,
>
>> > All the files are 0-sized, dates are set back to the epoch and
>> > directories are seen as files. Exporting ufs2 filesystems works as
>> > expected.
>
> I've had problems like this exporting CDs via NFS to solaris.
> Sorry the details are mur
Hi,
> > All the files are 0-sized, dates are set back to the epoch and
> > directories are seen as files. Exporting ufs2 filesystems works as
> > expected.
I've had problems like this exporting CDs via NFS to solaris.
Sorry the details are murky, but if its the same problem, there's a
work-aroun
Terry Lambert <[EMAIL PROTECTED]> writes:
>> I guess there is something wrong with exporting iso9660 CD's over NFS. I've added
>>
>> /cdrom -ro -mapall=root
>>
>> to /etc/exports, restarted mountd and after mounting the CD on Solaris 8. All the
>> files are 0-sized, dates are set back to the ep
S³awek ¯ak wrote:
> I guess there is something wrong with exporting iso9660 CD's over NFS. I've added
>
> /cdrom -ro -mapall=root
>
> to /etc/exports, restarted mountd and after mounting the CD on Solaris 8. All the
> files are 0-sized, dates are set back to the epoch and directories are seen a
I guess there is something wrong with exporting iso9660 CD's over NFS. I've added
/cdrom -ro -mapall=root
to /etc/exports, restarted mountd and after mounting the CD on Solaris 8. All the
files are 0-sized, dates are set back to the epoch and directories are seen as
files. Exporting ufs2 filesy
:Hmm, interesting. Do you have a 3C905B kicking around there somewhere
:that you could repeat the profiling run with? I must admit I hadn't had
:a chance to look at a profile dump using fxp, and this comes as a bit of
:a surprise.
I have two but they are both on slow machines (read: can'
> :That's interesting then, since your results are somewhat at odds with
> :what I've seen so far regarding interrupt load for network traffic. Do
> :you have any profiling results that point the finger more directly at
> :anything?
> :
> :--
>
> Ok, here is the kernel gprof output for o
>
> :< said:
> :
> :> the IP and UDP checksum guessing, but more that I think you'll find that
> :> a considerable amount of the inbound NFS traffic handling is actually
> :> performed in the interrupt context
> :
> :If it is, then there is a serious bug.
>
> No serious NFS traffic handlin
Kenneth D. Merry writes:
>
>
> Another advantage with gigabit ethernet is that if you can do jumbo frames,
> you can fit an entire 8K NFS packet in one frame.
>
> I'd like to see NFS numbers from two 21264 Alphas with GigE cards, zero
> copy, checksum offloading and a big striped array
:< said:
:
:> the IP and UDP checksum guessing, but more that I think you'll find that
:> a considerable amount of the inbound NFS traffic handling is actually
:> performed in the interrupt context
:
:If it is, then there is a serious bug.
:
:-GAWollman
:
:--
:Garrett A. Wollman | O Siem / We
...
> (200-300 MHz) clients. That's *with* packet loss (for some reason when
> my fxp ethernets pump data out that quickly they tend to cause packet
> loss in other parts of my HUBed network, which I find quite annoying).
Interesting you should say that I've been playing with so
< said:
> the IP and UDP checksum guessing, but more that I think you'll find that
> a considerable amount of the inbound NFS traffic handling is actually
> performed in the interrupt context
If it is, then there is a serious bug.
-GAWollman
--
Garrett A. Wollman | O Siem / We are all fami
On Wed, 15 Dec 1999, Matthew Dillon wrote:
> Here's a general update on this bug report to -current. It took all day
> but I was finally able to reproduce Andrew's bug.
>
> You guys are going to *love* this.
>
> NFS uses the kernel 'boottime' structure to generate its version i
>
> We've solved most of the performance issues, but NFS is still
> eating a little too much cpu for my tastes. Unfortunately it is getting to
> the point where a significant portion of the performance loss is occuring
> in the network driver itself. Some of my cards eat 25% of
On Thu, Dec 16, 1999 at 19:28:34 -0800, Matthew Dillon wrote:
> :Matthew Dillon writes:
> :
> : > We're already testing a patch.
> :
> :Thanks again Matt!
> :
> :The latest rev of nfs_serv.c has fixed it.
> :
> :I'm now seeing FreeBSD UDP client read bandwidth of 9.2MB/sec & write
> :bandwid
:Matthew Dillon writes:
:
: > We're already testing a patch.
:
:Thanks again Matt!
:
:The latest rev of nfs_serv.c has fixed it.
:
:I'm now seeing FreeBSD UDP client read bandwidth of 9.2MB/sec & write
:bandwidth of 10.9MB/sec. Solaris clients are writing over TCP at
:10.1MB/sec (and that
Matthew Dillon writes:
> We're already testing a patch.
Thanks again Matt!
The latest rev of nfs_serv.c has fixed it.
I'm now seeing FreeBSD UDP client read bandwidth of 9.2MB/sec & write
bandwidth of 10.9MB/sec. Solaris clients are writing over TCP at
10.1MB/sec (and that is across a
>
>
> On Thu, 16 Dec 1999, Warner Losh wrote:
>
> > In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
> > : If people do a "settimeofday" we change the boot time since the
> > : amount of time we've been up *IS* known for sure, whereas the boottime
> > : is only an estimate.
> >
> > Ther
+[ Warner Losh ]-
|
| There is one problem with this. The amount of uptime isn't the same
| as the amount of time since the machine booted. How can this happen?
| When a laptop suspends, it doesn't update the update while it is
| asleep, nor does i
On Thu, 16 Dec 1999, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Tom Bartol
>writes:
> : I tried 3.0-current after this merge, suspend and resume worked fine on my
> : 770 with the exception of uptime.
>
> I can confirm that uptime, at least as reported by uptime(1), isn't
> increased
In message <[EMAIL PROTECTED]> Tom Bartol
writes:
: I tried 3.0-current after this merge, suspend and resume worked fine on my
: 770 with the exception of uptime.
I can confirm that uptime, at least as reported by uptime(1), isn't
increased in the latest -current.
Warner
To Unsubscribe: send
On Thu, 16 Dec 1999, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Tom Bartol
>writes:
> : IIRC it does update uptime properly after a suspend in 2.2.8 but does not
> : do so in 3.X and -current on my ThinkPad 770.
>
> define correctly. Eg, if I suspend for an hour it adds an hour?
>
In message <[EMAIL PROTECTED]> Tom Bartol
writes:
: IIRC it does update uptime properly after a suspend in 2.2.8 but does not
: do so in 3.X and -current on my ThinkPad 770.
define correctly. Eg, if I suspend for an hour it adds an hour?
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
: Well, I don't think anybody has seriously thought about what the right
: semantics for APM is, and consequently the code we have is rather evil.
Don't know if I'd go so far as to say evil, but there are some pola
issues.
: What to do is
> : If people do a "settimeofday" we change the boot time since the
> : amount of time we've been up *IS* known for sure, whereas the boottime
> : is only an estimate.
>
> There is one problem with this. The amount of uptime isn't the same
> as the amount of time since the machine booted. How c
On Thu, 16 Dec 1999, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
> : If people do a "settimeofday" we change the boot time since the
> : amount of time we've been up *IS* known for sure, whereas the boottime
> : is only an estimate.
>
> There is one problem wi
In message <[EMAIL PROTECTED]>, Warner Losh writes:
>In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
>: If people do a "settimeofday" we change the boot time since the
>: amount of time we've been up *IS* known for sure, whereas the boottime
>: is only an estimate.
>
>There is one problem
In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
: If people do a "settimeofday" we change the boot time since the
: amount of time we've been up *IS* known for sure, whereas the boottime
: is only an estimate.
There is one problem with this. The amount of uptime isn't the same
as the am
:
:
:>Yeah, uptime is moving which makes it difficult for me too. When new
:>machines enter the network, they need to announce a number which is used to
:>decice who will become the master if the current master disappears. I could
:>just announce currenttime-uptime, but that's got a slightly diff
>Yeah, uptime is moving which makes it difficult for me too. When new
>machines enter the network, they need to announce a number which is used to
>decice who will become the master if the current master disappears. I could
>just announce currenttime-uptime, but that's got a slightly different
>m
>
> > In message <[EMAIL PROTECTED]>, Kevin Day writes:
> >
> > >Ack, I was using this very same thing for several devices in an isolated
> > >peer-to-peer network to decide who the 'master' was. (Whoever had been up
> > >longest knew more about the state of the network) Having this change could
Matt, you are a tenacious, fearsome bug hunter!
Matt
Matthew Dillon wrote:
>
> Here's a general update on this bug report to -current. It took all day
> but I was finally able to reproduce Andrew's bug.
>
> You guys are going to *love* this.
>
> NFS uses the kernel 'boottime'
In message <[EMAIL PROTECTED]>, Nate Williams writes:
>> In message <[EMAIL PROTECTED]>, Kevin Day writes:
>>
>> >Ack, I was using this very same thing for several devices in an isolated
>> >peer-to-peer network to decide who the 'master' was. (Whoever had been up
>> >longest knew more about the
Nate Williams wrote:
> > In message <[EMAIL PROTECTED]>, Kevin Day writes:
> >
> > >Ack, I was using this very same thing for several devices in an isolated
> > >peer-to-peer network to decide who the 'master' was. (Whoever had been up
> > >longest knew more about the state of the network) Having
> In message <[EMAIL PROTECTED]>, Kevin Day writes:
>
> >Ack, I was using this very same thing for several devices in an isolated
> >peer-to-peer network to decide who the 'master' was. (Whoever had been up
> >longest knew more about the state of the network) Having this change could
> >cause wei
Matthew Dillon writes:
>
> And so Andrews bug report comes into the light! His poor client
> (and mine once I reproduced the bug) got into a state, due to the
> server returning a different version id for virtually every packet,
> where it resent the same write data over t
In message <[EMAIL PROTECTED]>, Kevin Day writes:
>Ack, I was using this very same thing for several devices in an isolated
>peer-to-peer network to decide who the 'master' was. (Whoever had been up
>longest knew more about the state of the network) Having this change could
>cause weirdness for m
:
:>
:> In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
:> >
:> >:>NFS uses the kernel 'boottime' structure to generate its version id.
:> >:>Now normally you might believe that this structure, once set, will
:> >:>never change. The authors of NFS certainly make that assumpti
>
> In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
> >
> >:>NFS uses the kernel 'boottime' structure to generate its version id.
> >:>Now normally you might believe that this structure, once set, will
> >:>never change. The authors of NFS certainly make that assumption!
> >:
In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
>
>:>NFS uses the kernel 'boottime' structure to generate its version id.
>:>Now normally you might believe that this structure, once set, will
>:>never change. The authors of NFS certainly make that assumption!
>:
>:Is this anoth
:>NFS uses the kernel 'boottime' structure to generate its version id.
:>Now normally you might believe that this structure, once set, will
:>never change. The authors of NFS certainly make that assumption!
:
:Is this another case of "lets assume the time of day is a random number" o
In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
>Here's a general update on this bug report to -current. It took all day
>but I was finally able to reproduce Andrew's bug.
>
>You guys are going to *love* this.
>
>NFS uses the kernel 'boottime' structure to generate its vers
Here's a general update on this bug report to -current. It took all day
but I was finally able to reproduce Andrew's bug.
You guys are going to *love* this.
NFS uses the kernel 'boottime' structure to generate its version id.
Now normally you might believe that this structur
Matthew Dillon writes:
>
> :
> :
> :Matthew Dillon writes:
> : > This is very odd. Does it lockup with UDP or only with TCP? And only
> : > with a solaris client?
> :
> :This appears to be solaris only. I just tried a UDP mount & I see the
> :same problem. Is there anythin
Matthew Dillon writes:
>
> :Also, while read performance has improved by 44%, write performance
> :has degraded by between 50 - 70% (FreeBSD clients)! Here are some
> :quick benchmarks. Note that the file size of 512MB is larger than
> :memory on both the server and client. Also note tha
:Also, while read performance has improved by 44%, write performance
:has degraded by between 50 - 70% (FreeBSD clients)! Here are some
:quick benchmarks. Note that the file size of 512MB is larger than
:memory on both the server and client. Also note that the disk array
:on the server will re
:
:
:Matthew Dillon writes:
: > This is very odd. Does it lockup with UDP or only with TCP? And only
: > with a solaris client?
:
:This appears to be solaris only. I just tried a UDP mount & I see the
:same problem. Is there anything else I can do?
Yes, see if you can repeat th
Matthew Dillon writes:
> This is very odd. Does it lockup with UDP or only with TCP? And only
> with a solaris client?
This appears to be solaris only. I just tried a UDP mount & I see the
same problem. Is there anything else I can do?
<...>
> :
> :- UDP NFS write performance
:However, I'm seeing a showstopping problem when running newer kernels:
:When writing a large file via TCP, a Solaris 2.7 client pauses when
:closing the file, and appears to become stuck in an infinate loop.
:Eg:
:
:dd if=/dev/zero of=zot bs=64k count=8192
:8192+0 records in
:8192+0 records out
:
I have a few "scratch" servers which are running -current from early
July. They serve large, fast scratch filesystems striped over 4 large
IDE drives. With the recent improvements to the NFS code & the ATA
code, I was hoping to get them running a more recent -current.
However, I'm seeing a sh
I run a mailhub at 3.1
The problem is the /var/mail directory is NFS mounted
with HPUX 10.20 clients
there is a file locking problem due to the HPUX /bin/mail
command which try to create a user.lock file in the NFS mounted
/var/mail directory ...
Is there a NFS workaround or do I have to gi
On Tue, Jan 19, 1999 at 01:01:34PM +0200, Sheldon Hearn wrote:
[...]
> > But there's still something wrong: When shutting down the server
> > it still sometimes panics in vinvalbuf() complaining 'bout dirty
> > pages.
>
> I'm not sure this has anything to do with NFS. I got this after last
> night
This patch seems to fix my NFS problems. I started a make release yesterday
and it is still running (It's a slow machine). No problems so far.
The chroot dir is NFSv2/UDP mounted.
Thanks,
Daniel
Luoqi Chen schrieb:
>
> The check is correct and should be there, the B_CACHE bit was cleared becaus
On Tue, 19 Jan 1999 11:38:50 +0100, Bjoern Fischer wrote:
> But there's still something wrong: When shutting down the server
> it still sometimes panics in vinvalbuf() complaining 'bout dirty
> pages.
I'm not sure this has anything to do with NFS. I got this after last
night's fresh world and k
On Mon, Jan 18, 1999 at 10:05:50AM -0500, Luoqi Chen wrote:
> The check is correct and should be there, the B_CACHE bit was cleared because
> I made a mistake when setting the valid bit in the vm page.
[...]
> Note the calculation of ev, the original code was a round-up and I changed it
> to round-
A. Yes, I see. I will unapply my patch and apply this one and test
it.
I'm not sure what the use of having m->valid and m->clean bits are at all
if we have to munge them like this. Perhaps we should change these
vm_page_t to a byte range in -4.0.
I think we also nee
The check is correct and should be there, the B_CACHE bit was cleared because
I made a mistake when setting the valid bit in the vm page.
Index: vfs_bio.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_bio.c,v
retrieving revision 1.192
dif
Good work! I have to run at the moment but it looks like you nailed this
one. Your explanation coincides perfectly with the symptoms.
Thanks!
-Chris
On Mon, 18 Jan 1999, Matthew Dillon wrote:
> Ok, I believe I have found the bug. Please test the patch included below.
> I was able t
::On the server I downgraded vfs_bio.c to rev 1.187 & rebooted; no luck. I
::then installed the same kernel (with the downgraded vfs_bio.c) to the
::client. Bingo. With both NFS client & server machine running rev 1.187,
::...
::-Chris
:
:Hmm. r1.88 are Luoqi's fixes to the handling of misa
62 matches
Mail list logo
