Korn

the social network

2011-03-20T21:23:00.001+08:00

just saw the movie this afternoon, really good.
Hard work plus good idea, make the money!

A moment to remember

2011-03-15T22:18:00.001+08:00

Just got a chance to test a free service from tenacy, which is really good. With that, I'm back here, effectively breaks the wall, considering buying this service now.

I feel so sad right now and wanna die

2010-07-21T17:13:00.001+08:00

I feel so sad right now and wanna die

uploaded from google doc!

2009-12-29T22:06:00.001+08:00

uploaded from google doc!

Windows more user friendly than linux

2009-05-13T16:16:00.002+08:00

And I feel much more comfortable while using windows now...
Pidgin crashed a lot and I've no idea

Get file name from file descriptor under Linux

2009-03-18T15:23:00.003+08:00

/proc/pid/fd is a directory that has symbol link files named by its fd number pointing to the real name of the opened file.
Say a process, whose pid is 2771, opend a file /lib/libc-2.9.so and its fd is 3, then the symbol link file /proc/2771/fd/3 will point to /lib/libc-2.9.so.
readlink could get the pointed file path.

memory

2009-02-05T14:15:00.001+08:00

All my friends left via as of today, I feel sad.
Best wishes to them, and good luck.

personal fedora 9 problem list

2008-10-24T21:12:00.002+08:00

1 scim lock up keyboard input
2 one of the fedora box cannot change mouse pointer on the fly

solutions:
1 do not use scim
2 logout and then login

fuck?

Found a solution, install scim-bridge-gtk

birth

2008-10-13T21:14:00.001+08:00

cui had just given birth to her boy this afternoon, congratulations to her!
And ours are also coming near, we are waiting for you baby.

function register usage

2008-09-08T11:44:00.002+08:00

I'm writing a funtion totally in asm, and found that the calling function assume some register will not be clobbered by called function. I'm puzzled by this behaviour and a few times' google revealed that the architecture's ABI defined this behaviour.
extract from abi386 doc:
Registers%ebp, %ebx, %edi, %esi, and %esp belong to the calling function. In other words, a called function must preserve these registers values for its caller. Remaining registers belong to the called function. If a calling function wants to preserve such a register value across a function call, it must save the value in its local stack frame.

tickless system

2008-07-31T11:32:00.002+08:00

I've been experiencing bad cpu performance problem with centos being the guest os using virtualbox, when the guest is up, host cpu runs at 100% even the guest os is idle. It turned out to be timer's issue. 2.6 kernel uses 1000HZ default that caused this problem(guest cannot handle so much interrupts?). Either lower the frequency to 100HZ or enable tickless system(dynamic ticks) in kernel will solve this problem.
Dunno why virtual pc is not subjected to this problem.

pointer subtraction

2008-07-29T14:56:00.001+08:00

you cannot add two pointers, and if you subtract pointers the result is the number of elements between the two pointers.

I don't know the pointer subtraction behavior till today.

my winload

2008-07-04T09:45:00.004+08:00

Well, although the name is not very good, but it now finally could kind of work. I've successfully booted linux and reactos with grub legacy and freeldr, problem existed when booting freebsd with its boot loader, I'll take time to check it.
Todo:
1 speed up winload, now it is a little slow.
2 try to boot windows

FreeBSD's boot loader utilizes virtual 8086 mode and in that mode lgdt is not usable 'cause virtual 8086 mode task runs ar CPL 3 but lgdt needs CPL 0. So winload should not be able to service freebsd's bootloader.

notes on 8259 and APIC

2008-06-29T11:00:00.001+08:00

In systems containing an 8259 PIC, the 8259 may physically be connected to the LAPIC in the system's bootstrap processor (BSP), or to one of the system's I/O APICs, or both. Logically, however, the 8259 is only connected once at any given time.

Where to find udivdi3 and umoddi3 in gcc?

2008-04-14T12:00:00.000+08:00

These are functions calls that the compiler generates to do 64bit
arithmetic operations (because they are not atomic instructions on a
32bit processor). The functions are provided by libgcc.a. You must
explicitly link this library if you have used the -nostdlibs option. You
do this with the linker option -lgcc.

Note that header files are not generally where functions 'live' they
usually merely declare functions. You need the declarations so the
compiler 'knows' hot to generate calls to them (and so it can check your
calls are valid). The functions you are having trouble with are
'internal' compiler helper functions, the code generator creates the
calls to them, for code like:

long long x = 10 ;
long long y = 3 ;
long long z = x / 3 ; // generates call to __udivdi3

Conceptually, no function is called, so no header is provided for
__udivdi3 etc. - you would not call them explicitly in your code.

Clifford

live examine kernel data

2008-04-09T10:34:00.002+08:00

$ cd src/linux
$ su
# gdb vmlinux /proc/kcore
there you go.

I've been ignorant of this fact for years, this is really good to check system data and structures.

setup_memory

2008-04-07T17:34:00.003+08:00

I'll start from start_kernel, in start_kernel, setup_arch is called for architecture dependent init. in this function, setup_memory is called to init boot memory allocator. the job of setup_memory is to find min_low_pfn(the usable minimal page frame number, that's PFN_UP(init_pg_tables_end)), max_pfn(the available maximum page frame number) and max_low_pfn(the available maximum page frame number in low memory, that's under 896MB). then, setup_bootmem_allocator is called.
this function deals with low memory only, it first find out how many bytes needed to map all the low mamory pages, by mapsize = ((max_low_pfn - min_low_pfn) + 7) / 8, and sets the area from contig_page_data->bdata->node_bootmem_map to +mapsize all 0xff. every bits of node_bootmem_map represents if this corresponding page is reserved, so set them to all 1s first means all low memory is reserved. then register_bootmem_low_pages will clear the corresponding bits if ram is available in that page. after this, linux will reserve various range, like bootmem bitmap(from _text to min_low_pfn + bootmap_size), zero page, crashkernel, acpi, etc. till now, setup_memory's job is done.

more detail:
bootmap_size = init_bootmem(min_low_pfn, max_low_pfn);
where bootmap_size is calculated as stated in the last paragraph, init_bootmem calls init_bootmem_core(contig_page_data, min_low_pfn, 0, max_low_pfn); and in this function, boot_mem_data is initialized, its node_bootmem_map is set to min_low_pfn's virtual address, node_boot_start is 0 for one node system, node_low_pfn is set to max_low_pfn, finally, memset(bdata->node_bootmem_map, 0xff, mapsize);

linux kernel data structures

2008-04-07T14:42:00.003+08:00

The page_address_map structure's main purpose is to maintain the association with a page and its virtual address. This would be wasteful if the page had a linear association with its virtual address. This becomes necessary only if the addressing is hashed:
mm/highmem.c
490 struct page_address_map {
491 struct page *page;
492 void *virtual;
493 struct list_head list;
494 };
As you can see, the object keeps a pointer to the page structure that's associated with this page, a pointer to the virtual address, and a list_head struct to maintain its position in the doubly linked list of the page address list(page_address_pool) it is in. note: these two variables are only visible when the high mem is defined, that is, support for more than 896MB physical memory is defined.

big real mode

2008-04-07T09:53:00.000+08:00

For efficiency reasons, the 80386 and later x86 processors use the base address stored in their internal "descriptor" cache whenever accessing memory, regardless if they are operating in real or protected mode. The "selector", i.e. the 16-bit "segment number" visible to the programmer is used once, while reloading a segment register, to update the various fields of the respective "descriptor", and then is simply disregarded.
To enable unreal mode, the program has to enter protected mode, locate a flat descriptor in the GDT or LDT or create such, load some of the segment registers with the respective protected mode "selector", then cancel back to real mode. When jumping back to RM, the processor will continue using the cached descriptors as established in PM - thus allowing access to 4 GB of "extended" memory from inside real mode.
From Wikipedia, the free encyclopedia

linux boot time page enable

2008-04-03T16:44:00.003+08:00

I just read the linux kernel source code about boot time page enable, files involved are: head.S.
32-bit kernel entry point is startup_32, it first set segments to known values, and then clear .bss segments so that there are no surprises; copy bootup parameters to boot_params, and finally, it came to setup page tables.
The boot time page directory address is &swapper_pg_dir, which on my box is 0xc0342000. The setup procedure is:
1 set an entry in swapper_pg_dir, the first will be pg0, which is 0xc039a000, page-up-aligned of _end.
2 Fill that entry page with physical page addresses with flags, starts from 0. That means pg0's content would be 0x0007, 0x1007, 0x2007, ...
3 After filling the whole page over, check whether the mapped address is already large enough, by comparing the last mapped address with pg0 + sizeof(page tables) + INIT_MAP_BEYOND_END. If so, stops mapping process, or continue the process again by setting a new entry in swapper_pg_dir.
When all these steps are finished, we are ready to enable page by setting bit 31 of cr0 register.
BTW, as you can see by those addresses, when the pg0 page is used up, the last address we have mapped is 0x0 + 1023 * 0x1000 = 0x3ff000. and the address that we are requested to map is pg0 + sizeof(page tables) + INIT_MAP_BEYOND_END = pg0 + 0x1000 + 128 / 4 * 0x1000 = 0x3cd000, which is smaller than 0x3ff000 that we have already mapped, so this mapping process is ok to stop. And the init_pg_tables_end points to the first safe place after page tables, that would be pg0 + 0x1000 = 0x39b000.

Find a process' page tables under Linux

2008-04-02T10:27:00.007+08:00

I've long been crazy about page management, and now I finally made a application to play with and get an idea of the page tables that a process possesses.
Here is the idea: first, a user program cannot access kernel space, and we have to explore page table structures in kernel mode, so I added a system call to the kernel for the user application to call. In this system service function, I get the kernel mode esp of this process and then I can get thread_info and then task_struct and then mm and finally the process' pgd. And with this pgd, we can walk all the entries to see which entry is valid and dump its contents, that's it.
Belowe is the result that I get:
pgd base is 0xf76e3000
gdt entry offset 32 addr 0xf76e3080 value 0x3a5da067
gdt entry offset 735 addr 0xf76e3b7c value 0x3a776067
gdt entry offset 767 addr 0xf76e3bfc value 0x3a5de067
gdt entry offset 768 addr 0xf76e3c00 value 0x000001e3
gdt entry offset 769 addr 0xf76e3c04 value 0x004001e3
gdt entry offset 770 addr 0xf76e3c08 value 0x008001e3
gdt entry offset 771 addr 0xf76e3c0c value 0x00c001e3
gdt entry offset 772 addr 0xf76e3c10 value 0x010001e3
gdt entry offset 773 addr 0xf76e3c14 value 0x014001e3
... ... repeat
gdt entry offset 786 addr 0xf76e3c48 value 0x378001e3
gdt entry offset 786 addr 0xf76e3c48 value 0x37e36163
gdt entry offset 994 addr 0xf76e3f88 value 0x37d41067
gdt entry offset 1022 addr 0xf76e3ff8 value 0x00003067
gdt entry offset 1023 addr 0xf76e3ffc value 0x00002067

The low 12 bits is for flags, and 067 represents _PAGE_PRESENT + _PAGE_RW + _PAGE_USER, so such pages are user accessible read write pages. and the 1e3 represents _PAGE_PRESENT + _PAGE_RW + _PAGE_DIRTY + _PAGE_ACCESSED + _PAGE_PSE + _PAGE_GLOBAL, so these pages are not accessible from user mode and this entry has PSE bit set that means this gdt entry points directly to a 4MB-aligned block of memory.

The biggest kernel page we saw is 0x37e36163, and before it is 0x378001e3. so 0x378001e3 means this gdt points to a 4MB block memory that begins at 0x37800000, which is 888MB, so this block of memory is 888MB-892MB. And 0x37e36163 means it's a gdt entry, it should then point to a page at physical address 0x37e36000, which is some bytes above 892MB(more detail needed).

looking at /proc/id/maps, the code page is mapped at 0x0804xxxx, so its pgd entry index is 0x0804xxxx >> 22 = 0x20 = 32, remember the first gdt entry dump index is exactly 32, so we know the code page is contained by gdt entry index 32. the libc.so.6 and ld-2.6.s0 are mapped to 0xb7xxxxxx, where x >= 0xc, so its gdt entry is 0x2df = 735, so we know the libc and ld library is contained in pgd entry 735. user mode stack is mapped at 0xbfexxxxx, so its gdt entry is 0x2ff = 767. there is a vdso mapped at 0xffffe000-0xfffff000, gdt entry offset 32 addr 0xf7229080 value 0x35395067 so its gdt entry is at 0x3ff = 1023. I don't know what does entry 1022 do.

continue to explore user accessible pages, I found for gdt entry 32, it points to 0x35395000, flags is 067, that's rw. continue to find informations at 0x35395000, there are two entries that's valid, listed below:
gdt entry offset 32 addr 0xf7229080 value 0x35395067
exploring page table at 0xf5395000
pte offset 0x48 address 0xf5395120 value 0x353f7025
pte offset 0x49 address 0xf5395124 value 0x35127067
so, the 0x48 indexed page is read-only and the 0x49 indexed page will be rw. that's equal to say for user address that's 0x8048xxx will be read-only and 0x8049xxx is writable. this is easily explained by looking its sections address, .text and .rodata is in the 0x08048xxx range and .data and .bss is in the 0x08049xxx range.

Sin City Trailer

2008-03-06T16:05:00.000+08:00

Linux Kernel 32-bits startup function

2008-03-06T15:55:00.008+08:00

Actually I'm still confused by linux kernel's startup and
how filo makes it work. I've checked the kernel image file
(bzImage) and dumped the contents at offset (kern_header->setup_sects + 1) * 512
and found out that the code there is head_32.S at arch/x86/boot/compressed.
so basically the first function executed after filo transfer control to linux
is head_32.S' startup_32, which is copied by filo to physical address 0x100000.
The address depends on the kernel image format, bzImage or zImage.
From there on, it's all linux kernel thing.
filo omits the 16-bits setup code entirely of the kernel, which is understandable.
BTW, there is a appendix of understanding linux kernel on system startup that
explains what startup_32 does.
I just learned a little bit more about the kernel 32 bit startup functions, and learned that bzImage is obtained mainly from vmlinux.bin, setup and bootsect.
vmlinux.bin is the binary format of vmlinux, which is ld ed from misc.o, head.o
and piggy.o, all there three object files are in the compressed directory.
while bootsect and setup are the 16 bits monster(I guess) that filo discarded.
So, I'll just focus on the 32 bits files.
misc.o is obtained from misc.c, which does most of the decompress job with the
help of inflate.c;
head.o is obtained from head.S, which does the start up routine, clear the BSS segment, call decompress_kernel and move the decompressed kernel to its final place 0x100000;
piggy.o is the most interesting one, which is just a ELF wrapper for the gzipped original kernel(vmlinux)'s binary format file vmlinux.bin, plus at the very beginning it adds a long type variable that is the length of the vmlinux.bin.gz. beware that this vmlinux is different from the vmlinux that I mentioned before. this vmlinux is the one located at the top directory of the src tree, and the one I mentioned before is located at the arch/i386/boot/compressed directory.
After the startup_32 routine in head.S finished its job, the uncompressed kernel
will begin its life at __PHYSICAL_START, which is generally at 0x100000.

LinuxBIOS and kernel

2008-03-05T17:17:00.003+08:00

Because LinuxBIOS doesn't provide any traditional BIOS service,
so the kernel real-mode part cannot get what it wants, like
hard disk info, memory size info, etc.
LinuxBIOS makes use of a payload acting as a boot loader, which
is responsible to load a linux kernel. This payload understands
the tables that LinuxBIOS provided so it can generate the info
the linux kernel needs without the help of BIOS service.
And filo(one of a payload) sets these info in its own defined structure, linux_init_params, and before transfer control to linux kernel, it sets
esi to the address of linux_init_params, so linux kernel 32 bit code entry
function could get these info and copy them to boot_params in head_32.S.
boot_params of linux kernel is originally used for convey infos from 16-bit
setup code to 32-bit kernel code, so I think filo has done pretty good a job.

过年回家

2008-02-18T15:29:00.002+08:00

今年过年回家了，带着老婆，在邯郸机场双飞的。去的时候爸去接的我们，飞机晚点了3个小时。回到家感觉好亲切，爸妈和妹妹都还没有吃晚饭在等着我们一起。实际上我们已经在飞机上吃过了，所以并不饿。唉，爸妈对我们太好了。接下来开始每天猪一般的生活，睡觉看电视聊天，确实是休息啊，以至于到现在我还没有恢复过来，进入不了上班的状态。这次回家没见什么同学，就是想多在家陪陪爸妈。可惜的是在临回上海三天的时候，竟然发烧了，sigh。在上飞机的时候病都没好，回到上海继续闹了3天，很久没的病了，这次终于“如愿”了。走的时候爸妈都出动为我送行了，可惜当天状态不好，早早地进入了候机厅，没有和爸妈在外面多呆一会。不知道何时才能再见面啊