Kernel Traffic
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Kernel Traffic #104 For 26�Jan�2001

By Zack Brown

linux-kernel FAQ | subscribe to linux-kernel | linux-kernel Archives | | LxR Kernel Source Browser | All Kernels | Kernel Ports | Kernel Docs | Gary's Encyclopedia: Linux Kernel | #kernelnewbies

Table Of Contents

Mailing List Stats For This Week

We looked at 1438 posts in 6309K.

There were 453 different contributors. 207 posted more than once. 173 posted last week too.

The top posters of the week were:

1. More On 2.4 Development Policies

6�Jan�2001�-�16�Jan�2001 (11 posts) Archive Link: "Does reiserfs really meet the "Linux-2.4.x patch submission policy"?"

Topics: FS: ReiserFS, FS: XFS, FS: ext3

People: Andre Dahlqvist,�Linus Torvalds,�Aaron Lehmann

Andre Dahlqvist was surprised to see that Reiserfs had made it into the 2.4.1 prepatches. This didn't seem to go along with Linus Torvalds' patch submission policy (See Issue�#103, Section�#9� (6�Jan�2001:�Patch Submission Policy For 2.4) ), which had seemed to limit acceptable patches to only the most needed and obviously correct, at least in the early 2.4 kernels. Andre said, "In my understanding of your "2.4.x patch sumission guidelines" these large patches was exactly what you wanted to avoid at this point in time." He quoted Linus as having said, "I want to be absolutely convicned that the basic 2.4.x infrastructure is solid as a rock before starting to accept more involved patches." Andre added as a disclaimer, "Don't get me wrong, I am personally really excited that reiserfs was included. I just thought that you basically wanted 2.4.1 to be "boring"." Linus replied:

Reiserfs inclusion in 2.4.1 was basically the plan for the very beginning: it was so widely known that it was even reported in the press, so I didn't even bother to point out reiserfs as a 2.4.1 patch.

That said, I wanted to leave the window open for any showstopper bugs, and have a pure "bug-fixes only" 2.4.1 if needed. I'm actually fairly happy that there haven't been any really serious reports so far.

Inclusion of reiserfs is not going to add any bugs for the non-reiserfs case (apart from a stupid merge issue, and now I've watched all the non-reiserfs diffs with a microscope), so in that sense it's safe. Peopel who would have used reiserfs anyway would have gotten more problem reports, so..

If I were you, I'd worry more about the blk-patches from Jens, but they've been around for a long time, and Alan also put them in his tree. Which makes them as safe as any patch we've seen. So I took the approach that "we'll obviously have to put this _somewhere_ in 2.4.x". But that is, at least to me, a potentially bigger worry than reiserfs.

(Actually I'm not so much worried that the blk patches themselves would have bugs, as worried about them showing bugs in block drivers by being better at merging requests. Those kinds of bugs we'll have to figure out during 2.4.x anyway though, but it's a case of a latent bug maybe showing up more easily under higher load generated by the blk fixes).

Close by, Aaron Lehmann also asked about the possibility of XFS going into 2.4 at some point. He'd been using it for some time without any problems. Linus replied with a take on the whole journalling spectrum, and the purpose of the stable series in general:

ResierFS really is a fairly special case: it's been one of the main filesystems at SuSE for a longish time, and of the journalling filesystems it's the only one I know of that is in major real production use already, and has been for some time.

There's no question that there are other Journalling filesystems on the horizon, but I'm not hearing anybody who can't do the patching themselves who is interested in using it. Remember: one of the main criteria for 2.4.x inclusion was the "vendor would want it" part. If it's a "developers might want to play with it" kind of thing, then it might as well live as an external patch for a while.

For that reason, I would expect Ext3 to be the next filesystem to be integrated, but I would _also_ expect that RedHat will actually integrate it into their kernel _first_, and expect me to integrate it into the standard kernel only afterwards.

But no, vendors aren't everything. And there are other vendors than just SuSE and RedHat. So take all of the above with a pinch of salt. And remember: these are just the 2.4.x rules - it's a different game when the development kernel opens again, and "vendor wishes" are much less of an issue when that happens. In the meantime, I see the stable kernel mainly as a way to support vendors, and am thus always weighing things from that angle when worrying about 2.4.x features.

End of thread.

2. Greater 2.4 Swap Requirements

7�Jan�2001�-�18�Jan�2001 (100 posts) Archive Link: "Subtle MM bug"

Topics: Virtual Memory

People: Rik van Riel,�Linus Torvalds,�Eric W. Biederman,�Zlatko Calusic

In the course of discussion, it became clear that Linux 2.4.x required more swap than previous versions. Rik van Riel mentioned, "2.4 keeps dirty pages in the swap cache, so you will need more swap to run the same programs..." He asked Linus Torvalds, "is this something we want to keep or should we give the user the option to run in a mode where swap space is freed when we swap in something non-shared ?" Linus replied:

I'd prefer just documenting it and keeping it. I'd hate to have two fairly different modes of behaviour. It's always been the suggested "twice the amount of RAM", although there's historically been the "Linux doesn't really need that much" that we just killed with 2.4.x.

If you have 512MB of RAM, you can probably afford another 40GB or so of harddisk. They are disgustingly cheap these days.

Zlatko Calusic worried that more data in swap would degrade performance because the disk head would need more seek time to find data. He asked if Linus was sure this would be okay, and Linus replied, "I'm not _sure_, obviously. However, one thing I _am_ sure of is that the sticky page-cache simplifies some things enormously, and make some things possible that simply weren't possible before." . But in a nearby post he admitted, "the sticky allocation _might_ make the IO we do be more spread out." He felt it was important to consider these kinds of potential downsides, though he felt that in this case the benefits outweighed the drawbacks; and at one point Eric W. Biederman explained succinctly, "The tradeoff when implemented correctly is that writes will tend to be more spread out and reads should be better clustered together."

Zlatko ran some tests, and could not find any problems with the 2.4.0 memory management logic, though he added, "I have found that new kernel allocates 4 times more swap space under some circumstances. That may or may not be alarming, it remains to be seen." At one point, Linus gave his overall take on 2.2/2.4 performance issues. He said:

I personally think 2.4.x is going to be as fast or faster at just about anything. We do have some MM issues still to hash out, and tuning to do, but I'm absolutely convinced that 2.4.x is going to be a _lot_ easier to tune than 2.2.x ever was. The "scan the page tables without doing any IO" thing just makes the 2.4.x memory management several orders of magnitude more flexible than 2.2.x ever was.

(This is why I worked so hard at getting the PageDirty semantics right in the last two months or so - and why I released 2.4.0 when I did. Getting PageDirty right was the big step to make all of the VM stuff possible in the first place. Even if it probably looked a bit foolhardy to change the semantics of "writepage()" quite radically just before 2.4 was released).

Elsewhere, he considered the case of swapless or low-swap machines:

If you don't have any swap, or if you run out of swap, the major difference between 2.2.x and 2.4.x is probably going to be the oom handling: I suspect that 2.4.x might be more likely to kill things off sooner (but it tries to be graceful about which processes to kill).

Not having any swap is going to be a performance issue for both 2.2.x and 2.4.x - Linux likes to push inactive dirty pages out to swap where they can lie around without bothering anybody, even if there is no _major_ memory crunch going on.

If you do have swap, but it's smaller than your available physical RAM, I suspect that the Linux-2.4 swap pre-allocate may cause that kind of performance degradation earlier than 2.2.x would have. Another way of putting this: in 2.2.x you could use a fairly small swap partition to pick up some of the slack, and in 2.4.x a really small swap-partition doesn't really buy you much anything.

3. Dealing With Spammers

7�Jan�2001�-�18�Jan�2001 (32 posts) Archive Link: ".br blacklisted ?"

Topics: Spam

People: John O'Donnell,�Rik van Riel,�David Ford,�Peter Samuelson,�Antony Suter,�Brad Felmey

Rik van Riel tried to answer a question from John O'Donnell, but his email cuoldn't pass John's spam filters. Rik posted to the list, and John replied that the aggressive filter only applied to his work email. He explained, "My company typically gets "zero" emails from outside the US. If I get a piece of spam (sorry they are typically from outside the US), I just block the entire domain. I get far less SPAM now! I cannot express how much I loathe SPAM! I have taken this one in particular out just for you.... :-) I am the only one at my company really active on the internet.."

Rik replied, "Remind me to never help you with kernel problems again." David Ford lamented, "Others on this list blacklist or let others blacklist for them with varying precision. Sooner or later everyone is going to be blacklisting everyone else until it's a daily thing here and no developer or user can talk to any other devloper or user." Rik said he also had his own blacklist, and that "I chose to blacklist John O'Donnell and he will never get any kernel help from me again (since I can't see his email)." John's eyes bugged out and he replied, " Please tell me I just didn't just see this message??!?!?!?! Please??!?!?!? What are you doing? I mean no one person here any disrespect - please do the same. Why did you say this? Please tell me? Please?????" Peter Samuelson sat him down and said:

Hold on. First you go and blacklist the entire country of Brazil, then you actually wonder *why* someone working for a Brazilian company might blacklist you in return? The mind boggles.

Dude, I'm all for freedom-of-blacklisting (it is, after all, *your* mailbox), but you gotta take the consequences!

Roeland Th. Jansen said roughly the same thing, and John shrugged resignedly. "Oh well," he said, "Apologies Rik - I admire your toughness." Antony Suter replied, "I dont believe this. JohnO, you're a sysadmin and you blacklist the .com domain of an entire country just because you dont like some spam? You didn't checkout out any better ways of doing it?" John replied, "Maybe you don't understand," and explained that at his company, there were only 18 employees, and that none but him ever used the internet via that connection. Brad Felmey replied:

No, John, it's quite obvious that it's _you_ who does not understand. You've saved yourself some spam and pissed off a good deal of the kernel list, including the ones who are in the best position to help you. Was it a good trade?

When so many clueful folks disagree with you, perhaps you should re-examine your actions and ask yourself if they are all wrong, and you know better than all of them, or the inverse.

However, at this point David spoke up for John, saying:

Many disagree, but many here also support ORBS which does some pretty hefty galaxy wide blacklisting. Some of those that support it are some of the powers that be in here. I.e. clueful folk.

So you can't fault John for personally effecting a policy similar to what ORBS does en masse.

It's a vicious circle but nobody wants to take the effort to figure out a way we can all talk in spite of the filtering. For example, none of the networks I have permit open relaying and all of them are tested and listed "OK" w/ ORBS, but the only way I can email Alan is to post it here or go use somebody else's network. We, the internet, route around brokenness. For some things I arranged relays through their network so I could reach my recipients. What can you do? Spend connection fee after connection fee for a new provider because the provider you were with [which has a strong anti-spam TOS] get's targetted by ORBS? I don't think so.

Yes, it's an aggravation and it isn't going to get any better until enough people get blacklisted. It doesn't matter how good you, your network, or your upstream is, as long as there are projects out there that don't care if they smite 15% good guys as long as they are getting 85% bad guys and there's nothing reasonable you can do. I don't consider switching providers every few months reasonable, especially when given providers are very anti spam in the first place.

4. Elusive 2.4.0 Boot Failure On 80386

9�Jan�2001�-�15�Jan�2001 (39 posts) Archive Link: "Anybody got 2.4.0 running on a 386 ?"

Topics: FS: ext2

People: Robert Kaiser,�Ingo Molnar,�Paul Gortmaker,�Linus Torvalds,�Richard Moore,�Alan Cox,�Timur Tabi,�Brian Gerst

Robert Kaiser tried and failed to get 2.4.0 running on a 386. In fact he'd tried three separate 386 motherboards with no success at all. As far as he'd been able to dig, "Execution seems to get as far as pagetable_init() in arch/i386/mm/init.c, then it falls back into the BIOS as if someone had pressed the reset button. The same kernel boots fine on 486 and Pentium Systems." In a later post, he reported that the last message echoed to the screen was "Uncompressing Linux... Ok, booting the kernel."

In the course of discussion, Sven Joos managed to dig up an old 386 and confirm Robert's problem. Sven tried numerous kernels, and found that 2.2.19-pre6 and 2.3.39 would both compile and boot perfectly, while 2.3.59 wouldn't even compile, and the 2.3.99-pre* kernels would crash on the machine, as would 2.4.0; he asked which kernels to test next, and Brian Gerst suggested moving up to the 2.4.0-test series. Sven tried 2.4.0-test1 with the same crash, and the subthread ended. Close by, however, Sven reported some code changes that would allow the kernel to boot on a 386. There was no reply.

Elsewhere, other folks also tried to debug the problem. Brian thought the kernel might be misdetecting the memory size, and suggested specifying 8M RAM on the command line. Robert tried this with no success, but his results seemed to indicate to Timur Tabi that the problem was either a compiler bug or a race condition somewhere in the kernel. Ingo Molnar felt Robert's results could also appear if the kernel was too large, and suggested removing ext2fs support just to try to get through the boot process somehow.

Robert replied that he'd already left ext2fs out of the build, since the system was intended to be diskless. But he also recalled getting a bootable kernel by disabling floating point emulation support; though he didn't remember the details. Ingo replied, "math-FPU emulation takes up quite some space in the kernel image, so this could indeed be the case. Could you disable any non-boot-essential subsystem (networking, or the serial driver, or anything else), to significantly reduce the image size?" Robert tried it with no luck; the subthread continued diagnostically for awhile, then petered out.

Elsewhere, folks started peppering Robert with questions. How much physical RAM did he have? How big was his kernel image? Did he try to make zImage or bzImage? Did he use a .config file from a 2.2 kernels or did he build a new .config from scratch? At one point, Paul Gortmaker reported performing a similar experiment on possibly an identical machine as Robert's, an Olivetti M300-05 386sx with 5MB. He reported:

it came up ok, except that memory detection is off by a MB. (to be fixed in 2.4.1 or boot with mem= argument in 2.4.0)

What might be important here is your gcc & binutils (as/gas) version, combined with a miscompile in something like __verify_write that doesn't get used on anything but 386 (and hence went undetected).

Only thing strange on my box is that the kernel is compiled with gcc-2.7.2 which is officially unsupported but can be managed if you know what the gcc bugs are.

In reply to this, Robert said:

I finally found the reason why 386es have trouble booting the 2.4.0 kernel:

In routine pagetable_init() in arch/i386/mm/init.c, a pte gets installed before it actually has been filled with valid entries. This causes the kernel text segment to be temporarily unmapped. Pentiums are only lucky to not crash because they have a bigger TLB than 386s.

He posted a patch to fix it, and thanked everyone who'd helped track down the problem. Linus Torvalds congratulated him on a job well done, and commented regarding Pentium susceptibility to this bug:

Actually, with the 4M pages, it's not a question of luck any more - they just don't _have_ this bug, because on a machine with 4M pages the "cpu_has_pse" case handles this all and the buggy code is never actually entered.

Which explains why you'd only see this on a 386 (and I suspect your TLB size explanation is what saved some i486-class machines, although later i486 machines will have PSE as well).

As an epilog, Richard Moore asked, "Does linux cater of all the old 386 chip bugs - especially the memory management oddities?" Alan Cox replied, "So called 'sigma sigma' 386 and higher. Ie we dont support the 386 with the 32bit mul bugs. Also a lot of 386's crash if you abuse popad instructions from user space and there is no fix." Later he added, "We've never supported pre sigmasigma cpus although someone posted a patch to Linux 1.2 once. You won't find many of the cpus before that. At the time 386 was priced like a Xeon is now and most were recalled/pulled when the mul bug came out."

5. Module Initialization Issues

9�Jan�2001�-�15�Jan�2001 (41 posts) Archive Link: "Where did vm_operations_struct->unmap in 2.4.0 go?"

Topics: Kernel Build System, Networking, PCI

People: Keith Owens,�Alan Cox,�Ingo Oeser

In the course of discussion, Alan Cox asked how Keith Owens' modutils code would handle a loop in the module initialization order, and Keith replied that the code would not handle such a situation gracefully. He anecdoted, "A while ago there was accidentally a loop between two ppp related modules, each needed a routine in the other module. modprobe would not load them. Even if it could have loaded them, it would have been impossible to unload, both modules would have had a use count on the other. The fix was to remove the incorrect loop, it was a programming error." (see Issue�#97, Section�#6� (28�Nov�2000:�'modprobe' Infinite Loop On Buggy Drivers) ) Ingo Oeser asked for an in-depth explanation, and Keith obliged:

The initialisation order is a dependency on actions, not on symbols. Code F cannot start until code E has initialised so execute E before F. This should have *NOTHING* to do with link order, but it is implemented as a side effect of link ordering which confuses people.

People need to realise that the problem is initialisation order, nothing more, nothing less. You have to determine and document the startup requirements for your code. Only you know what the startup pre-requisites for your code are, there is no way for another program to determine this from the source. Document your startup requirements, implement according to the documentation and your problems go away.

Initialisation order is not the problem, the implementation is the problem. The method currently used to control initialisation order sucks. It is better than the original method (lots of conditional calls in main.c) but it still sucks.

It is no wonder that people have problems getting the initialisation order correct.

I want to completely remove this multi layered method for setting initialisation order and go back to basics. I want the programmer to say "initialise E and F after G, H and I". The kernel build system works out the directed graph of initialisation order then controls the execution of startup code to satisfy this graph.

That still means controlling link order to achieve the required result. But with my approach the complexity would be handled by kbuild based on explicit rules which are documented in the local Makefile, instead of the complexity being handled by programmer via implicit rules scattered over several layers of Makefiles.

A typical graph would have scsi disk depends on scsi host adaptor group which depends on pci. Within the scsi host adaptor group you might need to initialise one driver before another, so just declare the few inter-driver dependencies. kbuild would automatically initialise pci then the scsi host adaptors (in the correct order) then scsi disk.

Most of the objects have fairly simple execution dependencies, e.g. all file systems depend on core fs code having already executed. There are no dependencies between most file systems so most file systems could initialise in any order ( which means they could be linked in any order within the file system group.

I am ready and willing to code this method, it would make kbuild a lot easier to code, as well as making future maintainence a lot easier. Linus refuses to accept this approach. He insists that kernel coders explicitly specify the link order for everything, via Makefile order. As long as Linus insists on kernel coders explicitly controlling the entire link order, we are stuck with the current method. I have tried to change his mind without success.

6. Temporary Filesystem Corruption Workarounds In 2.4

12�Jan�2001�-�15�Jan�2001 (60 posts) Archive Link: "ide.2.4.1-p3.01112001.patch"

Topics: Disks: IDE, PCI

People: Linus Torvalds,�Andre Hedrick,�Vojtech Pavlik,�Alan Cox,�Stephen Clark

Andre Hedrick posted some IDE patches, and Linus Torvalds rejected them, saying, "I want to see the code to handle the apparent VIA DMA bug. At this point, preferably by just disabling DMA on VIA chipsets or something like that" [...] "We've already had one major fs corruption due to this, I want that fixed _first_." Alan Cox added that he'd seen other reports of this as well. Andre replied, "Well since I do not have VIA boards and Vojtech Pavlik <> is doing that chipset, take that issue to him. VIA has always been a HACK fro mthe beginning because it was written off the whitepapers that stink."

A couple posts later, Vojtech Pavlik said he had a vt82c586 for test purposes, and asked, "Does anyone still have any vt82c586 or vt82c586a the 2.4 VIA driver is corrupting data on? I'd like to hear about such reports so that I can start debugging (and perhaps get me one of those failing boards, they must be quite cheap these days)." Alan gave the details of one report, involving an AMD K6-3 on a FIC PA-2013 motherboard with 3 IDE disks. /dev/hda was 4.3G, /dev/hdb was 854M, and /dev/hdc was 1.2G; /dev/hdd was a CDROM drive. He added, "I think its significant that two reports I have are FIC PA-2013 but not all."

Linus also replied to Vojtech, regarding Vojtech's use of the vt82c586 board for testing. He said:

The fact that it works on one board doesn't mean that it works on _every_ board.

This is, in fact, why I will _NOT_ accept anything but a simple auto-dma disable for this problem for early 2.4.x. I hope that people will continue to work on and debug this problem, but it's just been around for too long, and it's obvious enough that it doesn't happen with all hardware that I doubt there is any other reasonable solution that doesn't require some _very_ extensive testing to verify.

I'd love to see people who see these problems and are willing to test out patches to fix it. But in parallel with that, I definitely want the 2.2.x "disable auto-DMA" thing for the big public. We can enable it later if some patch does seem to fix it for good.

Vojtech had no problem with this, and proposed:

Alan's IDE patch for 2.2 kills autodma on ALL VIA chipsets. That's because all VIA chipsets starting from vt82c586 to vt82c686b (UDMA100), share the same PCI ID.

Would you prefer to filter just vt82c586 and vt82c586a as the comment in Alan's code says or simply unconditionally kill autodma on all of VIA chipsets, as Alan's code does?

Linus replied, "for 2.4.1, I'd rather have the patch to just do the same as 2.2.x. We can figure it out better when we get a better idea of exactly what the bug is, and whether there is some other work-around, and whether it is 100% certain that it is just those two controllers (maybe the other ones are buggy too, but the 2.2.x tests basically cured their symptoms too and peopl ehaven't reported them because they are "fixed")." Vojtech posted a short patch, but then Stephen Clark objected, "This sucks! I have had several systems with VIA chipsets and have never had any problems. Currently I am running a SOYO K6-2 system with UDMA 33 and a SOYO K-7 system with both UDMA-33 and UDMA-66 with not problems. How do we know that there is not some related hardware problem, (cable, power supply, etc ) with the systems that reported problems? What percentage of people are running OK VS those that are not? Now everybody with a VIA chipset is going to be punished!"

There was no reply.

7. LVM Cleanup

12�Jan�2001�-�16�Jan�2001 (7 posts) Archive Link: "*** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at"

Topics: Disk Arrays: LVM, Ioctls

People: Andreas Dilger,�Patrick Caulfield,�Anton Blanchard,�Heinz Mauelshagen,�Christoph Hellwig

Heinz Mauelshagen announced Linux Logival Volume Manager version 0.9.1 beta1 at, and asked for all feedback to go to Anton Blanchard took a look at arch/sparc64/kernel/ioctl32.c in the 2.4 tree, and pointed out some ugly hacks required by LVM due to some messiness in the ioctl interface. He asked if it would be possible to clean up that code; Andreas Dilger took a look at the file, retched into his hand, and asked why such code was needed. "It may in fact be damaging," he advised, "because I don't know if any of the LVM developers even know it is there, and surely it will be out of sync..."

Anton Blanchard and Christoph Hellwig gave some technical explanation, and at one point Patrick Caulfield said to Christoph, "If you're prepared to do the work we'd be glad to accept the patch - please send it to me or the list so I can check over it before committing it. As we don't have an UltraSPARC available for testing it's probably better done by someone who does !"

8. 2.4 Interactivity On Low-End Systems

14�Jan�2001�-�15�Jan�2001 (3 posts) Archive Link: "2.4.0-ac9 works, but slower and swappier"

People: Mark Orr,�Marcelo Tosatti

Mark Orr tried 2.4.0-ac9 for a day or so on his Pentium 100MHz, 16M RAM system, and reported really bad responsiveness. He gave a brief description, saying, "it really seems to bog down with anything heavy in memory. Netscape seems to really drag, and any Java applets I encounter positively crawl -- you can see the individual widgets being drawn." He added that with 2.4.0-ac4, speed had been much more acceptable. Marcelo Tosatti gave a link to a patch, and Mark replied that this was a very decisive fix. The system reacted pretty much as it had with -ac4, maybe even a little better.

9. Test Suites

14�Jan�2001 (2 posts) Archive Link: "Article: Using test suites to test the new kernel"

People: Michael D. Crawford,�David D.W. Downey

Michael D. Crawford announced:

I've written a brief article on the topic of using test suites to test new linux kernels.

It is my hope that anyone who wants to play with the new kernels will try out some of these suites, not just people doing a formal QA process, so that more coverage of configurations can be achieved.

Using Test Suites to Validate the Linux Kernel

I cover the use of suites that test the correct functioning of applications (for example, language compliance tests for Python and Kaffe's Java implementation) as well as test suites aimed directly at testing Linux itself.

Links to five different packages with test suites are given. I'd appreciate hearing of any more that you know about.

I also appreciate your comments on how I can improve the article. This is a first draft.

David D.W. Downey fell to his knees, lifted his arms in the air, and said unto Michael, "God sent you right? :) Been looking for something along this nature."

10. Success With WinModems Under 2.4.0

15�Jan�2001 (7 posts) Archive Link: "linmodem????"

Topics: Modems

People: Wayne Brown,�Christoph Rohland,�Alan Shutko,�Jeff Chua,�Gary Lawrence Murphy

Jeff Chua wanted to use his WinModem under Linux 2.4.0, but the binary available at only worked under 2.2; Wayne Brown replied that he (Wayne) had not found any solution for this on his own system, and was forced to keep a 2.2.14 kernel around just in order to use the WinModem. He said, "It's a pain having to reboot when I want to use the modem, but it's the only solution I've found." Alan Shutko gave a pointer to a 2.4 solution, and Christoph Rohland, Jeff Chua, Gary Lawrence Murphy and Wayne all reported complete success.

11. 2.4 Series Changelogs

17�Jan�2001 (3 posts) Archive Link: "What happened to your kernel changelogs?"

Topics: FS: FAT, FS: ReiserFS, FS: ramfs, Hot-Plugging, Networking, SMP, USB, Virtual Memory

People: Rik van Riel,�Linus Torvalds,�Jens Axboe,�Andrew Morton,�Tobias Ringstrom

Tobias Ringstrom bemoaned the fact that Linus had stopped posting changelogs to each new pre-release after 2.4.0 came out. Rik van Riel replied:

I like them a lot too.

Without the changelogs Linus is just a "black box" which outputs random patches.

With a good changelog, we all have a much better idea what Linus wants and, consequently, what kind of patches we should give him (and which kind of patches we should wait with for a week or so).

Also, the changelog items are a good way to keep track of what's happening with the kernel, it makes it so much faster to track down exactly when a bug was fixed or introduced and what change had this effect.

Linus Torvalds replied:

Current half-assed changelog:


The need for changelogs was recently discussed during the 2.4-test series, and covered in Issue�#70, Section�#6� (23�May�2000:�Proposal For Kernel Changelogs) , and may have been the reason Linus started posting them shortly thereafter.

12. IBCS And ABI For 2.4 Or 2.5

17�Jan�2001�-�21�Jan�2001 (3 posts) Archive Link: "Ibcs2 or abi for kernel 2.4"

People: John O'Donnell,�David Woodhouse,�Haris Peco

Haris Peco wanted to run binaries from other OSes on Linux, and asked if ibcs2 or abi were available for 2.4.x, and John O'Donnell replied, "Been discussed - Check this out:" . David Woodhouse added, "Yeah - dusting it off and making it work in 2.5 is somewhere on my ever-growing TODO list." He gave another URL, and the thread ended.

13. Filesystem Corruption Possibly Traced To RAID5 In 2.4

19�Jan�2001�-�20�Jan�2001 (3 posts) Archive Link: "Don't mix reiserfs and RAID5 in linux-2.4.1-pre8, severe corruption"

Topics: Disk Arrays: RAID, FS: ReiserFS, FS: ext2

People: Ed Tomlinson,�Hans Reiser

Someone reported filesystem corruption on 2.4.1-pre8, and attributed it to using Reiserfs in conjunction with RAID5. Ed Tomlinson and Hans Reiser both replied. As Ed put it, "This is not just a reiserfs/raid problem. Corruption has been reported on the kernel mailing list with software raid 5 and ext2..." Other threads this week seem to confirm a link between RAID5 and FS corruption as well.

14. 2.4 Poor Latency Report

20�Jan�2001�-�21�Jan�2001 (5 posts) Archive Link: "Kernel 2.4.x and 2.4.1-preX - Higher latency then 2.2.x kernels?"

Topics: FS: ReiserFS, FS: ext2

People: Gregory Maxwell,�Chris Mason,�Shawn Starr

Shawn Starr reported slowdowns and general sluggishness in 2.4.x while using Reiserfs. Gregory Maxwell replied:

Reiserfs uses much more complex data structures then ext2 (trees..). I don't think that latency has ever been a design criteria and all of the benchmarks they use are pretty much pure throughput tests.

So it wouldn't be really surprising if reiserfs had very bad latency. You should apply the timepegs patch and profile your kernel latency to see where it's coming from.

But Chris Mason said, "I'm actually very interested in fixing any latency problems. If you do these tests, please send the results along."

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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.