HKCU\Software\Microsoft\Shell\NeverDorkMemory - General Topics

Just create a empty key:
HKCU\Software\Microsoft\Shell\NeverDorkMemory
kinda realtime memory defragmenter
Cheers
Edit 22 april 2006: it became clear that this setting locked the memory slider in place for pre wm2005 os. You also might be interested in this tweak: AutoOOM
I want to thank everybody who helped clearing this out.
Cheers and keep your minds open for new things ;O)

what does it do?

As I understand it maybe it is defragmenter for your ram memory, and it will make a little speed gain

NeverDorkMemory? Google shows it in two places, here, and some chinese site. What evidence do you have that it works?
Sounds a little fake ;D

If no progress ever was made we will still be running around naked with a lot of hair on our body....
Don't judge something you realy haven't got a clue about.

From hairy bodies...
back to the subject..
What does this Acctualy do?

what does it do?
thanks in advance

OK, but you asked for it ;O)
It controls your SystemMemoryDivision (fragmentation)
This is what it does:
...........
.text:00017AC8 BL GlobalMemStatus
.text:00017ACC LDR R1, Software\\Microsoft\\Shell\\NeverDorkMemory
.text:00017AD0 ADD R3, SP, #0x78+var_68
.text:00017AD4 STR R3, [SP,#0x78+var_78]
.text:00017AD8 MOV R2, #0
.text:00017ADC MOV R3, #1
.text:00017AE0 MOV R0, #0x80000001 (hkcu)
.text:00017AE4 BL RegOpenKeyExW
.text:00017AE8 CMP R0, #0
.text:00017AEC BEQ loc_17B0C
.text:00017AF0 ADD R0, SP, #0x78+var_44
.text:00017AF4 BL sub_176AC
.text:00017AF8 CMP R0, #0
.text:00017AFC BEQ loc_17B14
.text:00017B00 ADD R0, SP, #0x78+var_44
.text:00017B04 BL GlobalMemoryStatus
.text:00017B08 B loc_17B14
.......
sub_176AC ; CODE XREF: sub_17A88+6Cp
.text:000176AC
.text:000176AC var_3C = -0x3C
.text:000176AC var_38 = -0x38
.text:000176AC var_34 = -0x34
.text:000176AC var_2C = -0x2C
.text:000176AC var_28 = -0x28
.text:000176AC
.text:000176AC STMFD SP!, {R4-R11,LR}
.text:000176B0 SUB SP, SP, #0x18
.text:000176B4 MOV R4, R0
.text:000176B8 MOV R11, #0
.text:000176BC ADD R0, SP, #0x3C+var_2C
.text:000176C0 MOV R10, R11
.text:000176C4 BL GetStoreInformation
.text:000176C8 LDR R9, [SP,#0x3C+var_28]
.text:000176CC LDR R3, [R4,#0xC]
.text:000176D0 ADD R0, R9, R9,LSL#2
.text:000176D4 CMP R0, R3
.text:000176D8 BCC loc_176E8
.text:000176DC ADD R0, R3, R3,LSL#2
.text:000176E0 CMP R0, R9
.text:000176E4 BCS loc_177DC
.text:000176E8
.text:000176E8 loc_176E8 ; CODE XREF: sub_176AC+2Cj
.text:000176E8 ADD R2, SP, #0x3C+var_34
.text:000176EC ADD R1, SP, #0x3C+var_38
.text:000176F0 ADD R0, SP, #0x3C+var_3C
.text:000176F4 BL GetSystemMemoryDivision
.text:000176F8 LDR R0, [SP,#0x3C+var_38]
.text:000176FC LDR R2, =__rt_udiv
.text:00017700 LDR R6, [SP,#0x3C+var_3C]
.text:00017704 LDR R8, [SP,#0x3C+var_34]
.text:00017708 ADD R7, R6, R0
.text:0001770C LDR R1, [SP,#0x3C+var_28]
.text:00017710 LDR R3, [R2]
.text:00017714 MOV R0, R8
.text:00017718 MOV LR, PC
.text:0001771C MOV PC, R3
.text:00017720 LDR R2, =__rt_udiv
.text:00017724 MOV R9, R0
.text:00017728 LDR R1, [R4,#0xC]
.text:0001772C LDR R3, [R2]
.text:00017730 MOV R0, R8
.text:00017734 STR R9, [SP,#0x3C+var_28]
.text:00017738 MOV LR, PC
.text:0001773C MOV PC, R3
.text:00017740 LDR R2, =__rt_udiv
.text:00017744 STR R0, [R4,#0xC]
.text:00017748 ADD R0, R0, R9
.text:0001774C MOV R1, R0,LSR#1
.text:00017750 LDR R3, [R2]
.text:00017754 SUB R5, R1, R9
.text:00017758 MOVS R4, R5
.text:0001775C MOV R1, #0x7D000
.text:00017760 MOV R0, R8
.text:00017764 RSBMI R4, R4, #0
.text:00017768 MOV LR, PC
.text:0001776C MOV PC, R3
.text:00017770 CMP R4, R0
.text:00017774 BLE loc_177DC
.text:00017778 LDR R2, =__rt_udiv
.text:0001777C ADD R5, R6, R5
.text:00017780 MOV R1, #0x200000
.text:00017784 STR R5, [SP,#0x3C+var_3C]
.text:00017788 LDR R3, [R2]
.text:0001778C MOV R0, R8
.text:00017790 SUB R4, R7, R5
.text:00017794 MOV LR, PC
.text:00017798 MOV PC, R3
.text:0001779C CMP R4, R0
.text:000177A0 BCC loc_177DC
.text:000177A4 MOV R0, R5
.text:000177A8 BL SetSystemMemoryDivision
.text:000177AC CMP R0, #0
.text:000177B0 BNE loc_177D4
.text:000177B4 MOV R10, #1
.text:000177B8
.text:000177B8 loc_177B8 ; CODE XREF: sub_176AC+134j
.text:000177B8 LDR R2, =unk_401DC
.text:000177BC LDR R0, [R2]
.text:000177C0 BIC R1, R0, #0x10000
.text:000177C4 STR R1, [R2]
.text:000177C8
.text:000177C8 loc_177C8 ; CODE XREF: sub_176AC+158j
.text:000177C8 ; sub_176AC+190j ...
.text:000177C8 MOV R0, R10
.text:000177CC ADD SP, SP, #0x18
.text:000177D0 LDMFD SP!, {R4-R11,PC}
.text:000177D4 ; ---------------------------------------------------------------------------
.text:000177D4
.text:000177D4 loc_177D4 ; CODE XREF: sub_176AC+104j
.text:000177D4 LDR R9, [SP,#0x3C+var_28]
.text:000177D8 MOV R10, R11
.text:000177DC
.text:000177DC loc_177DC ; CODE XREF: sub_176AC+38j
.text:000177DC ; sub_176AC+C8j ...
.text:000177DC CMP R9, #loc_14000
.text:000177E0 BCS loc_177B8
.text:000177E4 LDR R1, =unk_401DC
.text:000177E8 LDR R0, [R1]
.text:000177EC TST R0, #loc_20000
.text:000177F0 BNE loc_17840
.text:000177F4 LDRH R0, [R1,#2]
.text:000177F8 MOV R1, R0,LSL#16
.text:000177FC MOV R2, R1,LSR#16
.text:00017800 TST R2, #1
.text:00017804 BNE loc_177C8
.text:00017808 MOV R0, #0xFF00
.text:0001780C MOV R3, #0
.text:00017810 MOV R2, #0
.text:00017814 MOV R1, #0x1F
.text:00017818 ORR R0, R0, #0xFB
.text:0001781C BL PostMessageW
.text:00017820 LDR R0, =unk_3FF1C
.text:00017824 MOV R1, #0x460
.text:00017828 LDR R0, [R0]
.text:0001782C MOV R3, #0
.text:00017830 MOV R2, #0
.text:00017834 ORR R1, R1, #0xC
.text:00017838 BL PostMessageW
.text:0001783C B loc_177C8
.text:00017840 ; ---------------------------------------------------------------------------
.text:00017840
.text:00017840 loc_17840 ; CODE XREF: sub_176AC+144j
.text:00017840 ORR R0, R0, #0x10000
.text:00017844 STR R0, [R1]
.text:00017848 B loc_177C8
.text:00017848 ; End of function sub_176AC
.text:00017848

Nice,,, you can do cut & paste.
please we are all visiting this site to share info and to get the best out of our PPC's.
every one who visited your subject asked a simple question and yet no asnswer that make sense "to me at least".

Take a look at the boards title: Developers.
That you cannot read my reply is not my problem.
Discussion closed.

tweakradje said:
Discussion closed.
Click to expand...
Click to collapse

And give the Dword Dec:1?
Nadav.

tweakradje
If only we were all of equal ability.
No teachers, no pupils, nothing more to learn.
Not for me though !

tweakradje said:
OK, but you asked for it ;O)
It controls your SystemMemoryDivision (fragmentation)
This is what it does:
...........
.text:00017AC8 BL GlobalMemStatus
.text:00017ACC LDR R1, Software\\Microsoft\\Shell\\NeverDorkMemory
<snip>
.text:00017848 ; End of function sub_176AC
.text:00017848
Click to expand...
Click to collapse
Makes an interesting read, although the lack of comments makes it tricky reading, as does the lack of documentation of the stack-frame. Given that you have not provided such information I would assume you do not know, this is reinforced by the fact the say 'This is what is does' and then simply list the assembly rather than a pseudo-code overview - perhaps somebody else has paralleled your research and would be in a better position to provide information on its behaviour?
Meanwhile I'll assume you are still in the exploritory phase of your research and wait for a firmer conclusion - thanks for sharing however.
-sf

I use this KEY (not a dword value guys, please read first post) for over a year now withoiut any bad side effects. I have 55 MB memory free (hard reset) and after the usual apps and data still about 35 Megs free. So I can hardly tell if it is of any use. Perhaps you guys with a lotta less memory free can tell us more here about the effects of the key.
So please share your findings. That gives resluts. I you don't wanna test fine, If you do even better.
Cheers
PS: get yourself a registry monitor for CE and you wil find yourself some interesting keys/values.

Which Registry Monitor have you used?

CeRegSpy

Tweak, I think the problem is your lack of providing anything to the poeple here besides a key and a VERY generic explination.
But, to show that even a rude person giving a tweak is a tweak, I am testing it now.
Mem free: 23 before reg hack
Mem free: 24.6 after reg entry
I loaded fresh from soft reboot... opened my reg program and added the entry. Then I checked memory.
I rebooted from soft boot and opened program, followed steps down to where it was, then exited. So there was a jump in ram by 1.6 meg. Thats a successful tweak if you ask me.

Also, I'm not losing my memory when using some programs and closing them. For example, a session with egress would make me lose 3 or 4 meg after closing the prog. It seems that I come back to the same ram value everytime now. must be testing longer to confirm.

boboki said:
Tweak, I think the problem is your lack of providing anything to the poeple here besides a key and a VERY generic explination.
But, to show that even a rude person giving a tweak is a tweak, I am testing it now.
Click to expand...
Click to collapse
I am a technical guy. Communicating is not my strongest point (call it rude or whatever). I think my attitude towards innovation and tweaking is more solid and thus I am not afraid to test anything if it seems feasable or likely. I cannot speak for others. There are too many of them ;O)
Take the information as you wanna take it. Use it or not. I only wanna share and carry on with my life. A lot of things still have to be discovered or understood. Life is too short you know..
Cheers

Related

Revolutionary study, the last etude s5k3bafx

I start this again if a cooker wanna test the new values
Sorry for the title I just love Chopin
Sick of contacting the I-mate support team with no help, and no reply from HTC and Samsung, Microsoft is telling me to contact HTC, so again to the same circle.
I want to share my last idea about prophet before I do the last decision I made.
I always thought that is the low frame rate in prophet camera is because the DMA so if someone help me in this please.
I think the functions related to this issue are (aCamreaDMA and CameraInterface) and it could be fixed or at least improved debugging the file s5k3bafx.dll that contains the functions for the Samsung chip.
Code:
.text:10002018 ; ---------------------------------------------------------------------------
.text:10002018 CMP R4, #1
.text:1000201C BNE loc_100020C0
.text:10002020 LDR R3, =aCameradma
.text:10002024 MOV R2, #0
.text:10002028 MOV R1, #0
.text:1000202C MOV R0, #0
.text:10002030 BL CreateEventW
.text:10002034 ; ---------------------------------------------------------------------------
.text:10002034 CMP R0, #0
.text:10002038 STR R0, [R5,#0x10]
.text:1000203C BEQ loc_10002070
.text:10002040 MOV R1, #2
.text:10002044 BL EventModify
.text:10002048 ; ---------------------------------------------------------------------------
.text:10002048 LDR R1, [R5,#0x10]
.text:1000204C MOV R3, #0
.text:10002050 MOV R2, #0
.text:10002054 MOV R0, #0x1F
.text:10002058 BL InterruptInitialize
.text:1000205C ; ---------------------------------------------------------------------------
.text:1000205C CMP R0, #1
.text:10002060 BNE loc_10002070
.text:10002064 MOV R0, #0x1F
.text:10002068 BL InterruptDone
.text:1000206C ; ---------------------------------------------------------------------------
.text:1000206C MOV R6, #1
.text:10002070
.text:10002070 loc_10002070 ; CODE XREF: .text:1000203Cj
.text:10002070 ; .text:10002060j
.text:10002070 LDR R3, =aCamerainterfac
.text:10002074 MOV R2, #0
.text:10002078 MOV R1, #0
.text:1000207C MOV R0, #0
.text:10002080 BL CreateEventW
.text:10002084 ; ---------------------------------------------------------------------------
.text:10002084 CMP R0, #0
.text:10002088 STR R0, [R5,#0x50]
.text:1000208C BEQ loc_10002108
.text:10002090 MOV R1, #2
.text:10002094 BL EventModify
.text:10002098 ; ---------------------------------------------------------------------------
.text:10002098 LDR R1, [R5,#0x50]
.text:1000209C MOV R3, #0
.text:100020A0 MOV R2, #0
.text:100020A4 MOV R0, #0x2B
.text:100020A8 BL InterruptInitialize
.text:100020AC ; ---------------------------------------------------------------------------
.text:100020AC CMP R0, #1
.text:100020B0 BNE loc_10002108
.text:100020B4 MOV R0, #0x2B
.text:100020B8 BL InterruptDone
.text:100020BC ; ---------------------------------------------------------------------------
.text:100020BC B loc_10002104
.text:100020C0 ; ---------------------------------------------------------------------------
.text:100020C0
.text:100020C0 loc_100020C0 ; CODE XREF: .text:1000201Cj
.text:100020C0 LDR R3, [R5,#0x10]
.text:100020C4 MOV R4, #0
.text:100020C8 CMP R3, #0
.text:100020CC BEQ loc_100020DC
.text:100020D0 MOV R0, R3
.text:100020D4 BL CloseHandle
.text:100020D8 ; ---------------------------------------------------------------------------
.text:100020D8 STR R4, [R5,#0x10]
.text:100020DC
.text:100020DC loc_100020DC ; CODE XREF: .text:100020CCj
.text:100020DC MOV R0, #0x1F
.text:100020E0 BL InterruptDisable
.text:100020E4 ; ---------------------------------------------------------------------------
.text:100020E4 LDR R3, [R5,#0x50]
.text:100020E8 CMP R3, #0
.text:100020EC BEQ loc_100020FC
.text:100020F0 MOV R0, R3
.text:100020F4 BL CloseHandle
.text:100020F8 ; ---------------------------------------------------------------------------
.text:100020F8 STR R4, [R5,#0x50]
.text:100020FC
.text:100020FC loc_100020FC ; CODE XREF: .text:100020ECj
.text:100020FC MOV R0, #0x2B
.text:10002100 BL InterruptDisable
.text:10002104 ; ---------------------------------------------------------------------------
.text:10002104
.text:10002104 loc_10002104 ; CODE XREF: .text:100020BCj
.text:10002104 MOV R6, #1
.text:10002108
.text:10002108 loc_10002108 ; CODE XREF: .text:1000208Cj
.text:10002108 ; .text:100020B0j
.text:10002108 MOV R0, #0
.text:1000210C BL SetKMode
.text:10002110 ; ---------------------------------------------------------------------------
.text:10002110 MOV R0, R6
.text:10002114 LDMFD SP!, {R4-R6,LR}
.text:10002118 BX LR
.text:10002118 ; ---------------------------------------------------------------------------
.text:1000211C off_1000211C DCD aCamerainterfac ; DATA XREF: .text:loc_10002070r
.text:1000211C ; "CameraInterface"
.text:10002120 off_10002120 DCD aCameradma ; DATA XREF: .text:10002020r
.text:10002120 ; "CameraDMA"
I think if we change the constant value at loc text:10002038 and text:10002088 and all related values (0x10, 0x50 to R5; register will be load to memory) will improve the DMA transfer from the camera chip to the device RAM, and will load less CPU make it faster.
Please help in this, how to improve the S5K3BAFX.dll driver and DMA compatibility with HTC prophet.
For ROM cookers:
The hex values need to be changed from (10 to 2C, 50 to 88) in the module S5K3BAFX.dll.
Version 2.15, the file need to be modify S000 the offsets are: 1050, 1060, 10A0, 10B0, 10D8, 10F0, 10FC, 1110.
Version 2.20 (the module in the AKU2.2 I'll attach it as it provide better picture but can't over clock the CPU) the offsets in S000 are: 1038, 1048, 1088, 1098, 10C0, 10D8, 10E4, 10F8.
I'm not sure about the 2C and 88 values, if someone can help to improve the camera DMA.
is there anything i can try to modify?

[dev] camera fix

Some fixes:
- dmesg
Code:
<6>[ 1.044134] pmem_camera: 1 init
- mem
Code:
static struct android_pmem_platform_data pmem_camera_pdata = {
.name = "pmem_camera",
.no_allocator = 0,
//cardsharing
// .cached = 0,
.cached = 1,
};
no more physical address error, but somethink is not ok with jpegtask
Code:
<6>[ 194.591656] pmem: successful request for physical address of pmem region id 1, offset 650190848, len 524288
<6>[ 194.591716] pmem: successful request for physical address of pmem region id 2, offset 661762048, len 6721536
<6>[ 194.612419] adsp_open() name = 'JPEGTASK'
<6>[ 194.612514] adsp: opening module JPEGTASK
<6>[ 194.613648] adsp: module JPEGTASK has been registered
<6>[ 194.613674] adsp_open() module 'JPEGTASK' adev e4978e84
<6>[ 194.613708] msm_adsp_enable() 'JPEGTASK'state[0] id[42]
<6>[ 194.614464] adsp: rpc event=0, proc_id=2, module=42, image=0
<6>[ 194.614748] adsp: module JPEGTASK: READY
<6>[ 194.615379] pmem: successful request for physical address of pmem region id 1, offset 649142272, len 4096
<6>[ 194.615554] pmem: successful request for physical address of pmem region id 1, offset 649146368, len 4096
<6>[ 194.615603] adsp_pmem_add module JPEGTASK vaddr:0x41168000 paddr:0x26b12000 len:4096
<6>[ 194.615633] adsp_pmem_add module JPEGTASK vaddr:0x4116c000 paddr:0x26b13000 len:4096
<6>[ 194.615801] adsp_pmem_add module JPEGTASK vaddr:0x41ffc000 paddr:0x26c12000 len:524288
<3>[ 194.615836] module JPEGTASK: verify failed.
maybe you have idea!
I think problem with: camera (jpeg), youtube (high def video) , but all working (output way), but not working (input way), is becouse we have something wrong with user space (maybe problem with permisions!), or maybe need corection for memory mapping!
I've tried to fix cammera, and I know bug is inside when camera catcing picture from jpeg task (input way not working, but output way working). Also, I know when youtube catching "high def video" (input way), something is not ok with "codecs" or "user space" or "memmory map"... maybe you have idea?
I think fixing cam bug will fix all (youtube...etc)
EDIT:
See this:
Code:
<6>[ 194.615801] adsp_pmem_add module JPEGTASK vaddr:0x41ffc000 paddr:0x26c12000 len:524288
Why len is 524288? Picture have size > 3-4M, maybe it cause problem with jpegtask verify??
about video and youtube problem in codecs
about camera problem in memory map
I think problem is in msm_adsp.h, adsp.c, adsp.h and adsp_photon.c
something is not ok there (I think wrong in adsp_photon.c != msm_adsp.h!) becouse I see in dmesg from int adsp_video_verify_cmd() warning about "unknown video queue"... from code:
Code:
int adsp_video_verify_cmd(struct msm_adsp_module *module,
unsigned int queue_id, void *cmd_data,
size_t cmd_size)
{
switch (queue_id) {
case QDSP_mpuVDecPktQueue:
DLOG("\n");
return verify_vdec_pkt_cmd(module, cmd_data, cmd_size);
default:
printk(KERN_INFO "unknown video queue %u\n", queue_id);
return 0;
}
}
and from it I know QDSP_mpuVDecPktQueue is not used, so I think we have problem in adsp_photon.c and need to realign it like defined in msm_adsp.h!!!
I dumped something, maybe help here:
Code:
<4>[ 0.972350] adsp: module name=AUDPLAY0TASK, module id=2, mod clk=<NULL>, verify cmd=0, patch event=0, pdev name=adsp_AUDPLAY0TASK, pdev id=-1, id_to_module=e4979000
<4>[ 0.972588] adsp: module name=AUDPPTASK, module id=7, mod clk=<NULL>, verify cmd=0, patch event=0, pdev name=adsp_AUDPPTASK, pdev id=-1, id_to_module=e4979148
<4>[ 0.972741] adsp: module name=AUDRECTASK, module id=19, mod clk=<NULL>, verify cmd=0, patch event=0, pdev name=adsp_AUDRECTASK, pdev id=-1, id_to_module=e4979290
<4>[ 0.972886] adsp: module name=AUDPREPROCTASK, module id=20, mod clk=<NULL>, verify cmd=0, patch event=0, pdev name=adsp_AUDPREPROCTASK, pdev id=-1, id_to_module=e49793d8
<4>[ 0.973040] adsp: module name=VFETASK, module id=31, mod clk=vfe_clk, verify cmd=c0143330, patch event=c01437f4, pdev name=adsp_VFETASK, pdev id=-1, id_to_module=e4979520
<4>[ 0.973183] adsp: module name=QCAMTASK, module id=43, mod clk=<NULL>, verify cmd=0, patch event=0, pdev name=adsp_QCAMTASK, pdev id=-1, id_to_module=e4979668
<4>[ 0.973330] adsp: module name=JPEGTASK, module id=42, mod clk=vdc_clk, verify cmd=c0142f0c, patch event=c01432d4, pdev name=adsp_JPEGTASK, pdev id=-1, id_to_module=e49797b0
<4>[ 0.973568] adsp: module name=VIDEOTASK, module id=9, mod clk=vdc_clk, verify cmd=c01429c0, patch event=0, pdev name=adsp_VIDEOTASK, pdev id=-1, id_to_module=e49798f8
<4>[ 0.973713] adsp: module name=VDEC_LP_MODE, module id=48, mod clk=<NULL>, verify cmd=0, patch event=0, pdev name=adsp_VDEC_LP_MODE, pdev id=-1, id_to_module=e4979a40
<4>[ 0.973901] adsp: module name=VIDEOENCTASK, module id=30, mod clk=vdc_clk, verify cmd=c0142bd8, patch event=0, pdev name=adsp_VIDEOENCTASK, pdev id=-1, id_to_module=e4979b88
And yes, cammera jpegtask have problem with memory map, but video have problem in adsp!
may be ,video with another player with codecs work good
http://gitorious.org/linux-on-qualcomm-s-msm/linux-msm/blobs/htc-msm-2.6.27/arch/arm/mach-msm/pmem.c
this file had camera pmem calc
i think this is help with with
NOTE: need edits in devices_htc.c/.h
NOTE2: Camera Snapshot work only in Fast Burst Camera
Ok I will try! Please see this -> http://forum.xda-developers.com/showpost.php?p=16448252&postcount=4
camera
Hi !
sorry for my English, but someone has a solution for a problem with camera in hd mini ? I try the android r134 FANTASTIC, but no photos some one can help me?
tanks
No reason do make doubbleposts.
As you can see in this thread, they are working on it.
Its still "under construction"
something interesting from strace
Code:
writev(3, [{"\4", 1}, {"GPhoto\0", 7}, {"Sd-card availableSize = 5673\0", 29}], 3) = 37
syscall_983042(0x43904738, 0x4390473c, 0, 0x4390473c, 0xaca8c3f4, 0x438f70cf, 0x434, 0xf0002, 0, 0x40041858, 0xcd80, 0xbe9e4700, 0, 0xbe9e43f0, 0xaca64fc7, 0xafd0ec8c, 0x8000010, 0x43904738, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0
Code:
recv(52740, 0x80, 4294966774, MSG_WAITALL|MSG_TRUNC|MSG_DONTWAIT|MSG_PROBE|MSG_FIN|MSG_NOSIGNAL|0xbe9e0000) = -1 ETIMEDOUT (Connection timed out)
TIMEDOUT !! I don't know where is timedout, hmmm FUTEX??? Also I seen in dmesg always diferent size in bank_1 but it's defined static !!
this adress 0xbe9e0000 don't responding
I found something! Curently error come from msm_camera.c (see dmesg.log) "msm_put_stats_buffer: NULL physical address"!!!
Two functions:
first:
Code:
static int msm_put_stats_buffer(struct msm_sync *sync, void __user *arg)
{
int rc = -EIO;
struct msm_stats_buf buf;
unsigned long pphy;
struct msm_vfe_cfg_cmd cfgcmd;
if (copy_from_user(&buf, arg,
sizeof(struct msm_stats_buf))) {
ERR_COPY_FROM_USER();
return -EFAULT;
}
CDBG("%s\n", __func__);
pphy = msm_pmem_stats_vtop_lookup(sync, buf.buffer, buf.fd);
if (pphy != 0) {
if (buf.type == STAT_AEAW)
cfgcmd.cmd_type = CMD_STATS_BUF_RELEASE;
else if (buf.type == STAT_AF)
cfgcmd.cmd_type = CMD_STATS_AF_BUF_RELEASE;
else {
pr_err("%s: invalid buf type %d\n",
__func__,
buf.type);
rc = -EINVAL;
goto put_done;
}
cfgcmd.value = (void *)&buf;
if (sync->vfefn.vfe_config) {
rc = sync->vfefn.vfe_config(&cfgcmd, &pphy);
if (rc < 0)
pr_err("%s: vfe_config error %d\n",
__func__, rc);
} else
pr_err("%s: vfe_config is NULL\n", __func__);
} else {
pr_err("%s: NULL physical address\n", __func__);
rc = -EINVAL;
}
put_done:
return rc;
}
In second function I added (see dmesg.log!) printk, and I see vaddr and buffer addr sometimes is ===, sometimes !== so it need to be fixed but hmmm where??? I not have idea , maybe you have idea:
Code:
static unsigned long msm_pmem_stats_vtop_lookup(
struct msm_sync *sync,
unsigned long buffer,
int fd)
{
struct msm_pmem_region *region;
struct hlist_node *node, *n;
hlist_for_each_entry_safe(region, node, n, &sync->pmem_stats, list) {
printk("ADSP TEST: region->info.vaddr(0x%08lx)==(0x%08lx)buffer, region->info.fd(%d)==(%d)fd, region->info.vfe_can_write(%d)==0\n",
((unsigned long)(region->info.vaddr)), buffer, region->info.fd, fd, region->info.vfe_can_write);
if (((unsigned long)(region->info.vaddr) == buffer) &&
(region->info.fd == fd) &&
region->info.vfe_can_write == 0) {
region->info.vfe_can_write = 1;
return region->paddr;
}
}
return 0;
}
As you see some memory regions is not writeable becouse region->info.vaddr !== buffer
i don't think so
i think problem in s5k4e1gx.c
Code:
{ /*Snapshot*/
0x06, /* pre_pll_clk_div REG=0x0305 */
0x00, /* pll_multiplier_msb REG=0x0306 */
0x50, /* pll_multiplier_lsb REG=0x0307 */
0x00, /* vt_sys_clk_div REG=0x30B5 */
0xB0, /* DPHY_bandctrl REG=0x30F1 */
0x00, /* read_mode REG=0x0101 */
0x0A, /* x_output_size_msb REG=0x034C */
0x30, /* x_output_size_lsb REG=0x034D */
0x07, /* y_output_size_msb REG=0x034E */
0xA8, /* y_output_size_lsb REG=0x034F */
0x01, /* x_even_inc REG=0x0381 */
0x01, /* x_odd_inc REG=0x0383 */
0x01, /* y_even_inc REG=0x0385 */
0x01, /* y_odd_inc REG=0x0387 */
0x03, /* h_binning REG=0x30A9 */
0xE8, /* v_binning REG=0x300E */
0x07, /* frame_length_lines_msb REG=0x0340 */
0xB4, /* frame_length_lines_lsb REG=0x0341 */
0x0A, /* line_length_pck_msb REG=0x0342 */
0xB2, /* line_length_pck_lsb REG=0x0343 */
0x10, /* pclk_inv; REG=0x3110 */
0x0C, /* pclk_delay; REG=0x3117 */
0x0A, /* v_h_strength; REG=0x3119 */
0xAA, /* data_pclk_strength; REG=0x311A */
0x82, /* cds_test REG=0x300F */
0xC0, /* rst_offset1 REG=0x3013 */
0xA4, /* rmp_init REG=0x3017 */ /*0x94*/
0x88, /* comp_bias REG=0x301B */ /*0x71*/
0x00, /* analogue_gain_code_global_msb REG=0x0204 */
0x80, /* analogue_gain_code_global_lsb REG=0x0205 */
0x07, /* coarse_integration_time_msb REG=0x0202 */
0xA8, /* coarse_intergation_time_lsb REG=0x0203 */
1960, /* size_h */
12, /* blk_l*/
2608, /* size_w*/
130 /* blk_p*/
}
};
or may be
static int msm_divert_snapshot(struct msm_sync *sync,
in msm_camera
Ok maybe! But as you see region->info.vaddr !== buffer ...some offsets differs there and I don't know what cause it or where I need to search Maybe haret not cleaned completely some memory regions?
i try to research diffs in leo kernel
only find time fix
Maked some tests and I confirm we have problem in queue_id and it need to be fixed in photon_adsp.c or msm_adsp.h... see dmesg with latest kernel from munjeni release thread... I tried video and camera and got "adsp_video_verify_cmd: unknown video queue 4" and in jpeg_verify "-1" !!! So one queue step fail or maybe array of the queues (or array of the module offsets) in adsp_photon.c or msm_adsp.h need to be realigned! I think it cause audio loop and video freze in youtube becouse wrong queue (wrong module used), allso cause problem in video capture! With new memory map I got youtube to "not freze" but could not stop audio and no high def video... please see commit http://gitorious.org/2-6-32-photon/testing/commit/e3121b4083068760fc33a277e10c049a4054840d you will see QDSP_uPJpegActionCmdQueue is not used!
i think value for camera 22 - 23
because logcat have error with 22 ioctl
QDSP_uPJpegActionCmdQueue with 22 value you can find in leo source msm_adsp
Maybe asking help from Cianogen to support our phone becouse it's related to rpc and we not have that knownledge, it is hard to fix without .pdf specification for our phone!
problem with resolution, in fast burst camera with large buffer and 1280x760 all good in android camera problem with buffer ,
the first what can be a problem : auto-focus wrong offset
the second : buffer with very high resolution too large and pmem don't have needed size
the third : problem with ioctl

Acer Liquid Metal questions about the

Hello;I want my phone to enter recovery mode (volume down-camera-power combination) three times before trying to continuous vibration after vibration and gives the following error is coming
osbl versiyon:a4.03.32.01 #0 #0 #0 #0
"sd image download proceduro... failed! image_dir_not_found"
Thank you for your help

[Help] Bootloader Exception

Bootloader exception
[ RST_STAT = 0x10000000 ]
EVT 1.0
ASV TBL VER 8, Grade = C
ECT : PARA005i
LOT_ID = NA46A
CHIP_ID = 02b62e48b99c
CHIP_ID2 = 00000000
MNGS:40'C APOLLO:40'C G3D:40'C ISP:41'C
Exception: do_handler_serror: SERROR(esr: 0xbf000000) 'a WB }
pc : 0x8f0132cc [r : 0x8f022 dbc sp : 0x8f10fe90 @
@ _
I've tried going into download mode but it isn't working.
Please Help!!
The computer doesn't recognize it either.. if anyone has any info please help me!

Debugging LibStageFright Woes - Disabling MiniJail/SECCOMP

I'm having problems debugging libstagefright.
Code:
#6 0xe6c9c740 in vpx_codec_decode () from target:/system/lib/libstagefright_soft_vpxdec.so
#7 0xe6c98f74 in android::SoftVPX::onQueueFilled(unsigned int) () from target:/system/lib/libstagefright_soft_vpxdec.so
#8 0xe88570f2 in android::SimpleSoftOMXComponent::onMessageReceived(android::sp<android::AMessage> const&) () from target:/system/lib/libstagefright_omx.so
#9 0xe885813e in android::AHandlerReflector<android::SimpleSoftOMXComponent>::onMessageReceived(android::sp<android::AMessage> const&) ()
from target:/system/lib/libstagefright_omx.so
#10 0xe8d24556 in android::AHandler::deliverMessage(android::sp<android::AMessage> const&) () from target:/system/lib/libstagefright_foundation.so
#11 0xe8d26a6a in android::AMessage::deliver() () from target:/system/lib/libstagefright_foundation.so
#12 0xe8d251d2 in android::ALooper::loop() () from target:/system/lib/libstagefright_foundation.so
#13 0xe83592b4 in android::Thread::_threadLoop(void*) () from target:/system/lib/libutils.so
#14 0xe8694812 in __pthread_start(void*) () from target:/system/lib/libc.so
#15 0xe866736a in __start_thread () from target:/system/lib/libc.so
#16 0x00000000 in ?? () from target:/system/vendor/bin/hw/[email protected]
I can debug code up until I get to android::SoftVPX:: onQueueFilled, once the call to vpx_codec_decode() is made, and I step, I get this error:
Thread 12 received signal SIGSYS, Bad system call.
It would appear to be due to this syscall made inside of __pthread_cond_timedwait():
Code:
Thread 13 (Thread 2656.12953):
#0 0xe8664e50 in syscall () from target:/system/lib/libc.so
#1 0xe86941a6 in __pthread_cond_timedwait(pthread_cond_internal_t*, pthread_mutex_t*, bool, timespec const*) () from target:/system/lib/libc.so
#2 0xe884cc58 in android::eek:MXNodeInstance::CallbackDispatcher::loop() () from target:/system/lib/libstagefright_omx.so
#3 0xe884cd04 in android::eek:MXNodeInstance::CallbackDispatcherThread::threadLoop() () from target:/system/lib/libstagefright_omx.so
#4 0xe8359236 in android::Thread::_threadLoop(void*) () from target:/system/lib/libutils.so
#5 0xe8694812 in __pthread_start(void*) () from target:/system/lib/libc.so
#6 0xe866736a in __start_thread () from target:/system/lib/libc.so
#7 0x00000000 in ?? () from target:/system/vendor/bin/hw/[email protected]
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Code:
(gdb) disas __pthread_cond_timedwait
...........
0xe86941a0 <+100>: movs r0, #240 ; 0xf0
0xe86941a2 <+102>: blx 0xe8661478 <[email protected]>
Syscall #240 appears to be the futex syscall (correct me if I'm wrong)...I added that to the media.codec seccomp profile file on the file system, along with a load of other syscalls, but it still doesn't work and I'm stuck, I don't know what to do as I need to be able to step through the code and it just errors out.
Any ideas on how to disable minijail/seccomp or add the correct syscall number so it doesn't bale once it enters vpx_codec_decode() from android::SoftVPX:: onQueueFilled?
Sorry to bump this, but here's some more output:
Code:
Thread 11 hit Breakpoint 1, 0xf1298e3e in android::SoftVPX:: onQueueFilled(unsigned int) () from target:/system/lib/libstagefright_soft_vpxdec.so
(gdb) c
Continuing.
Thread 11 hit Breakpoint 2, 0xf1298f6c in android::SoftVPX:: onQueueFilled(unsigned int) () from target:/system/lib/libstagefright_soft_vpxdec.so
(gdb) si
0xf1298f70 in android::SoftVPX::onQueueFilled(unsigned int) () from target:/system/lib/libstagefright_soft_vpxdec.so
(gdb) disas
0xf1298f6c <+320>: add.w r1, r12, lr
=> 0xf1298f70 <+324>: blx 0xf1297614 <[email protected]>
0xf1298f74 <+328>: mov r3, r0
0xf1298f76 <+330>: cmp r3, #0
0xf1298f78 <+332>: bne.n 0xf1298ffc <_ZN7android7SoftVPX13onQueueFilledEj+464>
0xf1298f7a <+334>: strb.w r11, [r10, #4]
(gdb) si
Thread 11 received signal SIGSYS, Bad system call.
0xf1297618 in [email protected] () from target:/system/lib/libstagefright_soft_vpxdec.so
As soon as I step into [email protected] I get that bad syscall error. I just don't really understand what the hell is going on.
int80 said:
Sorry to bump this, but here's some more output:
Code:
Thread 11 hit Breakpoint 1, 0xf1298e3e in android::SoftVPX:: onQueueFilled(unsigned int) () from target:/system/lib/libstagefright_soft_vpxdec.so
(gdb) c
Continuing.
Thread 11 hit Breakpoint 2, 0xf1298f6c in android::SoftVPX:: onQueueFilled(unsigned int) () from target:/system/lib/libstagefright_soft_vpxdec.so
(gdb) si
0xf1298f70 in android::SoftVPX::onQueueFilled(unsigned int) () from target:/system/lib/libstagefright_soft_vpxdec.so
(gdb) disas
0xf1298f6c <+320>: add.w r1, r12, lr
=> 0xf1298f70 <+324>: blx 0xf1297614 <[email protected]>
0xf1298f74 <+328>: mov r3, r0
0xf1298f76 <+330>: cmp r3, #0
0xf1298f78 <+332>: bne.n 0xf1298ffc <_ZN7android7SoftVPX13onQueueFilledEj+464>
0xf1298f7a <+334>: strb.w r11, [r10, #4]
(gdb) si
Thread 11 received signal SIGSYS, Bad system call.
0xf1297618 in [email protected] () from target:/system/lib/libstagefright_soft_vpxdec.so
As soon as I step into [email protected] I get that bad syscall error. I just don't really understand what the hell is going on.
Click to expand...
Click to collapse
gdb set force-mode thumb?
gellmar said:
gdb set force-mode thumb?
Click to expand...
Click to collapse
Thanks for the reply, but unfortunately not. I think it's something to do with threading and minijail/SECCOMP.
Code:
(gdb) set arm force-mode thumb
(gdb) si
[New Thread 2652.11026]
Thread 9 received signal SIGSYS, Bad system call.
0xe8a16618 in [email protected] () from target:/system/lib/libstagefright_soft_vpxdec.so

Categories

Resources