* Re: [PATCH 24/26] KVM: PPC: PV mtmsrd L=0 and mtmsr
From: Segher Boessenkool @ 2010-06-29 7:37 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc@vger.kernel.org
In-Reply-To: <05E77C6E-7465-4A0E-B00B-F1240417281D@suse.de>
>>> There is also a form of mtmsr where all bits need to be
>>> addressed. While the
>>> PPC64 Linux kernel behaves resonably well here, the PPC32 one
>>> never uses the
>>> L=1 form but does mtmsr even for simple things like only changing
>>> EE.
>>
>> You make it sound like the 32-bit kernel does something stupid, while
>> there is no other choice. The "L=1" thing only exists for 64-bit.
>
> Oh, so that's why :). That doesn't really change the fact that it's
> very hard to distinguish between a mtmsr that only changes MSR_EE
> vs one that changes MSR_IR for example :).
Hard to predict for the CPU as well, guess why there is a separate
instruction now :-P
By the way, L=1 _does_ exist for mtmsr; it's just that no 32-bit
"classic"
implementations support it.
Segher
^ permalink raw reply
* Re: [PATCH 11/26] KVM: PPC: Make RMO a define
From: Alexander Graf @ 2010-06-29 7:39 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, KVM list, kvm-ppc@vger.kernel.org
In-Reply-To: <07830DA6-1B53-4E84-A0E2-8449289C71F1@kernel.crashing.org>
On 29.06.2010, at 09:32, Segher Boessenkool wrote:
>>>> On PowerPC it's very normal to not support all of the physical RAM =
in real mode.
>>>=20
>>> Oh? Are you referring to "real mode limit", or 32-bit =
implementations with
>>> more than 32 address lines, or something else?
>>=20
>> The former.
>=20
> Okay. In that case, the hypervisor can usually access all of physical
> ram directly, unless it limits itself; and a supervisor gets either
> no real mode access, or all ram, or some part -- whatever the =
hypervisor
> likes.
>=20
> If you access outside of ram, you will most likely get a machine =
check.
> Depends on the implementation (like most things here).
>=20
>>> Either way, RMO is a really bad name for this, since that name is =
already
>>> used for a similar but different concept.
>>=20
>> It's the same concept, no? Not all physical memory is accessible from =
real mode.
>=20
> I think you're looking for "real mode limit":
>=20
> The concept is called "offset real mode".
>=20
> RMO ("real mode offset") is the value that is ORed to an effective =
address
> to make the physical address (not added, "offset" is a pretty bad =
name).
> RML ("real mode limit") is the value that has to be bigger than the =
effective
> address or you will get an exception.
> RMA ("real mode area") is the name for the range of addresses usable =
in offset
> real mode.
>=20
>>> Also, it seems you construct the physical address by masking out =
bits from
>>> the effective address. Most implementations will trap or machine =
check if
>>> you address outside of physical address space, instead.
>>=20
>> Well the only case where I remember to have hit a real RMO case is on =
the PS3 - that issues a data/instruction storage interrupt when =
accessing anything > 8MB in real mode.
>>=20
>> So I'd argue this is heavily implementation specific.
>=20
> It is. So what is the behaviour you want to implement?
The one below.
>=20
>> Apart from that what I'm trying to cover is that on ppc64 accessing =
0xc0000000000000 in real mode gets you 0x0. Is there a better name for =
this?
>=20
> (You missed two zeroes).
> In hypervisor real mode, the top few bits are magic. They are used =
for e.g.
> enabling hypervisor offset real mode.
> In supervisor real mode, those bits are ignored (and all other bits =
that do
> not correspond to physical address lines may also be ignored).
So which bits exactly are reserved? I couldn't find a reference to that =
part.
> Maybe you want to call it physical_address_mask or similar?
PAM - doesn't sound bad :).
Alex
^ permalink raw reply
* Re: [PATCH 11/26] KVM: PPC: Make RMO a define
From: Segher Boessenkool @ 2010-06-29 7:52 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc@vger.kernel.org
In-Reply-To: <182AF505-54A6-4F71-AF5D-7CA40D911C35@suse.de>
>>>> Also, it seems you construct the physical address by masking out
>>>> bits from
>>>> the effective address. Most implementations will trap or
>>>> machine check if
>>>> you address outside of physical address space, instead.
>>>
>>> Well the only case where I remember to have hit a real RMO case
>>> is on the PS3 - that issues a data/instruction storage interrupt
>>> when accessing anything > 8MB in real mode.
>>>
>>> So I'd argue this is heavily implementation specific.
>>
>> It is. So what is the behaviour you want to implement?
>
> The one below.
I'm sorry, I lost it. "Below"?
>>> Apart from that what I'm trying to cover is that on ppc64
>>> accessing 0xc0000000000000 in real mode gets you 0x0. Is there a
>>> better name for this?
>>
>> (You missed two zeroes).
>> In hypervisor real mode, the top few bits are magic. They are
>> used for e.g.
>> enabling hypervisor offset real mode.
>> In supervisor real mode, those bits are ignored (and all other
>> bits that do
>> not correspond to physical address lines may also be ignored).
>
> So which bits exactly are reserved? I couldn't find a reference to
> that part.
If by "reserved" you mean "cannot be used for addressing", it's the
top four
bits. Book III-S chapter 5.7.3 in the Power Architecture 2.06 document.
Implementations are allowed to ignore more bits than that.
I believe in earlier versions of the architecture it was the top two
bits,
not four, but maybe I misremember.
>> Maybe you want to call it physical_address_mask or similar?
>
> PAM - doesn't sound bad :).
And miraculously nothing in the Power arch uses that acronym yet! But I
would spell it out if I were you, acronyms are confusing.
Segher
^ permalink raw reply
* machine check in kernel for a mpc870 board
From: Shawn Jin @ 2010-06-29 7:59 UTC (permalink / raw)
To: ppcdev
I'm porting a mpc870 board to the powerpc arch. The base is the
adder-875 board. My first try to boot the cuImage.my870 is
experiencing a machine check. And I have no clue where to look. Any
help?
=> bootm 1000000
## Booting image at 01000000 ...
Image Name: Linux-2.6.33.5
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 747319 Bytes = 729.8 kB
Load Address: 00400000
Entry Point: 004004d4
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Bus Fault @ 0x00404c40, fixup 0x00000000
Machine check in kernel mode.
Caused by (from msr): regs 07d1cb80 Unknown values in msr
NIP: 00404C40 XER: 00000000 LR: 00404C24 REGS: 07d1cb80 TRAP: 0200 DAR: 00000001
MSR: 00001002 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
GPR00: 00404D50 07D1CC70 00000000 00000004 007FFF0C 00000001 0040AAB8 726F6F74
GPR08: 3D2F6465 0059D958 FF0009C0 0059DDDC FF003C00 1014BAC4 07FFF000 00000001
GPR16: 007FFF0D 004004D4 00000001 007FFF00 07FF9D78 FFFFFFFF 00000000 07D5D2A0
GPR24: 007FFEC0 00800000 00000000 00000000 00000000 0059D958 004129BC 00000000
Call backtrace:
machine check
Thanks alot,
-Shawn.
^ permalink raw reply
* Re: [PATCH 11/26] KVM: PPC: Make RMO a define
From: Alexander Graf @ 2010-06-29 8:04 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, KVM list, kvm-ppc@vger.kernel.org
In-Reply-To: <1550A5F0-3A22-48ED-8251-96328E2FEAE3@kernel.crashing.org>
On 29.06.2010, at 09:52, Segher Boessenkool wrote:
>>>>> Also, it seems you construct the physical address by masking out =
bits from
>>>>> the effective address. Most implementations will trap or machine =
check if
>>>>> you address outside of physical address space, instead.
>>>>=20
>>>> Well the only case where I remember to have hit a real RMO case is =
on the PS3 - that issues a data/instruction storage interrupt when =
accessing anything > 8MB in real mode.
>>>>=20
>>>> So I'd argue this is heavily implementation specific.
>>>=20
>>> It is. So what is the behaviour you want to implement?
>>=20
>> The one below.
>=20
> I'm sorry, I lost it. "Below"?
Well, the ones a few lines below :).
>=20
>>>> Apart from that what I'm trying to cover is that on ppc64 accessing =
0xc0000000000000 in real mode gets you 0x0. Is there a better name for =
this?
>>>=20
>>> (You missed two zeroes).
>>> In hypervisor real mode, the top few bits are magic. They are used =
for e.g.
>>> enabling hypervisor offset real mode.
>>> In supervisor real mode, those bits are ignored (and all other bits =
that do
>>> not correspond to physical address lines may also be ignored).
>>=20
>> So which bits exactly are reserved? I couldn't find a reference to =
that part.
>=20
> If by "reserved" you mean "cannot be used for addressing", it's the =
top four
> bits. Book III-S chapter 5.7.3 in the Power Architecture 2.06 =
document.
> Implementations are allowed to ignore more bits than that.
>=20
> I believe in earlier versions of the architecture it was the top two =
bits,
> not four, but maybe I misremember.
Ah, nice. So that part is implementation specific too. Awesome ;).
>=20
>>> Maybe you want to call it physical_address_mask or similar?
>>=20
>> PAM - doesn't sound bad :).
>=20
> And miraculously nothing in the Power arch uses that acronym yet! But =
I
> would spell it out if I were you, acronyms are confusing.
Well, the bad thing about not using acronyms here is that I'll run out =
of the 80 character limit pretty soon. And that means line wraps and =
more confusingness when reading the code.
Alex
^ permalink raw reply
* Re: machine check in kernel for a mpc870 board
From: Joakim Tjernlund @ 2010-06-29 8:06 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcdev
In-Reply-To: <AANLkTinA2ghLxBU41aFAsLM1oXQ8HMASx1eQMDVvi56n@mail.gmail.com>
> From: Shawn Jin <shawnxjin@gmail.com>
>
> I'm porting a mpc870 board to the powerpc arch. The base is the
> adder-875 board. My first try to boot the cuImage.my870 is
> experiencing a machine check. And I have no clue where to look. Any
> help?
>
> => bootm 1000000
> ## Booting image at 01000000 ...
> Image Name: Linux-2.6.33.5
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 747319 Bytes = 729.8 kB
> Load Address: 00400000
> Entry Point: 004004d4
Load and Entry Point should probably be 0
Jocke
^ permalink raw reply
* Re: machine check in kernel for a mpc870 board
From: Shawn Jin @ 2010-06-29 8:37 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: ppcdev
In-Reply-To: <OF0E653CF5.2ED4C3A3-ONC1257751.002C6D6E-C1257751.002C903E@transmode.se>
>> =3D> bootm 1000000
>> ## Booting image at 01000000 ...
>> =A0 =A0Image Name: =A0 Linux-2.6.33.5
>> =A0 =A0Image Type: =A0 PowerPC Linux Kernel Image (gzip compressed)
>> =A0 =A0Data Size: =A0 =A0747319 Bytes =3D 729.8 kB
>> =A0 =A0Load Address: 00400000
>> =A0 =A0Entry Point: =A0004004d4
>
> Load and Entry Point should probably be 0
But the cuImage.adder875-uboot image also has the same load address as
mine and the entry point is 0x4004d8. Also cuImage.mpc885ads has the
same load address and entry point as cuImage.adder875-uboot. So I
don't suspect them.
All right. I built a uImage for mpc885ads and the uImage's load
address and entry point are both 0. So this is because I'm using
cuImage instead of uImage.
Thanks Joake, anyway.
-Shawn.
^ permalink raw reply
* [PATCH] powerpc: disable SPARSE_IRQ by default
From: Li Yang @ 2010-06-29 9:32 UTC (permalink / raw)
To: benh, linuxppc-dev
The SPARSE_IRQ considerably adds overhead to critical path of IRQ
handling. However it doesn't benefit much in space for most systems with
limited IRQ_NR. Should be disabled unless really necessary.
Signed-off-by: Li Yang <leoli@freescale.com>
---
arch/powerpc/Kconfig | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 328774b..6506bf4 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -400,7 +400,7 @@ config IRQ_ALL_CPUS
config SPARSE_IRQ
bool "Support sparse irq numbering"
- default y
+ default n
help
This enables support for sparse irqs. This is useful for distro
kernels that want to define a high CONFIG_NR_CPUS value but still
@@ -409,7 +409,7 @@ config SPARSE_IRQ
( Sparse IRQs can also be beneficial on NUMA boxes, as they spread
out the irq_desc[] array in a more NUMA-friendly way. )
- If you don't know what to do here, say Y.
+ If you don't know what to do here, say N.
config NUMA
bool "NUMA support"
--
1.6.6-rc1.GIT
^ permalink raw reply related
* Re: [PATCH 01/26] KVM: PPC: Introduce shared page
From: Alexander Graf @ 2010-06-29 9:54 UTC (permalink / raw)
To: Avi Kivity; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <4C274028.7020105@redhat.com>
Avi Kivity wrote:
> On 06/26/2010 02:24 AM, Alexander Graf wrote:
>> For transparent variable sharing between the hypervisor and guest, I
>> introduce
>> a shared page. This shared page will contain all the registers the
>> guest can
>> read and write safely without exiting guest context.
>>
>> This patch only implements the stubs required for the basic structure
>> of the
>> shared page. The actual register moving follows.
>>
>>
>> @@ -123,8 +123,14 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct
>> kvm *kvm, unsigned int id)
>> if (err)
>> goto free_vcpu;
>>
>> + vcpu->arch.shared = (void*)__get_free_page(GFP_KERNEL|__GFP_ZERO);
>> + if (!vcpu->arch.shared)
>> + goto uninit_vcpu;
>> +
>> return vcpu;
>>
>> +uninit_vcpu:
>> + kvm_vcpu_uninit(vcpu);
>> free_vcpu:
>> kmem_cache_free(kvm_vcpu_cache, vcpu_44x);
>> out:
>> @@ -135,6 +141,7 @@ void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
>> {
>> struct kvmppc_vcpu_44x *vcpu_44x = to_44x(vcpu);
>>
>> + free_page((unsigned long)vcpu->arch.shared);
>> kvm_vcpu_uninit(vcpu);
>> kmem_cache_free(kvm_vcpu_cache, vcpu_44x);
>> }
>> diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
>> index 884d4a5..ba79b35 100644
>> --- a/arch/powerpc/kvm/book3s.c
>> +++ b/arch/powerpc/kvm/book3s.c
>> @@ -1247,6 +1247,10 @@ struct kvm_vcpu
>> *kvmppc_core_vcpu_create(struct kvm *kvm, unsigned int id)
>> if (err)
>> goto free_shadow_vcpu;
>>
>> + vcpu->arch.shared = (void*)__get_free_page(GFP_KERNEL|__GFP_ZERO);
>> + if (!vcpu->arch.shared)
>> + goto uninit_vcpu;
>> +
>> vcpu->arch.host_retip = kvm_return_point;
>> vcpu->arch.host_msr = mfmsr();
>> #ifdef CONFIG_PPC_BOOK3S_64
>> @@ -1277,6 +1281,8 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct
>> kvm *kvm, unsigned int id)
>>
>> return vcpu;
>>
>> +uninit_vcpu:
>> + kvm_vcpu_uninit(vcpu);
>> free_shadow_vcpu:
>> kfree(vcpu_book3s->shadow_vcpu);
>> free_vcpu:
>> @@ -1289,6 +1295,7 @@ void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
>> {
>> struct kvmppc_vcpu_book3s *vcpu_book3s = to_book3s(vcpu);
>>
>> + free_page((unsigned long)vcpu->arch.shared);
>> kvm_vcpu_uninit(vcpu);
>> kfree(vcpu_book3s->shadow_vcpu);
>> vfree(vcpu_book3s);
>> diff --git a/arch/powerpc/kvm/e500.c b/arch/powerpc/kvm/e500.c
>> index e8a00b0..71750f2 100644
>> --- a/arch/powerpc/kvm/e500.c
>> +++ b/arch/powerpc/kvm/e500.c
>> @@ -117,8 +117,14 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct
>> kvm *kvm, unsigned int id)
>> if (err)
>> goto uninit_vcpu;
>>
>> + vcpu->arch.shared = (void*)__get_free_page(GFP_KERNEL|__GFP_ZERO);
>> + if (!vcpu->arch.shared)
>> + goto uninit_tlb;
>> +
>> return vcpu;
>>
>> +uninit_tlb:
>> + kvmppc_e500_tlb_uninit(vcpu_e500);
>> uninit_vcpu:
>> kvm_vcpu_uninit(vcpu);
>> free_vcpu:
>> @@ -131,6 +137,7 @@ void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
>> {
>> struct kvmppc_vcpu_e500 *vcpu_e500 = to_e500(vcpu);
>>
>> + free_page((unsigned long)vcpu->arch.shared);
>> kvmppc_e500_tlb_uninit(vcpu_e500);
>> kvm_vcpu_uninit(vcpu);
>> kmem_cache_free(kvm_vcpu_cache, vcpu_e500);
>>
>
> Code repeats 3x. Share please.
Looking at this again, I could combine the 3 lines of init code into 3
lines of code that do a generic function call and then error checking.
And I could convert the one free_page line with one function call that
would free the page. Is there a real gain behind this?
Alex
^ permalink raw reply
* Re: [PATCH 1/5] microblaze: turn CONFIG_OF into a select
From: Michal Simek @ 2010-06-29 9:57 UTC (permalink / raw)
To: Stephen Rothwell
Cc: microblaze-uclinux, David Miller, Paul Mackerras, sparclinux,
linuxppc-dev, devicetree-discuss
In-Reply-To: <20100629124200.20ca24b7.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> so that we can make CONFIG_OF global and remove it from
> the architecture Kconfig files later.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Michal Simek <monstr@monstr.eu>
> ---
> arch/microblaze/Kconfig | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
> index 76818f9..2b37820 100644
> --- a/arch/microblaze/Kconfig
> +++ b/arch/microblaze/Kconfig
> @@ -17,6 +17,8 @@ config MICROBLAZE
> select HAVE_DMA_ATTRS
> select HAVE_DMA_API_DEBUG
> select TRACING_SUPPORT
> + select OF
> + select OF_FLATTREE
>
> config SWAP
> def_bool n
> @@ -125,8 +127,7 @@ config CMDLINE_FORCE
> override those passed by the boot loader.
>
> config OF
> - def_bool y
> - select OF_FLATTREE
> + bool
>
> config PROC_DEVICETREE
> bool "Support for device tree in /proc"
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
^ permalink raw reply
* Re: [PATCH 5/5] of: remove architecture CONFIG_OF definitions
From: Michal Simek @ 2010-06-29 9:58 UTC (permalink / raw)
To: Stephen Rothwell
Cc: microblaze-uclinux, David Miller, Paul Mackerras, sparclinux,
linuxppc-dev, devicetree-discuss
In-Reply-To: <20100629124701.f879c55c.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> now that CONFIG_OF is defined globally
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Michal Simek <monstr@monstr.eu>
> ---
> arch/microblaze/Kconfig | 3 ---
> arch/powerpc/Kconfig | 3 ---
> arch/sparc/Kconfig | 3 ---
> 3 files changed, 0 insertions(+), 9 deletions(-)
>
> diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
> index 2b37820..1a8f682 100644
> --- a/arch/microblaze/Kconfig
> +++ b/arch/microblaze/Kconfig
> @@ -126,9 +126,6 @@ config CMDLINE_FORCE
> Set this to have arguments from the default kernel command string
> override those passed by the boot loader.
>
> -config OF
> - bool
> -
> config PROC_DEVICETREE
> bool "Support for device tree in /proc"
> depends on PROC_FS
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 3697231..402f4c0 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -174,9 +174,6 @@ config ARCH_MAY_HAVE_PC_FDC
> config PPC_OF
> def_bool y
>
> -config OF
> - bool
> -
> config PPC_UDBG_16550
> bool
> default n
> diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
> index d02e8ac..13a9f2f 100644
> --- a/arch/sparc/Kconfig
> +++ b/arch/sparc/Kconfig
> @@ -149,9 +149,6 @@ config GENERIC_GPIO
> config ARCH_NO_VIRT_TO_BUS
> def_bool y
>
> -config OF
> - bool
> -
> config ARCH_SUPPORTS_DEBUG_PAGEALLOC
> def_bool y if SPARC64
>
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
^ permalink raw reply
* Re: [PATCH 01/26] KVM: PPC: Introduce shared page
From: Avi Kivity @ 2010-06-29 10:55 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <4C29C2E1.4000706@suse.de>
On 06/29/2010 12:54 PM, Alexander Graf wrote:
>
>> Code repeats 3x. Share please.
>>
> Looking at this again, I could combine the 3 lines of init code into 3
> lines of code that do a generic function call and then error checking.
> And I could convert the one free_page line with one function call that
> would free the page. Is there a real gain behind this?
>
>
Looks marginal, yes. It will help if initialization is expanded later,
but currently it doesn't help much.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* RE: [PATCH]460EX on-chip SATA driver<kernel 2.6.33><resubmission>
From: Rupjyoti Sarmah @ 2010-06-29 12:20 UTC (permalink / raw)
To: Marek Vasut, Rupjyoti Sarmah
Cc: linux-ide, sr, jgarzik, linux-kernel, linuxppc-dev
In-Reply-To: <201006290333.50673.marek.vasut@gmail.com>
Hi,
Thanks for your feedback. I submitted an updated version of this patch
later.
I tried to limit the lines within 80 characters.
Regards,
Rup
-----Original Message-----
From: Marek Vasut [mailto:marek.vasut@gmail.com]
Sent: Tuesday, June 29, 2010 7:04 AM
To: Rupjyoti Sarmah
Cc: linux-ide@vger.kernel.org; linux-kernel@vger.kernel.org;
jgarzik@pobox.com; sr@denx.de; linuxppc-dev@ozlabs.org
Subject: Re: [PATCH]460EX on-chip SATA driver<kernel 2.6.33><resubmission>
Dne P=C3=A1 4. =C4=8Dervna 2010 14:26:17 Rupjyoti Sarmah napsal(a):
> This patch enables the on-chip DWC SATA controller of the AppliedMicro
> processor 460EX.
>
> Signed-off-by: Rupjyoti Sarmah <rsarmah@appliedmicro.com>
> Signed-off-by: Mark Miesfeld <mmiesfeld@appliedmicro.com>
> Signed-off-by: Prodyut Hazarika <phazarika@appliedmicro.com>
>
--SNIP--
> + dev_err(ap->dev, "%s: Command not pending cmd_issued=3D%d "
> + "(tag=3D%d) DMA NOT started\n", __func__,
> + hsdevp->cmd_issued[tag], tag);
Just a nitpick, but don't break strings if possible.
^ permalink raw reply
* Re: [PATCH]460EX on-chip SATA driver<kernel 2.6.33><resubmission>
From: Anton Vorontsov @ 2010-06-29 12:44 UTC (permalink / raw)
To: Marek Vasut
Cc: linuxppc-dev, Rupjyoti Sarmah, linux-kernel, linux-ide, sr,
jgarzik
In-Reply-To: <201006290333.50673.marek.vasut@gmail.com>
On Tue, Jun 29, 2010 at 03:33:50AM +0200, Marek Vasut wrote:
> Dne Pá 4. června 2010 14:26:17 Rupjyoti Sarmah napsal(a):
> > This patch enables the on-chip DWC SATA controller of the AppliedMicro
> > processor 460EX.
> >
> > Signed-off-by: Rupjyoti Sarmah <rsarmah@appliedmicro.com>
> > Signed-off-by: Mark Miesfeld <mmiesfeld@appliedmicro.com>
> > Signed-off-by: Prodyut Hazarika <phazarika@appliedmicro.com>
> >
>
> --SNIP--
>
> > + dev_err(ap->dev, "%s: Command not pending cmd_issued=%d "
> > + "(tag=%d) DMA NOT started\n", __func__,
> > + hsdevp->cmd_issued[tag], tag);
>
> Just a nitpick, but don't break strings if possible.
Note that in this particular case breaking strings was OK, and
was actually done in a clever manner.
That is, I doubt that anyone grep for error messages with
regexps, so grep "Command not pending" or grep "DMA NOT started"
would work.
This makes the code more readable (literally, because you don't
have to scroll to see dev_err's arguments) without sacrificing
grep'ability.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Add generic hpte management functions
From: Alexander Graf @ 2010-06-29 12:56 UTC (permalink / raw)
To: Avi Kivity; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <4C286770.6010204@redhat.com>
Avi Kivity wrote:
> On 06/28/2010 11:55 AM, Alexander Graf wrote:
>>
>>>> +
>>>> +static inline u64 kvmppc_mmu_hash_pte(u64 eaddr) {
>>>> + return hash_64(eaddr>> PTE_SIZE, HPTEG_HASH_BITS_PTE);
>>>> +}
>>>> +
>>>> +static inline u64 kvmppc_mmu_hash_vpte(u64 vpage) {
>>>> + return hash_64(vpage& 0xfffffffffULL, HPTEG_HASH_BITS_VPTE);
>>>> +}
>>>> +
>>>> +static inline u64 kvmppc_mmu_hash_vpte_long(u64 vpage) {
>>>> + return hash_64((vpage& 0xffffff000ULL)>> 12,
>>>> + HPTEG_HASH_BITS_VPTE_LONG);
>>>> +}
>>>>
>>>>
>>> Still with the wierd coding style?
>>>
>> Not sure what's going on there. My editor displays it normally. Weird.
>>
>
> Try hitting 'save'.
hexdump -C on the respective section in the exact patch file I submitted
above shows:
00000a80 75 72 6e 20 68 61 73 68 5f 36 34 28 65 61 64 64 |urn
hash_64(eadd|
00000a90 72 20 3e 3e 20 50 54 45 5f 53 49 5a 45 2c 20 48 |r >>
PTE_SIZE, H|
Maybe your mail client breaks it?
Alex
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Add generic hpte management functions
From: Avi Kivity @ 2010-06-29 13:05 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <4C29ED94.6060904@suse.de>
On 06/29/2010 03:56 PM, Alexander Graf wrote:
> Avi Kivity wrote:
>
>> On 06/28/2010 11:55 AM, Alexander Graf wrote:
>>
>>>
>>>>> +
>>>>> +static inline u64 kvmppc_mmu_hash_pte(u64 eaddr) {
>>>>> + return hash_64(eaddr>> PTE_SIZE, HPTEG_HASH_BITS_PTE);
>>>>> +}
>>>>> +
>>>>> +static inline u64 kvmppc_mmu_hash_vpte(u64 vpage) {
>>>>> + return hash_64(vpage& 0xfffffffffULL, HPTEG_HASH_BITS_VPTE);
>>>>> +}
>>>>> +
>>>>> +static inline u64 kvmppc_mmu_hash_vpte_long(u64 vpage) {
>>>>> + return hash_64((vpage& 0xffffff000ULL)>> 12,
>>>>> + HPTEG_HASH_BITS_VPTE_LONG);
>>>>> +}
>>>>>
>>>>>
>>>>>
>>>> Still with the wierd coding style?
>>>>
>>>>
>>> Not sure what's going on there. My editor displays it normally. Weird.
>>>
>>>
>> Try hitting 'save'.
>>
> hexdump -C on the respective section in the exact patch file I submitted
> above shows:
>
> 00000a80 75 72 6e 20 68 61 73 68 5f 36 34 28 65 61 64 64 |urn
> hash_64(eadd|
> 00000a90 72 20 3e 3e 20 50 54 45 5f 53 49 5a 45 2c 20 48 |r>>
> PTE_SIZE, H|
>
>
> Maybe your mail client breaks it?
>
The list archives too:
http://www.mail-archive.com/kvm@vger.kernel.org/msg37093.html
Looks like a cache coherency bug. What processor are you using?
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Add generic hpte management functions
From: Alexander Graf @ 2010-06-29 13:06 UTC (permalink / raw)
To: Avi Kivity; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <4C29EF8A.4070508@redhat.com>
Avi Kivity wrote:
> On 06/29/2010 03:56 PM, Alexander Graf wrote:
>> Avi Kivity wrote:
>>
>>> On 06/28/2010 11:55 AM, Alexander Graf wrote:
>>>
>>>>
>>>>>> +
>>>>>> +static inline u64 kvmppc_mmu_hash_pte(u64 eaddr) {
>>>>>> + return hash_64(eaddr>> PTE_SIZE, HPTEG_HASH_BITS_PTE);
>>>>>> +}
>>>>>> +
>>>>>> +static inline u64 kvmppc_mmu_hash_vpte(u64 vpage) {
>>>>>> + return hash_64(vpage& 0xfffffffffULL, HPTEG_HASH_BITS_VPTE);
>>>>>> +}
>>>>>> +
>>>>>> +static inline u64 kvmppc_mmu_hash_vpte_long(u64 vpage) {
>>>>>> + return hash_64((vpage& 0xffffff000ULL)>> 12,
>>>>>> + HPTEG_HASH_BITS_VPTE_LONG);
>>>>>> +}
>>>>>>
>>>>>>
>>>>>>
>>>>> Still with the wierd coding style?
>>>>>
>>>>>
>>>> Not sure what's going on there. My editor displays it normally. Weird.
>>>>
>>>>
>>> Try hitting 'save'.
>>>
>> hexdump -C on the respective section in the exact patch file I submitted
>> above shows:
>>
>> 00000a80 75 72 6e 20 68 61 73 68 5f 36 34 28 65 61 64 64 |urn
>> hash_64(eadd|
>> 00000a90 72 20 3e 3e 20 50 54 45 5f 53 49 5a 45 2c 20 48 |r>>
>> PTE_SIZE, H|
>>
>>
>> Maybe your mail client breaks it?
>>
>
> The list archives too:
>
> http://www.mail-archive.com/kvm@vger.kernel.org/msg37093.html
>
> Looks like a cache coherency bug. What processor are you using?
Are we looking at the same link? Looks good to me there.
Alex
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Add generic hpte management functions
From: Avi Kivity @ 2010-06-29 13:13 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <4C29EFCC.3030303@suse.de>
On 06/29/2010 04:06 PM, Alexander Graf wrote:
>
> Are we looking at the same link? Looks good to me there.
>
>
We're probably looking at the same link but looking at different
things. I'm whining about
static u64 f() {
...
}
as opposed to the more sober
static u64 f()
{
...
}
for f in [kvmppc_mmu_hash_pte, kvmppc_mmu_hash_vpte,
kvmppc_mmu_hash_vpte_long].
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH] sched: fix spelling of sibling
From: David Howells @ 2010-06-29 14:14 UTC (permalink / raw)
To: Michael Neuling; +Cc: Peter Zijlstra, Ingo Molnar, linux-kernel, linuxppc-dev
In-Reply-To: <15249.1277776921@neuling.org>
Michael Neuling <mikey@neuling.org> wrote:
> No logic changes, only spelling.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
Acked-by: David Howells <dhowells@redhat.com>
^ permalink raw reply
* ftp login problem using wu-ftpd
From: Stevan Ignjatovic @ 2010-06-29 14:16 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I ported Linux-2.6.30-rc8 on my custom mpc885 board. The filesystem I am
using is jffs2 which I created from
eldk-4.2/ppc_8xx/images/ramdisk_image.gz. Linux boots fine and I can
telnet to the board but I cannot ftp:
# ftp 10.8.1.5
Connected to 10.8.1.5.
220 10.8.1.5 FTP server (Version wu-2.6.2(1) Wed Apr 2 09:10:49 MEST
2008) ready.
530 Please login with USER and PASS.
530 Please login with USER and PASS.
KERBEROS_V4 rejected as an authentication type
Name (10.8.1.5:root): root
Here ftp connection hangs. Do I have to create another user (beside
root) in order to make ftp connection? Earlier, when I was using 2.4
linux I didn't have problems with ftp connection as root.
/etc/ftpaccess:
class all real,guest,anonymous *
email root@localhost
loginfails 5
readme README* login
readme README* cwd=*
message /welcome.msg login
message .message cwd=*
compress yes all
tar yes all
chmod no guest,anonymous
delete no guest,anonymous
overwrite no guest,anonymous
rename no guest,anonymous
log transfers anonymous,real inbound,outbound
shutdown /etc/shutmsg
passwd-check rfc822 warn
/etc/xinetd.d/wu-ftpd:
# default: on
# description: The wu-ftpd FTP server serves FTP connections. It uses \
# normal, unencrypted usernames and passwords for authentication.
service ftp
{
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.ftpd
server_args = -l -a
log_on_success += DURATION USERID
log_on_failure += USERID
nice = 10
disable = no
}
/etc/pam.d/ftp:
#%PAM-1.0
auth include system-auth
auth required /lib/security/pam_listfile.so item=user sense=deny
file=/etc/ftpusers onerr=succeed
auth required /lib/security/pam_shells.so
account include system-auth
session include system-auth
Thanks in advance.
^ permalink raw reply
* kernel init exception
From: wilbur.chan @ 2010-06-29 15:21 UTC (permalink / raw)
To: linuxppc-dev
We are porting linux 2.6.21.7 to a powerpc e500mc board , p4080.
But something is wrong when loading init file:
log:
free init memory...
init has generated signal 4 but has no handler for it
I found it print in _exception --->
if (is_init(current)) {
if (handler == SIG_DFL) {
printk(KERN_CRIT "init has generated signal %d "
"but has no handler for it\n", signr);
do_exit(signr);
}
}
why there generated a signal 4 in init process?
Thanks
^ permalink raw reply
* RE: Using devices trees on X86
From: Stephen Neuendorffer @ 2010-06-29 15:56 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Michal Simek, microblaze-uclinux, devicetree-discuss,
Paul Mackerras, sparclinux, linuxppc-dev, David Miller
In-Reply-To: <20100629123843.5f94d477.sfr@canb.auug.org.au>
> -----Original Message-----
> From: Stephen Rothwell [mailto:sfr@canb.auug.org.au]
> Sent: Monday, June 28, 2010 7:39 PM
> To: Stephen Neuendorffer
> Cc: grant.likely@secretlab.ca; devicetree-discuss@lists.ozlabs.org;
David Miller;
> sparclinux@vger.kernel.org; Michal Simek;
microblaze-uclinux@itee.uq.edu.au; Benjamin Herrenschmidt;
> Paul Mackerras; linuxppc-dev@lists.ozlabs.org
> Subject: Re: Using devices trees on X86
> =
> Hi Stephen,
> =
> On Mon, 28 Jun 2010 10:57:33 -0700 Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
> >
> > 2) config OF is currently implemented in the architecture code.
This
> > should be non-architecture dependent and selected by the arches that
> > need it.
> >
> > Comments greatly appreciated, in particular if you have
> > likely-to-be-easy-to-get-accepted suggestions for 3), or feel like
> > carefully solving 2) in
> > a way which doesn't bork the existing of-based arches.
> =
> See the following patch set. Parts 1, 2 and 3 could be applied to the
> respective architecture trees as well as Grant's tree to aleviate some
> conflict problems. Part 5 could wait until a later time if necessary.
> However, this is relatively trivial, so we could just collect ACKs and
> put it all in Grant's tree and live with any minor pain.
> =
> Having OF in more than one Kconfig file should not cause any problems
as
> long as they are all the same.
Ah, well, that simplifies things.. :) Thanks!
Steve
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* [PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx
From: Steve Deiters @ 2010-06-29 16:04 UTC (permalink / raw)
To: linuxppc-dev
These processors will corrupt data if accessing the local bus with
unaligned
addresses. This version fixes the typical case of copying from Flash on
the
local bus by keeping the source address always aligned.
Signed-off-by: Steve Deiters <SteveDeiters@basler.com>
---
arch/powerpc/lib/copy_32.S | 56
++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/lib/copy_32.S b/arch/powerpc/lib/copy_32.S
index 74a7f41..42e7df5 100644
--- a/arch/powerpc/lib/copy_32.S
+++ b/arch/powerpc/lib/copy_32.S
@@ -226,6 +226,60 @@ _GLOBAL(memmove)
bgt backwards_memcpy
/* fall through */
=20
+#if defined(CONFIG_PPC_MPC512x) || defined(CONFIG_PPC_MPC52xx)
+
+/*
+ * Alternate memcpy for MPC512x and MPC52xx to guarantee source
+ * address is always aligned to prevent corruption issues when
+ * copying unaligned from the local bus. This only fixes the usage
+ * when copying from the local bus (e.g. Flash) and will not fix
+ * issues copying to the local bus
+ */
+_GLOBAL(memcpy)
+ srwi. r7,r5,3
+ addi r6,r3,-4
+ addi r4,r4,-4
+ beq 2f /* if less than 8 bytes to do */
+ andi. r0,r4,3 /* get src word aligned */
+ mtctr r7
+ bne 5f
+1: lwz r7,4(r4)
+ lwzu r8,8(r4)
+ stw r7,4(r6)
+ stwu r8,8(r6)
+ bdnz 1b
+ andi. r5,r5,7
+2: cmplwi 0,r5,4
+ blt 3f
+ andi. r0,r4,3
+ bne 3f
+ lwzu r0,4(r4)
+ addi r5,r5,-4
+ stwu r0,4(r6)
+3: cmpwi 0,r5,0
+ beqlr
+ mtctr r5
+ addi r4,r4,3
+ addi r6,r6,3
+4: lbzu r0,1(r4)
+ stbu r0,1(r6)
+ bdnz 4b
+ blr
+5: subfic r0,r0,4
+ mtctr r0
+6: lbz r7,4(r4)
+ addi r4,r4,1
+ stb r7,4(r6)
+ addi r6,r6,1
+ bdnz 6b
+ subf r5,r0,r5
+ rlwinm. r7,r5,32-3,3,31
+ beq 2b
+ mtctr r7
+ b 1b
+
+#else
+
_GLOBAL(memcpy)
srwi. r7,r5,3
addi r6,r3,-4
@@ -267,6 +321,8 @@ _GLOBAL(memcpy)
mtctr r7
b 1b
=20
+#endif
+
_GLOBAL(backwards_memcpy)
rlwinm. r7,r5,32-3,3,31 /* r0 =3D r5 >> 3 */
add r6,r3,r5
--=20
1.5.4.3
^ permalink raw reply related
* [RFC Patch 0/1] hw-breakpoint interfaces for BookE - ver II
From: K.Prasad @ 2010-06-29 16:51 UTC (permalink / raw)
To: linuxppc-dev
Hi All,
Please find a new version of the patch that implements generic
hw-breakpoint interfaces for PowerPC BookIII E.
While there are several improvements over the previous version in terms
of code placement, support for ptrace and fixes for incorrect issues, the
patch remains compile-tested (only)(against 44x/iss476-smp_defconfig config)
and is yet to be tested on hardware (for functionality).
Changelog Version II
(Version I:linuxppc-dev message-id: 20100427164029.GA8303@in.ibm.com)
-------------------------------------------------------------------------
- ptrace requests (through PTRACE_SET_DEBUGREG and PTRACE_GET_DEBUGREG) are
now supported.
- Changes in original arch/powerpc/kernel/hw_breakpoint.c have been percolated
down to hw_breakpoint_booke.c (such as introduction of thread_change_pc(),
arch_unregister_hw_breakpoint() and changes to hw_breakpoint_handler())
along with some code re-arrangement (for brevity/clarity).
The usage of CONFIG (in this patch) option doesn't largely represent a
form that it would turn into after enabling the use of DVCs, DACs by non-ptrace
breakpoint requests. They should turn correct as versions of this patch progress.
Kindly let me know your comments.
Thanks,
K.Prasad
^ permalink raw reply
* Re: kernel init exception
From: Segher Boessenkool @ 2010-06-29 16:51 UTC (permalink / raw)
To: wilbur.chan; +Cc: linuxppc-dev
In-Reply-To: <AANLkTimV1AFEUrRf-2iEizXH4HQFMrrAumsRVDKxNfAv@mail.gmail.com>
> why there generated a signal 4 in init process?
That's SIGILL; sounds like you compiled init with the wrong (sub-)arch
or cpu flags.
Segher
^ 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