[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201103181524.33246.arnd@arndb.de>
Date: Fri, 18 Mar 2011 15:24:33 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Michael Karcher <kernel@...rcher.dialup.fu-berlin.de>
Cc: Udo van den Heuvel <udovdh@...all.nl>,
Karsten Keil <isdn@...ux-pingi.de>, Greg KH <gregkh@...e.de>,
linux-kernel@...r.kernel.org, Alan Cox <alan@...ux.intel.com>,
Tilman Schmidt <tilman@...p.cc>, stable@...nel.org
Subject: Re: known vboxgetty/isdn issue in 2.6.35.3?
On Thursday 17 March 2011, Michael Karcher wrote:
> The same issue happened on our system. Sometimes vboxgetty gets stuck in
> state D on a debian stable system (2.6.32). I just applied your patch to
> that kernel and hope the problem went away. Please remind me to report
> back in one to two weeks if I didn't already report whether the hangs
> are fixed. Is something except for a test on a productive system missing
> to get this fix into 32-stable?
Thanks for the report. You are talking about this patch, right?
bc10f96757 "isdn: avoid calling tty_ldisc_flush() in atomic context"
Remove the call to tty_ldisc_flush() from the RESULT_NO_CARRIER
branch of isdn_tty_modem_result(), as already proposed in commit
00409bb045887ec5e7b9e351bc080c38ab6bfd33.
This avoids a "sleeping function called from invalid context" BUG
when the hardware driver calls the statcallb() callback with
command==ISDN_STAT_DHUP in atomic context, which in turn calls
isdn_tty_modem_result(RESULT_NO_CARRIER, ~), and from there,
tty_ldisc_flush() which may sleep.
Signed-off-by: Tilman Schmidt <tilman@...p.cc>
Signed-off-by: David S. Miller <davem@...emloft.net>
Arnd
--
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