[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