SCSI disc error

I was in the middle of processing about 500MB of data using RISC OS on the Beagleboard when I got an error during an OS_GBPB call for writing bytes to the file. The error number was &201C3 with description “Target error – medium error”. Having failed to find anything about this error in the PRMs or StrongHelp, I found an old manual for Acorn SCSI which lists this error number but does not really help me understand what to do about it or what might be the cause.

The application was processing the data and writing it out to any one of about 4000 different files, and only 20 of those were open at the time of the error. It was also reading from several input files, one of which was 500MB and another 900MB. So what I’m saying is that there are a lot of places to check if it was some sort of disc level error!

The files are all on a USB hard drive attached to the Beagleboard. Obviously I can go back and put some more logging in the application so that I can find out what file it was attempting to read or write at the time, but as the processing ahd taken several hours to get to thsi stage, it’s a bit of a nuisance! I’m used to OS_GBPB being 100% reliable usually, barring the disc filling up, so this was unexpected.

Does anyone have any experience of this error and knows what causes it, or what is the best response for an application to take?

The usual response to a read or write error is simply to repeat the read or write and if you get an error again and again then you are stuffed.

Have you considered doing the same operations on an SD card using SDFS? That, at least, cuts out the more generic USB interface as a possible source of error. It is also likely to be faster.

Matthew:

“Target error – medium error”

Unfortunately this is a generic catch-all error for when something happened but there isn’t better reporting to say what. It can be the device didn’t respond in time, it responded in an unexpected way, or there is some sort of low level corruption. I used to get this from time to time with my tape streamer – there was never a specific cause, I figure “the phase of the moon” was a good explanation as I’d retension the tape and restart the backup task and it would work fine.

As Chris says – if you get an error, just retry it. I’d be inclined to wait a second first. If you still get the error, then you fault it.

Chris:

It is also likely to be faster.

I’m not sure his description (4000 different files, big wodges of data, etc) is a setup that is going to be particularly flash-friendly. What might work, and be fast, is if Matthew could get the source files on the SD card, and write the processed results to the harddisc. Then you are reading from one media on one interface, and writing to another on another. That’s how I do video edits/transcodes on my PC – I used to read and write the same SD, but now I go from SD (source media, my PVR writes to SD) to a USB harddisc. Even though both hang off USB, that arrangement is notably faster for quick edit jobs that don’t require a full transcode.

Thanks! I have put some code in to reattempt the write five times at 0.1s intervals. The data processing is rerunning as I type but is currently estimating 22 hours for completion. As yet we have not had a recurrence of the error: I am now logging all occurrences with details of the file name, file pointer position and so on.

It’s an interesting suggestion to do the input and output to different file systems. In my case the problems are that I do not yet have SDFS as I have not upgraded the OS recently, plus as Rick points out it is rather read-write intensive. The first pass over the data involves reading 500MB from a single input file and producing several index files, some of which end up larger than the original. To build some of the index files I have to reference the earlier index files so there would need to be quite a bit of shifting about if they were to be kept on separate file systems. In the second pass the splitting into the final 4000 output files occurs, with reference to the original file and all the index files. I have sped things up now by managing to get the largest index file into a form which will fit in RAM, and I have a few other ideas for optimisations.

Hello, this thread seems to be similar to the problem that I’m having….

I have a Sonnics 120GB 2.5 inch External Pocket Sized USB Hard Drive that is running off a powered USB hub and connected to my Pi. I’m using this as a back up for the my Pi and my Risc PC via ShareFS.

It used to work great, but fairly recently (Apologies I can’t give you a start date to this problem) I keep getting errors when I try to read or write to it.

Maybe the easiest way to start is to post up the current error captured by Reporter:

[Reporter/2D00397C] Exec
20:28:22.84 TaskInit &2D00397C Reporter
[SCSIFiler/SCSI Filer] %Filer_OpenDir SCSI::BackUp.$
[RAMFSFiler/RAMFS Filer] %Filer_OpenDir RAM::RamDisc0.$
20:28:53.81 TaskClose &2D203980
[WindowManager/] Filer_Action
[WindowManager/] *WimpSlot -min 40k -max 40k
[Filer_Action/2D403980] Exec
20:29:16.83 * Error *
Error : &80000002
Message: Internal error: abort on data transfer at &FC1DD63C
20:29:16.87 * Error *
Error : &00800E07
Message: Internal error, no stack for trap handler: Internal error: abort on data transfer at &FC1DD63C, pc = FC19C7CC: registers at 203D045C
20:29:16.91 * WimpError ** from unknown task
Error : &00800E07
Message: Internal error, no stack for trap handler: Internal error: abort on data transfer at &FC1DD63C, pc = FC19C7CC: registers at 203D045C
[WindowManager/Filer Action Window] Exec
20:29:20.24 TaskClose &2D403980 Filer Action Window
[WindowManager/] Exec

Reporter 2.67 (14 Aug 2012) Listed 20 lines

I have reinstalled the Rom and Harddrive files several times and this problem keeps coming back (Possibly here to stay?)

This problem is happening all the time now after a period (Once again I can’t give you an exact date) of it working well. Can anyone help? If you want me to try any tests which I can report back with I’m willing to do this. Thanks.

Simon: your symptoms look like classic power supply problems. Try a different power supply (preferably with higher current rating).

I’ve come across several power supplies, for different equipment, whose current limit falls over time.

Hello Dave,

The current PSU I’m using is a 5V 1500mA model bought from the Pi Hut. I have tried another PSU (700mA) just in case the original one was failing as you suggested, unfortunately it’s the usual story with this second PSU, file transfer works for a bit then error:

[Reporter/2C603980] Exec
10:15:54.00 TaskInit &2C603980 Reporter
10:16:24.69 TaskClose &2B603974 Filer Action Window
[WindowManager/] Exec
10:54:29.56 TaskClose &2BE0397C Filer Action Window
[WindowManager/] Exec
10:54:54.45 TaskClose &2C803974
[WindowManager/] Filer_Action
[WindowManager/] *WimpSlot -min 40k -max 40k
[Filer_Action/2CA03974] Exec
10:55:24.86 * Error *
Error : &80000002
Message: Internal error: abort on data transfer at &FC1DD63C
10:55:24.90 * Error *
Error : &00800E07
Message: Internal error, no stack for trap handler: Internal error: abort on data transfer at &FC1DD63C, pc = FC19C7CC: registers at 2031E45C
10:55:24.95 * WimpError * from unknown task
Error : &00800E07
Message: Internal error, no stack for trap handler: Internal error: abort on data transfer at &FC1DD63C, pc = FC19C7CC: registers at 2031E45C
[WindowManager/Filer Action Window] Exec
10:55:30.42 TaskClose &2CA03974 Filer Action Window
[WindowManager/] Exec
10:55:30.50 * WimpError ** from Filer
Error : &00011AA0
Message: FileCore in use
[Filer/Filer] Exec

The powered USB hub is a 10 port 2000mA model. If it really is a bad PSU then I own both of them.

FileCore in use is shown at the end of this error list, when I see that it’s usually time for a reboot.

Unfortunately, it’s dubious whether 700 mA is really enough for a Pi anyway.

I don’t know what your cabling arrangements for powering the Pi are. In some cases the resistance of the cables, rather than the PSU’s current capability, can be the cause.

It’s also possible that something else entirely is doing it. I’ve never experienced the symptoms you describe, so I may not be able to help further, sorry.

Message: Internal error: abort on data transfer at &FC1DD63C

It seems to be starting with this. Do you know what it at this address?

If you go to the command line and enter *Modules (best in a TaskWindow, if you can get that far), you will see a list of modules with their base addresses and workspace. Of the module base addresses, one should cover that address. I’m just wondering what exactly it is that is failing.

Hello Rick,

A snippet from *modules:

• 20 FC1D4398 20009BD4 Portable
• 21 FC1D4C74 20009DB4 RTSupport
• 22 FC1D7F60 2000C474 USBDriver
• 23 FC1E3D60 20010CD4 DWCDriver
• 24 FC1F9E54 20022BF4 VCHIQ

It looks like the address exists in the USBDriver module (If I’m reading it correctly).

The current PSU I’m using is a 5V 1500mA model bought from the Pi Hut.
I have a Sonnics 120GB 2.5 inch External Pocket Sized USB Hard Drive that is running off a powered USB hub

That’s the hub that does not provide enough power. You can use a dual USB cable to get more power… or use another hub.

Hello David,

The powered USB hub is a 10 port 2000mA model, I’m hoping it should be plenty.

When you say the hub does not supply enough power, do you mean the particular brand of hub I own is no good? It’s a Trust 10 Port USB 2.0 Power Hub available on Amazon.

AIUI if a hub (or any other device) follows the USB spec properly they only supply 150mA until it negotiates more, up to a maximum of 500mA. We tested a few hubs a while back and all but one wired the 5V line in to all the USB outputs i.e. they did not comply with the spec. and would supply as much power as the PCB tracks would carry.
Cables can also be the problem, I’ve seen one that dropped a whole VOLT!

When you say the hub does not supply enough power, do you mean the particular brand of hub I own is no good?

Occasionally it happens that a power supply will still work, but not to the limits of its published specification in that it will no longer provide the maximum current that it is specified to. They will provide a lower current just fine. This means they work until a heavy current is demanded, whereupon the output voltage falls.

I’ve seen three that have developed such a fault: one for a 17" monitor, and two others whose purpose I can’t remember.

I must agree David and Chris. It looks like a power supply problem. The spec. of one USB Port is up to 500mA. Any HDs, Surfstick and cardreader are need more and they are delivered with a Y-cable (in USB A (full) and USB A (power only) and out micro/mini) so the devices can use up to 1000mA. The voltage of any Hubs are to small with bigger devices access. Any times the voltage falls under 5V and the transfer chrash.
10Port 2000mA is “underpowered” in my eyes.

Correct: it should work better with an Y-cable.
Most of the time, external hard disc don’t like hubs :)

Hello all,

Lots of feedback here, much appreciated. Possibly the external hard drive may not be ideal for my Pi, but I can consider having a look at the Y cable option. If I solve the problem in the future I will report back. Thanks.

Back again, the Y cable has arrived (The company messed up the order and it took them a while to sort it out) and the Y cable is plugged in and I still have the identical problem as I mentioned above. I have even bought a PiHut powered USB hub as a precaution and I still have the same problem.

Did notice another thread that looks similar, would it help to follow this route?:

https://www.riscosopen.org/forum/forums/11/topics/1965?page=1

I would be happy to send any information to try and sort this out as it’s getting frustrating now.

I think you need to rule out the drive having developed a fault. What format is it?
If FAT then can it be read on a PC?
If not does it have any data you want to get back?
If not format and test on a PC.