Date: Mon, 17 Jul 2000 22:04:36 -0600 From: "Kenneth D. Merry" <ken@kdm.org> To: "Jason T. Miller" <jasomill@shaffstall.com> Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Yamaha CDR100 and FreeBSD 4.0-STABLE Message-ID: <20000717220436.A96300@panzer.kdm.org> In-Reply-To: <Pine.LNX.4.10.10007170825460.5493-100000@guildenstern.shaffstall.com>; from jasomill@shaffstall.com on Mon, Jul 17, 2000 at 10:10:21AM -0500 References: <Pine.LNX.4.10.10007170825460.5493-100000@guildenstern.shaffstall.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 17, 2000 at 10:10:21 -0500, Jason T. Miller wrote: > I just recieved (for free), a Yamaha CDR100 4x CD burner. This is a great > drive that (at work) has served me well for a couple years; it works fine > with cdrecord and cdrdao. However, its cooperation with the FreeBSD SCSI > CD-ROM driver is not as good. First of all, if there is no media loaded on > boot, I get the messages "lost device" and "removing device entry." I > haven't done much research on this particular problem yet; I'm just > keeping a disc in the drive when I reboot. I have noticed, however, that > the "removal" of the device entry is not complete; if I try to access > /dev/cd0c, I get a kernel panic. Well, it might be interesting to see what exactly your drive returns in response to a read capacity when there is no CD in the drive. Here's an easy way to find out: # camcontrol cmd cd0 -v -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4" 191854 2048 [ eject the CD ] # camcontrol cmd cd0 -v -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4" camcontrol: error sending command (pass2:ahc0:0:4:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (pass2:ahc0:0:4:0): NOT READY asc:3a,0 (pass2:ahc0:0:4:0): Medium not present The cd(4) driver will attach to any CDROM or WORM device that returns a SCSI error for read capacity, as long as it isn't "logical unit not supported". If you get another type of error, like a selection timeout, it likely won't attach. So we need to figure out what sort of error your drive is returning to figure out whether there is a bug somewhere or not. As far as the panic, it would be nice if you could supply a stack trace for that. The FreeBSD Handbook covers crashdumps and kernel debugging: http://www.freebsd.org/handbook/kerneldebug.html [ Yamaha drive returns something other than 2048 for a blocksize ] > I'd like to get a working solution in the kernel, if possible, but want > input before I write up the diffs. The simplest thing would be to use my > "dumb hack" as a kernel DEFINE, since it shouldn't break anything that > already works anyway. It could also be added as a new drive quirk. The > most elegent solution, however, would be the above MODE SELECT solution, > plus possibly a quirk entry if it turns out not to be compatible with all > drives. Well, we've already solved that problem. You need a later version of -stable. Joerg Wunsch had a similar problem with an older Plasmon CD-R. The fix was to round any blocksize greater than 2048 and less than or equal to 2352 down to 2048. > Finally, I do realize that some OEM-modified CD-ROM drives allow a > 512-byte block size, then do the deblocking of 2048-byte records in the > drive. This was to maintain compatibility with hard drive code that was > dependent on a 512-byte block size. Are these drives supported now, and is > anyone using them? I don't think I have any, though I do have an old SunCD > that may or may not do it; haven't checked yet. Yes, they are supported by the driver, I'm not sure about the ISO9660 code. You can often use a dip switch or jumper to change the behavior back and forth, though. Usually you'll only want to use the drive in 512-byte block mode to access CDs created with a 512-byte blocksize. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000717220436.A96300>