* Re: about uImage-DENX-v2.6.14 config
From: Robert Schwebel @ 2007-11-18 11:17 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, zhangwei zhang, linuxppc-embedded
In-Reply-To: <20071118004301.475BC247F1@gemini.denx.de>
On Sun, Nov 18, 2007 at 01:43:01AM +0100, Wolfgang Denk wrote:
> In message <200711150713.28211.sr@denx.de> Stefan Roese wrote:
> > On Wednesday 14 November 2007, zhangwei zhang wrote:
> > > Hello, I have a problem when using linux-2.6.14(download from
> > > ftp.denx.de) for RTAI on ppc440EP.
> >
> > RTAI on PPC? I thought RTAI was dead for anything other than X86.
>
> Stefan is right.
>
> RTAI is dead.
>
> You should use Xenomai instead.
Or rt-preempt of course, which is the mainline way of doing realtime.
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* RE: MPC880: i2cer register says tx is done but tx buf descriptor is still ready
From: DI BACCO ANTONIO - technolabs @ 2007-11-18 11:12 UTC (permalink / raw)
To: Jochen Friedrich
In-Reply-To: <473F33BB.7050006@scram.de>
[-- Attachment #1: Type: text/plain, Size: 1589 bytes --]
A porting of the driver included in kernel 2.4.
Here is an excerpt of the method to send bytes over the i2c bus:
________________________________________________________________________
i2c->i2c_i2cmr = 0x00; /* Disable I2C interupts */
i2c->i2c_i2cer = 0xff;
i2c->i2c_i2mod |= 1; /* Enable */
i2c->i2c_i2com |= 0x80; /* Begin transmission */
tmo = jiffies + 1*HZ;
/* Busy wait, with a timeout */
while(!(i2c->i2c_i2cer & 0x12 || time_after(jiffies, tmo)));
if (signal_pending(current) || !tmo){
force_close(algo_8xx_data);
if (!tmo)
printk("IIC write: timeout!\n");
return -EIO;
}
if ((tbdf[0]->cbd_sc | tbdf[1]->cbd_sc) & BD_SC_NAK) {
printk(KERN_INFO "IIC write; no ack\n");
if (cpm_debug > 0)
printk("tx0 sc %04x, tx1 sc %04x\n", tbdf[0]->cbd_sc,tbdf[1]->cbd_sc);
return 0;
}
if ((tbdf[0]->cbd_sc | tbdf[1]->cbd_sc) & BD_SC_READY) {
printk(KERN_INFO "IIC write; complete but tbuf ready\n");
if (cpm_debug > 0)
printk("tx0 sc %04x, tx1 sc %04x\n", tbdf[0]->cbd_sc,tbdf[1]->cbd_sc);
return 0;
}
-----Original Message-----
From: Jochen Friedrich [mailto:jochen@scram.de]
Sent: Sat 17/11/2007 19.32
To: DI BACCO ANTONIO - technolabs
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: MPC880: i2cer register says tx is done but tx buf descriptor is still ready
Hi Antonio,
> How could it be possible? It happens during the first i2c transactions
> and then no more.
>
What linux version? Which driver?
Thanks,
Jochen
[-- Attachment #2: Type: text/html, Size: 2875 bytes --]
^ permalink raw reply
* Re: [patch] PS3: Fix printing of os-area magic numbers
From: Geert Uytterhoeven @ 2007-11-18 9:33 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev@ozlabs.org, Paul Mackerras
In-Reply-To: <473F6A28.5000309@am.sony.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1937 bytes --]
On Sat, 17 Nov 2007, Geoff Levand wrote:
> Fix a bug in the printing of the PS3 os-area magic numbers which assumed that
> magic numbers were zero terminated strings. The magic numbers are represented
> in memory as integers. If the os-area sections are not initialized correctly
> they could contained random data that would be printed to the display.
>
> CC: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
> ---
>
> Paul,
>
> This fixes a very minor bug in linus' current tree. Please consider
> for 2.6.24.
>
> -Geoff
>
> arch/powerpc/platforms/ps3/os-area.c | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> --- a/arch/powerpc/platforms/ps3/os-area.c
> +++ b/arch/powerpc/platforms/ps3/os-area.c
> @@ -269,8 +269,13 @@ static void __init os_area_get_property(
> static void _dump_header(const struct os_area_header *h, const char *func,
> int line)
> {
> + u8 str[sizeof(h->magic_num) + 1];
> +
> + memcpy(str, h->magic_num, sizeof(h->magic_num));
> + str[sizeof(h->magic_num)] = 0;
> +
> pr_debug("%s:%d: h.magic_num: '%s'\n", func, line,
> - h->magic_num);
> + str);
This only fixes the problem of a missing zero-termination (which could be
handled using `%*s').
I'm also worried about unprintable characters.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [PATCH] Xilinx TEMAC driver
From: David H. Lynch Jr. @ 2007-11-18 9:04 UTC (permalink / raw)
To: John Williams, linuxppc-embedded
In-Reply-To: <47392A2A.7020200@itee.uq.edu.au>
John Williams wrote:
> Hi David, GRant
>
> Any progress on the ll_temac driver since July? In EDK9.2, ll_temac is
> really the only supported ethernet solution, apart from ethernet lite
> (yuck).
>
> If there's a PPC version in a reasonable state, i'm happy to see
> what's requierd to port it across to MicroBlaze.
Little has been done since July. The version I posted did have ll_temac
support that once upon a time worked.
I have little experience on the firmware side - yet. Though I keep
getting pushed towards it, I also end up sufficiently busy on the
software side as to have no time to even finish installing Xilinx tools.
But I am pretty sure Pico is using 9.2 and I am completely certain we
are not currently using the ll_temac.
BUT, there is serious discussion about going back to it. We strive for
the absolute smallest firmware needed for a task. We have clients that
need Linux or GreenHills on the card AND are designing large blocks of
firmware for their own purposes. No matter how much free space we give
them they need more.
I have heard that the current incarnations of the ll_temac support
interrupts. This was the deal breaker for us on the original ll_temac.
Linux could be made to work (fairly badly) without interrupts, but while
nothing is impossible, trying to write a GreenHills NIC driver that is
polled was an excercise in futility. I managed to get a polled serial
driver working - but it was very ugly.
Presuming that the currently ll_temac is smaller than the plb
implimentation and presuming that it has the option of interrupts, it is
likely to return to my todo list shortly - of course that list is fairly
long. I have spent the past several months massaging Pico's Host
utilites to run under Linxu 2.6, 2.4, OpenBSD, and Mac OS X. I have been
living exclusively in Linux since March. I accidentally obliterated my
Windows partition and the recovery partition installing OS X86 and have
not even noticed it is gone.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* about xeno_hal modules
From: zhangwei zhang @ 2007-11-18 5:31 UTC (permalink / raw)
To: linuxppc-dev, linuxppc-embedded, xenomai-help
Hello, I have some problem of instalingl xenomai on ppc. I use the
linux-2.6.19 and xenomai-2.3.4, I want to get the xeno_hal.ko for emc
porting. But it seems that it can be only compiled in to the
kernel,not as module. What can I do to implement it?
Best wishes
kyla
^ permalink raw reply
* Re: Re: multiprocessor
From: keng_629 @ 2007-11-18 1:55 UTC (permalink / raw)
To: grant.likely; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <fa686aa40711171353t2e8789a2vcf6f2a72afc4c1cd@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 995 bytes --]
SMP doesn't work on the Virtex?i am so sorry .i just hoped to make exam on virtex for SMP.now i can just run separate Linux on each one.
thank you for you help
yours onmineroad
keng_629
2007-11-18
发件人： Grant Likely
发送时间： 2007-11-18 07:29:58
收件人： keng_629
抄送： linuxppc-embedded
主题： Re: multiprocessor
On 11/16/07, keng_629 <keng_629@126.com > wrote:
>
>
> i am trying to make a exam about Multiprocessor on the Xilinx Virtex-4 with
> two PowerPc hard core.
> please give me some advices about bootloader and os.
> how can i start my work.
I'm sorry, but I really don't understand what you're asking about.
Both u-boot and Linux run on the ppc405 cores that the Virtex-4 uses.
However, there is no cache coherency between the cores so you would
need to run a separate Linux image on each one. (SMP doesn't work)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
[-- Attachment #2: Type: text/html, Size: 4326 bytes --]
^ permalink raw reply
* Re: Hardware debuggers for PPC74xx G4 CPUs
From: Wolfgang Denk @ 2007-11-18 0:47 UTC (permalink / raw)
To: Jon Smirl; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <9e4733910711141834n2bfb1742v5637c56e27e26f5a@mail.gmail.com>
In message <9e4733910711141834n2bfb1742v5637c56e27e26f5a@mail.gmail.com> you wrote:
>
> > * The documentation is only available under NDA, a problem for open
> > source debuggers.
>
> This is what we need. I would like it specifically for the mpc5200.
> But we want to use it in OpenOCD so NDA won't work.
It doesn't work. Been there a logn time ago. It's and endless
fingerpointing. Freescale (by then: Motorola) says they cannot
release any information because of their contracts with IBM, and vice
versa.
> Dominic is way experienced implementing JTAG for ARM CPUs. He has done
> several dozen interfaces. ARM doesn't have any problems releasing
> their debugging info.
JTAG is simple, but you don't get the necessery information for the
COP (= debug) interface.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Genius doesn't work on an assembly line basis. You can't simply say,
"Today I will be brilliant."
-- Kirk, "The Ultimate Computer", stardate 4731.3
^ permalink raw reply
* Re: MPC5200B: Linux does not recognise the external PCI card
From: Wolfgang Denk @ 2007-11-18 0:51 UTC (permalink / raw)
To: Juergen Beisert; +Cc: linuxppc-embedded
In-Reply-To: <200711151521.43047.jbe@pengutronix.de>
In message <200711151521.43047.jbe@pengutronix.de> you wrote:
>
> > Which card?
>
> Its a NEC USB 2.0 card.
Are you absolutely sure that this card is 3.3V clean, i. e. that the
PCI slot on the Lite5200B provides all the needed voltages?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
A supercomputer is a machine that runs an endless loop in 2 seconds.
^ permalink raw reply
* Re: Problem with uboot on lite5200
From: Wolfgang Denk @ 2007-11-18 0:49 UTC (permalink / raw)
To: Leo Hendrawan; +Cc: linuxppc-embedded
In-Reply-To: <6b461e5b0711150114h26624cacq3cad2629912c60ea@mail.gmail.com>
In message <6b461e5b0711150114h26624cacq3cad2629912c60ea@mail.gmail.com> you wrote:
>
> how can i re-flash the uboot inside the MPC5200? i use bdi2000, compiled the
You are off topic here. Please post U-Boto related questions on the
U-Boot maioling list.
> new uboot version 1.1.6 but didnt find out anyway to flash it inside the
New? 1.1.6? That's stone-age.
Current U-Boot is 1.3.0-rc4. Please wake up.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
[Braddock:] Mr. Churchill, you are drunk.
[Churchill:] And you madam, are ugly. But I shall be sober tomorrow.
^ permalink raw reply
* Re: about uImage-DENX-v2.6.14 config
From: Wolfgang Denk @ 2007-11-18 0:43 UTC (permalink / raw)
To: zhangwei zhang; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <200711150713.28211.sr@denx.de>
In message <200711150713.28211.sr@denx.de> Stefan Roese wrote:
> On Wednesday 14 November 2007, zhangwei zhang wrote:
> > Hello, I have a problem when using linux-2.6.14(download from
> > ftp.denx.de) for RTAI on ppc440EP.
>
> RTAI on PPC? I thought RTAI was dead for anything other than X86.
Stefan is right.
RTAI is dead.
You should use Xenomai instead.
> And 2.6.14 is quite old. I suggest you use a newer binary version or compile a
> the image from the current kernel source.
He is reight again. Pleas euse a current kernel version from our git
repository; Xenomai should support this directly.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
1 1 was a race-horse, 2 2 was 1 2. When 1 1 1 1 race, 2 2 1 1 2.
^ permalink raw reply
* Re: [BUG] 2.6.24-rc2-mm1 - kernel bug on nfs v4
From: Torsten Kaiser @ 2007-11-17 23:44 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Trond Myklebust, steved, LKML, Kamalesh Babulal, linuxppc-dev,
nfs, Andrew Morton, Jan Blunck, Ingo Molnar, Balbir Singh
In-Reply-To: <20071117230508.GB25905@dyad>
On Nov 18, 2007 12:05 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
>
> On Sat, Nov 17, 2007 at 08:40:22PM +0100, Torsten Kaiser wrote:
>
> > Lockdep triggers immedetly before the freeze, but the result is still
> > not helpful:
> >
> > [ 221.565011] INFO: trying to register non-static key.
> > [ 221.566999] the code is fine but needs lockdep annotation.
> > [ 221.569206] turning off the locking correctness validator.
> > [ 221.571404]
> > [ 221.571405] Call Trace:
> > [ 221.572996] [<ffffffff8025a1b4>] __lock_acquire+0x4c4/0x1140
> > [ 221.575298] [<ffffffff8025ae85>] lock_acquire+0x55/0x70
> > [ 221.577429] [<ffffffff8022d6fd>] __wake_up+0x2d/0x70
> > [ 221.579457] [<ffffffff805c5f04>] _spin_lock_irqsave+0x34/0x50
> > [ 221.581800] [<ffffffff805c5e45>] _spin_unlock_irqrestore+0x55/0x70
> > [ 221.584317] [<ffffffff8022d6fd>] __wake_up+0x2d/0x70
> > [ 221.586344] [<ffffffff805a88b0>] rpc_async_schedule+0x0/0x10
> > [ 221.588648] [<ffffffff802fface>] nfs_free_unlinkdata+0x1e/0x50
> > [ 221.591023] [<ffffffff805a7e96>] rpc_release_calldata+0x26/0x50
> > [ 221.593428] [<ffffffff8024778f>] run_workqueue+0x16f/0x210
> > [ 221.595662] [<ffffffff80259731>] trace_hardirqs_on+0xc1/0x160
> > [ 221.598004] [<ffffffff802483d0>] worker_thread+0x0/0xb0
> > [ 221.600130] [<ffffffff802483d0>] worker_thread+0x0/0xb0
> > [ 221.602265] [<ffffffff8024843d>] worker_thread+0x6d/0xb0
> > [ 221.604431] [<ffffffff8024bfc0>] autoremove_wake_function+0x0/0x30
> > [ 221.606939] [<ffffffff802483d0>] worker_thread+0x0/0xb0
> > [ 221.609067] [<ffffffff802483d0>] worker_thread+0x0/0xb0
> > [ 221.611199] [<ffffffff8024bbeb>] kthread+0x4b/0x80
> > [ 221.613156] [<ffffffff8020cb98>] child_rip+0xa/0x12
> > [ 221.615151] [<ffffffff8020c2af>] restore_args+0x0/0x30
> > [ 221.617247] [<ffffffff8024bba0>] kthread+0x0/0x80
> > [ 221.619162] [<ffffffff8020cb8e>] child_rip+0x0/0x12
> > [ 221.621147]
> > [ 221.621749] INFO: lockdep is turned off.
>
> I've been staring at this NFS code for a while an can't make any sense
> out of it. It seems to correctly initialize the waitqueue. So this would
> indicate corruption of some sort.
Not sure if this is helpful, but after looking into the code, the
above stacktrace looks somewhat damaged.
Might be my fault: # CONFIG_FRAME_POINTER is not set
On the other hand the stacktrace from the run with the SLUB lockdep
fix shows the same function names.
That trace contains this line:
[<ffffffff8030167e>] nfs_free_unlinkdata+0x1e/0x50
(gdb) list *0xffffffff8030167e
0xffffffff8030167e is in nfs_free_unlinkdata (fs/nfs/unlink.c:33).
28 */
29 static void
30 nfs_free_unlinkdata(struct nfs_unlinkdata *data)
31 {
32 nfs_sb_deactive(NFS_SERVER(data->dir));
33 iput(data->dir);
34 put_rpccred(data->cred);
35 kfree(data->args.name.name);
36 kfree(data);
37 }
Is some inode lock guilty?
Please ask, if you need more information.
Torsten
^ permalink raw reply
* Re: [BUG] 2.6.24-rc2-mm1 - kernel bug on nfs v4
From: root @ 2007-11-17 23:00 UTC (permalink / raw)
To: Ingo Molnar
Cc: Trond Myklebust, Peter Zijlstra, LKML, Torsten Kaiser,
Kamalesh Babulal, linuxppc-dev, nfs, Christoph Lameter,
Andrew Morton, Jan Blunck, Balbir Singh
In-Reply-To: <20071117180946.GA14055@elte.hu>
On Sat, Nov 17, 2007 at 07:09:46PM +0100, Ingo Molnar wrote:
>
> * Torsten Kaiser <just.for.lkml@googlemail.com> wrote:
>
> > Sadly lockdep does not work for me, as it gets turned off early:
> > [ 39.851594] ---------------------------------
> > [ 39.855963] inconsistent {softirq-on-W} -> {in-softirq-W} usage.
> > [ 39.861981] swapper/0 [HC0[0]:SC1[1]:HE0:SE0] takes:
> > [ 39.866963] (&n->list_lock){-+..}, at: [<ffffffff802935c1>]
>
> hey, that means it found a bug - which is not sad at all :-)
---
Subject: lockdep: slub: annotate boot time node->list_lock usage
inconsistent {softirq-on-W} -> {in-softirq-W} usage.
swapper/0 [HC0[0]:SC1[1]:HE0:SE0] takes:
(&n->list_lock){-+..}, at: [<ffffffff802935c1>] add_partial+0x31/0xa0
{softirq-on-W} state was registered at:
[<ffffffff80259fb8>] __lock_acquire+0x3e8/0x1140
[<ffffffff80259838>] debug_check_no_locks_freed+0x188/0x1a0
[<ffffffff8025ad65>] lock_acquire+0x55/0x70
[<ffffffff802935c1>] add_partial+0x31/0xa0
[<ffffffff805c76de>] _spin_lock+0x1e/0x30
[<ffffffff802935c1>] add_partial+0x31/0xa0
[<ffffffff80296f9c>] kmem_cache_open+0x1cc/0x330
[<ffffffff805c7984>] _spin_unlock_irq+0x24/0x30
[<ffffffff802974f4>] create_kmalloc_cache+0x64/0xf0
[<ffffffff80295640>] init_alloc_cpu_cpu+0x70/0x90
[<ffffffff8080ada5>] kmem_cache_init+0x65/0x1d0
[<ffffffff807f1b4e>] start_kernel+0x23e/0x350
[<ffffffff807f112d>] _sinittext+0x12d/0x140
[<ffffffffffffffff>] 0xffffffffffffffff
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
CC: Christoph Lameter <clameter@sgi.com>
CC: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
---
mm/slub.c | 8 ++++++++
1 file changed, 8 insertions(+)
Index: linux-2.6/mm/slub.c
===================================================================
--- linux-2.6.orig/mm/slub.c
+++ linux-2.6/mm/slub.c
@@ -2155,6 +2155,7 @@ static struct kmem_cache_node *early_kme
{
struct page *page;
struct kmem_cache_node *n;
+ unsigned long flags;
BUG_ON(kmalloc_caches->size < sizeof(struct kmem_cache_node));
@@ -2179,7 +2180,14 @@ static struct kmem_cache_node *early_kme
#endif
init_kmem_cache_node(n);
atomic_long_inc(&n->nr_slabs);
+ /*
+ * lockdep requires consistent irq usage for each lock
+ * so even though there cannot be a race this early in
+ * the boot sequence, we still disable irqs.
+ */
+ local_irq_save(flags);
add_partial(kmalloc_caches, page, 0);
+ local_irq_restore(flags);
return n;
}
^ permalink raw reply
* Re: [BUG] 2.6.24-rc2-mm1 - kernel bug on nfs v4
From: Peter Zijlstra @ 2007-11-17 23:05 UTC (permalink / raw)
To: Torsten Kaiser
Cc: Trond Myklebust, Peter Zijlstra, steved, LKML, Kamalesh Babulal,
linuxppc-dev, nfs, Andrew Morton, Jan Blunck, Ingo Molnar,
Balbir Singh
In-Reply-To: <64bb37e0711171140w5f1451e0qea081a4fbc7a45f7@mail.gmail.com>
On Sat, Nov 17, 2007 at 08:40:22PM +0100, Torsten Kaiser wrote:
> Lockdep triggers immedetly before the freeze, but the result is still
> not helpful:
>
> [ 221.565011] INFO: trying to register non-static key.
> [ 221.566999] the code is fine but needs lockdep annotation.
> [ 221.569206] turning off the locking correctness validator.
> [ 221.571404]
> [ 221.571405] Call Trace:
> [ 221.572996] [<ffffffff8025a1b4>] __lock_acquire+0x4c4/0x1140
> [ 221.575298] [<ffffffff8025ae85>] lock_acquire+0x55/0x70
> [ 221.577429] [<ffffffff8022d6fd>] __wake_up+0x2d/0x70
> [ 221.579457] [<ffffffff805c5f04>] _spin_lock_irqsave+0x34/0x50
> [ 221.581800] [<ffffffff805c5e45>] _spin_unlock_irqrestore+0x55/0x70
> [ 221.584317] [<ffffffff8022d6fd>] __wake_up+0x2d/0x70
> [ 221.586344] [<ffffffff805a88b0>] rpc_async_schedule+0x0/0x10
> [ 221.588648] [<ffffffff802fface>] nfs_free_unlinkdata+0x1e/0x50
> [ 221.591023] [<ffffffff805a7e96>] rpc_release_calldata+0x26/0x50
> [ 221.593428] [<ffffffff8024778f>] run_workqueue+0x16f/0x210
> [ 221.595662] [<ffffffff80259731>] trace_hardirqs_on+0xc1/0x160
> [ 221.598004] [<ffffffff802483d0>] worker_thread+0x0/0xb0
> [ 221.600130] [<ffffffff802483d0>] worker_thread+0x0/0xb0
> [ 221.602265] [<ffffffff8024843d>] worker_thread+0x6d/0xb0
> [ 221.604431] [<ffffffff8024bfc0>] autoremove_wake_function+0x0/0x30
> [ 221.606939] [<ffffffff802483d0>] worker_thread+0x0/0xb0
> [ 221.609067] [<ffffffff802483d0>] worker_thread+0x0/0xb0
> [ 221.611199] [<ffffffff8024bbeb>] kthread+0x4b/0x80
> [ 221.613156] [<ffffffff8020cb98>] child_rip+0xa/0x12
> [ 221.615151] [<ffffffff8020c2af>] restore_args+0x0/0x30
> [ 221.617247] [<ffffffff8024bba0>] kthread+0x0/0x80
> [ 221.619162] [<ffffffff8020cb8e>] child_rip+0x0/0x12
> [ 221.621147]
> [ 221.621749] INFO: lockdep is turned off.
I've been staring at this NFS code for a while an can't make any sense
out of it. It seems to correctly initialize the waitqueue. So this would
indicate corruption of some sort.
> I also had another BUG output during system startup, but that should
> be unrelated:
> [ 103.254681] BUG: sleeping function called from invalid context at
> kernel/rwsem.c:20
> [ 103.257757] in_atomic():0, irqs_disabled():1
> [ 103.259469] 1 lock held by artsd/5883:
> [ 103.259470] #0: (pm_qos_lock){....}, at: [<ffffffff80250efb>]
> pm_qos_add_requirement+0x6b/0xf0
> [ 103.263316] irq event stamp: 49712
> [ 103.263318] hardirqs last enabled at (49711): [<ffffffff802941ed>]
> __kmalloc+0x10d/0x180
> [ 103.263321] hardirqs last disabled at (49712): [<ffffffff805c5eea>]
> _spin_lock_irqsave+0x1a/0x50
> [ 103.263326] softirqs last enabled at (48820): [<ffffffff805954d9>]
> unix_release_sock+0x79/0x240
> [ 103.263330] softirqs last disabled at (48818): [<ffffffff805c5b89>]
> _write_lock_bh+0x9/0x30
> [ 103.263333]
> [ 103.263333] Call Trace:
> [ 103.263335] [<ffffffff8024fc25>] down_read+0x15/0x40
> [ 103.263338] [<ffffffff802507e6>] __blocking_notifier_call_chain+0x46/0x90
> [ 103.263341] [<ffffffff80250f23>] pm_qos_add_requirement+0x93/0xf0
> [ 103.263344] [<ffffffff804fdc4a>] snd_pcm_hw_params+0x2fa/0x380
> [ 103.263347] [<ffffffff804fe93c>] snd_pcm_common_ioctl1+0xb4c/0xdc0
> [ 103.263350] [<ffffffff8027b167>] __do_fault+0x227/0x470
> [ 103.263353] [<ffffffff8025a435>] __lock_acquire+0x745/0x1140
> [ 103.263357] [<ffffffff805c5e45>] _spin_unlock_irqrestore+0x55/0x70
> [ 103.263359] [<ffffffff80259731>] trace_hardirqs_on+0xc1/0x160
> [ 103.263362] [<ffffffff804fee88>] snd_pcm_playback_ioctl1+0x48/0x240
> [ 103.263365] [<ffffffff804ffa36>] snd_pcm_playback_ioctl+0x36/0x50
> [ 103.263367] [<ffffffff802a80bf>] vfs_ioctl+0x2f/0xa0
> [ 103.263369] [<ffffffff802a8390>] do_vfs_ioctl+0x260/0x2e0
> [ 103.263371] [<ffffffff80259731>] trace_hardirqs_on+0xc1/0x160
> [ 103.263373] [<ffffffff802a84a1>] sys_ioctl+0x91/0xb0
> [ 103.263376] [<ffffffff8020bc5e>] system_call+0x7e/0x83
> [ 103.263379]
This pm-qos code is fubar, it calls blocking_notifier_call_chain while
holding a spinlock (and that is after 'fixing' it from a
srcu_notifier_call_chain - which is equally wrong).
^ permalink raw reply
* [patch] PS3: Fix printing of os-area magic numbers
From: Geoff Levand @ 2007-11-17 22:24 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Geert Uytterhoeven, linuxppc-dev@ozlabs.org
Fix a bug in the printing of the PS3 os-area magic numbers which assumed that
magic numbers were zero terminated strings. The magic numbers are represented
in memory as integers. If the os-area sections are not initialized correctly
they could contained random data that would be printed to the display.
CC: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
Paul,
This fixes a very minor bug in linus' current tree. Please consider
for 2.6.24.
-Geoff
arch/powerpc/platforms/ps3/os-area.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
--- a/arch/powerpc/platforms/ps3/os-area.c
+++ b/arch/powerpc/platforms/ps3/os-area.c
@@ -269,8 +269,13 @@ static void __init os_area_get_property(
static void _dump_header(const struct os_area_header *h, const char *func,
int line)
{
+ u8 str[sizeof(h->magic_num) + 1];
+
+ memcpy(str, h->magic_num, sizeof(h->magic_num));
+ str[sizeof(h->magic_num)] = 0;
+
pr_debug("%s:%d: h.magic_num: '%s'\n", func, line,
- h->magic_num);
+ str);
pr_debug("%s:%d: h.hdr_version: %u\n", func, line,
h->hdr_version);
pr_debug("%s:%d: h.db_area_offset: %u\n", func, line,
@@ -484,8 +489,13 @@ static int db_get_rtc_diff(const struct
static void _dump_db(const struct os_area_db *db, const char *func,
int line)
{
+ u8 str[sizeof(db->magic_num) + 1];
+
+ memcpy(str, &db->magic_num, sizeof(db->magic_num));
+ str[sizeof(db->magic_num)] = 0;
+
pr_debug("%s:%d: db.magic_num: '%s'\n", func, line,
- (const char*)&db->magic_num);
+ str);
pr_debug("%s:%d: db.version: %u\n", func, line,
db->version);
pr_debug("%s:%d: db.index_64: %u\n", func, line,
^ permalink raw reply
* Re: multiprocessor
From: Grant Likely @ 2007-11-17 21:53 UTC (permalink / raw)
To: keng_629; +Cc: linuxppc-embedded
In-Reply-To: <200711171445384213369@126.com>
On 11/16/07, keng_629 <keng_629@126.com> wrote:
>
>
> i am trying to make a exam about Multiprocessor on the Xilinx Virtex-4 with
> two PowerPc hard core.
> please give me some advices about bootloader and os.
> how can i start my work.
I'm sorry, but I really don't understand what you're asking about.
Both u-boot and Linux run on the ppc405 cores that the Virtex-4 uses.
However, there is no cache coherency between the cores so you would
need to run a separate Linux image on each one. (SMP doesn't work)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Makefile FLAGS typoes??
From: Robert P. J. Day @ 2007-11-17 20:32 UTC (permalink / raw)
To: Linux PPC Mailing List
from arch/powerpc/Makefile:
...
KBUILD_CPPFLAGS += $(CPPFLAGS-y)
KBUILD_AFLAGS += $(AFLAGS-y)
KBUILD_CFLAGS += -msoft-float -pipe $(CFLAGS-y)
...
those right-hand side variables don't look right. are you sure they
shouldn't be, say, CFLAGS, or ccflags-y? etc, etc.
rday
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
^ permalink raw reply
* Re: [BUG] 2.6.24-rc2-mm1 - kernel bug on nfs v4
From: Torsten Kaiser @ 2007-11-17 20:10 UTC (permalink / raw)
To: Christoph Lameter
Cc: Trond Myklebust, LKML, Kamalesh Babulal, linuxppc-dev, nfs,
Andrew Morton, Jan Blunck, Balbir Singh
In-Reply-To: <Pine.LNX.4.64.0711171128530.7986@schroedinger.engr.sgi.com>
On Nov 17, 2007 8:33 PM, Christoph Lameter <clameter@sgi.com> wrote:
> On Sat, 17 Nov 2007, Andrew Morton wrote:
>
> > That's slub. It appears that list_lock is being taken from process context
> > in one place and from softirq in another.
>
> I kicked out some weird interrupt disable code in mm that was only run during
> NUMA bootstrap.
I'm using NUMA (Opteron), so this indeed fixes it.
A kernel complied with SLUB now outputs the same message as the SLAB
one, that lockdep annotations are needed at the place where nfs hangs.
> This should fix it but isnt there some mechanism to convince lockdep that
> it is okay to do these things during bootstrap?
>
> ---
> mm/slub.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> Index: linux-2.6/mm/slub.c
> ===================================================================
> --- linux-2.6.orig/mm/slub.c 2007-11-17 11:31:21.044136631 -0800
> +++ linux-2.6/mm/slub.c 2007-11-17 11:32:17.364386560 -0800
> @@ -2044,7 +2044,9 @@ static struct kmem_cache_node *early_kme
> #endif
> init_kmem_cache_node(n);
> atomic_long_inc(&n->nr_slabs);
> + local_irq_disable();
> add_partial(kmalloc_caches, page, 0);
> + local_irq_enable();
> return n;
> }
>
>
>
^ permalink raw reply
* Re: 85xx software reset problems from paulus.git
From: Kumar Gala @ 2007-11-17 19:52 UTC (permalink / raw)
To: robert lazarski; +Cc: linuxppc-embedded
In-Reply-To: <f87675ee0711161401k600b658ao3d6ae572fb367c47@mail.gmail.com>
On Nov 16, 2007, at 4:01 PM, robert lazarski wrote:
> On Nov 16, 2007 4:46 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>>
>>
>> On Nov 16, 2007, at 3:28 PM, robert lazarski wrote:
>>
>>> On Nov 16, 2007 3:44 PM, robert lazarski <robertlazarski@gmail.com>
>>> wrote:
>>>> On Nov 16, 2007 10:27 AM, Clemens Koller
>>>> <clemens.koller@anagramm.de> wrote:
>>>>> The SRESET# (pin AF20) is the soft reset input, causes
>>>>> an mcp assertion to the core.... (RTFM)
>>>>>
>>>>
>>>> That's what we are doing. The 85xx docs say "Soft reset. Causes a
>>>> machine check interrupt to the e500 core. Note that if the e500
>>>> core
>>>> is not configured to process machine check interrupts, the
>>>> assertion
>>>> of SRESET causes a core checkstop. SRESET need not be asserted
>>>> during
>>>> a hard reset."
>>>>
>>>
>>> Sorry for replying to myself, but thought I'd mention SRESET works
>>> fine on 85xx 2.6.23 , ie, the board resets after kernel panic. It
>>> doesn't work for me on 2.6.24rc2 .
>>
>> What actual 85xx are you using?
>>
>> - k
>>
>
> Custom 8548 board. I'm using the cds 85xx code for a reference and I
> calling the same reset functions.
>
1. do you have the following in your dts:
global-utilities@e0000 { //global utilities reg
compatible = "fsl,mpc8548-guts";
reg = <e0000 1000>;
fsl,has-rstcr;
};
2. in your platform code are you using fsl_rstcr_restart in
define_machine()
- k
^ permalink raw reply
* Re: [BUG] 2.6.24-rc2-mm1 - kernel bug on nfs v4
From: Torsten Kaiser @ 2007-11-17 19:40 UTC (permalink / raw)
To: Andrew Morton
Cc: Trond Myklebust, Peter Zijlstra, LKML, Kamalesh Babulal,
linuxppc-dev, nfs, Ingo Molnar, Jan Blunck, Balbir Singh
In-Reply-To: <20071117101957.7562639d.akpm@linux-foundation.org>
On Nov 17, 2007 7:19 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Sat, 17 Nov 2007 19:09:46 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>
> >
> > * Torsten Kaiser <just.for.lkml@googlemail.com> wrote:
> >
> > > Sadly lockdep does not work for me, as it gets turned off early:
> > > [ 39.851594] ---------------------------------
> > > [ 39.855963] inconsistent {softirq-on-W} -> {in-softirq-W} usage.
> > > [ 39.861981] swapper/0 [HC0[0]:SC1[1]:HE0:SE0] takes:
> > > [ 39.866963] (&n->list_lock){-+..}, at: [<ffffffff802935c1>]
> >
> > hey, that means it found a bug - which is not sad at all :-)
It was sad, that it found a bug that I was not searching for. ;)
> mutter.
>
> Torsten, you could try CONFIG_SLAB=y, CONFIG_SLUB=n to see if you can make
> some progress on the NFS problem.
I should had thought of that myself... OK anyway here is the result:
The hang is reproducable, emerge froze the system again after download
the source.
Lockdep triggers immedetly before the freeze, but the result is still
not helpful:
[ 221.565011] INFO: trying to register non-static key.
[ 221.566999] the code is fine but needs lockdep annotation.
[ 221.569206] turning off the locking correctness validator.
[ 221.571404]
[ 221.571405] Call Trace:
[ 221.572996] [<ffffffff8025a1b4>] __lock_acquire+0x4c4/0x1140
[ 221.575298] [<ffffffff8025ae85>] lock_acquire+0x55/0x70
[ 221.577429] [<ffffffff8022d6fd>] __wake_up+0x2d/0x70
[ 221.579457] [<ffffffff805c5f04>] _spin_lock_irqsave+0x34/0x50
[ 221.581800] [<ffffffff805c5e45>] _spin_unlock_irqrestore+0x55/0x70
[ 221.584317] [<ffffffff8022d6fd>] __wake_up+0x2d/0x70
[ 221.586344] [<ffffffff805a88b0>] rpc_async_schedule+0x0/0x10
[ 221.588648] [<ffffffff802fface>] nfs_free_unlinkdata+0x1e/0x50
[ 221.591023] [<ffffffff805a7e96>] rpc_release_calldata+0x26/0x50
[ 221.593428] [<ffffffff8024778f>] run_workqueue+0x16f/0x210
[ 221.595662] [<ffffffff80259731>] trace_hardirqs_on+0xc1/0x160
[ 221.598004] [<ffffffff802483d0>] worker_thread+0x0/0xb0
[ 221.600130] [<ffffffff802483d0>] worker_thread+0x0/0xb0
[ 221.602265] [<ffffffff8024843d>] worker_thread+0x6d/0xb0
[ 221.604431] [<ffffffff8024bfc0>] autoremove_wake_function+0x0/0x30
[ 221.606939] [<ffffffff802483d0>] worker_thread+0x0/0xb0
[ 221.609067] [<ffffffff802483d0>] worker_thread+0x0/0xb0
[ 221.611199] [<ffffffff8024bbeb>] kthread+0x4b/0x80
[ 221.613156] [<ffffffff8020cb98>] child_rip+0xa/0x12
[ 221.615151] [<ffffffff8020c2af>] restore_args+0x0/0x30
[ 221.617247] [<ffffffff8024bba0>] kthread+0x0/0x80
[ 221.619162] [<ffffffff8020cb8e>] child_rip+0x0/0x12
[ 221.621147]
[ 221.621749] INFO: lockdep is turned off.
[ 226.369259] SysRq : Emergency Sync
[ 226.331342] Emergency Sync complete
[ 227.064545] SysRq : Emergency Remount R/O
[ 228.193491] SysRq : Emergency Sync
[ 228.155593] Emergency Sync complete
[ 228.767931] SysRq : Resetting
I also had another BUG output during system startup, but that should
be unrelated:
[ 103.254681] BUG: sleeping function called from invalid context at
kernel/rwsem.c:20
[ 103.257757] in_atomic():0, irqs_disabled():1
[ 103.259469] 1 lock held by artsd/5883:
[ 103.259470] #0: (pm_qos_lock){....}, at: [<ffffffff80250efb>]
pm_qos_add_requirement+0x6b/0xf0
[ 103.263316] irq event stamp: 49712
[ 103.263318] hardirqs last enabled at (49711): [<ffffffff802941ed>]
__kmalloc+0x10d/0x180
[ 103.263321] hardirqs last disabled at (49712): [<ffffffff805c5eea>]
_spin_lock_irqsave+0x1a/0x50
[ 103.263326] softirqs last enabled at (48820): [<ffffffff805954d9>]
unix_release_sock+0x79/0x240
[ 103.263330] softirqs last disabled at (48818): [<ffffffff805c5b89>]
_write_lock_bh+0x9/0x30
[ 103.263333]
[ 103.263333] Call Trace:
[ 103.263335] [<ffffffff8024fc25>] down_read+0x15/0x40
[ 103.263338] [<ffffffff802507e6>] __blocking_notifier_call_chain+0x46/0x90
[ 103.263341] [<ffffffff80250f23>] pm_qos_add_requirement+0x93/0xf0
[ 103.263344] [<ffffffff804fdc4a>] snd_pcm_hw_params+0x2fa/0x380
[ 103.263347] [<ffffffff804fe93c>] snd_pcm_common_ioctl1+0xb4c/0xdc0
[ 103.263350] [<ffffffff8027b167>] __do_fault+0x227/0x470
[ 103.263353] [<ffffffff8025a435>] __lock_acquire+0x745/0x1140
[ 103.263357] [<ffffffff805c5e45>] _spin_unlock_irqrestore+0x55/0x70
[ 103.263359] [<ffffffff80259731>] trace_hardirqs_on+0xc1/0x160
[ 103.263362] [<ffffffff804fee88>] snd_pcm_playback_ioctl1+0x48/0x240
[ 103.263365] [<ffffffff804ffa36>] snd_pcm_playback_ioctl+0x36/0x50
[ 103.263367] [<ffffffff802a80bf>] vfs_ioctl+0x2f/0xa0
[ 103.263369] [<ffffffff802a8390>] do_vfs_ioctl+0x260/0x2e0
[ 103.263371] [<ffffffff80259731>] trace_hardirqs_on+0xc1/0x160
[ 103.263373] [<ffffffff802a84a1>] sys_ioctl+0x91/0xb0
[ 103.263376] [<ffffffff8020bc5e>] system_call+0x7e/0x83
[ 103.263379]
Torsten
^ permalink raw reply
* Re: [BUG] 2.6.24-rc2-mm1 - kernel bug on nfs v4
From: Christoph Lameter @ 2007-11-17 19:33 UTC (permalink / raw)
To: Andrew Morton
Cc: Trond Myklebust, LKML, Torsten Kaiser, Kamalesh Babulal,
linuxppc-dev, nfs, Jan Blunck, Balbir Singh
In-Reply-To: <20071117100507.912c5e5c.akpm@linux-foundation.org>
On Sat, 17 Nov 2007, Andrew Morton wrote:
> > Don't know who to bug about that.
>
> That's slub. It appears that list_lock is being taken from process context
> in one place and from softirq in another.
I kicked out some weird interrupt disable code in mm that was only run during
NUMA bootstrap.
This should fix it but isnt there some mechanism to convince lockdep that
it is okay to do these things during bootstrap?
---
mm/slub.c | 2 ++
1 file changed, 2 insertions(+)
Index: linux-2.6/mm/slub.c
===================================================================
--- linux-2.6.orig/mm/slub.c 2007-11-17 11:31:21.044136631 -0800
+++ linux-2.6/mm/slub.c 2007-11-17 11:32:17.364386560 -0800
@@ -2044,7 +2044,9 @@ static struct kmem_cache_node *early_kme
#endif
init_kmem_cache_node(n);
atomic_long_inc(&n->nr_slabs);
+ local_irq_disable();
add_partial(kmalloc_caches, page, 0);
+ local_irq_enable();
return n;
}
^ permalink raw reply
* Re: [BUG] 2.6.24-rc2-mm1 - kernel bug on nfs v4
From: Torsten Kaiser @ 2007-11-17 19:18 UTC (permalink / raw)
To: Trond Myklebust
Cc: LKML, Kamalesh Babulal, linuxppc-dev, nfs, Andrew Morton,
Jan Blunck, Balbir Singh
In-Reply-To: <1195325920.7484.1.camel@localhost.localdomain>
On Nov 17, 2007 7:58 PM, Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
>
> On Sat, 2007-11-17 at 18:53 +0100, Torsten Kaiser wrote:
> > On Nov 16, 2007 3:15 PM, Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> > > Hi Andrew,
> > >
> > > The kernel enters the xmon state while running the file system
> > > stress on nfs v4 mounted partition.
> > [snip]
> > > 0:mon> t
> > > [c0000000dbd4fb50] c000000000069768 .__wake_up+0x54/0x88
> > > [c0000000dbd4fc00] d00000000086b890 .nfs_sb_deactive+0x44/0x58 [nfs]
> > > [c0000000dbd4fc80] d000000000872658 .nfs_free_unlinkdata+0x2c/0x74 [nfs]
> > > [c0000000dbd4fd10] d000000000598510 .rpc_release_calldata+0x50/0x74 [sunrpc]
> > > [c0000000dbd4fda0] c00000000008d960 .run_workqueue+0x10c/0x1f4
> > > [c0000000dbd4fe50] c00000000008ec70 .worker_thread+0x118/0x138
> > > [c0000000dbd4ff00] c0000000000939f4 .kthread+0x78/0xc4
> > > [c0000000dbd4ff90] c00000000002b060 .kernel_thread+0x4c/0x68
>
> Could you try with the attached patch.
[snip]
> Fix is to move the call to nfs_sb_deactive() into
> nfs_async_unlink_release().
I realley doubt that will fix it.
My stacktrace was like:
run_workqueue
called: rpc_async_schedule
that called: rpc_release_calldata
which points to: nfs_async_unlink_release
that called: nfs_free_unlinkdata
So it does not matter for me if nfs_sb_deactive is called one step earlier.
Currently building with SLAB instead SLUB to see if lockdep tells something...
Torsten
^ permalink raw reply
* Re: [BUG] 2.6.24-rc2-mm1 - kernel bug on nfs v4
From: Trond Myklebust @ 2007-11-17 18:58 UTC (permalink / raw)
To: Torsten Kaiser
Cc: LKML, Kamalesh Babulal, linuxppc-dev, nfs, Andrew Morton,
Jan Blunck, Balbir Singh
In-Reply-To: <64bb37e0711170953p67d1be49lf4eaa190d662e2b4@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 893 bytes --]
On Sat, 2007-11-17 at 18:53 +0100, Torsten Kaiser wrote:
> On Nov 16, 2007 3:15 PM, Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> > Hi Andrew,
> >
> > The kernel enters the xmon state while running the file system
> > stress on nfs v4 mounted partition.
> [snip]
> > 0:mon> t
> > [c0000000dbd4fb50] c000000000069768 .__wake_up+0x54/0x88
> > [c0000000dbd4fc00] d00000000086b890 .nfs_sb_deactive+0x44/0x58 [nfs]
> > [c0000000dbd4fc80] d000000000872658 .nfs_free_unlinkdata+0x2c/0x74 [nfs]
> > [c0000000dbd4fd10] d000000000598510 .rpc_release_calldata+0x50/0x74 [sunrpc]
> > [c0000000dbd4fda0] c00000000008d960 .run_workqueue+0x10c/0x1f4
> > [c0000000dbd4fe50] c00000000008ec70 .worker_thread+0x118/0x138
> > [c0000000dbd4ff00] c0000000000939f4 .kthread+0x78/0xc4
> > [c0000000dbd4ff90] c00000000002b060 .kernel_thread+0x4c/0x68
Could you try with the attached patch.
Cheers
Trond
[-- Attachment #2: linux-2.6.24-007-fix_nfs_free_unlinkdata.dif --]
[-- Type: message/rfc822, Size: 1254 bytes --]
From: Trond Myklebust <Trond.Myklebust@netapp.com>
Subject: NFS: Fix nfs_free_unlinkdata()
Date: Sat, 17 Nov 2007 13:52:36 -0500
Message-ID: <1195325920.7484.2.camel@localhost.localdomain>
We should really only be calling nfs_sb_deactive() at the end of an RPC
call, to balance the nfs_sb_active() call in nfs_do_call_unlink(). OTOH,
nfs_free_unlinkdata() can be called from a variety of other situations.
Fix is to move the call to nfs_sb_deactive() into
nfs_async_unlink_release().
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
---
fs/nfs/unlink.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/nfs/unlink.c b/fs/nfs/unlink.c
index b97d3bb..c90862a 100644
--- a/fs/nfs/unlink.c
+++ b/fs/nfs/unlink.c
@@ -31,7 +31,6 @@ struct nfs_unlinkdata {
static void
nfs_free_unlinkdata(struct nfs_unlinkdata *data)
{
- nfs_sb_deactive(NFS_SERVER(data->dir));
iput(data->dir);
put_rpccred(data->cred);
kfree(data->args.name.name);
@@ -116,6 +115,7 @@ static void nfs_async_unlink_release(void *calldata)
struct nfs_unlinkdata *data = calldata;
nfs_dec_sillycount(data->dir);
+ nfs_sb_deactive(NFS_SERVER(data->dir));
nfs_free_unlinkdata(data);
}
^ permalink raw reply related
* Re: MPC880: i2cer register says tx is done but tx buf descriptor is still ready
From: Jochen Friedrich @ 2007-11-17 18:32 UTC (permalink / raw)
To: DI BACCO ANTONIO - technolabs; +Cc: linuxppc-embedded
In-Reply-To: <F1F6EC0C8B75034F9E3A79FC85122E8EB7C778@aquib01a>
Hi Antonio,
> How could it be possible? It happens during the first i2c transactions
> and then no more.
>
What linux version? Which driver?
Thanks,
Jochen
^ permalink raw reply
* Re: [BUG] 2.6.24-rc2-mm1 - kernel bug on nfs v4
From: Andrew Morton @ 2007-11-17 18:19 UTC (permalink / raw)
To: Ingo Molnar
Cc: Trond Myklebust, Peter, Zijlstra, LKML, Torsten Kaiser,
Kamalesh Babulal, linuxppc-dev, nfs, Jan Blunck, Balbir Singh
In-Reply-To: <20071117180946.GA14055@elte.hu>
On Sat, 17 Nov 2007 19:09:46 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>
> * Torsten Kaiser <just.for.lkml@googlemail.com> wrote:
>
> > Sadly lockdep does not work for me, as it gets turned off early:
> > [ 39.851594] ---------------------------------
> > [ 39.855963] inconsistent {softirq-on-W} -> {in-softirq-W} usage.
> > [ 39.861981] swapper/0 [HC0[0]:SC1[1]:HE0:SE0] takes:
> > [ 39.866963] (&n->list_lock){-+..}, at: [<ffffffff802935c1>]
>
> hey, that means it found a bug - which is not sad at all :-)
>
mutter.
Torsten, you could try CONFIG_SLAB=y, CONFIG_SLUB=n to see if you can make
some progress on the NFS problem.
^ permalink raw reply
* Re: [BUG] 2.6.24-rc2-mm1 - kernel bug on nfs v4
From: Ingo Molnar @ 2007-11-17 18:09 UTC (permalink / raw)
To: Torsten Kaiser
Cc: Trond Myklebust, Peter Zijlstra, LKML, Kamalesh Babulal,
linuxppc-dev, nfs, Andrew Morton, Jan Blunck, Balbir Singh
In-Reply-To: <64bb37e0711170953p67d1be49lf4eaa190d662e2b4@mail.gmail.com>
* Torsten Kaiser <just.for.lkml@googlemail.com> wrote:
> Sadly lockdep does not work for me, as it gets turned off early:
> [ 39.851594] ---------------------------------
> [ 39.855963] inconsistent {softirq-on-W} -> {in-softirq-W} usage.
> [ 39.861981] swapper/0 [HC0[0]:SC1[1]:HE0:SE0] takes:
> [ 39.866963] (&n->list_lock){-+..}, at: [<ffffffff802935c1>]
hey, that means it found a bug - which is not sad at all :-)
Ingo
^ 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