lkml.org 
[lkml]   [2015]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject"scsi: convert host_busy to atomic_t" series causes regressions for some hardware configurations
Thanks Christoph for the answer!

Apparently I missed a piece of the thread where the test patch was originally
proposed . Now, I have gone through it and I see how the patch was not meant to
be a final correction.

My (possibly naive) understanding is that:

- Even if this might be due to hardware that not fully conforms to the standard
(but we do not know right now), commit 74665016086615bbaa3fa6f83af410a0a4e029ee
( scsi: convert host_busy to atomic_t ) certainly breaks the kernel for some
hardware configurations causing a regression.

- If the regression was immediately spotted, the patch would probably have been
revised right after proposal. Unfortunately, another bug - that got fixed only
much later with 045065d8a300a37218c - hid the original issue for a long time.

- Now that a lot of time has passed with the "scsi: convert host_busy to
atomic_t" series in the kernel, going back to look into it is much more
difficult. Libata people might not be very interested as they moved to other
topics and might need a lot of time to go through it (it has been known since
November 2014 - 9 months ago), possibly due to the race like nature of the issue
and the fact that the bug might not be reproducible on their hardware...

Is this correct?

Aren't commits that cause regressions confirmed by multiple users expected (at
least in principle) to be reverted?

If reverting is too costy, wouldn't your "papering over" or making the scsi
delay configurable be an acceptable solution?

Even better: can in some way the libata-people be helped find the real culprit,
given that there are at least two hardware setups that are known to trigger the
regression (mine and Barto's)?

I have tried the linux-ide mailing list, but got silence.

Best,

Sergio



On 20/08/2015 10:08, Christoph Hellwig wrote:
> Hi Sergio,
>
> On Tue, Aug 18, 2015 at 09:44:28AM +0200, Sergio Callegari wrote:
>> Hi,
>>
>> I have bisected the issue down to
>>
>> [045065d8a300a37218c548e9aa7becd581c6a0e8] [SCSI] fix qemu boot hang problem
>>
>> Bisecting has been a painful job due to the fact that the bug may show only
>> many hours after the system boot.
>>
>> The commit above in fact is not the culprit, but a fix to an issue that was
>> hiding the real bug on my system. See
>>
>> http://marc.info/?l=linux-kernel&m=143973820612978&w=2
>>
>> The real issue is with sata host lock and seems to be biting a few other
>> people as well
>>
>> https://bbs.archlinux.org/viewtopic.php?id=189324
>>
>> A patch fixing the issue was sent to the LKML back in Nov 2014 by Christoph
>> Hellwig (who is reading in CC)
>>
>> https://lkml.org/lkml/2014/11/20/581
>>
>> I have tested the patch and it works for me.
>>
>> What is expected to happen now?
> As mentioned in that thread we need more input from the libata people
> on what kind of race this is papering over.



\
 
 \ /
  Last update: 2015-08-24 19:41    [W:0.106 / U:0.808 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site