[Linux] JME micron, UDP checksum error

The Shuttle XS35 GTv2 box has a JME micron Ethernet card that tends to spam the syslog with checksum errors.

This solved it: ethtool -K eth0 rx off
Replace "eth0" with your network card's identifier.

Solution found here: Fedora Forums

Android: "Damaged SD card", how i lost my data but reclaimed my SD card (needs root)

Firstly: If you have this problem, contact your retailer or service point!

The story/instructions below are totally unsupported and requires expert knowledge!

My SD card was "damaged" according to Android (4.0.4) running on a HTC Desire S.
Mounting it from the Android menus didn't work at all. Since I didn't care about the data on the SD card I tried to reformat it from Linux but failed. This is how I managed to get the card to work again (though with my data LOST).

The instructions below erases ALL data on our SD card. I am not responsible for loss of data or any other damage to your Phone or SD card!


My phone was using a pre-rooted version of Android with busybox installed, and this is considered a requirement to do the steps below.


* Connect your phone to your computer using Android Debug Bridge (adb) from the Android SDK
* Find out which volume that is representing our SD card by starting logcat (adb logcat) and look at the screen printout while clicking on "Mount SD card" in the "Storage" menu on your Android phone. On mine it was /dev/block/vold/179:65
* Start an adb shell, (adb shell)
* Run fsck on your disk: fsck_msdos /dev/block/vold/179\:65
* Fsck will probably report errors, mine reported exit code 8. If fsck asks if it can try to repair you could try that, it didn't work for me though.
* If the fsck repair failed we are now sure that the card is not possible to rescue. Let's reformat.
* Still in the adb shell, run: mkfs.vfat /dev/block/vold/179\:65 (replace the device name with the name corresponding to your device from previous steps)
* mkfs doesn't output anything if it completed successfully. To make sure our volume/disk/card is OK we run fsck_msdos again fsck_msdos /dev/block/vold/179\:65
* fsck_msdos should report no errors
* Trying to remount the card again in Android should now hopefully work: Settings->Storage->Mount SD card

Again: These steps will erase your SD card completely and all your data will be LOST! I am not responsible for any data loss or damaged cards/phones! The methods above are totally unsupported and if in doubt, contact your retailer or service point!

Linux: Gnome 3.4, Nvidia. Fix tearing in fullscreen Flash

Add this line CLUTTER_PAINT=disable-clipped-redraws:disable-culling to the file /etc/environment
Restart your session and you should now be able to was Flash videos in full screen tear and lag free.

Bug is registered here:
https://bugzilla.gnome.org/show_bug.cgi?id=657071
https://bugzilla.redhat.com/show_bug.cgi?id=720605

Linux: Flash 11.2, Nvidia. Blue tint

If the Flash video on Youtube has a blue tint while using hardware acceleration, do the following.

Add the line EnableLinuxHWVideoDecode=1  to the file /etc/adobe/mms.cfg


This will fix the blue tint on Youtube and will probably lead to instability (crashes) on other sites.
To fully solve this a patched libvdpau is needed.

For Arch Linux you find it prepared here:http://aur.archlinux.org/packages.php?ID=59181
For ubuntu there doesn't seems to exist a fix for now: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/968489

Note that this a error in Flash and not VDPAU.

Android: Copying SD cards

Switching SD cards in your phone and copying the contents of the old to the new one can cause trouble if permissions aren't right. This usually happens if your "middle man"  is not using FAT file system. This is how I solved it (note; using 775 permissions can cause security issues!).

* Mount the SD card on a Linux machine through our phone or using a card reader.
* Copy the contents of the SD card to a temporary location on your machine
* Set permissions (recursively) to 775 (rwxrwxr-x) on the contents (chmod -R 775 /tmp/sdcard)
* Unmount SD card and mount the new one
* Copy the contents from the machine to the new SD card
* Unmount the SD card

Couple of tips:
* Don't switch SD cards while Android is running, especially not if you have apps or app data on the SD card
* ClockworkMod can mount the SD card as USB storage
* If you have CWM backups, try and open the "Restore" after the copy procedure. If your backups are listed your SD card is most probably good to use
* Again, don't switch SD cards when Android is running

Following these steps a 2GB card was successfully replaced with a 16GB without any application issues.

I am not responsible for any loss of data or damaged SD cards or phones.

[Linux]Logitech DiNovo Edge

The Logitech DiNovo Edge Bluetooth adapter can be used in two different modes.

Device mode

In this mode the keyboard and its adapter behaves like a USB-keyboard (and mouse). This mode requires no installation and is the preferred mode for non-experts. It is also the default mode of the keyboard on most operating systems.

Raw mode
In this mode the Bluetooth adapter appears as a Bluetooth adapter. This requires installation of the keyboard through Bluetooth pairing by the user. It also enabled the user to connect other devices through the adapters such as phones, headsets etc. As it requires additional configuration to get the keyboard up and running, it is not recommended for non-experienced users.

Linux
On current Linux (3.x), the mode of the Bluetooth adapter is controlled by udev and its rules in rules.d. These rules can be found in the following path /lib/udev/rules.d/ and the the related file including the rule/configuration for Logitech devices can be found in the following file (depending on the Bluetooth driver installed):
Arch Linux (Bluez): yx-bluetooth-hid2hci.rules 
Ubuntu 11.10: yx-bluez-hid2hic.rules (x & y = [0-9])

In the above file there is a couple of lines used to identify a Logitech device upon connected to the system. These lines looks something like this on most systems (Arch Linux showed):

# Logitech devices
KERNEL=="hidraw*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c70[345abce]|c71[34bc]", \
  RUN+="hid2hci --method=logitech-hid --devpath=%p"

This snippet shows that udev is told to register a device matching the product number for Logitech DiNovo (mine is C714) as a raw device(see above for definition) on the system.
If you, as administrator, change the string saying "hidraw" to "hiddev", and save the changes, the device will be registered as a device the next time it is connected (reboot or unplug/plugin).
Note! Since you haven't paired the keyboard and adapter the keyboard will appear as "non-functional", changing to device mode requires some kind of alternative input device (USB-keyboard, on-screen keyboard etc.) until you have  paired the keyboard with the Bluetooth adapter using your Bluetooth manager (gnome, blueman, hcitool etc.).

System upgrade etc.
It has been noted, several times, that a system upgrade some times overwrites your udev rules and restores them to whatever state your system has as default. Hence, the change to the udev rules described above might be necessary to perform more than once during your system's lifetime.

Also, a lot of users are reporting there DiNovo keyboard as non-functional in forum threads all over the Internet. This is however not totally true. What they are experiencing is probably that their adapter has switched mode (from whatever they had before). They could probably fix this by editing their Bluetooth udev rule, as mentioned above, to the inverse of what they currently have.

Related info
https://bugs.launchpad.net/ubuntu/+source/udev/+bug/872940


Update
After an upgrade of my system (Arch Linux) udev does not detect the USB adapter as a Bluetooth adapter even though the rules are set as above. But I found a solution for this:
* Unplug the USB adapter
* Hold the connect button while inserting the USB adapter again and do not release it until, in Gnome, the Bluetooth icon appears in the indicator panel.
If you are not using bluetooth-applet (or equivalent) then tailing the system log (ex. /var/log/messages) could be an alternative way of verifying that the adapter is identified.