There are several solutions out on the 'Net for changing the default block size to 512 bytes. If you followed the above advice for Solaris 2.x, you have already patched the kernel and should have no problems. [MH: For later versions of Solaris a program is provided below.] If you use it on SunOS 4.x, you will need to patch the driver so it can read discs with XAR (see below).
There can also find programs that change the block size. Every time you reboot you will have to run this program before booting:
"Here is the program to set the transfer length to 512 bytes: # include# include # include # include # include # include # include char cdrom[] = "/dev/rsr0"; extern char * cdrom_status(); /* group 0 commands */ #define TEST 0x00 #define REZERO 0x01 #define SENSEREQ 0x03 #define READ 0x08 #define SEEK 0x0b #define NOP 0x0d #define INQ 0x12 #define MODESEL 0x15 #define RESERVE 0x16 #define RELEASE 0x17 #define MODESENSE 0x1a #define STARTSTOP 0x1b #define DIAGRCV 0x1c #define DIAGSND 0x1d #define MEDIUMLOCK 0x1e /* group 1 commands */ #define READCAP 0x25 #define READEXT 0x28 #define SEEKEXT 0x2b /* group 6 commands */ #define AUDIOTRACK 0xc0 #define AUDIOPLAY 0xc1 #define AUDIOSTILL 0xc2 #define AUDIOSTOP 0xc3 #define EJECT 0xc4 #define CLOSE 0xc5 #define AUDIOSUB 0xc6 #define AUDIODISK 0xc7 #define ROMMODE 0xc8 /***/ #define CMDLEN(cmd) ((cmd >= 0x20) ? 10 : 6) /***/ main() { int fd; int i; struct uscsi_cmd ucmd; char * s_command; char * s_buffer; if ((fd = open(cdrom, 0)) == -1) { fprintf(stderr, "open: "); perror(cdrom); exit(1); } s_command = (char *) malloc(10); if (s_command == NULL) { printf("malloc error (command)\n"); exit(-1); } bzero(s_command, 10); s_buffer = (char *) malloc(256); if (s_buffer == NULL) { printf("malloc error (buffer)\n"); exit(-1); } bzero(s_buffer, 256); s_command[0] = MODESEL; s_command[1] = 0x10; s_command[4] = 12; s_buffer[3] = 0x08; s_buffer[10] = 0x02; ucmd.uscsi_cdb = s_command; ucmd.uscsi_cdblen = 6; ucmd.uscsi_bufaddr = s_buffer; ucmd.uscsi_buflen = 4096; ucmd.uscsi_flags = USCSI_WRITE; i = ioctl(fd, USCSICMD, ucmd); close(fd); exit(i); }
Please mail the author of the program with questions. Another user posted the method below for mounting Toshiba XM3401B discs (i.e. it also changes the blocksize). Since I do not have the hardware on hand to check either solution, I will just present the alternatives. Please send me feedback if either one does not work:
"Changing the block size using a user SCSI command with Solaris 1.x: #include#include #include #include struct uscsi_cmd usc; union scsi_cdb cdb; u_char cd_mode[] = { 0, 0, 0, 0x8, 0, 0, 0, 0, 0, 0, 0x2, /* 0x2 = 512, 0x8 = 2k */ 0 }; main() { int cfd; if ((cfd = open("/dev/rsr0", O_RDONLY | O_NDELAY)) < 0) { perror("open"); exit (1); } cdb.cdb_un.cmd = SCMD_MODE_SELECT; cdb.g0_count0 = sizeof(cd_mode); usc.uscsi_cdb = (caddr_t) &cdb; usc.uscsi_cdblen = CDB_GROUP0; usc.uscsi_bufaddr = (caddr_t) cd_mode; usc.uscsi_buflen = sizeof(cd_mode); usc.uscsi_flags = USCSI_DIAGNOSE | USCSI_ISOLATE; if ((ioctl(cfd, USCSICMD, (struct uscsi_cmd *) &usc)) < 0) { perror("USCSICMD ioctl"); exit (1); } exit(0); }"
Under newer versions of Solaris the patch may not work and running the following program during boot before vold runs allows use of 2048 block sized CD-ROMs. This is from Juergen Keil (JK). This program works OK for me, except that it's effects don't seem to hold after power management shutdowns (i.e. when you hit the keyboard power button and the machine goes off, press again and it comes back with a "cprboot" After the cprboot I couldn't use the CD-ROM and had to do a proper reboot. A better solution would be to stop and restart vold.
[JK: Run the following program before you start vold. Unfortunatelly there has to be a cdrom dics inserted into the drive or the program fails.] #include#include #define CDROM "/dev/rdsk/c0t6d0s2" main() { int fd; fd = open(CDROM, O_RDONLY|O_EXCL); if (fd < 0) { perror(CDROM); exit(1); } if (ioctl(fd, CDROMSBLKMODE, 512)) { perror("CDROMSBLKMODE"); exit(1); } return 0; }
I compiled this as "fixcd" with GCC and popped it in /sbin. Then modifed /etc/rc2.d/S92volmgt and added "/sbin/fixcd" under the 'start') clause just before the code that starts vold. This works OK on a normal boot, but apparently not a cprboot. Workaround is not to use power management, or to run:
# /etc/rc2.d/S92volmgt stop; /etc/rc2.d/S92volmgt start
by hand after the machine is up again. Even doing this you will lose programs that were running from the CD-ROM when you hit the power button. In the case of sunsolve this causes it to attempt to core to the CD-ROM. Maybe this should be another question? "I used the vold patch, why does my CD-ROM not work when start my machine with the keyboard power button?" Haven't done this yet, only just discovered it!
13. Why does SunOS 4.1.1 bomb when I try to mount
CD-ROM discs and what can I do about it?
SunOS 4.1.1 has problems with mounting ISO 9660 discs; resultingly, it turns the mount directory into a data file. In the case cited, a user typed
mount -rt hsfs /dev/sr0 /hsfs
and was rewarded with a 202 byte file for /mnt. Here is the solution:
"Again I got a few replies, and the solution in SunOS 4.1.1 is to implement:
Patch-ID# 100217-01 Synopsis: mounting certain iso 9660 cd's succeed but directory becomes data Date: 04/Feb/91 BugID's fixed with this patch:1047295
Another solution is to upgrade to SunOS 4.1.2."
[courtesy thorsen@stc.nato.int (Einar C. Thorsen)]
14. Why can't I mount certain ISO-9660 discs and
what does XAR have to do with it?
The best explanation for this I could find came from Peter Ford at
MIT. He also offers a way around the problem:
"At the raw level, all CD-ROMs appear identical to the reader--they consist of a fixed number of 2048 byte physical blocks (sectors). Under the standard SunOS 4.1.x configuration, you could access any block on the disk by opening /dev/rsr0 and calling lseek() and read(), as does my "cdio" package, see below.
[Note: this is not -exactly- true; a CD-ROM reader uses -logical- blocking; this is what lets a SCSI command (MODE SELECT) be used to switch between 512- and 2048-byte mode on Sony-based drives like the AppleCD -- see explanation above. --ed, original correction courtesy olson@zuni.esd.sgi.com (Dave Olson)]
Higher-level CD-ROM access is performed by software. This is where the disk format matters--the most popular current choices among system- independent formats are "High Sierra" and its international extension: ISO-9660. Other CD-ROMs are written in a machine-dependent format, e.g. as {VMS,Macintosh,UNIX} file systems which are intended to be accessed only by those operating systems.
SunOS 4.1.x contains software that lets you "mount" SunOS, High Sierra, and ISO-9660 disks. For SunOS disks, use the "-t 4.2" option. For the other two formats, use "-t hsfs" (having made sure that the HSFS option was selected in the SunOS system configuration file!) In either case, use the /dev/sr0 device name. Once mounted, you can access the contents as a tree of directories and files. If you are going to export the disk to NFS users, be sure to include the "ro" option in your local /etc/exports file.
One problem should be mentioned in the context of the ISO-9660 format. This ISO standard allows for an "extended attribute record" (XAR) to be associated with each file on the CD-ROM. This is for the convenience of those operating systems, e.g. VMS, that need additional data on file formats (e.g. logical blocking information and record lengths). Current versions of SunOS will refuse to open any file that possesses an XAR. I'm told that this situation will be fixed in the next incremental SunOS release. Meanwhile, I know of two alternatives if you need to read such a disk:
(1) access the disk as a raw device using the PD "cdio" software package available from the anonymous ftp server "space.mit.edu" [18.75.0.10]. The file is "src/cdio.shar". This gives you an interface to the CD-ROM that is similar to "ftp".
(2) get the patch "src/SunOS.4.x.CD-ROM.patch" from the "space.mit.edu" server and apply to your SunOS. It by-passes the XAR checking-code in the SunOS kernel.
The above discussion applies only to the Sun CD-ROM drive and SCSI interface. Some earlier drives couldn't access all possible High Sierra +r ISO-9660 disks because their SCSI interfaces didn't support sub- sector addressing, needed because these disk formats use the concept of a virtual disk block size that can differ from the 2048-byte sector size. "
[courtesy pgf@space.mit.edu (Peter G. Ford)]
Without any special driver, Mr. Clunie managed to get the following to work without any problems:
-mounting and reading HSFS discs -mounting and reading Sun UFS discs -mixing both (note: 2nd access hanges until first unmounted) -booting mini-root off one CD -installing SunOS 4.1.2
The Pioneer has a DIP switch on the back for setting to Sun mode, so these successes are not too surprising. However, in his article he explained how to mount all six discs sequentially without a special driver:
Add the following to your kernel:
disk sr0 at scsibus0 target 6 lun0 #CD-ROM drive disk sr1 at scsibus0 target 6 lun1 #CD-ROM drive disk sr2 at scsibus0 target 6 lun2 #CD-ROM drive disk sr3 at scsibus0 target 6 lun3 #CD-ROM drive disk sr4 at scsibus0 target 6 lun4 #CD-ROM drive disk sr5 at scsibus0 target 6 lun5 #CD-ROM drive Make the following devices in /dev: mknod sr1 b XX 8 mknod sr2 b XX 16 mknod sr3 b XX 24 mknod sr4 b XX 32 mknod sr5 b XX 40 mknod rsr1 c YY 8 mknod rsr2 c YY 16 mknod rsr3 c YY 24 mknod rsr4 c YY 32 mknod rsr5 c YY 40
The devices may already be there ... mine were. "
[courtesy dclunie@sirius.ucs.adelaide.edu.au (David Clunie)]
In short, treat the Pioneer like six different CD-ROM drives; SunOS will not be able to tell the difference so long as you have the right driver for each one and set the lun properly.
16. If I mount a PC-format CD, will SoftPC let DOS
applications access it?
Yes. As far as your DOS applications are concerned, it will look like a regular DOS CD-ROM. Here's how you do it:
as root: $ mkdir /cdrom $ mount -rt hsfs /dev/sr0 /cdrom in DOS: C:\> net use g: /cdrom[courtesy pek@logos.res.utc.com (Paul Kirschner)]
17. If none of this works, is there any other way to access a PC CD-ROM?
One 'Netter pointed out that you don't always need a PC CD-ROM hooked up to your Sun:
"Some folks may be like me - they have a PC clone w/ CD-ROM, and also a Sun workstation (4/110 in my case). I just want to load some CD_ROM- distributed software onto the Sun. I futzed around a few days trying to make the Sun talk SCSI to the CD-ROM with no joy. Then I realized that $60 gets an ethernet board for the PC, and there's enough freeware & shareware around (I'm using Trumpet Winsock & WFTPd) to just FTP the stuff over from a CD-ROM mounted on the PC. The only thing that's not smooth for me is automatically converting the Rock Ridge filenames."
[courtesy harr@netcom.com (Charles (Chuck) Harrison)]
You can also try to use dd to read the information directly:
"Here's a thought: WITHOUT mounting the troublesome CD-ROM (but having it in the drive), do something like:
dd if=/dev/rsr0 of=/tmp/foo count=20 ^ Note the "r"and then do the same using a CD-ROM with which you have no trouble mounting.
Using Emacs (or some binary comparator), determine the differences between the two extracted CD-ROM headers. The ISO-9660 and RockRidge formats are documented at (I believe) cdrom.com for ftp in the pub directory.
The "count=20" may be too much (or too little); read what the specs state."
[courtesy thad@cup.portal.com (Thad P Floryan)]