Re: Bootint big kernels
On Thu, Jun 11, 1998 at 06:10:16PM -0500, Martin Alonso Soto Jacome wrote: > Steve Dunham <[EMAIL PROTECTED]> wrote: > > The only isapnp devices I know of are audio. Are there any SCSI or > > enet devices? (If so a table would be necessary as they are discovered.) > > Yes, a lot of modern soundcards include an IDE controller, that is usually > configured with PnP. Also, my current network card (a 3Com 3c509) is also > ISA > PnP. I had to move it by hand to the non-PnP mode in order to use it with > Linux. And internal modems. I have three PnP modems in my dialin server, although two have PnP disabled because they are badly behaved (they both have the same board ID, exactly). Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bootint big kernels
Previously Steve Dunham wrote: > The only isapnp devices I know of are audio. Are there any SCSI or > enet devices? (If so a table would be necessary as they are discovered.) Yes, my adaptec 152x card is PnP. hint: don't use isapnp after booting from a PnP scsi-card! Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpryDbdHi8gC.pgp Description: PGP signature
Re: Bootint big kernels
Steve Dunham <[EMAIL PROTECTED]> wrote: > The only isapnp devices I know of are audio. Are there any SCSI or > enet devices? (If so a table would be necessary as they are discovered.) Yes, a lot of modern soundcards include an IDE controller, that is usually configured with PnP. Also, my current network card (a 3Com 3c509) is also ISA PnP. I had to move it by hand to the non-PnP mode in order to use it with Linux. > Digging through INF files in windows 95 would be a start. This is > something that should be closely coordinated with the ISApnp > utilities. Yes, again. I recall somebody else asking about getting info from Window$ for a similar purpose (monitor configuration, I think). The problem there could be the copyright of that information, that probably belongs to MS or their partners. I would be a good idea to find out about that before proceeding. > There is a kernel patch to initialize them, and I have a patch to GRUB > to pass the right magic to the kernel patch, but I don't use it right > now. (Not necessary, since my only ISApnp device is not critical to > booting.) Is that Tom Lees' patch? I'll give it a try these days just to see if it is suitable for this purpose. Regards, M. S. Martin A. Soto J. Profesor Departamento de Ingenieria de Sistemas y Computacion Universidad de los Andes [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bootint big kernels
Enrique Zanardi <[EMAIL PROTECTED]> writes: > On Thu, Jun 11, 1998 at 11:45:56AM -0500, Martin Alonso Soto Jacome wrote: > > Dale Scheetz <[EMAIL PROTECTED]> wrote: > > > I have wondered why we didn't try this once the kernel supported initrd. > > > To be honest I haven't figured out yet how to do the device selection, > > > other than going through a list of drivers, trying to insmod each one > > > until you are successful. > > > > Wouldn't PCI and ISA PnP support help here? Standard 2.0.x kernels support > > /proc/pci since a long time, so it should be possible to check the device > > names on /proc/pci against a table in order to load the apropriate modules. > > > > That's what Red Hat does, and what I plan to implement for slink. It > doesn't work for ISA cards though, therefore I plan to implement a method > for manually selecting modules at install time as well (probably a > modified "modconf"). You should boot the FreeBSD install disk once for ideas too. > > It should also be possible to deal with PnP just the same way, > Yes, but we will have to create the "device -> module" table from > scratch, as I don't know of anyone that maintains such a table. The only isapnp devices I know of are audio. Are there any SCSI or enet devices? (If so a table would be necessary as they are discovered.) Digging through INF files in windows 95 would be a start. This is something that should be closely coordinated with the ISApnp utilities. > > although I > don't know what the status of the PnP support in the > kernel is right now. > None AFAIK. PnP devices are configured with user-space tools (pnpdump and > isapnp). There is a kernel patch to initialize them, and I have a patch to GRUB to pass the right magic to the kernel patch, but I don't use it right now. (Not necessary, since my only ISApnp device is not critical to booting.) Steve [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bootint big kernels
Dale Scheetz <[EMAIL PROTECTED]> writes:
> On Thu, 11 Jun 1998, Enrique Zanardi wrote:
> > On Thu, Jun 11, 1998 at 09:41:03AM -0400, Dale Scheetz wrote:
> > > The problem is that the Debian installation kernel tries to be all things
> > > to all people. As there are machines that boot from SCSI drives, it was
> > > necessary to have all the scsi controlers "built in" to the kernel, hense
> > > its large size.
> > > We should recommend that everyone, once they have a standard system and
> > > can build a kernel, should build a custom kernel for their machine as
> > > early as possible.
> > > Another solution is the one that slackware provides. They build a "bunch"
> > > of kernels, each one for a specific hardware configuration (broad enought
> > > to cover a range of hardware, and chosen to keep incopatibly drivers out
> > > of the picture {like the wd9000 driver that plonks ethernet cards})
> > I'm working on a better solution that involves using initrd to
> > load the required controllers (built as loadable modules). I've tested
> > using initrd for lowmem installations and it works flawlessly (just have
> > a look at lowmem boot disk in boot-floppies_2.0.7 when I upload it next
> > weekend).
> I have wondered why we didn't try this once the kernel supported initrd.
> To be honest I haven't figured out yet how to do the device selection,
> other than going through a list of drivers, trying to insmod each one
> until you are successful.
Red Hat does this, we might want to look at their code. (Even after
the install you end up with both a kernel and an initrd image
containing the exact drivers you need in /boot - they mainly use this
for SCSI drivers - they might also do PCMCIA SCSI there, but I'm not
sure.)
They have a script to rebuild the initrd for newly compiled kernels,
but I usually just compile the drivers in.
> I would love to see your solution for this, even in whatever the current
> state is.
IIRC, they do some of the device selection via /proc/pci. I believe
they do this for ethernet and Video Cards too (to select the right
server) - if it's unsuccessful, you are presented with a list.
I know UltraPenguin probes the PROM tree for the video cards (again to
select a server), because I sent in a patch for the cgfourteen.
IMHO, the Debian install should detect as much as possible from
/proc/pci (and proc/openprom on the Sparc), and do automatic
configuration from this wherever possible.
> > Using initrd, our default kernel may be reduced to half its current size,
> > as all those different controllers may be built as modules and only the
> > required ones will be loaded at boot time. That will save our users a few
> > hundred KBs of RAM, and will make building a custom kernel a not so
> > needed step.
> Yes, this would be a great improvement over the current situation, making
> the installation kernel appropriate for a system kernel with no
> rebuilding.
It would also make new kernel packages available to a wider audience.
(At least some of those who compile their own may be less likely to.)
Steve
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bootint big kernels
On Thu, Jun 11, 1998 at 10:02:21AM -0400, Avery Pennarun wrote: > This is, if I recall, exactly what initrd was made for. Your bootloader > (eg. lilo) loads an initial ramdisk containing all the kernel modules you > might need. An init script on the ramdisk loads the right modules (however > you choose to do that) and then exits; the kernel unmounts the ramdisk and > remounts the "real" rootdisk. > > That way, you can have a kernel without _any_ disk drivers at all (even IDE) > and yet boot from any disk that has a kernel driver. Works like a charm and > avoids all problems with conflicting drivers. IIRC, with kernel v2.0.33 one can't build the IDE driver as a module. -- Enrique Zanardi[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bootint big kernels
On Thu, Jun 11, 1998 at 09:41:03AM -0400, Dale Scheetz wrote: > The problem is that the Debian installation kernel tries to be all things > to all people. As there are machines that boot from SCSI drives, it was > necessary to have all the scsi controlers "built in" to the kernel, hense > its large size. > > We should recommend that everyone, once they have a standard system and > can build a kernel, should build a custom kernel for their machine as > early as possible. This is, if I recall, exactly what initrd was made for. Your bootloader (eg. lilo) loads an initial ramdisk containing all the kernel modules you might need. An init script on the ramdisk loads the right modules (however you choose to do that) and then exits; the kernel unmounts the ramdisk and remounts the "real" rootdisk. That way, you can have a kernel without _any_ disk drivers at all (even IDE) and yet boot from any disk that has a kernel driver. Works like a charm and avoids all problems with conflicting drivers. Unfortunately, I would expect it to have the same high-loading problems as bzImage since a kernel+initrd would seldom fit in the low 640k. Have fun, Avery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bootint big kernels
On Thu, Jun 11, 1998 at 11:45:56AM -0500, Martin Alonso Soto Jacome wrote: > Dale Scheetz <[EMAIL PROTECTED]> wrote: > > I have wondered why we didn't try this once the kernel supported initrd. > > To be honest I haven't figured out yet how to do the device selection, > > other than going through a list of drivers, trying to insmod each one > > until you are successful. > > Wouldn't PCI and ISA PnP support help here? Standard 2.0.x kernels support > /proc/pci since a long time, so it should be possible to check the device > names on /proc/pci against a table in order to load the apropriate modules. That's what Red Hat does, and what I plan to implement for slink. It doesn't work for ISA cards though, therefore I plan to implement a method for manually selecting modules at install time as well (probably a modified "modconf"). > It should also be possible to deal with PnP just the same way, Yes, but we will have to create the "device -> module" table from scratch, as I don't know of anyone that maintains such a table. > although I > don't know what the status of the PnP support in the kernel is right now. None AFAIK. PnP devices are configured with user-space tools (pnpdump and isapnp). -- Enrique Zanardi[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bootint big kernels
Dale Scheetz <[EMAIL PROTECTED]> wrote: > I have wondered why we didn't try this once the kernel supported initrd. > To be honest I haven't figured out yet how to do the device selection, > other than going through a list of drivers, trying to insmod each one > until you are successful. Wouldn't PCI and ISA PnP support help here? Standard 2.0.x kernels support /proc/pci since a long time, so it should be possible to check the device names on /proc/pci against a table in order to load the apropriate modules. It should also be possible to deal with PnP just the same way, although I don't know what the status of the PnP support in the kernel is right now. Regards, M. S. Martin A. Soto J. Profesor Departamento de Ingenieria de Sistemas y Computacion Universidad de los Andes [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bootint big kernels
On Thu, 11 Jun 1998, Enrique Zanardi wrote:
> On Thu, Jun 11, 1998 at 09:41:03AM -0400, Dale Scheetz wrote:
> > The problem is that the Debian installation kernel tries to be all things
> > to all people. As there are machines that boot from SCSI drives, it was
> > necessary to have all the scsi controlers "built in" to the kernel, hense
> > its large size.
> >
> > We should recommend that everyone, once they have a standard system and
> > can build a kernel, should build a custom kernel for their machine as
> > early as possible.
> >
> > Another solution is the one that slackware provides. They build a "bunch"
> > of kernels, each one for a specific hardware configuration (broad enought
> > to cover a range of hardware, and chosen to keep incopatibly drivers out
> > of the picture {like the wd9000 driver that plonks ethernet cards})
>
> I'm working on a better solution that involves using initrd to
> load the required controllers (built as loadable modules). I've tested
> using initrd for lowmem installations and it works flawlessly (just have
> a look at lowmem boot disk in boot-floppies_2.0.7 when I upload it next
> weekend).
I have wondered why we didn't try this once the kernel supported initrd.
To be honest I haven't figured out yet how to do the device selection,
other than going through a list of drivers, trying to insmod each one
until you are successful.
I would love to see your solution for this, even in whatever the current
state is.
>
> Using initrd, our default kernel may be reduced to half its current size,
> as all those different controllers may be built as modules and only the
> required ones will be loaded at boot time. That will save our users a few
> hundred KBs of RAM, and will make building a custom kernel a not so
> needed step.
>
Yes, this would be a great improvement over the current situation, making
the installation kernel appropriate for a system kernel with no
rebuilding.
> When I have a "proof-of-concept" implementation, I plan to discuss the
> details with Herbert Xu, our kernel maintainer, to see if we can adopt
> this solution for slink.
>
This is wonderful Enrique, thanks for all your fine work on this package!
I look forward to seeing this,
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bootint big kernels
On Fri, Jun 12, 1998 at 12:25:59AM +1000, Hamish Moffatt wrote: > On Thu, Jun 11, 1998 at 03:13:37PM +0100, Enrique Zanardi wrote: > > Using initrd, our default kernel may be reduced to half its current size, > > as all those different controllers may be built as modules and only the > > required ones will be loaded at boot time. That will save our users a few > > hundred KBs of RAM, and will make building a custom kernel a not so > > needed step. > > Can we have zImages instead of bzImages then? :-) Probably. -- Enrique Zanardi[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bootint big kernels
On Thu, Jun 11, 1998 at 03:13:37PM +0100, Enrique Zanardi wrote: > Using initrd, our default kernel may be reduced to half its current size, > as all those different controllers may be built as modules and only the > required ones will be loaded at boot time. That will save our users a few > hundred KBs of RAM, and will make building a custom kernel a not so > needed step. Can we have zImages instead of bzImages then? :-) Hamish (with the weird desktop) -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bootint big kernels
On Thu, Jun 11, 1998 at 09:41:03AM -0400, Dale Scheetz wrote:
> The problem is that the Debian installation kernel tries to be all things
> to all people. As there are machines that boot from SCSI drives, it was
> necessary to have all the scsi controlers "built in" to the kernel, hense
> its large size.
>
> We should recommend that everyone, once they have a standard system and
> can build a kernel, should build a custom kernel for their machine as
> early as possible.
>
> Another solution is the one that slackware provides. They build a "bunch"
> of kernels, each one for a specific hardware configuration (broad enought
> to cover a range of hardware, and chosen to keep incopatibly drivers out
> of the picture {like the wd9000 driver that plonks ethernet cards})
I'm working on a better solution that involves using initrd to
load the required controllers (built as loadable modules). I've tested
using initrd for lowmem installations and it works flawlessly (just have
a look at lowmem boot disk in boot-floppies_2.0.7 when I upload it next
weekend).
Using initrd, our default kernel may be reduced to half its current size,
as all those different controllers may be built as modules and only the
required ones will be loaded at boot time. That will save our users a few
hundred KBs of RAM, and will make building a custom kernel a not so
needed step.
When I have a "proof-of-concept" implementation, I plan to discuss the
details with Herbert Xu, our kernel maintainer, to see if we can adopt
this solution for slink.
--
Enrique Zanardi[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bootint big kernels was Re: VI reasons (was Re: Base Set: Suggested additions & removals.)
Quoting Dale Scheetz ([EMAIL PROTECTED]):
> Another solution is the one that slackware provides. They build a "bunch"
> of kernels, each one for a specific hardware configuration (broad enought
> to cover a range of hardware, and chosen to keep incopatibly drivers out
> of the picture {like the wd9000 driver that plonks ethernet cards})
And one of slackware's biggest flaws is the hoard or new users that
can't figure out which kernel to use.
--
Michael Stone, Sysadmin, ITRI PGP: key 1024/76556F95 from mit keyserver,
[EMAIL PROTECTED]finger, or email with "Subject: get pgp key"
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bootint big kernels was Re: VI reasons (was Re: Base Set: Suggested additions & removals.)
On Thu, 11 Jun 1998, Hamish Moffatt wrote:
> On Wed, Jun 10, 1998 at 09:17:20PM -0600, Jason Gunthorpe wrote:
> > When you boot the kernel it copies the Image from the disk to 0x1000
> > (about 64k). If the Image is beyond 600k then you have a problem because
> > it suddenly will not all fit in low memory.
> >
> > A bzImage is more sinister. After it loads a few block in it makes some
> > bios calls to copy the blocks up to 1 meg where the 3rd stage boot loader
> > will run. After that it uncompresses the kernel to some location then
> > copies it to it's proper placement at 1M. a zImage simply uncompresses the
> > kernel to 1M.
> >
> > In theory, on a notebook the int calls are glitchy and crash the system.
> >
> > If your kernel is > 600k you MUST use a bzImage and you MUST load it into
>
> So is there any other advantage? 600k is pretty big for a default
> kernel, especially since we are making heavy use of modules. My custom 2.0.34
> is 300k odd, although obviously the Debian one needs a bunch of SCSI drivers.
> If we are < 600k, why use it when it is problematic?
>
The problem is that the Debian installation kernel tries to be all things
to all people. As there are machines that boot from SCSI drives, it was
necessary to have all the scsi controlers "built in" to the kernel, hense
its large size.
We should recommend that everyone, once they have a standard system and
can build a kernel, should build a custom kernel for their machine as
early as possible.
Another solution is the one that slackware provides. They build a "bunch"
of kernels, each one for a specific hardware configuration (broad enought
to cover a range of hardware, and chosen to keep incopatibly drivers out
of the picture {like the wd9000 driver that plonks ethernet cards})
Waiting is,
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
