• 1
  • 15
  • 16
  • 17
  • 18
  • 19(current)
[AppleTV] Compiling crystalhd-for-osx Lib/Kext
SO I recompiled the lspci kernel extension as well as the lspci tools (2.9) and lspci does see the BCM70012. So this is a good sign Smile :

12:00.0 Multimedia controller: Broadcom Corporation BCM70012 Video Decoder [Crystal HD] (rev 01)


XBMC still crash the box and here is the relevant part of the report to be sent after reboot :
Code:
Wed Jan 13 20:38:06 2010
panic(cpu 3 caller 0x55648d): "getPhysicalSegment() out of 32b range 0x105d97000, len 0x1000, class IOBufferMemoryDescriptor"@/SourceCache/xnu/xnu-1486.2.11/iokit/Kernel/IOMemoryDescriptor.cpp:1597
Backtrace (CPU 3), Frame : Return Address (4 potential args on stack)
0x85ffbbc8 : 0x21b2bd (0x5cf868 0x85ffbbfc 0x223719 0x0)
0x85ffbc18 : 0x55648d (0x5d8d28 0x5d97000 0x1 0x1000)
0x85ffbc68 : 0x16f7c5a (0x1ff0d680 0x0 0x85ffbc8c 0x0)
0x85ffbca8 : 0x16f76bb (0x1ffbe004 0x1 0x70154054 0x3058)
0x85ffbce8 : 0x16f16b6 (0x10e28c00 0x400 0x22c 0x10e12004)
0x85ffbd08 : 0x16f1349 (0x10e28c48 0x10e12004 0x0 0x6d5f2)
0x85ffbd48 : 0x16f0664 (0x10e28c00 0x1595f800 0x0 0x0)
0x85ffbd88 : 0x306310 (0xa000000 0xc0106213 0x85ffbed0 0x3)
0x85ffbdc8 : 0x2f9788 (0x85ffbde8 0x3 0x85ffbe18 0x57e444)
0x85ffbe18 : 0x2ee200 (0x18369970 0xc0106213 0x85ffbed0 0x3)
0x85ffbe78 : 0x46a2b2 (0x1109c700 0xc0106213 0x85ffbed0 0x85ffbf50)
0x85ffbe98 : 0x495c0a (0x1109c700 0xc0106213 0x85ffbed0 0x85ffbf50)
0x85ffbf78 : 0x4ee5dc (0x11093a80 0x1040e2e0 0x1040e324 0x0)
0x85ffbfc8 : 0x29deb8 (0x1219b680 0x0 0x10 0x0)
      Kernel Extensions in backtrace (with dependencies):
         com.broadcom.crystalhd.driver(0.9.26)@0x16ef000->0x16f9fff

BSD process name corresponding to current thread: XBMC

Mac OS version:
10C540

Kernel version:
Darwin Kernel Version 10.2.0: Tue Nov  3 10:37:10 PST 2009; root:xnu-1486.2.11~1/RELEASE_I386
System model name: MacPro1,1 (Mac-F4208DC8)


in the xbmc log :
Code:
21:39:11 T:2691036416 M:9397776384   DEBUG: SECTION:LoadDLL(libcrystalhd.dylib)
21:39:11 T:2691036416 M:9397862400   DEBUG: Loading: libcrystalhd.dylib
21:39:13 T:2691036416 M:9348304896    INFO: CrystalHD: device opened

So the lib is properly loaded.

Let me know if you need more debugging. I could also recompiled the kernel extension in 64 bits mode as a test.
The machine has 10GB or RAM .. in case this could be relevant to the fact that the kernel tries to get a physical segment address that is beyond the 32 bits address space.
R
Reply
Bobby Blixberg Wrote:With current SVN r26711 it has become worse.
Even 720p files that played well with previous releases are stuttering every 1 - 2 seconds - say nothing of 1080p files Confused

I'm seeing the same increased stuttering the current SVN.

Thanks
Reply
I have installed my card into my Mini but don't think it is being detected properly. I have installed the drivers and the kext is loading successfully but no joy in r26715.

My xbmc log is stating that the device hasn't been found so the library is unloaded.

sudo dmesg is OSX returns no mention of the BCM70012 device. Is there anything else I can do/check?

I have tried reseating the card to ensure its not an installation error.

Thanks
Ian

edit - OSX 10.4.11 btw
Reply
rpineau Wrote:SO I recompiled the lspci kernel extension as well as the lspci tools (2.9) and lspci does see the BCM70012. So this is a good sign Smile :

12:00.0 Multimedia controller: Broadcom Corporation BCM70012 Video Decoder [Crystal HD] (rev 01)


XBMC still crash the box and here is the relevant part of the report to be sent after reboot :
Code:
Wed Jan 13 20:38:06 2010
panic(cpu 3 caller 0x55648d): "getPhysicalSegment() out of 32b range 0x105d97000, len 0x1000, class IOBufferMemoryDescriptor"@/SourceCache/xnu/xnu-1486.2.11/iokit/Kernel/IOMemoryDescriptor.cpp:1597
Backtrace (CPU 3), Frame : Return Address (4 potential args on stack)
0x85ffbbc8 : 0x21b2bd (0x5cf868 0x85ffbbfc 0x223719 0x0)
0x85ffbc18 : 0x55648d (0x5d8d28 0x5d97000 0x1 0x1000)
0x85ffbc68 : 0x16f7c5a (0x1ff0d680 0x0 0x85ffbc8c 0x0)
0x85ffbca8 : 0x16f76bb (0x1ffbe004 0x1 0x70154054 0x3058)
0x85ffbce8 : 0x16f16b6 (0x10e28c00 0x400 0x22c 0x10e12004)
0x85ffbd08 : 0x16f1349 (0x10e28c48 0x10e12004 0x0 0x6d5f2)
0x85ffbd48 : 0x16f0664 (0x10e28c00 0x1595f800 0x0 0x0)
0x85ffbd88 : 0x306310 (0xa000000 0xc0106213 0x85ffbed0 0x3)
0x85ffbdc8 : 0x2f9788 (0x85ffbde8 0x3 0x85ffbe18 0x57e444)
0x85ffbe18 : 0x2ee200 (0x18369970 0xc0106213 0x85ffbed0 0x3)
0x85ffbe78 : 0x46a2b2 (0x1109c700 0xc0106213 0x85ffbed0 0x85ffbf50)
0x85ffbe98 : 0x495c0a (0x1109c700 0xc0106213 0x85ffbed0 0x85ffbf50)
0x85ffbf78 : 0x4ee5dc (0x11093a80 0x1040e2e0 0x1040e324 0x0)
0x85ffbfc8 : 0x29deb8 (0x1219b680 0x0 0x10 0x0)
      Kernel Extensions in backtrace (with dependencies):
         com.broadcom.crystalhd.driver(0.9.26)@0x16ef000->0x16f9fff

BSD process name corresponding to current thread: XBMC

Mac OS version:
10C540

Kernel version:
Darwin Kernel Version 10.2.0: Tue Nov  3 10:37:10 PST 2009; root:xnu-1486.2.11~1/RELEASE_I386
System model name: MacPro1,1 (Mac-F4208DC8)


in the xbmc log :
Code:
21:39:11 T:2691036416 M:9397776384   DEBUG: SECTION:LoadDLL(libcrystalhd.dylib)
21:39:11 T:2691036416 M:9397862400   DEBUG: Loading: libcrystalhd.dylib
21:39:13 T:2691036416 M:9348304896    INFO: CrystalHD: device opened

So the lib is properly loaded.

Let me know if you need more debugging. I could also recompiled the kernel extension in 64 bits mode as a test.
The machine has 10GB or RAM .. in case this could be relevant to the fact that the kernel tries to get a physical segment address that is beyond the 32 bits address space.
R

Very odd, the kext driver explicitly requests physical DMA memory to be below the 4GB boundary. Someone is not paying attention Smile I will look at this under 10.6 this weekend.
Reply
davilla Wrote:Very odd, the kext driver explicitly requests physical DMA memory to be below the 4GB boundary. Someone is not paying attention Smile I will look at this under 10.6 this weekend.

Ok, Thanks.

In the mean time I recompiled the kext in 64 bits (a few changes were needed but nothing drastic) and I'll try with this sometimes tomorrow.

R.
Reply
So with my 64 bits version of the kernel extension, xbmc no longer crash and I can select the crystal HD as the video playback render option.
If you want my patches for the 64 bits code let me know.

R.
Reply
rpineau Wrote:So with my 64 bits version of the kernel extension, xbmc no longer crash and I can select the crystal HD as the video playback render option.
If you want my patches for the 64 bits code let me know.

R.

sure, email to davilla [at] xbmc [dot] org, thanks.
Reply
Well , I might have speak to soon. I still get the same error from time to time.
Even if the kext is now said to be 64 bits :
Code:
BroadcomCrystalHD:

  Version:    0.9.26
  Last Modified:    Friday 15/1/10 16:57
  Kind:    Intel
  Architectures:    i386, x86_64
  64-Bit (Intel):    Yes
  Location:    /System/Library/Extensions/BroadcomCrystalHD.kext
  Kext Version:    0.9.26
  Load Address:    0x16ef000
  Valid:    Yes
  Authentic:    Yes
  Dependencies:    Satisfied

The error still show an issue with 32 bit addressing :
Code:
panic(cpu 0 caller 0x55648d): "getPhysicalSegment() out of 32b range 0x15dfc6000, len 0x1000, class IOBufferMemoryDescriptor"@/SourceCache/xnu/xnu-1486.2.11/iokit/Kernel/IOMemoryDescriptor.cpp:1597

The rest of the stack trace is similar to the one I posted before.

So it looks like there is still an issue and as my Mac Pro is a 2006 model I "can't" run the kernel in pure 64 bits and that's probably part of the problem as at some point there are 32 bits calls being done to the kernel.

I'll send you a tgz of the xcode project as I had to tweak it to build 32 and 64 bits in the same kext so that you can see what I did.
Look for the #ifndef __LP64__ in the code (in crystalhd_misc.c and linux_compatible.c).

So it looks like there is still a need to fix the 32 bit issue to make sure the kext request a DMA buffer below 4GB.

R.
Reply
  • 1
  • 15
  • 16
  • 17
  • 18
  • 19(current)

Logout Mark Read Team Forum Stats Members Help
[AppleTV] Compiling crystalhd-for-osx Lib/Kext0