On Wed, 1 Aug 2007 14:16:51 -0700
Kristen Carlson Accardi <[EMAIL PROTECTED]> wrote:
> I was able to duplicate Tejun's problem on an ATAPI device I had here.
> this updated patch fixed my problem. These devices are just setting
> PhyReady (N) and CommWake (W) in Serror on power state changes,
On Wed, 1 Aug 2007 14:16:51 -0700
Kristen Carlson Accardi [EMAIL PROTECTED] wrote:
I was able to duplicate Tejun's problem on an ATAPI device I had here.
this updated patch fixed my problem. These devices are just setting
PhyReady (N) and CommWake (W) in Serror on power state changes,
I was able to duplicate Tejun's problem on an ATAPI device I had here.
this updated patch fixed my problem. These devices are just setting
PhyReady (N) and CommWake (W) in Serror on power state changes, ignoring
them seems to be fine, and fixed the problem for me.
Enable Aggressive Link Power
On Wed, 01 Aug 2007 12:24:44 +0900
Tejun Heo <[EMAIL PROTECTED]> wrote:
> Kristen Carlson Accardi wrote:
> >> I don't think the interface you're suggesting is a good one. Do you?
> >
> > I think if it's applicable to SCSI at all it is fine. If it is not, then
> > I think we need to make do
On Wed, 2007-08-01 at 10:53 -0600, Matthew Wilcox wrote:
> On Tue, Jul 31, 2007 at 09:18:08AM -0500, James Bottomley wrote:
> > The other comment is that power saving seems to be a property of the
> > transport rather than the host. If you do it in the transport classes,
> > then you can expose
On Tue, Jul 31, 2007 at 09:18:08AM -0500, James Bottomley wrote:
> The other comment is that power saving seems to be a property of the
> transport rather than the host. If you do it in the transport classes,
> then you can expose all the knobs the actual transport possesses (which
> is,
On Wed, 01 Aug 2007 18:23:21 +0900
Tejun Heo <[EMAIL PROTECTED]> wrote:
> Tejun Heo wrote:
> > Arjan van de Ven wrote:
> >>> They were hardware problems. I don't think any amount of proper
> >>> implementation can fix them. I have one DVD RAM somewhere in my pile of
> >>> hardware which locks
On Wed, 01 Aug 2007 12:24:44 +0900
Tejun Heo <[EMAIL PROTECTED]> wrote:
> It would be *really* great if we can find more about how they do it.
> How and when it's enabled and on which systems. Is it possible to find
> this out?
No - it's really not a good idea for us to go and ask other OS's
Tejun Heo wrote:
> Arjan van de Ven wrote:
>>> They were hardware problems. I don't think any amount of proper
>>> implementation can fix them. I have one DVD RAM somewhere in my pile of
>>> hardware which locks up solidly if any link PS mode is used and had a
>> and the AHCI ALPM code decides
Tejun Heo wrote:
Arjan van de Ven wrote:
They were hardware problems. I don't think any amount of proper
implementation can fix them. I have one DVD RAM somewhere in my pile of
hardware which locks up solidly if any link PS mode is used and had a
and the AHCI ALPM code decides to use power
On Wed, 01 Aug 2007 12:24:44 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
It would be *really* great if we can find more about how they do it.
How and when it's enabled and on which systems. Is it possible to find
this out?
No - it's really not a good idea for us to go and ask other OS's how
On Wed, 01 Aug 2007 18:23:21 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
Tejun Heo wrote:
Arjan van de Ven wrote:
They were hardware problems. I don't think any amount of proper
implementation can fix them. I have one DVD RAM somewhere in my pile of
hardware which locks up solidly if any
On Tue, Jul 31, 2007 at 09:18:08AM -0500, James Bottomley wrote:
The other comment is that power saving seems to be a property of the
transport rather than the host. If you do it in the transport classes,
then you can expose all the knobs the actual transport possesses (which
is,
On Wed, 2007-08-01 at 10:53 -0600, Matthew Wilcox wrote:
On Tue, Jul 31, 2007 at 09:18:08AM -0500, James Bottomley wrote:
The other comment is that power saving seems to be a property of the
transport rather than the host. If you do it in the transport classes,
then you can expose all the
I was able to duplicate Tejun's problem on an ATAPI device I had here.
this updated patch fixed my problem. These devices are just setting
PhyReady (N) and CommWake (W) in Serror on power state changes, ignoring
them seems to be fine, and fixed the problem for me.
Enable Aggressive Link Power
On Wed, 01 Aug 2007 12:24:44 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
Kristen Carlson Accardi wrote:
I don't think the interface you're suggesting is a good one. Do you?
I think if it's applicable to SCSI at all it is fine. If it is not, then
I think we need to make do with the
Kristen Carlson Accardi wrote:
>> I don't think the interface you're suggesting is a good one. Do you?
>
> I think if it's applicable to SCSI at all it is fine. If it is not, then
> I think we need to make do with the interface we are given. I do not think
> we should hold up a feature for
Kristen Carlson Accardi wrote:
> So at current rate of development and kernel release schedule, the best
> possible scenario is still 6 months away - whereas this patchset is already
> tested and ready for merging now.
The best possible scenario is .24-rc1 merge window with or without
waiting.
On Wed, 01 Aug 2007 02:48:42 +0900
Tejun Heo <[EMAIL PROTECTED]> wrote:
> Hello, Kristen.
>
> Kristen Carlson Accardi wrote:
> > On Tue, 31 Jul 2007 23:45:25 +0900
> > Tejun Heo <[EMAIL PROTECTED]> wrote:
> >
> >> Anyways, I don't really think this attribute belongs to SCSI sysfs
> >>
On Wed, 01 Aug 2007 03:02:55 +0900
Tejun Heo <[EMAIL PROTECTED]> wrote:
> Kristen Carlson Accardi wrote:
> > I think what you are saying is that you'd like a way to use your HIPM
> > and DIPM without ALPM on the AHCI driver. Fine - it's really easy
> > to add these levels later - if they don't
Arjan van de Ven wrote:
>> They were hardware problems. I don't think any amount of proper
>> implementation can fix them. I have one DVD RAM somewhere in my pile of
>> hardware which locks up solidly if any link PS mode is used and had a
>
> and the AHCI ALPM code decides to use power savings
Kristen Carlson Accardi wrote:
> I think what you are saying is that you'd like a way to use your HIPM
> and DIPM without ALPM on the AHCI driver. Fine - it's really easy
> to add these levels later - if they don't make sense at the sysfs interface
> we can add module params to specify the
Hello, Kristen.
Kristen Carlson Accardi wrote:
> On Tue, 31 Jul 2007 23:45:25 +0900
> Tejun Heo <[EMAIL PROTECTED]> wrote:
>
>> Anyways, I don't really think this attribute belongs to SCSI sysfs
>> hierarchy. There currently isn't any alternative but sysfs is part of
>> userland visible
On Tue, 31 Jul 2007 15:27:34 +0900
Tejun Heo <[EMAIL PROTECTED]> wrote:
> Jeff Garzik wrote:
> > Any chance the SCSI peeps could ACK this, and then let me include it in
> > the ALPM patchset in the libata tree?
>
> ATA link PS is pretty complex with HIPM, DIPM and AHCI ALPM. I'm not
> sure
On Tue, 31 Jul 2007 23:45:25 +0900
Tejun Heo <[EMAIL PROTECTED]> wrote:
> Anyways, I don't really think this attribute belongs to SCSI sysfs
> hierarchy. There currently isn't any alternative but sysfs is part of
> userland visible interface and putting something into SCSI sysfs
> hierarchy just
> They were hardware problems. I don't think any amount of proper
> implementation can fix them. I have one DVD RAM somewhere in my pile of
> hardware which locks up solidly if any link PS mode is used and had a
and the AHCI ALPM code decides to use power savings on this device? if
so, please
Arjan van de Ven wrote:
> either sucks. AHCI ALPM ought to work if it's supported; it's what other
> operating systems also use...
A question. Does the other OS enable ALPM without checking against
white/black list? Or is it enabled only on certain configurations -
e.g. specific notebooks,
Arjan van de Ven wrote:
> On Tue, 2007-07-31 at 15:27 +0900, Tejun Heo wrote:
>> Jeff Garzik wrote:
>>> Any chance the SCSI peeps could ACK this, and then let me include it in
>>> the ALPM patchset in the libata tree?
>> ATA link PS is pretty complex with HIPM, DIPM and AHCI ALPM. I'm not
>> sure
On Tue, 2007-07-31 at 15:27 +0900, Tejun Heo wrote:
> Jeff Garzik wrote:
> > Any chance the SCSI peeps could ACK this, and then let me include it in
> > the ALPM patchset in the libata tree?
>
> ATA link PS is pretty complex with HIPM, DIPM and AHCI ALPM. I'm not
> sure whether this three level
On Tue, 2007-07-31 at 15:27 +0900, Tejun Heo wrote:
> Jeff Garzik wrote:
> > Any chance the SCSI peeps could ACK this, and then let me include it in
> > the ALPM patchset in the libata tree?
>
> ATA link PS is pretty complex with HIPM, DIPM and AHCI ALPM. I'm not
> sure whether this three level
Jeff Garzik wrote:
> Any chance the SCSI peeps could ACK this, and then let me include it in
> the ALPM patchset in the libata tree?
ATA link PS is pretty complex with HIPM, DIPM and AHCI ALPM. I'm not
sure whether this three level knob would be sufficient. It might be
good enough if we're
Jeff Garzik wrote:
Any chance the SCSI peeps could ACK this, and then let me include it in
the ALPM patchset in the libata tree?
ATA link PS is pretty complex with HIPM, DIPM and AHCI ALPM. I'm not
sure whether this three level knob would be sufficient. It might be
good enough if we're gonna
On Tue, 2007-07-31 at 15:27 +0900, Tejun Heo wrote:
Jeff Garzik wrote:
Any chance the SCSI peeps could ACK this, and then let me include it in
the ALPM patchset in the libata tree?
ATA link PS is pretty complex with HIPM, DIPM and AHCI ALPM. I'm not
sure whether this three level knob
On Tue, 2007-07-31 at 15:27 +0900, Tejun Heo wrote:
Jeff Garzik wrote:
Any chance the SCSI peeps could ACK this, and then let me include it in
the ALPM patchset in the libata tree?
ATA link PS is pretty complex with HIPM, DIPM and AHCI ALPM. I'm not
sure whether this three level knob
Arjan van de Ven wrote:
On Tue, 2007-07-31 at 15:27 +0900, Tejun Heo wrote:
Jeff Garzik wrote:
Any chance the SCSI peeps could ACK this, and then let me include it in
the ALPM patchset in the libata tree?
ATA link PS is pretty complex with HIPM, DIPM and AHCI ALPM. I'm not
sure whether this
Arjan van de Ven wrote:
either sucks. AHCI ALPM ought to work if it's supported; it's what other
operating systems also use...
A question. Does the other OS enable ALPM without checking against
white/black list? Or is it enabled only on certain configurations -
e.g. specific notebooks, etc?
They were hardware problems. I don't think any amount of proper
implementation can fix them. I have one DVD RAM somewhere in my pile of
hardware which locks up solidly if any link PS mode is used and had a
and the AHCI ALPM code decides to use power savings on this device? if
so, please
On Tue, 31 Jul 2007 23:45:25 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
Anyways, I don't really think this attribute belongs to SCSI sysfs
hierarchy. There currently isn't any alternative but sysfs is part of
userland visible interface and putting something into SCSI sysfs
hierarchy just
On Tue, 31 Jul 2007 15:27:34 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
Jeff Garzik wrote:
Any chance the SCSI peeps could ACK this, and then let me include it in
the ALPM patchset in the libata tree?
ATA link PS is pretty complex with HIPM, DIPM and AHCI ALPM. I'm not
sure whether this
Hello, Kristen.
Kristen Carlson Accardi wrote:
On Tue, 31 Jul 2007 23:45:25 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
Anyways, I don't really think this attribute belongs to SCSI sysfs
hierarchy. There currently isn't any alternative but sysfs is part of
userland visible interface and
Kristen Carlson Accardi wrote:
I think what you are saying is that you'd like a way to use your HIPM
and DIPM without ALPM on the AHCI driver. Fine - it's really easy
to add these levels later - if they don't make sense at the sysfs interface
we can add module params to specify the definition
Arjan van de Ven wrote:
They were hardware problems. I don't think any amount of proper
implementation can fix them. I have one DVD RAM somewhere in my pile of
hardware which locks up solidly if any link PS mode is used and had a
and the AHCI ALPM code decides to use power savings on this
On Wed, 01 Aug 2007 03:02:55 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
Kristen Carlson Accardi wrote:
I think what you are saying is that you'd like a way to use your HIPM
and DIPM without ALPM on the AHCI driver. Fine - it's really easy
to add these levels later - if they don't make sense
On Wed, 01 Aug 2007 02:48:42 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
Hello, Kristen.
Kristen Carlson Accardi wrote:
On Tue, 31 Jul 2007 23:45:25 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
Anyways, I don't really think this attribute belongs to SCSI sysfs
hierarchy. There currently
Kristen Carlson Accardi wrote:
So at current rate of development and kernel release schedule, the best
possible scenario is still 6 months away - whereas this patchset is already
tested and ready for merging now.
The best possible scenario is .24-rc1 merge window with or without
waiting.
Kristen Carlson Accardi wrote:
I don't think the interface you're suggesting is a good one. Do you?
I think if it's applicable to SCSI at all it is fine. If it is not, then
I think we need to make do with the interface we are given. I do not think
we should hold up a feature for libata
Kristen Carlson Accardi wrote:
@@ -42,6 +42,16 @@ enum scsi_eh_timer_return {
EH_RESET_TIMER,
};
+/*
+ * shost pm policy: If you alter this, you also need to alter scsi_sysfs.c
+ * (for the ascii descriptions)
+ */
+enum scsi_host_link_pm {
+ SHOST_NOT_AVAILABLE,
+
Kristen Carlson Accardi wrote:
@@ -42,6 +42,16 @@ enum scsi_eh_timer_return {
EH_RESET_TIMER,
};
+/*
+ * shost pm policy: If you alter this, you also need to alter scsi_sysfs.c
+ * (for the ascii descriptions)
+ */
+enum scsi_host_link_pm {
+ SHOST_NOT_AVAILABLE,
+
On Mon, 9 Jul 2007 19:36:04 +
Pavel Machek <[EMAIL PROTECTED]> wrote:
> Hi!
>
> > This patch will modify the scsi subsystem to allow
> > users to set a power management policy for the link.
> >
> > The scsi subsystem will create a new sysfs file for each
> > host in /sys/class/scsi_host
Hi!
> This patch will modify the scsi subsystem to allow
> users to set a power management policy for the link.
>
> The scsi subsystem will create a new sysfs file for each
> host in /sys/class/scsi_host called "link_power_management_policy".
> This file can have 3 possible values:
>
> Value
Hi!
This patch will modify the scsi subsystem to allow
users to set a power management policy for the link.
The scsi subsystem will create a new sysfs file for each
host in /sys/class/scsi_host called link_power_management_policy.
This file can have 3 possible values:
Value
On Mon, 9 Jul 2007 19:36:04 +
Pavel Machek [EMAIL PROTECTED] wrote:
Hi!
This patch will modify the scsi subsystem to allow
users to set a power management policy for the link.
The scsi subsystem will create a new sysfs file for each
host in /sys/class/scsi_host called
This patch will modify the scsi subsystem to allow
users to set a power management policy for the link.
The scsi subsystem will create a new sysfs file for each
host in /sys/class/scsi_host called "link_power_management_policy".
This file can have 3 possible values:
Value Meaning
This patch will modify the scsi subsystem to allow
users to set a power management policy for the link.
The scsi subsystem will create a new sysfs file for each
host in /sys/class/scsi_host called link_power_management_policy.
This file can have 3 possible values:
Value Meaning
54 matches
Mail list logo
