On Thu, Nov 15, 2007 at 10:36:13AM -0700, Alex Chiang wrote:
< snip >
> Ok, so all that said, after re-implementing my ACPI-PCI slot
> driver, we get all the correct answers, but with the additional
> appearance of slots 1 and 2 (which aren't hotpluggable):
Yea, looks much better. Nice to see
Hi Greg, Matt,
* Greg KH <[EMAIL PROTECTED]>:
> On Wed, Nov 14, 2007 at 02:42:21PM -0700, Alex Chiang wrote:
> > * Greg KH <[EMAIL PROTECTED]>:
> > > On Wed, Nov 14, 2007 at 10:37:08AM -0700, Bjorn Helgaas wrote:
> > > >
> > > > So I agree that the firmware kit has a clever hack that works
> > >
Hi Gary,
[I'm gonna take the points in your mail a little out of order]
> No, acpiphp should (and did before your changes) register all
> hotplug capable slots. All 6 slots (2 PCI-X, 4 PCIe) in that
> system are hotplug capable. Emptyness shouldn't matter. If
> the empty slots are not
Hi Gary,
[I'm gonna take the points in your mail a little out of order]
No, acpiphp should (and did before your changes) register all
hotplug capable slots. All 6 slots (2 PCI-X, 4 PCIe) in that
system are hotplug capable. Emptyness shouldn't matter. If
the empty slots are not registered
Hi Greg, Matt,
* Greg KH [EMAIL PROTECTED]:
On Wed, Nov 14, 2007 at 02:42:21PM -0700, Alex Chiang wrote:
* Greg KH [EMAIL PROTECTED]:
On Wed, Nov 14, 2007 at 10:37:08AM -0700, Bjorn Helgaas wrote:
So I agree that the firmware kit has a clever hack that works
on much existing
On Thu, Nov 15, 2007 at 10:36:13AM -0700, Alex Chiang wrote:
snip
Ok, so all that said, after re-implementing my ACPI-PCI slot
driver, we get all the correct answers, but with the additional
appearance of slots 1 and 2 (which aren't hotpluggable):
Yea, looks much better. Nice to see that
On Tue, Nov 13, 2007 at 06:37:32PM -0700, Alex Chiang wrote:
> Hi Gary,
>
> * Gary Hade <[EMAIL PROTECTED]>:
> > On Tue, Nov 13, 2007 at 01:11:02PM -0700, Matthew Wilcox wrote:
> > > On Tue, Nov 13, 2007 at 10:51:22AM -0800, Greg KH wrote:
> > > > Ok, again, I want to see the IBM people sign off
On Wed, Nov 14, 2007 at 02:42:21PM -0700, Alex Chiang wrote:
> * Greg KH <[EMAIL PROTECTED]>:
> > On Wed, Nov 14, 2007 at 10:37:08AM -0700, Bjorn Helgaas wrote:
> > >
> > > So I agree that the firmware kit has a clever hack that works
> > > on much existing x86 firmware, and it sounds like Tivoli
* Greg KH <[EMAIL PROTECTED]>:
> On Wed, Nov 14, 2007 at 10:37:08AM -0700, Bjorn Helgaas wrote:
> >
> > So I agree that the firmware kit has a clever hack that works
> > on much existing x86 firmware, and it sounds like Tivoli
> > might even rely on it. But I don't feel good about it, and
> > it
Hi Greg,
* Greg KH <[EMAIL PROTECTED]>:
> On Wed, Nov 14, 2007 at 10:37:08AM -0700, Bjorn Helgaas wrote:
> >
> > So I agree that the firmware kit has a clever hack that works
> > on much existing x86 firmware, and it sounds like Tivoli
> > might even rely on it. But I don't feel good about it,
Hi Greg,
* Greg KH <[EMAIL PROTECTED]>:
> On Wed, Nov 14, 2007 at 10:37:08AM -0700, Bjorn Helgaas wrote:
> >
> > So I agree that the firmware kit has a clever hack that works
> > on much existing x86 firmware, and it sounds like Tivoli
> > might even rely on it. But I don't feel good about it,
On Wed, 14 Nov 2007 18:55:21 +0900
Kenji Kaneshige <[EMAIL PROTECTED]> wrote:
> Matthew Wilcox :
> > On Tue, Nov 13, 2007 at 03:33:14PM -0800, Kristen Carlson Accardi wrote:
> >> As far as being able to retrieve the slot number (which it seemed from
> >> the HP manageablity application
Hi Gary,
* Gary Hade <[EMAIL PROTECTED]>:
> On Wed, Nov 14, 2007 at 07:42:37AM -0700, Alex Chiang wrote:
> > Hi Gary,
> >
> > * Gary Hade <[EMAIL PROTECTED]>:
> > >
> > > I am not fundamentally opposed to this new capability but share
> > > the same concerns that Greg and others have expressed.
On Wed, Nov 14, 2007 at 07:42:37AM -0700, Alex Chiang wrote:
> Hi Gary,
>
> * Gary Hade <[EMAIL PROTECTED]>:
> >
> > I am not fundamentally opposed to this new capability but share
> > the same concerns that Greg and others have expressed. So far,
> > I have only tried the changes on one single
On Wed, Nov 14, 2007 at 09:51:51AM -0800, Greg KH wrote:
> On Wed, Nov 14, 2007 at 05:44:01PM +, Matthew Garrett wrote:
> > Dumping raw ACPI tables isn't adequate - _SUN might be a complex ACPI
> > method with multiple reads and writes to raw hardware, and we really
> > don't want to do that
On Wed, Nov 14, 2007 at 10:37:08AM -0700, Bjorn Helgaas wrote:
> On Tuesday 13 November 2007 03:59:36 pm Kristen Carlson Accardi wrote:
> > On Tue, 13 Nov 2007 12:26:32 -0800 Greg KH <[EMAIL PROTECTED]> wrote:
> > > And isn't there some other tool that dumps the raw ACPI tables? I
> > > thought
On Wed, Nov 14, 2007 at 05:44:01PM +, Matthew Garrett wrote:
> On Tue, Nov 13, 2007 at 12:26:32PM -0800, Greg KH wrote:
>
> > Doesn't /sys/firmware/acpi give you raw access to the correct tables
> > already?
> >
> > And isn't there some other tool that dumps the raw ACPI tables? I
> >
On Tue, Nov 13, 2007 at 12:26:32PM -0800, Greg KH wrote:
> Doesn't /sys/firmware/acpi give you raw access to the correct tables
> already?
>
> And isn't there some other tool that dumps the raw ACPI tables? I
> thought the acpi developers used it all the time when debugging things
> with users.
On Tuesday 13 November 2007 03:59:36 pm Kristen Carlson Accardi wrote:
> On Tue, 13 Nov 2007 12:26:32 -0800 Greg KH <[EMAIL PROTECTED]> wrote:
> > And isn't there some other tool that dumps the raw ACPI tables? I
> > thought the acpi developers used it all the time when debugging things
> > with
* Andi Kleen <[EMAIL PROTECTED]>:
> On Wed, Nov 14, 2007 at 08:00:25AM -0700, Matthew Wilcox wrote:
> > On Wed, Nov 14, 2007 at 03:35:33PM +0100, Andi Kleen wrote:
> > > It becomes much more when someone does a find /sys.
> > > dentries are expensive. They eventually can get pruned
> > > again,
On Wed, Nov 14, 2007 at 04:08:01PM +0100, Andi Kleen wrote:
> Whoever is proposing a feature has the burden to justify that
> its usefulness is larger than the overhead/cost it adds.
>
> Doesn't seem to be the case with this one so far.
Huh? There are half a dozen people who think it does, and
On Wed, Nov 14, 2007 at 08:00:25AM -0700, Matthew Wilcox wrote:
> On Wed, Nov 14, 2007 at 03:35:33PM +0100, Andi Kleen wrote:
> > It becomes much more when someone does a find /sys. dentries are
> > expensive. They eventually can get pruned again, but it's still
> > costly to do that.
>
> Again,
On Wed, Nov 14, 2007 at 03:35:33PM +0100, Andi Kleen wrote:
> It becomes much more when someone does a find /sys. dentries are
> expensive. They eventually can get pruned again, but it's still
> costly to do that.
Again, if this is a big concern for you, there are better places to look
at for
Hi Gary,
* Gary Hade <[EMAIL PROTECTED]>:
>
> I am not fundamentally opposed to this new capability but share
> the same concerns that Greg and others have expressed. So far,
> I have only tried the changes on one single node system (IBM
> x3850) but the below NAK-worthy result supports the
On Wed, Nov 14, 2007 at 07:17:51AM -0700, Matthew Wilcox wrote:
> On Wed, Nov 14, 2007 at 02:07:56AM +0100, Andi Kleen wrote:
> > It's not only complexity. Each new sysfs entry costs memory.
> > Memory is not free. There should be always a good reason for those.
>
> It's not a lot of memory; it's
On Wed, Nov 14, 2007 at 02:07:56AM +0100, Andi Kleen wrote:
> It's not only complexity. Each new sysfs entry costs memory.
> Memory is not free. There should be always a good reason for those.
It's not a lot of memory; it's one directory and a couple of files for
each PCI slot in the system.
Hi,
I tried the series of patches and I encountered some problems.
Since I don't have enough time to investigate them, I can only
report them at present. My environment was ia64 machine with 64
hotplug slots (shpc & pcie). Those slots can be handled by
acpiphp too, though I have not tried it
Matthew Wilcox :
On Tue, Nov 13, 2007 at 03:33:14PM -0800, Kristen Carlson Accardi wrote:
As far as being able to retrieve the slot number (which it seemed from
the HP manageablity application perspective is the goal here), that
information is available from userspace as well for at
Matthew Wilcox :
On Tue, Nov 13, 2007 at 03:33:14PM -0800, Kristen Carlson Accardi wrote:
As far as being able to retrieve the slot number (which it seemed from
the HP manageablity application perspective is the goal here), that
information is available from userspace as well for at
Hi,
I tried the series of patches and I encountered some problems.
Since I don't have enough time to investigate them, I can only
report them at present. My environment was ia64 machine with 64
hotplug slots (shpc pcie). Those slots can be handled by
acpiphp too, though I have not tried it yet.
On Wed, Nov 14, 2007 at 02:07:56AM +0100, Andi Kleen wrote:
It's not only complexity. Each new sysfs entry costs memory.
Memory is not free. There should be always a good reason for those.
It's not a lot of memory; it's one directory and a couple of files for
each PCI slot in the system. Even
Hi Gary,
* Gary Hade [EMAIL PROTECTED]:
I am not fundamentally opposed to this new capability but share
the same concerns that Greg and others have expressed. So far,
I have only tried the changes on one single node system (IBM
x3850) but the below NAK-worthy result supports the idea that
On Wed, Nov 14, 2007 at 07:17:51AM -0700, Matthew Wilcox wrote:
On Wed, Nov 14, 2007 at 02:07:56AM +0100, Andi Kleen wrote:
It's not only complexity. Each new sysfs entry costs memory.
Memory is not free. There should be always a good reason for those.
It's not a lot of memory; it's one
On Wed, Nov 14, 2007 at 03:35:33PM +0100, Andi Kleen wrote:
It becomes much more when someone does a find /sys. dentries are
expensive. They eventually can get pruned again, but it's still
costly to do that.
Again, if this is a big concern for you, there are better places to look
at for
On Wed, Nov 14, 2007 at 04:08:01PM +0100, Andi Kleen wrote:
Whoever is proposing a feature has the burden to justify that
its usefulness is larger than the overhead/cost it adds.
Doesn't seem to be the case with this one so far.
Huh? There are half a dozen people who think it does, and half
On Wed, Nov 14, 2007 at 08:00:25AM -0700, Matthew Wilcox wrote:
On Wed, Nov 14, 2007 at 03:35:33PM +0100, Andi Kleen wrote:
It becomes much more when someone does a find /sys. dentries are
expensive. They eventually can get pruned again, but it's still
costly to do that.
Again, if this
* Andi Kleen [EMAIL PROTECTED]:
On Wed, Nov 14, 2007 at 08:00:25AM -0700, Matthew Wilcox wrote:
On Wed, Nov 14, 2007 at 03:35:33PM +0100, Andi Kleen wrote:
It becomes much more when someone does a find /sys.
dentries are expensive. They eventually can get pruned
again, but it's still
On Tue, Nov 13, 2007 at 12:26:32PM -0800, Greg KH wrote:
Doesn't /sys/firmware/acpi give you raw access to the correct tables
already?
And isn't there some other tool that dumps the raw ACPI tables? I
thought the acpi developers used it all the time when debugging things
with users.
On Tuesday 13 November 2007 03:59:36 pm Kristen Carlson Accardi wrote:
On Tue, 13 Nov 2007 12:26:32 -0800 Greg KH [EMAIL PROTECTED] wrote:
And isn't there some other tool that dumps the raw ACPI tables? I
thought the acpi developers used it all the time when debugging things
with users.
On Wed, Nov 14, 2007 at 05:44:01PM +, Matthew Garrett wrote:
On Tue, Nov 13, 2007 at 12:26:32PM -0800, Greg KH wrote:
Doesn't /sys/firmware/acpi give you raw access to the correct tables
already?
And isn't there some other tool that dumps the raw ACPI tables? I
thought the acpi
On Wed, Nov 14, 2007 at 10:37:08AM -0700, Bjorn Helgaas wrote:
On Tuesday 13 November 2007 03:59:36 pm Kristen Carlson Accardi wrote:
On Tue, 13 Nov 2007 12:26:32 -0800 Greg KH [EMAIL PROTECTED] wrote:
And isn't there some other tool that dumps the raw ACPI tables? I
thought the acpi
On Wed, Nov 14, 2007 at 09:51:51AM -0800, Greg KH wrote:
On Wed, Nov 14, 2007 at 05:44:01PM +, Matthew Garrett wrote:
Dumping raw ACPI tables isn't adequate - _SUN might be a complex ACPI
method with multiple reads and writes to raw hardware, and we really
don't want to do that in
Hi Gary,
* Gary Hade [EMAIL PROTECTED]:
On Wed, Nov 14, 2007 at 07:42:37AM -0700, Alex Chiang wrote:
Hi Gary,
* Gary Hade [EMAIL PROTECTED]:
I am not fundamentally opposed to this new capability but share
the same concerns that Greg and others have expressed. So far,
I have
On Wed, Nov 14, 2007 at 07:42:37AM -0700, Alex Chiang wrote:
Hi Gary,
* Gary Hade [EMAIL PROTECTED]:
I am not fundamentally opposed to this new capability but share
the same concerns that Greg and others have expressed. So far,
I have only tried the changes on one single node system
On Wed, 14 Nov 2007 18:55:21 +0900
Kenji Kaneshige [EMAIL PROTECTED] wrote:
Matthew Wilcox :
On Tue, Nov 13, 2007 at 03:33:14PM -0800, Kristen Carlson Accardi wrote:
As far as being able to retrieve the slot number (which it seemed from
the HP manageablity application perspective
Hi Greg,
* Greg KH [EMAIL PROTECTED]:
On Wed, Nov 14, 2007 at 10:37:08AM -0700, Bjorn Helgaas wrote:
So I agree that the firmware kit has a clever hack that works
on much existing x86 firmware, and it sounds like Tivoli
might even rely on it. But I don't feel good about it, and
it
Hi Greg,
* Greg KH [EMAIL PROTECTED]:
On Wed, Nov 14, 2007 at 10:37:08AM -0700, Bjorn Helgaas wrote:
So I agree that the firmware kit has a clever hack that works
on much existing x86 firmware, and it sounds like Tivoli
might even rely on it. But I don't feel good about it, and
it
* Greg KH [EMAIL PROTECTED]:
On Wed, Nov 14, 2007 at 10:37:08AM -0700, Bjorn Helgaas wrote:
So I agree that the firmware kit has a clever hack that works
on much existing x86 firmware, and it sounds like Tivoli
might even rely on it. But I don't feel good about it, and
it could easily
On Wed, Nov 14, 2007 at 02:42:21PM -0700, Alex Chiang wrote:
* Greg KH [EMAIL PROTECTED]:
On Wed, Nov 14, 2007 at 10:37:08AM -0700, Bjorn Helgaas wrote:
So I agree that the firmware kit has a clever hack that works
on much existing x86 firmware, and it sounds like Tivoli
might even
On Tue, Nov 13, 2007 at 06:37:32PM -0700, Alex Chiang wrote:
Hi Gary,
* Gary Hade [EMAIL PROTECTED]:
On Tue, Nov 13, 2007 at 01:11:02PM -0700, Matthew Wilcox wrote:
On Tue, Nov 13, 2007 at 10:51:22AM -0800, Greg KH wrote:
Ok, again, I want to see the IBM people sign off on this, after
On Tue, 13 Nov 2007, Greg KH wrote:
> On Tue, Nov 13, 2007 at 04:04:00PM -0700, Matthew Wilcox wrote:
> > On Tue, Nov 13, 2007 at 02:56:05PM -0800, Greg KH wrote:
> > > Why not just use the code in the linux firmware kit that does this
> > > already today from userspace (thanks to Kristen for
Hi Gary,
* Gary Hade <[EMAIL PROTECTED]>:
> On Tue, Nov 13, 2007 at 01:11:02PM -0700, Matthew Wilcox wrote:
> > On Tue, Nov 13, 2007 at 10:51:22AM -0800, Greg KH wrote:
> > > Ok, again, I want to see the IBM people sign off on this, after testing
> > > on all of their machines, before I'll
Greg KH <[EMAIL PROTECTED]> writes:
>
> Also, some companies already provide userspace tools to get all of this
> information about the different slots in a system and what is where,
> from userspace, no kernel changes are needed. So, why add all this
> extra complexity to the kernel if it is not
On Tue, Nov 13, 2007 at 03:33:14PM -0800, Kristen Carlson Accardi wrote:
> As far as being able to retrieve the slot number (which it seemed from
> the HP manageablity application perspective is the goal here), that
> information is available from userspace as well for at least standard PCI
> and
On Tue, 13 Nov 2007 16:04:00 -0700
Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 13, 2007 at 02:56:05PM -0800, Greg KH wrote:
> > Why not just use the code in the linux firmware kit that does this
> > already today from userspace (thanks to Kristen for pointing this out to
> > me on
Hi Greg,
* Greg KH <[EMAIL PROTECTED]>:
> On Tue, Nov 13, 2007 at 02:31:08PM -0700, Alex Chiang wrote:
> >
> > FWIW, the ACPI 2.0 spec did not require uniqueness for _SUN.
> > (although there is a strange table that refers to _SUN as the
> > slot-unique ID (table 6-1 in spec v2.0b), the actual
On Tue, Nov 13, 2007 at 01:11:02PM -0700, Matthew Wilcox wrote:
> On Tue, Nov 13, 2007 at 10:51:22AM -0800, Greg KH wrote:
> > 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
On Tue, Nov 13, 2007 at 04:04:00PM -0700, Matthew Wilcox wrote:
> On Tue, Nov 13, 2007 at 02:56:05PM -0800, Greg KH wrote:
> > Why not just use the code in the linux firmware kit that does this
> > already today from userspace (thanks to Kristen for pointing this out to
> > me on irc.)?
>
> So
On Tue, Nov 13, 2007 at 02:56:05PM -0800, Greg KH wrote:
> Why not just use the code in the linux firmware kit that does this
> already today from userspace (thanks to Kristen for pointing this out to
> me on irc.)?
So then we have something that works on ACPI-based machines. Who will
add
On Tue, 13 Nov 2007 12:26:32 -0800
Greg KH <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 13, 2007 at 01:21:54PM -0700, Alex Chiang wrote:
> > * Greg KH <[EMAIL PROTECTED]>:
> > > On Mon, Nov 12, 2007 at 05:08:53PM -0700, Alex Chiang wrote:
> > > >
> > > > Recently, Matthew Wilcox sent out the
On Tue, Nov 13, 2007 at 02:51:13PM -0800, Rick Jones wrote:
> Greg KH wrote:
>> Doesn't /sys/firmware/acpi give you raw access to the correct tables
>> already?
>> And isn't there some other tool that dumps the raw ACPI tables? I
>> thought the acpi developers used it all the time when debugging
Greg KH wrote:
Doesn't /sys/firmware/acpi give you raw access to the correct tables
already?
And isn't there some other tool that dumps the raw ACPI tables? I
thought the acpi developers used it all the time when debugging things
with users.
I'm neither an acpi developer (well I don't think
On Tue, Nov 13, 2007 at 03:01:01PM -0700, Bjorn Helgaas wrote:
> On Tuesday 13 November 2007 02:30:49 pm Greg KH wrote:
> > On Tue, Nov 13, 2007 at 01:36:45PM -0700, Alex Chiang wrote:
> > > * Greg KH <[EMAIL PROTECTED]>:
> > > > IBM sells a program that does this for server rooms. It's
> > > >
On Tuesday 13 November 2007 02:30:49 pm Greg KH wrote:
> On Tue, Nov 13, 2007 at 01:36:45PM -0700, Alex Chiang wrote:
> > * Greg KH <[EMAIL PROTECTED]>:
> > > IBM sells a program that does this for server rooms. It's
> > > probably part of some Tivoli package somewhere, sorry I don't
> > >
On Tue, Nov 13, 2007 at 03:41:21PM -0600, Linas Vepstas wrote:
> /sys/bus/pci/slots
> /sys/bus/pci/slots/control
> /sys/bus/pci/slots/control/remove_slot
> /sys/bus/pci/slots/control/add_slot
> /sys/bus/pci/slots/0001:00:02.0
> /sys/bus/pci/slots/0001:00:02.0/phy_location
Ugh. Almost two years
On Tue, Nov 13, 2007 at 01:59:39PM -0700, Alex Chiang wrote:
>
> > On pseries systems, I deal with something called the
> > "partitionable endpoint", which I think probably usually
> > corresponds to physical slots, but I don't really know.
> >
> > So, naively, the physical slot concept doesn't
On Tue, Nov 13, 2007 at 02:31:08PM -0700, Alex Chiang wrote:
> * Matt Domsch <[EMAIL PROTECTED]>:
> >
> > 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
On Tue, Nov 13, 2007 at 01:36:45PM -0700, Alex Chiang wrote:
> * Greg KH <[EMAIL PROTECTED]>:
> >
> > 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".
>
> Who would be a
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.
* Matt Domsch <[EMAIL PROTECTED]>:
>
> 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.
FWIW, the ACPI 2.0 spec did
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
* Linas Vepstas <[EMAIL PROTECTED]>:
> On Tue, Nov 13, 2007 at 09:01:29AM -0800, Greg KH wrote:
> >
> > Also, some companies already provide userspace tools to get
> > all of this information about the different slots in a system
> > and what is where, from userspace, no kernel changes are
> >
* Greg KH <[EMAIL PROTECTED]>:
>
> 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".
Who would be a good contact at IBM to get some eyes / machine
time on this?
> Also, how
On Tue, Nov 13, 2007 at 01:21:54PM -0700, Alex Chiang wrote:
> * Greg KH <[EMAIL PROTECTED]>:
> > On Mon, Nov 12, 2007 at 05:08:53PM -0700, Alex Chiang wrote:
> > >
> > > Recently, Matthew Wilcox sent out the following mail about
> > > PCI slots:
> > >
> > >
On Tue, Nov 13, 2007 at 09:01:29AM -0800, Greg KH wrote:
>
> Also, some companies already provide userspace tools to get all of this
> information about the different slots in a system and what is where,
> from userspace, no kernel changes are needed. So, why add all this
> extra complexity to
* Greg KH <[EMAIL PROTECTED]>:
> On Mon, Nov 12, 2007 at 05:08:53PM -0700, Alex Chiang wrote:
> >
> > Recently, Matthew Wilcox sent out the following mail about
> > PCI slots:
> >
> > http://marc.info/?l=linux-pci=119432330418980=2
> >
> > The following patch series is a rough first cut at
>
On Tue, Nov 13, 2007 at 01:11:02PM -0700, Matthew Wilcox wrote:
> On Tue, Nov 13, 2007 at 10:51:22AM -0800, Greg KH wrote:
> > 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
On Tue, Nov 13, 2007 at 10:51:22AM -0800, Greg KH wrote:
> 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".
That seems a little higher standard than patches are normally held
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
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
On Mon, Nov 12, 2007 at 05:08:53PM -0700, Alex Chiang wrote:
> Hello,
>
> [this patch series touches a few subsystems; hopefully I got all
> the right maintainers]
>
> Recently, Matthew Wilcox sent out the following mail about PCI
> slots:
>
> http://marc.info/?l=linux-pci=119432330418980=2
>
On Mon, Nov 12, 2007 at 05:08:53PM -0700, Alex Chiang wrote:
Hello,
[this patch series touches a few subsystems; hopefully I got all
the right maintainers]
Recently, Matthew Wilcox sent out the following mail about PCI
slots:
http://marc.info/?l=linux-pcim=119432330418980w=2
The
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
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
On Tue, Nov 13, 2007 at 10:51:22AM -0800, Greg KH wrote:
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.
That seems a little higher standard than patches are normally held to.
On Tue, Nov 13, 2007 at 01:11:02PM -0700, Matthew Wilcox wrote:
On Tue, Nov 13, 2007 at 10:51:22AM -0800, Greg KH wrote:
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.
* Greg KH [EMAIL PROTECTED]:
On Mon, Nov 12, 2007 at 05:08:53PM -0700, Alex Chiang wrote:
Recently, Matthew Wilcox sent out the following mail about
PCI slots:
http://marc.info/?l=linux-pcim=119432330418980w=2
The following patch series is a rough first cut at
implementing
On Tue, Nov 13, 2007 at 09:01:29AM -0800, Greg KH wrote:
Also, some companies already provide userspace tools to get all of this
information about the different slots in a system and what is where,
from userspace, no kernel changes are needed. So, why add all this
extra complexity to the
On Tue, Nov 13, 2007 at 01:21:54PM -0700, Alex Chiang wrote:
* Greg KH [EMAIL PROTECTED]:
On Mon, Nov 12, 2007 at 05:08:53PM -0700, Alex Chiang wrote:
Recently, Matthew Wilcox sent out the following mail about
PCI slots:
http://marc.info/?l=linux-pcim=119432330418980w=2
* Greg KH [EMAIL PROTECTED]:
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.
Who would be a good contact at IBM to get some eyes / machine
time on this?
Also, how about Dell
* Linas Vepstas [EMAIL PROTECTED]:
On Tue, Nov 13, 2007 at 09:01:29AM -0800, Greg KH wrote:
Also, some companies already provide userspace tools to get
all of this information about the different slots in a system
and what is where, from userspace, no kernel changes are
needed. So,
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
* Matt Domsch [EMAIL PROTECTED]:
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.
FWIW, the ACPI 2.0 spec did not
On Tue, Nov 13, 2007 at 01:36:45PM -0700, Alex Chiang wrote:
* Greg KH [EMAIL PROTECTED]:
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.
Who would be a good contact at
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
On Tue, Nov 13, 2007 at 02:31:08PM -0700, Alex Chiang wrote:
* Matt Domsch [EMAIL PROTECTED]:
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
On Tue, Nov 13, 2007 at 01:59:39PM -0700, Alex Chiang wrote:
On pseries systems, I deal with something called the
partitionable endpoint, which I think probably usually
corresponds to physical slots, but I don't really know.
So, naively, the physical slot concept doesn't really map
On Tue, Nov 13, 2007 at 03:41:21PM -0600, Linas Vepstas wrote:
/sys/bus/pci/slots
/sys/bus/pci/slots/control
/sys/bus/pci/slots/control/remove_slot
/sys/bus/pci/slots/control/add_slot
/sys/bus/pci/slots/0001:00:02.0
/sys/bus/pci/slots/0001:00:02.0/phy_location
Ugh. Almost two years ago,
On Tuesday 13 November 2007 02:30:49 pm Greg KH wrote:
On Tue, Nov 13, 2007 at 01:36:45PM -0700, Alex Chiang wrote:
* Greg KH [EMAIL PROTECTED]:
IBM sells a program that does this for server rooms. It's
probably part of some Tivoli package somewhere, sorry I don't
remember the name.
On Tue, Nov 13, 2007 at 03:01:01PM -0700, Bjorn Helgaas wrote:
On Tuesday 13 November 2007 02:30:49 pm Greg KH wrote:
On Tue, Nov 13, 2007 at 01:36:45PM -0700, Alex Chiang wrote:
* Greg KH [EMAIL PROTECTED]:
IBM sells a program that does this for server rooms. It's
probably part of
1 - 100 of 114 matches
Mail list logo
