dmazar

Pike R. Alpha, on 05 May 2013 - 04:29 AM, said:

Although Pike is gone, I'll still finish this one, since I already spent some time digging about it.

Yes, indeed. Sam wrote about how to resolve the P-State Stepper Error. I used her findings to fix P states in my DSDT. And I can only thank her for this.

As far as Chameleon's and Clover's P states code generator is concerned, if I got it right, this was never the issue, since those generators were always generating continues P states. Sam's findings were needed only for guys (like me) who had their own P states in their DSDT/SSDTs. No code changes in Clover were needed nor done.

I'm relatively new in hackintosh community and I really do not know who made what and when for many things I take for granted. For example: who made P and C states generators, who changed them, who made graphics injector, who discovered which properties we need to inject for which cards (ATI, NVIDIA, Intel, one person or many persons), USB injections, who find out what we need to inject for SMBIOS, which patches are needed for DSDT (every single one of them), kernel patching (pcj introduced it to Clover, but did he take it from meklort, or somebody else?) ... . Mentioned things are not even detailed enough and I am also far from listing all of it. And all those stuff are used in Clover, Chameleon and any other current and future booters.

I can easily say that this is all now common hackintosh knowledge and resolve the possible credits issues by just saying "Thanks to all hackintosh community". And then, behind every single discovery or feature there are real people who deserves to be mentioned and credited. And how to do that?

It looks impossible to me that some new developer would be able to investigate and list every single person who contributed to hackintosh stuff. Specially when you deal with boot loader which uses many different findings. Also it's not fair to credit only those who are loud enough to ask for their credits and leave out those who silently contribute with new things and are not asking around for recognition.

I have no idea how to resolve this. But I think guys who are moderating hack scene (forums) should try to move those things from developer as much as possible. If possible. I do not know ... maybe you could make some kind of registry and list all contributions with the list of people? And then anybody who is using that "common knowledge" can just reference to that list? Something like that would remove digging into hack history and fighting around who deserves credits for what of of our back.

First of all, I am speaking for myself and not for other Clover developers.

Pike, Google for "DHP Chameleon" reveals this as second link to me: http://forge.voodoop...ce/commit/2037/ . Were you thinking of this? There are around 50 files changed, mostly code reformatting. What should I do with this? How can I found out here what is taken from RevoBoot and how is this connected to Clover? How would I ever be able to write any line of code for Clover if I would have to go through every single commit of every project connected to hackintosh to discover which line is written by which developer? How would any new developer be able to do anything in the future if every person who ever contributed his/her findings or code to Chameleon start chasing that new developer for not mentioning his/her name because new developer took some code from Chameleon? Specially, when he/her talks in abstract and does not specify particular piece of the code?

Plus, most of those files listed in that commit are not even present in Clover.

Please, do not be lazy and point me to the code in Clover that is taken from RevoBoot. I see no point in abstract talking.

chosen/boot-uuid - this is not relevant for Clover since Clover is using Apple's boot.efi to boot OSX. You may try to sue Apple for using "chosen/boot-uuid" without mentioning RevoBoot.

iMessage - I'm sorry but I have no idea how Sam contributed to resolving that issue. Please be so kind and explain it. As far as I know, resolving iMessage issue was an example of collective community work where many people were involved in resolving the issue and where crucial part in understanding what is going on is found out by ElNono_ from ##### site.

@verdant: I have nothing against "many valuable contributions (both large and small) made by his sister Sam to the OSx86 hackintosh community, are open and fairly acknowledged". But I do not see any significant contribution to Clover speciffically.

@theconnactic: My personal issue is that I devoted significant time to Clover development and I found offending that Pike comes and claims ownership on something while I do not see how is this connected to Clover at all. Until I am presented with some more concrete examples and arguments, I am taking those requests simply as bullying. Again - it's my personal opinion.

Alessandro17, on 04 May 2013 - 07:44 AM, said:

As far as I know, there is no single line of code copied from RevoBoot into Clover.

But there are many lines of code in Clover that are copied from Chameleon. Many people were involved in Chameleon development and many more contributed to it. Maybe something in Chameleon was copied from RevoBoot - but I do not know that.

And now the question: how to track which specific line of Chameleon code is written by who in order to mention every single person in Clover's credit? That is impossible.

The solution to this is, as I see it, simple: Clover took some code from Chameleon and Clover should mention that and give credits to Chameleon team. If Chameleon took some code from RevoBoot, then Chameleon should give credits for this. If RevoBoot take that code from some other place, then RevoBoot should give credit for that, and so on ...

Who will know if Chameleon took some code from RevoBoot (if!!!)? Well, Chameleon team obviously. How could I know if that happened or not? So, if the answer is Yes, then this should be mentioned in Chameleon's credits. Why would we (Clover team) now need to investigate RevoBoot's contribution to Chameleon (if there is any)?

I already had one request from Pike to mention Sam in the code for Clover's AppleIntelCPUPowerManagemen kext patch (for locked MSR 0xE2), and now I am very close to regret that I did that. I took all needed info for this patch from flaked's speedstepper and put the link to it to the source (this one). Now I think this should be enough. If flAked used Sam's work for his speedstepper, then he should be chased for mentioning that in his thread, and that should be it.

By the way, where is this going? Apple vs Samsung, Oracle vs Google ... do we need layers now?

Do what you think is the best for the majority of users. As I said, I have no problem modifying it for my use. And ... thanks for your work again.

Ok, tested again with setLinkStatus() in start and enable() - it does not work.

From my various test so far I can conclude that as soon as setLinkStatus() is called in start, this results in some error which manifests in interrupts not being delivered. If setLinkStatus() is called in enable(), then all is working fine. Why this happens on my ProBook and not on desktop, and not on RehabMan's ProBook, I do not know. Maybe my ProBook is too slow and net stack is not configured properly yet during start()? I even tried to call setLinkStatus() in start() through commandGate, but this did not helped either.
Is there any sense in calling setLinkStatus() while the whole net stack is not connected and configured properly? Is enable() the only place where it is safe to assume that net interface is configured and attached properly to the rest of the net layer?

Few more observations:
I've took a quick look at Apple's sample AppleUSBCDCEEM driver - this one has setLinkStatus() in enable() and not in start(). Although, I know that this does not have to mean anything.

Quick look at IONetworkingFamily sources: setLinkStatus() uses some locking: MEDIUM_LOCK -> IOTakeLock -> IOLockLock:  Lock the mutex. If the lock is held by any thread, block waiting for its unlock. This function may block and so should not be called from interrupt level or while a spin lock is held. Locking the mutex recursively from one thread will result in deadlock.
Meaning: calling setLinkStatus() from interrupt routine should be done with caution, probably avoided (by calling through commandGate?).

All in all - I found the code that works for me:
- v 1.0.4
- commented out setLinkStatus() from start()
- changed checkLinkStatus():

} else {
	 if (interrupt) {
		 /* Stop watchdog and statistics updates. */
		 timerSource->cancelTimeout();
		 setLinkDown();
		
		 if (tp->mcfg == CFG_METHOD_23) {
			 WriteReg32(ERIDR, 0x00000001);
			 WriteReg32(ERIAR, 0x8042f108);
		 }
	 } else {
		 /* Called from enable() - just notify that the link is down. */
		 setLinkStatus(kIONetworkLinkValid);
	 }
}

Since you made the code available, it's not a problem for me to modify it as above for my personal use and compile it here.

EDIT: just to mention it once again: I do not need checkLinkStatus() to be called in enable() at all. All I need there is setLinkStatus(kIONetworkLinkValid) - and all works fine.