Wednesday, April 23, 2008

VirtualBox 1.5.6 with Linux Kernel 2.6.25

While compiling VirtualBox was successful, the loading failed with kernel message (seen using dmesg | tail -f):

release/bin/src ; USER=root ; COMMAND=/sbin/modprobe vboxdrv
Apr 23 22:20:16 linux-hp kernel: vboxdrv: Unknown symbol change_page_attr


With the introduction of the new API, no driver nor non-archcore code needs to use change_page_attr anymore. What I did was to grep for "change_page_attr" in VirtualBox source directory:

grep -R --include=*.? "change_page_attr"

And comment out all calls to this procedure. Loading the module then succeeded:

release/bin/src ; USER=root ; COMMAND=/sbin/modprobe vboxdrv
Apr 23 22:27:53 linux-hp kernel: vboxdrv: Trying to deactivate the NMI watchdog permanently...
Apr 23 22:27:53 linux-hp kernel: vboxdrv: Successfully done.
Apr 23 22:27:53 linux-hp kernel: vboxdrv: TSC mode is 'synchronous', kernel timer mode is 'normal'.
Apr 23 22:27:53 linux-hp kernel: vboxdrv: Successfully loaded version 1.5.6_OSE (interface 0x00050002).

Monday, April 21, 2008

Canon 4200F is still unsupported on Linux

lsusb -d 04a9:221b -vvv


lsusb -d 04a9:221b -vvv

Bus 007 Device 002: ID 04a9:221b Canon, Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 255 Vendor Specific Subclass
bDeviceProtocol 255 Vendor Specific Protocol
bMaxPacketSize0 64
idVendor 0x04a9 Canon, Inc.
idProduct 0x221b
bcdDevice 2.00
iManufacturer 3 Canon
iProduct 4 CanoScan
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 10mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 8
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 255 Vendor Specific Subclass
bDeviceProtocol 255 Vendor Specific Protocol
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0001
Self Powered

Creative XFi driver on Linux 2.6.25

There is still a problem with beta2 version of Creative Sound Blaster XFi driver on Linux kernel 2.6.25. If we do what is said by the driver installation instruction, it ends up with some errors. Here's a trick how to manually compile and install it:



  1. Download the driver from http://us.creative.com/support/downloads/download.asp?searchString=XFiDrv_Linux. or directly from shell: wget http://ccftp.creative.com/manualdn/Drivers/AVP/10530/0xE84AB36F/XFiDrv_Linux_US-1.18.tar.gz
    The latest is version 1.18

  2. Extract the tar.gz file from your build folder:

    tar zxvf XFiDrv_Linux_US-1.18.tar.gz

    This will extract all files to XFiDrv_Linux_US-1.18
  3. cd to the XFiDrv_Linux_US-1.18/drivers
  4. Try to do make (gotta be a root). It will cause some errors (the errors don't appear on the screen. They are logged in /var/log/creative-installer.log and need root access to see it). We can open another window/shell and just type: sudo tail -f /var/log/creative-installer.log to see what's going on.
  5. OK, now we're about to fix these problems. First, just typ: ./configure
  6. Don't do make yet. We need to modify some files.
  7. edit file LinuxSys.c: vi src/ossrv/LinuxSys.c
  8. Goto line 648 and replace SA_SHIRQ with IRQF_SHARED (Kernel 2.6.22 has told us that it was going to deprecate it although still defines it, but in kernel 2.6.25 this SA_SHIRQ is now gone!)
  9. Add the following line after line 33:


  10. #include <linux/fs.h> // for definitions of filp_*
  11. Add the following lines after line 37:

    #include <asm-generic/fcntl.h> // otherwise, some MACROS are undefined


  12. Compile with the following command: sudo make KBUILD_NOPEDANTIC=1 or modify (temporarily!) file /usr/src/linux/scripts/Makefile.build and comment out statements around line 46 as below:

  13.  #ifeq ($(KBUILD_NOPEDANTIC),)
    #ifneq ("$(save-cflags)","$(CFLAGS)")
    #$(error CFLAGS was changed in "$(kbuild-file)". Fix it to use EXTRA_CFLAGS)
    #endif

  14. Edit file in drivers/ctsound and change the order to:

    drivers="ctossrv emupia ctsfman haxfi ctalsa ct20xut ctexfifx cthwiut"

    #endif
  15. Install it: sudo make install

Saturday, April 19, 2008

Distributed Compile and Caching

This trick has boosted my compilation several times faster now. Here is the steps:

  1. First, you need to install both ccache and icecream (search on the Internet!). The default place for icecream files are under /opt/icecream.
  2. Create a folder /opt/ccache and /opt/ccache/bin
  3. Create file named "gcc" and type:
  4. #! /bin/sh
    export CCACHE_PATH=/opt/icecream/bin
    export PATH=/opt/icecream/bin:/usr/bin:$PATH
    ccache gcc "$@"
  5. Repeat step 3 and 4, but change line "ccache gcc" to "ccache c++" and name the file c++.
  6. Do the same thing (step 5) for cc abd g++
  7. Modify path (I put this in my ~/.profile): export PATH=/opt/ccache/bin:$PATH


To start icecream, as root do this: /etc/init.d/icecream restart
This will start the icecc daemon (iceccd). Here is my processes:

> ps -ef | grep ice
icecream 3944 1 0 19:33 ? 00:00:03 /usr/sbin/scheduler -d -l /var/log/icecc_scheduler -n icecream -vv
root 3957 1 0 19:33 ? 00:00:06 /usr/sbin/iceccd -d -l /var/log/iceccd --nice 5 -s linux-hp -n icecream -u icecream -b /var/cache/icecream -vv


(Modify file /etc/sysconfig/icecream as you needed (especially the scheduler and netname). I still not able to make my other computer to participate in the parallel compile (it is separated by a wireless router but in the same IP subnet). I don't know the root cause yet (the log said it was not able to find the scheduler, although I explicitly specify it [not thru broadcast]).

NVIDIA driver on Linux Kernel 2.6.25

The current Nvidia driver (NVIDIA-Linux-x86_64-169.12-pkg2.run) is somehow broken with Linux kernel 2.6.25. I googled and found discussion about this. Some people suggested to replace EXPORT_UNUSED_SYMBOL(init_mm) to EXPORT_SYMBOL(init_mm) in
/usr/src/linux/arch/x86/kernel/init_task.c. It didn't work (at least on my machine).

I look at the error log in /var/log/nvidia-installer.log. The last few lines in the file told me the global_flush_tlb() was implicitly declared (meaning, it was no longer exported by the Linux kernel. People in the discussion forum mentioned since 2.6.24 or something) while trying to compile nv-vm.c. This look weird, so I extracted the Nvidia driver with the following command:

sh download/nvidia/NVIDIA-Linux-x86_64-169.12-pkg2.run -a -q -n -x

This command extracted both binary files and its source codes onto NVIDIA-Linux-x86_64-169.12-pkg2/
I then cd to NVIDIA-Linux-x86_64-169.12-pkg2/usr/src/nv and commented out calling to that procedure. Here's my modified procedure of that file:

static void nv_flush_caches(void)
{
#if defined(KERNEL_2_4)
// for 2.4 kernels, just automatically flush the caches and invalidate tlbs
nv_execute_on_all_cpus(cache_flush, NULL);
#else
// for 2.6 (and later) kernels, rely on global_flush_tlb
#if defined(NV_CPA_NEEDS_FLUSHING)
nv_execute_on_all_cpus(cache_flush, NULL);
#endif
#if defined (NVCPU_X86) || defined (NVCPU_X86_64)
//global_flush_tlb();
#endif
nv_ext_flush_caches(); // handle other platform flushes if present
#endif
}

I then manually compile the code usual way (make module) from that folder and did "make install" (executed as root). For the binary files, I just manually copied them to their proper places.

Nervously, I typed "startx" and voila....my Xwindows started successfuly! So far, I haven't noticed any anomalies nor problems (this blog is actually done from my machine running the new driver). Apparently, the latest kernel doesn't require flushing cache anymore (it must be done automatically elsewhere).