* Re: [PATCH 1/1 kernel 2.6.15-rc1] Fix copy-paste bug in mpc52xx_uart.c (pdev<->dev)
From: Russell King @ 2005-11-12 22:04 UTC (permalink / raw)
To: Andrey Volkov; +Cc: Greg KH, linux-kernel, ML linuxppc-embedded
In-Reply-To: <4375E765.4000207@varma-el.com>
On Sat, Nov 12, 2005 at 04:00:21PM +0300, Andrey Volkov wrote:
> Fix copy-paste bug in mpc52xx_uart.c (pdev<->dev)
Applied, thanks.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* Re: Linuv 2.6.15-rc1
From: Olof Johansson @ 2005-11-12 22:08 UTC (permalink / raw)
To: Michael Buesch; +Cc: Linus Torvalds, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <200511122237.17157.mbuesch@freenet.de>
On Sat, Nov 12, 2005 at 10:37:16PM +0100, Michael Buesch wrote:
> The result of the build is:
>
> CHK include/linux/version.h
> CHK include/linux/compile.h
> CHK usr/initramfs_list
> GEN .version
> CHK include/linux/compile.h
> UPD include/linux/compile.h
> CC init/version.o
> LD init/built-in.o
> LD .tmp_vmlinux1
> arch/powerpc/kernel/built-in.o: In function `platform_init':
> : undefined reference to `prep_init'
> arch/powerpc/kernel/built-in.o:(__ksymtab+0x4d8): undefined reference to `ucSystemType'
> arch/powerpc/kernel/built-in.o:(__ksymtab+0x4e0): undefined reference to `_prep_type'
> make: *** [.tmp_vmlinux1] Error 1
Disabling CONFIG_PPC_PREP and CONFIG_PPC_CHRP will work around it for
now, neither are needed for a powermac.
-Olof
^ permalink raw reply
* Re: Linuv 2.6.15-rc1
From: Adrian Bunk @ 2005-11-12 22:20 UTC (permalink / raw)
To: Michael Buesch; +Cc: Linus Torvalds, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <200511122257.05552.mbuesch@freenet.de>
On Sat, Nov 12, 2005 at 10:57:05PM +0100, Michael Buesch wrote:
> On Saturday 12 November 2005 22:53, you wrote:
> > > CHK include/linux/version.h
> > > CHK include/linux/compile.h
> > > CHK usr/initramfs_list
> > > GEN .version
> > > CHK include/linux/compile.h
> > > UPD include/linux/compile.h
> > > CC init/version.o
> > > LD init/built-in.o
> > > LD .tmp_vmlinux1
> > > arch/powerpc/kernel/built-in.o: In function `platform_init':
> > > : undefined reference to `prep_init'
> > > arch/powerpc/kernel/built-in.o:(__ksymtab+0x4d8): undefined reference to `ucSystemType'
> > > arch/powerpc/kernel/built-in.o:(__ksymtab+0x4e0): undefined reference to `_prep_type'
> > > make: *** [.tmp_vmlinux1] Error 1
ucSystemType is a variable that is EXPORT_SYMBOL'ed but never used in
any way.
_prep_type is a variable that is needlessly EXPORT_SYMBOL'ed.
But prep_init points to the real problem:
CONFIG_PPC_PREP requires code from arch/ppc/platforms/, but this
directory is never visited.
What is the correct fix?
Migrate the code from arch/ppc/platforms/ to arch/powerpc/platforms/ ?
> > Please send your .config .
>
>
> I did this in my first mail:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=113182883102937&q=p5
OK, thanks, I missed this email.
> Greetings Michael.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: Linuv 2.6.15-rc1
From: Benjamin Herrenschmidt @ 2005-11-12 22:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, Michael Buesch, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.64.0511121257000.3263@g5.osdl.org>
On Sat, 2005-11-12 at 13:00 -0800, Linus Torvalds wrote:
>
> On Sat, 12 Nov 2005, Michael Buesch wrote:
> >
> > Latest GIT tree does not boot on my G4 PowerBook.
>
> What happens if you do
>
> make ARCH=powerpc
>
> and build everything that way (including the "config" phase)?
>
> So far ppc32 is still a valid architecture, and your config file makes it
> clear that you've used that. But I suspect most of the active testing has
> been done with the "powerpc" architecture compiled for 32-bit.
>
> That said, the ppc32 tree should still work. BenH? Paul?
Ìt should still work. I'm running -rc1 with "powerpc" on mine so that at
least works, it's possible that we broke "ppc", I'll have a look and
send a fix.
Ben.
^ permalink raw reply
* Re: Linuv 2.6.15-rc1
From: Benjamin Herrenschmidt @ 2005-11-12 22:25 UTC (permalink / raw)
To: Michael Buesch; +Cc: linuxppc-dev, Linus Torvalds, Linux Kernel Mailing List
In-Reply-To: <200511122237.17157.mbuesch@freenet.de>
On Sat, 2005-11-12 at 22:37 +0100, Michael Buesch wrote:
> On Saturday 12 November 2005 22:00, you wrote:
> >
> > On Sat, 12 Nov 2005, Michael Buesch wrote:
> > >
> > > Latest GIT tree does not boot on my G4 PowerBook.
> >
> > What happens if you do
> >
> > make ARCH=powerpc
> >
> > and build everything that way (including the "config" phase)?
>
> I did
> make mrproper
> copy the .config over again
> make ARCH=powerpc menuconfig
> exit and save from menuconfig
> make ARCH=powerpc
You need to disable PREP support when building with ARCH=powerpc for 32
bits, it doesn't build (yet). We should remove it from Kconfig...
Also, there is an issue with the make clean stuff, make sure when
switching archs to also remove arch/powerpc/include/asm symlink before
trying to build.
Ben.
^ permalink raw reply
* Re: Linuv 2.6.15-rc1
From: Michael Buesch @ 2005-11-12 22:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Linus Torvalds, Linux Kernel Mailing List
In-Reply-To: <1131834336.7406.46.camel@gaston>
[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]
On Saturday 12 November 2005 23:25, you wrote:
> On Sat, 2005-11-12 at 22:37 +0100, Michael Buesch wrote:
> > On Saturday 12 November 2005 22:00, you wrote:
> > >
> > > On Sat, 12 Nov 2005, Michael Buesch wrote:
> > > >
> > > > Latest GIT tree does not boot on my G4 PowerBook.
> > >
> > > What happens if you do
> > >
> > > make ARCH=powerpc
> > >
> > > and build everything that way (including the "config" phase)?
> >
> > I did
> > make mrproper
> > copy the .config over again
> > make ARCH=powerpc menuconfig
> > exit and save from menuconfig
> > make ARCH=powerpc
>
> You need to disable PREP support when building with ARCH=powerpc for 32
> bits, it doesn't build (yet). We should remove it from Kconfig...
>
> Also, there is an issue with the make clean stuff, make sure when
> switching archs to also remove arch/powerpc/include/asm symlink before
> trying to build.
Ok, thanks Ben.
ARCH=powerpc without PREP builds and boots.
--
Greetings Michael.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Linuv 2.6.15-rc1
From: Benjamin Herrenschmidt @ 2005-11-12 22:31 UTC (permalink / raw)
To: Adrian Bunk
Cc: linuxppc-dev, Linus Torvalds, Michael Buesch,
Linux Kernel Mailing List
In-Reply-To: <20051112222045.GC21448@stusta.de>
> ucSystemType is a variable that is EXPORT_SYMBOL'ed but never used in
> any way.
>
> _prep_type is a variable that is needlessly EXPORT_SYMBOL'ed.
Therse are old PREP stuffs
> But prep_init points to the real problem:
>
> CONFIG_PPC_PREP requires code from arch/ppc/platforms/, but this
> directory is never visited.
>
> What is the correct fix?
> Migrate the code from arch/ppc/platforms/ to arch/powerpc/platforms/ ?
Yes, PREP need to be migrated, but that includes adding some minimum
device-tree support for it among others. And few people still have PREP
machines, I'm not even sure we have access to one here in ozlabs... I
think for 2.6.15, we'd better just disable it in .config for
ARCH=powerpc.
Ben.
^ permalink raw reply
* asm/delay.h missing on powerpc (was: Re: Linuv 2.6.15-rc1)
From: Michael Buesch @ 2005-11-12 23:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Linux Kernel Mailing List
In-Reply-To: <1131834254.7406.43.camel@gaston>
[-- Attachment #1: Type: text/plain, Size: 430 bytes --]
On Saturday 12 November 2005 23:24, you wrote:
> Ìt should still work. I'm running -rc1 with "powerpc" on mine so that at
> least works, it's possible that we broke "ppc", I'll have a look and
> send a fix.
powerpc arch builds and runs now, but
I have problems compiling the bcm430x driver. It includes linux/delay.h.
linux/delay.h includes asm/delay.h, which does not exist.
What to do now?
--
Greetings Michael.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: 11-11-05 2.6.14 on AMCC Yosemite board(boot error)
From: Wolfgang Denk @ 2005-11-12 23:30 UTC (permalink / raw)
To: KylongMu; +Cc: linuxppc-embedded
In-Reply-To: <20051112164751.CA6C6DBB@smtp.263.net>
In message <20051112164751.CA6C6DBB@smtp.263.net> you wrote:
>
> >What you show is NOT the current code.
>
> By update with the most recent code, I did new test, and get
> Different error message, that I can't solve it, pls check the attachment.
...
> => tftp 4000000 ramdisk.img
...
> Bytes transferred = 8547050 (826aea hex)
That's a ramdisk image of more than 8 MB ...
> ## Booting image at 00400000 ...
> Image Name: Linux-2.6.14
...
> Linux version 2.6.14 (root@dxp) (gcc version 4.0.0) #1 Sat Nov 12 23:29:30 CST 2005
And this is not the current code. Current code is commit
99a21389..., and a U-Boot image built from current code (like that
available at ftp://ftp.denx.de/pub/linux/images/amcc/yosemite/uImage)
will identify itself as "Image Name: Linux-2.6.14-g99a21389".
> Kernel command line:
And you don't pass *any* boot arguments to the kernel.
...
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Because of not passing appropriate boot arguments, nor configuring
the kernel correctly, your maximum ramdisk size is 4 MB = the default
value.
...
> RAMDISK: Compressed image found at block 0
> RAMDISK: incomplete write (-28 != 32768) 4194304
> VFS: Mounted root (ext2 filesystem) readonly.
> Freeing unused kernel memory: 136k init
> attempt to access beyond end of device
> ram0: rw=0, want=32776, limit=8192
And here you see the consequences.
> I update my source code by "cg-update" directly, after many message and
> file download it shows "full merged",
>
> I think it is work. But the version only is 2.6.14.
I don't know what exactly you did, but the current code on our GIT
server as of now shows:
-> cg-log
commit 99a21389c2b0e55f30b6cf6550cb492b87dbaa3b
tree 417c9550fff5763f30f67a1fa041386281339b71
parent ff1df84b3c3154ffdb646941e1c70d17554e3042
author Heiko Schocher <hs@pollux.(none)> Fri, 11 Nov 2005 12:47:32 +0100
committer Heiko Schocher <hs@pollux.(none)> Fri, 11 Nov 2005 12:47:32 +0100
[PATCH] ppc32: fix Kernel Panic for PM82x Board with gcc-4.0.0.
Signed-off-by: Heiko Schocher <hs@denx.de>
...
If you don't see commit 99a21389..., then you don't have the current code.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Plan to throw one away. You will anyway."
- Fred Brooks, "The Mythical Man Month"
^ permalink raw reply
* Re: Problem solved: 11-11-05 2.6.14 on AMCC Yosemite board(boot error)
From: Wolfgang Denk @ 2005-11-12 23:32 UTC (permalink / raw)
To: KylongMu; +Cc: Linuxppc-embedded
In-Reply-To: <20051112180127.10C03CEA@smtp.263.net>
In message <20051112180127.10C03CEA@smtp.263.net> you wrote:
>
> The problem is solved After I check the document at:
> http://www.denx.de/wiki/view/DULG/RamdiskGreaterThan4MBCausesProblems
Yes, reading the FAQ has always been an excellent idea. But there was
no need to quote the text here in full.
> Last file I wrote:
...
> I update my source code by "cg-update" directly, after many message and
> file download it shows "full merged",
>
> I think it is work. But the version only is 2.6.14.
It ain't the current version.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Two wrongs don't make a right, but three rights make a left.
^ permalink raw reply
* Re: Linuv 2.6.15-rc1
From: Adrian Bunk @ 2005-11-12 21:53 UTC (permalink / raw)
To: Michael Buesch; +Cc: Linus Torvalds, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <200511122237.17157.mbuesch@freenet.de>
On Sat, Nov 12, 2005 at 10:37:16PM +0100, Michael Buesch wrote:
> On Saturday 12 November 2005 22:00, you wrote:
> >
> > On Sat, 12 Nov 2005, Michael Buesch wrote:
> > >
> > > Latest GIT tree does not boot on my G4 PowerBook.
> >
> > What happens if you do
> >
> > make ARCH=powerpc
> >
> > and build everything that way (including the "config" phase)?
>
> I did
> make mrproper
> copy the .config over again
> make ARCH=powerpc menuconfig
> exit and save from menuconfig
> make ARCH=powerpc
>
> The result of the build is:
>
> CHK include/linux/version.h
> CHK include/linux/compile.h
> CHK usr/initramfs_list
> GEN .version
> CHK include/linux/compile.h
> UPD include/linux/compile.h
> CC init/version.o
> LD init/built-in.o
> LD .tmp_vmlinux1
> arch/powerpc/kernel/built-in.o: In function `platform_init':
> : undefined reference to `prep_init'
> arch/powerpc/kernel/built-in.o:(__ksymtab+0x4d8): undefined reference to `ucSystemType'
> arch/powerpc/kernel/built-in.o:(__ksymtab+0x4e0): undefined reference to `_prep_type'
> make: *** [.tmp_vmlinux1] Error 1
Please send your .config .
> Greetings Michael.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: Linuv 2.6.15-rc1
From: Ulrich Teichert @ 2005-11-12 23:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1131834667.7406.49.camel@gaston>
Hi,
[trimmed the cc list a bit]
>Yes, PREP need to be migrated, but that includes adding some minimum
>device-tree support for it among others. And few people still have PREP
>machines, I'm not even sure we have access to one here in ozlabs... I
>think for 2.6.15, we'd better just disable it in .config for
>ARCH=powerpc.
for what's it worth, I'm still owning:
wehrle:~> uname -a
Linux wehrle 2.4.19 #3 Sun Aug 4 08:28:30 BST 2002 ppc unknown
wehrle:~> cat /proc/cpuinfo
cpu : 604r
clock : 199MHz
revision : 18.3 (pvr 0009 1203)
bogomips : 397.31
machine : PReP IBM 43P-140 (Tiger1)
upgrade cpu : not present
scsi fuse : ok
simms : 1:128MiB 2:128MiB 3:128MiB 4:128MiB 5:128MiB
l2 cache : sync burst, parity, 1MiB
and
sed:~> uname -a
Linux sed 2.4.28 #8 Mon Dec 13 22:16:08 CET 2004 ppc unknown
sed:~> cat /proc/cpuinfo
processor : 0
cpu : 604r
clock : ???
revision : 49.2 (pvr 0009 3102)
bogomips : 299.00
machine : PReP Utah (Powerstack II Pro4000)
l2 cache : 512KiB, parity disabled SRAM:synchronous, pipelined, no parity
Especially the 43p-140 is quite easy to get via ebay, the Powerstack II
is a more rare machine nowadays, I think.
HTH,
Uli
--
Dipl. Inf. Ulrich Teichert|e-mail: Ulrich.Teichert@gmx.de
Stormweg 24 |listening to: Suicide Drive (The Deep Eynde)
24539 Neumuenster, Germany|Public Pervert (Interpol) Cauchemar (Opération S)
^ permalink raw reply
* [PATCH] powerpc: vdso fixes
From: Benjamin Herrenschmidt @ 2005-11-13 0:27 UTC (permalink / raw)
To: Paul Mackerras
Cc: linuxppc-dev list, linuxppc64-dev, David Woodhouse, Steve Munroe,
tom_gall@mac.com
This fixes various errors in the new functions added in the vDSO's,
I've been able to test the 32 bits version and I get consistent results
with the corresponding syscalls.
There is still a question about get_tbfreq() though. It currently
returns the value that the kernel keeps in tb_ticks_per_sec. This value
is obtained from the timebase at boot, but it's truncated to HZ
precision:
tb_ticks_per_jiffy = ppc_tb_freq / HZ;
tb_ticks_per_sec = tb_ticks_per_jiffy * HZ;
And it's later on modified by the ppc_adjtimex() code.
This is different from the value exposed in /proc/cpuinfo for the
timebase which is a straight copy of ppc_tb_freq, which is the
calibration value obtained at boot and unmodified.
The question at this point are: Is that "rouding" to HZ done by the
kernel correct ? And should the vDSO return this value that gets
adjusted or the fixed initial calibration value, or both.
In the later case, should I add an argument to get_tbfreq() or add a
separate function ?
In the meantime, please apply this patch as it fixes a few annoying bug
in the vDSO implementation currently in -rc1.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/arch/powerpc/kernel/asm-offsets.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/asm-offsets.c 2005-11-13 10:34:07.000000000 +1100
+++ linux-work/arch/powerpc/kernel/asm-offsets.c 2005-11-13 10:34:50.000000000 +1100
@@ -275,8 +275,8 @@
#else
DEFINE(TVAL32_TV_SEC, offsetof(struct timeval, tv_sec));
DEFINE(TVAL32_TV_USEC, offsetof(struct timeval, tv_usec));
- DEFINE(TSPEC32_TV_SEC, offsetof(struct timespec, tv_sec));
- DEFINE(TSPEC32_TV_NSEC, offsetof(struct timespec, tv_nsec));
+ DEFINE(TSPC32_TV_SEC, offsetof(struct timespec, tv_sec));
+ DEFINE(TSPC32_TV_NSEC, offsetof(struct timespec, tv_nsec));
#endif
/* timeval/timezone offsets for use by vdso */
DEFINE(TZONE_TZ_MINWEST, offsetof(struct timezone, tz_minuteswest));
Index: linux-work/arch/powerpc/kernel/vdso32/gettimeofday.S
===================================================================
--- linux-work.orig/arch/powerpc/kernel/vdso32/gettimeofday.S 2005-11-13 10:34:07.000000000 +1100
+++ linux-work/arch/powerpc/kernel/vdso32/gettimeofday.S 2005-11-13 10:55:55.000000000 +1100
@@ -83,7 +83,7 @@
/* Check for supported clock IDs */
cmpli cr0,r3,CLOCK_REALTIME
cmpli cr1,r3,CLOCK_MONOTONIC
- cror cr0,cr0,cr1
+ cror cr0*4+eq,cr0*4+eq,cr1*4+eq
bne cr0,99f
mflr r12 /* r12 saves lr */
@@ -91,7 +91,7 @@
mr r10,r3 /* r10 saves id */
mr r11,r4 /* r11 saves tp */
bl __get_datapage@local /* get data page */
- mr r9, r3 /* datapage ptr in r9 */
+ mr r9,r3 /* datapage ptr in r9 */
beq cr1,50f /* if monotonic -> jump there */
/*
@@ -210,7 +210,7 @@
/* Check for supported clock IDs */
cmpwi cr0,r3,CLOCK_REALTIME
cmpwi cr1,r3,CLOCK_MONOTONIC
- cror cr0,cr0,cr1
+ cror cr0*4+eq,cr0*4+eq,cr1*4+eq
bne cr0,99f
li r3,0
Index: linux-work/arch/powerpc/kernel/vdso64/gettimeofday.S
===================================================================
--- linux-work.orig/arch/powerpc/kernel/vdso64/gettimeofday.S 2005-11-13 10:34:07.000000000 +1100
+++ linux-work/arch/powerpc/kernel/vdso64/gettimeofday.S 2005-11-13 10:56:08.000000000 +1100
@@ -68,7 +68,7 @@
/* Check for supported clock IDs */
cmpwi cr0,r3,CLOCK_REALTIME
cmpwi cr1,r3,CLOCK_MONOTONIC
- cror cr0,cr0,cr1
+ cror cr0*4+eq,cr0*4+eq,cr1*4+eq
bne cr0,99f
mflr r12 /* r12 saves lr */
@@ -181,7 +181,7 @@
/* Check for supported clock IDs */
cmpwi cr0,r3,CLOCK_REALTIME
cmpwi cr1,r3,CLOCK_MONOTONIC
- cror cr0,cr0,cr1
+ cror cr0*4+eq,cr0*4+eq,cr1*4+eq
bne cr0,99f
li r3,0
Index: linux-work/arch/powerpc/kernel/vdso32/datapage.S
===================================================================
--- linux-work.orig/arch/powerpc/kernel/vdso32/datapage.S 2005-11-12 08:27:18.000000000 +1100
+++ linux-work/arch/powerpc/kernel/vdso32/datapage.S 2005-11-13 11:06:39.000000000 +1100
@@ -77,8 +77,9 @@
mflr r12
.cfi_register lr,r12
bl __get_datapage@local
- lwz r3,CFG_TB_TICKS_PER_SEC(r3)
lwz r4,(CFG_TB_TICKS_PER_SEC + 4)(r3)
+ lwz r3,CFG_TB_TICKS_PER_SEC(r3)
mtlr r12
+ blr
.cfi_endproc
V_FUNCTION_END(__kernel_get_tbfreq)
Index: linux-work/arch/powerpc/kernel/vdso64/datapage.S
===================================================================
--- linux-work.orig/arch/powerpc/kernel/vdso64/datapage.S 2005-11-12 08:27:19.000000000 +1100
+++ linux-work/arch/powerpc/kernel/vdso64/datapage.S 2005-11-13 10:58:45.000000000 +1100
@@ -80,5 +80,6 @@
bl V_LOCAL_FUNC(__get_datapage)
ld r3,CFG_TB_TICKS_PER_SEC(r3)
mtlr r12
+ blr
.cfi_endproc
V_FUNCTION_END(__kernel_get_tbfreq)
^ permalink raw reply
* Re: [PATCH 2.6.14] mm: 8xx MM fix for
From: Marcelo Tosatti @ 2005-11-12 19:28 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Tom Rini, Dan Malek, gtolstolytkin, linuxppc-embedded
In-Reply-To: <F6AD7E21CDF4E145A44F61F43EE6D9393FD5C6@tmnt04.transmode.se>
On Mon, Nov 07, 2005 at 07:37:45PM +0100, Joakim Tjernlund wrote:
> >
> > On Mon, Nov 07, 2005 at 07:14:15PM +0100, Joakim Tjernlund wrote:
> > > > -----Original Message-----
> > > > From: Tom Rini [mailto:trini@kernel.crashing.org]
> > > > Sent: 07 November 2005 16:52
> > > > To: Marcelo Tosatti
> > > > Cc: Joakim Tjernlund; Pantelis Antoniou; Dan Malek;
> > > > linuxppc-embedded@ozlabs.org; gtolstolytkin@ru.mvista.com
> > > > Subject: Re: [PATCH 2.6.14] mm: 8xx MM fix for
> > > >
> > > > On Mon, Nov 07, 2005 at 08:16:18AM -0200, Marcelo Tosatti wrote:
> > > > > Joakim!
> > > > >
> > > > > On Mon, Nov 07, 2005 at 03:32:52PM +0100, Joakim
> > Tjernlund wrote:
> > > > > > Hi Marcelo
> > > > > >
> > > > > > [SNIP]
> > > > > > > The root of the problem are the changes against the 8xx TLB
> > > > > > > handlers introduced
> > > > > > > during v2.6. What happens is the TLBMiss handlers load the
> > > > > > > zeroed pte into
> > > > > > > the TLB, causing the TLBError handler to be invoked (thats
> > > > > > > two TLB faults per
> > > > > > > pagefault), which then jumps to the generic MM code to
> > > > setup the pte.
> > > > > > >
> > > > > > > The bug is that the zeroed TLB is not invalidated (the
> > > > same reason
> > > > > > > for the "dcbst" misbehaviour), resulting in infinite
> > > > TLBError faults.
> > > > > > >
> > > > > > > Dan, I wonder why we just don't go back to v2.4 behaviour.
> > > > > >
> > > > > > This is one reason why it is the way it is:
> > > > > >
> > > >
> > http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016382.html
> > > > > > This details are little fuzzy ATM, but I think the
> > reason for the
> > > > > > current
> > > > > > impl. was only that it was less intrusive to impl.
> > > > >
> > > > > Ah, I see. I wonder if the bug is processor specific: we
> > > > don't have such
> > > > > changes in our v2.4 tree and never experienced such problem.
> > > > >
> > > > > It should be pretty easy to hit it right? (instruction
> > > > pagefaults should
> > > > > fail).
> > > > >
> > > > > Grigori, Tom, can you enlight us about the issue on the URL
> > > > above. How
> > > > > can it be triggered?
> > > >
> > > > So after looking at the code in 2.6.14 and current git, I
> > think the
> > > > above URL isn't relevant, unless there was a change I
> > missed (which
> > > > could totally be possible) that reverted the patch there and
> > > > fixed that
> > > > issue in a different manner. But since I didn't figure that
> > > > out until I
> > > > had finished researching it again:
> > >
> > > I wasn't clear enough. What I meant was that the above patch made me
> > > think and
> > > the result was that I came up with a simpler fix, the "two
> > exception"
> > > fix that
> > > is in current kernels. See
> > >
> > http://linux.bkbits.net:8080/linux-2.6/diffs/arch/ppc/kernel/h
> > ead_8xx.S@
> > >
> > 1.19?nav=index.html|src/.|src/arch|src/arch/ppc|src/arch/ppc/k
> > ernel|hist
> > > /arch/ppc/kernel/head_8xx.S
> > > It appears this fix has some other issues :(
> > >
> > > How do the other ppc arches do? I am guessing that they don't double
> > > fault, but bails
> > > out to do_page_fault from the TLB Miss handler, like 8xx used to do.
> >
> > Assuming Dan doesn't come up with a more simple & better fix, maybe we
> > should go back to the original patch I made?
>
> That was what I was thinking too(or some variation of your patch)
> I wonder if that would solve the misbehaving dcbst problem Marcelo found
> some time ago too?
Hi Joakim,
Yes, it would fix the "dcbst" issue. That problem was triggered by a
zeroed TLB entry.
In practice it seems that the "three exception" approach does not impose
a significant overhead in comparison with the "two exception" version
(as can be seen by the results of the latency tests).
Anyway, if decided upon, the "two exception" version (no zeroed TLB
entry state) needs the TLBMiss handler should to the present bit as Dan
mentioned.
I don't know what Dan is up to, he meant to be doing significant changes.
I'll be playing with TLB preloading next week... how's your TLB handler
shrinkage idea?
^ permalink raw reply
* Re: asm/delay.h missing on powerpc (was: Re: Linuv 2.6.15-rc1)
From: Benjamin Herrenschmidt @ 2005-11-13 0:33 UTC (permalink / raw)
To: Michael Buesch; +Cc: linuxppc-dev, Linux Kernel Mailing List
In-Reply-To: <200511130013.45610.mbuesch@freenet.de>
On Sun, 2005-11-13 at 00:13 +0100, Michael Buesch wrote:
> On Saturday 12 November 2005 23:24, you wrote:
> > Ìt should still work. I'm running -rc1 with "powerpc" on mine so that at
> > least works, it's possible that we broke "ppc", I'll have a look and
> > send a fix.
>
> powerpc arch builds and runs now, but
> I have problems compiling the bcm430x driver. It includes linux/delay.h.
> linux/delay.h includes asm/delay.h, which does not exist.
> What to do now?
I suspect that building drivers out of tree doesn't work very well with
the new "merged" architecture where includes are split between asm/ppc
and asm-powerpc... You should make sure that you build the driver with
the same ARCH as the kernel, that is ARCH=powerpc at least, if we got
the Makefiles right, that should give you all the headers...
(building glibc is definitely a pain :)
Ben.
^ permalink raw reply
* [2.6 patch] PPC_PREP: remove unneeded exports
From: Adrian Bunk @ 2005-11-13 1:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Linus Torvalds, Michael Buesch,
Linux Kernel Mailing List
In-Reply-To: <1131834667.7406.49.camel@gaston>
On Sun, Nov 13, 2005 at 09:31:06AM +1100, Benjamin Herrenschmidt wrote:
>
> > ucSystemType is a variable that is EXPORT_SYMBOL'ed but never used in
> > any way.
> >
> > _prep_type is a variable that is needlessly EXPORT_SYMBOL'ed.
>
> Therse are old PREP stuffs
>...
Is the patch below OK?
> Ben.
cu
Adrian
<-- snip -->
This patch removes the EXPORT_SYMBOL'ed but completely unused variable
ucSystemType and removes the unneeded EXPORT_SYMBOL(_prep_type).
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
arch/powerpc/kernel/ppc_ksyms.c | 5 -----
arch/ppc/kernel/ppc_ksyms.c | 4 ----
arch/ppc/platforms/prep_setup.c | 1 -
include/asm-powerpc/processor.h | 1 -
4 files changed, 11 deletions(-)
--- linux-2.6.15-rc1/include/asm-powerpc/processor.h.old 2005-11-13 01:44:12.000000000 +0100
+++ linux-2.6.15-rc1/include/asm-powerpc/processor.h 2005-11-13 01:44:25.000000000 +0100
@@ -68,7 +68,6 @@
* vendor. Board revision is also made available. This will be moved
* elsewhere soon
*/
-extern unsigned char ucSystemType;
extern unsigned char ucBoardRev;
extern unsigned char ucBoardRevMaj, ucBoardRevMin;
--- linux-2.6.15-rc1/arch/ppc/platforms/prep_setup.c.old 2005-11-13 01:44:36.000000000 +0100
+++ linux-2.6.15-rc1/arch/ppc/platforms/prep_setup.c 2005-11-13 01:44:40.000000000 +0100
@@ -72,7 +72,6 @@
TODC_ALLOC();
-unsigned char ucSystemType;
unsigned char ucBoardRev;
unsigned char ucBoardRevMaj, ucBoardRevMin;
--- linux-2.6.15-rc1/arch/ppc/kernel/ppc_ksyms.c.old 2005-11-13 01:44:49.000000000 +0100
+++ linux-2.6.15-rc1/arch/ppc/kernel/ppc_ksyms.c 2005-11-13 01:44:54.000000000 +0100
@@ -82,10 +82,6 @@
EXPORT_SYMBOL(ISA_DMA_THRESHOLD);
EXPORT_SYMBOL(DMA_MODE_READ);
EXPORT_SYMBOL(DMA_MODE_WRITE);
-#if defined(CONFIG_PPC_PREP)
-EXPORT_SYMBOL(_prep_type);
-EXPORT_SYMBOL(ucSystemType);
-#endif
#if !defined(__INLINE_BITOPS)
EXPORT_SYMBOL(set_bit);
--- linux-2.6.15-rc1/arch/powerpc/kernel/ppc_ksyms.c.old 2005-11-13 01:45:06.000000000 +0100
+++ linux-2.6.15-rc1/arch/powerpc/kernel/ppc_ksyms.c 2005-11-13 01:45:12.000000000 +0100
@@ -76,11 +76,6 @@
EXPORT_SYMBOL(sys_sigreturn);
#endif
-#if defined(CONFIG_PPC_PREP)
-EXPORT_SYMBOL(_prep_type);
-EXPORT_SYMBOL(ucSystemType);
-#endif
-
EXPORT_SYMBOL(strcpy);
EXPORT_SYMBOL(strncpy);
EXPORT_SYMBOL(strcat);
^ permalink raw reply
* Re: [2.6 patch] PPC_PREP: remove unneeded exports
From: Benjamin Herrenschmidt @ 2005-11-13 3:23 UTC (permalink / raw)
To: Adrian Bunk
Cc: linuxppc-dev, Linus Torvalds, Michael Buesch,
Linux Kernel Mailing List
In-Reply-To: <20051113012608.GH21448@stusta.de>
On Sun, 2005-11-13 at 02:26 +0100, Adrian Bunk wrote:
> On Sun, Nov 13, 2005 at 09:31:06AM +1100, Benjamin Herrenschmidt wrote:
> >
> > > ucSystemType is a variable that is EXPORT_SYMBOL'ed but never used in
> > > any way.
> > >
> > > _prep_type is a variable that is needlessly EXPORT_SYMBOL'ed.
> >
> > Therse are old PREP stuffs
> >...
>
> Is the patch below OK?
The ucXXX variables should probably go (or at least be unexported) but I
would keep the _prep_type export for now, unless we are certain no
driver and no out of tree stuff neither uses it (hrm... might well be
the case).
In any case, the proper fix is probably to move the EXPORT_SYMBOL() out
of ppc_ksyms, and have it next to the declaration of the variable.
Ben.
^ permalink raw reply
* Re: [RFC] Attempt to clean up sigsuspend et al
From: Paul Mackerras @ 2005-11-13 6:58 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1131756526.27347.212.camel@baythorne.infradead.org>
David Woodhouse writes:
> I suppose I could make a TIF_xxx flag make entry.S do that. It's not
> massively pretty, but then it wasn't pretty beforehand either. At least
> I'd have made the ppc32 and ppc64 code match, removed the assembly
> wrappers for a bunch of syscalls, and shortened the syscall exit fast
> path on ppc64.
>
> I'd probably still be removing more lines of code than I add, but I'm
> not entirely convinced by the whole plan. What do you think?
Or have a mark in the syscall table (e.g. set the bottom bit of the
address) for the syscalls that need the full register set. That does
mean an extra conditional branch in the syscall entry path for all
syscalls, though.
> Failing that, I'll just switch them both to do either what ppc32
> currently does with sigreturn_exit() or what ppc64 does with returning
> zero to take the ret_from_except path. Probably the former, since
> pselect() and ppoll() will sometimes want to return zero without
> invoking a signal handler. And we can probably shorten the ppc64
> syscall exit path anyway, either way.
I'll be upset if you can shorten it by a lot - I thought I had it
pretty tight already. :)
Paul.
^ permalink raw reply
* Re: Linuv 2.6.15-rc1
From: Geert Uytterhoeven @ 2005-11-13 9:17 UTC (permalink / raw)
To: Ulrich Teichert; +Cc: Linux/PPC Development
In-Reply-To: <200511122351.jACNpiG5016918@arbas.nms.ulrich-teichert.org>
On Sun, 13 Nov 2005, Ulrich Teichert wrote:
> Especially the 43p-140 is quite easy to get via ebay, the Powerstack II
> is a more rare machine nowadays, I think.
^^^^^^^^
Probably because almost no one managed to buy one originally in the first
place? :-)
I tried a long time ago, but the people at the Motorola PowerPC booth at CeBIT
didn't even know about their own machines...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [RFC] Attempt to clean up sigsuspend et al
From: David Woodhouse @ 2005-11-13 9:41 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17270.58406.370195.733887@cargo.ozlabs.ibm.com>
On Sun, 2005-11-13 at 17:58 +1100, Paul Mackerras wrote:
> Or have a mark in the syscall table (e.g. set the bottom bit of the
> address) for the syscalls that need the full register set. That does
> mean an extra conditional branch in the syscall entry path for all
> syscalls, though.
We don't need to do it on entry; we can do it on exit. If do_signal()
sees that the nvgprs weren't saved in the pt_regs it's playing with,
then it can set a new TIF_SAVENVPGRS_TO_SIG_FRAME bit. I don't think we
even need to store a pointer saying where to put them -- the signal
frame will always be at the top of the userspace stack.
As long as we handle the new bit before TIF_SIGPENDING and before
another call to do_signal(), we don't need to worry about recursive
signals and having to fill in more than one signal frame.
--
dwmw2
^ permalink raw reply
* Re: asm/delay.h missing on powerpc (was: Re: Linuv 2.6.15-rc1)
From: Michael Buesch @ 2005-11-13 9:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Linux Kernel Mailing List
In-Reply-To: <1131841993.5504.13.camel@gaston>
[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]
On Sunday 13 November 2005 01:33, you wrote:
> On Sun, 2005-11-13 at 00:13 +0100, Michael Buesch wrote:
> > On Saturday 12 November 2005 23:24, you wrote:
> > > Ìt should still work. I'm running -rc1 with "powerpc" on mine so that at
> > > least works, it's possible that we broke "ppc", I'll have a look and
> > > send a fix.
> >
> > powerpc arch builds and runs now, but
> > I have problems compiling the bcm430x driver. It includes linux/delay.h.
> > linux/delay.h includes asm/delay.h, which does not exist.
> > What to do now?
>
> I suspect that building drivers out of tree doesn't work very well with
> the new "merged" architecture where includes are split between asm/ppc
> and asm-powerpc... You should make sure that you build the driver with
> the same ARCH as the kernel, that is ARCH=powerpc at least, if we got
> the Makefiles right, that should give you all the headers...
Call me an idiot ;)
doing make ARCH=powerpc in the driver works perfectly fine.
> (building glibc is definitely a pain :)
Try out the stable LFS book. It will guilde you trough it step by step. ;)
--
Greetings Michael.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Attempt to clean up sigsuspend et al
From: Paul Mackerras @ 2005-11-13 10:09 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1131874887.27347.221.camel@baythorne.infradead.org>
David Woodhouse writes:
> We don't need to do it on entry; we can do it on exit. If do_signal()
> sees that the nvgprs weren't saved in the pt_regs it's playing with,
> then it can set a new TIF_SAVENVPGRS_TO_SIG_FRAME bit. I don't think we
> even need to store a pointer saying where to put them -- the signal
> frame will always be at the top of the userspace stack.
Two problems with that: (1) for *sigsuspend, if do_signal returns 0,
then we need to go back and keep waiting, and (2) it doesn't handle
the other syscalls that need the full register set, such as fork,
clone etc. Also, for the *sigsuspend case, we need to pass the saved
signal set to do_signal, not NULL (as the call from the exception exit
path does).
Paul.
^ permalink raw reply
* Re: [RFC] Attempt to clean up sigsuspend et al
From: David Woodhouse @ 2005-11-13 11:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17271.4290.486710.929502@cargo.ozlabs.ibm.com>
On Sun, 2005-11-13 at 21:09 +1100, Paul Mackerras wrote:
> > We don't need to do it on entry; we can do it on exit. If do_signal()
> > sees that the nvgprs weren't saved in the pt_regs it's playing with,
> > then it can set a new TIF_SAVENVPGRS_TO_SIG_FRAME bit. I don't think we
> > even need to store a pointer saying where to put them -- the signal
> > frame will always be at the top of the userspace stack.
>
> Two problems with that: (1) for *sigsuspend, if do_signal returns 0,
> then we need to go back and keep waiting, and (2) it doesn't handle
> the other syscalls that need the full register set, such as fork,
> clone etc. Also, for the *sigsuspend case, we need to pass the saved
> signal set to do_signal, not NULL (as the call from the exception exit
> path does).
It doesn't address fork/vfork/clone; certainly. I haven't really looked
at that code path at all yet. It was the *suspend() functions which
offended me, mostly because I need similar behaviour for pselect() and
ppoll() and I didn't want to add to the mess.
But I think other things you mention are OK -- we'd still call
do_signal() from *sigsuspend() just as we do at the moment, with the
same loop. It's just that do_signal() would notice that the nvgprs
aren't saved, and would set the TIF_SAVENVPGRS_TO_SIG_FRAME bit. ..
if (!regs->trap & 1)
set_thread_flag(TIF_SAVENVGPRS_SIG);
We end up returning to userspace via entry.S, and the code there notices
the SAVENVGPRS bit and saves _just_ r14-r31 into the signal frame. It
doesn't have to call do_signal() again, so doesn't have to get the right
saved signal mask when doing so.
(Actually in the case of swapcontext() we don't know that the nvgprs
should be saved in a signal frame at the top of the userspace stack; the
context will be elsewhere. We probably do need to store a pointer in the
thread_info, but that's OK too)
--
dwmw2
^ permalink raw reply
* RE: [PATCH 2.6.14] mm: 8xx MM fix for
From: Joakim Tjernlund @ 2005-11-13 12:47 UTC (permalink / raw)
To: 'Marcelo Tosatti'
Cc: 'Tom Rini', 'Dan Malek', gtolstolytkin,
linuxppc-embedded
In-Reply-To: <20051112192826.GB20537@logos.cnet>
> -----Original Message-----
> From: Marcelo Tosatti [mailto:marcelo.tosatti@cyclades.com]
> Sent: den 12 november 2005 20:28
> To: Joakim Tjernlund
> Cc: Tom Rini; Dan Malek; gtolstolytkin@ru.mvista.com;
> linuxppc-embedded@ozlabs.org
> Subject: Re: [PATCH 2.6.14] mm: 8xx MM fix for
>
> On Mon, Nov 07, 2005 at 07:37:45PM +0100, Joakim Tjernlund wrote:
> > >
> > > On Mon, Nov 07, 2005 at 07:14:15PM +0100, Joakim Tjernlund wrote:
> > > > > -----Original Message-----
> > > > > From: Tom Rini [mailto:trini@kernel.crashing.org]
> > > > > Sent: 07 November 2005 16:52
> > > > > To: Marcelo Tosatti
> > > > > Cc: Joakim Tjernlund; Pantelis Antoniou; Dan Malek;
> > > > > linuxppc-embedded@ozlabs.org; gtolstolytkin@ru.mvista.com
> > > > > Subject: Re: [PATCH 2.6.14] mm: 8xx MM fix for
> > > > >
> > > > > On Mon, Nov 07, 2005 at 08:16:18AM -0200, Marcelo
> Tosatti wrote:
> > > > > > Joakim!
> > > > > >
> > > > > > On Mon, Nov 07, 2005 at 03:32:52PM +0100, Joakim
> > > Tjernlund wrote:
> > > > > > > Hi Marcelo
> > > > > > >
> > > > > > > [SNIP]
> > > > > > > > The root of the problem are the changes against the 8xx
> > > > > > > > TLB handlers introduced during v2.6. What
> happens is the
> > > > > > > > TLBMiss handlers load the zeroed pte into the
> TLB, causing
> > > > > > > > the TLBError handler to be invoked (thats two
> TLB faults
> > > > > > > > per pagefault), which then jumps to the generic
> MM code to
> > > > > setup the pte.
> > > > > > > >
> > > > > > > > The bug is that the zeroed TLB is not invalidated (the
> > > > > same reason
> > > > > > > > for the "dcbst" misbehaviour), resulting in infinite
> > > > > TLBError faults.
> > > > > > > >
> > > > > > > > Dan, I wonder why we just don't go back to v2.4
> behaviour.
> > > > > > >
> > > > > > > This is one reason why it is the way it is:
> > > > > > >
> > > > >
> > >
> http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016382.ht
> > > ml
> > > > > > > This details are little fuzzy ATM, but I think the
> > > reason for the
> > > > > > > current
> > > > > > > impl. was only that it was less intrusive to impl.
> > > > > >
> > > > > > Ah, I see. I wonder if the bug is processor specific: we
> > > > > don't have such
> > > > > > changes in our v2.4 tree and never experienced such problem.
> > > > > >
> > > > > > It should be pretty easy to hit it right? (instruction
> > > > > pagefaults should
> > > > > > fail).
> > > > > >
> > > > > > Grigori, Tom, can you enlight us about the issue on the URL
> > > > > above. How
> > > > > > can it be triggered?
> > > > >
> > > > > So after looking at the code in 2.6.14 and current git, I
> > > think the
> > > > > above URL isn't relevant, unless there was a change I
> > > missed (which
> > > > > could totally be possible) that reverted the patch there and
> > > > > fixed that issue in a different manner. But since I didn't
> > > > > figure that out until I had finished researching it again:
> > > >
> > > > I wasn't clear enough. What I meant was that the above
> patch made
> > > > me think and the result was that I came up with a
> simpler fix, the
> > > > "two
> > > exception"
> > > > fix that
> > > > is in current kernels. See
> > > >
> > > http://linux.bkbits.net:8080/linux-2.6/diffs/arch/ppc/kernel/h
> > > ead_8xx.S@
> > > >
> > > 1.19?nav=index.html|src/.|src/arch|src/arch/ppc|src/arch/ppc/k
> > > ernel|hist
> > > > /arch/ppc/kernel/head_8xx.S
> > > > It appears this fix has some other issues :(
> > > >
> > > > How do the other ppc arches do? I am guessing that they don't
> > > > double fault, but bails out to do_page_fault from the TLB Miss
> > > > handler, like 8xx used to do.
> > >
> > > Assuming Dan doesn't come up with a more simple & better
> fix, maybe
> > > we should go back to the original patch I made?
> >
> > That was what I was thinking too(or some variation of your patch) I
> > wonder if that would solve the misbehaving dcbst problem
> Marcelo found
> > some time ago too?
>
> Hi Joakim,
>
> Yes, it would fix the "dcbst" issue. That problem was
> triggered by a zeroed TLB entry.
>
> In practice it seems that the "three exception" approach does
> not impose a significant overhead in comparison with the "two
> exception" version (as can be seen by the results of the
> latency tests).
>
> Anyway, if decided upon, the "two exception" version (no
> zeroed TLB entry state) needs the TLBMiss handler should to
> the present bit as Dan mentioned.
>
> I don't know what Dan is up to, he meant to be doing
> significant changes.
>
> I'll be playing with TLB preloading next week... how's your
> TLB handler shrinkage idea?
Hi Marcelo
Its still holding I think, it's a add on to whats in linuxppc-2.4:
http://ppc.bkbits.net:8080/linuxppc-2.4/diffs/arch/ppc/kernel/head_8xx.S@1.21?nav=index.html|src/.|src/arch|src/arch/ppc|src/arch/pp
c/kernel|hist/arch/ppc/kernel/head_8xx.S
If one could eliminate the test for a zero L1 entry you save an extra 4 instructions.
+ mfcr r20
+ cmplwi cr0, r21, 0x0fff /* Test page descriptor page address */
+ bng- 2f /* If zero, don't try to find a pte */
+ mtcr r20
If SPRG2 is free to use you can stash r21 there, then you don't need to use RAM to stash registers.
Maybe its possible to PIN some of the vmalloc space and use that for modules?
Jocke
^ permalink raw reply
* Powerstack II (was: Re: Linuv 2.6.15-rc1)
From: Ulrich Teichert @ 2005-11-13 14:46 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux/PPC Development
In-Reply-To: <Pine.LNX.4.62.0511131014150.17491@numbat.sonytel.be>
Hi,
>On Sun, 13 Nov 2005, Ulrich Teichert wrote:
>> Especially the 43p-140 is quite easy to get via ebay, the Powerstack II
>> is a more rare machine nowadays, I think.
> ^^^^^^^^
>Probably because almost no one managed to buy one originally in the first
>place? :-)
I think they got sold more often in the project business, not to
"ordinary people", but I may be wrong ;-)
>I tried a long time ago, but the people at the Motorola PowerPC booth at CeBIT
>didn't even know about their own machines...
They show up on ebay from time to time, but spare parts are hard to
get. I'm searching for a hard disk tray since I got mine in 2003,
but I managed to find a tray for the floppy,
CU,
Uli
--
Dipl. Inf. Ulrich Teichert|e-mail: Ulrich.Teichert@gmx.de
Stormweg 24 |listening to: Suicide Drive (The Deep Eynde)
24539 Neumuenster, Germany|Public Pervert (Interpol) Cauchemar (Opération S)
^ 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