Re: Slow booting

From: Riley Williams (rhw@MemAlpha.CX)
Date: Thu Feb 17 2000 - 05:34:42 EST


Hi Pauline.

>> Update:
>> adding the compact option does solve the problem

>> I guess the older machines floppy controllers did some caching
>> on the controller that is not done on some of the new machines
>> and therefor when the code makes all the seperate requests the
>> older controllers are able to deliver the data while the newer
>> controllers have to do another seek to get the data.

> Eh, controllers don't cache data, they don't have the memory for
> it, they are just stupid in-between-things which translate
> signal levels (at about)

Actually, some floppy controllers (back in the days when the 8088 and
8086 processors ruled the PC world) included 8k of RAM on board, and
would stream an entire track into it as soon as any sector on that
track was requested. As a result, his suggestion isn't unrealistic.

>> one interesting sidenote.
>> without using the compact option lilo shows "reading kernel
>> image........" with several dots appearing as time goes on and
>> data is read, with the compact option it only shows a single dot
>> and that only when it has read the entire kernel image.

> Well, it seems than that a dot is printed between floppy reads
> and the compact options made it one big read, hence the one dot.

The actual procedure is for the driver to request the whole kernel,
take whatever it gets back, and then repeatedly request the rest,
displaying a dot after each successful read.

> I must say I find that strange, because you can only get atmost
> 9 sectors or you will run of the side of the floppy! :)

I have four systems at home that behave completely differently in this
respect when used with EXACTLY THE SAME boot disk:

 1. My print server clearly provides one track per read, and
    displays 56 dots as a result.

 2. My gateway clearly provides one CYLINDER per read, and
    displays 28 dots as a result.

 3. My Windows test station clearly provides 32k per read,
    and displays 16 dots as a result.

 4. My Linux workstation clearly provides 64k per read, and
    displays 8 dots as a result.

It would therefore NOT surprise me to discover that systems exist that
can provide the entire floppy at a single read, and would thus display
only a single dot.

> So I would expect at least some 33 dots, each for the 350/9
> tracks the kernel occupies.

We obviously have our kernels compiled differently as the one I use
occupies roundup(497k/9k) = 56 tracks = 28 cylinders.

Best wishes from Riley.

 * Copyright (C) 1999, Memory Alpha Systems.
 * All rights and wrongs reserved.

+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
 * http://www.memalpha.cx/Linux/Kernel/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:17 EST