|
Kernel Traffic Latest | Archives | People | Topics |
Wine Latest | Archives | People | Topics |
GNUe Latest | Archives | People | Topics |
| Czech |
| Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic |
linux-kernel FAQ | subscribe to linux-kernel | linux-kernel Archives | kernelnotes.org | LxR Kernel Source Browser | All Kernels | Kernel Ports | Kernel Docs | Gary's Encyclopedia: Linux Kernel | #kernelnewbies
Table Of Contents
| 1. | 30 Jun 2001 - 4 Jul 2001 | (8 posts) | 64-Bit Block Support |
| 2. | 4 Jul 2001 | (1 post) | Subject: "State of CML2" |
| 3. | 4 Jul 2001 - 6 Jul 2001 | (5 posts) | Identifying Merges From -ac Kernels To The Linus Tree |
| 4. | 4 Jul 2001 | (4 posts) | Mailing List Archive Problems |
| 5. | 6 Jul 2001 - 7 Jul 2001 | (4 posts) | Status Of ext3 |
| 6. | 9 Jul 2001 - 10 Jul 2001 | (28 posts) | Per-Process Memory Limits |
| 7. | 10 Jul 2001 - 11 Jul 2001 | (4 posts) | Resurrecting The sparc32 Port |
| 8. | 10 Jul 2001 - 11 Jul 2001 | (4 posts) | ESS137x Compilation Clash |
Introduction
I'd like to welcome John Guthrie. His first contribution may be small, but it was a thread I had inadvertantly passed over, so it's only by his good eye that KT has it this week. Adam is also back this week, with some very good work.
Mailing List Stats For This Week
We looked at 908 posts in 3534K.
There were 370 different contributors. 156 posted more than once. 130 posted last week too.
The top posters of the week were:
1. 64-Bit Block Support
30 Jun 2001 - 4 Jul 2001 (8 posts) Archive Link: "[RFC][PATCH] first cut 64 bit block support"
Summary By Zack Brown
Topics: Disk Arrays: LVM, Disk Arrays: RAID
People: Ben LaHaise, Chris Wedgwood
Ben LaHaise posted a patch and announced, "Below is the first cut at making the block size limit configurable to 64 bits on x86, as well as always 64 bits on 64 bit machines. The audit isn't complete yet, but a good chunk of it is done." [..] "The following should be 64 bit clean now: nbd, loop, raid0, raid1, raid5." He gave links to two homepages at http://people.redhat.com/bcrl/lb/ and http://www.kvack.org/~blah/lb/. He added, "Ugly bits: I had to add libgcc.a to satisfy the need for 64 bit division. Yeah, it sucks, but RAID needs some more massaging before I can remove the 64 bit division completely. This will be fixed." Chris Wedgwood proposed some changes to libgcc.a to be less ugly, and Ben replied, "I'm getting rid of the need for libgcc entirely. That's what "This will be fixed" means. If you want to expedite the process, send a patch. Until then, this is Good Enough for testing purposes."
Elsewhere, Ragnar Kjarstad was very happy about Ben's work, asking if LVM was also 64-bit clean. Ben replied cryptically, "Errr, I'll refrain from talking about LVM." Ragnar wanted some clarification, and Ben explained:
Fixing LVM is not on the radar of my priorities. The code is sorely in need of a rewrite and violates several of the basic planning tenents that any good code in the block layer should follow. Namely, it should have 1) planned on supporting 64 bit offsets, 2) never used multiplication, division or modulus on block numbers, and 3) don't allocate memory structures that are indexed by block numbers. LVM failed on all three of these -- and this si just what I noticed in a quick 5 minute glance through the code. Sorry, but LVM is obsolete by design. It will continue to work on 32 bit block devices, but if you try to use it beyond that, it will fail. That said, we'll have to make sure these failures are graceful and occur prior to the user having a chance at loosing any data.
Now, thankfully there are alternatives like ELVM, which are working on getting the details right from the lessons learned. Given that, I think we'll be in good shape during the 2.5 cycle.
End Of Thread (tm).
2. Subject: "State of CML2"
4 Jul 2001 (1 post) Archive Link: "State of CML2"
Summary By John Guthrie
Topics: Kernel Build System
People: Eric S. Raymond
Eric S. Raymond announced:
The CML2 core is in good shape. There have been no serious bugs since mid-April. The latest release (1.6.9) resynchronizes with 2.4.6 and ac24 and adds better compile-time type checking in expressions (thanks to Daniel Junglas for getting me off the dime on this).
There are a couple of minor Tkinter weirdnesses remaining in the xconfig interface, but they don't seem to show up in normal operation with the Linux kernel rules file. They are fully described in the distribution TODO file.
No speed complaints from the beta testers latelyl; the seige of tuning in May seems to have worked. The requests I'm getting are pretty much all for minor UI tweaks.
CML2 has another design win. The folks at Webmachines now use it to configure the Linux distribution that they put in the flash ROMS of their network apppliances. A lightly edited version of the Webmachines rulesfile is available on the CML2 project site as an example.
The dungeon walls in CML2 adventure now occasionally feature entertaining grafitti. Spot all the in-jokes and collect a valuable no-prize.
CML2 is ready.
3. Identifying Merges From -ac Kernels To The Linus Tree
4 Jul 2001 - 6 Jul 2001 (5 posts) Archive Link: "Linus vs. AC kernels"
Summary By Zack Brown
People: Alan Cox, Tim Waugh, Linus Torvalds
John Weber asked how to find out which parts of the -ac kernels had been merged into Linus Torvalds' tree. Tim Waugh suggested using diff. At one point Alan Cox said, "The -ac and Linus tree merging is not remotely in order of -ac releases, That does make it more complex to classify."
4. Mailing List Archive Problems
4 Jul 2001 (4 posts) Archive Link: "Mail list archives down"
Summary By Zack Brown
People: David Balazic, Erik Mouw, Zack Brown
David Balazic noticed:
I noticed 4 out of 5 LKML web archives listed in the FAQ are down as of today.
They are listed in the LKML FAQ at http://www.tux.org/lkml/ :
Conspiracy theories ?
Erik Mouw added a link to http://www.geocrawler.com/lists/3/Linux/35/0/, saying, "Here is another one that updates in real time but doesn't support thread mode." Havard Kvalen gave a link to one that seemed to work. Samuli Kaski also pointed to a simple archive.
(ed. [Zack Brown] The best archive I've found is the first link in David's list. If anyone finds anything better, please let me know.)
5. Status Of ext3
6 Jul 2001 - 7 Jul 2001 (4 posts) Archive Link: "ext3-2.4-0.9.0"
Summary By Zack Brown
People: Andrew Morton
Andrew Morton announced:
An update of the ext3 journalling filesystem for 2.4 kernels is available at
http://www.uow.edu.au/~andrewm/linux/ext3/
Patches are against 2.4.6-ac1 and 2.4.6.
Changes since 0.0.8 include:
The last change is probably the most significant - it prevents possible crashes and fs corruption under extreme workloads.
6. Per-Process Memory Limits
9 Jul 2001 - 10 Jul 2001 (28 posts) Archive Link: "What is the truth about Linux 2.4's RAM limitations?"
Summary By Adam Buchbinder
Topics: Big Memory Support, Virtual Memory
People: Adam Shand, Andi Kleen, Brian Gerst, Jesse Pollard, Rik van Riel, Jonathan Lundell
Adam Shand explained, "Where I just started work we run large processes for simulations" [...] "Currently we use Solaris because of past limitations on the amount of RAM that a single process can address under Linux." He posted two questions:
He went on to post the results of his research into the matter, saying that no definitive source existed:
He added that all information he received about this would go up on his web site.
Andi Kleen replied that the constant __PAGE_OFFSET could be set to raise the per-process RAM limit, and that arch/i386/vmlinux.lds had to be edited (He didn't say how). He also speculated, "The reason why your simulation stopped at 2.3GB is likely that the malloc allocation hit the shared libraries (check with /proc/<pid>/maps). Ways around that are telling malloc to use mmap more aggressively (see the malloc documentation in info libc) or moving the shared libraries up by changing a kernel constant called TASK_UNMAPPED_BASE."
Elsewhere, Rik van Riel said that the per-process limit was 3GB, and was a hardware limit. Brian Gerst also explained that the PAE extensions allowed the use of "64GB of PHYSICAL memory. The processor is still limited to 4GB of VIRTUAL memory per page table (per process) which must be shared between user space and kernel space. Linux uses a 3:1 split."
There was some suggestion about expanding the user-space portion of the 4GB space, but the consensus was that it would lead to instability and unacceptable performance hits. At one point Jesse Pollard asked for a full reference on Intel addressing capability, and Jonathan Lundell gave a link to Intel's Pentium III reference manuals.
7. Resurrecting The sparc32 Port
10 Jul 2001 - 11 Jul 2001 (4 posts) Archive Link: "Kernel 2.4.6 does not compile on Sparc"
Summary By Adam Buchbinder
Topics: Framebuffer, SMP
People: Fabrizio Gennari, Doug McNaught, Peter Zaitcev, Alex Buell
Fabrizio Gennari reported problems compiling 2.4.6 on a Sparc. "It seems that pgalloc.h defines as macros some identifiers which are defined elsewhere as functions." He said this was the same problem Alex Buell had reported to the list on May 9.
Doug McNaught replied, "Currently, 2.4.X does not compile or run on Sparc32 due to lack of a maintainer for that platform." Peter Zaitcev posted a link to a lengthy patch of his that "compiles, but does not run very well. It may be a good start if you want to fix sparc(32)."
Alex Buell said that he'd look into the patch as soon as he got back from vacation. In the meantime, he asked, "if anyone in the UK is willing to donate a SparcStation 20 with dual SM61s (or even better, SM71s) with a 24bit framebuffer, I can make sure SMP works on sun4m." There was no reply.
8. ESS137x Compilation Clash
10 Jul 2001 - 11 Jul 2001 (4 posts) Archive Link: "es1370/1371 compilation clash"
Summary By Adam Buchbinder
People: Martin A. Brooks
Martin A. Brooks reported an error while trying to compile both the es1370 and es1371 (sound) drivers under 2.4.6-ac2:
es1371.o(.text+0x587c): multiple definition of `gameport_register_port'
es1370.o(.text+0x5670): first defined here
Alexander Griesser posted a patch to prevent the symbols from being defined twice, Martin reported success, and the thread ended there.
Sharon And Joy
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. |