Date:	Tue, 27 Mar 2007 13:48:45 +1000
From:	Michael Ellerman <michael@...erman.id.au>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	David Miller <davem@...emloft.net>, bunk@...sta.de, gregkh@...e.de,
	linux-kernel@...r.kernel.org, linux-pci@...ey.karlin.mff.cuni.cz
Subject: Re: [RFC: 2.6.21 patch] let PCI_MSI depend on EXPERIMENTAL

On Mon, 2007-03-26 at 21:13 -0600, Eric W. Biederman wrote:
> David Miller <davem@...emloft.net> writes:
> 
> > From: Adrian Bunk <bunk@...sta.de>
> > Date: Tue, 27 Mar 2007 03:02:47 +0200
> >
> >> We had during the last months have quite a few MSI bugs and even 
> >> regressions due to:
> >> - core kernel bugs,
> >> - device driver bugs and
> >> - hardware bugs
>    - architecture bugs
>    - MSI enabled on hardware that does not support it.
> 
> aka.  Drivers have started supporting MSI, People have started using
> and testing MSI, and there has been MSI maintenance.  People care.
> 
> The most recent regressions involving MSI have been fixes propagating
> their way through the kernel, and I can't think of a one of them
> that was MSI specific.  Just that the bug didn't happen to show
> up clearly without MSI enabled.
> 
> Finding that pci_save_state/pci_restore_state had serious resources
> leaks was nasty.
> 
> Finding that pci_enable_device isn't suspend/resume safe as
> implemented on x86 and ia64 is very nasty.  Currently on x86 it is
> only really safe to call pci_enable_device exactly once.  But the bugs
> are small enough we don't generally notice.
> 
> Personally I prefer glaring outstanding bugs to little subtle once
> that only bite you on the second Tuesday of the month.
> 
> The recent MSI maintenance has shifted the code around enough that
> problems became visible.  I'm not happy with this but I don't expect
> this to be an on-going state of affairs.
> 
> >> OTOH, MSI doesn't bring any real advantages for most users.
> 
> So default it to off, although I suspect we are approaching the
> point where it would actually be safe to default it to on.  We
> need a kernel release that doesn't have msi issues yet.
> 
> >> Let's therefore mark PCI_MSI as EXPERIMENTAL.
> >> 
> >> Signed-off-by: Adrian Bunk <bunk@...sta.de>
> >
> > This is a good way to ensure that the code doesn't get tested
> > enough to ever fix the problems.
> 
> Dave I agreed.  PCI_MSI is not the problem.
> 
> I think marking PCI_MSI as EXPERIMENTAL now would be closing the
> barn door after the horses have fled.  I don't know of a core MSI
> code path that hasn't been scrutinized lately.  I wouldn't say they
> are perfect but they are junk either.  Especially given that the
> code is not good enough where non x86 architectures can support
> MSI.
> 
> There is one big remaining real world problem and that is we enable
> MSI optimistically.  Resulting in it being enabled on chipsets that
> don't support MSI.  We still need to change that behavior.  I have
> been buried in the guts of things so I haven't had the free cycles to
> worry about that yet, nor have there been enough people complaining
> that it has crossed my pain threshold to just fix the thing.
> 
> I think where we are honestly at is that today MSI works on most new
> chipsets.   MSI is supported by the hardware.  MSI is supported by the
> OS.  With a little more maturity devices and device drivers will start
> taking advantage of in ways that matter to users now that it works.

.. and we will start to see more and more hardware that _only_ uses MSI.
So we need to get it fixed, rather than sweeping the bugs under the
carpet 'til later.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)

Powered by blists - more mailing lists