All of them. Like inability to even boot zen based livecd under x64 KVM machine.

I boot very often slax-remix (i486 and x86_64, zen-kernel based) and the derivate porteus on a x86_64 kvm, really don't know which livecd you're referring to, sorre.
but I think you have to blame only who provides the livecd

The only problems I've ever had with zen-sources are their lackluster release timing and format. From only getting them through the git, to having them in portage, to changing the naming, and so on, keeping up with zen sources to be able to make seeds with them has been interesting, to say the least. To say the most, it's been a PITA!

As far as bugs, before you condemn the source, be absolutely SURE you've configured things properly. One bad setting can destroy a kernel's ability to work properly. Something I also recently discovered is if you push the timer frequency beyond 1000Hz, you will make an unstable kernel. This effect is amplified with multi-core processors, and can lead to all manner of trouble...file system corruption, inability to boot, drivers that don't load properly, and so on.

Before you give up on zen, try one of my seeds. The only caveat is that you set the timer less than 1500Hz. With multi-core processors, 300Hz will work just fine. I actually recommend that, as multi-core processors have more than enough horsepower without having to "hold the pedal to the floor" so to speak. Since the timer frequency multiplies itself by the number of processor cores, a four core processor would wind up creating 1200Hz internally.

Be that as it may, please note that I have experience with others who have had issues with that particular setting. I am sending out that reality for those who are having issues, not to compare with others who are not having issues. My laptop works fine at 1500, but none of the multi-core processors I have can handle it. At 300Hz, none of my machines have issues.

Be that as it may, please note that I have experience with others who have had issues with that particular setting. I am sending out that reality for those who are having issues, not to compare with others who are not having issues. My laptop works fine at 1500, but none of the multi-core processors I have can handle it. At 300Hz, none of my machines have issues.

thanks for the tips. it's stuff like this that makes it worthwhile hanging out in the forums.

i've had a relatively stable experience with 2.6.38.5-zen+, aside from my acer-wmi problems and the occasional btrfs BUG. i now re-checked and indeed i had been running this i3-330UM laptop at 1000Hz. this info was good enough reason to drop the timer down and enable some pm debug stuff as well for next testing leg.

All of them. Like inability to even boot zen based livecd under x64 KVM machine.

I boot very often slax-remix (i486 and x86_64, zen-kernel based) and the derivate porteus on a x86_64 kvm, really don't know which livecd you're referring to, sorre.
but I think you have to blame only who provides the livecd

That livecd I my own
It is unable to boot when zen-kernel is both on host and on livecd (I have a laptop with i7) and when livecd kernel has CK BFS enabled. I get only blank screen just after grub.
gentoo-sources do not experience that problem.

I boot very often slax-remix (i486 and x86_64, zen-kernel based) and the derivate porteus on a x86_64 kvm, really don't know which livecd you're referring to, sorre.
but I think you have to blame only who provides the livecd

There are lot of problems that I don't experience but a lot of other users and PCs administered by myself do. That doesn't mean there are no bugs. No wonder software testing is big business.

Something I also recently discovered is if you push the timer frequency beyond 1000Hz, you will make an unstable kernel. This effect is amplified with multi-core processors, and can lead to all manner of trouble...file system corruption, inability to boot, drivers that don't load properly, and so on.

This might be the root of the issue. All I know is that I've had at least three seed users who had problems with the timer settings...and all were multi-core. One was an i7, which was brought to its knees at 1000Hz. That was a bit of a humbling experience, but one I am glad I had nonetheless.

but it took a while since the symptoms were very weird
(e.g. the "ps" command hanging (happened once),
strange browser errors (honest) and the give away failure
to be able to halt or reboot ...)_________________.... there is nothing - absolutely nothing - half so much worth
doing as simply messing about with Linux ...
(apologies to Kenneth Graeme)

after it says: "booting kernel" there's no change, scrolling of text or anything else

it just sits there and waits for some serious mode change

graphics driver / card: Radeon 5850, opensource radeon-driver

it would be easy if I could compile in the radeon module and the additional dependencies but with that it would hardlock at boot (from the start - no improvements until now - so it has to be compiled as a module)

so i'm forced to fly this baby blind (enter password for the luks partitions) until I get to the login prompt, login as root

and do

Code:

modprobe radeon modeset=1

or

Code:

/etc/init.d/xdm start

after that I can get to X

with xdm start only (without loading the kernel-module) the output of the VTs is still the same like right after launching the kernel

the last line displayed is "booting kernel" - switching through them alt+f1 - f6 ...

shows no difference

but when inserting / modprobeing the module output of the VTs is displayed again and also for all the other VTs

does this ring a bell for anyone ? how can this be fixed ? did I miss to compile a missing dependency into the kernel or is this a known regression ?

same here since the first versions of master-2.6.39 (nvidia): I got around it installing the proprietary video driver via ssh and boot after with a graphical login manager (but still no output on the VTs)._________________look for monty python channel on youtube

same here since the first versions of master-2.6.39 (nvidia): I got around it installing the proprietary video driver via ssh and boot after with a graphical login manager (but still no output on the VTs).

well, according to the log of 2.6.39.1 it doesn't seem if that update would fix it :\