For those who have UP boot issue with BFS, I have found that this issue was introduced between 0458 and 0460 during kernel 3.17 to 3.18. It's caused by cpu becomes idle and enter C-states.
It's not yet found why BFS UP has this issue while mainline scheduler doesn't, maybe there is some piece of codes BFS is missing during 3.17 to 3.18 migration. We still need to look into it.
Here is a workaround if you have this kind of UP booting issue. Add "idle=halt" to kernel cmdline which will disable cpu C-states when cpu is idle. Plz try this and see if it works for you.
BR Alfred
Saturday, July 25, 2015
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
CONFIG_SCHED_DEBUG
CONFIG_SCHEDSTATS
CONFIG_SCHED_STACK_END_CHECK
CONFIG_TIMER_STATS
CONFIG_PROVE_LOCKING
CONFIG_LOCK_STAT
CONFIG_DEBUG_LOCKDEP
CONFIG_VT_CONSOLE
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
Edit:
-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.
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
CONFIG_SCHED_DEBUG
CONFIG_SCHEDSTATS
CONFIG_SCHED_STACK_END_CHECK
CONFIG_TIMER_STATS
CONFIG_PROVE_LOCKING
CONFIG_LOCK_STAT
CONFIG_DEBUG_LOCKDEP
CONFIG_VT_CONSOLE
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
Edit:
-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.
Subscribe to:
Posts (Atom)