* PS3 early lock-up
From: Geert Uytterhoeven @ 2008-08-04 15:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linux/PPC Development
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2591 bytes --]
On PS3, recent kernels lock up in the very early stage (i.e. before mere
mortals get to see a working console). The kernel crashes with
| kernel BUG at linux/arch/powerpc/platforms/ps3/htab.c:141!
Bisecting shows this happens since:
| commit a1f242ff460e4b50a045fa237c3c56cce9eabf83
| Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
| Date: Wed Jul 23 21:27:08 2008 -0700
|
| powerpc ioremap_prot
|
| This adds ioremap_prot and pte_pgprot() so that one can extract protection
| bits from a PTE and use them to ioremap_prot() (in order to support ptrace
| of VM_IO | VM_PFNMAP as per Rik's patch).
|
| This moves a couple of flag checks around in the ioremap implementations
| of arch/powerpc. There's a side effect of allowing non-cacheable and
| non-guarded mappings on ppc32 which before would always have _PAGE_GUARDED
| set whenever _PAGE_NO_CACHE is.
|
| (standard ioremap will still set _PAGE_GUARDED, but ioremap_prot will be
| capable of setting such a non guarded mapping).
Inside ps3_hpte_insert(), lv1_write_htab_entry() fails with error code 5
(LV1_ACCESS_VIOLATION) when adding the PS3 hotplug memory.
debug_dump_hpte() prints for the offending hpte:
| pa = 500001000000h
| lpar = 500001000000h
| va = adc7d4c2d0000000h
| group = 6168h
| bitmap = 0h
| hpte.v = adc7d4c2d011h
| hpte.r = 500001000115h
^
| psize = 0h
| slot = 6168h
After manually reverting the offending commit, the system boots again. The only
change is:
| pa = 500001000000h
| lpar = 500001000000h
| va = adc7d4c2d0000000h
| group = 6168h
| bitmap = 0h
| hpte.v = adc7d4c2d011h
| hpte.r = 500001000117h
^
| psize = 0h
| slot = 6168h
Note that when adding the initial (non-hotplug) memory, hpte.r always ends in
`194', both before and after reverting the offending commit.
ps3_hpte_insert() seems to be called during system initialization with the
following values of rflags:
- first call: 0x190
- initial memory: 0x194 (455 times)
- hotplug memory:
o crash: 0x115
o OK: 0x117
Do you have an idea of what's really going on?
Thanks!
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis 293-0376800-10 GEBA-BE-BB
^ permalink raw reply
* Re: [PATCH] port ndfc driver to arch/powerpc
From: Arnd Bergmann @ 2008-08-04 16:25 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Sean MacLennan
In-Reply-To: <20080801233000.3574434f@lappy.seanm.ca>
On Saturday 02 August 2008, Sean MacLennan wrote:
> This is a port of the ndfc driver from arch/ppc to arch/powerpc. Since
> arch/ppc has been removed, references to CONFIG_PPC_MERGE where removed.
>
> For an example of how to use the driver see
> arch/powerpc/platforms/44x/warp-nand.c .
>
> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
Shouldn't this instead use the device tree, like fsl_elbc, fsl_upm
and pasemi_nand do?
It feels awfully backwards to hardcode this stuff in the platform
source code.
Arnd <><
^ permalink raw reply
* Re: [PATCH 3/3] powerpc - Make the irq reverse mapping radix tree lockless
From: Daniel Walker @ 2008-08-04 16:31 UTC (permalink / raw)
To: Sebastien Dugue
Cc: tinytim, linux-rt-users, linux-kernel, rostedt, jean-pierre.dion,
linuxppc-dev, paulus, gilles.carry, tglx
In-Reply-To: <1217848124-3719-4-git-send-email-sebastien.dugue@bull.net>
On Mon, 2008-08-04 at 13:08 +0200, Sebastien Dugue wrote:
> --- a/arch/powerpc/include/asm/irq.h
> +++ b/arch/powerpc/include/asm/irq.h
> @@ -119,6 +119,7 @@ struct irq_host {
> } linear;
> struct radix_tree_root tree;
> } revmap_data;
> + spinlock_t tree_lock;
You have a tabbing issue above..
Daniel
^ permalink raw reply
* Re: [PATCH] port ndfc driver to arch/powerpc
From: Sean MacLennan @ 2008-08-04 17:24 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Sean MacLennan
In-Reply-To: <200808041825.02314.arnd@arndb.de>
On Mon, 4 Aug 2008 18:25:02 +0200
"Arnd Bergmann" <arnd@arndb.de> wrote:
> Shouldn't this instead use the device tree, like fsl_elbc, fsl_upm
> and pasemi_nand do?
> It feels awfully backwards to hardcode this stuff in the platform
> source code.
Yes, yes it should. This is just a patch to get the driver working... it
is not a full blown of platform driver.
Currently there is no working NDFC driver in the kernel. I felt a
working driver, even if less than optimal, is better than not
supporting NAND on the 44x. This driver is no worse than the
arch/ppc version was, it is just no better ;)
Cheers,
Sean
^ permalink raw reply
* Re: Creating a wrapped zImage.initrd -- can't start the trampoline?
From: Grant Likely @ 2008-08-04 17:25 UTC (permalink / raw)
To: Paul Smith; +Cc: Linuxppc-embedded
In-Reply-To: <1217644827.6390.12.camel@homebase.localnet>
On Fri, Aug 01, 2008 at 10:40:27PM -0400, Paul Smith wrote:
> Anyway, I need to generate an all-in-one image containing the kernel and
> the initrd, and the trampoline code tacked onto it to turn it into an
> ELF image. I'm worried I'll need to write a custom platform_init() but
> for now I'm just using of.c.
Take a look at Documentation/powerpc/bootwrapper.txt
You probably want the 'simpleImage.%' target. It also binds in a copy
of the device tree blob.
g.
^ permalink raw reply
* PCI support on the ML310 (Linux 2.4/2.6)
From: Juliana Su @ 2008-08-04 20:08 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am trying to get PCI support on the ML310. I was able to port Linux
2.6 (linux-2.6-virtex from Secret Lab) onto the board, but unfortunately
there is no PCI support in the kernel. When I enabled PCI support, I got
the same errors (see below) that were reported on the Secret Lab Wiki.
CC arch/ppc/syslib/ppc4xx_setup.o
arch/ppc/syslib/ppc4xx_setup.c: In function `ppc4xx_map_io':
arch/ppc/syslib/ppc4xx_setup.c:118: error: `PPC4xx_PCI_IO_VADDR'
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:118: error: (Each undeclared identifier
is reported only once
arch/ppc/syslib/ppc4xx_setup.c:118: error: for each function it appears in.)
arch/ppc/syslib/ppc4xx_setup.c:119: error: `PPC4xx_PCI_IO_PADDR'
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:119: error: `PPC4xx_PCI_IO_SIZE'
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:120: error: `PPC4xx_PCI_CFG_VADDR'
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:121: error: `PPC4xx_PCI_CFG_PADDR'
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:121: error: `PPC4xx_PCI_CFG_SIZE'
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:122: error: `PPC4xx_PCI_LCFG_VADDR'
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:123: error: `PPC4xx_PCI_LCFG_PADDR'
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:123: error: `PPC4xx_PCI_LCFG_SIZE'
undeclared (first use in this function)
make[1]: *** [arch/ppc/syslib/ppc4xx_setup.o] Error 1
make: *** [arch/ppc/syslib] Error 2
I went back to Linux 2.4 (v2.4.20_mvl31-ml300), but the system hangs
during ml310_init( ), specifically when it gets to pci_init( ), in
ml310.c. I put some print statements in ml310.c to debug and found out
that it gets pass the first two lines in pci_init( ) before hanging.
Basically, all I get on my screen is:
Xilinx ML310 Board-Specific Initialization:
ml310_init( ) looks like this:
void
ml310_init()
{
prints("\n\n");
prints("Xilinx ML310 Board-Specific Initialization:\n");
prints("\n");
pci_init();
ppb_init(9);
pci_scan();
sio_init();
sbr_init();
};
and pci_init( ) looks like this:
void
pci_init()
{
/* self-configuration */
WR32(PCI_CONFIG_ADDR, htole32(0x80004004)); // address
WR32(PCI_CONFIG_DATA, htole32(0xffff0147)); // data
/* max latency timer on bridge */
WR32(PCI_CONFIG_ADDR, htole32(0x8000400c)); // address
WR32(PCI_CONFIG_DATA, htole32(0x0000ff00)); // data
/* max bus number */
WR32(PCI_CONFIG_ADDR+8, htole32(0xff000000));
};
ml310.c was generated when I made the BSP in Xilinx EDK 9.1. I copied
it, along with the other files from the BSP, into the kernel source. I
am using a Crosstool cross-compiler, gcc-3.4.1-glibc-2.3.3. I have also
tried the linuxppc-2.4 and mvistappc_2_4_devel kernels from
source.mvista.com, but those both crashed with similar (and several)
errors concerning ide-taskfile.c during compilation.
Is anybody aware of how to manually map the PCI constants in 2.6 and
willing to help me map them? Does anybody have an idea why pci_init( )
is getting stuck? Any suggestions, in general, would be greatly appreciated.
Let me know if I need to provide more information or code. Thanks!
-Juliana
^ permalink raw reply
* Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
From: Paul Collins @ 2008-08-04 20:51 UTC (permalink / raw)
To: michael; +Cc: Neil Brown, J. Bruce Fields, nfsv4, linux-kernel, linuxppc-dev
In-Reply-To: <1217860597.12535.2.camel@localhost>
Michael Ellerman <michael@ellerman.id.au> writes:
> On Mon, 2008-08-04 at 22:00 +1200, Paul Collins wrote:
>> Paul Collins <paul@burly.ondioline.org> writes:
>>
>> > Neil Brown <neilb@suse.de> writes:
>> >> Could you try removing the 'static' declaration for nfsd_acceptable
>> >> and recompile?
>> >> Or maybe try a different compiler?
>> >
>> > I will give these a try this evening.
>>
>> I built myself a nice new cross compiler:
>>
>> powerpc-linux-gnu-gcc-4.1 (GCC) 4.1.3 20080623 (prerelease) (Debian 4.1.2-23)
>>
>> and rebuilt 94ad374a0751f40d25e22e036c37f7263569d24c. Running that on
>> the server and 2.6.26 on the client, I got yet another Oops. This one
>> locked the machine up pretty good, so all I have is a picture:
>>
>> http://ondioline.org/~paul/DSCN1608.JPG
>
> Wow.
>
> Can you try building a kernel on the server? ie. not over NFS.
Built kernels on the server with native gcc 4.2.4 and 4.3.1 and repeated
the build test. Both of them threw an Oops with traces like the ones
we've seen before. Also, because now's about time to start shooting in
the dark, I tried a cross-built kernel with CC_OPTIMIZE_FOR_SIZE
disabled. That one Oopses too. Also I reseated the server's memory.
Although I've been able to build kernels over NFS with 2.6.26 on the
server, I've just realized I haven't tried to stress it much. I'll try
a build loop when the server's running 2.6.26 this evening.
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply
* Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
From: J. Bruce Fields @ 2008-08-04 20:59 UTC (permalink / raw)
To: Paul Collins; +Cc: Neil Brown, nfsv4, linux-kernel, linuxppc-dev
In-Reply-To: <87hca05ws4.fsf@burly.wgtn.ondioline.org>
On Tue, Aug 05, 2008 at 08:51:23AM +1200, Paul Collins wrote:
> Michael Ellerman <michael@ellerman.id.au> writes:
>
> > On Mon, 2008-08-04 at 22:00 +1200, Paul Collins wrote:
> >> Paul Collins <paul@burly.ondioline.org> writes:
> >>
> >> > Neil Brown <neilb@suse.de> writes:
> >> >> Could you try removing the 'static' declaration for nfsd_acceptable
> >> >> and recompile?
> >> >> Or maybe try a different compiler?
> >> >
> >> > I will give these a try this evening.
> >>
> >> I built myself a nice new cross compiler:
> >>
> >> powerpc-linux-gnu-gcc-4.1 (GCC) 4.1.3 20080623 (prerelease) (Debian 4.1.2-23)
> >>
> >> and rebuilt 94ad374a0751f40d25e22e036c37f7263569d24c. Running that on
> >> the server and 2.6.26 on the client, I got yet another Oops. This one
> >> locked the machine up pretty good, so all I have is a picture:
> >>
> >> http://ondioline.org/~paul/DSCN1608.JPG
> >
> > Wow.
> >
> > Can you try building a kernel on the server? ie. not over NFS.
>
> Built kernels on the server with native gcc 4.2.4 and 4.3.1 and repeated
> the build test.
But the build test itself was over nfs? (And you can't reproduce the
same problem without nfs?)
--b.
> Both of them threw an Oops with traces like the ones
> we've seen before. Also, because now's about time to start shooting in
> the dark, I tried a cross-built kernel with CC_OPTIMIZE_FOR_SIZE
> disabled. That one Oopses too. Also I reseated the server's memory.
>
> Although I've been able to build kernels over NFS with 2.6.26 on the
> server, I've just realized I haven't tried to stress it much. I'll try
> a build loop when the server's running 2.6.26 this evening.
>
> --
> Paul Collins
> Wellington, New Zealand
>
> Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply
* Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
From: Dave Hansen @ 2008-08-04 21:10 UTC (permalink / raw)
To: Mel Gorman
Cc: linux-mm, libhugetlbfs-devel, linux-kernel, linuxppc-dev, abh,
ebmunson, Andrew Morton
In-Reply-To: <20080731103137.GD1704@csn.ul.ie>
On Thu, 2008-07-31 at 11:31 +0100, Mel Gorman wrote:
> We are a lot more reliable than we were although exact quantification is
> difficult because it's workload dependent. For a long time, I've been able
> to test bits and pieces with hugepages by allocating the pool at the time
> I needed it even after days of uptime. Previously this required a reboot.
This is also a pretty big expansion of fs/hugetlb/ use outside of the
filesystem itself. It is hacking the existing shared memory
kernel-internal user to spit out effectively anonymous memory.
Where do we draw the line where we stop using the filesystem for this?
Other than the immediate code reuse, does it gain us anything?
I have to think that actually refactoring the filesystem code and making
it usable for really anonymous memory, then using *that* in these
patches would be a lot more sane. Especially for someone that goes to
look at it in a year. :)
-- Dave
^ permalink raw reply
* Re: Creating a wrapped zImage.initrd -- can't start the trampoline?
From: Grant Likely @ 2008-08-04 21:30 UTC (permalink / raw)
To: paul; +Cc: Linuxppc-embedded
In-Reply-To: <1217878996.29051.560.camel@psmith-ubeta.netezza.com>
On Mon, Aug 4, 2008 at 1:43 PM, Paul Smith <paul@mad-scientist.us> wrote:
> On Mon, 2008-08-04 at 11:25 -0600, Grant Likely wrote:
>> Take a look at Documentation/powerpc/bootwrapper.txt
>> You probably want the 'simpleImage.%' target. It also binds in a copy
>> of the device tree blob.
>
> Hm. I'm using 2.6.25.14 and I don't see any bootwrapper.txt file in
> Documentation/powerpc (or anywhere else). I also can't see any target
> simpleImage in any makefile. Is this something new in 2.6.26? :-(
>
> Any help for folks still using 2.6.25?
It's new in .26, but it is relevant for .25 also.
Here's a link to it:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/powerpc/bootwrapper.txt;h=d60fced5e1cc69169d9bbf1b49faacb41ef8db9c;hb=8f616cd5249e03c9e1b371623d85e76d4b86bbc1
> I think I need some basic instruction on how bootloaders etc. work, with
> a concentration on embedded PPC if possible. Anyone have any pointers
> that would be worth investigating?
The document above should help.
Documentation/powerpc/booting-without-of.txt has some useful
information also.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: PS3 early lock-up
From: Benjamin Herrenschmidt @ 2008-08-04 21:44 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux/PPC Development
In-Reply-To: <Pine.LNX.4.64.0808041640220.31424@vixen.sonytel.be>
On Mon, 2008-08-04 at 17:48 +0200, Geert Uytterhoeven wrote:
> On PS3, recent kernels lock up in the very early stage (i.e. before mere
> mortals get to see a working console). The kernel crashes with
>
> | kernel BUG at linux/arch/powerpc/platforms/ps3/htab.c:141!
>
> Bisecting shows this happens since:
>
> | commit a1f242ff460e4b50a045fa237c3c56cce9eabf83
> | Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> | Date: Wed Jul 23 21:27:08 2008 -0700
> |
> | powerpc ioremap_prot
> |
> | This adds ioremap_prot and pte_pgprot() so that one can extract protection
> | bits from a PTE and use them to ioremap_prot() (in order to support ptrace
> | of VM_IO | VM_PFNMAP as per Rik's patch).
> |
> | This moves a couple of flag checks around in the ioremap implementations
> | of arch/powerpc. There's a side effect of allowing non-cacheable and
> | non-guarded mappings on ppc32 which before would always have _PAGE_GUARDED
> | set whenever _PAGE_NO_CACHE is.
> |
> | (standard ioremap will still set _PAGE_GUARDED, but ioremap_prot will be
> | capable of setting such a non guarded mapping).
>
> Inside ps3_hpte_insert(), lv1_write_htab_entry() fails with error code 5
> (LV1_ACCESS_VIOLATION) when adding the PS3 hotplug memory.
>
> debug_dump_hpte() prints for the offending hpte:
>
> | pa = 500001000000h
> | lpar = 500001000000h
> | va = adc7d4c2d0000000h
> | group = 6168h
> | bitmap = 0h
> | hpte.v = adc7d4c2d011h
> | hpte.r = 500001000115h
> ^
> | psize = 0h
> | slot = 6168h
>
> After manually reverting the offending commit, the system boots again. The only
> change is:
>
> | pa = 500001000000h
> | lpar = 500001000000h
> | va = adc7d4c2d0000000h
> | group = 6168h
> | bitmap = 0h
> | hpte.v = adc7d4c2d011h
> | hpte.r = 500001000117h
> ^
> | psize = 0h
> | slot = 6168h
>
> Note that when adding the initial (non-hotplug) memory, hpte.r always ends in
> `194', both before and after reverting the offending commit.
>
> ps3_hpte_insert() seems to be called during system initialization with the
> following values of rflags:
> - first call: 0x190
> - initial memory: 0x194 (455 times)
> - hotplug memory:
> o crash: 0x115
> o OK: 0x117
>
> Do you have an idea of what's really going on?
Weird... Both look incorrect. In fact, it's a bit scary...
The one with the 7 at the end means that user space as RO access to
the segment (oops !) and supervisor too. The one with the 5 means
RO for user and RW for supervisor.
That is unless your HV is munging them in strange ways... I don't
know why LV1 is refusing a combination though.
As for the flags, it depends what htab_bolt_mapping() is called
with.
Do you have a backtrace ? I'm a bit lots in the mem hotswap code
trying to figure out where the mapping comes from..
Ben.
^ permalink raw reply
* Re: PS3 early lock-up
From: Benjamin Herrenschmidt @ 2008-08-04 21:52 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux/PPC Development
In-Reply-To: <1217886287.24157.87.camel@pasglop>
> > ps3_hpte_insert() seems to be called during system initialization with the
> > following values of rflags:
> > - first call: 0x190
> > - initial memory: 0x194 (455 times)
> > - hotplug memory:
> > o crash: 0x115
> > o OK: 0x117
> >
> > Do you have an idea of what's really going on?
>
> Weird... Both look incorrect. In fact, it's a bit scary...
>
> The one with the 7 at the end means that user space as RO access to
> the segment (oops !) and supervisor too. The one with the 5 means
> RO for user and RW for supervisor.
>
> That is unless your HV is munging them in strange ways... I don't
> know why LV1 is refusing a combination though.
>
> As for the flags, it depends what htab_bolt_mapping() is called
> with.
>
> Do you have a backtrace ? I'm a bit lots in the mem hotswap code
> trying to figure out where the mapping comes from..
Ah, found it... It should be ok... both the mapping of the RAM itself
and vmemmap_populate() should be passing
_PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
Which should be 0x194.
Can you find out where that stupid value comes from ?
Ben.
^ permalink raw reply
* Re: suffisant space for U-Boot, Linux and an initrd image ? (4MB SDRAM)
From: Wolfgang Denk @ 2008-08-04 22:59 UTC (permalink / raw)
To: Fabien Oriede; +Cc: linuxppc-embedded
In-Reply-To: <789365.58211.qm@web27401.mail.ukl.yahoo.com>
In message <789365.58211.qm@web27401.mail.ukl.yahoo.com> you wrote:
>
> I would like to know if this is possible to port U-Boot, Linux and an initrd image on a board with 4MB of SDRAM ?
In Theory it may be possible, but just for very tiny demo
applications. Probably not for a useful device.
> When Linux try to boot, there is this line on the terminal :
> "Memory : 2036k available (1036k kernel code, 256k data, 80k init, 0k highmem)"
> So I have 2036k memory available for my initrd image but I don't know if this is suffisant.
Note that a ramdisk is NOT an efficient way to use memory. See fro
example http://www.denx.de/wiki/view/DULG/RootFileSystemSelection
which shows that for example a cramfs image is not only faster to boot
but also needs less RAM.
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
Keep your head and your heart going in the right direction and you
will not have to worry about your feet.
^ permalink raw reply
* Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
From: Michael Ellerman @ 2008-08-05 0:16 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Neil Brown, linuxppc-dev, nfsv4, Paul Collins, linux-kernel
In-Reply-To: <20080804205908.GA29890@fieldses.org>
[-- Attachment #1: Type: text/plain, Size: 1774 bytes --]
On Mon, 2008-08-04 at 16:59 -0400, J. Bruce Fields wrote:
> On Tue, Aug 05, 2008 at 08:51:23AM +1200, Paul Collins wrote:
> > Michael Ellerman <michael@ellerman.id.au> writes:
> >
> > > On Mon, 2008-08-04 at 22:00 +1200, Paul Collins wrote:
> > >> Paul Collins <paul@burly.ondioline.org> writes:
> > >>
> > >> > Neil Brown <neilb@suse.de> writes:
> > >> >> Could you try removing the 'static' declaration for nfsd_acceptable
> > >> >> and recompile?
> > >> >> Or maybe try a different compiler?
> > >> >
> > >> > I will give these a try this evening.
> > >>
> > >> I built myself a nice new cross compiler:
> > >>
> > >> powerpc-linux-gnu-gcc-4.1 (GCC) 4.1.3 20080623 (prerelease) (Debian 4.1.2-23)
> > >>
> > >> and rebuilt 94ad374a0751f40d25e22e036c37f7263569d24c. Running that on
> > >> the server and 2.6.26 on the client, I got yet another Oops. This one
> > >> locked the machine up pretty good, so all I have is a picture:
> > >>
> > >> http://ondioline.org/~paul/DSCN1608.JPG
> > >
> > > Wow.
> > >
> > > Can you try building a kernel on the server? ie. not over NFS.
> >
> > Built kernels on the server with native gcc 4.2.4 and 4.3.1 and repeated
> > the build test.
>
> But the build test itself was over nfs? (And you can't reproduce the
> same problem without nfs?)
Yeah, I'm not clear on that either. What I was aiming at was can you get
it to oops somewhere else by not building over NFS - in which case we
can rule NFS (more or less) out.
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,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: PS3 early lock-up
From: Geoff Levand @ 2008-08-05 0:31 UTC (permalink / raw)
To: benh; +Cc: Geert Uytterhoeven, Linux/PPC Development
In-Reply-To: <1217886777.24157.91.camel@pasglop>
Hi,
Benjamin Herrenschmidt wrote:
>> > ps3_hpte_insert() seems to be called during system initialization with the
>> > following values of rflags:
>> > - first call: 0x190
>> > - initial memory: 0x194 (455 times)
>> > - hotplug memory:
>> > o crash: 0x115
>> > o OK: 0x117
>> >
>> > Do you have an idea of what's really going on?
>>
>> Weird... Both look incorrect. In fact, it's a bit scary...
>>
>> The one with the 7 at the end means that user space as RO access to
>> the segment (oops !) and supervisor too. The one with the 5 means
>> RO for user and RW for supervisor.
>>
>> That is unless your HV is munging them in strange ways... I don't
>> know why LV1 is refusing a combination though.
>>
>> As for the flags, it depends what htab_bolt_mapping() is called
>> with.
>>
>> Do you have a backtrace ? I'm a bit lots in the mem hotswap code
>> trying to figure out where the mapping comes from..
>
> Ah, found it... It should be ok... both the mapping of the RAM itself
> and vmemmap_populate() should be passing
>
> _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
>
> Which should be 0x194.
That is 0x190.
0x194 = _PAGE_EXEC | _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX
>
> Can you find out where that stupid value comes from ?
I didn't have time to look at in detail, but it fails from the
ioremap call in ps3_map_htab (arch/powerpc/platfroms/ps3/htab.c):
htab = (__force struct hash_pte *)ioremap_flags(htab_addr, htab_size,
pgprot_val(PAGE_READONLY_X));
IIRC, lv1 doesn't allow a read/write mapping of the htab, and that is
why I used pgprot_val(PAGE_READONLY_X) here.
I guess the value returned from pgprot_val(PAGE_READONLY_X)
changed in recent kernels, and that is what is causing the failure.
Just FYI, I put these in:
printk("%s:%d: flags = %x\n", __func__, __LINE__, (_PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX));
printk("%s:%d: flags = %x\n", __func__, __LINE__, pgprot_val(PAGE_READONLY_X));
and got this (and lv1_write_htab_entry failed):
ps3_map_htab:288: flags = 190
ps3_map_htab:289: flags = 117
-Geoff
^ permalink raw reply
* Re: [PATCH 1/3] powerpc - Initialize the irq radix tree earlier
From: Benjamin Herrenschmidt @ 2008-08-05 1:03 UTC (permalink / raw)
To: Sebastien Dugue
Cc: tinytim, linux-rt-users, linux-kernel, rostedt, jean-pierre.dion,
linuxppc-dev, paulus, gilles.carry, tglx
In-Reply-To: <1217848124-3719-2-git-send-email-sebastien.dugue@bull.net>
On Mon, 2008-08-04 at 13:08 +0200, Sebastien Dugue wrote:
> The radix tree used for fast irq reverse mapping by the XICS is initialized
> late in the boot process, after the first interrupt (IPI) gets registered
> and after the first IPI is received.
>
> This patch moves the initialization of the XICS radix tree earlier into
> the boot process in smp_xics_probe() (the mm is already up but no interrupts
> have been registered at that point) to avoid having to insert a mapping into
> the tree in interrupt context. This will help in simplifying the locking
> constraints and move to a lockless radix tree in subsequent patches.
I'm not too happy with the moving of the radix tree init to platform
code.
The fact that the revmap code uses a radix tree should be mostly
transparent to the XICS code. I don't like adding this explicit code
from xics to initialize it.
I think the tree should still be initialized from generic code and it
can be done as late as we want as interrupts work without the tree being
there, they are just a bit slower.
I believe the right approach is:
- Remove the populating of the tree from the revmap function as
you already do
- Move it to irq_create_mapping() for the normal case
- For pre-existing interrupt, have the generic code that initializes
the radix tree walk through all interrupts and setup the revmap for
them. If that needs locking vs. concurrent irq_create_mapping, it's
easy to use one of the available spinlocks for that.
Cheers,
Ben.
> Signed-off-by: Sebastien Dugue <sebastien.dugue@bull.net>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Michael Ellerman <michael@ellerman.id.au>
> ---
> arch/powerpc/kernel/irq.c | 17 -----------------
> arch/powerpc/platforms/pseries/smp.c | 1 +
> arch/powerpc/platforms/pseries/xics.c | 5 +++++
> arch/powerpc/platforms/pseries/xics.h | 1 +
> 4 files changed, 7 insertions(+), 17 deletions(-)
>
> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> index d972dec..9bef9f3 100644
> --- a/arch/powerpc/kernel/irq.c
> +++ b/arch/powerpc/kernel/irq.c
> @@ -1016,23 +1016,6 @@ void irq_early_init(void)
> get_irq_desc(i)->status |= IRQ_NOREQUEST;
> }
>
> -/* We need to create the radix trees late */
> -static int irq_late_init(void)
> -{
> - struct irq_host *h;
> - unsigned long flags;
> -
> - irq_radix_wrlock(&flags);
> - list_for_each_entry(h, &irq_hosts, link) {
> - if (h->revmap_type == IRQ_HOST_MAP_TREE)
> - INIT_RADIX_TREE(&h->revmap_data.tree, GFP_ATOMIC);
> - }
> - irq_radix_wrunlock(flags);
> -
> - return 0;
> -}
> -arch_initcall(irq_late_init);
> -
> #ifdef CONFIG_VIRQ_DEBUG
> static int virq_debug_show(struct seq_file *m, void *private)
> {
> diff --git a/arch/powerpc/platforms/pseries/smp.c b/arch/powerpc/platforms/pseries/smp.c
> index 9d8f8c8..3d4429a 100644
> --- a/arch/powerpc/platforms/pseries/smp.c
> +++ b/arch/powerpc/platforms/pseries/smp.c
> @@ -130,6 +130,7 @@ static void smp_xics_message_pass(int target, int msg)
>
> static int __init smp_xics_probe(void)
> {
> + xics_radix_revmap_init();
> xics_request_IPIs();
>
> return cpus_weight(cpu_possible_map);
> diff --git a/arch/powerpc/platforms/pseries/xics.c b/arch/powerpc/platforms/pseries/xics.c
> index 0fc830f..d6e28f9 100644
> --- a/arch/powerpc/platforms/pseries/xics.c
> +++ b/arch/powerpc/platforms/pseries/xics.c
> @@ -556,6 +556,11 @@ static struct irq_host_ops xics_host_ops = {
> .xlate = xics_host_xlate,
> };
>
> +void __init xics_radix_revmap_init(void)
> +{
> + INIT_RADIX_TREE(&xics_host->revmap_data.tree, GFP_ATOMIC);
> +}
> +
> static void __init xics_init_host(void)
> {
> if (firmware_has_feature(FW_FEATURE_LPAR))
> diff --git a/arch/powerpc/platforms/pseries/xics.h b/arch/powerpc/platforms/pseries/xics.h
> index 1c5321a..11490be 100644
> --- a/arch/powerpc/platforms/pseries/xics.h
> +++ b/arch/powerpc/platforms/pseries/xics.h
> @@ -19,6 +19,7 @@ extern void xics_setup_cpu(void);
> extern void xics_teardown_cpu(void);
> extern void xics_kexec_teardown_cpu(int secondary);
> extern void xics_cause_IPI(int cpu);
> +extern void xics_radix_revmap_init(void);
> extern void xics_request_IPIs(void);
> extern void xics_migrate_irqs_away(void);
>
^ permalink raw reply
* Re: [PATCH 1/3] powerpc - Initialize the irq radix tree earlier
From: Benjamin Herrenschmidt @ 2008-08-05 1:05 UTC (permalink / raw)
To: Sebastien Dugue
Cc: tinytim, linux-rt-users, linux-kernel, rostedt, jean-pierre.dion,
linuxppc-dev, paulus, gilles.carry, tglx
In-Reply-To: <1217898226.24157.120.camel@pasglop>
> - Remove the populating of the tree from the revmap function as
> you already do
> - Move it to irq_create_mapping() for the normal case
> - For pre-existing interrupt, have the generic code that initializes
> the radix tree walk through all interrupts and setup the revmap for
> them. If that needs locking vs. concurrent irq_create_mapping, it's
> easy to use one of the available spinlocks for that.
And in fact, you may even be able to avoid GFP_ATOMIC completely here
and switch it to GFP_KERNEL since irq_create_mapping() can sleep afaik,
provided that you avoid the spinlocking.
Ben.
^ permalink raw reply
* Re: PS3 early lock-up
From: Benjamin Herrenschmidt @ 2008-08-05 1:40 UTC (permalink / raw)
To: Geoff Levand; +Cc: Geert Uytterhoeven, Linux/PPC Development
In-Reply-To: <48979F6F.1050507@am.sony.com>
> > Which should be 0x194.
>
> That is 0x190.
>
> 0x194 = _PAGE_EXEC | _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX
Right, _PAGE_EXEC should only be set for the part covering the kernel
text. In any case, it shouldn't be what you showed.
> > Can you find out where that stupid value comes from ?
>
> I didn't have time to look at in detail, but it fails from the
> ioremap call in ps3_map_htab (arch/powerpc/platfroms/ps3/htab.c):
>
> htab = (__force struct hash_pte *)ioremap_flags(htab_addr, htab_size,
> pgprot_val(PAGE_READONLY_X));
>
> IIRC, lv1 doesn't allow a read/write mapping of the htab, and that is
> why I used pgprot_val(PAGE_READONLY_X) here.
Why are you mapping it in the first place btw ? Do you actually use that
mapping ?
> I guess the value returned from pgprot_val(PAGE_READONLY_X)
> changed in recent kernels, and that is what is causing the failure.
Ok, there's definitely something fishy about passing the PP bits down
to ioremap. The reason it fails is that I no longer let _PAGE_USER
go down to the mapping. However, ioremap passes those bits as-is
to the hash insert code, it should instead perform the same munging
as the asm hashing code does, to turn that into a supervisor only
mapping.
However, there is a deeper issue with what you are doing. With using
only 2 PP bits, as is the case with linux, you -cannot- have a supervisor
read-only mapping that isn't also readable by userspace. It's possible
the newer 3 PPP bits encoding, but I don't know if Cell supports it and
linux currently doesn't use it.
That means that currently, your hash table is user readable... oops :-)
(This is a bug with other early IO mappings too btw, I'll have
to fix that).
However, it appears to me that you don't use the mapping of the hash
table anyway. So just remove the ioremap :-) I'll look at fixing
the attribute parsing for ioremap_prot() in the long run though.
Ben.
> Just FYI, I put these in:
>
> printk("%s:%d: flags = %x\n", __func__, __LINE__, (_PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX));
> printk("%s:%d: flags = %x\n", __func__, __LINE__, pgprot_val(PAGE_READONLY_X));
>
> and got this (and lv1_write_htab_entry failed):
>
> ps3_map_htab:288: flags = 190
> ps3_map_htab:289: flags = 117
>
> -Geoff
>
>
^ permalink raw reply
* 2.6.27 fixes for 4xx tree
From: Josh Boyer @ 2008-08-05 1:47 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
Hi All,
If you have fixes for 4xx that you want to get in the .27 kernel, please
let me know soon. I have the following queued up:
Sean MacLennan (3):
powerpc/4xx: Cleanup Warp for i2c driver changes.
powerpc/44x: Warp DTS changes for board updates
powerpc/44x: Incorrect NOR offset in Warp DTS
Valentine Barshak (1):
powerpc/44x: Adjust warp-nand resource end address
I'll also be updating all the defconfigs for 4xx in the next day or so.
Then I'll ask Paul to pull.
josh
^ permalink raw reply
* Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
From: Paul Collins @ 2008-08-05 3:43 UTC (permalink / raw)
To: michael; +Cc: J. Bruce Fields, Neil Brown, nfsv4, linux-kernel, linuxppc-dev
In-Reply-To: <1217895418.7951.7.camel@localhost>
Michael Ellerman <michael@ellerman.id.au> writes:
> On Mon, 2008-08-04 at 16:59 -0400, J. Bruce Fields wrote:
>> On Tue, Aug 05, 2008 at 08:51:23AM +1200, Paul Collins wrote:
>> > Michael Ellerman <michael@ellerman.id.au> writes:
>> >
>> > > On Mon, 2008-08-04 at 22:00 +1200, Paul Collins wrote:
>> > >> Paul Collins <paul@burly.ondioline.org> writes:
>> > >>
>> > >> > Neil Brown <neilb@suse.de> writes:
>> > >> >> Could you try removing the 'static' declaration for nfsd_acceptable
>> > >> >> and recompile?
>> > >> >> Or maybe try a different compiler?
>> > >> >
>> > >> > I will give these a try this evening.
>> > >>
>> > >> I built myself a nice new cross compiler:
>> > >>
>> > >> powerpc-linux-gnu-gcc-4.1 (GCC) 4.1.3 20080623 (prerelease) (Debian 4.1.2-23)
>> > >>
>> > >> and rebuilt 94ad374a0751f40d25e22e036c37f7263569d24c. Running that on
>> > >> the server and 2.6.26 on the client, I got yet another Oops. This one
>> > >> locked the machine up pretty good, so all I have is a picture:
>> > >>
>> > >> http://ondioline.org/~paul/DSCN1608.JPG
>> > >
>> > > Wow.
>> > >
>> > > Can you try building a kernel on the server? ie. not over NFS.
>> >
>> > Built kernels on the server with native gcc 4.2.4 and 4.3.1 and repeated
>> > the build test.
>>
>> But the build test itself was over nfs? (And you can't reproduce the
>> same problem without nfs?)
>
> Yeah, I'm not clear on that either. What I was aiming at was can you get
> it to oops somewhere else by not building over NFS - in which case we
> can rule NFS (more or less) out.
I think may be able to rule NFS out now. I just got this Oops when Xorg
started on boot.
Unable to handle kernel paging request for data at address 0x00000949
Faulting instruction address: 0xc0104190
Oops: Kernel access of bad area, sig: 11 [#1]
PowerMac
Modules linked in: snd_aoa_codec_tas snd_aoa_fabric_layout b43 snd_aoa mac80211 cfg80211 pcmcia snd_aoa_i2sbus snd_pcm_oss snd_pcm snd_page_alloc snd_aoa_soundbus yenta_socket rsrc_nonstatic pcmcia_core ssb uninorth_agp agpgart ehci_hcd ohci_hcd
NIP: c0104190 LR: c0104138 CTR: c01fbd8c
REGS: eee89c40 TRAP: 0300 Not tainted (2.6.27-rc1-00158-g643fbd8)
MSR: 00009032 <EE,ME,IR,DR> CR: 88088222 XER: 20000000
DAR: 00000949, DSISR: 42000000
TASK = c1ebb840[2528] 'Xorg' THREAD: eee88000
GPR00: c0104138 eee89cf0 c1ebb840 00000901 ef507d20 00000007 c0620000 c061ca30
GPR08: ef507d08 c05ae45c 9e370001 eee89cf0 28002248 101f3ca4 101ee800 101ebf1c
GPR16: eee89e2c fffffff4 c05d0000 eee89d60 ffffffd8 eee89d68 101ebf20 ef4ebab4
GPR24: c00d0148 00000000 28088222 ef4eba40 00000901 f0000627 ef3ee5e0 eee89cf0
NIP [c0104190] proc_lookup_de+0xe0/0xf8
LR [c0104138] proc_lookup_de+0x88/0xf8
Call Trace:
[eee89cf0] [c0104138] proc_lookup_de+0x88/0xf8 (unreliable)
[eee89d10] [c010467c] proc_lookup+0x34/0x4c
[eee89d20] [c00c034c] do_lookup+0x1a4/0x220
[eee89d50] [c00c2010] __link_path_walk+0x18c/0xdd4
[eee89dc0] [c00c2cb0] path_walk+0x58/0xe0
[eee89df0] [c00c2e68] do_path_lookup+0x78/0x17c
[eee89e20] [c00c3b58] user_path_at+0x64/0xa4
[eee89e90] [c00baa64] vfs_stat_fd+0x34/0x74
[eee89ec0] [c00bac2c] vfs_stat+0x30/0x48
[eee89ed0] [c00bac74] sys_stat64+0x30/0x5c
[eee89f40] [c0013aa8] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xfc4a300
LR = 0xfc4a2b8
Instruction dump:
4e800020 3860fffe 81610000 800b0004 bb6bffec 7d615b78 7c0803a6 4e800020
3d20c05b 7c641b78 3929e45c 7f83e378 <913c0048> 4bfc98bd 7f83e378 4bfc7dcd
---[ end trace 9be805d8b3000d04 ]---
And earlier today I got these three Oopses when I did "du -sh *" in my
homedir:
Oops: Exception in kernel mode, sig: 4 [#1]
PowerMac
Modules linked in: option radeon drm snd_aoa_codec_tas snd_aoa_fabric_layout b43 mac80211 snd_aoa cfg80211 pcmcia snd_aoa_i2sbus snd_pcm_oss snd_pcm snd_page_alloc snd_aoa_soundbus yenta_socket rsrc_nonstatic pcmcia_core ssb uninorth_agp agpgart ehci_hcd ohci_hcd
NIP: c00d01b4 LR: c00d0148 CTR: c01fbd8c
REGS: ec42bbf0 TRAP: 0700 Not tainted (2.6.27-rc1-00158-g643fbd8)
MSR: 00089032 <EE,ME,IR,DR> CR: 24088428 XER: 00000000
TASK = c1c837e0[3610] 'du' THREAD: ec42a000
GPR00: eee15e7c ec42bca0 c1c837e0 00000000 c0f1d4fc 002de7e6 ef306bb0 e9d3d104
GPR08: c0650000 e9d3fe84 e9d3fe7c c05d0000 24088422 10029cb8 10010a8c 10010f5c
GPR16: ec42be3c fffffff4 c05d0000 ec42bd70 ffffffd8 ec42bd78 1000f940 ee0c5338
GPR24: e9d3fe74 c0f0ae20 000126dc c0f1d4fc eee15e00 00000000 002de7e6 ec42bca0
NIP [c00d01b4] iget_locked+0xfc/0x148
LR [c00d0148] iget_locked+0x90/0x148
Call Trace:
[ec42bca0] [c00d0148] iget_locked+0x90/0x148 (unreliable)
[ec42bcd0] [c011cd60] ext3_iget+0x24/0x53c
[ec42bd00] [c0120dbc] ext3_lookup+0x108/0x144
[ec42bd30] [c00c034c] do_lookup+0x1a4/0x220
[ec42bd60] [c00c22ac] __link_path_walk+0x428/0xdd4
[ec42bdd0] [c00c2cb0] path_walk+0x58/0xe0
[ec42be00] [c00c2e68] do_path_lookup+0x78/0x17c
[ec42be30] [c00c3b58] user_path_at+0x64/0xa4
[ec42bea0] [c00ba884] vfs_lstat_fd+0x34/0x74
[ec42bed0] [c00bab2c] sys_fstatat64+0x88/0x90
[ec42bf40] [c0013aa8] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff4fc1c
LR = 0xff4fbb0
Instruction dump:
93d80020 3d00c065 3d60c05d 39580008 381c007c 812842d0 80ebd00c 39290001
912842d0 39380010 90f80008 914bd00b <00000000> 91470004 916a0004 811c007c
---[ end trace 63d4f9f1d8c7a13d ]---
Oops: Exception in kernel mode, sig: 4 [#2]
PowerMac
Modules linked in: option radeon drm snd_aoa_codec_tas snd_aoa_fabric_layout b43 mac80211 snd_aoa cfg80211 pcmcia snd_aoa_i2sbus snd_pcm_oss snd_pcm snd_page_alloc snd_aoa_soundbus yenta_socket rsrc_nonstatic pcmcia_core ssb uninorth_agp agpgart ehci_hcd ohci_hcd
NIP: c00d01b4 LR: c00d0148 CTR: c01fbd8c
REGS: ee7b7bb0 TRAP: 0700 Tainted: G D (2.6.27-rc1-00158-g643fbd8)
MSR: 00089032 <EE,ME,IR,DR> CR: 28888482 XER: 00000000
TASK = eef1a090[2587] 'emacs' THREAD: ee7b6000
GPR00: ef80e67c ee7b7c60 eef1a090 00000000 c0f13738 f0000000 c0620000 ef616884
GPR08: c0650000 ebdf6b90 ebdf6b88 c05d0000 28888482 102e8e60 102e2180 102e0000
GPR16: ee7b7e5c fffffff4 c05d0000 ee7b7d40 ffffffd8 ee7b7d48 1033a630 ef403e94
GPR24: ebdf6b80 c0f0ae20 00008918 c0f13738 ef80e600 00000000 f0000000 ee7b7c60
NIP [c00d01b4] iget_locked+0xfc/0x148
LR [c00d0148] iget_locked+0x90/0x148
Call Trace:
[ee7b7c60] [c00d0148] iget_locked+0x90/0x148 (unreliable)
[ee7b7c90] [c00fd314] proc_get_inode+0x34/0x188
[ee7b7cb0] [c0104138] proc_lookup_de+0x88/0xf8
[ee7b7cd0] [c010467c] proc_lookup+0x34/0x4c
[ee7b7ce0] [c00fdf10] proc_root_lookup+0x30/0x64
[ee7b7d00] [c00c034c] do_lookup+0x1a4/0x220
[ee7b7d30] [c00c22ac] __link_path_walk+0x428/0xdd4
[ee7b7da0] [c00c2cb0] path_walk+0x58/0xe0
[ee7b7dd0] [c00c2e68] do_path_lookup+0x78/0x17c
[ee7b7e00] [c00c3db4] __path_lookup_intent_open+0x68/0xdc
[ee7b7e30] [c00c3e50] path_lookup_open+0x28/0x40
[ee7b7e40] [c00c40b0] do_filp_open+0xa4/0x7cc
[ee7b7f00] [c00b30d4] do_sys_open+0x6c/0x108
[ee7b7f30] [c00b31e4] sys_open+0x38/0x50
[ee7b7f40] [c0013aa8] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xf1d8560
LR = 0xf1ea534
Instruction dump:
93d80020 3d00c065 3d60c05d 39580008 381c007c 812842d0 80ebd00c 39290001
912842d0 39380010 90f80008 914bd00b <00000000> 91470004 916a0004 811c007c
---[ end trace 63d4f9f1d8c7a13d ]---
Oops: Exception in kernel mode, sig: 4 [#3]
PowerMac
Modules linked in: option radeon drm snd_aoa_codec_tas snd_aoa_fabric_layout b43 mac80211 snd_aoa cfg80211 pcmcia snd_aoa_i2sbus snd_pcm_oss snd_pcm snd_page_alloc snd_aoa_soundbus yenta_socket rsrc_nonstatic pcmcia_core ssb uninorth_agp agpgart ehci_hcd ohci_hcd
NIP: c00d01b4 LR: c00d0148 CTR: c01fbd8c
REGS: ee7b1be0 TRAP: 0700 Tainted: G D (2.6.27-rc1-00158-g643fbd8)
MSR: 00089032 <EE,ME,IR,DR> CR: 22288428 XER: 00000000
TASK = ee7307e0[2574] 'bash' THREAD: ee7b0000
GPR00: eee15e7c ee7b1c90 ee7307e0 00000000 c0f43e10 0037e752 ef306bb0 ef548e9c
GPR08: c0650000 e9d3f12c e9d3f124 c05d0000 22288422 100e5894 100e0000 100df49c
GPR16: ee7b1e2c fffffff4 c05d0000 ee7b1d60 ffffffd8 ee7b1d68 100dde04 ef4f7748
GPR24: e9d3f11c c0f0ae20 00038ff0 c0f43e10 eee15e00 00000000 0037e752 ee7b1c90
NIP [c00d01b4] iget_locked+0xfc/0x148
LR [c00d0148] iget_locked+0x90/0x148
Call Trace:
[ee7b1c90] [c00d0148] iget_locked+0x90/0x148 (unreliable)
[ee7b1cc0] [c011cd60] ext3_iget+0x24/0x53c
[ee7b1cf0] [c0120dbc] ext3_lookup+0x108/0x144
[ee7b1d20] [c00c034c] do_lookup+0x1a4/0x220
[ee7b1d50] [c00c22ac] __link_path_walk+0x428/0xdd4
[ee7b1dc0] [c00c2cb0] path_walk+0x58/0xe0
[ee7b1df0] [c00c2e68] do_path_lookup+0x78/0x17c
[ee7b1e20] [c00c3b58] user_path_at+0x64/0xa4
[ee7b1e90] [c00baa64] vfs_stat_fd+0x34/0x74
[ee7b1ec0] [c00bac2c] vfs_stat+0x30/0x48
[ee7b1ed0] [c00bac74] sys_stat64+0x30/0x5c
[ee7b1f40] [c0013aa8] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xfece5e0
LR = 0x100671fc
Instruction dump:
93d80020 3d00c065 3d60c05d 39580008 381c007c 812842d0 80ebd00c 39290001
912842d0 39380010 90f80008 914bd00b <00000000> 91470004 916a0004 811c007c
---[ end trace 63d4f9f1d8c7a13d ]---
And then all my other windows started disappearing, so I figured it was
time to reboot.
In case anyone wants to disassemble it, I've uploaded the kernel to
http://ondioline.org/~paul/vmlinux-2.6.27-rc1-00158-g643fbd8 and the
config to http://ondioline.org/~paul/config-2.6.27-rc1-00158-g643fbd8
I've rebuilt a whole bunch of times in the course of this little
project, but the all four Oopses in this message are from the very
vmlinux linked above.
I have a couple of patches applied locally (a console font and a
Bluetooth HID quirk), so this is really Linus revision
94ad374a0751f40d25e22e036c37f7263569d24c.
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply
* Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
From: Michael Ellerman @ 2008-08-05 4:34 UTC (permalink / raw)
To: Paul Collins
Cc: J. Bruce Fields, Neil Brown, nfsv4, linux-kernel, linuxppc-dev
In-Reply-To: <8763qg5don.fsf@burly.wgtn.ondioline.org>
[-- Attachment #1: Type: text/plain, Size: 3183 bytes --]
On Tue, 2008-08-05 at 15:43 +1200, Paul Collins wrote:
> Michael Ellerman <michael@ellerman.id.au> writes:
>
> > On Mon, 2008-08-04 at 16:59 -0400, J. Bruce Fields wrote:
> >> On Tue, Aug 05, 2008 at 08:51:23AM +1200, Paul Collins wrote:
> >> > Michael Ellerman <michael@ellerman.id.au> writes:
> >> >
> >> > > On Mon, 2008-08-04 at 22:00 +1200, Paul Collins wrote:
> >> > >> Paul Collins <paul@burly.ondioline.org> writes:
> >> > >>
> >> > >> > Neil Brown <neilb@suse.de> writes:
> >> > >> >> Could you try removing the 'static' declaration for nfsd_acceptable
> >> > >> >> and recompile?
> >> > >> >> Or maybe try a different compiler?
> >> > >> >
> >> > >> > I will give these a try this evening.
> >> > >>
> >> > >> I built myself a nice new cross compiler:
> >> > >>
> >> > >> powerpc-linux-gnu-gcc-4.1 (GCC) 4.1.3 20080623 (prerelease) (Debian 4.1.2-23)
> >> > >>
> >> > >> and rebuilt 94ad374a0751f40d25e22e036c37f7263569d24c. Running that on
> >> > >> the server and 2.6.26 on the client, I got yet another Oops. This one
> >> > >> locked the machine up pretty good, so all I have is a picture:
> >> > >>
> >> > >> http://ondioline.org/~paul/DSCN1608.JPG
> >> > >
> >> > > Wow.
> >> > >
> >> > > Can you try building a kernel on the server? ie. not over NFS.
> >> >
> >> > Built kernels on the server with native gcc 4.2.4 and 4.3.1 and repeated
> >> > the build test.
> >>
> >> But the build test itself was over nfs? (And you can't reproduce the
> >> same problem without nfs?)
> >
> > Yeah, I'm not clear on that either. What I was aiming at was can you get
> > it to oops somewhere else by not building over NFS - in which case we
> > can rule NFS (more or less) out.
>
> I think may be able to rule NFS out now. I just got this Oops when Xorg
> started on boot.
Cool, that looks fairly convincing.
> In case anyone wants to disassemble it, I've uploaded the kernel to
> http://ondioline.org/~paul/vmlinux-2.6.27-rc1-00158-g643fbd8 and the
> config to http://ondioline.org/~paul/config-2.6.27-rc1-00158-g643fbd8
>
> I've rebuilt a whole bunch of times in the course of this little
> project, but the all four Oopses in this message are from the very
> vmlinux linked above.
>
> I have a couple of patches applied locally (a console font and a
> Bluetooth HID quirk), so this is really Linus revision
> 94ad374a0751f40d25e22e036c37f7263569d24c.
And you're _sure_ none of them has a "break-everything" hunk in it? :)
I see you have FTRACE enabled. That's new and could potentially bugger
things up without the compiler knowing, so can you turn that off.
And can you enable CONFIG_CODE_PATCHING_SELFTEST and
CONFIG_FTR_FIXUP_SELFTEST, that will enable tests of some code I changed
that /could/ (maybe) cause random blow ups.
Also, how old is the machine? Any chance you're just seeing random
memory corruption?
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,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
From: Paul Collins @ 2008-08-05 4:47 UTC (permalink / raw)
To: michael; +Cc: J. Bruce Fields, Neil Brown, nfsv4, linux-kernel, linuxppc-dev
In-Reply-To: <1217910862.7951.22.camel@localhost>
Michael Ellerman <michael@ellerman.id.au> writes:
> On Tue, 2008-08-05 at 15:43 +1200, Paul Collins wrote:
>> Michael Ellerman <michael@ellerman.id.au> writes:
>> I think may be able to rule NFS out now. I just got this Oops when Xorg
>> started on boot.
>
> Cool, that looks fairly convincing.
>
>> In case anyone wants to disassemble it, I've uploaded the kernel to
>> http://ondioline.org/~paul/vmlinux-2.6.27-rc1-00158-g643fbd8 and the
>> config to http://ondioline.org/~paul/config-2.6.27-rc1-00158-g643fbd8
>>
>> I've rebuilt a whole bunch of times in the course of this little
>> project, but the all four Oopses in this message are from the very
>> vmlinux linked above.
>>
>> I have a couple of patches applied locally (a console font and a
>> Bluetooth HID quirk), so this is really Linus revision
>> 94ad374a0751f40d25e22e036c37f7263569d24c.
>
> And you're _sure_ none of them has a "break-everything" hunk in it? :)
Pretty sure! Here's a diffstat:
$ git diff --stat HEAD^^..
drivers/video/console/Kconfig | 12 +
drivers/video/console/Makefile | 2 +
drivers/video/console/font_neepalt10x20.c | 5392 ++++++++++++++++++++++++
drivers/video/console/font_neepalt12x24.c | 6416 +++++++++++++++++++++++++++++
drivers/video/console/fonts.c | 8 +
include/linux/font.h | 6 +-
net/bluetooth/hidp/core.c | 6 +
7 files changed, 11841 insertions(+), 1 deletions(-)
> I see you have FTRACE enabled. That's new and could potentially bugger
> things up without the compiler knowing, so can you turn that off.
>
> And can you enable CONFIG_CODE_PATCHING_SELFTEST and
> CONFIG_FTR_FIXUP_SELFTEST, that will enable tests of some code I changed
> that /could/ (maybe) cause random blow ups.
I'll try these out.
> Also, how old is the machine? Any chance you're just seeing random
> memory corruption?
It's about four years old. It was in storage for about six months and I
got it repaired a few weeks ago (display cable and inverter). The sort
of crazy crap I've been reporting certainly smacks of memory corruption.
But on the other hand, 2.6.25 (Debian's) and 2.6.26 (my own) have been
trouble-free.
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Sean MacLennan @ 2008-08-05 6:12 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18582.35404.120586.238398@drongo.ozlabs.ibm.com>
On Mon, 4 Aug 2008 14:49:16 +1000
"Paul Mackerras" <paulus@samba.org> wrote:
> Linus,
>
> Please pull from the 'merge' branch of
>
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
>
> The main thing there is that we have moved the powerpc include files
> from include/asm-powerpc to arch/powerpc/include/asm. There is also a
> commit from Kumar Gala that removes code that was only referenced when
> compiling with ARCH=ppc, and is now dead since arch/ppc is gone, plus
> a couple of warning fixes from Tony Breeds.
What is the "correct" way to include these files? I have a driver
that needs to access get_tbl() which is defined in time.h.
Do I put:
#include <arch/powerpc/include/asm/time.h>
in the source file?
Cheers,
Sean
^ permalink raw reply
* [PATCH] powerpc/mm: Fix attribute confusion with htab_bolt_mapping()
From: Benjamin Herrenschmidt @ 2008-08-05 6:19 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
The function htab_bolt_mapping() is used to create permanent
mappings in the MMU hash table, for example, in order to create
the linear mapping of vmemmap. It's also used by early boot
ioremap (before mem_init_done).
However, the way ioremap uses it is incorrect as it passes it
the protection flags in the "linux PTE" form while htab_bolt_mapping()
expects them in the hash table format. This is made more confusing
by the fact that some of those flags are actually in the same
position in both cases.
This patch fixes it all by making htab_bolt_mapping() take normal
linux protection flags instead, and use a little helper to convert
them to htab flags. Callers can now use the usual PAGE_* definitions
safely.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
arch/powerpc/include/asm/mmu-hash64.h | 2 -
arch/powerpc/mm/hash_utils_64.c | 65 ++++++++++++++++++++--------------
arch/powerpc/mm/init_64.c | 9 +---
3 files changed, 44 insertions(+), 32 deletions(-)
--- linux-work.orig/arch/powerpc/mm/hash_utils_64.c 2008-08-05 15:15:06.000000000 +1000
+++ linux-work/arch/powerpc/mm/hash_utils_64.c 2008-08-05 16:09:47.000000000 +1000
@@ -18,7 +18,7 @@
* 2 of the License, or (at your option) any later version.
*/
-#undef DEBUG
+#define DEBUG
#undef DEBUG_LOW
#include <linux/spinlock.h>
@@ -151,39 +151,53 @@ static struct mmu_psize_def mmu_psize_de
},
};
+static unsigned long htab_convert_pte_flags(unsigned long pteflags)
+{
+ unsigned long rflags = pteflags & 0x1fa;
+
+ /* _PAGE_EXEC -> NOEXEC */
+ if ((pteflags & _PAGE_EXEC) == 0)
+ rflags |= HPTE_R_N;
+
+ /* PP bits. PAGE_USER is already PP bit 0x2, so we only
+ * need to add in 0x1 if it's a read-only user page
+ */
+ if ((pteflags & _PAGE_USER) && !((pteflags & _PAGE_RW) &&
+ (pteflags & _PAGE_DIRTY)))
+ rflags |= 1;
+
+ /* Always add C */
+ return rflags | HPTE_R_C;
+}
int htab_bolt_mapping(unsigned long vstart, unsigned long vend,
- unsigned long pstart, unsigned long mode,
+ unsigned long pstart, unsigned long prot,
int psize, int ssize)
{
unsigned long vaddr, paddr;
unsigned int step, shift;
- unsigned long tmp_mode;
int ret = 0;
shift = mmu_psize_defs[psize].shift;
step = 1 << shift;
+ prot = htab_convert_pte_flags(prot);
+
+ DBG("htab_bolt_mapping(%lx..%lx -> %lx (%lx,%d,%d)\n",
+ vstart, vend, pstart, prot, psize, ssize);
+
for (vaddr = vstart, paddr = pstart; vaddr < vend;
vaddr += step, paddr += step) {
unsigned long hash, hpteg;
unsigned long vsid = get_kernel_vsid(vaddr, ssize);
unsigned long va = hpt_va(vaddr, vsid, ssize);
- tmp_mode = mode;
-
- /* Make non-kernel text non-executable */
- if (!in_kernel_text(vaddr))
- tmp_mode = mode | HPTE_R_N;
-
hash = hpt_hash(va, shift, ssize);
hpteg = ((hash & htab_hash_mask) * HPTES_PER_GROUP);
- DBG("htab_bolt_mapping: calling %p\n", ppc_md.hpte_insert);
-
BUG_ON(!ppc_md.hpte_insert);
- ret = ppc_md.hpte_insert(hpteg, va, paddr,
- tmp_mode, HPTE_V_BOLTED, psize, ssize);
+ ret = ppc_md.hpte_insert(hpteg, va, paddr, prot,
+ HPTE_V_BOLTED, psize, ssize);
if (ret < 0)
break;
@@ -519,9 +533,9 @@ static unsigned long __init htab_get_tab
#ifdef CONFIG_MEMORY_HOTPLUG
void create_section_mapping(unsigned long start, unsigned long end)
{
- BUG_ON(htab_bolt_mapping(start, end, __pa(start),
- _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX,
- mmu_linear_psize, mmu_kernel_ssize));
+ BUG_ON(htab_bolt_mapping(start, end, __pa(start),
+ PAGE_KERNEL, mmu_linear_psize,
+ mmu_kernel_ssize));
}
int remove_section_mapping(unsigned long start, unsigned long end)
@@ -570,7 +584,7 @@ void __init htab_initialize(void)
{
unsigned long table;
unsigned long pteg_count;
- unsigned long mode_rw;
+ unsigned long prot, tprot;
unsigned long base = 0, size = 0, limit;
int i;
@@ -628,7 +642,7 @@ void __init htab_initialize(void)
mtspr(SPRN_SDR1, _SDR1);
}
- mode_rw = _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
+ prot = PAGE_KERNEL;
#ifdef CONFIG_DEBUG_PAGEALLOC
linear_map_hash_count = lmb_end_of_DRAM() >> PAGE_SHIFT;
@@ -646,8 +660,10 @@ void __init htab_initialize(void)
for (i=0; i < lmb.memory.cnt; i++) {
base = (unsigned long)__va(lmb.memory.region[i].base);
size = lmb.memory.region[i].size;
+ tprot = prot | (in_kernel_text(base) ? _PAGE_EXEC : 0);
- DBG("creating mapping for region: %lx : %lx\n", base, size);
+ DBG("creating mapping for region: %lx..%lx (prot: %x)\n",
+ base, size, tprot);
#ifdef CONFIG_U3_DART
/* Do not map the DART space. Fortunately, it will be aligned
@@ -664,21 +680,21 @@ void __init htab_initialize(void)
unsigned long dart_table_end = dart_tablebase + 16 * MB;
if (base != dart_tablebase)
BUG_ON(htab_bolt_mapping(base, dart_tablebase,
- __pa(base), mode_rw,
+ __pa(base), tprot,
mmu_linear_psize,
mmu_kernel_ssize));
if ((base + size) > dart_table_end)
BUG_ON(htab_bolt_mapping(dart_tablebase+16*MB,
base + size,
__pa(dart_table_end),
- mode_rw,
+ tprot,
mmu_linear_psize,
mmu_kernel_ssize));
continue;
}
#endif /* CONFIG_U3_DART */
BUG_ON(htab_bolt_mapping(base, base + size, __pa(base),
- mode_rw, mmu_linear_psize, mmu_kernel_ssize));
+ tprot, mmu_linear_psize, mmu_kernel_ssize));
}
/*
@@ -696,7 +712,7 @@ void __init htab_initialize(void)
tce_alloc_start = base + size + 1;
BUG_ON(htab_bolt_mapping(tce_alloc_start, tce_alloc_end,
- __pa(tce_alloc_start), mode_rw,
+ __pa(tce_alloc_start), prot,
mmu_linear_psize, mmu_kernel_ssize));
}
@@ -1117,8 +1133,7 @@ static void kernel_map_linear_page(unsig
unsigned long hash, hpteg;
unsigned long vsid = get_kernel_vsid(vaddr, mmu_kernel_ssize);
unsigned long va = hpt_va(vaddr, vsid, mmu_kernel_ssize);
- unsigned long mode = _PAGE_ACCESSED | _PAGE_DIRTY |
- _PAGE_COHERENT | PP_RWXX | HPTE_R_N;
+ unsigned long mode = htab_convert_pte_flags(PAGE_KERNEL);
int ret;
hash = hpt_hash(va, PAGE_SHIFT, mmu_kernel_ssize);
Index: linux-work/arch/powerpc/mm/init_64.c
===================================================================
--- linux-work.orig/arch/powerpc/mm/init_64.c 2008-08-05 15:15:06.000000000 +1000
+++ linux-work/arch/powerpc/mm/init_64.c 2008-08-05 16:09:47.000000000 +1000
@@ -206,13 +206,10 @@ static int __meminit vmemmap_populated(u
int __meminit vmemmap_populate(struct page *start_page,
unsigned long nr_pages, int node)
{
- unsigned long mode_rw;
unsigned long start = (unsigned long)start_page;
unsigned long end = (unsigned long)(start_page + nr_pages);
unsigned long page_size = 1 << mmu_psize_defs[mmu_vmemmap_psize].shift;
- mode_rw = _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
-
/* Align to the page size of the linear mapping. */
start = _ALIGN_DOWN(start, page_size);
@@ -230,9 +227,9 @@ int __meminit vmemmap_populate(struct pa
pr_debug("vmemmap %08lx allocated at %p, physical %08lx.\n",
start, p, __pa(p));
- mapped = htab_bolt_mapping(start, start + page_size,
- __pa(p), mode_rw, mmu_vmemmap_psize,
- mmu_kernel_ssize);
+ mapped = htab_bolt_mapping(start, start + page_size, __pa(p),
+ PAGE_KERNEL, mmu_vmemmap_psize,
+ mmu_kernel_ssize);
BUG_ON(mapped < 0);
}
Index: linux-work/arch/powerpc/include/asm/mmu-hash64.h
===================================================================
--- linux-work.orig/arch/powerpc/include/asm/mmu-hash64.h 2008-08-05 15:15:06.000000000 +1000
+++ linux-work/arch/powerpc/include/asm/mmu-hash64.h 2008-08-05 16:09:47.000000000 +1000
@@ -278,7 +278,7 @@ extern int hash_huge_page(struct mm_stru
unsigned long trap);
extern int htab_bolt_mapping(unsigned long vstart, unsigned long vend,
- unsigned long pstart, unsigned long mode,
+ unsigned long pstart, unsigned long prot,
int psize, int ssize);
extern void set_huge_psize(int psize);
extern void add_gpage(unsigned long addr, unsigned long page_size,
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Sean MacLennan @ 2008-08-05 6:27 UTC (permalink / raw)
Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080805021205.438365c0@lappy.seanm.ca>
False alarm. They hardcoded the arch into the include. So
#include <asm-powerpc/time.h>
no longer works but
#include <asm/time.h>
does. This is an artifact from when we where trying to use arch/ppc.
Cheers,
Sean
^ 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