Re: [GIT PULL] SCSI fixes for 4.9-rc3
On 12.11.2016 02:08, Kashyap Desai wrote:
>> -Original Message-
>> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
>> ow...@vger.kernel.org] On Behalf Of Gabriel C
>> Sent: Friday, November 11, 2016 9:40 AM
>> To: James Bottomley; Andrew Morton; Linus Torvalds
>> Cc: linux-scsi; linux-kernel; sta...@vger.kernel.org
>> Subject: Re: [GIT PULL] SCSI fixes for 4.9-rc3
>>
>>
>>
>> On 11.11.2016 04:30, Gabriel C wrote:
>>>
>>> On 05.11.2016 14:29, James Bottomley wrote:
>>>
>>>
>>> ...
>>>
>>>> Kashyap Desai (1):
>>>> scsi: megaraid_sas: Fix data integrity failure for JBOD
>>>> (passthrough) devices
>>>>
>>>> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>>>> b/drivers/scsi/megaraid/megaraid_sas_base.c
>>>> index 9ff57de..d8b1fbd 100644
>>>> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
>>>> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>>>> @@ -1700,16 +1700,13 @@ megasas_queue_command(struct Scsi_Host
>> *shost, struct scsi_cmnd *scmd)
>>>>goto out_done;
>>>>}
>>>>
>>>> - switch (scmd->cmnd[0]) {
>>>> - case SYNCHRONIZE_CACHE:
>>>> - /*
>>>> - * FW takes care of flush cache on its own
>>>> - * No need to send it down
>>>> - */
>>>> + /*
>>>> + * FW takes care of flush cache on its own for Virtual Disk.
>>>> + * No need to send it down for VD. For JBOD send
>> SYNCHRONIZE_CACHE to FW.
>>>> + */
>>>> + if ((scmd->cmnd[0] == SYNCHRONIZE_CACHE) &&
>>>> +MEGASAS_IS_LOGICAL(scmd)) {
>>>>scmd->result = DID_OK << 16;
>>>>goto out_done;
>>>> - default:
>>>> - break;
>>>>}
>>>>
>>>>return instance->instancet->build_and_issue_cmd(instance, scmd);
>>>
>>> This patch breaks my box.. I'm not able to boot it anymore.
>>> It seems with this patch I have /dev/sda[a-z] to /dev/sdz[a-z] ?!?
>>>
>>> I'm not sure how to get an log since dracut times out and I'm dropped
>>> , after a very long time of probing 'ghost devices', in a emercency
>>> shell,
>> journalctl doesn't work also..
>>>
>>> After reverting this one I can boot normal.
>>>
>>> Box is a FUJITSU PRIMERGY TX200 S5..
>
> Please check now commit. Below commit has complete fix.
>
> http://git.kernel.org/cgit/linux/kernel/git/jejb/scsi.git/commit/?id=5e5ec1759dd663a1d5a2f10930224dd009e500e8
>
This patch fixes the problem for me. Thank you.
Regards,
Gabriel C
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] SCSI fixes for 4.9-rc3
On 11.11.2016 04:30, Gabriel C wrote:
>
> On 05.11.2016 14:29, James Bottomley wrote:
>
>
> ...
>
>> Kashyap Desai (1):
>> scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough)
>> devices
>>
>> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>> b/drivers/scsi/megaraid/megaraid_sas_base.c
>> index 9ff57de..d8b1fbd 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
>> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>> @@ -1700,16 +1700,13 @@ megasas_queue_command(struct Scsi_Host *shost,
>> struct scsi_cmnd *scmd)
>> goto out_done;
>> }
>>
>> -switch (scmd->cmnd[0]) {
>> -case SYNCHRONIZE_CACHE:
>> -/*
>> - * FW takes care of flush cache on its own
>> - * No need to send it down
>> - */
>> +/*
>> + * FW takes care of flush cache on its own for Virtual Disk.
>> + * No need to send it down for VD. For JBOD send SYNCHRONIZE_CACHE to
>> FW.
>> + */
>> +if ((scmd->cmnd[0] == SYNCHRONIZE_CACHE) && MEGASAS_IS_LOGICAL(scmd)) {
>> scmd->result = DID_OK << 16;
>> goto out_done;
>> -default:
>> -break;
>> }
>>
>> return instance->instancet->build_and_issue_cmd(instance, scmd);
>
> This patch breaks my box.. I'm not able to boot it anymore.
> It seems with this patch I have /dev/sda[a-z] to /dev/sdz[a-z] ?!?
>
> I'm not sure how to get an log since dracut times out and I'm dropped , after
> a very long time
> of probing 'ghost devices', in a emercency shell, journalctl doesn't work
> also..
>
> After reverting this one I can boot normal.
>
> Box is a FUJITSU PRIMERGY TX200 S5..
>
> This is from an working kernel..
>
> [5.119371] megaraid_sas :01:00.0: FW now in Ready state
> [5.119418] megaraid_sas :01:00.0: firmware supports msix: (0)
> [5.119420] megaraid_sas :01:00.0: current msix/online cpus :
> (1/16)
> [5.119422] megaraid_sas :01:00.0: RDPQ mode : (disabled)
> [5.123100] ehci-pci :00:1a.7: cache line size of 32 is not supported
> [5.123113] ehci-pci :00:1a.7: irq 18, io mem 0xb002
>
> ...
>
> [5.208063] megaraid_sas :01:00.0: controller type : MR(256MB)
> [5.208065] megaraid_sas :01:00.0: Online Controller Reset(OCR) :
> Enabled
> [5.208067] megaraid_sas :01:00.0: Secure JBOD support : No
> [5.208070] megaraid_sas :01:00.0: megasas_init_mfi: fw_support_ieee=0
> [5.208073] megaraid_sas :01:00.0: INIT adapter done
> [5.208075] megaraid_sas :01:00.0: Jbod map is not supported
> megasas_setup_jbod_map 4967
> [5.230163] megaraid_sas :01:00.0: MR_DCMD_PD_LIST_QUERY failed/not
> supported by firmware
> [5.252080] megaraid_sas :01:00.0: DCMD not supported by firmware -
> megasas_ld_list_query 4369
> [5.274086] megaraid_sas :01:00.0: pci id:
> (0x1000)/(0x0060)/(0x1734)/(0x10f9)
> [5.274089] megaraid_sas :01:00.0: unevenspan support: no
> [5.274090] megaraid_sas :01:00.0: firmware crash dump : no
> [5.274092] megaraid_sas :01:00.0: jbod sync map : no
> [5.274094] scsi host0: Avago SAS based MegaRAID driver
> [5.280022] scsi 0:0:6:0: Direct-Access ATA WDC WD5002ABYS-5 3B06
> PQ: 0 ANSI: 5
> [5.282153] scsi 0:0:7:0: Direct-Access ATA WDC WD5002ABYS-5 3B06
> PQ: 0 ANSI: 5
> [5.285180] scsi 0:0:10:0: Direct-Access ATA ST500NM0011
> FTM6 PQ: 0 ANSI: 5
> [5.369885] scsi 0:2:0:0: Direct-Access LSI MegaRAID SAS RMB 1.40
> PQ: 0 ANSI: 5
>
> ..
>
> Please let me know if you need more infos and/or want me to test patches.
>
>
I managed to get some parts of the broken dmesg. There it is :
http://ftp.frugalware.org/pub/other/people/crazy/kernel/broken-dmesg
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] SCSI fixes for 4.9-rc3
On 05.11.2016 14:29, James Bottomley wrote:
...
> Kashyap Desai (1):
> scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough)
> devices
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index 9ff57de..d8b1fbd 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -1700,16 +1700,13 @@ megasas_queue_command(struct Scsi_Host *shost, struct
> scsi_cmnd *scmd)
> goto out_done;
> }
>
> - switch (scmd->cmnd[0]) {
> - case SYNCHRONIZE_CACHE:
> - /*
> - * FW takes care of flush cache on its own
> - * No need to send it down
> - */
> + /*
> + * FW takes care of flush cache on its own for Virtual Disk.
> + * No need to send it down for VD. For JBOD send SYNCHRONIZE_CACHE to
> FW.
> + */
> + if ((scmd->cmnd[0] == SYNCHRONIZE_CACHE) && MEGASAS_IS_LOGICAL(scmd)) {
> scmd->result = DID_OK << 16;
> goto out_done;
> - default:
> - break;
> }
>
> return instance->instancet->build_and_issue_cmd(instance, scmd);
This patch breaks my box.. I'm not able to boot it anymore.
It seems with this patch I have /dev/sda[a-z] to /dev/sdz[a-z] ?!?
I'm not sure how to get an log since dracut times out and I'm dropped , after a
very long time
of probing 'ghost devices', in a emercency shell, journalctl doesn't work also..
After reverting this one I can boot normal.
Box is a FUJITSU PRIMERGY TX200 S5..
This is from an working kernel..
[5.119371] megaraid_sas :01:00.0: FW now in Ready state
[5.119418] megaraid_sas :01:00.0: firmware supports msix: (0)
[5.119420] megaraid_sas :01:00.0: current msix/online cpus : (1/16)
[5.119422] megaraid_sas :01:00.0: RDPQ mode : (disabled)
[5.123100] ehci-pci :00:1a.7: cache line size of 32 is not supported
[5.123113] ehci-pci :00:1a.7: irq 18, io mem 0xb002
...
[5.208063] megaraid_sas :01:00.0: controller type : MR(256MB)
[5.208065] megaraid_sas :01:00.0: Online Controller Reset(OCR) :
Enabled
[5.208067] megaraid_sas :01:00.0: Secure JBOD support : No
[5.208070] megaraid_sas :01:00.0: megasas_init_mfi: fw_support_ieee=0
[5.208073] megaraid_sas :01:00.0: INIT adapter done
[5.208075] megaraid_sas :01:00.0: Jbod map is not supported
megasas_setup_jbod_map 4967
[5.230163] megaraid_sas :01:00.0: MR_DCMD_PD_LIST_QUERY failed/not
supported by firmware
[5.252080] megaraid_sas :01:00.0: DCMD not supported by firmware -
megasas_ld_list_query 4369
[5.274086] megaraid_sas :01:00.0: pci id:
(0x1000)/(0x0060)/(0x1734)/(0x10f9)
[5.274089] megaraid_sas :01:00.0: unevenspan support: no
[5.274090] megaraid_sas :01:00.0: firmware crash dump : no
[5.274092] megaraid_sas :01:00.0: jbod sync map : no
[5.274094] scsi host0: Avago SAS based MegaRAID driver
[5.280022] scsi 0:0:6:0: Direct-Access ATA WDC WD5002ABYS-5 3B06
PQ: 0 ANSI: 5
[5.282153] scsi 0:0:7:0: Direct-Access ATA WDC WD5002ABYS-5 3B06
PQ: 0 ANSI: 5
[5.285180] scsi 0:0:10:0: Direct-Access ATA ST500NM0011 FTM6
PQ: 0 ANSI: 5
[5.369885] scsi 0:2:0:0: Direct-Access LSI MegaRAID SAS RMB 1.40
PQ: 0 ANSI: 5
..
Please let me know if you need more infos and/or want me to test patches.
Best Regards,
Gabriel C
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc3-mm1: I/O error, system hangs
James Bottomley wrote: On Sat, 2007-11-24 at 13:57 +0100, Laurent Riffard wrote: Le 24.11.2007 07:42, James Bottomley a écrit : On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote: Le 23.11.2007 12:38, Hannes Reinecke a écrit : Hannes Reinecke wrote: Laurent Riffard wrote: Le 21.11.2007 23:41, Andrew Morton a écrit : On Wed, 21 Nov 2007 22:45:22 +0100 Laurent Riffard [EMAIL PROTECTED] wrote: Le 21.11.2007 05:45, Andrew Morton a écrit : ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/ Hello, My system hangs shortly after I logged in Gnome desktop. SysRq-W shows that a bunch of task are blocked in D state, they seem to wait for some I/O completion. I can try to hand-copy some data if requested. I found these messages in dmesg: ~$ grep -C2 end_request dmesg-2.6.24-rc3-mm1 EXT3-fs: mounted filesystem with ordered data mode. sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK end_request: I/O error, dev sda, sector 16460 ReiserFS: sda7: found reiserfs format 3.6 with standard journal ReiserFS: sda7: using ordered data mode -- ReiserFS: sda7: Using r5 hash to sort names sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK end_request: I/O error, dev sdb, sector 19632 sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK end_request: I/O error, dev sdb, sector 40037363 Adding 1048568k swap on /dev/mapper/vglinux1-lvswap. Priority:-1 extents:1 across:1048568k lp0: using parport0 (interrupt-driven). These errors occur *only* with 2.6.24-rc3-mm1, they are 100% reproducible. 2.6.24-rc3 and 2.6.24-rc2-mm1 are fine. Maybe something is broken in pata_via driver ? Could be - libata-reimplement-ata_acpi_cbl_80wire-using-ata_acpi_gtm_xfermask.patch and pata_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch touch pata_via.c. None of the above... I did a bisection, it spotted git-scsi-misc.patch. I just run 2.6.24-rc3-mm1 + revert-git-scsi-misc.patch, and it works fine. I guess commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 [SCSI] Do not requeue requests if REQ_FAILFAST is set is the real culprit. The other commits are touching documentation or drivers I don't use. I'll try to revert only this one this evening. I can confirm : reverting commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 does fix the problem. Hmm. Weird. I'll have a look into it. Apparently I'll be returning an error where I shouldn't. Checking ... Ok, found it. We are blocking even special commands (ie requests with PREEMPT not set) when FAILFAST is set. Which is clearly wrong. The attached patch fixes this. Sorry, it's not enough. 2.6.24-rc3-mm1 + your patch still hangs with I/O errors. I think the problem is the way we treat BLOCKED and QUIESCED (the latter is the state that the domain validation uses and which we cannot kill fastfail on). It's definitely wrong to kill fastfail requests when the state is QUIESCE. This patch (which is applied on top of Hannes original) separates the BLOCK and QUIESCE states correctly ... does this fix the problem? No, it doesn't help... (2.6.24-rc3-mm1 + your patch still has problems) OK, could you post dmesgs again, please. I actually tested this with an aic79xx card, and for me it does cause Domain Validation to succeed again. Are the patches indeed to fix that problem as well ? http://lkml.org/lkml/2007/11/23/5 James Gabriel - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc3-mm1: I/O error, system hangs
James Bottomley wrote: On Sat, 2007-11-24 at 18:54 +0100, Gabriel C wrote: James Bottomley wrote: On Sat, 2007-11-24 at 13:57 +0100, Laurent Riffard wrote: Le 24.11.2007 07:42, James Bottomley a écrit : On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote: Le 23.11.2007 12:38, Hannes Reinecke a écrit : Hannes Reinecke wrote: Laurent Riffard wrote: Le 21.11.2007 23:41, Andrew Morton a écrit : On Wed, 21 Nov 2007 22:45:22 +0100 Laurent Riffard [EMAIL PROTECTED] wrote: Le 21.11.2007 05:45, Andrew Morton a écrit : ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/ Hello, My system hangs shortly after I logged in Gnome desktop. SysRq-W shows that a bunch of task are blocked in D state, they seem to wait for some I/O completion. I can try to hand-copy some data if requested. I found these messages in dmesg: ~$ grep -C2 end_request dmesg-2.6.24-rc3-mm1 EXT3-fs: mounted filesystem with ordered data mode. sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK end_request: I/O error, dev sda, sector 16460 ReiserFS: sda7: found reiserfs format 3.6 with standard journal ReiserFS: sda7: using ordered data mode -- ReiserFS: sda7: Using r5 hash to sort names sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK end_request: I/O error, dev sdb, sector 19632 sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK end_request: I/O error, dev sdb, sector 40037363 Adding 1048568k swap on /dev/mapper/vglinux1-lvswap. Priority:-1 extents:1 across:1048568k lp0: using parport0 (interrupt-driven). These errors occur *only* with 2.6.24-rc3-mm1, they are 100% reproducible. 2.6.24-rc3 and 2.6.24-rc2-mm1 are fine. Maybe something is broken in pata_via driver ? Could be - libata-reimplement-ata_acpi_cbl_80wire-using-ata_acpi_gtm_xfermask.patch and pata_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch touch pata_via.c. None of the above... I did a bisection, it spotted git-scsi-misc.patch. I just run 2.6.24-rc3-mm1 + revert-git-scsi-misc.patch, and it works fine. I guess commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 [SCSI] Do not requeue requests if REQ_FAILFAST is set is the real culprit. The other commits are touching documentation or drivers I don't use. I'll try to revert only this one this evening. I can confirm : reverting commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 does fix the problem. Hmm. Weird. I'll have a look into it. Apparently I'll be returning an error where I shouldn't. Checking ... Ok, found it. We are blocking even special commands (ie requests with PREEMPT not set) when FAILFAST is set. Which is clearly wrong. The attached patch fixes this. Sorry, it's not enough. 2.6.24-rc3-mm1 + your patch still hangs with I/O errors. I think the problem is the way we treat BLOCKED and QUIESCED (the latter is the state that the domain validation uses and which we cannot kill fastfail on). It's definitely wrong to kill fastfail requests when the state is QUIESCE. This patch (which is applied on top of Hannes original) separates the BLOCK and QUIESCE states correctly ... does this fix the problem? No, it doesn't help... (2.6.24-rc3-mm1 + your patch still has problems) OK, could you post dmesgs again, please. I actually tested this with an aic79xx card, and for me it does cause Domain Validation to succeed again. Are the patches indeed to fix that problem as well ? http://lkml.org/lkml/2007/11/23/5 That dmesg is from an unknown SCSI card exhibiting Domain Validation problems, so it's a reasonable probability, yes ... but you'll need the additional hack I just did to prevent further intermittent failures. My controller is: 03:0e.0 SCSI storage controller [0100]: Adaptec AIC-7892P U160/m [9005:008f] (rev 02) I'll try the patches in a bit. James Gabriel - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc3-mm1: I/O error, system hangs
Gabriel C wrote: James Bottomley wrote: On Sat, 2007-11-24 at 18:54 +0100, Gabriel C wrote: James Bottomley wrote: On Sat, 2007-11-24 at 13:57 +0100, Laurent Riffard wrote: Le 24.11.2007 07:42, James Bottomley a écrit : On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote: Le 23.11.2007 12:38, Hannes Reinecke a écrit : Hannes Reinecke wrote: Laurent Riffard wrote: Le 21.11.2007 23:41, Andrew Morton a écrit : On Wed, 21 Nov 2007 22:45:22 +0100 Laurent Riffard [EMAIL PROTECTED] wrote: Le 21.11.2007 05:45, Andrew Morton a écrit : ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/ Hello, My system hangs shortly after I logged in Gnome desktop. SysRq-W shows that a bunch of task are blocked in D state, they seem to wait for some I/O completion. I can try to hand-copy some data if requested. I found these messages in dmesg: ~$ grep -C2 end_request dmesg-2.6.24-rc3-mm1 EXT3-fs: mounted filesystem with ordered data mode. sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK end_request: I/O error, dev sda, sector 16460 ReiserFS: sda7: found reiserfs format 3.6 with standard journal ReiserFS: sda7: using ordered data mode -- ReiserFS: sda7: Using r5 hash to sort names sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK end_request: I/O error, dev sdb, sector 19632 sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK end_request: I/O error, dev sdb, sector 40037363 Adding 1048568k swap on /dev/mapper/vglinux1-lvswap. Priority:-1 extents:1 across:1048568k lp0: using parport0 (interrupt-driven). These errors occur *only* with 2.6.24-rc3-mm1, they are 100% reproducible. 2.6.24-rc3 and 2.6.24-rc2-mm1 are fine. Maybe something is broken in pata_via driver ? Could be - libata-reimplement-ata_acpi_cbl_80wire-using-ata_acpi_gtm_xfermask.patch and pata_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch touch pata_via.c. None of the above... I did a bisection, it spotted git-scsi-misc.patch. I just run 2.6.24-rc3-mm1 + revert-git-scsi-misc.patch, and it works fine. I guess commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 [SCSI] Do not requeue requests if REQ_FAILFAST is set is the real culprit. The other commits are touching documentation or drivers I don't use. I'll try to revert only this one this evening. I can confirm : reverting commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 does fix the problem. Hmm. Weird. I'll have a look into it. Apparently I'll be returning an error where I shouldn't. Checking ... Ok, found it. We are blocking even special commands (ie requests with PREEMPT not set) when FAILFAST is set. Which is clearly wrong. The attached patch fixes this. Sorry, it's not enough. 2.6.24-rc3-mm1 + your patch still hangs with I/O errors. I think the problem is the way we treat BLOCKED and QUIESCED (the latter is the state that the domain validation uses and which we cannot kill fastfail on). It's definitely wrong to kill fastfail requests when the state is QUIESCE. This patch (which is applied on top of Hannes original) separates the BLOCK and QUIESCE states correctly ... does this fix the problem? No, it doesn't help... (2.6.24-rc3-mm1 + your patch still has problems) OK, could you post dmesgs again, please. I actually tested this with an aic79xx card, and for me it does cause Domain Validation to succeed again. Are the patches indeed to fix that problem as well ? http://lkml.org/lkml/2007/11/23/5 That dmesg is from an unknown SCSI card exhibiting Domain Validation problems, so it's a reasonable probability, yes ... but you'll need the additional hack I just did to prevent further intermittent failures. My controller is: 03:0e.0 SCSI storage controller [0100]: Adaptec AIC-7892P U160/m [9005:008f] (rev 02) I'll try the patches in a bit. With your patches my problem(s) are solved. Domain Validation works again. ... [ 32.179521] scsi 0:0:0:0: Direct-Access SEAGATE ST318406LW 0109 PQ: 0 ANSI: 3 [ 32.179540] scsi0:A:0:0: Tagged Queuing enabled. Depth 32 [ 32.179554] target0:0:0: Beginning Domain Validation [ 32.188553] target0:0:0: wide asynchronous [ 32.195302] target0:0:0: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 63) [ 32.206510] target0:0:0: Ending Domain Validation [ 32.211699] scsi 0:0:1:0: Direct-Access FUJITSU MAH3182MP0114 PQ: 0 ANSI: 4 [ 32.211707] scsi0:A:1:0: Tagged Queuing enabled. Depth 32 [ 32.211717] target0:0:1: Beginning Domain Validation [ 32.213980] target0:0:1: wide asynchronous [ 32.215682] target0:0:1: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 127) [ 32.220205] target0:0:1: Ending Domain Validation ... Thx James :) Gabriel - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL
Re: 2.6.24-rc3-mm1
I have some warnings on each SCSI disc: ... [ 30.724410] scsi 0:0:0:0: Direct-Access SEAGATE ST318406LW 0109 PQ: 0 ANSI: 3 [ 30.724419] scsi0:A:0:0: Tagged Queuing enabled. Depth 32 [ 30.724435] target0:0:0: Beginning Domain Validation [ 30.724446] target0:0:0: Domain Validation Initial Inquiry Failed -- [ 30.724572] target0:0:0: Ending Domain Validation [ 30.729747] scsi 0:0:1:0: Direct-Access FUJITSU MAH3182MP0114 PQ: 0 ANSI: 4 [ 30.729754] scsi0:A:1:0: Tagged Queuing enabled. Depth 32 [ 30.729771] target0:0:1: Beginning Domain Validation [ 30.729780] target0:0:1: Domain Validation Initial Inquiry Failed -- [ 30.729908] target0:0:1: Ending Domain Validation ... no idea whatever this is related but buffered disk reads are 2.XX MB/sec and the box is somewhat laggy. hdparm -t on sda and sdb reports : /dev/sda: Timing buffered disk reads:8 MB in 3.26 seconds = 2.46 MB/sec /dev/sdb: Timing buffered disk reads:8 MB in 3.56 seconds = 2.25 MB/sec My IDE discs are fine. Please let me know if you need my config or any other informations. Gabriel - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc3-mm1
Andrew Morton wrote: On Fri, 23 Nov 2007 02:39:08 +0100 Gabriel C [EMAIL PROTECTED] wrote: I have some warnings on each SCSI disc: ... [ 30.724410] scsi 0:0:0:0: Direct-Access SEAGATE ST318406LW 0109 PQ: 0 ANSI: 3 [ 30.724419] scsi0:A:0:0: Tagged Queuing enabled. Depth 32 [ 30.724435] target0:0:0: Beginning Domain Validation [ 30.724446] target0:0:0: Domain Validation Initial Inquiry Failed -- [ 30.724572] target0:0:0: Ending Domain Validation [ 30.729747] scsi 0:0:1:0: Direct-Access FUJITSU MAH3182MP 0114 PQ: 0 ANSI: 4 [ 30.729754] scsi0:A:1:0: Tagged Queuing enabled. Depth 32 [ 30.729771] target0:0:1: Beginning Domain Validation [ 30.729780] target0:0:1: Domain Validation Initial Inquiry Failed -- [ 30.729908] target0:0:1: Ending Domain Validation Don't know what would have caused that. But yes, something is wrong in scsi land. Actually I'm lucky the author didn't fix that FIXME in scsi_transport_spi.c and I still can boot ;) no idea whatever this is related but buffered disk reads are 2.XX MB/sec and the box is somewhat laggy. hdparm -t on sda and sdb reports : /dev/sda: Timing buffered disk reads:8 MB in 3.26 seconds = 2.46 MB/sec /dev/sdb: Timing buffered disk reads:8 MB in 3.56 seconds = 2.25 MB/sec My IDE discs are fine. Please let me know if you need my config or any other informations. And you're the second to report very slow scsi throughput in 2.6.24-rc3-mm1. I found the commit which cause these problems , it is in git-scsi-misc patch and reverting it fixes both problems for me. http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff_plain;h=8655a546c83fc43f0a73416bbd126d02de7ad6c0;hp=5bc717b6bdaaf52edf365eb7d9d8c89fec79df5d - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc2-mm1
Boaz Harrosh wrote:
On Thu, Nov 15 2007 at 19:15 +0200, Matthew Dharm [EMAIL PROTECTED] wrote:
On Wed, Nov 14, 2007 at 10:23:09AM +0100, Gabriel C wrote:
Matthew Dharm wrote:
On Wed, Nov 14, 2007 at 06:33:39AM +0100, Gabriel C wrote:
Matthew Dharm wrote:
On Tue, Nov 13, 2007 at 07:49:24PM -0800, Greg KH wrote:
Matt, are these the errors you were worried about with the patch we were
just talking about tha tis in my tree?
I can't tell from these logs.
There is the dmesg with CONFIG_USB_STORAGE_DEBUG :
http://194.231.229.228/dmesg-2.6.24-rc2-mm1
Good news: This isn't the bug Greg was worried about.
Bad news: Something is seriously strange here. Note the following from the
logs:
Nov 14 06:07:43 lara [ 41.890614] usb-storage: Bulk Status S 0x53425355
T 0xd R 0 Stat 0x0
Nov 14 06:07:43 lara [ 41.890616] usb-storage: -- unexpectedly short
transfer
Note the 'R' value of zero -- this is the residue value. It indicates a
complete transfer, and that matches the log lines immediately previous
which indicate a 4K transfer which completed properly.
If residue is zero, then srb-resid should be zero. Take a look in
linux/usb/storage/transport.c in usb_stor_Bulk_transport()
If srb-resid is zero, then you should NEVER get the unexpectedly short
transfer message. Look at usb_stor_invoke_transport() in the same file.
That code got replaced recently but I have no idea about it.
(
http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=shortlog
see the patches from Boaz Harrosh)
srb-resid got replaced by scsi_get_resid() it I see that right.
I'm CC'ing the author , he will know I think.
The replacement looks, to my eye, to be logically correct. The patch was
pretty clean.
Then again, I haven't looked at what is under the hood of the accessor
functions. Perhaps there is a side-effect somewhere in there?
Perhaps a quick debugging test -- print the value of scsi_get_resid(srb)
just after it's initialized to zero at the top of
usb_stor_invoke_transport(), and then just after the call to
us-transport().
I have found the bug. My bad sorry about that. Patch below
It is because I switched from use of usb_stor_bulk_transfer_sg()
to usb_stor_bulk_transfer_sglist, but forgot the residual handling.
Your patch fixes the problem. Thx.
(Please send scsi bugs to scsi list. My lkml mental filters are
much higher, Sorry for not seeing this yesterday)
Uhh sorry I forgot to CC linux-scsi =)
From: Boaz Harrosh [EMAIL PROTECTED]
Date: Thu, 15 Nov 2007 20:07:56 +0200
Subject: [PATCH] Fix bug in last usb accessor patch
Bad news: Something is seriously strange here. Note the following from the
logs:
Nov 14 06:07:43 lara [ 41.890614] usb-storage: Bulk Status S 0x53425355
T 0xd R 0 Stat 0x0
Nov 14 06:07:43 lara [ 41.890616] usb-storage: -- unexpectedly short
transfer
Note the 'R' value of zero -- this is the residue value. It indicates a
complete transfer, and that matches the log lines immediately previous
which indicate a 4K transfer which completed properly.
If residue is zero, then srb-resid should be zero. Take a look in
linux/usb/storage/transport.c in usb_stor_Bulk_transport()
If srb-resid is zero, then you should NEVER get the unexpectedly short
transfer message. Look at usb_stor_invoke_transport() in the same file.
That code got replaced recently but I have no idea about it.
wrong resid handling fixed
Signed-off-by: Boaz Harrosh [EMAIL PROTECTED]
---
drivers/usb/storage/transport.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c
index d3a84a2..d9f4912 100644
--- a/drivers/usb/storage/transport.c
+++ b/drivers/usb/storage/transport.c
@@ -465,11 +465,12 @@ static int usb_stor_bulk_transfer_sglist(struct us_data
*us, unsigned int pipe,
int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
struct scsi_cmnd* srb)
{
- int resid = scsi_get_resid(srb);
+ unsigned int partial;
int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
scsi_sg_count(srb), scsi_bufflen(srb),
- resid);
- scsi_set_resid(srb, resid);
+ partial);
+
+ scsi_set_resid(srb, scsi_bufflen(srb) - partial);
return result;
}
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
drivers/scsi/* compile warnings
Hi , on current git ( a3634d7169f56eca5e349fce2f1de228fc10efda ) I see the following compile warning from some scsi drivers. Someone may want to look at these :) ... --($:/work/crazy/linux-git/fresh-linux2.6)-- grep ^[a-z] build.log|grep scsi drivers/scsi/advansys.c:71:2: warning: #warning this driver is still not properly converted to the DMA API drivers/scsi/advansys.c: In function 'advansys_board_found': drivers/scsi/advansys.c:13874: warning: label 'err_shost' defined but not used drivers/scsi/advansys.c: At top level: drivers/scsi/advansys.c:11894: warning: 'Default_3550_EEPROM_Config' defined but not used drivers/scsi/advansys.c:11932: warning: 'ADVEEP_3550_Config_Field_IsChar' defined but not used drivers/scsi/advansys.c:11970: warning: 'Default_38C0800_EEPROM_Config' defined but not used drivers/scsi/advansys.c:12035: warning: 'ADVEEP_38C0800_Config_Field_IsChar' defined but not used drivers/scsi/advansys.c:12100: warning: 'Default_38C1600_EEPROM_Config' defined but not used drivers/scsi/advansys.c:12165: warning: 'ADVEEP_38C1600_Config_Field_IsChar' defined but not used drivers/scsi/advansys.c: In function 'advansys_board_found': drivers/scsi/advansys.c:13400: warning: 'share_irq' may be used uninitialized in this function drivers/scsi/advansys.c:13400: warning: 'ret' may be used uninitialized in this function drivers/scsi/ultrastor.c: In function 'find_and_clear_bit_16': drivers/scsi/ultrastor.c:303: warning: matching constraint does not allow a register drivers/scsi/ultrastor.c:302: warning: matching constraint does not allow a register drivers/scsi/ultrastor.c: In function 'ultrastor_host_reset': drivers/scsi/ultrastor.c:1013: warning: passing argument 1 of '__constant_c_and_count_memset' discards qualifiers from pointer target type drivers/scsi/ultrastor.c: At top level: drivers/scsi/ultrastor.c:1202: warning: matching constraint does not allow a register drivers/scsi/ultrastor.c:1202: warning: matching constraint does not allow a register drivers/scsi/ultrastor.c: In function 'ultrastor_queuecommand': drivers/scsi/ultrastor.c:698: warning: matching constraint does not allow a register drivers/scsi/ultrastor.c:698: warning: matching constraint does not allow a register drivers/scsi/ultrastor.c:698: warning: matching constraint does not allow a register drivers/scsi/ultrastor.c:698: warning: matching constraint does not allow a register drivers/scsi/ultrastor.c:698: warning: matching constraint does not allow a register drivers/scsi/ultrastor.c:698: warning: matching constraint does not allow a register drivers/scsi/ultrastor.c:698: warning: matching constraint does not allow a register drivers/scsi/ultrastor.c:698: warning: matching constraint does not allow a register drivers/scsi/ultrastor.c:302: warning: matching constraint does not allow a register drivers/scsi/ultrastor.c:302: warning: matching constraint does not allow a register drivers/scsi/aic7xxx_old.c:8902: warning: 'aic7xxx_configure_bugs' defined but not used drivers/scsi/aic7xxx_old.c: In function 'aic7xxx_free': drivers/scsi/aic7xxx_old.c:8490: warning: passing argument 3 of 'pci_free_consistent' discards qualifiers from pointer target type drivers/scsi/sym53c416.c: In function 'sym53c416_detect': drivers/scsi/sym53c416.c:638: warning: the address of 'sym53c416' will always evaluate as 'true' drivers/scsi/sym53c416.c:644: warning: the address of 'sym53c416_1' will always evaluate as 'true' drivers/scsi/sym53c416.c:650: warning: the address of 'sym53c416_2' will always evaluate as 'true' drivers/scsi/sym53c416.c:656: warning: the address of 'sym53c416_3' will always evaluate as 'true' ... sh scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux lara 2.6.24-rc1-g97855b49 #355 SMP Tue Oct 30 18:42:16 CET 2007 i686 Intel(R) Xeon(TM) CPU 2.00GHz GenuineIntel GNU/Linux Gnu C 4.2.2 Gnu make 3.81 binutils 2.18.50.0.2.20071001 util-linux 2.13 mount 2.13 module-init-tools 3.2.2 e2fsprogs 1.40.2 xfsprogs 2.9.4 pcmciautils014 quota-tools3.15. Linux C Library2.7 Dynamic linker (ldd) 2.7 Linux C++ Library 6.0.9 Procps 3.2.7 Net-tools 1.60 Kbd1.12 Sh-utils 6.9 udev 116 Modules Loaded fuse pc87360 hwmon_vid eeprom adm1021 sr_mod shpchp pci_hotplug iTCO_wdt iTCO_vendor_support intel_agp i82860_edac i2c_i801 edac_core cdrom agpgart 3c59x mii ext4dev jbd2 crc16 loop lp parport_pc parport evdev config is a allmodconfig with CONFIG_PCI and CONFIG_PM disabled. Regards, Gabriel - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] debloat aic7xxx and aic79xx drivers
Denys Vlasenko wrote: On Sunday 14 October 2007 18:47, Gabriel C wrote: Compile tested and applies cleanly to 2.6.23. I don't have this hardware anymore and cannot run test these patches. I can test these patches on an aic7892 controller later on today if you want. I'd appreciate that. Do you, by any chance, use aic94xx driver too (drivers/scsi/aic94xx/*)? After i'm done with aic7xxx, I may attack this one. Sorry I don't have any box uses this one , but I'll ask some friends maybe someone has :) BTW while you seems to care about this driver could you have a look at : http://bugzilla.kernel.org/show_bug.cgi?id=3062 ?!? I am a desktop Linux user, so far I don't use suspend at all. Sorry. Ok , no problem maybe one 'day' the SCSI folks cares ( where the 'day' may be never ), I dunno :( -- vda Gabriel - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] debloat aic7xxx and aic79xx drivers
Denys Vlasenko wrote: Hi, Hi, Compile tested and applies cleanly to 2.6.23. I don't have this hardware anymore and cannot run test these patches. I can test these patches on an aic7892 controller later on today if you want. BTW while you seems to care about this driver could you have a look at : http://bugzilla.kernel.org/show_bug.cgi?id=3062 ?!? Regards, Gabriel C - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: drivers/scsi/advansys.c - ld error ( Re: 2.6.23-rc3-mm1 )
Matthew Wilcox wrote:
On Wed, Aug 22, 2007 at 06:15:14PM +0200, Gabriel C wrote:
advansys.c:(.init.text+0x38ea): undefined reference to `isa_register_driver'
I guess advansys_{init,exit} is missing some #ifdef's ..
That's one conclusion. I prefer to think that the ISA support should
behave the same as the PCI and EISA support:
Yes right , your patch fixes the problem.
When CONFIG_ISA is disabled, the isa_driver support will not be compiled
in. Define stubs so that we don't get link-time errors.
Signed-off-by: Matthew Wilcox [EMAIL PROTECTED]
diff --git a/include/linux/isa.h b/include/linux/isa.h
index 1b85533..b0270e3 100644
--- a/include/linux/isa.h
+++ b/include/linux/isa.h
@@ -22,7 +22,18 @@ struct isa_driver {
#define to_isa_driver(x) container_of((x), struct isa_driver, driver)
+#ifdef CONFIG_ISA
int isa_register_driver(struct isa_driver *, unsigned int);
void isa_unregister_driver(struct isa_driver *);
+#else
+static inline int isa_register_driver(struct isa_driver *d, unsigned int i)
+{
+ return 0;
+}
+
+static inline void isa_unregister_driver(struct isa_driver *d)
+{
+}
+#endif
#endif /* __LINUX_ISA_H */
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23-rc2-mm2
Andrew Morton wrote: On Fri, 10 Aug 2007 14:35:01 +0200 Gabriel C [EMAIL PROTECTED] wrote: In file included from include/linux/blkdev.h:17, from kernel/sched.c:45: include/linux/bsg.h:67: warning: 'struct request_queue' declared inside parameter list include/linux/bsg.h:67: warning: its scope is only this definition or declaration, which is probably not what you want include/linux/bsg.h:71: warning: 'struct request_queue' declared inside parameter list Thanks, I'll fix that up. I just realized this problem exists in mainline too , introduced by this commit : http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a4ee0df8b3d007f0d685d38a56dc0b91e01aaaf7;hp=2cd614c8732172524c36cd5245620338928062b6 - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23-rc2-mm2
Some new warnings here :
...
In file included from include/linux/blkdev.h:17,
from kernel/sched.c:45:
include/linux/bsg.h:67: warning: 'struct request_queue' declared inside
parameter list
include/linux/bsg.h:67: warning: its scope is only this definition or
declaration, which is probably not what you want
include/linux/bsg.h:71: warning: 'struct request_queue' declared inside
parameter list
...
In file included from include/linux/blkdev.h:17,
from mm/filemap.c:29:
include/linux/bsg.h:67: warning: 'struct request_queue' declared inside
parameter list
include/linux/bsg.h:67: warning: its scope is only this definition or
declaration, which is probably not what you want
include/linux/bsg.h:71: warning: 'struct request_queue' declared inside
parameter list
...
Some more of these , all from bsg.h:{67,71}
config there :
http://194.231.229.228/kernel/mm/2.6.23-rc2-mm2/randconfig-auto-5
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers/scsi/advansys.c: fix advansys_board_found compile error
Eugene Teo wrote: Hi Gabriel, Hi Eugene, Hope the following trivial patch helps. Yes it does , thx. quote sender=Gabriel C Getting this with a randconfig ( http://194.231.229.228/MM/randconfig-auto-10 ) [...] drivers/scsi/advansys.c:794:2: warning: #warning this driver is still not properly converted to the DMA API drivers/scsi/advansys.c: In function 'advansys_board_found': drivers/scsi/advansys.c:17781: error: implicit declaration of function 'to_pci_dev' [...] This patch fixes the following compile error: drivers/scsi/advansys.c: In function 'advansys_board_found': drivers/scsi/advansys.c:17781: error: implicit declaration of function 'to_pci_dev' Signed-off-by: Eugene Teo [EMAIL PROTECTED] --- drivers/scsi/advansys.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/scsi/advansys.c b/drivers/scsi/advansys.c index 79c0b6e..908f02b 100644 --- a/drivers/scsi/advansys.c +++ b/drivers/scsi/advansys.c @@ -774,6 +774,7 @@ #include linux/stat.h #include linux/spinlock.h #include linux/dma-mapping.h +#include linux/pci.h #include asm/io.h #include asm/system.h - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
drivers/scsi/advansys.c compile error ( Re: 2.6.23-rc1-mm2 )
Getting this with a randconfig ( http://194.231.229.228/MM/randconfig-auto-10 ) ... drivers/scsi/advansys.c:794:2: warning: #warning this driver is still not properly converted to the DMA API drivers/scsi/advansys.c: In function 'advansys_board_found': drivers/scsi/advansys.c:17781: error: implicit declaration of function 'to_pci_dev' drivers/scsi/advansys.c:17781: warning: pointer/integer type mismatch in conditional expression drivers/scsi/advansys.c:17788: warning: unused variable 'pci_memory_address' drivers/scsi/advansys.c:17781: warning: unused variable 'pdev' make[2]: *** [drivers/scsi/advansys.o] Error 1 make[1]: *** [drivers/scsi] Error 2 make[1]: *** Waiting for unfinished jobs ... - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers/scsi/advansys.c: fix advansys_board_found compile error
Matthew Wilcox wrote: On Wed, Aug 01, 2007 at 09:39:12PM +0800, Eugene Teo wrote: This patch fixes the following compile error: drivers/scsi/advansys.c: In function 'advansys_board_found': drivers/scsi/advansys.c:17781: error: implicit declaration of function 'to_pci_dev' Or just remove the ifdefs around the include ... which is done in this patch: http://www.kernel.org/pub/linux/kernel/people/willy/advansys-2007-07-30/0001-advansys-version-copyright-etc.txt I'd be interested in seeing the results of the randconfig trials on the driver with those 23 patches applied, but not particularly interested in the intermediate result. I can do that on weekend. Are the patches meant for -mm or git head ? - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers/scsi/advansys.c: fix advansys_board_found compile error
Matthew Wilcox wrote: On Wed, Aug 01, 2007 at 04:27:15PM +0200, Gabriel C wrote: Matthew Wilcox wrote: I'd be interested in seeing the results of the randconfig trials on the driver with those 23 patches applied, but not particularly interested in the intermediate result. I can do that on weekend. Thanks Are the patches meant for -mm or git head ? They were developed against git head as of a few days ago. Here's a git tree, if that's easier for you: http://git.kernel.org/?p=linux/kernel/git/willy/advansys.git;a=shortlog Ach nice , yes is a lot easier to work with git. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
BSG: BLK_DEV_BSG=y , BLOCK=n compile error
[1]: *** [block/bsg.o] Error 1 make: *** [block] Error 2 make: *** Waiting for unfinished jobs ... A solution would be to move 'endif # BLOCK' in block/Kconfig after config BLK_DEV_BSG and before source block/Kconfig.iosched but that would move BSG inside the BLOCK menu. Regards, Gabriel C - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BSG: BLK_DEV_BSG=y , BLOCK=n compile error
FUJITA Tomonori wrote: From: Gabriel C [EMAIL PROTECTED] Subject: BSG: BLK_DEV_BSG=y , BLOCK=n compile error Date: Sat, 28 Jul 2007 14:54:02 +0200 Hi, BSG does not compile without BLOCK set : Thanks, this has already been addressed. http://marc.info/?l=linux-kernelm=118534836402440w=2 Upss , sorry I didn't find that one is why I reported it. Gabriel - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
drivers/scsi/sym53c416.c - address of 'sym53c416*' will always evaluate as 'true' , warnings
Hi, I got this warnings on current git with gcc 4.2.1 : ... drivers/scsi/sym53c416.c: In function 'sym53c416_detect': drivers/scsi/sym53c416.c:638: warning: the address of 'sym53c416' will always evaluate as 'true' drivers/scsi/sym53c416.c:644: warning: the address of 'sym53c416_1' will always evaluate as 'true' drivers/scsi/sym53c416.c:650: warning: the address of 'sym53c416_2' will always evaluate as 'true' drivers/scsi/sym53c416.c:656: warning: the address of 'sym53c416_3' will always evaluate as 'true' ... Regards, Gabriel C - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drivers/scsi/g_NCR5380.c - NCR53C400_PSEUDO_DMA is not defined
Hi, got this warning with current git : ... In file included from drivers/scsi/g_NCR5380_mmio.c:9: drivers/scsi/g_NCR5380.c:559:5: warning: NCR53C400_PSEUDO_DMA is not defined ... Signed-off-by: Gabriel Craciunescu [EMAIL PROTECTED] --- diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c index 880f70d..607336f 100644 --- a/drivers/scsi/g_NCR5380.c +++ b/drivers/scsi/g_NCR5380.c @@ -556,7 +556,7 @@ generic_NCR5380_biosparam(struct scsi_device *sdev, struct block_device *bdev, } #endif -#if NCR53C400_PSEUDO_DMA +#ifdef NCR53C400_PSEUDO_DMA /** * NCR5380_pread - pseudo DMA read - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
drivers/scsi/ultrastor.c - matching constraint does not allow a register , warnings
Hi, I got this warnings on current git with gcc 4.2.1 : ... drivers/scsi/ultrastor.c: In function 'find_and_clear_bit_16': drivers/scsi/ultrastor.c:303: warning: matching constraint does not allow a register drivers/scsi/ultrastor.c:302: warning: matching constraint does not allow a register drivers/scsi/ultrastor.c: At top level: drivers/scsi/ultrastor.c:1201: warning: matching constraint does not allow a register drivers/scsi/ultrastor.c:1201: warning: matching constraint does not allow a register drivers/scsi/ultrastor.c: In function 'ultrastor_queuecommand': drivers/scsi/ultrastor.c:698: warning: matching constraint does not allow a register drivers/scsi/ultrastor.c:698: warning: matching constraint does not allow a register drivers/scsi/ultrastor.c:698: warning: matching constraint does not allow a register drivers/scsi/ultrastor.c:698: warning: matching constraint does not allow a register drivers/scsi/ultrastor.c:698: warning: matching constraint does not allow a register drivers/scsi/ultrastor.c:698: warning: matching constraint does not allow a register drivers/scsi/ultrastor.c:698: warning: matching constraint does not allow a register drivers/scsi/ultrastor.c:698: warning: matching constraint does not allow a register drivers/scsi/ultrastor.c:302: warning: matching constraint does not allow a register drivers/scsi/ultrastor.c:302: warning: matching constraint does not allow a register ... Regards, Gabriel C - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: drivers/scsi/sym53c416.c - address of 'sym53c416*' will always evaluate as 'true' , warnings
Matthew Wilcox wrote: On Sun, Jul 22, 2007 at 03:52:21PM +0200, Gabriel C wrote: drivers/scsi/sym53c416.c: In function 'sym53c416_detect': drivers/scsi/sym53c416.c:638: warning: the address of 'sym53c416' will always evaluate as 'true' drivers/scsi/sym53c416.c:644: warning: the address of 'sym53c416_1' will always evaluate as 'true' drivers/scsi/sym53c416.c:650: warning: the address of 'sym53c416_2' will always evaluate as 'true' drivers/scsi/sym53c416.c:656: warning: the address of 'sym53c416_3' will always evaluate as 'true' These warnings certainly indicate a problem; I've looked through the driver and it's a bit of a mess. Do you have one of these cards? I can write and send you some patches to test on Monday or Tuesday, after I'm done with the advansys driver. Sorry , I don't have these cards :/ Regards, Gabriel - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Someone ( bsg merge ? ) broke {sd,hd}parm on current git
James Bottomley wrote:
On Thu, 2007-07-19 at 08:25 +0900, FUJITA Tomonori wrote:
From: Gabriel C [EMAIL PROTECTED]
Subject: Re: Someone ( bsg merge ? ) broke {sd,hd}parm on current git
Date: Tue, 17 Jul 2007 03:40:58 +0200
FUJITA Tomonori wrote:
From: Gabriel C [EMAIL PROTECTED]
Subject: Re: Someone ( bsg merge ? ) broke {sd,hd}parm on current git
Date: Tue, 17 Jul 2007 02:44:38 +0200
Gabriel C wrote:
Hello,
sdparm and hdparm are broken for me on git (
abce891a10559343d8ac9f79b46d78afdba63a40 )
~$ sudo hdparm /dev/sdc
/dev/sdc:
BLKROGET failed: Inappropriate ioctl for device
BLKRAGET failed: Inappropriate ioctl for device
BLKGETSIZE failed: Inappropriate ioctl for device
~$ sudo sdparm --all /dev/sdc
unable to access /dev/sdc, ATA disk?
Well it is bsg , setting BLK_DEV_BSG=n fixed all this errors.
I've not tested this yet (need to find sata drives in my workplace),
but James Bottomley told me that both works for him with bsg enabled.
It might worth trying the latest git tree.
It certainly does work for me. However, my ATA devices are connected to
an aic94xx SAS controller. Although this uses libata, the ioctl path is
probably slightly different from the libata one. I assume you're using a
SATA controller? Unfortunately I have no ability to test on a SATA
controller, but I'd suggest looking at the ioctl and REQ_BLOCK_PC paths
in libata for clues.
No is not an SATA controller.
sda and sdb are SCSI disks connected to an Adaptec AIC-7892P U160/m
controller using the aic7xxx driver.
sdc is an ATA-7 disk connected to an IDE controller ( 82801BA IDE U100
) using libata and the ata_piix driver.
$ lspci -nn
00:00.0 Host bridge [0600]: Intel Corporation 82860 860 (Wombat) Chipset
Host Bridge (MCH) [8086:2531] (rev 04)
00:01.0 PCI bridge [0604]: Intel Corporation 82850 850 (Tehama) Chipset
AGP Bridge [8086:2532] (rev 04)
00:02.0 PCI bridge [0604]: Intel Corporation 82860 860 (Wombat) Chipset
AGP Bridge [8086:2533] (rev 04)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge
[8086:244e] (rev 04)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801BA ISA Bridge (LPC)
[8086:2440] (rev 04)
00:1f.1 IDE interface [0101]: Intel Corporation 82801BA IDE U100
Controller [8086:244b] (rev 04)
00:1f.2 USB Controller [0c03]: Intel Corporation 82801BA/BAM USB
Controller #1 [8086:2442] (rev 04)
00:1f.3 SMBus [0c05]: Intel Corporation 82801BA/BAM SMBus Controller
[8086:2443] (rev 04)
00:1f.4 USB Controller [0c03]: Intel Corporation 82801BA/BAM USB
Controller #1 [8086:2444] (rev 04)
00:1f.5 Multimedia audio controller [0401]: Intel Corporation
82801BA/BAM AC'97 Audio Controller [8086:2445] (rev 04)
01:00.0 VGA compatible controller [0300]: nVidia Corporation NV11
[GeForce2 MX/MX 400] [10de:0110] (rev a1)
02:1f.0 PCI bridge [0604]: Intel Corporation 82806AA PCI64 Hub PCI
Bridge [8086:1360] (rev 03)
03:00.0 PIC [0800]: Intel Corporation 82806AA PCI64 Hub Advanced
Programmable Interrupt Controller [8086:1161] (rev 01)
03:0e.0 SCSI storage controller [0100]: Adaptec AIC-7892P U160/m
[9005:008f] (rev 02)
04:0b.0 Ethernet controller [0200]: 3Com Corporation 3c905C-TX/TX-M
[Tornado] [10b7:9200] (rev 78)
04:0c.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB12LV26
IEEE-1394 Controller (Link) [104c:8020]
04:0f.0 USB Controller [0c03]: NEC Corporation USB [1033:0035] (rev 41)
04:0f.1 USB Controller [0c03]: NEC Corporation USB [1033:0035] (rev 41)
04:0f.2 USB Controller [0c03]: NEC Corporation USB 2.0 [1033:00e0] (rev 02)
James
Gabriel
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Someone ( bsg merge ? ) broke {sd,hd}parm on current git
FUJITA Tomonori wrote:
From: Gabriel C [EMAIL PROTECTED]
Subject: Re: Someone ( bsg merge ? ) broke {sd,hd}parm on current git
Date: Tue, 17 Jul 2007 03:40:58 +0200
FUJITA Tomonori wrote:
From: Gabriel C [EMAIL PROTECTED]
Subject: Re: Someone ( bsg merge ? ) broke {sd,hd}parm on current git
Date: Tue, 17 Jul 2007 02:44:38 +0200
Gabriel C wrote:
Hello,
sdparm and hdparm are broken for me on git (
abce891a10559343d8ac9f79b46d78afdba63a40 )
~$ sudo hdparm /dev/sdc
/dev/sdc:
BLKROGET failed: Inappropriate ioctl for device
BLKRAGET failed: Inappropriate ioctl for device
BLKGETSIZE failed: Inappropriate ioctl for device
~$ sudo sdparm --all /dev/sdc
unable to access /dev/sdc, ATA disk?
Well it is bsg , setting BLK_DEV_BSG=n fixed all this errors.
I've not tested this yet (need to find sata drives in my workplace),
but James Bottomley told me that both works for him with bsg enabled.
It might worth trying the latest git tree.
Hi ,
I'm running current git head and this problem still exists.
[EMAIL PROTECTED]:/work/crazy/linux-git/linux2.6$ git rev-parse --verify HEAD
5bae7ac9feba925fd0099057f6b23d7be80b7b41
With BLK_DEV_BSG=n
[EMAIL PROTECTED]:/work/crazy/linux-git/linux2.6$ sudo sdparm /dev/sda
/dev/sda: SEAGATE ST318406LW 0109
Read write error recovery mode page:
AWRE 1 [cha: y, def: 1, sav: 1]
ARRE 1 [cha: y, def: 1, sav: 1]
PER 0 [cha: y, def: 0, sav: 0]
Caching (SBC) mode page:
WCE 1 [cha: y, def: 1, sav: 1]
RCD 0 [cha: y, def: 0, sav: 0]
Control mode page:
SWP 0 [cha: n, def: 0, sav: 0]
Informational exceptions control mode page:
EWASC 0 [cha: n, def: 0, sav: 0]
DEXCPT 0 [cha: y, def: 0, sav: 0]
MRIE 0 [cha: y, def: 0, sav: 0]
[EMAIL PROTECTED]:/work/crazy/linux-git/linux2.6$ sudo sdparm /dev/sdb
/dev/sdb: FUJITSU MAH3182MP 0114
Read write error recovery mode page:
AWRE 0 [cha: y, def: 0, sav: 0]
ARRE 1 [cha: y, def: 1, sav: 1]
PER 0 [cha: y, def: 0, sav: 0]
Caching (SBC) mode page:
WCE 1 [cha: y, def: 1, sav: 1]
RCD 0 [cha: y, def: 0, sav: 0]
Control mode page:
SWP 0 [cha: n, def: 0, sav: 0]
Informational exceptions control mode page:
EWASC 1 [cha: y, def: 0, sav: 1]
DEXCPT 0 [cha: y, def: 1, sav: 0]
MRIE 6 [cha: y, def: 0, sav: 6]
[EMAIL PROTECTED]:/work/crazy/linux-git/linux2.6$ sudo sdparm /dev/sdc
/dev/sdc: ATA SAMSUNG SP1203N TL10
Read write error recovery mode page:
AWRE 1
ARRE 1
PER 0
Caching (SBC) mode page:
WCE 1
RCD 0
Control mode page:
SWP 0
[EMAIL PROTECTED]:/work/crazy/linux-git/linux2.6$ sudo hdparm /dev/sda
/dev/sda:
readonly = 0 (off)
readahead = 256 (on)
geometry = 2231/255/63, sectors = 35843670, start = 0
[EMAIL PROTECTED]:/work/crazy/linux-git/linux2.6$ sudo hdparm /dev/sdb
/dev/sdb:
readonly = 0 (off)
readahead = 256 (on)
geometry = /255/63, sectors = 35701260, start = 0
[EMAIL PROTECTED]:/work/crazy/linux-git/linux2.6$ sudo hdparm /dev/sdc
/dev/sdc:
IO_support = 0 (default 16-bit)
readonly = 0 (off)
readahead = 256 (on)
geometry = 14596/255/63, sectors = 234493056, start = 0
And this when set to y
[EMAIL PROTECTED]:~$ sudo hdparm /dev/sda
/dev/sda:
BLKROGET failed: Inappropriate ioctl for device
BLKRAGET failed: Inappropriate ioctl for device
BLKGETSIZE failed: Inappropriate ioctl for device
[EMAIL PROTECTED]:~$ sudo hdparm /dev/sdb
/dev/sdb:
BLKROGET failed: Inappropriate ioctl for device
BLKRAGET failed: Inappropriate ioctl for device
BLKGETSIZE failed: Inappropriate ioctl for device
[EMAIL PROTECTED]:~$ sudo hdparm /dev/sdc
/dev/sdc:
BLKROGET failed: Inappropriate ioctl for device
BLKRAGET failed: Inappropriate ioctl for device
BLKGETSIZE failed: Inappropriate ioctl for device
[EMAIL PROTECTED]:~$ sudo sdparm /dev/sdc
unable to access /dev/sdc, ATA disk?
[EMAIL PROTECTED]:~$ sudo sdparm /dev/sdb
unable to access /dev/sdb, ATA disk?
[EMAIL PROTECTED]:~$ sudo sdparm /dev/sda
unable to access /dev/sda, ATA disk?
[EMAIL PROTECTED]:~$ dmesg|grep bsg
[ 41.411171] Block layer SCSI generic (bsg) driver version 0.4 loaded
(major 253)
Smartd now spams the dmesg too with :
snip
[ 75.329927] program smartd is using a deprecated SCSI ioctl, please
convert it to SG_IO
[ 75.334267] program smartd is using a deprecated SCSI ioctl, please
convert it to SG_IO
[ 75.334396] program smartd is using a deprecated SCSI ioctl, please
convert it to SG_IO
[ 75.388284] program smartd is using a deprecated SCSI ioctl, please
convert it to SG_IO
[ 75.438146] program smartd is using a deprecated SCSI ioctl, please
convert it to SG_IO
dmesg|grep 'program smartd is using'|wc -l
42
Just stopped it for now :)
You can find the used config and dmesg there :
http://194.231.229.228/2.6.22-g5bae7ac9/
Gabriel
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Someone ( bsg merge ? ) broke {sd,hd}parm on current git
Gabriel C wrote: Hello, sdparm and hdparm are broken for me on git ( abce891a10559343d8ac9f79b46d78afdba63a40 ) ~$ sudo hdparm /dev/sdc /dev/sdc: BLKROGET failed: Inappropriate ioctl for device BLKRAGET failed: Inappropriate ioctl for device BLKGETSIZE failed: Inappropriate ioctl for device ~$ sudo sdparm --all /dev/sdc unable to access /dev/sdc, ATA disk? Well it is bsg , setting BLK_DEV_BSG=n fixed all this errors. Maybe a bit off topic but it depends on EXPERIMENTAL so why the the menu is not telling this ? and why the default is 'y' for it ? IMO everything depends on EXPERIMENTAL should 1) Tell it is EXPERIMENTAL ( visible to the user in menu ) Foo New stuff ( EXPERIMENTAL ) 2) Should not default to 'y' , is up to the users/admins to set EXPERIMENTAL things to Y/M , isn't it ? ( PS: there are even defconfigs with EXPERIMENTAL things set to y but this is really off topic ) Regards, Gabriel C - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Someone ( bsg merge ? ) broke {sd,hd}parm on current git
FUJITA Tomonori wrote:
From: Gabriel C [EMAIL PROTECTED]
Subject: Re: Someone ( bsg merge ? ) broke {sd,hd}parm on current git
Date: Tue, 17 Jul 2007 02:44:38 +0200
Gabriel C wrote:
Hello,
sdparm and hdparm are broken for me on git (
abce891a10559343d8ac9f79b46d78afdba63a40 )
~$ sudo hdparm /dev/sdc
/dev/sdc:
BLKROGET failed: Inappropriate ioctl for device
BLKRAGET failed: Inappropriate ioctl for device
BLKGETSIZE failed: Inappropriate ioctl for device
~$ sudo sdparm --all /dev/sdc
unable to access /dev/sdc, ATA disk?
Well it is bsg , setting BLK_DEV_BSG=n fixed all this errors.
Can you check the major number of your /dev/sdc? I've seen that
/dev/sd* is linked to bsg devices somehow.
All my disks are doing this sdc was meant as example.
...
$ ls -la /dev/sd{a,b,c}
brw-r- 1 root disk 8, 0 16. Jul 23:11 /dev/sda
brw-rw 1 root disk 8, 16 16. Jul 23:11 /dev/sdb
brw-r- 1 root disk 8, 32 16. Jul 23:11 /dev/sdc
...
sd{a,b} are SCSI disks and sdc is an ATA disk.
You can get the used config from there :
http://194.231.229.228/2.6.22-gabce891a/config
Gabriel
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[SCSI] SD driver question
Hello, Is there any reason why sd is printing the driver informations for each disk twice in dmesg ? ... sd 0:0:0:0: [sda] 35843670 512-byte hardware sectors (18352 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 9f 00 10 08 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA sd 0:0:0:0: [sda] 35843670 512-byte hardware sectors (18352 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 9f 00 10 08 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA sda: sda1 sd 0:0:0:0: [sda] Attached SCSI disk sd 0:0:0:0: Attached scsi generic sg0 type 0 etc ... Is a bit annoying and floodish ;) on boxes with a lot SCSI , *ATA disks. Regards, Gabriel C - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SCSI] SD driver question
Uwe Kiewel wrote: Please, can you tell the version of the kernel you use? I use: [EMAIL PROTECTED] ~]$ uname -r 2.6.21-1.3228.fc7 It is the current Fedora 7 kernel. Sure. [EMAIL PROTECTED]:~$ uname -r 2.6.22-rc6-git4 Regards, Uwe Regards, Gabriel - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
