Kernel Traffic Zack Brown Thanks go out to Juan J. Quintela, Jeff Dike, Jeff Garzik, Rik van Riel, Dave Jones and the other folks on #kernelnewbies, for being so patient with my numerous questions.
FS: ext3

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.

Disks: IDE Networking POSIX SMP USB Virtual Memory Philipp Rumpf Kip Macy Christoph Rohland Jens Axboe Meelis Roos Andre Hedrick Jeff Garzik

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

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

Big Memory Support Jeff Garzik

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.

Disks: SCSI Framebuffer Modems Networking SMP

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:

SOYO D6IBA-2 MB
Dual Pentium II 400 CPU
256MB RAM
Adaptec 2940UW On-Board Controller
Intel EtherExpress Pro 100
IP Masquerading (One PPP Modem, One via NetGear Tulip Clone)

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.

Disks: IDE

Andre Hedrick put in a general request, saying:

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.
Virtual Memory

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.

  1. could you explain your shrink_mmap changes? why do they work?
  2. 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.

BSD: NetBSD Disks: IDE Disks: SCSI FS: JFS FS: ReiserFS FS: XFS FS: ext2 FS: ext3 Framebuffer IBCS Kernel Build System Networking POSIX Sound: ALSA User-Mode Linux Virtual Memory David Weinehall James Simmons Bill Wendling Rik van Riel David Woodhouse Lennert Buytenhek Ben Collins Ben Greear Eric S. Raymond Jamie Lokier Jeff V. Merkey Chris Evans H. Peter Anvin Alan Cox Marcelo Tosatti Peter Chubb Randy Dunlap Werner Almesberger Warren Young Andrew Morton

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".

Ben Collins also suggested for the "W" category, "Merge IBM JFS".

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.

CREDITS File Device Mapper I2C I2O Kernel Build System MAINTAINERS File Networking PCI Web Servers Cort Dougan Theodore Ts'o Matthias Welwarsky Tim Waugh Linus Torvalds David Hinds Theodore Y. Ts'o Andrea Arcangeli Vojtech Pavlik Andre Hedrick Jakub Jelinek David S. Miller Arjan van de Ven Grant R. Guenther Andreas Bombe Jay Schulist Randy Dunlap Alan Cox Martin Mares Ralf Baechle Russell King

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

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.

Disks: IDE Microsoft

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?

Code Freeze FS: ReiserFS

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

Kernel Build System

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:

  1. 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.
  2. 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.

Code Freeze FS: ReiserFS FS: XFS FS: devfs FS: ext2 FS: ext3 Networking Virtual Memory Rik van Riel Donald Becker Richard Gooch

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.

 For more on Bert's reference to Donald Becker's "situation", see and .

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 and .

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.

BSD Disks: IDE Kelsey Hudson Bernhard Rosenkraenzer Richard M. Stallman

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

Bruce Perens also replied to Andre with a brief admonition:

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. 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. He quoted most of section 3 (I quote it in full here):

3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:

a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)

The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.

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.

Richard replied to Andre and linux-kernel:

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.

There was no reply.

FS: ext2 Clustering: Beowulf Mike Black Stephen C. Tweedie Alan Cox

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...
Real-Time: RTLinux

Phil Marek asked about the status of the '/proc' 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.

Simon Trimmer Andrew Morton

Tigran Aivazian announced:

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:

Check the 'Specification Update' in developer.intel.com:

http://developer.intel.com/design/pro/specupdt/ (For PentiumPro)

In the list Bugs (Intel call it Errata), if you find: 'workaround: BIOS', it means that the last microcode (normally loaded by BIOS) will correct the bug.