On 9/22/2010 6:37 AM, John Baldwin wrote:
Unfortunately this can't be MFC'd to 7 as it would destroy the ABI for
existing klds.
Ah, ok, sorry, I did only check RELENG_7. Can we make it a kernel option
then?
Regards,
--
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
T/
Hi,
Is there any reason to keep MAXCPU at 16 in the default kernel config?
There are quite few servers on the market today that have 24 or even 32
physical cores. With hyper-threading this can even go as high as 48 or
64 virtual cpus. People who buy such hardware might get very
disappointed f
Maxim Sobolev wrote:
Maybe try adding
hint.atkbdc.0.disabled="1"
hint.atkbd.0.disabled="1"
to /boot/device.hints? That has reportedly removed minute-long boot
delays on some Nehalem machines.
No, that have not helped at all. I measured the delay - it's about 6
min
John Baldwin wrote:
On Tuesday 20 April 2010 8:30:42 am Maxim Sobolev wrote:
Update: I've discovered that the 7.3 kernels actually boot after some
ridiculously long waiting period after the "boot" command (i.e. 10
minutes or even more). I suspect that it might be caused by the
John Baldwin wrote:
On Tuesday 20 April 2010 8:30:42 am Maxim Sobolev wrote:
Update: I've discovered that the 7.3 kernels actually boot after some
ridiculously long waiting period after the "boot" command (i.e. 10
minutes or even more). I suspect that it might be caused by the
Update: I've discovered that the 7.3 kernels actually boot after some
ridiculously long waiting period after the "boot" command (i.e. 10
minutes or even more). I suspect that it might be caused by the memory
probing, which as far as I know the FreeBSD does to determine if the
physical memory th
Maxim Sobolev wrote:
the boot command, HEAD - filled in console with funny blinking characters.
...and hanged machine after that as well.
-Maxim
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
Hi,
For the first time in many years, I've stumbled across a server hardware
where FreeBSD kernel refuses to boot. It's FUJITSU PRIMERGY RX200 S5
server with 2x Quad core E5520 processors and 16GB of RAM. Linux boots
on that hardware just fine. Linux dmesg is available here:
http://sobomax.s
Jack Vogel wrote:
This thread is confusing, first he says its an igb problem, then you
offer an em patch :)
I suspect it could be patch for the kern/140326.
-Maxim
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo
Folks,
Indeed, it looks like igb(4) issue. Replacing the card with the
desktop-grade em(4)-supported card has fixed the problem for us. The
system has been happily pushing 110mbps worth of RTP traffic and 2000
concurrent calls without any problems for two days now.
e...@pci0:7:0:0: class=0x0
OK, here is some new data that I think rules out any issues with the
applications. Following Alfred's suggestion I have made a script to run
every second and output some system statistics:
date
netstat -m
vmstat -i
ps -axl
pstat -T
vmstat -z
sysctl -a
The problem had hit us again today several
Sergey Babkin wrote:
Maxim Sobolev wrote:
Hi,
Our company have a FreeBSD based product that consists of the numerous
interconnected processes and it does some high-PPS UDP processing
(30-50K PPS is not uncommon). We are seeing some strange periodic
failures under the load in several such
Hi,
Our company have a FreeBSD based product that consists of the numerous
interconnected processes and it does some high-PPS UDP processing
(30-50K PPS is not uncommon). We are seeing some strange periodic
failures under the load in several such systems, which usually evidences
itself in IPC
Jason Evans wrote:
Maxim Sobolev wrote:
Jason Evans wrote:
Maxim Sobolev wrote:
I am trying to figure out why java fails to start with 1024MB of
heap on i386 with 4GB of RAM and 4GB of swap. Both MAXDSIZ and
DFLDSIZ are set to 2GB.
Some memory (1GiB?) is reserved for kernel address space
Jason Evans wrote:
Maxim Sobolev wrote:
I am trying to figure out why java fails to start with 1024MB of heap
on i386 with 4GB of RAM and 4GB of swap. Both MAXDSIZ and DFLDSIZ are
set to 2GB.
Some memory (1GiB?) is reserved for kernel address space, and you
reserved 2GiB for DSS. That
Hi,
I am trying to figure out why java fails to start with 1024MB of heap on
i386 with 4GB of RAM and 4GB of swap. Both MAXDSIZ and DFLDSIZ are set
to 2GB. Here is my limits:
Resource limits (current):
cputime infinity secs
filesize infinity kB
datasize 2097152
Christoph Mallon wrote:
Roman Divacky schrieb:
I like the part about using as many variables as possible because
of documentation and performance enhancements. I tend to like
the other changes as well..
This is not about using as many variables as possible. The goal is to
use as many variable
Ivan Voras wrote:
Maxim Sobolev wrote:
The patch is available here:
http://sobomax.sippysoft.com/~sobomax/geom_mirror.diff. I would like to
get input on the functionality/code itself, as well on what is the best
way to add this functionality. Right now, it's part of the round-robin
bala
Robert Watson wrote:
Part of the point of mapping in the page at execve()-time, or
fork()-time for per-process pages (which I'm not entirely convinced we
need yet) is to avoid the cost of an extra device open, mmap, etc, for
every execve(), which can be quite expensive. I stuck a prototype pag
Peter Jeremy wrote:
On 2009-Mar-29 08:35:45 +0800, David Xu wrote:
Julian Elischer wrote:
interestingly it is even feasible to have a per-thread page..
it requires that the scheduler change a page table entry tough.
I will knock his door at midnight if he added such a heavy weight
task in the
Scott Long wrote:
I've been talking about this for years. All I need is help with the VM
magic to create the page on fork. I also want two pages, one global
for gettimeofday (and any other global data we can think of) and one
per-process for static data like getpid/getgid.
I believe somebody
Luigi Rizzo wrote:
On Mon, Dec 08, 2008 at 04:29:04PM -0800, Maxim Sobolev wrote:
Luigi Rizzo wrote:
...
4. another nitpick -- the value you pass in %si to the MBR does not
seem to point to anything useful. As discussed about boot0.S and
the followup in the mailing lists, there seems to
Luigi Rizzo wrote:
On Mon, Dec 08, 2008 at 02:40:41PM -0800, Maxim Sobolev wrote:
Hi,
Below please find patch that enhances cdboot with two compile-time options:
...
Any comments/suggestions are appreciated. If there are no objections I
would like to commit the change. The long-term goal is
Hi,
Below please find patch that enhances cdboot with two compile-time options:
1. CDBOOT_SILENT. When this option is set, the cdboot doesn't produce
any messages except "Loading, please wait..." and it also passes
RBX_MUTE flag to the next stage to silence it as well. This is intended
for cu
Hi,
Below please find patch that enhances cdboot with two compile-time options:
1. CDBOOT_SILENT. When this option is set, the cdboot doesn't produce
any messages except "Loading, please wait..." and it also passes
RBX_MUTE flag to the next stage to silence it as well. This is intended
for custo
Maxim Sobolev wrote:
Peter Jeremy wrote:
Is there a summary of the open issues somewhere? There are no sun4v
PRs open. http://wiki.freebsd.org/FreeBSD/sun4v effectively hasn't
been touched since November 2006 and suggests that the only critical
issue is lack of serial port support.
The
Peter Jeremy wrote:
Is there a summary of the open issues somewhere? There are no sun4v
PRs open. http://wiki.freebsd.org/FreeBSD/sun4v effectively hasn't
been touched since November 2006 and suggests that the only critical
issue is lack of serial port support.
There is a better interpretatio
Dag-Erling Smørgrav wrote:
Andrey Chernov <[EMAIL PROTECTED]> writes:
"BSD sort" as an idea will be a good project indeed, but "BSD sort"
implementation we currently have at hand is totally misleading and should
be rewritten from the scratch, I realize it when long time ago I try to
localize i
Hi,
Currently, FreeBSD by default disables hyper-threading "cores", by not
scheduling any threads to it. However, it still counts those cores as
"active but permanently idle" when calculating system-wide CPUs
statistics. It is incorrect, since it skews statistics quite a bit and
creates real
Dan Nelson wrote:
In the last episode (Aug 18), Jean-Michel Hiver said:
Kris Kennaway a écrit :
On Fri, Aug 18, 2006 at 10:37:43AM +0400, Jean-Michel Hiver wrote:
FreeBSD's SER port core dumps when I start it with 'fork=yes' in
the config file. The OS is freebsd 6.1, the platform is:
Typicall
Folks,
We experience a 100% reproducible panic on one of our machines during
shutdown+power off. We have found that it's caused by the interrupt
which happens in re(4) after re_shutdown() method has been called. Quick
googling reveals that we are not alone who experience this problem and
such
Hi,
I have found the scenario in which our libc behaves utterly
suboptimally. Consider the following piece of code reads and processes
every other 512-bytes block in a file (error handling intentionally
omitted):
FILE *f;
int i;
char buf[512];
f = fopen(...);
for (i = 0; feof(f) == 0; i++)
Roland Dowdeswell wrote:
[ cc'ing [EMAIL PROTECTED], because there has been talk
of GBDE there in the past.]
Well, I thought that since I saw this:
ALeine wrote a while ago:
[EMAIL PROTECTED] wrote:
Wouldn't be easier porting cgd* from NetBSD ?
* http://www.netbsd.org/guide/en/chap-cgd.html
Perha
Maxim Sobolev wrote:
Further investigation revealed that the said problem only happens when
the program is trying to re-connect() socket object which previously has
been connected to the unix domain socket closed on the server side at
the time when the second connect() is called. Attached
testcase.
-Maxim
Maxim Sobolev wrote:
Folks,
I've discovered very strange behaviour of the connect(2) system call
when it's called on already connected unix domain datagram socket. In
this case connect(2) fails with ECONNRESET, which is weird. ECONNRESET
is not even listed among possi
Folks,
I've discovered very strange behaviour of the connect(2) system call
when it's called on already connected unix domain datagram socket. In
this case connect(2) fails with ECONNRESET, which is weird. ECONNRESET
is not even listed among possible return values of connect(2). I've
confirmed
wrote:
On Thu, Dec 30, 2004 at 04:55:43PM +0200, Peter Pentchev wrote:
On Thu, Dec 30, 2004 at 04:20:16PM +0200, Maxim Sobolev wrote:
You don't check return code of the second lseek - I bet it fails. This
probably leads to creation of seemingly valid loop fs (i.e. with valid
header), but f
You don't check return code of the second lseek - I bet it fails. This
probably leads to creation of seemingly valid loop fs (i.e. with valid
header), but filled with zeroes or some random junk.
-Maxim
Peter Pentchev wrote:
On Thu, Dec 30, 2004 at 03:32:27PM +0200, Maxim Sobolev wrote:
Peter Pentchev wrote:
On Thu, Dec 30, 2004 at 01:28:28PM +0100, Matteo Riondato wrote:
Il giorno Gio, 30-12-2004 alle 12:34 +0200, Peter Pentchev ha scritto:
This could be fixed by the following patch. I'm CC'ing Maxim Sobolev,
the author of mkuzip(8); Maxim, do you have any objectio
On Sun, Nov 17, 2002 at 07:54:48PM -0500, Craig Rodrigues wrote:
> On Sun, Nov 17, 2002 at 11:16:54PM +0200, Maxim Sobolev wrote:
> > Hi there,
> >
> > I'm observing very strange memory corruption problems with 2GHz P4
> > system running 4.7 (security branch as of
Hi there,
I'm observing very strange memory corruption problems with 2GHz P4
system running 4.7 (security branch as of today). Under the load
(make -j20 buildworld) the compiler or make(1) often die with signal
11. I found in mailing lists that there is similarly looking problem
with -current, any
On Sun, Oct 27, 2002 at 01:24:19AM -0700, Juli Mallett wrote:
> * De: Maxim Sobolev <[EMAIL PROTECTED]> [ Data: 2002-10-27 ]
> [ Subjecte: Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC ]
> > On Sun, Oct 27, 2002 at 01:04:29AM -0700, Juli Mallett wrote:
> &g
On Sun, Oct 27, 2002 at 01:04:29AM -0700, Juli Mallett wrote:
> * De: Maxim Sobolev <[EMAIL PROTECTED]> [ Data: 2002-10-27 ]
> [ Subjecte: Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC ]
> > On Sat, Oct 26, 2002 at 06:09:31PM -0700, Nate Lawson wrote:
> &g
Folks,
Please review the patch, which adds two new types of events -
NOTE_STARTEXEC and NOTE_STOPEXEC, that could be used to get
notification when the image starts or stops executing. For example, it
could be used to monitor that a daemon is up and running and notify
administrator when for some re
On Fri, Oct 18, 2002 at 11:35:54AM -0700, Matthew Dillon wrote:
>
> :> :
> :> :There is a very easy way to trigger the problem: insert blank floppy
> :> :...
> :>
> :> Your patch looks slightly incomplete to me, but the concept is reasonable.
> :> The BIO_NORETRY test that sets B_INVAL sh
Matthew Dillon wrote:
>
> :Hi folks,
> :
> :I noticed that FreeBSD buf/bio subsystem has one very annoying problem
> :- once the write request is ejected into it, and write operation
> :failed, there seemingly no way valid to tell the layer to drop the
> :buffer. Instead, it retries the attempt ov
Hi folks,
I noticed that FreeBSD buf/bio subsystem has one very annoying problem
- once the write request is ejected into it, and write operation
failed, there seemingly no way valid to tell the layer to drop the
buffer. Instead, it retries the attempt over and over again, until
reboot, even thoug
n the situations where system open()
> blocks a whole calling process is blocked, where only a calling thread
> should actually be blocked. Necessary retries (similiar to read() and
> write()) should obviuosly be added too.
Andriy Gapon wrote:
>
> -- Forwarded message -
Terry Lambert wrote:
>
> [...]
> > > The assumption (which is potentially wrong) is that the program
> > > will correctly shut down all its threads, when in fact it was a
> > > module not under the programs control that created and used the
> > > threads.
> >
> > I do not quite agree. In such cas
Poul-Henning Kamp wrote:
>
> I've started to type in my mental sticky notes, have at it:
>
> http://people.freebsd.org/~phk/TODO/
Could you please modify reference to each of the tasks to be link to
the list of the relevant patches available so far, so that anybody who
wants to pick up
>
> On Fri, 16 Aug 2002, Maxim Sobolev wrote:
>
> MS>>
> MS>> On Fri, 16 Aug 2002, Maxim Sobolev wrote:
> MS>>
> MS>> MS>BTW, I've just realised that we can easily avoid breaking application
> MS>> MS>ABI by using currently
>
> On Fri, 16 Aug 2002, Maxim Sobolev wrote:
>
> MS>BTW, I've just realised that we can easily avoid breaking application
> MS>ABI by using currently unused ifr_ifru.ifru_flags[2] (aka. ifr_prevflags)
> MS>for storing another 16 flags. What do people think?
&g
int ifru_media;
> caddr_t ifru_data;
> int ifru_cap[2];
> } ifr_ifru;
> >
> > -Maxim
> >
> > >
> > > On Thu, 15 Aug 2002, Julian Elischer wrote:
> > >
> > > > you cannot br
>
> On Thu, 15 Aug 2002, Maxim Sobolev wrote:
>
> > When implementing ability to switch interface into promisc mode using
> > ifconfig(8) I've stumbled into the problem with already exhausted
> > space in the `short if_flags' field in the ifnet structure
) 5.1 or something.
> >
> >
> > On Thu, 15 Aug 2002, Maxim Sobolev wrote:
> >
> > > Folks,
> > >
> > > When implementing ability to switch interface into promisc mode using
> > > ifconfig(8) I've stumbled into the problem with already e
Folks,
When implementing ability to switch interface into promisc mode using
ifconfig(8) I've stumbled into the problem with already exhausted
space in the `short if_flags' field in the ifnet structure. I need to
allocate one new flag, while we already have 16 IFF_* flags, and even
one additional
Daniel Eischen wrote:
>
> On Mon, 12 Aug 2002, Maxim Sobolev wrote:
> > Folks,
> >
> > Attched please find two patches based on bin/29581 PR to make FreeBSD
> > resolver thread-safe. They represent two approaches to reach this goal
> > - the first is to
Terry Lambert wrote:
>
> Maxim Sobolev wrote:
> > > You may also want to consider the use of a .init and .fini
> > > section for the code, to permit the creation of an initial
> > > lookup context chunk; this is kind of a tradeoff, but it will
> > >
Daniel Eischen wrote:
>
> On Mon, 12 Aug 2002, Maxim Sobolev wrote:
> > Folks,
> >
> > Attched please find two patches based on bin/29581 PR to make FreeBSD
> > resolver thread-safe. They represent two approaches to reach this goal
> > - the first is to
Terry Lambert wrote:
>
> Maxim Sobolev wrote:
> > Attched please find two patches based on bin/29581 PR to make FreeBSD
> > resolver thread-safe. They represent two approaches to reach this goal
> > - the first is to introduce reentrant versions of the standard
> >
Folks,
Attched please find two patches based on bin/29581 PR to make FreeBSD
resolver thread-safe. They represent two approaches to reach this goal
- the first is to introduce reentrant versions of the standard
gethostbyXXX(3) APIs, similar to ones existing in other unices, and
the second one is
Folks,
I wonder if there is any co-operation between our KSE and similar
effort in NetBSD (see
http://web.mit.edu/nathanw/www/usenix/freenix-sa/freenix-sa.html). To
me it sounds logical to unite efforts if not for the kernel code, but
at least for the kernel interfaces and userland library.
-Max
strcmp(cp, ".bz2")))
+ || !strcmp(cp, ".bz2") || !strcmp(cp, ".split")))
return(ENOENT);
/* Construct new name */
Index: src/lib/libstand/splitfs.c
===
RCS file: src/lib/libstand/spli
Michael Smith wrote:
>
> > > > Please review attached patch, which adds long overdue feature to our
> > > > loader(8), allowing it to load sequence of files as a single object.
> > >
> > > I don't like this. I would much rather see support for 'split' files
> > > implemented as a stacking files
Michael Smith wrote:
>
> > Please review attached patch, which adds long overdue feature to our
> > loader(8), allowing it to load sequence of files as a single object.
>
> I don't like this. I would much rather see support for 'split' files
> implemented as a stacking filesystem layer like th
John Baldwin wrote:
>
> On 05-Mar-02 Maxim Sobolev wrote:
> > Hi folks,
> >
> > Please review attached patch, which adds long overdue feature to our
> > loader(8), allowing it to load sequence of files as a single object.
> > This should allow us to lift 1.44
file;
int err;
@@ -417,9 +428,9 @@
/*
* Get fully qualified KLD name
*/
-filename = file_search(kldname, kld_ext_list);
+filename = file_search(filesv[0], kld_ext_list);
if (filename == NULL) {
- sprintf(command_errbuf, "can't
"Andrey A. Chernov" wrote:
>
> On Mon, Feb 25, 2002 at 05:55:48 -0800, Maxim Sobolev wrote:
> > sobomax 2002/02/25 05:55:48 PST
> >
> > Modified files:
> > include grp.h
> > Log:
> > Backout rev.1.5 - it seems that
Terry Lambert wrote:
>
> Maxim Sobolev wrote:
> > But no library has it here! libc comes out of blue just before libc_r
> > - see attached script. Perhaps I'm missing something, but I can't
> > figure out where it comes from, could you?
>
> What does y
Terry Lambert wrote:
>
> Ruslan Ermilov wrote:
> > Sorry, but I don't get it. I can't reproduce it other than specifying
> > -lc explicitly. For example, -lssh now depends on -lcrypto and -lz, in
> > that order. Attempting to link a program with -lc_r -lssh gives, in
> > that order:
> >
> >
Will Andrews wrote:
>
> [ cc:-list from hell snipped ]
>
> On Fri, Feb 08, 2002 at 05:51:26PM +0200, Maxim Sobolev wrote:
> > But no library has it here! libc comes out of blue just before libc_r
> > - see attached script. Perhaps I'm missing something, but I can
Ruslan Ermilov wrote:
>
> On Fri, Feb 08, 2002 at 07:06:09AM -0800, Terry Lambert wrote:
> > Maxim Sobolev wrote:
> > > No, I meant ld(1). The problem here is that in the case when libc is
> > > recorded before libc_r in dynamic dependencies list the resulting
Ruslan Ermilov wrote:
>
> On Fri, Feb 08, 2002 at 12:48:34PM +0200, Maxim Sobolev wrote:
> > Terry Lambert wrote:
> > >
> > > Maxim Sobolev wrote:
> > > > That would be nice, but we have a real problem at hand. As I said, I
> > > > think th
Terry Lambert wrote:
>
> Maxim Sobolev wrote:
> [...]
> > > Symbols are resolved from libraries in the order in which
> > > they are specified to the linker.
> > >
> > > So the fix is obvious: specify them in the right order.
> [...]
> > All
Terry Lambert wrote:
>
> Maxim Sobolev wrote:
> > That would be nice, but we have a real problem at hand. As I said, I
> > think that ld(1) should be smart enough to reorder libc/libc_r so that
> > libc_r is always linked before libc. This is clearly not the case
>
Jason Evans wrote:
>
> On Fri, Feb 08, 2002 at 07:46:34AM +0200, Maxim Sobolev wrote:
> > Hi,
> >
> > When working on updating port of Ximian Evolution to the latest released
> > version I have stuck to the problem - the new version of application
> > just h
Stephen Montgomery-Smith wrote:
>
> "M. Warner Losh" wrote:
> >
> > Confirmed. test.c appears to work properly when compiled:
> >
> > cc -o test test.c -pthread
> > ./test
> >
> > Generally speaking, if you want to add -lc_r, you are doing things
> > incorrectly. I've done way to much building.
"M. Warner Losh" wrote:
>
> Confirmed. test.c appears to work properly when compiled:
>
> cc -o test test.c -pthread
> ./test
>
> Generally speaking, if you want to add -lc_r, you are doing things
> incorrectly. I've done way to much building... In FreeBSD 3.x you
> did need to do -lc_r, but
"M. Warner Losh" wrote:
>
> In message: <1013147180.73417.2.camel@notebook>
> Maxim Sobolev <[EMAIL PROTECTED]> writes:
> : Based on the problematic code in the ORBit I had prepared short testcase
> : illustrating the problem and attaching it wit
Terry Lambert wrote:
>
> Maxim Sobolev wrote:
> > $ cc test.c -o test -lc -lc_r
> >
> > When either of -lc or -lc_r is omitted, or their order is reversed the
> > problem disappears. The problem doesn't exist on 4-STABLE.
> >
> > Any ideas, comment
Hi,
When working on updating port of Ximian Evolution to the latest released
version I have stuck to the problem - the new version of application
just hanged on startup on my 5-CURRENT box. After lot of digging and
debugging I found that the source of the problem is that the resulting
application
Terry Lambert wrote:
>
> Greg Lehey wrote:
> > Since then, it has become possible for the loader to load modules
> > before booting the kernel. This means that, theoretically, it would
> > be possible to have a JFS root file system. Given the strong
> > opposition to the GPL in some factions of
"Jacques A. Vidrine" wrote:
>
> Hi,
>
> I decided to give Evolution a try. It seems that with large mail
> folder (via Maildir or IMAP), the mail component dies (signal 6). I
> notice the following:
>
> Dec 7 09:24:56 madman /kernel: sigreturn: eflags = 0x246
> Dec 7 09:24:56 madman /ke
Hiten Pandya wrote:
>
> hi all...
> i would like to know if possible what is PSEUDOFS...
> cause i forgot to update my kernel configuration file,
> regarding the message in the UPDATING section...
>
> i know what DEVFS is... after the lecture at the
> BSDCon
> 2001 Europe by phk
As far as I
On Thu, 15 Nov 2001 17:41:32 -0500 (EST), Daniel Eischen wrote:
> On Thu, 15 Nov 2001, Maxim Sobolev wrote:
> > On Thu, 15 Nov 2001 14:56:31 -0500 (EST), Joe Clarke wrote:
> > >
> > > I learned about this by reading through some of the -hackers archives.
> > &
On Thu, 15 Nov 2001 14:56:31 -0500 (EST), Joe Clarke wrote:
>
> I learned about this by reading through some of the -hackers archives.
> One person complained of similar errors trying to get xine to work on
> FreeBSD. Removing the MMX detection code fixed it. I remembered libpng
> also used MMX
> if (nevents > 0 || (eventlist[0].flags & EV_EOF) != 0) {
^^
OOPS, last minute bug. Should be `&&' instead, but it doesn't affect
outcome of the test.
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-ha
Hi,
I've noticed that kqueue(2) doesn't notify reader about EV_EOF
condition on pipe. Attached simple test program highlights
the problem (confirmed both on 5-CURRENT and 4-STABLE). Also
attached is the simple fix.
-Maxim
Index: sys/kern/sys_pipe.c
=
Peter Pentchev wrote:
>
> On Fri, Oct 26, 2001 at 06:06:59PM +0300, Maxim Sobolev wrote:
> > Peter Pentchev wrote:
> > >
> > > On Fri, Oct 26, 2001 at 05:49:08PM +0300, Maxim Sobolev wrote:
> [snip]
> > > >
> > > > On the step 3, when
Peter Pentchev wrote:
>
> On Fri, Oct 26, 2001 at 05:49:08PM +0300, Maxim Sobolev wrote:
> > Ian Dowse wrote:
> > >
> > > In message <[EMAIL PROTECTED]>, Maxim Sobolev writ
> > > es:
> > > > Nautilus from working properly. The problem di
Ian Dowse wrote:
>
> In message <[EMAIL PROTECTED]>, Maxim Sobolev writ
> es:
> > Nautilus from working properly. The problem disappeared when I've replaced
> > writev(2) call with appropriate loop based around ordinary write(2). Perhaps
> > this should
Adrian Chadd wrote:
> Hi all,
>
> Pardon the cross-posting. :-)
>
> I'd like to look at closing down / making inactive the squid22 and
> squid23 ports. The squid-2.2 and squid-2.3 codebases have been
> inactive and largely unsupported by the squid developers (read: myself
> inclusive here) for so
Chris Costello wrote:
> On Saturday, September 08, 2001, Maxim Sobolev wrote:
> > I don't like idea to hardcode the same string ("procfs"), with the
> > same meaning in several places across kernel. As for your proposition
> > to use f_fstypename to set
>
>
> apart from the numerical value, yes, looks good.
Ok, please find the final patch attached. Dare I say that it looks really
ugly?
I'm looking forward for your comments.
-Maxim
>
> Poul-Henning
>
> In message <[EMAIL PROTECTED]>, Maxim Sobolev wri
syncer work-list */
> #defineVMOUNT 0x40 /* Mount in progress */
> +#define VLOCKABLE 0x60 /* vnode supports locking */
> ...should be
> +#define VLOCKABLE 0x80 /* vnode supports locking */
Indeed. Thank you for pointing ou
> In message <[EMAIL PROTECTED]>, Maxim Sobolev writes:
> >>
> >> In message <[EMAIL PROTECTED]>, Brent Verner writes:
> >> >
> >> >I've done a /cursory/ look over how this v_tag is used. I'm not sure
> >> >this is
>
> In message <[EMAIL PROTECTED]>, Brent Verner writes:
> >On 04 Sep 2001 at 10:36 (+0200), Poul-Henning Kamp wrote:
> >|
> >| Assignment:
> >|
> >| The v_tag element in struct vnode is a debugging aid, but unfortunately
> >| it is implemented in a way which means that adding a filesystem mean
Konstantin Chuguev wrote:
> Hi,
>
> Ruslan Ermilov wrote:
>
> > The attached patch incorporates most of OpenBSD fixes to install(1).
> > It does not include manpage update. Most significant changes are:
> >
> > o New flag: -S (atomic install)
> >
> > : -SSafe copy. Normally, install unlinks
Please somebody take a look at attached patch that adds ``-h'' option
to the ln(1) command (obtained from NetBSD, which has it since 1997).
In addition, I've tried to minimise diffs between our code and
NetBSD's one, so there are several changes that at a first glance
look superfluous.
-Maxim
Hi,
I found it very frustrating that each time I need to change console
font (my native language has 3 different encodings, so I need to do it
regularly) I have to specify not only the font name, but fontsize as
well. I do not see any reasons why vidcontrol(8) can't guess correct
value from the f
1 - 100 of 106 matches
Mail list logo