On Sun, 5 Mar 2000, Mike Galbraith wrote:
> On Sun, 5 Mar 2000, Sergey Kubushin wrote:
>
> > On Sun, 5 Mar 2000, Mike Galbraith wrote:
> >
> > > On Sat, 4 Mar 2000, Sergey Kubushin wrote:
> > >
> > > > Unfortunately enough, vanilla 2.3.49 with some errors fixed (nothing
> > > > substantial, just some drivers fixed to get them compile) does not boot here
> > > > at all :(( "Uncompressing... OK. Now booting the kernel" and the machine is
> > > > dead...
> > > >
> > > > Initrd strikes back? People, will it EVER be fixed? We did already make the
> > > > setproctitle() fix (the right way IMHO with a coupla syscalls and supporting
> > > > userspace function which can be forced into glibc or made a separate lib),
> > > > but we're unable to test it :((
> > >
> > > As far as I know, initrd _is_ fixed. Funny thing: B. D. Elliot and I
> > > both posted workarounds for the problem, and you didn't even comment.
> > > Now you blurt "People, will it EVER be fixed?". Color me unimpressed.
> >
> > Look, I'm NOT a kernel hacker. I have helluva lot of another work and I can
> > NOT spend all of my time struggling with omissions and miscellaneous typos
> > in kernel sources which should have not been there if somebody did try to
> > compile the kernel before releasing. I'm a distribution maker and I have
> > much more urgent things to do. Yes, I do want to have some 2.3.xx which does
> > boot and which I can use as a base for a distro's beta. And I'm ready to
> > help in reaching this goal doing my best.
>
> So you're busy. So is averyone else here.. that buys you nothing.
> So you're a distributor with a vested interest in a functional beta
> kernel.. and have no time/resources to contribute to having it all
> delivered to you on your schedule. Now _that_ does buy you something.
>
> You could _contribute_ by struggling with some of the small shit.
> That can make the difference between guru doing serious as a heart
> attack development work and guru fixing silly assed typos. But then
> again, it usually _is_ 'someone else's job' if there's no money or
> glory to be had.
I'm not for a money or glory. I have to have the work done and distribution
made. The average distro contains 500+ packages which have to be built.
Kernel is one of the packages. If I turn my attention exclusively to the
kernel, those (500+ - 1) packages won't be built. It's that simple.
Our team _DO_ make miscellaneous contributions. We are NOT kernel hackers,
we're distribution makers so those contributions are made to a wide range of
software (e.g. util-linux to get new devices right, now it's a
setproctitle() proposal). We'd like to spend all our time for e.g. some
kernel trickery, but alas the real world is not all this way. The perfection
is infinite and no real things would be made if sometimes one have not step
on the throat of his own song... And, unfortunately, one have to provide his
family with some money for living and that money do not appear outta a clean
air... Especially here in 1/6 of the Earth...
> > I'd like to. But unfortunately I do NOT have enough time to do exclusively
> > kernel hacking and debugging. Yes, I can try some options, trace an oops
> > etc., but I will NOT spend all of my time trying to solve misteries kinda
> > "Why does the thing not boot at all?"... And I can't reboot my machine
> > umpting times a day for nothing. Especially considering the fact that often
> > encountered full fsck (we don't have journalling FS in kernel yet, do we?)
> > on 36 Gbyte disks takes almost an hour...
>
> Essentially, it sounds to me like you're too busy trying to make a buck
> to do anything except crack the whip. That uses up your oxygen ticket
> as far as I'm concerned.
BTW, there were VERY suspicious messages when building 2.3.49 with 64Gbyte
RAM support turned on. I do recompile the thing without highmem support to
see whether it help or not. Here come the build log excerpts for the
unbootable kernel with highmem enabled:
=== Cut ===
gcc -D__KERNEL__ -I/tmp/build-kernel/usr/src/linux-2.3.49/include -D__SMP__ -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -DCPU=686 -march=pentiumpro -mcpu=pentiumpro -bi686-ksi-linux -fno-strict-aliasing -c -o iodebug.o iodebug.c
{standard input}: Assembler messages:
{standard input}:758: Warning: Indirect lcall without `*'
{standard input}:843: Warning: Indirect lcall without `*'
{standard input}:924: Warning: Indirect lcall without `*'
{standard input}:963: Warning: Indirect lcall without `*'
{standard input}:995: Warning: Indirect lcall without `*'
{standard input}:1027: Warning: Indirect lcall without `*'
{standard input}:1058: Warning: Indirect lcall without `*'
{standard input}:1087: Warning: Indirect lcall without `*'
{standard input}:1116: Warning: Indirect lcall without `*'
{standard input}:1433: Warning: Indirect lcall without `*'
.
.
.
as -o bbootsect.o bbootsect.s
bbootsect.s: Assembler messages:
bbootsect.s:2139: Warning: Indirect lcall without `*'
.
.
.
as -o bsetup.o bsetup.s
bsetup.s: Assembler messages:
bsetup.s:2405: Warning: Indirect lcall without `*'
=== Cut ===
P.S. The first message is gone when building without highmem support, but
the same one did appear on garbage.c.
bbootsect.s and bsetup.s are still there...
P.P.S. I do use compressed romfs for initrd images and romfs is the only fs
(except procfs and devfs) built into the kernel. Works like a charm with
2.2.19pre9+devfs+ipvs+reiserfs+lvm and with a heavily patched 2.3.36+devfs.
===========================================================================
Sergey Kubushin aka the Tamer < > The impossible we do immediately.
e-mail: ksi@ksi-linux.com SK320-RIPE < > Miracles require 24-hour notice.
===========================================================================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:18 EST