Re: Debian rescue CD oddities
On 21/11/15 08:18, Ross Boylan wrote: After booting the Debian 8.2 netinst iso I noticed a couple of oddities. First, I selected advanced and rescue, but this seemed to end up walking me through the installer. I was expecting to be dropped into a shell. At the screen that asked for system name I switched virtual terminals. In my experience, "rescue" is a bit of a misnomer, as the toolset is just too rudimentary. For practical rescue activities, I've found the "live" image is far more heroic. It has more utilities out of the box, and can install packages into the live environment for any extras you might need. I often use it for resizing Windows partitions I want to keep when installing Debian (you can install from within the live environment too). Hope this helps, -- Chris
Re: An UML editor for Linux
On 09/11/15 09:23, Piyavkin wrote: — could you please recommend me some decent UML editor for Linux? I have a colleague who swears by PlantUML, which uses textual markup and GraphViz for generating diagrams. http://www.plantuml.com/ -- Chris
[Partially SOLVED] Re: Slow Xorg performance on dual Opteron + Radeon, Jessie 64-bit
Long story short: Disable ColorTiling in xorg.conf when using bitmap fonts on a Radeon. While searching for clues on this problem, I found this: http://unix.stackexchange.com/questions/111454/what-are-the-purposes-of-the-different-types-of-xwindows-fonts in which Gilles explains a bit of the history of font rendering in X11, notably the move to client-side font rendering that accompanied outline/antialiased fonts (and presumably Xft). This in turn led me to these: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648222 https://bugs.freedesktop.org/show_bug.cgi?id=34486 I can report that disabling the Radeon driver's ColorTiling option in xorg.conf seems to have solved the problem on my system, at least with X clients that use bitmap fonts. This is consistent with my observation that older X clients such as xosview and Notion seemed particularly badly affected. The Radeon driver turns ColorTiling on by default for most of the newer chipsets, according to the man page. However, GIMP (version 2.8.14) is still very slow, both in navigating the menus and when using drawing tools, and causes large amounts of CPU time to be spent in the Xorg process in the __memcpy_sse2_unaligned function. But perhaps the ColorTiling solution might suggest possible causes. I'm also interested in any comments on the slow memcpy performance on this system (which I might take up with the GNU libc team after doing some more testing). Cheers all, Chris -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55c5c8cb.6050...@cedwards.geek.nz
Re: [Partially SOLVED] Re: Slow Xorg performance on dual Opteron + Radeon, Jessie 64-bit
On 08/08/15 22:53, Jörg-Volker Peetz wrote: Maybe you could also play with Option AccelMethod in /etc/X11/xorg.conf, with can either be EXA or glamor (default for R300, see man radeon(4)). Compare these benchmarks: http://www.phoronix.com/vr.php?view=MTYzMDM Interesting - and very appealing benchmark results! I'd noticed a mention of glamor in the Radeon driver man page, but assumed that, since it was the default only on Tahiti and later, it probably didn't offer advantages for older chipsets (or might be unstable). I've tried it and, unfortunately, with 'Option AccelMethod glamor', Xorg won't start. It reports (EE) GLSL link failure and Failed to link: error: shader uses too many input components (44 40). It looks like this might have been patched already in upstream: https://bugs.freedesktop.org/show_bug.cgi?id=75709 Thanks for the suggestion - perhaps in future I can use it too. :) Chris -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55c6cd0a.5060...@cedwards.geek.nz
Re: Slow Xorg performance on dual Opteron + Radeon, Jessie 64-bit
Thanks for the ongoing suggestions. Some more testing and results:
`grep render /var/log/Xorg.0.log`:
[ 8898.907] (II) RADEON(0): Direct rendering enabled
`glxinfo | grep render` gives:
direct rendering: Yes
OpenGL renderer string: Gallium 0.4 on ATI R420
I've tested with an xorg.conf and without. Without, it comes up in
1024x768 resolution and the problem seems less severe, but it's still
noticeable, and Xorg still spends an awful lot of time in
__memcpy_sse2_unaligned.
While doing some further reading and searching, I discovered that Debian
only recently switched back to using glibc, after using eglibc since
about 2009. Since my first suspicions were around libc and possible
performance regressions there, I thought I'd take a closer look, using
the following test program:
#include string.h
#include stdlib.h
const int SIZE=1048576 * 1024;
const int REPS=20;
int i;
void main() {
void *chunk_a = malloc(SIZE);
void *chunk_b = malloc(SIZE);
for (i = 0; i REPS; i++)
memcpy(chunk_b, chunk_a, SIZE);
free(chunk_a);
free(chunk_b);
}
I found a .deb of glibc-2.17 for comparison (__memcpy_sse2_unaligned was
added between glibc-2.17 and glibc-2.18) and used LD_PRELOAD to load
that version instead of Jessie's native glibc-2.19.
time LD_PRELOAD=/tmp/lib/x86_64-linux-gnu/ld-2.17.so
/tmp/lib/x86_64-linux-gnu/libc-2.17.so ./memcpy-benchmark
real0m12.303s
user0m11.456s
sys 0m0.844s
And using the system libc:
time ./memcpy-benchmark
real0m22.509s
user0m21.504s
sys 0m0.992s
So Jessie's standard libc-2.19 is about half as fast as 2.17 on the same
hardware and otherwise same OS. I don't know if this accounts entirely
for the poor performance I'm seeing, but it probably doesn't help.
Might this be worth taking up with the GNU libc people? My guess is it
might be due to slow SSE2 execution on this old AMD64 CPU, whereas the
glibc code is probably optimised for much newer hardware.
Thanks again,
Chris
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55c20de2.4030...@cedwards.geek.nz
Re: Slow Xorg performance on dual Opteron + Radeon, Jessie 64-bit
On 06/08/15 01:21, Chris Edwards wrote: So Jessie's standard libc-2.19 is about half as fast as 2.17 on the same hardware and otherwise same OS. I don't know if this accounts entirely for the poor performance I'm seeing, but it probably doesn't help. Might this be worth taking up with the GNU libc people? My guess is it might be due to slow SSE2 execution on this old AMD64 CPU, whereas the glibc code is probably optimised for much newer hardware. Just to clarify further, the libc-2.17 library is specifically GNU C Library (Ubuntu EGLIBC 2.17-93ubuntu4) stable release version 2.17, and Jessie's native libc-2.19 is GNU C Library (Debian GLIBC 2.19-18) stable release version 2.19. I hadn't realised you could invoke a .so as an executable to find out such info! And, of course, I don't mean that the entire libc is slower, just the memcpy it chooses on my particular hardware. I'm not sure what memcpy implementation was actually being used internally for the libc-2.17 test, as it lacked the debugging symbols. Chris -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55c2174a.3060...@cedwards.geek.nz
Re: Slow Xorg performance on dual Opteron + Radeon, Jessie 64-bit
Thanks all for your help and suggestions. I'll summarise what further testing I've done: I believe 3D acceleration is working. `glxgears` runs and seems to achieve a smooth 60 Hz. The __memcpy_sse2_unaligned load doesn't seem to increase due to running glxgears. glxgears -info reports: GL_RENDERER = Gallium 0.4 on ATI R420 GL_VERSION= 2.1 Mesa 10.3.2 GL_VENDOR = X.Org R300 Project Perhaps interestingly, `glxinfo -i` reports: name of display: :0.0 X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 155 (GLX) Minor opcode of failed request: 24 (X_GLXCreateNewContext) Value in failed request: 0x0 Serial number of failed request: 56 Current serial number in output stream: 59 I'm not using anything fancy in terms of desktop environment: just the Notion (formerly Ion3) window manager plus a few accessories. Running `dpkg -S /lib/firmware/radeon/R420_cp.bin` returns: dpkg-query: no path found matching pattern /lib/firmware/radeon/R420_cp.bin Not sure where that firmware file would have originated from...it's possible I copied it from elsewhere when I first installed Jessie and forgot that I'd done it! `lspci | grep -i vga`: 02:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] R420 [Radeon X800 XT Platinum Edition AGP] `lsmod | grep video` returns nothing, but I do have the following: radeon 1345162 2 ttm77862 1 radeon drm_kms_helper 49210 1 radeon drm 249955 5 ttm,drm_kms_helper,radeon Out of curiosity, I did try installing firmware-linux-nonfree, and `dpkg -S /lib/firmware/radeon/R420_cp.bin` now reports: firmware-linux-nonfree: /lib/firmware/radeon/R420_cp.bin After rebooting, the sluggish redrawing and excessive time spent in Xorg/__memcpy_sse2_unaligned is still there. :( Thanks again! Chris -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55c0b14e.1050...@ripples.dyndns.org
Re: Slow Xorg performance on dual Opteron + Radeon, Jessie 64-bit
Thanks all for your help and suggestions. I'll summarise what further testing I've done: I believe 3D acceleration is working. `glxgears` runs and seems to achieve a smooth 60 Hz. The __memcpy_sse2_unaligned load doesn't seem to increase due to running glxgears. glxgears -info reports: GL_RENDERER = Gallium 0.4 on ATI R420 GL_VERSION= 2.1 Mesa 10.3.2 GL_VENDOR = X.Org R300 Project Perhaps interestingly, `glxinfo -i` reports: name of display: :0.0 X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 155 (GLX) Minor opcode of failed request: 24 (X_GLXCreateNewContext) Value in failed request: 0x0 Serial number of failed request: 56 Current serial number in output stream: 59 I'm not using anything fancy in terms of desktop environment: just the Notion (formerly Ion3) window manager plus a few accessories. Running `dpkg -S /lib/firmware/radeon/R420_cp.bin` returns: dpkg-query: no path found matching pattern /lib/firmware/radeon/R420_cp.bin Not sure where that firmware file would have originated from...it's possible I copied it from elsewhere when I first installed Jessie and forgot that I'd done it! `lspci | grep -i vga`: 02:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] R420 [Radeon X800 XT Platinum Edition AGP] `lsmod | grep video` returns nothing, but I do have the following: radeon 1345162 2 ttm77862 1 radeon drm_kms_helper 49210 1 radeon drm 249955 5 ttm,drm_kms_helper,radeon Out of curiosity, I did try installing firmware-linux-nonfree, and `dpkg -S /lib/firmware/radeon/R420_cp.bin` now reports: firmware-linux-nonfree: /lib/firmware/radeon/R420_cp.bin After rebooting, the sluggish redrawing and excessive time spent in Xorg/__memcpy_sse2_unaligned is still there. Thanks again! Chris -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55c0b423.7060...@cedwards.geek.nz
Slow Xorg performance on dual Opteron + Radeon, Jessie 64-bit
Hi all, I've recently installed Debian Jessie 64-bit on my (admittedly rather old) dual Opteron workstation, and I'm experiencing pretty bad performance in X11. Certain redrawing operations are extremely slow, with delays of half a second or more, and Xorg consumes a lot of CPU time. I've wondered if it's particularly a problem for older X clients using bitmapped fonts, as it's very noticeable when running xosview and when dragging tabs and invoking menus in Notion (window manager), but menu drawing in GIMP is also very slow. The machine has 8 GiB of RAM and only a couple are being used. It was formerly running Ubuntu 12 LTS and didn't have this problem. `Xorg -version` reports the following: X.Org X Server 1.16.4 Release Date: 2014-12-20 X Protocol Version 11, Revision 0 Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian Current Operating System: Linux zaphod 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 root=UUID=2cd952af-5971-442e-9254-bb15730dec1a ro quiet Build Date: 11 February 2015 12:32:02AM xorg-server 2:1.16.4-1 (http://www.debian.org/support) Current version of pixman: 0.32.6 My video card is a Radeon X800 XT Platinum Edition AGP, and Xorg is using the RADEON driver. It's running in dual-head mode. `perf top` seems to indicate that the C library's memcpy implementation is the main culprit: 44.29% libc-2.19.so [.] __memcpy_sse2_unaligned Here's the disassembly of the same, also courtesy of `perf`: __memcpy_sse2_unaligned /lib/x86_64-linux-gnu/libc-2.19.so ... │ lea0x30(%r10),%rax ▒ │ movdqu (%rcx,%r10,1),%xmm8 ▒ 10.42 │ movdqa %xmm8,(%rcx) ▒ 5.03 │ movdqu (%rcx,%r9,1),%xmm8 ▒ 10.35 │ movdqa %xmm8,0x10(%rcx) ▒ 10.60 │ movdqu (%rcx,%r8,1),%xmm8 ▒ 14.00 │ movdqa %xmm8,0x20(%rcx) ▒ 7.87 │ movdqu (%rcx,%rax,1),%xmm8 ▒ 12.53 │ movdqa %xmm8,0x30(%rcx) ▒ 7.57 │ add$0x40,%rcx ▒ │ cmp%rcx,%rdx ▒ 10.08 │ ↓ jne780 ▒ │ ↓ jmpq 6de ▒ │ cmp%rsi,%rdi Could it be a performance regression due to recent enhancements to GLIBC for newer CPUs? Any thoughts on how I can test this further? Thanks, Chris -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55bdb0bf.8020...@cedwards.geek.nz
Re: Slow Xorg performance on dual Opteron + Radeon, Jessie 64-bit
Hi Chris (ha, maybe I should have posted directly to the DunLUG list!)... On 02/08/15 18:39, Chris Bannister wrote: On Sun, Aug 02, 2015 at 05:55:11PM +1200, Chris Edwards wrote: I've recently installed Debian Jessie 64-bit on my (admittedly rather old) dual Opteron workstation, and I'm experiencing pretty bad performance in X11. [snip] I'm guessing it's a driver issue. What is the output of: apt-cache policy firmware-linux-nonfree firmware-linux-nonfree: Installed: (none) Candidate: 0.43 Version table: 0.43 0 500 http://ftp.nz.debian.org/debian/ jessie/non-free amd64 Packages Should I set things up for installing the firmware-linux-nonfree package? I do already see this in the kernel messages: [ 14.145030] radeon :02:00.0: firmware: direct-loading firmware radeon/R420_cp.bin and /lib/firmware/radeon/R420_cp.bin exists. You can 'browse' through /var/log/Xorg.0.log or similar, for the Xorg log. This shows some errors relating to the Wacom tablet I have configured in my Xorg.conf but not currently connected. It's using the RADEON driver. If I move my xorg.conf out of the way and run it with the default settings, the slowness is much less apparent, although __memcpy_see2_unaligned still dominates the CPU time according to `perf top` - the following output was generated while dragging a Notion window tab over an xosview window, which seems to be about the worst case scenario, with no xorg.conf: 63.21% libc-2.19.so [.] __memcpy_sse2_unaligned 4.45% [kernel] [k] acpi_pm_read 1.74% [kernel] [k] clear_page_c 1.33% libfb.so [.] fbBltOne 0.73% [kernel] [k] amd64_insert_memory 0.59% radeon_drv.so[.] memcpy@plt 0.30% [kernel] [k] kfree 0.30% libc-2.19.so [.] _int_free 0.28% libc-2.19.so [.] _int_malloc I did also notice this in the kernel messages: [ 15.616348] powernow_k8: [Firmware Bug]: No compatible ACPI _PSS objects found. [Firmware Bug]: First, make sure Cool'N'Quiet is enabled in the BIOS. [Firmware Bug]: If that doesn't help, try upgrading your BIOS. Could this be related? I think my BIOS and CPUs predate Cool'N'Quiet, and there are no BIOS updates available from the now-nonexistent vendor. :) Thanks, Chris -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55bde871.7000...@cedwards.geek.nz
how to fix this broken system?
Greetings, I can't remember the exact error, but something involving gmc caused my system to become unusable. When i boot linux up now, i get this error message: init: unable to load shared library: /usr/lib/libc6.so:, undefined symbol GLIBC_2.0 i've tried using the debian rescue but that hasn't worked. is there any way i can save my system (or at least get my data and do a sigh reinstall)? cheers, chris / [EMAIL PROTECTED]
