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
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
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