On Mon, 2007-03-26 at 21:13 -0600, Eric W. Biederman wrote: > David Miller <[EMAIL PROTECTED]> writes: > > > From: Adrian Bunk <[EMAIL PROTECTED]> > > 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 <[EMAIL PROTECTED]> > > > > 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
signature.asc
Description: This is a digitally signed message part
