-----Original Message----- From: linux-ia64-request@linuxia64.org [mailto:linux-ia64-request@linuxia64.org] Sent: 2003-05-10 (Åä) ¿ÀÀü 4:00 To: linux-ia64@linuxia64.org Cc: Subject: Linux-IA64 digest, Vol 1 #1022 - 14 msgs Send Linux-IA64 mailing list submissions to linux-ia64@linuxia64.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.linuxia64.org/lists/listinfo/linux-ia64 or, via email, send a message with subject or body 'help' to linux-ia64-request@linuxia64.org You can reach the person managing the list at linux-ia64-admin@linuxia64.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Linux-IA64 digest..." Today's Topics: 1. Re: SAL error record logging/decoding (Bjorn Helgaas) 2. Re: Building IA-64 toolchain (Jim Wilson) 3. RE: Re: [PATCH] head.S fix for unusual load addrs (David Mosberger) 4. Re: Re: [PATCH] head.S fix for unusual load addrs (Keith Owens) 5. RE: Re: [PATCH] head.S fix for unusual load addrs (Luck, Tony) 6. Re: gettimeoffset for 2.5.67 (David Mosberger) 7. Re: Re: [PATCH] head.S fix for unusual load addrs (David Mosberger) 8. Re: Re: [PATCH] head.S fix for unusual load addrs (David Mosberger) 9. Re: Re: [PATCH] head.S fix for unusual load addrs (Jesse Barnes) 10. Re: Running Serial Jobs on IA 64 (Rich Altmaier) 11. Re: Re: [PATCH] head.S fix for unusual load addrs (Jesse Barnes) 12. Re: Re: [PATCH] head.S fix for unusual load addrs (Jesse Barnes) 13. Re: Re: [PATCH] head.S fix for unusual load addrs (Jesse Barnes) 14. Re: Re: [PATCH] head.S fix for unusual load addrs (David Mosberger) --__--__-- Message: 1 From: Bjorn Helgaas To: "Luck, Tony" , Date: Thu, 8 May 2003 13:32:52 -0600 Subject: Re: [Linux-ia64] SAL error record logging/decoding On Wednesday 07 May 2003 6:13 pm, Luck, Tony wrote: > When to clear record from the SAL error log is a thorny question. > There are two conflicting goals: > 1) Making sure that we minimize the chance that we lose error > information ... i.e. we would like to be sure that the error > record was saved to some permanent storage before we clear it > > 2) We need to clear records from the SAL log as soon as we can to > make space for subsequent records to be logged (and to reveal other > records that are already in the log). > > I think that fact that we need to clear a record to see the next one > might force into taking a few risks of losing a message ... which > makes me believe that we need a mechanism to read and delete an error > record from the log and buffer it someplace until it can be picked up > from /proc (rather than using the "clear" command to the /proc > interface that you suggest). I actually implemented such a read/buffer/clear mechanism, but the buffer management makes it much more complicated and I couldn't see any benefit, based on the following reasoning: There's always a window between SAL_CHECK (where the error records are created, consuming buffer space) and SAL_CLEAR_STATE_INFO (where the buffer space is freed). Information about events that occur in that window may be lost, regardless of whether the error records are cleared by the kernel or by a user application. I'm unconvinced by the argument that the kernel should call SAL_CLEAR_STATE_INFO in order to reduce (but not eliminate) the window. Here's a likely scenario that shows why I think we have to make sure the log gets to stable storage before we clear it: - MCA occurs - Linux reboots - Kernel calls SAL_GET_STATE_INFO, copies records to buffer - Kernel calls SAL_CLEAR_STATE_INFO - Kernel panics because MCA corrupted root filesystem Now the MCA error records are lost, and it's not even because SAL ran out of buffer space! We might argue that for this reason, the kernel ought to decode the records to the console, but even then the console output might not be logged, and vital OEM data might not be decoded at all. With my proposal, we at least have the possibility of dumping the error records from the EFI user interface, even if we can no longer boot the kernel. Bjorn --__--__-- Message: 2 From: Jim Wilson To: linux-ia64@linuxia64.org Date: 08 May 2003 13:24:04 -0400 Subject: Re: [Linux-ia64] Building IA-64 toolchain On Thu, 2003-05-08 at 04:21, navin wrote: > ../../gcc-3.2/gcc/config/ia64/fde-glibc.c:42:3: #error You need GLIBC > 2.2.4 or later on IA-64 Linux The glibc copy you are using is too old. This glibc will work with gcc 2.96 (sic), but it won't work with gcc 3. There were related changes made to glibc and gcc to enable unwind info to work correctly, which was needed for C++ exception handling support. Thus you can't use a new gcc with an old glibc or vice versa. David Mosberger mentioned testdrive.hp.com or something like that. Perhaps you could get an account there, and then get a newer copy of the glibc header files from there. Jim --__--__-- Message: 3 From: David Mosberger Date: Thu, 8 May 2003 13:29:36 -0700 To: "Luck, Tony" Cc: , "Jesse Barnes" , "Keith Owens" , Reply-To: davidm@hpl.hp.com Subject: RE: [Linux-ia64] Re: [PATCH] head.S fix for unusual load addrs >>>>> On Thu, 8 May 2003 10:54:05 -0700, "Luck, Tony" said: Tony> In fact it might clear up the long standing issue with Tony> /proc/kcore, if we put the kernel at the low end of region 5 Tony> all the assumptions that module addresses are higher than Tony> kernel addresses will be valid for ia64 too :-) Yes, indeed. Tony> How does this look for an address map? Tony> 0xA000000000000000 kernel text Tony> 0xA000000100000000 kernel data Tony> 0xA000000200000000 percpu area Tony> 0xA000000300000000 vmalloc & kernel modules Tony> 0xBFFFFFFxxxxxxxxx CONFIG_VIRTUAL_MEM_MAP Tony> Reserving an almost arbitrary 4GB for each of kernel Tony> text/data/percpu (I picked 4GB, since it is the biggest page Tony> size supported by ia64 ... but other larger boundaries might Tony> make sense to make the upper level page tables for the vmalloc Tony> area start on a natural boundary). I think we may want to reserve the first 4GB for miscellaneous stuff, such as the start-of-kernel-space-hole, the gate page (and probably soon a read-only page), and the percpu area. In particular the guaranteed-not-to-be-mapped page needs to be right at the end of user space. --david --__--__-- Message: 4 From: Keith Owens To: linux-ia64@linuxia64.org Date: Fri, 09 May 2003 08:17:35 +1000 Subject: Re: [Linux-ia64] Re: [PATCH] head.S fix for unusual load addrs On Thu, 8 May 2003 10:07:49 -0700, David Mosberger wrote: >If we do have to go the virtual remapping route, my preference would >be to stick the kernel somewhere in region 5 (0xa..). Has anyone >tried that? It should work fine in principle (modules already live in >that space). That loses the alt[id]tlb handling for the kernel code and data. Is that going to be a performance problem? --__--__-- Message: 5 Date: Thu, 8 May 2003 15:27:39 -0700 From: "Luck, Tony" To: "Keith Owens" Cc: Subject: RE: [Linux-ia64] Re: [PATCH] head.S fix for unusual load addrs > On Thu, 8 May 2003 10:07:49 -0700,=20 > David Mosberger wrote: > >If we do have to go the virtual remapping route, my preference would > >be to stick the kernel somewhere in region 5 (0xa..). Has anyone > >tried that? It should work fine in principle (modules=20 > already live in > >that space). >=20 > That loses the alt[id]tlb handling for the kernel code and data. Is > that going to be a performance problem? I assume that we are still planning to lock the translations for the kernel into ITR[0] and DTR[0] ... we can still do this with the kernel mapped in region 5. -Tony --__--__-- Message: 6 From: David Mosberger Date: Thu, 8 May 2003 15:24:56 -0700 To: Jes Sorensen Cc: linux-ia64@linuxia64.org, wildos@sgi.com Reply-To: davidm@hpl.hp.com Subject: Re: [Linux-ia64] gettimeoffset for 2.5.67 >>>>> On Thu, 8 May 2003 12:44:47 -0400, Jes Sorensen said: Jes> Here it is finally, the long awaited gettimeoffset patch for 2.5.x. It's Jes> basically a forward port of my fix for 2.4.21, taking into account that Jes> gettimeoffset() returns a nanosecond offset now. Jes> Patch is relative to David's 2.5.67 0416 release. The patch looks largely fine to me. It's missing an update to fsys_gettimeofday() though. In that routine, you need to check whether the ITC_DRIFT flag is on and, if so, fall back on doing the heavy-weight syscall. BTW: There were some unrelated changes in the time code (for CLOCK_MONOTONIC), which make it likely that your patch won't apply. If you don't mind, wait with resubmitting the patch until 2.5.69 is out (hopefully today or tomorrow). But if you don't want to wait, that's OK too, I'll do the merge, if necessary. --david --__--__-- Message: 7 From: David Mosberger Date: Thu, 8 May 2003 15:53:50 -0700 To: Keith Owens Cc: linux-ia64@linuxia64.org Reply-To: davidm@hpl.hp.com Subject: Re: [Linux-ia64] Re: [PATCH] head.S fix for unusual load addrs >>>>> On Fri, 09 May 2003 08:17:35 +1000, Keith Owens said: Keith> On Thu, 8 May 2003 10:07:49 -0700, Keith> David Mosberger wrote: >> If we do have to go the virtual remapping route, my preference would >> be to stick the kernel somewhere in region 5 (0xa..). Has anyone >> tried that? It should work fine in principle (modules already live in >> that space). Keith> That loses the alt[id]tlb handling for the kernel code and data. Is Keith> that going to be a performance problem? Should be OK: I'm assuming you'd use a single (large) pinned TLB entry to map the entire kernel. So no, if anything, performance improves for the kernel itself. --david --__--__-- Message: 8 From: David Mosberger Date: Thu, 8 May 2003 16:32:15 -0700 To: Jesse Barnes Cc: linux-ia64@linuxia64.org Reply-To: davidm@hpl.hp.com Subject: Re: [Linux-ia64] Re: [PATCH] head.S fix for unusual load addrs >>>>> On Thu, 8 May 2003 15:31:14 -0700, Jesse Barnes said: Jesse> On Thu, May 08, 2003 at 10:50:22AM -0700, David Mosberger wrote: Jesse> Right, I thought about that. I don't think we need text Jesse> replication yet though anyway (at least our platform Jesse> doesn't). >> That's what I would have guessed. I think it might be different for >> the 8870 chipset though. Or does it have a huge L4 cache, too? Jesse> If they don't need it, would you be happy taking the simple reloc code Jesse> in elilo? And it seems simple enough, so even if we have to throw it Jesse> away, no big loss. I'm confused. Last time we talked about this, you said something along the lines that you couldn't find the reloc code. In any case, for elilo changes, you have to talk to Stephane. --david --__--__-- Message: 9 Date: Thu, 8 May 2003 17:01:35 -0700 From: Jesse Barnes To: davidm@hpl.hp.com Cc: linux-ia64@linuxia64.org Subject: Re: [Linux-ia64] Re: [PATCH] head.S fix for unusual load addrs On Thu, May 08, 2003 at 04:32:15PM -0700, David Mosberger wrote: > Jesse> If they don't need it, would you be happy taking the simple reloc code > Jesse> in elilo? And it seems simple enough, so even if we have to throw it > Jesse> away, no big loss. > > I'm confused. Last time we talked about this, you said something > along the lines that you couldn't find the reloc code. In any case, > for elilo changes, you have to talk to Stephane. Um, now I'm confused. Couldn't find what? You're right though, I guess the only kernel change we'd need is adding '-q' to the LDFLAGS. Thanks, Jesse --__--__-- Message: 10 Date: Thu, 08 May 2003 17:03:05 -0700 From: Rich Altmaier Organization: SGI To: Zac Morris CC: Linux-IA64@linuxia64.org Subject: Re: [Linux-ia64] Running Serial Jobs on IA 64 Zac, please take a look at this book, online at SGI, which provides some insight into creating parallel programs: http://techpubs.sgi.com/library/tpl/cgi-bin/summary.cgi?coll=linux&db=bks&docnumber=007-4558-003 Click on Table of Contents, Click on Chapter 4. Performance Tuning I hope this is helpful. Thanks! Rich Zac Morris wrote: > > I want to run jobs on a single IA64 box with 4 CPUs. > Will this job be serial or parallel? What should my > machine file look like? > > Appreciate any help!! > > Thanks, > ZAC > --__--__-- Message: 11 Date: Thu, 8 May 2003 17:11:17 -0700 From: Jesse Barnes To: davidm@hpl.hp.com, linux-ia64@linuxia64.org Subject: Re: [Linux-ia64] Re: [PATCH] head.S fix for unusual load addrs On Thu, May 08, 2003 at 05:01:35PM -0700, Jesse Barnes wrote: > On Thu, May 08, 2003 at 04:32:15PM -0700, David Mosberger wrote: > > Jesse> If they don't need it, would you be happy taking the simple reloc code > > Jesse> in elilo? And it seems simple enough, so even if we have to throw it > > Jesse> away, no big loss. > > > > I'm confused. Last time we talked about this, you said something > > along the lines that you couldn't find the reloc code. In any case, > > for elilo changes, you have to talk to Stephane. > > Um, now I'm confused. Couldn't find what? You're right though, I > guess the only kernel change we'd need is adding '-q' to the LDFLAGS. Ah, now I remember--elilo failing when kernels were stripped a certain way. No longer a problem... Thanks, Jesse --__--__-- Message: 12 Date: Thu, 8 May 2003 15:31:14 -0700 From: Jesse Barnes To: davidm@hpl.hp.com Cc: linux-ia64@linuxia64.org Subject: Re: [Linux-ia64] Re: [PATCH] head.S fix for unusual load addrs On Thu, May 08, 2003 at 10:50:22AM -0700, David Mosberger wrote: > Jesse> Right, I thought about that. I don't think we need text > Jesse> replication yet though anyway (at least our platform > Jesse> doesn't). > > That's what I would have guessed. I think it might be different for > the 8870 chipset though. Or does it have a huge L4 cache, too? If they don't need it, would you be happy taking the simple reloc code in elilo? And it seems simple enough, so even if we have to throw it away, no big loss. Thanks, Jesse --__--__-- Message: 13 Date: Fri, 9 May 2003 10:52:25 -0700 From: Jesse Barnes To: "Luck, Tony" Cc: davidm@hpl.hp.com, linux-ia64@linuxia64.org Subject: Re: [Linux-ia64] Re: [PATCH] head.S fix for unusual load addrs On Wed, May 07, 2003 at 04:24:09PM -0700, Luck, Tony wrote: > 1) My patch (posted around October last year) which picked virtual addresses > in the wild blue yonder (initial versions used 0xe002000000000000, later ones > used 0xffffffff00000000) for the link address for the kernel. Elilo can load > kernel at any suitably aligned physical address, and head.S establishes the > mappings using itr[0] and dtr[0]. > > pros) provided separate maps for kernel text and data, so supported kernel text > replication too. > cons) __pa() no longer works on kernel addresses, use new __tpa() instead. > Some ugly runtime patching of kernel code to get physical address of > swapper_pg_dir into the TLB miss code. > > 2) I think SGI are currently running a modified version of #1 without the text > replication support, and that provides a mapping from the normal virtual > address that the kernel is linked for (0xe00000000044000000) to whatever physical > address it was actually loaded at ... at least I think that's what Jack said. > > pros) simpler than my patch > > cons) Still needs __tpa() instead of __pa() for kernel addresses. > > 3) David's suggestion of boot-time relocation. Probably simplest to implement > this in elilo, but if you are really good at PIC asm code it could be done in > the kernel startup sequence. > > pros) Just like linking kernel at a new address. > Avoids the __tpa() issue. > Doesn't invalidate any assumptions about how to get from virtual to > physical addresses and back again. > > cons) Nobody has implemented it. doesn't address text replication concerns, while (1) and (2) do So, is there any consensus on the best path to pursue? Chris Wedgwood is working on option #3, and I've got Tony's patch trimmed down to #2 (with one piece missing--ia64_switch_to runtime patching), but none of these are in either 2.4 or 2.5 yet. Maybe for 2.4 we should do #2 or #3 and for 2.5 we could implement #1 with the virtual offsets Tony mentioned earlier? Thanks, Jesse --__--__-- Message: 14 From: David Mosberger Date: Fri, 9 May 2003 11:25:29 -0700 To: Jesse Barnes Cc: "Luck, Tony" , davidm@hpl.hp.com, linux-ia64@linuxia64.org Reply-To: davidm@hpl.hp.com Subject: Re: [Linux-ia64] Re: [PATCH] head.S fix for unusual load addrs >>>>> On Fri, 9 May 2003 10:52:25 -0700, Jesse Barnes said: Jesse> So, is there any consensus on the best path to pursue? Chris Wedgwood Jesse> is working on option #3, and I've got Tony's patch trimmed down to #2 Jesse> (with one piece missing--ia64_switch_to runtime patching), but none of Jesse> these are in either 2.4 or 2.5 yet. Maybe for 2.4 we should do #2 or Jesse> #3 and for 2.5 we could implement #1 with the virtual offsets Tony Jesse> mentioned earlier? I'm not sure. I got the impression Tony may be looking at the virtual remapping in region 5. I haven't heard whether text replication turned out to be important for 8870, but I'm starting to lean towards virtual remapping because it is more versatile (can handle both "strange" physical memory layouts and kernel replication). This, coupled with the fact that it doesn't break any of the existing tools makes it pretty compelling. Also, my primary objection about making the kernel model more complicated doesn't hold much water if we move everything to region 5. Would there be a downside to this on SGI's machines? --david --__--__-- _______________________________________________ Linux-IA64 mailing list Linux-IA64@linuxia64.org http://lists.linuxia64.org/lists/listinfo/linux-ia64 End of Linux-IA64 Digest