lkml.org 
[lkml]   [2007]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC: 2.6.21 patch] let PCI_MSI depend on EXPERIMENTAL
    From
    Date
    On Mon, 2007-03-26 at 21:13 -0600, Eric W. Biederman wrote:
    > David Miller <davem@davemloft.net> writes:
    >
    > > From: Adrian Bunk <bunk@stusta.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@stusta.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
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2007-03-27 05:51    [W:2.802 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site