scsirastools-developers Mailing List for scsirastools (Page 3)
Brought to you by:
arcress
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-03-05 20:15:31
|
Sorry, a bit too fast there. =20 It compiles and runs now. Andy=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) Cress, Andrew R napsal(a): > Yes, try sgsafte.c from SVN. >=20 > Andy=20 >=20 Thanks Andy, but sgafte.c don't compile. I sync my SVN with trung. See=20 atached log :-(. Dan |
From: Daniel S. <ma...@my...> - 2007-03-05 20:09:16
|
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 |
From: Cress, A. R <and...@in...> - 2007-03-05 19:45:26
|
Yes, try sgsafte.c from SVN. Andy=20 -----Original Message----- From: Daniel Smolik [mailto:ma...@my...]=20 Sent: Monday, March 05, 2007 1:37 PM To: Cress, Andrew R Cc: scs...@li... Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) Cress, Andrew R napsal(a): > Oops, sorry. That's a slang term. A wart in the code would be a = small piece that is attached, but doesn't belong there. :-) > In this case, it is just one line with an if condition. =20 >=20 Something new in SVN I am ready for testing :-) Many thanks Dan > Andy=20 >=20 > -----Original Message----- > From: scs...@li... = [mailto:scs...@li...] On Behalf = Of Daniel Smolik > Sent: Tuesday, February 27, 2007 2:25 AM > Cc: scs...@li... > Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) >=20 > Cress, Andrew R napsal(a): >=20 >>Daniel >> >>I see the problem now. >>The SCSI Inquiry of the Fujitsu disks reports the inquiry length of 41 = when actually the length of the inquiry data returned was 62. 44 bytes = would be enough to catch the serial number. =20 >> >>Hmmm. =20 >>I think I'll put in a wart to account for this disk firmware error. =20 >=20 > Sorry Andy, > but I don't uderstand your last sentence. Do you mean that you put = some > warn to code about this firmware error ? Sorry my English is not = perfect :) >=20 > Dan >=20 >=20 >=20 >=20 >>Andy >> >>-----Original Message----- >>From: scs...@li... = [mailto:scs...@li...] On Behalf = Of Cress, Andrew R >>Sent: Monday, February 26, 2007 9:06 AM >>To: Daniel Smolik >>Cc: scs...@li... >>Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) >> >>Well, then this must be a bug in my scsi code, if other tools can get = the rest of the serial number. Hmmm. >>Let me study this with your sgsafte.log again more thoroughly. =20 >> >>Andy >> >>-----Original Message----- >>From: scs...@li... = [mailto:scs...@li...] On Behalf = Of Daniel Smolik >>Sent: Friday, February 23, 2007 5:47 PM >>Cc: scs...@li...; Cress, Andrew R >>Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) >> >>Daniel Smolik napsal(a): >> >> >>>Cress, Andrew R napsal(a): >>> >>> >>> >>>>Daniel, >>>> >>>>All of your Fujitsu drives report the same thing from the SCSI = inquiry: >>>> FUJITSU MAG3091L SUN9.0G 1111 99444 >>>>There are really only 5 bytes of serial number data (99444) returned >>> >>>>from the drive. That's just wrong. The other drives look fine, = though. >>> >>> >>>>It looks like the model number and stuff were modified by Sun after >>>>Fujitsu manufactured the disks. This is a problem that Sun should = be >>>>able to fix by putting unique serial numbers on the disks, as = required >>>>by the SCSI standard. >>>>They may even be able to supply some tool to modify it on-site (?). >>>> >>> >>>Hm, interested I try remove all Fujitsu disk and use only one Seagate = >>>and one Fujitsu and see if it helps. I aslo try find some too to = change=20 >>>serial number. >>> >> >>I didn't found any tool :-) But tehere is outpu of inq. command = scsiinfo=20 >>/dev/sda >> >>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: 11119944498792=F7=BFF ir >> >> >> >>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: 11119944499149 >> >> >>And you see that number are differ or not ? >> >> >> Dan >> >> >> >> >> >> >> >> >> >> >> >>-----------------------------------------------------------------------= -- >>Take Surveys. Earn Cash. Influence the Future of IT >>Join SourceForge.net's Techsay panel and you'll get the chance to = shareyour >>opinions on IT & business topics through brief surveys-and earn cash >>http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV >>_______________________________________________ >>Scsirastools-developers mailing list >>Scs...@li... >>https://lists.sourceforge.net/lists/listinfo/scsirastools-developers >> >>-----------------------------------------------------------------------= -- >>Take Surveys. Earn Cash. Influence the Future of IT >>Join SourceForge.net's Techsay panel and you'll get the chance to = shareyour >>opinions on IT & business topics through brief surveys-and earn cash >>http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV >>_______________________________________________ >>Scsirastools-developers mailing list >>Scs...@li... >>https://lists.sourceforge.net/lists/listinfo/scsirastools-developers >=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-05 18:37:24
|
Cress, Andrew R napsal(a): > Oops, sorry. That's a slang term. A wart in the code would be a small= piece that is attached, but doesn't belong there. :-) > In this case, it is just one line with an if condition. =20 >=20 Something new in SVN I am ready for testing :-) Many thanks Dan > Andy=20 >=20 > -----Original Message----- > From: scs...@li... [mailto:scs= ira...@li...] On Behalf Of Daniel S= molik > Sent: Tuesday, February 27, 2007 2:25 AM > Cc: scs...@li... > Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) >=20 > Cress, Andrew R napsal(a): >=20 >>Daniel >> >>I see the problem now. >>The SCSI Inquiry of the Fujitsu disks reports the inquiry length of 41 = when actually the length of the inquiry data returned was 62. 44 bytes = would be enough to catch the serial number. =20 >> >>Hmmm. =20 >>I think I'll put in a wart to account for this disk firmware error. =20 >=20 > Sorry Andy, > but I don't uderstand your last sentence. Do you mean that you put some= > warn to code about this firmware error ? Sorry my English is not perfec= t :) >=20 > Dan >=20 >=20 >=20 >=20 >>Andy >> >>-----Original Message----- >>From: scs...@li... [mailto:scs= ira...@li...] On Behalf Of Cress, A= ndrew R >>Sent: Monday, February 26, 2007 9:06 AM >>To: Daniel Smolik >>Cc: scs...@li... >>Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) >> >>Well, then this must be a bug in my scsi code, if other tools can get t= he rest of the serial number. Hmmm. >>Let me study this with your sgsafte.log again more thoroughly. =20 >> >>Andy >> >>-----Original Message----- >>From: scs...@li... [mailto:scs= ira...@li...] On Behalf Of Daniel S= molik >>Sent: Friday, February 23, 2007 5:47 PM >>Cc: scs...@li...; Cress, Andrew R >>Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) >> >>Daniel Smolik napsal(a): >> >> >>>Cress, Andrew R napsal(a): >>> >>> >>> >>>>Daniel, >>>> >>>>All of your Fujitsu drives report the same thing from the SCSI inquir= y: >>>> FUJITSU MAG3091L SUN9.0G 1111 99444 >>>>There are really only 5 bytes of serial number data (99444) returned >>> >>>>from the drive. That's just wrong. The other drives look fine, thou= gh. >>> >>> >>>>It looks like the model number and stuff were modified by Sun after >>>>Fujitsu manufactured the disks. This is a problem that Sun should be= >>>>able to fix by putting unique serial numbers on the disks, as require= d >>>>by the SCSI standard. >>>>They may even be able to supply some tool to modify it on-site (?). >>>> >>> >>>Hm, interested I try remove all Fujitsu disk and use only one Seagate = >>>and one Fujitsu and see if it helps. I aslo try find some too to chang= e=20 >>>serial number. >>> >> >>I didn't found any tool :-) But tehere is outpu of inq. command scsiinf= o=20 >>/dev/sda >> >>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: 11119944498792=F7=BFF ir >> >> >> >>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: 11119944499149 >> >> >>And you see that number are differ or not ? >> >> >> 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=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV >>_______________________________________________ >>Scsirastools-developers mailing list >>Scs...@li... >>https://lists.sourceforge.net/lists/listinfo/scsirastools-developers >> >>-----------------------------------------------------------------------= -- >>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=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV >>_______________________________________________ >>Scsirastools-developers mailing list >>Scs...@li... >>https://lists.sourceforge.net/lists/listinfo/scsirastools-developers >=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-02-27 14:27:34
|
Oops, sorry. That's a slang term. A wart in the code would be a small = piece that is attached, but doesn't belong there. :-) In this case, it is just one line with an if condition. =20 Andy=20 -----Original Message----- From: scs...@li... = [mailto:scs...@li...] On Behalf = Of Daniel Smolik Sent: Tuesday, February 27, 2007 2:25 AM Cc: scs...@li... Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) Cress, Andrew R napsal(a): > Daniel >=20 > I see the problem now. > The SCSI Inquiry of the Fujitsu disks reports the inquiry length of 41 = when actually the length of the inquiry data returned was 62. 44 bytes = would be enough to catch the serial number. =20 >=20 > Hmmm. =20 > I think I'll put in a wart to account for this disk firmware error. =20 Sorry Andy, but I don't uderstand your last sentence. Do you mean that you put some warn to code about this firmware error ? Sorry my English is not perfect = :) Dan >=20 > Andy >=20 > -----Original Message----- > From: scs...@li... = [mailto:scs...@li...] On Behalf = Of Cress, Andrew R > Sent: Monday, February 26, 2007 9:06 AM > To: Daniel Smolik > Cc: scs...@li... > Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) >=20 > Well, then this must be a bug in my scsi code, if other tools can get = the rest of the serial number. Hmmm. > Let me study this with your sgsafte.log again more thoroughly. =20 >=20 > Andy >=20 > -----Original Message----- > From: scs...@li... = [mailto:scs...@li...] On Behalf = Of Daniel Smolik > Sent: Friday, February 23, 2007 5:47 PM > Cc: scs...@li...; Cress, Andrew R > Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) >=20 > Daniel Smolik napsal(a): >=20 >>Cress, Andrew R napsal(a): >> >> >>>Daniel, >>> >>>All of your Fujitsu drives report the same thing from the SCSI = inquiry: >>> FUJITSU MAG3091L SUN9.0G 1111 99444 >>>There are really only 5 bytes of serial number data (99444) returned >> >>>from the drive. That's just wrong. The other drives look fine, = though. >> >>> >>>It looks like the model number and stuff were modified by Sun after >>>Fujitsu manufactured the disks. This is a problem that Sun should be >>>able to fix by putting unique serial numbers on the disks, as = required >>>by the SCSI standard. >>>They may even be able to supply some tool to modify it on-site (?). >>> >> >>Hm, interested I try remove all Fujitsu disk and use only one Seagate=20 >>and one Fujitsu and see if it helps. I aslo try find some too to = change=20 >>serial number. >> >=20 > I didn't found any tool :-) But tehere is outpu of inq. command = scsiinfo=20 > /dev/sda >=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: 11119944498792=F7=BFF ir >=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: 11119944499149 >=20 >=20 > And you see that number are differ or not ? >=20 >=20 > Dan >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > = -------------------------------------------------------------------------= > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to = shareyour > opinions on IT & business topics through brief surveys-and earn cash > = http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > Scsirastools-developers mailing list > Scs...@li... > https://lists.sourceforge.net/lists/listinfo/scsirastools-developers >=20 > = -------------------------------------------------------------------------= > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to = shareyour > opinions on IT & business topics through brief surveys-and earn cash > = http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > Scsirastools-developers mailing list > Scs...@li... > https://lists.sourceforge.net/lists/listinfo/scsirastools-developers --=20 Mydatex s r.o. http://www.mydatex.cz email: sm...@my... mob: 604200362 tel: 226210085 -------------------------------------------------------------------------= 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=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV _______________________________________________ Scsirastools-developers mailing list Scs...@li... https://lists.sourceforge.net/lists/listinfo/scsirastools-developers |
From: Daniel S. <ma...@my...> - 2007-02-27 07:25:03
|
Cress, Andrew R napsal(a): > Daniel >=20 > I see the problem now. > The SCSI Inquiry of the Fujitsu disks reports the inquiry length of 41 = when actually the length of the inquiry data returned was 62. 44 bytes = would be enough to catch the serial number. =20 >=20 > Hmmm. =20 > I think I'll put in a wart to account for this disk firmware error. =20 Sorry Andy, but I don't uderstand your last sentence. Do you mean that you put some warn to code about this firmware error ? Sorry my English is not perfect = :) Dan >=20 > Andy >=20 > -----Original Message----- > From: scs...@li... [mailto:scs= ira...@li...] On Behalf Of Cress, A= ndrew R > Sent: Monday, February 26, 2007 9:06 AM > To: Daniel Smolik > Cc: scs...@li... > Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) >=20 > Well, then this must be a bug in my scsi code, if other tools can get t= he rest of the serial number. Hmmm. > Let me study this with your sgsafte.log again more thoroughly. =20 >=20 > Andy >=20 > -----Original Message----- > From: scs...@li... [mailto:scs= ira...@li...] On Behalf Of Daniel S= molik > Sent: Friday, February 23, 2007 5:47 PM > Cc: scs...@li...; Cress, Andrew R > Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) >=20 > Daniel Smolik napsal(a): >=20 >>Cress, Andrew R napsal(a): >> >> >>>Daniel, >>> >>>All of your Fujitsu drives report the same thing from the SCSI inquiry= : >>> FUJITSU MAG3091L SUN9.0G 1111 99444 >>>There are really only 5 bytes of serial number data (99444) returned >> >>>from the drive. That's just wrong. The other drives look fine, thoug= h. >> >>> >>>It looks like the model number and stuff were modified by Sun after >>>Fujitsu manufactured the disks. This is a problem that Sun should be >>>able to fix by putting unique serial numbers on the disks, as required= >>>by the SCSI standard. >>>They may even be able to supply some tool to modify it on-site (?). >>> >> >>Hm, interested I try remove all Fujitsu disk and use only one Seagate=20 >>and one Fujitsu and see if it helps. I aslo try find some too to change= =20 >>serial number. >> >=20 > I didn't found any tool :-) But tehere is outpu of inq. command scsiinf= o=20 > /dev/sda >=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: 11119944498792=F7=BFF ir >=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: 11119944499149 >=20 >=20 > And you see that number are differ or not ? >=20 >=20 > Dan >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----------------------------------------------------------------------= -- > 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=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > Scsirastools-developers mailing list > Scs...@li... > https://lists.sourceforge.net/lists/listinfo/scsirastools-developers >=20 > -----------------------------------------------------------------------= -- > 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=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > Scsirastools-developers mailing list > Scs...@li... > https://lists.sourceforge.net/lists/listinfo/scsirastools-developers --=20 Mydatex s r.o. http://www.mydatex.cz email: sm...@my... mob: 604200362 tel: 226210085 |
From: Cress, A. R <and...@in...> - 2007-02-26 18:42:30
|
Daniel I see the problem now. The SCSI Inquiry of the Fujitsu disks reports the inquiry length of 41 = when actually the length of the inquiry data returned was 62. 44 bytes = would be enough to catch the serial number. =20 Hmmm. =20 I think I'll put in a wart to account for this disk firmware error. =20 Andy -----Original Message----- From: scs...@li... = [mailto:scs...@li...] On Behalf = Of Cress, Andrew R Sent: Monday, February 26, 2007 9:06 AM To: Daniel Smolik Cc: scs...@li... Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) Well, then this must be a bug in my scsi code, if other tools can get = the rest of the serial number. Hmmm. Let me study this with your sgsafte.log again more thoroughly. =20 Andy -----Original Message----- From: scs...@li... = [mailto:scs...@li...] On Behalf = Of Daniel Smolik Sent: Friday, February 23, 2007 5:47 PM Cc: scs...@li...; Cress, Andrew R Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) Daniel Smolik napsal(a): > Cress, Andrew R napsal(a): >=20 >>Daniel, >> >>All of your Fujitsu drives report the same thing from the SCSI = inquiry: >> FUJITSU MAG3091L SUN9.0G 1111 99444 >>There are really only 5 bytes of serial number data (99444) returned >>from the drive. That's just wrong. The other drives look fine, = though. >> >> >>It looks like the model number and stuff were modified by Sun after >>Fujitsu manufactured the disks. This is a problem that Sun should be >>able to fix by putting unique serial numbers on the disks, as required >>by the SCSI standard. >>They may even be able to supply some tool to modify it on-site (?). >> >=20 > Hm, interested I try remove all Fujitsu disk and use only one Seagate=20 > and one Fujitsu and see if it helps. I aslo try find some too to = change=20 > serial number. >=20 I didn't found any tool :-) But tehere is outpu of inq. command scsiinfo = /dev/sda 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: 11119944498792=F7=BFF ir 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: 11119944499149 And you see that number are differ or not ? 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=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV _______________________________________________ Scsirastools-developers mailing list Scs...@li... https://lists.sourceforge.net/lists/listinfo/scsirastools-developers -------------------------------------------------------------------------= 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=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV _______________________________________________ Scsirastools-developers mailing list Scs...@li... https://lists.sourceforge.net/lists/listinfo/scsirastools-developers |
From: Cress, A. R <and...@in...> - 2007-02-26 14:06:38
|
Well, then this must be a bug in my scsi code, if other tools can get = the rest of the serial number. Hmmm. Let me study this with your sgsafte.log again more thoroughly. =20 Andy -----Original Message----- From: scs...@li... = [mailto:scs...@li...] On Behalf = Of Daniel Smolik Sent: Friday, February 23, 2007 5:47 PM Cc: scs...@li...; Cress, Andrew R Subject: Re: [Scsirastools-developers] New user (Fujitsu Sun drives) Daniel Smolik napsal(a): > Cress, Andrew R napsal(a): >=20 >>Daniel, >> >>All of your Fujitsu drives report the same thing from the SCSI = inquiry: >> FUJITSU MAG3091L SUN9.0G 1111 99444 >>There are really only 5 bytes of serial number data (99444) returned >>from the drive. That's just wrong. The other drives look fine, = though. >> >> >>It looks like the model number and stuff were modified by Sun after >>Fujitsu manufactured the disks. This is a problem that Sun should be >>able to fix by putting unique serial numbers on the disks, as required >>by the SCSI standard. >>They may even be able to supply some tool to modify it on-site (?). >> >=20 > Hm, interested I try remove all Fujitsu disk and use only one Seagate=20 > and one Fujitsu and see if it helps. I aslo try find some too to = change=20 > serial number. >=20 I didn't found any tool :-) But tehere is outpu of inq. command scsiinfo = /dev/sda 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: 11119944498792=F7=BFF ir 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: 11119944499149 And you see that number are differ or not ? 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=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV _______________________________________________ Scsirastools-developers mailing list Scs...@li... https://lists.sourceforge.net/lists/listinfo/scsirastools-developers |
From: Daniel S. <ma...@my...> - 2007-02-23 22:47:27
|
Daniel Smolik napsal(a): > Cress, Andrew R napsal(a): >=20 >>Daniel, >> >>All of your Fujitsu drives report the same thing from the SCSI inquiry:= >> FUJITSU MAG3091L SUN9.0G 1111 99444 >>There are really only 5 bytes of serial number data (99444) returned >>from the drive. That's just wrong. The other drives look fine, though= =2E >> >> >>It looks like the model number and stuff were modified by Sun after >>Fujitsu manufactured the disks. This is a problem that Sun should be >>able to fix by putting unique serial numbers on the disks, as required >>by the SCSI standard. >>They may even be able to supply some tool to modify it on-site (?). >> >=20 > Hm, interested I try remove all Fujitsu disk and use only one Seagate=20 > and one Fujitsu and see if it helps. I aslo try find some too to change= =20 > serial number. >=20 I didn't found any tool :-) But tehere is outpu of inq. command scsiinfo = /dev/sda 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: 11119944498792=C3=B7=C5=BCF ir 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: 11119944499149 And you see that number are differ or not ? Dan |
From: Daniel S. <ma...@my...> - 2007-02-23 22:36:22
|
Cress, Andrew R napsal(a): > Daniel, > > All of your Fujitsu drives report the same thing from the SCSI inquiry: > FUJITSU MAG3091L SUN9.0G 1111 99444 > There are really only 5 bytes of serial number data (99444) returned > from the drive. That's just wrong. The other drives look fine, though. > > > It looks like the model number and stuff were modified by Sun after > Fujitsu manufactured the disks. This is a problem that Sun should be > able to fix by putting unique serial numbers on the disks, as required > by the SCSI standard. > They may even be able to supply some tool to modify it on-site (?). > Hm, interested I try remove all Fujitsu disk and use only one Seagate and one Fujitsu and see if it helps. I aslo try find some too to change serial number. Dan > Andy > > -----Original Message----- > From: scs...@li... > [mailto:scs...@li...] On Behalf > Of Daniel Smolik > Sent: Friday, February 23, 2007 4:45 PM > To: Cress, Andrew R > Cc: scs...@li... > Subject: Re: [Scsirastools-developers] New user > > Cress, Andrew R napsal(a): > >>Daniel, >> >>The sgsafte log was revealing. >>Apparently most of your Fujitsu disks seem to have exactly the same >>serial number. >>The serial number is used to judge when Linux is confused and reports >>the same physical device on another /dev/sg* device (an impostor), so >>they get marked failed. It must be unique by the SCSI-2 standard. >> >>Hmmm. Fujitsu often has longer 12-byte serial numbers and is in the >>vend12 list in sgsafte.c to handle that. There is also a -m option to >>tell it to use longer 12-byte serial numbers, can you try sgsafte -m > > ? > >> > There is output sgsafte -m -x and sgsafte -m . But situation is the > same. > But remember this is s Sun hardware :-) > > Dan > > > > > >>Andy >> >>-----Original Message----- >>From: Daniel Smolik [mailto:ma...@my...] >>Sent: Friday, February 23, 2007 4:07 PM >>To: Cress, Andrew R; scs...@li... >>Subject: Re: [Scsirastools-developers] New user >> >>Cress, Andrew R napsal(a): >> >> >>>Ah, now we are getting somewhere. There is a later version of mdadm >>>that might compile better than the one I have copied in this tree. >>>But, the main issue: >>>It looks like we have functioning sg* tools, but there is an issue >> >>with >> >> >>>the devices on bus 5: >>>4 /dev/sg4 /dev/sdd 5:0:0:0 Disk SEAGATE ST39103LCSUN9.0G 034A >>>9949862528 ready >>>5 /dev/sg5 /dev/sde 5:0:1:0 Disk >>>failed >>> >>>The next step would be some debug. >>>1) "cat /proc/scsi/scsi" to see if these devices show up there. >>>2) "sgsafte -x" and attach /var/log/sgsafte.log >>>3) "sgdiag -x" and attach /var/log/sgdiag.log >>>4) "tail /var/log/messages" to see if there is any detail around the >> >>bus >> >> >>>error. >>> >>>This should tell me why a bus error is occurring. >>>It could be something physical, like termination, or it could be a >>>software bug of some sort. >> >>Hi, >>there are some logs that you want. >> >> Regards >> Dan > > > -- Mydatex s r.o. http://www.mydatex.cz email: sm...@my... mob: 604200362 tel: 226210085 |
From: Cress, A. R <and...@in...> - 2007-02-23 22:02:02
|
Daniel, All of your Fujitsu drives report the same thing from the SCSI inquiry: FUJITSU MAG3091L SUN9.0G 1111 99444 There are really only 5 bytes of serial number data (99444) returned from the drive. That's just wrong. The other drives look fine, though. It looks like the model number and stuff were modified by Sun after Fujitsu manufactured the disks. This is a problem that Sun should be able to fix by putting unique serial numbers on the disks, as required by the SCSI standard. They may even be able to supply some tool to modify it on-site (?). Andy -----Original Message----- From: scs...@li... [mailto:scs...@li...] On Behalf Of Daniel Smolik Sent: Friday, February 23, 2007 4:45 PM To: Cress, Andrew R Cc: scs...@li... Subject: Re: [Scsirastools-developers] New user Cress, Andrew R napsal(a): > Daniel, >=20 > The sgsafte log was revealing. =20 > Apparently most of your Fujitsu disks seem to have exactly the same > serial number. > The serial number is used to judge when Linux is confused and reports > the same physical device on another /dev/sg* device (an impostor), so > they get marked failed. It must be unique by the SCSI-2 standard.=20 >=20 > Hmmm. Fujitsu often has longer 12-byte serial numbers and is in the > vend12 list in sgsafte.c to handle that. There is also a -m option to > tell it to use longer 12-byte serial numbers, can you try sgsafte -m ? >=20 >=20 There is output sgsafte -m -x and sgsafte -m . But situation is the same. But remember this is s Sun hardware :-) Dan > Andy >=20 > -----Original Message----- > From: Daniel Smolik [mailto:ma...@my...]=20 > Sent: Friday, February 23, 2007 4:07 PM > To: Cress, Andrew R; scs...@li... > Subject: Re: [Scsirastools-developers] New user >=20 > Cress, Andrew R napsal(a): >=20 >>Ah, now we are getting somewhere. There is a later version of mdadm >>that might compile better than the one I have copied in this tree. =20 >>But, the main issue: >>It looks like we have functioning sg* tools, but there is an issue >=20 > with >=20 >>the devices on bus 5: >>4 /dev/sg4 /dev/sdd 5:0:0:0 Disk SEAGATE ST39103LCSUN9.0G 034A >>9949862528 ready >>5 /dev/sg5 /dev/sde 5:0:1:0 Disk >>failed >> >>The next step would be some debug. >>1) "cat /proc/scsi/scsi" to see if these devices show up there. >>2) "sgsafte -x" and attach /var/log/sgsafte.log >>3) "sgdiag -x" and attach /var/log/sgdiag.log >>4) "tail /var/log/messages" to see if there is any detail around the >=20 > bus >=20 >>error. >> >>This should tell me why a bus error is occurring. =20 >>It could be something physical, like termination, or it could be a >>software bug of some sort. =20 >=20 > Hi, > there are some logs that you want. >=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-02-23 21:45:00
|
Cress, Andrew R napsal(a): > Daniel, > > The sgsafte log was revealing. > Apparently most of your Fujitsu disks seem to have exactly the same > serial number. > The serial number is used to judge when Linux is confused and reports > the same physical device on another /dev/sg* device (an impostor), so > they get marked failed. It must be unique by the SCSI-2 standard. > > Hmmm. Fujitsu often has longer 12-byte serial numbers and is in the > vend12 list in sgsafte.c to handle that. There is also a -m option to > tell it to use longer 12-byte serial numbers, can you try sgsafte -m ? > > There is output sgsafte -m -x and sgsafte -m . But situation is the same. But remember this is s Sun hardware :-) Dan > Andy > > -----Original Message----- > From: Daniel Smolik [mailto:ma...@my...] > Sent: Friday, February 23, 2007 4:07 PM > To: Cress, Andrew R; scs...@li... > Subject: Re: [Scsirastools-developers] New user > > Cress, Andrew R napsal(a): > >>Ah, now we are getting somewhere. There is a later version of mdadm >>that might compile better than the one I have copied in this tree. >>But, the main issue: >>It looks like we have functioning sg* tools, but there is an issue > > with > >>the devices on bus 5: >>4 /dev/sg4 /dev/sdd 5:0:0:0 Disk SEAGATE ST39103LCSUN9.0G 034A >>9949862528 ready >>5 /dev/sg5 /dev/sde 5:0:1:0 Disk >>failed >> >>The next step would be some debug. >>1) "cat /proc/scsi/scsi" to see if these devices show up there. >>2) "sgsafte -x" and attach /var/log/sgsafte.log >>3) "sgdiag -x" and attach /var/log/sgdiag.log >>4) "tail /var/log/messages" to see if there is any detail around the > > bus > >>error. >> >>This should tell me why a bus error is occurring. >>It could be something physical, like termination, or it could be a >>software bug of some sort. > > Hi, > there are some logs that you want. > > Regards > Dan -- Mydatex s r.o. http://www.mydatex.cz email: sm...@my... mob: 604200362 tel: 226210085 |
From: Cress, A. R <and...@in...> - 2007-02-23 21:31:05
|
Daniel, The sgsafte log was revealing. =20 Apparently most of your Fujitsu disks seem to have exactly the same serial number. The serial number is used to judge when Linux is confused and reports the same physical device on another /dev/sg* device (an impostor), so they get marked failed. It must be unique by the SCSI-2 standard.=20 Hmmm. Fujitsu often has longer 12-byte serial numbers and is in the vend12 list in sgsafte.c to handle that. There is also a -m option to tell it to use longer 12-byte serial numbers, can you try sgsafte -m ? Andy -----Original Message----- From: Daniel Smolik [mailto:ma...@my...]=20 Sent: Friday, February 23, 2007 4:07 PM To: Cress, Andrew R; scs...@li... Subject: Re: [Scsirastools-developers] New user Cress, Andrew R napsal(a): > Ah, now we are getting somewhere. There is a later version of mdadm > that might compile better than the one I have copied in this tree. =20 > But, the main issue: > It looks like we have functioning sg* tools, but there is an issue with > the devices on bus 5: > 4 /dev/sg4 /dev/sdd 5:0:0:0 Disk SEAGATE ST39103LCSUN9.0G 034A > 9949862528 ready > 5 /dev/sg5 /dev/sde 5:0:1:0 Disk > failed >=20 > The next step would be some debug. > 1) "cat /proc/scsi/scsi" to see if these devices show up there. > 2) "sgsafte -x" and attach /var/log/sgsafte.log > 3) "sgdiag -x" and attach /var/log/sgdiag.log > 4) "tail /var/log/messages" to see if there is any detail around the bus > error. >=20 > This should tell me why a bus error is occurring. =20 > It could be something physical, like termination, or it could be a > software bug of some sort. =20 Hi, there are some logs that you want. Regards Dan |
From: Daniel S. <ma...@my...> - 2007-02-23 21:07:25
|
Cress, Andrew R napsal(a): > Ah, now we are getting somewhere. There is a later version of mdadm > that might compile better than the one I have copied in this tree. > But, the main issue: > It looks like we have functioning sg* tools, but there is an issue with > the devices on bus 5: > 4 /dev/sg4 /dev/sdd 5:0:0:0 Disk SEAGATE ST39103LCSUN9.0G 034A > 9949862528 ready > 5 /dev/sg5 /dev/sde 5:0:1:0 Disk > failed > > The next step would be some debug. > 1) "cat /proc/scsi/scsi" to see if these devices show up there. > 2) "sgsafte -x" and attach /var/log/sgsafte.log > 3) "sgdiag -x" and attach /var/log/sgdiag.log > 4) "tail /var/log/messages" to see if there is any detail around the bus > error. > > This should tell me why a bus error is occurring. > It could be something physical, like termination, or it could be a > software bug of some sort. Hi, there are some logs that you want. Regards Dan |
From: Daniel S. <ma...@my...> - 2007-02-20 14:04:12
|
Cress, Andrew R napsal(a): > Ah, now we are getting somewhere. There is a later version of mdadm > that might compile better than the one I have copied in this tree. > But, the main issue: > It looks like we have functioning sg* tools, but there is an issue with > the devices on bus 5: > 4 /dev/sg4 /dev/sdd 5:0:0:0 Disk SEAGATE ST39103LCSUN9.0G 034A > 9949862528 ready > 5 /dev/sg5 /dev/sde 5:0:1:0 Disk > failed > > The next step would be some debug. > 1) "cat /proc/scsi/scsi" to see if these devices show up there. > 2) "sgsafte -x" and attach /var/log/sgsafte.log > 3) "sgdiag -x" and attach /var/log/sgdiag.log > 4) "tail /var/log/messages" to see if there is any detail around the bus > error. > > This should tell me why a bus error is occurring. > It could be something physical, like termination, or it could be a > software bug of some sort. > > Andy Thanks I test this early. But I have lot of problems with external D1000 enclosure. May be that is Sparc specific. If I turn D1000 on all works great but after fires reboot disks aren't deteced. I investigate to solve this problem. Dan |
From: Cress, A. R <and...@in...> - 2007-02-20 13:51:02
|
Ah, now we are getting somewhere. There is a later version of mdadm that might compile better than the one I have copied in this tree. =20 But, the main issue: It looks like we have functioning sg* tools, but there is an issue with the devices on bus 5: 4 /dev/sg4 /dev/sdd 5:0:0:0 Disk SEAGATE ST39103LCSUN9.0G 034A 9949862528 ready 5 /dev/sg5 /dev/sde 5:0:1:0 Disk failed The next step would be some debug. 1) "cat /proc/scsi/scsi" to see if these devices show up there. 2) "sgsafte -x" and attach /var/log/sgsafte.log 3) "sgdiag -x" and attach /var/log/sgdiag.log 4) "tail /var/log/messages" to see if there is any detail around the bus error. This should tell me why a bus error is occurring. =20 It could be something physical, like termination, or it could be a software bug of some sort. =20 Andy -----Original Message----- From: scs...@li... [mailto:scs...@li...] On Behalf Of Daniel Smolik Sent: Friday, February 16, 2007 5:41 PM Cc: scs...@li... Subject: Re: [Scsirastools-developers] New user Cress, Andrew R napsal(a): > Daniel, >=20 > Hmmm. It compiles fine here on 32-bit or 64-bit. > Can you tell me if your Sun system is 32-bit or 64-bit? (uname -a) > There would be byte-order differences too, but that wouldn't cause any > compile errors. >=20 Linux e450 2.6.17.14 #2 SMP Thu Feb 15 22:22:11 CET 2007 sparc64 GNU/Linux > Did you do these steps after unpacking the tarball?: =20 > aclocal; autoconf; automake; configure; make=20 Before no. But now yes and result is the same. >=20 >=20 Maybe you could attach a sample of the compile errors you get? >=20 Yes there is : cd . && automake-1.9 --gnu Makefile cd . \ && CONFIG_FILES=3DMakefile CONFIG_HEADERS=3D /bin/sh ./config.status config.status: creating Makefile config.status: executing depfiles commands cd . && autoheader rm -f stamp-h1 touch config.h.in cd . && /bin/sh ./config.status config.h config.status: creating config.h config.status: config.h is unchanged make all-recursive make[1]: Entering directory `/root/scsirastools-1.5.1' Making all in mdadm.d make[2]: Entering directory `/root/scsirastools-1.5.1/mdadm.d' cd mdadm-1.3.0; make make[3]: Entering directory `/root/scsirastools-1.5.1/mdadm.d/mdadm-1.3.0' gcc -Wall -Werror -Wstrict-prototypes -DCONFFILE=3D\"/etc/mdadm.conf\"=20 -ggdb -DSen dmail=3D\""/usr/sbin/sendmail -t"\" -c = -o mdadm.o mdadm.c cc1: warnings being treated as errors mdadm.c: In function 'main': mdadm.c:365: warning: pointer targets in passing argument 2 of=20 'parse_uuid' diff er in signedness make[3]: *** [mdadm.o] Error 1 make[3]: Leaving directory `/root/scsirastools-1.5.1/mdadm.d/mdadm-1.3.0' make[2]: *** [mdadm] Error 2 make[2]: Leaving directory `/root/scsirastools-1.5.1/mdadm.d' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/scsirastools-1.5.1' make: *** [all] Error 2 I cd to src/ and copile only sg*. /sgsafte sgsafte utility v1.20 for SCSI SAF-TE testing Num Name bus:ch:id:lun Type Vendor Device_Model FRev Serial#=20 Status 0 /dev/sg0 /dev/sda 2:0:8:0 Disk FUJITSU MAG3091L SUN9.0G 1111 99444 ready 1 /dev/sg1 /dev/sdb 2:0:9:0 Disk=20 failed 2 /dev/sg2 2:0:15:0 Proc SYMBIOS D1000 2 `'x=20 ready 3 /dev/sg3 /dev/sdc 4:0:6:0 CDRM TOSHIBA XM6201TASUN32XCD 1103 12/12/97 ready 4 /dev/sg4 /dev/sdd 5:0:0:0 Disk SEAGATE ST39103LCSUN9.0G 034A=20 9949862528 ready 5 /dev/sg5 /dev/sde 5:0:1:0 Disk=20 failed monitoring 4 scsi devices ... e450:~/scsirastools-1.5.1/src# ./sg sgdefects sgdiag sgdiskmon sgdskfl sgmode sgraidmon=20 sgsafte e450:~/scsirastools-1.5.1/src# ./sgdiag sgdiag utility v1.13 for SCSI disks ****************************************** Log file /var/log/sgdiag.log is open, debug=3D0 Num Name [bus:ch:id:lun] Type Vendor Device_Model FW Serial# Size 0 /dev/sg0 [2:0:8:0] Disk FUJITSU MAG3091L SUN9.0G 1111 8637MB 1 /dev/sg1 [2:0:9:0] Disk FUJITSU MAG3091L SUN9.0G 1111 8637MB 2 /dev/sg2 [2:0:15:0] Proc SYMBIOS D1000 2 `'x 3 /dev/sg3 [4:0:6:0] CDROM TOSHIBA XM6201TASUN32XCD 1103 12/12/97 Bus error Thanks for your help Dan > Andy >=20 > -----Original Message----- > From: scs...@li... > [mailto:scs...@li...] On Behalf > Of Daniel Smolik > Sent: Friday, February 16, 2007 4:36 PM > To: scs...@li... > Subject: [Scsirastools-developers] New user >=20 > Hi all, > I have get E450 (Sun Sprac) and 3 pcs. of D1000 diak cabinet with SAF-TE >=20 > support. I search for tool that can read some infos from SAF-TE. I found >=20 > this tool. I try it compile on Sparc but get lot off errors. >=20 > sgsafte end with Buss error. I would like to help but I am not good=20 > programmer but good tester :-) >=20 > Regards > Dan >=20 >=20 >=20 ------------------------------------------------------------------------ - 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=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDE V _______________________________________________ Scsirastools-developers mailing list Scs...@li... https://lists.sourceforge.net/lists/listinfo/scsirastools-developers |
From: Daniel S. <ma...@my...> - 2007-02-16 22:41:06
|
Cress, Andrew R napsal(a): > Daniel, > > Hmmm. It compiles fine here on 32-bit or 64-bit. > Can you tell me if your Sun system is 32-bit or 64-bit? (uname -a) > There would be byte-order differences too, but that wouldn't cause any > compile errors. > Linux e450 2.6.17.14 #2 SMP Thu Feb 15 22:22:11 CET 2007 sparc64 GNU/Linux > Did you do these steps after unpacking the tarball?: > aclocal; autoconf; automake; configure; make Before no. But now yes and result is the same. > > Maybe you could attach a sample of the compile errors you get? > Yes there is : cd . && automake-1.9 --gnu Makefile cd . \ && CONFIG_FILES=Makefile CONFIG_HEADERS= /bin/sh ./config.status config.status: creating Makefile config.status: executing depfiles commands cd . && autoheader rm -f stamp-h1 touch config.h.in cd . && /bin/sh ./config.status config.h config.status: creating config.h config.status: config.h is unchanged make all-recursive make[1]: Entering directory `/root/scsirastools-1.5.1' Making all in mdadm.d make[2]: Entering directory `/root/scsirastools-1.5.1/mdadm.d' cd mdadm-1.3.0; make make[3]: Entering directory `/root/scsirastools-1.5.1/mdadm.d/mdadm-1.3.0' gcc -Wall -Werror -Wstrict-prototypes -DCONFFILE=\"/etc/mdadm.conf\" -ggdb -DSen dmail=\""/usr/sbin/sendmail -t"\" -c -o mdadm.o mdadm.c cc1: warnings being treated as errors mdadm.c: In function 'main': mdadm.c:365: warning: pointer targets in passing argument 2 of 'parse_uuid' diff er in signedness make[3]: *** [mdadm.o] Error 1 make[3]: Leaving directory `/root/scsirastools-1.5.1/mdadm.d/mdadm-1.3.0' make[2]: *** [mdadm] Error 2 make[2]: Leaving directory `/root/scsirastools-1.5.1/mdadm.d' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/scsirastools-1.5.1' make: *** [all] Error 2 I cd to src/ and copile only sg*. /sgsafte sgsafte utility v1.20 for SCSI SAF-TE testing Num Name bus:ch:id:lun Type Vendor Device_Model FRev Serial# Status 0 /dev/sg0 /dev/sda 2:0:8:0 Disk FUJITSU MAG3091L SUN9.0G 1111 99444 ready 1 /dev/sg1 /dev/sdb 2:0:9:0 Disk failed 2 /dev/sg2 2:0:15:0 Proc SYMBIOS D1000 2 `'x ready 3 /dev/sg3 /dev/sdc 4:0:6:0 CDRM TOSHIBA XM6201TASUN32XCD 1103 12/12/97 ready 4 /dev/sg4 /dev/sdd 5:0:0:0 Disk SEAGATE ST39103LCSUN9.0G 034A 9949862528 ready 5 /dev/sg5 /dev/sde 5:0:1:0 Disk failed monitoring 4 scsi devices ... e450:~/scsirastools-1.5.1/src# ./sg sgdefects sgdiag sgdiskmon sgdskfl sgmode sgraidmon sgsafte e450:~/scsirastools-1.5.1/src# ./sgdiag sgdiag utility v1.13 for SCSI disks ****************************************** Log file /var/log/sgdiag.log is open, debug=0 Num Name [bus:ch:id:lun] Type Vendor Device_Model FW Serial# Size 0 /dev/sg0 [2:0:8:0] Disk FUJITSU MAG3091L SUN9.0G 1111 8637MB 1 /dev/sg1 [2:0:9:0] Disk FUJITSU MAG3091L SUN9.0G 1111 8637MB 2 /dev/sg2 [2:0:15:0] Proc SYMBIOS D1000 2 `'x 3 /dev/sg3 [4:0:6:0] CDROM TOSHIBA XM6201TASUN32XCD 1103 12/12/97 Bus error Thanks for your help Dan > Andy > > -----Original Message----- > From: scs...@li... > [mailto:scs...@li...] On Behalf > Of Daniel Smolik > Sent: Friday, February 16, 2007 4:36 PM > To: scs...@li... > Subject: [Scsirastools-developers] New user > > Hi all, > I have get E450 (Sun Sprac) and 3 pcs. of D1000 diak cabinet with SAF-TE > > support. I search for tool that can read some infos from SAF-TE. I found > > this tool. I try it compile on Sparc but get lot off errors. > > sgsafte end with Buss error. I would like to help but I am not good > programmer but good tester :-) > > Regards > Dan > > > |
From: Cress, A. R <and...@in...> - 2007-02-16 22:22:02
|
Daniel, Hmmm. It compiles fine here on 32-bit or 64-bit. Can you tell me if your Sun system is 32-bit or 64-bit? (uname -a) There would be byte-order differences too, but that wouldn't cause any compile errors. Did you do these steps after unpacking the tarball?: =20 aclocal; autoconf; automake; configure; make=20 Maybe you could attach a sample of the compile errors you get? Andy -----Original Message----- From: scs...@li... [mailto:scs...@li...] On Behalf Of Daniel Smolik Sent: Friday, February 16, 2007 4:36 PM To: scs...@li... Subject: [Scsirastools-developers] New user Hi all, I have get E450 (Sun Sprac) and 3 pcs. of D1000 diak cabinet with SAF-TE support. I search for tool that can read some infos from SAF-TE. I found this tool. I try it compile on Sparc but get lot off errors. sgsafte end with Buss error. I would like to help but I am not good=20 programmer but good tester :-) Regards Dan --=20 Mydatex s r.o. http://www.mydatex.cz email: sm...@my... mob: 604200362 tel: 226210085 ------------------------------------------------------------------------ - 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=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDE V _______________________________________________ Scsirastools-developers mailing list Scs...@li... https://lists.sourceforge.net/lists/listinfo/scsirastools-developers |
From: Daniel S. <ma...@my...> - 2007-02-16 21:35:47
|
Hi all, I have get E450 (Sun Sprac) and 3 pcs. of D1000 diak cabinet with SAF-TE support. I search for tool that can read some infos from SAF-TE. I found this tool. I try it compile on Sparc but get lot off errors. sgsafte end with Buss error. I would like to help but I am not good programmer but good tester :-) Regards Dan -- Mydatex s r.o. http://www.mydatex.cz email: sm...@my... mob: 604200362 tel: 226210085 |
From: Cress, A. R <and...@in...> - 2007-02-09 22:06:06
|
The scsirastools-1.5.1 release is now posted. See http://scsirastools.sf.net for rpm, exe, and doc files. There are several bug fixes. =20 Andy =20 1.5.1 =3D released 02/09/07, updated 02/07/07 src/sgdskfl.c - fix seg fault if stale dbgout, add -i option, fix to correct sdname src/sgraidmon.c - fix to correct sdname src/sgdiskmon.c - sense_err mods, fix to correct sdname src/sgcommon.c - more debug code, added get_dev_maj_min, find_mmdev src/sgcommon.h - add maj, min to DEVLIST structure src/sgsub.c - additional protection for dbgout in write_buffer doc/sgdskfl.8 - more explanation of option -r usage doc/UserGuide scsirastools-1.5.1 contains: sgdefects.c: 1.6 sgdiag.c: 1.13 sgdiskmon.c: 0.6 sgdskfl.c: 1.9 sgmode.c: 1.10 sgraidmon.c: 1.28 sgsafte.c: 1.20 |
From: Cress, A. R <and...@in...> - 2007-01-23 21:28:54
|
scsirastools-1.5.0 adds a new sgdiskmon tool, and adds the -i option to allow specifying a given single disk. =20 Detailed changes: 1.5.0 =3D released 01/23/07, updated 01/04/07 src/sg*.c - added -i option for one disk src/Makefile.am src/sgdiskmon.c - new files/Makefile.am files/sgraid - added modprobe sg files/sgdisk - new files/sgevt - new files/rescan-scsi-bus.sh - new doc/Makefile.am doc/sgdiskmon.8 - new doc/scsirastools.spec - added sgdiskmon doc/UserGuide scsirastools-1.5.0 contains: sgraidmon.c: 1.28 sgdiskmon.c: 0.5 sgdefects.c: 1.6 sgdiag.c: 1.13 sgdskfl.c: 1.8 sgmode.c: 1.10 sgsafte.c: 1.20 =20 |
From: Cress, A. R <and...@in...> - 2005-09-07 12:49:05
|
Folks, The scsirastools-1.4.16 package is now released. It contains a fix for bug 1281273 and some enhancements. Note especially that sample snmptrap logic was added to mdevt/sgraidmon to send SNMP traps if a disk event occurs. This is turned off by default, but can be enabled by entering the SNMP destination IP address and turning on the dosnmptrap flag. It uses OIDs from Adaptec's iommib.mib, but this can also be changed to customize the traps. See the /sbin/mdevt script for more details. Below are the details of the changes. 1.4.16 =3D released 09/07/05, updated 09/06/05 doc/UserGuide how to set up sgraid kill scripts in rc0.d, rc6.d src/sgraidmon.c fix for 1281273, don't reset in sense_err if not managed. Also added -s option to skip any SCSI resets if desired. files/mdevt added sample snmptrap logic to send SNMP traps for disk events. Andy |
From: Cress, A. R <and...@in...> - 2005-05-11 19:22:08
|
A new scsirastools-1.4.15 version has been released. =20 The changes are due to input from Nate Dailey. Fixes a bug for more than 32 devices. The max number of devices (MAX_DEVLIST_DEVS) is now defined in sgcommon.h. It defaults to 128, and could be easily increased for users in larger configurations. =20 Memory consumption is 140 bytes per device in the table. Andy 1.4.15 =3D released 05/11/05, updated 05/11/05 src/sgdefects.c included patch for larger devlist from Nate Dailey src/sgdskfl.c included patch for larger devlist from Nate Dailey src/sgmode.c included patch for larger devlist from Nate Dailey src/sgdiag.c included patch for larger devlist from Nate Dailey=20 |
From: Dailey, N. <Nat...@st...> - 2005-05-11 17:05:10
|
That's a good point... I just picked 32k because that seemed to be the most sg devices that could ever exist. But certainly a much smaller number would be fine. I think 512 would be plenty... Nate -----Original Message----- From: Cress, Andrew R [mailto:and...@in...] Sent: Wednesday, May 11, 2005 11:33 AM To: Dailey, Nate; scs...@li... Subject: RE: [Scsirastools-developers] [PATCH] support more devices in sgdiag and check devlist array bo unds Nate, The size does need to be greater than 32. Thanks for the patch. However, as it is it adds 140 bytes * 32K devices = about 4.48MB to each utility. This is pretty big, but is doable for all but sgraidmon, since most of the utilities will run only occasionally and won't stay around in memory. Hmmm. Do we really need 32K scsi devices for an enclosure? Is there a real use case for more than say 512 or 1024? Andy -----Original Message----- From: scs...@li... [mailto:scs...@li...] On Behalf Of Dailey, Nate Sent: Tuesday, May 10, 2005 3:40 PM To: 'scs...@li...' Cc: Dailey, Nate Subject: [Scsirastools-developers] [PATCH] support more devices in sgdiag and check devlist array bo unds I hit a segmentation fault in sgdiag on a system with more than 32 devices. It turns out that there's no bounds checking on the devlist array, so additional devices trample on memory outside the devlist. The attached patch prevents writing outside the bounds of the array, and also ups the number of devices. It looks like the same problem exists in sgdefects, sgdskfl, and sgmode, but I haven't tested them to verify. This patch is against scsirastools 1.4.14. Nate Dailey Stratus Technologies |
From: Cress, A. R <and...@in...> - 2005-05-11 15:32:44
|
Nate, The size does need to be greater than 32. Thanks for the patch. However, as it is it adds 140 bytes * 32K devices =3D about 4.48MB to = each utility. This is pretty big, but is doable for all but sgraidmon, since most of the utilities will run only occasionally and won't stay around in memory. Hmmm. Do we really need 32K scsi devices for an enclosure? Is there a real use case for more than say 512 or 1024? =20 Andy -----Original Message----- From: scs...@li... [mailto:scs...@li...] On Behalf Of Dailey, Nate Sent: Tuesday, May 10, 2005 3:40 PM To: 'scs...@li...' Cc: Dailey, Nate Subject: [Scsirastools-developers] [PATCH] support more devices in sgdiag and check devlist array bo unds I hit a segmentation fault in sgdiag on a system with more than 32 devices. It turns out that there's no bounds checking on the devlist array, so additional devices trample on memory outside the devlist. The attached patch prevents writing outside the bounds of the array, and also ups the number of devices. It looks like the same problem exists in sgdefects, sgdskfl, and sgmode, but I haven't tested them to verify. This patch is against scsirastools 1.4.14. Nate Dailey Stratus Technologies |