bzImage, root device Q

[D. Stimits]

When booting to a bzImage kernel, bytes 508 and 509 can be used to name
the minor and major number of the intended root device (although it can
be overridden with a command line parameter). Other characteristics are
also available this way, through bytes in the kernel. rdev makes a
convenient way to hex edit those bytes.

What I'm more curious about is how does the kernel know what filesystem
_type_ the root is? Are there similar bytes in the bzImage, and can rdev
change this? And is there a command line syntax to allow specifying
filesystem type (e.g., something like "vmlinuz root=/dev/scd0,iso9660"
or "vmlinuz root=/dev/scd0,xfs")? Or is this limited in some way,
requiring mount on one or a few known filesystem types ("linux native"
subset comes to mind), followed by a chroot or pivot_root style command
(which in turn means no direct root mount of some filesystem types)?

D. Stimits, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

bzImage, root device Q

[D. Stimits]

When booting to a bzImage kernel, bytes 508 and 509 can be used to name
the minor and major number of the intended root device (although it can
be overridden with a command line parameter). Other characteristics are
also available this way, through bytes in the kernel. rdev makes a
convenient way to hex edit those bytes.

What I'm more curious about is how does the kernel know what filesystem
_type_ the root is? Are there similar bytes in the bzImage, and can rdev
change this? And is there a command line syntax to allow specifying
filesystem type (e.g., something like vmlinuz root=/dev/scd0,iso9660
or vmlinuz root=/dev/scd0,xfs)? Or is this limited in some way,
requiring mount on one or a few known filesystem types (linux native
subset comes to mind), followed by a chroot or pivot_root style command
(which in turn means no direct root mount of some filesystem types)?

D. Stimits, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: >128 MB RAM stability problems (again)

[D. Stimits]

Ronald Bultje wrote:
> 
> On 04 Jul 2001 17:29:12 -0400, Chris Siebenmann wrote:
> > You write:
> > | I'm kind of astounded now, WHY can't linux-2.4.x run on ANY machine in
> > | my house with more than 128 MB RAM?!? Can someone please point out to me
> > | that he's actually running kernel-2.4.x on a machine with more than 128
> > | MB RAM and that he's NOT having severe stability problems?
> >
> >  Me. Two machines. (Both 2.4.5 high -ac kernels.)
> >
> >  I strongly suggest getting memtest86 and running it on all of your
> > problematic machines.
> 
> I ran memtest tonight on all machines
> It gave 0 errors on all of them.
> 
> So this leads to the conclusion that the memory is okay, and that
> something else must be the problem Could it still be a failing power
> supply or something? It seems both computers have a 230 W power supply.
> Might be a problem, I guess, I can buy a 400 W thingy if that makes
> sense.
> 
> Other solutions I heard:
> - antistatic wrist strap: already have one :-)
> - BIOS fiddling... What exactly should I look for? They are, as far as I
> can see, identical memory sticks, probably both from different
> suppliers, but besides that quite the same

Look for wait states. Add a wait state, which slows down access to the
ram (if it doesn't help, put it back where it was).

> - are there different brands of memory of different quality and might
> that be a possible cause of the problems? And if so - what are good
> memory brands and what are the bad ones?
> - I mixed different types of SDRAM... Could be it My mainboard
> manual is not really clear about this And I have no clue what brand
> of memory I bought... they are all 133 MHz SDRAM sticks, some 64 MB,
> some 128 MB MB manual says it can handle all 64/128 MB sticks...

Mixing different types is a bad thing to leave to chance. Corsair and
Kingston I *think* are good brands.

> - 

Try each memory stick by itself; if it only fails when both are in at
once, reverse the slots they are in; if it still fails, get another
stick that is the same brand and type as another, try just those
together.

> 
> Anyway, thanks for any advice until now and thanks for listening again,
> hope to hear more solutions.
> 
> --
> Ronald Bultje
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 128 MB RAM stability problems (again)

[D. Stimits]

Ronald Bultje wrote:
 
 On 04 Jul 2001 17:29:12 -0400, Chris Siebenmann wrote:
  You write:
  | I'm kind of astounded now, WHY can't linux-2.4.x run on ANY machine in
  | my house with more than 128 MB RAM?!? Can someone please point out to me
  | that he's actually running kernel-2.4.x on a machine with more than 128
  | MB RAM and that he's NOT having severe stability problems?
 
   Me. Two machines. (Both 2.4.5 high -ac kernels.)
 
   I strongly suggest getting memtest86 and running it on all of your
  problematic machines.
 
 I ran memtest tonight on all machines
 It gave 0 errors on all of them.
 
 So this leads to the conclusion that the memory is okay, and that
 something else must be the problem Could it still be a failing power
 supply or something? It seems both computers have a 230 W power supply.
 Might be a problem, I guess, I can buy a 400 W thingy if that makes
 sense.
 
 Other solutions I heard:
 - antistatic wrist strap: already have one :-)
 - BIOS fiddling... What exactly should I look for? They are, as far as I
 can see, identical memory sticks, probably both from different
 suppliers, but besides that quite the same

Look for wait states. Add a wait state, which slows down access to the
ram (if it doesn't help, put it back where it was).

 - are there different brands of memory of different quality and might
 that be a possible cause of the problems? And if so - what are good
 memory brands and what are the bad ones?
 - I mixed different types of SDRAM... Could be it My mainboard
 manual is not really clear about this And I have no clue what brand
 of memory I bought... they are all 133 MHz SDRAM sticks, some 64 MB,
 some 128 MB MB manual says it can handle all 64/128 MB sticks...

Mixing different types is a bad thing to leave to chance. Corsair and
Kingston I *think* are good brands.

 - your solution here :-)

Try each memory stick by itself; if it only fails when both are in at
once, reverse the slots they are in; if it still fails, get another
stick that is the same brand and type as another, try just those
together.

 
 Anyway, thanks for any advice until now and thanks for listening again,
 hope to hear more solutions.
 
 --
 Ronald Bultje
 
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: >128 MB RAM stability problems (again)

[D. Stimits]

Ronald Bultje wrote:
> 
> Hi,
> 
> you might remember an e-mail from me (two weeks ago) with my problems
> where linux would not boot up or be highly instable on a machine with
> 256 MB RAM, while it was 100% stable with 128 MB RAM. Basically, I still
> have this problem, so I am running with 128 MB RAM again.

Some motherboards have ram requirements that might not be obvious
without reading the m/b manual. For example, some m/b's require
registered memory. Some don't work with ECC. Some require modules be
installed in pairs (of exact type match). Some require that larger
memory sticks be placed in earlier slots relative to smaller modules.
And if you add a wait state in the bios a marginal ram module can become
quite stable; the unstable version can behave differently under
different circumstances (including temperature). Check the m/b manual
and m/b web site for exact requirements, and make sure the ram matches;
even if your memory is good, it might not be good in your circumstances.

D. Stimits, [EMAIL PROTECTED]

> 
> I've been running Mandrake 7.2 on another machine for some time - no
> problem, until. I added another 64 MB RAM and tried to install
> redhat (25 times (!!!)) and Mandrake 8.0... Both crash with memory
> faults. Redhat just freezes or givesa a python warning, Mandrake
> gives a segfault with a warning that "memory is missing" Both refuse
> to complete installation...
> 
> I'm kind of astounded now, WHY can't linux-2.4.x run on ANY machine in
> my house with more than 128 MB RAM?!? Can someone please point out to me
> that he's actually running kernel-2.4.x on a machine with more than 128
> MB RAM and that he's NOT having severe stability problems?
> And can that same person PLEASE point out to me why 2.4.x is crashing on
> me (or help me to find out...)?
> 
> First machine is a Intel P-II 400 with 128 MB RAM (133 MHz SDRAM) and
> crashing when I insert an additional 128 - it's running RH-7.0 with
> kernel-2.4.4. Second machine is an AMD Duron 600 with 196 MB RAM (also
> 133 MHz SDRAM), crashing during the installation of both Mandrake 8.0
> and Redhat 7.1 and which used to run stable with 128 MB RAM or 64 MB RAM
> with Mandrake-7.2. Win2k runs stable on this machine in all
> configurations.
> 
> I'm getting desperate win2k is running stable and it's scary to see
> linux crash while win2k runs stable and smooth.
> 
> (ps I'm not subscribed to the list - please CC a copy to me when
> replying)
> 
> Thanks in advance for any help on this,
> 
> --
> Ronald Bultje
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 128 MB RAM stability problems (again)

[D. Stimits]

Ronald Bultje wrote:
 
 Hi,
 
 you might remember an e-mail from me (two weeks ago) with my problems
 where linux would not boot up or be highly instable on a machine with
 256 MB RAM, while it was 100% stable with 128 MB RAM. Basically, I still
 have this problem, so I am running with 128 MB RAM again.

Some motherboards have ram requirements that might not be obvious
without reading the m/b manual. For example, some m/b's require
registered memory. Some don't work with ECC. Some require modules be
installed in pairs (of exact type match). Some require that larger
memory sticks be placed in earlier slots relative to smaller modules.
And if you add a wait state in the bios a marginal ram module can become
quite stable; the unstable version can behave differently under
different circumstances (including temperature). Check the m/b manual
and m/b web site for exact requirements, and make sure the ram matches;
even if your memory is good, it might not be good in your circumstances.

D. Stimits, [EMAIL PROTECTED]

 
 I've been running Mandrake 7.2 on another machine for some time - no
 problem, until. I added another 64 MB RAM and tried to install
 redhat (25 times (!!!)) and Mandrake 8.0... Both crash with memory
 faults. Redhat just freezes or givesa a python warning, Mandrake
 gives a segfault with a warning that memory is missing Both refuse
 to complete installation...
 
 I'm kind of astounded now, WHY can't linux-2.4.x run on ANY machine in
 my house with more than 128 MB RAM?!? Can someone please point out to me
 that he's actually running kernel-2.4.x on a machine with more than 128
 MB RAM and that he's NOT having severe stability problems?
 And can that same person PLEASE point out to me why 2.4.x is crashing on
 me (or help me to find out...)?
 
 First machine is a Intel P-II 400 with 128 MB RAM (133 MHz SDRAM) and
 crashing when I insert an additional 128 - it's running RH-7.0 with
 kernel-2.4.4. Second machine is an AMD Duron 600 with 196 MB RAM (also
 133 MHz SDRAM), crashing during the installation of both Mandrake 8.0
 and Redhat 7.1 and which used to run stable with 128 MB RAM or 64 MB RAM
 with Mandrake-7.2. Win2k runs stable on this machine in all
 configurations.
 
 I'm getting desperate win2k is running stable and it's scary to see
 linux crash while win2k runs stable and smooth.
 
 (ps I'm not subscribed to the list - please CC a copy to me when
 replying)
 
 Thanks in advance for any help on this,
 
 --
 Ronald Bultje
 
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

page reserved twice

[D. Stimits]

I'm curious if there is any significance to this, which occurs at each
reboot on an SMP system running noapic (sometimes Netscape manages to
produce a hard lockup on the system, sometimes a core dump indicates NS
had signal 7, bus error, in cases where it doesn't lock the system),
2.4.6-pre1 with XFS patches:

 kernel: BIOS-provided physical RAM map:
 kernel:  BIOS-e820:  - 0009fc00 (usable)
 kernel:  BIOS-e820: 0009fc00 - 000a (reserved)
 kernel:  BIOS-e820: 000e - 0010 (reserved)
 kernel:  BIOS-e820: 0010 - 0ffe (usable)
 kernel:  BIOS-e820: 0ffe - 0fff8000 (ACPI data)
 kernel:  BIOS-e820: 0fff8000 - 1000 (ACPI NVS)
 kernel: Scan SMP from c000 for 1024 bytes.
 kernel: Scan SMP from c009fc00 for 1024 bytes.
 kernel: Scan SMP from c00f for 65536 bytes.
 kernel: found SMP MP-table at 000faf50
 kernel: hm, page 000fa000 reserved twice.
 kernel: hm, page 000fb000 reserved twice.
 kernel: hm, page 000f4000 reserved twice.
 thanteros kernel: hm, page 000f5000 reserved twice.
 thanteros kernel: On node 0 totalpages: 65504
 thanteros kernel: zone(0): 4096 pages.
 kernel: zone(1): 61408 pages.
 kernel: zone(2): 0 pages.
 kernel: Intel MultiProcessor Specification v1.1
 kernel: Virtual Wire compatibility mode.
 kernel: OEM ID: _AMI_Product ID: 840_CARMEL__ APIC at: 0xFEE0


Very similar messages seem to occur on a different machine with RH's
2.4.2 kernel, BX chipset, and IO-APIC enabled. The machine this is from
has had this message on earlier kernels as well, none of which had XFS
patches. What is the significance (or consequence) of pages reserved
twice?

D. Stimits, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

page reserved twice

[D. Stimits]

I'm curious if there is any significance to this, which occurs at each
reboot on an SMP system running noapic (sometimes Netscape manages to
produce a hard lockup on the system, sometimes a core dump indicates NS
had signal 7, bus error, in cases where it doesn't lock the system),
2.4.6-pre1 with XFS patches:

 kernel: BIOS-provided physical RAM map:
 kernel:  BIOS-e820:  - 0009fc00 (usable)
 kernel:  BIOS-e820: 0009fc00 - 000a (reserved)
 kernel:  BIOS-e820: 000e - 0010 (reserved)
 kernel:  BIOS-e820: 0010 - 0ffe (usable)
 kernel:  BIOS-e820: 0ffe - 0fff8000 (ACPI data)
 kernel:  BIOS-e820: 0fff8000 - 1000 (ACPI NVS)
 kernel: Scan SMP from c000 for 1024 bytes.
 kernel: Scan SMP from c009fc00 for 1024 bytes.
 kernel: Scan SMP from c00f for 65536 bytes.
 kernel: found SMP MP-table at 000faf50
 kernel: hm, page 000fa000 reserved twice.
 kernel: hm, page 000fb000 reserved twice.
 kernel: hm, page 000f4000 reserved twice.
 thanteros kernel: hm, page 000f5000 reserved twice.
 thanteros kernel: On node 0 totalpages: 65504
 thanteros kernel: zone(0): 4096 pages.
 kernel: zone(1): 61408 pages.
 kernel: zone(2): 0 pages.
 kernel: Intel MultiProcessor Specification v1.1
 kernel: Virtual Wire compatibility mode.
 kernel: OEM ID: _AMI_Product ID: 840_CARMEL__ APIC at: 0xFEE0


Very similar messages seem to occur on a different machine with RH's
2.4.2 kernel, BX chipset, and IO-APIC enabled. The machine this is from
has had this message on earlier kernels as well, none of which had XFS
patches. What is the significance (or consequence) of pages reserved
twice?

D. Stimits, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: For comment: draft BIOS use document for the kernel

[D. Stimits]

Alan Cox wrote:
> 
> Linux 2.4 BIOS usage reference
> 
> Boot Sequence
> -
> 
> Linux is normally loaded either directly as a bootable floppy image or from
> hard disk via a boot loader called lilo. The kernel image is transferred
> into low memory and a parameter block above it.
> 
> When booting from floppy disk the BIOS disk parameter tables are replaced
> by a new table set up to allow a maximum sector count of 36 (the track size
> for a 2.88Mb ED floppy)
> 
> int 0x13, AH=0x02 is issued to to probe and find the disk geometry.
> int 0x13, AH=0x00 is used to reset the floppy controller.
> int 0x13, AH=0x02 is then issued repeatedly to load tracks of data. The
> boot loader ensures no issued requests cross the track boundaries
> 
> int 0x10 service 3 is used during the boot loading sequence to obtain the
> cursor position. int 0x10 service 13 is used to display loading messages
> as the loading procedure continues. int 0x10 AH=0xE is used to display a
> progress bar of '=' characters during the bootstrap
> 
> Control is then transferred to the loaded image whether by the floppy boot
> loader or other services
> 

If it is within the realm of the paper, I'd like to know the differences
when booting from an ATAPI cdrom (or the fact that there is no
difference). Or for SCSI cdrom if relevant or useful to the purposes of
the paper.

D. Stimits, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Is this part of newer filesystem hierarchy?

[D. Stimits]

Alan Cox wrote:
> 
> > glad to know this, i do wonder how does /usr/bin/ld work for red hat.
> > to my old mentality this seems red hat is going out of any resonable
> > standard.
> 
> It works like /usr/bin/ld on any other platform I know of
> 
> > if the same libc stripped would not run library, and they HAVE to mantein
> > a libc.so.6 linside of /lib, otherway this would be too mutch against
> > a resonable standard.
> 
> bash-2.04$ ls -l /lib/libc.so.6
> lrwxrwxrwx1 root root   13 May 14 16:46 /lib/libc.so.6 -> 
>libc-2.2.2.so
> 
> I don't follow the discussion here.

There is a directory on RH 7.1 x86, /lib/i686/. When checking with ldd
to various applications, as to which libc they link to, it turns out
that the /lib/libc.so.6 is not used. They all seem to point at
/lib/i686/libc.so.6 (this is the version with debugging symbols) by
default. The odd thing is that there are NO LD_ style path variables set
on this system, there is NO /etc/ld.so.preload, and /etc/ld.so.conf does
not contain any reference to /lib/i686/. So there is a question of just
how it is possible for ld to use that directory and ignore /lib/ for
libc.so.6. So far the two possibilities seem to be that either the
linker was precompiled to look in the subdirectory, or else when the
linker looks at /lib/ it also recursively checks other directories (this
doesn't seem likely). The reason why it matters is because it is
confusing some custom boot floppy creation software. The original author
of that software is looking for a means to make it work correctly with
RH 7.1. The manual way for it to avoid confusion is to cd to the mount
point of the ramdisk which it builds up, into its lib directory, and sym
link the contents of the i686 subdirectory into the main lib directory.
But the original software does interesting things like checking what
ld.so.conf has, and checking what environment variables are set, but
since none of those provide any clues, the automated means remains
broken for now. Probably the next step will be manually testing for the
existence of /lib/{uname -m}/, and if it exists, sym linking it to /lib/
(these are actually relative to the mount point of the ramdisk during
creation). The boot system is designed as a customized bootdisk creation
that automatically detects various dependencies of a highly customized
linux install.

It still remains to be seen how it is that /lib/i686/libc.so.6 is used
in place of /lib/libc.so.6 (which could be deleted and RH 7.1 wouldn't
care...very strange).

D. Stimits, [EMAIL PROTECTED]

> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Is this part of newer filesystem hierarchy?

[D. Stimits]

Luigi Genoni wrote:
> 
> On Fri, 22 Jun 2001, D. Stimits wrote:
> 
> > Luigi Genoni wrote:
> > >
> > > Again i am confused.
> > >
> > > /usr/bin/ld is linker at compilation time, at it works how i told in
> > > second part
> > > of my mail, (just try to compile it, it comes with binutils,
> > > ftp.kernel.org/pub/linux/devel/binutils).
> > >
> > > /lib/d-2.2.X.so  is what you are talking about.
> > > So should i think os an hack to ld-2.2.3.so ??
> >
> > The RH 7.1 comes with:
> > :~# ld --version
> > GNU ld 2.10.91
> > Copyright 2001 Free Software Foundation, Inc.
> > This program is free software; you may redistribute it under the terms
> > of
> > the GNU General Public License.  This program has absolutely no
> > warranty.
> >   Supported emulations:
> >elf_i386
> >i386linux
> >elf_i386_glibc21
> Ok, this is the linker for compilation time, it
> is not related to the loader for shared libraries. You can even remove
> /usr/bin/ld, and the system will run anyway binaries, but you will not be
> able to link compiled objects.
> try a find for the directory ldscripts or for those files,

It appears that Redhat has eliminated much of this. If I run updatedb,
then locate, I find there is no instance of "ldscripts". Nor is there an
instance of "i386linux" or "i386coff" that can be seen by locate. So I
made it a wider locate, and tried for any instance of just "86linux" or
"86coff", these also do not exist. Apparently Redhat has completely
changed linking (looking at a backup of an older RH 6.2, these do exist,
so I suspect the change at around 7.0).

> 
> elf_i386.xelf_i386.xs   i386coff.xn  i386linux.xbn
> elf_i386.xbn  elf_i386.xu   i386coff.xr  i386linux.xn
> elf_i386.xn   i386coff.xi386coff.xu  i386linux.xr
> elf_i386.xr   i386coff.xbn  i386linux.x  i386linux.xu
> 
> you could not find the *coff* ones
> those are the configuration file (unproper definition, i ask
> excuse for my english), for /usr/bin/ld you are running
> doing ld --version.
> >
> > The glibc rpm is version 2.2.2-10.
> >
> > >
> > > to see how it works loock at /usr/bin/ldd, it's an interesting script.
> > >
> > > I can understand why old glibc 2.1 is not isered in the directories
> > > where ldconfig has to loock to create its db for loader, but there should
> > > be a corrispective /usr/i386-(redhat/glibc2.2???)-linux/ (with its
> > > subdirectories)
> > > for glibc 2.2, since it is necessary at compilation
> > > time.
> >
> > There is *no* /usr/i386-xxx except for:
> > /usr/i386-glibc21-linux/
> name could be different, just could you e-mail the output for
> the command tree inside of /usr?

The entire tree would be quite large. Are you looking only for
directories (this would be a much smaller listing)? It might even
challenge the maximum size an ISP allows before filtering it:
16632 directories, 258120 files

> >
> > No glibc22 version exists.
> >
> > > This do not change the problem which is related to /lib/ld-2.2.X.so.
> > > doing a strings /lib/ld-2.XXX
> > > you will find also
> > >
> > > info[19]->d_un.d_val == sizeof (Elf32_Rel)
> > > info[20]->d_un.d_val == 17
> > > /lib/
> > > /usr/lib/
> > > {ORIGIN}
> > > {PLATFORM}
> > > expand_dynamic_string_token
> > > dl-load.c
> >
> > "i686" is visible on a line by itself, but so are i386, i486, and i586.
> this is another thing...
> > The full path of /lib/i686/ is not mentioned anywhere. So it looks like
> > strings of /lib/ld-2* does not offer any hints as to how the i686
> > subdirectory is being chosen without it being specified anywhere else. I
> > think this will end up just being one of those mysteries, and the boot
> > software coder will have to find some non-trivial workaround. It sounds
> > like the /lib/i686/ path was hardcoded in the linker when it was
> > compiled, which means there are no simple config file checks.
> and then they compiled ALL other binaries from scratch with new linker,
> passing /lib/i686/libc.so.6 explivitally, or changing the script
> /usr/lib/libc.so?

No ldscripts on the system. Through locate and awk, I can guarantee
there is also only one ld on the system, /usr/bin/ld. It sounds like
they did compile all other binaries from scratch, passing /lib/i686/
explicitly.

> 
> boh! I do not know, and I am not thinking I am going to install a Red Hat
> right now (simply it is not suitable for my needs, it is a great
> dis

Re: Is this part of newer filesystem hierarchy?

[D. Stimits]

Luigi Genoni wrote:
 
 On Fri, 22 Jun 2001, D. Stimits wrote:
 
  Luigi Genoni wrote:
  
   Again i am confused.
  
   /usr/bin/ld is linker at compilation time, at it works how i told in
   second part
   of my mail, (just try to compile it, it comes with binutils,
   ftp.kernel.org/pub/linux/devel/binutils).
  
   /lib/d-2.2.X.so  is what you are talking about.
   So should i think os an hack to ld-2.2.3.so ??
 
  The RH 7.1 comes with:
  :~# ld --version
  GNU ld 2.10.91
  Copyright 2001 Free Software Foundation, Inc.
  This program is free software; you may redistribute it under the terms
  of
  the GNU General Public License.  This program has absolutely no
  warranty.
Supported emulations:
 elf_i386
 i386linux
 elf_i386_glibc21
 Ok, this is the linker for compilation time, it
 is not related to the loader for shared libraries. You can even remove
 /usr/bin/ld, and the system will run anyway binaries, but you will not be
 able to link compiled objects.
 try a find for the directory ldscripts or for those files,

It appears that Redhat has eliminated much of this. If I run updatedb,
then locate, I find there is no instance of ldscripts. Nor is there an
instance of i386linux or i386coff that can be seen by locate. So I
made it a wider locate, and tried for any instance of just 86linux or
86coff, these also do not exist. Apparently Redhat has completely
changed linking (looking at a backup of an older RH 6.2, these do exist,
so I suspect the change at around 7.0).

 
 elf_i386.xelf_i386.xs   i386coff.xn  i386linux.xbn
 elf_i386.xbn  elf_i386.xu   i386coff.xr  i386linux.xn
 elf_i386.xn   i386coff.xi386coff.xu  i386linux.xr
 elf_i386.xr   i386coff.xbn  i386linux.x  i386linux.xu
 
 you could not find the *coff* ones
 those are the configuration file (unproper definition, i ask
 excuse for my english), for /usr/bin/ld you are running
 doing ld --version.
 
  The glibc rpm is version 2.2.2-10.
 
  
   to see how it works loock at /usr/bin/ldd, it's an interesting script.
  
   I can understand why old glibc 2.1 is not isered in the directories
   where ldconfig has to loock to create its db for loader, but there should
   be a corrispective /usr/i386-(redhat/glibc2.2???)-linux/ (with its
   subdirectories)
   for glibc 2.2, since it is necessary at compilation
   time.
 
  There is *no* /usr/i386-xxx except for:
  /usr/i386-glibc21-linux/
 name could be different, just could you e-mail the output for
 the command tree inside of /usr?

The entire tree would be quite large. Are you looking only for
directories (this would be a much smaller listing)? It might even
challenge the maximum size an ISP allows before filtering it:
16632 directories, 258120 files

 
  No glibc22 version exists.
 
   This do not change the problem which is related to /lib/ld-2.2.X.so.
   doing a strings /lib/ld-2.XXX
   you will find also
  
   info[19]-d_un.d_val == sizeof (Elf32_Rel)
   info[20]-d_un.d_val == 17
   /lib/
   /usr/lib/
   {ORIGIN}
   {PLATFORM}
   expand_dynamic_string_token
   dl-load.c
 
  i686 is visible on a line by itself, but so are i386, i486, and i586.
 this is another thing...
  The full path of /lib/i686/ is not mentioned anywhere. So it looks like
  strings of /lib/ld-2* does not offer any hints as to how the i686
  subdirectory is being chosen without it being specified anywhere else. I
  think this will end up just being one of those mysteries, and the boot
  software coder will have to find some non-trivial workaround. It sounds
  like the /lib/i686/ path was hardcoded in the linker when it was
  compiled, which means there are no simple config file checks.
 and then they compiled ALL other binaries from scratch with new linker,
 passing /lib/i686/libc.so.6 explivitally, or changing the script
 /usr/lib/libc.so?

No ldscripts on the system. Through locate and awk, I can guarantee
there is also only one ld on the system, /usr/bin/ld. It sounds like
they did compile all other binaries from scratch, passing /lib/i686/
explicitly.

 
 boh! I do not know, and I am not thinking I am going to install a Red Hat
 right now (simply it is not suitable for my needs, it is a great
 distribution, of course, but it is not what my users need).
 
 want my suggestion?
 upgrade to glibc 2.2.3 and to binutils 2.11.90.0.19 building
 them from sources against 2.4.X kernel includes. And you wil see if it
 works how you would expect.

Part of my reason for running Redhat 7.1 (aside from liking it's X11
support) is that I expect to be testing a lot of software for
compatibility against this particular distribution. I might upgrade my
glibc from 2.2.2 to 2.2.3, but not for a while, due to the same reasons.

As far as this particular problem goes, I am trying to help the author
of some general boot disk utilities find a good way to automatically
detect (through perl scripts) the correct libc configuration. Telling
users of the software that Redhat 7.1 is not supported is not an option,
regardless of why

Re: Is this part of newer filesystem hierarchy?

[D. Stimits]

Alan Cox wrote:
 
  glad to know this, i do wonder how does /usr/bin/ld work for red hat.
  to my old mentality this seems red hat is going out of any resonable
  standard.
 
 It works like /usr/bin/ld on any other platform I know of
 
  if the same libc stripped would not run library, and they HAVE to mantein
  a libc.so.6 linside of /lib, otherway this would be too mutch against
  a resonable standard.
 
 bash-2.04$ ls -l /lib/libc.so.6
 lrwxrwxrwx1 root root   13 May 14 16:46 /lib/libc.so.6 - 
libc-2.2.2.so
 
 I don't follow the discussion here.

There is a directory on RH 7.1 x86, /lib/i686/. When checking with ldd
to various applications, as to which libc they link to, it turns out
that the /lib/libc.so.6 is not used. They all seem to point at
/lib/i686/libc.so.6 (this is the version with debugging symbols) by
default. The odd thing is that there are NO LD_ style path variables set
on this system, there is NO /etc/ld.so.preload, and /etc/ld.so.conf does
not contain any reference to /lib/i686/. So there is a question of just
how it is possible for ld to use that directory and ignore /lib/ for
libc.so.6. So far the two possibilities seem to be that either the
linker was precompiled to look in the subdirectory, or else when the
linker looks at /lib/ it also recursively checks other directories (this
doesn't seem likely). The reason why it matters is because it is
confusing some custom boot floppy creation software. The original author
of that software is looking for a means to make it work correctly with
RH 7.1. The manual way for it to avoid confusion is to cd to the mount
point of the ramdisk which it builds up, into its lib directory, and sym
link the contents of the i686 subdirectory into the main lib directory.
But the original software does interesting things like checking what
ld.so.conf has, and checking what environment variables are set, but
since none of those provide any clues, the automated means remains
broken for now. Probably the next step will be manually testing for the
existence of /lib/{uname -m}/, and if it exists, sym linking it to /lib/
(these are actually relative to the mount point of the ramdisk during
creation). The boot system is designed as a customized bootdisk creation
that automatically detects various dependencies of a highly customized
linux install.

It still remains to be seen how it is that /lib/i686/libc.so.6 is used
in place of /lib/libc.so.6 (which could be deleted and RH 7.1 wouldn't
care...very strange).

D. Stimits, [EMAIL PROTECTED]

 
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: For comment: draft BIOS use document for the kernel

[D. Stimits]

Alan Cox wrote:
 
 Linux 2.4 BIOS usage reference
 
 Boot Sequence
 -
 
 Linux is normally loaded either directly as a bootable floppy image or from
 hard disk via a boot loader called lilo. The kernel image is transferred
 into low memory and a parameter block above it.
 
 When booting from floppy disk the BIOS disk parameter tables are replaced
 by a new table set up to allow a maximum sector count of 36 (the track size
 for a 2.88Mb ED floppy)
 
 int 0x13, AH=0x02 is issued to to probe and find the disk geometry.
 int 0x13, AH=0x00 is used to reset the floppy controller.
 int 0x13, AH=0x02 is then issued repeatedly to load tracks of data. The
 boot loader ensures no issued requests cross the track boundaries
 
 int 0x10 service 3 is used during the boot loading sequence to obtain the
 cursor position. int 0x10 service 13 is used to display loading messages
 as the loading procedure continues. int 0x10 AH=0xE is used to display a
 progress bar of '=' characters during the bootstrap
 
 Control is then transferred to the loaded image whether by the floppy boot
 loader or other services
 

If it is within the realm of the paper, I'd like to know the differences
when booting from an ATAPI cdrom (or the fact that there is no
difference). Or for SCSI cdrom if relevant or useful to the purposes of
the paper.

D. Stimits, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Cleanup kbuild for aic7xxx

[D. Stimits]

"Justin T. Gibbs" wrote:
> 
> >> >Users don't have to manually select "rebuild firmware".  They can
> >> >rely on the generated files already in the aic7xxx directory.  This
> >> >is why the option defaults to off.
> >
> >For the SGI patched kernels based on either 2.4.5 or 2.4.6-pre1, I have
> >had to manually select this for a 7892 controller. Without manually
> >selecting it, it guarantees boot failure. I don't know if this is due to
> >the SGI modifications or not. The real problem I found is that during
> >boot failure, there was no meaningful debug message.
> 
> I don't know why your kernel source is out of sync.  I will have to
> go pull down the 2.4.5 and 2.4.6 trees and see if some portion of
> my patches never made it into those trees.  It also looks like the
> comment section for this option didn't make it into my 2.4.4 and above
> patches.  I'll correct this on this on Monday.  Here's the relevent
> info.  Do you have any comments on what would make it more useful?
> 
> +Build Adapter Firmware with Kernel Build
> +CONFIG_AIC7XXX_BUILD_FIRMWARE
> +  This option should only be enabled if you are modifying the
> +  firmware source to the aic7xxx driver and wish to have the
> +  generated firmware include files updated during a normal
> +  kernel build.  The assmebler for the firmware requires
> +  lex and yacc or their equivalents, as well as the db v1
> +  library.  You may have to install additional packages or
> +  modify the assmebler make file or the files it includes
> +  if your build environment is different than that of the
> +  author.

I would add a note to try without it at first, but if bootup starts
normally, then hangs in what seems like a controller or filesystem
failure of a scsi drive, try to enable the option.

(this would give some hint about debugging an aic7xxx failure,
regardless of error messages)

D. Stimits, [EMAIL PROTECTED]

> 
> >Missing firmware rebuild is fatal for my system, SMP x86 with integrated
> >7892. Messages and config menu information is inadequate, it requires a
> >bit of pounding the head on the wall to figure it out.
> 
> It is hard to make the kernel driver give a reasonable message for every
> possible error that running with incompatible components may cause.
> 
> --
> Justin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Is this part of newer filesystem hierarchy?

[D. Stimits]

Luigi Genoni wrote:
> 
> Again i am confused.
> 
> /usr/bin/ld is linker at compilation time, at it works how i told in
> second part
> of my mail, (just try to compile it, it comes with binutils,
> ftp.kernel.org/pub/linux/devel/binutils).
> 
> /lib/d-2.2.X.so  is what you are talking about.
> So should i think os an hack to ld-2.2.3.so ??

The RH 7.1 comes with:
:~# ld --version
GNU ld 2.10.91
Copyright 2001 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of
the GNU General Public License.  This program has absolutely no
warranty.
  Supported emulations:
   elf_i386
   i386linux
   elf_i386_glibc21

The glibc rpm is version 2.2.2-10.

> 
> to see how it works loock at /usr/bin/ldd, it's an interesting script.
> 
> I can understand why old glibc 2.1 is not isered in the directories
> where ldconfig has to loock to create its db for loader, but there should
> be a corrispective /usr/i386-(redhat/glibc2.2???)-linux/ (with its
> subdirectories)
> for glibc 2.2, since it is necessary at compilation
> time.

There is *no* /usr/i386-xxx except for:
/usr/i386-glibc21-linux/

No glibc22 version exists.

> This do not change the problem which is related to /lib/ld-2.2.X.so.
> doing a strings /lib/ld-2.XXX
> you will find also
> 
> info[19]->d_un.d_val == sizeof (Elf32_Rel)
> info[20]->d_un.d_val == 17
> /lib/
> /usr/lib/
> {ORIGIN}
> {PLATFORM}
> expand_dynamic_string_token
> dl-load.c

"i686" is visible on a line by itself, but so are i386, i486, and i586.
The full path of /lib/i686/ is not mentioned anywhere. So it looks like
strings of /lib/ld-2* does not offer any hints as to how the i686
subdirectory is being chosen without it being specified anywhere else. I
think this will end up just being one of those mysteries, and the boot
software coder will have to find some non-trivial workaround. It sounds
like the /lib/i686/ path was hardcoded in the linker when it was
compiled, which means there are no simple config file checks.

D. Stimits, [EMAIL PROTECTED]

> 
> this is the interesting section of the output. This way you can check for
> an hack to the loader, but I think to something else instead of an hack.
> 
> I do not have a red hat here around, since i do prefer another style for
> my linux systems, so i cannot check by person.
> 
> Luigi Genoni
> 
> On Fri, 22 Jun 2001, D. Stimits wrote:
> 
> > Luigi Genoni wrote:
> > >
> > > I do not know if this is a new filesystem hierarchy, it should not be,
> > > at less untill lsb finishes all discussion (anyway it is similar to lsb
> > > standard). Your mail is a little confusing for me. Let's see if i can
> > > clarify my ideas.
> > >
> > > On Thu, 21 Jun 2001, D. Stimits wrote:
> > >
> > > > I found on my newer Redhat 7.1 distribution that glibc is being placed
> > > > differently than just /lib/. Here is the structure I found:
> > > >
> > > > /lib/ has:
> > > > libc-2.2.2.so (hard link)
> > > > libc.so.6 (sym link to above)
> > > >
> > > > A new directory appears, /lib/i686/ (uname -m is i686):
> > > > libc-2.2.2.so (a full hard link copy of /lib/ version)
> > > > libc.so.6 (sym link to hard link in this directory)
> > > >
> > > > The file size of /lib/libc-2.2.2.so is around 1.2 MB, while the size of
> > > > /lib/i686/libc-2.2.2.so is over 5 MB. The 5 MB version has symbols,
> > > > while the 1.2 MB version is stripped.
> > > >
> > > > Here is the peculiar part that I need to find out about. My
> > > > /lib/ld.so.conf does not contain the i686 directory in its path. Nor do
> > > > any local LD environment variables. Even so, "ldconfig -p" lists *only*
> > > > the libc.so.6 sym link, not the libc-2.2.2.so, and the one listed is for
> > > > the i686 subdirectory, not the /lib/ directory. How is it possible that
> > > > the i686 directory is being checked if it is not listed in ld.so.conf
> > > > and not part of any LD path variable? I am using a non-Redhat kernel
> > > > (patched 2.4.6-pre1), so I know it isn't a Redhat-ism related to the
> > > > kernel itself. My ld version:
> > > excuse, but if you do something like,
> > > ldd /bin/ls
> > >
> > > what do you get, which libc is loaded?
> >
> > :~# ldd /bin/ls
> >   libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002a000)
> >   libc.so.6 => /lib/i686/libc.so.6 (0x4002e000)
> >   /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)
> >
> > The i686

Re: Cleanup kbuild for aic7xxx

[D. Stimits]

"J . A . Magallon" wrote:
> 
> On 20010623 Keith Owens wrote:
> >
> >>What again are you trying to fix?  It looks to me like you are simply
> >>trying to make it harder for people actually working on the aic7xxx
> >>driver to have proper dependencies.
> >
> >The patch still works for anybody changing the aic7xxx firmware or the
> >aicasm code.  Any change to the generated files or the aicasm files now
> >forces a rebuild, the option is not required.  Only people changing
> >aic7xxx firmware are affected, instead of everybody.
> >
> 
> It is easier than that. Nobody should be rebuilding the firmware apart
> from driver mantainers. If driver version in 2.4.5 is 6.1.13, that version
> includes a certain firmware in .h format and that is all. Apart from
> this, the author (Justin) can make available in his web page one other
> package for driver testers or developers including aicasm and firmware
> source. But that should not be in the kernel tree.
> If there are updates to the firmware, just send the patch for .h files
> to kernel mantainers and/or lkml, as everybody does.
> 
> This is easier, doesn't it ?

It would cause problems for me. Perhaps it is an issue of XFS filesystem
patches, rather than the regular kernel, I don't know what it modifies
relative to aic7xxx. But so far all of my recent test kernels will fail
to complete boot correctly if rebuild firmware is not used.

D. Stimits, [EMAIL PROTECTED]

> 
> --
> J.A. Magallon   #  Let the source be with you...
> mailto:[EMAIL PROTECTED]
> Mandrake Linux release 8.1 (Cooker) for i586
> Linux werewolf 2.4.5-ac17 #2 SMP Fri Jun 22 01:36:07 CEST 2001 i686
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Cleanup kbuild for aic7xxx

[D. Stimits]

Keith Owens wrote:
> 
> On Fri, 22 Jun 2001 13:39:45 -0600,
> "Justin T. Gibbs" <[EMAIL PROTECTED]> wrote:
> >>The existing build process for aic7xxx on Linux has several problems.
> >>
> >>* Users have to manually select "rebuild firmware".  Relying on users
> >>  to perform any action other than make *config is unacceptable.  It is
> >>  far too error prone.
> >
> >Users don't have to manually select "rebuild firmware".  They can
> >rely on the generated files already in the aic7xxx directory.  This
> >is why the option defaults to off.

For the SGI patched kernels based on either 2.4.5 or 2.4.6-pre1, I have
had to manually select this for a 7892 controller. Without manually
selecting it, it guarantees boot failure. I don't know if this is due to
the SGI modifications or not. The real problem I found is that during
boot failure, there was no meaningful debug message.

> 
> You rely on a timestamp check to tell the users "suggest you rebuild
> firmware".  That timestamp check is inherently unreliable when files
> are both generated and shipped.
> 
> >>* Rebuilding the firmware requires lex, yacc and libdb.  Not everybody
> >>  has these installed.
> >
> >Then they shouldn't check the box "rebuild firmware".
> 
> See above.  Users think they need to turn on the firmware build, then
> complain when it breaks.
> 
> >>* The check for which libdb to use assumes that the presence of a db.h
> >>  is enough, but the overlap between glibc-devel and dbx-devel packages
> >>  means that finding a db.h is not enough, you have to confirm that the
> >>  corresponding libdb exists.
> >
> >Such is Linux.  Those who understand what it means to rebuild the
> >firmware will have the necessary tools, check the box in config,
> >and have it work.

But there is insufficient menu dialog associated with rebuild firmware.

> 
> Wrong.  Such is the way it _used_ to be.  As the use of Linux expands,
> more and more people are building their own kernels without knowing all
> the internals.  This is good, we get more users.  But kernel build code
> can no longer assume that anybody building a kernel is automatically an
> expert.
> 
> >>* It checks if the firmware is up to date by comparing the timestamps
> >>  on aic7xxx_seq.h and aic7xxx_reg.h against aic7xxx.seq and
> >>  aic7xxx.reg.  Alas, when a patch hits those files there is no
> >>  guarantee which order the files are listed in the patch so the final
> >>  timestamp order is unreliable.  diff lists files in alphabetical
> >>  order but other source repository systems can generate patches in any
> >>  order.  This is a problem for all generated files, not just aic7xxx.
> >
> >So you might get a harmless warning if you haven't checked the box.  This
> >is not fatal and I have yet to hear one complaint about it.

Missing firmware rebuild is fatal for my system, SMP x86 with integrated
7892. Messages and config menu information is inadequate, it requires a
bit of pounding the head on the wall to figure it out.

> 
> http://marc.theaimsgroup.com/?l=linux-kernel=99124017310488=2
> was fatal, you even replied to it.
> 
> >>* Shipping files which are also overwritten by users causes problems
> >>  for source control systems and can cause spurious differences when
> >>  generating patches.  This is a problem for all generated files, not
> >>  just aic7xxx.
> >
> >Those using revision control should know how to use revision control.
> >The driver is developed under revision control and the current setup
> >causes me no grief.  Of course, I don't keep the generated files in
> >revision control because there is no benefit in doing so.
> 
> Users take patches from Linus or Alan Cox which include the generated
> patches and add the patches to local source repositories.  That
> includes the generated files.  If it comes from Linus or AC it is a
> "master" copy.  End users do not have the luxury of excluding the
> generated files from revision control because it is not their input.
> And if they do exclude the files then their users are forced to
> generate the firmware.  Excluding the aic7xxx generated files from
> source revision works for you because you always generate the firmware,
> it does not work for anybody else.
> 
> >For those
> >that decide to keep the generated files in revision control, they
> >should pull any update to the generated files from the vendor (they
> >are always provided in my patches) and *never check the box*.
> 
> Users must not be forced to go hunting for files from a vendor when the
> rst of the code is in the kernel.  Especially when that vendor is not
> listed in MAINTAINERS and there is no contact data in the aic7xxx
> directory.
> 
> >>The patch below fixes all of the above issues.  It does not touch the
> >>aic7xxx code nor sequencer input, just the generated files and the
> >>kbuild related files.  The patch is approx 100Kb but most of it is the
> >>rename of aic7xxx_{seq,reg}.h to aic7xxx_{seq,reg}.h_shipped.
> >
> >I don't see this as an improvement.

Re: Is this part of newer filesystem hierarchy?

[D. Stimits]

Luigi Genoni wrote:
> 
> I do not know if this is a new filesystem hierarchy, it should not be,
> at less untill lsb finishes all discussion (anyway it is similar to lsb
> standard). Your mail is a little confusing for me. Let's see if i can
> clarify my ideas.
> 
> On Thu, 21 Jun 2001, D. Stimits wrote:
> 
> > I found on my newer Redhat 7.1 distribution that glibc is being placed
> > differently than just /lib/. Here is the structure I found:
> >
> > /lib/ has:
> > libc-2.2.2.so (hard link)
> > libc.so.6 (sym link to above)
> >
> > A new directory appears, /lib/i686/ (uname -m is i686):
> > libc-2.2.2.so (a full hard link copy of /lib/ version)
> > libc.so.6 (sym link to hard link in this directory)
> >
> > The file size of /lib/libc-2.2.2.so is around 1.2 MB, while the size of
> > /lib/i686/libc-2.2.2.so is over 5 MB. The 5 MB version has symbols,
> > while the 1.2 MB version is stripped.
> >
> > Here is the peculiar part that I need to find out about. My
> > /lib/ld.so.conf does not contain the i686 directory in its path. Nor do
> > any local LD environment variables. Even so, "ldconfig -p" lists *only*
> > the libc.so.6 sym link, not the libc-2.2.2.so, and the one listed is for
> > the i686 subdirectory, not the /lib/ directory. How is it possible that
> > the i686 directory is being checked if it is not listed in ld.so.conf
> > and not part of any LD path variable? I am using a non-Redhat kernel
> > (patched 2.4.6-pre1), so I know it isn't a Redhat-ism related to the
> > kernel itself. My ld version:
> excuse, but if you do something like,
> ldd /bin/ls
> 
> what do you get, which libc is loaded?

:~# ldd /bin/ls
  libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002a000)
  libc.so.6 => /lib/i686/libc.so.6 (0x4002e000)
  /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)

The i686 subdirectory version is visible to the linker. I don't know
how.

> 
> have you got a file like /etc/ld.so.preload??

No. Nor are any preload or LD environment variables set. Something
Redhat has done is making the i686 subdirectory visible. Maybe ld
searches recursively?

> basically you can use the stripped glibc (faster), but then,
> if you have troubles and you need to debug, just set the preload file,
> or use LD_PRELOAD variable to use
> the non stripped library. In princip it is not a stupid idea,
> not that i like it, but it is not stupid.

Without any preload, it appears the linker is by default choosing the
debug version in the i686 subdirectory. Redhat must have mucked with it,
otherwise I don't see how it could be searching the i686 subdirectory
without any configuration customization (no preload, no LD environment
variables). But this is what I want to verify...where the "mucking" has
occurred, it is important to find out for some software that is used to
create custom and/or rescue disks. (alternately, to find out if there is
a predictable scheme, such as knowning ld is searching recursively, or
searches for /lib/{uname -m})

> 
> > ~# ld --version
> > GNU ld 2.10.91
> > Copyright 2001 Free Software Foundation, Inc.
> > This program is free software; you may redistribute it under the terms
> > of
> > the GNU General Public License.  This program has absolutely no
> > warranty.
> >   Supported emulations:
> >elf_i386
> >i386linux
> >elf_i386_glibc21
> >
> > Possibly Redhat altered ld? According to the man page, this directory
> > should not be found since it is not part of ld.so.conf, and also the
> > /lib/ version *should* be found (but isn't). What has changed, is it a
> > standard for filesystem hierarchy, or is it something distribution
> > specific? (I need to pass the answer along to someone working on
> > customized boot software that is currently being confused by this
> > distinction; there is a need to find a proper means to detect libc and
> > linker information)
> ld links dynamic libraries if the final extension is .so (usually a link),
> and uses the soname (usually a link too, created by ldconfig), for
> the binaries it generates, otherway it will use .a library archives.
> /usr/lib/libc.so (the file used by ld to link glibc), is a script. There
> are good reason for that, with libc5 it was a link to /lib/libc.so.5
> (soname).
> ld loocks for .so files as is configured
> inside of the files in /usr//lib/ldscripts

Interesting that there is a /usr/i386-glibc21-linux/ directory, but
glibc 2.2 is used. In /usr/i386-glibc21-linux/lib/ is file
libc-2.1.3.so, which matches this particular naming, but ldconfig -p
does not indicate this directory is searched. There is no ldscripts,
either as a file name or 

Re: Is this part of newer filesystem hierarchy?

[D. Stimits]

Luigi Genoni wrote:
 
 I do not know if this is a new filesystem hierarchy, it should not be,
 at less untill lsb finishes all discussion (anyway it is similar to lsb
 standard). Your mail is a little confusing for me. Let's see if i can
 clarify my ideas.
 
 On Thu, 21 Jun 2001, D. Stimits wrote:
 
  I found on my newer Redhat 7.1 distribution that glibc is being placed
  differently than just /lib/. Here is the structure I found:
 
  /lib/ has:
  libc-2.2.2.so (hard link)
  libc.so.6 (sym link to above)
 
  A new directory appears, /lib/i686/ (uname -m is i686):
  libc-2.2.2.so (a full hard link copy of /lib/ version)
  libc.so.6 (sym link to hard link in this directory)
 
  The file size of /lib/libc-2.2.2.so is around 1.2 MB, while the size of
  /lib/i686/libc-2.2.2.so is over 5 MB. The 5 MB version has symbols,
  while the 1.2 MB version is stripped.
 
  Here is the peculiar part that I need to find out about. My
  /lib/ld.so.conf does not contain the i686 directory in its path. Nor do
  any local LD environment variables. Even so, ldconfig -p lists *only*
  the libc.so.6 sym link, not the libc-2.2.2.so, and the one listed is for
  the i686 subdirectory, not the /lib/ directory. How is it possible that
  the i686 directory is being checked if it is not listed in ld.so.conf
  and not part of any LD path variable? I am using a non-Redhat kernel
  (patched 2.4.6-pre1), so I know it isn't a Redhat-ism related to the
  kernel itself. My ld version:
 excuse, but if you do something like,
 ldd /bin/ls
 
 what do you get, which libc is loaded?

:~# ldd /bin/ls
  libtermcap.so.2 = /lib/libtermcap.so.2 (0x4002a000)
  libc.so.6 = /lib/i686/libc.so.6 (0x4002e000)
  /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000)

The i686 subdirectory version is visible to the linker. I don't know
how.

 
 have you got a file like /etc/ld.so.preload??

No. Nor are any preload or LD environment variables set. Something
Redhat has done is making the i686 subdirectory visible. Maybe ld
searches recursively?

 basically you can use the stripped glibc (faster), but then,
 if you have troubles and you need to debug, just set the preload file,
 or use LD_PRELOAD variable to use
 the non stripped library. In princip it is not a stupid idea,
 not that i like it, but it is not stupid.

Without any preload, it appears the linker is by default choosing the
debug version in the i686 subdirectory. Redhat must have mucked with it,
otherwise I don't see how it could be searching the i686 subdirectory
without any configuration customization (no preload, no LD environment
variables). But this is what I want to verify...where the mucking has
occurred, it is important to find out for some software that is used to
create custom and/or rescue disks. (alternately, to find out if there is
a predictable scheme, such as knowning ld is searching recursively, or
searches for /lib/{uname -m})

 
  ~# ld --version
  GNU ld 2.10.91
  Copyright 2001 Free Software Foundation, Inc.
  This program is free software; you may redistribute it under the terms
  of
  the GNU General Public License.  This program has absolutely no
  warranty.
Supported emulations:
 elf_i386
 i386linux
 elf_i386_glibc21
 
  Possibly Redhat altered ld? According to the man page, this directory
  should not be found since it is not part of ld.so.conf, and also the
  /lib/ version *should* be found (but isn't). What has changed, is it a
  standard for filesystem hierarchy, or is it something distribution
  specific? (I need to pass the answer along to someone working on
  customized boot software that is currently being confused by this
  distinction; there is a need to find a proper means to detect libc and
  linker information)
 ld links dynamic libraries if the final extension is .so (usually a link),
 and uses the soname (usually a link too, created by ldconfig), for
 the binaries it generates, otherway it will use .a library archives.
 /usr/lib/libc.so (the file used by ld to link glibc), is a script. There
 are good reason for that, with libc5 it was a link to /lib/libc.so.5
 (soname).
 ld loocks for .so files as is configured
 inside of the files in /usr/arch/host name/lib/ldscripts

Interesting that there is a /usr/i386-glibc21-linux/ directory, but
glibc 2.2 is used. In /usr/i386-glibc21-linux/lib/ is file
libc-2.1.3.so, which matches this particular naming, but ldconfig -p
does not indicate this directory is searched. There is no ldscripts,
either as a file name or a directory name. The visible directory tree
there is:
/usr/i386-glibc21-linux/ as base, then these:
-- lib
`-- gcc-lib
`-- i386-redhat-linux
`-- 2.96
`-- include
-../../../../../lib/gcc-lib/i386-glibc21-linux/egcs-2.91.66/include



 
 please note that usually for klibraries inside of /lib, the .so link is in
 /usr/lib, or at less it should.
 
 syntax is like:
 SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/local/lib); \
 SEARCH_DIR(/usr

Re: Cleanup kbuild for aic7xxx

[D. Stimits]

Keith Owens wrote:
 
 On Fri, 22 Jun 2001 13:39:45 -0600,
 Justin T. Gibbs [EMAIL PROTECTED] wrote:
 The existing build process for aic7xxx on Linux has several problems.
 
 * Users have to manually select rebuild firmware.  Relying on users
   to perform any action other than make *config is unacceptable.  It is
   far too error prone.
 
 Users don't have to manually select rebuild firmware.  They can
 rely on the generated files already in the aic7xxx directory.  This
 is why the option defaults to off.

For the SGI patched kernels based on either 2.4.5 or 2.4.6-pre1, I have
had to manually select this for a 7892 controller. Without manually
selecting it, it guarantees boot failure. I don't know if this is due to
the SGI modifications or not. The real problem I found is that during
boot failure, there was no meaningful debug message.

 
 You rely on a timestamp check to tell the users suggest you rebuild
 firmware.  That timestamp check is inherently unreliable when files
 are both generated and shipped.
 
 * Rebuilding the firmware requires lex, yacc and libdb.  Not everybody
   has these installed.
 
 Then they shouldn't check the box rebuild firmware.
 
 See above.  Users think they need to turn on the firmware build, then
 complain when it breaks.
 
 * The check for which libdb to use assumes that the presence of a db.h
   is enough, but the overlap between glibc-devel and dbx-devel packages
   means that finding a db.h is not enough, you have to confirm that the
   corresponding libdb exists.
 
 Such is Linux.  Those who understand what it means to rebuild the
 firmware will have the necessary tools, check the box in config,
 and have it work.

But there is insufficient menu dialog associated with rebuild firmware.

 
 Wrong.  Such is the way it _used_ to be.  As the use of Linux expands,
 more and more people are building their own kernels without knowing all
 the internals.  This is good, we get more users.  But kernel build code
 can no longer assume that anybody building a kernel is automatically an
 expert.
 
 * It checks if the firmware is up to date by comparing the timestamps
   on aic7xxx_seq.h and aic7xxx_reg.h against aic7xxx.seq and
   aic7xxx.reg.  Alas, when a patch hits those files there is no
   guarantee which order the files are listed in the patch so the final
   timestamp order is unreliable.  diff lists files in alphabetical
   order but other source repository systems can generate patches in any
   order.  This is a problem for all generated files, not just aic7xxx.
 
 So you might get a harmless warning if you haven't checked the box.  This
 is not fatal and I have yet to hear one complaint about it.

Missing firmware rebuild is fatal for my system, SMP x86 with integrated
7892. Messages and config menu information is inadequate, it requires a
bit of pounding the head on the wall to figure it out.

 
 http://marc.theaimsgroup.com/?l=linux-kernelm=99124017310488w=2
 was fatal, you even replied to it.
 
 * Shipping files which are also overwritten by users causes problems
   for source control systems and can cause spurious differences when
   generating patches.  This is a problem for all generated files, not
   just aic7xxx.
 
 Those using revision control should know how to use revision control.
 The driver is developed under revision control and the current setup
 causes me no grief.  Of course, I don't keep the generated files in
 revision control because there is no benefit in doing so.
 
 Users take patches from Linus or Alan Cox which include the generated
 patches and add the patches to local source repositories.  That
 includes the generated files.  If it comes from Linus or AC it is a
 master copy.  End users do not have the luxury of excluding the
 generated files from revision control because it is not their input.
 And if they do exclude the files then their users are forced to
 generate the firmware.  Excluding the aic7xxx generated files from
 source revision works for you because you always generate the firmware,
 it does not work for anybody else.
 
 For those
 that decide to keep the generated files in revision control, they
 should pull any update to the generated files from the vendor (they
 are always provided in my patches) and *never check the box*.
 
 Users must not be forced to go hunting for files from a vendor when the
 rst of the code is in the kernel.  Especially when that vendor is not
 listed in MAINTAINERS and there is no contact data in the aic7xxx
 directory.
 
 The patch below fixes all of the above issues.  It does not touch the
 aic7xxx code nor sequencer input, just the generated files and the
 kbuild related files.  The patch is approx 100Kb but most of it is the
 rename of aic7xxx_{seq,reg}.h to aic7xxx_{seq,reg}.h_shipped.
 
 I don't see this as an improvement.
 
 I do, and I am the kernel build maintainer.  I don't tell you how to
 code aic7xxx drivers, but I can and will fix kbuild problems.  The
 current aic7xxx kbuild is a problem.

Re: Cleanup kbuild for aic7xxx

[D. Stimits]

J . A . Magallon wrote:
 
 On 20010623 Keith Owens wrote:
 
 What again are you trying to fix?  It looks to me like you are simply
 trying to make it harder for people actually working on the aic7xxx
 driver to have proper dependencies.
 
 The patch still works for anybody changing the aic7xxx firmware or the
 aicasm code.  Any change to the generated files or the aicasm files now
 forces a rebuild, the option is not required.  Only people changing
 aic7xxx firmware are affected, instead of everybody.
 
 
 It is easier than that. Nobody should be rebuilding the firmware apart
 from driver mantainers. If driver version in 2.4.5 is 6.1.13, that version
 includes a certain firmware in .h format and that is all. Apart from
 this, the author (Justin) can make available in his web page one other
 package for driver testers or developers including aicasm and firmware
 source. But that should not be in the kernel tree.
 If there are updates to the firmware, just send the patch for .h files
 to kernel mantainers and/or lkml, as everybody does.
 
 This is easier, doesn't it ?

It would cause problems for me. Perhaps it is an issue of XFS filesystem
patches, rather than the regular kernel, I don't know what it modifies
relative to aic7xxx. But so far all of my recent test kernels will fail
to complete boot correctly if rebuild firmware is not used.

D. Stimits, [EMAIL PROTECTED]

 
 --
 J.A. Magallon   #  Let the source be with you...
 mailto:[EMAIL PROTECTED]
 Mandrake Linux release 8.1 (Cooker) for i586
 Linux werewolf 2.4.5-ac17 #2 SMP Fri Jun 22 01:36:07 CEST 2001 i686
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Is this part of newer filesystem hierarchy?

[D. Stimits]

Luigi Genoni wrote:
 
 Again i am confused.
 
 /usr/bin/ld is linker at compilation time, at it works how i told in
 second part
 of my mail, (just try to compile it, it comes with binutils,
 ftp.kernel.org/pub/linux/devel/binutils).
 
 /lib/d-2.2.X.so  is what you are talking about.
 So should i think os an hack to ld-2.2.3.so ??

The RH 7.1 comes with:
:~# ld --version
GNU ld 2.10.91
Copyright 2001 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of
the GNU General Public License.  This program has absolutely no
warranty.
  Supported emulations:
   elf_i386
   i386linux
   elf_i386_glibc21

The glibc rpm is version 2.2.2-10.

 
 to see how it works loock at /usr/bin/ldd, it's an interesting script.
 
 I can understand why old glibc 2.1 is not isered in the directories
 where ldconfig has to loock to create its db for loader, but there should
 be a corrispective /usr/i386-(redhat/glibc2.2???)-linux/ (with its
 subdirectories)
 for glibc 2.2, since it is necessary at compilation
 time.

There is *no* /usr/i386-xxx except for:
/usr/i386-glibc21-linux/

No glibc22 version exists.

 This do not change the problem which is related to /lib/ld-2.2.X.so.
 doing a strings /lib/ld-2.XXX
 you will find also
 
 info[19]-d_un.d_val == sizeof (Elf32_Rel)
 info[20]-d_un.d_val == 17
 /lib/
 /usr/lib/
 {ORIGIN}
 {PLATFORM}
 expand_dynamic_string_token
 dl-load.c

i686 is visible on a line by itself, but so are i386, i486, and i586.
The full path of /lib/i686/ is not mentioned anywhere. So it looks like
strings of /lib/ld-2* does not offer any hints as to how the i686
subdirectory is being chosen without it being specified anywhere else. I
think this will end up just being one of those mysteries, and the boot
software coder will have to find some non-trivial workaround. It sounds
like the /lib/i686/ path was hardcoded in the linker when it was
compiled, which means there are no simple config file checks.

D. Stimits, [EMAIL PROTECTED]

 
 this is the interesting section of the output. This way you can check for
 an hack to the loader, but I think to something else instead of an hack.
 
 I do not have a red hat here around, since i do prefer another style for
 my linux systems, so i cannot check by person.
 
 Luigi Genoni
 
 On Fri, 22 Jun 2001, D. Stimits wrote:
 
  Luigi Genoni wrote:
  
   I do not know if this is a new filesystem hierarchy, it should not be,
   at less untill lsb finishes all discussion (anyway it is similar to lsb
   standard). Your mail is a little confusing for me. Let's see if i can
   clarify my ideas.
  
   On Thu, 21 Jun 2001, D. Stimits wrote:
  
I found on my newer Redhat 7.1 distribution that glibc is being placed
differently than just /lib/. Here is the structure I found:
   
/lib/ has:
libc-2.2.2.so (hard link)
libc.so.6 (sym link to above)
   
A new directory appears, /lib/i686/ (uname -m is i686):
libc-2.2.2.so (a full hard link copy of /lib/ version)
libc.so.6 (sym link to hard link in this directory)
   
The file size of /lib/libc-2.2.2.so is around 1.2 MB, while the size of
/lib/i686/libc-2.2.2.so is over 5 MB. The 5 MB version has symbols,
while the 1.2 MB version is stripped.
   
Here is the peculiar part that I need to find out about. My
/lib/ld.so.conf does not contain the i686 directory in its path. Nor do
any local LD environment variables. Even so, ldconfig -p lists *only*
the libc.so.6 sym link, not the libc-2.2.2.so, and the one listed is for
the i686 subdirectory, not the /lib/ directory. How is it possible that
the i686 directory is being checked if it is not listed in ld.so.conf
and not part of any LD path variable? I am using a non-Redhat kernel
(patched 2.4.6-pre1), so I know it isn't a Redhat-ism related to the
kernel itself. My ld version:
   excuse, but if you do something like,
   ldd /bin/ls
  
   what do you get, which libc is loaded?
 
  :~# ldd /bin/ls
libtermcap.so.2 = /lib/libtermcap.so.2 (0x4002a000)
libc.so.6 = /lib/i686/libc.so.6 (0x4002e000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000)
 
  The i686 subdirectory version is visible to the linker. I don't know
  how.
 
  
   have you got a file like /etc/ld.so.preload??
 
  No. Nor are any preload or LD environment variables set. Something
  Redhat has done is making the i686 subdirectory visible. Maybe ld
  searches recursively?
 
   basically you can use the stripped glibc (faster), but then,
   if you have troubles and you need to debug, just set the preload file,
   or use LD_PRELOAD variable to use
   the non stripped library. In princip it is not a stupid idea,
   not that i like it, but it is not stupid.
 
  Without any preload, it appears the linker is by default choosing the
  debug version in the i686 subdirectory. Redhat must have mucked with it,
  otherwise I don't see how it could be searching the i686 subdirectory
  without any

Re: Cleanup kbuild for aic7xxx

[D. Stimits]

Justin T. Gibbs wrote:
 
  Users don't have to manually select rebuild firmware.  They can
  rely on the generated files already in the aic7xxx directory.  This
  is why the option defaults to off.
 
 For the SGI patched kernels based on either 2.4.5 or 2.4.6-pre1, I have
 had to manually select this for a 7892 controller. Without manually
 selecting it, it guarantees boot failure. I don't know if this is due to
 the SGI modifications or not. The real problem I found is that during
 boot failure, there was no meaningful debug message.
 
 I don't know why your kernel source is out of sync.  I will have to
 go pull down the 2.4.5 and 2.4.6 trees and see if some portion of
 my patches never made it into those trees.  It also looks like the
 comment section for this option didn't make it into my 2.4.4 and above
 patches.  I'll correct this on this on Monday.  Here's the relevent
 info.  Do you have any comments on what would make it more useful?
 
 +Build Adapter Firmware with Kernel Build
 +CONFIG_AIC7XXX_BUILD_FIRMWARE
 +  This option should only be enabled if you are modifying the
 +  firmware source to the aic7xxx driver and wish to have the
 +  generated firmware include files updated during a normal
 +  kernel build.  The assmebler for the firmware requires
 +  lex and yacc or their equivalents, as well as the db v1
 +  library.  You may have to install additional packages or
 +  modify the assmebler make file or the files it includes
 +  if your build environment is different than that of the
 +  author.

I would add a note to try without it at first, but if bootup starts
normally, then hangs in what seems like a controller or filesystem
failure of a scsi drive, try to enable the option.

(this would give some hint about debugging an aic7xxx failure,
regardless of error messages)

D. Stimits, [EMAIL PROTECTED]

 
 Missing firmware rebuild is fatal for my system, SMP x86 with integrated
 7892. Messages and config menu information is inadequate, it requires a
 bit of pounding the head on the wall to figure it out.
 
 It is hard to make the kernel driver give a reasonable message for every
 possible error that running with incompatible components may cause.
 
 --
 Justin
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Unable to handle kernel NULL pointer dereference at virtual address - 2.4.5

[D. Stimits]

Chris Leger wrote:
> 
> Hi,
> 
> I have the same problem, only mine occurs early in the boot process
> (right after a message saying something like "trying to mount old
> root..."; or maybe s/mount/unmount)so I don't have a log.  I have a
> similar system: dual PIIIs w/ Adaptec AIC-7xxx controller, an HP Kayak.
> I saw some earlier messages about AIC-7xxx problems w/ 2.4.5, so I tried
> using aic7xxx_old and also tried a patch someone mentioned.  I have yet
> to be able to bring up my machine with 2.4.5 under any combination of
> aic7xxx drivers, so maybe it's not the driver after all.
> 
> Any ideas?  I built the kernel w/ gcc 2.91.66 (kgcc).

I have no problems running RH 7.l with the 2.4.5 ac series, provided I
have the patch to fs/block_dev.c (which apparently is in at around ac3;
also in 2.4.6-pre2 I think). When using an XFS filesystem patch, I also
have to use their "rebuild firmware" option, which I don't think is part
of ac or regular kernels. I use kgcc to compile all, and am running dual
pIII (I run without APIC because of the defective i840 chipset). All of
this is using the stock aic7xxx module or compiled in directly.

D. Stimits, [EMAIL PROTECTED]

> 
> Thanks,
> 
> Chris Leger
> 
> Rafael Martinez writes:
> > Hello
> >
> > I have got a error in my syslog about a Null pointer in the kernel:
> >
> > Kernel 2.4.5
> > glibc 2.2.12
> > gcc version 2.96 2731 (Red Hat Linux 7.0)
> >
> > Modell: ISP2150
> > Motherboard: L440GX+ DP
> > CPU: 2 x Intel Pentium III (Coppermine) 850 MHz L2 cache: 256K / Bus: 100 MHz
> > RAM: 256 MB
> > SCSI controller: Adaptec AIC-7896/7 Ultra2
> >
> >Unable to handle kernel NULL pointer dereference at virtual address
> > 0015
> >  printing eip:
> > c014db72
> > *pde = 
> > Oops: 0002
> > CPU:1
> > EIP:0010:[]
> > EFLAGS: 000
> 
> --
> [ Chris Leger  ::  [EMAIL PROTECTED]   (818)393-4462 ]
> 
> You can come up with a hundred reasons why a thing can't be done,
> and you have to eat them all when someone else does it.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Controversy over dynamic linking -- how to end the panic

[D. Stimits]

Jonathan Lundell wrote:
> 
> At 8:06 PM +0100 2001-06-21, Alan Cox wrote:
> >  > > the stdio.h, I'd tell him to go screw himself.
> >>  What is the difference between including kernel header file and
> >>  including GPLed header file?
> >
> >There are real differences between programs and interface definitions. At this
> >point you get into law and the like and its probably best you read up on it
> >from a reputable source not l/k
> 
> Though header files don't fall clearly on the interface-definition
> side of the line. ctype.h, for example, in userland, or any other
> header with #defined or inline code.
> --
> /Jonathan Lundell.

Add to that the complications of C++ templates (not used in kernel, but
it could certainly test the law).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Is this part of newer filesystem hierarchy?

[D. Stimits]

I found on my newer Redhat 7.1 distribution that glibc is being placed
differently than just /lib/. Here is the structure I found:

/lib/ has:
libc-2.2.2.so (hard link)
libc.so.6 (sym link to above)

A new directory appears, /lib/i686/ (uname -m is i686):
libc-2.2.2.so (a full hard link copy of /lib/ version)
libc.so.6 (sym link to hard link in this directory)

The file size of /lib/libc-2.2.2.so is around 1.2 MB, while the size of
/lib/i686/libc-2.2.2.so is over 5 MB. The 5 MB version has symbols,
while the 1.2 MB version is stripped.

Here is the peculiar part that I need to find out about. My
/lib/ld.so.conf does not contain the i686 directory in its path. Nor do
any local LD environment variables. Even so, "ldconfig -p" lists *only*
the libc.so.6 sym link, not the libc-2.2.2.so, and the one listed is for
the i686 subdirectory, not the /lib/ directory. How is it possible that
the i686 directory is being checked if it is not listed in ld.so.conf
and not part of any LD path variable? I am using a non-Redhat kernel
(patched 2.4.6-pre1), so I know it isn't a Redhat-ism related to the
kernel itself. My ld version:
~# ld --version
GNU ld 2.10.91
Copyright 2001 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of
the GNU General Public License.  This program has absolutely no
warranty.
  Supported emulations:
   elf_i386
   i386linux
   elf_i386_glibc21

Possibly Redhat altered ld? According to the man page, this directory
should not be found since it is not part of ld.so.conf, and also the
/lib/ version *should* be found (but isn't). What has changed, is it a
standard for filesystem hierarchy, or is it something distribution
specific? (I need to pass the answer along to someone working on
customized boot software that is currently being confused by this
distinction; there is a need to find a proper means to detect libc and
linker information)

D. Stimits, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Is this part of newer filesystem hierarchy?

[D. Stimits]

I found on my newer Redhat 7.1 distribution that glibc is being placed
differently than just /lib/. Here is the structure I found:

/lib/ has:
libc-2.2.2.so (hard link)
libc.so.6 (sym link to above)

A new directory appears, /lib/i686/ (uname -m is i686):
libc-2.2.2.so (a full hard link copy of /lib/ version)
libc.so.6 (sym link to hard link in this directory)

The file size of /lib/libc-2.2.2.so is around 1.2 MB, while the size of
/lib/i686/libc-2.2.2.so is over 5 MB. The 5 MB version has symbols,
while the 1.2 MB version is stripped.

Here is the peculiar part that I need to find out about. My
/lib/ld.so.conf does not contain the i686 directory in its path. Nor do
any local LD environment variables. Even so, ldconfig -p lists *only*
the libc.so.6 sym link, not the libc-2.2.2.so, and the one listed is for
the i686 subdirectory, not the /lib/ directory. How is it possible that
the i686 directory is being checked if it is not listed in ld.so.conf
and not part of any LD path variable? I am using a non-Redhat kernel
(patched 2.4.6-pre1), so I know it isn't a Redhat-ism related to the
kernel itself. My ld version:
~# ld --version
GNU ld 2.10.91
Copyright 2001 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of
the GNU General Public License.  This program has absolutely no
warranty.
  Supported emulations:
   elf_i386
   i386linux
   elf_i386_glibc21

Possibly Redhat altered ld? According to the man page, this directory
should not be found since it is not part of ld.so.conf, and also the
/lib/ version *should* be found (but isn't). What has changed, is it a
standard for filesystem hierarchy, or is it something distribution
specific? (I need to pass the answer along to someone working on
customized boot software that is currently being confused by this
distinction; there is a need to find a proper means to detect libc and
linker information)

D. Stimits, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Controversy over dynamic linking -- how to end the panic

[D. Stimits]

Jonathan Lundell wrote:
 
 At 8:06 PM +0100 2001-06-21, Alan Cox wrote:
 the stdio.h, I'd tell him to go screw himself.
   What is the difference between including kernel header file and
   including GPLed header file?
 
 There are real differences between programs and interface definitions. At this
 point you get into law and the like and its probably best you read up on it
 from a reputable source not l/k
 
 Though header files don't fall clearly on the interface-definition
 side of the line. ctype.h, for example, in userland, or any other
 header with #defined or inline code.
 --
 /Jonathan Lundell.

Add to that the complications of C++ templates (not used in kernel, but
it could certainly test the law).
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Unable to handle kernel NULL pointer dereference at virtual address - 2.4.5

[D. Stimits]

Chris Leger wrote:
 
 Hi,
 
 I have the same problem, only mine occurs early in the boot process
 (right after a message saying something like trying to mount old
 root...; or maybe s/mount/unmount)so I don't have a log.  I have a
 similar system: dual PIIIs w/ Adaptec AIC-7xxx controller, an HP Kayak.
 I saw some earlier messages about AIC-7xxx problems w/ 2.4.5, so I tried
 using aic7xxx_old and also tried a patch someone mentioned.  I have yet
 to be able to bring up my machine with 2.4.5 under any combination of
 aic7xxx drivers, so maybe it's not the driver after all.
 
 Any ideas?  I built the kernel w/ gcc 2.91.66 (kgcc).

I have no problems running RH 7.l with the 2.4.5 ac series, provided I
have the patch to fs/block_dev.c (which apparently is in at around ac3;
also in 2.4.6-pre2 I think). When using an XFS filesystem patch, I also
have to use their rebuild firmware option, which I don't think is part
of ac or regular kernels. I use kgcc to compile all, and am running dual
pIII (I run without APIC because of the defective i840 chipset). All of
this is using the stock aic7xxx module or compiled in directly.

D. Stimits, [EMAIL PROTECTED]

 
 Thanks,
 
 Chris Leger
 
 Rafael Martinez writes:
  Hello
 
  I have got a error in my syslog about a Null pointer in the kernel:
 
  Kernel 2.4.5
  glibc 2.2.12
  gcc version 2.96 2731 (Red Hat Linux 7.0)
 
  Modell: ISP2150
  Motherboard: L440GX+ DP
  CPU: 2 x Intel Pentium III (Coppermine) 850 MHz L2 cache: 256K / Bus: 100 MHz
  RAM: 256 MB
  SCSI controller: Adaptec AIC-7896/7 Ultra2
 
 Unable to handle kernel NULL pointer dereference at virtual address
  0015
   printing eip:
  c014db72
  *pde = 
  Oops: 0002
  CPU:1
  EIP:0010:[c014db72]
  EFLAGS: 000
 
 --
 [ Chris Leger  ::  [EMAIL PROTECTED]   (818)393-4462 ]
 
 You can come up with a hundred reasons why a thing can't be done,
 and you have to eat them all when someone else does it.
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Threads FAQ entry incomplete

[D. Stimits]

"J.D. Bakker" wrote:
> 
> At 13:42 -0600 20-06-2001, Charles Cazabon wrote:
> >Rodrigo Ventura <[EMAIL PROTECTED]> wrote:
> >  > BTW, I have a question: Can the availability of dual-CPU boards for intel
> >>  and amd processors, rather then tri- or quadra-CPU boards, be explained with
> >>  the fact that the performance degrades significantly for three or more CPUs?
> >>  Or is there a technological and/or comercial reason behind?
> >
> >Commercial reasons.  Cost per motherboard/chipset goes way up as the number of
> >CPUs supported goes up.  For each CPU that a chipset supports, it has to add a
> >lot of pins/lands, and chipsets are already typically land-limited.
> 
> That's not quite accurate. Most modern SMP-able processors have a
> common bus, where going from 1->2 CPUs adds just a handful of extra
> nets (usually bus request, bus grant and some IRQs). The actual
> issues are threefold.

Some SMP chipset/cpu combos allow direct cache-to-cache update when a
dirty cache line is found through snooping, while the lower performance
ones don't. Wouldn't any kind of cache-to-cache direct update that
bypasses the main bus also add physical complexity (extra traces)? And
wouldn't that become more important as the number of cpu's goes up?

> 
> First, most commodity chipsets simply support no more than two CPUs
> at best; most CPUs don't support having more (or any) siblings.
> Adding more is cheap on the ASIC level, but nobody bothers because
> there is no demand.
> 
> Second, adding more CPUs on a shared bus decreases the bus bandwidth
> that is available per CPU. This is comparable with having Ethernet
> hubs vs switches. The really expensive multi-CPU boards have crossbar
> switches between CPUs, memory and PCI. Future stuff like RapidIO may
> mitigate this.
> 
> Third, the more CPUs a bus holds, the higher the capacitance on the
> bus lines. Higher capacitance means lower maximum bus speed, which
> aggravates point two.
> 
> >Motherboard trace complexity (and therefore number of layers) goes up.  Add to
> >that that the potential market goes down as CPUs goes up.
> 
> True enough.
> 
> Regards,
> 
> JDB
> [working on a SMP PowerPC design]
> --
> LART. 250 MIPS under one Watt. Free hardware design files.
> http://www.lart.tudelft.nl/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Alan Cox quote? (was: Re: accounting for threads)

[D. Stimits]

Rob Landley wrote:
...snip...
> The patches-linus-actuall-applies mailing list idea is based on how Linus
> says he works: he appends patches he likes to a file and then calls patch -p1
> < thatfile after a mail reading session.  It wouldn't be too much work for
> somebody to write a toy he could use that lets him work about the same way
> but forwards the messages to another folder where they can go out on an
> otherwise read-only list.  (No extra work for Linus.  This is EXTREMELY
> important, 'cause otherwise he'll never touch it.)

What if the file doing patches from is actually visible on a web page?
Or better yet, if the patch command itself was modified such that at the
same time it applies a patch, the source and the results were added to a
MySQL server which in turn shows as a web page?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Alan Cox quote? (was: Re: accounting for threads)

[D. Stimits]

Rob Landley wrote:
...snip...
 The patches-linus-actuall-applies mailing list idea is based on how Linus
 says he works: he appends patches he likes to a file and then calls patch -p1
  thatfile after a mail reading session.  It wouldn't be too much work for
 somebody to write a toy he could use that lets him work about the same way
 but forwards the messages to another folder where they can go out on an
 otherwise read-only list.  (No extra work for Linus.  This is EXTREMELY
 important, 'cause otherwise he'll never touch it.)

What if the file doing patches from is actually visible on a web page?
Or better yet, if the patch command itself was modified such that at the
same time it applies a patch, the source and the results were added to a
MySQL server which in turn shows as a web page?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Threads FAQ entry incomplete

[D. Stimits]

J.D. Bakker wrote:
 
 At 13:42 -0600 20-06-2001, Charles Cazabon wrote:
 Rodrigo Ventura [EMAIL PROTECTED] wrote:
BTW, I have a question: Can the availability of dual-CPU boards for intel
   and amd processors, rather then tri- or quadra-CPU boards, be explained with
   the fact that the performance degrades significantly for three or more CPUs?
   Or is there a technological and/or comercial reason behind?
 
 Commercial reasons.  Cost per motherboard/chipset goes way up as the number of
 CPUs supported goes up.  For each CPU that a chipset supports, it has to add a
 lot of pins/lands, and chipsets are already typically land-limited.
 
 That's not quite accurate. Most modern SMP-able processors have a
 common bus, where going from 1-2 CPUs adds just a handful of extra
 nets (usually bus request, bus grant and some IRQs). The actual
 issues are threefold.

Some SMP chipset/cpu combos allow direct cache-to-cache update when a
dirty cache line is found through snooping, while the lower performance
ones don't. Wouldn't any kind of cache-to-cache direct update that
bypasses the main bus also add physical complexity (extra traces)? And
wouldn't that become more important as the number of cpu's goes up?

 
 First, most commodity chipsets simply support no more than two CPUs
 at best; most CPUs don't support having more (or any) siblings.
 Adding more is cheap on the ASIC level, but nobody bothers because
 there is no demand.
 
 Second, adding more CPUs on a shared bus decreases the bus bandwidth
 that is available per CPU. This is comparable with having Ethernet
 hubs vs switches. The really expensive multi-CPU boards have crossbar
 switches between CPUs, memory and PCI. Future stuff like RapidIO may
 mitigate this.
 
 Third, the more CPUs a bus holds, the higher the capacitance on the
 bus lines. Higher capacitance means lower maximum bus speed, which
 aggravates point two.
 
 Motherboard trace complexity (and therefore number of layers) goes up.  Add to
 that that the potential market goes down as CPUs goes up.
 
 True enough.
 
 Regards,
 
 JDB
 [working on a SMP PowerPC design]
 --
 LART. 250 MIPS under one Watt. Free hardware design files.
 http://www.lart.tudelft.nl/
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ipchains

[D. Stimits]

Ted Gervais wrote:
> 
> I just ran into something odd. To me anyways, it was odd.
> I just installed and brought up kernel 2.4.5 and my ipchains failed.
> So I upgraded to the latest (that I could find) ipchains-1.3.10, and
> that also fails.
> 
> Has anyone got any version of ipchains to work with the new(er) kernels?
> 
> ---
> Doubt is not a pleasant condition, but certainty is absurd.
> -- Voltaire
> 
> Ted Gervais <[EMAIL PROTECTED]>
> 44.135.34.201 linux.ve1drg.ampr.org
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

It works, but you can't load iptables modules at the same time as
ipchains. Be sure ipchains is the only module you are loading. rmmod any
iptables items before modprobe of ipchains. If you are running redhat,
also do not believe the script in /etc/rc.d/init.d/ipchains as to
whether or not ipchains is actually running, it is broken (does not
check return values), and lies and does not tell you when ipchains
startup fails (as root manually do something like ipchains -L -n).

D. Stimits, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ipchains

[D. Stimits]

Ted Gervais wrote:
 
 I just ran into something odd. To me anyways, it was odd.
 I just installed and brought up kernel 2.4.5 and my ipchains failed.
 So I upgraded to the latest (that I could find) ipchains-1.3.10, and
 that also fails.
 
 Has anyone got any version of ipchains to work with the new(er) kernels?
 
 ---
 Doubt is not a pleasant condition, but certainty is absurd.
 -- Voltaire
 
 Ted Gervais [EMAIL PROTECTED]
 44.135.34.201 linux.ve1drg.ampr.org
 
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/

It works, but you can't load iptables modules at the same time as
ipchains. Be sure ipchains is the only module you are loading. rmmod any
iptables items before modprobe of ipchains. If you are running redhat,
also do not believe the script in /etc/rc.d/init.d/ipchains as to
whether or not ipchains is actually running, it is broken (does not
check return values), and lies and does not tell you when ipchains
startup fails (as root manually do something like ipchains -L -n).

D. Stimits, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: bzDisk compression Q; boot debug Q

[D. Stimits]

Holger Lubitz wrote:
> 
> "D. Stimits" proclaimed:
> > down to 1.44 MB. But then it would also have to be self-extracting,
> > which complicates it, so I'm wondering how effective this current
> > compression is, and if a more bzip2-like system would be beneficial as
> > kernels get larger?
> 
> bzip2 has pretty large memory requirements, consuming up to 8 MB in
> addition to the data being uncompressed.
> Although thats less of an issue now than it was some years ago, i still
> doubt that the kernel is going to be bzip2 compressed any time soon.
> 
> if you're looking for better compression, you might want to examine upx
> (http://wildsau.idv.uni-linz.ac.at/mfx/upx.html). The kernel image
> compression is still experimental, but already usable. kernels tend to
> get ~100 K smaller compared to the usual gzip compressed bzImage.

Interesting stuff...and the license is non-commercial as well.

D. Stimits, [EMAIL PROTECTED]

> 
> Holger
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: bzDisk compression Q; boot debug Q

[D. Stimits]

"Khachaturov, Vassilii" wrote:
> 
> > Question 2, apparently ramdisk uses gzip compression; the name of the
> > kernel from make bzImage seems to maybe refer to bzip2 compression. Is
> > the kernel image using gzip or bzip2 compression for bzImage? Would
> bzImage stands for "big zImage" - this is a format invented for kernels that
> don't fit into zImage. bzip2 has nothing to do with it :)

Compression is one of those areas someone is always claiming to own a
part of, so it is a pain to deal with. But I still curious, how
effective is the compression that "big zImage" uses, compared to
something like bzip2? If the algorithm is the same as what gzip uses,
I'd imagine that some of my current 1.6 MB boot images could be brought
down to 1.44 MB. But then it would also have to be self-extracting,
which complicates it, so I'm wondering how effective this current
compression is, and if a more bzip2-like system would be beneficial as
kernels get larger?

D. Stimits, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: initial ramdisk failure

[D. Stimits]

To punish myself for this silly problem, I'll be giving Bill Gates a
compliment, and pulling my toe nails out with pliers. Everything was set
up right, but the one thing I always config, "initial ramdisk", was not
set. Sorry.

D. Stimits, [EMAIL PROTECTED]


"D. Stimits" wrote:
> 
> I have been trying for a while now, without luck, to get a kernel with
> the SGI XFS system to boot as modules. I do fine if I make all scsi and
> XFS as non-modules, but modules fail for both scsi and XFS (I can make
> one or the other modular at a time, or both, it fails). According to
> what I see, this should not be happening, but it is. All messages
> indicate it was successful. I can also take the initial ramdisk image
> and gzip, and create a file that I mount via loopback to actually view
> the items it contains...no surprises, it has what it should have. But
> lilo is not using it (the messages from lilo claim to, but proof is in
> the failure). I'm going to list my output below, but the question will
> be, for an SMP scsi aic7xxx system, noapic, with ext2 compiled in, and
> /boot on its own ext2 partition (root is XFS), how is it possible that
> this output lies and does not install scsi or XFS modules? Big note:
> label with -2 is successful and has no modules; label with -3 fails, if
> any part of filesystem XFS or scsi is modular, and otherwise, there are
> no kernel configuration differences. Also, the "ramdisk_size" argument
> of the relevant kernel is due to the size of XFS, just to be sure. The
> output:
> 
> lilo.conf:
> boot=/dev/sda
> map=/boot/map
> install=/boot/boot.b
> prompt
> timeout=50
> message=/boot/message
> linear
> vga=0x030c
> default=2.4.6-p1-xfs-2
> backup=boot.backup.when-2.4.6-pre1-xfs-3
> 
> # FAILS, modular.
> image=/boot/vmlinuz-2.4.6-pre1-xfs-3
> label=2.4.6-p1-xfs-3
> initrd=/boot/ir-2.4.6-p1-xfs-3.img
> read-only
> root=/dev/sda6
> append="noapic ramdisk_size=16000"
> 
> # WORKS, no relevant modules, despite a ramdisk.
> image=/boot/vmlinuz-2.4.6-pre1-xfs-2
> label=2.4.6-p1-xfs-2
> initrd=/boot/initrd-2.4.6-pre1-xfs-2.img
> read-only
> root=/dev/sda6
> append="noapic"
> 
> Creating the ramdisk (tried both with SGI's mkinitrd.xfs, as well as
> regular mkinitrd):
> mkinitrd \
>  -v \
>  -f \
>  --preload pagebuf \
>  --preload xfs_support \
>  --preload xfs \
>  --with=scsi_mod \
>  --with=sd_mod \
>  --with=aic7xxx \
>  /boot/ir-2.4.6-p1-xfs-3.img \
>  2.4.6-pre1-xfs-3
> 
> The output of mkinitrd:
> Using modules:  ./kernel/fs/pagebuf/pagebuf.o
> ./kernel/fs/xfs_support/xfs_support.o ./kernel/fs/xfs/xfs.o
> ./kernel/drivers/scsi/scsi_mod.o ./kernel/drivers/scsi/sd_mod.o
> ./kernel/drivers/scsi/aic7xxx/aic7xxx.o
> Using loopback device /dev/loop0
> /sbin/nash -> /tmp/initrd.sXOMy4/bin/nash
> /sbin/insmod.static -> /tmp/initrd.sXOMy4/bin/insmod
> `/lib/modules/2.4.6-pre1-xfs-3/./kernel/fs/pagebuf/pagebuf.o' ->
> `/tmp/initrd.sXOMy4/lib/pagebuf.o'
> `/lib/modules/2.4.6-pre1-xfs-3/./kernel/fs/xfs_support/xfs_support.o' ->
> `/tmp/initrd.sXOMy4/lib/xfs_support.o'
> `/lib/modules/2.4.6-pre1-xfs-3/./kernel/fs/xfs/xfs.o' ->
> `/tmp/initrd.sXOMy4/lib/xfs.o'
> `/lib/modules/2.4.6-pre1-xfs-3/./kernel/drivers/scsi/scsi_mod.o' ->
> `/tmp/initrd.sXOMy4/lib/scsi_mod.o'
> `/lib/modules/2.4.6-pre1-xfs-3/./kernel/drivers/scsi/sd_mod.o' ->
> `/tmp/initrd.sXOMy4/lib/sd_mod.o'
> `/lib/modules/2.4.6-pre1-xfs-3/./kernel/drivers/scsi/aic7xxx/aic7xxx.o'
> -> `/tmp/initrd.sXOMy4/lib/aic7xxx.o'
> Loading module pagebuf with options
> Loading module xfs_support with options
> Loading module xfs with options
> Loading module scsi_mod with options
> Loading module sd_mod with options
> Loading module aic7xxx with options
> 
> The output of lilo -v -v:
> # lilo -v -v
> LILO version 21.4-4, Copyright (C) 1992-1998 Werner Almesberger
> 'lba32' extensions Copyright (C) 1999,2000 John Coffman
> 
> Reading boot sector from /dev/sda
> Merging with /boot/boot.b
> Secondary loader: 11 sectors.
> Mapping message file /boot/message
> Message: 46 sectors.
> Boot image: /boot/vmlinuz-2.4.6-pre1-xfs-3
> Setup length is 9 sectors.
> Mapped 1607 sectors.
> Mapping RAM disk /boot/ir-2.4.6-p1-xfs-3.img
> RAM disk: 1304 sectors.
> Added 2.4.6-p1-xfs-3
> Boot image: /boot/vmlinuz-2.4.6-pre1-xfs-2
> Setup length is 9 sectors.
> Mapped 2274 sectors.
> Mapping RAM disk /boot/initrd-2.4.6-pre1-xfs-2.img
> RAM disk: 500 sectors.
> Added 2.4.6-p1-xfs-2 *
> boot.backup.when-2.4.6-pre1-xfs-3 exists - no backup copy made.
> Map file size: 34304 bytes

Re: initial ramdisk failure

[D. Stimits]

To punish myself for this silly problem, I'll be giving Bill Gates a
compliment, and pulling my toe nails out with pliers. Everything was set
up right, but the one thing I always config, initial ramdisk, was not
set. Sorry.

D. Stimits, [EMAIL PROTECTED]


D. Stimits wrote:
 
 I have been trying for a while now, without luck, to get a kernel with
 the SGI XFS system to boot as modules. I do fine if I make all scsi and
 XFS as non-modules, but modules fail for both scsi and XFS (I can make
 one or the other modular at a time, or both, it fails). According to
 what I see, this should not be happening, but it is. All messages
 indicate it was successful. I can also take the initial ramdisk image
 and gzip, and create a file that I mount via loopback to actually view
 the items it contains...no surprises, it has what it should have. But
 lilo is not using it (the messages from lilo claim to, but proof is in
 the failure). I'm going to list my output below, but the question will
 be, for an SMP scsi aic7xxx system, noapic, with ext2 compiled in, and
 /boot on its own ext2 partition (root is XFS), how is it possible that
 this output lies and does not install scsi or XFS modules? Big note:
 label with -2 is successful and has no modules; label with -3 fails, if
 any part of filesystem XFS or scsi is modular, and otherwise, there are
 no kernel configuration differences. Also, the ramdisk_size argument
 of the relevant kernel is due to the size of XFS, just to be sure. The
 output:
 
 lilo.conf:
 boot=/dev/sda
 map=/boot/map
 install=/boot/boot.b
 prompt
 timeout=50
 message=/boot/message
 linear
 vga=0x030c
 default=2.4.6-p1-xfs-2
 backup=boot.backup.when-2.4.6-pre1-xfs-3
 
 # FAILS, modular.
 image=/boot/vmlinuz-2.4.6-pre1-xfs-3
 label=2.4.6-p1-xfs-3
 initrd=/boot/ir-2.4.6-p1-xfs-3.img
 read-only
 root=/dev/sda6
 append=noapic ramdisk_size=16000
 
 # WORKS, no relevant modules, despite a ramdisk.
 image=/boot/vmlinuz-2.4.6-pre1-xfs-2
 label=2.4.6-p1-xfs-2
 initrd=/boot/initrd-2.4.6-pre1-xfs-2.img
 read-only
 root=/dev/sda6
 append=noapic
 
 Creating the ramdisk (tried both with SGI's mkinitrd.xfs, as well as
 regular mkinitrd):
 mkinitrd \
  -v \
  -f \
  --preload pagebuf \
  --preload xfs_support \
  --preload xfs \
  --with=scsi_mod \
  --with=sd_mod \
  --with=aic7xxx \
  /boot/ir-2.4.6-p1-xfs-3.img \
  2.4.6-pre1-xfs-3
 
 The output of mkinitrd:
 Using modules:  ./kernel/fs/pagebuf/pagebuf.o
 ./kernel/fs/xfs_support/xfs_support.o ./kernel/fs/xfs/xfs.o
 ./kernel/drivers/scsi/scsi_mod.o ./kernel/drivers/scsi/sd_mod.o
 ./kernel/drivers/scsi/aic7xxx/aic7xxx.o
 Using loopback device /dev/loop0
 /sbin/nash - /tmp/initrd.sXOMy4/bin/nash
 /sbin/insmod.static - /tmp/initrd.sXOMy4/bin/insmod
 `/lib/modules/2.4.6-pre1-xfs-3/./kernel/fs/pagebuf/pagebuf.o' -
 `/tmp/initrd.sXOMy4/lib/pagebuf.o'
 `/lib/modules/2.4.6-pre1-xfs-3/./kernel/fs/xfs_support/xfs_support.o' -
 `/tmp/initrd.sXOMy4/lib/xfs_support.o'
 `/lib/modules/2.4.6-pre1-xfs-3/./kernel/fs/xfs/xfs.o' -
 `/tmp/initrd.sXOMy4/lib/xfs.o'
 `/lib/modules/2.4.6-pre1-xfs-3/./kernel/drivers/scsi/scsi_mod.o' -
 `/tmp/initrd.sXOMy4/lib/scsi_mod.o'
 `/lib/modules/2.4.6-pre1-xfs-3/./kernel/drivers/scsi/sd_mod.o' -
 `/tmp/initrd.sXOMy4/lib/sd_mod.o'
 `/lib/modules/2.4.6-pre1-xfs-3/./kernel/drivers/scsi/aic7xxx/aic7xxx.o'
 - `/tmp/initrd.sXOMy4/lib/aic7xxx.o'
 Loading module pagebuf with options
 Loading module xfs_support with options
 Loading module xfs with options
 Loading module scsi_mod with options
 Loading module sd_mod with options
 Loading module aic7xxx with options
 
 The output of lilo -v -v:
 # lilo -v -v
 LILO version 21.4-4, Copyright (C) 1992-1998 Werner Almesberger
 'lba32' extensions Copyright (C) 1999,2000 John Coffman
 
 Reading boot sector from /dev/sda
 Merging with /boot/boot.b
 Secondary loader: 11 sectors.
 Mapping message file /boot/message
 Message: 46 sectors.
 Boot image: /boot/vmlinuz-2.4.6-pre1-xfs-3
 Setup length is 9 sectors.
 Mapped 1607 sectors.
 Mapping RAM disk /boot/ir-2.4.6-p1-xfs-3.img
 RAM disk: 1304 sectors.
 Added 2.4.6-p1-xfs-3
 Boot image: /boot/vmlinuz-2.4.6-pre1-xfs-2
 Setup length is 9 sectors.
 Mapped 2274 sectors.
 Mapping RAM disk /boot/initrd-2.4.6-pre1-xfs-2.img
 RAM disk: 500 sectors.
 Added 2.4.6-p1-xfs-2 *
 boot.backup.when-2.4.6-pre1-xfs-3 exists - no backup copy made.
 Map file size: 34304 bytes.
 Writing boot sector.
 
 NOTE: It explicitly states Mapping RAM disk
 /boot/ir-2.4.6-p1-xfs-3.img, the relevant ramdisk. It lied. How can it
 be? I've been going at this for a couple of weeks now with no success.
 
 After using gzip -dc on the .img, and mounting it via loopback, here is
 the content of linuxrc:
 #!/bin/nash
 
 echo Loading pagebuf module
 insmod /lib/pagebuf.o
 echo Loading xfs_support module
 insmod /lib/xfs_support.o
 echo Loading xfs module
 insmod /lib/xfs.o
 echo Loading scsi_mod module
 insmod /lib/scsi_mod.o
 echo Loading

Re: bzDisk compression Q; boot debug Q

[D. Stimits]

Khachaturov, Vassilii wrote:
 
  Question 2, apparently ramdisk uses gzip compression; the name of the
  kernel from make bzImage seems to maybe refer to bzip2 compression. Is
  the kernel image using gzip or bzip2 compression for bzImage? Would
 bzImage stands for big zImage - this is a format invented for kernels that
 don't fit into zImage. bzip2 has nothing to do with it :)

Compression is one of those areas someone is always claiming to own a
part of, so it is a pain to deal with. But I still curious, how
effective is the compression that big zImage uses, compared to
something like bzip2? If the algorithm is the same as what gzip uses,
I'd imagine that some of my current 1.6 MB boot images could be brought
down to 1.44 MB. But then it would also have to be self-extracting,
which complicates it, so I'm wondering how effective this current
compression is, and if a more bzip2-like system would be beneficial as
kernels get larger?

D. Stimits, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: bzDisk compression Q; boot debug Q

[D. Stimits]

Holger Lubitz wrote:
 
 D. Stimits proclaimed:
  down to 1.44 MB. But then it would also have to be self-extracting,
  which complicates it, so I'm wondering how effective this current
  compression is, and if a more bzip2-like system would be beneficial as
  kernels get larger?
 
 bzip2 has pretty large memory requirements, consuming up to 8 MB in
 addition to the data being uncompressed.
 Although thats less of an issue now than it was some years ago, i still
 doubt that the kernel is going to be bzip2 compressed any time soon.
 
 if you're looking for better compression, you might want to examine upx
 (http://wildsau.idv.uni-linz.ac.at/mfx/upx.html). The kernel image
 compression is still experimental, but already usable. kernels tend to
 get ~100 K smaller compared to the usual gzip compressed bzImage.

Interesting stuff...and the license is non-commercial as well.

D. Stimits, [EMAIL PROTECTED]

 
 Holger
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

initial ramdisk failure

[D. Stimits]

- ram
|   |-- systty
|   |-- tty1
|   |-- tty2
|   |-- tty3
|   `-- tty4
|-- etc
|-- lib
|   |-- aic7xxx.o
|   |-- pagebuf.o
|   |-- scsi_mod.o
|   |-- sd_mod.o
|   |-- xfs.o
|   `-- xfs_support.o
|-- linuxrc
|-- loopfs
`-- sbin
|-- bin -> bin
`-- modprobe -> /bin/nash



Something is wrong, it lacks scsi support if I make scsi a module, it
lacks XFS support if I make that a module. For all intents and purposes,
lilo totally ignored the ramdisk. Any possible clues at all how this
could be?

D. Stimits, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: obsolete code must die

[D. Stimits]

Daniel wrote:
> 
> Anyone concerned about the current size of the kernel source code? I am, and
> I propose to start cleaning house on the x86 platform. I mean it's all very
> well and good to keep adding features, but stuff needs to go if kernel
> development is to move forward. Before listing the gunk I want to get rid
> of, here's my justification for doing so:
> -- Getting rid of old code can help simplify the kernel. This means less
> chance of bugs.
> -- Simplifying the kernel means that it will be easier for newbies to
> understand and perhaps contribute.
> -- a simpler, cleaner kernel will also be of more use in an academic
> environment.
> -- a smaller kernel is easier to maintain and is easier to re-architect
> should the need arise.
> -- If someone really needs support for this junk, they will always have the
> option of using the 2.0.x, 2.2.x or 2.4.x series.
> 
> So without further ado here're the features I want to get rid of:
> 
> i386, i486
> The Pentium processor has been around since 1995. Support for these older
> processors should go so we can focus on optimizations for the pentium and
> better processors.
> 
> math-emu
> If support for i386 and i486 is going away, then so should math emulation.
> Every intel processor since the 486DX has an FPU unit built in. In fact
> shouldn't FPU support be a userspace responsibility anyway?
> 
> ISA bus, MCA bus, EISA bus
> PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP,
> CONFIG_ISAPNP, etc
> 
> ISA, MCA, EISA device drivers
> If support for the buses is gone, there's no point in supporting devices for
> these buses.
> 
> all code marked as CONFIG_OBSOLETE
> Since we're cleaning house we may as well get rid of this stuff.
> 
> MFM/RLL/XT/ESDI hard drive support
> Does anyone still *have* an RLL drive that works? At the very least get rid
> of the old driver (eg CONFIG_BLK_DEV_HD_ONLY, CONFIG_BLK_DEV_HD_IDE,
> CONFIG_BLK_DEV_XD, CONFIG_BLK_DEV_PS2)
> 
> parallel/serial/game ports
> More controversial to remove this, since they are *still* in pretty wide
> use -- but USB and IEEE 1394 are the way to go. No ifs ands or buts.

This is completely wrong. USB is a hog, IEEE 1394 joysticks? Almost
every sound card out there...modern...have game ports that are useful
now. USB is an evolving and often broken standard. Your idea of obsolete
is not completely wrong, but it is far too wrong to go about it this
way. And printers or serial mice?

D. Stimits, [EMAIL PROTECTED]

> 
> a.out
> Who needs it anymore. I love ELF.
> 
> I really think doing a clean up is worthwhile. Maybe while looking for stuff
> to clean up we'll even be able to better comment the existing code. Any
> other features people would like to get rid of? Any comments or suggestions?
> I'd love to start a good discussion about this going so please send me your
> 2 cents.
> 
> Daniel
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

bzDisk compression Q; boot debug Q

[D. Stimits]

First I have a question about the compression of bzDisk. While trying to
debug the reason for a modular boot failure versus a successful
non-module boot (XFS filesystem for root), I found that I can mount my
initial ramdisk on loopback as a means of examining which modules are
available to it. However, it doesn't actually point out which modules
were loaded at the time when a filesystem mount fails. Viewing ramdisk
is via:
gzip -dc your.img > somefile
mount -o loop somefile somedir

Question 1, how hard would it be to cause failure of mount of root
filesystem to also output a list of current modules it has loaded?

Question 2, apparently ramdisk uses gzip compression; the name of the
kernel from make bzImage seems to maybe refer to bzip2 compression. Is
the kernel image using gzip or bzip2 compression for bzImage? Would
anything be gained in reducing boot size requirements by running bzip2
compression for any initial ramdisk, versus gzip compression?

D. Stimits, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

bzDisk compression Q; boot debug Q

[D. Stimits]

First I have a question about the compression of bzDisk. While trying to
debug the reason for a modular boot failure versus a successful
non-module boot (XFS filesystem for root), I found that I can mount my
initial ramdisk on loopback as a means of examining which modules are
available to it. However, it doesn't actually point out which modules
were loaded at the time when a filesystem mount fails. Viewing ramdisk
is via:
gzip -dc your.img  somefile
mount -o loop somefile somedir

Question 1, how hard would it be to cause failure of mount of root
filesystem to also output a list of current modules it has loaded?

Question 2, apparently ramdisk uses gzip compression; the name of the
kernel from make bzImage seems to maybe refer to bzip2 compression. Is
the kernel image using gzip or bzip2 compression for bzImage? Would
anything be gained in reducing boot size requirements by running bzip2
compression for any initial ramdisk, versus gzip compression?

D. Stimits, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: obsolete code must die

[D. Stimits]

Daniel wrote:
 
 Anyone concerned about the current size of the kernel source code? I am, and
 I propose to start cleaning house on the x86 platform. I mean it's all very
 well and good to keep adding features, but stuff needs to go if kernel
 development is to move forward. Before listing the gunk I want to get rid
 of, here's my justification for doing so:
 -- Getting rid of old code can help simplify the kernel. This means less
 chance of bugs.
 -- Simplifying the kernel means that it will be easier for newbies to
 understand and perhaps contribute.
 -- a simpler, cleaner kernel will also be of more use in an academic
 environment.
 -- a smaller kernel is easier to maintain and is easier to re-architect
 should the need arise.
 -- If someone really needs support for this junk, they will always have the
 option of using the 2.0.x, 2.2.x or 2.4.x series.
 
 So without further ado here're the features I want to get rid of:
 
 i386, i486
 The Pentium processor has been around since 1995. Support for these older
 processors should go so we can focus on optimizations for the pentium and
 better processors.
 
 math-emu
 If support for i386 and i486 is going away, then so should math emulation.
 Every intel processor since the 486DX has an FPU unit built in. In fact
 shouldn't FPU support be a userspace responsibility anyway?
 
 ISA bus, MCA bus, EISA bus
 PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP,
 CONFIG_ISAPNP, etc
 
 ISA, MCA, EISA device drivers
 If support for the buses is gone, there's no point in supporting devices for
 these buses.
 
 all code marked as CONFIG_OBSOLETE
 Since we're cleaning house we may as well get rid of this stuff.
 
 MFM/RLL/XT/ESDI hard drive support
 Does anyone still *have* an RLL drive that works? At the very least get rid
 of the old driver (eg CONFIG_BLK_DEV_HD_ONLY, CONFIG_BLK_DEV_HD_IDE,
 CONFIG_BLK_DEV_XD, CONFIG_BLK_DEV_PS2)
 
 parallel/serial/game ports
 More controversial to remove this, since they are *still* in pretty wide
 use -- but USB and IEEE 1394 are the way to go. No ifs ands or buts.

This is completely wrong. USB is a hog, IEEE 1394 joysticks? Almost
every sound card out there...modern...have game ports that are useful
now. USB is an evolving and often broken standard. Your idea of obsolete
is not completely wrong, but it is far too wrong to go about it this
way. And printers or serial mice?

D. Stimits, [EMAIL PROTECTED]

 
 a.out
 Who needs it anymore. I love ELF.
 
 I really think doing a clean up is worthwhile. Maybe while looking for stuff
 to clean up we'll even be able to better comment the existing code. Any
 other features people would like to get rid of? Any comments or suggestions?
 I'd love to start a good discussion about this going so please send me your
 2 cents.
 
 Daniel
 
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: missing sysrq

[D. Stimits]

"Mike A. Harris" wrote:
> 
> On Fri, 1 Jun 2001, Dieter Nützel wrote:
> 
> >> > In article <[EMAIL PROTECTED]> you wrote:
> >> > > However, if I go to /proc/sys/kernel/sysrq does not exist.
> >> >
> >> > It is a compile time option, so the person who compiled your kernel
> >> > left it out.
> >>
> >> I compiled it, and the sysrq is definitely in the config. No doubt at
> >> all. I also use make mrproper and config again before dep and actual
> >> compile. Maybe it is just a quirk/oddball.
> >>
> >> D. Stimits, [EMAIL PROTECTED]
> >
> >Have you tried "echo 1 > /proc/sys/kernel/sysrq"?
> >You need both, compiled in and activation.

Since then I've completely removed that kernel source and kernel, only
the config file remains (and it had it activated if the config followed
it). All kernels before worked, and those since then also work, so I
know it isn't the keyboard. I also always run make mrproper and config
it again between compiles (I keep a list of config history), so I don't
know what was wrong, but replacing the kernel fixed it, and is no longer
an issue. I will, however, keep the showkey suggestion handy in case it
ever does it again.

D. Stimits, [EMAIL PROTECTED]

> 
> If you *know* it is compiled into your kernel, and you *know* it
> is enabled via the above, and it still does not work, do the
> following:
> 
> Run:
> 
> showkey -s
> 
> Then press LALT quickly followed by SYSRQ, and keep holding both
> down, and you should see:
> 
> 0x38
> 0x54
> 
> You might see a bunch of extra 0x38's which is ok.
> 
> If however when you press ALT-SYSRQ you see:
> 
> 0x38 0x54 0xd4
> 
> and are still holding both keys down, then your keyboard is
> broken and incompatible with the kernel SYSRQ feature.
> 
> A proper keyboard will only show "0x38 0x54".  I have written a
> patch for SYSRQ to allow it to be used with broken keyboards that
> send the make+break code for the SYSRQ sequence simultaneously.
> 
> If you need it, let me know and I'll send it to you.
> 
> --
> Mike A. Harris  -  Linux advocate  -  Open Source advocate
>Opinions and viewpoints expressed are solely my own.
> --
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.6 pre1 and 2.4.5 CONFIG_IP_NF_COMPAT_IPCHAINS missing?

[D. Stimits]

"D. Stimits" wrote:
> 
> I know somewhere there is a menuconfig item corresponding to
> CONFIG_IP_NF_COMPAT_IPCHAINS, and that selecting various other iptables
> options can make this item disappear and no longer be selectable. But I
> have fished all over, have set config to give devel and incomplete
> items, tried turning on or off anything possibly related to iptables,
> and cannot find this item in the make menuconfig. It still exists in
> Documentation/Configure.help, so I assume this has not yet been removed
> from available kernel compile options. I've been searching for the means
> to interactively select this item, with no luck. Can anyone tell me if
> ipchains compatibility has been removed from current config options? If
> not, how it can be selected, or if it is broken?
> 
> D. Stimits, [EMAIL PROTECTED]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


Nevermind, I found the item in question. Turns out that the option is
added to the config menu, but not under the item that activated the
option...most of the way down the menu instead, so I didn't see it.

D. Stimits, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.4.6 pre1 and 2.4.5 CONFIG_IP_NF_COMPAT_IPCHAINS missing?

[D. Stimits]

I know somewhere there is a menuconfig item corresponding to
CONFIG_IP_NF_COMPAT_IPCHAINS, and that selecting various other iptables
options can make this item disappear and no longer be selectable. But I
have fished all over, have set config to give devel and incomplete
items, tried turning on or off anything possibly related to iptables,
and cannot find this item in the make menuconfig. It still exists in
Documentation/Configure.help, so I assume this has not yet been removed
from available kernel compile options. I've been searching for the means
to interactively select this item, with no luck. Can anyone tell me if
ipchains compatibility has been removed from current config options? If
not, how it can be selected, or if it is broken?

D. Stimits, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.4.6 pre1 and 2.4.5 CONFIG_IP_NF_COMPAT_IPCHAINS missing?

[D. Stimits]

I know somewhere there is a menuconfig item corresponding to
CONFIG_IP_NF_COMPAT_IPCHAINS, and that selecting various other iptables
options can make this item disappear and no longer be selectable. But I
have fished all over, have set config to give devel and incomplete
items, tried turning on or off anything possibly related to iptables,
and cannot find this item in the make menuconfig. It still exists in
Documentation/Configure.help, so I assume this has not yet been removed
from available kernel compile options. I've been searching for the means
to interactively select this item, with no luck. Can anyone tell me if
ipchains compatibility has been removed from current config options? If
not, how it can be selected, or if it is broken?

D. Stimits, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.6 pre1 and 2.4.5 CONFIG_IP_NF_COMPAT_IPCHAINS missing?

[D. Stimits]

D. Stimits wrote:
 
 I know somewhere there is a menuconfig item corresponding to
 CONFIG_IP_NF_COMPAT_IPCHAINS, and that selecting various other iptables
 options can make this item disappear and no longer be selectable. But I
 have fished all over, have set config to give devel and incomplete
 items, tried turning on or off anything possibly related to iptables,
 and cannot find this item in the make menuconfig. It still exists in
 Documentation/Configure.help, so I assume this has not yet been removed
 from available kernel compile options. I've been searching for the means
 to interactively select this item, with no luck. Can anyone tell me if
 ipchains compatibility has been removed from current config options? If
 not, how it can be selected, or if it is broken?
 
 D. Stimits, [EMAIL PROTECTED]
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/


Nevermind, I found the item in question. Turns out that the option is
added to the config menu, but not under the item that activated the
option...most of the way down the menu instead, so I didn't see it.

D. Stimits, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: missing sysrq

[D. Stimits]

Mike A. Harris wrote:
 
 On Fri, 1 Jun 2001, Dieter Nützel wrote:
 
   In article [EMAIL PROTECTED] you wrote:
However, if I go to /proc/sys/kernel/sysrq does not exist.
  
   It is a compile time option, so the person who compiled your kernel
   left it out.
 
  I compiled it, and the sysrq is definitely in the config. No doubt at
  all. I also use make mrproper and config again before dep and actual
  compile. Maybe it is just a quirk/oddball.
 
  D. Stimits, [EMAIL PROTECTED]
 
 Have you tried echo 1  /proc/sys/kernel/sysrq?
 You need both, compiled in and activation.

Since then I've completely removed that kernel source and kernel, only
the config file remains (and it had it activated if the config followed
it). All kernels before worked, and those since then also work, so I
know it isn't the keyboard. I also always run make mrproper and config
it again between compiles (I keep a list of config history), so I don't
know what was wrong, but replacing the kernel fixed it, and is no longer
an issue. I will, however, keep the showkey suggestion handy in case it
ever does it again.

D. Stimits, [EMAIL PROTECTED]

 
 If you *know* it is compiled into your kernel, and you *know* it
 is enabled via the above, and it still does not work, do the
 following:
 
 Run:
 
 showkey -s
 
 Then press LALT quickly followed by SYSRQ, and keep holding both
 down, and you should see:
 
 0x38
 0x54
 
 You might see a bunch of extra 0x38's which is ok.
 
 If however when you press ALT-SYSRQ you see:
 
 0x38 0x54 0xd4
 
 and are still holding both keys down, then your keyboard is
 broken and incompatible with the kernel SYSRQ feature.
 
 A proper keyboard will only show 0x38 0x54.  I have written a
 patch for SYSRQ to allow it to be used with broken keyboards that
 send the make+break code for the SYSRQ sequence simultaneously.
 
 If you need it, let me know and I'll send it to you.
 
 --
 Mike A. Harris  -  Linux advocate  -  Open Source advocate
Opinions and viewpoints expressed are solely my own.
 --
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: missing sysrq

[D. Stimits]

Dieter Nützel wrote:
> 
> > D. Stimits wrote:
> >
> > > Bernd Eckenfels wrote:
> > > >
> > > In article <[EMAIL PROTECTED]> you wrote:
> > > > However, if I go to /proc/sys/kernel/sysrq does not exist.
> > >
> > > It is a compile time option, so the person who compiled your kernel
> > > left it out.
> >
> > I compiled it, and the sysrq is definitely in the config. No doubt at
> > all. I also use make mrproper and config again before dep and actual
> > compile. Maybe it is just a quirk/oddball.
> >
> > D. Stimits, [EMAIL PROTECTED]
> 
> Have you tried "echo 1 > /proc/sys/kernel/sysrq"?
> You need both, compiled in and activation.

It is compiled in, but the echo is summarily rejected. Root is not
allowed to write to that file, which doesn't exist. I'm going to just
wipe out everything from that kernel and redo the whole thing.

D. Stimits, [EMAIL PROTECTED]

> 
> Regards,
> Dieter
> --
> Dieter Nützel
> Graduate Student, Computer Science
> 
> email: [EMAIL PROTECTED]
> @home: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: missing sysrq

[D. Stimits]

Dieter Nützel wrote:
 
  D. Stimits wrote:
 
   Bernd Eckenfels wrote:
   
   In article [EMAIL PROTECTED] you wrote:
However, if I go to /proc/sys/kernel/sysrq does not exist.
  
   It is a compile time option, so the person who compiled your kernel
   left it out.
 
  I compiled it, and the sysrq is definitely in the config. No doubt at
  all. I also use make mrproper and config again before dep and actual
  compile. Maybe it is just a quirk/oddball.
 
  D. Stimits, [EMAIL PROTECTED]
 
 Have you tried echo 1  /proc/sys/kernel/sysrq?
 You need both, compiled in and activation.

It is compiled in, but the echo is summarily rejected. Root is not
allowed to write to that file, which doesn't exist. I'm going to just
wipe out everything from that kernel and redo the whole thing.

D. Stimits, [EMAIL PROTECTED]

 
 Regards,
 Dieter
 --
 Dieter Nützel
 Graduate Student, Computer Science
 
 email: [EMAIL PROTECTED]
 @home: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: missing sysrq

[D. Stimits]

Bernd Eckenfels wrote:
> 
> In article <[EMAIL PROTECTED]> you wrote:
> > However, if I go to /proc/sys/kernel/sysrq does not exist.
> 
> It is a compile time option, so the person who compiled your kernel left it
> out.

I compiled it, and the sysrq is definitely in the config. No doubt at
all. I also use make mrproper and config again before dep and actual
compile. Maybe it is just a quirk/oddball.

D. Stimits, [EMAIL PROTECTED]

> 
> > vm.freepages = 383 766 1149
> 
> tat feature is removed in recent VM Systems.
> 
> Greetings
> Bernd
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

missing sysrq

[D. Stimits]

I have compiled the magic sysrq as enabled in most kernels I've used for
quite a while. Most recently 2.4.5-ac5, on a RH 7.1 SMP machine with
APIC disabled. The /etc/sysctl.conf contains this line:
kernel.sysrq = 1

However, if I go to /proc/sys/kernel/sysrq does not exist. Nor is it
possible for root to echo to that file name. Attempts to use the magic
sysrq keys, such as for sync, prove that it truly is not enabled, or is
otherwise missing. Has something changed in the enabling of magic sysrq?
Or is this one of those strange "it should be there" things?

A second observation, maybe related (maybe not), is the
/var/log/messages line:
sysctl: error: permission denied on key 'vm.freepages'

This particular line has occurred since install of RH 7.1, even with its
original kernel, but continues into 2.4.5-ac5. The relevant line in
/etc/sysctl.conf:
vm.freepages = 383 766 1149

This line is how the original RH 7.1 install set it up. This particular
machine has 256 MB of ram, and somewhat over a 1 GB of swap. Is the
vm.freepages not intended to be set in /etc/sysctl.conf? Or maybe the
specs are off for this particular hardware? I know a lot of vm changes
are going on in the kernel, and wondering if this could be something
that used to be supported but no longer is.

D. Stimits, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

missing sysrq

[D. Stimits]

I have compiled the magic sysrq as enabled in most kernels I've used for
quite a while. Most recently 2.4.5-ac5, on a RH 7.1 SMP machine with
APIC disabled. The /etc/sysctl.conf contains this line:
kernel.sysrq = 1

However, if I go to /proc/sys/kernel/sysrq does not exist. Nor is it
possible for root to echo to that file name. Attempts to use the magic
sysrq keys, such as for sync, prove that it truly is not enabled, or is
otherwise missing. Has something changed in the enabling of magic sysrq?
Or is this one of those strange it should be there things?

A second observation, maybe related (maybe not), is the
/var/log/messages line:
sysctl: error: permission denied on key 'vm.freepages'

This particular line has occurred since install of RH 7.1, even with its
original kernel, but continues into 2.4.5-ac5. The relevant line in
/etc/sysctl.conf:
vm.freepages = 383 766 1149

This line is how the original RH 7.1 install set it up. This particular
machine has 256 MB of ram, and somewhat over a 1 GB of swap. Is the
vm.freepages not intended to be set in /etc/sysctl.conf? Or maybe the
specs are off for this particular hardware? I know a lot of vm changes
are going on in the kernel, and wondering if this could be something
that used to be supported but no longer is.

D. Stimits, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: missing sysrq

[D. Stimits]

Bernd Eckenfels wrote:
 
 In article [EMAIL PROTECTED] you wrote:
  However, if I go to /proc/sys/kernel/sysrq does not exist.
 
 It is a compile time option, so the person who compiled your kernel left it
 out.

I compiled it, and the sysrq is definitely in the config. No doubt at
all. I also use make mrproper and config again before dep and actual
compile. Maybe it is just a quirk/oddball.

D. Stimits, [EMAIL PROTECTED]

 
  vm.freepages = 383 766 1149
 
 tat feature is removed in recent VM Systems.
 
 Greetings
 Bernd
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.5 Oops at boot

[D. Stimits]

Chris Mason wrote:
> 
> On Wednesday, May 30, 2001 03:03:32 PM -0600 "D. Stimits"
> <[EMAIL PROTECTED]> wrote:
> 
> [ snip ]
> 
> > RAMDISK: Compressed image found at block 0
> > Freeing initrd memory: 249k freed
> > VFS: Mounted root (ext2 filesystem).
> > Red Hat nash version 3.0.10 starting
> > VFS: Mounted root (ext2 filesystem) readonly.
> > change_root: old root has d_count=2
> > Trying to unmount old root ... <1>Unable to handle kernel NULL pointer
> > dereference at virtual address 0010
> >  printing eip:
> 
> Can't say for sure without the oops decoded through ksymoops, but this
> looks like the oops in rd_ioctl fixed by 2.4.5-ac3 and higher.  I think the
> following patch (taken from ac3) will be sufficient:
> 
> -chris
> 
> --- linux.vanilla/fs/block_dev.cSat May 26 16:53:17 2001
> +++ linux.ac/fs/block_dev.c Mon May 28 16:10:59 2001
> @@ -603,6 +602,7 @@
> if (!bdev->bd_op->ioctl)
> return -EINVAL;
> inode_fake.i_rdev=rdev;
> +   inode_fake.i_bdev=bdev;
> init_waitqueue_head(_fake.i_wait);
> set_fs(KERNEL_DS);
> res = bdev->bd_op->ioctl(_fake, NULL, cmd, arg);

I'm just verifying that this one change was sufficient to allow booting
from a hard disk install. I'm still trying to figure out why "make
bzdisk" is failing, I will try the ac5 patch next.

Thanks,
D. Stimits, [EMAIL PROTECTED]

PS: Is it possible to read a floppy image directly (for example, after
dd to a file), and tell if it is overrunning its maximum size limit? For
example, the partition records always end with 55 AA, is there something
I can look for to determine if a floppy image has gone too far?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.4.5 Oops at boot

[D. Stimits]

I have two systems, one running RH 7.1 as base, the other RH 7.1 beta.
Both are x86 SMP. The following Oops is from the RH 7.1 machine
(non-beta) for kernel 2.4.5 (compiled with kgcc, no patches). Please
note that both machines will fail to create a bootable floppy with make
bzdisk; I have tried half a dozen separate floppies from separate boxes.
Both will boot from floppy made through mkbootdisk. Both have scsi
compiled directly in, and are not modules. Both use aic7xxx. The machine
with Oops being reported on is being booted "noapic", since it is the
i840 chipset (the other machine is BX chipset).

The following bootup message excerpt should be accurate, but I had to
type this whole thing in by hand, since the system dies. I went through
a lot of effort to make sure there were no typo's, but there is still a
very minor possibility of such. It isn't possible to list lspci -vv for
the failed kernel, which is requested in the boot message at one point,
so I have to do this through the RH stock 2.4.2 SMP kernel of RH 7.1.
Kernel config for this is attached.

D. Stimits, [EMAIL PROTECTED]

Bootup:
...
...
...
Redundant entry in serial pci_table.  Please send the output of
lspci -vv, this message (4793,4104,4793,173)
...
...
...
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 249k freed
VFS: Mounted root (ext2 filesystem).
Red Hat nash version 3.0.10 starting
VFS: Mounted root (ext2 filesystem) readonly.
change_root: old root has d_count=2
Trying to unmount old root ... <1>Unable to handle kernel NULL pointer
dereference at virtual address 0010
 printing eip:
c01c5bda
*pde = 
Oops: 
CPU:1
EIP:0010:[]
EFLAGS: 00010202
eax:    ebx:    ecx: 1261   edx: c1479d98
esi:    edi: c1479e2c   ebp:    esp: c1479d68
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 1, stackpage=c1479000)
Stack: c1478000 cfe97f60 c1479e2c c013b0fb c1479d98  1261

   cfeac560  fffe cfe97f60 cff06ea4 cff06e10 c0346340
0001def6
   cfef0001 c01ea7b2 cff06e00 0082 0202 c14e1cb8 cfef8200
cff07e60
Call Trace: [] [] [] []
[] [] []
   [] [] [] [] []
[] [] []
   [] [] []

Code: 8b 40 10 83 f8 02 7e 0e b8 f0 ff ff ff eb 7e 8d b4 26 00 00
Kernel panic: Attempted to kill init!




>From lspci -vv:
~# lspci -vv
00:00.0 Host bridge: Intel Corporation 82840 840 (Carmel) Chipset Host
Bridge (Hub A) (rev 01)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:01.0 PCI bridge: Intel Corporation 82840 840 (Carmel) Chipset AGP
Bridge (rev 01) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Reset- FastB2B-

00:02.0 PCI bridge: Intel Corporation 82840 840 (Carmel) Chipset PCI
Bridge (Hub B) (rev 01) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Reset- FastB2B-

00:1e.0 PCI bridge: Intel Corporation 82801AA PCI Bridge (rev 02)
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Reset- FastB2B-

00:1f.0 ISA bridge: Intel Corporation 82801AA ISA Bridge (LPC) (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort- SERR- Reset- FastB2B-

03:00.0 PIC: Intel Corporation 82806AA PCI64 Hub Advanced Programmable
Interrupt Controller (rev 01) (prog-if 20 [IO(X)-APIC])
Subsystem: Intel Corporation 82806AA PCI64 Hub Advanced Programmable
Interrupt Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort-
SERR- TAbort-
SERR- 

#
# Automatically generated by make menuconfig: don't edit
#
CONFIG_X86=y
CONFIG_ISA=y
# CONFIG_SBUS is not set
CONFIG_UID16=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
CONFIG_MPENTIUMIII=y
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is 

2.4.5 Oops at boot

[D. Stimits]

I have two systems, one running RH 7.1 as base, the other RH 7.1 beta.
Both are x86 SMP. The following Oops is from the RH 7.1 machine
(non-beta) for kernel 2.4.5 (compiled with kgcc, no patches). Please
note that both machines will fail to create a bootable floppy with make
bzdisk; I have tried half a dozen separate floppies from separate boxes.
Both will boot from floppy made through mkbootdisk. Both have scsi
compiled directly in, and are not modules. Both use aic7xxx. The machine
with Oops being reported on is being booted noapic, since it is the
i840 chipset (the other machine is BX chipset).

The following bootup message excerpt should be accurate, but I had to
type this whole thing in by hand, since the system dies. I went through
a lot of effort to make sure there were no typo's, but there is still a
very minor possibility of such. It isn't possible to list lspci -vv for
the failed kernel, which is requested in the boot message at one point,
so I have to do this through the RH stock 2.4.2 SMP kernel of RH 7.1.
Kernel config for this is attached.

D. Stimits, [EMAIL PROTECTED]

Bootup:
...
...
...
Redundant entry in serial pci_table.  Please send the output of
lspci -vv, this message (4793,4104,4793,173)
...
...
...
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 249k freed
VFS: Mounted root (ext2 filesystem).
Red Hat nash version 3.0.10 starting
VFS: Mounted root (ext2 filesystem) readonly.
change_root: old root has d_count=2
Trying to unmount old root ... 1Unable to handle kernel NULL pointer
dereference at virtual address 0010
 printing eip:
c01c5bda
*pde = 
Oops: 
CPU:1
EIP:0010:[c01c5bda]
EFLAGS: 00010202
eax:    ebx:    ecx: 1261   edx: c1479d98
esi:    edi: c1479e2c   ebp:    esp: c1479d68
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 1, stackpage=c1479000)
Stack: c1478000 cfe97f60 c1479e2c c013b0fb c1479d98  1261

   cfeac560  fffe cfe97f60 cff06ea4 cff06e10 c0346340
0001def6
   cfef0001 c01ea7b2 cff06e00 0082 0202 c14e1cb8 cfef8200
cff07e60
Call Trace: [c013b0fb] [c01ea7b2] [c0112912] [c01bd021]
[c01c5b69] [c01bdd44] [c01374cd]
   [c012dcef] [c0124bc9] [c0147e3f] [c014961b] [c013b3d4]
[c0139027] [c013825c] [c0106efb]
   [c01051d8] [c010522a] [c01056fb]

Code: 8b 40 10 83 f8 02 7e 0e b8 f0 ff ff ff eb 7e 8d b4 26 00 00
Kernel panic: Attempted to kill init!




From lspci -vv:
~# lspci -vv
00:00.0 Host bridge: Intel Corporation 82840 840 (Carmel) Chipset Host
Bridge (Hub A) (rev 01)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort-
MAbort+ SERR- PERR+
Latency: 0
Region 0: Memory at f000 (32-bit, prefetchable) [size=128M]
Capabilities: [a0] AGP version 2.0
Status: RQ=31 SBA+ 64bit- FW+ Rate=x1,x2
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=none

00:01.0 PCI bridge: Intel Corporation 82840 840 (Carmel) Chipset AGP
Bridge (rev 01) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort-
MAbort- SERR- PERR-
Latency: 64
Bus: primary=00, secondary=04, subordinate=04, sec-latency=64
I/O behind bridge: d000-dfff
Memory behind bridge: fca0-feaf
Prefetchable memory behind bridge: dc10-ec1f
BridgeCtl: Parity+ SERR+ NoISA- VGA+ MAbort- Reset- FastB2B-

00:02.0 PCI bridge: Intel Corporation 82840 840 (Carmel) Chipset PCI
Bridge (Hub B) (rev 01) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort-
MAbort- SERR- PERR-
Latency: 64
Bus: primary=00, secondary=02, subordinate=03, sec-latency=64
I/O behind bridge: b000-cfff
Memory behind bridge: fc80-fc9f
Prefetchable memory behind bridge: dbf0-dc0f
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- Reset- FastB2B-

00:1e.0 PCI bridge: Intel Corporation 82801AA PCI Bridge (rev 02)
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort-
MAbort- SERR- PERR-
Latency: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
I/O behind bridge: a000-afff
Memory behind bridge: fc30-fc7f
Prefetchable memory behind bridge: dbe0-dbef
BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- Reset- FastB2B-

00:1f.0 ISA bridge: Intel Corporation 82801AA ISA Bridge (LPC) (rev 02)
Control: I/O

Re: 2.4.5 Oops at boot

[D. Stimits]

Chris Mason wrote:
 
 On Wednesday, May 30, 2001 03:03:32 PM -0600 D. Stimits
 [EMAIL PROTECTED] wrote:
 
 [ snip ]
 
  RAMDISK: Compressed image found at block 0
  Freeing initrd memory: 249k freed
  VFS: Mounted root (ext2 filesystem).
  Red Hat nash version 3.0.10 starting
  VFS: Mounted root (ext2 filesystem) readonly.
  change_root: old root has d_count=2
  Trying to unmount old root ... 1Unable to handle kernel NULL pointer
  dereference at virtual address 0010
   printing eip:
 
 Can't say for sure without the oops decoded through ksymoops, but this
 looks like the oops in rd_ioctl fixed by 2.4.5-ac3 and higher.  I think the
 following patch (taken from ac3) will be sufficient:
 
 -chris
 
 --- linux.vanilla/fs/block_dev.cSat May 26 16:53:17 2001
 +++ linux.ac/fs/block_dev.c Mon May 28 16:10:59 2001
 @@ -603,6 +602,7 @@
 if (!bdev-bd_op-ioctl)
 return -EINVAL;
 inode_fake.i_rdev=rdev;
 +   inode_fake.i_bdev=bdev;
 init_waitqueue_head(inode_fake.i_wait);
 set_fs(KERNEL_DS);
 res = bdev-bd_op-ioctl(inode_fake, NULL, cmd, arg);

I'm just verifying that this one change was sufficient to allow booting
from a hard disk install. I'm still trying to figure out why make
bzdisk is failing, I will try the ac5 patch next.

Thanks,
D. Stimits, [EMAIL PROTECTED]

PS: Is it possible to read a floppy image directly (for example, after
dd to a file), and tell if it is overrunning its maximum size limit? For
example, the partition records always end with 55 AA, is there something
I can look for to determine if a floppy image has gone too far?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

bzdisk broken in 2.4.5?

[D. Stimits]

I've tried on two separate machines to test out 2.4.5 through the "make
bzdisk" boot floppy, and it fails on both (the compile succeeds, but
boot never gets to LILO, it simply gives "400" and a repeating list of
AX, BX, CX, and DX registers). Both are scsi aic7xxx, but use different
controllers, and have scsi directly compiled in. One machine is based on
RH 7.1 beta, the other on RH 7.1. Both are x86 SMP, with motherboard and
all hardware being different. Using the same kernel through a
"mkbootdisk" works, only "make bzdisk" fails. Can anyone here verify
that "make bzdisk" will create a bootable floppy (I did try an entire
box of different floppies) on 2.4.5+? Especially, can anyone verify this
for SMP and/or purely scsi machines? If scsi, do you use aic7xxx?

D. Stimits, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

bzdisk broken in 2.4.5?

[D. Stimits]

I've tried on two separate machines to test out 2.4.5 through the make
bzdisk boot floppy, and it fails on both (the compile succeeds, but
boot never gets to LILO, it simply gives 400 and a repeating list of
AX, BX, CX, and DX registers). Both are scsi aic7xxx, but use different
controllers, and have scsi directly compiled in. One machine is based on
RH 7.1 beta, the other on RH 7.1. Both are x86 SMP, with motherboard and
all hardware being different. Using the same kernel through a
mkbootdisk works, only make bzdisk fails. Can anyone here verify
that make bzdisk will create a bootable floppy (I did try an entire
box of different floppies) on 2.4.5+? Especially, can anyone verify this
for SMP and/or purely scsi machines? If scsi, do you use aic7xxx?

D. Stimits, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/