Kernel Traffic has just changed its publication system. It used to use a home-grown XML parser that interfaced with a database back-end to produce flat HTML, which would then be uploaded to the various machines in the DNS round-robin.
The new system uses XSLT files to transform the XML into HTML, and uses 'make' to ensure that only the right files are rebuilt. Eventually the publication system will be released with version numbers, revision control, etc., but for now you can still view the files at http://kt.zork.net/xslt/. The key XSLT file used to produce the HTML on the site is http://kt.zork.net/xslt/kt.xsl, which in turn references files in the various subdirectories.
I'll have more to say about this, and some documentation, in upcoming weeks. For now I'm just letting folks know the files are there, in case anyone wants to experiment with them, and maybe send me patches and feature ideas.
Special thanks go to Joerg Heinicke and Jeni Tennison from the XSL mailing list, who wrote the <kcref> handler in http://kt.zork.net/xslt/html/misc.xsl.
Karim Yaghmour announced:
LTT 0.9.5 has now been released.
A very large number of enhancements have been added since 0.9.4. This is a summary:
- S/390 port
- SuperH port
- MIPS port
- Cross-platform trace reading capabilities
- Updated RTAI support
- User-space events (LibUserTrace)
- Binary traces accessible through user-space library (LibLTT)
- Visualizer enhancements
- Dynamic modification of trace masks
- Autoconf/autobuild build system integration
For the full detail of the additions, see the news section of the project's website.
Since LTT is close to 3 years old, it has become a large body of software. To facilitate easy understanding of what LTT does and what it doesn't, I've added a "features" description on the project's front page: http://www.opersys.com/LTT/index.html#features
The list of events traced LTT had been previously documented in some of the articles I presented about the tool. In order to facilitate access, I've added an online version of the events list: http://www.opersys.com/LTT/trace-points.html
As I said earlier, a 2.5.x patch is available and LTT is ready to be integrated into the 2.5 series.
LTT's website is: http://www.opersys.com/LTT
Roman Zippel liked the patch and thought it should go into the mainline kernel sources, but felt the formatting of the code needed adjustment. He pointed Karim to Documentation/CodingStyle in the source tree. Karim said he'd take care of this; and they had a couple of exchanges about the details.
David Macbanay reported that on his SOYO K7VTA-B with a VIA 82C686B chipset
and a Duron 750mhz processor, Starting sometime
after kernel 2.5.1 (I couldn't compile any kernels from then up until 2.5.5)
the Evolution email program locks up whenever Calender, Tasks, or Contacts
is selected. I have to go to another terminal and kill it.
Pavel
Machek suggested using strace to see what Evolution was doing just before
it crashed. Dave Jones agreed with this, and asked if it could be reproduced
under 2.5.10; David confirmed, this occurs in any
kernel from 2.5.5 through 2.5.10. It may have happened before that also but
I wasn't able to compile any kernels after 2.5.1 up until 2.5.5.
He
posted the last few lines of his strace output.
Meanwhile, Tommy Faasen confirmed the problem in 2.5.8, and said it did not appear in the 2.4 kernels. At this point, Miles Lane explained:
I have been aware of this bug since about 2.5.5. It is still present in 2.5.10. I have been attempting to gather more useful debugging information. So far, I haven't come up with anything that points clearly to the problem.
Regarding using strace to identify the bug, it should be noted that Evolution uses multiple processes that all communicate with the shell process (evolution). The process that handles access to much of Evolution's storage for the most of the Evolution components is called wombat.
My plan is to run "strace wombat", "strace evolution-mail" and "strace evolution-addressbook" in separate terminal windows. The evolution process can then be started normally.
My observations so far lead me to suspect a problem with wombat. If any of you other Evolution uses would care to help me with this testing, please do!
Keith Owens asked, What state are the tasks
in when it hangs, S, R, D, N, T, what? I have an intermittent problem on
2.4 where an entire process group goes into T state even though nothing is
tracing it. Killing the offending process then sending SIGCONT to the rest
of the process group restarts the group. The offending process is usually the
last one on the tree.
And Miles replied, Hmm.
I checked while running 2.5.12 (it still hangs) and all the Evolution-related
processes were in "S" state after the hang.
End of thread.
Wakko Warner reported that his brand new 160G disk would only show up as
137G. Randy Dunlap replied, There was a thread on
this 2-3 months back. IDE in 2.4 doesn't have a 48-bit block address interface
IIRC, although Andre has some patches for this. This is necessary to go above
137 GB.
Mike Fedyk pointed out that some of Andre's patches had been
merged in the 2.4.19-pre timeframe, and Jeff V. Merkey said, True, but some cards will require a firmware upgrade.
Elsewhere, Jeff suggested that Wakko do this, if he was using a 3Ware
adapter or any other RAID controller. But Wakko replied, It's not on a raid controller. The machine has a PIIX3 ide controller
and a AHA-2940UW scsi controller. Both exibit the same problem.
Martin Bene replied:
Actually, no: To fully use 160GB ATA drives, whatever device is on the other end of the ATA bus needs to actively support 48-bit address mode. In for the two cases you tried, that means
IDE: The kernel IDE driver needs to support 48-bit addresseing to support 160GB.
SCSI: The firmware in your IDE<->SCSI Adapter needs to support 48-bit addressing.
So, while the symptoms are the same in both cases the problem is actually in two completely different places.
Most probably, you can't do anything about the IDE<->SCSI adapters firmware; however, you can do something about the linux ATA driver: code is in the 2.4.19-pre tree, it went in with 2.4.19-pre3.
Ville Herva asked, But which IDE controllers
support 48-bit addressing?
Vojtech Pavlik said, all of them, but Andre
Hedrick replied that he had a list of ones IDE controllers that failed. Vojtech
asked him to post that list to linux-kernel, but Andre didn't reply. Elsewhere,
other folks also debated the question, with no conclusive result.
Con Kolivas announced:
I've combined the following patches against 2.4.18:
Scheduler 0(1)
Low Latency
Preemptible
Compressed cache
new IDE subsystemThese are based on fairly recent patches, but not all are the latest.
I've noticed palpable improvements (the feel of using the machine) enabling all of these except for the compressed cache but have no data to support my feelings. The machine I tried them on was up for 3 weeks with heavy loads and proved to be quite stable. I've posted a combined patch at:
Feel free to test it out and tell me what you think. Thanks very much to those who put all the effort into each one of these patches.
Mark Hounschell replied off-list, saying that doing a 'make mrproper
oldconfig dep bzImage' would fail to compile. Leaving out the 'mrproper'
compiled fine. Con said, Hmm. I used a make
mrproper && make clean followed by manual configuration without
any problems.
Mark replied (on-list this time), I do not think all these patches play well together with the
O(1)
J.A. Magallon asked if the e100 or e1000 drivers would make it into the main kernel sources. Jeff Garzik replied:
e100 has been in 2.5.x for quite a long time. All license issues have similarly been resolved a long time ago.
I expect Intel's Q/A to green light their current driver. With a few patches it should be ready for 2.4.x soon.
You can easily copy drivers/net/e100[0] into a 2.4.x kernel, it likely compiles without modification.
J.A. replied, I did it, taking drivers from
2.5.12, and at least it compiles. I have to try in the real box, but I don't
think there were any problems, at least the same than 2.5.... Marcelo, is
there any chance to get this in next -pre or in .19 ?
Jeff replied:
When they are suitable for Marcelo, I'm going to send them to Marcelo.
As I wrote in the quoted message, they need some more patches, and I'm also interested in feedback from Intel Q/A (which is scheduled for sometime this week).
If you are interesting in maintaining 2.4.x patches for a short time, go for it. But I would rather not have a almost-ready e100 go to Marcelo and get released in 2.4.19 in incomplete form. It's out there, it's public, let's leave at that for a little while.
J.A. apologized for the misunderstanding. He added, If somebody wants to try them, look at one other post
about -jam9. It is the same story, I need them for some new boxen (e1000)
and I prefer to have all in the same tree than apart, so took those from
2.5 instead of Intel's.
Guillaume Boissiere gave the status of 2.5:
Many changes since last week - of particular note, the beginning of the new buffer layer by Andrew Morton and a much improved Bluetooth subsystem, courtesy of Maxim Krasnyansky et al.
The gory details are at the usual URL:
http://kernelnewbies.org/status/
Don't hesitate to speak out of if there are any inaccuracies or missing items. Enjoy!
Jeff Dike posted some updates to various items on Guillaume's list. End of thread.
Eugene Kuznetsov asked when the AMD 760 IRQ router would be supported
under Linux, and Alan Cox replied, When someone
volunteers to test it.
Eugene volunteered, and they went back and
forth with some patches. At first Eugene reported failure, and Alan thought
his BIOS was simply broken. But then Eugene started seeing success. He said,
Without noapic, the output from previous
email was with MP 1.1. With MP 1.4 kernel hangs somewhere near "calibrating
APIC timer". With noapic it seems to work with both 1.1 and 1.4.
Alan asked, Would this be an ASUS A7M-266D ? If so it
seems to randomly depend on which BIOS you have what actually works. Find a
BIOS that works and dont touch it 8).
And Eugene confirmed, Yes - that's my motherboard. I have BIOS revision
1004 from 12/17/2001.
Jeff Dike sang out:
UML is now able to run nested inside itself. This works as of UML 2.4.18-21, which isn't released yet, but will be soon. See the log below for the gory details, and also see http://user-mode-linux.sf.net/nesting.html for how to do it yourself.
This is a sign of UML maturity rather than any new magic functionality having been added. UML is a demanding process, so even though it uses only the Linux system call interface, it takes some maturity for a Linux kernel to host it.
The missing pieces were a couple of signal delivery bugs that were still lurking. Once these were fixed, UML booted right up.
He corrected the version number right away though. It wasn't 2.4.18-21,
it was 2.4.18-22. Andries Brouwer was very impressed, and said, Reminds me of the good old times 30 years ago -
had a tower of three virtual machines on top of a real PDP 8/I. Now that
you can run UML under UML, can you run UML under UML under UML?
Jeff said it should work, and elsewhere remarked that one interesting
project he had for the medium term was to try to spread an SMP UML instance
across multiple hosts. Mike Fedyk wondered what benefit this would have
over something like MOSIX, or other clustering solutions. Jeff replied,
MOSIX (or Compaq's SSI) would certainly be a way
of doing it. It happens that there's a particularly simple way of doing
it with UML. You'd partition UML's 'physical' memory between the hosts,
and use the fact that those pages are really virtual to fault them between
hosts as needed. This would perform particularly badly, but its simplicity
appeals to me.
Lars Marowsky-Bree replied:
An interesting and simple approach indeed; but spreading an instance across multiple nodes is nowhere as simple as it seems; where do you keep OS data, IO access, scheduling decisions, inter-node communication in the first place, how to deal with node failure etc...
However, I believe it could potentially be implemented cleaner than currently with the Compaq SSI stuff, because the encapsulation is better etc; but I have been known to be wrong ;-)
It would certainly be very interesting. If you _really_ want to open this can of worms, you should consider joining linux-cluster mailing list for this, or the Open Clustering Framework list (because you are going to stumble into the madness which is "interoperability and lack of standards" here).
They went back-and-forth on the implementation details for awhile. Lars was revolted by some of Jeff's ideas, but Jeff pointed out that he was only describing something that was possible, not something that was pretty or efficient.
Larry McVoy announced:
http://www.bitkeeper.com/stats/linux.html
Let me know what you think, I'd like to know if you find this useful because if you do, I can do something like this as a part of the BK/Web interface, then you get these stats for every tree on bkbits.
There was no reply.
Pawel Kot announced:
With much help from Anton, I backported the NTFS-TNG driver to 2.4.x Linux kernel series. If you are afraid of running 2.5.x kernel, but you would like to get all benefits of the new NTFS driver use this one.
It should have all features the driver for 2.5.x has -- only 2.5.x series specific code was removed/altered.
The driver itself really looks to be stable, it survived all the run tests, but if you have any problems running it, please, contact me or Anton.
You can download the patch for the vanilla 2.4.18 from:
http://prdownloads.sourceforge.net/linux-ntfs/linux-2.4.18-ntfs-2.0.6a.patch
http://prdownloads.sourceforge.net/linux-ntfs/linux-2.4.18-ntfs-2.0.6a.patch.gz
http://prdownloads.sourceforge.net/linux-ntfs/linux-2.4.18-ntfs-2.0.6a.patch.bz2I plan also to sync the patch with the 2.4.19pre releases but it may take some time.
Erik Andersen was very impressed, and asked if this version included
write-support. Pawel replied, Nope. This is also
read-only support. According to Anton, it will take a lot of time to have
write support for NTFS...
End of thread.