Posts Tagged ‘linux’

Boot Ubuntu from RAID

May 13th, 2016 No comments

I had lately setup RAID 5 (three 2TB disks) with i7 6700 + ASUS H170 MoBo + 32GB DDR4 RAM followed by installing Ubuntu 16.04 x64 on it.  The installation went very well with Kernel 4.4.0-21.  But, upon restart the installation was unable to move ahead as the Kernel was not able to read from the RAID device.

Basically, the issue is that the install kernel didn’t have the RAID drivers embedded within.  Upon digging for few hours, found one solution at , which didn’t work as is.  The following modification worked:

  1. Boot from Live DVD image, which would load the RAID drivers automatically allowing you to see the device correctly.
  2. Now mount the root partition. (say /mnt/root-partition)
  3. Edit /mnt/root-partition/etc/initramfs-tools/modules for adding drivers that should get embedded into Initialization RAM drive file System (initrd).
  4. Add the following list at the end of the modules file.  The list is generated using “lsmod|grep raid” during the live DVD session.
    1. dm_raid
  5. Run “mkinitramfs -r /mnt/root-partition -o /mnt/root-partition/boot/initrd.img-4.4.0-21-generic”
  6. Reboot the machine to see that RAID is being detected.
  7. Install dmraid (apt-get install dmraid), which would again fix the initrd image with necessary stuff.
  8. Now, my machine works smooth.

If nothing worked, get a small HDD to install the OS in it.  While booting the OS, you may load the drivers via /etc/rc.local and dmraid commands to activate the RAID device and mount it for use.

Sony UWA-BR100

October 27th, 2012 2 comments
    Today, I purchased the WiFi adapter for Sony 32EX650 LED TV, which is exclusively built for the Sony HD LED TV with USB connectivity.  When I tried plugging that in my Windows 7 x64 PC, the device was not recognized as there was no Windows driver, but the device showed up as CEWL-1.  While discussing about that with my wife, I had to take the brickbats for wasting the money, while we already have wifi access from the available devices.  Now, I had to prove that my investment is worth, but I have no clue how to. 

    Started my search for unofficial drivers for the device in Linux and Windows, following that gracefully landed at, which said that the device is indeed Atheros chipset based and detectable in Linux as ath9k_htc and moreover they had also provided a free download link for getting the all-windows driver.

    Now, I have installed the windows driver and the wifi device works like a breeze.  I have been testing it against B/G wifi network, so the speed I am seeing is 54Mbps.  I will try this again with A/N/B/G to check whether it goes to higher speeds as claimed in the website.  Interestingly, Windows 8 would support these devices out of the box as per this Sony support page.

Update: I have tested the device against a A/N/B/G router in the 5Ghz spectrum and found that the device is connected at 300Mbps speed 🙂  And, indeed it is using the ath9k_htc driver supplied via compat-wireless package.

Hash Overflow due to 64 bit upcasting

October 28th, 2011 No comments
    Lately, I had to debug the following piece of code, where it caused overflow on the hash bucket design.  The code worked perfectly on a Windows machine while compiled for Win32, but failed to work on a Linux Mint x64 machine.  The code is listed below, which basically calculates hash value of an input 32 bit unsigned number, limiting the hash value to 2^10 (1Meg).

hash = ( fpArray*2654404609 )>>12; // Calculate the hash and limit the value to 2^20 (1 Meg)

   When the input value for fpArray was 1724463449 (0x66C93959), the hash value generated was 1779068547 (0x6A0A6E83), which is more than (0x000FFFFF) to cause the hash bucket overflow.

unsigned hash = fpArray * 2654404609;
hash = hash >> 12;

    When I rewrote the code like the above, the value of hash was 2800236889 (0xA6E83959).  Upon shifting right by 12 yields 638651 (0x0009BEBB), which is the correct and expected hash value.

    Overall, the first snippet of code appears to be correct.  Do you see a problem there?  I couldn’t find the issue, until I recalled the 32bit vs 64bit difference.  If you carefully look at the multiplier 2654404609 (0x9E370001), although appears to be a valid 32 bit number, what is the default assignment of type to this number by the compiler?  If it was assigned 64bits, what would happen to the results?  To validate this, I changed the 2nd snippet as the following.

unsigned long hash = (unsigned long)fpArray * 2654404609;
hash = hash >> 12;
unsigned h2 = (unsigned)hash;

    Now, when the input is the same 1724463449 (0x66C93959), the value of hash becomes 4577423727077636441 (0x3F8646A0A6E83959) and upon right shifting by 12 bits yields 1117535089618563 (0x0003F8646A0A6E83). Followed by downcasting to unsigned yield 1779068547 (0x6A0A6E83). Bingo!

    So, what is happening here? While performing (fpArray * 2654404609), the computation is upcasted to 64bit computation by the 64 bit compiler.  So, what is the solution? Just put a “U” at the end of the constant.

hash = ( fpArray*2654404609U )>>12; // Calculate the hash and limit the value to 2^20 (1 Meg)
const unsigned multipler = 2654404609; // here U suffix is not needed as the constant is explicitly made unsigned
hash = ( fpArray * multiplier ) >> 12;

    Now, the computation will happen with 32 bit numbers to get the expected outputs.

Lessons Learned here:

  1. While using constants, beware of the upcasting and downcasting. So use proper suffixes like U, L, F etc.
  2. Instead of using constants directly in expressions, use them as constant variables.
  3. Be conscious about the compiler type and the assumptions made by the compiler in different build modes.

PROXIM ORINOCO 802.11 a/b/g/n

June 30th, 2011 No comments

Did you try this page for the driver?

Procedure for setting up proxim driver is given here:-

If you want to try an alternate device, use this list linux compatible devices:-

How to on Wireless networking:-

If there is a windows driver, you can use “ndiswrapper” to setup a Linux module atop the windows driver sys and inf files. Try this as well.

Greeter Application appears to be crashing. Attempting to use a different one.

July 17th, 2008 No comments

Before the login screen appears in Fedora, you may get a popup saying
“Greeter Application appears to be crashing. Attempting to use a
different one”. You may think, this could be due to video driver fault.
In most of the cases, it is because your root directory “/” is 100%
full. When you free you space in the “/” drive, the problem goes away.