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/
next prev 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.