Date: Tue, 6 Jun 2000 18:59:01 +0100 From: Nik Clayton <nik@freebsd.org> To: stable@freebsd.org, announce@freebsd.org Subject: [Conspectus] -stable, week ending 29th May 2000 Message-ID: <20000606185901.A55056@catkin.nothing-going-on.org>
next in thread | raw e-mail | index | archive | help
[ Posting on behalf of Salvo Bartolotta, who did all the hard work. See http://www.FreeBSD.org/conspectus/index.html for more information. To contribute, contact doc@FreeBSD.org -- N ] FreeBSD-stable Conspectus, week ending 29th May 2000 Dates # Posts Subject May 23 - May 27 20 Re: ad0 drivers revisited May 25 - 29 May 19 Problems compiling FreeBSD stable May 24 - May 26 10 4-stable won't boot May 23 - May 23 1 solved Re: spontaneous reboots May 26 - May 27 5 making 4.0 DOS resistant May 23 - May 23 2 Problems with NFS on FreeBSD 4.0 May 27 - May 29 3 Strange message May 24 - May 27 5 Transparent proxies and fetch May 23 - May 23 6 tun0: Warning: CHAP 0x81 not supported May 23 - May 23 4 Re: -CURRENT Mylex on stable? May 24 - May 25 7 ntpdate could not sync time from any server May 25 - May 26 4 3DNow! binutils & Mesa for -STABLE --------------------------------------------------------------------------- May 23 - May 27 (20 posts): Re: ad0 drivers revisited Last week's thought-provoking debate continued this week; the discussion focused on a a few possible workarounds for circumventing the well-known ad driver bug early in the booting process. It seems that an effective solution has not still been implemented. However, a number of interesting suggestions were offered. The point is that, in order to prevent any HD damage, PIO mode should be set by default very early at boot time. Albeit the bug only manifests itself in the worst form in a very limited number of cases -- ie rather special combinations of hardware components -- when it does, it does ... --------------------------------------------------------------------------- May 25 - May 29 (19 posts): Problems compiling FreeBSD stable On May 25, 2000, [Graham Wheeler] met a number of errors in the make world process while compiling gcc. After some experimentation, he got rid of them by using the "i" option for make. He seems to be the only person in the forum to have found these errors; probably, they were caused by an incorrect updating procedure. Although the problems were soon easily solved, several fine points were hinted at in this thread: in particular, such a secondary specific procedure as "make includes", which is (usually) relevant to -CURRENT. --------------------------------------------------------------------------- May 24 - May 26 (10 posts): 4-stable won't boot The boot problem in question turned out to be trivial: the ata device was commented out (!) in the kernel configuration file. The correspondents, subsequently, went on to describe their experience with such dangerous options as AUTO_EOI_1 and AUTO_EOI_2. --------------------------------------------------------------------------- May 23 - May 23 (1 posts): solved Re: spontaneous reboots On May 23, 2000, [Fritz Heinrichmeyer] announced that he had solved his spontaneous reboot problem by upgrading to -STABLE -- the SMP cleanups seemed to require a recompilation. Incidentally, I have read about spontaneous reboots a good number of times in the FreeBSD mailing lists. The most common cause is bad hardware; sometimes, as in the present situation, the cause is of software nature. Upgrading to -STABLE, as is very often the case, is the solution to that vexed question. On May, 29, however, Fritz wrote again. Other spontaneous reboots, in fact, occurred a few days later. Also, [MI] reported on the same matter -- MI, too, has been running SMP boards. This anomalous behavio(ur) seems to be specifically related to the SMP code, and is currently under investigation. --------------------------------------------------------------------------- May 26 - May 27 (5 posts): making 4.0 DOS resistant [Sameer R.Manek] was seeking information about FreeBSD strategies for handling DOS attacks. [Bill Fumerola] pointed out that such options as ICMP_BANDLIM, TCP_DROP_SYNFIN, and TCP_RESTRICT_RST, albeit useful in fighting DOS attacks (e.g. attacks on IRC servers), cannot cope with spoofed ip syn floods. In particular, Bill is going to publish some (on-line) material about DOS attacks at large: stay tuned... though I'll probably post my findings/suggestions on -security when I finally write them up. --------------------------------------------------------------------------- May 23 - May 23 (2 posts): Problems with NFS on FreeBSD 4.0 [Paul A. Howes] , answering a letter of [Zherdev Anatoly]'s, suggested a procedure for installing ports over a network: What I usually do is perform the first-time build and install on the server. Then, when I need one of the applications in /usr/ports on a different system, I NFS-mount /usr/ports and perform a "make reinstall" to get the application installed, but not built from scratch, on the client. I do it this way, because I had been alerted to permission problems in the building of various components. It's just simpler to do all of the builds on a server, and only do the installs on the client. Besides, my server is a faster machine than the clients I have, so builds go MUCH faster on it. --------------------------------------------------------------------------- May 27 - May 29 (3 posts): Strange message [Derek Tattersall] wrote: I am getting a message shortly after boot-up finishes which puzzles me. The message follows: lorne /kernel: arplookup 0.0.0.0 failed: host is not on local network. [Lucas Ertl] replied: I had almost the same message here, but it was host 13.10.15.10 instead of 0.0.0.0. The problem was a program called "LanGuard", installed on the Win2k box of one of my co-workers, that continously sent out arp requests but spoofed the MAC address of the machines NIC. You could try: tcpdump -n -e -p arp and then hunt down the MAC address. --------------------------------------------------------------------------- May 24 - May 27 (5 posts): Transparent proxies and fetch [Joe Shevland] found this error: Attempting to fetch from http://people.FreeBSD.org/~andreas/download/. fetch: empty reply from people.FreeBSD.org Both the stable forum and the c.u.b.f.m. newsgroup provided him with the long sought-after answer: Try "make FETCH_BEFORE_ARGS=-tb" or add "FETCH_BEFORE_ARGS=-tb" to /etc/make.conf. --------------------------------------------------------------------------- May 23 - May 23 (6 posts): tun0: Warning: CHAP 0x81 not supported After setting up a pptp vpn (using pptp client from ports), [Michael Lucas] read these messages while trying to connect: May 23 10:02:24 proxybox (unknown)[2067]: log[pptp_dispatch_ctrl_packet:pptp_ctrl.c:531]: Client connection established. May 23 10:02:25 proxybox (unknown)[2067]: log[pptp_dispatch_ctrl_packet:pptp_ctrl.c:637]: Outgoing call established. May 23 10:02:28 proxybox ppp[2065]: tun0: Warning: CHAP 0x81 not supported [Brian Somers] responded: This (CHAP 0x81) is M$CHAPv2. An implementation will be committed to -current RSN. The work has been done by [Nathan Binkert] --------------------------------------------------------------------------- May 22 - May 23 (4 posts): Re: -CURRENT Mylex on stable? [Shawn Barnhart] asked for the diffs making Mylex work under -STABLE. [Mike Smith] rejoined: 1) Get the diffs. You will need a CVS repository, or use the cvsweb interface at http:// www.freebsd.org/cgi/cvsweb.cgi to extract the diffs. Note that mlx.c, mlx_disk.c, mlx_pci.c and mlxvar.h all changed in this fix. 2) Apply the diffs. Shawn Barnhart: I'm missing where the end result of diff/patch differs from the files themselves. It's a nice exercise, but kind of a PITA when you're not a CVS user. Mike Smith: The goal is to extract the changes I made to portions of the driver that are largely common between the two versions. --------------------------------------------------------------------------- May 24 - May 25 (7 posts): ntpdate could not sync time from any server [Lev Serebryakov] could not syncronize time on his homebox via ntpdate over a V.90 connection. On the same wavelenght, complaining about ntpdate not syncing over a DSL line, [Glen Gross] added: I have had the same experience, with a DSL line. I don't know if ntpdate requires the time to be within a certain threshold before it will sync or not. Does anyone know the answer to this? [Ian Smith] replied: Yes, it does; -t sets the time ntpdate will wait for a valid response. Still get one of these logged once every few days when upstream PPP link is extra heavily used, but used to get it much more often before using: ntpdate -t 2.4 -s ntp.ml.csiro.au ntp.cs.mu.oz.au judge.lis.net.au That's 2.4 seconds. man ntpdate isn't exactly clear re the unit format, but it does say that the default of 1 second is suitable for a LAN. --------------------------------------------------------------------------- May 25 - May 26 (4 posts): 3DNow! binutils & Mesa for -STABLE [Randall Hopper] posted the following message: Thanks to David O'Brien for upgrading -current's binutils. This new version supports AMD 3DNow! for the K6-2, K6-III, and Athelon folks. Wanting 3DNow support in gas, I pulled a copy from CVS and built it for 3.4-RELEASE (w/ gdb commented out). Now Mesa and friends detect and build in 3DNow support for Mesa on -stable. For other -stable folks that want to give it a shot, just fetch copies of src/contrib/binutils and src/gnu/usr.bin/binutils modules from the latest CVS ("cvs checkout <module>"). Also, I'll be happy to send binutils exec binaries to anyone running 3.4. [Wilko Bulte] asked: Do thinks like fxtv use 3dnow to their advantage (I guess not)? But I assume the various mpeg* things might? [Randall Hopper] remarked: No fxtv doesn't, and I think you're right. As I recall MMX adds SIMD integer ops which is where the boost would be for things like pixel repacking. 3DNow's primary add was parallel floating/fixed point I believe. Rather than reinvent the wheel, I'll likely stack fxtv on the hermes port one of these days if there isn't a big turn-out for an alternative video API. --------------------------------------------------------------------------- * The present Conspectus expresses my strictly personal understanding of what occurred on the FreeBSD-stable mailing list during the specified week. * I may have made errors and/or mistakes as well as typos. If you feel that this is indeed the case, and/or that I have omitted some significant thread or part of a thread, feel free to contact me via email. Constructive criticism is more than welcome. Salvo Bartolotta To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000606185901.A55056>