carroll@m.cs.uiuc.edu (06/06/90)
I run the Orchid ProDesigner512 with ISC 2.0.2 X11R3 1.1 (not 1.0!) in
1024x768x4 mode (4 bits, 16 colors). I don't think it works under 1.0.
Also, if you have a mono card in the bus, yank it. It won't work with both.
Alan M. Carroll Barbara/Marilyn in '92 :
carroll@cs.uiuc.edu + This time, why not choose the better halves?
Epoch Development Team
CS Grad / U of Ill @ Urbana ...{ucbvax,pur-ee,convex}!cs.uiuc.edu!carrollbrando@uicsl.csl.uiuc.edu (07/10/90)
You seem to be one of the many of us that unfortunately have the same problem with the Adaptec 1542x card and ISC 2.2. What really yaks me off is that everything works fine on 2.0.2, and after all the bug fixes associated with 2.0.2, I felt I had a stable system. I tried installing 3 different sets of 2.2 diskettes on my machine, all failing at different points with different problems. Lucky me. I was so impressed by 2.0.2, that I bought a workstation developer for 2.2 instead of upgrading my 2.0.2, so that I could get all of the new manuals, etc. Now, $1500+ dollars later, I have a completely unoperational system, hurrah ISC!! Thank God I paid by American Express so that I can withold payment until they get their act together.... Anyway, the moral of the story is your card is probably the same as a bunch of others have (there is a list). So if you want your update for the "update" I suggest you call 1 (800) 344-3896, wait on hold for 15-25 minutes, and ask for David. He is the only winner I see at ISC. He is cool about telling you whats happening up front. As for ISC, everyone makes mistakes; I'll give 'em another try on this release with the hopes that they can get it right. I came over from the SCO boat because of the support/activation key/price bullshit, and it looks like everyone is going to it.....Lucky us...... A very miffed off user who is trying to sound intelligent by offering ISC another chance......... Supportless, Brandon +-----------------------------------------------------------------------------+ | Brandon Brown | Internet: brando@uicsl.csl.uiuc.edu | | Coordinated Science Laboratory | UUCP: uiucuxc!addamax!brando!brown | | University of Illinois | CompuServe: 73040,447 | | Urbana, IL 61801 | GEnie: macbrando | +-----------------------------------------------------------------------------+
carroll@m.cs.uiuc.edu (08/19/90)
/* Written 11:26 am Aug 7, 1990 by chip@tct.uucp in m.cs.uiuc.edu:comp.unix.i386 */ /* ---------- "Bug fix for GDB 3.5 with COFF" ---------- */ This patch fixes a bug that shows up in GDB 3.5 when reading COFF files. The code that reads enum members doesn't stop when it should, thus consuming symbols that should be read elsewhere. In my system, it showed up when debugging gdb failed; gdb complained because the .bb/.eb (begin block/end block) symbols didn't nest properly. Chip Salzenberg at ComDev/TCT <chip@tct.uucp>, <uunet!ateng!tct!chip> /* End of text from m.cs.uiuc.edu:comp.unix.i386 */ I've experienced the same problem under ISC 2.0.2, using GCC 1.37. I've seen underruns as well as overruns for this (I put in a similar fix, but had it generate a warning message). It seems that it is not a GDB bug, but a problem with the binary itself. A count is included in addition to the EOS mark, and that count is wrong sometimes. I don't use GAS, and assembler output from GCC seems to be correct. I'm not an expert on this, so I could be mistaken.