Jump to content

Have you noticed the AutoRestartAfterKernelPanic function lost ?


p.H
 Share

47 posts in this topic

Recommended Posts

iirc the restart after power failure is added using slice version, sry I didn't make what I was saying very clear b4. But as you said, neither will enable the restart after freeze option :( You could always try using a smbios for an xserve :)

but i am using a notebook

i don't think the smbios file for mbp would be running server :(

Link to comment
Share on other sites

So, I decided why not, and tried on my backup install: post-734613-0-55437600-1346927655_thumb.jpg Sys prefs is the same, no change

It's my first time to see such a picture.

Is it the original one or you modified somethign ?

 

Finally I got the answer...thanks mate... :D

u mean answer for what problem ?

Link to comment
Share on other sites

It's my first time to see such a picture.

Is it the original one or you modified somethign ?

 

 

u mean answer for what problem ?

 

He answered why on Lion I got 5 options on Energy saver preferences whereas in Mountain Lion I only got 3 options....so his posted screenshots and explanation had answered the question that has been in my mind for a while (yeah I never bother to ask around and just accept it).

Link to comment
Share on other sites

He answered why on Lion I got 5 options on Energy saver preferences whereas in Mountain Lion I only got 3 options....so his posted screenshots and explanation had answered the question that has been in my mind for a while (yeah I never bother to ask around and just accept it).

That's nice

When I tried ML DP4, the first thing impressed me is this

So I try to figure it out asap. :)

Link to comment
Share on other sites

It's my first time to see such a picture.

Is it the original one or you modified somethign ?

Modified smbios for Xserve only, no modifications to the picture or any of the coreservices at all. This was on a 2nd install I keep that is just a fresh install with nothing but initial setup done. I used it to first make my RAID-0, and keep it incase I need to fix something, I have working ML to use.

Link to comment
Share on other sites

Modified smbios for Xserve only, no modifications to the picture or any of the coreservices at all. This was on a 2nd install I keep that is just a fresh install with nothing but initial setup done. I used it to first make my RAID-0, and keep it incase I need to fix something, I have working ML to use.

Xserver is the original machine for OS X server ?

Link to comment
Share on other sites

Hi guys, just wanted to write that there is a flag in boot args structure that is sent to kernel which can influence this KP restart. Went to copy/paste those boot args definitions from cparm's branch, and noticed that cparm already added that to his branch: http://forge.voodooprojects.org/p/chameleon/source/commit/2052/'>http://forge.voodooprojects.org/p/chameleon/source/commit/2052/

Flag: RebootOnPanic

:)

hey dude, sorry for replying your message this late.

Have u tested it ?

 

Hi guys, just wanted to write that there is a flag in boot args structure that is sent to kernel which can influence this KP restart. Went to copy/paste those boot args definitions from cparm's branch, and noticed that cparm already added that to his branch: http://forge.voodooprojects.org/p/chameleon/source/commit/2052/

Flag: RebootOnPanic

:)

 

Plus, I got the chameleon file using this command in the terminal

http://forge.voodooprojects.org/svn/chameleon/trunk/

is that capable of the so-called cparm's function ?

Link to comment
Share on other sites

I did not test it. I'm not familiar with cparm's branch.

 

I have used this boot args flag during some UEFI boot tests. boot.efi (Apple's EFI boot loader) sets this flag to 1 and this causes restarts when KP happens in those tests. If I set it to 0 (as Chameleon is doing by default), then KP stays on screen. But those KPs happens to me only during testing and during boot. I do not know how to make a KP when my hack is running.

 

Anyway, you can always ask cparm or ErmaC to port this flag to Chameleon's trunk. It looks to me that it will do exactly what you wanted.

Link to comment
Share on other sites

I did not test it. I'm not familiar with cparm's branch. I have used this boot args flag during some UEFI boot tests. boot.efi (Apple's EFI boot loader) sets this flag to 1 and this causes restarts when KP happens in those tests. If I set it to 0 (as Chameleon is doing by default), then KP stays on screen. But those KPs happens to me only during testing and during boot. I do not know how to make a KP when my hack is running. Anyway, you can always ask cparm or ErmaC to port this flag to Chameleon's trunk. It looks to me that it will do exactly what you wanted.

So you mean that my way of getting chameleon using http://forge.voodoop...hameleon/trunk/ won't get cparm's version ?

Do you have some ideas about how can I get cparm's version directly ?

 

:D it's always much more easier to meet kp than not.

Just put AppleHDA and VoodooHDA together in SLE.

Link to comment
Share on other sites

I think this should build it:
 svn co http://forge.voodooprojects.org/svn/chameleon/branches/cparm cd cparm make 

:D

it works.

Still confused with the revision number. Since trunk version is 2054 now, while cparm's is 2052

Does it mean that trunk (2054>2052) already contains the cparm's version ?

  • Like 1
Link to comment
Share on other sites

No. Trunk is one set of sources and cparm's branch is another. But they are in the same repository and they "share" revision counter (change in a trunk or branch increments counter).

That's sad though 0-0

Dunno when will this function be merged into trunk.

Link to comment
Share on other sites

You can always ask ErmaC or cparm to add it to trunk. It's up to them then to decide if they can/will do it or not.

 

In the meantime, you can try setting this flag in trunk code:

in i386/libsaio/bootstruct.c

change:

bootArgs->deviceTreeP = (uint32_t)addr;
bootArgs->deviceTreeLength = size;

// Copy BootArgs values to older structure

to:

bootArgs->deviceTreeP = (uint32_t)addr;
bootArgs->deviceTreeLength = size;

// set flag RebootOnPanic
bootArgs->__reserved1[0] = 1;

// Copy BootArgs values to older structure

Compile it and try if it works as expected. I did not test it.

Link to comment
Share on other sites

You can always ask ErmaC or cparm to add it to trunk. It's up to them then to decide if they can/will do it or not. In the meantime, you can try setting this flag in trunk code: in i386/libsaio/bootstruct.c change:
 bootArgs->deviceTreeP = (uint32_t)addr; bootArgs->deviceTreeLength = size; // Copy BootArgs values to older structure 

to:

 bootArgs->deviceTreeP = (uint32_t)addr; bootArgs->deviceTreeLength = size; // set flag RebootOnPanic bootArgs->__reserved1[0] = 1; // Copy BootArgs values to older structure 

Compile it and try if it works as expected. I did not test it.

:D

it seems to be the code cparm added to its branch

I will contact ErmaC to see if it's possible to add it to trunk

Link to comment
Share on other sites

You can always ask ErmaC or cparm to add it to trunk. It's up to them then to decide if they can/will do it or not. In the meantime, you can try setting this flag in trunk code: in i386/libsaio/bootstruct.c change:
 bootArgs->deviceTreeP = (uint32_t)addr; bootArgs->deviceTreeLength = size; // Copy BootArgs values to older structure 

to:

 bootArgs->deviceTreeP = (uint32_t)addr; bootArgs->deviceTreeLength = size; // set flag RebootOnPanic bootArgs->__reserved1[0] = 1; // Copy BootArgs values to older structure 

Compile it and try if it works as expected. I did not test it.

ErmaC has already added this feature to his branch

I tested it and it works.

So I just hope this feature will be added asap

cheers.

Link to comment
Share on other sites

 Share

×
×
  • Create New...