Re: [PATCH resend 5/5] libata-scsi: fix MODE SELECT translation for Control mode page

On Fri, Jul 22, 2016 at 02:41:54AM +0800, tom.t...@gmail.com wrote: > From: Tom Yan > > scsi_done() was called repeatedly and apparently because of that, > the kernel would call trace when we touch the Control mode page: > > Call Trace: > [] dump_stack+0x63/0x81 > []

Re: [PATCH resend 5/5] libata-scsi: fix MODE SELECT translation for Control mode page

On Fri, Jul 22, 2016 at 02:41:54AM +0800, tom.t...@gmail.com wrote: > From: Tom Yan > > scsi_done() was called repeatedly and apparently because of that, > the kernel would call trace when we touch the Control mode page: > > Call Trace: > [] dump_stack+0x63/0x81 > [] __warn+0xcb/0xf0 > []

Re: [PATCH resend 5/5] libata-scsi: fix MODE SELECT translation for Control mode page

Yes, because it touches an actual ATA drive setting, while D_SENSE is merely a "software setting" stored in dev->flags to make the kernel response differently when build sense data. On 26 July 2016 at 02:30, Tejun Heo wrote: > On Fri, Jul 22, 2016 at 05:50:18AM +0800, Tom Yan

Re: [PATCH resend 5/5] libata-scsi: fix MODE SELECT translation for Control mode page

Yes, because it touches an actual ATA drive setting, while D_SENSE is merely a "software setting" stored in dev->flags to make the kernel response differently when build sense data. On 26 July 2016 at 02:30, Tejun Heo wrote: > On Fri, Jul 22, 2016 at 05:50:18AM +0800, Tom Yan wrote: >> As I've

Re: [PATCH resend 5/5] libata-scsi: fix MODE SELECT translation for Control mode page

On Fri, Jul 22, 2016 at 05:50:18AM +0800, Tom Yan wrote: > As I've mentioned in the comment/message, there is no ATA command > needed to be sent to the device, since it only toggles a bit in > dev->flags. See that there is no ata_taskfile constructed in > ata_mselect_control(). But

Re: [PATCH resend 5/5] libata-scsi: fix MODE SELECT translation for Control mode page

On Fri, Jul 22, 2016 at 05:50:18AM +0800, Tom Yan wrote: > As I've mentioned in the comment/message, there is no ATA command > needed to be sent to the device, since it only toggles a bit in > dev->flags. See that there is no ata_taskfile constructed in > ata_mselect_control(). But

Re: [PATCH resend 5/5] libata-scsi: fix MODE SELECT translation for Control mode page

As I've mentioned in the comment/message, there is no ATA command needed to be sent to the device, since it only toggles a bit in dev->flags. See that there is no ata_taskfile constructed in ata_mselect_control(). On 22 July 2016 at 05:26, Tejun Heo wrote: > On Fri, Jul 22, 2016

Re: [PATCH resend 5/5] libata-scsi: fix MODE SELECT translation for Control mode page

As I've mentioned in the comment/message, there is no ATA command needed to be sent to the device, since it only toggles a bit in dev->flags. See that there is no ata_taskfile constructed in ata_mselect_control(). On 22 July 2016 at 05:26, Tejun Heo wrote: > On Fri, Jul 22, 2016 at 02:41:54AM

Re: [PATCH resend 5/5] libata-scsi: fix MODE SELECT translation for Control mode page

On Fri, Jul 22, 2016 at 02:41:54AM +0800, tom.t...@gmail.com wrote: > @@ -3854,6 +3852,8 @@ static unsigned int ata_scsi_mode_select_xlat(struct > ata_queued_cmd *qc) > if (ata_mselect_control(qc, p, pg_len, ) < 0) { > fp += hdr_len + bd_len; >

Re: [PATCH resend 5/5] libata-scsi: fix MODE SELECT translation for Control mode page

On Fri, Jul 22, 2016 at 02:41:54AM +0800, tom.t...@gmail.com wrote: > @@ -3854,6 +3852,8 @@ static unsigned int ata_scsi_mode_select_xlat(struct > ata_queued_cmd *qc) > if (ata_mselect_control(qc, p, pg_len, ) < 0) { > fp += hdr_len + bd_len; >

[PATCH resend 5/5] libata-scsi: fix MODE SELECT translation for Control mode page

From: Tom Yan scsi_done() was called repeatedly and apparently because of that, the kernel would call trace when we touch the Control mode page: Call Trace: [] dump_stack+0x63/0x81 [] __warn+0xcb/0xf0 [] warn_slowpath_null+0x1d/0x20 [] ata_eh_finish+0xe0/0xf0 [libata]

[PATCH resend 5/5] libata-scsi: fix MODE SELECT translation for Control mode page

From: Tom Yan scsi_done() was called repeatedly and apparently because of that, the kernel would call trace when we touch the Control mode page: Call Trace: [] dump_stack+0x63/0x81 [] __warn+0xcb/0xf0 [] warn_slowpath_null+0x1d/0x20 [] ata_eh_finish+0xe0/0xf0 [libata] []