* Re: INFO: task snmpd:398 blocked for more than 120 seconds.
From: Norbert van Bolhuis @ 2010-11-09 9:47 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev, David Laight
In-Reply-To: <OF068D03E2.B4929626-ONC12577D5.0056CBDF-C12577D5.00571CBD@transmode.se>
Joakim Tjernlund wrote:
>>> I can't make out what is causing this hang every now an then:
>>>
>>> INFO: task snmpd:398 blocked for more than 120 seconds.
>> My problem with that 'error' message is that there is no way
>> for a driver to disable it on a per-process basis.
>> We have some processes whose 'normal state' is to sleep
>> uninterruptibly in the kernel. Shutdown is handled by
>> an explicit request (not by sending a signal).
>> The processes could be kernel worker threads (except that
>> is is ~impossible to handle them exiting from a loadble
>> kernel module) so are actually children of a daemon sat
>> inside an ioctl() request that never terminates!
>>
>> However, on the face of it, your case does look as though
>> the mutex is fubar'ed.
>>
>> Might be worth (somehow) dumping the mutex state.
>
> ehh, it is locked, isn't it? How to find who locked it
> and forgot to release it?
>
You could add show_state to check_hung_task
It worked for me while solving some (application) task hangups.
---
N. van Bolhuis.
^ permalink raw reply
* Re: [PATCH] powerpc: Add jump label support
From: Michael Ellerman @ 2010-11-09 4:02 UTC (permalink / raw)
To: Steven Rostedt
Cc: Stephen Rothwell, Kumar Gala, jbaron, linux-kernel, linuxppc-dev,
Anton Blanchard, David S. Miller
In-Reply-To: <1289274119.12418.79.camel@gandalf.stny.rr.com>
[-- Attachment #1: Type: text/plain, Size: 698 bytes --]
On Mon, 2010-11-08 at 22:41 -0500, Steven Rostedt wrote:
> On Tue, 2010-11-09 at 14:33 +1100, Michael Ellerman wrote:
>
> > > You don't need this protection in a file that is not exported to user
> > > space.
> >
> > Ah true. I'll respin after I've heard if anyone has tested it :)
>
> Don't wait for me. I'm stuck debugging some other crap. Getting a 4.5
> PPC compiler working is very low on my priority list, unfortunately. :-(
No worries, testing is for sissies anyway.
There are 4.5.0 crosses on kernel.org, I think they're the same as the
ones I'm using, which seem to work on powerpc at least.
http://kernel.org/pub/tools/crosstool/files/bin/x86_64/4.5.0/
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Add jump label support
From: Steven Rostedt @ 2010-11-09 3:41 UTC (permalink / raw)
To: michael
Cc: Stephen Rothwell, Kumar Gala, jbaron, linux-kernel, linuxppc-dev,
Anton Blanchard, David S. Miller
In-Reply-To: <1289273608.21111.194.camel@concordia>
On Tue, 2010-11-09 at 14:33 +1100, Michael Ellerman wrote:
> > You don't need this protection in a file that is not exported to user
> > space.
>
> Ah true. I'll respin after I've heard if anyone has tested it :)
Don't wait for me. I'm stuck debugging some other crap. Getting a 4.5
PPC compiler working is very low on my priority list, unfortunately. :-(
-- Steve
^ permalink raw reply
* Re: [PATCH] powerpc: Add jump label support
From: Michael Ellerman @ 2010-11-09 3:33 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Kumar Gala, jbaron, linux-kernel, rostedt, linuxppc-dev,
Anton Blanchard, David S. Miller
In-Reply-To: <20101109133517.b6be28bf.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]
On Tue, 2010-11-09 at 13:35 +1100, Stephen Rothwell wrote:
> Hi Michael,
>
> Just a trivial note ...
>
> On Mon, 8 Nov 2010 15:12:46 +1100 (EST) Michael Ellerman <michael@ellerman.id.au> wrote:
> >
> > diff --git a/arch/powerpc/include/asm/jump_label.h b/arch/powerpc/include/asm/jump_label.h
> > new file mode 100644
> > index 0000000..feffb86
> > --- /dev/null
> > +++ b/arch/powerpc/include/asm/jump_label.h
> > @@ -0,0 +1,46 @@
> > +#ifndef _ASM_POWERPC_JUMP_LABEL_H
> > +#define _ASM_POWERPC_JUMP_LABEL_H
> > +
> > +/*
> > + * Copyright 2010 Michael Ellerman, IBM Corp.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > + * as published by the Free Software Foundation; either version
> > + * 2 of the License, or (at your option) any later version.
> > + */
> > +
> > +#ifdef __KERNEL__
>
> You don't need this protection in a file that is not exported to user
> space.
Ah true. I'll respin after I've heard if anyone has tested it :)
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Add jump label support
From: Michael Ellerman @ 2010-11-09 3:33 UTC (permalink / raw)
To: Steven Rostedt
Cc: Kumar Gala, linux-kernel, David S.Miller, linuxppc-dev,
Anton Blanchard, jbaron
In-Reply-To: <1289225915.12418.2.camel@gandalf.stny.rr.com>
[-- Attachment #1: Type: text/plain, Size: 913 bytes --]
On Mon, 2010-11-08 at 09:18 -0500, Steven Rostedt wrote:
> On Mon, 2010-11-08 at 15:12 +1100, Michael Ellerman wrote:
> > This patch adds support for the new "jump label" feature.
>
> Darn it! I wanted to port this!!!
>
> ;-)
Sorry! I've been locked in a dark room for ages and this was a nice
chance to work on some upstream code for a change :)
> > Built for 64 & 32 bit, tested on 64 bit. Survives a kernel build under
> > perf with all tracepoints enabled, and manual inspection of the patched
> > code looks right. But still, lightly tested, YMMV.
> >
> > Unlike x86 and sparc we just merrily patch the code with no locks etc,
> > as far as I know this is safe, but I'm not really sure what the x86/sparc
> > code is protecting against so maybe it's not.
>
> Thanks, I'll give it a test on my electra as soon as I get a gcc 4.5.1
> cross compiler working.
Thanks.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH] powerpc: Consolidate obj-y assignments
From: Michael Ellerman @ 2010-11-09 3:31 UTC (permalink / raw)
To: linuxppc-dev
No need to have three of them.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/Makefile | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 36c30f3..3bb2a3e 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -29,8 +29,10 @@ endif
obj-y := cputable.o ptrace.o syscalls.o \
irq.o align.o signal_32.o pmc.o vdso.o \
init_task.o process.o systbl.o idle.o \
- signal.o sysfs.o cacheinfo.o
-obj-y += vdso32/
+ signal.o sysfs.o cacheinfo.o time.o \
+ prom.o traps.o setup-common.o \
+ udbg.o misc.o io.o dma.o \
+ misc_$(CONFIG_WORD_SIZE).o vdso32/
obj-$(CONFIG_PPC64) += setup_64.o sys_ppc32.o \
signal_64.o ptrace32.o \
paca.o nvram_64.o firmware.o
@@ -80,9 +82,6 @@ extra-$(CONFIG_FSL_BOOKE) := head_fsl_booke.o
extra-$(CONFIG_8xx) := head_8xx.o
extra-y += vmlinux.lds
-obj-y += time.o prom.o traps.o setup-common.o \
- udbg.o misc.o io.o dma.o \
- misc_$(CONFIG_WORD_SIZE).o
obj-$(CONFIG_PPC32) += entry_32.o setup_32.o
obj-$(CONFIG_PPC64) += dma-iommu.o iommu.o
obj-$(CONFIG_KGDB) += kgdb.o
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] powerpc: Add jump label support
From: Stephen Rothwell @ 2010-11-09 2:35 UTC (permalink / raw)
To: Michael Ellerman
Cc: Kumar Gala, jbaron, linux-kernel, rostedt, linuxppc-dev,
Anton Blanchard, David S. Miller
In-Reply-To: <45fbc3cd7f6ce404d1e25bf01695fb629d86189d.1289189560.git.michael@ellerman.id.au>
[-- Attachment #1: Type: text/plain, Size: 1002 bytes --]
Hi Michael,
Just a trivial note ...
On Mon, 8 Nov 2010 15:12:46 +1100 (EST) Michael Ellerman <michael@ellerman.id.au> wrote:
>
> diff --git a/arch/powerpc/include/asm/jump_label.h b/arch/powerpc/include/asm/jump_label.h
> new file mode 100644
> index 0000000..feffb86
> --- /dev/null
> +++ b/arch/powerpc/include/asm/jump_label.h
> @@ -0,0 +1,46 @@
> +#ifndef _ASM_POWERPC_JUMP_LABEL_H
> +#define _ASM_POWERPC_JUMP_LABEL_H
> +
> +/*
> + * Copyright 2010 Michael Ellerman, IBM Corp.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +
> +#ifdef __KERNEL__
You don't need this protection in a file that is not exported to user
space.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Consolidate obj-y assignments
From: Michael Ellerman @ 2010-11-09 1:25 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev
In-Reply-To: <87y694z3b8.fsf@macbook.be.48ers.dk>
[-- Attachment #1: Type: text/plain, Size: 681 bytes --]
On Mon, 2010-11-08 at 08:23 +0100, Peter Korsgaard wrote:
> >>>>> "Michael" == Michael Ellerman <michael@ellerman.id.au> writes:
>
> Michael> No need to have three of them.
> Michael> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> Michael> ---
> Michael> arch/powerpc/kernel/Makefile | 9 ++++-----
> Michael> 1 files changed, 4 insertions(+), 5 deletions(-)
>
> Michael> - signal.o sysfs.o cacheinfo.o
> Michael> -obj-y += vdso32/
> Michael> + signal.o sysfs.o cacheinfo.o time.o \
> Michael> + time.o prom.o traps.o setup-common.o \
>
> You have time.o twice.
Yeah, it makes the kernel run twice as fast.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH 01/17][trivial] powerpc: Remove unnecessary casts of void ptr returning alloc function return values
From: Jesper Juhl @ 2010-11-08 23:07 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev, trivial, Paul Mackerras
Hi,
The [vk][cmz]alloc(_node) family of functions return void pointers which
it's completely unnecessary/pointless to cast to other pointer types since
that happens implicitly.
This patch removes such casts from arch/powerpc/
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
pgtable_32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index a87ead0..d1833ed 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -78,7 +78,7 @@ pgd_t *pgd_alloc(struct mm_struct *mm)
/* pgdir take page or two with 4K pages and a page fraction otherwise */
#ifndef CONFIG_PPC_4K_PAGES
- ret = (pgd_t *)kzalloc(1 << PGDIR_ORDER, GFP_KERNEL);
+ ret = kzalloc(1 << PGDIR_ORDER, GFP_KERNEL);
#else
ret = (pgd_t *)__get_free_pages(GFP_KERNEL|__GFP_ZERO,
PGDIR_ORDER - PAGE_SHIFT);
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* Re: PowerMac8600 help ...
From: Benjamin Herrenschmidt @ 2010-11-08 22:31 UTC (permalink / raw)
To: kevin diggs; +Cc: Linuxppc-dev
In-Reply-To: <AANLkTiksY8x7XOifU3FAAPpCa_h4oEBmqu_a0vjRE5h5@mail.gmail.com>
On Mon, 2010-11-08 at 10:43 -0600, kevin diggs wrote:
>
> Sorry for the noise but I am having trouble getting the latest kernel
> built for a PowerMac8600 with a 750GX processor card. If this is not
> an appropriate topic for the list please tell me (and hopefully point
> me in the correct direction).
>
> I have narrowed the problem down to the compiler. YDL 4.0 is installed
> on the machine. The stock compiler is 3.3.3. That version can NOT
> build past 2.6.28. I built 3.4.6, (the latest 3 series I could find).
> It can NOT build later kernel versions either. It can build Firefox
> 2.0.0.15pre, including powerpc thin lock support. Running it now.
>
> I then tried 4.3.5. This will build the kernel. But the resulting
> kernel will NOT run. A firefox built with 4.3.5 also will not run. Or
> if it runs it crashes often (http://abcnews.com).
>
> What really puzzles me is I used the same basic compiler boot
> strapping (3.3.3 to build 3.4.6, 3.4.6 to build 4.3.5) on a GiGE. That
> machine is now running 2.6.36.
>
> The CFLAGS used were: "-O2 -mcpu=7450 -mmultiple -mstring" for the
> GiGE (dual 7455s). Substitute 750 for the 8600.
>
> Any suggestions would be appreciated.
This is odd... I wonder if your 8600 is having some memory problems ?
Have you tried using the kernel/firefox built with 4.3.5 on the GigE and
booting them on the 8600 ?
3.x are ancient but I would expect 4.3.x to work just fine
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC PATCH 0/7 v2] ppc: enable dynamic dma window support
From: Nishanth Aravamudan @ 2010-11-08 19:42 UTC (permalink / raw)
To: sonnyrao, miltonm, Benjamin Herrenschmidt, Paul Mackerras,
Grant Likely, linuxppc-dev
In-Reply-To: <1288150518-4026-1-git-send-email-nacc@us.ibm.com>
Hi all,
On 26.10.2010 [20:35:10 -0700], Nishanth Aravamudan wrote:
> The following series, which builds upon the series of cleanups I posted
> on 9/15 and 10/18 as "ppc iommu cleanups", enables the pseries firmware
> feature dynamic dma windows. This feature will allow future devices to
> have a 64-bit DMA mapping covering all memory, coexisting with a smaller
> IOMMU window in 32-bit PCI space
Was ping'ing on this changeset. If there are no objections, I will
repost it without the RFC tag asking Ben to merge it.
Thanks,
Nish
> Changes from v1 to v2:
>
> Fixed numerous bugs/issues found in testing.
> Reworked to be based off platform hook dma_set_mask().
>
> Nishanth Aravamudan (7):
> macio: ensure all dma routines get copied over
> ppc: add memory_hotplug_max
> ppc: do not search for dma-window property on dlpar remove
> ppc: checking for pdn->parent is redundant
> ppc/iommu: do not need to check for dma_window == NULL
> ppc/iommu: pass phb only to iommu_table_setparms_lpar
> ppc: add dynamic dma window support
>
> arch/powerpc/include/asm/device.h | 6 +
> arch/powerpc/include/asm/mmzone.h | 5 +
> arch/powerpc/mm/numa.c | 26 ++
> arch/powerpc/platforms/pseries/iommu.c | 600 ++++++++++++++++++++++++++++++--
> drivers/macintosh/macio_asic.c | 7 +-
> 5 files changed, 619 insertions(+), 25 deletions(-)
>
>
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply
* Re: INFO: task snmpd:398 blocked for more than 120 seconds.
From: Joakim Tjernlund @ 2010-11-08 18:22 UTC (permalink / raw)
Cc: linuxppc-dev
In-Reply-To: <OF5A1033A2.48B05F1F-ONC12577D5.00605774-C12577D5.00606A22@transmode.se>
>
> linuxppc-dev-bounces+joakim.tjernlund=transmode.se@lists.ozlabs.org wrote on 2010/11/08 16:05:30:
>
> > From: Joakim Tjernlund <joakim.tjernlund@transmode.se>
> > To: linuxppc-dev@ozlabs.org
> > Date: 2010/11/08 16:12
> > Subject: INFO: task snmpd:398 blocked for more than 120 seconds.
> > Sent by: linuxppc-dev-bounces+joakim.tjernlund=transmode.se@lists.ozlabs.org
> >
> >
> > I can't make out what is causing this hang every now an then:
> >
> > INFO: task snmpd:398 blocked for more than 120 seconds.
> > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > snmpd D 0fad1760 0 398 1 0x00000000
> > Call Trace:
> > [c7b5fc70] [c7a49a80] 0xc7a49a80 (unreliable)
> > [c7b5fd30] [c0008608] __switch_to+0x4c/0x6c
> > [c7b5fd40] [c028fed4] schedule+0x184/0x310
> > [c7b5fd70] [c0290e5c] __mutex_lock_slowpath+0xa4/0x150
> > [c7b5fdb0] [c0290c50] mutex_lock+0x44/0x48
> > [c7b5fdc0] [c01eb5b0] rtnl_lock+0x18/0x28
> > [c7b5fdd0] [c01df6c4] dev_ioctl+0x2b4/0x764
> > [c7b5fe60] [c01cafc8] sock_ioctl+0x18c/0x2a0
> > [c7b5fe80] [c009a16c] vfs_ioctl+0xcc/0xe0
> > [c7b5fea0] [c009a998] do_vfs_ioctl+0xc4/0x79c
> > [c7b5ff10] [c009b0b0] sys_ioctl+0x40/0x74
> > [c7b5ff40] [c00117c4] ret_from_syscall+0x0/0x38
> >
> > The dev_ioctl is in SIOCGIFCONF:
> > int dev_ioctl(struct net *net, unsigned int cmd, void __user *arg)
> > {
> > struct ifreq ifr;
> > int ret;
> > char *colon;
> >
> > /* One special case: SIOCGIFCONF takes ifconf argument
> > and requires shared lock, because it sleeps writing
> > to user space.
> > */
> >
> > if (cmd == SIOCGIFCONF) {
> > rtnl_lock();
> > ret = dev_ifconf(net, (char __user *) arg);
> > rtnl_unlock();
> > return ret;
> > }
> >
> > Any ideas? Kernel is 2.6.35
>
> I tried PROVE_LOCKING but now my kernel doesn't boot at all :)
>
> Something goes very wrong in arch/powerpc/kernel/prom.c:694
> 694 memblock_reserve(PHYSICAL_START, __pa(klimit) - PHYSICAL_START);
>
> (gdb) print klimit
> $8 = 0xc08c9000
>
> What is klimit and can I do something about it?
>
> kernel 2.6.35 on a mpc8321
That was not quite right, turns out that early_init_devtree(*params)
points to a memory that has been zeroed:
print initial_boot_params
$3 = (struct boot_param_header *) 0xc07fa000
Above matches what u-boot writes:
Booting kernel from Legacy Image at 00200000 ...
Image Name: oskernel02a:p1a:99
Created: 2010-11-08 18:09:28 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1898430 Bytes = 1.8 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 07fdebb0
Booting using the fdt blob at 0x7fdebb0
Uncompressing Kernel Image ... OK
Loading Device Tree to 007fa000, end 007ff327 ... OK
(gdb) print *initial_boot_params
$4 = {magic = 0x0, totalsize = 0x0, off_dt_struct = 0x0, off_dt_strings = 0x0,
off_mem_rsvmap = 0x0, version = 0x0, last_comp_version = 0x0,
boot_cpuid_phys = 0x0, dt_strings_size = 0x0, dt_struct_size = 0x0}
Jocke
^ permalink raw reply
* Re: INFO: task snmpd:398 blocked for more than 120 seconds.
From: Joakim Tjernlund @ 2010-11-08 17:33 UTC (permalink / raw)
Cc: linuxppc-dev
In-Reply-To: <OF385C74E5.E81887CB-ONC12577D5.00527686-C12577D5.0052E6B5@transmode.se>
linuxppc-dev-bounces+joakim.tjernlund=transmode.se@lists.ozlabs.org wrote on 2010/11/08 16:05:30:
> From: Joakim Tjernlund <joakim.tjernlund@transmode.se>
> To: linuxppc-dev@ozlabs.org
> Date: 2010/11/08 16:12
> Subject: INFO: task snmpd:398 blocked for more than 120 seconds.
> Sent by: linuxppc-dev-bounces+joakim.tjernlund=transmode.se@lists.ozlabs.org
>
>
> I can't make out what is causing this hang every now an then:
>
> INFO: task snmpd:398 blocked for more than 120 seconds.
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> snmpd D 0fad1760 0 398 1 0x00000000
> Call Trace:
> [c7b5fc70] [c7a49a80] 0xc7a49a80 (unreliable)
> [c7b5fd30] [c0008608] __switch_to+0x4c/0x6c
> [c7b5fd40] [c028fed4] schedule+0x184/0x310
> [c7b5fd70] [c0290e5c] __mutex_lock_slowpath+0xa4/0x150
> [c7b5fdb0] [c0290c50] mutex_lock+0x44/0x48
> [c7b5fdc0] [c01eb5b0] rtnl_lock+0x18/0x28
> [c7b5fdd0] [c01df6c4] dev_ioctl+0x2b4/0x764
> [c7b5fe60] [c01cafc8] sock_ioctl+0x18c/0x2a0
> [c7b5fe80] [c009a16c] vfs_ioctl+0xcc/0xe0
> [c7b5fea0] [c009a998] do_vfs_ioctl+0xc4/0x79c
> [c7b5ff10] [c009b0b0] sys_ioctl+0x40/0x74
> [c7b5ff40] [c00117c4] ret_from_syscall+0x0/0x38
>
> The dev_ioctl is in SIOCGIFCONF:
> int dev_ioctl(struct net *net, unsigned int cmd, void __user *arg)
> {
> struct ifreq ifr;
> int ret;
> char *colon;
>
> /* One special case: SIOCGIFCONF takes ifconf argument
> and requires shared lock, because it sleeps writing
> to user space.
> */
>
> if (cmd == SIOCGIFCONF) {
> rtnl_lock();
> ret = dev_ifconf(net, (char __user *) arg);
> rtnl_unlock();
> return ret;
> }
>
> Any ideas? Kernel is 2.6.35
I tried PROVE_LOCKING but now my kernel doesn't boot at all :)
Something goes very wrong in arch/powerpc/kernel/prom.c:694
694 memblock_reserve(PHYSICAL_START, __pa(klimit) - PHYSICAL_START);
(gdb) print klimit
$8 = 0xc08c9000
What is klimit and can I do something about it?
kernel 2.6.35 on a mpc8321
^ permalink raw reply
* PowerMac8600 help ...
From: kevin diggs @ 2010-11-08 16:43 UTC (permalink / raw)
To: Linuxppc-dev
Hi,
Sorry for the noise but I am having trouble getting the latest kernel
built for a PowerMac8600 with a 750GX processor card. If this is not
an appropriate topic for the list please tell me (and hopefully point
me in the correct direction).
I have narrowed the problem down to the compiler. YDL 4.0 is installed
on the machine. The stock compiler is 3.3.3. That version can NOT
build past 2.6.28. I built 3.4.6, (the latest 3 series I could find).
It can NOT build later kernel versions either. It can build Firefox
2.0.0.15pre, including powerpc thin lock support. Running it now.
I then tried 4.3.5. This will build the kernel. But the resulting
kernel will NOT run. A firefox built with 4.3.5 also will not run. Or
if it runs it crashes often (http://abcnews.com).
What really puzzles me is I used the same basic compiler boot
strapping (3.3.3 to build 3.4.6, 3.4.6 to build 4.3.5) on a GiGE. That
machine is now running 2.6.36.
The CFLAGS used were: "-O2 -mcpu=7450 -mmultiple -mstring" for the
GiGE (dual 7455s). Substitute 750 for the 8600.
Any suggestions would be appreciated.
Thanks!
kevin
P.S.: Why does this program work:
int main(int argc, char *argv[])
{
unsigned int pvr;
// asm("mfspr %0,22\n"
asm("mfspr %0,287\n"
:"=r" (pvr)
);
printf("pvr is 0x%x\n",pvr);
}
>From what I have read, access to the pvr is restricted? strace does
not show an illegal instruction trap for SPRN_PVR.
^ permalink raw reply
* Better performance when CONFIG_DEBUG_KERNEL is on
From: Jean-Michel Hautbois @ 2010-11-08 16:00 UTC (permalink / raw)
To: linuxppc-dev
Hi everybody,
I am using a mpc5200 chip with a linux 2.6.33.7-rt29.
I am using the ELDK toolchain :
ppc_6xx-gcc -v
Target: powerpc-linux
Configured with:
/opt/eldk/build/ppc-2008-04-01/work/usr/src/denx/BUILD/crosstool-0.43/build/gcc-4.2.2-glibc-20070515T2025-eldk/powerpc-linux/gcc-4.2.2/configure
--target=powerpc-linux --host=i686-host_pc-linux-gnu
--prefix=/var/tmp/eldk.UZpAG7/usr/crosstool/gcc-4.2.2-glibc-20070515T2025-eldk/powerpc-linux
--disable-hosted-libstdcxx
--with-headers=/var/tmp/eldk.UZpAG7/usr/crosstool/gcc-4.2.2-glibc-20070515T2025-eldk/powerpc-linux/powerpc-linux/include
--with-local-prefix=/var/tmp/eldk.UZpAG7/usr/crosstool/gcc-4.2.2-glibc-20070515T2025-eldk/powerpc-linux/powerpc-linux
--disable-nls --enable-threads=posix --enable-symvers=gnu
--enable-__cxa_atexit --enable-languages=c,c++,java --enable-shared
--enable-c99 --enable-long-long --without-x
Thread model: posix
gcc version 4.2.2
When I have the CONFIG_DEBUG_KERNEL flag, the latencies I am mesuring
are better than when the flag is off.
And the jitter is lower...
I must tell I am confused. I have no explanation about that, except
maybe optimisations which would be different when the -g flag is
added...
If any of you has an idea, I am looking forward for your response :).
Thanks in advance,
Best Regards.
JM
^ permalink raw reply
* RE: INFO: task snmpd:398 blocked for more than 120 seconds.
From: Joakim Tjernlund @ 2010-11-08 15:51 UTC (permalink / raw)
To: David Laight; +Cc: linuxppc-dev
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8AB9A@saturn3.aculab.com>
>
> > I can't make out what is causing this hang every now an then:
> >
> > INFO: task snmpd:398 blocked for more than 120 seconds.
>
> My problem with that 'error' message is that there is no way
> for a driver to disable it on a per-process basis.
> We have some processes whose 'normal state' is to sleep
> uninterruptibly in the kernel. Shutdown is handled by
> an explicit request (not by sending a signal).
> The processes could be kernel worker threads (except that
> is is ~impossible to handle them exiting from a loadble
> kernel module) so are actually children of a daemon sat
> inside an ioctl() request that never terminates!
>
> However, on the face of it, your case does look as though
> the mutex is fubar'ed.
>
> Might be worth (somehow) dumping the mutex state.
ehh, it is locked, isn't it? How to find who locked it
and forgot to release it?
Jocke
^ permalink raw reply
* RE: INFO: task snmpd:398 blocked for more than 120 seconds.
From: David Laight @ 2010-11-08 15:19 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <OF385C74E5.E81887CB-ONC12577D5.00527686-C12577D5.0052E6B5@transmode.se>
=20
> I can't make out what is causing this hang every now an then:
>=20
> INFO: task snmpd:398 blocked for more than 120 seconds.
My problem with that 'error' message is that there is no way
for a driver to disable it on a per-process basis.
We have some processes whose 'normal state' is to sleep
uninterruptibly in the kernel. Shutdown is handled by
an explicit request (not by sending a signal).
The processes could be kernel worker threads (except that
is is ~impossible to handle them exiting from a loadble
kernel module) so are actually children of a daemon sat
inside an ioctl() request that never terminates!
However, on the face of it, your case does look as though
the mutex is fubar'ed.
Might be worth (somehow) dumping the mutex state.
David
^ permalink raw reply
* INFO: task snmpd:398 blocked for more than 120 seconds.
From: Joakim Tjernlund @ 2010-11-08 15:05 UTC (permalink / raw)
To: linuxppc-dev
I can't make out what is causing this hang every now an then:
INFO: task snmpd:398 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
snmpd D 0fad1760 0 398 1 0x00000000
Call Trace:
[c7b5fc70] [c7a49a80] 0xc7a49a80 (unreliable)
[c7b5fd30] [c0008608] __switch_to+0x4c/0x6c
[c7b5fd40] [c028fed4] schedule+0x184/0x310
[c7b5fd70] [c0290e5c] __mutex_lock_slowpath+0xa4/0x150
[c7b5fdb0] [c0290c50] mutex_lock+0x44/0x48
[c7b5fdc0] [c01eb5b0] rtnl_lock+0x18/0x28
[c7b5fdd0] [c01df6c4] dev_ioctl+0x2b4/0x764
[c7b5fe60] [c01cafc8] sock_ioctl+0x18c/0x2a0
[c7b5fe80] [c009a16c] vfs_ioctl+0xcc/0xe0
[c7b5fea0] [c009a998] do_vfs_ioctl+0xc4/0x79c
[c7b5ff10] [c009b0b0] sys_ioctl+0x40/0x74
[c7b5ff40] [c00117c4] ret_from_syscall+0x0/0x38
The dev_ioctl is in SIOCGIFCONF:
int dev_ioctl(struct net *net, unsigned int cmd, void __user *arg)
{
struct ifreq ifr;
int ret;
char *colon;
/* One special case: SIOCGIFCONF takes ifconf argument
and requires shared lock, because it sleeps writing
to user space.
*/
if (cmd == SIOCGIFCONF) {
rtnl_lock();
ret = dev_ifconf(net, (char __user *) arg);
rtnl_unlock();
return ret;
}
Any ideas? Kernel is 2.6.35
^ permalink raw reply
* Re: [PATCH] powerpc: Add jump label support
From: Steven Rostedt @ 2010-11-08 14:18 UTC (permalink / raw)
To: Michael Ellerman
Cc: Kumar Gala, linux-kernel, David S.Miller, linuxppc-dev,
Anton Blanchard, jbaron
In-Reply-To: <45fbc3cd7f6ce404d1e25bf01695fb629d86189d.1289189560.git.michael@ellerman.id.au>
On Mon, 2010-11-08 at 15:12 +1100, Michael Ellerman wrote:
> This patch adds support for the new "jump label" feature.
Darn it! I wanted to port this!!!
;-)
>
> Built for 64 & 32 bit, tested on 64 bit. Survives a kernel build under
> perf with all tracepoints enabled, and manual inspection of the patched
> code looks right. But still, lightly tested, YMMV.
>
> Unlike x86 and sparc we just merrily patch the code with no locks etc,
> as far as I know this is safe, but I'm not really sure what the x86/sparc
> code is protecting against so maybe it's not.
Thanks, I'll give it a test on my electra as soon as I get a gcc 4.5.1
cross compiler working.
-- Steve
^ permalink raw reply
* Re: Problem Ethernet Initialization MPC5200 + LXT971A
From: Stefan Strobl @ 2010-11-08 13:25 UTC (permalink / raw)
To: tiejun.chen; +Cc: linuxppc-dev
In-Reply-To: <4CD7C802.8020908@windriver.com>
Hi Tiejun
tiejun.chen wrote:
> Stefan Strobl wrote:
>> To workaround I could make u-boot run eth_init() always but that doesn't
>> seem the right approach to this.
>
> Yes. Often we shouldn't depend the bootloader do this when we use NIC. But its
> worth tracking eth_init in detail to check what are missed for Linux. I guest
> those should be dedicated to the hardware. For example, configuring
> multiplex-pin, or reset PHY before the real operation action and so on.
>
You're right! It was a wrong Port Multiplex Configuration.
I think it's fair to expect the bootloader to do that bit of setup,
since it's very hardware dependent. All I did was to adapt my
CONFIG_SYS_GPS_PORT_CONFIG in u-boot.
Many thanks
Stefan.
^ permalink raw reply
* [PATCH] ucc_geth: Fix hung tasks.
From: Joakim Tjernlund @ 2010-11-08 10:23 UTC (permalink / raw)
To: linuxppc-dev, netdev, Anton Vorontsov
We noticed a few hangs like this:
INFO: task ifconfig:572 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
ifconfig D 0ff65760 0 572 369 0x00000000
Call Trace:
[c6157be0] [c6008460] 0xc6008460 (unreliable)
[c6157ca0] [c0008608] __switch_to+0x4c/0x6c
[c6157cb0] [c028fecc] schedule+0x184/0x310
[c6157ce0] [c0290e54] __mutex_lock_slowpath+0xa4/0x150
[c6157d20] [c0290c48] mutex_lock+0x44/0x48
[c6157d30] [c01aba74] phy_stop+0x20/0x70
[c6157d40] [c01aef40] ucc_geth_stop+0x30/0x98
[c6157d60] [c01b18fc] ucc_geth_close+0x9c/0xdc
[c6157d80] [c01db0cc] __dev_close+0xa0/0xd0
[c6157d90] [c01deddc] __dev_change_flags+0x8c/0x148
[c6157db0] [c01def54] dev_change_flags+0x1c/0x64
[c6157dd0] [c0237ac8] devinet_ioctl+0x678/0x784
[c6157e50] [c0239a58] inet_ioctl+0xb0/0xbc
[c6157e60] [c01cafa8] sock_ioctl+0x174/0x2a0
[c6157e80] [c009a16c] vfs_ioctl+0xcc/0xe0
[c6157ea0] [c009a998] do_vfs_ioctl+0xc4/0x79c
[c6157f10] [c009b0b0] sys_ioctl+0x40/0x74
[c6157f40] [c00117c4] ret_from_syscall+0x0/0x38
I THINK this is due to a missing cancel_work_sync in the driver
although we cannot be sure. I found this by comparing
ucc_geth with gianfar.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
drivers/net/ucc_geth.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 97f9f7d..6647ed7 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3556,6 +3556,7 @@ static int ucc_geth_close(struct net_device *dev)
napi_disable(&ugeth->napi);
+ cancel_work_sync(&ugeth->timeout_work);
ucc_geth_stop(ugeth);
free_irq(ugeth->ug_info->uf_info.irq, ugeth->ndev);
--
1.7.2.2
^ permalink raw reply related
* Re: Problem Ethernet Initialization MPC5200 + LXT971A
From: tiejun.chen @ 2010-11-08 9:50 UTC (permalink / raw)
To: Stefan Strobl; +Cc: linuxppc-dev
In-Reply-To: <4CD431B4.7060405@gersys.de>
Stefan Strobl wrote:
> Hi
>
> I'm having a Problem with the Initialization of my Ethernet PHY
> (FEC_MPC5200 + LXT971A Phy). I'm using latest U-Boot and Linux 2.6.37
> from Denx.
>
> Once in Linux I can ping my own IP-Address but not any other device in
> my network. The Link LED is on when connected to the network but when
> pinging some other device nothing is being transmitted (Traffic LED is
> off).
>
> If - before booting - I'm using any network command under U-Boot (which
> is calling eth_init()), the interface works fine after that under Linux
> also!
> In that case the kernel prints the line:
> PHY: f003000:00 - Link is Up - 100/Full
Can you probe PHY successfully when failed?
>
> So I'm not sure whether the Linux driver does not initialize the PHY
> correctly or whether I should be running a command under Linux that
> makes the interface work. I've played around with ifconfig but that
> didn't get me any further.
>
> Under sysfs I can see that the MAC address is assigned correctly but:
> carrier = 0 (should be 1)
> duplex = half (should be full)
> operstate = down
> speed = 10 (should be 100)
>
Can you use 'ethtool' utility to access/control that? If no please check how you
access PHY by MII bus? I doubts some multiplex PIN should be configured when you
operate PHY.
> To workaround I could make u-boot run eth_init() always but that doesn't
> seem the right approach to this.
Yes. Often we shouldn't depend the bootloader do this when we use NIC. But its
worth tracking eth_init in detail to check what are missed for Linux. I guest
those should be dedicated to the hardware. For example, configuring
multiplex-pin, or reset PHY before the real operation action and so on.
Tiejun
>
> Any ideas?
>
> Many Thanks,
> Stefan.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH] powerpc: Consolidate obj-y assignments
From: Peter Korsgaard @ 2010-11-08 7:23 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <0429b4b15a3c65fdae92f92cce656b4859dca05e.1289190214.git.michael@ellerman.id.au>
>>>>> "Michael" == Michael Ellerman <michael@ellerman.id.au> writes:
Michael> No need to have three of them.
Michael> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Michael> ---
Michael> arch/powerpc/kernel/Makefile | 9 ++++-----
Michael> 1 files changed, 4 insertions(+), 5 deletions(-)
Michael> - signal.o sysfs.o cacheinfo.o
Michael> -obj-y += vdso32/
Michael> + signal.o sysfs.o cacheinfo.o time.o \
Michael> + time.o prom.o traps.o setup-common.o \
You have time.o twice.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [PATCH] powerpc: Consolidate obj-y assignments
From: Michael Ellerman @ 2010-11-08 4:24 UTC (permalink / raw)
To: linuxppc-dev
No need to have three of them.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/Makefile | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 36c30f3..259e4ce 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -29,8 +29,10 @@ endif
obj-y := cputable.o ptrace.o syscalls.o \
irq.o align.o signal_32.o pmc.o vdso.o \
init_task.o process.o systbl.o idle.o \
- signal.o sysfs.o cacheinfo.o
-obj-y += vdso32/
+ signal.o sysfs.o cacheinfo.o time.o \
+ time.o prom.o traps.o setup-common.o \
+ udbg.o misc.o io.o dma.o \
+ misc_$(CONFIG_WORD_SIZE).o vdso32/
obj-$(CONFIG_PPC64) += setup_64.o sys_ppc32.o \
signal_64.o ptrace32.o \
paca.o nvram_64.o firmware.o
@@ -80,9 +82,6 @@ extra-$(CONFIG_FSL_BOOKE) := head_fsl_booke.o
extra-$(CONFIG_8xx) := head_8xx.o
extra-y += vmlinux.lds
-obj-y += time.o prom.o traps.o setup-common.o \
- udbg.o misc.o io.o dma.o \
- misc_$(CONFIG_WORD_SIZE).o
obj-$(CONFIG_PPC32) += entry_32.o setup_32.o
obj-$(CONFIG_PPC64) += dma-iommu.o iommu.o
obj-$(CONFIG_KGDB) += kgdb.o
--
1.7.1
^ permalink raw reply related
* [PATCH] powerpc: Ensure the else case of feature sections will fit
From: Michael Ellerman @ 2010-11-08 4:22 UTC (permalink / raw)
To: linuxppc-dev
When we create an alternative feature section, the else case must be the
same size or smaller than the body. This is because when we patch the
else case in we just overwrite the body, so there must be room.
Up to now we just did this by inspection, but it's quite easy to enforce
it in the assembler, so we should.
The only change is to add the ifgt block, but that effects the alignment
of the tabs and so the whole macro is modified.
Also add a test, but #if 0 it because we don't want to break the build.
Anyone who's modifying the feature macros should enable the test.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/include/asm/feature-fixups.h | 27 +++++++++++++++------------
arch/powerpc/lib/feature-fixups-test.S | 19 +++++++++++++++++++
2 files changed, 34 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/include/asm/feature-fixups.h b/arch/powerpc/include/asm/feature-fixups.h
index 96a7d06..921a847 100644
--- a/arch/powerpc/include/asm/feature-fixups.h
+++ b/arch/powerpc/include/asm/feature-fixups.h
@@ -37,18 +37,21 @@ label##2: \
.align 2; \
label##3:
-#define MAKE_FTR_SECTION_ENTRY(msk, val, label, sect) \
-label##4: \
- .popsection; \
- .pushsection sect,"a"; \
- .align 3; \
-label##5: \
- FTR_ENTRY_LONG msk; \
- FTR_ENTRY_LONG val; \
- FTR_ENTRY_OFFSET label##1b-label##5b; \
- FTR_ENTRY_OFFSET label##2b-label##5b; \
- FTR_ENTRY_OFFSET label##3b-label##5b; \
- FTR_ENTRY_OFFSET label##4b-label##5b; \
+#define MAKE_FTR_SECTION_ENTRY(msk, val, label, sect) \
+label##4: \
+ .popsection; \
+ .pushsection sect,"a"; \
+ .align 3; \
+label##5: \
+ FTR_ENTRY_LONG msk; \
+ FTR_ENTRY_LONG val; \
+ FTR_ENTRY_OFFSET label##1b-label##5b; \
+ FTR_ENTRY_OFFSET label##2b-label##5b; \
+ FTR_ENTRY_OFFSET label##3b-label##5b; \
+ FTR_ENTRY_OFFSET label##4b-label##5b; \
+ .ifgt (label##4b-label##3b)-(label##2b-label##1b); \
+ .error "Feature section else case larger than body"; \
+ .endif; \
.popsection;
diff --git a/arch/powerpc/lib/feature-fixups-test.S b/arch/powerpc/lib/feature-fixups-test.S
index cb73748..f461311 100644
--- a/arch/powerpc/lib/feature-fixups-test.S
+++ b/arch/powerpc/lib/feature-fixups-test.S
@@ -172,6 +172,25 @@ globl(ftr_fixup_test6_expected)
3: or 3,3,3
+#if 0
+/* Test that if we have a larger else case the assembler spots it and
+ * reports an error. #if 0'ed so as not to break the build normally.
+ */
+ftr_fixup_test7:
+ or 1,1,1
+BEGIN_FTR_SECTION
+ or 2,2,2
+ or 2,2,2
+ or 2,2,2
+FTR_SECTION_ELSE
+ or 3,3,3
+ or 3,3,3
+ or 3,3,3
+ or 3,3,3
+ALT_FTR_SECTION_END(0, 1)
+ or 1,1,1
+#endif
+
#define MAKE_MACRO_TEST(TYPE) \
globl(ftr_fixup_test_ ##TYPE##_macros) \
or 1,1,1; \
--
1.7.1
^ permalink raw reply related
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