On Tue, Nov 13, 2007 at 10:51:22AM -0800, Greg KH wrote:
quoted text
> On Tue, Nov 13, 2007 at 11:33:53AM -0700, Matthew Wilcox wrote:
> > On Tue, Nov 13, 2007 at 09:01:29AM -0800, Greg KH wrote:
> > > I'm still not sold on this idea at all.  I'm really betting that there
> > > is a lot of incorrect acpi slot information floating around in machines
> > > and odd things will show up in these slot entries.
> > 
> > Is that the end of the world?  Instead of having no information, we'll
> > end up with odd information.  If people complain, we can always
> > blacklist (indeed, won't the ACPI rolling blacklist catch the majority
> > of these machines?)
> 
> I don't think the rolling blacklist will catch this, as the rest of the
> ACPI code is "correct".
> 
> And yes, incorrect information exported by the kernel is not good at
> all, especially if a user expects it to work properly :)
> 
> > > I say this because for a long time there was no "standard" acpi entries
> > > for hotplug slots and different companies did different things.  Hence
> > > the "odd" IBM acpi hotplug implementation as one example.  If this is
> > > going to go anywhere, you need to get IBM to agree that it works
> > > properly with all their machines...
> > 
> > Not in terms of slot names.  There were various things that ACPI didn't
> > specify, like attention and latches, but the description of _SUN hasn't
> > changed.
> 
> Ok, again, I want to see the IBM people sign off on this, after testing
> on all of their machines, before I'll consider this, as I know the IBM
> acpi tables are "odd".
> 
> Also, how about Dell machines?  I know they are probably not expecting
> this information to show up and who knows if the numbering of their
> slots match up with their physical diagrams (I say this based on all of
> the eth0/eth1 "issues" with Dell machines over the years...)


The only reported _SUN problems on Dell systems were on the PE6800 and
PE6850 systems, which we've fixed with an updated BIOS several months
ago.  IIRC the values weren't always unique which kind of defeated the
purpose.

The eth0/eth1 "issues" are completely separate, with no relation to
ACPI.  That's purely a PCI tree depth-first discovery
vs. breadth-first discovery (where it indeed seems everyone except
Linux 2.6 uses and expects breadth-first).  We looked at extending
ACPI to export device naming preference, but instead extended SMBIOS
tables because we could get that change in far easier.

The other bit that looks at slot numbers is the old PCI IRQ Routing
Table, which still exists on Dell systems.

quoted text
> > We should, IMO, be improving the way we tell users which device has
> > a problem.  'tulip7', 'eth4', 'pci 0000:04:1e.3' ... all the user wants
> > to know is which damn card it is so they can replace it.  And slot name
> > tells them that.
> 
> Not if the slot information is incorrect :)
> 
> That's my main concern.

Again, I've only seen this be incorrect on those two models of Dell
servers with outdated BIOS versions.

Thanks,
Matt

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/