Kernel Traffic #9 For 11 Mar 1999

By Zack Brown

Table Of Contents

• Printer-Friendly Format
• Text Format
• XML Source
• Introduction
• Mailing List Stats For This Week
• Threads Covered

  1.	28 Feb 1999 - 4 Mar 1999	(77 posts)	Panic Hunt
  2.	2 Mar 1999 - 4 Mar 1999	(19 posts)	Article On I/O Buffering And Caching
  3.	2 Mar 1999 - 5 Mar 1999	(47 posts)	Disabling Intel Serial Numbers; US History
  4.	2 Mar 1999 - 5 Mar 1999	(42 posts)	Undelete
  5.	3 Mar 1999 - 5 Mar 1999	(18 posts)	RAID And CONFIG_FILTER Troubles Under 2.2.2
  6.	3 Mar 1999 - 4 Mar 1999	(18 posts)	Trident To GPL A Sound Driver
  7.	3 Mar 1999 - 7 Mar 1999	(25 posts)	Buffer Overflow Attacks; Big Memory Machines
  8.	4 Mar 1999	(2 posts)	Upgrading To 2.0.37 On Red Hat 4.2
  9.	4 Mar 1999 - 7 Mar 1999	(15 posts)	Intel Not Releasing Specs On EtherExpress PRO/100 Server Adapter
  10.	4 Mar 1999 - 5 Mar 1999	(4 posts)	/proc Docs; Performance Of SMP Kernels Running On UP Systems
  11.	4 Mar 1999 - 7 Mar 1999	(21 posts)	CPU Quality
  12.	4 Mar 1999 - 5 Mar 1999	(12 posts)	Philosophy Of Kernel Development
  13.	4 Mar 1999 - 5 Mar 1999	(3 posts)	Some Explanation Of I/O Caching
  14.	4 Mar 1999 - 5 Mar 1999	(4 posts)	Scheduling On SMP Machines
  15.	5 Mar 1999 - 6 Feb 1999	(2 posts)	Socket Filtering Broken In 2.2.2
  16.	4 Mar 1999 - 7 Mar 1999	(16 posts)	Portable I/O Memory Access
  17.	5 Mar 1999 - 7 Mar 1999	(8 posts)	HP Begins Closed Port To Merced (To Be GPLed Eventually)
  18.	5 Mar 1999 - 7 Mar 1999	(7 posts)	Toshiba Spec And Licensing Silliness
  19.	6 Mar 1999 - 8 Mar 1999	(4 posts)	FAT Speedup
  20.	6 Mar 1999 - 9 Mar 1999	(37 posts)	Binary Module Famewar
  21.	6 Mar 1999 - 7 Mar 1999	(10 posts)	videodev/mm Fix
  22.	6 Mar 1999 - 9 Mar 1999	(6 posts)	Gnome CDROM Bug Uncovered

Introduction

Kernel Traffic has been reviewed: Positive Propaganda, Volume 4 Issue 5, has us sandwiched between a serious page about East Timor, and a light-hearted story called Linux Got Me Kicked Out Of Wal*mart by the same folks who do Positive Propaganda.

Someone wrote in, asking us to give a link to the archives for each thread we discuss here. We never mentioned this, but we've been doing that all along: just click on the title of each article, and you'll go directly to that thread's initial message in the archives at http://www.uwsg.indiana.edu/hypermail/linux/kernel/index.html. Unfortunately, the archives themselves are not well threaded (read: threading is completely broken). If anyone knows who we can talk to about that, please tell us or ask them to contact us. We'd like to help.

Mailing List Stats For This Week

We looked at 961 posts in 3642K.

There were 377 different contributors. 148 posted more than once. 136 posted last week too.

The top posters of the week were:

• 70 posts in 192K by (Alan Cox)
• 55 posts in 257K by Andrea Arcangeli
• 38 posts in 153K by Richard Gooch
• 32 posts in 118K by Alexander Viro
• 15 posts in 42K by
• Full Stats

1. Panic Hunt

28 Feb 1999 - 4 Mar 1999 (77 posts) Archive Link: "Kernel panic: can't push onto full stack"

Topics: BSD: FreeBSD, FS, SMP, Security

People: Alan Cox, Alexander Viro, Alexey Kuznetsov, Michael Merhej, Andrea Arcangeli

Alexander Viro, Alexey Kuznetsov, and Andrea Arcangeli took up the vast majority of this 5-day, nearly 80-post thread. Michael Merhej (who was also a significant voice in the thread) posted an interesting hang he'd been experiencing on 3 similarly configured machines. He asked what the error ("Kernel panic: can't push onto full stack") meant, and Alan Cox replied, "It means something very bad happened in a situation where a lot of file handles were being passed across sockets." He added, "I've been pondering this one (you are the third report I've seen). It basically implies a bug in the mark/sweep garbage collector, or a race of some kind." Alexander Viro confirmed the bug was a race and posted a short patch (cced to Alexey Kuznetsov). Two hours later he posted a revised patch after help from Alexey, who found another problem in addition to the race.

Andrea Arcangeli asked for some explanation; he thought Alexander's first patch had looked good. Alexander and Alexey both replied, Alexander saying, "Sockets waiting for to be accepted don't have associated struct file yet. Anyway, the second variant eliminates the need to allocate the stack which is Good Thing(tm);" and Alexey saying, "we may have up to 2*max_files unix sockets: not-yet-accepted ones are not associated with files/inodes" and "we could limit number of unix sockets by max_files, but it is still not complete solution: max_files may be decreased," and "using list is always OK, however it also requires reviewing af_unix.c: f.e. pending socket destruction must be blocked while gc is running." To that last, Alexander added, "Only on the marking phase. And there we cannot block. *If* it may happen within the marking phase we were equally deep in it with the old variant."

Michael Merhej initially thought his troubles were over, but then his machines started locking up again, and he had some private email with Alexander, who then wrote to the list, "Michael sent me the lis of oopsen for the second patch. All of them are in the same place and it looks, uhm, interesting." He proceeded to identify the file and function (fs/proc/array.c, get_stat()) where the problem showed itself, but couldn't get any farther than that. Andrea said he thought the problem was that "some (SMP) race in af_unix.c or garbage.c is corrupting memory."

Alexander posted jubilently, "Methink I found the sucker we have one place where the unix_socket is freed without kernel_lock hold. It is in unix_destroy_timer(). I'm adding a semaphore (unix_gc_marking). unix_gc() holds it during the mark phase. unix_destroy_timer() tries to get it, if it fails it postpones removal even more, otherwise it holds the semaphore while doing sk_free(). I hate voodoo programming and it's pretty likely to be only a bandaid, but if it will reduce breakage we'll get at least some hints on the nature of sucker." He also added a lengthy patch. But Alexey cried out, "Stop, stop, stop! To the time, when socket is destroyed from timer, it is dead. It is detached from hash tables, its queues are already destroyed etc. It is hold only to tell peer, that endpoint is dead and to die in piece."

Alexander asked, "Alexey, could you comment on test for tsk->dead in unix_accept()? Just what is tested there? It had been added in 2.1.124 and AFAICS there is no way to ->dead on a passed sock to be set. Was it just-in-case test or should it be unix_peer(tsk)->dead? IOW, if somebody did connect() and then close() before we accept() should we return this (hung) connection on accept()?"

Alexey replied:

Alexander added two more possible solutions:

But 25 minutes later, he wrote, "Darn. Screw #4 - it doesn't solve anything. Add #5: block on close() (maybe make it an setsockopt()-controllable)." He added, "BTW, from my reading of kern/uipc_userreq.c it looks like freebsd-hackers folks might be also interested in situation - I'm not on FreeBSD box, but from what I see in source they are also vulnerable..."

Andrea said Alexander's patch seemed to be working, and also that he'd "discovered a way to leak memory and cause the machine to stall completly in kernel mode for minutes as normal user. Waiting a bit more it will eat all memory and the machine will crash badly. It's a plain security issue." He posted a program to demonstrate the exploit, as well as a lengthy patch that grouped together all the unix domain socket fixes he was aware of (including Alexander's patches). And he put together a 2.2.2_arca4.gz which included unrelated fixes as well.

At this point they dove so deep they were lost from view. I could only snorkel around as they faded from sight. They stayed down a long time, but finally, Alexander came up and said:

2. Article On I/O Buffering And Caching

2 Mar 1999 - 4 Mar 1999 (19 posts) Archive Link: "OSDI paper - IO-Lite: A Unified I/O Buffering and Caching System"

Topics: BSD: FreeBSD

People: Alan Cox, Jim Gettys, Oliver Xymoron

Jim Gettys gave URLs http://www.cs.rice.edu/~vivek/iol98/ and http://www.cs.rice.edu/~vivek/vivekmsee/, called IO-Lite: A Unified I/O Buffering and Caching System, by Vivek Pai, Peter Druschel, and Willy Zwaenepoel, published in the 3rd Symposium on Operating Systems Design and Implementation (OSDI '99) Proceedings, New Orleans, Louisiana, February 22-25, 1999, pp15-28.

The paper describes a method of IO, already used in FreeBSD, which should result in significant performance gains.

Oliver Xymoron was intrigued, but felt Linux wouldn't see the gains FreeBSD saw. One subthread coming out of that was a technical discussion of performance gains and implementation details, while in another, Jan Vroonhof suggested that the whole thing could be done in user space. This seemed reasonable to Alan Cox, and others agreed. There followed a brief technical discussion of implementation.

3. Disabling Intel Serial Numbers; US History

2 Mar 1999 - 5 Mar 1999 (47 posts) Archive Link: "[patch] PIII/Katmai & FXSAVE support, disable serial-#, 2.2.2"

People: Richard B. Johnson, Ingo Molnar

Ingo Molnar posted a new version of his Katmai patch, including changes from various sources. He added that this wasn't the final version, but he wanted to make it available for developing. There followed a big discussion about the new Intel P3 serial numbers. Linux will disable the serial numbers, so the main question was, "could someone re-enable them from user-space?" A number of people were worried about this, while a number of others felt that there was no privacy in today's world anyway, so a serial number on our CPUs wouldn't make much difference. The following story from Richard B. Johnson is a fun hilight:

4. Undelete

2 Mar 1999 - 5 Mar 1999 (42 posts) Archive Link: "EXT2_UNRM_FL"

Topics: FS

People: Theodore Y. Ts'o, Mike A. Harris, Richard Gooch

The quest for the perfect undelete. This discussion comes up every once in awhile, on linux-kernel as everywhere else. On linux-kernel it can get a bit more interesting because the people talking about it actually try to find a good way to implement it. In this thread, a number of top developers hacked at it for awhile.

Theodore Y. Ts'o said, "It's not too hard to translate a unlink to a rename call, and move the file to some directory; but handling (a) undeleting the inode, (b) security so that users can't see other people's deleted files, and (c) automatically deleting "deleted" files when the filesystem needs space, all starts making the problem a lot harder...."

Richard Gooch said he wrote a userspace tool years ago to accomplish all that. Mike A. Harris objected, "And what if someone deletes using mc, or some other filemanager, or their own code? It isn't transparent. I'd rather see it in the filesystem myself," but Richard replied, "Write a wrapper for unlink() and use LD_PRELOAD. No need to bloat the kernel."

Ted agreed, but added, "It might be worth it for the kernel to add a wakeup to the undelete daemon telling it that space is low and it should remove some of the deleted files, but I'd want to see how well a strategy of polling every minute works (or doesn't work) before deciding whether the extra kernel bloat was worth it." He explained, "Someone deletes a large number of files on the system. Sometime later, some other user starts unpacking a kernel tree, and needs space. It would be nice for a daemon to notice that free space was getting critical, and for it to start really deleted files that were in the "trashcan" in order to make space. After all, when the user deleted the files, they're effectively stating that they don't want them anymore, and the undelete option is just as a saving throw. If they then logout for three months, if the space is needed for something more worthy, there should be a way for that space to be reclaimed automatically." Richard Gooch replied, "OK. Yeah, regular polling by the daemon could be used to see if you run out of space. Yep. Let's first see if a polling daemon is effective before hacking the kernel. The cost of polling should be really cheap, so doing it once a second or more should be OK."

5. RAID And CONFIG_FILTER Troubles Under 2.2.2

3 Mar 1999 - 5 Mar 1999 (18 posts) Archive Link: "2.2.2 two major problems"

Topics: Disk Arrays: RAID, FS: NFS

People: Mike Black, Alan Cox, Mark Lord, Andrea Arcangeli

Mike Black posted the following raucus flame:

Alan Cox replied to this, saying that the second problem had been fixed a couple weeks ago, and Mike could pick up the solution from the linux-kernel archives. To the first problem, he said, "Ok they've been working for pretty much everyone. Congratulations on finding a torture test,"

Mark Lord interrupted, with:

Romano Giannetti confirmed he also had problems, but hadn't said anything on the list because they weren't reproducible.

While this was going on, Mike Black posted some raucus praise under the Subject: 2.2.3-pre1+patch Success with RAID and DHCP:

He also posted the lengthy patch that allowed mke2fs on the RAID set.

6. Trident To GPL A Sound Driver

3 Mar 1999 - 4 Mar 1999 (18 posts) Archive Link: "which pci sound card does not have dropouts under load"

Topics: PCI, Sound: ALSA, Sound: SoundBlaster, USB

People: Alan Cox, Brian Gerst, Aaron Tiensivu

Thomas Mertes asked what would be a good sound card to use under Linux, given that some companies don't release their specs. His Soundblaster 16 Vibra from Creative is not really supported, due to the specs problem.

Alan Cox wrote:

There followed a brief discussion about problems with USB. Aaron Tiensivu pointed out that USBs passed most of the work to the CPU. Brian Gerst mournfully compared this to the WinModem problem, though Alan added, "Its a combination. Basically you get what the USB kit can do and the rest is a mix of software and the USB chips (they do all the DMA and the like for you including fairly hard real time output)."

7. Buffer Overflow Attacks; Big Memory Machines

3 Mar 1999 - 7 Mar 1999 (25 posts) Archive Link: "Linux Buffer Overflow Security Exploits"

Topics: Big Memory Support, Microsoft, Security

People: Sarah Addams, Oliver Xymoron, Rogier Wolff, Alan Cox, Tuomas Heino, Linus Torvalds, Stephen Tweedie

Sarah Addams said, "Excuse my ignorance, but would someone explain to me why Linux and other Unices are vulnerable to buffer overflow exploits? I suspect it's because the code, data and stack for a given process is kept in a single memory segment, but I'm not at all sure about that. If however, I'm right, would Linux Alpha, running on a Harvard architecture 21164, be immune from this weakness?"

Oliver Xymoron responded:

In a later post, regarding the fourth item above, he commented, "I'm going to rescind my statement that this is less common - most overflows occur inside library functions operating on stack variables in an application. This is actually worse - unless the library was compiled with Stackguard, you can't protect against it, as the exploit occurs when the library function returns rather than when the caller does," and added the interesting tidbit, "Stacks growing downward is not completely arbitrary, either. It's very convenient to have a known starting point for both code and data. Since code likes to run upwards, it makes sense to have code start near the bottom. Since the optimal way to put two growing structures (code+heap and stack) in a linear array is to start them at opposite ends and have them grow inward, the stack gets placed at the top. Less of a concern when you have ridiculously large address spaces like the Alpha, but still not arbitrary."

In response to Sarah's original post, Rogier Wolff reminisced:

Alan Cox, also responding to Sarah's original question about why UNIX is vulnerable to buffer overrun exploits, said, "Because like basically all computers you don't have hardware type and size tags on all pointers. There are approaches to reduce the probability of that error but reading and checking code is the most productive. Logic errors tend to be as big a problem."

Sarah replied with, "Isn't it the case for Intel 386 and up processors, as is true for other modern processors, that memory segments can be marked execute, read and/or write by a process running at a sufficiently high privilege level. So if you write your kernel to take advantage of these features, you could guard against the case where a buffer overflow is used to sneak code into an otherwise secure system?" She supposed her original question could be boiled down to, "Does a Linux (and/or other Unix) process inhabit a single read/write/execute memory segment?" to which Alan responded, "No. The executable image is read only or copy-on-write. The stack however has to readable (obviously) and x86 has a problem with page level permissions for execute only (it hasnt got them)." He remarked, "Forget about segments, intel has been trying to de-invent them since the 386."

Tuomas Heino demanded, "And how do you use more than 4 gigabytes of RAM on these boring Intel boxes _without_ segmentation? ;) [... and don't say "ram drives" - unless you have a new meaning for that," and that formed the subject of the rest of the thread.

Later on, in a different thread altogether, Linus Torvalds made this comment:

8. Upgrading To 2.0.37 On Red Hat 4.2

4 Mar 1999 (2 posts) Archive Link: "kernel 2.0.37 and old distro"

People: Alan Cox

Carrer yuri asked what he would have to upgrade (other than his binutils) on his RedHat 4.2 system, to use kernel 2.0.37. Alan Cox replied, Nothing. He also said he was trying to make sure it stayed that way.

End Of Thread.

9. Intel Not Releasing Specs On EtherExpress PRO/100 Server Adapter

4 Mar 1999 - 7 Mar 1999 (15 posts) Archive Link: "Intel EtherExpress PRO/100 Server Adapter"

Topics: I2O, PCI

People: Alan Cox, Marek Habersack, Deepak Saxena, Stephen Williams

Marek Habersack posted looking for a driver or for a tip on who to ask. Alan Cox replied, "I think it is a matter of either Intel or Divine Intervention. What I don't know is if that card is an I2O device. If so then in time the I2O code will handle it - check with Intel"

Marek came back with, "The datasheet on the Intel pages (http://www.intel.com/network/products/pro100int.htm) doesn't explicitly say whether it's an I2O device. It comes with an on-board i960 CPU, but I suppose it doesn't mean it's an I2O device :-)))"

Alan offered, "If you are feeling really brave you can boot my very early I2O patches kernel and see if that thinks its I2O. Its just about able to get as far as talking to an I2O device, setting it up for some subsets of devices and asking for the vendor information and printing it," when Deepak Saxena poured cold water on both of them, with, "The Pro/100 Server Adapter is not an I2O device. The 960 is just used to run the firmware for the card and do buffer mnagement functions under NT and Netware BorderManager. The Pro100 driver won't work since the driver has to go through the firmware and doesn't talk directly to the 82558 MAC chips is my guess."

Marek pined, "But the card works under M$ Winblows with the standard EEPRO/100 driver, so I presume it should work with the standard Linux EEPRO100 driver," to which Deepak replied, "Oh...that's different than. Does the kernel support pci-pci bridges? It's possible that if the 960 firmware isn't initialized by the the Pro/100 server specific driver, it just acts as a dumb PCI bridge...just an educated guess."

Stephen Williams came in with, "I've been trying to get programming information out of Intel for months now. I have a development kit that we use for our own i960Rx boards and would work dandy with this board, I just need a few more bytes of information to write a board support interface," and added, "I have a case # and everything. If anybody can shake loose the information I need, I can get the ball rolling." He also replied to Deepak's "educated guess", with:

10. /proc Docs; Performance Of SMP Kernels Running On UP Systems

4 Mar 1999 - 5 Mar 1999 (4 posts) Archive Link: "SMP on a UP system, and Hitchhikers guide to the proc file system?"

Topics: SMP

People: Christopher McCrory, Alan Cox

Christopher McCrory asked for docs on /proc and was pointed to /usr/src/linux/Documentation/proc.txt. He also asked about performance of SMP kernels running on UP machines, to which Angus Mackay said yes, there would be a performance hit. He went on:

Alan Cox added, "The SMP kernel wont run on some non SMP boxes, and is a bit bigger and slower, maybe 15% in real terms from experience. The question is whether 15% is worth the hassle of maintaing two kernel sets in your environment"

11. CPU Quality

4 Mar 1999 - 7 Mar 1999 (21 posts) Archive Link: "RH5.2 won't install on Cyrix"

People: George Bonser, Alan Cox, Bob Tracy, Denis Voitenko, Anthony Barbachan, Mike A. Harris, Rafael Reilova

Denis Voitenko's machine kept rebooting whenever he reached the "second level setup" message during installation. Alan Cox and George Bonser agreed that the problem was probably the CPU overheating. George had some workarounds:

Denis asked if there were a way to trick RedHat into thinking the CPU wasn't overheated. Rafael Reilova suggested he underclock the processor as much as possible, while Alan said, "If you managed to trick the chip into not noticing it had overheated and thus doing a thermal powerdown it would just damage itself."

Bob Tracy posted some advice:

Denis mused that maybe the best thing would be just getting generic Intel chips, adding "you get what you pay for, right?"

Anthony Barbachan replied, "their are plenty of both buggy and bad intel chips out there as well," and Mike A. Harris said, "Since when has Intel been known for providing chips that run cool? They never have to my knowledge."

Alan added:

12. Philosophy Of Kernel Development

4 Mar 1999 - 5 Mar 1999 (12 posts) Archive Link: "*sigh* Please give me something..."

Topics: Development Philosophy

People: Zygo Blaxell

A very frustrated Jeremy Hansen was having daily crashes with 2.2.2ac7 with raid patches. He complained that 2.2.2 should never have been released as 'stable'. In reply, Zygo Blaxell summed up the philosophy of the even numbered releases: "Later 2.2.x kernels will of course work for more and more people, but the early 2.2.x kernels are really only a week or two different from the late 2.1.x kernels. "Normal" users who rely on hard stability should wait until a real Linux vendor sorts out the bugs and shrink-wraps the kernel into a nice well-tested package for them. Everyone else will be busily banging on the 2.2.x until then."

One of the strengths of free software is that it's possible to have stability as a goal rather than a guarantee. Commercial venders have their reputation on the line, so they have to stand by their buggy products; while free software writers can persistently improve things.

13. Some Explanation Of I/O Caching

4 Mar 1999 - 5 Mar 1999 (3 posts) Archive Link: "90% mem for buff??? (2.2.2ac7 other not tested...)"

People: Kurt Garloff

An often repeated question:

Gregoire Favre noticed his buffers were huge, making it look as though all his memory was tied up. Kurt Garloff said, "this also puzzled me, when I started Linux hacking in 1994. You think, why does Linux need so much memory?" He explained, "You should look at it from the other side: There is hardware, CPU, RAM, etc. and Linux tries to make the best possible use of it. Now, provided no process needs your RAM, it would be just stupid to leave it unused. Linux uses it for buffering (caching) disk I/O and speeding up I/O operations this way. As soon as your processes need more memory, they will get what they ask for and the buffer will shrink, until it is only a few percent of total mem. Only then, Linux will start to page(swap) to disk."

14. Scheduling On SMP Machines

4 Mar 1999 - 5 Mar 1999 (4 posts) Archive Link: "Scheduler oddness"

Topics: SMP, Scheduler

People: Mathew G Monroe

Rui Sousa noticed that when running 3 similar processes on his SMP machine, one of them seemed to get the lion's share of the CPU time. He noticed that running 4 similar processes got rid of the problem. Mathew G Monroe replied, "Yes, on SMP machines an advantage is given for processes to stay on the same CPU (preventing cache thrashing). As such basically with three processes, you get one on a one cpu, and two processes on the second CPU. They will CPU jump a little, but it is discouraged by the scheduler to prevent worse overall preformance. So you endup with one process getting a lot more CPU time."

15. Socket Filtering Broken In 2.2.2

5 Mar 1999 - 6 Feb 1999 (2 posts) Archive Link: "linux-2.2.2 won't compile"

People: Tuomas Heino

Ingo Saitz was getting the error "dereferencing pointer to incomplete type" in /usr/src/linux/drivers/net/loopback.c, when doing 'make oldconfig' for 2.2.2; doing a 'make -ki' pointed him to /usr/src/linux/include/net/sock.h

Tuomas Heino replied, "It's a known problem: The socket filtering patches weren't properly merged in 2.2.2; disable socket filtering if you don't need it; if you need it then check out the mailing list archives for the million messages on the subject...]"

16. Portable I/O Memory Access

4 Mar 1999 - 7 Mar 1999 (16 posts) Archive Link: "user space writel() etc. in 2.2.2"

Topics: PCI

People: Vassili Leonov

Vassili Leonov wrote, "I'm trying to redo our LML33 (http://linuxmedialabs.com/lml33doc.html) card driver and configuration scripts and have run into the following: in the io.h file functions to read/write IO memory (writel(),readl() etc.) are only defined with __KERNEL__ macro defined. Under 2.0.36 that was not the case." He added, "I don't like setting __KERNEL__ for user space allications, besides it produces a lot of errors when I try to compile," and asked, "Q: what is the right way to access IO memory under 2.2.2?"

There followed a discussion of the technical issues involved. Finally, Vassili summed up, "OK, finally I am enlightened (by Alan and others). The story is that there is no portable solution for IO memory acces in current Linux. It is platform dependent in a non-trivial way."

He quoted a map posted by Alan:

17. HP Begins Closed Port To Merced (To Be GPLed Eventually)

5 Mar 1999 - 7 Mar 1999 (8 posts) Archive Link: "Linux/IA-64 (Merced)"

People: David Mosberger-Tang, Alan Cox, Larry McVoy, Gerard Roudier, Kai Henningsen, Andrea Arcangeli, David Mosberger

David Mosberger-Tang wrote:

Andrea Arcangeli's only comment was to quote the two lines, "we can't invite everybody to join the development" and "... "make real money from Linux won't mean that Linux developers will stop working together," to which Alan Cox replied, "Nod. But Intel are unlikely to risk AMD cloning their new chip before its out. Hopefully VA Research and others who have announced other ports (I assume they are seperate) will decide to work together though." He added, "If the entire rumour mill is correct there are IBM and SGI porting projects too 8). But then Linux/3090 was a rumour mill item that hasnt occured so who knows the real count."

Larry McVoy added, "There is one point which perhaps should be made more clear: if you are under NDA for IA-64 and you want to help with the IA-64 port, then you should contact David and coordinate with him. Just because you don't work at the same company doesn't mean you can't talk to each other about this port. I know of at least 4 companies who are all NDA'd on IA-64 and are all doing work on it and may or may not be talking to each other. If you are interested in contacts and have IA-64 NDA, let me know, I can put you in touch with the people inside the other companies."

Gerard Roudier gave the rye remark, "Times have changed. Seems Linux folk is now talking about NDAs without any flame," to which Kai Henningsen replied, "The important difference here, IMHO, is that the NDA is limited to the time period where the hardware isn't available." He added, "That's extremely different from the typical flame case where the hardware has been available for a while, but information is still available only under NDA and there's no hope the NDA will *ever* be lifted."

18. Toshiba Spec And Licensing Silliness

5 Mar 1999 - 7 Mar 1999 (7 posts) Archive Link: "Hard Drive Cache information"

Topics: Microsoft

People: Alan Olsen

Alan Olsen had the hilight of this thread, with, "Toshiba has started shipping their latest laptops in a plastic wrapper that states that by opening the wrapper you agree to the Microsoft Licence Agreement. (i.e. you cannot return the MS portions to get out of paying cash to Bill.) They seem to be sucking up to Microsoft in a big way."

The general concensus on the list was, Toshiba is not releasing specs, so boycott Toshiba till they get a clue. Sounds like a good idea to me.

19. FAT Speedup

6 Mar 1999 - 8 Mar 1999 (4 posts) Archive Link: "FAT speedup patch revisited for 2.2.1"

Topics: FS: FAT, FS: VFAT, Microsoft

People: Jukka Tapani Santala, Riley Williams

Jukka Tapani Santala posted this very interesting exposition:

Riley Williams found an interesting exception:

Jukka replied:

20. Binary Module Famewar

6 Mar 1999 - 9 Mar 1999 (37 posts) Archive Link: "Lets get this right (WAS RE:MOSIX and kernel mods)"

Topics: Binary-Only Modules, Clustering: Mosix

People: Larry McVoy, Richard Gooch

A straightforward flame war growing out of the MOSIX binary module issue. The most interesting thing to come out of it was that Larry McVoy and Richard Gooch, who were at each other's throats last week over Issue #8, Section #2  (24 Feb 1999: Real-Time Scheduling Flame War) issues, found themselves on the same side this time, to their great surprise. at one point Larry said, "I'm really giving myself a bad rep here, because I have to keep agreeing with Richard :-) But hey, when he's right, he's right, what can I do :-)"

21. videodev/mm Fix

6 Mar 1999 - 7 Mar 1999 (10 posts) Archive Link: "BUG in videodev.c [PATCH]"

People: Richard Guenther, Linus Torvalds

Richard Guenther offered a patch and said, "A bug in videodev.c lets you mmap device memory and free it via close() - this leaves you with a nice "Blanko" mapping of some memory. For example the bttv driver is vulnerable as it frees its buffer in close(). (The drivers itself cannot fix it, since they dont get the vm_area_struct)"

Linus Torvalds replied, "This patch looks like extra code to get around some other driver bug, and I'd much rather just see the driver fixed properly." In a later post he added, "I see what the problem is now: it appears that the driver has a completely unrelated bug, which is that it doesn't save away the file in the vma, which is why the system gets confused: it doesn't know that the mapping still holds on to driver resources." He gave his own fix, but replied to himself a few minutes later with, "Duh. Looking at the original patch, this was what the patch did, I was just confused by the other stuff. Never mind, the patch looks fine (except all the confusion has just convinced me that I should do this in the mm layer so that it can never happen again, and so that drivers don't even have to care)," and replied to himself again half an hour later with, "done. Adding it in one place allowed me to remove it in 17 other places (and then not apply the videodev.c patch because now it is no longer needed)." He added, "One less cause of hard-to-find bugs."

22. Gnome CDROM Bug Uncovered

6 Mar 1999 - 9 Mar 1999 (6 posts) Archive Link: "cdrom eject fails in 2.2.2-ac7"

People: Keith Bennett, Jens Axboe

Keith Bennett posted noticed that 'eject' no longer worked for him. Jens Axboe told him to upgrade to eject 2.0; he did so and started getting "device or resource busy" errors. Jens asked if Keith had a cd player in the background, and Keith said, "doh! okay, you win. it seems that gnome doesnt kill off its panel applets when you remove them from the panel. time to write a bug report to gnome (i'll just add it to the list)"

Sharon And Joy