From ericvanhensbergen at us.ibm.com Tue Jun 1 12:41:02 2004 From: ericvanhensbergen at us.ibm.com (Eric V Van hensbergen) Date: Mon, 31 May 2004 22:41:02 -0400 Subject: Build Tools Problem Message-ID: Just went through the exercise of the re-building my tools environment based on the instructions from penguinppc64.org Tried the crosstool route first, but could only build staticly-linked applications with it. People on #ppc64 suggested the biarch route was much more stable, so I went through and build the biarch tools. They successfully compile and link simple applications but when I went to build my kernel I got: CC kernel/compat.o IKCFG kernel/ikconfig.h CC kernel/configs.o Inconsistency detected by ld.so: dl-minimal.c: 137: realloc: Assertion `new == ptr' failed! make[1]: *** [kernel/configs.o] Error 127 make: *** [kernel] Error 2 Any body have any pointers as to what I'm doing wrong and/or where I can find build tool instructions that will allow me to build both applications and my kernel for PPC64 boxes? If it's relevant - these results were on a G5 with a Gentoo distribution. Thanks for nay help. -eric ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From dank at kegel.com Tue Jun 1 14:09:18 2004 From: dank at kegel.com (Dan Kegel) Date: Mon, 31 May 2004 21:09:18 -0700 Subject: Build Tools Problem In-Reply-To: References: Message-ID: <40BC016E.9050804@kegel.com> Eric V Van hensbergen wrote: > Just went through the exercise of the re-building my tools environment > based on the instructions from penguinppc64.org > > Tried the crosstool route first, but could only build staticly-linked > applications with it. That sounds annoying. What happened when you tried to build dynamically-linked apps? - Dan -- ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From dank at kegel.com Tue Jun 1 14:14:48 2004 From: dank at kegel.com (Dan Kegel) Date: Mon, 31 May 2004 21:14:48 -0700 Subject: Build Tools Problem In-Reply-To: <40BC016E.9050804@kegel.com> References: <40BC016E.9050804@kegel.com> Message-ID: <40BC02B8.4020302@kegel.com> Dan Kegel wrote: > Eric V Van hensbergen wrote: > >> Just went through the exercise of the re-building my tools environment >> based on the instructions from penguinppc64.org >> >> Tried the crosstool route first, but could only build staticly-linked >> applications with it. > > > That sounds annoying. What happened when you tried to > build dynamically-linked apps? Oh, also, http://penguinppc64.org/toolchain.shtml points to an out-of-date copy of crosstool. The latest snapshot is http://kegel.com/crosstool/crosstool-0.28-rc21.tar.gz And can I ask which kernel and glibc your target system is running? - Dan -- ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From ericvanhensbergen at us.ibm.com Tue Jun 1 22:21:43 2004 From: ericvanhensbergen at us.ibm.com (Eric V Van hensbergen) Date: Tue, 1 Jun 2004 08:21:43 -0400 Subject: Build Tools Problem In-Reply-To: Message-ID: I'll try the newer version of crosstool this morning. In answer to your other questions, I'm running a 2.6.6 kernel and a 2.3.2-r9 glibc. When I try to compile dynamically with crosstool I get a segmentation fault. Interestingly enough when I compile with crosstool and have /lib64 linked to the biarch /lib64 - it seems to work. -eric Dan Kegel Sent by: owner-linuxppc64-dev at lists.linuxppc.org 06/01/04 12:22 AM To Dan Kegel cc Eric V Van hensbergen/Austin/IBM at IBMUS, PPC64 External List Subject Re: Build Tools Problem Dan Kegel wrote: > Eric V Van hensbergen wrote: > >> Just went through the exercise of the re-building my tools environment >> based on the instructions from penguinppc64.org >> >> Tried the crosstool route first, but could only build staticly-linked >> applications with it. > > > That sounds annoying. What happened when you tried to > build dynamically-linked apps? Oh, also, http://penguinppc64.org/toolchain.shtml points to an out-of-date copy of crosstool. The latest snapshot is http://kegel.com/crosstool/crosstool-0.28-rc21.tar.gz And can I ask which kernel and glibc your target system is running? - Dan -- ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olh at suse.de Wed Jun 2 03:32:34 2004 From: olh at suse.de (Olaf Hering) Date: Tue, 1 Jun 2004 19:32:34 +0200 Subject: [PATCH] kernel Makefile options for $(AS) In-Reply-To: <20040526235602.GT2564@bubble.modra.org> References: <20040526225658.GA5409@suse.de> <20040526235602.GT2564@bubble.modra.org> Message-ID: <20040601173234.GA30874@suse.de> On Thu, May 27, Alan Modra wrote: > > On Thu, May 27, 2004 at 12:56:58AM +0200, Olaf Hering wrote: > > Is -64 still a valid option for as? Should it be -mppc64? > > No, it should be -a64. pass correct options to $(AS) diff -p -purN linux-2.6.7-rc2-bk2/arch/ppc64/Makefile linux-2.6.7-rc2-bk2.ppc64/arch/ppc64/Makefile --- linux-2.6.7-rc2-bk2/arch/ppc64/Makefile 2004-06-01 18:59:19.000000000 +0200 +++ linux-2.6.7-rc2-bk2.ppc64/arch/ppc64/Makefile 2004-06-01 19:01:40.000000000 +0200 @@ -17,7 +17,7 @@ KERNELLOAD := 0xc000000000000000 HAS_BIARCH := $(shell if $(CC) -m64 -S -o /dev/null -xc /dev/null > /dev/null 2>&1; then echo y; else echo n; fi;) ifeq ($(HAS_BIARCH),y) -AS := $(AS) -64 +AS := $(AS) -a64 LD := $(LD) -m elf64ppc CC := $(CC) -m64 endif -- USB is for mice, FireWire is for men! sUse lINUX ag, n?RNBERG ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From ericvanhensbergen at us.ibm.com Wed Jun 2 03:50:55 2004 From: ericvanhensbergen at us.ibm.com (Eric V Van hensbergen) Date: Tue, 1 Jun 2004 13:50:55 -0400 Subject: Build Tools Problem Message-ID: Managed to fix my bi-arch problems. Tracked it down to libraries being searched in the wrong order by ld. Resolved by changing the following lines in /opt/biarch/tools/biarch-3.4/usr/lib/../lib64/libc.so (and /opt/biarch/tools/biarch-3.4/usr/lib/libc.so): Was: GROUP ( /opt/biarch/tools/biarch-3.4/lib/ld.so.1 /opt/biarch/tools/biarch-3.4/lib/libc.so.6 /opt/biarch/tools/biarch-3.4/usr/lib/libc_nonshared.a ) Now: GROUP ( /opt/biarch/tools/biarch-3.4/lib/libc.so.6 /opt/biarch/tools/biarch-3.4/usr/lib/libc_nonshared.a /opt/biarch/tools/biarch-3.4/lib/ld.so.1) Kernel now compiles clean as does the other applications in which we were experiencing the realloc assert problem. Not sure what I did wrong to get this behavior in the first place, or if this is the best fix for the problem, but I figured I'd post here for others who might be frustrated by this problem. -eric ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olh at suse.de Wed Jun 2 03:51:39 2004 From: olh at suse.de (Olaf Hering) Date: Tue, 1 Jun 2004 19:51:39 +0200 Subject: [PATCH] update info about available iseries_veth interfaces In-Reply-To: References: Message-ID: <20040601175139.GB30874@suse.de> On Fri, May 14, Dave Boutcher wrote: > Cooperative patch developed by olh and ntl that fixes a couple of nasty > lurking bugs in viopath.c and adds information required to know if the > iseries_veth module should be loaded on legacy iSeries systems. > /proc/iSeries/config contains now the number of configured virtual ethernet adapters. AVAILABLE_VETH should only indicate if there is at least one interface available, iseries_veth must be loaded in this case. printing the entire map will give installers some hints about what interface numbers will appear and how the MAC address may look like. diff -p -purN linux-2.6.7-rc2-bk2/arch/ppc64/kernel/viopath.c linux-2.6.7-rc2-bk2.ppc64/arch/ppc64/kernel/viopath.c --- linux-2.6.7-rc2-bk2/arch/ppc64/kernel/viopath.c 2004-06-01 18:58:45.000000000 +0200 +++ linux-2.6.7-rc2-bk2.ppc64/arch/ppc64/kernel/viopath.c 2004-06-01 19:02:34.000000000 +0200 @@ -191,7 +191,6 @@ static int proc_viopath_show(struct seq_ { char *buf; u16 vlanMap; - int vlanIndex; dma_addr_t handle; HvLpEvent_Rc hvrc; DECLARE_MUTEX_LOCKED(Semaphore); @@ -219,17 +218,10 @@ static int proc_viopath_show(struct seq_ down(&Semaphore); vlanMap = HvLpConfig_getVirtualLanIndexMap(); - vlanIndex = 0; - while (vlanMap != 0){ - if (vlanMap & 0x8000) - vlanIndex++;; - vlanMap = vlanMap << 1; - } buf[PAGE_SIZE-1] = '\0'; seq_printf(m, "%s", buf); - - seq_printf(m, "AVAILABLE_VETH=%d\n", vlanIndex ); + seq_printf(m, "AVAILABLE_VETH=%x\n", vlanMap); seq_printf(m, "SRLNBR=%c%c%c%c%c%c%c\n", e2a(xItExtVpdPanel.mfgID[2]), e2a(xItExtVpdPanel.mfgID[3]), -- USB is for mice, FireWire is for men! sUse lINUX ag, n?RNBERG ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From linas at austin.ibm.com Thu Jun 3 09:14:55 2004 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Wed, 2 Jun 2004 18:14:55 -0500 Subject: hotplug remove vs. device driver close Message-ID: <20040602181455.C17544@forte.austin.ibm.com> Hi, We are hitting a situation where we are hot-plug removing a pci card before closing the device driver. This seems to lead to kernel memory leaks if not outright crashes. I'm trying to understand what the correct solution to this is supposed to be. For example: 'ifup eth0' and 'ifdown eth0' are what usually cause an ethernet device driver to be opened/closed. Seprately, we have a userland tool that can be used to power off the pci slot, and thus perform a hotplug unconfigure in the kernel (i.e. calls pci_remove_bus_device()). Thus, the sysadmin currently has the power to hot-remove a device without first closing the device driver. Surely, this is bad. (Right?) But how is this supposed to be handled? Please don't tell me that a good sysadmin should never do that ... in the hothouse of the server room, crazy stuff happens and it should not result in a server crash so easily ... I'm hoping that the answer also isn't that 'the hotplug scripts should do that', since hotplug scripts can be buggy, or can crash for many reasons; such events shouldn't bring down the kernel. So I conclude two possibilities: -- All device drivers should watch for hotplug remove, and close themselves down in such an event -- The syscall that allows the pci slot to be powered off should also go through the steps of closing the device driver first. Is there another possibility? What's the right way of handling this? --linas ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From greg at kroah.com Thu Jun 3 09:28:51 2004 From: greg at kroah.com (Greg KH) Date: Wed, 2 Jun 2004 16:28:51 -0700 Subject: hotplug remove vs. device driver close In-Reply-To: <20040602181455.C17544@forte.austin.ibm.com> References: <20040602181455.C17544@forte.austin.ibm.com> Message-ID: <20040602232851.GA24169@kroah.com> On Wed, Jun 02, 2004 at 06:14:55PM -0500, linas at austin.ibm.com wrote: > > Hi, > > We are hitting a situation where we are hot-plug removing a pci card before > closing the device driver. This seems to lead to kernel memory leaks if not > outright crashes. I'm trying to understand what the correct solution to this > is supposed to be. To paraphrase from the PCI Hotplug spec, "DO NOT DO THAT!" > For example: 'ifup eth0' and 'ifdown eth0' are what usually cause an ethernet > device driver to be opened/closed. Seprately, we have a userland tool that > can be used to power off the pci slot, and thus perform a hotplug unconfigure > in the kernel (i.e. calls pci_remove_bus_device()). Thus, the sysadmin > currently has the power to hot-remove a device without first closing the > device driver. Surely, this is bad. (Right?) But how is this supposed to > be handled? Again, do not do that. > Please don't tell me that a good sysadmin should never do that ... in the > hothouse of the server room, crazy stuff happens and it should not result > in a server crash so easily ... Tough, do not do that. That being said, a lot of the PCI drivers can recover from this as they also work for PCMCIA devices, and they need to be able to handle this. It is possible, and pretty simple to fix within the driver itself. > I'm hoping that the answer also isn't that 'the hotplug scripts should > do that', since hotplug scripts can be buggy, or can crash for many reasons; > such events shouldn't bring down the kernel. No, it's not a hotplug script issue. > So I conclude two possibilities: > > -- All device drivers should watch for hotplug remove, and close themselves > down in such an event No, they should watch for errors when trying to read and write from their devices and if that happens, handle it properly. The kernel will tell them at some time that the device is really gone by calling the disconnect() callback. > -- The syscall that allows the pci slot to be powered off should also > go through the steps of closing the device driver first. No. Read the PCI Hotplug spec. > Is there another possibility? What's the right way of handling this? See above. What driver is dying for you? It should be quite easy to fix. thanks, greg k-h ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Thu Jun 3 11:40:04 2004 From: anton at samba.org (Anton Blanchard) Date: Thu, 3 Jun 2004 11:40:04 +1000 Subject: hotplug remove vs. device driver close In-Reply-To: <20040602232851.GA24169@kroah.com> References: <20040602181455.C17544@forte.austin.ibm.com> <20040602232851.GA24169@kroah.com> Message-ID: <20040603014004.GA16092@krispykreme> Hi, > > We are hitting a situation where we are hot-plug removing a pci card > > before closing the device driver. This seems to lead to kernel > > memory leaks if not outright crashes. I'm trying to understand what > > the correct solution to this is supposed to be. > > To paraphrase from the PCI Hotplug spec, "DO NOT DO THAT!" How do you currently guarantee this on cardbus? Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From greg at kroah.com Fri Jun 4 02:20:20 2004 From: greg at kroah.com (Greg KH) Date: Thu, 3 Jun 2004 09:20:20 -0700 Subject: hotplug remove vs. device driver close In-Reply-To: <20040603014004.GA16092@krispykreme> References: <20040602181455.C17544@forte.austin.ibm.com> <20040602232851.GA24169@kroah.com> <20040603014004.GA16092@krispykreme> Message-ID: <20040603162020.GA3022@kroah.com> On Thu, Jun 03, 2004 at 11:40:04AM +1000, Anton Blanchard wrote: > > Hi, > > > > We are hitting a situation where we are hot-plug removing a pci card > > > before closing the device driver. This seems to lead to kernel > > > memory leaks if not outright crashes. I'm trying to understand what > > > the correct solution to this is supposed to be. > > > > To paraphrase from the PCI Hotplug spec, "DO NOT DO THAT!" > > How do you currently guarantee this on cardbus? We make no such guarantee. As I stated, the Cardbus/PCMCIA handle this quite easily, so it is pretty simple to fix up a PCI driver to also handle this. But the main answer is that the PCI Hotplug spec states that the OS does NOT have to protect for this happening to regular PCI devices. thanks, greg k-h ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From linas at austin.ibm.com Fri Jun 4 04:50:44 2004 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Thu, 3 Jun 2004 13:50:44 -0500 Subject: hotplug remove vs. device driver close In-Reply-To: <20040603162020.GA3022@kroah.com>; from greg@kroah.com on Thu, Jun 03, 2004 at 09:20:20AM -0700 References: <20040602181455.C17544@forte.austin.ibm.com> <20040602232851.GA24169@kroah.com> <20040603014004.GA16092@krispykreme> <20040603162020.GA3022@kroah.com> Message-ID: <20040603135044.E17544@forte.austin.ibm.com> On Thu, Jun 03, 2004 at 09:20:20AM -0700, Greg KH wrote: > On Thu, Jun 03, 2004 at 11:40:04AM +1000, Anton Blanchard wrote: > > > > > > We are hitting a situation where we are hot-plug removing a pci card > > > > before closing the device driver. This seems to lead to kernel > > > > memory leaks if not outright crashes. I'm trying to understand what > > > > the correct solution to this is supposed to be. > > > > > > To paraphrase from the PCI Hotplug spec, "DO NOT DO THAT!" > > > > How do you currently guarantee this on cardbus? > > We make no such guarantee. As I stated, the Cardbus/PCMCIA handle this > quite easily, so it is pretty simple to fix up a PCI driver to also > handle this. > > But the main answer is that the PCI Hotplug spec states that the OS does > NOT have to protect for this happening to regular PCI devices. So if I understand what you are saying: if the OS crashes because of a sysadmin error or a script error during pci hotplug remove, that's considered OK? I understand why the PCI spec would say that: they have no desire to over-burden already struggling OS developers: the PCI spec committee probably thinks in terms of "provide function not policy". That's normal and as it should be. But in the five-9's world of high availability, automatic failover, etc. etc. this sure sounds like a great way of putting executives on a warpath. I humbly suggest that the Linux kernel policy should be that we do better than th PCI spec, and attempt minimize damage due to operator error. If not all drivers or tools or subsystems adhere to this policy, so be it, but robustness should be a goal. --linas ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From greg at kroah.com Fri Jun 4 05:02:06 2004 From: greg at kroah.com (Greg KH) Date: Thu, 3 Jun 2004 12:02:06 -0700 Subject: hotplug remove vs. device driver close In-Reply-To: <20040603135044.E17544@forte.austin.ibm.com> References: <20040602181455.C17544@forte.austin.ibm.com> <20040602232851.GA24169@kroah.com> <20040603014004.GA16092@krispykreme> <20040603162020.GA3022@kroah.com> <20040603135044.E17544@forte.austin.ibm.com> Message-ID: <20040603190206.GA23248@kroah.com> On Thu, Jun 03, 2004 at 01:50:44PM -0500, linas at austin.ibm.com wrote: > On Thu, Jun 03, 2004 at 09:20:20AM -0700, Greg KH wrote: > > On Thu, Jun 03, 2004 at 11:40:04AM +1000, Anton Blanchard wrote: > > > > > > > > We are hitting a situation where we are hot-plug removing a pci card > > > > > before closing the device driver. This seems to lead to kernel > > > > > memory leaks if not outright crashes. I'm trying to understand what > > > > > the correct solution to this is supposed to be. > > > > > > > > To paraphrase from the PCI Hotplug spec, "DO NOT DO THAT!" > > > > > > How do you currently guarantee this on cardbus? > > > > We make no such guarantee. As I stated, the Cardbus/PCMCIA handle this > > quite easily, so it is pretty simple to fix up a PCI driver to also > > handle this. > > > > But the main answer is that the PCI Hotplug spec states that the OS does > > NOT have to protect for this happening to regular PCI devices. > > So if I understand what you are saying: if the OS crashes because of > a sysadmin error or a script error during pci hotplug remove, that's > considered OK? As sysadmin I can delete your whole root fs, and reboot the box into obvilion. Are you considering changing this ability too? :) If you are really worried about this, then look into a different permisssion model for Linux like SELinux. Or you can simply fix up your PCI driver to properly handle reading all FF when the device has been removed. That seems to be what you need to do to solve this for your small subset of drivers on your platform, correct? > I understand why the PCI spec would say that: they have no desire > to over-burden already struggling OS developers: the PCI spec > committee probably thinks in terms of "provide function not policy". > That's normal and as it should be. That's also what the kernel provides, function not policy. Put your policy in userspace and force your admin to use a tool that ensures that the device has properly shutdown anything that is bound to that device before it tells the kernel to remove it from the system. thanks, greg k-h ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From brazilnut at us.ibm.com Fri Jun 4 05:23:04 2004 From: brazilnut at us.ibm.com (Don Fry) Date: Thu, 3 Jun 2004 12:23:04 -0700 (PDT) Subject: hotplug remove vs. device driver close In-Reply-To: <20040603190206.GA23248@kroah.com> from "Greg KH" at Jun 03, 2004 12:02:06 PM Message-ID: <200406031923.i53JN4B14127@DYN318364BLD.beaverton.ibm.com> > > > We make no such guarantee. As I stated, the Cardbus/PCMCIA handle this > > > quite easily, so it is pretty simple to fix up a PCI driver to also > > > handle this. > > > > > > But the main answer is that the PCI Hotplug spec states that the OS does > > > NOT have to protect for this happening to regular PCI devices. > > > > So if I understand what you are saying: if the OS crashes because of > > a sysadmin error or a script error during pci hotplug remove, that's > > considered OK? > > As sysadmin I can delete your whole root fs, and reboot the box into > obvilion. Are you considering changing this ability too? :) > > If you are really worried about this, then look into a different > permisssion model for Linux like SELinux. > > Or you can simply fix up your PCI driver to properly handle reading all > FF when the device has been removed. That seems to be what you need to > do to solve this for your small subset of drivers on your platform, > correct? > The pcnet32 driver tries to do the 'right thing' when it reads 0xffff, but that does not include doing a 'close' prior to being removed. The driver could keep some state around so that if its remove routine was called without close first, it would cleanup, but I don't know of any network driver that does this. The remove with a close is where the leak/crash might occur. > > I understand why the PCI spec would say that: they have no desire > > to over-burden already struggling OS developers: the PCI spec > > committee probably thinks in terms of "provide function not policy". > > That's normal and as it should be. > > That's also what the kernel provides, function not policy. Put your > policy in userspace and force your admin to use a tool that ensures that > the device has properly shutdown anything that is bound to that device > before it tells the kernel to remove it from the system. > > thanks, > > greg k-h -- Don Fry brazilnut at us.ibm.com ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From greg at kroah.com Fri Jun 4 05:28:17 2004 From: greg at kroah.com (Greg KH) Date: Thu, 3 Jun 2004 12:28:17 -0700 Subject: hotplug remove vs. device driver close In-Reply-To: <200406031923.i53JN4B14127@DYN318364BLD.beaverton.ibm.com> References: <20040603190206.GA23248@kroah.com> <200406031923.i53JN4B14127@DYN318364BLD.beaverton.ibm.com> Message-ID: <20040603192817.GC23564@kroah.com> On Thu, Jun 03, 2004 at 12:23:04PM -0700, Don Fry wrote: > > > > We make no such guarantee. As I stated, the Cardbus/PCMCIA handle this > > > > quite easily, so it is pretty simple to fix up a PCI driver to also > > > > handle this. > > > > > > > > But the main answer is that the PCI Hotplug spec states that the OS does > > > > NOT have to protect for this happening to regular PCI devices. > > > > > > So if I understand what you are saying: if the OS crashes because of > > > a sysadmin error or a script error during pci hotplug remove, that's > > > considered OK? > > > > As sysadmin I can delete your whole root fs, and reboot the box into > > obvilion. Are you considering changing this ability too? :) > > > > If you are really worried about this, then look into a different > > permisssion model for Linux like SELinux. > > > > Or you can simply fix up your PCI driver to properly handle reading all > > FF when the device has been removed. That seems to be what you need to > > do to solve this for your small subset of drivers on your platform, > > correct? > > > > The pcnet32 driver tries to do the 'right thing' when it reads 0xffff, > but that does not include doing a 'close' prior to being removed. The > driver could keep some state around so that if its remove routine was > called without close first, it would cleanup, but I don't know of any > network driver that does this. > > The remove with a close is where the leak/crash might occur. That's up to the upper layer, above the network driver to do, right? It's the same way for all USB and SCSI/block devices. Remember, the driver isn't unloaded at device removal time, it should always be bound to memory until the userspace "open" goes away. thanks, greg k-h ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From linas at austin.ibm.com Fri Jun 4 05:34:23 2004 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Thu, 3 Jun 2004 14:34:23 -0500 Subject: hotplug remove vs. device driver close In-Reply-To: <20040603190206.GA23248@kroah.com>; from greg@kroah.com on Thu, Jun 03, 2004 at 12:02:06PM -0700 References: <20040602181455.C17544@forte.austin.ibm.com> <20040602232851.GA24169@kroah.com> <20040603014004.GA16092@krispykreme> <20040603162020.GA3022@kroah.com> <20040603135044.E17544@forte.austin.ibm.com> <20040603190206.GA23248@kroah.com> Message-ID: <20040603143423.G17544@forte.austin.ibm.com> On Thu, Jun 03, 2004 at 12:02:06PM -0700, Greg KH wrote: > > Or you can simply fix up your PCI driver to properly handle reading all > FF when the device has been removed. That seems to be what you need to > do to solve this for your small subset of drivers on your platform, > correct? Yes. Well, specifically, the check will be "if (0xff && pci_unplugged) then close();" Due to the nature of the existing PPC64 code, this check will occur in the ppc64 inb()/inw() macros, and thus solves the problem for my little neck of the woods. Is there something in writing somewhere that discusses this as a guideline for Linux device driver authors? Something that I can throw at the driver authors and say "here do this, this fixes it for all arches"? --linas ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From linas at austin.ibm.com Fri Jun 4 05:39:39 2004 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Thu, 3 Jun 2004 14:39:39 -0500 Subject: hotplug remove vs. device driver close In-Reply-To: <200406031923.i53JN4B14127@DYN318364BLD.beaverton.ibm.com>; from brazilnut@us.ibm.com on Thu, Jun 03, 2004 at 12:23:04PM -0700 References: <20040603190206.GA23248@kroah.com> <200406031923.i53JN4B14127@DYN318364BLD.beaverton.ibm.com> Message-ID: <20040603143939.H17544@forte.austin.ibm.com> On Thu, Jun 03, 2004 at 12:23:04PM -0700, Don Fry wrote: > > The pcnet32 driver tries to do the 'right thing' when it reads 0xffff, > but that does not include doing a 'close' prior to being removed. The > driver could keep some state around so that if its remove routine was > called without close first, it would cleanup, but I don't know of any > network driver that does this. What I get out of this thread is that pcnet32, and in fact, all drivers, should keep sufficient state around so that close() can be called either after or before remove(). --linas ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From brazilnut at us.ibm.com Fri Jun 4 06:02:27 2004 From: brazilnut at us.ibm.com (Don Fry) Date: Thu, 3 Jun 2004 13:02:27 -0700 (PDT) Subject: hotplug remove vs. device driver close In-Reply-To: <20040603143939.H17544@forte.austin.ibm.com> from "linas@austin.ibm.com" at Jun 03, 2004 02:39:39 PM Message-ID: <200406032002.i53K2Sr14159@DYN318364BLD.beaverton.ibm.com> > > > > The pcnet32 driver tries to do the 'right thing' when it reads 0xffff, > > but that does not include doing a 'close' prior to being removed. The > > driver could keep some state around so that if its remove routine was > > called without close first, it would cleanup, but I don't know of any > > network driver that does this. > > What I get out of this thread is that pcnet32, and in fact, all drivers, > should keep sufficient state around so that close() can be called either > after or before remove(). > Today in 2.6.6 if I try and do a rmmod pcnet32 and something is still using the device, the rmmod will wait until the device is closed, and then it goes away. If the unplug does the same thing, and doesn't complete until the close occurs, then I would not expect to leak anything, or crash either. > --linas > > -- Don Fry brazilnut at us.ibm.com ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From greg at kroah.com Fri Jun 4 06:39:37 2004 From: greg at kroah.com (Greg KH) Date: Thu, 3 Jun 2004 13:39:37 -0700 Subject: hotplug remove vs. device driver close In-Reply-To: <200406032002.i53K2Sr14159@DYN318364BLD.beaverton.ibm.com> References: <20040603143939.H17544@forte.austin.ibm.com> <200406032002.i53K2Sr14159@DYN318364BLD.beaverton.ibm.com> Message-ID: <20040603203937.GA25755@kroah.com> On Thu, Jun 03, 2004 at 01:02:27PM -0700, Don Fry wrote: > > > > > > The pcnet32 driver tries to do the 'right thing' when it reads 0xffff, > > > but that does not include doing a 'close' prior to being removed. The > > > driver could keep some state around so that if its remove routine was > > > called without close first, it would cleanup, but I don't know of any > > > network driver that does this. > > > > What I get out of this thread is that pcnet32, and in fact, all drivers, > > should keep sufficient state around so that close() can be called either > > after or before remove(). > > > > Today in 2.6.6 if I try and do a rmmod pcnet32 and something is still using > the device, the rmmod will wait until the device is closed, and then it > goes away. Yes, that's a "feature" of the network stack :) > If the unplug does the same thing, and doesn't complete until the > close occurs, then I would not expect to leak anything, or crash > either. The device unplug knows nothing about the upper layers that the device might have attached to, sorry. thanks, greg k-h ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From linas at austin.ibm.com Fri Jun 4 08:25:03 2004 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Thu, 3 Jun 2004 17:25:03 -0500 Subject: hotplug remove vs. device driver close In-Reply-To: <200406032002.i53K2Sr14159@DYN318364BLD.beaverton.ibm.com>; from brazilnut@us.ibm.com on Thu, Jun 03, 2004 at 01:02:27PM -0700 References: <20040603143939.H17544@forte.austin.ibm.com> <200406032002.i53K2Sr14159@DYN318364BLD.beaverton.ibm.com> Message-ID: <20040603172503.J17544@forte.austin.ibm.com> Greg, My apologies, I think I needed to read the source before posting to the mailing list. (yes, my middle name really is 'Luke', no kidding). I might have been on a wild goose chase. See below. On Thu, Jun 03, 2004 at 01:02:27PM -0700, Don Fry wrote: > > > > > > The pcnet32 driver tries to do the 'right thing' when it reads 0xffff, > > > but that does not include doing a 'close' prior to being removed. The > > > driver could keep some state around so that if its remove routine was > > > called without close first, it would cleanup, but I don't know of any > > > network driver that does this. > > > > What I get out of this thread is that pcnet32, and in fact, all drivers, > > should keep sufficient state around so that close() can be called either > > after or before remove(). > > Today in 2.6.6 if I try and do a rmmod pcnet32 and something is still using > the device, the rmmod will wait until the device is closed, and then it > goes away. Where? pcnet32_cleanup_module() doesn't seem to wait for anything. However, I'm reading the source, tracing through a power-off, and I don't see any device driver memory leaks, at least not in the 'typical' pcnet32 driver. What I do see is that the the device driver close() routine is called before the device driver memory is released. Anatomy of a device remove, --------------------------- starting with an echo 1 > /sysfs/bus/ .. power file ... I trace this through the ppc64 rpaphp hotplug code, and the pcnet32 code. I did this manually, I hope there aren't any mistakes. power_write_file () // in /drivers/pci/hotplug/pci_hotplug_core.c { calls slot->ops->disable_slot() which is just struct hotplug_slot_ops ->disable_slot() which is just disable_slot (struct hotplug_slot *) // in /drivers/pci/hotplug/rpaphp_core.c { which calls rpa_php_unconfig_pci_adapter (struct slot *) // in rpaphp_pci.c { calls pci_remove_bus_device (struct pci_dev *) // in /drivers/pci/remove.c { calls pci_destroy_dev (struct pci_dev *) { calls device_unregister (&dev->dev) // in /drivers/base/core.c { calls device_del (struct device *) { calls bus_remove_device() // in /drivers/base/bus.c { calls device_release_driver() { calls struct device_driver->remove() which is just pci_device_remove() // in /drivers/pci/pci_driver.c { calls struct pci_driver->remove() which is just pcnet32_remove_one() // in /drivers/net/pcnet32.c { calls unregister_netdev() // in /net/core/dev.c { calls dev_close() // in /net/core/dev.c { calls dev->stop(); which is just pcnet32_close() // in pcnet32.c { which does what you wanted to stop the device } } } which frees pcnet32 device driver memory } }}}}}} ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From zhouwoody at yahoo.com Fri Jun 4 12:38:08 2004 From: zhouwoody at yahoo.com (Woody Zhou) Date: Thu, 3 Jun 2004 19:38:08 -0700 (PDT) Subject: [PATCH] increase the upper limit of sg_io64.dxfer_len to make "sg_logs -p=0x0f /dev/sgN" happy Message-ID: <20040604023808.87240.qmail@web60007.mail.yahoo.com> Hello all, Following is a patch to remedy an "invalid argument" error while executing "sg_logs -p=0x0f /dev/sgN". I submit it here for your review. At this place /dev/sgN should be mapped to a SCSI device which support page 0x0f(Application client), such as IBM IC35L036UCDY10-0 disks. Index: 2.4.21-15.EL/arch/ppc64/kernel/ioctl32.c =================================================================== --- arch/ppc64/kernel/ioctl32.c.orig 2004-05-25 15:18:46.000000000 +0800 +++ arch/ppc64/kernel/ioctl32.c 2004-05-25 15:20:33.000000000 +0800 @@ -1301,7 +1301,7 @@ goto out; } } else { - if (sg_io64.dxfer_len > 4*PAGE_SIZE) { + if (sg_io64.dxfer_len > 8*PAGE_SIZE) { err = -EINVAL; goto out; } =================================================================== As follow is a short explanation for this. In the conversion code between 32bit and 64bit native ioctl(arch/ppc64/kernel/ioctl32.c), sg_ioctl_trans limit the sg_io64.dxfer_len to 4 pages, maybe to stop users from performing denial of service attack by asking the kernel to kmalloc an unreasonable amount of memory. However the size limit seems to be too small, since SCSI LOG SENSE page 0x0f always ask for 4*PAGE_SIZE+4. So I made a change to this: increasing it to 8*PAGE_SIZE. This patch is suggested by Matin Schwenke at OZlab. So thanks for your guidance, Martin! It is made against Redhat's 2.4.21-15.EL, and should also apply to other 2.4 kernel. Thanks and Best Regards --------------------------------------------- Wu Zhou LTC and pLinux Testing, China Software Development Lab, Beijing TEL: (8610)82782244-2830 FAX: (8610)82782244-2887 E-mail: zhouwu at cn.ibm.com ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From benh at kernel.crashing.org Fri Jun 4 13:58:23 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Fri, 04 Jun 2004 13:58:23 +1000 Subject: hotplug remove vs. device driver close In-Reply-To: <20040603143939.H17544@forte.austin.ibm.com> References: <20040603190206.GA23248@kroah.com> <200406031923.i53JN4B14127@DYN318364BLD.beaverton.ibm.com> <20040603143939.H17544@forte.austin.ibm.com> Message-ID: <1086321503.1838.62.camel@gaston> On Fri, 2004-06-04 at 05:39, linas at austin.ibm.com wrote: > On Thu, Jun 03, 2004 at 12:23:04PM -0700, Don Fry wrote: > > > > The pcnet32 driver tries to do the 'right thing' when it reads 0xffff, > > but that does not include doing a 'close' prior to being removed. The > > driver could keep some state around so that if its remove routine was > > called without close first, it would cleanup, but I don't know of any > > network driver that does this. > > What I get out of this thread is that pcnet32, and in fact, all drivers, > should keep sufficient state around so that close() can be called either > after or before remove(). I think the problem is more specific to the netdev interface no ? Isn't it just that unregister_netdevice fails when it's open ? In which case, remove should fail ... which may not be what you want, but I don't see a proper solution unless we fix the network core. Hrm... looking at the code, unregister_netdevice is supposed to do a close... Maybe something isn't working properly there... Ben. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From greg at kroah.com Sat Jun 5 02:24:45 2004 From: greg at kroah.com (Greg KH) Date: Fri, 4 Jun 2004 09:24:45 -0700 Subject: hotplug remove vs. device driver close In-Reply-To: <20040603143423.G17544@forte.austin.ibm.com> References: <20040602181455.C17544@forte.austin.ibm.com> <20040602232851.GA24169@kroah.com> <20040603014004.GA16092@krispykreme> <20040603162020.GA3022@kroah.com> <20040603135044.E17544@forte.austin.ibm.com> <20040603190206.GA23248@kroah.com> <20040603143423.G17544@forte.austin.ibm.com> Message-ID: <20040604162445.GA9342@kroah.com> On Thu, Jun 03, 2004 at 02:34:23PM -0500, linas at austin.ibm.com wrote: > > Is there something in writing somewhere that discusses this as a > guideline for Linux device driver authors? Something that I can > throw at the driver authors and say "here do this, this fixes it > for all arches"? Point them at this thread :) Or point them to me. Or send me the wording you want to see added to Documentation/pci.txt that would help you out. thanks, greg k-h ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From linas at austin.ibm.com Sat Jun 5 03:26:41 2004 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Fri, 4 Jun 2004 12:26:41 -0500 Subject: hotplug remove vs. device driver close In-Reply-To: <1086321503.1838.62.camel@gaston>; from benh@kernel.crashing.org on Fri, Jun 04, 2004 at 01:58:23PM +1000 References: <20040603190206.GA23248@kroah.com> <200406031923.i53JN4B14127@DYN318364BLD.beaverton.ibm.com> <20040603143939.H17544@forte.austin.ibm.com> <1086321503.1838.62.camel@gaston> Message-ID: <20040604122641.N17544@forte.austin.ibm.com> On Fri, Jun 04, 2004 at 01:58:23PM +1000, Benjamin Herrenschmidt wrote: > Hrm... looking at the code, unregister_netdevice is supposed to do > a close... Maybe something isn't working properly there... Err, yes, I discovered this yesterday. There's a delay in mail delivery somehwere, possibly at my end. Seems the issues I raised aren't a problem, its just that some of the device drivers might be buggy, will investigate offline. --linas ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From haveblue at us.ibm.com Sat Jun 5 07:37:38 2004 From: haveblue at us.ibm.com (Dave Hansen) Date: Fri, 04 Jun 2004 14:37:38 -0700 Subject: [RFC] don't create cpu/online sysfs file Message-ID: <1086385058.24915.86.camel@nighthawk> I sent this out earlier this week, but wanted to make sure everybody is happy with it before I sent it upstream. I'm doing it backwards: [PATCH] before [RFC]. :) Rusty said he didn't have a problem with it already. Anton, do mind putting this in your patch queue, or should I send it upstream myself? -- The following patch restricts creation of the /sys/devices/system/cpu/cpuX/online file to conditions where it is known that cpu hotplugging might be possible. It also leaves room for a much more complex method of deciding this information in the future, on a per-cpu basis. It fixes a bug where CPU hotplug ppc64 RTAS calls were being made on a non-partitioned system. This caused RTAS assertions, which are bad. Any new architecture that defines CONFIG_HOTPLUG_CPU will need to implement a cpu_is_hotpluggable() function. This could be overcome by a series of #ifdefs, but I think someone porting CPU hotplug to a new architecture can figure this one out. Tested on 16-way ppc64 LPAR and 8-way bare-metal ppc64. Compile tested on x86. -- Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: ppc64-cpuhotplug-online-2.6.7-rc2-mm2-3.patch Type: text/x-patch Size: 2390 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20040604/52bdf763/attachment.bin From jschopp at austin.ibm.com Sat Jun 5 08:06:14 2004 From: jschopp at austin.ibm.com (Joel Schopp) Date: Fri, 04 Jun 2004 17:06:14 -0500 Subject: [RFC] don't create cpu/online sysfs file In-Reply-To: <1086385058.24915.86.camel@nighthawk> References: <1086385058.24915.86.camel@nighthawk> Message-ID: <40C0F256.8090809@austin.ibm.com> I might change cpu_is_hotpluggable to __cpu_is_hotpluggable to help indicate it is a platform specific function. Also, won't you want to stub out the function for the other platforms that do cpu hotplug? -Joel Dave Hansen wrote: > I sent this out earlier this week, but wanted to make sure everybody is > happy with it before I sent it upstream. I'm doing it backwards: > [PATCH] before [RFC]. :) > > Rusty said he didn't have a problem with it already. Anton, do mind > putting this in your patch queue, or should I send it upstream myself? > > -- > > The following patch restricts creation of the > /sys/devices/system/cpu/cpuX/online file to conditions where it is known > that cpu hotplugging might be possible. It also leaves room for a much > more complex method of deciding this information in the future, on a > per-cpu basis. > > It fixes a bug where CPU hotplug ppc64 RTAS calls were being made on a > non-partitioned system. This caused RTAS assertions, which are bad. > > Any new architecture that defines CONFIG_HOTPLUG_CPU will need to > implement a cpu_is_hotpluggable() function. This could be overcome by a > series of #ifdefs, but I think someone porting CPU hotplug to a new > architecture can figure this one out. > Tested on 16-way ppc64 LPAR and 8-way bare-metal ppc64. Compile tested > on x86. > > -- Dave > > > ------------------------------------------------------------------------ > > Signed-off-by: Dave Hansen > > diff -urp linux-2.6.7-rc2-mm2-clean/arch/ppc64/kernel/smp.c linux-2.6.7-rc2-mm2-cpuonline/arch/ppc64/kernel/smp.c > --- linux-2.6.7-rc2-mm2-clean/arch/ppc64/kernel/smp.c Fri Jun 4 13:27:13 2004 > +++ linux-2.6.7-rc2-mm2-cpuonline/arch/ppc64/kernel/smp.c Fri Jun 4 13:27:29 2004 > @@ -444,6 +444,21 @@ static inline void look_for_more_cpus(vo > for (i = 0; i < maxcpus; i++) > cpu_set(i, cpu_possible_map); > } > + > +int cpu_is_hotpluggable(struct cpu *cpu) > +{ > + /* > + * For now, we just see if the system supports making > + * the RTAS calls for CPU hotplug. But, there may be a > + * more comprehensive way to do this for an individual > + * CPU. For instance, the boot cpu might never be valid > + * for hotplugging. > + */ > + if (systemcfg->platform == PLATFORM_PSERIES_LPAR) > + return 1; > + > + return 0; > +} > #else /* ... CONFIG_HOTPLUG_CPU */ > static inline int __devinit smp_startup_cpu(unsigned int lcpu) > { > diff -urp linux-2.6.7-rc2-mm2-clean/drivers/base/cpu.c linux-2.6.7-rc2-mm2-cpuonline/drivers/base/cpu.c > --- linux-2.6.7-rc2-mm2-clean/drivers/base/cpu.c Fri Jun 4 13:27:09 2004 > +++ linux-2.6.7-rc2-mm2-cpuonline/drivers/base/cpu.c Fri Jun 4 13:27:29 2004 > @@ -48,7 +48,8 @@ static SYSDEV_ATTR(online, 0600, show_on > > static void __init register_cpu_control(struct cpu *cpu) > { > - sysdev_create_file(&cpu->sysdev, &attr_online); > + if (cpu_is_hotpluggable(cpu)) > + sysdev_create_file(&cpu->sysdev, &attr_online); > } > #else /* ... !CONFIG_HOTPLUG_CPU */ > static inline void register_cpu_control(struct cpu *cpu) > diff -urp linux-2.6.7-rc2-mm2-clean/include/linux/cpu.h linux-2.6.7-rc2-mm2-cpuonline/include/linux/cpu.h > --- linux-2.6.7-rc2-mm2-clean/include/linux/cpu.h Fri Jun 4 13:27:11 2004 > +++ linux-2.6.7-rc2-mm2-cpuonline/include/linux/cpu.h Fri Jun 4 13:27:29 2004 > @@ -65,6 +65,10 @@ extern struct semaphore cpucontrol; > register_cpu_notifier(&fn##_nb); \ > } > int cpu_down(unsigned int cpu); > + > +/* expected to be defined in arch-specific code */ > +extern int cpu_is_hotpluggable(struct cpu *cpu); > + > #define cpu_is_offline(cpu) unlikely(!cpu_online(cpu)) > #else > #define lock_cpu_hotplug() do { } while (0) > @@ -74,6 +78,7 @@ int cpu_down(unsigned int cpu); > > /* CPUs don't go offline once they're online w/o CONFIG_HOTPLUG_CPU */ > #define cpu_is_offline(cpu) 0 > +#define cpu_is_hotpluggable(cpu) 0 > #endif > > #endif /* _LINUX_CPU_H_ */ ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From haveblue at us.ibm.com Sat Jun 5 08:32:01 2004 From: haveblue at us.ibm.com (Dave Hansen) Date: Fri, 04 Jun 2004 15:32:01 -0700 Subject: [RFC] don't create cpu/online sysfs file In-Reply-To: <40C0F256.8090809@austin.ibm.com> References: <1086385058.24915.86.camel@nighthawk> <40C0F256.8090809@austin.ibm.com> Message-ID: <1086388321.24915.115.camel@nighthawk> On Fri, 2004-06-04 at 15:06, Joel Schopp wrote: > I might change cpu_is_hotpluggable to __cpu_is_hotpluggable to help > indicate it is a platform specific function. Yeah, that naming is a lot more consistent with the other functions in the arch-specific cpu hotplug code. New version attached. > Also, won't you want to > stub out the function for the other platforms that do cpu hotplug? Gah. There weren't any in 2.6.6, but it looks like ia64 got merged recently. I see it in 2.6.7-rc2-mm2. cc'ing ia64 list... Any comments from the ia64 crowd on this one? It should maintain existing behavior on your platform. You can always make that function smarter in the future if you like. -- Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: cpuhotplug-online-2.6.7-rc2-mm2-4.patch Type: text/x-patch Size: 2894 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20040604/a26ef9e2/attachment.bin From roland at topspin.com Sat Jun 5 08:32:05 2004 From: roland at topspin.com (Roland Dreier) Date: 04 Jun 2004 15:32:05 -0700 Subject: Distro for ppc64/2.6 work? Message-ID: <52oenzosyi.fsf@topspin.com> I have an IBM pSeries 630 box that I would like to start using for kernel 2.6-based development. What is a good distribution to start with? I'm not that concerned about the distribution installing 2.6 to start with, but I'd like to avoid dealing with having to build a newer toolchain, install module-init-tools, etc. if possible. Along the same lines, should a recent stock Linus kernel (say 2.6.6) work on a p630 (with pSeries_defconfig), or is there a better tree to work with? Thanks, Roland ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From ashok.raj at intel.com Sat Jun 5 08:49:52 2004 From: ashok.raj at intel.com (Ashok Raj) Date: Fri, 4 Jun 2004 15:49:52 -0700 Subject: [lhcs-devel] Re: [RFC] don't create cpu/online sysfs file In-Reply-To: <1086388321.24915.115.camel@nighthawk>; from haveblue@us.ibm.com on Fri, Jun 04, 2004 at 03:32:01PM -0700 References: <1086388321.24915.115.camel@nighthawk> Message-ID: <20040604154952.A15326@unix-os.sc.intel.com> On Fri, Jun 04, 2004 at 03:32:01PM -0700, Dave Hansen wrote: > > On Fri, 2004-06-04 at 15:06, Joel Schopp wrote: > > I might change cpu_is_hotpluggable to __cpu_is_hotpluggable to help > > indicate it is a platform specific function. > > Yeah, that naming is a lot more consistent with the other functions in > the arch-specific cpu hotplug code. New version attached. > > > Also, won't you want to > > stub out the function for the other platforms that do cpu hotplug? > > Gah. There weren't any in 2.6.6, but it looks like ia64 got merged > recently. I see it in 2.6.7-rc2-mm2. cc'ing ia64 list... > > Any comments from the ia64 crowd on this one? It should maintain > existing behavior on your platform. You can always make that function > smarter in the future if you like. In IA64 if we consider just logical offline, any processor could be put back in SAL_BOOT_RENDEZ mode, i.e the same state the processor was before woken as a secondary proccessor. (including the boot cpu). [this code to place the processor in this mode is not yet in the mainline code for ia64 merged in the 2.6.7-rc series. Current state of CPU hotplug for IA64 we dont permit boot cpu as there is some code that needs to be changed (master timekeeper), once we do that any cpu could be taken logically offline. Instead of not creating the control files, would it be fine if we are able to display a status instead? In think in the long run, if we are going to remove the /proc/cpu's etc, how about make an info file that can display status of all cpu's present. i.e place a file in /sys/devices/system/cpuinfo, which when one does a cat on can display cpu0: online, not offlinable cpu1: online cpu2: offline (meaning present) the reason this cannot be determined at early time, is say if a set of cpu's are in a special mode, i.e only those 4 cpu's can retrieve a set of platform registers. for error processing. And i can offline each of those, until i run into the last of those 4 cpus. I would prefer to not have a macro to preventy its creation, but have a facility to know the offlineable status via a single information file, and let __cpu_disable() determine if offline should fail based on current ability to offline a cpu. what do you think? Cheers, ashok ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From haveblue at us.ibm.com Sat Jun 5 09:04:17 2004 From: haveblue at us.ibm.com (Dave Hansen) Date: Fri, 04 Jun 2004 16:04:17 -0700 Subject: [lhcs-devel] Re: [RFC] don't create cpu/online sysfs file In-Reply-To: <20040604154952.A15326@unix-os.sc.intel.com> References: <1086388321.24915.115.camel@nighthawk> <20040604154952.A15326@unix-os.sc.intel.com> Message-ID: <1086390257.24915.132.camel@nighthawk> On Fri, 2004-06-04 at 15:49, Ashok Raj wrote: > place a file in /sys/devices/system/cpuinfo, which when one does a cat on > can display > > cpu0: online, not offlinable > cpu1: online > cpu2: offline (meaning present) This might be a little bit more than is intended for a sysfs file, especially if the information can be obtained some other way. Here's what I was thinking of: cat /sys/devices/system/cpu/cpuX/online doesn't exist: online, not offlinable 1: online 0: offline (meaning present) If you want to get information like you have above, it's pretty trivial to write a little script to do it. > the reason this cannot be determined at early time, is say if a set of cpu's are > in a special mode, i.e only those 4 cpu's can retrieve a set of platform registers. > for error processing. And i can offline each of those, until i run into the last > of those 4 cpus. Are you saying that you don't know if a CPU can be offlined at the time that the sysfs files are created? If so, I bet we could delay the creation of the kobjects until a more appropriate time. I don't think anything in early boot actually needs them. > I would prefer to not have a macro to preventy its creation, but have a > facility to know the offlineable status via a single information file, and > let __cpu_disable() determine if offline should fail based on current ability > to offline a cpu. > > what do you think? I just worry that any single information file doesn't fit in well with the sysfs model. -- Dave ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From greg at kroah.com Sat Jun 5 09:13:08 2004 From: greg at kroah.com (Greg KH) Date: Fri, 4 Jun 2004 16:13:08 -0700 Subject: [lhcs-devel] Re: [RFC] don't create cpu/online sysfs file In-Reply-To: <20040604154952.A15326@unix-os.sc.intel.com> References: <1086388321.24915.115.camel@nighthawk> <20040604154952.A15326@unix-os.sc.intel.com> Message-ID: <20040604231308.GB14330@kroah.com> On Fri, Jun 04, 2004 at 03:49:52PM -0700, Ashok Raj wrote: > place a file in /sys/devices/system/cpuinfo, which when one does a cat on > can display > > cpu0: online, not offlinable > cpu1: online > cpu2: offline (meaning present) No, put a status file in each cpu directory if you really want this. Remember, sysfs is 1 value per file, which this proposed file violates. thanks, greg k-h ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From ashok.raj at intel.com Sat Jun 5 09:17:50 2004 From: ashok.raj at intel.com (Ashok Raj) Date: Fri, 4 Jun 2004 16:17:50 -0700 Subject: [lhcs-devel] Re: [RFC] don't create cpu/online sysfs file In-Reply-To: <1086390257.24915.132.camel@nighthawk>; from haveblue@us.ibm.com on Fri, Jun 04, 2004 at 04:04:17PM -0700 References: <1086388321.24915.115.camel@nighthawk> <20040604154952.A15326@unix-os.sc.intel.com> <1086390257.24915.132.camel@nighthawk> Message-ID: <20040604161749.A15628@unix-os.sc.intel.com> On Fri, Jun 04, 2004 at 04:04:17PM -0700, Dave Hansen wrote: Dave, I think your solution can be easily solved if all you want to do is "your platform does not support cpuhotplug", which case just dont create for any cpu, or even better dont do anything in register_cpu() related to control file creation. Forcing all implementations to behave one way just to do what you want seems not right approach, and limiting all to least common denominator. The preferable way to this would be. - platfform_supports_cpuhotplug(), like in your case, dont create the online file for any. - __cpu_is_hotpluggable(cpu#) can also exist if this is a static decision to be made, say if the platform says that a certain cpu cannot be removed. But you should not always assume this is a static decision just because its the case in one platform. In my earlier example, if you have 8 cpu system, but cpu0-3 are special, and atleast 1 needs to exist for the system to work. I can remove any of of cpu0-3 until i have atleast one of the cpu0-3 left. The last one is not removable. Keep it simple please:-) Cheers, ashok > On Fri, 2004-06-04 at 15:49, Ashok Raj wrote: > > place a file in /sys/devices/system/cpuinfo, which when one does a cat on > > can display > > > > cpu0: online, not offlinable > > cpu1: online > > cpu2: offline (meaning present) > > This might be a little bit more than is intended for a sysfs file, > especially if the information can be obtained some other way. Here's > what I was thinking of: > > cat /sys/devices/system/cpu/cpuX/online > doesn't exist: online, not offlinable > 1: online > 0: offline (meaning present) > > If you want to get information like you have above, it's pretty trivial > to write a little script to do it. > > > the reason this cannot be determined at early time, is say if a set of cpu's are > > in a special mode, i.e only those 4 cpu's can retrieve a set of platform registers. > > for error processing. And i can offline each of those, until i run into the last > > of those 4 cpus. > > Are you saying that you don't know if a CPU can be offlined at the time > that the sysfs files are created? If so, I bet we could delay the > creation of the kobjects until a more appropriate time. I don't think > anything in early boot actually needs them. > > > I would prefer to not have a macro to preventy its creation, but have a > > facility to know the offlineable status via a single information file, and > > let __cpu_disable() determine if offline should fail based on current ability > > to offline a cpu. > > > > what do you think? > > I just worry that any single information file doesn't fit in well with > the sysfs model. > > -- Dave > ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From haveblue at us.ibm.com Sat Jun 5 09:41:05 2004 From: haveblue at us.ibm.com (Dave Hansen) Date: Fri, 04 Jun 2004 16:41:05 -0700 Subject: [lhcs-devel] Re: [RFC] don't create cpu/online sysfs file In-Reply-To: <20040604161749.A15628@unix-os.sc.intel.com> References: <1086388321.24915.115.camel@nighthawk> <20040604154952.A15326@unix-os.sc.intel.com> <1086390257.24915.132.camel@nighthawk> <20040604161749.A15628@unix-os.sc.intel.com> Message-ID: <1086392465.24915.151.camel@nighthawk> On Fri, 2004-06-04 at 16:17, Ashok Raj wrote: > I think your solution can be easily solved if all you want to do is > "your platform does not support cpuhotplug", which case just dont create > for any cpu, or even better dont do anything in register_cpu() related > to control file creation. Forcing all implementations to behave one way just to > do what you want seems not right approach, and limiting all to least common > denominator. That's originally what I did. A single global function to see if the platform supported cpu hotplug at runtime. The addition of passing the 'struct cpu' to it was so trivial that I figured it might be useful to someone down the line. I'm regretting my "foresight" now :) > The preferable way to this would be. > > - platfform_supports_cpuhotplug(), like in your case, dont create the > online file for any. > - __cpu_is_hotpluggable(cpu#) can also exist if this is a static decision to > be made, say if the platform says that a certain cpu cannot be removed. That seems to be a pretty sensible way to do it. However, we keep the number of interfaces from generic to arch code down if we keep the interface confined to 1 function. It would be trivial to make any architecture that needs it do this: int __cpu_is_hotpluggable(struct cpu *cpu) { if (!platfform_supports_cpuhotplug()) return 0; lots(); of_complex_arch_code(); here(); ... } That ensures that there's only 1 function that needs to be defined globally: __cpu_is_hotpluggable(). But, I definitely see the merit in what you want. > But you should not always assume this is a static decision just because its the > case in one platform. In my earlier example, if you have 8 cpu system, > but cpu0-3 are special, and atleast 1 needs to exist for the system to work. > > I can remove any of of cpu0-3 until i have atleast one of the cpu0-3 left. The > last one is not removable. > > Keep it simple please:-) That's what I'm trying to to :) I was thinking that cpuX/online is only there to say whether hotplug _operations_ are supported on the cpu, not if it can be hotplugged right now. The "can currently be hotplugged" question is another can of worms that can't really be answered until the hotplug request is made anyway, so I'd prefer to keep from trying to decide that by the presence of the file. The purpose of the patch is originally only to keep ppc64 systems from making firmware calls that they couldn't support. (Someone tried to offline a CPU on a system when it wasn't supported and the firmware got mad) -- Dave ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From ashok.raj at intel.com Sun Jun 6 00:38:02 2004 From: ashok.raj at intel.com (Ashok Raj) Date: Sat, 5 Jun 2004 07:38:02 -0700 Subject: [lhcs-devel] Re: [RFC] don't create cpu/online sysfs file In-Reply-To: <1086392465.24915.151.camel@nighthawk>; from haveblue@us.ibm.com on Fri, Jun 04, 2004 at 04:41:05PM -0700 References: <1086388321.24915.115.camel@nighthawk> <20040604154952.A15326@unix-os.sc.intel.com> <1086390257.24915.132.camel@nighthawk> <20040604161749.A15628@unix-os.sc.intel.com> <1086392465.24915.151.camel@nighthawk> Message-ID: <20040605073802.A22026@unix-os.sc.intel.com> On Fri, Jun 04, 2004 at 04:41:05PM -0700, Dave Hansen wrote: > > That's originally what I did. A single global function to see if the > platform supported cpu hotplug at runtime. The addition of passing the > 'struct cpu' to it was so trivial that I figured it might be useful to > someone down the line. I'm regretting my "foresight" now :) > > > The preferable way to this would be. > > > > - platfform_supports_cpuhotplug(), like in your case, dont create the > > online file for any. > > - __cpu_is_hotpluggable(cpu#) can also exist if this is a static decision to > > be made, say if the platform says that a certain cpu cannot be removed. > > That seems to be a pretty sensible way to do it. However, we keep the > number of interfaces from generic to arch code down if we keep the > interface confined to 1 function. It would be trivial to make any > architecture that needs it do this: > > int __cpu_is_hotpluggable(struct cpu *cpu) > { > if (!platfform_supports_cpuhotplug()) > return 0; > > lots(); > of_complex_arch_code(); > here(); > ... > } > > That ensures that there's only 1 function that needs to be defined > globally: __cpu_is_hotpluggable(). > I feel the __cpu_disable() should be just sufficient to be the only function interface from generic to arch code. You run this __cpu_is_hotpluggable(cpu) only in ppc64, where you check and return error. maybe also printing to console saying the platform doesnt support it. you are adding an extra arch function just for a trivial thing, not to create a control file. > > > > Keep it simple please:-) > > That's what I'm trying to to :) > > I was thinking that cpuX/online is only there to say whether hotplug > _operations_ are supported on the cpu, not if it can be hotplugged right > now. The "can currently be hotplugged" question is another can of worms > that can't really be answered until the hotplug request is made anyway, > so I'd prefer to keep from trying to decide that by the presence of the > file. My recommendation is to not do anything, and just let __cpu_disable() handle it. print some verbose message for the operator that this aint going to work should be more than sufficient. There is not a whole lot of realusefullness for this to work. we if overdo something here, then memory hotplug, node hotplug would all need to do the same hack, __is_node_hotpluggable(node), is_memsection_hotpluggabe(mem) and so on.... Cheers, ashok ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From haveblue at us.ibm.com Sun Jun 6 05:22:21 2004 From: haveblue at us.ibm.com (Dave Hansen) Date: Sat, 05 Jun 2004 12:22:21 -0700 Subject: [lhcs-devel] Re: [RFC] don't create cpu/online sysfs file In-Reply-To: <20040605073802.A22026@unix-os.sc.intel.com> References: <1086388321.24915.115.camel@nighthawk> <20040604154952.A15326@unix-os.sc.intel.com> <1086390257.24915.132.camel@nighthawk> <20040604161749.A15628@unix-os.sc.intel.com> <1086392465.24915.151.camel@nighthawk> <20040605073802.A22026@unix-os.sc.intel.com> Message-ID: <1086463340.30138.58.camel@nighthawk> On Sat, 2004-06-05 at 07:38, Ashok Raj wrote: > I feel the __cpu_disable() should be just sufficient to be the only > function interface from generic to arch code. You run this > __cpu_is_hotpluggable(cpu) only in ppc64, where you check and return error. > maybe also printing to console saying the platform doesnt support it. Actually __cpu_is_hotpluggable(cpu) does get called on ia64, it's just a trivially-defined 'return 1' for now. Are there ever any plans to run an kernel with CONFIG_HOTPLUG_CPU on an ia64 machine that doesn't really support cpu hotplug? If so, I'd be happy to include the same functionality on ia64 that I put for ppc64. BTW, the reason that this is done on ppc64 is that we can run the same kernel on a wide variety of hardware, so it makes the distributions' jobs a bit easier. > you are adding an extra arch function just for a trivial thing, not to create a > control file. ... > My recommendation is to not do anything, and just let __cpu_disable() handle it. > print some verbose message for the operator that this aint going to work should > be more than sufficient. There is not a whole lot of realusefullness for this > to work. The non-trivial thing that this patch tries to do is give the user some knowledge about the system from the pure layout of sysfs. Waiting until __cpu_disable() to tell the user that there was no possibility of the cpu being offlined seems a bit late in the process. Your idea about the cpuinfo file in sysfs is definitely right; it has *exactly* the information that I'm trying to present. But, the current sysfs guidelines tend to discourage single files with lots of information like those in /proc. -- Dave ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From ashok.raj at intel.com Mon Jun 7 06:27:23 2004 From: ashok.raj at intel.com (Ashok Raj) Date: Sun, 6 Jun 2004 13:27:23 -0700 Subject: [lhcs-devel] Re: [RFC] don't create cpu/online sysfs file In-Reply-To: <1086463340.30138.58.camel@nighthawk>; from haveblue@us.ibm.com on Sat, Jun 05, 2004 at 12:22:21PM -0700 References: <1086388321.24915.115.camel@nighthawk> <20040604154952.A15326@unix-os.sc.intel.com> <1086390257.24915.132.camel@nighthawk> <20040604161749.A15628@unix-os.sc.intel.com> <1086392465.24915.151.camel@nighthawk> <20040605073802.A22026@unix-os.sc.intel.com> <1086463340.30138.58.camel@nighthawk> Message-ID: <20040606132723.A10563@unix-os.sc.intel.com> On Sat, Jun 05, 2004 at 12:22:21PM -0700, Dave Hansen wrote: > knowledge about the system from the pure layout of sysfs. Waiting until > __cpu_disable() to tell the user that there was no possibility of the > cpu being offlined seems a bit late in the process. Your idea about the > cpuinfo file in sysfs is definitely right; it has *exactly* the > information that I'm trying to present. But, the current sysfs > guidelines tend to discourage single files with lots of information like > those in /proc. How does the attached patch look? I would try to keep away from proliferation of common->arch->platform code as little as possible. What i have done is send a hint for suppressing the control file creation based on what was set in the struct cpu, before calling register_cpu() by the arch specific topology_init() functions. No new __arch/__platform functions. here is the untested patch for PPC64, does this seem to do what you need? Cheers, ashok -------------- next part -------------- D: This file provides ability for caller of register_cpu() to either create D: a control file, or not. This can be handy if a particular platform decides D: that certain CPU's are not removable. Hence would like to not create D: a control file. --- linux-2.6.7-rc2-root/arch/ppc64/kernel/sysfs.c | 10 ++++++++++ linux-2.6.7-rc2-root/drivers/base/cpu.c | 2 +- linux-2.6.7-rc2-root/include/linux/cpu.h | 1 + 3 files changed, 12 insertions(+), 1 deletion(-) diff -puN include/linux/cpu.h~cpu_control_file include/linux/cpu.h --- linux-2.6.7-rc2/include/linux/cpu.h~cpu_control_file 2004-06-06 12:54:02.319017387 -0700 +++ linux-2.6.7-rc2-root/include/linux/cpu.h 2004-06-06 12:56:01.663805054 -0700 @@ -27,6 +27,7 @@ struct cpu { int node_id; /* The node which contains the CPU */ + int not_removable; /* This cpu is not removable */ struct sys_device sysdev; }; diff -puN drivers/base/cpu.c~cpu_control_file drivers/base/cpu.c --- linux-2.6.7-rc2/drivers/base/cpu.c~cpu_control_file 2004-06-06 12:56:47.349375320 -0700 +++ linux-2.6.7-rc2-root/drivers/base/cpu.c 2004-06-06 12:58:12.390434486 -0700 @@ -75,7 +75,7 @@ int __init register_cpu(struct cpu *cpu, error = sysfs_create_link(&root->sysdev.kobj, &cpu->sysdev.kobj, kobject_name(&cpu->sysdev.kobj)); - if (!error) + if (!error && !cpu->not_removable) register_cpu_control(cpu); return error; } diff -puN arch/ppc64/kernel/sysfs.c~cpu_control_file arch/ppc64/kernel/sysfs.c --- linux-2.6.7-rc2/arch/ppc64/kernel/sysfs.c~cpu_control_file 2004-06-06 13:12:06.467033408 -0700 +++ linux-2.6.7-rc2-root/arch/ppc64/kernel/sysfs.c 2004-06-06 13:12:43.805919713 -0700 @@ -325,6 +325,16 @@ static int __init topology_init(void) #ifdef CONFIG_NUMA parent = &node_devices[cpu_to_node(cpu)]; #endif + /* + * For now, we just see if the system supports making + * the RTAS calls for CPU hotplug. But, there may be a + * more comprehensive way to do this for an individual + * CPU. For instance, the boot cpu might never be valid + * for hotplugging. + */ + if (systemcfg->platform == PLATFORM_PSERIES_LPAR) + cpu->not_removable=1; + register_cpu(c, cpu, parent); register_cpu_pmc(&c->sysdev); _ From rusty at rustcorp.com.au Mon Jun 7 09:08:18 2004 From: rusty at rustcorp.com.au (Rusty Russell) Date: Mon, 07 Jun 2004 09:08:18 +1000 Subject: [RFC] don't create cpu/online sysfs file In-Reply-To: <1086388321.24915.115.camel@nighthawk> References: <1086385058.24915.86.camel@nighthawk> <40C0F256.8090809@austin.ibm.com> <1086388321.24915.115.camel@nighthawk> Message-ID: <1086560462.18637.17.camel@bach> On Sat, 2004-06-05 at 08:32, Dave Hansen wrote: > On Fri, 2004-06-04 at 15:06, Joel Schopp wrote: > > I might change cpu_is_hotpluggable to __cpu_is_hotpluggable to help > > indicate it is a platform specific function. > > Yeah, that naming is a lot more consistent with the other functions in > the arch-specific cpu hotplug code. New version attached. The purpose of __ is to indicate a low-level function which requires special knowledge to call (usually a lock). The cpu hotplug code is a little odd, but way back when, it had cpu_disable() and cpu_die(), so the arch-specific parts which actually did the work were called __cpu_disable() and __cpu_die(). The names stuck. There's nothing special required to call cpu_is_hotpluggable(), so it's wrong to prepend __. Sorry for the inconsistency, Rusty. -- Anyone who quotes me in their signature is an idiot -- Rusty Russell ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From haveblue at us.ibm.com Mon Jun 7 15:05:35 2004 From: haveblue at us.ibm.com (Dave Hansen) Date: Sun, 06 Jun 2004 22:05:35 -0700 Subject: [lhcs-devel] Re: [RFC] don't create cpu/online sysfs file In-Reply-To: <20040606132723.A10563@unix-os.sc.intel.com> References: <1086388321.24915.115.camel@nighthawk> <20040604154952.A15326@unix-os.sc.intel.com> <1086390257.24915.132.camel@nighthawk> <20040604161749.A15628@unix-os.sc.intel.com> <1086392465.24915.151.camel@nighthawk> <20040605073802.A22026@unix-os.sc.intel.com> <1086463340.30138.58.camel@nighthawk> <20040606132723.A10563@unix-os.sc.intel.com> Message-ID: <1086584735.30138.130.camel@nighthawk> On Sun, 2004-06-06 at 13:27, Ashok Raj wrote: > On Sat, Jun 05, 2004 at 12:22:21PM -0700, Dave Hansen wrote: > > knowledge about the system from the pure layout of sysfs. Waiting until > > __cpu_disable() to tell the user that there was no possibility of the > > cpu being offlined seems a bit late in the process. Your idea about the > > cpuinfo file in sysfs is definitely right; it has *exactly* the > > information that I'm trying to present. But, the current sysfs > > guidelines tend to discourage single files with lots of information like > > those in /proc. > > How does the attached patch look? I would try to keep away from proliferation of > common->arch->platform code as little as possible. What i have done is > send a hint for suppressing the control file creation based on what was > set in the struct cpu, before calling register_cpu() by the arch specific > topology_init() functions. No new __arch/__platform functions. > > here is the untested patch for PPC64, does this seem to do what you need? I like that patch a lot. It certainly removes any argument about function names :) Can we maybe change the name of the new field a bit? -- Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: cpuhotplug-online-2.6.7-rc2-mm2-5.patch Type: text/x-patch Size: 1868 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20040606/e7c27986/attachment.bin From sfr at canb.auug.org.au Mon Jun 7 16:43:12 2004 From: sfr at canb.auug.org.au (Stephen Rothwell) Date: Mon, 7 Jun 2004 16:43:12 +1000 Subject: [PATCH] PPC64 iSeries virtual ethernet proc files Message-ID: <20040607164312.258a9f99.sfr@canb.auug.org.au> Hi Andrew, From: David Gibson This patch just adds back some of the iserires_veth proc files to provide information to user space (particularly Kudzu) to allow the virtual ethernets to be discovered. These files existed in a 2.4 version of this driver that was shipped by some distros. Signed-off-by: Stephen Rothwell -- Cheers, Stephen Rothwell sfr at canb.auug.org.au http://www.canb.auug.org.au/~sfr/ -------------- next part -------------- diff -ruN 2.6.7-rc2-bk7/drivers/net/iseries_veth.c 2.6.7-rc2-bk7.veth.proc.1/drivers/net/iseries_veth.c --- 2.6.7-rc2-bk7/drivers/net/iseries_veth.c 2004-06-07 13:35:47.000000000 +1000 +++ 2.6.7-rc2-bk7.veth.proc.1/drivers/net/iseries_veth.c 2004-06-07 15:28:40.000000000 +1000 @@ -165,6 +165,7 @@ static HvLpIndex this_lp; static struct veth_lpar_connection *veth_cnx[HVMAXARCHITECTEDLPS]; /* = 0 */ static struct net_device *veth_dev[HVMAXARCHITECTEDVIRTUALLANS]; /* = 0 */ +struct proc_dir_entry *veth_proc_root; /* = NULL */ static int veth_start_xmit(struct sk_buff *skb, struct net_device *dev); static void veth_recycle_msg(struct veth_lpar_connection *, struct veth_msg *); @@ -1328,6 +1329,91 @@ } /* + * procfs code (used by userspace for discovery) + */ +static int proc_veth_dump_port(char *page, char **start, off_t off, int count, + int *eof, void *data) +{ + char *out = page; + struct net_device *dev = data; + struct veth_port *port = dev->priv; + long len; + int i; + + BUG_ON(port == NULL); + + out += sprintf(out, "Net device name:\t%s\n", dev->name); + out += sprintf(out, "Address:\t%012lX\n", port->mac_addr >> 16); + + read_lock_irq(&port->mcast_gate); + out += sprintf(out, "Promiscuous:\t%d\n", port->promiscuous); + out += sprintf(out, "All multicast:\t%d\n", port->all_mcast); + out += sprintf(out, "Number multicast:\t%d\n", port->num_mcast); + + for (i = 0; i < port->num_mcast; ++i) + out += sprintf(out, " %012lX\n", port->mcast_addr[i] >> 16); + read_unlock_irq(&port->mcast_gate); + + len = (out - page) - off; + if (len < count) + *eof = 1; + else + len = count; + + if (len <= 0) + len = 0; + else + *start = page + off; + return len; +} + +static void veth_proc_init(void) +{ + int i; + + veth_proc_root = proc_mkdir("iSeries/veth", NULL); + if (veth_proc_root == NULL) + return; + + for (i = 0; i < HVMAXARCHITECTEDVIRTUALLANS; i++) { + struct proc_dir_entry *ent; + char name[10]; + + if (veth_dev[i] == NULL) + continue; + + sprintf(name, "veth%d", i); + ent = create_proc_entry(name, S_IFREG | S_IRUSR, + veth_proc_root); + if (ent == NULL) + return; + + ent->nlink = 1; + ent->owner = THIS_MODULE; + ent->data = veth_dev[i]; + ent->read_proc = proc_veth_dump_port; + ent->write_proc = NULL; + } +} + +static void veth_proc_delete(void) +{ + int i; + + for (i = 0; i < HVMAXARCHITECTEDVIRTUALLANS; i++) { + char name[10]; + + if (veth_dev[i] == NULL) + continue; + + sprintf(name, "veth%d", i); + remove_proc_entry(name, veth_proc_root); + } + + remove_proc_entry("iSeries/veth", NULL); +} + +/* * Module initialization/cleanup */ @@ -1335,6 +1421,8 @@ { int i; + veth_proc_delete(); + for (i = 0; i < HVMAXARCHITECTEDLPS; ++i) veth_destroy_connection(i); @@ -1394,6 +1482,8 @@ if (veth_cnx[i]) veth_kick_statemachine(veth_cnx[i]); + veth_proc_init(); + return 0; } module_init(veth_module_init); From jgarzik at pobox.com Mon Jun 7 23:21:00 2004 From: jgarzik at pobox.com (Jeff Garzik) Date: Mon, 07 Jun 2004 09:21:00 -0400 Subject: [PATCH] PPC64 iSeries virtual ethernet proc files In-Reply-To: <20040607164312.258a9f99.sfr@canb.auug.org.au> References: <20040607164312.258a9f99.sfr@canb.auug.org.au> Message-ID: <40C46BBC.7000001@pobox.com> Stephen Rothwell wrote: > Hi Andrew, > > From: David Gibson > > This patch just adds back some of the iserires_veth proc files to provide > information to user space (particularly Kudzu) to allow the virtual > ethernets to be discovered. These files existed in a 2.4 version of this > driver that was shipped by some distros. kudzu can find this stuff with ethtool, without adding this code. This code isn't needed in 2.6.x. Jeff ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From nathanl at austin.ibm.com Tue Jun 8 00:07:38 2004 From: nathanl at austin.ibm.com (Nathan Lynch) Date: Mon, 07 Jun 2004 09:07:38 -0500 Subject: [lhcs-devel] Re: [RFC] don't create cpu/online sysfs file In-Reply-To: <1086584735.30138.130.camel@nighthawk> References: <1086388321.24915.115.camel@nighthawk> <20040604154952.A15326@unix-os.sc.intel.com> <1086390257.24915.132.camel@nighthawk> <20040604161749.A15628@unix-os.sc.intel.com> <1086392465.24915.151.camel@nighthawk> <20040605073802.A22026@unix-os.sc.intel.com> <1086463340.30138.58.camel@nighthawk> <20040606132723.A10563@unix-os.sc.intel.com> <1086584735.30138.130.camel@nighthawk> Message-ID: <40C476AA.7070403@austin.ibm.com> Dave Hansen wrote: > diff -urp linux-2.6.7-rc2-mm2-clean/drivers/base/cpu.c linux-2.6.7-rc2-mm2-cpuonline2/drivers/base/cpu.c > --- linux-2.6.7-rc2-mm2-clean/drivers/base/cpu.c Fri Jun 4 13:27:09 2004 > +++ linux-2.6.7-rc2-mm2-cpuonline2/drivers/base/cpu.c Sun Jun 6 21:59:35 2004 > @@ -75,7 +75,7 @@ int __init register_cpu(struct cpu *cpu, > error = sysfs_create_link(&root->sysdev.kobj, > &cpu->sysdev.kobj, > kobject_name(&cpu->sysdev.kobj)); > - if (!error) > + if (!error && !cpu->can_control) Should be: + if (!error && cpu->can_control) Right? > diff -urp linux-2.6.7-rc2-mm2-clean/include/linux/cpu.h linux-2.6.7-rc2-mm2-cpuonline2/include/linux/cpu.h > --- linux-2.6.7-rc2-mm2-clean/include/linux/cpu.h Fri Jun 4 13:27:11 2004 > +++ linux-2.6.7-rc2-mm2-cpuonline2/include/linux/cpu.h Sun Jun 6 21:58:35 2004 > @@ -27,6 +27,7 @@ > > struct cpu { > int node_id; /* The node which contains the CPU */ > + int can_control; /* Should the sysfs control file be created? */ Minor nit -- could we change this comment to "Could this cpu ever be hotpluggable?" Or just name the field "hotpluggable"? That would better document the intent here, wouldn't it? Nathan ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From ashok.raj at intel.com Tue Jun 8 00:08:52 2004 From: ashok.raj at intel.com (Ashok Raj) Date: Mon, 7 Jun 2004 07:08:52 -0700 Subject: [lhcs-devel] Re: [RFC] don't create cpu/online sysfs file In-Reply-To: <1086584735.30138.130.camel@nighthawk>; from haveblue@us.ibm.com on Sun, Jun 06, 2004 at 10:05:35PM -0700 References: <1086388321.24915.115.camel@nighthawk> <20040604154952.A15326@unix-os.sc.intel.com> <1086390257.24915.132.camel@nighthawk> <20040604161749.A15628@unix-os.sc.intel.com> <1086392465.24915.151.camel@nighthawk> <20040605073802.A22026@unix-os.sc.intel.com> <1086463340.30138.58.camel@nighthawk> <20040606132723.A10563@unix-os.sc.intel.com> <1086584735.30138.130.camel@nighthawk> Message-ID: <20040607070852.A17932@unix-os.sc.intel.com> On Sun, Jun 06, 2004 at 10:05:35PM -0700, Dave Hansen wrote: > I like that patch a lot. It certainly removes any argument about > function names :) > > Can we maybe change the name of the new field a bit? I strategically (?) changed the name to not_removable, so the field name can indicate the purpose as well clearly. Oh well, i changed the field name to no_control, to indicate "not to create" a control file. the "can_remove" when i read it in isolation, seems to indicate "this cpu is removable" and for correcness i think we would change the normal case to set as 1 instead. picky picky picky :-) i added a note in the function doc as well for clarity. Signed-off-by: Ashok Raj D: This file provides ability for caller of register_cpu() to either create D: a control file, or not. This can be handy if a particular platform decides D: that certain CPU's are not removable. Hence would like to not create D: a control file. --- linux-2.6.7-rc2-root/arch/ppc64/kernel/sysfs.c | 10 ++++++++++ linux-2.6.7-rc2-root/drivers/base/cpu.c | 4 +++- linux-2.6.7-rc2-root/include/linux/cpu.h | 1 + 3 files changed, 14 insertions(+), 1 deletion(-) diff -puN include/linux/cpu.h~cpu_control_file include/linux/cpu.h --- linux-2.6.7-rc2/include/linux/cpu.h~cpu_control_file 2004-06-06 12:54:02.319017387 -0700 +++ linux-2.6.7-rc2-root/include/linux/cpu.h 2004-06-07 06:25:44.667732023 -0700 @@ -27,6 +27,7 @@ struct cpu { int node_id; /* The node which contains the CPU */ + int no_control; /* Should the sysfs control file be created? */ struct sys_device sysdev; }; diff -puN drivers/base/cpu.c~cpu_control_file drivers/base/cpu.c --- linux-2.6.7-rc2/drivers/base/cpu.c~cpu_control_file 2004-06-06 12:56:47.349375320 -0700 +++ linux-2.6.7-rc2-root/drivers/base/cpu.c 2004-06-07 07:03:12.624937664 -0700 @@ -58,6 +58,8 @@ static inline void register_cpu_control( /* * register_cpu - Setup a driverfs device for a CPU. + * @cpu - Callers can set the cpu->no_control field to 1, to indicate not to + * generate a control file in sysfs for this CPU. * @num - CPU number to use when creating the device. * * Initialize and register the CPU device. @@ -75,7 +77,7 @@ int __init register_cpu(struct cpu *cpu, error = sysfs_create_link(&root->sysdev.kobj, &cpu->sysdev.kobj, kobject_name(&cpu->sysdev.kobj)); - if (!error) + if (!error && !cpu->no_control) register_cpu_control(cpu); return error; } diff -puN arch/ppc64/kernel/sysfs.c~cpu_control_file arch/ppc64/kernel/sysfs.c --- linux-2.6.7-rc2/arch/ppc64/kernel/sysfs.c~cpu_control_file 2004-06-06 13:12:06.467033408 -0700 +++ linux-2.6.7-rc2-root/arch/ppc64/kernel/sysfs.c 2004-06-07 06:29:35.126834393 -0700 @@ -325,6 +325,16 @@ static int __init topology_init(void) #ifdef CONFIG_NUMA parent = &node_devices[cpu_to_node(cpu)]; #endif + /* + * For now, we just see if the system supports making + * the RTAS calls for CPU hotplug. But, there may be a + * more comprehensive way to do this for an individual + * CPU. For instance, the boot cpu might never be valid + * for hotplugging. + */ + if (systemcfg->platform == PLATFORM_PSERIES_LPAR) + cpu->no_control=1; + register_cpu(c, cpu, parent); register_cpu_pmc(&c->sysdev); _ ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From ashok.raj at intel.com Tue Jun 8 00:14:22 2004 From: ashok.raj at intel.com (Ashok Raj) Date: Mon, 7 Jun 2004 07:14:22 -0700 Subject: [lhcs-devel] Re: [RFC] don't create cpu/online sysfs file In-Reply-To: <40C476AA.7070403@austin.ibm.com>; from nathanl@austin.ibm.com on Mon, Jun 07, 2004 at 09:07:38AM -0500 References: <1086388321.24915.115.camel@nighthawk> <20040604154952.A15326@unix-os.sc.intel.com> <1086390257.24915.132.camel@nighthawk> <20040604161749.A15628@unix-os.sc.intel.com> <1086392465.24915.151.camel@nighthawk> <20040605073802.A22026@unix-os.sc.intel.com> <1086463340.30138.58.camel@nighthawk> <20040606132723.A10563@unix-os.sc.intel.com> <1086584735.30138.130.camel@nighthawk> <40C476AA.7070403@austin.ibm.com> Message-ID: <20040607071422.B17971@unix-os.sc.intel.com> On Mon, Jun 07, 2004 at 09:07:38AM -0500, Nathan Lynch wrote: > Dave Hansen wrote: > > - if (!error) > > + if (!error && !cpu->can_control) > > Should be: > + if (!error && cpu->can_control) > Glad someone else also read it the same way as i did the name is now fixed in the new patch posted.... you caught me just few mins before. Cheers, ashok ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From haveblue at us.ibm.com Tue Jun 8 02:41:49 2004 From: haveblue at us.ibm.com (Dave Hansen) Date: Mon, 07 Jun 2004 09:41:49 -0700 Subject: [lhcs-devel] Re: [RFC] don't create cpu/online sysfs file In-Reply-To: <20040607070852.A17932@unix-os.sc.intel.com> References: <1086388321.24915.115.camel@nighthawk> <20040604154952.A15326@unix-os.sc.intel.com> <1086390257.24915.132.camel@nighthawk> <20040604161749.A15628@unix-os.sc.intel.com> <1086392465.24915.151.camel@nighthawk> <20040605073802.A22026@unix-os.sc.intel.com> <1086463340.30138.58.camel@nighthawk> <20040606132723.A10563@unix-os.sc.intel.com> <1086584735.30138.130.camel@nighthawk> <20040607070852.A17932@unix-os.sc.intel.com> Message-ID: <1086626508.28074.1.camel@nighthawk> On Mon, 2004-06-07 at 07:08, Ashok Raj wrote:plugging. > + if (systemcfg->platform == PLATFORM_PSERIES_LPAR) > + cpu->no_control=1; That condition is also inverted. Should read: if (systemcfg->platform != PLATFORM_PSERIES_LPAR) cpu->no_control = 1; -- Dave ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From ashok.raj at intel.com Tue Jun 8 03:22:26 2004 From: ashok.raj at intel.com (Ashok Raj) Date: Mon, 7 Jun 2004 10:22:26 -0700 Subject: [lhcs-devel] Re: [RFC] don't create cpu/online sysfs file In-Reply-To: <1086626508.28074.1.camel@nighthawk>; from haveblue@us.ibm.com on Mon, Jun 07, 2004 at 09:41:49AM -0700 References: <20040604154952.A15326@unix-os.sc.intel.com> <1086390257.24915.132.camel@nighthawk> <20040604161749.A15628@unix-os.sc.intel.com> <1086392465.24915.151.camel@nighthawk> <20040605073802.A22026@unix-os.sc.intel.com> <1086463340.30138.58.camel@nighthawk> <20040606132723.A10563@unix-os.sc.intel.com> <1086584735.30138.130.camel@nighthawk> <20040607070852.A17932@unix-os.sc.intel.com> <1086626508.28074.1.camel@nighthawk> Message-ID: <20040607102226.A19556@unix-os.sc.intel.com> On Mon, Jun 07, 2004 at 09:41:49AM -0700, Dave Hansen wrote: > On Mon, 2004-06-07 at 07:08, Ashok Raj wrote:plugging. > > + if (systemcfg->platform == PLATFORM_PSERIES_LPAR) > > + cpu->no_control=1; > > That condition is also inverted. Should read: > > if (systemcfg->platform != PLATFORM_PSERIES_LPAR) > cpu->no_control = 1; Good catch...I knew i mentioned untested :-) fixed patch attached... Cheers, ashok -------------- next part -------------- Signed-off-by: Ashok Raj D: This file provides ability for caller of register_cpu() to either create D: a control file, or not. This can be handy if a particular platform decides D: that certain CPU's are not removable. Hence would like to not create D: a control file. --- linux-2.6.7-rc2-root/arch/ppc64/kernel/sysfs.c | 10 ++++++++++ linux-2.6.7-rc2-root/drivers/base/cpu.c | 4 +++- linux-2.6.7-rc2-root/include/linux/cpu.h | 1 + 3 files changed, 14 insertions(+), 1 deletion(-) diff -puN include/linux/cpu.h~cpu_control_file include/linux/cpu.h --- linux-2.6.7-rc2/include/linux/cpu.h~cpu_control_file 2004-06-06 12:54:02.319017387 -0700 +++ linux-2.6.7-rc2-root/include/linux/cpu.h 2004-06-07 06:25:44.667732023 -0700 @@ -27,6 +27,7 @@ struct cpu { int node_id; /* The node which contains the CPU */ + int no_control; /* Should the sysfs control file be created? */ struct sys_device sysdev; }; diff -puN drivers/base/cpu.c~cpu_control_file drivers/base/cpu.c --- linux-2.6.7-rc2/drivers/base/cpu.c~cpu_control_file 2004-06-06 12:56:47.349375320 -0700 +++ linux-2.6.7-rc2-root/drivers/base/cpu.c 2004-06-07 07:03:12.624937664 -0700 @@ -58,6 +58,8 @@ static inline void register_cpu_control( /* * register_cpu - Setup a driverfs device for a CPU. + * @cpu - Callers can set the cpu->no_control field to 1, to indicate not to + * generate a control file in sysfs for this CPU. * @num - CPU number to use when creating the device. * * Initialize and register the CPU device. @@ -75,7 +77,7 @@ int __init register_cpu(struct cpu *cpu, error = sysfs_create_link(&root->sysdev.kobj, &cpu->sysdev.kobj, kobject_name(&cpu->sysdev.kobj)); - if (!error) + if (!error && !cpu->no_control) register_cpu_control(cpu); return error; } diff -puN arch/ppc64/kernel/sysfs.c~cpu_control_file arch/ppc64/kernel/sysfs.c --- linux-2.6.7-rc2/arch/ppc64/kernel/sysfs.c~cpu_control_file 2004-06-06 13:12:06.467033408 -0700 +++ linux-2.6.7-rc2-root/arch/ppc64/kernel/sysfs.c 2004-06-07 10:12:45.999901454 -0700 @@ -325,6 +325,16 @@ static int __init topology_init(void) #ifdef CONFIG_NUMA parent = &node_devices[cpu_to_node(cpu)]; #endif + /* + * For now, we just see if the system supports making + * the RTAS calls for CPU hotplug. But, there may be a + * more comprehensive way to do this for an individual + * CPU. For instance, the boot cpu might never be valid + * for hotplugging. + */ + if (systemcfg->platform != PLATFORM_PSERIES_LPAR) + cpu->no_control=1; + register_cpu(c, cpu, parent); register_cpu_pmc(&c->sysdev); _ From haveblue at us.ibm.com Tue Jun 8 05:25:57 2004 From: haveblue at us.ibm.com (Dave Hansen) Date: Mon, 07 Jun 2004 12:25:57 -0700 Subject: [lhcs-devel] Re: [RFC] don't create cpu/online sysfs file In-Reply-To: <20040607102226.A19556@unix-os.sc.intel.com> References: <20040604154952.A15326@unix-os.sc.intel.com> <1086390257.24915.132.camel@nighthawk> <20040604161749.A15628@unix-os.sc.intel.com> <1086392465.24915.151.camel@nighthawk> <20040605073802.A22026@unix-os.sc.intel.com> <1086463340.30138.58.camel@nighthawk> <20040606132723.A10563@unix-os.sc.intel.com> <1086584735.30138.130.camel@nighthawk> <20040607070852.A17932@unix-os.sc.intel.com> <1086626508.28074.1.camel@nighthawk> <20040607102226.A19556@unix-os.sc.intel.com> Message-ID: <1086636357.16083.1.camel@nighthawk> On Mon, 2004-06-07 at 10:22, Ashok Raj wrote: > On Mon, Jun 07, 2004 at 09:41:49AM -0700, Dave Hansen wrote: > > On Mon, 2004-06-07 at 07:08, Ashok Raj wrote:plugging. > > > + if (systemcfg->platform == PLATFORM_PSERIES_LPAR) > > > + cpu->no_control=1; > > > > That condition is also inverted. Should read: > > > > if (systemcfg->platform != PLATFORM_PSERIES_LPAR) > > cpu->no_control = 1; > > Good catch...I knew i mentioned untested :-) > > fixed patch attached... The smallest of nitpicks: cpu->no_control=1; needs to be cpu->no_control = 1; Would you like to submit this now? -- Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: p00002_cpu_control_file.patch Type: text/x-patch Size: 2644 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20040607/2ab96372/attachment.bin From nathanl at austin.ibm.com Tue Jun 8 06:38:04 2004 From: nathanl at austin.ibm.com (Nathan Lynch) Date: Mon, 07 Jun 2004 15:38:04 -0500 Subject: [PATCH] shared processor hcalls use wrong cpu id? Message-ID: <40C4D22C.4090902@austin.ibm.com> Hi- During cpu hotplug stress runs on shared processor configurations, we're seeing what looks like kernel stack corruption and sometimes deadlocks. The platform documentation is not terribly explicit about this, but the shared processor-related hcalls which take a processor number parameter (H_REGISTER_VPA, H_CONFER, H_PROD) expect that number to be the "hardware" id -- that is, the number taken from the ibm,ppc-interrupt-server#s property of the cpu's OF device node. Right now, we're passing the Linux "logical" cpu id to these calls. We're still running tests to determine whether this fixes some of the issues we're seeing; but I thought this was important enough to get out for review and to make sure I'm on the right track. The patch is pretty rough (e.g. I don't think we want to panic if H_CONFER fails for some reason). Also note that I changed the H_CONFER call in the lock code to pass -1 (all cpus) since it's not very clear to me how the lock holder is recorded in the spinlock. Nathan -------------- next part -------------- A non-text attachment was scrubbed... Name: vpa_fix_cpu_id.patch Type: text/x-patch Size: 2588 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20040607/0ad6bf65/attachment.bin From ashok.raj at intel.com Tue Jun 8 06:48:41 2004 From: ashok.raj at intel.com (Ashok Raj) Date: Mon, 7 Jun 2004 13:48:41 -0700 Subject: [lhcs-devel] Re: [RFC] don't create cpu/online sysfs file In-Reply-To: <1086636357.16083.1.camel@nighthawk>; from haveblue@us.ibm.com on Mon, Jun 07, 2004 at 12:25:57PM -0700 References: <20040604161749.A15628@unix-os.sc.intel.com> <1086392465.24915.151.camel@nighthawk> <20040605073802.A22026@unix-os.sc.intel.com> <1086463340.30138.58.camel@nighthawk> <20040606132723.A10563@unix-os.sc.intel.com> <1086584735.30138.130.camel@nighthawk> <20040607070852.A17932@unix-os.sc.intel.com> <1086626508.28074.1.camel@nighthawk> <20040607102226.A19556@unix-os.sc.intel.com> <1086636357.16083.1.camel@nighthawk> Message-ID: <20040607134840.A21245@unix-os.sc.intel.com> On Mon, Jun 07, 2004 at 12:25:57PM -0700, Dave Hansen wrote: > > cpu->no_control = 1; > > Would you like to submit this now? > Sounds good. Cheers, ashok ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From jschopp at austin.ibm.com Tue Jun 8 07:17:23 2004 From: jschopp at austin.ibm.com (Joel Schopp) Date: Mon, 07 Jun 2004 16:17:23 -0500 Subject: [PATCH] shared processor hcalls use wrong cpu id? In-Reply-To: <40C4D22C.4090902@austin.ibm.com> References: <40C4D22C.4090902@austin.ibm.com> Message-ID: <40C4DB63.4020405@austin.ibm.com> This is a great catch. > The platform documentation is not terribly explicit about this, but > the shared processor-related hcalls which take a processor number > parameter (H_REGISTER_VPA, H_CONFER, H_PROD) expect that number to be > the "hardware" id -- that is, the number taken from the > ibm,ppc-interrupt-server#s property of the cpu's OF device node. Right > now, we're passing the Linux "logical" cpu id to these calls. Logical and physical used to be the same for awhile. I guess Dave E. and I missed this when converting to logically numbering starting at 0. > > We're still running tests to determine whether this fixes some of the > issues we're seeing; but I thought this was important enough to get out > for review and to make sure I'm on the right track. The patch is pretty > rough (e.g. I don't think we want to panic if H_CONFER fails for some > reason). I think if H_CONFER fails we can just go on with our lives. It is a performance thing, not a correctness thing. > Also note that I changed the H_CONFER call in the lock code to pass -1 > (all cpus) since it's not very clear to me how the lock holder is > recorded in the spinlock. This will have to be fixed as well. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From greg at kroah.com Tue Jun 8 08:21:54 2004 From: greg at kroah.com (Greg KH) Date: Mon, 7 Jun 2004 15:21:54 -0700 Subject: [Pcihpd-discuss] Re: [PATCH] rpaphp.patch -- multi-function devices not handled correctly In-Reply-To: <40C4EE87.3000802@us.ibm.com> References: <40AC1099.9060007@us.ibm.com> <20040520211613.GA27095@kroah.com> <40AEBB98.5080903@us.ibm.com> <40C4EE87.3000802@us.ibm.com> Message-ID: <20040607222154.GA8232@kroah.com> On Mon, Jun 07, 2004 at 05:39:03PM -0500, Linda Xie wrote: > +#ifdef DEBUG > +static void print_slot_pci_funcs(struct slot *slot) > +{ > + struct list_head *l; > + > + if (slot->dev_type == PCI_DEV) { > + printk("pci_funcs of slot[%s]\n", slot->name); > + if (list_empty(&slot->dev.pci_funcs)) > + printk(" pci_funcs is EMPTY\n"); > + > + list_for_each (l, &slot->dev.pci_funcs) { > + struct rpaphp_pci_func *func = > + list_entry(l, struct rpaphp_pci_func, sibling); > + printk(" FOUND dev=%s\n", pci_name(func->pci_dev)); > + } > + } > +} > +#endif Please provide an empty version of this function if DEBUG is not defined. That way you get rid of the #ifdef in the places where you call this function. > +static ssize_t removable_read_file (struct hotplug_slot *php_slot, char *buf) > +{ > + u8 value; > + int retval = -ENOENT; > + struct slot *slot = (struct slot *)php_slot->private; > + > + if (!slot) > + return retval; > + > + value = slot->removable; > + retval = sprintf (buf, "%d\n", value); > + return retval; > +} Hm, you used spaces here instead of tabs :( > +static struct hotplug_slot_attribute hotplug_slot_attr_removable = { > + .attr = {.name = "phy_removable", .mode = S_IFREG | S_IRUGO}, > + .show = removable_read_file, > +}; Please use the proper macros for this. You didn't set the owner field due to this :( > + > +static void rpaphp_sysfs_add_attr_removable (struct hotplug_slot *slot) > +{ > + sysfs_create_file(&slot->kobj, &hotplug_slot_attr_removable.attr); > +} > + > +void rpaphp_sysfs_remove_attr_removable (struct hotplug_slot *slot) > +{ > + sysfs_remove_file(&slot->kobj, &hotplug_slot_attr_removable.attr); > +} Why is the add files function static, yet the remove one global? That's implying that your create is done at a different "level" than the remove, which it looks like it is. Should this be also fixed up? > +static int is_registered(struct slot *slot) > +{ > + struct list_head *tmp, *n; > + struct slot *tmp_slot; > + > + list_for_each_safe(tmp, n, &rpaphp_slot_head) { > + tmp_slot = list_entry(tmp, struct slot, rpaphp_slot_list); > + if (!strcmp(tmp_slot->name, slot->name)) > + return 1; > + } > + return 0; > +} list_for_each_safe() is not needed here. How about a simple list_for_each_entry() instead? Also, the pci hotplug core will catch this error, right? Why duplicate the logic again? > + /* should not try to register the same slot twice */ > + if (is_registered(slot)) { /* should't be here */ > + err("register_slot: slot[%s] is already registered\n", slot->name); > + rpaphp_release_slot(slot->hotplug_slot); > + return (1); > + } return is not a function :) > +static char *get_my_drc_name(struct device_node *dn, u32 my_drc_index) > +{ > + char *name, *ptr = NULL; > + int *drc_names, *drc_indexes, i; > + struct device_node *parent = dn->parent; > + > + if (!parent) > + return ptr; > + > + drc_names = (int *) get_property(parent, "ibm,drc-names", NULL); > + drc_indexes = (int *) get_property(parent, "ibm,drc-indexes", NULL); > + if (!drc_names || !drc_indexes) > + return ptr; > + > + name = (char *) &drc_names[1]; > + for (i = 0; i < drc_indexes[0]; i++, name += (strlen(name) + 1)) { > + if (drc_indexes[i + 1] == my_drc_index) { > + ptr = (char *) name; > + break; > + } > + } > + > + return ptr; > +} Again with the spaces... thanks, greg k-h ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From lxiep at us.ibm.com Tue Jun 8 08:39:03 2004 From: lxiep at us.ibm.com (Linda Xie) Date: Mon, 07 Jun 2004 17:39:03 -0500 Subject: [PATCH] rpaphp.patch -- multi-function devices not handled correctly In-Reply-To: <40AEBB98.5080903@us.ibm.com> References: <40AC1099.9060007@us.ibm.com> <20040520211613.GA27095@kroah.com> <40AEBB98.5080903@us.ibm.com> Message-ID: <40C4EE87.3000802@us.ibm.com> Linda Xie wrote: > Here is an updated rpaphp patch. > > Thanks, > > Linda > > Greg KH wrote: > >> On Wed, May 19, 2004 at 08:57:45PM -0500, Linda Xie wrote: >> >> >>> Can pci_scan_child_bus be exported? I pasted it in rpaphp_pci.c for >>> temparary use. >>> >>> >> >> Yes, I'll be glad to export it if you need it. Just send me a separate >> patch with your next, updated version. Should probably make it >> EXPORT_SYMBOL_GPL() just to be safe... >> >> thanks, >> >> greg k-h >> Hi Greg, Sorry for taking so long. The attached patch is the latest version of rpahp patch. It includes changes I made based on John Rose's comments. It also fixes a couple of bugs we found in the last couple of weeks. BTW, Some of our device driver developers have done some PHP tests(pcnet32-4ports, e1000-2ports, e100...) using this code. Please apply it to you tree. Thanks, Linda >> >> >> >> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rpaphp_updated.patch Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20040607/8c90d860/attachment.txt From sfr at canb.auug.org.au Tue Jun 8 17:13:44 2004 From: sfr at canb.auug.org.au (Stephen Rothwell) Date: Tue, 8 Jun 2004 17:13:44 +1000 Subject: [PATCH] remove struct vio_dev's archdata Message-ID: <20040608171344.7a3572bf.sfr@canb.auug.org.au> Hi Dave, This patch is the restart of my VIO work. This first patch just removes vio_dev's archdata member and uses its dev.platform_data instead since it is unused. This simplifies a couple of bits of the code and reduces struct vio_dev's size. I also static'ed a couple of functions. Please apply to the Ameslab tree if you think it is OK and have time. -- Cheers, Stephen Rothwell sfr at canb.auug.org.au http://www.canb.auug.org.au/~sfr/ -------------- next part -------------- diff -ruN ppc64-linux-2.5/arch/ppc64/kernel/vio.c ppc64-linux-2.5.archdata/arch/ppc64/kernel/vio.c --- ppc64-linux-2.5/arch/ppc64/kernel/vio.c 2004-05-19 18:04:56.000000000 +1000 +++ ppc64-linux-2.5.archdata/arch/ppc64/kernel/vio.c 2004-06-08 17:04:51.000000000 +1000 @@ -32,7 +32,9 @@ extern struct subsystem devices_subsys; /* needed for vio_find_name() */ -struct iommu_table *vio_build_iommu_table(struct vio_dev *dev); +static struct iommu_table *vio_build_iommu_table(struct vio_dev *); +static const struct vio_device_id *vio_match_device( + const struct vio_device_id *, const struct vio_dev *); #ifdef CONFIG_PPC_PSERIES static int vio_num_address_cells; @@ -136,15 +138,15 @@ * system is in its list of supported devices. Returns the matching * vio_device_id structure or NULL if there is no match. */ -const struct vio_device_id * vio_match_device(const struct vio_device_id *ids, +static const struct vio_device_id * vio_match_device(const struct vio_device_id *ids, const struct vio_dev *dev) { DBGENTER(); #ifdef CONFIG_PPC_PSERIES while (ids->type) { - if ((strncmp(dev->archdata->type, ids->type, strlen(ids->type)) == 0) && - device_is_compatible((struct device_node*)dev->archdata, ids->compat)) + if ((strncmp(((struct device_node *)dev->dev.platform_data)->type, ids->type, strlen(ids->type)) == 0) && + device_is_compatible(dev->dev.platform_data, ids->compat)) return ids; ids++; } @@ -263,14 +265,13 @@ DBGENTER(); /* XXX free TCE table */ - of_node_put(viodev->archdata); + of_node_put(viodev->dev.platform_data); kfree(viodev); } static ssize_t viodev_show_devspec(struct device *dev, char *buf) { - struct vio_dev *viodev = to_vio_dev(dev); - struct device_node *of_node = viodev->archdata; + struct device_node *of_node = dev->platform_data; return sprintf(buf, "%s\n", of_node->full_name); } @@ -278,8 +279,7 @@ static ssize_t viodev_show_name(struct device *dev, char *buf) { - struct vio_dev *viodev = to_vio_dev(dev); - struct device_node *of_node = viodev->archdata; + struct device_node *of_node = dev->platform_data; return sprintf(buf, "%s\n", of_node->name); } @@ -290,7 +290,7 @@ * @of_node: The OF node for this device. * * Creates and initializes a vio_dev structure from the data in - * of_node (archdata) and adds it to the list of virtual devices. + * of_node (dev.platform_data) and adds it to the list of virtual devices. * Returns a pointer to the created vio_dev or NULL if node has * NULL device_type or compatible fields. */ @@ -324,7 +324,7 @@ } memset(viodev, 0, sizeof(struct vio_dev)); - viodev->archdata = (void *)of_node_get(of_node); + viodev->dev.platform_data = of_node_get(of_node); viodev->unit_address = *unit_address; viodev->iommu_table = vio_build_iommu_table(viodev); @@ -380,7 +380,7 @@ */ const void * vio_get_attribute(struct vio_dev *vdev, void* which, int* length) { - return get_property((struct device_node *)vdev->archdata, (char*)which, length); + return get_property(vdev->dev.platform_data, (char*)which, length); } EXPORT_SYMBOL(vio_get_attribute); @@ -427,7 +427,7 @@ * Returns a pointer to the built tce tree, or NULL if it can't * find property. */ -struct iommu_table * vio_build_iommu_table(struct vio_dev *dev) +static struct iommu_table * vio_build_iommu_table(struct vio_dev *dev) { unsigned int *dma_window; struct iommu_table *newTceTable; @@ -435,7 +435,7 @@ unsigned long size; int dma_window_property_size; - dma_window = (unsigned int *) get_property((struct device_node *)dev->archdata, "ibm,my-dma-window", &dma_window_property_size); + dma_window = (unsigned int *) get_property(dev->dev.platform_data, "ibm,my-dma-window", &dma_window_property_size); if(!dma_window) { return NULL; } diff -ruN ppc64-linux-2.5/drivers/scsi/ibmvscsi/iseries_vscsi.c ppc64-linux-2.5.archdata/drivers/scsi/ibmvscsi/iseries_vscsi.c --- ppc64-linux-2.5/drivers/scsi/ibmvscsi/iseries_vscsi.c 2004-05-22 10:04:35.000000000 +1000 +++ ppc64-linux-2.5.archdata/drivers/scsi/ibmvscsi/iseries_vscsi.c 2004-06-08 16:27:52.000000000 +1000 @@ -153,7 +153,6 @@ int __init ibmvscsi_module_init(void) { - iseries_vscsi_dev.archdata = to_vio_dev(iSeries_vio_dev)->archdata; iseries_vscsi_dev.iommu_table = to_vio_dev(iSeries_vio_dev)->iommu_table; if (device_register(&iseries_vscsi_dev.dev)) { diff -ruN ppc64-linux-2.5/include/asm-ppc64/vio.h ppc64-linux-2.5.archdata/include/asm-ppc64/vio.h --- ppc64-linux-2.5/include/asm-ppc64/vio.h 2004-04-13 18:06:17.000000000 +1000 +++ ppc64-linux-2.5.archdata/include/asm-ppc64/vio.h 2004-06-08 16:32:33.000000000 +1000 @@ -43,8 +43,6 @@ int vio_register_driver(struct vio_driver *drv); void vio_unregister_driver(struct vio_driver *drv); -const struct vio_device_id * vio_match_device(const struct vio_device_id *ids, - const struct vio_dev *dev); struct vio_dev * __devinit vio_register_device(struct device_node *node_vdev); void __devinit vio_unregister_device(struct vio_dev *dev); @@ -52,7 +50,6 @@ const void * vio_get_attribute(struct vio_dev *vdev, void* which, int* length); int vio_get_irq(struct vio_dev *dev); -struct iommu_table * vio_build_iommu_table(struct vio_dev *dev); int vio_enable_interrupts(struct vio_dev *dev); int vio_disable_interrupts(struct vio_dev *dev); @@ -110,7 +107,6 @@ * The vio_dev structure is used to describe virtual I/O devices. */ struct vio_dev { - struct device_node *archdata; /* Open Firmware node */ void *driver_data; /* data private to the driver */ struct iommu_table *iommu_table; /* vio_map_* uses this */ uint32_t unit_address; From sfr at canb.auug.org.au Tue Jun 8 17:40:04 2004 From: sfr at canb.auug.org.au (Stephen Rothwell) Date: Tue, 8 Jun 2004 17:40:04 +1000 Subject: [PATCH] remove struct vio_dev's driver_data Message-ID: <20040608174004.56c392fc.sfr@canb.auug.org.au> Hi Dave, Next in the series ... This patch removes struct vio_dev's driver_data in favour of using hte driver_data in hte embedded struct device. This simplifies some of the virtual scsi code a little and saves us yet more room in strcut vio_dev. Please review and apply to Ameslab if you thing it is OK. This patch goes on top of the patch to remove archdata. -- Cheers, Stephen Rothwell sfr at canb.auug.org.au http://www.canb.auug.org.au/~sfr/ -------------- next part -------------- diff -ruN ppc64-linux-2.5.archdata/drivers/char/hvcs.c ppc64-linux-2.5.driver_data/drivers/char/hvcs.c --- ppc64-linux-2.5.archdata/drivers/char/hvcs.c 2004-05-12 09:07:38.000000000 +1000 +++ ppc64-linux-2.5.driver_data/drivers/char/hvcs.c 2004-06-08 17:23:25.000000000 +1000 @@ -342,7 +342,7 @@ hvcsd->kobj.ktype = &hvcs_kobj_type; hvcsd->vdev = dev; - dev->driver_data = hvcsd; + dev->dev.driver_data = hvcsd; sprintf(hvcsd->name,"%X",dev->unit_address); hvcsd->index = ++hvcs_struct_count; @@ -377,7 +377,7 @@ static int __devexit hvcs_remove(struct vio_dev *dev) { - struct hvcs_struct *hvcsd = (struct hvcs_struct *)dev->driver_data; + struct hvcs_struct *hvcsd = dev->dev.driver_data; if (!hvcsd) return -ENODEV; @@ -912,7 +912,7 @@ static inline struct hvcs_struct *from_vio_dev(struct vio_dev *viod) { - return (struct hvcs_struct *)viod->driver_data; + return viod->dev.driver_data; } /* The sysfs interface for the driver and devices */ diff -ruN ppc64-linux-2.5.archdata/drivers/net/ibmveth.c ppc64-linux-2.5.driver_data/drivers/net/ibmveth.c --- ppc64-linux-2.5.archdata/drivers/net/ibmveth.c 2004-05-28 11:04:34.000000000 +1000 +++ ppc64-linux-2.5.driver_data/drivers/net/ibmveth.c 2004-06-08 17:24:43.000000000 +1000 @@ -902,7 +902,7 @@ adapter = netdev->priv; memset(adapter, 0, sizeof(adapter)); - dev->driver_data = netdev; + dev->dev.driver_data = netdev; adapter->vdev = dev; adapter->netdev = netdev; @@ -972,7 +972,7 @@ static int __devexit ibmveth_remove(struct vio_dev *dev) { - struct net_device *netdev = dev->driver_data; + struct net_device *netdev = dev->dev.driver_data; struct ibmveth_adapter *adapter = netdev->priv; unregister_netdev(netdev); diff -ruN ppc64-linux-2.5.archdata/drivers/scsi/ibmvscsi/ibmvscsis.c ppc64-linux-2.5.driver_data/drivers/scsi/ibmvscsi/ibmvscsis.c --- ppc64-linux-2.5.archdata/drivers/scsi/ibmvscsi/ibmvscsis.c 2004-05-28 11:04:34.000000000 +1000 +++ ppc64-linux-2.5.driver_data/drivers/scsi/ibmvscsi/ibmvscsis.c 2004-06-08 17:31:01.000000000 +1000 @@ -2205,7 +2205,7 @@ { struct device *dev = container_of(vbus->kobj.parent, struct device , kobj); - struct server_adapter *adapter = (struct server_adapter *)to_vio_dev(dev)->driver_data; + struct server_adapter *adapter = dev->driver_data; int cur_num_targets = atomic_read(&vbus->num_targets); unsigned long flags; @@ -2257,7 +2257,7 @@ static void set_num_buses(struct device *dev, long value) { - struct server_adapter *adapter = (struct server_adapter *)to_vio_dev(dev)->driver_data; + struct server_adapter *adapter = dev->driver_data; int cur_num_buses = atomic_read(&adapter->num_buses); unsigned long flags; @@ -2329,7 +2329,7 @@ { struct vdev *vdev = container_of(kobj, struct vdev, kobj); struct device *dev = container_of(kobj->parent->parent, struct device, kobj); - struct server_adapter *adapter = (struct server_adapter *)to_vio_dev(dev)->driver_data; + struct server_adapter *adapter = dev->driver_data; unsigned long flags; ssize_t returned; @@ -2357,7 +2357,7 @@ { struct vdev *vdev = container_of(kobj, struct vdev, kobj); struct device *dev = container_of(kobj->parent->parent, struct device, kobj); - struct server_adapter *adapter = (struct server_adapter *)to_vio_dev(dev)->driver_data; + struct server_adapter *adapter = dev->driver_data; long flags; long value = simple_strtol(buf, NULL, 10); @@ -2474,7 +2474,7 @@ /* Device attributes */ static ssize_t vscsi_dev_bus_show(struct device * dev, char * buf) { - struct server_adapter *adapter = (struct server_adapter *)to_vio_dev(dev)->driver_data; + struct server_adapter *adapter = dev->driver_data; return sprintf(buf, "%d\n", atomic_read(&adapter->num_buses)); } @@ -2578,7 +2578,7 @@ memset(adapter, 0x00, sizeof(*adapter)); adapter->dma_dev = dev; adapter->dev = &dev->dev; - dev->driver_data = adapter; + dev->dev.driver_data = adapter; sprintf(adapter->name, "%x", dev->unit_address); adapter->lock = SPIN_LOCK_UNLOCKED; @@ -2647,8 +2647,7 @@ int bus; int target; unsigned long flags; - struct server_adapter *adapter = - (struct server_adapter *)dev->driver_data; + struct server_adapter *adapter = dev->dev.driver_data; info("entering remove for UA 0x%x\n", dev->unit_address); diff -ruN ppc64-linux-2.5.archdata/drivers/scsi/ibmvscsi/rpa_vscsi.c ppc64-linux-2.5.driver_data/drivers/scsi/ibmvscsi/rpa_vscsi.c --- ppc64-linux-2.5.archdata/drivers/scsi/ibmvscsi/rpa_vscsi.c 2004-04-28 17:04:34.000000000 +1000 +++ ppc64-linux-2.5.driver_data/drivers/scsi/ibmvscsi/rpa_vscsi.c 2004-06-08 17:26:33.000000000 +1000 @@ -282,7 +282,7 @@ { struct ibmvscsi_host_data *hostdata = ibmvscsi_probe(&vdev->dev); if (hostdata) { - vdev->driver_data = hostdata; + vdev->dev.driver_data = hostdata; return 0; } else { return -1; @@ -295,8 +295,7 @@ */ static int rpa_remove(struct vio_dev *vdev) { - struct ibmvscsi_host_data *hostdata = - (struct ibmvscsi_host_data *)vdev->driver_data; + struct ibmvscsi_host_data *hostdata = vdev->dev.driver_data; ibmvscsi_remove(hostdata); return 0; } diff -ruN ppc64-linux-2.5.archdata/include/asm-ppc64/vio.h ppc64-linux-2.5.driver_data/include/asm-ppc64/vio.h --- ppc64-linux-2.5.archdata/include/asm-ppc64/vio.h 2004-06-08 16:32:33.000000000 +1000 +++ ppc64-linux-2.5.driver_data/include/asm-ppc64/vio.h 2004-06-08 17:31:55.000000000 +1000 @@ -107,7 +107,6 @@ * The vio_dev structure is used to describe virtual I/O devices. */ struct vio_dev { - void *driver_data; /* data private to the driver */ struct iommu_table *iommu_table; /* vio_map_* uses this */ uint32_t unit_address; unsigned int irq; From lxiep at us.ibm.com Wed Jun 9 15:00:29 2004 From: lxiep at us.ibm.com (Linda Xie) Date: Wed, 09 Jun 2004 00:00:29 -0500 Subject: [Pcihpd-discuss] Re: [PATCH] rpaphp.patch -- multi-function devices not handled correctly In-Reply-To: <20040607222154.GA8232@kroah.com> References: <40AC1099.9060007@us.ibm.com> <20040520211613.GA27095@kroah.com> <40AEBB98.5080903@us.ibm.com> <40C4EE87.3000802@us.ibm.com> <20040607222154.GA8232@kroah.com> Message-ID: <40C6996D.2030405@us.ibm.com> Hi Greg, Thank you very much for your comments. The attached patch contains the following fixes. (See my comments below). John, your rpadlpar patch has been merged. Linda Greg KH wrote: >On Mon, Jun 07, 2004 at 05:39:03PM -0500, Linda Xie wrote: > > >>+#ifdef DEBUG >>+static void print_slot_pci_funcs(struct slot *slot) >>+{ >>+ struct list_head *l; >>+ >>+ if (slot->dev_type == PCI_DEV) { >>+ printk("pci_funcs of slot[%s]\n", slot->name); >>+ if (list_empty(&slot->dev.pci_funcs)) >>+ printk(" pci_funcs is EMPTY\n"); >>+ >>+ list_for_each (l, &slot->dev.pci_funcs) { >>+ struct rpaphp_pci_func *func = >>+ list_entry(l, struct rpaphp_pci_func, sibling); >>+ printk(" FOUND dev=%s\n", pci_name(func->pci_dev)); >>+ } >>+ } >>+} >>+#endif >> >> > >Please provide an empty version of this function if DEBUG is not >defined. That way you get rid of the #ifdef in the places where you >call this function. > Fixed. > > >>+static ssize_t removable_read_file (struct hotplug_slot *php_slot, char *buf) >>+{ >>+ u8 value; >>+ int retval = -ENOENT; >>+ struct slot *slot = (struct slot *)php_slot->private; >>+ >>+ if (!slot) >>+ return retval; >>+ >>+ value = slot->removable; >>+ retval = sprintf (buf, "%d\n", value); >>+ return retval; >>+} >> >> > >Hm, you used spaces here instead of tabs :( > Fixed. > > >>+static struct hotplug_slot_attribute hotplug_slot_attr_removable = { >>+ .attr = {.name ="phy_removable", .mode = S_IFREG | S_IRUGO}, >>+ .show = removable_read_file, >>+}; >> >> > >Please use the proper macros for this. You didn't set the owner field >due to this :( > > I checked the owner field of the file, it did get set. I found that pci_hotplug_core.c uses the same macors for "adapter" (read only attribute). Am I missing anything? > > > >>+ >>+static void rpaphp_sysfs_add_attr_removable (struct hotplug_slot *slot) >>+{ >>+ sysfs_create_file(&slot->kobj, &hotplug_slot_attr_removable.attr); >>+} >>+ >>+void rpaphp_sysfs_remove_attr_removable (struct hotplug_slot *slot) >>+{ >>+ sysfs_remove_file(&slot->kobj, &hotplug_slot_attr_removable.attr); >>+} >> >> > >Why is the add files function static, yet the remove one global? >That's implying that your create is done at a different "level" than the >remove, which it looks like it is. Should this be also fixed up? > Fixed. > > >>+static int is_registered(struct slot *slot) >>+{ >>+ struct list_head *tmp, *n; >>+ struct slot *tmp_slot; >>+ >>+ list_for_each_safe(tmp, n, &rpaphp_slot_head) { >>+ tmp_slot = list_entry(tmp, struct slot, rpaphp_slot_list); >>+ if (!strcmp(tmp_slot->name, slot->name)) >>+ return 1; >>+ } >>+ return 0; >>+} >> >> > >list_for_each_safe() is not needed here. How about a simple >list_for_each_entry() instead? > Fixed. >Also, the pci hotplug core will catch this error, right? Why duplicate >the logic again? > I don't think that the pci hotplug core handles this error very nicely -- crahsing the system, if pci_hp_register(slot) is called with the same slot->name that has been registered before. > > > > >>+ /* should not try to register the same slot twice */ >>+ if (is_registered(slot)) { /* should't be here */ >>+ err("register_slot: slot[%s] is already registered\n", slot->name); >>+ rpaphp_release_slot(slot->hotplug_slot); >>+ return (1); >>+ } >> >> > >return is not a function :) > changed to "return 1" . > > >>+static char *get_my_drc_name(struct device_node *dn, u32 my_drc_index) >>+{ >>+ char *name, *ptr = NULL; >>+ int *drc_names, *drc_indexes, i; >>+ struct device_node *parent = dn->parent; >>+ >>+ if (!parent) >>+ return ptr; >>+ >>+ drc_names = (int *) get_property(parent, "ibm,drc-names", NULL); >>+ drc_indexes = (int *) get_property(parent, "ibm,drc-indexes", NULL); >>+ if (!drc_names || !drc_indexes) >>+ return ptr; >>+ >>+ name = (char *) &drc_names[1]; >>+ for (i = 0; i < drc_indexes[0]; i++, name += (strlen(name) + 1)) { >>+ if (drc_indexes[i + 1] == my_drc_index) { >>+ ptr = (char *) name; >>+ break; >>+ } >>+ } >>+ >>+ return ptr; >>+} >> >> >> > >Again with the spaces... > Fixed. >thanks, > >greg k-h > > > > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rpaphp_updated.patch Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20040609/f5a63997/attachment.txt From akpm at osdl.org Wed Jun 9 17:10:36 2004 From: akpm at osdl.org (Andrew Morton) Date: Wed, 9 Jun 2004 00:10:36 -0700 Subject: [lhcs-devel] Re: [RFC] don't create cpu/online sysfs file In-Reply-To: <20040607102226.A19556@unix-os.sc.intel.com> References: <20040604154952.A15326@unix-os.sc.intel.com> <1086390257.24915.132.camel@nighthawk> <20040604161749.A15628@unix-os.sc.intel.com> <1086392465.24915.151.camel@nighthawk> <20040605073802.A22026@unix-os.sc.intel.com> <1086463340.30138.58.camel@nighthawk> <20040606132723.A10563@unix-os.sc.intel.com> <1086584735.30138.130.camel@nighthawk> <20040607070852.A17932@unix-os.sc.intel.com> <1086626508.28074.1.camel@nighthawk> <20040607102226.A19556@unix-os.sc.intel.com> Message-ID: <20040609001036.7fae44fb.akpm@osdl.org> Ashok Raj wrote: > > On Mon, Jun 07, 2004 at 09:41:49AM -0700, Dave Hansen wrote: > > On Mon, 2004-06-07 at 07:08, Ashok Raj wrote:plugging. > > > + if (systemcfg->platform == PLATFORM_PSERIES_LPAR) > > > + cpu->no_control=1; > > > > That condition is also inverted. Should read: > > > > if (systemcfg->platform != PLATFORM_PSERIES_LPAR) > > cpu->no_control = 1; > > Good catch...I knew i mentioned untested :-) > > fixed patch attached... > > ... > --- linux-2.6.7-rc2/arch/ppc64/kernel/sysfs.c~cpu_control_file 2004-06-06 13:12:06.467033408 -0700 > +++ linux-2.6.7-rc2-root/arch/ppc64/kernel/sysfs.c 2004-06-07 10:12:45.999901454 -0700 > @@ -325,6 +325,16 @@ static int __init topology_init(void) > #ifdef CONFIG_NUMA > parent = &node_devices[cpu_to_node(cpu)]; > #endif > + /* > + * For now, we just see if the system supports making > + * the RTAS calls for CPU hotplug. But, there may be a > + * more comprehensive way to do this for an individual > + * CPU. For instance, the boot cpu might never be valid > + * for hotplugging. > + */ > + if (systemcfg->platform != PLATFORM_PSERIES_LPAR) > + cpu->no_control=1; > + > register_cpu(c, cpu, parent); > > register_cpu_pmc(&c->sysdev); > The ppc64 part doesn't compile - `cpu' is an integer. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From ashok.raj at intel.com Thu Jun 10 00:27:12 2004 From: ashok.raj at intel.com (Ashok Raj) Date: Wed, 9 Jun 2004 07:27:12 -0700 Subject: [lhcs-devel] Re: [RFC] don't create cpu/online sysfs file In-Reply-To: <20040609001036.7fae44fb.akpm@osdl.org>; from akpm@osdl.org on Wed, Jun 09, 2004 at 12:10:36AM -0700 References: <20040604161749.A15628@unix-os.sc.intel.com> <1086392465.24915.151.camel@nighthawk> <20040605073802.A22026@unix-os.sc.intel.com> <1086463340.30138.58.camel@nighthawk> <20040606132723.A10563@unix-os.sc.intel.com> <1086584735.30138.130.camel@nighthawk> <20040607070852.A17932@unix-os.sc.intel.com> <1086626508.28074.1.camel@nighthawk> <20040607102226.A19556@unix-os.sc.intel.com> <20040609001036.7fae44fb.akpm@osdl.org> Message-ID: <20040609072712.A7061@unix-os.sc.intel.com> On Wed, Jun 09, 2004 at 12:10:36AM -0700, Andrew Morton wrote: > Ashok Raj wrote: > > > > On Mon, Jun 07, 2004 at 09:41:49AM -0700, Dave Hansen wrote: > > > On Mon, 2004-06-07 at 07:08, Ashok Raj wrote:plugging. > > > > + if (systemcfg->platform == PLATFORM_PSERIES_LPAR) > > > > + cpu->no_control=1; > > > > The ppc64 part doesn't compile - `cpu' is an integer. Sorry about that... I dont have a PPC64 platform.... ashokr Signed-off-by: Ashok Raj D: This file provides ability for caller of register_cpu() to either create D: a control file, or not. This can be handy if a particular platform decides D: that certain CPU's are not removable. Hence would like to not create D: a control file. --- linux-2.6.7-rc2-root/arch/ppc64/kernel/sysfs.c | 10 ++++++++++ linux-2.6.7-rc2-root/drivers/base/cpu.c | 4 +++- linux-2.6.7-rc2-root/include/linux/cpu.h | 1 + 3 files changed, 14 insertions(+), 1 deletion(-) diff -puN include/linux/cpu.h~cpu_control_file include/linux/cpu.h --- linux-2.6.7-rc2/include/linux/cpu.h~cpu_control_file 2004-06-06 12:54:02.000000000 -0700 +++ linux-2.6.7-rc2-root/include/linux/cpu.h 2004-06-07 06:25:44.000000000 -0700 @@ -27,6 +27,7 @@ struct cpu { int node_id; /* The node which contains the CPU */ + int no_control; /* Should the sysfs control file be created? */ struct sys_device sysdev; }; diff -puN drivers/base/cpu.c~cpu_control_file drivers/base/cpu.c --- linux-2.6.7-rc2/drivers/base/cpu.c~cpu_control_file 2004-06-06 12:56:47.000000000 -0700 +++ linux-2.6.7-rc2-root/drivers/base/cpu.c 2004-06-07 07:03:12.000000000 -0700 @@ -58,6 +58,8 @@ static inline void register_cpu_control( /* * register_cpu - Setup a driverfs device for a CPU. + * @cpu - Callers can set the cpu->no_control field to 1, to indicate not to + * generate a control file in sysfs for this CPU. * @num - CPU number to use when creating the device. * * Initialize and register the CPU device. @@ -75,7 +77,7 @@ int __init register_cpu(struct cpu *cpu, error = sysfs_create_link(&root->sysdev.kobj, &cpu->sysdev.kobj, kobject_name(&cpu->sysdev.kobj)); - if (!error) + if (!error && !cpu->no_control) register_cpu_control(cpu); return error; } diff -puN arch/ppc64/kernel/sysfs.c~cpu_control_file arch/ppc64/kernel/sysfs.c --- linux-2.6.7-rc2/arch/ppc64/kernel/sysfs.c~cpu_control_file 2004-06-06 13:12:06.000000000 -0700 +++ linux-2.6.7-rc2-root/arch/ppc64/kernel/sysfs.c 2004-06-09 07:22:12.206182184 -0700 @@ -325,6 +325,16 @@ static int __init topology_init(void) #ifdef CONFIG_NUMA parent = &node_devices[cpu_to_node(cpu)]; #endif + /* + * For now, we just see if the system supports making + * the RTAS calls for CPU hotplug. But, there may be a + * more comprehensive way to do this for an individual + * CPU. For instance, the boot cpu might never be valid + * for hotplugging. + */ + if (systemcfg->platform != PLATFORM_PSERIES_LPAR) + c->no_control = 1; + register_cpu(c, cpu, parent); register_cpu_pmc(&c->sysdev); _ ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Thu Jun 10 08:40:00 2004 From: anton at samba.org (Anton Blanchard) Date: Thu, 10 Jun 2004 08:40:00 +1000 Subject: Distro for ppc64/2.6 work? In-Reply-To: <52oenzosyi.fsf@topspin.com> References: <52oenzosyi.fsf@topspin.com> Message-ID: <20040609224000.GA21437@krispykreme> Hi, > I have an IBM pSeries 630 box that I would like to start using for > kernel 2.6-based development. What is a good distribution to start > with? I'm not that concerned about the distribution installing 2.6 to > start with, but I'd like to avoid dealing with having to build a newer > toolchain, install module-init-tools, etc. if possible. Unfortunately if you go with RHEL3 or SLES8 you will need to install a newer module-init-tools. > Along the same lines, should a recent stock Linus kernel (say 2.6.6) > work on a p630 (with pSeries_defconfig), or is there a better tree to > work with? Yes, a Linus kernel should work fine. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From johnrose at austin.ibm.com Sat Jun 12 07:41:53 2004 From: johnrose at austin.ibm.com (John Rose) Date: Fri, 11 Jun 2004 16:41:53 -0500 Subject: [Pcihpd-discuss] Re: [PATCH] rpaphp.patch -- multi-function devices not handled correctly In-Reply-To: <40C6996D.2030405@us.ibm.com> References: <40AC1099.9060007@us.ibm.com> <20040520211613.GA27095@kroah.com> <40AEBB98.5080903@us.ibm.com> <40C4EE87.3000802@us.ibm.com> <20040607222154.GA8232@kroah.com> <40C6996D.2030405@us.ibm.com> Message-ID: <1086990113.24732.5.camel@sinatra.austin.ibm.com> Hi Linda- I have just one question: > diff -Nru a/drivers/pci/hotplug/rpadlpar_core.c b/drivers/pci/hotplug/rpadlpar_core.c > --- a/drivers/pci/hotplug/rpadlpar_core.c Tue Jun 8 22:53:59 2004 > +++ b/drivers/pci/hotplug/rpadlpar_core.c Tue Jun 8 22:53:59 2004 > @@ -24,25 +24,6 @@ > for (child = of_get_next_child(parent, NULL); > - child; child = of_get_next_child(parent, child)) { > + child; child = of_get_next_child(parent, child)) { > loc_code = get_property(child, "ibm,loc-code", NULL); > - if (loc_code && !strcmp(loc_code, drc_name)) > + if (loc_code && !strncmp(loc_code, drc_name, strlen(drc_name))) > return child; > } > Can you explain why strncmp rather than strcmp? Other than this, looks good to me! Thanks- John On Wed, 2004-06-09 at 00:00, Linda Xie wrote: > Hi Greg, > > Thank you very much for your comments. The attached patch contains > the following fixes. (See my comments below). > > John, your rpadlpar patch has been merged. > > > Linda > > ______________________________________________________________________ ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From linas at austin.ibm.com Sat Jun 12 09:32:32 2004 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Fri, 11 Jun 2004 18:32:32 -0500 Subject: [PATCH] PCI PHB unit id detection interface change Message-ID: <20040611183232.D12518@forte.austin.ibm.com> Hi, I'm looking for sanity-check/review of the following patch. Turns out ath the kernel has been using a deprecated firmware interface for discovring the PCI PHB Unit Id's. The PHN Unit ID's are used for a variety of PCI operations. The patch below is a change to use the recommended API. Its been tested on one-each of power3,4,and 5 boxes; however, given that its an API change, I have some concern that someone might get broken by this. Please review. --linas -------------- next part -------------- Index: arch/ppc64/kernel/pSeries_pci.c =================================================================== RCS file: /home/linas/cvsroot/eeh/arch/ppc64/kernel/pSeries_pci.c,v retrieving revision 1.1 diff -u -p -r1.1 pSeries_pci.c --- a/arch/ppc64/kernel/pSeries_pci.c 8 Jun 2004 22:52:54 -0000 1.1 +++ b/arch/ppc64/kernel/pSeries_pci.c 11 Jun 2004 21:56:41 -0000 @@ -353,6 +353,55 @@ static void python_countermeasures(unsig iounmap(chip_regs); } +void init_pci_config_tokens (void) +{ + read_pci_config = rtas_token("read-pci-config"); + write_pci_config = rtas_token("write-pci-config"); + ibm_read_pci_config = rtas_token("ibm,read-pci-config"); + ibm_write_pci_config = rtas_token("ibm,write-pci-config"); +} + +unsigned long get_phb_buid (struct device_node *phb) +{ + int addr_cells; + unsigned int *buid_vals; + unsigned int len; + unsigned long buid; + +#define NEW_STYLE_BUIDS +#ifdef NEW_STYLE_BUIDS + if (-1 == ibm_read_pci_config) return 0; + + /* PHB's will always be children of the root node, + * or so it is promised by the current firmware. */ + if (NULL == phb->parent) return 0; + if (phb->parent->parent) return 0; + + buid_vals = (unsigned int *) get_property(phb, "reg", &len); + if (NULL == buid_vals) return 0; + + addr_cells = prom_n_addr_cells(phb); + if (addr_cells == 1) { + buid = (unsigned long) buid_vals[0]; + } else { + buid = (((unsigned long)buid_vals[0]) << 32UL) | + (((unsigned long)buid_vals[1]) & 0xffffffff); + } +#else + // The use of ibm,fw-phb-id is deprecated. Keep a copy of this + // code for reference, in case the above code needs to be rolled back. + buid_vals = (int *) get_property(phb, "ibm,fw-phb-id", &len); + if (buid_vals == NULL) return 0; + if (len < 2 * sizeof(int)) { + buid = (unsigned long) buid_vals[0]; + } else { + buid = (((unsigned long)buid_vals[0]) << 32UL) | + (((unsigned long)buid_vals[1]) & 0xffffffff); + } +#endif + return buid; +} + struct pci_controller *alloc_phb(struct device_node *dev, unsigned int addr_size_words) { @@ -360,7 +409,6 @@ struct pci_controller *alloc_phb(struct unsigned int *ui_ptr = NULL, len; struct reg_property64 reg_struct; int *bus_range; - int *buid_vals; char *model; enum phb_types phb_type; struct property *of_prop; @@ -431,18 +479,7 @@ struct pci_controller *alloc_phb(struct phb->arch_data = dev; phb->ops = &rtas_pci_ops; - buid_vals = (int *) get_property(dev, "ibm,fw-phb-id", &len); - - if (buid_vals == NULL) { - phb->buid = 0; - } else { - if (len < 2 * sizeof(int)) - // Support for new OF that only has 1 integer for buid. - phb->buid = (unsigned long)buid_vals[0]; - else - phb->buid = (((unsigned long)buid_vals[0]) << 32UL) | - (((unsigned long)buid_vals[1]) & 0xffffffff); - } + phb->buid = get_phb_buid (dev); return phb; } @@ -456,10 +493,7 @@ unsigned long __init find_and_init_phbs( unsigned int *opprop; struct device_node *root = of_find_node_by_path("/"); - read_pci_config = rtas_token("read-pci-config"); - write_pci_config = rtas_token("write-pci-config"); - ibm_read_pci_config = rtas_token("ibm,read-pci-config"); - ibm_write_pci_config = rtas_token("ibm,write-pci-config"); + init_pci_config_tokens(); if (naca->interrupt_controller == IC_OPEN_PIC) { opprop = (unsigned int *)get_property(root, --- arch/ppc64/kernel/eeh.c.7.69-orig 2004-06-11 14:10:19.000000000 -0500 +++ arch/ppc64/kernel/eeh.c 2004-06-11 16:50:55.000000000 -0500 @@ -40,6 +40,10 @@ #define CONFIG_ADDR(busno, devfn) \ (((((busno) & 0xff) << 8) | ((devfn) & 0xf8)) << 8) +/* From pSeries_pci.h */ +extern void init_pci_config_tokens (void); +extern unsigned long get_phb_buid (struct device_node *); + /* RTAS tokens */ static int ibm_set_eeh_option; static int ibm_set_slot_reset; @@ -645,7 +649,7 @@ static void *early_enable_eeh(struct dev dn->full_name); #endif } else { - printk(KERN_WARNING "EEH: %s: rtas_call failed.\n", + printk(KERN_WARNING "EEH: %s: could not enable EEH, rtas_call failed.\n", dn->full_name); } } else { @@ -709,24 +713,16 @@ void __init eeh_init(void) } /* Enable EEH for all adapters. Note that eeh requires buid's */ + init_pci_config_tokens(); for (phb = of_find_node_by_name(NULL, "pci"); phb; phb = of_find_node_by_name(phb, "pci")) { - int len; - int *buid_vals; + unsigned long buid; - buid_vals = (int *)get_property(phb, "ibm,fw-phb-id", &len); - if (!buid_vals) - continue; - if (len == sizeof(int)) { - info.buid_lo = buid_vals[0]; - info.buid_hi = 0; - } else if (len == sizeof(int)*2) { - info.buid_hi = buid_vals[0]; - info.buid_lo = buid_vals[1]; - } else { - printk(KERN_INFO "EEH: odd ibm,fw-phb-id len returned: %d\n", len); - continue; - } + buid = get_phb_buid (phb); + if (0 == buid) continue; + + info.buid_lo = BUID_LO(buid); + info.buid_hi = BUID_HI(buid); traverse_pci_devices(phb, early_enable_eeh, NULL, &info); } From greg at kroah.com Sat Jun 12 10:13:36 2004 From: greg at kroah.com (Greg KH) Date: Fri, 11 Jun 2004 17:13:36 -0700 Subject: [Pcihpd-discuss] Re: [PATCH] rpaphp.patch -- multi-function devices not handled correctly In-Reply-To: <40C6996D.2030405@us.ibm.com> References: <40AC1099.9060007@us.ibm.com> <20040520211613.GA27095@kroah.com> <40AEBB98.5080903@us.ibm.com> <40C4EE87.3000802@us.ibm.com> <20040607222154.GA8232@kroah.com> <40C6996D.2030405@us.ibm.com> Message-ID: <20040612001336.GB10294@kroah.com> On Wed, Jun 09, 2004 at 12:00:29AM -0500, Linda Xie wrote: > Hi Greg, > > Thank you very much for your comments. The attached patch contains > the following fixes. (See my comments below). Applied, thanks. Next time can you please add the proper Signed-off-by: line? thanks, greg k-h ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From lxiep at us.ibm.com Sat Jun 12 10:34:50 2004 From: lxiep at us.ibm.com (Linda Xie) Date: Fri, 11 Jun 2004 19:34:50 -0500 Subject: [Pcihpd-discuss] Re: [PATCH] rpaphp.patch -- multi-function devices not handled correctly In-Reply-To: <1086990113.24732.5.camel@sinatra.austin.ibm.com> References: <40AC1099.9060007@us.ibm.com> <20040520211613.GA27095@kroah.com> <40AEBB98.5080903@us.ibm.com> <40C4EE87.3000802@us.ibm.com> <20040607222154.GA8232@kroah.com> <40C6996D.2030405@us.ibm.com> <1086990113.24732.5.camel@sinatra.austin.ibm.com> Message-ID: <40CA4FAA.3090805@us.ibm.com> John Rose wrote: >Hi Linda- > >I have just one question: > > > >>diff -Nru a/drivers/pci/hotplug/rpadlpar_core.c b/drivers/pci/hotplug/rpadlpar_core.c >>--- a/drivers/pci/hotplug/rpadlpar_core.c Tue Jun 8 22:53:59 2004 >>+++ b/drivers/pci/hotplug/rpadlpar_core.c Tue Jun 8 22:53:59 2004 >>@@ -24,25 +24,6 @@ >> for (child = of_get_next_child(parent, NULL); >>- child; child = of_get_next_child(parent, child)) { >>+ child; child = of_get_next_child(parent, child)) { >> loc_code = get_property(child, "ibm,loc-code", NULL); >>- if (loc_code && !strcmp(loc_code, drc_name)) >>+ if (loc_code && !strncmp(loc_code, drc_name, strlen(drc_name))) >> return child; >> } >> >> >> > >Can you explain why strncmp rather than strcmp? > > The drc-name and loc-code of a virtual device were the same for a while. Things have been changed. For examples: We used to have: U787A.001.100048A-V1-C7(drc-name) , U787A.001.100048A-V1-C7(loc-code) Now we have: U787A.001.100048A-V1-C7(drc-name), U787A.001.100048A-V1-C7-T1(loc-code) So to identify the device_node corresponding to the drc-name passed in, I have to change strcmp to strncmp. (I tested DLPAR VIO on veth(virtual ethernet) and vscsi(virtual scsi) devices.) Thanks, Linda >Other than this, looks good to me! > >Thanks- >John > > >On Wed, 2004-06-09 at 00:00, Linda Xie wrote: > > >>Hi Greg, >> >>Thank you very much for your comments. The attached patch contains >>the following fixes. (See my comments below). >> >>John, your rpadlpar patch has been merged. >> >> >>Linda >> >> > > > >>______________________________________________________________________ >> >> > > > > > > ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olh at suse.de Mon Jun 14 23:31:58 2004 From: olh at suse.de (Olaf Hering) Date: Mon, 14 Jun 2004 15:31:58 +0200 Subject: [PATCH] avoid multiline /proc/cmdline content on iSeries Message-ID: <20040614133158.GA17415@suse.de> /proc/cmdline is filled via an OS400 call iSeries_init(). It scans the returned data from the end, instead of the beginning. This leads to multiple lines in /proc/cmdline Just scan from the beginning and stop at the first newline. This patch changes also the /proc/iSeries/mf/*/cmdline interface to do the same as the initial setup. diff -purN linux-2.6.7-rc3-bk6.orig/arch/ppc64/kernel/iSeries_setup.c linux-2.6.7-rc3-bk6/arch/ppc64/kernel/iSeries_setup.c --- linux-2.6.7-rc3-bk6.orig/arch/ppc64/kernel/iSeries_setup.c 2004-06-14 15:21:47.000000000 +0200 +++ linux-2.6.7-rc3-bk6/arch/ppc64/kernel/iSeries_setup.c 2004-06-14 15:24:32.257675461 +0200 @@ -357,15 +357,14 @@ void __init iSeries_init(unsigned long r HvCallEvent_dmaToSp(cmd_line, 2 * 64* 1024, 256, HvLpDma_Direction_RemoteToLocal); - p = q = cmd_line + 255; - while (p > cmd_line) { - if ((*p == 0) || (*p == ' ') || (*p == '\n')) - --p; - else + p = cmd_line; + q = cmd_line + 255; + while( p < q ) { + if (!*p || *p == '\n') break; + ++p; } - if (p < q) - *(p + 1) = 0; + *p = 0; if (strstr(cmd_line, "dprofile=")) { for (q = cmd_line; (p = strstr(q, "dprofile=")) != 0; ) { diff -purN linux-2.6.7-rc3-bk6.orig/arch/ppc64/kernel/mf_proc.c linux-2.6.7-rc3-bk6/arch/ppc64/kernel/mf_proc.c --- linux-2.6.7-rc3-bk6.orig/arch/ppc64/kernel/mf_proc.c 2004-06-14 15:21:47.000000000 +0200 +++ linux-2.6.7-rc3-bk6/arch/ppc64/kernel/mf_proc.c 2004-06-14 15:24:32.259675139 +0200 @@ -25,33 +25,26 @@ static int proc_mf_dump_cmdline(char *pa { int len = count; char *p; - + + if (off) { + *eof = 1; + return 0; + } + len = mf_getCmdLine(page, &len, (u64)data); - p = page + len - 1; - while (p > page) { - if ((*p == 0) || (*p == ' ')) - --p; - else + p = page; + while (len < (count - 1)) { + if (!*p || *p == '\n') break; + p++; + len++; } - if (*p != '\n') { - ++p; - *p = '\n'; - } - ++p; + *p = '\n'; + p++; *p = 0; - len = p - page; - - len -= off; - if (len < count) { - *eof = 1; - if (len <= 0) - return 0; - } else - len = count; - *start = page + off; - return len; + + return p - page; } #if 0 -- USB is for mice, FireWire is for men! sUse lINUX ag, n?RNBERG ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olof at austin.ibm.com Tue Jun 15 05:57:59 2004 From: olof at austin.ibm.com (Olof Johansson) Date: Mon, 14 Jun 2004 14:57:59 -0500 Subject: [PATCH] PCI PHB unit id detection interface change In-Reply-To: <20040611183232.D12518@forte.austin.ibm.com> References: <20040611183232.D12518@forte.austin.ibm.com> Message-ID: <40CE0347.2000501@austin.ibm.com> linas at austin.ibm.com wrote: >Hi, > >I'm looking for sanity-check/review of the following patch. >Turns out ath the kernel has been using a deprecated firmware >interface for discovring the PCI PHB Unit Id's. The PHN Unit >ID's are used for a variety of PCI operations. The patch >below is a change to use the recommended API. > >Its been tested on one-each of power3,4,and 5 boxes; however, >given that its an API change, I have some concern that someone >might get broken by this. Please review. > Linas, Your code has some CodingStyle breakage. Mostly nitpicky stuff, see below. >------------------------------------------------------------------------ > >Index: arch/ppc64/kernel/pSeries_pci.c >=================================================================== >RCS file: /home/linas/cvsroot/eeh/arch/ppc64/kernel/pSeries_pci.c,v >retrieving revision 1.1 >diff -u -p -r1.1 pSeries_pci.c >--- a/arch/ppc64/kernel/pSeries_pci.c 8 Jun 2004 22:52:54 -0000 1.1 >+++ b/arch/ppc64/kernel/pSeries_pci.c 11 Jun 2004 21:56:41 -0000 >@@ -353,6 +353,55 @@ static void python_countermeasures(unsig > iounmap(chip_regs); > } > >+void init_pci_config_tokens (void) > Should this be __init? >+{ >+ read_pci_config = rtas_token("read-pci-config"); >+ write_pci_config = rtas_token("write-pci-config"); >+ ibm_read_pci_config = rtas_token("ibm,read-pci-config"); >+ ibm_write_pci_config = rtas_token("ibm,write-pci-config"); >+} >+ >+unsigned long get_phb_buid (struct device_node *phb) >+{ >+ int addr_cells; >+ unsigned int *buid_vals; >+ unsigned int len; >+ unsigned long buid; >+ >+#define NEW_STYLE_BUIDS >+#ifdef NEW_STYLE_BUIDS >+ if (-1 == ibm_read_pci_config) return 0; >+ >+ /* PHB's will always be children of the root node, >+ * or so it is promised by the current firmware. */ >+ if (NULL == phb->parent) return 0; > It's common practice in the Linux kernel to do tests in form ( == ). Good compilers should warn about missing equal signs anyway. :) >+ if (phb->parent->parent) return 0; >+ >+ buid_vals = (unsigned int *) get_property(phb, "reg", &len); >+ if (NULL == buid_vals) return 0; > Break if statements into two lines, please, all 4 above Also, another constant == variable check >+ >+ addr_cells = prom_n_addr_cells(phb); >+ if (addr_cells == 1) { >+ buid = (unsigned long) buid_vals[0]; >+ } else { >+ buid = (((unsigned long)buid_vals[0]) << 32UL) | >+ (((unsigned long)buid_vals[1]) & 0xffffffff); >+ } >+#else >+ // The use of ibm,fw-phb-id is deprecated. Keep a copy of this >+ // code for reference, in case the above code needs to be rolled back. > Please stick to C-style comments, i.e. /* */ Also, revision control is good enough to track old code for reference, instead of keeping it cluttered with #ifdefs. So please take out the old code alltogether. >+ buid_vals = (int *) get_property(phb, "ibm,fw-phb-id", &len); >+ if (buid_vals == NULL) return 0; > break in two lines >+ if (len < 2 * sizeof(int)) { >+ buid = (unsigned long) buid_vals[0]; >+ } else { >+ buid = (((unsigned long)buid_vals[0]) << 32UL) | >+ (((unsigned long)buid_vals[1]) & 0xffffffff); >+ } >+#endif >+ return buid; >+} >+ > struct pci_controller *alloc_phb(struct device_node *dev, > unsigned int addr_size_words) > { >@@ -360,7 +409,6 @@ struct pci_controller *alloc_phb(struct > unsigned int *ui_ptr = NULL, len; > struct reg_property64 reg_struct; > int *bus_range; >- int *buid_vals; > char *model; > enum phb_types phb_type; > struct property *of_prop; >@@ -431,18 +479,7 @@ struct pci_controller *alloc_phb(struct > phb->arch_data = dev; > phb->ops = &rtas_pci_ops; > >- buid_vals = (int *) get_property(dev, "ibm,fw-phb-id", &len); >- >- if (buid_vals == NULL) { >- phb->buid = 0; >- } else { >- if (len < 2 * sizeof(int)) >- // Support for new OF that only has 1 integer for buid. >- phb->buid = (unsigned long)buid_vals[0]; >- else >- phb->buid = (((unsigned long)buid_vals[0]) << 32UL) | >- (((unsigned long)buid_vals[1]) & 0xffffffff); >- } >+ phb->buid = get_phb_buid (dev); > Take out space between function name and () > > return phb; > } >@@ -456,10 +493,7 @@ unsigned long __init find_and_init_phbs( > unsigned int *opprop; > struct device_node *root = of_find_node_by_path("/"); > >- read_pci_config = rtas_token("read-pci-config"); >- write_pci_config = rtas_token("write-pci-config"); >- ibm_read_pci_config = rtas_token("ibm,read-pci-config"); >- ibm_write_pci_config = rtas_token("ibm,write-pci-config"); >+ init_pci_config_tokens(); > > if (naca->interrupt_controller == IC_OPEN_PIC) { > opprop = (unsigned int *)get_property(root, >--- arch/ppc64/kernel/eeh.c.7.69-orig 2004-06-11 14:10:19.000000000 -0500 >+++ arch/ppc64/kernel/eeh.c 2004-06-11 16:50:55.000000000 -0500 >@@ -40,6 +40,10 @@ > #define CONFIG_ADDR(busno, devfn) \ > (((((busno) & 0xff) << 8) | ((devfn) & 0xf8)) << 8) > >+/* From pSeries_pci.h */ >+extern void init_pci_config_tokens (void); >+extern unsigned long get_phb_buid (struct device_node *); >+ > > /* RTAS tokens */ > static int ibm_set_eeh_option; > static int ibm_set_slot_reset; >@@ -645,7 +649,7 @@ static void *early_enable_eeh(struct dev > dn->full_name); > #endif > } else { >- printk(KERN_WARNING "EEH: %s: rtas_call failed.\n", >+ printk(KERN_WARNING "EEH: %s: could not enable EEH, rtas_call failed.\n", > dn->full_name); > } > } else { >@@ -709,24 +713,16 @@ void __init eeh_init(void) > } > > /* Enable EEH for all adapters. Note that eeh requires buid's */ >+ init_pci_config_tokens(); > Why do you need this here? Is EEH code ever called before find_and_init_phbs? If so, can't you make the init_pci_config_tokens() an early_initcall() to avoid calling it twice? > for (phb = of_find_node_by_name(NULL, "pci"); phb; > phb = of_find_node_by_name(phb, "pci")) { >- int len; >- int *buid_vals; >+ unsigned long buid; > >- buid_vals = (int *)get_property(phb, "ibm,fw-phb-id", &len); >- if (!buid_vals) >- continue; >- if (len == sizeof(int)) { >- info.buid_lo = buid_vals[0]; >- info.buid_hi = 0; >- } else if (len == sizeof(int)*2) { >- info.buid_hi = buid_vals[0]; >- info.buid_lo = buid_vals[1]; >- } else { >- printk(KERN_INFO "EEH: odd ibm,fw-phb-id len returned: %d\n", len); >- continue; >- } >+ buid = get_phb_buid (phb); >+ if (0 == buid) continue; > break in two lines >+ >+ info.buid_lo = BUID_LO(buid); >+ info.buid_hi = BUID_HI(buid); > traverse_pci_devices(phb, early_enable_eeh, NULL, &info); > } > > > ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From linas at austin.ibm.com Tue Jun 15 07:17:03 2004 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Mon, 14 Jun 2004 16:17:03 -0500 Subject: [PATCH] PCI PHB unit id detection interface change In-Reply-To: <40CE0347.2000501@austin.ibm.com>; from olof@austin.ibm.com on Mon, Jun 14, 2004 at 02:57:59PM -0500 References: <20040611183232.D12518@forte.austin.ibm.com> <40CE0347.2000501@austin.ibm.com> Message-ID: <20040614161703.B21962@forte.austin.ibm.com> Hi Olof, Thanks, On Mon, Jun 14, 2004 at 02:57:59PM -0500, Olof Johansson wrote: > > > >+void init_pci_config_tokens (void) > > > Should this be __init? Yes, I missed that. > >+ if (NULL == phb->parent) return 0; > > > It's common practice in the Linux kernel to do tests in form ( > == ). Good compilers should warn about missing equal signs > anyway. :) Yes, 'should' being the operative word in that sentance :). I'd like to convince the world to change its coding style; no luck so far... > >+ if (NULL == buid_vals) return 0; > > > Break if statements into two lines, please, all 4 above Yes, this is another one that bugs me. I know this is not the kernel coding style but the style I like is "use {} if its more than one line". I have debugged code that looked like this if (x) if (y) p; else q; and have come to beleieve that the "one line or use {}" rule is the best. I have also seen people that took code that worked: if (x) p; And change it to the following if (x) q; p; when the reallly meant if (x) { q; p; } and so I've come to beleive that the 'one-line-rule' is better. Of course, I want to say that kernel programmers are usually smarter than the rest, but, if that were the really the case, we wouldn't need tools like 'sparse', right? > Take out space between function name and () Done. > > /* Enable EEH for all adapters. Note that eeh requires buid's */ > >+ init_pci_config_tokens(); > > > > Why do you need this here? Is EEH code ever called before > find_and_init_phbs? yes, in fact, its called immediately before. I think the idea is that one must not access any pci spaces until eeh is enabled first. > If so, can't you make the init_pci_config_tokens() > an early_initcall() to avoid calling it twice? I called it twice out of a sense of paranoia. I'll fix that. What is early_initcall? --linas ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From linas at austin.ibm.com Tue Jun 15 07:28:11 2004 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Mon, 14 Jun 2004 16:28:11 -0500 Subject: [PATCH] PCI PHB unit id detection interface change In-Reply-To: <40CE0347.2000501@austin.ibm.com>; from olof@austin.ibm.com on Mon, Jun 14, 2004 at 02:57:59PM -0500 References: <20040611183232.D12518@forte.austin.ibm.com> <40CE0347.2000501@austin.ibm.com> Message-ID: <20040614162811.C21962@forte.austin.ibm.com> On Mon, Jun 14, 2004 at 02:57:59PM -0500, Olof Johansson wrote: > > > >I'm looking for sanity-check/review of the following patch. > >Turns out ath the kernel has been using a deprecated firmware > >interface for discovring the PCI PHB Unit Id's. The PHN Unit > >ID's are used for a variety of PCI operations. The patch > >below is a change to use the recommended API. > > > >Its been tested on one-each of power3,4,and 5 boxes; however, > >given that its an API change, I have some concern that someone > >might get broken by this. Please review. > > Your code has some CodingStyle breakage. Mostly nitpicky stuff, see below. Reviesed, cleaned patch attached. --linas -------------- next part -------------- Index: arch/ppc64/kernel/pSeries_pci.c =================================================================== RCS file: /home/linas/cvsroot/eeh/arch/ppc64/kernel/pSeries_pci.c,v retrieving revision 1.1 diff -u -p -r1.1 pSeries_pci.c --- a/arch/ppc64/kernel/pSeries_pci.c 8 Jun 2004 22:52:54 -0000 1.1 +++ b/arch/ppc64/kernel/pSeries_pci.c 14 Jun 2004 21:21:33 -0000 @@ -353,6 +353,44 @@ static void python_countermeasures(unsig iounmap(chip_regs); } +void __init init_pci_config_tokens (void) +{ + read_pci_config = rtas_token("read-pci-config"); + write_pci_config = rtas_token("write-pci-config"); + ibm_read_pci_config = rtas_token("ibm,read-pci-config"); + ibm_write_pci_config = rtas_token("ibm,write-pci-config"); +} + +unsigned long __init get_phb_buid (struct device_node *phb) +{ + int addr_cells; + unsigned int *buid_vals; + unsigned int len; + unsigned long buid; + + if (ibm_read_pci_config == -1) return 0; + + /* PHB's will always be children of the root node, + * or so it is promised by the current firmware. */ + if (phb->parent == NULL) + return 0; + if (phb->parent->parent) + return 0; + + buid_vals = (unsigned int *) get_property(phb, "reg", &len); + if (buid_vals == NULL) + return 0; + + addr_cells = prom_n_addr_cells(phb); + if (addr_cells == 1) { + buid = (unsigned long) buid_vals[0]; + } else { + buid = (((unsigned long)buid_vals[0]) << 32UL) | + (((unsigned long)buid_vals[1]) & 0xffffffff); + } + return buid; +} + struct pci_controller *alloc_phb(struct device_node *dev, unsigned int addr_size_words) { @@ -360,7 +398,6 @@ struct pci_controller *alloc_phb(struct unsigned int *ui_ptr = NULL, len; struct reg_property64 reg_struct; int *bus_range; - int *buid_vals; char *model; enum phb_types phb_type; struct property *of_prop; @@ -431,18 +468,7 @@ struct pci_controller *alloc_phb(struct phb->arch_data = dev; phb->ops = &rtas_pci_ops; - buid_vals = (int *) get_property(dev, "ibm,fw-phb-id", &len); - - if (buid_vals == NULL) { - phb->buid = 0; - } else { - if (len < 2 * sizeof(int)) - // Support for new OF that only has 1 integer for buid. - phb->buid = (unsigned long)buid_vals[0]; - else - phb->buid = (((unsigned long)buid_vals[0]) << 32UL) | - (((unsigned long)buid_vals[1]) & 0xffffffff); - } + phb->buid = get_phb_buid(dev); return phb; } @@ -456,11 +482,6 @@ unsigned long __init find_and_init_phbs( unsigned int *opprop; struct device_node *root = of_find_node_by_path("/"); - read_pci_config = rtas_token("read-pci-config"); - write_pci_config = rtas_token("write-pci-config"); - ibm_read_pci_config = rtas_token("ibm,read-pci-config"); - ibm_write_pci_config = rtas_token("ibm,write-pci-config"); - if (naca->interrupt_controller == IC_OPEN_PIC) { opprop = (unsigned int *)get_property(root, "platform-open-pic", NULL); --- arch/ppc64/kernel/eeh.c.7.69-orig 2004-06-11 14:10:19.000000000 -0500 +++ arch/ppc64/kernel/eeh.c 2004-06-14 16:17:55.000000000 -0500 @@ -40,6 +40,10 @@ #define CONFIG_ADDR(busno, devfn) \ (((((busno) & 0xff) << 8) | ((devfn) & 0xf8)) << 8) +/* From pSeries_pci.h */ +extern void init_pci_config_tokens (void); +extern unsigned long get_phb_buid (struct device_node *); + /* RTAS tokens */ static int ibm_set_eeh_option; static int ibm_set_slot_reset; @@ -645,7 +649,7 @@ static void *early_enable_eeh(struct dev dn->full_name); #endif } else { - printk(KERN_WARNING "EEH: %s: rtas_call failed.\n", + printk(KERN_WARNING "EEH: %s: could not enable EEH, rtas_call failed.\n", dn->full_name); } } else { @@ -709,24 +713,17 @@ void __init eeh_init(void) } /* Enable EEH for all adapters. Note that eeh requires buid's */ + init_pci_config_tokens(); for (phb = of_find_node_by_name(NULL, "pci"); phb; phb = of_find_node_by_name(phb, "pci")) { - int len; - int *buid_vals; + unsigned long buid; - buid_vals = (int *)get_property(phb, "ibm,fw-phb-id", &len); - if (!buid_vals) - continue; - if (len == sizeof(int)) { - info.buid_lo = buid_vals[0]; - info.buid_hi = 0; - } else if (len == sizeof(int)*2) { - info.buid_hi = buid_vals[0]; - info.buid_lo = buid_vals[1]; - } else { - printk(KERN_INFO "EEH: odd ibm,fw-phb-id len returned: %d\n", len); + buid = get_phb_buid(phb); + if (buid == 0) continue; - } + + info.buid_lo = BUID_LO(buid); + info.buid_hi = BUID_HI(buid); traverse_pci_devices(phb, early_enable_eeh, NULL, &info); } From olof at austin.ibm.com Tue Jun 15 07:41:00 2004 From: olof at austin.ibm.com (Olof Johansson) Date: Mon, 14 Jun 2004 16:41:00 -0500 Subject: [PATCH] PCI PHB unit id detection interface change In-Reply-To: <20040614161703.B21962@forte.austin.ibm.com> References: <20040611183232.D12518@forte.austin.ibm.com> <40CE0347.2000501@austin.ibm.com> <20040614161703.B21962@forte.austin.ibm.com> Message-ID: <40CE1B6C.3090400@austin.ibm.com> linas at austin.ibm.com wrote: >>If so, can't you make the init_pci_config_tokens() >>an early_initcall() to avoid calling it twice? >> >> > >I called it twice out of a sense of paranoia. I'll fix that. >What is early_initcall? > > Nevermind, I was thinking of arch_initcall(). Either way, just take out one of them. -Olof ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Wed Jun 16 06:48:58 2004 From: anton at samba.org (Anton Blanchard) Date: Wed, 16 Jun 2004 06:48:58 +1000 Subject: [PATCH] PCI PHB unit id detection interface change In-Reply-To: <20040611183232.D12518@forte.austin.ibm.com> References: <20040611183232.D12518@forte.austin.ibm.com> Message-ID: <20040615204858.GA3228@krispykreme> Hi Linas, > I'm looking for sanity-check/review of the following patch. > Turns out ath the kernel has been using a deprecated firmware > interface for discovring the PCI PHB Unit Id's. The PHN Unit > ID's are used for a variety of PCI operations. The patch > below is a change to use the recommended API. Ouch. > Its been tested on one-each of power3,4,and 5 boxes; however, > given that its an API change, I have some concern that someone > might get broken by this. Please review. A few suggestions on top of Olafs comments. > +void init_pci_config_tokens (void) Can be marked static. > +#define NEW_STYLE_BUIDS > +#ifdef NEW_STYLE_BUIDS We are going to need to test this rather extensively, so once that is done we dont need to keep the old broken version. > +/* From pSeries_pci.h */ > +extern void init_pci_config_tokens (void); > +extern unsigned long get_phb_buid (struct device_node *); Prototypes should into a .h file, Ive been bitten by throwing prototypes into .c files before. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From linas at austin.ibm.com Wed Jun 16 07:23:55 2004 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Tue, 15 Jun 2004 16:23:55 -0500 Subject: [PATCH] PCI PHB unit id detection interface change In-Reply-To: <20040615204858.GA3228@krispykreme>; from anton@samba.org on Wed, Jun 16, 2004 at 06:48:58AM +1000 References: <20040611183232.D12518@forte.austin.ibm.com> <20040615204858.GA3228@krispykreme> Message-ID: <20040615162355.E21962@forte.austin.ibm.com> On Wed, Jun 16, 2004 at 06:48:58AM +1000, Anton Blanchard wrote: > > > +/* From pSeries_pci.h */ > > +extern void init_pci_config_tokens (void); > > +extern unsigned long get_phb_buid (struct device_node *); > > Prototypes should into a .h file, Ive been bitten by throwing prototypes > into .c files before. Sorry, yes, I cringed when I did that; I don't know what I was thinking. I have no excuse. I'll fix it up. --linas ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olof at austin.ibm.com Wed Jun 16 08:08:36 2004 From: olof at austin.ibm.com (Olof Johansson) Date: Tue, 15 Jun 2004 17:08:36 -0500 Subject: [PATCH] PCI PHB unit id detection interface change In-Reply-To: <20040614162811.C21962@forte.austin.ibm.com> References: <20040611183232.D12518@forte.austin.ibm.com> <40CE0347.2000501@austin.ibm.com> <20040614162811.C21962@forte.austin.ibm.com> Message-ID: <40CF7364.2010408@austin.ibm.com> linas at austin.ibm.com wrote: >Reviesed, cleaned patch attached. > > Linas, one more thing: alloc_phb is not __init, but find_phb_buid is, and alloc_phb calls it. Either both or neither sould be __init, right? John, do you need alloc_phb at runtime for hotplug? -Olof ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From johnrose at austin.ibm.com Wed Jun 16 08:11:32 2004 From: johnrose at austin.ibm.com (John Rose) Date: Tue, 15 Jun 2004 17:11:32 -0500 Subject: [PATCH] PCI PHB unit id detection interface change In-Reply-To: <40CF7364.2010408@austin.ibm.com> References: <20040611183232.D12518@forte.austin.ibm.com> <40CE0347.2000501@austin.ibm.com> <20040614162811.C21962@forte.austin.ibm.com> <40CF7364.2010408@austin.ibm.com> Message-ID: <1087337492.3094.29.camel@sinatra.austin.ibm.com> Hi Olof- On Tue, 2004-06-15 at 17:08, Olof Johansson wrote: > John, do you need alloc_phb at runtime for hotplug? I will soon. I'm currently implementing PHB-level DLPAR, and this involves calling alloc_phb at runtime. John ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From linas at austin.ibm.com Wed Jun 16 08:44:36 2004 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Tue, 15 Jun 2004 17:44:36 -0500 Subject: [PATCH] PCI PHB unit id detection interface change In-Reply-To: <40CF7364.2010408@austin.ibm.com>; from olof@austin.ibm.com on Tue, Jun 15, 2004 at 05:08:36PM -0500 References: <20040611183232.D12518@forte.austin.ibm.com> <40CE0347.2000501@austin.ibm.com> <20040614162811.C21962@forte.austin.ibm.com> <40CF7364.2010408@austin.ibm.com> Message-ID: <20040615174436.F21962@forte.austin.ibm.com> On Tue, Jun 15, 2004 at 05:08:36PM -0500, Olof Johansson wrote: > linas at austin.ibm.com wrote: > > >Reviesed, cleaned patch attached. > > > > > Linas, one more thing: alloc_phb is not __init, but find_phb_buid is, > and alloc_phb calls it. Either both or neither sould be __init, right? Yes, a grep of the current code indicates that alloc_phb() should have been declared static __init > John, do you need alloc_phb at runtime for hotplug? I'm guessing he does (John == John Rose) --linas ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olh at suse.de Thu Jun 17 19:14:17 2004 From: olh at suse.de (Olaf Hering) Date: Thu, 17 Jun 2004 11:14:17 +0200 Subject: [PATCH] PCI PHB unit id detection interface change In-Reply-To: <20040611183232.D12518@forte.austin.ibm.com> References: <20040611183232.D12518@forte.austin.ibm.com> Message-ID: <20040617091417.GA23808@suse.de> On Fri, Jun 11, linas at austin.ibm.com wrote: > @@ -456,10 +493,7 @@ unsigned long __init find_and_init_phbs( > unsigned int *opprop; > struct device_node *root = of_find_node_by_path("/"); > > - read_pci_config = rtas_token("read-pci-config"); > - write_pci_config = rtas_token("write-pci-config"); > - ibm_read_pci_config = rtas_token("ibm,read-pci-config"); > - ibm_write_pci_config = rtas_token("ibm,write-pci-config"); > + init_pci_config_tokens(); > > if (naca->interrupt_controller == IC_OPEN_PIC) { > opprop = (unsigned int *)get_property(root, > @@ -709,24 +713,16 @@ void __init eeh_init(void) > } > > /* Enable EEH for all adapters. Note that eeh requires buid's */ > + init_pci_config_tokens(); > for (phb = of_find_node_by_name(NULL, "pci"); phb; > phb = of_find_node_by_name(phb, "pci")) { this is broken. You rely on EEH being available. all power3 users will have a problem now. -- USB is for mice, FireWire is for men! sUse lINUX ag, n?RNBERG ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olh at suse.de Thu Jun 17 22:55:03 2004 From: olh at suse.de (Olaf Hering) Date: Thu, 17 Jun 2004 14:55:03 +0200 Subject: [PATCH] PCI PHB unit id detection interface change In-Reply-To: <20040617091417.GA23808@suse.de> References: <20040611183232.D12518@forte.austin.ibm.com> <20040617091417.GA23808@suse.de> Message-ID: <20040617125503.GA8179@suse.de> On Thu, Jun 17, Olaf Hering wrote: > > On Fri, Jun 11, linas at austin.ibm.com wrote: > > > @@ -456,10 +493,7 @@ unsigned long __init find_and_init_phbs( > > unsigned int *opprop; > > struct device_node *root = of_find_node_by_path("/"); > > > > - read_pci_config = rtas_token("read-pci-config"); > > - write_pci_config = rtas_token("write-pci-config"); > > - ibm_read_pci_config = rtas_token("ibm,read-pci-config"); > > - ibm_write_pci_config = rtas_token("ibm,write-pci-config"); > > + init_pci_config_tokens(); > > > > if (naca->interrupt_controller == IC_OPEN_PIC) { > > opprop = (unsigned int *)get_property(root, > > > @@ -709,24 +713,16 @@ void __init eeh_init(void) > > } > > > > /* Enable EEH for all adapters. Note that eeh requires buid's */ > > + init_pci_config_tokens(); > > for (phb = of_find_node_by_name(NULL, "pci"); phb; > > phb = of_find_node_by_name(phb, "pci")) { > > this is broken. You rely on EEH being available. all power3 users will > have a problem now. this one should work better. --- ./arch/ppc64/kernel/eeh.c~ 2004-06-17 10:53:59.876818306 +0000 +++ ./arch/ppc64/kernel/eeh.c 2004-06-17 12:05:04.798698425 +0000 @@ -679,6 +679,8 @@ void __init eeh_init(void) printk(KERN_WARNING "EEH: RTAS not found !\n"); return; } + + init_pci_config_tokens(); ibm_set_eeh_option = rtas_token("ibm,set-eeh-option"); ibm_set_slot_reset = rtas_token("ibm,set-slot-reset"); @@ -707,7 +709,6 @@ void __init eeh_init(void) } /* Enable EEH for all adapters. Note that eeh requires buid's */ - init_pci_config_tokens(); for (phb = of_find_node_by_name(NULL, "pci"); phb; phb = of_find_node_by_name(phb, "pci")) { unsigned long buid; -- USB is for mice, FireWire is for men! sUse lINUX ag, n?RNBERG ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From linas at austin.ibm.com Fri Jun 18 02:01:54 2004 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Thu, 17 Jun 2004 11:01:54 -0500 Subject: [PATCH] PCI PHB unit id detection interface change In-Reply-To: <20040617125503.GA8179@suse.de>; from olh@suse.de on Thu, Jun 17, 2004 at 02:55:03PM +0200 References: <20040611183232.D12518@forte.austin.ibm.com> <20040617091417.GA23808@suse.de> <20040617125503.GA8179@suse.de> Message-ID: <20040617110153.G21962@forte.austin.ibm.com> On Thu, Jun 17, 2004 at 02:55:03PM +0200, Olaf Hering wrote: > this one should work better. Yes, that is correct. I tested an earlier patch on pwer3, and it worked: the earlier patch had two calls to init_pci_config_tokens(), one of which got called on pwer3. But two calls seemed like one too many, and the one that got yanked was the one that was needed by power3. Sorry, I'm not sure why I'm being so error prone these days. --linas ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From linas at austin.ibm.com Fri Jun 18 08:11:15 2004 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Thu, 17 Jun 2004 17:11:15 -0500 Subject: [PATCH] minor rpaphp_pci.c patch Message-ID: <20040617171115.M21962@forte.austin.ibm.com> Hi Linda, Could you apply the attached patch to the rpaphp_pci.c code? Its a minor tweak that should not affect anything currently, but it helps getting some of my development code working correctly. --linas -------------- next part -------------- Index: drivers/pci/hotplug/rpaphp_pci.c =================================================================== RCS file: /home/linas/cvsroot/eeh/drivers/pci/hotplug/rpaphp_pci.c,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- a/drivers/pci/hotplug/rpaphp_pci.c 16 Jun 2004 19:00:55 -0000 1.1 +++ b/drivers/pci/hotplug/rpaphp_pci.c 16 Jun 2004 19:03:32 -0000 1.2 @@ -284,8 +284,8 @@ int rpaphp_unconfig_pci_adapter(struct s goto exit; } /* remove the device from the pci core */ - eeh_remove_device(slot->dev.pci_dev); pci_remove_bus_device(slot->dev.pci_dev); + eeh_remove_device(slot->dev.pci_dev); slot->state = NOT_CONFIGURED; info("%s: adapter in slot[%s] unconfigured.\n", __FUNCTION__, From sfr at au1.ibm.com Sun Jun 20 01:57:30 2004 From: sfr at au1.ibm.com (Stephen Rothwell) Date: Sun, 20 Jun 2004 01:57:30 +1000 Subject: Probing of iSeries devices with the 2.6 kernel, redux (bz122560) In-Reply-To: <20040619155016.4811b6dc.sfr@au.ibm.com> References: <1087505977.13370.14.camel@bree.local.net> <20040618084836.4f96f988.sfr@au.ibm.com> <1087514412.13370.24.camel@bree.local.net> <20040618134857.27cc7191.sfr@au.ibm.com> <1087531275.13370.62.camel@bree.local.net> <20040618153047.6e32cd9e.sfr@au.ibm.com> <20040619112949.671c4924.sfr@au.ibm.com> <1087623390.21082.1.camel@bree.local.net> <20040619155016.4811b6dc.sfr@au.ibm.com> Message-ID: <20040620015730.0e1a79be.sfr@au.ibm.com> On Sat, 19 Jun 2004 15:50:16 +1000 Stephen Rothwell wrote: > > This bug has been raised to "ship issue" on our side, so I will be working > on it over the weekend. Expect another patch. Unfortunately, the patch > is getting large - it needs infrastructure for all the sysfs stuff. Attached is another patch. It is against the Ameslab tree which should be pretty close to 2.6 upstream. I have cut it down as much as possible by removing a whole lot of cleanups I had in there. OK, this is what the patch does. All the iSeries virtual devices now appear in /sys/devices/vio and /sys/bus/vio/devices. Unfortunately, apart from the veth devices, there are all possible devices there at the moment - I need to think about how to reduce it but that requires moving all the probe code into vio.c ... However, in /sys/bus/drivers//, the only devices listed are the ones actually there. veth devices are symlinked from /sys/class/net/eth. viodasd devices are linked from /sys/block//device. As are viocds. viotape devices are linked from /sys/class/tape/. Suggestions welcome. I will put this in bugzilla as well. -- Cheers, Stephen Rothwell sfr at au.ibm.com IBM OzLabs Linux Technology Centre -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ames.ivio.1.diff Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20040620/8ac85e6d/attachment.txt From katzj at redhat.com Sun Jun 20 05:39:17 2004 From: katzj at redhat.com (Jeremy Katz) Date: Sat, 19 Jun 2004 15:39:17 -0400 Subject: Probing of iSeries devices with the 2.6 kernel, redux (bz122560) In-Reply-To: <20040620015730.0e1a79be.sfr@au.ibm.com> References: <1087505977.13370.14.camel@bree.local.net> <20040618084836.4f96f988.sfr@au.ibm.com> <1087514412.13370.24.camel@bree.local.net> <20040618134857.27cc7191.sfr@au.ibm.com> <1087531275.13370.62.camel@bree.local.net> <20040618153047.6e32cd9e.sfr@au.ibm.com> <20040619112949.671c4924.sfr@au.ibm.com> <1087623390.21082.1.camel@bree.local.net> <20040619155016.4811b6dc.sfr@au.ibm.com> <20040620015730.0e1a79be.sfr@au.ibm.com> Message-ID: <1087673957.21082.5.camel@bree.local.net> On Sun, 2004-06-20 at 01:57 +1000, Stephen Rothwell wrote: > OK, this is what the patch does. All the iSeries virtual devices now > appear in /sys/devices/vio and /sys/bus/vio/devices. Unfortunately, > apart from the veth devices, there are all possible devices there at > the moment - I need to think about how to reduce it but that requires > moving all the probe code into vio.c ... [snip] > Suggestions welcome. I will put this in bugzilla as well. Thanks, I'll take a look at this as soon as I can. Jeremy ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From akpm at osdl.org Sun Jun 20 20:02:45 2004 From: akpm at osdl.org (akpm at osdl.org) Date: Sun, 20 Jun 2004 03:02:45 -0700 Subject: [patch 1/2] ppc64 CONFIG_ALTIVEC=n build fix Message-ID: <200406201003.i5KA3br30463@mail.osdl.org> With CONFIG_ALTIVEC=n, flush_altivec_to_thread() has no implementation. Signed-off-by: Andrew Morton --- 25-power4-akpm/include/asm-ppc64/system.h | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletion(-) diff -puN include/asm-ppc64/system.h~ppc64-build-fix include/asm-ppc64/system.h --- 25-power4/include/asm-ppc64/system.h~ppc64-build-fix 2004-06-19 22:43:04.795360984 -0700 +++ 25-power4-akpm/include/asm-ppc64/system.h 2004-06-19 22:43:52.956039448 -0700 @@ -112,13 +112,21 @@ extern int _get_PVR(void); extern void giveup_fpu(struct task_struct *); extern void disable_kernel_fp(void); extern void flush_fp_to_thread(struct task_struct *); -extern void flush_altivec_to_thread(struct task_struct *); extern void enable_kernel_fp(void); extern void giveup_altivec(struct task_struct *); extern void disable_kernel_altivec(void); extern void enable_kernel_altivec(void); extern void cvt_fd(float *from, double *to, unsigned long *fpscr); extern void cvt_df(double *from, float *to, unsigned long *fpscr); + +#ifdef CONFIG_ALTIVEC +extern void flush_altivec_to_thread(struct task_struct *); +#else +static inline void flush_altivec_to_thread(struct task_struct *t) +{ +} +#endif + extern int abs(int); extern struct task_struct *__switch_to(struct task_struct *, _ ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From akpm at osdl.org Sun Jun 20 20:02:48 2004 From: akpm at osdl.org (akpm at osdl.org) Date: Sun, 20 Jun 2004 03:02:48 -0700 Subject: [patch 2/2] ppc64: eeh.h warning-fix Message-ID: <200406201003.i5KA3er30473@mail.osdl.org> In file included from include/asm/io.h:365, from drivers/video/kyro/STG4000Reg.h:23, from drivers/video/kyro/STG4000Ramdac.c:16: include/asm/eeh.h:58: warning: `struct device_node' declared inside parameter list include/asm/eeh.h:58: warning: its scope is only this definition or declaration, which is probably not what you want Signed-off-by: Andrew Morton --- 25-sparc64-akpm/include/asm-ppc64/eeh.h | 1 + 1 files changed, 1 insertion(+) diff -puN include/asm-ppc64/eeh.h~ppc64-eeh-warning-fix include/asm-ppc64/eeh.h --- 25-sparc64/include/asm-ppc64/eeh.h~ppc64-eeh-warning-fix 2004-06-19 23:41:18.412250488 -0700 +++ 25-sparc64-akpm/include/asm-ppc64/eeh.h 2004-06-19 23:41:41.241779872 -0700 @@ -55,6 +55,7 @@ void __init pci_addr_cache_build(void); * device (including config space i/o). Call eeh_add_device_late * to finish the eeh setup for this device. */ +struct device_node; void eeh_add_device_early(struct device_node *); void eeh_add_device_late(struct pci_dev *); _ ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From paulus at samba.org Mon Jun 21 08:05:34 2004 From: paulus at samba.org (Paul Mackerras) Date: Mon, 21 Jun 2004 08:05:34 +1000 Subject: [patch 1/2] ppc64 CONFIG_ALTIVEC=n build fix In-Reply-To: <200406201003.i5KA3br30463@mail.osdl.org> References: <200406201003.i5KA3br30463@mail.osdl.org> Message-ID: <16598.2606.955964.43196@cargo.ozlabs.ibm.com> akpm at osdl.org writes: > With CONFIG_ALTIVEC=n, flush_altivec_to_thread() has no implementation. Aargh, I thought I fixed that, sorry. Anyway, your patch looks fine. Paul. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From david at gibson.dropbear.id.au Mon Jun 21 16:08:44 2004 From: david at gibson.dropbear.id.au (David Gibson) Date: Mon, 21 Jun 2004 16:08:44 +1000 Subject: Abolish per-CPU RTAS args Message-ID: <20040621060844.GA32294@zax> Currently we store RTAS arguments in the PACA. The args have to be in the RMO, but since we have a global spinlock for RTAS anyway, there's no reason to have a separate copy of the args per-CPU. This patch replaces the PACA field with a single instance in the global rtas structure. The one exception is for the rtas_stop_self() call, which can't take the lock, because it never returns. But it has a fixed set of arguments, so we can use another global instance which is initialized at boot. This lets us remove rtas.h from paca.h, which substantially reduces overall #include hairiness (because paca.h is now, as it wants to be, a nice low-level structure-defining header which relies on very little and can safely be included almost anywhere). Although it does add some noise to the patch, because a bunch of places relied on the indirect inclusion of rtas.h, or even more indirect inclusions (see the hunks applying to eeh.h and current.h!). Does this seem like a good idea? Index: working-2.6/arch/ppc64/kernel/rtas.c =================================================================== --- working-2.6.orig/arch/ppc64/kernel/rtas.c 2004-06-21 11:29:19.000000000 +1000 +++ working-2.6/arch/ppc64/kernel/rtas.c 2004-06-21 15:31:12.970318312 +1000 @@ -68,11 +68,10 @@ void call_rtas_display_status(char c) { - struct rtas_args *args; + struct rtas_args *args = &rtas.args; unsigned long s; spin_lock_irqsave(&rtas.lock, s); - args = &(get_paca()->xRtas); args->token = 10; args->nargs = 1; @@ -113,15 +112,15 @@ err_args.args[2] = 0; temp_args = *rtas_args; - get_paca()->xRtas = err_args; + rtas.args = err_args; PPCDBG(PPCDBG_RTAS, "\tentering rtas with 0x%lx\n", __pa(&err_args)); - enter_rtas(__pa(&get_paca()->xRtas)); + enter_rtas(__pa(&rtas.args)); PPCDBG(PPCDBG_RTAS, "\treturned from rtas ...\n"); - err_args = get_paca()->xRtas; - get_paca()->xRtas = temp_args; + err_args = rtas.args; + rtas.args = temp_args; return err_args.rets[0]; } @@ -159,7 +158,7 @@ /* Gotta do something different here, use global lock for now... */ spin_lock_irqsave(&rtas.lock, s); - rtas_args = &(get_paca()->xRtas); + rtas_args = &rtas.args; rtas_args->token = token; rtas_args->nargs = nargs; @@ -481,9 +480,9 @@ spin_lock_irqsave(&rtas.lock, flags); - get_paca()->xRtas = args; - enter_rtas(__pa(&get_paca()->xRtas)); - args = get_paca()->xRtas; + rtas.args = args; + enter_rtas(__pa(&rtas.args)); + args = rtas.args; spin_unlock_irqrestore(&rtas.lock, flags); @@ -501,19 +500,23 @@ } #ifdef CONFIG_HOTPLUG_CPU -/* This version can't take the spinlock. */ +/* This version can't take the spinlock, because it never returns */ + +struct rtas_args rtas_stop_self_args = { + /* The token is initialized for real in setup_system() */ + .token = RTAS_UNKNOWN_SERVICE, + .nargs = 0, + .nret = 1, + .rets = &rtas_stop_self_args.args[0], +}; void rtas_stop_self(void) { - struct rtas_args *rtas_args = &(get_paca()->xRtas); + struct rtas_args *rtas_args = &rtas_stop_self_args; local_irq_disable(); - rtas_args->token = rtas_token("stop-self"); BUG_ON(rtas_args->token == RTAS_UNKNOWN_SERVICE); - rtas_args->nargs = 0; - rtas_args->nret = 1; - rtas_args->rets = &(rtas_args->args[0]); printk("%u %u Ready to die...\n", smp_processor_id(), hard_smp_processor_id()); Index: working-2.6/arch/ppc64/kernel/traps.c =================================================================== --- working-2.6.orig/arch/ppc64/kernel/traps.c 2004-06-21 15:23:45.949386784 +1000 +++ working-2.6/arch/ppc64/kernel/traps.c 2004-06-21 15:23:46.012377208 +1000 @@ -36,6 +36,7 @@ #include #include #include +#include #ifdef CONFIG_PPC_PSERIES /* This is true if we are using the firmware NMI handler (typically LPAR) */ Index: working-2.6/arch/ppc64/kernel/eeh.c =================================================================== --- working-2.6.orig/arch/ppc64/kernel/eeh.c 2004-06-04 10:53:50.000000000 +1000 +++ working-2.6/arch/ppc64/kernel/eeh.c 2004-06-21 15:23:46.013377056 +1000 @@ -31,6 +31,7 @@ #include #include #include +#include #include "pci.h" #undef DEBUG Index: working-2.6/arch/ppc64/kernel/rtc.c =================================================================== --- working-2.6.orig/arch/ppc64/kernel/rtc.c 2004-05-20 12:57:53.000000000 +1000 +++ working-2.6/arch/ppc64/kernel/rtc.c 2004-06-21 15:23:46.014376904 +1000 @@ -40,6 +40,7 @@ #include #include #include +#include #include #include Index: working-2.6/arch/ppc64/kernel/setup.c =================================================================== --- working-2.6.orig/arch/ppc64/kernel/setup.c 2004-05-26 11:12:58.000000000 +1000 +++ working-2.6/arch/ppc64/kernel/setup.c 2004-06-21 15:25:23.886401760 +1000 @@ -45,6 +45,7 @@ #include #include #include +#include extern unsigned long klimit; /* extern void *stab; */ @@ -222,6 +223,10 @@ } #endif /* CONFIG_BOOTX_TEXT */ +#if defined(CONFIG_HOTPLUG_CPU) && !defined(CONFIG_PPC_PMAC) + rtas_stop_self_args.token = rtas_token("stop-self"); +#endif /* CONFIG_HOTPLUG_CPU && !CONFIG_PPC_PMAC */ + #ifdef CONFIG_PPC_PSERIES if (systemcfg->platform & PLATFORM_PSERIES) { early_console_initialized = 1; Index: working-2.6/arch/ppc64/kernel/pSeries_pci.c =================================================================== --- working-2.6.orig/arch/ppc64/kernel/pSeries_pci.c 2004-05-20 12:57:52.000000000 +1000 +++ working-2.6/arch/ppc64/kernel/pSeries_pci.c 2004-06-21 15:23:46.015376752 +1000 @@ -40,6 +40,7 @@ #include #include #include +#include #include "open_pic.h" #include "pci.h" Index: working-2.6/arch/ppc64/kernel/smp.c =================================================================== --- working-2.6.orig/arch/ppc64/kernel/smp.c 2004-06-09 10:11:50.000000000 +1000 +++ working-2.6/arch/ppc64/kernel/smp.c 2004-06-21 15:23:46.016376600 +1000 @@ -52,6 +52,7 @@ #include #include #include +#include int smp_threads_ready; unsigned long cache_decay_ticks; Index: working-2.6/arch/ppc64/xmon/xmon.c =================================================================== --- working-2.6.orig/arch/ppc64/xmon/xmon.c 2004-06-21 11:29:19.000000000 +1000 +++ working-2.6/arch/ppc64/xmon/xmon.c 2004-06-21 15:23:46.018376296 +1000 @@ -30,6 +30,7 @@ #include #include #include +#include #include "nonstdio.h" #include "privinst.h" Index: working-2.6/include/asm-ppc64/rtas.h =================================================================== --- working-2.6.orig/include/asm-ppc64/rtas.h 2004-05-24 11:20:52.000000000 +1000 +++ working-2.6/include/asm-ppc64/rtas.h 2004-06-21 15:23:46.019376144 +1000 @@ -51,18 +51,17 @@ u32 nargs; u32 nret; rtas_arg_t args[16]; -#if 0 - spinlock_t lock; -#endif rtas_arg_t *rets; /* Pointer to return values in args[]. */ }; +extern struct rtas_args rtas_stop_self_args; + struct rtas_t { unsigned long entry; /* physical address pointer */ unsigned long base; /* physical address pointer */ unsigned long size; spinlock_t lock; - + struct rtas_args args; struct device_node *dev; /* virtual address pointer */ }; Index: working-2.6/include/asm-ppc64/paca.h =================================================================== --- working-2.6.orig/include/asm-ppc64/paca.h 2004-06-21 11:29:20.000000000 +1000 +++ working-2.6/include/asm-ppc64/paca.h 2004-06-21 15:23:46.019376144 +1000 @@ -29,7 +29,6 @@ #include #include #include -#include #include #include @@ -122,10 +121,9 @@ * CACHE_LINE_17-18 0x0800 - 0x08FF Reserved *===================================================================================== */ - struct rtas_args xRtas; /* Per processor RTAS struct */ u64 xR1; /* r1 save for RTAS calls */ u64 xSavedMsr; /* Old msr saved here by HvCall */ - u8 rsvd5[256-16-sizeof(struct rtas_args)]; + u8 rsvd5[256-16]; /*===================================================================================== * CACHE_LINE_19-30 0x0900 - 0x0EFF Reserved Index: working-2.6/include/asm-ppc64/eeh.h =================================================================== --- working-2.6.orig/include/asm-ppc64/eeh.h 2004-06-04 10:53:50.000000000 +1000 +++ working-2.6/include/asm-ppc64/eeh.h 2004-06-21 15:23:46.020375992 +1000 @@ -24,6 +24,7 @@ #include struct pci_dev; +struct device_node; /* I/O addresses are converted to EEH "tokens" such that a driver will cause * a bad page fault if the address is used directly (i.e. these addresses are Index: working-2.6/include/asm-ppc64/current.h =================================================================== --- working-2.6.orig/include/asm-ppc64/current.h 2004-06-09 10:11:50.000000000 +1000 +++ working-2.6/include/asm-ppc64/current.h 2004-06-21 15:23:46.020375992 +1000 @@ -10,8 +10,6 @@ * 2 of the License, or (at your option) any later version. */ -#include - #define get_current() (get_paca()->xCurrent) #define current get_current() -- David Gibson | For every complex problem there is a david AT gibson.dropbear.id.au | solution which is simple, neat and | wrong. http://www.ozlabs.org/people/dgibson ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Mon Jun 21 23:39:04 2004 From: anton at samba.org (Anton Blanchard) Date: Mon, 21 Jun 2004 23:39:04 +1000 Subject: Abolish per-CPU RTAS args In-Reply-To: <20040621060844.GA32294@zax> References: <20040621060844.GA32294@zax> Message-ID: <20040621133903.GB10087@krispykreme> Hi David, > Currently we store RTAS arguments in the PACA. The args have to be in > the RMO, but since we have a global spinlock for RTAS anyway, there's > no reason to have a separate copy of the args per-CPU. This patch > replaces the PACA field with a single instance in the global rtas > structure. I like it :) Any plans to merge your paca cleanup too? Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From katzj at redhat.com Tue Jun 22 06:43:35 2004 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 21 Jun 2004 16:43:35 -0400 Subject: Probing of iSeries devices with the 2.6 kernel, redux (bz122560) In-Reply-To: <20040620015730.0e1a79be.sfr@au.ibm.com> References: <1087505977.13370.14.camel@bree.local.net> <20040618084836.4f96f988.sfr@au.ibm.com> <1087514412.13370.24.camel@bree.local.net> <20040618134857.27cc7191.sfr@au.ibm.com> <1087531275.13370.62.camel@bree.local.net> <20040618153047.6e32cd9e.sfr@au.ibm.com> <20040619112949.671c4924.sfr@au.ibm.com> <1087623390.21082.1.camel@bree.local.net> <20040619155016.4811b6dc.sfr@au.ibm.com> <20040620015730.0e1a79be.sfr@au.ibm.com> Message-ID: <1087850615.20881.41.camel@bree.local.net> On Sun, 2004-06-20 at 01:57 +1000, Stephen Rothwell wrote: > On Sat, 19 Jun 2004 15:50:16 +1000 Stephen Rothwell wrote: > > This bug has been raised to "ship issue" on our side, so I will be working > > on it over the weekend. Expect another patch. Unfortunately, the patch > > is getting large - it needs infrastructure for all the sysfs stuff. > > Attached is another patch. It is against the Ameslab tree which should > be pretty close to 2.6 upstream. I have cut it down as much as possible > by removing a whole lot of cleanups I had in there. Applies fine here for the most part (we don't have the vscsi driver, so removed that chunk). Had to go back slightly to something 2.6.7-rc3-bk6 based as the final 2.6.7 seems to fail to build for iSeries with undefined references to .flush_altivec_to_thread, but that'll work itself out. > OK, this is what the patch does. All the iSeries virtual devices now > appear in /sys/devices/vio and /sys/bus/vio/devices. Unfortunately, > apart from the veth devices, there are all possible devices there at > the moment - I need to think about how to reduce it but that requires > moving all the probe code into vio.c ... It would definitely be helpful to have only the present ones listed. Seems to basically work with some quick probing code I wrote for the veth side at least. > Suggestions welcome. I will put this in bugzilla as well. Not directly related to this, but it would be helpful if iseries_veth would set the bus specific bits of the ETHTOOL_GDRVINFO structure. But not having won't completely break things, it'll just make some things a little bit less ideal. Jeremy ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From david at gibson.dropbear.id.au Tue Jun 22 10:33:30 2004 From: david at gibson.dropbear.id.au (David Gibson) Date: Tue, 22 Jun 2004 10:33:30 +1000 Subject: Abolish per-CPU RTAS args In-Reply-To: <20040621133903.GB10087@krispykreme> References: <20040621060844.GA32294@zax> <20040621133903.GB10087@krispykreme> Message-ID: <20040622003330.GA1894@zax> On Mon, Jun 21, 2004 at 11:39:04PM +1000, Anton Blanchard wrote: > > Hi David, > > > Currently we store RTAS arguments in the PACA. The args have to be in > > the RMO, but since we have a global spinlock for RTAS anyway, there's > > no reason to have a separate copy of the args per-CPU. This patch > > replaces the PACA field with a single instance in the global rtas > > structure. > > I like it :) Any plans to merge your paca cleanup too? So will you push it, or should I? I shoud perhaps mention that it hasn't yet been tested on machine that actually has hotplug CPU... I do plan to merge the paca cleanup at some point. This change lets me make the PACA cleanup more extensive, and get rid of some of the remaining cruft. -- David Gibson | For every complex problem there is a david AT gibson.dropbear.id.au | solution which is simple, neat and | wrong. http://www.ozlabs.org/people/dgibson ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From jschopp at austin.ibm.com Tue Jun 22 17:07:37 2004 From: jschopp at austin.ibm.com (Joel Schopp) Date: Tue, 22 Jun 2004 02:07:37 -0500 Subject: Abolish per-CPU RTAS args In-Reply-To: <20040622003330.GA1894@zax> References: <20040621060844.GA32294@zax> <20040621133903.GB10087@krispykreme> <20040622003330.GA1894@zax> Message-ID: <40D7DAB9.7060900@austin.ibm.com> > So will you push it, or should I? I shoud perhaps mention that it > hasn't yet been tested on machine that actually has hotplug CPU... I have such a machine. I'll try to get to testing your patch with hotplug CPU later this week. > > I do plan to merge the paca cleanup at some point. This change lets > me make the PACA cleanup more extensive, and get rid of some of the > remaining cruft. PACA cleanup! That would be great. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From linas at austin.ibm.com Thu Jun 24 04:49:18 2004 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Wed, 23 Jun 2004 13:49:18 -0500 Subject: [PATCH] Virtual IO devices don't have bridges Message-ID: <20040623134918.C21634@forte.austin.ibm.com> Hi Linda, Greg, Below follows a set of patches to the ppc64 pci hotplug code. If there are no objections from Linda or the other pSeries hotplug maintainers, then Greg, please apply to your sources. The three fixes are: -- Virtual I/O (VIO) devices do not have PCI bridges associated with them. Thus, performing a loop over all devices, when a VIO device was in the list caused a null-pointer deref. Appearently, no one ever tried to hot-unplug a pci slot on a system that had VIO devices on it before. -- slot-remove ordering problem. EEH remove should be done last, after the pci slot remove. This caused certain oddball but mostly harmless trouble in certain obscure hardware-failure testing scenarios. -- Minor performance tweak to the struct slot structure. Putting the two u8 members of the struct will shrink the total struct size by 8 bytes. Moving the struct list_head from last place to first place in the struct will avoid an add-immediate instruction generated by the compiler, without adversly afecting ofther member access. Linas -------------- next part -------------- --- drivers/pci/hotplug/rpaphp_pci.c.orig 2004-06-23 11:55:37.000000000 -0500 +++ drivers/pci/hotplug/rpaphp_pci.c 2004-06-23 13:22:01.000000000 -0500 @@ -376,8 +376,8 @@ int rpaphp_unconfig_pci_adapter(struct s func = list_entry(ln, struct rpaphp_pci_func, sibling); if (func->pci_dev) { - rpaphp_eeh_remove_bus_device(func->pci_dev); pci_remove_bus_device(func->pci_dev); + rpaphp_eeh_remove_bus_device(func->pci_dev); } kfree(func); } @@ -513,9 +513,18 @@ struct hotplug_slot *rpaphp_find_hotplug struct list_head *ln; slot = list_entry(tmp, struct slot, rpaphp_slot_list); + if (slot->bridge == NULL) { + if (slot->dev_type == PCI_DEV) { + printk (KERN_WARNING "PCI slot missing bridge %s %s \n", + slot->name, slot->location); + } + continue; + } + bus = slot->bridge->subordinate; - if (!bus) - return NULL; /* shouldn't be here */ + if (!bus) { + continue; /* should never happen? */ + } for (ln = bus->devices.next; ln != &bus->devices; ln = ln->next) { struct pci_dev *pdev = pci_dev_b(ln); if (pdev == dev) --- drivers/pci/hotplug/rpaphp.h.orig 2004-06-18 16:10:47.000000000 -0500 +++ drivers/pci/hotplug/rpaphp.h 2004-06-23 13:28:20.000000000 -0500 @@ -85,6 +85,7 @@ struct rpaphp_pci_func { * struct slot - slot information for each *physical* slot */ struct slot { + struct list_head rpaphp_slot_list; int state; u32 index; u32 type; @@ -92,6 +93,7 @@ struct slot { char *name; char *location; u8 removable; + u8 dev_type; /* VIO or PCI */ struct device_node *dn; /* slot's device_node in OFDT */ /* dn has phb info */ struct pci_dev *bridge; /* slot's pci_dev in pci_devices */ @@ -99,9 +101,7 @@ struct slot { struct list_head pci_funcs; /* pci_devs in PCI slot */ struct vio_dev *vio_dev; /* vio_dev in VIO slot */ } dev; - u8 dev_type; /* VIO or PCI */ struct hotplug_slot *hotplug_slot; - struct list_head rpaphp_slot_list; }; extern struct hotplug_slot_ops rpaphp_hotplug_slot_ops; From umutaymak at yahoo.com Thu Jun 24 08:14:26 2004 From: umutaymak at yahoo.com (umut aymakoglu) Date: Wed, 23 Jun 2004 15:14:26 -0700 (PDT) Subject: SIGILL on an assembly instruction on Linux PPC64 Message-ID: <20040623221426.68769.qmail@web60002.mail.yahoo.com> Hi - I am trying to convert an existing assembly file written for 64bit AIX on rs6000 to 64bit Linux on ppc64. In the aix file there is an instruction as: 1) bl ._savef14 which stores the floating point registers 14-31 to the stack frame and 2) bl ._restf14 which loads the floating point registers 14-31 The problem i have is: at (1) the code goes into .fsav() which stores only the fp14 and at (2) it goes into .fres() and gives SIGILL. Does anybody know what is going wrong? I would also like to know if there are any kind of documentation on the assembly for linux on ppc64 thanks alot, Umut ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From jschopp at austin.ibm.com Thu Jun 24 09:05:25 2004 From: jschopp at austin.ibm.com (Joel Schopp) Date: Wed, 23 Jun 2004 18:05:25 -0500 Subject: Abolish per-CPU RTAS args In-Reply-To: <20040621060844.GA32294@zax> References: <20040621060844.GA32294@zax> Message-ID: <40DA0CB5.7020400@austin.ibm.com> > Currently we store RTAS arguments in the PACA. The args have to be in > the RMO, but since we have a global spinlock for RTAS anyway, there's > no reason to have a separate copy of the args per-CPU. This patch > replaces the PACA field with a single instance in the global rtas > structure. To get this patch to compile I had to add the attached patch, which fixes some more implicit includes of rtas.h. If you know how to get mozilla mail to inline files instead of attaching them please let me know. Will test the combined patch soon. -Joel -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RTAS2.patch Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20040623/2dbc9a43/attachment.txt From sjmunroe at us.ibm.com Thu Jun 24 23:09:59 2004 From: sjmunroe at us.ibm.com (Steve Munroe) Date: Thu, 24 Jun 2004 08:09:59 -0500 Subject: SIGILL on an assembly instruction on Linux PPC64 In-Reply-To: <20040623221426.68769.qmail@web60002.mail.yahoo.com> Message-ID: Steven J. Munroe Linux on Power Toolchain Architect IBM Corporation, Linux Technology Center umut aymakoglu wrote on 06/23/2004 05:14:26 PM: > > Hi - > I am trying to convert an existing assembly file > written for 64bit AIX on rs6000 to 64bit Linux on > ppc64. In the aix file there is an instruction as: > > 1) bl ._savef14 which stores the floating point > registers 14-31 to the stack frame and > 2) bl ._restf14 which loads the floating point > registers 14-31 > > The problem i have is: at (1) the code goes into > .fsav() which stores only the fp14 and at (2) it goes > into .fres() and gives SIGILL. > > Does anybody know what is going wrong? I would also > like to know if there are any kind of documentation on > the assembly for linux on ppc64 > Read the following carefully ;-) GNU Not UNIX Also not AIX Linux uses the ELF ABI http://www.linuxbase.org/spec/ELF/ppc64/spec/book1.html ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From david at gibson.dropbear.id.au Fri Jun 25 14:53:10 2004 From: david at gibson.dropbear.id.au (David Gibson) Date: Fri, 25 Jun 2004 14:53:10 +1000 Subject: Abolish per-CPU RTAS args In-Reply-To: <40DA0CB5.7020400@austin.ibm.com> References: <20040621060844.GA32294@zax> <40DA0CB5.7020400@austin.ibm.com> Message-ID: <20040625045310.GA12317@zax> On Wed, Jun 23, 2004 at 06:05:25PM -0500, Joel Schopp wrote: > >Currently we store RTAS arguments in the PACA. The args have to be in > >the RMO, but since we have a global spinlock for RTAS anyway, there's > >no reason to have a separate copy of the args per-CPU. This patch > >replaces the PACA field with a single instance in the global rtas > >structure. > > To get this patch to compile I had to add the attached patch, which > fixes some more implicit includes of rtas.h. If you know how to get > mozilla mail to inline files instead of attaching them please let me > know. Sorry for the delay - I've been out sick the last couple of days. I would have missed those files because I wasn't compiling them with my config. I've folded your patch into mine. > Will test the combined patch soon. Any word on this? -- David Gibson | For every complex problem there is a david AT gibson.dropbear.id.au | solution which is simple, neat and | wrong. http://www.ozlabs.org/people/dgibson ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From linas at austin.ibm.com Sat Jun 26 04:00:16 2004 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Fri, 25 Jun 2004 13:00:16 -0500 Subject: [PATCH] Virtual IO devices don't have bridges In-Reply-To: <20040623134918.C21634@forte.austin.ibm.com>; from linas@austin.ibm.com on Wed, Jun 23, 2004 at 01:49:18PM -0500 References: <20040623134918.C21634@forte.austin.ibm.com> Message-ID: <20040625130015.A17308@forte.austin.ibm.com> Hi, Resending, I guess I needed the following line: Signed-off-by: Linas Vepstas On Wed, Jun 23, 2004 at 01:49:18PM -0500, linas at austin.ibm.com wrote: > > Hi Linda, Greg, > > Below follows a set of patches to the ppc64 pci hotplug code. > If there are no objections from Linda or the other pSeries > hotplug maintainers, then Greg, please apply to your sources. > > The three fixes are: > -- Virtual I/O (VIO) devices do not have PCI bridges associated > with them. Thus, performing a loop over all devices, when > a VIO device was in the list caused a null-pointer deref. > Appearently, no one ever tried to hot-unplug a pci slot > on a system that had VIO devices on it before. > > -- slot-remove ordering problem. EEH remove should be done last, > after the pci slot remove. This caused certain oddball but > mostly harmless trouble in certain obscure hardware-failure > testing scenarios. > > -- Minor performance tweak to the struct slot structure. > Putting the two u8 members of the struct will shrink the > total struct size by 8 bytes. Moving the struct list_head > from last place to first place in the struct will avoid > an add-immediate instruction generated by the compiler, > without adversly afecting ofther member access. > > Linas --- drivers/pci/hotplug/rpaphp_pci.c.orig 2004-06-23 11:55:37.000000000 -0500 +++ drivers/pci/hotplug/rpaphp_pci.c 2004-06-23 13:22:01.000000000 -0500 @@ -376,8 +376,8 @@ int rpaphp_unconfig_pci_adapter(struct s func = list_entry(ln, struct rpaphp_pci_func, sibling); if (func->pci_dev) { - rpaphp_eeh_remove_bus_device(func->pci_dev); pci_remove_bus_device(func->pci_dev); + rpaphp_eeh_remove_bus_device(func->pci_dev); } kfree(func); } @@ -513,9 +513,18 @@ struct hotplug_slot *rpaphp_find_hotplug struct list_head *ln; slot = list_entry(tmp, struct slot, rpaphp_slot_list); + if (slot->bridge == NULL) { + if (slot->dev_type == PCI_DEV) { + printk (KERN_WARNING "PCI slot missing bridge %s %s \n", + slot->name, slot->location); + } + continue; + } + bus = slot->bridge->subordinate; - if (!bus) - return NULL; /* shouldn't be here */ + if (!bus) { + continue; /* should never happen? */ + } for (ln = bus->devices.next; ln != &bus->devices; ln = ln->next) { struct pci_dev *pdev = pci_dev_b(ln); if (pdev == dev) --- drivers/pci/hotplug/rpaphp.h.orig 2004-06-18 16:10:47.000000000 -0500 +++ drivers/pci/hotplug/rpaphp.h 2004-06-23 13:28:20.000000000 -0500 @@ -85,6 +85,7 @@ struct rpaphp_pci_func { * struct slot - slot information for each *physical* slot */ struct slot { + struct list_head rpaphp_slot_list; int state; u32 index; u32 type; @@ -92,6 +93,7 @@ struct slot { char *name; char *location; u8 removable; + u8 dev_type; /* VIO or PCI */ struct device_node *dn; /* slot's device_node in OFDT */ /* dn has phb info */ struct pci_dev *bridge; /* slot's pci_dev in pci_devices */ @@ -99,9 +101,7 @@ struct slot { struct list_head pci_funcs; /* pci_devs in PCI slot */ struct vio_dev *vio_dev; /* vio_dev in VIO slot */ } dev; - u8 dev_type; /* VIO or PCI */ struct hotplug_slot *hotplug_slot; - struct list_head rpaphp_slot_list; }; extern struct hotplug_slot_ops rpaphp_hotplug_slot_ops; ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From moilanen at austin.ibm.com Sat Jun 26 05:46:28 2004 From: moilanen at austin.ibm.com (moilanen at austin.ibm.com) Date: Fri, 25 Jun 2004 14:46:28 -0500 Subject: [patch 1/1] Dump text for xmon Message-ID: <200406251947.i5PJl6cg074890@northrelay02.pok.ibm.com> Here's a patch to dump text in xmon. The 'dt' command works just like any other dump command, it takes an address and an optional number of lines. All non-printable characters are printed w/ a '.' instead. If no one has any objections, I'll push it to ames sometime late next week. Thanks, Jake --- diff -puN arch/ppc64/xmon/xmon.c~xmon-text-dump arch/ppc64/xmon/xmon.c --- linux-2.6/arch/ppc64/xmon/xmon.c~xmon-text-dump Wed Jun 23 11:29:27 2004 +++ linux-2.6-moilanen/arch/ppc64/xmon/xmon.c Fri Jun 25 14:41:13 2004 @@ -48,6 +48,7 @@ static unsigned long adrs; static int size = 1; static unsigned long ndump = 64; static unsigned long nidump = 16; +static unsigned long ntdump = 16; static unsigned long ncsum = 4096; static int termch; static char tmpstr[128]; @@ -81,6 +82,8 @@ static int bsesc(void); static void dump(void); static void prdump(unsigned long, long); static int ppc_inst_dump(unsigned long, long); +static int ppc_txt_dump(unsigned long, long); + void print_address(unsigned long); static void backtrace(struct pt_regs *); static void excprint(struct pt_regs *); @@ -156,6 +159,7 @@ Commands:\n\ di dump instructions\n\ df dump float values\n\ dd dump double values\n\ + dt dump text\n\ e print exception information\n\ f flush cache\n\ la lookup symbol+offset of specified address\n\ @@ -1543,6 +1547,13 @@ dump() nidump = 16; adrs += ppc_inst_dump(adrs, nidump); last_cmd = "di\n"; + } else if ( c == 't' ){ + scanhex(&ntdump); + if( ntdump == 0 ) { + ntdump = 16; + } + adrs += ppc_txt_dump(adrs, ntdump); + last_cmd = "dt\n"; } else { scanhex(&ndump); if( ndump == 0 ) @@ -1590,6 +1601,36 @@ prdump(unsigned long adrs, long ndump) if( nr < r ) break; } +} + +static int +ppc_txt_dump(unsigned long adr, long count) +{ + unsigned long first_adr; + char c; + + if (!adr) { + printf("xmon BUG: %s, %d\n", __FILE__, __LINE__); + return 0; + } + + for (first_adr = adr; count > 0; adr++) { + c = *(char *)adr; + if (c <= 31 || c >= 127) { + count--; + + if (c != '\n') { + printf("."); + continue; + } + } + + printf("%c", c); + } + + printf("%.16lx ", adr); + + return adr - first_adr; } int _ ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From moilanen at austin.ibm.com Sat Jun 26 06:08:01 2004 From: moilanen at austin.ibm.com (Jake Moilanen) Date: Fri, 25 Jun 2004 15:08:01 -0500 Subject: [patch 1/1] Dump text for xmon In-Reply-To: <200406251947.i5PJl6cg074890@northrelay02.pok.ibm.com> References: <200406251947.i5PJl6cg074890@northrelay02.pok.ibm.com> Message-ID: <20040625150801.4d539dac.moilanen@austin.ibm.com> > Here's a patch to dump text in xmon. The 'dt' command works > just like any other dump command, it takes an address and an > optional number of lines. > > All non-printable characters are printed w/ a '.' instead. > > If no one has any objections, I'll push it to ames sometime > late next week. Olof pointed out I forgot to mread the character. Here's a revised version. Thanks, Jake --- diff -puN arch/ppc64/xmon/xmon.c~xmon-text-dump arch/ppc64/xmon/xmon.c --- linux-2.6/arch/ppc64/xmon/xmon.c~xmon-text-dump Wed Jun 23 11:29:27 2004 +++ linux-2.6-moilanen/arch/ppc64/xmon/xmon.c Fri Jun 25 15:00:23 2004 @@ -48,6 +48,7 @@ static unsigned long adrs; static int size = 1; static unsigned long ndump = 64; static unsigned long nidump = 16; +static unsigned long ntdump = 16; static unsigned long ncsum = 4096; static int termch; static char tmpstr[128]; @@ -81,6 +82,8 @@ static int bsesc(void); static void dump(void); static void prdump(unsigned long, long); static int ppc_inst_dump(unsigned long, long); +static int ppc_txt_dump(unsigned long, long); + void print_address(unsigned long); static void backtrace(struct pt_regs *); static void excprint(struct pt_regs *); @@ -156,6 +159,7 @@ Commands:\n\ di dump instructions\n\ df dump float values\n\ dd dump double values\n\ + dt dump text\n\ e print exception information\n\ f flush cache\n\ la lookup symbol+offset of specified address\n\ @@ -1543,6 +1547,13 @@ dump() nidump = 16; adrs += ppc_inst_dump(adrs, nidump); last_cmd = "di\n"; + } else if ( c == 't' ){ + scanhex(&ntdump); + if( ntdump == 0 ) { + ntdump = 16; + } + adrs += ppc_txt_dump(adrs, ntdump); + last_cmd = "dt\n"; } else { scanhex(&ndump); if( ndump == 0 ) @@ -1590,6 +1601,37 @@ prdump(unsigned long adrs, long ndump) if( nr < r ) break; } +} + +static int +ppc_txt_dump(unsigned long adr, long count) +{ + unsigned long first_adr; + long nr; + char c; + + for (first_adr = adr; count > 0; adr++) { + + nr = mread(adr, &c, 1); + + if (!nr) + break; + + if (c <= 31 || c >= 127) { + count--; + + if (c != '\n') { + printf("."); + continue; + } + } + + printf("%c", c); + } + + printf("%.16lx ", adr); + + return adr - first_adr; } int _ ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From jschopp at austin.ibm.com Sat Jun 26 07:25:34 2004 From: jschopp at austin.ibm.com (Joel Schopp) Date: Fri, 25 Jun 2004 16:25:34 -0500 Subject: Abolish per-CPU RTAS args In-Reply-To: <20040625045310.GA12317@zax> References: <20040621060844.GA32294@zax> <40DA0CB5.7020400@austin.ibm.com> <20040625045310.GA12317@zax> Message-ID: <40DC984E.5060109@austin.ibm.com> >>Will test the combined patch soon. > > > Any word on this? > cpu 0x0: Vector: 700 (Program Check) at [c0000000005739f0] pc: c00000000003ab1c: .rtas_stop_self+0x34/0x70 lr: c00000000003e25c: .cpu_die+0x30/0x3c sp: c000000000573c70 msr: 8000000000021032 current = 0xc000000000605810 paca = 0xc000000000574000 pid = 0, comm = swapper enter ? for help 0:mon> t [c000000000573d00] c00000000003e25c .cpu_die+0x30/0x3c [c000000000573d70] c000000000014ee8 .default_idle+0xe8/0xec [c000000000573e00] c0000000000151d0 .cpu_idle+0x2c/0x44 [c000000000573e70] c00000000000c548 .rest_init+0x74/0x8c [c000000000573ef0] c0000000005218a0 .start_kernel+0x224/0x284 [c000000000573f90] c00000000000c270 .__setup_cpu_power3+0x0/0x4 Don't have time to investigate this much now, but it looks like the rtas_stop_self didn't work so well. Will poke at it next week. -Joel ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From hollisb at us.ibm.com Sat Jun 26 07:34:37 2004 From: hollisb at us.ibm.com (Hollis Blanchard) Date: Fri, 25 Jun 2004 16:34:37 -0500 Subject: [patch 1/1] Dump text for xmon In-Reply-To: <200406251947.i5PJl6cg074890@northrelay02.pok.ibm.com> References: <200406251947.i5PJl6cg074890@northrelay02.pok.ibm.com> Message-ID: <1088199277.30853.104.camel@localhost> On Fri, 2004-06-25 at 14:46, moilanen at austin.ibm.com wrote: > Here's a patch to dump text in xmon. The 'dt' command works > just like any other dump command, it takes an address and an > optional number of lines. Is this to dump the printk buffer more easily? Could we build in "look up and print the end of log_buf" too? :) -- Hollis Blanchard IBM Linux Technology Center ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From david at gibson.dropbear.id.au Sat Jun 26 13:21:23 2004 From: david at gibson.dropbear.id.au (David Gibson) Date: Sat, 26 Jun 2004 13:21:23 +1000 Subject: Abolish per-CPU RTAS args In-Reply-To: <40DC984E.5060109@austin.ibm.com> References: <20040621060844.GA32294@zax> <40DA0CB5.7020400@austin.ibm.com> <20040625045310.GA12317@zax> <40DC984E.5060109@austin.ibm.com> Message-ID: <20040626032123.GA30817@zax> On Fri, Jun 25, 2004 at 04:25:34PM -0500, Joel Schopp wrote: > >>Will test the combined patch soon. > > > > > >Any word on this? > > > > cpu 0x0: Vector: 700 (Program Check) at [c0000000005739f0] > pc: c00000000003ab1c: .rtas_stop_self+0x34/0x70 > lr: c00000000003e25c: .cpu_die+0x30/0x3c > sp: c000000000573c70 > msr: 8000000000021032 > current = 0xc000000000605810 > paca = 0xc000000000574000 > pid = 0, comm = swapper > enter ? for help > 0:mon> t > [c000000000573d00] c00000000003e25c .cpu_die+0x30/0x3c > [c000000000573d70] c000000000014ee8 .default_idle+0xe8/0xec > [c000000000573e00] c0000000000151d0 .cpu_idle+0x2c/0x44 > [c000000000573e70] c00000000000c548 .rest_init+0x74/0x8c > [c000000000573ef0] c0000000005218a0 .start_kernel+0x224/0x284 > [c000000000573f90] c00000000000c270 .__setup_cpu_power3+0x0/0x4 > > Don't have time to investigate this much now, but it looks like the > rtas_stop_self didn't work so well. Will poke at it next week. Bother. I wonder if it's hitting the BUG_ON() in there - if you get a chance, can you see if there is a BUG message before it enters xmon? -- David Gibson | For every complex problem there is a david AT gibson.dropbear.id.au | solution which is simple, neat and | wrong. http://www.ozlabs.org/people/dgibson ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From nathanl at austin.ibm.com Sun Jun 27 19:05:19 2004 From: nathanl at austin.ibm.com (Nathan Lynch) Date: Sun, 27 Jun 2004 04:05:19 -0500 Subject: Abolish per-CPU RTAS args In-Reply-To: <20040626032123.GA30817@zax> References: <20040621060844.GA32294@zax> <40DA0CB5.7020400@austin.ibm.com> <20040625045310.GA12317@zax> <40DC984E.5060109@austin.ibm.com> <20040626032123.GA30817@zax> Message-ID: <40DE8DCF.2040008@austin.ibm.com> David Gibson wrote: > On Fri, Jun 25, 2004 at 04:25:34PM -0500, Joel Schopp wrote: >>cpu 0x0: Vector: 700 (Program Check) at [c0000000005739f0] >> pc: c00000000003ab1c: .rtas_stop_self+0x34/0x70 >> lr: c00000000003e25c: .cpu_die+0x30/0x3c >> sp: c000000000573c70 >> msr: 8000000000021032 >> current = 0xc000000000605810 >> paca = 0xc000000000574000 >> pid = 0, comm = swapper >>enter ? for help >>0:mon> t >>[c000000000573d00] c00000000003e25c .cpu_die+0x30/0x3c >>[c000000000573d70] c000000000014ee8 .default_idle+0xe8/0xec >>[c000000000573e00] c0000000000151d0 .cpu_idle+0x2c/0x44 >>[c000000000573e70] c00000000000c548 .rest_init+0x74/0x8c >>[c000000000573ef0] c0000000005218a0 .start_kernel+0x224/0x284 >>[c000000000573f90] c00000000000c270 .__setup_cpu_power3+0x0/0x4 >> >>Don't have time to investigate this much now, but it looks like the >>rtas_stop_self didn't work so well. Will poke at it next week. > > > Bother. I wonder if it's hitting the BUG_ON() in there - if you get a > chance, can you see if there is a BUG message before it enters xmon? I don't have a way to test this at the moment, but moving this part (from setup.c): +#if defined(CONFIG_HOTPLUG_CPU) && !defined(CONFIG_PPC_PMAC) + rtas_stop_self_args.token = rtas_token("stop-self"); +#endif /* CONFIG_HOTPLUG_CPU && !CONFIG_PPC_PMAC */ down a few lines to after finish_device_tree() has been called should fix it. rtas_token() won't work until after finish_device_tree() has run. Nathan ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From sfr at canb.auug.org.au Sun Jun 27 21:24:35 2004 From: sfr at canb.auug.org.au (Stephen Rothwell) Date: Sun, 27 Jun 2004 21:24:35 +1000 Subject: [PATCH] PPC64 iSeries fails to boot Message-ID: <20040627212435.6369beef.sfr@canb.auug.org.au> Hi Andrew, Linus, Jeremy Katz of Red Hat reported that his iSeries machine would not boot with 2.6.7 based kernels. It appears that with the inclusion of Paul Mackerras' patch "Optimize exception/syscall entry/exit" a small previous patch got reverted. Here is that patch again. The lack of this patch does not stop all iSeries machines booting, but it does stop some. Please apply. Signed-off-by: Stephen Rothwell -- Cheers, Stephen Rothwell sfr at canb.auug.org.au http://www.canb.auug.org.au/~sfr/ diff -ruN 2.6.7-bk9/arch/ppc64/kernel/head.S 2.6.7-bk9.head/arch/ppc64/kernel/head.S --- 2.6.7-bk9/arch/ppc64/kernel/head.S 2004-06-27 13:31:01.000000000 +1000 +++ 2.6.7-bk9.head/arch/ppc64/kernel/head.S 2004-06-27 20:22:13.000000000 +1000 @@ -631,6 +631,9 @@ .globl SystemReset_Iseries SystemReset_Iseries: mfspr r13,SPRG3 /* Get paca address */ + mfmsr r24 + ori r24,r24,MSR_RI + mtmsrd r24 /* RI on */ lhz r24,PACAPACAINDEX(r13) /* Get processor # */ cmpwi 0,r24,0 /* Are we processor 0? */ beq .__start_initialization_iSeries /* Start up the first processor */ ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From david at gibson.dropbear.id.au Mon Jun 28 11:55:45 2004 From: david at gibson.dropbear.id.au (David Gibson) Date: Mon, 28 Jun 2004 11:55:45 +1000 Subject: Abolish per-CPU RTAS args In-Reply-To: <40DE8DCF.2040008@austin.ibm.com> References: <20040621060844.GA32294@zax> <40DA0CB5.7020400@austin.ibm.com> <20040625045310.GA12317@zax> <40DC984E.5060109@austin.ibm.com> <20040626032123.GA30817@zax> <40DE8DCF.2040008@austin.ibm.com> Message-ID: <20040628015545.GA650@zax> On Sun, Jun 27, 2004 at 04:05:19AM -0500, Nathan Lynch wrote: > > David Gibson wrote: > >On Fri, Jun 25, 2004 at 04:25:34PM -0500, Joel Schopp wrote: > >>cpu 0x0: Vector: 700 (Program Check) at [c0000000005739f0] > >> pc: c00000000003ab1c: .rtas_stop_self+0x34/0x70 > >> lr: c00000000003e25c: .cpu_die+0x30/0x3c > >> sp: c000000000573c70 > >> msr: 8000000000021032 > >> current = 0xc000000000605810 > >> paca = 0xc000000000574000 > >> pid = 0, comm = swapper > >>enter ? for help > >>0:mon> t > >>[c000000000573d00] c00000000003e25c .cpu_die+0x30/0x3c > >>[c000000000573d70] c000000000014ee8 .default_idle+0xe8/0xec > >>[c000000000573e00] c0000000000151d0 .cpu_idle+0x2c/0x44 > >>[c000000000573e70] c00000000000c548 .rest_init+0x74/0x8c > >>[c000000000573ef0] c0000000005218a0 .start_kernel+0x224/0x284 > >>[c000000000573f90] c00000000000c270 .__setup_cpu_power3+0x0/0x4 > >> > >>Don't have time to investigate this much now, but it looks like the > >>rtas_stop_self didn't work so well. Will poke at it next week. > > > > > >Bother. I wonder if it's hitting the BUG_ON() in there - if you get a > >chance, can you see if there is a BUG message before it enters xmon? > > I don't have a way to test this at the moment, but moving this part > (from setup.c): > > +#if defined(CONFIG_HOTPLUG_CPU) && !defined(CONFIG_PPC_PMAC) > + rtas_stop_self_args.token = rtas_token("stop-self"); > +#endif /* CONFIG_HOTPLUG_CPU && !CONFIG_PPC_PMAC */ > > down a few lines to after finish_device_tree() has been called should > fix it. rtas_token() won't work until after finish_device_tree() > has run. Ah, yes, that would explain it. Joel, could you test with this revised patch: This patch removes the RTAS arguments structure on ppc64 from the PACA. The args have to be in the RMO, but since we have a global spinlock for RTAS anyway, there's no reason to have a separate copy of the args per-CPU. This patch replaces the PACA field with a single instance in the global rtas structure. The one exception is for the rtas_stop_self() call, which can't take the lock, because it never returns. But it has a fixed set of arguments, so we can use another global instance which is initialized at boot. This lets us remove rtas.h from paca.h, which substantially reduces overall #include hairiness (because paca.h is now, as it wants to be, a nice low-level structure-defining header which relies on very little and can safely be included almost anywhere). Although it does add some noise to the patch, because a bunch of places relied on the indirect inclusion of rtas.h, or even more indirect inclusions (see the hunks applying to eeh.h and current.h!). Index: working-2.6/arch/ppc64/kernel/rtas.c =================================================================== --- working-2.6.orig/arch/ppc64/kernel/rtas.c 2004-06-21 11:29:19.000000000 +1000 +++ working-2.6/arch/ppc64/kernel/rtas.c 2004-06-28 11:54:01.775174032 +1000 @@ -68,11 +68,10 @@ void call_rtas_display_status(char c) { - struct rtas_args *args; + struct rtas_args *args = &rtas.args; unsigned long s; spin_lock_irqsave(&rtas.lock, s); - args = &(get_paca()->xRtas); args->token = 10; args->nargs = 1; @@ -113,15 +112,15 @@ err_args.args[2] = 0; temp_args = *rtas_args; - get_paca()->xRtas = err_args; + rtas.args = err_args; PPCDBG(PPCDBG_RTAS, "\tentering rtas with 0x%lx\n", __pa(&err_args)); - enter_rtas(__pa(&get_paca()->xRtas)); + enter_rtas(__pa(&rtas.args)); PPCDBG(PPCDBG_RTAS, "\treturned from rtas ...\n"); - err_args = get_paca()->xRtas; - get_paca()->xRtas = temp_args; + err_args = rtas.args; + rtas.args = temp_args; return err_args.rets[0]; } @@ -159,7 +158,7 @@ /* Gotta do something different here, use global lock for now... */ spin_lock_irqsave(&rtas.lock, s); - rtas_args = &(get_paca()->xRtas); + rtas_args = &rtas.args; rtas_args->token = token; rtas_args->nargs = nargs; @@ -481,9 +480,9 @@ spin_lock_irqsave(&rtas.lock, flags); - get_paca()->xRtas = args; - enter_rtas(__pa(&get_paca()->xRtas)); - args = get_paca()->xRtas; + rtas.args = args; + enter_rtas(__pa(&rtas.args)); + args = rtas.args; spin_unlock_irqrestore(&rtas.lock, flags); @@ -501,19 +500,23 @@ } #ifdef CONFIG_HOTPLUG_CPU -/* This version can't take the spinlock. */ +/* This version can't take the spinlock, because it never returns */ + +struct rtas_args rtas_stop_self_args = { + /* The token is initialized for real in setup_system() */ + .token = RTAS_UNKNOWN_SERVICE, + .nargs = 0, + .nret = 1, + .rets = &rtas_stop_self_args.args[0], +}; void rtas_stop_self(void) { - struct rtas_args *rtas_args = &(get_paca()->xRtas); + struct rtas_args *rtas_args = &rtas_stop_self_args; local_irq_disable(); - rtas_args->token = rtas_token("stop-self"); BUG_ON(rtas_args->token == RTAS_UNKNOWN_SERVICE); - rtas_args->nargs = 0; - rtas_args->nret = 1; - rtas_args->rets = &(rtas_args->args[0]); printk("%u %u Ready to die...\n", smp_processor_id(), hard_smp_processor_id()); Index: working-2.6/arch/ppc64/kernel/traps.c =================================================================== --- working-2.6.orig/arch/ppc64/kernel/traps.c 2004-06-28 11:54:01.477085176 +1000 +++ working-2.6/arch/ppc64/kernel/traps.c 2004-06-28 11:54:01.776173880 +1000 @@ -36,6 +36,7 @@ #include #include #include +#include #ifdef CONFIG_PPC_PSERIES /* This is true if we are using the firmware NMI handler (typically LPAR) */ Index: working-2.6/arch/ppc64/kernel/eeh.c =================================================================== --- working-2.6.orig/arch/ppc64/kernel/eeh.c 2004-06-04 10:53:50.000000000 +1000 +++ working-2.6/arch/ppc64/kernel/eeh.c 2004-06-28 11:54:01.787172208 +1000 @@ -31,6 +31,7 @@ #include #include #include +#include #include "pci.h" #undef DEBUG Index: working-2.6/arch/ppc64/kernel/rtc.c =================================================================== --- working-2.6.orig/arch/ppc64/kernel/rtc.c 2004-05-20 12:57:53.000000000 +1000 +++ working-2.6/arch/ppc64/kernel/rtc.c 2004-06-28 11:54:01.797170688 +1000 @@ -40,6 +40,7 @@ #include #include #include +#include #include #include Index: working-2.6/arch/ppc64/kernel/setup.c =================================================================== --- working-2.6.orig/arch/ppc64/kernel/setup.c 2004-05-26 11:12:58.000000000 +1000 +++ working-2.6/arch/ppc64/kernel/setup.c 2004-06-28 11:55:54.746169360 +1000 @@ -45,6 +45,7 @@ #include #include #include +#include extern unsigned long klimit; /* extern void *stab; */ @@ -255,6 +256,10 @@ } #endif /* CONFIG_PPC_PMAC */ +#if defined(CONFIG_HOTPLUG_CPU) && !defined(CONFIG_PPC_PMAC) + rtas_stop_self_args.token = rtas_token("stop-self"); +#endif /* CONFIG_HOTPLUG_CPU && !CONFIG_PPC_PMAC */ + /* Finish initializing the hash table (do the dynamic * patching for the fast-path hashtable.S code) */ Index: working-2.6/arch/ppc64/kernel/pSeries_pci.c =================================================================== --- working-2.6.orig/arch/ppc64/kernel/pSeries_pci.c 2004-05-20 12:57:52.000000000 +1000 +++ working-2.6/arch/ppc64/kernel/pSeries_pci.c 2004-06-28 11:54:01.806169320 +1000 @@ -40,6 +40,7 @@ #include #include #include +#include #include "open_pic.h" #include "pci.h" Index: working-2.6/arch/ppc64/kernel/smp.c =================================================================== --- working-2.6.orig/arch/ppc64/kernel/smp.c 2004-06-09 10:11:50.000000000 +1000 +++ working-2.6/arch/ppc64/kernel/smp.c 2004-06-28 11:54:01.808169016 +1000 @@ -52,6 +52,7 @@ #include #include #include +#include int smp_threads_ready; unsigned long cache_decay_ticks; Index: working-2.6/arch/ppc64/kernel/lparcfg.c =================================================================== --- working-2.6.orig/arch/ppc64/kernel/lparcfg.c 2004-05-20 12:57:52.000000000 +1000 +++ working-2.6/arch/ppc64/kernel/lparcfg.c 2004-06-28 11:54:01.809168864 +1000 @@ -28,6 +28,7 @@ #include #include #include +#include #define MODULE_VERS "1.0" #define MODULE_NAME "lparcfg" Index: working-2.6/arch/ppc64/xmon/xmon.c =================================================================== --- working-2.6.orig/arch/ppc64/xmon/xmon.c 2004-06-21 11:29:19.000000000 +1000 +++ working-2.6/arch/ppc64/xmon/xmon.c 2004-06-28 11:54:01.823166736 +1000 @@ -30,6 +30,7 @@ #include #include #include +#include #include "nonstdio.h" #include "privinst.h" Index: working-2.6/include/asm-ppc64/rtas.h =================================================================== --- working-2.6.orig/include/asm-ppc64/rtas.h 2004-05-24 11:20:52.000000000 +1000 +++ working-2.6/include/asm-ppc64/rtas.h 2004-06-28 11:54:01.835164912 +1000 @@ -51,18 +51,17 @@ u32 nargs; u32 nret; rtas_arg_t args[16]; -#if 0 - spinlock_t lock; -#endif rtas_arg_t *rets; /* Pointer to return values in args[]. */ }; +extern struct rtas_args rtas_stop_self_args; + struct rtas_t { unsigned long entry; /* physical address pointer */ unsigned long base; /* physical address pointer */ unsigned long size; spinlock_t lock; - + struct rtas_args args; struct device_node *dev; /* virtual address pointer */ }; Index: working-2.6/include/asm-ppc64/paca.h =================================================================== --- working-2.6.orig/include/asm-ppc64/paca.h 2004-06-21 11:29:20.000000000 +1000 +++ working-2.6/include/asm-ppc64/paca.h 2004-06-28 11:54:01.898155336 +1000 @@ -29,7 +29,6 @@ #include #include #include -#include #include #include @@ -122,10 +121,9 @@ * CACHE_LINE_17-18 0x0800 - 0x08FF Reserved *===================================================================================== */ - struct rtas_args xRtas; /* Per processor RTAS struct */ u64 xR1; /* r1 save for RTAS calls */ u64 xSavedMsr; /* Old msr saved here by HvCall */ - u8 rsvd5[256-16-sizeof(struct rtas_args)]; + u8 rsvd5[256-16]; /*===================================================================================== * CACHE_LINE_19-30 0x0900 - 0x0EFF Reserved Index: working-2.6/include/asm-ppc64/eeh.h =================================================================== --- working-2.6.orig/include/asm-ppc64/eeh.h 2004-06-22 09:56:21.000000000 +1000 +++ working-2.6/include/asm-ppc64/eeh.h 2004-06-28 11:54:01.909153664 +1000 @@ -24,6 +24,7 @@ #include struct pci_dev; +struct device_node; /* I/O addresses are converted to EEH "tokens" such that a driver will cause * a bad page fault if the address is used directly (i.e. these addresses are Index: working-2.6/include/asm-ppc64/current.h =================================================================== --- working-2.6.orig/include/asm-ppc64/current.h 2004-06-09 10:11:50.000000000 +1000 +++ working-2.6/include/asm-ppc64/current.h 2004-06-28 11:54:01.971144240 +1000 @@ -10,8 +10,6 @@ * 2 of the License, or (at your option) any later version. */ -#include - #define get_current() (get_paca()->xCurrent) #define current get_current() Index: working-2.6/drivers/pci/hotplug/rpadlpar_core.c =================================================================== --- working-2.6.orig/drivers/pci/hotplug/rpadlpar_core.c 2004-05-20 12:58:18.000000000 +1000 +++ working-2.6/drivers/pci/hotplug/rpadlpar_core.c 2004-06-28 11:54:01.980142872 +1000 @@ -18,6 +18,7 @@ #include #include #include +#include #include "../pci.h" #include "rpaphp.h" #include "rpadlpar.h" Index: working-2.6/drivers/pci/hotplug/rpaphp_pci.c =================================================================== --- working-2.6.orig/drivers/pci/hotplug/rpaphp_pci.c 2004-05-20 12:58:18.000000000 +1000 +++ working-2.6/drivers/pci/hotplug/rpaphp_pci.c 2004-06-28 11:54:01.981142720 +1000 @@ -24,6 +24,7 @@ */ #include #include +#include #include "../pci.h" /* for pci_add_new_bus */ #include "rpaphp.h" Index: working-2.6/drivers/pci/hotplug/rpaphp_slot.c =================================================================== --- working-2.6.orig/drivers/pci/hotplug/rpaphp_slot.c 2004-05-20 12:58:18.000000000 +1000 +++ working-2.6/drivers/pci/hotplug/rpaphp_slot.c 2004-06-28 11:54:01.982142568 +1000 @@ -27,6 +27,7 @@ #include #include #include +#include #include "rpaphp.h" static ssize_t location_read_file (struct hotplug_slot *php_slot, char *buf) -- David Gibson | For every complex problem there is a david AT gibson.dropbear.id.au | solution which is simple, neat and | wrong. http://www.ozlabs.org/people/dgibson ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From moilanen at austin.ibm.com Mon Jun 28 23:31:55 2004 From: moilanen at austin.ibm.com (Jake Moilanen) Date: Mon, 28 Jun 2004 08:31:55 -0500 Subject: [patch 1/1] Dump text for xmon In-Reply-To: <1088199277.30853.104.camel@localhost> References: <200406251947.i5PJl6cg074890@northrelay02.pok.ibm.com> <1088199277.30853.104.camel@localhost> Message-ID: <20040628083155.1936e9ed.moilanen@austin.ibm.com> > On Fri, 2004-06-25 at 14:46, moilanen at austin.ibm.com wrote: > > Here's a patch to dump text in xmon. The 'dt' command works > > just like any other dump command, it takes an address and an > > optional number of lines. > > Is this to dump the printk buffer more easily? Could we build in "look > up and print the end of log_buf" too? :) > Yes, one of the motivations is to make looking at log_buf a little easier. I was thinking of doing a follow on to this patch to do just what you described. Feel free to if you have some time. :) Jake ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From akpm at osdl.org Tue Jun 29 15:32:44 2004 From: akpm at osdl.org (Andrew Morton) Date: Mon, 28 Jun 2004 22:32:44 -0700 Subject: arch/ppc64/kernel/sysfs.c Message-ID: <20040628223244.28a0913e.akpm@osdl.org> arch/ppc64/kernel/sysfs.c:234: warning: `store_purr' defined but not used Shouldn't this: static SYSDEV_ATTR(purr, 0600, show_purr, NULL); be static SYSDEV_ATTR(purr, 0600, show_purr, store_purr); ? ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From jschopp at austin.ibm.com Wed Jun 30 06:49:02 2004 From: jschopp at austin.ibm.com (Joel Schopp) Date: Tue, 29 Jun 2004 15:49:02 -0500 Subject: [PATCH] rpaphp broken in ameslab Message-ID: <40E1D5BE.2010504@austin.ibm.com> A couple of things got broken in ameslab. Not sure why or where, but here is a patch that fixed it for me. Please apply to Ameslab barring any objections. -Joel -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: june29.patch Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20040629/d99cb397/attachment.txt From umutaymak at yahoo.com Wed Jun 30 08:43:11 2004 From: umutaymak at yahoo.com (umut aymakoglu) Date: Tue, 29 Jun 2004 15:43:11 -0700 (PDT) Subject: compare and swap Message-ID: <20040629224311.11829.qmail@web60006.mail.yahoo.com> Is there an implementation of the Compare And Swap operation available for Linux_PPC64? thanks, Umut ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From lxiep at us.ibm.com Wed Jun 30 09:09:59 2004 From: lxiep at us.ibm.com (Linda Xie) Date: Tue, 29 Jun 2004 18:09:59 -0500 Subject: [PATCH] rpaphp broken in ameslab In-Reply-To: <40E1D5BE.2010504@austin.ibm.com> References: <40E1D5BE.2010504@austin.ibm.com> Message-ID: <40E1F6C7.80907@us.ibm.com> Hi Joel, Any changes to rpaphp(or rpaphp related) now should be posted on PCI hotplug mailing list (CC to kernel mailing list and Greg KH). After Greg applies the changes to his tree, the changes will be merged into amslab. BTW, I posted a separate patch that exports pci_scan_chid_bus for rpaphp a while ago. Greg, Can you apply the attached patch to your tree? Signed-off-by: Linda Xie lxie at us.ibm.com Thanks, Linda Joel Schopp wrote: > A couple of things got broken in ameslab. Not sure why or where, but > here is a patch that fixed it for me. Please apply to Ameslab barring > any objections. > > -Joel > >------------------------------------------------------------------------ > >diff -Nru a/drivers/pci/hotplug/rpaphp_core.c b/drivers/pci/hotplug/rpaphp_core.c >--- a/drivers/pci/hotplug/rpaphp_core.c Tue Jun 29 13:42:55 2004 >+++ b/drivers/pci/hotplug/rpaphp_core.c Tue Jun 29 13:42:55 2004 >@@ -455,11 +455,6 @@ > return disable_slot(rpaphp_find_hotplug_slot(dev)); > } > >-static int rpaphp_disable_slot(struct pci_dev *dev) >-{ >- return disable_slot(rpaphp_find_hotplug_slot(dev)); >-} >- > static int disable_slot(struct hotplug_slot *hotplug_slot) > { > int retval; >diff -Nru a/drivers/pci/probe.c b/drivers/pci/probe.c >--- a/drivers/pci/probe.c Tue Jun 29 13:42:55 2004 >+++ b/drivers/pci/probe.c Tue Jun 29 13:42:55 2004 >@@ -326,7 +326,7 @@ > return child; > } > >-static unsigned int __devinit pci_scan_child_bus(struct pci_bus *bus); >+unsigned int __devinit pci_scan_child_bus(struct pci_bus *bus); > > /* > * If it's a bridge, configure it and scan the bus behind it. >@@ -694,7 +694,7 @@ > return nr; > } > >-static unsigned int __devinit pci_scan_child_bus(struct pci_bus *bus) >+unsigned int __devinit pci_scan_child_bus(struct pci_bus *bus) > { > unsigned int devfn, pass, max = bus->secondary; > struct pci_dev *dev; > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: probe.patch Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20040629/e969eab5/attachment.txt From benh at kernel.crashing.org Wed Jun 30 11:40:44 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Tue, 29 Jun 2004 20:40:44 -0500 Subject: compare and swap In-Reply-To: <20040629224311.11829.qmail@web60006.mail.yahoo.com> References: <20040629224311.11829.qmail@web60006.mail.yahoo.com> Message-ID: <1088559644.1922.5.camel@gaston> On Tue, 2004-06-29 at 17:43, umut aymakoglu wrote: > Is there an implementation of the Compare And Swap > operation available for Linux_PPC64? look for cmpxchg in include/asm-ppc64/system.h Ben. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From paulus at samba.org Wed Jun 30 16:09:10 2004 From: paulus at samba.org (Paul Mackerras) Date: Wed, 30 Jun 2004 16:09:10 +1000 Subject: [PATCH] rpaphp broken in ameslab In-Reply-To: <40E1F6C7.80907@us.ibm.com> References: <40E1D5BE.2010504@austin.ibm.com> <40E1F6C7.80907@us.ibm.com> Message-ID: <16610.22790.655073.704981@cargo.ozlabs.ibm.com> Linda, > Any changes to rpaphp(or rpaphp related) now should be posted on PCI > hotplug mailing list (CC to kernel mailing list and Greg KH). After The change to drivers/pci/hotplug/rpaphp_core.c was simply that rpaphp_disable_slot got duplicated due to a mis-merge. I'm happy to fix that in ameslab, particularly as it makes ameslab match upstream. The other change I agree should go through Greg. By the way, I notice that upstream rpaphp_core.c now has the call to eeh_register_disable_func(), although the actual function isn't present in arch/ppc64/kernel/eeh.c. I thought we were going to do that via userspace. Did Greg change his mind? Just on that issue, in principle I think that it is reasonable for a device driver to know about the state of the hardware it is controlling (without needing userspace to tell it), and I consider that the isolation status of a slot is part of that state. So I think that the rpaphp code *should* be informed by the eeh code when a slot gets isolated. I think that we have it the wrong way around though. I think that the rpaphp code should do something analogous to a request_irq() to ask to be informed about slot isolation events, rather than having the EEH code call the rpaphp code to disable a slot. In fact I think the separation is bogus; the EEH code and the rpaphp code are both part of the driver for the RPA PCI subsystem. Paul. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From david at gibson.dropbear.id.au Wed Jun 30 16:51:05 2004 From: david at gibson.dropbear.id.au (David Gibson) Date: Wed, 30 Jun 2004 16:51:05 +1000 Subject: RFC: Dynamic segment table allocation Message-ID: <20040630065105.GA19054@zax> Can anyone see a problem with the patch below? If not, I plan to push it to Andrew in the next few days. Boots on a 4-way Power3 (RS/6000 270) and an RS64 iSeries lpar. PPC64 machines before Power4 need a segment table page allocated for each CPU. Currently these are allocated statically in a big array in head.S for all CPUs. However, except for the boot CPU, there are no particular constraints on the segment table's location, and the secondary CPUs don't come up until quite late when get_free_pages() is operational. This patch dynamically allocates segment table pages as the secondary CPUs come up. This reduces the kernel image size by 192k... Signed-off-by: David Gibson Index: working-2.6/arch/ppc64/kernel/head.S =================================================================== --- working-2.6.orig/arch/ppc64/kernel/head.S 2004-06-30 16:01:34.503673448 +1000 +++ working-2.6/arch/ppc64/kernel/head.S 2004-06-30 16:04:44.314702496 +1000 @@ -2201,11 +2201,6 @@ ioremap_dir: .space 4096 -/* 1 page segment table per cpu (max 48, cpu0 allocated at STAB0_PHYS_ADDR) */ - .globl stab_array -stab_array: - .space 4096 * 48 - /* * This space gets a copy of optional info passed to us by the bootstrap * Used to pass parameters into the kernel like root=/dev/sda1, etc. Index: working-2.6/arch/ppc64/kernel/smp.c =================================================================== --- working-2.6.orig/arch/ppc64/kernel/smp.c 2004-06-30 16:01:34.506672992 +1000 +++ working-2.6/arch/ppc64/kernel/smp.c 2004-06-30 16:12:44.944722104 +1000 @@ -877,16 +877,17 @@ paca[cpu].default_decr = tb_ticks_per_jiffy / decr_overclock; if (!(cur_cpu_spec->cpu_features & CPU_FTR_SLB)) { - void *tmp; + unsigned long newstab; - /* maximum of 48 CPUs on machines with a segment table */ - if (cpu >= 48) - BUG(); - - tmp = &stab_array[PAGE_SIZE * cpu]; - memset(tmp, 0, PAGE_SIZE); - paca[cpu].stab_addr = (unsigned long)tmp; - paca[cpu].stab_real = virt_to_abs(tmp); + newstab = __get_free_page(GFP_KERNEL); + if (! newstab) { + printk(KERN_ERR "__cpu_up(): Unable to allocate segment table for CPU %d\n", cpu); + return -ENOMEM; + } + + memset((void *)newstab, 0, PAGE_SIZE); + paca[cpu].stab_addr = newstab; + paca[cpu].stab_real = virt_to_abs(newstab); } /* The information for processor bringup must -- David Gibson | For every complex problem there is a david AT gibson.dropbear.id.au | solution which is simple, neat and | wrong. http://www.ozlabs.org/people/dgibson ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/