This week I'm attending the Linux Plumbers Conference in Santa Rosa, CA. Yesterday I gave a brief presentation of the Firmware Test Suite in the Development Tools, and for reference, I've uploaded the slides here.Read more
UEFI variables in Linux can be found in /sys/firmware/efi/vars on UEFI firmware based machine, however, the raw variable data is in a binary format and hence not in a human readable form. The Ubuntu Natty firmware test suite contains the uefidump tool to extract and decode the binary data into a more human readable form.
To run, use:
I've been working away polishing up the Firmware Test Suite for Ubuntu Natty 11.04 and to complement the tool I have eventually got around to writing up a reference guide for the tool. The guide can be found at:
This complements the rather terse man page and ever terser fwts --help output.
I've now competed the documentation of the Firmware Test Suite and this include documenting each of the 50+ tests (which was a bit of a typing marathon). Each test has a brief description of what the test covers, example output from the test, how to run the test (possibly with different options) and explanations of test failure messages.
For example of the per-test documentation, check out the the suspend/resume test page and the ACPI tables test page.
I hope this is useful!
The Firmware Test Suite (fwts) is still a relatively new tool and hence this cycle I've still been adding some features and fixing bugs. I've been running fwts against large data sets to soak test the tool to catch a lot of stupid corner cases (e.g. broken ACPI tables). Also, I am focused on getting some better documentation written (this is still "work in progress").
New tests for the Oneiric 11.10 release are as follows:
Sanity check tables against the MultiProcessor Specification (MPS). For more information about MPS, see the wikipedia MPS page.
Dump annotated MPS tables.
Sanity check Model Specific Registers across all CPUs. Does some form of MSR default field sanity checking.
Very simple suspend (S3) power checks. This puts the machine into suspend and attempts to measure the power consumed while suspended. Generally this test gives more accurate results the longer one suspends the machine. Your mileage may vary on this test.
Hex dump of the Extended BIOS Data Area.
In addition to the above, the fwts "method" test is now expanded to evaluate and exercise over 90 ACPI objects and methods.
One can also join the fwts mailing list by going to the project page and subscribing.
The dwarves package contains a set of useful tools that use the DWARF information placed in the ELF binaries by the compiler. Utilities in the dwarves package include:
pahole: This will find alignment holes in structs and classes in languages such as C/C++. With careful repacking one can achieve better cache hits. I could have done with this when optimising some code a few years back...
codiff: This is a diff like tool use to compare the effect a change in source code can create on the compiled code.
pfunct: This displays information about functions, inlines, goto labels, function size, number of variables and much more.
pdwtags: A DWARF information pretty-printer.
pglobal: Dump out global symbols.
prefcnt: A DWARF tags usage count.
dtagnames: Will lists tag names.
So, using pglobal, I was able to quickly check which variables I had made global (or accidentally not made them static!) on some code that I was developing as follows:
pglobal -v progname
and the same for functions:
When I was a very junior software engineer working on Fortran 77 signal processing modules on MicroVaxes, PDP-11s, Masscomps and old 286 PCs I was given some very wise words by the owner of the company: "Assume nothing". This has stuck with me for nearly quarter of a century. It is pithy, easy to remember and is so true for software engineering.
1. "Assume nothing" makes me look up details when I'm not 100% sure.
2. "Assume nothing" means that I double check my facts when I think I'm 100% sure.
3. "Assume nothing" makes me question even the so called 'obvious'. "Of course it will work.." turns into "are we sure it will work for every possible case?"
4. "Assume nothing" makes me dot the i's and cross the t's.
5. "Assume nothing" keeps me sceptical, which is useful as there is a lot of stupidity masquerading as knowledge on the internet.
I could ramble on. However enough said. Just assume nothing, it will keep you out of a lot of trouble.
Here's a quick one-liner to find out which version of GCC was used to compile some code:
If you want know how fragmented a file is on an ext2/ext3/ext4 filesystem there are a couple of methods of finding out. One method is to use hdparm, but one needs CAP_SYS_RAWIO capability to do so, hence run with sudo:
sudo hdparm --fibmap /boot/initrd.img-2.6.38-9-generic
filesystem blocksize 4096, begins at LBA 24000512; assuming 512 byte sectors.
byte_offset begin_LBA end_LBA sectors
0 35747840 35764223 16384
8388608 39942144 39958527 16384
16777216 40954664 40957423 2760
Alternatively, one can use the filefrag utility (part of the e2fsprogs package) for reporting the number of extents:
/boot/initrd.img-2.6.38-9-generic: 3 extents found
..or more verbosely:
filefrag -v /boot/initrd.img-2.6.38-9-generic
Filesystem type is: ef53
File size of /boot/initrd.img-2.6.38-9-generic is 18189027 (4441 blocks, blocksize 4096)
ext logical physical expected length flags
0 0 1468416 2048
1 2048 1992704 1470463 2048
2 4096 2119269 1994751 345 eof
/boot/initrd.img-2.6.38-9-generic: 3 extents found
Well, that's useful. So, going one step further, how many free extents are available on the filesystem? Well, e2freefrag is the tool for this:
sudo e2freefrag /dev/sda1
Blocksize: 4096 bytes
Total blocks: 2999808
Free blocks: 1669815 (55.7%)
Min. free extent: 4 KB
Max. free extent: 1370924 KB
Avg. free extent: 6160 KB
Num. free extent: 1084
HISTOGRAM OF FREE EXTENT SIZES:
Extent Size Range : Free extents Free Blocks Percent
4K... 8K- : 450 450 0.03%
8K... 16K- : 97 227 0.01%
16K... 32K- : 99 527 0.03%
32K... 64K- : 134 1475 0.09%
64K... 128K- : 96 2193 0.13%
128K... 256K- : 50 2235 0.13%
256K... 512K- : 30 2643 0.16%
512K... 1024K- : 36 6523 0.39%
1M... 2M- : 36 13125 0.79%
2M... 4M- : 14 9197 0.55%
4M... 8M- : 15 18841 1.13%
8M... 16M- : 8 17515 1.05%
16M... 32M- : 7 38276 2.29%
32M... 64M- : 3 39409 2.36%
64M... 128M- : 3 67865 4.06%
512M... 1024M- : 4 802922 48.08%
1G... 2G- : 2 646392 38.71%
..thus reminding me to do some housekeeping and remove some junk from my file system... :-)
It just so happens that I have two Webcams on my machine, one being a rather poor one built into the laptop and a 2nd better quality Logitech webcam.
Using the 2nd webcam by default in Empathy for video conference calls required a little bit of hackery with gconf-editor by changing /system/gstreamer/0.10/default/videosrc from v4l2src to vl4l2src device="/dev/video1"
It appears that the semantics of halt mean it will stop the machine but it may or may not shut it down. Back when I used UNIX boxes, halt basically stopped the machine but never powered it down; to power it down one had to explicitly use "halt -p".
So things change. With upstart, halt is a symbolic link to reboot and reboot calls shutdown -h. The man page to shutdown states for the -h option:
"Requests that the system be either halted or powered off after it has been brought down, with the choice as to which left up to the system."
Hrm, so this vaguely explains why halting some machines may just halt and on others it may also shut the system down. I've not digged into this thoroughly yet, but one suspects that for different processor architectures we get different implementations. Even for x86 we have variations in CPUs and boards/platforms, so it really it is hard to say if halt will power down a machine.
The best bet is to assume halt just halts and if you want it to power down always use "halt -p".
The Linux PCI core driver provides a useful (and probably overlooked) sysfs interface to read PCI ROM resources. A PCI device that has a ROM resource will have a "rom" sysfs file associated with it, writing anything other than 0 to it will enable one to then read the ROM image from this file.
For example, on my laptop, to find PCI devices that have ROM images associated with them I used:
I don't want to start a vi vs emacs holy war, but I have found a wonderful binary editor based on the vi command set. The bvi editor is great for tweaking binary files - one can tab between the hex and ASCII representations of the binary data to re-edit the data.
To install use:
Dumping the contents of the Embedded Controller (EC) can be useful when debugging some x86 BIOS/kernel related issues. At a hardware level to get access to the EC memory one goes via the EC command/status and data port. As a side note, one can determine these ports as follows:
cat /proc/ioports | grep EC
The preferred way to access these is via the ACPI EC driver in drivers/acpi/ec.c which is used by the ACPI driver to handle read/write operations to the EC memory region.
In addition to this driver, there the ec_sys module that provides a useful debugfs interface to allow one to read + write to the EC memory. Write support is enabled with the ec_sys module parameter 'write_support' but it is generally discouraged as one may be poking data into memory may break things in an unpredictable manner, hence by default write support is disabled.
So, to dump the contents of the first EC (assuming debugfs is mounted), do:
SystemTap is a very useful and powerful tool that enables one to insert kernel debug into a running kernel. Today I wanted to inspect the I/O read/write operations occurring when running some ACPI AML, so it was a case of hacking up a few lines of system tap to dump out the relevant state (e.g. which port being accessed, width of the I/O operation in bits and value being written or read).
So instead of spinning a bespoke kernel with a few lines of debug in, I use SystemTap to quickly write a re-usable script. Simple and easy!
I've put the SystemTap script in my git repository for any who are interested.
The ACPI engine in the kernel can be debugged by building with CONFIG_ACPI_DEBUG and configuring /sys/module/acpi/parameters/debug_layer and /sys/module/acpi/parameters/debug_level appropriately. This can provide a wealth of data and is generally a very powerful debug state tracing mechanism. However, there are times when one wants to get a little more debug data out or perhaps just drill down on a specific core area of functionality without being swamped by too much ACPI debug. This is where tools like SystemTap are useful.
SystemTap is a very powerful tool that allows one to add extra debug instrumentation into a running kernel without the hassle and overhead of rebuilding a kernel with debug printk() statements in. It allows very quick turnaround in writing debug and one does not have to reboot a machine to load a new kernel since the debug is loaded and unloaded dynamically.
SystemTap has its own scripting language for writing debug scripts, but for specialised hackery it provides a mechanism ('guru mode') to embed C directly which can be called from the SystemTap script. The SystemTap language is fairly small and easy to understand and one easily becoming proficient with the language in a day.
The only downside is that one requires a .ddeb kernel package which is huge since it contains all the necessary kernel debug information.
Over the past week I have been looking at debugging various aspects of the ACPI core, such as fulling tracing suspend/resume and dumping out executed AML code at run time. I was able to quickly prototype a SystemTap script that dumps out AML opcodes on the Oneiric kernel - this saved me the usual build of a debug kernel with CONFIG_ACPI_DEBUG enabled and then capturing the appropriate debug and wading through copious amounts of debug data.
Conclusion: Some initial investment in time and effort is required to understand SystemTap (and to get to grips with the more useful features in 'guru mode'). However, one can be far more productive because the debug cycle is made far more efficient. Also, SystemTap provides plenty of functionality to allow very detailed and targeted debugging scripts.
Today we were trying to do some debugging by getting some tones out of a laptop speaker by frobbing bit 1 of port 0x61 on the keyboard controller. Rather unexpectedly I got no sound whatsoever out of the speaker, yet I had managed to do so the day before. So I double checked what had changed since the day before:
1. Was it because I upgraded my kernel?
2. Did I unexpected disabled the speaker when tweaking BIOS settings?
3. Was it something interfering with my port 0x61 bit twiddling?
4. Was the hardware now broken?
As per usual, I first assumed that the most complex parts of the system were to blame as they normally can go wrong in the most subtle way. After a lot of fiddling around I discovered that the PC speaker only worked when I plugged the AC power into the laptop. Now that wasn't obvious.
I suspect I should have applied Occam's Razor to this problem to begin with. We live and learn...
Back in February I wrote about turning off a PC using the Intel I/O Controller Hub and had some example code to do this, and it was a dirty hack. I've revised this code to be more aligned with how the Linux kernel does this, namely:
1. Cater for the possible existence of PM1b_EVT_BLK and PM1b_CNT_BLK registers.
2. Clear WAKE_STATUS before transitioning to S5
3. Instead of setting SLP_TYP and SLP_EN on, one sets SLP_TYPE and then finally sets SLP using separate writes.
The refined program requires 4 arguments, namely the port address of the PM1a_EVT_BLK, PM1b_EVT_BLK, PM1a_CNT_BLK and PM1b_CNT_BLK. If the PM1b_* ports are not defined, then these should be 0.
To find these ports run either:
Normally when I see a problem to do with CPU, I/O, network or memory resource hogging I turn to my trusty tools such as vmstat, iostate or ifstat to check system behaviour.
I stumbled upon dstat today, which boasts to be "a versatile replacement for vmstat, iostat and ifstat.". So let's see what it can do. First, install with:
© 2010 Canonical Ltd. Ubuntu and Canonical are registered trademarks of Canonical Ltd.