Monday, July 20, 2015

4.1 vrq -- reworking

It takes much for me to work out the vrq on 4.1 branch. It's because the -vrq branch used to work well on three of core2 based machines but now it is not quit happy with the chromebook pixel. I'll said that the new platform expose the issues. It's not so bad that reproduce the issue is the 50% work done to solve the issue, :)

In order to find out more possible log when issues pop up. I have enabled some kernel hacking configs. And in order to see the crash kernel message even kernel hangs in earlier stage, I enabled earlyprintk and vt console output.

For the vrq commits, I am reworking them by moving the less potential troublesome issues ahead and test them if any stabilize problem existed. Now I am on stabilize issue when udev starting up which has one ten or less possibility to be reproduced. I meet it once but unlucky too slow to pick up the cell-phone to get a screenshot and the incoming kernel message just flow it away. 

I would update the vrq branch after a commit passed my stabilize test and you can check if it works on your hw to help with the development.

First of all, here are the kernel hacking configs I enabled for testing



and the kernel options/parameters is "earlyprintk=vga,keep"
add the below line into /etc/sysctl.conf
kernel.printk = 7 7 1 7

Current -gc branch should works fine with above setup, plz have a try and I'll push -vrq branch soon.

BR Alfred


-vrq branch for 4.1 has been pushed to bitbucket and github. Which now have four more vrq commits add upon -gc branch and it should consider stable as -gc branch itself, if you have any issue plz try to enable above debug methods and report back. 


  1. Hi, Alfred!
    This one is a very nice release of VRQ! :-)))
    I'ts running for one day now on here, no issues during bootup (like with the previous release for 4.0) and everydays workflow. Hibernation with TuxOnIce also doesn't fail. So, I didn't feel the need to enable your hacking/debugging options at all.
    Desktop (KDE) and e.g. video playing experience (including flash in firefox) appears to be smoother (less stuttering at high CPU or I/O load). I hope this is intended. ;-)

    Very nice work! Thank you very much and best regards,

    Manuel Krause

    1. @Manuel
      Thanks for testing. It should be as stable as -gc branch, I'm still holding a high risky commit for testing atm. I believe I have fixed the stabilize issue on my new hardware and will push it if no more issue found on this commit next week.

    2. I really feel the need to add the following related to the -vrq patches upon -gc as of 2015-07-17:

      * In my experience of ~4 days of testing, this is the most stable "bfs" ever, the -vrq is even more stable than pure -gc (not comparable with previous releases of -vrq)
      * Since using -vrq, NO hibernation via TuxOnIce ever failed on my system (plus, no additionally needed trials to recover the image from disk, as it happened relatively often with pure -gc)
      * When making heavy use of /dev/shm, backed by swap, the response of processes, that also have many things in swap (e.g. a firefox with ~170 open tabs, you may remember the scenario) is significantly faster than with pure -gc. Some would call it not only smooth but "snappy"?!

      Please, take into account, that I don't benchmark, so the mentioned points are really only subjective observations. But they are that remarkable, that I wanted to tell you about.
      I can encourage anyone who is using -gc ATM to try the current -vrq patches on top.It's a kind of Milestone for me.

      BTW: Are you planning to rebase your -gc/ -vrq, now, after Con released his new BFS? I've read through the diffs a bit, and he's taken over some of your fixes.

      Best regards,
      Manuel Krause

    3. Good to hear that. Once there four commits are considered stable, I'll move them to -gc branch.
      I will rebase to CK's 0463 this week and some sync-up and fix commits will be added to -gc too.
      Of course, -vrq will also be synced up with the newest -gc branch.

      BR Alfred

    4. No need to hurry. This kernel gets a gold casing. *MK