* Re: [patch 5/6] PARISC: move PERR & SERR enables out of pcibios_enable_resources()
From: Jesse Barnes @ 2008-03-03 18:30 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, Chris Zankel, Grant Grundler, linux-parisc,
Matthew Wilcox, Kyle McMartin, linuxppc-dev, Paul Mackerras,
linux-arm-kernel, Russell King, Bjorn Helgaas
In-Reply-To: <20080228173125.GA16270@colo.lackof.org>
On Thursday, February 28, 2008 9:31 am Grant Grundler wrote:
> In general, I'm wondering if the check for device class would be
> sufficient here to NOT enable PERR/SERR for graphics automatically.
> While disabling PERR was "the right thing" for older "mostly write"
> devices of the 1990's and early 2000, it might not be correct for
> current 3-D graphics devices which use host mem to buffer processed
> results. I'm thinking of Intel graphics controllers in particular
> but I don't know any details of how they actually work.
Well, in general chipset devices aren't required to support parity checking,
AIUI; Intel gfx devices don't bother (PERR enable is hardwired to 0).
> I'm also a bit concerned about this now becuase (IIRC) AGP didn't
> implement parity though it looked like PCI protocol. PCI-e certainly
> does but it's possible BIOS/Firmware disable parity generation
> on the host bridge when connected to a gfx device.
> We wouldn't want to enable parity checking on a PCI-e gfx device in this
> case and I hope someone (perhaps at Intel) could double check this.
I'd have to ping our BIOS folks to see if that's the case, but I doubt it. It
would be a bad idea to disable any PCIe error reporting (including legacy
error mapping) just because a gfx device was attached. Apparently the AMD
PCIe parts include PERR generation, so disabling upstream reporting at boot
time seems like it would be an outright bug; it should be left up to driver &
OS software.
Jesse
^ permalink raw reply
* [PATCH][MTD][NOR]Add support for the SST 36VF3203 flash chip
From: Andrei Dolnikov @ 2008-03-03 18:01 UTC (permalink / raw)
To: linux-mtd; +Cc: linuxppc-dev
Add support for the SST 36VF3203 flash chip. It is used on Emerson KSI8560 board.
Signed-off-by: Andrei Dolnikov <adolnikov@ru.mvista.com>
---
jedec_probe.c | 13 +++++++++++++
1 files changed, 13 insertions(+)
diff --git a/drivers/mtd/chips/jedec_probe.c b/drivers/mtd/chips/jedec_probe.c
index 6405938..15e061b 100644
--- a/drivers/mtd/chips/jedec_probe.c
+++ b/drivers/mtd/chips/jedec_probe.c
@@ -160,6 +160,7 @@
#define SST49LF030A 0x001C
#define SST49LF040A 0x0051
#define SST49LF080A 0x005B
+#define SST36VF3203 0x7354
/* Toshiba */
#define TC58FVT160 0x00C2
@@ -1412,6 +1413,18 @@ static const struct amd_flash_info jedec_table[] = {
ERASEINFO(0x1000,256)
}
}, {
+ .mfr_id = MANUFACTURER_SST,
+ .dev_id = SST36VF3203,
+ .name = "SST 36VF3203",
+ .devtypes = CFI_DEVICETYPE_X16|CFI_DEVICETYPE_X8,
+ .uaddr = MTD_UADDR_0x0AAA_0x0555,
+ .dev_size = SIZE_4MiB,
+ .cmd_set = P_ID_AMD_STD,
+ .nr_regions = 1,
+ .regions = {
+ ERASEINFO(0x10000,64),
+ }
+ }, {
.mfr_id = MANUFACTURER_ST,
.dev_id = M29F800AB,
.name = "ST M29F800AB",
^ permalink raw reply related
* Re: [patch 6/6] PCI: consolidate several pcibios_enable_resources() implementations
From: Jesse Barnes @ 2008-03-03 18:45 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, Chris Zankel, Grant Grundler, linux-parisc,
Matthew Wilcox, Kyle McMartin, linuxppc-dev, Paul Mackerras,
linux-arm-kernel, Russell King, Bjorn Helgaas
In-Reply-To: <20080228001053.404893334@ldl.fc.hp.com>
On Wednesday, February 27, 2008 4:04 pm 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 consolidates most of them to use the version annotated below.
> This is the original x86 version, except that it uses the resource
> collision check from powerpc at (5):
Looks really good to me, definitely a step in the right direction.
> The mips/pmc-sierra implementation of pcibios_enable_resources() is
> cluttered with a bunch of titan stuff, so I can't immediately consolidate
> it with the others. So I made the generic version "weak" so pmc-sierra
> can override it.
>
> Not-Yet-Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
So you'd like to see the MIPS stuff cleaned up a bit more first before actual
sign-off? Or just more testing?
> 18 files changed, 43 insertions(+), 507 deletions(-)
Nice diffstat. :)
Jesse
^ permalink raw reply
* Re: [PATCH] add strncmp to PowerPC
From: Segher Boessenkool @ 2008-03-03 19:08 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev, paulus, LKML, Steven Rostedt
In-Reply-To: <20080303095443.GB27105@iram.es>
>> Even if it was logically faster (which I still doubt) it's a hell of
>> a lot
>> of cache lines to waste.
Yeah, 1 on 64-bit and 3 on 32-bit, that's a terrible lot.</sarcasm>
> Indeed, but there are some corner cases that the C code handles. Like
> a length of 0 which may lead to infinite loop in the asm code.
>
> OTOH, I'm a bit surprised by the extsb instructions in the compiler
> generated
> code. We don't compile with -fsigned-char, do we? The clrldi
> instructions are also extremely stupid.
Those are both necessary to be equivalent to the C code, which uses
signed char explicitly. It is generally considered a Good Thing(tm)
for the compiler to generate assembler code equivalent to the C code,
even if the C code is wrong.
> Now that I think a bit more about it, I believe that the C version is
> incorrect
It is. It's a great entry for the IOCCC as well.
I just tested the following (can't guarantee it's correct, just a PoC):
int strncmp(const char *s1, const char *s2, unsigned long /*size_t*/
len)
{
while (len--) {
unsigned char c1, c2;
c1 = *s1++;
c2 = *s2++;
int cmp = c1 - c2;
if (cmp)
return cmp;
if (c1 == 0 || c2 == 0)
break;
}
return 0;
}
which generates (with GCC-4.2.3)
strncmp:
addi 5,5,1
mtctr 5
.L2:
bdz .L11
lbz 0,0(3)
addi 3,3,1
lbz 9,0(4)
addi 4,4,1
cmpwi 7,0,0
subf. 0,9,0
cmpwi 6,9,0
bne- 0,.L4
beq- 7,.L4
bne+ 6,.L2
.L4:
mr 3,0
blr
.L11:
li 0,0
mr 3,0
blr
which isn't horrid, although it does some weirdish things obviously.
Current GCC-4.4.0 generates
strncmp:
addi 5,5,1
mr 10,3
mtctr 5
li 11,0
bdz .L7
.p2align 4,,15
.L4:
lbzx 0,10,11
lbzx 9,4,11
addi 11,11,1
subf. 3,9,0
cmpwi 6,9,0
cmpwi 7,0,0
bnelr 0
beqlr 7
beqlr 6
bdnz .L4
.L7:
li 3,0
blr
which is about as good as it can get (well, it didn't realise you
only need to test one of c1, c2 for zero. Did I say this was just
proof-of-concept code?)
Segher
^ permalink raw reply
* Re: [PATCH 2/2 v2] [POWERPC] Ignore disabled serial ports
From: Scott Wood @ 2008-03-03 19:09 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus, Arnd Bergmann
In-Reply-To: <20080302224317.15f259ca@zod.rchland.ibm.com>
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...
-Scott
^ permalink raw reply
* Re: [PATCH 2/2 v2] [POWERPC] Ignore disabled serial ports
From: Josh Boyer @ 2008-03-03 19:21 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus, Arnd Bergmann
In-Reply-To: <20080303190925.GA6735@loki.buserror.net>
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.
josh
^ permalink raw reply
* Re: [patch 6/6] PCI: consolidate several pcibios_enable_resources() implementations
From: Bjorn Helgaas @ 2008-03-03 19:10 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
In-Reply-To: <200803031045.07054.jbarnes@virtuousgeek.org>
On Monday 03 March 2008 11:45:06 am Jesse Barnes wrote:
> On Wednesday, February 27, 2008 4:04 pm Bjorn Helgaas wrote:
> >
> > Not-Yet-Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
>
> So you'd like to see the MIPS stuff cleaned up a bit more first before actual
> sign-off? Or just more testing?
I think it'd be *nice* if that MIPS stuff got cleaned up, but that's
way beyond my scope. I just want to address Kyle's comments and make
sure I don't screw up ARM and PARISC.
Bjorn
^ permalink raw reply
* 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
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