00:29.27 | *** join/#htc-linux rajkosto (~rajkosto@wan.rajkonet.info) |
00:56.16 | *** join/#htc-linux whitglint (~whitglint@114-40-171-120.dynamic.hinet.net) |
01:11.05 | detule | ugh |
01:12.59 | *** join/#htc-linux BHSPitMonkey (~stephen@unaffiliated/bhspitmonkey) |
01:23.31 | jonpry | hey detule |
02:00.13 | *** join/#htc-linux whitglint (~whitglint@114-40-171-120.dynamic.hinet.net) |
02:04.42 | *** join/#htc-linux detule (~detule@unaffiliated/d3tul3) |
02:04.59 | detule | hi jonpry |
02:22.39 | *** join/#htc-linux whitglint (~whitglint@114-40-171-120.dynamic.hinet.net) |
02:56.57 | detule | pretty sure google is doing something stupid with evdev |
02:57.42 | jonpry | oh yeah? |
02:58.36 | detule | https://github.com/android/kernel_common/commit/783820ba98710e0529c4a358a73ec1999dc4e7fd#drivers/input/evdev.c |
02:59.02 | detule | i got a few sod-s on 3.4, need someone to blame |
02:59.49 | jonpry | ugh sod |
03:04.31 | detule | made any progress on the droid? |
03:12.13 | jonpry | i need a serial cable to do anything |
03:12.28 | jonpry | so i ordered one from china. hopefully it will help |
03:13.00 | jonpry | i tried search for any available piece of memory to make a ramconsole out of but it appears to all be zeroed by something |
03:13.13 | jonpry | and the sram is zeroed by the kernel |
03:15.30 | jonpry | might be some kind of gpio led |
03:25.55 | *** join/#htc-linux rob_w_ (~bob@host-188-174-175-223.customer.m-online.net) |
03:36.46 | *** join/#htc-linux Ondalf (~ondalf@cable-roi-fe98dc00-121.dhcp.inet.fi) |
03:44.24 | detule | how did you search the memory? |
03:44.48 | detule | pretty sure i've been using this with no evdev wakelocks |
03:51.13 | jonpry | i made a kernel module that i can load |
03:52.23 | jonpry | there is a big hole at the end of ram for dsp stuff that i think only gets loaded for video decoding so i ioremap'd it. put some stuff in it, rebooted. all zero's |
03:55.02 | jonpry | i suppose its possible that the hole gets zeroed but regular kernel memory doesn't somehow |
03:55.34 | jonpry | but that is a can of worms trying to carve out memory live in the kernel |
03:57.12 | detule | are there any moto sources out there with ram console addresses? |
03:57.42 | jonpry | the source can be compiled with ram console and it generates a hole |
03:58.28 | jonpry | also there is some kind of apanic thing i don't understand |
03:58.50 | jonpry | like i can blow up a kernel and it will email motorola |
03:59.45 | jonpry | but i wonder how worthwhile all that is when it has serial capability |
04:02.20 | *** join/#htc-linux AstainHellbring (~AstainHel@unaffiliated/astainhellbring) |
04:04.48 | jonpry | this device tree stuff is also really scary |
04:04.56 | jonpry | like all moto phones use the same kernel |
04:05.00 | jonpry | with same machtype |
04:05.07 | jonpry | and even the same boardfile |
04:06.58 | detule | wow they make htc look good |
04:07.20 | jonpry | i'm not convinced this is a terrible idea |
04:07.44 | jonpry | really they are just antiquating machtype voodoo in exchange for device tree |
04:07.49 | detule | sounds like xdandroid all over again and the cluster that was .27 |
04:08.07 | detule | i take it back |
04:08.25 | jonpry | we could do device tree |
04:09.29 | jonpry | all the cool people are doing it |
04:10.03 | detule | oh yeah i really have no idea how these dts's work |
04:10.34 | jonpry | there is that problem |
04:15.16 | detule | so what's the advantage here - less code replication? |
04:17.34 | jonpry | something like that. eventually get it to a place where there is no board specific code in the kernel |
04:17.50 | jonpry | and a kernel can just run on a phone with a good enough device tree |
04:23.35 | *** join/#htc-linux ElFinLazz (~elfinlazz@182.215.84.22) |
05:22.10 | *** join/#htc-linux DuperMan (~Duper@93-173-12-225.bb.netvision.net.il) |
05:24.28 | *** join/#htc-linux DuperMa (~Duper@109-186-23-45.bb.netvision.net.il) |
05:26.30 | *** join/#htc-linux e334 (~e334@c-76-20-17-84.hsd1.ca.comcast.net) |
05:56.54 | *** join/#htc-linux kiozen (~kiozen@p578a42db.dip0.t-ipconnect.de) |
06:04.40 | *** join/#htc-linux tsdogs (~tsdogs@213.203.187.146) |
06:17.47 | *** join/#htc-linux ychavan (ychavan@nat/redhat/x-txckybaztoxozccx) |
06:42.56 | *** join/#htc-linux eR^zeRa` (zzeratul@kaj-0011.koleje.cuni.cz) |
07:05.53 | *** join/#htc-linux gauner1986 (~Miranda@ip-178-202-173-10.unitymediagroup.de) |
07:10.05 | *** join/#htc-linux AstainHellbring (~AstainHel@unaffiliated/astainhellbring) |
08:09.27 | *** join/#htc-linux helicopter88 (~helicopte@host52-117-dynamic.55-79-r.retail.telecomitalia.it) |
08:15.58 | *** join/#htc-linux balans2 (~user@82-170-217-205.ip.telfort.nl) |
08:17.42 | *** join/#htc-linux arif-ali (~arif-ali@81.23.53.226) |
08:30.39 | *** join/#htc-linux marc1706 (~Marc@phpbb/modifications/marc1706) |
09:36.55 | *** join/#htc-linux Funklord (~cow@84-55-99-121.customers.ownit.se) |
09:39.07 | *** join/#htc-linux ychavan (ychavan@nat/redhat/x-ffqmkfdyqylhrclb) |
11:09.18 | *** join/#htc-linux detule (~detule@unaffiliated/d3tul3) |
11:12.09 | *** join/#htc-linux BabelO (~wdlxtv@AMontpellier-553-1-32-245.w92-145.abo.wanadoo.fr) |
11:53.29 | *** part/#htc-linux chillmore (~chillmore@e176075190.adsl.alicedsl.de) |
13:17.43 | *** join/#htc-linux BabelO (~wdlxtv@AMontpellier-553-1-32-245.w92-145.abo.wanadoo.fr) |
13:25.10 | *** join/#htc-linux BabelO (~wdlxtv@AMontpellier-553-1-32-245.w92-145.abo.wanadoo.fr) |
13:29.48 | *** join/#htc-linux ychavan (ychavan@nat/redhat/x-camvaviuicapqesv) |
13:45.34 | *** join/#htc-linux Ondalf (~ondalf@cable-roi-fe98dc00-121.dhcp.inet.fi) |
13:50.41 | *** join/#htc-linux DuperMa (~Duper@109-186-23-45.bb.netvision.net.il) |
13:52.44 | *** join/#htc-linux gauner1986 (~Miranda@ip-178-202-173-10.unitymediagroup.de) |
14:16.37 | *** join/#htc-linux polyrhythmic (~polyrhyth@c-24-17-231-236.hsd1.wa.comcast.net) |
14:18.53 | *** join/#htc-linux marc1706 (~Marc@phpbb/modifications/marc1706) |
14:28.09 | *** join/#htc-linux detule (~detule@unaffiliated/d3tul3) |
14:35.27 | *** join/#htc-linux Alex[sp3dev] (d5551202@gateway/web/freenode/ip.213.85.18.2) |
14:35.34 | *** join/#htc-linux [1]NeoMatrixJR (~NeoMatrix@173-18-84-218.client.mchsi.com) |
14:42.58 | *** join/#htc-linux NeoMatrixJR (~NeoMatrix@173-18-84-218.client.mchsi.com) |
15:07.20 | *** join/#htc-linux NeoMatrixJR (~NeoMatrix@173-18-84-218.client.mchsi.com) |
15:25.10 | *** join/#htc-linux NeoMatrixJR_away (~NeoMatrix@173-18-84-218.client.mchsi.com) |
15:40.55 | *** join/#htc-linux MethoS- (~clemens@134.102.106.250) |
15:42.09 | *** join/#htc-linux eR^zeRa` (zzeratul@kaj-0011.koleje.cuni.cz) |
15:44.23 | *** join/#htc-linux rob_w (~bob@host-188-174-175-223.customer.m-online.net) |
15:44.23 | *** join/#htc-linux rob_w (~bob@unaffiliated/rob-w/x-1112029) |
16:06.00 | *** join/#htc-linux |Jeroen| (~jeroen@d5153E8CC.access.telenet.be) |
16:09.20 | *** join/#htc-linux BabelO (~wdlxtv@AMontpellier-553-1-32-245.w92-145.abo.wanadoo.fr) |
17:25.51 | *** join/#htc-linux XirXes (~xirxes@67-2-31-70.slkc.qwest.net) |
18:32.08 | *** join/#htc-linux Cotulla (~myfakemai@nat100-255-205-109.tvoe.tv) |
18:32.23 | Cotulla | hi |
18:51.36 | *** join/#htc-linux rajkosto (~rajkosto@wan.rajkonet.info) |
18:58.54 | *** join/#htc-linux arif-ali (~arif-ali@94-192-24-56.zone6.bethere.co.uk) |
19:01.09 | *** join/#htc-linux surge (surge@pool-98-118-183-214.bflony.fios.verizon.net) |
19:03.16 | *** join/#htc-linux Alex[sp3dev] (d5551202@gateway/web/freenode/ip.213.85.18.2) |
19:38.11 | zeusk | hi |
19:42.48 | *** join/#htc-linux detule (~detule@unaffiliated/d3tul3) |
20:09.07 | *** join/#htc-linux ImCoKeMaN (~imcokeman@pool-173-67-144-183.hrbgpa.fios.verizon.net) |
20:32.53 | *** join/#htc-linux furtardo (~mks@nat/yahoo/x-wseqcybqwmvcaoax) |
20:41.22 | *** join/#htc-linux jonpry (~jon@c-24-17-200-206.hsd1.wa.comcast.net) |
20:47.00 | detule | jonpry, fix this pos 3.4 |
20:47.17 | jonpry | broke? |
20:47.32 | detule | yeah and i don't think it's us |
20:48.06 | detule | i get the same sod-like failure with clean android patches, and with our own 3.2/3.3 patches |
20:49.52 | jonpry | hrm |
20:50.16 | jonpry | some kind of arch/arm mach-msm interaction? |
20:51.21 | detule | don't think so i think it something with the process freezer |
20:52.35 | jonpry | why is that? |
20:52.48 | jonpry | have you pulled a ramconsole from after sod? |
20:53.12 | detule | i've pulled maybe 20, i can reproduce it |
20:53.38 | jonpry | anything juicy? |
20:53.58 | detule | http://pastebin.com/2Mag3jbn |
20:54.14 | detule | i can reproduce it if i get on a call |
20:54.18 | detule | cover the prox |
20:54.22 | detule | (proximity 0 in the log) |
20:54.27 | detule | phone goes to sleep |
20:54.30 | detule | doesn't wake up |
20:54.46 | detule | note at the end of that log |
20:55.00 | detule | everything is working as in there are repeated requests for this thing to wake up |
20:55.14 | detule | but the kernel is completely unresponsive |
20:55.32 | jonpry | yes |
20:55.44 | jonpry | so not really an sod |
20:56.02 | detule | no |
20:56.04 | Alex[sp3dev] | on kovsky/35 the similiar problem was because of mmc, so i had to hack it for wl1251. but it may be anything. you could try ftrace to write the log to sd card although it is not very nice |
20:56.37 | jonpry | kernel seems to have woken up |
20:56.47 | jonpry | i would blame that evdev time crapola |
20:57.11 | detule | well i still haven't patched this thing for embedded sdio -> though wifi is working fine...could that be a problem? |
20:57.14 | Alex[sp3dev] | well, it may just spin or wait_event in some place |
20:57.24 | Alex[sp3dev] | detule: nope, embedded sdio is deprecated |
20:57.27 | jonpry | there is a timesource change in evdev too |
20:57.30 | detule | not in our kernel |
20:57.35 | jonpry | lol |
20:57.52 | Alex[sp3dev] | detule: well, embedded sdio was never needed for bcm4329 |
20:58.01 | Alex[sp3dev] | it was for wl1251 which doesn't have cccr/cis registers |
20:58.10 | detule | thanks, i suspected that was the case |
20:58.52 | detule | [ 493.940000] Restarting tasks ... done. |
20:58.53 | detule | <PROTECTED> |
20:58.57 | Alex[sp3dev] | either way, i don't know a good way of debugging kernel except inserting printk everywhere around locks/wait_events |
20:59.20 | jonpry | not a believer in timesource problem? |
20:59.57 | detule | if i knew what it was |
21:00.10 | detule | this is with evdev.c from 3.3 |
21:00.11 | Alex[sp3dev] | that may be the case, especially if there's some timeout waiting |
21:00.32 | Willd | xles: Dang! |
21:00.39 | Willd | Err. Wrong. |
21:00.39 | Alex[sp3dev] | jonpry: can you imagine how secure nexus is? xloader really didn't check SBL signature and boots any crap i flash |
21:00.53 | jonpry | i wish i had that problem |
21:01.46 | jonpry | how many pc's would it take to brute force a sha1? |
21:02.02 | Willd | Err. Wrong. |
21:02.05 | Willd | Gah. |
21:03.27 | Alex[sp3dev] | "German security researcher Thomas Roth was able to crack 14 SHA1-encrypted hashes in just 49 minutes, renting CPU time on Amazon’s cloud computing infrastructure, at a cost of just $2.10" |
21:04.10 | Alex[sp3dev] | but really, isn't omap using some 1024bit rsa? |
21:04.44 | detule | here's another log with a different wake_lock http://pastebin.com/QQCaZ6sb .... |
21:05.13 | jonpry | not sure. and sbl could use its own method |
21:06.25 | Alex[sp3dev] | PM: Device power.0 failed to suspend noirq: error -11 >>> that's strange. on most devices android alarm does return error, but power.0 is something new |
21:08.06 | Alex[sp3dev] | that's likely wakelock |
21:08.42 | detule | yeah but like, the failure path is somehow polluted |
21:09.55 | detule | and i don't get why the active wake lock doesn't show up in "Freezing user space processes" since I am pretty sure that guy also checks "has_wake_lock(" |
21:10.53 | jonpry | i could have botched the patches to kernel/power |
21:10.58 | jonpry | it would't be the first time |
21:11.36 | detule | yeah but i get the same thing with your patches, and with clean android patches....ugh tired of looking at this |
21:15.19 | *** join/#htc-linux marc1706 (~Marc@phpbb/modifications/marc1706) |
21:15.39 | Alex[sp3dev] | a crazy idea. port the hw drivers to a hypervisor like L4 and run a single kernel/userland on all android devices. |
21:16.03 | Cotulla | lol Alexx |
21:20.09 | Alex[sp3dev] | i wonder how long checking out cm9 code will take |
21:20.21 | jonpry | few days |
21:20.46 | Alex[sp3dev] | checking out as in cloning (vcs checkout), not reading it |
21:20.54 | detule | lol |
21:21.02 | Alex[sp3dev] | i would assume some 3-4 hours though |
21:22.09 | jonpry | yeah it literally took me days to git clone |
21:22.18 | jonpry | but that was back when kernel.org had flopped |
21:22.22 | Alex[sp3dev] | i see |
21:23.44 | jonpry | and every cracker wanted ics source. i wonder what part of internet traffic was taken up by that stuff |
21:32.31 | Cotulla | :D |
21:32.45 | Cotulla | how is L4 port Alexx/ |
21:33.05 | Cotulla | & |
21:33.08 | Cotulla | ? |
21:45.03 | Alex[sp3dev] | Cotulla: not yet started. that's not the primary goal. for now, it is necessary to finish uboot port (add dfu/fastboot) and write some userland software |
22:15.10 | *** join/#htc-linux rajkosto (~rajkosto@wan.rajkonet.info) |
22:23.49 | *** join/#htc-linux rajkosto (~rajkosto@wan.rajkonet.info) |
22:26.36 | *** join/#htc-linux ALoGeNo (~alogeno@unaffiliated/alogeno) |
22:26.39 | *** join/#htc-linux skodde (~skodde@unaffiliated/skodde) |
22:31.03 | *** join/#htc-linux polyrhythmic (~polyrhyth@c-24-17-231-236.hsd1.wa.comcast.net) |
22:53.30 | *** join/#htc-linux furtardo (~mks@nat/yahoo/x-jdrezpftfwknakzu) |
22:57.45 | *** part/#htc-linux Cotulla (~myfakemai@nat100-255-205-109.tvoe.tv) |
23:31.42 | *** join/#htc-linux rajkosto (~rajkosto@wan.rajkonet.info) |
23:41.46 | *** join/#htc-linux rajkosto (~rajkosto@wan.rajkonet.info) |