Hi,
every few days or so, my -STABLE NFS server (v3 and v4) gets wedged with a ton
of messages about "nfsd server cache flooded, try to increase nfsrc_floodlevel"
in the log, and nfsstat shows TCPPeak at 16385. It requires a reboot to
unwedge, restarting the server does not help.
The clients a
On Aug 5, 2013, at 11:20 AM, Adrian Chadd wrote:
> .. and I bet it's not a design pattern, and this is total conjecture on my
> part:
>
> * the original drivers weren't SMP safe;
> * noone really sat down and figured out how to correctly synchronise
> all of this stuff;
> * people did the minim
On Aug 6, 2013, at 9:43 AM, Andre Oppermann wrote:
> The driver supplies a TX frame transmit function (mostly like if_transmit
> today) which does all locking and multi-queue handling internally (driver
> owned. This gives driver writers the freedom to better adjust to different
> hardware commu
On Aug 6, 2013, at 9:43 AM, Andre Oppermann wrote:
> The driver supplies a TX frame transmit function (mostly like if_transmit
> today) which does all locking and multi-queue handling internally (driver
> owned. This gives driver writers the freedom to better adjust to different
> hardware commu
On Wed, Aug 7, 2013 at 11:04 AM, Harald Schmalzbauer <
h.schmalzba...@omnilan.de> wrote:
> Bezüglich Attilio Rao's Nachricht vom 14.10.2012 02:27 (localtime):
> > On Fri, Sep 21, 2012 at 1:22 AM, Attilio Rao
> wrote:
> >> On Wed, Sep 19, 2012 at 3:48 AM, Attilio Rao
> wrote:
> >>> On Fri, Jul 1
On 07.08.2013 09:18, Luigi Rizzo wrote:
On Wed, Aug 7, 2013 at 5:26 AM, Mike Karels mailto:m...@karels.net>> wrote:
Jumping to (near) the end of the thread, I like most of Andre's proposal.
Running with minimal locks at this layer is an admirable goal, and I agree
with most of what wa
Thanks, Bapt, for answering.
Am 07.08.2013 19:43, schrieb Baptiste Daroussin:
> On Wed, Aug 07, 2013 at 07:28:41PM +0200, Rainer Hurling wrote:
>> After introducing r253839 on HEAD (/head/contrib/binutils/ld/ldmain.c),
>> I recognized some wired behaviour in the ports system on my CURRENT boxes.
>
Bezüglich Attilio Rao's Nachricht vom 14.10.2012 02:27 (localtime):
> On Fri, Sep 21, 2012 at 1:22 AM, Attilio Rao wrote:
>> On Wed, Sep 19, 2012 at 3:48 AM, Attilio Rao wrote:
>>> On Fri, Jul 13, 2012 at 12:18 AM, Attilio Rao wrote:
2012/7/4 Attilio Rao :
> 2012/6/29 Attilio Rao :
>>>
On Wed, Aug 07, 2013 at 07:28:41PM +0200, Rainer Hurling wrote:
> After introducing r253839 on HEAD (/head/contrib/binutils/ld/ldmain.c),
> I recognized some wired behaviour in the ports system on my CURRENT boxes.
>
> Some of the ports do not build anymore. They print almost similar
> messages ab
After introducing r253839 on HEAD (/head/contrib/binutils/ld/ldmain.c),
I recognized some wired behaviour in the ports system on my CURRENT boxes.
Some of the ports do not build anymore. They print almost similar
messages about an ld problem (invalid DSO for symbol 'xxx' definition),
followed by t
On Aug 7, 2013, at 15:40, Robert Huff wrote:
> Boris Samorodov writes:
...
>> Are there some non-default configure/environment values?
>
> Not as far as I know. There is no src.conf; make.conf is appended.
>
>
> Robert Huff
>
>
>
> CFLAGS= -
On 07.08.2013 15:48, Jean-Sébastien Pédron wrote:
> On 07.08.2013 06:03, Rui Paulo wrote:
>> -*status = ifmr.ifm_status & IFM_ACTIVE;
>> +*status = ifmr.ifm_status & (IFM_ACTIVE|IFM_AVALID);
>
> The timing problem is back with this change. I guess because IFM_AVALID
> is set but not IFM_AC
- Original Message -
> it'd be nice if we could get vmware to just support the drivers in tree..
> by which I mean, just submit patches.. why do they need to have it out
> of tree?
>
I agree. But they are all unfriendly licensed. The FF had a discussion
to get them relicensed to somethi
Boris Samorodov writes:
> While at the first e-mail last log line was:
> >> sh /usr/src/tools/install.sh -o root -g wheel -m 555 make \
> >> /usr/obj/usr/src/make.amd64/make
>
> Are there some non-default configure/environment values?
Not as far as I know. There is no src.conf;
07.08.2013 16:14, Robert Huff пишет:
>
> Boris Samorodov writes:
>
>> > sh /usr/src/tools/install.sh -o root -g wheel -m 555 make
>> /usr/obj/usr/src/make.amd64/bmake
>> > cd /usr/src; PATH=/sbin:/bin:/usr/sbin:/usr/bin `test -x
>> /usr/obj/usr/src/make.amd64/bmake && echo /usr/obj/usr/src
Boris Samorodov writes:
> > sh /usr/src/tools/install.sh -o root -g wheel -m 555 make
> /usr/obj/usr/src/make.amd64/bmake
> > cd /usr/src; PATH=/sbin:/bin:/usr/sbin:/usr/bin `test -x
> /usr/obj/usr/src/make.amd64/bmake && echo /usr/obj/usr/src/make.amd64/bmake
> || echo make` -m /usr/src
07.08.2013 15:14, Dimitry Andric пишет:
> On Aug 7, 2013, at 12:31, Boris Samorodov wrote:
>> 06.08.2013 03:45, Robert Huff пишет:
> ...
>>> cd /usr/src; PATH=/sbin:/bin:/usr/sbin:/usr/bin `test -x
>>> /usr/obj/usr/src/make.amd64/bmake && echo /usr/obj/usr/src/make.amd64/bmake
>>> || echo make`
On Aug 7, 2013, at 12:31, Boris Samorodov wrote:
> 06.08.2013 03:45, Robert Huff пишет:
...
>> cd /usr/src; PATH=/sbin:/bin:/usr/sbin:/usr/bin `test -x
>> /usr/obj/usr/src/make.amd64/bmake && echo /usr/obj/usr/src/make.amd64/bmake
>> || echo make` -m /usr/src/share/mk -f Makefile.inc1 TARGET=am
06.08.2013 03:45, Robert Huff пишет:
>
> Boris Samorodov writes:
>
>> This note from /usr/src/UPDATING may be relevant:
>> -
>> 20130613:
>> Some people report the following error after the switch to bmake:
>>
>> make: illegal option -- J
>> usa
On Wed, Aug 7, 2013 at 5:26 AM, Mike Karels wrote:
> I'm replying to one of the last messages of this thread, but in part going
> back to the beginning; then I'm following up on Andre's proposal.
>
> Luigi wrote:
> > i am slightly unclear of what mechanisms we use to prevent races
> > between int
20 matches
Mail list logo
