On Tue, Nov 13, 2007 at 03:15:09PM -0600, Matt Domsch wrote: > On Tue, Nov 13, 2007 at 10:51:22AM -0800, Greg KH wrote: > > 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. Heh, I can imagine :) > 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. I know they are different, I was using that as an example of trying to match up physical descriptions on a machine with the internal kernel representation. It isn't always easy and lots of times things go wrong, if for no other reason than no one is checking these things. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
