New: echo min_power > /sys/class/scsi_host/host0/active_mode causes problem

Bugme-new Andrew Morton 4 participants 4 messages Jun 16, 2008 1 message not in the archive SCSI

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]/

Andrew Morton

author

2008-06-16 01:02 UTC #1 lore raw

Quoted 25 lines · On Sun, 15 Jun 2008 01:52:26 -0700 (PDT) [email protected] wrote:

http://bugzilla.kernel.org/show_bug.cgi?id=10915
Summary: echo min_power > /sys/class/scsi_host/host0/active_mode
causes problem
Product: File System
Version: 2.5
KernelVersion: 2.6.25.6
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: SysFS
AssignedTo: [email protected]
ReportedBy: [email protected]
Latest working kernel version: unknown Earliest failing kernel version: unknown
Distribution: Debian testing Hardware Environment: HP Compaq 6910p Software Environment: Debian testing, sysfs Problem Description:

Quoted 7 lines

In accident I proceed
echo min_power > /sys/class/scsi_host/host0/active_mode
which causes HIGH cpu load, echo wasn't killable so reboot was only solution :(
Steps to reproduce:
proceed command

For reasons which escape me, there is no description text in bugzilla for this report, yet the reporter entered some.

Anyway. Could someone please refile this under scsi? Or fix the bug ;)

James Bottomley

maintainer

2008-06-16 02:00 UTC #2 lore raw

Quoted 32 lines · Andrew Morton

Quoted 30 lines · On Sun, 15 Jun 2008 01:52:26 -0700 (PDT) [email protected] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=10915
Summary: echo min_power > /sys/class/scsi_host/host0/active_mode
causes problem
Product: File System
Version: 2.5
KernelVersion: 2.6.25.6
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: SysFS
AssignedTo: [email protected]
ReportedBy: [email protected]
Latest working kernel version: unknown Earliest failing kernel version: unknown
Distribution: Debian testing Hardware Environment: HP Compaq 6910p Software Environment: Debian testing, sysfs Problem Description:
In accident I proceed
echo min_power > /sys/class/scsi_host/host0/active_mode
which causes HIGH cpu load, echo wasn't killable so reboot was only solution :(

Quoted 7 lines

Quoted 2 lines
Steps to reproduce:
proceed command
For reasons which escape me, there is no description text in bugzilla for this report, yet the reporter entered some.
Anyway. Could someone please refile this under scsi? Or fix the bug ;)

Um ... actually, maybe not. The active_mode file is read only (it has a NULL store method). It's designed to show what mode the host is activated in "initiator", "target" (or both or unknown). If echoing something to a read only sysfs file with no actual store method is causing this behaviour, the root cause has to be somewhere in sysfs.

However, since the file has nothing to do with power saving ... unless some driver I can't find is trying to duplicate it, so there's no reason to try to echo "min_power" to it, so some of the details on this report might bear further investigation ...

James

FUJITA Tomonori

2008-06-16 04:51 UTC #3 lore raw

Quoted 39 lines · On Sun, 15 Jun 2008 21:00:10 -0500 James Bottomley…

Quoted 38 lines · Andrew Morton
Quoted 25 lines · On Sun, 15 Jun 2008 01:52:26 -0700 (PDT) [email protected] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=10915
Summary: echo min_power > /sys/class/scsi_host/host0/active_mode
causes problem
Product: File System
Version: 2.5
KernelVersion: 2.6.25.6
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: SysFS
AssignedTo: [email protected]
ReportedBy: [email protected]
Latest working kernel version: unknown Earliest failing kernel version: unknown
Distribution: Debian testing Hardware Environment: HP Compaq 6910p Software Environment: Debian testing, sysfs Problem Description:
Quoted 7 lines
In accident I proceed
echo min_power > /sys/class/scsi_host/host0/active_mode
which causes HIGH cpu load, echo wasn't killable so reboot was only solution :(
Steps to reproduce:
proceed command
For reasons which escape me, there is no description text in bugzilla for this report, yet the reporter entered some.

Quoted 7 lines

Quoted 1 line
Anyway. Could someone please refile this under scsi? Or fix the bug ;)
Um ... actually, maybe not. The active_mode file is read only (it has a NULL store method). It's designed to show what mode the host is activated in "initiator", "target" (or both or unknown). If echoing something to a read only sysfs file with no actual store method is causing this behaviour, the root cause has to be somewhere in sysfs.

This bug doesn't happen with the latest git so I guess that the root cause was fixed, which can't handle the NULL store method properly.

But I think that it would be better to set active_mode and support_mode files to read-only (though in the future, active_mode would be changeable for a dual-mode driver).

Quoted 4 lines

However, since the file has nothing to do with power saving ... unless some driver I can't find is trying to duplicate it, so there's no reason to try to echo "min_power" to it, so some of the details on this report might bear further investigation ...

I guess that he intended to echo "min_power" to
link_power_management_policy file.

=
From: FUJITA Tomonori <[email protected]>
Subject: [PATCH] set active_mode and support_mode sysfs files to read-only

Signed-off-by FUJITA Tomonori <[email protected]>

---
 drivers/scsi/scsi_sysfs.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

drivers/scsi/scsi_sysfs.c +2 -2

index 93d2b67..01191bb 100644
@@ -227,7 +227,7 @@ show_shost_supported_mode(struct device *dev, struct device_attribute *attr,
 	return show_shost_mode(supported_mode, buf);
 }
 
-static DEVICE_ATTR(supported_mode, S_IRUGO | S_IWUSR, show_shost_supported_mode, NULL);
+static DEVICE_ATTR(supported_mode, S_IRUGO, show_shost_supported_mode, NULL);
 
 static ssize_t
 show_shost_active_mode(struct device *dev,

@@ -241,7 +241,7 @@ show_shost_active_mode(struct device *dev,
 		return show_shost_mode(shost->active_mode, buf);
 }
 
-static DEVICE_ATTR(active_mode, S_IRUGO | S_IWUSR, show_shost_active_mode, NULL);
+static DEVICE_ATTR(active_mode, S_IRUGO, show_shost_active_mode, NULL);
 
 shost_rd_attr(unique_id, "%u\n");
 shost_rd_attr(host_busy, "%hu\n");

Signature · 1 line

1.5.5.GIT

Andi Kleen

2008-06-16 12:48 UTC #4 lore raw

In reply to James Bottomley

Quoted 11 lines · James Bottomley

Um ... actually, maybe not. The active_mode file is read only (it has a NULL store method). It's designed to show what mode the host is activated in "initiator", "target" (or both or unknown). If echoing something to a read only sysfs file with no actual store method is causing this behaviour, the root cause has to be somewhere in sysfs.
However, since the file has nothing to do with power saving ... unless some driver I can't find is trying to duplicate it, so there's no reason to try to echo "min_power" to it, so some of the details on this report might bear further investigation ...

I remember hitting something like this in the past when write() returned 0. Some versions of echo loop in this case.

-Andi