[Coco] DW4 problems
Tim Fadden
t.fadden at cox.net
Mon Oct 15 01:59:12 EDT 2012
Jean,
Just a thought. I was testing drive wire by doing dsaves of my hard
drive to a DW disk. I would get read errors after a while, and drop
files. ( about 40 meg worth of data copied) On normal usage, it never
showed up, just on very long copy usage, like backups. I found that it
did not like serial cables longer than 3 feet. I switched to a 3 foot
serial cable, and a long usb cable to the serial to usb converter, and
my problems went away. Just a thought.
Tim Fadden
On 10/14/2012 9:36 PM, Gene Heskett wrote:
> On Sunday 14 October 2012 23:57:54 Aaron Wolfe did opine:
>
>> On Sun, Oct 14, 2012 at 10:25 PM, Bob Devries <devries.bob at gmail.com>
> wrote:
>>> Thanks, Robert.
>>> That worked, but made no difference to the problems. I'm still getting
>>> bad checksums (which seem to be ignored), and time-out, which causes
>>> an ERROR #245.
>>>
>>> @Aaron,
>>> would the fact that I'm running this on a PAL coco3 make any
>>> difference? I'm not sure what the clock2 module does in the drivewire
>>> boot, or whether the clock module is in fact supposed to be for 60Hz
>>> working?
>> I wouldn't think so, the timing for the i/o is based on instruction
>> cycles.. those don't change in a 50hz system do they, same cpu crystal
>> right? Excuse my ignorance, guessing only the video stuff changes but
>> what do I know :)
>>
>> What kind of hard drive are you copying from? I have only the
>> superIDE here, and tests with it seem to work OK but I need to do some
>> more. I know Gene's hdd is an uncommon one... wondering if maybe the
>> DW driver and the hdd driver don't get along in your cases, some
>> timing thing that only rears its head under stressful constant use?
>>
>> Given enough info and time I'm sure we can sort this out and make
>> everything work properly, but I'm having a hard time getting a test
>> case where I can recreate the issue put together so far.
>
> So am I. I hate to have to shotgun every piece in the USB chain just to
> rule it out as that is at least $150 worth of hardware.
>
> As for my HD setup being an odd one, so its scsi, on a TC^3 controller,
> shouldn't be a big deal.
>
> I can do a megaread from either of them in exactly the same time as myram
> can do a megaread, around 11.5 seconds. So far I haven't seen any figures
> on the IDE interfaces that can match that, the last ones quoted on this
> list were about 18 seconds. These drives are so fast (20Mb/sec or more)
> that megaread is basically testing how fast it can move a megabyte from one
> location in ram to a different one, so why does the IDE stuff crawl in
> comparison? I don't know.
>
> The last time I tried to backup one of these drives using my basic09
> version of dd, it got to 68 megabytes according to drivewire before it
> timed out.
>
> But when I looked at the disk image with ls -l, the image on the disk was
> only 25 bytes long, and could not be remounted by dw once unloaded. So dw
> never even wrote the first sector of about 132,000 sectors it claimed to
> have written at that point. That image was a copy of another file I'm
> still using, renamed, about 4Mb in size, and my dd was supposed to
> completely overwrite it from LSN0 on, so that I would wind up with a
> verbatum copy of that disk as a 1 Gb file on my disk.
>
> Now, this particular kernel seems to have a scheduler problem, and its
> entirely possible in my mind that its poor performance could cause some
> data loss from a usb stream. The way to answer that is probably for me to
> copy over one of the lots newer kernels from my old pclos install, which is
> on a different drive & reboot to it. Those were SMP, PAE and BFS enabled
> and this machine ran a lot snappier.
>
> I may see if I can do that tomorrow.
>
> In the meantime Aaron, I've did the display 1b etc stuff you were doing in
> the video, to /n5, then started a shell on /n5, so it looks like this in a
> proc report:
> {t2|08}/DD/MAXTOR/CMDSINEVERUSE:proc
>
> ID Prnt User Pty Age Tsk Status Signal Module I/O Paths
> ___ ____ ____ ___ ___ ___ _______ __ __ _________ __________________
> 1 0 0 255 255 00 sTimOut 0 00 System <Term >Term >>Term
> 2 1 0 128 128 00 s 0 00 Shell <Term >Term >>Term
> 3 2 0 128 128 00 s 0 00 Shell <N5 >N5 >>N5
> 4 8 0 128 128 02 s 0 00 Proc <t2 >t2 >>t2
> 5 0 0 128 131 00 s 0 00 Shell <W4 >W4 >>W4
> 6 0 0 128 131 00 s 0 00 Shell <W1 >W1 >>W1
> 7 0 0 128 131 00 s 0 00 Shell <W2 >W2 >>W2
> 8 0 0 128 131 00 s 0 00 Shell <t2 >t2 >>t2
> 9 0 0 128 131 00 s 0 00 inetd <W3 >W3 >>W3
>
> But there seems to be no way I can make the gui give me the extra header
> line with the N tabs that you show coming and going automatically.
>
> I've even tried to hook ZTerm to n5 but the only clue is a logged line that
> said dw didn't know what to do with the shell's signon banner.
>
> So how does that work? The video had the dw command line at the bottom of
> the screen clipped off.
>
> Cheers, Gene
More information about the Coco
mailing list