Il 08/02/2011 15:11, Stan Hoeppner ha scritto: >> I am currently running squeeze 2.6.32-5-686-bigmem. The machine has > > Why run the 32bit distro with the bigmem kernel on an AMD64 box? And why run > the bigmem kernel on a machine with only 1 GB RAM? The bigmem kernel is only > needed for PAE, which means machines with more than 3GB (IIRC) of RAM. Anyway, > you should always use the AMD64 kernel on supported CPUs as you get better > overall performance. I installed the 32bit OS because the 64bit ones i tried were crashing miserably. I know i shouldnt be using the 32bit bigmem kernel, but it was the default when i installed lenny using the preconfigured images from the datacenter. I guess i could easily switch to the default kernel, though. >> 1024MB of ram and 2x160Gb Sata HDDs. The NIC is a 100MBit realtek one, >> with proper drivers from the firmware-realtek debian package. > >> I would love to have some opinions on how to deal with this. > > First thing I would do is completely disable all power saving features in the > system BIOS, the kernel, and user space. If you still get the freezes, replace > hardware. As i don't have physical access to the machine, i can't play around with the bios. On topics about similar issues i saw replies close to this one you gave me, but i don't really know which direction i should take in order to "disable powersaving". Should i look for hardware specific stuff (like cpu frequency scaling which is directly connected to the CPU "Cool n Quiet" feature) or should i look for OS configuration? Do you know where should i look for information on the matter? > The San Diego core is 5 years old, making your server 4-5 years old. Did you > ever see these system lock ups in the past? If you run straight Lenny with the > regular i386 kernel (not bigmem) do you get these lock ups? > > Is this a brand name server, white box, DIY? If the latter, what motherboard? It's a low end dedicated server i am renting. I've had it for about a week now. This is the output of lspci: $ lspci 00:00.0 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge 00:00.1 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge 00:00.2 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge 00:00.3 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge 00:00.4 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge 00:00.7 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South] 00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10) 00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South] 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:00.0 VGA compatible controller: nVidia Corporation NV18 [GeForce4 MX 4000] (rev c1) I should add that limiting the rtorrent download bandwith to 5MBps has managed to keep the server up, with all the services running for almost a day now. The default setting was to limit the bandwith at 12MBps.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature