Linux-Development-Sys Digest #642, Volume #6     Wed, 21 Apr 99 21:14:38 EDT

Contents:
  Re: Beowulf, Can we use it? ("G. Sumner Hayes")
  Re: Glibc rant (Juergen Heinzl)
  Re: Problem with File System Check (Don Baccus)
  NFS vs DFS
  Re: Problem with File System Check (Mark Hahn)
  Re: NFS fcntl locking fails (kernel 2.2.5 -> 2.2.2) (Miquel van Smoorenburg)
  Re: Problem with File System Check (Juergen Heinzl)
  Re: Threads >> PThreads or LinuxThreads?? (Juergen Heinzl)
  Re: Ip Aliases - sending packets from aliases? (Andi Kleen)
  Re: Pbl with ATI RAGE PRO TURBO 8Mo (Vincent)
  Linux on old IBM M20 ? (Philippe Le Foll)
  Re: using mmap for PCI device memory ("jeff")
  Re: newdie: compiling shared libs ("MV Communications")
  Reading/Writing ethernet IP ("Mike Arias")
  Newby and fundamental problem ("Isidro")
  Re: saving program state with core files (Arthur Rabatin)
  Lilo problem with SMP systems and Phoenix BIOS (Josef =?iso-8859-1?Q?M=F6llers?=)
  Re: HELP!  Something Wicked happened! (Jeff McWilliams)

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

From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Subject: Re: Beowulf, Can we use it?
Date: Wed, 21 Apr 1999 17:16:06 -0400

Clint Byrum wrote:
> I'm trying to see if we can use Beowulf to provide bigger and/or more 
> robust linux systems to run our business apps on. Currently, we can 
> put(based on benchmarks) 200 users on a 4 Processor, intel SC450NX 
> Board w/ 1GB of RAM, a Mylex HW Raid Controller, running on the 2.2.2 
> kernel.  What I want to know is, If we wanted to do 300 users, could 
> we just use beowulf to "cluster" in another machine of similar 
> caliber(or maybe half). 

Probably not.  Beowulf applications need to be written to use PVM or
MPI, so if you're using off-the-shelf business apps then it's not
really a good choice.  Moreover, it sounds like your application isn't
really that well suited to a Beowulf-style approach in the first place.

> Would it be better just to get a Gigbit ethernet connect between them 
> and have one use nfs to access the other one(half the users would log 
> into the second machine)? Please advise! Thanks in advance!

Some sort of load-balancing solution like this is probably simpler, but
still not completely trivial if you want it to be transparent to the
users.  You could do round-robin DNS or something (so that logins to
job.wherever.com get routed alternately to job1.wherever.com and
job2.wherever.com based on whatever heuristic you want), but then you
still have to deal with the regular distributed account problems
(passwd changes, NFS or migrated home directories, NYS, etc).  If you're
already a distributed environment, fairly straightforward.  If not,
you have some reading to do.

Coda will probably be an eventual solution to some of these issues, but
it's not yet ready for deployment unless you're pretty familiar with
it and ready to tinker and troubleshoot a fair amount.

If you don't need a completely transparent solution, this becomes
straightforward -- get a couple of boxes, figure out a way to route
the incoming connections, and you're pretty much done.  In theory.

--Sumner

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

From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: Glibc rant
Date: Wed, 21 Apr 1999 21:23:04 GMT

In article <7fj2fl$28o$[EMAIL PROTECTED]>, Sam E. Trenholme wrote:
>I have some concerns about the relatively fast upgrade to glib2.1 from
>glibc2.0.  Having finally taken the plunge, and gone from libc5 to
>glibc2.0, I don't want to be pushed to make this kind of major surgery on
>the systems I administer once again.  Which is why I am wondering this: 
>
>* Will glibc2.1 be able to run _all_ glibc2.0 binaries without any problem
>  whatsoever?

No.

>In other words, can I replace glibc2.0 with glibc2.1 on a running glibc2.0
>system, without having to recompile every single program on my system?

Yes.

>I can understand a fundamental shift in the binary format once every three
>years or so, such as the a.out->elf(libc5) transition in 1995, and the
>libc5->glibc2.0 transition in 1998, but doing one every year is too often. 

No need to. I started to switch some weeks ago after running systems with
libc5 for years.

>Which is why I hope glib2.1 is not the same kind of fundamental shift
>libc5->glibc2.0 was.

Personally I have always had my qualms regarding 2.0.x *distributions*,
but all right. Regarding glibc-2.1, you can still wait and see and let
it stabilise it a bit. Still the formats have not changed fundamentally,
though there are some known issues but I cannot remember anyone telling
people glibc-2.0.x would be the final word for years to come. Add to
that some other priorities like stable systems the main reason I've
waited so long.

Cheers,
Juergen

-- 
\ Real name     : Jürgen Heinzl                 \       no flames      /
 \ EMail Private : [EMAIL PROTECTED] \ send money instead /

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

Subject: Re: Problem with File System Check
From: [EMAIL PROTECTED] (Don Baccus)
Date: 21 Apr 1999 10:44:02 PST

In article <[EMAIL PROTECTED]>,
Varghese Panicker K K  <[EMAIL PROTECTED]> wrote:
>HI All
>
>       I've used LINUX and a variety of UNIX flavors during
>the academics.

[crashing stories...]

>       Considering the popularity that LINUX has achieved
>as a good (or is it stable ?) OS, I think this is an important
>issue. I was wondering, whether there is any thing specific 
>to LINUX filesystems (or filesystem checks) which makes it
> behave 'badly'. Any comments ?

How many systems have you used linux on?  The kind of symptoms
you describe could easily be caused by flakey hardware and
not really represent the stability of the operating system
itself.  Believe me, commercial Unix flavors can act really
weird on an individual box which is flakey, i.e. exhibits
intermittent and hard-to-pin-down hardware problems.

I had my website up on a linux system a good four years
ago and it never crashed until someone broke in to the
system and pre-empted it to ftp stolen software all
over the place.

I should think the system's even more stable today, and
my personal linux system (2.0.36) has been up on a
P200 for about three months now, and has only been down
when I've shut it down to install new stuff, etc.  In
contrast, my win98 system freezes or otherwise hoses 
itself about every other day.

-- 

- Don Baccus, Portland OR <[EMAIL PROTECTED]>
  Nature photos, on-line guides, at http://donb.photo.net

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

From: <[EMAIL PROTECTED]>
Subject: NFS vs DFS
Date: Wed, 21 Apr 1999 16:51:55 -0500


Hi all
  

  I would like to know the essential differences between
Network File System and Distributed File System.

  NFS works by mounting remote file system ( exported by server)
on client machines. Incremental modifications made in a shared file
will not be visible across other clients. 

  I think NFS doesn't support migration of file from one server/machine
to other. Are there any othe primary differences. Could you list
any true DFS implemenatations.

  Can someone throw some light on these issues ?
 
Vijayan


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

From: Mark Hahn <[EMAIL PROTECTED]>
Subject: Re: Problem with File System Check
Date: 21 Apr 1999 20:20:15 GMT

> the academics. I have noticed one thing, LINUX systems are
> more prone to crash after an improper shutdown (may be a
...

only because Linux is more agressive at caching.  there are numerous
solutions available to you:

1. get an ups!  it's incredibly lame to complain about what happens when you
   abuse your computer with crappy power.
2. mount some of your filesystems readonly, or keep around
   a spare, bootable root partition.
3. investigate whether other mount options would reduce your 
   vulnerability.
4. fiddle with the tunables in /proc/sys that control how much
   dirty data is cached, and for how long.
5. wait for SCT's Journalling extension to ext2.

option 4 can reduce arbitrarily your exposure to crappy power.

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

From: [EMAIL PROTECTED] (Miquel van Smoorenburg)
Subject: Re: NFS fcntl locking fails (kernel 2.2.5 -> 2.2.2)
Date: 22 Apr 1999 00:52:52 +0200

In article <7fkduo$kro$[EMAIL PROTECTED]>,
Petter Reinholdtsen <[EMAIL PROTECTED]> wrote:
>I have a problem getting WP8 for Linux to run on our client machines.
>I have tracked it down to locking problems on NFS filesystems.
>Our Linux clients are RedHat 5.2 with kernel 2.2.5, and our Linux
>fileserver is RedHat 5.2 with kernel 2.2.2.

Linux 2.2.x tries to use NFS locking, while the user-level NFS server
doesn't support that. Mount your partition with the "nolock" option
or run the new kernel-level NFS daemon (and statd, and lockd) on
the server.

Mike.
-- 
Indifference will certainly be the downfall of mankind, but who cares?

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

From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: Problem with File System Check
Date: Wed, 21 Apr 1999 21:23:03 GMT

In article <[EMAIL PROTECTED]>, Varghese Panicker K K wrote:
>HI All
>
>       I've used LINUX and a variety of UNIX flavors during
>the academics. I have noticed one thing, LINUX systems are
>more prone to crash after an improper shutdown (may be a
>power failure which used to happen vey often). In one case I
>found that while booting, it is asking to do fsck manually 
>and asks the root passwd. But when I give the root passwd, 
>the system just reboots and gives the earlier message again
>(Infinite loop). At this point I need a floppy to disk to 
>reboot the system.

Here I would like to see your init setup and stuff. Sadly
enough I had the chance to experience some powerfailures
at work, starting with 0.99.10 and ending with my former
job and kernel 2.0.36.

>       However, most of the other UNIX flavors like Solaris,
>IRIX, AIX etc. very rarely (when compared to LINUX) gave such
>errors. Even the very old Sun OS 4.0.x. (running on SUN3 
>machines) was more stable. 

Stable means firstly a machine does not crash, though sure,
the most error prone thing is the filesystem and Linux does
not offer a journaling one yet.

>       Considering the popularity that LINUX has achieved
>as a good (or is it stable ?) OS, I think this is an important
>issue. I was wondering, whether there is any thing specific 
>to LINUX filesystems (or filesystem checks) which makes it
> behave 'badly'. Any comments ?

See above. I do not doubt what happened to you and in an
instable environment it might help to tune some bdflush
parameters.

Other things to consider are a small / partition, here
about 7MB used, mounting /usr and other partition read
only if possible and so on.

In addition my standard advice, have a second / partition
that is bootable ready, on a second disk if possible. Just
one case is not enough though and I've seen other systems
seen that fell over badly too. Caching of (meta) data is
"somewhat" dangerous.

Cheers,
Juergen

-- 
\ Real name     : Jürgen Heinzl                 \       no flames      /
 \ EMail Private : [EMAIL PROTECTED] \ send money instead /

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

From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: Threads >> PThreads or LinuxThreads??
Date: Wed, 21 Apr 1999 21:23:04 GMT

In article <[EMAIL PROTECTED]>, Martin Recktenwald wrote:
>Lorenz Hahn <[EMAIL PROTECTED]> writes:
>
>> As far as I know, Posix defins the API to threads, not the way they are
>> implemented. `Linuxthreads' as implementation and Posix as API shouldn't
>> exclude each other.
>
>Linuxthreads uses the POSIX API but is not (yet?) completely POSIX compliant.

You might have to be somewhat more specific here for there is
no such thing as "the" POSIX API regarding threads.
Just try to compile the same code on three different machines 8-/

Cheers,
Juergen

-- 
\ Real name     : Jürgen Heinzl                 \       no flames      /
 \ EMail Private : [EMAIL PROTECTED] \ send money instead /

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

From: Andi Kleen <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking
Subject: Re: Ip Aliases - sending packets from aliases?
Date: 21 Apr 1999 19:47:32 +0200

Geoff Wong <[EMAIL PROTECTED]> writes:
> 
> If so; could someone point me at the correct ioctl()
> or the socket options or even a snippet of code.

Use bind(2) to the alias before the connect.  After a connect
the local address cannot be changed anymore for obvious reasons.
bind can only be called once on a socket.

-Andi

-- 
This is like TV. I don't like TV.

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

From: Vincent <[EMAIL PROTECTED]>
Crossposted-To: 
comp.os.linux.development.apps,comp.os.linux.development,comp.os.linux.hardware,alt.os.linux,alt.linux,comp.os.linux.x
Subject: Re: Pbl with ATI RAGE PRO TURBO 8Mo
Date: Tue, 20 Apr 1999 13:45:42 +0200

I have a big problem with my video card. My hardware are
ATI RAGE PRO TURBO 87Mo with a Trinitron Sony 19" screen.

With the serveur MACH64 I can't put the resolution above 1024*768.
When I start with the SVGA server I can put the resolution to 1280*1024
but all text console have a black screen.

How can I solve this problem ???

[EMAIL PROTECTED]




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

From: Philippe Le Foll <[EMAIL PROTECTED]>
Subject: Linux on old IBM M20 ?
Date: Tue, 20 Apr 1999 11:14:00 +0200

Did someone already succeded to run Linux and
pre-powerpc IBM M20 machines ?

Philippe

-- 
La vitesse peut tuer: Utilisez Windows    (o^o)
======================================oOO==(~)==OOo========
[EMAIL PROTECTED], Philippe Le Foll Fridu (+33/0)609.794.781

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

From: "jeff" <[EMAIL PROTECTED]>
Subject: Re: using mmap for PCI device memory
Date: Wed, 21 Apr 1999 18:03:06 -0500

Tim,
I am currently struggling with the same problem. I even sent an email to
Rubini but not much help from his reply...

Anyways, I believe you indicate the physical address (i.e I am guessing that
the address read from the config space) in the remap_page_range call... see
page 281..

unsigned long physical = phys addr + off + PAGE_OFFSET;

I am getting segmentation fault... when I call the "mmap" function from the
user space.... struggle continues..

jeff-

Tim Linehan wrote in message ...
>Hello,
>
>In my ongoing "trial by fire" in the Linux Driver world, I'm now trying to
>map some device memory back to a user program, so it can have access to the
>device memory (not unlike an X Server).
>
>I've successfully detected (via PCI Config space) the physical device
memory
>location, and now I want to tell the user program where this is located.  I
>assume I must first get a virtual address for this memory (by using vremap
>()).
>
>If I understand correctly, I use the mmap method of my driver to implement
>this function.  I'm reading the "Linux Device Drivers" book by Rubini.  In
>the mmap method of one of his sample drivers, he uses remap_page_range ()
to
>remap the memory.  My question is, how do you tell this function where the
>memory that I want remapped is located?  Is it as simple as providing the
>physical address to the vm_area_struct->start member?
>
>Basically, in my code,
>G.REG_BASE = physical memory location (as per PCI Config space);
>G.virtual_REG_BASE = vremap (G.REG_BASE, REG_SIZE);
>
>then in my device_mmap function:
>int device_mmap (struct inode *inode, struct file *file, struct
>vm_area_struct *vma)
>{
>    vma->start = G.virtual_REG_BASE;
>    vma->end = G.virtual_REG_BASE + REG_SIZE;
>
>    if (remap_page_rnage (vma->vm_start, vma->vm_offset, vma->vm_end -
>vma->vm_start, vma->vm_page_prot))
>        return -EAGAIN;
>...
>}
>
>However, this does not appear to actually return a pointer to the location
I
>want.  From my test program, I call mmap:
>
>reg_base = (DWORD) mmap (0, 4*1024, PROT_READ | PROT_WRITE, MAP_PRIVATE,
>                                                    file_desc, 0);
>
>I do get a value returned, but it's not pointing to my PCI device memory.
(I
>can tell by reading back certain offsets, which have known values).
>
>If anyone has some advice or can straighten me out, I'd appreciate it.  As
I
>mentioned, I do have the Rubini book, and I have looked at some of the X
>Server code, but nothing that is device specific, where it maps in some
>memory on a device, back to a user program.  This is what I want to do.
>
>Whew.
>
>TL
>
>
>
>



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

From: "MV Communications" <[EMAIL PROTECTED]>
Subject: Re: newdie: compiling shared libs
Date: Tue, 20 Apr 1999 08:37:42 -0400

I did not phsically edit it, if that is what you mean, but i did run
ldconfig after my compile and installs. I will take a look-see to find out
what i can. Thanks.



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

From: "Mike Arias" <[EMAIL PROTECTED]>
Subject: Reading/Writing ethernet IP
Date: Tue, 20 Apr 1999 08:31:00 -0400

I am having trouble reading in IP traffic from my ethernet card and sending
out another one.  I have two 3Com 590.
I need to be able to read in any IP (including tcp, udp and so on) from one
ethernet and send out the other.  I someone could be so kind as to send me a
code fragment or simply point me in the right direction, I would appreciate
it very much.

Thanks,
Mike



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

From: "Isidro" <[EMAIL PROTECTED]>
Subject: Newby and fundamental problem
Date: 20 Apr 1999 12:06:24 GMT

I have a QPC-S40 DSP board. I want to read and write in its memory under
Linux.
¿How do I do? Must I write a device driver? Can I access the memory in a
ordinary user process? Is it useful the /dev/mem device?
Please, can sombody introduce me in this issue?

Thnaks in advance
Isidro

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

From: Arthur Rabatin <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc,comp.os.linux.development.apps
Subject: Re: saving program state with core files
Date: Tue, 20 Apr 1999 12:17:07 +0100
Reply-To: [EMAIL PROTECTED]

dementen wrote:
> 
> Hi,
> 
> I want to be able to save the state of a program (like a game for
> example) during its running and after to be able to load this state to
> continue the process at another time.
> 

Why don't you just write all relevant data to a file which
is then loaded at program startup? That could be put either
in the user's home dir or some shared dir.

If you want persistent data despite program crash you could either
save the current state from time to time and then return to the
last saved state (like emacs saves temporaries), or you can
(in C++) rely on exception handling to manage writing the state (but
that can be tricky as your data might not be available anymore).

Arthur



/* *******************************************************
Rabatin Investment Technology Ltd       http://rabatin.com
11 Grosvenor Place, 5th Floor, Svecia International UK Ltd
Tel: 0171 887 0 887  [EMAIL PROTECTED]   Fax 0171 887 0 888
*/

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

From: Josef =?iso-8859-1?Q?M=F6llers?= <[EMAIL PROTECTED]>
Subject: Lilo problem with SMP systems and Phoenix BIOS
Date: Tue, 20 Apr 1999 14:19:55 +0200

This is a multi-part message in MIME format.
==============02373531B2F937F22E79401D
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

Phoenix BIOS use the top end of base memory (640K) to store an "extended
BIOS data area". Among other things, the MP config table is stored
there. Since LILO assumes that the entire 640K are free, collisions
occur resulting in a corrupted MP config table.

I have attached two patches, one for LILO v2.0 and one for LILO 2.1.
Werner Almesberger has these patches, too, but since he's apparently
very busy, and I'd like to have some additional feedback, I'm posting
them here.

In essence, LILO is split into two parts: the first stage loader,
together with its data structures, is left where it is. The second stage
loader, together with its data structures, is relocated to an unused
memory segment at 0xb000, i.e. just below the kernel load area.
This frees 19K for use by the EBDA.

Josef
-- =

PS Die hier dargestellte Meinung ist die persoenliche Meinung des
Autors!
PS This article reflects the autor=B4s personal views only!
==============02373531B2F937F22E79401D
Content-Type: text/plain; charset=us-ascii;
 name="lilo20.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="lilo20.patch"

--- lilo.h.orig Thu Mar 18 10:50:36 1999
+++ lilo.h      Thu Mar 18 10:14:33 1999
@@ -143,10 +143,18 @@
 DFLCMD   = 0x2600                      ! default command line
 MAP      = 0x2000                      ! map load area offset
 KEYTABLE  = 0x2800                     ! keyboard translation table offset
+#ifndef LCF_LARGE_EBDA
 PARMLINE  = 0x2a00                     ! parameter line construction area off.
+#else
+PARMLINE  = 0xB000                     ! parameter line construction area off.
+#endif
 SECOND   = 0x1000                      ! second stage loader load address
 SECOND_SS = 0xB000                     ! second as seen from SS:0000
+#ifndef LCF_LARGE_EBDA
 SECONDSEG = 0x9B00                     ! second stage loader segment
+#else
+SECONDSEG = 0x0B00                     ! second stage loader segment
+#endif
 SLA_SIZE  = 0x9E00                     ! setup load area size
 KBBEG     = 0x41A                      ! beginning of keyboard buffer
 KBEND    = 0x41C                       ! end of keyboard buffer
--- first.S.orig        Thu Mar 18 10:50:36 1999
+++ first.S     Thu Mar 18 10:00:57 1999
@@ -99,7 +99,9 @@
        call    display
 
 lagain:        mov     si,#d_addr      ! ready to load the second stage loader
-       mov     bx,#SECOND
+       mov     ax,#SECONDSEG
+       mov     es,ax
+       xor     bx,bx
        cld
 sload: lodsw                   ! get CX
        mov     cx,ax
--- second.S.orig       Thu Mar 18 10:50:36 1999
+++ second.S    Thu Mar 18 10:02:51 1999
@@ -793,6 +793,10 @@
        call    load1
        mov     si,cmdbeg       ! copy non-options part of command line
        mov     di,#PARMLINE
+#ifdef LCF_LARGE_EBDA
+       mov     ax,#INITSEG
+       mov     es,ax
+#endif
 cpnocl:        cmp     si,options      ! at beginning of options ?
        je      cpnodn          ! yes -> go on
        movsb                   ! copy one byte
@@ -831,8 +835,13 @@
        seg     es
        mov     CL_MAGIC_ADDR,#CL_MAGIC ! set magic number
        seg     es
+#ifndef LCF_LARGE_EBDA
        mov     word ptr CL_OFFSET,#PARMLINE+SECOND_SS
                                ! set parameter line offset
+#else
+       mov     word ptr CL_OFFSET,#PARMLINE
+                               ! set parameter line offset
+#endif
        pop     si              ! restore SI
        lodsw                   ! get flags bit map
        mov     bx,ax

==============02373531B2F937F22E79401D
Content-Type: text/plain; charset=us-ascii;
 name="lilo21.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="lilo21.patch"

--- lilo.h.orig Thu Mar 18 10:47:47 1999
+++ lilo.h      Thu Mar 18 10:48:58 1999
@@ -144,15 +144,13 @@
 PARTS_LOAD= 0x0600                     ! partition sector load address
 PARTS_SCR = 0x0800                     ! ditto, for non-boot partitions
 PART_TABLE= 0x07BE                     ! partition table
-
-#ifndef LCF_LARGE_EBDA
 FIRSTSEG  = 0x9A00
 STACKSEG  = 0x9000
+
+#ifndef LCF_LARGE_EBDA
 SECONDSEG = 0x9B00                     ! second stage loader segment
 #else
-FIRSTSEG  = 0x8A00
-STACKSEG  = 0x8000
-SECONDSEG = 0x8B00                     ! second stage loader segment
+SECONDSEG = 0x0B00                     ! second stage loader segment
 #endif
 
 INITSEG   = DEF_INITSEG                        ! we move boot here - out of the way
@@ -164,7 +162,13 @@
 DFLCMD   = 0x2600                      ! default command line
 MAP      = 0x2000                      ! map load area offset
 KEYTABLE  = 0x2800                     ! keyboard translation table offset
+
+#ifndef LCF_LARGE_EBDA
 PARMLINE  = 0x2a00                     ! parameter line construction area off.
+#else
+PARMLINE  = 0xB000                     ! parameter line construction area off.
+#endif
+
 SECOND   = 0x1000                      ! second stage loader load address
 SECOND_SS = 0xB000                     ! second as seen from SS:0000
 SLA_SIZE  = 0x9E00                     ! setup load area size
--- first.S.orig        Thu Mar 18 10:48:00 1999
+++ first.S     Thu Mar 18 10:38:39 1999
@@ -100,7 +100,9 @@
        call    display
 
 lagain:        mov     si,#d_addr      ! ready to load the second stage loader
-       mov     bx,#SECOND
+       mov     ax,#SECONDSEG
+       mov     es,ax
+       xor     bx,bx
        cld
 sload: lodsw                   ! get CX
        mov     cx,ax
--- second.S.orig       Thu Mar 18 10:48:09 1999
+++ second.S    Thu Mar 18 10:47:24 1999
@@ -793,6 +793,10 @@
        call    load1
        mov     si,cmdbeg       ! copy non-options part of command line
        mov     di,#PARMLINE
+#ifdef LCF_LARGE_EBDA
+       mov     ax,#INITSEG
+       mov     es,ax
+#endif
 cpnocl:        cmp     si,options      ! at beginning of options ?
        je      cpnodn          ! yes -> go on
        movsb                   ! copy one byte
@@ -831,8 +835,13 @@
        seg     es
        mov     CL_MAGIC_ADDR,#CL_MAGIC ! set magic number
        seg     es
+#ifndef LCF_LARGE_EBDA
        mov     word ptr CL_OFFSET,#PARMLINE+SECOND_SS
                                ! set parameter line offset
+#else
+       mov     word ptr CL_OFFSET,#PARMLINE
+                               ! set parameter line offset
+#endif
        pop     si              ! restore SI
        lodsw                   ! get flags bit map
        mov     bx,ax

==============02373531B2F937F22E79401D==


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

From: [EMAIL PROTECTED] (Jeff McWilliams)
Subject: Re: HELP!  Something Wicked happened!
Reply-To: [EMAIL PROTECTED]
Date: Tue, 20 Apr 1999 13:44:46 GMT

In article <7fh7le$s9i$[EMAIL PROTECTED]>, Peter Samuelson wrote:
>
>Have you read Richard Gooch's Kernel Newsflash page?

Thanks, Peter.  I'll get the latest kernel, apply the patch, and see
what happens. 

Jeff
-- 
Jeff McWilliams - Advanced Development Engineer, ACE Technologies
[EMAIL PROTECTED]



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


** 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: [EMAIL PROTECTED]

You can send mail to the entire list (and comp.os.linux.development.system) via:

    Internet: [EMAIL PROTECTED]

Linux may be obtained via one of these FTP sites:
    ftp.funet.fi                                pub/Linux
    tsx-11.mit.edu                              pub/linux
    sunsite.unc.edu                             pub/Linux

End of Linux-Development-System Digest
******************************

Reply via email to