Stefan Richter wrote:
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.
Hehe problem solved I think (or hope).
I'll test it too when applying your patch (see last paragraph).
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.
The remaining disks were not found too.
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?
I know it because I actually bought them after doing a lot of research
about the quality of different IEEE1394 bridges and Oxfords were said to
be just the best ones.
I bought a bunch of old MacPower bridges (the OXFW911 bridges with blue
PCB and capacity limit of 128GB) on ebay. Got 3 plain OXFW911 bridges
and 1 with an Initio USB2.0 companion chip additionally to the OXFW911
for a few euros.
Took me a whole night to get the "Oxsemi Uploader" Java tool for
firmware updating and the 4.0 firmware for those bridges.
Now it says:
(Currently Running 13:59:47 Oct 15 2004 (v 4.0) firmware.)
And thanks to some voodoo in this firmware I can use up to 160GB drives
with those bridges. Thats the reason I bought them so my old drives
don't go to waste.
------------[ cut here ]------------
kernel BUG at fs/sysfs/file.c:460!
invalid opcode: 0000 [#1]
...->
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.
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.
Thank's a lot for your help and patience so far
Joern
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
