Kernel Traffic #72 For 19 Jun 2000

There were 479 different contributors. 213 posted more than once. 136 posted last week too.

Tugrul Galatali had been having good success with ext3 on recent stable kernels. However, he'd had a problem with ext3 0.0.2d on kernel 2.2.15. After installing ext3 and rebooting, any attempt to 'umount' the ext3 filesystems would hang the machine. This was on a 20GB WD205AA. He explained, "The thing that these problematic file systems have in common are that they are not the first partition in an extended partition. (There are other similarities, like they all extend/exist beyond 512 cylinders, but I have other machines where that doesn't seem to affect anything.)" He offered to provide any data folks needed to help debug the problem. There was not much discussion, but in the course of it, Stephen C. Tweedie (the 'ext3' author) said, "I'm putting together ext3-0.0.2e which addresses a couple of possible problems. The main one is that it was possible for a stray timer to be left after an ext3 unmount if there was a commit pending when the umount request came in." He also posted a patch for Tugrul to try, but there was no reply.

Alan Cox gave a URL and announced 2.4.0-test1-ac7 (against 2.4.0-test1). He explained, "The ac5/ac6/ac7 patches are really aimed mostly at folks actually fixing drivers and in paticular hacking on the vm and buffer cache races. There are things like broken and non fixed adaptec 29xx driver code and a suspected memory leak to deal with," and quoted the CHANGELOG:

2.4.0-test1-ac7

Fix the IDE damage done in ac6 (me, Jens Axboe)
Update the docbook on kernel locking (Rusty)
Port ymf7xx driver to the 2.4.0test tree (Jeff Garzik)
Bring capabilities more into line with Posix (Andrew Morgan)
Netfilter site has moved, Rusty has moved (Rusty)
-D__SMP__ and config.in cleanups (Niels Jensen)
Put the ENOTTY on failed fasync fix into 2.3 (Rusty)
IDE driver update This may break PIIX3 USB, if so can Andre and the USB folks figure it out between them (Andre Hedrick)
Further VM tuning (Rik van Riel)
8139 driver updates (Jeff Garzik)
List ALi in the docs/config for trident (Ching Ling Lee)
Add key bindings to Make xconfig (Kip Macy)
Do elevator accounting before queueing the I/O DAC960 probably works happily now (Leonard Zubkoff)
Stop open() on sockets (Chris Wedgewood)
Assorted minor cleanups (Statics etc) (Philipp Rumpf)

Nils Rennebarth reported a kernel panic with heavy network traffic, but there was no reply. Christoph Rohland reported that item 9 (Rik van Riel's VM tuning) would apparently kill random processes when stress-tested. Rik replied, "Hmm, I'll look into this. This is especially strange since I didn't touch the shm code." There was no reply.

H. Peter Anvin asked about item 14 ("Stop open() on sockets"), "I'm confused about this one. I always thought supporting open() on Unix domain sockets would be a great idea -- there is a number of things that you can do elegantly that way which you otherwise wouldn't be able to do. What is wrong with it?" Chris Wedgwood explained, "It's non-portable and the locking code exploded on such FDs at present. I would suggest we leave the fix I present as is until 2.5.x and then consider putting in non-portable semantics with a proper fix in the posix locking code."

Meelis Roos reported that his Tulip card had been broken since ac6, since Jeff Garzik's Tulip driver updates. Jeff posted a patch for ac8, and Meelis reported success with it.

Lee Chin asked if Linux on an Alpha could use 32-bit devices such as eepro100 cards. Jeff Garzik replied that the device itself would almost certainly be recognized, although there might not be a Linux driver for it. Torben Mathiasen gave a similar reply to Lee, saying that the driver might not be aware of 64-bit architectures. Markus Pfeiffer then asked specifically if the 8139 driver supported Alpha, and David S. Miller replied, "It should, it works on UltraSparc last time I played with the card I have." And Torben Mathiasen said to Markus, "Yes the 8139too.c driver does. Take a look at Documentation/networking/8139too.txt."

Elsewhere, Lyle Coder asked, "Have you actually tried eepro100 on Alpha? Because I am trying to get eepro100 to work on my IA64 platform and it fails because in speedo_start_xmit gets an skb that is at > 4Gb... and the card is only 32 bit, so it fails to send!" Jes Sorensen replied, "The question here is more whether the ia64 kernel actually supports > 1GB of memory, I am not 100% sure. The eepro100 worked just dandy in the ia64 last time I tried."

George Sexton was getting daily lockups on both of his PII SMP machines running 2.2.16pre7. The machines were much more stable with 2.2.14, going between 14 and 70 days without a crash. He listed his hardware:

German Jose Gomez Garcia confirmed the problem on his own hardware with dual PII and Adaptec ACI7890 onboard SCSI controller. He added, "The only strange thing is that usually the framebuffer gets a bit corrupted (the last line of text on current VC is someway pixel-remixed)." He identified the last non-crashing kernel as 2.2.16pre2. Everything since then would crash after half a day of lightly loaded uptime.

Marcelo Tosatti recommended, "You can try the NMI oopser to possibly get a clue about the crash. http://people.redhat.com/mingo/NMI-watchdog-patches/NMI-oopser-2.2.15-A0. Documentation on how to use it is included in the patch." George couldn't get NMI to work, and posted his '.config' file and 'dmesg' output. Toni Mattila looked over the output, and said, "I see you are running also aic7xxx+eepro100 combo with SOYO SMP MB.. I had constant crashes with 2.2.14 every 3-6 days. Changed to 2.2.16pre7 the box didn't hold even 24 hours. Now when I replaced eepro100 with 3com's 3c59x the box been holding already 2 days. What's common is that there was never oopses or anything, box just hung hard. (serial console). And SysRq didn't have any effect." And Zdenek Kabelac recommended that George try recompiling with 'gcc' 2.95.XX.

There needs to be a shutdown hook that would allow me to enable write-caching enabled in ATA. I need the shutdown hook to turn off caching to flush it before unmount devices.

Regardless of my need for this, it would be useful for all devices. This would remove the need of special scripts to do any special device cleanups before shutdown/reboot......

Alan Cox replied, "The kernel flushes all its blocks, and you get told your block device is being closed so you can act then. You can also hook the reboot notifier for final reboot stuff," but Andre objected:

I am not talking about the kernel buffers. I am referring to the buffer cache on the disks. There will be a need to flush/force write completion of data to the disk before power down if I enable the intelligent write-caching in the hardware.

Do if something exists, what do I need look for or hook to issue flush cache during a halt/reboot event?

To Andre's second paragraph, Alan suggested starting with the DAC960 driver. And to Andre's first paragraph, Alan replied, "If you do this then you won't be able to use IDE for journalling fs's. Before we can do cachable re-ordered writes on the device itself we have to implement store barrier points in the disk request queues so that the kernel can stop the drive re-ordering when it is not safe too" , to which Stephen C. Tweedie added (ending the thread):

Ditto for any applications which rely on write ordering, such as sendmail on a sync mail spool, or any database with log recovery.

Lying to the CPU about when the data is safe on disk is a bad thing to do, in general.

Andrea Arcangeli announced classzone 31, the only patch so far that has been able to solve the recent VM problems in the unstable series (kswapd using up 100% of the CPU, etc), but which many folks accuse of incorrect design. Rik van Riel posed:

In the process of writing the new VM code I've been looking through your patch for some ideas and I have some questions.

could you explain your shrink_mmap changes? why do they work?
why are you backing out bugfixes made by Linus and other people? what does your patch gain by that? (eg the do_try_to_free_pages stuff)

To question 1, Andrea offered a technical explanation, adding, "this shrink_mmap design changes have nothing to do with the classzone part of the patch but it happened that I developed it in parallel while working on the classzone stuff and I didn't had the time to split the orthogonal parts of the classzone patch in separate patches yet." To question 2, Andrea explained, "I backed out everything that looked not correct (even if only in a corner case and not in the common case) or that looked not worty enough."

Kenneth C. Arnold posted the latest version of his list of things to do during 2.5. The characters at the left are "N" for needed, "I" for important, and "W" for wishlist. Kenneth listed:

Drivers

Marcelo Tosatti <marcelo@conectiva.com.br>:
(I) Modularization of UDMA IDE drivers

James Simmons:
Finish cleaning up the fbdev layer with a new api
+ Support cards with multiple frame buffers
Incorporate Vojtechs input layer.
Add real multihead support to the console system.

fs

(W) Merge ext3
(W) Merge ReiserFS
(N) VFS changes

David Weinehall <tao@acc.umu.se>:
(W) HFS+

Architecture

API

Features

Warren Young <tangent@cyberport.com>:
(I) async io

Improvements

Uncategorized:

H. Peter Anvin <hpa@zytor.com>:
("N!!!") dev_t resizing

(N) Documentation

Jan Evert van Grootheest <janevert@iae.nl>:
(W) Kernel nanosecond timer support

(I) Get rid of SCSI host template
(I) Handle replugging

Rik van Riel:
Threaded dcache
Better VM (http://www.linux.eu.org/Linux-MM/)
fair scheduler (http://www.surriel.com/patches)
(better) support for NUMA machines

Add support to allocate very large chunks of continous memory after boot time.

Reorganize console code
Migrate input devices to new API

Ben Greear:
802.1Q VLAN patch

Lennert Buytenhek <buytenh@gnu.org>:
The VLAN project at http://vlan.sourceforge.net (noted)

Jeff V. Merkey: <jmerkey@timpanogas.com>
Logical block semantic for buffer cache
Support mirrored writes in page cache
Enable writes to concurrent devices in single commit_write()
Replace NWFS LRU code with Linux buffer cache
WorkToDo optimization for page cache/network layer
Merge NWFS

David Weinehall <tao@acc.umu.se>:

(W) ALSA
(international)
(N) IPsec
(N) International Kernel-patches

Andrew Morton <andrewm@uow.edu.au>:
Kernel timer review
Removal of struct timer_struct
Cleanup of legacy ISA net devices
Userland interface for failover notification
Sub-one-second target
(W) Update net device initialization
(W) Get rid of space.c
(W) Maintain net drivers from ftp://sourceforge.org/pcmcia/contrib/

Peter Chubb <peterc@aurema.com>:
(N) Make setrlimit() work for RLIMIT_RSS
(N) Make getrusage() and wait4() work for more resources than just CPU

Bill Wendling <wendling@ganymede.isdn.uiuc.edu>:
(N/W) O_DSYNC, O_RSYNC for POSIX compliance

David Woodhouse <dwmw2@infradead.org>:
Merge flash & other memory device drivers
(www.linux-mtd.infradead.org)
FFS2 and JFFS flash filing systems
PC speaker driver
Kill sleep_on() et al.
lm_sensors
uCLinux
User Mode Linux
iBCS/ABI stuff
loopback crypto
secure RPC
v4l2 (?)

Arne Thomassen <arneth@Pool.Informatik.RWTH-Aachen.DE>:
(W) Replace kernel lock with fine-grain locks [probably not]

Randy Dunlap <randy.dunlap@intel.com>:
({I,N}) V4L drivers to return BGR data and not do other various data conversions {affects lots of apps} [questionable]

Marcelo Tosatti <marcelo@conectiva.com.br>
(N) finish and merge userbeans (also write userlevel PAM code)

Kenneth replied to himself sometime later with a clarification, "Note: Names as listed are of those who suggested the item, and thus the people who you should contact if you have any question of interpretation. They are not necessarily responsible for completing the task. However, if you *are* working on something suggested here, please "claim" it. I will mark any claimed items as such." James Simmons replied, saying he claimed his section.

Chris Evans suggested that the revoke() system call should be added to the "N" category. Tigran Aivazian commented, "actually, revoke(2) syscall should come almost for free as a side-effect of some work I did to support forced umount. I know, I know - it should have materilized in the form of patch by now, but I have some other urgent work to complete before end of July - so forced umount will be ready "Real Soon Now(tm)" :)"

Eric S. Raymond suggested adding "Manage transition to CML2" to the "I" category. Werner Almesberger had two suggested additions for the "I" category: "Free initrd pages during copy to reduce peak memory usage" and "bootimg (boot Linux kernels from Linux to offload work from boot loader)". Jamie Lokier suggested for the "W" category, adding, "Return dirent->d_type information (patch available)"

Alan Cox also had some additions to suggest. In the "W" category, he suggested "merge XFS" and "merge NWFS". Without naming a category, he also suggested "Support for processors with 4 level page tables", "Support for page table discard (ala NetBSD) for non anonymous pages", "Fine grain locking on the serial layer", "64bit file locking", and possibly "ext2 acls" and "file system level capability data".

There was not much discussion about any of the items, either the ones already on the todo list or those suggested for addition. But with Alan and other big time hackers participating in the discussion, it seems like the idea of a 2.5/2.6 To Do list at this stage of the game has definitely been legitimized.

Eric S. Raymond was composing a list of configuration-file maintainers. He asked for additions and changes to what he had so far:

fs/Config.in
fs/ncpfs/Config.in
fs/nls/Config.in
fs/partitions/Config.in

Theodore Y. Ts'o <tytso@rt-11>
Last entry in fs/Changelog
net/ax25/Config.in
Matthias Welwarsky <dg2fef@afthd.tu-darmstadt.de>
MAINTAINERS file
net/Config.in
??
net/decnet/Config.in
Steven Whitehouse <SteveW@ACM.org>
MAINTAINERS file
net/ipv4/Config.in
net/ipv4/netfilter/Config.in
net/ipv6/Config.in
net/ipv6/netfilter/Config.in
net/sched/Config.in
??
net/ipx/Config.in
Jay Schulist <jschlst@turbolinux.com>
MAINTAINERS file
net/irda/Config.in
net/irda/compressors/Config.in
net/irda/ircomm/Config.in
net/irda/irlan/Config.in
drivers/net/irda/Config.in
Dag Brattli <dagb@cs.uit.no>
MAINTAINERS file
net/khttpd/Config.in
Arjan van de Ven <khttpd@fenrus.demon.nl>
net/khttpd/README
drivers/net/Config.in
??
drivers/net/wan/Config.in
Jaspreet Singh <jaspreet@sangoma>
gene@compuserve.com,
dm@sangoma.com
net/README, MAINTAINERS
drivers/net/tokenring/Config.in
drivers/sound/Config.in
drivers/sound/dmasound/Config.in
drivers/video/Config.in
drivers/i2o/Config.in
Alan Cox <alan@lxorguk.ukuu.org.uk>
net/README, MAINTAINERS, drivers/i2o/README
drivers/net/hamradio/Config.in
Joerg Reuter DL1BKE <jreuter@poboxes.com>
drivers/net/hamradio/Makefile
drivers/net/arcnet/Config.in
??
drivers/net/pcmcia/Config.in
drivers/char/pcmcia/Config.in
drivers/scsi/pcmcia/Config.in
drivers/pcmcia/Config.in
David Hinds <dhinds@zen.stanford.edu>
MAINTAINERS file
drivers/net/appletalk/Config.in
Jay Schulist <jschlst@turbolinux.com>
net/README
drivers/block/Config.in
??
drivers/block/paride/Config.in
Grant R. Guenther <grant@torque.net>
MAINTAINERS file
drivers/char/Config.in
Theodore Ts'o <tytso@rsts-11.mit.edu>
drivers/char/ChangeLog comments
drivers/char/ftape/Config.in
Claus-Justus Heine <claus@momo.math.rwth-aachen.de>
MAINTAINERS file
drivers/char/joystick/Config.in
Vojtech Pavlik <vojtech@suse.cz>
MAINTAINERS file
drivers/scsi/Config.in
linux-scsi@vger.rutgers.edu
MAINTAINERS file
drivers/pci/Config.in
Martin Mares <mj@suse.cz>
MAINTAINERS file
drivers/cdrom/Config.in
Eberhard Moenkeberg <emoenke@gwdg.de>
MAINTAINERS file
drivers/isdn/Config.in
Fritz Elfert <fritz@isdn4linux.de>
isdn4linux@listserv.isdn4linux.de
MAINTAINERS file
drivers/sbus/char/Config.in
drivers/sbus/audio/Config.in
David S. Miller <davem@redhat.com>
Comments in the directory
drivers/ide/Config.in
Andre Hedrick <andre@linux-ide.org>
MAINTAINERS file
drivers/pnp/Config.in
Tom Lees <tom@lpsg.demon.co.uk>
MAINTAINERS file
drivers/misc/Config.in
No maintainer -- the directory is empty!
drivers/sgi/Config.in
??
drivers/fc4/Config.in
Jakub Jelinek <jj@sunsite.mff.cuni.cz>
Comments in the directory
drivers/acorn/scsi/Config.in
drivers/acorn/block/Config.in
drivers/acorn/net/Config.in
arch/arm/config.in
Russell King <linux@arm.linux.org.uk>
MAINTAINERS file
drivers/usb/Config.in
Randy Dunlap <randy.dunlap@intel.com>
MAINTAINERS file
drivers/atm/Config.in
??
drivers/parport/Config.in
Phil Blundell <Philip.Blundell@pobox.com>
Tim Waugh <tim@cyberelk.demon.co.uk>
David Campbell <campbell@torque.net>
Andrea Arcangeli <andrea@e-mind.com>
MAINTAINERS file
drivers/i2c/Config.in
Simon Vogl <simon@tk.uni-linz.ac.at>
MAINTAINERS file
drivers/telephony/Config.in
Ed Okerson, <eokerson@quicknet.net>
Alan Cox, <alan@redhat.com>
Comments in the directory
drivers/ieee1394/Config.in
Andreas Bombe <andreas.bombe@munich.netsurf.de>
MAINTAINERS file
drivers/s390/Config.in
arch/s390/config.in
??
arch/i386/config.in
Linus Torvalds <torvalds@transmeta.com>
Just a wild guess...
arch/alpha/config.in
David A. Rusling <david.rusling@reo.mts.dec.com>
Comments in the alpha port directory
arch/sparc/config.in
arch/sparc64/config.in
David S. Miller <davem@redhat.com>
MAINTAINERS file
arch/mips/config.in
arch/mips64/config.in
Ralf Baechle <ralf@gnu.ai.mit.edu>
MAINTAINERS file
arch/ppc/config.in
arch/ppc/8xx_io/Config.in
arch/ppc/8260_io/Config.in
Cort Dougan <cort@fsmlabs.com>
CREDITS file
arch/m68k/config.in
Hamish Macdonald <hamishm@lucent.com>
CREDITS file
arch/sh/config.in
??
arch/ia64/config.in
Walt Drummond <drummond@valinux.com>
CREDITS file

Jeff Garzik replied, "There are no configuration file maintainers generally. For major subsystems, like drivers/char or drivers/net, it is -incorrect- to say that there is a maintainer at all. For specific subsystems, like ISDN or FireWire, the maintainers for those subsystems are the ones who typically update the Config.in file, but that is not a rule. Andrezj (sp?) in particular has been going through the Config.in files and cleaning up a lot of cruft." Eric replied:

OK, but knowing who considers themselves responsible for the associated subsystem is what I need (and a couple of people have in fact emailed me saying "that Config.in is mine").

What I'm trying to do is identify the people with the biggest stake in CML1 (and, correspondingly, the most to gain from scrapping it). I need to know who they are because I need a victory condition -- I need to engineer not just code but a visible consensus.

That is, to get CML2 adopted, I think I need to be able to go to Linus and say something like "30 of the 40 maintainers have signed off on the CML2 idea and the accuracy of their pieces of the CML1->CML2 translation".

If there's a group of major stakeholders I don't know about, please do tell me.

Jeff Garzik recommended, "Over and above the people who e-mail you, a good method is to look at the naming of each drivers/* subdirectory, and see if you can match up a name with an entry in MAINTAINERS. For example ISDN matches up with drivers/isdn/Config.in, while drivers/net/Config.in and drivers/char/Config.in do not have MAINTAINER entries. No hard and fast rule for this sort of thing.." Eric replied that he'd tried this first, and put the results in his initial post. There was no reply.

Andre Hedrick gave a pointer to his Linux ATA Development page, and quoted the entire Quantum Corporation press release about its new Ultra DMA 100. In the course of discussion, it came out that he'd specifically wanted to make sure that the driver would be ready as soon as the announcement came out, so Linux would support the drive before Microsoft. At one point he said, "I busted my ass all night to shake things down to be ready for the announcement......do you think it was an accident that I had a patch sitting around waiting for the press release?"

The first thing approaching an official announcement of a 2.4 code freeze appeared during a 'reiserfs' debate. The last I heard, Linus had officially proclaimed a feature freeze back in September, under the Subject: Linux-2.3.18... and a freeze (covered in Kernel Traffic Issue #35, Section #24 (10 Sep 1999: Linus Announces A Feature Freeze) ). That was the last official word. This week in the midst of saying other stuff, Alan Cox happened to mention, "We are in the 2.4 code freeze." Lacking word from Linus, this is about as good an indication as we can hope for.

So, it's official. As of June 5, Kernel development is in a code freeze for 2.4.0

Chris Lattner suggested enhancing CML2 to remove the need for 'make dep; make clean' to ensure consistency. Eric S. Raymond replied:

It would be technically possible. I don't want to do it -- or, at least, I don't want to do it yet. Here is why:

Right now, CML2 is focused on a single, well-defined problem for which the nature of a correct solution is clear. I want to solve that problem first without getting tangled up in larger, vaguer issues.
I suspect the problem you're talking about is best solved not with CML2 itself but with separate, custom-built script-language machinery operating on a configuration file produced by CML2.

Once we have a clean solution to the problem of generating and editing config files, then (and only then) I'll be willing to think about reforming other parts of the build system.

At that point, however, assuming CML2 is adopted, I'll be *very* willing. Configuration management challenges are in the class of problems I both understand and enjoy solving. I will get us good results there.

Chris understood Eric's reluctance, but admonished, "keep in mind areas that may need extension... so that there are no fundemental limitations that cause problems in the future. :)"

Keith Owens replied to Chris' initial post, explaining, "I will be rewriting the entire Makefile system for 2.5 and the removal of make dep/clean is one of my goals. The functionality is still needed but I want to make it automatic, i.e. have the rules decide it is needed instead of relying on the user." Chris and Eric were both thrilled, but Alan Cox replied, "The user often knows things the system doesnt. At the moment it should be automatic but doesnt quite work out for some module related symbolver stuff." Chris asked for more information, but the thread ended there.

In the course of discussion, Hans Reiser (main author of 'reiserfs') said, "I want to add reiserfs to linux, not merge it into ext3. This is the crux of the argument. Alan says I should wait until ext3 is added so that I can let them write part of our FS for us." Bert replied:

Part of being part of the kernel is cooperation. It's not just the code, which by what I hear, is excellent.

If reiserfs is to be included, you will from now on have to cooperate very closely with the kernel people. This is, I believe, a major point. If there are doubts as to if you are willing to play ball, I would consider keeping reiserfs separate.

You may be aware of the Donald Becker 'situation', who writes very beneficial code, but still ran into disagreements with others.

Rephrasing your version of what Alan said 'Alan said I should wait until ext3 is added so that we can *share common code*'. You are also right, however, in stating that perhaps we need a reiser-like FS now, instead of waiting for the Nirvana of complete code reuse.

Being part of the kernel is a lot like marrying, or going on a holliday in a cramped tent.

I believe Reiser, or NameSys, can be a very good partner in this. You appear to be a rather solid organisation, with true commitment to quality control and maintenance. You have also succeded in attracting capable personnel, which is hard enough these days.

It would be sad to waste this opportunity, for a merged reiserfs is a better fs. I wish you good luck in cooperating with everybody here, and getting your filesystem in the kernel.

The 'reiserfs' situation has an interesting parallel to 'devfs', in which Richard Gooch found that inclusion of 'devfs' in the kernel meant radical changes to the design, goals, and developmental processes of 'his' code. For more on the effects of that, see Issue #64, Section #1 (4 Apr 2000: Linus On devfs) and Issue #67, Section #7 (30 Apr 2000: 'devfs' Change Breaks Current Systems But Mollifies Detractors) .

Back to the present. Hans complimented Bert on the quality of his response, and replied in turn, "I would love to work towards defining a set of journaling related VFS operations in 2.5, and using them, and rewriting reiserfs in 2.5 to use them where they differ from what we have now. I would not like to have that be an excuse for our exclusion until that is done. I am a pretty simple guy." Stephen C. Tweedie (main author of 'ext3') replied to Hans:

Chris and I have *already been doing this*. That's one of the reasons I can't understand your attitude. We have a pretty good idea now of the underlying VM interactions which a journaling filesystem introduces, thanks to the fact that the core developers involved have an extremely good working relationship.

At issue is the timetable for integrating such significant VM interactions into the main kernel. The 2.4 is in codefreeze. There's no preferring ext3 over reiserfs involved: this is a significant new VM effect we're talking about, whichever filesystem is to use it (and hopefully all concerned filesystems can use the same hooks, as we've talked with some of the XFS people too about this.)

Hans objected, "There is no need to delay reiserfs integration into 2.4 to accomplish a journaling API in 2.5." And Stephen replied:

It wasn't a journaling API we were talking about for this. The problem is much more central to the VM than that --- basically, the VM currently assumes that any existing page can be evicted from memory with very little extra work. It just isn't prepared for the situation that you have with transactions, where you can't flush any of the existing dirty data to disk without first waiting for the transaction to proceed to a consistent, checkpointable state.

We've had a lot of trouble in the past even just with ext2 creating too many dirty buffers. That gets a lot worse if you have multiple transactional filesystems in memory. It's not the journaling itself, but the transactional requirements which are the problem --- basically the VM cannot do _anything_ about individual pages which are pinned by a transaction, but rather we need a way to trigger a filesystem flush, AND to prevent more dirtying of pages by the filesystem (these are two distinct problems), or we just lock up under load on lower memory boxes.

A reservation API which lets all transactional filesystems reserve the right to dirty a certain number of pages in advance of actually needing them is really needed to avoid such lockups. The reservation call can stall if the memory limit has been reached, providing flow control to the filesystem; and a notification list can start committing and flushing older transactions when that happens.

Once Hans was convinced that there was actually significant work to be done; he, Stephen, Rik van Riel, and others proceeded to have a fairly sizable and friendly implementation discussion.

Andre Hedrick said, "I am try to work with a hardware company, that supplies chips, to force and pressure this manufacturer into complying to GPL first. Please follow my lead, because I do not want to run over anyone here while I go for their throats!" He went on:

My replys to there BBS on the WEB?

http://www.gentus.com/ubb/Forum1/HTML/000267.html
http://www.gentus.com/ubb/Forum1/HTML/000371.html
http://www.gentus.com/ubb/Forum1/HTML/000380.html

My second discovery of all kinds of new tricks with binaries with out source. This first happened with Gentus 1.0 and now it returns with Gentus 2.0.

I am going to make a case that proves this distribution does nothing but give use the middle finger and disregards the nature of GPL.

http://www.gentus.com/about_linux.html

Here is their statement, but their actions have never matched.

I suggest that all Maintainers of various portions of the kernel investigate this Violation of your work, also.

I would hope that RedHat would choose to take some legal actions given the gross usage of your distribution. This does not include the comparison between Gentus 2.0 (6.2) and RedHat 6.2.

http://www.gentus.com/press.html

The short version of this is translated:

RedHat you Suck, and we fixed your failures, nana nana nu nu!

This really pisses me off in the worst way.....

Dr. Kelsey Hudson looked the situation over and was appalled. He concluded, "I _STRONGLY_ suggest that RedHat take action..."

This sort of situation is best handled with a level head. You must separate the GPL violation from anything else they do to annoy you.

Get a copy of their CD and document that accurate source of GPL-derived code is not available, on a file-by-file basis, showing evidence that the code was modified and that the modifications are not available in source form. Make it available to others so that they can confirm your findings. Then, and only then, can can this be pursued with ABIT and anyone else who distributes the CD.

I don't care much about anything they happen to say about Red Hat. I doubt Red Hat cares much either. Likewise for what they write about Linux. All I'd like to hear is how compiled code doesn't match available source.

You might find that emotionally difficult, but I can assure you that it is the only way to be effective in enforcing GPL violations.

Andre replied, "Gurrr...... Your are right," and said he'd follow Bruce's advice of getting ABIT's CD etc.

Gerhard Mack, also in reply to Andre's initial post, pointed out that in the last BBS post, Gentus seemed to be saying that the source for their kernel was available. He added, "If so, they wre blindingly stupid but didn't violate the GPL." Andre explained:

Only if you can build a kernel that is identical to the one you are booting, but you can not........

In Gentus 1.0 the LM7x serires drivers that are GPL were binaries and no source to be found.

The rules are simple, you may not ship a kernel with binary objects linked without the source code available. There is no variation that can be granted by anyone except Linus.

Simply stating, one can not create a kernel with the source code returned that is identical to the one shipped for booting.

This is by definition a clear violation of GPL......if I am wrong I want to be corrected. Note that there are parts of the kernel that are non-GPL but BSD-like, you can only use this as a module. Linking it to kernel is not allowed.

James Sutherland replied to several of these points. He pointed out that if ABIT was redistributing code without modifying it, then that wouldn't be a violation of the GPL because the code was available elsewhere. But Andre gave a pointer to http://www.gentus.com/ubb/Forum1/HTML/000385.html and replied, "Read what the folks that are trying to use "AbitPerMon" that is based on a modified "kernel module" known as lm_sensors....."

James had also asked what was missing from the source tree Gentus supplied, and Andre said, "I am still hunting.............but the compact raid code is hacked also. With a patch that is compressed bz2 to 192K against 2.2.13........"

James had also replied to Andre's statement that "you may not ship a kernel with binary objects linked without the source code available," saying again, "the GPL isn't quite that restrictive: I could take the kernel source and build, say, a 2.4.0test1 bootdisk, and distribute that, without needing to distribute the source myself - the 2.4.0test1 source is already available anyway. If I make any changes, I need to publish them, though." But Rogier Wolff clarified:

No. Anybody who gets the bootdisk from you has the right to ask you for the sources. Saying "they're available on my ftp-site for download" is condidered sufficient retort to the question nowadays.

Saying "they're available on ftp.kernel.org for download" is a bit tricky: This answer becomes invalid if ftp.kernel.org drops dead or removes the old kernel. Granting your users access to the sources is your problem, and you can be held responsible for their availability.

James replied that as long as the FTP site containing the sources was up and running, all he had to do was distribute the URL, even if the FTP site was not his. He added that only if the FTP site became unavailable would he then be obligated to provide sources himself or point to a different FTP site. Benny Amorsen replied to this by going straight to the GNU General Public License.

(ed. [] If you haven't read the GPL yet, I strongly recommend that you do now. It's a beautiful document, not at all the dry, complex tome some people make it out to be. In my experience, the folks who have those complaints about it have generally not bothered to read it themselves.)

Examining section 3a, he pointed out that ABIT clearly did not distribute the complete source code. Examining section 3b, he pointed out that as far as he knew, no written offer to provide source code had been made by ABIT either. Examining section 3c, he pointed out that this would only be possible if ABIT was distributing their product noncommercially, which was not the case. Benny's conclusion was, "This means that even if Abit distributed binaries compiled from completely unmodified sources, or even distributed binaries copied verbatim from say RedHat, they would still be in violation of the license."

At this point the discussion veered off, but elsewhere, under the Subject: Abit KA7-100 (Gentus Part II), Andre wrote directly to Richard M. Kadoi of Amax Engineering Corporation (Cc:ing linux-kernel) to say:

You asked me about this before ATA-100 was public. ABIT/Gentus Linux is in direct violation of GPL.

Please notify all of the members in the purchasing group across the USA that I am just short of calling of a product boycott. I would ask that you and your business associates apply finacial pressure on ABIT before a future boycott request could impact you. I regret that it may come to this point.

Second, I will call you in the morning about the purchase of one of these mainboards....as an ABIT customer....I am going to get real nasty about support. Since I know how to break their bootable kernel under the correct stress test and will not tell them how to fix it. I will soon attempt to invoke FS corruption by their binary kernels.

No one will use hardware that is defined and proven to eat data.

If you can help me and the OSC resolve the GPL issue, I will then tell them how to fix the bug and it is fixed in modern kernels.

Hate to reply to you this way, but I am only a salesman. I do not have the power nor the authority to influence purchasing in any way, shape or form. I will however forward this to our Linux development department and ask them to look into this matter. That is the most I can do about this matter.

As for Abit's version of Linux, we do not support it, nor do we distribute the product for Abit to my knowledge.

I'm sorry I cannot be of any more help. I will keep you abreast of any information I get back from the Linux development department here.

There were no replies to this, but under the Subject: Another Gentus Release in a month..., Andre wrote directly to various folks at ABIT, Cc:ing linux-kernel, Richard M. Stallman, and Bernhard Rosenkraenzer at Red Hat. Andre said:

LK, Please do not comment........this is only here for public record.

ABIT here is your chance to defend you action is a public forum. I am greatly abusing my privilges here on LK for on reason only. Trust that I will have hell to pay for this issue, but you will have even more if you choose not to respond!

Bernhard, please follow this thread.

RMS, I need to know if there are two different GPL's. The world GPL and Taiwan's GPL which I assume are not the same.

Since Mr. Tim Chin has announce this fact, I want to discuss with him about GPL and cleaning up ABIT's disregard for it. I have include Richard M. Stallman from the Free Software Foundation to listen and comment.

QUOTE from Inmunix site:

***********************************************************
Tim Chen: did initial testing of StackGuard 1.1, doing the first builds of Red Hat Linux with StackGuard, including debugging StackGuard 1.1
***********************************************************

http://lxr.telematik.informatik.uni-karlsruhe.de/source/drivers/scsi/i91uscsi.c

Now we all know that there are thousands of "Tim Chin"'s in the world, but I want the one answer questions on Gentus Discussion board calling himself a "member" and I get labeled a "junior member".

Since Gentus is "Red Hat" based as was "StackGuard" we are narrowing the gap on who is likely responsible or being made to look responsible for the gross violations of GPL.

If this is the same Tim Chin, being an old hat for 1994 and/or before, this puzzles me that one of our own turns to stab us in the back.

Mike Black remembered Stephen C. Tweedie saying in January, that 2.4 would not have the 2 Gigabyte limit on file sizes on 32-bit architectures. He asked if this was still true, and Matthew Wilcox replied, "yes, it's true. on ext2 in 2.4 you will be able to access over a terabyte." Alan Cox also replied to Mike, saying that 2.3 supported LFS, and that an LFS patch for 2.2 was also available. David Lombard gave a pointer to the LFS 2.2 patch and posted a small patch of his own to fix a bug in LFS. He added that users would also need a modified 'glibc', also available from the URL he'd given.

Albert D. Cahalan threw a wet blanket over the party, with, "Gee, it seems nearly dishonest to not mention the horrors of userspace. LFS is a joke. Without an LP64 compilation environment, there is just no hope of getting a complete system with large file support," and added that as far as he was concerned, the ALPHA was the only sane answer to large file needs. David replied, "LFS provides a fully functional 64-bit file capability for an ILP32 system. I've been using it for years..." There was some more discussion, and at one point Trond Myklebust said:

You'll note however that we're not yet ready to comply to the full LFS standard.

In particular, things like 64-bit inode numbers, 64 bit block sizes, are missing from our sys_*64() API. That's a bit worrying IMHO, since it will make it harder to get back to these things at some future time with the stat64 etc. structures fixed in stone.

We're also still missing some LFS functions such as getdents64() / readdir64(). That's less worrying since we can always come back to those for 2.5.x or whenever...

Phil Marek asked about the status of the '/proc/index.html' reorganization. The discussion about it had seemed to stop abruptly, and he was wondering if there was a hold-up. Jeff Garzik replied:

Someone needs to do a complete review of all proc code in the kernel, and post a document describing the namespace currently in use. That's a big first step which must occur before any reorg.

It's a task which has been languishing on my own todo list for quite a while, and its looking like 2.5 work unless someone beats me to it.

Alexander Viro remarked, "Heh. Stopped abruptly == everyone had time to talk about the grand new schemes, but nobody had time/desire to address the real problem:" He went on to agree with Jeff that a thorough review was a necessary first step; and added, "it starts smelling like providing small static trees from drivers may be the way to handle this stuff..." Victor Yodaiken replied, "That's what we are going to do in RTLinux. It would be nice if it fits well into /proc."

You can now download the latest Intel P6 microcode data file and the utility that manipulates it and interacts with the Linux /dev/cpu/microcode driver from the official homepage of this project:

http://www.urbanmyth.org/microcode/

Any comments, fixes and flames - send to me or to Simon Trimmer <simon@veritas.com>. Special thanks go to various people at Intel (you know who you are!) for providing the actual microcode updates to me and for the fact that documented specs actually match the reality which made it possible to write a Linux version of microcode update driver.

Brian Hall asked if this utility would also update the Celeron and Tigran replied, "in theory yes, but I don't have Celerons so, please try it and let me know what happens. (one thing I guarantee - it won't upgrade your Celeron into PIII Xeon :)" Andrew Morton asked what the microcode update was actually for, whether it was bugfixes, features, errata, or something else? Tigran didn't know, but he recommended, "you could try locating this info by searching developer.intel.com diligently. In the meantime, I will ask Intel people and see what they say." And Giacomo Catenazzi finished the thread with his findings:


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

1.	30 May 2000 - 6 Jun 2000	(5 posts)	'ext3' Successes And Problems
2.	31 May 2000 - 9 Jun 2000	(30 posts)	Alan Releases 2.4.0-test1-ac7
3.	1 Jun 2000 - 12 Jun 2000	(11 posts)	32-bit Devices On Alpha
4.	2 Jun 2000 - 8 Jun 2000	(10 posts)	Lockups With Recent Stable Pre-releases
5.	3 Jun 2000 - 6 Jun 2000	(5 posts)	Troubles Coding For Intelligent Hardware Write-Caching
6.	3 Jun 2000 - 7 Jun 2000	(8 posts)	More VM Bug Hunting
7.	5 Jun 2000 - 10 Jun 2000	(16 posts)	To Do List For Next Unstable Series
8.	5 Jun 2000 - 7 Jun 2000	(5 posts)	Pushing For Sign-off On CML2
9.	5 Jun 2000 - 9 Jun 2000	(88 posts)	Linux Driver For Ultra ATA/100 Before Microsoft
10.	5 Jun 2000 - 7 Jun 2000	(12 posts)	Linux Enters Code Freeze For 2.4.0
11.	5 Jun 2000 - 6 Jun 2000	(11 posts)	Easing The Compilation Process
12.	6 Jun 2000 - 9 Jun 2000	(59 posts)	Standardizing Journalling Filesystem Interactions With Virtual Memory
13.	6 Jun 2000 - 9 Jun 2000	(48 posts)	ABIT Violates The GPL -- Again
14.	8 Jun 2000 - 12 Jun 2000	(15 posts)	Large Files On 32-Bit Systems Under 2.4 And 2.2
15.	9 Jun 2000 - 11 Jun 2000	(4 posts)	Status Of /proc Reorganization
16.	9 Jun 2000 - 10 Jun 2000	(6 posts)	Intel P6 Microcode Upgrade And Linux Utility For Installing It