Here comes the vrq patch up on the latest -gc branch.
https://bitbucket.org/alfredchen/linux-gc/downloads/vrq_upon_3.19-gc.patch
As a pre-release, I don't want add details here, just want to know if it works for you and don't expect improvement comparing to -gc branch, based on my sanity test, it just can match the -gc branch at this moment.
I will continue do some code cleanup and tune before formal release.
Should one wait for benchmarks?
ReplyDelete@pf
DeleteI do suggest you should have a try personally, but don't pull to your repo at this moment as it is just a pre-release, I want more ppl to try it to find out something I can't cover yet.
@post-factum: Hi, Oleksandr,
Deletehave you found some time to test the -vrq patch, so far?
Maybe we need some experienced guy like you to help debugging. See the thread(s) below.
Best regards, and many thanks in advance,
Manuel Krause
I haven't. Probably, I should wait for resync against BFSv462.
DeleteIt doesn't work for me. I get a complete lockup at the moment the Xserver gets started and can't switch to the logging console. Need to power off. In the logs there doesn't appear any trace of the crash.
ReplyDeleteBest regards,
Manuel
@Manuel
DeleteDoes the pure console without X env works for you?
What video card and driver you have?
I tested intel and ati, X works fine.
Video Card is an integrated Intel Graphics GM45 using the intel / i915 driver.
DeleteAfter some testing this maybe _not_ the problem...
I can start the VRQ kernel into single user mode (former runlevel 1) without problems -- but already fail to go to 3 (multi-user with network services). It seems to hang after initializing sound and before activating the network services. They use the tg3 module "Broadcom Tigon3 ethernet driver". But module loading also works in single user mode.
I don't know for what and where to search further. Please, give me a hint!
Manuel
Unfortunately this doesn't stay the whole truth...
DeleteAfter even more testing (e.g. for runlevel 2, multi-user without network == nogo) and back to runlevel 1: Even booting to runlevel 1 is not reliable at all. Several attempts may fail, before one works. I haven't made up statistics, as they'd look bad. Sometimes I already came up with a blank screen after kernel loaded the initrd.
I'm quite sure, that I've reverted all patches having had prevously applied after your BFS -gc. {https://bitbucket.org/alfredchen/linux-gc/commits/branch/linux-3.19.y-gc}, and the vrq_upon_3.19-gc.patch applied and compiled cleanly. Can you, please, re-check, that this patch really is based upon this tree/branch?
Any other idea is highly appreciated, too... ;-)
In the meantime I'll rebuild the kernel 3.19.3 from scratch and report back.
Manuel
O.k. I've rebuilt the kenel. Same results. It's completely unpredictible, if it would boot through. Most times it fails even booting into single console -- runlevel 2,3 and 5 are far out of reach.
Delete:-(
So, it's obviously no driver problem itself.
Should I retest without the TuxOnIce patch?
Your -3.19.y-gc one from March 23rd without this new VRQ addon works like a charm and is my current standard kernel.
Thanks,
Manuel
@Manuel
DeleteWould you please download my -gc branch kernel tar-ball from https://bitbucket.org/alfredchen/linux-gc/get/v3.19.2-gc.tar.bz2 then apply the this patch upon it? So we have the same code-base to look at the problem.
Then please use your kernel config and build the kernel for test. If it is not working, please send me an email and attach your kernel file.
Since we have similar hardware, hopefully I can reproduce your issue with your config file.
BR Alfred
Sorry for the delay.
DeleteI've taken the long way to use your tarball first with all of my formerly applied patches and reduce them patch by patch upon each failure. Until I ended with your pure -gc and the VRQ-0.4 patch, only. This one also failed.
I've sent the .config file to your email address.
Within this testing I once got to see a "general protection fault" within schedule+0xf14/0x2f80. And there was mentioned ...hrtimer... in the trace. Unfortunately I was too lazy to write down all the numbers and there is nothing in the logs due to the complete lockup that always occurs. Afterwards I've also tried one kernel with disabled HIGH_RES_TIMERS in kernel config. This one also failed with VRQ.
Best regards,
Manuel
@Manuel
DeleteThanks for testing. I have build kernel with your config, got to buildin the btrfs into kernel to boot up my rootfs. Just give your a quick update here, 2 unexpected bootup/shutdown are captured so far, the task just like stop schedule and other init scripts depend on it are waiting. The reproduce chance is not high enough to get further info so far. So, you if you happen to crash and have a crash log on screen, you can take a picture on it using cellphone and send me a email. I'll keep looking into it.
BR Alfred
I'm sorry, my cellphone lacks a camera function, and I don't have a digital camera. :-(
DeleteManuel
Never mind. I will keep eyes open when go through commits in -vrq and hopefully find something I have missed.
DeleteAnd for sure, I will play with your config more time and see if lucky. Until now, the chance is about one of twenty and decreasing.
The difference in reproducibility is a bit sad.
ReplyDeleteIf I'd boot into runlevel 1 I'd fail in ~1 of 10 cases, while booting to runlevel 3 or 5 in 39 of 40 cases, approximately. About 3..4 times I got a blank screen just after initrd load attempt and crashing. And the crash message only showed up in one case of all, relatively early during kernel bootup (not yet starting the openSUSE startup scripts).
I hope that my .config doesn't have weird misconfigurations in it?!
Manuel