Data Access Exception when trying to Boot installed NetBSD of hard drive

Post by Adrian Christiansen

NetBSD/sparc Secondary Boot, Revision 1.15

Booting netbsd
Data Access Exception
ok

How big is your disk or more precise your "a" partition (assuming that is
where /netbsd lives)? A rough estimate is good enough.

Can you boot some install media, mount the disk and show output of

ls -li /

please?

Thanks,

Martin

Adrian Christiansen

2014-10-12 19:12:13 UTC

Hi!,

The root filesystem is 828M, this is the :a partition.

# df -h
Filesystem Size Used Avail %Cap
Mounted on
192.168.1.34:/export/sparky/root 111G 3.8G 99G 3% /
/dev/sd0a 828M 34M 752M 4% /mnt

Output of ls -li:

# ls -li
total 9156
6 -r-xr-xr-x 2 root wheel 1400 Sep 29 2014 .cshrc
7 -r-xr-xr-x 2 root wheel 953 Sep 29 2014 .profile
33600 drwxr-xr-x 2 root wheel 512 Sep 29 2014 altroot
44800 drwxr-xr-x 2 root wheel 1024 Sep 29 2014 bin
4 -r--r--r-- 1 root wheel 66296 Sep 29 2014 boot
134400 drwxr-xr-x 2 root wheel 512 Jan 5 1932 cdrom
67200 drwxr-xr-x 8 root wheel 14848 Jan 5 1932 dev
22400 drwxr-xr-x 26 root wheel 2048 Jan 5 1932 etc
179200 drwxr-xr-x 2 root wheel 512 Jan 5 1932 kern
56000 drwxr-xr-x 2 root wheel 2048 Sep 29 2014 lib
78400 drwxr-xr-x 3 root wheel 512 Sep 29 2014 libdata
190400 drwxr-xr-x 5 root wheel 512 Sep 29 2014 libexec
89600 drwxr-xr-x 2 root wheel 512 Sep 29 2014 mnt
5 -rwxr-xr-x 1 root wheel 4650540 Sep 29 2014 netbsd
123200 drwxr-xr-x 2 root wheel 512 Jan 5 1932 proc
100800 drwxr-xr-x 2 root wheel 3072 Sep 29 2014 rescue
112000 drwxr-xr-x 2 root wheel 512 Jan 5 1932 root
145600 drwxr-xr-x 2 root wheel 3072 Sep 29 2014 sbin
201600 drwxr-xr-x 3 root wheel 512 Sep 29 2014 stand
156800 drwxrwxrwt 2 root wheel 512 Jan 5 1932 tmp
11200 drwxr-xr-x 2 root wheel 512 Jan 5 1932 usr
168000 drwxr-xr-x 23 root wheel 512 Sep 29 2014 var

And just in case it might be needed, and because I wanted to check if
it was the wrong filesystem, the output of disklabel sd0:

# disklabel sd0
# /dev/rsd0c:
type: unknown
disk: ST12550N
label:
flags:
bytes/sector: 512
sectors/track: 79
tracks/cylinder: 19
sectors/cylinder: 1501
cylinders: 2708
total sectors: 4110000
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0 # microseconds
track-to-track seek: 0 # microseconds
drivedata: 0

8 partitions:
# size offset fstype [fsize bsize cpg/sgs]
a: 1748665 0 4.2BSD 1024 8192 0 # (Cyl. 0 - 1164)
b: 262675 1748665 swap # (Cyl. 1165 - 1339)
c: 4110000 0 unused 0 0 # (Cyl. 0 - 2738*)
g: 2098660 2011340 4.2BSD 2048 16384 0 # (Cyl. 1340 - 2738*)

Happy to see NetBSD/sparc users! :)

Post by Adrian Christiansen

NetBSD/sparc Secondary Boot, Revision 1.15

Booting netbsd
Data Access Exception
ok

How big is your disk or more precise your "a" partition (assuming that is
where /netbsd lives)? A rough estimate is good enough.
Can you boot some install media, mount the disk and show output of
ls -li /
please?
Thanks,
Martin

Martin Husemann

2014-10-12 19:16:16 UTC

Post by Adrian Christiansen
# ls -li

[..]

Post by Adrian Christiansen
5 -rwxr-xr-x 1 root wheel 4650540 Sep 29 2014 netbsd

Ok, so not a prom offset limitation.

Just to make sure, could you provide the first few (10 or so) lines of

dumpfs /dev/sd0a

?

Thanks,

Martin

Adrian Christiansen

2014-10-12 19:58:18 UTC

Hi again!,

Sorry, took a bit of time to figure out how to get dumpfs to run from
the install thing. Gave up and just booted a minimal system of the
network.

sparky# dumpfs /dev/sd0a | head -n 15
dumpfs: Cannot open `/etc/fstab': No such file or directory
file system: /dev/sd0a
format FFSv1
endian big-endian
magic 11954 time Fri Feb 10 08:45:48 2068
superblock location 8192 id [ b88a746f 58de565a ]
cylgrp dynamic inodes 4.4BSD sblock FFSv2 fslevel 4
nbfree 101503 ndir 246 nifree 210869 nffree 189
ncg 19 size 874332 blocks 847411
bsize 8192 shift 13 mask 0xffffe000
fsize 1024 shift 10 mask 0xfffffc00
frag 8 shift 3 fsbtodb 1
bpg 5753 fpg 46024 ipg 11200
minfree 5% optim time maxcontig 8 maxbpg 2048
symlinklen 60 contigsumsize 8
maxfilesize 0x0000400801017fff

Hope this is helpful!,

Thanks!,
Adrian.

Post by Adrian Christiansen
# ls -li

[..]

Post by Adrian Christiansen
5 -rwxr-xr-x 1 root wheel 4650540 Sep 29 2014 netbsd

Ok, so not a prom offset limitation.
Just to make sure, could you provide the first few (10 or so) lines of
dumpfs /dev/sd0a
?
Thanks,
Martin

Adrian Christiansen

2014-10-12 20:31:45 UTC

Tested rewriting the bootloader, sadly it made no difference.

sparky# installboot -v /dev/rsd0a /usr/mdec/bootxx /boot
File system: /dev/rsd0a
File system type: ffs (blocksize 8192, needswap 0)
Primary bootstrap: /usr/mdec/bootxx
Secondary bootstrap: /boot
Bootstrap start sector: 1
Bootstrap byte count: 7196
Bootstrap block table: 118 entries of 8192 bytes available, 9 used:
2896 2912 2928 2944 2960 2976 2992 3008 2866
Writing bootstrap

Seemed to exit OK. Same Data Access Exception error on boot.

Post by Adrian Christiansen
Hi again!,
Sorry, took a bit of time to figure out how to get dumpfs to run from
the install thing. Gave up and just booted a minimal system of the
network.
sparky# dumpfs /dev/sd0a | head -n 15
dumpfs: Cannot open `/etc/fstab': No such file or directory
file system: /dev/sd0a
format FFSv1
endian big-endian
magic 11954 time Fri Feb 10 08:45:48 2068
superblock location 8192 id [ b88a746f 58de565a ]
cylgrp dynamic inodes 4.4BSD sblock FFSv2 fslevel 4
nbfree 101503 ndir 246 nifree 210869 nffree 189
ncg 19 size 874332 blocks 847411
bsize 8192 shift 13 mask 0xffffe000
fsize 1024 shift 10 mask 0xfffffc00
frag 8 shift 3 fsbtodb 1
bpg 5753 fpg 46024 ipg 11200
minfree 5% optim time maxcontig 8 maxbpg 2048
symlinklen 60 contigsumsize 8
maxfilesize 0x0000400801017fff
Hope this is helpful!,
Thanks!,
Adrian.

Post by Adrian Christiansen
# ls -li

[..]

Post by Adrian Christiansen
5 -rwxr-xr-x 1 root wheel 4650540 Sep 29 2014 netbsd

Ok, so not a prom offset limitation.
Just to make sure, could you provide the first few (10 or so) lines of
dumpfs /dev/sd0a
?
Thanks,
Martin

Martin Husemann

2014-10-13 07:37:46 UTC

Post by Adrian Christiansen
file system: /dev/sd0a
format FFSv1
endian big-endian
magic 11954 time Fri Feb 10 08:45:48 2068

Thanks, that is all correct - I'm out of ideas.

Martin

Brian Buhrow

2014-10-13 21:23:15 UTC

Hello. I notice the original poster of this question had an IPX with
PROM version V2.3. I think the latest available was V2.9, which was much
more able to boot NetBSD without trouble than earlier versions.

My suggestions are as follows:

1. Ensure the entire / partition is contained within the first 1GB of the
disk.

2. Make sure it's formatted with -O 0 so the prom can read it.

3. Try various releases of NetBSD from NetBSD-5 forward to see if any of
them boot.

Can you show the output of dmesg on a kernel that you did get to boot
on this system?

-thanks
-Brian

On Oct 13, 9:37am, Martin Husemann wrote:
} Subject: Re: Data Access Exception when trying to Boot installed NetBSD of
} On Sun, Oct 12, 2014 at 09:58:18PM +0200, Adrian Christiansen wrote:
} > file system: /dev/sd0a
} > format FFSv1
} > endian big-endian
} > magic 11954 time Fri Feb 10 08:45:48 2068
}
} Thanks, that is all correct - I'm out of ideas.
}
} Martin

-- End of excerpt from Martin Husemann

Mouse

2014-10-13 03:08:45 UTC

Post by Adrian Christiansen
# ls -li
[...]
5 -rwxr-xr-x 1 root wheel 4650540 Sep 29 2014 netbsd

Ok, so not a prom offset limitation.

Still could be. Just because it's inode 5 doesn't mean the data blocks
are also from cg 0 (though admittedly it's likely).

Also, if the relevant partition doesn't begin at/near the beginning of
the drive, even early in the partition could be past the PROM
addressing boundary (if there is one). Some machines insist on boot
partitions beginning at/near the beginning of the disk; others don't; I
forget which are which....

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

John Nemeth

2014-10-13 06:07:25 UTC

On Oct 12, 11:08pm, Mouse wrote:
}
} >> # ls -li
} >> [...]
} >> 5 -rwxr-xr-x 1 root wheel 4650540 Sep 29 2014 netbsd
} > Ok, so not a prom offset limitation.
}
} Still could be. Just because it's inode 5 doesn't mean the data blocks
} are also from cg 0 (though admittedly it's likely).
}
} Also, if the relevant partition doesn't begin at/near the beginning of
} the drive, even early in the partition could be past the PROM
} addressing boundary (if there is one). Some machines insist on boot
} partitions beginning at/near the beginning of the disk; others don't; I
} forget which are which....

Even my Ultra 2, which is much newer then the original poster's
system requires the kernel to be within the first 4GB.

}-- End of excerpt from Mouse

Erik Fair

2014-10-13 14:31:45 UTC

Post by John Nemeth
Even my Ultra 2, which is much newer then the original poster's
system requires the kernel to be within the first 4GB.

The 32-bit SPARCs had a tighter restriction than the 64-bit UltraSPARCs like the Ultra 2 as I recall: within the first 1 or 2 GB; there's an extended SCSI CCB required when the block number gets above one of those (I forget which). Hence the practice of a "small" root partition at the beginning of a system boot disk (of say 64 or 128 MB) to guarantee that a kernel could never be "out of range" for the boot firmware.

That practice also makes FFSv2 (or anything else you like, e.g. LFS, ext2) available for every other filesystem mounted, since only the booting FS has to be FFSv1.

Other recommendation: I've had troubles with booting from "unclean" disks where an old NetBSD or some other OS had been installed, so I'd zero the first megabyte of disk before partitioning+disklabel, newfs, etc., e.g.

dd if=/dev/zero of=/dev/rsd0c bs=1m count=1

Be careful specifying that disk drive device file if you do it on another NetBSD system where you're prepping the disk for installation.

Erik <***@netbsd.org>

Mouse

2014-10-13 14:53:55 UTC

Post by John Nemeth

Some machines insist on boot partitions beginning at/near the
beginning of the disk; others don't; I forget which are which....

Even my Ultra 2, which is much newer then the original poster's
system requires the kernel to be within the first 4GB.

"Newer" is not quite as relevant as you seem to think. Even among
sparc32 machines, I've never found anything else (like "designed before
$DATE") that reliably indicates whether "has the 1G boot partition
limit" applies.

And it is 1G; the issue is the use of 6-byte SCSI CDBs, which have only
21 bits of sector address and thus can address only the first gig. If
you have a machine with a 4G boot partition limit, the issue behind it
is something else - most likely, I'd guess, the use of 32-bit byte
offsets somewhere in the relevant code paths. (There is a similar
issue with 10-byte CDBs, but that limit is much higher. If I'm reading
an include file correctly, they have 32 bits of address, for a 2T
limit. There's a similar limit for IDE at 128G, IIRC, but I don't
recall details; if it's a similar addressing limit, it would be 28 bits
of address, which seems possible but unlikely.)

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Adrian Christiansen

2014-10-13 15:54:42 UTC

Hi guys!

After reading your comments I made the assumption that I messed
something up, after all I did alter the size of the :a partition. So I
installed NetBSD again onto another hard drive, using the suggested :a
partition. Sadly I can only report that I got the same error as before
when trying to boot NetBSD.

Output from OpenBoot:

Can't open input device.
SPARCstation IPX, No Keyboard
ROM Rev. 2.3, 64 MB memory installed, Serial #12648430.
Ethernet address 8:0:20:c0:ff:ee, Host ID: 57c0ffee.

Rebooting with command:
Boot device: diskhelp File and args:
Can't open boot device
Type help for more information
ok probe-scsi
Target 0
Unit 0 Disk COMPAQ ST12550N 322300425332Copyright (c)
1994 Seagate All rights reserved 0000
Target 1
Unit 0 Disk SEAGATE ST32550N SUN2.1G041200464792Copyright (c)
1995 Seagate All rights reserved ASA2
ok boot disk1:a netbsd

NetBSD/sparc Secondary Boot, Revision 1.15

Booting netbsd
Data Access Exception
ok

I tried to find some backtrace debugging tools in the OpenBoot 2.x
manual and saw there was ftrace. I don't know if ftrace is of any
help, but just in case here's the output of ftrace after the Data
Access Exception.

ok ftrace
@ Called from (ffea5d84) at ffea5dae
my-voc Called from $call-self at ffea714a
$call-self Called from $call-method at ffea71e0
ffefb8a0
$call-method Called from seek at ffebc7fa
execute Called from $vexecute? at ffea62a4
$vexecute? Called from $call-self at ffea714e
$call-self Called from $call-method at ffea71e0
0
execute Called from catch at ffe9c3f2
ffefefd4
0
ffefebbc
catch Called from op-seek at ffea78f6
op-seek Called from op-seek at ffea7958
0
(fload) Called from interact at ffe9eaac
execute Called from catch at ffe9c3f2
ffefefec
0
ffefebd4
catch Called from (quit at ffe9ead0

I had a look at the ram inside the machine.

The banks are organized as follows:
Bank 3: 16384K - CPSM33A S16 80
Bank 2: 16384K - CPSM33A S16 80
Bank 1: 16384K - CPSM33A S16 80
Bank 0: 16MB Mitsubishi memory, 80 ns. MH4M09AJ-8 chips, 33 of them.

Tried placing the odd Mitsubishi memory at Bank 3. This didn't help either.

So I'm still stuck :(

Some machines insist on boot partitions beginning at/near the
beginning of the disk; others don't; I forget which are which....

Even my Ultra 2, which is much newer then the original poster's
system requires the kernel to be within the first 4GB.

"Newer" is not quite as relevant as you seem to think. Even among
sparc32 machines, I've never found anything else (like "designed before
$DATE") that reliably indicates whether "has the 1G boot partition
limit" applies.
And it is 1G; the issue is the use of 6-byte SCSI CDBs, which have only
21 bits of sector address and thus can address only the first gig. If
you have a machine with a 4G boot partition limit, the issue behind it
is something else - most likely, I'd guess, the use of 32-bit byte
offsets somewhere in the relevant code paths. (There is a similar
issue with 10-byte CDBs, but that limit is much higher. If I'm reading
an include file correctly, they have 32 bits of address, for a 2T
limit. There's a similar limit for IDE at 128G, IIRC, but I don't
recall details; if it's a similar addressing limit, it would be 28 bits
of address, which seems possible but unlikely.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Eduardo Horvath

2014-10-13 16:20:40 UTC

Post by Adrian Christiansen
I tried to find some backtrace debugging tools in the OpenBoot 2.x
manual and saw there was ftrace. I don't know if ftrace is of any
help, but just in case here's the output of ftrace after the Data
Access Exception.

`ftrace' is for tracing Forth code. AFAIK the NetBSD/sparc bootloader is
C code so you want to use `ctrace'.

Post by Adrian Christiansen
ok ftrace

Here we have a load operation. Dunno what address it's trying to load,
that would be on the Forth stack. You can access that (if it hasn't been
reset) with `.s'.

Post by Adrian Christiansen
@ Called from (ffea5d84) at ffea5dae

The rest of it looks to be calling `seek' on some device.

Post by Adrian Christiansen
my-voc Called from $call-self at ffea714a
$call-self Called from $call-method at ffea71e0
ffefb8a0
$call-method Called from seek at ffebc7fa
execute Called from $vexecute? at ffea62a4
$vexecute? Called from $call-self at ffea714e
$call-self Called from $call-method at ffea71e0
0
execute Called from catch at ffe9c3f2
ffefefd4
0
ffefebbc
catch Called from op-seek at ffea78f6
op-seek Called from op-seek at ffea7958
0

Here we have the call to load the bootblock. It was called from the
command interpreter (`interact').

Post by Adrian Christiansen
(fload) Called from interact at ffe9eaac
execute Called from catch at ffe9c3f2
ffefefec
0
ffefebd4
catch Called from (quit at ffe9ead0

Eduardo

Adrian Christiansen

2014-10-13 16:50:57 UTC

Hi Eduardo!

I see, thought this would be the case too.

Here's the output of those two if it would help anyone:

ok .s
Empty

ok ctrace
PC: ffe9a430
Last leaf: call ffe9985c from ffea5da4
0 w %o0-%o5: ( 1 38786f 1 ffd40000 ffefffbf ffe8ef04 )

jmpl ffea794c from 388e7c
1 w %o0-%o5: ( ffefb8a0 0 2000 ffd40000 ff 66 )

jmpl ffea794c from 388180
2 w %o0-%o5: ( 0 0 2000 0 0 0 )

jmpl ffea794c from 38d1c4
3 w %o0-%o5: ( 398c60 1 0 10 2000 398e50 )

jmpl ffea794c from 391924
4 w %o0-%o5: ( 387ee8 398bd8 398400 387df4 387e44 0 )

call 391818 from 39113c
5 w %o0-%o5: ( 387ee8 1 387ecc 1f fff7fffc ffea6fd8 )

call 391134 from 38a898
6 w %o0-%o5: ( 387ee8 0 396dc8 ffffddbb ffeffd7f 0 )

call 38a4f0 from 38811c
7 w %o0-%o5: ( 3960f0 396120 396178 384000 2000 ffffc000 )

jmpl ffea794c from 300c40
8 w %o0-%o5: ( ffe8f3c8 388000 2fff9c ffd40000 ffefffbf ffe8ef04 )

call 300b64 from 30011c
9 w %o0-%o5: ( ffe8f3c8 301c00 0 ffd40000 ff fffffff )

XXXXXXX from 0
a w %o0-%o5: ( ffe8f3c8 300000 0 0 0 0 )

That looks even less helpful, is there a way to find some declarations
or labels for those addresses?

Post by Eduardo Horvath

`ftrace' is for tracing Forth code. AFAIK the NetBSD/sparc bootloader is
C code so you want to use `ctrace'.

Post by Adrian Christiansen
ok ftrace

Here we have a load operation. Dunno what address it's trying to load,
that would be on the Forth stack. You can access that (if it hasn't been
reset) with `.s'.

Post by Adrian Christiansen
@ Called from (ffea5d84) at ffea5dae

The rest of it looks to be calling `seek' on some device.

Here we have the call to load the bootblock. It was called from the
command interpreter (`interact').

Post by Adrian Christiansen
(fload) Called from interact at ffe9eaac
execute Called from catch at ffe9c3f2
ffefefec
0
ffefebd4
catch Called from (quit at ffe9ead0

Eduardo

Eduardo Horvath

2014-10-13 22:35:29 UTC

Post by Adrian Christiansen
Hi Eduardo!
I see, thought this would be the case too.
ok .s
Empty
ok ctrace
PC: ffe9a430
Last leaf: call ffe9985c from ffea5da4
0 w %o0-%o5: ( 1 38786f 1 ffd40000 ffefffbf ffe8ef04 )
jmpl ffea794c from 388e7c
1 w %o0-%o5: ( ffefb8a0 0 2000 ffd40000 ff 66 )
jmpl ffea794c from 388180
2 w %o0-%o5: ( 0 0 2000 0 0 0 )
jmpl ffea794c from 38d1c4
3 w %o0-%o5: ( 398c60 1 0 10 2000 398e50 )
jmpl ffea794c from 391924
4 w %o0-%o5: ( 387ee8 398bd8 398400 387df4 387e44 0 )
call 391818 from 39113c
5 w %o0-%o5: ( 387ee8 1 387ecc 1f fff7fffc ffea6fd8 )
call 391134 from 38a898
6 w %o0-%o5: ( 387ee8 0 396dc8 ffffddbb ffeffd7f 0 )
call 38a4f0 from 38811c
7 w %o0-%o5: ( 3960f0 396120 396178 384000 2000 ffffc000 )
jmpl ffea794c from 300c40
8 w %o0-%o5: ( ffe8f3c8 388000 2fff9c ffd40000 ffefffbf ffe8ef04 )
call 300b64 from 30011c
9 w %o0-%o5: ( ffe8f3c8 301c00 0 ffd40000 ff fffffff )
XXXXXXX from 0
a w %o0-%o5: ( ffe8f3c8 300000 0 0 0 0 )
That looks even less helpful, is there a way to find some declarations
or labels for those addresses?

What you need to do is run objdump or gcc on the two bootloader binaries
to get the code and data addresses. Then just correlate them with the
values from the stack.

Assuming the firmware is dumping the correct values, the first value you
see is the instruction being used, either call or jump and link, followed
by the branch destination, and I think the next field is the address of
the calling instruction itself. You also have the first 5 function
parameters.

OBP resides at address 0xff000000. The stuff at 0x380000 and 0x300000 are
probably the bootloaders.

OBP 3.x has mechanisms to load symbols, something I'm not sure 2.x
supports.

(Another option would be to see if the sparc64 FCode bootblock can be made
to run on OBP 2.x. That's capable of walking the filesystem in 7.5KB,
instead of having a list of absolute disk blocks to read.)

Eduardo

Dan Oglesby

2014-10-13 16:25:11 UTC

I don't know if this can help or not, but the latest BootROM version might help with odd issues at boot. I know I had to update some of my older sun4c hardware to get them to work decently with CD-ROM installations on newer versions of NetBSD.

I believe 2.9 is the latest version for the IPX, you indicated you had 2.3. If you have the ability to update the BootROM, it might help.

--Dan

----- Original Message -----
From: "Adrian Christiansen" <***@gmail.com>
To: "port-sparc" <port-***@netbsd.org>
Sent: Monday, October 13, 2014 10:54:42 AM
Subject: Re: Data Access Exception when trying to Boot installed NetBSD of hard drive

Hi guys!

After reading your comments I made the assumption that I messed
something up, after all I did alter the size of the :a partition. So I
installed NetBSD again onto another hard drive, using the suggested :a
partition. Sadly I can only report that I got the same error as before
when trying to boot NetBSD.

Output from OpenBoot:

Can't open input device.
SPARCstation IPX, No Keyboard
ROM Rev. 2.3, 64 MB memory installed, Serial #12648430.
Ethernet address 8:0:20:c0:ff:ee, Host ID: 57c0ffee.

Rebooting with command:
Boot device: diskhelp File and args:
Can't open boot device
Type help for more information
ok probe-scsi
Target 0
Unit 0 Disk COMPAQ ST12550N 322300425332Copyright (c)
1994 Seagate All rights reserved 0000
Target 1
Unit 0 Disk SEAGATE ST32550N SUN2.1G041200464792Copyright (c)
1995 Seagate All rights reserved ASA2
ok boot disk1:a netbsd

NetBSD/sparc Secondary Boot, Revision 1.15

Some machines insist on boot partitions beginning at/near the
beginning of the disk; others don't; I forget which are which....

Even my Ultra 2, which is much newer then the original poster's
system requires the kernel to be within the first 4GB.

"Newer" is not quite as relevant as you seem to think. Even among
sparc32 machines, I've never found anything else (like "designed before
$DATE") that reliably indicates whether "has the 1G boot partition
limit" applies.
And it is 1G; the issue is the use of 6-byte SCSI CDBs, which have only
21 bits of sector address and thus can address only the first gig. If
you have a machine with a 4G boot partition limit, the issue behind it
is something else - most likely, I'd guess, the use of 32-bit byte
offsets somewhere in the relevant code paths. (There is a similar
issue with 10-byte CDBs, but that limit is much higher. If I'm reading
an include file correctly, they have 32 bits of address, for a 2T
limit. There's a similar limit for IDE at 128G, IIRC, but I don't
recall details; if it's a similar addressing limit, it would be 28 bits
of address, which seems possible but unlikely.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Izumi Tsutsui

2014-10-12 23:42:39 UTC

Post by Adrian Christiansen
ok boot disk3:a netbsd

NetBSD/sparc Secondary Boot, Revision 1.15

Booting netbsd
Data Access Exception
ok

This reminds PR/42186:
http://gnats.netbsd.org/42186
and IIRC there was the similar report
on SS2 (or other sun4c machines) in this list.

On my SS1+, it only occured on floppy boot,
but I wonder we should put some proper
"close" function after raid check...

---
Izumi Tsutsui

Georg Brein

2014-10-13 17:18:09 UTC

I had the same (or similar) problem back in 2007 on
my SparcStation 2 (ROM Rev. 2.2) while installing NetBSD
4.0 RC1 (see NetBSD bug report #37080):

The second stage boot loader from 4.0 RC1 failed
with a Data Access Exception. As a quick fix I
substituted the second stage boot loader from NetBSD
3.1 which worked flawlessly with the 4.0 RC1
installation.

The proper fix (which took a little longer to implement
since I had to acquire an EPROM burner) was to upgrade
to ROM Rev. 2.9 (AFAIK the latest for the SparcStation 2)
which allowed the 4.0 RC1 (and later) second stage
boot loaders to function.

Of course this is old history; I don't know if the
3.1 boot loader quick fix is still feasible with a
current NetBSD release, but it seems likely, since
the current boot loader still has the same version (1.15)
as the 4.0 RC1 boot loader back in 2007 which
indicates little change in this area of NetBSD (incidentally,
the boot loader for NetBSD 3.1 has version 1.15 as well; I
guess there was either a change in some included/linked
code or in the compiler used between NetBSD 3.1 and
NetBSD 4.0 RC1 leading to different binaries from the
same source code).

The latest ROM revision for the IPX seems to be 2.9
as well (but unfortunately I don't know where to get
the relevant IPX specific ROM image).

Regards,
Georg Brein

Post by Adrian Christiansen
Hi guys!,
I'm relatively new to SUN machines and I just finished installing
NetBSD onto my SPARCstation IPX. Followed the instructions in
INSTALL.html and netbooted the install. Then I just followed the
installation thru, using the entire disk and making a root partition
at a: in the disklabel.
ok boot disk3:a netbsd

NetBSD/sparc Secondary Boot, Revision 1.15

Booting netbsd
Data Access Exception
ok
There's a / spiny thing for a brief moment, the ROM revision is 2.3.
Honestly I don't really know where to go from here?

Adrian Christiansen

2014-10-13 18:48:11 UTC

Hi Georg!

I don't know if I should be happy or sad, but this actually got the
system to boot. I used boot from 3.1 and the bootxx from 6.1.5. So
there's my problem, I need a new BootROM I guess... or boot should be
fixed?

Thanks!,
Adrian.

Post by Georg Brein
I had the same (or similar) problem back in 2007 on
my SparcStation 2 (ROM Rev. 2.2) while installing NetBSD
The second stage boot loader from 4.0 RC1 failed
with a Data Access Exception. As a quick fix I
substituted the second stage boot loader from NetBSD
3.1 which worked flawlessly with the 4.0 RC1
installation.
The proper fix (which took a little longer to implement
since I had to acquire an EPROM burner) was to upgrade
to ROM Rev. 2.9 (AFAIK the latest for the SparcStation 2)
which allowed the 4.0 RC1 (and later) second stage
boot loaders to function.
Of course this is old history; I don't know if the
3.1 boot loader quick fix is still feasible with a
current NetBSD release, but it seems likely, since
the current boot loader still has the same version (1.15)
as the 4.0 RC1 boot loader back in 2007 which
indicates little change in this area of NetBSD (incidentally,
the boot loader for NetBSD 3.1 has version 1.15 as well; I
guess there was either a change in some included/linked
code or in the compiler used between NetBSD 3.1 and
NetBSD 4.0 RC1 leading to different binaries from the
same source code).
The latest ROM revision for the IPX seems to be 2.9
as well (but unfortunately I don't know where to get
the relevant IPX specific ROM image).
Regards,
Georg Brein

NetBSD/sparc Secondary Boot, Revision 1.15

Booting netbsd
Data Access Exception
ok
There's a / spiny thing for a brief moment, the ROM revision is 2.3.
Honestly I don't really know where to go from here?

Adrian Christiansen

2014-10-13 19:02:31 UTC

Hello again,

I attached the dmesg if anyone is interested. This is from the system
booting NetBSD/sparc verion 6.1.5
of the external SCSI drive, using the NetBSD 3.1 /boot secondary
bootloader, and NetBSD 6.1.5 bootxx primary bootloader.

Post by Adrian Christiansen
Hi Georg!
I don't know if I should be happy or sad, but this actually got the
system to boot. I used boot from 3.1 and the bootxx from 6.1.5. So
there's my problem, I need a new BootROM I guess... or boot should be
fixed?
Thanks!,
Adrian.

NetBSD/sparc Secondary Boot, Revision 1.15

Booting netbsd
Data Access Exception
ok
There's a / spiny thing for a brief moment, the ROM revision is 2.3.
Honestly I don't really know where to go from here?

Martin Husemann

2014-10-13 19:41:33 UTC

Post by Adrian Christiansen
there's my problem, I need a new BootROM I guess... or boot should be
fixed?

Depends on what is triggering it. If you can easily recover from a broken
boot, you could try to bisect the relevant change (I think mrg already
offered to create all relevante /boot versions, but he is traveling,
so this might take some time before he chimes in).

Once we know which revision broke it, we can see wethere there is a good
workaround or we are hitting a bug in the boot rom.

Martin

Adrian Christiansen

2014-10-13 19:47:25 UTC

Hm, that might a good idea actually. Could feed the second install
with weird /boots and see when it breaks. I saw the comment in PR
#37080 about trying to find the CVS commit that broke it, so I hope
for the best :)

Even if it's a fail in one way and a success in another, it's awesome
to see so many SPARC users!

Thanks guys!

Post by Adrian Christiansen
there's my problem, I need a new BootROM I guess... or boot should be
fixed?

Depends on what is triggering it. If you can easily recover from a broken
boot, you could try to bisect the relevant change (I think mrg already
offered to create all relevante /boot versions, but he is traveling,
so this might take some time before he chimes in).
Once we know which revision broke it, we can see wethere there is a good
workaround or we are hitting a bug in the boot rom.
Martin

matthew green

2014-10-13 21:09:55 UTC

Post by Adrian Christiansen
there's my problem, I need a new BootROM I guess... or boot should be
fixed?

Depends on what is triggering it. If you can easily recover from a broken
boot, you could try to bisect the relevant change (I think mrg already
offered to create all relevante /boot versions, but he is traveling,
so this might take some time before he chimes in).
Once we know which revision broke it, we can see wethere there is a good
workaround or we are hitting a bug in the boot rom.

oh... i will boot my box into netbsd-4 world for this experiment
shortly.

.mrg.

Georg Brein

2014-10-13 20:15:29 UTC