Hi,
I got some error while reconfiguring & rebooting the
kernel(version 2.4.7-10) in the Redhat linux 7.2 for
DiffServ support.
I followed the steps for reconfiguring & rebuilding
the kernel.
1) I downloaded kernel-source-2.4.7-10.rpm from the
internet.
2) After extracting, i got the "Linux" folder in
/usr/src path.
3) I edited the following commands in /usr/src/linux
path
#make xconfig
#make dep
#make clean
#nohup make bzImage
#make modules
#make modules_install
#cp /usr/src/linux/arch/i386/boot/bzImage
/boot/linix-ds
4) I added the "lilo.conf" file in /etc path like
image=/boot/linux-ds
label=DiffServ
read-only
root=/dev/hda6
5) I run "/sbin/lilo" file.
6) after rebooting the system,lilo shows the DiffServ
label.
7) I selected that label.
8) while system booting up, it shows the following
error
INIT: Id "x" respawing too fast: disabled for 5
minutes
Please help me.
what will i do?
Best Reagrds
D.SUndara Raman
=====
------------------------
D. Sundara Raman
150 Ettayapuram Road
Kovilpatti, Tamilnadu
India. 628 501.
Phone : 04632 - 27267
[email protected]
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
On Sun, Jan 26, 2003 at 09:00:34AM -0800, sundara raman wrote:
> 8) while system booting up, it shows the following
> error
>
> INIT: Id "x" respawing too fast: disabled for 5
> minutes
It's not a kernel problem -- there's something broken in your X
Windows configuration. xdm (or kdm or gdm) keeps trying to start and
fails, and init is restarting it, and it fails...
Take a look in your X logs (I run Debian and mine are in
/var/log/XFree86.log.0 -- yours may be somewhere else) for the cause
of X not starting.
Hope this helps,
Hugo.
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 1C335860 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- w.w.w. : England's batting scorecard ---
Hi Sundara :)
> INIT: Id "x" respawing too fast: disabled for 5 minutes
This has nothing to do with the kernel. Read the manual for your
sysvinit. There is the explanation of the problem and the posible
solutions.
FYI, your problem is a process spawned by your 'init' (check
/etc/inittab) dieing as soon as it is created. In order to avoid this
exec-die cycle, the respawning is stopped during 5 minutes. Read the
manual, anyway ;))
Ra?l
Hugo Mills wrote:
>
> On Sun, Jan 26, 2003 at 09:00:34AM -0800, sundara raman wrote:
>
> > 8) while system booting up, it shows the following
> > error
> >
> > INIT: Id "x" respawing too fast: disabled for 5
> > minutes
>
> It's not a kernel problem -- there's something broken in your X
> Windows configuration. xdm (or kdm or gdm) keeps trying to start and
> fails, and init is restarting it, and it fails...
I have recently had the same problem when I forgot to include some
driver in the kernel which was required by my X configuration.
--
Kasper Dupont -- der bruger for meget tid p? usenet.
For sending spam use mailto:[email protected]
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);
Kasper Dupont <[email protected]> said:
> Hugo Mills wrote:
> >
> > On Sun, Jan 26, 2003 at 09:00:34AM -0800, sundara raman wrote:
> >
> > > 8) while system booting up, it shows the following
> > > error
> > >
> > > INIT: Id "x" respawing too fast: disabled for 5
> > > minutes
> >
> > It's not a kernel problem -- there's something broken in your X
> > Windows configuration. xdm (or kdm or gdm) keeps trying to start and
> > fails, and init is restarting it, and it fails...
>
> I have recently had the same problem when I forgot to include some
> driver in the kernel which was required by my X configuration.
I've seen such problems too, caused by full /tmp
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Horst von Brand wrote:
>
> > > > INIT: Id "x" respawing too fast: disabled for 5
>
> I've seen such problems too, caused by full /tmp
Yes IIRC in that case xfs will fail to create /tmp/.font-unix
and the socket /tmp/.font-unix/fs7100 and X will fail because
of the missing font server.
Anyway, I was just stating that it could be caused by a
misconfigured kernel.
--
Kasper Dupont -- der bruger for meget tid p? usenet.
For sending spam use mailto:[email protected]
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);
Hello All!
After finally upgrading the 2.2 kernel on one of our alphas to the
2.4.21-pre4 kernel, the console got cluttered with EXT2 error messages
from the RAID-array on the Mylex DAC960PX. First I tought it was a file
system proble,m, but then found the following post:
On Wed, 20 Nov 2002, Ivan Kokshaysky wrote:
> That was it, I guess.
> virt_to_bus() is deprecated - driver *must* be converted
> to the DMA mapping interface (see Documentation/DMA-mapping.txt).
>
> virt_to_bus() on alpha works only for limited range of kernel addresses.
> On dp264 valid range is 0x00000000-0x7fefffff (i.e. 2Gb - 1Mb).
> Given the fact that __get_free_pages() returns highest possible
> pages I'm not surprised that this driver doesn't work on a 2Gb machine.
>
> Probably "mem=2047M" boot argument would help...
Actually, I first compiled the kernel as "Generic", which let the system
boot. When I recompiled the kernel more specifically for the machine type,
DP264/Tsunami/2*EV67, the boot process would halt when the DAC960 driver
tried to init. (A good thing; otherwise I would still be looking at the
problem as an ext2-problem).
Anyway, the machine has 2GB mem, and the "mem=2047M" seems to help (it
boots).
A question: Is this trick safe? Or should i downgrade to an earlier
kernel?
A comment: I guess a warning/conflict message about this should also be
printed for the "Generic" (and maybe other configs that manage to boot)
kernel compilation, as it seems to lead to massive file system corruption
on the RAID-array (e2fsck -y /dev/rd/c0d0 printed "a million" screens of
errors :-)
Have a nice day,
Mikael J.
http://www.helsinki.fi/~mpjohans/
Kasper Dupont <[email protected]> said:
> Horst von Brand wrote:
> >
> > > > > INIT: Id "x" respawing too fast: disabled for 5
> >
> > I've seen such problems too, caused by full /tmp
>
> Yes IIRC in that case xfs will fail to create /tmp/.font-unix
> and the socket /tmp/.font-unix/fs7100 and X will fail because
> of the missing font server.
Yep. And failing to start xfs has the same effect. Broken library
installations (such as missing/mangled /etc/ld.so.cache, also caused by
full / on boot; broken/mangled /etc/ld.so.conf) can also be a cause.
> Anyway, I was just stating that it could be caused by a
> misconfigured kernel.
Better check the easy answers first ;-)
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Hello All!
Top-posting and replying to my own mail. Let's hope this at least is
useful for someone :-)
An update on the issue described below: The "mem=2047M" only _seemed_ to
solve the problem. The machine booted, but processes accessing the
RAID-array mount (/wrk) froze and became unkillable in a "D-state"
(immortal is the wrong word; they weren't alive).
The foolproof method of creating these processes was running bonnie++ -f,
a few seconds after "Rewriting..." all access to /wrk died. Impossible to
kill the processes with "kill -9" either (is there an even deadlier way?)
This happened on all kernels I tested, 2.4.19, 2.4.20, 2.4.21-pre4.
Unfortunately I couldn't test the -ac patches, as they needed a header
file missing on my system, sched_runqueue.h. Failed to locate it anywhere
else also.
So I now compiled the 2.2.23 kernel, and it (again) _seems_ to be running
OK. At least bonnie++ finishes. Now there's only the occasional spinlocks
that get stuck...
Anyway, if someone has a similar system, DP264/Tsunami/2*EV67, and can't
get things working with the DAC960 and 2.4, you can take some comfort in
the fact that you are not alone.
Just realized that I should have checked with a non SMP kernel, to see if
that would have made a difference.
Finally, if there are any wise persons out there who would benefit from
more precise information in efforts to solve this, I will be very glad to
help out.
Have a nice day,
Mikael J.
http://www.helsinki.fi/~mpjohans/
On Fri, 31 Jan 2003, Mikael Johansson wrote
> Hello All!
>
> After finally upgrading the 2.2 kernel on one of our alphas to the
> 2.4.21-pre4 kernel, the console got cluttered with EXT2 error messages
> from the RAID-array on the Mylex DAC960PX. First I tought it was a file
> system proble,m, but then found the following post:
>
> On Wed, 20 Nov 2002, Ivan Kokshaysky wrote:
>
> > That was it, I guess.
> > virt_to_bus() is deprecated - driver *must* be converted
> > to the DMA mapping interface (see Documentation/DMA-mapping.txt).
> >
> > virt_to_bus() on alpha works only for limited range of kernel addresses.
> > On dp264 valid range is 0x00000000-0x7fefffff (i.e. 2Gb - 1Mb).
> > Given the fact that __get_free_pages() returns highest possible
> > pages I'm not surprised that this driver doesn't work on a 2Gb machine.
> >
> > Probably "mem=2047M" boot argument would help...
>
> Actually, I first compiled the kernel as "Generic", which let the system
> boot. When I recompiled the kernel more specifically for the machine type,
> DP264/Tsunami/2*EV67, the boot process would halt when the DAC960 driver
> tried to init. (A good thing; otherwise I would still be looking at the
> problem as an ext2-problem).
>
> Anyway, the machine has 2GB mem, and the "mem=2047M" seems to help (it
> boots).
>
> A question: Is this trick safe? Or should i downgrade to an earlier
> kernel?
>
> A comment: I guess a warning/conflict message about this should also be
> printed for the "Generic" (and maybe other configs that manage to boot)
> kernel compilation, as it seems to lead to massive file system corruption
> on the RAID-array (e2fsck -y /dev/rd/c0d0 printed "a million" screens of
> errors :-)
>
> Have a nice day,
> Mikael J.
> http://www.helsinki.fi/~mpjohans/