Kernel Traffic #106 For 9 Feb 2001

There were 544 different contributors. 265 posted more than once. 204 posted last week too.

There's been a lot of work on the 'zerocopy' patches over the past few weeks, including some long technical discussions. This week, David S. Miller announced the latest patch against the 2.4 tree, and Jonathan Earle asked what exactly these patches did. Mathieu Chouquet-Stringer explained, "Basically, if you want to send something to the network, the kernel has to copy your data to its memory space. It is an overhead and with these patches, the kernel doesn't has to do it. So it is faster. Moreover, few ethernet cards are able to compute the ip checksum so linux doesn't need anymore to do that." Jonathan speculated, "Hmm.. so things like routing should be faster then?" And Peter Samuelson replied:

Other network traffic too. Say you have an FTP server running and it wants to send a file out to a client. The old way was for it to read() the file into memory and then write() it to the network socket. To avoid having to copy all that data into the userspace buffer during read(), you can use mmap() instead. In Linux 2.1.1xx we gained a new syscall sendfile() which works like mmap()+write(), except faster since the necessary kernel memory management is a lot simpler. Using either sendfile() or mmap(), the userspace program (ftpd) doesn't have to touch the memory involved, just send it on to the socket. That was the first optimization relevant here, and it's been around awhile now.

Now with mmap()+write() or sendfile(), the kernel reads the data off the disk using the page cache, then the network stack copies it to other buffers, doing the TCP checksum in the process, and eventually the Ethernet card does a DMA transfer of some sort and sends it out the wire. Notice that the CPU has to copy the data from the disk DMA buffer to the network card DMA buffer, checksumming it somewhere along the way. Depending on circumstance, of course, there may be other copying involved as well.

With zerocopy, when you issue sendfile(), the kernel does the network DMA straight from the page cache, avoiding that extra copy. In the case where the network card is capable of doing the TCP checksum in hardware (as a lot of newer cards can), the kernel doesn't even have to look at the data between the disk DMA and the network DMA. This can save memory accesses and CPU data cache pollution. The only way to get a more direct route would be to do the DMA from disk controller to network card without touching main memory at all, but this can have a lot of complications and is probably not worth it in general

Alan Cox noticed an increase in the number of patches sent to him, containing broken spacing and line wrap damage. He said, "If your patches are getting ignored please mail yourself a copy and check your mailer works. If you have problems use mime (Linus doesnt like mime I dont care)." David Woodhouse pointed out that some recent versions of the pine mail reader would corrupt data by stripping white space off of line endings. Daniel Phillips added that netscape also corrupted patches, but Jeff Garzik said he sent patches via netscape all the time with very few problems. Daniel had also recommended kmail, and Chris Wedgwood recommended mutt.

Ralph Blach noticed kernel 2.2.18 supported HDLC (synchronous serial) cards, but that 2.4.0 did not; He asked why this was, and requested that the 2.2 interface be included somewhere down the 2.4 road. No one offered any explanation as to why the HDLC layer had been left out of 2.4.0, but Paul Fulghum and Alan Cox pointed out that it had already been added to the 2.4-ac patches, and Paul added, "I'm sure it will be folded into 2.4.X but I don't know when." That was that.

Micah Gorrell reported problems with the eepro100 driver under 2.4.0; under 2.2 it worked fine, "but under 2.4 I am unable to use more than one card in a server and when I do use one card I get errors stating that eth0 reports no recources." A lot of people confirmed this problem, and Andrey Savochkin said, "It's a known problem. I submitted the patch to Linus and the mailing list this weekend."

Elsewhere, under the Subject: eepro100 - Linux vs. FreeBSD, Romain Kang suggested, "One approach to the endless eepro100 headaches would be to port the FreeBSD if_fxp driver to Linux. After all, drivers have been ported between these OSs before; e.g., the aic7xxx SCSI adapter." The suggestion came out that the problems folks were seeing might be just in their configurations, but Udo A. Steinberg remarked, "Andrey posted a patch last week, which obviously fixes the 82559 problems. It's in Linus' latest 2.4.1-pre release too. I have an 82559 and with the patch there've been no issues here yet - so things are looking good so far. I suggest that instead of having 3 drivers (eepro100, e100, freebsd), people should just work together, look at the goodies of each driver and merge them into one perfect driver."

Michael B. Trausch reported problems with the maestro sound driver. When loading his system, the sound quality would get fuzzy, and would stay bad even after the load went down to previously acceptable levels. Georg Nikodym confirmed the problem, but said it had gone away in 2.4.0; but Michael replied that 2.4.0 did have the problem, it just didn't occur quite as often.

Barry K. Nathan also confirmed the problem, but added that he experienced the identical problem under Windows 2000. He said, "If it was just Linux, I'd assume it was a driver problem, but the fact that I'm getting very similar misbehavior from both Linux and Win2K (I don't have Win98 or ME on the machine, so I can't test that) makes me really wonder..." Michael replied that the card worked perfectly for him under Windows ME. Tom Sightler confirmed the problem under both Linux and Windows 2000, and Zach Brown explained:

This is a long-standing bug with the maestro2 driver.

My current theory is that its a race condition where the APUs get confused while we update their control memory, but this doesn't make total sense. Some of the bug reports I get are implying that the sound is breaking when we're not touching the apu's control mem. Maybe implying a nastier silicon bug..

I've been meaning to try implementing a work around to the theoretical bug, but I've always had trouble triggering it :/

The fun part of this (and why you would see the bug in win2k) is that the maestro2 is very poorly documented. I've never heard of anyone having full docs on the APUs, including the people I've talked to at ESS. They bought the part from another company.. (and thankfully axed it in the maestro3)

so we're stabbing in the dark.

Rob Kaper suggested renaming the lost+found directory to be .lost+found, which would make it a hidden file and keep it off of normal 'ls' listings. Various folks suggested other solutions, such as alias ls='ls -I "lost+found"', but Richard B. Johnson said lost+found was a part of the Linux/UNIX heritage and shouldn't go away. James Lewis Nance pointed out that IBM's JFS filesystem didn't have lost+found, Rodrigo Barbosa pointed out that reiserfs also didn't have it, but Stephen C. Tweedie pointed out that ext3 did have lost+found, since even journalling filesystems, he said, had to deal with filesystem corruption.

H. Peter Anvin reminded everyone that Rob's original question had been whether lost+found could be renamed, not done away with. H. Peter rephrased the question, as "does the tools (e2fsck &c) use "/lost+found/index.html" by name, or by inode?" He added, "As far as I know it always uses the same inode number (11), but I don't know if that is anywhere enforced." Andreas Dilger corrected the assumption, saying, "/lost+found just happens to use inode 11 on 99.9% of filesystems because it is the first inode available when mke2fs is creating the filesystem." He went on to explain:

It is perfectly acceptable to delete lost+found, and create it again with mklost+found, and chances are it will have a different inode... Just tested it, and sure enough, I got inode 612 for lost+found this time. I'm pretty sure that e2fsck looks for the name /lost+found, rather than inode 11.

This means that with stock e2fsck, mke2fs, mklost+found, you can't rename lost+found and expect anything to work. However, I would imagine it isn't _too_ hard to change these tools to create a different directory, and for e2fsck to look for the standard or the new directory to put nameless inodes.

Andreas rolled up his sleeves and dug into the e2fsck sources, finding only a single instance of the 'lost+found' string. mke2fs and mklost+found likewise had only a single occurrence.

Donghui Wen wanted to hack the 2.4 networking code for IPV4, and asked what he should read in order to understand the data structures and algorithms. David L. Nicol suggested just reading the source code, adding, "I like the a2ps tool for formatting source code for reading; I print out a sheaf of source code and retreat to a local coffee emporium with a highlighter and a legal pad." Daniel Chemko recommended, "Despite the fact that it is based on the 2.2 network core, the Coriolis book Linux IP Stacks was a good book of source code to scip to parts of the code which was related to my interests. It may be a little different now, with the iptables rework, but besides that, it is a good introduction to the implementation of the low level protcols."

Arnaldo Carvalho de Melo announced, "The kernel Janitor's TODO list is updated at http://bazar.conectiva.com.br/~acme/TODO, lots of things to do to get rid of old cruft, make sure that resources are properly used, etc, please take a look and help! Please send additions and corrections to me and I'll try to keep it updated."

Various folks suggested additions for the list, and Arnaldo ran right alongside, quickly adding everything to the page.

a new, 'ultra SMP scalable' implementation of Linux kernel timers is now available for download:

http://www.redhat.com/~mingo/scalable-timers/smptimers-2.4.0-B1

the patch is against 2.4.1-pre10 or ac12. The timer design in this implementation is a work of David Miller, Alexey Kuznetsov and myself.

The new implementation introduces per-CPU timer lists and per-CPU spinlocks that protect them. All timer operations, add_timer(), del_timer() and mod_timer() are still O(1) and cause no cacheline contention at all (because all data structures are separated). All existing semantics of Linux timers are preserved, so the patch is 'transparent' to all other subsystems.

The new timers still maintain 'semantical compatibility' with older concepts such as the IRQ lock and manipulation of TIMER_BH state. These constructs are quite rare already, in 2.5 they can be removed completely.

the patch has been sanity tested on UP-pure, UP-APIC, UP-IOAPIC and SMP systems. Reports/comments/questions/suggestions welcome!

Daniel Phillips had some problems with the code, and pointed out that the programmer interface "was designed primarly with one-shot timers in mind. Most timers events are multishot" [...] "so the API should be optimized for multishot and one-shot should be a special case of multishot." But Ingo replied, "for 2.4, the changing of the timer interface is out of question. My main goal was to achieve good SMP scalability with the existing interface."

Romain Kang noticed that, after the migration of the linux-kernel mailing list from vger.rutgers.edu to vger.kernel.org, it was impossible to sign up for a digest version. He offered to create his own and make it available to people. Parag Mehta liked the idea and offered to help out. Someone replied to Romain in private, saying that linux-kernel was available from egroups.com, but Romain replied to the list, "If you don't care for the advertising that comes with it, I've been informed there's a site that hopes to make a Mailman server publically available to carry linux-kernel as a digest also. They have to be prepared for 3000 digest users, since that's what vger.rutgers.edu used to carry. Watch the list for a public announcement." End of thread.

Yi Li announced XFS pre-release version 0.9, and gave a link to the announcement and to the project home page. Pedro M. Rodrigues asked how XFS would interact with the kernel nfsd feature, and Steve Lord from SGI replied, "You can NFS export XFS, I would have to say that this is not something we test regularly and you may find problems under high load." Pavel Machek also asked what support XFS provided for clustering, and Steve replied, "This statement is a little misleading, the clustering software is other stuff from SGI, they just have xfs filesystems on the machines. Now CXFS is another story, but it only exists for Irix now and it is almost certainly not going to be open source when it is available for Linux (and yes I know that makes packaging and support really interesting)."

David Riley reported tremendous slowdowns in 2.4.1-pre11 and -pre12 on his Athlon 900 with a KT133 chipset. Mark Hahn replied, "this is known: Linus decreed that, since two people reported disk corruption on VIA, any machine with a VIA southbridge must boot in stupid 1992 mode (PIO). (yes, it might be possible to boot with ide=autodma or something, but who would guess?)" He added to Linus Torvalds, "I hope you don't consider this a releasable state! VIA now owns 40% of the chipset market..." Linus replied:

So find somebody who can figure out why the corruption happens, and I'll be really happy with a patch that fixes it. In the meantime, "releaseable" very much means that we did _everything_ possible to make sure that people don't screw their disks over.

You have to realize that stability takes precedence over EVERYTHING.

After a bit of discussion it came out that David had been referring to a general slowdown of the entire machine, not just the disk. He summarized later, "My problem had nothing to do with disk access." [..] "The real culprit was ACPI, which is having some temporary problems. I turned it off and everything's great" Andrew Grover added, "ACPI driver is marked "developmental and/or incomplete" and will not be otherwise any time soon so it's broken-ness should IMO not hold up kernel releases." Elsewhere, under the Subject: ACPI broken in 2.4.1, Tony Hoyle and then Benson Chow reported seeing the same problem, and Alan Cox recommended, "Lots of people are seeing this. Stick to APM for now until the acpi folks fix it."

For more on the VIA disk situation, see Issue #103, Section #17 (12 Jan 2001: Unexplained 2.4.0 Filesystem Corruption) and Issue #104, Section #6 (12 Jan 2001: Temporary Filesystem Corruption Workarounds In 2.4) .

Miles Lane asked if the IBM encryption chip would need kernel support, or if it could be supported purely in user mode. Andre Hedrick remarked, "It looks like CPRM on the mainboard........." and Alan Cox replied:

Its certainly not a new idea. There are a wide number of trusted computing situations where high speed public key crypto that is very hard to go around the back of is a big win (think credit card data for one).

Its also uninteresting for real security applications because nobody will be prepared to assume that IBM silicon hasn't been tampered with by the NSA and friends.

to make the tracking of our bugs and feature requests easier I have opened a Bugzilla repository for the Linux-MM subsystem.

If you think you have new Linux MM bugs or want a new feature, feel free to enter something in the bugzilla.

The information page about this bugzilla can be found here:

http://www.linux.eu.org/Linux-MM/bugzilla.shtml

People wanting to see what's happening but don't want to look up the bugzilla page every day can subscribe to the linux-mm-bugs mailing list, where all bugzilla traffic will be sent.

To subscribe, send email to majordomo@nl.linux.org, with the text "subscribe linux-mm-bugs" in the body of the message.

If I did not misunderstood this news (Jan 15):

http://gcc.gnu.org/gcc-3.0/branch.html

http://gcc.gnu.org/ml/gcc/2001-01/msg00871.html

the gcc tree is feature-freezed to prepare 3.0. No more optimization algorithms, no more syntax-feature changes. Only bug fixes and compilation speed improvements.

So this is the gcc to feed kernel to, and check it for 3.0 release...

TUX 2.0 is now available for download at the following URL:

ftp://ftp.redhat.com/pub/redhat/tux/tux-2.0/

The TUX 2.0 release is an incremental upgrade to TUX 1.0 and keeps source-code level compatibility with user-space modules.

A number of incremental enhancements have been made:

True zero-copy disk reads: Whereas TUX 1.0 copied files into a temporary buffer, TUX 2.0 is integrated with the page cache and thus uses zero-copy block IO.
Generic zero-copy network writes: TUX 2.0 uses the generic zero-copy TCP framework.
Zero-copy parsing: Where possible, TUX parses input packets directly. Even in RAM-limited situations, TUX now does full, back-to-back zero-copy I/O.

Other changes include:

Enhanced user-space utilities and module support.
Mass virtual hosting support. The host-based virtual server patch has been added to TUX. There is no limit on the number of virtual hosts supported, only RAM and diskspace.
CGIs can be bound to particular CPUs or can be left unbound.
A number of bugs were fixed which caused performance problems - TUX 2.0 is now significantly faster than TUX 1.0!

Those interested in TUX usage or development are welcome, if they have not already done so, to join the TUX mailing list at:

tux-list@redhat.com

You can subscribe using the command:

echo subscribe | mail tux-list-request@redhat.com

Or you can use the web interface at

http://www.redhat.com/mailing-lists/

Walter Hofmann gave a link to some specweb results, that indicated a big improvement over Tux 1.0

Gregory Maxwell gave a link to Windows NT benchmarks, and asked, "Anyone know if their method of achieveing this is as flexible as TUX, or is their "SWC 3.0" simply mean 'spec web cheat' and involve implimenting the specweb dyanmic stuff in x86 assembly in their microkernel? :)" J Sloan replied, "One might say they cheated, both by using much faster disks and more of them, and "supercharging" their web server by putting a web cache in front of iis. Even so, they couldn't quite catch up to Tux." Paul Flinders gave a link to a similar benchmark with Tux running on Linux, pointing out, "Tux 2 is still faster on the same/similar hardware." Michael Poole replied soberly:

if you look closely, the Tux 2 system had an extra GigE card and 5 9GB 10KRPM drives instead of 1 9GB 10KRPM drive plus 8 16GB 15KRPM drives under IIS, so the hardware wasn't exactly the same for both.

Perhaps more telling is that in both cases the "Conforming Simultaneous Connections" was the same as the "Requested Connections" -- suggesting that neither TUX 2.0 nor IIS were pushed to the breaking point in the tests.

He posted a link to a similar benchmark with Zeus running under Linux, adding, "of course the normal disclaimers apply about how little benchmark results reflect what "average" commercial deployments see."

Someone reported being unable to boot their Sony Vaio c1ve under 2.4.1-ac1. He offered to try to find the most recent working kernel version, and Alan Cox said that would be great. Alan also asked how the machine did with vanilla 2.4.1; the original poster replied that yes, it did boot. Within moments, Alan had made a guess, confirmed it with the original poster and organized a fix; and Linus Torvalds explained, "The -ac patchset has the PCI bug re-introduced: in -ac the PCI probing will basically disable the northbridge while probing for it, thus killing the machine.."

Richard B. Johnson reported that messages to linux-kernel were being intercepted and answered by Meltingpot, a commercial organization. He couldn't explain how they could be intercepting the email, but Matthew Fredrickson speculated that someone subscribed linux-kernel to a Meltingpot mailing list.

David S. Miller also replied to Richard, saying he'd removed the Meltingpot address from linux-kernel. However, later, under the Subject: Ok, someone is trying to be funny, David reported:

Ok, it seems somebody is running a cron script or similar to keep resubscribing that meltingpot@miralink.com address to linux-kernel.

So if you see the "moderation" message back from a posting you make to linux-kernel, please dont' report it to us here at vger.kernel.org, we know about it.

Michael H. Warfield suggested, "So block them using the /etc/mail/access database for sendmail and do it with a "451" error code. The data will back up on their mail server and start clogging their mail spool till they get a clue. (Ok... 5 day expiration on the messages, but ITMT, they get several warning and error messages from each too)." David replied:

We don't use sendmail at vger, we use zmailer. Sendmail could not keep up with the load :-)

And yes I've done the zmailer equivalent (manual SPAM block database) of what you've suggested.

I asked David Hinds to write up an outline of the things that will be needed to get PCMCIA support cleanly and completely integrated into the kernel tree.

David has expressed that he'll not be able to participate in this work. He has his hands full with his day job and his role as maintainer/developer of the pcmcia-cs package.

To include 16-bit PCMCIA cards in the hot plug framework would require few driver changes; the only mandatory changes would be in how drivers register themselves and are hooked up with appropriate devices:

Make up pcmcia_device_id and pcmcia_driver types, and write new register/unregister calls to parallel PCI and USB drivers. This would eventually take over for the "ds" module and cardmgr.
Rewrite all PCMCIA client drivers to have MODULE_DEVICE_TABLE entries and use the new driver services. This can all be done incrementally, with ds/cardmgr handling old-style drivers.
The CIS override functionality in the PCMCIA package is unpleasant to support in a completely in-kernel framework.

Missing functionality in the hot plug framework:

Only new network devices generate /sbin/hotplug events now. Modify all other device types to also do so: the ones currently handled by PCMCIA include serial, parallel, SCSI (all types), and IDE.
There is no mechanism to request a card eject in the new framework. This is required for clean shutdown of SCSI and IDE adapters.
The PCMCIA device configuration scripts have a lot of capabilities that the hotplug scripts do not have yet. At the moment, the extent of device-specific hotplug configuration is running "ifup".

Missing functionality in the 2.4 PCMCIA drivers:

The yenta driver can't handle CardBus adapter cards for desktop systems. Many require explicit overrides for the default interrupt delivery settings, and a few require other special bridge settings.
The i82365 driver can't handle (non-CardBus) PCI-to-PCMCIA bridges any more. Some of the PCI code in the old i82365 driver needs to be put back.

Jeff Garzik volunteered to convert all the network drivers, once folks had agreed on the design. Miles said:

As we look into developing PCMCIA support in the 2.4/2.5 kernel trees, in addition to reading the pcmcia-cs code to learn about problems with specific devices that need to be handled, David Hinds also a reference page that lists some a bunch of issues that are in varying degrees of resolution:

http://pcmcia-cs.sourceforge.net/ftp/BUGS

This may be a useful resource. I'll see whether David has time to update this page with a bit more detailed explanations of the problems. Some of the items are pretty vague. For example,

the Asix AX88190 chipset, which has several serious bugs and incompatibilities that render the regular pcnet_cs driver unusable

It would be nice to know exactly what those bugs and incompatibilities are. :-)

For more on the situation of NTFS, see Issue #105, Section #8 (24 Jan 2001: NTFS: The Saga Continues) . This week, Anton Altaparmakov announced:

This is to announce the first public release of the Linux-NTFS project hosted on sourceforge. The project page, where you can download the source code tar ball or rpm as well as precompiled RPMs for RedHat Linux 7.0 (i386 architecture only), is:

http://sourceforge.net/projects/linux-ntfs/

You can also use the CVS server if you prefer... Note, that you need the kernel headers installed to compile linux-ntfs source (probably you will need 2.4.x kernel headers and not 2.2.x ones but I haven't actually checked whether it works with 2.2.x or not).

The first release contains the all new and wonderful ntfsfix utility, which repairs some of the damage that the current Linux NTFS driver does when writing to an NTFS partition.

If you are doing any writing to NTFS partitions using the Linux NTFS driver this is an absolute *MUST* at the present time. It won't solve all problems, but it goes quite some way to prevent data corruption.

Run it after dismounting your NTFS partition in Linux but before rebooting into Windows NT/2000.

Note, after running the utility, when Windows boots up it will run an automatic chkdsk on the partition which will finish fixing the damage done by the Linux NTFS driver without corrupting the written data or any other data (as long as the Linux NTFS driver hasn't corrupted something beyond repair, obviously).

For amusement value, the first release also includes the ntfsdump_logfile utility which when used on an NTFS partition will display information about the journal ($LogFile) of that partition.

Finally both these utilities make use of the also included NTFS library which offer NTFS access to open source programs. It is currently under heavy development and the API is not going to remain as it is so don't use it yet for your own programs.

For everyone interested in NTFS on-disk structures and functionality, you will find the doc directory and especially the include directory to be of great interest as the later includes header files with all known to me NTFS structures. I still haven't gone through all the NTFS information that is available so they are considered work in progress but are fairly complete I thing. Most people will probably find that the $LogFile structures have never been published before anywhere and now we have the restart area structure definitions.

Any problems compiling/running the utilities, just give me a shout, or even better submit bug reports on the project page!

Various people burst into spontaneous song, among them Jeff V. Merkey, who added:

To date, I have provided tools to 7,000+ folks who use this driver that trash their NTFS partitions. TRG will discontinue distribution of these tools at this point since Anton has a Linux based version.

Please do not email me for any more NT based repair tools for damaged NTFS partitions trashed by Linux. Please contact Anton and use his tools instead. I will inform Microsoft I will no longer be providing these tools since Anton now has something that will do the job.

Microsoft would be much happier I am certain with a pure Linux solution for this problem. They have been incredibly tolerant in allowing me to help customers with trashed drives, but I am sure you are aware that they were only tolerating it since it was helping customers who use both NT and Linux, and even this was quite a stretch they did not have to go. It's a statement that even in those cases where tey may be helping Linux, they put their customers needs first (this took some convincing on my part).

They are very angry at me right now for even doing this in the first place, and I doubt the relationship will ever be back on the keel it was originally, but since I work on Linux almost exslusively now, I do not think it matters.


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	24 Jan 2001 - 31 Jan 2001	(27 posts)	Some Explanation Of The 'zerocopy' Patches
2.	24 Jan 2001 - 29 Jan 2001	(10 posts)	Sending Patches By Email
3.	25 Jan 2001 - 31 Jan 2001	(3 posts)	Synchronous Serial Card Support In 2.2 But Not 2.4
4.	25 Jan 2001 - 30 Jan 2001	(22 posts)	eepro100 Problems In 2.4.0
5.	25 Jan 2001 - 30 Jan 2001	(8 posts)	Problems With The Maestro Driver
6.	26 Jan 2001 - 31 Jan 2001	(24 posts)	Renaming lost+found
7.	26 Jan 2001 - 30 Jan 2001	(3 posts)	Understanding Linux Networking Code
8.	27 Jan 2001 - 31 Jan 2001	(39 posts)	Kernel Janitor's TODO List
9.	28 Jan 2001 - 31 Jan 2001	(3 posts)	New 2.4 Timer Implementation
10.	28 Jan 2001 - 29 Jan 2001	(3 posts)	linux-kernel Mailing List Digest
11.	29 Jan 2001 - 1 Feb 2001	(6 posts)	XFS Pre-Release Version 0.9 Available
12.	29 Jan 2001 - 4 Feb 2001	(11 posts)	General Priorities For 2.4; ACPI Unstable In 2.4
13.	30 Jan 2001 - 31 Jan 2001	(3 posts)	Support For IBM Encryption Chip
14.	31 Jan 2001 - 2 Feb 2001	(4 posts)	Linux-MM Subsystem Uses Bugzilla
15.	31 Jan 2001	(1 post)	Preparing For gcc 3.0
16.	31 Jan 2001 - 1 Feb 2001	(2 posts)	Tux 2.0 Announced
17.	1 Feb 2001 - 2 Feb 2001	(6 posts)	Benchmarks Comparing NT With Tux and Zeus
18.	2 Feb 2001 - 3 Feb 2001	(7 posts)	Vaio Problems In -ac Patches
19.	2 Feb 2001	(7 posts)	Hostile Activity Against The linux-kernel Mailing List
20.	2 Feb 2001 - 4 Feb 2001	(5 posts)	Status Of PCMCIA
21.	3 Feb 2001	(11 posts)	Linux NTFS Project Announced

Kernel Traffic #106 For 9 Feb 2001

By Zack Brown