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
Posted by at
Labels: , , , ,

16 comments:

  1. AnonymousNovember 9, 2015 at 12:31 PM

    Thx, works fine so far

    ReplyDelete
  2. AnonymousNovember 9, 2015 at 1:21 PM

    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. AnonymousNovember 9, 2015 at 1:23 PM

    This was meant for TuxOnIce & BFQ included !
    Manuel

    ReplyDelete
    Replies
    1. Alfred ChenNovember 9, 2015 at 4:19 PM

      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. AnonymousNovember 10, 2015 at 11:38 AM

      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. Alfred ChenNovember 10, 2015 at 11:13 PM

      What's the fail-rate with that hunk?

      Delete
    4. AnonymousNovember 11, 2015 at 10:03 AM

      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. AnonymousNovember 12, 2015 at 9:23 AM

      @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. Alfred ChenNovember 12, 2015 at 5:01 PM

      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. AnonymousNovember 13, 2015 at 11:24 AM

      @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. AnonymousNovember 13, 2015 at 11:34 AM

      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. Alfred ChenNovember 15, 2015 at 4:30 PM

      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. AnonymousNovember 16, 2015 at 1:54 PM

      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. Alfred ChenNovember 16, 2015 at 10:07 PM

      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. AnonymousNovember 17, 2015 at 10:11 AM

      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. AnonymousNovember 17, 2015 at 6:15 PM

      like also to see a test patch

      Delete

Subscribe to: Post Comments (Atom)