|
Kernel Traffic Latest | Archives | People | Topics |
Wine Latest | Archives | People | Topics |
GNUe Latest | Archives | People | Topics |
| Czech |
| Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic |
Table Of Contents
| 1. | 25 May 2000 - 22 Jun 2000 | (26 posts) | Latest List Of Things To Do Before 2.4 Can Come Out |
| 2. | 13 Jun 2000 - 22 Jun 2000 | (66 posts) | Getting Rid Of zImage |
| 3. | 17 Jun 2000 - 20 Jun 2000 | (10 posts) | Old BIOSes Booting With IDE Disks Larger Than 33.8G |
| 4. | 17 Jun 2000 - 23 Jun 2000 | (9 posts) | 'kswapd' Still No Solution |
| 5. | 17 Jun 2000 - 26 Jun 2000 | (13 posts) | Some Discussion Of Locking |
| 6. | 17 Jun 2000 - 23 Jun 2000 | (16 posts) | Alan Recommends Against BitKeeper |
| 7. | 18 Jun 2000 - 20 Jun 2000 | (8 posts) | New Attempt At Fixing 'kswapd' But No Luck So Far |
| 8. | 18 Jun 2000 - 20 Jun 2000 | (7 posts) | Makefiles Inefficient Since 2.2.16 |
| 9. | 19 Jun 2000 - 23 Jun 2000 | (17 posts) | Maintaining Buildable Ports |
| 10. | 19 Jun 2000 - 20 Jun 2000 | (20 posts) | Hunting For The 'kswapd' Problem |
| 11. | 19 Jun 2000 - 22 Jun 2000 | (11 posts) | Virtual Memory Opponents Work Together |
| 12. | 20 Jun 2000 - 21 Jun 2000 | (6 posts) | More On VM: 'classzone' Better In Benchmarks |
| 13. | 22 Jun 2000 | (3 posts) | Philosophy Of Listing Security Fixes In Changelog |
| 14. | 23 Jun 2000 - 25 Jun 2000 | (11 posts) | Anonymous Poster Claims GPL Violations Are Accepted By Linux Community |
Introduction
Robert McMillan wrote to me, "Kernel Traffic was selected as one of the Top 100 Linux Web sites in the June issue of Linux Magazine." [...] " Linux Magazine will be publishing its list of Top 100 Linux Web sites on www.linux-mag.com at the end of the summer." Yay!
Mailing List Stats For This Week
We looked at 1318 posts in 5257K.
There were 457 different contributors. 209 posted more than once. 182 posted last week too.
The top posters of the week were:
1. Latest List Of Things To Do Before 2.4 Can Come Out
25 May 2000 - 22 Jun 2000 (26 posts) Subject: "LINUX Jobs for 2.4 update"
Topics: Compression, Disk Arrays: RAID, Disks: IDE, Disks: SCSI, FS: FAT, FS: NFS, FS: NTFS, FS: UMSDOS, FS: devfs, I2O, Networking, PCI, Power Management: ACPI, Real-Time, SMP, Samba, Security, USB, Virtual Memory, VisWS
People: Alan Cox, Tony Hoyle, Stephen Rothwell, Jens Axboe, Rogier Wolff, Mike Galbraith, Steve Dodd
Alan Cox posted his latest To Do list for things to do before 2.4 could come out:
Tony Hoyle suggested adding 2 items to section 7 (To Do But Non Showstopper):
To Tony's first item, Stephen Rothwell posted a patch and explained to Alan, "This is realtive to the patch I just sent you and should fix the problems with powering down SMP boxes using APM."
Elsewhere, Steve Dodd asked if item 5.14 (Loopback fs hangs) referred to the "disable plugin" fix that had been discussed earlier. Alan replied that yes it was, and added, "Its not merged because nobody has yet explained precisely why it works and if its the right solution." Steve offered a technical explanation, and there was some technical discussion involving him, Jens Axboe, Mike Galbraith, Andrea Arcangel, and Gisle Selensminde. Alan had no more to say.
2. Getting Rid Of zImage
13 Jun 2000 - 22 Jun 2000 (66 posts) Subject: "It's time to get rid of zImage"
People: H. Peter Anvin, Edward S. Marshall, Tigran Aivazian, Alan Cox, Brandon S. Allbery, Jens Axboe, Johan Kullstam, Chris Noe
H. Peter Anvin said it was time to get rid of zImage. He'd pointed it out many times before, but now he really wanted to emphasize that this was the thing to do. He explained:
when Linux was originally created, DOS memory was considered a critical resource and very few computer manufacturers would have ever considered burning this resource for anything that wasn't absolutely critical. This isn't the case anymore, and we're seeing an increasing number of BIOS extensions -- some of them hacks, some of them very necessary -- considering this available space.
With zImage, it is very hard to put the ceiling of the boot loader any lower than approximately 0x9c000. This isn't good enough when a bunch of these extensions are present.
With bzImage, combined with making the setup code segment-relocatable (which shouldn't be too hard), we should be able to boot with much less DOS memory available in the system. However, this requires bootloader restructuring which would make it very hard to retain support for zImage kernels.
Given this, he asked, did anyone see a need to support zImage anymore?
There were a lot of replies, and several sizeable subthreads. Brandon S. Allbery pointed out the perennial problem: traditionally, some systems could boot zImage but not bzImage. He asked if this had been solved. H. Peter replied that as far as he knew, all systems could currently boot bzImage. Any exceptions, he said, should be found and fixed. Elsewhere, Edward S. Marshall reported:
I am typing this on just such a machine. This is preventing my upgrading to 2.4.x, since I can't get a kernel built which fits as a zImage supporting the hardware in the machine plus the features I need (yes, everything that can be is a module), so I'm VERY interested in getting this solved now (previously, it was really just an annoyance). When booting from LILO, I get the following message when specifying a bzImage kernel:
Block move error 0x02
Booting the exact same kernel configuration (the current round of testing is being done with 2.2.16, but it's the same error I've gotten since bzImage was first introduced) as it's zImage counterpart works just fine.
I'm willing to run pretty much whatever tests people are interested in seeing, and can provide system specs for the machine (some of which I've attached below my signature). Current constraints are that the machine is purely Linux, so any tests involving other architectures will be...difficult. ;-)
Let me know what you need.
H. Peter felt this was probably a BIOS problem, and suggested Edward either use the 'syslinux' boot loader, which would bypass the BIOS block-move feature; or trying a very stripped down bzImage, since he was just interested in whether it would boot, not whether it was ideal (he also misspoke, in this post and others, interchanging "bzImage" with "zImage", making it difficult at times to figure out what was being said. Thanks go to Juan Quintela and Jens Axboe for clearing up the confusing areas). Edward did some tests replied that H. Peter seemed to be right: it looked like 'lilo' was having problems with the BIOS. Using the GRUB bootloader he'd managed to boot bzImage kernels.
Elsewhere, Alan Cox said that getting rid of zImage was really something for 2.5; H. Peter suggested, "I would like to suggest making zImage officially deprecated (preferrably including some echo statement in the Makefile), but not removed, in 2.4, and then nuked completely in 2.5." Chris Noe and Johan Kullstam were fine with this, but Tigran Aivazian objected mildly, "well, I don't strictly *need* zImage, but, when you are explaining to someone how Linux kernel boots on x86 it is so much easier to follow all the details in the case of zImage than bzImage. But, I agree, it is purely academical thing - I treat all Linux kernels as something one should print out and hang on the wall :)"
3. Old BIOSes Booting With IDE Disks Larger Than 33.8G
17 Jun 2000 - 20 Jun 2000 (10 posts) Subject: "big disks and old BIOS"
Topics: Disks: IDE
People: Andries Brouwer, Werner Almesberger, Shane Wegner
Andries Brouwer reported that under some old BIOSes, an IDE disk larger than 33.8G would cause the BIOS to hang at boot time. Placing a jumper to make the disk appear the proper size would allow the machine to boot, but access to sector 66055248 and above would give I/O errors. However, he continued:
Thanks to the report by Shane Wegner we now have confirmation that in such a case a small Linux utility that executes the READ NATIVE MAX ADDRESS and SET MAX ADDRESS commands suffices to get full capacity back. See also
Jumpers that clip total capacity
So, no need anymore to upgrade the BIOS or install MaxBlast. An all-Linux solution suffices.
Werner Almesberger reported that his GA-686LX board with an ancient AWARD BIOS and a Maxtor 93652U8 (~36 GB) was immune to this solution, and that in fact the Maxtor utility wouldn't even recognize the jumper. Andries couldn't believe this, and after a bit of a staircase the thread petered out.
4. 'kswapd' Still No Solution
17 Jun 2000 - 23 Jun 2000 (9 posts) Subject: "kswapd infinite loop"
Topics: SMP
People: Goswin Brederlow, Rik van Riel, Juan J. Quintela
Rui Sousa reported what he took to be an infinite loop in 'kswapd', manifesting as extremely high CPU usage under test1-ac19 on his two-way SMP system. After some discussion, Juan J. Quintela said he thought his latest patch solved several infinite loops in 'kswapd'. He gave a link (after some typo correction) to a patch against ac22-riel. Goswin Brederlow tried this and found it to be "less worse, about like the other acXX or plain kernels." Above that in the same email, he'd said, "I tried ac22-riel today. its worse than ever," and Rik van Riel replied quietly, "God I love detailed bug reports..."
5. Some Discussion Of Locking
17 Jun 2000 - 26 Jun 2000 (13 posts) Subject: "spin_lock_irq vs. spin_lock_irqsave."
Topics: Samba
People: Russell King, Manfred Spraul, Matthew Wilcox, Daniel Kobras, Paul Rusty Russell
Daniel Kobras asked when it was OK to not save/restore processor flags. Specifically, he wanted to know how to determine when spin_lock_irqsave() would be needed in his own code, or if spin_lock_irq() would be sufficient. Russell King explained:
Basically, if you can guarantee that at the point when spin_lock_irq() is called, interrupts will always be enabled, then you can use spin_lock_irq() instead of spin_lock_irqsave().
The reason for this is that you know that interrupts were enabled, so when you come out of your critical region, you can just re-enable them with spin_unlock_irq().
And Manfred Spraul added:
And if you know that the interrupts are always disabled you can use
spin_lock(&lock);
spin_lock(&lock) can also be used in your interrupt handler if your device only uses one interrupt: the kernel guarantees that a interrupt handler is never reentered, even if the interrupt handler runs with enabled interrupts.
The _bh variants disable bottom half delivery [softirqs, tasklets and the old bottom halfs such as timers]. Within your bh handler you can use spin_lock() instead of spin_lock_bh().
Elsewhere, Matthew Wilcox gave a pointer to The Fucked Up Sparc in the Unreliable Guide To Locking by Paul Rusty Russell.
6. Alan Recommends Against BitKeeper
17 Jun 2000 - 23 Jun 2000 (16 posts) Subject: "Linux 2.2.17pre4"
Topics: Version Control
People: Steven N. Hirsch, Alan Cox, Larry McVoy
Some confusion came up over which patches were producing which errors, and in the course of discussion Steven N. Hirsch remarked, "I _really_ wish that Larry McVoy's BitKeeper was in regular use, so patchsets can be applied/backed-out in a fine-grained manner." Alan Cox replied, "It wouldnt make any odds. Patchsets have complex inter-dependancies. You dont generally want to go playing mix and match." Bitkeeper was first covered by KT in Issue #19, Section #9 (11 May 1999: Bug Tracking And Revision Control For Linux) , then again in Issue #38, Section #5 (27 Sep 1999: Version Control System Flamewar) , and finally made a momentary mention in Issue #45, Section #8 (16 Nov 1999: Historical Digression) .
7. New Attempt At Fixing 'kswapd' But No Luck So Far
18 Jun 2000 - 20 Jun 2000 (8 posts) Subject: "PATCH: Improvements in shrink_mmap and kswapd"
People: Juan J. Quintela
Juan J. Quintela posted a patch, and announced, "this patch makes kswapd use less resources. It should solve the kswapd eats xx% of my CPU problems." No one replied with any success, and there was some criticism of the patch.
8. Makefiles Inefficient Since 2.2.16
18 Jun 2000 - 20 Jun 2000 (7 posts) Subject: "Very touchy eager-to-remake make or kernel makefiles?"
People: Igmar Palsenberg, Ricky Beam, Xuan Baldauf, Russell King
Russell King reported that during compilation, a lot of files seemed to be getting recompiled even though they hadn't changed. Igmar Palsenberg replied that he'd already posted a bug report on that. He added, "The makefile is realy f*cked up since 2.2.16. Try changing 1 c file, do a make and see that make fails after the System.map is created. No errors are shown." Elsewhere, Xuan Baldauf bemoaned the nonexistence of a global Makefile, which he felt would speed up compilation as well as the development process itself. Elsewhere, Mike Frisch also confirmed the problem, and Ricky Beam explained, "Well, there is a reason... there is a weak build avoidance system within the kernel makefile system that tries to check the "flags" used during compilation. If something doesn't get its flags marked, then it will be forced to be rebuilt -- I toyed with fixing this, but it's too much of a mess to be fixed easily. You'd think after 10 years, someone would have learned to write a makefile *sigh*"
9. Maintaining Buildable Ports
19 Jun 2000 - 23 Jun 2000 (17 posts) Subject: "IA64 version of 2.4.0-test1 has compile errors/config errors"
People: Jes Sorensen, Jeff V. Merkey, Matthew Wilcox
A similar discussion was covered recently in Issue #73, Section #10 (12 Jun 2000: Developer Philosophy: Quietly Breaking Hardware Ports In Unstable Series) .
Jeff V. Merkey was having trouble building 2.4.0test1 on the IA64. He posted some information, and Jes Sorensen chastized him for posting to linux-kernel instead of the more specific linux-ia64@linuxia64.org list, since as he put it, "There is a much bigger chance that the appropriate people will read it there." Jeff objected, "I understand that the IA64 folks should get the message in the most efficient manner possible, but unless I am mistaken, there's only "one" master Linux tree, and unless the two are planned to diverge, www.kernel.org should be the central repository for IA64, just like any other Linux port, otherwise, we get the current situation -- the build at www.kernel.org is not always current or at the expected level of completeness that the rest of Linux enjoys. It took me over four hours Sunday to locate and download all the patches and fixes from www.ia64linux.org and hp.com to get the build from www.kernel.org to even compile for IA64." Jes replied, "You know what, it's been like that for non x86 ports for years, we try to fold the stable trees into the official tree and keep the architecture specific changes uptodate in the development trees. However things are changing so fast and there is only *one* Linus that you *cannot* in any reasonable way expect to have anything integrated at all times."
In the same post, Jes added, "linux-kernel is already so overloaded with rubbish because a lot of people keep posting tons of totally non kernel related questions here (or say answers to the list which are just a personal thank you and a copy of the entire previous email .... hint hint). Having a dedicated mailing list per architecture to handle architecture specific questions is very useful." Jeff replied, "I agree so long as folks can get a **WORKING** IA64 linux tree from www.kernel.org. This is clearly not the case today. I am concerned that Intel's IA64 effort may get a black eye if everytime folks download an IA64 Linux from www.kernel.org, they discover that they canot build it." Jes said he could not see Jeff's point. Downloading the sources from www.kernel.org and applying a single patch, produced a working kernel. But Jeff replied that although this might be true, the compilation process produced a lot of warnings and errors, and forced the user to manually edit the config file.
Matthew Wilcox observed, "I don't see why ia64 should be treated any differently from mips/arm/m68k/ppc/sparc/... all of which are in the tree and still need separate patches. It's Just The Way It Works." Jeff reiterated that the patches were extremely difficult to apply, but Matthew finished with, "the same is true for almost all other architectures."
Jeff was not satisfied, and eventually the thread petered out.
10. Hunting For The 'kswapd' Problem
19 Jun 2000 - 20 Jun 2000 (20 posts) Subject: "shrink_mmap() change in ac-21"
Topics: Virtual Memory
People: Linus Torvalds, Rik van Riel, Zlatko Calusic
Zlatko Calusic noticed that the 2.4.0-test1-ac21 virtual memory system seemed to remove a test-for-wrong-zone in shrink_mmap(), which caused the system to discard many wrong pages before getting to the right one. In the course of discussion, Linus Torvalds said, "The zone test is _definitely_ needed, because without that test we'll deplete zones that have tons of memory and really should not be depleted.." And Rik van Riel remarked, "Indeed, and reinserting the zone goodness test makes the system perform wonderfully again. It was removed shortly in -ac21 for unknown reasons. Removing that test was done by a few people on IRC when we tried to identify if that was the cause of high kswapd cpu use on low-memory machines"
11. Virtual Memory Opponents Work Together
19 Jun 2000 - 22 Jun 2000 (11 posts) Subject: "test1-ac22-classzone performance"
Topics: Virtual Memory
People: Andrea Arcangeli, Rik van Riel, H. Peter Anvin
Rik van Riel and Andrea Arcangeli had another staircase (friendly, this time) about the Virtual Memory subsystem. H. Peter Anvin actually started it off with a report of very bad performance on a high memory machine running 2.4.0-test1-ac22 with Andrea's classzone patch compiled in. Andrea posted a patch, but said he thought the slowdown was not classzone-related. Rik felt that some parts of the patch were wrong, and eventually posted some code of his own. Andrea liked these changes, though he felt it wasn't perfect either, and they went back and forth a bit on the technical details.
12. More On VM: 'classzone' Better In Benchmarks
20 Jun 2000 - 21 Jun 2000 (6 posts) Subject: "ac22-class versus ac22-riel, P133-32Mb laptop"
Topics: Virtual Memory
People: Andrea Arcangeli, Juan J. Quintela, Cyrille Chepelov, Rik van Riel, Mike Galbraith
Cyrille Chepelov tried comparing 2.4.0-test1-ac22 plus Rik van Riel's strict zone patch, against the same kernel with Andrea Arcangeli's classzone patch instead of Rik's. He measured the cache-, swap-, and buffer-usage of both in a real-world situation. His conclusions were that the classzone patch used slightly less resources. However, it also started applications slower than Rik's patch did, and woke apps out of swap slower as well. Cyrille felt the tests to be inconclusive, favoring neither in any strong way.
Mike Galbraith also did some comparisons between those same kernels, except with Juan J. Quintela's latest patches added in. His measurements involved shoving as much stuff through swap as possible, and he found the classzone kernel to be much faster. There was no discussion.
13. Philosophy Of Listing Security Fixes In Changelog
22 Jun 2000 (3 posts) Subject: "List of security fixes in 2.2.x"
People: Florian Weimer, Alan Cox
Florian Weimer asked if a complete list of 2.2 security fixes existed anywhere. He remarked, "Alan Cox's "release notes" mention most fixes, but they are remarkably terse regarding security fixes. Is this intentional?" Alan Cox replied, "They should list all fixes reasonably accurately. They may well not tell you how to exploit them. That is intentional."
14. Anonymous Poster Claims GPL Violations Are Accepted By Linux Community
23 Jun 2000 - 25 Jun 2000 (11 posts) Subject: "GPL violation is a Linux Community standard"
People: Jes Sorensen, Alan Cox, Richard M. Stallman
An anonymous hotmail account identifying itself only as "Mr. Smith", posted to the list, claiming that various Open-Source-savvy people had told him about an unwritten clause of the GPL and LGPL, in which a distribution of binary-only versions of GPLed code can persist for an unspecified amount of time, as long as the distributor claims that it is only an intermediate package. The anonymous poster sited two cases, involving Tripwire Security and Corel Corporation. In the Tripwire case, Mr. Smith pointed out that, as stated in a press release, they announced they would Open Source their Linux product. But he pointed out that the demo, available at the Tripwire download page, violated the LGPL: Mr. Smith said that even after an inquiry by Richard Stallman, they did not provide object files for relinking to modified versions of the LGPLed library. Apparently Tripwire then claimed that the product was just an "intermediate package", after which they have seemingly been allowed to continue in violation of the LGPL.
In the case of Corel, Mr. Smith claimed that they had distributed CDs of their Linux distribution, without any offer of source code. When questioned, they apparently replied that the software was an "intermediate package". According to Mr. Smith, neither Corel nor Tripwire gave any indication of how long this intermediate phase would last.
There was no truly summarizable discussion, but some interesting tidbits, sometimes peripheral, did surface.
At one point, Jes Sorensen remarked, "The real question here is actually why someone hiding behind a hotmail account, without including his real name, posts something like this to linux-kernel where it is completely off topic. And of course the much bigger question why some people just have to reply to it? One can only guess it was a troll."
Elsewhere, Alan Cox remarked, "If someone is providing static linked binaries against glibc and not providing the required offer to either provide a dynamic linked one or a .o file (ie an ld -r) of the application and it is on the Red Hat extra applications disk I'd like to know, along with a copy of the correspondance involved."
Elsewhere, Alan also remarked, "Actually folks get sued for not following copyrights. I've been talking to someone recently who plans to solve the KDE gpl/nongpl issue by issuing cease and desist orders to KDE. Vendors also take it seriously. Some of them anyway"
Richard Stallman also posted to the list in reply to Mr. Smith's initial statement. He said:
Nothing in the GPL, whether written or "unwritten", makes any exception for "intermediate" packages. All distribution of all versions must follow the GPL.
However, the GPL is enforced by copyright holders, and they might find it reasonable to forgive a violation if the perpetrator agrees to bring it to an end reasonably quickly. For instance, I saw no point in threatening to sue Tripwire if they were going make their program free in short order and thus comply permanently. If it drags on, that's a different issue.
Regarding the Corel story, Richard replied, "I thought that Corel had abandoned these plans in September. Since then I have heard nothing about it. Would you please give me more details of this activity? What is the name of the product? Can you tell me the names of some FSF-copyrighted programs that are included?" And finally, he concluded, "no company is entitled to decide to pick and choose which parts of the GPL to follow. We will have to take action, once we get details to base action on."
There was also some talk that the whole topic was not relevant for linux-kernel, and eventually Richard replied to the general sentiment:
I can see why people on the linux-kernel list would consider license violations concerning GNU libc, or any program other than Linux, to be off-topic; the right place to report GNU libc license violations is to the FSF, which is the copyright holder of GNU libc.
I will ask my assistant to check the eight packages you mentioned, and we will take the appropriate actions. Thanks for sending the list. If you find any other such violations, you may as well send them directly to me.
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. |