Köşebaşı

Sonunda komut satırından gerekli komutların bir kısmını kullanma fırsatı buldum:

dbstop if error

deyip bir kod çalıştırdığımızda, hata üzerine hata ayıklama kipi açılıyor. Böylece normal yazı düzenleyicdeki gibi hata ayıklamak mümkün oluyor.

Burada önemli bir nokta, yukarıdaki komutu verdikten sonra Matlab komut satırında çalışsa bile grafik editörü açıyor. Bunu engellemek için Matlab'ı şu şekilde başlatmak gerekiyor:

matlab -nodesktop -nosplash -nodisplay

Hata ayıklama kipinden çıkmak için gerekli komut:

dbquit

Diğer hata ayıklama komutları için referans burada.

Uzun süren kerneller için gerekli xorg.conf ayarı:

Section "Device"
    Identifier     "Device1"
    Driver         "nvidia"
    BusID          "PCI:1:0:0"
    Option         "NoLogo" "true"
    Option         "UseEDID" "false"
    Option         "DPI" "96x96"
    # kernel timeout icin
    Option         "Interactive" "0"
EndSection

Sürücü sürümü ile SDK (toolkit) sürümü farklı olursa hiç bir şey ifade etmeyen genel hata gözükebilir:

unspecified launch failure

Kodun zamanlama ölçümü yapılırken cevabın karttan okunduğu satırında hesaba katılması gerekli. Çünkü anladığım kadarıyla kerneller tembel (lazy) çalışıyor. Yani sonucu okumaya çalışmadıkça kernel çalışmıyor!!! En azından zamanlama çalışmalarım bunu gösterdi.

Bu çok güzel bir nokta: hafıza problemlerini tespit etmek için derleme komutuna -G3 parametresi eklendikten sonra kod cuda-memcheck programı üzerinden çalıştırıldığında pek enfes hafıza hatası çıktıları gözükebiliyor. Örnek:

========= Invalid __global__ read of size 4
=========     at 0x00000660 in common/kernels.cu:300:calculate_C_mops
=========     by thread (7,0,0) in block (0,0,0)
=========     Address 0x05c66de0 is out of bounds
=========
========= ERROR SUMMARY: 8 errors

Emacs'te bir kod parçasının başına yorum karakteri koymak için (Ctrl C C kısayolunun çalışmadığı zamanlarda) bir türlü gerekli komutu bulamıyordum. Geçenlerde buldum, unutmadan not edeyim:

Ctrl SPACE
oklar ile bir kısım kod seçilir, yada bütün dökümana aynı işlemi yapmak için bu adım atlanabilir.


M x RET
replace-regexp RET
^ RET
% RET

Böylece satır başını anlatan ^ karakteri sayesinde bütün satırların başına Matlab'ın yorum karakterini koymuş oluyoruz.

Not: bu arada "regular expression" ifadesinin düzgün bir türkçesini bulamadım, rasyonel ifade gibi birşeyler var, ama o da pek güzel değil. Önerisi olan var mı?

#include < iostream >
#include < stdlib.h >
using namespace std;
int main(){
int a[] = {1,2};
int* b = a;
int c[] = { 3 , 4};
int** d = (int**) calloc(3, sizeof(int*));
d[0] = a;
d[1] = b;
d[2] = c;
for (int i=0; i<3; i++)
  for (int j=0; j<2; j++)
    cout << d[i][j] << endl;
}

Bunu sürekli unutuyorum buraya yazayım. Matlab'da MEX dosyaları çalıştırmak isteyince, sanırım Matlab'ın içinde gelen libc çalışmadığı için, şunu yapmak gerekiyor:

cd sys/os/glnxa64
mkdir old
mv mv libgcc* libstdc++* old/

Bunu yapabilmek için sürücü yükleyicisinde ufak bir düzenleme yapmak gerekiyor. Bir arkadaşımız şurada güzelce anlatmış. İbretlik bir paylaşım.

Sanırım bu sefer oldu!!! Buradan ve buradan öğrendiğim üzere hem pil sarfiyatını acayip düşüren, hem de bunu yaparken görüntü bozulmalarına sebep olmayan rc6 sürümü linux-next'e gelmiş gibi görünüyor. Denedim oldu!!! Ve bu gerçekten inanılmaz bir durum, kafayı yemek üzereydim!

Bu linux kernel sürümüne ulaşmak için iki yol var. Birincisi bir kaç gün bekleyip, 3.3-rc6 yı indirip, derleyip, kurmak. Diğeri ise linux-git deposundan indirip kurmak. Bunu yapmak için kodu şu şekilde indirmek gerekiyor:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux-git

Bu şekilde indirirseniz bütün geçmişi indiriyorsunuz toplam 2.3 GB. Mantıklı olarak sadece son halini isterseniz:

git clone --depth 1 git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux-git

O zaman sadece 400 MB boyutunda bir indirme yapmak gerekiyor. İndirme bittikten sonra yine derleme ve kurma işlemleri gerekiyor tabi. Yükleme için aşağıya bakabilirsiniz.

Bir diğer önemli nokta rc6 çalıştırmak için açılışta kernele parametreler vermek gerekiyor. Bunun için Debian tarzı sistemlerde /etc/grup/default dosyasında şöyle bir değişiklik yapmak gerekiyor:

GRUB_CMDLINE_LINUX_DEFAULT="quiet pcie_aspm=force i915.i915_enable_fbc=1 i915.lvds_downclock=1 i915.i915_enable_rc6=1"

Bunu yaptıktan sonra root kullanıcısı ile update-grub komutunu vermek gerekiyor. Bu yeni kernel ile bilgisayarı yeniden başlattıktan sonra Sandy Bridge işlemcinizin sağlayacağı uzun pil ömrünü doğru düzgün çalışan görüntü ile seyreylemenin mümkün olacağını düşünüyorum.

Genelde kalite bağımsız çalışan DNS sunucularımız için fena olmayan bir çözüm: pdnsd.

aptitude install pdnsd

komutu ile yüklenebilen paket DNS sorgularını yerel önbelleğinde tutarak, sonraki sorguları hızla cevaplayabiliyor. DNS problemi olanlara duyrulur.

Bir zamandır deniyorum, bağlantıda patlamalar olmadı, hafif bir DNS hızlanması da oldu gibi.Detaylı bilgi.

Bir kod parçası düşünün:

for i = 1..102660
  for j = 1..102660
    for k = 1..69679430
      ... birşeyler ...

Bunu derleyip g++ file.cc çalıştırdığımda j döngüsünün her bir elemanı 1 saniye civarında sürüyordu. Yani işin tamamı 28 * 102660 saat sürecek gibi gözüküyordu.

Sonra bunu şöyle derledim g++ -O3 file.cc. Birkaç kere denememe rağmen hala inanamıyorum ama kod dosyasına hiç dokunmadan bütün döngü bir saniyeden az bir sürede bitiyor!

Peki soruyorum sana -O3 eniyileme (optimizasyon) parametresini bilmeyenler ne yapacak g++!

Düzenleme: tabiki benim algım yanlışmış! Sanırım olan durum derleyicinin döngünün dışına bir sonuç çıkmadığını farkedip, döngünün içindeki kodu hiç çalıştırmaması idi!!! Döngünün içerisinde bir sayaç tutup yazdırmaya kalkınca aynı senaryoya göndük! Vay vay vay... C++'ın puslu yolları breh breh breh...

Unutmayalım. Diyelim ki bir satırımız var:

...
LAYER
...

Bunu şu şekilde değiştirmek istiyor olalım:

...
   
LAYER
...

Bunun için gerekli Emacs hareketi:

M-x replace-string RET
LAYER RET
C-q C-j LAYER RET

Projeden alınan, yani baldan da tatlı olsa da, üzerinize afiyet klavyesi son derece dandik olan Asus N53SN-SZ129V için sonunda düzgün bir klavye buldum. Düzgün ve hızlı yazılabilir bir çalışma ortamı edinme çalışmam sonlanmış oldu böylece. Anlatayım:

Önceliklen bütün gün başında durduğum bilgisayarın masa üzerinde bulunması, gıdı çıkaran bir pozisyonda bulunmayı gerektiriyor. Bütün gün bu şekilde durunca sanırım geceleri de bu şekilde duruyorum ve horlamama katkıda bulunuyor diye düşünüyorum. (İşte buna RSI derler! : ) )

Bu sebeple sevgili eşimin işe başlama hediyesi olarak bana aldığı, ederinden pahalı olan, Cooler Master NotePal ErgoStand dizüstü standını, yine neredeyse ederinden pahalı olan Case Logic sırt çantamda taşımaya başladım.

Tabi bu durumda klavye sıkıntısı doğdu. İşte bugün bu sıkıntıyı bir avantaja çeviren hamleyi yaptım ve bir adet Genius Luxemate I200 aldım. Ve huzura erdim.

Artık başım hizzasında düzgün bir monitör ve düzgün bir klavyeye sahibim. Bu yazının sebebi de klavyenin akıl almaz dügünlüğü aslında. Tuşların ayrık olması tuşların yerinin anlaşılmasını kolaylaştırıyor. Ayrıca tuşların geri bildirimi de tam tadında. Ne az ne fazla. Kritik olarak düzgün bir sağ ctrl tuşu var. Sağlam bir zemini var. Ayrıca rahatça çantaya girebilecek boyutlarda. Bu da yetmezmiş gibi sadece 28 TL!!! Acaba gidip üç-beş tane daha mı alsam. Zira kendisini hayatımın klavyesi olarak ilan ediyorum.

Bir tar dosyasını vim ile açınca içerisindeki dosyaların listesi gözüküyor, ok tuşaları ile bir dosya isminin üstüne gelip enter'a bastığınızda o dosyanın içeriğini gösteriyor.

Tar dosyalarının içeriğini öğrenmek ve içlerindeki yazı dosyalarını okumak için çok faydalı olabilir.

perl cüler bilir, CPAN perl paketlerini sunar. Ön sayfasında yazdığı üzere 103,200 adet perl paketi mevcut imiş. Pek mükemmel yani!

Geçmişten gelen problemlerinden birisi bu depodan yüklemek idi. Sanırım bugün bunu çözdüm. Meğersem birkaç yolu varmış. Benim beğendiğimde CPAN'dan paket indiriliyor, bununla bir deb paketi oluşturuluyor. Sonra bunu dpkg ile yüklüyoruz:

aptitude install dh-make-perl
cpan2deb Paket:İsim
dpkg -i oluşan.deb

ve CPAN'ın dünyası bize açılmış oluyor.

Not: cpan2deb komutunu ilk çalıştırdığınızda CPAN.pm ayarlaması yapılıyor. Burada önceden tanımlı seçenekler iyi çalışıyor gibi gözüküyor. root gereksinimi varmış gibi gözükse de olmadan iş görüyor.

Çok hayret vericiydi, siz de deneyin (root olarak):

sysctl -A

Listede çıkacak değişkenleri değiştirmek için /etc/sysctl.d/birdosya.conf dosyasına yazmak gerekiyor mesela:

echo kernel.shmmax = 268435456 > /etc/sysctl.d/local.conf

Sonra bunların geçerli olması için sadece ve sadece bir komut:

service procps start

Sonra sysctl -A ile bakıldığında görülecektir ki kernel parmetresi değişmiştir. Amaniii...

Bütün günü bilgisayarı yeniden başlatıp ayarlar denemek zorunda kaldıktan sonra bugün şunu öğrendim. Debian unstable dayken testing deposuna geçmek için şu yol kullanılabilir gibi. apt-show-versions paketini yükleyip komutu çalıştırdığınızda hangi paketin hangi depodan geldiğini gösteriyor, oraya bir grep çekip unstable olanları bulup, aptitude purge edip, sources.list'i güncelledikten sonra tekrar yüklenince, testing e dönebiliyor mesela paketler.

Arkadaş RAM'in mi var derdin var... İki gündür bir disk bölümleme (disk partitioning) problemi ile uğraşıyorum ki sormayın gitsin. Problemi anlatayım.

Bilgisayarı açtıktan sonra pm-hibernate ile güzelce hibernate ediyorum. Biraz sonra tekrar deniyorum, yine güzelce çalışıyor. Bir süre sonra çalışmaz oluyor, kernel dump a kadar şeyler oluyor. Ben de dedim ki acaba bu RAM'in takas bölümünden (swap) büyük olmasından mı kaynaklanıyor? Böylece kafadan 2 GB olarak tanımladığım takas alanını büyütmeye koyuldum.

Herşey iyi güzeldi bir Ubuntu 10.04 live cd si içindeki gparted ile işe başladım. Yapacağım şey şu idi.

sda1 -> aynen kalsın
sda2 -> biraz büyüsün
sda3 -> silinsin (eski swap)
sda4 -> 6 GB küçülsün, gerisi aynen kalsın
...  -> açılacak alanda yeni takas alanı oluşturulsun

Bu işlem dün bütün gün boyunca 8+ saat kadar sürdü!!! Bunun sebebi ise gparted gerek yok iken (!!!) sda4 ü bir miktar sola taşıması idi.

İşlem bitince sistem açıldı. Bir problem gözükmüyordu (bütün gün Ubuntu live cd si içerisinde mahkum olmanın dışında!). Taa ki fdisk -l diyene kadar. Çıktıda şu mesajlar geliyordu:

Partition 3 does not start on physical sector boundary.
Partition 4 does not start on physical sector boundary.

Biraz araştırdıktan sonra gördüm ki, gparted'ın lüzumsuz olduğunu düşündüğüm taşıma hareketi bütün gün sürmenin yanı sıra başlangıç noktasının sektör sınırına denk gelmemesini de sağlamış!!! Bir süre bakındıktan sonra, şu makalede gördüm ki bunun sebebi gparted'ın arayüzündeki "round to cylinders" seçeneğinin seçili olmasıymış, ki kendisi önceden tanımlı olarak seçili geliyor!!!

Bir süre sakinleşme gayreti gösterdikten sonra, Ubuntu'nun yeni sürümünü (11.10) indirdim. Yine gparted'ı açtım, bu sefer "align to" seçeneğinde bir de "MiB" çıkmış. Bir de bunu deneyelim diyerekten dün gece saat 1.00 de işlemi başlattım.

Sabah kalktığımda saat 7.00 civarında Ubuntu'nun ekranı çalışmaz hale gelmişti. Grafik ekran yerine siyah bir ekran gözüküyordu. Bir yandan CD durmadan çalışıyordu, sabit disk de durmadan çalışıyordu. İyi bari deyip, bir süre takılıp geri geldim. Bir de ne göreyim ekran kendine gelmiş birşeyler gösteriyor. Diyor ki bir buçuk saat daha işim var!!!! Bu sefer de tekrar bir taşıma işlemi olduğu için yine uzun sürmekte.

Yalnız bu sefer ki doğru bir taşıma işlemi. Bunun doğruluğunu kontrol etmenin yolu şu idi, sonuçta varılacak konfigürasyonda yeni disk bölümlerinin başlangıç noktaları 306491392 ve 1237057536, ikisi de 512'nin katları... Şükür... Bunu işlem başlamadan kontrol etmek de mümkündü.

Sonuçta şimdilik sonuç iyi oldu. Ama pek çok kıssadan hisse oluştu, dikatinize sunarım:

• Gerekmedikçe asla disk bölümü taşımayın. İnanılmaz uzun sürüyor.
• gparted'ın en son sürümünü kullanın.
• Bölümlerinizi oluşturmaya başlamadan önce BAŞLANGIÇ noktalarının 512'nin katı olduğundan emin olun.

Bu işlemin sonucunda oluşan gparted_details.htm dosyası, belki biraz daha fikir verebilir.

Farkettim ki sadece kerneli yenilemek suspend in çalışması için yeterli değil. Aynı zamanda aşağıdaki dosyları da belirtilen yerlere konulması gerekiyor:

/etc/pm/config.d/usb3-suspend-workaround


SUSPEND_MODULES="xhci ehci"

Aşağıdaki dosyanın çalıştırılabilir yapılması gerekiyor:

chmod a+x /etc/pm/sleep.d/20_custom-ehci_hcd

/etc/pm/sleep.d/20_custom-ehci_hcd


#!/bin/sh
#inspired by http://art.ubuntuforums.org/showpost.php?p=9744970&postcount=19
#...and http://thecodecentral.com/2011/01/18/fix-ubuntu-10-10-suspendhibernate-not-working-bug    
# tidied by tqzzaa :)


VERSION=1.1
DEV_LIST=/tmp/usb-dev-list
DRIVERS_DIR=/sys/bus/pci/drivers
DRIVERS="ehci xhci" # ehci_hcd, xhci_hcd
HEX="[[:xdigit:]]"
MAX_BIND_ATTEMPTS=2
BIND_WAIT=0.1


unbindDev() {
  echo -n > $DEV_LIST 2>/dev/null
  for driver in $DRIVERS; do
    DDIR=$DRIVERS_DIR/${driver}_hcd
    for dev in `ls $DDIR 2>/dev/null | egrep "^$HEX+:$HEX+:$HEX"`; do
      echo -n "$dev" > $DDIR/unbind
      echo "$driver $dev" >> $DEV_LIST
    done
  done
}


bindDev() {
  if [ -s $DEV_LIST ]; then
    while read driver dev; do
      DDIR=$DRIVERS_DIR/${driver}_hcd
      while [ $((MAX_BIND_ATTEMPTS)) -gt 0 ]; do
          echo -n "$dev" > $DDIR/bind
          if [ ! -L "$DDIR/$dev" ]; then
            sleep $BIND_WAIT
          else
            break
          fi
          MAX_BIND_ATTEMPTS=$((MAX_BIND_ATTEMPTS-1))
      done  
    done < $DEV_LIST
  fi
  rm $DEV_LIST 2>/dev/null
}


case "$1" in
  hibernate|suspend) unbindDev;;
  resume|thaw)       bindDev;;
esac

Malumunuzdur pek çok kişiler dosyayı başka kodlamada (encoding), içindeki yazıyı başka türlü kodlamada ustadır. Bazen de ne kadar gereksiz de olsa doğru bir şekilde hem dosyanın diske yazılmasında kullanılan kodlama hem de içindeki yazının kodlaması ISO-8859-9 şeklinde yapılır. Bu dosyaları ve içindeki yazıları da UTF-8 alemine geçirmek gereklidir. Senelerden beri süre gelen bu çile, bu can sıkıcı çözümsüzlük benim için dün son buldu. Sizin içinde son bulsun istedim.

Diyelim ki elimizde ISO-8859-9 ile kodlanmış bir dosya var, bunu vim ile UTF-8 kodlamasına çevirmek mümkünmüş:

:write ++enc=utf-8 yenidosya

Daha önceden bahsettiğim Sandy Bridge platformlar üzerinde düzgün olmayan ASPM özelliği 3.2-rc6 ile bugün itibariyle aramızda!!! Bu yazıyı yadığım sırada bilgisayarın fanı durdu, 11W güç harcayarak 4 saate kadar pil ömrü tahmini gördüm. Olley!

Süper bir insansın Matthew Garrett

i3/i5/i7 işlemcili Linux kullanıcılarına duyurulur.

Debian üzerinde kendi Kernelinizi derlemek için şuraya bakabilirsiniz. Oldukça basit bir işlem. Yalnız çok çekirdekli sistemlerde derleme yaparken parallelikten faydalanmak için şunu demeyi unutmayın:

export CONCURRENCY_LEVEL=16

Sayısal değer olarak çekirdek sayınızın iki katını girebilirsiniz. Benim canavar i7 işlemci için 8 çekirdek gözüktüğünden 16 yazdım.

Ve olmuştu, serverfault.com'da tesadüfen bir yazı okurken karşılaştım, ağ trafiğini inceleyip ağ kullanımına göre bağlantıları listeleyen program: iftop imiş! Ne zamandır isteyip ulaşamamıştım.

Tarayıcılar içinden Java desteği genelde dert olmuştur. O paket senin bu paket benim dolaşmak, linkler yapmak bir sürü uğraşmak gerekirdi. Geçen gün bu işler pek bir güzellikle yapan bir paket keşfettim:

aptitude install icedtea6-plugin

ve tarayıcılarda Java vardı... : )

Doğru dürüst çalışmayan Sandy Bridge desteği sebebiyle olduğunu zannettiğim, sabit diskin sürekli kapanıp açılması ve bu esnada hem performans hem de uzun vadede olası arızalara yol açabilecek hatasını düzeltmeye yarayan komut:

hdparm -B 255 /dev/sda

hdparm'ın bir çok daha şeker seçeneği var man sayfasından bakılabilir. -B seçeneğine 255 parametresini verdiğimide ilgili disk için "Advanced Power Management feature" özelliğini kapatmış oluyoruz. Böylece disk sürekli açılıp kapanmaktan vazgeçiyor.

Bu değerin açılışta ayarlanması için /etc/hdparm dosyasındaki yorumlu şekilde bulunan apm satırı kullanılabilir.

Düzgün ASPM desteği için hergün kernel.org'un sayfasına uğramaya devam ediyoruz.

Geçen gün gerçek bir hafıza kaçağını (memory leak) yakaladım! Düşündüm, bundandır dedim, düzelttim ve oldu! Bir ilkti.

Matlab üzerinden çalıştırılan C/C++ kodlarındaki elle ayrılmış (malloc) hafıza parçalarını yine elle boşa çıkarmak (free) gerekiyormuş. Normalde program kapanınca zaten boşa çıkmasını beklerdim. Ama belli ki Matlab programı pek de kapatmıyor... Neyseki çözümünü kolayca bulabildim.

Bildiğiniz gibi bir süredir Asus N53SN-SZ129V ile boğuşuyorum. Bugün suspend'i çalıştırdım ve çook şaşırdım! Garip olan çözümü bulmak değil, çözümün kendisiydi.

Yıllardır severek kullandığımız s2ram komutunu, bu bilgisayarda siyah bir ekran çıkarmaktan ibaret hale geldiğini görmek içimi hüzün kaplamaya yetmişti. Kardeşi s2disk çalışıyordu ama o da bizi geri dönüşü olmayan bir yola çıkarıyordu. Geri döndüğümüzde Optimus destekli ekran kartı çalışmaz oluyordu... Durum o kadar hüzünlüydü ki yıllardan beri öğrenmemeye gayret ettiğim açılıştaki disk kontrolünü düzenleme komutunu bile öğrenmeme sebep oldu:

tune2fs -c 0 -i 30d /dev/sda4

-c parametresi kaç mount sonra, -i parametresi de kaç zaman sonra açılışta kontrolü zorlayacağını belirtiyormuş...

Allem ve kullem ettikten sonra yeni bir komut imdadıma (nerdeyse) hızır gibi yetişti. pm-suspend komutu karanlık ekranımıza bir güneş gibi doğdu ve ben yeniden doğru düzgün suspend edebilir oldum. Satırlarımı ecnebilerin kralları öldüğünde söylediği ünlü sözle bitirmek istiyorum:

s2ram is dead, long live the pm-suspend

Güzel yazılar oldular