Kernel Traffic #99 For 25 Dec 2000

There were 453 different contributors. 197 posted more than once. 152 posted last week too.

Eckhard Jokisch had some problems using an Onstream drive, and in the course of discussion, Rogier Wolff said:

Stay away from onstream is my advice nowadays.

We've been trying to get the stupid thing to work since july 8th, and onstream technical support has been very helpful by telling us what to do and such. Like downgrading to a kernel version that has known remote attacks. However doing that does not solve the problems we report. After much ado, they promise to "escalate" the problem to people in the states, and then this does not lead to results in the month we've given them.

In short: in the simplest case, just writing a stream of bytes to the drive, it works. But the drive then doesn't nearly have the "raw error rate" that they claim.

If you start using a backup program that needs to seek back and forth a few times, the drive loses track where it is, and doesn't recover from this situation.

I've returned mine to my vendor, and I hope that Onstream gets the message in the end: They do NOT support Linux.

But Kurt Garloff dissented, "I've been using the USB and the SCSI versions of OnStream tapes with good success!" He added, "If you want a really helpful advice: Use the osst driver and the use it with ide-scsi. Report problems to the osst mailing list. So far, I'm not aware of anybody we failed to help. http://linux1.onstream.nl/test/" Eckhard replied, "This was really really helpfull :-) It just works fine now. Wouldn't it be good to put a slight hint somewhere in the kernel configuration?" End of thread.

Matti Aarnio announced that he'd removed all the mail-to-news feeds from Innominate. These included feeds from linux-alpha, linux-doc, linux-fsdevel, linux-kernel, linux-raid, linux-scsi, linux-smp, sparclinux, and ultralinux. He said, "Officially we don't approve bidirectional news<->list feeds, as those are prone to this type of blunders of looping messages back to the list."

We know that this is a difficult setup and we tested it thoroughly before using it, and it worked for a long time now. Unfortunately one of our admins updated the news server today without thinking of the implications :-(

We deeply regret this and apologize honestly, but also would like to resubscribe...

Rik van Riel suggested making the feeds one-way this time, as the bi-directional feeds always tended to give problems, in his opinion. Juri replied that they'd do this, since there didn't seem to be much choice. But Miquel van Smoorenburg offered:

At ftp://ftp.cistron.nl/pub/people/miquels/software/cistron-m2n-1.36.tar.gz you'll find some gatewaying software that is unidirectional, yet bidirectional ;)

It works by marking the groups as moderated. A posting to the group will be sent by mail to the moderator, which is a script that checks and rewrites the news message, and sends it to the list.

That way it's almost impossible for loops to get created.

Elsewhere, Marco d'Itri announced, "If vger postmasters do not mind, next week I'm going to unidirectinally gate linux-kernel (and maybe other high traffic vger lists, any suggestions?) to a group in the linux.* hierarchy." Matti replied, "You are welcome to do that. It is just the BI-directional gatewaying we are opposing for well observed reasons... (People are doing bidirectional gateways regardless of our opposition -- "we are good, we won't do it wrong", but when things irregardless do go wrong, we have to do some drastic measures to cut the loops.)"

Georg Nikodym reported that sysklogd 1.3-31 no longer compiled using the headers from 2.4.0-test11, because linux/module.h had changed in an incompatible way. He added, "Strictly speaking this isn't a kernel bug" [...] "It's not clear to me who's code needs changing so I'm sending both to linux-kernel and to some of the people that have the misfortune of being listed on the sysklogd man page." Keith Owens replied:

Speaking as the modutils maintainer and the person who added list.h to module.h, sysklogd should *not* be including linux/module.h. Linus has spoken, it is an error for user space applications to include kernel headers. Even modutils does not include linux/module.h, instead it has a portable (2.0 through 2.4) local definition of struct module.

ksym_mod.c is only present to try to decode oops reports in klogd. klogd only handles some architectures, it often gets the oops decode wrong and it destroys the log information that is needed by other oops decoders. IMNSHO ksymoops does a much better job of decoding the oops, but I maintain ksymoops so I am just a little biased ;)

I would prefer to see the oops decoding completely removed from klogd. The only justification for klogd converting the oops is to save users from running ksymoops by hand. I would not mind klogd capturing the oops text, forking to run ksymoops then logging the ksymoops output. Just as along as the original text was left alone and the ksymoops output was obviously distinguished from real kernel output.

Georg implemented this suggestion and posted a patch, but Keith replied, "You only removed the module symbol handling. The problem is that the entire klogd oops handling is out of date and broken. I recommend removing all oops processing from klogd, which means that klogd does not need any symbols nor System.map." Georg replied that he'd look into that, and added, "while we're doing extreme surgery, why have klogd at all? Every other unix, kernel messages are handled by the syslog system. What problem did klogd solve and does that problem still exist today?" He suggested that Keith's proposal would be the functional equivalent of 'cat < /proc/kmsg > /dev/log &'. Keith explained, "klogd maps the kernel messages from <n>text to syslog levels and does some fiddling with kernel log levels at start up. It needs to be more than a simple 'cat'. When symbol handling was added to klogd, ksymoops was built into the kernel and very unreliable. Since then ksymoops has been moved to a separate package and is now reliable. Alas oops handling in sysklogd has not kept up to date and is now the problem area." Georg performed an appendectomy, taking all symbol processing code out of sysklogd, and suggesting removing several files from that package as well. But now Keith objected, "Looks good, except that you need to keep the option flags for backwards compatibility. There are a *lot* of scripts out there which invoke klogd with various options and they will fail with this change. It is OK to issue a warning message "klogd options -[iIpkx] are no longer supported" as long as klogd continues to run. Otherwise you will get a lot of irate users complaining that klogd is failing at boot time." George posted a new patch to list various command-line options as obsolete, and the thread petered out.

Mike A. Harris asked which ethernet module to use with his D-LINK DFE-530-TX card. Peter Horton replied, "If the PCI device ID is 3065 then it's via-rhine, but not supported by the driver in the kernel. Get updated via-rhine from Donald Becker's site http://www.scyld.com/network." But Jeff Garzik pointed out, "2.4.x-test has some fixes for via-rhine which don't appear to have made it into the Becker driver yet..."

Simon Huggins asked if either of those would make it into the stock 2.2 via-rhine, and Jeff said, "Becker never replies to patches and changes I send him, so who knows. Ask Becker..." Alan Cox also said he'd include a port into 2.2.19pre if someone would write it. Urban Widmark posted a lengthy patch and explained:

Below a patch that updates the 2.2 via-rhine driver from Becker's 1.08b, except for the pci probing that is unchanged, compatibility macros and dead code that are not needed in 2.2 removed (removing ifdef CARDBUS is from 1.08b) and "clear_tally_counters" from 2.4.

It would be nice if people using 2.2 and one of these cards could test this too.

Patch includes:

new VT6102 pci id & supporting non-aligned data buffers for that chip
completely untested (by me, that is) big<->little endian stuff
free allocated memory on driver unload
no more writel to 0x7c.
2 16bit values accessed as one 32bit (why? not sure, pci optimization?)
change transmit ring size

and some other more or less minor changes/cleanups.

This is mostly a copy&paste operation. If you'd rather get a smaller change for just supporting the VT6102 that is easy to do.

However, this is very similar to the 2.4 driver (locking is a major diff) so I hope it is ok. Also, if I don't include most of the 1.08b driver I'm not sure what version name to give it ... :)

Jeff V. Merkey pointed out that he'd already sent out thousands of his NTFS repair tools, to folks contacting him after corrupting their filesystems with the badly broken read/write NTFS filesystem support under Linux. He added, "I will keep providing this service, but I am only treating the symptons of the illness and not curing the patient. Based upon the level of contamination of TRG with Microsoft IP, I have been advised if I post an NTFS replacement before the 18 month doctrine of inevitability "window" is past, Microsoft will most certainly sue us, and win." He suggested alerting users that the feature was dangerous and unstable, and that they shouldn't use it. Peter Samuelson replied:

Here's an idea: let's make r/w support a separate CONFIG option, and label it "DANGEROUS".

Oh wait, we already do that.

Perhaps we should warn users to back up their NTFS partitions before trying this option. Put that warning in the help text for CONFIG_NTFS_RW.

Oh wait, we already do that too.

How stupid does one have to be in order to enable an option labeled "DANGEROUS" for a non-experimental system?

Later, Michael H. Warfield also added, "It can't even be enabled unless you enabled experimental code options. Then, it's disabled by default and you first have to enable the R/O NTFS. Then you have to explicitly select the option to enable RW access that is clearly labeled DANGEROUS. This thing is not armed and dangerous due to an act of ommision. It's live and active only through three acts of commision. About the only thing left, short of removing it from the kernel entirely, is to make the option a hidden control option, like some of the debugging options, that requires editing a header file or a Makefile to enable." Further along in the thread, Peter also suggested, "comment out the CONFIG_NTFS_RW line entirely. Actually, I think that *would* be a good idea. Anyone who has any business messing with NTFS_RW is more than capable of editing Config.in." Jeff Garzik agreed, and added, "I would prefer that filesystems with known broken write support depend on CONFIG_BROKEN (which would be always defined to 'n')"

Elsewhere, Jeff V. M. added, "I've got even more bad news -- because it's in Linux, Microsoft is already altering the on-disk structures again, so it's about to be broken in R/O mode as well when Whistler comes out." In response to the idea that no additional warnings or preventative steps needed to be taken to keep people from trashing their systems, he added, "You guys make the call. I will be here to catch the 100+ messages that would normally be posting to the kernel list with "Linux destroyed my data", and I have been handling them. I am just alerting you guys that the numbers of people needing this are increasing, which is an indication more and more people are using Linux to migrate NT to Linux, and vice-versa, and getting themselves into trouble. We need to brainstorm a more long term solution for this problem. I suspect if I post these tools on our FTP server for free download, MS will promptly show up with attorneys. Normally, this is what I would do, but these tools were developed via access to MS IP, and so long as I am helping MS customers recover data in a "consulting" capacity, I do not believe they will interfere, particularly since everytime this happens, Linux gets a great big black eye with the affected customer. But very soon (like after 2.4 ships) the numbers of folks needing this may increase to a capacity I cannot support properly without dumping these tools into general distribution -- then the shit will hit the fan with MS if I do this."

Eric W. Biederman said that if Microsoft were deliberately preventing interpoerability between Windows NT and Linux, that Jeff V. M. should alert the antitrust lawers. But Jeff V. M. replied:

I think the anitrust issues are moot -- they have had their way already with Microsoft. They've been left beaten and crippled in the eyes of the general public. Large Customers seem to not be swallowing .NET.

Their behavior is inconsistent with the Trial Judge's ruling. Technically, by pursuing .NET, they are not observing the spirit of the ruling. If you get a ruling put on you by a court, you are supposed to observe what it says and correct your behavior, even if the execution order was stayed by the court pending appeal. The Judge did not set aside the ruling -- it's still there.

Because of this, any investment in Microsoft strategies by large enterprise customers are an unknown until the appeals court makes a determination. Microsoft is also setting itself up for a contempt order by doing this. The trial court told them to stay out of the internet business with their operating systems business unit. Their compliance has been illusionary with the court's ruling, and unless the appeals court vacates the ruling, they could be in big trouble.

If I were the DOJ, I would already be putting together an OFC for filing with the trial court. They are also doing the worst possible thing you can do while a case is on appeal, which is to ignore the trial court's rulings, and resorting to character assisination of the trial judge.

Elsewhere, approaching the entire problem from a different angle, Ren Haddock said, "I think part of the problem is that there are other things labeled DANGEROUS that actually do work fairly reliably (offhand, I'm thinking off the IDE config stuff..). Perhaps it needs to explicitely say 'This is broken and is gauranteed to destroy your data. Do not use it'. The 'DANGEROUS' label seems to suggest that it -may- destroy data, which leads to the 'it won't happen to me' mentality." Andre Hedrick replied historically:

DANGEROUS == GO_FOR_IT_DUMB_ARSE_SCREW_YOURSELF_WILDLY

This is the intent, when I put and started the DANGEROUS settings. Because the volitale nature of extreme alpha code in the beginning. However as time passed, people did not think it had meaning, but that is what it orginally was defined by me.

David Feuer agreed with Ren, the "Dangerous" label did not seem to be an absolute warning not to enable a given feature. Daryll Strauss suggested relabeling those features as "Broken", but Jes Sorensen replied, "I doubt it will make any difference whatever we write. I have seen several times how users enable every single option because 'they don't want to miss out on anything'."

If this was a business, and we were knowingly distributing software that was known to be dangerous, we would probably be risking legal action.

Why are we distributing such severely broken software? Heck, we seem reluctant to include reiserfs, a pretty high quality, supported file system. And we continue to distribute this !@#$%... There must be some strange agenda going on to limit the use of Linux.

But Horst von Brand replied that it wouldn't be legal, since there are prominent warnings displayed. He added, "It is just that NTFS has been in the kernel for ages, and rotted. Nobody has taken the time to remove it (would be a lot less than what has been wasted up to now discussing the matter here...)."

I compiled the Debian distribution of 2.2.18pre21 source on and for a AcerNote-950, with APM enabled.

All is fine except that I can reliably "oops" it simply by trying to read from /proc/apm (e.g. cat /proc/apm).

oops output and ksymoops-2.3.4 output is attached.

Is there anything else I can contribute?

The latitude and longtitude of the bios writers current position, and a ballistic missile.

Please boot 2.2.18pre24 (not pre25) on the machine and send me its DMI strings printed at boot time. I'll add it to the 'stupid morons who cant program and wouldnt know QA if it hit them on the head with a mallet' list

Neale did this, but couldn't see anything resembling a "DMI string", and Alan replied, "Ok your machine probably doesnt have DMI then. That unfortunately means its hard to identify the specific machine." After walking a brief staircase together, Neale came up with a patch to work around his buggy BIOS.

Fabien Ribes noticed that information on the status of Linux with regards to RFC 1122 (Requirements for Internet Hosts -- Communication Layers) was scattered throughout numerous files. He asked, "Is there a complete document showing RFC1122 status as a whole for a given kernel version ?" David S. Miller replied shortly, "No, unfortunately nobody has the time to do this." Andi Kleen added, "The RFC evaluation is also out of date and should be either redone or removed." David agreed, and said he'd remove all the "RFC1122 Status" comments from net/ipv4/*.c unless Andi wanted to fix it up. Andi replied, "Kill it ;)" David replied, "Done. Seriously, if someone wants to do this work please contact Andi or myself, we are willing to give some assistance." Fabien said he might have time to do some work on it; but there was no more discussion.

Steven Cole used kernel compilation time as a benchmark, and concluded that on uni-processor systems, 2.2.18pre26 was 3% faster than 2.4.0-test12-pre7 at building kernels. But he remarked with tongue in cheek, "However, the margin of victory is small enough that a recount may be necessary." He also added that he'd used gcc 2.91.66 (kgcc) to compile the 2.2.18 kernel used as the OS in the test, and gcc 2.95.3 for the 2.4.0 one used as the OS in the test. Several folks objected that kgcc would make a faster kernel than gcc, and that to be fair, the systems hosting the tests should be compiled with the same kernel. Steven replied with some new results, in which he showed that kgcc did indeed create slightly faster kernels than gcc. But rerunning one of his tests showed only a few second's improvement over the earlier one. He added consistently, "but I think we're getting into the pregnant or dimpled chad thing at this point." So his initial report seemed to stand, and there was a brief discussion of why 2.2.18 might be faster than 2.4.0. At one point Alan Cox remarked, "Its an interesting demo that 2.4 has some performance problems since 2.2 is slower than 2.0 although nowdays not much."

Later, Steven ran a similar set of benchmarks on SMP systems, and reported that for those systems, 2.4.0 was 2% faster than 2.2.18; Linus Torvalds replied:

Note that kernel compilation really isn't a very relevant benchmark, because percentage differences in this range can be basically just noise: things like driver version differences that show up, but impact different machines different ways (maybe one driver is better for certain machines, and worse on others. Things like that).

The setup you descibe is just too CPU-intensive, with little potential for truly interesting differences.

Steven had mentioned that in the SMP test, he'd "ran X and KDE 2.0 during the tests to provide a greater though reproducable load on the tested kernel." Linus suggested, in his same reply:

You might want to do the same in 32-64MB of RAM. And actually move your mouse around a bit to keep KDE/X from just being paged out, at which point it turns un-interesting again. I don't know how to do that repeatably, though, but one thing I occasionally do is to read my email (which is not very CPU-intensive, but it does keep the desktop active and also gives me a feel for interactive behaviour).

At that point the numbers are probably going to show more difference (and the variation is probably going to be much bigger).

Steven tried the same test again, doing a 'make -j3', moving the mouse around, and switching desktops a few times; and reported, "These results are even closer. The differences are so slight, that they are not statistically significant. Hmmm, maybe no news is good news in this case." Linus suggested:

Actually, do it with

make -j3 'MAKE=make -j3' bzImage

A single "-j3" won't do much. It will only build three directories at a time, and you'll never see much load. But doing it recursively means that you'll build three at a time all the way out to the leaf directories, and you should see loads up to 20+, and much more memory pressure too.

Steven tried this, and reported that 2.4.0 still finished 1.3 seconds faster than 2.2.18, and the system load stayed lower as well. There was no more discussion.

In the course of discussion, Alan Cox gave his expected timeline for 2.2.19. Regarding some possible changes, he said, "That wont be happening in 2.2 until 2.2.19 which probably means 6 months." Horst von Brand requested a quick 2.2.19, to include just the particular bug fixes under discussion, but Alan replied, "Shall I do a 2.2 release for every trivia. I think not. There is plenty to get into 2.2.19 already." End of thread.

Mark Symonds reported locked boxes with many "VM: do_try_to_free_pages failed" errors scrolling down the screen on 2.2.18; he added, "Something else I noticed is that the Load average is usually around 0.08, but when I let it idle for a few mins, just tapping the spacebar in a terminal will cause it to stop responding for 10 or so seconds with the load average skyrocketing to over 6. After that the system sometimes recovers and starts responding normally, other times it will die." Alan Cox replied, "Andrea's VM-global patch seems to be a wonder cure for those who have tried it. Give it a shot and let folks know." Mark and someone tried the patch and reported complete success, at which point Alan remarked, "I think Andrea just earned his official God status ;)" Another person asked if Andrea's patch would make it into 2.2.19, and Alan replied:

The question is merely 'in what form' . I wanted to keep them seperate from the other large changes in 2.2.18 for obvious reasons.

Andrea - can we have the core VM changes you did without adopting the change in semaphore semantics for file system locking which will give third party fs maintainers headaches and doesnt match 2.4 behaviour either ?

Andrea Arcangeli replied with some technical comments, and he and Alan went back-and-forth for awhile.

Rob Landley gave a pointer to a LinuxToday news article, and explained, "Scott McNealy has apparently been calling Solaris Sun's implementation of Linux. Trademark violation time." He quoted the article, which quoted Scott (Sun's CEO) as saying, "You people just don't get it, do you? All Linux applications run on Solaris, which is our implementation of Linux." Rob admitted that the source of the quote was questionable, but that assuming the accuracy of the quote, "this strikes me as a mondo trademark violation, and exactly the sort of thing the Linux trademark was designed to prevent. Solaris is NOT Linux."

There were several different takes on this. Rik van Riel said, "I wouldn't worry about this. It's only a question of time before people will start to ask him why Sun isn't shipping the "original Linux" but has their own, strange, version ;)" This sent Igmar Palsenberg into peals of laughter, but Rob replied, "Sure. But why HAVE a trademark if we don't enforce it? Grassroots support is always a wondeful thing, and educating the public is extremely important. Then again, what McNealy's trying to confuse his customers. Enforcing the trademark would therefore serve an educational purpose, wouldn't it? :)"

Elsewhere, Kevin A. Burton felt the Scott's remarks, even if accurate, looked like just an "off the cuff" remark, and were no cause for concern; but Rob replied:

Law isn't an all-or-nothing thing. Obviously this isn't worth a lawsuit. By itself it's not even close.

But sending an official letter asking them to respect the trademark counts as "defending the trademark" if it's abused in the future and we DO want to get serious about it. (Neutralizes this as a precedent slimy lawyers can point to of "Linux" being undefendable as a trademark and instead being a generic term.)

And if the pattern of behavior WERE to continue/get worse, having gone through the appropriate steps way back when (measured, proprotionate response to earlier incidents) makes a much firmer foundation for a lawsuit later.

And, because Sun's lawyers know that last point, they're fairly likely to take it seriously enough to let McNealy know that his course of action carries certain risks. (Remember that Meme Hacking talk, at the Fortune 500 it's all about reducing and managing risk.)

It's a bit like saying your cat's name when you see them up on the coffee table where they're not supposed to be. It's not the same as actually punishing them, just letting them know you're aware that they're doing it.

This does bring up an interesting situation.

The Linux community keeps saying that "Linux is a re-implementation of Unix."

This gets X/Open all pissed off at us, because Linux has not passed the qualification test suites which they use for branding. So we get around that by saying "Unix is a lot like Linux, except it costs a lot of money, comes in binary form, etc. etc."

Yet there is no real definition for "Linux".

Some people (the FSF for instance) say that Linux is just the kernel, but there are different kernels, with different patches.

There was even a Microkernel version of Linux called "MKLinux".

Others say that Linux is the whole distribution, but there are lots of distributions, all different (Red Hat, SuSE, etc.) There are different placements of files in the file tree.

I know from conversations with Linus that he anticipates having (perhaps) radically different kernels on top of "BIG IRON" machines, where the kernels (and the distributions) come from the "BIG IRON" makers.

The licensing of the Linux trademark has basically allowed someone to use the term "Linux" in their own trademark, but has done nothing to prevent someone from comparing their accumulation of code with "Linux", and nothing to define what Linux actually is.

If it is true that "all Linux applications work on top of Solaris", what standard prevents them from calling Solaris just another implementation of Linux? And should it?

From an ISV perspective, the more distributions of software that run their products binary compatible, the better off we are against Microsoft. If Linux does not handle the very high-end machines (yet), then why not let those applications run on Solaris? If people want to pay for Solaris, take the binary-only distribution from Sun and run it on that large iron, why not?

On the other hand, I think we need some type of definition to what is called "Linux". Perhaps this is where the Linux Standard Base might be appropriate.

Rob agreed with many of Jon's points, but still felt that "Sun is free to put out a version of Linux. But to call Solaris Linux is, in my opinion, going over the edge here and diluting the trademark." He gave a link to a post from Linus Torvalds explaining Linus' general stance on the trademark issue. He added, "If we said Linux was actually Solaris, Sun would be all over us with Lawyers. They'd have to protect their trademark. If Red Hat called its next release of Linux" [...] ""Red Hat Solaris", they'd get sued."


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

1.	30 Nov 2000 - 13 Dec 2000	(7 posts)	Problems With Drives From Onstream
2.	6 Dec 2000 - 12 Dec 2000	(7 posts)	linux-kernel News Gateway Problems
3.	6 Dec 2000 - 11 Dec 2000	(11 posts)	sysklogd Cleanup; Using Kernel Headers In User-Space Programs
4.	6 Dec 2000 - 14 Dec 2000	(15 posts)	Ethernet Module Update For The D-LINK DFE-530-TX Card In 2.2
5.	7 Dec 2000 - 11 Dec 2000	(76 posts)	Read-Write NTFS Support Broken And Should Not Be Used
6.	7 Dec 2000 - 12 Dec 2000	(13 posts)	AcerNote-950 APM Problems
7.	8 Dec 2000 - 13 Dec 2000	(18 posts)	Some Documentation Cleanup
8.	10 Dec 2000 - 15 Dec 2000	(28 posts)	2.0 Faster Than 2.2 Which Is Faster Than 2.4 (Except For SMP)
9.	13 Dec 2000 - 14 Dec 2000	(11 posts)	Timeline For 2.2.19
10.	13 Dec 2000 - 17 Dec 2000	(17 posts)	VM Problems In 2.2.18
11.	14 Dec 2000 - 16 Dec 2000	(16 posts)	Possible Linux Trademark Violation By Sun

Kernel Traffic #99 For 25 Dec 2000

By Zack Brown