On Thu, 2008-01-24 at 23:29 -0500, 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.
James Bottomley wrote:
On Thu, 2008-01-24 at 23:29 -0500, 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
On Fri, 2008-01-25 at 10:18 -0500, Mark Lord wrote:
James Bottomley wrote:
On Thu, 2008-01-24 at 23:29 -0500, 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
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
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
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.
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
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.
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
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
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
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,
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
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
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
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
16 matches
Mail list logo
