My HTC Desire has been a wonderful phone whcih I've had for a little over a year without mishap ... until last night (Thu 6.00pm) when it fell into the toilet. At least it had been flushed beforehand, so it was clean water.
Before going anything else, I took off the cover, took out the battery, took out the sim, took out the memory card, and stuck it in a container of rice overnight, and prayed.
This morning (Fri 7:00am, 13 hours later) I tried it. It seemed ok with a small hint of some capacitive loss.
One hour later on the way to work, I tried it again. Oh. Quite a lot of capacitive loss, requiring very heavy touches and swipes. Not good.
So it's now apart again and hopefully continuing to dry out in a dry air conditioned room.
Hint - make sure you do up the zip when putting it back in it's belt pouch.
Further updates to come ... all is not lost ... yet.
Fri 4:40pm (23 hours after the event): My latest test results on the phone are promising after giving it more time to dry in an air conditioned room. But it's too early to be 100% conclusive as I only had it on for a few minutes. I'll give it another day to dry out.
Mon 9:00am (3.5 days after the event): Turned it on for the first time in 2.5 days this morning. All appears to be ok. I'll now treat is "normally" and see how it goes. It's currently on charge (a low charge rate via a laptop usb port).
Tue 9:00am: All still ok.
[18-July-2011] 1.5 months later - all is well.
[20-July-2012] 13.5 months later - all is well apart from the camera which has lost it's clarity and focussing ability (which for all I know could be unrelated to the water incident).
[26-April-2013] All is still well.
[9-October-2013] All is still well.
Thursday, June 2, 2011
Wednesday, April 27, 2011
KGH: NO ACCESS
Finally there is information on the KGH: NO ACCESS shared pool component appearing on BLOGs and at Oracle Support.
- KGH: NO ACCESS – Buffer cache inside streams pool too! | www.oaktable.net
- ORA-04031 AND ASMM
- KGH: NO ACCESS allocations in V$SGASTAT – buffer cache within shared pool!
- ORA-04031 in 11g & 11gR2, Excess "KGH: NO ACCESS" Memory Allocation [ID 1127833.1]
- Common Cause for ORA-4031 in 10gR2, Excess "KGH: NO ACCESS" Memory Allocation [Video] [ID 801787.1]
Friday, April 15, 2011
Monday, August 23, 2010
Oracle Block Remastering
Here's good arcticle on dynamic remastering.
Remasting Technique
Remastering granularity
- Oracle 10g-11g. Block range (128 blocks in a range)
Queries:
select kj.*, le.le_Addr from ( select kjblname, kjblname2, kjblowner, kjblmaster, kjbllockp, substr ( kjblname2, instr(kjblname2,',')+1, instr(kjblname2,',',1,2)-instr(kjblname2,',',1,1)-1)/65536 fl, substr ( kjblname2, 1, instr(kjblname2,',')-1) blk from x$kjbl ) kj, x$le le where le.le_kjbl = kj.kjbllockp order by le.le_addr /
select * from x$object_affinity_statistics
/
select * from v$gcspfmaster_info
/
- With object remastering feature, if an object is accessed by an instance aggressively, then that instance will become the master of the object reducing gc remote grants improving performance of the application. In the prior sentence, I used the word “accessed”, but it is a loose term, and the correct term is if the instance is requesting much BL locks on an object, then that object can be remastered.
- Instance GRD is frozen during reconfiguration and in a very busy instances, this can take many seconds leading to instance freeze for several seconds.
Internal Parameters
- _gc_affinity_limit - the number of "opens" before an object is considered for remastering (defaults to 50)
- _gc_affinity_time - how often the queue is checked for remastering (defaults to 10 minutes)
- _gc_affinity_minimum - minimum amount of dynamic affinity activity per minute to be a candidate for remastering (defaults to 600/minute/cpu)
- _gc_undo_affinity - controls whether dynamic undo remastering is enabled
Evidence of remastering performance problems
- Wait events: "gcs drm freeze", "gc remaster", "gcs freeze"
- Log entries at the same time "DRM start"
Wednesday, July 14, 2010
Facebook Defaults
I thought when I first joined facebook that the default privacy rules were quite good. Look again now (2010-07-14) I see that they are not very private at all. So what "should" they be, especially for kids? Here's a great article. Basically, almost everything should be "Friends Only".
Tuesday, June 1, 2010
Oracle Clusterware Failures: Useful Logs
To determine why a node failed, try the following clusterware logs (in order of usefulness):
- alert log
- ocssd log
- evm log
Oracle Clusterware Parameters: misscount, disktimeout, reboottime
Clusterware timeout parameters:
- misscount - It represents maximum time in seconds that, a heartbeat can be missed before entering into a cluster reconfiguration to evict the node.
- disktimeout - It is the maximum amount of time allowed for a voting file I/O to complete; if this time is exceeded the voting disk will be marked as offline.
- reboottime - It is the amount of time allowed for a node to complete a reboot after the CSS daemon has been evicted.
- misscount = 60 seconds
- disktimeout = 200 seconds
- reboottime = 3 seconds
- crsctl get css misscount ---------- to check misscount value
- crsctl get css disktimeout --------- to check disktimeout value
- crsctl get css reboottime ---------- to check reboottime value
- crsctl set css misscount 120 --------- to set misscount to 120 seconds
- crsctl set css disktimeout 200 ------- to set disktimeout to 200 seconds
- crsctl set css reboottime 3 ----------- to set reboottime to 3 seconds
lssnmNMInitialize: misscount set to (30) clssnmNMInitialize: Network heartbeat thresholds are: impending reconfig 15000 ms, reconfig start (misscount) 30000 ms clssgmInitCMInfo: Wait for remote node termination set to 13 seconds clssnmNMInitialize: misscount set to (60), impending reconfig threshold set to (56000) clssnmNMInitialize: diskShortTimeout set to (57000)ms clssnmNMInitialize: diskLongTimeout set to (200000)ms clssnmHandleUpdate: diskTimeout set to (200000)ms
Subscribe to:
Posts (Atom)
