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

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 01/20/2017 11:29 AM, Boris Ostrovsky wrote:
> 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.


On the off-chance that he might know right away what this is I asked
SCSI maintainer (Martin Petersen) and he thought that this might be the fix:

http://git.kernel.org/cgit/linux/kernel/git/mkp/scsi.git/commit/?h=4.10/scsi-fixes&id=ffb58456589443ca572221fabbdef3db8483a779

Pull request was sent to Linus yesterday so it should be in the mainline
shortly.


-boris


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