IRC log for #htc-linux on 20120702

00:01.22*** join/#htc-linux mes (~mes@S0106000ce55186df.cc.shawcable.net)
00:02.21jonpryand i think your dmesg is a red herring
00:02.37jonprycause it actuall finished the memcpy, and assignment and went for the wild ride
00:03.03jonpryjust blew up once it hit restart
00:03.43detulei think it never actually made those assignments
00:04.05detuleor blew up when it tried
00:04.08jonpry*((u32*)reboot_code_buffer + kexec_start_address_offset/4) = image->start;
00:05.20detulei keep getting stuff like [  685.944025] reboot_code_buffer: db095000
00:05.21detule[  685.985655] [d9cc3e5c] *pgd=a031141e(bad)
00:05.38detulewhat is it doing at d9 if buffer is at db?
00:06.08jonprywell it's trying to to flatten the image array thingy
00:06.14jonprybut you gave it a bad pointer
00:06.17jonpryor no pointer
00:06.22detulethis btw is with *((u32*)reboot_code_buffer + ((u32*)&kexec_start_address-(u32*)relocate_new_kernel)) = image->start
00:06.42detuleand the other corresponding vars
00:07.13jonprysomething is just real weird
00:07.24jonprylike it seems to get to cpu_reset
00:07.34jonpryand after that kernel exceptions and stuff should be broke
00:08.06jonpryso i think aux core is enabled
00:08.26detulei am also missing +pr_crit("Past flush_cache_all\n");
00:08.49detuleand Bye for that matter
00:09.13jonpryhmm
00:09.44jonprywell this gets back to my theory about kexec problems with big memory
00:10.22jonprysetup_mm_for_reboot doesn't actually create an identity mapping for anything after 0xc000*
00:10.57jonpryso somehow you need to convince that kernel/kexec stuff to make sure *all* those pages it wants to allocate are located between 0x8000* and 0xc000*
00:11.22jonpryor its going to be fucked
00:12.50jonprybut this is not good
00:12.51jonpry]
00:12.51jonpry[  343.545765] [1:          kexec: 3385] CPU: 1    Tainted: P        W    (3.0.8-ge2ab1bc-dirty #35)
00:13.00jonpryCPU:1 should be offline
00:14.12detulei would think them arm boyz would have figured if they needed to hotplug that cpu
00:14.33jonpryi think your just supposed to do it in userland
00:14.40jonpryor w/ governor
00:14.54jonpryother code generally manages processor power
00:16.45jonprymy modules has to do it manually. although it would make sense to me that the kexec sys call would make some effort to make sure it can succeed
00:23.54detuledisable_nonboot_cpus() ?
00:25.09jonprymight work
00:26.30detulei mean kernel_kexec calls machine_shutdown
00:26.51detulewhich has smp ifdefed code that says smp_send_stop()
00:27.15jonprywell cpu 1 seems to still be online
00:27.49detuleyeah so that seems to be failing
00:29.58jonpryi don't know who did it or why. but my module does the disable_non_boot_cpus() then set_cpu_online, set_cpu_present and set_cpu_possible
00:30.29jonpryto take it down like a tons of bricks
00:31.14jonprybut in the end i'm sure this depends on your platforms implementation of platform_cpu_kill and platform_cpu_die
00:31.24*** join/#htc-linux ALoGeNo (~alogeno@243.Red-217-125-20.staticIP.rima-tde.net)
00:31.25*** join/#htc-linux ALoGeNo (~alogeno@unaffiliated/alogeno)
00:31.27jonprymsm has a tendency to just not implement those
00:32.02detulei mean this send_smp_stop has this delay loop where it keeps polling num_online_cpus()
00:32.14detulesmp_send_stop
00:32.44jonprybut online could mean anything
00:33.16detuleugh
00:33.20jonpryusually it means not scheduled. and in fact it spinning somewhere. maybe on wfi
00:39.16detuleit could be that send_smp_stop is killing 0
00:39.25detuleand perhaps msm8960 can't boot off of 1
00:40.02detulei mean smp_send_stop doesn't touch the cpu it's running on
00:40.47jonpryi'm sure kexec can't work on cpu1
00:41.42detulealright how can i force kexec to run on 0 - > taskset?
00:42.21detulescratch that
00:57.59detulewell forced it onto cpu 0 still no luck
00:58.12detuleperhaps i should back out all the assignments
00:58.12detulehttp://pastebin.com/hhuUYaBq
01:03.46jonpryso its crashing in cache_flush_all()?
01:05.24detulemaybe...i've come to beleve those printk's are misleading :p
01:07.05jonpryi wonder what a111141e is
01:07.11detulethere's an earlier flush_cache that seems to be going through...
01:07.22jonprycotulla would tell us
01:08.38detulei need to stop now otherwise i'll be dreaming about hex numbers like i did last night....thanks for multitasking between msm and omap
01:09.17jonprylol, ok
01:10.12*** join/#htc-linux polyrhythmic (~polyrhyth@c-24-17-231-236.hsd1.wa.comcast.net)
01:22.37*** join/#htc-linux DuperMan (~Duper@46-116-182-18.bb.netvision.net.il)
01:31.50*** join/#htc-linux AstainHellbring (AstainHell@unaffiliated/astainhellbring)
02:20.49*** join/#htc-linux mes (~mes@S0106000ce55186df.cc.shawcable.net)
02:25.30*** join/#htc-linux GNUtoo (~gnutoo@host87-128-dynamic.7-79-r.retail.telecomitalia.it)
02:25.45*** part/#htc-linux GNUtoo (~gnutoo@host87-128-dynamic.7-79-r.retail.telecomitalia.it)
02:41.54*** join/#htc-linux GNUtoo (~gnutoo@host87-128-dynamic.7-79-r.retail.telecomitalia.it)
02:42.00*** part/#htc-linux GNUtoo (~gnutoo@host87-128-dynamic.7-79-r.retail.telecomitalia.it)
02:44.36*** join/#htc-linux constintine (~constinti@216-111-105-244.dia.static.qwest.net)
02:55.53*** join/#htc-linux rajkosto (~rajkosto@wan.rajkonet.info)
03:00.55*** join/#htc-linux ChanServ (ChanServ@services.)
03:00.55*** mode/#htc-linux [+o ChanServ] by cameron.freenode.net
04:02.36*** join/#htc-linux BHSPitMonkey (~stephen@unaffiliated/bhspitmonkey)
04:02.40*** join/#htc-linux LTxda (~anon@c-98-194-107-10.hsd1.tx.comcast.net)
04:02.40*** join/#htc-linux LTxda (~anon@unaffiliated/ltxda)
04:03.00*** join/#htc-linux LTxda (~anon@c-98-194-107-10.hsd1.tx.comcast.net)
04:03.00*** join/#htc-linux LTxda (~anon@unaffiliated/ltxda)
04:03.22*** join/#htc-linux LTxda (~anon@unaffiliated/ltxda)
04:03.40*** join/#htc-linux LTxda (~anon@c-98-194-107-10.hsd1.tx.comcast.net)
04:03.40*** join/#htc-linux LTxda (~anon@unaffiliated/ltxda)
04:04.00*** join/#htc-linux LTxda (~anon@c-98-194-107-10.hsd1.tx.comcast.net)
04:04.01*** join/#htc-linux LTxda (~anon@unaffiliated/ltxda)
04:04.21*** join/#htc-linux LTxda (~anon@unaffiliated/ltxda)
04:04.42*** join/#htc-linux LTxda (~anon@c-98-194-107-10.hsd1.tx.comcast.net)
04:04.42*** join/#htc-linux LTxda (~anon@unaffiliated/ltxda)
04:05.02*** join/#htc-linux LTxda (~anon@c-98-194-107-10.hsd1.tx.comcast.net)
04:05.02*** join/#htc-linux LTxda (~anon@unaffiliated/ltxda)
04:05.20*** join/#htc-linux LTxda (~anon@c-98-194-107-10.hsd1.tx.comcast.net)
04:05.40*** join/#htc-linux LTxda (~anon@c-98-194-107-10.hsd1.tx.comcast.net)
04:05.41*** join/#htc-linux LTxda (~anon@unaffiliated/ltxda)
04:06.00*** join/#htc-linux LTxda (~anon@c-98-194-107-10.hsd1.tx.comcast.net)
04:06.00*** join/#htc-linux LTxda (~anon@unaffiliated/ltxda)
04:06.22*** join/#htc-linux LTxda (~anon@unaffiliated/ltxda)
04:06.42*** join/#htc-linux LTxda (~anon@c-98-194-107-10.hsd1.tx.comcast.net)
04:06.42*** join/#htc-linux LTxda (~anon@unaffiliated/ltxda)
04:07.02*** join/#htc-linux LTxda (~anon@unaffiliated/ltxda)
04:26.41*** join/#htc-linux jianC (4c141154@gateway/web/freenode/ip.76.20.17.84)
04:53.26*** join/#htc-linux rob_w (~bob@ppp-93-104-12-20.dynamic.mnet-online.de)
04:53.27*** join/#htc-linux rob_w (~bob@unaffiliated/rob-w/x-1112029)
04:54.31constintinehttps://dl.dropbox.com/u/2073566/02%20-%20Fearless%20%28Live%29.mp3
05:06.14*** join/#htc-linux mes (~mes@sentry.lazo.ca)
05:10.45*** join/#htc-linux mes (~mes@sentry.lazo.ca)
05:53.42*** join/#htc-linux kiozen (~kiozen@ppp-93-104-74-73.dynamic.mnet-online.de)
05:56.58*** join/#htc-linux kiozen (~kiozen@ppp-93-104-74-73.dynamic.mnet-online.de)
06:19.43*** join/#htc-linux balans2 (~user@82-170-217-205.ip.telfort.nl)
06:32.49*** join/#htc-linux sdub (~sdub@Aircrack-NG/Friend)
06:37.46*** join/#htc-linux eR^zeRa` (~zzeratul@88.103.98.168)
07:03.08*** join/#htc-linux Alex[sp3dev] (~alexander@nat.rnd.stcnet.ru)
07:13.58*** join/#htc-linux ALoGeNo (~alogeno@243.Red-217-125-20.staticIP.rima-tde.net)
07:13.59*** join/#htc-linux ALoGeNo (~alogeno@unaffiliated/alogeno)
07:29.58*** join/#htc-linux kiozen (~kiozen@p578a42db.dip0.t-ipconnect.de)
07:46.47*** part/#htc-linux EdLin (~EdLin@securabit/listener/edlin)
08:01.35*** join/#htc-linux ALoGeNo (~alogeno@unaffiliated/alogeno)
08:35.41*** join/#htc-linux ychavan (ychavan@nat/redhat/x-hoarptxgbzdshifu)
09:09.16*** join/#htc-linux marc1706 (~Marc@phpbb/modifications/marc1706)
09:25.04*** join/#htc-linux constintine (~constinti@216-111-105-244.dia.static.qwest.net)
09:45.11*** join/#htc-linux paulk-desktop (~paulk@lib33-1-82-233-88-171.fbx.proxad.net)
09:56.41*** join/#htc-linux Alex[sp3dev] (~alexander@nat.rnd.stcnet.ru)
09:56.41*** join/#htc-linux CIA-82 (~CIA@cia.atheme.org)
09:56.41*** join/#htc-linux pigeon (~pigeon@eth5284.nsw.adsl.internode.on.net)
10:00.52*** join/#htc-linux polyrhythmic (~polyrhyth@c-24-17-231-236.hsd1.wa.comcast.net)
10:17.24*** join/#htc-linux balans2 (~user@82-170-217-205.ip.telfort.nl)
10:23.16*** join/#htc-linux MethoS- (~clemens@134.102.106.250)
10:38.22*** join/#htc-linux Ondalf (~ondalf@cable-roi-fff8dd00-39.dhcp.inet.fi)
11:38.36*** join/#htc-linux GNUtoo (~gnutoo@host87-128-dynamic.7-79-r.retail.telecomitalia.it)
11:38.38*** join/#htc-linux arif-ali (~arif-ali@81.23.53.226)
11:46.45*** join/#htc-linux helicopter88 (~helicopte@host158-118-dynamic.47-79-r.retail.telecomitalia.it)
11:46.46*** join/#htc-linux ychavan (ychavan@nat/redhat/x-oiufuxbwvuhdkurw)
11:56.08*** join/#htc-linux detule (~detule@unaffiliated/d3tul3)
12:00.35*** join/#htc-linux helicopter88 (~helicopte@host158-118-dynamic.47-79-r.retail.telecomitalia.it)
12:52.57*** join/#htc-linux rajkosto (~rajkosto@cable-94-189-239-212.dynamic.sbb.rs)
13:17.10*** join/#htc-linux NeoMatrixJR (~NeoMatrix@173-18-84-218.client.mchsi.com)
13:24.46*** join/#htc-linux detule (~detule@unaffiliated/d3tul3)
13:25.44*** join/#htc-linux ychavan (ychavan@nat/redhat/x-jnkxixapcwvliuls)
13:25.59*** join/#htc-linux balans2 (~user@82-170-217-205.ip.telfort.nl)
13:45.44*** join/#htc-linux Cotulla (~myfakemai@nat100-255-205-109.tvoe.tv)
13:53.58*** join/#htc-linux l0wbra1n (~l0wbra1n@unaffiliated/l0wbra1n)
15:24.00*** join/#htc-linux conantroutman (~conantrou@cpc5-pert4-2-0-cust205.sgyl.cable.virginmedia.com)
15:43.08*** join/#htc-linux jonpry (~jon@c-24-17-200-206.hsd1.wa.comcast.net)
15:43.19*** join/#htc-linux Alex[sp3dev] (d5551202@gateway/web/freenode/ip.213.85.18.2)
15:50.23*** join/#htc-linux Alex[sp3dev] (d5551202@gateway/web/freenode/ip.213.85.18.2)
16:00.55*** join/#htc-linux ychavan (ychavan@nat/redhat/x-xnwtfjnnvulyqaoh)
16:07.42*** join/#htc-linux NEMESIS| (nembnc@bash0rt.euch.kacknubs.de)
16:11.07*** join/#htc-linux rekoil (~rekoil@c-5fa6e055.04-2-64736c12.cust.bredbandsbolaget.se)
16:12.57*** join/#htc-linux ychavan (ychavan@nat/redhat/x-orxjejdyjjxmyloy)
16:19.18detulejonpry, this is fubar
16:21.42detuleif i read this correctly the kexec binary is responsible for finding a (physical) memory range to copy the new kernel to....it does this by looking at proc/iomem .  I recompiled the binary to include debugging output to see what it passes to the kernel
16:22.30detulethis is what i get http://pastebin.com/g1cViwLe -> it's asking the new kernel to be copied smack on top of the old one
16:22.54detulethis happens before machine_kexec with the mmu ON and all
16:23.18jonpryi thought of another problem
16:24.08jonpryer
16:24.18jonpryyeah i think that segment stuff is fine
16:24.46jonpryit saves that crap in a data structure for relocate_kernel
16:25.15DuperManmozart saus: don giovanni fucked 3,000 spanish chicks
16:25.19DuperMan^fact
16:25.24detulenah i think it does load_normal_segment in kexec.c
16:25.33detuleloading the buffer to the mem address
16:25.37jonpryso like segment[1] will be located at some other physical location. and it will be copied to 0x80208000 after mmu is off
16:26.22jonpryit doesn't look like it quite got that far
16:26.26jonpry0x40168008 is a user pointer
16:27.11detulelike there's this in kexec.c         maddr = segment->mem;
16:27.11detulepage = kimage_alloc_page(image, GFP_HIGHUSER, maddr);
16:27.35DuperMantickle it with a explotive deleted
16:28.10detuleer maybe kimage_alloc_page is more careful than i thought
16:29.02jonpryi still think that you need to make sure those kzalloc's have phys < 0xc*
16:29.32jonprybut it really depends on your implementation of setup_mm_for_reboot
16:29.33DuperMannetchip the testing and just see
16:30.35jonpryif it makes you feel any better, my kernel is all corrupted by the time it gets entered
16:30.50DuperManno
16:31.11DuperMancorrupted in some cool non random way?
16:32.22jonprymaybe. i think it just only gets the first random number of pages
16:32.46DuperMansounds like smart thing u said before
16:45.32jonprydetule, i looked at your sgsiii git repo mm stuff
16:48.36jonpryi think it could work
16:48.48jonpryassuming that it actually hits cpu_reset
16:49.08jonpryand cpu_reset is located below 0xc* phys
16:49.24jonpryand all the caches have actually been turned off
16:49.42jonprythats the one i'm having trouble with
16:55.53*** join/#htc-linux jianC (4c141154@gateway/web/freenode/ip.76.20.17.84)
17:11.58*** join/#htc-linux kiozen (~kiozen@ppp-93-104-74-73.dynamic.mnet-online.de)
17:44.51detulejonpry, would http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=1a4baafa7d203da1cceb302c2df38f0fea1c17a1#patch22 help re: the location of cpu_reset
17:49.28jonpryit would assuming you don't have it
17:50.22jonprysometimes i wonder about this droid3 code
17:52.18jonpryturns out they were pumping the cache control registers with uninitialized poop
17:52.38jonpryno wonder it was "unreliable"
18:00.03*** join/#htc-linux rob_w (~bob@ppp-93-104-12-20.dynamic.mnet-online.de)
18:00.04*** join/#htc-linux rob_w (~bob@unaffiliated/rob-w/x-1112029)
18:08.40detuleno i don't have that commit
18:09.13detuleso what's the problem with setup_mm_for_reboot and addresses > 0xc*
18:13.51*** join/#htc-linux udos012345 (6d50f6a7@gateway/web/freenode/ip.109.80.246.167)
18:14.28jonpryit doesn't setup an identity map for anything >= 0xc*
18:14.45detulewhat's TASK_SIZE
18:14.47jonprybut really the only thing that needs to be in the idmap is cpu_reset
18:14.50jonpry0xc*
18:15.17jonprycause cpu_reset effectively takes out an idmap for all 4gb
18:15.41jonpryso whatever it takes. you need to get cpu_reset down there
18:16.19jonprybut in theory it should be just by virtue of being in .text
18:19.31jonpryi think i just rocked this kexec cache problem
18:19.51jonpryi got like 8 out of 8 boots
18:53.45*** join/#htc-linux AstainHellbring (~AstainHel@unaffiliated/astainhellbring)
18:59.14*** join/#htc-linux skodde (~skodde@unaffiliated/skodde)
19:17.11*** join/#htc-linux Cotulla (~myfakemai@nat100-255-205-109.tvoe.tv)
19:17.47*** join/#htc-linux constintine (~constinti@216-111-105-244.dia.static.qwest.net)
19:40.18*** join/#htc-linux mes (~mes@S0106000ce55186df.cc.shawcable.net)
19:45.27*** join/#htc-linux Alex[sp3dev] (d5551202@gateway/web/freenode/ip.213.85.18.2)
20:49.59detulejonpry, got it working?
20:57.53*** join/#htc-linux mastermerlin (~Adium@p4FEE5A50.dip.t-dialin.net)
21:02.50*** join/#htc-linux arif-ali (~arif-ali@94-192-24-56.zone6.bethere.co.uk)
21:13.45*** join/#htc-linux leviathan (~quassel@2001:470:26:484:6ef0:49ff:fee6:8dca)
21:26.33*** join/#htc-linux apt (~apt@rikers.org)
21:26.33*** topic/#htc-linux is Welcome to the HTC Linux project | Community portal & WiKi http://htc-linux.org | For IRC logs, HaRET & kernel mailing lists etc. see http://htc-linux.org/wiki/index.php?title=Contact | The htc-linux.org project is not affiliated with the HTC Corporation | This channel is for development purposes - Join #htc-linux-chat for offtopic
22:12.11*** join/#htc-linux ALoGeNo (~alogeno@unaffiliated/alogeno)
22:18.51*** join/#htc-linux rajkosto (~rajkosto@wan.rajkonet.info)
22:41.47*** join/#htc-linux AstainHellbring (~AstainHel@unaffiliated/astainhellbring)
23:05.07*** join/#htc-linux ccube (ccube@nx.ccube.de)
23:14.26*** join/#htc-linux BabelO (~wdlxtv@AMontpellier-553-1-176-108.w92-133.abo.wanadoo.fr)
23:34.35*** join/#htc-linux BHSPitMonkey (~stephen@unaffiliated/bhspitmonkey)

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