Kernel Traffic #270 by Zack Brown
[email protected] Sat, 07 Aug 2004 01:38:59 -0700
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <[email protected]> |
Kernel Traffic #270 For 7 Aug
By Zack Brown
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Introduction
* Mailing List Stats For This Week
* Threads Covered
1. 29 Jun - 8 Jul (16 Logging Firmware Errors During Boot
posts)
2. 2 Jul - 8 Jul (20 orinoco Update; Trouble Splitting The Patch
posts) For Kernel Inclusion
3. 4 Jul - 14 Jul (45 Possible XFS Data Corruption After Improper
posts) Shutdown
4. 5 Jul - 8 Jul (51 Linux 2.6.7-mm6 Released
posts)
5. 8 Jul - 14 Jul (22 Support For Boot-Time Splash-Screen In
posts) Software Suspend
6. 8 Jul - 9 Jul (3 Serial ATA (SATA) Status Report
posts)
7. 8 Jul (1 iswraid Updated For 2.4.26
post)
8. 11 Jul - 13 Jul (29 Linux 2.6.7-rc1 Released; Some Discussion Of
posts) Release Policy
9. 14 Jul (12 Status Of ipw2100 Wireless Driver
posts)
10. 14 Jul (17 Memory Hotremoval For 2.6.7
posts)
11. 14 Jul (1 kexec Update For 2.6 x86 And PowerPC
post)
Introduction
If anyone knows of a company looking for a talented writer with scripting and
other abilities, check out my r?sum? (resume.html) . I've done API
documentation with accompanying developer guides, and I'm published monthly as
a Contributing Editor in Linux Journal (http://www.linuxjournal.com/) and a
Columnist in Linux Magazine (http://www.linux-mag.com/) . I do my own creative
writing on the side, and have many strange writing- and communication-related
interests such as Labanotation. I also play a mean game of chess. I'm located
in San Francisco, and would prefer to work in that area; but for the right
offer I'd consider moving to a new location. I am both a US citizen and a
French citizen, making me eligible to live and work anywhere within the
European Union, as well as in the United States.
Mailing List Stats For This Week
We looked at 1537 posts in 8647K.
There were 446 different contributors. 231 posted more than once. 145 posted
last week too.
The top posters of the week were:
* 77 posts in 297K by Andrew Morton
* 59 posts in 290K by William Lee Irwin III
* 48 posts in 289K by Adrian Bunk
* 35 posts in 198K by Con Kolivas
* 29 posts in 116K by Greg KH
* Full Stats
1. Logging Firmware Errors During Boot
29 Jun - 8 Jul (16 posts) Archive Link: "[PATCH] [2.6] PPC64: log firmware
errors during boot."
Topics: Spam
People: Linas Vepstas, Paul Mackerras, Jake Moilanen, Greg KH, Hollis Blanchard
, Nathan Fontenot, Dave Hansen
Linas Vepstas said:
Firmware can report errors at any time, and not atypically during boot.
However, these reports were being discarded until th rtasd comes up, which
occurs fairly late in the boot cycle. As a result, firmware errors during
boot were being silently ignored.
This patch at least gets them printk'ed so that at least they show up in
boot.msg/syslog. There are two other logging mechanisms, nvram and rtas,
that I didn't touch because I don't understand the reprecussions. In
particular, nvram logging isn't enabled until late in the boot ... but
what's the point of nvram logging if not to catch messages that occured
very early in boot ??
Paul Mackerras replied, "As for printk'ing the errors, it is annoying and it
seems of somewhat dubious benefit to me, given that it is just incomprehensible
hex numbers that can go on and on. There has to be a better way. Putting it in
nvram seems like a better option to me. I don't know of any reason why we can't
use nvram quite early on." Jake Moilanen remarked, "We can initialize nvram
very early, but we shouldn't discard an event stored in nvram until rtasd is up
and can pull the event out as it might have been the error that took the system
down on the previous boot. We could probably start rtasd up a little earlier,
but I'm not sure it buys us that much." close by, Linas agreed in part with
Paul:
Yes, well, you'll be hard-pressed to find a lover of the hex format
anywhere. Lets review the history of the design decisions that got us to
this point. I think a better solution might then become evident.
-- Originally, these binary messages from firmware were decoded in the
kernel, and printed out in 'plain english'. However, there were problems:
1) the format of the binary kept evolving; I think we are now up to version
6. 2) the need for supporting version 6 and *all* of the earlier versions
lead to dreaded kernel bloat. For the current user-space decoder:
# wc *.c *.h
2207 7056 67959 total
-- So the decision was wisely made to move this all to user-space. But what
shall the communications link between user-space and kernel be? Somebody,
somewhere, I know not who or why, decided that they should go into syslog.
And so here we are.
How else could we do this? I have never had to architect a kernel-to-user
data communications interface, so I don't know what the alternatives are.
We could queue them up to some file in /proc, which user-space reads. Or
maybe /sys instead ?? Maybe a stunt with sockets? Some new device in /dev/
that can be opened, read, closed? How should the user space daemon indicate
that its picked up the message and doesn't need it any more? Write a msg
number to a /proc file? Maybe each individual message should go in its own
file, and user space just rm's that file after its fetched/saved the
message. I dunno, I think any one of these could be whipped up in a jiffy.
Convincing the user-space to use the interface might be harder.
Pick one. If it can be coded in under a day, I can volunteer to do that.
Greg KH thought the whole issue was moot, and that Linas should just "use
syslog or netlink like the whole rest of the kernel does. Don't reinvent the
wheel again, please." Paul also said to Linas, "Netlink is the usual solution
to this sort of problem. I think it would be reasonable to printk RTAS error
events with a severity of fatal and maybe even of error. Warnings and events
should just get sent to rtasd." Hollis Blanchard said, "I asked about this
before, and was told that there is no way to determine the severity of an event
without doing full parsing of the binary data. I'd be thrilled to be wrong..."
Nathan Fontenot replied:
Gettting the severity of an RTAS event is possible, and not too difficult.
Check out asm-ppc64/rtas.h for a definition of the RTAS event header
(struct rtas_error_log). All RTAS events have the same initial header
containing the severity of the event.
Decoding RTAS events beyond the intial header, that gets ugly quick and
will hopefully never need to be done in the kernel.
Close by, Jake remarked:
The original "plan" for error logging was to eventually take out the
printk's all together once we could get ela (the userspace daemon
responsible for parsing error messages and routing them appropriately) into
all distros. We didn't want the possibility of a customer losing a vital
message by not having ela installed.
I would propose the making the printk's of the messages a kernel config
option. Then the distros could turn it on or off depending on if they are
packaging ela. All messages should still go to userspace though. This will
alleviate the spamming of the printk buffer.
I have no problems in moving communication between kernel and userspace to
netlink. Whomever makes the change needs to keep Mike Strosaker and Nathan
Fontenot informed since they are maintaining the user space counterpart.
Close by, Linas said he'd like to wait to see if current patches got into the
kernel, before trying to deal with RTAS event severity; Greg and Dave Hansen
suggested that this would be a 2.7 issue; and the thread ended.
2. orinoco Update; Trouble Splitting The Patch For Kernel Inclusion
2 Jul - 8 Jul (20 posts) Archive Link: "[PATCH] Update in-kernel orinoco
drivers to upstream current CVS"
Topics: Version Control
People: Dan Williams, Jeff Garzik, Jean Tourrilhes, David Gibson, Francois
Romieu
Dan Williams said:
This patch is simply the fixed-up diff between the kernel's current 0.13e
version and the upstream 0.15rc1+ version from savannah CVS. 0.15rc1 has
been out for a couple months now and seems stable.
The major benefits that this newer version brings are, of course, many
bugfixes, but best of all wireless scanning support for the Orinoco line of
cards.
http://people.redhat.com/dcbw/linux-2.6.7-orinoco.patch.bz2
Jeff Garzik took a look at it and remarked, "I'm desperately hoping that
someone will split this up into multiple patches..." Jean Tourrilhes replied:
David Gibson is the official maintainer of the Orinoco driver. Pavel Roskin
is the person that did most of the work on 0.15rc1+. I think it would be a
nice idea to involve those two person in such a discussion (therefore,
cc'ed).
The difference between 0.13e and 0.15rc1+ is not small. I believe Pavel did
a good job in splitting the various patches in small pieces when adding
them to the CVS, and David has tracked the kernel, but reconciliating the
two branches is no trivial matter.
Jeff, does BitKeeper allow to merge patches at an earlier point than the
last version and reconciliate both branches ? That might come handy.
Good luck...
Jeff replied, "Yes, this is one of BitKeeper's strengths. I can create a
BitKeeper repository circa 2.6.0, merge a patch, and then merge that repository
into the 2.6.7-BK-latest repository."
Elsewhere, David Gibson apologized for the size of the patch, and said, "I've
done very, very little work on the driver for well over a year now and the
changes have built up to a megapatch. I really does need to be broken up, but
the chances of me finding the time and motivation to do so are not looking
good."
Close by, Francois Romieu did some work on his own, splitting off several patch
fragments. David replied:
Aha, that's a good start. During the week I'll try to look at these, put my
rubber stamp on them, and send them on to Jeff.
One thing I notice though (from your later ones, actually) is that you seem
to be moving from current 2.6 to the CVS HEAD branch. That includes the
orinoco_usb stuff, which I still don't think is done right and would rather
not push.
Francois said, "The savannah thing refused the cvs+ssh connection. It would
help if someone could post the url of the relevant tarball." Some private
communication took place; and a couple of days later Francois reported:
The news:
+ I got the adequate patch from the cvs repository
+ 35 patches are available at the usual location. The series-mm file
describes the ordering of the patches. I'll redo the numbering as it
starts to be scary
+ the remaining diff weights ~210k so far
At least it makes reviewing easier.
Jeff suggested, "If you are willing to do some re-diffing, feel free to send
out the boring, and easy-to-review parts such as netdev_priv() or obvious
cleanups. That would help, at least, to cut things to more meat, and less
noise." They started haggling over the patches, and the thread petered out.
3. Possible XFS Data Corruption After Improper Shutdown
4 Jul - 14 Jul (45 posts) Archive Link: "XFS: how to NOT null files on fsck?"
Topics: FS: XFS
People: L. A. Walsh, Chris Wedgwood
Norberto Bensa noticed that XFS would null out files after an improper
shutdown. He asked if there were a way to avoid this. L. A. Walsh replied that
this was an old problem, reported before on the XFS mailing list; but she
added:
Apparently not easily reproduced, no one has a clue why it does it. Just
does. Even after multiple syncs, files edited within the past few days will
sometimes go mysteriously null. Good reason to do daily backups as the
backups will usually contain the correct file...
Now if we could just come up with a reproducable test case...but when I try
to reproduce it, it doesn't. Grrr....it knows when I'm scrutinizing!! :-)
In the course of discussion, Chris Wedgwood said:
XFS does not zero files, it simply returns zeros for unwritten extents. If
you open an existing file and scribble all over it, you might see the old
data during a crash, or the new data if it was flushed. You shouldn't see
zero's though.
What does happen though, is that dotfiles are truncated and rewritten, if
the data blocks aren't flushed you will get zeros back because the extents
were unwritten. This is really the only sensible thing to do given the
circumstances.
My guess is that with other fs' (when journaling metadata only) the blocks
allocated for the newly written data are usually the same as the recently
freed blocks from the truncate so things appear to work but in reality it's
probably mostly luck. XFS could behave the same way, but sooner or later
you will still loose when you get crap back instead of old data.
Some applications just need to be fixed.
L. A. replied:
If it is of any help (I doubt it, it perplexes me)...the files I've written
out with vim and have returned "nulls" have been files that were written
out 2-3 DAYS earlier -- often with more recent write having been saved
fine.
I've also seen sections in log files where blocks would return zero in the
middle of a log. Obviously blocks before and after successfully made it to
disk, but in RARE circumstances (crashes and unplanned shutdowns are
already rare enough, so it's a rare bug that only shows up on a 'rare'
occasion...:-).
Almost (shot in the dark), like some code that was supposed to zero unused
but allocated datablocks got pointed at the wrong blocks, since these files
are readable as having been written (yes may all be out of membuffs) and
are often recoverable from the day's backup.
If it was a file I just edited and then it crashed, that I could understand
more than having files I haven't touched for a few days be zapped.
Chris said he had really never seen behavior like that, certainly not in files
that had been modified days earlier. He could guarantee that on his own system,
the checksumming scripts that kept track of all his files would have noticed
such behavior, and they never had. His best guess, in reply to L. A.'s report,
was that the files really were being changed somehow, and not by XFS.
There was more discussion, but nothing conclusive.
4. Linux 2.6.7-mm6 Released
5 Jul - 8 Jul (51 posts) Archive Link: "2.6.7-mm6"
Topics: Kernel Release Announcement, USB
People: Andrew Morton
Andrew Morton announced Linux 2.6.7-mm6, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/pat ches/2.6/2.6.7/
2.6.7-mm6/ (ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/
2.6.7/2.6.7-mm6/)
+ Added the DVD-RW/CD-RW packet writing patches. These need more work.
+ The USB update seems deadlocky. I fixed one bug but it still causes my
ia64 test box to lock up on boot. If it goes bad, please revert
usb-locking-fix.patch and then revert bk-usb.patch. Retest and send a
report to linux-kernel and [email protected] (
mailto:[email protected]) .
5. Support For Boot-Time Splash-Screen In Software Suspend
8 Jul - 14 Jul (22 posts) Archive Link: "[PATCH] swsusp bootsplash support"
Topics: FS: initramfs, FS: ramfs, Framebuffer, Software Suspend
People: Erik Rigtorp, Pavel Machek, Christoph Hellwig, Stefan Reinauer
Erik Rigtorp said, "This patch adds support for bootsplash to swsusp. The code
interfacing to bootsplash needs some more work, currently it's more or less
ripped from swsusp2. Some more code could probably be moved into console.c
instead." Christoph Hellwig pointed out that CONFIG_BOOTSPALSH was not
currently part of the official kernel tree; and so supporting it in the
Software Suspend patches was premature. Christoph also implied that
CONFIG_BOOTSPALSH was unwelcome in the main tree. Pavel Machek replied:
The patch was not intended for mainline... But it will be usefull anyway as
big distros want this kind of stuff....
Perhaps CONFIG_BOOTSPLASH should be in mainline after all? I really don't
want to see 2 different incompatible sets of hooks into swsusp....
But Christoph said, "No. This stuff has no business in the kernel, paint your
fancy graphics ontop of fbdev. And the SuSE bootsplash patch is utter crap, I
mean what do you have to smoke to put a jpeg decoder into the kernel?" Stefan
Reinauer took umbrage at these assertions, saying:
I agee with kernel 2.6 one could do a lot better due to proper initramfs
handling, but in kernel 2.4 there was no decent way of placing userspace
code early enough to be executed before framebuffer initialization.
On the other hand, the jpeg decoder is 8k object size - less than the
dozens of gzip/gunzip algorithms in the kernel, so complaining sounds a
little foolish to me. If you just want to bitch, go and critizise that with
1024x768 the bootsplash patch eats 1.5MB of memory permanently. THAT would
make sense, if anything.
Whether one wants retro text messages or a graphical bootup mechanism is
sure a philosophical thing. IMHO starting X that early is not an option.
Pavel also said to Christoph:
I have not seen SuSE version of bootsplash... I do not want to see. But
this way, SuSE has its own crappy bootsplash, RedHat probably too, Mandrake
probably too, etc.
And now, SUSE will want splash over swsusp, RedHat probably too, Madrake
probably too, etc. I do not want to deal with 3 different sets of hooks
into swsusp.
Now.. Perhaps cleaned-up bootsplash could find its way into kernel. That
would at least turn down ammount of crap in distributions. At least there
would be unified way to turn that thing off...
Or at least standartized hooks for various splashes, so that I do not have
to deal with 3 different sets?
Christoph replied, "Red Hat gets it right and uses a program that's using
fbdev. They also have no swsusp support, which makes quite a lot of sense given
how much in flux the code still is."
The discussion meandered on for a bit, then petered out inconclusively.
6. Serial ATA (SATA) Status Report
8 Jul - 9 Jul (3 posts) Archive Link: "Linux Serial ATA (SATA) status report"
Topics: Disk Arrays: RAID, Disks: IDE, Disks: SCSI, Hot-Plugging, Serial ATA
People: Jeff Garzik
Jeff Garzik said:
Serial ATA (SATA) for Linux
status report
July 8, 2004
This status report applies to the latest SATA driver release, found in (not
yet release) kernels 2.4.28 and 2.6.7.
Recent updates
Recent libata changes have focused on updating the libata core to be more
flexible, and support newer SATA-II host controllers. These changes aren't
very visible, but they lay the groundwork for a more ATA hardware interface
that supports queueing.
Various bits of the core have been tweaked in association with the
following buzzwords: ATAPI, DMADIR, legacy TCQ, NCQ, hotplug, port
multiplier, jelly beans. Ok, that last one isn't part of any official
specification. But the others should be fun.
Hardware support
Intel ICH5, ICH5-R, ICH6
Summary: No TCQ. Looks like a PATA controller, but with a few added,
non-standard SATA port controls. Hardware does not support hotplug.
"Coldplug" support is potentially feasible.
libata driver status: Production, but see issue #2, #3. Recently work on
issue #2 has improved the state of that issue.
drivers/ide driver status: Production, but see issue #1, #2.
Issue #1: Depending on BIOS settings, IDE driver may lock up computer when
probing drives.
Issue #2: Excessive interrupts are seen in some configurations.
Issue #3: "Enhanced mode" or "SATA-only mode" may need to be set in BIOS.
AHCI (Intel ICH6-R/ICH6-M currently)
Summary: Per-device queues, full SATA control including hotplug and PM.
libata driver status: "looks like ICH5" support available in ata_piix.
Preliminary driver with full AHCI support now exists, and is being
integrated into libata mainline.
Note1: AHCI specification is completely open.
Note2: To ease integration, AHCI on ICH6 will be deployed inside the
ata_piix driver.
Note3: SiS has AHCI on its roadmap. Hopefully others will follow.
Promise TX2/TX4/SX4
Summary: Per-host queues on all controllers. Full SATA control including
hotplug and PM on all but one controller (SX4).
libata TX2/TX4 driver status: Production, but see issue #5.
libata SX4 driver status: Production, but see issue #6.
Issue #5: Some boards appear to have PATA as well as SATA ports. PATA is
not currently supported, and no plans have yet been made to rectify this.
Ideally drivers/ide would drive PATA, but if they are the same PCI device,
that would not be feasible.
Issue #6: The SX4 hardware is not fully utilized by the Linux kernel
driver. The SX4 hardware includes an on-board DIMM and hardware XOR
offload. Using the on-board DIMM as cache, and issuing each RAID
transaction once (instead of once for each disk), will result in increased
performance, but the driver doesn't do that yet. SX4 hardware is very "RAID
friendly", particularly RAID1/5. Users may wish to use the Promise driver
to fully utilize the hardware.
Silicon Image 3112/3114
Summary: No TCQ. Looks like a PATA controller, but with full SATA control
including hotplug and PM.
libata driver status: Beta.
drivers/ide driver status: Beta?
Silicon Image 3124
Soon, hopefully. Silicon Image has made documentation and sample hardware
available to me (jgarzik) for development. Some code exists internally.
Broadcom/ServerWorks/Apple
Summary: Huge per-device queues, full SATA control including hotplug and PM
for the "Frodo4" and "Frodo8" boards. Apple K2 SATA, which also uses this
chipset, has all the feature of Frodo4/8 save the host DMA queueing feature
("QDMA"). QDMA supports legacy TCQ, but not NCQ.
libata driver status: Beta, but no QDMA support yet.
VIA
Summary: No TCQ. Looks like a PATA controller, but with full SATA control
including hotplug and PM.
libata driver status: Beta.
NVIDIA
Summary: No TCQ. Looks like a PATA controller, but with full SATA control
including hotplug and PM.
libata driver status: Beta.
SiS 180
Summary: No TCQ. Looks like a PATA controller, but with full SATA control
including hotplug and PM.
libata driver status: Beta
Vitesse 7174 / Intel 31244
Summary: NCQ and 64-bit DAC support possible, but not implemented. Looks
like a PATA controller, but with full SATA control including hotplug and
PM.
libata driver status: Beta
Marvell 88SX50[48]x
Summary: Similar to ServerWorks "frodo": per-device queues, supports legacy
TCQ but not NCQ (I think??), full SATA control including hotplug and PM.
libata driver status: in progress
HighPoint (HPT)
I've had no contact with the company. Someone poke them, and get them to
get me a card and docs :)
libata driver status: no driver planned at this point.
ADMA (including Pacific Digital Talon SATA)
Summary: No control over SATA phy at all (no hotplug/PM). Has per-device
hardware queues, and supports legacy TCQ.
Docs are public (yay!)
libata driver status: none, but hopefully soon
3ware SATA RAID
Not suited for libata architecture. Separate SCSI driver exists.
Software support
Basic Serial ATA support
The "ATA host state machine", the core of the entire driver, is considered
production-stable.
The error handling is very simple, but at this stage that is an advantage.
Error handling code anywhere is inevitably both complex and sorely
under-tested. libata error handling is intentionally simple. Positives:
Easy to review and verify correctness. Never data corruption. Negatives: if
an error occurs, libata will simply send the error back the block layer.
There are limited retries by the block layer, depending on the type of
error, but there is never a bus reset.
Or in other words: "it's better to stop talking to the disk than compound
existing problems with further problems."
As Serial ATA matures, and host- and device-side errata become apparent,
the error handling will be slowly refined. I am planning to work with a few
(kind!) disk vendors, to obtain special drives/firmwares that allow me to
inject faults, and otherwise exercise error handling code.
Queueing support
Even though some SATA host controllers on the market already support
command queueing (a.k.a. "TCQ"), libata does not yet support it.
However, libata was designed from the ground-up to support queueing, so I
need only change a few lines of code, and write two functions, to enable
this behavior.
Queueing will be enabled in libata soon, but to do so requires a long
stretch of testing on a large variety of controllers and drives. This is
very time-intensive, and is the largest part of this task.
Tangent: Host-based queueing and Native Command Queueing
Queueing is the process of sending multiple commands to a single device,
without waiting for prior commands to finish. This increases performance
and reduces latency. There are three types of queueing in the ATA world:
1. "legacy TCQ" -- some PATA devices support this. Just ignore it, it's
going away.
2. "host-based TCQ" -- the host controller supports a queue of drive
commands, whether or not the drive supports it.
3. "Native Command Queueing" -- both host and drive cooperate in the
queueing and execution of drive commands. This should provide the
highest performance and lowest latency of all three options.
#1 will be supported only where hardware handles all the details. #2 will
soon be supported by libata.
#3 will be supported by libata when hardware is available from drive
manufacturers.
Hotplug support
All SATA is hotplug.
libata does not support hotplug... yet.
The following SATA controllers will never support hotplug: Intel ICH5,
Intel ICH5-R, Intel ICH6 (non-AHCI), Pacific Digital Talon, Promise SATA
SX4.
These controllers do not export enough information about the SATA phy to
make it possible to support hotplug. In some cases, such as Intel ICH5/
ICH6, it is possible to support "coldplug" operation: the user informs the
OS driver he wishes to disconnect his SATA device, rather than simply
disconnecting it.
Power Management support
Over and above the power management specified in the ATA/ATAPI
specification, one can aggressively control the power consumption of SATA
hosts, the SATA bus, and the SATA device.
Note: as discussed on some mailing lists, the aggressive power management
can be too aggressive, and park the heads too often (resulting in shortened
disk drive life). Careful attention must be paid to balance.
SMART support
Soon. Requires the capability to directly submit ATA commands from
userspace to the low-level device, which must be added with care. The
smartmontools developers have committed to adding a new device type '-d
sata' to utilize this passthrough, once it is ready.
7. iswraid Updated For 2.4.26
8 Jul (1 post) Archive Link: "[Announce] "iswraid" (ICH5R/ICH6R ataraid
sub-driver) for 2.4.26"
Topics: Big Memory Support, Disk Arrays: RAID, Disks: IDE, Disks: SCSI, Serial
ATA
People: Martins Krikis, Jeff Garzik
Martins Krikis said:
Version 0.1.4 of the Intel Sofware RAID driver (iswraid) is now available
for the 2.4 series kernels at http://prdownloads.sourceforge.net/iswraid/
2.4.26-libata-iswraid.patch.gz?download
It is an ataraid "subdriver" but uses the SCSI subsystem to find the RAID
member disks. It depends on the libata library, particularly the ata_piix
driver that enables the Serial ATA capabilities in ICH5/ICH6 chipsets. The
libata patch by Jeff Garzik should be applied before applying this patch.
There is more information and some ICH6R related patches at the project's
home page at http://iswraid.sourceforge.net/.
The changes WRT version 0.1.3 are as follows:
+ a fix for CONFIG_HIGHMEM systems;
+ reasonable handling of missing disks;
+ when RAID1 goes degraded, the I/O succeeds;
+ new mode that does not fail degraded RAID1 ever;
+ metadata updates started from the scheduler's queue;
+ slab caches instead of kmalloc-s;
+ small /proc filesystem tweaks;
+ serial number extraction fixed;
+ unused disks properly freed;
+ added documentation file;
+ major style changes and more comments about implementation choices.
If you have any questions or comments, please CC me directly because I no
longer read this list.
8. Linux 2.6.7-rc1 Released; Some Discussion Of Release Policy
11 Jul - 13 Jul (29 posts) Archive Link: "Linux 2.6.8-rc1"
Topics: Disks: SCSI, FS: JFS, Kernel Release Announcement
People: Linus Torvalds, Adrian Bunk, Paolo Ciarrocchi
Linus Torvalds announced Linux 2.6.8-rc1, saying:
Ok, there's been a long time between "public" releases, although the
automated BK snapshots have obviously been keeping people up-to-date. Sorry
about that, I blame mainly moving boxes and stuff around...
The diff is big, and skewed by some QLogic SCSI controller firmware updates
along with a few new (and some moved) drivers. Most of the rest is a large
collection of fairly small patches.
Paolo Ciarrocchi suggested that there should be a battery of tests a kernel had
to go through before it could legitimately be labeled a release candidate (-rc)
or a full version. Adrian Bunk replied, "Unless he really knows what he's
doing, no user should use anything other than the actual releases (i.e. 2.6.7,
2.6.8, 2.6.9,...)." He went on, "It would be more important if Linus would
release one last -rc that will be released unchanged (except for EXTRAVERSION a
few days later to catch bugs in last minute changes. This might catch more
problems like the JFS compile problem in 2.6.7." A few posts later, Adrian said
that the current release practices worked fairly well for the Linux kernel; he
felt no need for a test suite to justify new releases. He added, "Compared to
some other open source projects like e.g. Debian the Linux kernel has a pretty
well-working release process (and the 2.6 development avoided several mistakes
of the 2.4 development)."
At this point, Linus remarked:
The whole _point_ of -rc kernels is to find silly problems.
Trying to have a release mechanism for -rc kernels in order to avoid some
problems in them would kind of defeat the point. The -rc kernels are there
to encourage people who wouldn't want to just take a daily shapshot to tell
us when we break things - and clearly it's working ;)
(There's also a totally nontechnical point to -rc kernels: it's a way to
tell people to calm down a bit. Usually we have a backlog that gets filled
up after a kernel release, and then with the -rc kernels people usually
slow down feeding non-critical stuff to me. At least a bit)
9. Status Of ipw2100 Wireless Driver
14 Jul (12 posts) Archive Link: "ipw2100 wireless driver"
People: Eric Brunet, Pavel Machek
Pavel Machek asked what the status was of the ipw2100 wireless driver, and in
particular whether it would be incorporated into the main 2.6 kernel tree. Eric
Brunet replied, "I am very happy with that module; I installed the rpm from
atrpms.net on my Fedora Core 2, ran the GUI to set up the interface, ifup eth1
and it worked on the first try. No recompile, no fiddle with configuration
files, I couldn't believe it and was very impressed. I am not using the wifi
card very often, but it works with no glitch each time I try it."
No definitive statement on the status or future of the driver was made.
10. Memory Hotremoval For 2.6.7
14 Jul (17 posts) Archive Link: "[PATCH] memory hotremoval for linux-2.6.7 [0/
16]"
People: Hirokazu Takahashi
In a series of 16 patches, Hirokazu Takahashi presented:
I'm pleased to say I've cleaned up the memory hotremoval patch Mr. Iwamoto
implemented. Part of ugly code has gone.
Main changes are:
+ Replaced the name remap with mmigrate as it was used for another
fuctionality.
+ Made some of the memory hotremoval code share with the swapout-code.
+ Added many comments to describe the design of the memory hotremoval.
+ Added a basic funtion to support for memsection. try_to_migrate_page()
is it. It continues to get a proper page in a specified section and
migrate it while there remain pages in the section.
The patches are against linux-2.6.7.
Note that some patches are to fix bugs. Without the patches hugetlbpage
migration won't work.
11. kexec Update For 2.6 x86 And PowerPC
14 Jul (1 post) Archive Link: "[ANNOUNCE] [PATCH] 2.6.8-rc1-kexec1 (ppc & x86)
"
Topics: Kexec
People: Eric W. Biederman
Eric W. Biederman said:
I finally found some time to work on kexec again. I have taken the time to
break the patches apart again, because with everything all in one patch
things get unmaintainable.
But I have also lumped everything together in one big patch to make testing
easier.
While doing this I found a bug where I was not putting IOAPIC into virtual
wire mode where appropriate. This allows kexec to work on Opterons and
other affected systems.
The files are available at: http://www.xmission.com/~ebiederm/files/kexec/
2.6.8-rc1-kexec1
The first hunk of patches are essentially generic fixes to the boot
process. That should be safe to apply in general.
i8259-shutdown.patch
apic-shutdown.patch
reboot-on-bsp.patch
ioapic-virtwire.patch
x86 does not like tlb flush or other generic code against the init_mm this
allows those to proceed. I think long term I want to get away from using
init_mm, to many architectures make weird assumptions.
flush-init-mm.patch
The next are the kexec patches themselves. The generic code and then the
architecture specific code.
kexec-generic.patch
i386-kexec.patch
ppc-gc-kexec.patch
We Hope You Enjoy Kernel Traffic
Kernel Traffic is grateful to be developed on a computer donated by Professor
Greg Benson and Professor Allan Cruse in the Department of Computer Science at
the University of San Francisco. This is the same department that invented
FlashMob Computing. Kernel Traffic is hosted by the generous folks at
kernel.org. All pages on this site are copyright their original authors, and
distributed under the terms of the GNU General Public License, version 2.0.