From: Vincent Cojot (coyote@step.polymtl.ca)
Date: Wed Nov 19 2003 - 05:52:53 EST
Hi everyone,
Thanks for the overwhelming response! I have received several e-mails
about that modified version of scsiinfo and I'm currently busy fixing
stuff.
I wish to thank:
- Tom Schmidt, for submitting a patch for SunOS-5.6 and SunOS-4.1.x.
- Charles Seeger, for hints on fixing the #ifdef mess I made in utils.[ch].
- Ric Anderson, for pointing out the problem with -p and get_devicepath().
- Robert Maiello, for much debugging and prtconf output information (the
new scsiinfo actually helped him find a problem on a new system he had.. :) )
- Others, which I did not list here..
I have two issues that I'm working on:
- Code cleanups and portability fixes in quc/qlc stuff.
- Fixing the 'probe' (-p) bug.
Also, I'd be interested to hear from anyone with more info about the
ISP10160 adapter.
The reason behind this is that SUN did not provide header files for the
qus (ISP10160) adapter. Since it was close enough to the ISP1040 adapter
(see isp.c in scsiinfo), I decided to create my own qus header files based
on information from the kernel (see /usr/lib/adb/qus_isp,
/usr/lib/adb/isp) and on the header files for the isp adapter. This is why
the qusmail.h, qusreg.h, qusvar.h files provided with the modified
scsiinfo look like ispmail.h, ispreg.h and ispvar.h, they are in fact base
on the latter.
However, the part I have trouble with is the following. In qusmail.h, I
declared these new values:
#define QUS_160M_SYNC_PERIOD 0x0008
#define QUS_80M_SYNC_PERIOD 0x0009
#define QUS_40M_SYNC_PERIOD 0x000A
I know from one of the V880's I have access to that the 160M value is
mostl likely right (prtconf -v also gives an hex value in the form of
targetX-sync-speed, which matches the negociated sync speed). Also, it
appears that the 80M value is also most likely OK -but- I have no idea if
I broke the routines for the other sync speeds (40M, 20M, 10M) or not..
The temporary conclusion is that you shouldn't trust too much the lower
negociated sync values reported by the qus driver in the modified scsiinfo
until I can get access to more information. I'll try to see if I can
connect older dds/cd drives to a qus adapter and see if the correct values
pop up. I you have devices connected to a qus adapter which are reported
by the modified scsiinfo to be in the 80M-4M range, please report this to
me along with a 'prtconf -v' output so I can verify we have the correct
values... :)
Also, about the qlc driver. This is a real hack as: 1) even though header
files are provided, I didn't know what all the values were used for (check
my 'topology type' which most likely means something but which I am unable
to diagnose precisely) and 2) I am no SAN expert. However, some of the
displayed values must be valuable since I had help from some SAN experts
here and since my output also matches the output from 'cfgadm -al -o
show_FCP_dev' and 'luxadm -e dump_map /dev/fc/fpX'.. :)
now, back to fixing scsiinfo before I submit a patch to John DiMarco..
Thanks for all the feedback!
,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,
Vincent S. Cojot, Computer Engineering. STEP project. _.,-*~'`^`'~*-,._.,-*~
Ecole Polytechnique de Montreal, Comite Micro-Informatique. _.,-*~'`^`'~*-,.
Linux Xview/OpenLook resources page _.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'
http://step.polymtl.ca/~coyote _.,-*~'`^`'~*-,._ coyote@step.polymtl.ca
They cannot scare me with their empty spaces
Between stars - on stars where no human race is
I have it in me so much nearer home
To scare myself with my own desert places. - Robert Frost
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:27:31 EDT