On 2016/12/8 23:39, James Bottomley wrote:
> On Thu, 2016-12-08 at 11:22 +0800, Wei Fang wrote:
>> Hi, James, Ewan,
>>
>> On 2016/12/8 10:33, James Bottomley wrote:
>>> On Thu, 2016-12-08 at 10:28 +0800, Wei Fang wrote:
Hi, James, Ewan,
On 2016/12/8 7:43, James Bottomley wrote:
>>>
On Thu, 2016-12-08 at 11:22 +0800, Wei Fang wrote:
> Hi, James, Ewan,
>
> On 2016/12/8 10:33, James Bottomley wrote:
> > On Thu, 2016-12-08 at 10:28 +0800, Wei Fang wrote:
> > > Hi, James, Ewan,
> > >
> > > On 2016/12/8 7:43, James Bottomley wrote:
> > > > On Wed, 2016-12-07 at 15:30 -0500, Ewan
On Thu, 2016-12-08 at 14:38 +0800, Wei Fang wrote:
> Hi, James, Ewan, Bart,
>
> On 2016/12/8 11:22, Wei Fang wrote:
> > I looked through those code and found that if we fix this bug
> > by removing setting the state in scsi_sysfs_add_sdev(), it
> > can't be fixed completely:
> >
> > scsi_device_s
Hi, James, Ewan, Bart,
On 2016/12/8 11:22, Wei Fang wrote:
> I looked through those code and found that if we fix this bug
> by removing setting the state in scsi_sysfs_add_sdev(), it
> can't be fixed completely:
>
> scsi_device_set_state(sdev, SDEV_RUNNING) in scsi_add_lun() and
> scsi_device_se
Hi, James, Ewan,
On 2016/12/8 10:33, James Bottomley wrote:
> On Thu, 2016-12-08 at 10:28 +0800, Wei Fang wrote:
>> Hi, James, Ewan,
>>
>> On 2016/12/8 7:43, James Bottomley wrote:
>>> On Wed, 2016-12-07 at 15:30 -0500, Ewan D. Milne wrote:
On Wed, 2016-12-07 at 12:09 -0800, James Bottomley w
On Thu, 2016-12-08 at 10:28 +0800, Wei Fang wrote:
> Hi, James, Ewan,
>
> On 2016/12/8 7:43, James Bottomley wrote:
> > On Wed, 2016-12-07 at 15:30 -0500, Ewan D. Milne wrote:
> > > On Wed, 2016-12-07 at 12:09 -0800, James Bottomley wrote:
> > > > Hm, it looks like the state set in scsi_sysfs_add_
Hi, James, Ewan,
On 2016/12/8 7:43, James Bottomley wrote:
> On Wed, 2016-12-07 at 15:30 -0500, Ewan D. Milne wrote:
>> On Wed, 2016-12-07 at 12:09 -0800, James Bottomley wrote:
>>> Hm, it looks like the state set in scsi_sysfs_add_sdev() is bogus.
>>> We expect the state to have been properly s
On Wed, 2016-12-07 at 15:30 -0500, Ewan D. Milne wrote:
> On Wed, 2016-12-07 at 12:09 -0800, James Bottomley wrote:
> > Hm, it looks like the state set in scsi_sysfs_add_sdev() is bogus.
> > We expect the state to have been properly set before that (in
> > scsi_add_lun), so can we not simply remo
On Wed, 2016-12-07 at 12:09 -0800, James Bottomley wrote:
> Hm, it looks like the state set in scsi_sysfs_add_sdev() is bogus. We
> expect the state to have been properly set before that (in
> scsi_add_lun), so can we not simply remove it?
>
> James
>
I was considering that, but...
enum scsi_d
On Wed, 2016-12-07 at 14:24 -0500, Ewan D. Milne wrote:
> On Wed, 2016-12-07 at 10:16 -0800, James Bottomley wrote:
> > On Wed, 2016-12-07 at 12:40 -0500, Ewan D. Milne wrote:
> > > On Wed, 2016-12-07 at 08:55 -0800, Bart Van Assche wrote:
> > > > On 12/07/2016 08:48 AM, Bart Van Assche wrote:
> >
On Wed, 2016-12-07 at 10:16 -0800, James Bottomley wrote:
> On Wed, 2016-12-07 at 12:40 -0500, Ewan D. Milne wrote:
> > On Wed, 2016-12-07 at 08:55 -0800, Bart Van Assche wrote:
> > > On 12/07/2016 08:48 AM, Bart Van Assche wrote:
> > > > It's a known bug. Some time ago I posted a patch that serial
On Wed, 2016-12-07 at 12:40 -0500, Ewan D. Milne wrote:
> On Wed, 2016-12-07 at 08:55 -0800, Bart Van Assche wrote:
> > On 12/07/2016 08:48 AM, Bart Van Assche wrote:
> > > It's a known bug. Some time ago I posted a patch that serializes
> > > all scsi_device_set_state() calls but I have not yet f
On Wed, 2016-12-07 at 08:55 -0800, Bart Van Assche wrote:
> On 12/07/2016 08:48 AM, Bart Van Assche wrote:
> > It's a known bug. Some time ago I posted a patch that serializes all
> > scsi_device_set_state() calls but I have not yet found it in the list
> > archives. However, that patch has not yet
On 12/06/2016 11:03 PM, Wei Fang wrote:
On 2016/12/7 12:40, Bart Van Assche wrote:
I am aware that commit 5c10e63c943b caused the behavior change. But that
doesn't mean that a fix has to undo the changes introduced by that
commit. We do not only want to make sure that the SCSI core works as
inte
On 12/07/2016 08:48 AM, Bart Van Assche wrote:
It's a known bug. Some time ago I posted a patch that serializes all
scsi_device_set_state() calls but I have not yet found it in the list
archives. However, that patch has not yet been merged.
See also https://www.spinics.net/lists/linux-scsi/msg6
Hi, Bart,
On 2016/12/7 12:40, Bart Van Assche wrote:
> I am aware that commit 5c10e63c943b caused the behavior change. But that
> doesn't mean that a fix has to undo the changes introduced by that
> commit. We do not only want to make sure that the SCSI core works as
> intended but also that th
On 12/06/16 19:41, Wei Fang wrote:
> On 2016/12/7 10:45, Bart Van Assche wrote:
>> The purpose of the scsi_device_set_state(sdev, SDEV_RUNNING) call in
>> scsi_sysfs_add_sdev() is to change the device state from SDEV_CREATED
>> into SDEV_RUNNING. Have you tried to modify scsi_sysfs_add_sdev() such
Hi, Bart,
On 2016/12/7 10:45, Bart Van Assche wrote:
> On 12/06/16 17:21, Wei Fang wrote:
>> The state of the scsi device first is changed to SDEV_BLOCK in
>> scsi_add_lun() as you mentioned, then it will be changed to SDEV_RUNNING
>> in scsi_sysfs_add_sdev().
>
> Hello Wei,
>
> The purpose of t
On 12/06/16 17:21, Wei Fang wrote:
> The state of the scsi device first is changed to SDEV_BLOCK in
> scsi_add_lun() as you mentioned, then it will be changed to SDEV_RUNNING
> in scsi_sysfs_add_sdev().
Hello Wei,
The purpose of the scsi_device_set_state(sdev, SDEV_RUNNING) call in
scsi_sysfs_ad
Hi, Bart,
On 2016/12/6 23:51, Bart Van Assche wrote:
> On 12/06/16 01:12, Wei Fang wrote:
>> The scsi device is being setted to the SDEV_RUNNING state at the end of
>> the scan work. When the remote port reappears, scsi_target_unblock()
>> will be called, but the QUEUE_FLAG_STOPPED flag will not b
On 12/06/16 01:12, Wei Fang wrote:
> The scsi device is being setted to the SDEV_RUNNING state at the end of
> the scan work. When the remote port reappears, scsi_target_unblock()
> will be called, but the QUEUE_FLAG_STOPPED flag will not be cleared,
> since scsi_internal_device_unblock() ignores S
21 matches
Mail list logo
