Spinup of SCSI Disks: allow_restart won't work on 2.6.18

I have now the allow_restart entry in sysfs.
It's set to 0 in my machine and it won't let me change it with 'echo 1 > allow_restart' or echo -n. I always get a write error.

Quoted 3 lines

I have now the allow_restart entry in sysfs.
It's set to 0 in my machine and it won't let me change it with 'echo 1

Quoted 1 line

allow_restart' or echo -n. I always get a write error.

I just bought an external USB->IDE converter and tested it again. Of course due to the cheap concerter-chip the USB disk wont go to standby mode but I can set 'allow_restart' to 1 with this converter.

So maybe it's only about sbp2 implementation or specifically my OXFW911 bridges?

FWIW, sbp2 in Linux 2.6.19-rcX sets the allow_restart flag for all HDDs and other direct access devices. In Linux 2.6.18 it does so only for Maxtor disks.

FWIW, sbp2 in Linux 2.6.19-rcX sets the allow_restart flag for all HDDs and other direct access devices. In Linux 2.6.18 it does so only for Maxtor disks. Beyond setting that flag or leaving as it is, the sbp2 driver has nothing to do with the restart facility; it's a thing between the SCSI error handler and the target. Of course the firmware of the FireWire bridge has to support it in the first place. I have no data which OXFW911 firmwares do or don't.

Also I don't remember which Linux release has the patch that exposes the allow_restart flag as a writable sysfs attribute but I suppose if you can see this attribute, then you have the patch. I can set and unset it with echo on 2.6.19-rc4 just fine, as root of course.

One problem left. I still can't set or unset the flag with echo even on 2.6.19-rc6 (as root). Always getting a write error. Not that I care much about this, 'cause I for sure don't want it disabled.
But it's strange nonethless.

Quoted 3 lines

One problem left. I still can't set or unset the flag with echo even on 2.6.19-rc6 (as root). Always getting a write error. Not that I care much about this, 'cause I for sure don't want it disabled. But it's strange nonethless.

But the attribute has write permission set? (ls -l) It is writable on the last kernel I tried, which is -rc4.

Quoted 2 lines

Quoted 2 lines

One problem left. I still can't set or unset the flag with echo even on 2.6.19-rc6 (as root).

Permissions of the file are -rw-r--r--. Owner is of course root. As I wrote before I can set/unset the flag without any problems when I connect a dumb USB<->IDE
converter with kernel 2.6.18. Same with 2.6.19-rc6.

The complete error message (sorry it's in german here) is:
"-bash: echo: write error: Das Argument ist ungueltig"

Is there a way to do some debug on the internals to see why the attribute isn't actually writeable? Do you need parts of the kernel log?

A new problem just arised:
When I switch on the external enclosure with 3 bridges and 3 disks a few seconds "before" I plug the firewire connector into the PC everything works.
But when I first plug in the connector and turn on the external enclosure later, 2.6.19-rc6 hangs on the first disk and throws a BUG message.
I have to reboot the PC then and I reproduced it serveral times.

------------------snip----------------------------------
ieee1394: Error parsing configrom for node 0-00:1023
ieee1394: Error parsing configrom for node 0-01:1023
ieee1394: Error parsing configrom for node 0-02:1023
ieee1394: Node changed: 0-00:1023 -> 0-03:1023
ieee1394: Node added: ID:BUS[0-00:1023] GUID[0001d20000091ab2]
ieee1394: Node added: ID:BUS[0-01:1023] GUID[0001d20000093c4d]
ieee1394: Error parsing configrom for node 0-02:1023 scsi0 : SBP-2 IEEE-1394
ieee1394: sbp2: Logged into SBP-2 device
ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [1024]
scsi 0:0:0:0: Direct-Access-RBC Maxtor 4 D080H4 DAK0 PQ: 0
ANSI: 4
scsi1 : SBP-2 IEEE-1394
SCSI device sda: 160086528 512-byte hdwr sectors (81964 MB)
sda: Write Protect is off
sda: Mode Sense: 11 00 00 00
SCSI device sda: drive cache: write back

SCSI device sda: 160086528 512-byte hdwr sectors (81964 MB)
sda: Write Protect is off
sda: Mode Sense: 11 00 00 00
SCSI device sda: drive cache: write back
sda: sda1
sd 0:0:0:0: Attached scsi disk sda
ieee1394: sbp2: Error logging into SBP-2 device - timed out
sbp2: probe of 0001d20000093c4d-0 failed with error -16

------------[ cut here ]------------
kernel BUG at fs/sysfs/file.c:460!
invalid opcode: 0000 [#1]
SMP
Modules linked in: sd_mod nfs nfsd exportfs lockd nfs_acl sunrpc button

ac battery ipv6 de4x5 dm_snapshot dm_mirror dm_mod sr_mod sbp2 scsi_mod ehci_hcd ohci_hcd tulip joydev tsdev pcmcia firmware_class evdev i810_audio ac97_codec psmouse serio_raw floppy snd_intel8x0 yenta_socket snd_ac97_codec snd_ac97_bus rsrc_nonstatic pcmcia_core snd_pcm snd_timer snd soundcore snd_page_alloc parport_pc parport i2c_piix4 pcspkr i2c_core rtc ext3 jbd mbcache ide_generic ide_cd cdrom ide_disk uhci_hcd piix generic ide_core usbcore ohci1394 ieee1394 thermal processor fan

CPU:    0
EIP:    0060:[<c01966c6>]    Not tainted VLI
EFLAGS: 00010202   (2.6.19-rc6 #1)

EIP is at sysfs_create_file+0x19/0x31
eax: c7d03800 ebx: cc85f12c ecx: c7d038b0 edx: cc85f101
esi: cc85f12c edi: 00000000 ebp: c7d03800 esp: cb5f1eb8
ds: 007b es: 007b ss: 0068
Process knodemgrd_0 (pid: 549, ti=cb5f0000 task=cb595ab0 task.ti=cb5f0000)

Stack: c7d03838 c021ed64 c7d03838 00000001 c7d03994 cc84f029 c7d03a14 00000014
      cc853f32 cae3f0f4 00000000 cae3f000 fffffffc c7d03800 ccc6b000 00000000
      00000000 cc84f45c fffffffc ccafd058 cae3f000 cb65d3f8 00000000 01afd058
Call Trace:
[<c021ed64>] device_create_file+0x1c/0x2b
[<cc84f029>] nodemgr_register_device+0xd0/0x150 [ieee1394]
[<cc84f45c>] nodemgr_process_unit_directory+0x333/0x348 [ieee1394]
[<cc84f668>] nodemgr_probe_ne+0x183/0x37a [ieee1394]
[<cc850204>] nodemgr_host_thread+0x827/0x970 [ieee1394]
[<cc84f9dd>] nodemgr_host_thread+0x0/0x970 [ieee1394]
[<c01304d2>] kthread+0xc2/0xf0
[<c0130410>] kthread+0x0/0xf0
[<c01038bb>] kernel_thread_helper+0x7/0x10
=======================
Code: 83 c0 74 e8 65 08 10 00 89 e8 83 c4 10 5b 5e 5f 5d c3 85 c0 89 c1

53 89 d3 74 10 83 78 30 00 0f 94 c2 85 db 0f 94 c0 08 c2 74 08 <0f> 0b cc 01 d0 56 2b c0 8b 41 30 89 da b9 04 00 00 00 5b e9 5e
EIP: [<c01966c6>] sysfs_create_file+0x19/0x31 SS:ESP 0068:cb5f1eb8

Quoted 2 lines · Joern Quillman

Quoted 2 lines

Quoted 2 lines

One problem left. I still can't set or unset the flag with echo even on 2.6.19-rc6 (as root).

...

Quoted 10 lines

Permissions of the file are -rw-r--r--. Owner is of course root. As I wrote before I can set/unset the flag without any problems when I connect a dumb USB<->IDE
converter with kernel 2.6.18. Same with 2.6.19-rc6.

The complete error message (sorry it's in german here) is:
"-bash: echo: write error: Das Argument ist ungueltig"

Is there a way to do some debug on the internals to see why the attribute isn't actually writeable? Do you need parts of the kernel log?

The responsible kernel code is drivers/scsi/sd.c::sd_store_allow_restart().

static ssize_t sd_store_allow_restart(struct class_device *cdev, const char *buf,
size_t count)

{
	struct scsi_disk *sdkp = to_scsi_disk(cdev);
	struct scsi_device *sdp = sdkp->device;

	if (!capable(CAP_SYS_ADMIN))
		return -EACCES;

	if (sdp->type != TYPE_DISK)
		return -EINVAL;

	sdp->allow_restart = simple_strtoul(buf, NULL, 10);

	return count;
}

I think the solution is easy: Replace if (sdp->type != TYPE_DISK) by

	if (sdp->type != TYPE_DISK && sdp->type != TYPE_RBC)

... but why have the condition at all? What other peripheral device type should the _sd_ driver be handling??

Quoted 2 lines · Douglas Gilbert

... but why have the condition at all? What other peripheral device type should the _sd_ driver be handling??

The original patch was for some IBM ipr array that behaves stupidly and requires a START_UNIT after a reset. I suspect this was the reason the type check was in there. However, if there's a use for this outside the particular array, then it should be taken out.

Note that there may be a bit of work necessary to make this function for
USB: it's keyed to the standard response CC/UA/LOGICAL UNIT NOT READY, INITIALIZING COMMAND REQUIRED. Since USB devices aren't necessarily standards compliant in this regard, simply setting the bit may not work.

Quoted 3 lines · Stefan Richter

I think the solution is easy: Replace if (sdp->type != TYPE_DISK) by

	if (sdp->type != TYPE_DISK && sdp->type != TYPE_RBC)

... but why have the condition at all? What other peripheral device type should the _sd_ driver be handling??

Quoted 2 lines

Is there a way to do some debug on the internals to see why the attribute isn't actually writeable? Do you need parts of the kernel log?

The responsible kernel code is drivers/scsi/sd.c::sd_store_allow_restart().

static ssize_t sd_store_allow_restart(struct class_device *cdev, const

I think the solution is easy: Replace if (sdp->type != TYPE_DISK) by

	if (sdp->type != TYPE_DISK && sdp->type != TYPE_RBC)

As you can see further below in your log, most SBP-2 disks implement the RBC command set, i.e. are a somewhat special kind of SCSI HDD. I suppose I grabbed one of the rare SBP-2 disks which pose as TYPE_DISK when I tested to write to the allow_restart attribute.

I will try this modification here too and send a proper patch to the list if my line of thinking is correct.

Quoted 3 lines

sd 0:0:0:0: Attached scsi disk sda
ieee1394: sbp2: Error logging into SBP-2 device - timed out
sbp2: probe of 0001d20000093c4d-0 failed with error -16

This should not be a problem per se, although it won't be possible to actually use the disk after a login failure of course.

I see from the GUIDs that the bridges were made by MacPower. They used to build them with the fine Oxford Semi SBP-2 bridges only, but some time ago they also used Prolific PL3507 for IEEE 1394A + USB 2.0 combo devices. I have 3 Oxford based MacPower enclosures and 1 Prolific based, and the latter behaves quite crappy. I get a lot of login failures on a 1394b host and occasional login failures on a 1394a host. Somebody else with, I believe, the same device as mine could fix this with a firmware update from http://www.prolific.com.tw/eng/downloads.asp?ID=44 (site is down right now, once again).

You said you have OXFW bridges, but do you know this from looking at the chips or merely from a spec sheet?

Quoted 3 lines

------------[ cut here ]------------
kernel BUG at fs/sysfs/file.c:460!

invalid opcode: 0000 [#1]

Quoted 4 lines

Code: 83 c0 74 e8 65 08 10 00 89 e8 83 c4 10 5b 5e 5f 5d c3 85 c0 89 c1

53 89 d3 74 10 83 78 30 00 0f 94 c2 85 db 0f 94 c0 08 c2 74 08 <0f> 0b cc 01 d0 56 2b c0 8b 41 30 89 da b9 04 00 00 00 5b e9 5e
EIP: [<c01966c6>] sysfs_create_file+0x19/0x31 SS:ESP 0068:cb5f1eb8

Hmm. This is not good. Maybe the ieee1394 driver received garbage data from the device's configuration ROM and sysfs blew up subsequently. I'm not sure if this is a realistic scenario and if so, which kinds of sanity checks might be missing in ieee1394. I'll check this eventually... Although if you can reproduce this bug, I could send you a patch with a bunch of printk's to narrow the offending sysfs attribute down.

Quoted 5 lines · Stefan Richter

Quoted 2 lines

ieee1394: sbp2: Error logging into SBP-2 device - timed out
sbp2: probe of 0001d20000093c4d-0 failed with error -16

This should not be a problem per se, although it won't be possible to actually use the disk after a login failure of course.

The remaining disks were not found too.

Quoted 3 lines

if you can reproduce this bug, I could send you a
patch with a bunch of printk's to narrow the offending sysfs attribute down.

Sure no problem. I'll test it asap.
Would be great to get a solution for this too. Kinda unfunny to always have the external disks running before the system boots.