[Linux-ia64] RE: Linux-IA64 digest, i want mailing list

["정 종준" <CJJUNG@digitalhenge.com>]

[-- Attachment #1: Type: text/plain, Size: 19878 bytes --]

 

	-----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 <bjorn_helgaas@hp.com>
	To: "Luck, Tony" <tony.luck@intel.com>, <linux-ia64@linuxia64.org>
	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 <wilson@tuliptree.org>
	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 <davidm@napali.hpl.hp.com>
	Date: Thu, 8 May 2003 13:29:36 -0700
	To: "Luck, Tony" <tony.luck@intel.com>
	Cc: <davidm@hpl.hp.com>, "Jesse Barnes" <jbarnes@sgi.com>,
	        "Keith Owens" <kaos@ocs.com.au>, <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 10:54:05 -0700, "Luck, Tony" <tony.luck@intel.com> 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 <kaos@ocs.com.au>
	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 <davidm@napali.hpl.hp.com> 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" <tony.luck@intel.com>
	To: "Keith Owens" <kaos@ocs.com.au>
	Cc: <linux-ia64@linuxia64.org>
	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 <davidm@napali.hpl.hp.com> 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 <davidm@napali.hpl.hp.com>
	Date: Thu, 8 May 2003 15:24:56 -0700
	To: Jes Sorensen <jes@wildopensource.com>
	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 <jes@wildopensource.com> 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 <davidm@napali.hpl.hp.com>
	Date: Thu, 8 May 2003 15:53:50 -0700
	To: Keith Owens <kaos@ocs.com.au>
	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 <kaos@ocs.com.au> said:
	
	  Keith> On Thu, 8 May 2003 10:07:49 -0700,
	  Keith> David Mosberger <davidm@napali.hpl.hp.com> 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 <davidm@napali.hpl.hp.com>
	Date: Thu, 8 May 2003 16:32:15 -0700
	To: Jesse Barnes <jbarnes@sgi.com>
	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 <jbarnes@sgi.com> 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 <jbarnes@sgi.com>
	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 <richa@engr.sgi.com>
	Organization: SGI
	To: Zac Morris <zorro7_98@yahoo.com>
	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 <jbarnes@sgi.com>
	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 <jbarnes@sgi.com>
	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 <jbarnes@sgi.com>
	To: "Luck, Tony" <tony.luck@intel.com>
	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 <davidm@napali.hpl.hp.com>
	Date: Fri, 9 May 2003 11:25:29 -0700
	To: Jesse Barnes <jbarnes@sgi.com>
	Cc: "Luck, Tony" <tony.luck@intel.com>, 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 <jbarnes@sgi.com> 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
	


[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 23067 bytes --]