Re: WARNING: at drivers/ata/libata-core.c:5988 ata_qc_issue()
Tejun Heo wrote: Mark Lord wrote: Another one for those beers, is a way to tell the IOMMU code about physical segment limitations -- so we can stop having to allocate PRD tables 2X as big as necessary in drivers like sata_mv. Hmmm... What's the restriction for sata_mv? The same as BMDMA? We need to update the block layer too to get the BMDMA right. Same as for BMDMA, specifically: after block/etc. merging is done, and things are passed to the IOMMU via dma_map_sg(), the IOMMU may merge -too- aggressively, merging across boundaries (like 64k bmdma boundary) because it is unaware of such restrictions. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WARNING: at drivers/ata/libata-core.c:5988 ata_qc_issue()
Mark Lord wrote: Tejun Heo wrote: Mark Lord wrote: .. Super! You've done a great job with this stuff, Tejun! Thanks but I can't really say nice things about how sata_sil24's qc_defer() is implemented or how we generally handle command deferring. We really need the control at the higher level - request_queue group. Oh well... I guess you guys will be talking about it over beer again soon. :-) .. You too? Another one for those beers, is a way to tell the IOMMU code about physical segment limitations -- so we can stop having to allocate PRD tables 2X as big as necessary in drivers like sata_mv. tomo fixed that, just need to merge it... Jeff - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About forcing 32bit DMA patch for AMD690G(SB600)
Andrew Paprocki wrote: > I have an SB600/RS690 here with SATA drives connected. I haven't been > following this thread, but I can help test something if it would help. We're trying to determine whether SB600 ahci controller can do 64bit DMA or not. Srihari's couldn't but Shane's test result tells a different story. Do you have memory mapped over 4G (if you have 4G some of them will be over 4G, you can know this by looking at the e820 map printed during boot)? -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WARNING: at drivers/ata/libata-core.c:5988 ata_qc_issue()
Mark Lord wrote: > Tejun Heo wrote: >> Mark Lord wrote: >> .. >>> Super! You've done a great job with this stuff, Tejun! >> >> Thanks but I can't really say nice things about how sata_sil24's >> qc_defer() is implemented or how we generally handle command deferring. >> We really need the control at the higher level - request_queue group. >> Oh well... I guess you guys will be talking about it over beer again >> soon. :-) > .. > > You too? Unfortunately not, overlapping family event && travel budget issues. :-( > Another one for those beers, is a way to tell the IOMMU code about > physical segment limitations -- so we can stop having to allocate > PRD tables 2X as big as necessary in drivers like sata_mv. Hmmm... What's the restriction for sata_mv? The same as BMDMA? We need to update the block layer too to get the BMDMA right. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WARNING: at drivers/ata/libata-core.c:5988 ata_qc_issue()
Tejun Heo wrote: Mark Lord wrote: .. Super! You've done a great job with this stuff, Tejun! Thanks but I can't really say nice things about how sata_sil24's qc_defer() is implemented or how we generally handle command deferring. We really need the control at the higher level - request_queue group. Oh well... I guess you guys will be talking about it over beer again soon. :-) .. You too? Another one for those beers, is a way to tell the IOMMU code about physical segment limitations -- so we can stop having to allocate PRD tables 2X as big as necessary in drivers like sata_mv. Cheers - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About forcing 32bit DMA patch for AMD690G(SB600)
Tejun, I have an SB600/RS690 here with SATA drives connected. I haven't been following this thread, but I can help test something if it would help. Thanks, -Andrew On Jan 24, 2008 7:21 PM, Tejun Heo <[EMAIL PROTECTED]> wrote: > Hello, Shane. Sorry about the delay. Got caught up in other stuff. > > Shane Huang wrote: > > Quoting Tejun: > >> Uh-oh, wait a bit. Nope. Until we figure out what the something > >> else > > is > >> and positively verify 64bit DMA works fine, the quirk stays in. > > > > Our HW engineer has confirmed that our SB600 SATA controller indeed > > has some MSI issue, and we do not have any workaround. > > > > The workaround "quirk_msi_intx_disable_bug" to SB700 SATA controller > > can NOT work to SB600 SATA controller in my debug, while disablement > > to RS690 MSI in kernel source can fix it. > > Hmmm... Okay. Is the SB600 SATA controller culprit or the north bridge > - RS690? If the former is the case, proper way to work around it is to > add AHCI_HFLAG_NO_MSI for SB600 AHCI. > > > As to the SB600 64 bit DMA capacity, do you have any methods to do > > further verification? I do NOT find any problem in my debug after I > > disabled RS690 MSI in kernel 2.6.24-rc7. > > The problem is that we didn't actually prove anything. In the tests > you've done, pci=nomsi didn't fix the problem but disable_all_msi quirk > did. pci=nomsi and disable_all_msi quirk are identical. Also, > Srihari's problem was not reproduced, so currently we can't say much > from the test results. Srihari, do you still have the system around? > > Thanks. > > -- > tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WARNING: at drivers/ata/libata-core.c:5988 ata_qc_issue()
Mark Lord wrote: > Tejun Heo wrote: >> Mark Lord wrote: > .. >>> Super. And when I add FIS-based-switching PMP support on top of NCQ, >>> *then* what should it point at? >> >> If the controller can do FIS-based switching w/o any other restrictions, >> ata_std_qc_defer() can just stay. If there are restrictions, you need >> to roll your own qc_defer. sata_sil24 had to. >> >> For command-based switching, sata_pmp_qc_defer_cmd_switch() can be used. > ... > > Super! You've done a great job with this stuff, Tejun! Thanks but I can't really say nice things about how sata_sil24's qc_defer() is implemented or how we generally handle command deferring. We really need the control at the higher level - request_queue group. Oh well... I guess you guys will be talking about it over beer again soon. :-) -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WARNING: at drivers/ata/libata-core.c:5988 ata_qc_issue()
Tejun Heo wrote: Mark Lord wrote: .. Super. And when I add FIS-based-switching PMP support on top of NCQ, *then* what should it point at? If the controller can do FIS-based switching w/o any other restrictions, ata_std_qc_defer() can just stay. If there are restrictions, you need to roll your own qc_defer. sata_sil24 had to. For command-based switching, sata_pmp_qc_defer_cmd_switch() can be used. ... Super! You've done a great job with this stuff, Tejun! -ml - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SATA timeouts on two disks
Tejun Heo wrote: Hello, Jim MacBaine wrote: A co-worker, to whom I explained my problem, asked me whether I had properly grounded my drives. In fact I had not: The drives resided in a vibration-absorbing frame through which their exterior had no electrical contact with the grounded case. Since I grounded the drives two days ago, I got no new errors. So maybe my problem is solved. Hmmm... Grounding. Interesting. Can you say about more about this, Jim? This may also be my problem, or part of it, as my drives too are mounted in such a way as not to be in physical contact with the case. How did you go about grounding them? I suppose one test would be just to remove the washers That said, in my case, 2.6.24 seems to make a big difference, too. I accidentally booted into 2.6.23 today and, boom. Richard - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AMD SB600 64 bit DMA issue
[cc'ing linux-ide] Thanks, hmmm... weird. The log is w/ MSI disabled, right? SB600 is reporting MSI capability alright. I wonder why MSI is not enabled with the quirk lifted. Can you please post full boot log and the result of 'lspci -nnvvvxxx' w/ the quirk removed? Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About forcing 32bit DMA patch for AMD690G(SB600)
Hello, Shane. Sorry about the delay. Got caught up in other stuff. Shane Huang wrote: > Quoting Tejun: >> Uh-oh, wait a bit. Nope. Until we figure out what the something >> else > is >> and positively verify 64bit DMA works fine, the quirk stays in. > > Our HW engineer has confirmed that our SB600 SATA controller indeed > has some MSI issue, and we do not have any workaround. > > The workaround "quirk_msi_intx_disable_bug" to SB700 SATA controller > can NOT work to SB600 SATA controller in my debug, while disablement > to RS690 MSI in kernel source can fix it. Hmmm... Okay. Is the SB600 SATA controller culprit or the north bridge - RS690? If the former is the case, proper way to work around it is to add AHCI_HFLAG_NO_MSI for SB600 AHCI. > As to the SB600 64 bit DMA capacity, do you have any methods to do > further verification? I do NOT find any problem in my debug after I > disabled RS690 MSI in kernel 2.6.24-rc7. The problem is that we didn't actually prove anything. In the tests you've done, pci=nomsi didn't fix the problem but disable_all_msi quirk did. pci=nomsi and disable_all_msi quirk are identical. Also, Srihari's problem was not reproduced, so currently we can't say much from the test results. Srihari, do you still have the system around? Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/14] sata_mv NCQ support
Mark Lord wrote: > sata_mv Add missing qc_defer op. > > This is necessary now that we support NCQ in the driver. > > Signed-off-by: Mark Lord <[EMAIL PROTECTED]> Acked-by: Tejun Heo <[EMAIL PROTECTED]> -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WARNING: at drivers/ata/libata-core.c:5988 ata_qc_issue()
Mark Lord wrote:
> Tejun Heo wrote:
>> Mark Lord wrote:
>>> Tejun Heo wrote:
Mark Lord wrote:
> Tejun Heo wrote:
>> Mark Lord wrote:
>>> Tejun,
>>> ..
>> void ata_qc_issue(struct ata_queued_cmd *qc)
>> {
>> struct ata_port *ap = qc->ap;
>> struct ata_link *link = qc->dev->link;
>>
>> /* Make sure only one non-NCQ command is outstanding. The
>> * check is skipped for old EH because it reuses active qc to
>> * request ATAPI sense.
>> */
> = WARN_ON(ap->ops->error_handler &&
Hmm... Thanks. Do you have your ->qc_defer set?
>>> ..
>>>
>>> Err.. no, never heard of it before (now).
>>>
>>> I suppose I should have it set to the default ?
>>
>> Yeah, just set it to ata_std_qc_defer().
> ..
>
> Super. And when I add FIS-based-switching PMP support on top of NCQ,
> *then* what should it point at?
If the controller can do FIS-based switching w/o any other restrictions,
ata_std_qc_defer() can just stay. If there are restrictions, you need
to roll your own qc_defer. sata_sil24 had to.
For command-based switching, sata_pmp_qc_defer_cmd_switch() can be used.
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/14] sata_mv NCQ support
sata_mv Add missing qc_defer op. This is necessary now that we support NCQ in the driver. Signed-off-by: Mark Lord <[EMAIL PROTECTED]> --- Who says a 14-patch series cannot have a 15th patch? :) --- old/drivers/ata/sata_mv.c 2008-01-24 18:55:12.0 -0500 +++ new/drivers/ata/sata_mv.c 2008-01-24 18:57:21.0 -0500 @@ -558,6 +558,7 @@ .post_internal_cmd = mv_post_int_cmd, .freeze = mv_eh_freeze, .thaw = mv_eh_thaw, + .qc_defer = ata_std_qc_defer, .scr_read = mv_scr_read, .scr_write = mv_scr_write, @@ -586,6 +587,7 @@ .post_internal_cmd = mv_post_int_cmd, .freeze = mv_eh_freeze, .thaw = mv_eh_thaw, + .qc_defer = ata_std_qc_defer, .scr_read = mv_scr_read, .scr_write = mv_scr_write, - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WARNING: at drivers/ata/libata-core.c:5988 ata_qc_issue()
Tejun Heo wrote:
Mark Lord wrote:
Tejun Heo wrote:
Mark Lord wrote:
Tejun Heo wrote:
Mark Lord wrote:
Tejun,
..
void ata_qc_issue(struct ata_queued_cmd *qc)
{
struct ata_port *ap = qc->ap;
struct ata_link *link = qc->dev->link;
/* Make sure only one non-NCQ command is outstanding. The
* check is skipped for old EH because it reuses active qc to
* request ATAPI sense.
*/
= WARN_ON(ap->ops->error_handler &&
Hmm... Thanks. Do you have your ->qc_defer set?
..
Err.. no, never heard of it before (now).
I suppose I should have it set to the default ?
Yeah, just set it to ata_std_qc_defer().
..
Super. And when I add FIS-based-switching PMP support on top of NCQ,
*then* what should it point at?
?
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WARNING: at drivers/ata/libata-core.c:5988 ata_qc_issue()
Mark Lord wrote:
> Tejun Heo wrote:
>> Mark Lord wrote:
>>> Tejun Heo wrote:
Mark Lord wrote:
> Tejun,
> ..
void ata_qc_issue(struct ata_queued_cmd *qc)
{
struct ata_port *ap = qc->ap;
struct ata_link *link = qc->dev->link;
/* Make sure only one non-NCQ command is outstanding. The
* check is skipped for old EH because it reuses active qc to
* request ATAPI sense.
*/
>>> = WARN_ON(ap->ops->error_handler &&
>>
>> Hmm... Thanks. Do you have your ->qc_defer set?
> ..
>
> Err.. no, never heard of it before (now).
>
> I suppose I should have it set to the default ?
Yeah, just set it to ata_std_qc_defer().
> sata_mv patch 15/14 forthcoming
:-)
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: excess timeouts accessing pci-sata card both ports
Hmm. Removed 3 drives. Both data and power. Left only port1 connected It's the drive and power cable that in the first test was port2 failing and in second test was port1 and ok both cards plugged in and initialized. third test it's the port1 alone sda working ok fourth test it's the port2 alone sda failing. any idea what's wrong as this does not seem to be power related problem. vanilla 2.6.23.14 sata_via module... details in the inlined emails. (4th test config) ata1: SATA link down (SStatus 0 SControl 310) ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310) ata4: SATA link down (SStatus 0 SControl 310) ata5: SATA link down (SStatus 0 SControl 310) Faulty card? Both cards? Driver bug? Or design bug/incompatibility on second port? __ > Od: [EMAIL PROTECTED] > Komu: > Datum: 24.01.2008 23:59 > Předmět: Re: excess timeouts accessing pci-sata card both ports > >Hi. > >More through test revealed that only the second port of each card is failing. > >Accessing (cat /dev/sdX > /dev/null) just the sdb or sdd alone = one drive at time produces the error message. > >Switched data cables on the card. ata1 port for ata2 port. This should eliminate defective power cable to sdb. >And also switched ata4 port for ata5 port data cable. This sould eliminate defective power cable to sdd. >(ata3 and 6 are not connected PATA ports on each card) > >Failing is again port 2 and port 5 which is now originally flawlessly working drives now failing. > > >__ >> Od: [EMAIL PROTECTED] >> Komu: >> Datum: 24.01.2008 09:27 >> Předmět: excess timeouts accessing pci-sata card both ports >> >>Hello. >> >>The scenario: >>PCI bus with 2 cards (sata_via) >>Each card has 2 SATA ports connected. >>Each disk does 40MB/s in hdparm -t read test. >> >>First card has the sda and sdb >>Second card has the sdc and sdd >>verified by watching the led blinking on the card >> >>ok - accessing two ports at same time but each port on different card: >>cat /dev/sda > /dev/null & cat /dev/sdc > /dev/null >> >>problem - accessing two ports at same time and both ports on same card: >>cat /dev/sda > /dev/null & cat /dev/sdb > /dev/null >> >>side effect of the problem: >>due to heavy traffic on one port the reset of the other port fails with >timeout and port is disabled >> >>logged error command at the initial problem (is it DMA read ext and DMA >write log?): >>ata2.00: exception Emask 0x2 SAct 0x0 SErr 0x3000400 action 0x2 frozen >>ata2.00: cmd 25/00:68:b8:83:13/00:01:00:00:00/e0 tag 0 cdb 0x0 data >184320 in >> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x6 (timeout) >>ata2: port is slow to respond, please be patient (Status 0xd0) >> >>ata2.00: exception Emask 0x2 SAct 0x0 SErr 0x3000400 action 0x2 frozen >>ata2.00: cmd c8/00:60:70:50:08/00:00:00:00:00/e0 tag 0 cdb 0x0 data 49152 >in >> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x6 (timeout) >>ata2: port is slow to respond, please be patient (Status 0xd0) >> >>logged EH sequence failure: >>ata2: port is slow to respond, please be patient (Status 0xd0) >>ata2: device not ready (errno=-16), forcing hardreset >>ata2: hard resetting port >>ata2: port is slow to respond, please be patient (Status 0x80) >>ata2: COMRESET failed (errno=-16) >>ata2: hard resetting port >>ata2: port is slow to respond, please be patient (Status 0x80) >>ata2: COMRESET failed (errno=-16) >>ata2: hard resetting port >>ata2: port is slow to respond, please be patient (Status 0x80) >>ata2: COMRESET failed (errno=-16) >>ata2: hard resetting port >>ata2: COMRESET failed (errno=-16) >>ata2: reset failed, giving up >>ata2.00: disabled >>ata2: EH complete >>sd 1:0:0:0: [sdb] Result: hostbyte=0x04 driverbyte=0x00 >> >>tried does not work: >>- multiply the ATA_TMOUT values by 10 and later by 100 against vanilla >>- increase retry counters >> >>some lines from dmesg below >>libata version 2.21 loaded. >>sata_via :00:0d.0: version 2.3 >>ACPI: PCI Interrupt :00:0d.0[A] -> Link [LNKA] -> GSI 11 (level, low) >-> IRQ 11 >>sata_via :00:0d.0: routed to hard irq line 11 >>scsi0 : sata_via >>scsi1 : sata_via >>scsi2 : sata_via >>ata1: SATA max UDMA/133 cmd 0x0001b800 ctl 0x0001b80a bmdma 0x0001a400 >irq 11 >>ata2: SATA max UDMA/133 cmd 0x0001b400 ctl 0x0001b40a bmdma 0x0001a408 >irq 11 >>ata3: PATA max UDMA/133 cmd 0x0001b000 ctl 0x0001b00a bmdma 0x0001a410 >irq 11 >>ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) >>ata1.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133 >>ata1.00: 490234752 sectors, multi 16: LBA48 NCQ (not used) >>ata1.00: configured for UDMA/133 >>ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310) >>ata2.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133 >>ata2.00: 490234752 sectors, multi 16: LBA48 NCQ (not used) >>ata2.00: configured for UDMA/133 >>scsi 0:0:0:0: Direct-Access ATA Maxtor 6L250S0 BANC PQ: 0 >ANSI: 5 >>sd 0:0:0:0: [sda] 490234752 512-byte h
Re: WARNING: at drivers/ata/libata-core.c:5988 ata_qc_issue()
Tejun Heo wrote:
Mark Lord wrote:
Tejun Heo wrote:
Mark Lord wrote:
Tejun,
..
void ata_qc_issue(struct ata_queued_cmd *qc)
{
struct ata_port *ap = qc->ap;
struct ata_link *link = qc->dev->link;
/* Make sure only one non-NCQ command is outstanding. The
* check is skipped for old EH because it reuses active qc to
* request ATAPI sense.
*/
= WARN_ON(ap->ops->error_handler &&
Hmm... Thanks. Do you have your ->qc_defer set?
..
Err.. no, never heard of it before (now).
I suppose I should have it set to the default ?
sata_mv patch 15/14 forthcoming.. :)
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WARNING: at drivers/ata/libata-core.c:5988 ata_qc_issue()
Mark Lord wrote:
> Tejun Heo wrote:
>> Mark Lord wrote:
>>> Tejun,
>>>
>>> During testing with NCQ on sata_mv (patches coming shortly),
>>> I found this gem in the syslog. This doesn't look like something
>>> that a LLD could cause, but rather a race perhaps in libata-core.
>>
>> Hmmm... This isn't supposed to happen.
>>
>>> System is a 2.4GHz 32-bit Core2Quad, 2GB RAM (during this test),
>>> running 2.6.24-rc6-git12 + newer sata_mv, with two sata_mv controller
>>> cards, each with one NCQ drive performing heavy R/W activity.
>>>
>>> Other than that, I'm not sure what triggered this.
>>
>> Can you please tell me which version you were using? Or tell me which
>> one of the three WARN_ON()'s in ata_qc_issue() was triggered? Thanks.
> ..
>>> [ 289.892890] WARNING: at drivers/ata/libata-core.c:5988 ata_qc_issue()
> ..
>
> The first one shown below, at drivers/ata/libata-core.c:5988:
>
>> void ata_qc_issue(struct ata_queued_cmd *qc)
>> {
>> struct ata_port *ap = qc->ap;
>> struct ata_link *link = qc->dev->link;
>>
>> /* Make sure only one non-NCQ command is outstanding. The
>> * check is skipped for old EH because it reuses active qc to
>> * request ATAPI sense.
>> */
> = WARN_ON(ap->ops->error_handler &&
Hmm... Thanks. Do you have your ->qc_defer set?
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SATA timeouts on two disks
Hello, Jim MacBaine wrote: > A co-worker, to whom I explained my problem, asked me whether I had > properly grounded my drives. In fact I had not: The drives resided in > a vibration-absorbing frame through which their exterior had no > electrical contact with the grounded case. Since I grounded the drives > two days ago, I got no new errors. So maybe my problem is solved. Hmmm... Grounding. Interesting. > If not, I will happily try out your suggestion. Would you be so kind > to explain in a few words, what connecting one drive to a second > (supposedly good) PSU will show? It's just a good way to isolate problems. For example, the motherboard could be doing something strange on the 12v rail and the PSU could be too sensitive causing the whole rail to fluctuate slightly leading to occasional transmission errors. SATA links are the first to be affected by those kinds of electrical problems. > (Is this still on-topic on this list?) Yeah, sure. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: excess timeouts accessing pci-sata card both ports
Hi. More through test revealed that only the second port of each card is failing. Accessing (cat /dev/sdX > /dev/null) just the sdb or sdd alone = one drive at time produces the error message. Switched data cables on the card. ata1 port for ata2 port. This should eliminate defective power cable to sdb. And also switched ata4 port for ata5 port data cable. This sould eliminate defective power cable to sdd. (ata3 and 6 are not connected PATA ports on each card) Failing is again port 2 and port 5 which is now originally flawlessly working drives now failing. __ > Od: [EMAIL PROTECTED] > Komu: > Datum: 24.01.2008 09:27 > Předmět: excess timeouts accessing pci-sata card both ports > >Hello. > >The scenario: >PCI bus with 2 cards (sata_via) >Each card has 2 SATA ports connected. >Each disk does 40MB/s in hdparm -t read test. > >First card has the sda and sdb >Second card has the sdc and sdd >verified by watching the led blinking on the card > >ok - accessing two ports at same time but each port on different card: >cat /dev/sda > /dev/null & cat /dev/sdc > /dev/null > >problem - accessing two ports at same time and both ports on same card: >cat /dev/sda > /dev/null & cat /dev/sdb > /dev/null > >side effect of the problem: >due to heavy traffic on one port the reset of the other port fails with timeout and port is disabled > >logged error command at the initial problem (is it DMA read ext and DMA write log?): >ata2.00: exception Emask 0x2 SAct 0x0 SErr 0x3000400 action 0x2 frozen >ata2.00: cmd 25/00:68:b8:83:13/00:01:00:00:00/e0 tag 0 cdb 0x0 data 184320 in > res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x6 (timeout) >ata2: port is slow to respond, please be patient (Status 0xd0) > >ata2.00: exception Emask 0x2 SAct 0x0 SErr 0x3000400 action 0x2 frozen >ata2.00: cmd c8/00:60:70:50:08/00:00:00:00:00/e0 tag 0 cdb 0x0 data 49152 in > res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x6 (timeout) >ata2: port is slow to respond, please be patient (Status 0xd0) > >logged EH sequence failure: >ata2: port is slow to respond, please be patient (Status 0xd0) >ata2: device not ready (errno=-16), forcing hardreset >ata2: hard resetting port >ata2: port is slow to respond, please be patient (Status 0x80) >ata2: COMRESET failed (errno=-16) >ata2: hard resetting port >ata2: port is slow to respond, please be patient (Status 0x80) >ata2: COMRESET failed (errno=-16) >ata2: hard resetting port >ata2: port is slow to respond, please be patient (Status 0x80) >ata2: COMRESET failed (errno=-16) >ata2: hard resetting port >ata2: COMRESET failed (errno=-16) >ata2: reset failed, giving up >ata2.00: disabled >ata2: EH complete >sd 1:0:0:0: [sdb] Result: hostbyte=0x04 driverbyte=0x00 > >tried does not work: >- multiply the ATA_TMOUT values by 10 and later by 100 against vanilla >- increase retry counters > >some lines from dmesg below >libata version 2.21 loaded. >sata_via :00:0d.0: version 2.3 >ACPI: PCI Interrupt :00:0d.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11 >sata_via :00:0d.0: routed to hard irq line 11 >scsi0 : sata_via >scsi1 : sata_via >scsi2 : sata_via >ata1: SATA max UDMA/133 cmd 0x0001b800 ctl 0x0001b80a bmdma 0x0001a400 irq 11 >ata2: SATA max UDMA/133 cmd 0x0001b400 ctl 0x0001b40a bmdma 0x0001a408 irq 11 >ata3: PATA max UDMA/133 cmd 0x0001b000 ctl 0x0001b00a bmdma 0x0001a410 irq 11 >ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) >ata1.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133 >ata1.00: 490234752 sectors, multi 16: LBA48 NCQ (not used) >ata1.00: configured for UDMA/133 >ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310) >ata2.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133 >ata2.00: 490234752 sectors, multi 16: LBA48 NCQ (not used) >ata2.00: configured for UDMA/133 >scsi 0:0:0:0: Direct-Access ATA Maxtor 6L250S0 BANC PQ: 0 ANSI: 5 >sd 0:0:0:0: [sda] 490234752 512-byte hardware sectors (251000 MB) >sd 0:0:0:0: [sda] Write Protect is off >sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 >sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA >sd 0:0:0:0: [sda] 490234752 512-byte hardware sectors (251000 MB) >sd 0:0:0:0: [sda] Write Protect is off >sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 >sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA > sda: sda1 sda2 sda3 >sd 0:0:0:0: [sda] Attached SCSI disk >sd 0:0:0:0: Attached scsi generic sg0 type 0 >scsi 1:0:0:0: Direct-Access ATA Maxtor 6L250S0 BANC PQ: 0 ANSI: 5 >sd 1:0:0:0: [sdb] 490234752 512-byte hardware sectors (251000 MB) >sd 1:0:0:0: [sdb] Write Protect is off >sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 >sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA >sd 1:0:0:0: [sdb] 490234752 512-byte hardware sectors (251000 MB) >sd 1:0:0:0: [sdb] Write Protect is off >sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 >sd 1:0:0:0: [sdb] Write cac
Re: [PATCH 00/12] sata_mv NCQ support
Mark Lord wrote: Here is a set of 12 patches that gradually add working NCQ support to sata_mv. .. Well, 14 patches, not 12. But they're mostly very small. :) - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/14] sata_mv Enable NCQ operation
sata_mv Enable NCQ operation.
Final changes to actually turn on NCQ in the driver for GEN II/IIE hardware.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
--- old/drivers/ata/sata_mv.c 2008-01-24 14:46:16.0 -0500
+++ new/drivers/ata/sata_mv.c 2008-01-24 14:49:28.0 -0500
@@ -499,7 +499,8 @@
.name = DRV_NAME,
.ioctl = ata_scsi_ioctl,
.queuecommand = ata_scsi_queuecmd,
- .can_queue = ATA_DEF_QUEUE,
+ .change_queue_depth = ata_scsi_change_queue_depth,
+ .can_queue = MV_MAX_Q_DEPTH - 1,
.this_id= ATA_SHT_THIS_ID,
.sg_tablesize = MV_MAX_SG_CT / 2,
.cmd_per_lun= ATA_SHT_CMD_PER_LUN,
@@ -617,26 +618,29 @@
.port_ops = &mv5_ops,
},
{ /* chip_604x */
- .flags = MV_COMMON_FLAGS | MV_6XXX_FLAGS,
+ .flags = MV_COMMON_FLAGS | MV_6XXX_FLAGS |
+ ATA_FLAG_NCQ,
.pio_mask = 0x1f, /* pio0-4 */
.udma_mask = ATA_UDMA6,
.port_ops = &mv6_ops,
},
{ /* chip_608x */
.flags = MV_COMMON_FLAGS | MV_6XXX_FLAGS |
- MV_FLAG_DUAL_HC,
+ MV_FLAG_DUAL_HC | ATA_FLAG_NCQ,
.pio_mask = 0x1f, /* pio0-4 */
.udma_mask = ATA_UDMA6,
.port_ops = &mv6_ops,
},
{ /* chip_6042 */
- .flags = MV_COMMON_FLAGS | MV_6XXX_FLAGS,
+ .flags = MV_COMMON_FLAGS | MV_6XXX_FLAGS |
+ ATA_FLAG_NCQ,
.pio_mask = 0x1f, /* pio0-4 */
.udma_mask = ATA_UDMA6,
.port_ops = &mv_iie_ops,
},
{ /* chip_7042 */
- .flags = MV_COMMON_FLAGS | MV_6XXX_FLAGS,
+ .flags = MV_COMMON_FLAGS | MV_6XXX_FLAGS |
+ ATA_FLAG_NCQ,
.pio_mask = 0x1f, /* pio0-4 */
.udma_mask = ATA_UDMA6,
.port_ops = &mv_iie_ops,
@@ -1291,7 +1295,8 @@
u16 flags = 0;
unsigned in_index;
- if (qc->tf.protocol != ATA_PROT_DMA)
+ if ((qc->tf.protocol != ATA_PROT_DMA) &&
+ (qc->tf.protocol != ATA_PROT_NCQ))
return;
/* Fill in command request block
@@ -1327,13 +1332,11 @@
case ATA_CMD_WRITE_FUA_EXT:
mv_crqb_pack_cmd(cw++, tf->hob_nsect, ATA_REG_NSECT, 0);
break;
-#ifdef LIBATA_NCQ /* FIXME: remove this line when NCQ added */
case ATA_CMD_FPDMA_READ:
case ATA_CMD_FPDMA_WRITE:
mv_crqb_pack_cmd(cw++, tf->hob_feature, ATA_REG_FEATURE, 0);
mv_crqb_pack_cmd(cw++, tf->feature, ATA_REG_FEATURE, 0);
break;
-#endif /* FIXME: remove this line when NCQ added */
default:
/* The only other commands EDMA supports in non-queued and
* non-NCQ mode are: [RW] STREAM DMA and W DMA FUA EXT, none
@@ -1382,7 +1385,8 @@
unsigned in_index;
u32 flags = 0;
- if (qc->tf.protocol != ATA_PROT_DMA)
+ if ((qc->tf.protocol != ATA_PROT_DMA) &&
+ (qc->tf.protocol != ATA_PROT_NCQ))
return;
/* Fill in Gen IIE command request block
@@ -1448,7 +1452,8 @@
struct mv_port_priv *pp = ap->private_data;
u32 in_index;
- if (qc->tf.protocol != ATA_PROT_DMA) {
+ if ((qc->tf.protocol != ATA_PROT_DMA) &&
+ (qc->tf.protocol != ATA_PROT_NCQ)) {
/* We're about to send a non-EDMA capable command to the
* port. Turn off EDMA so there won't be problems accessing
* shadow block, etc registers.
@@ -1459,12 +1464,6 @@
mv_start_dma(ap, port_mmio, pp, qc->tf.protocol);
- in_index = pp->req_idx & MV_MAX_Q_DEPTH_MASK;
-
- /* until we do queuing, the queue should be empty at this point */
- WARN_ON(in_index != ((readl(port_mmio + EDMA_REQ_Q_OUT_PTR_OFS)
- >> EDMA_REQ_Q_PTR_SHIFT) & MV_MAX_Q_DEPTH_MASK));
-
pp->req_idx++;
in_index = (pp->req_idx & MV_MAX_Q_DEPTH_MASK) << EDMA_REQ_Q_PTR_SHIFT;
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/14] sata_mv No soft resets
sata_mv No soft resets.
Soft resets rarely have significant effect with these chips,
so always do a hard reset instead.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
--- old/drivers/ata/sata_mv.c 2008-01-24 14:49:28.0 -0500
+++ new/drivers/ata/sata_mv.c 2008-01-24 14:51:53.0 -0500
@@ -2414,8 +2414,7 @@
static void mv_error_handler(struct ata_port *ap)
{
- ata_do_eh(ap, mv_prereset, ata_std_softreset,
- mv_hardreset, mv_postreset);
+ ata_do_eh(ap, mv_prereset, NULL, mv_hardreset, mv_postreset);
}
static void mv_post_int_cmd(struct ata_queued_cmd *qc)
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/14] sata_mv Comments and version bump
sata_mv Comments and version bump.
Remove some obsolete comments, and bump up the driver version number.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
--- old/drivers/ata/sata_mv.c 2008-01-24 15:09:31.0 -0500
+++ new/drivers/ata/sata_mv.c 2008-01-24 15:41:17.0 -0500
@@ -29,8 +29,6 @@
I distinctly remember a couple workarounds (one related to PCI-X)
are still needed.
- 4) Add NCQ support (easy to intermediate, once new-EH support appears)
-
5) Investigate problems with PCI Message Signalled Interrupts (MSI).
6) Add port multiplier support (intermediate)
@@ -53,8 +51,6 @@
Target mode, for those without docs, is the ability to directly
connect two SATA controllers.
- 13) Verify that 7042 is fully supported. I only have a 6042.
-
*/
@@ -73,7 +69,7 @@
#include
#define DRV_NAME"sata_mv"
-#define DRV_VERSION"1.01"
+#define DRV_VERSION"1.20"
enum {
/* BAR's are enumerated in terms of pci_resource_start() terms */
@@ -885,7 +881,7 @@
static void mv_start_dma(struct ata_port *ap, void __iomem *port_mmio,
struct mv_port_priv *pp, u8 protocol)
{
- int want_ncq = ata_is_ncq(protocol);
+ int want_ncq = (protocol == ATA_PROT_NCQ);
if (pp->pp_flags & MV_PP_FLAG_EDMA_EN) {
int using_ncq = ((pp->pp_flags & MV_PP_FLAG_NCQ_EN) != 0);
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/12] sata_mv Introduce per-tag SG tables
sata_mv Introduce per-tag SG tables.
In preparation for supporting NCQ, we must allocate separate SG tables
for each command tag, rather than just a single table per port as before.
Gen-I hardware cannot do NCQ, though, so we still allocate just a single
table for that, but populate it in all 32 slots to avoid special-cases
elsewhere in hotter paths of the code.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
--- old/drivers/ata/sata_mv.c 2008-01-24 14:17:39.0 -0500
+++ new/drivers/ata/sata_mv.c 2008-01-24 14:46:16.0 -0500
@@ -395,8 +395,8 @@
dma_addr_t crqb_dma;
struct mv_crpb *crpb;
dma_addr_t crpb_dma;
- struct mv_sg*sg_tbl;
- dma_addr_t sg_tbl_dma;
+ struct mv_sg*sg_tbl[MV_MAX_Q_DEPTH];
+ dma_addr_t sg_tbl_dma[MV_MAX_Q_DEPTH];
unsigned intreq_idx;
unsigned intresp_idx;
@@ -472,6 +472,10 @@
void __iomem *port_mmio, int want_ncq);
static int __mv_stop_dma(struct ata_port *ap);
+/* .sg_tablesize is (MV_MAX_SG_CT / 2) in the structures below
+ * because we have to allow room for worst case splitting of
+ * PRDs for 64K boundaries in mv_fill_sg().
+ */
static struct scsi_host_template mv5_sht = {
.module = THIS_MODULE,
.name = DRV_NAME,
@@ -711,12 +715,23 @@
static void mv_free_pool_items(struct ata_port *ap)
{
+ struct mv_host_priv *hpriv = ap->host->private_data;
struct mv_port_priv *pp = ap->private_data;
+ int tag;
- if (pp->sg_tbl) {
- dma_pool_free(mv_sg_tbl_pool, pp->sg_tbl, pp->sg_tbl_dma);
- pp->sg_tbl = NULL;
+ /*
+* For GEN_I, there's no NCQ, so we have only a single sg_tbl.
+* For later hardware, we have one unique sg_tbl per NCQ tag.
+*/
+ for (tag = 0; tag < MV_MAX_Q_DEPTH; ++tag) {
+ if (pp->sg_tbl[tag]) {
+ if (tag == 0 || !IS_GEN_I(hpriv))
+ dma_pool_free(mv_sg_tbl_pool, pp->sg_tbl[tag],
+ pp->sg_tbl_dma[tag]);
+ pp->sg_tbl[tag] = NULL;
+ }
}
+
if (pp->crqb) {
dma_pool_free(mv_crqb_pool, pp->crqb, pp->crqb_dma);
pp->crpb = NULL;
@@ -1136,7 +1151,7 @@
struct mv_port_priv *pp;
void __iomem *port_mmio = mv_ap_base(ap);
unsigned long flags;
- int rc;
+ int tag, rc;
pp = devm_kzalloc(dev, sizeof(*pp), GFP_KERNEL);
if (!pp)
@@ -1153,10 +1168,21 @@
pp->crpb = dma_pool_alloc(mv_crpb_pool, GFP_KERNEL, &pp->crpb_dma);
if (!pp->crpb)
goto out_alloc_failed;
-
- pp->sg_tbl = dma_pool_alloc(mv_sg_tbl_pool, GFP_KERNEL,
&pp->sg_tbl_dma);
- if (!pp->sg_tbl)
- goto out_alloc_failed;
+ /*
+* For GEN_I, there's no NCQ, so we only allocate a single sg_tbl.
+* For later hardware, we need one unique sg_tbl per NCQ tag.
+*/
+ for (tag = 0; tag < MV_MAX_Q_DEPTH; ++tag) {
+ if (tag == 0 || !IS_GEN_I(hpriv)) {
+ pp->sg_tbl[tag] = dma_pool_alloc(mv_sg_tbl_pool,
+ GFP_KERNEL, &pp->sg_tbl_dma[tag]);
+ if (!pp->sg_tbl[tag])
+ goto out_alloc_failed;
+ } else {
+ pp->sg_tbl[tag] = pp->sg_tbl[0];
+ pp->sg_tbl_dma[tag] = pp->sg_tbl_dma[0];
+ }
+ }
spin_lock_irqsave(&ap->host->lock, flags);
@@ -1209,7 +1235,7 @@
struct mv_sg *mv_sg, *last_sg = NULL;
unsigned int si;
- mv_sg = pp->sg_tbl;
+ mv_sg = pp->sg_tbl[qc->tag];
for_each_sg(qc->sg, sg, qc->n_elem, si) {
dma_addr_t addr = sg_dma_address(sg);
u32 sg_len = sg_dma_len(sg);
@@ -1279,9 +1305,9 @@
in_index = pp->req_idx & MV_MAX_Q_DEPTH_MASK;
pp->crqb[in_index].sg_addr =
- cpu_to_le32(pp->sg_tbl_dma & 0x);
+ cpu_to_le32(pp->sg_tbl_dma[qc->tag] & 0x);
pp->crqb[in_index].sg_addr_hi =
- cpu_to_le32((pp->sg_tbl_dma >> 16) >> 16);
+ cpu_to_le32((pp->sg_tbl_dma[qc->tag] >> 16) >> 16);
pp->crqb[in_index].ctrl_flags = cpu_to_le16(flags);
cw = &pp->crqb[in_index].ata_cmd[0];
@@ -1372,8 +1398,8 @@
in_index = pp->req_idx & MV_MAX_Q_DEPTH_MASK;
crqb = (struct mv_crqb_iie *) &pp->crqb[in_index];
- crqb->addr = cpu_to_le32(pp->sg_tbl_dma & 0x);
- crqb->addr_hi = cpu_to_le32((pp->sg_tbl_dma >> 16) >> 16);
+ crqb->addr = cpu_to_le32(pp->sg_tbl_dma[qc->tag] & 0x);
+ crqb->addr_hi = cpu_to_le32((pp->sg_tbl_dma[qc->tag] >> 16) >> 16);
[PATCH 10/14] sata_mv Use DMA memory pools for hardware memory tables
sata_mv Use DMA memory pools for hardware memory tables.
Create module-owned DMA memory pools, for use in allocating/freeing per-port
command/response queues and SG tables. This gives us a way to guarantee we
meet the hardware address alignment requirements, and also reduces memory that
might otherwise be wasted on alignment gaps.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
--- old/drivers/ata/sata_mv.c 2008-01-24 12:40:10.0 -0500
+++ new/drivers/ata/sata_mv.c 2008-01-24 14:17:39.0 -0500
@@ -107,14 +107,12 @@
/* CRQB needs alignment on a 1KB boundary. Size == 1KB
* CRPB needs alignment on a 256B boundary. Size == 256B
-* SG count of 176 leads to MV_PORT_PRIV_DMA_SZ == 4KB
* ePRD (SG) entries need alignment on a 16B boundary. Size == 16B
*/
MV_CRQB_Q_SZ= (32 * MV_MAX_Q_DEPTH),
MV_CRPB_Q_SZ= (8 * MV_MAX_Q_DEPTH),
- MV_MAX_SG_CT= 176,
+ MV_MAX_SG_CT= 256,
MV_SG_TBL_SZ= (16 * MV_MAX_SG_CT),
- MV_PORT_PRIV_DMA_SZ = (MV_CRQB_Q_SZ + MV_CRPB_Q_SZ + MV_SG_TBL_SZ),
MV_PORTS_PER_HC = 4,
/* == (port / MV_PORTS_PER_HC) to determine HC from 0-7 port */
@@ -701,6 +699,33 @@
*/
static int msi; /* Use PCI msi; either zero (off, default) or non-zero */
+/*
+ * These consistent DMA memory pools are owned by this module,
+ * and shared among all device instances. This gives us guaranteed
+ * alignment for hardware-accessed data structures, and low memory
+ * waste in accomplishing the alignment.
+ */
+static struct dma_pool *mv_crpb_pool;
+static struct dma_pool *mv_crqb_pool;
+static struct dma_pool *mv_sg_tbl_pool;
+
+static void mv_free_pool_items(struct ata_port *ap)
+{
+ struct mv_port_priv *pp = ap->private_data;
+
+ if (pp->sg_tbl) {
+ dma_pool_free(mv_sg_tbl_pool, pp->sg_tbl, pp->sg_tbl_dma);
+ pp->sg_tbl = NULL;
+ }
+ if (pp->crqb) {
+ dma_pool_free(mv_crqb_pool, pp->crqb, pp->crqb_dma);
+ pp->crpb = NULL;
+ }
+ if (pp->crqb) {
+ dma_pool_free(mv_crqb_pool, pp->crqb, pp->crqb_dma);
+ pp->crqb = NULL;
+ }
+}
/* move to PCI layer or libata core? */
static int pci_go_64(struct pci_dev *pdev)
@@ -1110,8 +1135,6 @@
struct mv_host_priv *hpriv = ap->host->private_data;
struct mv_port_priv *pp;
void __iomem *port_mmio = mv_ap_base(ap);
- void *mem;
- dma_addr_t mem_dma;
unsigned long flags;
int rc;
@@ -1119,37 +1142,21 @@
if (!pp)
return -ENOMEM;
- mem = dmam_alloc_coherent(dev, MV_PORT_PRIV_DMA_SZ, &mem_dma,
- GFP_KERNEL);
- if (!mem)
- return -ENOMEM;
- memset(mem, 0, MV_PORT_PRIV_DMA_SZ);
-
rc = ata_pad_alloc(ap, dev);
if (rc)
return rc;
- /* First item in chunk of DMA memory:
-* 32-slot command request table (CRQB), 32 bytes each in size
-*/
- pp->crqb = mem;
- pp->crqb_dma = mem_dma;
- mem += MV_CRQB_Q_SZ;
- mem_dma += MV_CRQB_Q_SZ;
-
- /* Second item:
-* 32-slot command response table (CRPB), 8 bytes each in size
-*/
- pp->crpb = mem;
- pp->crpb_dma = mem_dma;
- mem += MV_CRPB_Q_SZ;
- mem_dma += MV_CRPB_Q_SZ;
-
- /* Third item:
-* Table of scatter-gather descriptors (ePRD), 16 bytes each
-*/
- pp->sg_tbl = mem;
- pp->sg_tbl_dma = mem_dma;
+ pp->crqb = dma_pool_alloc(mv_crqb_pool, GFP_KERNEL, &pp->crqb_dma);
+ if (!pp->crqb)
+ goto out_alloc_failed;
+
+ pp->crpb = dma_pool_alloc(mv_crpb_pool, GFP_KERNEL, &pp->crpb_dma);
+ if (!pp->crpb)
+ goto out_alloc_failed;
+
+ pp->sg_tbl = dma_pool_alloc(mv_sg_tbl_pool, GFP_KERNEL,
&pp->sg_tbl_dma);
+ if (!pp->sg_tbl)
+ goto out_alloc_failed;
spin_lock_irqsave(&ap->host->lock, flags);
@@ -1165,6 +1172,10 @@
*/
ap->private_data = pp;
return 0;
+
+out_alloc_failed:
+ mv_free_pool_items(ap);
+ return -ENOMEM;
}
/**
@@ -1179,6 +1190,7 @@
static void mv_port_stop(struct ata_port *ap)
{
mv_stop_dma(ap);
+ mv_free_pool_items(ap);
}
/**
@@ -2825,14 +2837,39 @@
IS_GEN_I(hpriv) ? &mv5_sht : &mv6_sht);
}
+static void mv_destroy_pools(void)
+{
+ if (mv_sg_tbl_pool)
+ dma_pool_destroy(mv_sg_tbl_pool);
+ if (mv_crpb_pool)
+ dma_pool_destroy(mv_crpb_pool);
+ if (mv_crqb_pool)
+ dma_pool_destroy(mv_crqb_pool);
+}
+
static int __init mv_init(void)
{
+ /* Ideally, a device (second parameter) would "own" these pools.
+* But for maximum memory efficiency, we really need one global
+* set of each, shared among all like devi
[PATCH 08/14] sata_mv Ignore response status LSB on NCQ
sata_mv Ignore response status LSB on NCQ.
The lower 8 bits of response status are not valid for NCQ.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
--- old/drivers/ata/sata_mv.c 2008-01-24 12:35:14.0 -0500
+++ new/drivers/ata/sata_mv.c 2008-01-24 12:35:43.0 -0500
@@ -1587,13 +1587,12 @@
qc = ata_qc_from_tag(ap, tag);
- /* lower 8 bits of status are EDMA_ERR_IRQ_CAUSE_OFS
-* bits (WARNING: might not necessarily be associated
-* with this command), which -should- be clear
-* if all is well
+ /* For non-NCQ mode, the lower 8 bits of status
+* are from EDMA_ERR_IRQ_CAUSE_OFS,
+* which should be zero if all went well.
*/
status = le16_to_cpu(pp->crpb[out_index].flags);
- if (unlikely(status & 0xff)) {
+ if ((status & 0xff) && !(pp->pp_flags & MV_PP_FLAG_NCQ_EN)) {
mv_err_intr(ap, qc);
return;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/14] sata_mv Restrict max_sectors to 8-bits on GenII NCQ
sata_mv Restrict max_sectors to 8-bits on GenII NCQ.
The GenII chips have only 8-bits for the sector_count field when performing NCQ.
Add a dev_config method to restrict this when necessary, taking care not to
override any other restriction already in place (likely none, but someday.. ?).
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
--- old/drivers/ata/sata_mv.c 2008-01-24 12:35:43.0 -0500
+++ new/drivers/ata/sata_mv.c 2008-01-24 12:40:10.0 -0500
@@ -446,6 +446,7 @@
static void mv_post_int_cmd(struct ata_queued_cmd *qc);
static void mv_eh_freeze(struct ata_port *ap);
static void mv_eh_thaw(struct ata_port *ap);
+static void mv6_dev_config(struct ata_device *dev);
static int mv_init_one(struct pci_dev *pdev, const struct pci_device_id *ent);
static void mv5_phy_errata(struct mv_host_priv *hpriv, void __iomem *mmio,
@@ -538,6 +539,7 @@
};
static const struct ata_port_operations mv6_ops = {
+ .dev_config = mv6_dev_config,
.tf_load= ata_tf_load,
.tf_read= ata_tf_read,
.check_status = ata_check_status,
@@ -1051,6 +1053,17 @@
return -EINVAL;
}
+static void mv6_dev_config(struct ata_device *adev)
+{
+ /*
+* We don't have hob_nsect when doing NCQ commands on Gen-II.
+* See mv_qc_prep() for more info.
+*/
+ if (adev->flags & ATA_DFLAG_NCQ)
+ if (adev->max_sectors > ATA_MAX_SECTORS)
+ adev->max_sectors = ATA_MAX_SECTORS;
+}
+
static void mv_edma_cfg(struct mv_port_priv *pp, struct mv_host_priv *hpriv,
void __iomem *port_mmio, int want_ncq)
{
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/14] sata_mv Use hqtag instead of ioid
sata_mv Use hqtag instead of ioid. Simplify tag handling by using the cid/hqtag field instead of ioid, as recommended by Marvell. Signed-off-by: Mark Lord <[EMAIL PROTECTED]> --- old/drivers/ata/sata_mv.c 2008-01-24 12:07:16.0 -0500 +++ new/drivers/ata/sata_mv.c 2008-01-24 12:35:14.0 -0500 @@ -132,15 +132,12 @@ CRQB_FLAG_READ = (1 << 0), CRQB_TAG_SHIFT = 1, - CRQB_IOID_SHIFT = 6,/* CRQB Gen-II/IIE IO Id shift */ CRQB_HOSTQ_SHIFT= 17, /* CRQB Gen-II/IIE HostQueTag shift */ CRQB_CMD_ADDR_SHIFT = 8, CRQB_CMD_CS = (0x2 << 11), CRQB_CMD_LAST = (1 << 15), CRPB_FLAG_STATUS_SHIFT = 8, - CRPB_IOID_SHIFT_6 = 5,/* CRPB Gen-II IO Id shift */ - CRPB_IOID_SHIFT_7 = 7,/* CRPB Gen-IIE IO Id shift */ EPRD_FLAG_END_OF_TBL= (1 << 31), @@ -1252,7 +1249,6 @@ flags |= CRQB_FLAG_READ; WARN_ON(MV_MAX_Q_DEPTH <= qc->tag); flags |= qc->tag << CRQB_TAG_SHIFT; - flags |= qc->tag << CRQB_IOID_SHIFT; /* 50xx appears to ignore this*/ /* get current queue index from software */ in_index = pp->req_idx & MV_MAX_Q_DEPTH_MASK; @@ -1345,8 +1341,7 @@ WARN_ON(MV_MAX_Q_DEPTH <= qc->tag); flags |= qc->tag << CRQB_TAG_SHIFT; - flags |= qc->tag << CRQB_IOID_SHIFT; /* "I/O Id" is -really- - what we use as our tag */ + flags |= qc->tag << CRQB_HOSTQ_SHIFT; /* get current queue index from software */ in_index = pp->req_idx & MV_MAX_Q_DEPTH_MASK; @@ -1587,13 +1582,8 @@ * support for queueing. this works transparently for * queued and non-queued modes. */ - else if (IS_GEN_II(hpriv)) - tag = (le16_to_cpu(pp->crpb[out_index].id) - >> CRPB_IOID_SHIFT_6) & 0x3f; - - else /* IS_GEN_IIE */ - tag = (le16_to_cpu(pp->crpb[out_index].id) - >> CRPB_IOID_SHIFT_7) & 0x3f; + else + tag = le16_to_cpu(pp->crpb[out_index].id) & 0x1f; qc = ata_qc_from_tag(ap, tag); - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/14] sata_mv Add want_ncq parameter for EDMA configuration
sata_mv Add want_ncq parameter for EDMA configuration.
An extra EDMA config bit is required for NCQ operation.
So set/clear it as needed, and cache current setting in port_priv.
For now though, it will always be "off" (0).
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
--- old/drivers/ata/sata_mv.c 2008-01-24 12:12:37.0 -0500
+++ new/drivers/ata/sata_mv.c 2008-01-24 12:07:16.0 -0500
@@ -331,6 +331,7 @@
/* Port private flags (pp_flags) */
MV_PP_FLAG_EDMA_EN = (1 << 0), /* is EDMA engine enabled? */
+ MV_PP_FLAG_NCQ_EN = (1 << 1), /* is EDMA set up for NCQ? */
MV_PP_FLAG_HAD_A_RESET = (1 << 2), /* 1st hard reset complete? */
};
@@ -471,8 +472,9 @@
static void mv_reset_pci_bus(struct pci_dev *pdev, void __iomem *mmio);
static void mv_channel_reset(struct mv_host_priv *hpriv, void __iomem *mmio,
unsigned int port_no);
-static void mv_edma_cfg(struct ata_port *ap, struct mv_host_priv *hpriv,
- void __iomem *port_mmio);
+static void mv_edma_cfg(struct mv_port_priv *pp, struct mv_host_priv *hpriv,
+ void __iomem *port_mmio, int want_ncq);
+static int __mv_stop_dma(struct ata_port *ap);
static struct scsi_host_template mv5_sht = {
.module = THIS_MODULE,
@@ -838,8 +840,15 @@
* Inherited from caller.
*/
static void mv_start_dma(struct ata_port *ap, void __iomem *port_mmio,
-struct mv_port_priv *pp)
+struct mv_port_priv *pp, u8 protocol)
{
+ int want_ncq = ata_is_ncq(protocol);
+
+ if (pp->pp_flags & MV_PP_FLAG_EDMA_EN) {
+ int using_ncq = ((pp->pp_flags & MV_PP_FLAG_NCQ_EN) != 0);
+ if (want_ncq != using_ncq)
+ __mv_stop_dma(ap);
+ }
if (!(pp->pp_flags & MV_PP_FLAG_EDMA_EN)) {
struct mv_host_priv *hpriv = ap->host->private_data;
int hard_port = mv_hardport_from_port(ap->port_no);
@@ -859,7 +868,7 @@
hc_mmio + HC_IRQ_CAUSE_OFS);
}
- mv_edma_cfg(ap, hpriv, port_mmio);
+ mv_edma_cfg(pp, hpriv, port_mmio, want_ncq);
/* clear FIS IRQ Cause */
writelfl(0, port_mmio + SATA_FIS_IRQ_CAUSE_OFS);
@@ -1045,8 +1054,8 @@
return -EINVAL;
}
-static void mv_edma_cfg(struct ata_port *ap, struct mv_host_priv *hpriv,
- void __iomem *port_mmio)
+static void mv_edma_cfg(struct mv_port_priv *pp, struct mv_host_priv *hpriv,
+ void __iomem *port_mmio, int want_ncq)
{
u32 cfg;
@@ -1066,6 +1075,12 @@
cfg |= (1 << 17); /* enab cut-through (dis stor&forwrd) */
}
+ if (want_ncq) {
+ cfg |= EDMA_CFG_NCQ;
+ pp->pp_flags |= MV_PP_FLAG_NCQ_EN;
+ } else
+ pp->pp_flags &= ~MV_PP_FLAG_NCQ_EN;
+
writelfl(cfg, port_mmio + EDMA_CFG_OFS);
}
@@ -1128,7 +1143,7 @@
spin_lock_irqsave(&ap->host->lock, flags);
- mv_edma_cfg(ap, hpriv, port_mmio);
+ mv_edma_cfg(pp, hpriv, port_mmio, 0);
mv_set_edma_ptrs(port_mmio, hpriv, pp);
@@ -1396,7 +1411,7 @@
return ata_qc_issue_prot(qc);
}
- mv_start_dma(ap, port_mmio, pp);
+ mv_start_dma(ap, port_mmio, pp, qc->tf.protocol);
in_index = pp->req_idx & MV_MAX_Q_DEPTH_MASK;
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/14] sata_mv Fix EDMA configuration
sata_mv Fix EDMA configuration.
Simplify and fix EDMA configuration setup to match Marvell specificiations.
The chip documentation gives a specific (re)init sequence, which we now follow.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
--- old/drivers/ata/sata_mv.c 2008-01-24 12:06:25.0 -0500
+++ new/drivers/ata/sata_mv.c 2008-01-24 12:12:37.0 -0500
@@ -210,6 +210,7 @@
/* SATA registers */
SATA_STATUS_OFS = 0x300, /* ctrl, err regs follow status */
SATA_ACTIVE_OFS = 0x350,
+ SATA_FIS_IRQ_CAUSE_OFS = 0x364,
PHY_MODE3 = 0x310,
PHY_MODE4 = 0x314,
PHY_MODE2 = 0x330,
@@ -222,11 +223,11 @@
/* Port registers */
EDMA_CFG_OFS= 0,
- EDMA_CFG_Q_DEPTH= 0,/* queueing disabled */
- EDMA_CFG_NCQ= (1 << 5),
- EDMA_CFG_NCQ_GO_ON_ERR = (1 << 14), /* continue on error
*/
- EDMA_CFG_RD_BRST_EXT= (1 << 11), /* read burst 512B */
- EDMA_CFG_WR_BUFF_LEN= (1 << 13), /* write buffer 512B
*/
+ EDMA_CFG_Q_DEPTH= 0x1f, /* max device queue depth */
+ EDMA_CFG_NCQ= (1 << 5), /* for R/W FPDMA queued */
+ EDMA_CFG_NCQ_GO_ON_ERR = (1 << 14), /* continue on error */
+ EDMA_CFG_RD_BRST_EXT= (1 << 11), /* read burst 512B */
+ EDMA_CFG_WR_BUFF_LEN= (1 << 13), /* write buffer 512B */
EDMA_ERR_IRQ_CAUSE_OFS = 0x8,
EDMA_ERR_IRQ_MASK_OFS = 0xc,
@@ -470,6 +471,8 @@
static void mv_reset_pci_bus(struct pci_dev *pdev, void __iomem *mmio);
static void mv_channel_reset(struct mv_host_priv *hpriv, void __iomem *mmio,
unsigned int port_no);
+static void mv_edma_cfg(struct ata_port *ap, struct mv_host_priv *hpriv,
+ void __iomem *port_mmio);
static struct scsi_host_template mv5_sht = {
.module = THIS_MODULE,
@@ -834,13 +837,33 @@
* LOCKING:
* Inherited from caller.
*/
-static void mv_start_dma(void __iomem *port_mmio, struct mv_host_priv *hpriv,
+static void mv_start_dma(struct ata_port *ap, void __iomem *port_mmio,
struct mv_port_priv *pp)
{
if (!(pp->pp_flags & MV_PP_FLAG_EDMA_EN)) {
+ struct mv_host_priv *hpriv = ap->host->private_data;
+ int hard_port = mv_hardport_from_port(ap->port_no);
+ void __iomem *hc_mmio = mv_hc_base_from_port(
+ ap->host->iomap[MV_PRIMARY_BAR], hard_port);
+ u32 hc_irq_cause, ipending;
+
/* clear EDMA event indicators, if any */
writelfl(0, port_mmio + EDMA_ERR_IRQ_CAUSE_OFS);
+ /* clear EDMA interrupt indicator, if any */
+ hc_irq_cause = readl(hc_mmio + HC_IRQ_CAUSE_OFS);
+ ipending = (DEV_IRQ << hard_port) |
+ (CRPB_DMA_DONE << hard_port);
+ if (hc_irq_cause & ipending) {
+ writelfl(hc_irq_cause & ~ipending,
+hc_mmio + HC_IRQ_CAUSE_OFS);
+ }
+
+ mv_edma_cfg(ap, hpriv, port_mmio);
+
+ /* clear FIS IRQ Cause */
+ writelfl(0, port_mmio + SATA_FIS_IRQ_CAUSE_OFS);
+
mv_set_edma_ptrs(port_mmio, hpriv, pp);
writelfl(EDMA_EN, port_mmio + EDMA_CMD_OFS);
@@ -1025,30 +1048,22 @@
static void mv_edma_cfg(struct ata_port *ap, struct mv_host_priv *hpriv,
void __iomem *port_mmio)
{
- u32 cfg = readl(port_mmio + EDMA_CFG_OFS);
+ u32 cfg;
/* set up non-NCQ EDMA configuration */
- cfg &= ~(1 << 9); /* disable eQue */
+ cfg = EDMA_CFG_Q_DEPTH; /* always 0x1f for *all* chips */
- if (IS_GEN_I(hpriv)) {
- cfg &= ~0x1f; /* clear queue depth */
+ if (IS_GEN_I(hpriv))
cfg |= (1 << 8); /* enab config burst size mask */
- }
- else if (IS_GEN_II(hpriv)) {
- cfg &= ~0x1f; /* clear queue depth */
+ else if (IS_GEN_II(hpriv))
cfg |= EDMA_CFG_RD_BRST_EXT | EDMA_CFG_WR_BUFF_LEN;
- cfg &= ~(EDMA_CFG_NCQ | EDMA_CFG_NCQ_GO_ON_ERR); /* clear NCQ */
- }
else if (IS_GEN_IIE(hpriv)) {
cfg |= (1 << 23); /* do not mask PM field in rx'd FIS */
cfg |= (1 << 22); /* enab 4-entry host queue cache */
- cfg &= ~(1 << 19);/* dis 128-entry queue (for now?) */
cfg |= (1 << 18); /* enab early completion */
cfg |= (1 << 17); /* enab cut-through (dis stor&forwrd) */
- cfg &= ~(1 << 16);/* dis FIS-based switching (for now) */
- cfg &= ~(EDMA_CFG_NCQ); /* clear NCQ */
}
writelfl(cfg, p
[PATCH 04/14] sata_mv rename base to port_mmio
sata_mv rename base to port_mmio.
Use naming consistent with elsewhere in this driver.
This will keep things less confusing when we later add "hc_mmio" in this
function.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
--- old/drivers/ata/sata_mv.c 2008-01-24 11:23:05.0 -0500
+++ new/drivers/ata/sata_mv.c 2008-01-24 11:26:33.0 -0500
@@ -834,19 +834,19 @@
* LOCKING:
* Inherited from caller.
*/
-static void mv_start_dma(void __iomem *base, struct mv_host_priv *hpriv,
+static void mv_start_dma(void __iomem *port_mmio, struct mv_host_priv *hpriv,
struct mv_port_priv *pp)
{
if (!(pp->pp_flags & MV_PP_FLAG_EDMA_EN)) {
/* clear EDMA event indicators, if any */
- writelfl(0, base + EDMA_ERR_IRQ_CAUSE_OFS);
+ writelfl(0, port_mmio + EDMA_ERR_IRQ_CAUSE_OFS);
- mv_set_edma_ptrs(base, hpriv, pp);
+ mv_set_edma_ptrs(port_mmio, hpriv, pp);
- writelfl(EDMA_EN, base + EDMA_CMD_OFS);
+ writelfl(EDMA_EN, port_mmio + EDMA_CMD_OFS);
pp->pp_flags |= MV_PP_FLAG_EDMA_EN;
}
- WARN_ON(!(EDMA_EN & readl(base + EDMA_CMD_OFS)));
+ WARN_ON(!(EDMA_EN & readl(port_mmio + EDMA_CMD_OFS)));
}
/**
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/14] sata_mv Mask transient IRQs.
sata_mv Mask transient IRQs.
The chips can handle many transient errors internally without a software IRQ.
We now mask/ignore those interrupts here. This is necessary for NCQ, later on.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
--- old/drivers/ata/sata_mv.c 2008-01-24 11:11:26.0 -0500
+++ new/drivers/ata/sata_mv.c 2008-01-24 11:17:42.0 -0500
@@ -170,7 +170,7 @@
PCIE_IRQ_CAUSE_OFS = 0x1900,
PCIE_IRQ_MASK_OFS = 0x1910,
- PCIE_UNMASK_ALL_IRQS= 0x70a,/* assorted bits */
+ PCIE_UNMASK_ALL_IRQS= 0x40a,/* assorted bits */
HC_MAIN_IRQ_CAUSE_OFS = 0x1d60,
HC_MAIN_IRQ_MASK_OFS= 0x1d64,
@@ -241,17 +241,36 @@
EDMA_ERR_BIST_ASYNC = (1 << 8), /* BIST FIS or Async Notify */
EDMA_ERR_TRANS_IRQ_7= (1 << 8), /* Gen IIE transprt layer irq
*/
EDMA_ERR_CRQB_PAR = (1 << 9), /* CRQB parity error */
- EDMA_ERR_CRPB_PAR = (1 << 10), /* CRPB parity error */
- EDMA_ERR_INTRL_PAR = (1 << 11), /* internal parity error */
- EDMA_ERR_IORDY = (1 << 12), /* IORdy timeout */
- EDMA_ERR_LNK_CTRL_RX= (0xf << 13),/* link ctrl rx error */
- EDMA_ERR_LNK_CTRL_RX_2 = (1 << 15),
- EDMA_ERR_LNK_DATA_RX= (0xf << 17),/* link data rx error */
- EDMA_ERR_LNK_CTRL_TX= (0x1f << 21), /* link ctrl tx error */
- EDMA_ERR_LNK_DATA_TX= (0x1f << 26), /* link data tx error */
- EDMA_ERR_TRANS_PROTO= (1 << 31), /* transport protocol error */
- EDMA_ERR_OVERRUN_5 = (1 << 5),
- EDMA_ERR_UNDERRUN_5 = (1 << 6),
+ EDMA_ERR_CRPB_PAR = (1 << 10), /* CRPB parity error */
+ EDMA_ERR_INTRL_PAR = (1 << 11), /* internal parity error */
+ EDMA_ERR_IORDY = (1 << 12), /* IORdy timeout */
+
+ EDMA_ERR_LNK_CTRL_RX= (0xf << 13),/* link ctrl rx error */
+ EDMA_ERR_LNK_CTRL_RX_0 = (1 << 13), /* transient: CRC err */
+ EDMA_ERR_LNK_CTRL_RX_1 = (1 << 14), /* transient: FIFO err */
+ EDMA_ERR_LNK_CTRL_RX_2 = (1 << 15), /* fatal: caught SYNC */
+ EDMA_ERR_LNK_CTRL_RX_3 = (1 << 16), /* transient: FIS rx err */
+
+ EDMA_ERR_LNK_DATA_RX= (0xf << 17),/* link data rx error */
+
+ EDMA_ERR_LNK_CTRL_TX= (0x1f << 21), /* link ctrl tx error */
+ EDMA_ERR_LNK_CTRL_TX_0 = (1 << 21), /* transient: CRC err */
+ EDMA_ERR_LNK_CTRL_TX_1 = (1 << 22), /* transient: FIFO err */
+ EDMA_ERR_LNK_CTRL_TX_2 = (1 << 23), /* transient: caught SYNC */
+ EDMA_ERR_LNK_CTRL_TX_3 = (1 << 24), /* transient: caught DMAT */
+ EDMA_ERR_LNK_CTRL_TX_4 = (1 << 25), /* transient: FIS collision */
+
+ EDMA_ERR_LNK_DATA_TX= (0x1f << 26), /* link data tx error */
+
+ EDMA_ERR_TRANS_PROTO= (1 << 31), /* transport protocol error */
+ EDMA_ERR_OVERRUN_5 = (1 << 5),
+ EDMA_ERR_UNDERRUN_5 = (1 << 6),
+
+ EDMA_ERR_IRQ_TRANSIENT = EDMA_ERR_LNK_CTRL_RX_0 |
+ EDMA_ERR_LNK_CTRL_RX_1 |
+ EDMA_ERR_LNK_CTRL_RX_3 |
+ EDMA_ERR_LNK_CTRL_TX,
+
EDMA_EH_FREEZE = EDMA_ERR_D_PAR |
EDMA_ERR_PRD_PAR |
EDMA_ERR_DEV_DCON |
@@ -1716,18 +1735,19 @@
struct ata_host *host = dev_instance;
unsigned int hc, handled = 0, n_hcs;
void __iomem *mmio = host->iomap[MV_PRIMARY_BAR];
- u32 irq_stat;
+ u32 irq_stat, irq_mask;
+ spin_lock(&host->lock);
irq_stat = readl(mmio + HC_MAIN_IRQ_CAUSE_OFS);
+ irq_mask = readl(mmio + HC_MAIN_IRQ_MASK_OFS);
/* check the cases where we either have nothing pending or have read
* a bogus register value which can indicate HW removal or PCI fault
*/
- if (!irq_stat || (0xU == irq_stat))
- return IRQ_NONE;
+ if (!(irq_stat & irq_mask) || (0xU == irq_stat))
+ goto out_unlock;
n_hcs = mv_get_hc_count(host->ports[0]->flags);
- spin_lock(&host->lock);
if (unlikely(irq_stat & PCI_ERR)) {
mv_pci_error(host, mmio);
@@ -2428,8 +2448,8 @@
writelfl(readl(port_mmio + serr_ofs), port_mmio + serr_ofs);
writelfl(0, port_mmio + EDMA_ERR_IRQ_CAUSE_OFS);
- /* unmask all EDMA error interrupts */
- writelfl(~0, port_mmio + EDMA_ERR_IRQ_MASK_OFS);
+ /* unmask all non-transient EDMA error interrupts */
+ writelfl(~EDMA_ERR_IRQ_TRANSIENT, port_mmio + EDMA_ERR_IRQ_MASK_OFS);
VPRINTK("EDMA cfg=0x%08x EDMA IRQ err cause/mask=0x%08x/0x%08x\n",
readl(port_mmio + EDMA_CFG_OFS),
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [
[PATCH 03/14] sata_mv Clear queue indexes on chip restart
sata_mv Clear queue indexes on chip restart. Force in/out queue pointer indexes back to zero on any (re)init. This ensures things are in a consistent state after any chip/dev errors. Signed-off-by: Mark Lord <[EMAIL PROTECTED]> --- old/drivers/ata/sata_mv.c 2008-01-24 11:17:42.0 -0500 +++ new/drivers/ata/sata_mv.c 2008-01-24 11:23:05.0 -0500 @@ -792,7 +792,7 @@ /* * initialize request queue */ - index = (pp->req_idx & MV_MAX_Q_DEPTH_MASK) << EDMA_REQ_Q_PTR_SHIFT; + index = pp->req_idx = 0; WARN_ON(pp->crqb_dma & 0x3ff); writel((pp->crqb_dma >> 16) >> 16, port_mmio + EDMA_REQ_Q_BASE_HI_OFS); @@ -808,7 +808,7 @@ /* * initialize response queue */ - index = (pp->resp_idx & MV_MAX_Q_DEPTH_MASK) << EDMA_RSP_Q_PTR_SHIFT; + index = pp->resp_idx = 0; WARN_ON(pp->crpb_dma & 0xff); writel((pp->crpb_dma >> 16) >> 16, port_mmio + EDMA_RSP_Q_BASE_HI_OFS); - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/14] sata_mv EH fixes
sata_mv EH fixes.
A hard reset is necessary after hotplug events.
Only clear the error irq bits that were set on entry.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
--- old/drivers/ata/sata_mv.c 2008-01-24 10:40:11.0 -0500
+++ new/drivers/ata/sata_mv.c 2008-01-24 11:11:26.0 -0500
@@ -1437,6 +1437,7 @@
ata_ehi_hotplugged(ehi);
ata_ehi_push_desc(ehi, edma_err_cause & EDMA_ERR_DEV_DCON ?
"dev disconnect" : "dev connect");
+ action |= ATA_EH_HARDRESET;
}
if (IS_GEN_I(hpriv)) {
@@ -1465,7 +1466,7 @@
}
/* Clear EDMA now that SERR cleanup done */
- writelfl(0, port_mmio + EDMA_ERR_IRQ_CAUSE_OFS);
+ writelfl(~edma_err_cause, port_mmio + EDMA_ERR_IRQ_CAUSE_OFS);
if (!err_mask) {
err_mask = AC_ERR_OTHER;
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/12] sata_mv NCQ support
Here is a set of 12 patches that gradually add working NCQ support to sata_mv. The driver still has issues afterwards, but nothing new that wasn't broken already. I am working on additional patches to correct the interrupt and error handling problems that still exist in the driver, as well as PMP and ATAPI support (later). Patches are against Jeff's #upstream git from this morning. Cheers Mark - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ide-io: set REQ_FAILED when drive is dead
Currently it's possible to ide-cd to set an incorrect blocksize by
reading garbage if the drive is dead:
ide_cd_probe()
-> cdrom_read_toc()
-> cdrom_read_capacity()
-> cdrom_queue_packet_command()
-> ide_do_drive_cmd()
-> ide_do_request()
-> start_request()
on start_request():
/* bail early if we've exceeded max_failures */
if (drive->max_failures && (drive->failures > drive->max_failures)) {
goto kill_rq;
}
(...)
kill_rq:
ide_kill_rq(drive, rq);
return ide_stopped;
ide_kill_rq() and the next calls won't set REQ_FAILED on rq->cmd_flags and thus
cdrom_queue_packet_command() won't return an error. then:
stat = cdrom_queue_packet_command(drive, &req);
if (stat == 0) {
*capacity = 1 + be32_to_cpu(capbuf.lba);
*sectors_per_frame =
be32_to_cpu(capbuf.blocklen) >> SECTOR_BITS;
}
cdrom_read_capacity() ends believing capbuf is valid but in fact it's just
uninitialized data. back to cdrom_read_toc():
/* Try to get the total cdrom capacity and sector size. */
stat = cdrom_read_capacity(drive, &toc->capacity, §ors_per_frame,
sense);
if (stat)
toc->capacity = 0x1f;
set_capacity(info->disk, toc->capacity * sectors_per_frame);
/* Save a private copy of te TOC capacity for error handling */
drive->probed_capacity = toc->capacity * sectors_per_frame;
blk_queue_hardsect_size(drive->queue,
sectors_per_frame << SECTOR_BITS);
that will set drive->queue->hardsect_size to be the random value.
hardsect_size is used to calculate inode->i_blkbits. later on, on a read
path:
void create_empty_buffers(struct page *page,
unsigned long blocksize, unsigned long b_state)
{
struct buffer_head *bh, *head, *tail;
head = alloc_page_buffers(page, blocksize, 1);
bh = head;
do {
bh->b_state |= b_state;
tail = bh;
bh = bh->b_this_page;
} while (bh);
tail->b_this_page = head;
alloc_page_buffers() will return NULL if blocksize > 4096. blocksize is
calculed based on inode->i_blkbits. that will trigger a null
dereference on create_empty_buffers().
Signed-off-by: Aristeu Rozanski <[EMAIL PROTECTED]>
---
drivers/ide/ide-io.c |1 +
1 file changed, 1 insertion(+)
--- linus-2.6.orig/drivers/ide/ide-io.c 2007-12-18 07:54:59.0 -0500
+++ linus-2.6/drivers/ide/ide-io.c 2008-01-24 14:48:29.0 -0500
@@ -1003,6 +1003,7 @@ static ide_startstop_t start_request (id
/* bail early if we've exceeded max_failures */
if (drive->max_failures && (drive->failures > drive->max_failures)) {
+ rq->cmd_flags |= REQ_FAILED;
goto kill_rq;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Palmchip BK3710 IDE driver
Anton Salnikov wrote:
This is Palmchip BK3710 IDE controller support for kernel version 2.6.24-rc8.
The IDE controller logic supports PIO, multiword DMA and ultra-DMA modes.
Supports interface to compact Flash (CF) configured in True-IDE mode.
Signed-off-by: Anton Salnikov <[EMAIL PROTECTED]>
---
Index: 2.6.24-rc8.ide/drivers/ide/arm/palm_bk3710.c
===
--- /dev/null
+++ 2.6.24-rc8.ide/drivers/ide/arm/palm_bk3710.c
@@ -0,0 +1,428 @@
+static inline u8 hwif_read8(u32 base, u32 reg)
+{
+ return readb(base + reg);
+}
+
+static inline void hwif_write8(u32 base, u8 val, u32 reg)
+{
+ writeb(val, base + reg);
+}
+
+static inline u16 hwif_read16(u32 base, u32 reg)
+{
+ return readw(base + reg);
+}
+
+static inline void hwif_write16(u32 base, u16 val, u32 reg)
+{
+ writew(val, base + reg);
+}
+
+static inline u32 hwif_read32(u32 base, u32 reg)
+{
+ return readl(base + reg);
+}
+
+static inline void hwif_write32(u32 base, u32 val, u32 reg)
+{
+ writel(val, base + reg);
+}
Hm, I don't see why you need those accessors but well...
+static void palm_bk3710_setudmamode(u32 base, unsigned int dev,
+ unsigned int mode)
+{
+ u8 tenv, trp, t0;
+ u32 val32;
+ u16 val16;
+
+ /* DMA Data Setup */
+ t0 = (palm_bk3710_udmatimings[mode].cycletime + ide_palm_clk - 1)
+ / ide_palm_clk - 1;
+ tenv = (20 + ide_palm_clk - 1) / ide_palm_clk - 1;
+ trp = (palm_bk3710_udmatimings[mode].rptime + ide_palm_clk - 1)
+ / ide_palm_clk - 1;
+
+ /* udmatim Register */
+ val16 = hwif_read16(base, BK3710_UDMATIM) & (dev ? 0xFF0F : 0xFFF0);
+ val16 |= (mode << ((!dev) ? 0 : 4));
Why not (dev ? 4 : 0) like the rest?
+ hwif_write16(base, val16, BK3710_UDMATIM);
+
+ /* udmastb Ultra DMA Access Strobe Width */
+ val32 = hwif_read32(base, BK3710_UDMASTB) & (0xFF << (dev ? 0 : 8));
+ val32 |= (t0 << (dev ? 8 : 0));
+ hwif_write32(base, val32, BK3710_UDMASTB);
+
+ /* udmatrp Ultra DMA Ready to Pause Time */
+ val32 = hwif_read32(base, BK3710_UDMATRP) & (0xFF << (dev ? 0 : 8));
+ val32 |= (trp << (dev ? 8 : 0));
+ hwif_write32(base, val32, BK3710_UDMATRP);
+
+ /* udmaenv Ultra DMA envelop Time */
+ val32 = hwif_read32(base, BK3710_UDMAENV) & (0xFF << (dev ? 0 : 8));
+ val32 |= (tenv << (dev ? 8 : 0));
+ hwif_write32(base, val32, BK3710_UDMAENV);
+
+ /* Enable UDMA for Device */
+ val16 = hwif_read16(base, BK3710_UDMACTL) | (1 << dev);
+ hwif_write16(base, val16, BK3710_UDMACTL);
+}
+
+static void palm_bk3710_setdmamode(u32 base, unsigned int dev,
+ unsigned short min_cycle,
+ unsigned int mode)
+{
+ u8 td, tkw, t0;
+ u32 val32;
+ u16 val16;
+
+ unsigned cycletime = max_t(int, ide_timing_find_mode(mode)->cycle,
+ min_cycle);
Hm, why integer comparison and then unsigned maximum?
+
+ /* DMA Data Setup */
+ t0 = (cycletime + ide_palm_clk - 1) / ide_palm_clk;
+ td = (ide_timing_find_mode(mode)->active + ide_palm_clk - 1)
+ / ide_palm_clk;
Couldn't you call ide_timing_find_mode() only once?
[...]
+static int __devinit palm_bk3710_probe(struct platform_device *pdev)
+{
+ hw_regs_t ide_ctlr_info;
+ int index = 0;
+ int pribase;
+ struct clk *clkp;
+ struct resource *mem, *irq;
+ ide_hwif_t *hwif;
+ u32 base;
+ int ret;
+
+ clkp = clk_get(NULL, "IDECLK");
+ if (IS_ERR(clkp))
+ return -ENODEV;
+
+ ideclkp = clkp;
+ clk_enable(ideclkp);
+ ide_palm_clk = clk_get_rate(ideclkp)/10;
+ ide_palm_clk = (1/ide_palm_clk) + 1;
+ /* Register the IDE interface with Linux ATA Interface */
+ memset(&ide_ctlr_info, 0, sizeof(ide_ctlr_info));
+
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (mem == NULL) {
+ printk(KERN_INFO "failed to get memory region resource\n");
This deserves KERN_ERR, not KERN_INFO.
+ return -ENODEV;
+ }
+ irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (irq == NULL) {
+ printk(KERN_INFO "failed to get IRQ resource\n");
This too...
+ return -ENODEV;
+ }
+
+ base = mem->start;
+
+ /* Configure the Palm Chip controller */
+ palm_bk3710_chipinit(base);
+
+ pribase = mem->start + IDE_PALM_ATA_PRI_REG_OFFSET;
+ for (index = 0; index < IDE_NR_PORTS - 2; index++)
+ ide_ctlr_info.io_ports[index] = pribase + index;
+ ide_ctlr_info.io_ports[IDE_CONTROL_OFFSET] = mem->start +
+ IDE_PALM_ATA_PRI_CTL_OFFSET;
+ ide_ctlr_info.irq =
Re: SATA timeouts on two disks
Hi, On Jan 21, 2008 8:47 AM, Tejun Heo <[EMAIL PROTECTED]> wrote: > If you still have the old PSU lying around, please try to power one of > the failing drive with the old PSU. Just leave everything else as-is, > power-up old PSU by itself as described in the following web page and > connect only one of the failing drive to the old PSU. > > http://modtown.co.uk/mt/article2.php?id=psumod > > And see whether the problem continues and if so on which drives. > Connecting SATA drives to separate power is completely safe even if they > don't have common ground because SATA connection never directly connect > to each other. Yes, I still have the old PSU lying around. A co-worker, to whom I explained my problem, asked me whether I had properly grounded my drives. In fact I had not: The drives resided in a vibration-absorbing frame through which their exterior had no electrical contact with the grounded case. Since I grounded the drives two days ago, I got no new errors. So maybe my problem is solved. If not, I will happily try out your suggestion. Would you be so kind to explain in a few words, what connecting one drive to a second (supposedly good) PSU will show? (Is this still on-topic on this list?) Thanks a lot, Jim - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sata_sil24 / Alpha / 4726 PMP issue ..
Thomas Evans wrote: > That's what I thought - is there another chip that support the 4726 > PMP that you think I could try? JMicron SATA controllers are ahci and support PMP. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sata_sil24 / Alpha / 4726 PMP issue ..
That's what I thought - is there another chip that support the 4726 PMP that you think I could try? ...tom On Jan 24, 2008 10:11 AM, Tejun Heo <[EMAIL PROTECTED]> wrote: > Thomas Evans wrote: > > I will work on getting that log - is there anything non-kernel that > > may have changed that could cause this? udev changes or something > > like that? Just so odd for it to start failing after having worked > > for so long. > > Nope, this is way before userland has any say in it. The same kernel > version which used to work doesn't work on two slightly different > machines. That's just weird. :-( > > -- > tejun > - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WARNING: at drivers/ata/libata-core.c:5988 ata_qc_issue()
Tejun Heo wrote:
Mark Lord wrote:
Tejun,
During testing with NCQ on sata_mv (patches coming shortly),
I found this gem in the syslog. This doesn't look like something
that a LLD could cause, but rather a race perhaps in libata-core.
Hmmm... This isn't supposed to happen.
System is a 2.4GHz 32-bit Core2Quad, 2GB RAM (during this test),
running 2.6.24-rc6-git12 + newer sata_mv, with two sata_mv controller
cards, each with one NCQ drive performing heavy R/W activity.
Other than that, I'm not sure what triggered this.
Can you please tell me which version you were using? Or tell me which
one of the three WARN_ON()'s in ata_qc_issue() was triggered? Thanks.
..
[ 289.892890] WARNING: at drivers/ata/libata-core.c:5988 ata_qc_issue()
..
The first one shown below, at drivers/ata/libata-core.c:5988:
void ata_qc_issue(struct ata_queued_cmd *qc)
{
struct ata_port *ap = qc->ap;
struct ata_link *link = qc->dev->link;
/* Make sure only one non-NCQ command is outstanding. The
* check is skipped for old EH because it reuses active qc to
* request ATAPI sense.
*/
= WARN_ON(ap->ops->error_handler && ata_tag_valid(link->active_tag));
if (qc->tf.protocol == ATA_PROT_NCQ) {
WARN_ON(link->sactive & (1 << qc->tag));
..
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WARNING: at drivers/ata/libata-core.c:5988 ata_qc_issue()
Mark Lord wrote:
> Tejun,
>
> During testing with NCQ on sata_mv (patches coming shortly),
> I found this gem in the syslog. This doesn't look like something
> that a LLD could cause, but rather a race perhaps in libata-core.
Hmmm... This isn't supposed to happen.
> System is a 2.4GHz 32-bit Core2Quad, 2GB RAM (during this test),
> running 2.6.24-rc6-git12 + newer sata_mv, with two sata_mv controller
> cards, each with one NCQ drive performing heavy R/W activity.
>
> Other than that, I'm not sure what triggered this.
Can you please tell me which version you were using? Or tell me which
one of the three WARN_ON()'s in ata_qc_issue() was triggered? Thanks.
> [ 265.473596] EXT3-fs: mounted filesystem with ordered data mode.
> [ 289.892890] WARNING: at drivers/ata/libata-core.c:5988 ata_qc_issue()
> [ 289.892898] Pid: 4661, comm: mirrordir Not tainted 2.6.24-rc6-git12 #7
> [ 289.892911] [ata_qc_issue+88/1512] ata_qc_issue+0x58/0x5e8
> [ 289.892922] [scsi_get_cmd_from_req+23/51]
> scsi_get_cmd_from_req+0x17/0x33
> [ 289.892934] [scsi_done+0/22] scsi_done+0x0/0x16
> [ 289.892939] [ata_scsi_translate+233/272] ata_scsi_translate+0xe9/0x110
> [ 289.892949] [scsi_done+0/22] scsi_done+0x0/0x16
> [ 289.892954] [ata_scsi_queuecmd+412/443] ata_scsi_queuecmd+0x19c/0x1bb
> [ 289.892960] [ata_scsi_rw_xlat+0/478] ata_scsi_rw_xlat+0x0/0x1de
> [ 289.892968] [scsi_dispatch_cmd+422/547] scsi_dispatch_cmd+0x1a6/0x223
> [ 289.892976] [scsi_request_fn+631/814] scsi_request_fn+0x277/0x32e
> [ 289.892982] [blk_remove_plug+79/91] blk_remove_plug+0x4f/0x5b
> [ 289.892991] [__generic_unplug_device+29/31]
> __generic_unplug_device+0x1d/0x1f
> [ 289.892998] [elv_insert+166/326] elv_insert+0xa6/0x146
> [ 289.893006] [__make_request+993/1109] __make_request+0x3e1/0x455
> [ 289.893012] [swsusp_show_speed+15/237] swsusp_show_speed+0xf/0xed
> [ 289.893021] [generic_make_request+425/471]
> generic_make_request+0x1a9/0x1d7
> [ 289.893028] [bio_add_page+49/55] bio_add_page+0x31/0x37
> [ 289.893036] [do_mpage_readpage+947/1108] do_mpage_readpage+0x3b3/0x454
> [ 289.893044] [submit_bio+237/244] submit_bio+0xed/0xf4
> [ 289.893053] [add_to_page_cache+111/140] add_to_page_cache+0x6f/0x8c
> [ 289.893061] [mpage_end_io_read+0/83] mpage_end_io_read+0x0/0x53
> [ 289.893066] [mpage_bio_submit+25/29] mpage_bio_submit+0x19/0x1d
> [ 289.893073] [mpage_readpages+177/188] mpage_readpages+0xb1/0xbc
> [ 289.893080] [] ext2_get_block+0x0/0x5d8 [ext2]
> [ 289.893097] [] ext2_readpages+0x0/0x15 [ext2]
> [ 289.893109] [__do_page_cache_readahead+319/446]
> __do_page_cache_readahead+0x13f/0x1be
> [ 289.893115] [] ext2_get_block+0x0/0x5d8 [ext2]
> [ 289.893128] [page_cache_sync_readahead+42/47]
> page_cache_sync_readahead+0x2a/0x2f
> [ 289.893136] [do_generic_mapping_read+221/936]
> do_generic_mapping_read+0xdd/0x3a8
> [ 289.893143] [file_read_actor+0/204] file_read_actor+0x0/0xcc
> [ 289.893153] [generic_file_aio_read+353/412]
> generic_file_aio_read+0x161/0x19c
> [ 289.893160] [file_read_actor+0/204] file_read_actor+0x0/0xcc
> [ 289.893170] [do_sync_read+199/266] do_sync_read+0xc7/0x10a
> [ 289.893181] [autoremove_wake_function+0/53]
> autoremove_wake_function+0x0/0x35
> [ 289.893195] [do_sync_read+0/266] do_sync_read+0x0/0x10a
> [ 289.893201] [vfs_read+136/266] vfs_read+0x88/0x10a
> [ 289.893207] [sys_read+65/103] sys_read+0x41/0x67
> [ 289.893214] [sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85
> [ 289.893226] ===
> [ 319.846321] ata5.00: exception Emask 0x0 SAct 0x2 SErr 0x0 action 0x2
> frozen
> [ 319.846435] ata5.00: cmd 60/08:08:6f:20:0b/00:00:00:00:00/40 tag 1
> ncq 4096 in
> [ 319.846437] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
> 0x4 (timeout)
> [ 319.846542] ata5.00: status: { DRDY }
> [ 319.846615] ata5: hard resetting link
> [ 319.876280] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [ 320.029413] ata5.00: configured for UDMA/133
> [ 320.029422] ata5: EH complete
>
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: at drivers/ata/libata-core.c:5988 ata_qc_issue()
Tejun,
During testing with NCQ on sata_mv (patches coming shortly),
I found this gem in the syslog. This doesn't look like something
that a LLD could cause, but rather a race perhaps in libata-core.
System is a 2.4GHz 32-bit Core2Quad, 2GB RAM (during this test),
running 2.6.24-rc6-git12 + newer sata_mv, with two sata_mv controller
cards, each with one NCQ drive performing heavy R/W activity.
Other than that, I'm not sure what triggered this.
[ 265.473596] EXT3-fs: mounted filesystem with ordered data mode.
[ 289.892890] WARNING: at drivers/ata/libata-core.c:5988 ata_qc_issue()
[ 289.892898] Pid: 4661, comm: mirrordir Not tainted 2.6.24-rc6-git12 #7
[ 289.892911] [ata_qc_issue+88/1512] ata_qc_issue+0x58/0x5e8
[ 289.892922] [scsi_get_cmd_from_req+23/51] scsi_get_cmd_from_req+0x17/0x33
[ 289.892934] [scsi_done+0/22] scsi_done+0x0/0x16
[ 289.892939] [ata_scsi_translate+233/272] ata_scsi_translate+0xe9/0x110
[ 289.892949] [scsi_done+0/22] scsi_done+0x0/0x16
[ 289.892954] [ata_scsi_queuecmd+412/443] ata_scsi_queuecmd+0x19c/0x1bb
[ 289.892960] [ata_scsi_rw_xlat+0/478] ata_scsi_rw_xlat+0x0/0x1de
[ 289.892968] [scsi_dispatch_cmd+422/547] scsi_dispatch_cmd+0x1a6/0x223
[ 289.892976] [scsi_request_fn+631/814] scsi_request_fn+0x277/0x32e
[ 289.892982] [blk_remove_plug+79/91] blk_remove_plug+0x4f/0x5b
[ 289.892991] [__generic_unplug_device+29/31]
__generic_unplug_device+0x1d/0x1f
[ 289.892998] [elv_insert+166/326] elv_insert+0xa6/0x146
[ 289.893006] [__make_request+993/1109] __make_request+0x3e1/0x455
[ 289.893012] [swsusp_show_speed+15/237] swsusp_show_speed+0xf/0xed
[ 289.893021] [generic_make_request+425/471] generic_make_request+0x1a9/0x1d7
[ 289.893028] [bio_add_page+49/55] bio_add_page+0x31/0x37
[ 289.893036] [do_mpage_readpage+947/1108] do_mpage_readpage+0x3b3/0x454
[ 289.893044] [submit_bio+237/244] submit_bio+0xed/0xf4
[ 289.893053] [add_to_page_cache+111/140] add_to_page_cache+0x6f/0x8c
[ 289.893061] [mpage_end_io_read+0/83] mpage_end_io_read+0x0/0x53
[ 289.893066] [mpage_bio_submit+25/29] mpage_bio_submit+0x19/0x1d
[ 289.893073] [mpage_readpages+177/188] mpage_readpages+0xb1/0xbc
[ 289.893080] [] ext2_get_block+0x0/0x5d8 [ext2]
[ 289.893097] [] ext2_readpages+0x0/0x15 [ext2]
[ 289.893109] [__do_page_cache_readahead+319/446]
__do_page_cache_readahead+0x13f/0x1be
[ 289.893115] [] ext2_get_block+0x0/0x5d8 [ext2]
[ 289.893128] [page_cache_sync_readahead+42/47]
page_cache_sync_readahead+0x2a/0x2f
[ 289.893136] [do_generic_mapping_read+221/936]
do_generic_mapping_read+0xdd/0x3a8
[ 289.893143] [file_read_actor+0/204] file_read_actor+0x0/0xcc
[ 289.893153] [generic_file_aio_read+353/412]
generic_file_aio_read+0x161/0x19c
[ 289.893160] [file_read_actor+0/204] file_read_actor+0x0/0xcc
[ 289.893170] [do_sync_read+199/266] do_sync_read+0xc7/0x10a
[ 289.893181] [autoremove_wake_function+0/53]
autoremove_wake_function+0x0/0x35
[ 289.893195] [do_sync_read+0/266] do_sync_read+0x0/0x10a
[ 289.893201] [vfs_read+136/266] vfs_read+0x88/0x10a
[ 289.893207] [sys_read+65/103] sys_read+0x41/0x67
[ 289.893214] [sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85
[ 289.893226] ===
[ 319.846321] ata5.00: exception Emask 0x0 SAct 0x2 SErr 0x0 action 0x2 frozen
[ 319.846435] ata5.00: cmd 60/08:08:6f:20:0b/00:00:00:00:00/40 tag 1 ncq 4096
in
[ 319.846437] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4
(timeout)
[ 319.846542] ata5.00: status: { DRDY }
[ 319.846615] ata5: hard resetting link
[ 319.876280] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 320.029413] ata5.00: configured for UDMA/133
[ 320.029422] ata5: EH complete
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sata_sil24 / Alpha / 4726 PMP issue ..
Thomas Evans wrote: > I will work on getting that log - is there anything non-kernel that > may have changed that could cause this? udev changes or something > like that? Just so odd for it to start failing after having worked > for so long. Nope, this is way before userland has any say in it. The same kernel version which used to work doesn't work on two slightly different machines. That's just weird. :-( -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sata_sil24 / Alpha / 4726 PMP issue ..
I will work on getting that log - is there anything non-kernel that may have changed that could cause this? udev changes or something like that? Just so odd for it to start failing after having worked for so long. ...tom On Jan 23, 2008 10:52 PM, Tejun Heo <[EMAIL PROTECTED]> wrote: > Thomas Evans wrote: > > Um, I can, but it's not all that different than the others - is there > > something I am missing that would collect more info in the logs? > > Well, at times, small differences can tell us more information. The > best we can do here is to gather as much information as possible. Even > if we fail to solve the issue now, it may come handy later when similar > instances happen and more clues are gathered. > > -- > tejun > - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Palmchip BK3710 IDE driver
This is Palmchip BK3710 IDE controller support for kernel version 2.6.24-rc8.
The IDE controller logic supports PIO, multiword DMA and ultra-DMA modes.
Supports interface to compact Flash (CF) configured in True-IDE mode.
Signed-off-by: Anton Salnikov <[EMAIL PROTECTED]>
---
drivers/ide/Kconfig |8
drivers/ide/arm/Makefile |1
drivers/ide/arm/palm_bk3710.c | 428 ++
drivers/ide/ide-proc.c|1
include/linux/ide.h |2
5 files changed, 439 insertions(+), 1 deletion(-)
Index: 2.6.24-rc8.ide/drivers/ide/Kconfig
===
--- 2.6.24-rc8.ide.orig/drivers/ide/Kconfig
+++ 2.6.24-rc8.ide/drivers/ide/Kconfig
@@ -1008,6 +1008,14 @@ config BLK_DEV_Q40IDE
normally be on; disable it only if you are running a custom hard
drive subsystem through an expansion card.
+config BLK_DEV_PALMCHIP_BK3710
+ bool "Palmchip bk3710 IDE controller support"
+ depends on ARCH_DAVINCI
+ select BLK_DEV_IDEDMA_PCI
+ help
+ Say Y here if you want to support the onchip IDE controller on the
+ TI DaVinci SoC
+
config BLK_DEV_MPC8xx_IDE
bool "MPC8xx IDE support"
depends on 8xx && (LWMON || IVMS8 || IVML24 || TQM8xxL) && IDE=y &&
BLK_DEV_IDE=y && !PPC_MERGE
Index: 2.6.24-rc8.ide/drivers/ide/arm/Makefile
===
--- 2.6.24-rc8.ide.orig/drivers/ide/arm/Makefile
+++ 2.6.24-rc8.ide/drivers/ide/arm/Makefile
@@ -2,5 +2,6 @@
obj-$(CONFIG_BLK_DEV_IDE_ICSIDE) += icside.o
obj-$(CONFIG_BLK_DEV_IDE_RAPIDE) += rapide.o
obj-$(CONFIG_BLK_DEV_IDE_BAST) += bast-ide.o
+obj-$(CONFIG_BLK_DEV_PALMCHIP_BK3710) += palm_bk3710.o
EXTRA_CFLAGS := -Idrivers/ide
Index: 2.6.24-rc8.ide/drivers/ide/arm/palm_bk3710.c
===
--- /dev/null
+++ 2.6.24-rc8.ide/drivers/ide/arm/palm_bk3710.c
@@ -0,0 +1,428 @@
+/*
+ * Palmchip bk3710 IDE controller
+ *
+ * Copyright (C) 2006 Texas Instruments.
+ * Copyright (C) 2007 MontaVista Software, Inc., <[EMAIL PROTECTED]>
+ *
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Offset of the primary interface registers */
+#define IDE_PALM_ATA_PRI_REG_OFFSET 0x1F0
+
+/* Primary Control Offset */
+#define IDE_PALM_ATA_PRI_CTL_OFFSET 0x3F6
+
+/*
+ * PalmChip 3710 IDE Controller UDMA timing structure Definition
+ */
+struct palm_bk3710_udmatiming {
+ unsigned int rptime;/* Ready to pause time */
+ unsigned int cycletime; /* Cycle Time */
+};
+
+#define BK3710_BMICP 0x00
+#define BK3710_BMISP 0x02
+#define BK3710_BMIDTP 0x04
+#define BK3710_BMICS 0x08
+#define BK3710_BMISS 0x0A
+#define BK3710_BMIDTS 0x0C
+#define BK3710_IDETIMP 0x40
+#define BK3710_IDETIMS 0x42
+#define BK3710_SIDETIM 0x44
+#define BK3710_SLEWCTL 0x45
+#define BK3710_IDESTATUS 0x47
+#define BK3710_UDMACTL 0x48
+#define BK3710_UDMATIM 0x4A
+#define BK3710_MISCCTL 0x50
+#define BK3710_REGSTB 0x54
+#define BK3710_REGRCVR 0x58
+#define BK3710_DATSTB 0x5C
+#define BK3710_DATRCVR 0x60
+#define BK3710_DMASTB 0x64
+#define BK3710_DMARCVR 0x68
+#define BK3710_UDMASTB 0x6C
+#define BK3710_UDMATRP 0x70
+#define BK3710_UDMAENV 0x74
+#define BK3710_IORDYTMP0x78
+#define BK3710_IORDYTMS0x7C
+
+#include "../ide-timing.h"
+
+static long ide_palm_clk;
+
+static const struct palm_bk3710_udmatiming palm_bk3710_udmatimings[6] = {
+ {160, 240}, /* UDMA Mode 0 */
+ {125, 160}, /* UDMA Mode 1 */
+ {100, 120}, /* UDMA Mode 2 */
+ {100, 90}, /* UDMA Mode 3 */
+ {85, 60}, /* UDMA Mode 4 */
+};
+
+static struct clk *ideclkp;
+
+static inline u8 hwif_read8
excess timeouts accessing pci-sata card both ports
Hello. The scenario: PCI bus with 2 cards (sata_via) Each card has 2 SATA ports connected. Each disk does 40MB/s in hdparm -t read test. First card has the sda and sdb Second card has the sdc and sdd verified by watching the led blinking on the card ok - accessing two ports at same time but each port on different card: cat /dev/sda > /dev/null & cat /dev/sdc > /dev/null problem - accessing two ports at same time and both ports on same card: cat /dev/sda > /dev/null & cat /dev/sdb > /dev/null side effect of the problem: due to heavy traffic on one port the reset of the other port fails with timeout and port is disabled logged error command at the initial problem (is it DMA read ext and DMA write log?): ata2.00: exception Emask 0x2 SAct 0x0 SErr 0x3000400 action 0x2 frozen ata2.00: cmd 25/00:68:b8:83:13/00:01:00:00:00/e0 tag 0 cdb 0x0 data 184320 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x6 (timeout) ata2: port is slow to respond, please be patient (Status 0xd0) ata2.00: exception Emask 0x2 SAct 0x0 SErr 0x3000400 action 0x2 frozen ata2.00: cmd c8/00:60:70:50:08/00:00:00:00:00/e0 tag 0 cdb 0x0 data 49152 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x6 (timeout) ata2: port is slow to respond, please be patient (Status 0xd0) logged EH sequence failure: ata2: port is slow to respond, please be patient (Status 0xd0) ata2: device not ready (errno=-16), forcing hardreset ata2: hard resetting port ata2: port is slow to respond, please be patient (Status 0x80) ata2: COMRESET failed (errno=-16) ata2: hard resetting port ata2: port is slow to respond, please be patient (Status 0x80) ata2: COMRESET failed (errno=-16) ata2: hard resetting port ata2: port is slow to respond, please be patient (Status 0x80) ata2: COMRESET failed (errno=-16) ata2: hard resetting port ata2: COMRESET failed (errno=-16) ata2: reset failed, giving up ata2.00: disabled ata2: EH complete sd 1:0:0:0: [sdb] Result: hostbyte=0x04 driverbyte=0x00 tried does not work: - multiply the ATA_TMOUT values by 10 and later by 100 against vanilla - increase retry counters some lines from dmesg below libata version 2.21 loaded. sata_via :00:0d.0: version 2.3 ACPI: PCI Interrupt :00:0d.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11 sata_via :00:0d.0: routed to hard irq line 11 scsi0 : sata_via scsi1 : sata_via scsi2 : sata_via ata1: SATA max UDMA/133 cmd 0x0001b800 ctl 0x0001b80a bmdma 0x0001a400 irq 11 ata2: SATA max UDMA/133 cmd 0x0001b400 ctl 0x0001b40a bmdma 0x0001a408 irq 11 ata3: PATA max UDMA/133 cmd 0x0001b000 ctl 0x0001b00a bmdma 0x0001a410 irq 11 ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) ata1.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133 ata1.00: 490234752 sectors, multi 16: LBA48 NCQ (not used) ata1.00: configured for UDMA/133 ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310) ata2.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133 ata2.00: 490234752 sectors, multi 16: LBA48 NCQ (not used) ata2.00: configured for UDMA/133 scsi 0:0:0:0: Direct-Access ATA Maxtor 6L250S0 BANC PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 490234752 512-byte hardware sectors (251000 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 490234752 512-byte hardware sectors (251000 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sd 0:0:0:0: [sda] Attached SCSI disk sd 0:0:0:0: Attached scsi generic sg0 type 0 scsi 1:0:0:0: Direct-Access ATA Maxtor 6L250S0 BANC PQ: 0 ANSI: 5 sd 1:0:0:0: [sdb] 490234752 512-byte hardware sectors (251000 MB) sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 1:0:0:0: [sdb] 490234752 512-byte hardware sectors (251000 MB) sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb: sdb1 sdb2 sdb3 sd 1:0:0:0: [sdb] Attached SCSI disk sd 1:0:0:0: Attached scsi generic sg1 type 0 ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10 PCI: setting IRQ 10 as level-triggered ACPI: PCI Interrupt :00:0e.0[A] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10 sata_via :00:0e.0: routed to hard irq line 10 scsi3 : sata_via scsi4 : sata_via scsi5 : sata_via ata4: SATA max UDMA/133 cmd 0x00019800 ctl 0x0001980a bmdma 0x00018400 irq 10 ata5: SATA max UDMA/133 cmd 0x00019400 ctl 0x0001940a bmdma 0x00018408 irq 10 ata6: PATA max UDMA/133 cmd 0x00019000 ctl 0x0001900a bmdma 0x00018410 irq 10 ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310) ata4.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133 ata4.00: 490234752 sectors, multi 16: LBA48 NCQ (not used) ata
