tag:blogger.com,1999:blog-28261187254497717312023-11-16T01:20:41.816+08:00CoolDavid's Blogcooldavidhttp://www.blogger.com/profile/00453403892734426430noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-2826118725449771731.post-35342867017746083012009-02-21T11:26:00.002+08:002009-02-21T11:38:59.379+08:00HOWTO: 亞太 CDMA Modem 手機上網<br /><span style="font-weight: bold;">With wvdial</span><br />wvdial.conf:<br /><blockquote>[Dialer apbw]<br />Modem = /dev/ttyACM0<br />Baud = 460800<br />Phone = #777<br />Username = apbw<br />Password = apbw<br />Stupid Mode = 0<br />Auto DNS = on<br />PPPD Options = crtcts lock defaultroute<br /></blockquote>call with: "wvdial apbw"<br /><br /><span style="font-weight: bold;">With pppd directly</span><br />/etc/ppp/chat-apbw:<br /><blockquote>ABORT "NO CARRIER"<br />ABORT "NO DIALTONE"<br />ABORT "ERROR"<br />ABORT "NO ANSWER"<br />ABORT "BUSY"<br />"" "ATZ"<br />OK "ATDT#777"<br />"CONNECT"</blockquote>/etc/ppp/chap-secret:<br /><blockquote>apbw * apbw</blockquote>/etc/ppp/pap/secret:<br /><blockquote>apbw * apbw</blockquote>/etc/ppp/peer/apbw:<br /><blockquote>/dev/ttyACM0 460800<br />crtscts<br />modem<br />user apbw<br />connect '/usr/sbin/chat -v -f /etc/ppp/chat-apbw'<br />login<br />defaultroute<br />noipdefault<br />lock</blockquote>call with: "pppd call apbw"<br /><br /><br /><blockquote></blockquote>cooldavidhttp://www.blogger.com/profile/00453403892734426430noreply@blogger.com0tag:blogger.com,1999:blog-2826118725449771731.post-79895334235793968782008-07-02T15:48:00.002+08:002008-07-02T15:51:28.762+08:00Code Fetches in Uncacheable MemoryNote From "Intel 64 and IA-32 Arch. Software development guide Volume 3A: System Programming Guide"<br /><br />10.3.3 Code Fetches in Uncacheable Memory<br />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.<br />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).<br />Because of the above and because cacheline sizes may change in future processors, <span style="color: rgb(51, 51, 255);">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.</span>cooldavidhttp://www.blogger.com/profile/00453403892734426430noreply@blogger.com0tag:blogger.com,1999:blog-2826118725449771731.post-59696703362477103342008-02-14T22:15:00.000+08:002008-02-14T22:17:00.581+08:00HOWTO: 用Gentoo連上HiNet TB使用IPv6從這裡看到相關的訊息的:<br /> http://blog.ijliao.info/archives/2007/10/16/3342/<br /> http://forum.go6.net/viewtopic.php?p=704<br /><br />1. 裝tunctl<br /> emerge usermode-utilities<br /><br />2. 改kernel config<br /> cd /usr/src/linux ; make menuconfig<br /> Device Drivers ---> Network device support ---><br /> <*> Universal TUN/TAP device driver support<br /> (改好存檔重編好當然要重開機囉)<br /><br />3. 下載 & 安裝 TB Client<br /> su -<br /> cd ~ ; mkdir gw6c ; cd gw6c<br /> wget -O gw6c-5_1-RELEASE-src.tar.gz http://go6.net/4105/file.asp?file_id=150<br /> tar -zxf gw6c-5_1-RELEASE-src.tar.gz<br /> cd ./tspc-advanced/<br /> make all target=linux<br /> make install target=linux installdir=/usr/local/gw6c<br /> chmod +x /usr/local/gw6c/template/*.sh<br /> cd /usr/local/gw6c/bin<br /><br />4. 編輯gw6c.conf<br /> server=203.74.21.89<br /><br /> host_type=host<br /> #prefixlen=64<br /> if_prefix=tun0<br /> dns_server=168.95.1.1<br /><br />5. 開啟tun0介面給TB Client程式用<br /> tunctl -t tun0<br /><br />6. 啟動TB Client<br /> /usr/local/gw6c/bin/gw6c<br /><br /><br />以後要連線只需要做 5. 6.<br /><br />Enjoy! ^^cooldavidhttp://www.blogger.com/profile/00453403892734426430noreply@blogger.com0tag:blogger.com,1999:blog-2826118725449771731.post-74591885941490170922008-01-06T14:11:00.000+08:002008-01-11T03:49:19.249+08:00close-on-execNot until I noticed the FD_<span class="blsp-spelling-error" id="SPELLING_ERROR_0">CLOEXEC</span> flag of file <span class="blsp-spelling-corrected" id="SPELLING_ERROR_1">descriptor</span>, I thought all file handlers will be closed on calling exec(), and stdin, stdout, stderr will be reopened too.<br /><br />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.<br /><br />But if the file descriptor have set with FD_CLOEXEC flag, it'll be closed when calling exec().cooldavidhttp://www.blogger.com/profile/00453403892734426430noreply@blogger.com1tag:blogger.com,1999:blog-2826118725449771731.post-91940984827075769082008-01-06T13:04:00.000+08:002008-01-06T13:49:32.293+08:00About signal handling functionAfter running some test on FreeBSD 5.4-STABLE (Duo core <span class="blsp-spelling-corrected" id="SPELLING_ERROR_0">machine</span>) I've found that:<br /><br />1. Signal handler function and main program won't execute concurrently.<br /> (Not time-shared, Non-interleaved execution, Won't run on different core)<br /><br />2. If multiple signal arrives:<br /> a. Signal handler functions won't execute concurrently.<br /> b. Later come serves first.<br /> c. The signal number does not mean the priority of signal.<br /> (ex: When USR1 is processing, USR2 arrives, USR2 will be served immediately. Vice versa.)<br /> d. If the same signal is processing, and comes again, it'll be stacked. And also, later come serves first.<br /> ex: When<br /> USR1(a) processed in the half.<br /> USR2(a) is processing.<br /> USR1(b) comes again.<br /> USR2(b) comes again.<br />The remaining execution order will be:<br /> USR2(a), USR2(b), USR1(b), USR1(a), Main Programcooldavidhttp://www.blogger.com/profile/00453403892734426430noreply@blogger.com3tag:blogger.com,1999:blog-2826118725449771731.post-20600696447635058312008-01-02T15:41:00.001+08:002008-01-02T17:04:01.010+08:00Using X11ForwardingIt's a lot easier then I thought:<br /><br /><span style="font-weight: bold;font-size:130%;" >On the ssh server(which runs X-Client):</span><br />edit /etc/ssh/sshd_config<br />uncomment "#X11Forwarding no"<br />and modify it as "X11Forwarding yes"<br /><br /><br /><span style="font-weight: bold;font-size:130%;" >On the ssh client(which has X-Server running)</span><br />edit /etc/ssh/ssh_config<br />uncomment "#ForwardX11 no"<br />and modify it as "ForwardX11 yes"<br /><br />Or simply add "-X" argument when connecting to server.<br /><br /><br /><span style="font-weight: bold;font-size:130%;" >If it success, after login to server, type</span><br /><br /><span style="font-weight: bold; color: rgb(0, 0, 0); background-color: rgb(200, 200, 200);">$ export | grep DISPLAY</span><br /><br />you should see something like<br /><br /><span style="font-weight: bold; color: rgb(0, 0, 0); background-color: rgb(200, 200, 200);">declare -x DISPLAY="localhost:10.0"</span>cooldavidhttp://www.blogger.com/profile/00453403892734426430noreply@blogger.com1