Table Of Contents
|1.||5 Apr 1999 - 6 Apr 1999||(10 posts)||linux-kernel Troubles|
|2.||30 Mar 1999 - 7 Apr 1999||(34 posts)||The Speed Of The Bazaar|
|3.||2 Apr 1999 - 9 Apr 1999||(9 posts)||Distributed File System|
|4.||4 Apr 1999 - 7 Apr 1999||(5 posts)||The 'gcc' Vs. 'egcs' Saga Continues|
|5.||6 Apr 1999 - 9 Apr 1999||(7 posts)||ISDN Difficulties Going Into The Main Tree|
|6.||4 Apr 1999 - 8 Apr 1999||(4 posts)||Fix For NFS Accidentally Deleting Files|
|7.||5 Apr 1999||(6 posts)||Boot Failure When Monitor Unattached|
|8.||5 Apr 1999 - 6 Apr 1999||(4 posts)||Syslogd Broken By Kernel Header Changes|
|9.||6 Apr 1999 - 9 Apr 1999||(8 posts)||aic7xxx 5.1.14 Driver Announced|
|10.||7 Apr 1999 - 8 Apr 1999||(10 posts)||Aggressive Spam Filtering|
|11.||7 Apr 1999||(3 posts)||Linker Errors In 2.2.5ac5|
|12.||9 Apr 1999 - 10 Apr 1999||(3 posts)||Difficulties Of Trapping Kernel Stack Overflows|
KT got a lot more traffic last week because the editorial (kt19990408_13.html#0) on the "Linux" vs. "GNU/Linux" debate was mentioned on Slashdot. If you're interested, check out the slashdot discussion (http://slashdot.org/articles/99/04/09/1516203.shtml) . I'd like to thank all the people who emailed me personally about it as well.
There was some feedback on the layout change. A number of folks pointed out that there should be a permanent link for the latest page. So that's up in the links section, and the URL is http://kt.zork.net/latest.html
I mentioned Loren Osborn last week in Issue #13, Section #3 (25 Mar 1999: Console Scrolling With Mouse Wheels) , and referred to him mistakenly as 'she' (it's been corrected now). Sorry about that, Loren.
Mailing List Stats For This Week
We looked at 1020 posts in 3608K.
There were 432 different contributors. 179 posted more than once. 141 posted last week too.
The top posters of the week were:
1. linux-kernel Troubles
5 Apr 1999 - 6 Apr 1999 (10 posts) Archive Link: "is it just me getting $($F$b$i$($^$;$s$G$7$g$&$+!#"
Topics: Mailing List Administration
People: Matti Aarnio, Aaron T Porter
Apparently linux-kernel was accidentally receiving bounces from a Japanese Linux list, resulting in a lot of Japanese-encoded text showing up as garbage ascii on linux-kernel. Matti Aarnio said, "... well, I hope I got them all before more arrived to the lists. Because it looked like a loop at somebody's mailbox retrieval software, I have blocked that particular source address from sending to VGER for a while -- say for next few days. I will try to remember to remove the block latter this week. "
Elsewhere Aaron T Porter, one of the maintainers of linux-kernel, said he had sent nasty letters around. Matti replied:
I really wish you folks had better sense than sending any nasty letters, or for that matter, REACTING AT ALL, when somebody does loop messages from their mailbox-client to unintended destinations. Especially you, Aaron.. (Well, *you* can react by doing filtering at linux-kernel, but that is an off-line discussion topic between you and me.)
Due to the "little" burst of "junk", and "reactions", VGER had a queue of several *thousand* messages to handle, and it took a while to process them -- even with me manually scrubbing several of the messages, and heaps of reactions... Now the queue is back to zero.
I bet you sent the nastygrams to email@example.com, which list has NOTHING to do with this case (aside of being place where the messages were sent 4 months ago.) The little I know of Japanese culture, I do suggest you send an apology letter to those innocent addresses you likely have offended.
I do know the real culprit source address, but these reactions you people have shown, does suggest to me that I should not reveal it aside of very few selected people..
2. The Speed Of The Bazaar
30 Mar 1999 - 7 Apr 1999 (34 posts) Archive Link: "Address spaces on a i386 - Getting Confused"
Topics: New Developers
People: Paul Sargent
This was an amazing thread. Paul Sargent was trying to understand the address spaces used in various circumstances in the kernel. He went over his basic understanding and described what parts didn't make sense to him. A big pile of top developers dove on top of him with a lot of absolutely incredible explanations. I didn't know what they were talking about, but they were having fun!
At a certain point, under the Subject: Address spaces on i386 - Some clarity is forming (http://www.kernelnotes.org/lnxlists/linux-kernel/lk_9903_05/msg00237.html) , Paul said, "First of all thanks to those who have come to my aid. It's now about 3 hours on from my initial cry for help and I think I understand."
3. Distributed File System
2 Apr 1999 - 9 Apr 1999 (9 posts) Archive Link: "OT:fault tolerant nfs HOW?"
People: Stephen C. Tweedie
Peter-Paul Witta asked about the possibility of a file server that would never go down, i.e. if one node died the others would immediately compensate. Some speculation followed from various folks, and Stephen C. Tweedie gave a pointer to the Global File System (http://gfs.lcse.umn.edu/) homepage.
4. The 'gcc' Vs. 'egcs' Saga Continues
4 Apr 1999 - 7 Apr 1999 (5 posts) Archive Link: "Still no ISDN connection :("
Topics: Compiler, Networking
People: Linus Torvalds
Nuno Carvalho's PC-Bit card wouldn't work under kernels >=2.2.4; he tried a number of things, including the bleeding edge of the isdn4linux package. But Nuno Ferreira replied that this was an egcs problem (and he'd already posted to their list as well as linux-kernel about it), and would go away under gcc. An overjoyed Nuno Carvalho replied that installing gcc 188.8.131.52 solved the problem.
Kernel Traffic first discussed the egcs vs. gcc situation in Issue #1, Section #5 (8 Jan 1999: GCC or EGCS?) . We've definitely come a long way since then. By Issue #10, Section #4 (6 Mar 1999: 'gcc' Vs. 'egcs') there was already confirmation that the latest kernel's would successfully compile under egcs. Then last week (Issue #13, Section #10 (29 Mar 1999: 2.2.5 Announcement; Linus Goes On Vacation) ) in the 2.2.5 announcement, Linus Torvalds indicated that egcs may (or may not) be the cause of a few hard-to-track bugs.
It will probably be a long time (if ever) before the last lingering egcs doubt is extinguished, but it's fascinating to watch it gradually happen.
5. ISDN Difficulties Going Into The Main Tree
6 Apr 1999 - 9 Apr 1999 (7 posts) Archive Link: "Bug? ISDN stops working with 2.2.5ac2"
Topics: Compression, Networking, Version Control
People: David Woodhouse, Alan Cox, Paul Slootman, Henner Eisen
Another ISDN problem came up this week. Mikko Hyvarinen found that between 2.2.5 and 2.2.5ac1 something broke ISDN syncPPP connections. He didn't get an answer on the list (though it might have gone to private mail), but in the course of the discussion it came out that the isdn4linux code in 2.2 kernels was old. David Woodhouse explained:
The ISDN code from the CVS tree contains support for more cards, support for compression, including LZS compression, and Telco approval for the HiSax driver on certain cards. And last time I compared them, the 2.2.x code would last about 30 seconds before crashing the machine, while the CVS code didn't crash.
Linus didn't want to accept the CVS code immediately before releasing 2.2.0, and the only thing that went in to 2.2.x was a patch containing the most important bug fixes.
Even the ISDN code in 2.0.37 is newer than the code in 2.2.x, and contains (IIRC) a some of the newer drivers, and the HiSax certification.
Alan Cox said, "It needs people to take a stable cut from the isdn cvs tree and integrate it back into the tree. I've seen no evidence of the ISDN people doing that."
Paul Slootman replied:
Henner Eisen had taken it upon himself to feed the cvs version in (incremental but working) parts, as apparently Linus' biggest complaint was that he would never accept the large patch necessary for getting the 2.2.x isdn stuff up to the (stable) cvs version in one go (hence the parts).
He sent you (Alan) a patch for the link level in the first week of February, for inclusion in your 2.2.2ac series (at that time). It was basically the cvs link level with the TIMRU and BUDGET extensions taken out, as those aren't "clean" enough. I assume he's waiting to see that appear before he's able to send the next patch.
So, Alan, have you lost / rejected / ignored that patch? I'm curious as to the status...
The thread ended here, but presumably the latest ISDN code may start to be included in Alan's ac series, to the great jubilation of many.
6. Fix For NFS Accidentally Deleting Files
4 Apr 1999 - 8 Apr 1999 (4 posts) Archive Link: "NFS Problem"
Topics: FS: NFS
People: Trond Myklebust, Steven N. Hirsch
Steven N. Hirsch found that exiting his newsreader when his home directory was NFS mounted would delete his .newsrc file! Trond Myklebust posted a small patch to linux/fs/nfs/dir.c and asked Steven to try it in conjunction with anything newer than 2.2.4ac1. A happy Steven replied that it worked like a charm.
End Of Thread (tm).
7. Boot Failure When Monitor Unattached
5 Apr 1999 (6 posts) Archive Link: "Linux 2.2.5 won't boot?"
People: Riley Williams, Meelis Roos
Jussi Hämäläinen had an interesting problem: his machine wouldn't boot without a monitor attached. Lilo would load the kernel and then hang until he plugged in the monitor. This didn't make any sense to him, so he posted to the list.
Meelis Roos and Neil Cherry confirmed they had experienced similar things. Riley Williams suggested changing video cards, explaining, "some PnP motherboards ask a PnP video subsystem to check what type of monitor is connected as part of their PCI initialisation, and some video cards hang when asked to do so if no monitor is connected."
8. Syslogd Broken By Kernel Header Changes
5 Apr 1999 - 6 Apr 1999 (4 posts) Archive Link: "Segfault in syslogd <problem shown>"
Topics: Debugging, Developer Interaction
People: Chris Wedgwood, Richard B. Johnson
Richard B. Johnson posted a little code from syslogd which would segfault under certain conditions. An irate Chris Wedgwood said, "What the hell is this doing here? _You_ should know by now this doesn't belong here," to which Richard replied, "Well it _does_ belong here because changes in the _kernel_ headers make the source generate bad code (without directly including kernel headers, BTW)." He went on, " so I suggest that you quiet down a bit and appreciate the debugging that I did so that utilities that work with the kernel can be updated to continue to work." Chris said, "oops... I wasn't paying attention and my brain was in auto-disengage mode."
9. aic7xxx 5.1.14 Driver Announced
6 Apr 1999 - 9 Apr 1999 (8 posts) Archive Link: "aic7xxx driver update"
People: Doug Ledford
Doug Ledford announced:
I've released the 5.1.14 version of the aic7xxx driver. This driver should fix the outstanding problems that I know of on all of the PCI class adaptec controllers. There may be some outstanding issues on EISA controllers. I will be verifying the EISA controllers later this week. There are several sections of code that underwent heavy modifications though. The most heavily modified is the device speed negotiation code. It's hoped that this code will be better than the previous code was, but it is in need of testing. Specifically, there are drives out there that will initiate negotiation with the controller isntead of waiting for the controller to start the negotiation process. That has traditionally been a spot of problems in the aic7xxx driver. If some of the people that have drives that initiate negotiation on their own could try out this code and report back to me, I would greatly appreciate it.
The update can be found at ftp://ftp.redhat.com/aic/5.1.14 and there are patches against a clean 2.0.36 or a clean 2.2.5 kernel.
10. Aggressive Spam Filtering
7 Apr 1999 - 8 Apr 1999 (10 posts) Archive Link: "Mail delivery failed: returning message to sender (fwd)"
Topics: Mailing List Administration, Microsoft, Spam
People: Matti Aarnio, Bob Lorenzini, Riley Williams, Bruce Korb
Riley Williams' email was being blocked as an anti-spam measure by someone on linux-kernel, and he posted his feelings to the list as the only way to express them to that person. Matti Aarnio replied:
Yeah, that is a (misguided) case of "ban that domain because its used in so many spams.."
I have contemplated doing exactly that for AOL at VGER, but VGER does have a few lists where AOL users are in great abundance... Can't do it :-/
Oh yes, often when list-owners get that type of rejections, our reaction is simple: Remove the recipient which yields the rejection report. (in fact, remove any recipient which yields any rejection, including any recipient which yields delivery timeout...)
Sure that reaction may sound stupid to you at first, but consider that each of us must somehow process something like 200 to 2000 rejection reports every day thru all the year, and we do all that at our spare time.
Unfortunately we postmasters/list-owners don't have the luxury of time to educate people of the nyances of email systems; when to blame some system, and when *not* to blame. That last one can be a difficult question to answer without 5+ years of email systems and protocols experience...
So, if you folks want to filter incoming email against some source addresses carrying SPAM, be damn carefull that you don't filter too much. Letting *some* spam thru is way better than killing all your incoming email.
Filtering the email by delivering it to /dev/null is also better approach, than rejecting it at the input phase. Sure the byte- counters spin, but that isn't so bad as becoming removed because of over-eager pre-reception blocking based on false rules.
Meanwhile, Bob Lorenzini (from a netcom.com address) replied to Riley's original post with, "I respectfully dissagree on this Riley. I realise you have been inconvienced by this policy but think about the rest of us. You could help by refusing to patronise a provider who caters to net abusers."
Riley replied in turn, "I was also 'inconvenienced', along with a lot of other people, when microsoft.com blacklisted the .ac.uk 'domain' and thus denied access to their site from every university in the UK. The problem with that is that the .ac.uk 'domain' is NOT a single domain, but a super-domain like .net or .org with many separate subdomains that are administered separately..."
Bruce Korb also replied to Bob, with, "Um, so why are you_ using netcom? Try posting to a distribution list on egcs.cygnus.com. You cannot do it." Bob replied, "Well if netcom is still relaying spam they should be cut off. I thought they had stopped under threat of being shut off usenet. Their acceptable use policy does not allow posting of spam and will terminate accounts upon complaint."
11. Linker Errors In 2.2.5ac5
7 Apr 1999 (3 posts) Archive Link: "Linux 2.2.5ac5"
People: Alan Cox
Alan Cox announced his latest ac patch, and Gregoire Favre said it gave linker errors with undefined references to rd_doload and rd_load_secondary. Alan replied, "Yep. My fault. If you have floppy=y and ram disk=n it burps. I'll stick an ac6 up shortly." End Of Thread.
12. Difficulties Of Trapping Kernel Stack Overflows
9 Apr 1999 - 10 Apr 1999 (3 posts) Archive Link: "[RFC] Trapping/tracing kernel stack overflows"
People: Martijn van Oosterhout, Alexander Viro
Martijn van Oosterhout had the interesting idea of using the i386 debug registers to trap kernel stack overflows. He said, "Obviously you'd have to block the ptrace GET/SETREGS," and, "Any process that is that deep probably has a lot of locks. Just dying would probably kill everything anyway. AFAIK the linux kernel has no machanism for undoing locks held by a faulting process. If it did you'd be able to use the floppy drive after the fat module had segfaulted on a bad floppy."
Alexander Viro replied, "Yes, it's the common problem with all kernel-mode faults. The problem being: you don't know *who* had set the lock/spinlock/semaphore, increased the usage counter, etc. and which resources were held by dying process. Any attempt to store this information (i.e. do equivalent of destructors) will have a nasty side-effect - we'll slow down a lot of stuff on nearly every time-critical path ;-/ So the current behaviour is least of two evils - after all, it doesn't punish correct code."
This was enough for Martijn. He said, "You are right. It could be done by attaching the locks as a linked list to the current process, which would allow you to track them all down, but it would penelize all the times where nothing goes wrong. After all, it won't be needed when the kernel is bug free :)"
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.