headers
Johnny Billquist | 1 May 2010 12:31
Picon

Re: Broken GENERIC kernel

George Harvey wrote:
> On Thu, 29 Apr 2010 17:59:15 +0200
> Martin Husemann <martin <at> duskware.de> wrote:
> 
>> On Thu, Apr 29, 2010 at 05:39:11PM +0200, Johnny Billquist wrote:
>>> Woo. I just decided to try the latest release - 5.1_RC1, and it's pretty 
>>> broken on the VAX...
>> Works for me....
> 
> Doesn't work for me :(

Ok. Now have done some hacking on the KA86 code for NetBSD-current, and
have a kernel that seems to work.

I suspect that there is noone else running such a machine, so maybe this
isn't too interesting for others...
However, in doing this, I have also been tearing through the SBI code,
the KA780 and KA750, as well as a little fiddling with the Unibus code.

So if anyone have such a machine running (real or emulated), it would be
nice to talk and test my code to see that those machines also work. Then
I'll be happy to send in my changes so that they can be incorporated in
the official sources again.

Another thing - in the process of this I also discovered that /boot does
not work on the 8650. I don't know how/if it works on other machines.
Anyone who can test a fairly new version and report?

I guess I might look at that next, once I'm done with this part. My
current /boot is from 2006...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rhialto | 2 May 2010 00:08
Picon

newfs seems stuck in loop

I am trying to install a recently updated tree (crosscompiled on amd64)
and chose my "new" 2 GB scsi disk (a HP OEM disk from Seagate). My VAX
is a headless VAXstation 3100 with 32 MB RAM.

When sysinst got to newfs'ing the /home partition, it seemed to do its
work, but then it got into an infinite loop, eating CPU user time.

(all retyped by hand:)

Command: /sbin/newfs -V2 -O 1 -b 16384 -f 2048 /dev/rsd0e

/dev/rsd0e: 1306.6MB (2676004 sectors) block size 16384, fragment size 2048
using 7 cylinder groups of 186.67MB, 11947 blks, 23552 inodes.
..............................................................................
load: 1.08  cmd: newfs 22 [runnable] 2615.23u 3.61s 99% 876k

The system time doesn't seem to increase.

I interrupted it after the time shown. I hoped it had really done its
work, but fsck could not find the superblock. When I retried the command
from the shell, it printed the same, and 7 numbers followed by commas
(those are the superblock numbers, right?) I didn't test if the comma
after number #7 meant it wanted to print another one, which may explain
the loop?

/dev/rsd0e: 1306.6MB (2676004 sectors) block size 16384, fragment size 2048
        using 7 cylinder groups of 186.67MB, 11947 blks, 23552 inodes.
32,
382336,
764640,
(Continue reading)

Permalink | Reply | 15 comments |
headers
Carl Lowenstein | 2 May 2010 09:00
Picon

Re: newfs seems stuck in loop

On Sat, May 1, 2010 at 3:08 PM, Rhialto <rhialto <at> falu.nl> wrote:
> I am trying to install a recently updated tree (crosscompiled on amd64)
> and chose my "new" 2 GB scsi disk (a HP OEM disk from Seagate). My VAX
> is a headless VAXstation 3100 with 32 MB RAM.
>
> When sysinst got to newfs'ing the /home partition, it seemed to do its
> work, but then it got into an infinite loop, eating CPU user time.
>
> (all retyped by hand:)
>
> Command: /sbin/newfs -V2 -O 1 -b 16384 -f 2048 /dev/rsd0e
>
> /dev/rsd0e: 1306.6MB (2676004 sectors) block size 16384, fragment size 2048
> using 7 cylinder groups of 186.67MB, 11947 blks, 23552 inodes.
> ..............................................................................
> load: 1.08  cmd: newfs 22 [runnable] 2615.23u 3.61s 99% 876k
>
> The system time doesn't seem to increase.
>
> I interrupted it after the time shown. I hoped it had really done its
> work, but fsck could not find the superblock. When I retried the command
> from the shell, it printed the same, and 7 numbers followed by commas
> (those are the superblock numbers, right?) I didn't test if the comma
> after number #7 meant it wanted to print another one, which may explain
> the loop?

This is a real hardware VAXstation, right.  Maybe it has a really old
SCSI controller that uses the 6-byte command set and can not address
beyond 1GB.   Or rather disk addresses wrap around so that after 1GB
they over-write the beginning of the disk.
(Continue reading)

Permalink | Reply | 14 comments |
headers
Rhialto | 2 May 2010 11:29
Picon

Re: newfs seems stuck in loop

On Sun 02 May 2010 at 00:00:36 -0700, Carl Lowenstein wrote:
> This is a real hardware VAXstation, right.  Maybe it has a really old
> SCSI controller that uses the 6-byte command set and can not address
> beyond 1GB.   Or rather disk addresses wrap around so that after 1GB
> they over-write the beginning of the disk.

I should have mentioned that there was already another 2 GB disk in the
machine, which I installed with 2.0F or similar vintage, and the
partitioning is very similar, and then I must have been able to newfs
it. I wanted to test a fresh install on the "new" disk.

>     carl
-Olaf.
--

-- 
___ Olaf 'Rhialto' Seibert    -- You author it, and I'll reader it.
\X/ rhialto/at/xs4all.nl      -- Cetero censeo "authored" delendum esse.
Permalink | Reply | 8 comments |
headers
Johnny Billquist | 2 May 2010 12:09
Picon

Re: newfs seems stuck in loop

Carl Lowenstein wrote:
> On Sat, May 1, 2010 at 3:08 PM, Rhialto <rhialto <at> falu.nl> wrote:
>> I am trying to install a recently updated tree (crosscompiled on amd64)
>> and chose my "new" 2 GB scsi disk (a HP OEM disk from Seagate). My VAX
>> is a headless VAXstation 3100 with 32 MB RAM.
>>
>> When sysinst got to newfs'ing the /home partition, it seemed to do its
>> work, but then it got into an infinite loop, eating CPU user time.
>>
>> (all retyped by hand:)
>>
>> Command: /sbin/newfs -V2 -O 1 -b 16384 -f 2048 /dev/rsd0e
>>
>> /dev/rsd0e: 1306.6MB (2676004 sectors) block size 16384, fragment size 2048
>> using 7 cylinder groups of 186.67MB, 11947 blks, 23552 inodes.
>> ..............................................................................
>> load: 1.08  cmd: newfs 22 [runnable] 2615.23u 3.61s 99% 876k
>>
>> The system time doesn't seem to increase.
>>
>> I interrupted it after the time shown. I hoped it had really done its
>> work, but fsck could not find the superblock. When I retried the command
>> from the shell, it printed the same, and 7 numbers followed by commas
>> (those are the superblock numbers, right?) I didn't test if the comma
>> after number #7 meant it wanted to print another one, which may explain
>> the loop?
> 
> This is a real hardware VAXstation, right.  Maybe it has a really old
> SCSI controller that uses the 6-byte command set and can not address
> beyond 1GB.   Or rather disk addresses wrap around so that after 1GB
(Continue reading)

Permalink | Reply | 4 comments |
headers
Johnny Billquist | 2 May 2010 12:13
Picon

Re: newfs seems stuck in loop

Johnny Billquist wrote:
> Carl Lowenstein wrote:
>> On Sat, May 1, 2010 at 3:08 PM, Rhialto <rhialto <at> falu.nl> wrote:
>>> I am trying to install a recently updated tree (crosscompiled on amd64)
>>> and chose my "new" 2 GB scsi disk (a HP OEM disk from Seagate). My VAX
>>> is a headless VAXstation 3100 with 32 MB RAM.
>>>
>>> When sysinst got to newfs'ing the /home partition, it seemed to do its
>>> work, but then it got into an infinite loop, eating CPU user time.
>>>
>>> (all retyped by hand:)
>>>
>>> Command: /sbin/newfs -V2 -O 1 -b 16384 -f 2048 /dev/rsd0e
>>>
>>> /dev/rsd0e: 1306.6MB (2676004 sectors) block size 16384, fragment 
>>> size 2048
>>> using 7 cylinder groups of 186.67MB, 11947 blks, 23552 inodes.
>>> .............................................................................. 
>>>
>>> load: 1.08  cmd: newfs 22 [runnable] 2615.23u 3.61s 99% 876k
>>>
>>> The system time doesn't seem to increase.
>>>
>>> I interrupted it after the time shown. I hoped it had really done its
>>> work, but fsck could not find the superblock. When I retried the command
>>> from the shell, it printed the same, and 7 numbers followed by commas
>>> (those are the superblock numbers, right?) I didn't test if the comma
>>> after number #7 meant it wanted to print another one, which may explain
>>> the loop?
>>
(Continue reading)

Permalink | Reply | 3 comments |
headers
der Mouse | 2 May 2010 13:44

Re: newfs seems stuck in loop

>> The 6-byte limitation of old VAXstations is not a limitation of the
>> controller, but of the firmware in the boot monitor.  [...]
>> Once the OS driver takes over, it can use 8-byte disk block numbers.

Well, it can try.  Depending on how recent the disk is, it may not
recognize 16-byte read and write CDBs (which are the ones with 8 bytes
of block number).

You're probably going to be better off with the 10-byte versions, which
have only 4 bytes of block number ("only" - 32 bits of block number can
address two terabytes of disk).

> And, fyi: If you can make sure that the boot monitor will only access
> data in the first 1G of a disk, you can actually have a disk of any
> size also as the boot disk.  And since Unix partitions the disk, all
> you need to do is make sure that the root partition (partition a) is
> less than 1G, and you are home free.

The boot partition, actually, not necessarily the root partition.
I have some Suns with the same problem (ROM code restricted to 6-byte
CDBs) on which I have a tiny boot partition (a few tens of megs at
most) and use kernels configured with root specifically put somewhere
else.  (I generally mount the boot partition as /kernels and symlink
/netbsd -> kernels/netbsd.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse <at> rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
(Continue reading)

Permalink | Reply | 2 comments |
headers
Rhialto | 2 May 2010 14:03
Picon

Re: newfs seems stuck in loop

On Sun 02 May 2010 at 11:29:21 +0200, Rhialto wrote:
> I should have mentioned that there was already another 2 GB disk in the
> machine, which I installed with 2.0F or similar vintage, and the
> partitioning is very similar, and then I must have been able to newfs
> it. I wanted to test a fresh install on the "new" disk.

I'm trying in SIMH now (V3.8-1, a minor version higher than in pkgsrc,
but the maintainer hasn't updated it despite my mail to remind them)
but it doesn't want to see my 2100MB file as that size; instead it
thinks this:

RQ, address=20001468-2000146B*, no vector, 4 units
  RQ0, 1505MB, attached to netbsd599.dsk, write enabled, RA92
  RQ1, 681MB, attached to vaxcd.iso, read only, read only, RRD40

I'm trying the new command "set -l rq0 rauser=4300800" which I found in
the user manual but it doesn't seem to work. Autosizing seems to work
for RLx disks, but their maximum size is too small.

Anyway, in the emulator, even with the too small disk, newfs has no
problems initializing a partition of about 1300 MB...

-Olaf.
--

-- 
___ Olaf 'Rhialto' Seibert    -- You author it, and I'll reader it.
\X/ rhialto/at/xs4all.nl      -- Cetero censeo "authored" delendum esse.
Permalink | Reply | 7 comments |
headers
Johnny Billquist | 2 May 2010 14:21
Picon

Re: newfs seems stuck in loop

der Mouse wrote:
>>> The 6-byte limitation of old VAXstations is not a limitation of the
>>> controller, but of the firmware in the boot monitor.  [...]
>>> Once the OS driver takes over, it can use 8-byte disk block numbers.
> 
> Well, it can try.  Depending on how recent the disk is, it may not
> recognize 16-byte read and write CDBs (which are the ones with 8 bytes
> of block number).

Well, the point was that once the OS takes over, you are free to use 
whatever sizes you want. The limitation is not in the hardware (well, 
unless you count the disk, which obviously also have to understand what 
you are saying :-) ).

> You're probably going to be better off with the 10-byte versions, which
> have only 4 bytes of block number ("only" - 32 bits of block number can
> address two terabytes of disk).

Right. And actually, I was confusing the size of the request with the 
size of the disk block address (which you probably suspected).

>> And, fyi: If you can make sure that the boot monitor will only access
>> data in the first 1G of a disk, you can actually have a disk of any
>> size also as the boot disk.  And since Unix partitions the disk, all
>> you need to do is make sure that the root partition (partition a) is
>> less than 1G, and you are home free.
> 
> The boot partition, actually, not necessarily the root partition.
> I have some Suns with the same problem (ROM code restricted to 6-byte
> CDBs) on which I have a tiny boot partition (a few tens of megs at
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rhialto | 2 May 2010 15:42
Picon

Re: newfs seems stuck in loop

On Sun 02 May 2010 at 14:03:28 +0200, Rhialto wrote:
> Anyway, in the emulator, even with the too small disk, newfs has no
> problems initializing a partition of about 1300 MB...

Booted from NetBSD 2.0F, I am running its newfs command:

/sbin/newfs -O 1 -b 16384 -f 2048 /dev/rsd0e

it didn't like the "-V2" option, and it prints a different number of
inodes per cylinder group (23424) but the rest of the numbers it shows
are the same. Now too it takes a long time after printing the last
superblock number.

It might be the disk; it makes some rattling sounds now and then, like
it is recalibrating (somewhat similar to the sounds of a Commodore
floppy disk drive, actually). It also gets quite hot. But newfs loops in
user space and no kernel time is used, so it may well be unrelated.

It might also be something else with this hardware; but I'm pretty sure
it once worked since the older 2 GB disk is partitioned similarly, and
actually slightly larger, but I'm not sure with which version it was
originally newfs'ed.

I have a couple of 18 GB disks spare to try, but they have SCA
connectors so I'll have to buy some converter first.

Meanwhile, a full installation in SIMH on a 1505 MB RA92 disk image
completed and appears to run fine:

# dhclient qe0
(Continue reading)

Permalink | Reply | 6 comments |

Gmane