getsockopt not working??

[S.RadhaKrishna]

hi,
  I'm using getsockopt to get IP_MULTICAST_TTL. But it always returns ttl
as 0. It doesn't fail either.
Here is the call I'm using :
---
int get_ttl=0;
u_char ttlSize=0;
if (getsockopt(sockfd, IPPROTO_IP, IP_MULTICAST_TTL,
   (void*)&get_ttl,(int *)&ttlSize) < 0)
 {
  printf("ttl.c:get ttl failed\n");
  perror("getsockopt");
  exit(1);
 }
--
I used setsockopt to set ttl value. It works fine (I saw the packets on the
network using a sniffer). But getsockopt returns always 0. 
Any help on this would be appreciated.

regards
radha


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: CFD: "bogomips" CPU performance metric

[Mike Nowlin]

>I disagree.  BogoMIPS is a completely meaningless measurement
> and does not belong in our source tree as it will only produce
> repository bloat.

I would agree..  BogoMIPS actually stands for "Bogus, Misleading
Indication of Processor Speed"...  In an old Linux Journal article I have
(will dig it up upon request), it describes how BogoMIPS is calculated --
it's VERY processor-dependant, and only really (sort of) useful for
comparing motherboards with the same processor on them.  Switch from
an Intel 486/66 to an AMD 486/100, and the numbers do NOT match up to what
you'd think And if you change to a Pentium, forget it.

The biggest thing it's good for is as an ego-booster  Of course, my
dual-PII/450 box has a bigger BogoMIPS rating than any machine at work..
:)

--mike




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: SMP + fxp0 wierdness

[Mike Smith]

>   Well that's not good, since I have almost convinced my boss to replace
> the crappy IDE drives on our shiny new Intel N440BX mb's with scsi
> drives since the controller is built in. :-/  Does this look like a
> soluble problem, or is it just going to be a case of "don't do that?"
> Anything I can do to help mail me and let me know.

You could try turning on DMA and discovering that these drives aren't 
_that_ shitty. 8)

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: SMP + fxp0 wierdness

[Doug]

David Greenman wrote:
> 
> >> So if this problem is NOT related to specific hardware, how can we get
> >> the driver fixed?
> >
> >Talk to the maintainer (David).  We've offered him cores and kernels
> >before.  Alternatively, you'll need to experiment with your setup to
> >determine what characterises the failures and help David out with more
> >data.
> 
>Hotmail has troubleshooted the problem down to the NCR controller. It
> appears that the problem only occurs when using one of those. If they plug
> in an Adaptec 2940 and use it instead of the onboard NCR then the problems
> disappear.

Well that's not good, since I have almost convinced my boss to replace
the crappy IDE drives on our shiny new Intel N440BX mb's with scsi
drives since the controller is built in. :-/  Does this look like a
soluble problem, or is it just going to be a case of "don't do that?"
Anything I can do to help mail me and let me know.

Doug
-- 
"Stop it, I'm gettin' misty." 

- Mel Gibson as Porter, "Payback"


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Unquoted mail (was: aio_read kills machine)

[Chris Costello]

On Tue, Oct 12, 1999, Greg Lehey wrote:
> It doesn't have anything to do with the MUA.  The message arrived here
> without a > in front of the 'From ' at the beginning of the line,
> which is an indication that it's a new message.  But it's interesting
> that it didn't happen to everybody.

   Some MTA between him and me (his mail server, calldei.com's
mail server, or my fetchmail) has quoted it on my message.

> Greg

-- 
|Chris Costello <[EMAIL PROTECTED]>
|State-of-the-art: What we could do with enough money.
`-


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Unquoted mail (was: aio_read kills machine)

[Greg Lehey]

On Monday, 11 October 1999 at 20:39:11 -0500, Matthew D. Fuller wrote:
> On Tue, Oct 12, 1999 at 11:04:50AM +0930, a little birdie told me
> that Greg Lehey remarked
>>
>> What mailer are you using?  It didn't quote the "From " at the
>> beginning of the message, so David's message appeared as a separate
>> message.  If you're looking for it, sort your messages in mailbox
>> order and it'll be the next message after Andy's original.
>
> He appears to be using Pine, and it quoted it just fine for me.
> And I do believe we're both using the same MUA, so I don't know where it
> burped on the way to you.

It doesn't have anything to do with the MUA.  The message arrived here
without a > in front of the 'From ' at the beginning of the line,
which is an indication that it's a new message.  But it's interesting
that it didn't happen to everybody.

Greg
--
See complete headers for address, home page and phone numbers
finger [EMAIL PROTECTED] for PGP public key


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: aio_read kills machine

[Matthew D. Fuller]

On Tue, Oct 12, 1999 at 11:04:50AM +0930, a little birdie told me
that Greg Lehey remarked
> 
> What mailer are you using?  It didn't quote the "From " at the
> beginning of the message, so David's message appeared as a separate
> message.  If you're looking for it, sort your messages in mailbox
> order and it'll be the next message after Andy's original.

He appears to be using Pine, and it quoted it just fine for me.
And I do believe we're both using the same MUA, so I don't know where it
burped on the way to you.




-- 
Matthew Fuller (MF4839) |[EMAIL PROTECTED]
Unix Systems Administrator  |[EMAIL PROTECTED]
Specializing in FreeBSD |http://www.over-yonder.net/
FutureSouth Communications  |ISPHelp ISP Consulting

"The only reason I'm burning my candle at both ends, is because I
  haven't figured out how to light the middle yet"


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: aio_read kills machine

[Greg Lehey]

On Tuesday, 12 October 1999 at  8:09:40 +1000, Andy Farkas wrote:
>
> On Mon, 11 Oct 1999, Steven Ames wrote:
>
>> Could someone define what NMBCLUSTERS is and what it is used for? I've
>> seen a lot of cases where increasing it (beyond the default 1024?) has
>> helped systems be more stable, but what is it?
>>
>
> Here is an informative email from David Greenman:
>
> snip

What mailer are you using?  It didn't quote the "From " at the
beginning of the message, so David's message appeared as a separate
message.  If you're looking for it, sort your messages in mailbox
order and it'll be the next message after Andy's original.

Greg
--
See complete headers for address, home page and phone numbers
finger [EMAIL PROTECTED] for PGP public key


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Single character errors in source files, stop kernel

[do not use this address]

I had a similar problem.  There was a pattern to the changes; one bit
was being set (I think it was bit 5) occasionally.  It gradually became
more frequent, and turned out to be a faulty IDE controller card.

Needless to say, I had thought that it was the connector/s, the cable,
or the drive, in that order.

-- Tim Jackson

please reply to: t i m . j @ f u n b o x . d e m o n . c o . u k



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: SMP + fxp0 wierdness

[David Greenman]

>> >> So if this problem is NOT related to specific hardware, how can we get
>> >> the driver fixed?
>> >
>> >Talk to the maintainer (David).  We've offered him cores and kernels 
>> >before.  Alternatively, you'll need to experiment with your setup to 
>> >determine what characterises the failures and help David out with more 
>> >data.
>> 
>>Hotmail has troubleshooted the problem down to the NCR controller. It
>> appears that the problem only occurs when using one of those. If they plug
>> in an Adaptec 2940 and use it instead of the onboard NCR then the problems
>> disappear.
>
>We did this (you remember that we went through all this a while back, 
>right?), but we've also been seing reports from people that aren't 
>using NCR controllers.

   I haven't seen a report yet from someone not using an NCR/Symbios
controller.

-DG

David Greenman
Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org
Creator of high-performance Internet servers - http://www.terasolutions.com
Pave the road of life with opportunities.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: aio_read kills machine

[Andy Farkas]

On Mon, 11 Oct 1999, Steven Ames wrote:

> Could someone define what NMBCLUSTERS is and what it is used for? I've
> seen a lot of cases where increasing it (beyond the default 1024?) has 
> helped systems be more stable, but what is it?
> 

Here is an informative email from David Greenman:

snip
>From [EMAIL PROTECTED] Tue Oct 12 08:07:20 1999
Date: Mon, 17 May 1999 18:58:06 -0700
From: David Greenman <[EMAIL PROTECTED]>
To: Nicole Harrington <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], Brian Behlendorf <[EMAIL PROTECTED]>
Subject: Re: maxusers/nmbclusters 

> I have read that if you have needs that would require turning up NMBclusters,
>and certain sysctl options, etc, that you should do so independantly and not
>increase maxusers up much above 256. Will that recomendation change with 3.2 as
>well?

   If you specify NMBCLUSTERS, then you only need to tune maxusers for
increased number of processes (nproc = 16 * maxusers). This is true in all
versions of FreeBSD.

-DG

David Greenman
Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org
Creator of high-performance Internet servers - http://www.terasolutions.com
snip

> -Steve
> 

--
 
 :{ [EMAIL PROTECTED]
  
Andy Farkas
System Administrator
   Speednet Communications
 http://www.speednet.com.au/
  




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: SMP + fxp0 wierdness

[Mike Smith]

> >> So if this problem is NOT related to specific hardware, how can we get
> >> the driver fixed?
> >
> >Talk to the maintainer (David).  We've offered him cores and kernels 
> >before.  Alternatively, you'll need to experiment with your setup to 
> >determine what characterises the failures and help David out with more 
> >data.
> 
>Hotmail has troubleshooted the problem down to the NCR controller. It
> appears that the problem only occurs when using one of those. If they plug
> in an Adaptec 2940 and use it instead of the onboard NCR then the problems
> disappear.

We did this (you remember that we went through all this a while back, 
right?), but we've also been seing reports from people that aren't 
using NCR controllers.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: aio_read kills machine

[Brian F. Feldman]

I'd like everyone to note that for now, if you are providing user-access
to a 4.0 box (and you don't absolutely trust your users), you should be
using the RLIMIT_SBSIZE for limiting network memory usage just as
you use other RLIMITs for memory limiting, etc.

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: SMP + fxp0 wierdness

[David Greenman]

>> So if this problem is NOT related to specific hardware, how can we get
>> the driver fixed?
>
>Talk to the maintainer (David).  We've offered him cores and kernels 
>before.  Alternatively, you'll need to experiment with your setup to 
>determine what characterises the failures and help David out with more 
>data.

   Hotmail has troubleshooted the problem down to the NCR controller. It
appears that the problem only occurs when using one of those. If they plug
in an Adaptec 2940 and use it instead of the onboard NCR then the problems
disappear.

-DG

David Greenman
Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org
Creator of high-performance Internet servers - http://www.terasolutions.com
Pave the road of life with opportunities.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: CFD: "bogomips" CPU performance metric

[Brian F. Feldman]

On Sun, 10 Oct 1999, Chris Costello wrote:

> On Sun, Oct 10, 1999, Laurence Berland wrote:
> > I like the idea as an optional LINT parameter that is NOT in the generic
> > kernel.  Might make some linux people feel comfortable with the switch,
> > or might prove useful under some odd circumstances, but I agree it'd be
> > silly to include it by default (kindof on the level of a splash screen)
> 
>I disagree.  BogoMIPS is a completely meaningless measurement
> and does not belong in our source tree as it will only produce
> repository bloat.
> 

Right.  If you're worried that there's something wrong with your CPU
speed, you can always bootverbose and check out the clocks and bzero
tests.

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: aio_read kills machine

[Steven Ames]

> > > > Running ``nmap -sP 172.22.0.0/16'' as a normal user will cause 
> > > > a panic on a recent 3.3-STABLE system :(
> > > 
> > > Could you be any less specific about the panic?  Any sort of detail 
> > > is just going to make us want to fix it.
> > 
> > Here most of the message I posted to -stable:
>
> Oh, that one.  You need to increase maxusers or NMBCLUSTERS.  This is 
> the subject of ongoing work in -current that ought to make it back to 
> -stable eventually.

Could someone define what NMBCLUSTERS is and what it is used for? I've
seen a lot of cases where increasing it (beyond the default 1024?) has 
helped systems be more stable, but what is it?

If someone does bother to respond to this with a good definition then
maybe that definition could make it into LINT?

-Steve


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Squid under FreeBSD 3.3-STABLE ...

[Henrik Nordstrom]

Marc G. Fournier wrote:

> 4. Decreased TCP's Maximum Segment Lifetime to three seconds
> - did it

This tweak is specific to PolyGraph testing in high speed LAN
environment. It is defenitely NOT recommended tuning for an Internet
connected system...  MSL should in WAN connections be no less than 30
seconds.

--
Henrik Nordstrom
Squid hacker


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: aio_read kills machine

[Mike Smith]

> 
> On Mon, 11 Oct 1999, Mike Smith wrote:
> 
> > > Running ``nmap -sP 172.22.0.0/16'' as a normal user will cause a panic on
> > > a recent 3.3-STABLE system :(
> > 
> > Could you be any less specific about the panic?  Any sort of detail is 
> > just going to make us want to fix it.
> 
> Here most of the message I posted to -stable:

Oh, that one.  You need to increase maxusers or NMBCLUSTERS.  This is 
the subject of ongoing work in -current that ought to make it back to 
-stable eventually.

> snip
> *From [EMAIL PROTECTED] Tue Oct 12 07:20:08 1999
> Date: Mon, 27 Sep 1999 19:43:21 +1000 (EST)
> To: [EMAIL PROTECTED]
> Subject: nmap V. 2.3BETA5 causes panic
> 
> The system will panic with an 'out of mbufs' message when I run the above
> nmap command ("ping scan" a class B subnet - my internal IP network).
> 
> Should this be happening when run as a normal user??  The kernel is pretty
> stock with maxusers 32, no NMBCLUSTERS option, unneeded devices removed.  
> There is 64M RAM and 256M swap; it is has dual 90MHz P54C's.
> 
> This system (my workstation) is a:
> FreeBSD 3.3-STABLE #0: Mon Sep 20 09:44:35 EST 1999
> 
> I am:
> bash-2.03$ id
> uid=1000(andyf) gid=1000(andyf) groups=1000(andyf), 0(wheel)
> 
> I have:
> bash-2.03$ limits
> Resource limits (current):
>   cputime  infinity secs
>   filesize  1048576 kb
>   datasize65536 kb
>   stacksize8192 kb
>   coredumpsize   131072 kb
>   memoryuse   65536 kb
>   memorylocked 8192 kb
>   maxprocesses  256
>   openfiles 256
> 
> I use:
> bash-2.03$ 
> 
> How would you go about preventing this problem?
> 
> Thanks.
> snip
> 
> > 
> > -- 
> > \\ Give a man a fish, and you feed him for a day. \\  Mike Smith
> > \\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
> > \\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]
> > 
> > 
> 
> --
>  
>  :{ [EMAIL PROTECTED]
>   
> Andy Farkas
> System Administrator
>Speednet Communications
>  http://www.speednet.com.au/
>   
> 
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: aio_read kills machine

[Andy Farkas]

On Mon, 11 Oct 1999, Mike Smith wrote:

> > Running ``nmap -sP 172.22.0.0/16'' as a normal user will cause a panic on
> > a recent 3.3-STABLE system :(
> 
> Could you be any less specific about the panic?  Any sort of detail is 
> just going to make us want to fix it.

Here most of the message I posted to -stable:

snip
*From [EMAIL PROTECTED] Tue Oct 12 07:20:08 1999
Date: Mon, 27 Sep 1999 19:43:21 +1000 (EST)
To: [EMAIL PROTECTED]
Subject: nmap V. 2.3BETA5 causes panic

The system will panic with an 'out of mbufs' message when I run the above
nmap command ("ping scan" a class B subnet - my internal IP network).

Should this be happening when run as a normal user??  The kernel is pretty
stock with maxusers 32, no NMBCLUSTERS option, unneeded devices removed.  
There is 64M RAM and 256M swap; it is has dual 90MHz P54C's.

This system (my workstation) is a:
FreeBSD 3.3-STABLE #0: Mon Sep 20 09:44:35 EST 1999

I am:
bash-2.03$ id
uid=1000(andyf) gid=1000(andyf) groups=1000(andyf), 0(wheel)

I have:
bash-2.03$ limits
Resource limits (current):
  cputime  infinity secs
  filesize  1048576 kb
  datasize65536 kb
  stacksize8192 kb
  coredumpsize   131072 kb
  memoryuse   65536 kb
  memorylocked 8192 kb
  maxprocesses  256
  openfiles 256

I use:
bash-2.03$ 

How would you go about preventing this problem?

Thanks.
snip

> 
> -- 
> \\ Give a man a fish, and you feed him for a day. \\  Mike Smith
> \\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
> \\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]
> 
> 

--
 
 :{ [EMAIL PROTECTED]
  
Andy Farkas
System Administrator
   Speednet Communications
 http://www.speednet.com.au/
  




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: aio_read kills machine

[Mike Smith]

> On Mon, 11 Oct 1999, Chris Costello wrote:
> 
> >Not really.  The fact is that a user program can crash
> > 3.3-STABLE and that is unacceptable.  No user program should be
> > able to bring down a system, _especially_ in -STABLE.
> > 
> 
> Running ``nmap -sP 172.22.0.0/16'' as a normal user will cause a panic on
> a recent 3.3-STABLE system :(

Could you be any less specific about the panic?  Any sort of detail is 
just going to make us want to fix it.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: aio_read kills machine

[Andy Farkas]

On Mon, 11 Oct 1999, Chris Costello wrote:

>Not really.  The fact is that a user program can crash
> 3.3-STABLE and that is unacceptable.  No user program should be
> able to bring down a system, _especially_ in -STABLE.
> 

Running ``nmap -sP 172.22.0.0/16'' as a normal user will cause a panic on
a recent 3.3-STABLE system :(

--
 
 :{ [EMAIL PROTECTED]
  
Andy Farkas
System Administrator
   Speednet Communications
 http://www.speednet.com.au/
  




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: aio_read kills machine

[Christopher Sedore]

On Mon, 11 Oct 1999, Chris Costello wrote:

> On Mon, Oct 11, 1999, Chad David wrote:
> > Some replys indicated that I should use -current
> > for aio_*.  Would this be true also for any
> > serious threading? Is -current ready for a
> > semi-production environment?
> 
>Not really.  The fact is that a user program can crash
> 3.3-STABLE and that is unacceptable.  No user program should be
> able to bring down a system, _especially_ in -STABLE.

You need to rip out most of aio_* in -stable or -current for
this to be true.

-Chris





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: aio_read kills machine

[Chris Costello]

On Mon, Oct 11, 1999, Chad David wrote:
> Some replys indicated that I should use -current
> for aio_*.  Would this be true also for any
> serious threading? Is -current ready for a
> semi-production environment?

   Not really.  The fact is that a user program can crash
3.3-STABLE and that is unacceptable.  No user program should be
able to bring down a system, _especially_ in -STABLE.

> The source for this code is available from
> http://www.guild.ab.ca/killer.tar.gz if anyone
> would like to take a look.  The crash has been
> truncating main.c, so you may want to copy it
> before running the program.
> 
> Thanks.
> 
> Chad

-- 
|Chris Costello <[EMAIL PROTECTED]>
|TRAPEZOID - A device for catching zoids.
`


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: aio_read kills machine

[Arindum Mukerji]

* Luoqi Chen ([EMAIL PROTECTED]) [991011 12:58]:
> You need to go to -current for this.
> 

Surely the relevant patches should be backported to -release, then?
Given the severity of the problem and the fact that this problem
purportedly hangs the entire system from an unprivileged context,
going to -current should take a back seat to backporting the
relevant fix to -release.

Let me know if I can help with this.

Just my $0.02.

-- 
Arindum


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: aio_read kills machine

[Chad David]

I have submitted a PR.  Upon closer inspection
I found that it is not (directly) the call
to aio_read() that kills the machine, but
instead a call to sched_yield() after a call
to pthread_cond_wait() with a NULL in the mutex
field.  Even a print statement before the call
to sched_yield() prevents the kill.

Some replys indicated that I should use -current
for aio_*.  Would this be true also for any
serious threading? Is -current ready for a
semi-production environment?

The source for this code is available from
http://www.guild.ab.ca/killer.tar.gz if anyone
would like to take a look.  The crash has been
truncating main.c, so you may want to copy it
before running the program.

Thanks.

Chad

On Sun, 10 Oct 1999, Chris Costello wrote:

> On Wed, Jan 01, 1997, Chad David wrote:
> > I am certain that my program is not correct
> > (besides the obvious consiquence of running
> > it :) ), but I would also like to determine
> > why it kills the machine.  I was not root
> > either time I ran the code.
> 
>Then FreeBSD does have a problem.  Please file a PR using the
> ``send-pr'' command or http://www.freebsd.org/send-pr.html and
> supply the source to your program and whatever other information
> you think will help us in figuring out the problem.
> 
> -- 
> |Chris Costello <[EMAIL PROTECTED]>
> |Field tested: Manufacturing doesn't have a test system.
> `---
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: SMP + fxp0 wierdness

[Mike Smith]

> So if this problem is NOT related to specific hardware, how can we get
> the driver fixed?

Talk to the maintainer (David).  We've offered him cores and kernels 
before.  Alternatively, you'll need to experiment with your setup to 
determine what characterises the failures and help David out with more 
data.

> Stevan Arychuk
> AvantGo Inc.
> [EMAIL PROTECTED]
> 
> Mike Smith wrote:
> > 
> > > Thanks for your response David.
> > >
> > > Do you think the problem is isolated to just the onboard devices?  Would
> > > a PCI NIC help or is it the entire N440BX board?
> > 
> > We've seen these symptoms on non-Intel boards.  (eg. ASUS P2L, P2B).
> > 
> > --
> > \\ Give a man a fish, and you feed him for a day. \\  Mike Smith
> > \\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
> > \\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: SMP + fxp0 wierdness

[Stevan Arychuk]

So if this problem is NOT related to specific hardware, how can we get
the driver fixed?

Stevan Arychuk
AvantGo Inc.
[EMAIL PROTECTED]

Mike Smith wrote:
> 
> > Thanks for your response David.
> >
> > Do you think the problem is isolated to just the onboard devices?  Would
> > a PCI NIC help or is it the entire N440BX board?
> 
> We've seen these symptoms on non-Intel boards.  (eg. ASUS P2L, P2B).
> 
> --
> \\ Give a man a fish, and you feed him for a day. \\  Mike Smith
> \\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
> \\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: aio_read kills machine

[Luoqi Chen]

> I am working on a small threaded program
> that uses aio_read().  In my first attempt
> to run the program it killed my machine
> instantly.  The second time it only locked
> it solid.  I get no messages, warnings, or
> errors.
> 
> I am certain that my program is not correct
> (besides the obvious consiquence of running
> it :) ), but I would also like to determine
> why it kills the machine.  I was not root
> either time I ran the code.
> 
> I could provide additional debugging information,
> and the source to anybody who cares about this.
> I am not sure up front what would be helpful.
> 
> The machine is a dual 400 with 512Mg ram, running
> 3.3-stable as of Sept 28 with SMP enabled.
> 
> Thanks in advance.
> 
> Chad
> [EMAIL PROTECTED]
> 
You need to go to -current for this.

-lq


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Sv: mrtg, user-ppp

[Brian Somers]

[.]
> Looking into the code, no such accumulated timer exists.
> I either have to write a "proxy" querying ppp every 30 secs (faster than idle 
>timeout), accumulating the values for mrtg to query every 5 minutes, or modify ppp 
>itself. Perhaps a "pppctl show mrtg", giving output directly in the format mrtg 
>likes...
> 
> Leif

Hmm, something a bit more generic would be preferred (w/ patches ?).

There's an item on my TODO list that will allow ``display variable'' 
so that people can show the values of individual variables in a 
consistent way.  The possible values of ``variable'' will be 
documented - in much the same way as the output of ``show ...'' isn't.

The ultimate objective is to write a tcl based front end that will 
give you xload-style throughput graphs, connect/disconnect buttons, 
timeout slide bars etc.

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
     <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !  <[EMAIL PROTECTED]>




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: keeping termcap up to date

[Anders Andersson]

On Tis, Sep 21, 1999 at 12:58:37am +0900, Kazutaka YOKOTA wrote:
> I just wonder why don't we just import termcap database from
> the master site: http://www.tuxedo.org/terminfo, rather than
> maintaining our own copy?
> 
> In the past, it has been pointed out that some of the termcap entries
> needs updating.  Some entries have been revised.  But, it appears that
> some others haven't, and we are now getting out of sync with the
> latest version of the terminal database.
> 
> The simplest and the easiest thing to do is to just import
> the master copy from the above site...

This sounds great!

You can look at both NetBSD and OpenBSD for example how to merge it
since both use their termcap from ESR master. Although NetBSD is a bit
dated.

Best regards,

Anders
-- 
Anders Andersson[EMAIL PROTECTED]
Sanyusan International AB   http://www.sanyusan.se/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: How to prevent a system call from restart?

[Zhihui Zhang]

On Mon, 11 Oct 1999, Ruslan Ermilov wrote:

> On Sun, Oct 10, 1999 at 03:16:43PM -0400, Zhihui Zhang wrote:
> > 
> > I modify the day time client program from the Stevens' book and run it on
> > both a Sun workstation and a FreeBSD machine.  In the program, I use
> > signal() and alarm() to set a 5 seconds timeout.  The program works as
> > expected on Sun (after I comment out the daytime line in the file
> > /etc/inetd.conf) but not on the FreeBSD machine. 
> > 
> > Later I find out that the reason maybe the recvfrom() restarts
> > *automatically* in FreeBSD.  Why the default behaviour is different from
> > SunOS? If I am correct about the reason, can anyone tell me how to prevent
> > the recvfrom() from restart after receiving the SIGALRM signal? 
> > 
> > By the way, I also try the socket timeout option.  It works immediately.
> > 
> > Any help is appreciated.
> > 
> Refer to the siginterrupt(3) manpage, it has all info you are looking for.

Thanks! I add the following line after signal(), then it works:

(void) signal(SIGALRM, sig_alarm);
siginterrupt(SIGALRM, 1);   <-- only add this line.

-Zhihui




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

testable! Re: work in progress, (was Re: sbappend() is not scalable)

[Alfred Perlstein]

replying to my own message. :)

I have a newer version of the patch, it doesn't look like it's panic'ing
but it really needs some serious testing.

http://www.freebsd.org/~alfred/sockbuf4.diff

If you are running -current and know how to get a crashdump please
give this a whirl and tell me what it does for you.

thanks,
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
Wintelcom systems administrator and programmer
   - http://www.wintelcom.net/ [[EMAIL PROTECTED]]


On Mon, 11 Oct 1999, Alfred Perlstein wrote:

> 
> On Fri, 8 Oct 1999, Mohit Aron wrote:
> 
> > Hi,
> > I recently did some experiments with TCP over a high b/w-delay path
> > and found a scalability problem in sbappend(). The experimental setup
> > consisted of a 100Mbps network with a round-trip delay of 100ms. Under this
> > situation, FreeBSD's TCP version is incapable of attaining more than 65 Mbps
> > on a 300MHz Pentium II - even without slow-start.
> > 
> > I tracked down the problem to sbappend() - the routine that appends user data
> > into the socket buffers for network transmission. Every time a TCP ACK 
> > acknowledges some data, space is created in the socket buffer that permits
> > more data to be appended. Unfortunately, the implementation does not maintain
> > a pointer to the end of the list of mbufs in the socket buffer. Thus each 
> > time any data is added, the whole list of mbufs is traversed to reach the 
> > very end where the data is added. Since the b/w-delay product is large, there
> > can be about 600 mbufs in the socket buffer waiting to be acknowledged. Thus
> > upon every ACK, about 600 mbufs are traversed causing the TCP sender to run 
> > out of CPU.
> > 
> > The problem is not limited only to high b/w networks - it is also present in
> > long latency paths (satellite links). Thus a server transferring a large file
> > over a satellite link can spend lot of CPU due to the above problem.
> > 
> > Hope the problem shall be fixed in future releases,
> 
> I started work on this, addmittedly i'm pretty new to the uipc code
> and right now I have some work done towards this:
> 
> http://www.freebsd.org/~alfred/sockbuf3.diff
> 
> (pre green's socketbuf limiting stuff)
> 
> however it panics the box if you send a lot of data, a good way
> to have it blow up is to "ls -lR /" through telnet.  It's also
> pretty verbose with debug printfs.
> 
> It panics when tcp_output does an mcopy with invalid parameters, it
> seems that sb_mb is getting set to NULL somehow (my new sbcompress
> may be the culpret)
> 
> the reason i'm posting it is that i'm tired and and hoping to wake
> up with a email saying "here just fix line xxx of zzz" :)
> 
> the patches also address (or try to address) a flaw in the sbcompress() 
> function, right now it always tries to copy mbuf 'backwards' my patch
> tries to do a copy forward if it can.
> 
> personally i don't like sbcompress I'm interested in what people think
> about making it 'lazy' the algorithm would work like so:
> 
> on sbcompress, 
> walk the mbuf list free'ing empty bufs (already done)
> note any places where a copy would work to compress, but instead
> of compressing, just update a counter in the socketbuf.
> if sbcompress notices the that the amount of "fragmanentation"
> has exceeded a certain level then it will walk the entire
> socket compressing it and reset the counters.
> 
> It would also be interesting to vary how sbcompress works based
> on the amount of free mbufs in the system (using phk's 
> green/yellow/red state to determine what to do)
> 
> either way this would _really_ help with short lived sockets
> that are transmitting small amounts of data.
> 
> the only problem is that i'm not sure if it's ok to mess with
> the mbufs after they've been put into the socketbuffer because
> someone else my be holding a reference to it.
> 
> comments?
> 
> the patch also adds a whole lot of comments, and removes some
> useless casts and changes a lot of m = 0 to m = NULL.
> 
> And if anyone made it this far, :) do you happen to know what
> the #ifdef notyet along with mcopypack stuff is for?
> 
> -Alfred
> 
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Sv: mrtg, user-ppp

[Leif Neland]

- Original Message - 
From: Brian F. Feldman <[EMAIL PROTECTED]>
To: Leif Neland <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, October 10, 1999 3:49 PM
Subject: Re: mrtg, user-ppp


> On Sun, 10 Oct 1999, Leif Neland wrote:
> 
> > I'd like to plot uptime and number of calls from ppp to mrtg.
> > 
> > Any 'easy' way to ask ppp for these values, getting the answer for number
> > of seconds online since last asked?
> > 
> 
> Store the time from the previous call after each call, as with a
> (non-thread-safe) "static" variable in C.  You can accomplish reading the
> time up pretty reasonably using either pppctl or just working directly
> with the ppp socket in the program.

I can't seem to find an accumulated off-hook time. pppctl only lists the off-hook time 
of the last call. So 3 calls of one minute will only be shown as one minute when 
queryed by mrtg.
Looking into the code, no such accumulated timer exists.
I either have to write a "proxy" querying ppp every 30 secs (faster than idle 
timeout), accumulating the values for mrtg to query every 5 minutes, or modify ppp 
itself. Perhaps a "pppctl show mrtg", giving output directly in the format mrtg 
likes...

Leif


> 
> > Leif
> > 
> 
> -- 
>  Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
>  [EMAIL PROTECTED]`--'
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: file system system calls

[Zhihui Zhang]

On Mon, 11 Oct 1999, Gustavo V G C Rios wrote:

> May anyone here point me where in the source tree i can see file system
> API implemented, like open, write, close, etc.

Check files /sys/src/sys/kern/vfs_syscalls.c and
/sys/src/sys/kern/sys_generic.c

-Zhihui



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

work in progress, (was Re: sbappend() is not scalable)

[Alfred Perlstein]

On Fri, 8 Oct 1999, Mohit Aron wrote:

> Hi,
>   I recently did some experiments with TCP over a high b/w-delay path
> and found a scalability problem in sbappend(). The experimental setup
> consisted of a 100Mbps network with a round-trip delay of 100ms. Under this
> situation, FreeBSD's TCP version is incapable of attaining more than 65 Mbps
> on a 300MHz Pentium II - even without slow-start.
> 
> I tracked down the problem to sbappend() - the routine that appends user data
> into the socket buffers for network transmission. Every time a TCP ACK 
> acknowledges some data, space is created in the socket buffer that permits
> more data to be appended. Unfortunately, the implementation does not maintain
> a pointer to the end of the list of mbufs in the socket buffer. Thus each 
> time any data is added, the whole list of mbufs is traversed to reach the 
> very end where the data is added. Since the b/w-delay product is large, there
> can be about 600 mbufs in the socket buffer waiting to be acknowledged. Thus
> upon every ACK, about 600 mbufs are traversed causing the TCP sender to run 
> out of CPU.
> 
> The problem is not limited only to high b/w networks - it is also present in
> long latency paths (satellite links). Thus a server transferring a large file
> over a satellite link can spend lot of CPU due to the above problem.
> 
> Hope the problem shall be fixed in future releases,

I started work on this, addmittedly i'm pretty new to the uipc code
and right now I have some work done towards this:

http://www.freebsd.org/~alfred/sockbuf3.diff

(pre green's socketbuf limiting stuff)

however it panics the box if you send a lot of data, a good way
to have it blow up is to "ls -lR /" through telnet.  It's also
pretty verbose with debug printfs.

It panics when tcp_output does an mcopy with invalid parameters, it
seems that sb_mb is getting set to NULL somehow (my new sbcompress
may be the culpret)

the reason i'm posting it is that i'm tired and and hoping to wake
up with a email saying "here just fix line xxx of zzz" :)

the patches also address (or try to address) a flaw in the sbcompress() 
function, right now it always tries to copy mbuf 'backwards' my patch
tries to do a copy forward if it can.

personally i don't like sbcompress I'm interested in what people think
about making it 'lazy' the algorithm would work like so:

on sbcompress, 
walk the mbuf list free'ing empty bufs (already done)
note any places where a copy would work to compress, but instead
of compressing, just update a counter in the socketbuf.
if sbcompress notices the that the amount of "fragmanentation"
has exceeded a certain level then it will walk the entire
socket compressing it and reset the counters.

It would also be interesting to vary how sbcompress works based
on the amount of free mbufs in the system (using phk's 
green/yellow/red state to determine what to do)

either way this would _really_ help with short lived sockets
that are transmitting small amounts of data.

the only problem is that i'm not sure if it's ok to mess with
the mbufs after they've been put into the socketbuffer because
someone else my be holding a reference to it.

comments?

the patch also adds a whole lot of comments, and removes some
useless casts and changes a lot of m = 0 to m = NULL.

And if anyone made it this far, :) do you happen to know what
the #ifdef notyet along with mcopypack stuff is for?

-Alfred



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: multicast set TTL regarding...

[Luigi Rizzo]

>  all,
>I'm using the following call to set the ttl value (after doing a
> successful
> socket call)
> --
>  ttl=5;
>  if (setsockopt(sockfd, IPPROTO_IP, IP_MULTICAST_TTL,
> (char *)&ttl, sizeof(ttl)) < 0)

check the type of "ttl". On Unix it should be char;
on Windows it needs to be int. Some implementations can be more or less
tolerant on size mismatch

cheers
luigi


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

multicast set TTL regarding...

[Singuru RadhaKrishna]

 all,
   I'm using the following call to set the ttl value (after doing a
successful
socket call)
--
 ttl=5;
 if (setsockopt(sockfd, IPPROTO_IP, IP_MULTICAST_TTL,
(char *)&ttl, sizeof(ttl)) < 0)
 {
  printf("\nserv.c: setting of TTL value failed \n");
  perror("setsockopt");
  exit(1);
 }
-

It gives the following message :
--
serv.c: setting of TTL value failed
setsockopt: Invalid argument


I tried with "root" perms also. But it didn't help. I would be
thankful if any one can provide me some help on this.

PS: I'm not in this mailing list. Please mark a copy to
"[EMAIL PROTECTED]"



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Ukrainian locale & co

[Sergey Shkonda]

There is a ukrainian locale sources.
Can someone commit it ?


--
Sergey Shkonda   <[EMAIL PROTECTED]>

begin 644 ukrainian_locale.tgz
M'XL(`*N@`3@``^Q<6W,41Y;V*^=7E,&:!H\1=;_0C=A&$D@@)(UN-HQF/%7=
M5:A12ZWIBT#,Y;?8C/%ZQP'\A;77Q(1W'`8#LVSL@\,P$>N7C?6C7_=S"^S\IS*.E])HM6H#T:5U1.O[>.AV;KG.-IK&AUZ!ZH+
MS=-UW3),SW`TS=`=RWY-<_9S4NG1:C3#NJ:]5J_5FCNUN[84Q]6#F-#!'BWE
M_Y7E:JT45N/]"(0]^-_P=/*_:9E&W_\'<73YOQPVPY<'6S42S]T#$/77=O>UO^FI]N;S[]C
MN^A_UW7TUS3]9=[H=L<_N/]/O`G:F]K$U'!Q8O1=]K26U.K:_'(]K*Q6PE5M
MN5;QC[>TTE)8#TO-N*XUXJ9V=.;LL&D9P3'L?`)&)X>G1L8GSQTZ/#DU.7H8
M%HHSX\4S$Z/IT[TS&<`1.*+-+54:&OX_U$JUE95XM8FUQ8GIL>*A0[EB3CNN
MY2[GM%S(9S=RFGX]M+"(J"CI6*E?3Q(8GIJS;.7AH4^%2X5%1
MWII+.8'I^EIGLGF@J@5B&@F$7)5W^.:W-MO-14C7,\$SH3R;@S,3Q'1XO3N#9]!B&`]?"
MQ>(T+Z.:PJ'"UCV-:KW>7+B-W*7-MN7>7+B-UV70NK@T%7;MU,PBS5HZ=WLM?
MS/5JD5W^'BVT32]$UI;QT.;R9VNS77BA([NC2U=MM@LO=.1V=.FJS7;AA8Z\
MCBY=M=DNO-!1N:-+S]KVY8_U=FO[\I-U;BK[".+:;CZ!V**'.7T8T6STLF\^
MMF)_D?U_I_?_\+3ONOO__L>WOI')_TQ^_^M.__U_$,)006]JQ.'"D]F]W*3!&C;T]H6:BNWX=D076)209E#0IE#
MXK]8HO#CRA$R&[N:@B_;<:CW;!1LKDYF1^]LA,O&KNS]HM[T_`[#;(7$3L,8
MGMN,'OJ`W2VA]Q$M(_7MF1YG^E6K5:CI-]^3G`GK[_._3]SS1LM__][R".
M3O_OP^??O?C?LBR;OO_J3O_[[X$A&\SEB"UX\18KO3A#&,T'J@ZEQ:0O1U6%\G-*!<)S2A7"6TH,77
M-K3XVH%UOG9AG:\]*'-_'UJ,`:PSAC!']^U',,%8@K.,9:@RQC##F,`@W7>@
MPTE&`TXSFC#>(K0@X6L;&K0>@0,S-._`A=/DE\"#4P5"'X9.$08PR>U#&*?Y
M!1&,G",L@/]L#F*?U"4.8Y^L(6A1/80GF:3YA&:XP7PSK;$]@@=I'
M.#Y=1P:L4_L([Y_\'EEP:930A@6N=V"MC.,7]$CA/
M^TVL0Y'ZQ0:<831AF!&?/T;<;Q@=.,OHPCE&#\88?1AG#.`\8P@7&#'^&4MP
MD;$,DXPQ3#$F,$V8Z'"^2&C`#%^;,,MHP1RC#?.,#ERF^2_X9G6QWO?]?U^M]_#^0XDOY,]F@4EI:OA?4R?7A="YN5J!IKURK-):TX
M.SP^?HR_SKXQ7CZIM44'1L4;:*)ON9@U:EN9(]3JY1@W6^Q5JJTVZ[5J`PX5
M)N>'\H.#@_G"_.Q0'FU4A6>%V>FA_.OYQM[('S7?*IBS0\?R%@\1"/_)
M_&(^OUC(%TX5AO*G\H430Z>&\D/YT_G"<`U'*C9Y'EHI7*LTPRH<*G+GRS1\
MH8A-"V>H6*#B'!>C-#\Z&Z7B$EV.XW0+EP>H.,43+XR3;7R<&E!QGBXO4#%!
MQ44J)JF8HF*:BAG56:)W':`'6R=\+=.]U*F:(8T9:E:ODPA&:
M,ME:9)NGLWG5H$4-6A-40V?K9%NG5@MTMJ!:K;.-6BU04::Q1\84`UVT:"+S
M=#;/4Z*S=3I;6))6P_D.]P/H/]0/K/]0)K/\POV;]5U;Z#_-QUG^8A[/^PSR<]5^D]%^D
M]!_J']9]F*>RWL,\EG4=YJNLXQ*EXS#/9?V&NH+U&^H>UF^H$UB_83[->BM1
M.BY1^@WS9M9OF"^/U$5/L+Y#_5)FG>7#"-^?TG>HHUC?H0YA?8>ZA/4=ZA[6
M=ZBG6-^AOIKGZY+H.]1)K.]0)[&^0QVTGNJX*)TG>8
MUR\PKZOT'\Z/[A=UT@BM,^HDUG^HLUC_H9YB_8=ZBO4?ZC#6?ZB/6/^A7EK@
M>J7_4!>P_D,]POH/=3#K/]3!):5S6/^%2O^%2O^A'F+]A_IX2>DBUG^H@UG_
MH0YF_8:R@]UE1ZK*7T
M&.N_4.D_U.FL_U!?;2B]Q?H/=3GK/]1EK/]0=['^0WW&^@]U&^L_U&FL_X)8
M])^OB_[S#=%_@2OZSU?ZSU?Z+[!%__F6Z+_`$?WG^Z+__$#TGQ^*_O,CT7]^
M2?2?7Q;]Y\>B__Q$]%^0B/X+=-%_@2'Z+S!%_P66Z#]?Z3_?%/T7E$3_!9'H
M/]\3_1?XHO^"LNB_(!#]1]]-N%_X_TG_I;_^L__Z3_#L=#7RF]^6/OC+''G[^Z[K\^Y^ZZ3C]G_\>
MQ"'^;U96XOWZ[8\]^=]&SZ/_Z0-PW_\'<;3[?S]^^V-OS[]CT_EO]MDW[_R[$LHY__'\1!/][EMAIL PROTECTED][J366`M+
M<0/S^PTMBK6XT8A7FY6PJH5-K;F$%:MEK99HUZ]]F'7WP%#^[SR?V_PI,/GSR^_Q!/
M<$;W/J.;?TSW_"#WU>,O/_\WG.C?/KW_^!-F?.?=9(7^%&)@[.3`Q9,#LUQY
M/:TL#PZL#`YL<&4IK0RU@5@;B+2!=[2!2VP*5[`XVKQ64XX^!IK,=PT-\.`!
MG^,6$'=17&*6RQTND#O3*JM:F/FSCJ167Q&OW/OR/\DMG_^[>(4NR2V$Y!="
M<@PW^_P!`;F&D'U#)^0.2Y=?M_B.JC?R&R6_],E\CXC!!9;Q(B,R.R$^``C#C(K:=T@B,]$_O3
M9W?NOOR0$]S^0(.[MS6X^4R#I]]H\"WB73I_?Z>X=/[OP9;GY_\]F=;_`$)W7K`UJ$9W3O=W/?/;O]T7]_!T___OZ=9^\=5$YP
M]^[S_S]US;[
M_C^0H[?_6\OUP=(:_5[@X')4?M$Q=L[_+,\R4?^[GN?BJ6Z1_UW#Z/_]_X$<
M1[0?>N`[GW[ML!2N;M.@M-JL5]O:;X'8JK72,O_J:#G6M"AL8*DUEBI)<[.S
MNE)]>]G0?E,"@ZZ5_L(CC:BT+93F]/0=%)__07P;%>
M%/KV2ZTH.#J/2[-WI9FLE8*=;(J"H_.4-/MYKUGL8%,4%)V1D"HHQ]4,[&13
M%!2=2TUIU@RCKI%494^;HN#H_*U,]A<,Y9*1`<,-&.BS1J=-&V8*CLYK0O$V
M0]R,,F!:.E,X>K=-47!TQD(Q*A2KO\V`:?+PANUUVQ0%1V==*&;4C9@9,#R9
MA>5WVX3"Y.AL"L6)3=B=-L4!4=G
M2RCF)7S"Y0P8KE!81K=-47!T5H1BG$%%B0+3DB5QS&Z;HN"]LR844PR-BI8!
M4Q;!<*QNFZ+@O7--**9E.:MQ!@Q7G&HYW39%P='Y2Z'XG2QGV\O'-"4Z[:#;
M)@'.@9/[E5#\@>&*/%$*3$M\ZS"8PF3:?H:"SDMUKE"P6LW"3C9%0:S5$K_V
M]PQ"P0\1_:.%FOR[J+344HSC%$:M,4,#RY$=OJMBD*CLXEH1@3BK8-US0E+FR[VZ8H.#JO"L7Y7+?O
M#4]1F-TV1<'1N2P4%QC69:D4&)[LPE;0;5,4O'=6A6*"(4FT#!BNS$*>^7:;
MHN"],[]]&F*XKE#8W3:)3INC,]>6DK4U,^4%8C@JIE2$V1D*CL[?",4?>[U3
M=[`I"KK%JN35>P9%P=&Y*"/]7I93G*Y@)YNBX.B\(7+7A>(=!J53%)BR^QN.T6U3%!R=):$85J_EZQDP3?6,.-TV1<'1N2X4
M"W(C&ZL9,#QYV-G['39%P=$9"<49H9`A%!BN[%K\,'78%`5'YZI03*J-3\N`
M:4ITRC[5;A,*SCQR*T)Q49:S;<\V97C#<;MMBH*C4Q+L7*'G,R(>D3=2K^CD
MMZU*L'-#/9\160O'WY:"H_/$]DGR3C9%0=%9EY#?,R@*CLXWVY1`V^:VDTU1
MT$)711;O&10%1ZJ:#1:JQM72D*6NB05#QZ>Z^@*,C=R7*\@;*9
M`)4!`3Y;!+CI-4IU4M0(AD#F2BCX=<<4IE#80N$*A<^=3.DDD+E2%$9*(<,;
M,CPF/TP1<"=+.EG2,M#3*T5AIA0RO"'#XTN8P.;6I*BIDZTHC/1*45@IA0QO
MR/#X1#`%MR9%39T<16&F5XK"3BED>$.&QVR"*;@U*6KJ))"Y4A1.2B'#&S*\
M)?[!_9TZ>5IO4!1N2B'#FS*\)?[!_9U:^UIO4!1>2B'#FS*\)?[!/9=:!UIO
M4!2^HC!D>%.&M\0_N-O1;>M:;U`4`3]X'*][!J%@V=20FCV#HDBC$[?R]#O#
MKD&;9(HT.G$K3[\S[!H411J=N)6GWQEV#8HBC4[C
M78.B2*,3M_+TX]&N05&DT8E;>?KQ:->@*-+HQ*U;8/2B*=._$K3S](KAK
M$`H_W3MQ*T^_".X:%$4:G;B5IU\$=PV*(HU.W,K3[T^[!D5!T:F^[J0YP@X0
MU5A2*5`4%)WJ;;9GD"?5I^A\L<_'OOOB%&ET&K)IFK)I6O)6L;W,R[0;%,7F
MWBF;IOE_[5UM<]O(D<[7\%<(@@Q*-D0(E$0!ADR"HDUIO:0(FK8$FA"`W%YR
ME;K*)I5-JN[GW_1TSPM`&J8`E[/)8FPM3!#3F.GIZ9EY^E$O.LUS7%4N/&TQ
MW;Z0"+#.9L=^'ZSS[WB*?_:%1/!])^WJGGLA$="EGW_A[20]%T'[KX^(#];Y
MES_^X

More libpcap problems

[Reinier Bezuidenhout]

Hi ...

I have an application which uses libpcap ... after running for several
weeks normally .. the application coredumps .. I've traced the problem
back to libpcap which somehow reads garbage packet information (or is
given garbage). Here is a short view of the gdb ..

(gdb) p *(struct bpf_hdr *)pkt
$2 = {bh_tstamp = {tv_sec = 0, tv_usec = 0}, bh_caplen = 0, 
  bh_datalen = 4294922246, bh_hdrlen = 24577}
(gdb) p *pkt
$3 = {ts = {tv_sec = 0, tv_usec = 0}, caplen = 0, len = 4294922246}
(gdb)   

Take a look at the bh_datalen and bh_hdrlen ... those values are
not ok.  The only value which makes sense is the bh_caplen.  Should
I use that to determine if I should try and examine the packet ???

I've already had to make a change to libpcap where it got stuck
in and endless loop after receiving such "bad" data. (It has been
submitted in a PR)

Thanks
Reinier


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: How to prevent a system call from restart?

[Ruslan Ermilov]

On Sun, Oct 10, 1999 at 03:16:43PM -0400, Zhihui Zhang wrote:
> 
> I modify the day time client program from the Stevens' book and run it on
> both a Sun workstation and a FreeBSD machine.  In the program, I use
> signal() and alarm() to set a 5 seconds timeout.  The program works as
> expected on Sun (after I comment out the daytime line in the file
> /etc/inetd.conf) but not on the FreeBSD machine. 
> 
> Later I find out that the reason maybe the recvfrom() restarts
> *automatically* in FreeBSD.  Why the default behaviour is different from
> SunOS? If I am correct about the reason, can anyone tell me how to prevent
> the recvfrom() from restart after receiving the SIGALRM signal? 
> 
> By the way, I also try the socket timeout option.  It works immediately.
> 
> Any help is appreciated.
> 
Refer to the siginterrupt(3) manpage, it has all info you are looking for.

Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA of the
[EMAIL PROTECTED]United Commercial Bank,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.247.647Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message