headers
Michael Ellerman | 1 Mar 2007 01:30
Picon
Gravatar

Re: Make sure we populate the initroot filesystem late enough

On Wed, 2007-02-28 at 10:13 +0000, David Woodhouse wrote:
> On Wed, 2007-02-28 at 07:43 +0100, Benjamin Herrenschmidt wrote:
> > I wouldn't be that sure ... I've had problems in the past with PMU based
> > cpufreq... looks like flushing all caches and hard-resetting the
> > processor on the fly when there can be pending DMAs might be a source of
> > trouble... especially on CPUs that don't have working cache flush HW
> > assist. 
> 
> I've seen it on a PowerMac3,1 (400MHz G4) where we don't have cpufreq.
> I've also seen it on the latest 1.5GHz Mac Mini, and on my shinybook.
> They all fall over with the latest kernel, although the shinybook only
> does so immediately when booted with mem=512M. The shinybook does crash
> later with new kernels though; I don't yet know why. It could be the
> same thing, or it could be something different. That one seemed to
> appear between Fedora's 2.6.19-1.2913 and 2.6.19-1.2914 kernels, where
> we did nothing but turned CONFIG_SYSFS_DEPRECATED on.
> 
> I don't blame cpufreq. At various times I've been equally convinced that
> it was due to CONFIG_KPROBES, and Linus' initrd-moving patch.

Is there any pattern to the way it dies? Or is it just randomly dieing
somewhere depending on which config options you have enabled?

This is starting to sound reminiscent of a bug I chased for a while last
year on Power5, but didn't find. It was "fixed" on some machines by
disabling CONFIG_KEXEC, and/or other random unrelated CONFIG options.
Unfortunately it magically stopped reproducing so I never caught it :/

cheers
(Continue reading)

Permalink | Reply | 0 comments |
headers
Segher Boessenkool | 1 Mar 2007 02:53

Re: problems with pci bus on a pm520 board

>  * JohnDeere Vehicleserver (based on pm520 board by microsys) 
> devicetree file
>  * Copyright 2006 Pengutronix
>  * Luotao Fu <l.fu <at> pengutronix.de>

You removed the original copyright notice, please don't;
it might even be illegal to do so, depending on where
you live/work.  Just add your own, don't remove the original.

> 			interrupt-map = <8000 0 0 1 500 1 1 3 // e100, 10.0
> 			                 8000 0 0 2 500 1 1 3
> 			                 8000 0 0 3 500 1 1 3
> 			                 8000 0 0 4 500 1 1 3

8000 is device 16, not 10

> 			                 8800 0 0 1 500 1 0 3 // usb 11.0, 11.1, 11.2
> 			                 8800 0 0 2 500 1 2 3
> 			                 8800 0 0 3 500 1 3 3
> 			                 8800 0 0 4 500 0 0 3>;

and 8800 is device 17

Your tree looks reasonable otherwise, I didn't look at
the details though.

Hope that helps,

Segher
(Continue reading)

Permalink | Reply | 4 comments |
headers
Segher Boessenkool | 1 Mar 2007 02:55

Re: [RFC] powerpc: Document new property called interrupt-parents

>> Do the version and last_comp_version in the blob header
>> help here?
>
> Unfortunately not.  Those fields version the the serialization format
> of the device tree, not the content of the device tree.

I'm glad you agree :-)

Segher
Permalink | Reply | 0 comments |
headers
Michael Ellerman | 1 Mar 2007 07:11
Picon
Gravatar

[PATCH] Allow spufs to build as a module with slices enabled

The slice code is missing some exports to allow spufs to build as a
module. Add them.

Signed-off-by: Michael Ellerman <michael <at> ellerman.id.au>
---
 MODPOST 209 modules
WARNING: ".get_slice_psize" [arch/powerpc/platforms/cell/spufs/spufs.ko] undefined!
WARNING: ".slice_get_unmapped_area" [arch/powerpc/platforms/cell/spufs/spufs.ko] undefined!

---
 arch/powerpc/mm/slice.c |    3 +++
 1 file changed, 3 insertions(+)

Index: ecell/arch/powerpc/mm/slice.c
===================================================================
--- ecell.orig/arch/powerpc/mm/slice.c
+++ ecell/arch/powerpc/mm/slice.c
 <at>  <at>  -29,6 +29,7  <at>  <at> 
 #include <linux/pagemap.h>
 #include <linux/err.h>
 #include <linux/spinlock.h>
+#include <linux/module.h>
 #include <asm/mman.h>
 #include <asm/mmu.h>
 #include <asm/spu.h>
 <at>  <at>  -499,6 +500,7  <at>  <at>  unsigned long slice_get_unmapped_area(un
 	return addr;

 }
+EXPORT_SYMBOL(slice_get_unmapped_area);
(Continue reading)

Permalink | Reply | 2 comments |
headers
Michael Ellerman | 1 Mar 2007 07:18
Picon
Gravatar

Re: [PATCH 14/22] spufs: use SPU master control to prevent wild SPU execution

On Mon, 2006-11-20 at 18:45 +0100, Arnd Bergmann wrote:
> plain text document attachment (spufs-master-control.diff)
> When the user changes the runcontrol register, an SPU might be
> running without a process being attached to it and waiting for
> events. In order to prevent this, make sure we always disable
> the priv1 master control when we're not inside of spu_run.

Hi Arnd,

Sorry I didn't comment on this when you sent it, I wasn't paying enough
attention. This patch confuses me, you say we should make sure we always
disable the master control when we're not inside spu_run, but I see
several exit paths where we leave the master run bit enabled - or maybe
I'm reading it wrong.

I think I've also seen it happen:

[root <at> localhost dma5]# ./put-test 
10963.13
[root <at> localhost dma5]# find /spu
/spu
[root <at> localhost dma5]# echo x > /proc/sysrq-trigger 
SysRq : Entering xmon

0:mon> ss
..
Stopped spu 06, was running (mfc_sr1: 0x32 runcntl: 0x1)
Stopped spu 07, was running (mfc_sr1: 0x32 runcntl: 0x1)
..
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Ellerman | 1 Mar 2007 08:29
Picon
Gravatar

Re: [PATCH 0/5] Support 64K pages mapping of SPE local stores on 4K kernel

On Tue, 2007-02-20 at 18:44 +1100, Benjamin Herrenschmidt wrote:
> This serie of patches supports userland mappings of SPE local stores
> using 64K hardware pages rather than 4K on a kernel using 4K pages to
> improve performances.
> 
> The current version of this serie relies on a hack to the generic code
> which is probably not acceptable upsteam. I have plans to do a proper
> fix but haven't had time to do it yet.
> 
> The first patch of the serie is fairly independant of the rest and
> should be applied to 2.6.21 as I beleive it fixes a bug with handling
> of huge pages from SPEs.

Unfortunately this seems to break a test case I have which dmas between
two SPEs.

The process just seems to hang, the machine is still pingable. gdb hangs
attaching to the spu process, but killing the spu process from another
console seems to return the system to normal.

cheers

--

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luotao Fu | 1 Mar 2007 10:29
Picon

Re: problems with pci bus on a pm520 board

Hi,

Segher Boessenkool wrote:

> You removed the original copyright notice, please don't;
> it might even be illegal to do so, depending on where
> you live/work.  Just add your own, don't remove the original.
> 

OK, thanx for the hint.

>>             interrupt-map = <8000 0 0 1 500 1 1 3 // e100, 10.0
>>                              8000 0 0 2 500 1 1 3
>>                              8000 0 0 3 500 1 1 3
>>                              8000 0 0 4 500 1 1 3
> 
> 8000 is device 16, not 10
> 
>>                              8800 0 0 1 500 1 0 3 // usb 11.0, 11.1, 11.2
>>                              8800 0 0 2 500 1 2 3
>>                              8800 0 0 3 500 1 3 3
>>                              8800 0 0 4 500 0 0 3>;
> 
> and 8800 is device 17
> 

Hmm, this is strange. I put some debug printks in the of parser
prom_parser.c in the function of_irq_map_raw somewhere in the machting
loop, which prints the imap and address being parsed. So that the lines
at about 834 now looks like this:
(Continue reading)

Permalink | Reply | 3 comments |
headers
Russell King | 1 Mar 2007 11:30
Picon

Re: [PATCH 1/2] Define FIXED_PORT flag for serial_core

On Thu, Mar 01, 2007 at 10:44:24AM +1100, David Gibson wrote:
> On Wed, Feb 28, 2007 at 10:26:30PM +0000, Russell King wrote:
> > On Tue, Feb 20, 2007 at 02:19:51PM +1100, David Gibson wrote:
> > > Therefore, this patch defines a UPF_FIXED_PORT flag for the uart_port
> > > structure.  If this flag is set when the serial port is configured,
> > > any attempts to alter the port's type, io address, irq or base clock
> > > with setserial are ignored.
> > 
> > I've been wondering about this, and it is questionable whether we
> > should allow any serial port which isn't owned by the legacy platform
> > device (the one called "serial8250", iow by the 8250 driver itself)
> > to have the base addresses and interrupts changed.
> > 
> > IOW, we apply this "fixed port" to any port registered by probe
> > modules external to the 8250 driver itself, such as PCI, PNP, etc.
> 
> Sounds reasonable to me.  But maybe in that case we should invert the
> sense of the flag.  UPF_MOVABLE_PORT or UPF_USER_CONFIGURABLE or
> something.

I was thinking about not even having a flag, but instead checking for
port->dev == &serial8250_isa_devs->dev.

--

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
Permalink | Reply | 0 comments |
headers
Segher Boessenkool | 1 Mar 2007 13:54

Re: problems with pci bus on a pm520 board

>>>             interrupt-map = <8000 0 0 1 500 1 1 3 // e100, 10.0
>>>                              8000 0 0 2 500 1 1 3
>>>                              8000 0 0 3 500 1 1 3
>>>                              8000 0 0 4 500 1 1 3
>>
>> 8000 is device 16, not 10

<snip>

> I got the address 8000 here. Is the
> pdev->bus->number actually supposed to be 10 for device 10? I had some
> trouble tracking down how the bus number is initialized. It might be
> nice if you or some one could give me a hint on this.

8000 is device 16 is 0x10 hex.  PCI device numbers are
usually written in decimal.  Is your device 10 == 0x0a
or 16 == 0x10?

Segher
Permalink | Reply | 2 comments |
headers
Jerry Van Baren | 1 Mar 2007 15:01

RFA & Update: Using libfdt in u-boot for fdt command

Hi all,

This is a Request for Advice.

First off, for those on both the u-boot and linuxppc-dev lists, sorry 
for cross posting.  :-)

Git repo pointers...
libfdt hacks:
<http://www.cideas.us/cgi-bin/gitweb.cgi?p=linux/libfdt.git;a=summary>
u-boot hacks:
<http://www.cideas.us/cgi-bin/gitweb.cgi?p=u-boot/u-boot-mpc83xx;a=summary>

I have a proof-of-concept (actually, somewhat more than PoC) fdt command 
built using libfdt.  Now I'm looking for advice on the best way to turn 
the PoC into Real Code[tm].

Current commands:
-----------------
fdt address        - set the base address of the blob
fdt get <property> - get a property
fdt print <node>   - print the subtree starting at <node>[1]

Planned commands:
-----------------
fdt set <property> <value> - set a property value (do we want an
                        "=" as in <property> = <value>?)
fdt ?synthesize?   - create the "chosen" branch and optionally the
                        u-boot variables branch.  The OF code/calls
                        currently in bootm would be moved to this
(Continue reading)

Permalink | Reply | 0 comments |

Gmane