Hello!
Currently, when a program built without OpenMP (-fopenmp) is trying to
dlopen a library, built with the feature, the result is a crash from
bad system call:
#0 0x0008009a223c in ksem_init () from /lib/libc.so.7
#1 0x000800998a8f in sem_init () from /lib/libc.so.7
#2
Sent by Kostik Belousov:
On Wed, Nov 12, 2008 at 01:09:22PM -0500, Mikhail Teterin wrote:
Hello!
Currently, when a program built without OpenMP (-fopenmp) is trying to
dlopen a library, built with the feature, the result is a crash from
bad system call:
#0 0x0008009a223c
Sent by Daniel Eischen:
On Wed, 12 Nov 2008, Mikhail Teterin wrote:
Sent by Kostik Belousov:
On Wed, Nov 12, 2008 at 01:09:22PM -0500, Mikhail Teterin wrote:
Hello!
Currently, when a program built without OpenMP (-fopenmp) is trying
to dlopen a library, built with the feature, the result
Sent by Daniel Eischen:
No, I simply meant that you saw it was returning bad system
call from sem_init/ksem_init.
Instead, I suspected, that it is the OpenMP, that's at fault. I'm sorry
for failing to live up to your expectations of a true FreeBSD user.
A little investigation would have turned
Hello!
I was trying to build OpenOffice using all of my 4 CPUs. To be able to
do other work on the machine comfortably, I ran the build under nice,
and assigned real-time priority to the two Xorg processes.
The build started at about 23:10 last night, and hung at 23:46. The
procstat output
Paul B. Mahol написав(ла):
Let me know, what else I can do to help fix this bug -- I'm going to
reboot the machine tonight... Should I switch to SCHED_ULE as a
work-around?
SCHED_BSD4 is suboptimal for 4 CPUs, and it is replaced with SCHED_ULE
on 7 STABLE.
Thanks, Paul for the
Josh Carroll написав(ла):
However, what I'm seeing on my system today is evidence of the scheduler
having a bug, rather than merely being suboptimal. If the old scheduler is
still maintained and supposed to work (however sub-optimally) in 4-CPU
configurations, I'd expect either inquiries for
Robert Watson написав(ла):
Could you try procstat -kk on the process, does that shed any light?
When I was trying `procstat -k', I was getting the message:
PIDTID COMM TDNAME
KSTACK
procstat: sysctl: kern.proc.kstack unavailable
Robert Watson написав(ла):
Sounds a lot like a lock leak/deadlock. Other than DDB output or a
crashdump, which would allow us to explore some more, there's probably
not much to be done with the box at this point other than reset.
Sorry about that.
Well, to reproduce you can try to build
Hello!
A machine I manage remotely for a friend comes under a distributed ssh
break-in attack every once in a while. Annoyed (and alarmed) by the
messages like:
Aug 12 10:21:17 symbion sshd[4333]: Invalid user mythtv from 85.234.158.180
Aug 12 10:21:18 symbion sshd[4335]: Invalid user mythtv
David Wolfskill написав(ла):
While the amount of work involved was assuredly greater in that case
than in yours, those of us who were actually building and running the
relays in question were very unsurprised when Postfix performance
improved significantly following a redesign of the
Neil Neely написав(ла):
I haven't explored this issue enough to speak with any authority - but
once upon a time I had an app doing tons of ipfw rule add/removes all
the time and we had no end of performance and stability problems on
that box (this would have been in 4.x or so timeline I
Jeremy Chadwick написав(ла):
The above looks like sshguard.
Yes, several people have pointed this out. Thanks!
I've personally never trusted something that *automatically* adjusts firewall
rules based on data read from text
logs or packets coming in off the Internet. The risks involved are
Ross Wheeler написав(ла):
I overcame these conflicting requirements with a 2-step process. They
authorised user first browsed to a website which asked their
username and password. When entered correctly, it opened a hole in the
firewall to allow that IP to their network. A timer ran every 15
John Baldwin написав(ла):
I think this case is still a lingering bug in the sleep queue code since the
thread lock stuff went in. There have been several reports of it but I have
been unable to figure out how the wakeup is being missed.
Is there anything I can still do for the
Hello!
My attempt to build openoffice.org-3 seems to be hanging. Pressing
Ctrl-T produces:
load: 0.11 cmd: tcsh 79759 [sleeping without queue] 0.00u 0.00s 0% 0k
(tcsh is used by OOo's build-script). What is this sleeping without
queue state, and why is process in it for so long?
This
Kris Kennaway написав(ла):
Mikhail Teterin wrote:
Hello!
My attempt to build openoffice.org-3 seems to be hanging. Pressing
Ctrl-T produces:
load: 0.11 cmd: tcsh 79759 [sleeping without queue] 0.00u 0.00s
0% 0k
(tcsh is used by OOo's build-script). What is this sleeping without
Jeremy Chadwick написав(ла):
On Tue, Jul 22, 2008 at 12:13:25PM -0400, Mikhail Teterin wrote:
Kris Kennaway написав(ла):
Mikhail Teterin wrote:
Hello!
My attempt to build openoffice.org-3 seems to be hanging. Pressing
Ctrl-T produces:
load: 0.11 cmd: tcsh 79759
Kris Kennaway написав(ла):
Well, I mean kernel backtrace.
Can I obtain that remotely and without restarting/panicking the box? Thanks,
-mi
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To
Kris Kennaway написав(ла):
Mikhail Teterin wrote:
Kris Kennaway написав(ла):
Well, I mean kernel backtrace.
Can I obtain that remotely and without restarting/panicking the box?
Thanks,
kgdb on /dev/mem or procstat
[EMAIL PROTECTED]:~ (107) kgdb /boot/kernel/kernel /dev/mem
Kostik Belousov написав(ла):
Did you switched to the process before doing backtrace (using the proc pid
command)?
Ok, thanks. Did not know about this one. Here:
...
(kgdb) proc 79759
(kgdb) bt
#0 sched_switch (td=0xff01286dc000, newtd=0xff00010ce000,
flags=2) at
Kostik Belousov написав(ла):
On Tue, Jul 22, 2008 at 03:26:29PM -0400, Mikhail Teterin wrote:
Kostik Belousov написав(ла):
Did you switched to the process before doing backtrace (using the proc
pid
command)?
Ok, thanks. Did not know about this one. Here:
...
(kgdb) proc 79759
(kgdb) bt
#0
Hello!
I had some troubles mounting the filesystem from:
da0 at umass-sim0 bus 0 target 0 lun 0
da0: MATSHITA DMC-FX12 0100 Removable Direct Access SCSI-2 device
da0: 1.000MB/s transfers
da0: 3886MB (7959552 512 byte sectors: 255H 63S/T 495C)
and decided to just
On понеділок 21 квітень 2008, Kostik Belousov wrote:
= Because the kernel has a bug ? As is, the report is useless. Please, do
= not hesitate to provide at least the backtrace.
The backtrace is attached. The filesystem is thus (newfs -N):
/store: 476940.0MB (976773168 sectors) block size 16384,
Hello!
I have a 7.0 system (amd64) and am trying to run a FreeBSD-4 executable.
It dies on startup with bad system call. The core shows, that it is
simply trying to mmap something.
I have the following COMPAT-options enabled in my kernel:
options COMPAT_43 # Needed by
вівторок 12 лютий 2008 11:41 по, Kip Macy Ви написали:
What workload, if any, was running at the time?
I was just swithed from one X11-session to another (Ctrl-Alt-F5) and clicked
on the KDE's button to start an xterm.
You would notice, that kdeinit is the current process in the dump.
The
Hello!
I bumped my RAM yesterday from 2Gb to 4Gb and ran memtest-x86
-- no errors detected (took 4+ hours).
I then booted and proceeded to use the machine. It seemed fine
for a while, until a sudden (there was nobody at the console at
the time) panic. Below.
The box runs FreeBSD 6.3-STABLE as
The machine is running 6.3-PRERELEASE as of Dec 30th. It just
paniced in the middle of web-session as I was browsing for a file to
upload via a web-form... The firefox in use is native (amd64), not a
Linux-binary.
The firefox process had over 550Mb of memory to its name -- it was
середа 23 січень 2008 09:20 до, John Baldwin Ви написали:
Is this something, that should be fixed in the 6.3? The kernel is
6.2-STABLE from June (see uptime).
What kind of CPU?
Dual Opteron. FreeBSD/amd64.
There was a fix for a certain edge condition in 6.x post 6.2, but usually
when I
середа 23 січень 2008 03:45 по, John Baldwin Ви написали:
In the controller? It is a newish ahd (although from eBay) -- what could
be wrong?
RAM.
Ouch... You mean, the main computer RAM or the controller's own memory?
The box itself is from a reputable workstation-maker and is otherwise
Hello!
Is this something, that should be fixed in the 6.3? The kernel is 6.2-STABLE
from June (see uptime).
Thanks!
-mi
Unread portion of the kernel message buffer:
TPTE at 0x8038 IS ZERO @ VA 7000
panic: bad pte
cpuid = 1
Uptime: 133d0h42m22s
Dumping 3583 MB (2
Attached is the stack...
I was trying to back up a DVD (acd0) to a file-system (on ad8). According to
the ``systat 1 -vm'' window frozen on my screen, the system was processing an
awful lot of interrupts, when it paniced.
I have the entire vmcore. Attached is the debugger's stack of it. The
On середа 26 грудень 2007, M. Warner Losh wrote:
= As a project we're not leveraging the community sufficiently when it
= comes to contributions. The current system of patch review and
= submission is very hap-hazard. If you happen to get the attention of
= the right person at the right time,
четвер 27 грудень 2007 10:52 до, M. Warner Losh Ви написали:
Usually that's called a maintainer, but we haven't had a real one in a
long time. Or even a fake one.
Well, you responded to me earlier suggesting, I take it upon myself to merge
USB-advancements from 7.x to 6.x. That implied,
четвер 27 грудень 2007 12:33 по, M. Warner Losh Ви написали:
I did the bulk of the work for the 7.0 stuff, at least getting things
into the tree. Since I did the work, my last job got totally insane
and then I switched jobs.
As the old Russian saying went: if vodka interferes with your job,
On субота 22 грудень 2007, Mike Tancsa wrote:
= Perhaps its the one card reader you are using is particularly
= problematic ? I have been using the multi-type cheapo reader below
= for some time
Perhaps. But /nothing/ excuses devfs hanging for 25 minutes. Nothing. It
should be more resilient
Another attempt to use USB-storage with FreeBSD, another moment of
hair-pulling frustration.
I attach the card-reader with the media card already inserted (detection of
card-insertion has not worked in a long time, if ever).
The disk appears:
umass1: Genesys USB Reader, rev
Has anyone had any luck using ImageMagick built with modules support?
If I try that, and follow-up with `gmake check' (in the ${WRKSRC}),
about a fifth of ImageMagick's own self-tests seg-fault -- all of
them inside __cxa_finalize (after main() has already returned):
[EMAIL
Sent something to the ulpt... Sudden crash.
Please, advise.
-mi
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol ps_pglobal_lookup]
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic
The patch in the PR allows our two Symbios 875 boards to work with
FreeBSD-6.2-recent.
However, the machine continues to suffer from the spin lock held to long
panics every few days. Usually, there is a double-panic, which prevents crash
dump from occuring. But this morning it succeeded.
The
On Wednesday 01 March 2006 11:07, Mikhail Teterin wrote:
= On Wednesday 01 March 2006, SЬren Schmidt wrote:
= = dd if=/dev/ad8 of=/dev/null bs=1m
=
= Well, as I said, there is no obvious problems with _reading_. The above
= command reads at well over 60Mb/s:
=
= 1638924288 bytes transferred
On Monday 26 March 2007 15:21, Søren Schmidt wrote:
= What HW was this again, there has been alot of updates/changes over the
= last year ?
It is now a quad core (dual CPU) Opteron-275 using IWill's DK8X motherboard.
http://www.google.com/search?q=iwill+dk8x
The SATA controller(s) are
On Monday 26 March 2007 17:35, Søren Schmidt wrote:
= Nopes its the stock AMD and a SiI chip..
Yes, that's correct. Sorry for the confusion.
= Anyhow there has been some changes in that area that actually might fix
= an interrupt routing bogon. Please try the attached patch against an up
= to
On Monday 26 March 2007 18:38, Mikhail Teterin wrote:
= I'm running a compressed dump now to see, if the data corruption is still
= here.
Yes, it is still here. Although the dump/compression finished cleanly, the
result is broken:
# gzip -t /store/home.0.gz
gzip: data stream
Hello!
I can reinit the ata0 (no devices) and ata1 (a single DVD drive) without any
problems -- they are both IDE (PATA).
Reinit-ing ata2 (with one SATA drive) hangs the machine solid. Most of the
time...
This one time, however, it paniced and dumped core instead of hanging. Here is
the
On Monday 05 March 2007 08:23, Yar Tikhiy wrote:
= How will it break them? swap backing only touches swap if there is
= memory pressure, i.e. precisely the situation in which malloc backing
= will panic.
=
= I forgot that in BSD swap wouldn't be allocated in advance to its
= consumers. Then
The memory-mounted /tmp filled up on this 6.2-PRERELEASE system (as of Nov 7).
Unfortunately, instead of the process existing due to ENOSPC, the entire
system paniced:
[...]
g_vfs_done():md0[WRITE(offset=982335488, length=131072)]error = 28
g_vfs_done():md0[WRITE(offset=982466560,
On Tuesday 27 February 2007 11:41, Alex Kozlov wrote:
= On Tue, Feb 27, 2007 at 10:59:08AM -0500, Mikhail Teterin wrote:
= /tmp's space allocation (after reboot) is as follows:
=
=Filesystem 1K-blocks Used Avail Capacity Mounted on
=/dev/md0 2026030 3552 1860396 0%/tmp
On Tuesday 27 February 2007 15:53, Alex Kozlov wrote:
= Yes, I switched to swap-backed md already. But the malloc-based variety is
= currently the _default_ (see /etc/defaults/rc.conf)...
= Bad default.
Filing a PR.
= Creation of a 2Gb malloc-based md should've failed on a machine with
=
On Tuesday 27 February 2007 16:09, Kris Kennaway wrote:
= Documented in the manpage, use swap backing or reserve enough space.
=
= Kris
The strings panic and -o reserve are mentioned in neither mdmfs(8) nor in
rc.conf(5)... Is one supposed to look elsewhere?
Worse, the use of malloc-based mds
Hello!
For several years we had some group-names spelled out in Cyrillics on the
server. That worked in 4.10 and seems to continue to work in 6.2. Except for
the following daily warnings, which we never saw in 4.x:
-- Forwarded Message --
Date: Fri, 2 Feb 2007 03:08:36 -0500
On Tuesday 31 October 2006 20:41, Jack Vogel wrote:
= I still think it looks like some kind of scheduler issue going on
= here, so maybe this is something to check.
Ok. First I tried to cvs the sys/dev/em back to 6.1 -- the new kernel
had the same problems...
Then I tried to change the 'PCI
On Tuesday 31 October 2006 20:41, Jack Vogel wrote:
= I still think it looks like some kind of scheduler issue going on
= here, so maybe this is something to check.
Why would the scheduler affect the sys component of the load (which
shoots to the sky before the machine drops of the network)? I
середа 01 листопад 2006 08:44, Steven Hartland написав:
Actually, it stalls even with polling disabled. It just takes A LOT
longer, as I just found out.
Instead of minutes, it takes hours of heavey traffict to stall, but
it still happens. Pressing a key still wakes it up...
Sounds like
вівторок 31 жовтень 2006 19:43, Jack Vogel написав:
This is fairly bizarre :) I think I can say pretty safely that this is NOT
an em driver issue, its a scheduler problem of some sort.
Am I the only one having problems with em driver? In its latest
6.x-incarnation?
Or is the enabled
понеділок 30 жовтень 2006 23:23, Mikhail Teterin написав:
Ok. I rebooted and restarted the heavy traffic dump (DEVICE_POLLING in
kernel, but without polling actialy enabled). The dump got underway,
although the amount of sys load was rather high -- way above 70%
most of the time (on a dual-CPU
вівторок 31 жовтень 2006 13:49, Jack Vogel написав:
Scott's question still hasnt been answered, or if so I dont understand it.
If everything was working why were you trying to turn on polling?
Because it was working poorly -- over 50% of the (combined) CPU time was spent
in the kernel (sys)
вівторок 31 жовтень 2006 14:14, Jeremy Chadwick написав:
On Tue, Oct 31, 2006 at 01:57:54PM -0500, Mikhail Teterin wrote:
Nothing -- the screen (console) is not updated. If I leave top(1)
running, I'll see INSANE amounts of CPU-time (1300% each, for example)
getting attributed
Actually, it stalls even with polling disabled. It just takes A LOT longer, as
I just found out.
Instead of minutes, it takes hours of heavey traffict to stall, but it still
happens. Pressing a key still wakes it up...
-mi
___
On Saturday 21 October 2006 13:33, Gleb Smirnoff wrote:
= We aren't currently speaking about performance, we need to know whether
= kernel with DEVICE_POLLING option makes NIC work stable.
Having noticed today's em-driver update, I rebuilt world/kernel and tried the
dump-test again.
The kernel
субота 21 жовтень 2006 13:33, Gleb Smirnoff написав:
We aren't currently speaking about performance, we need to know whether
kernel with DEVICE_POLLING option makes NIC work stable.
Yes, that seems to be the case... After I got to the machine's console
(there was no network access) and turning
понеділок 23 жовтень 2006 13:37, Mikhail Teterin написав:
We aren't currently speaking about performance, we need to know whether
kernel with DEVICE_POLLING option makes NIC work stable.
Yes, that seems to be the case...
I spoke too soon :-( It took a lot longer this time (without polling
Hello!
Looking at the http://www.freebsd.org/releases/6.2R/todo.html today, I was
surprised to not see the following problems in addition to the em(4) issue:
. devel/nspr's self test fails: the forktest executable complains
about a bug in pthread. Using libthr seems to work,
= I'd appreciate if people who are observing the problem will report
= whether adding DEVICE_POLLING option to kernel config helps them
= or not. This will help to tell whether the problem is in the above
= quote or in the import of new versions from vendor.
I tried this yesterday -- before
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29390
четвер 12 жовтень 2006 05:54, Kostik Belousov написав:
Thread model: posix
gcc version 3.4.6 [FreeBSD] 20060305
opt/gcc-3.4.6 is the stock version of the 3.4.6 built directly from the FSF
sources (relatively long time ago).
Well, if
GCC would not fix the bug described in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29390
because the compiler is of an unsupported version (they only support 4.x now).
Yet, the problem is rather real and hits when the devel/icu port is built with
low optimization (-O1 or -O0).
Any
неділя 24 вересень 2006 04:43, Hiroki Sato написав:
mi Could a committer with interest in -stable, please, see to it, that
mi Andrey's recent change to getopt_long makes it into 6.2-RELEASE?
mi
mi The change makes our implementation of getopt_long closer to GNULIB's
and will mi make it easier
Could someone with knowledge of compilers, please, look at the PR 103610?
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/103610
One of the source files, when compiled (with -O0 or -O1), grows a symbol, that
is not referenced anywhere else... Depending on the optimizations, the symbol
-- Переслане повідомлення --
Subject: Re: getopt_long and POSIXLY_CORRECT
Date: п'ятниця 22 вересень 2006 13:19
From: Andrey Chernov [EMAIL PROTECTED]
To: Mikhail Teterin [EMAIL PROTECTED]
Cc: bug-m4@gnu.org, bug-gnulib bug-gnulib@gnu.org,
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL
kmail prompted me for password, which I supplied. Then, all of a sudden,
the system slowed to a crawl -- even the mouse curse was barely moving.
It took many minutes to login from the outside and some more to start top.
Below you can see kmail in kserel keeping the processor(s) EXTREMELY busy.
п'ятниця 09 червень 2006 08:20, Alexander Leidinger написав:
This sounds like the /famous/ this software isn't branded correctly
bug. Please check that every binary executable, specially every static
one, is branded with brandelf to Linux.
Thanks for the pointer, I'll check the binaries.
Hello!
I installed the databases/sybase_ase port on the FreeBSD/amd64 system running
6.1-STABLE.
The install went fine, and trying to run the
su sybase
cd ${PREFIX}/sybase-ase
install/sybinit
progresses fine for some time, until the system resets :-( The last messages
On Tuesday 02 May 2006 02:22, Giorgos Keramidas wrote:
= cc can build binaries just fine if you also use the -B option:
=
= % cc -m32 -B/usr/lib32 ...
Yes, this is a work-around. It is not a solution... /usr/lib32 should be there
automatically.
= I know it does because I've used it on
On Tuesday 02 May 2006 05:59, Peter Jeremy wrote:
= But probably not as fast since it's using a generic 'C' core instead
= of a hand-tweaked assembler core. I read Mikhail's comment as meaning
= that it is possible to build non-trivial 32-bit executables on amd64,
= there's just work still needed
Can I direct someone's attention to the annoying but easy to fix bug:
http://www.freebsd.org/cgi/query-pr.cgi?pr=gnu/96570
There are still a few days left to make sure, FreeBSD-6.1 is shipped with
amd64 being able to link 32-bit executables.
Release Engineers insist, it must be fixed
понеділок 01 травень 2006 17:25, Paul Allen написав:
This was originally mentioned in amd64/76224 which was closed by obrien
with the terse remark: We don't yet support building 32-bit apps on a
64-bit system. We only barely support *running* them at this point.
I may be missing something
понеділок 01 травень 2006 18:55, Jonathan Noack написав:
Did you miss the previous reply which mentioned using '-B/usr/lib32
-B/usr/local/lib32' in addition to '-m32'?
I did not miss this work-around. But it is not a proper way -- one need not
specify -B/usr/lib in the 64-bit case. Nor should
понеділок 01 травень 2006 19:25, Sean Bryant написав:
The gcc's multilib.h functionality is just for that. [...]
Then why not work on adding the functionality? I'm sure freebsd people
would love to have a proper working 32 bit compatibility layer
happening.
Did you see the PR -- with the
[Moved to -stable]
On Sunday 16 April 2006 07:04, Søren Schmidt wrote:
= I just tried this on a system as close to the one you have as possible
You are welcome to visit my machine and take a look. Use the same ssh key as
for the FreeBSD cluster and connect to aldan.algebra.com.
= That
On Sunday 02 April 2006 04:42 pm, Søren Schmidt wrote:
= What freebsd version are we talking about here ? (dmesg would have been
= nice).
6.1 as of Sunday. dmesg.boot attached.
= Have you tried another cable ?
Not yet -- I was not there on weekend. I vaguely remember nVidia controllers
being
Hello!
We have an amd64 machine with an nVidia3 SATA controller on motherboard.
The drive just came from the manufacturer and the self-tests initiated
via smartctl show no problems:
atapci1: nVidia nForce3 Pro SATA150 controller port
вівторок 28 березень 2006 05:27, Peter Jeremy написав:
I'd suggest that each mmap be capable of storing several hundred msec of
data as a minumum (maybe 10MB input and 5MB output, preferably more).
Synchronisation can be done by writing tokens into pipes shared with the
mmap's, optimised by
On Saturday 25 March 2006 06:46 pm, Peter Jeremy wrote:
= My guess is that the read-ahead algorithms are working but aren't doing
= enough re-ahead to cope with read a bit, do some cpu-intensive processing
= and repeat at 25MB/sec so you're winding up with a degree of serialisation
= where the I/O
On Saturday 25 March 2006 05:39 am, Peter Jeremy wrote:
= On Fri, 2006-Mar-24 15:18:00 -0500, Mikhail Teterin wrote:
= which there is not with the read. Read also requires fairly large
= buffers in the user space to be efficient -- *in addition* to the
= buffers in the kernel.
=
= I disagree
Hi!
I updated world to today's 6.1 and my syslog is filling up with:
Mar 24 15:08:29 aldan sshd[2163]: login_getclass: unknown class 'root'
The /etc/login.conf did not change since November. I never had login.conf.db
-- it was always optional. Did that just change, or is something else broken
Matthew Dillon wrote:
It is possible that the kernel believes the VM system to be too loaded
to issue read-aheads, as a consequence of your blowing out of the system
caches.
See attachment for the snapshot of `systat 1 -vm' -- it stays like that for
the most of the compression run time
середа 22 березень 2006 15:20, Matthew Dillon Ви написали:
The only real solution is to make the NFS client aware of the
restricted user id exported by the server by requiring that the
same uid be specified in the mount command the client uses to
mount the NFS partition. The
вівторок 21 березень 2006 20:09, Matthew Dillon Ви написали:
'vmstat 1' while the program is running would tell us if VM faults
are creating an issue.
This problem -- vmstat and `systat -vm' occasionally stalling the entire
system -- did not go away, it just became less frequent and
вівторок 21 березень 2006 17:48, Matthew Dillon Ви написали:
Reading via mmap() is very well optimized.
Actually, I can not agree here -- quite the opposite seems true. When running
locally (no NFS involved) my compressor with the `-1' flag (fast, least
effective compression), the program
четвер 23 березень 2006 15:48, Matthew Dillon Ви написали:
Well, I don't know about FreeBSD, but both grep cases work just fine on
DragonFly.
Yes, they both do work fine, but time gives very different stats for each. In
my experiments, the total CPU time is noticably less with mmap,
середа 22 березень 2006 12:23, Matthew Dillon Ви написали:
My guess is that you are exporting the filesystem as a particular
user id that is not root (i.e. you do not have -maproot=root: in the
exports line on the server).
Yes, indeed, re-exporting with -maproot=0 leads to normal
середа 22 березень 2006 14:03, Matthew Dillon Ви написали:
I consider it a bug. I think the only way to reliably fix the problem
is to give the client the ability to specify the uid to issue RPCs with
in the NFS mount command, to match what the export does.
So, the problem is, the
[Moved from -current to -stable]
вівторок 21 березень 2006 16:23, Matthew Dillon Ви написали:
You might be doing just writes to the mmap()'d memory, but the system
doesn't know that.
Actually, it does. The program tells it, that I don't care to read, what's
currently there, by
When I mount with large read and write sizes:
mount_nfs -r 65536 -w 65536 -U -ointr pandora:/backup /backup
it changes -- for the worse. Short time into it -- the file stops growing
according to the `ls -sl' run on the NFS server (pandora) at exactly 3200
FS blocks (the FS was created
вівторок 21 березень 2006 17:48, Matthew Dillon Ви написали:
:Actually, it does. The program tells it, that I don't care to read, what's
:currently there, by specifying the PROT_READ flag only.
That's an architectural flag. Very few architectures actually support
write-only memory
вівторок 21 березень 2006 17:56, Matthew Dillon Ви написали:
For UDP mounts, 65536 is too large (the UDP data length can
only be 65536 bytes. For that matter, the *IP* packet itself can
not exceed 65535 bytes. So 65536 will not work with a UDP mount.
Well, then the mount should
вівторок 21 березень 2006 18:48, Patrick M. Hausen Ви написали:
On Tue, Mar 21, 2006 at 06:26:45PM -0500, Mikhail Teterin wrote:
The problem is about same with 32K and 16K packets. With 8K packets, the
thing kind-of works (although trying to `systat -vm' still stalls disk
access
вівторок 21 березень 2006 18:48, Patrick M. Hausen Ви написали:
Are you using TCP or UDP for your NFS mounts?
Ok, I just tried tcp as follows:
mount_nfs -r 8192 -w 8192 -U -otcp,intr,tcp pandora:/backup /backup
(oops, twice :-)
The symptoms are largely the same. The file stopped
вівторок 21 березень 2006 19:25, Matthew Dillon Ви написали:
If the program works over a local
filesystem but fails to produce data in the output file on an NFS
mount (but completes otherwise), then there is a bug in NFS somewhere.
If the problem is simply due to the program
вівторок 21 березень 2006 20:09, Matthew Dillon Ви написали:
If the network bandwidth is still going full bore then the program is
doing something. NFS retries would not account for it. A simple
test for that would be to ^Z the program once it gets into this state
and see if
1 - 100 of 135 matches
Mail list logo
