tag:blogger.com,1999:blog-6469704299235308349.post4751606153901925808..comments2024-03-28T15:50:13.644+11:00Comments on -ck hacking: BFS 461, linux-3.19-ck1ckhttp://www.blogger.com/profile/02904761195451530213noreply@blogger.comBlogger22125tag:blogger.com,1999:blog-6469704299235308349.post-22160675424993908522015-04-22T21:56:13.410+10:002015-04-22T21:56:13.410+10:00Not sure if this applied to my early panic in cpu_...Not sure if this applied to my early panic in cpu_startup_entry when running -ck built as uniprocesser; I saw that this patch is in linux 4.0, but I still get the panic.jwh7https://www.blogger.com/profile/09659185315567537391noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-78051680710199950242015-04-16T08:41:01.105+10:002015-04-16T08:41:01.105+10:00This sync-up patch effectively incorporates the ch...This sync-up patch effectively incorporates the changes to cfs into BFS, that kernelOfTruth had pointed to already some weeks earlier. Ported parts of this patch already have been working very well on here with 3.19.2..3 for many weeks now. The newly added chunks by Alfred (@3.19.4 applied if needed or not) don't show any issues, so far.<br /><br />@CK: Could be a bit too trivial for you to publish your new BFS/CK patchset. ;-)<br /><br />Best regards, <br />Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-80702733426634026282015-04-15T23:06:57.678+10:002015-04-15T23:06:57.678+10:00Just upload my linux4.0 syncup patch for BFS0461 a...Just upload my linux4.0 syncup patch for BFS0461 at https://bitbucket.org/alfredchen/linux-gc/downloads/bfs0461_linux4.0_syncup.patch <br /><br />Please be noticed that extract __schedule() and sched_submit_work() from schedule() used to cause some issues when ck release similar changes for BFS in 3.18 release, then it is reverted in 0460 for 3.19. Hopefully these are fixed in upstream kernel changes.<br /><br />BR AlfredAlfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-50579883168192043502015-03-27T11:44:33.374+11:002015-03-27T11:44:33.374+11:00FYI:
[PATCHv2] mm/slub: fix lockups on PREEMPT &a...FYI:<br /><br />[PATCHv2] mm/slub: fix lockups on PREEMPT && !SMP kernels<br />http://marc.info/?l=linux-kernel&m=142659459326875&w=2<br /><br />Just FYI I've hit this problem on x86. I think I used gcc 4.7 and 4.8, and<br />maybe also 4.6 earlier.<br /><br />Here's the diff in asm after applying the fix:<br /><br /> 240a: 0f 85 ce 00 00 00 jne 24de <br /> 2410: 89 75 f0 mov %esi,-0x10(%ebp)<br /> 2413: 8b 07 mov (%edi),%eax<br />- 2415: 8b 50 04 mov 0x4(%eax),%edx<br />- 2418: 8b 48 04 mov 0x4(%eax),%ecx<br />- 241b: 39 d1 cmp %edx,%ecx<br />- 241d: 75 f9 jne 2418 <br />+ 2415: 8b 48 04 mov 0x4(%eax),%ecx<br />+ 2418: 8b 50 04 mov 0x4(%eax),%edx<br />+ 241b: 39 ca cmp %ecx,%edx<br />+ 241d: 75 f6 jne 2415 <br /> 241f: 8b 4d f0 mov -0x10(%ebp),%ecx<br /> 2422: 39 48 08 cmp %ecx,0x8(%eax)<br /> 2425: 0f 85 9a 00 00 00 jne 24c5 <br /><br />As 3.19+ is broken now, this should go into stable.<br />Cc: stable@vger.kernel.org<br /><br /><br />kernelOfTruthnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-77850594317150393872015-03-26T11:22:14.396+11:002015-03-26T11:22:14.396+11:00@Alfred,
alright, just updated to your new -gc
t...@Alfred,<br /><br />alright, just updated to your new -gc<br /><br />thanks for letting me know =)kernelOfTruthnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-44027915822645750412015-03-24T09:41:07.339+11:002015-03-24T09:41:07.339+11:00BTW, Alfred Chen has rebuilt his -gc branch yester...BTW, Alfred Chen has rebuilt his -gc branch yesterday.<br />My 3.19.2 with TOI and BFQ and Alfred's own updated patches, based on BFS 461, is running well on here.<br />Someone else wanting to test reads here, first:<br />http://cchalpha.blogspot.de/2015/03/319y-gc-branch-updates.html<br />and gets it here:<br />https://bitbucket.org/alfredchen/linux-gc/commits/branch/linux-3.19.y-gc<br /><br />Best regards for all of you,<br />Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-81339339946113877912015-03-23T13:36:24.814+11:002015-03-23T13:36:24.814+11:00@kernelOfTruth
I used -new branch to sync up git t...@kernelOfTruth<br />I used -new branch to sync up git tree when I code remotely. The last 4 commits on it is not well tested. So... *FORGET ABOUT IT* please.Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-74955867706003743892015-03-21T03:18:43.715+11:002015-03-21T03:18:43.715+11:00thanks for listing those !
Alfred & Con are c...thanks for listing those !<br /><br />Alfred & Con are clearly the experts here,<br /><br />I merely help out where I can as my knowledge of the internals or how things work is pretty superficial :)<br /><br />kernelOfTruthnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-71291390119073478322015-03-20T10:56:19.495+11:002015-03-20T10:56:19.495+11:00FYI:
the following WARNING, kernel/workqueue.c: p...FYI:<br /><br />the following WARNING, kernel/workqueue.c: process_one_work<br /><br />error message came up:<br /><br />http://pastebin.com/y0J8AEuL<br /><br /><br />The strange thing is that the related upstream fix already is applied to BFS<br /><br /><br />Line 1958 is the last one of:<br /><br />/*<br /> * context_switch - switch to the new MM and the new thread's register state.<br /> */<br />static inline struct rq *<br />context_switch(struct rq *rq, struct task_struct *prev,<br /> struct task_struct *next)kernelOfTruthnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-73425663757354369112015-03-19T13:38:03.196+11:002015-03-19T13:38:03.196+11:00Many thanks for your extensive work !Many thanks for your extensive work !kernelOfTruthnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-10040439194964440102015-03-19T13:37:30.569+11:002015-03-19T13:37:30.569+11:00Hi Alfred,
FYI:
I just booted up a kernel with ...Hi Alfred,<br /><br /><br />FYI:<br /><br />I just booted up a kernel with your https://bitbucket.org/alfredchen/linux-gc/branch/linux-3.19.y-new branch integrated<br /><br />and it constantly shows the following kind of errors:<br /><br />http://pastebin.com/QDq66MM6<br /><br /><br />Looks like I have to disable that config option for now :DkernelOfTruthnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-41666339619676469142015-03-10T21:03:45.254+11:002015-03-10T21:03:45.254+11:00Hi,
I can confirm that the workaround described b...Hi,<br /><br />I can confirm that the workaround described by jwh7 (SMP=y) does work for my single core, 32bit Pentium M processor.<br />Thanks for the hint. Using now the Zen 3.19.1 kernel.<br /><br />And thanks Con for your work.<br /><br />Regards sysitosMikehttps://www.blogger.com/profile/12391045215046883684noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-7136976286063092922015-03-04T13:40:18.732+11:002015-03-04T13:40:18.732+11:00I should also note that my Arch AUR linux-ck packa...I should also note that my Arch AUR linux-ck package build make config automatically enabled HT when I enabled SMP:<br />CONFIG_X86_HT=y<br />...so its possible that the root cause is related to that and not just the SMP option(s).jwh7https://www.blogger.com/profile/09659185315567537391noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-38943371230361467252015-03-04T03:17:48.303+11:002015-03-04T03:17:48.303+11:00I came across this; may well be deprecated and/or ...I came across this; may well be deprecated and/or irrelevant, but in case its any help:<br />http://stackoverflow.com/questions/14380417/understanding-link-between-config-smp-spinlocks-and-config-preempt-in-latest-3<br />-jwhjwh7https://www.blogger.com/profile/09659185315567537391noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-74379840850744948822015-03-03T13:17:54.979+11:002015-03-03T13:17:54.979+11:00No it's not expected, it's clearly a bug a...No it's not expected, it's clearly a bug as it should be possible to build a uniprocessor config. Using SMP as a config option will do as a workaround till I get around to finding out why and fixing it, thanks.ckhttps://www.blogger.com/profile/02904761195451530213noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-13765569727922543302015-03-03T13:13:54.260+11:002015-03-03T13:13:54.260+11:00I had been having this issue as well; I had a hunc...I had been having this issue as well; I had a hunch it was related to SMP in the kernel config, and was right. This is probably obvious to some, but I'll pat myself on the back anyway. :-P Running on 3.19.0-ck1 now; I set:<br />$ zcat /proc/config.gz|grep SMP<br />CONFIG_X86_32_SMP=y<br />CONFIG_GENERIC_SMP_IDLE_THREAD=y<br />CONFIG_SMP=y<br /># CONFIG_X86_BIGSMP is not set<br />CONFIG_PM_SLEEP_SMP=y<br />CONFIG_SCSI_SAS_HOST_SMP=y<br />CONFIG_VIDEO_VP27SMPX=m<br /><br />I previously had the "Kernel panic - not syncing: Attempted to kill the idle task!" in 3.18, and 3.19 had another message when i tried disabling all the SMP, HT, AMD64 config options. Until I re-enabled SMP. <br /><br />ck, Is this expected, and what other kernel options are 'required'? Thanks! -jwhjwh7https://www.blogger.com/profile/09659185315567537391noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-53253026423254343542015-03-03T03:20:34.174+11:002015-03-03T03:20:34.174+11:00Hi, is there a solution for single core, single th...Hi, is there a solution for single core, single thread, 32 bit pentium m CPU?<br />debug preemptible kernel config is not enabled.<br />3.17 with BFS worked great, 3.18 and 3.19 does not boot at all without any message. Thank you.<br />D.<br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-9028320533354922802015-02-28T18:06:23.231+11:002015-02-28T18:06:23.231+11:00Thank you very much. Keep going :)Thank you very much. Keep going :)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-65396089470703642042015-02-28T13:42:28.652+11:002015-02-28T13:42:28.652+11:00My first test for BFS 461 run well last night. I w...My first test for BFS 461 run well last night. I will see what need to be updated in -gc branch and update it next week.<br /><br />For the incoming pending patches for schedulers, I agreed that we should wait till they are finalized. At the meantime, we can investigate __schedule() in BFS, it was introduce in 460 but reverted in 461.Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-51095644679278963822015-02-28T05:41:13.935+11:002015-02-28T05:41:13.935+11:00@ kernelOfTruth / Alfred Chen
sorry for my (googl...@ kernelOfTruth / Alfred Chen<br /><br />sorry for my (google) english....<br /><br />i noticed that<br />"sched: Fix lost reschedule in __cond_resched()"<br />has been renamed and another patch (loop) came to:<br />[1/2] sched: Fix missing preemption check in cond_resched()<br />[2/2] sched: Pull resched loop to __schedule() callers<br /><br />Both patches are in Jacob Shin´s tip-bot:<br />https://patchwork.kernel.org/patch/5757231/<br />https://patchwork.kernel.org/patch/5777031/<br /><br />I don´t know, but is it probably/possible, that these patches belong together???<br /><br />Also, the following patch could be interesting:<br />sched: Fix preempt_schedule_common() triggering tracing recursion<br />https://patchwork.kernel.org/patch/5845531/<br />(was [LKP,sched] BUG: kernel boot hang https://patchwork.kernel.org/patch/5830291)<br /><br />thx to allAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-69859284202093622132015-02-28T00:47:27.380+11:002015-02-28T00:47:27.380+11:00Combined preliminary kerneloftruth's "pen...Combined preliminary kerneloftruth's "pending scheduler changes" for BFS patch:<br />http://pastebin.com/e23iUF3X<br /><br />BR, ManuelAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-14017773633445700042015-02-28T00:22:27.002+11:002015-02-28T00:22:27.002+11:00Thank you very much for the update, Con! :-)
I ho...Thank you very much for the update, Con! :-)<br /><br />I hope, you(r) contributors, Alfred Chen, kerneloftruth and post-factum will catch it up soon. <br />Need to say, the rest of 3.19.y-gc tree (omitted his BFS port) from Alfred doesn't patch well with BFS-461 anymore. I for myself can't figure it out.<br /><br />Please honor, that they all did great jobs in providing also additional preliminary patches for BFS/ CK in the meantime.<br /><br />kerneloftruth's last proposed patch for the "pending scheduler changes" together with his late addon do work well on here, when applied to 3.19.0 + 3.19.y-gc (Alfred's BFS 460 port) patches + TuxOnIce + BFQ.<br /><br />Best regards,<br />ManuelAnonymousnoreply@blogger.com