If anyone knows of a company looking for a talented writer with scripting and other abilities, check out my résumé. I've done API documentation with accompanying developer guides, and I'm published monthly as a Contributing Editor in Linux Journal and a Columnist in Linux Magazine. 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.
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.
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.
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.
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.
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/
- 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 linux-usb-devel@lists.sourceforge.net.
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.
Jeff Garzik said:
Serial ATA (SATA) for Linux
status report
July 8, 2004This 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:
- "legacy TCQ" -- some PATA devices support this. Just ignore it, it's going away.
- "host-based TCQ" -- the host controller supports a queue of drive commands, whether or not the drive supports it.
- "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.
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.
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)
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.
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.
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.patchx86 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