Monday, November 9, 2015

GC and VRQ branch update for v4.3

GC branch has been updated at bitbucket and github, gc version has bumped to v4.3_0463_1 with a minor v4.3 sync-up update. The all-in-one patch file is at gc_v4.3_0463_1.patch.

VRQ branch has been also updated at bitbucket and github, the version is v4.3_0463_1_vrq0, new commit for vrq will be added upon it. All-in-one patch file is at gc_v4.3_0463_1_vrq0.patch.

Have fun with 4.3 kernel.

BR Alfred

16 comments:

  1. Thx, works fine so far

    ReplyDelete
  2. Both, the -gc and -vrq kernels fail to resume from hibernation, even after re-adjusting my i915 config settings.. :-(((
    More than 10 retries for each hibernation.

    Manuel Krause

    ReplyDelete
  3. This was meant for TuxOnIce & BFQ included !
    Manuel

    ReplyDelete
    Replies
    1. As you said from v4.2.4, it failed from time to time. It may be some mainline changes between v4.2 and v4.2.4 outside of scheduler part cause the issue when combine with bfs code. The code of gc and vrq doesn't change a lot at that time, just sync-up changes from mainline scheduler code. I will find some time to double check if anything missing when sync-up.

      BR Alfred

      Delete
    2. I really don't want you to waste your valuable time. At this moment I'm testing the 4.2.6-vrq with the one hunk reverted that you mentioned recently.
      The TuxOnIce hibernation does not always resume at first attempt, but at least within reasonable retries (4).

      I know this is quite offtopic for this 4.3 thread, but I wanted to let you know about my latest findings.

      BR Manuel

      Delete
    3. What's the fail-rate with that hunk?

      Delete
    4. Mmm. It's a weird issue.
      To be honest, after some more reboots + hibernation cycles, with and without this hunk in bfs.c, it turns out to make no difference. Both versions are reliable in the same way. Sometimes already the first resume attempt succeeds, sometimes not before the 21st attempt. Once I gave up after the 25th try.
      I don't know whats going on since 4.2.4.
      What I can mention in addition: the only thing I changed in my kernel .config inbetween these kernel versions was to throw out CONFIG_LIBNVDIMM +sub-modules and CONFIG_X86_PMEM_LEGACY as I thought to make no use of it. Can this be related?

      Any ideas appreciated, thank you,
      Manuel

      Delete
    5. @Alfred:
      What do you think about Con's newly released BFS/CK patch?
      He codes the discussed hunk like this:

      @@ -5623,6 +5755,16 @@ static int sched_cpu_active(struct notif
      unsigned long action, void *hcpu)
      {
      switch (action & ~CPU_TASKS_FROZEN) {
      + case CPU_STARTING:
      + return NOTIFY_OK;
      + case CPU_ONLINE:
      + /*
      + * At this point a starting CPU has marked itself as online via
      + * set_cpu_online(). But it might not yet have marked itself
      + * as active, which is essential from here on.
      + *
      + * Thus, fall-through and help the starting CPU along.
      + */
      case CPU_DOWN_FAILED:
      set_cpu_active((long)hcpu, true);
      return NOTIFY_OK;

      I don't have enough knowledge to get an overview, if there are other related changes in Con's code.
      Do you plan to rebase your patchsets based on the new BFS 465?

      BR Manuel

      Delete
    6. I will try to rebase 465 this weekend, considering the huge changes of 463 to 465, I think it takes time to renew each commit in gc and vrq.

      Delete
    7. @Alfred:
      I would really thank you, if you took all the time needed to renew the commits based on 465 -- no matter how long it takes.
      Atm I'm testing the -ck1 (BFS 465) 4.3.0-kernel with the rest of the setup unchanged. It appears to be "a little more reliable" on resumes with TuxOnIce.
      Unfortunately my testing is not really standardized, I only try to meet the almost same circumstances when hibernating, within real world usage of my machine, you know.

      BR, and best wishes for your hard work, and don't forget to spend some spare time (weekend!) outdoors and with family and friends... ;-)
      Thank you in advance,
      Manuel

      Delete
    8. I just had another idea: Based on our earlier discussions, that the issue is a timing problem during TuxOnIce (what may be buggy) resume together with my i915 gfx driver (what may be buggy, too), would you think, that altering the rr_interval value can change the resume reliability/behaviour?

      Manuel

      Delete
    9. I heard from a polish website that i915 has issue with 4.3, but as I don't have such issue and doesn't want to go through 100+ posts via google translator, I just ignore it, :)
      Intel driver usually has some issue from time to time, maybe just wait for 4.3.1 or 4.3.2 and see if there are fixes for it.

      BR Alfred

      Delete
    10. Thank you for your reply. It's atonishing how much mess can emerge from actualizing a driver like i915. 4.2.x has several warnigs with resuming, they're gone with 4.3. Now I get a bootup warning instead.

      If you find time, just post the link to the polish posting. Let me try to get something out of it myself.

      I hope your rework session for your branches is running successfully?!

      My best wishes to you, Manuel

      Delete
    11. Codes are ready, adding part3 of task caching and testing. And I want to wait for v4.3.1 before public the code in case another sync-up cycle short after this one.

      BR Alfred

      Delete
    12. Mmm. Not even a preliminary test patch for "early adopters"? ;-)
      It can take more than one further week for 4.3.1 to appear...

      BR Manuel

      Delete
    13. like also to see a test patch

      Delete