Re: offtopic: assembly
Fabio Miranda wrote: > I want to understand Why each byte (8 bit of data and > 1 bit of parity) has one bit of parity? To permit the hardware to catch single bit errors. ECC is a better version of this, which permits the hardware to correct single bit errors, and catch multiple bit errors. > what makes the difference from 'par' to 'no par'? A byte had even partiy if there are an even number of bits set, and odd paroty if an odd number of bits are set. > What part of > the program do the requested byte belongs (Code, data, > stack)? It doesn't matter. It all gets checked. > p.s. Anyone know a site like linux's > www.linuxassembly.org? > I want to know the freebsd developer's resources on > web ( i am not lucky to buy books online and my > bookstores arent unix-focused:)), i want to understand > freebsd internals! There have been a number of programs in assembly published in -hacers and -current, as well as -alpha (if you are in need of an Aplha assembly language "Hello World!" program). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: marking disks
Brooks Davis wrote: > What I'd been thinking was that I could write a magic string over the > beginning of the MBR since I'm never going to try and boot these disks. > That would let me detect uninitalized drives as well as out of date > partitioning schemes. Are there any problems to look out for with > this solution? Does anyone know of a better one? It would be easiest for you to create a partition table on the disk, and steal a table entry with a "magic" partition type to indicate that either the LBA or CHS data was actually version or type information, etc.. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: offtopic: assembly
On Wed, Dec 05, 2001 at 12:10:08AM -0800, Terry Lambert wrote: > Fabio Miranda wrote: > > p.s. Anyone know a site like linux's > > www.linuxassembly.org? > > I want to know the freebsd developer's resources on > > web ( i am not lucky to buy books online and my > > bookstores arent unix-focused:)), i want to understand > > freebsd internals! > > There have been a number of programs in assembly published > in -hacers and -current, as well as -alpha (if you are in > need of an Aplha assembly language "Hello World!" program). As well, you could check out www.int80h.org. > > -- Terry > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- Chad David[EMAIL PROTECTED] ACNS Inc. Calgary, Alberta Canada To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Fwd: Jul 30 changes to ppp break my Telstra ADSL PPPoE connection]
Hi, Thanks for your report. Would you be able to grab me logs of the connection that doesn't work (the latest ppp) and the one that works (the pre-July 30 one) with the following set: set log tun chat lcp ipcp It may be possible to fix the problem by changing your ``set mru'' and ``set mtu'' lines to set mru max 1454 set mtu max 1454 but, even if this is successful, I'd be interested in the logs. It may also be worth trying the latest version of ppp from my web site (http://www.Awfulak.org/~brian) - just in case it's something that I've already fixed but have forgotten to MFC. If that's the case, then I should be able to find the bogus code more easily. Thanks. > Original Message > From: Greg Lane <[EMAIL PROTECTED]> > Subject: Jul 30 changes to ppp break my Telstra ADSL PPPoE connection > To: [EMAIL PROTECTED] > CC: [EMAIL PROTECTED] > > G'day all, > > I have a problem with PPPoE over Telstra ADSL (Australia). A full > description of the problem can be found in freebsd-questions > (see [EMAIL PROTECTED] dated Nov 30) > with the subject: > > ADSL PPPoE (Telstra Aust.) began to hang between 4.3- and 4.4-RELEASE > > The short of it is that at some point during my cvsup history certain > types of traffic would hang, specifically most web traffic and certain > types of ssh (e.g. ls -l of a long directory). This was reminiscent of > the MTU/MRU problems at the beginning of the year. I backdated to > 4.3-RELEASE which worked and I forgot about it until recently when I > decided to change my gateway machine. > > I have now chased it up in earnest by going back through > various dated "cvsup's" and making the world. On > July 30th there were some changes to src/usr.sbin/ppp that break ppp > and cause this problem. Strangely enough the changes were related to > MRU's :-> !! > > I can reliably make my DSL connection work on three different machines > using four different network cards (ed, de, vr, rl) with source dated > Jul 30 12:01am, and reliably break it with anything after > Jul 31 12:01am. > > The changes made to ppp on that day were to: > > src/usr.sbin/ppp/command.c > src/usr.sbin/ppp/lpc.c > src/usr.sbin/ppp/nat_cmd.c > src/usr.sbin/ppp/nat_cmd.h > src/usr.sbin/ppp/ppp.8 > > The most likely problem is lpc.c because 1) it looks the most > complicated(!!) and 2) it is supposed to: > > MFC: Handle peer REQ/NAKs of >1500 byte MRUs when we have no preference > > The other diffs were small and were to implement two issues: > > MFC: If the peer REJects our MRU REQ, stop REQing it -- *EVEN* if we're > doing PPPoE and the default MRU is therefore too big. > > MFC: Actually add the ``nat proto'' command > > I'm afraid my lack of knowledge stops me going on from here. My > ppp.conf is below and I start ppp with "ppp -ddial -nat -quiet bigpond" > Can anyone see the problem and suggest further detective work I can > perform or even better, a fix or workaround? > > Cheers, > Greg > > P.S. I have cross-posted to questions since the thread started there > and hackers since I believe I have narrowed down the problem and it is > technical. I hope this is OK. Please confine your reply to whatever > list you feel is appropriate, I am subscribed to both. > > --- > default: > #Only enable logging for troubleshooting > #set log CBCP CCP Chat Connect Command IPCP tun Phase Warning Debug LCP sync > > set device PPPoE:rl0:bigpond > set speed sync > set mru 1454 > set mtu 1454 > set ctsrts off > enable lqr > add default HISADDR > set timeout 0 > set redial 7 0 > set socket /var/run/pppsocket * > > #Network Address Translation (NAT) > nat enable yes > nat log yes > #nat same_ports yes > nat unregistered_only yes > > #enable dns # this disabled since the box now runs its own dns > > bigpond: > set authname *** > set authkey *** > --- -- Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]> http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: offtopic: assembly
> > Fabio Miranda wrote: > > I want to understand Why each byte (8 bit of data and > > 1 bit of parity) has one bit of parity? > > To permit the hardware to catch single bit errors. > > ECC is a better version of this, which permits the hardware to > correct single bit errors, and catch multiple bit errors. Well, AFAIK, ECC cat correct single bit errors and detect double bit errors. Everything else is problematic, it may or may not detect multiple bit errors, depending on conditions. Just my 2 cents. Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
wc* function
According to mail archive, work on supporting wide-char functions was in progress some time but then stopped. May be is there some results of this work somewhere? Continue will better than beginning from scratch. Sem. --- Sergey Matveychuk | System Administrator E-Mail: [EMAIL PROTECTED] | Institute Of Aviation Motors Tel: +7(095)362-56-58 | Moscow, Russia Pager: +7(095)918-19-19 ab.2244 | ICQ UIN: 3317990 --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
4G phisical memory kernel trap
Hi, I have a PIII box with 4G phisical memory and FreeBSD 4.2 and it traps while booting - "fatal trap 12 page fault". With less than 4G memory the server is working good. There is no MAXMEM option in the kernel (as is by default). What would you suggest to make this box running with 4G? May be, specifying MAXMEM slightly less than 4G, or what else? Thank you. Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4G phisical memory kernel trap
On Wed, Dec 05, 2001 at 03:57:22PM +0300, Varshavchick Alexander wrote: > Hi, > > I have a PIII box with 4G phisical memory and FreeBSD 4.2 and it traps > while booting - "fatal trap 12 page fault". With less than 4G memory the > server is working good. There is no MAXMEM option in the kernel (as is by > default). What would you suggest to make this box running with 4G? May be, > specifying MAXMEM slightly less than 4G, or what else? Thank you. Try upgrading it to 4.4-STABLE, there has been dome some work regarding this since 4.2 /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work:Network manager @ AS3292 (Tele Danmark DataNetworks) Private: FreeBSD committer @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4G phisical memory kernel trap
As the matters stand, it's a heavily loaded working system and I can't afford experimenting with any major system changes. Tweaking kernel, boot loaded are allowed, but not major version upgrades. Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) On Wed, 5 Dec 2001, Jesper Skriver wrote: > Date: Wed, 5 Dec 2001 14:04:06 +0100 > From: Jesper Skriver <[EMAIL PROTECTED]> > To: Varshavchick Alexander <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: 4G phisical memory kernel trap > > On Wed, Dec 05, 2001 at 03:57:22PM +0300, Varshavchick Alexander wrote: > > Hi, > > > > I have a PIII box with 4G phisical memory and FreeBSD 4.2 and it traps > > while booting - "fatal trap 12 page fault". With less than 4G memory the > > server is working good. There is no MAXMEM option in the kernel (as is by > > default). What would you suggest to make this box running with 4G? May be, > > specifying MAXMEM slightly less than 4G, or what else? Thank you. > > Try upgrading it to 4.4-STABLE, there has been dome some work > regarding this since 4.2 > > /Jesper > > -- > Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 > Work:Network manager @ AS3292 (Tele Danmark DataNetworks) > Private: FreeBSD committer @ AS2109 (A much smaller network ;-) > > One Unix to rule them all, One Resolver to find them, > One IP to bring them all and in the zone to bind them. > > 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: 4G phisical memory kernel trap
May be let's look at the matter different way: what is the maximum memory limit that can be handled without system upgrading? If it's 3.9G or simiilar then this will solve the issue. Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) On Wed, 5 Dec 2001, Jesper Skriver wrote: > Date: Wed, 5 Dec 2001 14:04:06 +0100 > From: Jesper Skriver <[EMAIL PROTECTED]> > To: Varshavchick Alexander <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: 4G phisical memory kernel trap > > On Wed, Dec 05, 2001 at 03:57:22PM +0300, Varshavchick Alexander wrote: > > Hi, > > > > I have a PIII box with 4G phisical memory and FreeBSD 4.2 and it traps > > while booting - "fatal trap 12 page fault". With less than 4G memory the > > server is working good. There is no MAXMEM option in the kernel (as is by > > default). What would you suggest to make this box running with 4G? May be, > > specifying MAXMEM slightly less than 4G, or what else? Thank you. > > Try upgrading it to 4.4-STABLE, there has been dome some work > regarding this since 4.2 > > /Jesper > > -- > Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 > Work:Network manager @ AS3292 (Tele Danmark DataNetworks) > Private: FreeBSD committer @ AS2109 (A much smaller network ;-) > > One Unix to rule them all, One Resolver to find them, > One IP to bring them all and in the zone to bind them. > > 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: [Fwd: Jul 30 changes to ppp break my Telstra ADSL PPPoE connection]
Brian Somers wrote:
>
> Hi,
>
> Thanks for your report. Would you be able to grab me logs of the
> connection that doesn't work (the latest ppp) and the one that works
> (the pre-July 30 one) with the following set:
>
> set log tun chat lcp ipcp
>
> It may be possible to fix the problem by changing your ``set mru''
> and ``set mtu'' lines to
>
> set mru max 1454
> set mtu max 1454
>
> but, even if this is successful, I'd be interested in the logs.
>
> It may also be worth trying the latest version of ppp from my web
> site (http://www.Awfulak.org/~brian) - just in case it's something
> that I've already fixed but have forgotten to MFC. If that's the
> case, then I should be able to find the bogus code more easily.
>
I am having great difficulty getting logs. I noticed the last time I had ppp log data
was November 20th. But this is what I have.
/etc/syslog.conf:
!ppp
*.* /var/log/ppp.log
/var/log/ppp.log:
Dec 5 08:02:26 server ppp[198]: tun0: LCP: deflink: RecvEchoRequest(2) state = Opened
Dec 5 08:02:26 server ppp[198]: tun0: LCP: deflink: SendEchoReply(2) state = Opened
jhousley@server:~ {13} pppctl -p xx 3000 show log
Log: Chat IPCP LCP Tun Warning Error Alert
Local: Warning Error Alert
I am getting this with both RELENG_4_3 ppp and RELENG_4 ppp. Yes syslogd is running
as "syslogd -s -s" If I turn on tcp/ip or debug I get lots of information in the log
files. Is it possible that some of the log levels were broken. I will try the latest
verson from (http://www.Awfulak.org/~brian) is see if that logs properly
Jim
--
/"\ ASCII Ribbon Campaign .
\ / - NO HTML/RTF in e-mail .
X - NO Word docs in e-mail .
/ \ -
[EMAIL PROTECTED] http://www.FreeBSD.org The Power to Serve
[EMAIL PROTECTED] http://www.TheHousleys.net
[EMAIL PROTECTED] http://www.SimTel.Net
-
Your mouse has moved.
Windows NT must be restarted for the change to take effect!
Reboot now? [OK]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: bin/32261: dump creates a dump file much larger than sum of dumped files
On Tue, Dec 04, 2001 at 11:26:39PM -0800, Crist J . Clark wrote: > On Wed, Dec 05, 2001 at 05:10:49PM +1000, Greg Black wrote: > > "Crist J . Clark" wrote: > > > > | On Wed, Dec 05, 2001 at 06:02:49AM +1000, Greg Black wrote: > > | > Matthew Dillon wrote: > > | > > > | > | :In message <[EMAIL PROTECTED]>, Bernd Walter writes: > > | > | :>> Is there any reason we don't want to truncate the file? Does O_TRUNC > > | > | :>> not work well of the file is a tape device or something? > > | > | :> > > | > | :>I don't expect O_TRUNK to work on devices such tapes and disks. > > | > | : > > | > | :Well, it won't achieve anything on tapes or disk devices, but it > > | > | :should be completely harmless to add the O_TRUNC flag. The current > > | > | :behaviour is likely to be unexpected and cause confusion so it > > | > | :might as well be changed. I'll commit this later unless someone > > | > | :can think of a good reason not to. > > | > | : > > | > | :Ian > > | > | > > | > | Woa! That sounds like a bad idea to me. If you want to do it right > > | > | then open(), fstat(), and only if the stat says it is a regular file > > | > | do you then ftruncate(). Passing O_TRUNC to a tape device may be ignored > > | > | by us, but it's not a valid flag to pass to a tape device and we >shouldn't > > | > | do it. > > | > > > | > I haven't used any of them for a while, but there are certainly > > | > Unix systems that treat O_TRUNC as a signal to rewind a tape > > | > device before writing to it. > > | > > | So? Who cares? This is FreeBSD's dump(8) and FreeBSD's write(2). There > > | is no reason to worry about portability of FreeBSD's dump(8) in how > > | write(2) flags work. If our write(2) "does the right thing" with > > | O_TRUNC and tape devices, there is no reason not to let it do the > > | right thing on its own. > > > > That's a rather strange attitude. All I was suggesting that, > > from the once-respected POLA, it would be less surprising to > > people who might have experience of other systems if FreeBSD did > > not make its own arrangements without some good reason. > > From what Ian said elsewhere in this thread, the O_TRUNC already does > not "act strange" on a tape device. I don't see any new POLA issues if > adding O_TRUNC to the write call doesn't change how dump(8) has been > working on tapes for FreeBSD for these n years now. The only POLA > issue I see is the current behavior that "regular" files are _not_ > truncated, which was the start of the thread and the issue in the PR. That FreeBSD tape devices ignore this isn't a strong reason to do. People may also dump to disk devices, unix domains sockets, fifo devices or media your don't even know today. And the fstat way don't hurt anyone but instead is an absolute save way without expecting anything about the output stream behavour. > > There's > > no need for responses like: "So? Who cares?" -- if there's some > > reason not to consider other people, by all means explain it; > > but be polite while you're at it. > > I don't see who would care if FreeBSD's dump(8) might have some funny > reactions on UNIX-like systems where O_TRUNC has a different behavior > on tape devices. I don't think the Project is overly concerned about > porting FreeBSD's dump(8) to other OSes. But we might care porting device drivers to FreeBSD. Think of that we may start and run linux kernel modules someday. I don't asume it to be very likely - but you never know. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4G phisical memory kernel trap
In the last episode (Dec 05), Varshavchick Alexander said: > On Wed, 5 Dec 2001, Jesper Skriver wrote: > > On Wed, Dec 05, 2001 at 03:57:22PM +0300, Varshavchick Alexander wrote: > > > I have a PIII box with 4G phisical memory and FreeBSD 4.2 and it > > > traps while booting - "fatal trap 12 page fault". With less than > > > 4G memory the server is working good. There is no MAXMEM option > > > in the kernel (as is by default). What would you suggest to make > > > this box running with 4G? May be, specifying MAXMEM slightly less > > > than 4G, or what else? Thank you. > > > > Try upgrading it to 4.4-STABLE, there has been dome some work > > regarding this since 4.2 > > As the matters stand, it's a heavily loaded working system and I > can't afford experimenting with any major system changes. Tweaking > kernel, boot loaded are allowed, but not major version upgrades. You can run a 4.4 kernel on a 4.2 userland with no problem. On some of my production boxes, I'm running a 4.4 kernel on a 4.0 userland :) You should be able to build a 4.4 kernel, copy it to /kernel.test, and do a quick reboot to see if it works. That way you can fall back to the 4.2 kernel if you have problems. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4G phisical memory kernel trap
Thank you Dan, can you please give a more detailed description as how to do it? > You can run a 4.4 kernel on a 4.2 userland with no problem. On some of > my production boxes, I'm running a 4.4 kernel on a 4.0 userland :) You > should be able to build a 4.4 kernel, copy it to /kernel.test, and do a > quick reboot to see if it works. That way you can fall back to the 4.2 > kernel if you have problems. > > -- > Dan Nelson > [EMAIL PROTECTED] > Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SMB driver for 4.2 SMP kernel (healthd, lmmon, etc.)
On Tue, Dec 04, 2001 at 09:37:24PM -0800, Srinivas Dharmasanam wrote: > Hi, > I'm not able to work the SMB driver (used by healthd, lmmon, etc.) on an > Intel x86 FreeBSD 4.2 SMP system for getting system statistics such as the > CPU temps, voltages, fan rpm's etc. > > With a FreeBSD 4.2 single cpu kernel, all of these utilities work fine using > > the underlying SMB driver (/dev/smb0 device). However, with an SMP kernel I > get a "device not configured" error message when doing ioctl on this device. Unfortunatly, I don't have access to biproc MB to do necessary testing/debug in good conditions. And time does not permit me to do it without HW testing. Nicholas -- Alcôve Technical Manager - [EMAIL PROTECTED] - http://www.alcove.com FreeBSD Developer - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can TCP changes be put in RELENG_4?
Jim Durham <[EMAIL PROTECTED]> writes: > Duh... right. OGS..(Old Guy Syndrome). I actually just did a cvsup to > RELENG_4_4 and it didn't have the fixes. I guess I'll rephrase my > question... "Can we have the patches in REGENG_4_4?". RELENG_4_4 is for security fixes only. Consider using -STABLE if you require additional improvements. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can TCP changes be put in RELENG_4?
On Wed, Dec 05, 2001 at 11:51:02AM -0500, Mike Barcroft wrote: > Jim Durham <[EMAIL PROTECTED]> writes: > > Duh... right. OGS..(Old Guy Syndrome). I actually just did a cvsup to > > RELENG_4_4 and it didn't have the fixes. I guess I'll rephrase my > > question... "Can we have the patches in REGENG_4_4?". > > RELENG_4_4 is for security fixes only. Consider using -STABLE if you > require additional improvements. s/security/security and critical bug/ -- | / o / /_ _ email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can TCP changes be put in RELENG_4?
Wilko Bulte <[EMAIL PROTECTED]> writes: > On Wed, Dec 05, 2001 at 11:51:02AM -0500, Mike Barcroft wrote: > > Jim Durham <[EMAIL PROTECTED]> writes: > > > Duh... right. OGS..(Old Guy Syndrome). I actually just did a cvsup to > > > RELENG_4_4 and it didn't have the fixes. I guess I'll rephrase my > > > question... "Can we have the patches in REGENG_4_4?". > > > > RELENG_4_4 is for security fixes only. Consider using -STABLE if you > > require additional improvements. > > s/security/security and critical bug/ Did I miss a change in policy? The original announcement about RELENG_4_3 said: : 2) INTRODUCTION OF THE RELENG_4_3 SECURITY BRANCH :-- : : As of FreeBSD 4.3-RELEASE, the security officer will be providing : support for a new CVS branch consisting of 4.3-RELEASE plus all : released security patches from FreeBSD Security Advisories. This : branch carries the CVS branch tag of ``RELENG_4_3'', and can be : tracked using the usual source distribution methods such as cvsup : using this branch tag. : : In contrast to 4.3-STABLE (``RELENG_4''), which carries security : updates as well as general bugfixes and feature enhancements, the : RELENG_4_3 release branch will carry ONLY security fixes: it is : intended for users of FreeBSD who do not wish to track the full : 4.3-STABLE branch but who wish to keep their system up-to-date with : security fixes in a semi-automated manner (i.e. without applying : patches by hand). : : This practise of using a release branch to hold security fixes is : likely to be continued for future releases of FreeBSD. I was hoping to find more information in the Handbook, but we seem to be missing a chapter about this. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can TCP changes be put in RELENG_4?
FWIW, I'd vote for "MFS"ing the TCP changes in -STABLE to RELENG_4_4. As it stands right now 4.4 is kinda broken. On Wed, 5 Dec 2001, Mike Barcroft wrote: > Jim Durham <[EMAIL PROTECTED]> writes: > > Duh... right. OGS..(Old Guy Syndrome). I actually just did a cvsup to > > RELENG_4_4 and it didn't have the fixes. I guess I'll rephrase my > > question... "Can we have the patches in REGENG_4_4?". > > RELENG_4_4 is for security fixes only. Consider using -STABLE if you > require additional improvements. > > Best regards, > Mike Barcroft > > 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: wc* function
hi, On Wed, Dec 05, 2001 at 03:28:29PM +0300, Sergey Matveychuk wrote: > According to mail archive, work on supporting wide-char functions was in > progress some time but then stopped. > > May be is there some results of this work somewhere? Continue will better > than beginning from scratch. Check out Citrus[1] project's CVS Repo. They have quite promising implementation of w* functions. Also as I recall correctly some amount of w* functions are already commited in. [1] http://citurs.bsdclub.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Tracking down system freeze
Hi all. Does anyone have ANY suggestions on how to determine where the kernel/program is when the system freezes??? Even hardware solutions, such as the infamous paperclip across two pins will do. I am trying to track down what appears to be a kernel freeze problem, but alas, debuggers, et.al. are worthless because they too are frozen. It appears to be one of those difficult problems where part A is doing something wrong (which it doesn't mind) but later unrelated part B is being blasted by it. And of course, while it happens often, it doesn't happen every time. But I can't tell where we are when the system freezes. Is there any way to kick the system in the butt somehow to at least let the debugger do it's thing? On the same line, can anyone tell me where I can find out everything a program does when executed BEFORE the first line of code is reached (gcc). not THE Mike Smith To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can TCP changes be put in RELENG_4?
On Tue, Dec 04, 2001 at 11:48:52AM -0500, Jim Durham wrote: > I know that only security fixes are supposed to go in RELENG_4, but > the recent changes in the TCP stuff seem important enough that > perhaps they could be put in RELENG_4 for those of us who run > productions servers on -RELEASE ? After reading the replies a bit, I'm going to suggest some middle ground. I think the changes should sit in stable for "a while", and while they are there we should make notes of it in a few different places and have people beat up on the changes with various tests. I think this is very good stuff, and that most of the people tracking RELENG4_4 would want it, but only if it is 210% fully tested and helps out 99.999% of all people. So let's verify both of those and then revisit the issue. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4G phisical memory kernel trap
Alexander, I had experienced this problem before. It is most likely that you are running out of page table pages. Try changing NKPT in /sys/i386/include/pmap.h to 64. That worked for me. tim On Wed, Dec 05, 2001 at 03:57:22PM +0300, Varshavchick Alexander wrote: > Hi, > > I have a PIII box with 4G phisical memory and FreeBSD 4.2 and it traps > while booting - "fatal trap 12 page fault". With less than 4G memory the > server is working good. There is no MAXMEM option in the kernel (as is by > default). What would you suggest to make this box running with 4G? May be, > specifying MAXMEM slightly less than 4G, or what else? Thank you. > > Alexander Varshavchick, Metrocom Joint Stock Company > Phone: (812)118-3322, 118-3115(fax) > > > > 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
rxvt terminal detection patch
Hi,
I received the following email regarding terminal
detection. Does this looks sane? Any comments?
I will add this to the rxvt port if I get positive
feedback.
I believe it is correct but I thought I should ask
a broader audiance.
Regards,
- Forwarded message from -
To: [EMAIL PROTECTED]
Date: Wed, 12 Sep 2001 16:08:15 +1000 (EST)
Message-Id: <[EMAIL PROTECTED]>
Subject: rxvt patch
Hi there,
I have been having problens with rxvt that does not exist in an normal xterm.
I was giving me an error message:
can't open pseudo-tty
I traced this to the get_pty() func in command.c and found FreeBSD uses
the PTYS_ARE_SEARCHED define. This is OK except I also found that the
PTYCHAR1 and PTYCHAR2 defs did not seam to include all the ptys on
a FreeBSD machine. We have many users here and it did not take long before
there were no ptys left in the seach. We have all 256 configured.
Here is the patch that got me working. I was using the /usr/ports/x11/rxvt
(rxvt-2.6.3). Hope this helps.
--- src/command.c.orig Wed Sep 12 15:41:30 2001
+++ src/command.c Wed Sep 12 15:42:37 2001
@@ -321,8 +321,8 @@
ptydev = pty_name;
ttydev = tty_name;
-# define PTYCHAR1 "pqrstuvwxyz"
-# define PTYCHAR2 "0123456789abcdef"
+# define PTYCHAR1 "pqrstuvPQRSTUV"
+# define PTYCHAR2 "0123456789abcdefghijklmnopqrstuv"
for (c1 = PTYCHAR1; *c1; c1++) {
ptydev[len] = ttydev[len] = *c1;
for (c2 = PTYCHAR2; *c2; c2++) {
--
Daryl Sayers
Corinthian Engineering Ph: (02) 9906 7866
Suite 19, 401 Pacific Hwy Fax: (02) 9906 1556
Artarmon, NSW, 2064 email: [EMAIL PROTECTED]
Australia www: http://www.cordoors.com.au
- End forwarded message -
--
Mario S F Ferreira - DF - Brazil - "I guess this is a signature."
Computer Science Undergraduate | FreeBSD Committer | CS Developer
flames to beloved [EMAIL PROTECTED]
feature, n: a documented bug | bug, n: an undocumented feature
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: marking disks
On Wed, Dec 05, 2001 at 12:11:55AM -0800, Terry Lambert wrote: > Brooks Davis wrote: > > What I'd been thinking was that I could write a magic string over the > > beginning of the MBR since I'm never going to try and boot these disks. > > That would let me detect uninitalized drives as well as out of date > > partitioning schemes. Are there any problems to look out for with > > this solution? Does anyone know of a better one? > > It would be easiest for you to create a partition table on the > disk, and steal a table entry with a "magic" partition type to > indicate that either the LBA or CHS data was actually version or > type information, etc.. The thing I'm worried about there is that some "smart" bios or os might sanity check the values and refuse to work with the drive. Is that a likely scenerio? -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg29607/pgp0.pgp Description: PGP signature
Re: Tracking down system freeze
On Wed, Dec 05, 2001 at 01:14:51PM -0500, PSI, Mike Smith wrote: > Does anyone have ANY suggestions on how to determine where the > kernel/program is when the system freezes??? Even hardware solutions, > such as the infamous paperclip across two pins will do. Serial console and serial break-to-the-debugger work fairly well for this sort of thing. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
gdb serial port
While compiling a debug kernel, I forgot to set the flag of sio0 to 0x80. Is there anyway I can fix this quickly without recompiling the kernel? Thanks, -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
How to handle replaced files in repos ?
Hi all, Aside from manually re-adding local changes, is there a way to avoid cvsup to replace files (that have been manually changed in the FreeBSD repos) when there are local branches ? ie: Someone recently replaced: Replace src/contrib/gcc/config/alpha/freebsd.h,v Replace src/contrib/gcc/config/freebsd.h,v Replace src/contrib/gcc/config/i386/freebsd.h,v and my local branches tags are gone. TIA. RN. IaM To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gdb serial port
At 2:41 PM -0500 12/5/01, Zhihui Zhang wrote: >While compiling a debug kernel, I forgot to set the flag of sio0 to >0x80. Is there anyway I can fix this quickly without recompiling >the kernel? Thanks, For -current, you can change (or add) a hint to /boot/device.hints such as: hint.sio.0.flags="0x80" For -stable, I believe you have to recompile the kernel. Mark To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can TCP changes be put in RELENG_4?
On Wed, Dec 05, 2001 at 12:08:49PM -0500, Mike Barcroft wrote: > Wilko Bulte <[EMAIL PROTECTED]> writes: > > On Wed, Dec 05, 2001 at 11:51:02AM -0500, Mike Barcroft wrote: > > > Jim Durham <[EMAIL PROTECTED]> writes: > > > > Duh... right. OGS..(Old Guy Syndrome). I actually just did a cvsup to > > > > RELENG_4_4 and it didn't have the fixes. I guess I'll rephrase my > > > > question... "Can we have the patches in REGENG_4_4?". > > > > > > RELENG_4_4 is for security fixes only. Consider using -STABLE if you > > > require additional improvements. > > > > s/security/security and critical bug/ > > Did I miss a change in policy? The original announcement about > RELENG_4_3 said: > > : 2) INTRODUCTION OF THE RELENG_4_3 SECURITY BRANCH > :-- > : > : As of FreeBSD 4.3-RELEASE, the security officer will be providing > : support for a new CVS branch consisting of 4.3-RELEASE plus all > : released security patches from FreeBSD Security Advisories. This > : branch carries the CVS branch tag of ``RELENG_4_3'', and can be > : tracked using the usual source distribution methods such as cvsup > : using this branch tag. > : > : In contrast to 4.3-STABLE (``RELENG_4''), which carries security > : updates as well as general bugfixes and feature enhancements, the > : RELENG_4_3 release branch will carry ONLY security fixes: it is > : intended for users of FreeBSD who do not wish to track the full > : 4.3-STABLE branch but who wish to keep their system up-to-date with > : security fixes in a semi-automated manner (i.e. without applying > : patches by hand). > : > : This practise of using a release branch to hold security fixes is > : likely to be continued for future releases of FreeBSD. > > I was hoping to find more information in the Handbook, but we seem to > be missing a chapter about this. Say if a serious bug was found where a system could easily be made instable, without directly posing a security threat. I think one would then also fix this bug in RELENG_4_4 This following the reasoning that people track RELENG_4_4 for production systems that need the utmost stability. Of course this needs approval from the release engineer team. Crashing a system is the ultimate DoS, and DoS fixes would (I assume) find approval from the security-officer. Does this sound reasonable? I agree with you if you want to see this documented somehow. Wilko -- | / o / /_ _ email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gdb serial port
in 4.4 or 5.x you can set the flags in /boot/device.hints On Wed, 5 Dec 2001, Zhihui Zhang wrote: > > While compiling a debug kernel, I forgot to set the flag of sio0 to > 0x80. Is there anyway I can fix this quickly without recompiling > the kernel? Thanks, > > -Zhihui > > > 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: How to handle replaced files in repos ?
On Wed, Dec 05, 2001 at 08:48:19PM +0100, [EMAIL PROTECTED] wrote: > Aside from manually re-adding local changes, is there a way to avoid > cvsup to replace files (that have been manually changed in the FreeBSD > repos) when there are local branches ? Yes, somewhat. Have you read http://www.polstra.com/projects/freeware/CVSup/faq.html#canilocal To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: wc* function
On Wed, Dec 05, 2001 at 03:28:29PM +0300, Sergey Matveychuk wrote: > According to mail archive, work on supporting wide-char functions was in > progress some time but then stopped. We are in need of a new wchar i18n person. Interested? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: wc* function
* Sergey Matveychuk <[EMAIL PROTECTED]> [011205 06:30] wrote: > According to mail archive, work on supporting wide-char functions was in > progress some time but then stopped. > > May be is there some results of this work somewhere? Continue will better > than beginning from scratch. It seems that freebsd has implemented some of the functions in wchar.h, but not many or none of the ones in wctype.h. NetBSD seems to have these integrated, you can crib from them as I am trying to do with my miniscule free time. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bin/32261: dump creates a dump file much larger than sum of dumped files
On Tue, Dec 04, 2001 at 07:37:04PM -0500, Garance A Drosihn wrote: > While on the topic of 'dump', note that there's also the patch in > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=bin/32414 > > which fixes a problem where dump will include information that > should not be included (due to the nodump flag being set). This > too would result in dump files larger than they "should" be... > > The PR includes a patch which is meant to fix this problem. Committed. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Tracking down system freeze
* PSI, Mike Smith <[EMAIL PROTECTED]> [011205 12:12] wrote: > Hi all. > > Does anyone have ANY suggestions on how to determine where the > kernel/program is when the system freezes??? Even hardware solutions, > such as the infamous paperclip across two pins will do. Ohh... the infamous paperclip trick... That's what I used to debug the wi wireless driver. * THIS DIAGRAM IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS DIAGRAM, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. Ok, now.. What you do is fold a paperclip then use it to make the last two pins of the ISA bus short: here vv | || || || || :: :: :: | [-] <- blow up diagram | || || || || :: :: :: | [ ] make paperclip short | || || || || :: :: :: | [ ] the last two terminals | || || || || :: :: :: | [ ] that face each other | || || || || :: :: :: | [ ] | || || || || :: :: :: | [ ] | || || || ||| [ ] | || || || || \_/| [ ] | PCI slots | | \/ | | ISA slots| || || || Be warned, this doesn't work on all motherboards! The one that I had that it didn't work on didn't have any damage though. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: wctype.h
On Mon, Dec 03, 2001 at 04:27:09PM -0500, Garance A Drosihn wrote: > > I thought we had some project which brought in the wide-character > stuff, or at least was working on it. We had one person doing it, but he got ran off from a heated discussion in the freebsd-i18n list. We are in need of a wchar person. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: wc* function
> Check out Citrus[1] project's CVS Repo. They have quite promising implementation > of w* functions. Also as I recall correctly some amount of w* functions > are already commited in. > > [1] http://citurs.bsdclub.org Link is dead. Can you check it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: wc* function
> Check out Citrus[1] project's CVS Repo. They have quite promising implementation > of w* functions. Also as I recall correctly some amount of w* functions > are already commited in. > > [1] http://citurs.bsdclub.org Link is dead. Can you check it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Tracking down system freeze
On 05-Dec-01 PSI, Mike Smith wrote: > Hi all. > > Does anyone have ANY suggestions on how to determine where the > kernel/program is when the system freezes??? Even hardware solutions, > such as the infamous paperclip across two pins will do. > > I am trying to track down what appears to be a kernel freeze problem, > but alas, debuggers, et.al. are worthless because they too are frozen. > It appears to be one of those difficult problems where part A is doing > something wrong (which it doesn't mind) but later unrelated part B is > being blasted by it. And of course, while it happens often, it doesn't > happen every time. > > But I can't tell where we are when the system freezes. Is there any way > to kick the system in the butt somehow to at least let the debugger do > it's thing? Trigger an NMI. Alfred's post was one way of doing this. There are also various instructions floating around on building NMI switches on the web that you might be able to find. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: more on jail - suitable for multi user system ?
Make sure that these users can't send outgoing mail and can't ping-flood from your machine, if they are really random users off the street. I did a very similar project years ago and abuse was a big issue. -- Ben "An art scene of delight I created this to be ..." -- Sun Ra To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: wc* function
On Thu, Dec 06, 2001 at 12:04:31AM +0300, Sergey Matveychuk wrote: > > Check out Citrus[1] project's CVS Repo. They have quite promising > implementation > > of w* functions. Also as I recall correctly some amount of w* functions > > are already commited in. > > > > [1] http://citurs.bsdclub.org > > Link is dead. Can you check it? Ugh! Typo :-( http://citrus.bsdclub.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: wc* function
> On Wed, Dec 05, 2001 at 03:28:29PM +0300, Sergey Matveychuk wrote: > > According to mail archive, work on supporting wide-char functions was in > > progress some time but then stopped. > > We are in need of a new wchar i18n person. Interested? Yes, but I can't. I don't know a lot about wchar. I read now some docs, but not sure it's enough. Alfred Perlstein has offered to integrate this code from netbsd. And it must be tested a few people. I'm ready to take a part. Sem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tar and nodump flag (fwd)
>From [EMAIL PROTECTED] Mon Dec 3 20:27:24 2001 >On Thu, Nov 29, 2001 at 09:07:03PM +0100, Joerg Schilling wrote: >> >> - An idiosyncratic build system. >> >> This is really funny >Please don't waste time on this issue. I can bmake and shoe-horn >anything into our build system. Right, this is definitely not a topic to put effort on ... but to make it easier to understand problems with star vs. GNU tar I spend several hours to prepare a comparison (much more than it took to implement star -nodump ;-) In order to allow an unbiased discussion, I prepared this comparison. It contains some hints for people (currently using Gnu tar) who like to like to switch to 'star' and a list of features missing in Gnu tar, a smaller list of features missing in star and a list of incompatible options in Gnu tar. As I am not sure whether I will have the time to keep it in sync with future changes, it is valid for December 1st 2001. First some background notes. Star is several years older than Gnu tar and most of the options that have different meanings in gnu tar have been in use with star since 1985. This is about two years before the first versions of Gnu tar (called PD tar or SUG tar in 1987) have been known. Do not expect that the meaning of those options will be changed in star in the future. Star tries to be as compatible as possible with the BSD tar implementation from 1982 and with the POSIX standard. Of course, it implements a lot of enhancements. Gnu tar in former times (in 1987 when being called PD tar / SUG tar) has been compatible to the BSD tar implementation but this changed in 1989 when FSF adopted the program as Gnu tar. Gnu tar is not very POSIX compliant (in command line options as well as in the archive format). If you know the standard and thus know where Gnu tar is not standard compliant, it is easy to switch between Gnu tar and star if you only use the basic functionality. If you don't know the standard and only know Gnu tar you may get into some problems but this is really a Gnu tar problem. Now let us compare functionality and options. Star has a lot of functions that are usually invisible to the user but make the daily use much easier: - A FIFO allows to keeps the tape streaming. This gives you faster backups than you can achieve with ufsdump and with other tar implementations if the size of the filesystem is > 1 GByte. - A powerful pattern matcher for a convenient user interface (see manual page for more details) to archive/extract a subset of files. - A sophisticated diff with a user tailorable interface for comparing tar archives against file trees. This is one of the most interesting parts of the star implementation. - deals with all 3 times, it stores/restores all 3 times of a file (even creation time) On Solaris, it may reset access time after doing the backup without clobbering the ctime. - Star does not clobber files by default. More recent copies on disk will not be clobbered from tape. This may be the main advantage over other tar implementations. This allows automatically repairing of corruptions after a crash & fsck (Check for differences after doing this with the diff option). - Star does automatic byte swapping if needed. Star automatically detects swapped archives and transparently reads them the right way. - Star has automatic compression detection. In the recent case when star is used to unpack compressed files containing tar archives, star will transparently detect and call the right decompression program. - Star has automatic archive format detection. Star automatically detects several common archive formats and adopts to them. Supported archive types are: tar old tar format starold star format from 1985 gnutar gnu tar format ustar standard tar (ieee 1003.1) format xstar extended standard tar format xustar extended standard tar format without tar signature exustar extended standard tar format without tar signature (always x-header) pax extended POSIX.1-200x standard tar format suntar Sun's extended pre-POSIX.1-200x Solaris 7/8 tar format - Star is fully ANSI/Posix 1003.1 compatible. See README.otherbugs for a complete description of bugs found in other tar implementations. - Support for the new POSIX.1-200x extended tar format. This new tar format allows to archive many new things in a standard compliant way. These things are currently are implemented in Gnu tar in a proprietary way and have in former times been implemented in a proprietary way in star. To give an example, the
Re: Can TCP changes be put in RELENG_4?
These changes are performance fixes, not security fixes. I consider them fairly significant performance fixes, but these bugs have been in the TCP stack for literally a whole year without an outcry so I don't see much justification for putting them into the security branch. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Repost - f_type value in statfs structure
Hi all, Sorry to repost this, but I'm still trying to nail this issue. Any assistance would be much appreciated. I've written an application that uses getmntinfo which creates an array of statfs structs and stores information about mounted filesystems there. The issue that I am having is detecting valid filesystems to do further checks on. I am only interested in checking local filesystems such as UFS. Originally I was checking to see if f_type in the created struct was a certain number. The man page described this as being int f_type; /* type of filesystem */ I have now had to revert to checking f_fstypename against a string (ufs only for now) because f_type seems to contain different numbers for the same f_fstypename on different machines. Eg on three different machines running FreeBSD 4.4-STABLE I got 1, 3 and 5 for f_type where the f_fstypename was ufs. Is the f_type supposed to be consistent? If so, where is this normally defined? If the f_type is not supposed to be consistent, is there any way to check a the filesystem in the current statfs struct against a list of values without having to do if ( (strcmp(mounted_fs[count].f_fstypename, "ufs") != 0) || (strcmp(mounted_fs[count].f_fstypename, "hfs") !=0) ) ? Thanks -- - Wayne Pascoe | I haven't lost my mind... [EMAIL PROTECTED] | It's backed up on tape somewhere. http://www.molemanarmy.com | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Repost - f_type value in statfs structure
On Wed, Dec 05, 2001 at 10:21:16PM +, Wayne Pascoe wrote:
> Hi all,
>
> Sorry to repost this, but I'm still trying to nail this issue. Any
> assistance would be much appreciated.
>
> I've written an application that uses getmntinfo which creates an
> array of statfs structs and stores information about mounted
> filesystems there.
>
> The issue that I am having is detecting valid filesystems to do
> further checks on. I am only interested in checking local filesystems
> such as UFS.
Check for the MNT_LOCAL flag in f_flags.
For example:
#include
#include
#include
#include
int
main() {
struct statfs *fs, *fsa;
int cnt;
cnt = getmntinfo(&fsa, 0);
if (!cnt) {
fprintf(stderr, "getmntinfo() failed\n");
exit(1);
}
for (fs = fsa; cnt != 0; fs++, cnt--)
printf("%s %d\n", fs->f_fstypename, (fs->f_flags & MNT_LOCAL) ==
MNT_LOCAL);
exit(0);
}
Hope that helps.
--
Chad David[EMAIL PROTECTED]
ACNS Inc. Calgary, Alberta Canada
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Can TCP changes be put in RELENG_4?
On Wed, Dec 05, 2001 at 01:19:03PM -0500, Leo Bicknell wrote: > On Tue, Dec 04, 2001 at 11:48:52AM -0500, Jim Durham wrote: > > I know that only security fixes are supposed to go in RELENG_4, but > > the recent changes in the TCP stuff seem important enough that > > perhaps they could be put in RELENG_4 for those of us who run > > productions servers on -RELEASE ? > > After reading the replies a bit, I'm going to suggest some middle > ground. > > I think the changes should sit in stable for "a while", and while > they are there we should make notes of it in a few different places > and have people beat up on the changes with various tests. > > I think this is very good stuff, and that most of the people > tracking RELENG4_4 would want it, but only if it is 210% fully > tested and helps out 99.999% of all people. So let's verify > both of those and then revisit the issue. 4.5-RELEASE is only a month and a half away. By the time this "while" passes, we'll be there. If people have lived this long with the bugs, they can last until late January. -- "It's always funny until someone gets hurt. Then it's hilarious." Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can TCP changes be put in RELENG_4?
On Wed, Dec 05, 2001 at 03:12:29PM -0800, Crist J . Clark wrote: > 4.5-RELEASE is only a month and a half away. By the time this "while" > passes, we'll be there. If people have lived this long with the bugs, > they can last until late January. I find it hard to argue with that. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tar and nodump flag (fwd)
Joerg Schilling writes: . > STAR Option Description Gnu >tar equiv. Remarks > === === >= === . > file=nm,f=nm use 'nm' as tape instead of stdin/stdout-f > close to identical May be close to identical in function, but not in convenience What about f=*.[ch] or f=something . > C=dir perform a chdir to 'dir' before storing next file -C > identical Unconvenient, see above . > Options only found in GNUtar: > > GNUtar option GNUtar description Star >remarks > == >=== > Main operation mode: > -A, --catenate append tar files to an archive low >importance Hm.. Are you shure? . > --remove-files remove files after adding them to the archivenot >needed May be low importance? -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tar and nodump flag (fwd)
>From [EMAIL PROTECTED] Thu Dec 6 00:41:54 2001 >. >> STAR Option Description Gnu >tar equiv. Remarks >> === === >= === >. >> file=nm,f=nm use 'nm' as tape instead of stdin/stdout-f > close to identical >May be close to identical in function, but not in convenience >What about f=*.[ch] or f=something >. >> C=dirperform a chdir to 'dir' before storing next file > -C identical >Unconvenient, see above So you obviously never used star and are only writing about your prejudices. an option usage f=value May be written in the following ways: f=value -f=value f= value -f= value -f value -fvalue getargs() is a lot more flexible than getopt() and it is even older than getopt(). Jörg EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) If you don't have iso-8859-1 [EMAIL PROTECTED] (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Success! [with patch] (was Re: umass & ATAPI)
I can confirm that the patches are also working flawlessly for a Pentax Optio 330 on a 5.0-current system. M. Heller To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can TCP changes be put in RELENG_4?
On Wednesday 05 December 2001 04:42 pm, Matthew Dillon wrote: > These changes are performance fixes, not security fixes. I consider > them fairly significant performance fixes, but these bugs have been in > the TCP stack for literally a whole year without an outcry so I don't > see much justification for putting them into the security branch. > > -Matt I have no axe to grind on this at all. It just appeared to me that a lot of folks must be in similar circumstances to mine. I have to keep 5 4.x servers up 24x7 and I don't normally need anything except really reliable service for mail, NFS, samba, etc, which the -RELEASE branch gives me in spades. Going to -stable is just a little to "avant-gard" for us! However, having the kind of increase in network performance that you achieved would really be favorable for our network, as I have drives mounted via SMB over several thousand miles of network. There must be, I thought, others in the same situation that would love to have that stuff in 4.4-RELEASE, but I can understand if the consensus is otherwise. So, I will probably just put the patches into 4.4-RELEASE, and give it a try on my "test" box here at home before putting the changes into the 4.4's at work. I appreciate the hard work. Thanks. -- Jim Durham To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Linus Torvalds and urgent message about your future!
Title: Urgent!!! Linus Torvalds, you must have friends in high places. I've been authorized to issue you a Special Tarot Reading! You can learn about important events concerning your future. It is vital that you call immediately! So, make this FREE CALL to 1-800-311-1736 Talk with a psychic specialist and find out what is likely to happen in the next weeks. Linus Torvalds, we know more about you then you may think. This free offer is for a limited time only- I can only hold it for just a little while! Immediately call 1-800-311-1736 - it's FREE! Linus Torvalds, our elite team of psychic predictors and Tarot readers can be extremely accurate and should not be underestimated. Linus Torvalds PLEASE CALL 1-800-311-1736 WHILE THIS OFFER IS STILL APPROVED. P.S. Linus Torvalds, Please do not give or use this number for anyone other than yourself. It's a special number that's meant only for you! It is essential, however, that you call in the next few days. Call 1-800-311-1736. Give it a try - it's FREE! With love & hope, Miss CLEO Make a FREE CALL to 1-800-218-6722 to hear about other special reading offers. Si usted prefiere su lectura en español, llámenos al 800-543-4051. Esta llamada es gratis. Date: 12/05/2001 Must be 18+. For entertainment purposes only. If you wish to unsubscribe from further emailings, please Click Here. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can TCP changes be put in RELENG_4?
On Wed, 5 Dec 2001, Leo Bicknell wrote: > On Wed, Dec 05, 2001 at 03:12:29PM -0800, Crist J . Clark wrote: > > 4.5-RELEASE is only a month and a half away. By the time this "while" > > passes, we'll be there. If people have lived this long with the bugs, > > they can last until late January. > > I find it hard to argue with that. Same here. I thought 4.5 was further off than that... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: wc* function
Alexey Zelkin wrote: > > According to mail archive, work on supporting wide-char functions was in > > progress some time but then stopped. > > > > May be is there some results of this work somewhere? Continue will better > > than beginning from scratch. > > Check out Citrus[1] project's CVS Repo. They have quite promising implementation > of w* functions. Also as I recall correctly some amount of w* functions > are already commited in. The w* functions are all implemented in work which Sun made available as part of the stuff they gave to the X Consortium under the OpenView release. The license is BSD-like in the extreme. There are some patches to it that were done by WIDE, in Japan, but they are incredibly minor (might as well have them, though). Go searching for OpenView in relation to X11, and you will find the code. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can TCP changes be put in RELENG_4?
In article <[EMAIL PROTECTED]>, Matthew Dillon <[EMAIL PROTECTED]> wrote: > These changes are performance fixes, not security fixes. I consider > them fairly significant performance fixes, but these bugs have been in > the TCP stack for literally a whole year without an outcry so I don't > see much justification for putting them into the security branch. > > -Matt Yep, I agree 100%. The purpose of the security branch was spelled out clearly from day one. People who want something else can move to -stable. John -- John Polstra 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: marking disks
Brooks Davis wrote: > > It would be easiest for you to create a partition table on the > > disk, and steal a table entry with a "magic" partition type to > > indicate that either the LBA or CHS data was actually version or > > type information, etc.. > > The thing I'm worried about there is that some "smart" bios or os might > sanity check the values and refuse to work with the drive. Is that a > likely scenerio? As long as you never marked the entry active, or ever used the data in it for other than your "magic" application, I don't see a problem. The BIOS only cares about active partitions, and then only when it is trying to boot ffrom them. If you want to play it safe, use entry #4 (if it's free) instead of entry #1 (option base 1). I have seen a number of RAID products that used partition table entries for stripe set identifiers before. While it's theoretically possible for something to care about it, it's incredibly unlikely. New partition types happen all the time, and most partition types are "spoken for". At a bare minimum, you should be able to use a very old partition type, make it valid, and then use the LBA fields (32 bit sector offset and length) to save your data, since very old things like the original FAT types, never referenced those fields at all. If you plan on hacking up fdisk, please teach it about partition type 27 (decimal), which is "Partition Magic". It doesn't affect its operation or FreeBSD's ability to mount the things as FAT32 drives, but it is moderately annoying to see "unknown" out there... 8^). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can TCP changes be put in RELENG_4?
On Wednesday 05 December 2001 01:19 pm, Leo Bicknell wrote: > On Tue, Dec 04, 2001 at 11:48:52AM -0500, Jim Durham wrote: > > I know that only security fixes are supposed to go in RELENG_4, but > > the recent changes in the TCP stuff seem important enough that > > perhaps they could be put in RELENG_4 for those of us who run > > productions servers on -RELEASE ? > > After reading the replies a bit, I'm going to suggest some middle > ground. > > I think the changes should sit in stable for "a while", and while > they are there we should make notes of it in a few different places > and have people beat up on the changes with various tests. > > I think this is very good stuff, and that most of the people > tracking RELENG4_4 would want it, but only if it is 210% fully > tested and helps out 99.999% of all people. So let's verify > both of those and then revisit the issue. Well, sounds fine to me, especially if 4.5 is so close. Incidentally, I applied the patches to 4.4-RELEASE on my 'test' box and my laptop. I tried an FTP transfer between the two that previously did 500kB/sec and it is now 954kB/sec. Mucho better. -- Jim Durham To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can TCP changes be put in RELENG_4?
Matthew Dillon wrote: > > These changes are performance fixes, not security fixes. I consider > them fairly significant performance fixes, but these bugs have been in > the TCP stack for literally a whole year without an outcry so I don't > see much justification for putting them into the security branch. I think the main question is whether or not Linux should continue to kick FreeBSD's ass after 4.5 is released. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can TCP changes be put in RELENG_4?
In message <[EMAIL PROTECTED]> Mike Barcroft writes: : Did I miss a change in policy? The original announcement about : RELENG_4_3 said: That text didn't accurately reflect the agreement that the security officer and the release engineer came to when we set things up. There can be critical bug fixes, but they have to be very very severe. The more things that change in these branches, the harder it is to do binary patches. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Tracking down system freeze
In message <[EMAIL PROTECTED]> Alfred Perlstein writes: : What you do is fold a paperclip then use it to make the last : two pins of the ISA bus short: and it doesn't work on PCI bus, or any other bus than ISA (except maybe EISA). I have a small ISA card that I have connected to the parallel port for remote NMI generation/reset. But it is a gross hack. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can TCP changes be put in RELENG_4?
Terry Lambert wrote: > I think the main question is whether or not Linux should continue > to kick FreeBSD's ass after 4.5 is released. ^- until -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can TCP changes be put in RELENG_4?
It will be still a defacto, because Linux distributions will always install tuned version of Linux kernel as default while FreeBSD not, the default GENERIC FreeBSD kernel's performace sucks, and ordinary user will find FreeBSD is slower, could we let user to select which kernel to install at installing time? -- David Xu Terry Lambert wrote: >Matthew Dillon wrote: > >>These changes are performance fixes, not security fixes. I consider >>them fairly significant performance fixes, but these bugs have been in >>the TCP stack for literally a whole year without an outcry so I don't >>see much justification for putting them into the security branch. >> > >I think the main question is whether or not Linux should continue >to kick FreeBSD's ass after 4.5 is released. > >-- Terry > >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: 4G phisical memory kernel trap
Tim Wiess wrote: > > Alexander, > I had experienced this problem before. It is most likely that you are running > out of page table pages. Try changing NKPT in /sys/i386/include/pmap.h to 64. > That worked for me. > > tim > > On Wed, Dec 05, 2001 at 03:57:22PM +0300, Varshavchick Alexander wrote: > > Hi, > > > > I have a PIII box with 4G phisical memory and FreeBSD 4.2 and it traps > > while booting - "fatal trap 12 page fault". With less than 4G memory the > > server is working good. He will still se problems under load, if he does this. In particular, it will lead to panics under load. The primary problem with using 4G is that the KVA space is too small to use that much memory reasonably, because of the swap maps that get created in /sys/i386/i386/machdep.c, which are scaled to 3 times the KVA space. In general, the FreeBSD design was to support sparse memory maps, where the amount of physical RAM did not approach the limits of the address space. I worked around this once by changing the calculation significantly, so that there was not an overallocation of the mapping tables. To be able to put this extra memory to profitable use, you will need to be able to allocate kernel structures, such as sockets, mbufs, and open file table entries, tcpcb's and inpcb's in it. For this to work, you really MUST address the machdep.c problems. I also suggest increasing the KVA space from 3G to 4G. Another sugestion is that you should use 4M pages for most of this memory, if you can figure out how to do it (it's not hard, but there is some minor intelligence required, since you will end up getting more trap 12 faults if you aren't careful). The mere acto of going to 4M pages will save you 4K per 4M of pages times how many pages you have, or ~4M. You will also get a 4-6% performance increase, overall, depending on usage patterns. I really should write an article for Daemon New on the FreeBSD startup process at boot time, to fill in the gaps behind Matt Dillon's articles on FreeBSD VM after it has been started up. I will start work on one. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can TCP changes be put in RELENG_4?
David Xu wrote: > > It will be still a defacto, because Linux distributions will always > install tuned version of Linux kernel as default Tuned for what? > while FreeBSD not, the default GENERIC FreeBSD kernel's performace > sucks, For what application? > and ordinary user will find FreeBSD is slower, could we let user to > select which kernel to install at installing time? It's a possibility that I've considered, given that sysinstall had a hard time supporting installing FreeBSD from a single CDROM image to support both developers and the end product with a single "golden" system image. The problem with doing this is that it sort of grates against the idea of a "GENERIC" entirely. It also provides a false sense of security, should FreeBSD go to such a mechanism, and then have a canned "firewall" (for example). The main problem which needs addressing is that the allocation mechanisms are Schitzophrenic in whether they can be used at interrupt time, or not. If they can be used at interrupt time, then they require mapping preallocation, at a minimum, and then, generally, underlying page preallocation, as well. The problem with mapping preallocation, even if you eat the "allocation failed because of no backing pages" bullet (i.e. for mbuf allocations) is that it cuts chunks out of the KVA map which can then not be used for other applications. There is also a dichotomy in the mapping for swappable vs. non memory; swappable does best with 4K page mapping (for obvious reasons), while non-swappable does best with 4M mappings (also for obvious reasons). The only method I could think of to deal with this is to grow the non-swappable up and the swappable down (you would generally want to try to keep non-swappable memory low to permit access by hardware, and making swappable memory high has the advantage of being able to handle 16G of RAM on some current hardware, if you support bank selection of the top 1G (or 2G, if you are agressive). Really, it boils down to the allocation systems needing rewrite, and (painful as this is to say) a move away from type stable memory, to permit reuse, rather than static purposing of large blocks: static purposing is the primary reason a general turning can not be near optimal for a lot of applications. If you want to discuss this further, the -arch list is probably the best place to hold the discussion, since this is not a decision that can reasonably be made in -hackers. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bin/32261: dump creates a dump file much larger than sum of dumped files
On Wed, Dec 05, 2001 at 04:02:47PM +0100, Bernd Walter wrote: > On Tue, Dec 04, 2001 at 11:26:39PM -0800, Crist J . Clark wrote: [snip] > > From what Ian said elsewhere in this thread, the O_TRUNC already does > > not "act strange" on a tape device. I don't see any new POLA issues if > > adding O_TRUNC to the write call doesn't change how dump(8) has been > > working on tapes for FreeBSD for these n years now. The only POLA > > issue I see is the current behavior that "regular" files are _not_ > > truncated, which was the start of the thread and the issue in the PR. > > That FreeBSD tape devices ignore this isn't a strong reason to do. > People may also dump to disk devices, I tested it. They don't care about O_TRUNC. > unix domains sockets, fifo I tested it. They don't care about O_TRUNC. > devices or media your don't even know today. How can you say if O_TRUNC or !O_TRUNC will be the desired behavior? Right now, O_TRUNC is desired for plain ol' files. O_TRUNC doesn't make a difference for tapes, raw disks, or FIFOs. If we need to add support for something else in the future, fine. If a future media type wants O_TRUNC, it's already there. > And the fstat way don't hurt anyone but instead is an absolute save > way without expecting anything about the output stream behavour. So you are going to do a switch for every possible file type? But what about the future unknown types? What do you do for the default case? Why bother since what to do for all of the known cases can be the same and should work for unknown cases too. > > I don't see who would care if FreeBSD's dump(8) might have some funny > > reactions on UNIX-like systems where O_TRUNC has a different behavior > > on tape devices. I don't think the Project is overly concerned about > > porting FreeBSD's dump(8) to other OSes. > > But we might care porting device drivers to FreeBSD. This will have no impact on device drivers. > Think of that we may start and run linux kernel modules someday. If open(2) calls behave differently, dump(8) is going to be the least of our concerns. > I don't asume it to be very likely - but you never know. Nope, not very likely. How about I put this in CURRENT, let it sit for a while, and if anyone has problems, we can deal with them? I don't see a big problem here. -- "It's always funny until someone gets hurt. Then it's hilarious." Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4G phisical memory kernel trap
On Wed, 5 Dec 2001, Terry Lambert wrote: > > Alexander, > > I had experienced this problem before. It is most likely that you are running > > out of page table pages. Try changing NKPT in /sys/i386/include/pmap.h to 64. > > That worked for me. > > > > tim > > > > On Wed, Dec 05, 2001 at 03:57:22PM +0300, Varshavchick Alexander wrote: > Date: Wed, 05 Dec 2001 22:02:19 -0800 > From: Terry Lambert <[EMAIL PROTECTED]> > To: Tim Wiess <[EMAIL PROTECTED]> > Cc: Varshavchick Alexander <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: 4G phisical memory kernel trap > > Tim Wiess wrote: > > > > > Hi, > > > > > > I have a PIII box with 4G phisical memory and FreeBSD 4.2 and it traps > > > while booting - "fatal trap 12 page fault". With less than 4G memory the > > > server is working good. > > He will still se problems under load, if he does this. In particular, > it will lead to panics under load. > > > The primary problem with using 4G is that the KVA space is too > small to use that much memory reasonably, because of the swap maps > that get created in /sys/i386/i386/machdep.c, which are scaled to > 3 times the KVA space. > > In general, the FreeBSD design was to support sparse memory maps, > where the amount of physical RAM did not approach the limits of > the address space. > > I worked around this once by changing the calculation significantly, > so that there was not an overallocation of the mapping tables. > > To be able to put this extra memory to profitable use, you will > need to be able to allocate kernel structures, such as sockets, > mbufs, and open file table entries, tcpcb's and inpcb's in it. > > For this to work, you really MUST address the machdep.c problems. So how can it be done, are there any patches for machdep.c, or is it solved in 4.4-stable kernel? > > I also suggest increasing the KVA space from 3G to 4G. > You mean setting KVA_SPACE option in kernel config? > Another sugestion is that you should use 4M pages for most of > this memory, if you can figure out how to do it (it's not hard, > but there is some minor intelligence required, since you will > end up getting more trap 12 faults if you aren't careful). The > mere acto of going to 4M pages will save you 4K per 4M of pages > times how many pages you have, or ~4M. You will also get a 4-6% > performance increase, overall, depending on usage patterns. > I'm afraid I can have problems figuring this thing out, can you please give guidelines here? > I really should write an article for Daemon New on the FreeBSD > startup process at boot time, to fill in the gaps behind Matt > Dillon's articles on FreeBSD VM after it has been started up. > I will start work on one. > It will be great! Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
SHCC: National Sales Expansion Position Company for Rapid Growth N
Investment News Alert Tonight's Featured Company ShareCom, Inc. (OTCBB: SHCC) Current Price: $0.016 52 Week High: $2.49 52 Week Low: $0.0155 SHCC has established business relationships with FEMA, the American Red Cross, AAA, NOAA, and more. Partnerships and market advantage fuel exponential growth for SHCC. SHCC is currently booking revenues of $45,000 per month and projects revenues of $13 million for 2002. A Brief Introduction The Federal Emergency Management Agency (FEMA), the National Weather Service (NWS), the Red Cross and AAA are a but a few of the agencies and organizations with whom ShareCom Inc. has forged alliances to ensure clear competitive advantage for its product lines. The past 10 years have seen a dramatic increase in severe weather conditionsÿ85and with continued global warming these patterns will exacerbate. Prompted by FEMA and NWS aggressive programs, demand for the Companyÿ92s NOAA Weather Radio will soar. Today 7% of American homes possess a NOAA radioÿ85 the national goal is 100%. ShareComÿ92s www.WeatherRadios.com is the site for consumers to purchase the Companyÿ92s superior product at a significant discount. SHCC's revenue flow rate is at $45,000/month and growing. The Company will realize a profit this year and plans to triple it next.. SHCC's market dominance in this growing "bread and butter", niche business makes it an interesting acquisition candidate and a compelling investment. Reasons to Consider Buying SHCC 1. WeatherRadios.com has been awarded a National Partnership with the Federal Emergency Management Agency (FEMA) to increase the use of Weather Radios country wide through a program called Project Impact. There are 2,600 Project Impact communities in the U.S. The FEMA web site lists WeatherRadios.com as a national partner providing a banner and link to the WeatherRadios.com site. The FEMA site receives over 100,000 visitors per day. 2. The National Oceanic and Aerospace Administration (NOAA) has WeatherRadios.com listed first on their web site page that tells people where to purchase a NOAA Weather Radio. 3. The National Weather Service (NWS) has offered to promote corporate sponsorships to the WeatherRadios.com site through recognition and media support. 4. Local American Red Cross chapters will promote NOAA Weather Radios through WeatherRadios.com in exchange for a $5.00 donation per sold radio. 5. The Chicago area AAA will feature 2WayTalk.com on its web site offering exclusive discounts on Weather Radios, and FRS Family Radios. 2WayTalk.com will also be listed in the AAA magazine called "H
dhcpd problem
I'm having trouble configuring my dhcpd. This is the config file I've nocked up: start config file -- default-lease-time 3600; max-lease-time 9; ddns-update-style ad-hoc; option subnet-mask 255.255.255.0; option broadcast-address 192.10.10.255; option domain-name-servers 194.168.8.100,194.168.4.100; option domain-name dolphintime; end config file -- When I try to start dhcpd (by running "/usr/local/etc/rc.d/dhcpd") I get the following error: start error message -- No subnet declaration for xl1 (80.x.x.x). ** Ignoring requests on xl1. If this is not what you want, please write a subnet declaration in your dhcpd.conf file for the network segment to which interface xl1 is attached. ** No subnet declaration for xl0 (192.10.10.4). ** Ignoring requests on xl0. If this is not what you want, please write a subnet declaration in your dhcpd.conf file for the network segment to which interface xl0 is attached. ** Not configured to listen on any interfaces! end error message -- Any suggestions will be really appreciated! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
