OESF | ELSI | pdaXrom | OpenZaurus | Zaurus Themes | Community Links | Ibiblio

IPB

Welcome Guest ( Log In | Register )

2 Pages V   1 2 >  
Reply to this topicStart new topic
> Console Response After Running X, slow console response after quitting X
wilkes
post Jun 13 2006, 06:11 AM
Post #1





Group: Members
Posts: 4
Joined: 2-April 05
Member No.: 6,772



I'm running a 03-Jun-06 snap, but I noticed this behavior on the 3.9 release as well.

When I run startx (or startxfec4) from the console and subsequently quit X and return to the console, response sucks; noticeable lag echoing typed characters, etc. It's bad enough that I have to reboot to get a normal acting console again.

Anyone else seeing this? Is there a cure? (Other than always rebooting after X, that is...)

-jw-
Go to the top of the page
 
+Quote Post
iamasmith
post Jun 13 2006, 06:43 AM
Post #2





Group: Members
Posts: 1,248
Joined: 6-July 04
Member No.: 3,928



Yes, it's well known. I don't know if anybody is tackling it.

I always use vt02 after running an X session since the second vt is unaffected. Ctrl-Alt-F2 for vt02, Ctrl-Alt-F1 to switch back to vt01.

Remember to switch back to vt01 before running X though.


p.s. you can switch to vt02 whilst running X on vt01 if you just want a text console quickly smile.gif

-Andy
Go to the top of the page
 
+Quote Post
TronDD
post Jun 13 2006, 06:08 PM
Post #3





Group: Members
Posts: 53
Joined: 6-January 05
Member No.: 6,137



Cool! I didn't know virtual terminal switching worked. I didn't realize the program keys were just F keys until recently so I never even thought terminal switching was possible.

And yeah, using the terminal after X sucks.
Go to the top of the page
 
+Quote Post
iamasmith
post Jun 14 2006, 12:40 AM
Post #4





Group: Members
Posts: 1,248
Joined: 6-July 04
Member No.: 3,928



zkbd(4) man page is well worth a read if you haven't already smile.gif

-Andy
Go to the top of the page
 
+Quote Post
mathemajikian
post Jul 30 2006, 04:44 AM
Post #5





Group: Members
Posts: 304
Joined: 8-July 06
From: United Kingdom for now....
Member No.: 10,349



This is still an issue. What could be the cause of this? Is X not flushing the framebuffer correctly when exiting?
Go to the top of the page
 
+Quote Post
iamasmith
post Jul 31 2006, 07:38 AM
Post #6





Group: Members
Posts: 1,248
Joined: 6-July 04
Member No.: 3,928



It's not X specifically, the problem also occurs when using ztsscale.

I would like to get to the bottom of this and may have some time to devote to finding the culprit soon. tongue.gif

-Andy
Go to the top of the page
 
+Quote Post
mathemajikian
post Jul 31 2006, 11:34 AM
Post #7





Group: Members
Posts: 304
Joined: 8-July 06
From: United Kingdom for now....
Member No.: 10,349



I have noticed that if I just let the Z sit for about 5 minutes the console response returns to normal.



QUOTE(iamasmith @ Jul 31 2006, 03:38 PM)
It's not X specifically, the problem also occurs when using ztsscale.

I would like to get to the bottom of this and may have some time to devote to finding the culprit soon. tongue.gif

-Andy
*
Go to the top of the page
 
+Quote Post
coreilly
post Jul 31 2006, 04:04 PM
Post #8





Group: Members
Posts: 65
Joined: 10-November 05
Member No.: 8,517



Just tried it on my c3200, running last 3.9 snapshot before 4.0 was released... left it for 5-10 minutes.. still choppy.. a bit better. will leave it for longer and see.
Go to the top of the page
 
+Quote Post
iamasmith
post Aug 2 2006, 02:03 AM
Post #9





Group: Members
Posts: 1,248
Joined: 6-July 04
Member No.: 3,928



mmmm, think I have found it. Thankfully it isn't a kernel problem... going to rebuild X and some stuff to test it out before I start pointing fingers though.
Go to the top of the page
 
+Quote Post
iamasmith
post Aug 2 2006, 02:28 AM
Post #10





Group: Members
Posts: 1,248
Joined: 6-July 04
Member No.: 3,928



ah maybe that isn't the problem... digging a little deeper now.
Go to the top of the page
 
+Quote Post
iamasmith
post Aug 2 2006, 07:23 AM
Post #11





Group: Members
Posts: 1,248
Joined: 6-July 04
Member No.: 3,928



Actually this does look like a kernel related issue.

The display is actually handled via DMA from certain memory mapped regions (one for eash wsdisplay screen).

It appears that following an access to the bitmap returned by mmap of the frame buffer (used to gain access to the memory map) of /dev/ttyC0 the cache coherency is swictched off. This essentially means that DMA transfer to the screen for this region is subject to cache rather than immediate write through from this point onwards.

Since the bitmap for ttyC1 hasn't been touched in this manner this appears to be why the second VT is unaffected.

Interestingly enough the mmap call handler for the lcd device does actually specify that DMA should be coherent. The coherency seems to be being dropped when the mmap is being freed.

I tested this with the following test program.

CODE
#include <sys/param.h>
#include <sys/mman.h>
#include <sys/ioctl.h>
#include <sys/sysctl.h>
#include <machine/cpu.h>
#include <dev/wscons/wsconsio.h>

#include <err.h>
#include <fcntl.h>
#include <math.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

#include <stdio.h>

#define WIDTH   640
#define HEIGHT  480

main()
{
       u_short         *mapaddr;
       u_short         *tptr;
       int fd;
       u_short nTval;
       int nCount1,nCount2,nCount3;
       int mode = WSDISPLAYIO_MODE_DUMBFB;

/* Open the display */
       fd = open("/dev/ttyC0", O_RDWR);
       if (fd < 0)
               err(2, "open /dev/ttyC0");

       if (ioctl(fd, WSDISPLAYIO_SMODE, &mode) == -1)
               warn("ioctl SMODE");
       mapaddr = (void *)mmap(0, WIDTH*HEIGHT*sizeof(short),
           PROT_READ|PROT_WRITE, MAP_SHARED, fd, (off_t)0);
       if (mapaddr == (void *)-1)
               err(2, "mmap");

/* Our simple test pattern flash 12 blue stripes 5 times with 2 second gaps */

       nTval=0;
       for (nCount1=0;nCount1<10;nCount1++) {
               nTval^=0x00ff;  /* toggle nTval */
               tptr=mapaddr;
               for (nCount2=0;nCount2<12;nCount2++) {
                       for (nCount3=0;nCount3<480;nCount3++)
                               *(tptr++)=nTval;
                       tptr+=25*2*480; /* Skip 25 raster lines */
               }
               sleep(2);
       }


       mode = WSDISPLAYIO_MODE_EMUL;

       munmap((void*) mapaddr,WIDTH*HEIGHT*sizeof(short));

       if (ioctl(fd, WSDISPLAYIO_SMODE, &mode) == -1)
               warn("ioctl SMODE");
}


The stripes are there to generate some non sequential access so that the DMA controller doesn't simply burst the updates and generate a false test pattern. If the coherency was missing at this stage then we may expect to see some graphical artifacts in the stripes, potentially at the end of the stripes. We don't see this so I surmise that coherency is enabled for the DMA when the frame buffer is in bitmapped mode.

I am now looking at why coherency seems to be disabled when the region is unmapped... incidentally the X server seems to omit the unmap call (and for that matter the call to free the buffer that it uses to preserve the screen contents). This obviously has little bearing upon the issue being observed.

-Andy
Go to the top of the page
 
+Quote Post
coreilly
post Aug 2 2006, 08:25 AM
Post #12





Group: Members
Posts: 65
Joined: 10-November 05
Member No.: 8,517



I have absolutely no idea what that means but thanks again for all your work Andy! smile.gif
Go to the top of the page
 
+Quote Post
mathemajikian
post Aug 2 2006, 09:59 AM
Post #13





Group: Members
Posts: 304
Joined: 8-July 06
From: United Kingdom for now....
Member No.: 10,349



Term 2 is also affected. Login as root under Term 1 then as normal user under Term 2. Start X from Term 2 then exit X. Term 2 will then be jacked up. Now go back to Term 1 and just have root build some arbituary port. While this port is building switch back over to Term 2. Term 2 is now functioning correctly but stops functioning correctly once port has stopped building.





QUOTE(coreilly @ Aug 2 2006, 04:25 PM)
I have absolutely no idea what that means but thanks again for all your work Andy! smile.gif
*
Go to the top of the page
 
+Quote Post
iamasmith
post Aug 2 2006, 10:34 AM
Post #14





Group: Members
Posts: 1,248
Joined: 6-July 04
Member No.: 3,928



QUOTE(mathemajikian @ Aug 2 2006, 05:59 PM)
Term 2 is also affected. Login as root under Term 1 then as normal user under Term 2. Start X from Term 2 then exit X. Term 2 will then be jacked up. Now go back to Term 1 and just have root build some arbituary port. While this port is building switch back over to Term 2. Term 2 is now functioning correctly but stops functioning correctly once port has stopped building.

QUOTE(coreilly @ Aug 2 2006, 04:25 PM)
I have absolutely no idea what that means but thanks again for all your work Andy! smile.gif
*

*



Correct, you can make it barf term 2 easily by starting something graphical with term 2 active, this seems to be related to some of the LCD code which returns an mmap for the currently active screen instead of the screen associated with the process. This stuff has been 'inherited' from NetBSD and is probably due an overhaul.

The reason why your build seems to 'fix' the problem is probably because you are constantly filling the dma controller cache so it is forced to write the updates to the screen.

-Andy
Go to the top of the page
 
+Quote Post
Sequethin
post Aug 2 2006, 11:05 AM
Post #15





Group: Members
Posts: 72
Joined: 12-December 04
Member No.: 5,903



QUOTE(coreilly @ Aug 2 2006, 12:25 PM)
I have absolutely no idea what that means but thanks again for all your work Andy! smile.gif
*



I second that! smile.gif
Go to the top of the page
 
+Quote Post

2 Pages V   1 2 >
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 21st September 2014 - 08:10 AM