From tinglett at vnet.ibm.com Tue Jul 9 05:28:45 2002 From: tinglett at vnet.ibm.com (Todd Inglett) Date: 08 Jul 2002 14:28:45 -0500 Subject: lkcd is in... Message-ID: <1026156528.17261.39.camel@q.rchland.ibm.com> I just checked in a minimal set of Linux Kernel Crash Dump (lkcd) changes into our internal tree. I'll package up the user mode code real soon...but I think there are a few kinks to work out yet. It has had little testing other than sysrq-c, for example :). I don't like the code that IPI's for processors to save state. This will likely get stuck. If we had pSeries soft disable we could emulate an NMI which could be useful for the debugger too. I also don't care for the fact that interrupts are required to write to disk. The lkcd guys are working on this, but it would be nice if the hypervisor (if in use) could help out like it does for OS/400 dumps on iSeries. Someday... :) -todd ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Tue Jul 16 10:28:28 2002 From: anton at samba.org (Anton Blanchard) Date: Mon, 15 Jul 2002 17:28:28 -0700 Subject: 64bit glibc Message-ID: <20020716002828.GA19399@krispykreme> Hi, I just had a look over 64 bit glibc and have some random thoughts. 1. I compared us with x86-64 and noticed they have unsigned long st_dev, st_ino, st_nlink in their stat structures. They also reserve space for nanoseconds in some of the ipc structs. 2. The overflow of the TOC is nasty. I just got it while compiling samba. We need to fix it one way or another. Compiling everything with -mminimal-toc is not a great solution, we should either make gcc much more efficient at TOC usage or else add a mixed mode 32/64 bit target to gcc. Thoughts? Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From dje at watson.ibm.com Tue Jul 16 11:57:47 2002 From: dje at watson.ibm.com (David Edelsohn) Date: Mon, 15 Jul 2002 21:57:47 -0400 Subject: 64bit glibc In-Reply-To: Message from Anton Blanchard of "Mon, 15 Jul 2002 17:28:28 PDT." <20020716002828.GA19399@krispykreme> Message-ID: <200207160157.VAA30182@makai.watson.ibm.com> >>>>> Anton Blanchard writes: Anton> 2. The overflow of the TOC is nasty. I just got it while compiling Anton> samba. We need to fix it one way or another. Compiling everything with Anton> -mminimal-toc is not a great solution, we should either make gcc much Anton> more efficient at TOC usage or else add a mixed mode 32/64 bit target Anton> to gcc. Thoughts? Much more efficient TOC usage is quite attainable, but it requires GCC being smarter about storage pools. Other work-arounds are non-starters in my book. David ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From ssrikrishnan at yahoo.com Fri Jul 19 01:34:14 2002 From: ssrikrishnan at yahoo.com (Srikrishnan Sundararajan) Date: Thu, 18 Jul 2002 08:34:14 -0700 (PDT) Subject: addnote : zImage is not a big-endian 32-bit ELF image Message-ID: <20020718153414.37205.qmail@web20414.mail.yahoo.com> Hi, I'm trying to compile the kernel for ppc64 on an RS6000 machine. While doing 'make zImage', I get the following error: ./addnote zImage zImage is not a big-endian 32-bit ELF image. make[1]: *** [zImage] Error 1 make[1]: Leaving directory '/usr/src/linux-2.4.13.Suse/arch/ppc64/boot' Upon reading the addnote.c file, I find that this error message is printed if either of the following is not found as part of the zImage's ELF signature. ELFCLASS32 (for 32-bit I guess) and ELFDATA2MSB(For big-endian) Am I missing any thing? Any help will be appreciated. srikrishnan ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From ken at tossell.net Fri Jul 19 05:25:34 2002 From: ken at tossell.net (Ken Tossell) Date: Thu, 18 Jul 2002 15:25:34 -0400 Subject: addnote : zImage is not a big-endian 32-bit ELF image In-Reply-To: <20020718153414.37205.qmail@web20414.mail.yahoo.com> References: <20020718153414.37205.qmail@web20414.mail.yahoo.com> Message-ID: <1027020334.3d37162e5b9b4@mail.tossell.net> Quoting Srikrishnan Sundararajan : > > Hi, > I'm trying to compile the kernel for ppc64 on an > RS6000 machine. While doing 'make zImage', I get the > following error: > > ./addnote zImage > zImage is not a big-endian 32-bit ELF image. > make[1]: *** [zImage] Error 1 > make[1]: Leaving directory > '/usr/src/linux-2.4.13.Suse/arch/ppc64/boot' > > Upon reading the addnote.c file, I find that this > error message is printed if either of the following is > not found as part of the zImage's ELF signature. > ELFCLASS32 (for 32-bit I guess) and ELFDATA2MSB(For > big-endian) > > Am I missing any thing? Any help will be appreciated. > > srikrishnan > > > > Which patch did you apply? Also, it might be better to use the 2.4.19-rc1 kernel. It is very stable. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Fri Jul 19 07:31:23 2002 From: anton at samba.org (Anton Blanchard) Date: Thu, 18 Jul 2002 14:31:23 -0700 Subject: [Fwd: [Linuxppc-dev] Re: [Linuxppc-cvs64] CVS: linuxppc64_2_4/arch/ppc64/kernel head.S,1.32.6.1,1.32.6.2] In-Reply-To: <3D1B7C0D.88310356@vnet.ibm.com> References: <3D138804.FE96871@vnet.ibm.com> <20020621211523.GA15846@krispykreme> <3D1B7C0D.88310356@vnet.ibm.com> Message-ID: <20020718213123.GA20710@krispykreme> > I'm not sure that we have other exposures like this one. Certainly in > the case we have identified, we should be ok. The text is bolted in > the SLB so the only exception should be on the stack address segment. > As long as the kernel stack is aligned to its size, we will only take > the one exception & then the stack should be ok. At this point, we > are hard disabled and all addresses are bolted in the HPT. I agree the current fix is the way to go for 2.4. In 2.5 Im going to experiment with replaying exception exit since the SLB cast out path will be heavily hit on workloads with very large memory footprints. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From bergner at brule.borg.umn.edu Tue Jul 23 05:47:18 2002 From: bergner at brule.borg.umn.edu (Peter Bergner) Date: Mon, 22 Jul 2002 14:47:18 -0500 Subject: real mode limit Message-ID: <20020722144718.A817400@brule.borg.umn.edu> Anton wrote: : Peter checked a fix in to move the RTAS region to just under 4GB. In 2.5 : I am currently allocating it where the kernel was. (ie about 20MB) : : My question is how does this all fit in with a 256MB real mode limit : (which we need to go to for hot swap memory). Is there any reason for : allocating the region so high in the 4G space? It doesn't. Do do it "right", we need to detect how big the RMO region is and allocate it within min(RMO size, partition size, 4G). Anyone know how to get the RMO size? It'd be nice if it were a OF variable... Peter ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From bergner at brule.borg.umn.edu Tue Jul 23 05:52:01 2002 From: bergner at brule.borg.umn.edu (Peter Bergner) Date: Mon, 22 Jul 2002 14:52:01 -0500 Subject: 2.5 Message-ID: <20020722145201.A834206@brule.borg.umn.edu> Anton wrote: : I have some rather large patches I want to commit next: changing r13 : to point to the processor data area and remove all of RELOC() and : reworking most of head.S. How do you plan on removing RELOC()? IIRC, Alan mentioned we cannot play the same trick ppc32 did to get rid of the RELOC()'s. Did you have something else in mind? Perhaps pushing the OF calls into the zImage wrapper? Peter ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From bergner at brule.borg.umn.edu Tue Jul 23 05:52:22 2002 From: bergner at brule.borg.umn.edu (Peter Bergner) Date: Mon, 22 Jul 2002 14:52:22 -0500 Subject: 2.5 Message-ID: <20020722145201.A834206@brule.borg.umn.edu> Anton wrote: : I have some rather large patches I want to commit next: changing r13 : to point to the processor data area and remove all of RELOC() and : reworking most of head.S. How do you plan on removing RELOC()? IIRC, Alan mentioned we cannot play the same trick ppc32 did to get rid of the RELOC()'s. Did you have something else in mind? Perhaps pushing the OF calls into the zImage wrapper? Peter ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Tue Jul 23 06:20:54 2002 From: anton at samba.org (Anton Blanchard) Date: Tue, 23 Jul 2002 06:20:54 +1000 Subject: real mode limit In-Reply-To: <20020722144718.A817400@brule.borg.umn.edu> References: <20020722144718.A817400@brule.borg.umn.edu> Message-ID: <20020722202054.GA18937@krispykreme> > It doesn't. Do do it "right", we need to detect how big the RMO region > is and allocate it within min(RMO size, partition size, 4G). > > Anyone know how to get the RMO size? It'd be nice if it were a OF variable... The safe thing here is to always allocate it in the first 256MB, since we will want that for DLPAR. PS Milton also reminded me that we need to make sure the region does not cross a segment boundary. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Tue Jul 23 06:24:45 2002 From: anton at samba.org (Anton Blanchard) Date: Tue, 23 Jul 2002 06:24:45 +1000 Subject: 2.5 In-Reply-To: <20020722145201.A834206@brule.borg.umn.edu> References: <20020722145201.A834206@brule.borg.umn.edu> Message-ID: <20020722202445.GB18937@krispykreme> > How do you plan on removing RELOC()? IIRC, Alan mentioned we cannot > play the same trick ppc32 did to get rid of the RELOC()'s. Did you > have something else in mind? Perhaps pushing the OF calls into the > zImage wrapper? At this stage I am just copying the kernel to its final location and relying on the architecture to drop the upper two bits on addresses when in real mode. I store the exception vectors in an init section and copy them in when I am finished with OF. I agree putting them into a zImage wrapper is the way to go in the future, but I cant see myself having the time in the next few months before the code freeze. Do any of you guys look like you will have the time? This interim step at least cleans up prom.c a whole lot. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Tue Jul 23 10:57:49 2002 From: anton at samba.org (Anton Blanchard) Date: Tue, 23 Jul 2002 10:57:49 +1000 Subject: 2.4 zImage rework Message-ID: <20020723005749.GB20719@krispykreme> Hi, When rerunning make zImage, I get an error: /usr/local/ppc64/bin/powerpc64-linux-nm -n /home/anton/ppc64/linuxppc64_2_4/vmlinux | tail -1 | awk '{printf "unsigned long vmlinux_memsize = 0x%s;\n", substr($1,8)}' >> imagesize.c gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -I/home/anton/ppc64/linuxppc64_2_4/include -c -o imagesize.o imagesize.c gzip -cvf9 /home/anton/ppc64/linuxppc64_2_4/vmlinux > kernel-vmlinux.gz /home/anton/ppc64/linuxppc64_2_4/vmlinux: 69.7% /usr/local/ppc64/bin/powerpc64-linux-objcopy zImage.o \ --add-section=.kernel:vmlinux=kernel-vmlinux.gz \ --set-section-flags=.kernel:vmlinux=contents,alloc,load,readonly,data /usr/local/ppc64/bin/powerpc64-linux-objcopy: stnXfLy8: Bad value make[1]: *** [vmlinux] Error 1 make[1]: Leaving directory `/home/anton/ppc64/linuxppc64_2_4/arch/ppc64/boot' make: *** [zImage.initrd] Error 2 If I rm arch/ppc64/boot/zImage.o and make again it works OK. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From amodra at bigpond.net.au Tue Jul 23 11:28:34 2002 From: amodra at bigpond.net.au (Alan Modra) Date: Tue, 23 Jul 2002 10:58:34 +0930 Subject: 2.4 zImage rework In-Reply-To: <20020723005749.GB20719@krispykreme> References: <20020723005749.GB20719@krispykreme> Message-ID: <20020723012834.GM30362@bubble.sa.bigpond.net.au> On Tue, Jul 23, 2002 at 10:57:49AM +1000, Anton Blanchard wrote: > > /usr/local/ppc64/bin/powerpc64-linux-objcopy zImage.o \ > --add-section=.kernel:vmlinux=kernel-vmlinux.gz \ > --set-section-flags=.kernel:vmlinux=contents,alloc,load,readonly,data > /usr/local/ppc64/bin/powerpc64-linux-objcopy: stnXfLy8: Bad value > make[1]: *** [vmlinux] Error 1 > make[1]: Leaving directory > `/home/anton/ppc64/linuxppc64_2_4/arch/ppc64/boot' > make: *** [zImage.initrd] Error 2 > > If I rm arch/ppc64/boot/zImage.o and make again it works OK. I guess zImage.o isn't being recompiled, so you're trying to add a .kernel section that already exists. objcopy ought to give a better error message, but it sounds like you need to fix the makefile too. -- Alan Modra IBM OzLabs - Linux Technology Centre ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From tinglett at vnet.ibm.com Wed Jul 24 12:12:17 2002 From: tinglett at vnet.ibm.com (Todd Inglett) Date: 23 Jul 2002 21:12:17 -0500 Subject: addnote : zImage is not a big-endian 32-bit ELF image In-Reply-To: <20020718153414.37205.qmail@web20414.mail.yahoo.com> References: <20020718153414.37205.qmail@web20414.mail.yahoo.com> Message-ID: <1027476738.2853.21.camel@z3.home> On Thu, 2002-07-18 at 10:34, Srikrishnan Sundararajan wrote: > > Hi, > I'm trying to compile the kernel for ppc64 on an > RS6000 machine. While doing 'make zImage', I get the > following error: > > ../addnote zImage > zImage is not a big-endian 32-bit ELF image. > make[1]: *** [zImage] Error 1 > make[1]: Leaving directory > '/usr/src/linux-2.4.13.Suse/arch/ppc64/boot' Try "file arch/ppc64/boot/zImage". Is it a 32-bit ELF executable? If not, delete it and make zImage again, this time watching carefully how zImage gets compiled & linked. The most obvious problem would be that you are cross compiling on some other architecture (e.g. x86 producing x86 binaries). If so, read arch/ppc64/boot/Makefile and you will need to set CROSS32_COMPILE to point to your gcc 32-bit cross compiler. If you don't have a 32-bit gcc you can either skip building a zImage (e.g. use yaboot to boot the vmlinux directly), or you can build your own 32-bit gcc. Use the same sources you used to build the 64-bit gcc, but configure it for powerpc-linux. -todd ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From bergner at borg.umn.edu Thu Jul 25 06:25:08 2002 From: bergner at borg.umn.edu (Peter Bergner) Date: Wed, 24 Jul 2002 15:25:08 -0500 Subject: real mode limit Message-ID: <20020724202508.GA89738@congo.borg.umn.edu> Todd Inglett: : I already warned Pete that he'll have to deal with the RMO size. : Hopefully he will get to it soon (just back from a long vacation) :). : : Offhand I'm not sure how to determine the RMO size. It's encoded in a : HID reg that I'm sure we can't read. We could just allocate just under : 256MB when under a hypervisor, I suppose, even though current systems : are 1GB. Ok, Dave found out that the RMO region for an LPAR system is just the first LMB region. Getting late now, so I'll fix that in prom.c to read that value in the morning. Peter ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From engebret at vnet.ibm.com Sat Jul 27 06:09:03 2002 From: engebret at vnet.ibm.com (Dave Engebretsen) Date: Fri, 26 Jul 2002 15:09:03 -0500 Subject: [announce] New ppc64 kernel available (2.4.19-rc3) Message-ID: <3D41AC5F.A5BF069E@vnet.ibm.com> A new patch for the linux/ppc64 kernel has been released for the iSeries and pSeries platforms. This patch upgrades the kernel to 2.4.19-rc3. This patch is primarily just an update to rc3. A change log as well as links to the patch and the base code it applies against can be found at: http://www.linuxppc64.org/source.shtml Dave Engebretsen, IBM ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From engebret at vnet.ibm.com Sat Jul 27 06:13:08 2002 From: engebret at vnet.ibm.com (Dave Engebretsen) Date: Fri, 26 Jul 2002 15:13:08 -0500 Subject: [announce] New ppc64 kernel available (2.4.13) Message-ID: <3D41AD54.6FE9F6EA@vnet.ibm.com> A new patch for the linux/ppc64 kernel has been released for the iSeries and pSeries platforms. This patch is for the 2.4.13 branch, and is primarily bug fixes. A change log as well as links to the patch and the base code it applies against can be found at: http://www.linuxppc64.org/source.shtml Dave Engebretsen, IBM ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/