<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED FIXED - K8M800/K8N800 (unsure which): 0.5.0-rc2 gets stuck saturating cpu during basic use" href="https://bugs.freedesktop.org/show_bug.cgi?id=96711#c12">Comment # 12</a> on <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED FIXED - K8M800/K8N800 (unsure which): 0.5.0-rc2 gets stuck saturating cpu during basic use" href="https://bugs.freedesktop.org/show_bug.cgi?id=96711">bug 96711</a> from <a class="email" href="mailto:kevinbrace@gmx.com" title="Kevin Brace <kevinbrace@gmx.com>"> Kevin Brace</a> <pre> (In reply to Roc Vallès Domènech from <a href="show_bug.cgi?id=96711#c6">comment #6</a>) Hi Roc, > Found this config file, which I apparently wrote in 24122014 and forgot > about: > > Section "Device" > Identifier "openchrome" > Driver "openchrome" > Option "SWCursor" "true" > Option "AccelMethod" "XAA" > Option "NoXVDMA" "true" > #Option "VBEModes" "true" > EndSection > > So, I'm leaving the file as it might be helpful in the future, but commented > all option lines and restarted X. > You can safely take out the following lines. Option "AccelMethod" "XAA" #Option "VBEModes" "true" XAA has been gone since Version 0.3.3. VBE was removed by me when Version 0.4.0 was released. VBE is gone forever. As for NoXVDMA, OpenChrome might be disabling it internally regardless of the option since they has been some talk about K8M800 having a hardware bug with their interrupt handling. I think this will be the minimalist xorg.conf. ______________________________________________________________________ Section "Device" Option "SWCursor" "true" Option "NoXVDMA" "true" EndSection ______________________________________________________________________ You can probably even take out NoXVDMA option. > X seems to start, but no mouse pointer. Power cycled just in case. Still no > mouse pointer. Xorg of this attached shortly. > Okay, I should have read your comment more carefully before clicking the "Save Changes" button. It appears that K8M800 and CN700 (and P4M800 Pro and VN800) all seem to have a CLE video display engine. In this situation, it is possible that one monitor (i.e., VGA) might see the cursor, but not the other one. I observed this with CN700 chipset recently. When I tested OpenChrome with ABIT KV-80 mainboard (K8M800 chipset) 2 months ago, hardware cursor worked. (i.e., I did not have to use xorg.conf.) > Then I uncommented the SWCursor line, and so far all good, and with EXA now > that the other lines are commented. > You will have to stick to that option for now. Around Version 0.6, I may force turn on software cursor if 2 display controllers are going to be used. HW cursor appears to work for desktop K8M800 (i.e., VGA only). > Tested xterm scrolling, watching a video with mpv; it's as good (or as bad) > as usual. -vo x11, as -vo xv (as always before) doesn't display a thing. Did > some webbrowsing. So far so good. > When I saw the Xorg.0.log, you are getting around 50 MB / sec. frame buffer bandwidth. ______________________________________________________________________ . . . [ 67.817] DRM memory allocation failed -6 [ 67.817] 635904 bytes of Linear memory allocated at 649000, handle 138823280 [ 67.828] (II) CHROME(0): Benchmarking video copy. Less time is better. [ 67.849] (--) CHROME(0): Timed libc YUV420 copy... 17592246. Throughput: 54.0 MiB/s. [ 67.870] (--) CHROME(0): Timed kernel YUV420 copy... 16968511. Throughput: 55.9 MiB/s. [ 67.890] (--) CHROME(0): Timed SSE YUV420 copy... 16869077. Throughput: 56.3 MiB/s. [ 67.911] (--) CHROME(0): Timed MMX YUV420 copy... 16908711. Throughput: 56.1 MiB/s. [ 67.931] (--) CHROME(0): Timed 3DNow! YUV420 copy... 16954890. Throughput: 56.0 MiB/s. [ 67.951] (--) CHROME(0): Timed MMX2 YUV420 copy... 16867230. Throughput: 56.3 MiB/s. [ 67.951] Freed 6590464 (pool 4) . . . ______________________________________________________________________ Due to the way AMD architected HyperTransport bus and K8M800 being the first generation AMD Athlon 64 IGP for VIA Technologies, maybe this is to be expected. K8M800 needs to talk to Athlon 64 first before Athlon 64 accesses its DRAM controller reserved for frame buffer use. This adds tremendous memory access latency. Furthermore, write combining may not be turned on by BenQ (in the firmware), and I will assume that this reduces performance as well. Plus, the Athlon 64 you have is probably a single channel memory model (Socket 754 equivalent). No wonder you end up with direct CPU frame buffer access performance worse than CLE266. > Also tested booting without viafb. Still crashes all the same. I am still working on this, but it will likely take time before it is resolved. Eventually, OpenChrome needs to get the intialization right since I will like to resume the work on the newer DRM module supporting KMS. But before that, I need to stabilize the UMS code.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>