Hi,
We've been struggling to debug a hang on a large ppc64 box. Every time
we collect oops output there are pieces of the oops output missing and
in some cases entire CPUs are missing.
Eventually I realised the hvc_console driver is dropping characters.
The commit that caused this is:
commit 3
On 03.07.2011, at 11:12, Avi Kivity wrote:
> On 07/03/2011 12:09 PM, Alexander Graf wrote:
>> >
>> > Right. The idea is that if KVM_FLAG_BLAH implies a field
>> > kvm_struct::blah, then either both are present in the headers, or none of
>> > them.
>>
>> Yup, makes sense. I like the idea :).
On 07/04/2011 01:59 PM, Alexander Graf wrote:
On 03.07.2011, at 11:12, Avi Kivity wrote:
> On 07/03/2011 12:09 PM, Alexander Graf wrote:
>> >
>> > Right. The idea is that if KVM_FLAG_BLAH implies a field
kvm_struct::blah, then either both are present in the headers, or none of them.
>>
>
On 04.07.2011, at 13:22, Avi Kivity wrote:
> On 07/04/2011 01:59 PM, Alexander Graf wrote:
>> On 03.07.2011, at 11:12, Avi Kivity wrote:
>>
>> > On 07/03/2011 12:09 PM, Alexander Graf wrote:
>> >> >
>> >> > Right. The idea is that if KVM_FLAG_BLAH implies a field
>> >> kvm_struct::blah, t
On 07/04/2011 02:36 PM, Alexander Graf wrote:
>
> What intermediate steps? We can't add fields to the structure before we get
the extensibility infrastructure, but that's all.
If we add it now without extensibility code, we will have a kernel that only knows the
ioctl with the size as it is
On 04.07.2011, at 13:37, Avi Kivity wrote:
> On 07/04/2011 02:36 PM, Alexander Graf wrote:
>> >
>> > What intermediate steps? We can't add fields to the structure before we
>> > get the extensibility infrastructure, but that's all.
>>
>> If we add it now without extensibility code, we will ha
On Fri, Jul 01, 2011 at 11:37:42AM -0700, Dave Hansen wrote:
> On Wed, 2011-06-29 at 20:21 +1000, Paul Mackerras wrote:
> > +struct kvmppc_pginfo {
> > + unsigned long pfn;
> > + atomic_t refcnt;
> > +};
>
> I only see this refcnt inc'd in one spot and never decremented or read.
> Is the refc
Hello,
On 03.07.2011 01:50, Segher Boessenkool wrote:
+static int u3_ht_root_write_config(struct pci_controller *hose, u8
offset,
+ int len, u32 val)
+{
+ volatile void __iomem *addr;
+
+ addr = hose->cfg_addr + ((offset & ~3) << 2) + (4 - len - (offset
& 3));
+
+ if (offset >= PCI_BASE_ADDRESS_
On Tue, May 24, 2011 at 11:52:23PM +0200, Frederic Weisbecker wrote:
> Migrate conditional hw_breakpoint code compilation under
> the new config to prepare for letting the user chose whether
> or not to build this feature
>
> Signed-off-by: Frederic Weisbecker
> Acked-by: Will Deacon
> Cc: Ingo
On Mon, Jul 04, 2011 at 06:57:46PM +0530, K.Prasad wrote:
> On Tue, May 24, 2011 at 11:52:23PM +0200, Frederic Weisbecker wrote:
> > Migrate conditional hw_breakpoint code compilation under
> > the new config to prepare for letting the user chose whether
> > or not to build this feature
> >
> > Si
On Tue, May 24, 2011 at 11:52:25PM +0200, Frederic Weisbecker wrote:
> The breakpoint support ability in an arch is not related
> to the fact perf events is built or not. HAVE_HW_BREAKPOINT
> only shows an ability so this dependency makes no sense
> anymore. Archs that select HAVE_HW_BREAKPOINT alr
On Mon, Jul 04, 2011 at 07:02:23PM +0530, K.Prasad wrote:
> On Tue, May 24, 2011 at 11:52:25PM +0200, Frederic Weisbecker wrote:
> > The breakpoint support ability in an arch is not related
> > to the fact perf events is built or not. HAVE_HW_BREAKPOINT
> > only shows an ability so this dependency
On Mon, 2011-07-04 at 20:57 +1000, Anton Blanchard wrote:
.../...
> The hypervisor gives us a busy return, so we could retry a number of
> times instead of dropping it on the floor. We'd need to do it in the
> hvc_console driver - the tty drivers share the same backend
> functions so we can't hi
On Mon, Jul 04, 2011 at 11:56:27PM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2011-07-04 at 20:57 +1000, Anton Blanchard wrote:
>
> .../...
>
> > The hypervisor gives us a busy return, so we could retry a number of
> > times instead of dropping it on the floor. We'd need to do it in the
> >
On Mon, Jul 04, 2011 at 03:29:14PM +0200, Frederic Weisbecker wrote:
> On Mon, Jul 04, 2011 at 06:57:46PM +0530, K.Prasad wrote:
> > On Tue, May 24, 2011 at 11:52:23PM +0200, Frederic Weisbecker wrote:
> > > Migrate conditional hw_breakpoint code compilation under
> > > the new config to prepare fo
From: Xu lei
For Freescale eSDHC registers only support 32-bit accesses,
this patch ensure that all Freescale eSDHC register accesses
are 32-bit.
Signed-off-by: Xu lei
Signed-off-by: Roy Zang
Signed-off-by: Kumar Gala
---
drivers/mmc/host/sdhci-of-esdhc.c | 18 ++
1 files c
P4080 eSDHC errata 12 describes incorrect default value of the
the host controller capabilities register.
The default value of the VS18 and VS30 fields in the host controller
capabilities register (HOSTCAPBLT) are incorrect. The default of these bits
should be zero instead of one in the eSDHC logi
From: Xu lei
When esdhc module was enabled in p5020, there were following errors:
mmc0: Timeout waiting for hardware interrupt.
mmc0: error -110 whilst initialising SD card
mmc0: Unexpected interrupt 0x0200.
mmc0: Timeout waiting for hardware interrupt.
mmc0: error -110 whilst initialising S
On Mon, Jul 4, 2011 at 9:24 AM, Hendrik Brueckner
wrote:
> I will check this again for my hvc_iucv back-end. Meanwhile a found
> an old thread discussing the same issue. It covers some differences
> between console and ttys which actually does not matter for hvc-backend
> because of the shared
From: Dave Kleikamp
The 44x code (which is shared by 47x) assumes the available physical memory
begins at 0x. This is not necessarily the case in an AMP
environment.
Support CONFIG_RELOCATABLE for 476 in order to allow the kernel to be
loaded into a higher memory range.
Signed-off-by:
From: Dave Kleikamp
Since other OS's may be running on the other cores don't use tlbivax
Signed-off-by: Dave Kleikamp
Signed-off-by: Tony Breeds
Cc: Benjamin Herrenschmidt
Cc: Josh Boyer
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/include/asm/mmu.h |7 ++-
arch/powerpc/kernel
From: Dave Kleikamp
For AMP, different kernel instances load into separate memory regions.
Read the start of memory from the device tree and limit the memory to what's
specified in the device tree.
Signed-off-by: Dave Kleikamp
Signed-off-by: Tony Breeds
Cc: Benjamin Herrenschmidt
Cc: Josh Boy
On 32bit platforms that support >= 4GB memory total_ram was truncated.
This creates a confusing printk:
Top of RAM: 0x1, Total RAM: 0x0
Fix that:
Top of RAM: 0x1, Total RAM: 0x1
Signed-off-by: Tony Breeds
---
arch/powerpc/mm/mem.c |4 ++--
1 files chan
We check for timeout expiry in the outer loop, but we also need to
check it in the inner loop or we can lock up forever waiting for a
CPU to hit real mode.
Signed-off-by: Anton Blanchard
Cc:
---
Index: linux-powerpc/arch/powerpc/kernel/crash.c
==
On 07/05/11 10:06, Tony Breeds wrote:
From: Dave Kleikamp
The 44x code (which is shared by 47x) assumes the available physical memory
begins at 0x. This is not necessarily the case in an AMP
environment.
Support CONFIG_RELOCATABLE for 476 in order to allow the kernel to be
loaded into
On Tue, 2011-07-05 at 04:17 +, Tabi Timur-B04825 wrote:
> On Mon, Jul 4, 2011 at 9:24 AM, Hendrik Brueckner
> wrote:
>
> > I will check this again for my hvc_iucv back-end. Meanwhile a found
> > an old thread discussing the same issue. It covers some differences
> > between console and ttys
The existing code it pretty ugly. How about we clean it up even more
like this?
From: Anton Blanchard
We check for timeout expiry in the outer loop, but we also need to
check it in the inner loop or we can lock up forever waiting for a
CPU to hit real mode.
Signed-off-by: Anton Blanchard
Sign
27 matches
Mail list logo
