Jump to content
12 posts in this topic

Recommended Posts

Hi,

 

I use a Sony VAIO F11 with external accelerated nvidia display.

 

When I am watching on EyeTV (external usb receiver) and I move a window around with the mouse, the video will freeze until I stop the movement.

 

If I access an external usb harddrive while tv video, the video + sound will freeze exactly for the time of the access.

 

I think these are two different problems, but it seems to me, it's some kind of interrupt problem...?

 

Is there a way to determine the interrupt allocation and influence it?

 

Could it be done by modifiing the dsdt?

 

Thanks for tips.

You can use IORegistryExplorer to see how OS X assigns IRQs. It comes with Apple Xcode. You can download Xcode 3 for free at the the Apple developer site but you need to register first. Or you can buy Xcode 4 in the App store, but it's missing some nice tools that came with Xcode 3 such as the plist editor.

 

Visit the DSDT subforum over on the Project OSX forums and read the thread named something like "IRQ fix for slow SATA".

Thanks Gringo,

 

I already have ioregExplorer installed of course.

 

I made some more tests, also vlc or quicktime freezes while window movements.

 

I already use an advanced DSDT that originally comes from kizwan.

 

Am I right that this issue is caused by a wrong IRQ for the graphics interface?

 

Do you mean this thread: Slow data issue fix - project osx

 

 

I attached an ioreg dump:

 

vaiodump.ioreg.zip

Yes that's the thread. Edit the mentioned devices in your DSDT.aml to match.

 

Chameleon lets you specify a dsdt file to load on bootup, so if you save it as test.aml you can experiment all you want until you're happy with the result. If you don't specify which DSDT file to load, Chameleon will continue to load your /Extra/DSDT.aml.

 

Type dsdt=[path-to-dsdt] at the boot prompt to load your experimental DSDT.

I do not understand how to set the irq for example for NGFX device....

Neither do I! :) But I've seen examples around. Search and then search some more. IIRC there's a on-board Firewire issues thread here somewhere with some good tips, try to find that.

 

The first thing you need to do is find out if you actually need to do it.

 

As I said you can see the assigned IRQ(s) for each device in IOReg - you will want to go through them all and find out if there is a conflict. And if that's the case, maybe you'll find that it's easier to change it for the other, conflicting device, rather than NGFX? Bet you didn't think about that. :(

 

All I know is that it's possible to do it (at least for devices that are in your DSDT already) I have never had to do it myself so I can't offer any further help.

I don't know, but it sounds like it would be a good idea to try it.

 

The model identifier affects mostly power management, who knows if that in turn could affect IRQ assignments.

 

It sounds like you're trying to avoid having to manually go through IOReg to find conflicts! tsk tsk

 

I can see you've done your model identifier homework already but for completions sake (not the rice wine);

 

You can use something like MacTracker, or the everymac site to find the best matching model identifier.

 

However, if you want really detailed info, you'll want to look at Linux bug reports posted by people running Linux on Macs.

 

For example, you would google "MacBookPro6,1 DMI" (no quotes) and find something like this:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/650724

Here's the 11,1: https://bugs.launchpad.net/ubuntu/+source/l...g/398788/+index

There's an LSPCI dump, all you need to make an accurate smbios.plist, CPU info and more. It's a treasure trove, the motherload, the whole shebang.

The problem completly disappears if I disable beamsync with QuartzDebug or add "deferredUpdates = 0" to windowserver.plist....

 

Seems the nvidia driver has problems with beamsyncing and there is no irq problem....

Yeah that's supposed to be off if you're not using a CRT monitor?

 

I don't remember..it's a prehistoric tweak.

 

/EDIT

 

Look what I dug up....all the way back from 2005:

http://hints.macworld.com/comment.php?mode...w&cid=58223

No, it's an external HDMI LED-display.

 

Exactly, not a CRT, so beamsync should be off. If I'm understanding this correctly.

 

Your problem is that beamsync doesn't stay off, and you want to force it off. Right?

 

Maybe OS X is not identifying your display correctly and therefore not setting the beamsync value correctly.

You could probably verify this by trying a DVI or VGA connection to the display and see if the problem goes away or something different happens.

 

If your vaio has nvidia graphics, there's a property you can inject called "display-cfg" that might help.

Presently the only way to do this is via DSDT gfx device or NVEnabler.kext. Look in the NVENabler release thread over at the Project OS X forums for more information.

 

Good luck.

×
×
  • Create New...