* Re: [RFC] Attempt to clean up sigsuspend et al
From: Paul Mackerras @ 2005-11-14 4:43 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1131883101.27347.233.camel@baythorne.infradead.org>
David Woodhouse writes:
> 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. ..
Ah ok, I see now, that sounds all right.
> (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)
True.
Paul.
^ permalink raw reply
* [PATCH] powerpc: vdso fixes (take #2)
From: Benjamin Herrenschmidt @ 2005-11-14 3:55 UTC (permalink / raw)
To: Paul Mackerras
Cc: linuxppc-dev list, tom_gall@mac.com, David Woodhouse,
Steve Munroe, linuxppc64-dev
This fixes various errors in the new functions added in the vDSO's,
I've now verified all functions on both 32 and 64 bits vDSOs. It also
fix a sign extension bug getting the initial time of day at boot that
could cause the monotonic clock value to be completely on bogus for
64 bits applications (with either the vDSO or the syscall) on
powermacs.
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-14 11:06:58.000000000 +1100
+++ linux-work/arch/powerpc/kernel/asm-offsets.c 2005-11-14 13:09:57.000000000 +1100
@@ -270,13 +270,15 @@
DEFINE(TVAL64_TV_USEC, offsetof(struct timeval, tv_usec));
DEFINE(TVAL32_TV_SEC, offsetof(struct compat_timeval, tv_sec));
DEFINE(TVAL32_TV_USEC, offsetof(struct compat_timeval, tv_usec));
+ DEFINE(TSPC64_TV_SEC, offsetof(struct timespec, tv_sec));
+ DEFINE(TSPC64_TV_NSEC, offsetof(struct timespec, tv_nsec));
DEFINE(TSPC32_TV_SEC, offsetof(struct compat_timespec, tv_sec));
DEFINE(TSPC32_TV_NSEC, offsetof(struct compat_timespec, tv_nsec));
#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-14 11:06:58.000000000 +1100
+++ linux-work/arch/powerpc/kernel/vdso32/gettimeofday.S 2005-11-14 12:06:27.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 */
/*
@@ -173,10 +173,14 @@
add r4,r4,r7
lis r5,NSEC_PER_SEC@h
ori r5,r5,NSEC_PER_SEC@l
- cmpli cr0,r4,r5
+ cmpl cr0,r4,r5
+ cmpli cr1,r4,0
blt 1f
subf r4,r5,r4
addi r3,r3,1
+1: bge cr1,1f
+ addi r3,r3,-1
+ add r4,r4,r5
1: stw r3,TSPC32_TV_SEC(r11)
stw r4,TSPC32_TV_NSEC(r11)
@@ -210,7 +214,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-14 11:06:58.000000000 +1100
+++ linux-work/arch/powerpc/kernel/vdso64/gettimeofday.S 2005-11-14 14:38:51.000000000 +1100
@@ -1,4 +1,5 @@
-/*
+
+ /*
* Userland implementation of gettimeofday() for 64 bits processes in a
* ppc64 kernel for use in the vDSO
*
@@ -68,7 +69,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 */
@@ -84,16 +85,17 @@
bl V_LOCAL_FUNC(__do_get_xsec) /* get xsec from tb & kernel */
- lis r7,0x3b9a /* r7 = 1000000000 = NSEC_PER_SEC */
- ori r7,r7,0xca00
+ lis r7,15 /* r7 = 1000000 = USEC_PER_SEC */
+ ori r7,r7,16960
rldicl r5,r4,44,20 /* r5 = sec = xsec / XSEC_PER_SEC */
rldicr r6,r5,20,43 /* r6 = sec * XSEC_PER_SEC */
std r5,TSPC64_TV_SEC(r11) /* store sec in tv */
subf r0,r6,r4 /* r0 = xsec = (xsec - r6) */
- mulld r0,r0,r7 /* nsec = (xsec * NSEC_PER_SEC) /
+ mulld r0,r0,r7 /* usec = (xsec * USEC_PER_SEC) /
* XSEC_PER_SEC
*/
rldicl r0,r0,44,20
+ mulli r0,r0,1000 /* nsec = usec * 1000 */
std r0,TSPC64_TV_NSEC(r11) /* store nsec in tp */
mtlr r12
@@ -106,15 +108,16 @@
50: bl V_LOCAL_FUNC(__do_get_xsec) /* get xsec from tb & kernel */
- lis r7,0x3b9a /* r7 = 1000000000 = NSEC_PER_SEC */
- ori r7,r7,0xca00
+ lis r7,15 /* r7 = 1000000 = USEC_PER_SEC */
+ ori r7,r7,16960
rldicl r5,r4,44,20 /* r5 = sec = xsec / XSEC_PER_SEC */
rldicr r6,r5,20,43 /* r6 = sec * XSEC_PER_SEC */
subf r0,r6,r4 /* r0 = xsec = (xsec - r6) */
- mulld r0,r0,r7 /* nsec = (xsec * NSEC_PER_SEC) /
+ mulld r0,r0,r7 /* usec = (xsec * USEC_PER_SEC) /
* XSEC_PER_SEC
*/
rldicl r6,r0,44,20
+ mulli r6,r6,1000 /* nsec = usec * 1000 */
/* now we must fixup using wall to monotonic. We need to snapshot
* that value and do the counter trick again. Fortunately, we still
@@ -123,8 +126,8 @@
* can be used
*/
- lwz r4,WTOM_CLOCK_SEC(r9)
- lwz r7,WTOM_CLOCK_NSEC(r9)
+ lwa r4,WTOM_CLOCK_SEC(r3)
+ lwa r7,WTOM_CLOCK_NSEC(r3)
/* We now have our result in r4,r7. We create a fake dependency
* on that result and re-check the counter
@@ -144,10 +147,14 @@
add r7,r7,r6
lis r9,NSEC_PER_SEC@h
ori r9,r9,NSEC_PER_SEC@l
- cmpli cr0,r7,r9
+ cmpl cr0,r7,r9
+ cmpli cr1,r7,0
blt 1f
subf r7,r9,r7
addi r4,r4,1
+1: bge cr1,1f
+ addi r4,r4,-1
+ add r7,r7,r9
1: std r4,TSPC64_TV_SEC(r11)
std r7,TSPC64_TV_NSEC(r11)
@@ -181,7 +188,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-14 11:06:58.000000000 +1100
+++ linux-work/arch/powerpc/kernel/vdso32/datapage.S 2005-11-14 11:07:11.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-14 11:06:58.000000000 +1100
+++ linux-work/arch/powerpc/kernel/vdso64/datapage.S 2005-11-14 11:07:11.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)
Index: linux-work/include/asm-powerpc/vdso_datapage.h
===================================================================
--- linux-work.orig/include/asm-powerpc/vdso_datapage.h 2005-11-14 10:42:00.000000000 +1100
+++ linux-work/include/asm-powerpc/vdso_datapage.h 2005-11-14 11:52:12.000000000 +1100
@@ -73,7 +73,7 @@
/* those additional ones don't have to be located anywhere
* special as they were not part of the original systemcfg
*/
- __s64 wtom_clock_sec; /* Wall to monotonic clock */
+ __s32 wtom_clock_sec; /* Wall to monotonic clock */
__s32 wtom_clock_nsec;
__u32 syscall_map_64[SYSCALL_MAP_SIZE]; /* map of syscalls */
__u32 syscall_map_32[SYSCALL_MAP_SIZE]; /* map of syscalls */
Index: linux-work/arch/powerpc/platforms/powermac/time.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/powermac/time.c 2005-11-01 14:13:53.000000000 +1100
+++ linux-work/arch/powerpc/platforms/powermac/time.c 2005-11-14 14:28:10.000000000 +1100
@@ -102,7 +102,7 @@
static unsigned long cuda_get_time(void)
{
struct adb_request req;
- unsigned long now;
+ unsigned int now;
if (cuda_request(&req, NULL, 2, CUDA_PACKET, CUDA_GET_TIME) < 0)
return 0;
@@ -113,7 +113,7 @@
req.reply_len);
now = (req.reply[3] << 24) + (req.reply[4] << 16)
+ (req.reply[5] << 8) + req.reply[6];
- return now - RTC_OFFSET;
+ return ((unsigned long)now) - RTC_OFFSET;
}
#define cuda_get_rtc_time(tm) to_rtc_time(cuda_get_time(), (tm))
@@ -146,7 +146,7 @@
static unsigned long pmu_get_time(void)
{
struct adb_request req;
- unsigned long now;
+ unsigned int now;
if (pmu_request(&req, NULL, 1, PMU_READ_RTC) < 0)
return 0;
@@ -156,7 +156,7 @@
req.reply_len);
now = (req.reply[0] << 24) + (req.reply[1] << 16)
+ (req.reply[2] << 8) + req.reply[3];
- return now - RTC_OFFSET;
+ return ((unsigned long)now) - RTC_OFFSET;
}
#define pmu_get_rtc_time(tm) to_rtc_time(pmu_get_time(), (tm))
^ permalink raw reply
* Re: Linuv 2.6.15-rc1
From: Jesper Juhl @ 2005-11-14 1:04 UTC (permalink / raw)
To: Michael Buesch; +Cc: Linus Torvalds, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <200511122237.17157.mbuesch@freenet.de>
On 11/12/05, Michael Buesch <mbuesch@freenet.de> 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=3Dpowerpc
> >
> > and build everything that way (including the "config" phase)?
>
> I did
> make mrproper
> copy the .config over again
are you not missing a "make oldconfig" step here?
> make ARCH=3Dpowerpc menuconfig
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
^ permalink raw reply
* Re: [PATCH] ppc64: Thermal control for SMU based machines
From: Benjamin Herrenschmidt @ 2005-11-13 21:00 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux/PPC Development, Linux Kernel Development
In-Reply-To: <Pine.LNX.4.62.0511131845230.17491@numbat.sonytel.be>
> > --- a/drivers/macintosh/Kconfig
> > +++ b/drivers/macintosh/Kconfig
> > @@ -169,6 +169,25 @@ config THERM_PM72
> > This driver provides thermostat and fan control for the desktop
> > G5 machines.
> >
> > +config WINDFARM
> > + tristate "New PowerMac thermal control infrastructure"
>
> Shouldn't this depend on some PowerMac-related variables, to prevent it from
> showing up on m68k?
Well, the windfarm core is not really platform specific at all ...
Christoph even proposed to move it to some more "common" place, though
as I said, I want to work on it a bit more before that happens.
Ben.
^ permalink raw reply
* Re: Linuv 2.6.15-rc1
From: Benjamin Herrenschmidt @ 2005-11-13 20:59 UTC (permalink / raw)
To: Kumar Gala
Cc: ppc-dev list, Linus Torvalds, Michael Buesch,
Linux Kernel Mailing List
In-Reply-To: <71C11A0C-4FC8-4081-A890-A4FF7DA48752@kernel.crashing.org>
On Sun, 2005-11-13 at 10:37 -0600, Kumar Gala wrote:
> Can we please add some defconfigs for arch/powerpc to possibly help
> with this issue. I'm think a pmac32, pmac64, and whatever other 64
> bit configs would be a good start.
The 64 bits defconfigs are there already. I'll do a pmac one.
Ben.
^ permalink raw reply
* Re: [PATCH] ppc64: Thermal control for SMU based machines
From: Geert Uytterhoeven @ 2005-11-13 17:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras
Cc: Linux/PPC Development, Linux Kernel Development
In-Reply-To: <200511080502.jA852dWI011502@hera.kernel.org>
On Mon, 7 Nov 2005, Linux Kernel Mailing List wrote:
> tree d3f63b3ea80790c2f29ea435781c1331f17d269e
> parent 7d49697ef92bd2cf84ab53bd4cea82fefb197fb9
> author Benjamin Herrenschmidt <benh@kernel.crashing.org> Mon, 07 Nov 2005 16:08:17 +1100
> committer Paul Mackerras <paulus@samba.org> Tue, 08 Nov 2005 11:17:56 +1100
>
> [PATCH] ppc64: Thermal control for SMU based machines
>
> This adds a new thermal control framework for PowerMac, along with the
> implementation for PowerMac8,1, PowerMac8,2 (iMac G5 rev 1 and 2), and
> PowerMac9,1 (latest single CPU desktop). In the future, I expect to move
> the older G5 thermal control to the new framework as well.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> --- a/drivers/macintosh/Kconfig
> +++ b/drivers/macintosh/Kconfig
> @@ -169,6 +169,25 @@ config THERM_PM72
> This driver provides thermostat and fan control for the desktop
> G5 machines.
>
> +config WINDFARM
> + tristate "New PowerMac thermal control infrastructure"
Shouldn't this depend on some PowerMac-related variables, to prevent it from
showing up on m68k?
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: Linuv 2.6.15-rc1
From: Kumar Gala @ 2005-11-13 16:37 UTC (permalink / raw)
To: Paul Mackerras
Cc: ppc-dev list, Linus Torvalds, Michael Buesch,
Linux Kernel Mailing List
In-Reply-To: <1131834336.7406.46.camel@gaston>
On Nov 12, 2005, at 4:25 PM, Benjamin Herrenschmidt 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.
Can we please add some defconfigs for arch/powerpc to possibly help
with this issue. I'm think a pmac32, pmac64, and whatever other 64
bit configs would be a good start.
- kumar
^ 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
* 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
* 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: [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: 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: 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: 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: 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: [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
* [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: 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
* 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
* [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: 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
* 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: 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: 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
* 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
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