00diabolic Posted April 17, 2008 Share Posted April 17, 2008 (edited) I am getting sick and tired of seeing incomplete lists of kernel flags. :censored2: I always find a new one's and then I wonder what other ones are out there. So here is a list of all the ones I have come across because I cant find an extensive list like this anywhere else. I also would like to see others help add to this list. Mods do you think this can be a sticky? The Flags are divided up this way. By category they fit in. Those are boot loader & kernel level flags. A. By version of OS X they work with. Currently I have little data for this breakdown. It is impossible to tell which ones are specific to a OS version without extensive testing of each flag. B. By kernel they work with. Only data I have for this breakdown is for hacked and vanilla kernels in Leopard currently. Note: All unknown flags will go in separate list at the bottom of the category they belong to or in there own separate category for now. Once more information is gathered the list will be updated and flag categorized better. I am asking anyone to help with notes or details for any flag to please step forward with any additional information you have. Darwin boot loader level flags, for Darwin version 8.0: -v = verbose mode. Basically tells you wants happening during boot up. -x = Safe mode. Basically boots your system with the bare minimum kexts. -s = Single user mode. Command line only mode. Allows you to run commands as root to fix system. -f = Tells the machine to reload all kext and dump the boot configuration cache, (kext cache found in: /System/Library/Extensions.mkext, you can delete it manually and the system will recreate it). "Graphics Mode"= Tells the system what resolution width, height, color depth & refresh rate to boot the OS with. Ex: "Graphics Mode"="1024x768x32" WIDTHxHEIGHTxDEPTH For VESA 3.0 graphics, you may append a refresh rate after an "@" character Ex: "Graphics Mode"="640x480x32@60" WIDTHxHEIGHTxDEPTH@REFRESHRATE rd= This parameter state what is the boot disk to use (instead of using the boot menu appearing before the prompt) you state the drive and partition in here: diskXsY where X stands for the disk number (first disk, usually primary master in IDE or SATA) 0 second disk is 1 etc.) and Y stands for the partition on that disk starting with 1 as the first partition. Ex: rd=disk0s1 If you have one disk and one partition the parameter will look like this. You can also use rd=*<IODeviceTree path> for booting from a PCI RAID card for example. Ex: of this would be rd=*/PCI0@0/CHN0@0/@0:1 Platform= this parameter sets the platform to use at this boot time. Examples of this flag are: platform=ACPI (ACPI support) platform=X86PC (non ACPI support) platform=ACPI|86PC (try to support ACPI if fails do not support it) ?memory = this info screen display information about the memory on the machine ?video = this info screen display information about the video card supported graphic modes ACPI Flags acpi=off = Don't enable ACPI acpi=ht = Use ACPI boot table parsing, but don't enable ACPI interpreter acpi=force = Force ACPI on (currently not needed) acpi=strict = Disable out of spec ACPI workarounds. acpi_sci={edge,level,high,low} Set up ACPI SCI interrupt. EX: acpi_sci=edge acpi=noirq = Don't route interrupts Darwin flags most commonly added to com.apple.Boot.plist file: Note: Any flag can be added to your boot.plist but these are just the common ones. "Boot Graphics"=Yes = Yes or No. Use graphics mode or text mode when starting. Turns off vesa mode graphics at boot. "Quiet Boot"=Yes = Yes or No. Use quiet boot mode (no messages or prompt). Same as adding -v option. Timeout=3 = Any number 1-100. Number of seconds to pause at the boot prompt. debug=0x144 When added as a boot flag to your com.apple.Boot.plist will give you details about a kernel panic you have at any time when running OSX. I believe it is the same as debug=0x100, not sure. Unknown Darwin Boot Loader Flags Text Mode = Might be the same as -v not sure. Kernel Flags = ? MKext Cache = Might be to specify the mkext cache to use. Not sure. Kernel = To specify kernel to use. Correct? Kernel Cache = Possibly to specify where the kernel should cache? Boot Device = Might be the same as rd= above. Not sure. boot-uuid = Believed to be the same as for example rd=disk1s1. Not sure exactly how this is formatted and if it has any other special characteristics. Might be useful to some where the rd flag gives you trouble. CD-ROM Prompt = ? CD-ROM Option Key = ? -F = Not sure could be the same as lower case -f flag. Kernel level flags: -l = The flag attempts to enable the L2 cache if not already enabled. Not sure if this works on hacks. If your having an L2 cache issue try this flag. cpus= Tells the kernel how many cores there are in place. Ex: cpus=1 OR cpus=2 idlehalt= Lets you set two values ether 1 or 0 stating true or false, if set to true then at idle time the cpu will halt causing power saving and cooling of CPU, if set to 0 then the cpu will allways run even in idle time. idlehalt=0 idlehalt=1 cpuidle= Lets you set two values ether 1 or 0 stating true or false. This flag is exactly the same as the one above I believe. Please correct me if I'm wrong. cpuidle=0 cpuidle=1 -legacy = causes the system to load in 32 bit mode while running on 64 bit version of OS X debug=0x100 = To show information about kernel panics & other useful info from system at startup. If you are getting a auto rebooting from bad kernel or kext being loaded use this flag to see what it is. Will help when posting information on this forum for diagnoses. maxmem=xxxx = This allows you to specify maximum memory used by the system. Not sure if the rest of the memory is used for apps or not. Many people have to use this if they have 4GB of memory in a 32bit OS. Ex: maxmem=2048 Unknown kernel level flags dtrace_dof_mode = ? DisableFBT = ? IgnoreFBTBlacklist = ? -s = May sever the same purpose as -s at darwin. Otherwise how would you enter this. May not be a correct flag. -b = ? -x = May sever the same purpose as -x at darwin. Otherwise how would you enter this. May not be a correct flag. srv = ? ncl = ? nbuf = ? kmem = ? trace = ? msgbuf = ? rp = ? mcache_flags = ? mbuf_debug = ? initmcl = ? socket_debug = ? net_affinity = ? rte_debug = ? -rwroot_hack = ? keepsyms = ? mseg = ? dart = ? io = ? nvram_paniclog = ? pmsafe_debug = ? preempt = ? unsafe = = ? poll = ? yield = ? panic_io_port = ? _fpu = ? diag = ? serial = ? himemory_mode = ? immediate_NMI = ? lcks = ? novmx = ? max_valid_dma_addr = ? maxbouncepool = ? maxloreserve = ? mtxspin = ? npvhash = ? wpkernel = ? -no_shared_cr3 = ? -pmap_trace = ? _panicd_ip = ? _router_ip = ? panicd_port = ? -zc = ? vmmforce = ? zsize = ? colors = ? fill = ? serialbaud = ? net_affinity = ? rte_debug = ? fn=x This flag can increase performance and forces OSX to use the users input for CPU/Fan/Idle control. "fn" stands for "forcenap" and provides different implementions for handling CPU idle time with the goal of CPU heat/fan control. There are five values: fn=0 : Sets this to off I believe fn=1 : Not sure what this one does? fn=2 : Uses CPU instructions "monitor/mwait" (will crash on SSE2 CPUs) fn=3 : Original implemention of the previous Mac OS X x86 builds. This option sets your energy level to high and causes the fans to run full. This is helpful to keep your processor running fast, but chews up your battery life. Some users find this option gives the fastest system performance on desktops. fn=4 : Uses CPU instructions "monitor/mwait" (will crash on SSE2 CPUs) Kernel level flags used for hacked kernels ONLY kernel name "mach_kernel" This flag simply tells the system to boot from another kernel available in / (aka root). fsb=<mhz> = Most of the hacked kernels include the possibility at boot to chosen FSB frequency. These flags DO NOT work with any known vanilla kernel. Do testing with the below values to see what works for you. The default value is 200Mhz. If you want different value, you have a few possibilities. Ex: kernel name "netkasSS_kernel" Ex: fsb=800 or use one of these flags below: -g = For frequency's multiplied by 100 Mhz -y = For frequency's multiplied by 133 Mhz -z = For frequency's multiplied by 166 Mhz * You can easily add either the -y, -g, or -z options to your boot.plist file or use the fsb=<mhz> flag to give it an exact figure. I have not tested the fsb=<mhz> flag but the -y gave me the correct 800fsb (100mhz x 8) and boosted my performance to where it should be in OSX. This may not change the FSB in about this mac on a hack, it did not for me. You would need to test with a benchmark app to see the gain. Hopefully hardcoded front side bus speeds can be added to SMBIOS files at some point in the future by netkas or Mac.Nub. -vmware = Force vmware support, with hacked kernels. Needs testing. -force64 = Force 64bit mode for AMD 64 bit cpu's. Needs testing. cpu=x = Number of physical cpu's installed NOT CORES. Also needs testing Unix Flags that might work in OSX. See subcategories for details This list is mostly AMD specific boot options & for 64bit CPU's. Might also help with Intel CPU's. This list needs extensive testing & feedback but most of these flags do work in OSX. Once more info is gathered They will be categorized into the lists above Machine check Options Flags mce=off = Disable machine check. For compatibility with i386. Might help boot some AMD systems. nomce does the same same as mce=off mce=bootlog = Enable logging of machine checks left over from booting. Disabled by default on AMD because some BIOS leave bogus logs. If your BIOS does not do that it's a good idea to enable this log to make sure you log every machine check event that result in a reboot. On Intel systems it is enabled by default. mce=nobootlog = Disable boot machine check logging. mce=tolerancelevel (number from list below) 0: always panic on uncorrected errors, log corrected errors 1: panic or SIGBUS on uncorrected errors, log corrected errors. Default is 1 2: SIGBUS or log uncorrected errors, log corrected errors 3: never panic or SIGBUS, log all errors (for testing only) APIC Flags apic = Use IO-APIC. Default noapic = Don't use the IO-APIC. disableapic = Don't use the local APIC nolapic = Don't use the local APIC (alias for i386 compatibility) noapictimer = Don't set up the APIC timer no_timer_check = Don't check the IO-APIC timer. This can work around problems with incorrect timer initialization on some boards. apicmaintimer = Run time keeping from the local APIC timer instead of using the PIT/HPET interrupt for this. This is useful when the PIT/HPET interrupts are unreliable. noapicmaintimer = Don't do time keeping using the APIC timer. Useful when this option was auto selected, but doesn't work. apicpmtimer=1 Either set to 0 or 1. Same as apicmaintimer=1/0. Do APIC timer calibration using the pmtimer. Implies apicmaintimer. Useful when your PIT timer is totally broken. Sometimes there are timer routing problems on some Nvidia and ATI chipsets. Assuming you're using 64bit then you can try apicmaintimer or apicpmtimer. On 32bit you can try pci=noacpi noapic. Needs testing. disable_8254_timer / enable_8254_timer = Enable interrupt 0 timer routing over the 8254 in addition to over the IO-APIC. The kernel tries to set a sensible default. PCI Flags pci=off = Don't use PCI pci=conf1 = Use conf1 access. pci=conf2 = Use conf2 access. pci=rom = Assign ROMs. pci=assign-busses = Assign busses pci=noacpi = Don't use ACPI to set up PCI interrupt routing. IOMMU is Input/output memory management unit Flags Currently four x86-64 PCI-DMA mapping implementations exist: iommu=[1,2,3,4][<size>][,noagp][,off][,force][,noforce][,leak[=<nr_of_leak_pages>] [,memaper[=<order>]][,merge][,forcesac][,fullflush][,nomerge] [,noaperture][,calgary] 1-4 consist of the following combined options: 1. <arch/x86_64/kernel/pci-nommu.c>: use no hardware/software IOMMU at all (e.g. because you have < 3 GB memory). Kernel boot message: "PCI-DMA: Disabling IOMMU" 2. <arch/x86_64/kernel/pci-gart.c>: AMD GART based hardware IOMMU. Kernel boot message: "PCI-DMA: using GART IOMMU" 3. <arch/x86_64/kernel/pci-swiotlb.c> : Software IOMMU implementation. Used e.g. if there is no hardware IOMMU in the system and it is need because you have >3GB memory or told the kernel to us it (iommu=soft)) Kernel boot message: "PCI-DMA: Using software bounce buffering for IO (SWIOTLB)" 4. <arch/x86_64/pci-calgary.c> : IBM Calgary hardware IOMMU. Used in IBM pSeries and xSeries servers. This hardware IOMMU supports DMA address mapping with memory protection, etc. Kernel boot message: "PCI-DMA: Using Calgary IOMMU" General iommu options: off = Don't initialize and use any kind of IOMMU. noforce = Don't force hardware IOMMU usage when it is not needed. (default). force = Force the use of the hardware IOMMU even when it is not actually needed (e.g. because < 3 GB memory). soft = Use software bounce buffering (SWIOTLB) (default for Intel machines). This can be used to prevent the usage of an available hardware IOMMU. iommu options only relevant to the AMD GART hardware IOMMU: <size> Set the size of the remapping area in bytes. allowed Overwrite iommu off workarounds for specific chipsets. fullflush Flush IOMMU on each allocation (default). nofullflush Don't use IOMMU fullflush. leak Turn on simple iommu leak tracing (only when CONFIG_IOMMU_LEAK is on). Default number of leak pages is 20. memaper[=<order>] Allocate an own aperture over RAM with size 32MB<<order. (default: order=1, i.e. 64MB) merge Do scatter-gather (SG) merging. Implies "force" (experimental). nomerge Don't do scatter-gather (SG) merging. noaperture Ask the IOMMU not to touch the aperture for AGP. forcesac Force single-address cycle (SAC) mode for masks <40bits (experimental). noagp Don't initialize the AGP driver and use full aperture. allowdac Allow double-address cycle (DAC) mode, i.e. DMA >4GB. DAC is used with 32-bit PCI to push a 64-bit address in two cycles. When off all DMA over >4GB is forced through an IOMMU or software bounce buffering. nodac Forbid DAC mode, i.e. DMA >4GB. panic Always panic when IOMMU overflows. calgary Use the Calgary IOMMU if it is available Early Console Flags, not sure if this exists in OSX earlyprintk=vga earlyprintk=serial[,ttySn[,baudrate]] EX: earlyprintk=serial,ttyS0,115200 OR earlyprintk=serial,ttyS1,9600 The early console is useful when the kernel crashes before the normal console is initialized. It is not enabled by default because it has some cosmetic problems. Append keep to not disable it when the real console takes over. Only use vga or serial, not both. Currently only ttyS0 and ttyS1 are supported. Interaction with the standard serial driver is not very good. The VGA output is eventually overwritten by the real console. Timing Flags notsc = Don't use the CPU time stamp counter to read the wall time. This can be used to work around timing problems on multiprocessor systems with not properly synchronized CPUs. report_lost_ticks = Report when timer interrupts are lost because some code turned off interrupts for too long. nmi_watchdog="NUMBER" nmi_watchdog=NUMBER[,panic] NUMBER can be: 0 = don't use an NMI watchdog 1 = use the IO-APIC timer for the NMI watchdog 2 = use the local APIC for the NMI watchdog using a performance counter. Note This will use one performance counter and the local APIC's performance vector. When ,panic is specified panic when an NMI watchdog timeout occurs. This is useful when you use a ,panic=... timeout and need the box quickly up again. EX nmi_watchdog=2,panic=20 nohpet = Don't use the HPET timer. Idle loop Flags idle=poll = Don't do power saving in the idle loop using HLT, but poll for rescheduling event. This will make the CPUs eat a lot more power, but may be useful to get slightly better performance in multiprocessor benchmarks. It also makes some profiling using performance counters more accurate. Please note that on systems with MONITOR/MWAIT support (like Intel EM64T CPUs) this option has no performance advantage over the normal idle loop. It may also interact badly with hyperthreading. Rebooting flags, to control how the system reboots reboot= b[ios] | t[riple] | k[bd] [, w[arm] | c[old] bios = Use the CPU reboot vector for warm reset warm = Don't set the cold reboot flag cold = Set the cold reboot flag triple = Force a triple fault (init) kbd = Use the keyboard controller. cold reset (default) Using warm reset will be much faster especially on big memory systems because the BIOS will not go through the memory check. Disadvantage is that not all hardware will be completely reinitialized on reboot so there may be boot problems on some systems. reboot=force Don't stop other CPUs on reboot. This can make reboot more reliable in some cases. Non Executable Mappings flags noexec=on/off on Enable(default) off Disable Debugging Flags oops=panic = Always panic on oopses. Default is to just kill the process, but there is a small probability of deadlocking the machine. This will also cause panics on machine check exceptions. Useful together with panic=30 to trigger a reboot. kstack=N = Print N words from the kernel stack in oops dumps. pagefaulttrace = Dump all page faults. Only useful for extreme debugging and will create a lot of output. call_trace= [old|both|newfallback|new] old: use old inexact backtracer new: use new exact dwarf2 unwinder both: print entries from both newfallback: use new unwinder but fall back to old if it gets stuck (default) Example of some flags from above that can help to get speedstep to work on a nonhpet AMD system with the ToH 9.2.0 SS kernel apicpmtimer=1 notsc=1 nohpet=1 cpus=2 PLEASE feel free to post additional flags you know. I bet there are even more out there that I have not come across. Also you can add all of these to a text file and place it in /usr/standalone/i386/BootHelp.txt. Then when you type ? in darwin all of these flags will be displayed on screen. Cool Uh. Thanks Superhai for that one!! THANKS ALL Edited July 13, 2008 by 00Diabolic ~~ hassling will get you nowhere 4 1 Link to comment Share on other sites More sharing options...
Superhai Posted April 19, 2008 Share Posted April 19, 2008 You could make this into a text file and put it into /usr/standalone/BootHelp.txt so it is available during boot (when using ?) Link to comment Share on other sites More sharing options...
00diabolic Posted April 20, 2008 Author Share Posted April 20, 2008 You could make this into a text file and put it into /usr/standalone/BootHelp.txt so it is available during boot (when using ?) So you can access it in single user mode? Or is there some way to get to txt files from darwin like typing ? might do to see available commands? Link to comment Share on other sites More sharing options...
Superhai Posted April 20, 2008 Share Posted April 20, 2008 Or is there some way to get to txt files from darwin like typing ? might do to see available commands? It is to use when you need it. It is in the same prompt where you would write the kernel flags. 1 Link to comment Share on other sites More sharing options...
iSkylla Posted April 20, 2008 Share Posted April 20, 2008 You forgot the most important one! To get kernel panics to post useful information, boot with kernel debug mode debug=0x100 Link to comment Share on other sites More sharing options...
00diabolic Posted April 21, 2008 Author Share Posted April 21, 2008 You forgot the most important one! To get kernel panics to post useful information, boot with kernel debug mode debug=0x100 THANKS iSkylla.. I added your flag to the list. Now its more complete then ever. MODS STICKY THIS ALREADY :-P Link to comment Share on other sites More sharing options...
iSkylla Posted April 21, 2008 Share Posted April 21, 2008 THANKS iSkylla.. I added your flag to the list. Now its more complete then ever. MODS STICKY THIS ALREADY :-P Nice. That is probably one of the most helpful flags Technically, all it does is remove graphical KP screen. Too bad we don't have NVRAM or we wouldn't need that. Link to comment Share on other sites More sharing options...
BigPimpin Posted April 22, 2008 Share Posted April 22, 2008 The official list of debug flags from Apple. Table 19-1 lists and describes all the values you can use for "debug=". Most are only useful if you're programming something in the kernel or a kext. 0x100 is definitely the most useful one for hackintosh users. Link to comment Share on other sites More sharing options...
00diabolic Posted April 22, 2008 Author Share Posted April 22, 2008 The official list of debug flags from Apple. Table 19-1 lists and describes all the values you can use for "debug=". Most are only useful if you're programming something in the kernel or a kext. 0x100 is definitely the most useful one for hackintosh users. Sweet, this will help a lot to. I made a few more changes to the list also incase anyone missed it. Now has a -l flag & few others. Not sure if it even does anything though on a hackintosh. OK!!!! This is mega sticky worthy!!! THANKS.. The mods told me there trying to find a place for this topic since they have so many sticky's. Should be up somewhere soon though. I hope to get some feedback here on which one of these flags work and don't work on a hack. It appears there are some of them that only work if you have a hacked kernel and I would bet some that only work if you have the vanilla kernel although i bet very few. Link to comment Share on other sites More sharing options...
00diabolic Posted April 23, 2008 Author Share Posted April 23, 2008 Well, the kernel's whether vanilla or hacked are still using Darwin to boot so the flags should work. This should be a sticky in alot of sections IMO. True but some of the flags only affect the kernel and have nothing to do with darwin. They belong together for sure but maybe I should categorize the ones that only work with hacked kernels. Only problem is there is not enough feedback to know which ones do and dont. So far only the FSB ones seem to be hacked kernel only. Link to comment Share on other sites More sharing options...
Superhai Posted April 24, 2008 Share Posted April 24, 2008 "Boot Graphics"=Yes = Yes or No. Use graphics mode or text mode when starting. Same as single user more flag -s. It is not the same as -s. It turns off vesa boot graphics. And I think separating the options for vanilla and modified kernels would be better. Link to comment Share on other sites More sharing options...
inimicus Posted April 24, 2008 Share Posted April 24, 2008 Just to comment: When a noobie looks at the title, what would they see? A bunch of cryptic non-sense. It may make more sense to do away with the "intimidating" words and create a title meaningful to even the most noobie of noobs. Such as, "Troubleshooting and Diagnostic Messages","A Complete list of boot flags" I dunno. Just a thought. Link to comment Share on other sites More sharing options...
Superhai Posted April 24, 2008 Share Posted April 24, 2008 It may make more sense to do away with the "intimidating" words and create a title meaningful to even the most noobie of noobs. If you find it intimidating, then OSX86 is nothing for you. Buy a proper mac. Just a thought. Link to comment Share on other sites More sharing options...
inimicus Posted April 24, 2008 Share Posted April 24, 2008 Not sure if you're using "you" in the general sense or referring specifically to me. But either way, please note the quotes on the word. Semantics aside, my point is that a new user — one eager to learn — is probably not going to understand what is contained in this thread just by looking at the title. We all know what value these flags have, but how about someone without such experience? Does a noobie know what a boot flag is? Or the benefit they have in debugging a new kext install that seems to have fubar'd their system? That's all I'm getting at, sir. Link to comment Share on other sites More sharing options...
iSkylla Posted April 24, 2008 Share Posted April 24, 2008 Well if they don't then once they start tinkering with it, they'll learn quickly. Link to comment Share on other sites More sharing options...
inimicus Posted April 24, 2008 Share Posted April 24, 2008 /me <3 your avatar. Link to comment Share on other sites More sharing options...
00diabolic Posted April 25, 2008 Author Share Posted April 25, 2008 Well if they don't then once they start tinkering with it, they'll learn quickly. Yeah I would agree. Noobies gotta learn somewhere. I would not no what to title this in order to get noobies to get it besides what it is already. But I'll think about it. Troubleshooting diagnostic messages would just be way to broad really. I'll try to adjust it some. Hager already did so now I dont know if I can anyway. Link to comment Share on other sites More sharing options...
00diabolic Posted April 27, 2008 Author Share Posted April 27, 2008 I think separating the options for vanilla and modified kernels would be better. I looked into this and the only boot option I know of that is strictly hacked kernel only is the fsb ones. Do you know what other ones might be hacked kernel only? I mentioned on the fsb flag that it is known only to work with hacked kernel. Link to comment Share on other sites More sharing options...
00diabolic Posted April 28, 2008 Author Share Posted April 28, 2008 More updates thanks everyone who helped. Link to comment Share on other sites More sharing options...
mwtnzb Posted April 29, 2008 Share Posted April 29, 2008 Very Handy. Mucho Thanks. Link to comment Share on other sites More sharing options...
00diabolic Posted April 30, 2008 Author Share Posted April 30, 2008 Very Handy. Mucho Thanks. No problem. Now If I could only get this sticked somewhere. It would I'm sure reach a lot more people. Link to comment Share on other sites More sharing options...
Hagar Posted April 30, 2008 Share Posted April 30, 2008 thought this might be useful http://forum.insanelymac.com/index.php?showtopic=38172 Link to comment Share on other sites More sharing options...
00diabolic Posted May 1, 2008 Author Share Posted May 1, 2008 thought this might be useful http://forum.insanelymac.com/index.php?showtopic=38172 Thanks Hager. I never knew about some of those flags.. not the most useful ones but I added them to my list. All the hacked kernel flags are under there own group now. Do you think we can get this topic sticked in this thread now? Link to comment Share on other sites More sharing options...
lordzed Posted May 3, 2008 Share Posted May 3, 2008 Thanks for the flag info. Link to comment Share on other sites More sharing options...
00diabolic Posted May 5, 2008 Author Share Posted May 5, 2008 Thanks for the flag info. NP.. Hey didn't you post here already. What happened to that post? It seems to have disappeared along with some others two. Weird. Ahhh Well... This took me a while to comprise.. Sure hope people here dont let this topic die. Nice guide on the Darwin Bootloader. I finally got around to reading it and found it quite useful. Don't worry, Mebster will sticky it for you eventually if you ask, as he is a pretty kind mod Regards, MoC Your welcome. Link to comment Share on other sites More sharing options...
Recommended Posts