" Seaman) (07/18/90)
Well, here are the results of my attempt to fix the 2091 problem: First, I booted my Amiga (cold) from the unmodified backup of the A2091 Installation Disk. I opened the shell, and ran my program that checks address zero (it prints the value in decimal). It reports 184549384 as the value. I then ran the HDToolBox software, selected 'Partition Drive', then 'Advanced Options', then 'Add/Update Filesystem', and finally 'Update Filesystem' from the appropriate menus. In the requester, I entered 'df1:l/FastFileSystem', which represented my unmodified Workbench 1.3.2 disk. The copy of FastFileSystem on that disk is 12248 bytes, dated 5/9/89, has the string 'V36.03(5/9/89)' embedded in it, and has the ID of '0x444f5301' in HDToolBox. For those using the old (version 1.000) CRC program, the crc value is 2F43. I selected 'OK', and the floppy was accessed. I then selected 'OK' to exit from each sub-menu, saved the changes to the RDB, and exited HDToolBox. I then powered down the Amiga, restarted (from the 2091 Install Disk), and checked address zero: 184549384. This is the same value that has been reported on every boot since I installed the 2091. To be absolutely sure, I repeated this process two more times, with absolutely no difference in the outcome. If someone can point out where I erred, I would be most grateful. Otherwise, I can only assume that there are different ROM revisions out there on the 2091, and mine is different from those who don't have the problem. The only other possibility I can think of would be a problem running the 2091 on my 2620-equipped rev 4.4 B2000-CR motherboard. Any ideas? -- Chris (Insert phrase here) Seaman | /--\ cseaman@sequent <or> | | | "This is as real as ...!uunet!sequent!cseaman | | \ | your so-called 'Life' gets" The Home of the Killer Smiley | \--X__
yarnall@usceast.UUCP (Ken Yarnall) (07/19/90)
In article <38936@sequent.UUCP> cseaman@sequent.UUCP (Chris "I'm Outta Here, Man!" Seaman) writes:
+Well, here are the results of my attempt to fix the 2091 problem:
+
+First, I booted my Amiga (cold) from the unmodified backup of the A2091
+Installation Disk. I opened the shell, and ran my program that
+checks address zero (it prints the value in decimal). It reports
+184549384 as the value.
+
[...]
+
+I then powered down the Amiga, restarted (from the 2091 Install Disk),
+and checked address zero: 184549384. This is the same value that has
+been reported on every boot since I installed the 2091. To be
+absolutely sure, I repeated this process two more times, with
+absolutely no difference in the outcome.
+
+If someone can point out where I erred, I would be most grateful.
+Otherwise, I can only assume that there are different ROM revisions
+out there on the 2091, and mine is different from those who don't
+have the problem. The only other possibility I can think of would
+be a problem running the 2091 on my 2620-equipped rev 4.4 B2000-CR
+motherboard.
+
+Any ideas?
I got my ProWrite 3.0 upgrade *after* I had updated the filesystem on my 2091
(in my 2500/30), which a thread in c.s.a.tech awhile back had indicated would
clear up the `garbage-at-location-zero' problem. When I tried to start
ProWrite op, it promptly crashed. I called New Horizons, told the tech. rep.
what had happened, and he said "I bet you have a 2091."
What he said is that the roms on the 2091 have some inadvertently released
debugging software, that sets location zero to a non-NULL value. He didn't
explain to me why his program crashed because of this (which it should not
have, IMHO), but he did say that his information came from Commodore. He was
clear in that the problem was in the rom, and not in the filesystem.
New Horizons sent me ProWrite 3.0.1 in a matter of days. Since, I have
gotten by on a little program that clears the zero spot, that I run from my
startup-sequence. It allows JR-Comm 1.0 to run, for instance.
My dealer hinted at a rom upgrade for the 2091 being forthcoming. Any
news??
+Chris (Has anyone seen my) Seaman
kenny
--
Ken Yarnall /// yarnall@cs.scarolina.EDU
Math Department, USC \\\/// yarnall@ucseast.UUCP
Columbia, S.C. 29208 \\\/ (803)777-6686papa@pollux.usc.edu (Marco Papa) (07/20/90)
In article <3343@usceast.UUCP> yarnall@usceast.UUCP (Ken Yarnall) writes: >I got my ProWrite 3.0 upgrade *after* I had updated the filesystem on my 2091 >(in my 2500/30), which a thread in c.s.a.tech awhile back had indicated would >clear up the `garbage-at-location-zero' problem. When I tried to start >ProWrite op, it promptly crashed. I called New Horizons, told the tech. rep. >what had happened, and he said "I bet you have a 2091." > >What he said is that the roms on the 2091 have some inadvertently released >debugging software, that sets location zero to a non-NULL value. He didn't >explain to me why his program crashed because of this (which it should not >have, IMHO), but he did say that his information came from Commodore. He was >clear in that the problem was in the rom, and not in the filesystem. > >New Horizons sent me ProWrite 3.0.1 in a matter of days. Since, I have >gotten by on a little program that clears the zero spot, that I run from my >startup-sequence. It allows JR-Comm 1.0 to run, for instance. Let me put it this way. It is true that the drivers for the A2091 and A590 do put some debugging stuff (non-zero) at location zero, BUT it is also true that the programs that bomb in this situation ARE the culprits. What these program do is the following: they use pointers statically un-initialized (therefore zero) and READ the value pointed by them, BEFORE initializing them. So they read location zero. Of course what they do is "random", but if they read the data and use it as pointer they'll point back to zero and the dereference will get zero again. Problem is, if location zero is NOT zero (like on the A2091) they'll reference some random location in memory and start using the data at that location. That's why some of these programs will work fine (they don't crash, just by chance) in one case, and they GURU in the other one. Of course this bug is NOT very easy to find since it can't be found on a 68000. I.e. sdb or cpr (the debuggers) can't be used to check for a "read" access in low memeory. They can only be used to monitor write access. This is also the reason why all those other tools like memwatch are useless, since they also can only check for write access, not read. The only useful tool is Bryce's Enforcer (on the DevCon '90 disk) that can be used on any system with an MMU and that can check for incorrect read access on low memeory. -- Marco -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
yarnall@usceast.UUCP (Ken Yarnall) (07/20/90)
In article <26032@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: +In article <3343@usceast.UUCP> yarnall@usceast.UUCP (Ken Yarnall) writes: +> +>[...] +> +>What he said is that the roms on the 2091 have some inadvertently released +>debugging software, that sets location zero to a non-NULL value. He didn't +>explain to me why his program crashed because of this (which it should not +>have, IMHO), but he did say that his information came from Commodore. He was +>clear in that the problem was in the rom, and not in the filesystem. +> +>[...] + +Let me put it this way. It is true that the drivers for the A2091 and A590 +do put some debugging stuff (non-zero) at location zero, BUT it is also +true that the programs that bomb in this situation ARE the culprits. What +these program do is the following: they use pointers statically un-initialized +(therefore zero) and READ the value pointed by them, BEFORE initializing +them.... + +[...] You're preaching to the converted, Marco. I guess I wasn't clear enough in what I wrote above. I *know* what causes programs with uninitialized pointers to crash, have seen the symptoms, and have even spent hours ferreting out bugs of this nature. When I said I would have liked the guy at New Horizons to explain why his program crashed because of this, what I meant was "Why did you release a commercial program (which sports a `bug-free' guarentee!) with a bug like this?" Everyone is to blame here. I think it is clear from what I said that I feel the software developers should be more careful (you never catch me using uninitialized pointers -- no way, man, never! ;^), but there doesn't seem to me to be much of an excuse for C= to be releasing *roms* with active diagnostic code in them. Let me say, though, that Commodore has been very forthright about explaining what went wrong, and providing work-arounds. +-- Marco kenny -- Ken Yarnall /// yarnall@cs.scarolina.EDU Math Department, USC \\\/// yarnall@ucseast.UUCP Columbia, S.C. 29208 \\\/ (803)777-6686
jprad@faatcrl.UUCP (Jack Radigan) (07/20/90)
papa@pollux.usc.edu (Marco Papa) writes: >Of course this bug is NOT very easy to find since it can't be found on a >68000. I.e. sdb or cpr (the debuggers) can't be used to check for a "read" >access in low memeory. They can only be used to monitor write access. This >is also the reason why all those other tools like memwatch are useless, since >they also can only check for write access, not read. The only useful tool is >Bryce's Enforcer (on the DevCon '90 disk) that can be used on any system >with an MMU and that can check for incorrect read access on low memeory. Hmm, I follow what you're saying, but even if you can't track reads, most code (at least mine) does also write to this pointers. Ok, for data tables and such other cases you'll be limited to reads. Maybe I am doing this, but not in any area that I can think of off-hand. Besides, if it was strictly related to a dereferenced pointer read, it should still fail on an A1000 by setting location zero to any non-zero value, especially an odd value. but, in this particular case it doesn't fail... I'm still looking around for malformed code, but haven't found it yet. -jack-
plav@cup.portal.com (Rick M Plavnicky) (07/21/90)
On 7/18/90 yarnall@usceast.UUCP (Ken Yarnall) writes: >In article <38936@sequent.UUCP> cseaman@sequent.UUCP (Chris "I'm Outta Here, >+Well, here are the results of my attempt to fix the 2091 problem: >+ >+First, I booted my Amiga (cold) from the unmodified backup of the A2091 [Chris' description of his FS update deleted] >+If someone can point out where I erred, I would be most grateful. >+Otherwise, I can only assume that there are different ROM revisions >+out there on the 2091, and mine is different from those who don't >+have the problem. The only other possibility I can think of would >+be a problem running the 2091 on my 2620-equipped rev 4.4 B2000-CR >+motherboard. >+ >+Any ideas? > [Ken's experiences with the ProWrite 3.0 upgrade deleted] >[ProWrite..] said [...] the roms on the 2091 have some inadvertently released >debugging software, that sets location zero to a non-NULL value. He didn't >explain to me why his program crashed because of this (which it should not >have, IMHO), but he did say that his information came from Commodore. He was >clear in that the problem was in the rom, and not in the filesystem. > [A little more deleted...] >My dealer hinted at a rom upgrade for the 2091 being forthcoming. Any >news?? > >+Chris (Has anyone seen my) Seaman > >kenny >-- > Ken Yarnall /// yarnall@cs.scarolina.EDU > Math Department, USC \\\/// yarnall@ucseast.UUCP > Columbia, S.C. 29208 \\\/ (803)777-6686 I recently had my 2000 in for warranty service. (20 days and 2 motherboards worth, but that's another story...) Since it was there anyway, I asked the dealer to install the new 2091 ROMs if they became available while my machine was being serviced. They did. For reference, though, here are the part numbers for the ROMs in question: Original ROMs Upgraded ROMs ------------- ------------- Even (U13) 390508-02 390721-01 Odd (U12) 390509-02 390722-01 Honestly, I've noticed no difference in the 2091's operation. And I never had any problems due to corruption of the longwords at location 0 in the first place (I must not run the 'right' software :) So, yes, new ROMs are available. Hope that helps. /* Rick Plavnicky ...!sun!cup.portal.com!plav -or- plav@cup.portal.com */