[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080408201723.GD28148@elte.hu>
Date: Tue, 8 Apr 2008 22:17:23 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Matthew Wilcox <matthew@....cx>
Cc: "Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
"Kok, Auke-jan H" <auke-jan.h.kok@...el.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
NetDev <netdev@...r.kernel.org>,
e1000-list <e1000-devel@...ts.sourceforge.net>,
linux-pci maillist <linux-pci@...ey.karlin.mff.cuni.cz>,
Jeff Garzik <jeff@...zik.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"David S. Miller" <davem@...emloft.net>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"Ronciak, John" <john.ronciak@...el.com>,
"Allan, Bruce W" <bruce.w.allan@...el.com>,
Greg KH <greg@...ah.com>,
Arjan van de Ven <arjan@...ux.intel.com>,
"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: [regression] e1000e broke e1000 (was: Re: [ANNOUNCE] e1000
toe1000e migration of PCI Express devices)
* Matthew Wilcox <matthew@....cx> wrote:
> On Tue, Apr 08, 2008 at 09:59:49PM +0200, Ingo Molnar wrote:
> > Btw., a sidenote: this is another generally annoying property of Linux:
> > there's no easy and user-visible enumeration of PCI IDs (devices) that
> > we _could_ support but dont enable for some reason. It is a royal PITA
> > to track down when some driver decides to (silently) ignore a piece of
> > hardware.
> >
> > Having a seemingly dead piece of hardware component is one of the most
> > frustrating user experiences possible - the first instinctive reaction
> > is "did my hw break???". The kernel should proactively know about all
> > inactive pieces of hardware and should have a one-stop-shop for users
> > where they can reassure themselves which devices are not active and why.
>
> It's almost trivial to add new string attributes to sysfs. We could
> have a file, say, /sys/bus/pci/devices/0000:07:03.0/broken which lspci
> could read to see if anything's left a message for us.
>
> Is that the kind of thing you had in mind?
yep, that would be fantastic.
i guess more could be done as well - this was just the result of 10
seconds of thinking - please try to think all such scenarios through
with the mindset of the user who is faced with a non-working device. Our
failure diagnostics are rather ad-hoc in general. Say an USB stick did
not come up. Or some card isnt working. Or the mouse is dead. Plain
everyday annoyances - we need good, unified, understandable interfaces
for users to get reassurances and vectors of action from. Maybe even a
WARN_ON() for kerneloops.org to pick up automatically. _Anything_ that
is actionable by plain users. Because failures in hw functionality is
one of the most serious failure an OS can impose on users (it's only
slightly better than say data loss, and clearly worse to most users than
say sporadic crashes), and it is the main area where we _lose_ users
every day.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists