* Re: [BUG/RFC/PATCH] drm: Fix for non-coherent DMA PowerPC
From: Gerhard Pircher @ 2008-03-03 19:51 UTC (permalink / raw)
To: benh; +Cc: airlied, linuxppc-dev, dri-devel, linux-kernel
In-Reply-To: <1204498569.15052.488.camel@pasglop>
-------- Original-Nachricht --------
> Datum: Mon, 03 Mar 2008 09:56:09 +1100
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org, dri-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, airlied@linux.ie
> Betreff: Re: [BUG/RFC/PATCH] drm: Fix for non-coherent DMA PowerPC
> Bah, I think I found the problem:
>
> +static inline void *drm_vmalloc_dma(unsigned long size)
> +{
> +#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE)
> + return __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM,
> + PAGE_KERNEL | _PAGE_NO_CACHE);
> +#else
> + return vmalloc_32(size);
> +#endif
> +}
> +
>
> Remove the GFP_HIGHMEM from the above. It looks like our cache
> flushing isn't going to work for highmem, it would need some
> kmap's for that.
Yes, it looks like this was the problem. No kernel oops anymore.
The machine locks up anyway (which is a well known hardware problem).
It doesn't lock up with CPPIOMode=true, but probably only because the
initialization of DRI fails with "BAD cp_mode (f0000000)!".
Gerhard
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
^ permalink raw reply
* RE: Xilinx PowerPC
From: Stephen Neuendorffer @ 2008-03-03 19:53 UTC (permalink / raw)
To: monstr; +Cc: linuxppc-embedded
In-Reply-To: <47CAF0FC.70706@seznam.cz>
Michel,
I've had it on my todo list to get the u-boot stuff working for powerpc
too... However, I remember a brief comment from John Williams that
you'd separated the BSP generation process more. Details (or better
yet, code and patches) would be appreciated, here, since I'm a bit
swamped at the moment.
Steve
> -----Original Message-----
> From: Michal Simek [mailto:monstr@seznam.cz]
> Sent: Sunday, March 02, 2008 10:25 AM
> To: Stephen Neuendorffer
> Cc: David H. Lynch Jr.; Grant Likely; linuxppc-embedded
> Subject: Re: Xilinx PowerPC
>=20
> Hi All,
>=20
> > http://git.xilinx.com/gen-mhs-devtree.git contains two utilities for
> > generating device trees from EDK projects. The older option is a
python
> > script, originally written by Grant. The newer (and probably more
> > mature at this point) option is an EDK BSP generator for u-boot,
> > originally written by Michal Simek. Preferably this gets passed
from a
> > uboot, although it's also possible to compile it into the kernel.
> > Currently, the uboot option is somewhat annoying because there's not
a
> > good surefire way for getting uboot up and running on an EDK design.
> > (Unfortunately, the EDK BSP generator is incomplete, and the uboot
> > support for virtex needs some work to get it integrated as well).
>=20
> U-BOOT part will be removed from EDK generator. The new name will be
only
> fdt_v1.00.a. I have prepared separated version for FDT generation and
for U-BOOT
> generation.
>=20
> Steve: You can remove U-BOOT part from generator. This part is useful
only for
> Microblaze cpu.
>=20
> Regards,
> Michal Simek
^ permalink raw reply
* Re: [patch 0/6] RFC: PCI: consolidate pcibios_enable_resources() implementations, v2
From: Russell King @ 2008-03-03 19:44 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-arch, Chris Zankel, Grant Grundler, linux-parisc,
Matthew Wilcox, Kyle McMartin, linuxppc-dev, Paul Mackerras,
linux-pci, linux-arm-kernel
In-Reply-To: <20080228000437.880811124@ldl.fc.hp.com>
On Wed, Feb 27, 2008 at 05:04:37PM -0700, Bjorn Helgaas wrote:
> There are many implementations of pcibios_enable_resources() that differ
> in minor ways that look more like bugs than architectural differences.
> This patch series consolidates most of them to use the x86 version.
>
> Changes between v1 and v2:
>
> - Moved ARM bridge enable to new platform_pci_enable_device(),
> called by pcibios_enable_device()
Looks fine. However, long term I've no idea what to do about this because
I don't remember the reasoning behind it. So to change it risks breakage
of one sort or another.
It might have been something to do with the Mobility Cardbus docking
station, which adds a pair of P2P bridges onto the PCI chain downstream
of the Cardbus controller, and then a full PCI bus containing USB, VGA,
and other peripherals.
This _once_ used to work with Linux but I suspect as a result of "fixing"
other issues its now utterly broken.
In any case, that docking station isn't ARM specific in any way; merely
a toy Alan Cox sent me. When I gave up my PCMCIA maintainership, I gave
up trying to keep it supported by Linux.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: [patch 4/6] ARM: move bridge enable out of pcibios_enable_resources()
From: Benjamin Herrenschmidt @ 2008-03-03 20:35 UTC (permalink / raw)
To: Jesse Barnes
Cc: linux-arch, Chris Zankel, Grant Grundler, linux-parisc,
Matthew Wilcox, Kyle McMartin, linuxppc-dev, Paul Mackerras,
linux-pci, linux-arm-kernel, Russell King, Bjorn Helgaas
In-Reply-To: <200803030959.35625.jbarnes@virtuousgeek.org>
On Mon, 2008-03-03 at 09:59 -0800, Jesse Barnes wrote:
> On Wednesday, February 27, 2008 4:04 pm Bjorn Helgaas wrote:
> > Move bridge enable from pcibios_enable_resources() to
> > platform_pci_enable_device() so the former matches other
> > architectures and can be shared.
>
> I really like the direction of these patches. Getting PCI resources assigned
> & devices setup correctly for new arches has always been a bit more trouble
> than it should be...
You'll noticed that I recently moved powerpc to something more common to
x86 in the are of resource allocation. Still -slightly- different but I
do believe there is room for somebody with some skills to try to turn
some of that into generic code.
Ben.
^ permalink raw reply
* Re: [patch 4/6] ARM: move bridge enable out of pcibios_enable_resources()
From: Jesse Barnes @ 2008-03-03 20:43 UTC (permalink / raw)
To: benh
Cc: linux-arch, Chris Zankel, Grant Grundler, linux-parisc,
Matthew Wilcox, Kyle McMartin, linuxppc-dev, Paul Mackerras,
linux-pci, linux-arm-kernel, Russell King, Bjorn Helgaas
In-Reply-To: <1204576557.21545.4.camel@pasglop>
On Monday, March 03, 2008 12:35 pm Benjamin Herrenschmidt wrote:
> On Mon, 2008-03-03 at 09:59 -0800, Jesse Barnes wrote:
> > On Wednesday, February 27, 2008 4:04 pm Bjorn Helgaas wrote:
> > > Move bridge enable from pcibios_enable_resources() to
> > > platform_pci_enable_device() so the former matches other
> > > architectures and can be shared.
> >
> > I really like the direction of these patches. Getting PCI resources
> > assigned & devices setup correctly for new arches has always been a bit
> > more trouble than it should be...
>
> You'll noticed that I recently moved powerpc to something more common to
> x86 in the are of resource allocation. Still -slightly- different but I
> do believe there is room for somebody with some skills to try to turn
> some of that into generic code.
Yeah, I think that would be a good thing to shoot for. Even on PCs there are
times when we need resource allocation to be done (or re-done) by the kernel
for hotplug or just because the platform is pared down enough that it doesn't
to it all by itself.
I might be able to find time to look into that myself in the next few weeks; I
think we even have some open PCI bugs that could be solved by better resource
allocation.
Jesse
^ permalink raw reply
* Re: [BUG/RFC/PATCH] drm: Fix for non-coherent DMA PowerPC
From: Benjamin Herrenschmidt @ 2008-03-03 20:44 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: airlied, linuxppc-dev, dri-devel, linux-kernel
In-Reply-To: <20080303195117.7040@gmx.net>
On Mon, 2008-03-03 at 20:51 +0100, Gerhard Pircher wrote:
> > Remove the GFP_HIGHMEM from the above. It looks like our cache
> > flushing isn't going to work for highmem, it would need some
> > kmap's for that.
> Yes, it looks like this was the problem. No kernel oops anymore.
> The machine locks up anyway (which is a well known hardware problem).
> It doesn't lock up with CPPIOMode=true, but probably only because the
> initialization of DRI fails with "BAD cp_mode (f0000000)!".
Damn, I wonder why you insist trying to make that machine work :-) The
hardware is just totally busted.
Ben.
^ permalink raw reply
* Re: I2S driver
From: Timur Tabi @ 2008-03-03 20:50 UTC (permalink / raw)
To: Angelo; +Cc: Linuxppc-embedded
In-Reply-To: <157246.48338.qm@web23111.mail.ird.yahoo.com>
Angelo wrote:
> Timur wrote:
>>I wrote an ASoC driver for the MPC8610, which also has
>>an I2S interface. You can find it in sound/soc/fsl.
>
> in my kernel version (2.6.22) there isn't any folder named
> fsl in sound/soc/
It's in 2.6.25.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Philippe De Muyter @ 2008-03-03 21:05 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080303170719.GC28951@ld0162-tx32.am.freescale.net>
Hi Scott,
On Mon, Mar 03, 2008 at 11:07:20AM -0600, Scott Wood wrote:
> On Mon, Mar 03, 2008 at 03:47:27PM +0100, Philippe De Muyter wrote:
> > My root device is on a compact-flash connected to a PCI yenta chip from TI,
> > and this one is not working, altough it seems to be discovered :
> >
> > Yenta: CardBus bridge found at 0000:00:12.0 [0000:0000]
> > Yenta: Using CSCINT to route CSC interrupts to PCI
> > Yenta: Routing CardBus interrupts to PCI
> > Yenta TI: socket 0000:00:12.0, mfunc 0x00001b22, devctl 0x64
> > irq 18: nobody cared (try booting with the "irqpoll" option)
> > Call Trace:
> > [cf813af0] [c00066c8] show_stack+0x3c/0x1bc (unreliable)
> > [cf813b30] [c003c1ac] __report_bad_irq+0x38/0xcc
> > [cf813b50] [c003c4c8] note_interrupt+0x288/0x2cc
> > [cf813b80] [c003cc34] handle_fasteoi_irq+0x94/0xf8
>
> Maybe your PCI interrupt-map is wrong...
Is the PCI-interrupt map that part of the dts file :
interrupt-map = <
/* IDSEL 0x02 */
1000 0 0 1 &mpic 1 1
1000 0 0 2 &mpic 2 1
1000 0 0 3 &mpic 3 1
1000 0 0 4 &mpic 4 1
/* IDSEL 0x03 */
1800 0 0 1 &mpic 4 1
1800 0 0 2 &mpic 1 1
1800 0 0 3 &mpic 2 1
1800 0 0 4 &mpic 3 1
...
I do not understand anything there :(
Philippe
^ permalink raw reply
* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Scott Wood @ 2008-03-03 21:11 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: linuxppc-dev
In-Reply-To: <20080303210532.GA20382@netgate.macqel>
Philippe De Muyter wrote:
> Is the PCI-interrupt map that part of the dts file :
>
> interrupt-map = <
>
> /* IDSEL 0x02 */
> 1000 0 0 1 &mpic 1 1
> 1000 0 0 2 &mpic 2 1
> 1000 0 0 3 &mpic 3 1
> 1000 0 0 4 &mpic 4 1
>
> /* IDSEL 0x03 */
> 1800 0 0 1 &mpic 4 1
> 1800 0 0 2 &mpic 1 1
> 1800 0 0 3 &mpic 2 1
> 1800 0 0 4 &mpic 3 1
>
> ...
Yes.
> I do not understand anything there :(
It maps PCI interrupts to mpic interrupts. The first three cells are
the PCI address (only the device number is unmasked), then the PCI
interrupt (INTA=1, INTB=2, etc.), then a phandle to the parent interrupt
controller, then the interrupt specifier for the parent controller.
-Scott
^ permalink raw reply
* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Philippe De Muyter @ 2008-03-03 21:26 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <47CC696C.4090103@freescale.com>
Hi Scott,
On Mon, Mar 03, 2008 at 03:11:08PM -0600, Scott Wood wrote:
> Philippe De Muyter wrote:
>> Is the PCI-interrupt map that part of the dts file :
>> interrupt-map = <
>> /* IDSEL 0x02 */
>> 1000 0 0 1 &mpic 1 1
>> 1000 0 0 2 &mpic 2 1
>> 1000 0 0 3 &mpic 3 1
>> 1000 0 0 4 &mpic 4 1
>> /* IDSEL 0x03 */
>> 1800 0 0 1 &mpic 4 1
>> 1800 0 0 2 &mpic 1 1
>> 1800 0 0 3 &mpic 2 1
>> 1800 0 0 4 &mpic 3 1
>> ...
>
> Yes.
>
>> I do not understand anything there :(
>
> It maps PCI interrupts to mpic interrupts. The first three cells are the
> PCI address (only the device number is unmasked), then the PCI interrupt
> (INTA=1, INTB=2, etc.), then a phandle to the parent interrupt controller,
> then the interrupt specifier for the parent controller.
Thanks
The following seems important also :
/*
interrupts = <18 2>;
*/
/* interrupts number are coded in hexa ! */
interrupts = <12 2 19 2 1a 2 1b 2 35 2 36 2 37 2>;
I have replaced the interrupts spec in comments by the longer interrupts spec
below, and it seems to have some positive effect, but I do not know
precisely what I have described there.
I know that 25, 26, 27, 53, 54 and 55 decimal i(hence 19, 1a etc...) are the
interrupts numbers that I had in the ARCH=ppc version. I added 18 because
of the error message, but it did not help.
What should be described here and how ?
Philippe
^ permalink raw reply
* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Benjamin Herrenschmidt @ 2008-03-03 21:26 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20080303210532.GA20382@netgate.macqel>
> > Maybe your PCI interrupt-map is wrong...
>
> Is the PCI-interrupt map that part of the dts file :
>
> interrupt-map = <
>
> /* IDSEL 0x02 */
> 1000 0 0 1 &mpic 1 1
> 1000 0 0 2 &mpic 2 1
> 1000 0 0 3 &mpic 3 1
> 1000 0 0 4 &mpic 4 1
>
> /* IDSEL 0x03 */
> 1800 0 0 1 &mpic 4 1
> 1800 0 0 2 &mpic 1 1
> 1800 0 0 3 &mpic 2 1
> 1800 0 0 4 &mpic 3 1
>
> ...
>
> I do not understand anything there :(
It's documented in booting-without-of.txt afaik... The interrupt-map
goes along with the interrupt-map-mask. The later defines which bits of
the map are relevant.
The first part of the map is 3 cells containing a PCI address, followed
by a cell containing a PCI IRQ line (1=A....4=D). The next is the parent
interrupt controller, followed by the IRQ specification, which for MPIC
is the interrupt number on that controller, followed by an encoding of
the interrupt polarity & trigger type (1 for level-low).
The first part, the PCI address, has a special format, which should be
documented as well in the document I pointed out. For readability, we
ommited the top 16 bits of the first cell, which are the address type
and bus number, mostly irrelevant for interrupt mapping. The next bits
are the device/function. Usually only the device part is unmasked.
Ben.
^ permalink raw reply
* Re: [BUG/RFC/PATCH] drm: Fix for non-coherent DMA PowerPC
From: Gerhard Pircher @ 2008-03-03 21:37 UTC (permalink / raw)
To: benh; +Cc: airlied, linuxppc-dev, dri-devel, linux-kernel
In-Reply-To: <1204577051.21545.12.camel@pasglop>
-------- Original-Nachricht --------
> Datum: Tue, 04 Mar 2008 07:44:11 +1100
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: airlied@linux.ie, linux-kernel@vger.kernel.org, dri-devel@lists.sourceforge.net, linuxppc-dev@ozlabs.org
> Betreff: Re: [BUG/RFC/PATCH] drm: Fix for non-coherent DMA PowerPC
> On Mon, 2008-03-03 at 20:51 +0100, Gerhard Pircher wrote:
> > > Remove the GFP_HIGHMEM from the above. It looks like our cache
> > > flushing isn't going to work for highmem, it would need some
> > > kmap's for that.
>
> > Yes, it looks like this was the problem. No kernel oops anymore.
> > The machine locks up anyway (which is a well known hardware problem).
> > It doesn't lock up with CPPIOMode=true, but probably only because the
> > initialization of DRI fails with "BAD cp_mode (f0000000)!".
>
> Damn, I wonder why you insist trying to make that machine work :-) The
> hardware is just totally busted.
Because it's a challenge! :) Or because the OS4 developers say that
PCIGART works.
Gerhard
--
Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games!
http://games.entertainment.web.de/de/entertainment/games/free
^ permalink raw reply
* Re: [PATCH 2/2 v2] [POWERPC] Ignore disabled serial ports
From: Nathan Lynch @ 2008-03-03 21:40 UTC (permalink / raw)
To: Josh Boyer; +Cc: Scott Wood, linuxppc-dev, paulus, Arnd Bergmann
In-Reply-To: <20080303132107.67200634@weaponx>
Josh Boyer wrote:
> On Mon, 3 Mar 2008 13:09:25 -0600
> Scott Wood <scottwood@freescale.com> wrote:
>
> > On Sun, Mar 02, 2008 at 10:43:17PM -0600, Josh Boyer wrote:
> > > On Mon, 3 Mar 2008 04:43:42 +0100
> > > Arnd Bergmann <arnd@arndb.de> wrote:
> > > > I wonder whether we should move the check for "used-by-rtas" into the
> > > > of_device_is_available function. I understand that used-by-rtas is
> > > > another way of expressing the idea that the kernel is not supposed to
> > > > access the specific device. In this case, the device is physically
> > > > present, but is not available to the OS.
> > >
> > > I'd rather not at the moment. My intention was to only look at the
> > > status property for now. I'd like to avoid this function growing into
> > > a huge switch statement for $random_firmware's way of flagging
> > > something as "don't touch".
> >
> > Better that than having the "huge" list of tests in every driver...
>
> Perhaps.
>
> This isn't set in stone. I'd rather get what's in the patch in-tree
> now and massage it as we go. Otherwise this bike shed will wind up
> being rainbow colored yet totally useless because it's a never-ending
> patch rework.
I agree. Josh's patch is immediately useful to other code as-is.
used-by-rtas is powerpc-specific and doesn't belong in drivers/of IMO.
^ permalink raw reply
* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Benjamin Herrenschmidt @ 2008-03-03 21:41 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20080303212622.GB20382@netgate.macqel>
> Thanks
>
> The following seems important also :
>
> /*
> interrupts = <18 2>;
> */
> /* interrupts number are coded in hexa ! */
> interrupts = <12 2 19 2 1a 2 1b 2 35 2 36 2 37 2>;
>
> I have replaced the interrupts spec in comments by the longer interrupts spec
> below, and it seems to have some positive effect, but I do not know
> precisely what I have described there.
>
> I know that 25, 26, 27, 53, 54 and 55 decimal i(hence 19, 1a etc...) are the
> interrupts numbers that I had in the ARCH=ppc version. I added 18 because
> of the error message, but it did not help.
Where is this ? (What node ?) The above looks like the interrupt spec
for a single device with 7 interrupts, is that what you are trying to
do ?
If not, then it's incorrect, you have to figure the interrupt-map out
(it's really not -that- hard).
Ben.
^ permalink raw reply
* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Scott Wood @ 2008-03-03 21:55 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: linuxppc-dev
In-Reply-To: <20080303212622.GB20382@netgate.macqel>
Philippe De Muyter wrote:
> The following seems important also :
>
> /*
> interrupts = <18 2>;
> */
> /* interrupts number are coded in hexa ! */
> interrupts = <12 2 19 2 1a 2 1b 2 35 2 36 2 37 2>;
>
> I have replaced the interrupts spec in comments by the longer interrupts spec
> below,
Why?
> and it seems to have some positive effect,
What kind of positive effect? I'd think the extra interrupts would just
be ignored. The interrupts property for the PCI node itself is
generally for error reporting.
> I know that 25, 26, 27, 53, 54 and 55 decimal i(hence 19, 1a etc...) are the
> interrupts numbers that I had in the ARCH=ppc version. I added 18 because
> of the error message, but it did not help.
What ARCH=ppc version? There are no device trees for non-OF boards in
arch/ppc.
-Scott
^ permalink raw reply
* Re: I2S driver
From: Wolfgang Denk @ 2008-03-03 22:06 UTC (permalink / raw)
To: Pedro Luis D. L.; +Cc: linuxppc-embedded
In-Reply-To: <BLU106-W22AC7D9FCF4035AF6AB5E6CA170@phx.gbl>
In message <BLU106-W22AC7D9FCF4035AF6AB5E6CA170@phx.gbl> you wrote:
>
> depends on which kernel version are you using. You can find some working code in DENX repository:
> http://source.denx.net/cgi-bin/gitweb.cgi
Ah, you should use the official server instead:
http://www.denx.de/cgi-bin/gitweb.cgi
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
\|/ ____ \|/ \|/ ____ \|/
@~/ ,. \~@ @~/ ,. \~@
/_( \__/ )_\ /_( \__/ )_\
\__U_/ \__U_/
^ permalink raw reply
* locking problem in sata_sil24?
From: Rune Torgersen @ 2008-03-03 22:10 UTC (permalink / raw)
To: linuxppc-dev, linux-ide
Hi I am trying to get PREEMPT_RT pach to wokr on my 2.6.24 kernel, but
kept gettign a BUG() (kernel BUG at kernel/rtmutex.c:692).
While tryiong to figure out what it was, I saw some mention of trying
LOCKDEP to see what is going on, so I patched my -rt1 kernel with some
lockdep patches from BenH.
Now I get an "inconsistent locking state", but I need help in trying to
fiure out what I should look for.
kernel is fo an Freescale 8280 and the locking seems to occur in the
driver for a Silicon Image SII3124 SATA disk driver
Linux version 2.6.24-rt1 (runet@runet) (gcc version 4.1.2) #12 PREEMPT
RT Mon Mar 3 15:47:03 CST 2008
Trying to allocate DevcomPtr
DevcomHugeMemPtr =3D c1800000
Zone PFN ranges:
DMA 0 -> 196608
Normal 196608 -> 196608
HighMem 196608 -> 262144
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 262144
Real-Time Preemption Support (C) 2004-2007 Ingo Molnar
Built 1 zonelists in Zone order, mobility grouping on. Total pages:
260096
Kernel command line: root=3D/dev/sda3 rw console=3DttyCPM0,115200
WARNING: experimental RCU implementation.
PID hash table entries: 4096 (order: 12, 16384 bytes)
clocksource: timebase mult[a0c0437] shift[22] registered
console [ttyCPM0] enabled
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES: 8
... MAX_LOCK_DEPTH: 30
... MAX_LOCKDEP_KEYS: 2048
... CLASSHASH_SIZE: 1024
... MAX_LOCKDEP_ENTRIES: 16384
... MAX_LOCKDEP_CHAINS: 32768
... CHAINHASH_SIZE: 16384
memory used by lock dependency info: 1568 kB
per task-struct memory footprint: 1200 bytes
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1007824k/1048576k available (3240k kernel code, 302324k
reserved, 176k data, 2803k bss, 128k init)
Mount-cache hash table entries: 512
net_namespace: 88 bytes
NET: Registered protocol family 16
PCI: Probing PCI hardware
SCSI subsystem initialized
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 32768 (order: 9, 2228224 bytes)
TCP: Hash tables configured (established 131072 bind 32768)
TCP reno registered
krcupreemptd setsched 0
prio =3D 98
highmem bounce pool size: 64 pages
JFFS2 version 2.2. (NAND) .. 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
ttyCPM0 at MMIO 0xf1050a80 (irq =3D 16) is a CPM UART
Fixed MDIO Bus: probed
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
eth0: fs_enet: 00:30:d7:00:14:52
eth1: fs_enet: 00:30:d7:00:14:53
eth2: fs_enet: 00:30:d7:00:00:01
Driver 'sd' needs updating - please use bus_type methods
scsi0 : sata_sil24
scsi1 : sata_sil24
scsi2 : sata_sil24
scsi3 : sata_sil24
ata1: SATA max UDMA/100 host m128@0x90000000 port 0x90008000 irq 17
ata2: SATA max UDMA/100 host m128@0x90000000 port 0x9000a000 irq 17
ata3: SATA max UDMA/100 host m128@0x90000000 port 0x9000c000 irq 17
ata4: SATA max UDMA/100 host m128@0x90000000 port 0x9000e000 irq 17
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
stopped custom tracer.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
[ INFO: inconsistent lock state ]
[ 2.6.24-rt1 #12
---------------------------------
inconsistent {hardirq-on-W} -> {in-hardirq-W} usage.
swapper/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
(&host->lock){+-..}, at: [<c01c8e14>] sil24_interrupt+0x68/0x53c
{hardirq-on-W} state was registered at:
[<c0047724>] __lock_acquire+0x494/0xc04
[<c0047ee8>] lock_acquire+0x54/0x78
[<c025c8f0>] rt_spin_lock+0x34/0x54
[<c01b45ac>] ata_dev_init+0x38/0x88
[<c01b467c>] ata_link_init+0x80/0xa4
[<c01b4840>] ata_port_alloc+0x1a0/0x1bc
[<c01b48f4>] ata_host_alloc+0x98/0xf8
[<c01b4974>] ata_host_alloc_pinfo+0x20/0x104
[<c01c83b4>] sil24_init_one+0x128/0x390
[<c01802f0>] pci_device_probe+0x70/0xa8
[<c0197d10>] driver_probe_device+0x104/0x1ac
[<c0197e0c>] __driver_attach+0x54/0x8c
[<c0197030>] bus_for_each_dev+0x58/0xa0
[<c0197adc>] driver_attach+0x2c/0x44
[<c0197778>] bus_add_driver+0xb4/0x1b8
[<c01980b8>] driver_register+0x7c/0x114
[<c01803bc>] __pci_register_driver+0x60/0x78
[<c031e620>] sil24_init+0x2c/0x44
[<c030a2c8>] kernel_init+0xdc/0x334
[<c0010408>] kernel_thread+0x44/0x60
irq event stamp: 16174
hardirqs last enabled at (16173): [<c0046d18>]
trace_hardirqs_on+0x1c/0x34
hardirqs last disabled at (16174): [<c0045554>]
trace_hardirqs_off+0x1c/0x34
softirqs last enabled at (0): [<00000000>] 0x0
softirqs last disabled at (0): [<00000000>] 0x0
other info that might help us debug this:
no locks held by swapper/0.
stack backtrace:
Call Trace:
[c0357ca0] [c0008474] show_stack+0x54/0x18c (unreliable)
[c0357cd0] [c00085cc] dump_stack+0x20/0x38
[c0357ce0] [c00460a0] print_usage_bug+0x130/0x14c
[c0357d10] [c0046674] mark_lock+0xf0/0x4ec
[c0357d30] [c004769c] __lock_acquire+0x40c/0xc04
[c0357d80] [c0047ee8] lock_acquire+0x54/0x78
[c0357da0] [c025c8f0] rt_spin_lock+0x34/0x54
[c0357dc0] [c01c8e14] sil24_interrupt+0x68/0x53c
[c0357e00] [c00529e0] handle_IRQ_event+0x6c/0x114
[c0357e30] [c0052bcc] __do_IRQ+0x144/0x1c4
[c0357e50] [c0017d88] apmax_int_irq_demux+0x90/0xb8
[c0357e70] [c00063f0] do_IRQ+0x6c/0xb0
[c0357e80] [c0010cfc] ret_from_except+0x0/0x28
--- Exception: 501 at check_critical_timing+0x184/0x190
LR =3D check_critical_timing+0x15c/0x190
[c0357f80] [c00519a4] touch_critical_timing+0x5c/0xb0
[c0357fa0] [c00096c4] cpu_idle+0xe4/0x124
[c0357fb0] [c0003bcc] rest_init+0x78/0xac
[c0357fc0] [c030ab9c] start_kernel+0x2c4/0x2dc
[c0357ff0] [00003438] 0x3438
ata1.00: ATA-7: Hitachi HDT725032VLA360, V54OA52A, max UDMA/133
ata1.00: 625142448 sectors, multi 0: LBA48 NCQ (depth 31/32)
ata1.00: configured for UDMA/100
ata2: SATA link down (SStatus 0 SControl 0)
ata3: SATA link down (SStatus 0 SControl 0)
ata4: SATA link down (SStatus 0 SControl 0)
scsi 0:0:0:0: Direct-Access ATA Hitachi HDT72503 V54O PQ: 0
ANSI: 5
sd 0:0:0:0: [sda] 625142448 512-byte hardware sectors (320073 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 0:0:0:0: [sda] 625142448 512-byte hardware sectors (320073 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 >
sd 0:0:0:0: [sda] Attached SCSI disk
ff800000.flash: Found 1 x16 devices at 0x0 in 16-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
ff800000.flash: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
cmdlinepart partition parsing not available
RedBoot partition parsing not available
Creating 7 MTD partitions on "ff800000.flash":
0x00000000-0x00010000 : "HWCR"
0x00010000-0x00030000 : "Altera"
0x00030000-0x00600000 : "Kernel"
0x00700000-0x00740000 : "u-boot"
0x00740000-0x00750000 : "u-boot-env"
0x00750000-0x00800000 : "JFFS2"
0x00600000-0x00610000 : "Altera Backup"
of-flash f8400000.sram: Device tree uses obsolete "direct-mapped" flash
binding
cmdlinepart partition parsing not available
RedBoot partition parsing not available
Creating 1 MTD partitions on "f8400000.sram":
0x00000000-0x00020000 : "SRAM"
arp_tables: (C) 2002 David S. Miller
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
------------[ cut here ]------------
kernel BUG at kernel/rtmutex.c:692!
Oops: Exception in kernel mode, sig: 5 [#1]
PREEMPT Innovative Systems ApMax
Modules linked in:
NIP: c025c340 LR: c025c318 CTR: c01c8dac
REGS: ef859ad0 TRAP: 0700 Not tainted (2.6.24-rt1)
MSR: 00021032 <ME,IR,DR> CR: 28004042 XER: 20000000
TASK =3D ef852090[8] 'softirq-block/0' THREAD: ef858000
GPR00: 00000001 ef859b80 ef852090 00000000 00000000 00000000 00000000
00000002
GPR08: 00000001 ef852090 ef852090 ef859b80 00000000 ffffffff 0fffd000
00000028
GPR16: 00800564 00800000 00000000 007fff00 00000000 00000001 ef8bc000
ef3ac2f0
GPR24: 00000011 00000000 00000000 ef3f77e0 ef858000 00001032 ef3ac2f0
ef859b80
NIP [c025c340] rt_spin_lock_slowlock+0x7c/0x1c0
LR [c025c318] rt_spin_lock_slowlock+0x54/0x1c0
Call Trace:
[ef859b80] [c025c318] rt_spin_lock_slowlock+0x54/0x1c0 (unreliable)
[ef859be0] [c025c78c] __rt_spin_lock+0x80/0x98
[ef859bf0] [c025c8f8] rt_spin_lock+0x3c/0x54
[ef859c10] [c01c8e14] sil24_interrupt+0x68/0x53c
[ef859c50] [c00529e0] handle_IRQ_event+0x6c/0x114
[ef859c80] [c0052bcc] __do_IRQ+0x144/0x1c4
[ef859ca0] [c0017d88] apmax_int_irq_demux+0x90/0xb8
[ef859cc0] [c00063f0] do_IRQ+0x6c/0xb0
[ef859cd0] [c0010cfc] ret_from_except+0x0/0x28
--- Exception: 501 at ata_qc_issue+0x140/0x684
LR =3D ata_scsi_translate+0x138/0x184
[ef859d90] [ef385960] 0xef385960 (unreliable)
[ef859dd0] [c01bd7a0] ata_scsi_translate+0x138/0x184
[ef859e00] [c01c0d0c] ata_scsi_queuecmd+0x210/0x240
[ef859e20] [c01a46d4] scsi_dispatch_cmd+0x1d0/0x240
[ef859e40] [c01aaecc] scsi_request_fn+0x274/0x340
[ef859e60] [c0160b9c] blk_run_queue+0x68/0xac
[ef859e80] [c01a8ee0] scsi_run_queue+0x1cc/0x1e4
[ef859eb0] [c01a9678] scsi_next_command+0x3c/0x5c
[ef859ed0] [c01a987c] scsi_end_request+0xd4/0xf4
[ef859ef0] [c01a9c30] scsi_io_completion+0xf4/0x320
[ef859f30] [c01a3f78] scsi_finish_command+0x94/0xac
[ef859f50] [c01aa5d4] scsi_softirq_done+0xd4/0xec
[ef859f70] [c015c83c] blk_done_softirq+0x8c/0xbc
[ef859f90] [c0026008] ksoftirqd+0x168/0x27c
[ef859fd0] [c00386d0] kthread+0x50/0x90
[ef859ff0] [c0010408] kernel_thread+0x44/0x60
Instruction dump:
7fc3f378 4bdefce9 2f830000 41be0010 7fc3f378 7fa4eb78 48000140 801e002c
5400003a 7c001278 7c000034 5400d97e <0f000000> 38000004 901f0008
801f0008
Kernel panic - not syncing: Fatal exception in interrupt
Call Trace:
[ef8598f0] [c0008474] show_stack+0x54/0x18c (unreliable)
[ef859920] [c00085cc] dump_stack+0x20/0x38
[ef859930] [c001f198] panic+0x94/0x178
[ef859980] [c000e4d0] die+0x178/0x184
[ef8599a0] [c000e6d8] _exception+0x5c/0x17c
[ef859a90] [c000eadc] program_check_exception+0x154/0x504
[ef859ac0] [c0010cb0] ret_from_except_full+0x0/0x4c
--- Exception: 700 at rt_spin_lock_slowlock+0x7c/0x1c0
LR =3D rt_spin_lock_slowlock+0x54/0x1c0
[ef859be0] [c025c78c] __rt_spin_lock+0x80/0x98
[ef859bf0] [c025c8f8] rt_spin_lock+0x3c/0x54
[ef859c10] [c01c8e14] sil24_interrupt+0x68/0x53c
[ef859c50] [c00529e0] handle_IRQ_event+0x6c/0x114
[ef859c80] [c0052bcc] __do_IRQ+0x144/0x1c4
[ef859ca0] [c0017d88] apmax_int_irq_demux+0x90/0xb8
[ef859cc0] [c00063f0] do_IRQ+0x6c/0xb0
[ef859cd0] [c0010cfc] ret_from_except+0x0/0x28
--- Exception: 501 at ata_qc_issue+0x140/0x684
LR =3D ata_scsi_translate+0x138/0x184
[ef859d90] [ef385960] 0xef385960 (unreliable)
[ef859dd0] [c01bd7a0] ata_scsi_translate+0x138/0x184
[ef859e00] [c01c0d0c] ata_scsi_queuecmd+0x210/0x240
[ef859e20] [c01a46d4] scsi_dispatch_cmd+0x1d0/0x240
[ef859e40] [c01aaecc] scsi_request_fn+0x274/0x340
[ef859e60] [c0160b9c] blk_run_queue+0x68/0xac
[ef859e80] [c01a8ee0] scsi_run_queue+0x1cc/0x1e4
[ef859eb0] [c01a9678] scsi_next_command+0x3c/0x5c
[ef859ed0] [c01a987c] scsi_end_request+0xd4/0xf4
[ef859ef0] [c01a9c30] scsi_io_completion+0xf4/0x320
[ef859f30] [c01a3f78] scsi_finish_command+0x94/0xac
[ef859f50] [c01aa5d4] scsi_softirq_done+0xd4/0xec
[ef859f70] [c015c83c] blk_done_softirq+0x8c/0xbc
[ef859f90] [c0026008] ksoftirqd+0x168/0x27c
[ef859fd0] [c00386d0] kthread+0x50/0x90
[ef859ff0] [c0010408] kernel_thread+0x44/0x60
Rebooting in 180 seconds..
^ permalink raw reply
* Re: locking problem in sata_sil24?
From: Benjamin Herrenschmidt @ 2008-03-03 22:37 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B0410A524@ismail.innsys.innovsys.com>
On Mon, 2008-03-03 at 16:10 -0600, Rune Torgersen wrote:
> Hi I am trying to get PREEMPT_RT pach to wokr on my 2.6.24 kernel, but
> kept gettign a BUG() (kernel BUG at kernel/rtmutex.c:692).
> While tryiong to figure out what it was, I saw some mention of trying
> LOCKDEP to see what is going on, so I patched my -rt1 kernel with some
> lockdep patches from BenH.
>
> Now I get an "inconsistent locking state", but I need help in trying to
> fiure out what I should look for.
> kernel is fo an Freescale 8280 and the locking seems to occur in the
> driver for a Silicon Image SII3124 SATA disk driver
What core is in the 8280 ? At this stage, I wouldn't rule out a bug in
the lockdep patches, I need to do more work on them.
Cheers,
Ben.
^ permalink raw reply
* RE: locking problem in sata_sil24?
From: Rune Torgersen @ 2008-03-03 22:44 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <1204583866.21545.31.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Mon, 2008-03-03 at 16:10 -0600, Rune Torgersen wrote:
>> Hi I am trying to get PREEMPT_RT pach to wokr on my 2.6.24 kernel,
> What core is in the 8280 ? At this stage, I wouldn't rule out a bug in
> the lockdep patches, I need to do more work on them.
Should be an 603e
adn revision (from u-boot)
CPU: MPC8280 (HiP7 Rev 14, Mask 1.0 1K49M) at 447.897 MHz
I am currently compiling a LOCKDEP kernel for my x86 desktop, as it has
the exact same SiliconImage controller on a card, so I'll see if it gets
a similar detection.
^ permalink raw reply
* RE: locking problem in sata_sil24?
From: Benjamin Herrenschmidt @ 2008-03-03 22:58 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B0410A575@ismail.innsys.innovsys.com>
On Mon, 2008-03-03 at 16:44 -0600, Rune Torgersen wrote:
> Benjamin Herrenschmidt wrote:
> > On Mon, 2008-03-03 at 16:10 -0600, Rune Torgersen wrote:
> >> Hi I am trying to get PREEMPT_RT pach to wokr on my 2.6.24 kernel,
>
> > What core is in the 8280 ? At this stage, I wouldn't rule out a bug in
> > the lockdep patches, I need to do more work on them.
>
> Should be an 603e
> adn revision (from u-boot)
> CPU: MPC8280 (HiP7 Rev 14, Mask 1.0 1K49M) at 447.897 MHz
>
>
>
> I am currently compiling a LOCKDEP kernel for my x86 desktop, as it has
> the exact same SiliconImage controller on a card, so I'll see if it gets
> a similar detection.
In fact, I remember working on 64 bits lockdep, based on patches from
Johannes, but I didn't do 32 bits. I think somebody worked on it, but
now I can't find the patches...
Whoever did it can bounce them back to me ? I intend to do some more
work on this soon.
Cheers,
Ben.
^ permalink raw reply
* RE: locking problem in sata_sil24?
From: Rune Torgersen @ 2008-03-03 23:13 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <1204585095.21545.37.camel@pasglop>
> From: Benjamin Herrenschmidt
> In fact, I remember working on 64 bits lockdep, based on patches from
> Johannes, but I didn't do 32 bits. I think somebody worked on it, but
> now I can't find the patches...
http://patchwork.ozlabs.org/linuxppc/patch?id=3D16652
> Whoever did it can bounce them back to me ? I intend to do some more
> work on this soon.
^ permalink raw reply
* RE: locking problem in sata_sil24?
From: Johannes Berg @ 2008-03-03 23:28 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <1204585095.21545.37.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 550 bytes --]
> In fact, I remember working on 64 bits lockdep, based on patches from
> Johannes,
Your patches never really worked for me so far but I'll be happy to try
new ones, haven't gotten around to checking into the differences.
> but I didn't do 32 bits. I think somebody worked on it, but
> now I can't find the patches...
>
> Whoever did it can bounce them back to me ? I intend to do some more
> work on this soon.
That was Dale Farnsworth, with the subject
"[RFC/PATCH] powerpc: Add irqtrace support to 32-bit powerpc"
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH 0/8] pseries: phyp dump: hypervisor-assisted dump
From: Joel Schopp @ 2008-03-03 23:37 UTC (permalink / raw)
To: Manish Ahuja; +Cc: ppc-dev, Linas Vepstas, paulus
In-Reply-To: <47C74A66.1060105@austin.ibm.com>
This looks like it is to a stable usable point now. In my opinion it is
ready to be merged into the next tree for 2.6.26.
Reviewed-by: Joel Schopp <jschopp@austin.ibm.com>
Manish Ahuja wrote:
> Changes from previous version:
>
> The only changes are in patch 2.
> moved early_init_dt_scan_phyp_dump from rtas.c to phyp_dump.c
> Added dummy function in phyp_dump.h
>
> Patch 3 required repatching due to changes to patch 2.
> Resubmitting all patches to avoid confusion.
>
> Thanks,
> Manish
>
>
> Michael Ellerman wrote:
>
>> On Sun, 2008-02-17 at 22:53 -0600, Manish Ahuja wrote:
>>
>>> The following series of patches implement a basic framework
>>> for hypervisor-assisted dump. The very first patch provides
>>> documentation explaining what this is :-) . Yes, its supposed
>>> to be an improvement over kdump.
>>>
>>> A list of open issues / todo list is included in the documentation.
>>> It also appears that the not-yet-released firmware versions this was tested
>>> on are still, ahem, incomplete; this work is also pending.
>>>
>>> I have included most of the changes requested. Although, I did find
>>> one or two, fixed in a later patch file rather than the first location
>>> they appeared at.
>>>
>> This series still doesn't build on !CONFIG_RTAS configs:
>> http://kisskb.ellerman.id.au/kisskb/head/629/
>>
>> This solution is to move early_init_dt_scan_phyp_dump() into
>> arch/powerpc/platforms/pseries/phyp_dump.c and provide a dummy
>> implementation in asm-powerpc/phyp_dump.c for the !CONFIG_PHYP_DUMP
>> case.
>>
>> cheers
>>
>>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Bamboo PCI interrupt issues
From: Hollis Blanchard @ 2008-03-04 0:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kvm-ppc-devel
I'm having two problems with PCI interrupts as described in bamboo.dts.
Here is are the properties in question:
/* Bamboo has all 4 IRQ pins tied together per slot */
interrupt-map-mask = <f800 0 0 0>;
interrupt-map = <
/* IDSEL 1 */
0800 0 0 0 &UIC0 1c 8
/* IDSEL 2 */
1000 0 0 0 &UIC0 1b 8
/* IDSEL 3 */
1800 0 0 0 &UIC0 1a 8
/* IDSEL 4 */
2000 0 0 0 &UIC0 19 8
>;
First, the 440EP[1] and Bamboo[2] user manuals indicate that PCI IRQ 0-3
-> board IRQ 2-5 -> UIC IRQ 25-28. However, the device tree has that
reversed, so PCI IRQ 0 appears as UIC IRQ 28 (0x1c).
Second, the sensitivity seems to be wrong. All these interrupts have the
sensitivity encoded as 8, which means "high to low edge" in the OpenPIC
binding. Now, 440EP has a UIC, rather than an OpenPIC, but there is no
UIC binding AFAICS.
When I change the 8 to a 4 ("active high level"), I see the proper
values in the UIC polarity register, and PCI interrupts start working in
KVM.
Is anybody using Bamboo PCI support right now? Does it actually work?
[1]
https://www.amcc.com/MyAMCC/retrieveDocument/PowerPC/440EP/PPC440EP_UM2000.pdf
[2] Seems to have been deleted from the web. Thanks, AMCC.
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 3/3] ppc64-specific memory notifier support
From: Nathan Lynch @ 2008-02-29 0:39 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Badari Pulavarty
In-Reply-To: <1204243875.7729.3.camel@concordia.ozlabs.ibm.com>
Michael Ellerman wrote:
> On Thu, 2008-02-28 at 08:46 -0800, Badari Pulavarty wrote:
> > Hotplug memory notifier for ppc64. This gets invoked by writing
> > the device-node that needs to be removed to /proc/ppc64/ofdt.
> > We need to adjust the sections and remove sysfs entries by
> > calling __remove_pages(). Then call arch specific code to
> > get rid of htab mappings for the section of memory.
> >
> > Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com>
> > ---
> > arch/powerpc/platforms/pseries/Makefile | 1
> > arch/powerpc/platforms/pseries/hotplug-memory.c | 98 ++++++++++++++++++++++++
> > 2 files changed, 99 insertions(+)
> >
> > Index: linux-2.6.25-rc2/arch/powerpc/platforms/pseries/hotplug-memory.c
> > ===================================================================
> > --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> > +++ linux-2.6.25-rc2/arch/powerpc/platforms/pseries/hotplug-memory.c 2008-02-28 08:20:14.000000000 -0800
>
> > +
> > +static struct notifier_block pseries_smp_nb = {
> > + .notifier_call = pseries_memory_notifier,
> > +};
> > +
> > +static int __init pseries_memory_hotplug_init(void)
> > +{
> > + if (firmware_has_feature(FW_FEATURE_LPAR))
> > + pSeries_reconfig_notifier_register(&pseries_smp_nb);
> > +
> > + return 0;
> > +}
> > +arch_initcall(pseries_memory_hotplug_init);
>
> This is going to fire on non-pseries LPAR platforms, like iSeries and
> PS3. Which is not what you want I think.
Well, the notifier will be registered, yes, but it will never be
called because that path is reachable only from a write to
/proc/ppc64/ofdt, which is not created on non-pseries.
Maybe it should be
machine_device_initcall(pseries, pseries_memory_hotplug_init);
(and pseries_cpu_hotplug_init in hotplug-cpu.c should be changed to
machine_arch_initcall)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox