OESF Portables Forum
Everything Else => Zaurus Distro Support and Discussion => Distros, Development, and Model Specific Forums => Archived Forums => OpenBSD => Topic started by: wilkes on June 13, 2006, 10:11:57 am
-
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-
-
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
-Andy
-
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.
-
zkbd(4) man page is well worth a read if you haven't already
-Andy
-
This is still an issue. What could be the cause of this? Is X not flushing the framebuffer correctly when exiting?
-
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.
-Andy
-
I have noticed that if I just let the Z sit for about 5 minutes the console response returns to normal.
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.
-Andy
[div align=\"right\"][a href=\"index.php?act=findpost&pid=137067\"][{POST_SNAPBACK}][/a][/div]
-
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.
-
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.
-
ah maybe that isn't the problem... digging a little deeper now.
-
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.
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#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
-
I have absolutely no idea what that means but thanks again for all your work Andy!
-
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.
I have absolutely no idea what that means but thanks again for all your work Andy!
[div align=\"right\"][a href=\"index.php?act=findpost&pid=137258\"][{POST_SNAPBACK}][/a][/div]
-
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.
I have absolutely no idea what that means but thanks again for all your work Andy!
[div align=\"right\"][a href=\"index.php?act=findpost&pid=137258\"][{POST_SNAPBACK}][/a][/div]
[div align=\"right\"][a href=\"index.php?act=findpost&pid=137268\"][{POST_SNAPBACK}][/a][/div]
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
-
I have absolutely no idea what that means but thanks again for all your work Andy!
[div align=\"right\"][a href=\"index.php?act=findpost&pid=137258\"][{POST_SNAPBACK}][/a][/div]
I second that!
-
OK, for now I have put out the word on arm@openbsd.org whilst I rebuild my environment using OpenBSD 4.0. Started from scratch since it has been upgraded quite a lot and was long overdue.
Will take a look at it again as soon as X has finished building.
-Andy
-
I think I have a reasonable handle on what is causing this to happen now, although there are some areas of complexity that I need to understand and the PXA270 programmers guide is tough reading.
Basically the console is handled as follows..
wsdisplay interfaces with pxa2x0_lcd.c and the function pxa_lcd_new_screen is used to create the memory map for the display (using bus_dmamem_alloc) and then map that into a kernel virtual address using bus_dmamem_map. This address becomes the internal frame buffer address that is used to render the text consoles which are actually implemented through the rasops library since the display is bitmap only.
When the dma map is created to give the kernel the address of the buffer a particular flag is used, BUS_DMA_COHERENT, which should ensure that writes to this region are immediately sent to the device on the other end of the DMA channel (the display).
As long as you are working in text mode and don't change anything then the frame buffer DMA doesn't get upset.
To access the bitmap display from userland such that graphical applications function it is necessary to perform two steps, step one is to send an IOCTL to the frame buffer to say that it should go into dumb mode (theoretically this should perform extra initialisations and store some flag information for the system to say that the normal text display isn't available any more) and then a call to the system call mmap is used to obtain a memory mapped region with which to communicate with the display.
The mmap call is implemented again in pxa2x0_lcd.c and what it actually does is very simply to use bus_dmamem_mmap to obtain another virtual address region corresponding to the previously allocated buffer created in pxa_lcd_new_screen. This is necessary since a process virtual address space will be different to the kernel virtual address space. This call is made, again, using the BUS_DMA_COHERENT flag to ensure that anything written to this region is immediately written to the device on the other end of the DMA channel.
bus_dmamem_mmap/map deals with virtual addresses but I suspect that, since the DMA controller of the PXA is an integrated device, it also deals with descriptors that map virtual addresses to physical addresses. This being the case what happens when a second descriptor is created to a region for transfer when a descriptor already exists? (as in the case of bus_dmamem_mmap during mmap call following bus_dmamem_map during text frame buffer creation) - my suspicion at this stage is that the controller will handle only the last initialised DMA transfer in a coherent state. This would explain why a return to the text buffer starts to experience transfer slowness in the rasops library that is used to render the text display. (upon return the kernel bitmap used for this display is no longer flagged coherent and is subject to writeback cache built into the DMA controller).
I hope to fix this by implementing an IOCTL handler within the pxa2x0_lcd.c for the WSDISPLAY_SMODE message that restores the coherency to the original (kernel) bitmapped region used by the rasops functions so that this region returns to its original snappy state. This is the area that I am tinkering with at the moment.
-Andy
-
Have you had any luck sorting this out?
controller).
I hope to fix this by implementing an IOCTL handler within the pxa2x0_lcd.c for the WSDISPLAY_SMODE message that restores the coherency to the original (kernel) bitmapped region used by the rasops functions so that this region returns to its original snappy state. This is the area that I am tinkering with at the moment.
-Andy
[div align=\"right\"][a href=\"index.php?act=findpost&pid=137519\"][{POST_SNAPBACK}][/a][/div]
-
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-
This has been fixed in 4.1-current .
-
hmmm.. what ever happened to Iamasmith...
-
hmmm.. what ever happened to Iamasmith...
He still posts every once and awhile.
-
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-
This has been fixed in 4.1-current .
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160589\"][{POST_SNAPBACK}][/a][/div]
It seems the issue is still there. Now I am using 4.1 kernel GENERIC#55 (= the 4.1 official release).
Still experiencing lag in console after exiting X.
But this is not as a big problem as the suspend issue (in the 4.1 snapshots).
-
It seems the issue is still there. Now I am using 4.1 kernel GENERIC#55 (= the 4.1 official release).
Still experiencing lag in console after exiting X.
But this is not as a big problem as the suspend issue (in the 4.1 snapshots).
Wow! I must have the golden Zaurus. Did you remember if you had the lag issue in --current? Try and use this ttys file and see if it persists:
[ You are not allowed to view attachments ] [span style=\'font-size:8pt;line-height:100%\'] rename the file to ttys and put it in /etc/ then reboot. Does the lag problem still exist?[/span]
Can anyone else verify that this problem is no longer present in 4.1 --current?
-
It seems the issue is still there. Now I am using 4.1 kernel GENERIC#55 (= the 4.1 official release).
Still experiencing lag in console after exiting X.
But this is not as a big problem as the suspend issue (in the 4.1 snapshots).
Wow! I must have the golden Zaurus. Did you remember if you had the lag issue in --current? Try and use this ttys file and see if it persists:
[ You are not allowed to view attachments ] [span style=\'font-size:8pt;line-height:100%\'] rename the file to ttys and put it in /etc/ then reboot. Does the lag problem still exist?[/span]
Can anyone else verify that this problem is no longer present in 4.1 --current?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=161173\"][{POST_SNAPBACK}][/a][/div]
i'm using 4.1 GENERIC#89 and i haven't seen it although i'm used to go forth and back from X to console
-
hmmm.. what ever happened to Iamasmith...
He still posts every once and awhile.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160592\"][{POST_SNAPBACK}][/a][/div]
Heh, I'm still here and listening in from time to time. However, I have been contracting for about 9 months now and am pretty focussed upon that so I don't have as much time to tinker.
I'm working in a more strategic field right now and technology is only a small part of the problems that I face.
I will post when I can and hope to start contributing to OpenBSD again at some point... incidently - I believe that the console problems aren't fixed. What they have done is made X run on Console #2 and switch to screen 2 whilst running X.
The X server still seems to screw up the frame buffer. I believe there is still an outstanding problem with the DMA cache coherency.
BTW: I'm really sorry that I didn't follow up on Theo's request to nag the committers to include a variant of my Caps lock fixes for Kernel and X on 4.1. I have just been soooo busy. The good news is that they still seem to apply without any problems
-Andy