IRC log for #htc-linux on 20120330

00:10.43*** join/#htc-linux AstainHellbring (AstainHell@unaffiliated/astainhellbring)
00:17.43jonpryhrm. where is this asm/mach/mmc.h
00:20.09detuleproblems?
00:24.12*** join/#htc-linux Alex[sp3dev] (~alexander@178.76.204.11)
00:27.39detulehm the overwhelming majority of my wakeup wake locks are reported as wakeup wake lock: event0-1422
00:27.45detuleevent0 being "h2w headset"
00:29.51jonprythey changed something with includes. fixed now
00:31.29jonprywistilt2 made this new pm.c that supposedly worked great for him. but my power in collapse was like 240ma. i reverted it was back down to 24
00:32.20jonprynot sure if maybe it got reupgraded
00:32.23*** join/#htc-linux AstainHellbring (~AstainHel@unaffiliated/astainhellbring)
00:32.27detuleit did, meaning i broke something
00:32.49detulehow are you measuring it
00:33.31jonpryi did it with a multimeter. but i have not measured lately. this is just from memory
00:33.56detuleoh pm.c currently is mostly stock codeaurora very few hacks in there
00:34.15detulecurrently in 3.2 that is
00:34.47jonprythat may not be a good thing. it seems the amss is quite involved in collapse and if you don't do it a certain way it gets unhappy
00:36.12detulei was having problems with pm.c as it was before once we introduced idle pc....i reverted my changes yesterday and i found the same probelms waiting for me again....these random wakes from susepnd, where it just stays awake for more than a minute doing absolutely nothing
00:36.46jonpryidle suspend isn't really a good idea
00:36.52jonpryer idle pc
00:37.04detulei think i am starting to agree with that
00:37.42jonpryit saves like 2ma when the screen is on using hundreds anyways
00:38.20detulei have a suspcion that these power collapses are also doing some unhealthy things to the radio
00:38.51jonprylike what?
00:39.14jonpryhow old is our drivers/usb now?
00:39.45detulei think you originally got it from .38 CA, at some point i updated the udc driver to CA 3.0
00:39.51detulei didn't touch _otg
00:40.10detulei've been cherrypicking the android gadget stuff from their tree
00:40.34detulelike these reports of gsm users
00:40.42detule(btw the smd patch didn't fix it for them)
00:40.44jonpryi'm not so worried about the _otg driver. just we have been copying over the whole usb core
00:41.14detuleoh yeah, we should probably try to just copy udc and otg and the android stuff this time aorund if possible
00:41.44jonpryi think we need a working kernel before that can be attempted
00:41.54jonprymaybe even upgrade the 3.2 usb to 3.2
00:42.27detuleback to the gsm stuff -> it's like the radio falls asleep at stupid times and is unresponsive to AT commands
00:42.51detulei am seeing these AT< [WCDMA] WAKEUP PDA: U(),T(),R(DS) messages in my radio log -> i have no idea why I would be getting WCDMA prefixed messages
00:43.25jonprywould it be possible for them to run the radio log via dmesg thing
00:43.48jonpryi am not convinced the radio can fail to respond
00:45.31*** join/#htc-linux ALoGeNo (~alogeno@unaffiliated/alogeno)
00:45.53*** join/#htc-linux |lippa| (~lippa@CPE-121-220-44-147.lnse2.win.bigpond.net.au)
00:46.01detuleyeah i guess we can try that kernel dump
00:46.15jonpryalso the build fingerprint is weird
00:46.24jonpryshouldn't it be a12d2827cd6f8d27d61879cd2b9e3da9c93a5feb
00:47.52jonpryfor that matter i can't even find a 3c01b
00:48.26detuleit is
00:48.31detuleignore the "g" i guess
00:50.01detuleuh oh
00:50.07detulei see what you are saying
00:50.38detulehe's on a kernel i sent him -> it had a full revert of hyc's patch
00:51.02detule(all channels not just data)
00:51.16jonpryi think my patch is more of a problem than the hyc one
00:52.06jonprythat whole ldisc short circuiting thing was kanged from a driver that only used N_PPP
00:52.33detulebut here's the thing your original patch is in .27
00:52.33jonpryi never expected it to work on the raw channels but it seemed to so i never made it channel specific
00:52.40detuleand hyc says everything is peachy over there
00:52.47jonpryyeah its timing sensitive
00:55.39*** join/#htc-linux AstainW00T (~AstainHel@unaffiliated/astainhellbring)
00:56.50*** join/#htc-linux ychavan (ychavan@nat/redhat/x-xwmhzlhbjnzfvwwi)
00:57.17*** join/#htc-linux infernix (nix@unaffiliated/infernix)
00:57.22jonprydid codahighland try the latest autobuild?
00:58.46*** join/#htc-linux ahigerd (~ahigerd@libqxt/developer/ahigerd)
00:58.51ahigerdsneezes
00:59.31detulejonpry, meet ahigerd = codahighland
00:59.40ahigerdwaves
00:59.50jonprywe were just talking about you
00:59.53ahigerdSo I heard
01:00.22detuleso i've been feeding ahigerd kernels but perhaps i should've just had him try the autobuild
01:00.41jonpryyeah a12d2827cd6f8d27d61879cd2b9e3da9c93a5feb is the bees knees
01:01.57detuleyeah the kernel there's more of a difference between the kernel i gave you and the one in the autobuild than i originally thought
01:02.26ahigerdWhoops
01:02.37ahigerdDoes that include the tasklet change?
01:02.49detuledisregard that kernel for now
01:02.54ahigerdsnrks
01:02.56ahigerdI just got that one booted XD
01:03.02detulekexec ftw
01:03.04ahigerdYup
01:03.10ahigerdBut I had to reboot first to make adb wake up
01:03.18jonprytasklet?
01:03.26detulei changed the queues in tty to tasklets
01:03.42detulealso changed the wakelocks to IDLE
01:03.45jonprybold
01:03.57jonpryps ax | grep smd?
01:04.35detuleeh?
01:04.39ahigerdpppd on smd1
01:04.46ahigerdThat's it
01:05.08jonprytasklets show up is ps no? no real purpose
01:05.42detulewell i thought there was less latency
01:05.51detulealso they don't sleep
01:06.04jonpryhrm
01:06.22jonprythis is for the rescheduling on slab failure?
01:06.45ahigerdHe was saying something about power collapse interfering with the buffers or something like that, and thinking tasklets would prevent that
01:06.46detulethe entire smd_read queue business
01:06.55ahigerddoesn't remember exactly
01:07.09detulechanging the wake locks to idle had more to do with the PC business
01:09.20jonprythis whole business with writing to the tty layers internal data structures is highly risky and suspect
01:09.47ahigerdPC business?
01:09.52detulepower collapse
01:09.54ahigerdOh yeah
01:11.33jonprycan you reproduce these problems quickly?
01:11.53jonpryon my phone it was almost constant. usually could only get one phonecall in before it freaked
01:11.54ahigerdSadly no
01:12.18ahigerdFor me it's maybe one or two times a week, seems signal-related
01:12.34ahigerdRarely happens at home, happens more often when I'm out
01:13.43*** join/#htc-linux whiteE (~whiteE@66.239.12.42.ptr.us.xo.net)
01:14.07*** join/#htc-linux AstainHellbring (~AstainHel@unaffiliated/astainhellbring)
01:14.07jonpryimho that autobuild kernel will fix it right up
01:16.27ahigerdorly
01:16.58ahigerdpulls it down
01:18.08ahigerdkexecs
01:18.37detuleyou should also probably go to the stock ril
01:18.43ahigerdk
01:18.55ahigerdI'll make that switch after it finishes booting
01:19.13detuleit might help manifest any issues sooner
01:19.19ahigerdFair enough
01:20.50jonprywhat were the change to drivers/base/power/Makefile?
01:22.16*** join/#htc-linux mitsutaka (~mitsutaka@219.143.36.82)
01:22.55detulehttp://pastebin.com/ubJUuU41
01:23.28jonpry:p i have that. what does it do?
01:24.26detuleyou put it there
01:24.41detulefor one i think we are not compiling clock_ops
01:25.38jonpryprobably need to ask myself next time i'm around
01:26.04detuleprobably commenting out clock_ops is the only thing that's needed
01:27.20jonpryit sort of builds. won't link yet
01:33.39*** join/#htc-linux mitsutak_ (~mitsutaka@219.143.36.82)
01:36.04*** join/#htc-linux bitrot (~rajkosto@2001:470:d76b:da7a:fd2f:5462:fff6:41c1)
01:42.59*** join/#htc-linux furtardo (~mks@nat/yahoo/x-muiylpvulcmcyeqk)
01:47.39*** join/#htc-linux AstainHellbring (AstainHell@unaffiliated/astainhellbring)
02:01.39jonpryhrm what to do about drivers/staging
02:02.57*** join/#htc-linux AstainHellbring (AstainHell@unaffiliated/astainhellbring)
02:03.47detulenot much has changed right?
02:04.12detulei mean we should be able to use staging/android from 3.3
02:06.25jonprynot sure haven't looked at it. there are lots of different pmem's floating about
02:06.36detuleoh yeah we would need our own pmem
02:07.59detulethere's some changes to their alarm driver (they moved it from driver/rtc to staging/android) but i've backported that to 3.2 so it should work
02:13.21jonpryi think if this thing had pmem it would link and run
02:14.18jonprydur. how do i removed files i accidentally committed
02:17.33jonpryk situation rectified
02:18.28jonprythe goods are pushed
02:19.23jonpryhrm. our ashmem is in /mm
02:23.17jonprythat was easier than i thought :p
02:25.48jonpryhrm no vibe
02:33.03*** join/#htc-linux jonpry (~jon@adsl-98-85-196-230.mco.bellsouth.net)
02:46.58*** join/#htc-linux jonpry (~jon@adsl-98-85-196-230.mco.bellsouth.net)
02:53.47*** join/#htc-linux AstainHellbring (AstainHell@unaffiliated/astainhellbring)
03:07.11*** join/#htc-linux AstainHellbring (AstainHell@unaffiliated/astainhellbring)
03:30.51*** join/#htc-linux DuperMa (~Duper@93-173-141-174.bb.netvision.net.il)
04:15.25jonpryhmm. seems we are not supposed to be iomapping at the end to vmalloc anymore
04:55.12*** join/#htc-linux friehmaen (~fm@fm.xers.de)
04:55.51*** join/#htc-linux Rob2222 (~Miranda@p4FFD3CAC.dip.t-dialin.net)
04:59.37*** join/#htc-linux DuperMan (~Duper@93-173-141-174.bb.netvision.net.il)
05:08.50*** join/#htc-linux kiozen (~kiozen@ppp-93-104-66-44.dynamic.mnet-online.de)
05:09.36*** join/#htc-linux lamikr (lamikr@nat/nokia/x-opsunpjijbqrveuy)
05:35.42*** join/#htc-linux friehmaen (~fm@fm.xers.de)
05:51.40*** join/#htc-linux G4y (~heaheahah@77.106.182.232)
05:51.44*** join/#htc-linux jonpry (~jon@adsl-98-85-196-230.mco.bellsouth.net)
05:56.51*** join/#htc-linux DuperMan (~Duper@93-173-13-4.bb.netvision.net.il)
06:27.19*** join/#htc-linux kiozen (~kiozen@p578a42db.dip0.t-ipconnect.de)
06:33.00*** join/#htc-linux LordDeath (~LordDeath@cable-81-173-164-174.netcologne.de)
06:50.16*** join/#htc-linux balans2 (~user@82-170-217-205.ip.telfort.nl)
07:35.31*** join/#htc-linux pbaxter (~pbaxter@host254-13-dynamic.244-95-r.retail.telecomitalia.it)
07:39.00*** join/#htc-linux gauner1986 (~Miranda@ip-109-91-241-106.unitymediagroup.de)
07:57.33*** join/#htc-linux polyrhythmic (~polyrhyth@c-71-197-239-27.hsd1.wa.comcast.net)
08:05.05*** join/#htc-linux Rob2222 (~Miranda@p4FFD16E0.dip.t-dialin.net)
08:07.17*** join/#htc-linux MacDrunk (~marper@201.165.119.167)
08:15.21*** join/#htc-linux swc|666 (~goldbond@Aircrack-NG/Friend)
08:15.22*** join/#htc-linux ychavan (ychavan@nat/redhat/x-gnjkfdesveltdmtm)
09:39.55*** join/#htc-linux Ondalf (~ondalf@cable-roi-fe98dc00-121.dhcp.inet.fi)
09:49.50*** join/#htc-linux MethoS- (~clemens@134.102.106.250)
10:09.10*** part/#htc-linux MacDrunk (~marper@201.165.119.167)
10:53.29*** join/#htc-linux ychavan (ychavan@nat/redhat/x-pebihdvefgxbshxm)
11:08.33*** join/#htc-linux jonpry (~jon@adsl-98-85-196-230.mco.bellsouth.net)
11:10.43*** join/#htc-linux zmc (~zmc@lurian.net)
11:19.36*** join/#htc-linux GNUtoo (~gnutoo@host149-73-dynamic.56-82-r.retail.telecomitalia.it)
11:31.02*** join/#htc-linux jonpry (~jon@adsl-98-85-196-230.mco.bellsouth.net)
11:43.19*** join/#htc-linux Alex[sp3dev] (~alexander@178.76.204.11)
11:53.15*** join/#htc-linux jonpry (~jon@adsl-98-85-196-230.mco.bellsouth.net)
12:07.05*** join/#htc-linux G4y (~heaheahah@160.8.202.84.customer.cdi.no)
12:31.41*** join/#htc-linux yuuki (~yuuki@dsbg-d9bb1b40.pool.mediaWays.net)
12:47.44*** join/#htc-linux AstainHellbring (AstainHell@unaffiliated/astainhellbring)
13:11.57*** join/#htc-linux milaq|afk (~milaq@lb-info.de)
13:15.08*** join/#htc-linux ccube (ccube@nx.ccube.de)
13:19.31*** join/#htc-linux balans2 (~user@82-170-217-205.ip.telfort.nl)
13:21.58*** join/#htc-linux detule (~detule@unaffiliated/d3tul3)
13:30.08jonpryhi detule
13:30.57detulehey
13:31.06detulevmalloc whoa
13:31.39jonpryyeah big trouble
13:32.25jonprywriting has been on the wall for awhile so this work can be done on 3.2
13:32.44detulewait what have they done
13:33.07jonpryfor one your not allowed to define VMALLOC_END anymore
13:33.14jonpryjust hard coded to 0xff000000
13:33.26jonprywhich is right before the coherent dma segment
13:34.12jonprybeyond that i'm not totally sure of the ramifications
13:34.29detuleweren't we defining it at 0xf8 or whatever
13:34.32jonpryall arm soc's now have there io area mapped at 0xe0000000
13:34.41jonpryyes we were
13:35.07jonpryi'm not sure what region that is in, but i suspect that ioremap doesn't work at all
13:35.21detuleso they are forcing us to use more vmalloc?
13:35.36*** join/#htc-linux Rob2222 (~Miranda@p4FFD16E0.dip.t-dialin.net)
13:44.31detulejonpry can we do something like this commit for us "ARM: move VMALLOC_END down temporarily for shmobile"
13:45.47detuleoh all that does is an undef and a define
13:50.16detuleso their commit log seems to indicate they want us to iomap within the vmalloc region
13:51.21*** join/#htc-linux jonpry (~jon@adsl-98-85-196-230.mco.bellsouth.net)
13:51.38detule<detule> so their commit log seems to indicate they want us to iomap within the vmalloc region
13:53.10jonpryits worth a try. seems to be what is happening in mach-msm
13:53.24jonprycheckout arm/mm/mmu.c:iotable_init
13:53.43detuleyeah that's what i am looking at
13:53.54jonprythis is how the other platforms are doing it
13:54.00detulethough if that's available for vmalloc what's to say we won't grab it by mistake?
13:54.15jonpry?
13:55.45detulenevermind i see we are setting vm_ioremap flag
13:56.40detulewhich i guess make sures we can't trample over that with vmalloc calls
13:57.17jonpryi can't tell if iotable_init and ioremap have the same effect
13:57.41jonpryits possible that iotable_init way notifies the allocator somehow
13:57.51jonprylike the call to early_alloc
14:03.25detuleso er just take out msm_map_common_io in io.c?
14:05.46jonprywe are talking 3.2?
14:06.50jonpryi think the first thing is to set vmalloc_end to the new address and rebase all the mappings on to 0xe*
14:07.28*** join/#htc-linux LargePrime (~LargePrim@70-8-143-167.pools.spcsdns.net)
14:08.09jonprydur i didn't realize io.c called iotable_init
14:08.21detuleso er help me understand....i thought we can leave all our mappings to 0xf8 and above in this new scheme....but now they will be inside the vmalloc region
14:09.03detuleand instead of us mapping them in io.c all this is doing is letting the mapping be done in mmu.c inside the vmalloc region
14:10.57detuledur someone still has to call iotable_init
14:11.24jonpry3.2 and 3.3 iotable_init are way different
14:12.16jonpryi'm not sure why they want the iomappings at the bottom of vmalloc
14:13.06detulei mean different in that all it does is creates a vm struct for each entry
14:21.46jonprysomehow i think vmalloc starts at 0xf*
14:22.21jonpry"the default is 240m."
14:25.33detulei think in 3.3 they just gave us the option of defining vmalloc_start
14:25.38detulei think the default hasn't changed
14:27.18jonpryin vanilla 3.2 they used end==0xd* with all io starting at 0xe*
14:27.44jonpryand stuff apparently still worked when end became 0xff
14:30.34jonpryi like that idea for some reason
14:35.37*** join/#htc-linux AstainHellbring (~AstainHel@unaffiliated/astainhellbring)
14:51.24*** join/#htc-linux jonpry (~jon@adsl-98-85-196-230.mco.bellsouth.net)
14:52.05jonprychanging everything to 0xe didn't help
14:53.00detuledo you have any ramconsole output after the failed boot
14:53.29detulei mean i am sure this business is no good but could it be failing for other reasons as well
14:54.22jonpryno ramconsole
14:54.35jonprythat has lead me to believe its a memory mapping problem
14:55.10jonpryother possibilities are atag problems or segfault somewhere
15:00.31detulewell one thing we could do is to revert the vmalloc patch in 3.3 to pin down if that's the problem
15:02.16jonpryyeah. there is some interrupt stuff going on too. but i think ramconsole comes up before interrupt
15:04.20jonprythere is this strange build error about ARCH_MSM not being defined that has be worried
15:09.22*** join/#htc-linux Bry8Star (~Bry8Star@gateway/tor-sasl/bry8star)
15:10.21detulethey've also done a number on ioremap
15:22.10*** join/#htc-linux rpierce99 (~rpierce99@96-42-107-19.dhcp.stcd.mn.charter.com)
15:25.28*** join/#htc-linux LordDeath (~LordDeath@cable-81-173-164-174.netcologne.de)
15:37.30jonpryhttp://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=b12e9ba59c83f7df846602b201b64e4ddf28ccee
15:38.55detulelol yeah that might be important
15:50.45*** join/#htc-linux rob_w (~bob@ppp-88-217-92-252.dynamic.mnet-online.de)
15:50.45*** join/#htc-linux rob_w (~bob@unaffiliated/rob-w/x-1112029)
15:50.51detulethis as well? http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/088009.html
16:05.32*** join/#htc-linux helicopter88 (~helicopte@95.234.35.188)
16:10.04jonpryi'm guessing those made it into 3.3
16:13.39*** join/#htc-linux jzma (5278306c@gateway/web/freenode/ip.82.120.48.108)
16:34.58*** join/#htc-linux Bry8Star (~Bry8Star@gateway/tor-sasl/bry8star)
16:35.59*** join/#htc-linux kiozen (~kiozen@ppp-93-104-66-44.dynamic.mnet-online.de)
16:53.22*** join/#htc-linux mitsutaka (~mitsutaka@123.116.125.0)
16:56.50jonpryarch/arm/mach-msm/board-htcrhodium.c:1398:8: error: 'arch_ioremap_caller' undeclared (first use in this function)
16:57.42*** join/#htc-linux CptAJ (AJ@190.74.22.95)
17:00.59jonpryguess we did need that other patch
17:06.05*** join/#htc-linux ahigerd (~ahigerd@173.218.156.102)
17:06.05*** join/#htc-linux ahigerd (~ahigerd@libqxt/developer/ahigerd)
17:10.27jonpryahigerd any trouble with the new kernel?
17:10.54ahigerdI dunno, I've been sleeping most of the time since I installed it
17:11.02ahigerdHaven't made any calls
17:11.19jonpryah
17:11.20arrrghhhyou don't sleepcall
17:11.26ahigerdI try not to
17:11.33arrrghhhthat was one of the requirements of running a kernel from jonpry
17:11.55jonpryhave to put that in the readme
17:12.29arrrghhhlol
17:18.50detuleyeah that patch didn't help it boot over here
17:20.24jonpryouch
17:20.48jonprymaybe we need a more powerful debugging method
17:24.32*** join/#htc-linux paulk-desktop (~paulk@lib33-1-82-233-88-171.fbx.proxad.net)
17:44.10jonpryis there a region of ebi/ebin that would work for ramconsole?
17:52.03*** join/#htc-linux GNUtoo (~gnutoo@host149-73-dynamic.56-82-r.retail.telecomitalia.it)
18:09.43*** join/#htc-linux whitekidney (~wkl0l@141.0.136.22)
18:09.47whitekidneydamn autojoin not working
18:22.00jonpryi got it to print something after decompress
18:25.10*** join/#htc-linux Rob2223 (~Miranda@p4FFD1EF3.dip.t-dialin.net)
18:25.51*** join/#htc-linux Cthulhu (77eb360e@gateway/web/freenode/ip.119.235.54.14)
18:37.15jonprydetule is your assembler getting better?
18:43.48*** join/#htc-linux Rob2222 (~Miranda@p4FFD3212.dip.t-dialin.net)
18:53.39detulemy assembler is rudimentary at best
18:54.03detulewhat printed out?
18:54.16detuleand what did you do to get it that far
19:02.24*** join/#htc-linux Rob2223 (~Miranda@p4FFD0F2C.dip.t-dialin.net)
19:02.50jonpryhttp://pastebin.com/7EuZUxc5
19:03.03jonpryi'm just writing a,b,c into ramconsole area
19:03.32jonpryc hasn't happened yet. its the tricky one
19:04.55jonprybut once it does. this could be a super ultimate tool
19:06.31jonpryhrm c worked
19:06.35ahigerdWhat are you guys up to?
19:06.54jonprytrying to figure out why kernel 3.3 won't boot
19:10.57helicopter883.2 boots right?
19:11.21arrrghhhlol
19:11.26arrrghhh3.2's worked for a while man
19:11.41arrrghhhprobably before you got that battery sucking device
19:12.16arrrghhh(on RHOD mind you)
19:12.33arrrghhhi don't think .39+ works on anything but RHOD as far as our livery of devices goes
19:12.49arrrghhh.35 probably works on a few because of alex and michael
19:13.07helicopter88I missed a ","
19:13.22arrrghhhwhut
19:13.29helicopter88what have they changed between 3.2 and 3.3 ?
19:14.17jonprynothing obvious
19:14.35jonpryi think either the mmu is fubar or irq
19:15.10detuleif it got as far as irq would we see anything in ramconsole?
19:15.20helicopter88arrrghhh: it lasts 2 days with moderate usage
19:16.59jonprydetule, not sure
19:17.00*** join/#htc-linux ali1234 (~ajbuxton@s15821883.onlinehome-server.info)
19:21.04detulemach-msm/irq.c hasn't changed on korg in over a year
19:22.20jonpryyeah they are pushing for this new thing that is common to all socs
19:23.50jonprythis thing i am doing with the mmu is actually pretty cool
19:24.16jonpryit could be refactored with minimal effort to give debug_ll level of functionality via smi
19:26.17jonprysweet we have entry into c code at start_kernel()
19:29.26*** join/#htc-linux furtardo (~mks@nat/yahoo/x-iawihgkcgyqzyqlo)
19:36.04*** join/#htc-linux LargePrime (~LargePrim@173-108-144-110.pools.spcsdns.net)
19:44.22*** join/#htc-linux swc|666 (~goldbond@Aircrack-NG/Friend)
19:45.00*** join/#htc-linux detule (~detule@unaffiliated/d3tul3)
19:54.04jonprydeath is in setup_arch
19:54.45jonpryor maybe not
20:01.37*** join/#htc-linux leviathan (~quassel@2001:470:26:484:6ef0:49ff:fee6:8dca)
20:13.52*** join/#htc-linux kiozen (~kiozen@ppp-93-104-66-44.dynamic.mnet-online.de)
20:27.44*** join/#htc-linux ahigerd (~ahigerd@173.218.156.102)
20:27.57*** join/#htc-linux ahigerd (~ahigerd@libqxt/developer/ahigerd)
20:28.24*** join/#htc-linux jonpry (~jon@adsl-98-85-196-230.mco.bellsouth.net)
20:36.41jonpryappears to be hanging in iotable_init
20:40.56detuleearly_alloc_alligned?
20:41.52*** join/#htc-linux mastermerlin (~Adium@p4FEE4D79.dip.t-dialin.net)
20:43.06jonprycould be. i'm not sure how many more add traces and reboot i can take
20:45.25jonprystupid usb cable keeps crashing my laptop
20:48.03*** join/#htc-linux mastermerlin (~Adium@p4FEE4D79.dip.t-dialin.net)
20:55.25detuleMSM_SHARED_RAM_BASE that's IOMEM(0xE0100000)
20:56.14detuleand that last entry in msm_io_desc is at that virt
20:56.43detuleis that under vmalloc_start?
20:58.20jonpry?
20:58.21jonpry#define MSM_SHARED_RAM_BASE   IOMEM(0xF8100000)
20:59.16jonpryi went back to 0xf8 btw
21:00.05detuleugh looking at the wrong branch
21:01.15jonpryinterested in doing any tracing?
21:02.30detulesure, but my usb cable situation is worse than yours....at least until i get home later tonight
21:03.16detulei need to have an elaborate setup (often involves the phone hanging by the usb cable) for it to register
21:03.36jonprylol
21:03.48jonpryhttp://pastebin.com/HwpHu5Fm
21:04.17jonpryonce it gets going it just phys=virt for smi
21:04.26jonpryso you do for example *((unsigned char*)0x8e0025) = 'j'
21:05.44CptAJdetule,  My usb cable is being held together by medical tape >_>
21:06.28detuleCptAJ, did you figure out your screen issues on the whitestone
21:07.30CptAJI used haret to watch the tssc registers and logged a couple of taps with the stylus. I'm trying to compare that to the driver source and see exactly where it is going wrong.
21:07.31detulejonpry, so how far do you get with the trace
21:07.49jonpryi know that it stops in msm_map_common_io
21:08.02CptAJI'm slowly trying to wrap my head around it
21:08.06detuleCptAJ, after you left last time someone mentioned it could be toolchain issues
21:08.12detulewhich toolchain are you using?
21:08.19CptAJlatest from the site
21:08.25jonpryuh oh
21:08.28detuleprobably need to downgrade
21:08.30CptAJwhich one is the prefered one?
21:08.33detule2010 q3
21:08.41CptAJI'll try that. thanks
21:09.50detulejonpry, so you see 'd' but no 'e' ?
21:11.52jonprycorrect
21:12.04jonpryi did some strange modulo 4 deal
21:12.21jonpryso it prints AaaaBbbbCcccDdddEee Ff
21:14.52detulei don't see your capital A or B
21:16.18jonpryassembler
21:16.39jonpry+               mov     r0, #0x8e0000
21:16.39jonpry+               mov     r1, #0x41
21:17.21detuleimagine that 0x41
21:17.49detulethanks
21:18.02jonpryno problem
21:18.25detuleyou're right this is pretty cool
21:19.37jonpryit should be possible to change debug-macro.S to use it
21:35.55detulei gotta go, i have a feeling you'll have it figured out by the time i get a chance to run these traces...pretty cool eitherway
23:24.20*** join/#htc-linux LargePrime (~LargePrim@184.244.158.129)
23:25.44*** join/#htc-linux Alex[sp3dev] (~alexander@178.76.204.11)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.