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.
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).
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.
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.
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/ :
- http://www.uwsg.indiana.edu/hypermail/linux/kernel/index.html this is the only on that works for me. It is missing most of todays messages. I guess is is not updated in real time.
- http://boudicca.tux.org/hypermail/linux-kernel/ This one is inaccessible for several days. ( gives a connection timeout )
- http://marc.theaimsgroup.com/?l=linux-kernel The site says : Due to another 3Ware-driver-related system crash, marc.theaimsgroup.com and lists.kde.org are down.
- http://kernelnotes.org/lnxlists/linux-kernel/ Inaccessible site. ( gives a connection timeout )
- http://web.gnu.walfield.org/mail-archive/linux-kernel The site responds , but is empty. There are no messages archived.
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.
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:
- Multiplied the version numbering by ten to cater for bugfix releases against the 0.9.0 stream.
- The main thrust has been the removal of a number of changes in the core kernel which were required for to support the journalling of data. This has caused some duplication of core code within ext3, but it's not too bad.
- A number of cleanups and resyncs with latest ext2. (Thanks, Al).
- Reorganised and optimised ext3_write_inode() and the handling of files which were opened O_SYNC.
- Move quota operations outside lock_super() - fixes last known source of quota deadlocks in -ac kernels.
- Deleted large chunks of debug/development support code.
- Improved handling of corner-case errors.
- Improved robustness in out-of-memory situations.
The last change is probably the most significant - it prevents possible crashes and fs corruption under extreme workloads.
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:
- What is the maximum amount of RAM that a *single* process can address under a 2.4 kernel, with PAE enabled? Without?
- And, what (if any) paramaters can effect this (recompiling the app etc)?
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.
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.
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.