Thursday, January 3, 2013

Android Settings Reset Using ADB

I'm going to try updating my blog with all the random hacks I seem to end up doing.

I run CM10.1 nightly (Android 4.2.1) on my Galaxy SII and decided to mess with some of the developer options. After enabling "Simulate secondary displays" my phone locked up. So I reboot and it locks up again during boot... sigh...

Now there are lots of ways to recover from this in a brute force manner (reinstall the ROM, do a factory reset, etc), but I decided to try reverting the specific option using ADB.

First I installed the Android SDK to get access to ADB, then rebooted my phone into CWM recovery (hold volume-up, home and power). After CWM recovery booted I mounted the "/system" and "/data" filesystems from the menu. After this I tried running ADB on my PC, which gave:

C:\adt-bundle-windows-x86_64\sdk\platform-tools>adb shell
error: device not found

Crap! It can't find my phone. A few minutes of sanity checking revealed that I didn't have the proper Samsung USB Drivers installed (SAMSUNG_USB_Driver_for_Mobile_Phones.exe). After installing them I could finally get access to the ADB shell of my phone:

C:\adt-bundle-windows-x86_64\sdk\platform-tools>adb shell
shell@android:/ $

Now to figure out what I need to change, and how to change it. Luckily Android and Cyanogenmod are both open source, and a quick search of the code for "Simulate secondary displays" located this:
<string name="overlay_display_devices_title">Simulate secondary displays</string>
private static final String OVERLAY_DISPLAY_DEVICES_KEY = "overlay_display_devices";
String value = Settings.Global.getString(getActivity().getContentResolver(), Settings.Global.OVERLAY_DISPLAY_DEVICES);

So the "overlay_display_devices" global setting is the culprit! After a bit of searching I found that android simply stores all settings in the "" sqlite database. So resetting it should be pretty trivial. First I confirmed that I can actually see the value, and that it makes sense..

C:\adt-bundle-windows-x86_64\sdk\platform-tools>adb shell
shell@android:/ $ sqlite3 /data/data/
SQLite version 3.7.11 2012-03-20 11:35:50
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> select * from global where name="overlay_display_devices";

Okay, that looks sane! So hopefully just deleting that row and rebooting should work..

sqlite> delete from global where name="overlay_display_devices";
sqlite> select * from global where name="overlay_display_devices";

And... The setting is gone! And my phone boots into android again! Success!

Thursday, October 14, 2010

Dell Precision 690 Power Usage

I recently got an old P690 workstation for home and have been a little curious about its power consumption. They don't seem like very energy efficient systems so I borrowed a watt meter and took some measurements in various states.

The specs for the machine I'm testing:
Dell Precision 690 (750W PSU)
2x Intel Xeon 5160 @ 3.00ghz
ATI FirePro V3700
4gb FB-DIMM (2x1gb, 4x512mb)
Windows 7 Ultimate X64 (fully up-to-date)

And here are the results (note that "low power mode" was enabled, and wake-on-lan was disabled in the BIOS):

Power off: 22w
Power on/idle: 198w
Power on/prime95(small fft):  312w
S3 Sleep: 22w

The power on usage is around what I'd expect, but the off/sleep usage is a little high. I've heard FB-DIMMs are quite power hungry, so let's try removing some and testing with 2x1gb, also I decided to test S1 sleep too:
Power off: 22w
Power on/idle: 162w
Power on/prime95(small fft): 275w
S1 Sleep: 178w
S3 Sleep: 22w

So power on usage has dropped by around 35watts, that's quite a lot of power for 2gb of ram! But what's this? S1 sleep actually consumes more power than normal power-on mode... Maybe speedstep isn't used when in S1 sleep mode? Maybe there's a bug in the BIOS? Who knows, but it seems like a useless sleep state.

Well there you go, not too many shockers, but at least all this explains why the RAM gets so damn hot :P

Saturday, December 12, 2009

DebConf issues on OpenSolaris

So, with new system calls added to lx-brand it's possible to run an up-to-date Debian in an OpenSolaris zone, but apt will not work correctly due to the following error:
  debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Bad file descriptor

Doing a bit of investigation it appears to be failing because Debconf tries to acquire an exclusive lock on a read only file descriptor, apparently this is fine to do on a Linux machine but OpenSolaris doesn't allow it. The offending code is in /usr/share/perl5/Debconf/DbDriver/ (version 1.5.28):
  51: if (! open ($this->{_fh}, $this->{filename})) {
  57: while (! flock($this->{_fh}, LOCK_EX | LOCK_NB)) {

Some tutorials suggest just removing the lock code as a solution. This actually allows debconf to work but may cause weird issues if running multiple debconf utilities at the same time.
Nexenta also modifies the debconf code, but instead of removing the lock code it changes it to a shared lock.

Another possible fix is to simply make DebConf open the file descriptor with with write access, this is what I'm currently using and it seems to be the safest method since it allows acquisition of an exclusive lock even on OpenSolaris.
  51: if (! open ($this->{_fh}, "+<", $this->{filename})) {

I'm not sure if it's worth changing the lx_brand code to emulate this specific behaviour, hacking the debconf code is easy enough and seems to work fine.

Saturday, August 29, 2009

Debian squeeze in a solaris BrandZ zone!

I wanted to run some debian squeeze programs on my opensolaris machine in a branded zone but after successfully installing it using some guide I found online I noticed that lots of commands fail due to functions not being implemented!

unconfigured:~# touch foo
unconfigured:~# rm foo
rm: cannot remove `foo': Function not implemented

Oh noes! How come rm isn't implemented, that's pretty basic right?

unconfigured:~# strace rm foo 2>&1 | grep -i "not implemented"
unlinkat(AT_FDCWD, "foo", 0) = -1 ENOSYS (Function not implemented)

Ah, what's this? unlinkat? I bet lx-brand doesn't implement this syscall since it's so new or maybe there's some switch to enable it? But how does this BrandZ voodoo magic work anyway? Turns out the emulation itself is done in userland by one library (/usr/lib/, and after some digging I came across {"unlinkat", NULL, NOSYS_NULL, 0} in some code which pretty much confirms that unlinkat and the other *at functions aren't implemented at all!
Well damn, this sucks, maybe I'll recompile squeeze libraries and programs so that they don't use these syscalls and thus work with BrandZ, but that sounds tedious and not very fun... so clearly it's time to hack some new syscalls into lx-brand!
But how the hell do you compile onnv-gate code anyway? It seems to use a very odd build system which is designed for build robots rather than humans! Well luckily there are other crazy people on the internet who have already found out how, is a very nice tutorial on how to do it and it works great, just instead of going to usr/src/uts goto usr/src/lib/brand/lx/lx_brand!

So a few hours of hacking and reading posix standards later I now have a /usr/lib/ which implements openat(), mkdirat(), mknodat(), fchownat(), futimesat(), fstatat64(), unlinkat(), renameat(), linkat(), symlinkat(), readlinkat(), fchmodat() and faccessat() resulting in a working debian squeeze userland, although there are still a few issues like the debconf flock issue mentioned in the etch-zone tutorial and some syscalls still fail but seem to be innocuous...
Also I'm sure the syscalls implemented aren't fully compatible with the proper linux versions and I'm sure there are lots of error conditions that will freak out user mode programs... but for now it works well enough to run debian squeeze which was the goal!

If you're interested in trying out what I've done you can download my patch and a pre-built library (built against the b118 onnv-gate source, since that's what I happened to be running at the time) from my website, and if you do try it out please let me know how it goes! Although be warned that it's super experimental and not recommended for production systems, I highly recommend you take snapshots before proceeding!

[2009-12-17 Update] The patch has been integrated: e8c975bf2038 should be in snv131 and above

PSN Portable ID