Problems when upgrading the kernel
Hi! I've got a new Intel Pentium 4 dual core server with sarge (3.1r1) installed from the binary-1 CD. (It seems like the e1000 network module in Debian is too old to support the network cards and I couldn't use the netinst CD. There are two Intel 82573 gigabit controllers on the motherboard.) Since the CPU is dual core I need to upgrade to an SMP kernel to use them both, right? So I installed the kernel from kernel-image-2.6.8-2-686-smp_2.6.8-16sarge1_i386.deb but when i reboot the server hangs at "Uncompressing Linux...". I then tried to install both kernel-image-2.6.8-3-686-smp_2.6.8-16sarge2_i386.deb and kernel-image-2.6.8-3-686_2.6.8-16sarge2_i386.deb with the same result. Could I have done anything wrong? Why wont the kernel unpack on this machine? Has anyone else experienced the same problem? Any help would be appreciated. I'm out of ideas myself. :-) Best regards, Jonas Mixter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
System "freeze" / IBM x3650 kernel options
Hi! I have an IBM x3650 server with a single quad-core 2.0 GHz Intel Xeon (and one empty CPU-slot) and 4 GB RAM. The system is running an ordinary installation of etch. I used the linux-image-2.6.18-6-686-bigmem kernel but had some strange problems with the server. It all booted fine but occasionally the entire system freezed for a few seconds. Both running services (smtp, pop, imap-daemons, ongoing ssh-sessions) and the local console is "dead". After a little while (about 10-20 seconds typically) all the services became avaliable again. This has happened at least 5-6 times during last afternoon and evening. I booted the server with noapic, nolapic and clock=pit as kernel options (I later saw that clock was replaced with clocksource, so I don't know if that option changes anything) during the problems. The kernel hangs from time to time at boot without the noapic and nolapic options, and there also seems to be problem with clock skew on the machine. Now I've upgraded the kernel to etchnhalf (linux-image-2.6.24-etchnhalf.1-686-bigmem) and I hope that this will solve the problem. I have seen a few signs of the freeze after the upgrade, but I cannot verify it yet. The previous booting problems without noapic and nolapic seems to be gone with this kernel version, so the kernel now boots without any special options. I have had a few problems with the clock too after the upgrade... The kernel prints this at boot time: kernel: Time: tsc clocksource has been installed. So, finally, my question... :-) Is there anyone else running etch on a IBM x3650 (dual or quad core, I have clock skew-problems with another server too that has a dual core Xeon)? Is there any kernel parameters needed? Which kernel version is recommended? 2.6.18, 2.6.24 or a custom kernel? Does anyone else (with a x3650 or not) have similar problems with etch and x3650? I get no errors in dmesg or syslog about the freeze and the system just run on as nothing has happened afterwards. Best regards, Jonas Mixter -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
PHP and memory_limit
Hi list! I've got a problem with PHP and memory_limit. It seems like the the memory usage in the following example isn't limited at all, even though memory_limit is set. I've tried this on both lenny and squeeze with the standard php.ini. Libgd (gd.so) is included as an extension and also from the standard Debian package. When running the following example, it seems like PHP doesn't know how much memory is used by the PHP process. In php.ini, memory_limit is set to 32 MB, PHP thinks it uses ~57 kB of memory. That's all good, but the process uses more than 330 MB of memory when imagecreatetruecolor() is finished! Please see the output below. I've also tested the same script on OS X (version 10.6.6, PHP 5.3.3) and the execution is aborted when the memory usage is running off. Just as I would anticipate. I'm not seeking advice on OS X... I'm just providing the output as comparison. Of course, this isn't any problem if the PHP process uses only 300 MB of memory. But this will also work with larger images and memory usage of several GB. I've managed to take down a server completely with just this single line of PHP code. Could this be because libgd is loaded as an extension? Is this behaviour then by design? Is there anyone else on the list that could reproduce the same result? I've tested on several Debian boxes at the office, and they all happily let's me use way more memory that allowed. Best regards, Jonas Mixter --- Example output from Debian machines --- # php ./mem_test PHP memory limit before imagecreatetruecolor(): 32M PHP memory usage before imagecreatetruecolor(): 58280 bytes Process memory usage before imagecreatetruecolor(): 6 MB Creating image... Will allocate ~300 MB of memory PHP memory limit after imagecreatetruecolor(): 32M PHP memory usage after imagecreatetruecolor(): 67064 bytes Process memory usage after imagecreatetruecolor(): 338 MB --- Example output from OS X --- $ php ./mem_test PHP memory limit before imagecreatetruecolor(): 128M PHP memory usage before imagecreatetruecolor(): 644976 bytes Process memory usage before imagecreatetruecolor(): 8 MB Creating image... Will allocate ~300 MB of memory Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 4 bytes) in /Users/jonas/mem_test on line 20 --- The PHP-file mem_test.php --- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d5136c9.3000...@jamtport.se
Re: PHP and memory_limit
Hi Stan! Thank you for your answer. Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 4 bytes) in /Users/jonas/mem_test on line 20 Looks like you have a problem with OSX as well. Your test failed at allocating 40 KB when 128 MB was available. So, it's not failing at all on Debian, and it's failing incorrectly on OSX. PHP allocates memory in chunks until memory_limit has been exceeded. At the time the script stopped executing, it was trying to allocate another 40 kB and probably used about 127,96 MB already. I'd say you should hit a PHP mailing list or IRC channel. They'll likely know this stuff better than anyone here. This seems to be related to Debian since this works as expected in Ubuntu (don't know the version) with PHP 5.2.14 and on another unknown linux-box with PHP 5.3.5. I haven't been able to recreate the problem on a non-Debian box. BTW, if you're going to be processing images, there's not way around consuming memory, thus you'll just have many fail if you set the memory limit low. That doesn't get any work done. The problem is that the processing doesn't fail. ;-) The thing is that the code isn't mine, but the server is and I'd like to make sure that the server cannot be abused like this. Could you recreate the problem Stan? Or does the PHP code fail with an error if you run it on lenny or squeeze? Regards, Jonas Mixter -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d516974.6050...@jamtport.se
