nForce OS X Snow Leopard (10.6) RETAIL INSTALL GUIDE on a Series 6 or 7 nForce chipset / Intel CPU MOBO

[MasterTiiro]

On the sound issue-try reinstalling your audio kext. I'm using voodooHDA kext.

 

Hi all,

 

After a long struggle, I managed to get SL to install on my P5N32-E SLI motherboard

 

Everything is working except for network??? Can't seem to get that to work? Any advice?

 

I'm using Chameleon 2.0 RC4 with PC EFI 10.6 (latest). I use the -x32 boot flag, but everyone seems to recommend arch=i386. What is the difference? On that topic - it would seem IMPOSSIBLE to boot into 64bit mode?

 

I've also lost audio again after the update to 10.6.3 - Any pointers on getting that back?

 

My 8800GTS Graphics card "just seems to work"? Not 100% sure from the notes if I need to mess with EFI and stuff??

 

 

Oh, I managed all of this without access to another mac - Took me long enough!!

 

Thanks,

D.

[verdant]

Woo. Thanks a bunch.

 

I just encoded some video, unRared using stuffit and they worked fine. I only had one torrent to test resuming with and it worked so for now I'm going to assume everything is ok. The real testing will be once I get Final Cut installed. Now the only two things left to worry about is my sata DVD drives and the clock. From what I read there is nothing really I can do for the DVD drives but wait until some writes working drivers. As for my clock issue, I cannot get it it to sync with my bios and Windows partition. I have windows set to sync on reboot but cannot seem to find a way to do that with OSX unless I use a third party application which I rather not do. Someone suggested I try OSX Time Sync Fix by Zephyroth however, I installed it and it doesn't seem to change a thing. Any ideas?

 

For solving the clock time sync issue, see this entry in my blog.......

 

BTW it would helpful to always be reminded of your system specs in a signature........

[verdant]

Hi all,

 

After a long struggle, I managed to get SL to install on my P5N32-E SLI motherboard

 

Everything is working except for network??? Can't seem to get that to work? Any advice?

 

I'm using Chameleon 2.0 RC4 with PC EFI 10.6 (latest). I use the -x32 boot flag, but everyone seems to recommend arch=i386. What is the difference? On that topic - it would seem IMPOSSIBLE to boot into 64bit mode?

 

I've also lost audio again after the update to 10.6.3 - Any pointers on getting that back?

 

My 8800GTS Graphics card "just seems to work"? Not 100% sure from the notes if I need to mess with EFI and stuff??

 

 

Oh, I managed all of this without access to another mac - Took me long enough!!

 

Thanks,

D.

 

Well done for getting to this stage without access to another Mac......did you use Windows/Transmac or what.....?

 

As regards boot flags, see post #1....., the 32bit mode bootflag for the PC_EFI v10.0 to v10.2 boot files is -x32 whereas for Chameleon 2.0, you should use arch=i386 as the 32bit mode boot flag.......but PC_EFI v10.3 and later version boot files are based on Chameleon 2.0......

 

To boot into 64bit mode, all non-Apple kexts need to be fully functional when loaded in the 64bit kernel but from most reports, this is still not the case for AppleNForceATA.kext at present.......

 

See one solution in post #2 NEWS UPDATES.......doing so may work for your audio setup......

 

If you have a transparent Finder top menu bar, then you have CI/QE.......in which case your video is working OK

[verdant]

I still get random lockups. I seem to get it from CPU intensive usage, but sometimes even just watching videos on the browser can trigger it. Whenever I get lockups, I'd wait for 5 minutes before I manually reboot the system, but still couldn't see any debug info on screen. What am I doing wrong?

 

Here's my current com.apple.Boot.plist:

 

Try debug=0x144 instead of debug=0x100

 

Which version of AppleNForceATA.kext do you have installed?

[Dawid Mostert]

Well done for getting to this stage without access to another Mac......did you use Windows/Transmac or what.....?

 

As regards boot flags, see post #1....., the 32bit mode bootflag for the PC_EFI v10.0 to v10.2 boot files is -x32 whereas for Chameleon 2.0, you should use arch=i386 as the 32bit mode boot flag.......but PC_EFI v10.3 and later version boot files are based on Chameleon 2.0......

 

To boot into 64bit mode, all non-Apple kexts need to be fully functional when loaded in the 64bit kernel but from most reports, this is still not the case for AppleNForceATA.kext at present.......

 

See one solution in post #2 NEWS UPDATES.......doing so may work for your audio setup......

 

If you have a transparent Finder top menu bar, then you have CI/QE.......in which case your video is working OK

 

I looked at and used bits from various guides. At the end I used Parted Magic to initialize the drive as GUIDED, create and install a Chameleon partition and create a partially working SL installation partition. I then managed to boot using the installer partition and create a PROPER install image from my DMG....

 

Any tips on my networking? I've only got my onboard NForce network controllers to use..... (The LAST important bit to get working! )

 

Thanks for the guide...

 

D

[verdant]

I looked at and used bits from various guides. At the end I used Parted Magic to initialize the drive as GUIDED, create and install a Chameleon partition and create a partially working SL installation partition. I then managed to boot using the installer partition and create a PROPER install image from my DMG....

 

Any tips on my networking? I've only got my onboard NForce network controllers to use..... (The LAST important bit to get working! )

 

Thanks for the guide...

 

D

 

Have you not tried eno's nForceLAN.kext?......my Snow_Support_Files_V2.3 includes the installer for it.........

[MasterTiiro]

I'll switch to your new advice and see if that works.

 

I'm now using Slash's kext, but I was using the other one.

 

Try debug=0x144 instead of debug=0x100

 

Which version of AppleNForceATA.kext do you have installed?

[verdant]

I'll switch to your new advice and see if that works.

 

I'm now using Slash's kext, but I was using the other one.

 

I have found slashack's kext to be pretty stable......I am trying out AnV's SL AppleNForceATA.kext in 32bit mode at present......

[Dawid Mostert]

Have you not tried eno's nForceLAN.kext?......my Snow_Support_Files_V2.3 includes the installer for it.........

 

Thanks verdant!

 

Finally posting from inside SL.....

 

How am I supposed to replace the AppleHDA.kext? Drag to trash and copy the new one from Support Files 2.3?

 

I see things move fast around here - when I started my "journey" a couple of days ago, Support Files 2.2 was the latest and greatest!

 

Regards,

D

[verdant]

Thanks verdant!

 

Finally posting from inside SL.....

 

How am I supposed to replace the AppleHDA.kext? Drag to trash and copy the new one from Support Files 2.3?

 

I see things move fast around here - when I started my "journey" a couple of days ago, Support Files 2.2 was the latest and greatest!

 

Regards,

D

 

Glad to help.......

 

Open Terminal.....then:

 

Rename 10.6.3 AppleHDA.kext:

 

cd /System/Library/Extensions
sudo mv AppleHDA.kext AppleHDA.kext.orig
exit

 

Drag 10.6.2 AppleHDA.kext into /S/L/E and repair Extensions ownership and permissions using Kext Utility v2.4.2......

[RaMDaY]

For solving the clock time sync issue, see this entry in my blog.......

 

BTW it would helpful to always be reminded of your system specs in a signature........

Thanks for the tip about the time. The spinning balls still pops up from time to time but no where as much as before. It happen once when encoding some more video and when I tried to install Final Cut. For both tasks I restarted, tried again and they worked no problem. Its seems now that if I try to do these things and then do something simple in the background (browse the web, talk on AIM, click around and view data on my hard drives) at the same time I get the beach ball. If I just let the task go and not doing anything else then it goes through fine. I never removed the debug=0x100 string from my plist and never saw any text pop up or anything when I got the never ending beach balls.

[verdant]

Thanks for the tip about the time. The spinning balls still pops up from time to time but no where as much as before. It happen once when encoding some more video and when I tried to install Final Cut. For both tasks I restarted, tried again and they worked no problem. Its seems now that if I try to do these things and then do something simple in the background (browse the web, talk on AIM, click around and view data on my hard drives) at the same time I get the beach ball. If I just let the task go and not doing anything else then it goes through fine. I never removed the debug=0x100 string from my plist and never saw any text pop up or anything when I got the never ending beach balls.

 

Try debug=0x144 in place of debug=0x100

 

Are you using slashack's AppleNForceATA.kext? If not, try it.........

[RaMDaY]

Try debug=0x144 in place of debug=0x100

 

Are you using slashack's AppleNForceATA.kext? If not, try it.........

 

I'm currently using the kext found here

 

 

http://www.insanelymac.com/forum/index.php?showtopic=211866

 

I tried the AppleNForceATA.slash.kext in your Snow Support Files pack before I changed my plist file like you suggested so I'll give it a now with the new settings.

[RaMDaY]

I tried Slashack's AppleNForceATA.kext and got the same spinning ball problem while encoding some more video. I also tried debug=0x144 and didn't get any error messages or anything. Also, the Slash kext doesn't like to load my hard drive when I connect to any of my on board firewire ports. Only the port on my Audigy2 ZS card works.

[verdant]

I tried Slashack's AppleNForceATA.kext and got the same spinning ball problem while encoding some more video. I also tried debug=0x144 and didn't get any error messages or anything. Also, the Slash kext doesn't like to load my hard drive when I connect to any of my on board firewire ports. Only the port on my Audigy2 ZS card works.

 

Firewire can be problematic.......the Southbridge MCP chipset controls all the device I/O such as USB, SATA, PATA and Firewire.......what is your MOBO's Firewire chipset?......is it TI or VIA for example? You can use OSxTools to install lspci and find out.....or DPCIManager.....

 

 

UPDATE:

 

Information from M-Audio FireWire Series FAQ's

FireWire was developed by a partnership of Apple, Texas Instruments, and several other companies. FireWire is a great method for transferring streaming data like audio and video, which require a lot of bandwidth and CANNOT have the signal interrupted without serious degradation to the signal. Because this format was developed by Apple, the architecture is optimized for Apple systems. Some PC manufacturers don’t do as well as others integrating this technology. PC’s base their architecture on a system of interrupts, and typically use synchronous data transfer. FireWire uses asynchronous data transfer, or a specialized version of asynchronous data transfer called isochronous data transfer. Synchronous transfer will guarantee that data packages will be delivered, but will not guarantee that they will be delivered at a certain time. Asynchronous transfer guarantees that packages will be delivered at a certain time, but if there is interference or delay, the packages may be dropped and will not be re-sent. This means that no data will be lost when using synchronous mode, but it could happen that packages are delivered late because they are re-sent if they are lost for some reason. For audio, it's useless if packages arrive late. Late audio is delayed audio and pauses in the audio. The guarantee that audio is delivered on-time is what s important to digital audio; and that's why FireWire audio devices use the asynchronous transfer. Any lost packages will appear as audio drop outs. So, as you can see it is important that FireWire data is not interrupted. However, PC architecture (ACPI) is built on the concept of interrupts. While the interrupts of Windows systems may be problematic, firewire audio can operate efficiently if the data is managed correctly. This is where the FireWire controller chipset is VERY important. Because timing is so important, there are many controls which manage the FireWire bus to ensure the high transfer rate. The FireWire controller must initialize and release FireWire devices connected to the computer, communicate with all FireWire devices connected to the bus, assist those devices in dedicating a single clock for the timing of the entire FireWire bus, manage the electrical power distributed to the devices, construct a hierarchy of device priority in the system, and manage the data being transferred. There are several FireWire chipset developers that build chips that are significantly cheaper than Texas Instruments, and for this reason, PC manufacturers are starting to use these less expensive chipsets. Unfortunately, many of these other chipsets are not as reliable as those manufactured by Texas Instruments. M-Audio cannot simply say only use Texas Instruments chipsets, because some of these other controllers actually work very well, and M-Audio does not want to endorse any particular manufacturer. Some firewire chipset manufacturers are improving the quality of their controllers, but when problems are encountered, the chipset is the first place to look. When a chipset is in question, M-Audio does recommend using the controller chipsets which have a history of being the most reliable. Even if your motherboard has an on-board FireWire controller with a Texas Instruments chipset, you may encounter problems because all onboard devices, including the FireWire controller, are run through the Southbridge of the processor. This means that there is a lot of traffic that the FireWire signal must compete with for access to the processor (all USB, onboard audio, onboard video, serial ports, network controllers, etc...). Data coming from all of these devices creates a bottleneck and greatly increases the chance of the FireWire signal being interrupted. The interrupted data is dropped to maintain the delivery time of the rest of the data. When too much data is dropped, the audio signal may be appear as distorted, completely dropped, or the computer may even drop the connection with the FireWire audio device. To avoid this on a PC, we always advise installing a dedicated FireWire card. This is because the PCI bus runs to the Northbridge of the processor. The Northbridge provides more reliable access to the processor because it only manages the data from the PCI, AGP, and memory.

[breakingbad]

@verdant.

Hello mate... passing around to see what's happening to the nForce Side of the Moon. LOL !

How things going around here?

 

I read the message about FireWire issues and found it interesting and got myself thinking... I don't have a FireWire port in my mobo... and soon I realized that the Camcorder I bought is only compatible with mac using FireWire ports... shame on me. LOL !

 

Could you get any ideas about the DSDT stuff you're looking for with Cartri?

 

Well, gotta go by now. I gotta say that sometimes I miss my nForce mobo and all its issues with OS X. But I can't complain... my Gigabyte board works damn fine and in a certain way, I have to deal with some issues with it too. Less issues it's true, but sitll have issues.

 

Let me know if there's something I can help you with.

 

Cheers,

bb.

[The Sauce]

BB!!!!!!!!! na Paz Cara. I got snow Leo working properly than to verdant. LoL except for sleep of course! LoL falamos irmão! Liga no msn quando tenha o tempo.

[Dilemma Prison]

Verdant's post is interesting. I have had no issues with the Agere/Lucent chipset on a PCI board yet. I've not tried capturing from a firewire camera (I shall test it this weekend and repost!). I have a vague memory of dealing with troubleshooting issues on real macs, in the form of some specialty devices not working with some add-in boards and older chipsets due too their lack of proper support for particular IO modes (This is back in the OS 9 days). I suppose it makes sense.

 

I shall test my trv900 camera / a dv video bridge i have laying around on my hack and at least find out if capture is workable via a non-TI based PCI card.

 

I can't help but feel that it is either that northbridge/southbridge issue, or a issue in the way that apple deals with TI chipsets (given that they are the flavor of PHY used on real macs).

 

also : i have some advice when testing firewire that is rather important. . . .

 

Depending on the power mode your firewire is defaulting to, you may not have hot-plug functionality. If your testing firewire you need to test with the device plugged in and active at boot AND test it powered up after boot. This issue can be fixed on some hardware combos with a dsdt edit. Most of the posts i breezed over mentioned 'Firewire Power Conservation'

 

@verdant.

Hello mate... passing around to see what's happening to the nForce Side of the Moon. LOL !

How things going around here?

 

I read the message about FireWire issues and found it interesting and got myself thinking... I don't have a FireWire port in my mobo... and soon I realized that the Camcorder I bought is only compatible with mac using FireWire ports... shame on me. LOL !

 

Could you get any ideas about the DSDT stuff you're looking for with Cartri?

 

Well, gotta go by now. I gotta say that sometimes I miss my nForce mobo and all its issues with OS X. But I can't complain... my Gigabyte board works damn fine and in a certain way, I have to deal with some issues with it too. Less issues it's true, but sitll have issues.

 

Let me know if there's something I can help you with.

 

Cheers,

bb.

[verdant]

Verdant's post is interesting. I have had no issues with the Agere/Lucent chipset on a PCI board yet. I've not tried capturing from a firewire camera (I shall test it this weekend and repost!). I have a vague memory of dealing with troubleshooting issues on real macs, in the form of some specialty devices not working with some add-in boards and older chipsets due too their lack of proper support for particular IO modes (This is back in the OS 9 days). I suppose it makes sense.

 

I shall test my trv900 camera / a dv video bridge i have laying around on my hack and at least find out if capture is workable via a non-TI based PCI card.

 

I can't help but feel that it is either that northbridge/southbridge issue, or a issue in the way that apple deals with TI chipsets (given that they are the flavor of PHY used on real macs).

 

also : i have some advice when testing firewire that is rather important. . . .

 

Depending on the power mode your firewire is defaulting to, you may not have hot-plug functionality. If your testing firewire you need to test with the device plugged in and active at boot AND test it powered up after boot. This issue can be fixed on some hardware combos with a dsdt edit. Most of the posts i breezed over mentioned 'Firewire Power Conservation'

 

Regarding "hot-plugging" of Firewire devices, here is some interesting information from M-Audio:

Caution: Do Not Hot-Plug FireWire Devices

Text size [-] [+]

 

Reports have come to our attention of isolated problems when hot-plugging IEEE 1394 (aka “FireWire”) devices. (Hot-plugging refers to making 1394/FireWire connections when one or more of the devices—including the computer—is on.)

 

When hot-plugging, there are rare occurrences where either the FireWire peripheral or the FireWire port on the host computer is rendered permanently inoperable. While M-Audio products adhere rigidly to the FireWire industry standard and pass stringent internal testing, the possibility remains that hot-plugging your M-Audio FireWire interface with some computers may result in the type of problem described here.

 

We strongly encourage you to protect your equipment by refraining from hot-plugging any bus-powered FireWire device, including the M-Audio family of FireWire products. Connect your FireWire device while both the computer and FireWire device are powered off. Power on the FireWire device, then turn the computer on last. If you are using bus power (systems with IEEE1394 6-pin connectors) make sure you make the cable connection first, then turn the FireWire device power switch on, and turn the computer system on last.

 

For a technical explanation about how hot-plugging a firewire device can damage the host or the device, please read this documentation by Texas Intruments.

 

M-Audio is being proactive in investigating any issues that may adversely affect our customers. Please consult the Knowledge Base in the Support section at www.m-audio.com for updates on this important issue.

 

 

In case your M-Audio FireWire device is not detected by your computer on startup, try one or more of the following troubleshooting steps instead of hotplugging it:

 

1. Turn your M-Audio FireWire device off, wait 30 seconds then power it on.

 

2. Restart the computer (don’t turn it off) while the M-Audio FireWire device remains connected and powered on.

 

Given that M-Audio have such a strong activity in the use of the Firewire interface for audio signals, I personally follow their advice.........

 

 

@verdant.

Hello mate... passing around to see what's happening to the nForce Side of the Moon. LOL !

How things going around here?

 

I read the message about FireWire issues and found it interesting and got myself thinking... I don't have a FireWire port in my mobo... and soon I realized that the Camcorder I bought is only compatible with mac using FireWire ports... shame on me. LOL !

 

Could you get any ideas about the DSDT stuff you're looking for with Cartri?

 

Well, gotta go by now. I gotta say that sometimes I miss my nForce mobo and all its issues with OS X. But I can't complain... my Gigabyte board works damn fine and in a certain way, I have to deal with some issues with it too. Less issues it's true, but sitll have issues.

 

Let me know if there's something I can help you with.

 

Cheers,

bb.

 

Hi bb,

 

Firewire is a good interface (despite its issues on PCs) because it imposes little overhead on the CPU compared with USB and so even Firewire 400 generally gives a faster "real" data transfer rate than USB 2.0.......with Firewire being much faster than USB 20.0........see here

[verdant]

@ bb

 

Good to see you passing by and still finding out useful information on Firewire on the "nForce Side of the Moon"........ yesterday, I was listening to the Dark Side of the Moon again.....LOL

 

I have not been in further contact with Cartri on BIOS/DSDT stuff..........I want to learn more about ASL etc. before contacting him again.........

 

But as usual I have been side-tracked again, helping newbies with Snow Leopard on nForce MOBO stuff...... with the result that I have had to write a new Install Guide entry in my blog on installing Snow Leopard 10.6.3 on my nForce MOBO using Hazard's Snow Leopard Install DVD distro BUT then recommending:

 

Despite a successful installation and updating to OS X 10.6.3, MY RECOMMENDATION is to do a full vanilla Snow Leopard Retail OS X Install DVD installation, with the necessary non-vanilla kexts placed, if at all possible, only in /Extra/Extensions/, using my nForce GUIDE to INSTALL Snow Leopard (10.6) on a Series 6 or 7 nForce chipset / Intel Core2 Duo or Quad or newer CPU MOBO, which explains how to do a successful installation of Snow Leopard 10.6 using either a USB flash drive installer method, or my nForceSLBoot132DVD method........ angel.png

 

Thanks for the offer of help......

 

@ Majestus

 

I can tell you are still excited about my guide having helped you get Snow Leopard running.......

[Dilemma Prison]

a bit of personal advice with some m-audio firewire interfaces and one of those snippits you posted : (i find some amusement with the whole 'rendered permanently inoperable.' thing in the maudio guide) some m-audio firewire audio interfaces can fry a fw port when hotplugging. or fault the real smu/cuda whatever on a real mac. i had a customer with a mid-sized m-audio firewire audio IO who blew a mainboard twice; turned out that hotplugging with a lot of live gear attached was causing his ports to blow. (I have personally seen a large sticker on the back of the 410 model that says not to hot-plug it)

 

as to hot plugging in general ; I've attached/detached bus powered drives to and from thousands of different macintoshes over the years and never fried a port / bridge / mainboard with the computer running. However; it pays to be cautious with large daisy chains of powered devices or any high power device in general. You can get away with plugging 3 or more 2.5 inch bus powered drives into some firewire interfaces. . but the spec is fairly broad and not all manufacturers build their products up to spec. I've encountered non-bus powered drives with messed up bridges that fry anything you plug them in to. I've seen firewire bridges fuse from lightning strikes and blow ports (and motherboards) they were hooked to afterwards. Some mainboard/case-accessory manufacturers have produced header cables and front panel interfaces with questionable wiring which sometimes results in shorts on the firewire bus that can take out mainboards when hotplugged. Worn-down firewire plugs also can cause shorts.

 

Those ports can put out up to 9-30 volts ~ 40-45watts of power, or so i have read.

 

The firewire ports on some of the G4/G5 towers are a good example; providing juice to melt hubs produced by less than reputable manufacturers. (yeah, they actually melted >.<)

[verdant]

a bit of personal advice with some m-audio firewire interfaces and one of those snippits you posted : (i find some amusement with the whole 'rendered permanently inoperable.' thing in the maudio guide) some m-audio firewire audio interfaces can fry a fw port when hotplugging. or fault the real smu/cuda whatever on a real mac. i had a customer with a mid-sized m-audio firewire audio IO who blew a mainboard twice; turned out that hotplugging with a lot of live gear attached was causing his ports to blow. (I have personally seen a large sticker on the back of the 410 model that says not to hot-plug it)

 

as to hot plugging in general ; I've attached/detached bus powered drives to and from thousands of different macintoshes over the years and never fried a port / bridge / mainboard with the computer running. However; it pays to be cautious with large daisy chains of powered devices or any high power device in general. You can get away with plugging 3 or more 2.5 inch bus powered drives into some firewire interfaces. . but the spec is fairly broad and not all manufacturers build their products up to spec. I've encountered non-bus powered drives with messed up bridges that fry anything you plug them in to. I've seen firewire bridges fuse from lightning strikes and blow ports (and motherboards) they were hooked to afterwards. Some mainboard/case-accessory manufacturers have produced header cables and front panel interfaces with questionable wiring which sometimes results in shorts on the firewire bus that can take out mainboards when hotplugged. Worn-down firewire plugs also can cause shorts.

 

Those ports can put out up to 9-30 volts ~ 40-45watts of power, or so i have read.

 

The firewire ports on some of the G4/G5 towers are a good example; providing juice to melt hubs produced by less than reputable manufacturers. (yeah, they actually melted >.<)

 

Tell me about it....LOL

 

You are correct......the problem is that the spec is fairly broad and not all manufacturers build their products up to spec. or perhaps more importantly, build them to cope with the low and high end of the spec!

 

I have recently had personal experience of this.......I plugged my PowerMac Dual 2.0 G5 Firewire 400 cable into my PowerMac G3 Combo USB/400 Firewire PCI card (NEC chipset), which was working 100%, to do a Target Mode transfer and heard a very LOUD POP from the G3........the G5 Firewire output was sufficient to blow a capacitor on the card to "debris" covering the other board components.......the ruptured metal capacitor can was empty!

 

The reason is apparently that the G5 Firewire ports operate at nominally 30V (and hence even up to 33V as some have measured) to enable them to power a large Firewire daisychain, whereas as 3rd party manufacturers of PCI Firewire cards, especially generic ones for PC/Mac use, typically operate up to nominally 12V to 15V........

[Dilemma Prison]

Tell me about it....LOL

 

You are correct......the problem is that the spec is fairly broad and not all manufacturers build their products up to spec. or perhaps more importantly, build them to cope with the low and high end of the spec!

 

I have recently had personal experience of this.......I plugged my PowerMac Dual 2.0 G5 Firewire 400 cable into my PowerMac G3 Combo USB/400 Firewire PCI card (NEC chipset), which was working 100%, to do a Target Mode transfer and heard a very LOUD POP from the G3........the G5 Firewire output was sufficient to blow a capacitor on the card to "debris" covering the other board components.......the ruptured metal capacitor can was empty!

 

The reason is apparently that the G5 Firewire ports operate at nominally 30V (and hence even up to 33V as some have measured) to enable them to power a large Firewire daisychain, whereas as 3rd party manufacturers of PCI Firewire cards, especially generic ones for PC/Mac use, typically operate up to nominally 12V to 15V........

 

Sorry to hear that >.<

 

I have always been rather reluctant to interconnect any target mode mac to anything but another mac.

 

On a side note, i have heard of people making 6-6 pin firewire cables with the two power wires cut for that sort of thing. I remember reading about it in the AASP mailing list.

 

Some of my PCI firewire cards have 6 pin plugs but a visual examination reveals that the power leads aren't even hooked up! (bare space on the board for a floppy power connector). I really wish vendors would follow spec. It would almost make life easier if they put 4 pin ports on anything that isn't going to handle the full range of the spec :/

[Kilopopo]

Maybe someone can help me here

 

I got the usb installer working everything boots towards the installer but when i install 10.6 - just the base system - i get kernel panic thread at Mac OS X Install\

 

 

i tried prasys way of mediating the problem by removing frambuffers kext and patching osinstall and osinstall.mpkg but it still goes to kernel panic.

 

 

please if anyone has managed solve this kernel panic let me know please.

[verdant]

Maybe someone can help me here

 

I got the usb installer working everything boots towards the installer but when i install 10.6 - just the base system - i get kernel panic thread at Mac OS X Install\

 

 

i tried prasys way of mediating the problem by removing frambuffers kext and patching osinstall and osinstall.mpkg but it still goes to kernel panic.

 

 

please if anyone has managed solve this kernel panic let me know please.

 

It would be helpful if you updated your signature.........

 

The error message is indicating that your kernel has not been located and/or loaded.......

 

1. Carefully double-check your BIOS settings against the 650i template for OS X in my Pre-series 7 nForce thread post #1......

 

2. Unhide the system and hidden files on your USB Installer volume, to check that you have the vanilla SL mach_kernel in the / directory and that in the com.apple.Boot.plist file in both /Extra/ and in Library/Preferences/SystemConfiguration/, you have:

 

<key>Kernel</key>
<string>mach_kernel</string>

 

3. Use Terminal to repair ownership and permissions on the kernel installed on your USB Installer volume:

 

sudo chown root:wheel /Volumes/"Your USB installer name"/mach_kernel
sudo chmod 644 /Volumes/"Your USB installer name"/mach_kernel
exit

 

4. Use Terminal to repair ownership and permissions on the Extensions folder (and its contents) installed on your USB Installer volume:

 

sudo chown -R root:wheel /Volumes/"Your USB installer name"//Extra/Extensions/
sudo chmod -R 755 /Volumes/"Your USB installer name"/Extra/Extensions/
sudo touch /Volumes/"Your USB installer name"/Extra/Extensions/
exit

 

5. Boot your USB Installer with

 

-v -f arch=i386

 

If that still does not work, then try

 

-v -f arch=i386 cpus=1 maxmem=2048