quoting from: https://github.com/inspircd/inspircd/issues/34
"I noticed that my inspircd would run at 100% CPU usage after being
restarted. Well actually this only started after I logged out. A quick
strace shows that inspircd calls poll in a loop and the result is always
fd=0. lsof then shows tha
+1, I can confirm this report... inspircd consumes 100% cpu
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1003196
Title:
inspircd consumes all cpu
To manage notifications about this bug go to:
http
Update as of 2011-11-30
Some package update appears to have revert/changed. The above notes an
comments no longer seem valid for Ubuntu 10.04
Below is the new configuration setting we have had to use to make Ubuntu
10.04 work with serial; it is still not 100% as physical console access
to the g
Ubuntu 10.04 Re-Test
-
- ENABLED, com1, vt100, 115200, redirect after console
*DISABLED*
Grub (NON WORKING CONFIG)
GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT=5
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /
Comparison Between Ubuntu 10.04 and 11.04
---
Ubuntu 11 exhibits the same behavior as Ubuntu 10.However... a potential
workaround may have been found for Ubuntu 11 as it appears to be working...
Enable motherboard redirection
--
Feedback:
-
Apparently... *disabling* console redirection in the motherboard allows grub to
function somewhat correctly. This was not a problem in Ubuntu 8.04 (I will be
testing Ubuntu 11.04 in just a moment). I found the following footnote quote
"If you're sure you've configured
Experienced Same issue:
error: unknown terminal 'serial'
error: unknown command `terminal'.
Have been testing multiple configurations with limited success.
This command throws errors:
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200 --word=8 --parity=no
--stop=1"
This command seems to stop
Greetings~
I am not sure if my team is suffering from the problems described in
this thread... but we've been having very strange i/o problems.
We have also found a slight solution:
Compile the kernel with:
CONFIG_HZ_1000=y
CONFIG_HZ=1000
(as opposed to CONFIG_HZ_100=y CONFIG_HZ=100)
I say s
