Hi,
I get the above message frequently while copying data (around 200000 mail
files, 2GB) from my laptop to an external harddisk via ieee1394. The ieee
system completely deadlocked with 2.6.13 without the chance to umount or
reuse the device. Now I upgraded to 2.6.14-rc5 and I still get the error
followed by a 10sec pause or so, but then the copying continues. I will have
to check if it copied all data correctly, though.
When attaching the device this is what the kernel says:
kernel: ieee1394: Current remote IRM is not 1394a-2000 compliant, resetting...
kernel: ieee1394: Error parsing configrom for node 0-00:1023
kernel: ieee1394: Node changed: 0-00:1023 -> 0-01:1023
kernel: ieee1394: Node added: ID:BUS[0-00:1023] GUID[0000000e000031d1]
kernel: scsi1 : SCSI emulation for IEEE-1394 SBP-2 Devices
kernel: ieee1394: sbp2: Logged into SBP-2 device
kernel: ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
kernel: Vendor: WDC WD20 Model: 00JB-00GVC0 Rev:
kernel: Type: Direct-Access-RBC ANSI SCSI revision: 04
kernel: Attached scsi generic sg0 at scsi1, channel 0, id 0, lun 0, type 14
kernel: SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB)
kernel: sda: asking for cache data failed
kernel: sda: assuming drive cache: write through
kernel: SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB)
kernel: sda: asking for cache data failed
kernel: sda: assuming drive cache: write through
kernel: sda: sda1 sda2 sda3 sda4
kernel: Attached scsi disk sda at scsi1, channel 0, id 0, lun 0
And the complete error message:
kernel: ieee1394: sbp2: sbp2util_node_write_no_wait failed.
kernel:
kernel: ieee1394: sbp2: aborting sbp2 command
kernel: scsi1 : destination target 0, lun 0
kernel: command: cdb[0]=0x2a: 2a 00 09 76 04 73 00 00 01 00
kernel: ieee1394: sbp2: sbp2util_node_write_no_wait failed.
kernel:
kernel: ieee1394: sbp2: aborting sbp2 command
kernel: scsi1 : destination target 0, lun 0
kernel: command: cdb[0]=0x2a: 2a 00 08 5f 83 54 00 00 01 00
[lots more of that, the command hex code changes everytime]
I have a preemt kernel:
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
and the 1000hz timer:
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_PHYSICAL_START=0x100000
and the following is the ieee config:
CONFIG_IEEE1394=m
CONFIG_IEEE1394_OHCI1394=m
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_SBP2=m
CONFIG_IEEE1394_SBP2_PHYS_DMA=y
# CONFIG_IEEE1394_ETH1394 is not set
CONFIG_IEEE1394_DV1394=m
CONFIG_IEEE1394_RAWIO=m
# CONFIG_IEEE1394_CMP is not set
Please tell me if you need more info, I'd like to provide all the help needed
to fix this issue.
Cheers,
--
Michael Brade; KDE Developer, Student of Computer Science
|-mail: echo brade !#|tr -d "c oh"|s\e\d 's/e/\@/2;s/$/.org/;s/bra/k/2'
?--web: http://www.kde.org/people/michaelb.html
KDE 3: The Next Generation in Desktop Experience
Michael> I get the above message frequently while copying data (around
Michael> 200000 mail files, 2GB) from my laptop to an external
Michael> harddisk via ieee1394. The ieee system completely deadlocked
Michael> with 2.6.13 without the chance to umount or reuse the
Michael> device. Now I upgraded to 2.6.14-rc5 and I still get the
Michael> error followed by a 10sec pause or so, but then the copying
Michael> continues. I will have to check if it copied all data
Michael> correctly, though.
One thing I suggest right off the bat is to make sure that firmware on
your external enclosure is updated to the latest/greatest. Alot of
vendors (esp those using the Prolific chipset) don't get it right
initially.
Other than that, at least it's recovering better now and not locking
up!
John
On Monday 24 October 2005 16:03, John Stoffel wrote:
> Michael> I get the above message frequently while copying data (around
> Michael> 200000 mail files, 2GB) from my laptop to an external
> Michael> harddisk via ieee1394. The ieee system completely deadlocked
> Michael> with 2.6.13 without the chance to umount or reuse the
> Michael> device. Now I upgraded to 2.6.14-rc5 and I still get the
> Michael> error followed by a 10sec pause or so, but then the copying
> Michael> continues. I will have to check if it copied all data
> Michael> correctly, though.
Ok, update and good news: it did actually copy the files properly, reading and
checking worked without errors.
> One thing I suggest right off the bat is to make sure that firmware on
> your external enclosure is updated to the latest/greatest. Alot of
> vendors (esp those using the Prolific chipset) don't get it right
> initially.
Good guess and damn, yes, I've got the Icy Box IB-351-UE which has the
prolific chipset, I guess it's the (cursed) PL3507. [The IcyBox FAQ says:
IB-350/351/360UE Prolific (PL3507) - Agere (FW8028)]
However, I've read that they had problems in 2004 and that all new devices
(starting from October 2004) have the updated firmware already.
I have also found some of your posts from 2004 on lkml about the prolific
chipset, actually anything I found is mostly from 2004 :-/
So sorry for the dumb question, but do I check if I've got the newest firmware
without windows? I had a look at http://www.icybox.de but found no firmware for
ib-351, only for ib-350 and that one is from Dec 2004.
And even if I've got the newest firmware already, does the prolific stuff work
by now or should I chuck it out the window?
> Other than that, at least it's recovering better now and not locking
> up!
Yes, which makes the thing at least usable now :-) But it still takes forever
since it happens every 30-120 seconds. And just now the HD started making
*really* strange noises after I let it sit there idle for 10-20 minutes or
so. The I quickly read some files and it stopped. I'm scared of my data...
Thanks for your help,
--
Michael Brade; KDE Developer, Student of Computer Science
|-mail: echo brade !#|tr -d "c oh"|s\e\d 's/e/\@/2;s/$/.org/;s/bra/k/2'
?--web: http://www.kde.org/people/michaelb.html
KDE 3: The Next Generation in Desktop Experience
>>>>> "Michael" == Michael Brade <[email protected]> writes:
>> One thing I suggest right off the bat is to make sure that firmware on
>> your external enclosure is updated to the latest/greatest. Alot of
>> vendors (esp those using the Prolific chipset) don't get it right
>> initially.
Michael> Good guess and damn, yes, I've got the Icy Box IB-351-UE
Michael> which has the prolific chipset, I guess it's the (cursed)
Michael> PL3507. [The IcyBox FAQ says: IB-350/351/360UE Prolific
Michael> (PL3507) - Agere (FW8028)]
I've got the same box, and I've given up on the firewire side of
things and I just use the USB port now. But it's just my backup box,
so I don't really use it too much.
Michael> However, I've read that they had problems in 2004 and that
Michael> all new devices (starting from October 2004) have the updated
Michael> firmware already.
Check anyway... I think I posted recently about my luck in getting the
USB side working with 2.6.12+ once I updated the firmware on the
chipset, which was a pain.
Michael> I have also found some of your posts from 2004 on lkml about
Michael> the prolific chipset, actually anything I found is mostly
Michael> from 2004 :-/
Yeah, from what I've been reading, the Prolific chipset sucked even
for Windows users, at least until the latest firmware. Goto these
pages:
http://tech.prolific.com.tw/visitor/v_filebrw_result.asp
http://forum.rpc1.org/viewtopic.php?t=25140&postdays=0&postorder=asc&&start=25&sid=6801466c15ef74f35a490bbdb423cf37
The second one is a forum which had some useful info.
Michael> So sorry for the dumb question, but do I check if I've got
Michael> the newest firmware without windows? I had a look at
Michael> http://www.icybox.de but found no firmware for ib-351, only for
Michael> ib-350 and that one is from Dec 2004.
You need to go by chipset, not by enclosure. I poked on my system,
but there's nothing obvious about how to get the firmware level in the
output of 'lsusb'. Sorry.
Michael> And even if I've got the newest firmware already, does the
Michael> prolific stuff work by now or should I chuck it out the
Michael> window?
It works with USB, I don't know about firewire since I've just chucked
that for now. Which is why I got the dual input setup, USB/Firewire.
Haven't tried the firewire on a Windows box either since the upgrade,
might one of these days, but I'm in no rush.
John
On Monday 24 October 2005 21:48, John Stoffel wrote:
> Yeah, from what I've been reading, the Prolific chipset sucked even
> for Windows users, at least until the latest firmware. Goto these
> pages:
>
> http://tech.prolific.com.tw/visitor/v_filebrw_result.asp
> http://forum.rpc1.org/viewtopic.php?t=25140&postdays=0&postorder=asc&&star
>t=25&sid=6801466c15ef74f35a490bbdb423cf37
>
> The second one is a forum which had some useful info.
Thank you so much for your help! It probably won't make my device work with
ieee1394 out of the blue but it sure got me out of my ignorance!
> Michael> And even if I've got the newest firmware already, does the
> Michael> prolific stuff work by now or should I chuck it out the
> Michael> window?
>
> It works with USB
Ok, I will try that then. I have only USB 1.1 on my laptop so I guess either
I'll get rid of the icy box (what a name..) or get a USB 2.0 PCMCIA card.
Cheers,
--
Michael Brade; KDE Developer, Student of Computer Science
|-mail: echo brade !#|tr -d "c oh"|s\e\d 's/e/\@/2;s/$/.org/;s/bra/k/2'
?--web: http://www.kde.org/people/michaelb.html
KDE 3: The Next Generation in Desktop Experience
On Monday 24 October 2005 21:48, John Stoffel wrote:
> It works with USB, I don't know about firewire since I've just chucked
> that for now. Which is why I got the dual input setup, USB/Firewire.
> Haven't tried the firewire on a Windows box either since the upgrade,
> might one of these days, but I'm in no rush.
Ok, just a little update as it might be interesting for others, too: yesterday
a friend came surprisingly to my place because his server didn't work
properly (we worked till 4am...) and he brought a windows laptop! So I
searched a bit more and found a new firmware for the PL3507, dated September
2005, and flashed it.
But, alas, to no avail. The problem persists, when writing to the HD I get the
above error and the hd/kernel hangs for some time until it resumes. So my
guess is, this might really be a bug in our kernel and not the firmware?
And I haven't even mentioned yet that I have a DVD writer in an icybox as
well, I flashed this one too but still can't even *read* from any CD/DVD.
There the kernel hangs itself for a while and prints
kernel: ieee1394: sbp2: aborting sbp2 command
kernel: scsi3 : destination target 0, lun 0
kernel: command: cdb[0]=0x28: 28 00 00 00 10 6f 00 00 01 00
kernel: ieee1394: sbp2: aborting sbp2 command
kernel: scsi3 : destination target 0, lun 0
kernel: command: cdb[0]=0x0: 00 00 00 00 00 00
kernel: ieee1394: sbp2: reset requested
kernel: ieee1394: sbp2: Generating sbp2 fetch agent reset
kernel: ieee1394: sbp2: aborting sbp2 command
kernel: scsi3 : destination target 0, lun 0
kernel: command: cdb[0]=0x0: 00 00 00 00 00 00
kernel: ieee1394: sbp2: reset requested
kernel: ieee1394: sbp2: Generating sbp2 fetch agent reset
kernel: ieee1394: sbp2: aborting sbp2 command
kernel: scsi3 : destination target 0, lun 0
kernel: command: cdb[0]=0x0: 00 00 00 00 00 00
kernel: ieee1394: sbp2: reset requested
kernel: ieee1394: sbp2: Generating sbp2 fetch agent reset
kernel: ieee1394: sbp2: aborting sbp2 command
kernel: scsi3 : destination target 0, lun 0
kernel: command: cdb[0]=0x0: 00 00 00 00 00 00
kernel: scsi: Device offlined - not ready after error recovery: host 3 channel
0 id 0 lun 0
kernel: sr 3:0:0:0: SCSI error: return code = 0x50000
kernel: end_request: I/O error, dev sr0, sector 16828
kernel: Buffer I/O error on device sr0, logical block 4207
kernel: scsi3 (0:0): rejecting I/O to offline device
Oh well. For now I most definitely have to look for the USB alternative.
Cheers,
--
Michael Brade; KDE Developer, Student of Computer Science
|-mail: echo brade !#|tr -d "c oh"|s\e\d 's/e/\@/2;s/$/.org/;s/bra/k/2'
?--web: http://www.kde.org/people/michaelb.html
KDE 3: The Next Generation in Desktop Experience
Alright, very bad news:
On Monday 24 October 2005 21:48, John Stoffel wrote:
> Yeah, from what I've been reading, the Prolific chipset sucked even
> for Windows users, at least until the latest firmware.
Because of this I gave my prolific stuff back (they actually took it back,
great) and got an Oxford 911. I *STILL* get the same kind of errors though!
Here's what the syslog says again:
kernel: ieee1394: The root node is not cycle master capable; selecting a new
root node and resetting.
kernel: ieee1394: Error parsing configrom for node 0-00:1023
kernel: ieee1394: Node changed: 0-00:1023 -> 0-01:1023
kernel: ieee1394: Node added: ID:BUS[0-00:1023] GUID[0030e001e0454647]
kernel: SCSI subsystem initialized
kernel: sbp2: $Rev: 1306 $ Ben Collins <[email protected]>
kernel: ieee1394: sbp2: Driver forced to serialize I/O (serialize_io=1)
kernel: ieee1394: sbp2: Try serialize_io=0 for better performance
kernel: scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices
kernel: ieee1394: sbp2: Logged into SBP-2 device
kernel: ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
kernel: Vendor: WDC WD20 Model: 00JB-00GVC0 Rev: 08.0
kernel: Type: Direct-Access-RBC ANSI SCSI revision: 04
kernel: SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB)
kernel: sda: asking for cache data failed
kernel: sda: assuming drive cache: write through
kernel: SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB)
kernel: sda: asking for cache data failed
kernel: sda: assuming drive cache: write through
kernel: sda: sda1 sda2 sda3 sda4
kernel: Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
kernel: XFS mounting filesystem sda1
kernel: Ending clean XFS mount for filesystem: sda1
kernel: XFS mounting filesystem sda2
kernel: Ending clean XFS mount for filesystem: sda2
kernel: ieee1394: sbp2: sbp2util_node_write_no_wait failed.
kernel:
kernel: ieee1394: sbp2: aborting sbp2 command
kernel: scsi0 : destination target 0, lun 0
kernel: command: cdb[0]=0x2a: 2a 00 06 48 37 51 00 00 01 00
kernel: ieee1394: sbp2: sbp2util_node_write_no_wait failed.
kernel:
kernel: ieee1394: sbp2: aborting sbp2 command
kernel: scsi0 : destination target 0, lun 0
kernel: command: cdb[0]=0x2a: 2a 00 06 95 d7 31 00 00 01 00
kernel: ieee1394: sbp2: sbp2util_node_write_no_wait failed.
kernel:
kernel: ieee1394: sbp2: aborting sbp2 command
kernel: scsi0 : destination target 0, lun 0
kernel: command: cdb[0]=0x2a: 2a 00 06 9b 52 c1 00 00 01 00
kernel: ieee1394: sbp2: sbp2util_node_write_no_wait failed.
kernel:
kernel: ieee1394: sbp2: aborting sbp2 command
kernel: scsi0 : destination target 0, lun 0
kernel: command: cdb[0]=0x2a: 2a 00 06 9c 3a a1 00 00 01 00
kernel: ieee1394: sbp2: sbp2util_node_write_no_wait failed.
kernel:
kernel: ieee1394: sbp2: aborting sbp2 command
kernel: scsi0 : destination target 0, lun 0
kernel: command: cdb[0]=0x2a: 2a 00 06 3f 17 80 00 00 01 00
I'm running kernel 2.6.14-rc5. Does anyone have any ideas about how to fix
this? Is anybody actually using a harddisk on ieee1394 without problems?
Please CC me on replies, thanks.
Thanks,
--
Michael Brade; KDE Developer, Student of Computer Science
|-mail: echo brade !#|tr -d "c oh"|s\e\d 's/e/\@/2;s/$/.org/;s/bra/k/2'
?--web: http://www.kde.org/people/michaelb.html
KDE 3: The Next Generation in Desktop Experience