* 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
* 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: 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: 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: 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: 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: 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: 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
* 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: [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
* 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: 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: 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: Problem with uboot on lite5200
From: Clemens Koller @ 2007-11-18 13:21 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20071118004919.19256247F1@gemini.denx.de>
Hello, Wolfgang!
Wolfgang Denk schrieb:
> 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.
How should people get a glue what's current, when in the section
"Latest News" at http://sourceforge.net/projects/u-boot/ the people
still find a more or less official looking "u-boot-1.1.5" release.
(And they don't want to use scm repositories because they are afraid
of using anything unstable.)
> Current U-Boot is 1.3.0-rc4. Please wake up.
Well... maybe it's better to remove all references to the old
releases at sourceforge and point them to ftp://ftp.denx.de/pub/u-boot/
instead. Btw. 1.3.0-rc4 isn't there as well. :-P
Regards,
--
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm-technology.com
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* Re: [POWERPC] [RFC] Fix 8xx tlbie definition
From: Kumar Gala @ 2007-11-18 16:51 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071117110658.7375dc1a@vader.jdub.homelinux.org>
>>> Where can I grab it to give a try? My linuxppc archive is silent
>>> for some reason..
>>
>> Looks like I may have failed to post it ... weird, I was sure I
>> posted
>> that days ago, when Olof first mentioned the breakage. I'll check &
>> resend.
>
> I never saw it. If I had, I wouldn't have bothered to post my own
> version :)
we still haven't seen ben's version :)
- k
^ permalink raw reply
* Re: how to improve linux tcp/ip(UDP) efficiency on mpc8541 833Mhz.
From: Theo Gjaltema @ 2007-11-18 17:56 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <47398B44.2070902@anagramm.de>
Hi,
We use a 8250 and 8270 of which the performance is highly limited by the
bandwidth of the memory to the very small internal cache.
I once modified a driver into a "polling" method polling the device
every millisecond. The amount of messages processed trippled this way!
On full speed the console could even be used for "normal" operation (in
contrairy to the interrupt driver driver).
The penalties are obvious: When the bandwith used is low the delay for
polled messages is higher and the CPU overhead is higher.
Succes,
Theo.
Clemens Koller schreef:
> huangyun@coship.com schrieb:
> > hi,everbody:
> > I have run linux-2.6.15 on my mpc8541 custom board. but when i test
> > TSEC use UDP, i found it's efficinecy is lower.
> > my test enviroment: i only run a UDP recieve program and not to handle data
> > recieved. when i recevie 400Mbps data, 79% of MPC8541 have be consumed.
> > so i think tcp/ip protocal have consume my mpc8541 resource. i dont know
> > how to improve tcp/ip code or TSEC driver(gianfar.c).
> > can somebody help me ?
>
> Hmm... you should first try one of the current kernels and check the
> performance there.
> For further details about linux networking, I recommend you to contact
> the guys at the netdev list, giving lots of details how you do your
> benchmarking and how your workload looks like.
>
> Regards,
>
> Clemens Koller
> __________________________________
> R&D Imaging Devices
> Anagramm GmbH
> Rupert-Mayer-Straße 45/1
> Linhof Werksgelände
> D-81379 München
> Tel.089-741518-50
> Fax 089-741518-19
> http://www.anagramm-technology.com
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
^ permalink raw reply
* Revisited, audio codec device tree entries.
From: Jon Smirl @ 2007-11-18 18:10 UTC (permalink / raw)
To: PowerPC dev list
I've been trying to write ALSA SOC code supporting audio codecs and
device trees.
This looks ok for the main device tree entires. Codecs are hung off
from their controlling bus. It may still need a little tweaking.
ac97@2200 { // PSC2
compatible = "mpc5200b-psc-ac97","mpc5200-psc-ac97";
cell-index = <1>;
reg = <2200 100>;
interrupts = <2 2 0>;
interrupt-parent = <&mpc5200_pic>;
codec@0 {
compatible = "idt,stac9766";
reg = <0>;
};
};
i2c@3d40 {
compatible = "mpc5200b-i2c","mpc5200-i2c","fsl-i2c";
reg = <3d40 40>;
interrupts = <2 10 0>;
interrupt-parent = <&mpc5200_pic>;
fsl5200-clocking;
codec@15 {
compatible = "ti,tas5504";
reg = <15>;
i2s-handle = <i2s@2400>;
};
};
i2s@2400 { // PSC4
compatible = "mpc5200b-psc-i2s","mpc5200-psc-i2s";
cell-index = <1>;
reg = <2400 100>;
interrupts = <2 3 0>;
interrupt-parent = <&mpc5200_pic>;
};
In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
A fabric driver tells specifically how a generic codec is wired into
the board. What I haven't been able figure out is how to load the
right fabric driver.
It is starting to make more sense to me that fabric driver actually
does represent a physical device - the cluster of wires. David Gibson
made a proposal that a fabric node wrap the codec node. That doesn't
work very well with the i2c bus where the bus code is walking down the
nodes and triggering the instantiation of the i2c drivers.
But what about putting the fabric node inside the codec node?
codec@15 {
compatible = "ti,tas5504";
reg = <15>;
i2s-handle = <i2s@2400>;
codec-fabric {
compatible = "digispeaker,fabric"
};
};
codec@0 {
compatible = "idt,stac9766";
reg = <0>;
codec-fabric {
compatible = "efika,fabric"
};
};
This sort of makes sense, the ac97/i2c bus is connected to the codec,
which is then connected to the fabric.
The example used in the ALSA doc of an ac97 chip needing a fabric
driver was a case where the ac97 chip has an external amp. The fabric
driver uses a GPIO to turn the amp on/off with suspend/resume.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [BUG] 2.6.24-rc2-mm1 - kernel bug on nfs v4
From: Torsten Kaiser @ 2007-11-18 18: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:
> 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.
No, it does not "correctly" initialize the waitqueue. It doesn't even
try to initialize it.
I now found the guilty patch and what is wrong with it.
nfs-stop-sillyname-renames-and-unmounts-from-racing.patch adds:
@@ -110,8 +112,22 @@ struct nfs_server {
filesystem */
#endif
void (*destroy)(struct nfs_server *);
+
+ atomic_t active; /* Keep trace of any activity to this server */
+ wait_queue_head_t active_wq; /* Wait for any activity to stop */
and tries to initialize it:
@@ -593,6 +593,10 @@ static int nfs_init_server(struct nfs_server *server,
server->namelen = data->namlen;
/* Create a client RPC handle for the NFSv3 ACL management interface */
nfs_init_server_aclclient(server);
+
+ init_waitqueue_head(&server->active_wq);
+ atomic_set(&server->active, 0);
+
and then uses it via nfs_sb_active and nfs_sb_deactive:
@@ -29,6 +29,7 @@ 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);
@@ -151,6 +152,7 @@ static int nfs_do_call_unlink(struct dentry
*parent, struct inode *dir, struct n
nfs_dec_sillycount(dir);
return 0;
}
+ nfs_sb_active(NFS_SERVER(dir));
data->args.fh = NFS_FH(dir);
nfs_fattr_init(&data->res.dir_attr);
But it does not notice this:
struct dentry_operations nfs_dentry_operations = {
.d_revalidate = nfs_lookup_revalidate,
.d_delete = nfs_dentry_delete,
.d_iput = nfs_dentry_iput,
};
struct dentry_operations nfs4_dentry_operations = {
.d_revalidate = nfs_open_revalidate,
.d_delete = nfs_dentry_delete,
.d_iput = nfs_dentry_iput,
};
NFSv2/3 and NFSv4 share the same dentry_iput and so share the same
unlink and sillyrename logic.
But they do not share nfs_init_server()!
I wonder why this doesn't blow up more violently, but only hangs...
But as I don't know if it is correct to add the workqueue
initialization to nfs4_init_server() or remove the nfs_sb_active /
nfs_sb_deactive for the NFSv4 case, I can't offer a patch to fix this.
Torsten
^ permalink raw reply
* Re: [BUG] 2.6.24-rc2-mm1 - kernel bug on nfs v4
From: Trond Myklebust @ 2007-11-18 19:18 UTC (permalink / raw)
To: Torsten Kaiser
Cc: Peter Zijlstra, steved, LKML, Kamalesh Babulal, linuxppc-dev, nfs,
Andrew Morton, Jan Blunck, Ingo Molnar, Balbir Singh
In-Reply-To: <64bb37e0711181044s75fd1081sdf44dac2e060d49a@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3001 bytes --]
On Sun, 2007-11-18 at 19:44 +0100, Torsten Kaiser wrote:
> On Nov 18, 2007 12:05 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> > 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.
>
> No, it does not "correctly" initialize the waitqueue. It doesn't even
> try to initialize it.
>
> I now found the guilty patch and what is wrong with it.
>
> nfs-stop-sillyname-renames-and-unmounts-from-racing.patch adds:
>
> @@ -110,8 +112,22 @@ struct nfs_server {
> filesystem */
> #endif
> void (*destroy)(struct nfs_server *);
> +
> + atomic_t active; /* Keep trace of any activity to this server */
> + wait_queue_head_t active_wq; /* Wait for any activity to stop */
>
> and tries to initialize it:
> @@ -593,6 +593,10 @@ static int nfs_init_server(struct nfs_server *server,
> server->namelen = data->namlen;
> /* Create a client RPC handle for the NFSv3 ACL management interface */
> nfs_init_server_aclclient(server);
> +
> + init_waitqueue_head(&server->active_wq);
> + atomic_set(&server->active, 0);
> +
>
> and then uses it via nfs_sb_active and nfs_sb_deactive:
>
> @@ -29,6 +29,7 @@ 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);
> @@ -151,6 +152,7 @@ static int nfs_do_call_unlink(struct dentry
> *parent, struct inode *dir, struct n
> nfs_dec_sillycount(dir);
> return 0;
> }
> + nfs_sb_active(NFS_SERVER(dir));
> data->args.fh = NFS_FH(dir);
> nfs_fattr_init(&data->res.dir_attr);
>
>
> But it does not notice this:
> struct dentry_operations nfs_dentry_operations = {
> .d_revalidate = nfs_lookup_revalidate,
> .d_delete = nfs_dentry_delete,
> .d_iput = nfs_dentry_iput,
> };
> struct dentry_operations nfs4_dentry_operations = {
> .d_revalidate = nfs_open_revalidate,
> .d_delete = nfs_dentry_delete,
> .d_iput = nfs_dentry_iput,
> };
>
> NFSv2/3 and NFSv4 share the same dentry_iput and so share the same
> unlink and sillyrename logic.
> But they do not share nfs_init_server()!
>
> I wonder why this doesn't blow up more violently, but only hangs...
>
> But as I don't know if it is correct to add the workqueue
> initialization to nfs4_init_server() or remove the nfs_sb_active /
> nfs_sb_deactive for the NFSv4 case, I can't offer a patch to fix this.
>
> Torsten
I had already fixed that one in my own stack. Attached are the 3 patches
that I've got. 1 from SteveD, 2 fixes.
Andrew, could you please unapply the sillyrename patches you've got, and
apply these 3 instead?
Trond
[-- Attachment #2: linux-2.6.24-005-fix_sillyrename_bug_on_umount.dif --]
[-- Type: message/rfc822, Size: 4060 bytes --]
From: Steve Dickson <SteveD@redhat.com>
Subject: NFS: Stop sillyname renames and unmounts from racing
Date: Thu, 08 Nov 2007 04:05:04 -0500
Message-ID: <1195413486.7893.17.camel@heimdal.trondhjem.org>
Added an active/deactive mechanism to the nfs_server structure
allowing async operations to hold off umount until the
operations are done.
Signed-off-by: Steve Dickson <steved@redhat.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
---
fs/nfs/client.c | 4 ++++
fs/nfs/super.c | 13 +++++++++++++
fs/nfs/unlink.c | 2 ++
include/linux/nfs_fs_sb.h | 17 +++++++++++++++++
4 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/fs/nfs/client.c b/fs/nfs/client.c
index 70587f3..2ecf726 100644
--- a/fs/nfs/client.c
+++ b/fs/nfs/client.c
@@ -593,6 +593,10 @@ static int nfs_init_server(struct nfs_server *server,
server->namelen = data->namlen;
/* Create a client RPC handle for the NFSv3 ACL management interface */
nfs_init_server_aclclient(server);
+
+ init_waitqueue_head(&server->active_wq);
+ atomic_set(&server->active, 0);
+
dprintk("<-- nfs_init_server() = 0 [new %p]\n", clp);
return 0;
diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index 71067d1..833aed8 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -202,6 +202,7 @@ static int nfs_get_sb(struct file_system_type *, int, const char *, void *, stru
static int nfs_xdev_get_sb(struct file_system_type *fs_type,
int flags, const char *dev_name, void *raw_data, struct vfsmount *mnt);
static void nfs_kill_super(struct super_block *);
+static void nfs_put_super(struct super_block *);
static struct file_system_type nfs_fs_type = {
.owner = THIS_MODULE,
@@ -223,6 +224,7 @@ static const struct super_operations nfs_sops = {
.alloc_inode = nfs_alloc_inode,
.destroy_inode = nfs_destroy_inode,
.write_inode = nfs_write_inode,
+ .put_super = nfs_put_super,
.statfs = nfs_statfs,
.clear_inode = nfs_clear_inode,
.umount_begin = nfs_umount_begin,
@@ -1772,6 +1774,17 @@ static void nfs4_kill_super(struct super_block *sb)
nfs_free_server(server);
}
+static void nfs_put_super(struct super_block *sb)
+{
+ struct nfs_server *server = NFS_SB(sb);
+ /*
+ * Make sure there are no outstanding ops to this server.
+ * If so, wait for them to finish before allowing the
+ * unmount to continue.
+ */
+ wait_event(server->active_wq, atomic_read(&server->active) == 0);
+}
+
/*
* Clone an NFS4 server record on xdev traversal (FSID-change)
*/
diff --git a/fs/nfs/unlink.c b/fs/nfs/unlink.c
index 233ad38..cf12a24 100644
--- a/fs/nfs/unlink.c
+++ b/fs/nfs/unlink.c
@@ -29,6 +29,7 @@ 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);
@@ -151,6 +152,7 @@ static int nfs_do_call_unlink(struct dentry *parent, struct inode *dir, struct n
nfs_dec_sillycount(dir);
return 0;
}
+ nfs_sb_active(NFS_SERVER(dir));
data->args.fh = NFS_FH(dir);
nfs_fattr_init(&data->res.dir_attr);
diff --git a/include/linux/nfs_fs_sb.h b/include/linux/nfs_fs_sb.h
index 0cac49b..6ef3af8 100644
--- a/include/linux/nfs_fs_sb.h
+++ b/include/linux/nfs_fs_sb.h
@@ -4,6 +4,8 @@
#include <linux/list.h>
#include <linux/backing-dev.h>
+#include <asm/atomic.h>
+
struct nfs_iostats;
/*
@@ -110,8 +112,23 @@ struct nfs_server {
filesystem */
#endif
void (*destroy)(struct nfs_server *);
+
+ atomic_t active; /* Keep trace of any activity to this server */
+ wait_queue_head_t active_wq; /* Wait for any activity to stop */
};
+static inline void
+nfs_sb_active(struct nfs_server *server)
+{
+ atomic_inc(&server->active);
+}
+static inline void
+nfs_sb_deactive(struct nfs_server *server)
+{
+ if (atomic_dec_and_test(&server->active))
+ wake_up(&server->active_wq);
+}
+
/* Server capabilities */
#define NFS_CAP_READDIRPLUS (1U << 0)
#define NFS_CAP_HARDLINKS (1U << 1)
[-- Attachment #3: linux-2.6.24-006-fix_to_fix_sillyrename_bug_on_umount.dif --]
[-- Type: message/rfc822, Size: 4205 bytes --]
From: Trond Myklebust <Trond.Myklebust@netapp.com>
Subject: NFS: Fix up problems with Steve's sillyrename fix
Date: Sat, 17 Nov 2007 13:08:49 -0500
Message-ID: <1195413486.7893.18.camel@heimdal.trondhjem.org>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
---
fs/nfs/client.c | 6 +++---
fs/nfs/internal.h | 2 ++
fs/nfs/super.c | 33 ++++++++++++++++++++++-----------
fs/nfs/unlink.c | 2 ++
include/linux/nfs_fs_sb.h | 13 +------------
5 files changed, 30 insertions(+), 26 deletions(-)
diff --git a/fs/nfs/client.c b/fs/nfs/client.c
index 2ecf726..be9fecb 100644
--- a/fs/nfs/client.c
+++ b/fs/nfs/client.c
@@ -594,9 +594,6 @@ static int nfs_init_server(struct nfs_server *server,
/* Create a client RPC handle for the NFSv3 ACL management interface */
nfs_init_server_aclclient(server);
- init_waitqueue_head(&server->active_wq);
- atomic_set(&server->active, 0);
-
dprintk("<-- nfs_init_server() = 0 [new %p]\n", clp);
return 0;
@@ -736,6 +733,9 @@ static struct nfs_server *nfs_alloc_server(void)
INIT_LIST_HEAD(&server->client_link);
INIT_LIST_HEAD(&server->master_link);
+ init_waitqueue_head(&server->active_wq);
+ atomic_set(&server->active, 0);
+
server->io_stats = nfs_alloc_iostats();
if (!server->io_stats) {
kfree(server);
diff --git a/fs/nfs/internal.h b/fs/nfs/internal.h
index f3acf48..7579379 100644
--- a/fs/nfs/internal.h
+++ b/fs/nfs/internal.h
@@ -160,6 +160,8 @@ extern struct rpc_stat nfs_rpcstat;
extern int __init register_nfs_fs(void);
extern void __exit unregister_nfs_fs(void);
+extern void nfs_sb_active(struct nfs_server *server);
+extern void nfs_sb_deactive(struct nfs_server *server);
/* namespace.c */
extern char *nfs_path(const char *base,
diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index 833aed8..046d1ac 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -327,6 +327,28 @@ void __exit unregister_nfs_fs(void)
unregister_filesystem(&nfs_fs_type);
}
+void nfs_sb_active(struct nfs_server *server)
+{
+ atomic_inc(&server->active);
+}
+
+void nfs_sb_deactive(struct nfs_server *server)
+{
+ if (atomic_dec_and_test(&server->active))
+ wake_up(&server->active_wq);
+}
+
+static void nfs_put_super(struct super_block *sb)
+{
+ struct nfs_server *server = NFS_SB(sb);
+ /*
+ * Make sure there are no outstanding ops to this server.
+ * If so, wait for them to finish before allowing the
+ * unmount to continue.
+ */
+ wait_event(server->active_wq, atomic_read(&server->active) == 0);
+}
+
/*
* Deliver file system statistics to userspace
*/
@@ -1774,17 +1796,6 @@ static void nfs4_kill_super(struct super_block *sb)
nfs_free_server(server);
}
-static void nfs_put_super(struct super_block *sb)
-{
- struct nfs_server *server = NFS_SB(sb);
- /*
- * Make sure there are no outstanding ops to this server.
- * If so, wait for them to finish before allowing the
- * unmount to continue.
- */
- wait_event(server->active_wq, atomic_read(&server->active) == 0);
-}
-
/*
* Clone an NFS4 server record on xdev traversal (FSID-change)
*/
diff --git a/fs/nfs/unlink.c b/fs/nfs/unlink.c
index cf12a24..b97d3bb 100644
--- a/fs/nfs/unlink.c
+++ b/fs/nfs/unlink.c
@@ -14,6 +14,8 @@
#include <linux/sched.h>
#include <linux/wait.h>
+#include "internal.h"
+
struct nfs_unlinkdata {
struct hlist_node list;
struct nfs_removeargs args;
diff --git a/include/linux/nfs_fs_sb.h b/include/linux/nfs_fs_sb.h
index 6ef3af8..9f949b5 100644
--- a/include/linux/nfs_fs_sb.h
+++ b/include/linux/nfs_fs_sb.h
@@ -3,6 +3,7 @@
#include <linux/list.h>
#include <linux/backing-dev.h>
+#include <linux/wait.h>
#include <asm/atomic.h>
@@ -117,18 +118,6 @@ struct nfs_server {
wait_queue_head_t active_wq; /* Wait for any activity to stop */
};
-static inline void
-nfs_sb_active(struct nfs_server *server)
-{
- atomic_inc(&server->active);
-}
-static inline void
-nfs_sb_deactive(struct nfs_server *server)
-{
- if (atomic_dec_and_test(&server->active))
- wake_up(&server->active_wq);
-}
-
/* Server capabilities */
#define NFS_CAP_READDIRPLUS (1U << 0)
#define NFS_CAP_HARDLINKS (1U << 1)
[-- Attachment #4: linux-2.6.24-007-fix_nfs_free_unlinkdata.dif --]
[-- Type: message/rfc822, Size: 1255 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: <1195413486.7893.19.camel@heimdal.trondhjem.org>
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);
}
[-- Attachment #5: series --]
[-- Type: text/plain, Size: 231 bytes --]
# This series applies on GIT commit 4c1fe2f78a08e2c514a39c91a0eb7b55bbd3c0d2
linux-2.6.24-005-fix_sillyrename_bug_on_umount.dif
linux-2.6.24-006-fix_to_fix_sillyrename_bug_on_umount.dif
linux-2.6.24-007-fix_nfs_free_unlinkdata.dif
^ permalink raw reply related
* Re: Revisited, audio codec device tree entries.
From: Segher Boessenkool @ 2007-11-18 20:16 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910711181010q50c08d2ek8413af74d58cf0ce@mail.gmail.com>
> ac97@2200 { // PSC2
> compatible = "mpc5200b-psc-ac97","mpc5200-psc-ac97";
> cell-index = <1>;
> reg = <2200 100>;
> interrupts = <2 2 0>;
> interrupt-parent = <&mpc5200_pic>;
You need #address-cells, #size-cells here.
> codec@0 {
> compatible = "idt,stac9766";
> reg = <0>;
> };
> };
>
> i2c@3d40 {
> compatible = "mpc5200b-i2c","mpc5200-i2c","fsl-i2c";
> reg = <3d40 40>;
> interrupts = <2 10 0>;
> interrupt-parent = <&mpc5200_pic>;
> fsl5200-clocking;
And here.
> codec@15 {
> compatible = "ti,tas5504";
> reg = <15>;
> i2s-handle = <i2s@2400>;
Should use an alias here (or the full path, if that works).
> };
> };
>
> i2s@2400 { // PSC4
> compatible = "mpc5200b-psc-i2s","mpc5200-psc-i2s";
> cell-index = <1>;
> reg = <2400 100>;
> interrupts = <2 3 0>;
> interrupt-parent = <&mpc5200_pic>;
> };
>
> In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
> A fabric driver tells specifically how a generic codec is wired into
> the board. What I haven't been able figure out is how to load the
> right fabric driver.
Whatever way works for the platform.
> It is starting to make more sense to me that fabric driver actually
> does represent a physical device - the cluster of wires.
That's only part of it, as far as I understand.
> David Gibson
> made a proposal that a fabric node wrap the codec node. That doesn't
> work very well with the i2c bus where the bus code is walking down the
> nodes and triggering the instantiation of the i2c drivers.
Yeah, doesn't work at all.
> But what about putting the fabric node inside the codec node?
_Which_ codec node? Having more than one isn't uncommon at all.
There is no way you can describe this fabric stuff in a generic way in
the device tree. Just hardcode it in your platform support code; if
the platform code supports several variant boards, _it_ can probe that
from the device tree (in whatever way works for that platform).
Segher
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Jon Smirl @ 2007-11-18 21:49 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: PowerPC dev list
In-Reply-To: <0fd3304ee694b2dc6a8f3055c08dc015@kernel.crashing.org>
On 11/18/07, Segher Boessenkool <segher@kernel.crashing.org> wrote:
> > David Gibson
> > made a proposal that a fabric node wrap the codec node. That doesn't
> > work very well with the i2c bus where the bus code is walking down the
> > nodes and triggering the instantiation of the i2c drivers.
>
> Yeah, doesn't work at all.
>
> > But what about putting the fabric node inside the codec node?
>
> _Which_ codec node? Having more than one isn't uncommon at all.
In all of them. Fabric can probably be split into pieces that
corresponds to the codec.
> There is no way you can describe this fabric stuff in a generic way in
> the device tree. Just hardcode it in your platform support code; if
> the platform code supports several variant boards, _it_ can probe that
> from the device tree (in whatever way works for that platform).
The codec-fabric node was just being used to trigger the loading of
the platform specific driver.
>
>
> Segher
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH 4/21] ide/Kconfig: fix mpc8xx host driver dependencies
From: Bartlomiej Zolnierkiewicz @ 2007-11-18 22:15 UTC (permalink / raw)
To: linux-ide; +Cc: linuxppc-dev
Only LWMON, IVMS8, IVML24 and TQM8xxL platforms have the needed
defines (IDE0_BASE_OFFSET and friends) in the platform header file.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
drivers/ide/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ide/Kconfig
===================================================================
--- a/drivers/ide/Kconfig
+++ b/drivers/ide/Kconfig
@@ -951,7 +951,7 @@ config BLK_DEV_Q40IDE
config BLK_DEV_MPC8xx_IDE
bool "MPC8xx IDE support"
- depends on 8xx && IDE=y && BLK_DEV_IDE=y && !PPC_MERGE
+ depends on 8xx && (LWMON || IVMS8 || IVML24 || TQM8xxL) && IDE=y && BLK_DEV_IDE=y && !PPC_MERGE
select IDE_GENERIC
help
This option provides support for IDE on Motorola MPC8xx Systems.
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Matt Sealey @ 2007-11-18 22:46 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910711181349q1f840bc2w8d30bb33d2a353ce@mail.gmail.com>
Jon Smirl wrote:
>
> The codec-fabric node was just being used to trigger the loading of
> the platform specific driver.
Just remember one thing.
1) the term "fabric" when coined for audio drivers is a new, ALSA SoC
specific term. It isn't relevant for anything but ALSA SoC drivers.
2) this device tree stuff will end up in more than Linux device trees
3) you're going to piss off Open Firmware developers by specifying
very Linux-specific features in a device tree the same way Apple
pissed off Linux developers by encoding MacOS X-specific features in
the device tree.
Audio driver control like this has to be very specific for a good
reason; you can do it a billion ways to Sunday. I'd suggest basically
that if you must control a device in a way that needs to be defined by
a device which can change address (either dynamically on boot or by
board design change - per revision, for example, or with a change of
controller) then simply use the device tree to report this address
so that you can have the same basic fabric driver (all in Linux) which
can handle minor modifications of your board design.
If you require the codec to be subservient to some "fabric" then I
suggest you make a "sound" node with a compatible entry which is
defined as something specific to your board (digispeaker,audio) and
let your driver pick that up and then switch on the model (rather like
Apple's layout-id) of that device to pick out the specifics of that
fabric. If it needs an audio codec (ac97 or i2s) and a control
interface (i2c or spi) then it knows which ones it is looking for
based on the model.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* 2.6.24-rc3: High CPU load -- hardware interrupts
From: Jörg Sommer @ 2007-11-18 21:53 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I've installed the new kernel version and now suspend to RAM works. But I
saw that the CPU load is everytime 50% due to hardware interrupts. Is
this a known bug?
top - 22:51:19 up 21:58, 8 users, load average: 0.36, 0.39, 0.40
Tasks: 66 total, 4 running, 62 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.7%us, 0.5%sy, 11.2%ni, 27.0%id, 0.0%wa, 60.6%hi, 0.0%si, 0.0%st
% diff <(cat /proc/interrupts) <(sleep 2; cat /proc/interrupts)
--- /proc/self/fd/11 2007-11-18 13:02:25.204839099 +0100
+++ /proc/self/fd/13 2007-11-18 13:02:25.228832847 +0100
@@ -1,16 +1,16 @@
CPU0
21: 1 MPIC 1 Edge PMac Output
24: 68 MPIC 1 Level ide1
- 25: 1337463 MPIC 1 Level VIA-PMU
+ 25: 1337690 MPIC 1 Level VIA-PMU
26: 378 MPIC 1 Level keywest i2c
29: 1 MPIC 1 Level ohci_hcd:usb2
30: 1 MPIC 1 Edge PMac Input
39: 249347 MPIC 1 Level ide0
40: 3 MPIC 1 Level ohci1394
41: 3454 MPIC 1 Level eth0
- 42: 30782 MPIC 1 Level keywest i2c
- 47: 22021 MPIC 1 Level GPIO1 ADB
- 48: 23892 MPIC 1 Level radeon@pci:0000:00:10.0
+ 42: 30800 MPIC 1 Level keywest i2c
+ 47: 22049 MPIC 1 Level GPIO1 ADB
+ 48: 24014 MPIC 1 Level radeon@pci:0000:00:10.0
61: 0 MPIC 1 Edge Sound Headphone Detection
63: 94237 MPIC 1 Level ehci_hcd:usb1, ohci_hcd:usb3, ohci_hcd:usb4
BAD: 0
% cat /proc/cpuinfo
processor : 0
cpu : 7455, altivec supported
clock : 798.720000MHz
revision : 0.3 (pvr 8001 0303)
bogomips : 48.41
timebase : 18432000
platform : PowerMac
machine : PowerBook6,3
motherboard : PowerBook6,3 MacRISC3 Power Macintosh
detected as : 287 (iBook G4)
pmac flags : 0000001b
L2 cache : 256K unified
pmac-generation : NewWorld
% uname -a
Linux ibook 2.6.24-rc3 #1 Sat Nov 17 16:06:21 CET 2007 ppc GNU/Linux
Bye, Jörg.
--
Es liegt in der Natur des Menschen, vernünftig zu denken und
unlogisch zu handeln! Das Gesagte ist nicht das Gemeinte und das Gehörte
nicht das Verstandene!
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Matt Sealey @ 2007-11-18 23:31 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <4740C0E3.5080704@genesi-usa.com>
Matt Sealey wrote:
> Jon Smirl wrote:
>
> If you require the codec to be subservient to some "fabric" then I
> suggest you make a "sound" node with a compatible entry which is
> defined as something specific to your board (digispeaker,audio) and
> let your driver pick that up and then switch on the model (rather like
> Apple's layout-id) of that device to pick out the specifics of that
> fabric. If it needs an audio codec (ac97 or i2s) and a control
> interface (i2c or spi) then it knows which ones it is looking for
> based on the model.
Sigh, I suck, I forgot the example :D
And I forgot the rant you guys usually get - for god's sake, why isn't
anyone using the "model" property? Do I have to whine about this some
more to get your attention, guys? name, device_type, compatible and
model are your tools for building device trees and detecting
things. That's FOUR unique properties.
How come I only see device trees defined using "name", with the same
device_type, and "compatible"? This is braindead design.
Why is every example device tree I see defining weird little extra
nodes for anything and everything that some driver API exposes? If
you want to expose a grand new kind of driver fabric like ALSA SoC
wants, put your codec in the tree, and give it a model property
with your unique name.
I'd suggest something like this:
sound@0 {
\\ this is our magic audio fabric
device_type = "digispeaker,flinger";
\\ it's actually just an i2s pcm codec
compatible = "mpc5200-psc-i2s";
\\ and this defines the layout Jon picked for the DACs
\\ just like Apple's layout-id value
model = "flinger,2"
codec@15 {
compatible = "TXN,tas5504";
codec-control = <&codec-control>;
}
\\ and every i2s driver on the planet will just ignore these
\\ unless it's one of our boards
digispeaker,amp-control = <&-control>
}
Then you control the fabric for your boards and get to attach
whatever the hell you want to those codecs, control interfaces
and special little tweak features you always wanted.
Be careful cross-referencing devices with each other,
for instance in your example you made the i2c codec device
point back to an i2s handle - it's a good idea, but not well
executed in my opinion as it lacks context.
Isn't the primary concern of an audio codec, to play audio?
Therefore, shouldn't the audio codec point back to it's control
interface? Also, why give the name as 'i2s-handle'? Surely it
could be any interface. In reverse, it would be, perhaps, as
above, i2c-handle, but then what if you change the interface
type (for instance a bunch of Wolfson codecs can do i2c and
spi for control). Your property name is obselete, then and
drivers will need to switch on property names to find out
which control interface is present.
What they should really do, is be told where their control
interface handle is, then you can look at that handle and
the device it contains - that device itself will tell you the
bus type, any devices under it, and any quirky things you
need to do besides (above, &codec-control etc. would point to
i2c@3d40 {
codec-control@15 {
blah
}
}
spi@beef {
codec-control@19 {
blah
}
}
gpio@cafe {
amp-control@0 {
compatible = "gpio-bit";
bit = "1";
open-drain;
}
}
If you couldn't tell it's a device on an i2c bus then you
are coding your driver badly. And you can have lots of
codecs, and just back reference which control interface
they have. I dunno.
Remember, it doesn't matter what NAME you give it, the name
is for people to read, device_type is what you search for,
and phandles let you attach specific devices to each other.
compatible is for when you want to tell people "it acts the
same as this" and model is to give you the enviable ability
to define PRECISELY what you are looking at beyond a chip
name. I'd suggest we use all of them for great justice.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ 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