Re: Save a few hunderd kilobytes or a few hundred perl users?
NetBSD (-current, at least) does not have perl in the base. OpenBSD has 5.6.something. *NOD* Perhaps FreeBSD could benefit from following NetBSD, and use awk or whatever to replace the perl stuff for kernel build and wherever else. We've already sorted that out for the kernel build. I'm going to see how well miniperl works for the userland perl scripts. People who actually want perl could then install a miniperl package and as many modules as they need or like, up to and including the very latest full-bloat^H^Hwn version, if desired. I reckon we'll keep miniperl for a while. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn #text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc #application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users?
I'm not sure that is acceptable. I believe that perl 5.8.0 will be +- 45 MB. I cannot afford to import all of that - I'd get lynched. that is price, for example, for Unicode. Okay, when many platforms will be doing stripping their tools, everyone should remember where his perl programs are able to run and where they are not and require additional dowloading. (I remember how I was disappointed that Redhat linux distribution did not contained Tk in its distribution, even for optional installation. It was a pain to rebuild) For me, nowadays 45MB is nothing compared to medium HDD capacity, and even my POCKET PC will easily accomodate it... Vadim. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
PHY patch, please test.
This patch simplifies the auto-negotiation in the MII/PHY code, but I don't have enough weird ethernet cards to test it out. Please test and if it doesn't work send me dmesg -v output and info on what netcard it breaks. http://phk.freebsd.dk/patch/phy00.patch I hope to commit it this weekend. I am also interested to hear from people using the NetGear 622 or other if_nge based gigabit cards. Thanks in advance! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
lock order reversal in uma_core.c
I'm seeing this reversal: lock order reversal 1st 0xc8b01664 DIRHASH (UMA zone) @ ../../../vm/uma_core.c:527 2nd 0xc042a724 PCPU KMAP ENTRY (UMA cpu) @ ../../../vm/uma_core.c:1301 Is this known? -- Jonathan Mini [EMAIL PROTECTED] http://www.haikugeek.com He who is not aware of his ignorance will be only misled by his knowledge. -- Richard Whatley To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PHY patch, please test.
Poul-Henning Kamp wrote: This patch simplifies the auto-negotiation in the MII/PHY code, but I don't have enough weird ethernet cards to test it out. Please test and if it doesn't work send me dmesg -v output and info on what netcard it breaks. http://phk.freebsd.dk/patch/phy00.patch I hope to commit it this weekend. So, in a nutshell, you removed the ability for the card driver to request the phy driver to wait for negotiation to complete, and removed the interlock that prevents duplicate negotiation requests when the negotiation took longer than the allotted time? Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cc1 crashes with SIGBUS while building XFree86-Server-4.2.0_2
On Tue, Apr 30, 2002 at 06:24:14PM -0400, Forrest Aldrich wrote: I've experienced this same problem today; but only after installing 5.0-current on the system in question. It compiled fine with FreeBSD_4.5. This is a 1.2ghz Pentium with 1gb of RAM. No problems with other things (large compile projects with 4.5 before). I have been building XFree86 without problems, until I updated my -CURRENT system (I did the previous update three months ago). I don't think that this is a hardware related problem. My -CURRENT system is running on an 800 MHz Duron (KT133 chipset), and performs flawlessly otherwise, including large builds such as make worlds. The kernel has all debugging options removed, and the malloc.conf options are aj. -- ** Jose M. Alcaide // [EMAIL PROTECTED] // [EMAIL PROTECTED] ** ** Beware of Programmers who carry screwdrivers -- Leonard Brandwein ** To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users?
Johnny Lam [EMAIL PROTECTED] writes: perl-5.10.0 perl-library-standard-1.0 perl-library-ISP-1.0 ... Whatever approach we take, two major problems must be solved to accomplish this: 1: A perl distribution must be able to be (re)located anywhere and use itself as a starting point to find its additional libraries and modules. The way ActiveState's rpm handles it (by patching the binaries and scripts) works, but defeats the rpm functionality to verify an installation. 2: Add-on modules (base-perl and site-perl) must be able to fit themselves into an existing perl installation so they can be distributed in prebuilt form. In short, we need componentized, prebuilt distributions. Is this being worked on already? -- Johan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users?
Johan Vromans [EMAIL PROTECTED] wrote: :Johnny Lam [EMAIL PROTECTED] writes: : : perl-5.10.0 : perl-library-standard-1.0 : perl-library-ISP-1.0 : ... : :Whatever approach we take, two major problems must be solved to :accomplish this: : 1: A perl distribution must be able to be (re)located anywhere and :use itself as a starting point to find its additional libraries :and modules. :The way ActiveState's rpm handles it (by patching the binaries and :scripts) works, but defeats the rpm functionality to verify an :installation. : 2: Add-on modules (base-perl and site-perl) must be able to fit :themselves into an existing perl installation so they can be :distributed in prebuilt form. : :In short, we need componentized, prebuilt distributions. : :Is this being worked on already? Not that I'm aware; volunteers welcome. Hugo To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
clock drift in -CURRENT
Hi, after almost 50 days of uptime I suddenly noticed an extreme clock drift in current. Here is an excerpt from my /var/log/messages (March 8th was my last reboot time): Mar 8 18:38:07 gate syslogd: kernel boot file is /boot/kernel/kernel Mar 8 18:38:07 gate kernel: Copyright (c) 1992-2002 The FreeBSD Project. [...] Apr 27 20:03:10 gate ntpd[157]: time reset -0.250532 s Apr 27 20:18:14 gate ntpd[157]: time reset 0.446208 s Apr 27 20:39:57 gate ntpd[157]: time reset -0.820100 s Apr 27 21:11:19 gate ntpd[157]: time reset 0.887949 s Apr 27 21:25:33 gate ntpd[157]: time reset -0.228488 s Apr 27 21:54:35 gate ntpd[157]: time reset -0.395676 s Apr 28 12:59:15 gate ntpd[157]: time reset -0.381327 s Apr 28 13:19:52 gate ntpd[157]: time reset 0.815323 s Apr 28 13:31:50 gate ntpd[157]: time reset 0.844171 s Apr 28 13:58:52 gate ntpd[157]: time reset 1.447538 s Apr 28 14:14:58 gate ntpd[157]: time reset 0.915263 s Apr 28 14:36:38 gate ntpd[157]: time reset 0.860966 s Apr 28 14:47:29 gate ntpd[157]: time reset 0.984839 s Apr 28 15:06:59 gate ntpd[157]: time reset 1.025584 s Apr 28 15:27:32 gate ntpd[157]: time reset 1.156623 s Apr 28 15:48:59 gate ntpd[157]: time reset 0.896726 s Apr 28 16:00:52 gate ntpd[157]: time reset 0.973291 s Apr 28 16:24:24 gate ntpd[157]: time reset 1.212415 s Apr 28 16:37:19 gate ntpd[157]: time reset 0.859379 s Apr 28 16:56:49 gate ntpd[157]: time reset 0.914863 s Apr 28 17:13:05 gate ntpd[157]: time reset 1.100234 s Apr 28 17:35:59 gate ntpd[157]: time reset 1.231416 s Apr 28 17:59:53 gate ntpd[157]: time reset 1.026558 s Apr 28 18:11:59 gate ntpd[157]: time reset 0.995554 s Apr 28 18:34:45 gate ntpd[157]: time reset 1.140261 s Apr 28 18:54:19 gate ntpd[157]: time reset 0.856611 s Apr 28 19:07:15 gate ntpd[157]: time reset 1.094226 s Apr 28 19:22:30 gate ntpd[157]: time reset 0.879816 s Apr 28 19:47:25 gate ntpd[157]: time reset 1.332108 s Apr 28 20:06:56 gate ntpd[157]: time reset 0.949128 s Apr 28 20:28:27 gate ntpd[157]: time reset 0.906657 s Apr 28 20:41:37 gate ntpd[157]: time reset 0.877976 s Apr 28 20:57:57 gate ntpd[157]: time reset 1.103012 s Apr 28 21:28:19 gate ntpd[157]: time reset 1.607870 s Apr 28 21:59:43 gate ntpd[157]: time reset 1.253603 s Apr 28 22:14:46 gate ntpd[157]: time reset 1.181729 s Apr 28 22:47:13 gate ntpd[157]: time reset 1.573263 s Apr 28 23:07:47 gate ntpd[157]: time reset 0.836291 s Apr 28 23:20:52 gate ntpd[157]: time reset 1.105955 s Apr 28 23:35:59 gate ntpd[157]: time reset 0.839469 s [...] So the machine is losing a second every 20 minutes. After a reboot everything was OK again. The drift began exactly at the moment the counter for clock interrupts got past the 2^31 mark (I have HZ=500 in the kernel): 500 ticks/s * 49.7 days ~ 2^31 ticks After a reboot everything went ok again. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: clock drift in -CURRENT
When was your source tree from on that kernel ? I'm not too confident in your diagnosis, mostly because we don't have a counter like you describe :-) My guess is that ntpd get confused. Please try a newer kernel, a number of bug(lets) have been fixed since march. If it happens again, please email me the output of: ntpdc -c peer ntpdc -c loopi ntpdc -c kerni dmesg Thanks! Poul-Henning In message [EMAIL PROTECTED], Daniel Rock writes: Hi, after almost 50 days of uptime I suddenly noticed an extreme clock drift in current. Here is an excerpt from my /var/log/messages (March 8th was my last reboot time): Mar 8 18:38:07 gate syslogd: kernel boot file is /boot/kernel/kernel Mar 8 18:38:07 gate kernel: Copyright (c) 1992-2002 The FreeBSD Project. [...] Apr 27 20:03:10 gate ntpd[157]: time reset -0.250532 s Apr 27 20:18:14 gate ntpd[157]: time reset 0.446208 s Apr 27 20:39:57 gate ntpd[157]: time reset -0.820100 s Apr 27 21:11:19 gate ntpd[157]: time reset 0.887949 s Apr 27 21:25:33 gate ntpd[157]: time reset -0.228488 s Apr 27 21:54:35 gate ntpd[157]: time reset -0.395676 s Apr 28 12:59:15 gate ntpd[157]: time reset -0.381327 s Apr 28 13:19:52 gate ntpd[157]: time reset 0.815323 s Apr 28 13:31:50 gate ntpd[157]: time reset 0.844171 s Apr 28 13:58:52 gate ntpd[157]: time reset 1.447538 s Apr 28 14:14:58 gate ntpd[157]: time reset 0.915263 s Apr 28 14:36:38 gate ntpd[157]: time reset 0.860966 s Apr 28 14:47:29 gate ntpd[157]: time reset 0.984839 s Apr 28 15:06:59 gate ntpd[157]: time reset 1.025584 s Apr 28 15:27:32 gate ntpd[157]: time reset 1.156623 s Apr 28 15:48:59 gate ntpd[157]: time reset 0.896726 s Apr 28 16:00:52 gate ntpd[157]: time reset 0.973291 s Apr 28 16:24:24 gate ntpd[157]: time reset 1.212415 s Apr 28 16:37:19 gate ntpd[157]: time reset 0.859379 s Apr 28 16:56:49 gate ntpd[157]: time reset 0.914863 s Apr 28 17:13:05 gate ntpd[157]: time reset 1.100234 s Apr 28 17:35:59 gate ntpd[157]: time reset 1.231416 s Apr 28 17:59:53 gate ntpd[157]: time reset 1.026558 s Apr 28 18:11:59 gate ntpd[157]: time reset 0.995554 s Apr 28 18:34:45 gate ntpd[157]: time reset 1.140261 s Apr 28 18:54:19 gate ntpd[157]: time reset 0.856611 s Apr 28 19:07:15 gate ntpd[157]: time reset 1.094226 s Apr 28 19:22:30 gate ntpd[157]: time reset 0.879816 s Apr 28 19:47:25 gate ntpd[157]: time reset 1.332108 s Apr 28 20:06:56 gate ntpd[157]: time reset 0.949128 s Apr 28 20:28:27 gate ntpd[157]: time reset 0.906657 s Apr 28 20:41:37 gate ntpd[157]: time reset 0.877976 s Apr 28 20:57:57 gate ntpd[157]: time reset 1.103012 s Apr 28 21:28:19 gate ntpd[157]: time reset 1.607870 s Apr 28 21:59:43 gate ntpd[157]: time reset 1.253603 s Apr 28 22:14:46 gate ntpd[157]: time reset 1.181729 s Apr 28 22:47:13 gate ntpd[157]: time reset 1.573263 s Apr 28 23:07:47 gate ntpd[157]: time reset 0.836291 s Apr 28 23:20:52 gate ntpd[157]: time reset 1.105955 s Apr 28 23:35:59 gate ntpd[157]: time reset 0.839469 s [...] So the machine is losing a second every 20 minutes. After a reboot everything was OK again. The drift began exactly at the moment the counter for clock interrupts got past the 2^31 mark (I have HZ=500 in the kernel): 500 ticks/s * 49.7 days ~ 2^31 ticks After a reboot everything went ok again. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: clock drift in -CURRENT
On Wed, 1 May 2002, Poul-Henning Kamp wrote: When was your source tree from on that kernel ? I'm not too confident in your diagnosis, mostly because we don't have a counter like you describe :-) From kern_clock.c: %%% int ticks; %%% but this is treated as an cyclic counter so its overflow shouldn't matter on machines where overflow doesn't trap. [context lost to top posting] Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: clock drift in -CURRENT
I had the same symptoms (drifting about 2 minutes an hour) on sources before April 17 or so. Since then, ntpd has only logged 5 time updates, as opposed to 3 per hour. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users?
[Quoting Hugo van der Sanden, on May 1 2002, 15:06, in Re: Save a few hunde] Johan Vromans [EMAIL PROTECTED] wrote: :Whatever approach we take, two major problems must be solved to :accomplish this: : 1: A perl distribution must be able to be (re)located anywhere and :use itself as a starting point to find its additional libraries :and modules. :The way ActiveState's rpm handles it (by patching the binaries and :scripts) works, but defeats the rpm functionality to verify an :installation. : 2: Add-on modules (base-perl and site-perl) must be able to fit :themselves into an existing perl installation so they can be :distributed in prebuilt form. : :In short, we need componentized, prebuilt distributions. : :Is this being worked on already? Not that I'm aware; volunteers welcome. Okay, I'll bite. Who joins? -- Johan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users?
I'm not sure that is acceptable. I believe that perl 5.8.0 will be +- 45 MB. I cannot afford to import all of that - I'd get lynched. that is price, for example, for Unicode. Okay, when many platforms will be doing stripping their tools, everyone should remember where his perl programs are able to run and where they are not and require additional dowloading. (I remember how I was disappointed that Redhat linux distribution did not contained Tk in its distribution, even for optional installation. It was a pain to rebuild) For me, nowadays 45MB is nothing compared to medium HDD capacity, and even my POCKET PC will easily accomodate it... 45 MB is fine as a port - we have ports that are way bigger than that. As part of the base OS? Nope. The only functionality that we _need_ is the basic language - effectively miniperl. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn #text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc #application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users?
Debian's perl-base is a little bit more than miniperl but it still is only 1.2MB (ix86). -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users?
On Thursday, May 2, 2002, at 12:56 , Mark Murray wrote: For me, nowadays 45MB is nothing compared to medium HDD capacity, and even my POCKET PC will easily accomodate it... 45 MB is fine as a port - we have ports that are way bigger than that. And we even have bigger ports that does take longer to build than 'make buildworld' the whole FreeBSD (which takes less than 30 minutes on Athron XP 1400 -- the fastest box I have at my fingertip). As part of the base OS? Nope. The only functionality that we _need_ is the basic language - effectively miniperl. But to sensibly strip down the distribution to just as much as needed does take a lot of something the most precious -- intellectual power. That I consider a waste. I don't think anyone objects that there are several hundred, or even thousand, files under /usr/src so long as it builds and so long as it nicely fits -- say, in a CD-ROM. FreeBSD 4.5-stable as of now is just 364,149 kBytes UNCOMPRESSED. Why don't you just untargz what Perl 5 porter has to offer and forget about what files should go and stay? You can easily install only needed parts. Speaking of which, the whole build process does not use objective-C (correct me if I am wrong). So if you insist on stripping Perl it may as well be unfair to leave GCC unstripped (I pretty much doubt GPL allows you to do so, however). Dan the Wanted for Bloating Perl 5.8 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users?
But to sensibly strip down the distribution to just as much as needed does take a lot of something the most precious -- intellectual power. That I consider a waste. I don't think anyone objects that there are several hundred, or even thousand, files under /usr/src so long as it builds and so long as it nicely fits -- say, in a CD-ROM. FreeBSD 4.5-stable as of now is just 364,149 kBytes UNCOMPRESSED. Why don't you just untargz what Perl 5 porter has to offer and forget about what files should go and stay? You can easily install only needed parts. Well, my understanding is that this is exactly what Mark is talking about-- for the needs of the FreeBSD itself (build, pksrc?) they don't need all of Perl. For that miniperl or something like Debian's perl-base where you don't start by leaving out what you don't need but instead by taking in only what one absolutely needs. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users?
On Thursday, May 2, 2002, at 12:56 , Mark Murray wrote: For me, nowadays 45MB is nothing compared to medium HDD capacity, and even my POCKET PC will easily accomodate it... 45 MB is fine as a port - we have ports that are way bigger than that. And we even have bigger ports that does take longer to build than 'make buildworld' the whole FreeBSD (which takes less than 30 minutes on Athron XP 1400 -- the fastest box I have at my fingertip). As part of the base OS? Nope. The only functionality that we _need_ is the basic language - effectively miniperl. But to sensibly strip down the distribution to just as much as needed does take a lot of something the most precious -- intellectual power. Nope - it is trivial. We already make miniperl. We just need to install it and not install the rest of perl. 10 mins to do the work, and on-and-off fiddling to make the world build complete. M That I consider a waste. I don't think anyone objects that there are several hundred, or even thousand, files under /usr/src so long as it builds and so long as it nicely fits -- say, in a CD-ROM. FreeBSD 4.5-stable as of now is just 364,149 kBytes UNCOMPRESSED. Why don't you just untargz what Perl 5 porter has to offer and forget about what files should go and stay? You can easily install only needed parts. Bloat. Its easy to rm -rf stuff where stuff != unix, and other simple rules. Speaking of which, the whole build process does not use objective-C (correct me if I am wrong). So if you insist on stripping Perl it may as well be unfair to leave GCC unstripped (I pretty much doubt GPL allows you to do so, however). We strip GCC. We strip most things that we install in src/contrib. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn #text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc #application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users?
On Wed, 1 May 2002, Jarkko Hietaniemi wrote: Well, my understanding is that this is exactly what Mark is talking about-- for the needs of the FreeBSD itself (build, pksrc?) they don't need all of Perl. For that miniperl or something like Debian's perl-base where you don't start by leaving out what you don't need but instead by taking in only what one absolutely needs. [I have removed perl5-porters from the CC list since I don't think that's necessarily the best forum to give unbiased advice about balancing different needs in setting up the base FreeBSD system :-). Also, it was seeming to generate more heat than light.] This is an issue for many distributions. Solaris too is considering doing something like that. It's very sane and sensible to consider. Presumably, the resulting stripped package will be named or identified in such a way that it is clear that it's not the standard package, and it will be easy for users to install the standard package once they have everything else set up. If so, I don't see any problems. A former perl maintainer, Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PHY patch, please test.
In message [EMAIL PROTECTED], Peter Wemm writes: Poul-Henning Kamp wrote: This patch simplifies the auto-negotiation in the MII/PHY code, but I don't have enough weird ethernet cards to test it out. Please test and if it doesn't work send me dmesg -v output and info on what netcard it breaks. http://phk.freebsd.dk/patch/phy00.patch I hope to commit it this weekend. So, in a nutshell, you removed the ability for the card driver to request the phy driver to wait for negotiation to complete, and removed the interlock that prevents duplicate negotiation requests when the negotiation took longer than the allotted time? yes and yes. The wait for negotiation to complete does not make sense, and in particular the 500ms worth of DELAY() calls is totally bogus. If a driver wants to wait 500msec and see if it got link, it should wait 500msec for and query status or better yet: just react to the events coming back up to it about like and state changes. There is no such thing as duplicate autoneg requests, if you send a new one (like we do after the 5 or 10 sec timeout) the negotiation starts over. The 5 seconds for 10/100 is probably a couple of seconds too short but we don't notice because 10/100 negotiation is very fast (sub second). The 10 seconds for gigE _is_ too short, since cisco switches may hold carrier down for several seconds, and it may take a couple of tries of a couple (of a couple of seconds each) to get the line equalization right. (I'm still experimenting with this bit.) In general, I think we need a much more capable state engine for the autoneg stuff. Right now we start our timeout when we start autonegotiation, but carrier from the remote end may not appear for another N seconds, so our timeout must be long enough for that AND the basic negotiation timeout. We should probably have a short timeout (maybe 5 seconds) when we receive no carrier, from we see carrier we until we abort 10/100 autoneg should probably be a 10 sec delay and for gigE autoneg more like 30 seconds. Things are compounded by driver mistakes like the if_nge driver calling mii_tick() for every MII/PHY interrupt in addition to every second, this makes any timeout shorter by about 3 seconds in practice since the PHY typically sends 3 interrupts per autonegotiation. And as you said yourself: there is additional NEWBUS'ing to be done in this area. I've sent email to a couple of strategig NetBSD'ers, but received no replies. I don't have time to go all the way through this area, but I have a need to get NetGear622 solid and working and I'll do what it takes to get that done at least. Volounteers welcome. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cc1 crashes with SIGBUS while building XFree86-Server-4.2.0_2
On Wed, 1 May 2002 13:32:35 +0200, Jose M. Alcaide [EMAIL PROTECTED] said: I have been building XFree86 without problems, I just rebuilt both -current (Friday or Saturday timeframe) and all of X (last night) without a problem. (Well, other than all of the old binaries I need to recompile now...) -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Avoid: Acer TravelMate laptop + -current
Hi, While doing network installs of recent -current versions (FTP NFS), I have experienced a problem I can't live with - and which needs the laptop to be sent to Acer to get fixed. The problem is: the installation freezes (usually quite early in the installation process, doing /bin or something), and after a hard reset (power off + on), the darn craptop has PlatinumPAS - PreBoot Authentication Services Verify enabled.. This is a protection mode which needs a valid smartcard to unlock the computer, which makes the BIOS not let you boot from anything. I didn't ask for it to get enabled, and the smartcards I got with the computer are not valid. I can't even boot a floppy at that stage, and I don't know of any way to fix it except send it to Acer for repair (already did it once, I'm not happy about doing it once more in one week). I'm planning to stop using this laptop (since it belongs to my company: ask them to throw it to the junkyard or something), unless there is some neat trick to disable the PlatinumPAS thing, or if there's a solution to making -current not switch it on. In the meantime: my advice for all Acer TravelMate users is to not use or try -current on them. Cheers, -- Anders. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Avoid: Acer TravelMate laptop + -current
On Wed, May 01, 2002 at 08:54:16PM +0200, Anders Nordby wrote: While doing network installs of recent -current versions (FTP NFS), I have experienced a problem I can't live with - and which needs the laptop to be sent to Acer to get fixed. I should add: my laptop is an Acer TravelMate 613 TXV laptop. Cheers, -- Anders. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cc1 crashes with SIGBUS while building XFree86-Server-4.2.0_2
On Tue, 2002-04-30 at 10:35, Ian wrote: cpp0: cc: output pipe has been closedInternal compiler error: program cc1 got fatal signal 10 I have seen cc1 die like this many many times, and have only ever seen 2 root causes for the death: 1) bad ram 2) you overclocked the cpu or bus just a bit too much How about signal 4? I was rebuilding my -current the other day and I kept getting mostly signal 4 errors (in different places) with a couple of signal 10's and 11's. I tried finding a run-down of what the various errors meant, but I couldn't find a thing. The weird thing is that when I switched terminals in KDE (i.e. opened a new Konsole window), my build problems ceased. Windows XP runs on the same box with no problems (i.e. will run for weeks without a reboot) so I'm a little hesitant to blame my hardware. -Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: clock drift in -CURRENT
Poul-Henning Kamp schrieb: When was your source tree from on that kernel ? I'm not too confident in your diagnosis, mostly because we don't have a counter like you describe :-) My guess is that ntpd get confused. Please try a newer kernel, a number of bug(lets) have been fixed since march. If it happens again, please email me the output of: ntpdc -c peer ntpdc -c loopi ntpdc -c kerni dmesg [...] My kernel war relatively recent at the time of last boot - build around March 2nd from -CURRENT sources a few hours before. If someone runs -CURRENT with default HZ of 100 and moans 247 days later, his -CURRENT cannot be called -CURRENT any more... I am now running an up-to-date -CURRENT. I have set HZ=1, so I don't have to wait another 50 days. Hope this high HZ value has no negative impact on the test. I will inform you in 3 days if anything strange happens again. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
newsyslog(8) should wait(2) for children
Does anyone object to the next patch:
Index: newsyslog.c
===
RCS file: /home/ncvs/src/usr.sbin/newsyslog/newsyslog.c,v
retrieving revision 1.41
diff -u -r1.41 newsyslog.c
--- newsyslog.c 10 Apr 2002 10:38:44 - 1.41
+++ newsyslog.c 1 May 2002 19:15:40 -
@@ -38,6 +38,7 @@
#include ctype.h
#include err.h
+#include errno.h
#include fcntl.h
#include grp.h
#include paths.h
@@ -135,6 +136,12 @@
p = p-next;
free((char *) q);
q = p;
+ }
+ for (;;) {
+ if (wait(NULL) 0) {
+ if (errno != EINTR)
+ break;
+ }
}
return (0);
}
%%%
--
Maxim Konovalov, MAcomnet, Internet Dept., system engineer
phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: clock drift in -CURRENT
In message [EMAIL PROTECTED], Daniel Rock writes: Poul-Henning Kamp schrieb: When was your source tree from on that kernel ? I'm not too confident in your diagnosis, mostly because we don't have a counter like you describe :-) My guess is that ntpd get confused. Please try a newer kernel, a number of bug(lets) have been fixed since march. If it happens again, please email me the output of: ntpdc -c peer ntpdc -c loopi ntpdc -c kerni dmesg [...] My kernel war relatively recent at the time of last boot - build around March 2nd from -CURRENT sources a few hours before. Right, but look at a cvs log src/sys/kern/kern_tc.c... I've fixed at least one bug in the NTP steering since then. If someone runs -CURRENT with default HZ of 100 and moans 247 days later, his -CURRENT cannot be called -CURRENT any more... :-) I am now running an up-to-date -CURRENT. I have set HZ=1, so I don't have to wait another 50 days. Hope this high HZ value has no negative impact on the test. I will inform you in 3 days if anything strange happens again. Cool. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users?
On Thu, May 02, 2002 at 01:17:40AM +0900, Dan Kogai wrote: Speaking of which, the whole build process does not use objective-C (correct me if I am wrong). The cost of Objective-C, given we have to have C, is 1 minute in build time, and 390K of diskspace (installed). This is several orders of manitude below Perl 5.6.x. So if you insist on stripping Perl it may as well be unfair to leave GCC unstripped (I pretty much doubt GPL allows you to do so, however). Why in the world do you think the GPL prevents that? -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Save a few hunderd kilobytes or a few hundred perl users?
Title: RE: Save a few hunderd kilobytes or a few hundred perl users? One possible solution might be as follow; rename /usr/src/contrib/perl5 to /usr/src/contrib/miniperl5 and just add enough file to build miniperl. I've read all the messages in this thread, but I'm still unclear -- are we talking about building the miniperl that Perl already creates during the build process? If not, the minimal perl for building the FreeBSD kernel should have a different name, like: smallperl modestperl tightperl midgetperl petiteperl or something similar. I see much potential for confusion if miniperl means different Perl builds in different contexts. === Mark Leighton Fisher [EMAIL PROTECTED] Thomson multimedia, Inc. Indianapolis IN We have tamed lightning and used it to teach sand to think
Re: Save a few hunderd kilobytes or a few hundred perl users?
On Wed, May 01, 2002 at 03:00:45PM -0500, Fisher Mark wrote: One possible solution might be as follow; rename /usr/src/contrib/perl5 to /usr/src/contrib/miniperl5 and just add enough file to build miniperl. I've read all the messages in this thread, but I'm still unclear -- are we talking about building the miniperl that Perl already creates during the build process? If not, the minimal perl for building the FreeBSD kernel should have a different name, like: smallperl modestperl tightperl midgetperl petiteperl or something similar. I see much potential for confusion if miniperl means different Perl builds in different contexts. Yes, if it is anything more than the one single executable miniperl, it should be called something else (it probably should have something a little bit more, again, see Debian's perl-base for a reasonable set of functionality). I STRONGLY suggest that this discussion should get it's own mailing list, though, this is off topic for both perl5-porters and freebsd-current. I'm certain both those lists are busy enough, and OS distrib people need a common ground. [EMAIL PROTECTED]? Ask, could you create the list? -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 3Com 3c905C-TX
On Mon, Apr 29, 2002 at 08:08:02PM +0300, Danny Braniss wrote: at 100baseTX full-duplex is slower than 10Mgb :-( Same problem here with the xl0 driver. My 3Com 3c905C-TX Fast Etherlink XL connects to a Cisco Micro Switch (1548, unmanaged). According to the lights on the back of the switch everything runs at 100 Mbits full-duplex initially (that is after a reboot). However after a while the switch indicates that it is running at 100 Mbits half-duplex. I don't know what causes it, but this is happening for at least a month. When this happens 'ifconfig -a' will still report that everything is running at 100 Mbits full-duplex. Judging from the performance and what the Cisco switch indicates this is not true, it is running half-duplex! Unfortunately the switch is unmanaged hence I am not able to explicitely set the switch to 100 Mbits full-duplex. Using ifconfig to set the nic to 10baseT/UTP and then back to 100baseTX full-duplex doesn't help. Only a reboot will bring the NIC back to 100 Mbits full duplex mode. -- Guido msg37926/pgp0.pgp Description: PGP signature
Re: clock drift in -CURRENT
Bill Fenner schrieb: I had the same symptoms (drifting about 2 minutes an hour) on sources before April 17 or so. Since then, ntpd has only logged 5 time updates, as opposed to 3 per hour. The drift wasn't visible immediately, but only after the magical 49.7 days or 2^31 clock ticks. Before that I had the usual corrections if you run ntp over a dialup line with large variations in round trip times (around one correction every few days). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 3Com 3c905C-TX
On Wed, 1 May 2002, Guido Kollerie wrote: snip Unfortunately the switch is unmanaged hence I am not able to explicitely set the switch to 100 Mbits full-duplex. Using ifconfig to set the nic to 10baseT/UTP and then back to 100baseTX full-duplex doesn't help. Only a reboot will bring the NIC back to 100 Mbits full duplex mode. Please note that due to vagaries in the auto-negotiation spec 3com and cisco dont work well together. And 3coms ( on linux atleast ) have the added bonus of sometimes deciding to change speed/duplex just for the heck of it. The only way to use them reliably is to force both the card and the switch. We came to the conclusion that fxp's are a nicer option. IMHO just creating a reliable and clearly defined auto-negotiation protocol will do more for ethernet speed than gigabit ethernet :). -- Sten Spans What does one do with ones money, when there is no more empty rackspace ? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
difficulties with ed driver (was d-link dwl520 wireless pci...)
i broke down and did a fresh install of the developer's
preview of 5.0 and the wi driver picks up the d-link
wireless card and works like a champ. the catch is that
for some reason the ed driver doesn't seem to want to recognize
my isa ne2000 (compliant) nic. i recompiled the kernel making
sure that device ed was specified (along with miibus) and still
no luck. i was thinking it may have been a problem with the network card,
but slackware 8 with kernel 2.4.17 (on a different partition) picked up
the network card just fine (as well as the d-link card, via wlan drivers).
i've gone into the dumb dos setup utility for the network
card at least twenty times, specifying just about every
combination of options (enabled/disabled plug-and-play
and tried a bunch of different port/irq/iomem). i've also
gone into the bios and tried enabling and disabling pnp-OS.
dmesg (used boot -v) doesn't list anything resembling an
isa nic at all, but kldstat -v has if_ed listed in (seemingly)
all the right places. i did specify the pertaining values
in /boot/devices for the ed driver as well.
all this to no avail. i know there's something i've overlooked..
any hints/suggestions? thanks!!!
--tents
On Fri, 26 Apr 2002, . ten tacles . . wrote:
recently acquired a dwl520 and i was wondering
if there is freebsd support for this card.
i looked through what appeared to be the pci-support
portion of the wi driver (if_wi_pci.c ..checked out
via cvs last night) and i couldn't find a definition of this card:
pci_ids[] = {
{0x1638, 0x1100, WI_BUS_PCI_PLX, PRISM2STA PCI WaveLAN/IEEE 802.11},
{0x1385, 0x4100, WI_BUS_PCI_PLX, Netgear MA301 PCI IEEE 802.11b},
{0x16ab, 0x1101, WI_BUS_PCI_PLX, GLPRISM2 PCI WaveLAN/IEEE 802.11},
{0x16ab, 0x1102, WI_BUS_PCI_PLX, Linksys WDT11 PCI IEEE 802.11b},
{0x1260, 0x3873, WI_BUS_PCI_NATIVE, Linksys WMP11 PCI Prism2.5},
{0x10b7, 0x7770, WI_BUS_PCI_PLX, 3Com Airconnect IEEE 802.11b},
{0x111a, 0x1023, WI_BUS_PCI_PLX, Siemens SpeedStream IEEE 802.11b},
{0, 0, 0, NULL}
this may or may not be indicative of support for this card as far as i
know (which is not much regarding driver hacking). i compiled the driver
into the kernel anyways and got this on bootup:
pci0: unknown card (vendor=0x1260, dev=0x3873) at 11.0 irq 12
so would anyone happen to know if this card is supported and if so,
is there a diff/patch/revision that i should get or procedure i should
follow?
thanks a bunches!
--tents
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users?
My take on this. We should remove perl from the base, and automatically install the port for most users in sysinstall, just like we do with XFree86. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users?
But doesn't the kernel rely on perl for building? perl5 ../../kern/vnode_if.pl -h ../../kern/vnode_if.src does it make sense to remove it from the base when the base depends on it? Ken On Wed, 1 May 2002, M. Warner Losh wrote: My take on this. We should remove perl from the base, and automatically install the port for most users in sysinstall, just like we do with XFree86. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users?
In message: [EMAIL PROTECTED] Kenneth Culver [EMAIL PROTECTED] writes: : But doesn't the kernel rely on perl for building? : : : perl5 ../../kern/vnode_if.pl -h ../../kern/vnode_if.src : : does it make sense to remove it from the base when the base depends on it? The base will no longer depend on it before too much longer. The vnode and kobj dependencies are already gone in current. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
fast playback with Intel 82801BA (ICH2)
-current compiled today mp3s play too fast, any ideas on how to diagnose this? pcm0: Intel 82801BA (ICH2) port 0xef00-0xef3f,0xe800-0xe8ff irq 9 at device 31.5 on pci0 pcm0: measured ac97 link rate at 44061 Hz -- -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.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fast playback with Intel 82801BA (ICH2)
/-- Alfred Perlstein wrote: | -current compiled today mp3s play too fast, any ideas on how to | diagnose this? | | pcm0: Intel 82801BA (ICH2) port 0xef00-0xef3f,0xe800-0xe8ff irq 9 at device | 31.5 on pci0 | pcm0: measured ac97 link rate at 44061 Hz You can set a sysctl to set the ac97 link rate. I don't recall offhand what it is (hw.snd.pcm0.ac97rate?) - sysctl -a | grep ac97 will find it. There is a calibration test in the ich code since various mfrs do funny things with the clock. I'd be interested to know what boot -v output is and what ac97 link rate works. This is the second box reported failing on this recently. - Orion To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users?
and just add enough file to build miniperl. I've read all the messages in this thread, but I'm still unclear -- are we talking about building the miniperl that Perl already creates during the build process? If not, the minimal perl for building the FreeBSD kernel should have a different name, like: smallperl modestperl tightperl midgetperl petiteperl Sure, whatever. Smallperl it is. :-) M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn #text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc #application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
New Perl list (was: Save a few hunderd kilobytes or a few hundredperl users?)
On Wed, 1 May 2002, Jarkko Hietaniemi wrote: I STRONGLY suggest that this discussion should get it's own mailing list, though, this is off topic for both perl5-porters and freebsd-current. I'm certain both those lists are busy enough, and OS distrib people need a common ground. [EMAIL PROTECTED]? Ask, could you create the list? [EMAIL PROTECTED] will accept your subscription request. Within a few hours of the first posting to the list it will also be available at news://nntp.perl.org/perl.dist Elaine, please get the list description and stuff from Jarkko and put the list on lists.perl.org. :) - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New Perl list (was: Save a few hunderd kilobytes or a few hundred perl users?)
On Wed, May 01, 2002 at 02:37:10PM -0700, Ask Bjoern Hansen wrote: On Wed, 1 May 2002, Jarkko Hietaniemi wrote: I STRONGLY suggest that this discussion should get it's own mailing list, though, this is off topic for both perl5-porters and freebsd-current. I'm certain both those lists are busy enough, and OS distrib people need a common ground. [EMAIL PROTECTED]? Ask, could you create the list? [EMAIL PROTECTED] will accept your subscription request. Within a few hours of the first posting to the list it will also be available at news://nntp.perl.org/perl.dist Elaine, please get the list description and stuff from Jarkko and put the list on lists.perl.org. :) The charter of the [EMAIL PROTECTED] mailing list is to discuss the splitting or repackaging of the Perl distribution. The new forum has been created, I hope the clamour about this subject in p5p and freebsd-current will now cease. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Replace makeLINT.pl with makeLINT.sh
How about using this script instead of makeLINT.pl?
# MIME multipart post is rejected by hub...
-
#! /bin/sh
# $FreeBSD$
/usr/bin/sed -e 's/#.*//' -e 's/\ //' | /usr/bin/awk '
/^[ \t]*$/ { next }
/^hint\./ { next }
/^(\
machine|\
ident|\
device|\
makeoptions|\
options|\
profile|\
cpu|\
option|\
maxusers\
)[ \t]/ { print; next }
{ printf(unrecognized line: line %d: %s\n, NR, $0) /dev/stderr }
'
-
--
Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc.
[EMAIL PROTECTED] // FreeBSD Project
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: building -current on -stable broken?
On Mon, Apr 29, 2002 at 10:33:05 +0300, Ruslan Ermilov wrote: On Sun, Apr 28, 2002 at 10:27:10PM -0600, Kenneth D. Merry wrote: I'm trying to build -current from today (4/28/2002) on a -stable box with a kernel/world from April 25th. It blows up in xlint: == cc -O -pipe -I. -I/c/ken/perforce/FreeBSD-ken/src/usr.bin/xlint/lint1 -I/c/ken/perforce/FreeBSD-ken/src/usr.bin/xlint/lint1/../arch/i386 -I/c/ken/perforce/FreeBSD-ken/src/usr.bin/xlint/lint1/../common-D__FBSDID=__RCSID -static -o lint1 cgram.o scan.o mem1.o mem.o err.o main1.o decl.o tree.o func.o init.o emit.o emit1.o inittyp.o -ll -lm cgram.o: In function `yyparse': cgram.o(.text+0x10b8): undefined reference to `xcalloc' cgram.o(.text+0x10f0): undefined reference to `xcalloc' scan.o: In function `ccon': scan.o(.text+0x23f7): undefined reference to `xcalloc' func.o: In function `label': func.o(.text+0x6a8): undefined reference to `xcalloc' init.o: In function `prepinit': init.o(.text+0x78): undefined reference to `xcalloc' init.o(.text+0x214): more undefined references to `xcalloc' follow emit.o: In function `outopen': emit.o(.text+0x4f): undefined reference to `xmalloc' emit.o: In function `outxbuf': emit.o(.text+0xd4): undefined reference to `xrealloc' emit1.o: In function `ttos': emit1.o(.text+0x2d5): undefined reference to `xmalloc' *** Error code 1 Stop in /c/ken/perforce/FreeBSD-ken/src/usr.bin/xlint/lint1. *** Error code 1 Stop in /c/ken/perforce/FreeBSD-ken/src. *** Error code 1 Stop in /c/ken/perforce/FreeBSD-ken/src. *** Error code 1 Stop in /c/ken/perforce/FreeBSD-ken/src. == Am I doing something wrong here or is building -current on -stable broken? Seems to work OK here; xcalloc() and xmalloc() are defined in mem.c. The problem I'm having is a stale version of xlint/lint1/mem.c in my cvsup-perforce gateway tree. cvs has a similar problem. If I update an existing tree, lint1/mem.c doesn't get deleted even though everything in that directory is on the HEAD, and mem.c is in the attic! # pwd /a/src/usr.bin/xlint/lint1 # cvs update -Pd cvs update: Updating . # ls -la mem.c -rw-r--r-- 1 root wheel 2398 Apr 15 11:43 mem.c # cvs status mem.c === File: mem.c Status: Up-to-date Working revision:1.1 Mon Apr 15 17:43:04 2002 Repository revision: 1.1 /usr/local/cvs/src/usr.bin/xlint/lint1/Attic/mem.c,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) If I checkout a new copy of xlint, though, I don't get a copy of lint1/mem.c. I suspect cvsup has a similar problem -- even if I remove the checkouts.cvs:. file, xlint/lint1/mem.c still gets checked out, and it's a version from 1995 at that! C src/usr.bin/xlint/lint1/mem.c,v . . 2#871#110#10157933134#39763#444 1.1.1.1 95.11.05.15.56.40 2#871#19#8155870004#23983#600 Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Replace makeLINT.pl with makeLINT.sh
On Thu, May 02, 2002 at 12:04:47PM +0900, Jun Kuriyama wrote: How about using this script instead of makeLINT.pl? Looks great. Please commit. :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 3Com 3c905C-TX
Out of curiosity, do only 3c509's exibit this behavior, or is this the core problem with 3c59x's as well? My experiences have not been consistent with these cards, and I had assumed it was due to buggy code in the 3-Com chipset. I've noticed flaky behavior from the Vortex [3c59x] card as well. Just now I have been wrestling with an ISA 3c509 which has a Lucent 40-01304 chip on it. At first the card was detected, and later not detected [on a different OS.]I vote for the fxp's as well, I've had hardly any problems with them. Is there a way to lock down the card by hacking the driver, so it won't try to auto-negotiate the connection? On Wed, 1 May 2002, Sten wrote: On Wed, 1 May 2002, Guido Kollerie wrote: snip Unfortunately the switch is unmanaged hence I am not able to explicitely set the switch to 100 Mbits full-duplex. Using ifconfig to set the nic to 10baseT/UTP and then back to 100baseTX full-duplex doesn't help. Only a reboot will bring the NIC back to 100 Mbits full duplex mode. Please note that due to vagaries in the auto-negotiation spec 3com and cisco dont work well together. And 3coms ( on linux atleast ) have the added bonus of sometimes deciding to change speed/duplex just for the heck of it. The only way to use them reliably is to force both the card and the switch. We came to the conclusion that fxp's are a nicer option. IMHO just creating a reliable and clearly defined auto-negotiation protocol will do more for ethernet speed than gigabit ethernet :). -- Sten Spans What does one do with ones money, when there is no more empty rackspace ? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: newsyslog(8) should wait(2) for children
Maxim Konovalov [EMAIL PROTECTED] writes: Does anyone object to the next patch: while (wait(NULL) 0 || errno == EINTR) /* nothing */ ; DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: newsyslog(8) should wait(2) for children
Maxim Konovalov wrote: [ ... patch to wait for children, but do nothing with the result ... ] Yes. Why not just set the signal handler for the child process termination to ignore, so that the child processes do not become zombied in the first place, so it's not ever necessary to do a useless loop whose only purpose is to reap zombies without examining their exit status? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users?
Fisher Mark wrote: Part 1.1Type: Plain Text (text/plain) [ ... de-MIME-ed dso that it's distinguishable from an email virus ... ] ] I've read all the messages in this thread, but I'm still unclear -- are we ] talking about building the miniperl that Perl already creates during the ] build process? If not, the minimal perl for building the FreeBSD kernel ] should have a different name, like: ] smallperl ] modestperl ] tightperl ] midgetperl ] petiteperl ] or something similar. I see much potential for confusion if miniperl ] means different Perl builds in different contexts. It's really assinine (IMO) to have a non-standard third party application. Either it's perl or it's not perl. The big argument here appears to be that there are a number of CPAN modules used for writing CGIs that FreeBSD doesn't include by default, while the perl community itself seems intent on bloating the base perl distribution with these things... and most everyone else considers them security risks or bloat or whatever. Frankly, I think if anyone were honestly concerned about bloat, we wouldn't have perl in the base system in the first place. So let's just take the anti-bloat argument off the table. That should clear the picture up considerably. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 3Com 3c905C-TX
On Wed, 1 May 2002, Glendon Gross wrote: Out of curiosity, do only 3c509's exibit this behavior, or is this the core problem with 3c59x's as well? My experiences have not been consistent with these cards, and I had assumed it was due to buggy code in the 3-Com chipset. I've noticed flaky behavior from the Vortex [3c59x] card as well. I would assume is the chipset, because just out of the blue redoing negotiation doesnt seem like something that a sane driver would do. The most probable thing is that the card interprets normal traffic erronously as negotiation signals. Just now I have been wrestling with an ISA 3c509 which has a Lucent 40-01304 chip on it. At first the card was detected, and later not detected [on a different OS.]I vote for the fxp's as well, I've had hardly any problems with them. Is there a way to lock down the card by hacking the driver, so it won't try to auto-negotiate the connection? Like I said forcing it ( with the dos config tool ) helps, and solves the problems in most cases. But it's pretty workable when you force both sides. -- Sten Spans What does one do with ones money, when there is no more empty rackspace ? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
