Wei Chong's Blog

USB pendrive installer from DVD installer

noreply@blogger.com (Wei Chong Tan) — Sat, 31 Mar 2012 19:17:35 PDT

Again, it has been a long time since my last post. :-) This weekend I was trying to help my mom with her Linux Mint 12 installation. So, I burnt an installer DVD for her, only to find out that her old laptop's DVD drive is not working any more. It just can't read the DVD. Without downloading yet another USB pendrive image, I had to find a way to convert the installer DVD into a pendrive installer. So, here is what I did:
1. Mount the DVD installer on my own laptop, which DVD drive is working and read the size (block count) using the df command:

[weichong@aspire4810tz ~]$ df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sr0 1052128 1052128 0 100% /media/Linux Mint 12 32-bit

2. Use dd to extract the ISO from the DVD drive:

[weichong@aspire4810tz ~]$ dd if=/dev/sr0 of=./linuxmint12.iso bs=1024 count=1052128

3. Use md5sum to verify that the ISO image is the same with the original ISO image in the distro website:

[weichong@aspire4810tz ~]$ md5sum ./Downloads/linuxmint12.iso ee3d6e2ca498bc7685b7f17cdb5f2eea ./Downloads/linuxmint12.iso

4. Plug a USB pendrive into my laptop (/dev/sdb1), and follow these steps here to produce a bootable pendrive:

[weichong@aspire4810tz ~]$ su -c 'livecd-iso-to-disk ./Downloads/linuxmin12.iso /dev/sdb1'

5. Copy all the content from the mounted DVD drive to the pendrive (/media/LIVE):

[weichong@aspire4810tz ~]$ cp -R /media/Linux\ Mint\ 12\ 32-bit/* /media/LIVE/

6. Plug in this USB pendrive to my mom's laptop and boot from there. Note that the steps described here an account I try to recall. Hopefully, I didn't recall anything wrongly by mistake. If I do, hehe, this is April fool's joke. :-)

Patch to build OpenCV 2.3.0 with ffmpeg

noreply@blogger.com (Wei Chong Tan) — Thu, 14 Jul 2011 06:38:05 PDT

It has been ages I have not update my blog at all. Partly due to busy schedule, and partly due to laziness :P
Lately I am trying out OpenCV on my Ubuntu 10.04 LTS box.
Due to some issue in the old pre built libcv-dev with v4l2 which cause the webcam not able to work properly without PRELOAD=/usr/lib/libv4l/v4l1compat.so, I tried to build my own OpenCV 2.3.0 and ffmpeg from source.
However, I realize that OpenCV 2.3.0 still have not keep up with the latest changes in ffmpeg. So, I either have to content with using the ffmpeg that comes with the OpenCV source, or I have to patch it to work. I chose that later as I wanted it to use my custom ffmpeg.
Thinking that it might benefits other I try to post it here, just in case:

Index: OpenCV-2.3.0/modules/highgui/src/cap_ffmpeg_impl.hpp
===================================================================
--- OpenCV-2.3.0.orig/modules/highgui/src/cap_ffmpeg_impl.hpp 2011-07-10 11:26:54.000000000 +0800
+++ OpenCV-2.3.0/modules/highgui/src/cap_ffmpeg_impl.hpp 2011-07-10 11:50:15.000000000 +0800
@@ -135,7 +135,13 @@
#define PIX_FMT_RGBA32 PIX_FMT_RGB32
#endif

+#ifndef CODEC_TYPE_VIDEO
+#define CODEC_TYPE_VIDEO AVMEDIA_TYPE_VIDEO
+#endif

+#ifndef PKT_FLAG_KEY
+#define PKT_FLAG_KEY AV_PKT_FLAG_KEY
+#endif

char * FOURCC2str( int fourcc )
{
@@ -550,7 +556,7 @@

// First time we're called, set packet.data to NULL to indicate it
// doesn't have to be freed
- if (bFirstTime) {
+ if (bFirstTime) {
bFirstTime = false;
packet.data = NULL;
}
@@ -561,7 +567,7 @@
// free last packet if exist
if (packet.data != NULL) {
av_free_packet (&packet);
- }
+ }

// get the next frame
while (!valid) {
@@ -574,17 +580,20 @@
if( packet.stream_index != video_stream ) {
av_free_packet (&packet);
continue;
- }
+ }

-#if LIBAVFORMAT_BUILD > 4628
- avcodec_decode_video(video_st->codec,
- picture, &got_picture,
- packet.data, packet.size);
-#else
- avcodec_decode_video(&video_st->codec,
- picture, &got_picture,
- packet.data, packet.size);
-#endif
+//#if LIBAVFORMAT_BUILD > 4628
+// avcodec_decode_video(video_st->codec,
+// picture, &got_picture,
+// packet.data, packet.size);
+//#else
+// avcodec_decode_video(&video_st->codec,
+// picture, &got_picture,
+// packet.data, packet.size);
+//#endif
+avcodec_decode_video2(video_st->codec,
+ picture, &got_picture,
+ &packet);

if (got_picture) {
// we have a new picture, so memorize it
@@ -825,16 +834,16 @@
static const char * icvFFMPEGErrStr(int err)
{
switch(err) {
- case AVERROR_NUMEXPECTED:
- return "Incorrect filename syntax";
+// case AVERROR_NUMEXPECTED:
+// return "Incorrect filename syntax";
case AVERROR_INVALIDDATA:
return "Invalid data in header";
- case AVERROR_NOFMT:
- return "Unknown format";
- case AVERROR_IO:
- return "I/O error occurred";
- case AVERROR_NOMEM:
- return "Memory allocation error";
+// case AVERROR_NOFMT:
+// return "Unknown format";
+// case AVERROR_IO:
+// return "I/O error occurred";
+// case AVERROR_NOMEM:
+// return "Memory allocation error";
default:
break;
}
@@ -1237,7 +1246,7 @@
av_register_all ();

/* auto detect the output format from the name and fourcc code. */
- fmt = guess_format(NULL, filename, NULL);
+ fmt = av_guess_format(NULL, filename, NULL);
if (!fmt)
return false;

@@ -1260,7 +1269,7 @@
#endif

// alloc memory for context
- oc = av_alloc_format_context();
+ oc = avformat_alloc_context();
assert (oc);

/* set file name */

By the way, for those who intend to build OpenCV 2.2.0 instead, patches already exist here.

Hope it helps. Enjoy! :)

tty anyone? reading serially...

noreply@blogger.com (Wei Chong Tan) — Fri, 28 May 2010 05:30:42 PDT

Text terminal (and of course, console, pseudo-terminal, virtual console and terminal emulator) or TTY (teletype printer) as it is usually called, due to historical reason, is something any average Linux/UNIX user would use on a daily basis, in one form or another.
Its internal mechanism is indeed something that has always catch my attention and curiosity. Since today is a holiday, I took some time off to trace the code behind the serial interface (like ttyS0). Below is what I learn...(or so I think).

Before diving deep into the rest of the source, lets look at some definition.

#include/linux/serial_reg.h:
#define UART_RX 0 /* In: Receive buffer */
#define UART_LSR 5 /* In: Line Status Register */
#define UART_LSR_BI 0x10 /* Break interrupt indicator */
#define UART_LSR_DR 0x01 /* Receiver data ready */

And also the central structure tty_struct, which due to history reason, also include data for the line discipline.

#include/linux/tty.h:
struct tty_struct {
...
struct tty_ldisc *ldisc;
...
struct tty_bufhead buf;
...
wait_queue_head_t read_wait;
...
* The following is data for the N_TTY line discipline. For
* historical reasons, this is included in the tty structure.
...
char *read_buf;
...
struct tty_port *port;
};

When there are data on the serial (UART) interface, and the interrupt is trigger, the interrupt service routine serial8250_interrupt() is invoked.

drivers/serial/8250.c:
static irqreturn_t serial8250_interrupt(int irq, void *dev_id)
{
...
if (!(iir & UART_IIR_NO_INT)) {
serial8250_handle_port(up);
...
}

static void serial8250_handle_port(struct uart_8250_port *up)
{
...
if (status & (UART_LSR_DR | UART_LSR_BI))
receive_chars(up, &status);
...
}

static void
receive_chars(struct uart_8250_port *up, unsigned int *status)
{
...
do {
if (likely(lsr & UART_LSR_DR))
ch = serial_inp(up, UART_RX);
...
uart_insert_char(&up->port, lsr, UART_LSR_OE, ch, flag);

ignore_char:
lsr = serial_inp(up, UART_LSR);
} while ((lsr & (UART_LSR_DR | UART_LSR_BI)) && (max_count-- > 0));
...
tty_flip_buffer_push(tty);
...
}

#include/linux/serial_core.h:
static inline void
uart_insert_char(struct uart_port *port, unsigned int status,
unsigned int overrun, unsigned int ch, unsigned int flag)
{
...
tty_insert_flip_char(tty, ch, flag);
...
}

From the interrupt service routine, the callee will eventually copy the data to the corresponding tty_buffer.

#include/linux/tty_flip.h:
static inline int tty_insert_flip_char(struct tty_struct *tty,
unsigned char ch, char flag)
{
...
struct tty_buffer *tb = tty->buf.tail;
...
tb->char_buf_ptr[tb->used++] = ch;
...
}

Then, the data is push/flush to the corresponding line discipline.

drivers/char/tty_buffer.c:
* Queue a push of the terminal flip buffers to the line discipline. This
void tty_flip_buffer_push(struct tty_struct *tty)
{
...
if (tty->low_latency)
flush_to_ldisc(&tty->buf.work.work);
else
schedule_delayed_work(&tty->buf.work, 1);
}

static void flush_to_ldisc(struct work_struct *work)
{
...
struct tty_ldisc *disc;
...
disc->ops->receive_buf(tty, char_buf,
flag_buf, count);
...
}

#include/linux/tty_ldisc.h:
struct tty_ldisc_ops {
...
/*
* The following routines are called from below.
*/
void (*receive_buf)(struct tty_struct *, const unsigned char *cp,
char *fp, int count);
void (*write_wakeup)(struct tty_struct *);

...
};

struct tty_ldisc {
struct tty_ldisc_ops *ops;
...
};

The line discipline's receive_buf hook will copy the data to its own read buffer and wake up the process that is waiting (sleeping) for the incoming data.

drivers/char/n_tty.c:
* Called by the terminal driver when a block of characters has
* been received. This function must be called from soft contexts
* not from interrupt context. The driver is responsible for making
* calls one at a time and in order (or using flush_to_ldisc)
static void n_tty_receive_buf(struct tty_struct *tty, const unsigned char *cp,
char *fp, int count)
{
...
memcpy(tty->read_buf + tty->read_head, cp, i);
...
if (!tty->icanon && (tty->read_cnt >= tty->minimum_to_wake)) {
kill_fasync(&tty->fasync, SIGIO, POLL_IN);
if (waitqueue_active(&tty->read_wait))
wake_up_interruptible(&tty->read_wait);
}
...
}

struct tty_ldisc_ops tty_ldisc_N_TTY = {
...
.receive_buf = n_tty_receive_buf,
...
};

And that is how the program (like the bash shell that is running on ttyS0) receive the data!
Or at least that is what I think how it all works.
If time permits, it would be great to continue digging into how write operation works on ttyS0, and other "terminals" like pty etc.

vmware, qemu and gdb for boot time real mode debugging

noreply@blogger.com (Wei Chong Tan) — Sat, 17 Apr 2010 21:37:17 PDT

I kinda like vmware (for its speed and support of a more recent virtual hardware then the default qemu one) but all these while I favor qemu over vmware when it comes to kernel debugging since qemu let me inspect the state of the guest OS execution.

This is especially true when it comes to early boot time debugging on stuff like boot loaders where I need to guest system to halt for remote debugger as early as possible, using options such as

qemu -s -S -cpu coreduo /path/to/my/guestos.qcow2

Note that, to break very early at boot loader (or earlier) stage, at addresses such as 0x7c00, we need to boot the kernel off the target guestos.qcow2, and not using option like this one, since (I think) qemu would bypass the boot loader stage and go straight to boot the kernel.

qemu -s -S -cpu coreduo -kernel arch/x86/boot/bzImage -append "init=/bin/bash root=/dev/sda1" /path/to/my/guestos.qcow2

However, today I found out that vmware too, have awesome capability to allow me to halt the guest system for remote gdb connection, as early as the reboot vector in real mode!
All I have to do is to add the below option to my VMX config file:

debugStub.listen.guest32 = "TRUE"
debugStub.listen.guest32.remote = "TRUE"
monitor.debugOnStartGuest32 = "TRUE"

To connect to a qemu system, the gdb port to use is:

target remote localhost:1234

For vmware, it is:

target remote localhost:8832

Finally, I also learn that gdb can switch architecture, which is useful when debugging x86 guest system early in boot time, where there are real mode codes and later with protected mode code, using the commands below:

set architecture i8086
set architecture i386

Reading MSR

noreply@blogger.com (Wei Chong Tan) — Fri, 09 Apr 2010 16:21:56 PDT

Lately, I have been playing with the msr-tools utility rdmsr and wrmsr.
They are really convenient.
However, it is not so convenient when I have to play with bitwise or and bitwise and manipulation.
So, I use strace to observe how the rdmsr utility do its job.
Additionally, I read the source of linux/arch/x86/kernel/msr.c to understand how /dev/cpu/0/msr behaves.
Looks like the msr driver just use the lseek() system call to adjust the "offset", brilliant.
After that I just try to reinvent the wheel and write my own rdmsr in C.

#include <stdio.h>

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/ioctl.h>

/* Arbitrarily choose any MSR from linux/arch/x86/include/asm/msr-index.h, in this case MSR_IA32_PERF_STATUS */
#define REG_ADDR 0x198

int main ()
{
int fd = 0;
off_t of = 0;
ssize_t sz = 0;
unsigned long long int msr = 0;

fd = open("/dev/cpu/0/msr", O_RDWR);
if (!fd) {
perror("open /dev/cpu/0/msr fail\n");
return -1;
}

of = lseek(fd, REG_ADDR, SEEK_SET);
sz = read(fd, &msr, sizeof(msr));
printf("MSR %x = %llx\n", REG_ADDR, msr);

close(fd);
return 0;
}

yum install from media.repo in Fedora installer CD

noreply@blogger.com (Wei Chong Tan) — Wed, 07 Apr 2010 17:37:15 PDT

Disclaimer: I'm pretty newbie in the YUM/RPM world, so there might already be a better way to do this out there.

Usually, for shorter install time, I choose only the minimal package during the installation. I will then install more packages using the yum install after the system boots.

This is usually not a problem when the network is fast enough and I actually want to get the latest and greatest package from the remote YUM repository.

However, this becomes a problem when:
1. Network is unavailable for the new system.
2. I just want to have the exact same snapshot of RPM with the installer CD/DVD.

After playing around. I found this workaround:

# mount /dev/cdrom /media
# cp /media/media.repo /etc/yum.repos.d/

Then, add this line to /etc/yum.repos.d/media.repo under the [InstallMedia] section:

baseurl=file:///media/

The above line will enable YUM to locate /media/repodata/ for things like /media/repodata/repomd.xml.

Finally, one can do the usual yum install (to get, say xorg-x11-server-Xorg) with the cdrom still mounted to /media:

# yum install xorg-x11-server-Xorg

page fault and block device, part 3

noreply@blogger.com (Wei Chong Tan) — Tue, 06 Apr 2010 05:40:20 PDT

Just for the fun of tracing a running system while studying about page fault, I setup a qemu system to be debug via gdb. I chose to break the system at mpage_end_io_read() which gets call upon completion for waking up the process.

I executed grep upon reboot, so that the program is page fault for the 1st time.

root@(none)/# ls /bin/ | grep grep

As expected, gdb breaks at mpage_end_io_read() with the below backtrace:

#0 mpage_end_io_read (bio=0xc79c4380, err=0) at fs/mpage.c:45
#1 0xc10c0a8f in bio_endio (bio=0xc79c4380, error=0) at fs/bio.c:1431
#2 0xc1121128 in req_bio_endio (rq=0xc7983708, bio=0xc79c4380, nbytes=, error=0) at block/blk-core.c:160
#3 0xc112126c in blk_update_request (req=0xc7983708, error=, nr_bytes=) at block/blk-core.c:1976
#4 0xc1121407 in blk_update_bidi_request (rq=0xc79c4380, error=0, nr_bytes=3238806812, bidi_bytes=0) at block/blk-core.c:2077
#5 0xc1121d5b in blk_end_bidi_request (rq=0xc79c4380, error=0, nr_bytes=3238806812, bidi_bytes=0) at block/blk-core.c:2140
#6 0xc1121dc7 in blk_end_request (rq=0xc79c4380, error=0, nr_bytes=3238806812) at block/blk-core.c:2192
#7 0xc11e9883 in scsi_end_request (cmd=0xc795f900, good_bytes=) at drivers/scsi/scsi_lib.c:548
#8 scsi_io_completion (cmd=0xc795f900, good_bytes=) at drivers/scsi/scsi_lib.c:795
#9 0xc11e4a42 in scsi_finish_command (cmd=0xc795f900) at drivers/scsi/scsi.c:849
#10 0xc11e9bbc in scsi_softirq_done (rq=) at drivers/scsi/scsi_lib.c:1444
#11 0xc1126375 in blk_done_softirq (h=) at block/blk-softirq.c:34
#12 0xc1033313 in __do_softirq () at kernel/softirq.c:219
#13 0xc10333da in do_softirq () at kernel/softirq.c:266
#14 0xc10334d7 in irq_exit () at kernel/softirq.c:303
#15 0xc101534a in smp_apic_timer_interrupt (regs=) at arch/x86/kernel/apic/apic.c:826
#16 0xc1247b9a in ?? () at /home/weichong78/Development/tar/linux-2.6.34-rc3/arch/x86/include/asm/entry_arch.h:48
#17 0xc11e44c8 in spin_unlock_irqrestore (lock=0xc79c4380, flags=0) at include/linux/spinlock.h:339
#18 0xc11e4b87 in scsi_dispatch_cmd (cmd=0xc795f900) at drivers/scsi/scsi.c:752
#19 0xc11e8fd3 in scsi_request_fn (q=0xc79a0000) at drivers/scsi/scsi_lib.c:1559
#20 0xc11225c4 in __generic_unplug_device (q=0xc79a0000) at block/blk-core.c:265
#21 0xc11227d6 in generic_unplug_device (q=0xc79a0000) at block/blk-core.c:283
#22 0xc111efd2 in blk_unplug_work (work=) at block/blk-core.c:303
#23 0xc103f72b in run_workqueue (__cwq=) at kernel/workqueue.c:403
#24 worker_thread (__cwq=) at kernel/workqueue.c:445
#25 0xc1042577 in kthread (_create=0xc783ff24) at kernel/kthread.c:78
#26 0xc1002cb6 in ?? () at arch/x86/kernel/entry_32.S:1051

The code for mpage_end_io_read() is like this:

static void mpage_end_io_read(struct bio *bio, int err)
{
...
struct page *page = bvec->bv_page;
...
unlock_page(page);
...
}

So, by stepping the code until after *page is initialized, I can examine its value.

(gdb) display page
1: page =
(gdb) next
50 if (--bvec >= bio->bi_io_vec)
1: page = (struct page *) 0xc14fafa0
(gdb) print *((struct page*)0xc14fafa0)
$1 = {
flags = 1073872929,
_count = {
counter = 1
},
{
_mapcount = {
counter = -1
},
{
inuse = 65535,
objects = 65535
}
},
{
{
private = 0,
mapping = 0xc7474148
},
ptl = {
{
rlock = {
raw_lock = {
slock = 0
}
}
}
},
slab = 0x0,
first_page = 0x0
},
{
index = 3,
freelist = 0x3
},
lru = {
next = 0xc14f8cf8,
prev = 0xc13bc714
}
}

The definition of struct page is:

struct page {
...
struct address_space *mapping;
...
};

So, using gdb to cast mapping = 0xc7474148 as struct address_space*, we can see that

(gdb) print (struct address_space)*0xc7474148
$2 = {
host = 0xc747409c,
page_tree = {
height = 1,
gfp_mask = 32,
rnode = 0xc747dce9
},
tree_lock = {
{
rlock = {
raw_lock = {
slock = 1028
}
}
}
},
i_mmap_writable = 0,
i_mmap = {
prio_tree_node = 0x0,
index_bits = 1,
raw = 1
},
i_mmap_nonlinear = {
next = 0xc7474168,
prev = 0xc7474168
},
i_mmap_lock = {
{
rlock = {
raw_lock = {
slock = 0
}
}
}
},
truncate_count = 0,
nrpages = 4,
writeback_index = 0,
a_ops = 0xc125f494,
flags = 131290,
backing_dev_info = 0xc79a00b8,
private_lock = {
{
rlock = {
raw_lock = {
slock = 0
}
}
}
},
private_list = {
next = 0xc7474190,
prev = 0xc7474190
},
assoc_mapping = 0x0
}

The definition of struct address_space is:

struct address_space {
struct inode *host; /* owner: inode, block_device */
...
};

From there, we can find out which file (more precisely, inode) is this completion about:

(gdb) print (struct inode)*0xc747409c
$3 = {
i_hash = {
next = 0x0,
pprev = 0xc15d43c8
},
i_list = {
next = 0xc74652d8,
prev = 0xc139bf8c
},
i_sb_list = {
next = 0xc747bdb4,
prev = 0xc798ce74
},
i_dentry = {
next = 0xc74726a4,
prev = 0xc74726a4
},
i_ino = 186584,
i_count = {
counter = 1
},
i_nlink = 1,
i_uid = 0,
i_gid = 0,
i_rdev = 0,
i_blkbits = 12,
i_version = 1,
i_size = 100468,
i_size_seqcount = {
sequence = 0
},
i_atime = {
tv_sec = 1270473948,
tv_nsec = 0
},
i_mtime = {
tv_sec = 1220202404,
tv_nsec = 0
},
i_ctime = {
tv_sec = 1238493459,
tv_nsec = 0
},
i_blocks = 208,
i_bytes = 0,
i_mode = 33261,
i_lock = {
{
rlock = {
raw_lock = {
slock = 257
}
}
}
},
i_mutex = {
count = {
counter = 1
},
wait_lock = {
{
rlock = {
raw_lock = {
slock = 0
}
}
}
},
wait_list = {
next = 0xc7474118,
prev = 0xc7474118
},
owner = 0x0
},
i_alloc_sem = {
count = 0,
wait_lock = {
{
rlock = {
raw_lock = {
slock = 0
}
}
}
},
wait_list = {
next = 0xc747412c,
prev = 0xc747412c
}
},
i_op = 0xc125f2c0,
i_fop = 0xc125f258,
i_sb = 0xc798ce00,
i_flock = 0x0,
i_mapping = 0xc7474148,
i_data = {
host = 0xc747409c,
page_tree = {
height = 1,
gfp_mask = 32,
rnode = 0xc747dce9
},
tree_lock = {
{
rlock = {
raw_lock = {
slock = 1028
}
}
}
},
i_mmap_writable = 0,
i_mmap = {
prio_tree_node = 0x0,
index_bits = 1,
raw = 1
},
i_mmap_nonlinear = {
next = 0xc7474168,
prev = 0xc7474168
},
i_mmap_lock = {
{
rlock = {
raw_lock = {
slock = 0
}
}
}
},
truncate_count = 0,
nrpages = 4,
writeback_index = 0,
a_ops = 0xc125f494,
flags = 131290,
backing_dev_info = 0xc79a00b8,
private_lock = {
{
rlock = {
raw_lock = {
slock = 0
}
}
}
},
private_list = {
next = 0xc7474190,
prev = 0xc7474190
},
assoc_mapping = 0x0
},
i_devices = {
next = 0xc747419c,
prev = 0xc747419c
},
{
i_pipe = 0x0,
i_bdev = 0x0,
i_cdev = 0x0
},
i_generation = 1002704581,
i_fsnotify_mask = 0,
i_fsnotify_mark_entries = {
first = 0x0
},
inotify_watches = {
next = 0xc74741b4,
prev = 0xc74741b4
},
inotify_mutex = {
count = {
counter = 1
},
wait_lock = {
{
rlock = {
raw_lock = {
slock = 0
}
}
}
},
wait_list = {
next = 0xc74741c4,
prev = 0xc74741c4
},
owner = 0x0
},
i_state = 0,
dirtied_when = 0,
i_flags = 0,
i_writecount = {
counter = -1
},
i_security = 0x0,
i_acl = 0xffffffff,
i_default_acl = 0xffffffff,
i_private = 0x0
}

To identify the inode, take note on i_ino = 186584.

To verify that the inode is indeed /bin/grep, i resume the execution.
Then in the target machine's bash shell:

root@(none)/# find /bin -inum 186584
/bin/grep

Ok, admittedly this post doesn't really explore much, just for the fun of it.
If I have time to trace till the waiting (sleeping) process, then it would be more fun.
Let see how it goes. :-)

page fault and block device, part 2

noreply@blogger.com (Wei Chong Tan) — Sun, 04 Apr 2010 05:08:45 PDT

On the waking up mechanism upon completion.

Since the page faults need block device access, the waiting thread is naturally put to sleep.
This was done in mpage_bio_submit() via bio->bi_end_io = mpage_end_io_read.

Upon completion, the wake up process is done via...

linux-2.6/fs/mpage.c:
static void mpage_end_io_read(struct bio *bio, int err)
{
unlock_page(page);
}

linux-2.6/mm/filemap.c:
void unlock_page(struct page *page)
{
wake_up_page(page, PG_locked);
}

static inline void wake_up_page(struct page *page, int bit)
{
__wake_up_bit(page_waitqueue(page), &page->flags, bit);
}

linux-2.6/kernel/wait.c:
void __wake_up_bit(wait_queue_head_t *wq, void *word, int bit)
{
struct wait_bit_key key = __WAIT_BIT_KEY_INITIALIZER(word, bit);
if (waitqueue_active(wq))
__wake_up(wq, TASK_NORMAL, 1, &key);
}

page fault and block device

noreply@blogger.com (Wei Chong Tan) — Sat, 03 Apr 2010 19:44:03 PDT

Since college days, I was always told about the theory of how a page fault would eventually lead to data being page in from the secondary storage or block device.
In practice, this simple theory seems to be more then just a little complicated.
Having some free time, I try to blindly browse/grep for the related code.
I am not sure if this is one of the actual/correct path of execution when a page fault occur, leading up to the block device access to locate the data. I am pretty sure, however, that this is definitely not the only path of execution, since there are multiple condition where page fault can happen.

linux-2.6/mm/memory.c:

int handle_mm_fault(struct mm_struct *mm, struct vm_area_struct *vma,
unsigned long address, unsigned int flags)
{
return handle_pte_fault(mm, vma, address, pte, pmd, flags);
}

static inline int handle_pte_fault(struct mm_struct *mm,
struct vm_area_struct *vma, unsigned long address,
pte_t *pte, pmd_t *pmd, unsigned int flags)
{
return do_linear_fault(mm, vma, address,
pte, pmd, flags, entry);
}

static int do_linear_fault(struct mm_struct *mm, struct vm_area_struct *vma,
unsigned long address, pte_t *page_table, pmd_t *pmd,
unsigned int flags, pte_t orig_pte)
{
return __do_fault(mm, vma, address, pmd, pgoff, flags, orig_pte);
}

static int __do_fault(struct mm_struct *mm, struct vm_area_struct *vma,
unsigned long address, pmd_t *pmd,
pgoff_t pgoff, unsigned int flags, pte_t orig_pte)
{
ret = vma->vm_ops->fault(vma, &vmf);
}

linux-2.6/mm/filemap.c:

const struct vm_operations_struct generic_file_vm_ops = {
.fault = filemap_fault,
};

int filemap_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
error = mapping->a_ops->readpage(file, page);
}

linux-2.6/fs/ext2/inode.c

const struct address_space_operations ext2_aops = {
.readpage = ext2_readpage,
.readpages = ext2_readpages,
}

static int ext2_readpage(struct file *file, struct page *page)
{
return mpage_readpage(page, ext2_get_block);
}

linux-2.6/fs/mpage.c:

int mpage_readpage(struct page *page, get_block_t get_block)
{
mpage_bio_submit(READ, bio);
}

static struct bio *mpage_bio_submit(int rw, struct bio *bio)
{
bio->bi_end_io = mpage_end_io_read;
if (rw == WRITE)
bio->bi_end_io = mpage_end_io_write;
submit_bio(rw, bio);
return NULL;
}

linux-2.6/block/blk-core.c:

void submit_bio(int rw, struct bio *bio)
{
generic_make_request(bio);
}

This will just be the beginning of my investigation. More will come. Any guidance and feedback is welcome.

i915 mode setting code

noreply@blogger.com (Wei Chong Tan) — Sat, 06 Feb 2010 21:56:06 PST

In one of my previous post, I blindly rely on the higher level code to turn the display on and off.
Recently, I'm interested to look deeper into the i915 driver to understand how some of the mode setting code works, as explained in the good Intel® 965 Express Chipset Family and Intel® G35 Express Chipset Graphics Controller PRM Programmer’s Reference Manual (PRM) Volume 3: Display Registers
in www.intellinuxgraphics.org.

I start my journey with linux/drivers/gpu/drm/i915/intel_display.c.

First of all, I see:

linux/drivers/gpu/drm/i915/intel_display.c:

static const struct drm_crtc_helper_funcs intel_helper_funcs = {
.dpms = intel_crtc_dpms,
.mode_fixup = intel_crtc_mode_fixup,
.mode_set = intel_crtc_mode_set,
.mode_set_base = intel_pipe_set_base,
.prepare = intel_crtc_prepare,
.commit = intel_crtc_commit,
.load_lut = intel_crtc_load_lut,
};

At a first glance, intel_crtc_mode_set() looks like a promising place to look for mode setting code. However, since it is register as a hook of drm_crtc_helper_funcs, I presume some high level code must be calling it. To understand more about the calling sequence, I decided to look for the caller first.

linux/drivers/gpu/drm/drm_crtc_helper.c:

bool drm_crtc_helper_set_mode(...)
{
...
crtc_funcs->prepare(crtc);

/* Set up the DPLL and any encoders state that needs to adjust or depend
* on the DPLL.
*/
ret = !crtc_funcs->mode_set(crtc, mode, adjusted_mode, x, y, old_fb);
...
}

So, it is apparent that the caller will perform some preparation with intel_crtc_prepare() before calling intel_crtc_mode_set().

Some of the mode switching sequence is actually documented in the PRM's section 2.2.2 Mode Switch Programming Sequences.

When we look at intel_crtc_prepare(), looks like it is using some DPMS related code to turn of the display before setting the mode.

linux/drivers/gpu/drm/i915/intel_display.c:

static void intel_crtc_prepare (struct drm_crtc *crtc)
{
struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
crtc_funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
}

But crtc_funcs->dpms() is actually intel_crtc_dpms().
So,

linux/drivers/gpu/drm/i915/intel_display.c:

static void intel_crtc_dpms(struct drm_crtc *crtc, int mode)
{
...
struct drm_i915_private *dev_priv = dev->dev_private;
...
dev_priv->display.dpms(crtc, mode);
...
}

where...

linux/drivers/gpu/drm/i915/i915_drv.h:

typedef struct drm_i915_private {
...
/* Display functions */
struct drm_i915_display_funcs display;
...
} drm_i915_private_t;

Note that this hook is initialized in:

linux/drivers/gpu/drm/i915/intel_display.c:

static void intel_init_display(struct drm_device *dev)
{
...
/* We always want a DPMS function */
if (IS_IRONLAKE(dev))
dev_priv->display.dpms = ironlake_crtc_dpms;
else
dev_priv->display.dpms = i9xx_crtc_dpms;
...
}

So, in other words, intel_crtc_dpms() indirectly calls either ironlake_crtc_dpms() or i9xx_crtc_dpms(), to disable the display pipeline, depending on the GMCH type. For this discussion, lets take i9xx_crtc_dpms() as example.

linux/drivers/gpu/drm/i915/intel_display.c:

static void i9xx_crtc_dpms(struct drm_crtc *crtc, int mode)
{
...
int dpll_reg = (pipe == 0) ? DPLL_A : DPLL_B;
int dspcntr_reg = (plane == 0) ? DSPACNTR : DSPBCNTR;
int dspbase_reg = (plane == 0) ? DSPAADDR : DSPBADDR;
int pipeconf_reg = (pipe == 0) ? PIPEACONF : PIPEBCONF;
...
case DRM_MODE_DPMS_OFF:
...
/* Disable display plane */
temp = I915_READ(dspcntr_reg);
if ((temp & DISPLAY_PLANE_ENABLE) != 0) {
I915_WRITE(dspcntr_reg, temp & ~DISPLAY_PLANE_ENABLE);
/* Flush the plane changes */
I915_WRITE(dspbase_reg, I915_READ(dspbase_reg));
I915_READ(dspbase_reg);
}

if (!IS_I9XX(dev)) {
/* Wait for vblank for the disable to take effect */
intel_wait_for_vblank(dev);
}

/* Next, disable display pipes */
temp = I915_READ(pipeconf_reg);
if ((temp & PIPEACONF_ENABLE) != 0) {
I915_WRITE(pipeconf_reg, temp & ~PIPEACONF_ENABLE);
I915_READ(pipeconf_reg);
}

/* Wait for vblank for the disable to take effect. */
intel_wait_for_vblank(dev);

temp = I915_READ(dpll_reg);
if ((temp & DPLL_VCO_ENABLE) != 0) {
I915_WRITE(dpll_reg, temp & ~DPLL_VCO_ENABLE);
I915_READ(dpll_reg);
}

/* Wait for the clocks to turn off. */
udelay(150);
}

The mode switching disabling sequence is explained in the PRM as follow:

2.2.2 Mode Switch Programming Sequences
...
• Planes must be disabled before pipe is disabled or pipe timings changed.
...
Table 2-1. Mode Switch Sequences
...
Disable sequence
...
Disable ports
Disable planes (VGA or hires)
Disable pipe
Disable VGA display in 0x71400 bit 31
(Disable VGA display done after disable pipe to allow pipe to turn off when no vblank is available in native VGA mode)
If Gen4 { Wait for pipe off status }
(Wait ensures planes and pipe have completely turned off prior to disabling panelfitter then
DPLL)
Disable panelfitter
Disable DPLL
...

After the disabling sequence comes the enabling sequence, where drm_crtc_helper_set_mode() will indirectly call intel_crtc_mode_set() via the crtc_funcs hooks.

Firstly, the reference clock frequency is determined.

linux/drivers/gpu/drm/i915/intel_display.c:

static int intel_crtc_mode_set(...)
{
...
} else if (IS_I9XX(dev)) {
refclk = 96000;
...
}

The information about reference clock can be seen in the PRM:

2.5 Display Clock Control Registers (06000h–06FFFh)

Reference Frequency:
96MHz for SDVO CRT, HDMI,
96MHz or 100MHz for LVDS.

After performing some DPLL magic (magic because my shallow knowledge doesn't fully comprehend the PRM yet :-), intel_crtc_set_mode() proceed to set the new "mode":

linux/drivers/gpu/drm/i915/intel_display.c:

static int intel_crtc_mode_set(...)
{
...
/* setup pipeconf */
pipeconf = I915_READ(pipeconf_reg);

/* Set up the display plane register */
dspcntr = DISPPLANE_GAMMA_ENABLE;
...
dspcntr |= DISPLAY_PLANE_ENABLE;
pipeconf |= PIPEACONF_ENABLE;
dpll |= DPLL_VCO_ENABLE;
...
I915_WRITE(htot_reg, (adjusted_mode->crtc_hdisplay - 1) |
((adjusted_mode->crtc_htotal - 1) << 16));
I915_WRITE(hblank_reg, (adjusted_mode->crtc_hblank_start - 1) |
((adjusted_mode->crtc_hblank_end - 1) << 16));
I915_WRITE(hsync_reg, (adjusted_mode->crtc_hsync_start - 1) |
((adjusted_mode->crtc_hsync_end - 1) << 16));
I915_WRITE(vtot_reg, (adjusted_mode->crtc_vdisplay - 1) |
((adjusted_mode->crtc_vtotal - 1) << 16));
I915_WRITE(vblank_reg, (adjusted_mode->crtc_vblank_start - 1) |
((adjusted_mode->crtc_vblank_end - 1) << 16));
I915_WRITE(vsync_reg, (adjusted_mode->crtc_vsync_start - 1) |
((adjusted_mode->crtc_vsync_end - 1) << 16));
...
I915_WRITE(pipesrc_reg, ((mode->hdisplay - 1) << 16) | (mode->vdisplay - 1));
...
I915_WRITE(pipeconf_reg, pipeconf);
I915_READ(pipeconf_reg);

intel_wait_for_vblank(dev);
...
I915_WRITE(dspcntr_reg, dspcntr);
...
}

Much of the information about mode adjustment code can be found in the PRM section 2.7 Display Pipeline / Port Registers (60000h–6FFFFh), 2.10.1.3 PIPEACONF—Pipe A Configuration Register and also Enable sequence in 2.2.2 Mode Switch Programming Sequences.

I guess that is the overall flow of what happen during a KMS mode setting like when we use xrandr to select another resolution.
Having said that, this is just the beginning of my investigation and nothing here is authoritative. If any of you understand better, please do enlighten me. Any advise is welcome.

OpenOffice Automation with Python

noreply@blogger.com (Wei Chong Tan) — Thu, 04 Feb 2010 04:41:18 PST

Linux and UNIX users tend to automate many things with script and I'm no exception.
However, most of the scripting skill I have learned tend to deal with text files and text terminal.
Lately, I am interested to learn how to apply similar scripting automation to modern GUI application after noticing a few of my friends have trouble with spreadsheet formula verifications.

After browsing around the web and some useful advice from friend forum users, I started to out to try some ad hoc script on OpenOffice.org 3.1 using Python.

Here is my ad hoc script that populate two simple column with data and generate a chart from there:

from com.sun.star.awt import Rectangle

def populateSheet1():
ctx = XSCRIPTCONTEXT.getComponentContext()
doc = XSCRIPTCONTEXT.getDocument()
shs = doc.getSheets()
sht = shs.getByName("Sheet1")
crg = sht.getCellRangeByName("A1:B1")
crg.setPropertyValue("CellBackColor", 0xF000F0)
cel = sht.getCellByPosition(0,0)
cel.setFormula("value")
sht.getCellByPosition(1,0).setFormula("value x 2")
crg = sht.getCellRangeByName("A2:A11")
crg.setPropertyValue("CellBackColor", 0x00F0F0)
for r in range(1,11):
cel = sht.getCellByPosition(0,r)
cel.setValue(r)
cel = sht.getCellByPosition(1,r)
fml = "=A" + str(r+1) + "*2"
cel.setFormula(fml)
adr = sht.getCellRangeByName("A2:A11").getRangeAddress()
a = (adr,)
# Properties can be access directly or using getPropertyValue()
siz = sht.getCellByPosition(2,0).Size
pos = sht.getCellByPosition(2,0).getPropertyValue("Position")
rect = Rectangle()
rect.X = pos.X
rect.Y = pos.Y
rect.Width = siz.Width * 3
rect.Height = siz.Height * 11
chs = sht.getCharts()
chs.addNewByName("Chart1", rect, a, True, False)

The result is...

Linux ACPI processor and C-states

noreply@blogger.com (Wei Chong Tan) — Wed, 13 Jan 2010 07:43:04 PST

I always wanted to understand how Linux ACPI subsystem prepare my laptop CPU for entering C-state when it has nothing productive to do.
After some kernel code reading, below is what I believe how it works.

Firstly, the ACPI code scan the system and register anything it can find.

drivers/acpi/scan.c
:

struct bus_type acpi_bus_type = {

...

.probe = acpi_device_probe,

...

};

static int acpi_device_probe(struct device * dev)

{

...

ret = acpi_bus_driver_init(acpi_dev, acpi_drv);

...

}

static int acpi_bus_driver_init(struct acpi_device *device, struct acpi_driver *driver)

{

...

result = driver->ops.add(device);

...

}

Particularly, ACPI code will add the device and driver for ACPI processor.

drivers/acpi/processor_core.c:

static struct acpi_driver acpi_processor_driver = {

...

.add = acpi_processor_add,

...

};

static int __cpuinit acpi_processor_add(struct acpi_device *device)

{

...

acpi_processor_power_init(pr, device);

...

}

When a processor is found or "added", it obtains the relevant information in this way.
acpi_processor_get_power_info_cst() is where the bulk of the initialization is done,
especially on
struct acpi_processor_cx.
Here it reads the ACPI _CST object from BIOS.

drivers/acpi/processor_idle.c:

int __cpuinit acpi_processor_power_init(struct acpi_processor *pr, struct acpi_device *device)
{
...
acpi_processor_get_power_info(pr);
...
}

static int acpi_processor_get_power_info(struct acpi_processor *pr)

{

...

result = acpi_processor_get_power_info_cst(pr);

if (result == -ENODEV)

result = acpi_processor_get_power_info_fadt(pr);

...

}

static int acpi_processor_get_power_info_cst(struct acpi_processor *pr)

{

...

status = acpi_evaluate_object(pr->handle, "_CST", NULL, &buffer);

...

if (reg->space_id == ACPI_ADR_SPACE_FIXED_HARDWARE) {

if (acpi_processor_ffh_cstate_probe(pr->id, &cx, reg) == 0) {

...

}

Finally, the architecture specific code will fill in the details:

arch/x86/kernel/acpi/cstate.c:

#define MWAIT_ECX_INTERRUPT_BREAK (0x1)

int acpi_processor_ffh_cstate_probe(unsigned int cpu, struct acpi_processor_cx *cx, struct acpi_power_register *reg)

{

...

retval = work_on_cpu(cpu, acpi_processor_ffh_cstate_probe_cpu, cx);

if (retval == 0) {

/* Use the hint in CST */

percpu_entry->states[cx->index].eax = cx->address;

percpu_entry->states[cx->index].ecx = MWAIT_ECX_INTERRUPT_BREAK;

}

...

}

static long acpi_processor_ffh_cstate_probe_cpu(void *_cx)

{

...

cpuid(CPUID_MWAIT_LEAF, &eax, &ebx, &ecx, &edx);

/* Check whether this particular cx_type (in CST) is supported or not */

cstate_type = ((cx->address >> MWAIT_SUBSTATE_SIZE) & MWAIT_CSTATE_MASK) + 1;

edx_part = edx >> (cstate_type * MWAIT_SUBSTATE_SIZE);

num_cstate_subtype = edx_part & MWAIT_SUBSTATE_MASK;

...

}

How does the kernel actually make the CPU enter C-state? It usually trigger it via the cpuidle subsystem code, which we will discuss on another day :). But just the ACPI processor portion, here is a preview:

void acpi_processor_ffh_cstate_enter(struct acpi_processor_cx *cx)

{

...

mwait_idle_with_hints(percpu_entry->states[cx->index].eax,

percpu_entry->states[cx->index].ecx);

}

Linux ACPI T-state Processor Throttling, Part 1

noreply@blogger.com (Wei Chong Tan) — Thu, 07 Jan 2010 06:31:33 PST

Lately, T-state caught my attention.
So, let's start browsing over some kernel code.

linux-2.6/drivers/acpi/processor_core.c:

static int __init acpi_processor_init(void)
{
...
result = acpi_bus_register_driver(&acpi_processor_driver);
...
}

where

linux-2.6/drivers/acpi/processor_core.c:

static struct acpi_driver acpi_processor_driver = {
.name = "processor",
.class = ACPI_PROCESSOR_CLASS,
.ids = processor_device_ids,
.ops = {
.add = acpi_processor_add,
.remove = acpi_processor_remove,
.suspend = acpi_processor_suspend,
.resume = acpi_processor_resume,
.notify = acpi_processor_notify,
},
};

So, from the look of it, upon detection of a newly "added" processor, I guess...

linux-2.6/drivers/acpi/processor_core.c:

static int __cpuinit acpi_processor_add(struct acpi_device *device)
{
...
acpi_processor_get_throttling_info(pr);
...
}

int acpi_processor_get_throttling_info(struct acpi_processor *pr)
{
...
/*
* Evaluate _PTC, _TSS and _TPC
* They must all be present or none of them can be used.
*/
if (acpi_processor_get_throttling_control(pr) ||
acpi_processor_get_throttling_states(pr) ||
acpi_processor_get_platform_limit(pr))
{
pr->throttling.acpi_processor_get_throttling =
&acpi_processor_get_throttling_fadt;
pr->throttling.acpi_processor_set_throttling =
&acpi_processor_set_throttling_fadt;
if (acpi_processor_get_fadt_info(pr))
return 0;
} else {
...
if (acpi_processor_get_tsd(pr)) {
...
}

browsing along...

linux-2.6/drivers/acpi/processor_throttling.c:

/*
* _PTC - Processor Throttling Control (and status) register location
*/
static int acpi_processor_get_throttling_control(struct acpi_processor *pr)
{
...
status = acpi_evaluate_object(pr->handle, "_PTC", NULL, &buffer);
...
}

where according to ACPI 3.0a spec:

8.4.3.1 _PTC (Processor Throttling Control)
_PTC is an optional object that defines a processor throttling control interface alternative to the I/O address spaced-based P_BLK throttling control register (P_CNT)
...
OSPM performs processor throttling control by writing the Control field value for the target throttling state (T-state), retrieved from the Throttling Supported States object (_TSS), to the Throttling Control Register (THROTTLE_CTRL) defined by the _PTC object.
...
The _PTC object contains data in the following format:
Name (_PTC, Package()
{
ResourceTemplate(){Throttling_Control_Register}, //Generic Register Descriptor
ResourceTemplate(){Throttling_Status_Register} //Generic Register Descriptor
}) // End of _PTC

So, back to the code:

/*
* _TSS - Throttling Supported States
*/
static int acpi_processor_get_throttling_states(struct acpi_processor *pr)
{
...
status = acpi_evaluate_object(pr->handle, "_TSS", NULL, &buffer);
...
}

where according to ACPI 3.0a spec:

8.4.3.2 _TSS (Throttling Supported States)
This optional object indicates to OSPM the number of supported processor throttling states that a platform supports.

Again, back to the code:

linux-2.6/drivers/acpi/processor_throttling.c:

/*
* _TPC - Throttling Present Capabilities
*/
static int acpi_processor_get_platform_limit(struct acpi_processor *pr)
{
...
status = acpi_evaluate_integer(pr->handle, "_TPC", NULL, &tpc);
...
}

where the ACPI 3.0a spec says:

8.4.3.3 _TPC (Throttling Present Capabilities)
This optional object is a method that dynamically indicates to OSPM the number of throttling states currently supported by the platform. This method returns a number that indicates the _TSS entry number of the highest power throttling state that OSPM can use at a given time. OSPM may choose the corresponding state entry in the _TSS as indicated by the value returned by the _TPC method or any lower power (higher numbered) state entry in the _TSS.

Looking acpi_processor_get_tsd():

linux-2.6/drivers/acpi/processor_throttling.c:

/*
* _TSD - T-State Dependencies
*/
static int acpi_processor_get_tsd(struct acpi_processor *pr)
{
...
status = acpi_evaluate_object(pr->handle, "_TSD", NULL, &buffer);
...
}

where again, according to the ACPI 3.0a spec:

8.4.3.4 _TSD (T-State Dependency)
This optional object provides T-state control cross logical processor dependency information to OSPM.
The _TSD object evaluates to a packaged list of information that correlates with the T-state information returned by the _TSS object. Each packaged list entry identifies a dependency domain number for the logical processor’s T-states, the coordination type for that T-state and the number of logical processors belonging to the domain.

Ok, thats all for a quick 15 minutes investigation for tonight. More to be continue in future post.

CPU Temperature via lm-sensors vs ACPI

noreply@blogger.com (Wei Chong Tan) — Sun, 03 Jan 2010 19:17:58 PST

Recently, I'm curious about how Linux detect/report my laptop health, particularly the CPU temperature and learn that there are actually at least 2 related but not identical way of obtaining such information. One via ACPI and another via lm-sensors infrastructure.

For lm-sensors running on my personal laptop, it can utilize the coretemp driver which basically just read of the IA32_THERM_STATUS MSR (0x19C), as can be seen from the kernel code below:

linux/drivers/hwmon/coretemp.c:

static struct coretemp_data *coretemp_update_device(struct device *dev)
{
struct coretemp_data *data = dev_get_drvdata(dev);
...
rdmsr_on_cpu(data->id, MSR_IA32_THERM_STATUS, &eax, &edx);
...
}

For ACPI related code, my guess is that the kernel depends on ACPI _TMP Object in obtaining the temperature of the "thermal zone", as can be seen from the snippet below:

linux/drivers/acpi/thermal.c:

static int acpi_thermal_get_info(struct acpi_thermal *tz)
{
...
/* Get temperature [_TMP] (required) */
result = acpi_thermal_get_temperature(tz);
...
}

static int acpi_thermal_get_temperature(struct acpi_thermal *tz)
{
...
status = acpi_evaluate_integer(tz->device->handle, "_TMP", NULL, &tmp);
...
}

From the ACPI 3.0a spec I downloaded, it states that _TMP is the "Thermal zone object that returns current temperature in tenths of degrees Kelvin".
So, it depends on how my laptop ACPI (BIOS) implements _TMP, that is what I get, I guess.
In the meantime, I'm still curious about the code in linux/drivers/acpi/processor_thermal.c. But that will be for my next post :-).

cpufreq and acpi

noreply@blogger.com (Wei Chong Tan) — Thu, 31 Dec 2009 17:22:29 PST

Happy New Year 2010, everybody!
Let this be my first post in 2010 :)

Ok, so lately I'm curious about how my laptop's acpi-cpufreq gets its value:

weichong78@weichong78-ulv:/sys/devices/system/cpu/cpu0/cpufreq$ cat scaling_available_frequencies
1300000 1200000

So, I dive straight into the code of arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c.
In the initialization code:

static int __init acpi_cpufreq_init(void)
{
...
ret = cpufreq_register_driver(&acpi_cpufreq_driver);
...
}

where acpi_cpufreq_driver is:

static struct cpufreq_driver acpi_cpufreq_driver = {
.verify = acpi_cpufreq_verify,
.target = acpi_cpufreq_target,
.bios_limit = acpi_processor_get_bios_limit,
.init = acpi_cpufreq_cpu_init,
.exit = acpi_cpufreq_cpu_exit,
.resume = acpi_cpufreq_resume,
.name = "acpi-cpufreq",
.owner = THIS_MODULE,
.attr = acpi_cpufreq_attr,
};

In acpi_cpufreq_cpu_init:

static int acpi_cpufreq_cpu_init(struct cpufreq_policy *policy)
{
...
struct acpi_cpufreq_data *data;
...
struct acpi_processor_performance *perf;
...
result = acpi_processor_register_performance(data->acpi_data, cpu);
...
}

We can find in drivers/acpi/processor_perflib.c:

int
acpi_processor_register_performance(struct acpi_processor_performance
*performance, unsigned int cpu)
{
...
if (acpi_processor_get_performance_info(pr)) {
...
}

static int acpi_processor_get_performance_info(struct acpi_processor *pr)
{
...
status = acpi_get_handle(pr->handle, "_PCT", &handle);
...
result = acpi_processor_get_performance_control(pr);
...
result = acpi_processor_get_performance_states(pr);
...
}

static int acpi_processor_get_performance_control(struct acpi_processor *pr)
{
...
status = acpi_evaluate_object(pr->handle, "_PCT", NULL, &buffer);
...
}

static int acpi_processor_get_performance_states(struct acpi_processor *pr)
{
...
status = acpi_evaluate_object(pr->handle, "_PSS", NULL, &buffer);
...
}

So, there we have it, acpi-cpufreq takes from ACPI _PCT and _PSS. But from where? And what do they mean?

After some investigation, I try the below:

weichong78@weichong78-ulv:/tmp$ cp /sys/firmware/acpi/tables/dynamic/SSDT* .
weichong78@weichong78-ulv:/tmp$ cp /sys/firmware/acpi/tables/SSDT* .
weichong78@weichong78-ulv:/tmp$ iasl -d SSDT*

weichong78@weichong78-ulv:/tmp$ grep _PCT SSDT*
Binary file SSDT3 matches
SSDT3.dsl: Method (_PCT, 0, NotSerialized)
Binary file SSDT5 matches
SSDT5.dsl: Method (_PCT, 0, NotSerialized)
SSDT5.dsl: Method (_PCT, 0, NotSerialized)
SSDT5.dsl: Return (\_PR.CPU1._PCT ())
SSDT5.dsl: Method (_PCT, 0, NotSerialized)
SSDT5.dsl: Return (\_PR.CPU1._PCT ())

weichong78@weichong78-ulv:/tmp$ grep _PSS SSDT*
Binary file SSDT3 matches
SSDT3.dsl: Name (_PSS, Package (0x02)
Binary file SSDT5 matches
SSDT5.dsl: External (\_PR_.CPU0._PSS, IntObj)
SSDT5.dsl: Method (_PSS, 0, NotSerialized)
SSDT5.dsl: Return (\_PR.CPU0._PSS)
SSDT5.dsl: Method (_PSS, 0, NotSerialized)
SSDT5.dsl: Return (\_PR.CPU1._PSS ())
SSDT5.dsl: Method (_PSS, 0, NotSerialized)
SSDT5.dsl: Return (\_PR.CPU1._PSS ())

Ok, so _PCT and _PSS are found under SSDT. Now, there is only one thing left to find out, the definitions of _PCT and _PSS. The best place to find such info is of course the ACPI spec.
Rather then writing them in my own words, I'm going to just quote from the copy of Advanced Configuration and Power Interface Specification 3.0a that I just downloaded.

For _PCT:

8.4.4.1 _PCT (Performance Control)
This optional object declares an interface that allows OSPM to transition the processor into a performance state. OSPM performs processor performance transitions by writing the performance state–specific control value to a Performance Control Register (PERF_CTRL).
OSPM may select a processor performance state as indicated by the performance state value returned by the _PPC method, or any lower power (higher numbered) state. The control value to write is contained in the corresponding _PSS entry’s “Control” field.
Success or failure of the processor performance transition is determined by reading a Performance Status Register (PERF_STATUS) to determine the processor’s current performance state. If the transition was successful, the value read from PERF_STATUS will match the “Status” field in the _PSS entry that corresponds to the desired processor performance state.
This object evaluates to a package that declares the above-mentioned transition control and status addresses
as follows:
Name (_PCT, Package()
{
ResourceTemplate(){Perf_Ctrl_Register},
ResourceTemplate(){Perf_Status_Register}
}) // End of _PCT

8.4.4.2 _PSS (Performance Supported States)
This optional object indicates to OSPM the number of supported processor performance states that any given system can support. This object evaluates to a packaged list of information about available performance states including internal CPU core frequency, typical power dissipation, control register values needed to transition between performance states, and status register values that allow OSPM to verify performance transition status after any OS-initiated transition change request. The list is sorted in descending order by typical power dissipation. As a result, the zeroth entry describes the highest performance state and the ‘nth’ entry describes the lowest performance state.

Name (_PSS, Package()
{ // Field Name Field Type
Package () // Performance State 0 Definition – P0
{
CoreFreq, // DWordConst
Power, // DWordConst
TransitionLatency, // DWordConst
BusMasterLatency, // DWordConst
Control, // DWordConst
Status // DWordConst
},
.
.
.
Package () // Performance State n Definition – Pn
{
CoreFreq, // DWordConst
Power, // DWordConst
TransitionLatency, // DWordConst
BusMasterLatency, // DWordConst
Control, // DWordConst
Status // DWordConst
}
}) // End of _PSS object
Each performance state entry contains six data fields as follows:
• CoreFreq. Indicates the core CPU operating frequency (in MHz).
• Power. Indicates the performance state’s maximum power dissipation (in milliWatts).
• TransitionLatency. Indicates the worst-case latency in microseconds that the CPU is unavailable during a transition from any performance state to this performance state.
• BusMasterLatency. Indicates the worst-case latency in microseconds that Bus Masters are prevented from accessing memory during a transition from any performance state to this performance state.
• Control. Indicates the value to be written to the Performance Control Register (PERF_CTRL) in order to initiate a transition to the performance state.
• Status. Indicates the value that OSPM will compare to a value read from the Performance Status
Register (PERF_STATUS) to ensure that the transition to the performance state was successful. OSPM may always place the CPU in the lowest power state, but additional states are only available when indicated by the _PPC method.

So, there we have it, Happy New Year! :)

startup_32 continues...

noreply@blogger.com (Wei Chong Tan) — Fri, 11 Dec 2009 06:31:22 PST

One year later, I finally have the time and opportunity to continue my exploration of Linux kernel boot code, following my previous posts here, here, here, here and here.

For Bootstrap Processor (BSP), the code start at:

startup_32 (arch/x86/kernel/head_32.S)

The execution started by setting up GDT (first with boot_gdt_descr, later with early_gdt_descr) and IDT, and also copy boot_params to another location. It also initialize page tables using swapper_pg_dir etc. Some of these detail can be found on books, so I'm going to just skip over.
Application Processor (AP) also executes some of these code, but it started from startup_32_smp rather then from the beginning of startup_32.

Approaching the end of startup_32, it jumps to the location pointed by:

*initial_code (arch/x86/kernel/head_32.S)

which is:

i386_start_kernel (arch/x86/kernel/head32.c)

Here in i386_start_kernel, memory is reserved for trampoline code (which we will investigate some other day :-), and the built in kernel initramfs, which is excellently documented here.
Then, from the x86 specific code, it jumps to the architecture independent code at:

start_kernel (init/main.c)

which is explained in some of the good kernel book, such as Professional Linux Kernel Architecture by Wolfgang Mauerer.
Among other things, start_kernel also call x86 specific code in:

setup_arch (arch/x86/kernel/setup.c)

which I will be interested to inspect with more detail in the near future.

kernel rpmbuild shortcut

noreply@blogger.com (Wei Chong Tan) — Sat, 07 Nov 2009 20:23:23 PST

Admittedly I'm more of a Debian/Ubuntu fan than a Fedora/Redhat fan. But occasionally I need to dive into the RPM world too.
One thing that troubles me (maybe it is due to my shallow understanding) is kernel compilation in the RPM world.
I know 2 different proper ways of kernel compilation in the RPM land:

1. Using the git kernel, we can do a 'make rpm-pkg'.
2. Using the src.rpm, we can do a rpmbuild -bb.

However, neither of these method fits my need. To be more specific, I need a method which, after my first complete compilation, allows me to just do minor modification, compile only that portion and link everything again. This is important to me when I need to do random ad hoc changes and don't wish to wait for a complete rebuild, since the kernel is only for my own personal experimental usage, and not a production build.
Using method 1, for it seems that unlike 'make deb-pkg', 'make rpm-pkg' seems to 'rm -rf' the entire build tree and rebuild the entire kernel again from scratch each time it is run. While method 2 let me short cut the build using command like 'rpmbuild -bi' etc, it won't let me complete the build (or maybe I just don't know the right way).
So, usually what I do is 'make deb-pkg' in a .DEB world, and then use 'alien -r' to switch it to RPM. While handy, this method would not work in a real .RPM distro.
Lately, however, I have discover a new workaround by observing how 'alien -r -v' works.
Below, I will describe the method I use with a git kernel, .src.rpm kernel can be similarly used by unpacking the kernel source.

1. In linux/ source tree, perform a 1st round of complete kernel build using the vanilla 'make' command.
2. mkdir -p /tmp/linux-install/boot/
3. make INSTALL_PATH=/tmp/linux-install/boot/ install
4. mkdir -p /tmp/linux-install/lib/modules/
5. make INSTALL_MOD_PATH=/tmp/linux-install/ modules_install (this will also install firmware)
6. mkdir -p /tmp/linux-install/usr/
7. make INSTALL_HDR_PATH=/tmp/linux-install/usr/ headers_install

At this point, the /tmp/linux-install/ will have a complete installation of the Linux kernel.
Create a kernelhack.spec file that only have the %files section like below (the easiest way to get this sort of .spec file is to hijack it from alien).

Name: kernelhack
Version: 2.6.32.rc6
Release: netbook
Summary: Kernel RPM created by packaging the 'make install' result

Group: System Environment/Kernel
License: GPLv2
URL: http://www.kernel.org

%description
The kernel package contains only the files under /boot such as vmlinuz and System.map

%files
# %defattr(-,root,root,-)
# %doc
%dir /boot
/boot/*
%dir /lib/firmware
/lib/firmware/*
%dir /lib/modules
/lib/modules/*
%dir /usr/include
/usr/include/*

%changelog

In addition, add the below to your .rpmmacros:

%_buildrootdir /tmp/
%buildroot %{_buildrootdir}/linux-install/

%_rpmdir /tmp/RPMS/

%_nonzero_exit_pkgcheck_terminate_build 0
%_unpackaged_files_terminate_build 0
%_missing_doc_files_terminate_build 0
%_binaries_in_noarch_packages_terminate_build 0
%_missing_build_ids_terminate_build 0

Finally, just do a 'rpmbuild -bb kernelhack.spec'
When a modification is needed, just repeat the 'make install' steps above to install it to /tmp/linux-install/ and rerun the rpmbuild.

My new USB video class webcam, EXOO M031

noreply@blogger.com (Wei Chong Tan) — Sat, 10 Oct 2009 04:48:37 PDT

I just bought a webcam to try out some applications in my Linux laptop. To prevent from buying yet-another-win-only-product, I did my home work and print the supported webcam list for the gspca and uvc driver with me. In fact, I brought along my laptop with me to test it out. As I expected, there are only very limited choices in my local store, and the first reaction from the store keeper is always say NO to the L word before he even check it out. But I insisted to try them out. To my suprise there is a low-end webcam that has a penguin logo on its box. So, I tried that and viola, it worked without any extra configuration. So, I purchased that.
The box didn't show the brand name but it seems that both my Debian (with latest git kernel) and Ubuntu is able to detect and drive it with the uvcvideo driver.
I'm happy that the manufacturer, EXOO produce something that works across OS using the USB Video Class UVC standard and thus would like to introduce this to those of you who read my blog, thereby encouraging you to support manufacturer that produce such Linux friendly product. Here is a link to the webcam website.
Good on you, EXOO!

get_current task_struct, stack pointer and FS segment, part 2

noreply@blogger.com (Wei Chong Tan) — Fri, 18 Sep 2009 08:17:58 PDT

The new utilization of per cpu area to locate current task_struct really got me confused for a while. This has motivated me to "use the source" (and objdump the binary) again.

The per cpu area is located via the 27th entry of the GDT. One can inspect this by dumping out the GDT using, say, kernel debugger or anything. I use the free dtdumper tool by cr0.org.

GDT size: 0xFF (32 entries), GDT LA: 0xC3C00000

(#027) 0xD8 028F937A8000FFFF Data D/B=16bts AVL=0 Present DPL=0 TYPE= eWA BASE=0x027A8000 LIMIT=0xFFFFFFFF

This segment is defined here in the source:

arch/x86/include/asm/segment.h:

* ------- start of kernel segments:
* 12 - kernel code segment <==== new cacheline
#define GDT_ENTRY_KERNEL_BASE 12
* 27 - per-cpu [ offset to per-cpu data area ]
#define GDT_ENTRY_PERCPU (GDT_ENTRY_KERNEL_BASE + 15)

The code that setup this segment entry is here:

arch/x86/kernel/setup_percpu.c:

static inline void setup_percpu_segment(int cpu)
write_gdt_entry(get_cpu_gdt_table(cpu),
GDT_ENTRY_PERCPU, &gdt, DESCTYPE_S);

which was called from here, in the same source file:

arch/x86/kernel/setup_percpu.c:

void __init setup_per_cpu_areas(void)
/* alrighty, percpu areas up and running */
delta = (unsigned long)pcpu_base_addr - (unsigned long)__per_cpu_start;
for_each_possible_cpu(cpu) {
per_cpu_offset(cpu) = delta + pcpu_unit_offsets[cpu];
per_cpu(this_cpu_off, cpu) = per_cpu_offset(cpu);
per_cpu(cpu_number, cpu) = cpu;
setup_percpu_segment(cpu);

The per_cpu_offset is actually a macro that expand to the __per_cpu_offset array defined in setup_percpu.c itself:

arch/x86/kernel/setup_percpu.c:

unsigned long __per_cpu_offset[NR_CPUS] __read_mostly = {
[0 ... NR_CPUS-1] = BOOT_PERCPU_OFFSET,
};
EXPORT_SYMBOL(__per_cpu_offset);

with the help from:

include/asm-generic/percpu.h:

#ifdef CONFIG_SMP
/*
* per_cpu_offset() is the offset that has to be added to a
* percpu variable to get to the instance for a certain processor.
*
* Most arches use the __per_cpu_offset array for those offsets but
* some arches have their own ways of determining the offset (x86_64, s390).
*/
#ifndef __per_cpu_offset
extern unsigned long __per_cpu_offset[NR_CPUS];
#define per_cpu_offset(x) (__per_cpu_offset[x])
#endif

If one notice the GDT dump above, one would be curious about BASE=0x027A8000, since such linear address would be way below the 0xc0000000 kernel address. To understand this, we have to understand the line

delta = (unsigned long)pcpu_base_addr - (unsigned long)__per_cpu_start;

in the arch/x86/kernel/setup_percpu.c code above.

The variable pcpu_base_addr is define here:

mm/percpu.c:

/* the address of the first chunk which starts with the kernel static area */
void *pcpu_base_addr __read_mostly;

while __per_cpu_start is the start of a section, added by the linker during the kernel image build, as can be seen in the linker script here:

arch/x86/kernel/vmlinux.lds:

. = ALIGN((1 << 12)); .data.percpu : AT(ADDR(.data.percpu) - 0xC0000000) { __per_cpu_load = .; __per_cpu_start = .; *(.data.percpu.first) *(.data.percpu.page_aligned) *(.data.percpu) *(.data.percpu.shared_aligned) __per_cpu_end = .; }

So, in essence, what is store in the BASE portion of the GDT 27th entry, is the offset between the pcpu_base_addr variable (which would of cause have a linear address above 0xC0000000) and the __per_cpu_start introduced during linking. I believe the delta is needed to compensate for the difference in the link time address and the actual load/run time address. This offset will correctly offset the processor to locate the run time per cpu variable, such as per_cpu__current_task which points to the current active task_struct.

To ensure myself of my own findings, I disassemble vmlinux. And can be seen from the mix C-asm disassembly,

int do_one_initcall(initcall_t fn):

static __always_inline struct task_struct *get_current(void)
{
return percpu_read_stable(current_task);
c1001142: 64 a1 54 94 45 c1 mov %fs:0xc1459454,%eax
/*

and as we can see by doing objump -x vmlinux:

c1459454 g O .data.percpu 00000004 per_cpu__current_task

this is how the current task_struct can be retrieved via the offset stored in 27th entry of GDT.

By the way, the 27th entry of GDT is accessed by %fs segment register.

Well, this is what I found out so far by refering to the source in Linux 2.6.31. Feel free to educate me if what I think I understand is wrong. Thank you.

get_current task_struct, stack pointer and FS segment, part 1

noreply@blogger.com (Wei Chong Tan) — Fri, 18 Sep 2009 06:49:41 PDT

Recently, I was playing around with some toy kernel code and found out that in arch x86, the get_current() inline function that the 'current' macro expands to whenever we try to access the task_struct of the active running process is no longer the same as previously explained in many Linux kernel books such as Robert Love's Linux Kernel Development and also Bovet's Understanding the Linux Kernel.
What I learn from the books earlier was that the current task_struct can be access via the current thread_info, which can be located using the %esp stack pointer since they share the same 4k (or 8k depends on config) pages.
Currently, for asm-generic/current.h, that method is still there, but for x86, the new method is to utilized the per cpu area. The change has been around for some time now (and more changes since), as can be detected by git diff as can be seen below:

git diff 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2..7c3576d261ce046789a7db14f43303f8120910c7 -- include/asm-i386/current.h

diff --git a/include/asm-i386/current.h b/include/asm-i386/current.h
index d973289..d352485 100644
--- a/include/asm-i386/current.h
+++ b/include/asm-i386/current.h
@@ -1,13 +1,15 @@
#ifndef _I386_CURRENT_H
#define _I386_CURRENT_H

-#include
+#include
+#include

struct task_struct;

-static inline struct task_struct * get_current(void)
+DECLARE_PER_CPU(struct task_struct *, current_task);
+static __always_inline struct task_struct *get_current(void)
{
- return current_thread_info()->task;
+ return x86_read_percpu(current_task);
}

#define current get_current()

and this one too...

git diff 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2..ec7fcaabbfb3c5bd5189f857b6ac7bb9745ef291 -- include/asm-i386/current.h

diff --git a/include/asm-i386/current.h b/include/asm-i386/current.h
index d973289..5252ee0 100644
--- a/include/asm-i386/current.h
+++ b/include/asm-i386/current.h
@@ -1,13 +1,14 @@
#ifndef _I386_CURRENT_H
#define _I386_CURRENT_H

-#include
+#include
+#include

struct task_struct;

-static inline struct task_struct * get_current(void)
+static __always_inline struct task_struct *get_current(void)
{
- return current_thread_info()->task;
+ return read_pda(pcurrent);
}

#define current get_current()

Playing with Integrated Graphics Device D-state

noreply@blogger.com (Wei Chong Tan) — Sat, 05 Sep 2009 18:19:50 PDT

Following my previous toy on switching AC'97 between D3 - D0 states, I was tempted to play with more complex components in my personal laptop. However, just passing the PCI IDs of my integrated graphics device wouldn't work as the device has more state to maintain then just the PCI config space, I think. Navigating around further in the kernel source makes me think in terms of utilizing the suspend/resume hook of the DRM (direct rendering manager) kernel codes. I saw that there is a pci_driver embedded inside the DRM code. So, I try to use that. My initial attempts failed, until a friend remind me that the i915 DRM code is not necessarily registering itself as a pci_driver unless Kernel Mode Setting code is being utilized. So, I try my code under Fedora 11 (kernel 2.6.29.5-191.fc11.i586 and xorg-x11-server-Xorg-1.6.1.901-1.fc11.i586) where the X.org i915 is using KMS and it works! So, here is my updated toy code:

/* PCI Power Management D-state test

* Copyright (c) 31 August 2009 Tan Wei Chong

* This file is released under the GPLv2 */

#include <linux/init.h>
#include <linux/module.h>

#include <linux/pci.h>

#include <linux/pci_ids.h>

#include <linux/pm.h>
#include <drm/drmP.h>

/* default test device was the AC97 controller in the author's laptop */

#define PCI_DSTATE_VENDOR_ID_DEFAULT PCI_VENDOR_ID_INTEL

#define PCI_DSTATE_DEVICE_ID_DEFAULT PCI_DEVICE_ID_INTEL_82801DB_5

#define PCI_DSTATE_BUS_DEFAULT 0x0

#define PCI_DSTATE_SLOT_DEFAULT 0x1f

#define PCI_DSTATE_FUNC_DEFAULT 0x5

static int use_devfn = 0;

static unsigned short bus = 0;

static unsigned short slot = 0;

static unsigned short func = 0;

static unsigned int vendor_id = 0;

static unsigned int device_id = 0;

static struct pci_dev* pci_dstate_find_dev (void)

{

struct pci_dev *pci_dev;

pci_dev = NULL;

if (use_devfn) {

if (!bus) bus = PCI_DSTATE_BUS_DEFAULT;

if (!slot) slot = PCI_DSTATE_SLOT_DEFAULT;

if (!func) func = PCI_DSTATE_FUNC_DEFAULT;

printk("pci_dstate_find_dev: bus = %x, slot = %x, func = %x\n", bus, slot, func);

pci_dev = pci_get_bus_and_slot(bus, PCI_DEVFN(slot, func));

} else {

if (!vendor_id) vendor_id = PCI_DSTATE_VENDOR_ID_DEFAULT;

if (!device_id) device_id = PCI_DSTATE_DEVICE_ID_DEFAULT;

printk("pci_dstate_find_dev: vendor_id = %x, device_id = %x\n", vendor_id, device_id);

pci_dev = pci_get_device(vendor_id, device_id, NULL);

}

if (pci_dev) {

printk("pci_dstate_find_dev: pci_dev->vendor = %x, pci_dev->device = %x\n", pci_dev->vendor, pci_dev->device);

printk("pci_dstate_find_dev: pci_dev->bus->number = %x, pci_dev->devfn = %x (PCI_SLOT = %x, PCI_FUNC = %x)\n",

pci_dev->bus->number, pci_dev->devfn, PCI_SLOT(pci_dev->devfn), PCI_FUNC(pci_dev->devfn));

printk("pci_dstate_find_dev: pci_dev->class = %x\n", pci_dev->class);

} else {

printk("pci_dstate_find_dev: pci_dev is NULL!\n");

}

return pci_dev;

}

static int gfx_d3hot (struct pci_dev* pci_dev)

{

pm_message_t state;

if (pci_dev && pci_dev->driver && pci_dev->driver->suspend) {

state.event = PM_EVENT_SUSPEND;

return pci_dev->driver->suspend(pci_dev, state);

} else {

if (!pci_dev)

printk("gfx_d3hot: pci_dev is NULL, do nothing\n");

else if (!pci_dev->driver)

printk("gfx_d3hot: pci_dev->driver is NULL, do nothing\n");

else if (!pci_dev->driver->suspend)

printk("gfx_d3hot: pci_dev->driver->suspend is NULL, do nothing\n");

return 0;

}

}

static void pci_d3hot (struct pci_dev* pci_dev)

{

pci_power_t power_state;

power_state = PCI_D3hot;

if (pci_dev) {

pci_save_state(pci_dev);

pci_set_power_state(pci_dev, power_state);

}

}

static int gfx_d0 (struct pci_dev* pci_dev)

{

if (pci_dev && pci_dev->driver && pci_dev->driver->resume) {

return pci_dev->driver->resume(pci_dev);

} else {

if (!pci_dev)

printk("gfx_d0: pci_dev NULL, do nothing\n");

else if (!pci_dev->driver)

printk("gfx_d0: pci_dev->driver is NULL, do nothing\n");

else if (!pci_dev->driver->resume)

printk("gfx_d0: pci_dev->driver->resume is NULL, do nothing\n");

return 0;

}

}

static void pci_d0 (struct pci_dev* pci_dev)

{

pci_power_t power_state;

power_state = PCI_D0;

if (pci_dev) {

pci_set_power_state(pci_dev, power_state);

pci_restore_state(pci_dev);

}

}

int __init pci_dstate_init (void)

{

struct pci_dev *pci_dev;

pci_dev = pci_dstate_find_dev();

if (pci_dev->class == (PCI_CLASS_DISPLAY_VGA << 8)) {

gfx_d3hot(pci_dev);

} else {

pci_d3hot(pci_dev);

}

return 0;

}

void __exit pci_dstate_exit (void)

{

struct pci_dev *pci_dev;

pci_dev = pci_dstate_find_dev();

if (pci_dev->class == (PCI_CLASS_DISPLAY_VGA << 8)) {

gfx_d0(pci_dev);

} else {

pci_d0(pci_dev);

}

}

module_init(pci_dstate_init);

module_exit(pci_dstate_exit);

MODULE_PARM_DESC(use_devfn, "true means use bus/slot/func, false means use vendor id and device id");

module_param(use_devfn, bool, S_IRUGO);

MODULE_PARM_DESC(bus, "PCI bus number");

module_param(bus, ushort, S_IRUGO);

MODULE_PARM_DESC(slot, "PCI device/slot number");

module_param(slot, ushort, S_IRUGO);

MODULE_PARM_DESC(func, "PCI device/slot number");

module_param(func, ushort, S_IRUGO);

MODULE_PARM_DESC(vendor_id, "PCI vendor ID");

module_param(vendor_id, uint, S_IRUGO);

MODULE_PARM_DESC(device_id, "PCI device ID");

module_param(device_id, uint, S_IRUGO);

MODULE_LICENSE("GPL");

Playing with PCI PM D-state

noreply@blogger.com (Wei Chong Tan) — Mon, 31 Aug 2009 06:01:40 PDT

Its been a really long time I haven't post anything. Yeah, life is busy, and I am lazy :).
About that I'm just thinking of just putting a test program I play with tonight to shut off my personal home laptop's PCI device (which I just arbitrarily chose my AC'97 audio controller for its simplicity).
I use speaker-test and lspci to verify that the device does in fact switch between D0 and D3.
Long story short, here is my hobbyist test program :).

/* PCI Power Management D-state test
* Copyright (c) 31 August 2009 Tan Wei Chong
* This file is released under the GPLv2 */

#include <linux/init.h>
#include <linux/module.h>
#include <linux/pci.h>
#include <linux/pci_ids.h>

/* default test device was the AC97 controller in the author's laptop */
#define PCI_DSTATE_VENDOR_ID_DEFAULT PCI_VENDOR_ID_INTEL
#define PCI_DSTATE_DEVICE_ID_DEFAULT PCI_DEVICE_ID_INTEL_82801DB_5
#define PCI_DSTATE_BUS_DEFAULT 0x0
#define PCI_DSTATE_SLOT_DEFAULT 0x1f
#define PCI_DSTATE_FUNC_DEFAULT 0x5

static bool use_devfn = false;
static unsigned short bus = 0;
static unsigned short slot = 0;
static unsigned short func = 0;
static unsigned int vendor_id = 0;
static unsigned int device_id = 0;
static struct pci_dev *pci_dev;

int __init pci_dstate_init (void)
{
pci_power_t power_state;

power_state = PCI_D3hot;

if (use_devfn) {
if (!bus) bus = PCI_DSTATE_BUS_DEFAULT;
if (!slot) slot = PCI_DSTATE_SLOT_DEFAULT;
if (!func) func = PCI_DSTATE_FUNC_DEFAULT;
printk("pci_dstate_init: bus = %x, slot = %x, func = %x\n", bus, slot, func);
pci_dev = pci_get_bus_and_slot(bus, PCI_DEVFN(slot, func));
} else {
if (!vendor_id) vendor_id = PCI_DSTATE_VENDOR_ID_DEFAULT;
if (!device_id) device_id = PCI_DSTATE_DEVICE_ID_DEFAULT;
printk("pci_dstate_init: vendor_id = %x, device_id = %x\n", vendor_id, device_id);
pci_dev = pci_get_device(vendor_id, device_id, NULL);
}
if (!pci_dev) {
printk("pci_dstate_init: pci_dev is NULL!\n");
goto init_finish;
}
printk("pci_dstate_init: pci_dev->vendor = %x, pci_dev->device = %x\n", pci_dev->vendor, pci_dev->device);
printk("pci_dstate_init: pci_dev->bus->number = %x, pci_dev->devfn = %x (PCI_SLOT = %x, PCI_FUNC = %x)\n",
pci_dev->bus->number, pci_dev->devfn, PCI_SLOT(pci_dev->devfn), PCI_FUNC(pci_dev->devfn));
pci_save_state(pci_dev);
pci_set_power_state(pci_dev, power_state);
init_finish:
printk("pci_dstate_init return\n");
return 0;
}

void __exit pci_dstate_exit (void)
{
pci_power_t power_state;

power_state = PCI_D0;
if (!pci_dev) {
printk("pci_dstate_exit: pci_dev is NULL!\n");
goto exit_finish;
}
pci_set_power_state(pci_dev, power_state);
pci_restore_state(pci_dev);
exit_finish:
printk("pci_dstate_exit return\n");
}

module_init(pci_dstate_init);
module_exit(pci_dstate_exit);

MODULE_PARM_DESC(use_devfn, "true means use bus/slot/func, false means use vendor id and device id");
module_param(use_devfn, bool, S_IRUGO);

MODULE_PARM_DESC(bus, "PCI bus number");
module_param(bus, ushort, S_IRUGO);

MODULE_PARM_DESC(slot, "PCI device/slot number");
module_param(slot, ushort, S_IRUGO);

MODULE_PARM_DESC(func, "PCI device/slot number");
module_param(func, ushort, S_IRUGO);

MODULE_PARM_DESC(vendor_id, "PCI vendor ID");
module_param(vendor_id, uint, S_IRUGO);

MODULE_PARM_DESC(device_id, "PCI device ID");
module_param(device_id, uint, S_IRUGO);

MODULE_LICENSE("GPL");

exploring page cache and picking up oops debugging

noreply@blogger.com (Wei Chong Tan) — Wed, 22 Oct 2008 05:26:28 PDT

A while ago, I wrote a small toy kernel module to understand how a process interact with page cache after accessing a file, to verify what I have learn from the great ULK3:

#include <linux/module.h>
#include <linux/init.h>
#include <linux/fs.h>
#include <linux/cdev.h>
#include <linux/sched.h>
#include <linux/file.h>
#include <linux/pagemap.h>
#include <linux/highmem.h>
#include <asm/uaccess.h>

#define FILEPROBE_MAJOR 200
#define FILEPROBE_MINOR 0

struct fileprobe {
int qpid;
dev_t dev;
struct cdev cdev;
};

struct fileprobe fp;

static int fileprobe_open (struct inode *inode, struct file *file)
{
printk("fileprobe_open\n");
return 0;
}

static ssize_t fileprobe_read (struct file* file, char __user *buf, size_t count, loff_t *ppos)
{
printk("fileprobe_read\n");
return 0;
}

static void fileprobe_queryfile (struct file* qfile)
{
struct page* qpage;
char* qcontent;

printk("fileprobe_queryfile\n");
printk("find_get_page 0\n");
qpage = find_get_page(qfile->f_mapping, 0);
if (NULL != qpage) {
qcontent = (char*)kmap(qpage);
if (NULL != qcontent) {
printk(" the content of 1st page is [%c%c%c%c]\n", qcontent[0], qcontent[1], qcontent[2], qcontent[3]);
kunmap((void*)qcontent);
}
}
printk("find_get_page 1\n");
qpage = find_get_page(qfile->f_mapping, 1);
if (NULL != qpage) {
qcontent = (char*)kmap(qpage);
if (NULL != qcontent) {
printk(" the content of 2nd page is [%c%c%c%c]\n", qcontent[0], qcontent[1], qcontent[2], qcontent[3]);
kunmap((void*)qcontent);
}
}
}

static ssize_t fileprobe_write (struct file* file, const char __user *buf, size_t count, loff_t *ppos)
{
struct task_struct *qtask;
int fd_nr;
struct file* qfile;

printk("fileprobe_write\n");
get_user(fp.qpid, (int __user *)buf);

for_each_process(qtask) {
if(qtask->pid == fp.qpid) {
printk("task_struct found for PID %d, %s\n", qtask->pid, qtask->comm);
for(fd_nr = 0; fd_nr <>files->fdt->max_fds; fd_nr++) {
qfile = qtask->files->fdt->fd[fd_nr];
if(qfile != NULL) {
printk(" fd_nr is %d, dentry->d_iname is %s\n", fd_nr, qfile->f_path.dentry->d_iname);
if(0 == strcmp(qfile->f_path.dentry->d_iname,"fileprobe.log")) {
fileprobe_queryfile(qfile);
}
}
}
}
}
return 0;
}

struct file_operations f_ops = {
.open = fileprobe_open,
/* .release = fileprobe_release, */
.read = fileprobe_read,
.write = fileprobe_write
};

int __init fileprobe_init (void)
{
int ret;
printk("fileprobe_init\n");
cdev_init(&fp.cdev, &f_ops);
fp.dev = MKDEV(FILEPROBE_MAJOR, FILEPROBE_MINOR);
ret = register_chrdev_region(fp.dev, 1, "fileprobe");
ret = cdev_add(&fp.cdev, fp.dev, 1);
if (ret != 0) goto err1;
return 0;
err1:
unregister_chrdev_region(fp.dev, 1);
return -1;
}

void __exit fileprobe_exit (void)
{
cdev_del(&fp.cdev);
unregister_chrdev_region(fp.dev, 1);
printk("fileprobe_exit\n");
}

module_init(fileprobe_init);
module_exit(fileprobe_exit);

MODULE_LICENSE("GPL");

Basically, it is a simple character device module that accept a PID as argument. With that PID, it search for the task_struct from the task list. It then search the task_struct's file descriptor table to look for an open file with the file name (from dentry) "fileprobe.log". With the located struct file, it try to look for the corresponding struct address_space through f_mapping. The address_space structure has a (if I remember correctly) red-black tree of struct page which identify which physical page frame host the file content. The module utilizes the kernel function find_get_page() to locate the page frames by passing the 4k page order as the second argument. It then use kmap to obtain a virtual address of the physical page and use printk to display partial content of "fileprobe.log".

Now this whole thing is very toyish and canned for learning purpose only. The content of "fileprobe.log" is exactly 8k. The first 4k starts with 3 characters "1st" follow by all 'X' characters while the second 4k starts with 3 characters "2nd" follow by all 'Y', to make it easy for verification. Basically, such a file can easily be created by a perl command line like

perl -e 'print "X"x4096'

with the first 3 characters replaced (vim recommended :-).

I then conduct the experiment by using less to open the "fileprobe.log" file, obtain the PID of the less process and write the value to the device node of the kernel module using a user space program like:

#include
#include
#include

int main (int argc, char** argv)
{
int qpid = atoi(argv[1]);
printf("qpid is %d\n", qpid);
int fd = open("./fileprobe", O_WRONLY);
write(fd, &qpid, sizeof(qpid));
close(fd);
return 0;
}

With the description above, all went well. But the above kernel module was not the original version, which had the below difference:

--- fileprobe.c 2008-10-21 21:12:23.000000000 +0800
+++ fileprobe.c.orig 2008-10-21 21:11:07.000000000 +0800
@@ -42,7 +42,7 @@
if (NULL != qpage) {
qcontent = (char*)kmap(qpage);
if (NULL != qcontent) {
- printk(" the content of 1st page is [%c%c%c%c]\n", qcontent[0], qcontent[1], qcontent[2], qcontent[3]);
+ printk(" the content of 1st page is [%s]\n", qcontent);
kunmap((void*)qcontent);
}
}
@@ -51,7 +51,7 @@
if (NULL != qpage) {
qcontent = (char*)kmap(qpage);
if (NULL != qcontent) {
- printk(" the content of 2nd page is [%c%c%c%c]\n", qcontent[0], qcontent[1], qcontent[2], qcontent[3]);
+ printk(" the content of 2nd page is [%s]\n", qcontent);
kunmap((void*)qcontent);
}
}

This original version actually gave an OOPs the first time I tried, which looks like this:

[ 852.962496] fileprobe_init
[ 853.794718] fileprobe_open
[ 853.794728] fileprobe_write
[ 853.794753] task_struct found for PID 9096, less
[ 853.794756] fd_nr is 0, dentry->d_iname is tty2
[ 853.794758] fd_nr is 1, dentry->d_iname is tty2
[ 853.794761] fd_nr is 2, dentry->d_iname is tty2
[ 853.794763] fd_nr is 3, dentry->d_iname is tty
[ 853.794765] fd_nr is 4, dentry->d_iname is fileprobe.log
[ 853.794767] fileprobe_queryfile
[ 853.794769] find_get_page 0
[ 853.794810] BUG: unable to handle kernel paging request at virtual address ffa0b000
[ 853.794813] printing eip: c021a6f6 *pde = 00004067 *pte = 00000000
[ 853.794819] Oops: 0000 [#1] SMP
[ 853.794898] Modules linked in: fileprobe michael_mic arc4 ecb blkcipher ieee80211_crypt_tkip appletalk ax25 ipx p8023 binfmt_misc rfcomm l2cap bluetooth uinput ppdev i915 drm ipv6 sbs container sbshc dock cpufreq_conservative cpufreq_ondemand cpufreq_userspace cpufreq_powersave cpufreq_stats freq_table iptable_filter ip_tables x_tables aes_i586 dm_crypt dm_mod lp af_packet pcmcia battery ac snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm psmouse ipw2200 serio_raw yenta_socket rsrc_nonstatic pcmcia_core ieee80211 ieee80211_crypt snd_seq_dummy video output snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event button snd_seq snd_timer snd_seq_device intel_agp thinkpad_acpi nvram evdev agpgart parport_pc parport shpchp pci_hotplug iTCO_wdt iTCO_vendor_support snd soundcore snd_page_alloc pcspkr ext3 jbd mbcache sg sr_mod cdrom sd_mod ata_generic pata_acpi ata_piix e100 mii libata scsi_mod ehci_hcd uhci_hcd usbcore thermal processor fan fbcon tileblit font bitblit softcursor fuse
[ 853.797243]
[ 853.797281] Pid: 9146, comm: fileprobe_user Not tainted (2.6.24-19-generic #1)
[ 853.797343] EIP: 0060:[] EFLAGS: 00010097 CPU: 0
[ 853.797392] EIP is at strnlen+0x6/0x20
[ 853.797433] EAX: ffa0b000 EBX: c048e93e ECX: ffa0a000 EDX: ffffeffe
[ 853.797479] ESI: ffa0a000 EDI: 00000000 EBP: ffffffff ESP: ebb97e88

[ 853.797525] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 853.797570] Process fileprobe_user (pid: 9146, ti=ebb96000 task=ea3dc5c0 task.ti=ebb96000)
[ 853.797619] Stack: c0219c99 000c2091 00000000 0000000a 00000006 ffffffff 00000001 00000400
[ 853.797848] c048e920 0000000a c048ed20 ffa0a000 ffffffff ffffffff f8e1731b 00000400
[ 853.798075] ffa0a000 ea308b80 00000000 c0219f14 ebb97f68 ea1e6600 c012ce7c ebb97f64
[ 853.798303] Call Trace:
[ 853.798372] [] vsnprintf+0x459/0x610
[ 853.798453] [] vscnprintf+0x14/0x20
[ 853.798519] [] vprintk+0x5c/0x380
[ 853.798591] [] set_page_address+0xa2/0x160
[ 853.798663] [] kmap_high+0x18f/0x1b0
[ 853.798732] [] printk+0x1b/0x20
[ 853.798795] [] fileprobe_write+0x117/0x180 [fileprobe]
[ 853.798866] [] fileprobe_write+0x0/0x180 [fileprobe]
[ 853.798931] [] vfs_write+0xb9/0x170
[ 853.799000] [] sys_write+0x41/0x70
[ 853.799067] [] sysenter_past_esp+0x6b/0xa9
[ 853.799143] =======================
[ 853.799182] Code: 90 8d 74 26 00 85 c9 57 89 c7 89 d0 74 05 f2 ae 75 01 4f 89 f8 5f c3 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 89 c1 89 c8 eb 06 <80> 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 c3 90 90 90 90 90 90
[ 853.800471] EIP: [] strnlen+0x6/0x20 SS:ESP 0068:ebb97e88
[ 853.800555] ---[ end trace 45550c129f3be6fa ]---

The OOPs actually puzzled me for a while, until I talked to a mighty parrot this afternoon, and he noticed the "strnlen" in the OOPs, which I was careless enough to missed that obvious hint, thinking that it could be related instead to kmap, all these while, silly me.

So, go along with that hint, I tried to modify the module which looks like the final version above, and yippie, it worked, with the following dmesg instead:

[ 686.833604] fileprobe_init
[ 724.422097] fileprobe_open
[ 724.422107] fileprobe_write
[ 724.422139] task_struct found for PID 7564, less
[ 724.422142] fd_nr is 0, dentry->d_iname is 1
[ 724.422144] fd_nr is 1, dentry->d_iname is 1
[ 724.422146] fd_nr is 2, dentry->d_iname is 1
[ 724.422148] fd_nr is 3, dentry->d_iname is tty
[ 724.422151] fd_nr is 4, dentry->d_iname is fileprobe.log
[ 724.422153] fileprobe_queryfile
[ 724.422154] find_get_page 0
[ 724.422157] the content of 1st page is [1stX]
[ 724.422159] find_get_page 1
[ 724.422161] the content of 2nd page is [2ndY]
[ 724.422163] fd_nr is 11, dentry->d_iname is
[ 724.422166] fd_nr is 62, dentry->d_iname is
[ 724.422168] fd_nr is 63, dentry->d_iname is

Notice the content of the page starts with "1stX" and the second with "2ndY"? Well, looks like what I read in ULK3 is true.

By the way, on an unrelated account, the mighty parrot also told me that /etc in Linux stands for "errata configuration" and /usr stands for "UNIX service resource". :-)

Ok, it is getting late, and I'm tired, so that's all I'm going to dump in this post for now. If there is any error you notice, please do drop me a comment or email so that I can correct them.

objdump vmlinux

noreply@blogger.com (Wei Chong Tan) — Tue, 14 Oct 2008 05:31:45 PDT

Being able to quickly figure out which part of the kernel source code correspond to the binary (in memory image of) running kernel is always handy, especially when debugging a faulty/oops/crashing system.
A while ago, I used objdump -d -S on the .ko file of the driver I compiled which would intersperse my driver source with the .ko binary. Thinking along that line, vmlinux should be able to give us similar output with the kernel source code. After searching around in the web, I found this site that confirms this.
I tried objdump -d -S vmlinux and got a huge 65MB text file that list what I have expected, part of it looks like this:

vmlinux: file format elf32-i386

Disassembly of section .text.head:

c0100000 <_text>:
*/
.section .text.head,"ax",@progbits
ENTRY(startup_32)
/* test KEEP_SEGMENTS flag to see if the bootloader is asking
us to not reload segments */
testb $(1<<6), BP_loadflags(%esi)
c0100000: f6 86 11 02 00 00 40 testb $0x40,0x211(%esi)
jnz 2f
c0100007: 75 14 jne c010001d <_text+0x1d>

and this:

c03453a0 :
*/
#ifdef CONFIG_X86_64
asmlinkage
#endif
void __kprobes do_page_fault(struct pt_regs *regs, unsigned long error_code)
{
c03453a0: 55 push %ebp
c03453a1: 89 e5 mov %esp,%ebp
c03453a3: 57 push %edi
c03453a4: 56 push %esi
c03453a5: 53 push %ebx
c03453a6: 83 ec 34 sub $0x34,%esp
c03453a9: e8 72 fe db ff call c0105220
c03453ae: 89 45 e4 mov %eax,-0x1c(%ebp)
c03453b1: 89 55 e0 mov %edx,-0x20(%ebp)

static inline unsigned long __raw_local_save_flags(void)
{
unsigned long f;

asm volatile(paravirt_alt(PV_SAVE_REGS
c03453b4: 51 push %ecx
c03453b5: 52 push %edx
c03453b6: ff 15 bc 78 43 c0 call *0xc04378bc
c03453bc: 5a pop %edx
c03453bd: 59 pop %ecx
* should be a rarely used function, only in places where its
* otherwise impossible to know the irq state, like in traps.
*/
static inline void trace_hardirqs_fixup_flags(unsigned long flags)
{
if (raw_irqs_disabled_flags(flags))
c03453be: f6 c4 02 test $0x2,%ah
c03453c1: 0f 85 ea 00 00 00 jne c03454b1
trace_hardirqs_off();
c03453c7: e8 d4 55 e3 ff call c017a9a0
c03453cc: 64 a1 00 70 4c c0 mov %fs:0xc04c7000,%eax
c03453d2: 89 45 e8 mov %eax,-0x18(%ebp)
* We can fault from pretty much anywhere, with unknown IRQ state.
*/
trace_hardirqs_fixup();

tsk = current;
mm = tsk->mm;
c03453d5: 8b 90 b0 00 00 00 mov 0xb0(%eax),%edx
c03453db: 89 d6 mov %edx,%esi
c03453dd: 89 55 ec mov %edx,-0x14(%ebp)
c03453e0: 83 c6 34 add $0x34,%esi
PVOP_VCALL1(pv_cpu_ops.write_cr0, x);
}

This much I have expected. But something even better that I tried after reading the website is the make .lst file actually works!
I did a:

make kernel/panic.lst

and here is part of the panic.lst that I get in return:

panic.o: file format elf32-i386

Disassembly of section .text:

c012c3e0 :
return 1;
}
__setup("panic=", panic_setup);

static long no_blink(long time)
{
c012c3e0: 55 push %ebp
c012c3e1: 89 e5 mov %esp,%ebp
c012c3e3: e8 fc ff ff ff call c012c3e4
c012c3e4: R_386_PC32 mcount
return 0;
}
c012c3e8: 5d pop %ebp
c012c3e9: 31 c0 xor %eax,%eax
c012c3eb: c3 ret
c012c3ec: 8d 74 26 00 lea 0x0(%esi),%esi

Floating Point

noreply@blogger.com (Wei Chong Tan) — Tue, 30 Sep 2008 18:36:11 PDT

Last night, out of boredom (because I had a swollen foot), I revised how floating point is represented in PC, using the IEEE Standard 754 format. To convince myself about what was read, I code this short code snippet:

/* This code is licensed under GPLv2 and above */
#include <stdio.h>

int main ()
{
/* Single Precision Float */
/* S Exponent Significant */
/* 0 1000_0000 [1]000_0000_0000_0000_0000_0000 */
/* Note that the Exponent is in Biased format, therefore,
1000_0000 - 0111_1111 (decimal 127) = 0000_0001 (decimal 2)
while the Significant is in Normalized format, which means the 1.bbbb is implied */
/* 0100_0000_0000_0000_0000_0000_0000_0000 */
/* Hex: 0x40000000 */

unsigned long int usi = 0x40000000;
signed long int si = usi;
float f = usi;

unsigned long int *uptr = &usi;
signed long int *sptr = &usi;
float *fptr = &usi;

printf("for 0x40000000\n");
printf("before assignment:\n");
printf("unsigned int = %lu, signed int = %ld, float = %f\n", *uptr, *sptr, *fptr);
printf("after assignment:\n");
printf("unsigned int = %lu, signed int = %ld, float = %f\n", usi, si, f);

return 0;
}

and the output from the execution is:

for 0x40000000
before assignment:
unsigned int = 1073741824, signed int = 1073741824, float = 2.000000
after assignment:
unsigned int = 1073741824, signed int = 1073741824, float = 1073741824.000000