Thursday 26 May 2011

2.6.39-ck1 unstable

As much as I hate to say this, I have to give up on 2.6.39 for now. I just don't have the time nor energy to fix this. I'm grateful for all your testing, but it's just going to have to go on hold and I'll have to support .38 kernels in the meantime until I have a revelation of some sort, or help from someone who also knows kernel internals.

10 comments:

  1. 2.6.39 mainline (no BFS or ck-patch) hangs for me anyway. Something to do with the clocksource. Could be that whatever changed there also affects your patches.

    https://bugzilla.kernel.org/show_bug.cgi?id=35652

    ReplyDelete
  2. Worry not, Con! This is just for fun, right? (Most) people will survive without the .39 kernel, as you will know exceptionally well. In the mean while we can anesthetize ourselves with .38, lrzip, and dreams of 3.0-bfs :D

    ReplyDelete
  3. Yes, don't worry! Thnx for all your work Con!

    But: this is why BFS should be included into mainline - time for a compile time plugin infrastructure of the mainline scheduler.

    At the previous thread: Wasn't this mainly because of virtualbox? Then, someone should ask in the forums of virtualbox.org for help with BFS integration pointing to Cons previous blog entry. Shouldn't there be anyone interested in this matter? Especially if this only reveals some deeper mainline bug ...

    ReplyDelete
  4. +1 on thanks for all the great work. Love BFS!

    ReplyDelete
  5. Despite Cons "I have to give up" - I see him working: Two new test patches today.

    ReplyDelete
  6. I put the linux-image-2.6.39-ck1-1_2.6.39-ck1-1-10.00.Custom_amd64.deb on 2 different servers.
    1 - ADM64 1 core 2500 MHz
    The assembly is stable, without a glitch

    2 - 6 * AMD64 3400
    Hung assembly, even when you reboot. On this server to downgrade linux-image-2.6.38.4-ck1-1_2.6.38.4-ck1-a-10.00.Custom_amd64.deb

    ReplyDelete
  7. Thanks. I didn't say I was giving up forever, just for now.

    ReplyDelete
  8. Sometimes it is good go on a walk about from time to time. I can't tell you how many times I've walked away from a problem for a few days then suddenly come up with a solution. Thanks for everything you do. It is appreciated.

    ReplyDelete
  9. Con simply should wait:

    I saw some very low level trivial candidate patches for coming 2.6.39.1 in the queue, I don't know for sure this will be relevant:

    http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=blob;f=queue-2.6.39/cpu-hotplug-re-create-sysfs-directory-and-symlinks.patch;h=df0d7e945e694498ce7048651a1dc7e834a051e1;hb=42730985ffe992c4ce51a3aa40e29a488bd2b58f

    http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=blob;f=queue-2.6.39/x86-cpufeature-fix-cpuid-leaf-7-feature-detection.patch;h=6d98b1fe93096abdec07907d9f5e69947643e00b;hb=42730985ffe992c4ce51a3aa40e29a488bd2b58f

    ReplyDelete
  10. The above patches from Gregs stable queue are identical to patches meant for 2.6.38. I dont expect them to solve the issues for BFS-404.

    Just for the record I never had a better and more performant system, which reliable serves my purpose:
    Gentoo 64bit experimental compiled using gcc-4.6.0 running Linux-2.6.39-ck1-bfs404 patched with some 20 stable-queue fixes.

    ReplyDelete