Linux-Development-Sys Digest #847, Volume #7 Fri, 12 May 00 06:13:15 EDT
Contents:
Instruction Access Exception ([EMAIL PROTECTED])
Re: ANSI C & void main() (Kaz Kylheku)
PPP implementation with numbered mode ("Samuel Wang")
Re: ANSI C & void main() ("Mark Graybill")
Re: LILO Win+Linux on an old system (Josef Moellers)
Re: LILO Win+Linux on an old system (Josef Moellers)
Distributed file system (Chetan Ahuja)
Re: tcp window (bob@p)
Re: ANSI C & void main() (Erik Max Francis)
Re: pid vs. thread question (Anand Krishnamoorthy)
Re: where can i find a kernel debugger? (Anand Krishnamoorthy)
Re: How to create memory in ptraced child process w/o child source code (Anand
Krishnamoorthy)
Re: Other than console (Anand Krishnamoorthy)
Re: Instruction Access Exception (Anand Krishnamoorthy)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.setup,comp.os.linux.misc
Subject: Instruction Access Exception
Date: 12 May 2000 04:23:29 GMT
Hey all,
I'm trying to recompile the kernel on my SPARCstation 10.
I downloaded the source (2.2.12 and 2.2.14 tried) from tsx-11, make
config, make dep, make vmlinux, make modules, copied vmlinux to
/boot/vmlinux-2.2.14 (also moved the System.map), and updated silo.conf
appropriately.
What fairly obvious step am I missing here? Every time I boot a kernel
that I have compiled myself, I get "Instruction Access Exception" and get
kicked back to the boot PROM. I then restart the system with the 'boot'
command and use the old kernel to get back in.
Ideas?
--J
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: ANSI C & void main()
Reply-To: [EMAIL PROTECTED]
Date: Fri, 12 May 2000 05:24:21 GMT
On Fri, 12 May 2000 03:41:31 GMT, Mark Graybill <[EMAIL PROTECTED]> wrote:
>There's been a heated discussion concerning whether void main() is allowed
>by the current ANSI C standard, which brought to the group some color.
>
>The discussion has served two purposes for me: 1) My learning of void main()
>being migrated out of the ANSI C standard, and 2) aided a research project
void main was never in any ANSI or ISO standard. It was ANSI C that formally
added the void keyword to the language, but never in the role as the return
value for main.
>in psychology, although I have yet to receive approval for it.
>
>Since my C days during my undergraduate studies were pre-ANSI standard, and
>figuring my memory was failing, I checked with the Computer Science and
>Engineering department at the University of Minnesota, and found that the
>original standard did allow void main().
I suspect that a member of the janitorial staff played a prank on you.
Next time, try calling them during office hours. ;)
>As far as undefined behavior, which is not defined as behavior not advocated
>by ANSI standards but rather behavior not yet observed, the behavior of
Undefined behavior is quite simply behavior that is not defined. The standard
is a merely a requirement specification which describes features that the
conforming language implementation must provide, and rules that programs must
obey in order to be acceptable to implementations. Undefined behavior is
simply the absence of requirements. If you invoke it, you are in the hands of
the implementor. The role of standards is not to advocate or observe, but
simply to specify---or not, as the case may be.
>using void main() is defined if it is consistently observed in a large
>sample of popular compilers and platforms.
Compilers are man made. There is no need to study them empirically like
an orinthologist might study a flock of birds.
If you write some non-portable program, and it outputs -1 on half the compilers
in a sample, and 1 on the other half, does the program compute a mean value of
zero within some confidence interval? ;)
You should repost some of this stuff to comp.lang.c. Or better yet, comp.std.c.
Heh heh.
--
#exclude <windows.h>
------------------------------
From: "Samuel Wang" <[EMAIL PROTECTED]>
Subject: PPP implementation with numbered mode
Date: Thu, 11 May 2000 23:07:51 -0700
Does anyone know of any PPP implementation that supports numbered mode ?
Thanks in advance.
Samuel
------------------------------
Reply-To: "Mark Graybill" <[EMAIL PROTECTED]>
From: "Mark Graybill" <[EMAIL PROTECTED]>
Subject: Re: ANSI C & void main()
Date: Fri, 12 May 2000 06:05:26 GMT
Kaz Kylheku wrote in message ...
>On Fri, 12 May 2000 03:41:31 GMT, Mark Graybill <[EMAIL PROTECTED]> wrote:
>>Since my C days during my undergraduate studies were pre-ANSI standard,
and
>>figuring my memory was failing, I checked with the Computer Science and
>>Engineering department at the University of Minnesota, and found that the
>>original standard did allow void main().
>
>I suspect that a member of the janitorial staff played a prank on you.
>Next time, try calling them during office hours. ;)
It was Professor Matts Heimdahl, Ph.D. - CSci
>>As far as undefined behavior, which is not defined as behavior not
advocated
>>by ANSI standards but rather behavior not yet observed, the behavior of
>
>Undefined behavior is quite simply behavior that is not defined. The
standard
>is a merely a requirement specification which describes features that the
>conforming language implementation must provide, and rules that programs
must
>obey in order to be acceptable to implementations. Undefined behavior is
>simply the absence of requirements. If you invoke it, you are in the hands
of
>the implementor. The role of standards is not to advocate or observe, but
>simply to specify---or not, as the case may be.
Agreed - we are at the mercy of the tools ghouls. Nothing is more annoying
than misbehaving tools.
Definition comes from both specification, and observation. A certain
behavior can be defined in a standard, but not observed. For instance, I
remember one project, and OS project based on the microkernel, where ++i
worked only intermittently. It was surprise to find junior members of the
team unsure why ++i didn't work, and wouldn't say anything until they were
sure they didn't screw up (it's hard to screw up ++i.)
Turns out it was a bug in the microkernel. Hence ++i was defined by the
standard, but not observed.
>>using void main() is defined if it is consistently observed in a large
>>sample of popular compilers and platforms.
>
>Compilers are man made. There is no need to study them empirically like
>an orinthologist might study a flock of birds.
It comes though experience, not study. However, I can think of many more
interesting things to do than study compilers or develop them (like Y2K
work.) :)
>If you write some non-portable program, and it outputs -1 on half the
compilers
>in a sample, and 1 on the other half, does the program compute a mean value
of
>zero within some confidence interval? ;)
>
>You should repost some of this stuff to comp.lang.c. Or better yet,
comp.std.c.
>Heh heh.
It is good rhetoric, isn't it? :)
Cheers,
Mark
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: LILO Win+Linux on an old system
Date: Fri, 12 May 2000 08:09:03 +0200
"Paul D. Smith" wrote:
> =
> %% Josef Moellers <[EMAIL PROTECTED]> writes:
> =
> jm> "Paul D. Smith" wrote:
> =
> >> I'm not exactly sure what you're trying to say here, but as I said=
, it
> >> can't be a problem with the Windows filesystem since I'm not able =
to get
> >> past the "LI" in the boot sequence.
> =
> jm> Technically speaking, this means that the first "half" of the LIL=
O boot
> jm> loader was loaded successfully, but the second "half" wasn't ("ha=
lf"
> jm> because they are not equal in size).
> =
> Yep. But I have no idea what, exactly, the halves entail. I assume
> that if I can't even get the LILO "boot:" prompt, it sure hasn't
> examined enough of /dev/hda1 (which is not the root partition) to decid=
e
> what filesystem is on it. Why would it?
The first "half" (or first stage loader, as it's called) is usually
installed in either the MBR (master boot record, the very very first
sector on a hard disk) or the partition boot record (the very very first
sector in the partition LINUX is installed in). The BIOS has no problem
in finding it (the MBR has cylinder 0, head 0, sector 1, if the partiton
is accessable, then the partition boot record can also be found.)
The second "half" (or second stage loader, as it's surprisingly called
B-{) is located in the file "/boot/boot.b". When you run "lilo" in
Linux, then the first stage loader is modified by inserting the exact
locations of the sectors that contain the second stage loader. This has
the advantage that the first stage loader doesn't have to know anything
about ext2 filesystems etc.
But here's the catch: Both, Linux and the BIOS, do not have to have the
same idea about the disk's logical layout. Since, by default, the second
stage loader's sector addresses are recorded in the first stage loader
in cylinder/head/sector form suitable for an "INT 13H" call, this will
lead to problems when both disagree.
Example:
Linux thinks the disk has 255 sectors/track and 32 heads while the BIOS
thinks it has 63 sectors/track and 32 heads. (The number of cylinders is
irrelevant here.)
Linux determines that the first sector of the second stage loader is at
cylinder 1, sector 2, head 3 which is sector number 8227, if you number
the sctors linearly. So it records 1/2/3 (c/h/s) in the first stage
loader. Now you reboot and the BIOS is told (by the first stage loader's
call to "INT 13H") to read cylinder 1, sector 2, head 3. Since the BIOS
thinks the disk has only 63 sectors/track, it will try to read sector
number 2083.
The "linear" flag in /etc/lilo.conf" has the effect of recording the
linear address of 8227 in the first stage loader. The first stage loader
now has to call the BIOS twice: once to determine the logical layout of
the disk (i.e. 63 sectors/track and 32 heads). With this information it
can determine that the first sector of the second stage loader is at
cylinder 4, head 5, sector 3. It can then call "INT 13H" the second time
to read that sector which is correct.
Another possibility is to tell the lilo installer (i.e. the "lilo"
program you run unter Linux) what the BIOS thinks the logical layout of
the disk is by using the "disk=3D" directive, but just specifying "linear=
"
will usually do the trick.
> =
> jm> 1. to add the keyword "linear" to your /etc/lilo.conf file?
> =
> Yes, that didn't help :(.
I hope the somewhat lengthy explanation above tells you why.
> jm> 2. to add the disk parameters (C/H/S) to the /etc/lilo.conf file?=
> =
> I haven't done this. I'm not sure how to proceed here. I recall a
> mention on the docs, I'll take a look for details tonight.
> =
> jm> I'd suggest you try the first first, it often fixes the problem.
> =
> I read all the docs, including the mini-howtos, user guide, and
> technical doc. I searched the RedHat problems DB.
> =
> While I have seen references to getting to "LI" and no further (althoug=
h
> none with any useful suggestions for fixing it), I've never seen one
> that mentioned what happens to me: it doesn't just print "LI" then stop=
,
> it prints "LI" forever, until I reboot:
> =
> LI
> LI
> LI
> LI
> LI
> LI
It could just be that, in Linux, the first sector of the second stage
loader has the same c/h/s coordinates as the first stage loader in the
BIOS.
> ...
> =
> Thanks for your messages...
"That's what we're here for".
-- =
Josef M=F6llers
Fujitsu Siemens Computers
SHV Server DS 1
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: LILO Win+Linux on an old system
Date: Fri, 12 May 2000 08:31:46 +0200
Ooops, "though shalt not follow up on thyself" ...
Josef Moellers wrote:
> >
> > jm> 1. to add the keyword "linear" to your /etc/lilo.conf file?
> >
> > Yes, that didn't help :(.
> =
> I hope the somewhat lengthy explanation above tells you why.
I just _wanted_ to read "Yes, that did help :)."
BTW Did you call "lilo" again after you added the "linear" option? I
sometimes forget ...
> > jm> 2. to add the disk parameters (C/H/S) to the /etc/lilo.conf fil=
e?
> >
> > I haven't done this. I'm not sure how to proceed here. I recall a
> > mention on the docs, I'll take a look for details tonight.
=46rom my example:
disk=3D/dev/hda
bios=3D0x80
sectors=3D63
heads=3D32
As you can see, the number of cylinders is irrelevant B-{). You can
specify them and they can be used for sanity checks. If you don't
specify them, the lilo installer will asume 1024 cylinders.
You may be able to obtain the geometry from the BIOS Setup screens.
Sometimes these are printed somewhere on the disk drive.
-- =
Josef M=F6llers
Fujitsu Siemens Computers
SHV Server DS 1
------------------------------
From: Chetan Ahuja <[EMAIL PROTECTED]>
Subject: Distributed file system
Date: 12 May 2000 07:14:58 GMT
Hi,
Does anybody know of a distributed file system available for
linux. I know about Coda but the application domain seemingly
addressed by coda ( multiple, mobile caching workstations; central
server) is not what I am looking for. What I have in mind is something
which would be suitable for, say, a clustered web server. The data
would probably reside on multiple disks on separate workstations. Any
user level request (say from the httpd) on any one server will be
transparently served, wherever the actual data might be residing. Some
level of redundancy and fault tolerance might be thrown in as bonus.
These are not hard requirements but I know I don't want NFS
(i.e. no single server/lots of clients model). Is Coda suitable for
such a purpose after all? I would be spending a lot of time
implementing such a system so I want to get wiser people's
opinions before I start. I vaguely remember hearing something about a
distributed file system project started specifically for linux
once but don't remember what it was called or even if it's real or
just a dream I had. Is there anything in the design of the newer file
systems coming up for linux ( Reiser, JFS, ext3 etc) which lends them
for distributed operation ( after modifications of course).
Thanks for your time
Chetan
------------------------------
From: bob@p
Subject: Re: tcp window
Date: 12 May 2000 00:36:26 -0700
In article <8fe7pu$ml2$[EMAIL PROTECTED]>, "Christos says...
>
>I used a sniffer to examine the packets of a telnet connection in my PC and
>I noticed that my initial tcp window' s size was 512 bytes. At the next
>packet it went to 32,120. Could anybody give some axplanation ?
>
> Christos
>
probably a bug in sniffer. you are talking about ksniffer, right?
------------------------------
From: Erik Max Francis <[EMAIL PROTECTED]>
Subject: Re: ANSI C & void main()
Date: Fri, 12 May 2000 01:40:19 -0700
Mark Graybill wrote:
> Since my C days during my undergraduate studies were pre-ANSI
> standard, and
> figuring my memory was failing, I checked with the Computer Science
> and
> Engineering department at the University of Minnesota, and found that
> the
> original standard did allow void main().
What in the world are you talking about? What "original standard"?
ANSI C has always required that main return int.
> I doubt the new C standard includes it, ...
What in the world makes you say that?
> ... which is one reason why I didn't pay
> the large fee for obtaining a copy (the other is I don't program in C
> anymore.)
What is that? "I suppose I'm right, so I won't bother verifying it"?
> As far as undefined behavior, which is not defined as behavior not
> advocated
> by ANSI standards but rather behavior not yet observed, the behavior
> of
> using void main() is defined if it is consistently observed in a large
> sample of popular compilers and platforms.
Get a copy of the ANSI C standard, or read the comp.lang.c FAQ.
"Undefined behavior" has a very specific meaning, as defined in such
standards; it means "the compiler may produce code which does anything
it pleases." You can argue that is not the case, and that undefined
behavior is okay if you mean well and know that a few compilers accept
it, but that does not make it any more true.
Did you even read the original thread?
--
Erik Max Francis / [EMAIL PROTECTED] / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ Life imitates art far more than art imitates life.
\__/ Oscar Wilde
Crank Dot Net / http://www.crank.net/
Cranks, crackpots, kooks, & loons on the Net.
------------------------------
From: Anand Krishnamoorthy <[EMAIL PROTECTED]>
Subject: Re: pid vs. thread question
Date: Fri, 12 May 2000 14:52:22 -0400
==============B1B355996298B26400BCA413
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> > As much as I know, in Linux there is a implementation
> > for threads with the clone system call, which is used
> > by the pthread calls!
> >
> I did a "man clone" and found this:
>
> CLONE_PID
> If CLONE_PID is set, the child process
> is created with the same process ID
> as its parent process.
>
> BUGS
> As of version 2.1.97 of the kernel, the CLONE_PID
> flag should not be used, since other parts of the kernel and
> most system software still assume that process IDs are unique.
>
That is true... The concept of two processes having the same PID is
gone... Reference to the do_fork() code for this option would tell you
that...
Is there any other kernel support for threads,
is pthreads really just a posix library magic trick that
makes it look like linux has a kernel supported thread
model?
I believe so... It actually uses the clone system call...
>If threads are implemented as a group of processes
>that share resources, I wonder how it handles
>opening files, or mallocs (if it needs to extend
>memory) getting propogated to all the other
>processes (threads?).
They are. I don't know how they work, precisely, but I would assume
that the processes simply share the same memory mappings and open file
tables and such.
Clone has a flag called CLONE_FILES. Check out man clone for details about
the effect of using this flag.
Another flag to check out is CLONE_VM. This should answer your memory
related query.
Hope this helps..
Anand .K
[EMAIL PROTECTED]
==============B1B355996298B26400BCA413
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<HTML>
<BLOCKQUOTE TYPE=CITE><I>> As much as I know, in Linux there is a implementation</I>
<BR><I>> for threads with the clone system call, which is used</I>
<BR><I>> by the pthread calls!</I>
<BR><I>></I>
<BR><I>I did a "man clone" and found this:</I><I></I>
<P><I>CLONE_PID</I>
<BR><I> If CLONE_PID is set, the child process</I>
<BR><I> is created with the same process ID</I>
<BR><I> as its parent process.</I><I></I>
<P><I>BUGS</I>
<BR><I> As of version 2.1.97 of the kernel, the CLONE_PID</I>
<BR><I> flag should not be used, since other parts of the kernel and</I>
<BR><I> most system software still assume that process IDs are unique.</I>
<BR><I></I> </BLOCKQUOTE>
That is true... The concept of two processes having the same PID
is gone... Reference to the do_fork() code for this option would tell you
that...<I></I>
<P><I>Is there any other kernel support for threads,</I>
<BR><I>is pthreads really just a posix library magic trick that</I>
<BR><I>makes it look like linux has a kernel supported thread</I>
<BR><I>model?</I><I></I>
<P>I believe so... It actually uses the clone system call...
<P><I>>If threads are implemented as a group of processes</I>
<BR><I>>that share resources, I wonder how it handles</I>
<BR><I>>opening files, or mallocs (if it needs to extend</I>
<BR><I>>memory) getting propogated to all the other</I>
<BR><I>>processes (threads?).</I><I></I>
<P><I>They are. I don't know how they work, precisely, but I would assume</I>
<BR><I>that the processes simply share the same memory mappings and open
file</I>
<BR><I>tables and such.</I><I></I>
<P>Clone has a flag called CLONE_FILES. Check out man clone for details
about the effect of using this flag.
<BR>Another flag to check out is CLONE_VM. This should answer your memory
related query.
<P>Hope this helps..
<P>Anand .K
<BR>[EMAIL PROTECTED]</HTML>
==============B1B355996298B26400BCA413==
------------------------------
From: Anand Krishnamoorthy <[EMAIL PROTECTED]>
Subject: Re: where can i find a kernel debugger?
Date: Fri, 12 May 2000 15:03:54 -0400
==============6E7F8B2E8C6ECF507986F680
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> Best and safest way is to use printk for debugging.
Disputable... KDB is pretty good enough....
> Just one thing to
> add: everything you print out gets out on the console, so if you're
> running X, you probably won't see anything (I had the problem myself).
You can actually configure it to send the output to a file... Check out
/etc/syslog.conf
Anand .K
[EMAIL PROTECTED]
==============6E7F8B2E8C6ECF507986F680
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<HTML>
<BLOCKQUOTE TYPE=CITE><I>Best and safest way is to use printk for
debugging.</I></BLOCKQUOTE>
Disputable... KDB is pretty good enough....
<BLOCKQUOTE TYPE=CITE><I>Just one thing to</I>
<BR><I>add: everything you print out gets out on the console, so if you're</I>
<BR><I>running X, you probably won't see anything (I had the problem
myself).</I></BLOCKQUOTE>
You can actually configure it to send the output to a file... Check out
/etc/syslog.conf
<P>Anand .K
<P>[EMAIL PROTECTED]</HTML>
==============6E7F8B2E8C6ECF507986F680==
------------------------------
From: Anand Krishnamoorthy <[EMAIL PROTECTED]>
Subject: Re: How to create memory in ptraced child process w/o child source code
Date: Fri, 12 May 2000 15:20:39 -0400
==============435CD41B759DC1C9733FD060
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I don't think that is ever possible... But one thing that beats me is why you
need such an operation to be performed... If the code in the child process
cannot know that a new page (say) of memory has been allocated to it, how is it
going to be useful to it other than it leaking memory??
Anand .K
[EMAIL PROTECTED]
> I am trying to allocate a new segment of memory for the child process by way
> of the controlling parent process under the ptrace environment. The
> underlying premise is that I do not want to change the child's source code
> (assume source code is not available).
>
> The following peudo code should give an idea of what I want to do.
> main()
> {
> fork()
>
> /* child */
> ptrace(PTRACEME)
> exec() /* execute the real child */
>
> /* parent */
> wait()
> create memory in child's process and write to it.
> ptrace(DETACH)
>
> }
>
> If I can changed the child's source, I can do a shmget() and shmctl().
> However, the child's source code is not available.
>
> Can someone help?
==============435CD41B759DC1C9733FD060
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<HTML>
I don't think that is ever possible... But one thing that beats me is why
you need such an operation to be performed... If the code in the child
process cannot know that a new page (say) of memory has been allocated
to it, how is it going to be useful to it other than it leaking memory??
<P>Anand .K
<P>[EMAIL PROTECTED]
<BR><I></I>
<BLOCKQUOTE TYPE=CITE><I>I am trying to allocate a new segment of memory
for the child process by way</I>
<BR><I>of the controlling parent process under the ptrace environment.
The</I>
<BR><I>underlying premise is that I do not want to change the child's source
code</I>
<BR><I>(assume source code is not available).</I><I></I>
<P><I>The following peudo code should give an idea of what I want to do.</I>
<BR><I>main()</I>
<BR><I>{</I>
<BR><I>fork()</I><I></I>
<P><I>/* child */</I>
<BR><I>ptrace(PTRACEME)</I>
<BR><I>exec() /* execute the real child */</I><I></I>
<P><I>/* parent */</I>
<BR><I>wait()</I>
<BR><I>create memory in child's process and write to it.</I>
<BR><I>ptrace(DETACH)</I><I></I>
<P><I>}</I><I></I>
<P><I>If I can changed the child's source, I can do a shmget() and shmctl().</I>
<BR><I>However, the child's source code is not available.</I><I></I>
<P><I>Can someone help?</I></BLOCKQUOTE>
<I> </I></HTML>
==============435CD41B759DC1C9733FD060==
------------------------------
From: Anand Krishnamoorthy <[EMAIL PROTECTED]>
Subject: Re: Other than console
Date: Fri, 12 May 2000 15:25:00 -0400
==============6412E223728FF2BD9EC4D416
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
prabha wrote:
> Hi All,
> Some commands are not working in terminals other than console on a RH 6.0
> system. I know there is a file to change all these stuff, but don't know
> where it is.
> Can somebody help with this.
>
> -prabha
Like what commands??? Please be more specific...
Anand .K
[EMAIL PROTECTED]
==============6412E223728FF2BD9EC4D416
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<HTML>
<I></I>
<P><I>prabha wrote:</I>
<BLOCKQUOTE TYPE=CITE><I>Hi All,</I>
<BR><I>Some commands are not working in terminals other than console on
a RH 6.0</I>
<BR><I>system. I know there is a file to change all these stuff, but don't
know</I>
<BR><I>where it is.</I>
<BR><I>Can somebody help with this.</I><I></I>
<P><I>-prabha</I></BLOCKQUOTE>
<I> </I>Like what commands??? Please be more specific...
<P>Anand .K
<P>[EMAIL PROTECTED]</HTML>
==============6412E223728FF2BD9EC4D416==
------------------------------
From: Anand Krishnamoorthy <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.setup,comp.os.linux.misc
Subject: Re: Instruction Access Exception
Date: Fri, 12 May 2000 15:28:33 -0400
==============5DDB30176074D7FD305B3E25
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
[EMAIL PROTECTED] wrote:
> Hey all,
>
> I'm trying to recompile the kernel on my SPARCstation 10.
>
> I downloaded the source (2.2.12 and 2.2.14 tried) from tsx-11, make
> config, make dep, make vmlinux, make modules, copied vmlinux to
> /boot/vmlinux-2.2.14 (also moved the System.map), and updated silo.conf
> appropriately.
>
> What fairly obvious step am I missing here? Every time I boot a kernel
> that I have compiled myself, I get "Instruction Access Exception" and get
> kicked back to the boot PROM. I then restart the system with the 'boot'
> command and use the old kernel to get back in.
>
> Ideas?
>
> --J
Did you run 'lilo' after updating the lilo.conf? Try that out if you
haven't..
Anand .K
[EMAIL PROTECTED]
==============5DDB30176074D7FD305B3E25
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<HTML>
<I></I> <I></I>
<P><I>[EMAIL PROTECTED] wrote:</I>
<BLOCKQUOTE TYPE=CITE><I>Hey all,</I><I></I>
<P><I>I'm trying to recompile the kernel on my SPARCstation 10.</I><I></I>
<P><I>I downloaded the source (2.2.12 and 2.2.14 tried) from tsx-11, make</I>
<BR><I>config, make dep, make vmlinux, make modules, copied vmlinux to</I>
<BR><I>/boot/vmlinux-2.2.14 (also moved the System.map), and updated silo.conf</I>
<BR><I>appropriately.</I><I></I>
<P><I>What fairly obvious step am I missing here? Every time I boot
a kernel</I>
<BR><I>that I have compiled myself, I get "Instruction Access Exception"
and get</I>
<BR><I>kicked back to the boot PROM. I then restart the system with
the 'boot'</I>
<BR><I>command and use the old kernel to get back in.</I><I></I>
<P><I>Ideas?</I><I></I>
<P><I>--J</I></BLOCKQUOTE>
<I> </I>Did you run 'lilo' after updating the lilo.conf? Try that
out if you haven't..
<P>Anand .K
<P>[EMAIL PROTECTED]</HTML>
==============5DDB30176074D7FD305B3E25==
------------------------------
** 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
******************************
