--- Log opened Mon Jul 18 00:28:16 2011
00:28 -!- S_a_i_n_t is now known as [Saint]
02:05 -!- TheSeven [~TheSeven@rockbox/developer/TheSeven] has quit [Disconnected by services]
02:05 -!- [7] [~TheSeven@rockbox/developer/TheSeven] has joined #freemyipod
06:56 -!- user890104 [~Venci@83.228.31.135] has joined #freemyipod
07:06 -!- [Saint] [~st.lasciv@124-197-58-10.callplus.net.nz] has quit [Quit: Imagination is for turbo-nerds who can't handle how kick-butt reality is. I'm a kick-butt reality master! I would rather die, than be imaginative. I mean that.]
07:09 -!- [Saint] [~Saint]@124-197-58-10.callplus.net.nz] has joined #freemyipod
07:11 -!- HiddeBoomsma [~hboomsma@office.hostnetbv.nl] has joined #freemyipod
07:13 -!- user890104_ [~Venci@213.226.63.138] has joined #freemyipod
07:16 -!- user890104 [~Venci@83.228.31.135] has quit [Ping timeout: 260 seconds]
07:19 -!- user890104_ is now known as user890104
09:03 -!- HiddeBoomsma [~hboomsma@office.hostnetbv.nl] has quit [Quit: Leaving.]
09:07 -!- HiddeBoomsma [~hboomsma@office.hostnetbv.nl] has joined #freemyipod
12:46 -!- Keripo [~Keripo@c-76-28-198-27.hsd1.wa.comcast.net] has quit [Read error: Connection reset by peer]
13:31  * user890104 found a typo
13:31 < user890104> static void chooser_ction_handler_wheel_destroy(struct chooser_data* data)
13:32 < [7]> wtf
13:33 < [7]> this must be either unused or consistently wrong then
13:35 < user890104> it's names the same below
13:35 < user890104>     .destroy = chooser_ction_handler_wheel_destroy
13:35 < user890104> that's why it works :)
13:38 < [7]> feel free to commit a fix for that
13:42 < fmibot> New commit by user890104 (r755): libui: Fix a typo
13:43 < fmibot> r755 build result: emcore: All green!
13:43 < fmibot> r755 build result: umsboot: All green!
13:44 < user890104> [7]: did you look at the chooser_renderer_list issue i told you about yesterday?
13:44 < [7]> not yet
13:44 < [7]> do you have an idea what's going on?
13:44 < user890104> i'm trying to make dynamic lists, so that would be a problem
13:45 < [7]> building a file chooser? :)
13:45 < user890104> well, if i add more items than the screen can display, the thread probably enters an infinite loop
13:45 < user890104> yep :)
13:45 < [7]> that was on my todo list as well :)
13:45 < user890104> but libui needs some documentation
13:46 < user890104> i'm currently trying to make things by example
13:46 < [7]> yes, like most of our code
13:46 < user890104> this one is rather complicated (at least for me)
13:47 < [7]> are you really sure that the hang is caused by the length of the list?
13:47 < [7]> i can't see a way for that to happen at the first glance
13:47 < [7]> but i just spotted some other line that looks like bullshit:
13:47 < [7]> while (item <= rdata->bottom_item)
13:48 < [7]> comparing pointers that way doesn't seem like a good idea
13:48 < [7]> (assuming it is a linked list)
13:48 < [7]> if it's an array list, this might be correct
13:48 < [7]> damn, it's been too long since I've written that :)
13:49 < [7]> hm, actually it seems to be an array list, so that's fine
13:51 < [7]> possibly something funky going on with rdata->bottom_item or chooser_renderer_list_scroll_into_view in general
13:51 < user890104> http://pastebin.com/ShXVbcwr
13:51 < user890104> this is a list with 12 items
13:51 < user890104> with 11 it works fine
13:52 < [7]> can you upload the elf file of that libui builds somewhere?
13:53 < user890104> it crashed with 11 this time
13:53 < user890104> "hit reset vector"
13:53 < [7]> on a nano2g?
13:54 < user890104> yes
13:54 < user890104> ok, works now
13:54 < user890104> i'll rebuild it with 12
13:54 < user890104> i can also send you my source
13:54 < user890104> there's a chance that i'm doing something wrong
13:55 < [7]> elf + getprocinfo + dumpmalloc will be most helpful to figure out what's going on
13:56 < user890104> http://www.datafilehost.com/download-16b13a42.html
13:57 < user890104> http://pastebin.com/r8SqPfHA
13:58 < [7]> do you know how to run dumpmalloc?
13:58 < user890104> http://pastebin.com/mhW8vFe1
13:58 < [7]> apparently :)
13:58 < user890104> i didn't, but i found out :)
13:59 < [7]> er, wait a second
14:00 < [7]> hm, it's spinning in libui, so i'll need the elf of that as well
14:00 < user890104> ok
14:01 < user890104> so you mean the binary that's in my ipod's nor?
14:01 < [7]> PC=libui+0xdcc
14:02 < [7]> if you didn't load libui from somewhere else, then yes
14:02 < user890104> how do i dump it
14:03 < [7]> the elf isn't on the flash, so you would have to disassemble the binary :/
14:03 < [7]> let's just hope that it's identical with the one I have floating around
14:04 < user890104> if it isn't, i can recompile the installer and flash it
14:04 < user890104> libui hasn't been changed since r708
14:07 < [7]> loc_DCC
14:07 < [7]> LDR     R12, [R2,#8]
14:07 < [7]> LDR     R12, [R12,#4]
14:07 < [7]> CMP     R3, R12
14:07 < [7]> BLT     loc_DCC
14:07 < [7]> that code doesn't make any sense to me
14:08 < [7]> it's quite clear how that can result in an endless loop, but i fail to match it to any of the source code
14:09 < [7]> gcc has apparently heavily optimized that part of the code
14:09 < user890104> compiler weirdness?
14:09 < [7]> there are not even clear function boundaries any more
14:09 < [7]> code being shared amongst different functions which have the same stack frame etc.
14:12  * user890104 removes -Os from libui's CFLAGS and compiles a nano2g installer
14:15 < user890104> it locked up again
14:16 < [7]>         iparams = (const struct chooser_renderer_list_itemdata*)(curr->renderparams);
14:16 < [7]>         if (available >= iparams->size.y)
14:16 < [7]>         {
14:16 < [7]>             available -= iparams->size.y;
14:16 < [7]>             curr++;
14:16 < [7]>         }
14:16 < [7]> it seems to be this code that produces a loop(!) in the binary
14:17 -!- STeeF [~STeeF@office.hostnetbv.nl] has quit [Remote host closed the connection]
14:19 < user890104> now something even more weird happened
14:19 < user890104> i tried to run the previously-working app
14:19 < user890104> and i got an error Could not load libui
14:19 < user890104> then i tried to run it again and got
14:20 < user890104> Stack overflow! (9   kn)
14:21 < [7]> kernel memory corruption...
14:21 < [7]> a reboot should fix that :)
14:21 < user890104> Executed emCORE application as thread 0x61206F6A
14:21 < [7]> nice ascii
14:22 < [7]> "jo a"
14:23 < [7]> now the malloc chain seems to be damaged as well
14:26 -!- STeeF [~STeeF@office.hostnetbv.nl] has joined #freemyipod
14:28 < user890104> http://www.datafilehost.com/download-d4a90bca.html
14:29 < user890104> source: http://www.datafilehost.com/download-b4da3eb2.html
14:30 -!- [Saint] [~Saint]@124-197-58-10.callplus.net.nz] has quit [Remote host closed the connection]
14:30 < user890104> you can also tell me how to find where the problem is by myself :)
14:31 -!- [Saint] [~st.lasciv@124-197-58-10.callplus.net.nz] has joined #freemyipod
14:31 < [7]> this is not a particularly easy one
14:32 < user890104> so PC is at 0x0801BED8
14:32 < user890104> then i look it up in the malloc dump, right?
14:32 < [7]> yeah
14:33 < [7]> turns out ot be in section 0801A400, which is not the same as where the SP is, so it must be a lib
14:34 < [7]> so this time it's libui+0x1AD8
14:34 < user890104> it uses only libui, so it's not hard to find out which is the lib
14:34 < [7]> if you have multiple libs, you can download the memory section and look for the library token
14:35 < user890104> then we load ui.elf in ida and go to 1ad8?
14:36 < [7]> yes
14:36 < [7]> this tells us that it's chooser_renderer_list_scroll_into_view
14:36 < [7]> there are four loops in that function, two outer and two inner ones
14:37 < [7]> it's in the first inner loop
14:37 < [7]> but looking at the source code, it doesn't have an inner loop in the fist one
14:38 < [7]> as they're branching to the same point, it seems to be a "continue" statement
14:38 < [7]> apparently the compiler inverted the if
14:41 < user890104> is this the same code that you pasted earlier?
14:49 < [7]> possibly
14:49 < [7]> it isn't really recognizable in the optimized version
14:49 < [7]> and the optimized one definitely had a bug
14:49 < [7]> IIUC the compiler misplaced the branch destination in that one
14:49 < [7]> the unoptimized one is looking better
15:00 < user890104> what is the expected behavior? scrolling up/down like in of/rockbox?
15:01 < user890104> and .. how do we fix it? :)
15:06 < user890104> i feel a bit lost in these structs having function pointers in them and the whole casting something to a struct
15:35 -!- [Saint] [~st.lasciv@124-197-58-10.callplus.net.nz] has quit [Quit: Imagination is for turbo-nerds who can't handle how kick-butt reality is. I'm a kick-butt reality master! I would rather die, than be imaginative. I mean that.]
15:37 -!- [Saint] [~Saint]@124-197-58-10.callplus.net.nz] has joined #freemyipod
15:49 -!- GeekShad0w [~Antoine@82.203.120.78.rev.sfr.net] has joined #freemyipod
15:52 -!- GeekShad0w [~Antoine@82.203.120.78.rev.sfr.net] has quit [Client Quit]
15:58 -!- HiddeBoomsma [~hboomsma@office.hostnetbv.nl] has quit [Quit: Leaving.]
16:48 -!- ceipha [~ceipha@cm-84.215.1.105.getinternet.no] has joined #freemyipod
17:42 -!- user890104 [~Venci@213.226.63.138] has quit [Ping timeout: 240 seconds]
17:43 -!- user890104 [~Venci@213.226.63.145] has joined #freemyipod
18:54 -!- AlexP [~alex@rockbox/staff/AlexP] has quit [Quit: Please insert girder]
18:55 -!- AlexP [~alex@rockbox/staff/AlexP] has joined #freemyipod
18:55 -!- AlexP [~alex@rockbox/staff/AlexP] has quit [Client Quit]
18:56 -!- AlexP [~alex@rockbox/staff/AlexP] has joined #freemyipod
19:40  * user890104 blames r736 for his issues with emcore on windows
19:44 < [7]> that's very very strange
19:44 < [7]> this commit should have *fixed* that kind of thing, not broken it...
19:46 < user890104> tried with the cpu_freq from that revision and still works
19:46 < user890104> so i guess that if i try cachealign_bits it will break again
19:46 < [7]> yeah, but increasing that should never hurt...
19:47 < user890104> i don't think so
19:47 < user890104> an unknown device just appeared
19:47 < user890104> as soon as i runfirmware
19:48 < user890104> and it seems to be broken only on windows
19:48 < user890104> tested on 7 x64 and xp
19:48 < [7]> very very odd issue
19:49 < user890104> so we only have it in util.h
19:51 < user890104> so it changes cachealign size from 16 to 32
19:58 < user890104> [7]: what does this actually do?
20:00 < [7]> it specifies the alignment that's neccessary for DMA operations to avoid cache coherency problems
20:00 < [7]> placing a too low number there might cause odd bugs, but a too large number would just waste space
20:01 < user890104> i'll try with 6 then
20:02 < user890104> it causes the usb error too
20:02 < user890104> since we have a lot of ram, i'll try increasing it a bit more :)
20:04 < [7]> i know for sure that 5 is the correct value
20:04 < [7]> i'd rather assume that increasing it from 4 to 5 moved things around in RAM in a way that broke something
20:04 < [7]> no idea what though
20:05 < [7]> is it just usb that's broken, or do other things fail as well?
20:05 < user890104> i don't know how to check without usb access
20:05 < user890104> the backlight/display seem to work
20:06 < user890104> i'll redefine cachealign_size only for usb.c
20:07 < user890104> btw any value from 6 to 10 inclusive breaks it the same way as 5
20:08 < [7]> you said that USB works on linux?
20:08 < user890104> yeah, and on mac too
20:09 < user890104> but on windows it fails for some reason
20:09 < user890104> the device descriptor is read
20:09 < user890104> but maybe it fails at the config one
20:11 < [7]> what about trying to access it from linux, to see if other functions are working then?
20:11 < user890104> usb.c with #define CACHEALIGN_SIZE 16 works
20:12 < user890104> and i left CACHEALIGN_BITS to 4 in target.h
20:15 < user890104> since there are only vars/structs with cachealign_attr, i can manually test which one is causing the trouble
20:19 < user890104> found it :)
20:20 < user890104> -} __attribute__((packed)) CACHEALIGN_ATTR config_bundle =
20:20 < user890104> +} __attribute__((packed)) __attribute__((aligned(16))) config_bundle =
20:21 < [7]> hm, very weird
20:21 < user890104> what's this attribute "packed" for?
20:24 < user890104> i found this: http://digitalvampire.org/blog/index.php/2006/07/31/why-you-shouldnt-use-__attribute__packed/
20:26 -!- posixnin_ [~textual@h149.26.190.173.dynamic.ip.windstream.net] has joined #freemyipod
20:28 -!- posixninja [~textual@h36.147.90.75.dynamic.ip.windstream.net] has quit [Ping timeout: 276 seconds]
20:28 -!- posixnin_ is now known as posixninja
20:30 < [7]> it is absolutely neccessary here
20:30 < [7]> it ensures that the order and size of the elements is kept, and not padded in anyway
20:30 < [7]> and as the structure needs to conform to the USB standards, there is no way to get around that
20:32 < user890104> so why it doesn't work with aligned(32) but only with aligned(16)?
20:33 < [7]> absolutely no idea
20:33 < [7]> probably because it moves something completely different around, and causes it to break
20:37 < user890104> can you confirm if svn head breaks or works on your nano4g on windows?
20:37 < user890104> i can do a lsusb on linux to check what's wrong with the descriptor
20:41 -!- user890104 [~Venci@213.226.63.145] has quit []
20:54 -!- user890104 [53e41f87@gateway/web/freenode/ip.83.228.31.135] has joined #freemyipod
20:56 < user890104> [7]: you might want to see this: http://pastie.org/2233717
21:01 -!- user890104 [53e41f87@gateway/web/freenode/ip.83.228.31.135] has quit [Ping timeout: 252 seconds]
21:03 -!- user890104 [~Venci@213.226.63.134] has joined #freemyipod
21:04 -!- user890104_ [~Venci@213.226.63.142] has joined #freemyipod
21:08 -!- user890104 [~Venci@213.226.63.134] has quit [Ping timeout: 252 seconds]
21:08 -!- user890104 [~Venci@213.226.63.134] has joined #freemyipod
21:09 -!- user890104_ [~Venci@213.226.63.142] has quit [Ping timeout: 264 seconds]
23:37 -!- [Saint] [~Saint]@124-197-58-10.callplus.net.nz] has quit [*.net *.split]
23:37 -!- belak [belak@subtle/user/belak] has quit [*.net *.split]
23:37 -!- Utchy [~Utchy@rps6752.ovh.net] has quit [*.net *.split]
23:43 -!- [Saint] [~Saint]@124-197-58-10.callplus.net.nz] has joined #freemyipod
23:43 -!- belak [belak@subtle/user/belak] has joined #freemyipod
23:43 -!- Utchy [~Utchy@rps6752.ovh.net] has joined #freemyipod
--- Log closed Tue Jul 19 00:47:34 2011