Friday, 27 February 2015

BFS 461, linux-3.19-ck1

Announcing a resync and update of BFS for linux-3.19

BFS by itself:

3.19-sched-bfs-461.patch

-ck branded linux-3.19-ck1 patches:

3.19-ck1 patches

Apart from a resync with mainline and merging of the pending patches that were around for BFS460, there are no new changes. Apologies if I've been unable to address any new issues posted here - as per usual lack of time is the reason. There are some pending changes to the scheduler for mainline (as pointed out by kernelOfTruth here: link) but they're not finalised so I won't be delaying this release to wait for them.

Enjoy!
お楽しみください

Posted by at
Labels: , ,

22 comments:

  1. Anonymous28 February 2015 at 00:22

    Thank you very much for the update, Con! :-)

    I hope, you(r) contributors, Alfred Chen, kerneloftruth and post-factum will catch it up soon.
    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.

    Please honor, that they all did great jobs in providing also additional preliminary patches for BFS/ CK in the meantime.

    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.

    Best regards,
    Manuel

    ReplyDelete
  2. Anonymous28 February 2015 at 00:47

    Combined preliminary kerneloftruth's "pending scheduler changes" for BFS patch:
    http://pastebin.com/e23iUF3X

    BR, Manuel

    ReplyDelete
  3. Anonymous28 February 2015 at 05:41

    @ kernelOfTruth / Alfred Chen

    sorry for my (google) english....

    i noticed that
    "sched: Fix lost reschedule in __cond_resched()"
    has been renamed and another patch (loop) came to:
    [1/2] sched: Fix missing preemption check in cond_resched()
    [2/2] sched: Pull resched loop to __schedule() callers

    Both patches are in Jacob Shin´s tip-bot:
    https://patchwork.kernel.org/patch/5757231/
    https://patchwork.kernel.org/patch/5777031/

    I don´t know, but is it probably/possible, that these patches belong together???

    Also, the following patch could be interesting:
    sched: Fix preempt_schedule_common() triggering tracing recursion
    https://patchwork.kernel.org/patch/5845531/
    (was [LKP,sched] BUG: kernel boot hang https://patchwork.kernel.org/patch/5830291)

    thx to all

    ReplyDelete
    Replies
    1. kernelOfTruth21 March 2015 at 03:18

      thanks for listing those !

      Alfred & Con are clearly the experts here,

      I merely help out where I can as my knowledge of the internals or how things work is pretty superficial :)

      Delete
  4. Alfred Chen28 February 2015 at 13:42

    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.

    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.

    ReplyDelete
    Replies
    1. kernelOfTruth19 March 2015 at 13:37

      Hi Alfred,


      FYI:

      I just booted up a kernel with your https://bitbucket.org/alfredchen/linux-gc/branch/linux-3.19.y-new branch integrated

      and it constantly shows the following kind of errors:

      http://pastebin.com/QDq66MM6


      Looks like I have to disable that config option for now :D

      Delete
    2. kernelOfTruth19 March 2015 at 13:38

      Many thanks for your extensive work !

      Delete
    3. kernelOfTruth20 March 2015 at 10:56

      FYI:

      the following WARNING, kernel/workqueue.c: process_one_work

      error message came up:

      http://pastebin.com/y0J8AEuL


      The strange thing is that the related upstream fix already is applied to BFS


      Line 1958 is the last one of:

      /*
      * context_switch - switch to the new MM and the new thread's register state.
      */
      static inline struct rq *
      context_switch(struct rq *rq, struct task_struct *prev,
      struct task_struct *next)

      Delete
    4. Alfred Chen23 March 2015 at 13:36

      @kernelOfTruth
      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.

      Delete
    5. Anonymous24 March 2015 at 09:41

      BTW, Alfred Chen has rebuilt his -gc branch yesterday.
      My 3.19.2 with TOI and BFQ and Alfred's own updated patches, based on BFS 461, is running well on here.
      Someone else wanting to test reads here, first:
      http://cchalpha.blogspot.de/2015/03/319y-gc-branch-updates.html
      and gets it here:
      https://bitbucket.org/alfredchen/linux-gc/commits/branch/linux-3.19.y-gc

      Best regards for all of you,
      Manuel Krause

      Delete
    6. kernelOfTruth26 March 2015 at 11:22

      @Alfred,

      alright, just updated to your new -gc

      thanks for letting me know =)

      Delete
  5. Anonymous28 February 2015 at 18:06

    Thank you very much. Keep going :)

    ReplyDelete
  6. Anonymous3 March 2015 at 03:20

    Hi, is there a solution for single core, single thread, 32 bit pentium m CPU?
    debug preemptible kernel config is not enabled.
    3.17 with BFS worked great, 3.18 and 3.19 does not boot at all without any message. Thank you.
    D.

    ReplyDelete
    Replies
    1. Mike10 March 2015 at 21:03

      Hi,

      I can confirm that the workaround described by jwh7 (SMP=y) does work for my single core, 32bit Pentium M processor.
      Thanks for the hint. Using now the Zen 3.19.1 kernel.

      And thanks Con for your work.

      Regards sysitos

      Delete
  7. jwh73 March 2015 at 13:13

    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:
    $ zcat /proc/config.gz|grep SMP
    CONFIG_X86_32_SMP=y
    CONFIG_GENERIC_SMP_IDLE_THREAD=y
    CONFIG_SMP=y
    # CONFIG_X86_BIGSMP is not set
    CONFIG_PM_SLEEP_SMP=y
    CONFIG_SCSI_SAS_HOST_SMP=y
    CONFIG_VIDEO_VP27SMPX=m

    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.

    ck, Is this expected, and what other kernel options are 'required'? Thanks! -jwh

    ReplyDelete
    Replies
    1. ck3 March 2015 at 13:17

      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.

      Delete
    2. jwh74 March 2015 at 03:17

      I came across this; may well be deprecated and/or irrelevant, but in case its any help:
      http://stackoverflow.com/questions/14380417/understanding-link-between-config-smp-spinlocks-and-config-preempt-in-latest-3
      -jwh

      Delete
    3. jwh74 March 2015 at 13:40

      I should also note that my Arch AUR linux-ck package build make config automatically enabled HT when I enabled SMP:
      CONFIG_X86_HT=y
      ...so its possible that the root cause is related to that and not just the SMP option(s).

      Delete
  8. kernelOfTruth27 March 2015 at 11:44

    FYI:

    [PATCHv2] mm/slub: fix lockups on PREEMPT && !SMP kernels
    http://marc.info/?l=linux-kernel&m=142659459326875&w=2

    Just FYI I've hit this problem on x86. I think I used gcc 4.7 and 4.8, and
    maybe also 4.6 earlier.

    Here's the diff in asm after applying the fix:

    240a: 0f 85 ce 00 00 00 jne 24de
    2410: 89 75 f0 mov %esi,-0x10(%ebp)
    2413: 8b 07 mov (%edi),%eax
    - 2415: 8b 50 04 mov 0x4(%eax),%edx
    - 2418: 8b 48 04 mov 0x4(%eax),%ecx
    - 241b: 39 d1 cmp %edx,%ecx
    - 241d: 75 f9 jne 2418
    + 2415: 8b 48 04 mov 0x4(%eax),%ecx
    + 2418: 8b 50 04 mov 0x4(%eax),%edx
    + 241b: 39 ca cmp %ecx,%edx
    + 241d: 75 f6 jne 2415
    241f: 8b 4d f0 mov -0x10(%ebp),%ecx
    2422: 39 48 08 cmp %ecx,0x8(%eax)
    2425: 0f 85 9a 00 00 00 jne 24c5

    As 3.19+ is broken now, this should go into stable.
    Cc: stable@vger.kernel.org


    ReplyDelete
    Replies
    1. jwh722 April 2015 at 21:56

      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.

      Delete
  9. Alfred Chen15 April 2015 at 23:06

    Just upload my linux4.0 syncup patch for BFS0461 at https://bitbucket.org/alfredchen/linux-gc/downloads/bfs0461_linux4.0_syncup.patch

    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 Alfred

    ReplyDelete
    Replies
    1. Anonymous16 April 2015 at 08:41

      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.

      @CK: Could be a bit too trivial for you to publish your new BFS/CK patchset. ;-)

      Best regards,
      Manuel Krause

      Delete

Subscribe to: Post Comments (Atom)