Path: utzoo!censor!isgtec!bmw From: bmw@isgtec.UUCP (Bruce Walker) Newsgroups: comp.protocols.tcp-ip.ibmpc Subject: Re: Some questions about new(?) KA9Q (FAT-trash revealed!) Keywords: tcp/ip ka9q hosts internet-addresses Clarkson packet driver Message-ID: <129@isgtec.UUCP> Date: 29 Aug 89 17:08:55 GMT Reply-To: bmw@isgtec.UUCP (Bruce Walker) Distribution: na Organization: I.S.G. Technologies, Toronto, Ontario Lines: 38 Bruce Walker: (me) >> The environment: >> - floppies (I'm really paranoid since experimenting with this stuff has >> resulted in trashed FAT's now and then!) Phil Karn: > I am very concerned about your report of FAT-trashing. This is the first > such report I've received, and if you can isolate the problem I would > very much appreciate the details. Be sure you start with the latest > code. Sorry about the delay ... I better clarify; I don't wish to start rumours. Summary: 1) my problem was NOT caused by KA9Q code. 2) my problem WAS caused by bad handling of args by Clarkson packet driver. I had been having some troubles getting two PC's to talk SLIP to each other. While fiddling around, I thought "maybe there is no 8250 code in here" (meaning net.exe) and so I tried loading the 8250 packet driver from Clarkson. Well I didn't fully understand the command line syntax, particularly the first argument, so I invoked it like this: slip8250 sl0 slip 3 0x2f8 9600 ^^^ and my machine hung with the hard disk led on. After reboot I had the dreaded cross-linked clusters on some files (luckily expendable). My prognosis is that the Clarkson packet drivers are negligent in their parsing of arguments and managed to turn "sl0" into a number (!) which became the interrupt vector to take over (maybe int zero?). Zang! I don't take kindly to software that causes this sort of minor disaster so I have been using extreme caution since. -- Bruce Walker ...uunet!mnetor!lsuc!isgtec!bmw "Better Living Through Connectivity" ...utzoo!lsuc!isgtec!bmw ISG Technologies Inc. 3030 Orlando Dr. Mississauga. Ont. Can. L4V 1S8