Oddly high load average
The load average on my machine is inexplicably high; when idle, it sits up between 0.6 and 0.7. Though I'm running a snapshot from last night, I've seen the same behaviour since I first installed a 4.4 snapshot from about three weeks ago. This is on a Lenovo X200. As I understand it, load average is supposed to be roughly based on the number of processes in the run queue. But I don't actually have any processes running, or blocking. I shut down almost every non-essential service, and I'm still seeing a load average consistantly above 0.5: - # ps auxw USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 1 0.0 0.0 408 360 ?? Is 2:19AM0:00.01 /sbin/init root 11766 0.0 0.1 552 740 ?? Is 2:19AM0:00.00 syslogd: [priv] (syslogd) _syslogd 22554 0.0 0.1 584 796 ?? I 2:19AM0:00.17 syslogd -a /var/empty/dev/log root 12786 0.0 0.1 400 768 ?? Ss 2:20AM0:00.76 /usr/sbin/apmd -C root 5282 0.0 0.1 560 900 ?? Ss 2:20AM0:00.03 cron root 28457 0.0 0.1 380 772 ?? Ss11:34AM0:00.01 wsmoused root 6904 0.0 0.1 548 532 C0 Ss 2:20AM0:00.03 -ksh (ksh) root 6962 0.0 0.0 348 312 C0 R+/0 11:35AM0:00.00 ps -auxw root 13089 0.0 0.1 244 888 C1 Is+2:20AM0:00.00 /usr/libexec/getty std.9600 ttyC1 root 18525 0.0 0.1 380 888 C2 Is+2:20AM0:00.00 /usr/libexec/getty std.9600 ttyC2 root 24949 0.0 0.1 340 888 C3 Is+2:20AM0:00.00 /usr/libexec/getty std.9600 ttyC3 root 19012 0.0 0.1 380 892 C5 Is+2:20AM0:00.00 /usr/libexec/getty std.9600 ttyC5 # uptime ; vmstat 10 6 ; uptime 11:36AM up 9:16, 1 user, load averages: 0.71, 0.72, 0.67 procsmemory pagedisk traps cpu r b wavm fre flt re pi po fr sr sd0 int sys cs us sy id 0 0 0 3460 768044 86 0 0 0 0 0 1 30 352 78 0 0 99 0 0 0 3460 7680446 0 0 0 0 0 0 2213 38 0 0 100 0 0 0 3460 7680444 0 0 0 0 0 0 23 5 38 0 0 100 0 0 0 3460 7680444 0 0 0 0 0 0 23 5 39 0 0 100 0 0 0 3460 7680444 0 0 0 0 0 0 24 5 38 0 0 100 0 0 0 3460 7680444 0 0 0 0 0 0 23 5 39 0 0 100 11:36AM up 9:17, 1 user, load averages: 0.63, 0.70, 0.67 # uptime ; iostat 10 6 ; uptime 11:37AM up 9:18, 1 user, load averages: 0.65, 0.69, 0.67 ttysd0 cpu tin tout KB/t t/s MB/s us ni sy in id 0 16 16.15 1 0.01 0 0 0 0 99 00 2.00 0 0.00 0 0 0 0100 00 16.00 0 0.00 0 0 0 0100 00 0.00 0 0.00 0 0 0 0100 00 2.67 0 0.00 0 0 0 0100 00 16.00 0 0.00 0 0 0 0100 11:38AM up 9:19, 1 user, load averages: 0.70, 0.69, 0.67 # - So, what exactly is my machine doing? Note that this doesn't really seem to be causing me any grief: apmd is properly dropping my cpuspeed, hw.sensors are all showing cool-running temperatures, and I'm still getting at least seven hours of battery life, even with a wireless connection. I just have this oddly high load average, for seemingly no reason at all. Here's the dmesg. Please ignore the stuff around em0; that's me trying to figure out the phy for the Montevino chipset: - OpenBSD 4.4-current (GENERIC.MP) #11: Fri Nov 7 02:18:56 EST 2008 [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 999145472 (952MB) avail mem = 969613312 (924MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (62 entries) bios0: vendor LENOVO version 6DET30WW (1.07 ) date 09/10/2008 bios0: LENOVO 7454CTO acpi0 at bios0: rev 2 acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA DMAR SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) EHC0(S3) EHC1(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz, 2394.34 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,CX16,xTPR,NXE,LONG cpu0: 3MB 64b/line 8-way L2 cache cpu0: apic clock running at 266MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz, 2394.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,CX16,xTPR,NXE,LONG cpu1: 3MB 64b/line 8-way L2 cache ioapic0 at mainbus0 apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at
Re: Oddly high load average
Mark Zimmerman wrote: : I bet you could get your load average to drop if you forced your cpu : to run full speed even when doing nothing. I am guessing that this is : not really what you want. Not only would that not fix it, it doesn't make any sense, either. If my machine has no workload, increasing the available power to process said nonexistant workload isn't going to change anything. And let's not forget that I'm curious to find out why the load average is up there when there's no apparent workload; dropping the load average is not really the goal of the question.
Re: Oddly high load average
Theo de Raadt wrote: : The load average on my machine is inexplicably high; when idle, it sits up : between 0.6 and 0.7. : : Oh my god, the horror. Nothing is wrong with your machine at all. : However, I have a diff which will probably keep you happy. Not sure if you caught my last paragraph, but I did say that nothing was wrong with the system at all, I'm just curious as to why the average is high.
Re: Oddly high load average
Theo de Raadt wrote: : Looks like you don't know the algorithms used to calculate the number. : But it is clearly beyond your skills to go read the source. I would assume you're referring to uvm_loadav in uvm_meter.c? That's where I'm looking. I was hoping for a little English to help me with my understanding, but maybe I'm just not clever enough.
Re: Duplicate incoming packets to multiple destinations using pf
Simen Stavdal wrote: :1) Less configuration on the devices (and also less load, though not a :big problem anymore). This is not really a problem for small :installations, but once you have 500+ devices to configure, it is easy :to do the maths. You should always have systems in place to manage your installation. Larger installations require more effort in getting those systems in place. There are umpteen options available at your fingertips with little to no effort, and there's another umpteen products -- both free and paid -- that will help you do this as well. This should *never* be a reason for doing (or not doing, as the case may be) something. And I'm speaking as someone with experience handling large installations. :2) Easier to administer centrally by making profiles based on source :addresses etc. Um, sure? See above. :3) Maintaining the source address in the trap udp header. :I have looked at trap exploders (my guess is that you are referring :to CA's trap exploder?), but a lot of these store and forward the :traps, thereby issuing new packets with a source address of the trap :exploder. Perhaps Claers idea of proxying with net-snmp is a way to do :it (but I have a feeling this might be store and forward too... I'll :check it out though. No, I wasn't explicitly referring to CA's Trap Exploder, or I would have capitalized it. It's just what we call them in my place of employ. I'll admit that the source issue is a valid one, and one we struggled with (with our internally developed trap exploder). However, if you *really* want to maintain source address, I'd argue that the proper way to do it is have the source send multiple traps. As a workaround, you can try to coax your trap exploder (or proxy or forwarder or whatever you want to call it) to add the original source IP as a varbind, and then configure your NMSs to replace the source with the contents of that varbind. (Alternatively, Net-SNMP can pass the trap on to an external script. From there, the possibilities are endless.) - Damian
Re: Duplicate incoming packets to multiple destinations using pf
Simen Stavdal wrote: : I am not trying to escape the fact that one needs systems in place : to manage large installations, I am merely looking for what *I* : think would be a better way to deploy resources. I'm just going to drop this part of the thread. : As a service provider I can provide advice (and hence I posted this : question in the first place to see if there was a good way to : multicast traps to predefined destinations), but it is not in my ... but I want to keep this in the message. : Maybe this could be input for further development of pf? As one can : think of many alternative workarounds, can one think of a reason : not to implement this feature (technially or otherwise)? Worth submitting a feature request? : I can think of other scenarios too, where this functionality might : prove useful, for instance for netflow export which may produce a : lot more output than snmp traps, and thereby adding load on the : network. Preserving the source address is important to identify the : source, and while you can do this in snmp traps, using the i-agent : field, or a varbind, it may not be the case for other protocols. Now, we've changed the scope of the problem from SNMP to traffic. And you've already answered your own question. You have a piece of machinery. It's going to send traffic, to a given destination. However, this destination may be more than one machine. It may be two. It may be five. And the traffic may be single datagrams, or it may be a constant stream. Who knows. You don't want to update the source when this destination point changes, due to administrative overhead. So, you need an arbitrary resolution that is not protocol-specific, that provides a single point of management (or otherwise incurs a very low administrative overhead), and where the client doesn't need to be modified. Remember way above when you mentioned the word multicast? There's absolutely no reason why your trap destinations couldn't be a multicast address. Same with your netflow destinations. Or, heck, your SMTP destinations, if you're feeling adventurous. Granted, this is a network re-architecture, but see below before responding. -- There's two different discussions going on here, that are complicating things. 1) You're looking for a short-term fix for your problem. You've been handed a short-term fix. 2) Because you don't like the short-term fix, the conversation has shifted to looking for a long-term fix (changes to pf, network re-architectures, etc.).
Re: Duplicate incoming packets to multiple destinations using pf
Simen Stavdal wrote: : Worth submitting a feature request? : --- I looks like this would be the best solution --- Sounds like you have your desired solution. So long as the OBSD developers accept your request as valid. : --- The subject of my posting is Duplicating incoming packets to : multiple destinations using pf --- : --- And I never initially asked a closed question, but I did state : a scenario --- Right, so I was led to believe that the context of your question was limited to re-mapping SNMP destinations. In other words, you had a specific problem on hand to solve, and that SNMP trap multiplexing was that problem. : You have a piece of machinery. It's going to send traffic, to a : given : destination. However, this destination may be more than one : machine. It : may be two. It may be five. And the traffic may be single : datagrams, or : it may be a constant stream. Who knows. You don't want to update : the : source when this destination point changes, due to administrative : overhead. : So, you need an arbitrary resolution that is not protocol-specific, : that : provides a single point of management (or otherwise incurs a very : low : administrative overhead), and where the client doesn't need to be : modified. : --- I wouldn't describe the scenario as arbitrary --- Let's not argue over words. You need a resolution that can be applied to any number of situations. You need a resolution that is sufficiently abstracted such that it addresses the root problem, not the specific use case you supplied. This is where I went wrong, and my apologies: I addressed the specific instance of the problem, and not the underlying challenge. : --- There is a very usable syntax in place, which is also the : beauty of pf --- Whether or not it's the right tool for the job, I leave it up to the OBSD developers to decide. : --- A multicast sends traps to all listening devices, which : excludes the opportunity to filter destinations in pf --- Not entirely true. A multicast packet is destined towards a single address, for which multiple (physically separate hosts) are listening. Network gear duplicates the packet as needed, to ensure it reaches all members of that multicast group. I'm arguing semantics here, but there's a very important distinction: your SNMP client only sends out *one* packet per trap. : things. : 1) You're looking for a short-term fix for your problem. You've : been handed : a short-term fix. : --- I didn't say I was looking for a short term fix --- Not explicitly, but you implied it with your use case. Or maybe I misread you. Either way, you've established that you don't care to fix this specific SNMP problem, you want PF to be modified to do what you need. (Speaking of which, there's Yet Another Alternative. Set your trap destination to be some arbitrary address. Assign that address to the loopback interface of *all* SNMP receivers. Assign unique IPs to their external interfaces. That way, when you use pf's dup-to, each machine will actually receive the packet. It's clean, uses the functionality that currently exists, is only a mild abuse of best practices, and requires no network reconfiguration. This approach can be duplicated as needed.) - Damian
Re: Duplicate incoming packets to multiple destinations using pf
Claer wrote: : Thanks for the answer, I guess dup-to isn4t the right tool then... : Has anyone tried to achieve what I am trying to do though? : I am obviously open to other ideas. : Maybe I'll give you a wrong path but, did you looked at proxying the : trap with net-snmp ? : Direct the original trap to your firewall (carped ?) and then when the : trap arrives on it, ask net-snmp to send serveral traps to the : supervision servers. I can't help but feel that the OP is trying to use the wrong tool for the job. There are two really good options when dealing with what he's trying to do: 1) Configure multiple SNMP trap destinations in the client. Any halfway decent SNMP stack supports trapping to more than one destination. But in the cases this doesn't work... 2) Investigate a trap exploder. Heck, you could even run it right on the firewall itself, as Claer has suggested. (In fact, this is *exactly* what Claer suggested, only I've called it a fancy name: trap exploder.)
Re: Random crashes with Intel D945GCLF2
Robert wrote: On Thu, 9 Oct 2008 23:10:02 +0200 (CEST) Mark Kettenis [EMAIL PROTECTED] wrote: I just committed a fix for the dmesg corruption problem. This may also fix the random crashes you were saying. Current snapshots should already have the fix. Boy, those Intel-branded boards have shitty BIOSes... Rev 1.84 of sys/arch/amd64/amd64/machdep.c also fixes the dmesg-output on my Thinkpad X200, a Centrino 2 system. And having it in place for going on 48 hours with no freeze, I'd say it fixed my problem as well. - Damian
Re: Random crashes with Intel D945GCLF2
Mark Kettenis wrote: I just committed a fix for the dmesg corruption problem. This may also fix the random crashes you were saying. Current snapshots should already have the fix. Thanks, Mark! I'll give it a shot tonight and report back with the results. Boy, those Intel-branded boards have shitty BIOSes... And support. They've basically said that OpenBSD is not a supported OS, so they won't help me. Neither do they support diagnostics from third-party programs or companies. I think I've learned my lesson here. - Damian
Re: Random crashes with Intel D945GCLF2
On Tue 08/10/07 20:02, Damian Gerow [EMAIL PROTECTED] wrote: Sevan / Venture37 wrote: Are you running the latest version of the BIOS on the board?? http://clk.atdmt.com/UKM/go/111354029/direct/01/ Ah, yes, I knew I forgot to include something. I also updated the BIOS to the latest revision today, and re-ran all the tests, to the exact same conclusion. A few people have pointed out that I didn't include the dmesg. Here it is, in all its ugly glory. --- \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\ M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^? snip about 100 more lines of the same \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\ M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M ^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?OpenBSD 4.4-current (GENERIC.MP) #1868: Sat Oct 4 17:50:16 MDT 2008 [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2123968512 (2025MB) avail mem = 2062356480 (1966MB) RTC BIOS diagnostic error 80clock_battery mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe3590 (23 entries) bios0: vendor Intel Corp. version LF94510J.86A.0103.2008.0814.1910 date 08/14/2008 bios0: Intel Corporation D945GCLF2 acpi0 at bios0: rev 0 acpi0: tables DSDT FACP APIC WDDT MCFG ASF! acpi0: wakeup devices SLPB(S4) P32_(S4) UAR1(S4) UAR2(S4) PEX0(S4) PEX1(S4) PEX2(S4) PEX3(S4) PEX4(S4) PEX5(S4) UHC1(S3) UHC2(S3) UHC3(S3) UHC4(S3) EHCI(S3) AC9M(S4) AZAL(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Atom(TM) CPU 330 @ 1.60GHz, 1596.30 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,A CPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,TM2,CX16,xTPR,NXE,LONG cpu0: 512KB 64b/line 16-way L2 cache cpu0: apic clock running at 135MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Atom(TM) CPU 330 @ 1.60GHz, 1628.01 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,A CPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,TM2,CX16,xTPR,NXE,LONG cpu1: 512KB 64b/line 16-way L2 cache cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Atom(TM) CPU 330 @ 1.60GHz, 1628.01 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,A CPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,TM2,CX16,xTPR,NXE,LONG cpu2: 512KB 64b/line 16-way L2 cache cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Atom(TM) CPU 330 @ 1.60GHz, 1628.01 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,A CPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,TM2,CX16,xTPR,NXE,LONG cpu3: 512KB 64b/line 16-way L2 cache ioapic0 at mainbus0 apid 2 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 2 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 4 (P32_) acpiprt2 at acpi0: bus 1 (PEX0) acpiprt3 at acpi0: bus -1 (PEX1) acpiprt4 at acpi0: bus 2 (PEX2) acpiprt5 at acpi0: bus 3 (PEX3) acpiprt6 at acpi0: bus -1 (PEX4) acpiprt7 at acpi0: bus -1 (PEX5) acpicpu0 at acpi0 acpicpu1 at acpi0 acpicpu2 at acpi0 acpicpu3 at acpi0 acpibtn0 at acpi0: SLPB pci0 at mainbus0 bus 0: configuration mode 1 pchb0 at pci0 dev 0 function 0 Intel 82945G Host rev 0x02 vga1 at pci0 dev 2 function 0 Intel 82945G Video rev 0x02 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) agp0 at vga1: aperture at 0x8000, size 0x800 ppb0 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x01: apic 2 int 17 (irq 255) pci1 at ppb0 bus 1 re0 at pci1 dev 0 function 0 Realtek 8168 rev 0x02: RTL8168C/8111C (0x3c00), apic 2 int 16 (irq 11), address 00:1c:c0:70:6a:11 rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 2 ppb1 at pci0 dev 28 function 2 Intel 82801GB PCIE rev 0x01: apic 2 int 18 (irq 255) pci2 at ppb1 bus 2 ppb2 at pci0 dev 28 function 3 Intel 82801GB PCIE rev 0x01: apic 2 int 19 (irq 255) pci3 at ppb2 bus 3 uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x01: apic 2 int 23 (irq 9) uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x01: apic 2 int 19 (irq 10) uhci2 at pci0 dev 29 function 2 Intel 82801GB USB rev 0x01: apic 2 int 18 (irq 11) uhci3 at pci0 dev 29 function 3 Intel 82801GB USB rev 0x01: apic 2 int 16 (irq 11) ehci0 at pci0 dev 29 function 7 Intel 82801GB USB rev 0x01: apic 2 int 23 (irq 9) usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb3 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0xe1 pci4 at ppb3 bus 4 pcib0 at pci0 dev 31 function 0 Intel 82801GB LPC rev 0x01 pciide0 at pci0 dev 31 function 1 Intel 82801GB IDE rev 0x01: DMA, channel 0 configured to com\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M ^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M
Random crashes with Intel D945GCLF2
Release: 4.4 snapshot as of 2008/06/10 Platform: amd64 UP and MP Hardware: Intel Atom 330 on D945GCLF2 I picked up an Intel D945GCLF2 last week to play with, and it's been fairly unstable. Specifically, it randomly just freezes: no ddb, no error messages, it just hangs. When it's hung, the IP stack still seems to be functional, as I can ping the machine and establish TCP sessions, and established SSH sessions do not disconnect. However, anything beyond that is unresponsive, including the console At first I thought it was the networking, but after installing an em(4), and not loading pf on boot, I still see freezes. Then I tried disk load, but that didn't cause any reproducable errors either. Next I tried CPU load, which involved various factors of booting the UP vs. MP kernel, enabling and disabling hyperthreading, and running load tests. This didn't seem to trigger it either. So I figured it's got to be RAM. I've completed four full runs of memtest86+ today, and no errors have come up. However, I've found something strange: If I ask memtest86+ to probe the system for RAM, it seems to start looking for addresses above the 2GB mark -- and, obviously, throwing errors for those addresses. Shortly after that, it freezes. (Additionally, if I tell it to use BIOS - All memory sizing, it appears to look at memory addresses up to the 4GB mark. But this doesn't really surprise me.) Using BIOS - Std works just fine, and turns up no errors. I'm not sure if this is normal, and I don't have another x86/x64 machine to test on. But I'd expect that when probing, it shouldn't be told there's more memory available than what actually is present. Is anyone running a stable D945GCLF2?
Re: Random crashes with Intel D945GCLF2
Sevan / Venture37 wrote: Are you running the latest version of the BIOS on the board?? http://clk.atdmt.com/UKM/go/111354029/direct/01/ Ah, yes, I knew I forgot to include something. I also updated the BIOS to the latest revision today, and re-ran all the tests, to the exact same conclusion. - Damian
Re: OT: quiet fans and heatsinks
Thus spake J.C. Roberts ([EMAIL PROTECTED]) [05/06/06 05:20]: : Most people just don't get it. The equation is simple: : : HEAT * TIME And, as someone else has more elegantly pointed out: COOL != LOUD A well-designed cooling system can keep your system running cooler than with stock hardware, all while generating much less noise.
Re: OT: quiet fans and heatsinks
Thus spake J.C.Roberts ([EMAIL PROTECTED]) [05/06/06 08:35]: : You're right that well designed cooling systems can make things run : cooler and with less noise but more importantly, there's only one way to : determine if various cooling systems are actually well designed; namely, : you have to go buy a stack of them and then test all of them in your : particular application... -and how do you find out if they are reliable? Funny. I did a bunch of research for other's opinions on the Web, and the first set of heatsink/fans I purchased turned out to be quiet, cool, and reliable -- three years later, I'm still using the original fan I purchased. All subsequent purchases from the same company (Zalman) have proven to be pretty much exactly the same: quiet, cool, and reliable. (This is my last contribution to this thread. It's pretty off-topic, and the original poster already has a few good leads on good cooling solutions.) - Damian
Re: ALTQ priq: bandwidth or no?
Thus spake Jeff Quast ([EMAIL PROTECTED]) [11/05/06 09:22]: : On 5/11/06, Damian Gerow [EMAIL PROTECTED] wrote: : I'm not interested in bandwidth limitations, so it looks like priq is : likely my best bet. : [...] : Then I create a queue with a bandwidth limit of 700Kbps. : : The man page is a little vague on this point : The priq scheduler does not support band-width specification. : : huh? Exactly my point. The man page states that priq does /not/ support bandwidth-restricted queues, yet the altq statement has a bandwidth setting in it (and seems to require it). So: does priq do bandwidth queueing at all? Is the altq definition wrong, or is the manpage misleading? (Or am I completely missing something here?) : Use cbq if you want to throttle bandwidth to a limit, something like: I don't. That's the point.
Re: ALTQ priq: bandwidth or no?
Thus spake Melameth, Daniel D. ([EMAIL PROTECTED]) [13/05/06 20:06]:
: It would seem altq wants a bandwidth declaration. However, from man 5
: pf.conf:
:
: If bandwidth is not specified, the interface bandwidth is used.
And OpenBSD complains bitterly when not defining the bandwidth on a pppoe
virtual interface:
# pfctl -F queue -f /etc/pf.conf
altq cleared
cannot determine interface bandwidth for pppoe0, specify an absolute
bandwidth
altq not defined on pppoe0
/etc/pf.conf:73: errors in queue definition
more specific queue errors here
pfctl: Syntax error in config file: pf rules not loaded
#
: In any event, all my priq queues appear to simply be prioritized and the
: overall outbound bandwidth of all queues, collectively, never exceeds
: the altq bandwidth keyword--and this works well for me with the
: exception of the annoying PR 4312.
The way I'm reading 4312 is that priq is doing something it isn't supposed
to do -- bandwidth throttling. No?
And yes, it looks like I've run into 4312 as well. Annoying.
The answer to my previous question leads me to one followup:
My altq definition:
altq on $ext_if priq bandwidth 700Kb queue { default, high, bittorrent,
vpn, pubservices }
queue default priority 3 priq(default)
queue high priority 7
queue bittorrent priority 0
queue vpn priority 4
queue pubservices priority 5
is subsequently applied to the interface as such:
pass in quick on $ext_if inet proto tcp from any to $mailserver port
$mailports flags S/SA modulate state queue (pubservices, high)
pass in quick on $ext_if inet proto tcp from any to $webserver port
$webports flags S/SA modulate state queue (default, high)
pass in quick on $ext_if inet proto tcp from any to $btserver port $btports
flags S/SA modulate state queue (bittorrent, default)
pass in quick on $ext_if inet proto gre from any to $ian modulate state
queue (vpn, high)
pass out quick on $ext_if inet proto tcp from $external_addr to any flags
S/SA modulate state queue (default, high)
pass out quick on $ext_if inet proto { udp, icmp } from $external_addr to
any modulate state queue (default)
pass out quick on $ext_if inet proto gre from $external_addr to any
modulate state queue (vpn, high)
As priq seems to be doing bandwidth throttling, does this not place an
artificial bandwidth restriction of 700Kb/s on my /inbound/ traffic as well
(which is something more in the order of a raw 3Mbps)? Yes, I fully
recognize that by the time it gets here it's already traversed the pipe, but
if altq only allows the OS to process at 700Kbps, then the pipe is
effectively 700Kbps.
(FWIW, I've done a few bandwidth tests that conradict that directly -- i.e.
I transfer close to the practical maximum of 3Mbps, not the artificial
maximum of 700Kbps. Hence my question.)
ALTQ priq: bandwidth or no?
After a bandwidth incident a few hours ago, I'm starting to look at doing
some queuing on my (unfortunately) asynchronous link at home. But as I'm
doing so, I've got a few questions. I'm not interested in bandwidth
limitations, so it looks like priq is likely my best bet.
If I declare my altq as such (my DSL modem gives me an upstream of 800Kbps):
altq on $ext_if priq bandwidth 700Kb queue { default, high, bittorrent,
vpn, pubservices }
queue default priority 3 priq(default)
queue high priority 7
queue bittorrent priority 0
queue vpn priority 4
queue pubservices priority 5
Then I create a queue with a bandwidth limit of 700Kbps. Does priq fully
ignore /all/ bandwidth limitations, or just not accept limitations on the
defined queues? The man page is a little vague on this point, and I'm not
sure if the bandwidth declaration defined by altq is adhered to or not (I
would think it is, but a quick test indicates it isn't).
Re: PF and PPTP
Thus spake Bruno Carnazzi ([EMAIL PROTECTED]) [10/05/06 01:37]: : My home PF NATing gateway route just one PPTP tunnel (for my laptop), : and I don't need special thing for it to work (GRE enabled via sysctl : and pf must pass GRE proto). Is there a special case when you have : multiple PPTP (GRE) tunnels that need proxying ? In theory, so long as there is only one given client on the LAN connecting to a given PPTP endpoint on the 'Net, I can handle it all using standard PF syntax. My problem is that I have two clients on the LAN that wish to connect to the same endpoint -- that, AFAIK, requires a proxy. - Damian
PF and PPTP
I find myself in a situation where I need to route a few PPTP tunnels through a NATing PF gateway. Because of the usage of GRE, I'm aware that I need to enable GRE via sysctl, and that I'll need to run the connections through a proxy. However, I'm having a hard time digging up a proxy I've got confidence in. I've tried pptpproxy: http://www.mgix.com/pptpproxy/ and frickin: http://sourceforge.net/projects/frickin/ But the former won't compile, and the latter doesn't instill a large amount of confidence in me (not to mention that it won't fork to the background). This is on a 3.9 system (or shortly before). How are other people handling multiple PPTP tunnels?
Re: Empty root password
Thus spake Jonathan Glaschke ([EMAIL PROTECTED]) [06/05/06 16:58]: : Think of somebody who burgles your house to steal your privat data. When : your computer asks him to enter the password he sure will try the well : known standard passwords like god, secret and sex. Or maybe : swordfish. But have you ever seen a film where someone was hacked by : just typing nothing but enter? I've done it many times. Most persons I know of give it a shot. In fact, there was an interview just posted with the guy who wormed his way into various Military computers, and he used blank passwords to do so. Movies != Real Life : He will try Marie5, then marie5, Marie_five and probably 5Mary : or Password Marie5 but he sure won't try . : : Try it, it works. *gak* I'll refrain from entering the typical debate and leave it at this: Whether or not it works depends *entirely* on your threat model. It sure as heck wouldn't work in mine.
Re: Via EPIA boards
Thus spake Timo Schoeler ([EMAIL PROTECTED]) [18/04/06 08:33]: : hm. somehow missing ECC et al. keeps me from deploying such systems on : a regular basis... even when they're 'only' x86. The systems, as much as I love 'em, are missing a few crucial 'features': 1) Proper RAID support 2) 3+ NIC support 3) 802.11 support 4) ECC memory Though you can have, with a PCI slot, RAID, *or* 3+ NIC, *or* 802.11, you can't get 'em all. It would also be nice if their DP line eventually hit the market...
Re: no internet with cable provider (videotron.ca)
Thus spake Peter ([EMAIL PROTECTED]) [21/03/06 01:46]: : Was the Win2k box connected first? Many (most?) Canadian cable : providers : cache the MAC address of the connected machine, and generally : speaking, : unplugging the cable modem for five minutes should re-set the cached : address : on their side. : : Otherwise... logs? : : I did hear of the caching feature so I unplugged the power but only for : about 10 seconds. Five minutes you say? Yeah, give it five minutes. That /should/ clear it out. (You may want to unplug power as well -- I've heard conflicting reports about that.) : I don't see any logs being generated except for it not being able to : find a dhcp server. On one occasion only did I see something to the : effect accepted blah length not same as blah length. Like what it : received was not the length of what is was supposed to receive. Strange. My guess is the caching -- it really is as simple as running 'dhclient interface'. You could also try calling them up to see if they cache the MAC or not, for how long if they do, and what it takes to flush the cache.
Re: restore question: is my dump hosed?
Thus spake Joachim Schipper ([EMAIL PROTECTED]) [20/03/06 00:34]: : Provided that you didn't do something strange when copying the dump, it : should - at least - be restorable on something that closely resembles : the platform it was taken on (FreeBSD-6.x). I believe the default FS type in FreeBSD 6.x (and even in 5.x) is UFS2. Which, as I understand it, only has the beginnings of a framework being developed for OpenBSD. And no, you can't restore a UFS2 dump on a UFS filesystem: $ restore -ivf root.ufs2.dmp Verify tape and initialize maps Tape block size is 32 restore: Tape is not a dump tape $ - Damian
ral(4) troubles
I've spent the past few days trying to get a wireless LAN working off my OpenBSD gateway. There's a few interfaces in there, and I just moved to a house that uses WiFi a fair bit. I thought I'd do the bridging right on the gateway, so there's one less device running. After a spate of other troubles, I've gotten most of it working. Part of that included upgrading to a -current as of this morning, from 3.7. I'm still having two ongoing problems, though: 1) DHCP. The DHCP server is running, and the logs show it handing out addresses. But the remote machine never gets the address. If I shift over to static addressing, it all Just Works. Note that this could be coincidence, because... 2) I have random periods where the WLAN just flat-out doesn't work. Like right now. When I try to ping out on ral0, this is what I get (note that 192.168.132.50 is a statically-assigned machine that is most definitely on the network): # ifconfig ral0 ral0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:12:17:85:9a:3b media: IEEE802.11 autoselect hostap (autoselect mode 11b hostap) status: active ieee80211: nwid WINSTON68 chan 11 bssid 00:12:17:85:9a:3b 100dBm inet 192.168.132.8 netmask 0xff00 broadcast 255.255.255.0 inet6 fe80::212:17ff:fe85:9a3b%ral0 prefixlen 64 scopeid 0x3 # ping -c 1 192.168.132.50 PING 192.168.132.50 (192.168.132.50): 56 data bytes ping: sendto: No buffer space available ping: wrote 192.168.132.50 64 chars, ret=-1 # I did a few quick Google searches, but came up with nothing. Can anyone shed any light on this? All other interfaces seem to be working just peachy, so this seems to be a ral(4)-specific issue and not a general networking (i.e. buffer space) issue. - Damian - dmesg: OpenBSD 3.7-current (GENERIC) #0: Mon Jun 13 14:04:19 EDT 2005 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: VIA Nehemiah (CentaurHauls 686-class) 1 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,CX8,SEP,MTRR,PGE,CMOV,PAT,MMX,FXSR,SSE cpu0: RNG AES real mem = 519614464 (507436K) avail mem = 467263488 (456312K) using 4278 buffers containing 26083328 bytes (25472K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(93) BIOS, date 11/25/02, BIOS32 rev. 0 @ 0xfb070 apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown apm0: flags 70102 dobusy 1 doidle 1 pcibios0 at bios0: rev 2.1 @ 0xf/0xdf44 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfded0/112 (5 entries) pcibios0: PCI Exclusive IRQs: 5 7 11 12 pcibios0: no compatible PCI ICU found pcibios0: Warning, unable to fix up PCI interrupt routing pcibios0: PCI bus #1 is the last bus bios0: ROM list: 0xc/0xfa00 0xd/0x800 0xd1000/0x1000 cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 VIA VT8623 PCI rev 0x00 ppb0 at pci0 dev 1 function 0 VIA VT8633 AGP rev 0x00 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 VIA CLE266 rev 0x03: aperture at 0xe000, size 0x1000 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) fxp0 at pci0 dev 8 function 0 Intel 82557 rev 0x05, i82558: irq 11, address 00:80:5f:f7:45:53 inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 0 fxp1 at pci0 dev 9 function 0 Intel 82557 rev 0x08, i82559: irq 12, address 00:d0:b7:23:65:34 inphy1 at fxp1 phy 1: i82555 10/100 PHY, rev. 4 ral0 at pci0 dev 10 function 0 Ralink RT2560 rev 0x01: irq 5, address 00:12:17:85:9a:3b ral0: MAC/BBP RT2560 (rev 0x04), RF RT2525 uhci0 at pci0 dev 16 function 0 VIA VT83C572 USB rev 0x80: irq 11 usb0 at uhci0: USB revision 1.0 uhub0 at usb0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1 at pci0 dev 16 function 1 VIA VT83C572 USB rev 0x80: irq 12 usb1 at uhci1: USB revision 1.0 uhub1 at usb1 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2 at pci0 dev 16 function 2 VIA VT83C572 USB rev 0x80: irq 5 usb2 at uhci2: USB revision 1.0 uhub2 at usb2 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0 at pci0 dev 16 function 3 VIA VT6202 USB rev 0x82: irq 7 usb3 at ehci0: USB revision 2.0 uhub3 at usb3 uhub3: VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered pcib0 at pci0 dev 17 function 0 VIA VT8235 ISA rev 0x00 pciide0 at pci0 dev 17 function 1 VIA VT82C571 IDE rev 0x06: ATA133, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: ST340014A wd0: 16-sector PIO, LBA48, 38166MB, 78165360 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: SONY, CD-RW CRX230E, QYS1 SCSI0 5/cdrom removable
Re: ral(4) troubles
Thus spake Damian Gerow ([EMAIL PROTECTED]) [13/06/05 20:55]: : house that uses WiFi a fair bit. I thought I'd do the bridging right on the Ack. 'bridging' is the wrong word; I'm definitely not bridging networks here.
Re: 3.7CDs arrived today...
Thus spake Ben Goren ([EMAIL PROTECTED]) [06/05/05 11:42]: : But do you complain to the record companies about their jewel cases? For the record, I've never, ever received a broken jewel case for a music CD that's been shipped in the mail (dozens of CDs). But from OpenBSD, it's been broken both times. However, I don't really give a rat's ass. It's broken. Whoop-de-doo. Do the CDs still work? Yep. So there's no reason to complain. Just setting the facts straight.
