All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Hancock <hancockr@shaw.ca>
To: Mark Lord <liml@rtr.ca>
Cc: "Morrison, Tom" <tmorrison@empirix.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	ide <linux-ide@vger.kernel.org>, Jeff Garzik <jeff@garzik.org>,
	Tejun Heo <htejun@gmail.com>
Subject: Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)
Date: Fri, 23 Nov 2007 18:13:45 -0600	[thread overview]
Message-ID: <47476CB9.2040409@shaw.ca> (raw)
In-Reply-To: <474711FE.8040805@rtr.ca>

Mark Lord wrote:
> Morrison, Tom wrote:
>> I am hopeful that the sata_mv has this bug (I proved that the
>> problem I was experiencing was due to the sata_mv driver with 3.75Gig 
>> or more of memory)...
>>  
>> I am on vacation for a week or more ...or I'd tell you today
>> if it did have this bug!
> ..
> 
> Yeah, I kind of had your reports in mind when I asked that.  :)
> 
> On a related note, I now have lots of Marvell (sata_mv) hardware here,
> and an Intel CPU/chipset box with physical RAM above the 4GB boundary.

Based on a quick look at sata_mv it appears it sets a 64-bit DMA mask 
unconditionally, but for non-ATA_PROT_DMA commands (which includes all 
ATAPI), it just falls back to ata_qc_issue_prot which issues via the 
legacy SFF interface and can only handle 32-bit addressing. So yes, it 
appears to have a similar bug as sata_nv had.

Likely it needs a similar slave_config trick to change bounce limit 
depending on the connected device, unless there is really a way to issue 
ATAPI commands with this EDMA interface, as the TODO list in sata_mv.c 
suggests may be possible..

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/


  parent reply	other threads:[~2007-11-24  0:13 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-23  2:04 [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3) Robert Hancock
2007-11-23 15:22 ` Mark Lord
2007-11-23 17:30   ` Morrison, Tom
2007-11-23 17:46     ` Mark Lord
2007-11-23 18:47       ` Morrison, Tom
2007-11-23 20:40         ` Mark Lord
2007-11-24  0:13       ` Robert Hancock [this message]
2007-11-24  0:20         ` Jeff Garzik
2007-11-24  0:31           ` Robert Hancock
2007-11-24  2:48           ` Mark Lord
2007-11-24  5:12 ` Tejun Heo
2007-12-04 22:17 ` Jeff Garzik
2007-12-05  1:09   ` Robert Hancock
2007-12-28 21:37     ` Robert Hancock
2007-12-08 18:36   ` Robert Hancock
2007-12-17 11:44 ` shyam_iyer
2007-12-17 16:17   ` shyam_iyer
2007-12-18  2:50     ` Tejun Heo
2007-12-18  3:52     ` Tejun Heo
2007-12-18 10:22       ` Shyam_Iyer
2007-12-18 12:12         ` Shyam_Iyer
2007-12-20 11:15           ` shyam_iyer
2007-12-17 11:47 ` shyam_iyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47476CB9.2040409@shaw.ca \
    --to=hancockr@shaw.ca \
    --cc=htejun@gmail.com \
    --cc=jeff@garzik.org \
    --cc=liml@rtr.ca \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tmorrison@empirix.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.