Jul 2, 2008

Code Fetches in Uncacheable Memory

Note From "Intel 64 and IA-32 Arch. Software development guide Volume 3A: System Programming Guide"

10.3.3 Code Fetches in Uncacheable Memory
Programs may execute code from uncacheable (UC) memory, but the implications are different from accessing data in UC memory. When doing code fetches, the processor never transitions from cacheable code to UC code speculatively. It also never speculatively fetches branch targets that result in UC code.
The processor may fetch the same UC cache line multiple times in order to decode an instruction once. It may decode consecutive UC instructions in a cacheline without fetching between each instruction. It may also fetch additional cachelines from the same or a consecutive 4-KByte page in order to decode one non-speculative UC instruction (this can be true even when the instruction is contained fully in one line).
Because of the above and because cacheline sizes may change in future processors, software should avoid placing memory-mapped I/O with read side effects in the same page or in a subsequent page used to execute UC code.

Feb 14, 2008

HOWTO: 用Gentoo連上HiNet TB使用IPv6


1. 裝tunctl
emerge usermode-utilities

2. 改kernel config
cd /usr/src/linux ; make menuconfig
Device Drivers ---> Network device support --->
<*> Universal TUN/TAP device driver support

3. 下載 & 安裝 TB Client
su -
cd ~ ; mkdir gw6c ; cd gw6c
wget -O gw6c-5_1-RELEASE-src.tar.gz http://go6.net/4105/file.asp?file_id=150
tar -zxf gw6c-5_1-RELEASE-src.tar.gz
cd ./tspc-advanced/
make all target=linux
make install target=linux installdir=/usr/local/gw6c
chmod +x /usr/local/gw6c/template/*.sh
cd /usr/local/gw6c/bin

4. 編輯gw6c.conf


5. 開啟tun0介面給TB Client程式用
tunctl -t tun0

6. 啟動TB Client

以後要連線只需要做 5. 6.

Enjoy! ^^

Jan 6, 2008


Not until I noticed the FD_CLOEXEC flag of file descriptor, I thought all file handlers will be closed on calling exec(), and stdin, stdout, stderr will be reopened too.

But it seems not, After some testing, I think that the file handlers might be all untouched on calling exec(), opened files remained opened, closed stdio remained closed.

But if the file descriptor have set with FD_CLOEXEC flag, it'll be closed when calling exec().

About signal handling function

After running some test on FreeBSD 5.4-STABLE (Duo core machine) I've found that:

1. Signal handler function and main program won't execute concurrently.
(Not time-shared, Non-interleaved execution, Won't run on different core)

2. If multiple signal arrives:
a. Signal handler functions won't execute concurrently.
b. Later come serves first.
c. The signal number does not mean the priority of signal.
(ex: When USR1 is processing, USR2 arrives, USR2 will be served immediately. Vice versa.)
d. If the same signal is processing, and comes again, it'll be stacked. And also, later come serves first.
ex: When
USR1(a) processed in the half.
USR2(a) is processing.
USR1(b) comes again.
USR2(b) comes again.
The remaining execution order will be:
USR2(a), USR2(b), USR1(b), USR1(a), Main Program

Jan 2, 2008

Using X11Forwarding

It's a lot easier then I thought:

On the ssh server(which runs X-Client):
edit /etc/ssh/sshd_config
uncomment "#X11Forwarding no"
and modify it as "X11Forwarding yes"

On the ssh client(which has X-Server running)
edit /etc/ssh/ssh_config
uncomment "#ForwardX11 no"
and modify it as "ForwardX11 yes"

Or simply add "-X" argument when connecting to server.

If it success, after login to server, type

$ export | grep DISPLAY

you should see something like

declare -x DISPLAY="localhost:10.0"