On Wed, Apr 22, 2015 at 05:23:28PM +0200, Luis R. Rodriguez wrote:

On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote:

quoted

On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote:

quoted

quoted

Mike, do you think the time is right to just remove the iPath driver?

With PAT now being default the driver effectively won't work
with write-combining on modern kernels. Even if systems are old
they likely had PAT support, when upgrading kernels PAT will work
but write-combing won't on ipath.

Sorry, do you mean the driver already doesn't get WC? Or do you mean
after some more pending patches are applied?

No, you have to consider the system used and the effects of calls used
on the driver in light of this table:

So, just to be clear:

At some point Linux started setting the PAT bits during
ioremap_nocache, which overrides MTRR, and at that point the driver
became broken on all PAT capable systems?

Not only that, but we've only just noticed it now, and no user ever
complained?

So that means either no users exist, or all users are on non-PAT
systems?

This driver only works on x86-64 systems. Are there any x86-64 systems
that are not PAT capable? IIRC even the first Opteron had PAT, but my
memory is fuzzy from back then :|

Another option in order to enable this type of checks at run time
and still be able to build the driver on standard distributions and
just prevent if from loading on PAT systems is to have some code in
place which would prevent the driver from loading if PAT was
enabled, this would enable folks to disable PAT via a kernel command
line option, and if that was used then the driver probe would
complete.

This seems like a reasonble option to me. At the very least we might
learn if anyone is still using these cards.

I'd also love to remove the driver if it turns out there are actually
no users. qib substantially replaces it except for a few very old
cards.

Mike?

Jason