caker wrote:
usr01 wrote:
It would be nice if Linode, as it's a serious company, investigates to solve the problem
Of course we are... That xen-devel thread was us.
I made that statement before knowing that thread was opened.
caker wrote:
This was bad advice, and I've informed our staff. 2.6.32 is unmaintained and eventually will not even be available. It's better to choose "Latest 3.0 x86_64", save, and reboot, since we know the 64 bit kernel is unaffected. 64 bit kernels can run 32 bit userspace just fine.
Sorry, I'm not an expert. What are the implications of changing a kernel to 64 bits for the rest of the software installed? We're talking about production environments...
caker wrote:
It's a software problem, most likely a race.
But the cause is unknown, isn't it?
caker wrote:
Everyone is responsible for solving problems in open source software. Only you can prevent forest fires.
Obviously, I didn't mean to say the opposite. What I wanted to say was that the errors weren't caused by the customers. Most people don't have the time/knowledge to directly solve a problem in Xen software's source code. The best we can do is help experts to solve the problem, and I said repeatedly that users with this problem should notify Linode support. Of course everybody must help to prevent forest fires, but only experts should go with the firetruck to extinguish the fire.
However the key question is: why doesn't Linode publish a post about this error instead or correcting/quoting posts written by customers like me? I asked for permission to the support guys before publishing the above tickets in this forum, so I feel a bit uncomfortable with a member of Linode's staff correcting me later.
FAQ
Search
Members
Register
Login [ Anonymous ]
