scsirastools-developers Mailing List for scsirastools (Page 2)
Brought to you by:
arcress
Menu
▾
▴
scsirastools-developers — Developer list for scsirastools raid1 project
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(3) |
Feb
(1) |
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
(3) |
Jun
(1) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2005 |
Jan
|
Feb
(3) |
Mar
|
Apr
(1) |
May
(6) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
(1) |
Feb
(16) |
Mar
(27) |
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(6) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(7) |
| 2014 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Cress, A. R <and...@in...> - 2007-04-23 15:58:13
|
The scsirastools-1.5.4 release is now posted to sourceforge. See http://scsirastools.sf.net for rpms, etc. =20 Changes: 1.5.4 =3D released 04/16/07, updated 04/16/07 src/sgsubmon.c - handle SES enclosure LED controls files/alarms - new version with alarms -d option for enclosure files/sgevt - invoke alarms -d files/mdevt - invoke alarms -d scsirastools-1.5.4 contains: sgdefects.c ver 1.9 sgdiag.c ver 1.16 sgdiskmon.c ver 1.2 sgdskfl.c ver 1.12 sgmode.c ver 1.13 sgraidmon.c ver 1.31 sgsafte.c ver 1.23 =20 Andy=20 |
|
From: Cress, A. R <and...@in...> - 2007-04-13 19:39:05
|
The scsirastools-1.5.3 release is now posted on sourceforge. SES-2 support has been added. See http://scsirastools.sf.net for rpms, etc. =20 Changes: 1.5.3 =3D released 04/13/07, updated 04/13/07 src/sgdiskmon.c - handle SES enclosure slot statuses, cleanup src/sgraidmon.c - handle SES enclosure slot statuses src/sgsafte.c - handle SES enclosure slot statuses src/sgsubmon.c - handle SES enclosure slot statuses src/Makefile.am - allow make sgerr src/sgerr.c - added TEST flag to build separate sgerr utility files/sgevt - fixed lines 128,131 for alarms changed disklist to use /proc/partitions instead of fdisk files/mdevt - changed disklist to use /proc/partitions instead of fdisk doc/sgsafte.8 - new file scsirastools-1.5.3 contains: sgdefects.c ver 1.8 sgdiag.c ver 1.15 sgdiskmon.c ver 1.1 sgdskfl.c ver 1.11 sgmode.c ver 1.12 sgraidmon.c ver 1.30 sgsafte.c ver 1.22 =20 Andy Cress 803-216-2356 fax:803-216-2178 Software Architect and...@in... Intel Corporation, Columbia Design Center 100 Center Point Cir, Suite 200, Columbia, SC 29210 http://ipmiutil.sf.net <http://ipmiutil.sf.net/> http://scsirastools.sf.net <http://scsirastools.sf.net/>=20 "Do not merely look out for your own personal interests, but also for the interests of others." Phil 2:4 =20 |
|
From: Cress, A. R <and...@in...> - 2007-03-15 14:19:33
|
The scsirastools-1.5.2 release is posted on sourceforge. See http://scsirastools.sf.net for rpms, etc. =20 Changes for this release, from ChangeLog: 1.5.2 =3D released 03/15/07, updated 03/14/07 src/sgdiskmon.c - fprintf error checking in add/rem_scsi_dev, Fix Fujitsu disk fw bug with inquiry len of 41, allow Encl devtype=3D=3D13 fix matching dev to a proc in write_slots src/sgraidmon.c - Fix Fujitsu disk fw bug with inquiry len of 41, allow Encl devtype=3D=3D13 fix matching dev to a proc in write_slots src/sgsafte.c - Fix Fujitsu disk fw bug with inquiry len of 41, allow Encl devtype=3D=3D13 fix matching dev to a proc in write_slots src/sgcommon.c - Fix Fujitsu disk fw bug with inquiry len of 41. src/sgsubmon.c - new, merged subroutines for sgdiskmon, sgsafte, sgraidmon src/sgsubmon.h - new, merged includes for sgdiskmon, sgsafte, sgraidmon src/Makefile.am - added sgsubmon.[c,h] scsirastools-1.5.2 contains: sgdefects.c ver 1.7 sgdiag.c ver 1.14 sgdiskmon.c ver 1.0 sgdskfl.c ver 1.10 sgmode.c ver 1.11 sgraidmon.c ver 1.29 sgsafte.c ver 1.21 =20 =20 |
|
From: Cress, A. R <and...@in...> - 2007-03-15 13:29:04
|
That's weird, the slot status being read in step 2 does not show that the disk fault bit has been turned on for disk 0. Perhaps the HSBP only uses its own leads to set the read status and doesn't look at the disk fault bit that was in the write status. Maybe there is another way to read that. I'll look into it. =20 It would definitely show a different status if the disk(s) were really removed or not ready, though. =20 I need to go ahead and release a new 1.5.2 version with the changes made so far. Thankfully, the case of more than one disk fault (especially while still ready) at the same time should be rare, so I think that change can wait until 1.5.3. Andy=20 -----Original Message----- From: Daniel Smolik [mailto:ma...@my...]=20 Sent: Thursday, March 15, 2007 9:17 AM To: Cress, Andrew R; scs...@li... Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) Cress, Andrew R napsal(a): > Hmmm. It has to set all of the slot LEDs on a backplane when it sets > any one of them, but it reads the current status first before changing > the one indicated. >=20 > Can you send me the sgsafte.log with -x turned on for that case? =20 > That should show what the last read status is for the slots. =20 >=20 Yes, I do : ./sgsafte -x -d0 -f > /tmp/log ./sgsafte -x -d1 -f >> /tmp/log ./sgsafte -x -d0 -f >> /tmp/log > Andy=20 >=20 > -----Original Message----- > From: Daniel Smolik [mailto:ma...@my...]=20 > Sent: Wednesday, March 14, 2007 3:57 PM > Cc: Cress, Andrew R; scs...@li... > Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) >=20 > Daniel Smolik napsal(a): >=20 >>Cress, Andrew R napsal(a): >> >> >>>Dan, >>> >>>OK, I have posted to the SVN trunk an updated sgsafte.c with more >>>sophisticated handling for >=3D2 HSBP proc devices like you have. >>>Please see if this handles the disk fault LEDs better, and send me >=20 > the >=20 >>>debug log.=20 >> >> >>Hi, >>there is debug log now. Status of LEDs I can test tomorrow. >>Displaying informations about disks and processor are now excelent >=20 > :-) > I today test LED on enclosure. Situation is better. I can switch to=20 > orange each led this is good. But if I turn on LED1 and after this a=20 > try turn on LED 2, LED 1 turn off and LED2 turn on. If I try turn on LED >=20 > 3 LED 2 turn off and LED 3 turn on. I cannot get all LEDs on. >=20 >=20 > Regards > Dan --=20 Mydatex s r.o. http://www.mydatex.cz email: sm...@my... mob: 604200362 tel: 226210085 |
|
From: Daniel S. <ma...@my...> - 2007-03-15 13:23:29
|
Daniel Smolik napsal(a): > Cress, Andrew R napsal(a): > >> Hmmm. It has to set all of the slot LEDs on a backplane when it sets >> any one of them, but it reads the current status first before changing >> the one indicated. >> >> Can you send me the sgsafte.log with -x turned on for that case? That >> should show what the last read status is for the slots. > > > Yes, > I do : > > ./sgsafte -x -d0 -f > /tmp/log > > > ./sgsafte -x -d1 -f >> /tmp/log > ./sgsafte -x -d0 -f >> /tmp/log > Sorry. ./sgsafte -x -d2 -f >> /tmp/log Dan > > > > > > >> Andy >> -----Original Message----- >> From: Daniel Smolik [mailto:ma...@my...] Sent: Wednesday, March >> 14, 2007 3:57 PM >> Cc: Cress, Andrew R; scs...@li... >> Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) >> >> Daniel Smolik napsal(a): >> >>> Cress, Andrew R napsal(a): >>> >>> >>>> Dan, >>>> >>>> OK, I have posted to the SVN trunk an updated sgsafte.c with more >>>> sophisticated handling for >=2 HSBP proc devices like you have. >>>> Please see if this handles the disk fault LEDs better, and send me >> >> >> the >> >>>> debug log. >>> >>> >>> >>> Hi, >>> there is debug log now. Status of LEDs I can test tomorrow. >>> Displaying informations about disks and processor are now excelent >> >> >> :-) >> I today test LED on enclosure. Situation is better. I can switch to >> orange each led this is good. But if I turn on LED1 and after this a >> try turn on LED 2, LED 1 turn off and LED2 turn on. If I try turn on LED >> >> 3 LED 2 turn off and LED 3 turn on. I cannot get all LEDs on. >> >> >> Regards >> Dan > > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > > ------------------------------------------------------------------------ > > _______________________________________________ > Scsirastools-developers mailing list > Scs...@li... > https://lists.sourceforge.net/lists/listinfo/scsirastools-developers -- Mydatex s r.o. http://www.mydatex.cz email: sm...@my... mob: 604200362 tel: 226210085 |
|
From: Daniel S. <ma...@my...> - 2007-03-15 13:17:27
|
Cress, Andrew R napsal(a): > Hmmm. It has to set all of the slot LEDs on a backplane when it sets > any one of them, but it reads the current status first before changing > the one indicated. > > Can you send me the sgsafte.log with -x turned on for that case? > That should show what the last read status is for the slots. > Yes, I do : ./sgsafte -x -d0 -f > /tmp/log ./sgsafte -x -d1 -f >> /tmp/log ./sgsafte -x -d0 -f >> /tmp/log > Andy > > -----Original Message----- > From: Daniel Smolik [mailto:ma...@my...] > Sent: Wednesday, March 14, 2007 3:57 PM > Cc: Cress, Andrew R; scs...@li... > Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) > > Daniel Smolik napsal(a): > >>Cress, Andrew R napsal(a): >> >> >>>Dan, >>> >>>OK, I have posted to the SVN trunk an updated sgsafte.c with more >>>sophisticated handling for >=2 HSBP proc devices like you have. >>>Please see if this handles the disk fault LEDs better, and send me > > the > >>>debug log. >> >> >>Hi, >>there is debug log now. Status of LEDs I can test tomorrow. >>Displaying informations about disks and processor are now excelent > > :-) > I today test LED on enclosure. Situation is better. I can switch to > orange each led this is good. But if I turn on LED1 and after this a > try turn on LED 2, LED 1 turn off and LED2 turn on. If I try turn on LED > > 3 LED 2 turn off and LED 3 turn on. I cannot get all LEDs on. > > > Regards > Dan -- Mydatex s r.o. http://www.mydatex.cz email: sm...@my... mob: 604200362 tel: 226210085 |
|
From: Cress, A. R <and...@in...> - 2007-03-15 12:59:34
|
Hmmm. It has to set all of the slot LEDs on a backplane when it sets any one of them, but it reads the current status first before changing the one indicated. Can you send me the sgsafte.log with -x turned on for that case? =20 That should show what the last read status is for the slots. =20 Andy=20 -----Original Message----- From: Daniel Smolik [mailto:ma...@my...]=20 Sent: Wednesday, March 14, 2007 3:57 PM Cc: Cress, Andrew R; scs...@li... Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) Daniel Smolik napsal(a): > Cress, Andrew R napsal(a): >=20 >> Dan, >> >> OK, I have posted to the SVN trunk an updated sgsafte.c with more >> sophisticated handling for >=3D2 HSBP proc devices like you have. >> Please see if this handles the disk fault LEDs better, and send me the >> debug log.=20 >=20 >=20 > Hi, > there is debug log now. Status of LEDs I can test tomorrow. > Displaying informations about disks and processor are now excelent :-) I today test LED on enclosure. Situation is better. I can switch to=20 orange each led this is good. But if I turn on LED1 and after this a=20 try turn on LED 2, LED 1 turn off and LED2 turn on. If I try turn on LED 3 LED 2 turn off and LED 3 turn on. I cannot get all LEDs on. Regards Dan |
|
From: Daniel S. <ma...@my...> - 2007-03-14 19:57:35
|
Daniel Smolik napsal(a): > Cress, Andrew R napsal(a): > >> Dan, >> >> OK, I have posted to the SVN trunk an updated sgsafte.c with more >> sophisticated handling for >=2 HSBP proc devices like you have. >> Please see if this handles the disk fault LEDs better, and send me the >> debug log. > > > Hi, > there is debug log now. Status of LEDs I can test tomorrow. > Displaying informations about disks and processor are now excelent :-) I today test LED on enclosure. Situation is better. I can switch to orange each led this is good. But if I turn on LED1 and after this a try turn on LED 2, LED 1 turn off and LED2 turn on. If I try turn on LED 3 LED 2 turn off and LED 3 turn on. I cannot get all LEDs on. Regards Dan |
|
From: Daniel S. <ma...@my...> - 2007-03-13 15:35:43
|
Cress, Andrew R napsal(a): > Dan, > > OK, I have posted to the SVN trunk an updated sgsafte.c with more > sophisticated handling for >=2 HSBP proc devices like you have. > Please see if this handles the disk fault LEDs better, and send me the > debug log. Hi, there is debug log now. Status of LEDs I can test tomorrow. Displaying informations about disks and processor are now excelent :-) Regards Dan |
|
From: Cress, A. R <and...@in...> - 2007-03-13 15:19:56
|
Dan, OK, I have posted to the SVN trunk an updated sgsafte.c with more sophisticated handling for >=3D2 HSBP proc devices like you have. Please see if this handles the disk fault LEDs better, and send me the debug log.=20 Andy=20 -----Original Message----- From: Daniel Smolik [mailto:ma...@my...]=20 Sent: Friday, March 09, 2007 4:25 PM To: Cress, Andrew R Cc: scs...@li... Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) Cress, Andrew R napsal(a): > Hmmm. I think I see the problem, but this may take some time to change. >=20 Ok no problem let me know :-) I test again. Dan > Andy=20 >=20 > -----Original Message----- > From: Daniel Smolik [mailto:ma...@my...]=20 > Sent: Friday, March 09, 2007 2:52 PM > To: Cress, Andrew R; scs...@li... > Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) >=20 > Cress, Andrew R napsal(a): >=20 >>Dan, >> >>I made both of those changes in the svn trunk. >>Please try it out when you get a chance. >> >=20 > I today test LEDs and result is there. > My enclosure (D1000) have two channels and on the each I have 3 disks. > I try sgasafte -f -d 0-3 and -d 4-6. >=20 > LED1 LED2 LED3 LED4 LED5 LED6 >=20 > -d0-3 turn orange LED on LED4-LED6 but d4-6 doesn't turn LED. > I cann't switch LED1 - LED3 to orange in any way. >=20 >=20 > Dan --=20 Mydatex s r.o. http://www.mydatex.cz email: sm...@my... mob: 604200362 tel: 226210085 |
|
From: Daniel S. <ma...@my...> - 2007-03-09 21:25:29
|
Cress, Andrew R napsal(a): > Hmmm. I think I see the problem, but this may take some time to change. > Ok no problem let me know :-) I test again. Dan > Andy > > -----Original Message----- > From: Daniel Smolik [mailto:ma...@my...] > Sent: Friday, March 09, 2007 2:52 PM > To: Cress, Andrew R; scs...@li... > Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) > > Cress, Andrew R napsal(a): > >>Dan, >> >>I made both of those changes in the svn trunk. >>Please try it out when you get a chance. >> > > I today test LEDs and result is there. > My enclosure (D1000) have two channels and on the each I have 3 disks. > I try sgasafte -f -d 0-3 and -d 4-6. > > LED1 LED2 LED3 LED4 LED5 LED6 > > -d0-3 turn orange LED on LED4-LED6 but d4-6 doesn't turn LED. > I cann't switch LED1 - LED3 to orange in any way. > > > Dan -- Mydatex s r.o. http://www.mydatex.cz email: sm...@my... mob: 604200362 tel: 226210085 |
|
From: Cress, A. R <and...@in...> - 2007-03-09 21:18:25
|
Hmmm. I think I see the problem, but this may take some time to change. Andy=20 -----Original Message----- From: Daniel Smolik [mailto:ma...@my...]=20 Sent: Friday, March 09, 2007 2:52 PM To: Cress, Andrew R; scs...@li... Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) Cress, Andrew R napsal(a): > Dan, >=20 > I made both of those changes in the svn trunk. > Please try it out when you get a chance. >=20 I today test LEDs and result is there. My enclosure (D1000) have two channels and on the each I have 3 disks. I try sgasafte -f -d 0-3 and -d 4-6. LED1 LED2 LED3 LED4 LED5 LED6 -d0-3 turn orange LED on LED4-LED6 but d4-6 doesn't turn LED. I cann't switch LED1 - LED3 to orange in any way. Dan |
|
From: Daniel S. <ma...@my...> - 2007-03-09 19:51:51
|
Cress, Andrew R napsal(a): > Dan, > > I made both of those changes in the svn trunk. > Please try it out when you get a chance. > I today test LEDs and result is there. My enclosure (D1000) have two channels and on the each I have 3 disks. I try sgasafte -f -d 0-3 and -d 4-6. LED1 LED2 LED3 LED4 LED5 LED6 -d0-3 turn orange LED on LED4-LED6 but d4-6 doesn't turn LED. I cann't switch LED1 - LED3 to orange in any way. Dan |
|
From: Daniel S. <ma...@my...> - 2007-03-08 22:24:49
|
Cress, Andrew R napsal(a):
> Dan,
>
> I made both of those changes in the svn trunk.
> Please try it out when you get a chance.
>
I have only remote access now.
sgsafte utility v1.21 for SCSI SAF-TE testing
Num Name bus:ch:id:lun Type Vendor Device_Model FRev Serial#
Status
0 /dev/sg0 /dev/sda 1:0:8:0 Disk FUJITSU MAG3091L SUN9.0G 1111
9944498794?` ready
1 /dev/sg1 /dev/sdb 1:0:9:0 Disk FUJITSU MAG3091L SUN9.0G 1111
9944499100?` ready
2 /dev/sg2 /dev/sdc 1:0:10:0 Disk FUJITSU MAG3091L SUN9.0G 1111
9944499308?` ready
3 /dev/sg3 1:0:15:0 Proc SYMBIOS D1000 2 `'}
ready
4 /dev/sg4 /dev/sdd 2:0:8:0 Disk FUJITSU MAG3091L SUN9.0G 1111
9944498792 ready
5 /dev/sg5 /dev/sde 2:0:9:0 Disk FUJITSU MAG3091L SUN9.0G 1111
9944499149 ready
6 /dev/sg6 /dev/sdf 2:0:10:0 Disk FUJITSU MAG3091L SUN9.0G 1111
9944499314 ready
7 /dev/sg7 2:0:15:0 Proc SYMBIOS D1000 2 `'}
ready
8 /dev/sg8 /dev/sdg 4:0:6:0 CDRM TOSHIBA XM6201TASUN32XCD 1103 12/12/97
ready
9 /dev/sg9 /dev/sdh 5:0:0:0 Disk SEAGATE ST39103LCSUN9.0G 034A
9949862528 ready
monitoring 10 scsi devices ...
Bit still some garbage on end of serial number. Status led I test tomorow.
Dan
|
|
From: Cress, A. R <and...@in...> - 2007-03-08 22:01:33
|
Dan, I made both of those changes in the svn trunk. Please try it out when you get a chance. Andy=20 -----Original Message----- From: Daniel Smolik [mailto:ma...@my...]=20 Sent: Thursday, March 08, 2007 3:07 PM To: Cress, Andrew R Cc: scs...@li... Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) Cress, Andrew R napsal(a): > That's good news. >=20 > The orange led is the correct color (disk fault LED is orange), the > green means disk activity. >=20 Yes I agree with you. > I think that I can avoid the extra characters by making sure that the > inquiry buffer is fully initialized to the buffer size, instead of the > inquiry length (which came back wrong from those drives). =20 >=20 > Turning on the LED in both enclosures is a bug, and I need to handle > that. > There is apparently a problem matching the disk to the proper > Proc/Backplane. Thanks. Dan >=20 > Andy=20 >=20 > -----Original Message----- > From: Daniel Smolik [mailto:ma...@my...]=20 > Sent: Thursday, March 08, 2007 6:55 AM > To: Cress, Andrew R > Cc: scs...@li... > Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) >=20 > Cress, Andrew R napsal(a): >=20 >>Evan, >> >>That looks much better. >>The only anomaly in it, is that it tried to see if two proc's match >=20 > serial number, and it shouldn't try. >=20 >>This is unusual that two of the same procs are in the same system, >=20 > which is why I never had this problem before. >=20 >>Anyway, this latest sgsafte.c should work fine on your system now. >> >>If it still has some problems, send me the sgsafte -x log output >=20 > again. >=20 >>If it works ok, let me know and I'll make sure these fixes are working >=20 > in the other tools as well. >=20 >=20 > sgsafte utility v1.21 for SCSI SAF-TE testing > Num Name bus:ch:id:lun Type Vendor Device_Model FRev Serial#=20 > Status > 0 /dev/sg0 /dev/sda 1:0:8:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20 > 9944498794?` rea=20 > dy > 1 /dev/sg1 /dev/sdb 1:0:9:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20 > 9944499100?` rea=20 > dy > 2 /dev/sg2 /dev/sdc 1:0:10:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20 > 9944499308?` re=20 > ady > 3 /dev/sg3 1:0:15:0 Proc SYMBIOS D1000 2 `'}=20 > ready > 4 /dev/sg4 /dev/sdd 2:0:8:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20 > 9944498792 ready=20 >=20 > 5 /dev/sg5 /dev/sde 2:0:9:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20 > 9944499149 ready=20 >=20 > 6 /dev/sg6 /dev/sdf 2:0:10:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20 > 9944499314 read=20 > y > 7 /dev/sg7 2:0:15:0 Proc SYMBIOS D1000 2 `'}=20 > ready > 8 /dev/sg8 /dev/sdg 4:0:6:0 CDRM TOSHIBA XM6201TASUN32XCD 1103 12/12/97 >=20 > ready > 9 /dev/sg9 /dev/sdh 5:0:0:0 Disk SEAGATE ST39103LCSUN9.0G 034A=20 > 9949862528 ready >=20 >=20 > sgsafte utility v1.21 for SCSI SAF-TE testing > Num Name bus:ch:id:lun Type Vendor Device_Model FRev Serial#=20 > Status > 0 /dev/sg0 /dev/sda 1:0:8:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20 > 9944498794 ready > 1 /dev/sg1 /dev/sdb 1:0:9:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20 > 9944499100 ready > 2 /dev/sg2 /dev/sdc 1:0:10:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20 > 9944499308 ready > 3 /dev/sg3 1:0:15:0 Proc SYMBIOS D1000 2 `'}=20 > ready > 4 /dev/sg4 /dev/sdd 2:0:8:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20 > 9944498792 ready > 5 /dev/sg5 /dev/sde 2:0:9:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20 > 9944499149 ready > 6 /dev/sg6 /dev/sdf 2:0:10:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20 > 9944499314 ready > 7 /dev/sg7 2:0:15:0 Proc SYMBIOS D1000 2 `'}=20 > ready > 8 /dev/sg8 /dev/sdg 4:0:6:0 CDRM TOSHIBA XM6201TASUN32XCD 1103 12/12/97 >=20 > ready > 9 /dev/sg9 /dev/sdh 5:0:0:0 Disk SEAGATE ST39103LCSUN9.0G 034A=20 > 9949862528 ready > monitoring 10 scsi devices ... >=20 >=20 > Thanks Andy , great work now displays all correctly. Only small garbage=20 > when sometime run (look at first output). I now test sgsafte -d 0 -f and >=20 > it works !!! Turn on orange led instead of green led on enclosure. But > this turn on led on second half of enclosure too (on second processor). >=20 > Dan >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 --=20 Mydatex s r.o. http://www.mydatex.cz email: sm...@my... mob: 604200362 tel: 226210085 |
|
From: Daniel S. <ma...@my...> - 2007-03-08 20:07:27
|
Cress, Andrew R napsal(a): > That's good news. > > The orange led is the correct color (disk fault LED is orange), the > green means disk activity. > Yes I agree with you. > I think that I can avoid the extra characters by making sure that the > inquiry buffer is fully initialized to the buffer size, instead of the > inquiry length (which came back wrong from those drives). > > Turning on the LED in both enclosures is a bug, and I need to handle > that. > There is apparently a problem matching the disk to the proper > Proc/Backplane. Thanks. Dan > > Andy > > -----Original Message----- > From: Daniel Smolik [mailto:ma...@my...] > Sent: Thursday, March 08, 2007 6:55 AM > To: Cress, Andrew R > Cc: scs...@li... > Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) > > Cress, Andrew R napsal(a): > >>Evan, >> >>That looks much better. >>The only anomaly in it, is that it tried to see if two proc's match > > serial number, and it shouldn't try. > >>This is unusual that two of the same procs are in the same system, > > which is why I never had this problem before. > >>Anyway, this latest sgsafte.c should work fine on your system now. >> >>If it still has some problems, send me the sgsafte -x log output > > again. > >>If it works ok, let me know and I'll make sure these fixes are working > > in the other tools as well. > > > sgsafte utility v1.21 for SCSI SAF-TE testing > Num Name bus:ch:id:lun Type Vendor Device_Model FRev Serial# > Status > 0 /dev/sg0 /dev/sda 1:0:8:0 Disk FUJITSU MAG3091L SUN9.0G 1111 > 9944498794?` rea > dy > 1 /dev/sg1 /dev/sdb 1:0:9:0 Disk FUJITSU MAG3091L SUN9.0G 1111 > 9944499100?` rea > dy > 2 /dev/sg2 /dev/sdc 1:0:10:0 Disk FUJITSU MAG3091L SUN9.0G 1111 > 9944499308?` re > ady > 3 /dev/sg3 1:0:15:0 Proc SYMBIOS D1000 2 `'} > ready > 4 /dev/sg4 /dev/sdd 2:0:8:0 Disk FUJITSU MAG3091L SUN9.0G 1111 > 9944498792 ready > > 5 /dev/sg5 /dev/sde 2:0:9:0 Disk FUJITSU MAG3091L SUN9.0G 1111 > 9944499149 ready > > 6 /dev/sg6 /dev/sdf 2:0:10:0 Disk FUJITSU MAG3091L SUN9.0G 1111 > 9944499314 read > y > 7 /dev/sg7 2:0:15:0 Proc SYMBIOS D1000 2 `'} > ready > 8 /dev/sg8 /dev/sdg 4:0:6:0 CDRM TOSHIBA XM6201TASUN32XCD 1103 12/12/97 > > ready > 9 /dev/sg9 /dev/sdh 5:0:0:0 Disk SEAGATE ST39103LCSUN9.0G 034A > 9949862528 ready > > > sgsafte utility v1.21 for SCSI SAF-TE testing > Num Name bus:ch:id:lun Type Vendor Device_Model FRev Serial# > Status > 0 /dev/sg0 /dev/sda 1:0:8:0 Disk FUJITSU MAG3091L SUN9.0G 1111 > 9944498794 ready > 1 /dev/sg1 /dev/sdb 1:0:9:0 Disk FUJITSU MAG3091L SUN9.0G 1111 > 9944499100 ready > 2 /dev/sg2 /dev/sdc 1:0:10:0 Disk FUJITSU MAG3091L SUN9.0G 1111 > 9944499308 ready > 3 /dev/sg3 1:0:15:0 Proc SYMBIOS D1000 2 `'} > ready > 4 /dev/sg4 /dev/sdd 2:0:8:0 Disk FUJITSU MAG3091L SUN9.0G 1111 > 9944498792 ready > 5 /dev/sg5 /dev/sde 2:0:9:0 Disk FUJITSU MAG3091L SUN9.0G 1111 > 9944499149 ready > 6 /dev/sg6 /dev/sdf 2:0:10:0 Disk FUJITSU MAG3091L SUN9.0G 1111 > 9944499314 ready > 7 /dev/sg7 2:0:15:0 Proc SYMBIOS D1000 2 `'} > ready > 8 /dev/sg8 /dev/sdg 4:0:6:0 CDRM TOSHIBA XM6201TASUN32XCD 1103 12/12/97 > > ready > 9 /dev/sg9 /dev/sdh 5:0:0:0 Disk SEAGATE ST39103LCSUN9.0G 034A > 9949862528 ready > monitoring 10 scsi devices ... > > > Thanks Andy , great work now displays all correctly. Only small garbage > when sometime run (look at first output). I now test sgsafte -d 0 -f and > > it works !!! Turn on orange led instead of green led on enclosure. But > this turn on led on second half of enclosure too (on second processor). > > Dan > > > > > > > > -- Mydatex s r.o. http://www.mydatex.cz email: sm...@my... mob: 604200362 tel: 226210085 |
|
From: Cress, A. R <and...@in...> - 2007-03-08 19:23:15
|
That's good news.
The orange led is the correct color (disk fault LED is orange), the
green means disk activity.
I think that I can avoid the extra characters by making sure that the
inquiry buffer is fully initialized to the buffer size, instead of the
inquiry length (which came back wrong from those drives). =20
Turning on the LED in both enclosures is a bug, and I need to handle
that.
There is apparently a problem matching the disk to the proper
Proc/Backplane.
Andy=20
-----Original Message-----
From: Daniel Smolik [mailto:ma...@my...]=20
Sent: Thursday, March 08, 2007 6:55 AM
To: Cress, Andrew R
Cc: scs...@li...
Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives)
Cress, Andrew R napsal(a):
> Evan,
>=20
> That looks much better.
> The only anomaly in it, is that it tried to see if two proc's match
serial number, and it shouldn't try.
> This is unusual that two of the same procs are in the same system,
which is why I never had this problem before.
> Anyway, this latest sgsafte.c should work fine on your system now.
>=20
> If it still has some problems, send me the sgsafte -x log output
again.
> If it works ok, let me know and I'll make sure these fixes are working
in the other tools as well.
>=20
sgsafte utility v1.21 for SCSI SAF-TE testing
Num Name bus:ch:id:lun Type Vendor Device_Model FRev Serial#=20
Status
0 /dev/sg0 /dev/sda 1:0:8:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20
9944498794?` rea=20
dy
1 /dev/sg1 /dev/sdb 1:0:9:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20
9944499100?` rea=20
dy
2 /dev/sg2 /dev/sdc 1:0:10:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20
9944499308?` re=20
ady
3 /dev/sg3 1:0:15:0 Proc SYMBIOS D1000 2 `'}=20
ready
4 /dev/sg4 /dev/sdd 2:0:8:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20
9944498792 ready=20
5 /dev/sg5 /dev/sde 2:0:9:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20
9944499149 ready=20
6 /dev/sg6 /dev/sdf 2:0:10:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20
9944499314 read=20
y
7 /dev/sg7 2:0:15:0 Proc SYMBIOS D1000 2 `'}=20
ready
8 /dev/sg8 /dev/sdg 4:0:6:0 CDRM TOSHIBA XM6201TASUN32XCD 1103 12/12/97
ready
9 /dev/sg9 /dev/sdh 5:0:0:0 Disk SEAGATE ST39103LCSUN9.0G 034A=20
9949862528 ready
sgsafte utility v1.21 for SCSI SAF-TE testing
Num Name bus:ch:id:lun Type Vendor Device_Model FRev Serial#=20
Status
0 /dev/sg0 /dev/sda 1:0:8:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20
9944498794 ready
1 /dev/sg1 /dev/sdb 1:0:9:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20
9944499100 ready
2 /dev/sg2 /dev/sdc 1:0:10:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20
9944499308 ready
3 /dev/sg3 1:0:15:0 Proc SYMBIOS D1000 2 `'}=20
ready
4 /dev/sg4 /dev/sdd 2:0:8:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20
9944498792 ready
5 /dev/sg5 /dev/sde 2:0:9:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20
9944499149 ready
6 /dev/sg6 /dev/sdf 2:0:10:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20
9944499314 ready
7 /dev/sg7 2:0:15:0 Proc SYMBIOS D1000 2 `'}=20
ready
8 /dev/sg8 /dev/sdg 4:0:6:0 CDRM TOSHIBA XM6201TASUN32XCD 1103 12/12/97
ready
9 /dev/sg9 /dev/sdh 5:0:0:0 Disk SEAGATE ST39103LCSUN9.0G 034A=20
9949862528 ready
monitoring 10 scsi devices ...
Thanks Andy , great work now displays all correctly. Only small garbage=20
when sometime run (look at first output). I now test sgsafte -d 0 -f and
it works !!! Turn on orange led instead of green led on enclosure. But=20
this turn on led on second half of enclosure too (on second processor).
Dan
--=20
Mydatex s r.o.
http://www.mydatex.cz
email: sm...@my...
mob: 604200362
tel: 226210085
|
|
From: Daniel S. <ma...@my...> - 2007-03-08 11:54:54
|
Cress, Andrew R napsal(a):
> Evan,
>
> That looks much better.
> The only anomaly in it, is that it tried to see if two proc's match serial number, and it shouldn't try.
> This is unusual that two of the same procs are in the same system, which is why I never had this problem before.
> Anyway, this latest sgsafte.c should work fine on your system now.
>
> If it still has some problems, send me the sgsafte -x log output again.
> If it works ok, let me know and I'll make sure these fixes are working in the other tools as well.
>
sgsafte utility v1.21 for SCSI SAF-TE testing
Num Name bus:ch:id:lun Type Vendor Device_Model FRev Serial#
Status
0 /dev/sg0 /dev/sda 1:0:8:0 Disk FUJITSU MAG3091L SUN9.0G 1111
9944498794?` rea
dy
1 /dev/sg1 /dev/sdb 1:0:9:0 Disk FUJITSU MAG3091L SUN9.0G 1111
9944499100?` rea
dy
2 /dev/sg2 /dev/sdc 1:0:10:0 Disk FUJITSU MAG3091L SUN9.0G 1111
9944499308?` re
ady
3 /dev/sg3 1:0:15:0 Proc SYMBIOS D1000 2 `'}
ready
4 /dev/sg4 /dev/sdd 2:0:8:0 Disk FUJITSU MAG3091L SUN9.0G 1111
9944498792 ready
5 /dev/sg5 /dev/sde 2:0:9:0 Disk FUJITSU MAG3091L SUN9.0G 1111
9944499149 ready
6 /dev/sg6 /dev/sdf 2:0:10:0 Disk FUJITSU MAG3091L SUN9.0G 1111
9944499314 read
y
7 /dev/sg7 2:0:15:0 Proc SYMBIOS D1000 2 `'}
ready
8 /dev/sg8 /dev/sdg 4:0:6:0 CDRM TOSHIBA XM6201TASUN32XCD 1103 12/12/97
ready
9 /dev/sg9 /dev/sdh 5:0:0:0 Disk SEAGATE ST39103LCSUN9.0G 034A
9949862528 ready
sgsafte utility v1.21 for SCSI SAF-TE testing
Num Name bus:ch:id:lun Type Vendor Device_Model FRev Serial#
Status
0 /dev/sg0 /dev/sda 1:0:8:0 Disk FUJITSU MAG3091L SUN9.0G 1111
9944498794 ready
1 /dev/sg1 /dev/sdb 1:0:9:0 Disk FUJITSU MAG3091L SUN9.0G 1111
9944499100 ready
2 /dev/sg2 /dev/sdc 1:0:10:0 Disk FUJITSU MAG3091L SUN9.0G 1111
9944499308 ready
3 /dev/sg3 1:0:15:0 Proc SYMBIOS D1000 2 `'}
ready
4 /dev/sg4 /dev/sdd 2:0:8:0 Disk FUJITSU MAG3091L SUN9.0G 1111
9944498792 ready
5 /dev/sg5 /dev/sde 2:0:9:0 Disk FUJITSU MAG3091L SUN9.0G 1111
9944499149 ready
6 /dev/sg6 /dev/sdf 2:0:10:0 Disk FUJITSU MAG3091L SUN9.0G 1111
9944499314 ready
7 /dev/sg7 2:0:15:0 Proc SYMBIOS D1000 2 `'}
ready
8 /dev/sg8 /dev/sdg 4:0:6:0 CDRM TOSHIBA XM6201TASUN32XCD 1103 12/12/97
ready
9 /dev/sg9 /dev/sdh 5:0:0:0 Disk SEAGATE ST39103LCSUN9.0G 034A
9949862528 ready
monitoring 10 scsi devices ...
Thanks Andy , great work now displays all correctly. Only small garbage
when sometime run (look at first output). I now test sgsafte -d 0 -f and
it works !!! Turn on orange led instead of green led on enclosure. But
this turn on led on second half of enclosure too (on second processor).
Dan
--
Mydatex s r.o.
http://www.mydatex.cz
email: sm...@my...
mob: 604200362
tel: 226210085
|
|
From: Daniel S. <ma...@my...> - 2007-03-07 22:00:08
|
Cress, Andrew R napsal(a): > Evan, >=20 > That looks much better. > The only anomaly in it, is that it tried to see if two proc's match ser= ial number, and it shouldn't try. > This is unusual that two of the same procs are in the same system, whic= h is why I never had this problem before. > Anyway, this latest sgsafte.c should work fine on your system now. >=20 > If it still has some problems, send me the sgsafte -x log output again.= > If it works ok, let me know and I'll make sure these fixes are working = in the other tools as well. >=20 Many thanks I test this tomorow. I change on e450 kernel and machine now = doesn't boot :-) Dan > Andy=20 >=20 > -----Original Message----- > From: Daniel Smolik [mailto:ma...@my...]=20 > Sent: Wednesday, March 07, 2007 4:31 PM > To: Cress, Andrew R; scs...@li... > Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) >=20 > Cress, Andrew R napsal(a): >=20 >>Dan, >> >>I put more mods into sgsafte.c. >>Please try this and send me the sgsafte -x output. >> >=20 > Yes here is. >=20 > Dan >=20 > PS: my SVN revision is 8 >=20 >=20 >=20 >>Andy=20 >> >>-----Original Message----- >>From: Daniel Smolik [mailto:ma...@my...]=20 >>Sent: Wednesday, March 07, 2007 3:54 PM >>To: Cress, Andrew R >>Cc: scs...@li... >>Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) >> >>Cress, Andrew R napsal(a): >> >> >>>Dan, >>> >>>I think it needs 4 more bytes of serial number data, so I added that >>>assumption to the fix.=20 >>>I think the Proc isn't being recognized because of non-ASCII character= s >>>in the inquiry string, so I added more debug to show if that has >>>happened. >>>If so, I'm not sure what to do to work around that, but let's find out= >>>if that is the problem first. =20 >>> >>>I checked an updated sgsafte.c into the SVN trunk, and it compiles/run= s >>>here. >>>Let me know how this looks. =20 >> >> >>Again better. Disk are propertly rekognized. Second Processor still=20 >>nothing. But string that you get via inquiry is the same as the first=20 >>processor and it's recognized. >> >> >> >> >> >> >>0 /dev/sg0 /dev/sda 1:0:8:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20 >>9944498794 ready >>1 /dev/sg1 /dev/sdb 1:0:9:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20 >>9944499100 ready >>2 /dev/sg2 /dev/sdc 1:0:10:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20 >>9944499308 ready >>3 /dev/sg3 1:0:15:0 Proc SYMBIOS D1000 2 `'} >> ^^^^^^^^^^^^^ no= n=20 >>asci char. and corectly displayed >>ready >> >> >>4 /dev/sg4 /dev/sdd 2:0:8:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20 >>9944498792=C0=C0 ready >>5 /dev/sg5 /dev/sde 2:0:9:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20 >>9944499149=C0=C0 ready >>6 /dev/sg6 /dev/sdf 2:0:10:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20 >>9944499314=C0=C0 ready >> ^^ some nensense characters (too log string ?) >> >> >>7 /dev/sg7 /dev/sdg 2:0:15:0 Disk >>the same non ascii and not detected ? >> >> failed >>8 /dev/sg8 /dev/sdg 4:0:6:0 CDRM TOSHIBA XM6201TASUN32XCD 1103 12/12/9= 7=20 >>ready >>9 /dev/sg9 /dev/sdh 5:0:0:0 Disk SEAGATE ST39103LCSUN9.0G 034A=20 >>9949862528 ready >> >> >>scsiinfo -i /dev/sg3 >>Relative Address 0 >>Wide bus 32 0 >>Wide bus 16 0 >>Synchronous neg. 0 >>Linked Commands 0 >>Command Queueing 0 >>SftRe 0 >>Device Type 3 >>Peripheral Qualifier 0 >>Removable? 0 >>Device Type Modifier 0 >>ISO Version 0 >>ECMA Version 0 >>ANSI Version 2 >>AENC 0 >>TrmIOP 0 >>Response Data Format 2 >>Vendor: SYMBIOS >>Product: D1000 >>Revision level: 2 `'}=20 >>SAF-TE1.00=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0= =C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0= =C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0= =C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0= =C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0= =C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0= =C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0= =C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0= =C0=C0=C0=C0=C0=B2 >> >> >>scsiinfo -i /dev/sg0 >> >> >> >> >>Inquiry command >>--------------- >>Relative Address 0 >>Wide bus 32 0 >>Wide bus 16 1 >>Synchronous neg. 1 >>Linked Commands 1 >>Command Queueing 1 >>SftRe 0 >>Device Type 0 >>Peripheral Qualifier 0 >>Removable? 0 >>Device Type Modifier 0 >>ISO Version 0 >>ECMA Version 0 >>ANSI Version 2 >>AENC 0 >>TrmIOP 1 >>Response Data Format 2 >>Vendor: FUJITSU >>Product: MAG3091L SUN9.0G >>Revision level: 11119944498794 >> >> >>when sgsafte -x >> >>on first half of case you redad correct name >>dev[0] iret=3D0, ret=3D0, len=3D48 1:0:8:0 /dev/sg0 /dev/sda FUJITSU MA= G3091L=20 >>SUN9.0G11119944498794 >> >>but when sgsafte -x on second half of case >> >>dev[6] iret=3D0, ret=3D0, len=3D48 2:0:10:0 /dev/sg6 /dev/sdf FUJITSU M= AG3091L=20 >>SUN9.0G11119944499314=C0=C0 >> ^^ >>inquiry ret=3D0, errno=3D2 >> >>Note: >>I don't know if you know something about Sun. >>But when i run probe-scsi-all from OPB (Sun BIOS) >>I can show you how Sun displayes disk and processor labels. >> >> >> >> >> >> >> >> >>/pci@6,4000/scsi@4=20 >>=20 >> >>Target 8=20 >>=20 >> >> Unit 0 Disk FUJITSU MAG3091L SUN9.0G1111994449879=20 >>=20 >> >>Target 9=20 >>=20 >> >> Unit 0 Disk FUJITSU MAG3091L SUN9.0G1111994449914=20 >>=20 >> >>Target a=20 >>=20 >> >> Unit 0 Disk FUJITSU MAG3091L SUN9.0G1111994449931=20 >>=20 >> >>Target f=20 >>=20 >> >> Unit 0 Processor SYMBIOS D1000 2 `'} SAF-TE1.0= =20 >>=20 >> >>=20 >>=20 >> >>/pci@6,4000/scsi@3,1=20 >>=20 >> >>Target 8=20 >>=20 >> >> Unit 0 Disk FUJITSU MAG3091L SUN9.0G1111994449879=20 >>=20 >> >>Target 9=20 >>=20 >> >> Unit 0 Disk FUJITSU MAG3091L SUN9.0G1111994449910=20 >>=20 >> >>Target a=20 >>=20 >> >> Unit 0 Disk FUJITSU MAG3091L SUN9.0G1111994449930=20 >>=20 >> >>Target f=20 >>=20 >> >> Unit 0 Processor SYMBIOS D1000 2 `'} SAF-TE1.0= =20 >>=20 >> >> >> >> >> >> >> Thanks >> Dan >> >> >> >> >> >> >> >> >> >> >> >=20 >=20 >=20 --=20 Mydatex s r.o. http://www.mydatex.cz email: sm...@my... mob: 604200362 tel: 226210085 |
|
From: Cress, A. R <and...@in...> - 2007-03-07 21:52:09
|
Evan, That looks much better. The only anomaly in it, is that it tried to see if two proc's match = serial number, and it shouldn't try. This is unusual that two of the same procs are in the same system, which = is why I never had this problem before. Anyway, this latest sgsafte.c should work fine on your system now. If it still has some problems, send me the sgsafte -x log output again. If it works ok, let me know and I'll make sure these fixes are working = in the other tools as well. Andy=20 -----Original Message----- From: Daniel Smolik [mailto:ma...@my...]=20 Sent: Wednesday, March 07, 2007 4:31 PM To: Cress, Andrew R; scs...@li... Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) Cress, Andrew R napsal(a): > Dan, >=20 > I put more mods into sgsafte.c. > Please try this and send me the sgsafte -x output. >=20 Yes here is. Dan PS: my SVN revision is 8 > Andy=20 >=20 > -----Original Message----- > From: Daniel Smolik [mailto:ma...@my...]=20 > Sent: Wednesday, March 07, 2007 3:54 PM > To: Cress, Andrew R > Cc: scs...@li... > Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) >=20 > Cress, Andrew R napsal(a): >=20 >>Dan, >> >>I think it needs 4 more bytes of serial number data, so I added that >>assumption to the fix.=20 >>I think the Proc isn't being recognized because of non-ASCII = characters >>in the inquiry string, so I added more debug to show if that has >>happened. >>If so, I'm not sure what to do to work around that, but let's find out >>if that is the problem first. =20 >> >>I checked an updated sgsafte.c into the SVN trunk, and it = compiles/runs >>here. >>Let me know how this looks. =20 >=20 >=20 > Again better. Disk are propertly rekognized. Second Processor still=20 > nothing. But string that you get via inquiry is the same as the first=20 > processor and it's recognized. >=20 >=20 >=20 >=20 >=20 >=20 > 0 /dev/sg0 /dev/sda 1:0:8:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20 > 9944498794 ready > 1 /dev/sg1 /dev/sdb 1:0:9:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20 > 9944499100 ready > 2 /dev/sg2 /dev/sdc 1:0:10:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20 > 9944499308 ready > 3 /dev/sg3 1:0:15:0 Proc SYMBIOS D1000 2 `'} > ^^^^^^^^^^^^^ = non=20 > asci char. and corectly displayed > ready >=20 >=20 > 4 /dev/sg4 /dev/sdd 2:0:8:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20 > 9944498792=C0=C0 ready > 5 /dev/sg5 /dev/sde 2:0:9:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20 > 9944499149=C0=C0 ready > 6 /dev/sg6 /dev/sdf 2:0:10:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20 > 9944499314=C0=C0 ready > ^^ some nensense characters (too log string ?) >=20 >=20 > 7 /dev/sg7 /dev/sdg 2:0:15:0 Disk > the same non ascii and not detected ? >=20 > failed > 8 /dev/sg8 /dev/sdg 4:0:6:0 CDRM TOSHIBA XM6201TASUN32XCD 1103 = 12/12/97=20 > ready > 9 /dev/sg9 /dev/sdh 5:0:0:0 Disk SEAGATE ST39103LCSUN9.0G 034A=20 > 9949862528 ready >=20 >=20 > scsiinfo -i /dev/sg3 > Relative Address 0 > Wide bus 32 0 > Wide bus 16 0 > Synchronous neg. 0 > Linked Commands 0 > Command Queueing 0 > SftRe 0 > Device Type 3 > Peripheral Qualifier 0 > Removable? 0 > Device Type Modifier 0 > ISO Version 0 > ECMA Version 0 > ANSI Version 2 > AENC 0 > TrmIOP 0 > Response Data Format 2 > Vendor: SYMBIOS > Product: D1000 > Revision level: 2 `'}=20 > = SAF-TE1.00=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0= =C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0= =C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0= =C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0= =C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0= =C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0= =C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0= =C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0= =C0=C0=C0=C0=C0=B2 >=20 >=20 > scsiinfo -i /dev/sg0 >=20 >=20 >=20 >=20 > Inquiry command > --------------- > Relative Address 0 > Wide bus 32 0 > Wide bus 16 1 > Synchronous neg. 1 > Linked Commands 1 > Command Queueing 1 > SftRe 0 > Device Type 0 > Peripheral Qualifier 0 > Removable? 0 > Device Type Modifier 0 > ISO Version 0 > ECMA Version 0 > ANSI Version 2 > AENC 0 > TrmIOP 1 > Response Data Format 2 > Vendor: FUJITSU > Product: MAG3091L SUN9.0G > Revision level: 11119944498794 >=20 >=20 > when sgsafte -x >=20 > on first half of case you redad correct name > dev[0] iret=3D0, ret=3D0, len=3D48 1:0:8:0 /dev/sg0 /dev/sda FUJITSU = MAG3091L=20 > SUN9.0G11119944498794 >=20 > but when sgsafte -x on second half of case >=20 > dev[6] iret=3D0, ret=3D0, len=3D48 2:0:10:0 /dev/sg6 /dev/sdf FUJITSU = MAG3091L=20 > SUN9.0G11119944499314=C0=C0 > ^^ > inquiry ret=3D0, errno=3D2 >=20 > Note: > I don't know if you know something about Sun. > But when i run probe-scsi-all from OPB (Sun BIOS) > I can show you how Sun displayes disk and processor labels. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > /pci@6,4000/scsi@4=20 > =20 >=20 > Target 8=20 > =20 >=20 > Unit 0 Disk FUJITSU MAG3091L SUN9.0G1111994449879=20 > =20 >=20 > Target 9=20 > =20 >=20 > Unit 0 Disk FUJITSU MAG3091L SUN9.0G1111994449914=20 > =20 >=20 > Target a=20 > =20 >=20 > Unit 0 Disk FUJITSU MAG3091L SUN9.0G1111994449931=20 > =20 >=20 > Target f=20 > =20 >=20 > Unit 0 Processor SYMBIOS D1000 2 `'} = SAF-TE1.0=20 > =20 >=20 > =20 > =20 >=20 > /pci@6,4000/scsi@3,1=20 > =20 >=20 > Target 8=20 > =20 >=20 > Unit 0 Disk FUJITSU MAG3091L SUN9.0G1111994449879=20 > =20 >=20 > Target 9=20 > =20 >=20 > Unit 0 Disk FUJITSU MAG3091L SUN9.0G1111994449910=20 > =20 >=20 > Target a=20 > =20 >=20 > Unit 0 Disk FUJITSU MAG3091L SUN9.0G1111994449930=20 > =20 >=20 > Target f=20 > =20 >=20 > Unit 0 Processor SYMBIOS D1000 2 `'} = SAF-TE1.0=20 > =20 >=20 >=20 >=20 >=20 >=20 >=20 > Thanks > Dan >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 --=20 Mydatex s r.o. http://www.mydatex.cz email: sm...@my... mob: 604200362 tel: 226210085 |
|
From: Daniel S. <ma...@my...> - 2007-03-07 21:31:11
|
Cress, Andrew R napsal(a): > Dan, >=20 > I put more mods into sgsafte.c. > Please try this and send me the sgsafte -x output. >=20 Yes here is. Dan PS: my SVN revision is 8 > Andy=20 >=20 > -----Original Message----- > From: Daniel Smolik [mailto:ma...@my...]=20 > Sent: Wednesday, March 07, 2007 3:54 PM > To: Cress, Andrew R > Cc: scs...@li... > Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) >=20 > Cress, Andrew R napsal(a): >=20 >>Dan, >> >>I think it needs 4 more bytes of serial number data, so I added that >>assumption to the fix.=20 >>I think the Proc isn't being recognized because of non-ASCII characters= >>in the inquiry string, so I added more debug to show if that has >>happened. >>If so, I'm not sure what to do to work around that, but let's find out >>if that is the problem first. =20 >> >>I checked an updated sgsafte.c into the SVN trunk, and it compiles/runs= >>here. >>Let me know how this looks. =20 >=20 >=20 > Again better. Disk are propertly rekognized. Second Processor still=20 > nothing. But string that you get via inquiry is the same as the first=20 > processor and it's recognized. >=20 >=20 >=20 >=20 >=20 >=20 > 0 /dev/sg0 /dev/sda 1:0:8:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20 > 9944498794 ready > 1 /dev/sg1 /dev/sdb 1:0:9:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20 > 9944499100 ready > 2 /dev/sg2 /dev/sdc 1:0:10:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20 > 9944499308 ready > 3 /dev/sg3 1:0:15:0 Proc SYMBIOS D1000 2 `'} > ^^^^^^^^^^^^^ no= n=20 > asci char. and corectly displayed > ready >=20 >=20 > 4 /dev/sg4 /dev/sdd 2:0:8:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20 > 9944498792=C0=C0 ready > 5 /dev/sg5 /dev/sde 2:0:9:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20 > 9944499149=C0=C0 ready > 6 /dev/sg6 /dev/sdf 2:0:10:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20 > 9944499314=C0=C0 ready > ^^ some nensense characters (too log string ?) >=20 >=20 > 7 /dev/sg7 /dev/sdg 2:0:15:0 Disk > the same non ascii and not detected ? >=20 > failed > 8 /dev/sg8 /dev/sdg 4:0:6:0 CDRM TOSHIBA XM6201TASUN32XCD 1103 12/12/9= 7=20 > ready > 9 /dev/sg9 /dev/sdh 5:0:0:0 Disk SEAGATE ST39103LCSUN9.0G 034A=20 > 9949862528 ready >=20 >=20 > scsiinfo -i /dev/sg3 > Relative Address 0 > Wide bus 32 0 > Wide bus 16 0 > Synchronous neg. 0 > Linked Commands 0 > Command Queueing 0 > SftRe 0 > Device Type 3 > Peripheral Qualifier 0 > Removable? 0 > Device Type Modifier 0 > ISO Version 0 > ECMA Version 0 > ANSI Version 2 > AENC 0 > TrmIOP 0 > Response Data Format 2 > Vendor: SYMBIOS > Product: D1000 > Revision level: 2 `'}=20 > SAF-TE1.00=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0= =C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0= =C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0= =C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0= =C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0= =C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0= =C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0= =C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0= =C0=C0=C0=C0=C0=B2 >=20 >=20 > scsiinfo -i /dev/sg0 >=20 >=20 >=20 >=20 > Inquiry command > --------------- > Relative Address 0 > Wide bus 32 0 > Wide bus 16 1 > Synchronous neg. 1 > Linked Commands 1 > Command Queueing 1 > SftRe 0 > Device Type 0 > Peripheral Qualifier 0 > Removable? 0 > Device Type Modifier 0 > ISO Version 0 > ECMA Version 0 > ANSI Version 2 > AENC 0 > TrmIOP 1 > Response Data Format 2 > Vendor: FUJITSU > Product: MAG3091L SUN9.0G > Revision level: 11119944498794 >=20 >=20 > when sgsafte -x >=20 > on first half of case you redad correct name > dev[0] iret=3D0, ret=3D0, len=3D48 1:0:8:0 /dev/sg0 /dev/sda FUJITSU MA= G3091L=20 > SUN9.0G11119944498794 >=20 > but when sgsafte -x on second half of case >=20 > dev[6] iret=3D0, ret=3D0, len=3D48 2:0:10:0 /dev/sg6 /dev/sdf FUJITSU M= AG3091L=20 > SUN9.0G11119944499314=C0=C0 > ^^ > inquiry ret=3D0, errno=3D2 >=20 > Note: > I don't know if you know something about Sun. > But when i run probe-scsi-all from OPB (Sun BIOS) > I can show you how Sun displayes disk and processor labels. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > /pci@6,4000/scsi@4=20 > =20 >=20 > Target 8=20 > =20 >=20 > Unit 0 Disk FUJITSU MAG3091L SUN9.0G1111994449879=20 > =20 >=20 > Target 9=20 > =20 >=20 > Unit 0 Disk FUJITSU MAG3091L SUN9.0G1111994449914=20 > =20 >=20 > Target a=20 > =20 >=20 > Unit 0 Disk FUJITSU MAG3091L SUN9.0G1111994449931=20 > =20 >=20 > Target f=20 > =20 >=20 > Unit 0 Processor SYMBIOS D1000 2 `'} SAF-TE1.0= =20 > =20 >=20 > =20 > =20 >=20 > /pci@6,4000/scsi@3,1=20 > =20 >=20 > Target 8=20 > =20 >=20 > Unit 0 Disk FUJITSU MAG3091L SUN9.0G1111994449879=20 > =20 >=20 > Target 9=20 > =20 >=20 > Unit 0 Disk FUJITSU MAG3091L SUN9.0G1111994449910=20 > =20 >=20 > Target a=20 > =20 >=20 > Unit 0 Disk FUJITSU MAG3091L SUN9.0G1111994449930=20 > =20 >=20 > Target f=20 > =20 >=20 > Unit 0 Processor SYMBIOS D1000 2 `'} SAF-TE1.0= =20 > =20 >=20 >=20 >=20 >=20 >=20 >=20 > Thanks > Dan >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 --=20 Mydatex s r.o. http://www.mydatex.cz email: sm...@my... mob: 604200362 tel: 226210085 |
|
From: Cress, A. R <and...@in...> - 2007-03-07 21:17:38
|
Dan,
I put more mods into sgsafte.c.
Please try this and send me the sgsafte -x output.
Andy=20
-----Original Message-----
From: Daniel Smolik [mailto:ma...@my...]=20
Sent: Wednesday, March 07, 2007 3:54 PM
To: Cress, Andrew R
Cc: scs...@li...
Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives)
Cress, Andrew R napsal(a):
> Dan,
>=20
> I think it needs 4 more bytes of serial number data, so I added that
> assumption to the fix.=20
> I think the Proc isn't being recognized because of non-ASCII =
characters
> in the inquiry string, so I added more debug to show if that has
> happened.
> If so, I'm not sure what to do to work around that, but let's find out
> if that is the problem first. =20
>=20
> I checked an updated sgsafte.c into the SVN trunk, and it =
compiles/runs
> here.
> Let me know how this looks. =20
Again better. Disk are propertly rekognized. Second Processor still=20
nothing. But string that you get via inquiry is the same as the first=20
processor and it's recognized.
0 /dev/sg0 /dev/sda 1:0:8:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20
9944498794 ready
1 /dev/sg1 /dev/sdb 1:0:9:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20
9944499100 ready
2 /dev/sg2 /dev/sdc 1:0:10:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20
9944499308 ready
3 /dev/sg3 1:0:15:0 Proc SYMBIOS D1000 2 `'}
^^^^^^^^^^^^^ non =
asci char. and corectly displayed
ready
4 /dev/sg4 /dev/sdd 2:0:8:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20
9944498792=C0=C0 ready
5 /dev/sg5 /dev/sde 2:0:9:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20
9944499149=C0=C0 ready
6 /dev/sg6 /dev/sdf 2:0:10:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20
9944499314=C0=C0 ready
^^ some nensense characters (too log string ?)
7 /dev/sg7 /dev/sdg 2:0:15:0 Disk
the same non ascii and not detected ?
failed
8 /dev/sg8 /dev/sdg 4:0:6:0 CDRM TOSHIBA XM6201TASUN32XCD 1103 12/12/97 =
ready
9 /dev/sg9 /dev/sdh 5:0:0:0 Disk SEAGATE ST39103LCSUN9.0G 034A=20
9949862528 ready
scsiinfo -i /dev/sg3
Relative Address 0
Wide bus 32 0
Wide bus 16 0
Synchronous neg. 0
Linked Commands 0
Command Queueing 0
SftRe 0
Device Type 3
Peripheral Qualifier 0
Removable? 0
Device Type Modifier 0
ISO Version 0
ECMA Version 0
ANSI Version 2
AENC 0
TrmIOP 0
Response Data Format 2
Vendor: SYMBIOS
Product: D1000
Revision level: 2 `'}=20
SAF-TE1.00=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=
=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=
=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=
=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=
=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=
=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=
=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=
=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=
=C0=C0=C0=C0=C0=B2
scsiinfo -i /dev/sg0
Inquiry command
---------------
Relative Address 0
Wide bus 32 0
Wide bus 16 1
Synchronous neg. 1
Linked Commands 1
Command Queueing 1
SftRe 0
Device Type 0
Peripheral Qualifier 0
Removable? 0
Device Type Modifier 0
ISO Version 0
ECMA Version 0
ANSI Version 2
AENC 0
TrmIOP 1
Response Data Format 2
Vendor: FUJITSU
Product: MAG3091L SUN9.0G
Revision level: 11119944498794
when sgsafte -x
on first half of case you redad correct name
dev[0] iret=3D0, ret=3D0, len=3D48 1:0:8:0 /dev/sg0 /dev/sda FUJITSU =
MAG3091L=20
SUN9.0G11119944498794
but when sgsafte -x on second half of case
dev[6] iret=3D0, ret=3D0, len=3D48 2:0:10:0 /dev/sg6 /dev/sdf FUJITSU =
MAG3091L=20
SUN9.0G11119944499314=C0=C0
^^
inquiry ret=3D0, errno=3D2
Note:
I don't know if you know something about Sun.
But when i run probe-scsi-all from OPB (Sun BIOS)
I can show you how Sun displayes disk and processor labels.
/pci@6,4000/scsi@4=20
=20
Target 8=20
=20
Unit 0 Disk FUJITSU MAG3091L SUN9.0G1111994449879=20
=20
Target 9=20
=20
Unit 0 Disk FUJITSU MAG3091L SUN9.0G1111994449914=20
=20
Target a=20
=20
Unit 0 Disk FUJITSU MAG3091L SUN9.0G1111994449931=20
=20
Target f=20
=20
Unit 0 Processor SYMBIOS D1000 2 `'} SAF-TE1.0=20
=20
=20
=20
/pci@6,4000/scsi@3,1=20
=20
Target 8=20
=20
Unit 0 Disk FUJITSU MAG3091L SUN9.0G1111994449879=20
=20
Target 9=20
=20
Unit 0 Disk FUJITSU MAG3091L SUN9.0G1111994449910=20
=20
Target a=20
=20
Unit 0 Disk FUJITSU MAG3091L SUN9.0G1111994449930=20
=20
Target f=20
=20
Unit 0 Processor SYMBIOS D1000 2 `'} SAF-TE1.0=20
=20
Thanks
Dan
|
|
From: Daniel S. <ma...@my...> - 2007-03-07 20:54:22
|
Cress, Andrew R napsal(a):
> Dan,
>=20
> I think it needs 4 more bytes of serial number data, so I added that
> assumption to the fix.=20
> I think the Proc isn't being recognized because of non-ASCII characters=
> in the inquiry string, so I added more debug to show if that has
> happened.
> If so, I'm not sure what to do to work around that, but let's find out
> if that is the problem first. =20
>=20
> I checked an updated sgsafte.c into the SVN trunk, and it compiles/runs=
> here.
> Let me know how this looks. =20
Again better. Disk are propertly rekognized. Second Processor still=20
nothing. But string that you get via inquiry is the same as the first=20
processor and it's recognized.
0 /dev/sg0 /dev/sda 1:0:8:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20
9944498794 ready
1 /dev/sg1 /dev/sdb 1:0:9:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20
9944499100 ready
2 /dev/sg2 /dev/sdc 1:0:10:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20
9944499308 ready
3 /dev/sg3 1:0:15:0 Proc SYMBIOS D1000 2 `'}
^^^^^^^^^^^^^ non =
asci char. and corectly displayed
ready
4 /dev/sg4 /dev/sdd 2:0:8:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20
9944498792=C0=C0 ready
5 /dev/sg5 /dev/sde 2:0:9:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20
9944499149=C0=C0 ready
6 /dev/sg6 /dev/sdf 2:0:10:0 Disk FUJITSU MAG3091L SUN9.0G 1111=20
9944499314=C0=C0 ready
^^ some nensense characters (too log string ?)
7 /dev/sg7 /dev/sdg 2:0:15:0 Disk
the same non ascii and not detected ?
failed
8 /dev/sg8 /dev/sdg 4:0:6:0 CDRM TOSHIBA XM6201TASUN32XCD 1103 12/12/97 =
ready
9 /dev/sg9 /dev/sdh 5:0:0:0 Disk SEAGATE ST39103LCSUN9.0G 034A=20
9949862528 ready
scsiinfo -i /dev/sg3
Relative Address 0
Wide bus 32 0
Wide bus 16 0
Synchronous neg. 0
Linked Commands 0
Command Queueing 0
SftRe 0
Device Type 3
Peripheral Qualifier 0
Removable? 0
Device Type Modifier 0
ISO Version 0
ECMA Version 0
ANSI Version 2
AENC 0
TrmIOP 0
Response Data Format 2
Vendor: SYMBIOS
Product: D1000
Revision level: 2 `'}=20
SAF-TE1.00=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=
=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=
=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=
=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=
=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=
=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=
=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=
=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=C0=
=C0=C0=C0=C0=C0=B2
scsiinfo -i /dev/sg0
Inquiry command
---------------
Relative Address 0
Wide bus 32 0
Wide bus 16 1
Synchronous neg. 1
Linked Commands 1
Command Queueing 1
SftRe 0
Device Type 0
Peripheral Qualifier 0
Removable? 0
Device Type Modifier 0
ISO Version 0
ECMA Version 0
ANSI Version 2
AENC 0
TrmIOP 1
Response Data Format 2
Vendor: FUJITSU
Product: MAG3091L SUN9.0G
Revision level: 11119944498794
when sgsafte -x
on first half of case you redad correct name
dev[0] iret=3D0, ret=3D0, len=3D48 1:0:8:0 /dev/sg0 /dev/sda FUJITSU MAG3=
091L=20
SUN9.0G11119944498794
but when sgsafte -x on second half of case
dev[6] iret=3D0, ret=3D0, len=3D48 2:0:10:0 /dev/sg6 /dev/sdf FUJITSU MAG=
3091L=20
SUN9.0G11119944499314=C0=C0
^^
inquiry ret=3D0, errno=3D2
Note:
I don't know if you know something about Sun.
But when i run probe-scsi-all from OPB (Sun BIOS)
I can show you how Sun displayes disk and processor labels.
/pci@6,4000/scsi@4=20
=20
Target 8=20
=20
Unit 0 Disk FUJITSU MAG3091L SUN9.0G1111994449879=20
=20
Target 9=20
=20
Unit 0 Disk FUJITSU MAG3091L SUN9.0G1111994449914=20
=20
Target a=20
=20
Unit 0 Disk FUJITSU MAG3091L SUN9.0G1111994449931=20
=20
Target f=20
=20
Unit 0 Processor SYMBIOS D1000 2 `'} SAF-TE1.0=20
=20
=20
=20
/pci@6,4000/scsi@3,1=20
=20
Target 8=20
=20
Unit 0 Disk FUJITSU MAG3091L SUN9.0G1111994449879=20
=20
Target 9=20
=20
Unit 0 Disk FUJITSU MAG3091L SUN9.0G1111994449910=20
=20
Target a=20
=20
Unit 0 Disk FUJITSU MAG3091L SUN9.0G1111994449930=20
=20
Target f=20
=20
Unit 0 Processor SYMBIOS D1000 2 `'} SAF-TE1.0=20
=20
Thanks
Dan
|
|
From: Cress, A. R <and...@in...> - 2007-03-07 20:13:26
|
Dan, I think it needs 4 more bytes of serial number data, so I added that assumption to the fix.=20 I think the Proc isn't being recognized because of non-ASCII characters in the inquiry string, so I added more debug to show if that has happened. If so, I'm not sure what to do to work around that, but let's find out if that is the problem first. =20 I checked an updated sgsafte.c into the SVN trunk, and it compiles/runs here. Let me know how this looks. =20 Andy=20 -----Original Message----- From: scs...@li... [mailto:scs...@li...] On Behalf Of Daniel Smolik Sent: Monday, March 05, 2007 3:22 PM To: Cress, Andrew R Cc: scs...@li... Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) Cress, Andrew R napsal(a): > Sorry, a bit too fast there. =20 > It compiles and runs now. >=20 > Andy=20 >=20 > -----Original Message----- > From: Daniel Smolik [mailto:ma...@my...]=20 > Sent: Monday, March 05, 2007 3:09 PM > To: Cress, Andrew R > Cc: scs...@li... > Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) >=20 > Cress, Andrew R napsal(a): >=20 >>Yes, try sgsafte.c from SVN. >> >>Andy=20 >> >=20 > Thanks Andy, but sgafte.c don't compile. I sync my SVN with trung. See > atached log :-(. >=20 > Dan Thanks :-) Its now better but still not detetct second Porcessor and 3=20 Fujitsu disk on second half on enclosure. New log. Output of sgsafte. Dan |
|
From: Daniel S. <ma...@my...> - 2007-03-05 20:22:17
|
Cress, Andrew R napsal(a): > Sorry, a bit too fast there. > It compiles and runs now. > > Andy > > -----Original Message----- > From: Daniel Smolik [mailto:ma...@my...] > Sent: Monday, March 05, 2007 3:09 PM > To: Cress, Andrew R > Cc: scs...@li... > Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) > > Cress, Andrew R napsal(a): > >>Yes, try sgsafte.c from SVN. >> >>Andy >> > > Thanks Andy, but sgafte.c don't compile. I sync my SVN with trung. See > atached log :-(. > > Dan Thanks :-) Its now better but still not detetct second Porcessor and 3 Fujitsu disk on second half on enclosure. New log. Output of sgsafte. Dan |
7 messages has been excluded from this view by a project administrator.
