From: Robert Hancock <hancockr@shaw.ca>
To: Jeff Garzik <jeff@garzik.org>
Cc: Kuan Luo <kluo@nvidia.com>, Tejun Heo <htejun@gmail.com>,
Mark Lord <liml@rtr.ca>,
IDE/ATA development list <linux-ide@vger.kernel.org>,
Allen Martin <AMartin@nvidia.com>, Peer Chen <pchen@nvidia.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
David Milburn <dmilburn@redhat.com>
Subject: Re: sata_nv and 2.6.24 (was Re: fixed a bug of adma in rhel4u5 with HDS7250SASUN500G.)
Date: Wed, 23 Jan 2008 08:44:39 -0600 [thread overview]
Message-ID: <479752D7.4020206@shaw.ca> (raw)
In-Reply-To: <479709BE.2090707@garzik.org>
Jeff Garzik wrote:
> Ping... sata_nv status is still a bit open for 2.6.24, and I would like
> to move us forward a bit.
>
> * Kuan's patch... it has been confirmed (and is needed), correct? can
> someone work up a good patch for 2.6.24? The only one I ever received
> was badly word-wrapped, and at the time, Robert seemed uncertain of it,
> so I waited.
I can get you one later today hopefully.
>
> * ADMA ATAPI 4GB issues... playing tricks with the ordering of
> allocations and DMA masks is just way too fragile. We just cannot
> guarantee that all allocators work that way. The obvious solution to me
> seems to be hardcoding the consistent DMA mask to 32-bit, but using
> 64-bit for regular dma mask if-and-only-if ADMA is enabled.
That's not enough to fix the problem since there's issues with actual
transfer data being allocated above 4GB as well, not just the consistent
allocations (it appears that blk_queue_bounce_limit setting to 32-bit
doesn't prevent this on x86_64). Either we play some funky games with
changing the DMA mask of the entire device to 32-bit if either port is
in ATAPI mode (which blew up when I tried it) or we add the ability to
set the DMA mask independently on each port (like by setting the mask on
the SCSI device and using that for DMA mapping instead) which requires
core changes.
>
> * it sure seems like there are other open sata_nv ADMA issues -- can we
> hard-confirm or deny this? bugzilla wasn't very helpful for me. It
> doesn't seem like we can disable ADMA (to solve those issues) and get
> enough test time in (which is what I said a week (or more?) ago too...)
The NCQ/non-NCQ command switching issue is still hitting some people
(last I heard Kuan was looking into this), also there's a hotplug issue
that Tejun reported..
>
> It seems like we should be able to tackle the first two issues promptly,
> at least.
>
> Jeff
>
>
>
>
next prev parent reply other threads:[~2008-01-23 14:45 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-07 9:25 disabling sata_nv ADMA for 2.6.24 Tejun Heo
2008-01-07 15:15 ` Mark Lord
2008-01-07 15:35 ` [PATCH #upstream-fixes] sata_nv: disable ADMA mode by default Tejun Heo
2008-01-10 5:58 ` Jeff Garzik
2008-01-10 6:29 ` Tejun Heo
2008-01-07 23:35 ` disabling sata_nv ADMA for 2.6.24 Robert Hancock
2008-01-07 23:56 ` Tejun Heo
2008-01-08 0:12 ` Robert Hancock
2008-01-08 1:01 ` Tejun Heo
2008-01-08 1:16 ` Tejun Heo
2008-01-08 2:29 ` Robert Hancock
2008-01-08 2:53 ` Tejun Heo
2008-01-08 2:55 ` Tejun Heo
2008-01-08 3:01 ` Robert Hancock
2008-01-08 3:08 ` Tejun Heo
2008-01-08 9:58 ` Tejun Heo
2008-01-08 14:40 ` Robert Hancock
2008-01-09 1:58 ` Tejun Heo
2008-01-09 2:00 ` Tejun Heo
2008-01-09 3:50 ` Robert Hancock
2008-01-09 5:09 ` Tejun Heo
2008-01-10 0:33 ` Robert Hancock
2008-01-10 6:59 ` Tejun Heo
2008-01-11 7:54 ` fixed a bug of adma in rhel4u5 with HDS7250SASUN500G Kuan Luo
2008-01-11 14:29 ` Robert Hancock
2008-01-11 21:57 ` David Milburn
2008-01-12 1:07 ` Robert Hancock
2008-01-14 3:08 ` Kuan Luo
2008-01-14 5:20 ` Robert Hancock
2008-01-14 6:23 ` Kuan Luo
2008-01-23 9:32 ` sata_nv and 2.6.24 (was Re: fixed a bug of adma in rhel4u5 with HDS7250SASUN500G.) Jeff Garzik
2008-01-23 14:44 ` Robert Hancock [this message]
2008-01-24 1:42 ` Jeff Garzik
2008-01-24 1:53 ` Robert Hancock
2008-01-24 0:43 ` fixed a bug of adma in rhel4u5 with HDS7250SASUN500G Robert Hancock
2008-01-24 3:20 ` Kuan Luo
2008-01-28 23:50 ` Robert Hancock
2008-01-29 2:48 ` Kuan Luo
2008-01-29 4:59 ` Kuan Luo
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=479752D7.4020206@shaw.ca \
--to=hancockr@shaw.ca \
--cc=AMartin@nvidia.com \
--cc=dmilburn@redhat.com \
--cc=htejun@gmail.com \
--cc=jeff@garzik.org \
--cc=kluo@nvidia.com \
--cc=liml@rtr.ca \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pchen@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).