Re: [linux-linus bisection] complete test-amd64-amd64-xl-qemut-win7-amd64 [and 1 more messages]

From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [linux-linus bisection] complete test-amd64-amd64-xl-qemut-win7-amd64 [and 1 more messages]
Date: Fri, 20 Jan 2017 11:29:26 -0500	[thread overview]
Message-ID: <82d7e1c9-cf6c-265d-9995-1d462c78c4d9@oracle.com> (raw)
In-Reply-To: <22657.61410.949927.536885@mariner.uk.xensource.com>

On 01/20/2017 06:09 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [linux-linus bisection] complete test-amd64-amd64-xl-qemut-win7-amd64 [and 1 more messages]"):
>> On 01/19/2017 01:05 PM, Ian Jackson wrote:
>>> This means that the bug is in commits which diverged before the last
>>> pass of this test.
>>>
>>> (Did your filters get you a copy of the bisection email?)
>> No, I haven't set a filter for the bisector but I did see this message
>> and didn't find bisection results particularly useful. bcc981e9ed84 is
>> from about a year ago, which, I think, is when you stopped running this
>> test. And so the question might be whether "Bug not present" is really true?
> It means that this precise combination of software was tested and
> passed, recently, on the same hosts, several times.
>
> See
>   http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-amd64-xl-qemut-win7-amd64.xen-boot.html
> where you can see the flight numbers.  (They are sequential.)
>
> So yes it is really true.

Here is a typical scenario that leads to the mptsas error:
...
Jan 19 13:09:39.545726 [   10.241093]  sda: sda1 sda2 < sda5 >
Jan 19 13:09:39.609596 [   10.314016] sd 4:0:0:0: [sda] Attached SCSI disk
Jan 19 13:09:39.681544 [   19.883573] random: crng init done
Jan 19 13:09:49.249674 [   40.938069] sd 4:0:0:0: attempting task abort!
scmd(ffff880016e06600)
Jan 19 13:10:10.305667 [ 40.938090] sd 4:0:0:0: [sda] tag#0 CDB: ATA
command pass through(12)/Blank a1 08 2e 00 01 00 00 00 00 ec 00 00
...

There is difference of about 30 seconds between the disk attachment and
abort sequence initiation. Which also happens to be default scsi disk
timeout. For example:

root@haswell> for f in /sys/block/sd?/device/timeout; do echo -n $f ":
"; cat $f; done
/sys/block/sda/device/timeout : 30
/sys/block/sdb/device/timeout : 30
root@haswell>

So it looks like the device may have timed out for some reason.

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel