Posts Tagged ‘cores’

Windows XP multicore not detected after CPU update – XP Enable multicore after singlecore install

Friday, April 8th, 2016

Reading Time: 3minutes

windows-xp-add-multicore-with-command-after-multiple-cpu-not-detected
These days it is not common to install Windows XP however for some old unsupproted applications that still work on XP in many countries  in Africa, Asia, Europe and even America. Custom patched Windows XP is still heaveily used for some corporate businesses in accounting and on airports and other government institutions even to these day, I'm aware of Windows still heavily used especially in  Russia, Belarus,Ukraine, Kazakhstan, Armenia, Bulgaria etc.

Hence still there is plenty of softwares designed to work XP the good old Win XP and thus often XP needs to be emulated on VMs though officially not supported any longer  by Microsoft (its Support lifecycle End was for a last time on April 14, 2009).

Now I guess these days I guess nobody doesn't install and use Windows XP on a normal hardware PC Desktop / laptop but XP is continually installed on Virtual machine servers VMWare / VirtualBox.

Hence if you happen to have already migrated or installed some old Windows XP operating systems under VMWare for a corporate clients single core machine (no matter virtual or physical) and the client requires an update of hardware of the Virtual Machine you will be surprised that even though you add a second / third etc. core (new CPUs) the virtual machine hardware and restart the Windows XP installation.

It seems XP is designed to remember the install time CPU model hardware so once the VM and doesn't have a way to update its HAL (Hardware Abstraction Layer) definitions if you install it in Virtualbox thus to make XP recognize the extra added CPU cores it is necessery to do a small hack with a devcon.exe utility downloadable from Microsoft site to do the trick

1. Download the command line devicemanager utility (devcon.exe) from Microsoft Development Network MSDN here.

Note that it will work only if you use the correct version depending whether XP is  (x86/x64) bit install so check it out from My Computer -> Properties.

windows-xp-multicore-not-detected-enable-add-multicore-after-singlecore-windows-xp-install-with-devcon-exe

2  Next. Execute the following 2 commands:

    devcon sethwid @ROOT\ACPI_HAL\0000 := +acpiapic_mp !acpiapic_up
    devcon update c:\windows\inf\hal.inf acpiapic_mp

devcon.exe will  let the automatic hardware detection find out the extra CPU (multicores) added.
Wait 'till you get prompted for a reboot.
Be brave Reboot! 🙂

There is pretty much more fun useful things you can do with devcon.exe such as disabling USBs from command line,

DEVCON-command-DisableUSB_on-windows-xp-7-8-howto

listing your PCI devices and so on:

devcon-windows-command-to-list-pci-devices-on-xp7-win8-win10

You should now see all cores, hooray cores will appear in Task Manager / System Information.

Fix Apache [error] [client xx.xxx.xxx.xx] PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0

Wednesday, August 14th, 2013

Reading Time: < 1minute

I have a busy Linux server with 24 cores each running on ..4 Ghz. Server is configured to server  Apache and MySQL queries and a dozen of high traffic websites are hosted on it. Until just recently server worked fine and since about few days I started getting SMS notifications that server is inaccessible few times a day. To check what's wrong I checked in /var/log/apache2/error.log  and there I found  following error:

[error] [client 95.107.233.2] PHP Warning:  Unknown: Input variables exceeded 1000.

To increase the limit change max_input_vars in php.ini. in Unknown on line 0 referer: http://www.site-domain-name.com/predict/2013-08-10
 

Before I check Apache error.log, I had a guess that ServerLimit of 256 (spawned servers max) is reached so solution would be raise of ServerLimit to more than MaxClients setting defined in /etc/apache2/apache2.conf. After checking /var/log/apache2/error.log I've realized problem is because the many websites hosted on server exceed maximum defined variables possible to assign by libphp in php.ini. maximum possible defined variables before PHP stops servering is set through max_input_vars variable

As I'm running a Debian Squeeze Linux server, here is what is set as default for max_input_vars in /etc/php5/apache2/php.ini:

; How many GET/POST/COOKIE input variables may be accepted
; max_input_vars = 1000

So to fix it in php.ini just raised a bit setting to 1500, i.e.:

max_input_vars = 1500

Though I hit the error on Debian I assume same error occurs on Redhat RPM based (Fedora, CentOS, RHEL Linux) servers.
Hence I assume

max_input_vars = 1500

or higher should fix on those servers too. Looking forward to hear if same error is hit on RedHats.

Enjoy 🙂
 

List and get rid of obsolete program core dump files and completely disable core files on FreeBSD

Tuesday, November 1st, 2011

Reading Time: < 1minute
My FreeBSD router has started running out of space, I looked for ways to clean up some space. So I remembered some programs are generating core files while they crash. Some of these files are really huge and ban be from 1Mb to > 1G.

I used find to first list all my produced core files starting from root directory (/) , like so:

find / -name core -exec du -hsc {} ;
....

Having a list of my core files with the respective core file size and after reviewing, I deleted one by one the cores which were there just taking up space.
It’s a wise idea that core dumps file generation on program crash is completely disabled, however I forgot to disable cores, so I had plenty of the cores – (crash files which are handy for debug purposes and fixing the bug that caused the crash).

Further on I used an /etc/rc.confdumpdev=NO , variable which instructs the kernel to not generate core files on program crash:

freebsd# echo 'dumpdev=NO' >> /etc/rc.conf

Next, to make dumpdev=NO , take affect I rebooted the server:

freebsd# shutdown -r now
...

There is a way to instruct every server running daemon to know about the newly set dumpdev=NO by restarting each of the services with their init scripts individually, but I was too lazy to do that.