Subject: Linux-Development Digest #855
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:     Fri, 24 Jun 94 22:13:06 EDT

Linux-Development Digest #855, Volume #1         Fri, 24 Jun 94 22:13:06 EDT

Contents:
  Re: Context of signal handler call (Steven Buytaert)
  Re: Subnetting on byte boundaries (Alan Cox)
  TCP routes anomaly. (Steve Brown)
  DosEmu suggestion (Albert Hui)
  Re: Strange stty/logout problem in 1.1.20 (Frank Lofaro)
  Re: Disk-compression for Linux (Ron Smits)
  Re: linux-1.1.20 breaks dosemu0.52 (Damian LETTIE)
  Re: Hard disks limited to 16 heads? (Alan Cox)
  Re: Disk-compression for Linux (David C. Brown)
  Kernel message from 3c503 driver (Adam Caldwell)
  Re: Deadlock with unix domain sockets (Matthew Dillon)
  Re: Runtime compilation and execution (Steven Hugg)
  Re: Disk-compression for Linux (Wayne Schlitt)
  Re: more breakage under 1.1.21 (rlogin xterms freeze up until being reset) (David Barr)
  IN2000 SCSI Driver & CD-Rom (Clay Van Kempema)
  Re: Need help with gcc/ncurses under 99pl15 (Mark P. Nelson)
  Porting libpthreads to Linux? (Yves Arrouye)
  Re: Strange stty/logout problem in 1.1.20 (Matthias Urlichs)
  Re: Porting libpthreads to Linux? (Marino Ladavac)
  Re: linux-1.1.20 breaks dosemu0.52 (Michael Will)
  Re: 'meta data' - the old fashioned way (Peter Desnoyers)
  Re: Hard disks limited to 16 heads? (Bill C. Riemers)
  Re: linux-1.1.20 breaks dosemu0.52 (Martin Rex)

----------------------------------------------------------------------------

From: buytaert@imec.be (Steven Buytaert)
Subject: Re: Context of signal handler call
Date: Fri, 24 Jun 1994 10:16:26 GMT

Markus Daetwyler (mdaetwyl@iiic.ethz.ch) wrote:
: In article <1994Jun23.131320.6295@imec.be>,
: Steven Buytaert <buytaert@imec.be> wrote:
: >  You should check out the signal.h file in the linux/include/linux

: Thank you for your help: it seems I should update my Kernel sources
: Markus Daetwyler

  No problem. You can buy me a beer when I'm in the neighbourhood :-)
  (Sometimes I do come to Switzerland for courses... BTW, nice
  playing of your team in the States...)

  Up to Linux stuff now,

  Stef

--
Steven Buytaert 

WORK buytaert@imec.be
HOME buytaert@innet.be

        'Imagination is more important than knowledge.'
                        (A. Einstein)

------------------------------

From: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: Subnetting on byte boundaries
Date: Tue, 21 Jun 1994 18:27:42 GMT

In article <55390.dennyfox@maroon.tc.umn.edu> <dennyfox@maroon.tc.umn.edu> writes:
>In paragraph 4.1 of the NET-2 HOWTO, there is a statement that subnetting 
>is supported on bytes boundaries only, "at this time". Does anyone know 
>when this restriction may be lifted? I'm in the process of designing a new 

About 0.99.15 I seem to remember. Its been gone for a long long time

ALan


------------------------------

From: stevebr@cherokee (Steve Brown)
Subject: TCP routes anomaly.
Date: 24 Jun 1994 08:47:02 GMT

Hi,
    I have a strange problem with Linux 1.0.8 and static routing....
Sendmail receives an email for a system that calls into my Linux box and
thus its route would normally be over device sl0. However, when sendmail gets
an email for said machine, Linux CREATES its own route table entry for the
machine, even though its not dialed in, and is therefore totally unreachable,
and whats worse it creates the route on eth0. The dial in machine will never
ever be on eth0.......

Why has Linux decided to start creating its own route entry's just because a
outside machine wants to talk to it? As far as I know it should return
host_unreachable and that be the end of it..... Can anyone suggest what to
do? ( Please dont say upgrade to 1.1.x, as I need to have a stable kernel, 
which 1.0.8 certainly seems to be :) ).

Thanks,
Steve.

--
=============================================================================
Steve Brown           |  stevebr@summer.bt.co.uk  | Act upon what matters,
Room 209, B81. PP35   | brown_s_m@bt-web.bt.co.uk | Not how you're perceived.
BT Labs               | steve@unicorn.dungeon.com | 
Ipswich, England.     |    Tel: +44 473 640523    | D A Gibson.
=============================================================================

------------------------------

From: s931306@yallara.cs.rmit.OZ.AU (Albert Hui)
Subject: DosEmu suggestion
Date: 24 Jun 1994 09:35:28 GMT

Now I've got DosEmu running happily and I like the emufs.sys
very much.  With my Linux partition being accessible in a DOS
session is real nice.

However, it would be even better if the DOS partitions are
mapped back to Linux.  People running Stacker or Double Space
will appreciate this very much, because the device driver
must be executed (DosEmu allows such program to execute) in
order to access the compressed drive...

Is it possible?
--
`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._
  Albert Hui (The Avatar)            |
  - avatar@suburbia.apana.org.au     | "Your mind is the only prison
  - s931306@yallara.cs.rmit.oz.au    |  that can ever bind your soul."

------------------------------

From: ftlofaro@unlv.edu (Frank Lofaro)
Subject: Re: Strange stty/logout problem in 1.1.20
Date: Wed, 22 Jun 94 20:10:23 GMT

In article <2u9i5h$ihu@po-box.norand.com> GREENJC@norand.com writes:
>>With 1.1.20 suddenly, when I log in and my .login does an stty (it does 2,
>>stty crt -ctlecho and stty erase ^?) the stty gets suspended (actually, I
>>believe it's the .login being suspended) and I get a shell. If I 'fg' the
>>suspended stty I get logged out
>>
>>The processes are reporting as being suspended on tty output.
>
>Did you "make clean" before compiling the kernel?  I had this happen back on
>1.1.17 I think, where the new kernel seemed to break the shell's job control.
>csh and tcsh would not work properly, but sh (with no job control) worked
>just fine.  This seems to be the standard thing that happens when people don't
>"make clean" first.  Maybe it's deliberate, so that we're forced to do a
>complete recompile. :)
>
>So, anyone want to offer a technical explanation for this? :)
>

Yeah, I wanna know too.  Isn't the whole idea of "make" to recompile
everything that has changed, or has not been compiled yet, and leave
the rest alone?

Does that break if the dependencies have changed. Maybe a make depend,
make would work.


------------------------------

From: ron@draconia.hacktic.nl (Ron Smits)
Subject: Re: Disk-compression for Linux
Date: 21 Jun 1994 11:31:50 GMT

there already is a compression package called double. It works
reasonably well
--



                Ron Smits
                ron@draconia.hacktic.nl
                Ron.Smits@Netherlands.NCR.COM

/*-( My opinions are my opinions, My boss's opinions are his opinions )-*/
/*-(                They might not be the same                        )-*/

------------------------------

From: em550@halls1.cc.monash.edu.au (Damian LETTIE)
Subject: Re: linux-1.1.20 breaks dosemu0.52
Date: Thu, 23 Jun 1994 09:47:17 GMT

>> I also am seeing a strange 'feature' in dosemu0.52, though it is under
>> 1.1.19.  After a clean compile, I try to run in a vt.  It goes as far as
>> saying that no errors were detected parsing the config file and then just
>> hangs.  Is this possibly due to rawkey on?

I recently installed dosemu0.52 using my 1.0.8 kernel: same problem as
you described above.  I managed to fix it, but the only thing I can put
it down to was recompiling the kernel.  I'd previously removed the 
'System V IPC' option (in the hope of slightly smaller and faster
kernel), but reinserted it this time.  Dosemu now works, but I still
have no idea if this had anything to do with it.  Can somebody describe
what 'System V IPC' does?

------------------------------

From: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: Hard disks limited to 16 heads?
Date: Wed, 22 Jun 1994 08:56:50 GMT

In article <BCR.94Jun21145535@k9.via.term.none> bcr@physics.purdue.edu writes:
>Linux doesn't suffer from this limitation at all.  Your BIOS might.
>Also Lilo does, but as near as I can tell this is caused by Lilo
>itself and not by anything built into the kernel.  If need be, you
Lilo uses the bios.

The basic rules are

A) You must not have a primary partition extending beyond cylinder 1023
or the start of your disk will get eaten
B) Your kernel must fall within a partition below cylinder 1024 so that
LILO can load it.

Alan

------------------------------

From: dbrow42@rfc.comm.harris.com (David C. Brown)
Subject: Re: Disk-compression for Linux
Date: Fri, 24 Jun 1994 16:12:27 GMT

Mihail S. Iotov (iotov@cco.caltech.edu) wrote:
: kevin@valis.worldgate.edmonton.ab.ca (Kevin B. Fluet) writes:

: Are you sure about the lost time ? Since compression makes less data go to
: the disk it might be actually faster (especially if your CPU would have been
: idle anyway.)    

Speaking from personal experience, I experienced a noticable increase in speed
when I installed compression on my MSDOS 286 with an ancient (slow) SCSI 
disk.  I was puzzled at first, then figured it out.  I haven't ever installed
compression on my more modern Linux computer, so I'm anxious to hear about
any of your real-world experience. 

------------------------------

From: acaldwel@103mort2.cs.ohiou.edu (Adam Caldwell)
Subject: Kernel message from 3c503 driver
Date: Wed, 22 Jun 1994 03:22:27 GMT


I've now seen the following message on two systems that are running with a
3 Com 3c503 Etherlink II network card:

eth0: Interrupts while interrupts are masked! isr=0x0 imr=0x0
eth0: FIFO blocked in el2_block_output (At xx of xx)

Any ideas on why, and if its a bug how to fix it?

-- Adam Caldwell

------------------------------

From: dillon@apollo.west.oic.com (Matthew Dillon)
Subject: Re: Deadlock with unix domain sockets
Date: 22 Jun 1994 20:40:34 -0700

In article <2uadn6$m7s@zeus.fasttax.com> phil@zeus.fasttax.com (Phil Howard) writes:
:iiitac@uk.ac.swan.pyr (Alan Cox) writes:
:
:>Yeah as I keep pointing out unix domain sockets are only partially implemented
:>and it doesn't make sense to complete them until the other restructuring is
:>done. If that one worries you just fix linux/net/unix/sock.c to handle the
:>O_NDELAY flag properly.
:
:Does this mean that the kernel is not organized where all I/O goes through
:a master point of some sort where things like O_NDELAY can be done in a way
:where it is in effect for all devices?  No, I have not studied the Linux
:kernel long enough yet to get the big picture on how it is organized.  I
:probably should soon since I have an idea would want to try in the kernel
:as a device driver.
:-- 
:Phil Howard KA9WGN      | The drive spec says the capacity is 600mb unformatted
:Unix/Internet/Sys Admin | and 525mb formatted.  So where do I find an unformat
:CLR/Fast-Tax            | utility?
:phil@fasttax.com        |

    For networking, I/O is layered quite nicely.  However, a flag as critical 
    as O_NDELAY is in any system using the UNIX signalling model must 
    ultimately be handled at a very deep level.

                                                -Matt

-- 

    Matthew Dillon              dillon@apollo.west.oic.com
    1005 Apollo Way             ham: KC6LVW (no mail drop)
    Incline Village, NV. 89451  Obvious Implementations Corporation
    USA                         Sandel-Avery Engineering
    [always include a portion of the original email in any response!]


------------------------------

From: hugg@xi.cs.fsu.edu (Steven Hugg)
Subject: Re: Runtime compilation and execution
Date: 23 Jun 1994 19:39:27 GMT

Well, la-dee-daa!!! Looks like the data segment is executable after all.
Just pop your code in and jump to it. Only problem is keeping the cache
happy (didn't we just talk about this??). Isn't there an invalidate()
function? Let me thread back and search for "cache"...

Now all I have to do is figure out how to get GDB to let me disassemble
code in the data segment :)

--
Steven E. Hugg
hugg@cs.fsu.edu

------------------------------

From: wayne@backbone.uucp (Wayne Schlitt)
Subject: Re: Disk-compression for Linux
Date: Fri, 24 Jun 1994 02:51:01 GMT
Reply-To: wayne@cse.unl.edu

In article <1994Jun22.133916.115@eltsac.nbg.de> felix@eltsac.nbg.de (Felix Schmidt) writes:
> What about the performance?
> 
> When used on a multitasing-OS, some other processes may want to do
> some work while the disk-driver waits for the IO to finish.
> I admit that i do not know how fast those algorithms really are, but
> there is for sure some work to do to acheive a rate of 2:1.
> 
> Has anybody *seen* a compressing filesystem on a multiuser-OS
> already?


Well, I have not actually seen it in use, but there are compressed
file systems for Unix (SVR4, SCO, etc).  They _claim_ that they are
faster than non compressed filesystems, unless you have a lot of CPU
bound jobs.  

I once timed it.  Even gzip can compress stuff faster than most disks
can transfer, so it is quite believable that if you have disk bound
jobs, that using compression could actually speed things up.


-wayne

-- 
Our reasoning goes something like this:  "If I want it, I need it.  If
I need it, it's my right.  If it's my right, someone should give it to
me.  Or else I'll sue."     -- Newsweek June 27, 1994

------------------------------

From: barr@pop.psu.edu (David Barr)
Subject: Re: more breakage under 1.1.21 (rlogin xterms freeze up until being reset)
Date: 24 Jun 1994 13:08:50 -0400

[ removing Distribution: na ]
In article <2uf0na$qe0@salyko.cube.net>,
Hubert Weikert <weikert@salyko.cube.net> wrote:
>'make clean' isn't sufficient, .depend files are not removed.  You
>should use 'make mrproper' to clean up all, especially if you step up to
>a new patchlevel. 

I never understand why people insist on using "make mrproper" when
upgrading kernels.

I've been using "make dep;make zlilo" (or whatever) and it works fine.
It saves a _lot_ of time, compared to a full rebuild.

--Dave
-- 
"Opera is when a guy gets stabbed in the back and instead of bleeding
he sings." - Ed Gardner

------------------------------

From: clay@agora.rdrop.com (Clay Van Kempema)
Subject: IN2000 SCSI Driver & CD-Rom
Date: Thu, 23 Jun 1994 16:36:58 GMT



If anyone out there has experience with the IN2000 SCSI driver,
especially if you are using it with a CD, I would like to hear
from you.  The driver works fine with a hard drive but gives me
timeout errors with a CD.  Any help would be appreciated.

Thanks in advance,

Clay


------------------------------

From: mpn@AlleleB (Mark P. Nelson)
Subject: Re: Need help with gcc/ncurses under 99pl15
Date: 23 Jun 1994 18:08:37 GMT
Reply-To: mpn@alleleb.berkeley.edu

Scott Wegener (wegster@connected.com) wrote:

: main()
: {
:   initscr();
:   clear();
:   move(1,1);
:   puts("This is a test....");getchar();
:   return;
: }
:  
: According to the ncurses man pages, need to include the -lncurses
: switch, but this made no difference in results at all..
: ok, so command line is: cc -lncurses test.c

No, it isn't; the order is wrong.  Try this:

cc test.c -lncurses

or better yet, this:

gcc -Wall -Wstrict-prototypes test.c -lncurses

I too came from DOS C programming to Unix, many years ago, and there's a
lot both to learn and to unlearn.

If you have the info program (try typing info at the prompt), you should
find a number of info sheets documenting various GNU parts.  You can find 
also a lot of documentation at rtfm.mit.edu

: If you have any ideas or suggestions I would greatly appreciate them.

Well, that's what I have to start with.  Feel free to email me if I can
be of any more help.

--
Mark P. Nelson (mpn@alleleb.berkeley.edu)
                         While I'll admit that anyone can make a mistake once,
                         to go on making the same lethal errors century after
                         century seems to me nothing short of deliberate.--V.

------------------------------

Crossposted-To: comp.os.linux.kernel
From: arrouye@petole.imag.fr (Yves Arrouye)
Subject: Porting libpthreads to Linux?
Date: Thu, 23 Jun 1994 08:14:11 GMT

Hello,

I would like to port Mueller et al.'s libpthreads (ftp.cs.fsu.edu:/pub/PART/)
to Linux, but I am having a lot of problems because I really do not know where
to find the information I need.
        Did someone do the port? If so, where can I find it? If not, does
someone volonteer to help me? The informations I need are relative to the
stack frames management, the jump buffer structure (although I think I've  
found what I need in jmp_buf.h) and the structure of informations saved when
a user handler as set by sigaction is called. If soemeone can also implement  
context switches in assembler, (s)he is welcome!
        The goal of the porting is twofold: first, having a  
library-implementation of Pthreads under Linux; second, use it to have tasks  
in GNAT's Ada9x runtime.

Thanks in advance for any help.
Yves.

--
Advocates for the C++ school claim that a well designed           Yves Arrouye
    program does not need the extra flexibility (a lie),  Yves.Arrouye@imag.fr
while advocates for the Objective-C school claim that         (33) 76 57 48 64
    the errors are no problem in practice (another lie).             NeXT Mail

------------------------------

From: urlichs@smurf.noris.de (Matthias Urlichs)
Subject: Re: Strange stty/logout problem in 1.1.20
Date: 22 Jun 1994 21:17:24 +0200

In comp.os.linux.development, article <2u9i5h$ihu@po-box.norand.com>,
  GREENJC@norand.com writes:
> 
> Did you "make clean" before compiling the kernel?  I had this happen back on
> 1.1.17 I think, where the new kernel seemed to break the shell's job control.
> [...]
> So, anyone want to offer a technical explanation for this? :)
> 
I'd like a technical explanation why the relevant files (which?) have not
been recompiled in the first place. Assuming that you did do a "make depend"
after patching (the dependencies might have changed!), "make clean" should
definitely not be necessary. 

-- 
Clay's Conclusion:
       Creativity is great, but plagiarism is faster.
-- 
Matthias Urlichs        \ XLink-POP N|rnberg  | EMail: urlichs@smurf.noris.de
Schleiermacherstra_e 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 N|rnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42

Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

------------------------------

From: lan_lada@aaf.alcatel.at (Marino Ladavac)
Subject: Re: Porting libpthreads to Linux?
Reply-To: lan_lada@aaf.alcatel.at
Date: Fri, 24 Jun 1994 08:21:31 GMT

Since the original author has a French address, the better site for Linux
pthreads library would be
        ftp://ftp.ibp.fr/pub/unix/threads/pthreads

The Florida State threads can be found on the same site at
        ftp://ftp.ibp.fr/pub/unix/threads/part

There is also at least one project dealing with kernel pthread implementation under
way.  Please contact me if you are interested.

Hope it helped,
/Alby

---
Proof by Intimidation:
        "I'm bigger, therefore I'm right."

noone@nowhere.in.particular



------------------------------

From: zxmgv07@studserv.zdv.uni-tuebingen.de (Michael Will)
Subject: Re: linux-1.1.20 breaks dosemu0.52
Date: 22 Jun 94 18:44:38 GMT

>RAINER SCHIELE INFORMATIK <81264@novell1.rz.fht-mannheim.de> wrote:
>>Hello
>>
>>Yesterday i compiled dossemu0.52. When i start it, i can not enter more then
>>one keystroke. My display locks then up. Using rawkey off, give me the 
>>chance to switch to another vt and kill the process. The Problem is mentioned
>>in the HOWTO(keybint on), but this must be another mistake. When using 
>>linux-1.1.19 dosemu0.52 runs.
For me it is exactly the other way round. I could not run it with 1.1.19
but succeded with 1.1.20 and 1.1.21.

The keyboard-handling is very messy though, it really is not what I would
call stable, but it is *fast* - I can run pinball or mpeg.exe and it
absolutely flies!

Great thing, eh? 

Cheers, Michael Will

------------------------------

Subject: Re: 'meta data' - the old fashioned way
From: peterd@pjd.dev.cdx.mot.com (Peter Desnoyers)
Date: Tue, 21 Jun 1994 15:10:11 GMT

djk@dirku.demon.co.uk (Dirk-Jan Koopman) writes:

>Mark Evans (evansmp@mb5194.aston.ac.uk) wrote:
>: Dirk-Jan Koopman (djk@dirku.demon.co.uk) wrote:
>: : Many (many) years ago there was a (wonderful) operating system called George 3
>: : (yes I was one of those programmers!). The way directory updates were done was
>: : as follows:-

[...]

It sounds an awful lot like a log-structured filesystem to me. There's
been a lot of work on this lately - see, for instance, Sprite. (which
is available - source and binaries - on a CDROM from Walnut Creek)

If anyone's really interested in adding such a filesystem to Linux,
I'm sure an afternoon at a good university library would turn up a few
candidates besides Sprite, including maybe one or two ones that run on
real Unix. The exercise of finding the source and porting it to Linux
is left to the reader...

                                Peter Desnoyers
-- 

------------------------------

From: bcr@k9.via.term.none (Bill C. Riemers)
Subject: Re: Hard disks limited to 16 heads?
Date: 21 Jun 94 19:55:35 GMT
Reply-To: bcr@physics.purdue.edu

In article <Crr5LF.Awo@sci.kun.nl> pieterh@sci.kun.nl (Peter Herweijer) writes:

   onno@stack.urc.tue.nl (Onno Hovers) writes:

    >Oystein H. Olsen (Biology) (oystein@bimcore.emory.edu) wrote:
    >> I have a 540 Mb hard disk from Dell that is configured for 32 heads,
    >> 524 cylinders, and 63 sectors. The kernel complains about using more

   This is not a valid configuration for an IDE drive.  No doubt your
   BIOS is doing some translation magic here.

Actually, I've yet to see a harddrive with 32 heads.  I don't think
they make them...  Normally when someone claims they have 32 heads,
its because that is what thier BIOS said, but thier BIOS is wrong.
If anyone comes across a real drive that has more than 16 heads, I'm
sure there would be more trouble convincing Linus to remove this
restriction.

    >> than 16 heads and cannot use the drive. I then reduced the heads to 16
    >> and doubled the cylinders to 1028. [...]
    >> So, back to the initial problem, why does the kernel (hd.c) limit the number
    >> of heads to 16?

The per fact that this worked, tells me you don't have 32 heads.  If
you did this wouldn't work!!!

    >This is a limitaition of the BIOS.

Only some BIOS's have this limitation.  With my BIOS it autoscans 
32 heads with my 1725MB harddrive.  However, since this I know this
is wrong, I select USER_CONFIG and type in the parameters listed on
a sticker on the side of my harddrive.  This makes Linux and DOS 
happy.  (Although Lilo doesn't seem to like it!!!)  And yes, the
correct parameters for me are 16 heads, and double the # of cylinders
from what is auto-detected.

   No way.  _This_ babe is an IDE limitation.  The BIOS will happily
   go all the way up to 255 (or was it 256?) heads, hence the 8GB BIOS
   capacity limit.  The IDE capacity limit is significantly higher.
   It's only when BIOS and IDE are combined that you get the famous
   500-odd MB limit.

    >There is a standard called "enhanced IDE" that should solve those
    >problems.

   Yes.  No bullshit, no physical and logical geometry hassles, just
   Linear Block Addressing (LBA).

No I believe enhanced IDE still only allows 16 heads.  But more than
1024 cylinders are allowed.  As I started out saying, I've yet to
come across a real harddrive that actually has more than 16 heads.

    >[...] Anyway, you should try to format your harddisk under the
    >following settings:
    >  cylinders: 1024 
    >  heads:     16
    >  sectors:   63
    >This should get you the maximum of space that's available. Only SCSI
    >harddisks can have more space. 

   This is NOT true.  Linux suffers from the BIOS limits, more
   specifically, the 1024 cylinder limit, only during booting.  So
   as long as you make sure that LILO and the kernel image are on a
   partition <1024 cylinders, you can happily use 1048 or even more
   cylinders, ignoring all warnings to the contrary.

Linux doesn't suffer from this limitation at all.  Your BIOS might.
Also Lilo does, but as near as I can tell this is caused by Lilo
itself and not by anything built into the kernel.  If need be, you
can specify your hard-drives geometry at compile time and bypass
any BIOS restrictions.  (I did this befor I relized my BIOS would
allow me to manually enter the correct configuration.)

   Having said that, I'm not sure what Linux' limits for IDE geometry
   actually are---maybe a kernel wizard can enlighten us.  But I'm
   positive that it can go beyond 1024 cylinders.


Works fine for me.

                                Bill


------------------------------

From: mrex@indigo0.urz.uni-heidelberg.de (Martin Rex)
Subject: Re: linux-1.1.20 breaks dosemu0.52
Date: Sat, 25 Jun 1994 00:56:34 GMT
Reply-To: mrex@rz.fht-mannheim.de

Mike Heidt (heidt@mikey.jsc.nasa.gov) wrote:
> I also had problems with dosemu0.52 and linux 1.0.20. Dosemu would report no
> problems, then blank the screen and hang. I was using an ATI ultra 
> mach 8 card. I replaced the mach 8 with an et4000 card and everything
> works fine, so I conclude that the problem is in the video drvers. The
> mach 8 was hanging during execution of the onboard bios. Turning graphics
> off worked mostly, but no cursor. I would like to go back to the mach 8
> if the problem ever gets fixed because it is faster in X windows. BTW, the
> mach 8 worked fine in dosemu0.49.

The reason your ATI Ultra was not working might be the video ports it
is using.  I had the same problem with my ATI Graphics Ultra, so I enabled
port debugging and traced what ports where accessed.  With the following
line dosemu-0.52 and linux-1.1.19 works just as good as dosemu-0.49 did.

ports  { 0x1ce 0x1cf 0x238 0x23b 0x23c 0x23f 0x9ae8 0x9ae9 0x9aee 0x9aef }

-Martin Rex
--
Martin Rex
Rechenzentrum, Netzwerk- und Systemadministration (Unix)
Fachhochschule fuer Technik Mannheim, Germany
E-Mail: mrex@rz.fht-mannheim.de

------------------------------


** 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
******************************
