Kernel Traffic #98 For 18�Dec�2000

Many thanks go to Martin Josefsson and the rest of the folks on #kernelnewbies (http://kernelnewbies.org/) for getting me out of a jam. I was dropped from linux-kernel for bounces (long story), and by the time I could resubscribe I'd already lost a significant chunk of material. I went to #kernelnewbies and lo-and-behold, several folks offered help and advice. Martin zipped up a large archive and sent it to me. *whew*! Thanks, Martin and folks!

There were 368 different contributors. 156 posted more than once. 129 posted last week too.

James Lamanna reported good success with Promise Technologies' Fasttrack 100 driver (available as source, with one proprietary object file). He asked if it was possible to compile the module directly into the kernel, so his system could automatically detect the card. He added, "A simple linking of the module into the scsi library by editing the Makefile doesn't seem to do it. It doesn't detect the drives if I boot off of a floppy with this kernel on it." Andre Hedrick replied forcefully:

NO!

Doing so VIOLATES the terms and agreement that you obtained the BINARY Soft-Raid Engine and the GPL terms of the kernel.

Henning P. Schmiedehausen tried to correct him, saying that the only violation would be if James then tried to distribute the result. He said, "You can compile into your kernel anything you like as long as you don't give it away."

Andre came back with, "remember, I DEFINED the terms that the module could be created! Go and examine the wrapper and it is portions of the pdc202xx.c code that is mine. With that in mind, in order to use that GPL code, the restrictions and terms imposed were module exclusive."

Regarding the general GPL question, Dr. Kelsey Hudson disagreed with Henning, saying that modifying a GPLed source required the user to distribute the result. He said, "You can't add stuff to it and then not distribute it, that's in violation." Alan Cox replied, "No it isnt. Some people seem to think it is. You only have to provide a change if you give someone the binaries concerned. Some people also think that 'linking' clauses mean they can just direct the customer to do the link, that also would appear to be untrue in legal precedent - the law cares about the intent." Pavel Machek replied, "This is currently happening with lucent winmodem driver: there's modified version of serial.c, and customers are asked to compile it and (staticaly-)link it against proprietary code to get usable driver. Is that okay or not?" Alan felt probably not, though he added that it was really up to Theodore Y. Ts'o to enforce or not. And Ted said at length:

Well, it's not up to just me, given that Linus also has his copyright on the code (although I doubt there's more than a few lines which are originally his). There are some other people who have contributed code to the serial driver in the past, although most have probably not given me more than a dozen lines of code or so, which seems to be the (completely untested in court) standard which the FSF uses to decide whether or not they need to get formal legal papers signed.

The legal issues are also incredibly murky, since the customers create the derived work, and issues of intent aside, you can't necessarily use intent to change the legal definition of "derived work". (Be glad; although it can be used to create a loophole in GPL, just meditate a while on what the MPAA could do with such an "intent" argument before you decide whether or not it's a good thing. Or think what Microsoft could do if they could make their EULA's as infectious as the GPL with the "intent" argument.) The whole dynamic linking argument is a very slippery slope; where do you draw the line? Does a shell script which calls a GPL program get infected? What about a propietary C program which makes a system() call to invoke a GPL'ed bash? What about an RPC call across the network? What about a GNOME Corba interface? Is it OK if it's on separate machines, but are they considered a single program if the CORBA client and server are on the same machine, since now they share the same VM?

In any case, the FSF has their opinion, and at least one Ivy League law professor laughed aloud when he was asked what he thought about the FSF's legal theories; other people have their own. Most importantly, none of this has been tested in court. So it's probably not worth trying to settle this on the linux-kernel list.

As far as this particular case is concerned, at least Lucent is shipping part of the driver in source. Some of the other winmodem drivers are shipping a pure binary module, which means it will only work against a single kernel version, which locks out users form upgrading to newer kernels if they still want to use their winmodem. So at least Lucent is trying to be at least somewhat good guys about this.

I could threaten to sue them, but it's not clear to me what good it will do, short of depriving some users from being able to use their winmodem. I suppose we could encourage them to rewrite the modified-serial.c for scratch, but aside from making some GPL fanatics feel good, enriching some consultant and making Lucent a little poorer, what good does it really do in the long run? And I have better things to do with my time. At the same time, I certainly won't bless what they are doing. What they are doing is clearly wrong, and illegal. But it is an imperfect world that we live in, as the events in Florida have been clearly demonstrating over the past month.

Given the limited time that I have, I'd much rather spend it going after the Rockwell/Connexant winmodem driver, which also pretty clearly uses serial.c, but for which they've only distributed a single .o file for a specific kernel version. Or I could spend it on programming.....

Under the "Doctrine of Inevitable Disclosure" even looking at GPL code and using techniques it contains would contaminate anything someone works on. This doctrine put forward two concepts that have been used in trade secret cases to justify injunctions and non-competes in areas of IP pollution -- negative knowledge and inevitable misappropriation.

The argument goes something like this. Negative knowledge is defined as knowing what techniques do not work (as opposed to what techniques do work). In the course of development of a piece of software, there are many "blind alleys" and "false starts" that are encountered as an individual uses trial and error to perfect whatever piece of software he is writing. Over time, the person learns what approaches are blind alleys and which work. This knowledge becomes imprinted into the actual thinking processes of this person.

Source code can also contain notes and comments about what does not work, and what does work. Someone reading this source code would then incorporate these ideas and knowledge into their thinking processes. Companies spend lots of money paying engineers to develop software, and this "negative knowledge", under the doctrine of inevitable disclosure is legally the property of an employer since they paid an engineer to experiment and learn it. This is how companies are able to get non-compete court orders against employees in trade secret lawsuits -- they argue that noone is going to go down a development path using ideas or approaches they know do not work. This argument goes on to state that if two engineers, one who had access to a piece of code vs. one who did not were to start at the same time working on the same problem, the person who had access to the code would finish first because he would "inevitably use" the knowledge gained from access to the source code.

Let's say for example two engineers wanted to write a new Linux-like replacement. One of them had access to ftp.kernel.org and the other did not. Which one of the engineers would finish first? Obviously the one with access to ftp.kernel.org would finish first and would not have had to use trial and error to get all the IOCTL calls working, etc. The engineer without source code access would take longer, perhaps by a factor of years, to complete the same project.

Under this argument, it is argued that the engineer who had source code access "inevitably used" negative knowledge he gained from his study of the Linux sources. Absent the vague descriptions of what a "derivative work" is in the GPL, it could be argued that conversion of any knowledge contained in GPL code is a "derivative work".

There are a lot of big software companies who believe this and fear application of the doctrine of inevitable disclosure relative to GPL code. Novell and Microsoft both do not even allow employees to bring GPL code into the building -- period -- for fear that someone will attempt to file a claim that they have "converted" GPL code and created derivative works that may have contaminated non-GPL code projects. Novell has an official standing policy barring employees from using GPL code. That's why all the Linux work for NetWare is done in the India development center, and not the US, out of fear of IP pollution in the Provo facility. When I officed at the Microsoft campus in 1999, they had similiar policies, and were even more strict than Novell.

Now, in reality, these folks have employees in both companies who download stuff at home, and putz around with it, GPL code included, but that's a lot different from these companies having official policies allowing projects to use GPL code in their normal course of business.

In short, under the doctrine of inevitable disclosure, a GPL copyright holder could succeed with a claim of conversion from someone simply looking at a piece of GPL code, then using whatever it contained to build either interface modules or a module with similiar functionality. It would be a hard call for a sitting judge to make, but I have seen actual cases where a judge does just that with the help of a special master.

Personally, I think the doctrine is one of the most evil fucking things in existence, legal opponents call it "the doctrine of intellectual slavery" because it has the affect under the law to be able to convert simple NDA agreements into non-compete agreements, and I've seen it used this way. Novell has blocked all internal access to the NWFS ftp server TRG, BTW, because they are afraid I would attempt to apply the doctrine to force them to open source NetWare projects if they download NWFS and used it internally with eDirectory. They've told us so.

This may help you understand just how complicated this whole IP stuff is relative to derived works. It's undefined under current case law and precednt relative to the GPL, but these big companies are taking no chances....

Later, he added, "BTW, for those legal folks who also demand I post case law citations, please see the Pesico vs. (I forget the guys name) case. Just get on Westlaw, and look up "Pepsico". This is the case where this doctrine was created and applied by a state judge. The case was upheld, and has been used all over the US since then to shaft departing employees from big software/hardware companies."

In reply to Jeff's statement about converting simple NDAs into non-competes, Ted replied, "most courts have strict limits to how far they will take non-compete arguments, and if an NDA turned into a non-compete, past a certain point they will say that a person has a right to earn a living..... Fortunately most judges will apply some amount of common sense, even despite their law school training. In any case, the GPL doesn't involve NDA's or Trade Secrets, so saying that this doctrine could be used to contaminate non-GPL code simply by having people look at GPL code is bullshit." Jeff replied, "This "I have a right to make a living argument" only holds water if the other side refuses to post a bond. If they post a large enough bond, a court WILL rule in favor of inevitability if they make a good case for it. (The bond required to keep me from programming for 18 months cost Novell $10,000,000.00.)" Regarding the common-sense of judges, he added, "US Judges are pontius pilate's all -- with hearts as black as the robes they wear. They don't care about you, or your rights. Remember, almost all judges are lawyers who are too old or to incompetent to practice law so they get themselves an appointment. Most of them were crooked lawyers who went into politics (which is how a lawyer gets made into a judge, BTW, he goes into politics)."

Continuing from Issue�#97, Section�#2� (22�Nov�2000:�More 2.4 Filesystem Corruption) , Andries Brouwer reported, "I did again a large test comparing two identical trees. Found again corruption, and, upon inspection, the disk files did not differ - this is in-core corruption only." Linus Torvalds asked for a rough estimate on when Andries started seeing this behavior, and Andries replied, "I reported both cases. That is, I started seeing it a few days ago." Linus replied:

I wasn't trying to imply that you hadn't reported them well.

It's just that I was born with a highly developed case of Altzheimers, and I have trouble keeping details around in my head for more than about five minutes.

I'm half serious, btw. It's not that I don't have a good memory, but I tend to remember patterns and how things work, and I'm _really_ bad at keeping track of details. This is why I absolutely depend on people like Alan Cox etc who maintain lists of problems, and who are good at gathering reports on what kinds of machines see it etc. I just suck at it. I really do.

Anyway, it tentatively sounds like it might have been request corruption by the new re-merge code. It fits the details, you having IDE and all. I see that you can't at least easily reproduce it in pre3 any more, but if it turns out later that you still can, please holler. Loudly.

That still leaves the SCSI corruption, which could not have been due to the request issue. What's the pattern there for people?

Elsewhere, Andries reported, "I just tried 2.4.0test12pre3, which has Jens' fix, and no corruption to be seen. Will test a bit more, but perhaps this did it." Tigran Aivazian tried this on his SCSI system, but Jens Axboe explained, "No, the fix could only really make a difference on IDE. So it can't possibly account for all the corruption issues reported, but I'm hoping at least some of them... The fix was posted in the other corruption thread, and it's in test12-pre3 too."

In technical discussions elsewhere, a bunch of folks tried to track down the various problems.

Patrick van de Lageweg posted a patch to allow a user-space daemon to handle the internals of a serial port. He added, "It was writen for the Pele 833 RAS Server but is also usable for other serial device drivers in user space." Pavel Machek remarked, "Good, someone finally implemented this. This is going to be mandatory if we want to support winmodems properly; also ISDN people might be interested [to kick AT emulation out of kernel]." And Jamie Lokier added, "For winmodems you can do a pretty good job with ptys -- the pty and tty side access the same share termios structure. The new driver is a much cleaner way to the same functionality though."

However, Tigran Aivazian pointed out some bloat in the patch, where variables were explicitly initialized to zero, rather than letting them take an initial 0 value from the BSS area, which the kernel cleared automatically on bootup. He explained that the code as it stood "wastes at least 4 * USSP_MAX_PORTS bytes in the kernel image. Typically around 64 bytes but could be more. For more info see the recent silly flamewars on the list." Rogier Wolff came back with, "And I think the guys who were saying that the "documentation is more important than those few bytes" were winning." He argued that setting the initial null value explicitly, gave important information to the code maintainers. At one point Russell King argued in response, "In which case, can we put it in as a documentation fix rather than changing the compiler output?" He suggested simply including a comment to the effect that the variables were expected to be zero initially. This did not appeal to Rogier, who replied:

I care more about the 4 bytes of extra source than the 4 bytes of extra object.

I consider the 4 bytes of extra object code a compiler bug, and if we start catering for that, the bug in the compiler will never be fixed.

This is similar to how Linus forced the recognition of the "unroll-loops" bug by the gcc team.

This patch makes the same changes (dma_prog and poll) that are already made to some other OSS drivers (test12-pre3). Further it finally includes all modifications made in 2.2.18 (Alan: why do you do them line by line ?).

It implements mono output and fixes a bug in the dma logic (reset necessary because some descriptors are already prefetched and are not updated when the dma is only halted and not reset). There is still a bug in the device close handling, it gives an occasional dma overrun error.

It has been tested on by 3 people on 4 different machines with 3 different chip sets and at least 3 different codecs, so it really should work ! And it does the same things the alsa driver does.

Alan Cox asked Linus Torvalds not to apply the patch, saying, "Not only does it do format conversions in kernel (which is a strict not to be done in the sound driver policy) it also makes it impossible to make mmap work correctly with the OSS API definitions." He added, "Tjeerd. I deliberately applied only small bits of your patch before because the mono mode stuff clutters the driver horribly and is not in the right place. It belongs in the application/libraries." Pavel Machek replied that in this case, parts of drivers/usb/audio needed to be removed as well, since they also contained format conversions. Alan replied, "Definitely we should." At this point Thomas Sailer broke in, arguing:

If you start killing format conversion then >99% of the existing applications won't work anymore with usbaudio. At that point you can dump the OSS interface just as well.

And before killing format conversion you should kill the mmap stunt, because the format conversion complexity (~25 LOC) is by far dwarfed by the mmap emulation stuff.

The underlying question is:

do we want an usb audio driver that supports the OSS interface and with which most existing applications work
or do we want a simple driver with its own non-OSS interface.

Anything in between is IMO silly. Killing the format conversion drops the advantage of running many existing applications but don't bring you much closer to the goal of simplicity.

Those applications already have to deal with the fact some devices only support 48KHz 16bit stereo audio. I run a full desktop environment on such hardware without problems.

What format is it that causes the problems, the only badly supported key format right know I know of is 16bit bigendian. That needs some small esd patches.

To which Thomas replied, "S8 is a not very well supported format. And btw there are many applications that cannot live with esd for latency reasons." End of thread.

Roberto Ragusa reported that on recent development kernels (2.4.0-test10 and 2.4.0-test11), the SoftwareRAID autodetect code gave a kernel panic. He included a lot of system information and oops output, etc., and Neil Brown offhandedly replied that this had been fixed in 2.4.0-test12pre3; Roberto reported that no, the problem persisted in that kernel as well. Neil took a closer look, and replied:

My apologies. There was a "oops in SoftwareRAID autodetect" in test10 and test11 that was fixed in test12pre3, and I just assumed that your's was the same, and didn't look at it properly.

On looking again, your problem is definately different and quite weird.

He included a one-liner and added, "I went back and poured over the code for a little while, and I think I found something. linear.c may over-run a kmalloced buffer, which could product exactly what you are getting. The following patch isn't *correct*, but if it makes a difference for you, then it means that we have found the problem.. please let me know."

Roberto replied happily, "Yes, it makes a difference :-) . The boot doesn't fail anymore and all the RAID partitions are correctly detected." At this point the discussion skewed off.

Steven N. Hirsch reported that 2.2.18 detected a nonexistent PS/2 mouse on his system. Alan Cox replied, "I've fixed the major case." [...] "I take it like the others 2.4test also misreports a PS/2 mouse being present. Anyway I think its no longer a showstopper for 2.2.18. Someone with an affected board can piece together the picture." Jeff V. Merkey reported the problem gone on 2.2.18-24. Steven was not so lucky, and still reported the same problem, though he added, "I agree the mouse mis-detection isn't a showstopper - just damn annoying."

I am working on enabling Linux console for Local languages. As the current PSF format doesn't support variable width fonts , I have made a patch in the console driver so that it will load a user defined multi-glyph mapping table so that multiple glyphs can be displayed for a single character code. All editing operations will also be taken care of.

Further, for Indian languages, there are various consonant/vowel modifiers which result in complex character clusters. So I have extended the patch to load user defined context sensitive parse rules for glyphs / character codes as well. Again, all editing operations will behave according to the parse rule specifications.

Even though the patch has been developed keeping Indian languages in mind, I feel it will be applicable to many other languages (for eg. Chinese) which require wider fonts on console or user defined parsing at I/O level.

Currently I have developed the patch for Kernel versions 2.2.14 and and am in the process of making it for 2.2.16 and 2.2.17. I request people to try out this patch and give comments and suggestions to me.

Those who want to try out this patch can send mail to me in the address rathee@lantana.iitm.ernet.in (mailto:rathee@lantana.iitm.ernet.in) or to indlinux-iitm@lantana.iitm.ernet.in (mailto:indlinux-iitm@lantana.iitm.ernet.in)

The package , containing the patch , some documentation ,utilities and sample files will come around 100 KB.

Andries Brouwer was happy to hear about this, and added, "Last year I needed support for Tibetan and added just the converse: single glyphs that were represented by a sequence of Unicode symbols. This is needed e.g. in the situation where Unicode does not have precomposed symbol+diacritical, so that the glyph that represents an accented character corresponds to a sequence rather than a single Unicode symbol." He asked to see K's patch, and Kurt Garloff replied, "Andries, I sent you a patch a couple of months ago which does enable the support of wide characters and another font (besides the sun12x22) making use of it. I hope it's in your codebase by now, so it does not get lost when the advanced things of K Ratheesh get merged." End of thread.

Oleg Drokin noticed that in 2.4.0-test11, enabling hot-plugging would cause a race condition, if the number of network interfaces were to change (as by invoking ppp, in his case). Andrew Morton posted a lengthy patch, and explained, "Yup. This is due to the kernel trying to fork/exec from within a half-dead process. Could you please test this patch? It was sent to Linus for test12-pre4, but...." Oleg replied, "Yes, it works that way. But code path and readability became horrible, unfortunatelly. :(" there was no reply.

here is my latest attempt to find a way to toggle A20M# that genuinely works on all machines -- including Olivettis, IBM Aptivas, bizarre notebooks, yadda yadda.

The bizarre notebooks with broken SMM code are the ones I really worry most about... there may very well be NO WAY to support them that actually works on all machines, because you don't get any kind of feedback that they are broken.

If you have had A20M# problems with any kernel -- recent or not -- *please* try this patch, against 2.4.0-test12-pre5

Linus Torvalds made some technical points, and added, "Btw, do we actually know of any machine that really needs the "and $0xfe"? That register really makes me nervous." To which H. Peter replied, "Good question. The whole thing makes me nervous... in fact, perhaps we should really consider using the BIOS INT 15h interrupt to enter protected mode?" And Alan Cox interjected with a smirk, "From my experience with BIOS authors, only if Windows 98 uses the same function with the same arguments, the same stuff top of stack and the same segment registers loaded ;)" Elsewhere, Linus continued, "I agree with Peter - if somebody knows BIOS programming and how to use "int 15" to enter protected mode, then that migth well be the easiest solution. The only real reason the linux setup code does it by hand is that the original code was written that way - and it was written that way because I had never used the BIOS in my life before, _and_ I wanted to learn the i386. Both of which were valid reasons back in 1991. Neither of which is probably a very good reason ten years later"

The protected-mode switch in INT 15 is probably the least tested BIOS function ever. I wouldn't trust it, and relying on it will put further burden on embedded Linux developers, many of whom don't even have a BIOS. It is 'least tested' because there is no way provided to get back to real-mode. This implies that somebody probably 'tested' it once, verified that some simple 32-bit function executed for a few microseconds, then declared; "It works!".

Many new chip-sets snoop for the sequence:

Write 0xd1 to port 0x64
Write 0xN1 to port 0x60

... Where 'N' are any bits and the LSB enables A<20> propagation.

The writes have to be in sequence, therefore, one must read 0x60 first, OR in bit 0. Write 0xD1 to 0x64, then write the new enable- value to port 0x60.

It takes about 700 to 1500 microseconds for a real keyboard controller to enable the A<20> propagation bit. It takes only a few hundred nanoseconds for the virtual sequence, above, to do the same thing.

On all machines I have looked at, including several lap-tops, the 'fast' A<20> enable port is R/W. This means that you don't have to crash the machine by setting some secret reserved bit. Just read first, OR in your A<20> bit, then write.

You can experiment by booting DOS (or free-DOS), and play using DEBUG. Setting A<20> while in real-mode DOS won't hurt anything. You can even check for wrap beyond FFFF:0000 from DEBUG to see if the bit is enabled.

I suggest that a "universal" sequence is the D1/N1 sequence shown above (this will work with real keyboard controllers), you don't have to wait for completion of the last command as long as you don't have more than two commands in sequence. This is because the controller doesn't know if you ever read the status, and it will execute the next command, if one exists, as soon as it writes the completion status from the previous.

The next step of the "universal" sequence, if the previous doesn't work, would be to enable the fast A<20> bit (only) in port 0x92.

Elsewhere, Kai Germaschewski reported failure with H. Peter's initial patch, saying, "Just a datapoint: This patch doesn't fix the problem here (Sony PCG-Z600NE). Still the spontaneous reboot exactly the moment I expect to get my console back from resumeing." Linus had a brainwave, and replied:

I bet I know what's up.

Want to bet $5 USD that suspend/resume saves the keyboard A20 state, but does NOT save the fast-A20 gate information?

So anything that enables A20 with only the fast A20 gate will find that A20 is disabled again on resume.

Which would make Linux _really_ unhappy, needless to say. Instant death in the form of a triple fault (all of the Linux kernel code is in the 1-2MB area, which would be invisible), resulting in an instant reboot.

Peter, we definitely need to do the keyboard A20, even if fast-A20 works fine.

Yup. It's a BIOS bug, oh what a shocker... (that never happens, right)?

I might hack on using INT 15h to do the jump to protected mode, as ugly as it is, but I won't have time before my trip. It would require quite a bit of restructuring in setup.S, and would probably break LOADLIN.

Right now this is my interim patch (to clean test11). The thing to note is that I decreased the keyboard controller timeout by a factor of about 167, while making the "delay" a bit longer.

Now, if you don't have a keyboard controller, the bootup delay should be on the order of 1.2 seconds or so (calling empty_8042 three times, each around 0.4 seconds to time out). Which is acceptable. Especially as the non-keyboard-controller machines that don't even emulate one are quite rare. And it's still long enough that if the keyboard controller hasn't emptied in 0.4 seconds, something else is badly wrong.

The non-keyboard-controller timeout used to be around three minutes before. Which _definitely_ is excessive. Most people would assume that the machine had hung.

Okay, here is yet another A20 patch (against test12-pre6) this time for people to try out. This patch uses the following algorithm for enabling A20:

Try the BIOS call. If it works, we're cool.
Try the KBC (using Linus' lowered timeouts.)
If the KBC doesn't work, or is very slow, flip port 92.

After 3 it sits into the same infinite loop waiting for A20 to become enabled (necessary on for example some Toshiba notebooks which have an extremely slow response to A20.)

The main differences between this patch and test12-pre6:

Trying the BIOS first of all. This should reduce the risk of the BIOS getting confused while doing a suspend. This also gives even less of an excuse for any nonstandard arrangement -- if you didn't implement the standard KBC *and* you didn't provide the BIOS call, you have a seriously broken piece of hardware.
If the KBC responds quickly enough (within about 10000 cycles), we don't ever touch the fast A20 gate. This is a difference from previous code, where the fast A20 gate was toggled immediately after the KBC, even if the KBC responded instantly.
I had to move the A20 code somewhat earlier in setup.S in order for the BIOS to still be available.

Please try it out and let me know as soon as possible...

Jan Niehusmann reported filesystem corruption under the latest developer kernels, and over the next couple days posted a patch to prevent it, though he added, "Please note that the patch circumvents the problem more than it fixes it. The true fix would invalidate the mappings, but I don't know how to do it." Udo A. Steinberg confirmed that the patch worked, and asked Alexander Viro what he thought. There followed a very brief technical discussion, ending with Jan asking for documentation and getting no answer.

Later, under the Subject: Trashing ext2 with hdparm (http://www.uwsg.indiana.edu/hypermail/linux/kernel/0012.0/0690.html) , Udo reported, "Following the discussion in another thread where someone reported fs corruption when enabling DMA with hdparm, I've played around with hdparm and found that even the rather harmless hdparm operations are capable of trashing an ext2 filesystem quite nicely." Jan replied that he was currently trying to isolate a bug that might be related, and Byron Stanoszek speculated, "I've seen this behavior on test-6 and up. I think it has something to do with a problem in shared memory which is used by the 'hdparm -tT' code snippet. I believe it munges over a lot of the memory segments that contain cached disk files (the common ones accessed, such as /etc/mtab and /etc/utmp..etc). When looking at the contents of those files, the memory is obtained from the cache and they appear bogus, but on disk they are still correct."

Andre Hedrick objected that Udo's exploit could not possibly cause corruption, as it was a read-only test. But Jan confirmed the exploit, and Udo also replied to Andre, "As others pointed out, it's probably something related to shared memory, but it's definitely hdparm that triggers it. I haven't got the hdparm sources here to look at what exactly it's doing, but there is corruption going on, not on disk, but definitely in memory." At this point the discussion skewed off unresolved.

Reto Baettig asked, "Is there any way of getting a standardized way of doing I/O to a block device which could handle 64bit addresses for the block number?" He added that, with the current 32-bit scheme, "Don't you think that we will run into problems anyway because soon there will be raid systems with a couple of Terrabytes of space to waste for mp3's ;-)" Brian Pomerantz sited a real-world example of this problem, saying, "I'm going to be putting together a RAID system with between 1.7-5.1TB by February. This will be seen as a single block device to clients via a network block device (more than likely it will be 16 Ciprico Rimfire 7000's spread across 4 nodes via a Quadrics switch). So, what I'm seeing right now is that I won't be able to address this amount of space with a single block device. By the summer of 2001 we could be looking at putting together 10-150TB (depends on budget and need) of disk space for a production cluster and it would be nice if our parallel filesystem could span that entire space with a single image." Stephen C. Tweedie said that this was on the agenda for "urgent fixing" in 2.5.

David Woodhouse reported a bug in the FAT filesystem, and Alan Cox replied, "I'd suggest you don't run the FAT file system code in 2.4test* unless you are doing it read only or have the patches applied that fix truncate, otherwise you will turn your msdos fs to gloop right now." End Of Thread (tm).

The cyrixIII chips by via have the centaur vendor id which causes the identify_cpu call in arch/i386/kernel/setup.c to fail. It is probably reasonable for it to have the centaur id as via owns centaur as well. I just replaced the centaur_model call with the cyrix_model one, but I know that I am using a cyrix chip.

A test probably needs to be added in the centaur_model section to test for the cyrixIII in disguise.

The error is a general protection fault.

He apologized in advance if this was "old hat", but Alan Cox replied, "Its fairly new hat. VIA cyrix III is a next generation IDT winchip (VIA bought both the winchip stuff and the Cyrix stuff). 2.2.18 should handle the winchip properly." Dave Jones pointed out that the stable and developer trees had had the test for some time already, and asked Eric, "Are you saying the latest versions still don't recognise it?" But there was no reply.

Carl Perry read on Slashdot that the Microsoft API was very poorly documented, and he didn't want to see Linux go the same way. He asked if there was a project underway to document the kernel subsystems, drivers, portability issues, etc.; and volunteered to coordinate and host the effort. Jeff V. Merkey replied, "Whoever posted this on Slashdot is smoking some killer dope or something. The Windows API is very well documented via online docs from MSDN -- better than most software anywhere in the world. Whoever said this was high or something or ignorant or never had an MSDN subscription. I used to get 20-40 CD's a month from MS on a Universal Subscription, with enormous documentation.." Alan Cox also replied to Carl:

For the kernel stuff there is a project to put documentation about functions and what they do inline into the kernel. Its slow progress. Trying to do anything formal and structured isnt going to be productive until the documentation is much much more complete

For syscalls Andries Brouwer maintains a man page collection (and writes many of them). He takes submissions.

Daniel Phillips gave a link to Linux Cross Reference (http://lxr.linux.no) , and reminisced, "I know exactly how it feels when first getting into the internal kernel interfaces - for me that was barely a year ago. I wanted at that time to try and fix all the documentation problems as I went, but it quickly turned into a choice between doing useful development and doing useful documentation. Guess which one I chose. I sincerely hope that others will make the opposite choice, and the linux hacking world will be a better place." He also gave a link to Andries Brouwer's Linux Information (http://www.win.tue.nl/math/dw/personalpages/aeb/linux/) pages and the Kernelnewbies (http://kernelnewbies.org/links/) links page. He added, "Tigran Aivazian has been preparing 'Linux Kernel Internals' which is *highly recommended* and 100% free. Why don't you get together with him, and Gary Lawrence Murphy (see his monthy kernel wiki nag)?" and Tigran Aivazian replied, regarding "Linux Kernel Internals:

in case he is curious where to find it:

http://www.moses.uklinux.net/patches/lki.html

(or .sgml for master source).

Interestingly, the main problem with LKI turned out to be _not_ the issue of keeping it uptodate but filling in the missing bits, most notably buffer cache and page cache. By now I more or less actually understand the Linux buffer cache (only after diligent comparison with UW7, AIX, OSR5 and many other commercial UNIX implementations whose source code is available) but still not the page cache (even after reading everything about it that I could find, including recent Understanding Linux Kernel book by Bovet which I just finished reading). E.g. it is not even obvious to me that things will get any worse if one throws away the entire readahead logic from the page cache.

So, if someone wants to write a chapter on Linux page cache and contribute it to the LKI book (and thus become a co-author :) please feel free -- it will be a proof that someone in the world actually understands it -- at the moment I doubt that very much... Take it as a challenge :)

Pavel Machek noticed, somewhat to his dismay, that it was possible to delete a swapfile that was in use. Trying to 'swapoff', however, would report the file as nonexistent. Creating the file anew and trying 'swapoff', would give an error. Without running 'swapoff', he was unable to safely reboot the system. He asked for help.

Rik van Riel suggested not deleting the files in the first place, and added that rebooting was the only solution. Pavel argued that the mistake was too easy to make, and should be prevented if possible, or at least there should be a way to recover. He added that rebooting would cause problems, since the filesystem was still busy.

No solution appeared for Pavel during the thread, but Peter Samuelson suggested, "add code to /sbin/swapon and /sbin/swapoff to set and clear immutable bit. Sure it only works on ext2 but how far do you want to take this thing?" Someone else suggested adding /proc entries for each swapfile, so root could run 'swapoff' even if they were delted. David Feuer liked the idea, and the thread ended.

1.	24�Nov�2000�-�5�Dec�2000	(34 posts)	Licencing Discussion
2.	28�Nov�2000�-�4�Dec�2000	(56 posts)	Hunting Several Filsystem Corruption Bugs: The Saga Continues
3.	30�Nov�2000�-�7�Dec�2000	(9 posts)	User-Space Serial Port Driver
4.	1�Dec�2000�-�4�Dec�2000	(8 posts)	Problems With Proposed Sound Code Cleanup In Stable Series
5.	1�Dec�2000�-�6�Dec�2000	(12 posts)	Kernel Panic In SoftwareRAID Autodection In Recent Development Kernels
6.	3�Dec�2000�-�9�Dec�2000	(16 posts)	False Detection Of PS/2 Mouse In Recent Stable Kernels
7.	3�Dec�2000�-�4�Dec�2000	(3 posts)	Local Language Support
8.	4�Dec�2000	(3 posts)	Race Condition with Hot-Plugging And Number Of Network Interfaces
9.	5�Dec�2000�-�8�Dec�2000	(21 posts)	Negotiating The A20 Address Gate
10.	5�Dec�2000�-�7�Dec�2000	(6 posts)	Filesystem Corruption In Developer Kernels
11.	6�Dec�2000�-�7�Dec�2000	(5 posts)	Status Of Large Filesystem Support
12.	6�Dec�2000�-�7�Dec�2000	(2 posts)	FATFS Not Yet Ready In Developer Series
13.	7�Dec�2000	(3 posts)	Trouble Identifying Cyrix III Chips From Via
14.	7�Dec�2000�-�8�Dec�2000	(6 posts)	Kernel Documentation
15.	9�Dec�2000�-�10�Dec�2000	(7 posts)	Running 'swapoff' On Deleted Swapfile

Kernel Traffic #98 For 18�Dec�2000

By Zack Brown