[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a781481a0705112245u356759dcm9a550e432ed178fd@mail.gmail.com>
Date: Sat, 12 May 2007 11:15:43 +0530
From: "Satyam Sharma" <satyam.sharma@...il.com>
To: "Dmitry Torokhov" <dtor@...ightbb.com>
Cc: "Andrew Morton" <akpm@...ux-foundation.org>,
"Matt Mackall" <mpm@...enic.com>, rlove@...ve.org,
linux-kernel@...r.kernel.org, "Ingo Molnar" <mingo@...e.hu>
Subject: Re: 2.6.21-mm2: HDAPS? BUG: at kernel/mutex.c:311
Hi Dmitry,
On 5/12/07, Dmitry Torokhov <dtor@...ightbb.com> wrote:
> On Friday 11 May 2007 20:53, Andrew Morton wrote:
> > Ho hum. I suppose a suitable workaround would be to convert hdaps_mtx back
> > into a semaphore. ug.
>
> Actually I was looking for victimes^Wvolunteers to test the patch below.
> It gets rid of _trylock business.
Ah! You just beat me here, and your patch is definitely better.
I was wondering why this driver wanted to use a mutex (previously the
semaphore) to synchronize between process and interrupt context in the
first place. Most of the code in here uses synchronous delays so never
sleeps anyway, but then unfortunately it does a weird
repeated-waiting-hardware-status-register-check thingy in its .probe()
which meant a straightforward mutex -> spinlock wasn't possible.
So then made a patch pushing off the poll to keventd workqueue, when
I saw your mail that does exactly the same, but wrapped about in the
generic input-polldev infrastructure! It's barely 12 days old in mainline --
no wonder I didn't know about it. Seems to be good-looking code!
Thanks,
Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists