From trini at kernel.crashing.org Wed Feb 1 02:08:24 2006 From: trini at kernel.crashing.org (Tom Rini) Date: Tue, 31 Jan 2006 08:08:24 -0700 Subject: Maple fails to boot current git In-Reply-To: <1138679592.4934.1.camel@localhost.localdomain> References: <20060130171759.GE22672@smtp.west.cox.net> <20060130231118.GA19671@localhost.localdomain> <1138679592.4934.1.camel@localhost.localdomain> Message-ID: <20060131150824.GO22672@smtp.west.cox.net> On Tue, Jan 31, 2006 at 02:53:11PM +1100, Benjamin Herrenschmidt wrote: > On Tue, 2006-01-31 at 12:11 +1300, David Gibson wrote: > > On Mon, Jan 30, 2006 at 10:17:59AM -0700, Tom Rini wrote: > > > Hello, trying to boot my maple board (ppc64_defconfig + > > > CONFIG_PPC_EARLY_DEBUG_MAPLE=y) fails as follows (the "dirty" is > > > #define DEBUG in kernel/prom_parse.c and platforms/maple/time.c): > > > > Crud. Our Maple is stuffed at the moment (doesn't complete the CPU > > init script, so PIBS never even comes up on the 970), so I can't > > really investigate. > > Well, the RTC problem definitely looks like a bogus or lack of "ranges" > property or the fact that the parser doesn't recognize "ht" as a PCI > bus. You may want to try updating prom_parse.c to treat "ht" as a PCI > bus and see if that helps. With the following, I get parent bus is pci now, but still: OF: ** translation for device /ht at 0/isa at 4/rtc at 900 ** OF: bus is isa (na=2, ns=1) on /ht at 0/isa at 4 OF: translating address: 00000001 00000900 OF: parent bus is pci (na=3, ns=2) on /ht at 0 OF: walking ranges... OF: not found ! Maple: Unable to translate RTC address Maple: No device node for RTC, assuming legacy address (0x70) diff --git a/arch/powerpc/kernel/prom_parse.c b/arch/powerpc/kernel/prom_parse.c index a8099c8..6006201 100644 --- a/arch/powerpc/kernel/prom_parse.c +++ b/arch/powerpc/kernel/prom_parse.c @@ -1,4 +1,4 @@ -#undef DEBUG +#define DEBUG #include #include @@ -113,8 +113,10 @@ static unsigned int of_bus_default_get_f static int of_bus_pci_match(struct device_node *np) { - /* "vci" is for the /chaos bridge on 1st-gen PCI powermacs */ - return !strcmp(np->type, "pci") || !strcmp(np->type, "vci"); + /* "vci" is for the /chaos bridge on 1st-gen PCI powermacs, "ht" + * is the maple board. */ + return !strcmp(np->type, "pci") || !strcmp(np->type, "vci") || + !strcmp(np->type, "ht"); } static void of_bus_pci_count_cells(struct device_node *np, @@ -239,6 +241,16 @@ static struct of_bus of_busses[] = { .translate = of_bus_pci_translate, .get_flags = of_bus_pci_get_flags, }, + /* HT */ + { + .name = "ht", + .addresses = "assigned-addresses", + .match = of_bus_pci_match, + .count_cells = of_bus_pci_count_cells, + .map = of_bus_pci_map, + .translate = of_bus_pci_translate, + .get_flags = of_bus_pci_get_flags, + }, /* ISA */ { .name = "isa", -- Tom Rini http://gate.crashing.org/~trini/ From trini at kernel.crashing.org Wed Feb 1 02:11:17 2006 From: trini at kernel.crashing.org (Tom Rini) Date: Tue, 31 Jan 2006 08:11:17 -0700 Subject: [PATCH 2.6.16-rc1] Fix booting Maple boards (was: Re: LINUXPPC64 Maple fails to boot current git) In-Reply-To: <1138662630.3417.26.camel@brick.watson.ibm.com> References: <20060130171759.GE22672@smtp.west.cox.net> <1138662630.3417.26.camel@brick.watson.ibm.com> Message-ID: <20060131151117.GP22672@smtp.west.cox.net> On Mon, Jan 30, 2006 at 06:10:30PM -0500, Michal Ostrowski wrote: > I saw something similar on a JS-20 w SLOF. The last message you see is > related to the RTC driver, but the next thing to run after that is > console_init(), which was where my system was dying. > > Dropping the "#ifdef CONFIG_ISA" statements in > arch/powerpc/kernel/legacy_serial.c appears to fix things, and I've been > told that a patch to this effect has been posted (though I've yet to see > it). The following gets my Maple booting again, and I _think_ is testing what was intended --- When looking for legacy serial ports, condition poking of "ISA" areas on CONFIG_GENERIC_ISA_DMA, rather than CONFIG_ISA as some boards (such as the Maple) have no ISA slots, but do have ISA serial ports. Signed-off-by: Tom Rini arch/powerpc/kernel/legacy_serial.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c index f970ace..3dd7b39 100644 --- a/arch/powerpc/kernel/legacy_serial.c +++ b/arch/powerpc/kernel/legacy_serial.c @@ -134,7 +134,7 @@ static int __init add_legacy_soc_port(st return add_legacy_port(np, -1, UPIO_MEM, addr, addr, NO_IRQ, flags); } -#ifdef CONFIG_ISA +#ifdef CONFIG_GENERIC_ISA_DMA static int __init add_legacy_isa_port(struct device_node *np, struct device_node *isa_brg) { @@ -276,7 +276,7 @@ void __init find_legacy_serial_ports(voi of_node_put(soc); } -#ifdef CONFIG_ISA +#ifdef CONFIG_GENERIC_ISA_DMA /* First fill our array with ISA ports */ for (np = NULL; (np = of_find_node_by_type(np, "serial"));) { struct device_node *isa = of_get_parent(np); -- Tom Rini http://gate.crashing.org/~trini/ From linas at austin.ibm.com Wed Feb 1 07:22:14 2006 From: linas at austin.ibm.com (linas) Date: Tue, 31 Jan 2006 14:22:14 -0600 Subject: creating PCI-related sysfs entries Message-ID: <20060131202214.GZ19465@austin.ibm.com> Hi, I want to create some sysfs entries in order to report on the status of PCI slots. (If you are guessing that this pertains to the PCI error recovery code, you'd be right). I'm having trouble figuring out the best way to do this. There are existing entries at /sys/bus/pci/slots/... but these are for hotplug slots only; none of the soldered-onto-the-MB devices show up here. Is this intentional, or is this a bug/ overshight/not-yet-implemented thing? I also want to report some roll-up system-wide statistics both /sys/module and /sys/class seem reasonable. My code does not compile as a module. Suggestions? Yes, I'm going to RTFM shortly after I hit the send key, assuming I find the FM. --linas From greg at kroah.com Wed Feb 1 07:34:56 2006 From: greg at kroah.com (Greg KH) Date: Tue, 31 Jan 2006 12:34:56 -0800 Subject: creating PCI-related sysfs entries In-Reply-To: <20060131202214.GZ19465@austin.ibm.com> References: <20060131202214.GZ19465@austin.ibm.com> Message-ID: <20060131203456.GA23819@kroah.com> On Tue, Jan 31, 2006 at 02:22:14PM -0600, linas wrote: > > Hi, > > I want to create some sysfs entries in order to report on the > status of PCI slots. (If you are guessing that this pertains > to the PCI error recovery code, you'd be right). I'm having > trouble figuring out the best way to do this. > > There are existing entries at /sys/bus/pci/slots/... but these > are for hotplug slots only; none of the soldered-onto-the-MB > devices show up here. Is this intentional, or is this a bug/ > overshight/not-yet-implemented thing? Not implemented, as it's up to a pci hotplug controller driver to provide those slots. It sounds like your driver needs to be expanded :) > I also want to report some roll-up system-wide statistics > both /sys/module and /sys/class seem reasonable. My code > does not compile as a module. Suggestions? What kind of statistics? Is this driver related? PCI bus related? Device related? thanks, greg k-h From linas at austin.ibm.com Wed Feb 1 08:08:05 2006 From: linas at austin.ibm.com (linas) Date: Tue, 31 Jan 2006 15:08:05 -0600 Subject: creating PCI-related sysfs entries In-Reply-To: <20060131203456.GA23819@kroah.com> References: <20060131202214.GZ19465@austin.ibm.com> <20060131203456.GA23819@kroah.com> Message-ID: <20060131210805.GA19465@austin.ibm.com> On Tue, Jan 31, 2006 at 12:34:56PM -0800, Greg KH was heard to remark: > On Tue, Jan 31, 2006 at 02:22:14PM -0600, linas wrote: > > > > I want to create some sysfs entries in order to report on the > > status of PCI slots. (If you are guessing that this pertains > > to the PCI error recovery code, you'd be right). I'm having > > trouble figuring out the best way to do this. > > > > There are existing entries at /sys/bus/pci/slots/... but these > > are for hotplug slots only; none of the soldered-onto-the-MB > > devices show up here. Is this intentional, or is this a bug/ > > overshight/not-yet-implemented thing? > > Not implemented, as it's up to a pci hotplug controller driver to > provide those slots. It sounds like your driver needs to be expanded :) Hmm. But these slots are not hot-plugabble; should the arch use the hotplug infrastructure even on those slots? I note that /sys/devices/pciXXXX does have all of the pci slos listed, so perhaps that is where I can place per-slot data. > > I also want to report some roll-up system-wide statistics > > both /sys/module and /sys/class seem reasonable. My code > > does not compile as a module. Suggestions? > > What kind of statistics? Is this driver related? PCI bus related? > Device related? Related to the PCI error recovery. I'm not sure how to conceptually peg this: one could say that it is the driver for a specific type of pci-host bridge, although the code is not currently structured as such. Should I try to restructure it as such? If so, I'm not clear on how to proceed; I can't say I've clearly seen a kernel abstraction of a pci-host bridge device onto which to staple myself. I wanted to report a few read-only statistics, and a few writeable parameters: Read-only: -- total number of PCI device resets due to detected errors -- total number of "false positives" (probable errors that weren't) -- some other misc related stats. Most, but not all, of these statistics could be obtained by totalling up the per-slot statistics. Writable: -- Number of reset tries to perform before concluding that the device is hopelessly dead. Resets are disruptive and intensive, and I don't want to get stuck in an inf loop on a dead device. Linas. From greg at kroah.com Wed Feb 1 08:26:24 2006 From: greg at kroah.com (Greg KH) Date: Tue, 31 Jan 2006 13:26:24 -0800 Subject: creating PCI-related sysfs entries In-Reply-To: <20060131210805.GA19465@austin.ibm.com> References: <20060131202214.GZ19465@austin.ibm.com> <20060131203456.GA23819@kroah.com> <20060131210805.GA19465@austin.ibm.com> Message-ID: <20060131212624.GA10513@kroah.com> On Tue, Jan 31, 2006 at 03:08:05PM -0600, linas wrote: > On Tue, Jan 31, 2006 at 12:34:56PM -0800, Greg KH was heard to remark: > > On Tue, Jan 31, 2006 at 02:22:14PM -0600, linas wrote: > > > > > > I want to create some sysfs entries in order to report on the > > > status of PCI slots. (If you are guessing that this pertains > > > to the PCI error recovery code, you'd be right). I'm having > > > trouble figuring out the best way to do this. > > > > > > There are existing entries at /sys/bus/pci/slots/... but these > > > are for hotplug slots only; none of the soldered-onto-the-MB > > > devices show up here. Is this intentional, or is this a bug/ > > > overshight/not-yet-implemented thing? > > > > Not implemented, as it's up to a pci hotplug controller driver to > > provide those slots. It sounds like your driver needs to be expanded :) > > Hmm. But these slots are not hot-plugabble; should the arch > use the hotplug infrastructure even on those slots? Why not? It's a good place to put them, right? > I note that /sys/devices/pciXXXX does have all of the pci > slos listed, so perhaps that is where I can place per-slot data. That's only because your arch might happen to have 1 device per slot, which is not true for other arches. And I bet it's also not true for your non-virtual boxes... > > > I also want to report some roll-up system-wide statistics > > > both /sys/module and /sys/class seem reasonable. My code > > > does not compile as a module. Suggestions? > > > > What kind of statistics? Is this driver related? PCI bus related? > > Device related? > > Related to the PCI error recovery. I'm not sure how to conceptually > peg this: one could say that it is the driver for a specific type > of pci-host bridge, although the code is not currently structured > as such. Should I try to restructure it as such? If so, I'm not > clear on how to proceed; I can't say I've clearly seen a kernel > abstraction of a pci-host bridge device onto which to staple myself. People have suggested that they create such a driver for a long time. Why not just do that? > I wanted to report a few read-only statistics, and a few writeable > parameters: > > Read-only: > -- total number of PCI device resets due to detected errors > -- total number of "false positives" (probable errors that weren't) > -- some other misc related stats. These are all "per slot" right? > Most, but not all, of these statistics could be obtained by > totalling up the per-slot statistics. > > Writable: > -- Number of reset tries to perform before concluding that the > device is hopelessly dead. Resets are disruptive and intensive, > and I don't want to get stuck in an inf loop on a dead device. Why would you want to change this value? Just pick one at build time. thanks, greg k-h From benh at kernel.crashing.org Wed Feb 1 08:31:34 2006 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Wed, 01 Feb 2006 08:31:34 +1100 Subject: Maple fails to boot current git In-Reply-To: <20060131150824.GO22672@smtp.west.cox.net> References: <20060130171759.GE22672@smtp.west.cox.net> <20060130231118.GA19671@localhost.localdomain> <1138679592.4934.1.camel@localhost.localdomain> <20060131150824.GO22672@smtp.west.cox.net> Message-ID: <1138743094.4934.11.camel@localhost.localdomain> On Tue, 2006-01-31 at 08:08 -0700, Tom Rini wrote: > On Tue, Jan 31, 2006 at 02:53:11PM +1100, Benjamin Herrenschmidt wrote: > > On Tue, 2006-01-31 at 12:11 +1300, David Gibson wrote: > > > On Mon, Jan 30, 2006 at 10:17:59AM -0700, Tom Rini wrote: > > > > Hello, trying to boot my maple board (ppc64_defconfig + > > > > CONFIG_PPC_EARLY_DEBUG_MAPLE=y) fails as follows (the "dirty" is > > > > #define DEBUG in kernel/prom_parse.c and platforms/maple/time.c): > > > > > > Crud. Our Maple is stuffed at the moment (doesn't complete the CPU > > > init script, so PIBS never even comes up on the 970), so I can't > > > really investigate. > > > > Well, the RTC problem definitely looks like a bogus or lack of "ranges" > > property or the fact that the parser doesn't recognize "ht" as a PCI > > bus. You may want to try updating prom_parse.c to treat "ht" as a PCI > > bus and see if that helps. > > With the following, I get parent bus is pci now, but still: > OF: ** translation for device /ht at 0/isa at 4/rtc at 900 ** > OF: bus is isa (na=2, ns=1) on /ht at 0/isa at 4 > OF: translating address: 00000001 00000900 > OF: parent bus is pci (na=3, ns=2) on /ht at 0 > OF: walking ranges... > OF: not found ! > Maple: Unable to translate RTC address > Maple: No device node for RTC, assuming legacy address (0x70) Can you send me the device-tree dump ? Ben. From markh at osdl.org Wed Feb 1 08:33:00 2006 From: markh at osdl.org (Mark Haverkamp) Date: Tue, 31 Jan 2006 13:33:00 -0800 Subject: iommu_alloc failure and panic In-Reply-To: <43DF691E.1020008@emulex.com> References: <200601310118.k0V1Il7Z018408@falcon30.maxeymade.com> <43DF691E.1020008@emulex.com> Message-ID: <1138743180.15732.15.camel@markh3.pdx.osdl.net> On Tue, 2006-01-31 at 08:41 -0500, James Smart wrote: > >> 2) The emulex driver has been prone to problems in the past where it's > >> been very aggressive at starting DMA operations, and I think it can > >> be avoided with tuning. What I don't know is if it's because of this, > >> or simply because of the large number of targets you have. Cc:ing James > >> Smart. > > I don't have data points for the 2.6 kernel, but I can comment on what I > have seen on the 2.4 kernel. > > The issue that I saw on the 2.4 kernel was that the pci dma alloc routine > was inappropriately allocating from the dma s/g maps. On systems with less > than 4Gig of memory, or on those with no iommmu (emt64), the checks around > adapter-supported dma masks were off (I'm going to be loose in terms to not > describe it in detail). The result was, although the adapter could support > a fully 64bit address and/or although the physical dma address would be under > 32-bits, the logic forced allocation from the mapped dma pool. On some > systems, this pool was originally only 16MB. Around 2.4.30, the swiotlb was > introduced, which reduced issue, but unfortunately, still never solved the > allocation logic. It fails less as the swiotlb simply had more space. > As far as I know, this problem doesn't exist in the 2.6 kernel. I'd have to > go look at the dma map functions to make sure. > > Why was the lpfc driver prone to the dma map exhaustion failures ? Due to the > default # of commands per lun and max sg segments reported by the driver to > the scsi midlayer, the scsi mid-layer's preallocation of dma maps for commands > for each lun, and the fact that our FC configs were usually large, had lots > of luns, and replicated the resources for each path to the same storage. > > Ultimately, what I think is the real issue here is the way the scsi mid-layer > is preallocating dma maps for the luns. 16000 luns is a huge number. > Multiply this by a max sg segment count of 64 by the driver, and a number > between 3 and 30 commands per lun, and you can see the numbers. Scsi does do > some interesting allocation algorithms once it hits an allocation failure. > One side effect of this is that it is fairly efficient at allocating the > bulk of the dma pool. James, Thanks for the information. I tried loading the lpfc driver with lpfc_lun_queue_depth=1 and haven't seen iommu_alloc failures. I'm still curious why the alloc failures lead to a panic though. Mark. > > -- james s -- Mark Haverkamp From grundler at parisc-linux.org Wed Feb 1 09:48:52 2006 From: grundler at parisc-linux.org (Grant Grundler) Date: Tue, 31 Jan 2006 15:48:52 -0700 Subject: creating PCI-related sysfs entries In-Reply-To: <20060131210805.GA19465@austin.ibm.com> References: <20060131202214.GZ19465@austin.ibm.com> <20060131203456.GA23819@kroah.com> <20060131210805.GA19465@austin.ibm.com> Message-ID: <20060131224852.GA25579@colo.lackof.org> On Tue, Jan 31, 2006 at 03:08:05PM -0600, linas wrote: > Related to the PCI error recovery. I'm not sure how to conceptually > peg this: one could say that it is the driver for a specific type > of pci-host bridge, although the code is not currently structured > as such. Should I try to restructure it as such? If so, I'm not > clear on how to proceed; I can't say I've clearly seen a kernel > abstraction of a pci-host bridge device onto which to staple myself. AFAIK, no pci-host device abstraction exists. Each arch deals with pci-host bridges as it sees fit. But access methods to some PCI features are abstracted: o method access to CFG space o method to register IRQs o advertise MMIO/IO Port routing. Sounds like you want to add another method for error recovery stats/control. grant From James.Smart at Emulex.Com Wed Feb 1 00:41:50 2006 From: James.Smart at Emulex.Com (James Smart) Date: Tue, 31 Jan 2006 08:41:50 -0500 Subject: iommu_alloc failure and panic In-Reply-To: <200601310118.k0V1Il7Z018408@falcon30.maxeymade.com> References: <200601310118.k0V1Il7Z018408@falcon30.maxeymade.com> Message-ID: <43DF691E.1020008@emulex.com> >> 2) The emulex driver has been prone to problems in the past where it's >> been very aggressive at starting DMA operations, and I think it can >> be avoided with tuning. What I don't know is if it's because of this, >> or simply because of the large number of targets you have. Cc:ing James >> Smart. I don't have data points for the 2.6 kernel, but I can comment on what I have seen on the 2.4 kernel. The issue that I saw on the 2.4 kernel was that the pci dma alloc routine was inappropriately allocating from the dma s/g maps. On systems with less than 4Gig of memory, or on those with no iommmu (emt64), the checks around adapter-supported dma masks were off (I'm going to be loose in terms to not describe it in detail). The result was, although the adapter could support a fully 64bit address and/or although the physical dma address would be under 32-bits, the logic forced allocation from the mapped dma pool. On some systems, this pool was originally only 16MB. Around 2.4.30, the swiotlb was introduced, which reduced issue, but unfortunately, still never solved the allocation logic. It fails less as the swiotlb simply had more space. As far as I know, this problem doesn't exist in the 2.6 kernel. I'd have to go look at the dma map functions to make sure. Why was the lpfc driver prone to the dma map exhaustion failures ? Due to the default # of commands per lun and max sg segments reported by the driver to the scsi midlayer, the scsi mid-layer's preallocation of dma maps for commands for each lun, and the fact that our FC configs were usually large, had lots of luns, and replicated the resources for each path to the same storage. Ultimately, what I think is the real issue here is the way the scsi mid-layer is preallocating dma maps for the luns. 16000 luns is a huge number. Multiply this by a max sg segment count of 64 by the driver, and a number between 3 and 30 commands per lun, and you can see the numbers. Scsi does do some interesting allocation algorithms once it hits an allocation failure. One side effect of this is that it is fairly efficient at allocating the bulk of the dma pool. -- james s From olh at suse.de Wed Feb 1 19:26:21 2006 From: olh at suse.de (Olaf Hering) Date: Wed, 1 Feb 2006 09:26:21 +0100 Subject: [PATCH] ppc64: per cpu data optimisations In-Reply-To: <20060111021644.GC4767@krispykreme> References: <20060111021644.GC4767@krispykreme> Message-ID: <20060201082621.GA29274@suse.de> On Wed, Jan 11, Anton Blanchard wrote: Anton, this causes trouble if you have sles10 installed and if runlevel 6 is your default runlevel (aka reboot in a loop). Whats wrong with the patch? See https://bugzilla.novell.com/show_bug.cgi?id=145459 for details. there are 2 other bugs which are seen also on other archs, will start looking at them now. -- short story of a lazy sysadmin: alias appserv=wotan From linas at austin.ibm.com Thu Feb 2 08:30:18 2006 From: linas at austin.ibm.com (linas) Date: Wed, 1 Feb 2006 15:30:18 -0600 Subject: creating PCI-related sysfs entries In-Reply-To: <20060131212624.GA10513@kroah.com> References: <20060131202214.GZ19465@austin.ibm.com> <20060131203456.GA23819@kroah.com> <20060131210805.GA19465@austin.ibm.com> <20060131212624.GA10513@kroah.com> Message-ID: <20060201213018.GG14705@austin.ibm.com> On Tue, Jan 31, 2006 at 01:26:24PM -0800, Greg KH was heard to remark: > On Tue, Jan 31, 2006 at 03:08:05PM -0600, linas wrote: > > > > ... the PCI error recovery. I'm not sure how to conceptually > > peg this: one could say that it is the driver for a specific type > > of pci-host bridge, although the code is not currently structured > > as such. Should I try to restructure it as such? If so, I'm not > > clear on how to proceed; I can't say I've clearly seen a kernel > > abstraction of a pci-host bridge device onto which to staple myself. > > People have suggested that they create such a driver for a long time. > Why not just do that? OK. Let me get this straight, then. Create a generic struct pci_host_bridge, which encapsulates some (all?) of the functions that Grant Grundler mentions in his email: Grant Grundler : <> Each arch deals with pci-host bridges as it sees fit. <> <>But access methods to some PCI features are abstracted: <>o method access to CFG space <>o method to register IRQs <>o advertise MMIO/IO Port routing. At the risk of over-engineering, maybe there should be a struct bus_host_bridge, and struct pci_host_bridge would derive from that? --linas p.s. rest of message: > > I wanted to report a few read-only statistics, and a few writeable > > parameters: > > > > Read-only: > > -- total number of PCI device resets due to detected errors > > -- total number of "false positives" (probable errors that weren't) > > -- some other misc related stats. > > These are all "per slot" right? Right. I'll keep them that way. > > Writable: > > -- Number of reset tries to perform before concluding that the > > device is hopelessly dead. Resets are disruptive and intensive, > > and I don't want to get stuck in an inf loop on a dead device. > > Why would you want to change this value? Just pick one at build time. OK. --linas From linas at austin.ibm.com Thu Feb 2 08:35:46 2006 From: linas at austin.ibm.com (linas) Date: Wed, 1 Feb 2006 15:35:46 -0600 Subject: creating PCI-related sysfs entries In-Reply-To: <20060131224852.GA25579@colo.lackof.org> References: <20060131202214.GZ19465@austin.ibm.com> <20060131203456.GA23819@kroah.com> <20060131210805.GA19465@austin.ibm.com> <20060131224852.GA25579@colo.lackof.org> Message-ID: <20060201213546.GH14705@austin.ibm.com> On Tue, Jan 31, 2006 at 03:48:52PM -0700, Grant Grundler was heard to remark: > On Tue, Jan 31, 2006 at 03:08:05PM -0600, linas wrote: > > Related to the PCI error recovery. I'm not sure how to conceptually > > peg this: one could say that it is the driver for a specific type > > of pci-host bridge, although the code is not currently structured > > as such. Should I try to restructure it as such? If so, I'm not > > clear on how to proceed; I can't say I've clearly seen a kernel > > abstraction of a pci-host bridge device onto which to staple myself. > > AFAIK, no pci-host device abstraction exists. > Each arch deals with pci-host bridges as it sees fit. > > But access methods to some PCI features are abstracted: > o method access to CFG space > o method to register IRQs > o advertise MMIO/IO Port routing. > > Sounds like you want to add another method for error recovery > stats/control. Actually, the "recovery" part is already (mostly) in mainline, See Documentation/pci-error-recovery.txt What's hanging out are patches to specific device drivers, which have been submitted, but haven't been accepted. Another issue is that there's no implementation at this time for any arch other than powerpc, although the latest pci express bridges support this function in principle. --linas From linas at austin.ibm.com Thu Feb 2 11:19:06 2006 From: linas at austin.ibm.com (Linas Vepstas) Date: Wed, 1 Feb 2006 18:19:06 -0600 Subject: [PATCH 1/2]: PowerPC/PCI Hotplug build break In-Reply-To: <1138833335.6933.5.camel@sinatra.austin.ibm.com> References: <1138833335.6933.5.camel@sinatra.austin.ibm.com> Message-ID: <20060202001906.GA24916@austin.ibm.com> Please apply ASAP: Build break: Building PCI hotplug on PowerPC results in a build break, due to failure to export symbols. Reported today by Dave Jones : drivers/pci/hotplug/rpaphp.ko needs unknown symbol pcibios_add_pci_devices This patch fixes the break in the arch/powerpc tree. Next patch fixes same problem in drivers/pci tree Signed-off-by: Linas Vepstas --- pci_dlpar.c | 3 +++ 1 files changed, 3 insertions(+) Index: linux-2.6.16-rc1-git5/arch/powerpc/platforms/pseries/pci_dlpar.c =================================================================== --- linux-2.6.16-rc1-git5.orig/arch/powerpc/platforms/pseries/pci_dlpar.c 2006-02-01 18:06:12.380829512 -0600 +++ linux-2.6.16-rc1-git5/arch/powerpc/platforms/pseries/pci_dlpar.c 2006-02-01 18:11:41.040673750 -0600 @@ -58,6 +58,7 @@ return find_bus_among_children(pdn->phb->bus, dn); } +EXPORT_SYMBOL_GPL(pcibios_find_pci_bus); /** * pcibios_remove_pci_devices - remove all devices under this bus @@ -106,6 +107,7 @@ } } } +EXPORT_SYMBOL_GPL(pcibios_fixup_new_pci_devices); static int pcibios_pci_config_bridge(struct pci_dev *dev) @@ -172,3 +174,4 @@ pcibios_pci_config_bridge(dev); } } +EXPORT_SYMBOL_GPL(pcibios_add_pci_devices); From linas at austin.ibm.com Thu Feb 2 11:21:09 2006 From: linas at austin.ibm.com (Linas Vepstas) Date: Wed, 1 Feb 2006 18:21:09 -0600 Subject: [PATCH 2/2]: PowerPC/PCI Hotplug build break Message-ID: <20060202002109.GB24916@austin.ibm.com> Please apply ASAP: Build break: Building PCI hotplug on PowerPC results in a build break, due to failure to export symbols. Reported today by Dave Jones : drivers/pci/hotplug/rpaphp.ko needs unknown symbol pcibios_add_pci_devices This patch fixes same problem in drivers/pci tree Previous patch fixes the break in the arch/powerpc tree. Signed-off-by: Linas Vepstas --- rpaphp_slot.c | 1 + 1 files changed, 1 insertion(+) Index: linux-2.6.16-rc1-git5/drivers/pci/hotplug/rpaphp_slot.c =================================================================== --- linux-2.6.16-rc1-git5.orig/drivers/pci/hotplug/rpaphp_slot.c 2006-02-01 18:06:06.022722369 -0600 +++ linux-2.6.16-rc1-git5/drivers/pci/hotplug/rpaphp_slot.c 2006-02-01 18:11:46.049970222 -0600 @@ -159,6 +159,7 @@ dbg("%s - Exit: rc[%d]\n", __FUNCTION__, retval); return retval; } +EXPORT_SYMBOL_GPL(rpaphp_deregister_slot); int rpaphp_register_slot(struct slot *slot) { From grundler at parisc-linux.org Thu Feb 2 16:52:43 2006 From: grundler at parisc-linux.org (Grant Grundler) Date: Wed, 1 Feb 2006 22:52:43 -0700 Subject: creating PCI-related sysfs entries In-Reply-To: <20060201213546.GH14705@austin.ibm.com> References: <20060131202214.GZ19465@austin.ibm.com> <20060131203456.GA23819@kroah.com> <20060131210805.GA19465@austin.ibm.com> <20060131224852.GA25579@colo.lackof.org> <20060201213546.GH14705@austin.ibm.com> Message-ID: <20060202055243.GA12588@colo.lackof.org> On Wed, Feb 01, 2006 at 03:35:46PM -0600, linas wrote: > > Sounds like you want to add another method for error recovery > > stats/control. > > Actually, the "recovery" part is already (mostly) in mainline, > See Documentation/pci-error-recovery.txt Yes - I've reviewed a few of the times you submitted it. What I meant was, you want to formalize error recovery methods and make it a peer to the other resources access methods I listed. ... > Another issue is that there's no implementation at this time for > any arch other than powerpc, Well, some ia64 chipsets have some limited support but it's really up to the respective companies to drive that. > although the latest pci express bridges support this function in principle. "Nguyen, Tom L" has proposed patches to support PCI-e AER (Advanced Error Reporting): http://lkml.org/lkml/2005/3/11/269 I've cc'd him in case he has an interest in resurrecting those patches and adapting them to the current framework (and vice versa). grant From linas at austin.ibm.com Fri Feb 3 03:36:36 2006 From: linas at austin.ibm.com (Linas Vepstas) Date: Thu, 2 Feb 2006 10:36:36 -0600 Subject: creating PCI-related sysfs entries In-Reply-To: <20060202055243.GA12588@colo.lackof.org> References: <20060131202214.GZ19465@austin.ibm.com> <20060131203456.GA23819@kroah.com> <20060131210805.GA19465@austin.ibm.com> <20060131224852.GA25579@colo.lackof.org> <20060201213546.GH14705@austin.ibm.com> <20060202055243.GA12588@colo.lackof.org> Message-ID: <20060202163636.GD24916@austin.ibm.com> On Wed, Feb 01, 2006 at 10:52:43PM -0700, Grant Grundler was heard to remark: > On Wed, Feb 01, 2006 at 03:35:46PM -0600, linas wrote: > > > Sounds like you want to add another method for error recovery > > > stats/control. > > > > Actually, the "recovery" part is already (mostly) in mainline, > > See Documentation/pci-error-recovery.txt > > What I meant was, you want to formalize error recovery methods > and make it a peer to the other resources access methods I listed. Hmm. Not sure what you mean by "a peer". pci config-space i/o is done through callbacks in the pci bus->ops structure. The PCI error recovery is done via callbacks in the pci dev structure. Was there something you'd like to see done differently? Given GregKH's remarks, it sounded like there was some interest in a "struct bus_host_bridge" abstraction, and I'd be willing to take a shot at that, provided there is general interest and general agreement. I'm not quite sure what such a struct might contain, just yet, I'm just imagining it might be non-empty. > "Nguyen, Tom L" has proposed patches > to support PCI-e AER (Advanced Error Reporting): I kept looking at AER, and could not figure out what to do with it. --linas From jfaslist at yahoo.fr Fri Feb 3 04:03:06 2006 From: jfaslist at yahoo.fr (jfaslist) Date: Thu, 02 Feb 2006 18:03:06 +0100 Subject: Maple freezing on PCI Target-Abort Message-ID: <43E23B4A.4020402@yahoo.fr> Hi, We have designed our own IBM970fx motherboard which is a (almost)clone to the IBM Maple reference kit. We are seeing that whenever a PIO read PCI cycle bound to the PCI bus that is across the AMD8111 is ended w/ a target-abort, the whole system freezes. The device signaling the TA is a PCI-VME bridge. It does so as the address passed is invalid. When the system hangs, using the service processor, I can access some AMD8111, CPC925 registers from which I can draw the following conclusions: 1- The AMD8111 secondary status tells me the AMD8111 got a TA 2- The CPC925 status/command register (0cf8070010) tells me that the TA error was forwarded to the CPC925. 3- The CPC925 APIEXCP register tells me that a DERR exception was signaled. From what I can read on the CPC925 and IBM970 cpu user manual, the DERR is the bus error that is returned to the CPU by the CPC925 to let him know that the cycle ended w/ an error. I have the following questions: -What exception vector is taking care of a DERR excp? From what I can see it seems to be the "machine check" vector. But that seems a bit drastic to me. After all this is just a PCI target abort. -I expect that the normal behavior would be for the kernel to send a signal termination to the user process which caused the PIO READ PCI cycle (from a previously mmap()'ed VMA address). Is it doable on this platform? Since a READ operation is coupled by nature, I think this is the only acceptable way. I have tried to set the MSR[RI] bit before doing the PCI cycle, but it didn't change change anything. Also on our design we disconnect the CPC925 checkstop pin from the 970 machine check pin.(see page 39 of cpc925 user's manual). So a DERR shouldn't cause a machine check I would think. I realize that these questions are very H/W related but couldn't find the answer in IBM doc. Thanks for the help, -- Best regards, _______________________________________ jean-francois simon - themis computer 5, rue irene joliot curie 38330 eybens - france +33 (0)4 76 14 77 85 ___________________________________________________________________________ Nouveau : t?l?phonez moins cher avec Yahoo! Messenger ! D?couvez les tarifs exceptionnels pour appeler la France et l'international. T?l?chargez sur http://fr.messenger.yahoo.com From grundler at parisc-linux.org Fri Feb 3 06:39:02 2006 From: grundler at parisc-linux.org (Grant Grundler) Date: Thu, 2 Feb 2006 12:39:02 -0700 Subject: creating PCI-related sysfs entries In-Reply-To: <20060202163636.GD24916@austin.ibm.com> References: <20060131202214.GZ19465@austin.ibm.com> <20060131203456.GA23819@kroah.com> <20060131210805.GA19465@austin.ibm.com> <20060131224852.GA25579@colo.lackof.org> <20060201213546.GH14705@austin.ibm.com> <20060202055243.GA12588@colo.lackof.org> <20060202163636.GD24916@austin.ibm.com> Message-ID: <20060202193902.GA5424@colo.lackof.org> On Thu, Feb 02, 2006 at 10:36:36AM -0600, Linas Vepstas wrote: > Hmm. Not sure what you mean by "a peer". Just at the same level of the architecture - i.e. a server like the others. > pci config-space i/o is done through callbacks in the pci bus->ops > structure. The PCI error recovery is done via callbacks in the pci dev > structure. Was there something you'd like to see done differently? No. Each set of callbacks serves a different purpose. The services/resources at the bus level are different from those at the device level. My guess is error handling/containment can abstract at the "bus" level since we can't always guarantee "one device per slot" (think multifunction devices). > Given GregKH's remarks, it sounded like there was some interest in > a "struct bus_host_bridge" abstraction, and I'd be willing > to take a shot at that, provided there is general interest and > general agreement. I'm not quite sure what such a struct might > contain, just yet, I'm just imagining it might be non-empty. Yes, I agree don't have a better idea other than what I already pointed out. > I kept looking at AER, and could not figure out what to do > with it. I haven't either - other folks in HP "own" that. grant From linas at austin.ibm.com Fri Feb 3 07:46:24 2006 From: linas at austin.ibm.com (Linas Vepstas) Date: Thu, 2 Feb 2006 14:46:24 -0600 Subject: creating PCI-related sysfs entries In-Reply-To: <20060202193902.GA5424@colo.lackof.org> References: <20060131202214.GZ19465@austin.ibm.com> <20060131203456.GA23819@kroah.com> <20060131210805.GA19465@austin.ibm.com> <20060131224852.GA25579@colo.lackof.org> <20060201213546.GH14705@austin.ibm.com> <20060202055243.GA12588@colo.lackof.org> <20060202163636.GD24916@austin.ibm.com> <20060202193902.GA5424@colo.lackof.org> Message-ID: <20060202204624.GM24916@austin.ibm.com> On Thu, Feb 02, 2006 at 12:39:02PM -0700, Grant Grundler was heard to remark: > > My guess is error handling/containment can abstract at the "bus" level > since we can't always guarantee "one device per slot" (think > multifunction devices). :-) Yes, testing with multi-function cards exposed bugs, but the code should work fine with them. In particular, the design allows multi-function devices to "vote" how they want to be reset, with the dumbest voter getting thier way. The bus disconnect is reported to all functions on all affected cards/slots. This allows all instances of a device driver to react appropriately. However, for card setup/init, typically, you want to have only one driver instance do that. You'll notice in the sym53cxx2 patch I just sent, there's a + if (PCI_FUNC(pdev->devfn) == 0) + sym_reset_scsi_bus(np, 0); so that the other instances don't fall over each other reseting. There's similar code in the e100 e1000 and ixgb drivers; I tested multi-function versions of these. (not sure about ixgb). > Yes, I agree don't have a better idea other than what I already > pointed out. Hmm. well, I may have lost the thread of what that was. --linas From geoffrey.levand at am.sony.com Fri Feb 3 09:47:12 2006 From: geoffrey.levand at am.sony.com (Geoff Levand) Date: Thu, 02 Feb 2006 14:47:12 -0800 Subject: [PATCH] spufs split off platform code In-Reply-To: <200601280457.08170.arnd@arndb.de> References: <200601280457.08170.arnd@arndb.de> Message-ID: <43E28BF0.8060700@am.sony.com> Arnd Bergmann wrote: > I guess that the "spc" device type can be removed now, I don't think > that > any systems are left that have not been converted. > > Do you have "spe" type nodes at all? Is there anything that you need to > do different about them? Yes, scp can be removed. I think we can arrange it so some of the create_spu code can go back to generic code. Still investigating... >>+void spu_free_irqs(struct spu *spu) >>+{ >>+???????int irq_base; >>+ >>+???????if(!spu->priv_data) { >>+???????????????pr_debug("null priv_data in %p\n", spu); >>+???????????????return; >>+???????} > > > It may be just me, but I don't like this bit of coding style: > You are trying to deal with priv_data being either allocated > or not allocated at this point. Better make sure that you have > freed the structure before returning an error from any function > that would allocate it on success. Then get rid of the check > here. Yes, it really doesn't add any value does it. >>+struct spu_priv_data; >>+struct spu_phys { >>+???????unsigned long addr; >>+???????unsigned long size; >>+}; >> >>?struct spu { >>+???????struct spu_priv_data *priv_data; /* opaque */ >>????????char *name; > > > If you want priv_data to point to different types of data structures > depending on the context, I find it easier to understand if there is > a simple void pointer and the actual struct definitions have different > type names. Yes, a good tip. I'm looking into pushing these differences down into the lower level platform code. Hopefully it will simplify these parts. -Geoff From linas at austin.ibm.com Fri Feb 3 11:06:02 2006 From: linas at austin.ibm.com (Linas Vepstas) Date: Thu, 2 Feb 2006 18:06:02 -0600 Subject: [PATCH]: Documentation: Updated PCI Error Recovery Message-ID: <20060203000602.GQ24916@austin.ibm.com> I'm not sure who I'm addressing this patch to: Linus, maybe? Please apply. Fingers crossed, I hope this may make it into 2.6.16. --linas This patch is a cleanup/restructuring/clarification of the PCI error handling doc. It should look rather professional at this point. Signed-off-by: Linas Vepstas -- pci-error-recovery.txt | 462 ++++++++++++++++++++++++++++++++----------------- 1 files changed, 306 insertions(+), 156 deletions(-) Index: linux-2.6.16-rc1-git5/Documentation/pci-error-recovery.txt =================================================================== --- linux-2.6.16-rc1-git5.orig/Documentation/pci-error-recovery.txt 2006-02-01 17:09:01.000000000 -0600 +++ linux-2.6.16-rc1-git5/Documentation/pci-error-recovery.txt 2006-02-02 18:04:57.714942210 -0600 @@ -1,246 +1,396 @@ PCI Error Recovery ------------------ - May 31, 2005 + February 2, 2006 - Current document maintainer: - Linas Vepstas + Current document maintainer: + Linas Vepstas -Some PCI bus controllers are able to detect certain "hard" PCI errors -on the bus, such as parity errors on the data and address busses, as -well as SERR and PERR errors. These chipsets are then able to disable -I/O to/from the affected device, so that, for example, a bad DMA -address doesn't end up corrupting system memory. These same chipsets -are also able to reset the affected PCI device, and return it to -working condition. This document describes a generic API form -performing error recovery. - -The core idea is that after a PCI error has been detected, there must -be a way for the kernel to coordinate with all affected device drivers -so that the pci card can be made operational again, possibly after -performing a full electrical #RST of the PCI card. The API below -provides a generic API for device drivers to be notified of PCI -errors, and to be notified of, and respond to, a reset sequence. - -Preliminary sketch of API, cut-n-pasted-n-modified email from -Ben Herrenschmidt, circa 5 april 2005 +Many PCI bus controllers are able to detect a variety of hardware +PCI errors on the bus, such as parity errors on the data and address +busses, as well as SERR and PERR errors. Some of the more advanced +chipsets are able to deal with these errors; these include PCI-E chipsets, +and the PCI-host bridges found on IBM Power4 and Power5-based pSeries +boxes. A typical action taken is to disconnect the affected device, +halting all I/O to it. The goal of a disconnection is to avoid system +corruption; for example, to halt system memory corruption due to DMA's +to "wild" addresses. Typically, a reconnection mechanism is also +offered, so that the affected PCI device(s) are reset and put back +into working condition. The reset phase requires coordination +between the affected device drivers and the PCI controller chip. +This document describes a generic API for notifying device drivers +of a bus disconnection, and then performing error recovery. +This API is currently implemented in the 2.6.16 and later kernels. + +Reporting and recovery is performed in several steps. First, when +a PCI hardware error has resulted in a bus disconnect, that event +is reported as soon as possible to all affected device drivers, +including multiple instances of a device driver on multi-function +cards. This allows device drivers to avoid deadlocking in spinloops, +waiting for some i/o-space register to change, when it never will. +It also gives the drivers a chance to defer incoming I/O as +needed. + +Next, recovery is performed in several stages. Most of the complexity +is forced by the need to handle multi-function devices, that is, +devices that have multiple device drivers associated with them. +In the first stage, each driver is allowed to indicate what type +of reset it desires, the choices being a simple re-enabling of I/O +or requesting a hard reset (a full electrical #RST of the PCI card). +If any driver requests a full reset, that is what will be done. + +After a full reset and/or a re-enabling of I/O, all drivers are +again notified, so that they may then perform any device setup/config +that may be required. After these have all completed, a final +"resume normal operations" event is sent out. + +The biggest reason for choosing a kernel-based implementation rather +than a user-space implementation was the need to deal with bus +disconnects of PCI devices attached to storage media, and, in particular, +disconnects from devices holding the root file system. If the root +file system is disconnected, a user-space mechanism would have to go +through a large number of contortions to complete recovery. Almost all +of the current Linux file systems are not tolerant of disconnection +from/reconnection to their underlying block device. By contrast, +bus errors are easy to manage in the device driver. Indeed, most +device drivers already handle very similar recovery procedures; +for example, the SCSI-generic layer already provides significant +mechanisms for dealing with SCSI bus errors and SCSI bus resets. + + +Detailed Design +--------------- +Design and implementation details below, based on a chain of +public email discussions with Ben Herrenschmidt, circa 5 April 2005. The error recovery API support is exposed to the driver in the form of a structure of function pointers pointed to by a new field in struct -pci_driver. The absence of this pointer in pci_driver denotes an -"non-aware" driver, behaviour on these is platform dependant. -Platforms like ppc64 can try to simulate pci hotplug remove/add. - -The definition of "pci_error_token" is not covered here. It is based on -Seto's work on the synchronous error detection. We still need to define -functions for extracting infos out of an opaque error token. This is -separate from this API. +pci_driver. A driver that fails to provide the structure is "non-aware", +and the actual recovery steps taken are platform dependent. The +arch/powerpc implementation will simulate a PCI hotplug remove/add. This structure has the form: - struct pci_error_handlers { - int (*error_detected)(struct pci_dev *dev, pci_error_token error); + int (*error_detected)(struct pci_dev *dev, enum pci_channel_state); int (*mmio_enabled)(struct pci_dev *dev); - int (*resume)(struct pci_dev *dev); int (*link_reset)(struct pci_dev *dev); int (*slot_reset)(struct pci_dev *dev); + void (*resume)(struct pci_dev *dev); +}; + +The possible channel states are: +enum pci_channel_state { + pci_channel_io_normal, /* I/O channel is in normal state */ + pci_channel_io_frozen, /* I/O to channel is blocked */ + pci_channel_io_perm_failure, /* PCI card is dead */ +}; + +Possible return values are: +enum pci_ers_result { + PCI_ERS_RESULT_NONE, /* no result/none/not supported in device driver */ + PCI_ERS_RESULT_CAN_RECOVER, /* Device driver can recover without slot reset */ + PCI_ERS_RESULT_NEED_RESET, /* Device driver wants slot to be reset. */ + PCI_ERS_RESULT_DISCONNECT, /* Device has completely failed, is unrecoverable */ + PCI_ERS_RESULT_RECOVERED, /* Device driver is fully recovered and operational */ }; -A driver doesn't have to implement all of these callbacks. The -only mandatory one is error_detected(). If a callback is not -implemented, the corresponding feature is considered unsupported. -For example, if mmio_enabled() and resume() aren't there, then the -driver is assumed as not doing any direct recovery and requires +A driver does not have to implement all of these callbacks; however, +if it implements any, it must implement error_detected(). If a callback +is not implemented, the corresponding feature is considered unsupported. +For example, if mmio_enabled() and resume() aren't there, then it +is assumed that the driver is not doing any direct recovery and requires a reset. If link_reset() is not implemented, the card is assumed as -not caring about link resets, in which case, if recover is supported, -the core can try recover (but not slot_reset() unless it really did -reset the slot). If slot_reset() is not supported, link_reset() can -be called instead on a slot reset. - -At first, the call will always be : - - 1) error_detected() - - Error detected. This is sent once after an error has been detected. At -this point, the device might not be accessible anymore depending on the -platform (the slot will be isolated on ppc64). The driver may already -have "noticed" the error because of a failing IO, but this is the proper -"synchronisation point", that is, it gives a chance to the driver to -cleanup, waiting for pending stuff (timers, whatever, etc...) to -complete; it can take semaphores, schedule, etc... everything but touch -the device. Within this function and after it returns, the driver +not care about link resets. Typically a driver will want to know about +a slot_reset(). + +The actual steps taken by a platform to recover from a PCI error +event will be platform-dependent, but will follow the general +sequence described below. + +STEP 0: Error Event +------------------- +PCI bus error is detect by the PCI hardware. On powerpc, the slot +is isolated, in that all I/O is blocked: all reads return 0xffffffff, +all writes are ignored. + + +STEP 1: Notification +-------------------- +Platform calls the error_detected() callback on every instance of +every driver affected by the error. + +At this point, the device might not be accessible anymore, depending on +the platform (the slot will be isolated on powerpc). The driver may +already have "noticed" the error because of a failing I/O, but this +is the proper "synchronization point", that is, it gives the driver +a chance to cleanup, waiting for pending stuff (timers, whatever, etc...) +to complete; it can take semaphores, schedule, etc... everything but +touch the device. Within this function and after it returns, the driver shouldn't do any new IOs. Called in task context. This is sort of a "quiesce" point. See note about interrupts at the end of this doc. - Result codes: - - PCIERR_RESULT_CAN_RECOVER: - Driever returns this if it thinks it might be able to recover +All drivers participating in this system must implement this call. +The driver must return one of the following result codes: + - PCI_ERS_RESULT_CAN_RECOVER: + Driver returns this if it thinks it might be able to recover the HW by just banging IOs or if it wants to be given - a chance to extract some diagnostic informations (see - below). - - PCIERR_RESULT_NEED_RESET: - Driver returns this if it thinks it can't recover unless the - slot is reset. - - PCIERR_RESULT_DISCONNECT: - Return this if driver thinks it won't recover at all, - (this will detach the driver ? or just leave it - dangling ? to be decided) - -So at this point, we have called error_detected() for all drivers -on the segment that had the error. On ppc64, the slot is isolated. What -happens now typically depends on the result from the drivers. If all -drivers on the segment/slot return PCIERR_RESULT_CAN_RECOVER, we would -re-enable IOs on the slot (or do nothing special if the platform doesn't -isolate slots) and call 2). If not and we can reset slots, we go to 4), -if neither, we have a dead slot. If it's an hotplug slot, we might -"simulate" reset by triggering HW unplug/replug though. + a chance to extract some diagnostic information (see + mmio_enable, below). + - PCI_ERS_RESULT_NEED_RESET: + Driver returns this if it can't recover without a hard + slot reset. + - PCI_ERS_RESULT_DISCONNECT: + Driver returns this if it doesn't want to recover at all. + +The next step taken will depend on the result codes returned by the +drivers. + +If all drivers on the segment/slot return PCI_ERS_RESULT_CAN_RECOVER, +then the platform should re-enable IOs on the slot (or do nothing in +particular, if the platform doesn't isolate slots), and recovery +proceeds to STEP 2 (MMIO Enable). + +If any driver requested a slot reset (by returning PCI_ERS_RESULT_NEED_RESET), +then recovery proceeds to STEP 4 (Slot Reset). + +If the platform is unable to recover the slot, the next step +is STEP 6 (Permanent Failure). ->>> Current ppc64 implementation assumes that a device driver will ->>> *not* schedule or semaphore in this routine; the current ppc64 +>>> The current powerpc implementation assumes that a device driver will +>>> *not* schedule or semaphore in this routine; the current powerpc >>> implementation uses one kernel thread to notify all devices; ->>> thus, of one device sleeps/schedules, all devices are affected. +>>> thus, if one device sleeps/schedules, all devices are affected. >>> Doing better requires complex multi-threaded logic in the error >>> recovery implementation (e.g. waiting for all notification threads >>> to "join" before proceeding with recovery.) This seems excessively >>> complex and not worth implementing. ->>> The current ppc64 implementation doesn't much care if the device ->>> attempts i/o at this point, or not. I/O's will fail, returning +>>> The current powerpc implementation doesn't much care if the device +>>> attempts I/O at this point, or not. I/O's will fail, returning >>> a value of 0xff on read, and writes will be dropped. If the device >>> driver attempts more than 10K I/O's to a frozen adapter, it will >>> assume that the device driver has gone into an infinite loop, and ->>> it will panic the the kernel. +>>> it will panic the the kernel. There doesn't seem to be any other +>>> way of stopping a device driver that insists on spinning on I/O. - 2) mmio_enabled() +STEP 2: MMIO Enabled +------------------- +The platform re-enables MMIO to the device (but typically not the +DMA), and then calls the mmio_enabled() callback on all affected +device drivers. - This is the "early recovery" call. IOs are allowed again, but DMA is +This is the "early recovery" call. IOs are allowed again, but DMA is not (hrm... to be discussed, I prefer not), with some restrictions. This is NOT a callback for the driver to start operations again, only to peek/poke at the device, extract diagnostic information, if any, and eventually do things like trigger a device local reset or some such, -but not restart operations. This is sent if all drivers on a segment -agree that they can try to recover and no automatic link reset was -performed by the HW. If the platform can't just re-enable IOs without -a slot reset or a link reset, it doesn't call this callback and goes -directly to 3) or 4). All IOs should be done _synchronously_ from -within this callback, errors triggered by them will be returned via -the normal pci_check_whatever() api, no new error_detected() callback -will be issued due to an error happening here. However, such an error -might cause IOs to be re-blocked for the whole segment, and thus -invalidate the recovery that other devices on the same segment might -have done, forcing the whole segment into one of the next states, -that is link reset or slot reset. +but not restart operations. This is callback is made if all drivers on +a segment agree that they can try to recover and if no automatic link reset +was performed by the HW. If the platform can't just re-enable IOs without +a slot reset or a link reset, it wont call this callback, and instead +will have gone directly to STEP 3 (Link Reset) or STEP 4 (Slot Reset) + +>>> The following is proposed; no platform implements this yet: +>>> Proposal: All I/O's should be done _synchronously_ from within +>>> this callback, errors triggered by them will be returned via +>>> the normal pci_check_whatever() API, no new error_detected() +>>> callback will be issued due to an error happening here. However, +>>> such an error might cause IOs to be re-blocked for the whole +>>> segment, and thus invalidate the recovery that other devices +>>> on the same segment might have done, forcing the whole segment +>>> into one of the next states, that is, link reset or slot reset. - Result codes: - - PCIERR_RESULT_RECOVERED +The driver should return one of the following result codes: + - PCI_ERS_RESULT_RECOVERED Driver returns this if it thinks the device is fully - functionnal and thinks it is ready to start + functional and thinks it is ready to start normal driver operations again. There is no guarantee that the driver will actually be allowed to proceed, as another driver on the same segment might have failed and thus triggered a slot reset on platforms that support it. - - PCIERR_RESULT_NEED_RESET + - PCI_ERS_RESULT_NEED_RESET Driver returns this if it thinks the device is not recoverable in it's current state and it needs a slot reset to proceed. - - PCIERR_RESULT_DISCONNECT + - PCI_ERS_RESULT_DISCONNECT Same as above. Total failure, no recovery even after reset driver dead. (To be defined more precisely) ->>> The current ppc64 implementation does not implement this callback. - - 3) link_reset() - - This is called after the link has been reset. This is typically -a PCI Express specific state at this point and is done whenever a -non-fatal error has been detected that can be "solved" by resetting -the link. This call informs the driver of the reset and the driver -should check if the device appears to be in working condition. -This function acts a bit like 2) mmio_enabled(), in that the driver -is not supposed to restart normal driver I/O operations right away. -Instead, it should just "probe" the device to check it's recoverability -status. If all is right, then the core will call resume() once all -drivers have ack'd link_reset(). +The next step taken depends on the results returned by the drivers. +If all drivers returned PCI_ERS_RESULT_RECOVERED, then the platform +proceeds to either STEP3 (Link Reset) or to STEP 5 (Resume Operations). + +If any driver returned PCI_ERS_RESULT_NEED_RESET, then the platform +proceeds to STEP 4 (Slot Reset) + +>>> The current powerpc implementation does not implement this callback. + + +STEP 3: Link Reset +------------------ +The platform resets the link, and then calls the link_reset() callback +on all affected device drivers. This is a PCI-Express specific state +and is done whenever a non-fatal error has been detected that can be +"solved" by resetting the link. This call informs the driver of the +reset and the driver should check to see if the device appears to be +in working condition. + +The driver is not supposed to restart normal driver I/O operations +at this point. It should limit itself to "probing" the device to +check it's recoverability status. If all is right, then the platform +will call resume() once all drivers have ack'd link_reset(). Result codes: - (identical to mmio_enabled) + (identical to STEP 3 (MMIO Enabled) ->>> The current ppc64 implementation does not implement this callback. +The platform then proceeds to either STEP 4 (Slot Reset) or STEP 5 +(Resume Operations). - 4) slot_reset() +>>> The current powerpc implementation does not implement this callback. - This is called after the slot has been soft or hard reset by the -platform. A soft reset consists of asserting the adapter #RST line -and then restoring the PCI BARs and PCI configuration header. If the -platform supports PCI hotplug, then it might instead perform a hard -reset by toggling power on the slot off/on. This call gives drivers -the chance to re-initialize the hardware (re-download firmware, etc.), -but drivers shouldn't restart normal I/O processing operations at -this point. (See note about interrupts; interrupts aren't guaranteed -to be delivered until the resume() callback has been called). If all -device drivers report success on this callback, the patform will call -resume() to complete the error handling and let the driver restart -normal I/O processing. + +STEP 4: Slot Reset +------------------ +The platform performs a soft or hard reset of the device, and then +calls the slot_reset() callback. + +A soft reset consists of asserting the adapter #RST line and then +restoring the PCI BAR's and PCI configuration header to a state +that is equivalent to what it would be after a fresh system +power-on followed by power-on BIOS/system firmware initialization. +If the platform supports PCI hotplug, then the reset might be +performed by toggling the slot electrical power off/on. + +It is important for the platform to restore the PCI config space +to the "fresh poweron" state, rather than the "last state". After +a slot reset, the device driver will almost always use its standard +device initialization routines, and an unusual config space setup +may result in hung devices, kernel panics, or silent data corruption. + +This call gives drivers the chance to re-initialize the hardware +(re-download firmware, etc.). At this point, the driver may assume +that he card is in a fresh state and is fully functional. In +particular, interrupt generation should work normally. + +Drivers should not yet restart normal I/O processing operations +at this point. If all device drivers report success on this +callback, the platform will call resume() to complete the sequence, +and let the driver restart normal I/O processing. A driver can still return a critical failure for this function if it can't get the device operational after reset. If the platform -previously tried a soft reset, it migh now try a hard reset (power +previously tried a soft reset, it might now try a hard reset (power cycle) and then call slot_reset() again. It the device still can't be recovered, there is nothing more that can be done; the platform will typically report a "permanent failure" in such a case. The device will be considered "dead" in this case. +Drivers for multi-function cards will need to coordinate among +themselves as to which driver instance will perform any "one-shot" +or global device initialization. For example, the Symbios sym53cxx2 +driver performs device init only from PCI function 0: + ++ if (PCI_FUNC(pdev->devfn) == 0) ++ sym_reset_scsi_bus(np, 0); + Result codes: - - PCIERR_RESULT_DISCONNECT + - PCI_ERS_RESULT_DISCONNECT Same as above. ->>> The current ppc64 implementation does not try a power-cycle reset ->>> if the driver returned PCIERR_RESULT_DISCONNECT. However, it should. - - 5) resume() +Platform proceeds either to STEP 5 (Resume Operations) or STEP 6 (Permanent +Failure). - This is called if all drivers on the segment have returned -PCIERR_RESULT_RECOVERED from one of the 3 prevous callbacks. -That basically tells the driver to restart activity, tht everything -is back and running. No result code is taken into account here. If -a new error happens, it will restart a new error handling process. - -That's it. I think this covers all the possibilities. The way those -callbacks are called is platform policy. A platform with no slot reset -capability for example may want to just "ignore" drivers that can't +>>> The current powerpc implementation does not currently try a +>>> power-cycle reset if the driver returned PCI_ERS_RESULT_DISCONNECT. +>>> However, it probably should. + + +STEP 5: Resume Operations +------------------------- +The platform will call the resume() callback on all affected device +drivers if all drivers on the segment have returned +PCI_ERS_RESULT_RECOVERED from one of the 3 previous callbacks. +The goal of this callback is to tell the driver to restart activity, +that everything is back and running. This callback does not return +a result code. + +At this point, if a new error happens, the platform will restart +a new error recovery sequence. + +STEP 6: Permanent Failure +------------------------- +A "permanent failure" has occurred, and the platform cannot recover +the device. The platform will call error_detected() with a +pci_channel_state value of pci_channel_io_perm_failure. + +The device driver should, at this point, assume the worst. It should +cancel all pending I/O, refuse all new I/O, returning -EIO to +higher layers. The device driver should then clean up all of its +memory and remove itself from kernel operations, much as it would +during system shutdown. + +The platform will typically notify the system operator of the +permanent failure in some way. If the device is hotplug-capable, +the operator will probably want to remove and replace the device. +Note, however, not all failures are truly "permanent". Some are +caused by over-heating, some by a poorly seated card. Many +PCI error events are caused by software bugs, e.g. DMA's to +wild addresses or bogus split transactions due to programming +errors. See the discussion in powerpc/eeh-pci-error-recovery.txt +for additional detail on real-life experience of the causes of +software errors. + + +Conclusion; General Remarks +--------------------------- +The way those callbacks are called is platform policy. A platform with +no slot reset capability may want to just "ignore" drivers that can't recover (disconnect them) and try to let other cards on the same segment recover. Keep in mind that in most real life cases, though, there will be only one driver per segment. -Now, there is a note about interrupts. If you get an interrupt and your +Now, a note about interrupts. If you get an interrupt and your device is dead or has been isolated, there is a problem :) - -After much thinking, I decided to leave that to the platform. That is, -the recovery API only precies that: +The current policy is to turn this into a platform policy. +That is, the recovery API only requires that: - There is no guarantee that interrupt delivery can proceed from any device on the segment starting from the error detection and until the -restart callback is sent, at which point interrupts are expected to be +resume callback is sent, at which point interrupts are expected to be fully operational. - - There is no guarantee that interrupt delivery is stopped, that is, ad -river that gets an interrupts after detecting an error, or that detects -and error within the interrupt handler such that it prevents proper + - There is no guarantee that interrupt delivery is stopped, that is, +a driver that gets an interrupt after detecting an error, or that detects +an error within the interrupt handler such that it prevents proper ack'ing of the interrupt (and thus removal of the source) should just -return IRQ_NOTHANDLED. It's up to the platform to deal with taht -condition, typically by masking the irq source during the duration of +return IRQ_NOTHANDLED. It's up to the platform to deal with that +condition, typically by masking the IRQ source during the duration of the error handling. It is expected that the platform "knows" which interrupts are routed to error-management capable slots and can deal -with temporarily disabling that irq number during error processing (this +with temporarily disabling that IRQ number during error processing (this isn't terribly complex). That means some IRQ latency for other devices sharing the interrupt, but there is simply no other way. High end platforms aren't supposed to share interrupts between many devices anyway :) +>>> Implementation details for the powerpc platform are discussed in +>>> the file Documentation/powerpc/eeh-pci-error-recovery.txt + +>>> As of this writing, there are six device drivers with patches +>>> implementing error recovery. Not all of these patches are in +>>> mainline yet. These may be used as "examples": +>>> +>>> drivers/scsi/ipr.c +>>> drivers/scsi/sym53cxx_2 +>>> drivers/next/e100.c +>>> drivers/net/e1000 +>>> drivers/net/ixgb +>>> drivers/net/s2io.c -Revised: 31 May 2005 Linas Vepstas +The End +------- From benh at kernel.crashing.org Fri Feb 3 12:42:37 2006 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Fri, 03 Feb 2006 12:42:37 +1100 Subject: Maple freezing on PCI Target-Abort In-Reply-To: <43E23B4A.4020402@yahoo.fr> References: <43E23B4A.4020402@yahoo.fr> Message-ID: <1138930958.4934.102.camel@localhost.localdomain> > -What exception vector is taking care of a DERR excp? From what I can > see it seems to be the "machine check" vector. But that seems a bit > drastic to me. After all this is just a PCI target abort. I would expect a machine check yes. > -I expect that the normal behavior would be for the kernel to send a > signal termination to the user process which caused the PIO READ PCI > cycle (from a previously mmap()'ed VMA address). Is it doable on this > platform? Since a READ operation is coupled by nature, I think this is > the only acceptable way. It should SIGBUS except if the problem occurred in the kernel. I don't know why it's not doing so, maybe you are hitting an issue/errata or misconfiguration of the 925 ? > I have tried to set the MSR[RI] bit before doing the PCI cycle, but it > didn't change change anything. Also on our design we disconnect the > CPC925 checkstop pin from the 970 machine check pin.(see page 39 of > cpc925 user's manual). So a DERR shouldn't cause a machine check I would > think. > > I realize that these questions are very H/W related but couldn't find > the answer in IBM doc. From benh at kernel.crashing.org Fri Feb 3 12:45:03 2006 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Fri, 03 Feb 2006 12:45:03 +1100 Subject: creating PCI-related sysfs entries In-Reply-To: <20060131210805.GA19465@austin.ibm.com> References: <20060131202214.GZ19465@austin.ibm.com> <20060131203456.GA23819@kroah.com> <20060131210805.GA19465@austin.ibm.com> Message-ID: <1138931103.4934.105.camel@localhost.localdomain> On Tue, 2006-01-31 at 15:08 -0600, linas wrote: > Hmm. But these slots are not hot-plugabble; should the arch > use the hotplug infrastructure even on those slots? If those are EEH slots, they should probably treated as hotplugable... after all, didn't we discuss back then that one strategy we could use for recovery simulating an unplug/replug to the driver along with a slot hard reset ? From benh at kernel.crashing.org Fri Feb 3 12:56:01 2006 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Fri, 03 Feb 2006 12:56:01 +1100 Subject: [PATCH 2.6.16-rc1] Fix booting Maple boards (was: Re: LINUXPPC64 Maple fails to boot current git) In-Reply-To: <20060131151117.GP22672@smtp.west.cox.net> References: <20060130171759.GE22672@smtp.west.cox.net> <1138662630.3417.26.camel@brick.watson.ibm.com> <20060131151117.GP22672@smtp.west.cox.net> Message-ID: <1138931761.4934.113.camel@localhost.localdomain> > When looking for legacy serial ports, condition poking of "ISA" areas > on CONFIG_GENERIC_ISA_DMA, rather than CONFIG_ISA as some boards (such > as the Maple) have no ISA slots, but do have ISA serial ports. Hrm... not sure ISA_DMA has anything to do with that at all.. in fact its more like "has legacy devices". I don't remember adding the ifdef CONFIG_ISA in the first place, maybe I did... it's a bit dodgy I'd say. Indeed, lots of machines have ISA devices (a superIO typically) without having ISA slots... Ben. > Signed-off-by: Tom Rini > > arch/powerpc/kernel/legacy_serial.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c > index f970ace..3dd7b39 100644 > --- a/arch/powerpc/kernel/legacy_serial.c > +++ b/arch/powerpc/kernel/legacy_serial.c > @@ -134,7 +134,7 @@ static int __init add_legacy_soc_port(st > return add_legacy_port(np, -1, UPIO_MEM, addr, addr, NO_IRQ, flags); > } > > -#ifdef CONFIG_ISA > +#ifdef CONFIG_GENERIC_ISA_DMA > static int __init add_legacy_isa_port(struct device_node *np, > struct device_node *isa_brg) > { > @@ -276,7 +276,7 @@ void __init find_legacy_serial_ports(voi > of_node_put(soc); > } > > -#ifdef CONFIG_ISA > +#ifdef CONFIG_GENERIC_ISA_DMA > /* First fill our array with ISA ports */ > for (np = NULL; (np = of_find_node_by_type(np, "serial"));) { > struct device_node *isa = of_get_parent(np); > From benh at kernel.crashing.org Fri Feb 3 12:53:21 2006 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Fri, 03 Feb 2006 12:53:21 +1100 Subject: creating PCI-related sysfs entries In-Reply-To: <20060131212624.GA10513@kroah.com> References: <20060131202214.GZ19465@austin.ibm.com> <20060131203456.GA23819@kroah.com> <20060131210805.GA19465@austin.ibm.com> <20060131212624.GA10513@kroah.com> Message-ID: <1138931602.4934.110.camel@localhost.localdomain> > That's only because your arch might happen to have 1 device per slot, > which is not true for other arches. And I bet it's also not true for > your non-virtual boxes... Even that is not true since we can have multi-function devices or devices with p2p bridges but the basic entity where the error management infos is available to us is indeed the physical slot. > People have suggested that they create such a driver for a long time. > Why not just do that? Depends if he wants per domain statistics or really per slot ... we do have per-slot control on most of IBM machines, thus I would rather have these info there (though if he also wants consolidated "global" stats, then yes, a host controller driver might be the way to go). From linas at austin.ibm.com Fri Feb 3 13:03:41 2006 From: linas at austin.ibm.com (Linas Vepstas) Date: Thu, 2 Feb 2006 20:03:41 -0600 Subject: creating PCI-related sysfs entries In-Reply-To: <1138931103.4934.105.camel@localhost.localdomain> References: <20060131202214.GZ19465@austin.ibm.com> <20060131203456.GA23819@kroah.com> <20060131210805.GA19465@austin.ibm.com> <1138931103.4934.105.camel@localhost.localdomain> Message-ID: <20060203020341.GR24916@austin.ibm.com> On Fri, Feb 03, 2006 at 12:45:03PM +1100, Benjamin Herrenschmidt was heard to remark: > On Tue, 2006-01-31 at 15:08 -0600, linas wrote: > > > Hmm. But these slots are not hot-plugabble; should the arch > > use the hotplug infrastructure even on those slots? > > If those are EEH slots, they should probably treated as hotplugable... > after all, didn't we discuss back then that one strategy we could use > for recovery simulating an unplug/replug to the driver along with a slot > hard reset ? Yes, and EEH does do that (in mainline, 10K times in a row, last I tried). This email was in reference to the layout of /sys/bus/pci/slots which seems to have only hotplug slots in there; I am not yet sure why. Its possible John Rose can shed some rapid insight? --linas From gregkh at suse.de Fri Feb 3 14:48:41 2006 From: gregkh at suse.de (Greg KH) Date: Thu, 2 Feb 2006 19:48:41 -0800 Subject: [PATCH]: Documentation: Updated PCI Error Recovery In-Reply-To: <20060203000602.GQ24916@austin.ibm.com> References: <20060203000602.GQ24916@austin.ibm.com> Message-ID: <20060203034841.GA14169@suse.de> On Thu, Feb 02, 2006 at 06:06:02PM -0600, Linas Vepstas wrote: > > I'm not sure who I'm addressing this patch to: Linus, maybe? As it's PCI related, I'll take it, like the other PCI stuff, and put it into my trees, which go into -mm, and then into Linus's tree. I'll add this to my queue. thanks, greg k-h From boutcher at cs.umn.edu Fri Feb 3 18:18:50 2006 From: boutcher at cs.umn.edu (Dave C Boutcher) Date: Fri, 3 Feb 2006 01:18:50 -0600 Subject: [PATCH 0/3] powerpc minor fixes to the rtas_percpu_suspend_me routine Message-ID: <17379.986.599275.637898@hound.rchland.ibm.com> A series of small fixes to the rtas_percpu_suspend_me routine for problems discovered since it was pushed to 2.6.16-rc1. Dave Boutcher From boutcher at cs.umn.edu Fri Feb 3 18:18:36 2006 From: boutcher at cs.umn.edu (Dave C Boutcher) Date: Fri, 3 Feb 2006 01:18:36 -0600 Subject: [PATCH 3/3] powerpc remove useless call to touch_softlockup_watchdog Message-ID: <17379.972.53558.75428@hound.rchland.ibm.com> It turns out that we can't stop the watchdog from triggering here. If we touch the timer (which just uses the current jiffie value) before we enable interrupts, it does nothing because jiffies are not mass-updated until after we enable interrupts. If we touch the timer after we enable interrupts, its too late because the softlockup watchdog will already have triggered. The touch_softlockup_watchdog call removed below does nothing. Signed-off-by: Dave Boutcher --- arch/powerpc/kernel/rtas.c | 4 ---- 1 files changed, 0 insertions(+), 4 deletions(-) 14caae1e3b5508ce8798618f9f952f14e7c6d41a diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c index 4038ac1..1ecfcf8 100644 --- a/arch/powerpc/kernel/rtas.c +++ b/arch/powerpc/kernel/rtas.c @@ -598,10 +598,6 @@ static void rtas_percpu_suspend_me(void } out: - /* before we restore interrupts, make sure we don't - * generate a spurious soft lockup errors - */ - touch_softlockup_watchdog(); local_irq_restore(flags); return; } -- 1.1.4.g7310 From boutcher at cs.umn.edu Fri Feb 3 18:18:39 2006 From: boutcher at cs.umn.edu (Dave C Boutcher) Date: Fri, 3 Feb 2006 01:18:39 -0600 Subject: [PATCH 2/3] powerpc prod all processors after ibm,suspend-me Message-ID: <17379.975.326033.286493@hound.rchland.ibm.com> We need to prod everyone here since this is the only CPU that is guaranteed to be running after the ibm,suspend-me RTAS call returns. Signed-off-by: Dave Boutcher --- arch/powerpc/kernel/rtas.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) 9d615a50c077f82926732c8b9f366bebe50a4660 diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c index 107bd86..4038ac1 100644 --- a/arch/powerpc/kernel/rtas.c +++ b/arch/powerpc/kernel/rtas.c @@ -565,6 +565,7 @@ static int ibm_suspend_me_token = RTAS_U #ifdef CONFIG_PPC_PSERIES static void rtas_percpu_suspend_me(void *info) { + int i; long rc; long flags; struct rtas_suspend_me_data *data = @@ -589,6 +590,8 @@ static void rtas_percpu_suspend_me(void data->waiting = 0; data->args->args[data->args->nargs] = rtas_call(ibm_suspend_me_token, 0, 1, NULL); + for_each_cpu(i) + plpar_hcall_norets(H_PROD,i); } else { data->waiting = -EBUSY; printk(KERN_ERR "Error on H_Join hypervisor call\n"); -- 1.1.4.g7310 From boutcher at cs.umn.edu Fri Feb 3 18:18:46 2006 From: boutcher at cs.umn.edu (Dave C Boutcher) Date: Fri, 3 Feb 2006 01:18:46 -0600 Subject: [PATCH 1/3] powerpc return correct rtas status from ibm,suspend-me Message-ID: <17379.982.159401.407606@hound.rchland.ibm.com> Correctly return the status from the RTAS call. rtas_call expects to return the status as a return value. Signed-off-by: Dave Boutcher --- arch/powerpc/kernel/rtas.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) a0f3095607ff19d730f2ed5181bd37df231d4015 diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c index 7fe4a5c..107bd86 100644 --- a/arch/powerpc/kernel/rtas.c +++ b/arch/powerpc/kernel/rtas.c @@ -587,8 +587,8 @@ static void rtas_percpu_suspend_me(void if (rc == H_Continue) { data->waiting = 0; - rtas_call(ibm_suspend_me_token, 0, 1, - data->args->args); + data->args->args[data->args->nargs] = + rtas_call(ibm_suspend_me_token, 0, 1, NULL); } else { data->waiting = -EBUSY; printk(KERN_ERR "Error on H_Join hypervisor call\n"); -- 1.1.4.g7310 From michael at ellerman.id.au Fri Feb 3 19:05:14 2006 From: michael at ellerman.id.au (Michael Ellerman) Date: Fri, 03 Feb 2006 19:05:14 +1100 Subject: [PATCH] powerpc: Don't start secondary CPUs in a UP && KEXEC kernel Message-ID: <20060203080536.DA5AF68A10@ozlabs.org> Because smp_release_cpus() is built for SMP || KEXEC, it's not safe to unconditionally call it from setup_system(). On a UP && KEXEC kernel we'll start up the secondary CPUs which will then go beserk and we die. Simple fix is to conditionally call smp_release_cpus() in setup_system(). We that in place we don't need the dummy definition of smp_release_cpus() because all call sites are #ifdef'ed either SMP or KEXEC. Signed-off-by: Michael Ellerman --- arch/powerpc/kernel/setup_64.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Index: kdump/arch/powerpc/kernel/setup_64.c =================================================================== --- kdump.orig/arch/powerpc/kernel/setup_64.c +++ kdump/arch/powerpc/kernel/setup_64.c @@ -311,8 +311,6 @@ void smp_release_cpus(void) DBG(" <- smp_release_cpus()\n"); } -#else -#define smp_release_cpus() #endif /* CONFIG_SMP || CONFIG_KEXEC */ /* @@ -470,10 +468,12 @@ void __init setup_system(void) check_smt_enabled(); smp_setup_cpu_maps(); +#ifdef CONFIG_SMP /* Release secondary cpus out of their spinloops at 0x60 now that * we can map physical -> logical CPU ids */ smp_release_cpus(); +#endif printk("Starting Linux PPC64 %s\n", system_utsname.version); From michael at ellerman.id.au Fri Feb 3 19:05:47 2006 From: michael at ellerman.id.au (Michael Ellerman) Date: Fri, 03 Feb 2006 19:05:47 +1100 Subject: [PATCH] powerpc: Don't overwrite flat device tree with kdump kernel Message-ID: <20060203080609.403CA68A1F@ozlabs.org> It's possible for prom_init to allocate the flat device tree inside the kdump crash kernel region. If this happens, when we load the kdump kernel we overwrite the flattened device tree, which is bad. We could make prom_init try and avoid allocating inside the crash kernel region, but then we run into issues if the crash kernel region uses all the space inside the RMO. The easiest solution is to move the flat device tree once we're running in the kernel. Signed-off-by: Michael Ellerman --- arch/powerpc/kernel/prom.c | 27 +++++++++++++++++++++++++++ arch/powerpc/kernel/setup_64.c | 3 +++ include/asm-powerpc/prom.h | 2 ++ 3 files changed, 32 insertions(+) Index: kdump/arch/powerpc/kernel/prom.c =================================================================== --- kdump.orig/arch/powerpc/kernel/prom.c +++ kdump/arch/powerpc/kernel/prom.c @@ -1913,3 +1913,30 @@ int prom_update_property(struct device_n return 0; } + +#ifdef CONFIG_KEXEC +/* We may have allocated the flat device tree inside the crash kernel region + * in prom_init. If so we need to move it out into regular memory. */ +void kdump_move_device_tree(void) +{ + unsigned long start, end; + struct boot_param_header *new; + + start = __pa((unsigned long)initial_boot_params); + end = start + initial_boot_params->totalsize; + + if (end < crashk_res.start || start > crashk_res.end) + return; + + new = (struct boot_param_header*) + __va(lmb_alloc(initial_boot_params->totalsize, PAGE_SIZE)); + + memcpy(new, initial_boot_params, initial_boot_params->totalsize); + + initial_boot_params = new; + + DBG("Flat device tree blob moved to %p\n", initial_boot_params); + + /* XXX should we unreserve the old DT? */ +} +#endif /* CONFIG_KEXEC */ Index: kdump/arch/powerpc/kernel/setup_64.c =================================================================== --- kdump.orig/arch/powerpc/kernel/setup_64.c +++ kdump/arch/powerpc/kernel/setup_64.c @@ -398,6 +398,9 @@ void __init setup_system(void) { DBG(" -> setup_system()\n"); +#ifdef CONFIG_KEXEC + kdump_move_device_tree(); +#endif /* * Unflatten the device-tree passed by prom_init or kexec */ Index: kdump/include/asm-powerpc/prom.h =================================================================== --- kdump.orig/include/asm-powerpc/prom.h +++ kdump/include/asm-powerpc/prom.h @@ -222,5 +222,7 @@ extern int of_address_to_resource(struct extern int of_pci_address_to_resource(struct device_node *dev, int bar, struct resource *r); +extern void kdump_move_device_tree(void); + #endif /* __KERNEL__ */ #endif /* _POWERPC_PROM_H */ From benh at kernel.crashing.org Fri Feb 3 20:07:37 2006 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Fri, 03 Feb 2006 20:07:37 +1100 Subject: creating PCI-related sysfs entries In-Reply-To: <20060203020341.GR24916@austin.ibm.com> References: <20060131202214.GZ19465@austin.ibm.com> <20060131203456.GA23819@kroah.com> <20060131210805.GA19465@austin.ibm.com> <1138931103.4934.105.camel@localhost.localdomain> <20060203020341.GR24916@austin.ibm.com> Message-ID: <1138957657.4934.124.camel@localhost.localdomain> On Thu, 2006-02-02 at 20:03 -0600, Linas Vepstas wrote: > Yes, and EEH does do that (in mainline, 10K times in a row, > last I tried). This email was in reference to the > layout of /sys/bus/pci/slots which seems to have only hotplug > slots in there; I am not yet sure why. Its possible John Rose > can shed some rapid insight? Ok... also, about this "max number of resets" thing, it would be useful in fact to have a rate limit rather ... a network card that for some reason need to be reset about once a day is still fairly useable and it would be nice if the system didn't consider it dead after 10 days ... Also, it might be useful to have an entry to force a retry on a card that has been considered dead... Ben. From galak at kernel.crashing.org Sat Feb 4 01:25:08 2006 From: galak at kernel.crashing.org (Kumar Gala) Date: Fri, 3 Feb 2006 08:25:08 -0600 Subject: [PATCH] powerpc: Don't overwrite flat device tree with kdump kernel In-Reply-To: <20060203080609.403CA68A1F@ozlabs.org> References: <20060203080609.403CA68A1F@ozlabs.org> Message-ID: <8FC7251A-6C37-4B4B-9120-0845616D0E60@kernel.crashing.org> On Feb 3, 2006, at 2:05 AM, Michael Ellerman wrote: > It's possible for prom_init to allocate the flat device tree inside > the > kdump crash kernel region. If this happens, when we load the kdump > kernel we > overwrite the flattened device tree, which is bad. > > We could make prom_init try and avoid allocating inside the crash > kernel > region, but then we run into issues if the crash kernel region uses > all the > space inside the RMO. The easiest solution is to move the flat > device tree > once we're running in the kernel. > > Signed-off-by: Michael Ellerman Doesn't setup_32.c need a similar change? - k > --- > > arch/powerpc/kernel/prom.c | 27 +++++++++++++++++++++++++++ > arch/powerpc/kernel/setup_64.c | 3 +++ > include/asm-powerpc/prom.h | 2 ++ > 3 files changed, 32 insertions(+) > > Index: kdump/arch/powerpc/kernel/prom.c > =================================================================== > --- kdump.orig/arch/powerpc/kernel/prom.c > +++ kdump/arch/powerpc/kernel/prom.c > @@ -1913,3 +1913,30 @@ int prom_update_property(struct device_n > > return 0; > } > + > +#ifdef CONFIG_KEXEC > +/* We may have allocated the flat device tree inside the crash > kernel region > + * in prom_init. If so we need to move it out into regular memory. */ > +void kdump_move_device_tree(void) > +{ > + unsigned long start, end; > + struct boot_param_header *new; > + > + start = __pa((unsigned long)initial_boot_params); > + end = start + initial_boot_params->totalsize; > + > + if (end < crashk_res.start || start > crashk_res.end) > + return; > + > + new = (struct boot_param_header*) > + __va(lmb_alloc(initial_boot_params->totalsize, PAGE_SIZE)); > + > + memcpy(new, initial_boot_params, initial_boot_params->totalsize); > + > + initial_boot_params = new; > + > + DBG("Flat device tree blob moved to %p\n", initial_boot_params); > + > + /* XXX should we unreserve the old DT? */ > +} > +#endif /* CONFIG_KEXEC */ > Index: kdump/arch/powerpc/kernel/setup_64.c > =================================================================== > --- kdump.orig/arch/powerpc/kernel/setup_64.c > +++ kdump/arch/powerpc/kernel/setup_64.c > @@ -398,6 +398,9 @@ void __init setup_system(void) > { > DBG(" -> setup_system()\n"); > > +#ifdef CONFIG_KEXEC > + kdump_move_device_tree(); > +#endif > /* > * Unflatten the device-tree passed by prom_init or kexec > */ > Index: kdump/include/asm-powerpc/prom.h > =================================================================== > --- kdump.orig/include/asm-powerpc/prom.h > +++ kdump/include/asm-powerpc/prom.h > @@ -222,5 +222,7 @@ extern int of_address_to_resource(struct > extern int of_pci_address_to_resource(struct device_node *dev, int > bar, > struct resource *r); > > +extern void kdump_move_device_tree(void); > + > #endif /* __KERNEL__ */ > #endif /* _POWERPC_PROM_H */ > _______________________________________________ > Linuxppc64-dev mailing list > Linuxppc64-dev at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc64-dev From trini at kernel.crashing.org Sat Feb 4 01:47:13 2006 From: trini at kernel.crashing.org (Tom Rini) Date: Fri, 3 Feb 2006 07:47:13 -0700 Subject: LINUXPPC64 Maple fails to boot current git) In-Reply-To: <1138931761.4934.113.camel@localhost.localdomain> References: <20060130171759.GE22672@smtp.west.cox.net> <1138662630.3417.26.camel@brick.watson.ibm.com> <20060131151117.GP22672@smtp.west.cox.net> <1138931761.4934.113.camel@localhost.localdomain> Message-ID: <20060203144713.GE3800@smtp.west.cox.net> On Fri, Feb 03, 2006 at 12:56:01PM +1100, Benjamin Herrenschmidt wrote: > > > When looking for legacy serial ports, condition poking of "ISA" areas > > on CONFIG_GENERIC_ISA_DMA, rather than CONFIG_ISA as some boards (such > > as the Maple) have no ISA slots, but do have ISA serial ports. > > Hrm... not sure ISA_DMA has anything to do with that at all.. in fact > its more like "has legacy devices". I don't remember adding the ifdef > CONFIG_ISA in the first place, maybe I did... it's a bit dodgy I'd say. > Indeed, lots of machines have ISA devices (a superIO typically) without > having ISA slots... Olaf says that he sent a patch to Andrew, who should be passing it along if not already, to just remove the #ifdefs there. -- Tom Rini http://gate.crashing.org/~trini/ From ericvh at gmail.com Sat Feb 4 01:54:41 2006 From: ericvh at gmail.com (Eric Van Hensbergen) Date: Fri, 3 Feb 2006 08:54:41 -0600 (CST) Subject: [patch 0/3] systemsim patch cleanup Message-ID: <20060203145441.6EC0A5A8075@localhost.localdomain> These are a set of code cleanups based on Arnd's systemsim patch-set sent out on January 14th. This patch attempts to clean-up some of the issues with the bogus network and bogus disk facilities of systemsim -- but is largely cosmetic. We had looked at incorporating the bogus devices into the IBM-maintained virtualization drivers in the past, but at the time it didn't look like there was a good match in the veth or the vscsi code -- the call-thru's would not integrate as nicely as they did with the hvc console code. The bogus disk and bogus network drivers are largely a stop-gap measure for systems the simulator doesn't have complete device models for. More complete device models are already in the plans for systemsim-cell, which will likely eventually replace the need for the "bogus" drivers. As such, I'll maintain the existing bogus drivers out-of-tree in my git repository on kernel.org (/pub/scm/linux/kernel/git/ericvh/systemsim.git) Unless there are any objections, I'll continue cc:'ing the ppc64-dev list on modifications to the patches. -eric From ericvh at gmail.com Sat Feb 4 01:56:17 2006 From: ericvh at gmail.com (Eric Van Hensbergen) Date: Fri, 3 Feb 2006 08:56:17 -0600 (CST) Subject: [patch 3/3] systemsim: new systemsim default configuration Message-ID: <20060203145617.D6FCD5A809C@localhost.localdomain> Subject: [PATCH] systemsim: clean up default configuration Signed-off-by: Eric Van Hensbergen --- arch/powerpc/configs/systemsim_defconfig | 125 +++++++----------------------- 1 files changed, 28 insertions(+), 97 deletions(-) 72e13e73b5998b853a9bd20e8c425486818ed09a diff --git a/arch/powerpc/configs/systemsim_defconfig b/arch/powerpc/configs/systemsim_defconfig index 59f1d0f..f7daa08 100644 --- a/arch/powerpc/configs/systemsim_defconfig +++ b/arch/powerpc/configs/systemsim_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: -# Fri Jan 13 09:33:18 2006 +# Linux kernel version: 2.6.16-rc1 +# Thu Feb 2 15:18:13 2006 # CONFIG_PPC64=y CONFIG_64BIT=y @@ -18,7 +18,6 @@ CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_PPC_UDBG_16550=y -# CONFIG_CRASH_DUMP is not set CONFIG_GENERIC_TBSYNC=y # @@ -57,7 +56,7 @@ CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_CPUSETS is not set CONFIG_INITRAMFS_SOURCE="" -CONFIG_CC_OPTIMIZE_FOR_SIZE=y +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set @@ -100,11 +99,11 @@ CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y -# CONFIG_DEFAULT_AS is not set +CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set -CONFIG_DEFAULT_NOOP=y -CONFIG_DEFAULT_IOSCHED="noop" +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED="anticipatory" # # Platform support @@ -116,7 +115,7 @@ CONFIG_PPC_MULTIPLATFORM=y CONFIG_PPC_PSERIES=y # CONFIG_PPC_PMAC is not set CONFIG_PPC_MAPLE=y -CONFIG_PPC_CELL=y +# CONFIG_PPC_CELL is not set CONFIG_PPC_SYSTEMSIM=y CONFIG_SYSTEMSIM_IDLE=y CONFIG_XICS=y @@ -126,9 +125,8 @@ CONFIG_PPC_RTAS=y CONFIG_RTAS_ERROR_LOGGING=y CONFIG_RTAS_PROC=y # CONFIG_RTAS_FLASH is not set -CONFIG_MMIO_NVRAM=y +# CONFIG_MMIO_NVRAM is not set CONFIG_MPIC_BROKEN_U3=y -CONFIG_CELL_IIC=y CONFIG_IBMVIO=y # CONFIG_IBMEBUS is not set # CONFIG_PPC_MPC106 is not set @@ -136,11 +134,6 @@ CONFIG_IBMVIO=y # CONFIG_WANT_EARLY_SERIAL is not set # -# Cell Broadband Engine options -# -CONFIG_SPU_FS=m - -# # Kernel options # # CONFIG_HZ_100 is not set @@ -157,6 +150,7 @@ CONFIG_FORCE_MAX_ZONEORDER=13 # CONFIG_IOMMU_VMERGE is not set # CONFIG_HOTPLUG_CPU is not set # CONFIG_KEXEC is not set +# CONFIG_CRASH_DUMP is not set # CONFIG_IRQ_ALL_CPUS is not set # CONFIG_PPC_SPLPAR is not set CONFIG_EEH=y @@ -299,6 +293,7 @@ CONFIG_BRIDGE_NETFILTER=y # Core Netfilter Configuration # # CONFIG_NETFILTER_NETLINK is not set +# CONFIG_NETFILTER_XTABLES is not set # # IP: Netfilter Configuration @@ -315,91 +310,11 @@ CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_AMANDA=m # CONFIG_IP_NF_PPTP is not set CONFIG_IP_NF_QUEUE=m -CONFIG_IP_NF_IPTABLES=m -CONFIG_IP_NF_MATCH_LIMIT=m -# CONFIG_IP_NF_MATCH_IPRANGE is not set -CONFIG_IP_NF_MATCH_MAC=m -CONFIG_IP_NF_MATCH_PKTTYPE=m -CONFIG_IP_NF_MATCH_MARK=m -CONFIG_IP_NF_MATCH_MULTIPORT=m -CONFIG_IP_NF_MATCH_TOS=m -CONFIG_IP_NF_MATCH_RECENT=m -CONFIG_IP_NF_MATCH_ECN=m -CONFIG_IP_NF_MATCH_DSCP=m -CONFIG_IP_NF_MATCH_AH_ESP=m -CONFIG_IP_NF_MATCH_LENGTH=m -CONFIG_IP_NF_MATCH_TTL=m -CONFIG_IP_NF_MATCH_TCPMSS=m -CONFIG_IP_NF_MATCH_HELPER=m -CONFIG_IP_NF_MATCH_STATE=m -CONFIG_IP_NF_MATCH_CONNTRACK=m -CONFIG_IP_NF_MATCH_OWNER=m -# CONFIG_IP_NF_MATCH_PHYSDEV is not set -# CONFIG_IP_NF_MATCH_ADDRTYPE is not set -# CONFIG_IP_NF_MATCH_REALM is not set -# CONFIG_IP_NF_MATCH_SCTP is not set -# CONFIG_IP_NF_MATCH_DCCP is not set -# CONFIG_IP_NF_MATCH_COMMENT is not set -# CONFIG_IP_NF_MATCH_HASHLIMIT is not set -# CONFIG_IP_NF_MATCH_STRING is not set -# CONFIG_IP_NF_MATCH_POLICY is not set -CONFIG_IP_NF_FILTER=m -CONFIG_IP_NF_TARGET_REJECT=m -CONFIG_IP_NF_TARGET_LOG=m -CONFIG_IP_NF_TARGET_ULOG=m -CONFIG_IP_NF_TARGET_TCPMSS=m -# CONFIG_IP_NF_TARGET_NFQUEUE is not set -CONFIG_IP_NF_NAT=m -CONFIG_IP_NF_NAT_NEEDED=y -CONFIG_IP_NF_TARGET_MASQUERADE=m -CONFIG_IP_NF_TARGET_REDIRECT=m -# CONFIG_IP_NF_TARGET_NETMAP is not set -# CONFIG_IP_NF_TARGET_SAME is not set -CONFIG_IP_NF_NAT_SNMP_BASIC=m -CONFIG_IP_NF_NAT_IRC=m -CONFIG_IP_NF_NAT_FTP=m -CONFIG_IP_NF_NAT_TFTP=m -CONFIG_IP_NF_NAT_AMANDA=m -CONFIG_IP_NF_MANGLE=m -CONFIG_IP_NF_TARGET_TOS=m -CONFIG_IP_NF_TARGET_ECN=m -CONFIG_IP_NF_TARGET_DSCP=m -CONFIG_IP_NF_TARGET_MARK=m -# CONFIG_IP_NF_TARGET_CLASSIFY is not set -# CONFIG_IP_NF_TARGET_TTL is not set -# CONFIG_IP_NF_RAW is not set -CONFIG_IP_NF_ARPTABLES=m -CONFIG_IP_NF_ARPFILTER=m -CONFIG_IP_NF_ARP_MANGLE=m # # IPv6: Netfilter Configuration (EXPERIMENTAL) # # CONFIG_IP6_NF_QUEUE is not set -CONFIG_IP6_NF_IPTABLES=m -CONFIG_IP6_NF_MATCH_LIMIT=m -CONFIG_IP6_NF_MATCH_MAC=m -CONFIG_IP6_NF_MATCH_RT=m -CONFIG_IP6_NF_MATCH_OPTS=m -CONFIG_IP6_NF_MATCH_FRAG=m -CONFIG_IP6_NF_MATCH_HL=m -CONFIG_IP6_NF_MATCH_MULTIPORT=m -CONFIG_IP6_NF_MATCH_OWNER=m -CONFIG_IP6_NF_MATCH_MARK=m -CONFIG_IP6_NF_MATCH_IPV6HEADER=m -CONFIG_IP6_NF_MATCH_AHESP=m -CONFIG_IP6_NF_MATCH_LENGTH=m -CONFIG_IP6_NF_MATCH_EUI64=m -# CONFIG_IP6_NF_MATCH_PHYSDEV is not set -# CONFIG_IP6_NF_MATCH_POLICY is not set -CONFIG_IP6_NF_FILTER=m -CONFIG_IP6_NF_TARGET_LOG=m -# CONFIG_IP6_NF_TARGET_REJECT is not set -# CONFIG_IP6_NF_TARGET_NFQUEUE is not set -CONFIG_IP6_NF_MANGLE=m -CONFIG_IP6_NF_TARGET_MARK=m -# CONFIG_IP6_NF_TARGET_HL is not set -# CONFIG_IP6_NF_RAW is not set # # DECnet: Netfilter Configuration @@ -443,6 +358,11 @@ CONFIG_IPDDP_ENCAP=y CONFIG_IPDDP_DECAP=y # CONFIG_X25 is not set # CONFIG_LAPB is not set + +# +# TIPC Configuration (EXPERIMENTAL) +# +# CONFIG_TIPC is not set CONFIG_NET_DIVERT=y # CONFIG_ECONET is not set CONFIG_WAN_ROUTER=m @@ -555,6 +475,7 @@ CONFIG_MTD_CFI_I2=y # CONFIG_MTD_RAM is not set # CONFIG_MTD_ROM is not set # CONFIG_MTD_ABSENT is not set +# CONFIG_MTD_OBSOLETE_CHIPS is not set # # Mapping drivers for chip access @@ -707,7 +628,6 @@ CONFIG_SYSTEMSIM_NET=y # CONFIG_SK98LIN is not set # CONFIG_TIGON3 is not set # CONFIG_BNX2 is not set -# CONFIG_SPIDER_NET is not set # CONFIG_MV643XX_ETH is not set # @@ -815,7 +735,7 @@ CONFIG_HW_CONSOLE=y CONFIG_SERIAL_8250=y # CONFIG_SERIAL_8250_CONSOLE is not set CONFIG_SERIAL_8250_NR_UARTS=4 -CONFIG_SERIAL_8250_RUNTIME_UARTS=2 +CONFIG_SERIAL_8250_RUNTIME_UARTS=4 # CONFIG_SERIAL_8250_EXTENDED is not set # @@ -826,7 +746,10 @@ CONFIG_SERIAL_CORE=y CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 +CONFIG_HVC_DRIVER=y # CONFIG_HVC_CONSOLE is not set +CONFIG_HVC_FSS=y +CONFIG_HVC_RTAS=y # CONFIG_HVCS is not set # @@ -864,6 +787,12 @@ CONFIG_LEGACY_PTY_COUNT=256 # CONFIG_I2C is not set # +# SPI support +# +# CONFIG_SPI is not set +# CONFIG_SPI_MASTER is not set + +# # Dallas's 1-wire bus # # CONFIG_W1 is not set @@ -1057,6 +986,7 @@ CONFIG_UNIXWARE_DISKLABEL=y CONFIG_SGI_PARTITION=y # CONFIG_ULTRIX_PARTITION is not set CONFIG_SUN_PARTITION=y +# CONFIG_KARMA_PARTITION is not set # CONFIG_EFI_PARTITION is not set # @@ -1137,6 +1067,7 @@ CONFIG_DEBUG_SPINLOCK_SLEEP=y # CONFIG_DEBUG_INFO is not set # CONFIG_DEBUG_FS is not set # CONFIG_DEBUG_VM is not set +CONFIG_FORCED_INLINING=y # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_DEBUG_STACK_USAGE is not set -- 1.0.GIT From ericvh at gmail.com Sat Feb 4 01:55:06 2006 From: ericvh at gmail.com (Eric Van Hensbergen) Date: Fri, 3 Feb 2006 08:55:06 -0600 (CST) Subject: [patch 1/3] systemsim: cleanup systemsim network patch Message-ID: <20060203145506.1E0405A807B@localhost.localdomain> Subject: [PATCH] systemsim: clean-up systemsim network patch Incorporate some of the LKML feedback, clean-up naming conventions and fix a bogus free in the close routine. Signed-off-by: Eric Van Hensbergen --- drivers/net/systemsim_net.c | 113 ++++++++++++++++++++++--------------------- 1 files changed, 57 insertions(+), 56 deletions(-) 79e30c5718a29c6de20e45f00bc1b458b359c29c diff --git a/drivers/net/systemsim_net.c b/drivers/net/systemsim_net.c index babc1fb..0a4cea9 100644 --- a/drivers/net/systemsim_net.c +++ b/drivers/net/systemsim_net.c @@ -60,32 +60,32 @@ #include #include -#define MAMBO_BOGUS_NET_PROBE 119 -#define MAMBO_BOGUS_NET_SEND 120 -#define MAMBO_BOGUS_NET_RECV 121 +#define SYSTEMSIM_NET_PROBE 119 +#define SYSTEMSIM_NET_SEND 120 +#define SYSTEMSIM_NET_RECV 121 -static inline int MamboBogusNetProbe(int devno, void *buf) +static inline int systemsim_bogusnet_probe(int devno, void *buf) { - return callthru2(MAMBO_BOGUS_NET_PROBE, + return callthru2(SYSTEMSIM_NET_PROBE, (unsigned long)devno, (unsigned long)buf); } -static inline int MamboBogusNetSend(int devno, void *buf, ulong size) +static inline int systemsim_bogusnet_send(int devno, void *buf, ulong size) { - return callthru3(MAMBO_BOGUS_NET_SEND, + return callthru3(SYSTEMSIM_NET_SEND, (unsigned long)devno, (unsigned long)buf, (unsigned long)size); } -static inline int MamboBogusNetRecv(int devno, void *buf, ulong size) +static inline int systemsim_bogusnet_recv(int devno, void *buf, ulong size) { - return callthru3(MAMBO_BOGUS_NET_RECV, + return callthru3(SYSTEMSIM_NET_RECV, (unsigned long)devno, (unsigned long)buf, (unsigned long)size); } static irqreturn_t -mambonet_interrupt(int irq, void *dev_instance, struct pt_regs *regs); +systemsim_net_intr(int irq, void *dev_instance, struct pt_regs *regs); #define INIT_BOTTOM_HALF(x,y,z) INIT_WORK(x, y, (void*)z) #define SCHEDULE_BOTTOM_HALF(x) schedule_delayed_work(x, 1) @@ -100,18 +100,18 @@ struct netdev_private { struct net_device_stats stats; }; -static int mambonet_probedev(int devno, void *buf) +static int systemsim_net_probedev(int devno, void *buf) { - struct device_node *mambo; + struct device_node *systemsim; struct device_node *net; unsigned int *reg; - mambo = find_path_device("/mambo"); + systemsim = find_path_device("/systemsim"); - if (mambo == NULL) { + if (systemsim == NULL) { return -1; } - net = find_path_device("/mambo/bogus-net at 0"); + net = find_path_device("/systemsim/bogus-net at 0"); if (net == NULL) { return -1; } @@ -121,20 +121,20 @@ static int mambonet_probedev(int devno, return -1; } - return MamboBogusNetProbe(devno, buf); + return systemsim_bogusnet_probe(devno, buf); } -static int mambonet_send(int devno, void *buf, ulong size) +static int systemsim_net_send(int devno, void *buf, ulong size) { - return MamboBogusNetSend(devno, buf, size); + return systemsim_bogusnet_send(devno, buf, size); } -static int mambonet_recv(int devno, void *buf, ulong size) +static int systemsim_net_recv(int devno, void *buf, ulong size) { - return MamboBogusNetRecv(devno, buf, size); + return systemsim_bogusnet_recv(devno, buf, size); } -static int mambonet_start_xmit(struct sk_buff *skb, struct net_device *dev) +static int systemsim_net_start_xmit(struct sk_buff *skb, struct net_device *dev) { struct netdev_private *priv = (struct netdev_private *)dev->priv; int devno = priv->devno; @@ -142,7 +142,7 @@ static int mambonet_start_xmit(struct sk skb->dev = dev; /* we might need to checksum or something */ - mambonet_send(devno, skb->data, skb->len); + systemsim_net_send(devno, skb->data, skb->len); dev->last_rx = jiffies; priv->stats.rx_bytes += skb->len; @@ -155,7 +155,7 @@ static int mambonet_start_xmit(struct sk return (0); } -static int mambonet_poll(struct net_device *dev, int *budget) +static int systemsim_net_poll(struct net_device *dev, int *budget) { struct netdev_private *np = dev->priv; int devno = np->devno; @@ -166,7 +166,7 @@ static int mambonet_poll(struct net_devi int max_frames = min(*budget, dev->quota); int ret = 0; - while ((ns = mambonet_recv(devno, buffer, 1600)) > 0) { + while ((ns = systemsim_net_recv(devno, buffer, 1600)) > 0) { if ((skb = dev_alloc_skb(ns + 2)) != NULL) { skb->dev = dev; skb_reserve(skb, 2); /* 16 byte align the IP @@ -209,12 +209,12 @@ static int mambonet_poll(struct net_devi return ret; } -static void mambonet_timer(struct net_device *dev) +static void systemsim_net_timer(struct net_device *dev) { int budget = 16; struct netdev_private *priv = (struct netdev_private *)dev->priv; - mambonet_poll(dev, &budget); + systemsim_net_poll(dev, &budget); if (!priv->closing) { SCHEDULE_BOTTOM_HALF(&priv->poll_task); @@ -228,7 +228,7 @@ static struct net_device_stats *get_stat } static irqreturn_t -mambonet_interrupt(int irq, void *dev_instance, struct pt_regs *regs) +systemsim_net_intr(int irq, void *dev_instance, struct pt_regs *regs) { struct net_device *dev = dev_instance; if (netif_rx_schedule_prep(dev)) { @@ -237,7 +237,7 @@ mambonet_interrupt(int irq, void *dev_in return IRQ_HANDLED; } -static int mambonet_open(struct net_device *dev) +static int systemsim_net_open(struct net_device *dev) { struct netdev_private *priv; int ret = 0; @@ -245,29 +245,30 @@ static int mambonet_open(struct net_devi priv = dev->priv; /* - * we can't start polling in mambonet_init, because I don't think + * we can't start polling in systemsim_net_init, because I don't think * workqueues are usable that early. so start polling now. */ if (dev->irq) { - ret = request_irq(dev->irq, &mambonet_interrupt, 0, + ret = request_irq(dev->irq, &systemsim_net_intr, 0, dev->name, dev); if (ret == 0) { netif_start_queue(dev); } else { - printk(KERN_ERR "mambonet: request irq failed\n"); + printk(KERN_ERR "systemsim net: request irq failed\n"); } - MamboBogusNetProbe(priv->devno, NULL); /* probe with NULL to activate interrupts */ + /* probe with NULL to activate interrupts */ + systemsim_bogusnet_probe(priv->devno, NULL); } else { - mambonet_timer(dev); + systemsim_net_timer(dev); } return ret; } -static int mambonet_close(struct net_device *dev) +static int systemsim_net_close(struct net_device *dev) { struct netdev_private *priv; @@ -282,30 +283,29 @@ static int mambonet_close(struct net_dev KILL_BOTTOM_HALF(&priv->poll_task); } - kfree(priv); - return 0; } -static struct net_device_stats mambonet_stats; +static struct net_device_stats systemsim_net_stats; -static struct net_device_stats *mambonet_get_stats(struct net_device *dev) +static struct net_device_stats *systemsim_net_get_stats(struct net_device *dev) { - return &mambonet_stats; + return &systemsim_net_stats; } -static int mambonet_set_mac_address(struct net_device *dev, void *p) +static int systemsim_net_set_mac_address(struct net_device *dev, void *p) { return -EOPNOTSUPP; } -static int mambonet_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) +static int systemsim_net_ioctl(struct net_device *dev, struct ifreq *ifr, + int cmd) { return -EOPNOTSUPP; } static int nextdevno = 0; /* running count of device numbers */ /* Initialize the rest of the device. */ -int __init do_mambonet_probe(struct net_device *dev) +int __init do_systemsim_net_probe(struct net_device *dev) { struct netdev_private *priv; int devno = nextdevno++; @@ -313,7 +313,7 @@ int __init do_mambonet_probe(struct net_ printk("eth%d: bogus network driver initialization\n", devno); - irq = mambonet_probedev(devno, dev->dev_addr); + irq = systemsim_net_probedev(devno, dev->dev_addr); if (irq < 0) { printk("No IRQ retreived\n"); @@ -328,14 +328,14 @@ int __init do_mambonet_probe(struct net_ dev->irq = irq; dev->mtu = MAMBO_MTU; - dev->open = mambonet_open; - dev->poll = mambonet_poll; + dev->open = systemsim_net_open; + dev->poll = systemsim_net_poll; dev->weight = 16; - dev->stop = mambonet_close; - dev->hard_start_xmit = mambonet_start_xmit; - dev->get_stats = mambonet_get_stats; - dev->set_mac_address = mambonet_set_mac_address; - dev->do_ioctl = mambonet_ioctl; + dev->stop = systemsim_net_close; + dev->hard_start_xmit = systemsim_net_start_xmit; + dev->get_stats = systemsim_net_get_stats; + dev->set_mac_address = systemsim_net_set_mac_address; + dev->do_ioctl = systemsim_net_ioctl; dev->priv = kmalloc(sizeof(struct netdev_private), GFP_KERNEL); if (dev->priv == NULL) @@ -348,14 +348,14 @@ int __init do_mambonet_probe(struct net_ dev->get_stats = get_stats; if (dev->irq == 0) { - INIT_BOTTOM_HALF(&priv->poll_task, (void *)mambonet_timer, + INIT_BOTTOM_HALF(&priv->poll_task, (void *)systemsim_net_timer, (void *)dev); } return (0); }; -struct net_device *__init mambonet_probe(int unit) +struct net_device *__init systemsim_net_probe(int unit) { struct net_device *dev = alloc_etherdev(0); int err; @@ -366,7 +366,7 @@ struct net_device *__init mambonet_probe sprintf(dev->name, "eth%d", unit); netdev_boot_setup_check(dev); - err = do_mambonet_probe(dev); + err = do_systemsim_net_probe(dev); if (err) goto out; @@ -382,11 +382,12 @@ struct net_device *__init mambonet_probe return ERR_PTR(err); } -int __init init_mambonet(void) +int __init init_systemsim_net(void) { - mambonet_probe(0); + systemsim_net_probe(0); return 0; } -module_init(init_mambonet); +module_init(init_systemsim_net); +MODULE_DESCRIPTION("Systemsim Network Driver"); MODULE_LICENSE("GPL"); -- 1.0.GIT From ericvh at gmail.com Sat Feb 4 01:55:36 2006 From: ericvh at gmail.com (Eric Van Hensbergen) Date: Fri, 3 Feb 2006 08:55:36 -0600 (CST) Subject: [patch 2/3] systemsim: cleanup systemsim block driver patch Message-ID: <20060203145536.CB9C35A8098@localhost.localdomain> Subject: [PATCH] systemsim: clean up systemsim block driver Clean-up the systemsim block driver and integrate some of the suggestions from LKML. Signed-off-by: Eric Van Hensbergen --- drivers/block/systemsim_bd.c | 159 ++++++++++++++++++++++++------------------ 1 files changed, 91 insertions(+), 68 deletions(-) ea40711c3a573b917cade94c1bdca659e4f3f905 diff --git a/drivers/block/systemsim_bd.c b/drivers/block/systemsim_bd.c index deecfb8..bec453e 100644 --- a/drivers/block/systemsim_bd.c +++ b/drivers/block/systemsim_bd.c @@ -11,7 +11,7 @@ * written by Pavel Machek and Steven Whitehouse * * Some code is from the IBM Full System Simulator Group in ARL - * Author: PAtrick Bohrer + * Author: Patrick Bohrer * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -43,7 +43,7 @@ #include #include #include - +#include #include #include @@ -52,21 +52,21 @@ #include #define MAJOR_NR 42 -#define MAX_MBD 128 +#define MAX_SYSTEMSIM_BD 128 -#define MBD_SET_BLKSIZE _IO( 0xab, 1 ) -#define MBD_SET_SIZE _IO( 0xab, 2 ) -#define MBD_SET_SIZE_BLOCKS _IO( 0xab, 7 ) -#define MBD_DISCONNECT _IO( 0xab, 8 ) +#define SYSTEMSIM_BD_SET_BLKSIZE _IO( 0xab, 1 ) +#define SYSTEMSIM_BD_SET_SIZE _IO( 0xab, 2 ) +#define SYSTEMSIM_BD_SET_SIZE_BLOCKS _IO( 0xab, 7 ) +#define SYSTEMSIM_BD_DISCONNECT _IO( 0xab, 8 ) -struct mbd_device { +struct systemsim_bd_device { int initialized; int refcnt; int flags; struct gendisk *disk; }; -static struct mbd_device mbd_dev[MAX_MBD]; +static struct systemsim_bd_device systemsim_bd_dev[MAX_SYSTEMSIM_BD]; #define BD_INFO_SYNC 0 #define BD_INFO_STATUS 1 @@ -79,7 +79,7 @@ static struct mbd_device mbd_dev[MAX_MBD #define BOGUS_DISK_INFO 118 static inline int -MamboBogusDiskRead(int devno, void *buf, ulong sect, ulong nrsect) +systemsim_disk_read(int devno, void *buf, ulong sect, ulong nrsect) { return callthru3(BOGUS_DISK_READ, (unsigned long)buf, (unsigned long)sect, @@ -87,34 +87,34 @@ MamboBogusDiskRead(int devno, void *buf, } static inline int -MamboBogusDiskWrite(int devno, void *buf, ulong sect, ulong nrsect) +systemsim_disk_write(int devno, void *buf, ulong sect, ulong nrsect) { return callthru3(BOGUS_DISK_WRITE, (unsigned long)buf, (unsigned long)sect, (unsigned long)((nrsect << 16) | devno)); } -static inline int MamboBogusDiskInfo(int op, int devno) +static inline int systemsim_disk_info(int op, int devno) { return callthru2(BOGUS_DISK_INFO, (unsigned long)op, (unsigned long)devno); } -static int mbd_init_disk(int devno) +static int systemsim_bd_init_disk(int devno) { - struct gendisk *disk = mbd_dev[devno].disk; + struct gendisk *disk = systemsim_bd_dev[devno].disk; unsigned int sz; /* check disk configured */ - if (!MamboBogusDiskInfo(BD_INFO_STATUS, devno)) { + if (!systemsim_disk_info(BD_INFO_STATUS, devno)) { printk(KERN_ERR "Attempting to open bogus disk before initializaiton\n"); return 0; } - mbd_dev[devno].initialized++; + systemsim_bd_dev[devno].initialized++; - sz = MamboBogusDiskInfo(BD_INFO_DEVSZ, devno); + sz = systemsim_disk_info(BD_INFO_DEVSZ, devno); printk("Initializing disk %d with devsz %u\n", devno, sz); @@ -123,7 +123,7 @@ static int mbd_init_disk(int devno) return 1; } -static void do_mbd_request(request_queue_t * q) +static void do_systemsim_bd_request(request_queue_t * q) { int result = 0; struct request *req; @@ -133,14 +133,14 @@ static void do_mbd_request(request_queue switch (rq_data_dir(req)) { case READ: - result = MamboBogusDiskRead(minor, - req->buffer, req->sector, - req->current_nr_sectors); - break; - case WRITE: - result = MamboBogusDiskWrite(minor, + result = systemsim_disk_read(minor, req->buffer, req->sector, req->current_nr_sectors); + break; + case WRITE: + result = systemsim_disk_write(minor, + req->buffer, req->sector, + req->current_nr_sectors); }; if (result) @@ -150,108 +150,131 @@ static void do_mbd_request(request_queue } } -static int mbd_release(struct inode *inode, struct file *file) +static int systemsim_bd_release(struct inode *inode, struct file *file) { - struct mbd_device *lo; + struct systemsim_bd_device *lo; int dev; if (!inode) return -ENODEV; dev = inode->i_bdev->bd_disk->first_minor; - if (dev >= MAX_MBD) + if (dev >= MAX_SYSTEMSIM_BD) return -ENODEV; - if (MamboBogusDiskInfo(BD_INFO_SYNC, dev) < 0) { - printk(KERN_ALERT "mbd_release: unable to sync\n"); + if (systemsim_disk_info(BD_INFO_SYNC, dev) < 0) { + printk(KERN_ALERT "systemsim_bd_release: unable to sync\n"); } - lo = &mbd_dev[dev]; + lo = &systemsim_bd_dev[dev]; if (lo->refcnt <= 0) - printk(KERN_ALERT "mbd_release: refcount(%d) <= 0\n", + printk(KERN_ALERT "systemsim_bd_release: refcount(%d) <= 0\n", lo->refcnt); lo->refcnt--; return 0; } -static int mbd_revalidate(struct gendisk *disk) +static int systemsim_bd_revalidate(struct gendisk *disk) { int devno = disk->first_minor; - mbd_init_disk(devno); + systemsim_bd_init_disk(devno); return 0; } -static int mbd_open(struct inode *inode, struct file *file) +static int systemsim_bd_open(struct inode *inode, struct file *file) { int dev; if (!inode) return -EINVAL; dev = inode->i_bdev->bd_disk->first_minor; - if (dev >= MAX_MBD) + if (dev >= MAX_SYSTEMSIM_BD) return -ENODEV; check_disk_change(inode->i_bdev); - if (!mbd_dev[dev].initialized) - if (!mbd_init_disk(dev)) + if (!systemsim_bd_dev[dev].initialized) + if (!systemsim_bd_init_disk(dev)) return -ENODEV; - mbd_dev[dev].refcnt++; + systemsim_bd_dev[dev].refcnt++; return 0; } -static struct block_device_operations mbd_fops = { +static struct block_device_operations systemsim_bd_fops = { owner:THIS_MODULE, - open:mbd_open, - release:mbd_release, - /* media_changed: mbd_check_change, */ - revalidate_disk:mbd_revalidate, + open:systemsim_bd_open, + release:systemsim_bd_release, + /* media_changed: systemsim_bd_check_change, */ + revalidate_disk:systemsim_bd_revalidate, }; -static spinlock_t mbd_lock = SPIN_LOCK_UNLOCKED; +static spinlock_t systemsim_bd_lock = SPIN_LOCK_UNLOCKED; -static int __init mbd_init(void) +static int __init systemsim_bd_init(void) { + struct device_node *systemsim; int err = -ENOMEM; int i; - for (i = 0; i < MAX_MBD; i++) { + systemsim = find_path_device("/systemsim"); + + if (systemsim == NULL) { + printk("NO SYSTEMSIM BOGUS DISK DETECTED\n"); + return -1; + } + + /* + * We could detect which disks are configured in openfirmware + * but I think this unnecessarily limits us from being able to + * hot-plug bogus disks durning run-time. + * + */ + + for (i = 0; i < MAX_SYSTEMSIM_BD; i++) { struct gendisk *disk = alloc_disk(1); if (!disk) goto out; - mbd_dev[i].disk = disk; + systemsim_bd_dev[i].disk = disk; /* * The new linux 2.5 block layer implementation requires * every gendisk to have its very own request_queue struct. * These structs are big so we dynamically allocate them. */ - disk->queue = blk_init_queue(do_mbd_request, &mbd_lock); + disk->queue = + blk_init_queue(do_systemsim_bd_request, &systemsim_bd_lock); if (!disk->queue) { put_disk(disk); goto out; } } - if (register_blkdev(MAJOR_NR, "mbd")) { + if (register_blkdev(MAJOR_NR, "systemsim_bd")) { err = -EIO; goto out; } #ifdef MODULE - printk("mambo bogus disk: registered device at major %d\n", MAJOR_NR); + printk("systemsim bogus disk: registered device at major %d\n", + MAJOR_NR); #else - printk("mambo bogus disk: compiled in with kernel\n"); + printk("systemsim bogus disk: compiled in with kernel\n"); #endif + /* + * left device name alone for now as too much depends on it + * external to the kernel + * + */ + devfs_mk_dir("mambobd"); - for (i = 0; i < MAX_MBD; i++) { /* load defaults */ - struct gendisk *disk = mbd_dev[i].disk; - mbd_dev[i].initialized = 0; - mbd_dev[i].refcnt = 0; - mbd_dev[i].flags = 0; + for (i = 0; i < MAX_SYSTEMSIM_BD; i++) { /* load defaults */ + struct gendisk *disk = systemsim_bd_dev[i].disk; + systemsim_bd_dev[i].initialized = 0; + systemsim_bd_dev[i].refcnt = 0; + systemsim_bd_dev[i].flags = 0; disk->major = MAJOR_NR; disk->first_minor = i; - disk->fops = &mbd_fops; - disk->private_data = &mbd_dev[i]; + disk->fops = &systemsim_bd_fops; + disk->private_data = &systemsim_bd_dev[i]; sprintf(disk->disk_name, "mambobd%d", i); sprintf(disk->devfs_name, "mambobd%d", i); set_capacity(disk, 0x7ffffc00ULL << 1); /* 2 TB */ @@ -261,25 +284,25 @@ static int __init mbd_init(void) return 0; out: while (i--) { - if (mbd_dev[i].disk->queue) - blk_cleanup_queue(mbd_dev[i].disk->queue); - put_disk(mbd_dev[i].disk); + if (systemsim_bd_dev[i].disk->queue) + blk_cleanup_queue(systemsim_bd_dev[i].disk->queue); + put_disk(systemsim_bd_dev[i].disk); } return -EIO; } -static void __exit mbd_cleanup(void) +static void __exit systemsim_bd_cleanup(void) { devfs_remove("mambobd"); - if (unregister_blkdev(MAJOR_NR, "mbd") != 0) - printk("mbd: cleanup_module failed\n"); + if (unregister_blkdev(MAJOR_NR, "systemsim_bd") != 0) + printk("systemsim_bd: cleanup_module failed\n"); else - printk("mbd: module cleaned up.\n"); + printk("systemsim_bd: module cleaned up.\n"); } -module_init(mbd_init); -module_exit(mbd_cleanup); +module_init(systemsim_bd_init); +module_exit(systemsim_bd_cleanup); -MODULE_DESCRIPTION("Mambo Block Device"); +MODULE_DESCRIPTION("Systemsim Block Device"); MODULE_LICENSE("GPL"); -- 1.0.GIT From jfaslist at yahoo.fr Sat Feb 4 02:58:36 2006 From: jfaslist at yahoo.fr (jfaslist) Date: Fri, 03 Feb 2006 16:58:36 +0100 Subject: Maple freezing on PCI Target-Abort In-Reply-To: <1138930958.4934.102.camel@localhost.localdomain> References: <43E23B4A.4020402@yahoo.fr> <1138930958.4934.102.camel@localhost.localdomain> Message-ID: <43E37DAC.4030606@yahoo.fr> Hi, Yes, we are going to dig into all this CPC925 and Processor Interface initialization. Note that I checked that both MSR_ME and MSR_RI were set prior to triggering the PCI Target-Abort. -MSR_ME: If not set the CPU will "checkstop" on a machine chaeck. -MSR_RI: So that the exception is recoverable. Regarding MSR_RI, this should always be set, I think? Thanks -jfs Benjamin Herrenschmidt wrote: >>-What exception vector is taking care of a DERR excp? From what I can >>see it seems to be the "machine check" vector. But that seems a bit >>drastic to me. After all this is just a PCI target abort. >> >> > >I would expect a machine check yes. > > > >>-I expect that the normal behavior would be for the kernel to send a >>signal termination to the user process which caused the PIO READ PCI >>cycle (from a previously mmap()'ed VMA address). Is it doable on this >>platform? Since a READ operation is coupled by nature, I think this is >>the only acceptable way. >> >> > >It should SIGBUS except if the problem occurred in the kernel. I don't >know why it's not doing so, maybe you are hitting an issue/errata or >misconfiguration of the 925 ? > > > >>I have tried to set the MSR[RI] bit before doing the PCI cycle, but it >>didn't change change anything. Also on our design we disconnect the >>CPC925 checkstop pin from the 970 machine check pin.(see page 39 of >>cpc925 user's manual). So a DERR shouldn't cause a machine check I would >>think. >> >>I realize that these questions are very H/W related but couldn't find >>the answer in IBM doc. >> >> > > > > > > ___________________________________________________________________________ Nouveau : t?l?phonez moins cher avec Yahoo! Messenger ! D?couvez les tarifs exceptionnels pour appeler la France et l'international. T?l?chargez sur http://fr.messenger.yahoo.com From ahuja at austin.ibm.com Wed Feb 1 06:11:54 2006 From: ahuja at austin.ibm.com (Manish Ahuja) Date: Tue, 31 Jan 2006 13:11:54 -0600 Subject: [PATCH] PPC64 collect and export low-level cpu usage statistics In-Reply-To: <20060126204432.GG19465@austin.ibm.com> References: <43CFC094.8000709@austin.ibm.com> <20060126204432.GG19465@austin.ibm.com> Message-ID: <43DFB67A.5080508@austin.ibm.com> Yes, It probably is a good idea to have #define for it, but since purr is only available on power5 architecture, none of the other architecture's really need this code and maybe I should enclose this for power5 setup only. >>+static ssize_t show_dispatchedcycles(struct sys_device *, char *); >>+static ssize_t show_offline_cpu_cycles(struct sys_device *, char *); >>+ >>+static SYSDEV_ATTR(offline_cpu_cycles, 0444, show_offline_cpu_cycles, NULL); >>+static SYSDEV_ATTR(cpu_dispatched_cycles, 0444, show_dispatchedcycles, NULL); >> >> > >I think you need a #ifdef CONFIG_PPC64 around the above. > > >>- if (cpu_has_feature(CPU_FTR_SMT)) >>+ if (cpu_has_feature(CPU_FTR_SMT)) { >> sysdev_create_file(s, &attr_purr); >>+ sysdev_create_file(s, &attr_offline_cpu_cycles); >>+ sysdev_create_file(s, &attr_cpu_dispatched_cycles); >>+ } >> >> > >Shouldn't this be CPU_FTR_PURR not FTR_SMT ? (and also in the next >section too). > > > Yes, the original was FTR_SMT. I overlooked it. Thanks for pointing it out. +/* Defined in setup.c */ >>+extern u64 offline_cpu_total_tb; >>+extern u64 offline_cpu_total_cpu_util; >>+extern u64 offline_cpu_total_krncycles; >>+extern u64 offline_cpu_total_idle; >> >> > >These should be in a header file, probably arch/powerpc/kernel/setup.h > > > >>+static ssize_t show_offline_cpu_cycles(struct sys_device *dev, char *buf) >> >> > >#ifdef CONFIG_PPC64 surrounding the above .... > >--linas > > Okay, I can move it around, if its okay with everyone else. Thanks for the comments. From linas at austin.ibm.com Sat Feb 4 03:58:30 2006 From: linas at austin.ibm.com (Linas Vepstas) Date: Fri, 3 Feb 2006 10:58:30 -0600 Subject: creating PCI-related sysfs entries In-Reply-To: <1138957657.4934.124.camel@localhost.localdomain> References: <20060131202214.GZ19465@austin.ibm.com> <20060131203456.GA23819@kroah.com> <20060131210805.GA19465@austin.ibm.com> <1138931103.4934.105.camel@localhost.localdomain> <20060203020341.GR24916@austin.ibm.com> <1138957657.4934.124.camel@localhost.localdomain> Message-ID: <20060203165829.GS24916@austin.ibm.com> On Fri, Feb 03, 2006 at 08:07:37PM +1100, Benjamin Herrenschmidt was heard to remark: > On Thu, 2006-02-02 at 20:03 -0600, Linas Vepstas wrote: > > > Yes, and EEH does do that (in mainline, 10K times in a row, > > last I tried). This email was in reference to the > > layout of /sys/bus/pci/slots which seems to have only hotplug > > slots in there; I am not yet sure why. Its possible John Rose > > can shed some rapid insight? > > Ok... also, about this "max number of resets" thing, it would be useful > in fact to have a rate limit rather ... a network card that for some > reason need to be reset about once a day is still fairly useable and it > would be nice if the system didn't consider it dead after 10 days ... Yes, I've often thought about this. Only two designs come to mind: 1) a timer pops ever 8 hours, and decrements the failure count by 1. Thus, anything less than 3 resets a day would be acceptable. 2) Store the jiffies of the last reset. Increment the fail count only if previous jiffies is less than 8 hours ago. Set fail count to 1 if previous jiffies is more then 48 hours ago. Advantage over 1: no timers. Any preferences? > Also, it might be useful to have an entry to force a retry on a card > that has been considered dead... Actually, hotplug remove/add or dlpar remove/add can be used to clear the count. (and that's how I do my test cases) The problem is that the documentation for this is buried somwhere where it cannot be found. Actually, this is one of my bigger/biggest concerns: the info about any of this is unfindable. I'd like to hype it up a bit, but am not sure how. --linas From linas at austin.ibm.com Sat Feb 4 04:08:34 2006 From: linas at austin.ibm.com (Linas Vepstas) Date: Fri, 3 Feb 2006 11:08:34 -0600 Subject: creating PCI-related sysfs entries In-Reply-To: <1138931602.4934.110.camel@localhost.localdomain> References: <20060131202214.GZ19465@austin.ibm.com> <20060131203456.GA23819@kroah.com> <20060131210805.GA19465@austin.ibm.com> <20060131212624.GA10513@kroah.com> <1138931602.4934.110.camel@localhost.localdomain> Message-ID: <20060203170834.GT24916@austin.ibm.com> On Fri, Feb 03, 2006 at 12:53:21PM +1100, Benjamin Herrenschmidt was heard to remark: > > > People have suggested that they create such a driver for a long time. > > Why not just do that? > > if he also wants consolidated "global" stats, > then yes, a host controller driver might be the way to go). I've had trouble parsing these suggestions. I can certainly hack up some pci-host structure so I can publish a few stats (the goal is to eliminate /proc/ppc64/eeh). By "hack" I mean something that would live with either the rpaphp code or the powerpc code. However, this is a different type of activity than the idea "define a generic architecture-neutral pci-host bridge structure". Maybe I should just do the first, and if it ignites anyone's imagination, we can talk about the second. --linas From info at schihei.de Sat Feb 4 05:04:42 2006 From: info at schihei.de (Heiko J Schick) Date: Fri, 3 Feb 2006 19:04:42 +0100 Subject: kernel debugging tool In-Reply-To: <0ITB0074BC0LA6@mmp2.samsung.com> References: <0ITB0074BC0LA6@mmp2.samsung.com> Message-ID: <07030771-257D-4204-A0C4-1833B9F9FBD3@schihei.de> Hello, you can also use XMON or KDB, which are kernel debuggers. XMON is normally included in PowerPC kernels. I think for KDB you have to patch your kernel, but that could be wrong. If you dump out the crash instruction and compare it with the assembler output of your GCC, you can find fast the source code line which caused the kernel panic. Perhaps the following links helps, too: http://urbanmyth.org/linux/oops/ http://www-128.ibm.com/developerworks/library/l-kprobes.html?ca=dgr- lnxw42Kprobe http://www-128.ibm.com/developerworks/linux/library/l-kdbug/ Sometimes also very useful, too. :) On Jan 19, 2006, at 1:00 AM, Hyo Jung Song wrote: > WE are interested in Cell BE (broadband engine) Linux patch. > (found in > http://www.bsc.es/projects/deepcomputing/linuxoncell/cbexdev.html) > We want to debug kernel sources sometimes. How can we do it? > I believe you guys debugged kernel source codes for CBE and you > used > some tools. > Could you please some tips for this? Thank you. > > > > Hyo Jung Song > Senior Engineer > Samsung Electronics > tel. 82-2-3416-0355 > > -----Original Message----- > From: Cell Support [mailto:cell_support at bsc.es] > Sent: Wednesday, January 18, 2006 11:27 PM > To: hjsong at samsung.com > Cc: cell_support at bsc.es > Subject: Re: Fwd: kernel debugging tool > > Dear Hyo, > > we don't develop linux patches for Cell BE. We got them from public > kernel mailing lists and post them to help > people to built a kernel that works with Cell BE. This avoids > having to > go through kernel mailing lists to > find the correct patch files that fit a specific kernel release. Hope > this helps people. > > We think you should post your question to a linux kernel mailing list. > Regarding the ppc64 kernel development, > the linuxppc64-dev at ozlabs.org is the right place > (https://ozlabs.org/mailman/listinfo/linuxppc64-dev). But > you can also sent this to the http://www.kernel.org mailing lists. > Probable, kernel developers can help you > because they are always debugging new their code. > > Hope this helps. > > Regards, > >> Sender : hjsong at samsung.com >> Date : 2006-01-17 10:13 >> Title : kernel debugging tool >> >> Hi. >> >> WE are interested in CBE Linux patch. >> We want to debug kernel sources sometimes. How can we do it? >> I believe you guys debugged kernel source codes for CBE and you used >> some tools. >> Could you please some tips for this? Thank you. >> >> >> >> Hyo Jung Song >> Senior Engineer >> Samsung Electronics >> tel. 82-2-3416-0355 > > > > _______________________________________________ > Linuxppc64-dev mailing list > Linuxppc64-dev at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc64-dev From info at schihei.de Sat Feb 4 04:55:19 2006 From: info at schihei.de (Heiko J Schick) Date: Fri, 3 Feb 2006 18:55:19 +0100 Subject: kernel debugging tool In-Reply-To: <0ITB0074BC0LA6@mmp2.samsung.com> References: <0ITB0074BC0LA6@mmp2.samsung.com> Message-ID: <759A45E8-8A3E-47CD-B3C9-880C0EBDC25B@schihei.de> Hello, you can also use XMON or KDB, which are kernel debuggers. XMON is normally included in PowerPC kernels. I think for KDB you have to patch your kernel, but that could be wrong. Sometimes also very useful, too. :) On Jan 19, 2006, at 1:00 AM, Hyo Jung Song wrote: > WE are interested in Cell BE (broadband engine) Linux patch. > (found in > http://www.bsc.es/projects/deepcomputing/linuxoncell/cbexdev.html) > We want to debug kernel sources sometimes. How can we do it? > I believe you guys debugged kernel source codes for CBE and you > used > some tools. > Could you please some tips for this? Thank you. > > > > Hyo Jung Song > Senior Engineer > Samsung Electronics > tel. 82-2-3416-0355 > > -----Original Message----- > From: Cell Support [mailto:cell_support at bsc.es] > Sent: Wednesday, January 18, 2006 11:27 PM > To: hjsong at samsung.com > Cc: cell_support at bsc.es > Subject: Re: Fwd: kernel debugging tool > > Dear Hyo, > > we don't develop linux patches for Cell BE. We got them from public > kernel mailing lists and post them to help > people to built a kernel that works with Cell BE. This avoids > having to > go through kernel mailing lists to > find the correct patch files that fit a specific kernel release. Hope > this helps people. > > We think you should post your question to a linux kernel mailing list. > Regarding the ppc64 kernel development, > the linuxppc64-dev at ozlabs.org is the right place > (https://ozlabs.org/mailman/listinfo/linuxppc64-dev). But > you can also sent this to the http://www.kernel.org mailing lists. > Probable, kernel developers can help you > because they are always debugging new their code. > > Hope this helps. > > Regards, > >> Sender : hjsong at samsung.com >> Date : 2006-01-17 10:13 >> Title : kernel debugging tool >> >> Hi. >> >> WE are interested in CBE Linux patch. >> We want to debug kernel sources sometimes. How can we do it? >> I believe you guys debugged kernel source codes for CBE and you used >> some tools. >> Could you please some tips for this? Thank you. >> >> >> >> Hyo Jung Song >> Senior Engineer >> Samsung Electronics >> tel. 82-2-3416-0355 > > > > _______________________________________________ > Linuxppc64-dev mailing list > Linuxppc64-dev at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc64-dev ------------------------------------------------------------------------ heiko j schick tel1: +49 (0) 7031 438635 theodor-storm-weg 14 tel2: +49 (0) 7431 971370 71101 schoenaich mobil-tel: +49 (0) 172 9365733 email: info at schihei.de homepage: http://www.schihei.de/ icq: 29165160 pgp-key id: 0x899AD7DC ------------------------------------------------------------------------ From haren at us.ibm.com Sat Feb 4 06:03:11 2006 From: haren at us.ibm.com (Haren Myneni) Date: Fri, 03 Feb 2006 11:03:11 -0800 Subject: [PATCH] powerpc: Don't overwrite flat device tree with kdump kernel In-Reply-To: <20060203080609.403CA68A1F@ozlabs.org> References: <20060203080609.403CA68A1F@ozlabs.org> Message-ID: <43E3A8EF.8000609@us.ibm.com> Michael Ellerman wrote: >It's possible for prom_init to allocate the flat device tree inside the >kdump crash kernel region. If this happens, when we load the kdump kernel we >overwrite the flattened device tree, which is bad. > >We could make prom_init try and avoid allocating inside the crash kernel >region, but then we run into issues if the crash kernel region uses all the >space inside the RMO. The easiest solution is to move the flat device tree >once we're running in the kernel. > >Signed-off-by: Michael Ellerman >--- > > arch/powerpc/kernel/prom.c | 27 +++++++++++++++++++++++++++ > arch/powerpc/kernel/setup_64.c | 3 +++ > include/asm-powerpc/prom.h | 2 ++ > 3 files changed, 32 insertions(+) > >Index: kdump/arch/powerpc/kernel/prom.c >=================================================================== >--- kdump.orig/arch/powerpc/kernel/prom.c >+++ kdump/arch/powerpc/kernel/prom.c >@@ -1913,3 +1913,30 @@ int prom_update_property(struct device_n > > return 0; > } >+ >+#ifdef CONFIG_KEXEC >+/* We may have allocated the flat device tree inside the crash kernel region >+ * in prom_init. If so we need to move it out into regular memory. */ >+void kdump_move_device_tree(void) > > Should be void __init kdump_move_device_tree(void) >+{ >+ unsigned long start, end; >+ struct boot_param_header *new; >+ >+ start = __pa((unsigned long)initial_boot_params); >+ end = start + initial_boot_params->totalsize; >+ >+ if (end < crashk_res.start || start > crashk_res.end) >+ return; >+ >+ new = (struct boot_param_header*) >+ __va(lmb_alloc(initial_boot_params->totalsize, PAGE_SIZE)); >+ >+ memcpy(new, initial_boot_params, initial_boot_params->totalsize); > > We are touching the second kernel memory and the kexec boot will not initialize this region. So, reset this memory. memset((void *)initial_boot_params, 0, initial_boot_params->totalsize); Thanks Haren From cfriesen at nortel.com Sat Feb 4 10:21:00 2006 From: cfriesen at nortel.com (Christopher Friesen) Date: Fri, 03 Feb 2006 17:21:00 -0600 Subject: how to limit memory with 2.6.10 on ppc64 machine? Message-ID: <43E3E55C.90504@nortel.com> I'm running 2.6.10 on a ppc64 machine with 4GB of memory. We're debugging an issue and would like to try and see if disabling the U3 DART makes the problem go away. Unfortunately, this particular blade is unstable if not all the memory banks are populated. After some frustration I looked at the code and realized that the "mem=" functionality is not supported for ppc64 on this particular kernel. Can anyone give me some advice on the simplest way to limit this thing to under 2GB of memory so that the DART is not allocated/used? Does anyone know when support for "mem=" was added? I know it is there in the current git version, but the "powerpc" consolidation means everything is all different now. Thanks, Chris From benh at kernel.crashing.org Sat Feb 4 11:12:54 2006 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Sat, 04 Feb 2006 11:12:54 +1100 Subject: Maple freezing on PCI Target-Abort In-Reply-To: <43E37DAC.4030606@yahoo.fr> References: <43E23B4A.4020402@yahoo.fr> <1138930958.4934.102.camel@localhost.localdomain> <43E37DAC.4030606@yahoo.fr> Message-ID: <1139011975.8543.4.camel@localhost.localdomain> On Fri, 2006-02-03 at 16:58 +0100, jfaslist wrote: > Hi, > Yes, we are going to dig into all this CPC925 and Processor Interface > initialization. > Note that I checked that both MSR_ME and MSR_RI were set prior to > triggering the PCI Target-Abort. > > -MSR_ME: If not set the CPU will "checkstop" on a machine chaeck. > -MSR_RI: So that the exception is recoverable. > > Regarding MSR_RI, this should always be set, I think? Yes, MSR:RI is always set by the kernel except in the rare code path where taking an exception is actually unsafe (like in some of the exception handling code itself) Ben. From michael at ellerman.id.au Sat Feb 4 11:54:02 2006 From: michael at ellerman.id.au (Michael Ellerman) Date: Sat, 4 Feb 2006 11:54:02 +1100 Subject: how to limit memory with 2.6.10 on ppc64 machine? In-Reply-To: <43E3E55C.90504@nortel.com> References: <43E3E55C.90504@nortel.com> Message-ID: <200602041154.12710.michael@ellerman.id.au> On Sat, 4 Feb 2006 10:21, Christopher Friesen wrote: > I'm running 2.6.10 on a ppc64 machine with 4GB of memory. > > We're debugging an issue and would like to try and see if disabling the > U3 DART makes the problem go away. Unfortunately, this particular blade > is unstable if not all the memory banks are populated. > > After some frustration I looked at the code and realized that the "mem=" > functionality is not supported for ppc64 on this particular kernel. > > Can anyone give me some advice on the simplest way to limit this thing > to under 2GB of memory so that the DART is not allocated/used? > > Does anyone know when support for "mem=" was added? I know it is there > in the current git version, but the "powerpc" consolidation means > everything is all different now. From memory (harhar) the mem= support was merged in 2.6.11, so the original patch should _probably_ apply on a vanilla 2.6.10 tree, try it: http://patchwork.ozlabs.org/linuxppc64/patch?id=724 cheers -- Michael Ellerman IBM OzLabs email: michael:ellerman.id.au inmsg: mpe:jabber.org wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20060204/229eceaf/attachment.pgp From akpm at osdl.org Sat Feb 4 15:25:31 2006 From: akpm at osdl.org (Andrew Morton) Date: Fri, 3 Feb 2006 20:25:31 -0800 Subject: Altix SN2 2.6.16-rc1-mm5 build breakage (was: msi support) In-Reply-To: <20060203201441.194be500.pj@sgi.com> References: <20060119194647.12213.44658.14543@lnx-maule.americas.sgi.com> <20060119194702.12213.16524.93275@lnx-maule.americas.sgi.com> <20060203201441.194be500.pj@sgi.com> Message-ID: <20060203202531.27d685fa.akpm@osdl.org> Paul Jackson wrote: > > The following patch seems to be breaking my ia64 sn2_defconfig > build of 2.6.16-rc1-mm5: > > gregkh-pci-altix-msi-support-git-ia64-fix.patch > > I'm guessing you should remove it for now. > > > Details: > ======== > > When I try to build an ia64 sn2_defconfig 2.6.16-rc1-mm5, the > build fails: > > arch/ia64/sn/pci/tioce_provider.c:699:49: macro "ATE_MAKE" passed 3 arguments, but takes just 2 > arch/ia64/sn/pci/tioce_provider.c: In function `tioce_reserve_m32': > arch/ia64/sn/pci/tioce_provider.c:699: error: `ATE_MAKE' undeclared (first use in this function) > > If I remove the patch: > > gregkh-pci-altix-msi-support-git-ia64-fix.patch > > then it compiles fine. OK. I autodrop several of Greg's MSI patches because a) they had bugs which broke stuff a while ago and b) they don't apply and I'm lazy. So it looks like you've found a fix for a patch which isn't actually in -mm any more. I sent that fix to Greg the other day. > It seems that someone added a patchset to change the ATE_MAKE() > macro from 2 to 3 args, then someone added this above fix patch > for a missed change, then someone reverted it all back to 2 args, > but leaving this fix patch. > > I guess it means Andrew should remove the above patch. I'll do that, thanks. From akpm at osdl.org Sat Feb 4 15:27:42 2006 From: akpm at osdl.org (Andrew Morton) Date: Fri, 3 Feb 2006 20:27:42 -0800 Subject: Altix SN2 2.6.16-rc1-mm5 build breakage (was: msi support) In-Reply-To: <20060203202531.27d685fa.akpm@osdl.org> References: <20060119194647.12213.44658.14543@lnx-maule.americas.sgi.com> <20060119194702.12213.16524.93275@lnx-maule.americas.sgi.com> <20060203201441.194be500.pj@sgi.com> <20060203202531.27d685fa.akpm@osdl.org> Message-ID: <20060203202742.1e514fcc.akpm@osdl.org> Andrew Morton wrote: > > So it > looks like you've found a fix for a patch which isn't actually in -mm any > more. I sent that fix to Greg the other day. Actually, gregkh-pci-altix-msi-support-git-ia64-fix.patch fix`es git-ia64.patch when gregkh-pci-altix-msi-support.patch is also applied, so it's not presently useful to either Greg or Tony. I'll take care of it, somehow.. From pj at sgi.com Sat Feb 4 15:14:41 2006 From: pj at sgi.com (Paul Jackson) Date: Fri, 3 Feb 2006 20:14:41 -0800 Subject: Altix SN2 2.6.16-rc1-mm5 build breakage (was: msi support) In-Reply-To: <20060119194702.12213.16524.93275@lnx-maule.americas.sgi.com> References: <20060119194647.12213.44658.14543@lnx-maule.americas.sgi.com> <20060119194702.12213.16524.93275@lnx-maule.americas.sgi.com> Message-ID: <20060203201441.194be500.pj@sgi.com> Andrew, The following patch seems to be breaking my ia64 sn2_defconfig build of 2.6.16-rc1-mm5: gregkh-pci-altix-msi-support-git-ia64-fix.patch I'm guessing you should remove it for now. Details: ======== When I try to build an ia64 sn2_defconfig 2.6.16-rc1-mm5, the build fails: arch/ia64/sn/pci/tioce_provider.c:699:49: macro "ATE_MAKE" passed 3 arguments, but takes just 2 arch/ia64/sn/pci/tioce_provider.c: In function `tioce_reserve_m32': arch/ia64/sn/pci/tioce_provider.c:699: error: `ATE_MAKE' undeclared (first use in this function) If I remove the patch: gregkh-pci-altix-msi-support-git-ia64-fix.patch then it compiles fine. It seems that someone added a patchset to change the ATE_MAKE() macro from 2 to 3 args, then someone added this above fix patch for a missed change, then someone reverted it all back to 2 args, but leaving this fix patch. I guess it means Andrew should remove the above patch. But I really do not know what is going on here. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson 1.925.600.0401 From maule at sgi.com Sat Feb 4 15:42:34 2006 From: maule at sgi.com (Mark Maule) Date: Fri, 3 Feb 2006 22:42:34 -0600 Subject: Altix SN2 2.6.16-rc1-mm5 build breakage (was: msi support) In-Reply-To: <20060203202742.1e514fcc.akpm@osdl.org> References: <20060119194647.12213.44658.14543@lnx-maule.americas.sgi.com> <20060119194702.12213.16524.93275@lnx-maule.americas.sgi.com> <20060203201441.194be500.pj@sgi.com> <20060203202531.27d685fa.akpm@osdl.org> <20060203202742.1e514fcc.akpm@osdl.org> Message-ID: <20060204044234.GA31134@sgi.com> On Fri, Feb 03, 2006 at 08:27:42PM -0800, Andrew Morton wrote: > Andrew Morton wrote: > > > > So it > > looks like you've found a fix for a patch which isn't actually in -mm any > > more. I sent that fix to Greg the other day. > > Actually, gregkh-pci-altix-msi-support-git-ia64-fix.patch fix`es > git-ia64.patch when gregkh-pci-altix-msi-support.patch is also applied, so > it's not presently useful to either Greg or Tony. I'll take care of it, > somehow.. > I think what happened here is that I submitted a patchset for msi abstractions (and others posted a couple of subsequent bugfix incrementals), but these were not taken into the 2.6.16 base 'cause of their invasiveness. These patches touched the tioce_provider.c file. Then I submitted another patch which touched the tioce_provider.c file, and it looks like I probably based this file on the previous msi versions which were being held back, so in order for everything to build, you need all of the msi patches applied first. What's the preferred way to handle this ... fix the current ia64 build and then resubmit the msi patches relative to that base? Mark From akpm at osdl.org Sat Feb 4 16:08:07 2006 From: akpm at osdl.org (Andrew Morton) Date: Fri, 3 Feb 2006 21:08:07 -0800 Subject: Altix SN2 2.6.16-rc1-mm5 build breakage (was: msi support) In-Reply-To: <20060204044234.GA31134@sgi.com> References: <20060119194647.12213.44658.14543@lnx-maule.americas.sgi.com> <20060119194702.12213.16524.93275@lnx-maule.americas.sgi.com> <20060203201441.194be500.pj@sgi.com> <20060203202531.27d685fa.akpm@osdl.org> <20060203202742.1e514fcc.akpm@osdl.org> <20060204044234.GA31134@sgi.com> Message-ID: <20060203210807.56a48888.akpm@osdl.org> Mark Maule wrote: > > On Fri, Feb 03, 2006 at 08:27:42PM -0800, Andrew Morton wrote: > > Andrew Morton wrote: > > > > > > So it > > > looks like you've found a fix for a patch which isn't actually in -mm any > > > more. I sent that fix to Greg the other day. > > > > Actually, gregkh-pci-altix-msi-support-git-ia64-fix.patch fix`es > > git-ia64.patch when gregkh-pci-altix-msi-support.patch is also applied, so > > it's not presently useful to either Greg or Tony. I'll take care of it, > > somehow.. > > > > I think what happened here is that I submitted a patchset for msi > abstractions (and others posted a couple of subsequent bugfix incrementals), > but these were not taken into the 2.6.16 base 'cause of their invasiveness. > These patches touched the tioce_provider.c file. > > Then I submitted another patch which touched the tioce_provider.c file, and > it looks like I probably based this file on the previous msi versions which > were being held back, so in order for everything to build, you need all of > the msi patches applied first. > > What's the preferred way to handle this ... fix the current ia64 build and > then resubmit the msi patches relative to that base? > umm, tricky. This situation doesn't arise very often. What you could do is to prepare the patches against Tony's latest tree. Then I can put them in -mm and Greg can drop them. Once Tony merges up with Linus I transfer the patches to Greg. Or we put the patches into Tony's tree. Either way - they'll be the same patches. But it does mean that the patches won't be merged into mainline until Tony merges up. If that's a problem then we'll need to think again. From benh at kernel.crashing.org Sun Feb 5 09:56:02 2006 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Sun, 05 Feb 2006 09:56:02 +1100 Subject: [PATCH] powerpc: Fix PowerMac sound i2c In-Reply-To: <87y80rkmk7.fsf@briny.internal.ondioline.org> References: <1136695956.30123.44.camel@localhost.localdomain> <87y80rkmk7.fsf@briny.internal.ondioline.org> Message-ID: <1139093763.5634.3.camel@localhost.localdomain> On Sat, 2006-02-04 at 18:26 +0000, Paul Collins wrote: > Hi Ben, > > Benjamin Herrenschmidt writes: > > > My patch reworking the PowerMac i2c code break the sound drivers as they > > used to rely on some broken behaviour of i2c-keywest that is gone now. > > This patch should fix them (tested on a g5 with alsa only). It might > > also fix an oops if the alsa driver hits an unsupported chip. > > Applied Linus's current git tree, this patch makes ALSA sound on my > PowerBook5,4 work again. The second patch does not work because the > i2c wrapper (I assume that's what i2c_smbus_write_i2c_block_data is) > has apparently not yet returned. > > It would be nice to have this fix in 2.6.16 if possible. The second patch is the one that should go in, but it relies on an i2c fix (undoing some Bunk damage) that is still staging in Greg tree... I don't know what's up with that, I'll ask around. Ben. From haren at us.ibm.com Sun Feb 5 13:25:14 2006 From: haren at us.ibm.com (Haren Myneni) Date: Sat, 04 Feb 2006 18:25:14 -0800 Subject: [PATCH] powerpc: Don't overwrite flat device tree with kdump kernel In-Reply-To: <8FC7251A-6C37-4B4B-9120-0845616D0E60@kernel.crashing.org> References: <20060203080609.403CA68A1F@ozlabs.org> <8FC7251A-6C37-4B4B-9120-0845616D0E60@kernel.crashing.org> Message-ID: <43E5620A.6060503@us.ibm.com> Kumar Gala wrote: >On Feb 3, 2006, at 2:05 AM, Michael Ellerman wrote: > > > >>It's possible for prom_init to allocate the flat device tree inside >>the >>kdump crash kernel region. If this happens, when we load the kdump >>kernel we >>overwrite the flattened device tree, which is bad. >> >>We could make prom_init try and avoid allocating inside the crash >>kernel >>region, but then we run into issues if the crash kernel region uses >>all the >>space inside the RMO. The easiest solution is to move the flat >>device tree >>once we're running in the kernel. >> >>Signed-off-by: Michael Ellerman >> >> > >Doesn't setup_32.c need a similar change? > > At present kdump will not be supported on ppc32. In case, kdump_move_device_tree() can be called at the beginning of unflatten_device_tree() to support both ppc32 and 64 instead of making changes in setup_64.c and setup_32.c. The extern definition can be removed from asm-powerpc/prom.h and this function can be static. Michael, what do you think if we have some printk to tell the user that device_tree is moved to new location. Because, the console messages from prom_init are saying about old addresses. Thanks Haren >- k > > > >>--- >> >> arch/powerpc/kernel/prom.c | 27 +++++++++++++++++++++++++++ >> arch/powerpc/kernel/setup_64.c | 3 +++ >> include/asm-powerpc/prom.h | 2 ++ >> 3 files changed, 32 insertions(+) >> >>Index: kdump/arch/powerpc/kernel/prom.c >>=================================================================== >>--- kdump.orig/arch/powerpc/kernel/prom.c >>+++ kdump/arch/powerpc/kernel/prom.c >>@@ -1913,3 +1913,30 @@ int prom_update_property(struct device_n >> >> return 0; >> } >>+ >>+#ifdef CONFIG_KEXEC >>+/* We may have allocated the flat device tree inside the crash >>kernel region >>+ * in prom_init. If so we need to move it out into regular memory. */ >>+void kdump_move_device_tree(void) >>+{ >>+ unsigned long start, end; >>+ struct boot_param_header *new; >>+ >>+ start = __pa((unsigned long)initial_boot_params); >>+ end = start + initial_boot_params->totalsize; >>+ >>+ if (end < crashk_res.start || start > crashk_res.end) >>+ return; >>+ >>+ new = (struct boot_param_header*) >>+ __va(lmb_alloc(initial_boot_params->totalsize, PAGE_SIZE)); >>+ >>+ memcpy(new, initial_boot_params, initial_boot_params->totalsize); >>+ >>+ initial_boot_params = new; >>+ >>+ DBG("Flat device tree blob moved to %p\n", initial_boot_params); >>+ >>+ /* XXX should we unreserve the old DT? */ >>+} >>+#endif /* CONFIG_KEXEC */ >>Index: kdump/arch/powerpc/kernel/setup_64.c >>=================================================================== >>--- kdump.orig/arch/powerpc/kernel/setup_64.c >>+++ kdump/arch/powerpc/kernel/setup_64.c >>@@ -398,6 +398,9 @@ void __init setup_system(void) >> { >> DBG(" -> setup_system()\n"); >> >>+#ifdef CONFIG_KEXEC >>+ kdump_move_device_tree(); >>+#endif >> /* >> * Unflatten the device-tree passed by prom_init or kexec >> */ >>Index: kdump/include/asm-powerpc/prom.h >>=================================================================== >>--- kdump.orig/include/asm-powerpc/prom.h >>+++ kdump/include/asm-powerpc/prom.h >>@@ -222,5 +222,7 @@ extern int of_address_to_resource(struct >> extern int of_pci_address_to_resource(struct device_node *dev, int >>bar, >> struct resource *r); >> >>+extern void kdump_move_device_tree(void); >>+ >> #endif /* __KERNEL__ */ >> #endif /* _POWERPC_PROM_H */ >>_______________________________________________ >>Linuxppc64-dev mailing list >>Linuxppc64-dev at ozlabs.org >>https://ozlabs.org/mailman/listinfo/linuxppc64-dev >> >> > >_______________________________________________ >Linuxppc64-dev mailing list >Linuxppc64-dev at ozlabs.org >https://ozlabs.org/mailman/listinfo/linuxppc64-dev > > > From paul at briny.ondioline.org Sun Feb 5 05:26:16 2006 From: paul at briny.ondioline.org (Paul Collins) Date: Sat, 04 Feb 2006 18:26:16 +0000 Subject: [PATCH] powerpc: Fix PowerMac sound i2c In-Reply-To: <1136695956.30123.44.camel@localhost.localdomain> (Benjamin Herrenschmidt's message of "Sun, 08 Jan 2006 15:52:36 +1100") References: <1136695956.30123.44.camel@localhost.localdomain> Message-ID: <87y80rkmk7.fsf@briny.internal.ondioline.org> Hi Ben, Benjamin Herrenschmidt writes: > My patch reworking the PowerMac i2c code break the sound drivers as they > used to rely on some broken behaviour of i2c-keywest that is gone now. > This patch should fix them (tested on a g5 with alsa only). It might > also fix an oops if the alsa driver hits an unsupported chip. Applied Linus's current git tree, this patch makes ALSA sound on my PowerBook5,4 work again. The second patch does not work because the i2c wrapper (I assume that's what i2c_smbus_write_i2c_block_data is) has apparently not yet returned. It would be nice to have this fix in 2.6.16 if possible. > Signed-off-by: Benjamin Herrenschmidt > > Index: linux-work/sound/ppc/tumbler.c > =================================================================== > --- linux-work.orig/sound/ppc/tumbler.c 2005-11-24 17:19:14.000000000 +1100 > +++ linux-work/sound/ppc/tumbler.c 2006-01-08 15:18:09.000000000 +1100 > @@ -137,6 +137,22 @@ static int send_init_client(pmac_keywest > return 0; > } > > +static int tumbler_write_block(struct i2c_client *client, u8 reg, int len, > + u8 *values) > +{ > + union i2c_smbus_data data; > + int err; > + > + data.block[0] = len; > + memcpy(&data.block[1], values, len); > + err = i2c_smbus_xfer(client->adapter, client->addr, client->flags, > + I2C_SMBUS_WRITE, reg, I2C_SMBUS_I2C_BLOCK_DATA, > + &data); > + return err; > +} > + > + > + > > static int tumbler_init_client(pmac_keywest_t *i2c) > { > @@ -239,8 +255,7 @@ static int tumbler_set_master_volume(pma > block[4] = (right_vol >> 8) & 0xff; > block[5] = (right_vol >> 0) & 0xff; > > - if (i2c_smbus_write_block_data(mix->i2c.client, TAS_REG_VOL, > - 6, block) < 0) { > + if (tumbler_write_block(mix->i2c.client, TAS_REG_VOL, 6, block) < 0) { > snd_printk("failed to set volume \n"); > return -EINVAL; > } > @@ -340,8 +355,7 @@ static int tumbler_set_drc(pmac_tumbler_ > val[1] = 0; > } > > - if (i2c_smbus_write_block_data(mix->i2c.client, TAS_REG_DRC, > - 2, val) < 0) { > + if (tumbler_write_block(mix->i2c.client, TAS_REG_DRC, 2, val) < 0) { > snd_printk("failed to set DRC\n"); > return -EINVAL; > } > @@ -376,8 +390,7 @@ static int snapper_set_drc(pmac_tumbler_ > val[4] = 0x60; > val[5] = 0xa0; > > - if (i2c_smbus_write_block_data(mix->i2c.client, TAS_REG_DRC, > - 6, val) < 0) { > + if (tumbler_write_block(mix->i2c.client, TAS_REG_DRC, 6, val) < 0) { > snd_printk("failed to set DRC\n"); > return -EINVAL; > } > @@ -481,8 +494,8 @@ static int tumbler_set_mono_volume(pmac_ > vol = info->table[vol]; > for (i = 0; i < info->bytes; i++) > block[i] = (vol >> ((info->bytes - i - 1) * 8)) & 0xff; > - if (i2c_smbus_write_block_data(mix->i2c.client, info->reg, > - info->bytes, block) < 0) { > + if (tumbler_write_block(mix->i2c.client, info->reg, > + info->bytes, block) < 0) { > snd_printk("failed to set mono volume %d\n", info->index); > return -EINVAL; > } > @@ -611,7 +624,7 @@ static int snapper_set_mix_vol1(pmac_tum > for (j = 0; j < 3; j++) > block[i * 3 + j] = (vol >> ((2 - j) * 8)) & 0xff; > } > - if (i2c_smbus_write_block_data(mix->i2c.client, reg, 9, block) < 0) { > + if (tumbler_write_block(mix->i2c.client, reg, 9, block) < 0) { > snd_printk("failed to set mono volume %d\n", reg); > return -EINVAL; > } > Index: linux-work/sound/oss/dmasound/tas_common.h > =================================================================== > --- linux-work.orig/sound/oss/dmasound/tas_common.h 2005-11-24 17:19:14.000000000 +1100 > +++ linux-work/sound/oss/dmasound/tas_common.h 2006-01-08 15:33:29.000000000 +1100 > @@ -157,6 +157,21 @@ tas_mono_to_stereo(uint mono) > return mono | (mono<<8); > } > > +static int tas_write_block(struct i2c_client *client, u8 reg, int len, u8 *vals) > +{ > + union i2c_smbus_data data; > + int err; > + > + data.block[0] = len; > + memcpy(&data.block[1], vals, len); > + err = i2c_smbus_xfer(client->adapter, client->addr, client->flags, > + I2C_SMBUS_WRITE, reg, I2C_SMBUS_I2C_BLOCK_DATA, > + &data); > + return err; > +} > + > + > + > /* > * Todo: make these functions a bit more efficient ! > */ > @@ -178,10 +193,8 @@ tas_write_register( struct tas_data_t *s > if (write_mode & WRITE_SHADOW) > memcpy(self->shadow[reg_num],data,reg_width); > if (write_mode & WRITE_HW) { > - rc=i2c_smbus_write_block_data(self->client, > - reg_num, > - reg_width, > - data); > + rc = tas_write_block(self->client, reg_num, > + reg_width, data); > if (rc < 0) { > printk("tas: I2C block write failed \n"); > return rc; > @@ -199,10 +212,8 @@ tas_sync_register( struct tas_data_t *se > > if (reg_width==0 || self==NULL) > return -EINVAL; > - rc=i2c_smbus_write_block_data(self->client, > - reg_num, > - reg_width, > - self->shadow[reg_num]); > + rc = tas_write_block(self->client, reg_num, > + reg_width, self->shadow[reg_num]); > if (rc < 0) { > printk("tas: I2C block write failed \n"); > return rc; > Index: linux-work/sound/ppc/pmac.c > =================================================================== > --- linux-work.orig/sound/ppc/pmac.c 2005-12-19 16:13:48.000000000 +1100 > +++ linux-work/sound/ppc/pmac.c 2006-01-08 15:37:10.000000000 +1100 > @@ -74,7 +74,7 @@ static int snd_pmac_dbdma_alloc(pmac_t * > > static void snd_pmac_dbdma_free(pmac_t *chip, pmac_dbdma_t *rec) > { > - if (rec) { > + if (rec->space) { > unsigned int rsize = sizeof(struct dbdma_cmd) * (rec->size + 1); > > dma_free_coherent(&chip->pdev->dev, rsize, rec->space, rec->dma_base); > @@ -895,6 +895,7 @@ static int __init snd_pmac_detect(pmac_t > chip->can_capture = 1; > chip->num_freqs = ARRAY_SIZE(awacs_freqs); > chip->freq_table = awacs_freqs; > + chip->pdev = NULL; > > chip->control_mask = MASK_IEPC | MASK_IEE | 0x11; /* default */ > -- Dag vijandelijk luchtschip de huismeester is dood From bdc at carlstrom.com Sun Feb 5 17:10:48 2006 From: bdc at carlstrom.com (Brian D. Carlstrom) Date: 5 Feb 2006 06:10:48 -0000 Subject: G5 fan problems return moving to 2.6.15 with dual processor 2.7GHz machine Message-ID: <20060205061048.7261.qmail@electricrain.com> I've been having problems with overheating on two of my three dual processor 2.7GHzs running Fedora Core 4's 2.6.14 kernels since November. Because of a pending deadline and the time of year, I simply opened the window and let nature cool the machines. In early January, I saw the therm_pm72.c fix in 2.6.15 http://ozlabs.org/pipermail/linuxppc64-dev/2006-January/007299.html [PATCH] powerpc: more g5 overtemp problem fix I tried Fedora's updates-testing 2.6.15 kernel to get the fix. That caused the fans to blow full blast like the old days, which was better than leaving the window open, which had several issues with storm winds closing the windows, unhappy facilities managers, and "helpful" co-workers closing the windows for me. Finally last week I had some time to work on this. My first step was to backport the therm_pm72.c fix from 2.6.14 and that worked like a charm, allowing humans with hearing to inhabit the office again. I'm running CPU simulations 24/7 on these machines, and without this fix they were powering off once a day or more without any fix, although I'd fixed them to reboot instead with a /sbin/critical_overtemp script that called "reboot -f". However, even after reporting the problems with the 2.6.15 updates-testing kernel, Fedora Core released the 2.6.15 kernel update anyway. I decided to try and debug what is going on since other people are going to start seeing this issue. Looking at the dmesg output change between 2.6.14 and 2.6.15, both start with the following: PowerMac G5 Thermal control driver 1.2b2 Detected fan controls: 0: PWM fan, id 1, location: BACKSIDE,SYS CTRLR FAN 1: RPM fan, id 2, location: DRIVE BAY 2: PWM fan, id 2, location: SLOT,PCI FAN 3: RPM fan, id 3, location: CPU A INTAKE 4: RPM fan, id 4, location: CPU A EXHAUST 5: RPM fan, id 5, location: CPU B INTAKE 6: RPM fan, id 6, location: CPU B EXHAUST 7: RPM fan, id 1, location: CPU A PUMP 8: RPM fan, id 0, location: CPU B PUMP However, 2.6.14 has the following addition line which I've come to expect on the 2.5GHz and 2.7GHz machines, although not on the 2.0GHz machines of course: Liquid cooling pumps detected, using new algorithm ! I decided to do a little more debugging before reporting this. I built the driver with "#define DEBUG" and added some additional DBG tracing messages (marked "XXX bdc" below). Here is the output with therm_pm72 built into the kernel, not as a module: Feb 4 12:19:06 youngmc kernel: Detected fan controls: Feb 4 12:19:06 youngmc kernel: 0: PWM fan, id 1, location: BACKSIDE,SYS CTRLR FAN Feb 4 12:19:06 youngmc kernel: 1: RPM fan, id 2, location: DRIVE BAY Feb 4 12:19:06 youngmc kernel: 2: PWM fan, id 2, location: SLOT,PCI FAN Feb 4 12:19:06 youngmc kernel: 3: RPM fan, id 3, location: CPU A INTAKE Feb 4 12:19:06 youngmc kernel: 4: RPM fan, id 4, location: CPU A EXHAUST Feb 4 12:19:06 youngmc kernel: 5: RPM fan, id 5, location: CPU B INTAKE Feb 4 12:19:06 youngmc kernel: 6: RPM fan, id 6, location: CPU B EXHAUST Feb 4 12:19:06 youngmc kernel: 7: RPM fan, id 1, location: CPU A PUMP Feb 4 12:19:06 youngmc kernel: 8: RPM fan, id 0, location: CPU B PUMP Feb 4 12:19:06 youngmc kernel: XXX bdc therm_pm72_attach Feb 4 12:19:06 youngmc kernel: XXX bdc therm_pm72_attach adapter->name=monid Feb 4 12:19:06 youngmc kernel: XXX bdc therm_pm72_attach Feb 4 12:19:06 youngmc kernel: XXX bdc therm_pm72_attach adapter->name=dvi Feb 4 12:19:06 youngmc kernel: XXX bdc therm_pm72_attach Feb 4 12:19:06 youngmc kernel: XXX bdc therm_pm72_attach adapter->name=vga Feb 4 12:19:06 youngmc kernel: XXX bdc therm_pm72_attach Feb 4 12:19:06 youngmc kernel: XXX bdc therm_pm72_attach adapter->name=crt2 Feb 4 12:19:06 youngmc kernel: Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 Feb 4 12:19:06 youngmc kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx Feb 4 12:19:06 youngmc kernel: ide0: Found Apple K2 ATA-6 controller, bus ID 3, irq 39 Feb 4 12:19:06 youngmc kernel: hda: PIONEER DVD-RW DVR-109, ATAPI CD/DVD-ROM drive Feb 4 12:19:06 youngmc kernel: hda: Enabling Ultra DMA 4 Feb 4 12:19:06 youngmc kernel: ide0 at 0xd000080083656000-0xd000080083656007,0xd000080083656160 on irq 39 Feb 4 12:19:06 youngmc kernel: hda: ATAPI 32X DVD-ROM DVD-R CD-R/RW drive, 2000kB Cache, UDMA(66) Feb 4 12:19:06 youngmc kernel: Uniform CD-ROM driver Revision: 3.20 Feb 4 12:19:06 youngmc kernel: ide-floppy driver 0.99.newide Feb 4 12:19:06 youngmc kernel: usbcore: registered new driver libusual Feb 4 12:19:06 youngmc kernel: usbcore: registered new driver hiddev Feb 4 12:19:06 youngmc kernel: usbcore: registered new driver usbhid Feb 4 12:19:06 youngmc kernel: drivers/usb/input/hid-core.c: v2.6:USB HID core driver Feb 4 12:19:06 youngmc kernel: mice: PS/2 mouse device common for all mice Feb 4 12:19:06 youngmc kernel: /u3 at 0,f8000000/i2c at f8001000: Missing interrupt or address ! Feb 4 12:19:06 youngmc kernel: XXX bdc therm_pm72_attach Feb 4 12:19:06 youngmc kernel: XXX bdc therm_pm72_attach adapter->name=mac-io 0 Feb 4 12:19:06 youngmc kernel: Found K2 Feb 4 12:19:06 youngmc kernel: Found KeyWest i2c on "mac-io", 1 channel, stepping: 4 bits I'm guessing I should have seen a "found U3-0", but I see a suspicious message here: /u3 at 0,f8000000/i2c at f8001000: Missing interrupt or address ! that I do not see in the working 2.6.14 boot. I was wondering if the change from module to builtin was causing the problem (grasping at straws I guess) so I also tried building it as a module. I get the similar results: Feb 4 12:59:26 youngmc kernel: /u3 at 0,f8000000/i2c at f8001000: Missing interrupt or address ! Feb 4 12:59:26 youngmc kernel: Found KeyWest i2c on "mac-io", 1 channel, stepping: 4 bits ... Feb 4 12:59:27 youngmc kernel: Detected fan controls: Feb 4 12:59:27 youngmc kernel: 0: PWM fan, id 1, location: BACKSIDE,SYS CTRLR FAN Feb 4 12:59:27 youngmc kernel: 1: RPM fan, id 2, location: DRIVE BAY Feb 4 12:59:27 youngmc kernel: 2: PWM fan, id 2, location: SLOT,PCI FAN Feb 4 12:59:27 youngmc kernel: 3: RPM fan, id 3, location: CPU A INTAKE Feb 4 12:59:27 youngmc kernel: 4: RPM fan, id 4, location: CPU A EXHAUST Feb 4 12:59:27 youngmc kernel: 5: RPM fan, id 5, location: CPU B INTAKE Feb 4 12:59:27 youngmc kernel: 6: RPM fan, id 6, location: CPU B EXHAUST Feb 4 12:59:27 youngmc kernel: 7: RPM fan, id 1, location: CPU A PUMP Feb 4 12:59:28 youngmc kernel: 8: RPM fan, id 0, location: CPU B PUMP Feb 4 12:59:28 youngmc kernel: XXX bdc therm_pm72_attach Feb 4 12:59:28 youngmc kernel: XXX bdc therm_pm72_attach adapter->name=monid Feb 4 12:59:28 youngmc kernel: XXX bdc therm_pm72_attach Feb 4 12:59:28 youngmc kernel: XXX bdc therm_pm72_attach adapter->name=dvi Feb 4 12:59:28 youngmc kernel: XXX bdc therm_pm72_attach Feb 4 12:59:28 youngmc kernel: XXX bdc therm_pm72_attach adapter->name=vga Feb 4 12:59:28 youngmc kernel: XXX bdc therm_pm72_attach Feb 4 12:59:28 youngmc kernel: XXX bdc therm_pm72_attach adapter->name=crt2 Feb 4 12:59:28 youngmc kernel: XXX bdc therm_pm72_attach Feb 4 12:59:28 youngmc kernel: XXX bdc therm_pm72_attach adapter->name=mac-io 0 Feb 4 12:59:28 youngmc kernel: Found K2 Now this "/u3 at 0,f8000000/i2c at f8001000: Missing interrupt or address !" warning I'm seeing in both cases looked familar, in fact I was on a thread about it when the 2.7GHz machines first came out: http://patchwork.ozlabs.org/linuxppc64/patch?id=1982 The code that this patched applied to has moved to a new location arch/powerpc/kernel/prom_init.c, but logically it still seems like it should cover my case. The code says: if (u3_rev < 0x35 || u3_rev > 0x39) return; and my u3_rev looks to be 0x35 $ hexdump /proc/device-tree/u3 at 0,f8000000/device-rev 0000000 0000 0035 0000004 Unforunately it looks like I need to use prom_print to add debugging, which I'm guessing only comes to the console which I'm not near right now. Before going further, is there something obvious that the Fedora 2.6.15 kernel is doing wrong, given that the 2.6.14 kernel works and the 2.6.15 seems to have a regression? I'm willing to do some more debugging or try a more up-to-date kernel to help resolve this issue. One last note, my dual processor 2.0GHz and 2.5GHz machines are running fine with 2.6.15... -bri From benh at kernel.crashing.org Sun Feb 5 20:06:24 2006 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Sun, 05 Feb 2006 20:06:24 +1100 Subject: G5 fan problems return moving to 2.6.15 with dual processor 2.7GHz machine In-Reply-To: <20060205061048.7261.qmail@electricrain.com> References: <20060205061048.7261.qmail@electricrain.com> Message-ID: <1139130385.5634.14.camel@localhost.localdomain> > I'm guessing I should have seen a "found U3-0", but I see a suspicious message here: > /u3 at 0,f8000000/i2c at f8001000: Missing interrupt or address ! > that I do not see in the working 2.6.14 boot. > > I was wondering if the change from module to builtin was causing the > problem (grasping at straws I guess) so I also tried building it as a > module. I get the similar results: > > Feb 4 12:59:26 youngmc kernel: /u3 at 0,f8000000/i2c at f8001000: Missing interrupt or address ! > Feb 4 12:59:26 youngmc kernel: Found KeyWest i2c on "mac-io", 1 channel, stepping: 4 bits That looks like a fix in prom_init.c that is missing from 2.6.15.. I'll have to double check... Apple indeed seems to have a "bug" in the device-tree of some of those machines. prom_init.c has some code to fix it up, but there have been several versions of the fix and maybe that broke some way... Ah... now I'm reading the rest of the message and see that you figured that out already ;) > Now this "/u3 at 0,f8000000/i2c at f8001000: Missing interrupt or address !" > warning I'm seeing in both cases looked familar, in fact I was on a > thread about it when the 2.7GHz machines first came out: > > http://patchwork.ozlabs.org/linuxppc64/patch?id=1982 > > The code that this patched applied to has moved to a new location > arch/powerpc/kernel/prom_init.c, but logically it still seems like it > should cover my case. The code says: > > if (u3_rev < 0x35 || u3_rev > 0x39) > return; > > and my u3_rev looks to be 0x35 > $ hexdump /proc/device-tree/u3 at 0,f8000000/device-rev > 0000000 0000 0035 > 0000004 > > Unforunately it looks like I need to use prom_print to add debugging, > which I'm guessing only comes to the console which I'm not near right > now. > > Before going further, is there something obvious that the Fedora > 2.6.15 kernel is doing wrong, given that the 2.6.14 kernel works and > the 2.6.15 seems to have a regression? I'm willing to do some more > debugging or try a more up-to-date kernel to help resolve this issue. > > One last note, my dual processor 2.0GHz and 2.5GHz machines are running > fine with 2.6.15... Might be something in that prom_init.c fix that broke... it would be really nice if you could give a try with the console and find out what it is ... Unfortunately, I don't have access to one of these machines with the "problem" at the moment... Cheers, Ben. From galak at kernel.crashing.org Mon Feb 6 03:41:18 2006 From: galak at kernel.crashing.org (Kumar Gala) Date: Sun, 5 Feb 2006 10:41:18 -0600 Subject: [PATCH] powerpc: Don't overwrite flat device tree with kdump kernel In-Reply-To: <43E5620A.6060503@us.ibm.com> References: <20060203080609.403CA68A1F@ozlabs.org> <8FC7251A-6C37-4B4B-9120-0845616D0E60@kernel.crashing.org> <43E5620A.6060503@us.ibm.com> Message-ID: <2E5AE9B2-F10D-4CC4-B8C9-FBC929C76B3D@kernel.crashing.org> On Feb 4, 2006, at 8:25 PM, Haren Myneni wrote: > Kumar Gala wrote: > >> On Feb 3, 2006, at 2:05 AM, Michael Ellerman wrote: >> >> >>> It's possible for prom_init to allocate the flat device tree >>> inside the >>> kdump crash kernel region. If this happens, when we load the >>> kdump kernel we >>> overwrite the flattened device tree, which is bad. >>> >>> We could make prom_init try and avoid allocating inside the >>> crash kernel >>> region, but then we run into issues if the crash kernel region >>> uses all the >>> space inside the RMO. The easiest solution is to move the flat >>> device tree >>> once we're running in the kernel. >>> >>> Signed-off-by: Michael Ellerman >>> >> >> Doesn't setup_32.c need a similar change? >> > At present kdump will not be supported on ppc32. > In case, kdump_move_device_tree() can be called at the beginning of > unflatten_device_tree() to support both ppc32 and 64 instead of > making changes in setup_64.c and setup_32.c. The extern definition > can be removed from asm-powerpc/prom.h and this function can be > static. > > Michael, what do you think if we have some printk to tell the user > that device_tree is moved to new location. Because, the console > messages from prom_init are saying about old addresses. What's the issue with kdump on ppc32? One of the reasons we merged ppc32 and ppc64 was to avoid such issues going forward? - k >>> --- >>> >>> arch/powerpc/kernel/prom.c | 27 +++++++++++++++++++++++++++ >>> arch/powerpc/kernel/setup_64.c | 3 +++ >>> include/asm-powerpc/prom.h | 2 ++ >>> 3 files changed, 32 insertions(+) >>> >>> Index: kdump/arch/powerpc/kernel/prom.c >>> =================================================================== >>> --- kdump.orig/arch/powerpc/kernel/prom.c >>> +++ kdump/arch/powerpc/kernel/prom.c >>> @@ -1913,3 +1913,30 @@ int prom_update_property(struct device_n >>> >>> return 0; >>> } >>> + >>> +#ifdef CONFIG_KEXEC >>> +/* We may have allocated the flat device tree inside the crash >>> kernel region >>> + * in prom_init. If so we need to move it out into regular >>> memory. */ >>> +void kdump_move_device_tree(void) >>> +{ >>> + unsigned long start, end; >>> + struct boot_param_header *new; >>> + >>> + start = __pa((unsigned long)initial_boot_params); >>> + end = start + initial_boot_params->totalsize; >>> + >>> + if (end < crashk_res.start || start > crashk_res.end) >>> + return; >>> + >>> + new = (struct boot_param_header*) >>> + __va(lmb_alloc(initial_boot_params->totalsize, PAGE_SIZE)); >>> + >>> + memcpy(new, initial_boot_params, initial_boot_params->totalsize); >>> + >>> + initial_boot_params = new; >>> + >>> + DBG("Flat device tree blob moved to %p\n", initial_boot_params); >>> + >>> + /* XXX should we unreserve the old DT? */ >>> +} >>> +#endif /* CONFIG_KEXEC */ >>> Index: kdump/arch/powerpc/kernel/setup_64.c >>> =================================================================== >>> --- kdump.orig/arch/powerpc/kernel/setup_64.c >>> +++ kdump/arch/powerpc/kernel/setup_64.c >>> @@ -398,6 +398,9 @@ void __init setup_system(void) >>> { >>> DBG(" -> setup_system()\n"); >>> >>> +#ifdef CONFIG_KEXEC >>> + kdump_move_device_tree(); >>> +#endif >>> /* >>> * Unflatten the device-tree passed by prom_init or kexec >>> */ >>> Index: kdump/include/asm-powerpc/prom.h >>> =================================================================== >>> --- kdump.orig/include/asm-powerpc/prom.h >>> +++ kdump/include/asm-powerpc/prom.h >>> @@ -222,5 +222,7 @@ extern int of_address_to_resource(struct >>> extern int of_pci_address_to_resource(struct device_node *dev, >>> int bar, >>> struct resource *r); >>> >>> +extern void kdump_move_device_tree(void); >>> + >>> #endif /* __KERNEL__ */ >>> #endif /* _POWERPC_PROM_H */ >>> _______________________________________________ >>> Linuxppc64-dev mailing list >>> Linuxppc64-dev at ozlabs.org >>> https://ozlabs.org/mailman/listinfo/linuxppc64-dev >>> >> >> _______________________________________________ >> Linuxppc64-dev mailing list >> Linuxppc64-dev at ozlabs.org >> https://ozlabs.org/mailman/listinfo/linuxppc64-dev >> >> From david at gibson.dropbear.id.au Mon Feb 6 13:18:53 2006 From: david at gibson.dropbear.id.au (David Gibson) Date: Mon, 6 Feb 2006 13:18:53 +1100 Subject: Hugepages need clear_user_highpage() not clear_highpage() Message-ID: <20060206021853.GC10708@localhost.localdomain> When hugepages are newly allocated to a file in mm/hugetlb.c, we clear them with a call to clear_highpage() on each of the subpages. We should be using clear_user_highpage(): on powerpc, at least, clear_highpage() doesn't correctly mark the page as icache dirty so if the page is executed shortly after it's possible to get strange results. This is a bugfix and should go into 2.6.16. Signed-off-by: David Gibson Index: working-2.6/mm/hugetlb.c =================================================================== --- working-2.6.orig/mm/hugetlb.c 2006-02-06 12:58:07.000000000 +1100 +++ working-2.6/mm/hugetlb.c 2006-02-06 12:58:19.000000000 +1100 @@ -107,7 +107,7 @@ struct page *alloc_huge_page(struct vm_a set_page_count(page, 1); page[1].mapping = (void *)free_huge_page; for (i = 0; i < (HPAGE_SIZE/PAGE_SIZE); ++i) - clear_highpage(&page[i]); + clear_user_highpage(&page[i], addr); return page; } -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson From david at gibson.dropbear.id.au Mon Feb 6 13:24:53 2006 From: david at gibson.dropbear.id.au (David Gibson) Date: Mon, 6 Feb 2006 13:24:53 +1100 Subject: powerpc: Cleanup, consolidating icache dirtying logic Message-ID: <20060206022453.GA19390@localhost.localdomain> The code to mark a page as icache dirty (so that it will later be icache-dcache flushed when we try to execute from it) is duplicated in three places: flush_dcache_page() does this marking and nothing else, but clear_user_page() and copy_user_page() duplicate it, since those functions make the page icache dirty themselves. This patch makes those other functions call flush_dcache_page() instead, so the logic's all in one place. This will make life less confusing if we ever need to tweak the details of the the lazy icache flush mechanism. arch/powerpc/mm/mem.c | 14 ++------------ 1 file changed, 2 insertions(+), 12 deletions(-) Signed-off-by: David Gibson Index: working-2.6/arch/powerpc/mm/mem.c =================================================================== --- working-2.6.orig/arch/powerpc/mm/mem.c 2006-02-06 12:58:07.000000000 +1100 +++ working-2.6/arch/powerpc/mm/mem.c 2006-02-06 13:20:29.000000000 +1100 @@ -435,17 +435,12 @@ void clear_user_page(void *page, unsigne { clear_page(page); - if (cpu_has_feature(CPU_FTR_COHERENT_ICACHE)) - return; /* * We shouldnt have to do this, but some versions of glibc * require it (ld.so assumes zero filled pages are icache clean) * - Anton */ - - /* avoid an atomic op if possible */ - if (test_bit(PG_arch_1, &pg->flags)) - clear_bit(PG_arch_1, &pg->flags); + flush_dcache_page(pg); } EXPORT_SYMBOL(clear_user_page); @@ -469,12 +464,7 @@ void copy_user_page(void *vto, void *vfr return; #endif - if (cpu_has_feature(CPU_FTR_COHERENT_ICACHE)) - return; - - /* avoid an atomic op if possible */ - if (test_bit(PG_arch_1, &pg->flags)) - clear_bit(PG_arch_1, &pg->flags); + flush_dcache_page(pg); } void flush_icache_user_range(struct vm_area_struct *vma, struct page *page, -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson From haren at us.ibm.com Mon Feb 6 13:46:05 2006 From: haren at us.ibm.com (Haren Myneni) Date: Sun, 05 Feb 2006 18:46:05 -0800 Subject: [PATCH] powerpc: Don't overwrite flat device tree with kdump kernel In-Reply-To: <2E5AE9B2-F10D-4CC4-B8C9-FBC929C76B3D@kernel.crashing.org> References: <20060203080609.403CA68A1F@ozlabs.org> <8FC7251A-6C37-4B4B-9120-0845616D0E60@kernel.crashing.org> <43E5620A.6060503@us.ibm.com> <2E5AE9B2-F10D-4CC4-B8C9-FBC929C76B3D@kernel.crashing.org> Message-ID: <43E6B86D.4070108@us.ibm.com> Kumar Gala wrote: > > On Feb 4, 2006, at 8:25 PM, Haren Myneni wrote: > >> Kumar Gala wrote: >> >>> On Feb 3, 2006, at 2:05 AM, Michael Ellerman wrote: >>> >>> >>>> It's possible for prom_init to allocate the flat device tree >>>> inside the >>>> kdump crash kernel region. If this happens, when we load the >>>> kdump kernel we >>>> overwrite the flattened device tree, which is bad. >>>> >>>> We could make prom_init try and avoid allocating inside the crash >>>> kernel >>>> region, but then we run into issues if the crash kernel region >>>> uses all the >>>> space inside the RMO. The easiest solution is to move the flat >>>> device tree >>>> once we're running in the kernel. >>>> >>>> Signed-off-by: Michael Ellerman >>>> >>> >>> Doesn't setup_32.c need a similar change? >>> >> At present kdump will not be supported on ppc32. >> In case, kdump_move_device_tree() can be called at the beginning of >> unflatten_device_tree() to support both ppc32 and 64 instead of >> making changes in setup_64.c and setup_32.c. The extern definition >> can be removed from asm-powerpc/prom.h and this function can be static. >> >> Michael, what do you think if we have some printk to tell the user >> that device_tree is moved to new location. Because, the console >> messages from prom_init are saying about old addresses. > > > What's the issue with kdump on ppc32? One of the reasons we merged > ppc32 and ppc64 was to avoid such issues going forward? Main issue is with the user level kexec-tools which does not have the kdump support for PPC32. One of the changes should be some cleanup/merge the way it happened in the kernel. At present, normal kexec support is included for gamecube/ppc32. Any help is appreciated. Thanks Haren > > - k > >>>> --- >>>> >>>> arch/powerpc/kernel/prom.c | 27 +++++++++++++++++++++++++++ >>>> arch/powerpc/kernel/setup_64.c | 3 +++ >>>> include/asm-powerpc/prom.h | 2 ++ >>>> 3 files changed, 32 insertions(+) >>>> >>>> Index: kdump/arch/powerpc/kernel/prom.c >>>> =================================================================== >>>> --- kdump.orig/arch/powerpc/kernel/prom.c >>>> +++ kdump/arch/powerpc/kernel/prom.c >>>> @@ -1913,3 +1913,30 @@ int prom_update_property(struct device_n >>>> >>>> return 0; >>>> } >>>> + >>>> +#ifdef CONFIG_KEXEC >>>> +/* We may have allocated the flat device tree inside the crash >>>> kernel region >>>> + * in prom_init. If so we need to move it out into regular >>>> memory. */ >>>> +void kdump_move_device_tree(void) >>>> +{ >>>> + unsigned long start, end; >>>> + struct boot_param_header *new; >>>> + >>>> + start = __pa((unsigned long)initial_boot_params); >>>> + end = start + initial_boot_params->totalsize; >>>> + >>>> + if (end < crashk_res.start || start > crashk_res.end) >>>> + return; >>>> + >>>> + new = (struct boot_param_header*) >>>> + __va(lmb_alloc(initial_boot_params->totalsize, PAGE_SIZE)); >>>> + >>>> + memcpy(new, initial_boot_params, initial_boot_params->totalsize); >>>> + >>>> + initial_boot_params = new; >>>> + >>>> + DBG("Flat device tree blob moved to %p\n", initial_boot_params); >>>> + >>>> + /* XXX should we unreserve the old DT? */ >>>> +} >>>> +#endif /* CONFIG_KEXEC */ >>>> Index: kdump/arch/powerpc/kernel/setup_64.c >>>> =================================================================== >>>> --- kdump.orig/arch/powerpc/kernel/setup_64.c >>>> +++ kdump/arch/powerpc/kernel/setup_64.c >>>> @@ -398,6 +398,9 @@ void __init setup_system(void) >>>> { >>>> DBG(" -> setup_system()\n"); >>>> >>>> +#ifdef CONFIG_KEXEC >>>> + kdump_move_device_tree(); >>>> +#endif >>>> /* >>>> * Unflatten the device-tree passed by prom_init or kexec >>>> */ >>>> Index: kdump/include/asm-powerpc/prom.h >>>> =================================================================== >>>> --- kdump.orig/include/asm-powerpc/prom.h >>>> +++ kdump/include/asm-powerpc/prom.h >>>> @@ -222,5 +222,7 @@ extern int of_address_to_resource(struct >>>> extern int of_pci_address_to_resource(struct device_node *dev, >>>> int bar, >>>> struct resource *r); >>>> >>>> +extern void kdump_move_device_tree(void); >>>> + >>>> #endif /* __KERNEL__ */ >>>> #endif /* _POWERPC_PROM_H */ >>>> _______________________________________________ >>>> Linuxppc64-dev mailing list >>>> Linuxppc64-dev at ozlabs.org >>>> https://ozlabs.org/mailman/listinfo/linuxppc64-dev >>>> >>> >>> _______________________________________________ >>> Linuxppc64-dev mailing list >>> Linuxppc64-dev at ozlabs.org >>> https://ozlabs.org/mailman/listinfo/linuxppc64-dev >>> >>> > > From michael at ellerman.id.au Mon Feb 6 14:04:49 2006 From: michael at ellerman.id.au (Michael Ellerman) Date: Mon, 6 Feb 2006 14:04:49 +1100 Subject: [PATCH] powerpc: Don't overwrite flat device tree with kdump kernel In-Reply-To: <2E5AE9B2-F10D-4CC4-B8C9-FBC929C76B3D@kernel.crashing.org> References: <20060203080609.403CA68A1F@ozlabs.org> <43E5620A.6060503@us.ibm.com> <2E5AE9B2-F10D-4CC4-B8C9-FBC929C76B3D@kernel.crashing.org> Message-ID: <200602061404.52478.michael@ellerman.id.au> On Mon, 6 Feb 2006 03:41, Kumar Gala wrote: > On Feb 4, 2006, at 8:25 PM, Haren Myneni wrote: > > Kumar Gala wrote: > >> Doesn't setup_32.c need a similar change? > > > > At present kdump will not be supported on ppc32. > > In case, kdump_move_device_tree() can be called at the beginning of > > unflatten_device_tree() to support both ppc32 and 64 instead of > > making changes in setup_64.c and setup_32.c. The extern definition > > can be removed from asm-powerpc/prom.h and this function can be > > static. > > What's the issue with kdump on ppc32? One of the reasons we merged > ppc32 and ppc64 was to avoid such issues going forward? Currently in mainline all we have is hooks for ppc32 kexec, no actual implementation. Apparently it exists somewhere, but I haven't seen it. cheers -- Michael Ellerman IBM OzLabs email: michael:ellerman.id.au inmsg: mpe:jabber.org wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20060206/03a24485/attachment.pgp From michael at ellerman.id.au Mon Feb 6 17:34:14 2006 From: michael at ellerman.id.au (Michael Ellerman) Date: Mon, 06 Feb 2006 17:34:14 +1100 Subject: [PATCH] powerpc: Don't use toc in decrementer_iSeries_masked Message-ID: <20060206063434.22D37689F3@ozlabs.org> Since 404849bbd2bfd62e05b36f4753f6e1af6050a824 we've been using LOAD_REG_ADDRBASE, which uses the toc pointer, in decrementer_iSeries_masked. This can explode if we take the decrementer interrupt while we're in a module, because the toc pointer in r2 will be the module's toc pointer. Instead do an immediate load. I'm not sure if we really need the trickery in here, what do people think? arch/powerpc/kernel/head_64.S | 9 +++++++-- 1 files changed, 7 insertions(+), 2 deletions(-) Index: iseries/arch/powerpc/kernel/head_64.S =================================================================== --- iseries.orig/arch/powerpc/kernel/head_64.S +++ iseries/arch/powerpc/kernel/head_64.S @@ -752,8 +752,13 @@ decrementer_iSeries_masked: li r11,1 ld r12,PACALPPACAPTR(r13) stb r11,LPPACADECRINT(r12) - LOAD_REG_ADDRBASE(r12,tb_ticks_per_jiffy) - lwz r12,ADDROFF(tb_ticks_per_jiffy)(r12) + /* We have no TOC pointer in here, so we can't load tb_ticks_per_jiffy + * using the usual macros. We want to be fast, so we assume the top + * word of the lppaca pointer is the same as the top word of + * &tb_ticks_per_jiffy. + */ + oris r12,r12,tb_ticks_per_jiffy at h + lwz r12,tb_ticks_per_jiffy at l(r12) mtspr SPRN_DEC,r12 /* fall through */ From david at gibson.dropbear.id.au Mon Feb 6 17:42:47 2006 From: david at gibson.dropbear.id.au (David Gibson) Date: Mon, 6 Feb 2006 17:42:47 +1100 Subject: [PATCH] powerpc: Don't use toc in decrementer_iSeries_masked In-Reply-To: <20060206063434.22D37689F3@ozlabs.org> References: <20060206063434.22D37689F3@ozlabs.org> Message-ID: <20060206064247.GA31631@localhost.localdomain> On Mon, Feb 06, 2006 at 05:34:14PM +1100, Michael Ellerman wrote: > Since 404849bbd2bfd62e05b36f4753f6e1af6050a824 we've been using > LOAD_REG_ADDRBASE, which uses the toc pointer, in decrementer_iSeries_masked. > > This can explode if we take the decrementer interrupt while we're in a module, > because the toc pointer in r2 will be the module's toc pointer. > > Instead do an immediate load. I'm not sure if we really need the trickery in > here, what do people think? > > arch/powerpc/kernel/head_64.S | 9 +++++++-- > 1 files changed, 7 insertions(+), 2 deletions(-) > > Index: iseries/arch/powerpc/kernel/head_64.S > =================================================================== > --- iseries.orig/arch/powerpc/kernel/head_64.S > +++ iseries/arch/powerpc/kernel/head_64.S > @@ -752,8 +752,13 @@ decrementer_iSeries_masked: > li r11,1 > ld r12,PACALPPACAPTR(r13) > stb r11,LPPACADECRINT(r12) > - LOAD_REG_ADDRBASE(r12,tb_ticks_per_jiffy) > - lwz r12,ADDROFF(tb_ticks_per_jiffy)(r12) > + /* We have no TOC pointer in here, so we can't load tb_ticks_per_jiffy > + * using the usual macros. We want to be fast, so we assume the top > + * word of the lppaca pointer is the same as the top word of > + * &tb_ticks_per_jiffy. > + */ you need a clrrdi r12,r12,32 here, because r12's low word may not contain zero. > + oris r12,r12,tb_ticks_per_jiffy at h > + lwz r12,tb_ticks_per_jiffy at l(r12) > mtspr SPRN_DEC,r12 > /* fall through */ > > _______________________________________________ > Linuxppc64-dev mailing list > Linuxppc64-dev at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc64-dev > -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson From david at gibson.dropbear.id.au Mon Feb 6 17:44:38 2006 From: david at gibson.dropbear.id.au (David Gibson) Date: Mon, 6 Feb 2006 17:44:38 +1100 Subject: [PATCH] powerpc: Don't use toc in decrementer_iSeries_masked In-Reply-To: <20060206064247.GA31631@localhost.localdomain> References: <20060206063434.22D37689F3@ozlabs.org> <20060206064247.GA31631@localhost.localdomain> Message-ID: <20060206064438.GB31631@localhost.localdomain> On Mon, Feb 06, 2006 at 05:42:47PM +1100, David Gibson wrote: > On Mon, Feb 06, 2006 at 05:34:14PM +1100, Michael Ellerman wrote: > > Since 404849bbd2bfd62e05b36f4753f6e1af6050a824 we've been using > > LOAD_REG_ADDRBASE, which uses the toc pointer, in decrementer_iSeries_masked. > > > > This can explode if we take the decrementer interrupt while we're in a module, > > because the toc pointer in r2 will be the module's toc pointer. > > > > Instead do an immediate load. I'm not sure if we really need the trickery in > > here, what do people think? > > > > arch/powerpc/kernel/head_64.S | 9 +++++++-- > > 1 files changed, 7 insertions(+), 2 deletions(-) > > > > Index: iseries/arch/powerpc/kernel/head_64.S > > =================================================================== > > --- iseries.orig/arch/powerpc/kernel/head_64.S > > +++ iseries/arch/powerpc/kernel/head_64.S > > @@ -752,8 +752,13 @@ decrementer_iSeries_masked: > > li r11,1 > > ld r12,PACALPPACAPTR(r13) > > stb r11,LPPACADECRINT(r12) > > - LOAD_REG_ADDRBASE(r12,tb_ticks_per_jiffy) > > - lwz r12,ADDROFF(tb_ticks_per_jiffy)(r12) > > + /* We have no TOC pointer in here, so we can't load tb_ticks_per_jiffy > > + * using the usual macros. We want to be fast, so we assume the top > > + * word of the lppaca pointer is the same as the top word of > > + * &tb_ticks_per_jiffy. > > + */ > > you need a > clrrdi r12,r12,32 > here, because r12's low word may not contain zero. > > > + oris r12,r12,tb_ticks_per_jiffy at h Oh, and that needs to be @ha, because the load offset below is treated as signed. > > + lwz r12,tb_ticks_per_jiffy at l(r12) > > mtspr SPRN_DEC,r12 > > /* fall through */ -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson From olof at lixom.net Mon Feb 6 17:53:54 2006 From: olof at lixom.net (Olof Johansson) Date: Mon, 6 Feb 2006 00:53:54 -0600 Subject: [PATCH] powerpc: Don't use toc in decrementer_iSeries_masked In-Reply-To: <20060206064247.GA31631@localhost.localdomain> References: <20060206063434.22D37689F3@ozlabs.org> <20060206064247.GA31631@localhost.localdomain> Message-ID: <20060206065354.GA7626@pb15.lixom.net> On Mon, Feb 06, 2006 at 05:42:47PM +1100, David Gibson wrote: > On Mon, Feb 06, 2006 at 05:34:14PM +1100, Michael Ellerman wrote: > > Since 404849bbd2bfd62e05b36f4753f6e1af6050a824 we've been using > > LOAD_REG_ADDRBASE, which uses the toc pointer, in decrementer_iSeries_masked. > > > > This can explode if we take the decrementer interrupt while we're in a module, > > because the toc pointer in r2 will be the module's toc pointer. > > > > Instead do an immediate load. I'm not sure if we really need the trickery in > > here, what do people think? > > > > arch/powerpc/kernel/head_64.S | 9 +++++++-- > > 1 files changed, 7 insertions(+), 2 deletions(-) > > > > Index: iseries/arch/powerpc/kernel/head_64.S > > =================================================================== > > --- iseries.orig/arch/powerpc/kernel/head_64.S > > +++ iseries/arch/powerpc/kernel/head_64.S > > @@ -752,8 +752,13 @@ decrementer_iSeries_masked: > > li r11,1 > > ld r12,PACALPPACAPTR(r13) > > stb r11,LPPACADECRINT(r12) > > - LOAD_REG_ADDRBASE(r12,tb_ticks_per_jiffy) > > - lwz r12,ADDROFF(tb_ticks_per_jiffy)(r12) > > + /* We have no TOC pointer in here, so we can't load tb_ticks_per_jiffy > > + * using the usual macros. We want to be fast, so we assume the top > > + * word of the lppaca pointer is the same as the top word of > > + * &tb_ticks_per_jiffy. > > + */ > > + oris r12,r12,tb_ticks_per_jiffy at h > > you need a > clrrdi r12,r12,32 > here, because r12's low word may not contain zero. Or do: oris r12,r11,tb_ticks_per_jiffy at ha since r11 only contains '1'. It's a bit obfuscated though, it depends on if the saved single extra instruction is that precious or not. :-) -Olof From olof at lixom.net Mon Feb 6 17:55:47 2006 From: olof at lixom.net (Olof Johansson) Date: Mon, 6 Feb 2006 00:55:47 -0600 Subject: [PATCH] powerpc: Don't use toc in decrementer_iSeries_masked In-Reply-To: <20060206065354.GA7626@pb15.lixom.net> References: <20060206063434.22D37689F3@ozlabs.org> <20060206064247.GA31631@localhost.localdomain> <20060206065354.GA7626@pb15.lixom.net> Message-ID: <20060206065547.GB7626@pb15.lixom.net> On Mon, Feb 06, 2006 at 12:53:54AM -0600, Olof Johansson wrote: > Or do: > oris r12,r11,tb_ticks_per_jiffy at ha > > since r11 only contains '1'. It's a bit obfuscated though, it depends on > if the saved single extra instruction is that precious or not. :-) DOH. That obviously won't work. Nevermind. -Olof From wli at holomorphy.com Mon Feb 6 19:19:39 2006 From: wli at holomorphy.com (William Lee Irwin III) Date: Mon, 6 Feb 2006 00:19:39 -0800 Subject: Hugepages need clear_user_highpage() not clear_highpage() In-Reply-To: <20060206021853.GC10708@localhost.localdomain> References: <20060206021853.GC10708@localhost.localdomain> Message-ID: <20060206081939.GA6789@holomorphy.com> On Mon, Feb 06, 2006 at 01:18:53PM +1100, David Gibson wrote: > When hugepages are newly allocated to a file in mm/hugetlb.c, we clear > them with a call to clear_highpage() on each of the subpages. We > should be using clear_user_highpage(): on powerpc, at least, > clear_highpage() doesn't correctly mark the page as icache dirty so if > the page is executed shortly after it's possible to get strange > results. > This is a bugfix and should go into 2.6.16. > Signed-off-by: David Gibson Not sure how this got past the usual crapfilters. Sorry about that. Acked-by: William Irwin -- wli From bgill at freescale.com Tue Feb 7 07:26:31 2006 From: bgill at freescale.com (Becky Bruce) Date: Mon, 6 Feb 2006 14:26:31 -0600 (CST) Subject: [PATCH] documentation: add bus-frequency property to SOC node Message-ID: Updated SOC node definition in documentation to include bus-frequency property. Also extended mdio example to match specification. Signed-off-by: Becky Bruce Signed-off-by: Kumar Gala --- commit 3441bf59c7e1dc3823f9be57838a2536c78f6f8f tree 2901a0e19418f1fe904ff0d041c630b3af048961 parent 66c490c9b00c52cd0f1e088ad689c9148e46f49e author Becky Bruce Thu, 02 Feb 2006 15:41:11 -0600 committer Becky Bruce Thu, 02 Feb 2006 15:41:11 -0600 Documentation/powerpc/booting-without-of.txt | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt index 1284498..54e5f9b 100644 --- a/Documentation/powerpc/booting-without-of.txt +++ b/Documentation/powerpc/booting-without-of.txt @@ -880,6 +880,10 @@ address which can extend beyond that lim - device_type : Should be "soc" - ranges : Should be defined as specified in 1) to describe the translation of SOC addresses for memory mapped SOC registers. + - bus-frequency: Contains the bus frequency for the SOC node. + Typically, the value of this field is filled in by the boot + loader. + Recommended properties: @@ -919,6 +923,7 @@ SOC. device_type = "soc"; ranges = <00000000 e0000000 00100000> reg = ; + bus-frequency = <0>; } @@ -1170,6 +1175,8 @@ platforms are moved over to use the flat mdio at 24520 { reg = <24520 20>; + device_type = "mdio"; + compatible = "gianfar"; ethernet-phy at 0 { ...... @@ -1317,6 +1324,7 @@ not necessary as they are usually the sa device_type = "soc"; ranges = <00000000 e0000000 00100000> reg = ; + bus-frequency = <0>; mdio at 24520 { reg = <24520 20>; From mikey at neuling.org Tue Feb 7 10:58:21 2006 From: mikey at neuling.org (Michael Neuling) Date: Tue, 7 Feb 2006 10:58:21 +1100 Subject: [PATCH] powerpc: hypervisor check in pseries_kexec_cpu_down Message-ID: <20060207105821.bfd5ea21.mikey@neuling.org> Paulus, We call unregister_vpa but we don't check to see if the hypervisor supports this. Please apply. Signed-off-by: Michael Neuling Acked-by: Anton Blanchard -- arch/powerpc/platforms/pseries/setup.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6-powerpc/arch/powerpc/platforms/pseries/setup.c =================================================================== --- linux-2.6-powerpc.orig/arch/powerpc/platforms/pseries/setup.c +++ linux-2.6-powerpc/arch/powerpc/platforms/pseries/setup.c @@ -585,7 +585,7 @@ static int pSeries_pci_probe_mode(struct static void pseries_kexec_cpu_down(int crash_shutdown, int secondary) { /* Don't risk a hypervisor call if we're crashing */ - if (!crash_shutdown) { + if (firmware_has_feature(FW_FEATURE_SPLPAR) && !crash_shutdown) { unsigned long vpa = __pa(get_lppaca()); if (unregister_vpa(hard_smp_processor_id(), vpa)) { From sfr at canb.auug.org.au Tue Feb 7 10:59:06 2006 From: sfr at canb.auug.org.au (Stephen Rothwell) Date: Tue, 7 Feb 2006 10:59:06 +1100 Subject: [PATCH] powerpc: wire up the *at system calls Message-ID: <20060207105906.04a22df3.sfr@canb.auug.org.au> Signed-off-by: Stephen Rothwell --- arch/powerpc/kernel/systbl.S | 13 +++++++++++++ include/asm-powerpc/unistd.h | 15 ++++++++++++++- 2 files changed, 27 insertions(+), 1 deletions(-) This depend on the patch that creates all the compat wrappers. -- Cheers, Stephen Rothwell sfr at canb.auug.org.au http://www.canb.auug.org.au/~sfr/ d02d8208813d8cae2c814a85734a1a31fed2f3ac diff --git a/arch/powerpc/kernel/systbl.S b/arch/powerpc/kernel/systbl.S index 007b15e..fe16d9c 100644 --- a/arch/powerpc/kernel/systbl.S +++ b/arch/powerpc/kernel/systbl.S @@ -323,3 +323,16 @@ SYSCALL(spu_run) SYSCALL(spu_create) COMPAT_SYS(pselect6) COMPAT_SYS(ppoll) +COMPAT_SYS(openat) +COMPAT_SYS(mkdirat) +COMPAT_SYS(mknodat) +COMPAT_SYS(fchownat) +COMPAT_SYS(futimesat) +COMPAT_SYS(newfstatat) +COMPAT_SYS(unlinkat) +COMPAT_SYS(renameat) +COMPAT_SYS(linkat) +COMPAT_SYS(symlinkat) +COMPAT_SYS(readlinkat) +COMPAT_SYS(fchmodat) +COMPAT_SYS(faccessat) diff --git a/include/asm-powerpc/unistd.h b/include/asm-powerpc/unistd.h index a40cdff..d05b85e 100644 --- a/include/asm-powerpc/unistd.h +++ b/include/asm-powerpc/unistd.h @@ -300,8 +300,21 @@ #define __NR_spu_create 279 #define __NR_pselect6 280 #define __NR_ppoll 281 +#define __NR_openat 282 +#define __NR_mkdirat 283 +#define __NR_mknodat 284 +#define __NR_fchownat 285 +#define __NR_futimesat 286 +#define __NR_newfstatat 287 +#define __NR_unlinkat 288 +#define __NR_renameat 289 +#define __NR_linkat 290 +#define __NR_symlinkat 291 +#define __NR_readlinkat 292 +#define __NR_fchmodat 293 +#define __NR_faccessat 294 -#define __NR_syscalls 282 +#define __NR_syscalls 295 #ifdef __KERNEL__ #define __NR__exit __NR_exit -- 1.1.5 From michael at ellerman.id.au Tue Feb 7 11:07:58 2006 From: michael at ellerman.id.au (Michael Ellerman) Date: Tue, 7 Feb 2006 11:07:58 +1100 Subject: [PATCH] powerpc: Don't use toc in decrementer_iSeries_masked In-Reply-To: <20060206063434.22D37689F3@ozlabs.org> References: <20060206063434.22D37689F3@ozlabs.org> Message-ID: <200602071108.01571.michael@ellerman.id.au> On Mon, 6 Feb 2006 17:34, Michael Ellerman wrote: > Since 404849bbd2bfd62e05b36f4753f6e1af6050a824 we've been using > LOAD_REG_ADDRBASE, which uses the toc pointer, in > decrementer_iSeries_masked. > > This can explode if we take the decrementer interrupt while we're in a > module, because the toc pointer in r2 will be the module's toc pointer. > > Instead do an immediate load. I'm not sure if we really need the trickery > in here, what do people think? I think we answered that question pretty thoroughly, I'll post an updated and simplified version soon. cheers -- Michael Ellerman IBM OzLabs email: michael:ellerman.id.au inmsg: mpe:jabber.org wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20060207/3ebdce2c/attachment.pgp From michael at ellerman.id.au Tue Feb 7 11:21:13 2006 From: michael at ellerman.id.au (Michael Ellerman) Date: Tue, 7 Feb 2006 11:21:13 +1100 Subject: [PATCH] powerpc: hypervisor check in pseries_kexec_cpu_down In-Reply-To: <20060207105821.bfd5ea21.mikey@neuling.org> References: <20060207105821.bfd5ea21.mikey@neuling.org> Message-ID: <200602071121.17076.michael@ellerman.id.au> On Tue, 7 Feb 2006 10:58, Michael Neuling wrote: > Index: linux-2.6-powerpc/arch/powerpc/platforms/pseries/setup.c > =================================================================== > --- linux-2.6-powerpc.orig/arch/powerpc/platforms/pseries/setup.c > +++ linux-2.6-powerpc/arch/powerpc/platforms/pseries/setup.c > @@ -585,7 +585,7 @@ static int pSeries_pci_probe_mode(struct > static void pseries_kexec_cpu_down(int crash_shutdown, int secondary) > { > /* Don't risk a hypervisor call if we're crashing */ > - if (!crash_shutdown) { > + if (firmware_has_feature(FW_FEATURE_SPLPAR) && !crash_shutdown) { > unsigned long vpa = __pa(get_lppaca()); > > if (unregister_vpa(hard_smp_processor_id(), vpa)) { Is SPLPAR the right test? I would have thought LPAR? cheers -- Michael Ellerman IBM OzLabs email: michael:ellerman.id.au inmsg: mpe:jabber.org wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20060207/782a9e55/attachment.pgp From mikey at neuling.org Tue Feb 7 11:58:16 2006 From: mikey at neuling.org (Michael Neuling) Date: Tue, 7 Feb 2006 11:58:16 +1100 Subject: [PATCH] powerpc: hypervisor check in pseries_kexec_cpu_down In-Reply-To: <200602071121.17076.michael@ellerman.id.au> References: <20060207105821.bfd5ea21.mikey@neuling.org> <200602071121.17076.michael@ellerman.id.au> Message-ID: <20060207115816.c2314f86.mikey@neuling.org> > Is SPLPAR the right test? I would have thought LPAR? I missed your patch which added this but you're right. Revised patch attached. Now depends on MPE's patches from here: http://patchwork.ozlabs.org/linuxppc64/patch?id=4088 -- We call unregister_vpa but we don't check to see if the hypervisor supports this. Signed-off-by: Michael Neuling arch/powerpc/platforms/pseries/setup.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6-powerpc/arch/powerpc/platforms/pseries/setup.c =================================================================== --- linux-2.6-powerpc.orig/arch/powerpc/platforms/pseries/setup.c +++ linux-2.6-powerpc/arch/powerpc/platforms/pseries/setup.c @@ -585,7 +585,7 @@ static int pSeries_pci_probe_mode(struct static void pseries_kexec_cpu_down(int crash_shutdown, int secondary) { /* Don't risk a hypervisor call if we're crashing */ - if (!crash_shutdown) { + if (firmware_has_feature(FW_FEATURE_LPAR) && !crash_shutdown) { unsigned long vpa = __pa(get_lppaca()); if (unregister_vpa(hard_smp_processor_id(), vpa)) { From michael at ellerman.id.au Tue Feb 7 13:26:14 2006 From: michael at ellerman.id.au (Michael Ellerman) Date: Tue, 07 Feb 2006 13:26:14 +1100 Subject: [PATCH] powerpc: Don't use toc in decrementer_iSeries_masked Message-ID: <20060207022639.1F591689DD@ozlabs.org> Since 404849bbd2bfd62e05b36f4753f6e1af6050a824 we've been using LOAD_REG_ADDRBASE, which uses the toc pointer, in decrementer_iSeries_masked. This can explode if we take the decrementer interrupt while we're in a module, because the toc pointer in r2 will be the module's toc pointer. arch/powerpc/kernel/head_64.S | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) Index: iseries/arch/powerpc/kernel/head_64.S =================================================================== --- iseries.orig/arch/powerpc/kernel/head_64.S +++ iseries/arch/powerpc/kernel/head_64.S @@ -749,11 +749,12 @@ iSeries_secondary_smp_loop: .globl decrementer_iSeries_masked decrementer_iSeries_masked: + /* We may not have a valid TOC pointer in here. */ li r11,1 ld r12,PACALPPACAPTR(r13) stb r11,LPPACADECRINT(r12) - LOAD_REG_ADDRBASE(r12,tb_ticks_per_jiffy) - lwz r12,ADDROFF(tb_ticks_per_jiffy)(r12) + LOAD_REG_IMMEDIATE(r12, tb_ticks_per_jiffy) + lwz r12,0(r12) mtspr SPRN_DEC,r12 /* fall through */ From ntl at pobox.com Tue Feb 7 14:39:53 2006 From: ntl at pobox.com (Nathan Lynch) Date: Mon, 6 Feb 2006 21:39:53 -0600 Subject: [PATCH] powerpc: hypervisor check in pseries_kexec_cpu_down In-Reply-To: <20060207115816.c2314f86.mikey@neuling.org> References: <20060207105821.bfd5ea21.mikey@neuling.org> <200602071121.17076.michael@ellerman.id.au> <20060207115816.c2314f86.mikey@neuling.org> Message-ID: <20060207033953.GH18730@localhost.localdomain> Michael Neuling wrote: > > Is SPLPAR the right test? I would have thought LPAR? > > I missed your patch which added this but you're right. Actually I think the original patch is correct. VPAs come into play only when the hypervisor supports the SPLPAR option. From paulus at samba.org Tue Feb 7 14:41:39 2006 From: paulus at samba.org (Paul Mackerras) Date: Tue, 7 Feb 2006 14:41:39 +1100 Subject: merge these lists? Message-ID: <17384.5875.790692.127762@cargo.ozlabs.ibm.com> A lot of messages seem to get cross-posted to both linuxppc-dev and linuxppc64-dev these days, since we are all working in the one tree. Rather than having to cross-post, I propose that we create a single powerpc-dev at ozlabs.org list to replace linuxppc-dev and linuxppc64-dev. (The linuxppc-embedded list would continue as at present.) If we do this, we would set up the new list with the union of the subscribers of the old lists, and make emails sent to linuxppc-dev and linuxppc64-dev go to the new list, so it should be painless. Thoughts? Comments? Objections? Paul. From jk at ozlabs.org Tue Feb 7 14:45:45 2006 From: jk at ozlabs.org (Jeremy Kerr) Date: Tue, 7 Feb 2006 14:45:45 +1100 Subject: merge these lists? In-Reply-To: <17384.5875.790692.127762@cargo.ozlabs.ibm.com> References: <17384.5875.790692.127762@cargo.ozlabs.ibm.com> Message-ID: <200602071445.45805.jk@ozlabs.org> Paul, > If we do this, we would set up the new list with the union of the > subscribers of the old lists, and make emails sent to linuxppc-dev > and linuxppc64-dev go to the new list, so it should be painless. > > Thoughts? Comments? Objections? How about the patchwork lists? Should I look at merging those too? Jeremy From haren at us.ibm.com Tue Feb 7 14:50:03 2006 From: haren at us.ibm.com (Haren Myneni) Date: Mon, 06 Feb 2006 19:50:03 -0800 Subject: [PATCH] Fix in free initrd when overlapped with crashkernel region Message-ID: <43E818EB.7010003@us.ibm.com> It is possible that the reserved crashkernel region can be overlapped with initrd since the bootloader sets the initrd location. When the initrd region is freed, the second kernel memory will not be contiguous. The Kexec_load can cause an oops since there is no contiguous memory to write the second kernel or this memory could be used in the first kernel itself and may not be part of the dump. For example, on powerpc, the initrd is located at 36MB and the crashkernel starts at 32MB. The kexec_load caused panic since writing into non-allocated memory (after 36MB). We could see the similar issue even on other archs. One possibility is to move the initrd outside of crashkernel region. But, the initrd region will be freed anyway before the system is up. This patch fixes this issue and frees only regions that are not part of crashkernel memory in case overlaps. Thanks Haren Signed-off-by: Haren Myneni -------------- next part -------------- A non-text attachment was scrubbed... Name: kdump-initrd-overlap-fix.patch Type: text/x-patch Size: 1723 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20060206/cb4e1a08/attachment.bin From olof at lixom.net Tue Feb 7 15:12:43 2006 From: olof at lixom.net (Olof Johansson) Date: Mon, 6 Feb 2006 22:12:43 -0600 Subject: merge these lists? In-Reply-To: <200602071445.45805.jk@ozlabs.org> References: <17384.5875.790692.127762@cargo.ozlabs.ibm.com> <200602071445.45805.jk@ozlabs.org> Message-ID: <20060207041243.GC7626@pb15.lixom.net> On Tue, Feb 07, 2006 at 02:45:45PM +1100, Jeremy Kerr wrote: > Paul, > > > If we do this, we would set up the new list with the union of the > > subscribers of the old lists, and make emails sent to linuxppc-dev > > and linuxppc64-dev go to the new list, so it should be painless. > > > > Thoughts? Comments? Objections? > > How about the patchwork lists? Should I look at merging those too? I get a feeling that our maintainers might not be using them much any more (most patches since August of last year are still "New"), but I find it convenient to search for a patch that you know has gone by but can't find in your list mbox. I would appreciate either a merge, or a new archive started for the new list. It's useful. -Olof From michael at ellerman.id.au Tue Feb 7 15:29:49 2006 From: michael at ellerman.id.au (Michael Ellerman) Date: Tue, 7 Feb 2006 15:29:49 +1100 Subject: merge these lists? In-Reply-To: <20060207041243.GC7626@pb15.lixom.net> References: <17384.5875.790692.127762@cargo.ozlabs.ibm.com> <200602071445.45805.jk@ozlabs.org> <20060207041243.GC7626@pb15.lixom.net> Message-ID: <200602071529.52073.michael@ellerman.id.au> On Tue, 7 Feb 2006 15:12, Olof Johansson wrote: > On Tue, Feb 07, 2006 at 02:45:45PM +1100, Jeremy Kerr wrote: > > Paul, > > > > > If we do this, we would set up the new list with the union of the > > > subscribers of the old lists, and make emails sent to linuxppc-dev > > > and linuxppc64-dev go to the new list, so it should be painless. > > > > > > Thoughts? Comments? Objections? > > > > How about the patchwork lists? Should I look at merging those too? > > I get a feeling that our maintainers might not be using them much any > more (most patches since August of last year are still "New"), but I > find it convenient to search for a patch that you know has gone by but > can't find in your list mbox. > > I would appreciate either a merge, or a new archive started for the new > list. It's useful. And while Jk has nothing else to do .. I'd like to be able to managed my own patches, ie. set them as obsolete etc etc. Oh and yeah I think we should merge the lists :D cheers -- Michael Ellerman IBM OzLabs email: michael:ellerman.id.au inmsg: mpe:jabber.org wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20060207/1a84a395/attachment.pgp From ntl at pobox.com Tue Feb 7 15:44:23 2006 From: ntl at pobox.com (Nathan Lynch) Date: Mon, 6 Feb 2006 22:44:23 -0600 Subject: [PATCH] avoid timer interrupt replay effect when onlining cpu Message-ID: <20060207044422.GI18730@localhost.localdomain> When a cpu is hotplug-onlined, if we don't set per_cpu(last_jiffy) to something sane, timer_interrupt will execute its while loop for every tick missed since the cpu was last online (or since the system was booted, if we're adding a new cpu). This can cause weird hangs, ssh sessions dropping, and we can even go xmon if we take a global IPI at the wrong time. Signed-off-by: Nathan Lynch --- powerpc-timer_interrupt-replay.orig/arch/powerpc/kernel/smp.c +++ powerpc-timer_interrupt-replay/arch/powerpc/kernel/smp.c @@ -540,6 +540,9 @@ int __devinit start_secondary(void *unus if (smp_ops->take_timebase) smp_ops->take_timebase(); + if (system_state > SYSTEM_BOOTING) + per_cpu(last_jiffy, cpu) = get_tb(); + spin_lock(&call_lock); cpu_set(cpu, cpu_online_map); spin_unlock(&call_lock); From mikey at neuling.org Tue Feb 7 15:55:39 2006 From: mikey at neuling.org (Michael Neuling) Date: Tue, 7 Feb 2006 15:55:39 +1100 Subject: [PATCH] powerpc: hypervisor check in pseries_kexec_cpu_down In-Reply-To: <20060207033953.GH18730@localhost.localdomain> References: <20060207105821.bfd5ea21.mikey@neuling.org> <200602071121.17076.michael@ellerman.id.au> <20060207115816.c2314f86.mikey@neuling.org> <20060207033953.GH18730@localhost.localdomain> Message-ID: <20060207155539.8e2130b7.mikey@neuling.org> > > > Is SPLPAR the right test? I would have thought LPAR? > > > > I missed your patch which added this but you're right. > > Actually I think the original patch is correct. VPAs come into play > only when the hypervisor supports the SPLPAR option. My bad. Looking at the PAPR you're right. Original patch is good. Second patch is bogus. Mikey From michael at ellerman.id.au Tue Feb 7 16:02:33 2006 From: michael at ellerman.id.au (Michael Ellerman) Date: Tue, 7 Feb 2006 16:02:33 +1100 Subject: [PATCH] powerpc: Don't use toc in decrementer_iSeries_masked In-Reply-To: <20060207022639.1F591689DD@ozlabs.org> References: <20060207022639.1F591689DD@ozlabs.org> Message-ID: <200602071602.36387.michael@ellerman.id.au> On Tue, 7 Feb 2006 13:26, Michael Ellerman wrote: > Since 404849bbd2bfd62e05b36f4753f6e1af6050a824 we've been using > LOAD_REG_ADDRBASE, which uses the toc pointer, in > decrementer_iSeries_masked. > > This can explode if we take the decrementer interrupt while we're in a > module, because the toc pointer in r2 will be the module's toc pointer. Ooops ... Signed-off-by: Michael Ellerman -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20060207/bf7fb4ea/attachment.pgp From michael at ellerman.id.au Tue Feb 7 16:03:11 2006 From: michael at ellerman.id.au (Michael Ellerman) Date: Tue, 7 Feb 2006 16:03:11 +1100 Subject: [PATCH] powerpc: Fix !SMP build of rtas.c In-Reply-To: <20060131061807.0104468A53@ozlabs.org> References: <20060131061807.0104468A53@ozlabs.org> Message-ID: <200602071603.14043.michael@ellerman.id.au> On Tue, 31 Jan 2006 17:17, Michael Ellerman wrote: > arch/powerpc/kernel/rtas.c is getting hvcall.h via spinlock.h, but when > we're building for UP we don't include spinlock.h. > > arch/powerpc/kernel/rtas.c | 1 + > 1 files changed, 1 insertion(+) Signed-off-by: Michael Ellerman -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20060207/00d0561d/attachment.pgp From michael at ellerman.id.au Tue Feb 7 16:03:52 2006 From: michael at ellerman.id.au (Michael Ellerman) Date: Tue, 7 Feb 2006 16:03:52 +1100 Subject: [PATCH] powerpc: ibmveth: Harden driver initilisation for kexec In-Reply-To: <20060131041055.5623C68A46@ozlabs.org> References: <20060131041055.5623C68A46@ozlabs.org> Message-ID: <200602071603.55743.michael@ellerman.id.au> On Tue, 31 Jan 2006 15:10, Michael Ellerman wrote: > After a kexec the veth driver will fail when trying to register with the > Hypervisor because the previous kernel has not unregistered. > > So if the registration fails, we unregister and then try again. Sorry this is missing: Signed-off-by: Michael Ellerman -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20060207/a5ff0bbc/attachment.pgp From michael at ellerman.id.au Tue Feb 7 16:22:00 2006 From: michael at ellerman.id.au (Michael Ellerman) Date: Tue, 07 Feb 2006 16:22:00 +1100 Subject: [PATCH] powerpc: Make BUG_ON & WARN_ON play nice with compile-time optimisations Message-ID: <20060207052220.917C668A92@ozlabs.org> Currently if you do BUG_ON(0) you'll still get a trap instruction in your object, although it'll never trigger. That's ok, but a bit ugly, it'd be nice if the compiler could completely eliminate any trace of the BUG_ON. So update the BUG_ON & WARN_ON macros to make this possible. From the comment in the patch: The if statement in BUG_ON and WARN_ON gives the compiler a chance to do compile-time optimisation and possibly elide the entire block. The check for !__builtin_constant(x) has the oppposite effect, if we must do the test at runtime then we avoid a spurious compare and branch by ensuring the if condition is always true. I've confirmed it works in both cases, if the condition is false at compile time we get no code emitted for the BUG statement. If the condition needs to be evaluated at runtime we get the same code we used to, ie. only one test in the trap instruction. It's not clear from the patch due to the whitespace changes, but there's no changes to the inline asm whatsoever. For consideration for 2.6.17 I guess. Signed-off-by: Michael Ellerman --- include/asm-powerpc/bug.h | 46 +++++++++++++++++++++++++++++----------------- 1 files changed, 29 insertions(+), 17 deletions(-) Index: iseries/include/asm-powerpc/bug.h =================================================================== --- iseries.orig/include/asm-powerpc/bug.h +++ iseries/include/asm-powerpc/bug.h @@ -39,25 +39,37 @@ struct bug_entry *find_bug(unsigned long : : "i" (__LINE__), "i" (__FILE__), "i" (__FUNCTION__)); \ } while (0) -#define BUG_ON(x) do { \ - __asm__ __volatile__( \ - "1: "PPC_TLNEI" %0,0\n" \ - ".section __bug_table,\"a\"\n" \ - "\t"PPC_LONG" 1b,%1,%2,%3\n" \ - ".previous" \ - : : "r" ((long)(x)), "i" (__LINE__), \ - "i" (__FILE__), "i" (__FUNCTION__)); \ +/* + * The if statement in BUG_ON and WARN_ON gives the compiler a chance to do + * compile-time optimisation and possibly elide the entire block. The check + * for !__builtin_constant(x) has the oppposite effect, if we must do the + * test at runtime then we avoid a spurious compare and branch by ensuring + * the if condition is always true. + */ + +#define BUG_ON(x) do { \ + if (!__builtin_constant_p(x) || (x)) { \ + __asm__ __volatile__( \ + "1: "PPC_TLNEI" %0,0\n" \ + ".section __bug_table,\"a\"\n" \ + "\t"PPC_LONG" 1b,%1,%2,%3\n" \ + ".previous" \ + : : "r" ((long)(x)), "i" (__LINE__), \ + "i" (__FILE__), "i" (__FUNCTION__)); \ + } \ } while (0) -#define WARN_ON(x) do { \ - __asm__ __volatile__( \ - "1: "PPC_TLNEI" %0,0\n" \ - ".section __bug_table,\"a\"\n" \ - "\t"PPC_LONG" 1b,%1,%2,%3\n" \ - ".previous" \ - : : "r" ((long)(x)), \ - "i" (__LINE__ + BUG_WARNING_TRAP), \ - "i" (__FILE__), "i" (__FUNCTION__)); \ +#define WARN_ON(x) do { \ + if (!__builtin_constant_p(x) || (x)) { \ + __asm__ __volatile__( \ + "1: "PPC_TLNEI" %0,0\n" \ + ".section __bug_table,\"a\"\n" \ + "\t"PPC_LONG" 1b,%1,%2,%3\n" \ + ".previous" \ + : : "r" ((long)(x)), \ + "i" (__LINE__ + BUG_WARNING_TRAP), \ + "i" (__FILE__), "i" (__FUNCTION__)); \ + } \ } while (0) #define HAVE_ARCH_BUG From sfr at canb.auug.org.au Tue Feb 7 17:40:17 2006 From: sfr at canb.auug.org.au (Stephen Rothwell) Date: Tue, 7 Feb 2006 17:40:17 +1100 Subject: [PATCH] compat: add compat functions for *at syscalls In-Reply-To: <20060206.160140.59716704.davem@davemloft.net> References: <20060207105631.39a1080c.sfr@canb.auug.org.au> <20060206.160140.59716704.davem@davemloft.net> Message-ID: <20060207174017.5e3b0ce0.sfr@canb.auug.org.au> On Mon, 06 Feb 2006 16:01:40 -0800 (PST) "David S. Miller" wrote: > > From: Stephen Rothwell > Date: Tue, 7 Feb 2006 10:56:31 +1100 > > > This adds compat version of all the remaining *at syscalls > > so that the "dfd" arguments can be properly sign extended. > > > > Signed-off-by: Stephen Rothwell > > I do the sign extension with tiny stubs in arch/sparc64/kernel/sys32.S > so that the arg frobbing does not consume a stack frame, which is what > happens if you do this in C code. > > We need to revisit this at some point and make a way for all > compat platforms to do this with a portable table of some kind > that expands a bunch of macros defined by the platform. How about the following (modifiying Linus' suggestion and copying what sparc64 already does)? The assumption is that all arguments have been zero extended by the compat syscall entry code, so we just sign extend those that need it. I am not sure of the sparc64 code below, s390 doesn't seem to follow our "all arguments are zero extended" assumption and x86_64 may not need any of these wrappers anyway. It may be that we would be better following Linus's suggestion of generating stubs for all of the compat syscalls. -- Cheers, Stephen Rothwell sfr at canb.auug.org.au http://www.canb.auug.org.au/~sfr/ Subject: [PATCH] compat: introduce kernel/compat_wrapper.S and the necessary compat_wrapper.h with implementations for powerpc and sparc64. compat_wrapper.S builds wrappers for those syscalls that require sign extension for some of their arguments. Signed-off-by: Stephen Rothwell --- arch/sparc64/kernel/systbls.S | 6 +++--- include/asm-ia64/compat_wrapper.h | 15 +++++++++++++++ include/asm-mips/compat_wrapper.h | 15 +++++++++++++++ include/asm-parisc/compat_wrapper.h | 15 +++++++++++++++ include/asm-powerpc/compat_wrapper.h | 28 ++++++++++++++++++++++++++++ include/asm-s390/compat_wrapper.h | 15 +++++++++++++++ include/asm-sparc64/compat_wrapper.h | 33 +++++++++++++++++++++++++++++++++ include/asm-x86_64/compat_wrapper.h | 15 +++++++++++++++ include/linux/compat.h | 22 ++++++++++++++++++++++ kernel/Makefile | 2 +- kernel/compat_wrapper.S | 18 ++++++++++++++++++ 11 files changed, 180 insertions(+), 4 deletions(-) create mode 100644 include/asm-ia64/compat_wrapper.h create mode 100644 include/asm-mips/compat_wrapper.h create mode 100644 include/asm-parisc/compat_wrapper.h create mode 100644 include/asm-powerpc/compat_wrapper.h create mode 100644 include/asm-s390/compat_wrapper.h create mode 100644 include/asm-sparc64/compat_wrapper.h create mode 100644 include/asm-x86_64/compat_wrapper.h create mode 100644 kernel/compat_wrapper.S 1cffeae9ae628af849952cf90fbfca1d98befb97 diff --git a/arch/sparc64/kernel/systbls.S b/arch/sparc64/kernel/systbls.S index 2881faf..a2cc631 100644 --- a/arch/sparc64/kernel/systbls.S +++ b/arch/sparc64/kernel/systbls.S @@ -77,9 +77,9 @@ sys_call_table32: /*270*/ .word sys32_io_submit, sys_io_cancel, compat_sys_io_getevents, sys32_mq_open, sys_mq_unlink .word compat_sys_mq_timedsend, compat_sys_mq_timedreceive, compat_sys_mq_notify, compat_sys_mq_getsetattr, compat_sys_waitid /*280*/ .word sys_ni_syscall, sys_add_key, sys_request_key, sys_keyctl, compat_sys_openat - .word sys_mkdirat, sys_mknodat, sys_fchownat, compat_sys_futimesat, compat_sys_newfstatat -/*285*/ .word sys_unlinkat, sys_renameat, sys_linkat, sys_symlinkat, sys_readlinkat - .word sys_fchmodat, sys_faccessat, compat_sys_pselect6, compat_sys_ppoll + .word compat_sys_mkdirat, compat_sys_mknodat, compat_sys_fchownat, compat_sys_futimesat, compat_sys_newfstatat +/*285*/ .word compat_sys_unlinkat, compat_sys_renameat, compat_sys_linkat, compat_sys_symlinkat, compat_sys_readlinkat + .word compat_sys_fchmodat, compat_sys_faccessat, compat_sys_pselect6, compat_sys_ppoll #endif /* CONFIG_COMPAT */ diff --git a/include/asm-ia64/compat_wrapper.h b/include/asm-ia64/compat_wrapper.h new file mode 100644 index 0000000..f82befc --- /dev/null +++ b/include/asm-ia64/compat_wrapper.h @@ -0,0 +1,15 @@ +/* + * Definitions used to generate the sign extending stubs + * for compat syscalls + */ + +#define ARG1 +#define ARG2 +#define ARG3 +#define ARG4 +#define ARG5 +#define ARG6 + +#define compat_fn1(fn, arg) + +#define compat_fn2(fn, arg1, arg2) diff --git a/include/asm-mips/compat_wrapper.h b/include/asm-mips/compat_wrapper.h new file mode 100644 index 0000000..f82befc --- /dev/null +++ b/include/asm-mips/compat_wrapper.h @@ -0,0 +1,15 @@ +/* + * Definitions used to generate the sign extending stubs + * for compat syscalls + */ + +#define ARG1 +#define ARG2 +#define ARG3 +#define ARG4 +#define ARG5 +#define ARG6 + +#define compat_fn1(fn, arg) + +#define compat_fn2(fn, arg1, arg2) diff --git a/include/asm-parisc/compat_wrapper.h b/include/asm-parisc/compat_wrapper.h new file mode 100644 index 0000000..f82befc --- /dev/null +++ b/include/asm-parisc/compat_wrapper.h @@ -0,0 +1,15 @@ +/* + * Definitions used to generate the sign extending stubs + * for compat syscalls + */ + +#define ARG1 +#define ARG2 +#define ARG3 +#define ARG4 +#define ARG5 +#define ARG6 + +#define compat_fn1(fn, arg) + +#define compat_fn2(fn, arg1, arg2) diff --git a/include/asm-powerpc/compat_wrapper.h b/include/asm-powerpc/compat_wrapper.h new file mode 100644 index 0000000..9bc0669 --- /dev/null +++ b/include/asm-powerpc/compat_wrapper.h @@ -0,0 +1,28 @@ +/* + * Definitions used to generate the sign extending stubs + * for compat syscalls + * + * Copyright (C) 2006 Stephen Rothwell, IBM Corp + */ + +#define ARG1 %r3 +#define ARG2 %r4 +#define ARG3 %r5 +#define ARG4 %r6 +#define ARG5 %r7 +#define ARG6 %r8 + +#define compat_fn1(fn, arg) \ + .text; \ + .global .compat_sys_ ## fn; \ +.compat_sys_ ## fn: \ + extsw arg, arg; \ + b .sys_ ## fn + +#define compat_fn2(fn, arg1, arg2) \ + .text; \ + .global .compat_sys_ ## fn; \ +.compat_sys_ ## fn: \ + extsw arg1, arg1; \ + extsw arg2, arg2; \ + b .sys_ ## fn diff --git a/include/asm-s390/compat_wrapper.h b/include/asm-s390/compat_wrapper.h new file mode 100644 index 0000000..f82befc --- /dev/null +++ b/include/asm-s390/compat_wrapper.h @@ -0,0 +1,15 @@ +/* + * Definitions used to generate the sign extending stubs + * for compat syscalls + */ + +#define ARG1 +#define ARG2 +#define ARG3 +#define ARG4 +#define ARG5 +#define ARG6 + +#define compat_fn1(fn, arg) + +#define compat_fn2(fn, arg1, arg2) diff --git a/include/asm-sparc64/compat_wrapper.h b/include/asm-sparc64/compat_wrapper.h new file mode 100644 index 0000000..42afb2c --- /dev/null +++ b/include/asm-sparc64/compat_wrapper.h @@ -0,0 +1,33 @@ +/* + * Definitions used to generate the sign extending stubs + * for compat syscalls + * + * Copyright (C) 2006 Stephen Rothwell, IBM Corp + * Based on arch/sparc64/kernel/sys32.S + */ + +#define ARG1 %o0 +#define ARG2 %o1 +#define ARG3 %o2 +#define ARG4 %o3 +#define ARG5 %o4 +#define ARG6 %o5 + +#define compat_fn1(fn, arg) \ + .text; \ + .align 32; \ + .globl compat_sys_ ## fn; \ +compat_sys_ ## fn: \ + sethi %hi(sys_ ## fn), %g1; \ + jmpl %g1 + %lo(sys_ ## fn), %g0; \ + sra arg, 0, arg + +#define compat_fn2(fn, arg1, arg2) \ + .text; \ + .align 32; \ + .globl compat_sys_ ## fn; \ +compat_sys_ ## fn: \ + sethi %hi(sys_ ## fn), %g1; \ + sra arg1, 0, arg1; \ + jmpl %g1 + %lo(sys_ ## fn), %g0; \ + sra arg2, 0, arg2 diff --git a/include/asm-x86_64/compat_wrapper.h b/include/asm-x86_64/compat_wrapper.h new file mode 100644 index 0000000..f82befc --- /dev/null +++ b/include/asm-x86_64/compat_wrapper.h @@ -0,0 +1,15 @@ +/* + * Definitions used to generate the sign extending stubs + * for compat syscalls + */ + +#define ARG1 +#define ARG2 +#define ARG3 +#define ARG4 +#define ARG5 +#define ARG6 + +#define compat_fn1(fn, arg) + +#define compat_fn2(fn, arg1, arg2) diff --git a/include/linux/compat.h b/include/linux/compat.h index 2d7e7f1..b501201 100644 --- a/include/linux/compat.h +++ b/include/linux/compat.h @@ -168,6 +168,28 @@ asmlinkage long compat_sys_newfstatat(un int flag); asmlinkage long compat_sys_openat(unsigned int dfd, const char __user *filename, int flags, int mode); +asmlinkage long compat_sys_mkdirat(unsigned int dfd, + const char __user * pathname, int mode); +asmlinkage long compat_sys_mknodat(unsigned int dfd, + const char __user *filename, int mode, unsigned dev); +asmlinkage long compat_sys_fchownat(unsigned int dfd, + const char __user *filename, uid_t user, gid_t group, int flag); +asmlinkage long compat_sys_unlinkat(unsigned int dfd, + const char __user *pathname, int flag); +asmlinkage long compat_sys_renameat(unsigned int olddfd, + const char __user *oldname, unsigned int newdfd, + const char __user *newname); +asmlinkage long compat_sys_linkat(unsigned int olddfd, + const char __user *oldname, unsigned int newdfd, + const char __user *newname); +asmlinkage long compat_sys_symlinkat(const char __user *oldname, + unsigned int newdfd, const char __user *newname); +asmlinkage long compat_sys_readlinkat(unsigned int dfd, + const char __user *path, char __user *buf, int bufsiz); +asmlinkage long compat_sys_fchmodat(unsigned int dfd, + const char __user *filename, mode_t mode); +asmlinkage long compat_sys_faccessat(unsigned int dfd, + const char __user *filename, int mode); #endif /* CONFIG_COMPAT */ #endif /* _LINUX_COMPAT_H */ diff --git a/kernel/Makefile b/kernel/Makefile index 4ae0fbd..a0679c4 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -22,7 +22,7 @@ obj-$(CONFIG_KALLSYMS) += kallsyms.o obj-$(CONFIG_PM) += power/ obj-$(CONFIG_BSD_PROCESS_ACCT) += acct.o obj-$(CONFIG_KEXEC) += kexec.o -obj-$(CONFIG_COMPAT) += compat.o +obj-$(CONFIG_COMPAT) += compat.o compat_wrapper.o obj-$(CONFIG_CPUSETS) += cpuset.o obj-$(CONFIG_IKCONFIG) += configs.o obj-$(CONFIG_STOP_MACHINE) += stop_machine.o diff --git a/kernel/compat_wrapper.S b/kernel/compat_wrapper.S new file mode 100644 index 0000000..da009eb --- /dev/null +++ b/kernel/compat_wrapper.S @@ -0,0 +1,18 @@ +/* + * Copyright (C) 2006 Stephen Rothwell, IBM Corp + * + * this file will generate compat_ wrapper functions for + * syscalls that need sign extension for some of their arguments + */ +#include + +compat_fn1(mkdirat, ARG1) +compat_fn1(mknodat, ARG1) +compat_fn1(fchownat, ARG1) +compat_fn1(unlinkat, ARG1) +compat_fn2(renameat, ARG1, ARG3) +compat_fn2(linkat, ARG1, ARG3) +compat_fn1(symlinkat, ARG2) +compat_fn1(readlinkat, ARG1) +compat_fn1(fchmodat, ARG1) +compat_fn1(faccessat, ARG1) -- 1.1.5 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20060207/553bb4f8/attachment.pgp From paulus at samba.org Tue Feb 7 19:47:39 2006 From: paulus at samba.org (Paul Mackerras) Date: Tue, 7 Feb 2006 19:47:39 +1100 Subject: [PATCH] Fix in free initrd when overlapped with crashkernel region In-Reply-To: <43E818EB.7010003@us.ibm.com> References: <43E818EB.7010003@us.ibm.com> Message-ID: <17384.24235.960221.979322@cargo.ozlabs.ibm.com> Haren Myneni writes: > --- 2616-rc2.orig/include/linux/kexec.h 2006-02-06 19:08:01.000000000 -0800 > +++ 2616-rc2/include/linux/kexec.h 2006-02-06 19:06:37.000000000 -0800 > @@ -6,6 +6,7 @@ > #include > #include > #include > +#include > #include What's this hunk for? Paul. From hch at lst.de Tue Feb 7 21:56:43 2006 From: hch at lst.de (Christoph Hellwig) Date: Tue, 7 Feb 2006 11:56:43 +0100 Subject: merge these lists? In-Reply-To: <17384.5875.790692.127762@cargo.ozlabs.ibm.com> References: <17384.5875.790692.127762@cargo.ozlabs.ibm.com> Message-ID: <20060207105643.GA22234@lst.de> On Tue, Feb 07, 2006 at 02:41:39PM +1100, Paul Mackerras wrote: > A lot of messages seem to get cross-posted to both linuxppc-dev and > linuxppc64-dev these days, since we are all working in the one tree. > Rather than having to cross-post, I propose that we create a single > powerpc-dev at ozlabs.org list to replace linuxppc-dev and > linuxppc64-dev. (The linuxppc-embedded list would continue as at > present.) Why not just kill linuxppc64-dev and leave linuxppc-dev? Probably not worth to remove the well-known and widely used address just for the sake of it. From galak at kernel.crashing.org Wed Feb 8 01:35:23 2006 From: galak at kernel.crashing.org (Kumar Gala) Date: Tue, 7 Feb 2006 08:35:23 -0600 Subject: merge these lists? In-Reply-To: <20060207105643.GA22234@lst.de> References: <17384.5875.790692.127762@cargo.ozlabs.ibm.com> <20060207105643.GA22234@lst.de> Message-ID: On Feb 7, 2006, at 4:56 AM, Christoph Hellwig wrote: > On Tue, Feb 07, 2006 at 02:41:39PM +1100, Paul Mackerras wrote: >> A lot of messages seem to get cross-posted to both linuxppc-dev and >> linuxppc64-dev these days, since we are all working in the one tree. >> Rather than having to cross-post, I propose that we create a single >> powerpc-dev at ozlabs.org list to replace linuxppc-dev and >> linuxppc64-dev. (The linuxppc-embedded list would continue as at >> present.) > > Why not just kill linuxppc64-dev and leave linuxppc-dev? Probably not > worth to remove the well-known and widely used address just for the > sake of it. I agree. Let's just kill linuxppc64-dev and direct people at linuxppc-dev. - kumar From galak at kernel.crashing.org Wed Feb 8 01:36:35 2006 From: galak at kernel.crashing.org (Kumar Gala) Date: Tue, 7 Feb 2006 08:36:35 -0600 Subject: merge these lists? In-Reply-To: <200602071445.45805.jk@ozlabs.org> References: <17384.5875.790692.127762@cargo.ozlabs.ibm.com> <200602071445.45805.jk@ozlabs.org> Message-ID: <6FED97E8-FD6B-4CEC-983F-5CA149A50E79@kernel.crashing.org> On Feb 6, 2006, at 9:45 PM, Jeremy Kerr wrote: > Paul, > >> If we do this, we would set up the new list with the union of the >> subscribers of the old lists, and make emails sent to linuxppc-dev >> and linuxppc64-dev go to the new list, so it should be painless. >> >> Thoughts? Comments? Objections? > > How about the patchwork lists? Should I look at merging those too? Hmm, how about a merged patchwork starting after 2.6.16? - kumar From linas at austin.ibm.com Wed Feb 8 03:43:05 2006 From: linas at austin.ibm.com (Linas Vepstas) Date: Tue, 7 Feb 2006 10:43:05 -0600 Subject: merge these lists? In-Reply-To: References: <17384.5875.790692.127762@cargo.ozlabs.ibm.com> <20060207105643.GA22234@lst.de> Message-ID: <20060207164305.GI24916@austin.ibm.com> On Tue, Feb 07, 2006 at 08:35:23AM -0600, Kumar Gala was heard to remark: > > I agree. Let's just kill linuxppc64-dev and direct people at > linuxppc-dev. Can a sysadmin merge the subscription lists? I didn't even know that there was a linuxppc-dev list; I thought the merge of these two lists occured a year ago, when it was moved to ozlabs :-/ --linas From jschopp at austin.ibm.com Wed Feb 8 03:45:38 2006 From: jschopp at austin.ibm.com (Joel Schopp) Date: Tue, 07 Feb 2006 10:45:38 -0600 Subject: merge these lists? In-Reply-To: <17384.5875.790692.127762@cargo.ozlabs.ibm.com> References: <17384.5875.790692.127762@cargo.ozlabs.ibm.com> Message-ID: <43E8CEB2.4020009@austin.ibm.com> > A lot of messages seem to get cross-posted to both linuxppc-dev and > linuxppc64-dev these days, since we are all working in the one tree. > Rather than having to cross-post, I propose that we create a single > powerpc-dev at ozlabs.org list to replace linuxppc-dev and > linuxppc64-dev. (The linuxppc-embedded list would continue as at > present.) > > If we do this, we would set up the new list with the union of the > subscribers of the old lists, and make emails sent to linuxppc-dev and > linuxppc64-dev go to the new list, so it should be painless. > > Thoughts? Comments? Objections? Marvelous idea. I like the new name too, matches the kernel tree and all that. A few points to make sure we get right, most of which have already been mentioned: -New archives should have links to the old archives. -Old list addresses should automagically send to new list. -The subscribers to both lists should automagically be subscribed to the new list. From jschopp at austin.ibm.com Wed Feb 8 04:06:25 2006 From: jschopp at austin.ibm.com (Joel Schopp) Date: Tue, 07 Feb 2006 11:06:25 -0600 Subject: [PATCH] avoid timer interrupt replay effect when onlining cpu In-Reply-To: <20060207044422.GI18730@localhost.localdomain> References: <20060207044422.GI18730@localhost.localdomain> Message-ID: <43E8D391.2090208@austin.ibm.com> > Signed-off-by: Nathan Lynch > > > --- powerpc-timer_interrupt-replay.orig/arch/powerpc/kernel/smp.c > +++ powerpc-timer_interrupt-replay/arch/powerpc/kernel/smp.c > @@ -540,6 +540,9 @@ int __devinit start_secondary(void *unus > if (smp_ops->take_timebase) > smp_ops->take_timebase(); > > + if (system_state > SYSTEM_BOOTING) > + per_cpu(last_jiffy, cpu) = get_tb(); > + > spin_lock(&call_lock); > cpu_set(cpu, cpu_online_map); > spin_unlock(&call_lock); > _______________________________________________ Yep, this bug has been seen in SUSE & Redhat distro kernels and this patch fixes it. While we are here, is there any reason we still have next_jiffy_update_tb in the paca? It isn't used anywhere anymore. Acked-by: Joel Schopp From bdc at carlstrom.com Wed Feb 8 06:26:17 2006 From: bdc at carlstrom.com (Brian D. Carlstrom) Date: Tue, 7 Feb 2006 11:26:17 -0800 Subject: G5 fan problems return moving to 2.6.15 with dual processor 2.7GHz machine In-Reply-To: <1139130385.5634.14.camel@localhost.localdomain> References: <20060205061048.7261.qmail@electricrain.com> <1139130385.5634.14.camel@localhost.localdomain> Message-ID: <17384.62553.442011.514155@zot.electricrain.com> Benjamin Herrenschmidt writes: > Might be something in that prom_init.c fix that broke... it would be > really nice if you could give a try with the console and find out what > it is ... Unfortunately, I don't have access to one of these machines > with the "problem" at the moment... Well, I added several prom_printf calls to prom_init.c's fixup_device_tree routine. I assumed I would spot these scrolling by during boot before what appears to be the video mode switch. However, I didn't see anything, but I wasn't sure if it wasn't just going by too fast. I tried using PROM_BUG to halt the output, but that just resulted in returning to an OpenFirmware prompt, although with a white background instead of the usual black background when I go their from yaboot with 'o'. I also tried putting a "while (1) ;" after one of my prom_printf, in case the illegal instruction used by PROM_BUG was causing the output to be lost, since it was clearing the screen to display the OpenFirmware prompt. However then I just got a pure white screen. So clearly in both cases it was running my changed code, but I see no output. I tried reviewing some OpenFirmware doc, looking at their talk of debugging via serial and telnet, but that all seemed to be a dead end, although I learned much more about the device tree. :) Clearly I could theoretically debug by moving the while(1); around to see what branches are being taken, but since I'm away from the machines today, I figured I'd ask how I'm expected to use prom_printf, before returning to debugging tomorrow. Sorry my lack of ppc experience is showing. -bri From geoffrey.levand at am.sony.com Wed Feb 8 07:37:32 2006 From: geoffrey.levand at am.sony.com (Geoff Levand) Date: Tue, 07 Feb 2006 12:37:32 -0800 Subject: __setup_cpu_be problem Message-ID: <43E9050C.2000300@am.sony.com> Arnd, It seems HID6 is a hypervisor resource... Can we just have '.cpu_setup = __setup_cpu_power4', and you setup your page sizes somewhere else? -Geoff struct cpu_spec cpu_specs[] = { { /* Cell Broadband Engine */ .cpu_setup = __setup_cpu_be, }, _GLOBAL(__setup_cpu_be) /* Set large page sizes LP=0: 16MB, LP=1: 64KB */ addi r3, 0, 0 ori r3, r3, HID6_LB sldi r3, r3, 32 nor r3, r3, r3 mfspr r4, SPRN_HID6 and r4, r4, r3 addi r3, 0, 0x02000 sldi r3, r3, 32 or r4, r4, r3 mtspr SPRN_HID6, r4 blr From heiko.carstens at de.ibm.com Tue Feb 7 20:31:54 2006 From: heiko.carstens at de.ibm.com (Heiko Carstens) Date: Tue, 7 Feb 2006 10:31:54 +0100 Subject: [PATCH] compat: add compat functions for *at syscalls In-Reply-To: <20060207174017.5e3b0ce0.sfr@canb.auug.org.au> References: <20060207105631.39a1080c.sfr@canb.auug.org.au> <20060206.160140.59716704.davem@davemloft.net> <20060207174017.5e3b0ce0.sfr@canb.auug.org.au> Message-ID: <20060207093154.GA9311@osiris.boeblingen.de.ibm.com> > How about the following (modifiying Linus' suggestion and copying what > sparc64 already does)? > > The assumption is that all arguments have been zero extended by the compat > syscall entry code, so we just sign extend those that need it. > > I am not sure of the sparc64 code below, s390 doesn't seem to follow our > "all arguments are zero extended" assumption and x86_64 may not need any > of these wrappers anyway. On s390 we do already sign extension for int/long and zero extension for the unsigned parameters. Even though I wasn't aware that we should do zero extension for _all_ parameters of the compat system calls, regardless of their type. In addition we must do pointer conversion to 64 bit, since the compat tasks have the most significant bit set (to distinguish between 24- and 31-bit addressing mode). Therefore I think Linus' suggestion with having something like compat_fn6(sys_waitif, SARG, UARG, UARG, SARG, UARG); would be better. Just that we would need something for pointers as well. And to make things just a bit more complicated: only the first five parameters are in registers. Number six and the following are already on the stack. E.g. the compat wrapper for the futex syscall would need extra assembly code to do conversion on the stack. Maybe having defines like SARG1..SARG6 that would define assembly code instead of the register would do the job. Thanks, Heiko From heiko.carstens at de.ibm.com Wed Feb 8 00:29:49 2006 From: heiko.carstens at de.ibm.com (Heiko Carstens) Date: Tue, 7 Feb 2006 14:29:49 +0100 Subject: [PATCH] compat: add compat functions for *at syscalls In-Reply-To: <20060207093154.GA9311@osiris.boeblingen.de.ibm.com> References: <20060207105631.39a1080c.sfr@canb.auug.org.au> <20060206.160140.59716704.davem@davemloft.net> <20060207174017.5e3b0ce0.sfr@canb.auug.org.au> <20060207093154.GA9311@osiris.boeblingen.de.ibm.com> Message-ID: <20060207132949.GB9311@osiris.boeblingen.de.ibm.com> > Therefore I think Linus' suggestion with having something like > > compat_fn6(sys_waitif, SARG, UARG, UARG, SARG, UARG); > > would be better. Just that we would need something for pointers as well. > And to make things just a bit more complicated: only the first five > parameters are in registers. Number six and the following are already on > the stack. E.g. the compat wrapper for the futex syscall would need extra > assembly code to do conversion on the stack. > > Maybe having defines like SARG1..SARG6 that would define assembly code > instead of the register would do the job. Ah, stupid me... the SARG define defines assembly code of course. Just that we would need different defines for arguments that are in registers or on the stack. Is s390 the only architecture that has argument six on the stack? Heiko From greg at kroah.com Wed Feb 8 09:21:44 2006 From: greg at kroah.com (Greg KH) Date: Tue, 7 Feb 2006 14:21:44 -0800 Subject: [PATCH]: Documentation: Updated PCI Error Recovery In-Reply-To: <20060203000602.GQ24916@austin.ibm.com> References: <20060203000602.GQ24916@austin.ibm.com> Message-ID: <20060207222144.GA15622@kroah.com> On Thu, Feb 02, 2006 at 06:06:02PM -0600, Linas Vepstas wrote: > > I'm not sure who I'm addressing this patch to: Linus, maybe? > > Please apply. Fingers crossed, I hope this may make it into 2.6.16. This does not apply to the current tree, what kernel did you do it against? Care to respin it against the latest -git release? thanks, greg k-h From akpm at osdl.org Wed Feb 8 09:30:52 2006 From: akpm at osdl.org (Andrew Morton) Date: Tue, 7 Feb 2006 14:30:52 -0800 Subject: [PATCH]: Documentation: Updated PCI Error Recovery In-Reply-To: <20060207222144.GA15622@kroah.com> References: <20060203000602.GQ24916@austin.ibm.com> <20060207222144.GA15622@kroah.com> Message-ID: <20060207143052.19978ca7.akpm@osdl.org> Greg KH wrote: > > On Thu, Feb 02, 2006 at 06:06:02PM -0600, Linas Vepstas wrote: > > > > I'm not sure who I'm addressing this patch to: Linus, maybe? > > > > Please apply. Fingers crossed, I hope this may make it into 2.6.16. > > This does not apply to the current tree, what kernel did you do it > against? > > Care to respin it against the latest -git release? > err, I already merged it. Saw "documentation" and leapt on it ;) From greg at kroah.com Wed Feb 8 09:39:56 2006 From: greg at kroah.com (Greg KH) Date: Tue, 7 Feb 2006 14:39:56 -0800 Subject: [PATCH]: Documentation: Updated PCI Error Recovery In-Reply-To: <20060207143052.19978ca7.akpm@osdl.org> References: <20060203000602.GQ24916@austin.ibm.com> <20060207222144.GA15622@kroah.com> <20060207143052.19978ca7.akpm@osdl.org> Message-ID: <20060207223956.GA19009@kroah.com> On Tue, Feb 07, 2006 at 02:30:52PM -0800, Andrew Morton wrote: > Greg KH wrote: > > > > On Thu, Feb 02, 2006 at 06:06:02PM -0600, Linas Vepstas wrote: > > > > > > I'm not sure who I'm addressing this patch to: Linus, maybe? > > > > > > Please apply. Fingers crossed, I hope this may make it into 2.6.16. > > > > This does not apply to the current tree, what kernel did you do it > > against? > > > > Care to respin it against the latest -git release? > > > > err, I already merged it. Saw "documentation" and leapt on it ;) Ah, nevermind then... For some reason patch didn't say it looked like it had already been applied, otherwise I would have caught that... thanks, greg k-h From slpratt at austin.ibm.com Wed Feb 8 09:45:48 2006 From: slpratt at austin.ibm.com (Steven Pratt) Date: Tue, 07 Feb 2006 16:45:48 -0600 Subject: make install fails Message-ID: <43E9231C.4000004@austin.ibm.com> Hey, does anyone know why you can no longer do "make install" on ppc kernels on recent releases? Steve From akpm at osdl.org Wed Feb 8 09:53:47 2006 From: akpm at osdl.org (Andrew Morton) Date: Tue, 7 Feb 2006 14:53:47 -0800 Subject: [PATCH]: Documentation: Updated PCI Error Recovery In-Reply-To: <20060207223956.GA19009@kroah.com> References: <20060203000602.GQ24916@austin.ibm.com> <20060207222144.GA15622@kroah.com> <20060207143052.19978ca7.akpm@osdl.org> <20060207223956.GA19009@kroah.com> Message-ID: <20060207145347.72c0a77e.akpm@osdl.org> Greg KH wrote: > > On Tue, Feb 07, 2006 at 02:30:52PM -0800, Andrew Morton wrote: > > Greg KH wrote: > > > > > > On Thu, Feb 02, 2006 at 06:06:02PM -0600, Linas Vepstas wrote: > > > > > > > > I'm not sure who I'm addressing this patch to: Linus, maybe? > > > > > > > > Please apply. Fingers crossed, I hope this may make it into 2.6.16. > > > > > > This does not apply to the current tree, what kernel did you do it > > > against? > > > > > > Care to respin it against the latest -git release? > > > > > > > err, I already merged it. Saw "documentation" and leapt on it ;) > > Ah, nevermind then... For some reason patch didn't say it looked like > it had already been applied, otherwise I would have caught that... > It could be all the newly-added trailing whitespace I chopped off. `patch -p1 -R -l --dry-run'. From haren at us.ibm.com Wed Feb 8 10:01:30 2006 From: haren at us.ibm.com (Haren Myneni) Date: Tue, 07 Feb 2006 15:01:30 -0800 Subject: [PATCH] Fix in free initrd when overlapped with crashkernel region In-Reply-To: <17384.24235.960221.979322@cargo.ozlabs.ibm.com> References: <43E818EB.7010003@us.ibm.com> <17384.24235.960221.979322@cargo.ozlabs.ibm.com> Message-ID: <43E926CA.3000601@us.ibm.com> Paul Mackerras wrote: >Haren Myneni writes: > > > >>--- 2616-rc2.orig/include/linux/kexec.h 2006-02-06 19:08:01.000000000 -0800 >>+++ 2616-rc2/include/linux/kexec.h 2006-02-06 19:06:37.000000000 -0800 >>@@ -6,6 +6,7 @@ >> #include >> #include >> #include >>+#include >> #include >> >> > >What's this hunk for? > >Paul. > > crashk_res is an extern declaration in kexec.h. Declared as "struct resource" which is defined in linux/ioport.h. For other places wherever this variable is used, ioport.h got included through some other header file. Whereas for initramfs.c, either we need to include ioport.h explicitly or include in kexec.h. Chosen the later one. Probably, some comment would be better to make it clear. Paul, do you prefer to repost the patch with the comment? Thanks Haren >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to majordomo at vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ > > > From geoffrey.levand at am.sony.com Wed Feb 8 10:10:47 2006 From: geoffrey.levand at am.sony.com (Geoff Levand) Date: Tue, 07 Feb 2006 15:10:47 -0800 Subject: [PATCH] fix prom_init undefined error Message-ID: <43E928F7.1050307@am.sony.com> Paul, This patch fixes a build error when CONFIG_PPC_OF=n, CONFIG_PPC_MULTIPLATFORM=y. It makes the conditionals consistent in arch/powerpc/kernel/Makefile and head_64.S to both be on CONFIG_PPC_OF. arch/powerpc/kernel/head_64.o: In function `.__boot_from_prom': linux/arch/powerpc/kernel/head_64.S:(.text+0x8158): undefined reference to `.prom_init' obj-$(CONFIG_PPC_OF) += prom_init.o Signed-off-by: Geoff Levand -- --- powerpc.git.orig/arch/powerpc/kernel/head_64.S 2006-02-07 13:18:14.000000000 -0800 +++ powerpc.git/arch/powerpc/kernel/head_64.S 2006-02-07 14:51:15.000000000 -0800 @@ -1515,7 +1515,7 @@ * */ _GLOBAL(__start_initialization_multiplatform) -#ifdef CONFIG_PPC_MULTIPLATFORM +#ifdef CONFIG_PPC_OF /* * Are we booted from a PROM Of-type client-interface ? */ @@ -1542,7 +1542,7 @@ bl .__mmu_off b .__after_prom_start -#ifdef CONFIG_PPC_MULTIPLATFORM +#ifdef CONFIG_PPC_OF _STATIC(__boot_from_prom) /* Save parameters */ mr r31,r3 From greg at kroah.com Wed Feb 8 10:19:27 2006 From: greg at kroah.com (Greg KH) Date: Tue, 7 Feb 2006 15:19:27 -0800 Subject: [PATCH]: Documentation: Updated PCI Error Recovery In-Reply-To: <20060207145347.72c0a77e.akpm@osdl.org> References: <20060203000602.GQ24916@austin.ibm.com> <20060207222144.GA15622@kroah.com> <20060207143052.19978ca7.akpm@osdl.org> <20060207223956.GA19009@kroah.com> <20060207145347.72c0a77e.akpm@osdl.org> Message-ID: <20060207231927.GB19648@kroah.com> On Tue, Feb 07, 2006 at 02:53:47PM -0800, Andrew Morton wrote: > Greg KH wrote: > > > > On Tue, Feb 07, 2006 at 02:30:52PM -0800, Andrew Morton wrote: > > > Greg KH wrote: > > > > > > > > On Thu, Feb 02, 2006 at 06:06:02PM -0600, Linas Vepstas wrote: > > > > > > > > > > I'm not sure who I'm addressing this patch to: Linus, maybe? > > > > > > > > > > Please apply. Fingers crossed, I hope this may make it into 2.6.16. > > > > > > > > This does not apply to the current tree, what kernel did you do it > > > > against? > > > > > > > > Care to respin it against the latest -git release? > > > > > > > > > > err, I already merged it. Saw "documentation" and leapt on it ;) > > > > Ah, nevermind then... For some reason patch didn't say it looked like > > it had already been applied, otherwise I would have caught that... > > > > It could be all the newly-added trailing whitespace I chopped off. > `patch -p1 -R -l --dry-run'. Yup, that was it, quilt would have stripped them off for me too. Linas, please don't do this anymore... thanks, greg k-h From haren at us.ibm.com Wed Feb 8 10:47:03 2006 From: haren at us.ibm.com (Haren Myneni) Date: Tue, 07 Feb 2006 15:47:03 -0800 Subject: [PATHC] Trivial fix to set the proper timeout value for kdump Message-ID: <43E93177.5020601@us.ibm.com> The panic CPU is waiting forever due to some large timeout value if some CPU is not responding to an IPI. This patch will fixes this issue - The maximum waiting period will be 10 seconds and does the kdump boot. Thanks Haren Signed-off-by: Haren Myneni -------------- next part -------------- A non-text attachment was scrubbed... Name: kdump-timeout-value-fix.patch Type: text/x-patch Size: 616 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20060207/2b4e3870/attachment.bin From davem at davemloft.net Wed Feb 8 09:57:25 2006 From: davem at davemloft.net (David S. Miller) Date: Tue, 07 Feb 2006 14:57:25 -0800 (PST) Subject: [PATCH] compat: add compat functions for *at syscalls In-Reply-To: <20060207132949.GB9311@osiris.boeblingen.de.ibm.com> References: <20060207174017.5e3b0ce0.sfr@canb.auug.org.au> <20060207093154.GA9311@osiris.boeblingen.de.ibm.com> <20060207132949.GB9311@osiris.boeblingen.de.ibm.com> Message-ID: <20060207.145725.22157385.davem@davemloft.net> From: Heiko Carstens Date: Tue, 7 Feb 2006 14:29:49 +0100 > Ah, stupid me... the SARG define defines assembly code of course. Just > that we would need different defines for arguments that are in registers > or on the stack. Is s390 the only architecture that has argument six on > the stack? If I remember correctly, o32 mips binaries put arg 6 on the stack too. From sfr at canb.auug.org.au Wed Feb 8 11:01:50 2006 From: sfr at canb.auug.org.au (Stephen Rothwell) Date: Wed, 8 Feb 2006 11:01:50 +1100 Subject: merge these lists? In-Reply-To: <20060207164305.GI24916@austin.ibm.com> References: <17384.5875.790692.127762@cargo.ozlabs.ibm.com> <20060207105643.GA22234@lst.de> <20060207164305.GI24916@austin.ibm.com> Message-ID: <20060208110150.5d9d1936.sfr@canb.auug.org.au> On Tue, 7 Feb 2006 10:43:05 -0600 linas at austin.ibm.com (Linas Vepstas) wrote: > > On Tue, Feb 07, 2006 at 08:35:23AM -0600, Kumar Gala was heard to remark: > > > > I agree. Let's just kill linuxppc64-dev and direct people at > > linuxppc-dev. > > Can a sysadmin merge the subscription lists? Yes, "a sysadmin" could do that. However, those that are subscribed with different addresses on each list will end up subscribed twice and those who have changed their preferences on the abondoned list will have fix them as well. -- Cheers, Stephen Rothwell sfr at canb.auug.org.au http://www.canb.auug.org.au/~sfr/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20060208/fbe140ee/attachment.pgp From sfr at canb.auug.org.au Wed Feb 8 11:07:18 2006 From: sfr at canb.auug.org.au (Stephen Rothwell) Date: Wed, 8 Feb 2006 11:07:18 +1100 Subject: Membership stats (Was: Re: merge these lists?) In-Reply-To: <20060208110150.5d9d1936.sfr@canb.auug.org.au> References: <17384.5875.790692.127762@cargo.ozlabs.ibm.com> <20060207105643.GA22234@lst.de> <20060207164305.GI24916@austin.ibm.com> <20060208110150.5d9d1936.sfr@canb.auug.org.au> Message-ID: <20060208110718.57e9f9f5.sfr@canb.auug.org.au> On Wed, 8 Feb 2006 11:01:50 +1100 Stephen Rothwell wrote: > > Yes, "a sysadmin" could do that. However, those that are > subscribed with different addresses on each list will end > up subscribed twice and those who have changed their preferences on > the abondoned list will have fix them as well. Just for interest: members of linuxppc-dev 473 members of linuxppc64-dev 264 common 98 But, as I said, "common" above does not count those who have different addresses subscribed to each list. -- Cheers, Stephen Rothwell sfr at canb.auug.org.au http://www.canb.auug.org.au/~sfr/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20060208/0efd61cc/attachment.pgp From benh at kernel.crashing.org Wed Feb 8 14:56:56 2006 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Wed, 08 Feb 2006 14:56:56 +1100 Subject: G5 fan problems return moving to 2.6.15 with dual processor 2.7GHz machine In-Reply-To: <17384.62553.442011.514155@zot.electricrain.com> References: <20060205061048.7261.qmail@electricrain.com> <1139130385.5634.14.camel@localhost.localdomain> <17384.62553.442011.514155@zot.electricrain.com> Message-ID: <1139371016.8187.1.camel@localhost.localdomain> On Tue, 2006-02-07 at 11:26 -0800, Brian D. Carlstrom wrote: > Benjamin Herrenschmidt writes: > > Might be something in that prom_init.c fix that broke... it would be > > really nice if you could give a try with the console and find out what > > it is ... Unfortunately, I don't have access to one of these machines > > with the "problem" at the moment... > > Well, I added several prom_printf calls to prom_init.c's > fixup_device_tree routine. I assumed I would spot these scrolling by > during boot before what appears to be the video mode switch. However, I > didn't see anything, but I wasn't sure if it wasn't just going by too > fast. > > I tried using PROM_BUG to halt the output, but that just resulted in > returning to an OpenFirmware prompt, although with a white background > instead of the usual black background when I go their from yaboot with > 'o'. > > I also tried putting a "while (1) ;" after one of my prom_printf, in > case the illegal instruction used by PROM_BUG was causing the output to > be lost, since it was clearing the screen to display the OpenFirmware > prompt. However then I just got a pure white screen. So clearly in both > cases it was running my changed code, but I see no output. > > I tried reviewing some OpenFirmware doc, looking at their talk of > debugging via serial and telnet, but that all seemed to be a dead end, > although I learned much more about the device tree. :) > > Clearly I could theoretically debug by moving the while(1); around to > see what branches are being taken, but since I'm away from the machines > today, I figured I'd ask how I'm expected to use prom_printf, before > returning to debugging tomorrow. Sorry my lack of ppc experience is > showing. prom_printf should work ... try booting manually (from the OF command line) and maybe comment out the code that opens the displays... (it may be clearing the screen).... Ben. From benh at kernel.crashing.org Wed Feb 8 14:59:21 2006 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Wed, 08 Feb 2006 14:59:21 +1100 Subject: [PATCH] fix prom_init undefined error In-Reply-To: <43E928F7.1050307@am.sony.com> References: <43E928F7.1050307@am.sony.com> Message-ID: <1139371162.8187.3.camel@localhost.localdomain> On Tue, 2006-02-07 at 15:10 -0800, Geoff Levand wrote: > Paul, > > This patch fixes a build error when CONFIG_PPC_OF=n, > CONFIG_PPC_MULTIPLATFORM=y. It makes the conditionals > consistent in arch/powerpc/kernel/Makefile and head_64.S > to both be on CONFIG_PPC_OF. > > arch/powerpc/kernel/head_64.o: In function `.__boot_from_prom': > linux/arch/powerpc/kernel/head_64.S:(.text+0x8158): undefined reference to `.prom_init' > > obj-$(CONFIG_PPC_OF) += prom_init.o With ARCH=powerpc, CONFIG_PPC_OF should always be set. It's supposed to be set when the device-tree accessors exist which they always do. Besides, I'll be removing support for !MULTIPLATFORM too :) (Except for iSeries at least for a little while). Look at the patch I posted that removes _machine for an idea of where things are going. Why do you want CONFIG_PPC_OF not set ? Ben. From benh at kernel.crashing.org Wed Feb 8 16:42:51 2006 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Wed, 08 Feb 2006 16:42:51 +1100 Subject: [PATCH] powerpc: Thermal control for dual core G5s Message-ID: <1139377372.8187.16.camel@localhost.localdomain> This patch adds a windfarm module, windfarm_pm112, for the dual core G5s (both 2 and 4 core models), keeping the machine from getting into vacuum-cleaner mode ;) For proper credits, the patch was initially written by Paul Mackerras, and slightly reworked by me to add overtemp handling among others. The patch also removes the sysfs attributes from windfarm_pm81 and windfarm_pm91 and instead adds code to the windfarm core to automagically expose attributes for sensor & controls. Signed-off-by; Benjamin Herrenschmidt Index: linux-work/drivers/macintosh/Kconfig =================================================================== --- linux-work.orig/drivers/macintosh/Kconfig 2006-01-12 16:33:08.000000000 +1100 +++ linux-work/drivers/macintosh/Kconfig 2006-02-07 13:45:57.000000000 +1100 @@ -187,6 +187,14 @@ config WINDFARM_PM91 This driver provides thermal control for the PowerMac9,1 which is the recent (SMU based) single CPU desktop G5 +config WINDFARM_PM112 + tristate "Support for thermal management on PowerMac11,2" + depends on WINDFARM && I2C && PMAC_SMU + select I2C_PMAC_SMU + help + This driver provides thermal control for the PowerMac11,2 + which are the recent dual and quad G5 machines using the + 970MP dual-core processor. config ANSLCD tristate "Support for ANS LCD display" Index: linux-work/drivers/macintosh/Makefile =================================================================== --- linux-work.orig/drivers/macintosh/Makefile 2005-11-09 11:49:03.000000000 +1100 +++ linux-work/drivers/macintosh/Makefile 2006-02-07 13:45:57.000000000 +1100 @@ -35,3 +35,8 @@ obj-$(CONFIG_WINDFARM_PM91) += windf windfarm_smu_sensors.o \ windfarm_lm75_sensor.o windfarm_pid.o \ windfarm_cpufreq_clamp.o windfarm_pm91.o +obj-$(CONFIG_WINDFARM_PM112) += windfarm_pm112.o windfarm_smu_sat.o \ + windfarm_smu_controls.o \ + windfarm_smu_sensors.o \ + windfarm_max6690_sensor.o \ + windfarm_lm75_sensor.o windfarm_pid.o Index: linux-work/drivers/macintosh/windfarm.h =================================================================== --- linux-work.orig/drivers/macintosh/windfarm.h 2005-11-09 11:49:03.000000000 +1100 +++ linux-work/drivers/macintosh/windfarm.h 2006-02-07 13:45:57.000000000 +1100 @@ -14,6 +14,7 @@ #include #include #include +#include /* Display a 16.16 fixed point value */ #define FIX32TOPRINT(f) ((f) >> 16),((((f) & 0xffff) * 1000) >> 16) @@ -39,6 +40,7 @@ struct wf_control { char *name; int type; struct kref ref; + struct device_attribute attr; }; #define WF_CONTROL_TYPE_GENERIC 0 @@ -87,6 +89,7 @@ struct wf_sensor { struct wf_sensor_ops *ops; char *name; struct kref ref; + struct device_attribute attr; }; /* Same lifetime rules as controls */ Index: linux-work/drivers/macintosh/windfarm_core.c =================================================================== --- linux-work.orig/drivers/macintosh/windfarm_core.c 2005-11-09 11:49:03.000000000 +1100 +++ linux-work/drivers/macintosh/windfarm_core.c 2006-02-07 13:45:57.000000000 +1100 @@ -55,6 +55,10 @@ static unsigned int wf_overtemp; static unsigned int wf_overtemp_counter; struct task_struct *wf_thread; +static struct platform_device wf_platform_device = { + .name = "windfarm", +}; + /* * Utilities & tick thread */ @@ -156,6 +160,40 @@ static void wf_control_release(struct kr kfree(ct); } +static ssize_t wf_show_control(struct device *dev, + struct device_attribute *attr, char *buf) +{ + struct wf_control *ctrl = container_of(attr, struct wf_control, attr); + s32 val = 0; + int err; + + err = ctrl->ops->get_value(ctrl, &val); + if (err < 0) + return err; + return sprintf(buf, "%d\n", val); +} + +/* This is really only for debugging... */ +static ssize_t wf_store_control(struct device *dev, + struct device_attribute *attr, + const char *buf, size_t count) +{ + struct wf_control *ctrl = container_of(attr, struct wf_control, attr); + int val; + int err; + char *endp; + + val = simple_strtoul(buf, &endp, 0); + while (endp < buf + count && (*endp == ' ' || *endp == '\n')) + ++endp; + if (endp - buf < count) + return -EINVAL; + err = ctrl->ops->set_value(ctrl, val); + if (err < 0) + return err; + return count; +} + int wf_register_control(struct wf_control *new_ct) { struct wf_control *ct; @@ -172,6 +210,13 @@ int wf_register_control(struct wf_contro kref_init(&new_ct->ref); list_add(&new_ct->link, &wf_controls); + new_ct->attr.attr.name = new_ct->name; + new_ct->attr.attr.owner = THIS_MODULE; + new_ct->attr.attr.mode = 0644; + new_ct->attr.show = wf_show_control; + new_ct->attr.store = wf_store_control; + device_create_file(&wf_platform_device.dev, &new_ct->attr); + DBG("wf: Registered control %s\n", new_ct->name); wf_notify(WF_EVENT_NEW_CONTROL, new_ct); @@ -246,6 +291,19 @@ static void wf_sensor_release(struct kre kfree(sr); } +static ssize_t wf_show_sensor(struct device *dev, + struct device_attribute *attr, char *buf) +{ + struct wf_sensor *sens = container_of(attr, struct wf_sensor, attr); + s32 val = 0; + int err; + + err = sens->ops->get_value(sens, &val); + if (err < 0) + return err; + return sprintf(buf, "%d.%03d\n", FIX32TOPRINT(val)); +} + int wf_register_sensor(struct wf_sensor *new_sr) { struct wf_sensor *sr; @@ -262,6 +320,13 @@ int wf_register_sensor(struct wf_sensor kref_init(&new_sr->ref); list_add(&new_sr->link, &wf_sensors); + new_sr->attr.attr.name = new_sr->name; + new_sr->attr.attr.owner = THIS_MODULE; + new_sr->attr.attr.mode = 0444; + new_sr->attr.show = wf_show_sensor; + new_sr->attr.store = NULL; + device_create_file(&wf_platform_device.dev, &new_sr->attr); + DBG("wf: Registered sensor %s\n", new_sr->name); wf_notify(WF_EVENT_NEW_SENSOR, new_sr); @@ -395,10 +460,6 @@ int wf_is_overtemp(void) } EXPORT_SYMBOL_GPL(wf_is_overtemp); -static struct platform_device wf_platform_device = { - .name = "windfarm", -}; - static int __init windfarm_core_init(void) { DBG("wf: core loaded\n"); Index: linux-work/drivers/macintosh/windfarm_max6690_sensor.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ linux-work/drivers/macintosh/windfarm_max6690_sensor.c 2006-02-07 16:05:23.000000000 +1100 @@ -0,0 +1,169 @@ +/* + * Windfarm PowerMac thermal control. MAX6690 sensor. + * + * Copyright (C) 2005 Paul Mackerras, IBM Corp. + * + * Use and redistribute under the terms of the GNU GPL v2. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "windfarm.h" + +#define VERSION "0.1" + +/* This currently only exports the external temperature sensor, + since that's all the control loops need. */ + +/* Some MAX6690 register numbers */ +#define MAX6690_INTERNAL_TEMP 0 +#define MAX6690_EXTERNAL_TEMP 1 + +struct wf_6690_sensor { + struct i2c_client i2c; + struct wf_sensor sens; +}; + +#define wf_to_6690(x) container_of((x), struct wf_6690_sensor, sens) +#define i2c_to_6690(x) container_of((x), struct wf_6690_sensor, i2c) + +static int wf_max6690_attach(struct i2c_adapter *adapter); +static int wf_max6690_detach(struct i2c_client *client); + +static struct i2c_driver wf_max6690_driver = { + .driver = { + .name = "wf_max6690", + }, + .attach_adapter = wf_max6690_attach, + .detach_client = wf_max6690_detach, +}; + +static int wf_max6690_get(struct wf_sensor *sr, s32 *value) +{ + struct wf_6690_sensor *max = wf_to_6690(sr); + s32 data; + + if (max->i2c.adapter == NULL) + return -ENODEV; + + /* chip gets initialized by firmware */ + data = i2c_smbus_read_byte_data(&max->i2c, MAX6690_EXTERNAL_TEMP); + if (data < 0) + return data; + *value = data << 16; + return 0; +} + +static void wf_max6690_release(struct wf_sensor *sr) +{ + struct wf_6690_sensor *max = wf_to_6690(sr); + + if (max->i2c.adapter) { + i2c_detach_client(&max->i2c); + max->i2c.adapter = NULL; + } + kfree(max); +} + +static struct wf_sensor_ops wf_max6690_ops = { + .get_value = wf_max6690_get, + .release = wf_max6690_release, + .owner = THIS_MODULE, +}; + +static void wf_max6690_create(struct i2c_adapter *adapter, u8 addr) +{ + struct wf_6690_sensor *max; + char *name = "u4-temp"; + + max = kzalloc(sizeof(struct wf_6690_sensor), GFP_KERNEL); + if (max == NULL) { + printk(KERN_ERR "windfarm: Couldn't create MAX6690 sensor %s: " + "no memory\n", name); + return; + } + + max->sens.ops = &wf_max6690_ops; + max->sens.name = name; + max->i2c.addr = addr >> 1; + max->i2c.adapter = adapter; + max->i2c.driver = &wf_max6690_driver; + strncpy(max->i2c.name, name, I2C_NAME_SIZE-1); + + if (i2c_attach_client(&max->i2c)) { + printk(KERN_ERR "windfarm: failed to attach MAX6690 sensor\n"); + goto fail; + } + + if (wf_register_sensor(&max->sens)) { + i2c_detach_client(&max->i2c); + goto fail; + } + + return; + + fail: + kfree(max); +} + +static int wf_max6690_attach(struct i2c_adapter *adapter) +{ + struct device_node *busnode, *dev = NULL; + struct pmac_i2c_bus *bus; + const char *loc; + u32 *reg; + + bus = pmac_i2c_adapter_to_bus(adapter); + if (bus == NULL) + return -ENODEV; + busnode = pmac_i2c_get_bus_node(bus); + + while ((dev = of_get_next_child(busnode, dev)) != NULL) { + if (!device_is_compatible(dev, "max6690")) + continue; + loc = get_property(dev, "hwsensor-location", NULL); + reg = (u32 *) get_property(dev, "reg", NULL); + if (!loc || !reg) + continue; + printk("found max6690, loc=%s reg=%x\n", loc, *reg); + if (strcmp(loc, "BACKSIDE")) + continue; + wf_max6690_create(adapter, *reg); + } + + return 0; +} + +static int wf_max6690_detach(struct i2c_client *client) +{ + struct wf_6690_sensor *max = i2c_to_6690(client); + + max->i2c.adapter = NULL; + wf_unregister_sensor(&max->sens); + + return 0; +} + +static int __init wf_max6690_sensor_init(void) +{ + return i2c_add_driver(&wf_max6690_driver); +} + +static void __exit wf_max6690_sensor_exit(void) +{ + i2c_del_driver(&wf_max6690_driver); +} + +module_init(wf_max6690_sensor_init); +module_exit(wf_max6690_sensor_exit); + +MODULE_AUTHOR("Paul Mackerras "); +MODULE_DESCRIPTION("MAX6690 sensor objects for PowerMac thermal control"); +MODULE_LICENSE("GPL"); Index: linux-work/drivers/macintosh/windfarm_pid.c =================================================================== --- linux-work.orig/drivers/macintosh/windfarm_pid.c 2005-11-09 11:49:03.000000000 +1100 +++ linux-work/drivers/macintosh/windfarm_pid.c 2006-02-07 13:45:57.000000000 +1100 @@ -88,8 +88,8 @@ EXPORT_SYMBOL_GPL(wf_cpu_pid_init); s32 wf_cpu_pid_run(struct wf_cpu_pid_state *st, s32 new_power, s32 new_temp) { - s64 error, integ, deriv, prop; - s32 target, sval, adj; + s64 integ, deriv, prop; + s32 error, target, sval, adj; int i, hlen = st->param.history_len; /* Calculate error term */ @@ -117,7 +117,7 @@ s32 wf_cpu_pid_run(struct wf_cpu_pid_sta integ += st->errors[(st->index + hlen - i) % hlen]; integ *= st->param.interval; integ *= st->param.gr; - sval = st->param.tmax - ((integ >> 20) & 0xffffffff); + sval = st->param.tmax - (s32)(integ >> 20); adj = min(st->param.ttarget, sval); DBG("integ: %lx, sval: %lx, adj: %lx\n", integ, sval, adj); @@ -129,7 +129,7 @@ s32 wf_cpu_pid_run(struct wf_cpu_pid_sta deriv *= st->param.gd; /* Calculate proportional term */ - prop = (new_temp - adj); + prop = st->last_delta = (new_temp - adj); prop *= st->param.gp; DBG("deriv: %lx, prop: %lx\n", deriv, prop); Index: linux-work/drivers/macintosh/windfarm_pid.h =================================================================== --- linux-work.orig/drivers/macintosh/windfarm_pid.h 2005-11-09 11:49:03.000000000 +1100 +++ linux-work/drivers/macintosh/windfarm_pid.h 2006-02-07 13:45:57.000000000 +1100 @@ -72,6 +72,7 @@ struct wf_cpu_pid_state { int index; /* index of current power */ int tindex; /* index of current temp */ s32 target; /* current target value */ + s32 last_delta; /* last Tactual - Ttarget */ s32 powers[WF_PID_MAX_HISTORY]; /* power history buffer */ s32 errors[WF_PID_MAX_HISTORY]; /* error history buffer */ s32 temps[2]; /* temp. history buffer */ Index: linux-work/drivers/macintosh/windfarm_pm112.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ linux-work/drivers/macintosh/windfarm_pm112.c 2006-02-08 16:28:38.000000000 +1100 @@ -0,0 +1,698 @@ +/* + * Windfarm PowerMac thermal control. + * Control loops for machines with SMU and PPC970MP processors. + * + * Copyright (C) 2005 Paul Mackerras, IBM Corp. + * Copyright (C) 2006 Benjamin Herrenschmidt, IBM Corp. + * + * Use and redistribute under the terms of the GNU GPL v2. + */ +#include +#include +#include +#include +#include +#include +#include +#include + +#include "windfarm.h" +#include "windfarm_pid.h" + +#define VERSION "0.2" + +#define DEBUG +#undef LOTSA_DEBUG + +#ifdef DEBUG +#define DBG(args...) printk(args) +#else +#define DBG(args...) do { } while(0) +#endif + +#ifdef LOTSA_DEBUG +#define DBG_LOTS(args...) printk(args) +#else +#define DBG_LOTS(args...) do { } while(0) +#endif + +/* define this to force CPU overtemp to 60 degree, useful for testing + * the overtemp code + */ +#undef HACKED_OVERTEMP + +/* We currently only handle 2 chips, 4 cores... */ +#define NR_CHIPS 2 +#define NR_CORES 4 +#define NR_CPU_FANS 3 * NR_CHIPS + +/* Controls and sensors */ +static struct wf_sensor *sens_cpu_temp[NR_CORES]; +static struct wf_sensor *sens_cpu_power[NR_CORES]; +static struct wf_sensor *hd_temp; +static struct wf_sensor *slots_power; +static struct wf_sensor *u4_temp; + +static struct wf_control *cpu_fans[NR_CPU_FANS]; +static char *cpu_fan_names[NR_CPU_FANS] = { + "cpu-rear-fan-0", + "cpu-rear-fan-1", + "cpu-front-fan-0", + "cpu-front-fan-1", + "cpu-pump-0", + "cpu-pump-1", +}; +static struct wf_control *cpufreq_clamp; + +/* Second pump isn't required (and isn't actually present) */ +#define CPU_FANS_REQD (NR_CPU_FANS - 2) +#define FIRST_PUMP 4 +#define LAST_PUMP 5 + +/* We keep a temperature history for average calculation of 180s */ +#define CPU_TEMP_HIST_SIZE 180 + +/* Scale factor for fan speed, *100 */ +static int cpu_fan_scale[NR_CPU_FANS] = { + 100, + 100, + 97, /* inlet fans run at 97% of exhaust fan */ + 97, + 100, /* updated later */ + 100, /* updated later */ +}; + +static struct wf_control *backside_fan; +static struct wf_control *slots_fan; +static struct wf_control *drive_bay_fan; + +/* PID loop state */ +static struct wf_cpu_pid_state cpu_pid[NR_CORES]; +static u32 cpu_thist[CPU_TEMP_HIST_SIZE]; +static int cpu_thist_pt; +static s64 cpu_thist_total; +static s32 cpu_all_tmax = 100 << 16; +static int cpu_last_target; +static struct wf_pid_state backside_pid; +static int backside_tick; +static struct wf_pid_state slots_pid; +static int slots_started; +static struct wf_pid_state drive_bay_pid; +static int drive_bay_tick; + +static int nr_cores; +static int have_all_controls; +static int have_all_sensors; +static int started; + +static int failure_state; +#define FAILURE_SENSOR 1 +#define FAILURE_FAN 2 +#define FAILURE_PERM 4 +#define FAILURE_LOW_OVERTEMP 8 +#define FAILURE_HIGH_OVERTEMP 16 + +/* Overtemp values */ +#define LOW_OVER_AVERAGE 0 +#define LOW_OVER_IMMEDIATE (10 << 16) +#define LOW_OVER_CLEAR ((-10) << 16) +#define HIGH_OVER_IMMEDIATE (14 << 16) +#define HIGH_OVER_AVERAGE (10 << 16) +#define HIGH_OVER_IMMEDIATE (14 << 16) + + +/* Implementation... */ +static int create_cpu_loop(int cpu) +{ + int chip = cpu / 2; + int core = cpu & 1; + struct smu_sdbp_header *hdr; + struct smu_sdbp_cpupiddata *piddata; + struct wf_cpu_pid_param pid; + struct wf_control *main_fan = cpu_fans[0]; + s32 tmax; + int fmin; + + /* Get PID params from the appropriate SAT */ + hdr = smu_sat_get_sdb_partition(chip, 0xC8 + core, NULL); + if (hdr == NULL) { + printk(KERN_WARNING"windfarm: can't get CPU PID fan config\n"); + return -EINVAL; + } + piddata = (struct smu_sdbp_cpupiddata *)&hdr[1]; + + /* Get FVT params to get Tmax; if not found, assume default */ + hdr = smu_sat_get_sdb_partition(chip, 0xC4 + core, NULL); + if (hdr) { + struct smu_sdbp_fvt *fvt = (struct smu_sdbp_fvt *)&hdr[1]; + tmax = fvt->maxtemp << 16; + } else + tmax = 95 << 16; /* default to 95 degrees C */ + + /* We keep a global tmax for overtemp calculations */ + if (tmax < cpu_all_tmax) + cpu_all_tmax = tmax; + + /* + * Darwin has a minimum fan speed of 1000 rpm for the 4-way and + * 515 for the 2-way. That appears to be overkill, so for now, + * impose a minimum of 750 or 515. + */ + fmin = (nr_cores > 2) ? 750 : 515; + + /* Initialize PID loop */ + pid.interval = 1; /* seconds */ + pid.history_len = piddata->history_len; + pid.gd = piddata->gd; + pid.gp = piddata->gp; + pid.gr = piddata->gr / piddata->history_len; + pid.pmaxadj = (piddata->max_power << 16) - (piddata->power_adj << 8); + pid.ttarget = tmax - (piddata->target_temp_delta << 16); + pid.tmax = tmax; + pid.min = main_fan->ops->get_min(main_fan); + pid.max = main_fan->ops->get_max(main_fan); + if (pid.min < fmin) + pid.min = fmin; + + wf_cpu_pid_init(&cpu_pid[cpu], &pid); + return 0; +} + +static void cpu_max_all_fans(void) +{ + int i; + + /* We max all CPU fans in case of a sensor error. We also do the + * cpufreq clamping now, even if it's supposedly done later by the + * generic code anyway, we do it earlier here to react faster + */ + if (cpufreq_clamp) + wf_control_set_max(cpufreq_clamp); + for (i = 0; i < NR_CPU_FANS; ++i) + if (cpu_fans[i]) + wf_control_set_max(cpu_fans[i]); +} + +static int cpu_check_overtemp(s32 temp) +{ + int new_state = 0; + s32 t_avg, t_old; + + /* First check for immediate overtemps */ + if (temp >= (cpu_all_tmax + LOW_OVER_IMMEDIATE)) { + new_state |= FAILURE_LOW_OVERTEMP; + if ((failure_state & FAILURE_LOW_OVERTEMP) == 0) + printk(KERN_ERR "windfarm: Overtemp due to immediate CPU" + " temperature !\n"); + } + if (temp >= (cpu_all_tmax + HIGH_OVER_IMMEDIATE)) { + new_state |= FAILURE_HIGH_OVERTEMP; + if ((failure_state & FAILURE_HIGH_OVERTEMP) == 0) + printk(KERN_ERR "windfarm: Critical overtemp due to" + " immediate CPU temperature !\n"); + } + + /* We calculate a history of max temperatures and use that for the + * overtemp management + */ + t_old = cpu_thist[cpu_thist_pt]; + cpu_thist[cpu_thist_pt] = temp; + cpu_thist_pt = (cpu_thist_pt + 1) % CPU_TEMP_HIST_SIZE; + cpu_thist_total -= t_old; + cpu_thist_total += temp; + t_avg = cpu_thist_total / CPU_TEMP_HIST_SIZE; + + DBG_LOTS("t_avg = %d.%03d (out: %d.%03d, in: %d.%03d)\n", + FIX32TOPRINT(t_avg), FIX32TOPRINT(t_old), FIX32TOPRINT(temp)); + + /* Now check for average overtemps */ + if (t_avg >= (cpu_all_tmax + LOW_OVER_AVERAGE)) { + new_state |= FAILURE_LOW_OVERTEMP; + if ((failure_state & FAILURE_LOW_OVERTEMP) == 0) + printk(KERN_ERR "windfarm: Overtemp due to average CPU" + " temperature !\n"); + } + if (t_avg >= (cpu_all_tmax + HIGH_OVER_AVERAGE)) { + new_state |= FAILURE_HIGH_OVERTEMP; + if ((failure_state & FAILURE_HIGH_OVERTEMP) == 0) + printk(KERN_ERR "windfarm: Critical overtemp due to" + " average CPU temperature !\n"); + } + + /* Now handle overtemp conditions. We don't currently use the windfarm + * overtemp handling core as it's not fully suited to the needs of those + * new machine. This will be fixed later. + */ + if (new_state) { + /* High overtemp -> immediate shutdown */ + if (new_state & FAILURE_HIGH_OVERTEMP) + machine_power_off(); + if ((failure_state & new_state) != new_state) + cpu_max_all_fans(); + failure_state |= new_state; + } else if ((failure_state & FAILURE_LOW_OVERTEMP) && + (temp < (cpu_all_tmax + LOW_OVER_CLEAR))) { + printk(KERN_ERR "windfarm: Overtemp condition cleared !\n"); + failure_state &= ~FAILURE_LOW_OVERTEMP; + } + + return failure_state & (FAILURE_LOW_OVERTEMP | FAILURE_HIGH_OVERTEMP); +} + +static void cpu_fans_tick(void) +{ + int err, cpu; + s32 greatest_delta = 0; + s32 temp, power, t_max = 0; + int i, t, target = 0; + struct wf_sensor *sr; + struct wf_control *ct; + struct wf_cpu_pid_state *sp; + + DBG_LOTS(KERN_DEBUG); + for (cpu = 0; cpu < nr_cores; ++cpu) { + /* Get CPU core temperature */ + sr = sens_cpu_temp[cpu]; + err = sr->ops->get_value(sr, &temp); + if (err) { + DBG("\n"); + printk(KERN_WARNING "windfarm: CPU %d temperature " + "sensor error %d\n", cpu, err); + failure_state |= FAILURE_SENSOR; + cpu_max_all_fans(); + return; + } + + /* Keep track of highest temp */ + t_max = max(t_max, temp); + + /* Get CPU power */ + sr = sens_cpu_power[cpu]; + err = sr->ops->get_value(sr, &power); + if (err) { + DBG("\n"); + printk(KERN_WARNING "windfarm: CPU %d power " + "sensor error %d\n", cpu, err); + failure_state |= FAILURE_SENSOR; + cpu_max_all_fans(); + return; + } + + /* Run PID */ + sp = &cpu_pid[cpu]; + t = wf_cpu_pid_run(sp, power, temp); + + if (cpu == 0 || sp->last_delta > greatest_delta) { + greatest_delta = sp->last_delta; + target = t; + } + DBG_LOTS("[%d] P=%d.%.3d T=%d.%.3d ", + cpu, FIX32TOPRINT(power), FIX32TOPRINT(temp)); + } + DBG_LOTS("fans = %d, t_max = %d.%03d\n", target, FIX32TOPRINT(t_max)); + + /* Darwin limits decrease to 20 per iteration */ + if (target < (cpu_last_target - 20)) + target = cpu_last_target - 20; + cpu_last_target = target; + for (cpu = 0; cpu < nr_cores; ++cpu) + cpu_pid[cpu].target = target; + + /* Handle possible overtemps */ + if (cpu_check_overtemp(t_max)) + return; + + /* Set fans */ + for (i = 0; i < NR_CPU_FANS; ++i) { + ct = cpu_fans[i]; + if (ct == NULL) + continue; + err = ct->ops->set_value(ct, target * cpu_fan_scale[i] / 100); + if (err) { + printk(KERN_WARNING "windfarm: fan %s reports " + "error %d\n", ct->name, err); + failure_state |= FAILURE_FAN; + break; + } + } +} + +/* Backside/U4 fan */ +static struct wf_pid_param backside_param = { + .interval = 5, + .history_len = 2, + .gd = 48 << 20, + .gp = 5 << 20, + .gr = 0, + .itarget = 64 << 16, + .additive = 1, +}; + +static void backside_fan_tick(void) +{ + s32 temp; + int speed; + int err; + + if (!backside_fan || !u4_temp) + return; + if (!backside_tick) { + /* first time; initialize things */ + backside_param.min = backside_fan->ops->get_min(backside_fan); + backside_param.max = backside_fan->ops->get_max(backside_fan); + wf_pid_init(&backside_pid, &backside_param); + backside_tick = 1; + } + if (--backside_tick > 0) + return; + backside_tick = backside_pid.param.interval; + + err = u4_temp->ops->get_value(u4_temp, &temp); + if (err) { + printk(KERN_WARNING "windfarm: U4 temp sensor error %d\n", + err); + failure_state |= FAILURE_SENSOR; + wf_control_set_max(backside_fan); + return; + } + speed = wf_pid_run(&backside_pid, temp); + DBG_LOTS("backside PID temp=%d.%.3d speed=%d\n", + FIX32TOPRINT(temp), speed); + + err = backside_fan->ops->set_value(backside_fan, speed); + if (err) { + printk(KERN_WARNING "windfarm: backside fan error %d\n", err); + failure_state |= FAILURE_FAN; + } +} + +/* Drive bay fan */ +static struct wf_pid_param drive_bay_prm = { + .interval = 5, + .history_len = 2, + .gd = 30 << 20, + .gp = 5 << 20, + .gr = 0, + .itarget = 40 << 16, + .additive = 1, +}; + +static void drive_bay_fan_tick(void) +{ + s32 temp; + int speed; + int err; + + if (!drive_bay_fan || !hd_temp) + return; + if (!drive_bay_tick) { + /* first time; initialize things */ + drive_bay_prm.min = drive_bay_fan->ops->get_min(drive_bay_fan); + drive_bay_prm.max = drive_bay_fan->ops->get_max(drive_bay_fan); + wf_pid_init(&drive_bay_pid, &drive_bay_prm); + drive_bay_tick = 1; + } + if (--drive_bay_tick > 0) + return; + drive_bay_tick = drive_bay_pid.param.interval; + + err = hd_temp->ops->get_value(hd_temp, &temp); + if (err) { + printk(KERN_WARNING "windfarm: drive bay temp sensor " + "error %d\n", err); + failure_state |= FAILURE_SENSOR; + wf_control_set_max(drive_bay_fan); + return; + } + speed = wf_pid_run(&drive_bay_pid, temp); + DBG_LOTS("drive_bay PID temp=%d.%.3d speed=%d\n", + FIX32TOPRINT(temp), speed); + + err = drive_bay_fan->ops->set_value(drive_bay_fan, speed); + if (err) { + printk(KERN_WARNING "windfarm: drive bay fan error %d\n", err); + failure_state |= FAILURE_FAN; + } +} + +/* PCI slots area fan */ +/* This makes the fan speed proportional to the power consumed */ +static struct wf_pid_param slots_param = { + .interval = 1, + .history_len = 2, + .gd = 0, + .gp = 0, + .gr = 0x1277952, + .itarget = 0, + .min = 1560, + .max = 3510, +}; + +static void slots_fan_tick(void) +{ + s32 power; + int speed; + int err; + + if (!slots_fan || !slots_power) + return; + if (!slots_started) { + /* first time; initialize things */ + wf_pid_init(&slots_pid, &slots_param); + slots_started = 1; + } + + err = slots_power->ops->get_value(slots_power, &power); + if (err) { + printk(KERN_WARNING "windfarm: slots power sensor error %d\n", + err); + failure_state |= FAILURE_SENSOR; + wf_control_set_max(slots_fan); + return; + } + speed = wf_pid_run(&slots_pid, power); + DBG_LOTS("slots PID power=%d.%.3d speed=%d\n", + FIX32TOPRINT(power), speed); + + err = slots_fan->ops->set_value(slots_fan, speed); + if (err) { + printk(KERN_WARNING "windfarm: slots fan error %d\n", err); + failure_state |= FAILURE_FAN; + } +} + +static void set_fail_state(void) +{ + int i; + + if (cpufreq_clamp) + wf_control_set_max(cpufreq_clamp); + for (i = 0; i < NR_CPU_FANS; ++i) + if (cpu_fans[i]) + wf_control_set_max(cpu_fans[i]); + if (backside_fan) + wf_control_set_max(backside_fan); + if (slots_fan) + wf_control_set_max(slots_fan); + if (drive_bay_fan) + wf_control_set_max(drive_bay_fan); +} + +static void pm112_tick(void) +{ + int i, last_failure; + + if (!started) { + started = 1; + for (i = 0; i < nr_cores; ++i) { + if (create_cpu_loop(i) < 0) { + failure_state = FAILURE_PERM; + set_fail_state(); + break; + } + } + DBG_LOTS("cpu_all_tmax=%d.%03d\n", FIX32TOPRINT(cpu_all_tmax)); + +#ifdef HACKED_OVERTEMP + cpu_all_tmax = 60 << 16; +#endif + } + + /* Permanent failure, bail out */ + if (failure_state & FAILURE_PERM) + return; + /* Clear all failure bits except low overtemp which will be eventually + * cleared by the control loop itself + */ + last_failure = failure_state; + failure_state &= FAILURE_LOW_OVERTEMP; + cpu_fans_tick(); + backside_fan_tick(); + slots_fan_tick(); + drive_bay_fan_tick(); + + DBG_LOTS("last_failure: 0x%x, failure_state: %x\n", + last_failure, failure_state); + + /* Check for failures. Any failure causes cpufreq clamping */ + if (failure_state && last_failure == 0 && cpufreq_clamp) + wf_control_set_max(cpufreq_clamp); + if (failure_state == 0 && last_failure && cpufreq_clamp) + wf_control_set_min(cpufreq_clamp); + + /* That's it for now, we might want to deal with other failures + * differently in the future though + */ +} + +static void pm112_new_control(struct wf_control *ct) +{ + int i, max_exhaust; + + if (cpufreq_clamp == NULL && !strcmp(ct->name, "cpufreq-clamp")) { + if (wf_get_control(ct) == 0) + cpufreq_clamp = ct; + } + + for (i = 0; i < NR_CPU_FANS; ++i) { + if (!strcmp(ct->name, cpu_fan_names[i])) { + if (cpu_fans[i] == NULL && wf_get_control(ct) == 0) + cpu_fans[i] = ct; + break; + } + } + if (i >= NR_CPU_FANS) { + /* not a CPU fan, try the others */ + if (!strcmp(ct->name, "backside-fan")) { + if (backside_fan == NULL && wf_get_control(ct) == 0) + backside_fan = ct; + } else if (!strcmp(ct->name, "slots-fan")) { + if (slots_fan == NULL && wf_get_control(ct) == 0) + slots_fan = ct; + } else if (!strcmp(ct->name, "drive-bay-fan")) { + if (drive_bay_fan == NULL && wf_get_control(ct) == 0) + drive_bay_fan = ct; + } + return; + } + + for (i = 0; i < CPU_FANS_REQD; ++i) + if (cpu_fans[i] == NULL) + return; + + /* work out pump scaling factors */ + max_exhaust = cpu_fans[0]->ops->get_max(cpu_fans[0]); + for (i = FIRST_PUMP; i <= LAST_PUMP; ++i) + if ((ct = cpu_fans[i]) != NULL) + cpu_fan_scale[i] = + ct->ops->get_max(ct) * 100 / max_exhaust; + + have_all_controls = 1; +} + +static void pm112_new_sensor(struct wf_sensor *sr) +{ + unsigned int i; + + if (have_all_sensors) + return; + if (!strncmp(sr->name, "cpu-temp-", 9)) { + i = sr->name[9] - '0'; + if (sr->name[10] == 0 && i < NR_CORES && + sens_cpu_temp[i] == NULL && wf_get_sensor(sr) == 0) + sens_cpu_temp[i] = sr; + + } else if (!strncmp(sr->name, "cpu-power-", 10)) { + i = sr->name[10] - '0'; + if (sr->name[11] == 0 && i < NR_CORES && + sens_cpu_power[i] == NULL && wf_get_sensor(sr) == 0) + sens_cpu_power[i] = sr; + } else if (!strcmp(sr->name, "hd-temp")) { + if (hd_temp == NULL && wf_get_sensor(sr) == 0) + hd_temp = sr; + } else if (!strcmp(sr->name, "slots-power")) { + if (slots_power == NULL && wf_get_sensor(sr) == 0) + slots_power = sr; + } else if (!strcmp(sr->name, "u4-temp")) { + if (u4_temp == NULL && wf_get_sensor(sr) == 0) + u4_temp = sr; + } else + return; + + /* check if we have all the sensors we need */ + for (i = 0; i < nr_cores; ++i) + if (sens_cpu_temp[i] == NULL || sens_cpu_power[i] == NULL) + return; + + have_all_sensors = 1; +} + +static int pm112_wf_notify(struct notifier_block *self, + unsigned long event, void *data) +{ + switch (event) { + case WF_EVENT_NEW_SENSOR: + pm112_new_sensor(data); + break; + case WF_EVENT_NEW_CONTROL: + pm112_new_control(data); + break; + case WF_EVENT_TICK: + if (have_all_controls && have_all_sensors) + pm112_tick(); + } + return 0; +} + +static struct notifier_block pm112_events = { + .notifier_call = pm112_wf_notify, +}; + +static int wf_pm112_probe(struct device *dev) +{ + wf_register_client(&pm112_events); + return 0; +} + +static int wf_pm112_remove(struct device *dev) +{ + wf_unregister_client(&pm112_events); + /* should release all sensors and controls */ + return 0; +} + +static struct device_driver wf_pm112_driver = { + .name = "windfarm", + .bus = &platform_bus_type, + .probe = wf_pm112_probe, + .remove = wf_pm112_remove, +}; + +static int __init wf_pm112_init(void) +{ + struct device_node *cpu; + + if (!machine_is_compatible("PowerMac11,2")) + return -ENODEV; + + /* Count the number of CPU cores */ + nr_cores = 0; + for (cpu = NULL; (cpu = of_find_node_by_type(cpu, "cpu")) != NULL; ) + ++nr_cores; + + printk(KERN_INFO "windfarm: initializing for dual-core desktop G5\n"); + driver_register(&wf_pm112_driver); + return 0; +} + +static void __exit wf_pm112_exit(void) +{ + driver_unregister(&wf_pm112_driver); +} + +module_init(wf_pm112_init); +module_exit(wf_pm112_exit); + +MODULE_AUTHOR("Paul Mackerras "); +MODULE_DESCRIPTION("Thermal control for PowerMac11,2"); +MODULE_LICENSE("GPL"); Index: linux-work/drivers/macintosh/windfarm_smu_controls.c =================================================================== --- linux-work.orig/drivers/macintosh/windfarm_smu_controls.c 2006-01-12 16:33:08.000000000 +1100 +++ linux-work/drivers/macintosh/windfarm_smu_controls.c 2006-02-07 13:45:57.000000000 +1100 @@ -24,7 +24,7 @@ #include "windfarm.h" -#define VERSION "0.3" +#define VERSION "0.4" #undef DEBUG @@ -34,6 +34,8 @@ #define DBG(args...) do { } while(0) #endif +static int smu_supports_new_fans_ops = 1; + /* * SMU fans control object */ @@ -59,23 +61,49 @@ static int smu_set_fan(int pwm, u8 id, u /* Fill SMU command structure */ cmd.cmd = SMU_CMD_FAN_COMMAND; - cmd.data_len = 14; + + /* The SMU has an "old" and a "new" way of setting the fan speed + * Unfortunately, I found no reliable way to know which one works + * on a given machine model. After some investigations it appears + * that MacOS X just tries the new one, and if it fails fallbacks + * to the old ones ... Ugh. + */ + retry: + if (smu_supports_new_fans_ops) { + buffer[0] = 0x30; + buffer[1] = id; + *((u16 *)(&buffer[2])) = value; + cmd.data_len = 4; + } else { + if (id > 7) + return -EINVAL; + /* Fill argument buffer */ + memset(buffer, 0, 16); + buffer[0] = pwm ? 0x10 : 0x00; + buffer[1] = 0x01 << id; + *((u16 *)&buffer[2 + id * 2]) = value; + cmd.data_len = 14; + } + cmd.reply_len = 16; cmd.data_buf = cmd.reply_buf = buffer; cmd.status = 0; cmd.done = smu_done_complete; cmd.misc = ∁ - /* Fill argument buffer */ - memset(buffer, 0, 16); - buffer[0] = pwm ? 0x10 : 0x00; - buffer[1] = 0x01 << id; - *((u16 *)&buffer[2 + id * 2]) = value; - rc = smu_queue_cmd(&cmd); if (rc) return rc; wait_for_completion(&comp); + + /* Handle fallback (see coment above) */ + if (cmd.status != 0 && smu_supports_new_fans_ops) { + printk(KERN_WARNING "windfarm: SMU failed new fan command " + "falling back to old method\n"); + smu_supports_new_fans_ops = 0; + goto retry; + } + return cmd.status; } @@ -158,19 +186,29 @@ static struct smu_fan_control *smu_fan_c /* Names used on desktop models */ if (!strcmp(l, "Rear Fan 0") || !strcmp(l, "Rear Fan") || - !strcmp(l, "Rear fan 0") || !strcmp(l, "Rear fan")) + !strcmp(l, "Rear fan 0") || !strcmp(l, "Rear fan") || + !strcmp(l, "CPU A EXHAUST")) fct->ctrl.name = "cpu-rear-fan-0"; - else if (!strcmp(l, "Rear Fan 1") || !strcmp(l, "Rear fan 1")) + else if (!strcmp(l, "Rear Fan 1") || !strcmp(l, "Rear fan 1") || + !strcmp(l, "CPU B EXHAUST")) fct->ctrl.name = "cpu-rear-fan-1"; else if (!strcmp(l, "Front Fan 0") || !strcmp(l, "Front Fan") || - !strcmp(l, "Front fan 0") || !strcmp(l, "Front fan")) + !strcmp(l, "Front fan 0") || !strcmp(l, "Front fan") || + !strcmp(l, "CPU A INTAKE")) fct->ctrl.name = "cpu-front-fan-0"; - else if (!strcmp(l, "Front Fan 1") || !strcmp(l, "Front fan 1")) + else if (!strcmp(l, "Front Fan 1") || !strcmp(l, "Front fan 1") || + !strcmp(l, "CPU B INTAKE")) fct->ctrl.name = "cpu-front-fan-1"; - else if (!strcmp(l, "Slots Fan") || !strcmp(l, "Slots fan")) + else if (!strcmp(l, "CPU A PUMP")) + fct->ctrl.name = "cpu-pump-0"; + else if (!strcmp(l, "Slots Fan") || !strcmp(l, "Slots fan") || + !strcmp(l, "EXPANSION SLOTS INTAKE")) fct->ctrl.name = "slots-fan"; - else if (!strcmp(l, "Drive Bay") || !strcmp(l, "Drive bay")) + else if (!strcmp(l, "Drive Bay") || !strcmp(l, "Drive bay") || + !strcmp(l, "DRIVE BAY A INTAKE")) fct->ctrl.name = "drive-bay-fan"; + else if (!strcmp(l, "BACKSIDE")) + fct->ctrl.name = "backside-fan"; /* Names used on iMac models */ if (!strcmp(l, "System Fan") || !strcmp(l, "System fan")) @@ -223,7 +261,8 @@ static int __init smu_controls_init(void /* Look for RPM fans */ for (fans = NULL; (fans = of_get_next_child(smu, fans)) != NULL;) - if (!strcmp(fans->name, "rpm-fans")) + if (!strcmp(fans->name, "rpm-fans") || + device_is_compatible(fans, "smu-rpm-fans")) break; for (fan = NULL; fans && (fan = of_get_next_child(fans, fan)) != NULL;) { Index: linux-work/drivers/macintosh/windfarm_smu_sensors.c =================================================================== --- linux-work.orig/drivers/macintosh/windfarm_smu_sensors.c 2006-01-12 16:33:08.000000000 +1100 +++ linux-work/drivers/macintosh/windfarm_smu_sensors.c 2006-02-07 13:45:57.000000000 +1100 @@ -220,14 +220,29 @@ static struct smu_ad_sensor *smu_ads_cre !strcmp(l, "CPU T-Diode")) { ads->sens.ops = &smu_cputemp_ops; ads->sens.name = "cpu-temp"; + if (cpudiode == NULL) { + DBG("wf: cpudiode partition (%02x) not found\n", + SMU_SDB_CPUDIODE_ID); + goto fail; + } } else if (!strcmp(c, "current-sensor") && !strcmp(l, "CPU Current")) { ads->sens.ops = &smu_cpuamp_ops; ads->sens.name = "cpu-current"; + if (cpuvcp == NULL) { + DBG("wf: cpuvcp partition (%02x) not found\n", + SMU_SDB_CPUVCP_ID); + goto fail; + } } else if (!strcmp(c, "voltage-sensor") && !strcmp(l, "CPU Voltage")) { ads->sens.ops = &smu_cpuvolt_ops; ads->sens.name = "cpu-voltage"; + if (cpuvcp == NULL) { + DBG("wf: cpuvcp partition (%02x) not found\n", + SMU_SDB_CPUVCP_ID); + goto fail; + } } else if (!strcmp(c, "power-sensor") && !strcmp(l, "Slots Power")) { ads->sens.ops = &smu_slotspow_ops; @@ -365,29 +380,22 @@ smu_cpu_power_create(struct wf_sensor *v return NULL; } -static int smu_fetch_param_partitions(void) +static void smu_fetch_param_partitions(void) { struct smu_sdbp_header *hdr; /* Get CPU voltage/current/power calibration data */ hdr = smu_get_sdb_partition(SMU_SDB_CPUVCP_ID, NULL); - if (hdr == NULL) { - DBG("wf: cpuvcp partition (%02x) not found\n", - SMU_SDB_CPUVCP_ID); - return -ENODEV; + if (hdr != NULL) { + cpuvcp = (struct smu_sdbp_cpuvcp *)&hdr[1]; + /* Keep version around */ + cpuvcp_version = hdr->version; } - cpuvcp = (struct smu_sdbp_cpuvcp *)&hdr[1]; - /* Keep version around */ - cpuvcp_version = hdr->version; /* Get CPU diode calibration data */ hdr = smu_get_sdb_partition(SMU_SDB_CPUDIODE_ID, NULL); - if (hdr == NULL) { - DBG("wf: cpudiode partition (%02x) not found\n", - SMU_SDB_CPUDIODE_ID); - return -ENODEV; - } - cpudiode = (struct smu_sdbp_cpudiode *)&hdr[1]; + if (hdr != NULL) + cpudiode = (struct smu_sdbp_cpudiode *)&hdr[1]; /* Get slots power calibration data if any */ hdr = smu_get_sdb_partition(SMU_SDB_SLOTSPOW_ID, NULL); @@ -398,23 +406,18 @@ static int smu_fetch_param_partitions(vo hdr = smu_get_sdb_partition(SMU_SDB_DEBUG_SWITCHES_ID, NULL); if (hdr != NULL) debugswitches = (u8 *)&hdr[1]; - - return 0; } static int __init smu_sensors_init(void) { struct device_node *smu, *sensors, *s; struct smu_ad_sensor *volt_sensor = NULL, *curr_sensor = NULL; - int rc; if (!smu_present()) return -ENODEV; /* Get parameters partitions */ - rc = smu_fetch_param_partitions(); - if (rc) - return rc; + smu_fetch_param_partitions(); smu = of_find_node_by_type(NULL, "smu"); if (smu == NULL) Index: linux-work/drivers/macintosh/windfarm_smu_sat.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ linux-work/drivers/macintosh/windfarm_smu_sat.c 2006-02-07 16:18:32.000000000 +1100 @@ -0,0 +1,418 @@ +/* + * Windfarm PowerMac thermal control. SMU "satellite" controller sensors. + * + * Copyright (C) 2005 Paul Mackerras, IBM Corp. + * + * Released under the terms of the GNU GPL v2. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "windfarm.h" + +#define VERSION "0.2" + +#define DEBUG + +#ifdef DEBUG +#define DBG(args...) printk(args) +#else +#define DBG(args...) do { } while(0) +#endif + +/* If the cache is older than 800ms we'll refetch it */ +#define MAX_AGE msecs_to_jiffies(800) + +struct wf_sat { + int nr; + atomic_t refcnt; + struct semaphore mutex; + unsigned long last_read; /* jiffies when cache last updated */ + u8 cache[16]; + struct i2c_client i2c; + struct device_node *node; +}; + +static struct wf_sat *sats[2]; + +struct wf_sat_sensor { + int index; + int index2; /* used for power sensors */ + int shift; + struct wf_sat *sat; + struct wf_sensor sens; +}; + +#define wf_to_sat(c) container_of(c, struct wf_sat_sensor, sens) +#define i2c_to_sat(c) container_of(c, struct wf_sat, i2c) + +static int wf_sat_attach(struct i2c_adapter *adapter); +static int wf_sat_detach(struct i2c_client *client); + +static struct i2c_driver wf_sat_driver = { + .driver = { + .name = "wf_smu_sat", + }, + .attach_adapter = wf_sat_attach, + .detach_client = wf_sat_detach, +}; + +/* + * XXX i2c_smbus_read_i2c_block_data doesn't pass the requested + * length down to the low-level driver, so we use this, which + * works well enough with the SMU i2c driver code... + */ +static int sat_read_block(struct i2c_client *client, u8 command, + u8 *values, int len) +{ + union i2c_smbus_data data; + int err; + + data.block[0] = len; + err = i2c_smbus_xfer(client->adapter, client->addr, client->flags, + I2C_SMBUS_READ, command, I2C_SMBUS_I2C_BLOCK_DATA, + &data); + if (!err) + memcpy(values, data.block, len); + return err; +} + +struct smu_sdbp_header *smu_sat_get_sdb_partition(unsigned int sat_id, int id, + unsigned int *size) +{ + struct wf_sat *sat; + int err; + unsigned int i, len; + u8 *buf; + u8 data[4]; + + /* TODO: Add the resulting partition to the device-tree */ + + if (sat_id > 1 || (sat = sats[sat_id]) == NULL) + return NULL; + + err = i2c_smbus_write_word_data(&sat->i2c, 8, id << 8); + if (err) { + printk(KERN_ERR "smu_sat_get_sdb_part wr error %d\n", err); + return NULL; + } + + len = i2c_smbus_read_word_data(&sat->i2c, 9); + if (len < 0) { + printk(KERN_ERR "smu_sat_get_sdb_part rd len error\n"); + return NULL; + } + if (len == 0) { + printk(KERN_ERR "smu_sat_get_sdb_part no partition %x\n", id); + return NULL; + } + + len = le16_to_cpu(len); + len = (len + 3) & ~3; + buf = kmalloc(len, GFP_KERNEL); + if (buf == NULL) + return NULL; + + for (i = 0; i < len; i += 4) { + err = sat_read_block(&sat->i2c, 0xa, data, 4); + if (err) { + printk(KERN_ERR "smu_sat_get_sdb_part rd err %d\n", + err); + goto fail; + } + buf[i] = data[1]; + buf[i+1] = data[0]; + buf[i+2] = data[3]; + buf[i+3] = data[2]; + } +#ifdef DEBUG + DBG(KERN_DEBUG "sat %d partition %x:", sat_id, id); + for (i = 0; i < len; ++i) + DBG(" %x", buf[i]); + DBG("\n"); +#endif + + if (size) + *size = len; + return (struct smu_sdbp_header *) buf; + + fail: + kfree(buf); + return NULL; +} + +/* refresh the cache */ +static int wf_sat_read_cache(struct wf_sat *sat) +{ + int err; + + err = sat_read_block(&sat->i2c, 0x3f, sat->cache, 16); + if (err) + return err; + sat->last_read = jiffies; +#ifdef LOTSA_DEBUG + { + int i; + DBG(KERN_DEBUG "wf_sat_get: data is"); + for (i = 0; i < 16; ++i) + DBG(" %.2x", sat->cache[i]); + DBG("\n"); + } +#endif + return 0; +} + +static int wf_sat_get(struct wf_sensor *sr, s32 *value) +{ + struct wf_sat_sensor *sens = wf_to_sat(sr); + struct wf_sat *sat = sens->sat; + int i, err; + s32 val; + + if (sat->i2c.adapter == NULL) + return -ENODEV; + + down(&sat->mutex); + if (time_after(jiffies, (sat->last_read + MAX_AGE))) { + err = wf_sat_read_cache(sat); + if (err) + goto fail; + } + + i = sens->index * 2; + val = ((sat->cache[i] << 8) + sat->cache[i+1]) << sens->shift; + if (sens->index2 >= 0) { + i = sens->index2 * 2; + /* 4.12 * 8.8 -> 12.20; shift right 4 to get 16.16 */ + val = (val * ((sat->cache[i] << 8) + sat->cache[i+1])) >> 4; + } + + *value = val; + err = 0; + + fail: + up(&sat->mutex); + return err; +} + +static void wf_sat_release(struct wf_sensor *sr) +{ + struct wf_sat_sensor *sens = wf_to_sat(sr); + struct wf_sat *sat = sens->sat; + + if (atomic_dec_and_test(&sat->refcnt)) { + if (sat->i2c.adapter) { + i2c_detach_client(&sat->i2c); + sat->i2c.adapter = NULL; + } + if (sat->nr >= 0) + sats[sat->nr] = NULL; + kfree(sat); + } + kfree(sens); +} + +static struct wf_sensor_ops wf_sat_ops = { + .get_value = wf_sat_get, + .release = wf_sat_release, + .owner = THIS_MODULE, +}; + +static void wf_sat_create(struct i2c_adapter *adapter, struct device_node *dev) +{ + struct wf_sat *sat; + struct wf_sat_sensor *sens; + u32 *reg; + char *loc, *type; + u8 addr, chip, core; + struct device_node *child; + int shift, cpu, index; + char *name; + int vsens[2], isens[2]; + + reg = (u32 *) get_property(dev, "reg", NULL); + if (reg == NULL) + return; + addr = *reg; + DBG(KERN_DEBUG "wf_sat: creating sat at address %x\n", addr); + + sat = kzalloc(sizeof(struct wf_sat), GFP_KERNEL); + if (sat == NULL) + return; + sat->nr = -1; + sat->node = of_node_get(dev); + atomic_set(&sat->refcnt, 0); + init_MUTEX(&sat->mutex); + sat->i2c.addr = (addr >> 1) & 0x7f; + sat->i2c.adapter = adapter; + sat->i2c.driver = &wf_sat_driver; + strncpy(sat->i2c.name, "smu-sat", I2C_NAME_SIZE-1); + + if (i2c_attach_client(&sat->i2c)) { + printk(KERN_ERR "windfarm: failed to attach smu-sat to i2c\n"); + goto fail; + } + + vsens[0] = vsens[1] = -1; + isens[0] = isens[1] = -1; + child = NULL; + while ((child = of_get_next_child(dev, child)) != NULL) { + reg = (u32 *) get_property(child, "reg", NULL); + type = get_property(child, "device_type", NULL); + loc = get_property(child, "location", NULL); + if (reg == NULL || loc == NULL) + continue; + + /* the cooked sensors are between 0x30 and 0x37 */ + if (*reg < 0x30 || *reg > 0x37) + continue; + index = *reg - 0x30; + + /* expect location to be CPU [AB][01] ... */ + if (strncmp(loc, "CPU ", 4) != 0) + continue; + chip = loc[4] - 'A'; + core = loc[5] - '0'; + if (chip > 1 || core > 1) { + printk(KERN_ERR "wf_sat_create: don't understand " + "location %s for %s\n", loc, child->full_name); + continue; + } + cpu = 2 * chip + core; + if (sat->nr < 0) + sat->nr = chip; + else if (sat->nr != chip) { + printk(KERN_ERR "wf_sat_create: can't cope with " + "multiple CPU chips on one SAT (%s)\n", loc); + continue; + } + + if (strcmp(type, "voltage-sensor") == 0) { + name = "cpu-voltage"; + shift = 4; + vsens[core] = index; + } else if (strcmp(type, "current-sensor") == 0) { + name = "cpu-current"; + shift = 8; + isens[core] = index; + } else if (strcmp(type, "temp-sensor") == 0) { + name = "cpu-temp"; + shift = 10; + } else + continue; /* hmmm shouldn't happen */ + + /* the +16 is enough for "cpu-voltage-n" */ + sens = kzalloc(sizeof(struct wf_sat_sensor) + 16, GFP_KERNEL); + if (sens == NULL) { + printk(KERN_ERR "wf_sat_create: couldn't create " + "%s sensor %d (no memory)\n", name, cpu); + continue; + } + sens->index = index; + sens->index2 = -1; + sens->shift = shift; + sens->sat = sat; + atomic_inc(&sat->refcnt); + sens->sens.ops = &wf_sat_ops; + sens->sens.name = (char *) (sens + 1); + snprintf(sens->sens.name, 16, "%s-%d", name, cpu); + + if (wf_register_sensor(&sens->sens)) { + atomic_dec(&sat->refcnt); + kfree(sens); + } + } + + /* make the power sensors */ + for (core = 0; core < 2; ++core) { + if (vsens[core] < 0 || isens[core] < 0) + continue; + cpu = 2 * sat->nr + core; + sens = kzalloc(sizeof(struct wf_sat_sensor) + 16, GFP_KERNEL); + if (sens == NULL) { + printk(KERN_ERR "wf_sat_create: couldn't create power " + "sensor %d (no memory)\n", cpu); + continue; + } + sens->index = vsens[core]; + sens->index2 = isens[core]; + sens->shift = 0; + sens->sat = sat; + atomic_inc(&sat->refcnt); + sens->sens.ops = &wf_sat_ops; + sens->sens.name = (char *) (sens + 1); + snprintf(sens->sens.name, 16, "cpu-power-%d", cpu); + + if (wf_register_sensor(&sens->sens)) { + atomic_dec(&sat->refcnt); + kfree(sens); + } + } + + if (sat->nr >= 0) + sats[sat->nr] = sat; + + return; + + fail: + kfree(sat); +} + +static int wf_sat_attach(struct i2c_adapter *adapter) +{ + struct device_node *busnode, *dev = NULL; + struct pmac_i2c_bus *bus; + + bus = pmac_i2c_adapter_to_bus(adapter); + if (bus == NULL) + return -ENODEV; + busnode = pmac_i2c_get_bus_node(bus); + + while ((dev = of_get_next_child(busnode, dev)) != NULL) + if (device_is_compatible(dev, "smu-sat")) + wf_sat_create(adapter, dev); + return 0; +} + +static int wf_sat_detach(struct i2c_client *client) +{ + struct wf_sat *sat = i2c_to_sat(client); + + /* XXX TODO */ + + sat->i2c.adapter = NULL; + return 0; +} + +static int __init sat_sensors_init(void) +{ + int err; + + err = i2c_add_driver(&wf_sat_driver); + if (err < 0) + return err; + return 0; +} + +static void __exit sat_sensors_exit(void) +{ + i2c_del_driver(&wf_sat_driver); +} + +module_init(sat_sensors_init); +/*module_exit(sat_sensors_exit); Uncomment when cleanup is implemented */ + +MODULE_AUTHOR("Paul Mackerras "); +MODULE_DESCRIPTION("SMU satellite sensors for PowerMac thermal control"); +MODULE_LICENSE("GPL"); Index: linux-work/include/asm-powerpc/smu.h =================================================================== --- linux-work.orig/include/asm-powerpc/smu.h 2006-01-13 16:55:09.000000000 +1100 +++ linux-work/include/asm-powerpc/smu.h 2006-02-07 13:45:57.000000000 +1100 @@ -521,6 +521,11 @@ struct smu_sdbp_cpupiddata { extern struct smu_sdbp_header *smu_get_sdb_partition(int id, unsigned int *size); +/* Get "sdb" partition data from an SMU satellite */ +extern struct smu_sdbp_header *smu_sat_get_sdb_partition(unsigned int sat_id, + int id, unsigned int *size); + + #endif /* __KERNEL__ */ Index: linux-work/drivers/macintosh/windfarm_pm91.c =================================================================== --- linux-work.orig/drivers/macintosh/windfarm_pm91.c 2005-11-09 11:49:03.000000000 +1100 +++ linux-work/drivers/macintosh/windfarm_pm91.c 2006-02-08 16:34:39.000000000 +1100 @@ -458,45 +458,6 @@ static void wf_smu_slots_fans_tick(struc /* - * ****** Attributes ****** - * - */ - -#define BUILD_SHOW_FUNC_FIX(name, data) \ -static ssize_t show_##name(struct device *dev, \ - struct device_attribute *attr, \ - char *buf) \ -{ \ - ssize_t r; \ - s32 val = 0; \ - data->ops->get_value(data, &val); \ - r = sprintf(buf, "%d.%03d", FIX32TOPRINT(val)); \ - return r; \ -} \ -static DEVICE_ATTR(name,S_IRUGO,show_##name, NULL); - - -#define BUILD_SHOW_FUNC_INT(name, data) \ -static ssize_t show_##name(struct device *dev, \ - struct device_attribute *attr, \ - char *buf) \ -{ \ - s32 val = 0; \ - data->ops->get_value(data, &val); \ - return sprintf(buf, "%d", val); \ -} \ -static DEVICE_ATTR(name,S_IRUGO,show_##name, NULL); - -BUILD_SHOW_FUNC_INT(cpu_fan, fan_cpu_main); -BUILD_SHOW_FUNC_INT(hd_fan, fan_hd); -BUILD_SHOW_FUNC_INT(slots_fan, fan_slots); - -BUILD_SHOW_FUNC_FIX(cpu_temp, sensor_cpu_temp); -BUILD_SHOW_FUNC_FIX(cpu_power, sensor_cpu_power); -BUILD_SHOW_FUNC_FIX(hd_temp, sensor_hd_temp); -BUILD_SHOW_FUNC_FIX(slots_power, sensor_slots_power); - -/* * ****** Setup / Init / Misc ... ****** * */ @@ -581,10 +542,8 @@ static void wf_smu_new_control(struct wf return; if (fan_cpu_main == NULL && !strcmp(ct->name, "cpu-rear-fan-0")) { - if (wf_get_control(ct) == 0) { + if (wf_get_control(ct) == 0) fan_cpu_main = ct; - device_create_file(wf_smu_dev, &dev_attr_cpu_fan); - } } if (fan_cpu_second == NULL && !strcmp(ct->name, "cpu-rear-fan-1")) { @@ -603,17 +562,13 @@ static void wf_smu_new_control(struct wf } if (fan_hd == NULL && !strcmp(ct->name, "drive-bay-fan")) { - if (wf_get_control(ct) == 0) { + if (wf_get_control(ct) == 0) fan_hd = ct; - device_create_file(wf_smu_dev, &dev_attr_hd_fan); - } } if (fan_slots == NULL && !strcmp(ct->name, "slots-fan")) { - if (wf_get_control(ct) == 0) { + if (wf_get_control(ct) == 0) fan_slots = ct; - device_create_file(wf_smu_dev, &dev_attr_slots_fan); - } } if (fan_cpu_main && (fan_cpu_second || fan_cpu_third) && fan_hd && @@ -627,31 +582,23 @@ static void wf_smu_new_sensor(struct wf_ return; if (sensor_cpu_power == NULL && !strcmp(sr->name, "cpu-power")) { - if (wf_get_sensor(sr) == 0) { + if (wf_get_sensor(sr) == 0) sensor_cpu_power = sr; - device_create_file(wf_smu_dev, &dev_attr_cpu_power); - } } if (sensor_cpu_temp == NULL && !strcmp(sr->name, "cpu-temp")) { - if (wf_get_sensor(sr) == 0) { + if (wf_get_sensor(sr) == 0) sensor_cpu_temp = sr; - device_create_file(wf_smu_dev, &dev_attr_cpu_temp); - } } if (sensor_hd_temp == NULL && !strcmp(sr->name, "hd-temp")) { - if (wf_get_sensor(sr) == 0) { + if (wf_get_sensor(sr) == 0) sensor_hd_temp = sr; - device_create_file(wf_smu_dev, &dev_attr_hd_temp); - } } if (sensor_slots_power == NULL && !strcmp(sr->name, "slots-power")) { - if (wf_get_sensor(sr) == 0) { + if (wf_get_sensor(sr) == 0) sensor_slots_power = sr; - device_create_file(wf_smu_dev, &dev_attr_slots_power); - } } if (sensor_cpu_power && sensor_cpu_temp && @@ -720,40 +667,26 @@ static int wf_smu_remove(struct device * * with that except by adding locks all over... I'll do that * eventually but heh, who ever rmmod this module anyway ? */ - if (sensor_cpu_power) { - device_remove_file(wf_smu_dev, &dev_attr_cpu_power); + if (sensor_cpu_power) wf_put_sensor(sensor_cpu_power); - } - if (sensor_cpu_temp) { - device_remove_file(wf_smu_dev, &dev_attr_cpu_temp); + if (sensor_cpu_temp) wf_put_sensor(sensor_cpu_temp); - } - if (sensor_hd_temp) { - device_remove_file(wf_smu_dev, &dev_attr_hd_temp); + if (sensor_hd_temp) wf_put_sensor(sensor_hd_temp); - } - if (sensor_slots_power) { - device_remove_file(wf_smu_dev, &dev_attr_slots_power); + if (sensor_slots_power) wf_put_sensor(sensor_slots_power); - } /* Release all controls */ - if (fan_cpu_main) { - device_remove_file(wf_smu_dev, &dev_attr_cpu_fan); + if (fan_cpu_main) wf_put_control(fan_cpu_main); - } if (fan_cpu_second) wf_put_control(fan_cpu_second); if (fan_cpu_third) wf_put_control(fan_cpu_third); - if (fan_hd) { - device_remove_file(wf_smu_dev, &dev_attr_hd_fan); + if (fan_hd) wf_put_control(fan_hd); - } - if (fan_slots) { - device_remove_file(wf_smu_dev, &dev_attr_slots_fan); + if (fan_slots) wf_put_control(fan_slots); - } if (cpufreq_clamp) wf_put_control(cpufreq_clamp); Index: linux-work/drivers/macintosh/windfarm_pm81.c =================================================================== --- linux-work.orig/drivers/macintosh/windfarm_pm81.c 2006-01-13 16:55:07.000000000 +1100 +++ linux-work/drivers/macintosh/windfarm_pm81.c 2006-02-08 16:35:28.000000000 +1100 @@ -538,45 +538,6 @@ static void wf_smu_cpu_fans_tick(struct } } - -/* - * ****** Attributes ****** - * - */ - -#define BUILD_SHOW_FUNC_FIX(name, data) \ -static ssize_t show_##name(struct device *dev, \ - struct device_attribute *attr, \ - char *buf) \ -{ \ - ssize_t r; \ - s32 val = 0; \ - data->ops->get_value(data, &val); \ - r = sprintf(buf, "%d.%03d", FIX32TOPRINT(val)); \ - return r; \ -} \ -static DEVICE_ATTR(name,S_IRUGO,show_##name, NULL); - - -#define BUILD_SHOW_FUNC_INT(name, data) \ -static ssize_t show_##name(struct device *dev, \ - struct device_attribute *attr, \ - char *buf) \ -{ \ - s32 val = 0; \ - data->ops->get_value(data, &val); \ - return sprintf(buf, "%d", val); \ -} \ -static DEVICE_ATTR(name,S_IRUGO,show_##name, NULL); - -BUILD_SHOW_FUNC_INT(cpu_fan, fan_cpu_main); -BUILD_SHOW_FUNC_INT(sys_fan, fan_system); -BUILD_SHOW_FUNC_INT(hd_fan, fan_hd); - -BUILD_SHOW_FUNC_FIX(cpu_temp, sensor_cpu_temp); -BUILD_SHOW_FUNC_FIX(cpu_power, sensor_cpu_power); -BUILD_SHOW_FUNC_FIX(hd_temp, sensor_hd_temp); - /* * ****** Setup / Init / Misc ... ****** * @@ -654,17 +615,13 @@ static void wf_smu_new_control(struct wf return; if (fan_cpu_main == NULL && !strcmp(ct->name, "cpu-fan")) { - if (wf_get_control(ct) == 0) { + if (wf_get_control(ct) == 0) fan_cpu_main = ct; - device_create_file(wf_smu_dev, &dev_attr_cpu_fan); - } } if (fan_system == NULL && !strcmp(ct->name, "system-fan")) { - if (wf_get_control(ct) == 0) { + if (wf_get_control(ct) == 0) fan_system = ct; - device_create_file(wf_smu_dev, &dev_attr_sys_fan); - } } if (cpufreq_clamp == NULL && !strcmp(ct->name, "cpufreq-clamp")) { @@ -683,10 +640,8 @@ static void wf_smu_new_control(struct wf } if (fan_hd == NULL && !strcmp(ct->name, "drive-bay-fan")) { - if (wf_get_control(ct) == 0) { + if (wf_get_control(ct) == 0) fan_hd = ct; - device_create_file(wf_smu_dev, &dev_attr_hd_fan); - } } if (fan_system && fan_hd && fan_cpu_main && cpufreq_clamp) @@ -699,24 +654,18 @@ static void wf_smu_new_sensor(struct wf_ return; if (sensor_cpu_power == NULL && !strcmp(sr->name, "cpu-power")) { - if (wf_get_sensor(sr) == 0) { + if (wf_get_sensor(sr) == 0) sensor_cpu_power = sr; - device_create_file(wf_smu_dev, &dev_attr_cpu_power); - } } if (sensor_cpu_temp == NULL && !strcmp(sr->name, "cpu-temp")) { - if (wf_get_sensor(sr) == 0) { + if (wf_get_sensor(sr) == 0) sensor_cpu_temp = sr; - device_create_file(wf_smu_dev, &dev_attr_cpu_temp); - } } if (sensor_hd_temp == NULL && !strcmp(sr->name, "hd-temp")) { - if (wf_get_sensor(sr) == 0) { + if (wf_get_sensor(sr) == 0) sensor_hd_temp = sr; - device_create_file(wf_smu_dev, &dev_attr_hd_temp); - } } if (sensor_cpu_power && sensor_cpu_temp && sensor_hd_temp) @@ -794,32 +743,20 @@ static int wf_smu_remove(struct device * * with that except by adding locks all over... I'll do that * eventually but heh, who ever rmmod this module anyway ? */ - if (sensor_cpu_power) { - device_remove_file(wf_smu_dev, &dev_attr_cpu_power); + if (sensor_cpu_power) wf_put_sensor(sensor_cpu_power); - } - if (sensor_cpu_temp) { - device_remove_file(wf_smu_dev, &dev_attr_cpu_temp); + if (sensor_cpu_temp) wf_put_sensor(sensor_cpu_temp); - } - if (sensor_hd_temp) { - device_remove_file(wf_smu_dev, &dev_attr_hd_temp); + if (sensor_hd_temp) wf_put_sensor(sensor_hd_temp); - } /* Release all controls */ - if (fan_cpu_main) { - device_remove_file(wf_smu_dev, &dev_attr_cpu_fan); + if (fan_cpu_main) wf_put_control(fan_cpu_main); - } - if (fan_hd) { - device_remove_file(wf_smu_dev, &dev_attr_hd_fan); + if (fan_hd) wf_put_control(fan_hd); - } - if (fan_system) { - device_remove_file(wf_smu_dev, &dev_attr_sys_fan); + if (fan_system) wf_put_control(fan_system); - } if (cpufreq_clamp) wf_put_control(cpufreq_clamp); From torvalds at osdl.org Wed Feb 8 17:07:30 2006 From: torvalds at osdl.org (Linus Torvalds) Date: Tue, 7 Feb 2006 22:07:30 -0800 (PST) Subject: [PATCH] powerpc: Thermal control for dual core G5s In-Reply-To: <1139377372.8187.16.camel@localhost.localdomain> References: <1139377372.8187.16.camel@localhost.localdomain> Message-ID: On Wed, 8 Feb 2006, Benjamin Herrenschmidt wrote: > > This patch adds a windfarm module, windfarm_pm112, for the dual core G5s > (both 2 and 4 core models), keeping the machine from getting into > vacuum-cleaner mode ;) This seems to introduce a new warning.. arch/powerpc/platforms/83xx/Kconfig:10: warning: 'select' used by config symbol 'MPC834x_SYS' refer to undefined symbol 'DEFAULT_UIMAGE' drivers/macintosh/Kconfig:193: warning: 'select' used by config symbol 'WINDFARM_PM112' refer to undefined symbol 'I2C_PMAC_SMU' Hmm? Linus From benh at kernel.crashing.org Wed Feb 8 17:38:51 2006 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Wed, 08 Feb 2006 17:38:51 +1100 Subject: [PATCH] powerpc: Thermal control for dual core G5s In-Reply-To: References: <1139377372.8187.16.camel@localhost.localdomain> Message-ID: <1139380731.5003.1.camel@localhost.localdomain> On Tue, 2006-02-07 at 22:07 -0800, Linus Torvalds wrote: > > On Wed, 8 Feb 2006, Benjamin Herrenschmidt wrote: > > > > This patch adds a windfarm module, windfarm_pm112, for the dual core G5s > > (both 2 and 4 core models), keeping the machine from getting into > > vacuum-cleaner mode ;) > > This seems to introduce a new warning.. > > arch/powerpc/platforms/83xx/Kconfig:10: > warning: 'select' used by config symbol 'MPC834x_SYS' refer to undefined symbol 'DEFAULT_UIMAGE' Former is not mine... > drivers/macintosh/Kconfig:193: > warning: 'select' used by config symbol 'WINDFARM_PM112' refer to undefined symbol 'I2C_PMAC_SMU' Ok, looks like I forgot to update the Kconfig for the new i2c driver, it should select I2C_POWERMAC instead. Do you want a new patch or can you just fix it there ? Ben. From galak at kernel.crashing.org Thu Feb 9 01:52:33 2006 From: galak at kernel.crashing.org (Kumar Gala) Date: Wed, 8 Feb 2006 08:52:33 -0600 Subject: [PATCH] powerpc: Thermal control for dual core G5s In-Reply-To: References: <1139377372.8187.16.camel@localhost.localdomain> Message-ID: <87E547D2-A8FC-4A89-89A4-60313C9647B0@kernel.crashing.org> On Feb 8, 2006, at 12:07 AM, Linus Torvalds wrote: > > > On Wed, 8 Feb 2006, Benjamin Herrenschmidt wrote: >> >> This patch adds a windfarm module, windfarm_pm112, for the dual >> core G5s >> (both 2 and 4 core models), keeping the machine from getting into >> vacuum-cleaner mode ;) > > This seems to introduce a new warning.. > > arch/powerpc/platforms/83xx/Kconfig:10: > warning: 'select' used by config symbol 'MPC834x_SYS' refer to > undefined symbol 'DEFAULT_UIMAGE' That's my fault. Paul did push a simple build system update. I'll ask him to do so. http://ozlabs.org/pipermail/linuxppc-dev/2006-January/020980.html - kumar From dwmw2 at infradead.org Thu Feb 9 05:01:00 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 08 Feb 2006 18:01:00 +0000 Subject: PPC64 boot failure with 2.6.15 In-Reply-To: <1138660828.12601.21.camel@localhost.localdomain> References: <200601251821.47557.pat@computer-refuge.org> <200601252307.45741.pat@computer-refuge.org> <200601260051.00902.pat@computer-refuge.org> <200601262025.44777.pat@computer-refuge.org> <1138660828.12601.21.camel@localhost.localdomain> Message-ID: <1139421660.4183.15.camel@pmac.infradead.org> On Tue, 2006-01-31 at 09:40 +1100, Benjamin Herrenschmidt wrote: > Interesting... best would be to try to bisect to find out what > specific patch broke it but I understand that's not easy with those > old kernels that were maintained with bitkeeper... Maybe you could try > to spot which daily bk snapshot broke it if they are still available > somewhere ? What's wrong with just using 'git bisect' on the BK->git converted tree? -- dwmw2 From linas at austin.ibm.com Thu Feb 9 05:29:13 2006 From: linas at austin.ibm.com (Linas Vepstas) Date: Wed, 8 Feb 2006 12:29:13 -0600 Subject: [PATCH]: Documentation: Updated PCI Error Recovery In-Reply-To: <20060207231927.GB19648@kroah.com> References: <20060203000602.GQ24916@austin.ibm.com> <20060207222144.GA15622@kroah.com> <20060207143052.19978ca7.akpm@osdl.org> <20060207223956.GA19009@kroah.com> <20060207145347.72c0a77e.akpm@osdl.org> <20060207231927.GB19648@kroah.com> Message-ID: <20060208182913.GQ24916@austin.ibm.com> On Tue, Feb 07, 2006 at 03:19:27PM -0800, Greg KH was heard to remark: > > It could be all the newly-added trailing whitespace I chopped off. > > Yup, that was it, quilt would have stripped them off for me too. Linas, > please don't do this anymore... Sorry; I'm usually good about that in code, but the Pavlovian reaction didn't trip on docs. --linas From geoffrey.levand at am.sony.com Thu Feb 9 14:08:48 2006 From: geoffrey.levand at am.sony.com (Geoff Levand) Date: Wed, 08 Feb 2006 19:08:48 -0800 Subject: [PATCH] fix prom_init undefined error In-Reply-To: <1139371162.8187.3.camel@localhost.localdomain> References: <1139371162.8187.3.camel@localhost.localdomain> Message-ID: <43EAB240.8030107@am.sony.com> Benjamin Herrenschmidt wrote: > On Tue, 2006-02-07 at 15:10 -0800, Geoff Levand wrote: > >>Paul, >> >>This patch fixes a build error when CONFIG_PPC_OF=n, >>CONFIG_PPC_MULTIPLATFORM=y. It makes the conditionals >>consistent in arch/powerpc/kernel/Makefile and head_64.S >>to both be on CONFIG_PPC_OF. >> >> arch/powerpc/kernel/head_64.o: In function `.__boot_from_prom': >> linux/arch/powerpc/kernel/head_64.S:(.text+0x8158): undefined > > reference to `.prom_init' > >>obj-$(CONFIG_PPC_OF) += prom_init.o > > > With ARCH=powerpc, CONFIG_PPC_OF should always be set. It's supposed to > be set when the device-tree accessors exist which they always do. OK, that makes things clear. > Besides, I'll be removing support for !MULTIPLATFORM too :) (Except for > iSeries at least for a little while). Look at the patch I posted that > removes _machine for an idea of where things are going. I'll try and rework things when you get rid of MULTIPLATFORM. When can we expect it? -Geoff From benh at kernel.crashing.org Thu Feb 9 14:44:45 2006 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Thu, 09 Feb 2006 14:44:45 +1100 Subject: [PATCH] fix prom_init undefined error In-Reply-To: <43EAB240.8030107@am.sony.com> References: <1139371162.8187.3.camel@localhost.localdomain> <43EAB240.8030107@am.sony.com> Message-ID: <1139456685.5003.33.camel@localhost.localdomain> > > Besides, I'll be removing support for !MULTIPLATFORM too :) (Except for > > iSeries at least for a little while). Look at the patch I posted that > > removes _machine for an idea of where things are going. > > I'll try and rework things when you get rid of MULTIPLATFORM. When can > we expect it? Well, I posted a first patch that removes _machine and makes the platform "probe" closer between 32 and 64 bits already a few weeks ago before I went on vacation... I'll revive that patch today or tomorrow and have it merged in powerpc.git. At which point, I'll tackle in no specific order, removing of pre-parsed interrupt stuff in device_node (and implement a proper generic OF interrupt tree parser), making the early init code between 32 and 64 bits even more similar (si discussion about boot code I posted a month or two ago), etc... I'm sorry I can't promise any timeframe at this point though due to personal constraints (just had a baby). Ben. From bdc at carlstrom.com Thu Feb 9 17:02:37 2006 From: bdc at carlstrom.com (Brian D. Carlstrom) Date: Wed, 8 Feb 2006 22:02:37 -0800 Subject: G5 fan problems return moving to 2.6.15 with dual processor 2.7GHz machine In-Reply-To: <1139371016.8187.1.camel@localhost.localdomain> References: <20060205061048.7261.qmail@electricrain.com> <1139130385.5634.14.camel@localhost.localdomain> <17384.62553.442011.514155@zot.electricrain.com> <1139371016.8187.1.camel@localhost.localdomain> Message-ID: <17386.56061.78892.44180@zot.electricrain.com> Benjamin Herrenschmidt writes: > prom_printf should work ... try booting manually (from the OF command > line) and maybe comment out the code that opens the displays... (it > may be clearing the screen).... I tried commented out prom_check_displays and that does prevent the clearing of the screen, but still no visible prom_printf output. The last output seems to be from yaboot, its certainly not one of the prom_print messages from prom_init.c. For good measure, I also tried adding "video=ofonly". Still no prom_printf output visible. However, when I rebooted back to my 2.6.14 kernel, I saw the usual prom_printf messages from prom_init without any changes. I reviewed the prom_init.c diffs between 2.6.14 and 2.6.15 but they are large enough that its not easy to spot an obvious problem. In any case, I didn't have much time to really look at this today, just enough to try the disabling prom_check_displays, I'll have to look more Friday. -bri From michael at ellerman.id.au Thu Feb 9 17:03:27 2006 From: michael at ellerman.id.au (Michael Ellerman) Date: Thu, 09 Feb 2006 17:03:27 +1100 Subject: [PATCH 1/3] powerpc: Clean up pSeries firmware feature initialisation Message-ID: <1139465007.297357.792110844862.qpush@concordia> Clean up fw_feature_init in platforms/pseries/setup.c. Clean up white space and replace the while loop with a for loop - which seems clearer to me. Signed-off-by: Michael Ellerman --- arch/powerpc/platforms/pseries/setup.c | 45 +++++++++++++++------------------ 1 files changed, 21 insertions(+), 24 deletions(-) Index: to-merge/arch/powerpc/platforms/pseries/setup.c =================================================================== --- to-merge.orig/arch/powerpc/platforms/pseries/setup.c +++ to-merge/arch/powerpc/platforms/pseries/setup.c @@ -263,48 +263,45 @@ static int __init pSeries_init_panel(voi arch_initcall(pSeries_init_panel); -/* Build up the ppc64_firmware_features bitmask field - * using contents of device-tree/ibm,hypertas-functions. - * Ultimately this functionality may be moved into prom.c prom_init(). +/* Build up the firmware features bitmask using the contents of + * device-tree/ibm,hypertas-functions. Ultimately this functionality may + * be moved into prom.c prom_init(). */ static void __init fw_feature_init(void) { - struct device_node * dn; - char * hypertas; - unsigned int len; + struct device_node *dn; + char *hypertas, *s; + int len, i; DBG(" -> fw_feature_init()\n"); - ppc64_firmware_features = 0; dn = of_find_node_by_path("/rtas"); if (dn == NULL) { - printk(KERN_ERR "WARNING ! Cannot find RTAS in device-tree !\n"); + printk(KERN_ERR "WARNING! Cannot find RTAS in device-tree!\n"); goto no_rtas; } hypertas = get_property(dn, "ibm,hypertas-functions", &len); - if (hypertas) { - while (len > 0){ - int i, hypertas_len; + if (hypertas == NULL) + goto no_hypertas; + + for (s = hypertas; s < hypertas + len; s += strlen(s) + 1) { + for (i = 0; i < FIRMWARE_MAX_FEATURES; i++) { /* check value against table of strings */ - for(i=0; i < FIRMWARE_MAX_FEATURES ;i++) { - if ((firmware_features_table[i].name) && - (strcmp(firmware_features_table[i].name,hypertas))==0) { - /* we have a match */ - ppc64_firmware_features |= - (firmware_features_table[i].val); - break; - } - } - hypertas_len = strlen(hypertas); - len -= hypertas_len +1; - hypertas+= hypertas_len +1; + if (!firmware_features_table[i].name || + strcmp(firmware_features_table[i].name, s)) + continue; + + /* we have a match */ + ppc64_firmware_features |= + firmware_features_table[i].val; + break; } } +no_hypertas: of_node_put(dn); no_rtas: - DBG(" <- fw_feature_init()\n"); } From michael at ellerman.id.au Thu Feb 9 17:03:33 2006 From: michael at ellerman.id.au (Michael Ellerman) Date: Thu, 09 Feb 2006 17:03:33 +1100 Subject: [PATCH 2/3] powerpc: Move pSeries firmware feature setup into platforms/pseries In-Reply-To: <1139465007.297357.792110844862.qpush@concordia> Message-ID: <20060209060356.5606C679F6@ozlabs.org> Currently we have some stuff in firmware.h and kernel/firmware.c that is #ifdef CONFIG_PPC_PSERIES. Move it all into platforms/pseries. Signed-off-by: Michael Ellerman --- arch/powerpc/kernel/firmware.c | 25 ------- arch/powerpc/platforms/pseries/Makefile | 3 arch/powerpc/platforms/pseries/firmware.c | 104 ++++++++++++++++++++++++++++++ arch/powerpc/platforms/pseries/firmware.h | 17 ++++ arch/powerpc/platforms/pseries/setup.c | 46 ------------- include/asm-powerpc/firmware.h | 9 -- 6 files changed, 124 insertions(+), 80 deletions(-) Index: to-merge/arch/powerpc/kernel/firmware.c =================================================================== --- to-merge.orig/arch/powerpc/kernel/firmware.c +++ to-merge/arch/powerpc/kernel/firmware.c @@ -18,28 +18,3 @@ #include unsigned long ppc64_firmware_features; - -#ifdef CONFIG_PPC_PSERIES -firmware_feature_t firmware_features_table[FIRMWARE_MAX_FEATURES] = { - {FW_FEATURE_PFT, "hcall-pft"}, - {FW_FEATURE_TCE, "hcall-tce"}, - {FW_FEATURE_SPRG0, "hcall-sprg0"}, - {FW_FEATURE_DABR, "hcall-dabr"}, - {FW_FEATURE_COPY, "hcall-copy"}, - {FW_FEATURE_ASR, "hcall-asr"}, - {FW_FEATURE_DEBUG, "hcall-debug"}, - {FW_FEATURE_PERF, "hcall-perf"}, - {FW_FEATURE_DUMP, "hcall-dump"}, - {FW_FEATURE_INTERRUPT, "hcall-interrupt"}, - {FW_FEATURE_MIGRATE, "hcall-migrate"}, - {FW_FEATURE_PERFMON, "hcall-perfmon"}, - {FW_FEATURE_CRQ, "hcall-crq"}, - {FW_FEATURE_VIO, "hcall-vio"}, - {FW_FEATURE_RDMA, "hcall-rdma"}, - {FW_FEATURE_LLAN, "hcall-lLAN"}, - {FW_FEATURE_BULK, "hcall-bulk"}, - {FW_FEATURE_XDABR, "hcall-xdabr"}, - {FW_FEATURE_MULTITCE, "hcall-multi-tce"}, - {FW_FEATURE_SPLPAR, "hcall-splpar"}, -}; -#endif Index: to-merge/arch/powerpc/platforms/pseries/Makefile =================================================================== --- to-merge.orig/arch/powerpc/platforms/pseries/Makefile +++ to-merge/arch/powerpc/platforms/pseries/Makefile @@ -1,5 +1,6 @@ obj-y := pci.o lpar.o hvCall.o nvram.o reconfig.o \ - setup.o iommu.o ras.o rtasd.o pci_dlpar.o + setup.o iommu.o ras.o rtasd.o pci_dlpar.o \ + firmware.o obj-$(CONFIG_SMP) += smp.o obj-$(CONFIG_IBMVIO) += vio.o obj-$(CONFIG_XICS) += xics.o Index: to-merge/arch/powerpc/platforms/pseries/firmware.c =================================================================== --- /dev/null +++ to-merge/arch/powerpc/platforms/pseries/firmware.c @@ -0,0 +1,104 @@ +/* + * pSeries firmware setup code. + * + * Portions from arch/powerpc/platforms/pseries/setup.c: + * Copyright (C) 1995 Linus Torvalds + * Adapted from 'alpha' version by Gary Thomas + * Modified by Cort Dougan (cort at cs.nmt.edu) + * Modified by PPC64 Team, IBM Corp + * + * Portions from arch/powerpc/kernel/firmware.c + * Copyright (C) 2001 Ben. Herrenschmidt (benh at kernel.crashing.org) + * Modifications for ppc64: + * Copyright (C) 2003 Dave Engebretsen + * Copyright (C) 2005 Stephen Rothwell, IBM Corporation + * + * Copyright 2006 IBM Corporation. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +#undef DEBUG + +#include +#include + +#ifdef DEBUG +#define DBG(fmt...) udbg_printf(fmt) +#else +#define DBG(fmt...) +#endif + +typedef struct { + unsigned long val; + char * name; +} firmware_feature_t; + +static __initdata firmware_feature_t +firmware_features_table[FIRMWARE_MAX_FEATURES] = { + {FW_FEATURE_PFT, "hcall-pft"}, + {FW_FEATURE_TCE, "hcall-tce"}, + {FW_FEATURE_SPRG0, "hcall-sprg0"}, + {FW_FEATURE_DABR, "hcall-dabr"}, + {FW_FEATURE_COPY, "hcall-copy"}, + {FW_FEATURE_ASR, "hcall-asr"}, + {FW_FEATURE_DEBUG, "hcall-debug"}, + {FW_FEATURE_PERF, "hcall-perf"}, + {FW_FEATURE_DUMP, "hcall-dump"}, + {FW_FEATURE_INTERRUPT, "hcall-interrupt"}, + {FW_FEATURE_MIGRATE, "hcall-migrate"}, + {FW_FEATURE_PERFMON, "hcall-perfmon"}, + {FW_FEATURE_CRQ, "hcall-crq"}, + {FW_FEATURE_VIO, "hcall-vio"}, + {FW_FEATURE_RDMA, "hcall-rdma"}, + {FW_FEATURE_LLAN, "hcall-lLAN"}, + {FW_FEATURE_BULK, "hcall-bulk"}, + {FW_FEATURE_XDABR, "hcall-xdabr"}, + {FW_FEATURE_MULTITCE, "hcall-multi-tce"}, + {FW_FEATURE_SPLPAR, "hcall-splpar"}, +}; + +/* Build up the firmware features bitmask using the contents of + * device-tree/ibm,hypertas-functions. Ultimately this functionality may + * be moved into prom.c prom_init(). + */ +void __init fw_feature_init(void) +{ + struct device_node *dn; + char *hypertas, *s; + int len, i; + + DBG(" -> fw_feature_init()\n"); + + dn = of_find_node_by_path("/rtas"); + if (dn == NULL) { + printk(KERN_ERR "WARNING! Cannot find RTAS in device-tree!\n"); + goto no_rtas; + } + + hypertas = get_property(dn, "ibm,hypertas-functions", &len); + if (hypertas == NULL) + goto no_hypertas; + + for (s = hypertas; s < hypertas + len; s += strlen(s) + 1) { + for (i = 0; i < FIRMWARE_MAX_FEATURES; i++) { + /* check value against table of strings */ + if (!firmware_features_table[i].name || + strcmp(firmware_features_table[i].name, s)) + continue; + + /* we have a match */ + ppc64_firmware_features |= + firmware_features_table[i].val; + break; + } + } + +no_hypertas: + of_node_put(dn); +no_rtas: + DBG(" <- fw_feature_init()\n"); +} Index: to-merge/arch/powerpc/platforms/pseries/setup.c =================================================================== --- to-merge.orig/arch/powerpc/platforms/pseries/setup.c +++ to-merge/arch/powerpc/platforms/pseries/setup.c @@ -60,7 +60,6 @@ #include #include #include "xics.h" -#include #include #include #include @@ -70,6 +69,7 @@ #include "plpar_wrappers.h" #include "ras.h" +#include "firmware.h" #ifdef DEBUG #define DBG(fmt...) udbg_printf(fmt) @@ -262,50 +262,6 @@ static int __init pSeries_init_panel(voi } arch_initcall(pSeries_init_panel); - -/* Build up the firmware features bitmask using the contents of - * device-tree/ibm,hypertas-functions. Ultimately this functionality may - * be moved into prom.c prom_init(). - */ -static void __init fw_feature_init(void) -{ - struct device_node *dn; - char *hypertas, *s; - int len, i; - - DBG(" -> fw_feature_init()\n"); - - dn = of_find_node_by_path("/rtas"); - if (dn == NULL) { - printk(KERN_ERR "WARNING! Cannot find RTAS in device-tree!\n"); - goto no_rtas; - } - - hypertas = get_property(dn, "ibm,hypertas-functions", &len); - if (hypertas == NULL) - goto no_hypertas; - - for (s = hypertas; s < hypertas + len; s += strlen(s) + 1) { - for (i = 0; i < FIRMWARE_MAX_FEATURES; i++) { - /* check value against table of strings */ - if (!firmware_features_table[i].name || - strcmp(firmware_features_table[i].name, s)) - continue; - - /* we have a match */ - ppc64_firmware_features |= - firmware_features_table[i].val; - break; - } - } - -no_hypertas: - of_node_put(dn); -no_rtas: - DBG(" <- fw_feature_init()\n"); -} - - static void __init pSeries_discover_pic(void) { struct device_node *np; Index: to-merge/include/asm-powerpc/firmware.h =================================================================== --- to-merge.orig/include/asm-powerpc/firmware.h +++ to-merge/include/asm-powerpc/firmware.h @@ -89,15 +89,6 @@ static inline unsigned long firmware_has (FW_FEATURE_POSSIBLE & ppc64_firmware_features & feature); } -#ifdef CONFIG_PPC_PSERIES -typedef struct { - unsigned long val; - char * name; -} firmware_feature_t; - -extern firmware_feature_t firmware_features_table[]; -#endif - extern void system_reset_fwnmi(void); extern void machine_check_fwnmi(void); Index: to-merge/arch/powerpc/platforms/pseries/firmware.h =================================================================== --- /dev/null +++ to-merge/arch/powerpc/platforms/pseries/firmware.h @@ -0,0 +1,17 @@ +/* + * Copyright 2006 IBM Corporation. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +#ifndef _PSERIES_FIRMWARE_H +#define _PSERIES_FIRMWARE_H + +#include + +extern void __init fw_feature_init(void); + +#endif /* _PSERIES_FIRMWARE_H */ From michael at ellerman.id.au Thu Feb 9 17:03:35 2006 From: michael at ellerman.id.au (Michael Ellerman) Date: Thu, 09 Feb 2006 17:03:35 +1100 Subject: [PATCH 3/3] powerpc: Replace platform_is_lpar() with a firmware feature In-Reply-To: <1139465007.297357.792110844862.qpush@concordia> Message-ID: <20060209060359.2F789679F7@ozlabs.org> It has been decreed that platform numbers are evil, so as a step in that direction, replace platform_is_lpar() with a FW_FEATURE_LPAR bit. Signed-off-by: Michael Ellerman --- arch/powerpc/mm/hash_utils_64.c | 4 ++-- arch/powerpc/oprofile/op_model_power4.c | 3 ++- arch/powerpc/platforms/iseries/setup.c | 10 +++++++--- arch/powerpc/platforms/pseries/iommu.c | 2 +- arch/powerpc/platforms/pseries/setup.c | 11 +++++++---- arch/powerpc/platforms/pseries/smp.c | 2 +- arch/powerpc/platforms/pseries/xics.c | 3 ++- include/asm-powerpc/firmware.h | 7 ++++--- include/asm-powerpc/processor.h | 1 - 9 files changed, 26 insertions(+), 17 deletions(-) Index: to-merge/include/asm-powerpc/firmware.h =================================================================== --- to-merge.orig/include/asm-powerpc/firmware.h +++ to-merge/include/asm-powerpc/firmware.h @@ -41,6 +41,7 @@ #define FW_FEATURE_MULTITCE (1UL<<19) #define FW_FEATURE_SPLPAR (1UL<<20) #define FW_FEATURE_ISERIES (1UL<<21) +#define FW_FEATURE_LPAR (1UL<<22) enum { #ifdef CONFIG_PPC64 @@ -51,10 +52,10 @@ enum { FW_FEATURE_MIGRATE | FW_FEATURE_PERFMON | FW_FEATURE_CRQ | FW_FEATURE_VIO | FW_FEATURE_RDMA | FW_FEATURE_LLAN | FW_FEATURE_BULK | FW_FEATURE_XDABR | FW_FEATURE_MULTITCE | - FW_FEATURE_SPLPAR, + FW_FEATURE_SPLPAR | FW_FEATURE_LPAR, FW_FEATURE_PSERIES_ALWAYS = 0, - FW_FEATURE_ISERIES_POSSIBLE = FW_FEATURE_ISERIES, - FW_FEATURE_ISERIES_ALWAYS = FW_FEATURE_ISERIES, + FW_FEATURE_ISERIES_POSSIBLE = FW_FEATURE_ISERIES | FW_FEATURE_LPAR, + FW_FEATURE_ISERIES_ALWAYS = FW_FEATURE_ISERIES | FW_FEATURE_LPAR, FW_FEATURE_POSSIBLE = #ifdef CONFIG_PPC_PSERIES FW_FEATURE_PSERIES_POSSIBLE | Index: to-merge/arch/powerpc/mm/hash_utils_64.c =================================================================== --- to-merge.orig/arch/powerpc/mm/hash_utils_64.c +++ to-merge/arch/powerpc/mm/hash_utils_64.c @@ -421,7 +421,7 @@ void __init htab_initialize(void) htab_hash_mask = pteg_count - 1; - if (platform_is_lpar()) { + if (firmware_has_feature(FW_FEATURE_LPAR)) { /* Using a hypervisor which owns the htab */ htab_address = NULL; _SDR1 = 0; @@ -515,7 +515,7 @@ void __init htab_initialize(void) void htab_initialize_secondary(void) { - if (!platform_is_lpar()) + if (!firmware_has_feature(FW_FEATURE_LPAR)) mtspr(SPRN_SDR1, _SDR1); } Index: to-merge/arch/powerpc/oprofile/op_model_power4.c =================================================================== --- to-merge.orig/arch/powerpc/oprofile/op_model_power4.c +++ to-merge/arch/powerpc/oprofile/op_model_power4.c @@ -10,6 +10,7 @@ #include #include #include +#include #include #include #include @@ -232,7 +233,7 @@ static unsigned long get_pc(struct pt_re mmcra = mfspr(SPRN_MMCRA); /* Were we in the hypervisor? */ - if (platform_is_lpar() && (mmcra & MMCRA_SIHV)) + if (firmware_has_feature(FW_FEATURE_LPAR) && (mmcra & MMCRA_SIHV)) /* function descriptor madness */ return *((unsigned long *)hypervisor_bucket); Index: to-merge/arch/powerpc/platforms/pseries/iommu.c =================================================================== --- to-merge.orig/arch/powerpc/platforms/pseries/iommu.c +++ to-merge/arch/powerpc/platforms/pseries/iommu.c @@ -582,7 +582,7 @@ void iommu_init_early_pSeries(void) return; } - if (platform_is_lpar()) { + if (firmware_has_feature(FW_FEATURE_LPAR)) { if (firmware_has_feature(FW_FEATURE_MULTITCE)) { ppc_md.tce_build = tce_buildmulti_pSeriesLP; ppc_md.tce_free = tce_freemulti_pSeriesLP; Index: to-merge/arch/powerpc/platforms/pseries/setup.c =================================================================== --- to-merge.orig/arch/powerpc/platforms/pseries/setup.c +++ to-merge/arch/powerpc/platforms/pseries/setup.c @@ -246,7 +246,7 @@ static void __init pSeries_setup_arch(vo ppc_md.idle_loop = default_idle; } - if (platform_is_lpar()) + if (firmware_has_feature(FW_FEATURE_LPAR)) ppc_md.enable_pmcs = pseries_lpar_enable_pmcs; else ppc_md.enable_pmcs = power4_enable_pmcs; @@ -326,7 +326,7 @@ static void __init pSeries_init_early(vo fw_feature_init(); - if (platform_is_lpar()) + if (firmware_has_feature(FW_FEATURE_LPAR)) hpte_init_lpar(); else { hpte_init_native(); @@ -334,7 +334,7 @@ static void __init pSeries_init_early(vo get_property(of_chosen, "linux,iommu-off", NULL)); } - if (platform_is_lpar()) + if (firmware_has_feature(FW_FEATURE_LPAR)) find_udbg_vterm(); if (firmware_has_feature(FW_FEATURE_DABR)) @@ -390,6 +390,9 @@ static int __init pSeries_probe(int plat * it here ... */ + if (platform == PLATFORM_PSERIES_LPAR) + ppc64_firmware_features |= FW_FEATURE_LPAR; + return 1; } @@ -529,7 +532,7 @@ static void pseries_shared_idle(void) static int pSeries_pci_probe_mode(struct pci_bus *bus) { - if (platform_is_lpar()) + if (firmware_has_feature(FW_FEATURE_LPAR)) return PCI_PROBE_DEVTREE; return PCI_PROBE_NORMAL; } Index: to-merge/arch/powerpc/platforms/pseries/smp.c =================================================================== --- to-merge.orig/arch/powerpc/platforms/pseries/smp.c +++ to-merge/arch/powerpc/platforms/pseries/smp.c @@ -443,7 +443,7 @@ void __init smp_init_pSeries(void) smp_ops->cpu_die = pSeries_cpu_die; /* Processors can be added/removed only on LPAR */ - if (platform_is_lpar()) + if (firmware_has_feature(FW_FEATURE_LPAR)) pSeries_reconfig_notifier_register(&pSeries_smp_nb); #endif Index: to-merge/arch/powerpc/platforms/pseries/xics.c =================================================================== --- to-merge.orig/arch/powerpc/platforms/pseries/xics.c +++ to-merge/arch/powerpc/platforms/pseries/xics.c @@ -20,6 +20,7 @@ #include #include #include +#include #include #include #include @@ -536,7 +537,7 @@ nextnode: of_node_put(np); } - if (platform_is_lpar()) + if (firmware_has_feature(FW_FEATURE_LPAR)) ops = &pSeriesLP_ops; else { #ifdef CONFIG_SMP Index: to-merge/arch/powerpc/platforms/iseries/setup.c =================================================================== --- to-merge.orig/arch/powerpc/platforms/iseries/setup.c +++ to-merge/arch/powerpc/platforms/iseries/setup.c @@ -303,8 +303,6 @@ static void __init iSeries_init_early(vo { DBG(" -> iSeries_init_early()\n"); - ppc64_firmware_features = FW_FEATURE_ISERIES; - ppc64_interrupt_controller = IC_ISERIES; #if defined(CONFIG_BLK_DEV_INITRD) @@ -710,7 +708,13 @@ void __init iSeries_init_IRQ(void) { } static int __init iseries_probe(int platform) { - return PLATFORM_ISERIES_LPAR == platform; + if (PLATFORM_ISERIES_LPAR != platform) + return 0; + + ppc64_firmware_features |= FW_FEATURE_ISERIES; + ppc64_firmware_features |= FW_FEATURE_LPAR; + + return 1; } struct machdep_calls __initdata iseries_md = { Index: to-merge/include/asm-powerpc/processor.h =================================================================== --- to-merge.orig/include/asm-powerpc/processor.h +++ to-merge/include/asm-powerpc/processor.h @@ -52,7 +52,6 @@ #ifdef __KERNEL__ #define platform_is_pseries() (_machine == PLATFORM_PSERIES || \ _machine == PLATFORM_PSERIES_LPAR) -#define platform_is_lpar() (!!(_machine & PLATFORM_LPAR)) #if defined(CONFIG_PPC_MULTIPLATFORM) extern int _machine; From ntl at pobox.com Thu Feb 9 18:23:32 2006 From: ntl at pobox.com (Nathan Lynch) Date: Thu, 9 Feb 2006 01:23:32 -0600 Subject: [PATCH 1/3] powerpc: Clean up pSeries firmware feature initialisation In-Reply-To: <1139465007.297357.792110844862.qpush@concordia> References: <1139465007.297357.792110844862.qpush@concordia> Message-ID: <20060209072331.GK18730@localhost.localdomain> Michael Ellerman wrote: ... > DBG(" -> fw_feature_init()\n"); > > - ppc64_firmware_features = 0; > dn = of_find_node_by_path("/rtas"); > if (dn == NULL) { > - printk(KERN_ERR "WARNING ! Cannot find RTAS in device-tree !\n"); > + printk(KERN_ERR "WARNING! Cannot find RTAS in device-tree!\n"); > goto no_rtas; > } > > hypertas = get_property(dn, "ibm,hypertas-functions", &len); > - if (hypertas) { > - while (len > 0){ > - int i, hypertas_len; > + if (hypertas == NULL) > + goto no_hypertas; ... > +no_hypertas: > of_node_put(dn); > no_rtas: > - > DBG(" <- fw_feature_init()\n"); > } of_node_put can handle a null pointer fine, so you could get away with just one label here. From cfriesen at nortel.com Fri Feb 10 03:03:22 2006 From: cfriesen at nortel.com (Christopher Friesen) Date: Thu, 09 Feb 2006 10:03:22 -0600 Subject: question on ptep_clear_flush_dirty() for ppc64 Message-ID: <43EB67CA.7000207@nortel.com> I notice that (at least for 2.6.10) ptep_clear_flush_dirty() for ppc64 simply does ptep_test_and_clear_dirty(), then calls flush_tlb_pending(). I want to call ptep_clear_flush_dirty() for a large number of pages (tens of thousands) in an optimal manner--would it be legal for me to call ptep_test_and_clear_dirty() for each page, then call flush_tlb_pending() once at the end? Are there any implications for SMP machines? The reason I ask is that in a small experiment I did this increased the speed of a certain task by a factor of about 25%, which is significant in our application. I just wanted to make sure it was safe. Thanks, Chris From benh at kernel.crashing.org Fri Feb 10 10:04:40 2006 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Fri, 10 Feb 2006 10:04:40 +1100 Subject: G5 fan problems return moving to 2.6.15 with dual processor 2.7GHz machine In-Reply-To: <17386.56061.78892.44180@zot.electricrain.com> References: <20060205061048.7261.qmail@electricrain.com> <1139130385.5634.14.camel@localhost.localdomain> <17384.62553.442011.514155@zot.electricrain.com> <1139371016.8187.1.camel@localhost.localdomain> <17386.56061.78892.44180@zot.electricrain.com> Message-ID: <1139526280.5003.40.camel@localhost.localdomain> On Wed, 2006-02-08 at 22:02 -0800, Brian D. Carlstrom wrote: > Benjamin Herrenschmidt writes: > > prom_printf should work ... try booting manually (from the OF command > > line) and maybe comment out the code that opens the displays... (it > > may be clearing the screen).... > > I tried commented out prom_check_displays and that does prevent the > clearing of the screen, but still no visible prom_printf output. The > last output seems to be from yaboot, its certainly not one of the > prom_print messages from prom_init.c. For good measure, I also tried > adding "video=ofonly". Still no prom_printf output visible. > > However, when I rebooted back to my 2.6.14 kernel, I saw the usual > prom_printf messages from prom_init without any changes. I reviewed the > prom_init.c diffs between 2.6.14 and 2.6.15 but they are large enough > that its not easy to spot an obvious problem. > > In any case, I didn't have much time to really look at this today, just > enough to try the disabling prom_check_displays, I'll have to look more > Friday. That is strange... Ben. From olof at lixom.net Fri Feb 10 10:25:12 2006 From: olof at lixom.net (Olof Johansson) Date: Thu, 9 Feb 2006 17:25:12 -0600 Subject: [PATCH 2/3] powerpc: Move pSeries firmware feature setup into platforms/pseries In-Reply-To: <20060209060356.5606C679F6@ozlabs.org> References: <1139465007.297357.792110844862.qpush@concordia> <20060209060356.5606C679F6@ozlabs.org> Message-ID: <20060209232511.GN4833@pb15.lixom.net> On Thu, Feb 09, 2006 at 05:03:33PM +1100, Michael Ellerman wrote: > Currently we have some stuff in firmware.h and kernel/firmware.c that is > #ifdef CONFIG_PPC_PSERIES. Move it all into platforms/pseries. I suggest renaming it to something like fw_set_hv_features() while you're at it, since all features it parses and sets are hypervisor-related. There are other, not yet fully merged hypervisor guest ports that might want to share this code (Xen, rhype) for non-pseries machines, so there's a chance that a move into platforms will just need to be undone down the road. However, since that code isn't merged yet, let's worry about that then instead of now. -Olof From michael at ellerman.id.au Fri Feb 10 10:48:46 2006 From: michael at ellerman.id.au (Michael Ellerman) Date: Fri, 10 Feb 2006 10:48:46 +1100 Subject: [PATCH 1/3] powerpc: Clean up pSeries firmware feature initialisation In-Reply-To: <20060209072331.GK18730@localhost.localdomain> References: <1139465007.297357.792110844862.qpush@concordia> <20060209072331.GK18730@localhost.localdomain> Message-ID: <200602101048.50034.michael@ellerman.id.au> On Thu, 9 Feb 2006 18:23, Nathan Lynch wrote: > Michael Ellerman wrote: > > +no_hypertas: > > of_node_put(dn); > > no_rtas: > > - > > DBG(" <- fw_feature_init()\n"); > > } > > of_node_put can handle a null pointer fine, so you could get away with > just one label here. Nice, I'll fix it up and resend. -- Michael Ellerman IBM OzLabs wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20060210/11ffcc7e/attachment.pgp From benh at kernel.crashing.org Fri Feb 10 13:54:27 2006 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Fri, 10 Feb 2006 13:54:27 +1100 Subject: question on ptep_clear_flush_dirty() for ppc64 In-Reply-To: <43EB67CA.7000207@nortel.com> References: <43EB67CA.7000207@nortel.com> Message-ID: <1139540068.5003.72.camel@localhost.localdomain> On Thu, 2006-02-09 at 10:03 -0600, Christopher Friesen wrote: > I notice that (at least for 2.6.10) ptep_clear_flush_dirty() for ppc64 > simply does ptep_test_and_clear_dirty(), then calls flush_tlb_pending(). > > I want to call ptep_clear_flush_dirty() for a large number of pages > (tens of thousands) in an optimal manner--would it be legal for me to > call ptep_test_and_clear_dirty() for each page, then call > flush_tlb_pending() once at the end? Are there any implications for SMP > machines? > > The reason I ask is that in a small experiment I did this increased the > speed of a certain task by a factor of about 25%, which is significant > in our application. I just wanted to make sure it was safe. If you do that, just beware that if any "new" dirtying happens between the update of the linux PTE and the flush_tlb_pending(), it will not be lost... this is not a problem if you only "use" the result of the function (the collected dirty bits) after you flush_tlb_pending() since you will have those already marked dirty. I don't think you need the page table lock, though I'm a bit tired at the moment and may be missing something, and I don't think you need to disable preemption as a context switch will call flush_tlb_pending()... Ben. From benh at kernel.crashing.org Fri Feb 10 14:01:15 2006 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Fri, 10 Feb 2006 14:01:15 +1100 Subject: __setup_cpu_be problem In-Reply-To: <43E9050C.2000300@am.sony.com> References: <43E9050C.2000300@am.sony.com> Message-ID: <1139540476.5003.74.camel@localhost.localdomain> On Tue, 2006-02-07 at 12:37 -0800, Geoff Levand wrote: > Arnd, > > It seems HID6 is a hypervisor resource... Can we just have > '.cpu_setup = __setup_cpu_power4', and you setup your > page sizes somewhere else? Or better test if MSR:HV is set ? :) But yeah, he shouldn't have to set the page sizes there anyway, I would expect the firmware to do it and pass the right sizes via the device-tree since that's what the kernel expects. (Though you really want LP0 to be 16M and not 1M as the kernel can't really deal with the later properly anyway with the current page table layouts). > -Geoff > > struct cpu_spec cpu_specs[] = { > { /* Cell Broadband Engine */ > .cpu_setup = __setup_cpu_be, > }, > > _GLOBAL(__setup_cpu_be) > /* Set large page sizes LP=0: 16MB, LP=1: 64KB */ > addi r3, 0, 0 > ori r3, r3, HID6_LB > sldi r3, r3, 32 > nor r3, r3, r3 > mfspr r4, SPRN_HID6 > and r4, r4, r3 > addi r3, 0, 0x02000 > sldi r3, r3, 32 > or r4, r4, r3 > mtspr SPRN_HID6, r4 > blr > > _______________________________________________ > Linuxppc64-dev mailing list > Linuxppc64-dev at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc64-dev From arnd at arndb.de Fri Feb 10 15:21:15 2006 From: arnd at arndb.de (arnd at arndb.de) Date: Fri, 10 Feb 2006 05:21:15 +0100 Subject: AW: Re: __setup_cpu_be problem Message-ID: <2812322.110611139545275893.JavaMail.servlet@kundenserver> > >On Tue, 2006-02-07 at 12:37 -0800, Geoff Levand wrote: >> Arnd, >> >> It seems HID6 is a hypervisor resource... Can we just have >> '.cpu_setup = __setup_cpu_power4', and you setup your >> page sizes somewhere else? > >Or better test if MSR:HV is set ? :) But yeah, he shouldn't have to set >the page sizes there anyway, I would expect the firmware to do it and >pass the right sizes via the device-tree since that's what the kernel >expects. (Though you really want LP0 to be 16M and not 1M as the kernel >can't really deal with the later properly anyway with the current page >table layouts). > [/me is sing webmail from some distant location in .nz, sorry if the mail gets messed up] Doing it in the firmware sounds like the right solution to me. I would however not want to do that if the current firmware sets the wrong page sizes. I know that Hartmut wanted me to provide him with the right device tree information that he needs to create to say that the page size are 16M, 64k and 4k. Maybe we can find a combined solution for these problems. Using __setup_cpu_power4 should be ok. We could probably do a fallback in the cell setup to see if the properties are in the device tree and do our own HID6 setup stuff if not, normally expecting that the firmware settings match the device tree. Geoff, if your firmware does not already have the properties for large page sizes, could you add them? Ben, could you point Hartmut (and maybe Geoff) to the documentation for how the device tree needs to look like? Hartmut, can you find out the value of HID6 when you enter the kernel from the firmware? Arnd <>< From benh at kernel.crashing.org Fri Feb 10 15:35:15 2006 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Fri, 10 Feb 2006 15:35:15 +1100 Subject: AW: Re: __setup_cpu_be problem In-Reply-To: <2812322.110611139545275893.JavaMail.servlet@kundenserver> References: <2812322.110611139545275893.JavaMail.servlet@kundenserver> Message-ID: <1139546116.5003.81.camel@localhost.localdomain> > [/me is sing webmail from some distant location in .nz, sorry if > the mail gets messed up] > > Doing it in the firmware sounds like the right solution to me. > I would however not want to do that if the current firmware > sets the wrong page sizes. > > I know that Hartmut wanted me to provide him with the right device > tree information that he needs to create to say that the page > size are 16M, 64k and 4k. Maybe we can find a combined solution > for these problems. Using __setup_cpu_power4 should be ok. I don't completely understand your statement ... sorry > We could probably do a fallback in the cell setup to see if > the properties are in the device tree and do our own HID6 > setup stuff if not, normally expecting that the firmware settings > match the device tree. We should not touch HID6 at all ... we should assume the firmware set it appropriately and have setup matching page size entries in the device-tree. I don't think we need to support changing that value especially since the kernel doesn't quite support 1M large page sizes anyway. > Geoff, if your firmware does not already have the properties > for large page sizes, could you add them? > > Ben, could you point Hartmut (and maybe Geoff) to the documentation > for how the device tree needs to look like? I'm not sure we published that yet :) I would suggest looking at what the kernel does to parse these instead in hash_utils.c until I get a former IBM approval for the spec to be published > Hartmut, can you find out the value of HID6 when you enter the kernel > from the firmware? Ben. From michael at ellerman.id.au Fri Feb 10 15:47:32 2006 From: michael at ellerman.id.au (Michael Ellerman) Date: Fri, 10 Feb 2006 15:47:32 +1100 Subject: [PATCH 1/2] powerpc: Clean up pSeries firmware feature initialisation Message-ID: <1139546852.877687.10893684750.qpush@concordia> Clean up fw_feature_init in platforms/pseries/setup.c. Clean up white space and replace the while loop with a for loop - which seems clearer to me. Signed-off-by: Michael Ellerman --- arch/powerpc/platforms/pseries/setup.c | 48 +++++++++++++++------------------ 1 files changed, 22 insertions(+), 26 deletions(-) Index: to-merge/arch/powerpc/platforms/pseries/setup.c =================================================================== --- to-merge.orig/arch/powerpc/platforms/pseries/setup.c +++ to-merge/arch/powerpc/platforms/pseries/setup.c @@ -263,48 +263,44 @@ static int __init pSeries_init_panel(voi arch_initcall(pSeries_init_panel); -/* Build up the ppc64_firmware_features bitmask field - * using contents of device-tree/ibm,hypertas-functions. - * Ultimately this functionality may be moved into prom.c prom_init(). +/* Build up the firmware features bitmask using the contents of + * device-tree/ibm,hypertas-functions. Ultimately this functionality may + * be moved into prom.c prom_init(). */ static void __init fw_feature_init(void) { - struct device_node * dn; - char * hypertas; - unsigned int len; + struct device_node *dn; + char *hypertas, *s; + int len, i; DBG(" -> fw_feature_init()\n"); - ppc64_firmware_features = 0; dn = of_find_node_by_path("/rtas"); if (dn == NULL) { - printk(KERN_ERR "WARNING ! Cannot find RTAS in device-tree !\n"); - goto no_rtas; + printk(KERN_ERR "WARNING! Cannot find RTAS in device-tree!\n"); + goto out; } hypertas = get_property(dn, "ibm,hypertas-functions", &len); - if (hypertas) { - while (len > 0){ - int i, hypertas_len; + if (hypertas == NULL) + goto out; + + for (s = hypertas; s < hypertas + len; s += strlen(s) + 1) { + for (i = 0; i < FIRMWARE_MAX_FEATURES; i++) { /* check value against table of strings */ - for(i=0; i < FIRMWARE_MAX_FEATURES ;i++) { - if ((firmware_features_table[i].name) && - (strcmp(firmware_features_table[i].name,hypertas))==0) { - /* we have a match */ - ppc64_firmware_features |= - (firmware_features_table[i].val); - break; - } - } - hypertas_len = strlen(hypertas); - len -= hypertas_len +1; - hypertas+= hypertas_len +1; + if (!firmware_features_table[i].name || + strcmp(firmware_features_table[i].name, s)) + continue; + + /* we have a match */ + ppc64_firmware_features |= + firmware_features_table[i].val; + break; } } +out: of_node_put(dn); -no_rtas: - DBG(" <- fw_feature_init()\n"); } From michael at ellerman.id.au Fri Feb 10 15:47:36 2006 From: michael at ellerman.id.au (Michael Ellerman) Date: Fri, 10 Feb 2006 15:47:36 +1100 Subject: [PATCH 2/2] powerpc: Move pSeries firmware feature setup into platforms/pseries In-Reply-To: <1139546852.877687.10893684750.qpush@concordia> Message-ID: <20060210044802.B8D1E67B20@ozlabs.org> Currently we have some stuff in firmware.h and kernel/firmware.c that is #ifdef CONFIG_PPC_PSERIES. Move it all into platforms/pseries. Signed-off-by: Michael Ellerman --- arch/powerpc/kernel/firmware.c | 25 ------- arch/powerpc/platforms/pseries/Makefile | 3 arch/powerpc/platforms/pseries/firmware.c | 103 ++++++++++++++++++++++++++++++ arch/powerpc/platforms/pseries/firmware.h | 17 ++++ arch/powerpc/platforms/pseries/setup.c | 45 ------------- include/asm-powerpc/firmware.h | 9 -- 6 files changed, 123 insertions(+), 79 deletions(-) Index: to-merge/arch/powerpc/kernel/firmware.c =================================================================== --- to-merge.orig/arch/powerpc/kernel/firmware.c +++ to-merge/arch/powerpc/kernel/firmware.c @@ -18,28 +18,3 @@ #include unsigned long ppc64_firmware_features; - -#ifdef CONFIG_PPC_PSERIES -firmware_feature_t firmware_features_table[FIRMWARE_MAX_FEATURES] = { - {FW_FEATURE_PFT, "hcall-pft"}, - {FW_FEATURE_TCE, "hcall-tce"}, - {FW_FEATURE_SPRG0, "hcall-sprg0"}, - {FW_FEATURE_DABR, "hcall-dabr"}, - {FW_FEATURE_COPY, "hcall-copy"}, - {FW_FEATURE_ASR, "hcall-asr"}, - {FW_FEATURE_DEBUG, "hcall-debug"}, - {FW_FEATURE_PERF, "hcall-perf"}, - {FW_FEATURE_DUMP, "hcall-dump"}, - {FW_FEATURE_INTERRUPT, "hcall-interrupt"}, - {FW_FEATURE_MIGRATE, "hcall-migrate"}, - {FW_FEATURE_PERFMON, "hcall-perfmon"}, - {FW_FEATURE_CRQ, "hcall-crq"}, - {FW_FEATURE_VIO, "hcall-vio"}, - {FW_FEATURE_RDMA, "hcall-rdma"}, - {FW_FEATURE_LLAN, "hcall-lLAN"}, - {FW_FEATURE_BULK, "hcall-bulk"}, - {FW_FEATURE_XDABR, "hcall-xdabr"}, - {FW_FEATURE_MULTITCE, "hcall-multi-tce"}, - {FW_FEATURE_SPLPAR, "hcall-splpar"}, -}; -#endif Index: to-merge/arch/powerpc/platforms/pseries/Makefile =================================================================== --- to-merge.orig/arch/powerpc/platforms/pseries/Makefile +++ to-merge/arch/powerpc/platforms/pseries/Makefile @@ -1,5 +1,6 @@ obj-y := pci.o lpar.o hvCall.o nvram.o reconfig.o \ - setup.o iommu.o ras.o rtasd.o pci_dlpar.o + setup.o iommu.o ras.o rtasd.o pci_dlpar.o \ + firmware.o obj-$(CONFIG_SMP) += smp.o obj-$(CONFIG_IBMVIO) += vio.o obj-$(CONFIG_XICS) += xics.o Index: to-merge/arch/powerpc/platforms/pseries/firmware.c =================================================================== --- /dev/null +++ to-merge/arch/powerpc/platforms/pseries/firmware.c @@ -0,0 +1,103 @@ +/* + * pSeries firmware setup code. + * + * Portions from arch/powerpc/platforms/pseries/setup.c: + * Copyright (C) 1995 Linus Torvalds + * Adapted from 'alpha' version by Gary Thomas + * Modified by Cort Dougan (cort at cs.nmt.edu) + * Modified by PPC64 Team, IBM Corp + * + * Portions from arch/powerpc/kernel/firmware.c + * Copyright (C) 2001 Ben. Herrenschmidt (benh at kernel.crashing.org) + * Modifications for ppc64: + * Copyright (C) 2003 Dave Engebretsen + * Copyright (C) 2005 Stephen Rothwell, IBM Corporation + * + * Copyright 2006 IBM Corporation. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +#undef DEBUG + +#include +#include + +#ifdef DEBUG +#define DBG(fmt...) udbg_printf(fmt) +#else +#define DBG(fmt...) +#endif + +typedef struct { + unsigned long val; + char * name; +} firmware_feature_t; + +static __initdata firmware_feature_t +firmware_features_table[FIRMWARE_MAX_FEATURES] = { + {FW_FEATURE_PFT, "hcall-pft"}, + {FW_FEATURE_TCE, "hcall-tce"}, + {FW_FEATURE_SPRG0, "hcall-sprg0"}, + {FW_FEATURE_DABR, "hcall-dabr"}, + {FW_FEATURE_COPY, "hcall-copy"}, + {FW_FEATURE_ASR, "hcall-asr"}, + {FW_FEATURE_DEBUG, "hcall-debug"}, + {FW_FEATURE_PERF, "hcall-perf"}, + {FW_FEATURE_DUMP, "hcall-dump"}, + {FW_FEATURE_INTERRUPT, "hcall-interrupt"}, + {FW_FEATURE_MIGRATE, "hcall-migrate"}, + {FW_FEATURE_PERFMON, "hcall-perfmon"}, + {FW_FEATURE_CRQ, "hcall-crq"}, + {FW_FEATURE_VIO, "hcall-vio"}, + {FW_FEATURE_RDMA, "hcall-rdma"}, + {FW_FEATURE_LLAN, "hcall-lLAN"}, + {FW_FEATURE_BULK, "hcall-bulk"}, + {FW_FEATURE_XDABR, "hcall-xdabr"}, + {FW_FEATURE_MULTITCE, "hcall-multi-tce"}, + {FW_FEATURE_SPLPAR, "hcall-splpar"}, +}; + +/* Build up the firmware features bitmask using the contents of + * device-tree/ibm,hypertas-functions. Ultimately this functionality may + * be moved into prom.c prom_init(). + */ +void __init fw_feature_init(void) +{ + struct device_node *dn; + char *hypertas, *s; + int len, i; + + DBG(" -> fw_feature_init()\n"); + + dn = of_find_node_by_path("/rtas"); + if (dn == NULL) { + printk(KERN_ERR "WARNING! Cannot find RTAS in device-tree!\n"); + goto out; + } + + hypertas = get_property(dn, "ibm,hypertas-functions", &len); + if (hypertas == NULL) + goto out; + + for (s = hypertas; s < hypertas + len; s += strlen(s) + 1) { + for (i = 0; i < FIRMWARE_MAX_FEATURES; i++) { + /* check value against table of strings */ + if (!firmware_features_table[i].name || + strcmp(firmware_features_table[i].name, s)) + continue; + + /* we have a match */ + ppc64_firmware_features |= + firmware_features_table[i].val; + break; + } + } + +out: + of_node_put(dn); + DBG(" <- fw_feature_init()\n"); +} Index: to-merge/arch/powerpc/platforms/pseries/setup.c =================================================================== --- to-merge.orig/arch/powerpc/platforms/pseries/setup.c +++ to-merge/arch/powerpc/platforms/pseries/setup.c @@ -60,7 +60,6 @@ #include #include #include "xics.h" -#include #include #include #include @@ -70,6 +69,7 @@ #include "plpar_wrappers.h" #include "ras.h" +#include "firmware.h" #ifdef DEBUG #define DBG(fmt...) udbg_printf(fmt) @@ -262,49 +262,6 @@ static int __init pSeries_init_panel(voi } arch_initcall(pSeries_init_panel); - -/* Build up the firmware features bitmask using the contents of - * device-tree/ibm,hypertas-functions. Ultimately this functionality may - * be moved into prom.c prom_init(). - */ -static void __init fw_feature_init(void) -{ - struct device_node *dn; - char *hypertas, *s; - int len, i; - - DBG(" -> fw_feature_init()\n"); - - dn = of_find_node_by_path("/rtas"); - if (dn == NULL) { - printk(KERN_ERR "WARNING! Cannot find RTAS in device-tree!\n"); - goto out; - } - - hypertas = get_property(dn, "ibm,hypertas-functions", &len); - if (hypertas == NULL) - goto out; - - for (s = hypertas; s < hypertas + len; s += strlen(s) + 1) { - for (i = 0; i < FIRMWARE_MAX_FEATURES; i++) { - /* check value against table of strings */ - if (!firmware_features_table[i].name || - strcmp(firmware_features_table[i].name, s)) - continue; - - /* we have a match */ - ppc64_firmware_features |= - firmware_features_table[i].val; - break; - } - } - -out: - of_node_put(dn); - DBG(" <- fw_feature_init()\n"); -} - - static void __init pSeries_discover_pic(void) { struct device_node *np; Index: to-merge/include/asm-powerpc/firmware.h =================================================================== --- to-merge.orig/include/asm-powerpc/firmware.h +++ to-merge/include/asm-powerpc/firmware.h @@ -89,15 +89,6 @@ static inline unsigned long firmware_has (FW_FEATURE_POSSIBLE & ppc64_firmware_features & feature); } -#ifdef CONFIG_PPC_PSERIES -typedef struct { - unsigned long val; - char * name; -} firmware_feature_t; - -extern firmware_feature_t firmware_features_table[]; -#endif - extern void system_reset_fwnmi(void); extern void machine_check_fwnmi(void); Index: to-merge/arch/powerpc/platforms/pseries/firmware.h =================================================================== --- /dev/null +++ to-merge/arch/powerpc/platforms/pseries/firmware.h @@ -0,0 +1,17 @@ +/* + * Copyright 2006 IBM Corporation. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +#ifndef _PSERIES_FIRMWARE_H +#define _PSERIES_FIRMWARE_H + +#include + +extern void __init fw_feature_init(void); + +#endif /* _PSERIES_FIRMWARE_H */ From geoffrey.levand at am.sony.com Sat Feb 11 03:44:26 2006 From: geoffrey.levand at am.sony.com (Geoff Levand) Date: Fri, 10 Feb 2006 08:44:26 -0800 Subject: AW: Re: __setup_cpu_be problem In-Reply-To: <1139546116.5003.81.camel@localhost.localdomain> References: <2812322.110611139545275893.JavaMail.servlet@kundenserver> <1139546116.5003.81.camel@localhost.localdomain> Message-ID: <43ECC2EA.5040505@am.sony.com> Benjamin Herrenschmidt wrote: >> [/me is sing webmail from some distant location in .nz, sorry if >> the mail gets messed up] >> >> Doing it in the firmware sounds like the right solution to me. >> I would however not want to do that if the current firmware >> sets the wrong page sizes. Then we should consider support to change page sizes a firmware bug work-around. >> I know that Hartmut wanted me to provide him with the right device >> tree information that he needs to create to say that the page >> size are 16M, 64k and 4k. Maybe we can find a combined solution >> for these problems. Using __setup_cpu_power4 should be ok. > > I don't completely understand your statement ... sorry > >> We could probably do a fallback in the cell setup to see if >> the properties are in the device tree and do our own HID6 >> setup stuff if not, normally expecting that the firmware settings >> match the device tree. > > We should not touch HID6 at all ... we should assume the firmware set it > appropriately and have setup matching page size entries in the > device-tree. I don't think we need to support changing that value > especially since the kernel doesn't quite support 1M large page sizes > anyway. This seems reasonable. In the general case we shouldn't change the sizes. >> Ben, could you point Hartmut (and maybe Geoff) to the documentation >> for how the device tree needs to look like? > > I'm not sure we published that yet :) I would suggest looking at what > the kernel does to parse these instead in hash_utils.c until I get a > former IBM approval for the spec to be published It seems we can work with the info in hash_utils_64.c, but it would be good to get the documentation. -Geoff From ahuja at austin.ibm.com Sat Feb 11 07:45:08 2006 From: ahuja at austin.ibm.com (Manish Ahuja) Date: Fri, 10 Feb 2006 14:45:08 -0600 Subject: [PATCH] PPC64 collect and export low-level cpu usage statistics In-Reply-To: <43DFB67A.5080508@austin.ibm.com> References: <43CFC094.8000709@austin.ibm.com> <20060126204432.GG19465@austin.ibm.com> <43DFB67A.5080508@austin.ibm.com> Message-ID: <43ECFB54.9050907@austin.ibm.com> I have made some changes to the patch. I will drop another patch at a later date with enhancements and some modifications. At this point, I would like to resubmit this for review and forward if there are no further comments. Thanks, Manish Ahuja -------------------------------------------------------------------- The issue of correctness of time is an important one, where users would like to accurately get a feel for how the system is performing. With Virtualization and addition of abstract layers between the hardware and the OS, we have introduced changes that do not allow us to correctly measure performance or accuracy at this moment. Any activity at this moment that collects metrics is faced with the challenge of collecting values that might be bogus. POWER5 machines have a per-hardware-thread register which counts at a rate which is proportional to the percentage of cycles on which the cpu dispatches an instruction for this thread (if the thread gets all the dispatch cycles it counts at the same rate as the timebase register). This register is also context-switched by the hypervisor. Thus it gives a fine-grained measure of the actual cpu usage by the thread over time. This patch builds on a patch submitted earlier. This patch provides framework and data which allows other tools to report measurements accurately to different tools. This Patch calculates the amount of real physical time spent by the processor in each USER/SYS mode. It calculates that by trapping entry and exits into the kernel. The values after calculations are avilable from /sys/devices/system/cpu/cpuX/dispatched_cycles. These values are calculated during interrupts & context switches. To be able to correctly report all cycles, it is important to be able to track all the cycles that are given to lpars that are either offline or have been removed since the system started. All such cycles are calculated and stored in /sys/devices/system/cpu/cpuX/offline_cpu_cycles A few tools are in the works that will exploit the values being calculated. Example output look like as follows. %user %sys %wait %idle ------ ------ ------ ------ 00.90 0.09 0.00 99.01 This patch also keeps track of exact user/kernel times for each process and updates them accordingly to be used by tools like CKRM. I am working with performance group to calculate the impact of this patch. I will add those numbers as soon something becomes available. Signed-off-by: Manish Ahuja -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cpu_acct.patch.2 Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20060210/9d849630/attachment.txt From olof at lixom.net Sat Feb 11 10:23:25 2006 From: olof at lixom.net (Olof Johansson) Date: Fri, 10 Feb 2006 17:23:25 -0600 Subject: [PATCH] rename fw_feature_init() Message-ID: <20060210232325.GA4795@pb15.lixom.net> Hi, fw_feature_init() on pSeries is really just a setup of hypervisor features. Rename the function accordingly. Signed-off-by: Olof Johansson --- firmware.c | 18 +++++++++--------- firmware.h | 2 +- setup.c | 2 +- 3 files changed, 11 insertions(+), 11 deletions(-) Index: powerpc-git/arch/powerpc/platforms/pseries/firmware.c =================================================================== --- powerpc-git.orig/arch/powerpc/platforms/pseries/firmware.c +++ powerpc-git/arch/powerpc/platforms/pseries/firmware.c @@ -35,10 +35,10 @@ typedef struct { unsigned long val; char * name; -} firmware_feature_t; +} hypervisor_feature_t; -static __initdata firmware_feature_t -firmware_features_table[FIRMWARE_MAX_FEATURES] = { +static __initdata hypervisor_feature_t +hypervisor_features_table[FIRMWARE_MAX_FEATURES] = { {FW_FEATURE_PFT, "hcall-pft"}, {FW_FEATURE_TCE, "hcall-tce"}, {FW_FEATURE_SPRG0, "hcall-sprg0"}, @@ -65,13 +65,13 @@ firmware_features_table[FIRMWARE_MAX_FEA * device-tree/ibm,hypertas-functions. Ultimately this functionality may * be moved into prom.c prom_init(). */ -void __init fw_feature_init(void) +void __init hypervisor_feature_init(void) { struct device_node *dn; char *hypertas, *s; int len, i; - DBG(" -> fw_feature_init()\n"); + DBG(" -> hypervisor_feature_init()\n"); dn = of_find_node_by_path("/rtas"); if (dn == NULL) { @@ -86,18 +86,18 @@ void __init fw_feature_init(void) for (s = hypertas; s < hypertas + len; s += strlen(s) + 1) { for (i = 0; i < FIRMWARE_MAX_FEATURES; i++) { /* check value against table of strings */ - if (!firmware_features_table[i].name || - strcmp(firmware_features_table[i].name, s)) + if (!hypervisor_features_table[i].name || + strcmp(hypervisor_features_table[i].name, s)) continue; /* we have a match */ ppc64_firmware_features |= - firmware_features_table[i].val; + hypervisor_features_table[i].val; break; } } out: of_node_put(dn); - DBG(" <- fw_feature_init()\n"); + DBG(" <- hypervisor_feature_init()\n"); } Index: powerpc-git/arch/powerpc/platforms/pseries/firmware.h =================================================================== --- powerpc-git.orig/arch/powerpc/platforms/pseries/firmware.h +++ powerpc-git/arch/powerpc/platforms/pseries/firmware.h @@ -12,6 +12,6 @@ #include -extern void __init fw_feature_init(void); +extern void __init hypervisor_feature_init(void); #endif /* _PSERIES_FIRMWARE_H */ Index: powerpc-git/arch/powerpc/platforms/pseries/setup.c =================================================================== --- powerpc-git.orig/arch/powerpc/platforms/pseries/setup.c +++ powerpc-git/arch/powerpc/platforms/pseries/setup.c @@ -324,7 +324,7 @@ static void __init pSeries_init_early(vo DBG(" -> pSeries_init_early()\n"); - fw_feature_init(); + hypervisor_feature_init(); if (platform_is_lpar()) hpte_init_lpar(); From olof at lixom.net Sat Feb 11 10:49:03 2006 From: olof at lixom.net (Olof Johansson) Date: Fri, 10 Feb 2006 17:49:03 -0600 Subject: [PATCH] Update {g5,pseries,ppc64}_defconfig Message-ID: <20060210234903.GB4795@pb15.lixom.net> Hi, For powerpc.git (post-2.6.16): Update defconfigs for g5, pseries and generic ppc64. Default choices for everything, with the following exceptions: * Enable WINDFARM_PM112 on g5 and ppc64. * Increase CONFIG_NR_CPUS to 4 on g5_defconfig Signed-off-by: Olof Johansson Index: powerpc-git/arch/powerpc/configs/g5_defconfig =================================================================== --- powerpc-git.orig/arch/powerpc/configs/g5_defconfig +++ powerpc-git/arch/powerpc/configs/g5_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.15-rc5 -# Tue Dec 20 15:59:30 2005 +# Linux kernel version: 2.6.16-rc2 +# Fri Feb 10 17:33:08 2006 # CONFIG_PPC64=y CONFIG_64BIT=y @@ -16,6 +16,10 @@ CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y +CONFIG_PPC_OF=y +# CONFIG_PPC_UDBG_16550 is not set +CONFIG_GENERIC_TBSYNC=y +# CONFIG_DEFAULT_UIMAGE is not set # # Processor support @@ -26,13 +30,12 @@ CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y CONFIG_PPC_STD_MMU=y CONFIG_SMP=y -CONFIG_NR_CPUS=2 +CONFIG_NR_CPUS=4 # # Code maturity level options # CONFIG_EXPERIMENTAL=y -CONFIG_CLEAN_COMPILE=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 @@ -47,8 +50,6 @@ CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set -CONFIG_HOTPLUG=y -CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_CPUSETS is not set @@ -58,8 +59,10 @@ CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set +CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y +CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y @@ -68,8 +71,10 @@ CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 +CONFIG_SLAB=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 +# CONFIG_SLOB is not set # # Loadable module support @@ -112,13 +117,12 @@ CONFIG_PPC_PMAC=y CONFIG_PPC_PMAC64=y # CONFIG_PPC_MAPLE is not set # CONFIG_PPC_CELL is not set -CONFIG_PPC_OF=y CONFIG_U3_DART=y CONFIG_MPIC=y # CONFIG_PPC_RTAS is not set # CONFIG_MMIO_NVRAM is not set +CONFIG_MPIC_BROKEN_U3=y # CONFIG_PPC_MPC106 is not set -CONFIG_GENERIC_TBSYNC=y CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y # CONFIG_CPU_FREQ_DEBUG is not set @@ -151,6 +155,7 @@ CONFIG_FORCE_MAX_ZONEORDER=13 CONFIG_IOMMU_VMERGE=y # CONFIG_HOTPLUG_CPU is not set CONFIG_KEXEC=y +# CONFIG_CRASH_DUMP is not set CONFIG_IRQ_ALL_CPUS=y # CONFIG_NUMA is not set CONFIG_ARCH_SELECT_MEMORY_MODEL=y @@ -202,6 +207,7 @@ CONFIG_NET=y # # Networking options # +# CONFIG_NETDEBUG is not set CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_UNIX=y @@ -239,6 +245,7 @@ CONFIG_NETFILTER=y # Core Netfilter Configuration # # CONFIG_NETFILTER_NETLINK is not set +# CONFIG_NETFILTER_XTABLES is not set # # IP: Netfilter Configuration @@ -255,65 +262,6 @@ CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_AMANDA=m # CONFIG_IP_NF_PPTP is not set CONFIG_IP_NF_QUEUE=m -CONFIG_IP_NF_IPTABLES=m -CONFIG_IP_NF_MATCH_LIMIT=m -CONFIG_IP_NF_MATCH_IPRANGE=m -CONFIG_IP_NF_MATCH_MAC=m -CONFIG_IP_NF_MATCH_PKTTYPE=m -CONFIG_IP_NF_MATCH_MARK=m -CONFIG_IP_NF_MATCH_MULTIPORT=m -CONFIG_IP_NF_MATCH_TOS=m -CONFIG_IP_NF_MATCH_RECENT=m -CONFIG_IP_NF_MATCH_ECN=m -CONFIG_IP_NF_MATCH_DSCP=m -CONFIG_IP_NF_MATCH_AH_ESP=m -CONFIG_IP_NF_MATCH_LENGTH=m -CONFIG_IP_NF_MATCH_TTL=m -CONFIG_IP_NF_MATCH_TCPMSS=m -CONFIG_IP_NF_MATCH_HELPER=m -CONFIG_IP_NF_MATCH_STATE=m -CONFIG_IP_NF_MATCH_CONNTRACK=m -CONFIG_IP_NF_MATCH_OWNER=m -CONFIG_IP_NF_MATCH_ADDRTYPE=m -CONFIG_IP_NF_MATCH_REALM=m -CONFIG_IP_NF_MATCH_SCTP=m -# CONFIG_IP_NF_MATCH_DCCP is not set -CONFIG_IP_NF_MATCH_COMMENT=m -CONFIG_IP_NF_MATCH_CONNMARK=m -CONFIG_IP_NF_MATCH_CONNBYTES=m -CONFIG_IP_NF_MATCH_HASHLIMIT=m -CONFIG_IP_NF_MATCH_STRING=m -CONFIG_IP_NF_FILTER=m -CONFIG_IP_NF_TARGET_REJECT=m -CONFIG_IP_NF_TARGET_LOG=m -CONFIG_IP_NF_TARGET_ULOG=m -CONFIG_IP_NF_TARGET_TCPMSS=m -CONFIG_IP_NF_TARGET_NFQUEUE=m -CONFIG_IP_NF_NAT=m -CONFIG_IP_NF_NAT_NEEDED=y -CONFIG_IP_NF_TARGET_MASQUERADE=m -CONFIG_IP_NF_TARGET_REDIRECT=m -CONFIG_IP_NF_TARGET_NETMAP=m -CONFIG_IP_NF_TARGET_SAME=m -CONFIG_IP_NF_NAT_SNMP_BASIC=m -CONFIG_IP_NF_NAT_IRC=m -CONFIG_IP_NF_NAT_FTP=m -CONFIG_IP_NF_NAT_TFTP=m -CONFIG_IP_NF_NAT_AMANDA=m -CONFIG_IP_NF_MANGLE=m -CONFIG_IP_NF_TARGET_TOS=m -CONFIG_IP_NF_TARGET_ECN=m -CONFIG_IP_NF_TARGET_DSCP=m -CONFIG_IP_NF_TARGET_MARK=m -CONFIG_IP_NF_TARGET_CLASSIFY=m -CONFIG_IP_NF_TARGET_TTL=m -CONFIG_IP_NF_TARGET_CONNMARK=m -CONFIG_IP_NF_TARGET_CLUSTERIP=m -CONFIG_IP_NF_RAW=m -CONFIG_IP_NF_TARGET_NOTRACK=m -CONFIG_IP_NF_ARPTABLES=m -CONFIG_IP_NF_ARPFILTER=m -CONFIG_IP_NF_ARP_MANGLE=m # # DCCP Configuration (EXPERIMENTAL) @@ -324,6 +272,11 @@ CONFIG_IP_NF_ARP_MANGLE=m # SCTP Configuration (EXPERIMENTAL) # # CONFIG_IP_SCTP is not set + +# +# TIPC Configuration (EXPERIMENTAL) +# +# CONFIG_TIPC is not set # CONFIG_ATM is not set # CONFIG_BRIDGE is not set # CONFIG_VLAN_8021Q is not set @@ -342,7 +295,6 @@ CONFIG_LLC=y # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set -CONFIG_NET_CLS_ROUTE=y # # Network testing @@ -545,13 +497,7 @@ CONFIG_SCSI_SATA_SVW=y # CONFIG_SCSI_IPR is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set -CONFIG_SCSI_QLA2XXX=y -# CONFIG_SCSI_QLA21XX is not set -# CONFIG_SCSI_QLA22XX is not set -# CONFIG_SCSI_QLA2300 is not set -# CONFIG_SCSI_QLA2322 is not set -# CONFIG_SCSI_QLA6312 is not set -# CONFIG_SCSI_QLA24XX is not set +# CONFIG_SCSI_QLA_FC is not set # CONFIG_SCSI_LPFC is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set @@ -614,7 +560,6 @@ CONFIG_IEEE1394_SBP2=m CONFIG_IEEE1394_ETH1394=m CONFIG_IEEE1394_DV1394=m CONFIG_IEEE1394_RAWIO=y -# CONFIG_IEEE1394_CMP is not set # # I2O device support @@ -630,6 +575,7 @@ CONFIG_THERM_PM72=y CONFIG_WINDFARM=y CONFIG_WINDFARM_PM81=y CONFIG_WINDFARM_PM91=y +CONFIG_WINDFARM_PM112=y # # Network device support @@ -682,6 +628,7 @@ CONFIG_E1000=y # CONFIG_R8169 is not set # CONFIG_SIS190 is not set # CONFIG_SKGE is not set +# CONFIG_SKY2 is not set # CONFIG_SK98LIN is not set CONFIG_TIGON3=m # CONFIG_BNX2 is not set @@ -861,8 +808,7 @@ CONFIG_I2C_ALGOBIT=y # CONFIG_I2C_I801 is not set # CONFIG_I2C_I810 is not set # CONFIG_I2C_PIIX4 is not set -CONFIG_I2C_KEYWEST=y -CONFIG_I2C_PMAC_SMU=y +CONFIG_I2C_POWERMAC=y # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_PROSAVAGE is not set @@ -895,6 +841,12 @@ CONFIG_I2C_PMAC_SMU=y # CONFIG_I2C_DEBUG_CHIP is not set # +# SPI support +# +# CONFIG_SPI is not set +# CONFIG_SPI_MASTER is not set + +# # Dallas's 1-wire bus # # CONFIG_W1 is not set @@ -961,7 +913,6 @@ CONFIG_FB_RADEON_I2C=y # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set -# CONFIG_FB_CYBLA is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_VIRTUAL is not set @@ -1008,9 +959,10 @@ CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_SEQUENCER_OSS=y +# CONFIG_SND_DYNAMIC_MINORS is not set +CONFIG_SND_SUPPORT_OLD_API=y # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set -CONFIG_SND_GENERIC_DRIVER=y # # Generic devices @@ -1024,6 +976,8 @@ CONFIG_SND_GENERIC_DRIVER=y # # PCI devices # +# CONFIG_SND_AD1889 is not set +# CONFIG_SND_ALS4000 is not set # CONFIG_SND_ALI5451 is not set # CONFIG_SND_ATIIXP is not set # CONFIG_SND_ATIIXP_MODEM is not set @@ -1032,39 +986,38 @@ CONFIG_SND_GENERIC_DRIVER=y # CONFIG_SND_AU8830 is not set # CONFIG_SND_AZT3328 is not set # CONFIG_SND_BT87X is not set -# CONFIG_SND_CS46XX is not set +# CONFIG_SND_CA0106 is not set +# CONFIG_SND_CMIPCI is not set # CONFIG_SND_CS4281 is not set +# CONFIG_SND_CS46XX is not set # CONFIG_SND_EMU10K1 is not set # CONFIG_SND_EMU10K1X is not set -# CONFIG_SND_CA0106 is not set -# CONFIG_SND_KORG1212 is not set -# CONFIG_SND_MIXART is not set -# CONFIG_SND_NM256 is not set -# CONFIG_SND_RME32 is not set -# CONFIG_SND_RME96 is not set -# CONFIG_SND_RME9652 is not set -# CONFIG_SND_HDSP is not set -# CONFIG_SND_HDSPM is not set -# CONFIG_SND_TRIDENT is not set -# CONFIG_SND_YMFPCI is not set -# CONFIG_SND_AD1889 is not set -# CONFIG_SND_ALS4000 is not set -# CONFIG_SND_CMIPCI is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set -# CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_FM801 is not set +# CONFIG_SND_HDA_INTEL is not set +# CONFIG_SND_HDSP is not set +# CONFIG_SND_HDSPM is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set # CONFIG_SND_INTEL8X0 is not set # CONFIG_SND_INTEL8X0M is not set +# CONFIG_SND_KORG1212 is not set +# CONFIG_SND_MAESTRO3 is not set +# CONFIG_SND_MIXART is not set +# CONFIG_SND_NM256 is not set +# CONFIG_SND_PCXHR is not set +# CONFIG_SND_RME32 is not set +# CONFIG_SND_RME96 is not set +# CONFIG_SND_RME9652 is not set # CONFIG_SND_SONICVIBES is not set +# CONFIG_SND_TRIDENT is not set # CONFIG_SND_VIA82XX is not set # CONFIG_SND_VIA82XX_MODEM is not set # CONFIG_SND_VX222 is not set -# CONFIG_SND_HDA_INTEL is not set +# CONFIG_SND_YMFPCI is not set # # ALSA PowerMac devices @@ -1136,13 +1089,16 @@ CONFIG_USB_STORAGE_DPCM=y CONFIG_USB_STORAGE_SDDR09=y CONFIG_USB_STORAGE_SDDR55=y CONFIG_USB_STORAGE_JUMPSHOT=y +# CONFIG_USB_STORAGE_ALAUDA is not set # CONFIG_USB_STORAGE_ONETOUCH is not set +# CONFIG_USB_LIBUSUAL is not set # # USB Input Devices # CONFIG_USB_HID=y CONFIG_USB_HIDINPUT=y +# CONFIG_USB_HIDINPUT_POWERBOOK is not set CONFIG_HID_FF=y CONFIG_HID_PID=y CONFIG_LOGITECH_FF=y @@ -1159,6 +1115,7 @@ CONFIG_USB_HIDDEV=y # CONFIG_USB_YEALINK is not set # CONFIG_USB_XPAD is not set # CONFIG_USB_ATI_REMOTE is not set +# CONFIG_USB_ATI_REMOTE2 is not set # CONFIG_USB_KEYSPAN_REMOTE is not set # CONFIG_USB_APPLETOUCH is not set @@ -1207,6 +1164,7 @@ CONFIG_USB_SERIAL_GENERIC=y # CONFIG_USB_SERIAL_AIRPRIME is not set # CONFIG_USB_SERIAL_ANYDATA is not set CONFIG_USB_SERIAL_BELKIN=m +# CONFIG_USB_SERIAL_WHITEHEAT is not set CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m # CONFIG_USB_SERIAL_CP2101 is not set CONFIG_USB_SERIAL_CYPRESS_M8=m @@ -1288,6 +1246,10 @@ CONFIG_USB_EZUSB=y # # +# EDAC - error detection and reporting (RAS) +# + +# # File systems # CONFIG_EXT2_FS=y @@ -1317,6 +1279,7 @@ CONFIG_XFS_EXPORT=y CONFIG_XFS_SECURITY=y CONFIG_XFS_POSIX_ACL=y # CONFIG_XFS_RT is not set +# CONFIG_OCFS2_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_ROMFS_FS is not set CONFIG_INOTIFY=y @@ -1357,6 +1320,7 @@ CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y CONFIG_RAMFS=y # CONFIG_RELAYFS_FS is not set +# CONFIG_CONFIGFS_FS is not set # # Miscellaneous filesystems @@ -1426,6 +1390,7 @@ CONFIG_MSDOS_PARTITION=y # CONFIG_SGI_PARTITION is not set # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set +# CONFIG_KARMA_PARTITION is not set # CONFIG_EFI_PARTITION is not set # @@ -1481,10 +1446,6 @@ CONFIG_CRC32=y CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=m -CONFIG_TEXTSEARCH=y -CONFIG_TEXTSEARCH_KMP=m -CONFIG_TEXTSEARCH_BM=m -CONFIG_TEXTSEARCH_FSM=m # # Instrumentation Support @@ -1497,24 +1458,31 @@ CONFIG_OPROFILE=y # Kernel hacking # # CONFIG_PRINTK_TIME is not set -CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y +CONFIG_DEBUG_KERNEL=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_DETECT_SOFTLOCKUP=y # CONFIG_SCHEDSTATS is not set # CONFIG_DEBUG_SLAB is not set +CONFIG_DEBUG_MUTEXES=y # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_INFO is not set CONFIG_DEBUG_FS=y # CONFIG_DEBUG_VM is not set +CONFIG_FORCED_INLINING=y # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUGGER is not set CONFIG_IRQSTACKS=y CONFIG_BOOTX_TEXT=y +# CONFIG_PPC_EARLY_DEBUG_LPAR is not set +# CONFIG_PPC_EARLY_DEBUG_G5 is not set +# CONFIG_PPC_EARLY_DEBUG_RTAS is not set +# CONFIG_PPC_EARLY_DEBUG_MAPLE is not set +# CONFIG_PPC_EARLY_DEBUG_ISERIES is not set # # Security options Index: powerpc-git/arch/powerpc/configs/ppc64_defconfig =================================================================== --- powerpc-git.orig/arch/powerpc/configs/ppc64_defconfig +++ powerpc-git/arch/powerpc/configs/ppc64_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.15-rc5 -# Tue Dec 20 15:59:38 2005 +# Linux kernel version: 2.6.16-rc2 +# Fri Feb 10 17:32:14 2006 # CONFIG_PPC64=y CONFIG_64BIT=y @@ -16,6 +16,10 @@ CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y +CONFIG_PPC_OF=y +CONFIG_PPC_UDBG_16550=y +CONFIG_GENERIC_TBSYNC=y +# CONFIG_DEFAULT_UIMAGE is not set # # Processor support @@ -33,7 +37,6 @@ CONFIG_NR_CPUS=32 # Code maturity level options # CONFIG_EXPERIMENTAL=y -CONFIG_CLEAN_COMPILE=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 @@ -48,8 +51,6 @@ CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set -CONFIG_HOTPLUG=y -CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_CPUSETS=y @@ -59,8 +60,10 @@ CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set +CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y +CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y @@ -69,8 +72,10 @@ CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 +CONFIG_SLAB=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 +# CONFIG_SLOB is not set # # Loadable module support @@ -113,7 +118,6 @@ CONFIG_PPC_PMAC=y CONFIG_PPC_PMAC64=y CONFIG_PPC_MAPLE=y # CONFIG_PPC_CELL is not set -CONFIG_PPC_OF=y CONFIG_XICS=y CONFIG_U3_DART=y CONFIG_MPIC=y @@ -124,8 +128,8 @@ CONFIG_RTAS_FLASH=m # CONFIG_MMIO_NVRAM is not set CONFIG_MPIC_BROKEN_U3=y CONFIG_IBMVIO=y +# CONFIG_IBMEBUS is not set # CONFIG_PPC_MPC106 is not set -CONFIG_GENERIC_TBSYNC=y CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y # CONFIG_CPU_FREQ_DEBUG is not set @@ -158,6 +162,7 @@ CONFIG_FORCE_MAX_ZONEORDER=13 CONFIG_IOMMU_VMERGE=y CONFIG_HOTPLUG_CPU=y CONFIG_KEXEC=y +# CONFIG_CRASH_DUMP is not set CONFIG_IRQ_ALL_CPUS=y CONFIG_PPC_SPLPAR=y CONFIG_EEH=y @@ -178,6 +183,7 @@ CONFIG_HAVE_MEMORY_PRESENT=y CONFIG_SPARSEMEM_EXTREME=y # CONFIG_MEMORY_HOTPLUG is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +CONFIG_MIGRATION=y # CONFIG_PPC_64K_PAGES is not set # CONFIG_SCHED_SMT is not set CONFIG_PROC_DEVICETREE=y @@ -221,6 +227,7 @@ CONFIG_NET=y # # Networking options # +# CONFIG_NETDEBUG is not set CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_UNIX=y @@ -260,6 +267,7 @@ CONFIG_NETFILTER=y CONFIG_NETFILTER_NETLINK=y CONFIG_NETFILTER_NETLINK_QUEUE=m CONFIG_NETFILTER_NETLINK_LOG=m +# CONFIG_NETFILTER_XTABLES is not set # # IP: Netfilter Configuration @@ -277,65 +285,6 @@ CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_AMANDA=m # CONFIG_IP_NF_PPTP is not set CONFIG_IP_NF_QUEUE=m -CONFIG_IP_NF_IPTABLES=m -CONFIG_IP_NF_MATCH_LIMIT=m -CONFIG_IP_NF_MATCH_IPRANGE=m -CONFIG_IP_NF_MATCH_MAC=m -CONFIG_IP_NF_MATCH_PKTTYPE=m -CONFIG_IP_NF_MATCH_MARK=m -CONFIG_IP_NF_MATCH_MULTIPORT=m -CONFIG_IP_NF_MATCH_TOS=m -CONFIG_IP_NF_MATCH_RECENT=m -CONFIG_IP_NF_MATCH_ECN=m -CONFIG_IP_NF_MATCH_DSCP=m -CONFIG_IP_NF_MATCH_AH_ESP=m -CONFIG_IP_NF_MATCH_LENGTH=m -CONFIG_IP_NF_MATCH_TTL=m -CONFIG_IP_NF_MATCH_TCPMSS=m -CONFIG_IP_NF_MATCH_HELPER=m -CONFIG_IP_NF_MATCH_STATE=m -CONFIG_IP_NF_MATCH_CONNTRACK=m -CONFIG_IP_NF_MATCH_OWNER=m -CONFIG_IP_NF_MATCH_ADDRTYPE=m -CONFIG_IP_NF_MATCH_REALM=m -CONFIG_IP_NF_MATCH_SCTP=m -CONFIG_IP_NF_MATCH_DCCP=m -CONFIG_IP_NF_MATCH_COMMENT=m -CONFIG_IP_NF_MATCH_CONNMARK=m -CONFIG_IP_NF_MATCH_CONNBYTES=m -CONFIG_IP_NF_MATCH_HASHLIMIT=m -CONFIG_IP_NF_MATCH_STRING=m -CONFIG_IP_NF_FILTER=m -CONFIG_IP_NF_TARGET_REJECT=m -CONFIG_IP_NF_TARGET_LOG=m -CONFIG_IP_NF_TARGET_ULOG=m -CONFIG_IP_NF_TARGET_TCPMSS=m -CONFIG_IP_NF_TARGET_NFQUEUE=m -CONFIG_IP_NF_NAT=m -CONFIG_IP_NF_NAT_NEEDED=y -CONFIG_IP_NF_TARGET_MASQUERADE=m -CONFIG_IP_NF_TARGET_REDIRECT=m -CONFIG_IP_NF_TARGET_NETMAP=m -CONFIG_IP_NF_TARGET_SAME=m -CONFIG_IP_NF_NAT_SNMP_BASIC=m -CONFIG_IP_NF_NAT_IRC=m -CONFIG_IP_NF_NAT_FTP=m -CONFIG_IP_NF_NAT_TFTP=m -CONFIG_IP_NF_NAT_AMANDA=m -CONFIG_IP_NF_MANGLE=m -CONFIG_IP_NF_TARGET_TOS=m -CONFIG_IP_NF_TARGET_ECN=m -CONFIG_IP_NF_TARGET_DSCP=m -CONFIG_IP_NF_TARGET_MARK=m -CONFIG_IP_NF_TARGET_CLASSIFY=m -CONFIG_IP_NF_TARGET_TTL=m -CONFIG_IP_NF_TARGET_CONNMARK=m -CONFIG_IP_NF_TARGET_CLUSTERIP=m -CONFIG_IP_NF_RAW=m -CONFIG_IP_NF_TARGET_NOTRACK=m -CONFIG_IP_NF_ARPTABLES=m -CONFIG_IP_NF_ARPFILTER=m -CONFIG_IP_NF_ARP_MANGLE=m # # DCCP Configuration (EXPERIMENTAL) @@ -346,6 +295,11 @@ CONFIG_IP_NF_ARP_MANGLE=m # SCTP Configuration (EXPERIMENTAL) # # CONFIG_IP_SCTP is not set + +# +# TIPC Configuration (EXPERIMENTAL) +# +# CONFIG_TIPC is not set # CONFIG_ATM is not set # CONFIG_BRIDGE is not set # CONFIG_VLAN_8021Q is not set @@ -364,7 +318,6 @@ CONFIG_LLC=y # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set -CONFIG_NET_CLS_ROUTE=y # # Network testing @@ -572,13 +525,7 @@ CONFIG_SCSI_IPR_TRACE=y CONFIG_SCSI_IPR_DUMP=y # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set -CONFIG_SCSI_QLA2XXX=y -CONFIG_SCSI_QLA21XX=m -CONFIG_SCSI_QLA22XX=m -CONFIG_SCSI_QLA2300=m -CONFIG_SCSI_QLA2322=m -CONFIG_SCSI_QLA6312=m -CONFIG_SCSI_QLA24XX=m +# CONFIG_SCSI_QLA_FC is not set CONFIG_SCSI_LPFC=m # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set @@ -642,8 +589,6 @@ CONFIG_IEEE1394_SBP2=m CONFIG_IEEE1394_ETH1394=m CONFIG_IEEE1394_DV1394=m CONFIG_IEEE1394_RAWIO=y -CONFIG_IEEE1394_CMP=m -CONFIG_IEEE1394_AMDTP=m # # I2O device support @@ -659,6 +604,7 @@ CONFIG_THERM_PM72=y CONFIG_WINDFARM=y CONFIG_WINDFARM_PM81=y CONFIG_WINDFARM_PM91=y +CONFIG_WINDFARM_PM112=y # # Network device support @@ -731,6 +677,7 @@ CONFIG_E1000=y # CONFIG_R8169 is not set # CONFIG_SIS190 is not set # CONFIG_SKGE is not set +# CONFIG_SKY2 is not set # CONFIG_SK98LIN is not set # CONFIG_VIA_VELOCITY is not set CONFIG_TIGON3=y @@ -853,6 +800,7 @@ CONFIG_HW_CONSOLE=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_NR_UARTS=4 +CONFIG_SERIAL_8250_RUNTIME_UARTS=4 # CONFIG_SERIAL_8250_EXTENDED is not set # @@ -880,6 +828,7 @@ CONFIG_HVCS=m # CONFIG_WATCHDOG is not set # CONFIG_RTC is not set CONFIG_GEN_RTC=y +# CONFIG_GEN_RTC_X is not set # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set @@ -923,8 +872,7 @@ CONFIG_I2C_AMD8111=y # CONFIG_I2C_I801 is not set # CONFIG_I2C_I810 is not set # CONFIG_I2C_PIIX4 is not set -CONFIG_I2C_KEYWEST=y -CONFIG_I2C_PMAC_SMU=y +CONFIG_I2C_POWERMAC=y # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_PROSAVAGE is not set @@ -957,6 +905,12 @@ CONFIG_I2C_PMAC_SMU=y # CONFIG_I2C_DEBUG_CHIP is not set # +# SPI support +# +# CONFIG_SPI is not set +# CONFIG_SPI_MASTER is not set + +# # Dallas's 1-wire bus # # CONFIG_W1 is not set @@ -1028,7 +982,6 @@ CONFIG_FB_RADEON_I2C=y # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set -# CONFIG_FB_CYBLA is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_VIRTUAL is not set @@ -1073,9 +1026,10 @@ CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_SEQUENCER_OSS=y +# CONFIG_SND_DYNAMIC_MINORS is not set +CONFIG_SND_SUPPORT_OLD_API=y # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set -CONFIG_SND_GENERIC_DRIVER=y # # Generic devices @@ -1089,6 +1043,8 @@ CONFIG_SND_GENERIC_DRIVER=y # # PCI devices # +# CONFIG_SND_AD1889 is not set +# CONFIG_SND_ALS4000 is not set # CONFIG_SND_ALI5451 is not set # CONFIG_SND_ATIIXP is not set # CONFIG_SND_ATIIXP_MODEM is not set @@ -1097,39 +1053,38 @@ CONFIG_SND_GENERIC_DRIVER=y # CONFIG_SND_AU8830 is not set # CONFIG_SND_AZT3328 is not set # CONFIG_SND_BT87X is not set -# CONFIG_SND_CS46XX is not set +# CONFIG_SND_CA0106 is not set +# CONFIG_SND_CMIPCI is not set # CONFIG_SND_CS4281 is not set +# CONFIG_SND_CS46XX is not set # CONFIG_SND_EMU10K1 is not set # CONFIG_SND_EMU10K1X is not set -# CONFIG_SND_CA0106 is not set -# CONFIG_SND_KORG1212 is not set -# CONFIG_SND_MIXART is not set -# CONFIG_SND_NM256 is not set -# CONFIG_SND_RME32 is not set -# CONFIG_SND_RME96 is not set -# CONFIG_SND_RME9652 is not set -# CONFIG_SND_HDSP is not set -# CONFIG_SND_HDSPM is not set -# CONFIG_SND_TRIDENT is not set -# CONFIG_SND_YMFPCI is not set -# CONFIG_SND_AD1889 is not set -# CONFIG_SND_ALS4000 is not set -# CONFIG_SND_CMIPCI is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set -# CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_FM801 is not set +# CONFIG_SND_HDA_INTEL is not set +# CONFIG_SND_HDSP is not set +# CONFIG_SND_HDSPM is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set # CONFIG_SND_INTEL8X0 is not set # CONFIG_SND_INTEL8X0M is not set +# CONFIG_SND_KORG1212 is not set +# CONFIG_SND_MAESTRO3 is not set +# CONFIG_SND_MIXART is not set +# CONFIG_SND_NM256 is not set +# CONFIG_SND_PCXHR is not set +# CONFIG_SND_RME32 is not set +# CONFIG_SND_RME96 is not set +# CONFIG_SND_RME9652 is not set # CONFIG_SND_SONICVIBES is not set +# CONFIG_SND_TRIDENT is not set # CONFIG_SND_VIA82XX is not set # CONFIG_SND_VIA82XX_MODEM is not set # CONFIG_SND_VX222 is not set -# CONFIG_SND_HDA_INTEL is not set +# CONFIG_SND_YMFPCI is not set # # ALSA PowerMac devices @@ -1201,13 +1156,16 @@ CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set +# CONFIG_USB_STORAGE_ALAUDA is not set # CONFIG_USB_STORAGE_ONETOUCH is not set +# CONFIG_USB_LIBUSUAL is not set # # USB Input Devices # CONFIG_USB_HID=y CONFIG_USB_HIDINPUT=y +# CONFIG_USB_HIDINPUT_POWERBOOK is not set # CONFIG_HID_FF is not set CONFIG_USB_HIDDEV=y # CONFIG_USB_AIPTEK is not set @@ -1221,6 +1179,7 @@ CONFIG_USB_HIDDEV=y # CONFIG_USB_YEALINK is not set # CONFIG_USB_XPAD is not set # CONFIG_USB_ATI_REMOTE is not set +# CONFIG_USB_ATI_REMOTE2 is not set # CONFIG_USB_KEYSPAN_REMOTE is not set # CONFIG_USB_APPLETOUCH is not set @@ -1307,6 +1266,10 @@ CONFIG_INFINIBAND_IPOIB=m # # +# EDAC - error detection and reporting (RAS) +# + +# # File systems # CONFIG_EXT2_FS=y @@ -1340,6 +1303,7 @@ CONFIG_XFS_EXPORT=y CONFIG_XFS_SECURITY=y CONFIG_XFS_POSIX_ACL=y # CONFIG_XFS_RT is not set +# CONFIG_OCFS2_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_ROMFS_FS is not set CONFIG_INOTIFY=y @@ -1379,6 +1343,7 @@ CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y CONFIG_RAMFS=y # CONFIG_RELAYFS_FS is not set +# CONFIG_CONFIGFS_FS is not set # # Miscellaneous filesystems @@ -1449,6 +1414,7 @@ CONFIG_MSDOS_PARTITION=y # CONFIG_SGI_PARTITION is not set # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set +# CONFIG_KARMA_PARTITION is not set # CONFIG_EFI_PARTITION is not set # @@ -1504,10 +1470,6 @@ CONFIG_CRC32=y CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=m -CONFIG_TEXTSEARCH=y -CONFIG_TEXTSEARCH_KMP=m -CONFIG_TEXTSEARCH_BM=m -CONFIG_TEXTSEARCH_FSM=m # # Instrumentation Support @@ -1520,18 +1482,20 @@ CONFIG_OPROFILE=y # Kernel hacking # # CONFIG_PRINTK_TIME is not set -CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y +CONFIG_DEBUG_KERNEL=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_DETECT_SOFTLOCKUP=y # CONFIG_SCHEDSTATS is not set # CONFIG_DEBUG_SLAB is not set +CONFIG_DEBUG_MUTEXES=y # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_INFO is not set CONFIG_DEBUG_FS=y # CONFIG_DEBUG_VM is not set +CONFIG_FORCED_INLINING=y # CONFIG_RCU_TORTURE_TEST is not set CONFIG_DEBUG_STACKOVERFLOW=y CONFIG_DEBUG_STACK_USAGE=y @@ -1540,6 +1504,11 @@ CONFIG_XMON=y # CONFIG_XMON_DEFAULT is not set CONFIG_IRQSTACKS=y CONFIG_BOOTX_TEXT=y +# CONFIG_PPC_EARLY_DEBUG_LPAR is not set +# CONFIG_PPC_EARLY_DEBUG_G5 is not set +# CONFIG_PPC_EARLY_DEBUG_RTAS is not set +# CONFIG_PPC_EARLY_DEBUG_MAPLE is not set +# CONFIG_PPC_EARLY_DEBUG_ISERIES is not set # # Security options Index: powerpc-git/arch/powerpc/configs/pseries_defconfig =================================================================== --- powerpc-git.orig/arch/powerpc/configs/pseries_defconfig +++ powerpc-git/arch/powerpc/configs/pseries_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.15-rc5 -# Tue Dec 20 15:59:40 2005 +# Linux kernel version: 2.6.16-rc2 +# Fri Feb 10 17:33:32 2006 # CONFIG_PPC64=y CONFIG_64BIT=y @@ -16,6 +16,10 @@ CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y +CONFIG_PPC_OF=y +CONFIG_PPC_UDBG_16550=y +# CONFIG_GENERIC_TBSYNC is not set +# CONFIG_DEFAULT_UIMAGE is not set # # Processor support @@ -33,7 +37,6 @@ CONFIG_NR_CPUS=128 # Code maturity level options # CONFIG_EXPERIMENTAL=y -CONFIG_CLEAN_COMPILE=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 @@ -49,8 +52,6 @@ CONFIG_POSIX_MQUEUE=y CONFIG_SYSCTL=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y -CONFIG_HOTPLUG=y -CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_CPUSETS=y @@ -60,8 +61,10 @@ CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set +CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y +CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y @@ -70,8 +73,10 @@ CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 +CONFIG_SLAB=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 +# CONFIG_SLOB is not set # # Loadable module support @@ -113,7 +118,6 @@ CONFIG_PPC_PSERIES=y # CONFIG_PPC_PMAC is not set # CONFIG_PPC_MAPLE is not set # CONFIG_PPC_CELL is not set -CONFIG_PPC_OF=y CONFIG_XICS=y # CONFIG_U3_DART is not set CONFIG_MPIC=y @@ -123,8 +127,8 @@ CONFIG_RTAS_PROC=y CONFIG_RTAS_FLASH=m # CONFIG_MMIO_NVRAM is not set CONFIG_IBMVIO=y +# CONFIG_IBMEBUS is not set # CONFIG_PPC_MPC106 is not set -# CONFIG_GENERIC_TBSYNC is not set # CONFIG_CPU_FREQ is not set # CONFIG_WANT_EARLY_SERIAL is not set @@ -145,6 +149,7 @@ CONFIG_FORCE_MAX_ZONEORDER=13 CONFIG_IOMMU_VMERGE=y CONFIG_HOTPLUG_CPU=y CONFIG_KEXEC=y +# CONFIG_CRASH_DUMP is not set CONFIG_IRQ_ALL_CPUS=y CONFIG_PPC_SPLPAR=y CONFIG_EEH=y @@ -165,6 +170,7 @@ CONFIG_HAVE_MEMORY_PRESENT=y CONFIG_SPARSEMEM_EXTREME=y # CONFIG_MEMORY_HOTPLUG is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +CONFIG_MIGRATION=y CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y # CONFIG_PPC_64K_PAGES is not set CONFIG_SCHED_SMT=y @@ -209,6 +215,7 @@ CONFIG_NET=y # # Networking options # +# CONFIG_NETDEBUG is not set CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_UNIX=y @@ -248,6 +255,7 @@ CONFIG_NETFILTER=y CONFIG_NETFILTER_NETLINK=y CONFIG_NETFILTER_NETLINK_QUEUE=m CONFIG_NETFILTER_NETLINK_LOG=m +# CONFIG_NETFILTER_XTABLES is not set # # IP: Netfilter Configuration @@ -265,65 +273,6 @@ CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_AMANDA=m # CONFIG_IP_NF_PPTP is not set CONFIG_IP_NF_QUEUE=m -CONFIG_IP_NF_IPTABLES=m -CONFIG_IP_NF_MATCH_LIMIT=m -CONFIG_IP_NF_MATCH_IPRANGE=m -CONFIG_IP_NF_MATCH_MAC=m -CONFIG_IP_NF_MATCH_PKTTYPE=m -CONFIG_IP_NF_MATCH_MARK=m -CONFIG_IP_NF_MATCH_MULTIPORT=m -CONFIG_IP_NF_MATCH_TOS=m -CONFIG_IP_NF_MATCH_RECENT=m -CONFIG_IP_NF_MATCH_ECN=m -CONFIG_IP_NF_MATCH_DSCP=m -CONFIG_IP_NF_MATCH_AH_ESP=m -CONFIG_IP_NF_MATCH_LENGTH=m -CONFIG_IP_NF_MATCH_TTL=m -CONFIG_IP_NF_MATCH_TCPMSS=m -CONFIG_IP_NF_MATCH_HELPER=m -CONFIG_IP_NF_MATCH_STATE=m -CONFIG_IP_NF_MATCH_CONNTRACK=m -CONFIG_IP_NF_MATCH_OWNER=m -CONFIG_IP_NF_MATCH_ADDRTYPE=m -CONFIG_IP_NF_MATCH_REALM=m -CONFIG_IP_NF_MATCH_SCTP=m -# CONFIG_IP_NF_MATCH_DCCP is not set -CONFIG_IP_NF_MATCH_COMMENT=m -CONFIG_IP_NF_MATCH_CONNMARK=m -CONFIG_IP_NF_MATCH_CONNBYTES=m -CONFIG_IP_NF_MATCH_HASHLIMIT=m -CONFIG_IP_NF_MATCH_STRING=m -CONFIG_IP_NF_FILTER=m -CONFIG_IP_NF_TARGET_REJECT=m -CONFIG_IP_NF_TARGET_LOG=m -CONFIG_IP_NF_TARGET_ULOG=m -CONFIG_IP_NF_TARGET_TCPMSS=m -CONFIG_IP_NF_TARGET_NFQUEUE=m -CONFIG_IP_NF_NAT=m -CONFIG_IP_NF_NAT_NEEDED=y -CONFIG_IP_NF_TARGET_MASQUERADE=m -CONFIG_IP_NF_TARGET_REDIRECT=m -CONFIG_IP_NF_TARGET_NETMAP=m -CONFIG_IP_NF_TARGET_SAME=m -CONFIG_IP_NF_NAT_SNMP_BASIC=m -CONFIG_IP_NF_NAT_IRC=m -CONFIG_IP_NF_NAT_FTP=m -CONFIG_IP_NF_NAT_TFTP=m -CONFIG_IP_NF_NAT_AMANDA=m -CONFIG_IP_NF_MANGLE=m -CONFIG_IP_NF_TARGET_TOS=m -CONFIG_IP_NF_TARGET_ECN=m -CONFIG_IP_NF_TARGET_DSCP=m -CONFIG_IP_NF_TARGET_MARK=m -CONFIG_IP_NF_TARGET_CLASSIFY=m -CONFIG_IP_NF_TARGET_TTL=m -CONFIG_IP_NF_TARGET_CONNMARK=m -CONFIG_IP_NF_TARGET_CLUSTERIP=m -CONFIG_IP_NF_RAW=m -CONFIG_IP_NF_TARGET_NOTRACK=m -CONFIG_IP_NF_ARPTABLES=m -CONFIG_IP_NF_ARPFILTER=m -CONFIG_IP_NF_ARP_MANGLE=m # # DCCP Configuration (EXPERIMENTAL) @@ -334,6 +283,11 @@ CONFIG_IP_NF_ARP_MANGLE=m # SCTP Configuration (EXPERIMENTAL) # # CONFIG_IP_SCTP is not set + +# +# TIPC Configuration (EXPERIMENTAL) +# +# CONFIG_TIPC is not set # CONFIG_ATM is not set # CONFIG_BRIDGE is not set # CONFIG_VLAN_8021Q is not set @@ -352,7 +306,6 @@ CONFIG_LLC=y # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set -CONFIG_NET_CLS_ROUTE=y # # Network testing @@ -550,13 +503,7 @@ CONFIG_SCSI_IPR_TRACE=y CONFIG_SCSI_IPR_DUMP=y # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set -CONFIG_SCSI_QLA2XXX=y -CONFIG_SCSI_QLA21XX=m -CONFIG_SCSI_QLA22XX=m -CONFIG_SCSI_QLA2300=m -CONFIG_SCSI_QLA2322=m -CONFIG_SCSI_QLA6312=m -CONFIG_SCSI_QLA24XX=m +# CONFIG_SCSI_QLA_FC is not set CONFIG_SCSI_LPFC=m # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set @@ -678,6 +625,7 @@ CONFIG_E1000=y # CONFIG_R8169 is not set # CONFIG_SIS190 is not set # CONFIG_SKGE is not set +# CONFIG_SKY2 is not set # CONFIG_SK98LIN is not set # CONFIG_VIA_VELOCITY is not set CONFIG_TIGON3=y @@ -803,6 +751,7 @@ CONFIG_HW_CONSOLE=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_NR_UARTS=4 +CONFIG_SERIAL_8250_RUNTIME_UARTS=4 # CONFIG_SERIAL_8250_EXTENDED is not set # @@ -909,6 +858,12 @@ CONFIG_I2C_ALGOBIT=y # CONFIG_I2C_DEBUG_CHIP is not set # +# SPI support +# +# CONFIG_SPI is not set +# CONFIG_SPI_MASTER is not set + +# # Dallas's 1-wire bus # # CONFIG_W1 is not set @@ -976,7 +931,6 @@ CONFIG_FB_RADEON_I2C=y # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set -# CONFIG_FB_CYBLA is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_VIRTUAL is not set @@ -1061,12 +1015,15 @@ CONFIG_USB_STORAGE=y # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set +# CONFIG_USB_STORAGE_ALAUDA is not set +# CONFIG_USB_LIBUSUAL is not set # # USB Input Devices # CONFIG_USB_HID=y CONFIG_USB_HIDINPUT=y +# CONFIG_USB_HIDINPUT_POWERBOOK is not set # CONFIG_HID_FF is not set CONFIG_USB_HIDDEV=y # CONFIG_USB_AIPTEK is not set @@ -1080,6 +1037,7 @@ CONFIG_USB_HIDDEV=y # CONFIG_USB_YEALINK is not set # CONFIG_USB_XPAD is not set # CONFIG_USB_ATI_REMOTE is not set +# CONFIG_USB_ATI_REMOTE2 is not set # CONFIG_USB_KEYSPAN_REMOTE is not set # CONFIG_USB_APPLETOUCH is not set @@ -1167,6 +1125,10 @@ CONFIG_INFINIBAND_IPOIB=m # # +# EDAC - error detection and reporting (RAS) +# + +# # File systems # CONFIG_EXT2_FS=y @@ -1200,6 +1162,7 @@ CONFIG_XFS_EXPORT=y CONFIG_XFS_SECURITY=y CONFIG_XFS_POSIX_ACL=y # CONFIG_XFS_RT is not set +# CONFIG_OCFS2_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_ROMFS_FS is not set CONFIG_INOTIFY=y @@ -1240,6 +1203,7 @@ CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y CONFIG_RAMFS=y # CONFIG_RELAYFS_FS is not set +# CONFIG_CONFIGFS_FS is not set # # Miscellaneous filesystems @@ -1351,10 +1315,6 @@ CONFIG_CRC32=y CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=m -CONFIG_TEXTSEARCH=y -CONFIG_TEXTSEARCH_KMP=m -CONFIG_TEXTSEARCH_BM=m -CONFIG_TEXTSEARCH_FSM=m # # Instrumentation Support @@ -1367,18 +1327,20 @@ CONFIG_OPROFILE=y # Kernel hacking # # CONFIG_PRINTK_TIME is not set -CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y +CONFIG_DEBUG_KERNEL=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_DETECT_SOFTLOCKUP=y # CONFIG_SCHEDSTATS is not set # CONFIG_DEBUG_SLAB is not set +CONFIG_DEBUG_MUTEXES=y # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_INFO is not set CONFIG_DEBUG_FS=y # CONFIG_DEBUG_VM is not set +CONFIG_FORCED_INLINING=y # CONFIG_RCU_TORTURE_TEST is not set CONFIG_DEBUG_STACKOVERFLOW=y CONFIG_DEBUG_STACK_USAGE=y @@ -1387,6 +1349,11 @@ CONFIG_XMON=y CONFIG_XMON_DEFAULT=y CONFIG_IRQSTACKS=y # CONFIG_BOOTX_TEXT is not set +# CONFIG_PPC_EARLY_DEBUG_LPAR is not set +# CONFIG_PPC_EARLY_DEBUG_G5 is not set +# CONFIG_PPC_EARLY_DEBUG_RTAS is not set +# CONFIG_PPC_EARLY_DEBUG_MAPLE is not set +# CONFIG_PPC_EARLY_DEBUG_ISERIES is not set # # Security options From arnd at arndb.de Sun Feb 12 15:52:25 2006 From: arnd at arndb.de (Arnd Bergmann) Date: Sun, 12 Feb 2006 05:52:25 +0100 Subject: AW: Re: __setup_cpu_be problem In-Reply-To: <1139546116.5003.81.camel@localhost.localdomain> References: <2812322.110611139545275893.JavaMail.servlet@kundenserver> <1139546116.5003.81.camel@localhost.localdomain> Message-ID: <200602120552.26164.arnd@arndb.de> On Friday 10 February 2006 05:35, Benjamin Herrenschmidt wrote: > > > Doing it in the firmware sounds like the right solution to me. > > I would however not want to do that if the current firmware > > sets the wrong page sizes. > > > > I know that Hartmut wanted me to provide him with the right device > > tree information that he needs to create to say that the page > > size are 16M, 64k and 4k. Maybe we can find a combined solution > > for these problems. Using __setup_cpu_power4 should be ok. > > I don't completely understand your statement ... sorry The current firmware on the Cell blades does neither the setup of the HID6 register nor have the correct tables in the device tree. Since I'm still currently sitting in a garden in NZ instead of the B?blingen lab, I can't find out what the HID6 power-on defaults are. We might get away with just leaving the default there, but that might prevent us from using 16M and/or 64k pages and there are definitely some application which depend on 16M hugetlb mappings on Cell. The two problems we are facing currently are: - If HID6 defaults to disabling 16M large pages, the kernel will get the wrong information from the CPU features and applications that use it break. The firmware should add the setup if HID6 _now_, but we also should be prepared for users of old firmware that want to upgrade their kernel without upgrading the firmware at the same time. - We want to use 64k pages in the future, so the firmware needs to add the 'ibm,segment-page-sizes' property ASAP, preferrably at the same time they start setting up HID6. I currently have a hack for the kernel to override that, but we're in the process of eliminating all the special hacks that won't make in into the mainline kernel. > > We could probably do a fallback in the cell setup to see if > > the properties are in the device tree and do our own HID6 > > setup stuff if not, normally expecting that the firmware settings > > match the device tree. > > We should not touch HID6 at all ... we should assume the firmware set it > appropriately and have setup matching page size entries in the > device-tree. I don't think we need to support changing that value > especially since the kernel doesn't quite support 1M large page sizes > anyway. Yes, 1M mappings are probably not of much use to us, and other OSs already do whatever they like ;-). > > Geoff, if your firmware does not already have the properties > > for large page sizes, could you add them? > > > > Ben, could you point Hartmut (and maybe Geoff) to the documentation > > for how the device tree needs to look like? > > I'm not sure we published that yet :) I would suggest looking at what > the kernel does to parse these instead in hash_utils.c until I get a > former IBM approval for the spec to be published. Then please try to at least send the spec or a link to Hartmut's IBM internal address (hpenner at de.ibm.com). I already pointed him to the linux code when it was initially merged, but he argued that reverse engineering that code is not good enough to be sure to get the property right and not having it in there is better than having incorrect properties. Arnd <>< From benh at kernel.crashing.org Mon Feb 13 08:24:22 2006 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Mon, 13 Feb 2006 08:24:22 +1100 Subject: AW: Re: __setup_cpu_be problem In-Reply-To: <200602120552.26164.arnd@arndb.de> References: <2812322.110611139545275893.JavaMail.servlet@kundenserver> <1139546116.5003.81.camel@localhost.localdomain> <200602120552.26164.arnd@arndb.de> Message-ID: <1139779462.5247.30.camel@localhost.localdomain> > The current firmware on the Cell blades does neither the setup of > the HID6 register nor have the correct tables in the device tree. > > Since I'm still currently sitting in a garden in NZ instead of the > B?blingen lab, I can't find out what the HID6 power-on defaults > are. We might get away with just leaving the default there, but that > might prevent us from using 16M and/or 64k pages and there are > definitely some application which depend on 16M hugetlb mappings > on Cell. Yes, however, how much widely distributed and "frozen" is this current Cell firmware ? I mean, do we really need to add a workaround to the kenrel instead of just fixing the firmware here ? > The two problems we are facing currently are: > - If HID6 defaults to disabling 16M large pages, the kernel will > get the wrong information from the CPU features and applications > that use it break. The firmware should add the setup if HID6 > _now_, but we also should be prepared for users of old firmware > that want to upgrade their kernel without upgrading the firmware > at the same time. Do we really need to support old/broken firmware ? It's not like we had a released product all over the field... > - We want to use 64k pages in the future, so the firmware needs to > add the 'ibm,segment-page-sizes' property ASAP, preferrably at > the same time they start setting up HID6. I currently have a > hack for the kernel to override that, but we're in the process > of eliminating all the special hacks that won't make in into > the mainline kernel. The only things you need is to have this property set and the new ibm,pa-feature for which I need to dig out the latest spec.... The problem is that the kernel will currentl not enable 64k pages on any processor due to the lack of a feature bit (intentionally) from the cputable. That bit will be extracted from ibm,pa-features at least on pSeries. It's the bit indicating that L=1 works for cache inhibited mappings. > Yes, 1M mappings are probably not of much use to us, and other OSs > already do whatever they like ;-). Sure. Note that the firmware can still set HID6 to 1M pages and put the appropriate entries in the device-tree for 1M large pages. Linux won't be able to use them as-is though but at least the device-tree infos will be sane. I don't want to enter a debate wether we should be able to change HID6 etc... right now. It's more a firmware configuration issue as far as I'm concerned. > Then please try to at least send the spec or a link to Hartmut's IBM > internal address (hpenner at de.ibm.com). I already pointed him to the > linux code when it was initially merged, but he argued that reverse > engineering that code is not good enough to be sure to get the > property right and not having it in there is better than having incorrect > properties. Will do Ben. From benh at kernel.crashing.org Mon Feb 13 09:11:44 2006 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Mon, 13 Feb 2006 09:11:44 +1100 Subject: [PATCH] Update {g5,pseries,ppc64}_defconfig In-Reply-To: <20060210234903.GB4795@pb15.lixom.net> References: <20060210234903.GB4795@pb15.lixom.net> Message-ID: <1139782304.5247.42.camel@localhost.localdomain> On Fri, 2006-02-10 at 17:49 -0600, Olof Johansson wrote: > Hi, > > For powerpc.git (post-2.6.16): > > Update defconfigs for g5, pseries and generic ppc64. Default choices > for everything, with the following exceptions: > > * Enable WINDFARM_PM112 on g5 and ppc64. > * Increase CONFIG_NR_CPUS to 4 on g5_defconfig You probably also want to make tg3 built-in... Ben. > > Signed-off-by: Olof Johansson > > Index: powerpc-git/arch/powerpc/configs/g5_defconfig > =================================================================== > --- powerpc-git.orig/arch/powerpc/configs/g5_defconfig > +++ powerpc-git/arch/powerpc/configs/g5_defconfig > @@ -1,7 +1,7 @@ > # > # Automatically generated make config: don't edit > -# Linux kernel version: 2.6.15-rc5 > -# Tue Dec 20 15:59:30 2005 > +# Linux kernel version: 2.6.16-rc2 > +# Fri Feb 10 17:33:08 2006 > # > CONFIG_PPC64=y > CONFIG_64BIT=y > @@ -16,6 +16,10 @@ CONFIG_COMPAT=y > CONFIG_SYSVIPC_COMPAT=y > CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y > CONFIG_ARCH_MAY_HAVE_PC_FDC=y > +CONFIG_PPC_OF=y > +# CONFIG_PPC_UDBG_16550 is not set > +CONFIG_GENERIC_TBSYNC=y > +# CONFIG_DEFAULT_UIMAGE is not set > > # > # Processor support > @@ -26,13 +30,12 @@ CONFIG_PPC_FPU=y > CONFIG_ALTIVEC=y > CONFIG_PPC_STD_MMU=y > CONFIG_SMP=y > -CONFIG_NR_CPUS=2 > +CONFIG_NR_CPUS=4 > > # > # Code maturity level options > # > CONFIG_EXPERIMENTAL=y > -CONFIG_CLEAN_COMPILE=y > CONFIG_LOCK_KERNEL=y > CONFIG_INIT_ENV_ARG_LIMIT=32 > > @@ -47,8 +50,6 @@ CONFIG_POSIX_MQUEUE=y > # CONFIG_BSD_PROCESS_ACCT is not set > CONFIG_SYSCTL=y > # CONFIG_AUDIT is not set > -CONFIG_HOTPLUG=y > -CONFIG_KOBJECT_UEVENT=y > CONFIG_IKCONFIG=y > CONFIG_IKCONFIG_PROC=y > # CONFIG_CPUSETS is not set > @@ -58,8 +59,10 @@ CONFIG_CC_OPTIMIZE_FOR_SIZE=y > CONFIG_KALLSYMS=y > # CONFIG_KALLSYMS_ALL is not set > # CONFIG_KALLSYMS_EXTRA_PASS is not set > +CONFIG_HOTPLUG=y > CONFIG_PRINTK=y > CONFIG_BUG=y > +CONFIG_ELF_CORE=y > CONFIG_BASE_FULL=y > CONFIG_FUTEX=y > CONFIG_EPOLL=y > @@ -68,8 +71,10 @@ CONFIG_CC_ALIGN_FUNCTIONS=0 > CONFIG_CC_ALIGN_LABELS=0 > CONFIG_CC_ALIGN_LOOPS=0 > CONFIG_CC_ALIGN_JUMPS=0 > +CONFIG_SLAB=y > # CONFIG_TINY_SHMEM is not set > CONFIG_BASE_SMALL=0 > +# CONFIG_SLOB is not set > > # > # Loadable module support > @@ -112,13 +117,12 @@ CONFIG_PPC_PMAC=y > CONFIG_PPC_PMAC64=y > # CONFIG_PPC_MAPLE is not set > # CONFIG_PPC_CELL is not set > -CONFIG_PPC_OF=y > CONFIG_U3_DART=y > CONFIG_MPIC=y > # CONFIG_PPC_RTAS is not set > # CONFIG_MMIO_NVRAM is not set > +CONFIG_MPIC_BROKEN_U3=y > # CONFIG_PPC_MPC106 is not set > -CONFIG_GENERIC_TBSYNC=y > CONFIG_CPU_FREQ=y > CONFIG_CPU_FREQ_TABLE=y > # CONFIG_CPU_FREQ_DEBUG is not set > @@ -151,6 +155,7 @@ CONFIG_FORCE_MAX_ZONEORDER=13 > CONFIG_IOMMU_VMERGE=y > # CONFIG_HOTPLUG_CPU is not set > CONFIG_KEXEC=y > +# CONFIG_CRASH_DUMP is not set > CONFIG_IRQ_ALL_CPUS=y > # CONFIG_NUMA is not set > CONFIG_ARCH_SELECT_MEMORY_MODEL=y > @@ -202,6 +207,7 @@ CONFIG_NET=y > # > # Networking options > # > +# CONFIG_NETDEBUG is not set > CONFIG_PACKET=y > # CONFIG_PACKET_MMAP is not set > CONFIG_UNIX=y > @@ -239,6 +245,7 @@ CONFIG_NETFILTER=y > # Core Netfilter Configuration > # > # CONFIG_NETFILTER_NETLINK is not set > +# CONFIG_NETFILTER_XTABLES is not set > > # > # IP: Netfilter Configuration > @@ -255,65 +262,6 @@ CONFIG_IP_NF_TFTP=m > CONFIG_IP_NF_AMANDA=m > # CONFIG_IP_NF_PPTP is not set > CONFIG_IP_NF_QUEUE=m > -CONFIG_IP_NF_IPTABLES=m > -CONFIG_IP_NF_MATCH_LIMIT=m > -CONFIG_IP_NF_MATCH_IPRANGE=m > -CONFIG_IP_NF_MATCH_MAC=m > -CONFIG_IP_NF_MATCH_PKTTYPE=m > -CONFIG_IP_NF_MATCH_MARK=m > -CONFIG_IP_NF_MATCH_MULTIPORT=m > -CONFIG_IP_NF_MATCH_TOS=m > -CONFIG_IP_NF_MATCH_RECENT=m > -CONFIG_IP_NF_MATCH_ECN=m > -CONFIG_IP_NF_MATCH_DSCP=m > -CONFIG_IP_NF_MATCH_AH_ESP=m > -CONFIG_IP_NF_MATCH_LENGTH=m > -CONFIG_IP_NF_MATCH_TTL=m > -CONFIG_IP_NF_MATCH_TCPMSS=m > -CONFIG_IP_NF_MATCH_HELPER=m > -CONFIG_IP_NF_MATCH_STATE=m > -CONFIG_IP_NF_MATCH_CONNTRACK=m > -CONFIG_IP_NF_MATCH_OWNER=m > -CONFIG_IP_NF_MATCH_ADDRTYPE=m > -CONFIG_IP_NF_MATCH_REALM=m > -CONFIG_IP_NF_MATCH_SCTP=m > -# CONFIG_IP_NF_MATCH_DCCP is not set > -CONFIG_IP_NF_MATCH_COMMENT=m > -CONFIG_IP_NF_MATCH_CONNMARK=m > -CONFIG_IP_NF_MATCH_CONNBYTES=m > -CONFIG_IP_NF_MATCH_HASHLIMIT=m > -CONFIG_IP_NF_MATCH_STRING=m > -CONFIG_IP_NF_FILTER=m > -CONFIG_IP_NF_TARGET_REJECT=m > -CONFIG_IP_NF_TARGET_LOG=m > -CONFIG_IP_NF_TARGET_ULOG=m > -CONFIG_IP_NF_TARGET_TCPMSS=m > -CONFIG_IP_NF_TARGET_NFQUEUE=m > -CONFIG_IP_NF_NAT=m > -CONFIG_IP_NF_NAT_NEEDED=y > -CONFIG_IP_NF_TARGET_MASQUERADE=m > -CONFIG_IP_NF_TARGET_REDIRECT=m > -CONFIG_IP_NF_TARGET_NETMAP=m > -CONFIG_IP_NF_TARGET_SAME=m > -CONFIG_IP_NF_NAT_SNMP_BASIC=m > -CONFIG_IP_NF_NAT_IRC=m > -CONFIG_IP_NF_NAT_FTP=m > -CONFIG_IP_NF_NAT_TFTP=m > -CONFIG_IP_NF_NAT_AMANDA=m > -CONFIG_IP_NF_MANGLE=m > -CONFIG_IP_NF_TARGET_TOS=m > -CONFIG_IP_NF_TARGET_ECN=m > -CONFIG_IP_NF_TARGET_DSCP=m > -CONFIG_IP_NF_TARGET_MARK=m > -CONFIG_IP_NF_TARGET_CLASSIFY=m > -CONFIG_IP_NF_TARGET_TTL=m > -CONFIG_IP_NF_TARGET_CONNMARK=m > -CONFIG_IP_NF_TARGET_CLUSTERIP=m > -CONFIG_IP_NF_RAW=m > -CONFIG_IP_NF_TARGET_NOTRACK=m > -CONFIG_IP_NF_ARPTABLES=m > -CONFIG_IP_NF_ARPFILTER=m > -CONFIG_IP_NF_ARP_MANGLE=m > > # > # DCCP Configuration (EXPERIMENTAL) > @@ -324,6 +272,11 @@ CONFIG_IP_NF_ARP_MANGLE=m > # SCTP Configuration (EXPERIMENTAL) > # > # CONFIG_IP_SCTP is not set > + > +# > +# TIPC Configuration (EXPERIMENTAL) > +# > +# CONFIG_TIPC is not set > # CONFIG_ATM is not set > # CONFIG_BRIDGE is not set > # CONFIG_VLAN_8021Q is not set > @@ -342,7 +295,6 @@ CONFIG_LLC=y > # QoS and/or fair queueing > # > # CONFIG_NET_SCHED is not set > -CONFIG_NET_CLS_ROUTE=y > > # > # Network testing > @@ -545,13 +497,7 @@ CONFIG_SCSI_SATA_SVW=y > # CONFIG_SCSI_IPR is not set > # CONFIG_SCSI_QLOGIC_FC is not set > # CONFIG_SCSI_QLOGIC_1280 is not set > -CONFIG_SCSI_QLA2XXX=y > -# CONFIG_SCSI_QLA21XX is not set > -# CONFIG_SCSI_QLA22XX is not set > -# CONFIG_SCSI_QLA2300 is not set > -# CONFIG_SCSI_QLA2322 is not set > -# CONFIG_SCSI_QLA6312 is not set > -# CONFIG_SCSI_QLA24XX is not set > +# CONFIG_SCSI_QLA_FC is not set > # CONFIG_SCSI_LPFC is not set > # CONFIG_SCSI_DC395x is not set > # CONFIG_SCSI_DC390T is not set > @@ -614,7 +560,6 @@ CONFIG_IEEE1394_SBP2=m > CONFIG_IEEE1394_ETH1394=m > CONFIG_IEEE1394_DV1394=m > CONFIG_IEEE1394_RAWIO=y > -# CONFIG_IEEE1394_CMP is not set > > # > # I2O device support > @@ -630,6 +575,7 @@ CONFIG_THERM_PM72=y > CONFIG_WINDFARM=y > CONFIG_WINDFARM_PM81=y > CONFIG_WINDFARM_PM91=y > +CONFIG_WINDFARM_PM112=y > > # > # Network device support > @@ -682,6 +628,7 @@ CONFIG_E1000=y > # CONFIG_R8169 is not set > # CONFIG_SIS190 is not set > # CONFIG_SKGE is not set > +# CONFIG_SKY2 is not set > # CONFIG_SK98LIN is not set > CONFIG_TIGON3=m > # CONFIG_BNX2 is not set > @@ -861,8 +808,7 @@ CONFIG_I2C_ALGOBIT=y > # CONFIG_I2C_I801 is not set > # CONFIG_I2C_I810 is not set > # CONFIG_I2C_PIIX4 is not set > -CONFIG_I2C_KEYWEST=y > -CONFIG_I2C_PMAC_SMU=y > +CONFIG_I2C_POWERMAC=y > # CONFIG_I2C_NFORCE2 is not set > # CONFIG_I2C_PARPORT_LIGHT is not set > # CONFIG_I2C_PROSAVAGE is not set > @@ -895,6 +841,12 @@ CONFIG_I2C_PMAC_SMU=y > # CONFIG_I2C_DEBUG_CHIP is not set > > # > +# SPI support > +# > +# CONFIG_SPI is not set > +# CONFIG_SPI_MASTER is not set > + > +# > # Dallas's 1-wire bus > # > # CONFIG_W1 is not set > @@ -961,7 +913,6 @@ CONFIG_FB_RADEON_I2C=y > # CONFIG_FB_KYRO is not set > # CONFIG_FB_3DFX is not set > # CONFIG_FB_VOODOO1 is not set > -# CONFIG_FB_CYBLA is not set > # CONFIG_FB_TRIDENT is not set > # CONFIG_FB_VIRTUAL is not set > > @@ -1008,9 +959,10 @@ CONFIG_SND_OSSEMUL=y > CONFIG_SND_MIXER_OSS=m > CONFIG_SND_PCM_OSS=m > CONFIG_SND_SEQUENCER_OSS=y > +# CONFIG_SND_DYNAMIC_MINORS is not set > +CONFIG_SND_SUPPORT_OLD_API=y > # CONFIG_SND_VERBOSE_PRINTK is not set > # CONFIG_SND_DEBUG is not set > -CONFIG_SND_GENERIC_DRIVER=y > > # > # Generic devices > @@ -1024,6 +976,8 @@ CONFIG_SND_GENERIC_DRIVER=y > # > # PCI devices > # > +# CONFIG_SND_AD1889 is not set > +# CONFIG_SND_ALS4000 is not set > # CONFIG_SND_ALI5451 is not set > # CONFIG_SND_ATIIXP is not set > # CONFIG_SND_ATIIXP_MODEM is not set > @@ -1032,39 +986,38 @@ CONFIG_SND_GENERIC_DRIVER=y > # CONFIG_SND_AU8830 is not set > # CONFIG_SND_AZT3328 is not set > # CONFIG_SND_BT87X is not set > -# CONFIG_SND_CS46XX is not set > +# CONFIG_SND_CA0106 is not set > +# CONFIG_SND_CMIPCI is not set > # CONFIG_SND_CS4281 is not set > +# CONFIG_SND_CS46XX is not set > # CONFIG_SND_EMU10K1 is not set > # CONFIG_SND_EMU10K1X is not set > -# CONFIG_SND_CA0106 is not set > -# CONFIG_SND_KORG1212 is not set > -# CONFIG_SND_MIXART is not set > -# CONFIG_SND_NM256 is not set > -# CONFIG_SND_RME32 is not set > -# CONFIG_SND_RME96 is not set > -# CONFIG_SND_RME9652 is not set > -# CONFIG_SND_HDSP is not set > -# CONFIG_SND_HDSPM is not set > -# CONFIG_SND_TRIDENT is not set > -# CONFIG_SND_YMFPCI is not set > -# CONFIG_SND_AD1889 is not set > -# CONFIG_SND_ALS4000 is not set > -# CONFIG_SND_CMIPCI is not set > # CONFIG_SND_ENS1370 is not set > # CONFIG_SND_ENS1371 is not set > # CONFIG_SND_ES1938 is not set > # CONFIG_SND_ES1968 is not set > -# CONFIG_SND_MAESTRO3 is not set > # CONFIG_SND_FM801 is not set > +# CONFIG_SND_HDA_INTEL is not set > +# CONFIG_SND_HDSP is not set > +# CONFIG_SND_HDSPM is not set > # CONFIG_SND_ICE1712 is not set > # CONFIG_SND_ICE1724 is not set > # CONFIG_SND_INTEL8X0 is not set > # CONFIG_SND_INTEL8X0M is not set > +# CONFIG_SND_KORG1212 is not set > +# CONFIG_SND_MAESTRO3 is not set > +# CONFIG_SND_MIXART is not set > +# CONFIG_SND_NM256 is not set > +# CONFIG_SND_PCXHR is not set > +# CONFIG_SND_RME32 is not set > +# CONFIG_SND_RME96 is not set > +# CONFIG_SND_RME9652 is not set > # CONFIG_SND_SONICVIBES is not set > +# CONFIG_SND_TRIDENT is not set > # CONFIG_SND_VIA82XX is not set > # CONFIG_SND_VIA82XX_MODEM is not set > # CONFIG_SND_VX222 is not set > -# CONFIG_SND_HDA_INTEL is not set > +# CONFIG_SND_YMFPCI is not set > > # > # ALSA PowerMac devices > @@ -1136,13 +1089,16 @@ CONFIG_USB_STORAGE_DPCM=y > CONFIG_USB_STORAGE_SDDR09=y > CONFIG_USB_STORAGE_SDDR55=y > CONFIG_USB_STORAGE_JUMPSHOT=y > +# CONFIG_USB_STORAGE_ALAUDA is not set > # CONFIG_USB_STORAGE_ONETOUCH is not set > +# CONFIG_USB_LIBUSUAL is not set > > # > # USB Input Devices > # > CONFIG_USB_HID=y > CONFIG_USB_HIDINPUT=y > +# CONFIG_USB_HIDINPUT_POWERBOOK is not set > CONFIG_HID_FF=y > CONFIG_HID_PID=y > CONFIG_LOGITECH_FF=y > @@ -1159,6 +1115,7 @@ CONFIG_USB_HIDDEV=y > # CONFIG_USB_YEALINK is not set > # CONFIG_USB_XPAD is not set > # CONFIG_USB_ATI_REMOTE is not set > +# CONFIG_USB_ATI_REMOTE2 is not set > # CONFIG_USB_KEYSPAN_REMOTE is not set > # CONFIG_USB_APPLETOUCH is not set > > @@ -1207,6 +1164,7 @@ CONFIG_USB_SERIAL_GENERIC=y > # CONFIG_USB_SERIAL_AIRPRIME is not set > # CONFIG_USB_SERIAL_ANYDATA is not set > CONFIG_USB_SERIAL_BELKIN=m > +# CONFIG_USB_SERIAL_WHITEHEAT is not set > CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m > # CONFIG_USB_SERIAL_CP2101 is not set > CONFIG_USB_SERIAL_CYPRESS_M8=m > @@ -1288,6 +1246,10 @@ CONFIG_USB_EZUSB=y > # > > # > +# EDAC - error detection and reporting (RAS) > +# > + > +# > # File systems > # > CONFIG_EXT2_FS=y > @@ -1317,6 +1279,7 @@ CONFIG_XFS_EXPORT=y > CONFIG_XFS_SECURITY=y > CONFIG_XFS_POSIX_ACL=y > # CONFIG_XFS_RT is not set > +# CONFIG_OCFS2_FS is not set > # CONFIG_MINIX_FS is not set > # CONFIG_ROMFS_FS is not set > CONFIG_INOTIFY=y > @@ -1357,6 +1320,7 @@ CONFIG_HUGETLBFS=y > CONFIG_HUGETLB_PAGE=y > CONFIG_RAMFS=y > # CONFIG_RELAYFS_FS is not set > +# CONFIG_CONFIGFS_FS is not set > > # > # Miscellaneous filesystems > @@ -1426,6 +1390,7 @@ CONFIG_MSDOS_PARTITION=y > # CONFIG_SGI_PARTITION is not set > # CONFIG_ULTRIX_PARTITION is not set > # CONFIG_SUN_PARTITION is not set > +# CONFIG_KARMA_PARTITION is not set > # CONFIG_EFI_PARTITION is not set > > # > @@ -1481,10 +1446,6 @@ CONFIG_CRC32=y > CONFIG_LIBCRC32C=m > CONFIG_ZLIB_INFLATE=y > CONFIG_ZLIB_DEFLATE=m > -CONFIG_TEXTSEARCH=y > -CONFIG_TEXTSEARCH_KMP=m > -CONFIG_TEXTSEARCH_BM=m > -CONFIG_TEXTSEARCH_FSM=m > > # > # Instrumentation Support > @@ -1497,24 +1458,31 @@ CONFIG_OPROFILE=y > # Kernel hacking > # > # CONFIG_PRINTK_TIME is not set > -CONFIG_DEBUG_KERNEL=y > CONFIG_MAGIC_SYSRQ=y > +CONFIG_DEBUG_KERNEL=y > CONFIG_LOG_BUF_SHIFT=17 > CONFIG_DETECT_SOFTLOCKUP=y > # CONFIG_SCHEDSTATS is not set > # CONFIG_DEBUG_SLAB is not set > +CONFIG_DEBUG_MUTEXES=y > # CONFIG_DEBUG_SPINLOCK is not set > # CONFIG_DEBUG_SPINLOCK_SLEEP is not set > # CONFIG_DEBUG_KOBJECT is not set > # CONFIG_DEBUG_INFO is not set > CONFIG_DEBUG_FS=y > # CONFIG_DEBUG_VM is not set > +CONFIG_FORCED_INLINING=y > # CONFIG_RCU_TORTURE_TEST is not set > # CONFIG_DEBUG_STACKOVERFLOW is not set > # CONFIG_DEBUG_STACK_USAGE is not set > # CONFIG_DEBUGGER is not set > CONFIG_IRQSTACKS=y > CONFIG_BOOTX_TEXT=y > +# CONFIG_PPC_EARLY_DEBUG_LPAR is not set > +# CONFIG_PPC_EARLY_DEBUG_G5 is not set > +# CONFIG_PPC_EARLY_DEBUG_RTAS is not set > +# CONFIG_PPC_EARLY_DEBUG_MAPLE is not set > +# CONFIG_PPC_EARLY_DEBUG_ISERIES is not set > > # > # Security options > Index: powerpc-git/arch/powerpc/configs/ppc64_defconfig > =================================================================== > --- powerpc-git.orig/arch/powerpc/configs/ppc64_defconfig > +++ powerpc-git/arch/powerpc/configs/ppc64_defconfig > @@ -1,7 +1,7 @@ > # > # Automatically generated make config: don't edit > -# Linux kernel version: 2.6.15-rc5 > -# Tue Dec 20 15:59:38 2005 > +# Linux kernel version: 2.6.16-rc2 > +# Fri Feb 10 17:32:14 2006 > # > CONFIG_PPC64=y > CONFIG_64BIT=y > @@ -16,6 +16,10 @@ CONFIG_COMPAT=y > CONFIG_SYSVIPC_COMPAT=y > CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y > CONFIG_ARCH_MAY_HAVE_PC_FDC=y > +CONFIG_PPC_OF=y > +CONFIG_PPC_UDBG_16550=y > +CONFIG_GENERIC_TBSYNC=y > +# CONFIG_DEFAULT_UIMAGE is not set > > # > # Processor support > @@ -33,7 +37,6 @@ CONFIG_NR_CPUS=32 > # Code maturity level options > # > CONFIG_EXPERIMENTAL=y > -CONFIG_CLEAN_COMPILE=y > CONFIG_LOCK_KERNEL=y > CONFIG_INIT_ENV_ARG_LIMIT=32 > > @@ -48,8 +51,6 @@ CONFIG_POSIX_MQUEUE=y > # CONFIG_BSD_PROCESS_ACCT is not set > CONFIG_SYSCTL=y > # CONFIG_AUDIT is not set > -CONFIG_HOTPLUG=y > -CONFIG_KOBJECT_UEVENT=y > CONFIG_IKCONFIG=y > CONFIG_IKCONFIG_PROC=y > CONFIG_CPUSETS=y > @@ -59,8 +60,10 @@ CONFIG_CC_OPTIMIZE_FOR_SIZE=y > CONFIG_KALLSYMS=y > CONFIG_KALLSYMS_ALL=y > # CONFIG_KALLSYMS_EXTRA_PASS is not set > +CONFIG_HOTPLUG=y > CONFIG_PRINTK=y > CONFIG_BUG=y > +CONFIG_ELF_CORE=y > CONFIG_BASE_FULL=y > CONFIG_FUTEX=y > CONFIG_EPOLL=y > @@ -69,8 +72,10 @@ CONFIG_CC_ALIGN_FUNCTIONS=0 > CONFIG_CC_ALIGN_LABELS=0 > CONFIG_CC_ALIGN_LOOPS=0 > CONFIG_CC_ALIGN_JUMPS=0 > +CONFIG_SLAB=y > # CONFIG_TINY_SHMEM is not set > CONFIG_BASE_SMALL=0 > +# CONFIG_SLOB is not set > > # > # Loadable module support > @@ -113,7 +118,6 @@ CONFIG_PPC_PMAC=y > CONFIG_PPC_PMAC64=y > CONFIG_PPC_MAPLE=y > # CONFIG_PPC_CELL is not set > -CONFIG_PPC_OF=y > CONFIG_XICS=y > CONFIG_U3_DART=y > CONFIG_MPIC=y > @@ -124,8 +128,8 @@ CONFIG_RTAS_FLASH=m > # CONFIG_MMIO_NVRAM is not set > CONFIG_MPIC_BROKEN_U3=y > CONFIG_IBMVIO=y > +# CONFIG_IBMEBUS is not set > # CONFIG_PPC_MPC106 is not set > -CONFIG_GENERIC_TBSYNC=y > CONFIG_CPU_FREQ=y > CONFIG_CPU_FREQ_TABLE=y > # CONFIG_CPU_FREQ_DEBUG is not set > @@ -158,6 +162,7 @@ CONFIG_FORCE_MAX_ZONEORDER=13 > CONFIG_IOMMU_VMERGE=y > CONFIG_HOTPLUG_CPU=y > CONFIG_KEXEC=y > +# CONFIG_CRASH_DUMP is not set > CONFIG_IRQ_ALL_CPUS=y > CONFIG_PPC_SPLPAR=y > CONFIG_EEH=y > @@ -178,6 +183,7 @@ CONFIG_HAVE_MEMORY_PRESENT=y > CONFIG_SPARSEMEM_EXTREME=y > # CONFIG_MEMORY_HOTPLUG is not set > CONFIG_SPLIT_PTLOCK_CPUS=4 > +CONFIG_MIGRATION=y > # CONFIG_PPC_64K_PAGES is not set > # CONFIG_SCHED_SMT is not set > CONFIG_PROC_DEVICETREE=y > @@ -221,6 +227,7 @@ CONFIG_NET=y > # > # Networking options > # > +# CONFIG_NETDEBUG is not set > CONFIG_PACKET=y > # CONFIG_PACKET_MMAP is not set > CONFIG_UNIX=y > @@ -260,6 +267,7 @@ CONFIG_NETFILTER=y > CONFIG_NETFILTER_NETLINK=y > CONFIG_NETFILTER_NETLINK_QUEUE=m > CONFIG_NETFILTER_NETLINK_LOG=m > +# CONFIG_NETFILTER_XTABLES is not set > > # > # IP: Netfilter Configuration > @@ -277,65 +285,6 @@ CONFIG_IP_NF_TFTP=m > CONFIG_IP_NF_AMANDA=m > # CONFIG_IP_NF_PPTP is not set > CONFIG_IP_NF_QUEUE=m > -CONFIG_IP_NF_IPTABLES=m > -CONFIG_IP_NF_MATCH_LIMIT=m > -CONFIG_IP_NF_MATCH_IPRANGE=m > -CONFIG_IP_NF_MATCH_MAC=m > -CONFIG_IP_NF_MATCH_PKTTYPE=m > -CONFIG_IP_NF_MATCH_MARK=m > -CONFIG_IP_NF_MATCH_MULTIPORT=m > -CONFIG_IP_NF_MATCH_TOS=m > -CONFIG_IP_NF_MATCH_RECENT=m > -CONFIG_IP_NF_MATCH_ECN=m > -CONFIG_IP_NF_MATCH_DSCP=m > -CONFIG_IP_NF_MATCH_AH_ESP=m > -CONFIG_IP_NF_MATCH_LENGTH=m > -CONFIG_IP_NF_MATCH_TTL=m > -CONFIG_IP_NF_MATCH_TCPMSS=m > -CONFIG_IP_NF_MATCH_HELPER=m > -CONFIG_IP_NF_MATCH_STATE=m > -CONFIG_IP_NF_MATCH_CONNTRACK=m > -CONFIG_IP_NF_MATCH_OWNER=m > -CONFIG_IP_NF_MATCH_ADDRTYPE=m > -CONFIG_IP_NF_MATCH_REALM=m > -CONFIG_IP_NF_MATCH_SCTP=m > -CONFIG_IP_NF_MATCH_DCCP=m > -CONFIG_IP_NF_MATCH_COMMENT=m > -CONFIG_IP_NF_MATCH_CONNMARK=m > -CONFIG_IP_NF_MATCH_CONNBYTES=m > -CONFIG_IP_NF_MATCH_HASHLIMIT=m > -CONFIG_IP_NF_MATCH_STRING=m > -CONFIG_IP_NF_FILTER=m > -CONFIG_IP_NF_TARGET_REJECT=m > -CONFIG_IP_NF_TARGET_LOG=m > -CONFIG_IP_NF_TARGET_ULOG=m > -CONFIG_IP_NF_TARGET_TCPMSS=m > -CONFIG_IP_NF_TARGET_NFQUEUE=m > -CONFIG_IP_NF_NAT=m > -CONFIG_IP_NF_NAT_NEEDED=y > -CONFIG_IP_NF_TARGET_MASQUERADE=m > -CONFIG_IP_NF_TARGET_REDIRECT=m > -CONFIG_IP_NF_TARGET_NETMAP=m > -CONFIG_IP_NF_TARGET_SAME=m > -CONFIG_IP_NF_NAT_SNMP_BASIC=m > -CONFIG_IP_NF_NAT_IRC=m > -CONFIG_IP_NF_NAT_FTP=m > -CONFIG_IP_NF_NAT_TFTP=m > -CONFIG_IP_NF_NAT_AMANDA=m > -CONFIG_IP_NF_MANGLE=m > -CONFIG_IP_NF_TARGET_TOS=m > -CONFIG_IP_NF_TARGET_ECN=m > -CONFIG_IP_NF_TARGET_DSCP=m > -CONFIG_IP_NF_TARGET_MARK=m > -CONFIG_IP_NF_TARGET_CLASSIFY=m > -CONFIG_IP_NF_TARGET_TTL=m > -CONFIG_IP_NF_TARGET_CONNMARK=m > -CONFIG_IP_NF_TARGET_CLUSTERIP=m > -CONFIG_IP_NF_RAW=m > -CONFIG_IP_NF_TARGET_NOTRACK=m > -CONFIG_IP_NF_ARPTABLES=m > -CONFIG_IP_NF_ARPFILTER=m > -CONFIG_IP_NF_ARP_MANGLE=m > > # > # DCCP Configuration (EXPERIMENTAL) > @@ -346,6 +295,11 @@ CONFIG_IP_NF_ARP_MANGLE=m > # SCTP Configuration (EXPERIMENTAL) > # > # CONFIG_IP_SCTP is not set > + > +# > +# TIPC Configuration (EXPERIMENTAL) > +# > +# CONFIG_TIPC is not set > # CONFIG_ATM is not set > # CONFIG_BRIDGE is not set > # CONFIG_VLAN_8021Q is not set > @@ -364,7 +318,6 @@ CONFIG_LLC=y > # QoS and/or fair queueing > # > # CONFIG_NET_SCHED is not set > -CONFIG_NET_CLS_ROUTE=y > > # > # Network testing > @@ -572,13 +525,7 @@ CONFIG_SCSI_IPR_TRACE=y > CONFIG_SCSI_IPR_DUMP=y > # CONFIG_SCSI_QLOGIC_FC is not set > # CONFIG_SCSI_QLOGIC_1280 is not set > -CONFIG_SCSI_QLA2XXX=y > -CONFIG_SCSI_QLA21XX=m > -CONFIG_SCSI_QLA22XX=m > -CONFIG_SCSI_QLA2300=m > -CONFIG_SCSI_QLA2322=m > -CONFIG_SCSI_QLA6312=m > -CONFIG_SCSI_QLA24XX=m > +# CONFIG_SCSI_QLA_FC is not set > CONFIG_SCSI_LPFC=m > # CONFIG_SCSI_DC395x is not set > # CONFIG_SCSI_DC390T is not set > @@ -642,8 +589,6 @@ CONFIG_IEEE1394_SBP2=m > CONFIG_IEEE1394_ETH1394=m > CONFIG_IEEE1394_DV1394=m > CONFIG_IEEE1394_RAWIO=y > -CONFIG_IEEE1394_CMP=m > -CONFIG_IEEE1394_AMDTP=m > > # > # I2O device support > @@ -659,6 +604,7 @@ CONFIG_THERM_PM72=y > CONFIG_WINDFARM=y > CONFIG_WINDFARM_PM81=y > CONFIG_WINDFARM_PM91=y > +CONFIG_WINDFARM_PM112=y > > # > # Network device support > @@ -731,6 +677,7 @@ CONFIG_E1000=y > # CONFIG_R8169 is not set > # CONFIG_SIS190 is not set > # CONFIG_SKGE is not set > +# CONFIG_SKY2 is not set > # CONFIG_SK98LIN is not set > # CONFIG_VIA_VELOCITY is not set > CONFIG_TIGON3=y > @@ -853,6 +800,7 @@ CONFIG_HW_CONSOLE=y > CONFIG_SERIAL_8250=y > CONFIG_SERIAL_8250_CONSOLE=y > CONFIG_SERIAL_8250_NR_UARTS=4 > +CONFIG_SERIAL_8250_RUNTIME_UARTS=4 > # CONFIG_SERIAL_8250_EXTENDED is not set > > # > @@ -880,6 +828,7 @@ CONFIG_HVCS=m > # CONFIG_WATCHDOG is not set > # CONFIG_RTC is not set > CONFIG_GEN_RTC=y > +# CONFIG_GEN_RTC_X is not set > # CONFIG_DTLK is not set > # CONFIG_R3964 is not set > # CONFIG_APPLICOM is not set > @@ -923,8 +872,7 @@ CONFIG_I2C_AMD8111=y > # CONFIG_I2C_I801 is not set > # CONFIG_I2C_I810 is not set > # CONFIG_I2C_PIIX4 is not set > -CONFIG_I2C_KEYWEST=y > -CONFIG_I2C_PMAC_SMU=y > +CONFIG_I2C_POWERMAC=y > # CONFIG_I2C_NFORCE2 is not set > # CONFIG_I2C_PARPORT_LIGHT is not set > # CONFIG_I2C_PROSAVAGE is not set > @@ -957,6 +905,12 @@ CONFIG_I2C_PMAC_SMU=y > # CONFIG_I2C_DEBUG_CHIP is not set > > # > +# SPI support > +# > +# CONFIG_SPI is not set > +# CONFIG_SPI_MASTER is not set > + > +# > # Dallas's 1-wire bus > # > # CONFIG_W1 is not set > @@ -1028,7 +982,6 @@ CONFIG_FB_RADEON_I2C=y > # CONFIG_FB_KYRO is not set > # CONFIG_FB_3DFX is not set > # CONFIG_FB_VOODOO1 is not set > -# CONFIG_FB_CYBLA is not set > # CONFIG_FB_TRIDENT is not set > # CONFIG_FB_VIRTUAL is not set > > @@ -1073,9 +1026,10 @@ CONFIG_SND_OSSEMUL=y > CONFIG_SND_MIXER_OSS=m > CONFIG_SND_PCM_OSS=m > CONFIG_SND_SEQUENCER_OSS=y > +# CONFIG_SND_DYNAMIC_MINORS is not set > +CONFIG_SND_SUPPORT_OLD_API=y > # CONFIG_SND_VERBOSE_PRINTK is not set > # CONFIG_SND_DEBUG is not set > -CONFIG_SND_GENERIC_DRIVER=y > > # > # Generic devices > @@ -1089,6 +1043,8 @@ CONFIG_SND_GENERIC_DRIVER=y > # > # PCI devices > # > +# CONFIG_SND_AD1889 is not set > +# CONFIG_SND_ALS4000 is not set > # CONFIG_SND_ALI5451 is not set > # CONFIG_SND_ATIIXP is not set > # CONFIG_SND_ATIIXP_MODEM is not set > @@ -1097,39 +1053,38 @@ CONFIG_SND_GENERIC_DRIVER=y > # CONFIG_SND_AU8830 is not set > # CONFIG_SND_AZT3328 is not set > # CONFIG_SND_BT87X is not set > -# CONFIG_SND_CS46XX is not set > +# CONFIG_SND_CA0106 is not set > +# CONFIG_SND_CMIPCI is not set > # CONFIG_SND_CS4281 is not set > +# CONFIG_SND_CS46XX is not set > # CONFIG_SND_EMU10K1 is not set > # CONFIG_SND_EMU10K1X is not set > -# CONFIG_SND_CA0106 is not set > -# CONFIG_SND_KORG1212 is not set > -# CONFIG_SND_MIXART is not set > -# CONFIG_SND_NM256 is not set > -# CONFIG_SND_RME32 is not set > -# CONFIG_SND_RME96 is not set > -# CONFIG_SND_RME9652 is not set > -# CONFIG_SND_HDSP is not set > -# CONFIG_SND_HDSPM is not set > -# CONFIG_SND_TRIDENT is not set > -# CONFIG_SND_YMFPCI is not set > -# CONFIG_SND_AD1889 is not set > -# CONFIG_SND_ALS4000 is not set > -# CONFIG_SND_CMIPCI is not set > # CONFIG_SND_ENS1370 is not set > # CONFIG_SND_ENS1371 is not set > # CONFIG_SND_ES1938 is not set > # CONFIG_SND_ES1968 is not set > -# CONFIG_SND_MAESTRO3 is not set > # CONFIG_SND_FM801 is not set > +# CONFIG_SND_HDA_INTEL is not set > +# CONFIG_SND_HDSP is not set > +# CONFIG_SND_HDSPM is not set > # CONFIG_SND_ICE1712 is not set > # CONFIG_SND_ICE1724 is not set > # CONFIG_SND_INTEL8X0 is not set > # CONFIG_SND_INTEL8X0M is not set > +# CONFIG_SND_KORG1212 is not set > +# CONFIG_SND_MAESTRO3 is not set > +# CONFIG_SND_MIXART is not set > +# CONFIG_SND_NM256 is not set > +# CONFIG_SND_PCXHR is not set > +# CONFIG_SND_RME32 is not set > +# CONFIG_SND_RME96 is not set > +# CONFIG_SND_RME9652 is not set > # CONFIG_SND_SONICVIBES is not set > +# CONFIG_SND_TRIDENT is not set > # CONFIG_SND_VIA82XX is not set > # CONFIG_SND_VIA82XX_MODEM is not set > # CONFIG_SND_VX222 is not set > -# CONFIG_SND_HDA_INTEL is not set > +# CONFIG_SND_YMFPCI is not set > > # > # ALSA PowerMac devices > @@ -1201,13 +1156,16 @@ CONFIG_USB_STORAGE=m > # CONFIG_USB_STORAGE_SDDR09 is not set > # CONFIG_USB_STORAGE_SDDR55 is not set > # CONFIG_USB_STORAGE_JUMPSHOT is not set > +# CONFIG_USB_STORAGE_ALAUDA is not set > # CONFIG_USB_STORAGE_ONETOUCH is not set > +# CONFIG_USB_LIBUSUAL is not set > > # > # USB Input Devices > # > CONFIG_USB_HID=y > CONFIG_USB_HIDINPUT=y > +# CONFIG_USB_HIDINPUT_POWERBOOK is not set > # CONFIG_HID_FF is not set > CONFIG_USB_HIDDEV=y > # CONFIG_USB_AIPTEK is not set > @@ -1221,6 +1179,7 @@ CONFIG_USB_HIDDEV=y > # CONFIG_USB_YEALINK is not set > # CONFIG_USB_XPAD is not set > # CONFIG_USB_ATI_REMOTE is not set > +# CONFIG_USB_ATI_REMOTE2 is not set > # CONFIG_USB_KEYSPAN_REMOTE is not set > # CONFIG_USB_APPLETOUCH is not set > > @@ -1307,6 +1266,10 @@ CONFIG_INFINIBAND_IPOIB=m > # > > # > +# EDAC - error detection and reporting (RAS) > +# > + > +# > # File systems > # > CONFIG_EXT2_FS=y > @@ -1340,6 +1303,7 @@ CONFIG_XFS_EXPORT=y > CONFIG_XFS_SECURITY=y > CONFIG_XFS_POSIX_ACL=y > # CONFIG_XFS_RT is not set > +# CONFIG_OCFS2_FS is not set > # CONFIG_MINIX_FS is not set > # CONFIG_ROMFS_FS is not set > CONFIG_INOTIFY=y > @@ -1379,6 +1343,7 @@ CONFIG_HUGETLBFS=y > CONFIG_HUGETLB_PAGE=y > CONFIG_RAMFS=y > # CONFIG_RELAYFS_FS is not set > +# CONFIG_CONFIGFS_FS is not set > > # > # Miscellaneous filesystems > @@ -1449,6 +1414,7 @@ CONFIG_MSDOS_PARTITION=y > # CONFIG_SGI_PARTITION is not set > # CONFIG_ULTRIX_PARTITION is not set > # CONFIG_SUN_PARTITION is not set > +# CONFIG_KARMA_PARTITION is not set > # CONFIG_EFI_PARTITION is not set > > # > @@ -1504,10 +1470,6 @@ CONFIG_CRC32=y > CONFIG_LIBCRC32C=m > CONFIG_ZLIB_INFLATE=y > CONFIG_ZLIB_DEFLATE=m > -CONFIG_TEXTSEARCH=y > -CONFIG_TEXTSEARCH_KMP=m > -CONFIG_TEXTSEARCH_BM=m > -CONFIG_TEXTSEARCH_FSM=m > > # > # Instrumentation Support > @@ -1520,18 +1482,20 @@ CONFIG_OPROFILE=y > # Kernel hacking > # > # CONFIG_PRINTK_TIME is not set > -CONFIG_DEBUG_KERNEL=y > CONFIG_MAGIC_SYSRQ=y > +CONFIG_DEBUG_KERNEL=y > CONFIG_LOG_BUF_SHIFT=17 > CONFIG_DETECT_SOFTLOCKUP=y > # CONFIG_SCHEDSTATS is not set > # CONFIG_DEBUG_SLAB is not set > +CONFIG_DEBUG_MUTEXES=y > # CONFIG_DEBUG_SPINLOCK is not set > # CONFIG_DEBUG_SPINLOCK_SLEEP is not set > # CONFIG_DEBUG_KOBJECT is not set > # CONFIG_DEBUG_INFO is not set > CONFIG_DEBUG_FS=y > # CONFIG_DEBUG_VM is not set > +CONFIG_FORCED_INLINING=y > # CONFIG_RCU_TORTURE_TEST is not set > CONFIG_DEBUG_STACKOVERFLOW=y > CONFIG_DEBUG_STACK_USAGE=y > @@ -1540,6 +1504,11 @@ CONFIG_XMON=y > # CONFIG_XMON_DEFAULT is not set > CONFIG_IRQSTACKS=y > CONFIG_BOOTX_TEXT=y > +# CONFIG_PPC_EARLY_DEBUG_LPAR is not set > +# CONFIG_PPC_EARLY_DEBUG_G5 is not set > +# CONFIG_PPC_EARLY_DEBUG_RTAS is not set > +# CONFIG_PPC_EARLY_DEBUG_MAPLE is not set > +# CONFIG_PPC_EARLY_DEBUG_ISERIES is not set > > # > # Security options > Index: powerpc-git/arch/powerpc/configs/pseries_defconfig > =================================================================== > --- powerpc-git.orig/arch/powerpc/configs/pseries_defconfig > +++ powerpc-git/arch/powerpc/configs/pseries_defconfig > @@ -1,7 +1,7 @@ > # > # Automatically generated make config: don't edit > -# Linux kernel version: 2.6.15-rc5 > -# Tue Dec 20 15:59:40 2005 > +# Linux kernel version: 2.6.16-rc2 > +# Fri Feb 10 17:33:32 2006 > # > CONFIG_PPC64=y > CONFIG_64BIT=y > @@ -16,6 +16,10 @@ CONFIG_COMPAT=y > CONFIG_SYSVIPC_COMPAT=y > CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y > CONFIG_ARCH_MAY_HAVE_PC_FDC=y > +CONFIG_PPC_OF=y > +CONFIG_PPC_UDBG_16550=y > +# CONFIG_GENERIC_TBSYNC is not set > +# CONFIG_DEFAULT_UIMAGE is not set > > # > # Processor support > @@ -33,7 +37,6 @@ CONFIG_NR_CPUS=128 > # Code maturity level options > # > CONFIG_EXPERIMENTAL=y > -CONFIG_CLEAN_COMPILE=y > CONFIG_LOCK_KERNEL=y > CONFIG_INIT_ENV_ARG_LIMIT=32 > > @@ -49,8 +52,6 @@ CONFIG_POSIX_MQUEUE=y > CONFIG_SYSCTL=y > CONFIG_AUDIT=y > CONFIG_AUDITSYSCALL=y > -CONFIG_HOTPLUG=y > -CONFIG_KOBJECT_UEVENT=y > CONFIG_IKCONFIG=y > CONFIG_IKCONFIG_PROC=y > CONFIG_CPUSETS=y > @@ -60,8 +61,10 @@ CONFIG_CC_OPTIMIZE_FOR_SIZE=y > CONFIG_KALLSYMS=y > CONFIG_KALLSYMS_ALL=y > # CONFIG_KALLSYMS_EXTRA_PASS is not set > +CONFIG_HOTPLUG=y > CONFIG_PRINTK=y > CONFIG_BUG=y > +CONFIG_ELF_CORE=y > CONFIG_BASE_FULL=y > CONFIG_FUTEX=y > CONFIG_EPOLL=y > @@ -70,8 +73,10 @@ CONFIG_CC_ALIGN_FUNCTIONS=0 > CONFIG_CC_ALIGN_LABELS=0 > CONFIG_CC_ALIGN_LOOPS=0 > CONFIG_CC_ALIGN_JUMPS=0 > +CONFIG_SLAB=y > # CONFIG_TINY_SHMEM is not set > CONFIG_BASE_SMALL=0 > +# CONFIG_SLOB is not set > > # > # Loadable module support > @@ -113,7 +118,6 @@ CONFIG_PPC_PSERIES=y > # CONFIG_PPC_PMAC is not set > # CONFIG_PPC_MAPLE is not set > # CONFIG_PPC_CELL is not set > -CONFIG_PPC_OF=y > CONFIG_XICS=y > # CONFIG_U3_DART is not set > CONFIG_MPIC=y > @@ -123,8 +127,8 @@ CONFIG_RTAS_PROC=y > CONFIG_RTAS_FLASH=m > # CONFIG_MMIO_NVRAM is not set > CONFIG_IBMVIO=y > +# CONFIG_IBMEBUS is not set > # CONFIG_PPC_MPC106 is not set > -# CONFIG_GENERIC_TBSYNC is not set > # CONFIG_CPU_FREQ is not set > # CONFIG_WANT_EARLY_SERIAL is not set > > @@ -145,6 +149,7 @@ CONFIG_FORCE_MAX_ZONEORDER=13 > CONFIG_IOMMU_VMERGE=y > CONFIG_HOTPLUG_CPU=y > CONFIG_KEXEC=y > +# CONFIG_CRASH_DUMP is not set > CONFIG_IRQ_ALL_CPUS=y > CONFIG_PPC_SPLPAR=y > CONFIG_EEH=y > @@ -165,6 +170,7 @@ CONFIG_HAVE_MEMORY_PRESENT=y > CONFIG_SPARSEMEM_EXTREME=y > # CONFIG_MEMORY_HOTPLUG is not set > CONFIG_SPLIT_PTLOCK_CPUS=4 > +CONFIG_MIGRATION=y > CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y > # CONFIG_PPC_64K_PAGES is not set > CONFIG_SCHED_SMT=y > @@ -209,6 +215,7 @@ CONFIG_NET=y > # > # Networking options > # > +# CONFIG_NETDEBUG is not set > CONFIG_PACKET=y > # CONFIG_PACKET_MMAP is not set > CONFIG_UNIX=y > @@ -248,6 +255,7 @@ CONFIG_NETFILTER=y > CONFIG_NETFILTER_NETLINK=y > CONFIG_NETFILTER_NETLINK_QUEUE=m > CONFIG_NETFILTER_NETLINK_LOG=m > +# CONFIG_NETFILTER_XTABLES is not set > > # > # IP: Netfilter Configuration > @@ -265,65 +273,6 @@ CONFIG_IP_NF_TFTP=m > CONFIG_IP_NF_AMANDA=m > # CONFIG_IP_NF_PPTP is not set > CONFIG_IP_NF_QUEUE=m > -CONFIG_IP_NF_IPTABLES=m > -CONFIG_IP_NF_MATCH_LIMIT=m > -CONFIG_IP_NF_MATCH_IPRANGE=m > -CONFIG_IP_NF_MATCH_MAC=m > -CONFIG_IP_NF_MATCH_PKTTYPE=m > -CONFIG_IP_NF_MATCH_MARK=m > -CONFIG_IP_NF_MATCH_MULTIPORT=m > -CONFIG_IP_NF_MATCH_TOS=m > -CONFIG_IP_NF_MATCH_RECENT=m > -CONFIG_IP_NF_MATCH_ECN=m > -CONFIG_IP_NF_MATCH_DSCP=m > -CONFIG_IP_NF_MATCH_AH_ESP=m > -CONFIG_IP_NF_MATCH_LENGTH=m > -CONFIG_IP_NF_MATCH_TTL=m > -CONFIG_IP_NF_MATCH_TCPMSS=m > -CONFIG_IP_NF_MATCH_HELPER=m > -CONFIG_IP_NF_MATCH_STATE=m > -CONFIG_IP_NF_MATCH_CONNTRACK=m > -CONFIG_IP_NF_MATCH_OWNER=m > -CONFIG_IP_NF_MATCH_ADDRTYPE=m > -CONFIG_IP_NF_MATCH_REALM=m > -CONFIG_IP_NF_MATCH_SCTP=m > -# CONFIG_IP_NF_MATCH_DCCP is not set > -CONFIG_IP_NF_MATCH_COMMENT=m > -CONFIG_IP_NF_MATCH_CONNMARK=m > -CONFIG_IP_NF_MATCH_CONNBYTES=m > -CONFIG_IP_NF_MATCH_HASHLIMIT=m > -CONFIG_IP_NF_MATCH_STRING=m > -CONFIG_IP_NF_FILTER=m > -CONFIG_IP_NF_TARGET_REJECT=m > -CONFIG_IP_NF_TARGET_LOG=m > -CONFIG_IP_NF_TARGET_ULOG=m > -CONFIG_IP_NF_TARGET_TCPMSS=m > -CONFIG_IP_NF_TARGET_NFQUEUE=m > -CONFIG_IP_NF_NAT=m > -CONFIG_IP_NF_NAT_NEEDED=y > -CONFIG_IP_NF_TARGET_MASQUERADE=m > -CONFIG_IP_NF_TARGET_REDIRECT=m > -CONFIG_IP_NF_TARGET_NETMAP=m > -CONFIG_IP_NF_TARGET_SAME=m > -CONFIG_IP_NF_NAT_SNMP_BASIC=m > -CONFIG_IP_NF_NAT_IRC=m > -CONFIG_IP_NF_NAT_FTP=m > -CONFIG_IP_NF_NAT_TFTP=m > -CONFIG_IP_NF_NAT_AMANDA=m > -CONFIG_IP_NF_MANGLE=m > -CONFIG_IP_NF_TARGET_TOS=m > -CONFIG_IP_NF_TARGET_ECN=m > -CONFIG_IP_NF_TARGET_DSCP=m > -CONFIG_IP_NF_TARGET_MARK=m > -CONFIG_IP_NF_TARGET_CLASSIFY=m > -CONFIG_IP_NF_TARGET_TTL=m > -CONFIG_IP_NF_TARGET_CONNMARK=m > -CONFIG_IP_NF_TARGET_CLUSTERIP=m > -CONFIG_IP_NF_RAW=m > -CONFIG_IP_NF_TARGET_NOTRACK=m > -CONFIG_IP_NF_ARPTABLES=m > -CONFIG_IP_NF_ARPFILTER=m > -CONFIG_IP_NF_ARP_MANGLE=m > > # > # DCCP Configuration (EXPERIMENTAL) > @@ -334,6 +283,11 @@ CONFIG_IP_NF_ARP_MANGLE=m > # SCTP Configuration (EXPERIMENTAL) > # > # CONFIG_IP_SCTP is not set > + > +# > +# TIPC Configuration (EXPERIMENTAL) > +# > +# CONFIG_TIPC is not set > # CONFIG_ATM is not set > # CONFIG_BRIDGE is not set > # CONFIG_VLAN_8021Q is not set > @@ -352,7 +306,6 @@ CONFIG_LLC=y > # QoS and/or fair queueing > # > # CONFIG_NET_SCHED is not set > -CONFIG_NET_CLS_ROUTE=y > > # > # Network testing > @@ -550,13 +503,7 @@ CONFIG_SCSI_IPR_TRACE=y > CONFIG_SCSI_IPR_DUMP=y > # CONFIG_SCSI_QLOGIC_FC is not set > # CONFIG_SCSI_QLOGIC_1280 is not set > -CONFIG_SCSI_QLA2XXX=y > -CONFIG_SCSI_QLA21XX=m > -CONFIG_SCSI_QLA22XX=m > -CONFIG_SCSI_QLA2300=m > -CONFIG_SCSI_QLA2322=m > -CONFIG_SCSI_QLA6312=m > -CONFIG_SCSI_QLA24XX=m > +# CONFIG_SCSI_QLA_FC is not set > CONFIG_SCSI_LPFC=m > # CONFIG_SCSI_DC395x is not set > # CONFIG_SCSI_DC390T is not set > @@ -678,6 +625,7 @@ CONFIG_E1000=y > # CONFIG_R8169 is not set > # CONFIG_SIS190 is not set > # CONFIG_SKGE is not set > +# CONFIG_SKY2 is not set > # CONFIG_SK98LIN is not set > # CONFIG_VIA_VELOCITY is not set > CONFIG_TIGON3=y > @@ -803,6 +751,7 @@ CONFIG_HW_CONSOLE=y > CONFIG_SERIAL_8250=y > CONFIG_SERIAL_8250_CONSOLE=y > CONFIG_SERIAL_8250_NR_UARTS=4 > +CONFIG_SERIAL_8250_RUNTIME_UARTS=4 > # CONFIG_SERIAL_8250_EXTENDED is not set > > # > @@ -909,6 +858,12 @@ CONFIG_I2C_ALGOBIT=y > # CONFIG_I2C_DEBUG_CHIP is not set > > # > +# SPI support > +# > +# CONFIG_SPI is not set > +# CONFIG_SPI_MASTER is not set > + > +# > # Dallas's 1-wire bus > # > # CONFIG_W1 is not set > @@ -976,7 +931,6 @@ CONFIG_FB_RADEON_I2C=y > # CONFIG_FB_KYRO is not set > # CONFIG_FB_3DFX is not set > # CONFIG_FB_VOODOO1 is not set > -# CONFIG_FB_CYBLA is not set > # CONFIG_FB_TRIDENT is not set > # CONFIG_FB_VIRTUAL is not set > > @@ -1061,12 +1015,15 @@ CONFIG_USB_STORAGE=y > # CONFIG_USB_STORAGE_SDDR09 is not set > # CONFIG_USB_STORAGE_SDDR55 is not set > # CONFIG_USB_STORAGE_JUMPSHOT is not set > +# CONFIG_USB_STORAGE_ALAUDA is not set > +# CONFIG_USB_LIBUSUAL is not set > > # > # USB Input Devices > # > CONFIG_USB_HID=y > CONFIG_USB_HIDINPUT=y > +# CONFIG_USB_HIDINPUT_POWERBOOK is not set > # CONFIG_HID_FF is not set > CONFIG_USB_HIDDEV=y > # CONFIG_USB_AIPTEK is not set > @@ -1080,6 +1037,7 @@ CONFIG_USB_HIDDEV=y > # CONFIG_USB_YEALINK is not set > # CONFIG_USB_XPAD is not set > # CONFIG_USB_ATI_REMOTE is not set > +# CONFIG_USB_ATI_REMOTE2 is not set > # CONFIG_USB_KEYSPAN_REMOTE is not set > # CONFIG_USB_APPLETOUCH is not set > > @@ -1167,6 +1125,10 @@ CONFIG_INFINIBAND_IPOIB=m > # > > # > +# EDAC - error detection and reporting (RAS) > +# > + > +# > # File systems > # > CONFIG_EXT2_FS=y > @@ -1200,6 +1162,7 @@ CONFIG_XFS_EXPORT=y > CONFIG_XFS_SECURITY=y > CONFIG_XFS_POSIX_ACL=y > # CONFIG_XFS_RT is not set > +# CONFIG_OCFS2_FS is not set > # CONFIG_MINIX_FS is not set > # CONFIG_ROMFS_FS is not set > CONFIG_INOTIFY=y > @@ -1240,6 +1203,7 @@ CONFIG_HUGETLBFS=y > CONFIG_HUGETLB_PAGE=y > CONFIG_RAMFS=y > # CONFIG_RELAYFS_FS is not set > +# CONFIG_CONFIGFS_FS is not set > > # > # Miscellaneous filesystems > @@ -1351,10 +1315,6 @@ CONFIG_CRC32=y > CONFIG_LIBCRC32C=m > CONFIG_ZLIB_INFLATE=y > CONFIG_ZLIB_DEFLATE=m > -CONFIG_TEXTSEARCH=y > -CONFIG_TEXTSEARCH_KMP=m > -CONFIG_TEXTSEARCH_BM=m > -CONFIG_TEXTSEARCH_FSM=m > > # > # Instrumentation Support > @@ -1367,18 +1327,20 @@ CONFIG_OPROFILE=y > # Kernel hacking > # > # CONFIG_PRINTK_TIME is not set > -CONFIG_DEBUG_KERNEL=y > CONFIG_MAGIC_SYSRQ=y > +CONFIG_DEBUG_KERNEL=y > CONFIG_LOG_BUF_SHIFT=17 > CONFIG_DETECT_SOFTLOCKUP=y > # CONFIG_SCHEDSTATS is not set > # CONFIG_DEBUG_SLAB is not set > +CONFIG_DEBUG_MUTEXES=y > # CONFIG_DEBUG_SPINLOCK is not set > # CONFIG_DEBUG_SPINLOCK_SLEEP is not set > # CONFIG_DEBUG_KOBJECT is not set > # CONFIG_DEBUG_INFO is not set > CONFIG_DEBUG_FS=y > # CONFIG_DEBUG_VM is not set > +CONFIG_FORCED_INLINING=y > # CONFIG_RCU_TORTURE_TEST is not set > CONFIG_DEBUG_STACKOVERFLOW=y > CONFIG_DEBUG_STACK_USAGE=y > @@ -1387,6 +1349,11 @@ CONFIG_XMON=y > CONFIG_XMON_DEFAULT=y > CONFIG_IRQSTACKS=y > # CONFIG_BOOTX_TEXT is not set > +# CONFIG_PPC_EARLY_DEBUG_LPAR is not set > +# CONFIG_PPC_EARLY_DEBUG_G5 is not set > +# CONFIG_PPC_EARLY_DEBUG_RTAS is not set > +# CONFIG_PPC_EARLY_DEBUG_MAPLE is not set > +# CONFIG_PPC_EARLY_DEBUG_ISERIES is not set > > # > # Security options From olof at lixom.net Mon Feb 13 10:30:31 2006 From: olof at lixom.net (Olof Johansson) Date: Sun, 12 Feb 2006 17:30:31 -0600 Subject: [PATCH] Update {g5,pseries,ppc64}_defconfig In-Reply-To: <1139782304.5247.42.camel@localhost.localdomain> References: <20060210234903.GB4795@pb15.lixom.net> <1139782304.5247.42.camel@localhost.localdomain> Message-ID: <20060212233030.GA12445@pb15.lixom.net> On Mon, Feb 13, 2006 at 09:11:44AM +1100, Benjamin Herrenschmidt wrote: > You probably also want to make tg3 built-in... Good point. New patch below. --- Update defconfigs for g5, pseries and generic ppc64. Default choices for everything, with the following exceptions: * Enable WINDFARM_PM112 on g5 and ppc64. * Increase CONFIG_NR_CPUS to 4 in g5_defconfig * CONFIG_TIGON3=y instead of =m in g5_defconfig Signed-off-by: Olof Johansson Index: powerpc-git/arch/powerpc/configs/g5_defconfig =================================================================== --- powerpc-git.orig/arch/powerpc/configs/g5_defconfig +++ powerpc-git/arch/powerpc/configs/g5_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.15-rc5 -# Tue Dec 20 15:59:30 2005 +# Linux kernel version: 2.6.16-rc2 +# Fri Feb 10 17:33:08 2006 # CONFIG_PPC64=y CONFIG_64BIT=y @@ -16,6 +16,10 @@ CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y +CONFIG_PPC_OF=y +# CONFIG_PPC_UDBG_16550 is not set +CONFIG_GENERIC_TBSYNC=y +# CONFIG_DEFAULT_UIMAGE is not set # # Processor support @@ -26,13 +30,12 @@ CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y CONFIG_PPC_STD_MMU=y CONFIG_SMP=y -CONFIG_NR_CPUS=2 +CONFIG_NR_CPUS=4 # # Code maturity level options # CONFIG_EXPERIMENTAL=y -CONFIG_CLEAN_COMPILE=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 @@ -47,8 +50,6 @@ CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set -CONFIG_HOTPLUG=y -CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_CPUSETS is not set @@ -58,8 +59,10 @@ CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set +CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y +CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y @@ -68,8 +71,10 @@ CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 +CONFIG_SLAB=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 +# CONFIG_SLOB is not set # # Loadable module support @@ -112,13 +117,12 @@ CONFIG_PPC_PMAC=y CONFIG_PPC_PMAC64=y # CONFIG_PPC_MAPLE is not set # CONFIG_PPC_CELL is not set -CONFIG_PPC_OF=y CONFIG_U3_DART=y CONFIG_MPIC=y # CONFIG_PPC_RTAS is not set # CONFIG_MMIO_NVRAM is not set +CONFIG_MPIC_BROKEN_U3=y # CONFIG_PPC_MPC106 is not set -CONFIG_GENERIC_TBSYNC=y CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y # CONFIG_CPU_FREQ_DEBUG is not set @@ -151,6 +155,7 @@ CONFIG_FORCE_MAX_ZONEORDER=13 CONFIG_IOMMU_VMERGE=y # CONFIG_HOTPLUG_CPU is not set CONFIG_KEXEC=y +# CONFIG_CRASH_DUMP is not set CONFIG_IRQ_ALL_CPUS=y # CONFIG_NUMA is not set CONFIG_ARCH_SELECT_MEMORY_MODEL=y @@ -202,6 +207,7 @@ CONFIG_NET=y # # Networking options # +# CONFIG_NETDEBUG is not set CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_UNIX=y @@ -239,6 +245,7 @@ CONFIG_NETFILTER=y # Core Netfilter Configuration # # CONFIG_NETFILTER_NETLINK is not set +# CONFIG_NETFILTER_XTABLES is not set # # IP: Netfilter Configuration @@ -255,65 +262,6 @@ CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_AMANDA=m # CONFIG_IP_NF_PPTP is not set CONFIG_IP_NF_QUEUE=m -CONFIG_IP_NF_IPTABLES=m -CONFIG_IP_NF_MATCH_LIMIT=m -CONFIG_IP_NF_MATCH_IPRANGE=m -CONFIG_IP_NF_MATCH_MAC=m -CONFIG_IP_NF_MATCH_PKTTYPE=m -CONFIG_IP_NF_MATCH_MARK=m -CONFIG_IP_NF_MATCH_MULTIPORT=m -CONFIG_IP_NF_MATCH_TOS=m -CONFIG_IP_NF_MATCH_RECENT=m -CONFIG_IP_NF_MATCH_ECN=m -CONFIG_IP_NF_MATCH_DSCP=m -CONFIG_IP_NF_MATCH_AH_ESP=m -CONFIG_IP_NF_MATCH_LENGTH=m -CONFIG_IP_NF_MATCH_TTL=m -CONFIG_IP_NF_MATCH_TCPMSS=m -CONFIG_IP_NF_MATCH_HELPER=m -CONFIG_IP_NF_MATCH_STATE=m -CONFIG_IP_NF_MATCH_CONNTRACK=m -CONFIG_IP_NF_MATCH_OWNER=m -CONFIG_IP_NF_MATCH_ADDRTYPE=m -CONFIG_IP_NF_MATCH_REALM=m -CONFIG_IP_NF_MATCH_SCTP=m -# CONFIG_IP_NF_MATCH_DCCP is not set -CONFIG_IP_NF_MATCH_COMMENT=m -CONFIG_IP_NF_MATCH_CONNMARK=m -CONFIG_IP_NF_MATCH_CONNBYTES=m -CONFIG_IP_NF_MATCH_HASHLIMIT=m -CONFIG_IP_NF_MATCH_STRING=m -CONFIG_IP_NF_FILTER=m -CONFIG_IP_NF_TARGET_REJECT=m -CONFIG_IP_NF_TARGET_LOG=m -CONFIG_IP_NF_TARGET_ULOG=m -CONFIG_IP_NF_TARGET_TCPMSS=m -CONFIG_IP_NF_TARGET_NFQUEUE=m -CONFIG_IP_NF_NAT=m -CONFIG_IP_NF_NAT_NEEDED=y -CONFIG_IP_NF_TARGET_MASQUERADE=m -CONFIG_IP_NF_TARGET_REDIRECT=m -CONFIG_IP_NF_TARGET_NETMAP=m -CONFIG_IP_NF_TARGET_SAME=m -CONFIG_IP_NF_NAT_SNMP_BASIC=m -CONFIG_IP_NF_NAT_IRC=m -CONFIG_IP_NF_NAT_FTP=m -CONFIG_IP_NF_NAT_TFTP=m -CONFIG_IP_NF_NAT_AMANDA=m -CONFIG_IP_NF_MANGLE=m -CONFIG_IP_NF_TARGET_TOS=m -CONFIG_IP_NF_TARGET_ECN=m -CONFIG_IP_NF_TARGET_DSCP=m -CONFIG_IP_NF_TARGET_MARK=m -CONFIG_IP_NF_TARGET_CLASSIFY=m -CONFIG_IP_NF_TARGET_TTL=m -CONFIG_IP_NF_TARGET_CONNMARK=m -CONFIG_IP_NF_TARGET_CLUSTERIP=m -CONFIG_IP_NF_RAW=m -CONFIG_IP_NF_TARGET_NOTRACK=m -CONFIG_IP_NF_ARPTABLES=m -CONFIG_IP_NF_ARPFILTER=m -CONFIG_IP_NF_ARP_MANGLE=m # # DCCP Configuration (EXPERIMENTAL) @@ -324,6 +272,11 @@ CONFIG_IP_NF_ARP_MANGLE=m # SCTP Configuration (EXPERIMENTAL) # # CONFIG_IP_SCTP is not set + +# +# TIPC Configuration (EXPERIMENTAL) +# +# CONFIG_TIPC is not set # CONFIG_ATM is not set # CONFIG_BRIDGE is not set # CONFIG_VLAN_8021Q is not set @@ -342,7 +295,6 @@ CONFIG_LLC=y # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set -CONFIG_NET_CLS_ROUTE=y # # Network testing @@ -545,13 +497,7 @@ CONFIG_SCSI_SATA_SVW=y # CONFIG_SCSI_IPR is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set -CONFIG_SCSI_QLA2XXX=y -# CONFIG_SCSI_QLA21XX is not set -# CONFIG_SCSI_QLA22XX is not set -# CONFIG_SCSI_QLA2300 is not set -# CONFIG_SCSI_QLA2322 is not set -# CONFIG_SCSI_QLA6312 is not set -# CONFIG_SCSI_QLA24XX is not set +# CONFIG_SCSI_QLA_FC is not set # CONFIG_SCSI_LPFC is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set @@ -614,7 +560,6 @@ CONFIG_IEEE1394_SBP2=m CONFIG_IEEE1394_ETH1394=m CONFIG_IEEE1394_DV1394=m CONFIG_IEEE1394_RAWIO=y -# CONFIG_IEEE1394_CMP is not set # # I2O device support @@ -630,6 +575,7 @@ CONFIG_THERM_PM72=y CONFIG_WINDFARM=y CONFIG_WINDFARM_PM81=y CONFIG_WINDFARM_PM91=y +CONFIG_WINDFARM_PM112=y # # Network device support @@ -682,8 +628,9 @@ CONFIG_E1000=y # CONFIG_R8169 is not set # CONFIG_SIS190 is not set # CONFIG_SKGE is not set +# CONFIG_SKY2 is not set # CONFIG_SK98LIN is not set -CONFIG_TIGON3=m +CONFIG_TIGON3=y # CONFIG_BNX2 is not set # CONFIG_MV643XX_ETH is not set @@ -861,8 +808,7 @@ CONFIG_I2C_ALGOBIT=y # CONFIG_I2C_I801 is not set # CONFIG_I2C_I810 is not set # CONFIG_I2C_PIIX4 is not set -CONFIG_I2C_KEYWEST=y -CONFIG_I2C_PMAC_SMU=y +CONFIG_I2C_POWERMAC=y # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_PROSAVAGE is not set @@ -895,6 +841,12 @@ CONFIG_I2C_PMAC_SMU=y # CONFIG_I2C_DEBUG_CHIP is not set # +# SPI support +# +# CONFIG_SPI is not set +# CONFIG_SPI_MASTER is not set + +# # Dallas's 1-wire bus # # CONFIG_W1 is not set @@ -961,7 +913,6 @@ CONFIG_FB_RADEON_I2C=y # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set -# CONFIG_FB_CYBLA is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_VIRTUAL is not set @@ -1008,9 +959,10 @@ CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_SEQUENCER_OSS=y +# CONFIG_SND_DYNAMIC_MINORS is not set +CONFIG_SND_SUPPORT_OLD_API=y # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set -CONFIG_SND_GENERIC_DRIVER=y # # Generic devices @@ -1024,6 +976,8 @@ CONFIG_SND_GENERIC_DRIVER=y # # PCI devices # +# CONFIG_SND_AD1889 is not set +# CONFIG_SND_ALS4000 is not set # CONFIG_SND_ALI5451 is not set # CONFIG_SND_ATIIXP is not set # CONFIG_SND_ATIIXP_MODEM is not set @@ -1032,39 +986,38 @@ CONFIG_SND_GENERIC_DRIVER=y # CONFIG_SND_AU8830 is not set # CONFIG_SND_AZT3328 is not set # CONFIG_SND_BT87X is not set -# CONFIG_SND_CS46XX is not set +# CONFIG_SND_CA0106 is not set +# CONFIG_SND_CMIPCI is not set # CONFIG_SND_CS4281 is not set +# CONFIG_SND_CS46XX is not set # CONFIG_SND_EMU10K1 is not set # CONFIG_SND_EMU10K1X is not set -# CONFIG_SND_CA0106 is not set -# CONFIG_SND_KORG1212 is not set -# CONFIG_SND_MIXART is not set -# CONFIG_SND_NM256 is not set -# CONFIG_SND_RME32 is not set -# CONFIG_SND_RME96 is not set -# CONFIG_SND_RME9652 is not set -# CONFIG_SND_HDSP is not set -# CONFIG_SND_HDSPM is not set -# CONFIG_SND_TRIDENT is not set -# CONFIG_SND_YMFPCI is not set -# CONFIG_SND_AD1889 is not set -# CONFIG_SND_ALS4000 is not set -# CONFIG_SND_CMIPCI is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set -# CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_FM801 is not set +# CONFIG_SND_HDA_INTEL is not set +# CONFIG_SND_HDSP is not set +# CONFIG_SND_HDSPM is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set # CONFIG_SND_INTEL8X0 is not set # CONFIG_SND_INTEL8X0M is not set +# CONFIG_SND_KORG1212 is not set +# CONFIG_SND_MAESTRO3 is not set +# CONFIG_SND_MIXART is not set +# CONFIG_SND_NM256 is not set +# CONFIG_SND_PCXHR is not set +# CONFIG_SND_RME32 is not set +# CONFIG_SND_RME96 is not set +# CONFIG_SND_RME9652 is not set # CONFIG_SND_SONICVIBES is not set +# CONFIG_SND_TRIDENT is not set # CONFIG_SND_VIA82XX is not set # CONFIG_SND_VIA82XX_MODEM is not set # CONFIG_SND_VX222 is not set -# CONFIG_SND_HDA_INTEL is not set +# CONFIG_SND_YMFPCI is not set # # ALSA PowerMac devices @@ -1136,13 +1089,16 @@ CONFIG_USB_STORAGE_DPCM=y CONFIG_USB_STORAGE_SDDR09=y CONFIG_USB_STORAGE_SDDR55=y CONFIG_USB_STORAGE_JUMPSHOT=y +# CONFIG_USB_STORAGE_ALAUDA is not set # CONFIG_USB_STORAGE_ONETOUCH is not set +# CONFIG_USB_LIBUSUAL is not set # # USB Input Devices # CONFIG_USB_HID=y CONFIG_USB_HIDINPUT=y +# CONFIG_USB_HIDINPUT_POWERBOOK is not set CONFIG_HID_FF=y CONFIG_HID_PID=y CONFIG_LOGITECH_FF=y @@ -1159,6 +1115,7 @@ CONFIG_USB_HIDDEV=y # CONFIG_USB_YEALINK is not set # CONFIG_USB_XPAD is not set # CONFIG_USB_ATI_REMOTE is not set +# CONFIG_USB_ATI_REMOTE2 is not set # CONFIG_USB_KEYSPAN_REMOTE is not set # CONFIG_USB_APPLETOUCH is not set @@ -1207,6 +1164,7 @@ CONFIG_USB_SERIAL_GENERIC=y # CONFIG_USB_SERIAL_AIRPRIME is not set # CONFIG_USB_SERIAL_ANYDATA is not set CONFIG_USB_SERIAL_BELKIN=m +# CONFIG_USB_SERIAL_WHITEHEAT is not set CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m # CONFIG_USB_SERIAL_CP2101 is not set CONFIG_USB_SERIAL_CYPRESS_M8=m @@ -1288,6 +1246,10 @@ CONFIG_USB_EZUSB=y # # +# EDAC - error detection and reporting (RAS) +# + +# # File systems # CONFIG_EXT2_FS=y @@ -1317,6 +1279,7 @@ CONFIG_XFS_EXPORT=y CONFIG_XFS_SECURITY=y CONFIG_XFS_POSIX_ACL=y # CONFIG_XFS_RT is not set +# CONFIG_OCFS2_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_ROMFS_FS is not set CONFIG_INOTIFY=y @@ -1357,6 +1320,7 @@ CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y CONFIG_RAMFS=y # CONFIG_RELAYFS_FS is not set +# CONFIG_CONFIGFS_FS is not set # # Miscellaneous filesystems @@ -1426,6 +1390,7 @@ CONFIG_MSDOS_PARTITION=y # CONFIG_SGI_PARTITION is not set # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set +# CONFIG_KARMA_PARTITION is not set # CONFIG_EFI_PARTITION is not set # @@ -1481,10 +1446,6 @@ CONFIG_CRC32=y CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=m -CONFIG_TEXTSEARCH=y -CONFIG_TEXTSEARCH_KMP=m -CONFIG_TEXTSEARCH_BM=m -CONFIG_TEXTSEARCH_FSM=m # # Instrumentation Support @@ -1497,24 +1458,31 @@ CONFIG_OPROFILE=y # Kernel hacking # # CONFIG_PRINTK_TIME is not set -CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y +CONFIG_DEBUG_KERNEL=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_DETECT_SOFTLOCKUP=y # CONFIG_SCHEDSTATS is not set # CONFIG_DEBUG_SLAB is not set +CONFIG_DEBUG_MUTEXES=y # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_INFO is not set CONFIG_DEBUG_FS=y # CONFIG_DEBUG_VM is not set +CONFIG_FORCED_INLINING=y # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUGGER is not set CONFIG_IRQSTACKS=y CONFIG_BOOTX_TEXT=y +# CONFIG_PPC_EARLY_DEBUG_LPAR is not set +# CONFIG_PPC_EARLY_DEBUG_G5 is not set +# CONFIG_PPC_EARLY_DEBUG_RTAS is not set +# CONFIG_PPC_EARLY_DEBUG_MAPLE is not set +# CONFIG_PPC_EARLY_DEBUG_ISERIES is not set # # Security options Index: powerpc-git/arch/powerpc/configs/ppc64_defconfig =================================================================== --- powerpc-git.orig/arch/powerpc/configs/ppc64_defconfig +++ powerpc-git/arch/powerpc/configs/ppc64_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.15-rc5 -# Tue Dec 20 15:59:38 2005 +# Linux kernel version: 2.6.16-rc2 +# Fri Feb 10 17:32:14 2006 # CONFIG_PPC64=y CONFIG_64BIT=y @@ -16,6 +16,10 @@ CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y +CONFIG_PPC_OF=y +CONFIG_PPC_UDBG_16550=y +CONFIG_GENERIC_TBSYNC=y +# CONFIG_DEFAULT_UIMAGE is not set # # Processor support @@ -33,7 +37,6 @@ CONFIG_NR_CPUS=32 # Code maturity level options # CONFIG_EXPERIMENTAL=y -CONFIG_CLEAN_COMPILE=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 @@ -48,8 +51,6 @@ CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set -CONFIG_HOTPLUG=y -CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_CPUSETS=y @@ -59,8 +60,10 @@ CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set +CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y +CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y @@ -69,8 +72,10 @@ CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 +CONFIG_SLAB=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 +# CONFIG_SLOB is not set # # Loadable module support @@ -113,7 +118,6 @@ CONFIG_PPC_PMAC=y CONFIG_PPC_PMAC64=y CONFIG_PPC_MAPLE=y # CONFIG_PPC_CELL is not set -CONFIG_PPC_OF=y CONFIG_XICS=y CONFIG_U3_DART=y CONFIG_MPIC=y @@ -124,8 +128,8 @@ CONFIG_RTAS_FLASH=m # CONFIG_MMIO_NVRAM is not set CONFIG_MPIC_BROKEN_U3=y CONFIG_IBMVIO=y +# CONFIG_IBMEBUS is not set # CONFIG_PPC_MPC106 is not set -CONFIG_GENERIC_TBSYNC=y CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y # CONFIG_CPU_FREQ_DEBUG is not set @@ -158,6 +162,7 @@ CONFIG_FORCE_MAX_ZONEORDER=13 CONFIG_IOMMU_VMERGE=y CONFIG_HOTPLUG_CPU=y CONFIG_KEXEC=y +# CONFIG_CRASH_DUMP is not set CONFIG_IRQ_ALL_CPUS=y CONFIG_PPC_SPLPAR=y CONFIG_EEH=y @@ -178,6 +183,7 @@ CONFIG_HAVE_MEMORY_PRESENT=y CONFIG_SPARSEMEM_EXTREME=y # CONFIG_MEMORY_HOTPLUG is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +CONFIG_MIGRATION=y # CONFIG_PPC_64K_PAGES is not set # CONFIG_SCHED_SMT is not set CONFIG_PROC_DEVICETREE=y @@ -221,6 +227,7 @@ CONFIG_NET=y # # Networking options # +# CONFIG_NETDEBUG is not set CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_UNIX=y @@ -260,6 +267,7 @@ CONFIG_NETFILTER=y CONFIG_NETFILTER_NETLINK=y CONFIG_NETFILTER_NETLINK_QUEUE=m CONFIG_NETFILTER_NETLINK_LOG=m +# CONFIG_NETFILTER_XTABLES is not set # # IP: Netfilter Configuration @@ -277,65 +285,6 @@ CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_AMANDA=m # CONFIG_IP_NF_PPTP is not set CONFIG_IP_NF_QUEUE=m -CONFIG_IP_NF_IPTABLES=m -CONFIG_IP_NF_MATCH_LIMIT=m -CONFIG_IP_NF_MATCH_IPRANGE=m -CONFIG_IP_NF_MATCH_MAC=m -CONFIG_IP_NF_MATCH_PKTTYPE=m -CONFIG_IP_NF_MATCH_MARK=m -CONFIG_IP_NF_MATCH_MULTIPORT=m -CONFIG_IP_NF_MATCH_TOS=m -CONFIG_IP_NF_MATCH_RECENT=m -CONFIG_IP_NF_MATCH_ECN=m -CONFIG_IP_NF_MATCH_DSCP=m -CONFIG_IP_NF_MATCH_AH_ESP=m -CONFIG_IP_NF_MATCH_LENGTH=m -CONFIG_IP_NF_MATCH_TTL=m -CONFIG_IP_NF_MATCH_TCPMSS=m -CONFIG_IP_NF_MATCH_HELPER=m -CONFIG_IP_NF_MATCH_STATE=m -CONFIG_IP_NF_MATCH_CONNTRACK=m -CONFIG_IP_NF_MATCH_OWNER=m -CONFIG_IP_NF_MATCH_ADDRTYPE=m -CONFIG_IP_NF_MATCH_REALM=m -CONFIG_IP_NF_MATCH_SCTP=m -CONFIG_IP_NF_MATCH_DCCP=m -CONFIG_IP_NF_MATCH_COMMENT=m -CONFIG_IP_NF_MATCH_CONNMARK=m -CONFIG_IP_NF_MATCH_CONNBYTES=m -CONFIG_IP_NF_MATCH_HASHLIMIT=m -CONFIG_IP_NF_MATCH_STRING=m -CONFIG_IP_NF_FILTER=m -CONFIG_IP_NF_TARGET_REJECT=m -CONFIG_IP_NF_TARGET_LOG=m -CONFIG_IP_NF_TARGET_ULOG=m -CONFIG_IP_NF_TARGET_TCPMSS=m -CONFIG_IP_NF_TARGET_NFQUEUE=m -CONFIG_IP_NF_NAT=m -CONFIG_IP_NF_NAT_NEEDED=y -CONFIG_IP_NF_TARGET_MASQUERADE=m -CONFIG_IP_NF_TARGET_REDIRECT=m -CONFIG_IP_NF_TARGET_NETMAP=m -CONFIG_IP_NF_TARGET_SAME=m -CONFIG_IP_NF_NAT_SNMP_BASIC=m -CONFIG_IP_NF_NAT_IRC=m -CONFIG_IP_NF_NAT_FTP=m -CONFIG_IP_NF_NAT_TFTP=m -CONFIG_IP_NF_NAT_AMANDA=m -CONFIG_IP_NF_MANGLE=m -CONFIG_IP_NF_TARGET_TOS=m -CONFIG_IP_NF_TARGET_ECN=m -CONFIG_IP_NF_TARGET_DSCP=m -CONFIG_IP_NF_TARGET_MARK=m -CONFIG_IP_NF_TARGET_CLASSIFY=m -CONFIG_IP_NF_TARGET_TTL=m -CONFIG_IP_NF_TARGET_CONNMARK=m -CONFIG_IP_NF_TARGET_CLUSTERIP=m -CONFIG_IP_NF_RAW=m -CONFIG_IP_NF_TARGET_NOTRACK=m -CONFIG_IP_NF_ARPTABLES=m -CONFIG_IP_NF_ARPFILTER=m -CONFIG_IP_NF_ARP_MANGLE=m # # DCCP Configuration (EXPERIMENTAL) @@ -346,6 +295,11 @@ CONFIG_IP_NF_ARP_MANGLE=m # SCTP Configuration (EXPERIMENTAL) # # CONFIG_IP_SCTP is not set + +# +# TIPC Configuration (EXPERIMENTAL) +# +# CONFIG_TIPC is not set # CONFIG_ATM is not set # CONFIG_BRIDGE is not set # CONFIG_VLAN_8021Q is not set @@ -364,7 +318,6 @@ CONFIG_LLC=y # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set -CONFIG_NET_CLS_ROUTE=y # # Network testing @@ -572,13 +525,7 @@ CONFIG_SCSI_IPR_TRACE=y CONFIG_SCSI_IPR_DUMP=y # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set -CONFIG_SCSI_QLA2XXX=y -CONFIG_SCSI_QLA21XX=m -CONFIG_SCSI_QLA22XX=m -CONFIG_SCSI_QLA2300=m -CONFIG_SCSI_QLA2322=m -CONFIG_SCSI_QLA6312=m -CONFIG_SCSI_QLA24XX=m +# CONFIG_SCSI_QLA_FC is not set CONFIG_SCSI_LPFC=m # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set @@ -642,8 +589,6 @@ CONFIG_IEEE1394_SBP2=m CONFIG_IEEE1394_ETH1394=m CONFIG_IEEE1394_DV1394=m CONFIG_IEEE1394_RAWIO=y -CONFIG_IEEE1394_CMP=m -CONFIG_IEEE1394_AMDTP=m # # I2O device support @@ -659,6 +604,7 @@ CONFIG_THERM_PM72=y CONFIG_WINDFARM=y CONFIG_WINDFARM_PM81=y CONFIG_WINDFARM_PM91=y +CONFIG_WINDFARM_PM112=y # # Network device support @@ -731,6 +677,7 @@ CONFIG_E1000=y # CONFIG_R8169 is not set # CONFIG_SIS190 is not set # CONFIG_SKGE is not set +# CONFIG_SKY2 is not set # CONFIG_SK98LIN is not set # CONFIG_VIA_VELOCITY is not set CONFIG_TIGON3=y @@ -853,6 +800,7 @@ CONFIG_HW_CONSOLE=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_NR_UARTS=4 +CONFIG_SERIAL_8250_RUNTIME_UARTS=4 # CONFIG_SERIAL_8250_EXTENDED is not set # @@ -880,6 +828,7 @@ CONFIG_HVCS=m # CONFIG_WATCHDOG is not set # CONFIG_RTC is not set CONFIG_GEN_RTC=y +# CONFIG_GEN_RTC_X is not set # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set @@ -923,8 +872,7 @@ CONFIG_I2C_AMD8111=y # CONFIG_I2C_I801 is not set # CONFIG_I2C_I810 is not set # CONFIG_I2C_PIIX4 is not set -CONFIG_I2C_KEYWEST=y -CONFIG_I2C_PMAC_SMU=y +CONFIG_I2C_POWERMAC=y # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_PROSAVAGE is not set @@ -957,6 +905,12 @@ CONFIG_I2C_PMAC_SMU=y # CONFIG_I2C_DEBUG_CHIP is not set # +# SPI support +# +# CONFIG_SPI is not set +# CONFIG_SPI_MASTER is not set + +# # Dallas's 1-wire bus # # CONFIG_W1 is not set @@ -1028,7 +982,6 @@ CONFIG_FB_RADEON_I2C=y # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set -# CONFIG_FB_CYBLA is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_VIRTUAL is not set @@ -1073,9 +1026,10 @@ CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_SEQUENCER_OSS=y +# CONFIG_SND_DYNAMIC_MINORS is not set +CONFIG_SND_SUPPORT_OLD_API=y # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set -CONFIG_SND_GENERIC_DRIVER=y # # Generic devices @@ -1089,6 +1043,8 @@ CONFIG_SND_GENERIC_DRIVER=y # # PCI devices # +# CONFIG_SND_AD1889 is not set +# CONFIG_SND_ALS4000 is not set # CONFIG_SND_ALI5451 is not set # CONFIG_SND_ATIIXP is not set # CONFIG_SND_ATIIXP_MODEM is not set @@ -1097,39 +1053,38 @@ CONFIG_SND_GENERIC_DRIVER=y # CONFIG_SND_AU8830 is not set # CONFIG_SND_AZT3328 is not set # CONFIG_SND_BT87X is not set -# CONFIG_SND_CS46XX is not set +# CONFIG_SND_CA0106 is not set +# CONFIG_SND_CMIPCI is not set # CONFIG_SND_CS4281 is not set +# CONFIG_SND_CS46XX is not set # CONFIG_SND_EMU10K1 is not set # CONFIG_SND_EMU10K1X is not set -# CONFIG_SND_CA0106 is not set -# CONFIG_SND_KORG1212 is not set -# CONFIG_SND_MIXART is not set -# CONFIG_SND_NM256 is not set -# CONFIG_SND_RME32 is not set -# CONFIG_SND_RME96 is not set -# CONFIG_SND_RME9652 is not set -# CONFIG_SND_HDSP is not set -# CONFIG_SND_HDSPM is not set -# CONFIG_SND_TRIDENT is not set -# CONFIG_SND_YMFPCI is not set -# CONFIG_SND_AD1889 is not set -# CONFIG_SND_ALS4000 is not set -# CONFIG_SND_CMIPCI is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set -# CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_FM801 is not set +# CONFIG_SND_HDA_INTEL is not set +# CONFIG_SND_HDSP is not set +# CONFIG_SND_HDSPM is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set # CONFIG_SND_INTEL8X0 is not set # CONFIG_SND_INTEL8X0M is not set +# CONFIG_SND_KORG1212 is not set +# CONFIG_SND_MAESTRO3 is not set +# CONFIG_SND_MIXART is not set +# CONFIG_SND_NM256 is not set +# CONFIG_SND_PCXHR is not set +# CONFIG_SND_RME32 is not set +# CONFIG_SND_RME96 is not set +# CONFIG_SND_RME9652 is not set # CONFIG_SND_SONICVIBES is not set +# CONFIG_SND_TRIDENT is not set # CONFIG_SND_VIA82XX is not set # CONFIG_SND_VIA82XX_MODEM is not set # CONFIG_SND_VX222 is not set -# CONFIG_SND_HDA_INTEL is not set +# CONFIG_SND_YMFPCI is not set # # ALSA PowerMac devices @@ -1201,13 +1156,16 @@ CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set +# CONFIG_USB_STORAGE_ALAUDA is not set # CONFIG_USB_STORAGE_ONETOUCH is not set +# CONFIG_USB_LIBUSUAL is not set # # USB Input Devices # CONFIG_USB_HID=y CONFIG_USB_HIDINPUT=y +# CONFIG_USB_HIDINPUT_POWERBOOK is not set # CONFIG_HID_FF is not set CONFIG_USB_HIDDEV=y # CONFIG_USB_AIPTEK is not set @@ -1221,6 +1179,7 @@ CONFIG_USB_HIDDEV=y # CONFIG_USB_YEALINK is not set # CONFIG_USB_XPAD is not set # CONFIG_USB_ATI_REMOTE is not set +# CONFIG_USB_ATI_REMOTE2 is not set # CONFIG_USB_KEYSPAN_REMOTE is not set # CONFIG_USB_APPLETOUCH is not set @@ -1307,6 +1266,10 @@ CONFIG_INFINIBAND_IPOIB=m # # +# EDAC - error detection and reporting (RAS) +# + +# # File systems # CONFIG_EXT2_FS=y @@ -1340,6 +1303,7 @@ CONFIG_XFS_EXPORT=y CONFIG_XFS_SECURITY=y CONFIG_XFS_POSIX_ACL=y # CONFIG_XFS_RT is not set +# CONFIG_OCFS2_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_ROMFS_FS is not set CONFIG_INOTIFY=y @@ -1379,6 +1343,7 @@ CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y CONFIG_RAMFS=y # CONFIG_RELAYFS_FS is not set +# CONFIG_CONFIGFS_FS is not set # # Miscellaneous filesystems @@ -1449,6 +1414,7 @@ CONFIG_MSDOS_PARTITION=y # CONFIG_SGI_PARTITION is not set # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set +# CONFIG_KARMA_PARTITION is not set # CONFIG_EFI_PARTITION is not set # @@ -1504,10 +1470,6 @@ CONFIG_CRC32=y CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=m -CONFIG_TEXTSEARCH=y -CONFIG_TEXTSEARCH_KMP=m -CONFIG_TEXTSEARCH_BM=m -CONFIG_TEXTSEARCH_FSM=m # # Instrumentation Support @@ -1520,18 +1482,20 @@ CONFIG_OPROFILE=y # Kernel hacking # # CONFIG_PRINTK_TIME is not set -CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y +CONFIG_DEBUG_KERNEL=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_DETECT_SOFTLOCKUP=y # CONFIG_SCHEDSTATS is not set # CONFIG_DEBUG_SLAB is not set +CONFIG_DEBUG_MUTEXES=y # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_INFO is not set CONFIG_DEBUG_FS=y # CONFIG_DEBUG_VM is not set +CONFIG_FORCED_INLINING=y # CONFIG_RCU_TORTURE_TEST is not set CONFIG_DEBUG_STACKOVERFLOW=y CONFIG_DEBUG_STACK_USAGE=y @@ -1540,6 +1504,11 @@ CONFIG_XMON=y # CONFIG_XMON_DEFAULT is not set CONFIG_IRQSTACKS=y CONFIG_BOOTX_TEXT=y +# CONFIG_PPC_EARLY_DEBUG_LPAR is not set +# CONFIG_PPC_EARLY_DEBUG_G5 is not set +# CONFIG_PPC_EARLY_DEBUG_RTAS is not set +# CONFIG_PPC_EARLY_DEBUG_MAPLE is not set +# CONFIG_PPC_EARLY_DEBUG_ISERIES is not set # # Security options Index: powerpc-git/arch/powerpc/configs/pseries_defconfig =================================================================== --- powerpc-git.orig/arch/powerpc/configs/pseries_defconfig +++ powerpc-git/arch/powerpc/configs/pseries_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.15-rc5 -# Tue Dec 20 15:59:40 2005 +# Linux kernel version: 2.6.16-rc2 +# Fri Feb 10 17:33:32 2006 # CONFIG_PPC64=y CONFIG_64BIT=y @@ -16,6 +16,10 @@ CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y +CONFIG_PPC_OF=y +CONFIG_PPC_UDBG_16550=y +# CONFIG_GENERIC_TBSYNC is not set +# CONFIG_DEFAULT_UIMAGE is not set # # Processor support @@ -33,7 +37,6 @@ CONFIG_NR_CPUS=128 # Code maturity level options # CONFIG_EXPERIMENTAL=y -CONFIG_CLEAN_COMPILE=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 @@ -49,8 +52,6 @@ CONFIG_POSIX_MQUEUE=y CONFIG_SYSCTL=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y -CONFIG_HOTPLUG=y -CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_CPUSETS=y @@ -60,8 +61,10 @@ CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set +CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y +CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y @@ -70,8 +73,10 @@ CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 +CONFIG_SLAB=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 +# CONFIG_SLOB is not set # # Loadable module support @@ -113,7 +118,6 @@ CONFIG_PPC_PSERIES=y # CONFIG_PPC_PMAC is not set # CONFIG_PPC_MAPLE is not set # CONFIG_PPC_CELL is not set -CONFIG_PPC_OF=y CONFIG_XICS=y # CONFIG_U3_DART is not set CONFIG_MPIC=y @@ -123,8 +127,8 @@ CONFIG_RTAS_PROC=y CONFIG_RTAS_FLASH=m # CONFIG_MMIO_NVRAM is not set CONFIG_IBMVIO=y +# CONFIG_IBMEBUS is not set # CONFIG_PPC_MPC106 is not set -# CONFIG_GENERIC_TBSYNC is not set # CONFIG_CPU_FREQ is not set # CONFIG_WANT_EARLY_SERIAL is not set @@ -145,6 +149,7 @@ CONFIG_FORCE_MAX_ZONEORDER=13 CONFIG_IOMMU_VMERGE=y CONFIG_HOTPLUG_CPU=y CONFIG_KEXEC=y +# CONFIG_CRASH_DUMP is not set CONFIG_IRQ_ALL_CPUS=y CONFIG_PPC_SPLPAR=y CONFIG_EEH=y @@ -165,6 +170,7 @@ CONFIG_HAVE_MEMORY_PRESENT=y CONFIG_SPARSEMEM_EXTREME=y # CONFIG_MEMORY_HOTPLUG is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +CONFIG_MIGRATION=y CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y # CONFIG_PPC_64K_PAGES is not set CONFIG_SCHED_SMT=y @@ -209,6 +215,7 @@ CONFIG_NET=y # # Networking options # +# CONFIG_NETDEBUG is not set CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_UNIX=y @@ -248,6 +255,7 @@ CONFIG_NETFILTER=y CONFIG_NETFILTER_NETLINK=y CONFIG_NETFILTER_NETLINK_QUEUE=m CONFIG_NETFILTER_NETLINK_LOG=m +# CONFIG_NETFILTER_XTABLES is not set # # IP: Netfilter Configuration @@ -265,65 +273,6 @@ CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_AMANDA=m # CONFIG_IP_NF_PPTP is not set CONFIG_IP_NF_QUEUE=m -CONFIG_IP_NF_IPTABLES=m -CONFIG_IP_NF_MATCH_LIMIT=m -CONFIG_IP_NF_MATCH_IPRANGE=m -CONFIG_IP_NF_MATCH_MAC=m -CONFIG_IP_NF_MATCH_PKTTYPE=m -CONFIG_IP_NF_MATCH_MARK=m -CONFIG_IP_NF_MATCH_MULTIPORT=m -CONFIG_IP_NF_MATCH_TOS=m -CONFIG_IP_NF_MATCH_RECENT=m -CONFIG_IP_NF_MATCH_ECN=m -CONFIG_IP_NF_MATCH_DSCP=m -CONFIG_IP_NF_MATCH_AH_ESP=m -CONFIG_IP_NF_MATCH_LENGTH=m -CONFIG_IP_NF_MATCH_TTL=m -CONFIG_IP_NF_MATCH_TCPMSS=m -CONFIG_IP_NF_MATCH_HELPER=m -CONFIG_IP_NF_MATCH_STATE=m -CONFIG_IP_NF_MATCH_CONNTRACK=m -CONFIG_IP_NF_MATCH_OWNER=m -CONFIG_IP_NF_MATCH_ADDRTYPE=m -CONFIG_IP_NF_MATCH_REALM=m -CONFIG_IP_NF_MATCH_SCTP=m -# CONFIG_IP_NF_MATCH_DCCP is not set -CONFIG_IP_NF_MATCH_COMMENT=m -CONFIG_IP_NF_MATCH_CONNMARK=m -CONFIG_IP_NF_MATCH_CONNBYTES=m -CONFIG_IP_NF_MATCH_HASHLIMIT=m -CONFIG_IP_NF_MATCH_STRING=m -CONFIG_IP_NF_FILTER=m -CONFIG_IP_NF_TARGET_REJECT=m -CONFIG_IP_NF_TARGET_LOG=m -CONFIG_IP_NF_TARGET_ULOG=m -CONFIG_IP_NF_TARGET_TCPMSS=m -CONFIG_IP_NF_TARGET_NFQUEUE=m -CONFIG_IP_NF_NAT=m -CONFIG_IP_NF_NAT_NEEDED=y -CONFIG_IP_NF_TARGET_MASQUERADE=m -CONFIG_IP_NF_TARGET_REDIRECT=m -CONFIG_IP_NF_TARGET_NETMAP=m -CONFIG_IP_NF_TARGET_SAME=m -CONFIG_IP_NF_NAT_SNMP_BASIC=m -CONFIG_IP_NF_NAT_IRC=m -CONFIG_IP_NF_NAT_FTP=m -CONFIG_IP_NF_NAT_TFTP=m -CONFIG_IP_NF_NAT_AMANDA=m -CONFIG_IP_NF_MANGLE=m -CONFIG_IP_NF_TARGET_TOS=m -CONFIG_IP_NF_TARGET_ECN=m -CONFIG_IP_NF_TARGET_DSCP=m -CONFIG_IP_NF_TARGET_MARK=m -CONFIG_IP_NF_TARGET_CLASSIFY=m -CONFIG_IP_NF_TARGET_TTL=m -CONFIG_IP_NF_TARGET_CONNMARK=m -CONFIG_IP_NF_TARGET_CLUSTERIP=m -CONFIG_IP_NF_RAW=m -CONFIG_IP_NF_TARGET_NOTRACK=m -CONFIG_IP_NF_ARPTABLES=m -CONFIG_IP_NF_ARPFILTER=m -CONFIG_IP_NF_ARP_MANGLE=m # # DCCP Configuration (EXPERIMENTAL) @@ -334,6 +283,11 @@ CONFIG_IP_NF_ARP_MANGLE=m # SCTP Configuration (EXPERIMENTAL) # # CONFIG_IP_SCTP is not set + +# +# TIPC Configuration (EXPERIMENTAL) +# +# CONFIG_TIPC is not set # CONFIG_ATM is not set # CONFIG_BRIDGE is not set # CONFIG_VLAN_8021Q is not set @@ -352,7 +306,6 @@ CONFIG_LLC=y # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set -CONFIG_NET_CLS_ROUTE=y # # Network testing @@ -550,13 +503,7 @@ CONFIG_SCSI_IPR_TRACE=y CONFIG_SCSI_IPR_DUMP=y # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set -CONFIG_SCSI_QLA2XXX=y -CONFIG_SCSI_QLA21XX=m -CONFIG_SCSI_QLA22XX=m -CONFIG_SCSI_QLA2300=m -CONFIG_SCSI_QLA2322=m -CONFIG_SCSI_QLA6312=m -CONFIG_SCSI_QLA24XX=m +# CONFIG_SCSI_QLA_FC is not set CONFIG_SCSI_LPFC=m # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set @@ -678,6 +625,7 @@ CONFIG_E1000=y # CONFIG_R8169 is not set # CONFIG_SIS190 is not set # CONFIG_SKGE is not set +# CONFIG_SKY2 is not set # CONFIG_SK98LIN is not set # CONFIG_VIA_VELOCITY is not set CONFIG_TIGON3=y @@ -803,6 +751,7 @@ CONFIG_HW_CONSOLE=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_NR_UARTS=4 +CONFIG_SERIAL_8250_RUNTIME_UARTS=4 # CONFIG_SERIAL_8250_EXTENDED is not set # @@ -909,6 +858,12 @@ CONFIG_I2C_ALGOBIT=y # CONFIG_I2C_DEBUG_CHIP is not set # +# SPI support +# +# CONFIG_SPI is not set +# CONFIG_SPI_MASTER is not set + +# # Dallas's 1-wire bus # # CONFIG_W1 is not set @@ -976,7 +931,6 @@ CONFIG_FB_RADEON_I2C=y # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set -# CONFIG_FB_CYBLA is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_VIRTUAL is not set @@ -1061,12 +1015,15 @@ CONFIG_USB_STORAGE=y # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set +# CONFIG_USB_STORAGE_ALAUDA is not set +# CONFIG_USB_LIBUSUAL is not set # # USB Input Devices # CONFIG_USB_HID=y CONFIG_USB_HIDINPUT=y +# CONFIG_USB_HIDINPUT_POWERBOOK is not set # CONFIG_HID_FF is not set CONFIG_USB_HIDDEV=y # CONFIG_USB_AIPTEK is not set @@ -1080,6 +1037,7 @@ CONFIG_USB_HIDDEV=y # CONFIG_USB_YEALINK is not set # CONFIG_USB_XPAD is not set # CONFIG_USB_ATI_REMOTE is not set +# CONFIG_USB_ATI_REMOTE2 is not set # CONFIG_USB_KEYSPAN_REMOTE is not set # CONFIG_USB_APPLETOUCH is not set @@ -1167,6 +1125,10 @@ CONFIG_INFINIBAND_IPOIB=m # # +# EDAC - error detection and reporting (RAS) +# + +# # File systems # CONFIG_EXT2_FS=y @@ -1200,6 +1162,7 @@ CONFIG_XFS_EXPORT=y CONFIG_XFS_SECURITY=y CONFIG_XFS_POSIX_ACL=y # CONFIG_XFS_RT is not set +# CONFIG_OCFS2_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_ROMFS_FS is not set CONFIG_INOTIFY=y @@ -1240,6 +1203,7 @@ CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y CONFIG_RAMFS=y # CONFIG_RELAYFS_FS is not set +# CONFIG_CONFIGFS_FS is not set # # Miscellaneous filesystems @@ -1351,10 +1315,6 @@ CONFIG_CRC32=y CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=m -CONFIG_TEXTSEARCH=y -CONFIG_TEXTSEARCH_KMP=m -CONFIG_TEXTSEARCH_BM=m -CONFIG_TEXTSEARCH_FSM=m # # Instrumentation Support @@ -1367,18 +1327,20 @@ CONFIG_OPROFILE=y # Kernel hacking # # CONFIG_PRINTK_TIME is not set -CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y +CONFIG_DEBUG_KERNEL=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_DETECT_SOFTLOCKUP=y # CONFIG_SCHEDSTATS is not set # CONFIG_DEBUG_SLAB is not set +CONFIG_DEBUG_MUTEXES=y # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_INFO is not set CONFIG_DEBUG_FS=y # CONFIG_DEBUG_VM is not set +CONFIG_FORCED_INLINING=y # CONFIG_RCU_TORTURE_TEST is not set CONFIG_DEBUG_STACKOVERFLOW=y CONFIG_DEBUG_STACK_USAGE=y @@ -1387,6 +1349,11 @@ CONFIG_XMON=y CONFIG_XMON_DEFAULT=y CONFIG_IRQSTACKS=y # CONFIG_BOOTX_TEXT is not set +# CONFIG_PPC_EARLY_DEBUG_LPAR is not set +# CONFIG_PPC_EARLY_DEBUG_G5 is not set +# CONFIG_PPC_EARLY_DEBUG_RTAS is not set +# CONFIG_PPC_EARLY_DEBUG_MAPLE is not set +# CONFIG_PPC_EARLY_DEBUG_ISERIES is not set # # Security options From anton at samba.org Mon Feb 13 14:48:35 2006 From: anton at samba.org (Anton Blanchard) Date: Mon, 13 Feb 2006 14:48:35 +1100 Subject: [PATCH] powerpc: Fix runlatch performance issues Message-ID: <20060213034835.GB7922@krispykreme> The runlatch SPR can take a lot of time to write. My original runlatch code would set it on every exception entry even though most of the time this was not required. It would also continually set it in the idle loop, which is an issue on an SMT capable processor. Now we cache the runlatch value in a threadinfo bit, and only check for it in decrementer and hardware interrupt exceptions as well as the idle loop. Boot on POWER3, POWER5 and iseries, and compile tested on pmac32. Signed-off-by: Anton Blanchard --- Index: build/arch/powerpc/kernel/head_64.S =================================================================== --- build.orig/arch/powerpc/kernel/head_64.S 2006-02-11 14:50:46.000000000 +1100 +++ build/arch/powerpc/kernel/head_64.S 2006-02-13 13:11:22.000000000 +1100 @@ -321,7 +321,6 @@ exception_marker: label##_pSeries: \ HMT_MEDIUM; \ mtspr SPRN_SPRG1,r13; /* save r13 */ \ - RUNLATCH_ON(r13); \ EXCEPTION_PROLOG_PSERIES(PACA_EXGEN, label##_common) #define STD_EXCEPTION_ISERIES(n, label, area) \ @@ -329,7 +328,6 @@ label##_pSeries: \ label##_iSeries: \ HMT_MEDIUM; \ mtspr SPRN_SPRG1,r13; /* save r13 */ \ - RUNLATCH_ON(r13); \ EXCEPTION_PROLOG_ISERIES_1(area); \ EXCEPTION_PROLOG_ISERIES_2; \ b label##_common @@ -339,7 +337,6 @@ label##_iSeries: \ label##_iSeries: \ HMT_MEDIUM; \ mtspr SPRN_SPRG1,r13; /* save r13 */ \ - RUNLATCH_ON(r13); \ EXCEPTION_PROLOG_ISERIES_1(PACA_EXGEN); \ lbz r10,PACAPROCENABLED(r13); \ cmpwi 0,r10,0; \ @@ -392,6 +389,7 @@ label##_common: \ label##_common: \ EXCEPTION_PROLOG_COMMON(trap, PACA_EXGEN); \ DISABLE_INTS; \ + bl .ppc64_runlatch_on; \ addi r3,r1,STACK_FRAME_OVERHEAD; \ bl hdlr; \ b .ret_from_except_lite @@ -409,7 +407,6 @@ __start_interrupts: _machine_check_pSeries: HMT_MEDIUM mtspr SPRN_SPRG1,r13 /* save r13 */ - RUNLATCH_ON(r13) EXCEPTION_PROLOG_PSERIES(PACA_EXMC, machine_check_common) . = 0x300 @@ -436,7 +433,6 @@ END_FTR_SECTION_IFCLR(CPU_FTR_SLB) data_access_slb_pSeries: HMT_MEDIUM mtspr SPRN_SPRG1,r13 - RUNLATCH_ON(r13) mfspr r13,SPRN_SPRG3 /* get paca address into r13 */ std r3,PACA_EXSLB+EX_R3(r13) mfspr r3,SPRN_DAR @@ -462,7 +458,6 @@ data_access_slb_pSeries: instruction_access_slb_pSeries: HMT_MEDIUM mtspr SPRN_SPRG1,r13 - RUNLATCH_ON(r13) mfspr r13,SPRN_SPRG3 /* get paca address into r13 */ std r3,PACA_EXSLB+EX_R3(r13) mfspr r3,SPRN_SRR0 /* SRR0 is faulting address */ @@ -493,7 +488,6 @@ instruction_access_slb_pSeries: .globl system_call_pSeries system_call_pSeries: HMT_MEDIUM - RUNLATCH_ON(r9) mr r9,r13 mfmsr r10 mfspr r13,SPRN_SPRG3 @@ -577,7 +571,6 @@ slb_miss_user_pseries: system_reset_fwnmi: HMT_MEDIUM mtspr SPRN_SPRG1,r13 /* save r13 */ - RUNLATCH_ON(r13) EXCEPTION_PROLOG_PSERIES(PACA_EXGEN, system_reset_common) .globl machine_check_fwnmi @@ -585,7 +578,6 @@ system_reset_fwnmi: machine_check_fwnmi: HMT_MEDIUM mtspr SPRN_SPRG1,r13 /* save r13 */ - RUNLATCH_ON(r13) EXCEPTION_PROLOG_PSERIES(PACA_EXMC, machine_check_common) #ifdef CONFIG_PPC_ISERIES @@ -896,7 +888,6 @@ unrecov_fer: .align 7 .globl data_access_common data_access_common: - RUNLATCH_ON(r10) /* It wont fit in the 0x300 handler */ mfspr r10,SPRN_DAR std r10,PACA_EXGEN+EX_DAR(r13) mfspr r10,SPRN_DSISR @@ -1044,6 +1035,7 @@ hardware_interrupt_common: EXCEPTION_PROLOG_COMMON(0x500, PACA_EXGEN) hardware_interrupt_entry: DISABLE_INTS + bl .ppc64_runlatch_on addi r3,r1,STACK_FRAME_OVERHEAD bl .do_IRQ b .ret_from_except_lite Index: build/arch/powerpc/kernel/process.c =================================================================== --- build.orig/arch/powerpc/kernel/process.c 2006-02-11 14:50:46.000000000 +1100 +++ build/arch/powerpc/kernel/process.c 2006-02-13 13:12:45.000000000 +1100 @@ -888,3 +888,35 @@ void dump_stack(void) show_stack(current, NULL); } EXPORT_SYMBOL(dump_stack); + +#ifdef CONFIG_PPC64 +void ppc64_runlatch_on(void) +{ + unsigned long ctrl; + + if (cpu_has_feature(CPU_FTR_CTRL) && !test_thread_flag(TIF_RUNLATCH)) { + HMT_medium(); + + ctrl = mfspr(SPRN_CTRLF); + ctrl |= CTRL_RUNLATCH; + mtspr(SPRN_CTRLT, ctrl); + + set_thread_flag(TIF_RUNLATCH); + } +} + +void ppc64_runlatch_off(void) +{ + unsigned long ctrl; + + if (cpu_has_feature(CPU_FTR_CTRL) && test_thread_flag(TIF_RUNLATCH)) { + HMT_medium(); + + clear_thread_flag(TIF_RUNLATCH); + + ctrl = mfspr(SPRN_CTRLF); + ctrl &= ~CTRL_RUNLATCH; + mtspr(SPRN_CTRLT, ctrl); + } +} +#endif Index: build/arch/powerpc/platforms/iseries/setup.c =================================================================== --- build.orig/arch/powerpc/platforms/iseries/setup.c 2006-02-11 14:50:46.000000000 +1100 +++ build/arch/powerpc/platforms/iseries/setup.c 2006-02-11 14:50:55.000000000 +1100 @@ -648,6 +648,7 @@ static void yield_shared_processor(void) * here and let the timer_interrupt code sort out the actual time. */ get_lppaca()->int_dword.fields.decr_int = 1; + ppc64_runlatch_on(); process_iSeries_events(); } Index: build/include/asm-powerpc/reg.h =================================================================== --- build.orig/include/asm-powerpc/reg.h 2006-02-11 14:50:46.000000000 +1100 +++ build/include/asm-powerpc/reg.h 2006-02-11 14:50:55.000000000 +1100 @@ -615,27 +615,9 @@ #define proc_trap() asm volatile("trap") #ifdef CONFIG_PPC64 -static inline void ppc64_runlatch_on(void) -{ - unsigned long ctrl; - - if (cpu_has_feature(CPU_FTR_CTRL)) { - ctrl = mfspr(SPRN_CTRLF); - ctrl |= CTRL_RUNLATCH; - mtspr(SPRN_CTRLT, ctrl); - } -} - -static inline void ppc64_runlatch_off(void) -{ - unsigned long ctrl; - - if (cpu_has_feature(CPU_FTR_CTRL)) { - ctrl = mfspr(SPRN_CTRLF); - ctrl &= ~CTRL_RUNLATCH; - mtspr(SPRN_CTRLT, ctrl); - } -} + +extern void ppc64_runlatch_on(void); +extern void ppc64_runlatch_off(void); extern unsigned long scom970_read(unsigned int address); extern void scom970_write(unsigned int address, unsigned long value); @@ -645,15 +627,6 @@ extern void scom970_write(unsigned int a #define __get_SP() ({unsigned long sp; \ asm volatile("mr %0,1": "=r" (sp)); sp;}) -#else /* __ASSEMBLY__ */ - -#define RUNLATCH_ON(REG) \ -BEGIN_FTR_SECTION \ - mfspr (REG),SPRN_CTRLF; \ - ori (REG),(REG),CTRL_RUNLATCH; \ - mtspr SPRN_CTRLT,(REG); \ -END_FTR_SECTION_IFSET(CPU_FTR_CTRL) - #endif /* __ASSEMBLY__ */ #endif /* __KERNEL__ */ #endif /* _ASM_POWERPC_REG_H */ Index: build/include/asm-powerpc/thread_info.h =================================================================== --- build.orig/include/asm-powerpc/thread_info.h 2006-02-11 14:50:46.000000000 +1100 +++ build/include/asm-powerpc/thread_info.h 2006-02-11 14:50:55.000000000 +1100 @@ -113,7 +113,7 @@ static inline struct thread_info *curren #define TIF_POLLING_NRFLAG 4 /* true if poll_idle() is polling TIF_NEED_RESCHED */ #define TIF_32BIT 5 /* 32 bit binary */ -/* #define SPARE 6 */ +#define TIF_RUNLATCH 6 /* Is the runlatch enabled? */ #define TIF_ABI_PENDING 7 /* 32/64 bit switch needed */ #define TIF_SYSCALL_AUDIT 8 /* syscall auditing active */ #define TIF_SINGLESTEP 9 /* singlestepping active */ @@ -131,7 +131,7 @@ static inline struct thread_info *curren #define _TIF_NEED_RESCHED (1< Hi, HMT support is currently broken and needs to be reworked to play nicely with the SMT scheduler. Remove the bit rotten bits for the time being. I also updated an incorrect comment, we enter __secondary_hold with the physical cpu id in r3. Anton Signed-off-by: Anton Blanchard --- Index: build/arch/powerpc/kernel/head_64.S =================================================================== --- build.orig/arch/powerpc/kernel/head_64.S 2006-02-13 18:08:18.000000000 +1100 +++ build/arch/powerpc/kernel/head_64.S 2006-02-13 18:08:19.000000000 +1100 @@ -139,7 +139,7 @@ _GLOBAL(__secondary_hold) ori r24,r24,MSR_RI mtmsrd r24 /* RI on */ - /* Grab our linux cpu number */ + /* Grab our physical cpu number */ mr r24,r3 /* Tell the master cpu we're here */ @@ -153,11 +153,6 @@ _GLOBAL(__secondary_hold) cmpdi 0,r4,1 bne 100b -#ifdef CONFIG_HMT - SET_REG_IMMEDIATE(r4, .hmt_init) - mtctr r4 - bctr -#else #ifdef CONFIG_SMP LOAD_REG_IMMEDIATE(r4, .pSeries_secondary_smp_init) mtctr r4 @@ -166,7 +161,6 @@ _GLOBAL(__secondary_hold) #else BUG_OPCODE #endif -#endif /* This value is used to mark exception frames on the stack. */ .section ".toc","aw" @@ -1810,22 +1804,6 @@ _STATIC(start_here_multiplatform) ori r6,r6,MSR_RI mtmsrd r6 /* RI on */ -#ifdef CONFIG_HMT - /* Start up the second thread on cpu 0 */ - mfspr r3,SPRN_PVR - srwi r3,r3,16 - cmpwi r3,0x34 /* Pulsar */ - beq 90f - cmpwi r3,0x36 /* Icestar */ - beq 90f - cmpwi r3,0x37 /* SStar */ - beq 90f - b 91f /* HMT not supported */ -90: li r3,0 - bl .hmt_start_secondary -91: -#endif - /* The following gets the stack and TOC set up with the regs */ /* pointing to the real addr of the kernel stack. This is */ /* all done to support the C function call below which sets */ @@ -1939,77 +1917,8 @@ _STATIC(start_here_common) bl .start_kernel -_GLOBAL(hmt_init) -#ifdef CONFIG_HMT - LOAD_REG_IMMEDIATE(r5, hmt_thread_data) - mfspr r7,SPRN_PVR - srwi r7,r7,16 - cmpwi r7,0x34 /* Pulsar */ - beq 90f - cmpwi r7,0x36 /* Icestar */ - beq 91f - cmpwi r7,0x37 /* SStar */ - beq 91f - b 101f -90: mfspr r6,SPRN_PIR - andi. r6,r6,0x1f - b 92f -91: mfspr r6,SPRN_PIR - andi. r6,r6,0x3ff -92: sldi r4,r24,3 - stwx r6,r5,r4 - bl .hmt_start_secondary - b 101f - -__hmt_secondary_hold: - LOAD_REG_IMMEDIATE(r5, hmt_thread_data) - clrldi r5,r5,4 - li r7,0 - mfspr r6,SPRN_PIR - mfspr r8,SPRN_PVR - srwi r8,r8,16 - cmpwi r8,0x34 - bne 93f - andi. r6,r6,0x1f - b 103f -93: andi. r6,r6,0x3f - -103: lwzx r8,r5,r7 - cmpw r8,r6 - beq 104f - addi r7,r7,8 - b 103b - -104: addi r7,r7,4 - lwzx r9,r5,r7 - mr r24,r9 -101: -#endif - mr r3,r24 - b .pSeries_secondary_smp_init - -#ifdef CONFIG_HMT -_GLOBAL(hmt_start_secondary) - LOAD_REG_IMMEDIATE(r4,__hmt_secondary_hold) - clrldi r4,r4,4 - mtspr SPRN_NIADORM, r4 - mfspr r4, SPRN_MSRDORM - li r5, -65 - and r4, r4, r5 - mtspr SPRN_MSRDORM, r4 - lis r4,0xffef - ori r4,r4,0x7403 - mtspr SPRN_TSC, r4 - li r4,0x1f4 - mtspr SPRN_TST, r4 - mfspr r4, SPRN_HID0 - ori r4, r4, 0x1 - mtspr SPRN_HID0, r4 - mfspr r4, SPRN_CTRLF - oris r4, r4, 0x40 - mtspr SPRN_CTRLT, r4 - blr -#endif + /* Not reached */ + BUG_OPCODE /* * We put a few things here that have to be page-aligned. Index: build/arch/powerpc/kernel/prom_init.c =================================================================== --- build.orig/arch/powerpc/kernel/prom_init.c 2006-02-13 15:04:15.000000000 +1100 +++ build/arch/powerpc/kernel/prom_init.c 2006-02-13 18:08:19.000000000 +1100 @@ -205,14 +205,6 @@ static cell_t __initdata regbuf[1024]; #define MAX_CPU_THREADS 2 -/* TO GO */ -#ifdef CONFIG_HMT -struct { - unsigned int pir; - unsigned int threadid; -} hmt_thread_data[NR_CPUS]; -#endif /* CONFIG_HMT */ - /* * Error results ... some OF calls will return "-1" on error, some * will return 0, some will return either. To simplify, here are @@ -1319,10 +1311,6 @@ static void __init prom_hold_cpus(void) */ *spinloop = 0; -#ifdef CONFIG_HMT - for (i = 0; i < NR_CPUS; i++) - RELOC(hmt_thread_data)[i].pir = 0xdeadbeef; -#endif /* look for cpus */ for (node = 0; prom_next_node(&node); ) { type[0] = 0; @@ -1389,32 +1377,6 @@ static void __init prom_hold_cpus(void) /* Reserve cpu #s for secondary threads. They start later. */ cpuid += cpu_threads; } -#ifdef CONFIG_HMT - /* Only enable HMT on processors that provide support. */ - if (__is_processor(PV_PULSAR) || - __is_processor(PV_ICESTAR) || - __is_processor(PV_SSTAR)) { - prom_printf(" starting secondary threads\n"); - - for (i = 0; i < NR_CPUS; i += 2) { - if (!cpu_online(i)) - continue; - - if (i == 0) { - unsigned long pir = mfspr(SPRN_PIR); - if (__is_processor(PV_PULSAR)) { - RELOC(hmt_thread_data)[i].pir = - pir & 0x1f; - } else { - RELOC(hmt_thread_data)[i].pir = - pir & 0x3ff; - } - } - } - } else { - prom_printf("Processor is not HMT capable\n"); - } -#endif if (cpuid > NR_CPUS) prom_printf("WARNING: maximum CPUs (" __stringify(NR_CPUS) Index: build/arch/powerpc/platforms/pseries/Kconfig =================================================================== --- build.orig/arch/powerpc/platforms/pseries/Kconfig 2005-11-05 20:51:08.000000000 +1100 +++ build/arch/powerpc/platforms/pseries/Kconfig 2006-02-13 18:09:21.000000000 +1100 @@ -9,13 +9,6 @@ config PPC_SPLPAR processors, that is, which share physical processors between two or more partitions. -config HMT - bool "Hardware multithreading" - depends on SMP && PPC_PSERIES && BROKEN - help - This option enables hardware multithreading on RS64 cpus. - pSeries systems p620 and p660 have such a cpu type. - config EEH bool "PCI Extended Error Handling (EEH)" if EMBEDDED depends on PPC_PSERIES From utz.bacher at de.ibm.com Tue Feb 14 07:36:25 2006 From: utz.bacher at de.ibm.com (Utz Bacher) Date: Mon, 13 Feb 2006 21:36:25 +0100 (CET) Subject: [FYI/PATCH 2/3] fix IIC device tree interpretation for Cell Message-ID: This patch applies on top of Arnd's posting (patch id 4188) from 1/18 (on top of 2.6.15.4). It fixes the Linux interpretation of the Cell SLOF deivce tree IIC target IDs and is recommended for running on a Cell blade today. Cc: Jens Osterkamp Cc: Arnd Bergmann From: Gerhard Stenzel Signed-off-by: Utz Bacher Index: linux-2.6.15.4/arch/powerpc/platforms/cell/interrupt.c =================================================================== --- linux-2.6.15.4.orig/arch/powerpc/platforms/cell/interrupt.c +++ linux-2.6.15.4/arch/powerpc/platforms/cell/interrupt.c @@ -254,13 +254,13 @@ iic = &per_cpu(iic, np[0]); iic->regs = __ioremap(regs[0], sizeof(struct iic_regs), _PAGE_NO_CACHE); - iic->target_id = (np[0] << 4) + 0xe; + iic->target_id = ((np[0] & 2) << 3) + ((np[0] & 1) ? 0xf : 0xe); printk("IIC for CPU %d at %lx mapped to %p\n", np[0], regs[0], iic->regs); iic = &per_cpu(iic, np[1]); iic->regs = __ioremap(regs[2], sizeof(struct iic_regs), _PAGE_NO_CACHE); - iic->target_id = (np[1] << 3) + 0xe; + iic->target_id = ((np[1] & 2) << 3) + ((np[1] & 1) ? 0xf : 0xe); printk("IIC for CPU %d at %lx mapped to %p\n", np[1], regs[2], iic->regs); found++; From utz.bacher at de.ibm.com Tue Feb 14 07:33:42 2006 From: utz.bacher at de.ibm.com (Utz Bacher) Date: Mon, 13 Feb 2006 21:33:42 +0100 (CET) Subject: [FYI/PATCH 1/3] reenable CONFIG_GEN_RTC for Cell Message-ID: This patch applies on top of Arnd's posting (patch id 4182) from 1/18 (on top of 2.6.15.4). It reenables CONFIG_GEN_RTC which allows the clock to be set on Cell blades and is recommended for running on a such a system today. Cc: Arnd Bergmann From: Gerhard Stenzel Signed-off-by: Utz Bacher Index: linux-2.6.15.4/arch/powerpc/configs/cell_defconfig =================================================================== --- linux-2.6.15.4.orig/arch/powerpc/configs/cell_defconfig +++ linux-2.6.15.4/arch/powerpc/configs/cell_defconfig @@ -654,7 +654,7 @@ # CONFIG_PCIPCWATCHDOG is not set # CONFIG_WDTPCI is not set # CONFIG_RTC is not set -# CONFIG_GEN_RTC is not set +CONFIG_GEN_RTC=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set From HPENNER at de.ibm.com Tue Feb 14 05:19:10 2006 From: HPENNER at de.ibm.com (Hartmut Penner) Date: Mon, 13 Feb 2006 19:19:10 +0100 Subject: AW: Re: __setup_cpu_be problem In-Reply-To: <1139779462.5247.30.camel@localhost.localdomain> Message-ID: Hello the initial value set by FW of the HID6 is 0x00010034_00000000. I would like to support the large pages in the Firmware, but need to know excactly what properties I have to set. Looked at the linux code, but still are not quiet sure what values to put into ibm,segment-page-sizes. Could somebody enlighten me, how to find out ? I am right now in Rochester, would there be somebody here to talk about ? regards, Hartmut |---------+----------------------------> | | Benjamin | | | Herrenschmidt | | | | | | | | | 02/12/06 10:24 PM| |---------+----------------------------> >-------------------------------------------------------------------------------------------------------------------------------------| | | | To: Arnd Bergmann | | cc: Masato.Noguchi at jp.sony.com, linuxppc64-dev at ozlabs.org, geoffrey.levand at am.sony.com, Hartmut Penner/Germany/IBM at IBMDE| | Subject: Re: AW: Re: __setup_cpu_be problem | | | | | >-------------------------------------------------------------------------------------------------------------------------------------| > The current firmware on the Cell blades does neither the setup of > the HID6 register nor have the correct tables in the device tree. > > Since I'm still currently sitting in a garden in NZ instead of the > B?blingen lab, I can't find out what the HID6 power-on defaults > are. We might get away with just leaving the default there, but that > might prevent us from using 16M and/or 64k pages and there are > definitely some application which depend on 16M hugetlb mappings > on Cell. Yes, however, how much widely distributed and "frozen" is this current Cell firmware ? I mean, do we really need to add a workaround to the kenrel instead of just fixing the firmware here ? > The two problems we are facing currently are: > - If HID6 defaults to disabling 16M large pages, the kernel will > get the wrong information from the CPU features and applications > that use it break. The firmware should add the setup if HID6 > _now_, but we also should be prepared for users of old firmware > that want to upgrade their kernel without upgrading the firmware > at the same time. Do we really need to support old/broken firmware ? It's not like we had a released product all over the field... > - We want to use 64k pages in the future, so the firmware needs to > add the 'ibm,segment-page-sizes' property ASAP, preferrably at > the same time they start setting up HID6. I currently have a > hack for the kernel to override that, but we're in the process > of eliminating all the special hacks that won't make in into > the mainline kernel. The only things you need is to have this property set and the new ibm,pa-feature for which I need to dig out the latest spec.... The problem is that the kernel will currentl not enable 64k pages on any processor due to the lack of a feature bit (intentionally) from the cputable. That bit will be extracted from ibm,pa-features at least on pSeries. It's the bit indicating that L=1 works for cache inhibited mappings. > Yes, 1M mappings are probably not of much use to us, and other OSs > already do whatever they like ;-). Sure. Note that the firmware can still set HID6 to 1M pages and put the appropriate entries in the device-tree for 1M large pages. Linux won't be able to use them as-is though but at least the device-tree infos will be sane. I don't want to enter a debate wether we should be able to change HID6 etc... right now. It's more a firmware configuration issue as far as I'm concerned. > Then please try to at least send the spec or a link to Hartmut's IBM > internal address (hpenner at de.ibm.com). I already pointed him to the > linux code when it was initially merged, but he argued that reverse > engineering that code is not good enough to be sure to get the > property right and not having it in there is better than having incorrect > properties. Will do Ben. From arnd at arndb.de Tue Feb 14 09:17:31 2006 From: arnd at arndb.de (Arnd Bergmann) Date: Mon, 13 Feb 2006 23:17:31 +0100 Subject: AW: Re: __setup_cpu_be problem In-Reply-To: References: Message-ID: <200602132317.32034.arnd@arndb.de> On Monday 13 February 2006 19:19, Hartmut Penner wrote: > ? ? ? the initial value set by FW of the HID6 is 0x00010034_00000000. Ok, good: Both large page sizes are set to 16M, neither is 1M or 64k. That means that we can just rip out the HID6 setup from the kernel without losing the ability for 16M pages. Geoff, please submit a patch to replace __setup_cpu_be with __setup_cpu_power4 if that solves your problem. The new 64k page support has never worked so far on Cell because of missing spufs code for this, so we don't get a regression either way. We still need the firmware changes (HID6 setup and the device tree properties) in order to support 64k pages, but we don't need to worry about breaking stuff in the process. Arnd <>< From arnd at arndb.de Tue Feb 14 09:24:44 2006 From: arnd at arndb.de (Arnd Bergmann) Date: Mon, 13 Feb 2006 23:24:44 +0100 Subject: AW: Re: __setup_cpu_be problem In-Reply-To: <1139779462.5247.30.camel@localhost.localdomain> References: <2812322.110611139545275893.JavaMail.servlet@kundenserver> <200602120552.26164.arnd@arndb.de> <1139779462.5247.30.camel@localhost.localdomain> Message-ID: <200602132324.45433.arnd@arndb.de> On Sunday 12 February 2006 22:24, Benjamin Herrenschmidt wrote: > > The current firmware on the Cell blades does neither the setup of > > the HID6 register nor have the correct tables in the device tree. > > > > Since I'm still currently sitting in a garden in NZ instead of the > > B?blingen lab, I can't find out what the HID6 power-on defaults > > are. We might get away with just leaving the default there, but that > > might prevent us from using 16M and/or 64k pages and there are > > definitely some application which depend on 16M hugetlb mappings > > on Cell. > > Yes, however, how much widely distributed