Re: Ok, who broke timed?
On 20-Nov-01 John Baldwin wrote: > > On 20-Nov-01 John Baldwin wrote: >> >> On 20-Nov-01 Kris Kennaway wrote: >>> On Mon, Nov 19, 2001 at 05:57:06PM -0800, John Baldwin wrote: On 20-Nov-01 Kris Kennaway wrote: > On Mon, Nov 19, 2001 at 03:06:28PM -0800, John Baldwin wrote: >> Does timed have some major 64 bit issues or something? Trying to >> run timed on my 5.0 alpha from a 4.4 x86 box proves disastrous. 5.0 >> x86 clients work fine. The alpha keeps getting its date set back >> into 1970: > > It's probably never worked like that. The timed protocol is pretty > crufty and unportable. NetBSD fixed it to use fixed width sizes. I'm trying to port it but I think I'm missing bits. Now it sets the time to 2023 instead of 1970 however. *sigh* >>> >>> Getting closer..now you're only 22 years out instead of 31 :-) >> >> Heh. Still truncating the server name to 'in.baldwin.cx' however, so >> perhaps >> it is an alignment issue. *grump* >> >>> Kris > > Nope, typo. I had u_int64_t in place of u_short instead of u_int64_t. > *sigh* s/64/16/2, YKWIM. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ok, who broke timed?
On 20-Nov-01 John Baldwin wrote: > > On 20-Nov-01 Kris Kennaway wrote: >> On Mon, Nov 19, 2001 at 05:57:06PM -0800, John Baldwin wrote: >>> >>> On 20-Nov-01 Kris Kennaway wrote: >>> > On Mon, Nov 19, 2001 at 03:06:28PM -0800, John Baldwin wrote: >>> >> Does timed have some major 64 bit issues or something? Trying to >>> >> run timed on my 5.0 alpha from a 4.4 x86 box proves disastrous. 5.0 >>> >> x86 clients work fine. The alpha keeps getting its date set back >>> >> into 1970: >>> > >>> > It's probably never worked like that. The timed protocol is pretty >>> > crufty and unportable. >>> >>> NetBSD fixed it to use fixed width sizes. I'm trying to port it but I >>> think >>> I'm missing bits. Now it sets the time to 2023 instead of 1970 however. >>> *sigh* >> >> Getting closer..now you're only 22 years out instead of 31 :-) > > Heh. Still truncating the server name to 'in.baldwin.cx' however, so perhaps > it is an alignment issue. *grump* > >> Kris Nope, typo. I had u_int64_t in place of u_short instead of u_int64_t. *sigh* -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ok, who broke timed?
On 20-Nov-01 Kris Kennaway wrote: > On Mon, Nov 19, 2001 at 05:57:06PM -0800, John Baldwin wrote: >> >> On 20-Nov-01 Kris Kennaway wrote: >> > On Mon, Nov 19, 2001 at 03:06:28PM -0800, John Baldwin wrote: >> >> Does timed have some major 64 bit issues or something? Trying to >> >> run timed on my 5.0 alpha from a 4.4 x86 box proves disastrous. 5.0 >> >> x86 clients work fine. The alpha keeps getting its date set back >> >> into 1970: >> > >> > It's probably never worked like that. The timed protocol is pretty >> > crufty and unportable. >> >> NetBSD fixed it to use fixed width sizes. I'm trying to port it but I think >> I'm missing bits. Now it sets the time to 2023 instead of 1970 however. >> *sigh* > > Getting closer..now you're only 22 years out instead of 31 :-) Heh. Still truncating the server name to 'in.baldwin.cx' however, so perhaps it is an alignment issue. *grump* > Kris -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ok, who broke timed?
Leo Bicknell wrote: > On Mon, Nov 19, 2001 at 04:51:29PM -0800, John Baldwin wrote: > > That looks very promising indeed. Hrmm. I should go see if NetBSD has fix ed > > this. I guess having timeval be different sizes on different archs is a bi t of > > a pain. :( Perhaps it should use uint32_t? Or perhaps struct tsp should u se > > its own variant of timeval with uint32_t or some such. Ugh. > > If timeval is different sizes on different archs then I would > recomend the work be done take it to 64 bits, not 32. It fixes a > problem in about 30 years. :-) Unfortunately, it isn't our on-the-wire protocol to modify. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ok, who broke timed?
On Mon, Nov 19, 2001 at 05:57:06PM -0800, John Baldwin wrote: > > On 20-Nov-01 Kris Kennaway wrote: > > On Mon, Nov 19, 2001 at 03:06:28PM -0800, John Baldwin wrote: > >> Does timed have some major 64 bit issues or something? Trying to > >> run timed on my 5.0 alpha from a 4.4 x86 box proves disastrous. 5.0 > >> x86 clients work fine. The alpha keeps getting its date set back > >> into 1970: > > > > It's probably never worked like that. The timed protocol is pretty > > crufty and unportable. > > NetBSD fixed it to use fixed width sizes. I'm trying to port it but I think > I'm missing bits. Now it sets the time to 2023 instead of 1970 however. *sigh* Getting closer..now you're only 22 years out instead of 31 :-) Kris msg28642/pgp0.pgp Description: PGP signature
vmware boot problem (xp host, freebsd guest)
I am having trouble getting FreeBSD 4.4-RELEASE to run in vmware. I am using Windows XP Pro as the host os, vmware version 3, and FreeBSD as the guest os. I tried searching the mailing lists, but was unsuccessful in finding the answer to this problem. FreeBSD installs, but will not boot - it just hangs, with no errors. All suggestions / solutions appreciated. Thanks, Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ok, who broke timed?
On 20-Nov-01 Leo Bicknell wrote: > On Mon, Nov 19, 2001 at 04:51:29PM -0800, John Baldwin wrote: >> That looks very promising indeed. Hrmm. I should go see if NetBSD has >> fixed >> this. I guess having timeval be different sizes on different archs is a bit >> of >> a pain. :( Perhaps it should use uint32_t? Or perhaps struct tsp should >> use >> its own variant of timeval with uint32_t or some such. Ugh. > > If timeval is different sizes on different archs then I would > recomend the work be done take it to 64 bits, not 32. It fixes a > problem in about 30 years. :-) We'll cross that bridge when it comes to it, right now we need to not break binary compatibility with all those existing 4.x machines out there right now. Also, NetBSD used int32_t to be consistent. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ok, who broke timed?
On 20-Nov-01 Kris Kennaway wrote: > On Mon, Nov 19, 2001 at 03:06:28PM -0800, John Baldwin wrote: >> Does timed have some major 64 bit issues or something? Trying to >> run timed on my 5.0 alpha from a 4.4 x86 box proves disastrous. 5.0 >> x86 clients work fine. The alpha keeps getting its date set back >> into 1970: > > It's probably never worked like that. The timed protocol is pretty > crufty and unportable. NetBSD fixed it to use fixed width sizes. I'm trying to port it but I think I'm missing bits. Now it sets the time to 2023 instead of 1970 however. *sigh* > Kris -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ok, who broke timed?
On Mon, Nov 19, 2001 at 03:06:28PM -0800, John Baldwin wrote: > Does timed have some major 64 bit issues or something? Trying to > run timed on my 5.0 alpha from a 4.4 x86 box proves disastrous. 5.0 > x86 clients work fine. The alpha keeps getting its date set back > into 1970: It's probably never worked like that. The timed protocol is pretty crufty and unportable. Kris msg28638/pgp0.pgp Description: PGP signature
Re: FreeBSD (as a Guest OS), VMware & X11
"Glenn Gombert" wrote: > > In case anyone is interested...I have X11 running with FreeBSD as a Guest > operating system under Win2K..the current XFree86 server (v 4.101) > that is in the ports collection, runs ok with the generic wm that comes > with XFree86, when I try and run KDE under 'Current' I get .. > /usr/X11R6/lib/libXext.so.6 Undefined symbol "__stderrp"...for some > reason ... Be sure you have COMPAT4X=yes in /etc/make.conf. If you didn't, then do this: cd /usr/src/lib/compat/compat4x.i386 make obj make all make install Then all __stderrp etc stuff will go away, except for some *really* binaries that use libc_r.so.3 Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ok, who broke timed?
On Mon, Nov 19, 2001 at 04:51:29PM -0800, John Baldwin wrote: > That looks very promising indeed. Hrmm. I should go see if NetBSD has fixed > this. I guess having timeval be different sizes on different archs is a bit of > a pain. :( Perhaps it should use uint32_t? Or perhaps struct tsp should use > its own variant of timeval with uint32_t or some such. Ugh. If timeval is different sizes on different archs then I would recomend the work be done take it to 64 bits, not 32. It fixes a problem in about 30 years. :-) -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD (as a Guest OS), VMware & X11
On Mon, 19 Nov 2001, Glenn Gombert wrote: > > In case anyone is interested...I have X11 running with FreeBSD as a Guest > operating system under Win2K..the current XFree86 server (v 4.101) > that is in the ports collection, runs ok with the generic wm that comes > with XFree86, when I try and run KDE under 'Current' I get .. > /usr/X11R6/lib/libXext.so.6 Undefined symbol "__stderrp"...for some > reason ... don't worry this breakage is all over the place.. Almost nothing runs on -current because of it... (well.. you can get them going with some kludges but old binaries don't work by default, instead of "working by default I think it's in UPDATING somewhere but I forget what it was.. :-( > > GG. > > -- > Glenn Gombert > [EMAIL PROTECTED] - email > (513) 587-2643 x2263 - voicemail/fax > > > > __ > FREE voicemail, email, and fax...all in one place. > Sign Up Now! http://www.onebox.com > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ok, who broke timed?
On 20-Nov-01 Erik Trulsson wrote:
> On Mon, Nov 19, 2001 at 03:06:28PM -0800, John Baldwin wrote:
>> Does timed have some major 64 bit issues or something? Trying to run timed
>> on
>> my 5.0 alpha from a 4.4 x86 box proves disastrous. 5.0 x86 clients work
>> fine.
>> The alpha keeps getting its date set back into 1970:
>
> After quick look at the source I would say that timed has some major 64
> bit issues.
> As far as I can tell timed sends/receives a 'struct tsp' after
> adjusting it for byteorder but not for wordsize. This struct is
> defined in as
>
> struct tsp {
> u_char tsp_type;
> u_char tsp_vers;
> u_short tsp_seq;
> union {
> struct timeval tspu_time;
> char tspu_hopcnt;
> } tsp_u;
> char tsp_name[MAXHOSTNAMELEN];
> };
>
> and struct timeval is defined in as
>
> struct timeval {
> longtv_sec; /* seconds */
> longtv_usec;/* and microseconds */
> };
That looks very promising indeed. Hrmm. I should go see if NetBSD has fixed
this. I guess having timeval be different sizes on different archs is a bit of
a pain. :( Perhaps it should use uint32_t? Or perhaps struct tsp should use
its own variant of timeval with uint32_t or some such. Ugh.
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
FreeBSD (as a Guest OS), VMware & X11
In case anyone is interested...I have X11 running with FreeBSD as a Guest operating system under Win2K..the current XFree86 server (v 4.101) that is in the ports collection, runs ok with the generic wm that comes with XFree86, when I try and run KDE under 'Current' I get .. /usr/X11R6/lib/libXext.so.6 Undefined symbol "__stderrp"...for some reason ... GG. -- Glenn Gombert [EMAIL PROTECTED] - email (513) 587-2643 x2263 - voicemail/fax __ FREE voicemail, email, and fax...all in one place. Sign Up Now! http://www.onebox.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ok, who broke timed?
On Mon, Nov 19, 2001 at 03:06:28PM -0800, John Baldwin wrote:
> Does timed have some major 64 bit issues or something? Trying to run timed on
> my 5.0 alpha from a 4.4 x86 box proves disastrous. 5.0 x86 clients work fine.
> The alpha keeps getting its date set back into 1970:
After quick look at the source I would say that timed has some major 64
bit issues.
As far as I can tell timed sends/receives a 'struct tsp' after
adjusting it for byteorder but not for wordsize. This struct is
defined in as
struct tsp {
u_char tsp_type;
u_char tsp_vers;
u_short tsp_seq;
union {
struct timeval tspu_time;
char tspu_hopcnt;
} tsp_u;
char tsp_name[MAXHOSTNAMELEN];
};
and struct timeval is defined in as
struct timeval {
longtv_sec; /* seconds */
longtv_usec;/* and microseconds */
};
Since 'long' is 32-bit on x86 and 64-bits on Alpha this means that
"interesting" things seem likely to happen if one tries to send a
'long' between machines when they don't agree on how large a 'long' is.
>
> Nov 19 14:06:02 baz timed[379]: slave to in.cx
> Jan 2 21:35:41 baz timed[379]: date changed by in.cx from Mon Nov 19 14:06:02
> 2001
> 19 Nov 14:07:49 ntpdate[533]: step time server 216.34.144.7 offset
> 1006002718.410080 sec
>
> (I ran ntpdate manually after killing timed.)
>
> On x86 the messages look like so:
>
> Nov 19 13:14:05 deimos timed[425]: slave to server.baldwin.cx
> Nov 19 13:13:42 deimos timed[425]: date changed by server.baldwin.cx from Mon
> Nov 19 13:14:05 2001
>
> And work fine. Also, FWIW, timed spits out a bunch of unaligned access
> warnings when it starts up on alpha.
--
Erik Trulsson
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Ok, who broke timed?
Does timed have some major 64 bit issues or something? Trying to run timed on my 5.0 alpha from a 4.4 x86 box proves disastrous. 5.0 x86 clients work fine. The alpha keeps getting its date set back into 1970: Nov 19 14:06:02 baz timed[379]: slave to in.cx Jan 2 21:35:41 baz timed[379]: date changed by in.cx from Mon Nov 19 14:06:02 2001 19 Nov 14:07:49 ntpdate[533]: step time server 216.34.144.7 offset 1006002718.410080 sec (I ran ntpdate manually after killing timed.) On x86 the messages look like so: Nov 19 13:14:05 deimos timed[425]: slave to server.baldwin.cx Nov 19 13:13:42 deimos timed[425]: date changed by server.baldwin.cx from Mon Nov 19 13:14:05 2001 And work fine. Also, FWIW, timed spits out a bunch of unaligned access warnings when it starts up on alpha. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tcpdump
* Anjali Kulkarni <[EMAIL PROTECTED]> [09 04:25] wrote: > > Right! I am on a switch on a small n/w connected to another switch > which has a larger n/w connected to it. Will using the hub decrease > my response time for fetching web pages? (They are not large pages) A hub will cause slowdown, but probably not so much that your browsing is notiably effected. -- -Alfred Perlstein [[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Framebuffer device under FreeBSD?
On Fri, Nov 09, 2001 at 09:16:00AM -0800, Pedro F. Giffuni wrote: > >> Framebuffer devices, etc... > > Actually this discussion is moot: there has been an > important advance in porting KGI to FreeBSD. > > Check the developers list archives in > http://kgi.sourceforge.net/ > > For those lazy: it's not here yet, but FreeBSD 5.0 will > have kick ass graphics! Just to add this link (I have to update it with recent progress which is described in the kgi ML archive): http://people.freebsd.org/~nsouch/ggiport.html Note that a Linuxfb emulation layer should not be too hard with KGI. Please join the kgi ML, I immediatly ask the question there. Nicholas -- Alcôve Technical Manager - [EMAIL PROTECTED] - http://www.alcove.com FreeBSD Developer - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mt/dump/chio
> > rmt protocol doesn't handle changer commands. > > You want to start looking at things like NDMP instead. i know that rmt does not support it, but then again it's a a very small program that could be made to understand it. i also had a look at NDMP in the past, which is more ambitious, but as far as i can remember, it does not realy support changers. danny To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mt/dump/chio
rmt protocol doesn't handle changer commands. You want to start looking at things like NDMP instead. On Mon, 19 Nov 2001, Danny Braniss wrote: > i don't know if this is the right place, if not please re-direct me before > shooting :-) > > we have a tape changer (QUALSTAR TLS-4222i), with 2 scsi tapes, > now since both tar and dump understand -f host:/dev/sa, the next thing i did > was to make mt (MT(1)) understand it, so that i now can manipulate the > tape from afar, without having access permitions to host. > > the next step it to see how - if at all - mt should understand things like: > 'host:/dev/sa0:115' meaning mount tape 115 on /dev/sa0 > or more ambitious: > 'host:/dev/tape:100@10:45pm' mount tape number 100, on any free device > not earlier than 10:45pm > > if you can see where im going to, and have suggestions, they are welcome. > > danny > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
mt/dump/chio
i don't know if this is the right place, if not please re-direct me before shooting :-) we have a tape changer (QUALSTAR TLS-4222i), with 2 scsi tapes, now since both tar and dump understand -f host:/dev/sa, the next thing i did was to make mt (MT(1)) understand it, so that i now can manipulate the tape from afar, without having access permitions to host. the next step it to see how - if at all - mt should understand things like: 'host:/dev/sa0:115' meaning mount tape 115 on /dev/sa0 or more ambitious: 'host:/dev/tape:100@10:45pm' mount tape number 100, on any free device not earlier than 10:45pm if you can see where im going to, and have suggestions, they are welcome. danny To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: has 'options LOCKF_DEBUG' ever worked? (w/ patch) (fwd)
Hello,
Thank you Terry for your answer, I got your meaning. IMHO we can
safely commit my patch meanwhile:
http://news1.macomnet.ru/~maxim/p/kern_lockf.c.diff
Committers? :-)
On Fri, 16 Nov 2001, Terry Lambert wrote:
> Maxim Konovalov wrote:
> > Alfred, John, thanks you very much for your answers. I expected
> > something similar. Btw are there any smart ways to find out does
> > underlying FS support inode concept or not? Yes, I know about
> > vnode.v_tag, but comparing it with VT_UFS/VT_NFS/VT_MFS etc does not
> > look OK for me.
>
> In theory, vnodes are supposed to be opaque types, with no backing
> object exposure.
>
> The real problem here is that the lock list should not be hung
> off the inode at all, it should be hung off the vnode, and the
> underlying FS objects not referenced (as you noted, there's a
> "two for one" object reference locking problem in the current
> code). You still need to go to the backing FS, though, since
> you need to proxy NFS client locks to remote objects, etc.. IF
> you look at ufs_advlock(), you can see the problem:
>
> ufs_advlock(ap)
> struct vop_advlock_args /* {
> struct vnode *a_vp;
> caddr_t a_id;
> int a_op;
> struct flock *a_fl;
> int a_flags;
> } */ *ap;
> {
> register struct inode *ip = VTOI(ap->a_vp);
>
> return (lf_advlock(ap, &(ip->i_lockf), ip->i_size));
> }
>
> ... the vp lock has to imply an ip lock, at least for the i_lockf
> list head, which is procedurally exposed.
>
> A better fix would be to move the lock list into the vnode, and
> then call the VOP_ADVLOCK() and assert the lock only if the VFS
> VOP_ADVLOCK() returned true.
>
> This really can't be done safely, since you need to addert locally
> before remotely, but then you need to delay the local coelesce, or
> you can screw up if the local succeeds and the remote fails, or
> vice versa.
>
> So the true fix has to include delayed coelescing of the local lock
> assertion.
>
> That's true anyway, since the NFSv4 specification demands that the
> locks not be coelesced at all, for an implementation to be compliant.
>
> -- Terry
>
>
--
Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer
phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Major number for Sunlite USB DMX driver?
Hi, I've written completed a driver for Sunlite's USB DMX512 interface: http://nicolaudie.com/cgi-bin/bin?site=nicolaudie.com&lang=si For those who don't know, DMX512 is the standard control protocol for stage lighting, and it let's people use programs like Lula http://www-pu.informatik.uni-tuebingen.de/lula/index-english.html for lighting control instead of specialized, customized, expensive and bulky control consoles. The name of the driver is currently "udmx" to allow for the inclusion of other USB DMX devices. It would be nice to have a device major number allocated for it. I'm not sure if this needs to be coordinated with the USB developers and/or NetBSD, and I'd appreciate if anybody could let me know what needs to be done. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tcpdump
Right! I am on a switch on a small n/w connected to another switch which has a larger n/w connected to it. Will using the hub decrease my response time for fetching web pages? (They are not large pages) Anjali - Original Message - From: "Alfred Perlstein" <[EMAIL PROTECTED]> To: "Anjali Kulkarni" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, November 19, 2001 3:08 PM Subject: Re: tcpdump > * Anjali Kulkarni <[EMAIL PROTECTED]> [09 03:36] wrote: > > Hi, > > > > I am trying to make tcpdump work across 2 machines, ie trying to > > monitor a machine's IP packets from another machine. Just typing > > 'tcpdump host ip2' from the first m/c, say ip1, is not working. > > However, typing 'tcpdump host ip2' on ip2 works fine. Do I have to > > configure BSD packet filter to make this work ? I am working on > > 4.3. > > Please wrap lines at 70 characters. > > You're probably on a switch which means that other hosts on the same > ethernet segment can not see each other's packets. You need a hub > or a switch that supports a monitoring port where all packets are > repeated. > > -- > -Alfred Perlstein [[EMAIL PROTECTED]] > 'Instead of asking why a piece of software is using "1970s technology," > start asking why software is ignoring 30 years of accumulated wisdom.' >http://www.morons.org/rants/gpl-harmful.php3 > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kern.vm.kmem.size
On Thu, Nov 15, 2001 at 11:14:48PM +0700, Eugene Grosbein wrote: > You are absolutely right, it's using about 1/3 of RAM here > (108875776 when I do not tune kern.vm.kmem.size). > Hmm, my test seems to be incorrect somehow. > How can I see used amount of kernel malloc area? I think you could probably derive it from the info shown by "vmstat -m". David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
tcpdump
I forgot to mention, the line pseudo-device bpf 4 is there in the kernel config file Anjali
Re: tcpdump
* Anjali Kulkarni <[EMAIL PROTECTED]> [09 03:36] wrote: > Hi, > > I am trying to make tcpdump work across 2 machines, ie trying to > monitor a machine's IP packets from another machine. Just typing > 'tcpdump host ip2' from the first m/c, say ip1, is not working. > However, typing 'tcpdump host ip2' on ip2 works fine. Do I have to > configure BSD packet filter to make this work ? I am working on > 4.3. Please wrap lines at 70 characters. You're probably on a switch which means that other hosts on the same ethernet segment can not see each other's packets. You need a hub or a switch that supports a monitoring port where all packets are repeated. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
tcpdump
Hi, I am trying to make tcpdump work across 2 machines, ie trying to monitor a machine's IP packets from another machine. Just typing 'tcpdump host ip2' from the first m/c, say ip1, is not working. However, typing 'tcpdump host ip2' on ip2 works fine. Do I have to configure BSD packet filter to make this work ? I am working on 4.3. Thanks, Anjali
[no subject]
subscribe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
