| Re: G4-related problem [message #36270 is a reply to message #36110] |
Wed, 03 September 2003 09:26   |
Karl Schultz
Messages: 341
Registered: October 1999
|
Senior Member |
|
|
Update:
We heard back from Apple and they were able to find the problem via a bug
report I filed.
They said that the problem does exist on 10.2 and also in 10.3. In the 10.3
case, another issue hid the actual bug, which led us to believe that the
problem didn't exist in 10.3. In any case, the problem will not appear in
future OS X releases. The fix has been rolled into the current OS X 10.3
builds. It is unclear if there is going to be another 10.2.x release and if
this fix will be in it. (If there is another 10.2.x (10.2.7 ?), look for a
mention of this in the "fixed issues" list when you install the update).
Adding together what I observed and what they told us, I believe that the
cause of the problem was Altivec state not being handled correctly when the
OS X kernel interrupts the main thread to run the timer signal handler
thread. OS X uses the Altivec to implement the bcopy function, and so any
changes to Altivec state that may occur in the signal handler would cause an
interrupted bcopy call to malfunction.
Anyway, the problem is understood and the workarounds I suggested below are
still valid.
Karl
"Karl Schultz" <kschultz_no_spam@rsinc.com> wrote in message
news:vjq75m7imf90a2@corp.supernews.com...
>
> "Rudi Sch�fer" <rudi.schaefer@physik.uni-marburg.de> wrote in message
> news:bh8393$2as$1@surz18.uni-marburg.de...
>> Hi.
>>
>> I recently discovered a very nasty problem on my G4 (2*867, Mac OS X
>> 10.2.6) running IDL 5.6.
>>
>> The following code should not produce any output, if everything works.
>> Unfortunately, this is not the case on my G4, where the variable
>> assignment "data1=data0" produces messy data in a randomly fashion. So
>> it works most of the time, but once in a while, the data in "data1" will
>> be corrupted. Typically, there are some zeros showing up in the array
>> and some other garbage.
>>
>> Here is the code in question:
>>
>> data0=fltarr(10000)+1.
>> for ii=0L, 200000 do begin & $
>> data1=data0 & $
>> if min(where(data1 eq 0)) gt 0 then begin & $
>> print, ii & ii=200001L & endif & $
>> endfor
>>
>>
>>
>> This problem did not show up on other machines I have tested (Compaq
>> Alpha, a Windows PC or my iMac G3 running the same OS and IDL versions).
>>
>> So this can either be a G4-specific bug in IDL 5.6, a G4-specific bug in
>> Mac OS X 10.2.6, or a hardware problem on my G4.
>
> Aside from the Altivec code, there is no G4-specific code in IDL. Since
the
> Altivec is not used for simple copy operations and you disabled it, that
> can't be the problem. (But good thinking on disabling it)
>
>> Since I do not have a second G4 available, I would like to ask anyone
>> with a G4 to test the code snippet given above. You can simply paste the
>> code to the command line in IDL.
>
>
>> PS: What I already tested:
>> - setting TPOOL_NTHREADS=1 and VECTOR_ENABLE=0
>> - using different RAM
>> - replacing the RAM modules
>> - testing the RAM with the hardware test CD
>
> I've spent a bunch of time on this and I think I can help a little here.
>
> - The problem seems to only occur on OS X 10.2. I don't know if the story
> changes depending on the version of 10.2 (e.g., 10.2.3). The problem does
> not seem to occur on 10.1 and the developer's preview of 10.3. This last
it
> em is good news.
> - I've only seen or heard the problem reported on G4.
> - The flavor of the X11 server involved does not matter. The IDL program
> needs to be connected to *any* X server to demonstrate the problem. That
> is, the issue is all on the client side.
>
> Given those things, the problem is on OS X 10.2 G4's while IDL has an X
> connection open.
>
> On some systems (OS X is one), IDL uses a 1-second interval timer proc
that
> runs whenever there is an X connection. Its job is to keep your graphics
> windows reasonably up to date while IDL is performing some long operation,
> between interpreter instructions. Disabling this timer operation keeps
the
> problem from occuring, but at the (minor?) expense of unresponsive windows
> during these operations.
>
> So, possible solutions are:
> 1) Use 10.1 or wait for 10.3.
> 2) Issue (the undocumented) DEVICE, /NOTIMER to turn off the timer proc.
> You'll have to judge if this is ok for your app or not.
> 3) Make sure your program does not do any graphics. Note that if you have
> some DEVICE command in your startup file to configure your windows, this
> still makes a connection, even if you don't open any graphic or UI
windows.
>
> If you aren't sure if your machine suffers from the problem, I'd suggest
> running the program above.
>
> Hope this helps,
> Karl
>
>
>
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
