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 register
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 o
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, a
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, a
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 per
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 th
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
> > though
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 u
* 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
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 h
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 sav
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
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. Even
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.
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 leas
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 poin
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 conside
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 p
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 irc.
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 de
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"
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 the
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 support
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 followin
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 t
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 t
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
> > > > pr
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
> > > remembe
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 ag
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 unique
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 go
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 not
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
> > nee
* 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 abo
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-pci&m=1194
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 th
* 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&m=119432330418980&w=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 "odd"
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 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 s
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 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&m=119432330418980&w=
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&m=119432330418980&w=2
The following patch series is a rough first cut at implementing
the ideas he
57 matches
Mail list logo
