Announcement

Collapse
No announcement yet.

Please, some R200 love!

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by Panix View Post
    But, users with non-ATI cards claim GE work fine?
    Which may (or may not) just mean that the bug in GE doesn't trigger on other drivers.

    Software can be really weird, especially when working with an unmanaged language. Accessing an invalid pointer, for instance, can result in any of:

    (a) instantaneous crash via SIGSEGV
    (b) temporary corruption of some output via reading bogus data for transitory purposes or in a temporary buffer, which corrects itself later on
    (c) long-term corruption of some output via reading/writing bogus data in a non-temporary location, which cannot correct itself
    (d) crash many seconds, minutes, or even hours later via SIGSEGV after reading/writing bogus data to a long-term storage area
    (e) apparently perfectly working application with no errors or crashes at all

    Things like returning an error code from a function that isn't checked for, returning data in a valid but unexpected format, race conditions in the client application, and so on can all result in "crazy" errors and crashes that can appear to be the fault of some entirely different module or code than what is actually broken. That's software.

    Comment


    • #32
      Originally posted by Panix View Post
      But, users with non-ATI cards claim GE work fine?
      I have found a bug report about the exact same issue against an Intel driver, so I think all Mesa drivers suffer from this issue. It is somewhat related to libexpat, though.

      Comment


      • #33
        Originally posted by LinuxID10T View Post
        Actually mainline Linux needs a 386 with math coprocessor minimum. However, with ELKS it can run on an 8088. The sad part is that that project seems to be abandoned.
        Thank you for being thick... you've proven my point.

        Comment

        Working...
        X