home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / linux / 21868 < prev    next >
Encoding:
Internet Message Format  |  1992-12-28  |  3.2 KB
  1. Path: sparky!uunet!optilink!brad
  2. From: brad@optilink.COM (Brad Yearwood)
  3. Newsgroups: comp.os.linux
  4. Subject: Toshiba 3301 CD-ROM drives (Sun CD drive, too)
  5. Message-ID: <13720@optilink.COM>
  6. Date: 28 Dec 92 04:43:53 GMT
  7. References: <1992Dec27.053434.5519@netcom.com>
  8. Organization: Optilink Corporation, Petaluma, CA
  9. Lines: 62
  10.  
  11. In article <1992Dec27.053434.5519@netcom.com>, qualtrak@netcom.com (Qual Trak) writes:
  12. > 
  13. > Everything seems to be working fine ( I did have to get the ps sources
  14. > and compile them) except I can't talk to my CD-ROM (Toshiba XM-3301TA
  15. > Rev:  0272.
  16.  
  17. People have complained recently that Toshiba 3301 CD-ROM drives don't
  18. seem to work.  Under 0.99.1, I have been trying to use a Future Domain
  19. TMC-1660 SCSI controller with each of two types of CD-ROM drives:
  20.  
  21.   Sun Microsystems P/N 595-1929-04, claims on probe to be a Sony CDU-8012
  22.  
  23.   Toshiba TXM3301E1, purchased for use with a Sun, claims on probe to
  24.     be XM-3301TA, firmware revision 0272
  25.  
  26. A NEC CDR-73 works perfectly.  An old Texel DM-3020 (not a current model,
  27. and this particular one has been through a power supply failure, so it may
  28. be damaged) often mounts a 9660 filesystem OK, but shows some frequency of
  29. various SCSI complaints.
  30.  
  31. I try the following on the Sun and Toshiba drives:
  32.  
  33. mount -r -t /dev/scd0 /cdrom
  34.  
  35. I get a kernel panic complaining that "a multi-volume CD somehow got mounted".
  36. I did some experiments with hex dump code inside isofs/inode.c, and with
  37. using "dd if=/dev/scd0 of=/tmp/foo bs=2048 count=100" to see what would happen
  38. when I attempted to read the CD-ROM sequentially.  The results lead me to the
  39. following conclusion.
  40.  
  41. These two drives are apparently jimmied in firmware to emulate 512-byte
  42. sector sizes.  This is very handy in making them look more like normal
  43. SCSI disks, but it is not very handy in making them look like the usual
  44. 2048-byte sector CD-ROMs.  Perhaps some special SCSI command is available
  45. to put one or the other into a 2048-byte mode, but I have no detailed
  46. documentation.
  47.  
  48. As a test, I put some rude hacks into kernel/blk_dev/scsi/sr.c to try to
  49. undo a lot of what it does: re-blocking 512-byte requests from the block
  50. I/O system into 2048-byte requests to the drive.
  51.  
  52. When I do this, both drives appear to work.  Performance on the Sun drive
  53. is abysmal (perhaps due at least in part to the fact that I tried to
  54. simplify the rude hacks some by cutting out scatter/gather support), but
  55. performance on the Toshiba seems OK.
  56.  
  57. The changes are almost entirely untested, and as the holidays are ending,
  58. I need to return various CD-ROM drives to the systems I swiped them
  59. from (actually, I need to return the entire 486 machine to the group I swiped
  60. it from), so it is not feasible for me to put in any responsible amount
  61. of testing.  If you send a note promising that you won't use or pass
  62. them around as tested, working, or smoothly integrated code, I'll email
  63. a copy of the diffs (against a baseline of 0.99.1).
  64.  
  65. Because this Toshiba drive was purchased for use with Sun systems, there
  66. is some chance that it is a special configuration which emulates 512-byte
  67. sectors, and that the problems which people have reported with other Toshiba
  68. 3301 drives might have a different cause.
  69.  
  70. Brad Yearwood   brad@optilink.com   {uunet, pyramid}!optilink!brad
  71. Petaluma, CA
  72.  
  73.