sysmark@aurora.physics.utoronto.ca (Mark Bartelt) (05/17/91)
Robert Stephens, replying to a report of a mail bug, writes: | I have just verified that the fixed version shipped with IRIX 3.3.2. | It must be the case that your machine is running IRIX 3.3.1, you should | check to be sure. This brings up another question (several, actually): When did 3.3.2 start shipping? Is it still trickling out? We haven't gotten 3.3.2 for *any* of our Personal IRISes yet. (We have eight, all under extended warranty.) The fellow who looks after the 4D/280 which lives four floors down from us mentioned that 3.3.2 was being shipped *only* to those customers who asked for it, or who had reported bugs which 3.3.2 would fix. Is this a true rumour, or not? If true, then how were we supposed to know to ask for it? We certainly never heard anything by hardcopy mail, e-mail, or postings to this newsgroup. And if it's a false rumour, then why is it taking so long to get the tapes out to customers? (Didn't 3.3.2 start going out shortly after the start of the year?) Could someone from SGI please clarify what's going on here? Mark Bartelt 416/978-5619 Canadian Institute for mark@cita.toronto.edu Theoretical Astrophysics mark@cita.utoronto.ca
blbates@AERO36.LARC.NASA.GOV (Brent Bates ViGYAN AAD/TAB) (05/17/91)
It seems to be standard SGI policy to only ship updates to people who ask for them. But asking for them isn't always enough either. I find this very annoying. How is one suppose to know an update exists, if SGI doesn't tell you?! I have reported bugs in the past to the hotline and that isn't enough for them to tell you when it is fixed and what update release it is on. I recently received a copy of Pipeline and it has a postage paid postcard with questions related to this issue. I hope everyone sends it back. By the way I believe 3.3.3 is now the latest update level. We haven't gotten it. I have only seen it referenced in some email. I hope 4.0 comes out VERY soon (like in the next month?!) Brent L. Bates Phone:(804) 864-2854 NASA-Langley Research Center FAX:(804) 864-6792 M.S. 361 Hampton, Virginia 23665-5225 E-mail: blbates@aero36.larc.nasa.gov or blbates@aero8.larc.nasa.gov
pejacoby@mmm.serc.3m.com (Paul E. Jacoby) (05/17/91)
In article <1991May17.093936.28501@helios.physics.utoronto.ca> mark@cita.toronto.edu writes: >This brings up another question (several, actually): When did 3.3.2 start >shipping? Is it still trickling out? We haven't gotten 3.3.2 for *any* of >our Personal IRISes yet. (We have eight, all under extended warranty.) FYI, we just got a 4D/35, and it shipped with 3.3.2 installed. Paul -- | Paul E. Jacoby, 3M Company | | | Maplewood, MN 55144-1000 | Parachuting? Why jump out of a | | => pejacoby@3m.com | perfectly good airplane? | | (612) 737-3211 | |
bobg@rains.wpd.sgi.com (Bob Green) (05/18/91)
In article <1991May17.143713.10728@mmm.serc.3m.com>, pejacoby@mmm.serc.3m.com (Paul E. Jacoby) writes: |> In article <1991May17.093936.28501@helios.physics.utoronto.ca> mark@cita.toronto.edu writes: |> >This brings up another question (several, actually): When did 3.3.2 start |> >shipping? Is it still trickling out? We haven't gotten 3.3.2 for *any* of |> >our Personal IRISes yet. (We have eight, all under extended warranty.) |> |> FYI, we just got a 4D/35, and it shipped with 3.3.2 installed. |> |> Paul |> -- |> | Paul E. Jacoby, 3M Company | | |> | Maplewood, MN 55144-1000 | Parachuting? Why jump out of a | |> | => pejacoby@3m.com | perfectly good airplane? | |> | (612) 737-3211 | | 3.3.2 was incorporated into the manufacturing lines at SGI in late February. The earliest units would have made it out the door in March. Both the Personal Iris and the Power Series were modified at the same time. For systems which had already been shipped, the maintenance packaging of this release (3 tapes) was shipped to only those customers on maintenance contracts who had encountered problems fixed by this release. Bob Green
sysmark@aurora.physics.utoronto.ca (Mark Bartelt) (05/24/91)
In article <1991May17.194546.8546@odin.corp.sgi.com> bobg@rains.wpd.sgi.com (Bob Green) writes: | For systems which had already been shipped, the maintenance packaging of | this release (3 tapes) was shipped to only those customers on maintenance | contracts who had encountered problems fixed by this release. And how does SGI *know* which customers have encountered problems fixed by this release? Presumably the tapes went only to customers who had reported such bugs to SGI. But I'd expect that there are many more customers who may need or want the updates. Perhaps they encountered bugs but found some sort of workaround. Perhaps there are customers who haven't yet encountered one or more of these bugs, but might (tomorrow? next week? next month?). All in all, I think that the policy described above is rather shoddy. When we bought in to our maintenance contract, we were told that we'd automatically be getting *all* updates. No mention was ever made that we might or might not get them, depending on SGI's whim. Does anyone else feel a bit peeved by this, or am I just being overly cranky about it? Mark Bartelt 416/978-5619 Canadian Institute for mark@cita.toronto.edu Theoretical Astrophysics mark@cita.utoronto.ca
jim@baroque.Stanford.EDU (James Helman) (05/24/91)
There are always bugs to be fixed. But since the decision to produce a release is entirely at SGI's discretion, it's hard to complain too much when you don't receive one. Most maintenance contracts leave it entirely up to the vendor to decide if and when updates are distributed. For all I know, 3.3.2 might only fix some problem with HyperChannels to Crays! (But I doubt it.) It may be dubious customer relations to tell someone that after paying many $K for support, that SGI won't send out a 3.3.2 tape even after one asks for it, but SGI is within bounds on not sending it to everyone. However, I agree that if SGI deemed the fixes important enough to make a subrelease, I'd at least like to see a list of the bugs it addresses and be given the opportunity to request it. That would still save SGI lots of distribution costs and would protect those customers who believe they might be affected. Bugs can be like minefields for developers. Pop! You lose an hour. Kabooom! A month blasted off. IRIX is pretty good really, only an occasional pop. But if deactivation kits are too expensive, a map would still be nice. ;-} Jim Helman Department of Applied Physics Durand 012 Stanford University FAX: (415) 725-3377 (jim@KAOS.stanford.edu) Work: (415) 723-9127
dprmjc@prism.ARCO.COM (M. J. Cole) (05/25/91)
In article <1991May17.093936.28501@helios.physics.utoronto.ca>, mark@cita.toronto.edu (Mark Bartelt) writes: > ... > All in all, I think that the policy described above is rather shoddy. When we > bought in to our maintenance contract, we were told that we'd automatically be > getting *all* updates. No mention was ever made that we might or might not get > them, depending on SGI's whim. Does anyone else feel a bit peeved by this, or > am I just being overly cranky about it? I'm peeved too! In article <JIM.91May24092749@baroque.Stanford.EDU>, jim@baroque.Stanford.EDU (James Helman) writes: > ... > However, I agree that if SGI deemed the fixes important enough to make > a subrelease, I'd at least like to see a list of the bugs it addresses > and be given the opportunity to request it. > ... > Bugs can be like minefields for > developers. Pop! You lose an hour. Kabooom! A month blasted off. > ... YES! Is anyone at SGI listening? A bug that bit me in 3.2 just got fixed in 3.3.3. I heard it through the grapevine and played telephone tag with the hotline for 2 days before being promised a tape. Suggestions for SGI Support: 1) As Jim writes above, when a new subrelease is created send a list of included bug fixes to all customers under maintenance. 2) At the introduction of each major release, publish a list of known bugs. This would provide us with a much appreciated minefield map. 3) Give hotline workers answering machines. This would minimize bouts of telephone tag after a call is assigned. Frequently I return a hotline-worker's call only to be told by the switchboard, "He/She is on the phone, I'll have them return your call." Then they call me back, and I'm not in, so I call them back... In many cases, this sort of telephone tag would be eliminated if one could leave a detailed message. ............................................................................... Mary J. Cole ARCO Oil & Gas Company mjcole@arco.com 2300 W. Plano Parkway; PRC-D3239; (214)754-6857 Plano, TX 75075 ............................................................................... I'm continually AMAZED at th'breathtaking effects of WIND EROSION!! -ZIPPY ...............................................................................
merritt@climate.gsfc.nasa.gov (John H. Merritt) (05/25/91)
In article <1991May24.180228.28409@Arco.COM> dprmjc@prism.ARCO.COM (M. J. Cole) writes: [...] >YES! Is anyone at SGI listening? A bug that bit me in 3.2 just got fixed in >3.3.3. I heard it through the grapevine and played telephone tag with the hotline for 2 days before being promised a tape. I suggest that you call SGI every now and again, actually you will here it here first, about the status of their release tapes. If you want it, tell them so and they will most likely send it. I cannot see the point of shipping everyone and their grandmother a minor minor release. > >Suggestions for SGI Support: [...] > 2) At the introduction of each major release, publish a list of known > bugs. This would provide us with a much appreciated minefield map. I guess the 1/2 page section "Known Problems and Workarounds" (section 6 of the Owners manual) is just too short. ;-) >> > 3) Give hotline workers answering machines. This would minimize bouts > of telephone tag after a call is assigned. Frequently I return Why don't you leave the message with the switchboard operator? They will forward it. In fact, it will get forwarded all the way to the field engineer, if neccessary. At some point you have to assume that someone [the receptionist] can do their job. John H. Merritt --> merritt@climate.gsfc.nasa.gov Applied Research Corporation at NASA/GSFC "I am generally intolerant of ignorance, but I have made an exception in your case."
bobg@rains.wpd.sgi.com (Bob Green) (05/28/91)
The following text is an extract from the release notes of
4D1-3.3.2. I hope you find it useful:
Bob Green
4. Bug Fixes
This chapter describes bug fixes to Installation, IRIX,
Networking, Graphics, 4Sight, X11, Fortran, 4DDN, Power
Fortran Accelerator, and Emacs. A Silicon Graphics software
change request (SCR) number appears with some of the bug
fixes in this chapter.
4.1 Bug Fixes to Installation
+o The distcp command in 4D1-3.3.1 was not able to copy
data from tapes to file systems.
+o The installation of maintenance releases on diskless
clients would fail to link and copy all of the needed
files resulting in a nonfunctional system.
4.2 Bug Fixes to IRIX
+o A possible (but unlikely) system crash on a VGX could
occur when doing certain shared process operations that
involved copying data down to the graphics pipe.
+o A user could incorrectly raise the maximum amount of
lockable pages per user above what the user previously
specifically configured.
+o A user program could inadvertantly inherit another
program's address space due to translation problems
associated with shared address processes when those
processes shrunk their virtual space.
+o A deadlock could occur in the system when forking a
process that had a lot of locked memory.
+o A resource counting bug could occur when locking pages
and getting interrupted.
4.3 Bug Fixes to Networking
+o Use of netgroups could cause standard utilities like
select and id to dump core due to a NULL pointer being
returned by the getpwent() routine in libbsd.a.
4.6 Bug Fixes to 4Sight
+o The 4Sight copyarea primitive could cause portions of a
screen to display incorrectly depending on the
overlapping of windows.
+o Icons for the windows of NeWS clients could disappear
under other windows when stowed.
+o The 4Sight version number was changed from 1.5 to 1.51
to reflect the changes in functionality from the
previous bug fixes.
4.7 Bug Fixes to X11
+o SCR 9517 - The X11 server would return the wrong
dimensions on 14" monitors.
+o SCR 9951 - Xfig labels did not display. bobg@rains.wpd.sgi.com (Bob Green) (05/28/91)
The following is an extract from the 4D1-3.3.3 release notes. Please be
aware that a precondition for 4D1-3.3.3 is that 4D1-3.3.2 is installed on
the system.
Bob Green
4. Bug Fixes
This chapter describes bug fixes to IRIX, Networking, NFS
and NIS, Graphics, 4Sight, X11, and Demos. A Silicon
Graphics software change request (SCR) number appears with
some of the bug fixes in this chapter.
4.1 Bug Fixes to IRIX
+o The 1/2-inch tape driver fix that was supposed to have
been in the 4D1-3.3.2 maintenance set is now on the
4D1-3.3.3 tape.
+o Login was changed so that it does not request a new
password for accounts that have the aging feature
turned on and have been accessed through an rlogin with
an associated .rhosts file.
+o The 4D/310 kernels were fixed to exclude hardlocks,
thereby increasing performance.
+o The logical volume functionality was corrected to keep
it from occasionally causing a system crash.
+o Make core dumped when very long file names and the $!
operator were used.
+o The 2-gigabyte I/O limit on irregular files was
removed. This had caused errors when attempting to
back up logical volume file systems exceeding 2
gigabytes.
4.2 Bug Fixes to Networking
+o In 4D1-3.3.2, diskless workstations would sometimes
hang during periods of heavy swapping. This occurred
whenever the Ethernet driver tried direct memory access
(DMA) on consecutive virtual pages pointing to the same
physical page in memory.
4.3 Bug Fixes to NFS and NIS
+o UNIXrO domain sockets were fixed to work over NFS. This
bug disabled the BSD lpr utilities on diskless clients.
4.4 Bug Fixes to Graphics
+o The setvideo(3) Graphics Library call could
inadvertently cause the screen to blank on GT and GTX
systems running 4D1-3.3.2; this bug was most evident to
users of the Composite Video and Genlock Option.
+o The gl readscreen() internal Graphics Library call had
a problem with GT- and GTX-based systems that use the
RV2 (Raster Video 2) board; this bug prevented image
processing tools such as ipaste and scrsave from
functioning properly.
+o A defect disabling the use of all eight stenciling
planes was fixed in the PowerVision graphics.
+o On some Power Series GT, GTX, and VGX models with
programmable video formats, stereo operation did not
always replicate the cursor in a manner consistent with
other models. Cursor operation is now restricted to
the bottom ``right'' image, and a duplicated cursor is
drawn in the top ``left'' image for all models with
stereo capability.
+o On GT and GTX models with programmable video formats,
the NTSC and PAL formats had bugs that could insert a
vertical stripe on the right-hand edge of the video
image. The PAL format in particular would generate a
several-pixel-wide green stripe on the right-hand edge
of active video. Both formats have been fixed to
correct this problem.
4.5 Bug Fixes to 4Sight
+o The space character was incorrectly specified in the
75-dot-per-inch and 96-dot-per-inch fonts. This caused
some characters in FrameMakerrO to overlap.
4.6 Bug Fixes to X11
+o The Destroy.o module in libXt.a caused UIM/X to dump
core.
+o The 4D1-3.3 through 4D1-3.3.2 versions of xterm dropped
support for the -ibmkbd option referenced in the 4DDN
product. The 4D1-3.2 version of xterm has been added
to the release under the name xterm.3.2 for support of
this feature.
4.7 Bug Fixes to Demos
+o The eyes demo that was supposed to have been in the
4D1-3.3.2 maintenance set is now in the 4D1-3.3.3
maintenance set.dunlap@sgi.com (D. Christopher Dunlap) (05/30/91)
In article <5428@dftsrv.gsfc.nasa.gov> merritt@climate.UUCP (John H. Merritt) writes: >In article <1991May24.180228.28409@Arco.COM> dprmjc@prism.ARCO.COM (M. J. Cole) writes: >[...] > >>Suggestions for SGI Support: >[...] >>> >> 3) Give hotline workers answering machines. This would minimize bouts >> of telephone tag after a call is assigned. Frequently I return >Why don't you leave the message with the switchboard operator? They >will forward it. In fact, it will get forwarded all the way to the >field engineer, if neccessary. At some point you have to assume that >someone [the receptionist] can do their job. > > John H. Merritt --> merritt@climate.gsfc.nasa.gov > Applied Research Corporation at NASA/GSFC > "I am generally intolerant of ignorance, > but I have made an exception in your case." If you have a situation that is better described in a voice-mail (answering machine) message, then just ask the call administrator to put you through to the Support Engineer's voicemail. This works very well for our staff in Mountain View. A little bit less well for the Field folks. Again, any problems or deviations from what I state - just let me know. you can reach me through our 800 number (800-800-4SGI) or via email. regards, chris -- D. Christopher Dunlap Product Support Engineering Customer Support Division email: dunlap@sgi.com Silicon Graphics Computer Systems
dprmjc@prism.ARCO.COM (M. J. Cole) (05/30/91)
> In article <1991May24.180228.28409@Arco.COM> dprmjc@prism.ARCO.COM (M. J. Cole) writes: > > 3) Give hotline workers answering machines. This would minimize bouts > > of telephone tag after a call is assigned. Frequently I return In article <5428@dftsrv.gsfc.nasa.gov>, merritt@climate.gsfc.nasa.gov (John H. Merritt) replies: > Why don't you leave the message with the switchboard operator? They > will forward it. In fact, it will get forwarded all the way to the > field engineer, if neccessary. At some point you have to assume that > someone [the receptionist] can do their job. I DO leave messages. However: 1) the SGI receptionists will not take longish messages, 2) the SGI receptionists are errorprone (IMHO, based on experience) at taking technical messages, 3) In the case in point SGI required that the hotline worker speak to me directly and in person, not via messages before sending the tape. ............................................................................... Mary J. Cole ARCO Oil & Gas Company mjcole@arco.com 2300 W. Plano Parkway; PRC-D3239; (214)754-6857 Plano, TX 75075 ............................................................................... I'm continually AMAZED at th'breathtaking effects of WIND EROSION!! -ZIPPY ...............................................................................