s repost but I'm confused about the responses I
>>>>>>>>>> received
>>>>>>>>>> in my last post so I'm looking for some clarification.
>>>>>>>>>>
>>>>>>>>>> Specif
gt; >> > > > received
>> >> >> > > > in my last post so I'm looking for some clarification.
>> >> >> > > >
>> >> >> > > > Specifically, I though I could use the kqueue timer as
>> >> >> >
for some clarification.
> >> >> > > >
> >> >> > > > Specifically, I though I could use the kqueue timer as
> >> >> > > > essentially a
> >> >> > > > "drop in" replacement for lin
gt; > > >
> >> >> > > > Specifically, I though I could use the kqueue timer as
essentially a
> >> >> > > > "drop in" replacement for linuxfd_create/read, but was surprised
that
> >> >> > > > the accuracy
I could use the kqueue timer as essentially a
>> >> > > > "drop in" replacement for linuxfd_create/read, but was surprised
>> >> > > > that
>> >> > > > the accuracy of the kqueue timer is much less than what I need for
>> >&g
I could use the kqueue timer as essentially
> > >> > > > a
> > >> > > > "drop in" replacement for linuxfd_create/read, but was surprised
> > >> > > > that
> > >> > > > the accuracy o
ation.
> > > > >
> > > > > Specifically, I though I could use the kqueue timer as essentially a
> > > > > "drop in" replacement for linuxfd_create/read, but was surprised that
> > > > > the accuracy of the kqueue time
received
> >> > > > in my last post so I'm looking for some clarification.
> >> > > >
> >> > > > Specifically, I though I could use the kqueue timer as essentially a
> >> > > > "drop in" replacement for linuxfd_cr
t; received
> >> > > > in my last post so I'm looking for some clarification.
> >> > > >
> >> > > > Specifically, I though I could use the kqueue timer as essentially a
> >> > > > "drop in" replacement for linuxfd
; > > Specifically, I though I could use the kqueue timer as essentially a
>> > > > "drop in" replacement for linuxfd_create/read, but was surprised that
>> > > > the accuracy of the kqueue timer is much less than what I need for my
>> > >
t; > "drop in" replacement for linuxfd_create/read, but was surprised that
> > > > the accuracy of the kqueue timer is much less than what I need for my
> > > > application.
> > > >
> > > > So my confusion at this point is whethe
accuracy of the kqueue timer is much less than what I need for my
> > > application.
> > >
> > > So my confusion at this point is whether this is consider to be a bug or
> > > "feature"?
> > >
> > > Here's some test cod
on.
> >
> > Specifically, I though I could use the kqueue timer as essentially a
> > "drop in" replacement for linuxfd_create/read, but was surprised that
> > the accuracy of the kqueue timer is much less than what I need for my
> > application.
>
y a
> "drop in" replacement for linuxfd_create/read, but was surprised that
> the accuracy of the kqueue timer is much less than what I need for my
> application.
>
> So my confusion at this point is whether this is consider to be a bug or
> "feature"?
>
> "drop in" replacement for linuxfd_create/read, but was surprised that
> the accuracy of the kqueue timer is much less than what I need for my
> application.
>
> So my confusion at this point is whether this is consider to be a bug or
> "feature"?
>
>
the accuracy of the kqueue timer is much less than what I need for my
application.
So my confusion at this point is whether this is consider to be a bug or
"feature"?
Here's some test code if you want to verify the problem:
#include
#include
#include
#include
#include
#include
On 03.04.2012 23:46, rank1see...@gmail.com wrote:
> GEOM: md0s3: invalid entries in the EBR ignored.
> --
>
> Not 100% reproducible.
> Running again SAME 'gpart destroy' then 'gpart create', worked.
This should be fixed in stable/9 with r232535.
--
WBR, Andrey V. Elsukov
___
On Tue, Apr 3, 2012 at 3:46 PM, wrote:
> 9.0 R i386
>
> EBR scheme never installed
>
> md0s3 has BSD labels scheme
>
> # gpart destroy -F md0s3
> md0s3 destroyed
>
> # gpart create -s BSD md0s3
> gpart: geom 'md0s3': File exists
>
> # gpart show -p md0s3
> => 0 1023120 md0s3 EBR (49
9.0 R i386
EBR scheme never installed
md0s3 has BSD labels scheme
# gpart destroy -F md0s3
md0s3 destroyed
# gpart create -s BSD md0s3
gpart: geom 'md0s3': File exists
# gpart show -p md0s3
=> 0 1023120 md0s3 EBR (499M) [CORRUPT]
0 1023120 - free - (499M)
I just set up mirroring on my dual boot fb-7.1/vistaX32SP1 machine (the
dual boot works fine) but I got this message when I attempted to mount
vista via sysutils/fusefs-ntfs:
Actual VCN (0x336970100) of index buffer is different from expected
VCN (0x1).
Failed to mount '/dev/mirror/gm0s1'
I am trying to automatically generate a description for a given device (eg
what it's connected to) but I am having trouble with umass.
The other disks I have tried (acd, ad, twed) all have dev.name.number sysctl
nodes but umass disks seem to be inconsistently named.
For example they appear in k
In message <[EMAIL PROTECTED]>, Matthew Dillon w
rites:
>I'm trying to figure out how the acpi_sleep_machdep() code works and
>there are a couple of lines I just don't understand:
>
>pm = vmspace_pmap(p->p_vmspace);
>cr3 = rcr3();
>#ifdef PAE
>load_cr3(vtophys(pm->p
I'm trying to figure out how the acpi_sleep_machdep() code works and
there are a couple of lines I just don't understand:
pm = vmspace_pmap(p->p_vmspace);
cr3 = rcr3();
#ifdef PAE
load_cr3(vtophys(pm->pm_pdpt));
#else
load_cr3(vtophys(pm->pm_pdir));
#endif
Yan Yu wrote this message on Sat, Feb 26, 2005 at 01:10 -0800:
> Hello, all,
> I have a user program as below:
> FILE *fd;
> while (1)
> {
> fd= fopen( "tmp", "r" );
> if ( fd == NULL )
> break;
> }
>
> from my understanding, since i open the same file to read, my process
On Sat, 26 Feb 2005, Yan Yu wrote:
> Hello, all,
> I have a user program as below:
> FILE *fd;
> while (1)
> {
> fd= fopen( "tmp", "r" );
> if ( fd == NULL )
> break;
> }
>
> from my understanding, since i open the same file to read, my process
> should create a new file
Hello, all,
I have a user program as below:
FILE *fd;
while (1)
{
fd= fopen( "tmp", "r" );
if ( fd == NULL )
break;
}
from my understanding, since i open the same file to read, my process
should create a new file descriptor each time when fopen is called.
Therefore,
On 9 Mar 2004, Bin Ren wrote:
> Hi,
>
> After reading the MAN page and source codes for KSE, I find some parts
> contradicting. Maybe the MAN page is out-dated. But I want to confirm this.
>
> First confusion:
>
> In KSE MAN:
>
Hi,
After reading the MAN page and source codes for KSE, I find some parts
contradicting. Maybe the MAN page is out-dated. But I want to confirm this.
First confusion:
In KSE MAN:
...
To become multi-threaded, a process must first invoke kse_create(). The
I am having an anurism over this.
Trying to opendir, readdir and unlink files in a directory over nfs
(with fbsd-current client and a variety of nfs servers (netapp, linux
fbsd)
seems to produce unexpected results.
if i run this code:
#include
#include
#include
#include
int
main(void)
{
In the last episode (Jul 18), Alexey Neyman said:
> hi, there!
>
> On Wednesday 09 July 2003 00:30, Dan Nelson wrote:
> DN> > pos = telldir(dirp);
> DN> > ent = readdir(dirp);
> DN> > seekdir(dirp, pos);
> DN> > printf("First telldir:%d\nSecond telldir:%d\n", pos, telldir(dirp));
>
hi, there!
On Wednesday 09 July 2003 00:30, Dan Nelson wrote:
DN> > pos = telldir(dirp);
DN> > ent = readdir(dirp);
DN> > seekdir(dirp, pos);
DN> > printf("First telldir:%d\nSecond telldir:%d\n", pos, telldir(dirp));
DN> I don't think there's any pstandard that says that telldir h
On Tue, Jul 08, 2003 at 03:30:26PM -0500, Dan Nelson wrote:
>
> [snip]
>
> I don't think there's any pstandard that says that telldir has to
> return a seekable file offset, or that consecutive calls on the same
> position must return the same value. Think about a filesystem that
> uses hashed or
In the last episode (Jul 08), Jp Calderone said:
> I'm trying to work out some inconsistent behavior in my app across
> platforms. On FreeBSD, seekdir() doesn't seem to behave as I expect
> it to. Here's a short program that demonstrates my confusion:
>
> o
I'm trying to work out some inconsistent behavior in my app across
platforms. On FreeBSD, seekdir() doesn't seem to behave as I expect it to.
Here's a short program that demonstrates my confusion:
#include
#include
#include
int main() {
DIR* dirp;
off_t pos;
str
On Sat, 23 Jun 2001, Terry Lambert wrote:
> Zhihui Zhang wrote:
> > I think you got me wrong. I was talking about a device
> > with more than one names. So we can have more than one
> > vnode for the same device. (If there is more than one name
> > to the same device in the same FS, they can sh
Zhihui Zhang wrote:
> I think you got me wrong. I was talking about a device
> with more than one names. So we can have more than one
> vnode for the same device. (If there is more than one name
> to the same device in the same FS, they can share the vnode,
> otherwise, they cannot.)
This is not
On Fri, 22 Jun 2001, Terry Lambert wrote:
> Zhihui Zhang wrote:
> > According to the red daemon book, alias vnodes are used to make cache
> > coherent (vp as a key). But getblk() stuff does not seem to check it.
> > This makes me feel the code is there for historical reasons.
>
> The "BSD 4.4
Zhihui Zhang wrote:
> According to the red daemon book, alias vnodes are used to make cache
> coherent (vp as a key). But getblk() stuff does not seem to check it.
> This makes me feel the code is there for historical reasons.
The "BSD 4.4" book was written about a system without a
unified VM an
There is following comment inside ufs_mknod() which says
/*
* Remove inode, then reload it through VFS_VGET so it is
* checked to see if it is an alias of an existing entry in
* the inode cache.
*/
I really can not understand it. For each new disk inode, we call
u
Hi Michael,
What version of FreeBSD are you running? If it's not too much trouble,
can you please provide the code you're using to simulate the problem? Are the
TIME_WAIT state connections eventually timing out/disappearing?
Michael wrote:
> If this is not proper place to ask this, let me k
If this is not proper place to ask this, let me know and I'll go elsewhere as
it is a TCP question. . . but I specifically use (and prefer) FreeBSD.
I wrote a simple little I/O multiplexing thing that can act as a client or
server as a personal project in network programming. Everything seems f
Ok, I've got a system that seems to spuriously "panic: unknown/reserved
trap". In trying to figure out which exception got triggered, I did a
backtrace...
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:303
#1 0xc016a355 in panic (fmt=0xc02c58d9 "unknown/reserved trap") at
../../
>
> ok:
>
> #define nfsm_srvmtofh(f) \
> { int fhlen = NFSX_V3FH; \
> if (nfsd->nd_flag & ND_NFSV3) { \
> nfsm_dissect(tl, u_int32_t *, NFSX_UNSIGNED); \
> fhlen = fxdr_unsigned(int, *tl); \
> if (fhlen == 0) {
>
> ok:
>
> #define nfsm_srvmtofh(f) \
> { int fhlen = NFSX_V3FH; \
> if (nfsd->nd_flag & ND_NFSV3) { \
> nfsm_dissect(tl, u_int32_t *, NFSX_UNSIGNED); \
> fhlen = fxdr_unsigned(int, *tl); \
> if (fhlen == 0) {
:Right now it seems we're generating 8 bytes of fsid and 12 (padded to 16)
:bytes of handle data in the common case for a total of 24 bytes of filehandle.
:Then we pad that to 32 bytes for V2 or 64 bytes for V3, with random crud.
:Then we copy this around, store it all in memory, transmit it over t
On Tue, 3 Aug 1999, Peter Wemm wrote:
> Alfred Perlstein wrote:
> > On Mon, 2 Aug 1999, Matthew Dillon wrote:
> >
> > http://big.endian.org/~bright/freebsd/patches/nfsm_subs.diff
> >
> > This is a patch that Peter Wemm proposed however he had this:
> >
> > ! if (fhlen < NFSX_V3FH)
Alfred Perlstein wrote:
> On Mon, 2 Aug 1999, Matthew Dillon wrote:
>
> >
> > ::> it then rewinds the mbuf pointers (i think) because of the
> > ::> over "dissection" above.
> > ::> ---
> > ::>
> > ::> why does it do the copy, then rewind it, it seems like it knows
> > ::> it's doing something
:The whole file needs some documentation. :)
:I stared at that for so long wondering why the heck it was doing that.
NFS is the worst-documented code in the kernel, VFS is second-worst.
Without commit privs, documenting existing code eats too much of my time
I'm afraid. With com
On Mon, 2 Aug 1999, Matthew Dillon wrote:
>
> ::> it then rewinds the mbuf pointers (i think) because of the
> ::> over "dissection" above.
> ::> ---
> ::>
> ::> why does it do the copy, then rewind it, it seems like it knows
> ::> it's doing something wrong and instead of fixing it, it just
:Right now it seems we're generating 8 bytes of fsid and 12 (padded to 16)
:bytes of handle data in the common case for a total of 24 bytes of filehandle.
:Then we pad that to 32 bytes for V2 or 64 bytes for V3, with random crud.
:Then we copy this around, store it all in memory, transmit it over
On Tue, 3 Aug 1999, Peter Wemm wrote:
> Alfred Perlstein wrote:
> > On Mon, 2 Aug 1999, Matthew Dillon wrote:
> >
> > http://big.endian.org/~bright/freebsd/patches/nfsm_subs.diff
> >
> > This is a patch that Peter Wemm proposed however he had this:
> >
> > ! if (fhlen < NFSX_V3FH
Alfred Perlstein wrote:
> On Mon, 2 Aug 1999, Matthew Dillon wrote:
>
> >
> > ::> it then rewinds the mbuf pointers (i think) because of the
> > ::> over "dissection" above.
> > ::> ---
> > ::>
> > ::> why does it do the copy, then rewind it, it seems like it knows
> > ::> it's doing somethin
:The whole file needs some documentation. :)
:I stared at that for so long wondering why the heck it was doing that.
NFS is the worst-documented code in the kernel, VFS is second-worst.
Without commit privs, documenting existing code eats too much of my time
I'm afraid. With co
On Mon, 2 Aug 1999, Matthew Dillon wrote:
>
> ::> it then rewinds the mbuf pointers (i think) because of the
> ::> over "dissection" above.
> ::> ---
> ::>
> ::> why does it do the copy, then rewind it, it seems like it knows
> ::> it's doing something wrong and instead of fixing it, it just
::> it then rewinds the mbuf pointers (i think) because of the
::> over "dissection" above.
::> ---
::>
::> why does it do the copy, then rewind it, it seems like it knows
::> it's doing something wrong and instead of fixing it, it just
::> compensates after the fact.
::
::yes, replying to my
:On Mon, 2 Aug 1999, Alfred Perlstein wrote:
:
:> } \
:> if (fhlen != 0) { \
:> nfsm_dissect(tl, u_int32_t *, NFSX_V3FH); \
:> bcopy((caddr_t)tl, (caddr_t)(f), NFSX_V3FH); \
:> if ((nfsd->nd_flag & ND_NFSV3) ==
::> it then rewinds the mbuf pointers (i think) because of the
::> over "dissection" above.
::> ---
::>
::> why does it do the copy, then rewind it, it seems like it knows
::> it's doing something wrong and instead of fixing it, it just
::> compensates after the fact.
::
::yes, replying to my
:On Mon, 2 Aug 1999, Alfred Perlstein wrote:
:
:> } \
:> if (fhlen != 0) { \
:> nfsm_dissect(tl, u_int32_t *, NFSX_V3FH); \
:> bcopy((caddr_t)tl, (caddr_t)(f), NFSX_V3FH); \
:> if ((nfsd->nd_flag & ND_NFSV3) =
On Mon, 2 Aug 1999, Alfred Perlstein wrote:
> } \
> if (fhlen != 0) { \
> nfsm_dissect(tl, u_int32_t *, NFSX_V3FH); \
> bcopy((caddr_t)tl, (caddr_t)(f), NFSX_V3FH); \
> if ((nfsd->nd_flag & ND_NFSV3) == 0
ok:
#define nfsm_srvmtofh(f) \
{ int fhlen = NFSX_V3FH; \
if (nfsd->nd_flag & ND_NFSV3) { \
nfsm_dissect(tl, u_int32_t *, NFSX_UNSIGNED); \
fhlen = fxdr_unsigned(int, *tl); \
if (fhlen == 0) { \
On Mon, 2 Aug 1999, Alfred Perlstein wrote:
> } \
> if (fhlen != 0) { \
> nfsm_dissect(tl, u_int32_t *, NFSX_V3FH); \
> bcopy((caddr_t)tl, (caddr_t)(f), NFSX_V3FH); \
> if ((nfsd->nd_flag & ND_NFSV3) ==
ok:
#define nfsm_srvmtofh(f) \
{ int fhlen = NFSX_V3FH; \
if (nfsd->nd_flag & ND_NFSV3) { \
nfsm_dissect(tl, u_int32_t *, NFSX_UNSIGNED); \
fhlen = fxdr_unsigned(int, *tl); \
if (fhlen == 0) { \
Hi,
You need to either set the netmask of the alias address to
255.255.255.255, or add a manual route statement:
route add 127.1
That will do it. Then you will be able to get to the alias address from
the aliased machine. On a side note:
1. Does anyone know how to get this same thing to
I didn't notice this until recently, but on our production web servers I use
IP aliasing to host multiple sites on one box. Pretty normal stuff. Here's
an ifconfig on one of these boxes:
xl0: flags=8843 mtu 1500
inet 208.156.59.51 netmask 0xff00 broadcast 208.156.59.255
inet
64 matches
Mail list logo
