Thanks go to Leena Heino and Tom Davey for catching an HTML bug that caused an end-comment tag to show up where it wasn't wanted. Thanks, folks!
Some folks have written me asking how to find the latest KC news now that the right nav bar is gone. These can all still be found on the Linuxcare Homepage or the Kernel Cousin News Page.
David Weinehall initially took over the 2.0 series with Alan Cox's blessings
in
This week he announced 2.0.39-pre6; apparently -pre5 had some IDE breakage. He intended pre-6 to fix only those breakages, deferring other fixes until -pre7 and later. Two replies came to this. Ville Herva reported an oops with the old 2.0.37, to which there was no reply; and Rask Ingemann Lambertsen reported that he couldn't find 2.0.39-pre6 on any of David's directories in the kernel archive repositories. David replied that he'd messed up somehow, but that the patch should be available now. End Of Thread.
This previously came up in
This week, Ramon Garcia Fernandez said, Traditionally, Linux only supports async i/o with sockets and
terminals. You can use select on several handles to wait until pending input
is available on any of them (not exactly async); or you can use fcntl/sigio
and the kernel will tell you when input is available.
But he added
that a remark from Ingo Molnar on Slashdot had seemed to suggest that
asynchronous disk I/O with these tools ('select' and 'fcntl/sigio') was also
possible in 2.4; he asked if this were true, and Stephen C. Tweedie replied,
The kernel has async block device and file
IO support already --- it uses that sort of thing for file readahead, for
example. There isn't an exported async IO api for user applications yet,
although we're working on one. Kernel internal modules such as TUX can
access the async properties of the page cache if they want to.
And
Jeff V. Merkey added, NWFS has a very good
Asynch IO API for Linux AIO. You can get the code at 207.109.151.240. I already handle all the
buffer head allocations and returns and locking issues with the Linux
kernel. The file block.c has generic functions for all Linux versions
2.0/2.2/2.4 with a consistent asynch IO interface that runs across all
Linuxes. The code is all GPL, so you can pull it apart and use it anyway you
want.
Matthew Dharm reported that his DAC960 RAID controller had stopped working
somewhere between 2.4.0-test1 and 2.4.0-test4. During boot, as soon as the
kernel began to initialize the controller the machine would oops with a null
pointer dereferenced in the swapper. Matthew couldn't capture the oops, but
he explained that it happened every time the kernel tried to check the
partition on boot before mounting it, and it also happened regardless of
whether the driver was compiled directly into the kernel or only as a
binary. Jens Axboe replied, This is a known problem.
It happens because the DAC960 driver tries to use the block queue _before_
calling blk_init_queue(). I have informed Leonard about the problem, so he
is aware of it and will fix it. I saw him at OLS today, so it probably won't
get fixed within the next couple of days ;)
and Leonard N. Zubkoff
posted a patch and explained, The DAC960
driver in 2.4.0-testN is currently out of date and I will be sending an
update as soon as I verify that the next release works. The above problem
was actually already fixed in the 2.4.6 driver on my web page, but changes
to 2.4.0-test4 broke compilation. If you need a temporary fix for the
moment, please apply the following patch to the 2.4.6 driver from my web
page.
End Of Thread.
This was a long and bitter series of threads, in which Andre Hedrick was very upset and agitated through pretty much all of it. He had noticed that a benevolent root user writing to an IDE drive (something one might not generally expect to be dangerous to hardware), could wipe or even physically break the drive, if a small miscalculation were made in the data sent to the drive. He reported that this was true for all versions of Linux, and over the course of threads added that since the data in question was only a few bytes long, any simple exploit such as a small buffer overrun, could be enough for "Joe six-pack hacker" to take advantage of the weakness and destroy the drive.
However, in order to avoid giving away the details of how to do this, Andre felt the need to be somewhat oblique in his initial descriptions of the problem, and as a result many folks got the idea that he was simply concerned with security, to which they replied that there were so many ways for root to trash a system already, that it wasn't neccessary to include Andre's patch in 2.4; 2.5 would be soon enough.
Linus also rejected the patch on the grounds that the changes it made to the guts of the driver were too extensive for a code-freeze. Andre felt that this was not only a true fix, but a very important one that could significantly embarrass Linux as being a 'trash your hardware' OS. At one point he argued:
even priviledged users can not be allowed to send disk level distructive commands.
YES/NO ??
The subsystem needs to protect itself and the hardware from general abuse. In order to do that you must construct a superset (or complete set) of commands that to get blanket access must be a complied option and user is at their own risk. The default should be able to accept all commands and reject the harmful ones. Currently you could issue a modified setfeature used in configuring drive speed and destroy the drive or device.
The object is to protect this from happening even if you are ROOT or have stolen ROOT priviledges.
Does this help explain the issue or should I provide a "disk2brick.c" program to make the point clearer? This will vaporize a drive to the replacement level. Yes you can to that today!
Later he amended, I used a bad word of choice. I
can not DISKTOBRICK. But can genrate code that will attempt and may have
success. Regardless do you want access to such attempts available in the
kernel? Unchecked?
At one point Chris Kloiber confirmed Andre's report and the patch to fix it,
saying, I know it's true. I have run the
disk-destroyer program. Twice. I compiled a 2.4.0-test5-pre2 kernel with an
earlier version of Andre's patch and actually ran the disk-destroyer program
as a test. Andre specifically did not include the fry-your-drive codes in
the test program, but on the first try it sucessfully hosed the MBR and
partition table (my /dev/hda1 was/is swap, so I don't know how much of that
went bye-bye too). After a fresh install of Red Hat 6.2, I (glutton for
punishment that I am) recompiled 2.4.0-test5-pre2 with the latest patch (has
it been restored to www.kernel.org?) and now my system can survive the
disk-destroyer (The drive still makes god awful noise when run, but no
permanant damage occurs). I captured the output of the disk-destroyer and
sent it to Andre with a list of my hardware (mobo & drive models) so he
could further refine the patch.
This and other reports were brushed aside by various folks, who reiterated
that if someone had root access, they could damage the system however they
pleased. Horst von Brand replied to Chris, That
"disk-destroyer" just overwrites the partition table, something that can be
done in many easier ways. No real proof of the existence of the mythical
DISK2BRICK ATA command (that would in any case work only for certain
brands/models) that would make all this a real threat has been put forward.
No Windows/DOS virus/troyan has made use of this mythology either (and there
_have_ been instances of destroyed hardware, or close enough, in recent
history).
Eventually Andre started replying "Thanks for the vote of no confidence" to his patch's detractors, and began calling for the discussion to end. The discussion continued however, and various other arguments were put forward. Some folks pointed out that it was really the hardware that was broken already, if it allowed a simple out-of-spec command to destroy it. Andre countered this by saying that even if the hardware was poorly designed, the kernel should prevent itself from accidentally taking advantage of that.
The discussion raged back and forth for a long time, with neither side
giving an inch, and in many cases talking directly past each other. Many
people failed to grasp the scope of Andre's report, while Andre in turn did
not appreciate the counter arguments folks gave him. To give an example of
the kind of misunderstandings that ran rampant throughout the entire series
of threads, at one point Andre, extremely agitated by this time and very
frustrated, asked, Why is this such a big fight?
Does everybody want the kernel to be able to screw itself just by
blinking?
To which Oliver Xymoron replied, No, of course not, but we also don't want to make large changes to
the kernel to paper over a hole that we can't cement closed.
I
interpret Oliver as referring to the fact that root will always be able to
do lots of damage, and that to take away just one of those possibilities was
to "paper over" the problem, since to truly "cement" it would involve
putting many more restrictions on root. But as far as I can see, Andre
misinterpreted Oliver as saying that Andre's initial bug report was the one
that could not be cemented over. And to that idea, Andre replied, Here is you damn steel-plate-of-armor! I can close this
hole completely and you will never know the difference.
Eventually Andre boiled over completely, giving this one-line reply to
several different posts: Here is your SECURITY
HOLE! JOE-SIX-PACK-HACKER can fry your butt.
To one of these,
Stephen Frost replied, Will you *please* wake up
and realize that it makes no difference if it can fit into a buffer overrun
or not? That does not mean *anything* since you can almost always fit the
code neccessary to gain a root shell to the machine in the same
space.
At one point, Andre threw up his hands and said:
At this point I have no interest in publishing a finished patch to TASK and allow people to have fuller and more robust control over the kernel.
Basically screw the project!
But would you like to know the predictive write caching of a given drive to optimize things like the BLOCK_ELEVATOR, basically make it intellegent. You know I can do this for SCSI but screw that project too!
At another point, Andre said:
Screw your hardware! Since all of you are so damn smart and know the ATA-ATAPI specification, you are not sensible enough to see that I showed you that it can be violated. This violation of the standard, which none of you have the membership to vote on, is what I was trying to point out.
The reason why you can not do this level of destruction in Microsoft is that it does not have a HOLE the size of a MAC TRUCK! There is no one to blame for this, but I should have found it earlier. Now that it is found something needs to be done.
Since most of you POMPUS SCSI users are down playing the point you have no room or business to comment on a subsystem that you do not use. I base this because if you were using ATA you might think twice before calling NIMBY. It has been clearly pointed out that you have a problem of the same level, but the hole is smaller and harder to work through.
Since 90% of Linux depends on the ATA subsystem being stable and safe, all I will claim is that it is stable.
Nice to see that those with the biggest mouths fighting me on the issue are as big an ASS as me pushing the issue. I am glad to have the company of ASSHOLES as big as me debating the issue.
A lot of people told Andre at various points throughout the thread to calm
down. Bob Taylor was one, and advised, BTW, you seem
to lose your temper all to easily. Count slowly to (some number) while
taking a deep breath between each count. :-)
At one point Victor Khimenko, after being entirely opposed to the patch, admitted that for some extremely rare configurations, the patch might be valuable, though he doubted that anyone actually used systems with that configuration. Bartlomiej Zolnierkiewicz felt there might be some out there somewhere, but Andre replied:
No Bart,
Let them eat cake ............
The patch has been pulled .........
Linus Torvalds got into the debate toward the end, when James Sutherland
observed, IF capabilities can be used to block
this (and similar), and Andre's "sanity checking" for ATA is added, then
surely it *IS* possible to prevent root screwing the HDD (without replacing
the kernel, at which point all bets are off, of course).
Linus
replied:
What's the point?
If the system is secure, then adding sanity checking to the ATA code makes no difference: nobody gets to do anything improper anyway.
If the system is not secure, then adding sanity checking to the ATA code makes no difference: people who could use the ATA thing can use other things that are much more insidious.
The mechanism that everybody wants is _already_ there. It's called "permissions". No new driver code necessary.
If those permissions do not work, then they don't work, and adding last-minute band-aids makes no difference.
Just as a comparison, look at Windows. It takes the opposite approach: it has no real seurity, but a LOT of band-aids to avoid the "obvious" holes. Leaving it wide open.
To this, James replied, The "security" aspect
of this is largely a red herring, I suspect; at best, fixing this will make
a malicious root marginally less damaging. The real issue is just that the
kernel is accepting unvalidated parameters from userspace, and shooting
itself in the foot with them. MS took a fair bit of flak, IIRC, for doing
this with WIN32K.SYS in NT4. Do we now expect higher standards of design
from NT than Linux? :-)
To which Linus replied:
What validation?
The OS doesn't even know what the commands do. They are undocumented. And they vary from drive to drive.
How do you expect the OS to validate the drive firmware update commands for every drive manufacturer?
In short, should we
- know every single drive, know every command it can take, and do all of this inside the OS
OR should we
- move this policy into user space, and potentially have programs that know what different drives can do, and upgrade them the proper way
I think the thing is fairly clear. If you want "the OS" to validate the parameters, then you should create a user-mode program that validates the thing.
Basically, Linux already validates everything it _can_ validate. Sure, it could also verify that only "approved" commands are sent, but what about the undocumented yet potentially useful ones?
Let's take a hypothetial example (you judge on just _how_ hypothetical it actually is): imagine that you have a drive that can be made to refuse to read certain removable media based on where the drive was purchased. Imagine that this was actually done in firmware, and that there was a way of overriding it. Imagine further that you moved, and you wanted to make the drive read certain removable media in the new location, using undocumented commands..
Should the kernel block those commands because it doesn't know what they do?
Or should the kernel assume that "Oh, he has the permission to do this, then sure, I'll let him do it..".
Note that everybody has gotten very lathered up about the fact that you can kill certain hardware. Guess what? This is neither new nor very exciting. Look at your XFree86 configuration file some time, and read the warnings in the documentation. And ruminate on it. A monitor can be quite a bit more expensive than your harddisk.
Firthermore, destroying your harddisk may be the most _polite_ thing that can be done to you. Quite frankly, I'd personally rather have a dead harddisk than have all my data on that harddisk be siphoned back to an intruder.
A dead harddisk you might get a refund for under the warranty. Your credit card information (or your browsing habits or copies of your personal emails) made available all over the place might be more of a bother.
"There are worse things than death". Even with harddisks.
Andre replied to this with a third choice in addition to Linus' two above:
Or validate the commands listed in the SPEC for the default enable interface, and grant unrestriced access to all command with a compile option plus a sysctl flag that defaults in the off.
You will then no longer violate the usage of the SPEC by default. You will preserve the drive warrenties, and protect the commerial distribution market place for being liable for intent.
Specifically, it is public record that a distribution shipping without a taskfile filter in ATA and SCSI (I have this now) to carry copablity of knowingly with intent to sell product that allows no protection for improper calls to the hardware.
All you have to do is provide a default approved filter, and include the non-default option to disable the filter to not violate unix policies of no-policies and cover linux and distrubtors from issues that can be deemed actionable.
Upon the user disabling the command-filter, everyone is cleared of any and all issues that can be deemed actionable, and make the individual responsible for their actions and not you or the maintainers copablity.
This is all I want.........not to be sued in the future for decisions that are not mine to be made.
Linus replied:
I can live with that. The simple switch-statement that you posted as an alternative "minimal" approach would work for me. Preferably with an opt-out (sysctl-like thing).
What I do NOT want to see is big re-organizations around this, especially considering that this is not something new. Simple.
This satisfied Andre.
Folkert van Heusden wanted to use the on-board RAM from his PCI card as
regular RAM. Jeff Garzik remarked that this was likely to be very slow
compared to regular RAM; Timur Tabi agreed, and added, if you insist, ... the easiest way is to create another Zone, and
modify the zonelist structures to use that Zone as a backup zone for
ZONE_NORMAL. Then, whenever you run out of normal RAM, it will allocate your
PCI RAM.
He also suggested moving the discussion over to the
'mm-linux' mailing list.
Lenart Gabor also replied to Jeff, suggesting that the PCI RAM might make good swap space, and Mads Bondo Dydensborg replied:
I know that SCIos (http://sci-serv.inrialpes.fr/) does something like this: They use SCI networks to do distributed shared memory in a cluster. Then, if a node in the cluster wants to swap, it first checks if there are free memory in the distributed shared memory. If there is, it swaps to these pages. AFAIK they have found that it is quite a bit faster then disk. The SCI controllers are on the PCI bus, but the memory is main memory of a remote node. This means that they will have to travel 2 pci busses, the network and the main memory bus of the remote node. Only going through the local pci bus should be quite fast compared to this. (Slow compared to main memory, yes).
SCIos is based on Linux (is a set of patches) - maybe there are some code in there that could inspire someone.
Folkert also replied to Jeff, saying, it's
less slower than swapping to harddisk. Especially for the system I want to
implement this. That one has harddisks doing 1MB/sec. I think access trough
PCI can do better then that.
Jeff replied that using the PCI RAM as
swap was perfectly feasible, and mentioned that patches had appeared on
'linux-kernel' at one time or another, though he couldn't give an exact
reference.
Folkert mentioned that Linux was aware of several different kinds of RAM, and suggested that he might try to set the PCI RAM to the "slow" variety (he also mentioned that the patches Jeff referred to might be Folkert's own previous attempt at this). Several days later, Jamie Lokier explained:
The kernel has "zones" for different kinds of RAM that can be accessed in different ways, but it still assumes they are more or less the same speed. This means that if the PCI RAM were allocated for a user space page, it would stay continue using the PCI RAM even if it's used heavily.
If instead you use the PCI RAM as a ramdisk and swap to it, any program which makes heavy use of a page will cause the page to stay in main RAM where it should remain.
The thread ended there.
Tigran Aivazian felt that by putting some inode data in a union, 4 bytes
could be saved from the inode structure on 32-bit machines, and 8 on 64-bit
machines. Linus Torvalds didn't think the saved space would be noticable
enough to warrant the change, and remarked, You'd save more by making the quota stuff go away when quotas
aren't enabled..
Later he explained his reluctance more fully:
Unions are imho only acceptable when they implicitly know their own type. The in-kernel example of this is the inode per-filesystem thing. An inode has a filesystem-specific part, and there is no way any other filesystem can access it except by a major bug somewhere.
Any union that needs code like
if (xxx->type == yyy).. ....
is a design mistake.
I don't think you'll find all that many unions in Linux. And I don't think we should add new ones..
Joseph Elwell asked which was the best forum for reporting GPL violations
regarding the Linux kernel. He reported that Virgin Connect sold a web
device that shipped with Linux preinstalled, but that there was no mention
of this fact, the GPL, or any location of sources in the docs. He gave a
link to a
discussion board where the problem was discussed, and the the VirginConnectMe home page; as
well as the Merinta home page, the
company selling the machine to Virgin. From the Merinta press
release he verified that the machines were running Linux. Finally, he
concluded, I like the idea of all these new
Internet devices coming out, running Linux. But it worries me that they'll
all ignore the GPL as they go. Making it more difficult for fututre
improvements in the kernel code.
Mike A. Harris replied that the best place to report that kind of thing was linux-kernel. He went on:
It's the best place indeed. It might not be the most appropriate place, but if you are looking for results, it generally reaches the widest audience of insane bigmouths (and I don't exclude myself) that will fight to no end arguing about it and causing a big public stir. This causes it to get seen on Slashdot and the rest is history. If the FSF doesn't jump in, they likely will eventually, or someone will try and establish communications with the offending vendor.
It usually results in one of:
- The vendor eventually realizes they're screwed and does what is required to get themselves out of the mess legally.
- The vendor pulls the product
- Darth Vendor joins dark side of the source. (releases code)
Either way, a huge pissing match occurs that goes on for at least a month or so, but it usually ends up getting the job done, so it is worth it.
The pissing match did not occur in this thread, which petered out fairly
quickly. Other discussions of GPL violations were covered in
Robert H. de Vries posted a patch and reported, The __SI_CODE macro shifts its argument 16 bits to the left while the
only argument used is already shifted 16 bits to the left. In this way no
bits are left on a 32 bit architecture. Hence this patch, which removes the
superfluous shift.
Linus Torvalds replied, Sounds like the _users_ of __SI_CODE should be fixed, rather than
__SI_CODE. The new definition of __SI_CODE doesn't make much sense, in my
opinion.
But Robert explained, If I
would change the user, that would trigger an avalanche of changes, while my
proposition is limited to just one definition.
He gave a single
(lengthy) example, and concluded, I thought
I was being clever in finding the simplest patch. But then again you
decide.
Linus replied, After having
looked at that mess, you're right. Let's just change __SI_CODE.
Derek Martin asked if there were a web page tracking the list of things
needed before 2.4 could come out. Alan Cox posted his latest list of items,
which he said was out of date but still useful. The last time he posted his
list was in Dont mail me updates, find someone else to maintain it.
Linus
Torvalds replied:
Note that this part of the status page really is worth some attention.
Alan doesn't have the time to maintain 2.4.x issues. Which means that right now nobody is really doing it. I have a kind of general "map" in my head, but that isn't nearly good enough..
Would somebody be interested in taking this over?
Note! It's more than just maintaining a list. It's realizing what are show-stoppers, and what are just problems that should be fixed. It's trying to work with people in trying to get enough information to get a good list of problems, but it's also trying to confirm that the problem still exists or is fixed.
It's also possibly maintaining potential fixes: keeping track of who has suggested what fix (possibly with an actual patch). Sometimes the fixes aren't actually usable as-is due to other issues, but even when they are not usable they can be supremely important for people who try to fix the same thing in a acceptable manner.
It's also good if you're respected by people already, or at least think you can work with people without making them hate you.
In short: it's important. And it's something that Alan did for both 2.0 and 2.2. Nobody can quite live up to "being Alan", but hey, if you don't like long beards you may be just as heppy knowing that.
Anybody?
Theodore Y. Ts'o volunteered, with, I'm
willing to take this over. Note that unless Alan can give me his secret of
making clones of himself, I can't necessarily read every single message on
linux-kernel; so folks will need to send me mail explicitly if they want to
make sure I'm going to read it. I'll try to skim postings on linux-kernel,
but like most kernel developers, that isn't necessarily the most reliable
way of making sure I'll read something.
Kai Henningsen suggested
putting the list up on a web page for easy reference. At this point, Linus
said:
A number of people have suggested to me that using one of the automated bug-tracking systems would be nice.
I don't like using them myself, but some people do. Whoever would be the maintainer (and hey, Ted has been around since pretty much the beginning of Linux, so I'd certainly be inclined to trust him) would make his own choice on _how_ he does it. A web-interface sounds like a good idea. It boils down to how much work/help it is, and personal taste of the developer in question.
There was no reply here, but under the Subject: 2.4 status page, lightly updated, Theodore reported:
OK, this is my first attempt at publishing Alan's 2.4 todo list. It's been lightly updated so far, but I *know* that there's large parts of this list which are out of date.
So if you know that a particular problem has been dealt with, could you please let me know? Especially if your name appears next to the item as the one who reported the problem, or the kernel subsystem maintainer who's working on the issue.
I'll be publishing another version which will hopefully be a bit more up to date, and better at reflecting reality.
He posted the list:
- Should Be Fixed (Confirmation Wanted)
- IDE fails on some VIA boards (eg the i-opener)
- Floppy driver broken by VFS changes. Other drivers may be too (Stuff gets called after _close now - unload race possibly too)
- Fbcon races
- Fix all remaining PCI code to use pci_enable_device (mostly done)
- Capable Of Corrupting Your FS
- E820 memory setup causes crashes/corruption on some laptops[**VERY NASTY**]
- Use PCI DMA by default in IDE is unsafe (must not do so on via VPx x<3)
- Data corruption on IDE disks (Generic PCI DMA and SiS support (Steven Walter)
- Security
- Fix module remove race bug (mostly done - Al Viro)
- access_process_mm oops/lockup if task->mm changes (Manfred) [user can cause deliberately]
- Boot Time Failures
- AHA29xx driver appears to stomp other cards (may be BIOS)
- AHA27xx is broken (maybe 28xx too)
- Use PCI DMA 'lost interrupt' problem with some hw [which ?] (NEC Versa LX with PIIX tuning)
- HT6560/UMC8672 ide sets up stuff too early (before region stuff can be done)
- Crashes on boot on some Compaqs ? (may be fixed)
- Boot hangs on a range of Dell docking stations (Latitude)
- In Progress
- Dcache threading (Al Viro)
- Merge the network fixes (DaveM)
- Finish I2O merge (Intel/Alan)
- Exploitable leak in file locking (Willy)
- Restore O_SYNC functionality (Stephen) - core code and ext2 done
- Obvious Projects For People (well if you have the hardware..)
- pci_socket crash on unload
- DEFXX driver appears broken
- NCR5380 isnt smp safe
- DMFE is not SMP safe
- Make syncppp use new ppp code
- Fix SPX socket code
- Merge the 2.2 ServeRAID driver into 2.4
- Merge the current Compaq RAID driver into 2.4
- Fix Exists But Isnt Merged
- Update SGI VisWS to new-style IRQ handling (Ingo)
- 64bit lockf support
- Support MP table above 1Gig (Ingo)
- Dont panic on boot when meeting HP boxes with wacked APIC table numbering (AC)
- Scheduler bugs in RT (Dimitris)
- HFS is still broken
- AIC7xxx doesnt work non PCI ? (Doug says OK, new version due anyway)
- Fix boards with different TSC per CPU and kill TSC use on them
- Floppy last block cache flush error
- TB Multisound driver hasnt been updated for new isa I/O totally.
- To Do
- mount crashes on Alpha platforms
- Check all devices use resources properly
- Tulip hang on rmmod/crashes sometimes
- Devfs races, Sockfs (removing NULL ->i_sb stuf) (Al Viro)
- Debian report that the gcc 2.95 possibly miscompiles fault.c or mm/remap.c (Perl script available from Arjan)
- Fix further NFS races (Al Viro)
- Test other file systems on write
- Audit all char and block drivers to ensure they are safe with the 2.3 locking - a lot of them are not especially on the open() path.
- Stick lock_kernel() calls around driver with issues to hard to fix nicely for 2.4 itself
- PCMCIA/Cardbus hangs, IRQ problems. (Basically unusable - Hinds pcmcia code is reliable)_
- Keyboard/mouse problems (may be fixed ?)
- Fix mount failures due to copy_* user mishandling
- Fix default mount behaviour to disallow repeat mounting
- Check all file systems are either LFS compliant or error large files
- Issue with notifiers that try to deregister themselves? (lnz)
- Mount of new fs over existing mounted filesystem should return an error unless forced (Andrew McNabb, Alan Cox)
- Kernel build has race conditions when building modversions.h (Mikael Pettersson)
- To Do But Non Showstopper
- Finish 64bit vfs merges (lockf64 and friends missing)
- Go through as 2.4pre kicks in and figure what we should mark obsolete for the final 2.4
- Union mount (Al Viro)
- Per Process rtsigio limit
- iget abuse in knfsd
- Some people report 2.3.x serial problems
- USB hangs on APM suspend on some machines
- PCMCIA crashes on unloading pci_socket
- ISAPnP IRQ handling failing on SB1000 + resource handling bug
- DVD-RAM is apparently not working for write currently (Rogier Wolff)
- Parallel ports should set SA_SHIRQ if PCI (eg in Plip)
- Devfs compiled in but not mounted causes crap for ->mnt_devname of root (Al Viro)
- Compatibility Errors
- Xterm broke in 2.3.99pre6 (FIONREAD/select loop)
- Probably Post 2.4
- per super block write_super needs an async flag
- addres_space needs a VM pressure/flush callback (Ingo)
- per file_op rw_kiovec
- Drivers In 2.2 not 2.4
- To Check
- Check O_APPEND atomicity bug fixing is complete
- Protection on isize (sct) [Al Viro mostly done]
- Mikulas claims we need to fix the getblk/mark_buffer_uptodate thing for 2.3.x as well
- Network block device seems broken by block device changes
- VFS?VM - mmap/write deadlock (demo code seems to show lock is there)
- rw sempahores on page faults (mmap_sem)
- kiobuf seperate lock functions/bounce/page_address fixes
- Fix routing by fwmark
- Some FB drivers check the A000 area and find it busy then bomb out
- rw semaphores on inodes to fix read/truncate races ? [Probably fixed]
- Not all device drivers are safe now the write inode lock isnt taken on write
- File locking needs checking for races
- Multiwrite IDE breaks on a disk error [minor issue at best]
- ACPI/APM suspend issue - IDE related stuff ?
- NFS bugs are fixed
- Chase reports of SMB not working
- IRDA calls get random bytes before random is set up
- Some AWE cards are not being found by ISAPnP ??
- SHM segments not always being detached and destroyed right ?
- RAM disk contents vanishing on cramfs (block change) and bforget cases
- ACPI hangs on boot for some systems (Are there any cases left ?)
- Fixed
- Incredibly slow loopback tcp bug (believed fixed about 2.3.48)
- COMX series WAN now merged
- VM needs rebalancing or we have a bad leak
- SHM works chroot
- SHM back compatibility
- Intel i960 problems with I2O
- Symbol clashes and other mess from _three_ copies of zlib!
- PCI buffer overruns
- Shared memory changes change the API breaking applications (eg gimp)
- Finish softnet driver port over and cleanups
- via rhine oopses under load ?
- SCSI generic driver crashes controllers (need to pass PCI_DIR_UNKNOWN..)
- UMSDOS fixups resync (not quite done)
- Make NTFS sort of work
- Any user can crash FAT fs code with ftruncate
- AFFS fixups
- Directory race fix for UFS
- Security holes in execve()
- Lan Media WAN update for 2.3
- Get the Emu10K merged
- Paride seems to need fixes for the block changes yet
- Kernel corrupts fs and gs in some situations (Ulrich has demo code)
- 1.07 AMI MegaRAID
- Merge 2.2.15 changes (Alan)
- Get RAID 0.90 in (Ingo)
- S/390 Merge
- NFS DoS fix (security)
- Merge the RIO driver
- Fix Space.c duplicate string/write to constants
- Elevator and block handling queue change errors are all sorted
- Make sure all drivers return 1 from their __setup functions (Done ?)
- Enhanced disk statistics
- Complete vfsmount merge (Al Viro)
- Merge removed-buf-open directory stuff into VFS (Al Viro)
- Problems with ip autoconfig according to Zaitcev
- NFS causes dup kmem_create on reload (Trond)
- vmalloc(GFP_DMA) is needed for DMA drivers (Ingo)
- TLB flush should use highest priority (Ingo)
- SMP affinity code creates multiple dirs with the same name (Ingo)
- Set SMP affinity mask to actual cpu online mask (needed for some boards) (Ingo)
- heavy swapping corrupts ptes (believed so)
- pci_set_master forces a 64 latency on low latency setting devices.Some boards require all cards have latency <= 32
- msync fails on NFS (probably fixed anyway)
- Find out what has ruined disk I/O throughput. (mostly)
- PIII FXSAVE/FXRESTORE support
- The netdev name changing stuff broke GRE
- put_user is broken for i386 machines (security) - sem stuff may be wrong too
- BusLogic crashes when you cat /proc/scsi/BusLogic/0 (Robert de Vries)
- Finish sorting out VM balancing (Rik Van Riel, Juan Quintela et al)
- Fix eth= command line
- 8139 + bridging fails
- RtSig limit handling bug
- Signals leak kernel memory (security) [FIX in ac tree]
- TTY and N_HDLC layer called poll_wait twice per fd and corrupt memory
- ATM layer calls poll_wait twice per fd and corrupts memory
- Random calls poll_wait twice per fd and corrupts memory
- PCI sound calls poll_wait twice per fd and corrupts memory
- sbus audio calls poll_wait twice per fd and corrupts memory
- IBM MCA driver breaks on Device_Inquiry at boot
- SHM code corrupts memory (Russell)
- Linux sends a 1K buffer with SCSI inquiries. The ANSI-SCSI limit is 255.
- Linux uses TEST_UNIT_READY to chck for device presence on a PUN/LUN. The INQUIRY is the only valid test allowed by the spec.
- truncate_inode_pages does unsafe page cache operations
- Fix the ptrace code to be back compatible and add a new PTRACE call set for getting the PIII extra registers
- EPIC100 fixes
- Tlan and Epic100 crash under load
- Fix hpfs_unlink (Al Viro)
- exec loader permissions
- Locking on getcwd
- Loopback fs hangs
Linus replied to item 2.1 (Capable Of Corrupting Your FS: "E820 memory setup causes crashes/corruption on some laptops[**VERY NASTY**]"), saying:
This should be fixed as of -pre5. I finally got a hold of a laptop that did this.
Please, anybody that had random hangs/oopses that went away if you specified the memory size by hand with the "mem=xxx" boot option, test if 2.4.0-test5 works without the workaround..
Peter Enderborg replied to item 14.70 (Fixed: "Loopback fs hangs"), giving an exploit:
Sorry to say this. But the fs loopback is not fixed, or this some other bug fixed but than i have shown before. This an example. This kills my 2.4.0test5 system, an Intel PII SMP box. Im out of the office so I can only verfiy that i still exist on my machine.
This work is 2.2.14, but test[2-5] systems stops running without any messages.
Create an big image.
dd if=/dev/zero of=/someware/dosfs.img bs=64k count=10000
Create an msdos filesystem on the image. (Im using dosfstools-2.4) I have also done this with ext2 and get the same results.
msdosfs /somewhere/dosfs.img
Mount it.
mount -o loop /somewhere/dosfs.img /mnt/mymountpoint
Do the bad thing...
dd if=/dev/zero of=/mnt/mymountpoint/bigfile.foo bs=64k
Wait....
After a while the system can not create process and dies. A difference with 2.4.0test4 is that the filesystem is less corrupted with test5. And sync command not complete during the dd on the loopback device.
Steve Dodd replied, There are several deadlock
issues, and only one (the tq_disk problem) has been fixed so far (by
disabling plugging). I spent sometime looking at this, and I can't see any
obvious 'quick fix' solutions.
Elsewhere, Andi Kleen replied to item 3.1 (Security: "Fix module remove race
bug (mostly done - Al Viro)"), saying, It is not at
all done, there were some quick hacks for some file system objects, but the
general problem for zillion of other modules is still unsolved.
Alexander Viro didn't reply to this directly, but he replied to the same
item (and a number of others) in Theodore's list. To item 3.1, he said,
Already done: everything that exports
file_operations, fb stuff, procfs stuff. Not yet: TTY, ldisc, I2C,
video_device. Hell knows: network devices.
Alexander also reported that item 5.1 (In Progress: Dcache threading (Al
Viro)) was done. He also reported for item 8.4 (To Do: Devfs races, Sockfs
(removing NULL ->i_sb stuf) (Al Viro)), Sockfs - done. Removing bogus checks still isn't. Devfs races...
somewhat went down, but there's still a lot of them.
To item 8.8 (To Do: Audit all char and block drivers to ensure they are safe
with the 2.3 locking - a lot of them are not especially on the open()
path.), he remarked, What about the open() path?
They have (or grab) BKL there, so it should not be something special. Now,
read() and write()...
Alan replied, They dont
all get open right either ;) And yes a lot get read/write wrong or assume
incorrectly that single opener == single threaded read/write.
Alexander was surprised by that, and wondered aloud where he had "fscked
up", but Alan replied, You didnt. These have been
broken since 2.0 or earlier. Especially the read/write assumptions. These
arent things Al broke but things that never worked right ever.
Elsewhere, under the Subject: Updated 2.4 status/todo list, Theodore posted the latest list, and gave a URL to its location on Sourceforge. He also said:
everyone and his brother has approached me suggesting that I use their favorite bug tracking system. The answer which I'm giving folks is that for now, trying to get the information into a sane state is far more important than the mechanism of which bug tracking system to use. At the moment, the hardest parts of the problem are:
- Figuring out when Linus has applied a patch that fixes a particular item on the bug list.
- Determining when someone complains whether it's a real bug or not, and if so, how important is it.
- Ditto for when someone posts a patch.
- Figuring out what Alan meant by descriptive items such as "Check all devices use resources properly" (If anyone has a copy of Vulcan Mind Melds for Dummies, let me know. :-)
There was a bit more discussion.
Joe Pranevich announced:
I'm not sure if this has been discussed yet, I'm not completely caught up with the current kernel list. However with the pending release of Linux 2.4, it may be time to bring this up again.
I've created a rough draft (intended for discussion only!) of a press release for Linux 2.4, if we decide to go with one. Greg Smart and Albert Cahalan attempted this for Linux 2.2 but I don't think anything came of that work -- now I've decided to step up and make a fool of myself for Linux 2.4. :)
Please take a look at this and let me know what you think. There's probably someone on this list who actually knows what to do with a press release, it's quite a bit beyond my experience. Feel free to edit this as appropiate.
Oh, and I stuck a small plug for my "Wonderful World" document at the end. For a final version, we would want to point that at a good resource for more information about the release-- I'm a bit biased in this respect.
The 2.2 press release was covered in
Not discouraged, this week Joe posted his draft:
LINUX KERNEL 2.4 (DRAFT!)
The Internet, August XX, 2000Linus Torvalds and the kernel development team would like to announce the immediate availability of Linux 2.4, the latest revision of the popular open source operating system kernel. This update brings increased scalability and performance to all Linux users, in addition to new hardware support.
Notewothy Features:
- Enterprise Ready! Linux 2.4 includes changes that make it even more ready for Enterprise environments. This new revision supports up to 64 gigabytes of RAM, allows files to be larger than 2 gigabytes, supports many more simultaneous processes, and has been largely rewritten to take better advantage of systems with multiple processors.
- Cutting-edge hardware support. Linux now supports Itanium, the 64-bit Intel hardware soon to be released as well as the S/390, an IBM mainframe, and SuperH, often used in WindowsCE handhelds. Linux 2.4 improves support for Intel and Apple desktop and server hardware, in addition to Compaq servers based on the Alpha processor, Sun Sparc systems, MIPs systems, and other platforms.
- Linux is now even better suited for desktop environments with a new resource manager and support for USB and Firewire hardware. Additionally, Linux 2.4 also improves support for PC Cards (PCMCIA) and legacy "Plug-and-Play" cards.
- Rewritten network layer to be faster than ever before, especially on multiprocessor hardware. This new layer brings to Linux the flexibility and power formerly available only with expensive routing hardware.
- Support for version 3 of the popular NFS filesystem for sharing files in UNIX-like environments.
- Linux 2.4 includes special enhancments for webservers including a kernel-level web server and "wake one" support for speedier page serving with all popular web servers, including Apache.
- Logical Volume Manager for easy administration of disk space, including adding, deleting, and resizing disk slices on the fly.
This update is already available to advanced users through multiple kernel mirrors (ftp.kernel.org) Although no timeframes have been announced at this time, all current Linux distributors will be updating to this version of the kernel within the next several months.
Linux is developed by a online team of programmers headed by Linus Torvalds, a resident of Santa Clara, CA. Linux has been developed using the open source methodology which provides for source code and peer review at all stages of development. It is because of this system of openness that Linux has grown to be the most successful non-corporate operating system to date.
For more informatoon, please consult www.linux.org for a list of other Linux-related websites. More information on the new features in Linux 2.4 can be found in the "Wonderful World of Linux 2.4" document, available ...
Linux is a trademark of Linus Torvalds.
Daniel Stone also replied to Joe:
I think you should mention:
USB and FireWire - possibly appealing to the multimedia market, etc? Note the high proliferation of USB Zip drives, etc, so you could tout this as how it's great that we've got all the k-whrad standards.
Netfilter - I think I mention this to everyone I talk to about Linux 2.4. Stateful inspection, totally extensible, separate conntrack/NAT.
Jim Dennis also replied to Joe with lengthy commentary on the press release.
To item 1, Jim objected to the phrase "largely rewritten" as being a bit of
an overstatement. He explained, The SMP from 2.0 to
2.2 was "largely re-written." Most of the SMP locking code through 2.3.x has
been refined. I gather that the network devices and code path have been
"unserialized."
Jim also moved item 4 to be just below item 1, since unserialized net is more interesting in the server/enterprise
context.
He then added several items under that one:
- The new netfilter code replaces "ipchains" with the most flexible and modular packet filtering available.
- Policy based routing and quality of server (QoS) queueing and packet scheduling allows Linux systems to precisely control the flow of data through the system and into and out of your networks.
- FreeS/WAN and CIPE (available via international patches) provide kernel level support for transparent network cryptography.
- These (previous three) features make Linux the ideal kernel for building custom routers.
- Support for very high speed (gigabit) ethernet and other (FDDI, HIPPI) network interfaces.
To Joe's item 2, Jim added, Let's not forget
StrongARM/ARM, MIPS, 68k (including the Coldfire and Dragonball processors
in that family). These are used in many embedded systems (including many
PDAs). (Palm Pilot is Dragonball, moving to StrongARM?)
After Joe's item 3, Jim added several more bullet points:
- Linux is also well suited to many laptop, mobile and embedded applications. There is additional support for Transmeta's new line of "Crusoe (TM)" low-power consumption x86 processors which are powering web pads and long running "work all day" laptops.
- ACPI support builds on the advanced power management (APM) features from earlier kernel versions.
- The new Linux kernel now has integrated PCMCIA and Cardbus support (long available as an "add-on" patch). Also included is support for a number of wireless networking products and protocols, for "untethered" convenience.
To Joe's item 6, Jim remarked:
The Linux developers sarcastically acknowlege Mindcraft and thank them for their efforts in helping us identify the need for these improvements.
Also the "kernel-level web server" is better described as a kernel level web "accelerator." That is more accurate, and it is less likely to scare off business users who have already chosen a web server/daemon.
Finally, after Joe's item 7, Jim added a final bullet point (though he acknowledged it to be an oversimplification):
- "Capabilities" support extends the UNIX security model and allows Linux to provide more fine-grained access to system privileged. The "capabilities bounding set" further allows the administrator to "lock down" their system and prevent persistent changes, even in the face of "rogue" applications.
There was no reply.
Aaron Macks asked if it were possible to fool a UP kernel into behaving like
an SMP system; in other words, he asked, was it possible to have the
scheduler keep two queues and alternate them? Jeff Dike replied, There isn't now, but there will be in the not-too-distant
future. The user-mode port (see http://user-mode-linux.sourceforge.net)
can do this. I had SMP turned on and more or less working around 2.3.26. It
shouldn't be a big deal to turn it bad on, fix the bugs, and get it working.
Once that's done, you can start it up with "ncpus=2" or "ncpus=32", and you
get that many virtual processors.
Richard B. Johnson also replied to
Aaron, saying, You could have two (or more)
schedulers. However, this would not replicate nor even emulate two CPUs. A
single CPU can only do one thing at any instant. Two or more CPUs can do as
many things as there are CPUs. Some shared resources have to be
single-threaded with SMP, but otherwise a lot of activity can be done in
parallel.
Borislav Deianov also replied to Aaron, and suggested the fair scheduler. He gave what he
called his standard pitch, Fairsched is a
hierarchical fair CPU scheduler. Processes are divided into groups and each
group receives guaranteed CPU time allocation proportional to its weight.
The standard scheduler is used to schedule processes within a group. It can
be used to divide CPU time fairly among users or for more flexible CPU time
allocation on busy compute servers.
He added that Rik van Riel had
also written a variant that
was less flexible but significantly simpler. Bartlomiej Zolnierkiewicz asked
if 'fairsched' would one day allow users to choose a scheduling algorithm
for each group of processes, and Borislav replied, Actually this feature was present in fairsched's predecessor QLinux
(http://www.cs.umass.edu/~lass/software/qlinux/).
Dropping it simplified the code quite a bit and I didn't think it's that
useful.
Daniel Marmier posted a small patch to take out some code from
'include/linux/interrupt.h' that saved and restored flags. He felt the code
wasn't necessary because "hard interrupt requests" (hard IRQs) could not be
re-entered by other IRQs. Since the code was not in danger of being
re-entered, the flags were not in danger of changing and thus did not need
to be saved and restored. But Linus Torvalds explained, No, hard-irq's _can_ be re-entered. One hard-irq cannot re-enter
itself, but you can have _different_ irq's enter each other. As such, to
avoid deadlock in on the local CPU the current code is needed..
Stuart MacDonald asked, if hard IRQ A entered hard IRQ B, which in turn
entered hard IRQ A again, then hard IRQ A would have re-entered itself. But
Linus replied that while it was possible for A and B to enter each other, it
was not possible for them to subsequently re-enter themselves, because
We use the interrupt blocking hardware to make
sure that as long as irq A is running, further instances of irq A are
blocked. OTHER interrupts can still happen.
Tigran Aivazian replied
that he thought this was only true if SA_INTERRUPT was passed with the
interrupt (in which case the IRQ would be atomic not only with regard to
itself, but also to other interrupt handlers as well), as was the case with
2.2; but Linus explained:
SA_INTERRUPT is deprecated, as it fundamentally cannot work with shared interrupts (or at least they all have to _agree_ on SA_INTERRUPT, which basically means that you have to know exactly the type of sharing. Ugh).
And non-shared interrupts are _definitely_ deprecated, unless the hardware really forces you to use them. That kind of hardware is getting quite rare. Thank God.
That said, SA_INTERRUPT still works, but it's really only meant to be used for the timer handler (you don't want the timer to be interruptible: it's fast, and at least the SCSI layer historically wanted the timer to tick _while_ a SCSI interrupt is active, so you must not have a SCSI interrupt interrupt the timer, because if that happens..)
Vinay Vernekar asked how to open and read a file from within a driver. As far as he knew, normal file operations like fopen() couldn't be used within drivers. Theodore Y. Ts'o gave a link to the rocketport driver and replied:
The best way to do this is to do it in a user-mode program which is run out of an /etc/rc.d script, which uses ioctl()'s to download the firmware into kernel. This allows you to have much better error recovery and timeout handling than if you try to do this in the kernel.
For an exmaple program of how to do this, see the rocketport driver, especially how the loadrm2 program loads the Rocketmodem II firmware. There's some clever code there which allows multiple modems to be downloaded in parallel to speed things up. Feel free to steal it for your project; it's under the GPL.
Ashok Raj also suggested looking in the 'khttpd' code, which he said had plenty of examples. But Richard B. Johnson expounded at length:
The easiest way, and the way which will always work in the future, is to provide open() close() and ioctl() in your driver.
After the driver is installed (insmod) upon bootup, you execute a user-mode program that opens the device and sends file-data to the device via ioctl(). Your ioctl() routine in your driver puts this stuff in the right place inside your hardware and finishes initializing the device. The sysV-init scripts can be modified to do this automatically. You could, of course do the same thing using write(), but ioctl() allows you to pass function parameters so your startup code might do something like:
fd = open("MyDevice", O_RDWR);
file = open("MyBinaryJunk", O_RDONLY);
ioctl(fd, MYDEV_WAKEUP);
read(file, buf, len);
ioctl(fd, MYDEV_UPLOAD_WINDOW0, buf);
ioctl(fd, MYDEV_OPEN_WINDOW1);
read(file, buf, len);
ioctl(fd, MYDEV_UPLOAD_WINDOW1, buf);
ioctl(fd, MYDEV_.... etc.
ioctl(fd, MYDEV_START);Another way, is to make a 'C' array of the data that you need to put into your hardware. You can make a simple 'C' development tool that reads data from your file, converts it to text the compiler understands, and you include this during compilation. This has at least two major problems. The first is that you have to recompile to update your hardware-code. The second is that some code may be very large. This stays within the kernel when the module is installed and wastes kernel space.
You can't deallocate an array that the compiler initializes.
The last way, and the way I don't recommend, is to actually open and read the file from kernel space. This is complex because your driver needs to borrow a "process context" in order for file I/O to work. The file-system was designed to run from a user's data area (segment) and, for a file-descriptor to actually mean something, it has to be associated with a process. This can be done and I am sure that others will point you in that direction. However, what works today might not work for the next kernel version.
I wrote such a driver about a year ago. It seemed to work after I got a lot of help. However, even though the file was closed after the read, I was never able to unmount '/'. This means the next boot was a long fscking wait.
Ripping that up, and using user-mode access via ioctl() created a stable driver with the minimum of resident code.
Elsewhere, Jeff Garzik also recommended finding a user-space solution,
though he added, If you must do it in the kernel,
just use normal Unix syscalls... Inside the kernel, they are called
sys_open, sys_read, etc. Make sure the code calling those functions doesn't
mind if the called functions sleep.
Theodore objected, I wouldn't recommend that approach at all. First of
all, sys_open means you're messing with a process's file descriptor table,
and if another process can get at the fd table (i.e., because of a clone
system call), they may be able to cause mischief for the kernel (the fd can
get changed to be something else, etc.). Secondly, sys_read()/sys_write()
assumes that it will be reading and writing into user memory, not kernel
memory. There are games you can play to get around this, but such approaches
are fragile and complicated, and not what I'd recommend.
For CML2's initial announcement and discussion, see
This week, Eric S. Raymond announced:
The latest version is always available at http://www.tuxedo.org/~esr/kbuild/.
Release 0.7.4: Wed Jul 26 12:07:47 EDT 2000
- Randy Dunlap has certified the USB configuration.
- 'x' and 'q' reversed in curses and tty modes. 'q' now matches the semantics of the Tk Quit menu entry.
- We no longer write FOO=n in defconfig; this turned out to break a large number of ifdefs in old-style makefiles in the Linux kernel tree.
That third bullet item means that CML2 will not be able to do the right thing and support passing around partial configs until about 300 lines in various Makefiles are changed. Sigh...this may mean I put off issuing 1.0.0 until after CML2 has been accepted into the tree and those changes get made,
There are currently a couple of minor look and feel issues in the Tk interface, but no known bugs.
There was no reply, but elsewhere under the Subject: CML2 0-7-5 is available, he announced:
Release 0.7.5: Sat Jul 29 05:34:59 EDT 2000
- Sychronized with 2.4.0-test5
There was no reply.
Linus Torvalds announced Linux 2.4.0-test5, saying:
There's a 2.4.0-test5 kernel out there. The diff is pretty huge, to a large degree due to a bttv driver syntactic split-up and due to the NLS forward-port from 2.2.x.
Other notable bugfixes:
- the buggy Toshiba (and possibly others) BIOS memory reporting thing is fixed. Just ignore RAM that the BIOS reports in the 640k-1M range. The BIOS is confused.
- Manfred Spraul found and fixed a SMP TLB invalidation problem with threads.
- various architecture updates (arm, ia64, sparc, sh..)
- MD driver cleanups
- Toshiba floppy controller problem workaround
- updated DRI code (works with XF86-4.0.1)
- various driver updates (ToPIC CardBus should work, ide updates, etc)
- "kfree_s()" is gone. It hasn't existed for several years, but people still used it. No more.
- USB driver updates and fbcon cleanups
- various othe rupdates I've repressed.
Be happy.
There was no reply.
This was first covered in
Now, Kai Schulte asked for a variable to be returned to the code, because
'zImage' required it. He added, my good old 2MB
386SX terminal won't be amused if I ask it to load a bzImage ;)
Stephen Frost asked if Kai would give 'bzImage' a try, and Kai replied,
Why would you try? The compressed image will load
fine but there won't be any memory to decompress into, so it'll grind to a
halt.
H. Peter Anvin (who had led the earlier charge to get rid of
'zImage') replied, No, it will grind to a halt
because of a hard-coded limit (in setup.S, I believe.) It is currently set
to 2MB for zImage and 4MB for bzImage. I suspect those values are completely
arbitrary; trying without it would be interesting.
Kai agreed, there
was no reason bzImage couldn't work in 2MB, and said he'd give it a try. A
couple hours later he replied to himself, It does
:) There must be some other memory location that isn't being initialized,
though. Rebooting without hardware reset causes it to reboot continuously
right after the decompression - not quite what you'd expect from an embedded
system ;)
Elsewhere and a bit earlier in the discussion, Stephen remarked, It was my understanding that anything that zImage worked
on bzImage would work on.
Mike Castle explained:
They're HOPING for that.
There is currently a call out to find all machines that work with zImage but not bzImage so they can make bzImage work on them and then get rid of zImage.
Apparently one was found here.
They really really want zImage to go away. Rather than trying to get zImage to work on this particular computer again, I'd suggest concentrate on trying to get bzImage to work.
Here, Alan Cox brought the hammer down, mentioning, zImage wont go away. You cant boot a bzImage kernel on a 2Mb system
such as a low end embedded AMD board.
A couple posts down the line,
H. Peter concluded the thread with, Saying
"zImage won't go away" may be true (although I definitely wish it wasn't
so), but boot loaders probably will start to drop zImage support, because of
the hideous pain it takes to support them cleanly in a way that makes sense
at all. SYSLINUX simply load them high and copy them down before starting
the kernel -- anything else is too painful.