00:01.22 | *** join/#htc-linux mes (~mes@S0106000ce55186df.cc.shawcable.net) |
00:02.21 | jonpry | and i think your dmesg is a red herring |
00:02.37 | jonpry | cause it actuall finished the memcpy, and assignment and went for the wild ride |
00:03.03 | jonpry | just blew up once it hit restart |
00:03.43 | detule | i think it never actually made those assignments |
00:04.05 | detule | or blew up when it tried |
00:04.08 | jonpry | *((u32*)reboot_code_buffer + kexec_start_address_offset/4) = image->start; |
00:05.20 | detule | i keep getting stuff like [ 685.944025] reboot_code_buffer: db095000 |
00:05.21 | detule | [ 685.985655] [d9cc3e5c] *pgd=a031141e(bad) |
00:05.38 | detule | what is it doing at d9 if buffer is at db? |
00:06.08 | jonpry | well it's trying to to flatten the image array thingy |
00:06.14 | jonpry | but you gave it a bad pointer |
00:06.17 | jonpry | or no pointer |
00:06.22 | detule | this btw is with *((u32*)reboot_code_buffer + ((u32*)&kexec_start_address-(u32*)relocate_new_kernel)) = image->start |
00:06.42 | detule | and the other corresponding vars |
00:07.13 | jonpry | something is just real weird |
00:07.24 | jonpry | like it seems to get to cpu_reset |
00:07.34 | jonpry | and after that kernel exceptions and stuff should be broke |
00:08.06 | jonpry | so i think aux core is enabled |
00:08.26 | detule | i am also missing +pr_crit("Past flush_cache_all\n"); |
00:08.49 | detule | and Bye for that matter |
00:09.13 | jonpry | hmm |
00:09.44 | jonpry | well this gets back to my theory about kexec problems with big memory |
00:10.22 | jonpry | setup_mm_for_reboot doesn't actually create an identity mapping for anything after 0xc000* |
00:10.57 | jonpry | so 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.22 | jonpry | or its going to be fucked |
00:12.50 | jonpry | but this is not good |
00:12.51 | jonpry | ] |
00:12.51 | jonpry | [ 343.545765] [1: kexec: 3385] CPU: 1 Tainted: P W (3.0.8-ge2ab1bc-dirty #35) |
00:13.00 | jonpry | CPU:1 should be offline |
00:14.12 | detule | i would think them arm boyz would have figured if they needed to hotplug that cpu |
00:14.33 | jonpry | i think your just supposed to do it in userland |
00:14.40 | jonpry | or w/ governor |
00:14.54 | jonpry | other code generally manages processor power |
00:16.45 | jonpry | my 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.54 | detule | disable_nonboot_cpus() ? |
00:25.09 | jonpry | might work |
00:26.30 | detule | i mean kernel_kexec calls machine_shutdown |
00:26.51 | detule | which has smp ifdefed code that says smp_send_stop() |
00:27.15 | jonpry | well cpu 1 seems to still be online |
00:27.49 | detule | yeah so that seems to be failing |
00:29.58 | jonpry | i 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.29 | jonpry | to take it down like a tons of bricks |
00:31.14 | jonpry | but 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.27 | jonpry | msm has a tendency to just not implement those |
00:32.02 | detule | i mean this send_smp_stop has this delay loop where it keeps polling num_online_cpus() |
00:32.14 | detule | smp_send_stop |
00:32.44 | jonpry | but online could mean anything |
00:33.16 | detule | ugh |
00:33.20 | jonpry | usually it means not scheduled. and in fact it spinning somewhere. maybe on wfi |
00:39.16 | detule | it could be that send_smp_stop is killing 0 |
00:39.25 | detule | and perhaps msm8960 can't boot off of 1 |
00:40.02 | detule | i mean smp_send_stop doesn't touch the cpu it's running on |
00:40.47 | jonpry | i'm sure kexec can't work on cpu1 |
00:41.42 | detule | alright how can i force kexec to run on 0 - > taskset? |
00:42.21 | detule | scratch that |
00:57.59 | detule | well forced it onto cpu 0 still no luck |
00:58.12 | detule | perhaps i should back out all the assignments |
00:58.12 | detule | http://pastebin.com/hhuUYaBq |
01:03.46 | jonpry | so its crashing in cache_flush_all()? |
01:05.24 | detule | maybe...i've come to beleve those printk's are misleading :p |
01:07.05 | jonpry | i wonder what a111141e is |
01:07.11 | detule | there's an earlier flush_cache that seems to be going through... |
01:07.22 | jonpry | cotulla would tell us |
01:08.38 | detule | i 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.17 | jonpry | lol, 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.31 | constintine | https://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.18 | detule | jonpry, this is fubar |
16:21.42 | detule | if 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.30 | detule | this 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.54 | detule | this happens before machine_kexec with the mmu ON and all |
16:23.18 | jonpry | i thought of another problem |
16:24.08 | jonpry | er |
16:24.18 | jonpry | yeah i think that segment stuff is fine |
16:24.46 | jonpry | it saves that crap in a data structure for relocate_kernel |
16:25.15 | DuperMan | mozart saus: don giovanni fucked 3,000 spanish chicks |
16:25.19 | DuperMan | ^fact |
16:25.24 | detule | nah i think it does load_normal_segment in kexec.c |
16:25.33 | detule | loading the buffer to the mem address |
16:25.37 | jonpry | so like segment[1] will be located at some other physical location. and it will be copied to 0x80208000 after mmu is off |
16:26.22 | jonpry | it doesn't look like it quite got that far |
16:26.26 | jonpry | 0x40168008 is a user pointer |
16:27.11 | detule | like there's this in kexec.c maddr = segment->mem; |
16:27.11 | detule | page = kimage_alloc_page(image, GFP_HIGHUSER, maddr); |
16:27.35 | DuperMan | tickle it with a explotive deleted |
16:28.10 | detule | er maybe kimage_alloc_page is more careful than i thought |
16:29.02 | jonpry | i still think that you need to make sure those kzalloc's have phys < 0xc* |
16:29.32 | jonpry | but it really depends on your implementation of setup_mm_for_reboot |
16:29.33 | DuperMan | netchip the testing and just see |
16:30.35 | jonpry | if it makes you feel any better, my kernel is all corrupted by the time it gets entered |
16:30.50 | DuperMan | no |
16:31.11 | DuperMan | corrupted in some cool non random way? |
16:32.22 | jonpry | maybe. i think it just only gets the first random number of pages |
16:32.46 | DuperMan | sounds like smart thing u said before |
16:45.32 | jonpry | detule, i looked at your sgsiii git repo mm stuff |
16:48.36 | jonpry | i think it could work |
16:48.48 | jonpry | assuming that it actually hits cpu_reset |
16:49.08 | jonpry | and cpu_reset is located below 0xc* phys |
16:49.24 | jonpry | and all the caches have actually been turned off |
16:49.42 | jonpry | thats 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.51 | detule | jonpry, 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.28 | jonpry | it would assuming you don't have it |
17:50.22 | jonpry | sometimes i wonder about this droid3 code |
17:52.18 | jonpry | turns out they were pumping the cache control registers with uninitialized poop |
17:52.38 | jonpry | no 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.40 | detule | no i don't have that commit |
18:09.13 | detule | so 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.28 | jonpry | it doesn't setup an identity map for anything >= 0xc* |
18:14.45 | detule | what's TASK_SIZE |
18:14.47 | jonpry | but really the only thing that needs to be in the idmap is cpu_reset |
18:14.50 | jonpry | 0xc* |
18:15.17 | jonpry | cause cpu_reset effectively takes out an idmap for all 4gb |
18:15.41 | jonpry | so whatever it takes. you need to get cpu_reset down there |
18:16.19 | jonpry | but in theory it should be just by virtue of being in .text |
18:19.31 | jonpry | i think i just rocked this kexec cache problem |
18:19.51 | jonpry | i 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.59 | detule | jonpry, 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) |