I suggest that you read the T10 specifications a little more closely. These are not spurious CHECK CONDITIONS, but are defined by the specification. If I remember correctly the sending of these conditions is talked about in SAM.
On Mon, Feb 2, 2009 at 4:16 AM, kristof <[email protected]> wrote: > Hello mlaspina , > > A network trace was already attached, see my second message above. > > In the meantime we found the "real" cause thanks to Michael (etherboot): > > He checked the trace and told me: > > iSCSI targets have a habit of sending a spurious CHECK CONDITION response to > the first SCSI command, with sense data indicating that "power-on occurred". > We already issue and ignore > one extra READ CAPACITY (10) command to draw out this response. > > >From the capture that you provided, it seems that the comstar target is > >sending not one but two spurious CHECK CONDITION responses: one saying > >"power-on occurred" and one saying "reported LUNS data has changed". We > >currently expect only one spurious response, so the second spurious response > >gets treated as a genuine error by gPXE. > > Now Michael updated GPXE to attempt up to 10 dummy commands at start of day > before assuming that error responses are genuine. > > Today I tested latest GPXE and confirmed Michael was correct. > > kristof > -- > This message posted from opensolaris.org > _______________________________________________ > storage-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/storage-discuss > -- Rick McNeal "Democracy is two wolves and a sheep voting on what to have for lunch. Liberty is a well armed sheep contesting the vote." Benjamin Franklin _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
