[drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0

This is about how to solve a frame buffer problem I encountered after
upgrading to the 2.6.28-15-generic kernel. Last week I enabled the frame buffer
in my grub menu.lst to use the very fast fbterm(a Chinese console
environment, better than zhcon), with the following options:

vga=791 video=vesafb:ywrap,mtrr:3

At that time, everything worked well, and I really enjoyed the many
features of fbterm: display ttf font, Chinese and any other double width
characters, as well as the scrollback history.

However, after I upgraded to the latest kernel 2.6.28.15-generic in
through Ubuntu's apt, I found the console couldn't work any
longer. After the GRUB menu, everything disappeared and nothing showed
until the very late stage, when X desktop stared. If I get out to
the console with Ctrl+Alt+F1, it is still blank, and I found the
following message in dmesg every time I tried to invoke the console:

[drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for
disabled pipe 0

A quick google gave no answer to my question, and a test of booting with
the previous 2.6.28-14 kernel didn't help either. So it's not a problem
with the upgrade, and there must be something wrong with my
configuration, but I am sure I didn't change any of the system files.

...

The resolution of this problem finally came when I was checking the vga
opinions, and thought of the vesafb module. Was it loaded?

lsmod | grep fb

told me the answer, and after I load vesafb with the command:

modprobe vesafb

MY CONSOLE IS BACK!

I think the kernel should load it automatically as the options given is
clear, but it didn't. No matter how, I add the it in /etc/modules, and
hope it will solve this problem.

--------------------
UPDATE:

Found the source of the problem, in

/etc/modprobe.d/blacklist-framebuffer.conf

to solve the problem, just comment out the line of vesafb.

--------------------
UPDATE2:

It's not the blacklist, change it won't help. it's the mtrr option,
it should be:

vga=791 video=vesafb:ywrap,mtrr:1

iptables forward local port 80 to 8080

This is about how to forward local port 80 to 8080, or any other port,
which is useful when you are runing some test server with no root
privilege, while the client can still connect to the standard www port.

iptables -t nat -A OUTPUT -d 127.0.0.1 -p tcp --dport 80 -j REDIRECT --to-port 8080

cmd create a .lnk(shortcut)

We don't use any extra command tool that you have to download somewhere
else and worry about its security, but the winxp built-in cscript(or
wscript, if you prefer) to excute a little Jscript creat-a-lnk.js(source
followed), and create your shortcut on the desktop(or anywhere you want
to), quick and safe!

--------------------create-a-lnk.js--------------------
Shell = new ActiveXObject("WScript.Shell");
DesktopPath = Shell.SpecialFolders("Desktop");
link = Shell.CreateShortcut(DesktopPath + "\\shortcut-name.lnk");
// If you want:
// link = Shell.CreateShortcut("D:\\path\\to\\your\\shortcut-name.lnk");
link.Description = "a lnk created from cmd";
link.HotKey = "CTRL+ALT+SHIFT+l";
//link.IconLocation = ".exe,1";
link.TargetPath = Shell.CurrentDirectory + "\\lnk-to-this.txt";
// If you want:
// link.TargetPath = "E:\\path\\to\\your\\target.exe";
link.WindowStyle = 3;
link.Save();
--------------------create-a-lnk.js--------------------

Personally, I feel this is much better than running some unkown
XcreateLnk.exe as you can see the source, learn the process, and
guarante the security of your system.

linux zip/unzip err encoding 压缩解压中文文件 乱码

在linux下压缩和解压(zip,unzip)时,如果文件名中含有中文,就会由于文件名编码
(encoding)不同而出现平台(GNU/linux与win)之间制作的压缩包不能互相兼容的问
题,就是所谓的乱码.这里说一种最简单的解觉方法(2009)

首先,出现这种情况时不需要紧张,因为这只是文件名称的混乱,文件本身的内容还是正常
的.

然后,来看解觉的方法^_^:
前提:您身处2005以后的时代~
安装了zip,unzip ->以ubuntu为例 (~$ sudo apt-get install zip unzip)

1.制作可以在win下打开的zip压缩包
# sorry.暂缺

2.解压在win下制作的zip压缩包
~$ unzip -O cp936 /path/to/file.zip

-O 参数指定原压缩包的编码方式.
简体中文(GBK/GB2312) 为 cp936
繁体中文(BIG5) 为 cp950

结束语.
遇到问题,先尝试 -h --help,然后man,再然后才轮到Google.

小记:因为要从压缩包里取一个文件名含中文的文件夹出来,记得以前在linux下做的
压缩包在win下会打不开,反过来win下压缩的也会解压成乱码,就试验了一下.果然,
跟以前一样还是行不通的,并没有因为时间过渡到了2009,版本升到了9.04就有所改
变.乱码依旧,直接google,结果除了台湾一个贴子看起来比较有趣外,英文的搜索没
有结果,中文搜索 linux 压缩 解压 乱码得到的全部都是关于rar,7z代替的方案,
再不然就是一篇转了无数次的更改zip源代码的沉旧文章.可是我原先的zip都做好
了,并切也(还)没有养成动辙就源代码编译的好习惯(尤其是在ubuntu下),所以就准
备reboot回我们的D版winxp...

就在^D退出Terminal的这当口,想到了-h, --help.

于是就有了本篇的故事.为什么ubuntu里面带的zip不是Info-ZIP的呢?那样也许就
可以在制做压缩包的时候也指定编码格式了.

# 台湾的站
http://mrtg2.tnc.edu.tw/xoops/html/modules/weblog/details.php?blog_id=181

google code svnsync Error setting property

When I tried to sync a local repository to google code project host, I
got the Error setting property.
yang@acer:~$ svnsync init https://yangs.googlecode.com/svn file:///home/yang/code.google/
yang@acer:~$ svnsync sync https://yangs.googlecode.com/svn
.......
Committed revision 7.
Copied properties for revision 7.
Transmitting file data ................
Committed revision 8.
svnsync: Error setting property 'log'
svnsync: At least one property change failed;
repository is unchanged
svn: Error setting property 'log'
Could not execute PROPPATCH
After somewhat hours of googling, I didn't find any direct solution for
my problem, although it did help me get an general understanding of
several keyword in the err log:
PROPPATCH is an http method used in WebDav, just like GET, POST, and
PUT.
property is some technology SVN used to store additonal
information about the files in a repository.
Okay, let's go back to my problem, and its solution. In fact, it's easy,
and all included in the svn help. I didn't realize this until I went
back to the svnbook after long time unsuccessful attempts to google the
solution.
The Err message tells you that something wrong happened while setting a
property 'log'. Exactly speaking, it's the 'log' property of revision 8,
as the err happened right after revision 7's commit job was done. So, to
solve the problem, you need to check and repair the 'log' property of
r8, with the folling command:
svn propedit --revprop svn:log file:///home/yang/code.google/ -r8
In my case, it's some unknown blank new lines at the end of the 'log'
property. After remove them, and the command svnsync went through
without any problem.
Hope this will help those who encounter the same/similar questions, and
the lesson I learned from this experience, again: read the manual~