From tinglett at vnet.ibm.com Thu May 1 11:59:40 2003 From: tinglett at vnet.ibm.com (Todd Inglett) Date: 30 Apr 2003 20:59:40 -0500 Subject: Cross compiling the kernel In-Reply-To: <207D6ADFC044A84686D44CA11B297EEA02018A1B@chn-ex02.cvns.corp.covansys.com> References: <207D6ADFC044A84686D44CA11B297EEA02018A1B@chn-ex02.cvns.corp.covansys.com> Message-ID: <1051754380.7225.29.camel@a4.home> Also note that when you get to the build of zImage you need to be aware that it builds as a 32-bit executable. That means you also need a ppc32 cross compiler. See arch/ppc64/boot/Makefile. -- Todd Inglett ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From SVakkalankarao at covansys.com Thu May 1 17:29:55 2003 From: SVakkalankarao at covansys.com (VAKKALANKA RAO Sridhar) Date: Thu, 1 May 2003 12:59:55 +0530 Subject: Cross compiling the kernel Message-ID: <207D6ADFC044A84686D44CA11B297EEA02018A1E@chn-ex02.cvns.corp.covansys.com> Thank you Todd, Let me get this right. For zImage, I need a 32 bit gcc (--target=powerpc-linux for the gcc toolchain configuration) as opposed to a 64 bit gcc (--target=powerpc64-linux for the gcc toolchain configuration). Is that right? This brings me to a more fundamental question, which takes me back to a stage even before I download the kernel sources (please bear with me as I am doing this for the first time). When I build the toolchain for the first pass (binutils & gcc), I set the binutils configuration to --target=powerpc-linux --enable_targets=powerpc64-linux. As a result, the subsequent "make" & "make install" create the directory /opt/ppc64/powerpc-linux. They also create binaries with the full path /opt/ppc64/bin/powerpc-linux-XX. So, obviously when I configure gcc with --target=powerpc64-linux (as opposed to --target=powerpc-linux), the build fails. In order to solve this, I went into the directory /opt/ppc64 and executed the command "ln -s /opt/ppc64/powerpc-linux /opt/ppc64/powerpc64-linux". Subsequently, I went into the directory /opt/ppc64/bin and executed the commands "ln /opt/ppc64/bin/powerpc-linux-XX /opt/ppc64/bin/powerpc64-linux-XX" for each binary XX. Please tell me if creating these links was the correct thing to do. When configuring binutils with --enable_targets=powerpc64-linux, is it possible that I did something wrong which is why the subsequent gcc toolchain configuration failed? Also, if I am to cross-compile the kernel with a 32-bit gcc, how is it possible for my 64 bit machine to take advantage of its 64-bit features? Please give me an answer. Once again thanks Olaf and Todd. Sri ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Tue May 6 03:46:54 2003 From: anton at samba.org (Anton Blanchard) Date: Tue, 6 May 2003 03:46:54 +1000 Subject: async IO wrappers Message-ID: <20030505174654.GA1153@krispykreme> Hi, Andrew Morton is carrying my 32bit emulation patch for AIO, it can be found at: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.69/2.5.69-mm1/broken-out/ppc64-aio-32bit-emulation.patch Hopefully it will make its way into the generic compat layer, if not I'll check it into the ppc64 specific area. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From DJ at de.ibm.com Fri May 9 01:39:22 2003 From: DJ at de.ibm.com (Denis J Barrow) Date: Thu, 8 May 2003 17:39:22 +0200 Subject: re 2.5 Message-ID: I am also trying to get linuxppc64 2.5 going with a matrox card on a regatta 630. The matrox fb is switched off by default in the 2.5.66 kernel from IBM & this code unfortunately doesnt compile because the guy developing the matrox driver hasn't updated his code to the new 2.5 framebuffer driver model. The begining of the problem is him trying to include video/fbcon-cfb32.h which doesn't exist in 2.5 The problem is still there in 2.5.69 This is a patch posted on the mailing list which you maybe able to wrestle into working. http://www.ussg.iu.edu/hypermail/linux/kernel/0212.3/0214.html It might be possible to get a kernel going without framebuffer support but my 2.4.19 kernel uses it. D.J. Barrow Linux Kernel Developer dj at de.ibm.com,barrow_dj at yahoo.com Phone:0049-7031-16-2943 ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From DJ at de.ibm.com Fri May 9 02:20:14 2003 From: DJ at de.ibm.com (Denis J Barrow) Date: Thu, 8 May 2003 18:20:14 +0200 Subject: 2.5 kernel on Power3 Message-ID: sorry guys, the patch link on the last email was wrong & even the subject was wrong Try http://platan.vc.cvut.cz/ftp/pub/linux/matrox-latest he has some 2.5 patches there there is also another patch running around which puts the fbcon-cfb stuff back into 2.5 available here http://www.ussg.iu.edu/hypermail/linux/kernel/0212.3/0214.html >I am also trying to get linuxppc64 2.5 going with a matrox card on a regatta 630. >The matrox fb is switched off by default in the 2.5.66 kernel from IBM & this code unfortunately doesnt compile >because the guy developing the matrox driver hasn't updated his code to the new 2.5 framebuffer driver model. >The begining of the problem is him trying to include video/fbcon-cfb32.h which doesn't exist in 2.5 >The problem is still there in 2.5.69 D.J. Barrow Linux Kernel Developer dj at de.ibm.com,barrow_dj at yahoo.com Phone:0049-7031-16-2943 ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From SVakkalankarao at covansys.com Wed May 14 15:30:13 2003 From: SVakkalankarao at covansys.com (VAKKALANKA RAO Sridhar) Date: Wed, 14 May 2003 11:00:13 +0530 Subject: Installing the kernel zImage and glibc Message-ID: <207D6ADFC044A84686D44CA11B297EEA02018A26@chn-ex02.cvns.corp.covansys.com> Hello, I successfully built a kernel zImage & glibc (pass 2) for ppc64 and I am on to my next problem. i.e. using yaboot to install ppc64 linux into a p630-6E4. My p630-6E4 was shipped installed with a target AIX 5.1 operating system and it contains no development environment. As a result, (1) I cannot compile the yaboot source tarball and (2) downloading the binary is no help, because this binary is not AIX compatible. How do I proceed from here on? The zImage & glibc were compiled on an i686 with Redhat 8.0. This machine is connected to my p630 via a LAN, which is why I am considering a net boot. Somebody please give me an answer. In addition, if it is not necessary for me to use yaboot and other alternatives exist, please let me know. Thanks Sri ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From miltonm at realtime.net Thu May 15 04:19:20 2003 From: miltonm at realtime.net (Milton D. Miller II) Date: Wed, 14 May 2003 13:19:20 -0500 (CDT) Subject: Installing the kernel zImage and glibc Message-ID: <200305141819.h4EIJKlu085904@sullivan.realtime.net> Your plan of doing a netboot sounds like a good one. If you need a ramdisk for your installer, then I suggest making a zImage.initrd rather than *adding* netboot support to yaboot for rs/6k :-) You need to (1) set a bootp server (isc dhcpd works, with approprate config -- set a fixed-address by mac, you can get that either from the fw menu or from aix lsattr -El eth0). Put the zImage on your tftp server and point the boot to it. You can load an image upto 8M without any boot variable fiddling. PS: netbooting a zImage is a well tested path :) milton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From linas at austin.ibm.com Wed May 21 06:18:58 2003 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Tue, 20 May 2003 15:18:58 -0500 Subject: IDE & byte-swapping in 2.4.21 Message-ID: <20030520151858.A27184@forte.austin.ibm.com> Hi, I'm trying to debug a confusing IDE byteswapping bug in 2.4.21 on ppc64, and want to fish for some comments before I go off in the wrong direction. If you think you understand byteswapping, please help me out! Let me start at the begining: IDE in 2.4.21 in ppc64 doesn't work. I discovered that if I go into ide-iops.c and disable bytsewapping in the ide_fix_driveid() routine, then I can get IDE to sort-of work... it works in that I can create partions, fs, and read/write files. Unfortunately, the resulting partition tables & etc. are byte-swapped from 'normal': my whacked ide code cannot read ide drives from x86 bboxes, or from 2.4.19 ppc boxes. The 2.4.19 code uses insw() for PIO (in drivers/ide/ide.c/ide_input_data()) and both ppc and ppc64 #define insw _insw_ns with comments suggesting that 'ns' stands for no-swap. Then routines like ppc64_ide_fix_driveid() perform the actual swap, and everything works. The 2.4.21 code introduces some new routines: ide_mm_insw() and its cousins in drivers/ide/ide-iops.c. These are similar, but crucially different from ide_insw(). Whereas the latter call insw(), the former call readw(), and this difference seems to be very very intentional. On ppc and ppc64, readw map to in_le16 calls (which swap bytes), whereas insw calls do not. This seems to be at the root of the problem. There's just enough mapping and redirection & etc. in this code that I haven't quite figured out what the intent was, and therefore, haven't really figured out what the right fix is ... is it in the ide code? In the ppc64-specific code? Am I the only big-endian platform with this problem? Have other big-endian platforms tested? --linas ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From andre at linux-ide.org Wed May 21 08:17:44 2003 From: andre at linux-ide.org (Andre Hedrick) Date: Tue, 20 May 2003 15:17:44 -0700 (PDT) Subject: IDE & byte-swapping in 2.4.21 In-Reply-To: <20030520151858.A27184@forte.austin.ibm.com> Message-ID: Linas, All you need to do is override the io operations in the struct and install you own functions-pointers. Cheers, On Tue, 20 May 2003 linas at austin.ibm.com wrote: > > I'm trying to debug a confusing IDE byteswapping bug in 2.4.21 on > ppc64, and want to fish for some comments before I go off in the wrong > direction. If you think you understand byteswapping, please help me > out! > > Let me start at the begining: IDE in 2.4.21 in ppc64 doesn't work. > > I discovered that if I go into ide-iops.c and disable bytsewapping in > the ide_fix_driveid() routine, then I can get IDE to sort-of work... > it works in that I can create partions, fs, and read/write files. > Unfortunately, the resulting partition tables & etc. are byte-swapped > from 'normal': my whacked ide code cannot read ide drives from x86 > bboxes, or from 2.4.19 ppc boxes. > > The 2.4.19 code uses insw() for PIO (in > drivers/ide/ide.c/ide_input_data()) and both ppc and ppc64 #define > insw _insw_ns with comments suggesting that 'ns' stands for no-swap. > Then routines like ppc64_ide_fix_driveid() perform the actual swap, > and everything works. > > The 2.4.21 code introduces some new routines: ide_mm_insw() and its > cousins in drivers/ide/ide-iops.c. These are similar, but crucially > different from ide_insw(). Whereas the latter call insw(), the former > call readw(), and this difference seems to be very very intentional. > On ppc and ppc64, readw map to in_le16 calls (which swap bytes), > whereas insw calls do not. This seems to be at the root of the > problem. > > There's just enough mapping and redirection & etc. in this code that I > haven't quite figured out what the intent was, and therefore, haven't > really figured out what the right fix is ... is it in the ide code? In > the ppc64-specific code? Am I the only big-endian platform with this > problem? Have other big-endian platforms tested? Andre Hedrick LAD Storage Consulting Group ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From paulus at samba.org Wed May 21 10:53:44 2003 From: paulus at samba.org (Paul Mackerras) Date: Wed, 21 May 2003 10:53:44 +1000 Subject: IDE & byte-swapping in 2.4.21 In-Reply-To: <20030520151858.A27184@forte.austin.ibm.com> References: <20030520151858.A27184@forte.austin.ibm.com> Message-ID: <16074.52760.823968.563326@argo.ozlabs.ibm.com> linas at austin.ibm.com writes: > Let me start at the begining: IDE in 2.4.21 in ppc64 doesn't work. You must be from the future, 2.4.21 hasn't been released yet in my version of the universe. :) Seriously, what -pre or -rc version are you running? > I discovered that if I go into ide-iops.c and disable bytsewapping > in the ide_fix_driveid() routine, then I can get IDE to sort-of work... > it works in that I can create partions, fs, and read/write files. No, this isn't the right approach. > Unfortunately, the resulting partition tables & etc. are byte-swapped > from 'normal': my whacked ide code cannot read ide drives from > x86 bboxes, or from 2.4.19 ppc boxes. > > The 2.4.19 code uses insw() for PIO (in drivers/ide/ide.c/ide_input_data()) > and both ppc and ppc64 #define insw _insw_ns with comments suggesting > that 'ns' stands for no-swap. Then routines like ppc64_ide_fix_driveid() > perform the actual swap, and everything works. The reason is that the IDE code uses the insw/insl/outsw/outsl routines to transfer buffers of bytes. Because we are actually dealing with bytes at this level, rather than 16-bit or 32-bit integers, it is not appropriate to byte-swap. > The 2.4.21 code introduces some new routines: ide_mm_insw() and its > cousins in drivers/ide/ide-iops.c. These are similar, but crucially > different from ide_insw(). Whereas the latter call insw(), the former > call readw(), and this difference seems to be very very intentional. > On ppc and ppc64, readw map to in_le16 calls (which swap bytes), whereas > insw calls do not. This seems to be at the root of the problem. The official 2.4.21-rc2 has ide_mm_insw calling __ide_mm_insw, which doesn't appear to be defined for ppc64. On ppc32, we define it to _insw_ns, which doesn't byte-swap. You probably want something similar on ppc64. > There's just enough mapping and redirection & etc. in this code that > I haven't quite figured out what the intent was, and therefore, haven't > really figured out what the right fix is ... is it in the ide code? > In the ppc64-specific code? Am I the only big-endian platform with > this problem? Have other big-endian platforms tested? No, yes, probably, yes. IDE works fine on ppc32 (except for the problems with CF cards on powerbooks with IDE interfaces with no attached drives, but that's another story). Paul. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From benh at kernel.crashing.org Wed May 21 19:06:07 2003 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: 21 May 2003 11:06:07 +0200 Subject: IDE & byte-swapping in 2.4.21 In-Reply-To: <16074.52760.823968.563326@argo.ozlabs.ibm.com> References: <20030520151858.A27184@forte.austin.ibm.com> <16074.52760.823968.563326@argo.ozlabs.ibm.com> Message-ID: <1053507967.17223.5.camel@gaston> > No, yes, probably, yes. IDE works fine on ppc32 (except for the > problems with CF cards on powerbooks with IDE interfaces with no > attached drives, but that's another story). BTW. That one should be fixed in my tree. Alan took the patch to the core IDE code to "reserve" interfaces, once it gets to Marcelo (probably not before 2.4.22-*), I'll send an update to ide/ppc/pmac.c Ben. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From benh at kernel.crashing.org Wed May 21 19:09:43 2003 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: 21 May 2003 11:09:43 +0200 Subject: IDE & byte-swapping in 2.4.21 In-Reply-To: <16074.52760.823968.563326@argo.ozlabs.ibm.com> References: <20030520151858.A27184@forte.austin.ibm.com> <16074.52760.823968.563326@argo.ozlabs.ibm.com> Message-ID: <1053508182.17221.9.camel@gaston> > > > There's just enough mapping and redirection & etc. in this code that > > I haven't quite figured out what the intent was, and therefore, haven't > > really figured out what the right fix is ... is it in the ide code? > > In the ppc64-specific code? Am I the only big-endian platform with > > this problem? Have other big-endian platforms tested? > > No, yes, probably, yes. IDE works fine on ppc32 (except for the > problems with CF cards on powerbooks with IDE interfaces with no > attached drives, but that's another story). One thing too here is why would you end up using the "mm" versions of the IOPs ? By default, IDE uses the "pio" versions (the one doing insw/ outsw) and those should work fine for "normal" (read: common PCI) controllers. Unless you have a special memory mapped controller, like we have on pmac, you don't need the "mm" versions and the IDE code 'as is' should not have used them. Ben. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From SVakkalankarao at covansys.com Wed May 21 21:49:59 2003 From: SVakkalankarao at covansys.com (VAKKALANKA RAO Sridhar) Date: Wed, 21 May 2003 17:19:59 +0530 Subject: Network booting a p630 using tftp & dhcpd Message-ID: <207D6ADFC044A84686D44CA11B297EEA02018A2A@chn-ex02.cvns.corp.covansys.com> Hi, I recently built a "zImage" for the first time on a Pentium III and installed tftp & dhcpd on it. After putting the zImage in the "/tftpboot" directory, I tried to network boot the ppc64 (a p630-6E4) at the firmware level. Here is the firmware output I got: STARTING SOFTWARE PLEASE WAIT ... BOOTP: chosen-network-type = ethernet,10,rj45,half BOOTP: client IP = 0.0.0.0 BOOTP: server IP = 0.0.0.0 BOOTP: gateway IP = 0.0.0.0 BOOTP: wait 60 seconds for Spanning Tree... BOOTP: S=1 BOOTP R=6 FILE: zImage BOOTP: read-first-block failed: 0 BOOTP: S=1 BOOTP R=6 FILE: zImage BOOTP: read-first-block failed: 1 BOOTP: S=1 BOOTP R=6 FILE: zImage BOOTP: read-first-block failed: 2 BOOTP: S=1 BOOTP R=6 FILE: zImage BOOTP: read-first-block failed: 3 BOOTP: S=1 BOOTP R=6 FILE: zImage BOOTP: read-first-block failed: 4 BOOTP ERROR: TFTP of first block failed, ABORT !20A80005! If any of you are familiar with network booting a pSeries machine, please tell me what could have gone wrong. On the server side (Pentium III), I took all precautions for proper configuration (including execution of arp -s prior to net boot). Is it possible that this happened due to improper "zImage" compilation? Thanks Sri ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Thu May 22 00:58:34 2003 From: anton at samba.org (Anton Blanchard) Date: Thu, 22 May 2003 00:58:34 +1000 Subject: Network booting a p630 using tftp & dhcpd In-Reply-To: <207D6ADFC044A84686D44CA11B297EEA02018A2A@chn-ex02.cvns.corp.covansys.com> References: <207D6ADFC044A84686D44CA11B297EEA02018A2A@chn-ex02.cvns.corp.covansys.com> Message-ID: <20030521145834.GF20691@krispykreme> Hi, > I recently built a "zImage" for the first time on a Pentium III and > installed tftp & dhcpd on it. After putting the zImage in the > "/tftpboot" directory, I tried to network boot the ppc64 (a p630-6E4) > at the firmware level. Here is the firmware output I got: ... > BOOTP: S=1 BOOTP R=6 > FILE: zImage > BOOTP: read-first-block failed: 4 > BOOTP ERROR: TFTP of first block failed, ABORT > !20A80005! Looking for any tftp error messages in /var/log and also taking a dump of the network traffic with tcpdump would be useful. My guess is the client is trying to get a file that does not exist on the server. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From linas at austin.ibm.com Thu May 22 06:55:44 2003 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Wed, 21 May 2003 15:55:44 -0500 Subject: IDE & byte-swapping in 2.4.21 In-Reply-To: <1053508182.17221.9.camel@gaston>; from benh@kernel.crashing.org on Wed, May 21, 2003 at 11:09:43AM +0200 References: <20030520151858.A27184@forte.austin.ibm.com> <16074.52760.823968.563326@argo.ozlabs.ibm.com> <1053508182.17221.9.camel@gaston> Message-ID: <20030521155543.A31698@forte.austin.ibm.com> On Wed, May 21, 2003 at 11:09:43AM +0200, Benjamin Herrenschmidt wrote: > > > > > > There's just enough mapping and redirection & etc. in this code that > > > I haven't quite figured out what the intent was, and therefore, haven't > > > really figured out what the right fix is ... is it in the ide code? > > > In the ppc64-specific code? Am I the only big-endian platform with > > > this problem? Have other big-endian platforms tested? > > > > No, yes, probably, yes. IDE works fine on ppc32 (except for the > > problems with CF cards on powerbooks with IDE interfaces with no > > attached drives, but that's another story). > > One thing too here is why would you end up using the "mm" versions of > the IOPs ? By default, IDE uses the "pio" versions (the one doing insw/ > outsw) and those should work fine for "normal" (read: common PCI) > controllers. Unless you have a special memory mapped controller, like > we have on pmac, you don't need the "mm" versions and the IDE code 'as is' > should not have used them. I'm working with 2.4.21 pre4 which does things like grep mm_insw *.c ide-iops.c: hwif->INSW = ide_mm_insw; I've hardly studied the code, but it looks like hwif->INSW is used as the default by all the drivers. Maybe I'm mistaken. In addition, I also happen to be using a card that ends up with the siimage driver, which explictly calls __ide_mm_insw. I haven't tried it yet, but I'm guessing that implementing the __ide_mm_insw to be non-swapping on the ppc64 will cure my ills. If that is really the right thing to do. I still don't understand why a generic #ifdef BIG_ENDIAN in include/asm-generic/ide_iops.h isn't enough. After all, someone thought that this was a suitable generic implementation? --linas ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From andre at linux-ide.org Thu May 22 06:56:57 2003 From: andre at linux-ide.org (Andre Hedrick) Date: Wed, 21 May 2003 13:56:57 -0700 (PDT) Subject: IDE & byte-swapping in 2.4.21 In-Reply-To: <1053508182.17221.9.camel@gaston> Message-ID: Benjamin, You are smoking crack ! SATA uses PIO taskfile in MMIO mode :-P On 21 May 2003, Benjamin Herrenschmidt wrote: > > > > > > There's just enough mapping and redirection & etc. in this code that > > > I haven't quite figured out what the intent was, and therefore, haven't > > > really figured out what the right fix is ... is it in the ide code? > > > In the ppc64-specific code? Am I the only big-endian platform with > > > this problem? Have other big-endian platforms tested? > > > > No, yes, probably, yes. IDE works fine on ppc32 (except for the > > problems with CF cards on powerbooks with IDE interfaces with no > > attached drives, but that's another story). > > One thing too here is why would you end up using the "mm" versions of > the IOPs ? By default, IDE uses the "pio" versions (the one doing insw/ > outsw) and those should work fine for "normal" (read: common PCI) > controllers. Unless you have a special memory mapped controller, like > we have on pmac, you don't need the "mm" versions and the IDE code 'as is' > should not have used them. > > Ben. > Andre Hedrick LAD Storage Consulting Group ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From fweps at greenmail.ch Thu May 22 07:09:41 2003 From: fweps at greenmail.ch (Florian M. Weps) Date: Wed, 21 May 2003 23:09:41 +0200 Subject: Network booting a p630 using tftp & dhcpd Message-ID: <20030521210941.GA12599@dyn-cust.222.35.202.213.quicknet.ch> Hi Did you boot from the Open Firmware prompt? If so, did you use 0 > boot net:,, Also, how did you configure dhcp and tftpd? Did you check the logs (/var/log/daemon.log on a Debian box)? Cheers, Florian -- E-Mail: fweps at greenmail.ch (private) fmw at debian.org (Debian-related) Jabber: fmw at amessage.ch ICQ: 167919139 GPG Key ID: B34A0F1D GPG Fingerprint: 6FFC 6751 BBB8 0F60 C39D AB72 4A77 581C B34A 0F1D ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From linas at austin.ibm.com Thu May 22 08:11:50 2003 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Wed, 21 May 2003 17:11:50 -0500 Subject: IDE & byte-swapping in 2.4.21 In-Reply-To: <20030521155543.A31698@forte.austin.ibm.com>; from linas@austin.ibm.com on Wed, May 21, 2003 at 03:55:44PM -0500 References: <20030520151858.A27184@forte.austin.ibm.com> <16074.52760.823968.563326@argo.ozlabs.ibm.com> <1053508182.17221.9.camel@gaston> <20030521155543.A31698@forte.austin.ibm.com> Message-ID: <20030521171149.A31200@forte.austin.ibm.com> FYI. I tried to get ide modules to work, but gave up. Howwever, following simple patch helps a little bit: Index: setup-pci.c =================================================================== RCS file: /cvs/linuxppc64/linuxppc64_2_4/drivers/ide/setup-pci.c,v retrieving revision 1.1 diff -u -r1.1 setup-pci.c --- setup-pci.c 8 Jan 2003 18:08:22 -0000 1.1 +++ setup-pci.c 15 May 2003 16:49:12 -0000 @@ -172,16 +172,21 @@ * is already in DMA mode we check and enforce IDE simplex rules. */ -static unsigned long __init ide_get_or_set_dma_base (ide_hwif_t *hwif) +/* This must not be marked __init, since it is called during module load */ +static unsigned long ide_get_or_set_dma_base (ide_hwif_t *hwif) { unsigned long dma_base = 0; On Wed, May 21, 2003 at 03:55:44PM -0500, linas at austin.ibm.com wrote: > > I haven't tried it yet, but I'm guessing that implementing > the __ide_mm_insw to be non-swapping on the ppc64 will cure my > ills. FYI, The following cures all my ppc64 ills. --linas Index: ide.h =================================================================== RCS file: /cvs/linuxppc64/linuxppc64_2_4/include/asm-ppc64/ide.h,v retrieving revision 1.6 diff -u -r1.6 ide.h --- ide.h 8 Jan 2003 18:57:40 -0000 1.6 +++ ide.h 21 May 2003 21:58:15 -0000 @@ -48,7 +48,11 @@ { } -#include +#define __ide_mm_insw(p, a, c) _insw_ns((volatile u16 *)(p), (a), (c)) +#define __ide_mm_insl(p, a, c) _insl_ns((volatile u32 *)(p), (a), (c)) +#define __ide_mm_outsw(p, a, c) _outsw_ns((volatile u16 *)(p), (a), (c)) +#define __ide_mm_outsl(p, a, c) _outsl_ns((volatile u32 *)(p), (a), (c)) + #endif /* __KERNEL__ */ Index: io.h =================================================================== RCS file: /cvs/linuxppc64/linuxppc64_2_4/include/asm-ppc64/io.h,v retrieving revision 1.23.2.1 diff -u -r1.23.2.1 io.h --- io.h 2 Oct 2002 18:44:34 -0000 1.23.2.1 +++ io.h 16 May 2003 18:53:50 -0000 @@ -90,7 +90,7 @@ #define inw_p(port) inw(port) #define outw_p(val, port) (udelay(1), outw((val), (port))) #define inl_p(port) inl(port) -#define outl_p(val, port) (udelay(1), outl((val, (port))) +#define outl_p(val, port) (udelay(1), outl((val), (port))) Index: misc.S =================================================================== RCS file: /cvs/linuxppc64/linuxppc64_2_4/arch/ppc64/kernel/misc.S,v retrieving revision 1.47 diff -u -r1.47 misc.S --- misc.S 28 Apr 2003 20:27:54 -0000 1.47 +++ misc.S 21 May 2003 21:59:47 -0000 @@ -354,7 +354,7 @@ bdnz 00b blr -_GLOBAL(ide_insw) +/* _GLOBAL(ide_insw) now in drivers/ide/ide-iops.c */ _GLOBAL(_insw_ns) cmpwi 0,r5,0 mtctr r5 @@ -366,7 +366,7 @@ bdnz 00b blr -_GLOBAL(ide_outsw) +/* _GLOBAL(ide_outsw) now in drivers/ide/ide-iops.c */ _GLOBAL(_outsw_ns) cmpwi 0,r5,0 mtctr r5 ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From paulus at samba.org Thu May 22 10:04:33 2003 From: paulus at samba.org (Paul Mackerras) Date: Thu, 22 May 2003 10:04:33 +1000 Subject: IDE & byte-swapping in 2.4.21 In-Reply-To: <20030521171149.A31200@forte.austin.ibm.com> References: <20030520151858.A27184@forte.austin.ibm.com> <16074.52760.823968.563326@argo.ozlabs.ibm.com> <1053508182.17221.9.camel@gaston> <20030521155543.A31698@forte.austin.ibm.com> <20030521171149.A31200@forte.austin.ibm.com> Message-ID: <16076.5137.904778.391480@argo.ozlabs.ibm.com> linas at austin.ibm.com writes: > FYI, > The following cures all my ppc64 ills. The patch looks very reasonable to me. Dave E, do you want me to commit the patch to CVS? Paul. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From benh at kernel.crashing.org Thu May 22 18:37:59 2003 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: 22 May 2003 10:37:59 +0200 Subject: IDE & byte-swapping in 2.4.21 In-Reply-To: References: Message-ID: <1053592678.591.1.camel@gaston> On Wed, 2003-05-21 at 22:56, Andre Hedrick wrote: > Benjamin, > > You are smoking crack ! > > SATA uses PIO taskfile in MMIO mode :-P I'm not smoking crack yet ;) I didn't know he was using SATA, Jens told me about this problem a while ago and at that point, he said it affected various PCI ATA controllers. Ben ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From engebret at us.ibm.com Thu May 22 23:35:38 2003 From: engebret at us.ibm.com (David Engebretsen) Date: Thu, 22 May 2003 08:35:38 -0500 Subject: IDE & byte-swapping in 2.4.21 Message-ID: Paul, I would be happy to have your help here. Thanks. Dave Engebretsen Ph.D. Linux on PowerPC-64 Architecture and Development Dept 8DNA, Bldg 030-2, E306 (507) 253-2925, t/l 553-2925 engebret at us.ibm.com Paul Mackerras cc: linuxppc64-dev at lists.linuxppc.org, David Engebretsen/Rochester/IBM at IBMUS Subject: Re: IDE & byte-swapping in 2.4.21 05/21/2003 07:04 PM linas at austin.ibm.com writes: > FYI, > The following cures all my ppc64 ills. The patch looks very reasonable to me. Dave E, do you want me to commit the patch to CVS? Paul. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From SVakkalankarao at covansys.com Fri May 23 13:24:44 2003 From: SVakkalankarao at covansys.com (VAKKALANKA RAO Sridhar) Date: Fri, 23 May 2003 08:54:44 +0530 Subject: Network booting a p630 using tftp & dhcpd Message-ID: <207D6ADFC044A84686D44CA11B297EEA02018A2B@chn-ex02.cvns.corp.covansys.com> > > I recently built a "zImage" for the first time on a Pentium III and > > installed tftp & dhcpd on it. After putting the zImage in the > > "/tftpboot" directory, I tried to network boot the ppc64 (a p630-6E4) > > at the firmware level. Here is the firmware output I got: > > ... > > > BOOTP: S=1 BOOTP R=6 > > FILE: zImage > > BOOTP: read-first-block failed: 4 > > BOOTP ERROR: TFTP of first block failed, ABORT > > !20A80005! > > Looking for any tftp error messages in /var/log and also taking a dump > of the network traffic with tcpdump would be useful. My guess is the > client is trying to get a file that does not exist on the server. You were asolutely right. After checking the log file on the dhcpd/tftp server, I discovered the message "Cannot resolve group for user nobody" when it tried to access the zImage. My network administrator got on to it and said that this was caused by the firewall on the dhcpd/tftp server and he turned it off. Subsequently, he changed all configurations from user "nobody" to "root". Even then the problem was not solved. Well, the p630 has no floppy drive and is CD-bootable. Presently, my bootable CD installs a target AIX 5.1 O/S with no development environment. I have CD booted the p630 several times and found it to be very straight forward (at least for AIX). I am also told that SuSE sells such a CD for Linux on the p630. Using my zImage, is there some way that I can burn a bootable CD so I don't have to rely on a network boot? In order to set up a network boot environment, I had to request my own private network within my organization, the execution of which was not easy. Thanks again Sri ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From DJ at de.ibm.com Tue May 27 03:41:34 2003 From: DJ at de.ibm.com (Denis J Barrow) Date: Mon, 26 May 2003 19:41:34 +0200 Subject: broken kernel syscalls on ppc64 Message-ID: Hi, I am developing with 2.5.66 & SLES 8 from suse as most of the apps on SLES8 are 32 bit the check below is broken. The reason being if a syscall is made from the kernel in the context of a 32 bit process e.g. bash the syscall code below will incorrectly assume it the syscall is being made with 32 bit parameters. I talked to Martin Schwidefsky & on zSeries they are checking whether the PSW ( the s390's MSR ) is in 32 or 64 bit mode, I unfortunately don't think we can do the same thing as MSR[SF] is not used the same way as on zSeries. clrrdi r10,r1,THREAD_SHIFT ld r10,TI_FLAGS(r10) andi. r11,r10,_TIF_SYSCALL_TRACE bne- 50f cmpli 0,r0,NR_syscalls bge- 66f /* * Need to vector to 32 Bit or default sys_call_table here, * based on caller's run-mode / personality. */ andi. r11,r10,_TIF_32BIT beq- 15f ld r10,.SYS_CALL_TABLE32 at toc(2) D.J. Barrow Linux Kernel Developer dj at de.ibm.com,barrow_dj at yahoo.com Phone:0049-7031-16-2943 ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From DJ at de.ibm.com Wed May 28 01:37:21 2003 From: DJ at de.ibm.com (Denis J Barrow) Date: Tue, 27 May 2003 17:37:21 +0200 Subject: broken kernel syscalls on ppc64 Message-ID: Another side effect of this is kernel_thread doesn't work if the parent process is 32 bit e.g. bash on SLES8. D.J. Barrow Linux Kernel Developer dj at de.ibm.com,barrow_dj at yahoo.com Phone:0049-7031-16-2943 ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From DJ at de.ibm.com Wed May 28 01:59:05 2003 From: DJ at de.ibm.com (Denis J Barrow) Date: Tue, 27 May 2003 17:59:05 +0200 Subject: broken kernel syscalls on ppc64 Message-ID: Sorry I suspect my kernel_thread bug is something else. D.J. Barrow Linux Kernel Developer dj at de.ibm.com,barrow_dj at yahoo.com Phone:0049-7031-16-2943 ----- Forwarded by Denis J Barrow/Germany/Contr/IBM on 05/27/03 05:58 PM ----- Denis J Barrow To: aulus at ozlabs.au.ibm.com, David 05/27/03 05:37 PM Boutcher/Rochester/IBM at IBMUS, mfrueh at suse.de, linuxppc64-dev at lists.linuxppc.org cc: From: Denis J Barrow/Germany/Contr/IBM at IBMDE Subject: broken kernel syscalls on ppc64 Another side effect of this is kernel_thread doesn't work if the parent process is 32 bit e.g. bash on SLES8. D.J. Barrow Linux Kernel Developer dj at de.ibm.com,barrow_dj at yahoo.com Phone:0049-7031-16-2943 ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Wed May 28 02:08:54 2003 From: anton at samba.org (Anton Blanchard) Date: Wed, 28 May 2003 02:08:54 +1000 Subject: broken kernel syscalls on ppc64 In-Reply-To: References: Message-ID: <20030527160854.GA680@krispykreme> > Another side effect of this is kernel_thread doesn't work if the parent > process is 32 bit e.g. bash on SLES8. In 2.5 this should be fixed, we clear the 32bit flag in copy_process if we are creating a kernel thread. Im surprised a similar fix is not in 2.4, I hit this exact problem with the tux webserver there. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Wed May 28 02:13:39 2003 From: anton at samba.org (Anton Blanchard) Date: Wed, 28 May 2003 02:13:39 +1000 Subject: broken kernel syscalls on ppc64 In-Reply-To: References: Message-ID: <20030527161339.GB680@krispykreme> > I am developing with 2.5.66 & SLES 8 from suse > as most of the apps on SLES8 are 32 bit the check below is broken. > > The reason being if a syscall is made from the kernel in the context of a > 32 bit process > e.g. bash the syscall code below will incorrectly assume it the syscall is > being made with 32 bit > parameters. Interesting. Could you summarise what the application/kernel is doing here exactly? There are only a few syscalls we allow to be called out of the kernel, and they only seem to be used during boot. extern pid_t setsid(void); extern int write(int fd, const char *buf, off_t count); extern int read(int fd, char *buf, off_t count); extern off_t lseek(int fd, off_t offset, int count); extern int dup(int fd); extern int execve(const char *file, char **argv, char **envp); extern int open(const char *file, int flag, int mode); extern int close(int fd); extern pid_t waitpid(pid_t pid, int *wait_stat, int options); Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From DJ at de.ibm.com Wed May 28 02:43:44 2003 From: DJ at de.ibm.com (Denis J Barrow) Date: Tue, 27 May 2003 18:43:44 +0200 Subject: RFC change to process.c Message-ID: Hi, ptregs is set to NULL for kernel threads in linuxppc64 & linuxppc on 2.5.66 this is not done on non powerpc linux ports to my knowledge. The pSeries kernel boots fine with the modification below. It specifically prevents me from modifying the pt_regs on my kernel thread & it appears to be more a hindrance than a help & makes kernel threads harder to debug, unless somebody can give me a good reason why this is the way it is I suggest that the change below be accepted. PS Martin/Uli it might be an idea to clear_ti_thread_flag(p->thread_info, TIF_31BIT); for zSeries kernel threads in copy_thread. Index: process.c =================================================================== RCS file: /home/cvs/linuxppc64_2_5/arch/ppc64/kernel/process.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 process.c --- process.c 11 Apr 2003 10:59:52 -0000 1.1.1.1 +++ process.c 27 May 2003 16:35:27 -0000 @@ -200,14 +200,12 @@ if ((childregs->msr & MSR_PR) == 0) { /* for kernel thread, set stackptr in new task */ childregs->gpr[1] = sp + sizeof(struct pt_regs); - p->thread.regs = NULL; /* no user register state */ clear_ti_thread_flag(p->thread_info, TIF_32BIT); #ifdef CONFIG_PPC_ISERIES set_ti_thread_flag(p->thread_info, TIF_RUN_LIGHT); #endif } else { childregs->gpr[1] = usp; - p->thread.regs = childregs; if (clone_flags & CLONE_SETTLS) { if (test_thread_flag(TIF_32BIT)) childregs->gpr[2] = childregs->gpr[6]; @@ -215,6 +213,7 @@ childregs->gpr[13] = childregs->gpr[6]; } } + p->thread.regs = childregs; childregs->gpr[3] = 0; /* Result from fork() */ sp -= STACK_FRAME_OVERHEAD; D.J. Barrow Linux Kernel Developer dj at de.ibm.com,barrow_dj at yahoo.com Phone:0049-7031-16-2943 ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From DJ at de.ibm.com Wed May 28 02:57:52 2003 From: DJ at de.ibm.com (Denis J Barrow) Date: Tue, 27 May 2003 18:57:52 +0200 Subject: broken kernel syscalls on ppc64 Message-ID: Hi Anton/Others, I am opening & reading a file from the kernel in the context of a 32 bit bash process, i.e. I am echoing 1 to a sysfs file to cause the kernel to read a file. echo 1 > /sys/file the kludge I am doing at the moment & it is working is. int saved_32bit=test_and_clear_thread_flag(TIF_32BIT); & when I am finished loading the file ( doing the kernel syscalls ) I am doing. if(saved_32bit) set_thread_flag(TIF_32BIT); P.S.I added a fstat64 to my copy misc.S to get the file size. D.J. Barrow Linux Kernel Developer dj at de.ibm.com,barrow_dj at yahoo.com Phone:0049-7031-16-2943 Anton Blanchard To: Denis J Barrow/Germany/Contr/IBM at IBMDE cc: paulus at samba.org, David 05/27/03 06:13 PM Boutcher/Rochester/IBM at IBMUS, mfrueh at suse.de, linuxppc64-dev at lists.linuxppc.org Subject: Re: broken kernel syscalls on ppc64 > I am developing with 2.5.66 & SLES 8 from suse > as most of the apps on SLES8 are 32 bit the check below is broken. > > The reason being if a syscall is made from the kernel in the context of a > 32 bit process > e.g. bash the syscall code below will incorrectly assume it the syscall is > being made with 32 bit > parameters. Interesting. Could you summarise what the application/kernel is doing here exactly? There are only a few syscalls we allow to be called out of the kernel, and they only seem to be used during boot. extern pid_t setsid(void); extern int write(int fd, const char *buf, off_t count); extern int read(int fd, char *buf, off_t count); extern off_t lseek(int fd, off_t offset, int count); extern int dup(int fd); extern int execve(const char *file, char **argv, char **envp); extern int open(const char *file, int flag, int mode); extern int close(int fd); extern pid_t waitpid(pid_t pid, int *wait_stat, int options); Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From foerster at 8hertz.com Wed May 28 08:04:49 2003 From: foerster at 8hertz.com (Christian Foerster) Date: Wed, 28 May 2003 00:04:49 +0200 Subject: SCSI termination problem installing Redhat 7.1 Message-ID: <3C1024F8-908F-11D7-8607-00039366AD62@8hertz.com> Hi, we finally made some progress installing Redhat 7.1 on the p610. We successfully booted the kernel over ethernet and have got the installer been displayed over serial console. We have been able to configure network connection. We choose FTP install and have got the base files downloaded by the installer! Then the Redhat Anaconda installer application starts and lets us choose the system type we want to install. We chose 'custom installation' and the Anaconda application crashes immediately. It has been the same with 'server' and 'workstation' installion type. We guess its because of some SCSI conflict with our machine. The dmesg output says something so. Below you can find the Anaconda error message and the dmesg kernel output. Booting with the Suse kernel leads to the same affect. It complains about SCSI bus termination. However installation of AIX works like a charm. Any idea? Can someone maybe provide us with a working install kernel for the p610. Chris ############# Anaconda Error Message ################# An internal error occurred in the # x x x installation program. Please report a x  x this error to Red Hat (through the a x x x bugzilla.redhat.com web site) as a x   x soon as possible. Traceback a x x x (innermost last): a x x x File "/usr/bin/anaconda.real", a x   x line 533, in ? a x   x intf.run(todo, test = test) a x  x File a x x x "/var/tmp/anaconda-7.1//usr/lib/anac a x x x onda/text.py", line 1144, in run ################## dmesg boot kernel output ############################### Naca Info... naca = 0xc000000000004000 naca->processorCount = 0x0000000000000001 naca->physicalMemorySize = 0x0000000020000000 naca->dCacheL1LineSize = 0x0000000000000080 naca->dCacheL1LogLineSize = 0x0000000000000007 naca->dCacheL1LinesPerPage = 0x0000000000000020 naca->iCacheL1LineSize = 0x0000000000000080 naca->iCacheL1LogLineSize = 0x0000000000000007 naca->iCacheL1LinesPerPage = 0x0000000000000020 naca->pftSize = 0x0000000000000017 naca->serialPortAddr = 0x00000000f80003f8 naca->interrupt_controller = 0x0000000000000001 HTAB Info ... htab_data.htab = 0xc00000001e800000 htab_data.num_ptegs = 0x0000000000010000 ----------------------------------------------------- MM:exit id mach: done setup_arch:enter setup_arch:bootmem OpenPIC addr: ffc00000 setup_arch: exit openpic enter openpic timer openpic ipi openpic ext openpic spurious openpic exit Linux version 2.4.9-23.19.8 (root at shiznit.hsv.redhat.com) (gcc version 3.0.5 200 20418 (prerelease)) #1 SMP Wed Nov 20 14:10:18 CST 2002 Boot arguments: console=ttyS0,9600 text Python workaround: reg0: 18e3388 Python workaround: reg0: 18eb788 On node 0 totalpages: 131072 zone(0): 131072 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: console=ttyS0,9600 text OpenPIC Version 1.2 (8 CPUs and 1 IRQ sources) at e000000002207000 OpenPIC reversed IPI registers detected time_init: decrementer frequency = 95.141636 MHz time_init: processor frequency = 333.000000 MHz Console: colour dummy device 80x25 Calibrating delay loop... 332.99 BogoMips Memory: 482008k available (1936k kernel code, 3176k data, 304k init) [c000000000 000000,c000000020000000] Dentry-cache hash table entries: 65536 (order: 8, 1048576 bytes) Inode-cache hash table entries: 32768 (order: 7, 524288 bytes) Mount-cache hash table entries: 8192 (order: 5, 131072 bytes) Buffer-cache hash table entries: 32768 (order: 6, 262144 bytes) Page-cache hash table entries: 131072 (order: 9, 2097152 bytes) proc_ppc64: Creating /proc/ppc64/pmc PCI: /proc/ppc64/pci created. PCI: PciFr created at: 0xc000000001b0b000 PCI: /proc/ppc64/pcifr created. POSIX conformance testing by UNIFIX Entering SMP Mode... Probe found 1 CPUs Waiting for 0 CPUs PCI: Probing PCI hardware Using INTC for W82c105 IDE controller. Unknown bridge resource 0: assuming transparent Unknown bridge resource 2: assuming transparent PCI: Cannot allocate resource region 3 of PCI bridge 0 PCI: resource is a0000..9ffff (200), parent c000000000277520 PCI: Probing PCI hardware done 2.4.9-23.19.8 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket i/pSeries Real Time Clock Driver v1.1 RTAS daemon started PPC64 nvram contains 110592 bytes Starting kswapd v1.8 matroxfb: Matrox G450 detected matroxfb: 640x480x8bpp (virtual: 640x26208) matroxfb: framebuffer at 0xC0000000, mapped to 0xe00000000224c000, size 33554432 Console: switching to colour frame buffer device 80x30 fb0: MATROX VGA frame buffer device Detected PS/2 Mouse Port. pty: 2048 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI en abled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A block: queued sectors max/low 318485kB/187413kB, 960 slots per queue RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize Floppy drive(s): fd0 is 2.88M FDC 0 is a National Semiconductor PC87306 loop: loaded (max 8 devices) SCSI subsystem driver Revision: 1.00 PCI: Enabling device 00:0c.0 (0140 -> 0143) sym53c8xx: at PCI bus 0, device 12, function 0 sym53c8xx: setting PCI_COMMAND_MASTER...(fix-up) sym53c8xx: 53c1010-66 detected PCI: Enabling device 00:0c.1 (0140 -> 0143) sym53c8xx: at PCI bus 0, device 12, function 1 sym53c8xx: setting PCI_COMMAND_MASTER...(fix-up) sym53c8xx: 53c1010-66 detected sym53c1010-66-0: rev 0x1 on pci bus 0 device 12 function 0 irq 20 sym53c1010-66-0: ID 7, Fast-80, Parity Checking sym53c1010-66-0: suspicious SCSI data while resetting the BUS. sym53c1010-66-0: dp1,d15-8,dp0,d7-0,rst,req,ack,bsy,sel,atn,msg,c/d,i/o = 0x4001 00, expecting 0x100 sym53c1010-66-0: FATAL ERROR: CHECK SCSI BUS - CABLES, TERMINATION, DEVICE POWER etc.! sym53c1010-66-0: giving up ... sym53c1010-66-0: rev 0x1 on pci bus 0 device 12 function 1 irq 17 sym53c1010-66-0: ID 7, Fast-80, Parity Checking sym53c1010-66-0: handling phase mismatch from SCRIPTS. scsi0 : sym53c8xx-1.7.3c-20010512 B0roxfb_crtc2: secondary head of fb0 was registered as fb1 NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 2048 buckets, 32Kbytes TCP: Hash tables configured (established 65536 bind 65536) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. RAMDISK: Compressed image found at block 0 Freeing initrd memory: 982k freed VFS: Mounted root (ext2 filesystem). Freeing unused kernel memory: 304k init Greetings. Red Hat install init version 7.0 starting mounting /proc filesystem... done mounting /dev/pts (unix98 pty) filesystem... done Red Hat install init version 7.0 using a serial console remember, cereal is an important part of a nutritionally balanced breakfast. could not set new controlling tty checking for NFS root filesystem...no trying to remount root filesystem read write... done checking for writeable /tmp... yes running install... running /sbin/loader ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From streeter at redhat.com Wed May 28 08:23:01 2003 From: streeter at redhat.com (Guy M. Streeter) Date: 27 May 2003 17:23:01 -0500 Subject: SCSI termination problem installing Redhat 7.1 In-Reply-To: <3C1024F8-908F-11D7-8607-00039366AD62@8hertz.com> References: <3C1024F8-908F-11D7-8607-00039366AD62@8hertz.com> Message-ID: <1054074181.1018.34.camel@jarjar.hsv.redhat.com> The Red Hat Linux 7.1 distribution for pSeries supports the 620, 640, and 660 lines of pSeries systems. The p610 is not supported. --Guy On Tue, 2003-05-27 at 17:04, Christian Foerster wrote: > Hi, > > we finally made some progress installing Redhat 7.1 on the p610. We > successfully booted the kernel over ethernet and have got the installer > been displayed over serial console. We have been able to configure > network connection. We choose FTP install and have got the base files > downloaded by the installer! > > Then the Redhat Anaconda installer application starts and lets us > choose the system type we want to install. We chose 'custom > installation' and the Anaconda application crashes immediately. It has > been the same with 'server' and 'workstation' installion type. > > We guess its because of some SCSI conflict with our machine. The dmesg > output says something so. Below you can find the Anaconda error message > and the dmesg kernel output. Booting with the Suse kernel leads to the > same affect. It complains about SCSI bus termination. However > installation of AIX works like a charm. > > Any idea? Can someone maybe provide us with a working install kernel > for the p610. > > Chris > > > ############# Anaconda Error Message ################# > > An internal error occurred in the # x x > x installation program. Please report a x  > x this error to Red Hat (through the a x > x > x bugzilla.redhat.com web site) as a x  >  > x soon as possible. Traceback a x > x > x (innermost last): a x x > x File "/usr/bin/anaconda.real", a x  >  > x line 533, in ? a x  >  > x intf.run(todo, test = test) a x  > x File a x > x > x "/var/tmp/anaconda-7.1//usr/lib/anac a x > x > x onda/text.py", line 1144, in run > > > ################## dmesg boot kernel output > ############################### > > Naca Info... > > naca = 0xc000000000004000 > naca->processorCount = 0x0000000000000001 > naca->physicalMemorySize = 0x0000000020000000 > naca->dCacheL1LineSize = 0x0000000000000080 > naca->dCacheL1LogLineSize = 0x0000000000000007 > naca->dCacheL1LinesPerPage = 0x0000000000000020 > naca->iCacheL1LineSize = 0x0000000000000080 > naca->iCacheL1LogLineSize = 0x0000000000000007 > naca->iCacheL1LinesPerPage = 0x0000000000000020 > naca->pftSize = 0x0000000000000017 > naca->serialPortAddr = 0x00000000f80003f8 > naca->interrupt_controller = 0x0000000000000001 > > HTAB Info ... > > htab_data.htab = 0xc00000001e800000 > htab_data.num_ptegs = 0x0000000000010000 > > ----------------------------------------------------- > MM:exit > id mach: done > setup_arch:enter > setup_arch:bootmem > OpenPIC addr: ffc00000 > setup_arch: exit > openpic enter > openpic timer > openpic ipi > openpic ext > openpic spurious > openpic exit > Linux version 2.4.9-23.19.8 (root at shiznit.hsv.redhat.com) (gcc version > 3.0.5 200 > 20418 (prerelease)) #1 SMP Wed Nov 20 14:10:18 CST 2002 > Boot arguments: console=ttyS0,9600 text > Python workaround: reg0: 18e3388 > Python workaround: reg0: 18eb788 > On node 0 totalpages: 131072 > zone(0): 131072 pages. > zone(1): 0 pages. > zone(2): 0 pages. > Kernel command line: console=ttyS0,9600 text > OpenPIC Version 1.2 (8 CPUs and 1 IRQ sources) at e000000002207000 > OpenPIC reversed IPI registers detected > time_init: decrementer frequency = 95.141636 MHz > time_init: processor frequency = 333.000000 MHz > Console: colour dummy device 80x25 > Calibrating delay loop... 332.99 BogoMips > Memory: 482008k available (1936k kernel code, 3176k data, 304k init) > [c000000000 > 000000,c000000020000000] > Dentry-cache hash table entries: 65536 (order: 8, 1048576 bytes) > Inode-cache hash table entries: 32768 (order: 7, 524288 bytes) > Mount-cache hash table entries: 8192 (order: 5, 131072 bytes) > Buffer-cache hash table entries: 32768 (order: 6, 262144 bytes) > Page-cache hash table entries: 131072 (order: 9, 2097152 bytes) > proc_ppc64: Creating /proc/ppc64/pmc > PCI: /proc/ppc64/pci created. > PCI: PciFr created at: 0xc000000001b0b000 > PCI: /proc/ppc64/pcifr created. > POSIX conformance testing by UNIFIX > Entering SMP Mode... > Probe found 1 CPUs > Waiting for 0 CPUs > PCI: Probing PCI hardware > Using INTC for W82c105 IDE controller. > Unknown bridge resource 0: assuming transparent > Unknown bridge resource 2: assuming transparent > PCI: Cannot allocate resource region 3 of PCI bridge 0 > PCI: resource is a0000..9ffff (200), parent c000000000277520 > PCI: Probing PCI hardware done > > 2.4.9-23.19.8 > Linux NET4.0 for Linux 2.4 > Based upon Swansea University Computer Society NET3.039 > Initializing RT netlink socket > i/pSeries Real Time Clock Driver v1.1 > RTAS daemon started > PPC64 nvram contains 110592 bytes > Starting kswapd v1.8 > matroxfb: Matrox G450 detected > matroxfb: 640x480x8bpp (virtual: 640x26208) > matroxfb: framebuffer at 0xC0000000, mapped to 0xe00000000224c000, size > 33554432 > > Console: switching to colour frame buffer device 80x30 > fb0: MATROX VGA frame buffer device > Detected PS/2 Mouse Port. > pty: 2048 Unix98 ptys configured > Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ > SERIAL_PCI en > abled > ttyS00 at 0x03f8 (irq = 4) is a 16550A > ttyS01 at 0x02f8 (irq = 3) is a 16550A > block: queued sectors max/low 318485kB/187413kB, 960 slots per queue > RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize > Floppy drive(s): fd0 is 2.88M > FDC 0 is a National Semiconductor PC87306 > loop: loaded (max 8 devices) > SCSI subsystem driver Revision: 1.00 > PCI: Enabling device 00:0c.0 (0140 -> 0143) > sym53c8xx: at PCI bus 0, device 12, function 0 > sym53c8xx: setting PCI_COMMAND_MASTER...(fix-up) > sym53c8xx: 53c1010-66 detected > PCI: Enabling device 00:0c.1 (0140 -> 0143) > sym53c8xx: at PCI bus 0, device 12, function 1 > sym53c8xx: setting PCI_COMMAND_MASTER...(fix-up) > sym53c8xx: 53c1010-66 detected > sym53c1010-66-0: rev 0x1 on pci bus 0 device 12 function 0 irq 20 > sym53c1010-66-0: ID 7, Fast-80, Parity Checking > sym53c1010-66-0: suspicious SCSI data while resetting the BUS. > sym53c1010-66-0: dp1,d15-8,dp0,d7-0,rst,req,ack,bsy,sel,atn,msg,c/d,i/o > = 0x4001 > 00, expecting 0x100 > sym53c1010-66-0: FATAL ERROR: CHECK SCSI BUS - CABLES, TERMINATION, > DEVICE POWER > etc.! > sym53c1010-66-0: giving up ... > sym53c1010-66-0: rev 0x1 on pci bus 0 device 12 function 1 irq 17 > sym53c1010-66-0: ID 7, Fast-80, Parity Checking > sym53c1010-66-0: handling phase mismatch from SCRIPTS. > scsi0 : sym53c8xx-1.7.3c-20010512 > B0roxfb_crtc2: secondary head of fb0 was registered as fb1 > NET4: Linux TCP/IP 1.0 for NET4.0 > IP Protocols: ICMP, UDP, TCP, IGMP > IP: routing cache hash table of 2048 buckets, 32Kbytes > TCP: Hash tables configured (established 65536 bind 65536) > NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. > RAMDISK: Compressed image found at block 0 > Freeing initrd memory: 982k freed > VFS: Mounted root (ext2 filesystem). > Freeing unused kernel memory: 304k init > Greetings. > Red Hat install init version 7.0 starting > mounting /proc filesystem... done > mounting /dev/pts (unix98 pty) filesystem... done > Red Hat install init version 7.0 using a serial console > remember, cereal is an important part of a nutritionally balanced > breakfast. > > could not set new controlling tty > checking for NFS root filesystem...no > trying to remount root filesystem read write... done > checking for writeable /tmp... yes > running install... > running /sbin/loader > ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From SVakkalankarao at covansys.com Wed May 28 13:24:03 2003 From: SVakkalankarao at covansys.com (VAKKALANKA RAO Sridhar) Date: Wed, 28 May 2003 08:54:03 +0530 Subject: SCSI termination problem installing Redhat 7.1 Message-ID: <207D6ADFC044A84686D44CA11B297EEA01D7AD57@chn-ex02.cvns.corp.covansys.com> > The Red Hat Linux 7.1 distribution for pSeries supports the 620, 640, > and 660 lines of pSeries systems. > The p610 is not supported. What about higher versions of Red Hat. What I have is a p630? Sri ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From paulus at au1.ibm.com Wed May 28 13:53:18 2003 From: paulus at au1.ibm.com (Paul Mackerras) Date: Wed, 28 May 2003 13:53:18 +1000 Subject: RFC change to process.c In-Reply-To: References: Message-ID: <16084.12974.675783.382296@argo.ozlabs.ibm.com> Denis J Barrow writes: > ptregs is set to NULL for kernel threads in linuxppc64 & linuxppc on > 2.5.66 this > is not done on non powerpc linux ports to my knowledge. > The pSeries kernel boots fine with the modification below. The thread_struct is completely architecture-specific, so other architectures may well do something different. > It specifically prevents me from modifying the pt_regs on my kernel thread > & it > appears to be more a hindrance than a help & makes kernel threads harder to > debug, > unless somebody can give me a good reason why this is the way it is I > suggest > that the change below be accepted. There is a good reason why thread.regs is NULL for a kernel thread - it is because thread.regs reflects the user-mode state of the process. A kernel thread doesn't have any user-mode state for thread.regs to point to. Having a bogus (but superficially reasonable) value in there caused some very subtle and hard-to-find bugs in the past (in the ppc32 kernel), where code that wanted to modify user registers (specifically the MSR) ended up changing bits in the page following the process's kernel stack, causing completely unrelated code to crash some random time in the future. Why do you want to change the register values on your kernel thread from another process anyway? It sounds pretty dangerous. If you are trying to do kernel debugging, you won't get anywhere using thread.regs either for a kernel thread or for a normal process. If you want to know about the state of a process that is blocked in the kernel, you would look at p->thread.ksp for its kernel stack pointer, then add on 112 to get a pointer to where its register values are saved. However, only r14 - r31, nip and cr are saved there - the rest are either caller-saved (e.g. r0, r3-r13, xer, ctr), the same in all processes (e.g. r2, msr) or saved elsewhere (r1, r13). Paul. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From kaena at us.ibm.com Wed May 28 22:48:41 2003 From: kaena at us.ibm.com (Kaena Freitas) Date: Wed, 28 May 2003 07:48:41 -0500 Subject: SCSI termination problem installing Redhat 7.1 Message-ID: Sri - The p630 will be supported with RHEL 3 which is due out sometime in end of 3Q03. This release will support the entire line of pSeries servers. Aloha, Kaena D. Kaena Freitas Linux on pSeries Release Architect kaena at us.ibm.com Office: (512)838-2676 cell: (512)762-3884 "VAKKALANKA RAO Sridhar" , "Christian Foerster" > Sent by: cc: owner-linuxppc64-dev at lists.l Subject: RE: SCSI termination problem installing Redhat 7.1 inuxppc.org 05/27/2003 10:24 PM > The Red Hat Linux 7.1 distribution for pSeries supports the 620, 640, > and 660 lines of pSeries systems. > The p610 is not supported. What about higher versions of Red Hat. What I have is a p630? Sri ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From linas at austin.ibm.com Thu May 29 01:02:04 2003 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Wed, 28 May 2003 10:02:04 -0500 Subject: Documentation {was Re: RFC change to process.c] In-Reply-To: <16084.12974.675783.382296@argo.ozlabs.ibm.com>; from paulus@au1.ibm.com on Wed, May 28, 2003 at 01:53:18PM +1000 References: <16084.12974.675783.382296@argo.ozlabs.ibm.com> Message-ID: <20030528100204.A39616@forte.austin.ibm.com> On Wed, May 28, 2003 at 01:53:18PM +1000, Paul Mackerras wrote: > > There is a good reason why thread.regs is NULL for a kernel thread - Often when reading the source, I get the idea that there must be a good reason for doing things in that particular way, but I can't tell why, and there are no comments or other documentation (that I know of) that provides guidance. This concerns me. Yes, we can write to mailing lists like this, but if you personally (and/or a handful of other people) are on vacation, subtle changes that can induce subtle crashes can subtley work into the source base. In the long run, this hurts reliability. I don't know what the answer is, I just thought I'd bring it up. I, for one, would like to see more in-line comments explaining why code does certain things (not what it does, but why it does it). Yes, I know that documentation is sometimes painfully misleading, especially when the code changes but the comments don't ... but overall I think its a win ... --linas ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From fweps at greenmail.ch Thu May 29 05:34:55 2003 From: fweps at greenmail.ch (Florian M. Weps) Date: Wed, 28 May 2003 21:34:55 +0200 Subject: Debian Installation on an IBM p630 LPAR Message-ID: <20030528193455.GA31300@dyn-cust.222.35.202.213.quicknet.ch> We had the opportunity to test a p630 for a few weeks at our workplace. After the AIX tests were finished, we decided to install Debian GNU/Linux on one partition of the machine. Since we (or Google, actually) could not find any unified document describing the process of installing Debian on POWER4 machines, we hope that our account of the installation procedure will be of general interest. Below are links to German and English versions of the write-up we did. We benefitted greatly from the Debian-Network-Installation-on-POWER3 HOWTO by Rolf Brudeseth which was posted to the debian-powerpc list in July 2002. http://people.debian.org/~fmw/p630-LPAR-Debian-de.txt German http://people.debian.org/~fmw/p630-LPAR-Debian-en.txt English Manuel L?sser Ralf Strauss Florian M. Weps ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/