Fwd: next68k: current issues
Andreas Grabher <[email protected]> Tue, 7 Feb 2023 19:35:35 +0100
| Newsgroups | gmane.os.netbsd.ports.next68k |
|---|---|
| Message-ID | <[email protected]> |
--Apple-Mail=_0E0B689A-CCA2-4009-A1F1-CB6A44B2C8FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Mr. Tsutsui, thank you very much for the reply! Glad to see someone is working on = this! > Am 07.02.2023 um 17:09 schrieb Izumi Tsutsui <[email protected] = <mailto:[email protected]>>: >=20 > Hi, >=20 >> I am the maintainer of Previous (NeXT Computer Emulator). >> Mr. Engel might have already introduced me. We are trying >> to make NetBSD boot on emulated NeXT hardware and have run >> into some issues. I hope to have sorted out the problems >> that were inside Previous itself. Some issues left seem to >> be inside NetBSD: >=20 > Thank you for your reports! >=20 > As I wrote on this list before, I've just resurrected my slab > in the last January and notices there are so many regressions. >=20 > I'm still working to fix them and motivated by your info :-) >=20 >> 1. Turbo VRAM:=20 >> Obviously NetBSD uses the same addresses for Turbo NeXTcube >> and NeXTstation as for the non-Turbo ones. In fact the Turbos >> use different locations for their VRAM: 0x0C000000 (same for >> color and monochrome, only sizes vary) >> If I hack Previous to have the VRAM at that location, NetBSD >> boots on all Turbo systems (color and monochrome). >=20 > Ok, fixes for this problem should be trivial. >=20 > However currently framebuffer kernel virtual address regions > are allocated statically (both mono and color) during early startup > in pmap_bootstrap.c: >=20 > = https://github.com/NetBSD/src/blob/338f5e0c6c82c4e90272a48cbcdbcc0e071bc3c= 2/sys/arch/next68k/next68k/pmap_bootstrap.c#L426-L445 >=20 > Maybe we should reorganize them to handle these three cases, > rather than blindly allocate all regions. >=20 > If you could try to compile own kernel, could you check > if a custom kernel work with modifined COLORBASE and COLORTOP > (or MONOBASE and MONOTOP if your emulates NeXT_TURBO_MONO) > work on your emulator? >=20 > --- > diff --git a/sys/arch/next68k/include/cpu.h = b/sys/arch/next68k/include/cpu.h > index 63532eda6e59..8fb61bf54a3e 100644 > --- a/sys/arch/next68k/include/cpu.h > +++ b/sys/arch/next68k/include/cpu.h > @@ -314,8 +314,8 @@ int nmihand(void *); > #define INTIOTOP (0x02120000) > #define MONOBASE (0x0b000000) > #define MONOTOP (0x0b03a800) > -#define COLORBASE (0x2c000000) > -#define COLORTOP (0x2c1D4000) > +#define COLORBASE (0x0c000000) > +#define COLORTOP (0x0c1D4000) >=20 > #define NEXT_INTR_BITS \ > = "\20\40NMI\37PFAIL\36TIMER\35ENETX_DMA\34ENETR_DMA\33SCSI_DMA\32DISK_DMA\3= 1PRINTER_DMA\30SOUND_OUT_DMA\27SOUND_IN_DMA\26SCC_DMA\25DSP_DMA\24M2R_DMA\= 23R2M_DMA\22SCC\21REMOTE\20BUS\17DSP_4\16DISK|C16_VIDEO\15SCSI\14PRINTER\1= 3ENETX\12ENETR\11SOUND_OVRUN\10PHONE\07DSP_3\06VIDEO\05MONITOR\04KYBD_MOUS= E\03POWER\02SOFTINT1\01SOFTINT0" >=20 > --- Unfortunately I have no setup to compile the kernel. But maybe Mr. Engel = can compile it once he has some spare time. Anyway I=E2=80=99m quite = confident that it will work. >=20 >> 2. Incomplete SCSI transfer: >> The SCSI driver in the boot program (bootloader) seems to be >> a bit too restrictive when it comes to transfer length. I >> have the problem, that a shorter than expected inquiry reply >> causes the bootloader to fail. Inquiry message length varies >> between manufacturers and short messages should not cause an >> error. I think this could be fixed easily by setting >> next68k/stand/boot/scsi.c, line 446 from #if 1 to #if 0 >=20 > Hmm, do you see this problem on a real (and old) SCSI disk, > or only on emulator? There was the same issue on NetBSD/x68k > bootloader on the XM6 typeG emulator: > = https://github.com/NetBSD/src/commit/a81affde5b99bf3af0e633c9cdeea5a2b845a= 8ef I do not own any NeXT hardware. But my SCSI disk simulation is based on = the Seagate ST3283N SCSI-2 hard drive from the early 90s. It has a 54 = byte inquiry message. The NeXT ROM and kernel ask for 66 bytes but have = no problem handling the shorter reply. Same for the NetBSD kernel which = also asks for longer messages, just the NetBSD bootloader does not like = it. >=20 > It looks next68k bootloader uses "struct scsipi_inquiry_data" > to receive inquiry data defined in src/sys/dev/scsipi/scsipi_all.h: > = https://github.com/NetBSD/src/blob/338f5e0c6c82c4e90272a48cbcdbcc0e071bc3c= 2/sys/dev/scsipi/scsipi_all.h#L91-L166 >=20 > As commit history says the structure has been extended to 76 bytes > for SCSI3 devices back after NetBSD 1.5 days: > = https://github.com/NetBSD/src/commit/f65d97bb57b56032934aba4f0e615925b6be9= 5f5#diff-ad7fe06963e7b2afbd5e7932c7fe9c06ff0c7122a8a30393ab0ea217920665d2 >=20 > I know this problem could actually happen on old real SCSI1 drives, > but I guess a proper fix is to specify only 36 bytes as SCSI2 inquiry > command on the xfer, as x68k did. >=20 > Could you try the following patch? > (at least this works on a my real SCSI2 drive as before) I=E2=80=99m pretty sure the patch below will fix the problem with = Previous, as it has a 54 byte message. But on the other hand it would be = more secure to handle any (short) length of message. The messages might = vary, especially on old disks. I don=E2=80=99t see the point of treating = this as an error condition. >=20 > --- > diff --git a/sys/arch/next68k/stand/boot/sd.c = b/sys/arch/next68k/stand/boot/sd.c > index 321bbb2d4139..52289d1f42ba 100644 > --- a/sys/arch/next68k/stand/boot/sd.c > +++ b/sys/arch/next68k/stand/boot/sd.c > @@ -98,8 +98,8 @@ sdprobe(char target, char lun) >=20 > memset(&cdb2, 0, sizeof(cdb2)); > cdb2.opcode =3D INQUIRY; > - cdb2.length =3D sizeof(inq); > - count =3D sizeof (inq); > + cdb2.length =3D SCSIPI_INQUIRY_LENGTH_SCSI2; > + count =3D SCSIPI_INQUIRY_LENGTH_SCSI2; > error =3D scsiicmd(target, lun, (u_char *)&cdb2, sizeof(cdb2), > (char *)&inq, &count); > if (error !=3D 0) >=20 > --- >=20 > Note I just noticed yesterday that current next68k bootloader > had a bug that DMA register accesses were not handled properly. >=20 > Maybe you also have to pull the following change: > = http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/next68k/stand/boot/dmareg= .h#rev1.4=20 >=20 >> 3. There seems to be an issue with the structure of SCSI disks >> (might also be a usage problem by me): > : >> This leads to a disk thatcan be mounted and I can write and >> read files. But that disk can't be used for booting, because >> the bootloader is overwritten by newfs. If I swap steps B and >> C I get a disk with broken filesystem, but the bootloader does >> work. Obviously installboot and newfs write to the same location >> and overwrite each others results. >=20 > Yes, I got the same issue and have to prepare some spaces > at the top of the this. >=20 > Then I noticed it was a requirements of the original design: > https://mail-index.netbsd.org/port-next68k/2002/06/06/0003.html >>> You have to install an updated boot loader. The boot blocks are = located at >>> positions 32k and 96k. I believe the one at 32k is usually used but = I've >>> always written both on my disks. The installboot.sh script will = install the >>> boot blocks. You'll need at least 61k of free space at the = beginning of the >>> disk to install one boot block. The default on Nextstep is to leave = 160k >>> free. >=20 > As you noted, we should prepare some proper documents, but > I think it's also worth to have an explicit "BOOT" partition > in the disklabel partition and make the installboot(8) utility > check that the BOOT parition exists and has enough size, > as hp300 does: > = https://github.com/NetBSD/src/blob/338f5e0c6c82c4e90272a48cbcdbcc0e071bc3c= 2/usr.sbin/installboot/arch/hp300.c#L133-L157 The bootloader is not contained on a partition. The first 160 kB (320 = blocks) are reserved for the disk label and bootloader. There are 4 = copies of the label and 2 copies of the bootloader in case there are = faulty blocks. The label already contains correct information about the = bootloader positions (else NeXT ROM wouldn=E2=80=99t load it). But the = first partition overlaps with the bootloader.=20 NeXT=E2=80=99s disktab is useful for understanding the structure of the = disk and the disk label (appended). >=20 > Thanks, > --- > Izumi Tsutsui If I can help with anything that does not require NeXT real hardware or = compiling I=E2=80=99ll do my best. Best wishes, Andreas =EF=BF=BC= --Apple-Mail=_0E0B689A-CCA2-4009-A1F1-CB6A44B2C8FB Content-Type: multipart/mixed; boundary="Apple-Mail=_8450FE95-ADD8-47C2-9A88-B9A817A167CD" --Apple-Mail=_8450FE95-ADD8-47C2-9A88-B9A817A167CD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"content-type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;"><blockquote = style=3D"margin: 0 0 0 40px; border: none; padding: = 0px;"></blockquote>Hello Mr. Tsutsui,<br><br>thank you very much for the = reply! Glad to see someone is working on this!<br><br><blockquote = type=3D"cite" style=3D"color: rgb(0, 0, 0);">Am 07.02.2023 um 17:09 = schrieb Izumi Tsutsui <<a = href=3D"mailto:[email protected]">[email protected]</a>>:<b= r><br>Hi,<br><br><blockquote type=3D"cite">I am the maintainer of = Previous (NeXT Computer Emulator).<br>Mr. Engel might have already = introduced me. We are trying<br>to make NetBSD boot on emulated NeXT = hardware and have run<br>into some issues. I hope to have sorted out the = problems<br>that were inside Previous itself. Some issues left seem = to<br>be inside NetBSD:<br></blockquote><br>Thank you for your = reports!<br><br>As I wrote on this list before, I've just resurrected my = slab<br>in the last January and notices there are so many = regressions.<br><br>I'm still working to fix them and motivated by your = info :-)<br><br><blockquote type=3D"cite">1. Turbo = VRAM: <br>Obviously NetBSD uses the same addresses for Turbo = NeXTcube<br>and NeXTstation as for the non-Turbo ones. In fact the = Turbos<br>use different locations for their VRAM: 0x0C000000 (same = for<br>color and monochrome, only sizes vary)<br>If I hack Previous to = have the VRAM at that location, NetBSD<br>boots on all Turbo systems = (color and monochrome).<br></blockquote><br>Ok, fixes for this problem = should be trivial.<br><br>However currently framebuffer kernel virtual = address regions<br>are allocated statically (both mono and color) during = early startup<br>in pmap_bootstrap.c:<br><br><a = href=3D"https://github.com/NetBSD/src/blob/338f5e0c6c82c4e90272a48cbcdbcc0= e071bc3c2/sys/arch/next68k/next68k/pmap_bootstrap.c#L426-L445">https://git= hub.com/NetBSD/src/blob/338f5e0c6c82c4e90272a48cbcdbcc0e071bc3c2/sys/arch/= next68k/next68k/pmap_bootstrap.c#L426-L445</a><br><br>Maybe we should = reorganize them to handle these three cases,<br>rather than blindly = allocate all regions.<br><br>If you could try to compile own kernel, = could you check<br>if a custom kernel work with modifined COLORBASE and = COLORTOP<br>(or MONOBASE and MONOTOP if your emulates = NeXT_TURBO_MONO)<br>work on your emulator?<br><br>---<br>diff --git = a/sys/arch/next68k/include/cpu.h = b/sys/arch/next68k/include/cpu.h<br>index 63532eda6e59..8fb61bf54a3e = 100644<br>--- a/sys/arch/next68k/include/cpu.h<br>+++ = b/sys/arch/next68k/include/cpu.h<br>@@ -314,8 +314,8 @@ int<span = class=3D"Apple-tab-span" style=3D"white-space: pre;"> = </span>nmihand(void *);<br>#define<span class=3D"Apple-tab-span" = style=3D"white-space: pre;"> </span>INTIOTOP<span = class=3D"Apple-tab-span" style=3D"white-space: pre;"> = </span>(0x02120000)<br>#define MONOBASE<span class=3D"Apple-tab-span" = style=3D"white-space: pre;"> </span>(0x0b000000)<br>#define = MONOTOP<span class=3D"Apple-tab-span" style=3D"white-space: pre;"> = </span><span class=3D"Apple-tab-span" style=3D"white-space: pre;"> = </span>(0x0b03a800)<br>-#define COLORBASE<span class=3D"Apple-tab-span" = style=3D"white-space: pre;"> </span>(0x2c000000)<br>-#define = COLORTOP<span class=3D"Apple-tab-span" style=3D"white-space: pre;"> = </span>(0x2c1D4000)<br>+#define COLORBASE<span class=3D"Apple-tab-span" = style=3D"white-space: pre;"> </span>(0x0c000000)<br>+#define = COLORTOP<span class=3D"Apple-tab-span" style=3D"white-space: pre;"> = </span>(0x0c1D4000)<br><br>#define NEXT_INTR_BITS = \<br>"\20\40NMI\37PFAIL\36TIMER\35ENETX_DMA\34ENETR_DMA\33SCSI_DMA\32DISK_= DMA\31PRINTER_DMA\30SOUND_OUT_DMA\27SOUND_IN_DMA\26SCC_DMA\25DSP_DMA\24M2R= _DMA\23R2M_DMA\22SCC\21REMOTE\20BUS\17DSP_4\16DISK|C16_VIDEO\15SCSI\14PRIN= TER\13ENETX\12ENETR\11SOUND_OVRUN\10PHONE\07DSP_3\06VIDEO\05MONITOR\04KYBD= _MOUSE\03POWER\02SOFTINT1\01SOFTINT0"<br><br>---<br></blockquote><br>Unfor= tunately I have no setup to compile the kernel. But maybe Mr. Engel can = compile it once he has some spare time. Anyway I=E2=80=99m quite = confident that it will work.<br><blockquote type=3D"cite" style=3D"color: = rgb(0, 0, 0);"><br><blockquote type=3D"cite">2. Incomplete SCSI = transfer:<br>The SCSI driver in the boot program (bootloader) seems to = be<br>a bit too restrictive when it comes to transfer length. I<br>have = the problem, that a shorter than expected inquiry reply<br>causes the = bootloader to fail. Inquiry message length varies<br>between = manufacturers and short messages should not cause an<br>error. I think = this could be fixed easily by setting<br>next68k/stand/boot/scsi.c, line = 446 from #if 1 to #if 0<br></blockquote><br>Hmm, do you see this problem = on a real (and old) SCSI disk,<br>or only on emulator? There was = the same issue on NetBSD/x68k<br>bootloader on the XM6 typeG = emulator:<br><a = href=3D"https://github.com/NetBSD/src/commit/a81affde5b99bf3af0e633c9cdeea= 5a2b845a8ef">https://github.com/NetBSD/src/commit/a81affde5b99bf3af0e633c9= cdeea5a2b845a8ef</a><br></blockquote><br>I do not own any NeXT hardware. = But my SCSI disk simulation is based on the Seagate ST3283N SCSI-2 hard = drive from the early 90s. It has a 54 byte inquiry message. The NeXT ROM = and kernel ask for 66 bytes but have no problem handling the shorter = reply. Same for the NetBSD kernel which also asks for longer messages, = just the NetBSD bootloader does not like it.<br><blockquote type=3D"cite" = style=3D"color: rgb(0, 0, 0);"><br>It looks next68k bootloader uses = "struct scsipi_inquiry_data"<br>to receive inquiry data defined in = src/sys/dev/scsipi/scsipi_all.h:<br><a = href=3D"https://github.com/NetBSD/src/blob/338f5e0c6c82c4e90272a48cbcdbcc0= e071bc3c2/sys/dev/scsipi/scsipi_all.h#L91-L166">https://github.com/NetBSD/= src/blob/338f5e0c6c82c4e90272a48cbcdbcc0e071bc3c2/sys/dev/scsipi/scsipi_al= l.h#L91-L166</a><br><br>As commit history says the structure has been = extended to 76 bytes<br>for SCSI3 devices back after NetBSD 1.5 = days:<br><a = href=3D"https://github.com/NetBSD/src/commit/f65d97bb57b56032934aba4f0e615= 925b6be95f5#diff-ad7fe06963e7b2afbd5e7932c7fe9c06ff0c7122a8a30393ab0ea2179= 20665d2">https://github.com/NetBSD/src/commit/f65d97bb57b56032934aba4f0e61= 5925b6be95f5#diff-ad7fe06963e7b2afbd5e7932c7fe9c06ff0c7122a8a30393ab0ea217= 920665d2</a><br><br>I know this problem could actually happen on old = real SCSI1 drives,<br>but I guess a proper fix is to specify only 36 = bytes as SCSI2 inquiry<br>command on the xfer, as x68k did.<br><br>Could = you try the following patch?<br>(at least this works on a my real SCSI2 = drive as before)<br></blockquote><br>I=E2=80=99m pretty sure the patch = below will fix the problem with Previous, as it has a 54 byte message. = But on the other hand it would be more secure to handle any (short) = length of message. The messages might vary, especially on old disks. I = don=E2=80=99t see the point of treating this as an error = condition.<br><blockquote type=3D"cite" style=3D"color: rgb(0, 0, = 0);"><br>---<br>diff --git a/sys/arch/next68k/stand/boot/sd.c = b/sys/arch/next68k/stand/boot/sd.c<br>index 321bbb2d4139..52289d1f42ba = 100644<br>--- a/sys/arch/next68k/stand/boot/sd.c<br>+++ = b/sys/arch/next68k/stand/boot/sd.c<br>@@ -98,8 +98,8 @@ sdprobe(char = target, char lun)<br><br> memset(&cdb2, 0, = sizeof(cdb2));<br> cdb2.opcode =3D INQUIRY;<br>- = cdb2.length =3D sizeof(inq);<br>- = count =3D sizeof (inq);<br>+ = cdb2.length =3D SCSIPI_INQUIRY_LENGTH_SCSI2;<br>+ = count =3D = SCSIPI_INQUIRY_LENGTH_SCSI2;<br> error =3D = scsiicmd(target, lun, (u_char *)&cdb2, sizeof(cdb2),<br><span = class=3D"Apple-tab-span" style=3D"white-space: pre;"> </span><span = class=3D"Apple-tab-span" style=3D"white-space: pre;"> = </span> (char *)&inq, = &count);<br> if (error !=3D = 0)<br><br>---<br><br>Note I just noticed yesterday that current next68k = bootloader<br>had a bug that DMA register accesses were not handled = properly.<br><br>Maybe you also have to pull the following change:<br><a = href=3D"http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/next68k/stand/boo= t/dmareg.h#rev1.4">http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/next68= k/stand/boot/dmareg.h#rev1.4</a> <br><br><blockquote type=3D"cite">3.= There seems to be an issue with the structure of SCSI disks<br>(might = also be a usage problem by me):<br></blockquote>:<br><blockquote = type=3D"cite">This leads to a disk thatcan be mounted and I can write = and<br>read files. But that disk can't be used for booting, = because<br>the bootloader is overwritten by newfs. If I swap steps B = and<br>C I get a disk with broken filesystem, but the bootloader = does<br>work. Obviously installboot and newfs write to the same = location<br>and overwrite each others results.<br></blockquote><br>Yes, = I got the same issue and have to prepare some spaces<br>at the top of = the this.<br><br>Then I noticed it was a requirements of the original = design:<br><a = href=3D"https://mail-index.netbsd.org/port-next68k/2002/06/06/0003.html">h= ttps://mail-index.netbsd.org/port-next68k/2002/06/06/0003.html</a><br><blo= ckquote type=3D"cite"><blockquote type=3D"cite">You have to install an = updated boot loader. The boot blocks are located at<br>positions = 32k and 96k. I believe the one at 32k is usually used but = I've<br>always written both on my disks. The installboot.sh script = will install the<br>boot blocks. You'll need at least 61k of free = space at the beginning of the<br>disk to install one boot block. = The default on Nextstep is to leave = 160k<br>free.<br></blockquote></blockquote><br>As you noted, we should = prepare some proper documents, but<br>I think it's also worth to have an = explicit "BOOT" partition<br>in the disklabel partition and make the = installboot(8) utility<br>check that the BOOT parition exists and has = enough size,<br>as hp300 does:<br><a = href=3D"https://github.com/NetBSD/src/blob/338f5e0c6c82c4e90272a48cbcdbcc0= e071bc3c2/usr.sbin/installboot/arch/hp300.c#L133-L157">https://github.com/= NetBSD/src/blob/338f5e0c6c82c4e90272a48cbcdbcc0e071bc3c2/usr.sbin/installb= oot/arch/hp300.c#L133-L157</a><br></blockquote>The bootloader is not = contained on a partition. The first 160 kB (320 blocks) are reserved for = the disk label and bootloader. There are 4 copies of the label and 2 = copies of the bootloader in case there are faulty blocks. The label = already contains correct information about the bootloader positions = (else NeXT ROM wouldn=E2=80=99t load it). But the first partition = overlaps with the bootloader. <br><br>NeXT=E2=80=99s disktab is = useful for understanding the structure of the disk and the disk label = (appended).<br><blockquote type=3D"cite" style=3D"color: rgb(0, 0, = 0);"><br>Thanks,<br>---<br>Izumi Tsutsui<br></blockquote><br>If I can = help with anything that does not require NeXT real hardware or compiling = I=E2=80=99ll do my best.<br><br>Best = wishes,<br>Andreas<br></body></html>= --Apple-Mail=_8450FE95-ADD8-47C2-9A88-B9A817A167CD Content-Disposition: attachment; filename=disktab.0.9 Content-Type: application/octet-stream; x-unix-mode=0644; name="disktab.0.9" Content-Transfer-Encoding: 7bit # # Copyright (c) 1983,1986 Regents of the University of California. # All rights reserved. The Berkeley software License Agreement # specifies the terms and conditions for redistribution. # # @(#)disktab 4.11 (Berkeley) 5/31/86 # # Disk geometry and partition layout tables. # Key: # ty type of disk # ns #sectors/track -- DEV_BSIZE sectors # nt #tracks/cylinder # nc #cylinders/disk # rm rpm, 3600 default # ss sector size -- MUST ALWAYS BE DEV_BSIZE (1024) FOR NOW # fp # DEV_BSIZE blocks in front porch # bp # DEV_BSIZE blocks in back porch # ng #alternate groups # gs #sectors per alt group # ga #alt sectors per group # ao sector offset to alternates in group # os name of boot file # z[0-1] location of "block 0" boot code in DEV_BSIZE blocks # hn hostname # ro read only root partition (e.g. 'a') # rw read/write partition (e.g. 'b') # p[a-h] partition base in DEV_BSIZE blocks # s[a-h] partition sizes in DEV_BSIZE blocks # b[a-h] partition block sizes in bytes # f[a-h] partition fragment sizes in bytes # c[a-h] partition cylinders-per-group # d[a-h] partition density (bytes-per-inode) # r[a-h] partition minfree # o[a-h] partition optimization ("space" or "time") # i[a-h] partition newfs during init # m[a-h] partition mount point name # a[a-h] partition auto-mount on insert # t[a-h] partition file system type ("4.3BSD", "sound" etc.) # # Entries may also be used for other compatible drives # with the same geometry. # # Internal drives # omd-1|OMD-1|Canon OMD-1:\ :ty=removable_rw_optical:nc#921:nt#17:ns#16:ss#1024:rm#3000:\ :fp#256:bp#256:ng#156:gs#1600:ga#8:ao#784:\ :os=odmach:z0#80:z1#168:ro=a:\ :pa#0:sa#247104:ba#8192:fa#1024:ca#3:da#4096:ra#10:oa=time:\ :ia:ta=4.3BSD:aa: # # SCSI drives # # NOTE: Drives that use "cylinder-oriented sparing" do not have # simple values for sectors and tracks, since not all tracks have # the same number of available sectors. Therefore, the tracks and # sectors in these entries don't match the physical device, but are # chosen so that their product exactly matches the number of USABLE # sectors per cylinder. The slight lie about physical sectors/track # is covered up by tuning the file system rotational latency parameter # appropriately. # # MAXTOR XT-8760S with 1 spare sector/track and 512 byte sectors # # 'b' partition on XT-8760S is intended for NetBoot client private trees # If not supporting NetBoot clients, it may be mounted as desired. XT-8760S-512|MAXTOR XT-8760S-512|Maxtor 760MB w/512 byte sectors:\ :ty=fixed_rw_scsi:nc#1626:nt#15:ns#26:ss#1024:rm#3600:\ :fp#160:bp#0:ng#0:gs#0:ga#0:ao#0:\ :os=sdmach:z0#32:z1#96:ro=a:\ :pa#0:sa#413980:ba#8192:fa#1024:ca#32:da#4096:ra#10:oa=time:\ :ia:ta=4.3BSD:\ :pb#413980:sb#220000:bb#8192:fb#1024:cb#32:db#8192:rb#10:ob=time:\ :ib:tb=4.3BSD: XT-8760S-512-ALL|Maxtor 760MB w/512 byte sectors as 1 partition:\ :ty=fixed_rw_scsi:nc#1626:nt#15:ns#26:ss#1024:rm#3600:\ :fp#160:bp#0:ng#0:gs#0:ga#0:ao#0:\ :os=sdmach:z0#32:z1#96:ro=a:\ :pa#0:sa#633980:ba#8192:fa#1024:ca#32:da#4096:ra#10:oa=time:\ :ia:ta=4.3BSD: # MAXTOR XT-8760S with 4 spare sectors/cyl and 1024 byte sectors # # 'b' partition on XT-8760S is intended for NetBoot client private trees # If not supporting NetBoot clients, it may be mounted as desired. XT-8760S-1024|MAXTOR XT-8760S-1024|Maxtor 760MB w/1024 byte sectors:\ :ty=fixed_rw_scsi:nc#1626:nt#16:ns#26:ss#1024:rm#3600:\ :fp#160:bp#0:ng#0:gs#0:ga#0:ao#0:\ :os=sdmach:z0#32:z1#96:ro=a:\ :pa#0:sa#456256:ba#8192:fa#1024:ca#32:da#4096:ra#10:oa=time:\ :ia:ta=4.3BSD:\ :pb#456256:sb#220000:bb#8192:fb#1024:cb#32:db#8192:rb#10:ob=time:\ :ib:tb=4.3BSD: XT-8760S-1024-ALL|Maxtor 760MB w/1024 byte sectors as 1 partition:\ :ty=fixed_rw_scsi:nc#1626:nt#16:ns#26:ss#1024:rm#3600:\ :fp#160:bp#0:ng#0:gs#0:ga#0:ao#0:\ :os=sdmach:z0#32:z1#96:ro=a:\ :pa#0:sa#676256:ba#8192:fa#1024:ca#32:da#4096:ra#10:oa=time:\ :ia:ta=4.3BSD: # XT-8380S with 5 spare sectors/cyl and 512 byte sectors XT-8380S-512|MAXTOR XT-8380S-512|Maxtor 330MB w/512 byte sectors:\ :ty=fixed_rw_scsi:nc#1626:nt#7:ns#31:ss#1024:rm#3600:\ :fp#160:bp#0:ng#0:gs#0:ga#0:ao#0:\ :os=sdmach:z0#32:z1#96:ro=a:\ :pa#0:sa#346991:ba#8192:fa#1024:ca#32:da#4096:ra#10:oa=time:\ :ia:ta=4.3BSD: # XT-8380S with 4 spare sectors/cyl and 1024 byte sectors XT-8380S-1024|MAXTOR XT-8380S-1024|Maxtor 330MB w/1024 byte sectors:\ :ty=fixed_rw_scsi:nc#1626:nt#10:ns#22:ss#1024:rm#3600:\ :fp#160:bp#0:ng#0:gs#0:ga#0:ao#0:\ :os=sdmach:z0#32:z1#96:ro=a:\ :pa#0:sa#357560:ba#8192:fa#1024:ca#32:da#4096:ra#10:oa=time:\ :ia:ta=4.3BSD: --Apple-Mail=_8450FE95-ADD8-47C2-9A88-B9A817A167CD Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv="content-type" content="text/html; charset=us-ascii"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"></body></html> --Apple-Mail=_8450FE95-ADD8-47C2-9A88-B9A817A167CD-- --Apple-Mail=_0E0B689A-CCA2-4009-A1F1-CB6A44B2C8FB--