There are several implementations for some algorithms, which use CPU instructions which may or may not be available on current system. Is it good idea to just enable (in kernel, not as modules) all of them - i.e. is fastest implementation available on current CPU will be selected automatically?
Also, is OpenSSL will start using these optimized implementations provided by kernel automatically, or it should be configured somehow?
I'm converting my scripts from old net-tools:
ifconfig eth0 192.168.2.1 netmask 255.255.255.0
to iproute2:
ip link set eth0 up
ip addr add 192.168.2.1/24 dev eth0
and I notice that the new commands do not set the broadcast address by default.
What was:
1: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 1c:6f:65:c5:d6:d7 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.1/24 brd 192.168.2.255 scope global eth0
is now:
1: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 1c:6f:65:c5:d6:d7 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.1/24 scope global eth0
I can add the broadcast address to ip addr command, but I wonder if it is needed at all?
First of all, how and where is this broadcast address used? What might break if it is not set?
Second of all, it looks like the routing table still has the correct entries by default:
# ip route show table local dev eth0 scope link
broadcast 192.168.2.0 proto kernel src 192.168.2.1
broadcast 192.168.2.255 proto kernel src 192.168.2.1
I cannot even test it because nowadays no one replies to ping -b.
I've issue with apache. Everything begins about a week ago (so this may be related to latest system updates) - my monitoring tools SMS me about non-working website. I've checked it, and looks like request to trivial cgi (implemented in perl) took 30 seconds. After restarting apache problem was fixed for next few hours/days, and then happens again.
Initially I suspect php, because it was only update (5.3.15->5.3.18) which may affect apache. I've tried to disgrage it back to 5.3.15, but this won't fixed this issue.
Next, I did strace, and looks like delay happens while clone() syscall:
[pid 26659] 1356268557.675934 clone( <unfinished ...>
[pid 26659] 1356268587.684401 <... clone resumed> child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xa1033768) = 32169 <30.008452>
cgi itself runs after that and works ok and fast:
[pid 32169] 1356268587.686614 execve("/var/www/mysite.com/mycgi.cgi", ["/var/www/mysite.com/mycgi.cgi"], [/* 26 vars */]) = 0 <0.000776>
Any ideas why this may happens? How and why clone(2) may block for 30 seconds?! And successfully return after that… It looks like some timeout inside clone() because it always exactly 30 seconds.
I'm using up-to-date Hardened Gentoo Linux, kernel 3.5.4-hardened-r1, apache 2.2.23 (prefork, mod_cgi).
Update: I probably should add: this server isn't under high load. Apache childs use only about 120/40 MB (VIRT/RSS). Server has 2GB RAM, and only 400MB used (without buffers/cache).
I've D-Link DSL-2500U/BRU/D, ADSL mode is "ADSL2+ AnnexM EU-56", configured as bridge and connected to linux (Gentoo) workstation. Line is good enough, I've stable speed 2.09MiB/sec (i.e. about 18-20Mbps)... but I can see this speed only while downloading torrents or when downloading something using multiple connections (like running several wget processes in parallel).
Single wget process download at only 200KiB/sec in average from anywhere (like kernel.org or other servers I've tried). When wget started it may begin downloading at up to 400-500Kib, but quickly lower speed to about 100Kib, and then slowly increase it to 150-200Kib. Of course, this issue apply to any single tcp connection, not only to wget.
I've tried same wget to kernel.org in WinXP SP3, and LiveCDs of OpenSUSE-11.3, Ubuntu-9.04 and Ubuntu-6.10 - just to exclude possibility of wrong configuration of my Gentoo workstation. In all these OS I see same issue - single wget unable to download faster than 200KiB/sec, but I can run several wget's at that speed simultaneously, so it's not limitation of ADSL line.
Initially I think this issue is because of some ISP's shaper, but later I discover WinSeven able to wget from kernel.org at 1-2MiB/sec! Also, I've tried to switch modem from bridge to router mode, and got 1-2MiB/sec in single wget in my Gentoo, so this issue probably has nothing with ISP.
The MTU is set to 1500 on eth0 and 1492 on ppp0. I notice WinSeven use MTU 1480 on pppoe interface, and tried same value on linux - that doesn't helps. Also I've tried to play with different tcp optimizations using sysctl (rmem/wmem/etc.) - also without any success.
Any ideas how to fix this without switching modem from bridge to router?
I'm trying to start 64-bit guest (MacOSX and Windows7) on 32-bit host (Hardened Gentoo Linux, kernel 2.6.28-hardened-r9) using VMware Workstation (6.5.3.185404 and 7.0.1.227600).
If VT-X disabled in BIOS, VMware refuse to start 64-bit guest (as expected). If VT-X enabled in BIOS, VMware start guest without complaining, but then, in about a second (I suppose as soon as guest try to switch on 64-bit) my host reboots (actually, it's more like reset - normal reboot procedure skipped and BIOS POST start immediately).
My hardware is Core 2 Duo 6600 on ASUS P5B-Deluxe with latest stable BIOS 1101. I've power-cycled system, then enabled Vanderpool in BIOS. My CPU doesn't support Trusted Execution Technology, and there no way to disable it in BIOS. I've rebooted several times after that, sometimes with power-cycled, and ensure Vandertool is enabled in BIOS.
I've also run VMware-guest64check-5.5.0-18463 tool, and it report "This host is capable of running a 64-bit guest operating system under this VMware product.".
About a year ago I tried to disable hardened in kernel to ensure this isn't because of PaX/GrSecurity, but that doesn't help. I have not checked 32-bit guests with VT-X enabled yet, but without VT-X they works ok. ASUS provide "beta" BIOS updates, but according to their descriptions these updates doesn't fix this issue, so I'm not sure is it good idea to try it.
My best guess now it's motherboard/BIOS bug. Any ideas?
Update 1: I've tried to boot vt.iso provided at http://communities.vmware.com/docs/DOC-8978 and here is it report:
CPU 0: VT is enabled on this core
CPU 1: VT is enabled on this core
Update 2: I've just tried to boot 32-bit guests (Windows7, Ubuntu9.04 and Gentoo) using all possible virtualization modes. In Automatic, Automatic with Replay, Binary translation everything works, in Intel VT-x/EPT or AMD-V/RVI I got message "This host does not support EPT. Using software virtualization with a software MMU." and everything works. BUT in Intel VT-x or AMD-V mode all 32-bit guests reset host just like 64-bit guests! So, this issue is not specific to 64-bit guests.
One more thing. Using Intel VT-x or AMD-V mode for both 32/64-bit guests my host reset right after starting VM, i.e. before VM BIOS POST and before guest even start booting. But using Intel VT-x/EPT or AMD-V/RVI VM BIOS runs ok, then 64-bit guests start booting (Windows7 completed "Loading files" progressbar), and only after that host reset.