boot different kernels on the indy ?!

boot different kernels on the indy ?!

[Andrea Venturi]

i would like to compile and install a kernel from the cvs.sgi.com tree.

i would like not to loose my previous one (the one i get from the woody 
install) as a failsafe option..

i don't understand well i can have multiple kernel booting on the indy..

i believe i should change, in PROM mode, some environment variables.. am 
i wrong?

could someone point me to the right doc?

bye

andrea

Re: boot different kernels on the indy ?!

[Florian Lohoff]

[-- Attachment #1: Type: text/plain, Size: 969 bytes --]

On Tue, Mar 05, 2002 at 03:14:23PM +0100, Andrea Venturi wrote:
> i would like to compile and install a kernel from the cvs.sgi.com tree.
> 
> i would like not to loose my previous one (the one i get from the woody 
> install) as a failsafe option..
> 
> i don't understand well i can have multiple kernel booting on the indy..
> 
> i believe i should change, in PROM mode, some environment variables.. am 
> i wrong?
> 
> could someone point me to the right doc?

There is no doc yet - We have been working on a bootloader which makes
this easier 

Currently you have to put the ecoff kernel image into the volume header.
If you have a large enough volume header just compile your kernel
and put the new one into the volume header under a different name.
The tool to use is "dvhtool"

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
Nine nineth on september the 9th              Welcome to the new billenium

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: boot different kernels on the indy ?!

[Ladislav Michl]

On Wed, 6 Mar 2002, Florian Lohoff wrote:

> There is no doc yet - We have been working on a bootloader which makes
> this easier 
>
> Currently you have to put the ecoff kernel image into the volume header.
> If you have a large enough volume header just compile your kernel
> and put the new one into the volume header under a different name.
> The tool to use is "dvhtool"

boot loader is called arcboot and is well documented - arcboot(8)
atleast unstable contains arcboot-0.3 package.

	ladis

Re: boot different kernels on the indy ?!

[Florian Lohoff]

[-- Attachment #1: Type: text/plain, Size: 480 bytes --]

On Wed, Mar 06, 2002 at 06:24:41AM +0100, Ladislav Michl wrote:
> 
> boot loader is called arcboot and is well documented - arcboot(8)
> atleast unstable contains arcboot-0.3 package.
> 

Which means to switch from kernel-in-vh to arcboot :) Are there kernel
images with ELF kernels already in the archive ?

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
Nine nineth on september the 9th              Welcome to the new billenium

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

unhandled kernel unaligned access

[Sanjay Jain]

hi all,

I am running a kernel test program which makes following call.

getpeername(s, tdat[testno].sockaddr,tdat[testno].salen));

In one particular case tdat[testno].salen is set to 1 which is a unaligned
and invalid addr. It results in following oops.

Unhandled kernel unaligned access in unaligned.c:emulate_load_store_insn,
line
373:
$0 : 00000000 10000024 00000000 00000005
$4 : 10000d20 00000000 10000d20 00000001
$8 : ffffffff 8b179e98 801c6da0 00000003
$12: 00000000 00000002 8b179ecc 8f9875bc
$16: 8b1954c0 00000001 10000d20 00000001
$20: 004014e0 10002e08 00000000 0000000d
$24: 00000001 2ac2db50
$28: 8b178000 8b179e70 7fff7c70 801c6e2c
epc    : 00000000801c58d4
Status : 10009f03
Cause  : 00800010

BadAddr: 0000000000000001Process getpeername01 (pid: 9673,
stackpage=8b178000)
Stack: 8b179ec8 8eedf5a0 8b1954c0 00000001 801c6e2c 801c6dc4 8022370c
8020c788
       8b179ec8 8eedf5a0 00010060 8eedf5a0 00000005 801c5b08 802c2048
8023a65c
       000001d7 00000400 8b179ec8 00000005 000001d7 8eeb7780 5b343731
5d00d538
       8fd2cd80 ffffffea 8eeb7780 00000000 00000000 00000001 00000003
00000003
       7fff7c58 00000002 801c69b8 00406950 00401190 00000001 7fff7d24
00406950
       8b1954c0 ...
Call Trace: [<801c6e2c>] [<801c6dc4>] [<8022370c>] [<8020c788>] [<801c5b08>]
[<
8023a65c>]
 [<801c69b8>] [<8010dce8>]

Code: 04600003  00402821  8ce20000 <00002821> 00403021  10a00004  00a01021
8fb
f0010  03e00008

Is this the expected behavior if an unaligned address is passed in a system
call?

unhandled kernel unaligned access

[Sanjay Jain]

hi all,

I am running a kernel test program which makes following call.

getpeername(s, tdat[testno].sockaddr,tdat[testno].salen));

In one particular case tdat[testno].salen is set to 1 which is a unaligned
and invalid addr. It results in following oops.

Unhandled kernel unaligned access in unaligned.c:emulate_load_store_insn,
line
373:
$0 : 00000000 10000024 00000000 00000005
$4 : 10000d20 00000000 10000d20 00000001
$8 : ffffffff 8b179e98 801c6da0 00000003
$12: 00000000 00000002 8b179ecc 8f9875bc
$16: 8b1954c0 00000001 10000d20 00000001
$20: 004014e0 10002e08 00000000 0000000d
$24: 00000001 2ac2db50
$28: 8b178000 8b179e70 7fff7c70 801c6e2c
epc    : 00000000801c58d4
Status : 10009f03
Cause  : 00800010

BadAddr: 0000000000000001Process getpeername01 (pid: 9673,
stackpage=8b178000)
Stack: 8b179ec8 8eedf5a0 8b1954c0 00000001 801c6e2c 801c6dc4 8022370c
8020c788
       8b179ec8 8eedf5a0 00010060 8eedf5a0 00000005 801c5b08 802c2048
8023a65c
       000001d7 00000400 8b179ec8 00000005 000001d7 8eeb7780 5b343731
5d00d538
       8fd2cd80 ffffffea 8eeb7780 00000000 00000000 00000001 00000003
00000003
       7fff7c58 00000002 801c69b8 00406950 00401190 00000001 7fff7d24
00406950
       8b1954c0 ...
Call Trace: [<801c6e2c>] [<801c6dc4>] [<8022370c>] [<8020c788>] [<801c5b08>]
[<
8023a65c>]
 [<801c69b8>] [<8010dce8>]

Code: 04600003  00402821  8ce20000 <00002821> 00403021  10a00004  00a01021
8fb
f0010  03e00008

Is this the expected behavior if an unaligned address is passed in a system
call?

Re: unhandled kernel unaligned access

[Kevin D. Kissell]

Which sources are you using?  Up until pretty recently,
there was a bug in unaligned.c which could cause this.
I don't know when it was fixed at SGI, but the fix
is in the 2.4.19-pre2 sources at kernel.org.  The problem
was that the epc value in the exception context was
being advanced to the next instruction prior to the
invocation of search_exception_table(regs->cp0_epc).
The 2.4.19-pre2 code solves the problem by re-ordering
the operations and delaying the advancement of epc.
My own quick-and-dirty hack was simply to use the
unmutilated value which is also available to
emulate_load_store_insn(), changing that one line
to be "fixup = search_exception_table(pc)".  That
seems to work.

			Kevin K.

Sanjay Jain wrote:
> 
> hi all,
> 
> I am running a kernel test program which makes following call.
> 
> getpeername(s, tdat[testno].sockaddr,tdat[testno].salen));
> 
> In one particular case tdat[testno].salen is set to 1 which is a unaligned
> and invalid addr. It results in following oops.
> 
> Unhandled kernel unaligned access in unaligned.c:emulate_load_store_insn,
> line
> 373:
> $0 : 00000000 10000024 00000000 00000005
> $4 : 10000d20 00000000 10000d20 00000001
> $8 : ffffffff 8b179e98 801c6da0 00000003
> $12: 00000000 00000002 8b179ecc 8f9875bc
> $16: 8b1954c0 00000001 10000d20 00000001
> $20: 004014e0 10002e08 00000000 0000000d
> $24: 00000001 2ac2db50
> $28: 8b178000 8b179e70 7fff7c70 801c6e2c
> epc    : 00000000801c58d4
> Status : 10009f03
> Cause  : 00800010
> 
> BadAddr: 0000000000000001Process getpeername01 (pid: 9673,
> stackpage=8b178000)
> Stack: 8b179ec8 8eedf5a0 8b1954c0 00000001 801c6e2c 801c6dc4 8022370c
> 8020c788
>        8b179ec8 8eedf5a0 00010060 8eedf5a0 00000005 801c5b08 802c2048
> 8023a65c
>        000001d7 00000400 8b179ec8 00000005 000001d7 8eeb7780 5b343731
> 5d00d538
>        8fd2cd80 ffffffea 8eeb7780 00000000 00000000 00000001 00000003
> 00000003
>        7fff7c58 00000002 801c69b8 00406950 00401190 00000001 7fff7d24
> 00406950
>        8b1954c0 ...
> Call Trace: [<801c6e2c>] [<801c6dc4>] [<8022370c>] [<8020c788>] [<801c5b08>]
> [<
> 8023a65c>]
>  [<801c69b8>] [<8010dce8>]
> 
> Code: 04600003  00402821  8ce20000 <00002821> 00403021  10a00004  00a01021
> 8fb
> f0010  03e00008
> 
> Is this the expected behavior if an unaligned address is passed in a system
> call?

Re: unhandled kernel unaligned access

[Ralf Baechle]

On Wed, Mar 06, 2002 at 11:37:44AM -0800, Kevin D. Kissell wrote:

> Which sources are you using?  Up until pretty recently,
> there was a bug in unaligned.c which could cause this.
> I don't know when it was fixed at SGI, but the fix
> is in the 2.4.19-pre2 sources at kernel.org.

2.4.19-pre2 has most of the oss.sgi.com code as of about a week ago.

  Ralf