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

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.

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.

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!

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.

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/

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.

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.

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.

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. :-)

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!

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.