| 00:00 | [acl] | anways time to go home |
| 00:00 | [acl] | ill ttyl folks |
| 00:00 | faregran | guys, you're great! |
| 00:00 | faregran | it's a pleasure to read you |
| 00:02 | WisTilt2 | rpierce99 when my autobuild is done rebuilding 3.0 can you pull it and see if its still dirty. only thing i could find was some missing things in gitignore that are in both .39 and 3.1, everything else is identical in the build scripts i made for all of them. |
| 00:10 | rpierce99 | looks like it built, checking it now |
| 00:14 | rpierce99 | hm, something is odd here, still dirty, still #1 |
| 00:14 | rpierce99 | Linux localhost 3.0.9-g50eb1d1-dirty #1 PREEMPT Tue Jan 3 15:02:10 PST 2012 armv6l GNU/Linux |
| 00:15 | WisTilt2 | should always be #1 but why its still dirty is puzzling. nothing is showing up in git status that would make it a dirty build |
| 00:15 | rpierce99 | but it's the same build id too, every other time when it's the same build id it's incremented the number i thought |
| 00:16 | WisTilt2 | normally yes but i have it setup to clear version each build after it does the copy from the primary git folder |
| 00:16 | rpierce99 | gotcha |
| 00:17 | WisTilt2 | let me build manually and see if anything pops out causing this |
| 00:18 | WisTilt2 | was this thing building clean before that last commit do you know? |
| 00:22 | rpierce99 | i don't know when it started, the 3.0 kernel just started getting attention with the public release of the new gb |
| 00:23 | rpierce99 | and detule made a kernel testing thread looking for feedback on .39, 3.0, and 3.1 |
| 00:23 | rpierce99 | 3.0 was popular because it has bluetooth, but they couldn't get wifi because of a module mismatch |
| 00:24 | WisTilt2 | guess ill clone 3.0 locally and see if i get a dirty build. everything looks normal on the server so im stumped |
| 03:23 | d3tul3 | g'd evening |
| 03:30 | rpierce99 | hey d3tul3, might want to snoop the logs and make sure i didn't misrepresent your issue to wistilt2 |
| 03:30 | d3tul3 | just saw them, thanks for mentioning it to him |
| 03:31 | d3tul3 | it's storage that the vermagic in the modules is non-dirty but the kernel reports dirty.... |
| 03:31 | d3tul3 | *storage=strange |
| 03:34 | rpierce99 | totally storage |
| 09:18 | DuperMan | arrrghhh sup? |
| 12:07 | dunc001 | Any news from cotulla on MAGLDR 2.0 for HD2? |
| 12:10 | arif-ali | hey dunc001, did you get the init.rc cache working |
| 12:11 | dunc001 | Hey arif, Dan's working on it now. We've also switched to the new m2sd script so a bit more work to make all the changes |
| 12:12 | dunc001 | Did you see my question about adding the /download symlink into your 02cachesd script? |
| 12:13 | arif-ali | As you guys are not compiling from source, you don't need the 02cachesd script, you could hardcode everything into init.rc/init.htcleo.rc |
| 12:13 | arif-ali | 02cachesd is for those who compile from source, and use the standard init.rc from AOSP code |
| 12:17 | dunc001 | Confused? In to pm you said to remove all /cache references from the .rcs and use the 02cachesd script? |
| 12:19 | arif-ali | yeah, that is the other option |
| 12:24 | dunc001 | Ok, well we've done that so well leave it that way for now. If we want to put it back in the rc which one does it go in (or both)? |
| 12:25 | arif-ali | I would prefer to put it into init.rc in your case, that way it is more flexible, then you can hash out the mount for mtd@cache, and mount cache in your own way |
| 12:31 | dunc001 | Thanks, might do that then before we release it |
| 19:35 | WisTilt2 | detule, this dirty kernel build is a pita. everything looks correct so im stumped. when you clone the 3.0 tree and build is everything clean on your end? i tried that locally and got dirty kernel and modules right off the bat. |
| 19:35 | detule | Hey WisTilt2 |
| 19:35 | detule | let's see i think i found where in the build script it adds "-dirty" |
| 19:36 | detule | so "git status" returns nothing? |
| 19:36 | WisTilt2 | status shows nothing at all and looks clean. whats strange is the kernel.release isnt dirty |
| 19:37 | detule | i guess trying a "make clean" on the server |
| 19:37 | WisTilt2 | it does |
| 19:37 | detule | oh you already did that and still same situation? |
| 19:37 | WisTilt2 | make clean msm_defconfig make make modules, all same as .39 and 3.1 |
| 19:37 | detule | this is what the build script checks "git diff-index --name-only HEAD" |
| 19:38 | detule | but i assume if git status returns empty so will that |
| 19:39 | WisTilt2 | yep nothing at all listed in git status on the server or my local clone before or after building |
| 19:40 | WisTilt2 | you're getting clean build locally? what .gitignore you using? |
| 19:41 | detule | hm i am not sure i might be checking it out from the 3.1 branch |
| 19:42 | mgross029 | detule: just to be sure you may run a git diff. My git status on one of my modified kerenl directories shows different modified files that what git diff is showing me. Not sure why that is. |
| 19:42 | WisTilt2 | that shouldn't matter but i can try that. i cloned only the 3.0 tree alone. git branch shows htc-msm-3.0.0-rc1 so beats me |
| 19:43 | WisTilt2 | detule has 3.0 always built dirty kernels or do we know that? |
| 19:43 | detule | i am almost 100% sure it built clean for a while |
| 19:44 | detule | almost 100% ha |
| 19:46 | mgross029 | time to rm -R :p |
| 19:51 | detule | WisTilt2, what's the output of just "make kernelrelease" |
| 19:51 | WisTilt2 | 3.0.9-g50eb1d1 |
| 19:52 | WisTilt2 | thats off the autobuild |
| 19:55 | detule | this is stupid...it's possible we may have done something to the gitignore when we added a bunch of stuff last time |
| 19:55 | detule | we should have a single gitignore for all three trees...the one in 3.1 is stock from kernel.org |
| 19:55 | WisTilt2 | i even tried copying .gitignore from both .39 and 3.1 onto 3.0 same thing |
| 19:57 | WisTilt2 | im going to wipe the whole 3.0 off the autobuild and clone again and use 3.1 gitignore and see what it does |
| 19:58 | WisTilt2 | detule before i do this are we sure 3.1 is clean on both kernel and modules? |
| 19:59 | detule | let me double check it will take me a few minutes |
| 20:01 | detule | WisTilt2, btw have you checked if prox is working for you now on 39 |
| 20:02 | WisTilt2 | no, still running my .39 kernel from before xmas. i was going to get the new gb and try the autobuild .39 and 3.1 on it later today. |
| 20:03 | detule | 3.1 kernel from the autobuild is clean and matches the clean modules |
| 20:03 | WisTilt2 | ok thanks. im cloning 3.0 again on the autobuild so going to be awhile. |
| 20:04 | WisTilt2 | not checking out 3.0, cloning only 3.0 branch also. thats how i did 3.1 and dont remember if 3.0 was that way |
| 21:03 | mgross029 | Anyone ever try this setprop setting? ro.telephony.call_ring.delay=0 I was doing some searching and the default if it is not present in build.prop is 3 sec or typically the third ring on the callers end. I put it in to my build.prop and the phone seems to ring now sooner. |
| 21:04 | mgross029 | Was just wondering if others could try to make sure. |
| 21:06 | mgross029 | This is being referenced in ril.h via #define RIL_UNSOL_CALL_RING 1018 |
| 21:11 | mgross029 | WisTilt2: I pushed that prop setting to .39 just now and the phone rang after a 1.5 rings on the calling end. |
| 21:11 | mgross029 | Hey emwe |
| 21:15 | emwe | hi |
| 21:18 | mgross029 | emwe: applied a small fix up to the 35 kernel which helps the autoconnect and disconnect of bt with my car. So far it has been working well. |
| 21:19 | emwe | ok, what is it? |
| 21:19 | mgross029 | I found it after comparing .27acoustic and 3.0 board-htcrhodium.c |
| 21:19 | mgross029 | http://dl.dropbox.com/u/45928762/35btserialfix.txt |
| 21:20 | detule | mgross029, see those "#if 0" |
| 21:20 | mgross029 | detule: yes |
| 21:21 | detule | that code only compiles if the argument to "#if" tests positive....seeing how we are passing "0" to it, we are saying "never compile" |
| 21:22 | mgross029 | Hmmm. I pulled that from the 3.0 kernel actually and after applying to the 35 my car bt now autoconnects and disconnects where before it did not. |
| 21:23 | mgross029 | The #include is new. I haven't tested that out, just found that in all of the other kernels with working bt, but not in 35. So, that is something I need to test out yet to be sure it didn't break anything. |
| 21:25 | mgross029 | Another problem was when I hang up from the bt controls in the car it drops it from the car audio but the call stays up on the phone and that is where I thought the #include may help, but wasn't totally sure. |
| 21:27 | detule | much like the rest of it "#include" is not any effective execution code.. |
| 21:38 | emwe | mgross029: ehm, as detule said, this does nothing. |
| 21:38 | emwe | sorry for the delay. just figured my id-card expired. crapola. |
| 21:40 | mgross029 | emwe: That's a bummer about the id-card |
| 21:41 | emwe | i just online-requested a certificate of birth in my home town and thought the id-card number was required, but wasn't... and looked... ehm... |
| 21:41 | emwe | damn bureaucracy when you become parents... |
| 21:42 | mgross029 | emwe: over here it is worse. :p |
| 21:43 | mgross029 | Anyway I don't understand why putting that code in made a difference for me then if it does nothing. :-\ |
| 21:44 | detule | placebo...i've suffered similarly many-a-time |
| 21:44 | mgross029 | Well I'll keep testing it to see if the sugar wears off. :p |
| 21:45 | emwe | you didn't in between update .35, no? |
| 21:45 | emwe | i mean, pull in some commits... |
| 21:46 | mgross029 | I did see the recent commits you just did, but this was prior to those. |
| 21:46 | mgross029 | I have pulled your latest down and recompiled as well. |
| 21:48 | emwe | let me know how bad the panel wakes. |
| 21:48 | mgross029 | Will do. |
| 21:49 | mgross029 | emwe: did you see my post ^^ on ro.telephony.call_ring.delay=0... |
| 21:50 | emwe | one sec. |
| 22:30 | mgross029 | Later guys. I'm out! |
| 22:56 | [acl] | emwe: dood you around? |
| 22:56 | emwe | [acl]: a bit still. |
| 22:56 | [acl] | emwe: ill be quick |
| 22:56 | [acl] | its baout the 3.5mm gpio that we commented out |
| 22:57 | emwe | [acl]: me too... when you did the nand ril fix for GSM, was the issue a arm9 reset or a freeze? |
| 22:57 | emwe | we should enable it, it looks? |
| 22:58 | [acl] | emwe: well for gsm it would completelyu reboot |
| 22:58 | emwe | reboot, ok... |
| 22:58 | [acl] | emwe: so it would only boot if i disabled the ril. then i realied its ril related |
| 22:58 | [acl] | booted examined the radio and realized there were no replies unlike cdma. Then made sense |
| 22:59 | [acl] | emwe: anyway the gpio for 3,5mm apparently has to be set to 0 for it to be enabled |
| 22:59 | [acl] | and 1 for disabled |
| 22:59 | [acl] | so originally i set it to 1 and it killed detection in general |
| 22:59 | [acl] | but if you set it to 0, its all good. Not sure if its needed or not just thought id share |
| 23:00 | emwe | wasn't that gpio supposed to reset all microp interrupt pins? |
| 23:00 | emwe | ok, so if you set it to 0, does h2w headset detection still work? |
| 23:00 | [acl] | yeah |
| 23:01 | [acl] | h2w works |
| 23:01 | [acl] | when set to 0 |
| 23:01 | [acl] | 1 actually is meant to disable it |
| 23:01 | [acl] | so its kinda retarded and im not even sure if its a good idea to have that code in. |
| 23:01 | [acl] | well for nand we need it, but haret may be fine without it in general . |
| 23:01 | emwe | it had it's purpose in mahimahi, no? |
| 23:02 | [acl] | well to set the intial value i suppose. |
| 23:03 | emwe | hm, they set it to 1 only and are done. |
| 23:03 | emwe | i'll give it a try... so you got it set to 0 and the code enabled, yap? |
| 23:05 | [acl] | yeap. but that doesnt fix our interrupt issue |
| 23:05 | [acl] | we still dont get interrupts |
| 23:05 | emwe | 3.5mm insert interrupt? |
| 23:07 | [acl] | yeah |
| 23:07 | [acl] | funny i think i can actually poll for it, but there is no irq yet .. |
| 23:08 | [acl] | i think the irq itself is really not named properly on winmo |
| 23:08 | emwe | did you take over the interrupt mask change and read-method change i did on .35 back then? |
| 23:08 | [acl] | i mean it has nothing to do with gsensor |
| 23:09 | [acl] | yeah i tried a whole mess of things |
| 23:10 | emwe | ehm, typo? line 277... lin265 on mine. it's flipped upside down |
| 23:10 | [acl] | link? |
| 23:10 | emwe | lazy bitch :P |
| 23:10 | [acl] | :-p |
| 23:11 | emwe | keep my branch around and sync regularly. this is what i do with yours :P |
| 23:11 | emwe | for quick meld'ing |
| 23:11 | [acl] | ive been so busy lately i havent looked at anything |
| 23:12 | emwe | void microp_i2c_intr_work_func() still uses the two byte read. i took that over from htc to read 3 bytes. |
| 23:12 | emwe | (which is likely not relevant for us...) |
| 23:13 | [acl] | ahh, well its only 2 byte on winmo. but thats not the issue. The gpio irq is the one not working. i can actually poll the microp status and detect it. so something else is being a beotch |
| 23:13 | emwe | [acl]: https://gitorious.org/linux-on-qualcomm-s-msm/linux-msm/blobs/htc-msm-2.6.35/arch/arm/mach-msm/htc_headset_microp.c#line265 |
| 23:13 | emwe | but the work func is not triggered, right? |
| 23:15 | [acl] | work func i think itself is triggered once. but the irq handler is never triggered |
| 23:19 | emwe | think i can't be of much more help without being nanded |
| 23:20 | [acl] | i wouldnt worry about it. worse case ill poll it until its resolved |
| 23:20 | emwe | and you need the microp reset code in order for what to work? |
| 23:21 | [acl] | actually i dont. lol. |
| 23:22 | emwe | must have misunderstood, then. sorry. |
| 23:22 | [acl] | microp reset is just for formality :-\ |
| 23:23 | emwe | and kills h2w detection when kept at this place. |
| 23:23 | emwe | offtopic: you know if our ril sends multiple cring notifications or just one? |
| 23:24 | [acl] | i dunno, code wise its pretty close. I can dump some stuff for you if you need. Ril is not really my thing |
| 23:24 | Cotulla | sup doods |
| 23:24 | [acl] | damn |
| 23:24 | [acl] | Cotulla: whats good my good man |
| 23:24 | Cotulla | wanted to ask u |
| 23:24 | Cotulla | "{ |
| 23:24 | Cotulla | :P |
| 23:24 | emwe | [acl]: no worries, thanks. |
| 23:24 | emwe | hi Cotulla. |
| 23:25 | Cotulla | hi enwe |
| 23:25 | [acl] | Cotulla: ask quick.. my office is closing soon |
| 23:25 | emwe | my bed is calling soon, too :P |
| 23:25 | [acl] | lol |
| 23:27 | emwe | so, i gotta run. tty later, peeps. |
| 23:28 | [acl] | emwe: later dood |
| 23:29 | Cotulla | lol |
| 23:29 | Cotulla | bb |
| 23:32 | d3tul3 | [acl], thanks for gsm prox |
| 23:35 | [acl] | d3tul3: no problemo |
| 23:40 | WisTilt2 | d3tul3: i just stuck the new gb on along with .39 off autobuild and prox works perfect. someone needs to tell stinebd or whoever does this, they forgot the big easy ringtone:( |
| 23:41 | [acl] | lol |
| 23:41 | WisTilt2 | got busy here but im building 3.0 on the autobuild now so fingers crossed |
| 23:41 | [acl] | aite fellas. i'm out.. |
| 23:41 | WisTilt2 | hi/bye [acl] |
| 23:42 | d3tul3 | big easy i had to google it :) |
| 23:43 | WisTilt2 | thats my normal ringtone so need it:) so with this clean 3.0 and the 3.1 .gitignore it better build clean! |
| 23:44 | d3tul3 | if we get everything a-ok it might be a good idea to actually commit the gitignore file |
| 23:44 | d3tul3 | that way everyone building the kernel locally works with the same gitignore |
| 23:50 | WisTilt2 | still built dirty on the kernel but kernel.release is clean |
| 23:50 | WisTilt2 | out of ideas |
| 23:51 | d3tul3 | ugh i need to check that kernel that I compiled from my tree |
| 23:51 | WisTilt2 | git status on autobuild still shows 100% clean with no files |
| 23:51 | WisTilt2 | thats after building btw |
| 23:52 | d3tul3 | how about cat include/generated/utsrelease.h |
| 23:52 | WisTilt2 | #define UTS_RELEASE "3.0.9-g50eb1d1" thats the contents |
| 23:52 | WisTilt2 | looks clean to me |
| 23:58 | WisTilt2 | it's got to be some scripts somewhere thats borked. everything show clean. i just modified a file and built, now it shows modules dirty like it should along with the kernel. put original file back and modules are clean again. |
| 23:59 | d3tul3 | and i guess the zImage still dirty? |
| 23:59 | WisTilt2 | yep |
| 23:59 | rpierce99 | this will all resolve itself if you just keep your tree dirty :) |
| 23:59 | d3tul3 | i am going through the damn scripts trying to figure out where the zImage gets stamped |