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
+ 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
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
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
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
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
17 matches
Mail list logo
