[0/2] tty: serial: imx: fix lockup and garbage on SMP

Commit Message

Dirk Behme Aug. 27, 2012, 7:36 a.m. UTC

The following two patches are a port from Freescale's patch

http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/drivers/tty/serial/imx.c?h=imx_3.0.15_android&id=80e525d66d1818722db18e21dc7f1dc41f314156

Using a 3.6-rc3 kernel on a i.MX6 SabreLite board and increasing the
verbosity of the kernel's serial console output with some debug printk
like [1] results in two issues:

1. After some time the kernel output hangs [2]. The debugger tells us that
it hangs in drivers/tty/serial/imx.c at

...
/*
 *	Finally, wait for transmitter to become empty
 *	and restore UCR1/2/3
 */
while (!(readl(sport->port.membase + USR2) & USR2_TXDC));
...

with permanently reading 0x1000 from USR2 while it waits for bit USR2_TXDC
(0x8).

2. Even after applying the first patch, there happens to be some garbage in the
   output [3].

Both issues are gone applying these two patches.

Note: If these patches are fine, they should go to stable, too.

Best regards

Dirk

[1]


[2]
...
=> mmap_region: start: 0x76DBC000 end: 0x76DBE000 len: 8192
=> mmap_region: start: 0x76DBE000 end: 0x76DC0000 len: 8192
=> mmap_region: start: 0x76D5C000 end: 0x76DA0000 ÿ
<hang, no output any more>

[3]
...
=> mmap_region: start: 0x0011C000 end: 0x0011D000 len: 4096
=> mmap_region: start: 0x00008000 end: 0x000B500fè#.Æ ÄRèérêòjµ…Á}ɝ¥½¹é start: 0x000BD000 end: 0x000BE000 len: 4096
=> mmap_region: start: 0x000BD000 end: 0x000BE000 len: 4096
...

Comments

Shawn Guo Aug. 27, 2012, 10:31 p.m. UTC | #1

On Mon, Aug 27, 2012 at 09:36:50AM +0200, Dirk Behme wrote:
> Both issues are gone applying these two patches.
> 
> Note: If these patches are fine, they should go to stable, too.
> 
Then you should have Cc: <[e-mail]> tag on these patches.

Greg Kroah-Hartman Aug. 27, 2012, 10:51 p.m. UTC | #2

On Tue, Aug 28, 2012 at 06:31:35AM +0800, Shawn Guo wrote:
> On Mon, Aug 27, 2012 at 09:36:50AM +0200, Dirk Behme wrote:
> > Both issues are gone applying these two patches.
> > 
> > Note: If these patches are fine, they should go to stable, too.
> > 
> Then you should have Cc: <[e-mail]> tag on these patches.

On both of them?  I can do that if needed.  How far back should they go?

greg k-h

Shawn Guo Aug. 27, 2012, 11:37 p.m. UTC | #3

On Mon, Aug 27, 2012 at 03:51:42PM -0700, Greg Kroah-Hartman wrote:
> On both of them?  I can do that if needed.  How far back should they go?
> 
It should be okay to apply on 3.4 and 3.5.  But patch #2 is still in
question.  I do not like the #ifdef.

Dirk Behme Aug. 28, 2012, 6:03 a.m. UTC | #4

On 28.08.2012 01:37, Shawn Guo wrote:
> On Mon, Aug 27, 2012 at 03:51:42PM -0700, Greg Kroah-Hartman wrote:
>> On both of them?  I can do that if needed.  How far back should they go?
>>
> It should be okay to apply on 3.4 and 3.5. 

For patch #1/2: Yes, thanks!

> But patch #2 is still in
> question.  I do not like the #ifdef.

For patch #2/2: Yes, understood. I'll look at Troy's proposal and will 
update #2/2.

Many thanks and best regards

Dirk

Patch

Index: a/mm/mmap.c
===================================================================
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1290,6 +1290,9 @@  munmap_back:
 	vma->vm_pgoff = pgoff;
 	INIT_LIST_HEAD(&vma->anon_vma_chain);
 
+	printk(" => mmap_region: start: 0x%08X end: 0x%08X len: %d\n",
+		(unsigned int)vma->vm_start, (unsigned int)vma->vm_end, (int)len);
+
 	error = -EINVAL;	/* when rejecting VM_GROWSDOWN|VM_GROWSUP */
 
 	if (file) {