[Bf-committers] Quicktime & autoconf

Meino Christian Cramer bf-committers@blender.org
Fri, 02 May 2003 19:28:03 +0200 (CEST)


From: Kester Maddock <Christopher.Maddock.1@uni.massey.ac.nz>
Subject: Re: [Bf-committers] Quicktime & autoconf
Date: Sat, 3 May 2003 03:00:50 +1200

Hi Kester

> Tuhopuu is the experimental tree.  Major new features are developed and tested 
> here before being moved to the blender tree. 
> CVS instructions at http://projects.blender.org/cvsx/?group_id=11

  Thank you, Kester, for the instructions.
  I the meantime I had found my way to that branch myself, downloaded
  the 5 Megs and found the same bugs -- regardless where they are
  ... sigh. 

> >
> > > A new video card
> >
> >   Oh, please not...
> Can you borrow a different video card?

  Hmmmm....I did another experiment, which may render the bug -
  whereever it is -- with a handfuil more spotlights:

  I did a "chmod a-rw /dev/dri/card0" and started glxgears. The
  program said: No dri/drm available...ok, that's what I want.

  Then I started blender which also uses software rendering now. This
  time I could use the script (!)

  For me it means the following:
  Either:
  There is a bug in blender (for example an unsigned int param is given
  to a routine of the Xserver expecting a signed int) which triggers
  the lock in the XServer because the XServer isn't able to catch the
  fault before it do suicide.
  The software emulation may cath this more gracefully and simply
  ignore the upper bit. The error is "swallowed" and everything
  "works".

  Or:
  The Xserver itsself is the only guilty one. There is a vaild call
  which is turned into a working hard lock by the XServer. Dash.

  Or: 
  There is another effect, which may add an additional spotlight this
  sceen: 
  If I do the following: Make a little scene, enable DispWin, render
  the scene the first time (works), press RENDER again
  then: BLENDER crashes (no hard lock) and puts some info onto the
  console:
  
    [mccramer/] :/usr/local/bin/blender -nosound 2>&1 | grep -v GHOST
    X Error of failed request:  BadValue (integer parameter out of range for operation)
    Major opcode of failed request:  145 (XFree86-DRI)
    Minor opcode of failed request:  9 ()
    Value in failed request:  0x200000a
    Serial number of failed request:  1641
    Current serial number in output stream:  1641

 I dont know, what this means, but it may a little spotlight for you
 blender sourcerer...
  
 By the way: I mailed the XFree-people with my problems today but get
 no answer until now...

 
> There is also another XFree86 branch at http://dri.sf.net and some driver 
> snapshots at http://dri.sourceforge.net/snapshots/

  I tried the gatos project stuff before and found, that it --
  at the time I tried it -- provide lesser useable code than the XFree
  people. 

  I tried the following XFree versions:

  XFree 4.20
  XFree 4.21
  XFree 4.21.1
  XFree 4.30
  XFree 4.3.99.2
  and recently
  XFree 4.3.99.3

  But as Doug explained, blender runs with other (non-ati/radeon)
  XFree servers without those problems.

  But I hate to fix software problems by buying hardware, which does
  not use that kind of software....

> You should also check /var/log/messages for any warnings right before the 
> crash.  You can redirect blenders output to a log file with 
> blender > blender.log 2>&1
> According to the XFree86 and DRI mailing lists, there are still quite a few 
> people who's radeon's lock up.
> Use SysRq-S, SysRq-U, SysRq-B to reboot.  Does an emergency sync, remount read 
> only and reboot.  This will hopefully sync the logfiles to disk.

  No, unfortunately all those tricks  normally used in case of trouble
  fail, since the box is freezed at once. Keyboard dead, mouse dead,
  clock (icewm) dead, everything vanished into eternity...so to say.

  Since I use reserfs all changes written to disc in seconds before
  icetime are rewinded at boot time to ensure a sane filesystem.

  By the way: I have to cycle power to get back my box...simply
  presssing the reset bottom does not work.
 
> >
> >   Why does have no other program related to OpenGL/GLX and such have
> >   problems with my hardware -- except blender ???
> >
> >   This is _not only_ a rhetorical question...
> >
> Sometimes you just hate computers. :)  

  or, with other words:...it seems sometimes computers are hateing
  _me_....sigh

> My computer has a Voodoo3 in it because 
> nVidia cards lock up 30 seconds into anything 3d.

  Before I updated my computer to the current system I asked people
  about OpenGL-able graphic cards for linux. I got the hint, that the
  older ATI Radeon cards are well supported by Open Source
  codes. "Anything else" would use propietary "bunches of bin" as
  drivers. I "hate" those. As it seems, this was either a wrong info
  or my decision and feeling about prop. codes is wrong.

  But I dislike the thought of not controlling my life ... ooops 
  wrong movie...Neo said this in "The Matrix"...qhat I wanted to said: 
  I dislike the thought of not controlling my computer completly.

  Especially when it comes to "Digital total awarness" and such.
  But this is an evil branch of the "Politics today" project, which
  has'nt released any working code until now.... ;)


> >
> > > (btw --export-dynamic is already enabled in the NaN makefiles)
> >
> >   And why the option enable-blender-static then ?
> --export-dynamic makes some python interpreter functions available when 
> loading python modules from scripts. (ie import math)  Just in case anyone 
> else is reading.

  The problem of the "unresolved symbols" has been fixed, now. So I
  have no need to build blender statically anymore. On the other hand
  ... the --enable-blender-static should be removed then.


  Kind regards and thank you for your effort to help me!
  Meino

> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers@blender.org
> http://www.blender.org/mailman/listinfo/bf-committers
>