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
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 >>&g
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
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
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-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-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
>> 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. Works fine for me tested on : 03:0e.0 SCSI storage controller [0100]: Adaptec AIC-7892P U160/m [9005:008f] (rev 02) 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
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
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
Eugene Teo wrote: > Hi Gabriel, Hi Eugene, > Hope the following trivial patch helps. Yes it does , thx. > > >> 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 > #include > #include > +#include > > #include > #include > > - 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: 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-kernel&m=118534836402440&w=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
BSG: BLK_DEV_BSG=y , BLOCK=n compile error
error: dereferencing pointer to incomplete type block/bsg.c:970: error: dereferencing pointer to incomplete type block/bsg.c:1005: error: dereferencing pointer to incomplete type block/bsg.c:1006: error: dereferencing pointer to incomplete type make[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
[PATCH] Fix drivers/scsi/fdomain.c , CONFIG_PCI=n warnings
Hi,
I get this warnings on current git when CONFIG_PCI is not set :
...
drivers/scsi/fdomain.c:390: warning: 'PCI_dev' defined but not used
drivers/scsi/fdomain.c:1768: warning: 'fdomain_pci_tbl' defined but not used
...
Signed-off-by: Gabriel Craciunescu <[EMAIL PROTECTED]>
---
diff --git a/drivers/scsi/fdomain.c b/drivers/scsi/fdomain.c
index 36169d5..5d282e6 100644
--- a/drivers/scsi/fdomain.c
+++ b/drivers/scsi/fdomain.c
@@ -387,7 +387,9 @@ static void __iomem *bios_mem;
static int bios_major;
static int bios_minor;
static int PCI_bus;
+#ifdef CONFIG_PCI
static struct pci_dev *PCI_dev;
+#endif
static int Quantum; /* Quantum board variant */
static int interrupt_level;
static volatile int in_command;
@@ -1764,6 +1766,7 @@ struct scsi_host_template fdomain_driver_template = {
};
#ifndef PCMCIA
+#ifdef CONFIG_PCI
static struct pci_device_id fdomain_pci_tbl[] __devinitdata = {
{ PCI_VENDOR_ID_FD, PCI_DEVICE_ID_FD_36C70,
@@ -1771,7 +1774,7 @@ static struct pci_device_id fdomain_pci_tbl[]
__devinitdata = {
{ }
};
MODULE_DEVICE_TABLE(pci, fdomain_pci_tbl);
-
+#endif
#define driver_template fdomain_driver_template
#include "scsi_module.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
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
[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/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
Re: Someone ( bsg merge ? ) broke {sd,hd}parm on current git
James Bottomley wrote:
> On Thu, 2007-07-19 at 16:31 +0200, Gabriel C wrote:
>
>> 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.
>>
>
> OK, this definitely works for me, that's what my root disk is on. I
> think this isn't a kernel problem ... I think it's a udev name clash
> problem. Try the attached patch, which corrects the names:
>
Thx, your patch fixes the problem for me.
>
>> sdc is an ATA-7 disk connected to an IDE controller ( 82801BA IDE U100
>> ) using libata and the ata_piix driver.
>>
>
>
> James
>
> ---
>
> Index: BUILD-2.6/block/Kconfig
> ===
> --- BUILD-2.6.orig/block/Kconfig 2007-07-18 11:34:20.0 -0500
> +++ BUILD-2.6/block/Kconfig 2007-07-18 11:36:24.0 -0500
> @@ -53,7 +53,7 @@ endif # BLOCK
>
> config BLK_DEV_BSG
> bool "Block layer SG support v4 (EXPERIMENTAL)"
> - depends on (SCSI=y) && EXPERIMENTAL
> + depends on EXPERIMENTAL
> ---help---
> Saying Y here will enable generic SG (SCSI generic) v4 support
> for any block device.
> Index: BUILD-2.6/block/bsg.c
> ===
> --- BUILD-2.6.orig/block/bsg.c2007-07-18 11:34:20.0 -0500
> +++ BUILD-2.6/block/bsg.c 2007-07-18 11:36:24.0 -0500
> @@ -1009,29 +1009,6 @@ err:
> }
> EXPORT_SYMBOL_GPL(bsg_register_queue);
>
> -static int bsg_add(struct class_device *cl_dev, struct class_interface
> *cl_intf)
> -{
> - int ret;
> - struct scsi_device *sdp = to_scsi_device(cl_dev->dev);
> - struct request_queue *rq = sdp->request_queue;
> -
> - if (rq->kobj.parent)
> - ret = bsg_register_queue(rq, kobject_name(rq->kobj.parent));
> - else
> - ret = bsg_register_queue(rq,
> kobject_name(&sdp->sdev_gendev.kobj));
> - return ret;
> -}
> -
> -static void bsg_remove(struct class_device *cl_dev, struct class_interface
> *cl_intf)
> -{
> - bsg_unregister_queue(to_scsi_device(cl_dev->dev)->request_queue);
> -}
> -
> -static struct class_interface bsg_intf = {
> - .add= bsg_add,
> - .remove = bsg_remove,
> -};
> -
> static struct cdev bsg_cdev = {
> .kobj = {.name = "bsg", },
> .owner = THIS_MODULE,
> @@ -1069,16 +1046,9 @@ static int __init bsg_init(void)
> if (ret)
> goto unregister_chrdev;
>
> - ret = scsi_register_interface(&bsg_intf);
> - if (ret)
> - goto remove_cdev;
> -
> printk(KERN_INFO BSG_DESCRIPTION " version " BSG_VERSION
> " loaded (major %d)\n", bsg_major);
> return 0;
> -remove_cdev:
> - printk(KERN_ERR "bsg: failed register scsi interface %d\n", ret);
> - cdev_del(&bsg_cdev);
> unregister_chrdev:
> unregister_chrdev_region(MKDEV(bsg_major, 0), BSG_MAX_DEVS);
> destroy_bsg_class:
> Index: BUILD-2.6/drivers/scsi/scsi_sysfs.c
> ===
> --- BUILD-2.6.orig/drivers/scsi/scsi_sysfs.c 2007-07-18 11:36:02.0
> -0500
> +++ BUILD-2.6/drivers/scsi/scsi_sysfs.c 2007-07-19 10:10:50.0
> -0500
> @@ -715,6 +715,7 @@ static int attr_add(struct device *dev,
> int scsi_sysfs_add_sdev(struct scsi_device *sdev)
> {
> int error, i;
> + struct request_queue *rq = sdev->request_queue;
>
> if ((error = scsi_device_set_state(sdev, SDEV_RUNNING)) != 0)
> return error;
> @@ -734,6 +735,17 @@ int scsi_sysfs_add_sdev(struct scsi_devi
> /* take a reference for the sdev_classdev; this is
>* released by the sdev_class .release */
> get_device(&sdev->sdev_gendev);
> +
> + error = bsg_register_queue(rq, sdev->sdev_gendev.bus_id);
> +
> + if (error)
> + sdev_printk(KERN_INFO, sdev,
> + "Failed to register bsg queue, errno=%d\n", error);
> +
> + /* we're treating error on bsg register as non-fatal, so pretend
> + * nothing went wrong */
> + error = 0;
> +
> if (sdev->host->hostt->sdev_attrs) {
> for (i = 0; sdev->host->hostt->sdev_attrs[i]; i++) {
> error = attr_add(&sdev->sdev_gendev,
> @@ -780,6 +792,7 @@ void __scsi_remove_device(struct scsi_de
> if (scsi_device_set_state(sdev, SDEV_CANCEL) != 0)
> return;
>
> + bsg_unregister_queue(sdev->request_queue);
> class_device_unregister(&sdev->sdev_classdev);
> transport_remove_device(dev);
> device_del(dev);
>
>
>
>
>
-
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
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
Re: block/bsg.c
Satyam Sharma wrote: > On 7/17/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > CONFIG_BLK_DEV_BSG=y > CONFIG_SCSI=m > > block/built-in.o: In function `bsg_init': > block/bsg.c:1097: undefined reference to `scsi_register_interface' > make: *** [.tmp_vmlinux1] Error 1 > > on latest -git. > Should be fixed by this commit : http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=29417b899a77aaba1c060f5e123db4f50006f58a > Satyam > > 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: [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
[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
