RE: Path MTU discovery.
> > Just learning about this: I can see the advantages but does > anything use it? > > Sure, TCP uses it. > > TCP (at least in FreeBSD) sets the "don't frag" bit on all > its outgoing > packets. Good lord, so it does. Mental note, packet sniff before posting in future. So... thinking about what this means for firewalls and natd. If we block all incoming ICMP's across the firewall, it is quite possible that a server behind the firewall could completely fail to send packets to a client on a smaller MTU (modem user with MTU set to 576, for instance). Likewise natd would need to look at an incoming ICMP and if it's a "can't fragment" message, address translate it and send it onwards back to the IP that caused the error to happen. Hm. I'll hit the books. Return to the temple of Mr Stevens. Dave :) BTW, NT appears to set the DF flag too. If you cared. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
> I personally consider leaving the kernel module loadable intact after > boot to be a huge, huge security hole. Loadable modules... fine, but > once the machine goes multi-user I want to up the securelevel and > that disables any further kld operations. If one of the biggest > advantages of FreeBSD is its robustness and reliability, then one > generally does not want to go loading and unloading modules all the > time. > > A 'kerneld' like gizmo for FreeBSD would be a waste of time. The > scheme we have now -- having the utility programs load the modules > on the fly (ifconfig, vnconfig, etc...) works wonderfully. > Not to mention "how much memory do you really gain by unloading modules"? Considering the price of RAM these days (although not as low as it was, but I won't be spending $650 US for 16M any time soon again), the few K that unloading a bunch of modules saves won't EVER really be noticed by the 83Tb chunk that Nutscrape allocates. Excuse me, I must now think back to the dumbness achieved by people re-compiling Linux completely statically in hopes that it'll speed up their systems by not dynamically loading the libraries These were the same guys who wanted to unload modules to save kernel RAM... --mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
Mike Nowlin wrote: > > Not to mention "how much memory do you really gain by unloading modules"? > Considering the price of RAM these days (although not as low as > it was, but I won't be spending $650 US for 16M any time soon > again), the few K that unloading a bunch of modules saves won't > EVER really be noticed by the 83Tb chunk that Nutscrape allocates. > > Excuse me, I must now think back to the dumbness achieved by people > re-compiling Linux completely statically in hopes that it'll speed up > their systems by not dynamically loading the libraries These > were the same guys who wanted to unload modules to save kernel RAM... The issue is with really small ram embedded systems. Making things CAPABLE of being small is different from making them dynamicly loadable. > > --mike -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 ---> X_.---._/ presently in: Perth v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
3-Stable: Logging to syslog fails
Hi
I have a system running a stable snap of 3.4 of round about May 31,
I have a program that does quite a bit of logging, and sometime the
following occurs:
The process would just stop (seems to block) - a bt in gdb showed
that it was stuck in open after the following sequence of calls
syslog -> vsyslog -> open
After having a look at the code it seemed that the process was unable
to connect to syslogd and then continued to open the console (I have a
console configured on a serial line 9600 baud) and it got stuck in that open.
When I connected to the console, the log message was displayed.
On further inspection I saw that during the write of log info to syslog,
messages would stop appearing in the logfile in /var/log and ONLY be
displayed in the console. If nothing was connected to the console, it
would block and wait for ever.
Is this because of some buffer which is too small somewhere ?? that can
be changed ... or is this a bug ... or normal behaviour. e.g. What causes
the program not to be able to connect to write the log info ???
the sequence it seems to follow in libc's syslog.c
in the function vsyslog
Version 1.18.2.1
/* Get connected, output the message to the local logger. */
/*
* If the send() failed, the odds are syslogd was restarted.
* Make one (only) attempt to reconnect to /dev/log.
*/
/*
* Output the message to the console; don't worry about blocking,
* if console blocks everything will. Make sure the error reported
* is the one from the syslogd failure.
*/
And now it gets stuck in here
if (LogStat & LOG_CONS &&
(fd = open(_PATH_CONSOLE, O_WRONLY, 0)) >= 0) {
thanks
Reinier
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: kern/16318: Fix for wrong interface when adding new routes
This problem still affects the FreeBSD kernel in 4.0 and 5.0.
A patch file for 4.0-STABLE follows, I've tested this on 4.0-RELEASE and
4.0-STABLE (incl. SMP for what it's worth).
There is no difference between route.c at HEAD(5.0-current) and
RELENG_4(4.0-stable) so this patch should work effectively in both of
the aforementioned. And it does still fix my routing troubles.
--- route.c.origSat May 27 14:48:42 2000
+++ route.c Sat May 27 15:01:43 2000
@@ -400,6 +400,9 @@
struct sockaddr *dst, *gateway;
{
register struct ifaddr *ifa;
+ struct rtentry *rt;
+
+ ifa = 0;
if ((flags & RTF_GATEWAY) == 0) {
/*
* If we are adding a route to an interface,
@@ -408,7 +411,6 @@
* as our clue to the interface. Otherwise
* we can use the local address.
*/
- ifa = 0;
if (flags & RTF_HOST) {
ifa = ifa_ifwithdstaddr(dst);
}
@@ -425,18 +427,33 @@
if (ifa == 0)
ifa = ifa_ifwithnet(gateway);
if (ifa == 0) {
- struct rtentry *rt = rtalloc1(dst, 0, 0UL);
- if (rt == 0)
- return (0);
- rt->rt_refcnt--;
- if ((ifa = rt->rt_ifa) == 0)
- return (0);
+ rt = rtalloc1(dst, 0, 0UL);
+ if (rt) {
+ rt->rt_refcnt--;
+ if (rt->rt_ifa)
+ ifa = rt->rt_ifa;
+ }
}
- if (ifa->ifa_addr->sa_family != dst->sa_family) {
+ if ((ifa) && (ifa->ifa_addr->sa_family != dst->sa_family)) {
struct ifaddr *oifa = ifa;
ifa = ifaof_ifpforaddr(dst, ifa->ifa_ifp);
if (ifa == 0)
ifa = oifa;
+ }
+ /*
+* If we are adding a gateway, it is quite
+* possible that the routing table has a static
+* entry in place for the gateway, that may
+* not agree with the info from the interfaces.
+* The routing table should carry more precedence
+* than the interfaces in this matter.
+* Must be careful not to stomp on new entries from
+* rtinit, hence (ifa->ifa_addr !=gateway).
+*/
+ if ((ifa == 0 || ifa->ifa_addr != gateway) &&
+ (rt = rtalloc1(gateway,0,0UL))) {
+ rt->rt_refcnt--;
+ ifa = rt->rt_ifa;
}
return (ifa);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
syslog do not want to remote log
I have 2 machine's : A = Amnesiac B = ockle I want to remote log to ockle from Amnesiac Amnesiac : /etc/syslog.conf *.emerg * *.crit /var/log/crit *.err /var/log/errors *.info /var/log/all *.notice;kern.debug;lpr.info;mail.crit;news.err @ockle I started syslogd on Amnesiac with : syslogd -d and i get Logging to CONSOLE /dev/console 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 X WALL: 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 X FILE: /var/log/crit 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 X FILE: /var/log/errors 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 X FILE: /var/log/all 7 5 2 5 5 5 6 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 X UNUSED: logmsg: pri 56, flags 4, from Amnesiac, msg syslogd: restart Logging to FILE /var/log/all syslogd: restarted readfds = 0x38 NOTICE THE UNUSED Amnesiac do not want to use ockle - i tried specifying the i.p. of ockle but to no avail. ockle is in the hosts file on Amnesiac, a dns is present and specified in /etc/resolve.conf and it works. On ockle i started syslogd with -a and the i.p. of Amnesiac. But the problem is not here ( on ockle ), i first have to get syslogd on Amnesiac not to report UNUSED in debug mode ?? Any suggestions ?? -- E-Mail: Johan Kruger <[EMAIL PROTECTED]> Date: 08-Jun-00 Time: 10:56:22 This message was sent by XFMail -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IP prepaid accounting
On Wed 2000-06-07 (19:18), Poul-Henning Kamp wrote: > It should be possible to say say > >ipfw deny all ip from any to any exquota any > > as well as: > >ipfw deny all ip from any to any exquota guest How about: ipfw quota 1 config quota 10MB (and similar conversions as pipe for MB, Mb, kB, kb, &c.) ipfw quota 2 config quota 20MB (and similar conversions as pipe for MB, Mb, kB, kb, &c.) ipfw add quota 1 ip from any to any (add to quota 1's count) ipfw add quota 2 ip from any to any (add to quota 2's count) ipfw add allow ip from any to any uquota 1 (allow unhindered ip when under quota) ipfw add deny ip from any to any oquota 2 (deny ip when over high quota) ipfw add pipe 1 ip from any to any oquota 1 (dummynet ip when over low quota) Possibly also rules like: ipfw add pipe 1 ip from any to any oquota 1 uquota 2 (dummynet middle quota) ipfw add pipe 2 ip from any to any oquota 2 uquota 3 (get even slower) ipfw add deny ip from any to any oquota 3 (total stop) (allowing for slower and slower service instead of just two levels) Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IP prepaid accounting
sorry if i lost part of the discussion, but why dont you just associate a quota with a rule and specify one of the two possible results when exceeding quota: ipfw match-upto 20MB ipfw deny-above 20MB where the first syntax does not match when the rule's counters are above the quota, the second one denies the pkt when above quota. It looks of trivial implementation and rather easy to understand. You'd just need a new ipfw command to increase/decrease/set counters to a specific value rather than just zero them. cheers luigi ---+- Luigi RIZZO, [EMAIL PROTECTED] . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 ---+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Path MTU discovery.
On Thu, Jun 08, 2000 at 07:21:57PM +1200, Dave Preece wrote: > So... thinking about what this means for firewalls and natd. If we block all > incoming ICMP's across the firewall, it is quite possible that a server > behind the firewall could completely fail to send packets to a client on a > smaller MTU (modem user with MTU set to 576, for instance). Yes, that's correct -- The idea that ICMP is a separate and optional part of TCP/IP is fundamentally wrong. Blocking it unconditionally is a recipe for all kinds of hard-to-debug lossage around your firewall. Just Say No. - mark -- Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IP prepaid accounting
On Thu, 8 Jun 2000, Luigi Rizzo wrote: > sorry if i lost part of the discussion, but why dont you > just associate a quota with a rule and specify one of the > two possible results when exceeding quota: >ipfw match-upto 20MB >ipfw deny-above 20MB > where the first syntax does not match when the rule's counters > are above the quota, the second one denies the pkt when above quota. > It looks of trivial implementation and rather easy to understand. > You'd just need a new ipfw command to increase/decrease/set counters to > a specific value rather than just zero them. This is indeed true. Implementation would be simple. I'm not convinced that it would be easier to use, though: With the quotas being detached from the counters, they are easy to reference and check. It is also easier to assign traffic to combined quotas by seperate rules, which may or may not be desirable. Given that I implemented my proposal (together with phk's requested additions) already, the implementation triviality is not so much of an issue. In a nutshell: What I want is the functionality and I can offer to implement it myself. I want to have it in -CURRENT and -STABLE as soon as possible so that I do not have to bear with private patches, especially in the face of the change being relevant to both user mode programs and the kernel. If the original proposal and implementation is not good enough, I'll just do it again, but then I'd want you committers to agree that the change will be commited eventually 8) Thanks for your time, Hans -- finger [EMAIL PROTECTED] for details To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IP prepaid accounting
On Thu 2000-06-08 (11:43), Luigi Rizzo wrote: > sorry if i lost part of the discussion, but why dont you > just associate a quota with a rule and specify one of the > two possible results when exceeding quota: > >ipfw match-upto 20MB >ipfw deny-above 20MB > > where the first syntax does not match when the rule's counters > are above the quota, the second one denies the pkt when above quota. > > It looks of trivial implementation and rather easy to understand. > You'd just need a new ipfw command to increase/decrease/set counters to > a specific value rather than just zero them. Well, it may or may not be able to cover a situation I'm thinking about now: You have a server farm, or just a single machine with multiple IP addresses assigned to various jails, and you'd like them to be able to be able to be able to get anywhere. But, always allow traffic to and from a specific set of controlling machines, and also their owner company, and maybe a specified port for some form of VPN. If they exceed a first level of traffic, a dummynet rule kicks in slowing them down (alternate queueing system quite possibly too) just a bit, and as they break certain levels, slow them down more and more to non-specific sites. The specific sites may or may not contribute to the quota, but must remain available. Also, there may be a user account on the multi-user machine doing these rules who can log in to the base system to do certain forms of maintenance not easily available in the jail. Traffic caused by this person should also fall within the same quota. Further, a company may have two IP-based virtual hosts, or two or more servers in the server farm for some reason, sharing the same quota, and so forth. I just thought that: ipfw quota 1 config quota 20MB ipfw add quota 1 ipfw add quota 1 ipfw add quota 1 ipfw add allow ip from any to any uquota 1 ipfw add pipe 1 ip from any to any oquota 1 ... would be the extensible and more useful way of doing this, and most other IP-based quota systems. It also means you can set up your quotas, change the traffic numbers, change the match sets, all without changing your basic firewall rules. Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
4.0-Stable/XFree86-4.0/syscons switching crash
Hi all I am running 4.0-S on a Compaq Presario laptop with a Trident Cyberblade VGA. I couldn't get this to work in anything other than 640x480 with XFree86-3.3.6, so I moved to XFree86-4.0 (and no, I'm not interested in mail from people who say that the Trident Cyberblade works for them in 3.3.6; believe me, mine doesn't - I spent a week jumping through hoops with it before I gave up. If you were lucky enough to have xf86config or XF86Setup work for you with this chipset, I'm happy for you - but I had to hand-customise the XF86Config file extensively even to get 640x480 to work). Anyway, XFree86 4.0 works for me, except for a couple of glitches. The first one, which occurs sufficiently infrequently that I can live with it, is that sometimes when I kill X and return to text mode my Enter key gets remapped to Scroll Lock. Irritating in the extreme, but it doesn't happen consistently, just occasionally. Much more distressing: if I switch out of X to a text mode console with Ctrl-Alt-Fn, and then switch back to X, the machine freezes up completely and has to be power-cycled. It does first switch back into graphics mode, and I can see the top part of the screen is messed up, so it hasn't restored the low memory. Effectively this means once I'm in X, I need to stay in it, or kill it completely to get out (and hope my Enter key still works after that). Now, I'm not sure whether this is an XFree86 bug, and if so whether it is chipset-specific, or whether this is a syscons bug. I don't really know enough about either to really tackle it, but I'm prepared to make a stab at it - but I'd like to know where I should be looking. Should I be looking in the X sources, or the kernel sources? And whereabouts? Any pointers will be appreciated (no pun intended). TIA gram -- Dr Graham WheelerE-mail: [EMAIL PROTECTED] Director, Research and Development WWW:http://www.cequrux.com CEQURUX Technologies Phone: +27(21)423-6065 Firewalls/VPN SpecialistsFax:+27(21)424-3656 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.0-Stable/XFree86-4.0/syscons switching crash
Graham Wheeler wrote: > > > Much more distressing: if I switch out of X to a text mode console with > Ctrl-Alt-Fn, and then switch back to X, the machine freezes up > completely and has to be power-cycled. It does first switch back into > graphics mode, and I can see the top part of the screen is messed up, so > it hasn't restored the low memory. > I had similar problems. I removed splash_bmp from my loader.conf, splash screen/screen saver, and the problems has gone away for me. My would lockup if I tried to return to X from text after the delay time. Jim -- Studies show that 1 out of every 4 Americans suffer some form of mental illness. So look at your three best friends, if they are okay it is YOU! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IP prepaid accounting
> > sorry if i lost part of the discussion, but why dont you > > just associate a quota with a rule and specify one of the > > two possible results when exceeding quota: > > > >ipfw match-upto 20MB > >ipfw deny-above 20MB ... > Well, it may or may not be able to cover a situation I'm thinking about > now: ... it does, just use skipto rules to reach the final one where the quota is enforced, make it a "match-upto" rule, and follow it with a pipe (and match-upto the difference between first and second threshold, and so on...) cheers luigi ---+- Luigi RIZZO, [EMAIL PROTECTED] . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 ---+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.0-Stable/XFree86-4.0/syscons switching crash
James Housley wrote: > > Graham Wheeler wrote: > > > > Much more distressing: if I switch out of X to a text mode console with > > Ctrl-Alt-Fn, and then switch back to X, the machine freezes up > > completely and has to be power-cycled. It does first switch back into > > graphics mode, and I can see the top part of the screen is messed up, so > > it hasn't restored the low memory. > > > I had similar problems. I removed splash_bmp from my loader.conf, > splash screen/screen saver, and the problems has gone away for me. My > would lockup if I tried to return to X from text after the delay time. Jim When you say you removed it, do you mean you removed the line entirely, or that you set it to NO? Mine is currently set to NO, so I'm not sure the problem is the same as yours. g. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Path MTU discovery.
And fbsd will respond to other's queries depending on interface mtus only be careful if you are running natd. This copies the interface mtu on startup but does not learn the new value if it is reduced either manually or automatically. It can therefore respond with a to a query with a value that is still unusable. Jim Flowers <[EMAIL PROTECTED]> #4 ISP on C|NET, #1 in Ohio On Thu, 8 Jun 2000, Kenneth D. Merry wrote: > On Thu, Jun 08, 2000 at 18:03:45 +1200, Dave Preece wrote: > > Just learning about this: I can see the advantages but does anything use it? > > Sure, TCP uses it. > > TCP (at least in FreeBSD) sets the "don't frag" bit on all its outgoing > packets. > > If the packet gets to a router with an outgoing MTU that is too small to > hold the packet without fragmentation, the router is supposed to send back > and ICMP message telling the source machine to use a smaller packet size. > > When the source machine receives the ICMP message, it will update the MTU > for that route, and try sending packets out again with the lower MTU. > > Ken > -- > Kenneth Merry > [EMAIL PROTECTED] > > > 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: 4.0-Stable/XFree86-4.0/syscons switching crash
James Housley wrote: > > Graham Wheeler wrote: > > > > James Housley wrote: > > > > > > Graham Wheeler wrote: > > > > > > > > Much more distressing: if I switch out of X to a text mode console with > > > > Ctrl-Alt-Fn, and then switch back to X, the machine freezes up > > > > completely and has to be power-cycled. It does first switch back into > > > > graphics mode, and I can see the top part of the screen is messed up, so > > > > it hasn't restored the low memory. > > > > > > > I had similar problems. I removed splash_bmp from my loader.conf, > > > splash screen/screen saver, and the problems has gone away for me. > I removed in and unloaded the module, the saver_ modules might do the > same thing. I have removed my screen saver and my console fonts, and the problem still occurs, unfortunately. g. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_dc in v4.0 - Forcing store and forward?
At 10:48 PM 6/7/00 -0700, W Gerald Hicks wrote: >Peter Wemm wrote: > >> I suspect a generic chipset fault, or some design quirk that we are not >> working around. Note that the windoze drivers for these devices put them >> permanently in store-and-forward mode. if_de has the exact same problem on >> all of the systems above. Well we never saw these problems in v3.4...so what changed? DB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: syslog do not want to remote log
On Thu, 8 Jun 2000, Johan Kruger wrote: > I started syslogd on Amnesiac with : syslogd -d and i get > > Logging to CONSOLE /dev/console > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 X WALL: > 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 X FILE: /var/log/crit > 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 X FILE: /var/log/errors > 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 X FILE: /var/log/all > 7 5 2 5 5 5 6 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 X UNUSED: > logmsg: pri 56, flags 4, from Amnesiac, msg syslogd: restart > Logging to FILE /var/log/all > syslogd: restarted > readfds = 0x38 > > NOTICE THE UNUSED > Amnesiac do not want to use ockle - i tried specifying the i.p. of ockle > but to no avail. ockle is in the hosts file on Amnesiac, a dns is present > and specified in /etc/resolve.conf and it works. Try setting the hostname of the machine first -- syslog might be having trouble figuring out which interface touse. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Path MTU discovery.
> > > Just learning about this: I can see the advantages but does
> > anything use it?
> >
> > Sure, TCP uses it.
> >
> So... thinking about what this means for firewalls and natd. If we block all
> incoming ICMP's across the firewall
The moral of the story is don't block *ALL* incoming ICMP's across the
firewall. :)
Something like:
/sbin/ipfw add 1000 pass icmp from any to any via ${netif} icmptypes 0,3,11
Works for me, although you may not want type 11 packets coming in. (I
allow them in, so I can run traceroute);
Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: SVR4 Emulation [was Re: iBCS status?]
In article <[EMAIL PROTECTED]>, Dan Nelson <[EMAIL PROTECTED]> wrote: > But isn't there some SVR4 ABI standard that says "you must implement > these syscalls and these ioctls this way", etc? I'm sure the ABI > explicitly says what lseek() takes for arguments, for example. The SVR4 ABI specification doesn't say anything about system calls -- it just specifies what libc has to provide. (Actually in my old printed copy of the spec, they call the system interface library "libsys".) The library has to provide a certain kind of lseek(), for example, but the ABI standard says nothing about how that is implemented lower down. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SVR4 Emulation [was Re: iBCS status?]
In the last episode (Jun 08), John Polstra said: > > But isn't there some SVR4 ABI standard that says "you must implement > > these syscalls and these ioctls this way", etc? I'm sure the ABI > > explicitly says what lseek() takes for arguments, for example. > > The SVR4 ABI specification doesn't say anything about system calls -- > it just specifies what libc has to provide. (Actually in my old > printed copy of the spec, they call the system interface library > "libsys".) The library has to provide a certain kind of lseek(), for > example, but the ABI standard says nothing about how that is > implemented lower down. Hmm. So does this mean that SVR4-compliant programs must be dynamically-linked? Is there any recommendations on how an OS should supply an SVR4 libc to an SVR4 application when the OS itself may not be SVR4-compliant? And this doesn't address any libraries other than libc, I suppose? Sounds like trying to emulate "SVR4" in itself isn't sufficient. We can still call the kld svr4.ko, but it's really doing SCO/SolarisX86 syscall emulation. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SVR4 Emulation [was Re: iBCS status?]
In article <[EMAIL PROTECTED]>, Dan Nelson <[EMAIL PROTECTED]> wrote: > > Hmm. So does this mean that SVR4-compliant programs must be > dynamically-linked? Yes. The specification says that statically-linked programs are not compliant. > Is there any recommendations on how an OS should supply an SVR4 libc > to an SVR4 application when the OS itself may not be SVR4-compliant? Theoretically, you wouldn't need any kernel-level emulation at all if you provided the right libc. But of course it's not really SVR4 you want to emulate -- it's UnixWare or OpenServer or something else that has lots of extra interfaces which are outside the ABI specification. Overall I think it's easier to use the vendor's libraries and do the emulation at the kernel level, as we do now. > And this doesn't address any libraries other than libc, I suppose? Right. > Sounds like trying to emulate "SVR4" in itself isn't sufficient. We > can still call the kld svr4.ko, but it's really doing SCO/SolarisX86 > syscall emulation. Yep. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ACE wrappers woes on 4.x-stable (pthreads)
hi, there! can someone take a look at this? seems that it's a flaw in 4.x pthreads implementation under RELENG_3 everything works fine, haven't tried this on -current i'm totally lost at this point -- Forwarded message -- Date: Thu, 8 Jun 2000 09:07:54 -0500 (CDT) From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: [Bug 581] Changed - Reactor_Exceptions test dumps core http://ace.cs.wustl.edu/bugzilla/show_bug.cgi?id=581 *** shadow/581 Thu Jun 8 02:00:11 2000 --- shadow/581.tmp.6697 Thu Jun 8 09:07:54 2000 *** *** 128,130 --- 128,135 lark:~/ACE_wrappers/tests$ --- cut here --- + + --- Additional Comments From [EMAIL PROTECTED] 2000-06-08 09:07 --- + My guess is a platform problem. We don't see this + on any other platform. Sorry we can't be of any + more help. /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ACE wrappers woes on 4.x-stable (pthreads)
|hi, there! | |can someone take a look at this? |seems that it's a flaw in 4.x pthreads implementation |under RELENG_3 everything works fine, haven't tried this on -current |i'm totally lost at this point Multithreaded C++ exceptions have been broken since about August '99. Use the macros if you need exceptions with ACE/TAO. Russell | |-- Forwarded message -- |Date: Thu, 8 Jun 2000 09:07:54 -0500 (CDT) |From: [EMAIL PROTECTED] |Reply-To: [EMAIL PROTECTED] |To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] |Subject: [Bug 581] Changed - Reactor_Exceptions test dumps core | |http://ace.cs.wustl.edu/bugzilla/show_bug.cgi?id=581 | |*** shadow/581 Thu Jun 8 02:00:11 2000 |--- shadow/581.tmp.6697Thu Jun 8 09:07:54 2000 |*** |*** 128,130 |--- 128,135 | lark:~/ACE_wrappers/tests$ | --- cut here --- | |+ |+ --- Additional Comments From [EMAIL PROTECTED] 2000-06-08 09:07 --- |+ My guess is a platform problem. We don't see this |+ on any other platform. Sorry we can't be of any |+ more help. | |/fjoe | | | |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
Comments on Athlon [motherboards] sought..
I'm considering buying an Athlon based machine. Before shelling out the $ (well, fl ) I'd like to know what experiences have with Athlon and FreeBSD. And obviously which mom boards to prefer or keep away from. Thks Wilko -- Wilko Bulte FreeBSD, the power to serve http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Comments on Athlon [motherboards] sought..
fl == Florins? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
rlist.h !!! help !!!
I have several programs that use rlist.h (for various reasons ) and I cannot find it in FreeBSD 4.0 ! (mainly for swap info ) Has it been droped ? I know that the kernel/sys/rlist.h has been droped but does affect the /usr/include/sys/rlist.h ? If it has been dropped what do I use instead ??? thank you nathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Comments on Athlon [motherboards] sought..
On 08-Jun-00 Wilko Bulte wrote: > I'm considering buying an Athlon based machine. Before shelling out the > $ (well, fl ) I'd like to know what experiences have with Athlon and > FreeBSD. And obviously which mom boards to prefer or keep away from. > > Thks > Wilko I have good experiences so far with the Athlon stuff. However (sad to say) avoid the Asus MB if you need to reboot without a keyboard attached. So far I like the FIC and Aopen boards. Nicole > > -- > Wilko Bulte FreeBSD, the power to serve http://www.freebsd.org > http://www.nlfug.nl > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message [EMAIL PROTECTED] |\ __ /| (`\ http://www.unixgirl.com/ [EMAIL PROTECTED] | o_o |__ ) ) http://www.dangermouse.org/ // \\ ---(((---(((- -- Powered by Coka-Cola and FreeBSD -- -- Strong enough for a man - But made for a Woman -- -- OWNED? MS: Who's Been In/Virused Your Computer Today? -- --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Comments on Athlon [motherboards] sought..
On Thu, Jun 08, 2000 at 11:57:25AM -0700, Matthew Jacob wrote: > > fl == Florins? Yep! -- Wilko Bulte FreeBSD, the power to serve http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_dc in v4.0 - Forcing store and forward?
> > I suspect a generic chipset fault, or some design quirk that we are not > > working around. Note that the windoze drivers for these devices put them > > permanently in store-and-forward mode. if_de has the exact same problem on > > all of the systems above. ... > Store and forward mode introduces a horrible performance hit... Artesyn > wouldn't show us the source to their workaround :-( It should be noted that I was able to saturate a 100 Mbps Ethernet with FreeBSD 2.2 and a 21140 based card, using around 56% of the CPU of a PPro-200. This was done almost exactly three years ago, using the (then) standard if_de driver. I have no idea whether the card was operating in store-and-forward mode or not - but the performance was perfectly fine. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ACE wrappers woes on 4.x-stable (pthreads)
hi, there! On Thu, 8 Jun 2000, Russell L. Carter wrote: > |can someone take a look at this? > |seems that it's a flaw in 4.x pthreads implementation > |under RELENG_3 everything works fine, haven't tried this on -current > |i'm totally lost at this point > > Multithreaded C++ exceptions have been broken since about August '99. > Use the macros if you need exceptions with ACE/TAO. That's not a solution for me -- I want to port some app that uses ACE + TAO and does not use ACE exceptions macros. btw TAO/tests/Native_Exceptions_Test and that app work fine for me. however the Reactor_Exceptions_Test fails (SIGSEGV with stack smashed) and this makes me nervious. /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Comments on Athlon [motherboards] sought..
It seems Nicole Harrington. wrote: > > On 08-Jun-00 Wilko Bulte wrote: > > I'm considering buying an Athlon based machine. Before shelling out the > > $ (well, fl ) I'd like to know what experiences have with Athlon and > > FreeBSD. And obviously which mom boards to prefer or keep away from. > > > > Thks > > Wilko > > I have good experiences so far with the Athlon stuff. However (sad to say) > avoid the Asus MB if you need to reboot without a keyboard attached. What ? I have no probs whatsoever with my K7M doing that... > So far I like the FIC and Aopen boards. Dont _ever_ buy FIC, there are no ends of trouble with them -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
subscribe
To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ACE wrappers woes on 4.x-stable (pthreads)
It seems Max Khon wrote: > hi, there! > > On Thu, 8 Jun 2000, Russell L. Carter wrote: > > > |can someone take a look at this? > > |seems that it's a flaw in 4.x pthreads implementation > > |under RELENG_3 everything works fine, haven't tried this on -current > > |i'm totally lost at this point > > > > Multithreaded C++ exceptions have been broken since about August '99. > > Use the macros if you need exceptions with ACE/TAO. > > That's not a solution for me -- I want to port some app that uses ACE + > TAO and does not use ACE exceptions macros. > btw TAO/tests/Native_Exceptions_Test and that app work fine for me. > however the Reactor_Exceptions_Test fails (SIGSEGV with stack smashed) > and this makes me nervious. Totally unrelated but I'm currently wrestling a very semilar looking problem with gcc-2.95.2 on (cough) AIX43. It seems that gcc has problems with exceptions on at least AIX and HPUX, it could be the same problem that is biting here... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ACE wrappers woes on 4.x-stable (pthreads)
hi, there! On Fri, 9 Jun 2000, Max Khon wrote: > > Multithreaded C++ exceptions have been broken since about August '99. > > Use the macros if you need exceptions with ACE/TAO. > > That's not a solution for me -- I want to port some app that uses ACE + > TAO and does not use ACE exceptions macros. > btw TAO/tests/Native_Exceptions_Test and that app work fine for me. > however the Reactor_Exceptions_Test fails (SIGSEGV with stack smashed) > and this makes me nervious. forgot to add: I need pointers to start digging around /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Comments on Athlon [motherboards] sought..
I *LOVE* my Tyan S2380 K7 Trinity MB. = -Chris Watson (316) 326-3862 | FreeBSD Consultant, FreeBSD Geek Work: [EMAIL PROTECTED] | Open Systems Inc., Wellington, Kansas Home: [EMAIL PROTECTED] | http://open-systems.net = WINDOWS: "Where do you want to go today?" LINUX: "Where do you want to go tommorow?" BSD: "Are you guys coming or what?" = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ACE wrappers woes on 4.x-stable (pthreads)
| |forgot to add: I need pointers to start digging around It might be interesting to trace through libgcc_r. Russell | |/fjoe | | | |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: It's worth !
A site that pays you to receive some e-mails. No more than that. Nothing to buy, just to receive the e-mail and click on the link to visit the site. Don't you believe it exists ? Yes, it exists. And I have already received a US$ 50,00 check. Will you say that you don't want some money ? It's up to you to subscribe and start receiving e-mails and money ! Follow the link: http://www.sendmoreinfo.com/id/871883 See you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Stupid Bonzi program
Please accept my sincere apologies for sending this mail, I at least thought that the program would give a conformation of the addresses sent to. Apologies Steve. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Path MTU discovery.
Dave Preece wrote: > > > > Just learning about this: I can see the advantages but does > > anything use it? > > > > Sure, TCP uses it. > > > > TCP (at least in FreeBSD) sets the "don't frag" bit on all > > its outgoing > > packets. > > Good lord, so it does. Mental note, packet sniff before posting in future. > > So... thinking about what this means for firewalls and natd. If we block all > incoming ICMP's across the firewall That's a no-no. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Comments on Athlon [motherboards] sought..
Wilko Bulte wrote: > > I'm considering buying an Athlon based machine. Before shelling out the > $ (well, fl ) I'd like to know what experiences have with Athlon and > FreeBSD. And obviously which mom boards to prefer or keep away from. EPoX == trash. Avoid like the plague. ASUS K7v == good. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD Support of Hot Swappable NICs
Mike Smith wrote: > > Actually, there's still a *lot* of work that has to be done to make this > work "right" - let me say two things only: > > "resource allocation" > > "interrupt routing" And that's just the start. When it comes to network interfaces, trying to unthread them from the system in a small, fixed amount of time like will be required for hot-eject on CPCI, CardBus, etc., is really fugly. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Comments on Athlon [motherboards] sought..
On 08-Jun-00 Soren Schmidt wrote: > It seems Nicole Harrington. wrote: >> >> On 08-Jun-00 Wilko Bulte wrote: >> > I'm considering buying an Athlon based machine. Before shelling out the >> > $ (well, fl ) I'd like to know what experiences have with Athlon and >> > FreeBSD. And obviously which mom boards to prefer or keep away from. >> > >> > Thks >> > Wilko >> >> I have good experiences so far with the Athlon stuff. However (sad to say) >> avoid the Asus MB if you need to reboot without a keyboard attached. > > What ? I have no probs whatsoever with my K7M doing that... > Hmmm.. We got these new ones in a red box.. The bios doesn't have a "ignore no Key/mouse" :( It is one of there newer boards. >> So far I like the FIC and Aopen boards. > > Dont _ever_ buy FIC, there are no ends of trouble with them > So far I have had good luck with them... strangly enough. > -Søren [EMAIL PROTECTED] |\ __ /| (`\ http://www.unixgirl.com/ [EMAIL PROTECTED] | o_o |__ ) ) http://www.dangermouse.org/ // \\ ---(((---(((- -- Powered by Coka-Cola and FreeBSD -- -- Strong enough for a man - But made for a Woman -- -- OWNED? MS: Who's Been In/Virused Your Computer Today? -- --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SVR4 Emulation [was Re: iBCS status?]
On Thu, Jun 08, 2000 at 12:05:25PM -0500, Dan Nelson wrote: > Is there any recommendations on how an OS should > supply an SVR4 libc to an SVR4 application when the OS itself may not > be SVR4-compliant? That's what /compat/svr4 is for :-) > Sounds like trying to emulate "SVR4" in itself isn't sufficient. We > can still call the kld svr4.ko, but it's really doing SCO/SolarisX86 > syscall emulation. It is possible to reimplement libc and any/every other library that a SysV application would want, but that isn't happening at any time soon. That means we really need to put the syscall mappings into the svr4.ko module as we do at the moment, but perhaps put the syscall# -> syscall() mappings into separate modules (solaris.ko, sco.ko, unixware.ko, etc). - mark -- Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD Support of Hot Swappable NICs
With all the talk about adding support for hot plugging items into the system. Would it make sense to utilize Apple's work with IOKit in FreeBSD ? I know that this could be a BIG project- but why reproduce what apple is giving away ? It looks to be a really nice driver architecture. Would the APSL license stand in the way ??? I think that it would be mutually beneficial - Apple's Intel effort would acquire drivers by the boatload and the BSD community would have one cool driver development framework. Would the BSD community support such a project More information is available here for the interested. OS X Kernel - http://developer.apple.com/techpubs/macosx/System/Documentation/Developer/Kernel/KernelEnvironment.pdf IOKit - http://developer.apple.com/techpubs/macosx/System/Documentation/Developer/Kernel/Tutorials/2-HelloIOKit.pdf David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Comments on Athlon [motherboards] sought..
On Thursday, 8 June 2000 at 17:33:13 -0600, Wes Peters wrote: > Wilko Bulte wrote: >> >> I'm considering buying an Athlon based machine. Before shelling out the >> $ (well, fl ) I'd like to know what experiences have with Athlon and >> FreeBSD. And obviously which mom boards to prefer or keep away from. > > EPoX == trash. Avoid like the plague. Buy EPoX. They're good. > ASUS K7v == good. ASUS K7v == slow. I don't think that categorical statements like these help very much. I know you've had trouble with your EPoX boards, but you didn't ever find out whether this was a setup problem or a problem with the board. I had some setup problems with my EPoX board when I bought it, the dreaded: May 3 08:00:02 wantadilla /kernel: microuptime() went backwards (65202.831743 -> 65202,804412) I removed (not just disabled) apm from the kernel, and I haven't seen the problem since. In fact, I have had absolutely no problems. The fact that a disabled apm system can make a difference suggests that this isn't just a problem with the motherboard. A number of others have reported the same thing on this motherboard. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Comments on Athlon [motherboards] sought..
On Thu, 8 Jun 2000, Wes Peters wrote: > Wilko Bulte wrote: > > > > I'm considering buying an Athlon based machine. Before shelling out the > > $ (well, fl ) I'd like to know what experiences have with Athlon and > > FreeBSD. And obviously which mom boards to prefer or keep away from. > > ASUS K7v == good. I second that, I got one last week and its working great. The only thing odd about it is temperature monitors all report it being at 255C. Other than that its working well. Luke To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Processes, context switching in kernel...
All, I'm working on the emulator for OSF1/Mach for FreeBSD/Alpha, and I need some help understanding how to do some things in the FreeBSD kernel--if anyone can answer any of the following questions, it would be greatly appreciated: 1) How do you create a process in the kernel (i.e., you fork in user-space...what's the analogue for kernel-space)? 2) How do you clone a process in kernel-space (i.e., in user-space, you would fork and then share the entire process's memory space--how would you do such a thing in kernel-space)? 3) What needs to be done to perform a context switch (from within the kernel), and are there any MP considerations when doing this? 4) In what files do the proc and the u-area structures reside? Thanks, Andrew Miklic To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Comments on Athlon [motherboards] sought..
On Thursday, 8 June 2000 at 21:00:22 -0400, Luke wrote: > On Thu, 8 Jun 2000, Wes Peters wrote: >> Wilko Bulte wrote: >>> >>> I'm considering buying an Athlon based machine. Before shelling out the >>> $ (well, fl ) I'd like to know what experiences have with Athlon and >>> FreeBSD. And obviously which mom boards to prefer or keep away from. >> >> ASUS K7v == good. > > I second that, I got one last week and its working great. > The only thing odd about it is temperature monitors all report it being > at 255C. Other than that its working well. This looks like a software bug. 255°C is hotter than is possible, and it's also "all bits on" in a single byte. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD Support of Hot Swappable NICs
Wes Peters wrote: > > Mike Smith wrote: > > > > Actually, there's still a *lot* of work that has to be done to make this > > work "right" - let me say two things only: > > > > "resource allocation" > > > > "interrupt routing" > > And that's just the start. When it comes to network interfaces, trying > to unthread them from the system in a small, fixed amount of time like > will be required for hot-eject on CPCI, CardBus, etc., is really fugly. Maybe it can be solved in two steps: 1. When the card is physically removed inform the driver that it should shut down and don't try to get to the card afterwards. That means it would handle some subset of configuration requests and delay or throw away any data transfer requests. 2. Later take any neccessary amount of time to clean up the things. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Processes, context switching in kernel...
> All, > > I'm working on the emulator for OSF1/Mach for FreeBSD/Alpha, and I need > some help understanding how to do some things in the FreeBSD kernel--if anyone > can answer any of the following questions, it would be greatly appreciated: > > 1) How do you create a process in the kernel (i.e., you fork in > user-space...what's the analogue for kernel-space)? > fork1(), see kern_fork.c > 2) How do you clone a process in kernel-space (i.e., in user-space, you would > fork and then share the entire process's memory space--how would you do such a > thing in kernel-space)? > fork1() with RFMEM flag. > 3) What needs to be done to perform a context switch (from within the kernel), > and are there any MP considerations when doing this? > Do the following, s = splhigh(); setrunqueue(p); p->p_stats->p_ru.ru_nivcsw++; mi_switch(); splx(s); nothing special for MP yet, but that's going to change soon... > 4) In what files do the proc and the u-area structures reside? > If you mean header files, they are and . > Thanks, > Andrew Miklic > -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
> Mike Nowlin wrote: > > > > > Not to mention "how much memory do you really gain by unloading modules"? > > Considering the price of RAM these days (although not as low as > > it was, but I won't be spending $650 US for 16M any time soon > > again), the few K that unloading a bunch of modules saves won't > > EVER really be noticed by the 83Tb chunk that Nutscrape allocates. ... > The issue is with really small ram embedded systems. > Making things CAPABLE of being small is different from making > them dynamicly loadable. Nobody in their right mind is going to produce a "really small ram" embedded system that features the sort of nondeterminism that "automatically" (read 'randomly') unloading modules would involve. It's simple; a kernel-module-handling-daemon does not have anything to offer us at this time. We don't need one; the problems it might be applied to solve have already been solved differently, and we are (generally) happy with the results. -- \\ 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: 4.0-Stable/XFree86-4.0/syscons switching crash
>I am running 4.0-S on a Compaq Presario laptop with a Trident Cyberblade >VGA. I couldn't get this to work in anything other than 640x480 with >XFree86-3.3.6, so I moved to XFree86-4.0 (and no, I'm not interested in >mail from people who say that the Trident Cyberblade works for them in >3.3.6; believe me, mine doesn't - I spent a week jumping through hoops >with it before I gave up. If you were lucky enough to have xf86config or >XF86Setup work for you with this chipset, I'm happy for you - but I had >to hand-customise the XF86Config file extensively even to get 640x480 to >work). > >Anyway, XFree86 4.0 works for me, except for a couple of glitches. The >first one, which occurs sufficiently infrequently that I can live with >it, is that sometimes when I kill X and return to text mode my Enter key >gets remapped to Scroll Lock. Irritating in the extreme, but it doesn't >happen consistently, just occasionally. The cause of this is most likely that the X server failed to restore the keyboard mode (K_RAW to K_XLATE) when it's got killed. Try using the kbd_mode program that comes with XFree86. Run vidcontrol -s N-1 < /dev/ttyv0; kbd_mode -a < /dev/ttyvN (where N is the vty from which you started X) as root. For example, if you run `startx' in /dev/ttyv3, you should type: vidcontrol -s 4 < /dev/ttyv0; kbd_mode -a < /dev/ttyv3 >Much more distressing: if I switch out of X to a text mode console with >Ctrl-Alt-Fn, and then switch back to X, the machine freezes up >completely and has to be power-cycled. Does the machine respond to ping from another machine on the network? >It does first switch back into >graphics mode, and I can see the top part of the screen is messed up, so >it hasn't restored the low memory. Um, this sounds more like a bug in the X server. syscons does nothing to set up the graphics mode for the X server. It is entirely up to the X server to properly initialize the video chip set. The only thing syscons does when you switching back X is to tell the X server that the X server may now have the full access to the video card... Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ACE wrappers woes on 4.x-stable (pthreads)
hi, there! On Thu, 8 Jun 2000, Soren Schmidt wrote: > > > |can someone take a look at this? > > > |seems that it's a flaw in 4.x pthreads implementation > > > |under RELENG_3 everything works fine, haven't tried this on -current > > > |i'm totally lost at this point > > > > > > Multithreaded C++ exceptions have been broken since about August '99. > > > Use the macros if you need exceptions with ACE/TAO. > > > > That's not a solution for me -- I want to port some app that uses ACE + > > TAO and does not use ACE exceptions macros. > > btw TAO/tests/Native_Exceptions_Test and that app work fine for me. > > however the Reactor_Exceptions_Test fails (SIGSEGV with stack smashed) > > and this makes me nervious. > > Totally unrelated but I'm currently wrestling a very semilar looking > problem with gcc-2.95.2 on (cough) AIX43. It seems that gcc has problems > with exceptions on at least AIX and HPUX, it could be the same problem > that is biting here... RELENG_3 does not have the problem I'm trying to hunt (with gcc 2.95.2 built from ports) /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_dc in v4.0 - Forcing store and forward?
> At 10:48 PM 6/7/00 -0700, W Gerald Hicks wrote: > >Peter Wemm wrote: > > > >> I suspect a generic chipset fault, or some design quirk that we are not > >> working around. Note that the windoze drivers for these devices put them > >> permanently in store-and-forward mode. if_de has the exact same problem on > >> all of the systems above. > > Well we never saw these problems in v3.4...so what changed? Either the driver changed, or your hardware. As I've already pointed out, if your BIOS or board arrangement changed, all bets are off. As for the driver code, you have the CVS repo, go look for yourself. (Note: I have a number of systems using these devices, and I can't recall how long it's been since I saw a transmit underrun. It's not an intrinsic feature of the device or driver, it has to be an interaction issue.) -- \\ 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: 4.0-Stable/XFree86-4.0/syscons switching crash
>> Much more distressing: if I switch out of X to a text mode console with >> Ctrl-Alt-Fn, and then switch back to X, the machine freezes up >> completely and has to be power-cycled. It does first switch back into >> graphics mode, and I can see the top part of the screen is messed up, so >> it hasn't restored the low memory. >> >I had similar problems. I removed splash_bmp from my loader.conf, >splash screen/screen saver, and the problems has gone away for me. My >would lockup if I tried to return to X from text after the delay time. Would you give me some more details? 1. Exact sequence of events when this happened. 2. Settings in loader.conf. 3. Output from `vidcontrol -i adapter' and `vidcontrol -i mode'. 4. /var/run/dmesg.boot when the system was started by `boot -v'. 5. FreeBSD and XFree86 versions. 6. Output from `X -probeonly'. Thank you. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Comments on Athlon [motherboards] sought..
I have heard of a few problems with the k7m... but I don't have any firsthand experience with them. FIC on the other hand has made some pretty good motherboards, and are probably the last company that needs to be bashed as far as quality goes. ASUS and FIC are probably the two best mobo companies, to me anyway, never had any trouble with either one at all. Soren Schmidt had the audacity to say: > > What ? I have no probs whatsoever with my K7M doing that... > > > So far I like the FIC and Aopen boards. > > Dont _ever_ buy FIC, there are no ends of trouble with them > > -Søren > > -- Coleman Kane President, UC Free O.S. Users Group - http://pohl.ececs.uc.edu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
I personally, don't see the reason for having this sort of thing in embedded devices, either, a lot of which have just exactly what they need to operate in the kernel, leaving nothing to be loaded or unloaded. As far as the kerneld stuff goes, the kernel obviously provides us with an interface with which to load these drivers from whatever may use them, there probably isn't a need after all for this sort of thing, so I'm done thinking about it, on to more pertinent things... Mike Smith had the audacity to say: > Nobody in their right mind is going to produce a "really small ram" > embedded system that features the sort of nondeterminism that > "automatically" (read 'randomly') unloading modules would involve. > > It's simple; a kernel-module-handling-daemon does not have anything to > offer us at this time. We don't need one; the problems it might be > applied to solve have already been solved differently, and we are > (generally) happy with the results. > > -- > \\ 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 > -- Coleman Kane President, UC Free O.S. Users Group - http://pohl.ececs.uc.edu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_dc in v4.0 - Forcing store and forward?
[EMAIL PROTECTED] wrote: > > > > I suspect a generic chipset fault, or some design quirk that we are not > > > working around. Note that the windoze drivers for these devices put them > > > permanently in store-and-forward mode. if_de has the exact same problem on > > > all of the systems above. > ... > > Store and forward mode introduces a horrible performance hit... Artesyn > > wouldn't show us the source to their workaround :-( > > It should be noted that I was able to saturate a 100 Mbps Ethernet with > FreeBSD 2.2 and a 21140 based card, using around 56% of the CPU of a > PPro-200. This was done almost exactly three years ago, using the (then) > standard if_de driver. I have no idea whether the card was operating in > store-and-forward mode or not - but the performance was perfectly fine. I can guarantee that it was not running in store and forward mode if you were exceeding 30 Mbit throughput. Was this a 21140, 21140A or other stepping? These variations varied pretty wildly in their behavior (and I suspect in their actual implementation as well). Cheers, J. Hicks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_dc in v4.0 - Forcing store and forward?
Dennis wrote: > > At 10:48 PM 6/7/00 -0700, W Gerald Hicks wrote: > >Peter Wemm wrote: > > > >> I suspect a generic chipset fault, or some design quirk that we are not > >> working around. Note that the windoze drivers for these devices put them > >> permanently in store-and-forward mode. if_de has the exact same problem on > >> all of the systems above. > > Well we never saw these problems in v3.4...so what changed? > > DB The chips vary widely, we experienced great behavioral differences between steppings. The 21143 was particulary worrisome, as were some of the 21140 variants. I definitely experienced tx underruns on FreeBSD 3.4 with a 21140A. Never saw them with a good old 21040 though. After I was told by Intel that they're killing the device off, we decided to stop developing boards with them and eliminated at least *that* source of aggravation ;-) -- Jerry Hicks [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
Mike Smith wrote: > > > > The issue is with really small ram embedded systems. > > Making things CAPABLE of being small is different from making > > them dynamicly loadable. > > Nobody in their right mind is going to produce a "really small ram" > embedded system that features the sort of nondeterminism that > "automatically" (read 'randomly') unloading modules would involve. Actually, embedded programmers are more likely to link everything in the kernel so they don't have to worry about calling drivers that aren't loaded. A pretty conservative lot, in general. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
