This afternoon I have been testing the Rev. F DSDT on my DC7800 SFF. I could not find a DC7800 SFF tester, so I temporarily reactivated my own.
Works on Lion for sure.
Will probably work on Mountain Lion once I change the boot loader, which I'm NOT got to do at the present time.
This Lion system is based upon iATKOS L, the one from which those special kexts were extracted and which proved to be so necessary for OS X compatibility with the DC7800's non-AHCI disk subsystem.
So ...
I can now report, with confidence, that the Rev. F DSDT works on:
DC7800 SFF (with Lion, and most probably Mountain Lion; I did the testing)
DC7800 CMT (I'm not sure which OS X that particular tester used)
DC7900 CMT (With Mountain Lion, and most probably Lion; I did the testing)
I have no access to a DC7900 SFF.
Both Rev. F DSDTs which I have released are for CMTs, although the BIOSes from which each were obtained were a highest-level DC7800 SFF/CMT BIOS or a highest-level DC7900 SFF/CMT BIOS, hence these DSDTs appear to be applicable to SFFs/CMTs, as was my intention.
Also, I am most probably going to change my DC7800 CMT (C2Q E6850) which was converted to a DC7900 BACK to a DC7800 CMT and elevate my DC7900 CMT (C2Q E8400) to my primary hp/Compaq machine.
Many thanks to all testers. The DC7800/DC7900 project appears to be a resounding success.
> Also, I am most probably going to change my DC7800 CMT (C2Q E6850) which
> was converted to a DC7900 BACK to a DC7800 CMT and elevate my DC7900 CMT
> (C2Q E8400) to my primary hp/Compaq machine.
> I can now report, with confidence, that the Rev. F DSDT works on:
> DC7800 SFF (with Lion, and most probably Mountain Lion; I did the testing)
I can confirm that the "resume from suspend" function works on a DC7800 as
well.
Should you switch your monitor and keyboard away from the DC7800 for
(about) ten minutes (probably as set in System Preferences...) and then
switch these back, the monitor may be dark and the keyboard may be
unresponsive. If so, simply depress the power button once and the monitor
and keyboard will return to that state which existed before the suspend
was initiated.
The DC7900 works the same way, as was previously reported.
You may notice a sight difference between IORegistryExplorer outputs from
DC7800 and DC7900. This is because the DC7800 requires a special kext
(thanks to iATKOS) to map the SATA devices into the IDE-oriented DC7800
BIOS. The DC7900 BIOS fully supports ACHI (as well as IDE) so this kext is
not required, but it will not cause an error if it is present.
Remember: on DC7800s, select IDE mode; on DC7900s select ACHI mode.
That which I have referred to a "resume from suspend" is really a consequence of STR ... "Suspend to RAM", where a snapshot of the machine's state is written to RAM and all except the RAM are powered-down.
Pressing the power button once results in restoration of the machine's state exactly as before.
Long inactivity, even with the keyboard and monitor connected, can also result in STR.
My previous hacks did not seem to have STR implemented.
Perhaps I went too far with the DSDTs for the DC7800 and DC7900?
would be possible to upload the DSDT please? I personally own a DC7800 and a DC7900 and would like to test it. I have only found two differnet versions of Rev C which one works pretty well but the other one had much faster boot but nvidia gt520 didnt work with it so I had to revert to previus one.
On Saturday, September 29, 2012 11:51:36 AM UTC-7, lucky79 wrote:
> Hello,
> would be possible to upload the DSDT please? I personally own a DC7800 and > a DC7900 and would like to test it. I have only found two differnet > versions of Rev C which one works pretty well but the other one had much > faster boot but nvidia gt520 didnt work with it so I had to revert to > previus one.
> Thanks a lot
Rev. F is the final version.
It is presently working with Lion on a DC7800 SFF and on Mountain Lion on a DC7900 CMT,
On Saturday, September 29, 2012 11:56:41 AM UTC-7, PH wrote:
> On Saturday, September 29, 2012 11:51:36 AM UTC-7, lucky79 wrote:
>> Hello,
>> would be possible to upload the DSDT please? I personally own a DC7800 >> and a DC7900 and would like to test it. I have only found two differnet >> versions of Rev C which one works pretty well but the other one had much >> faster boot but nvidia gt520 didnt work with it so I had to revert to >> previus one.
I've got a dc7800 running on os x and i would love to use your dsdt file. Can you send it to me? And I would know to like what kexts you used to make it run smooth. For know i can think of fakesmc, nullcpupowermanagement, voodoohda and ioatafamily. Am I right?
Ben
Op dinsdag 4 september 2012 02:09:49 UTC+2 schreef PH het volgende:
> This afternoon I have been testing the Rev. F DSDT on my DC7800 SFF. I > could not find a DC7800 SFF tester, so I temporarily reactivated my own.
> Works on Lion for sure.
> Will probably work on Mountain Lion once I change the boot loader, which > I'm NOT got to do at the present time.
> This Lion system is based upon iATKOS L, the one from which those special > kexts were extracted and which proved to be so necessary for OS X > compatibility with the DC7800's non-AHCI disk subsystem.
> So ...
> I can now report, with confidence, that the Rev. F DSDT works on:
> DC7800 SFF (with Lion, and most probably Mountain Lion; I did the testing)
> DC7800 CMT (I'm not sure which OS X that particular tester used)
> DC7900 CMT (With Mountain Lion, and most probably Lion; I did the testing)
> I have no access to a DC7900 SFF.
> Both Rev. F DSDTs which I have released are for CMTs, although the BIOSes > from which each were obtained were a highest-level DC7800 SFF/CMT BIOS or a > highest-level DC7900 SFF/CMT BIOS, hence these DSDTs appear to be > applicable to SFFs/CMTs, as was my intention.
> Also, I am most probably going to change my DC7800 CMT (C2Q E6850) which > was converted to a DC7900 BACK to a DC7800 CMT and elevate my DC7900 CMT > (C2Q E8400) to my primary hp/Compaq machine.
> Many thanks to all testers. The DC7800/DC7900 project appears to be a > resounding success.
> On Saturday, September 29, 2012 11:56:41 AM UTC-7, PH wrote:
> On Saturday, September 29, 2012 11:51:36 AM UTC-7, lucky79 wrote:
> Hello,
> would be possible to upload the DSDT please? I personally own a DC7800 and a DC7900 and would like to test it. I have only found two differnet versions of Rev C which one works pretty well but the other one had much faster boot but nvidia gt520 didnt work with it so I had to revert to previus one.
> Thanks a lot
Sorry, must of missed this. The rev F DSDT can be found at :
> 4 - The un-modified version of the .dsl file won't compile either, iasl shows the same error.
> How can I compile the .dsl file? I'm not using the correct version of iasl, I guess.
There must be several revisions for this board as I never had any problems with mine, other than the initial problem with the Lion installer not being able to see my internal hard drives. Here are some things to try:
1. Try booting up without using a DSDT at all.
2. Try the iAtKOS L2 install.
3. Try a retail install using the MultiBeast no DSDT option.
As for not being able to compile the DSDT, you might give DSDTSE a try if you haven't already. Link to it can be found here:
>> How can I compile the .dsl file? I'm not using the correct version of
>> iasl, I guess.
> There must be several revisions for this board as I never had any problems
> with mine, other than the initial problem with the Lion installer not
> being able to see my internal hard drives. Here are some things to try:
> 1. Try booting up without using a DSDT at all.
> 2. Try the iAtKOS L2 install.
> 3. Try a retail install using the MultiBeast no DSDT option.
> As for not being able to compile the DSDT, you might give DSDTSE a try if
> you haven't already. Link to it can be found here:
I also have a 1.32 BIOS and a board which is compatible with it, and my
Rev. F DSDT works perfectly on it.
I always use DSDTSE, and the DSDT which I provided was, indeed,
successfully compiled using DSDTSE, without ANY errors whatsoever. No
warnings, either.
If you make your own mods to my Rev. F DSDTs for the DC7800 or the DC7900,
then PLEASE DO NOT CALL IT Rev. F, because it certainly is not longer my
Rev. F DSDT.
>>> How can I compile the .dsl file? I'm not using the correct version of
>>> iasl, I guess.
>> There must be several revisions for this board as I never had any problems
>> with mine, other than the initial problem with the Lion installer not
>> being able to see my internal hard drives. Here are some things to try:
>> 1. Try booting up without using a DSDT at all.
>> 2. Try the iAtKOS L2 install.
>> 3. Try a retail install using the MultiBeast no DSDT option.
>> As for not being able to compile the DSDT, you might give DSDTSE a try if
>> you haven't already. Link to it can be found here:
>> http://www.osx86.es/old/?cat=21 > I also have a 1.32 BIOS and a board which is compatible with it, and my
> Rev. F DSDT works perfectly on it.
> I always use DSDTSE, and the DSDT which I provided was, indeed,
> successfully compiled using DSDTSE, without ANY errors whatsoever. No
> warnings, either.
> If you make your own mods to my Rev. F DSDTs for the DC7800 or the DC7900,
> then PLEASE DO NOT CALL IT Rev. F, because it certainly is not longer my
> Rev. F DSDT.
How about a modifier using something like "Rev F, mod macsonly 1" or "Rev F, macsonly 1". That way it can be traced to the modifier of your DSDTs.
> How about a modifier using something like "Rev F, mod macsonly 1" or
> "Rev F, macsonly 1". That way it can be traced to the modifier of your
> DSDTs.
Reasonable.
You should be prepared to act as developer and also to provide support for
your modified versions.
>> How about a modifier using something like "Rev F, mod macsonly 1" or
>> "Rev F, macsonly 1". That way it can be traced to the modifier of your
>> DSDTs.
> Reasonable.
> You should be prepared to act as developer and also to provide support for
> your modified versions.
Incidentally, on my very own DC7900 CMT (Q45/ICH10-D0 chip sets), the IRQs
assigned to the HPET function, based upon IORegistryExplorer, were:
0bx (11, decimal), and
17x (23, decimal)
But, my DSDT specified 0 and 8.
I agree that that the HPET device is probably "stealing" IRQs, and IT DOES
appear to require FOUR IRQs and not TWO IRQs.
Whatever the reality, all three of my machines seem to be perfectly happy
with 0 and 8.
(They could, theoretically, also operate with NO IRQs being specified,
PROVIDED I was prepared to include the NullCPUPowerManager function.)
On another note, I just had my blood drawn for a comprehensive metabolic
panel, and the machine which directed the technician throughout the
process was an hp/Compaq 6000 SFF.
A quick reading of the 6000's specs states that it is a Q43 machine, not a
Q45 machine, and it has an E8400 proc, as does my DC7900 CMT.
I have been noticing quite a few businesses which have been using
hp/Compaqs, and nearly every one of these require re-booting periodically.
On Monday, January 7, 2013 3:39:10 PM UTC-5, PH wrote:
> ... > On another note, I just had my blood drawn for a comprehensive metabolic > panel, and the machine which directed the technician throughout the > process was an hp/Compaq 6000 SFF.
> A quick reading of the 6000's specs states that it is a Q43 machine, not a > Q45 machine, and it has an E8400 proc, as does my DC7900 CMT.
@PH About releasing a new DSDT based on your Rev F, didn't think about it. My DSDT file name was for testing purposes only. If you are ok with it, I'd like to ask for a proper name before releasing a new DSDT based on your Rev F. Hackintosh newbie here ;)
The dc7800 that was giving me trouble had some hardware problems, so I got a new one, same model.
Upgraded bios and installed iATKOS L2, following method 1 as described:
Now, USB ports seem to be working ok, but I detected a new error. If I connect a USB pendrive and (without disconnecting it) I shut down this new machine (Apple menu->Shut down), it reboots itself a couple of seconds after powering off.
Do you know what could be causing this problem?
TIA
El lunes, 7 de enero de 2013 21:39:10 UTC+1, PH escribió:
> >> How about a modifier using something like "Rev F, mod macsonly 1" or > >> "Rev F, macsonly 1". That way it can be traced to the modifier of your > >> DSDTs.
> > Reasonable.
> > You should be prepared to act as developer and also to provide support > for > > your modified versions.
> Incidentally, on my very own DC7900 CMT (Q45/ICH10-D0 chip sets), the IRQs > assigned to the HPET function, based upon IORegistryExplorer, were:
> 0bx (11, decimal), and
> 17x (23, decimal)
> But, my DSDT specified 0 and 8.
> I agree that that the HPET device is probably "stealing" IRQs, and IT DOES > appear to require FOUR IRQs and not TWO IRQs.
> Whatever the reality, all three of my machines seem to be perfectly happy > with 0 and 8.
> (They could, theoretically, also operate with NO IRQs being specified, > PROVIDED I was prepared to include the NullCPUPowerManager function.)
> On another note, I just had my blood drawn for a comprehensive metabolic > panel, and the machine which directed the technician throughout the > process was an hp/Compaq 6000 SFF.
> A quick reading of the 6000's specs states that it is a Q43 machine, not a > Q45 machine, and it has an E8400 proc, as does my DC7900 CMT.
> I have been noticing quite a few businesses which have been using > hp/Compaqs, and nearly every one of these require re-booting periodically.
> Now, USB ports seem to be working ok, but I detected a new error. If I
> connect a USB pendrive and (without disconnecting it) I shut down this new
> machine (Apple menu->Shut down), it reboots itself a couple of seconds
> after powering off.
> Do you know what could be causing this problem?
These are the kinds of problems which bedevil Hackintoshes.
They cannot be made absolutely, positively 100 percent like Macintoshes.
Perhaps 99.44 percent, however.
The lessons learned on the DC7900 CMT (my present main Hackintosh) were
translated back to the DC7800 CMT/SFF (these use the same BIOS).
I started with the DC7800 SFF and got that up to, I believe, DSDT Rev. C,
and then started on a DC7800 CMT into which I had installed a DC7900 CMT
mobo, but before I could attack that machine, the special deal on the
brand new DC7900 CMT came around, so I started work on that DSDT, and
eventually brought it up to Rev. F. Simultaneously with the release of
DC7900 Rev. F, the release of DC7800 Rev. F was done, incorporating the
lessens learned on the DC7900.
I have never had my DC7900 CMT restart after a shut-down.
Many thanks for your DSDT and thorough guide. Has been a great help for getting my DC7900 sff up and running. And helping me gradually understand some more detail of DSDT file and its structure.
I'm having one issue that I cannot get the onboard audio to work (AD1884a), I note in a previous post you commented you got working only on VoodooHDA 0.2.1 but I cannot get anything from the ports. the system sees the output devices (front black and rear green) But all I get is the odd speaker pop when playing sounds. I've also tried every Voodoo version following that (including the recent 2.8) but still nothing
Could you post the VoodooHDA kext file you're using?
On Tuesday, January 8, 2013 5:03:45 PM UTC-5, Carlos A. wrote:
> First things first, thank you all for your help.
> @PH About releasing a new DSDT based on your Rev F, didn't think about it. > My DSDT file name was for testing purposes only. If you are ok with it, I'd > like to ask for a proper name before releasing a new DSDT based on your Rev > F. Hackintosh newbie here ;)
> The dc7800 that was giving me trouble had some hardware problems, so I got > a new one, same model.
> Upgraded bios and installed iATKOS L2, following method 1 as described:
> Now, USB ports seem to be working ok, but I detected a new error. If I > connect a USB pendrive and (without disconnecting it) I shut down this new > machine (Apple menu->Shut down), it reboots itself a couple of seconds > after powering off.
> Do you know what could be causing this problem?
> TIA
> El lunes, 7 de enero de 2013 21:39:10 UTC+1, PH escribió:
>> >> How about a modifier using something like "Rev F, mod macsonly 1" or >> >> "Rev F, macsonly 1". That way it can be traced to the modifier of your >> >> DSDTs.
>> > Reasonable.
>> > You should be prepared to act as developer and also to provide support >> for >> > your modified versions.
>> Incidentally, on my very own DC7900 CMT (Q45/ICH10-D0 chip sets), the >> IRQs >> assigned to the HPET function, based upon IORegistryExplorer, were:
>> 0bx (11, decimal), and
>> 17x (23, decimal)
>> But, my DSDT specified 0 and 8.
>> I agree that that the HPET device is probably "stealing" IRQs, and IT >> DOES >> appear to require FOUR IRQs and not TWO IRQs.
>> Whatever the reality, all three of my machines seem to be perfectly happy >> with 0 and 8.
>> (They could, theoretically, also operate with NO IRQs being specified, >> PROVIDED I was prepared to include the NullCPUPowerManager function.)
>> On another note, I just had my blood drawn for a comprehensive metabolic >> panel, and the machine which directed the technician throughout the >> process was an hp/Compaq 6000 SFF.
>> A quick reading of the 6000's specs states that it is a Q43 machine, not >> a >> Q45 machine, and it has an E8400 proc, as does my DC7900 CMT.
>> I have been noticing quite a few businesses which have been using >> hp/Compaqs, and nearly every one of these require re-booting >> periodically.
> carlos--does the automatic restart happen every time you shut the machine down, or just every now and then?
If it's like mine, it started out almost every time, but then all at once it started shutting down as it should. I haven't had any problems with it since.
It's also worth noting that in addition to the system BIOS update, it may be wise to check the Intel Management Engine Firmware version to see if it is different. This info can be read from the first BIOS screen shot I posted the other day here. This firmware can only be updated via DOS or Windows, so I doubt anyone here has done so.
I don't really know how important it is for OS X, but I read where it does impact running Windows 7 on this system. I think it's always wise to run the latest firmware and BIOS on any system, as long as no problems have been reported from doing so. HTH
From the main system of mosslack...
______________________________
Alt-OS <+> GG <+> TBIE <+> Hack List
> I'm having one issue that I cannot get the onboard audio to work
> (AD1884a),
> I note in a previous post you commented you got working only on VoodooHDA
> 0.2.1
> but I cannot get anything from the ports. the system sees the output
> devices (front black and rear green)
> But all I get is the odd speaker pop when playing sounds.
> I've also tried every Voodoo version following that (including the recent
> 2.8) but still nothing
> Could you post the VoodooHDA kext file you're using?
2.7.3
There is a 2.7.4, but it apparently drops support for the AD1184A.
It starts out every time. The person who gave it to me told me that he did the same installation I did to several DC7800, all with the same reboot problem. They bought all of them at the same time, so maybe it's a model issue.
> carlos--does the automatic restart happen every time you shut the machine > down, or just every now and then?
> If it's like mine, it started out almost every time, but then all at once > it started shutting down as it should. I haven't had any problems with it > since.
> It's also worth noting that in addition to the system BIOS update, it may > be wise to check the Intel Management Engine Firmware version to see if it > is different. This info can be read from the first BIOS screen shot I > posted the other day here<https://docs.google.com/document/d/1y4B10-d8ndc7z0PyOI_zVvLb_gk3S2ogK...>. > This firmware can only be updated via DOS or Windows, so I doubt anyone > here has done so.
