From: Zhang Zhen Subject: Re: [RFC] With 8250 Designware UART, if writes to the LCR failed the kernel will hung up Date: Wed, 11 Mar 2015 09:20:19 +0800 Message-ID: <54FF9853.2060105@huawei.com> References: <54F96F5B.2090601@huawei.com> <54F9DACA.3020103@hurleysoftware.com> <54FD4779.3020902@huawei.com> <1425907939.3838.182.camel@linux.intel.com> <1425913502.3838.185.camel@linux.intel.com> <54FEF0B0.6010002@hurleysoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <54FEF0B0.6010002@hurleysoftware.com> Sender: linux-kernel-owner@vger.kernel.org To: Peter Hurley Cc: Tim Kryger , Alan Cox , "long.wanglong" , linux-serial@vger.kernel.org, Linux Kernel Mailing List , gregkh@linuxfoundation.org, Jamie Iles , Arnd Bergmann , shenjiangjiang@huawei.com, Wang Kai List-Id: linux-serial@vger.kernel.org On 2015/3/10 21:25, Peter Hurley wrote: > On 03/09/2015 10:47 PM, Tim Kryger wrote: >> The current workaround of clearing fifos and retrying a fixed number >> of times isn't ideal but I'm not sure what else can be done given th= e >> way this hardware works. >=20 > But hanging the machine is not an acceptable outcome. >=20 > Since the hang stems from the printk while already holding the port->= lock, > until I can fix the console write, I think it's best to comment out > the dev_err() with a FIXME note. Yeah=EF=BC=8Ci agree. >=20 > The 8250 console write already checks port->sysrq to allow printk fro= m > within the driver so this solution just needs to be generalized. > And there are debug uses of printk() from within the driver that are = just > as broken, so this isn't the only use case. (I want to do something > similar for the au_serial-* i/o accessors too). >=20 > Regards, > Peter Hurley >=20 >=20 >=20 > . >=20