wiki:jazz/09-01-14

Version 19 (modified by jazz, 16 years ago) (diff)

--

2009-01-14

  • Trac Wiki 改名的終極方法: 到 db/trac.db 去改內容 
    # sqlite3 db/trac.db
sqlite> update wiki set name='BOINC/Server' where name='BOINC_Server';
  • 如果有附件(Attachment)的話，比較麻煩 (1) 改 wiki (2) 改 attachment (3) 必須到 attachments/wiki/ 目錄去搬檔案 
    # sqlite3 db/trac.db
sqlite> update wiki set name='FlyCircuit/2008-03-26' where name='FlyCircit/2008-03-26';
sqlite> update attachment set id='FlyCircuit/2008-03-26' where id='FlyCircit/2008-03-26';
sqlite> update wiki set name='FlyCircuit/2008-06-24' where name='FlyCircit/2008-06-24';
sqlite> update attachment set id='FlyCircuit/2008-06-24' where id='FlyCircit/2008-06-24';

Linux 開機畫面 BootSplash? / USplash / Splashy

pixel 解析度 640x480 800x600 1024x768 1280x1024
text 文字行數 80x30 100x37 128x48 160x64
256 色( 8bit) 0x301 / 769 0x303 / 771 0x305 / 773 0x307 / 775
32k 色(16bit) 0x310 / 784 0x313 / 787 0x316 / 790 0x319 / 793
64k 色(24bit) 0x311 / 785 0x314 / 788 0x317 / 791 0x31A / 794
16M 色(32bit) 0x312 / 786 0x315 / 789 0x318 / 792 0x31B / 795

BootSplash?

USplash

Splashy

BUGFIX: jfbterm (4)

  • 在看 fbcommon.c 時，發現在這組出現錯誤的 mmap 前曾跑過另一組 mmap, 因此把參數印出來對照看看。
  • gdb debug 程序 
    file jfbterm
set args -e ls
show args
break fbcommon.c:500
break fbcommon.c:557
break fbcommon.c:566
run
p fb_fix
c
p fb_fix
c
p fb_fix.smem_len
p p->soff
p p->slen
p fb_fix.mmio_len
p p->moff
p p->mlen

    root@intrepid:~/jfbterm-0.4.7-dev# gdb
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
(gdb) file jfbterm
Reading symbols from /root/jfbterm-0.4.7-dev/jfbterm...done.
(gdb) set args -e ls
(gdb) show args
Argument list to give program being debugged when it is started is "-e ls".
(gdb) break fbcommon.c:500
Breakpoint 1 at 0x40303d: file fbcommon.c, line 500.
(gdb) break fbcommon.c:557
Breakpoint 2 at 0x40327e: file fbcommon.c, line 557.
(gdb) break fbcommon.c:566
Breakpoint 3 at 0x403301: file fbcommon.c, line 566.
(gdb) run
Starting program: /root/jfbterm-0.4.7-dev/jfbterm -e ls
...略...
Breakpoint 1, tfbm_open (p=0x6146e0) at fbcommon.c:501
501             if (fb_var.yres_virtual != fb_var.yres) {
(gdb) p fb_fix
$1 = {id = "▒\204▒▒Q\177\000\000\006\000\000\000\000\000\000", smem_start = 21037808, 
  smem_len = 4269392626, type = 32593, type_aux = 0, visual = 0,
  xpanstep = 65535, ypanstep = 65535, ywrapstep = 65535, line_length = 1, mmio_start = 15, 
  mmio_len = 21076240, accel = 0, reserved = {53071, 64, 0}}
(gdb) c
Continuing.
...略...
Breakpoint 2, tfbm_open (p=0x6146e0) at fbcommon.c:557
557             p->smem = (u_char*)mmap(NULL, p->slen, PROT_READ|PROT_WRITE,
(gdb) p fb_fix
$2 = {id = "VESA VGA\000\000\000\000\000\000\000", smem_start = 4026531840, 
  smem_len = 1572864, type = 0, type_aux = 0, visual = 3, xpanstep = 0,
  ypanstep = 0, ywrapstep = 0, line_length = 1024, mmio_start = 0, 
  mmio_len = 0, accel = 0, reserved = {0, 0, 0}}
(gdb) c
Continuing.

Breakpoint 3, tfbm_open (p=0x6146e0) at fbcommon.c:566
566             if(p->mlen == 0)
(gdb) p fb_fix.smem_len
$3 = 1572864
(gdb) p p->soff
$4 = 0
(gdb) p p->slen
$5 = 1572864
(gdb) p fb_fix.mmio_len
$6 = 0
(gdb) p p->moff
$7 = 0
(gdb) p p->mlen
$8 = 0
fb_fix.smem_len = 1572864 p->soff = 0 p->slen = 1572864 mmap 成功
fb_fix.mmio_len = 0 p->moff = 0 p->mlen = 0 mmap 失敗 (因為 length = 0)
  • 從數據看起來，無論是從 SSH 登入，或在本機 tty 使用，所得到的 fb_fix.mmio_len = 0 是主要原因。只是 mmio 所代表的意涵，fbcommon.h 程式碼並無註解。
  • 繼續往 fb_fix.mmio_len 的源頭追，是 tfbm_get_fix_screen_info 函式去更新 fb_fix 這個結構。資料是透過 ioctl 去詢問核心中對應的 FBIOGET_FSCREENINFO。 
    <fbcommon.c>

509         tfbm_get_fix_screen_info(p->fh, &fb_fix);

244 static void tfbm_get_fix_screen_info(int fh, struct fb_fix_screeninfo *fix)
245 {
246         if (ioctl(fh, FBIOGET_FSCREENINFO, fix)) {
247                 print_strerror_and_exit("ioctl FBIOGET_FSCREENINFO");
248         }
249 }
  • ​定義在 Kernel 2.6.11/drivers/video/fbmem.c 中 FBIOGET_FSCREENINFO 的 ioctl handler 
     804        case FBIOGET_FSCREENINFO:
 805                return copy_to_user(argp, &info->fix,
 806                                    sizeof(fix)) ? -EFAULT : 0;
  • ​定義在 Kernel 2.6.27/drivers/video/fbmem.c 中 FBIOGET_FSCREENINFO 的 ioctl handler 
    1247        case FBIOGET_FSCREENINFO:
1248                ret = fb_get_fscreeninfo(inode, file, cmd, arg);
1249                break;
    • fb_get_fscreeninfo 會呼叫 fb_ioctl 並以 cmd = FBIOGET_FSCREENINFO 去處理，看起來最後執行的程式碼是跟 2.6.11 一樣。 
      1013 static int 
1014 fb_ioctl(struct inode *inode, struct file *file, unsigned int cmd,
1015          unsigned long arg)

1018        struct fb_info *info = registered_fb[fbidx];

1046        case FBIOGET_FSCREENINFO:
1047                return copy_to_user(argp, &info->fix,
1048                                    sizeof(fix)) ? -EFAULT : 0;
  • 從 fb.h 的定義，我們可以確定 mmio_len 是從 info (型態為 fb_info) 結構中抓出 fb_fix_screeninfo 型態的 fix 回傳給使用者。 
    <linux-2.6.27.7/include/linux/fb.h>

 152 struct fb_fix_screeninfo {

 156        __u32 smem_len;                 /* Length of frame buffer mem */

 164        unsigned long mmio_start;       /* Start of Memory Mapped I/O   */
 165                                        /* (physical address) */
 166        __u32 mmio_len;                 /* Length of Memory Mapped I/O  */

 808 struct fb_info {

 811        struct fb_var_screeninfo var;   /* Current var */
 812        struct fb_fix_screeninfo fix;   /* Current fix */
  • 目前懷疑是 uvesafb 攔截了 FBIOGET_FSCREENINFO 的 ioctl 並回傳了不正確的 fb_fix_screeninfo 內容。因此先來寫一個測試程式，透過 FBIOGET_FSCREENINFO 的 ioctl 把 fb_fix_screeninfo 內容取出來。