Files
oldlinux-files/ftp-archives/tsx-11.mit.edu/1996-10-07/mail-archive/linux-devel/Volume2/digest117
2024-02-19 00:24:15 -05:00

743 lines
30 KiB
Plaintext

From: Digestifier <Linux-Development-Request@senator-bedfellow.mit.edu>
To: Linux-Development@senator-bedfellow.mit.edu
Reply-To: Linux-Development@senator-bedfellow.mit.edu
Date: Sun, 4 Sep 94 08:13:04 EDT
Subject: Linux-Development Digest #117
Linux-Development Digest #117, Volume #2 Sun, 4 Sep 94 08:13:04 EDT
Contents:
Re: more than 2 COM ports at the same time (Larry Doolittle)
Re: DOSEMU 0.53: Developers and testers needed! (Jim Gifford)
[DOSEMU][SERIAL] Incorrect Parity bits? (Joe George)
Re: Kernel change summary 1.1.45 -> 1.1.46 (Robert Sanders)
Wheres blkdev.h?? (compiling 1.1.49) (Carlos Dominguez)
Re: sb_dsp_operations undeclared 1.1.46 (Hannu Savolainen)
Re: Linux - my first impressions (Mark A. Horton KA4YBR)
Re: mmap( ..., PROT_WRITE, MAP_SHARED, ... ) WHY NOT? (Robert Sanders)
Re: IDE Hard Drives w/ over 1024 cylinders (Steve DuChene)
----------------------------------------------------------------------------
From: doolitt@recycle.cebaf.gov (Larry Doolittle)
Subject: Re: more than 2 COM ports at the same time
Reply-To: doolittle@cebaf.gov
Date: Sun, 4 Sep 1994 00:27:55 GMT
Harry C Pulley (hpulley@uoguelph.ca) wrote:
: I am trying to run with a mouse on COM2, modem on COM3 and terminal on COM4.
: Whenever I use both the mouse (COM2) and the terminal (COM4) at the same time I
: get no response from either. Is there any code around for sharing IRQs? If
: not, then is there any code for using one of the ports in a polled mode instead
: of interrupt driven?
: I already have 2 parallel ports on 5 and 7 and
: a sound card on IRQ7. Unfortunately, I don't think my multi-I/O card can
: change the IRQ for COM4 to IRQ2. Thus, changing IRQs is not an option.
I trust you know that the lp driver does not use IRQ's, and the
existence of setserial package to tell Linux about non-standard
IRQ's for serial ports. The only step left is for you to realize
that changing IRQ's in hardware *is* an option. I did it on a
multifunction board, this is actually easiest. Run a wire from a
COM IRQ jumper post to an LP IRQ jumper post. The posts are wire
wrap posts, so any thin wire with a few turns will be grabbed and
make reliable electrical contact. It took me about twenty minutes
staring at the board traces with good lighting to figure out which
two posts required the jumper. If you are not a hardware type, and
don't want to learn, find a friend who is. It really is pretty easy.
I am typing this on a machine with 4 com ports active, none of them
fancy, just standard clone stuff. Oh, yeah, my Boca modem can be
jumpered to IRQ's 3,4,5, or 7, so I only had to play the game above for
one non-standard IRQ.
- Larry Doolittle doolittle@cebaf.gov
------------------------------
From: jgifford@moe.coe.uga.edu (Jim Gifford)
Subject: Re: DOSEMU 0.53: Developers and testers needed!
Date: 4 Sep 1994 01:18:45 GMT
Harry C Pulley (hpulley@uoguelph.ca) wrote:
: John Saunders (john@odin.apana.org.au) wrote:
: : jonathan allen (jonathan@mirror.demon.co.uk) wrote:
: : > I wanted to have a try at DOSEMU0.53, and saw a post that it was at
: : > tsx11-mit.edu:/pub/Linux/ALPHA/private/devel but the 'private' directory
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
: : > is not open for me to pick it up. How/where _can_ I find it ?
: : Just CD into it and like magic all the files appear. At least that's
: : what I've bee told ;-) It's only hidden, not unavailable.
: Yep, type 'cd /pub/linux/ALPHA/dosemu/private/devel' and you'll be in. I just
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Anyone else notice this discrepency? I tried and tried a few days ago to
get at the first listing, but it wouldn't work. then I tried the second.
No problems. The only reason I kept trying the first was because several
people posted very authoritatively that the first WAS correct, and that
people such as myself were doing something wrong. I have yet to see a post
pointing out this little difference.
Oh well, ain't communication grand...
Later,
Jim
------------------------------
From: jgeorge@nbi.com (Joe George)
Subject: [DOSEMU][SERIAL] Incorrect Parity bits?
Date: Sat, 3 Sep 1994 20:50:02 GMT
Hello all,
I'm sending this message to a few different places because while I know what
problem I'm having, I'm at a loss to figure out exactly *where* the
breakdown is occurring.
I need to run a rather odd communications program that runs under MSDOS and
requires(!) 7 bit, mark parity, 1 stop bit settings. I've run this
successfully under MSDOS, and it ran successfully under Linux and DOSEMU
before the TTY patches were introduced into the kernel (1.1.13?). Now, under
DOSEMU (pre53_17 but also others) and Linux (1.1.49 and others as well) I
get a lot of dropped characters - actually, let me correct myself. The
characters are not dropped but the "mark" parity isn't dealt with properly
so I get garbage. I can also duplicate this under Qmodem 4.5 (under DOSEMU)
by setting the comm settings to 7-mark-1 and getting the exact same form of
character corruption, so it's not specific to my odd comm program.
Dialing the same system at 8N1, I get incorrect (but consistent) results
with minicom, dosemu+qmodem, dosemu+simpc (my odd comm program), and qmodem
and simpc under msdos, so I think the problem lies in the handling of 'mark'
parity somewhere in the serial driver. Whether it's in dosemu's serial
driver or in the kernel serial drivers, I do not know. I don't have a
program under Linux that I can set to 7-Mark-1 -- minicom doesn't support
mark, as far as I know.
Does anyone have a clue where I can look to fix this? Can someone point me
to a comm program under Linux that I can set to 7M1 and see if it works? At
least that way I can tell if the problem is dosemu's serial driver or
Linux's.
I am inclined to think that the problem is in the kernel serial drivers
because the program quit working when the new TTY drivers were included in
the kernel, and the version of dosemu at the time didn't change (though I
did go to a newer version to see if it fixed the problem).
Here are some results. I dialed the same number using QMODEM, once from real
MSDOS and once from DOSEMU, using 8N1 and one more time under each using
7M1. Both times I dialed 8N1 I got incorrect output (as to be expected), but
it was consistent, meaning that the Linux+dosemu serial code works at least
under normal circumstances. Here's what I get from dialing 7M1:
Qmodem+Msdos+7-mark-1 (what I'm trying to get under Dosemu!)
CONNECT 9600
ENTER SWITCH CHARACTERS
INVALID SWITCH CHARACTERS
+++
INVALID SWITCH CHARACTERS
OK
Qmodem+Dosemu+7-mark-1 (note the dropped bits)
CONNECT 9600
ILI WITC CRCTER+++ILI WITC CRCTER
OK
See what's happening?
Help...?
Joe
--
Joe George (jgeorge@crl.com, jgeorge@nbi.com)
Great Moments in Usenet news:
"Usenet is a cesspool, a dungheap." -Patrick Townson
"No." -Tim Pierce
------------------------------
From: rsanders@mindspring.com (Robert Sanders)
Subject: Re: Kernel change summary 1.1.45 -> 1.1.46
Date: 02 Sep 1994 05:43:53 GMT
On 1 Sep 1994 23:45:28 GMT, mjf@clark.net (Marc Fraioli) said:
>> The next e2fsprogs release (version 0.5b) contains support for these
>> new attributes (in the programs chattr and lsattr). As of Linux 1.1.46,
>> the kernel honours them.
>>
> Will we have to reformat to take advantage of these things?
Not at all; each file has had a 32-bit "attributes" field for quite
some time. We've still got quite a few bits to go before it's full.
I have to say, I like the "nodump" field best of all. With Remy's
excellent port of BSD dump/restore, it makes backups quite pleasant.
-- Robert
------------------------------
Crossposted-To: comp.os.linux.help
From: carlos@dorsai.dorsai.org (Carlos Dominguez)
Subject: Wheres blkdev.h?? (compiling 1.1.49)
Reply-To: Carlos Dominguez (carlos@dorsai.dorsai.org)
Date: Sun, 4 Sep 1994 01:38:06 GMT
I'm trying to compile the latest/greatest kernel in order to
get support for my 1mb/sec QIC80/floppy controller.
I got the 1.1.45 kernel, applied all the patches sequentially from
46 to 49 to my 45 source tree, and whenever I do a make dep I always
get this.
ksyms.c:13: linux/blkdev.h: No such file or directory
make[1] *** [dep] Error 1
I did a diff between a ksyms.c and a ksyms.c.orig and the diffs were
that statement and a "BLOCK DEVICE" section towards the end.
Can/Should I compile even with this dependency error?
Thanks
--
__ __ __ | .__. __. :::: Carlos Dominguez - Cyberdude & Gophermaster
| __| | | | | |__ :::: gophermaster@dorsai.org
|__ |__| | | |__| .__| :::: carlos@dorsai.dorsai.org
____________________________ I'm Looking for employment in the NYC area.
------------------------------
From: hannu@voxware.pp.fi (Hannu Savolainen)
Subject: Re: sb_dsp_operations undeclared 1.1.46
Date: Sun, 4 Sep 1994 08:39:00 GMT
wdoyle@hilbert.coe.northeastern.edu (Patrick Doyle) writes:
>BTW, I would like to formally request that the configuration
>parameters for the sound support be integrated in the rest of the
>kernel configuration parameters in time for the next code freeze. It
This is not likely to happen. VoxWare driver works also with other operating
systems than Linux (BSD, SCO, UW, ISC etc.) so the configuration method
should be distributed with the driver. In fact there is need to make the
configuration method yet more incompatible with the kernel one. Sound cards
are strange devices. While most other ISA cards serve just one purpose
(SCSI, IDE, serial+parallel, display etc.), sound cards are usually
multi function devices. All soundcards support at least
digitized voice (audio), music synthesis (FM, wave table), MIDI port and
joystick. Usually there is also some kind of SCSI and/or CD-ROM interface.
Latest sound cards have a DSP processor in them and even with capabilities
to hook them to the telephone network (FAX, voice mail, modem etc.).
Some of the new cards I'm working with (PSA based cards, Ensoniq SoundScape)
require so much configuration information that it's little bit difficult
to get them to work without a better configuration method. Propably this
means that a menu driven configuration program is required. Otherwise it's
not possible to implement sufficient online help and other AI features.
(Anybody willing to write this kind of program? I could try to write down
the specs).
>can really be annoying to try to remember what parameters I chose the
>last time I configured the kernel and there's no reason this fancy
>machine in front of me couldn't remember them for me automagically.
There is an easy way to do that. Just copy the linux/drivers/sound/local.h
to a safe place. You could then just answer yes to the question
"Do you want to disable the sound driver?". Then just copy the old local.h
to linux/drivers/sound and run "make dep". Unfortunately this method works
just as long as the new version of the driver doesn't support new cards.
All cards are enabled by default and may cause compiling errors with an old
local.h. (In this case you have to just run "make config" again).
Hannu
--
=============================
Hannu Savolainen
hannu@voxware.pp.fi
"Don't use Windows since there is a door!"
------------------------------
From: mah@ka4ybr.com (Mark A. Horton KA4YBR)
Subject: Re: Linux - my first impressions
Date: Sat, 3 Sep 1994 13:13:43 GMT
Kees J. Bot (kjb@cs.vu.nl) wrote:
: Under SunOS the installboot(8) program installs the bootstrap and the
: addresses to /boot into the boot block. This only needs to be done
: once, because /boot never changes.
: The LILO method is rather crude.
: --
: Kees J. Bot (kjb@cs.vu.nl)
: Systems Programmer, Vrije Universiteit Amsterdam
True in one sense, but then Suns don't have to deal with booting
completely alien operating systems on themselves or having SunOS (and thus
vmunix) installed as a SECONDARY operating system on an existing hardware
platform. When you consider that, I for one do not think of LILO as being
crude, but as being a tremendous achievement. Almesberger has done one
hell of a good job with that piece of code IMHO!
-- Mark
BTW: do you know of any way I can choose between booting SunOS 4.1.3
and Solaris 2.3 on my SPARCs? I currently run one on the SPARC-1 and one on
the SPARC-2 because I haven't figured out how to tell the boot nvram how to
boot an alternative partition/kernel... any clues? I'd really like to test
Solaris' performance on the 2, but am not about to lose my trusty SunOS 4.1.3
over ther! :)
Thanks for any help you can give me on how to do this...
--
Q. What's the difference between Solaris 2.x and the Andromeda Strain?
A. Solaris mutates quicker..... :-)
============================================================
Mark A. Horton ka4ybr mah@ka4ybr.atl.ga.us
P.O. Box 747 Decatur GA US 30031-0747 mah@ka4ybr.com
+1.404.371.0291 33 45 31 N / 084 16 59 W
------------------------------
From: rsanders@mindspring.com (Robert Sanders)
Subject: Re: mmap( ..., PROT_WRITE, MAP_SHARED, ... ) WHY NOT?
Date: 02 Sep 1994 05:47:40 GMT
On 1 Sep 1994 21:20:02 -0400, davem@er4.rutgers.edu (David Miller) said:
> Correct, this is not implemented as of yet (1.1.pre50 kernel).
> Due to some of the bogus parts of the i386 memory management
> facilities, an implementation of this is very difficult. Nevertheless
> this one of the projects in line for post-1.2.0 kernels, so stay
Actually, the i386 has very little to do with it. It's a tough thing
to get right whether it's on a 386 or a Sparc. We're slowly moving
that way -- shared libraries are now done via mmap(), for example --
but it's not easy.
-- Robert
------------------------------
From: s0017210@cc.ysu.edu (Steve DuChene)
Subject: Re: IDE Hard Drives w/ over 1024 cylinders
Date: 2 Sep 1994 07:07:09 GMT
Well this seems to be coming up so often that perhaps it should be
put into the FAQ! (I did suggest that but no responce from the
powers that be) The following is an article I saved that deals with
this very problem. The newer kernels are supposed to have special
fixes to take care of this problem but there are enough folks out
there still using (from CD-ROM distributions?) the 1.0 kernel.
Anyway what follows is the way to fix these problems with harddrives
with more than 1024 cylinders when you are using earlier kernels.
Newsgroups: comp.os.linux.help,alt.sys.pc-clone.gateway2000
From: deitrick@shell.com (Gregory L. Deitrick)
Subject: Re: LINUX success on Gateway 2000 P4D66, with 540MB drive
Organization: Shell Oil Co., Houston TX
Date: Wed, 27 Jul 1994 17:40:18 GMT
Lines: 365
... Regarding extended IDE (EIDE) hard disks (540Mb & larger):
I had many many problems with partitioning my 540Mb hard disk and installing
linux & LILO (not recognizing the disk, booting problems, etc., etc., ...)
that appeared to be caused by two problems:
1. fdisk (DOS & Linux) by default makes partitions that don't pass its own
checks.
2. properly dealing with EIDE.
I paid Yggdrasil's tech support fee and had them talk me through the install
which is now running exactly how I wanted it (LILO boots from the hard disk
and starts either DOS or Linux) with no error messages from fdisk
or booting problems. The Yggdrasil tech sent me Email on EIDE, and I've
combined this info with the fix for partitions with different physical/logical
endings and attached the result below:
===============================================================================
Subject: Linux and extended IDE drives.
========
Attachment 1 is a note from Patrick LoPresti <patl@lcs.mit.edu> by way of
(and with some additions by) Daniel Quinlan of Yggdrasil. At the end
is an example setup procedure (search for "Example") by Mr. Quinlan (I
presume). Attachment 2 is from Ian Jackson's FAQ dated 13 Jul 1994 to
fix a common disk partitioning problem I encountered when Dan helped me
partition my disk for Yggdrasil's distribution.
I have copied Mr. Quinlan's example and added a few notes from my own
experience that seemed to be left out. I would polish the presentation,
but prefer to leave that to someone (Dan?, Ian?) with more
experience/ perspective on Linux who could identify and address additional
pitfalls/contingencies.
I have sent this note to Dan Quinlan and Ian Jackson in the hopes that
they will consider disseminating this info with my suggestions; and to
Jonas Karlsson because he's posted a news item on this recently. As is
my practice I have also sent copies to others who have passed on various
tidbits for their personal reference.
I hope this helps someone and apoligize for adding to anyone's useless
junkmail.
Regards,
=============
Greg Deitrick
=========================================================================
Shell Development Co. | Email: deitrick@walt | Phone: (713) 245-7104
3737 Bellaire Blvd. | deitrick@shell.com | (ssn) 422-7104
Houston, TX 77025 | PROFS: deitrick | FAX: (713) 245-7990
=========================================================================
Example / Summary (Original by D. Quinlan?; ">" additions by G. Deitrick)
===========================================
I have a 1 Gig EIDE drive on which I recently installed Linux. Here
is the procedure I used.
1) Ran setup and examined the (bogus) disk geometry. It said 525
cylinders, 64 heads, 63 sectors. More than 16 heads is impossible, so
the real values must be 2100 cylinders, 16 heads, 63 sectors.
2) Booted DOS boot disk, ran fdisk, created a DOS partition.
3) Booted Yggdrasil boot disk. Typed "linux hd=2100,16,63" to boot
the kernel and logged in as root. Ran Linux fdisk, typed "p" to see
lots of errors, typed "x" to access expert mode, set cylinders to 505,
set heads to 64, returned to normal mode, typed "p" to see my DOS
partition and no error messages. Created partitions to heart's
content. Saved partition table. Logged out.
>EVERY TIME YOU RUN FDISK, SET CYLINDERS TO 505 AND HEADS TO 64 AND RETURN TO
>NORMAL MODE BEFORE DOING ANYTHING ELSE.
>Before logging out, rerun fdisk (see ABOVE) and type p from normal mode. If
>you get lots of errors about physical/logical endings being different, go to
>"Attachment 2" below to fix. If the first time you make your partitions you
>start by making your first partition in sector mode starting with sector 63
>and ending with +250M (for a 250Mb partition) and making the remaining
>partitions in cylinder mode, your first partition table should generate no
>subsequent error messages (this, at least, was my experience; I used +xxxM
>for the ends of all my partitions except my last one).
>Also before logging out be sure to set the System Id of the DOS partition
>properly (normal mode: t, id=6 [probably]), and set the boot flag.
4) Logged in as install and installed Yggdrasil normally, creating an
ordinary lilo.conf file.
5) Edited lilo.conf (in this case, /mnt/etc/lilo.conf) to add these
lines to the top:
append="hd=2100,16,63"
linear
6) Ran "lilo -r /mnt". I expected to need the "-P ignore" option, but
didn't. Go figure.
7) Installed DOS and Windows, much to my chagrin.
================= Attachment 1 ===========================================
Return-Path: quinlan@yggdrasil.com
Return-Path: <quinlan@yggdrasil.com>
Received: from shellgate.shell.com by walt.brc.shell.com (4.1/BRC-2.0)
id AA16608; Mon, 25 Jul 94 17:12:59 CDT
Received: by shellgate.shell.com SHELLGATE-I1.3 id AA13342; Mon, 25 Jul 94 17:13:14 -0500
Received: from freya.yggdrasil.com by uu5.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA08160 for deitrick; Mon, 25 Jul 94 12:38:55 -0400
Received: by freya (Linux Smail3.1.28.1 #58)
id m0qSaaS-000GK9C; Mon, 25 Jul 94 17:41 PDT
Message-Id: <m0qSaaS-000GK9C@freya>
Date: Mon, 25 Jul 94 17:41 PDT
From: quinlan@yggdrasil.com (Daniel Quinlan)
To: deitrick@shell.com
Cc: biro@yggdrasil.com
Subject: EIDE drives
This excellent explanation is from Patrick LoPresti <patl@lcs.mit.edu>,
although I've hacked at it to make it more applicable to a CD-ROM based
installation. Don't be too surprised if you find yourself doing
something slightly different -- it happens.
The LILO user manual is located in /usr/src/bin/lilo-14/doc/user.dvi.
This should explain how to set up DOS and Linux with LILO. Yggdrasil
does this by default, actually (that's what those "hdaX" LILO options
are).
Everything I Know About Linux with EIDE
---------------------------------------
Introduction
============
It is possible to use Linux on a large EIDE drive with no restrictions
on where anything resides. I only deal with DOS and Linux here, but
the approach I suggest should be compatible with other operating
systems as well.
I presently use version 1.0.9 of the kernel, but everything here
applies to kernels at least through 1.1.34. Sometime in the future,
Linux will probably support EIDE gracefully and transparently, at
which point all of this will be moot. Everything I suggest, however,
should continue to work with these future kernels, although most of it
will become unnecessary.
Background and Terminology
==========================
Sectors on an ATA (IDE) drive are 512 bytes long. There are two ways
to address sectors. Logical Block Address (LBA) form, or logical
form, numbers the sectors linearly starting with 0.
Cylinder-Head-Sector (CHS) form, or physical form, addresses each
sector with a (cylinder, head, sector) triplet. To convert addresses
from logical to physical form, it is necessary to know how many heads
per cylinder and how many sectors per head the drive has. If the
total number of cylinders is known as well, the size of the drive can
be determined. The number of cylinders, heads per cylinder ("heads"),
and sectors per head ("sectors") is called the "disk geometry".
Old controllers and BIOSes require sectors to be addressed in physical
form; all controllers and BIOSes allow sectors to be addressed in
physical form. Linux uses logical addresses everywhere except at the
lowest possible level, when it translates to physical form to talk to
the controller. Linux does not use the BIOS for anything except to
determine the disk geometry.
The partition table records the start and end of each partition in
*both* logical and physical form. Both DOS fdisk and Linux fdisk
expect these values to agree. DOS fdisk obtains the disk geometry by
querying the BIOS; Linux fdisk obtains the geometry by querying the
kernel.
Now for the fun part. MS-DOS and the BIOS interface use a 10-bit
field to hold the cylinder number, so they only allow cylinders 0-1023
to be accessed. This is not sufficient for modern drives, which tend
to have 63 sectors/head, 16 heads/cylinder, and many cylinders. The
"solution" is a complete hack: An EIDE BIOS will *lie* when queried
for the disk geometry by halving (or quartering) the number of
cylinders and doubling (or quadrupling) the number of heads. Then
whenever a physically addressed I/O request arrives, the BIOS will
assume the request is based on the bogus disk geometry, and will
convert it appropriately to talk to the controller. This process is
called "address translation".
The Problem
===========
When the Linux kernel queries the BIOS (actually, it just reads the
CMOS settings) to determine the disk geometry, it will get the bogus
values which claim more than 16 heads. Linux knows that this is
impossible, so the code in hd.c gives up and skips the drive. (Note
that even though the BIOS is reporting a bogus geometry, requests to
the controller still need to be based on the real geometry. Thus
merely eliminating the test in hd.c won't work.)
The Wrong Solution
==================
One fix is to use the BIOS "setup" program to turn off address
translation completely. You may have to manually set the
cylinder/head/sector values to the real geometry, or it may be
possible to simply turn off the translation, depending on how your
setup works.
Then you can repartition your drive with DOS and/or Linux fdisk,
install both operating systems, and things will work, provided you
observe certain restrictions.
The problem is that the BIOS still can't be used to access cylinders
above 1023. So all of your DOS partitions will have to be below that
limit, as will anything which needs to be accessed through the BIOS.
For example, LILO uses the BIOS to do its dirty work; so if you want
to use LILO to boot Linux, you will have to make sure the kernel
(read: entire root partition) lies below the 1024 cylinder limit.
Linux itself, however, will happily access the entire drive.
The Right Solution
==================
Restrictions are annoying, so we will avoid them. This obviously
requires leaving address translation on and dealing with the remaining
problems in a different way.
To fix the kernel's problem, simply feed the real geometry to the
kernel with a boot-time option line. You can do this from the LILO
boot prompt by typing "<image name> hd=<cylinders>,<heads>,<sectors>".
You can also have LILO feed the options automatically by using an
"append=" directive in your lilo.conf file.
Now the kernel will be able to recognize and access the drive, but
when a user mode program (e.g., fdisk or the LILO installer) queries
the kernel for the disk geometry, the kernel will return the real geometry,
not the bogus one. So Linux fdisk (which queries the kernel) and DOS
fdisk (which queries the BIOS) will disagree about how the partition
table should look. Also, the LILO installer will be computing
physical addresses which are incompatible with what the BIOS (and
therefore the LILO runtime) requires.
The fdisk problem is easy to fix: Go to expert mode, and set the
number of cylinders and number of heads to the bogus (BIOS-compliant)
values. Then edit the partition table and write it out, confident
that Linux fdisk and DOS fdisk are seeing eye to eye.
The LILO problem is just as easy to fix: Add the "linear" directive to
your lilo.conf file. This will cause LILO to use logical addresses
instead of physical to store its data, forcing LILO to compute
physical addresses at run time instead of at install time. This will
use the geometry supplied by the BIOS instead of that supplied by the
kernel, and everything will "just work".
Example / Summary (this is the hacked part)
===========================================
I have a 1 Gig EIDE drive on which I recently installed Linux. Here
is the procedure I used.
1) Ran setup and examined the (bogus) disk geometry. It said 525
cylinders, 64 heads, 63 sectors. More than 16 heads is impossible, so
the real values must be 2100 cylinders, 16 heads, 63 sectors.
2) Booted DOS boot disk, ran fdisk, created a DOS partition.
3) Booted Yggdrasil boot disk. Typed "linux hd=2100,16,63" to boot
the kernel and logged in as root. Ran Linux fdisk, typed "p" to see
lots of errors, typed "x" to access expert mode, set cylinders to 505,
set heads to 64, returned to normal mode, typed "p" to see my DOS
partition and no error messages. Created partitions to heart's
content. Saved partition table. Logged out.
4) Logged in as install and installed Yggdrasil normally, creating an
ordinary lilo.conf file.
5) Edited lilo.conf (in this case, /mnt/etc/lilo.conf) to add these
lines to the top:
append="hd=2100,16,63"
linear
6) Ran "lilo -r /mnt". I expected to need the "-P ignore" option, but
didn't. Go figure.
7) Installed DOS and Windows, much to my chagrin.
Note: You can also create the DOS partition from Linux fdisk.
================= Attachment 2: ===========================================
Excerps from:
Ian Jackson: Linux Frequently Asked Questions with Answers (FAQ: 1/2)
Wed, 13 Jul 1994 09:01
===============================================================================
Question 7.1. fdisk says Partition X has different phsyical/logical ...
If the partition number (X, above) is 1 this is the same problem as Q7.2
`fdisk: Partition 1 does not start on cylinder boundary'.
If the partition begins or ends on a cylinder numbered beyond 1024, this
is because standard DOS disk geometry information format in the partition
table can't cope with cylinder numbers with more than 10 bits.
This will cause DOS to be unable to access the partition correctly, and
will make booting a Linux kernel from that partition using LILO
problematic at best.
You can still use the partition for Linux or other operating systems that
use linear addressing (ie, number the disk blocks sequentially without
looking at heads, tracks and sectors).
I'd recommend creating at least one Linux partition entirely under the
1024-cylinder limit and booting off that; the other partitions will then
be OK.
===============================================================================
Question 7.2. fdisk: Partition 1 does not start on cylinder boundary
The version of fdisk that comes with many Linux systems creates partitions
that fail its own validity checking. Unfortunately if you've already
installed your system there's not much you can do about this, apart from
copying the data off the partition, deleting and remaking it, and copying
the data back.
If you are creating a new partition 1 that starts in the first cylinder,
you can do the following to get a partition that fdisk likes.
1. Create partition 1 in the normal way. A p listing will produce the
mismatch complaint.
2. Type u to set sector mode and do p again. Copy down the number from
the "End" column.
3. Delete partition 1.
4. While still in sector mode recreate partition 1. Set the first sector
to match the number of sectors per track. This is the sector number in
the first line of the p output. Set the last sector to the value noted in
2. above.
5. Type u to reset cylinder mode and continue with other partitions.
===============================================================================
--
| Steven A. DuChene sduchene@cis.ysu.edu or s0017210@cc.ysu.edu
| Youngstown State University | Computer Science / Math / Mech. Eng.
|They all laughed at Albert Einstein. They all laughed at Columbus.
|Unfortunately, they also all laughed at Bozo the Clown.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU
You can send mail to the entire list (and comp.os.linux.development) via:
Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU
Linux may be obtained via one of these FTP sites:
nic.funet.fi pub/OS/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development Digest
******************************