Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 Jan 1996 23:43:56 -0500
From:      James Faubus <faubus@fastlane.net>
To:        freebsd-scsi@FreeBSD.ORG
Subject:   scsiconf.c
Message-ID:  <31085C0C.7DA9@fastlane.net>

next in thread | raw e-mail | index | archive | help
I receintly tried to get a Panasonic PD-1 phase change optical PC/CD
drive to work with FreeBSD 2.1. I had an idea that it should work since 
it worked fine with the sd driver in NetBSD 1.1. However, I added the
device to the tables and recompiled, but it was still unrecognized
whether NEW_SCSICONF was defined or not. A search of the FreeBSD
archives turned this up.

======================================================================

> The first thing I did was add entries to the knowndevs[] of scsiconf.c which
> looked like this:
>         /* Added this one to force my fuji m2521A to device sd */
>         {
>                 T_OPTICAL, T_REMOV, "*", "*", "*",
>                 "sd", SC_ONE_LU
>         },
> and this:
>         /* Added this one to force my fuji m2521A to device sd */
>         {
>                 T_OPTICAL, T_REMOV, "FUJITSU", "any"
>                     ,"any", "sd", SC_ONE_LU
>         },
>
>correct
> for each of the defines (it turns out my kernel is compling with
> NEW_SCSICONF undefined).
>
>yes
> This resulted in no change of behavior :-( So I added a few printf in
> to see what was going on, and the problem is that when
> scsi_device_lookup(int type) is called, it checks the type of the device
> (T_OPTICAL in my case) against the type specified for the particular
> driver (T_DIRECT in the case of the sd driver). Since they never match,
> the uk driver is always defaulted to.
>eh? this has been changed by someone.....!
>I originally wrote it to specifically over-ride the default
>type if the tables said to!
>damn!
>thanks for pointing this out.!
>
> What I did was cheat, and make scsi_device_lookup() look like this...
>
> static struct scsi_device *
> scsi_device_lookup(int type)
> {
>         struct scsi_device *sd;
>                 if (sd->type == type ||
>                     (sd->type == T_DIRECT && type == T_OPTICAL)) {
>                         return sd;
>                  }
>         }
>
>         return &uk_switch;
> }==============================
and this
=====================================================================
>I don't know if I'm the culprit or not, but scsi_probedev is using
>scsi_selectdev to find the bestmatch in the scsi_devs table, and
>then it uses the type field in scsi_devs to override the type
>returned by the device.  Look at the very end of scsi_probedev.
>So if you change "T_OPTICAL" to "T_DIRECT" to fake your device out
>as a direct device and hook your device up to the sd driver. The
>"mx1" entries in scsiconf can't be working correctly.
>--
>Peter Dufault               Real Time Machine Control and Simulation==================================================================



Well I too was able to get the PD to work by making similar changes
to scsi_device_register().

But, although this enables the PD to be probed and found, now the CD
on lun 1 is not probed or found. (because it relies on uk somehow?)

Now, I personaly don't know enough about the scsi driver to be able
to fix this problem. I would just like to point out that there is a
problem with the way devices are probed. Apparently the tables are
useless even when "option NEW_SCSICONF" is defined in the kernel
conf, as was receintly pointed out reguarding CD-R drives.

The scsi driver seems to be able to handle the newer type removeable
and optical type drives just fine, it just seems to have some
problems recognizing and assigning the sd device to them.

Of course there are some other minor problems, like the "mode sense"
error given once in a while, but it is benign and really doesn't keep
the driver from functioning just fine. Also, the driver can't handle
sensing the drive door opening to auto sense when the media has
changed, but that only means you have to umount before switching
media. The NetBSD drivers also have the last two problems, but at
least they have fixed the device probe stuff to work with a wider
range of drives.

In this reguard I would like to pass along these diffs someone passed
along to me, if they would help anyone else. They are for the NetBSD
driver, but they do correct the drive door and mode sense prob.
Perhaps someone more familiar with the scsi code could look at the
probe prob, and maybe use the NetBSD driver patches to fix the sd
driver to support zip, jazz, PD, fuji optical as well.

I have seen reference to similar diffs in the od.c file in FreeBSD
curent for these same problems, but I have not had time to try them.
Until the real problem of device probing is fixed they are secondary
to me.

======================================================================
  Sorry for the delay ... These are the diffs I am using with
NetBSD-current
as of Friday.

Cheers,
                                Mark


                                - --
                                Mark Brinicombe
amb@physig.ph.kcl.ac.uk
Research Associate                      http://www.ph.kcl.ac.uk/~amb/
Department of Physics                   tel: 0171 873 2894
King's College London                   fax: 0171 873 2420

- --PART-BOUNDARY=.19512181747.ZM28312.ph.kcl.ac.uk
Encoding: 76 text
X-Zm-Content-Name: scsi.sd.c.patch
Content-Type: text/plain ; charset=us-ascii

*** sd.c.orig   Mon Dec 18 03:01:42 1995
- --- sd.c      Mon Dec 18 03:01:42 1995
***************
*** 85,90 ****
- --- 85,91 ----
#define       SDF_WLABEL      0x04            /* label is writable*/
#define       SDF_LABELLING   0x08            /* writing label */
#define       SDF_ANCIENT     0x10            /* disk is ancient;
for minphys */
+ #define       SDF_OPTICAL     0x20            /* device is optical
memory */
        struct scsi_link *sc_link;      /* contains our targ, lun,etc. 
*/
        struct disk_parms {
                        u_char heads;           /* number of heads */
***************
*** 175,180 ****
- --- 176,190 ----
        if ((sa->sa_inqbuf->version &SID_ANSII) == 0)
             sd->flags |= SDF_ANCIENT;

+       /*
+        *  Take note if it is an optical device - we need this info 
later
+        */
+
+       if ((sa->sa_inqbuf->device & SID_TYPE) == T_OPTICAL)
+               sd->flags |= SDF_OPTICAL;
+
+       sd->sc_dk.dk_driver = &sddkdriver;
+
        sd->sc_dk.dk_driver = &sddkdriver;
#if !defined(i386) || defined(NEWCONFIG)
          dk_establish(&sd->sc_dk, &sd->sc_dev);
***************
*** 375,380 ****
- --- 385,400 ----
          scsi_prevent(sd->sc_link, PR_ALLOW,

SCSI_IGNORE_ILLEGAL_REQUEST | SCSI_IGNORE_NOT_READY);
                sd->sc_link->flags &= ~SDEV_OPEN;
+
+     /*
+      * Some optical devices do not report unit attention messages
+      * when the media is changed. Thus the disc can be changed
+      * without SDEV_MEDIA_LOADED being set.
+      * Instead invalidate the media when the last opening is closed.
+      */
+
+      if (sd->sc_link->flags & SDEV_REMOVABLE)
+          sd->sc_link->flags &= ~SDEV_MEDIA_LOADED;
        }

        sdunlock(sd);
***************
*** 833,838 ****
- --- 853,866 ----
        u_long sectors;

        /*
+        * Optical memory devices do not support mode sense page 4
+        * (According to SCSI2 specs and my drive)
+        */
+
+       if (sd->flags & SDF_OPTICAL)
+               goto fake_it_for_optical;
+
+       /*
         * do a "mode sense page 4"
         */
           bzero(&scsi_cmd, sizeof(scsi_cmd));
***************
*** 849,854 ****
- --- 877,883 ----
           printf("%s: could not mode sense (4)", sd->sc_dev.dv_xname);
  fake_it:
           printf("; using fictitious geometry\n");
+ fake_it_for_optical:
       /*
        * use adaptec standard fictitious geometry
        * this depends on which controller (e.g. 1542C is

---PART-BOUNDARY=.19512181747.ZM28312.ph.kcl.ac.uk--

------- End of forwarded message -------

===========================================================


Could someone who knows how the sd driver really works please take a 
look at this along with the info in od.c and NetBSD and try to straiten
out the probs with sd.c and scsiconf.c as they relate to adding devices, 
like removable opticals and CD-R's in FreeBSD.

Maybe they already have and I just don't know it.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?31085C0C.7DA9>