showing which hardware is unclaimed

[Rick Jones]

Matthew Wilcox 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?

FWIW, this is what a command on "another OS" does with an unclaimed card:

# ioscan -fk -C lan
Class     I  H/W Path  Driver  S/W State   H/W Type     Description
====================================================================
lan       0  0/0/3/0   intl100   CLAIMED     INTERFACE    Intel PCI Pro 
10/100Tx Server Adapter
lan       1  0/1/2/0   igelan    CLAIMED     INTERFACE    HP PCI 
1000Base-T Core
lan       2  0/2/1/0   iether    CLAIMED     INTERFACE    HP A7012-60001 
PCI/PCI-X 1000Base-T Dual-port Adapter
lan       3  0/2/1/1   iether    CLAIMED     INTERFACE    HP A7012-60001 
PCI/PCI-X 1000Base-T Dual-port Adapter
lan       4  0/3/1/0   ixgbe     UNCLAIMED   UNKNOWN      PCI-X Ethernet 
(17d55831)

I'd probably call that "unclaimed" rather than "broken" but that may 
just be a preference thing.

rick jones

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/