greg@cica.cica.indiana.edu (Gregory TRAVIS) (01/15/91)
My (new, yea!) local Commodore dealer just called me back with some information she finally got out of Commodore Tech support regarding the awful A2091 controller. Now, don't take this as gospel but the dealer said that Commodore has a chip upgrade availavble now for $34.70 that fixes problems with certain 3rd party software. Now, I've never had that problem. My problem is that I STILL cannot use an external drive with the A2091 using Commodore's driver software. For those of you who are unfamiliar with the problem, if you try and hook more than one drive to the 2091, all will appear OK until something goes out there and hammers on both drives simultaneously. At that point the system will hang waiting on the controller which has failed. Commodore will attempt to drag a red-herring in front of you by claiming that the drive you're using does not conform to SCSI specs. This is a blatant lie as I have hooked two Quantum P40s (as orginally shipped from Commodore) to my machine and seen the lock-up. I've also demonstrated the problem with a wide variety of other drives (Miniscribe, Maxtor, CDC wren) that we use routinely around the lab here on other machines without problems. Commodore tech support indicated to my dealer that they were working on the problem but a fix would not be available for some time. Just to cross-check, I called CPU (the dealer from whom I bought the machine a year ago) up in Indianapolis and they had the same story. My local dealer said they called because they were having trouble with external SCSI devices (CD-ROM) attached to an A2091 controller. I would strongly advise people to REFUSE TO BUY any system with the A2091 unless it's thrown in free. This controller was garbage when it was designed years ago and continues to be garbage to this day. -- Gregory R. Travis Indiana University, Bloomington IN 47405 greg@cica.cica.indiana.edu Center for Innovative Computer Applications Disclaimer: Everything I say is true and I never lie.
swarren@convex.com (Steve Warren) (01/15/91)
In article <9696@cica.cica.indiana.edu> greg@cica.indiana.edu (Gregory TRAVIS) writes: [...] >I would strongly advise people to REFUSE TO BUY any system with the >A2091 unless it's thrown in free. This controller was garbage when it >was designed years ago and continues to be garbage to this day. BTW, it wasn't designed "years ago;" it has been out less than 2 years. I don't think you know what you are talking about. Your experience with your controller does not define the universe. I also think you are hearing some "information" that is bogus. Anyway, I think you are foolish to blurt out all the extravagent accusations you presented in this posting without personally verifying it (ie, you let your dealer(s) make the calls and you believed whatever they told you, even if it seemed ridiculous). I have seen too many examples of dealers who are incompetant and try to blame all their problems on Commodore. Their are several experts from Commodore who post technical help here. Have you attempted to contact any of them with these problems? An authentic request for help will get you a lot further than angry flaming denunciations of Commodore and their designs. The Commodore people who participate here are actually quite helpful and friendly if you don't go out of your way to insult them. -- _. --Steve ._||__ DISCLAIMER: All opinions are my own. Warren v\ *| ---------------------------------------------- V {uunet,sun}!convex!swarren; swarren@convex.com
greg@travis.cica.indiana.edu (Gregory TRAVIS) (01/15/91)
swarren@convex.com (Steve Warren) writes: >BTW, it wasn't designed "years ago;" it has been out less than 2 years. I bought my machine one year ago, I assume the controller wasn't designed the day I bought the machine. Ok, perhaps I should have said "over a year ago" >I don't think you know what you are talking about. Your experience with >your controller does not define the universe. I also think you are hearing >some "information" that is bogus. Sorry, I do know what I'm talking about. The problem was originally discovered by me last year. Early last summer a Commodore technical person informed me, on condition of anonymity, that the A2091 controller was indeed suspected of being defective within Commodore. I have duplicated the problem with numerous disk drives, cables, options settings, and, even, different A2091 cards. I have verified that the setup I'm attempting to use works correctly on other machines (I have used the drives and cables in question reliably on Suns, Macintoshes, and NeXTs). I have been working on this problem for quite some time now. >Anyway, I think you are foolish to blurt out all the extravagent accusations >you presented in this posting without personally verifying it (ie, you let >your dealer(s) make the calls and you believed whatever they told you, even >if it seemed ridiculous). I have seen too many examples of dealers who >are incompetant and try to blame all their problems on Commodore. Wrong again. I have attempted to contact Commodore directly a number of times. The one time that they didn't blow me off with "you'll have to go through your dealer for that information, sir" they acknowledged that there was, yes, a problem with the A2091 and my dealer should have the Tech Notes on it Real Soon Now. That was in late September of 1990, a full five months after I reported the problem to Commodore and four months since it had been privately verified to me by a Commodore employee. I, like you, suspected the dealers at first. But when I could not find a SINGLE dealer in Indiana, including CPU which is quite highly regarded by Amiga users, which could get the info from Commodore I began to think the problem might lie with Commodore. >Their are several experts from Commodore who post technical help here. Have >you attempted to contact any of them with these problems? An authentic >request for help will get you a lot further than angry flaming denunciations >of Commodore and their designs. The Commodore people who participate here are >actually quite helpful and friendly if you don't go out of your way to insult >them. Yes I have. This is my fourth posting on this subject. I began with earnest queries last summer to see if anyone else was having trouble with multiple drives. Slowly some users began to contact me and affirm that with higher performance drives there was a problem. I asked again, publicly on the net in September, what was going on since I could not get any information from Commodore or dealers. I was nice both of those two times and (relatively) nice when I posted the list of dealers I had called and their responses last October. All three times were opportunities for Commodore types "in the know" to respond with an explanation of what was going on and what was going to happen about it. I believe that only Andy Finkle even acknowledged my posting. Look, I believe I have been patient. When I first suspected the problem I blamed my setup. But I've heard from too many other people having trouble to think it's my fault. And Commodore is on record as admitting to the problem both when I called tech support and got a response that a fix was coming and in their response to both of the dealers I called today. My machine, for which I paid quite a bit of money (A2500/30, 4MB 32Bit RAM) is now desperately out of warranty. The specs DID advertise that the controller would handle multiple drives - guess I shouldn't trust specs. Why didn't/don't I ask my dealer to exchange my A2091 for a third-party controller? 1) I have this fantasy about running UNIX and I want to make sure the disk controller I have is supported. 2) I don't want to have to pay for another memory board to hold the 2MB I have on the A2091. I bought my first Amiga in 1985 and I think it's a great machine but I'm tired of being jerked around by Commodore. -- Gregory R. Travis Indiana University, Bloomington IN 47405 greg@cica.cica.indiana.edu Center for Innovative Computer Applications Disclaimer: Everything I say is true and I never lie.
jph@ais.org (Joseph Hillenburg) (01/16/91)
In article <9696@cica.cica.indiana.edu> greg@cica.indiana.edu (Gregory TRAVIS) writes: >My (new, yea!) local Commodore dealer just called me back with some >information she finally got out of Commodore Tech support regarding >the awful A2091 controller. Now, don't take this as gospel but the >dealer said that Commodore has a chip upgrade availavble now >for $34.70 that fixes problems with certain 3rd party software. Now, >I've never had that problem. My problem is that I STILL cannot use >an external drive with the A2091 using Commodore's driver >software. > >For those of you who are unfamiliar with the problem, if you try and >hook more than one drive to the 2091, all will appear OK until something >goes out there and hammers on both drives simultaneously. At that >point the system will hang waiting on the controller which has >failed. Commodore will attempt to drag a red-herring in front of you by >claiming that the drive you're using does not conform to SCSI specs. >This is a blatant lie as I have hooked two Quantum P40s (as orginally >shipped from Commodore) to my machine and seen the lock-up. I've also >demonstrated the problem with a wide variety of other drives (Miniscribe, >Maxtor, CDC wren) that we use routinely around the lab here on other >machines without problems. > >Commodore tech support indicated to my dealer that they were working >on the problem but a fix would not be available for some time. > >Just to cross-check, I called CPU (the dealer from whom I bought the >machine a year ago) up in Indianapolis and they had the same story. > >My local dealer said they called because they were having trouble with >external SCSI devices (CD-ROM) attached to an A2091 controller. Seeing as I'm from Bloomington, Indiana, same as you, I thought I'd comment on this... I've talked to the people at Digital Arts, and it didn't work on the A3000 either. The CURRENT problem is the Xetec CD-ROM drivers are screwed. You can run programs off the disk, etc, but you CAN'T copy from it! This happened when they had it hooked up to both the 3000 and 2091. > >I would strongly advise people to REFUSE TO BUY any system with the >A2091 unless it's thrown in free. This controller was garbage when it >was designed years ago and continues to be garbage to this day. > This is pure bullshit. the A2091 is an excellent controller, and is _very_ new. This is the ONLY problem with it (not handling multiple drives correctly...) I have one, it's very fast. It sounds like you are talking about the 2090 series. > > > >-- >Gregory R. Travis Indiana University, Bloomington IN 47405 >greg@cica.cica.indiana.edu Center for Innovative Computer Applications >Disclaimer: Everything I say is true and I never lie. Ever been to a BAUG meeting? -- // Joseph Hillenburg, Secretary, Bloomington Amiga Users Group \X/ joseph@valnet.UUCP jph@irie.ais.org jph@ai.mit.edu "Only Apple could slow down a 68030 chip" --Computer Shopper
dylan@cs.washington.edu (Dylan McNamee) (01/16/91)
In article <greg.663961145@travis> greg@travis.cica.indiana.edu (Gregory TRAVIS) writes: >blgardne@javelin.es.com (Blaine Gardner) writes: > > -But have you turned off reselection on both drives, as suggested by CBM > -personnel on several occasions? This fixed a similar problem for me on > -the A3000. > >Yes. This alleviates the problem somewhat but is a far cry from 100% >rock-solid. > I have a 2091, and have had very similar experience as Mr. Travis. I HAVE turned off reselection from both drives (which bugs me, since reselection is a nice performance enhancement) and still can get the SCSI devices to hang at will. (Just get both of them busy at once, with big loads or saves) I have been in direct contact with more than one person at Commodore, but just as they (there have been 2) seem to understand what's going wrong with my system, I lost track of them, and my mail remains unanswered. (Not that I was expecting such personal help in the first place.) I am convinced that a rom or rom/controller upgrade will fix the problem. (I am at ROM version 5.92, WD controller version PROTO) But my dealer has been very unhelpful in getting this thing fixed. (Seattle has only one dealer, and their tech person is rather rude.) It seems that everyone that got the 2500/30 when it was origionally released (mere months before the 3000!) is in the same boat as myself. Please, anyone on the net that hears of the "official" fix to the multiple drive problem, please inform all of us 2091 users. If there is a specific ROM or WD controller version we are looking for, please let us know. It's really annoying having to "tiptoe" around the system trying to avoid simultaneous disk access to prevent data loss! thanks, dylan -- dylan mcnamee "...I put the Mu in Mother Goose, dylan@cs.washington.edu the Doc in Doctor Seuss..." Young MC
jesup@cbmvax.commodore.com (Randell Jesup) (01/16/91)
In article <greg.663961145@travis> greg@travis.cica.indiana.edu (Gregory TRAVIS) writes: >blgardne@javelin.es.com (Blaine Gardner) writes: > > -But have you turned off reselection on both drives, as suggested by CBM > -personnel on several occasions? This fixed a similar problem for me on > -the A3000. > >Yes. This alleviates the problem somewhat but is a far cry from 100% >rock-solid. Turning off reselection should totally solve the problem. The problem is caused by the WD controller getting interrupted by a drive doing a reselection while the driver is trying set things up for another command or handling a previous interrupt. The earlier WD chips had a different internal state machine which didn't cause any problems; later chips changed their behavior in this situation (unknown to us). Turning off reselection for ALL drives (and that means resetting where all your partitions are, though if you do it right there's no need to reformat/restore) should make the problem go away totally. Some people have made mistakes when trying to turn off reselection by setting it to NO on the drive definition screen, but not selecting the modified drive type and OK in the drive selection screen (then you go to partition drive and put your partitons back where they were - write it all down first!) Then when that's all done, you select save changes to drive. We're working on a fix (new ROMs), hopefully available in the near future. There has been much discussion of this workaround here on the net in the past. Obviously responses from us here at commodore (on a non- official basis) may include information or suggestions that have not made it out to dealers/repair people yet. Personally, I think the A2091 is a really nice unit, and until I recently switched to an A{model deleted}, I was using an A2091 with 2x200Mb drives, a 50Mb drive, a 40Mb drive, and a SCSI tape unit (most of those are now on the other machine). Worked flawlessly, including doing diskcopies between HD partitions while running compiles, or when validating 4 partitions on each 200 meg drive at the same time (can you say "thrash"?) BTW, Commodore is not the only one that has been bitten by that sort of reselection bug in SCSI drivers. In fact, even people using some NCR SCSI chips have been hit by reselection during a command putting the chip in an undefined state. It seems to be a common problem for SCSI chip designers. (See comp.periphs.scsi.) I'm sorry if you feel you've been given a run-around. I severely doubt it was intentional, and was mostly caused by dealers/repair people being further down the information stream (especially since we only fairly recently (3 months? 6 months? I don't remember) figured out what was causing the problem). We try quite hard to support our users and let them know what's happening, including spending a lot of time giving help on the net and by mail when we're not required to. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
jesup@cbmvax.commodore.com (Randell Jesup) (01/16/91)
In article <14480@june.cs.washington.edu> dylan@june.cs.washington.edu (Dylan McNamee) writes: >I have a 2091, and have had very similar experience as Mr. Travis. I >HAVE turned off reselection from both drives (which bugs me, since >reselection is a nice performance enhancement) and still can get the >SCSI devices to hang at will. (Just get both of them busy at once, >with big loads or saves) Hmmm. Are you certain you actually managed to turn off reselection? As I posted before, it's fairly easy to confuse yourself by changing the definition file on the disk, but not actually select the modified definition and save it to the rigid disk block. Maybe I'll whip up a program to verify if a drive has reselection on or off. Please provide more details after you double-check your reselection status. Warning: I hacked this souce to add check_reselect without testing it, though it's pretty simple. The program defaults to reading 68 sectors or so from offset 0 and writing them to the file "rdsk". It's a kindof useful program for mucking with devices at a low-level, originally made for sucking rigid disk blocks off drives for analysis. Error checking is minimal. Other people who have tried turning off reselection and still have problems may wish to try this. All drives must have reselection turned off, one of two won't solve the problem until a new driver is available. If your drives have reselection off, and you still have problems, please send mail to bugs@cbmvax.commodore.com. /* readrdsk.c */ #include <exec/types.h> #include <exec/memory.h> #include <devices/trackdisk.h> #include <devices/hardblocks.h> #include <dos.h> #include <stdlib.h> #include <string.h> #include <stdio.h> /* for lattice */ #include <proto/exec.h> #include <proto/dos.h> void main (argc,argv) int argc; char **argv; { int ret = 20; struct IOStdReq *ior = NULL; struct MsgPort *port = NULL; int opened = FALSE,i; char *mem; BPTR fh = NULL; char *name = "rdsk"; char *device = "scsi.device"; int unit = 6, write = FALSE,start = 0,length=17*4*512; int check_reselect = FALSE; for (i = 1; i < argc; i++) { if (stricmp(argv[i],"device") == 0) device = argv[++i]; else if (stricmp(argv[i],"unit") == 0) unit = atoi(argv[++i]); else if (stricmp(argv[i],"write") == 0) write = TRUE; else if (stricmp(argv[i],"read") == 0) write = FALSE; else if (stricmp(argv[i],"start") == 0) start = atoi(argv[++i]); else if (stricmp(argv[i],"length") == 0) length = atoi(argv[++i]); else if (stricmp(argv[i],"check_reselect") == 0) check_reselect = TRUE; else if (stricmp(argv[i],"?") == 0) { /* defaults to read, scsi.device, unit 6, start 0, length 17*4*512, no check_reselect, file "rdsk". */ printf( "usage: readrdsk [device x] [unit y] [Read|write] [start z] [length q] \\\n" "\t\t [check_reselect] file\n"); exit(0); } else name = argv[i]; } if (!(port = CreatePort(0L,0L))) goto cleanup; if (!(ior = CreateStdIO(port))) goto cleanup; if (i = OpenDevice(device,unit, (struct IORequest *) ior,0L)) { printf("Error %d on device open!\n",i); goto cleanup; } opened = TRUE; if (write) { fh = Open(name,MODE_OLDFILE); if (!fh) { printf("Can't open %s!\n",name); goto cleanup; } if (length == 17*4*512) /* bad but quick test */ { Seek(fh,0,OFFSET_END); length = Seek(fh,0,OFFSET_BEGINNING); } } else { if (!(fh = Open(name,MODE_NEWFILE))) { printf("Can't open %s!\n",name); goto cleanup; } } mem = AllocMem(length,MEMF_CLEAR); if (!mem) { printf("can't allocate mem!\n"); goto cleanup; } if (write) { Read(fh,mem,length); /* no error checking */ } ior->io_Data = (APTR) mem; ior->io_Length = length; ior->io_Offset = start; ior->io_Command = write ? CMD_WRITE : CMD_READ; DoIO((struct IORequest *) ior); if (ior->io_Error) { printf("Error %ld on read/write!\n",ior->io_Error); goto cleanup; } if (!write) { if (Write(fh,mem,length) != length) goto cleanup; } if (check_reselect) { /* assumes you did a read from offset 0! */ if (((struct RigidDiskBlock *) mem)->rdb_Flags & RDBFF_NORESELECT) printf("reselect is disabled\n"); else printf("reselect is enabled\n"); } ret = 0; /* success */ cleanup: if (fh) Close(fh); if (opened) CloseDevice((struct IORequest *) ior); if (ior) DeleteStdIO(ior); if (port) DeletePort(port); if (mem) FreeMem(mem,length); exit(ret); } -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
greg@travis.cica.indiana.edu (Gregory TRAVIS) (01/16/91)
jesup@cbmvax.commodore.com (Randell Jesup) writes: > Turning off reselection should totally solve the problem. The problem is caused > Explanation of the problem and how to fix it deleted. THANK YOU Randell. I'll try your program to test if I've "really" turned off reselection when I get home and let you know. It feels much better that someone has finally acknowledged what's going on. The squeaky wheel gets the grease. > There has been much discussion of this workaround here on the net >in the past. Obviously responses from us here at commodore (on a non- >official basis) may include information or suggestions that have not made it >out to dealers/repair people yet. Personally, I think the A2091 is a really I've been looking at as many articles titled "A2091" as possible and never saw anything other than "Did you turn off reselection, that MAY help" kinds of things. If there was something posted which was more substantive than that I must have missed it and I apologize. >nice unit, and until I recently switched to an A{model deleted}, I was >using an A2091 with 2x200Mb drives, a 50Mb drive, a 40Mb drive, and a SCSI >tape unit (most of those are now on the other machine). Worked flawlessly, >including doing diskcopies between HD partitions while running compiles, or >when validating 4 partitions on each 200 meg drive at the same time (can you >say "thrash"?) > I'm sorry if you feel you've been given a run-around. I severely >doubt it was intentional, and was mostly caused by dealers/repair people >being further down the information stream (especially since we only fairly >recently (3 months? 6 months? I don't remember) figured out what was causing >the problem). We try quite hard to support our users and let them know >what's happening, including spending a lot of time giving help on the net and >by mail when we're not required to. Run-around hardly covers it. The person who initially affirmed the problem to me totally dissappeared e-mail wise (would not respond, etc.) almost immediately. Calls to Commodore were either blown off or referred to mysterious "Tech Reports" that "My dealer SHOULD have" which, as far as I can tell, no dealer has ever received. A real catch-22 situation in which all I got were a bunch of "we can neither confirm nor deny" responses. I believe Dylan Mcnamee describes a similar run-around with his experience and I have received numerous pieces of e-mail from people bemoaning the same (I wish they would have posted!). More than one person (and this is what really surprised me) wrote me that I should "give it up as you won't get any help at all from Commodore, who will deny a problem exists." And, of course, there was the obligatory hate mail from Amiga-Krishnas because I had dared besmirch the machine in public. A cogent explanation of the problem, such as Randell gave, is all I ever wanted from Commodore. Hell, I've been willing to PAY big money for a fix for a long time now. But I couldn't even get that far because no one would own up to a problem. Coming clean initially would have gone a long way towards assuaging a lot of people's complaints. Let me suggest that Commodore do its best to let its dealers know about this - they seem to be totally in the dark. I can't imagine what the poor slob without Usenet access who's got the problem is doing. Why didn't Commodore test for this problem? I discovered it the day I bought my machine. -- Gregory R. Travis Indiana University, Bloomington IN 47405 greg@cica.cica.indiana.edu Center for Innovative Computer Applications Disclaimer: Everything I say is true and I never lie.
rwm@atronx.OCUnix.On.Ca (Russell McOrmond) (01/17/91)
In a message posted on 14 Jan 91 18:08:42 GMT,
greg@cica.cica.indiana.edu (Gregory TRAVIS) wrote:
GT>dealer said that Commodore has a chip upgrade availavble now
GT>for $34.70 that fixes problems with certain 3rd party software. Now,
This is the 6.2 ROM upgrade that fixed the 'location 0 bug' that was in the
older ROMS.
GT>failed. Commodore will attempt to drag a red-herring in front of you by
GT>claiming that the drive you're using does not conform to SCSI specs.
I think you have still mis-understood what they are trying to say.
GT>This is a blatant lie as I have hooked two Quantum P40s (as orginally
GT>shipped from Commodore) to my machine and seen the lock-up. I've also
I myself have done the same on an A2091, and A590 and the machine I am typeing on
right now is an A3000 with two Quantum 40 drives in them, and I have NEVER had a
problem with the drives. I quite often copy entire partitions from one drive to the
other, as well as running a duel-network server (Fidonet and UUCP) in the background.
GT>I would strongly advise people to REFUSE TO BUY any system with the
GT>A2091 unless it's thrown in free. This controller was garbage when it
GT>was designed years ago and continues to be garbage to this day.
It is a controller that I will ALWAYS reccomend to others (And as a technician
at a local Amiga Dealership, always do (Even though my BOSS is a big GVP fan, I
still reccomend the A2091 over the GVP products) . I guess you are
intitled to your opinions, but do not be surprised if you are flamed for trying
to spread further mis-information about the controllers.
---
Opinions expressed in this message are my Own. My Employer does not even
know what these networks ARE.
Russell McOrmond rwm@Atronx.OCUnix.On.Ca {tigris,alzabo,...}!atronx!rwm
FidoNet 1:163/109 Net Support: (613) 230-2282
Amiga-Fidonet Support 1:1/109glmwc@marlin.jcu.edu.au (Matt Crowd) (01/17/91)
In article <1991Jan14.193336.13387@convex.com> swarren@convex.com (Steve Warren) writes: >In article <9696@cica.cica.indiana.edu> greg@cica.indiana.edu (Gregory TRAVIS) writes: > [...] >>I would strongly advise people to REFUSE TO BUY any system with the >>A2091 unless it's thrown in free. This controller was garbage when it >>was designed years ago and continues to be garbage to this day. > >BTW, it wasn't designed "years ago;" it has been out less than 2 years. > >I don't think you know what you are talking about. Your experience with >your controller does not define the universe. I also think you are hearing > _. >--Steve ._||__ DISCLAIMER: All opinions are my own. > Warren v\ *| ---------------------------------------------- > V {uunet,sun}!convex!swarren; swarren@convex.com I recieved my 2091 for free and have had problems using it in conjunction with an accelerator, just the other day when i booted it told me i had a read/write error! selecting "retry" continued the bootup. Matt Crowd.
jesup@cbmvax.commodore.com (Randell Jesup) (01/17/91)
In article <greg.664040658@travis> greg@travis.cica.indiana.edu (Gregory TRAVIS) writes: >> Explanation of the problem and how to fix it deleted. > >THANK YOU Randell. I'll try your program to test if I've "really" turned You're welcome. Glad to help. >Let me suggest that Commodore do its best to let its dealers know about >this - they seem to be totally in the dark. I can't imagine what the >poor slob without Usenet access who's got the problem is doing. I'll pass the comment on to the US Sales company/etc. >Why didn't Commodore test for this problem? I discovered it the day >I bought my machine. Normal production tests are single-drive. Many multi-drive configurations were tested during development, and they all worked, since WD hadn't changed their part yet. WD made a running change to fix other problems in the non-A part (stuff we didn't use because it didn't work), and the new A part caused this problem. The non-A parts are no longer available, I understand. After the problem was noticed (and once we got a handle on it), we did a full matrix test of all chip revs/driver revs/boyer revs with different SCSI bus configurations. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
limonce@pilot.njin.net (Tom Limoncelli +1 201 408 5389) (01/23/91)
In article <greg.664556625@travis> greg@travis.cica.indiana.edu (Gregory TRAVIS) writes: > Why is a ROM upgrade starting to smell like an unadulterated KLUDGE? I doubt it. It seems that the newer chips (and the older chips too) aren't broken, they just changed how the chips reacts in certain situations. The new ROM could figure out which chip you have and Do The Right Thing. I think it was mentioned that it would be difficult to come up with code that worked for both chips. (verification that?) Tom -- Headers, headers everywhere! Who needs a .sig?
daveh@cbmvax.commodore.com (Dave Haynie) (01/23/91)
In article <greg.664556625@travis> greg@travis.cica.indiana.edu (Gregory TRAVIS) writes: >clay@na.excelan.com (Clay Jones) writes: >>You need a WD SCSI controller with the same part # but without the "A" on the >>end. I have been using mine A2091 with multiple drives and reselection turned >>on for about 9 months with no problems. >Do we need to order this ourselves or will Commodore buy it for us? Why >do I keep hearing rumors that Commodore is working on a ROM upgrade >to the controller, instead of replacing the WD chip? Let's try this one again: STEP 1: Boyer builds the A2091, plugs in the WD33C93, and Steve proceeds to write the device driver. In the process of this, he discovers that there are some problems in the high level state logic of the WD33C93, but manages to get things working by resorting to some lower level functions. STEP 2: WD discontinues the WD33C93, replacing it with the WD33C93A. This part claims to fix the high level logic, but manages to break the low level logic that Steve used in the A2091 device driver. So reselection breaks. STEP 3: Steve revises the device driver (in the ROM, folks), to use the original functions that are finally corrected, and things work once again. >If I ordered this part from WD, could I just plug it in in place of my current >WD "PROTO" (yes, it says "Prototype" right on the chip) chip? The older part is not available anymore, WD has discontinued it. If you could manage to get hold of one, you could plug in right in place of your WD33C93A, and it would work, you could once again have reselection. A ROM upgrade will achieve the same end, only with the modern version of the SCSI chip. >Why is a ROM upgrade starting to smell like an unadulterated KLUDGE? Because you are confused. Hopefully, this has clarified things. >Gregory R. Travis Indiana University, Bloomington IN 47405 -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "What works for me might work for you" -Jimmy Buffett
jason@cbmami.UUCP (Jason Goldberg) (01/24/91)
In article <17905@cbmvax.commodore.com>, Dave Haynie writes: > Let's try this one again: > > STEP 1: > Boyer builds the A2091, plugs in the WD33C93, and Steve proceeds to > write the device driver. In the process of this, he discovers that > there are some problems in the high level state logic of the WD33C93, > but manages to get things working by resorting to some lower level > functions. > > STEP 2: > WD discontinues the WD33C93, replacing it with the WD33C93A. This part > claims to fix the high level logic, but manages to break the low level > logic that Steve used in the A2091 device driver. So reselection > breaks. > > STEP 3: > Steve revises the device driver (in the ROM, folks), to use the > original functions that are finally corrected, and things work once > again. > This certainly clears things up for me! I will pass the info along, one question though, is it possible for someone to provide the version numbers for the two ROMs which should be used with the WD33C93 and WD33C93A respectively? Also am I correct in assuming that as long as you have one of the correct combinations of WC Chips and ROMS that you can safely use reselection? And that if you don't have the correct combination you should turn off reselection, as an interum (partial) solution until you can get it fixed? On a related (much less important issue), is it true that the ROM which works with the WD33C93A does not change memory location zero, and the one which works with the WD33C93 does change this value? I'm assuming that if you have the older combination that the only work around (for the improperly written software) is to manual set location 0 to 0. Finnaly, if a customer has the old ROM and the old WD chip (so that he is able to have reselection on) is their any reason why he might want to upgrade to the new ROM and new WD chip? Thanks for clearing this up (at least for me) ;- -Jason- --------------------------------------------------------------------------- Jason Goldberg UUCP: ucsd!serene!cbmami!jason Del Mar, CA
clay@na.excelan.com (Clay Jones) (01/25/91)
In article <greg.664556625@travis> greg@travis.cica.indiana.edu (Gregory TRAVIS) writes: >clay@na.excelan.com (Clay Jones) writes: > >>You need a WD SCSI controller with the same part # but without the "A" on the >>end. I have been using mine A2091 with multiple drives and reselection turned >>on for about 9 months with no problems. > >Do we need to order this ourselves or will Commodore buy it for us? Why The non "A" part is no longer produced by WD. You will probably have to get one from a surplus store. >do I keep hearing rumors that Commodore is working on a ROM upgrade >to the controller, instead of replacing the WD chip? If I ordered this The ROM upgrade will work the "A" part which is the only version of the part that WD still makes. I believe the PROTO part is the same as the "A" part. >part from WD, could I just plug it in in place of my current >WD "PROTO" (yes, it says "Prototype" right on the chip) chip? Yes. > >Gregory R. Travis Indiana University, Bloomington IN 47405 >greg@cica.cica.indiana.edu Center for Innovative Computer Applications >Disclaimer: Everything I say is true and I never lie. Clay Jones clay@novell.com
greg@ogre.cica.indiana.edu (Gregory TRAVIS) (01/25/91)
Some followup on A2091 woes, now that the ball is rolling. Unfortunatly it appears, contrary to Randell's suggestions, that turning off reselection on both drives does not make the problem go away. It does VASTLY improve the situtation however. First, some data: 1) I'm not a bonehead. I have verified a number of ways that no-reselection is written into the parameters on BOTH drives and I had to re-do my paritions and everything. 2) There IS a marked improvement in reliability. I was convinced the problem had gone away for a week UNTIL... 3) Last night I was putting some stuff together in ProPage and UUCP kicked in. I wrote some stuff out of ProPage at the same time UUCP was going for my USR: disk. BAMMO, it locked up with the light on. 4) I thought it might have been a freak, or a bug in ProPage, so I went to bed last night while my machine ran two copies of a little program I wrote that just reads from files randomly. One copy ran from one drive, the other on the other drive. AND 5) When I woke up this morning, the controller was locked up. So, to protect myself and my work, I've got to go back pretending the Amiga is a single-tasking machine. Mondo Depresso. Unfortunatly, I don't have the $$$ for another (GVP) controller for my other drive. And if I did, I'd spend it on a Loran for my plane... -- Gregory R. Travis Indiana University, Bloomington IN 47405 greg@cica.cica.indiana.edu Center for Innovative Computer Applications Disclaimer: Everything I say is true and I never lie.
ridder@elvira.enet.dec.com (Hans Ridder) (01/26/91)
In article <17905@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes >[Dave explains steps taken to solve the famous A2091 problem] > >STEP 3: > Steve revises the device driver (in the ROM, folks), to use the > original functions that are finally corrected, and things work once > again. Thanks Dave! So, now all us A2091 owners have to do is get ahold of these new ROM's with the finally corrected device driver. The problem is that it apparently hasn't been released yet. The local dealer doesn't know anything about it. The A2091 is a nice "controller" (host adapter, really) except for this one long standing problem with the driver (and perhaps that the TRMPWR line isn't fused, and the terminators aren't socketed :-)). This has been a really frustrating problem for all of us, and probably hasn't given the Amiga a lot of good press. Dave, is there *any* information you can divulge on when and/or how these ROM's will become available? It feels like it's been *forever* since the problem was identified, and a fix promised. I know you're *only* an Engineer there, but if you could give us something or get the "right person" to give us some status, I'm sure it would lower the volume of these discussions. (Well probably not, but we could always hope!) >Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" -hans ------------------------------------------------------------------------ Hans-Gabriel Ridder Digital Equipment Corporation ridder@elvira.enet.dec.com Customer Support Center ...decwrl!elvira.enet!ridder Colorado Springs, CO
drxmann@ccwf.cc.utexas.edu (Dustin Christmann) (01/26/91)
In article <2386@shodha.enet.dec.com> ridder@elvira.enet.dec.com (Hans Ridder) writes: >Dave, is there *any* information you can divulge on when and/or how >these ROM's will become available? It feels like it's been *forever* >since the problem was identified, and a fix promised. I know you're >*only* an Engineer there, but if you could give us something or get the >"right person" to give us some status, I'm sure it would lower the >volume of these discussions. (Well probably not, but we could always >hope!) Another question. What will be the version number on these ROM's so that we know that we have the real bonafide fix? Thanx, Dustin R. Christmann Internet: drxmann@ccwf.cc.utexas.edu Bitnet: DRXMANN@UTXVM "Whatta maroon!" -Bugs Bunny
greg@travis.cica.indiana.edu (Gregory TRAVIS) (01/31/91)
Here is some more information for Commodore/Randell. As I posted before and as Randell suggested, turning off reselection on the A2091 with 5.92 ROMS and the WD "A" chip is NOT sufficient to avoid the lockup problem. First of all, my configuration: 1 A2500/30 with 4 Meg of 32-Bit RAM 1 A2091 with ROM V5.92 and the WD "A" chip. 2 Meg of 16-bit RAM on the board. 1 flickerFixer 1 Internal Quantum ProDrive 40Meg 1 External MiniScribe (forgot the model #) 300Meg 1 External CDC Wren, 300Meg Last night, due to the fact that I had trashed the Miniscribe (would not validate - Key already set) during a previous lock-up I copied off the data on the Quantum and the Miniscribe to the CDC Wren. I then: a) Made sure the drive types in HDtoolBox all had reselection turned OFF. b) Low-level formatted the Quantum and Miniscribe drives. c) Changed their partitions and wrote the new information out to disk. d) Copied the data back from the CDC drive to the Quantum and Miniscribe drives. e) Disconnected the CDC drive. f) Sat down and tried to do some work. At some point during the night, I had a program bomb on me (no big deal) while it was writing to the Miniscribe and it locked up the system (but not the controller) so I had to do the Control-Amiga-Amiga dance. I rebooted. However, since the Miniscribe was "dirty" at the time of the crash, the validator started trying to validate it AS my Startup-Sequence was being executed from the Quantum (my SYS: disk). As I'm sure you can all guess, the system locked up solid and was unable to complete the boot sequence. I was able to get it running again by hitting control-A/B/C right after the initial CLI window comes up - it stops execution of Startup-Sequence and the validator goes on and does its thing - if you're lucky. The worst is to have validators try and run on both the Quantum and Miniscribe at the same time - I have to turn off the Miniscribe before re-booting to get around that possibility. Leaving the CDC drive on-line (it was also formatted with reselection turned OFF) dramatically increases the likelyhood of the A2091 locking up. It can lock up during normal power-up just going out and looking at all those drives and trying to stick their icons in the workbench at the same time. I posted this to give Commodore (and Amiga users) some more data on the symptoms and system configurations under which the A2091 locks up. I sure hope those new ROMS become available soon and I can use my Amiga without fear! -- Gregory R. Travis Indiana University, Bloomington IN 47405 greg@cica.cica.indiana.edu Center for Innovative Computer Applications Disclaimer: Everything I say is true and I never lie.
jason@cbmami.UUCP (Jason Goldberg) (01/31/91)
In article <greg.665253236@travis>, Gregory TRAVIS writes: > Here is some more information for Commodore/Randell. As I posted before > and as Randell suggested, turning off reselection on the A2091 with > 5.92 ROMS and the WD "A" chip is NOT sufficient to avoid the lockup > problem. First of all, my configuration: > > 1 A2500/30 with 4 Meg of 32-Bit RAM > 1 A2091 with ROM V5.92 and the WD "A" chip. 2 Meg of 16-bit RAM > on the board. > 1 flickerFixer > 1 Internal Quantum ProDrive 40Meg > 1 External MiniScribe (forgot the model #) 300Meg > 1 External CDC Wren, 300Meg > I have virtually the same set-up, including the 5.92 ROMS and the WD "A" chip, except that all my HardDrives are wimpy Seagates 157N's. It has been my experience that the problems only crop up when drives of different speeds are used, thus the reason that my Seagates have never crashed, and you are having so many dificulties. If you have or get any additional info on problems with this combination or if you find any solution, please let me know. I am running out of storage and would like to add a big drive to me system i.e. a Wren. Thanks, -Jason- --------------------------------------------------------------------------- Jason Goldberg UUCP: ucsd!serene!cbmami!jason Del Mar, CA