Re: Possible sasyncd memory leak ?
W dniu 09.03.2019 o 12:43, Otto Moerbeek pisze: On Sat, Mar 09, 2019 at 12:10:34PM +0100, Michał Koc wrote: W dniu 09.03.2019 o 08:15, Otto Moerbeek pisze: On Fri, Mar 08, 2019 at 12:03:25PM +0100, Michał Koc wrote: Hi all, We have a triple redundant vpn gateway setup with sasyncd running and tons of tunnels, about 1000 flows. Looking at the graph of memory usage, you can clearly see that something is sucking up the memory. The graph can be viewed here: https://pasteboard.co/I4sjzQ8.jpg Looking at the ps, sasyncd shows huge memory consumption: USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND _isakmpd 33560 0.0 17.0 699264 708508 ?? S 26Feb19 6:58.81 /usr/sbin/sasyncd It only happens on the master node. Slaves do not show such a behavior. There is nothing about sasyncd in the logs. After sasyncd restart memory consumption is minimal, but tends to grow. Is it normal ? or am I missing something ? Best regards M.K. This is not normal. You could try to run with -vv to see if some error path is taken that triggers a leak. -Otto Should I look for something specific ? The log grows pretty fast and it looks like it could contain some security data which I wouldn't like to post online. The statistics of the log(about 2 hours) looks like this: carp_init: 1 config: 7 monitor_get_pfkey_snap: 4 monitor_loop: 1 net: 1 net_connect: 3 net_ctl: 4 net_disconnect_peer: 3 net_handle_messages: 2 net_queue: 91780 net_read: 10 net_send_messages: 39192 pfkey_send_flush: 4 pfkey_snapshot: 6832 timer_add: 19 timer_run: 18 Best regards M.K. Just the counts does not reveal anything. I did a quick audit of the memory allocation logic of sasyncd and did not spot an error. If you do not want to post the logs, you'll neeed to analyze them yourself. This requires matching the log lines to the code and tracking where stuff gets allocated and deallocated. Some digging could reveal the error. I used to run sasyncd, but I do no longer. Settig up a test env is quite some work I do not have time for. -Otto First of all, thank You for your time. I know it's one of the most valuable resource. We have done some analysis and we have found the problem. The problem is that the very master machine exists as a peer in it's config. The purpose of this is to make all of the config files to be as similar as possible for all of the members of the cluster. Removing it from peers fixes the problem. So there are three main roads we can follow: 1. Fix sasyncd to recognize self and handle it properly (a result) 2. It should be mentioned in manual, not to set self as a peer (an excuse) 3. We can change our internal config handling (no one else benefits) What would You recommend as a next step ? we will do much to follow road 1, but we might need help, eg. code review and some guidance to meet OpenBSD needs Furthermore if we follow road 1, is there any chance to get the reviewed, correct, accepted fix into the tree ? Best regards M.K.
Re: Possible sasyncd memory leak ?
W dniu 09.03.2019 o 08:15, Otto Moerbeek pisze: On Fri, Mar 08, 2019 at 12:03:25PM +0100, Michał Koc wrote: Hi all, We have a triple redundant vpn gateway setup with sasyncd running and tons of tunnels, about 1000 flows. Looking at the graph of memory usage, you can clearly see that something is sucking up the memory. The graph can be viewed here: https://pasteboard.co/I4sjzQ8.jpg Looking at the ps, sasyncd shows huge memory consumption: USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND _isakmpd 33560 0.0 17.0 699264 708508 ?? S 26Feb19 6:58.81 /usr/sbin/sasyncd It only happens on the master node. Slaves do not show such a behavior. There is nothing about sasyncd in the logs. After sasyncd restart memory consumption is minimal, but tends to grow. Is it normal ? or am I missing something ? Best regards M.K. This is not normal. You could try to run with -vv to see if some error path is taken that triggers a leak. -Otto Should I look for something specific ? The log grows pretty fast and it looks like it could contain some security data which I wouldn't like to post online. The statistics of the log(about 2 hours) looks like this: carp_init: 1 config: 7 monitor_get_pfkey_snap: 4 monitor_loop: 1 net: 1 net_connect: 3 net_ctl: 4 net_disconnect_peer: 3 net_handle_messages: 2 net_queue: 91780 net_read: 10 net_send_messages: 39192 pfkey_send_flush: 4 pfkey_snapshot: 6832 timer_add: 19 timer_run: 18 Best regards M.K.
Possible sasyncd memory leak ?
Hi all, We have a triple redundant vpn gateway setup with sasyncd running and tons of tunnels, about 1000 flows. Looking at the graph of memory usage, you can clearly see that something is sucking up the memory. The graph can be viewed here: https://pasteboard.co/I4sjzQ8.jpg Looking at the ps, sasyncd shows huge memory consumption: USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND _isakmpd 33560 0.0 17.0 699264 708508 ?? S 26Feb19 6:58.81 /usr/sbin/sasyncd It only happens on the master node. Slaves do not show such a behavior. There is nothing about sasyncd in the logs. After sasyncd restart memory consumption is minimal, but tends to grow. Is it normal ? or am I missing something ? Best regards M.K.
Re: Openbsd 6.1 and Current Console Freezes and lockup Proxmox PVE5.0
-- Wiadomość oryginalna -- *Temat: *Re: Openbsd 6.1 and Current Console Freezes and lockup Proxmox PVE5.0 *Nadawca: *Mike Larkin *Adresat: *Michał Koc *Kopia: *misc@openbsd.org *Data: *19.10.2017 08:36 On Fri, Oct 13, 2017 at 11:05:12PM +0200, Michał Koc wrote: On Thu, Oct 12, 2017 at 03:11:31PM -0700, Mike Larkin wrote: On Thu, Oct 12, 2017 at 10:36:42PM +0200, Michał Koc wrote: On Thu, Oct 12, 2017 at 01:23:36PM +0200, Michał Koc wrote: On Sun, Oct 08, 2017 at 11:59:52PM +0200, Oliver Marugg wrote: On 7 Oct 2017, at 22:01, Mike Larkin wrote: On Sat, Oct 07, 2017 at 02:19:58PM +0200, Oliver Marugg wrote: Just to add a 4th situation of hangs: Login via proxmox (pve)/kvm serial console (via noVNC), login successful: Vm guest in pve hangs, cpu usage at above 102%. Only way is to hard stop the Vm guest. -oliver sounds like a kvm bug. Ask your provider to investigate the host side when this happens. Thanks Mike, will do so. The proxmox guys have also the idea that it could be a bug in kvm hypervisor (which is the hypervisor part for proxmox) and will affect OpenBSD since 4.9, they wrote me in their public forum. As far as I understood they do not know what OpenBSD needs in kvm or what/where should be fixed in kvm run OpenBSD without that freezes. -oliver >From what I read, the cpu spins to 100%, which means somewhere on the host it's likely spinning also. Start with systrace/ptrace/ktrace/whatever on the host qemu-kvm and go from there... -ml Hi, it looks like the cpu process of kvm (CPU 0/KVM) is issuing 1500+ of ioctl(15, KVM_RUN, 0) per second while running OpenBSD 6.2 guest. What CPU profile is being presented to the OpenBSD guest? I've seen things like this happen when a vCPU is claimed to have monitor/mwait support, but the hypervisor implements those as NOPs, which just results in spinning like this. In short - try changing the type of CPU presented to the guest and see if that changes behaviour. At least then you'll have more data points to work with. -ml Okey, How would You disable monitor/mwait support in KVM to be presented to guest ? Well, monitor/mwait was just what I recall contributing to something *like* this. PS, IIRC qemu -cpu ? will show you a list of recognized cpuid flags, from which you can subtract off things you don't want. Hi Mike, Guest OpenBSD has those flags presented: cpu0: FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,APIC,MMX,HV,PERF What else should I switch off to get desired effect ? Those flags are completely bizarre. Compare to vmm(4): cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,ITSC,FSGSBASE,SMEP,ERMS >From what you said above, proxmox doesn't even expose PAE or PGE, which means it's emulating something like a 1990s era 80486 CPU. It doesn't even claim to support LONG, which means no 64 bit mode either. It sounds like whatever hypervisor you are using is completely messed up. You need to take this up with the proxmox or KVM people. -ml Hi Mike, after some fiddling around with various setting it looks like setting machine in hvm to q35 solves the problem at least partially. The host cpu consumption in below 2% and I cannot see any hangs. Even under heavy cpu load. BR M.K.
Re: Openbsd 6.1 and Current Console Freezes and lockup Proxmox PVE5.0
On Fri, Oct 13, 2017 at 11:05:12PM +0200, Michał Koc wrote: On Thu, Oct 12, 2017 at 03:11:31PM -0700, Mike Larkin wrote: On Thu, Oct 12, 2017 at 10:36:42PM +0200, Michał Koc wrote: On Thu, Oct 12, 2017 at 01:23:36PM +0200, Michał Koc wrote: On Sun, Oct 08, 2017 at 11:59:52PM +0200, Oliver Marugg wrote: On 7 Oct 2017, at 22:01, Mike Larkin wrote: On Sat, Oct 07, 2017 at 02:19:58PM +0200, Oliver Marugg wrote: Just to add a 4th situation of hangs: Login via proxmox (pve)/kvm serial console (via noVNC), login successful: Vm guest in pve hangs, cpu usage at above 102%. Only way is to hard stop the Vm guest. -oliver sounds like a kvm bug. Ask your provider to investigate the host side when this happens. Thanks Mike, will do so. The proxmox guys have also the idea that it could be a bug in kvm hypervisor (which is the hypervisor part for proxmox) and will affect OpenBSD since 4.9, they wrote me in their public forum. As far as I understood they do not know what OpenBSD needs in kvm or what/where should be fixed in kvm run OpenBSD without that freezes. -oliver >From what I read, the cpu spins to 100%, which means somewhere on the host it's likely spinning also. Start with systrace/ptrace/ktrace/whatever on the host qemu-kvm and go from there... -ml Hi, it looks like the cpu process of kvm (CPU 0/KVM) is issuing 1500+ of ioctl(15, KVM_RUN, 0) per second while running OpenBSD 6.2 guest. What CPU profile is being presented to the OpenBSD guest? I've seen things like this happen when a vCPU is claimed to have monitor/mwait support, but the hypervisor implements those as NOPs, which just results in spinning like this. In short - try changing the type of CPU presented to the guest and see if that changes behaviour. At least then you'll have more data points to work with. -ml Okey, How would You disable monitor/mwait support in KVM to be presented to guest ? Well, monitor/mwait was just what I recall contributing to something *like* this. PS, IIRC qemu -cpu ? will show you a list of recognized cpuid flags, from which you can subtract off things you don't want. Hi Mike, Guest OpenBSD has those flags presented: cpu0: FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,APIC,MMX,HV,PERF What else should I switch off to get desired effect ? Those flags are completely bizarre. Compare to vmm(4): cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,ITSC,FSGSBASE,SMEP,ERMS This is KVM on Debian 9 cripled to pentium BR M.K. >From what you said above, proxmox doesn't even expose PAE or PGE, which means it's emulating something like a 1990s era 80486 CPU. It doesn't even claim to support LONG, which means no 64 bit mode either. It sounds like whatever hypervisor you are using is completely messed up. You need to take this up with the proxmox or KVM people. -ml
Re: Openbsd 6.1 and Current Console Freezes and lockup Proxmox PVE5.0
On Thu, Oct 12, 2017 at 03:11:31PM -0700, Mike Larkin wrote: On Thu, Oct 12, 2017 at 10:36:42PM +0200, Michał Koc wrote: On Thu, Oct 12, 2017 at 01:23:36PM +0200, Michał Koc wrote: On Sun, Oct 08, 2017 at 11:59:52PM +0200, Oliver Marugg wrote: On 7 Oct 2017, at 22:01, Mike Larkin wrote: On Sat, Oct 07, 2017 at 02:19:58PM +0200, Oliver Marugg wrote: Just to add a 4th situation of hangs: Login via proxmox (pve)/kvm serial console (via noVNC), login successful: Vm guest in pve hangs, cpu usage at above 102%. Only way is to hard stop the Vm guest. -oliver sounds like a kvm bug. Ask your provider to investigate the host side when this happens. Thanks Mike, will do so. The proxmox guys have also the idea that it could be a bug in kvm hypervisor (which is the hypervisor part for proxmox) and will affect OpenBSD since 4.9, they wrote me in their public forum. As far as I understood they do not know what OpenBSD needs in kvm or what/where should be fixed in kvm run OpenBSD without that freezes. -oliver >From what I read, the cpu spins to 100%, which means somewhere on the host it's likely spinning also. Start with systrace/ptrace/ktrace/whatever on the host qemu-kvm and go from there... -ml Hi, it looks like the cpu process of kvm (CPU 0/KVM) is issuing 1500+ of ioctl(15, KVM_RUN, 0) per second while running OpenBSD 6.2 guest. What CPU profile is being presented to the OpenBSD guest? I've seen things like this happen when a vCPU is claimed to have monitor/mwait support, but the hypervisor implements those as NOPs, which just results in spinning like this. In short - try changing the type of CPU presented to the guest and see if that changes behaviour. At least then you'll have more data points to work with. -ml Okey, How would You disable monitor/mwait support in KVM to be presented to guest ? Well, monitor/mwait was just what I recall contributing to something *like* this. PS, IIRC qemu -cpu ? will show you a list of recognized cpuid flags, from which you can subtract off things you don't want. Hi Mike, Guest OpenBSD has those flags presented: cpu0: FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,APIC,MMX,HV,PERF What else should I switch off to get desired effect ? Best regards M.K. -ml If you can determine the guest %rip during each ioctl(vm_run) and give me a kernel or disassembly I may be able to see if it's something obvious. That, or describe a way I can repro this locally. I have a machine I could put linux on for an evening to test. -ml changing CPU to pentium or setting does not actually change anything in scope of host cpu utilization BR M.K. In case of linux guest the process issues about 15 of those ioctls per second. In any case I cannot make openbsd to starve KVM host cpu. OpenBSD uses at most(when idle) 7% of cpu. My versions: - OpenBSD 6.2 amd64 - KVM 2.8.1 BR M.K.
Re: Openbsd 6.1 and Current Console Freezes and lockup Proxmox PVE5.0
On Thu, Oct 12, 2017 at 01:23:36PM +0200, Michał Koc wrote: On Sun, Oct 08, 2017 at 11:59:52PM +0200, Oliver Marugg wrote: On 7 Oct 2017, at 22:01, Mike Larkin wrote: On Sat, Oct 07, 2017 at 02:19:58PM +0200, Oliver Marugg wrote: Just to add a 4th situation of hangs: Login via proxmox (pve)/kvm serial console (via noVNC), login successful: Vm guest in pve hangs, cpu usage at above 102%. Only way is to hard stop the Vm guest. -oliver sounds like a kvm bug. Ask your provider to investigate the host side when this happens. Thanks Mike, will do so. The proxmox guys have also the idea that it could be a bug in kvm hypervisor (which is the hypervisor part for proxmox) and will affect OpenBSD since 4.9, they wrote me in their public forum. As far as I understood they do not know what OpenBSD needs in kvm or what/where should be fixed in kvm run OpenBSD without that freezes. -oliver >From what I read, the cpu spins to 100%, which means somewhere on the host it's likely spinning also. Start with systrace/ptrace/ktrace/whatever on the host qemu-kvm and go from there... -ml Hi, it looks like the cpu process of kvm (CPU 0/KVM) is issuing 1500+ of ioctl(15, KVM_RUN, 0) per second while running OpenBSD 6.2 guest. What CPU profile is being presented to the OpenBSD guest? I've seen things like this happen when a vCPU is claimed to have monitor/mwait support, but the hypervisor implements those as NOPs, which just results in spinning like this. In short - try changing the type of CPU presented to the guest and see if that changes behaviour. At least then you'll have more data points to work with. -ml Okey, How would You disable monitor/mwait support in KVM to be presented to guest ? changing CPU to pentium or setting name='monitor'/> does not actually change anything in scope of host cpu utilization BR M.K. In case of linux guest the process issues about 15 of those ioctls per second. In any case I cannot make openbsd to starve KVM host cpu. OpenBSD uses at most(when idle) 7% of cpu. My versions: - OpenBSD 6.2 amd64 - KVM 2.8.1 BR M.K.
Re: Openbsd 6.1 and Current Console Freezes and lockup Proxmox PVE5.0
On Sun, Oct 08, 2017 at 11:59:52PM +0200, Oliver Marugg wrote: On 7 Oct 2017, at 22:01, Mike Larkin wrote: On Sat, Oct 07, 2017 at 02:19:58PM +0200, Oliver Marugg wrote: Just to add a 4th situation of hangs: Login via proxmox (pve)/kvm serial console (via noVNC), login successful: Vm guest in pve hangs, cpu usage at above 102%. Only way is to hard stop the Vm guest. -oliver sounds like a kvm bug. Ask your provider to investigate the host side when this happens. Thanks Mike, will do so. The proxmox guys have also the idea that it could be a bug in kvm hypervisor (which is the hypervisor part for proxmox) and will affect OpenBSD since 4.9, they wrote me in their public forum. As far as I understood they do not know what OpenBSD needs in kvm or what/where should be fixed in kvm run OpenBSD without that freezes. -oliver >From what I read, the cpu spins to 100%, which means somewhere on the host it's likely spinning also. Start with systrace/ptrace/ktrace/whatever on the host qemu-kvm and go from there... -ml Hi, it looks like the cpu process of kvm (CPU 0/KVM) is issuing 1500+ of ioctl(15, KVM_RUN, 0) per second while running OpenBSD 6.2 guest. In case of linux guest the process issues about 15 of those ioctls per second. In any case I cannot make openbsd to starve KVM host cpu. OpenBSD uses at most(when idle) 7% of cpu. My versions: - OpenBSD 6.2 amd64 - KVM 2.8.1 BR M.K.
Re: isakmpd dies quietly with over 100 tunnels
Hi Stuart, Rising openfiles-cur does not change anything. Best Regards M.K. -- Wiadomość oryginalna -- *Temat: *Re: isakmpd dies quietly with over 100 tunnels *Nadawca: *Stuart Henderson *Adresat: *misc@openbsd.org *Data: *30.05.2017 11:55 On 2017-05-28, Michał Koc wrote: Hi all, I'm running 6.0/amd64 inside KVM/Quemu with over 100 ipsec tunnels. Everything was running just fine when the number of tunnels was lower. But as we have been setting up more and more tunnels we suddenly run on problems. The isakmpd deaemon keeps dying quietly. Probably I'm running out of something, but I need some help to find out what it is and how to monitor it and tweak. Does it help to raise openfiles-cur for the daemon class in /etc/login.conf?
Re: isakmpd dies quietly with over 100 tunnels
Hi All, the trace is below, give mi a notice if anything else is needed: Program received signal SIGSEGV, Segmentation fault. [Switching to thread 162385] conf_get_str (section=0xa8735b03f80 ' 0xa8735b04000 out of bounds>, tag=0xa8459272809 "Phase") at /usr/src/sbin/isakmpd/conf.c:94 94 /usr/src/sbin/isakmpd/conf.c: No such file or directory. in /usr/src/sbin/isakmpd/conf.c Current language: auto; currently c (gdb) bt #0 conf_get_str (section=0xa8735b03f80 ' 0xa8735b04000 out of bounds>, tag=0xa8459272809 "Phase") at /usr/src/sbin/isakmpd/conf.c:94 #1 0x0a84590293b4 in pf_key_v2_remove_conf (section=0xa8735b03f80 ' ) at /usr/src/sbin/isakmpd/pf_key_v2.c:1905 #2 0x0a845902956a in pf_key_v2_stayalive (exchange=0xa86a6f44200, vconn=0xa8735b03f80, fail=1) at /usr/src/sbin/isakmpd/pf_key_v2.c:2131 #3 0x0a8459005bdf in exchange_run_finalizations (exchange=0xa86a6f44200, arg=0xa86c2fa4f80, fail=1) at /usr/src/sbin/isakmpd/exchange.c:653 #4 0x0a8459005bd2 in exchange_run_finalizations (exchange=0xa86a6f44200, arg=0xa86d33c9700, fail=1) at /usr/src/sbin/isakmpd/exchange.c:652 #5 0x0a8459005bd2 in exchange_run_finalizations (exchange=0xa86a6f44200, arg=0xa86a3fb3580, fail=1) at /usr/src/sbin/isakmpd/exchange.c:652 #6 0x0a8459005bd2 in exchange_run_finalizations (exchange=0xa86a6f44200, arg=0xa86f3332820, fail=1) at /usr/src/sbin/isakmpd/exchange.c:652 #7 0x0a8459005bd2 in exchange_run_finalizations (exchange=0xa86a6f44200, arg=0xa86d33c99a0, fail=1) at /usr/src/sbin/isakmpd/exchange.c:652 #8 0x0a8459005bd2 in exchange_run_finalizations (exchange=0xa86a6f44200, arg=0xa86f3332f20, fail=1) at /usr/src/sbin/isakmpd/exchange.c:652 #9 0x0a84590069e0 in exchange_free_aux (v_exch=Variable "v_exch" is not available. ) at /usr/src/sbin/isakmpd/exchange.c:1230 #10 0x0a845901e8f0 in timer_handle_expirations () at /usr/src/sbin/isakmpd/timer.c:76 #11 0x0a8459015b1b in main (argc=Variable "argc" is not available. ) at /usr/src/sbin/isakmpd/isakmpd.c:533 (gdb) Best regards M.K. -- Wiadomość oryginalna -- *Temat: *Re: isakmpd dies quietly with over 100 tunnels *Nadawca: *Michał Koc *Adresat: *Alexis VACHETTE , Theo de Raadt , Florian Ermisch *Kopia: *misc@openbsd.org *Data: *29.05.2017 11:39 Hi all, we are setting up a test environment, will be back soon with the traces. Best Regards M.K. -- Wiadomość oryginalna -- *Temat: *Re: isakmpd dies quietly with over 100 tunnels *Nadawca: *Alexis VACHETTE *Adresat: *Theo de Raadt , Florian Ermisch *Kopia: *, Michał Koc *Data: *29.05.2017 11:31 I didn't think it was isakmpd related back then. Maybe a configuration issue on my end or the partner's. But sure we need to post traces. Nonetheless OpenBSD is an amazing piece of software, so thank you ! Regards, Alexis. On 29/05/2017 11:14, Theo de Raadt wrote: Great thing is you all have source code, and can run the same debuggers live in your key-happy situations, and then generate traces to expose the problem so that someone can help you. But, yet, that doesn't happen. Strange isn't it? -- Michał Koc
Re: isakmpd dies quietly with over 100 tunnels
Hi all, we are setting up a test environment, will be back soon with the traces. Best Regards M.K. -- Wiadomość oryginalna -- *Temat: *Re: isakmpd dies quietly with over 100 tunnels *Nadawca: *Alexis VACHETTE *Adresat: *Theo de Raadt , Florian Ermisch *Kopia: *, Michał Koc *Data: *29.05.2017 11:31 I didn't think it was isakmpd related back then. Maybe a configuration issue on my end or the partner's. But sure we need to post traces. Nonetheless OpenBSD is an amazing piece of software, so thank you ! Regards, Alexis. On 29/05/2017 11:14, Theo de Raadt wrote: Great thing is you all have source code, and can run the same debuggers live in your key-happy situations, and then generate traces to expose the problem so that someone can help you. But, yet, that doesn't happen. Strange isn't it? --
isakmpd dies quietly with over 100 tunnels
Hi all, I'm running 6.0/amd64 inside KVM/Quemu with over 100 ipsec tunnels. Everything was running just fine when the number of tunnels was lower. But as we have been setting up more and more tunnels we suddenly run on problems. The isakmpd deaemon keeps dying quietly. Probably I'm running out of something, but I need some help to find out what it is and how to monitor it and tweak. Thank You in advance. Best Regards M.K. root@vgate0:/root# netstat -m 215 mbufs in use: 163 mbufs allocated to data 46 mbufs allocated to packet headers 6 mbufs allocated to socket names and addresses 160/920/6144 mbuf 2048 byte clusters in use (current/peak/max) 0/8/6144 mbuf 4096 byte clusters in use (current/peak/max) 0/8/6144 mbuf 8192 byte clusters in use (current/peak/max) 0/14/6146 mbuf 9216 byte clusters in use (current/peak/max) 0/10/6150 mbuf 12288 byte clusters in use (current/peak/max) 0/8/6144 mbuf 16384 byte clusters in use (current/peak/max) 0/8/6144 mbuf 65536 byte clusters in use (current/peak/max) 2760 Kbytes allocated to network (13% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines Sample tail of the log: When I run "isakmpd -K -d -DA=10": 142043.246192 Sdep 10 pf_key_v2_set_spi: satype 2 dst xxx.xxx.xxx.xxx SPI 0x42f03e5d 142043.246209 Timr 10 timer_add_event: event sa_soft_expire(0x1fb9d0bdf400) added before sa_soft_expire(0x1fb9c8f05400), expiration in 25056s 142043.246223 Timr 10 timer_add_event: event sa_hard_expire(0x1fb9d0bdf400) added before sa_soft_expire(0x1fb9dd458200), expiration in 28800s 142043.246326 Sdep 10 pf_key_v2_set_spi: satype 2 dst xxx.xxx.xxx.xxx SPI 0x3ffa5955 142043.268229 Default responder_recv_HASH_SA_NONCE: KEY_EXCH payload without a group desc. attribute 142043.268250 Default dropped message from xxx.xxx.xxx.xxx port 500 due to notification type NO_PROPOSAL_CHOSEN 142043.268281 Timr 10 timer_add_event: event exchange_free_aux(0x1fb9a5336400) added before sa_soft_expire(0x1fba0d6a2a00), expiration in 120s 142043.268289 Exch 10 exchange_establish_p2: 0x1fb9a5336400 policy initiator phase 2 doi 1 exchange 5 step 0 142043.268295 Exch 10 exchange_establish_p2: icookie 8c58f4e7f8269ed3 rcookie 0fe2d7657125a339 142043.268301 Exch 10 exchange_establish_p2: msgid de2c5cc3 sa_list 142043.269079 Timr 10 timer_add_event: event message_send_expire(0x1fb994136900) added before connection_checker(0x1fb9b2646280), expiration in 7s 142043.269614 Exch 10 exchange_finalize: 0x1fb9a5336400 policy> policy initiator phase 2 doi 1 exchange 5 step 1 142043.269630 Exch 10 exchange_finalize: icookie 8c58f4e7f8269ed3 rcookie 0fe2d7657125a339 142043.269637 Exch 10 exchange_finalize: msgid de2c5cc3 sa_list 142043.269653 Timr 10 timer_remove_event: removing event exchange_free_aux(0x1fb9a5336400) 142043.289465 Timr 10 timer_remove_event: removing event message_send_expire(0x1fb994136900) 142043.289513 Exch 10 exchange_finalize: 0x1fb972b59400 from-xxx.xxx.xxx.xxx/24-to-xxx.xxx.xxx.xxx/24 policy responder phase 2 doi 1 exchange 32 step 2 142043.289521 Exch 10 exchange_finalize: icookie 8c58f4e7f8269ed3 rcookie 0fe2d7657125a339 142043.289528 Exch 10 exchange_finalize: msgid de079ef6 sa_list 0x1fb9dd458800 0x1fb985d09e00 142043.289578 Sdep 10 pf_key_v2_set_spi: satype 2 dst xxx.xxx.xxx.xxx SPI 0xe5d04953 142043.289594 Timr 10 timer_add_event: event sa_soft_expire(0x1fb9dd458800) added before sa_soft_expire(0x1fba1d81de00), expiration in 3279s 142043.289608 Timr 10 timer_add_event: event sa_hard_expire(0x1fb9dd458800) added before sa_soft_expire(0x1fba2c980800), expiration in 3600s 142043.289710 Sdep 10 pf_key_v2_set_spi: satype 2 dst xxx.xxx.xxx.xxx SPI 0x4d895568 root@vgate0:/root# OpenBSD 6.0-stable (GENERIC.MP) #0: Sat Feb 4 21:55:17 CET 2017 root@amd64.vcomp:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1056956416 (1007MB) avail mem = 1020506112 (973MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf1dc0 (11 entries) bios0: vendor Bochs version "Bochs" date 01/01/2011 bios0: Bochs Bochs acpi0 at bios0: rev 0 acpi0: sleep states S3 S4 S5 acpi0: tables DSDT FACP SSDT APIC HPET acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: QEMU Virtual CPU version 2.1.2, 3492.32 MHz cpu0: FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,POPCNT,HV,NXE,LONG,LAHF,ABM cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 1000MHz cpu1 at mainbus0: apid 1 (application process
Re: what happened to the encap address_family
Tank You for the authoritative answer,
so we will have to get used to the, let say new, ipsecctl output.
Also good to know that monitoring tools have to look some elsewhere to
see VPN and routing is up :)
Instead of waking 12 people at 1:00 AM :)
Anyway, in my opinion this king of exercises are healthy :)
Than we can have a beer at 8:00 AM and have working "day" behind
Good news that OpenBSD is following best practices - as always :)
Seriously - good job as always - users have to adapt -> evolution or death
Best regards and good luck
Micha³ Koc
-- Wiadomo¶æ oryginalna --
*Temat: *Re: what happened to the encap address_family
*Nadawca: *Theo de Raadt
*Adresat: *Micha³ Koc
*Kopia: *Fred , Boris Goldberg
, misc@openbsd.org
*Data: *2015-05-16 01:04
>> Let me repeat myself: anyone CAPABLE to answer (and understand the
>> question) ?
>>
>> I really admire and appreciate your (misc) commitment.
> netstat was largely rewritten to not use kvm snooping. It now
> only gets information from the kernel via sysctl. The result is
> that it does not race against the kernel in uncomfortable ways,
> shows atomic data, and loses a setgid bit.
>
> A few pieces of functionality went away. I believe ipsecctl will
> show you what you need.
>
>
>
--
Micha³ Koc
Head of System Development
Mobile: +48 886 566 357
E-mail: m...@dclog.pl
WWW:http://www.dclog.pl/
perl -e
'for($i=0;$i<16;){push@b,"\e[".($i>>3).";".($i++%8+30)."m#"}for($C=15;--$C>-15;print"\n"){for($c=-51;++$c<25;print$b[--$k%16]){for($k=$z=$Z=0;$t=$z**2-$Z**2+$c/25,$Z=2*$z*$Z+$C/10,++$k<113&&$t**2+$Z**2<=10;$z=$t){}}}print"\e[0m"'
*DCLOG Sp. z o.o.*
03-934 Warszawa, ul. W±chocka 1M
NIP 1132851126, REGON 145879741
KRS 401936 S±d Rejonowy dla m. st. Warszawa, XIII Wydz. Gospodarczy
Kapita³ zak³adowy spó³ki: 75.000 z³ op³acony w ca³o¶ci
Informacja ta jest poufna i mo¿e zawieraæ materia³y objête prawem
autorskim. Ostrzegamy, i¿ kopiowanie lub dystrybucja tej wiadomo¶ci s±
dozwolone tylko przez adresata. Je¶li nie s± Pañstwo adresatami tej
informacji, prosimy o szybkie poinformowanie o tym nadawcy poczt±
elektroniczn± lub telefonicznie pod nr +48 886 566 357 i skasowanie
wiadomo¶ci.
Re: what happened to the encap address_family
Hi misc,
Let me repeat myself: anyone CAPABLE to answer (and understand the
question) ?
I really admire and appreciate your (misc) commitment.
Best regards
MichaÅ Koc
-- WiadomoÅÄ oryginalna --
*Temat: *Re: what happened to the encap address_family
*Nadawca: *Fred
*Adresat: *MichaÅ Koc , Boris Goldberg
, misc@openbsd.org
*Data: *2015-05-16 00:25
> On 05/15/15 21:13, MichaÅ Koc wrote:
>> Hello misc,
>>
>> anyone capable to answer ?
>>
>> Best regards
>> MichaÃ
â Koc
>>
>> -- WiadomoÃ
âºÃâ¡ oryginalna --
>> *Temat: *what happened to the encap address_family
>> *Nadawca: *Boris Goldberg
>> *Adresat: *misc@openbsd.org
>> *Data: *2015-05-14 18:14
>>> Hello misc,
>>>
>>>The encap address_family isn't in the netstat man page anymore
>>> (BTW, there
>>> is no "5.7" section at www.openbsd.org/cgi-bin/man.cgi, just
>>> "current").
>>> The "netstat -nrf encap" gives an error, the "netstat -nr" doesn't
>>> have the
>>> "Encap" section.
>>> Don't see anything about "netstat" nor about "encap" at
>>> http://www.openbsd.org/57.html, the google also didn't help.
>>>
>>> How do I check VPN related routing besides "ipsecctl -s flow"
>>> (which
>>> isn't exactly the strait way) ?
>>>
>>
>>
>
> do you mean:
>
> man 4 enc
>
> as in:
> port:fred ~> ifconfig enc
> enc0: flags=0<>
> priority: 0
> groups: enc
> status: active
>
>
>
--
MichaÅ Koc
Head of System Development
Mobile: +48 886 566 357
E-mail: m...@dclog.pl
WWW:http://www.dclog.pl/
perl -e
'for($i=0;$i<16;){push@b,"\e[".($i>>3).";".($i++%8+30)."m#"}for($C=15;--$C>-15;print"\n"){for($c=-51;++$c<25;print$b[--$k%16]){for($k=$z=$Z=0;$t=$z**2-$Z**2+$c/25,$Z=2*$z*$Z+$C/10,++$k<113&&$t**2+$Z**2<=10;$z=$t){}}}print"\e[0m"'
*DCLOG Sp. z o.o.*
03-934 Warszawa, ul. WÄ
chocka 1M
NIP 1132851126, REGON 145879741
KRS 401936 SÄ
d Rejonowy dla m. st. Warszawa, XIII Wydz. Gospodarczy
KapitaÅ zakÅadowy spóÅki: 75.000 zÅ opÅacony w caÅoÅci
Informacja ta jest poufna i może zawieraÄ materiaÅy objÄte prawem
autorskim. Ostrzegamy, iż kopiowanie lub dystrybucja tej wiadomoÅci sÄ
dozwolone tylko przez adresata. JeÅli nie sÄ
PaÅstwo adresatami tej
informacji, prosimy o szybkie poinformowanie o tym nadawcy pocztÄ
elektronicznÄ
lub telefonicznie pod nr +48 886 566 357 i skasowanie
wiadomoÅci.
Re: what happened to the encap address_family
Hello misc,
anyone capable to answer ?
Best regards
MichaÅ Koc
-- WiadomoÅÄ oryginalna --
*Temat: *what happened to the encap address_family
*Nadawca: *Boris Goldberg
*Adresat: *misc@openbsd.org
*Data: *2015-05-14 18:14
> Hello misc,
>
> The encap address_family isn't in the netstat man page anymore (BTW, there
> is no "5.7" section at www.openbsd.org/cgi-bin/man.cgi, just "current").
> The "netstat -nrf encap" gives an error, the "netstat -nr" doesn't have the
> "Encap" section.
>Don't see anything about "netstat" nor about "encap" at
> http://www.openbsd.org/57.html, the google also didn't help.
>
>How do I check VPN related routing besides "ipsecctl -s flow" (which
> isn't exactly the strait way) ?
>
--
MichaÅ Koc
Head of System Development
Mobile: +48 886 566 357
E-mail: m...@dclog.pl
WWW:http://www.dclog.pl/
perl -e
'for($i=0;$i<16;){push@b,"\e[".($i>>3).";".($i++%8+30)."m#"}for($C=15;--$C>-15;print"\n"){for($c=-51;++$c<25;print$b[--$k%16]){for($k=$z=$Z=0;$t=$z**2-$Z**2+$c/25,$Z=2*$z*$Z+$C/10,++$k<113&&$t**2+$Z**2<=10;$z=$t){}}}print"\e[0m"'
*DCLOG Sp. z o.o.*
03-934 Warszawa, ul. WÄ
chocka 1M
NIP 1132851126, REGON 145879741
KRS 401936 SÄ
d Rejonowy dla m. st. Warszawa, XIII Wydz. Gospodarczy
KapitaÅ zakÅadowy spóÅki: 75.000 zÅ opÅacony w caÅoÅci
Informacja ta jest poufna i może zawieraÄ materiaÅy objÄte prawem
autorskim. Ostrzegamy, iż kopiowanie lub dystrybucja tej wiadomoÅci sÄ
dozwolone tylko przez adresata. JeÅli nie sÄ
PaÅstwo adresatami tej
informacji, prosimy o szybkie poinformowanie o tym nadawcy pocztÄ
elektronicznÄ
lub telefonicznie pod nr +48 886 566 357 i skasowanie
wiadomoÅci.
Re: Time keeping problem
On Mon, Dec 01, 2014 at 17:33, MichaÅ Koc wrote: >> Hi All, >> >> I've got a OpenBSD installation on Microsoft Hyper-V, and there is a >> strange issue related to time. >> Actually the clock seems to be running fine, but all of the sleep >> operations expire 2 times too fast. >> cpu0 at mainbus0: apid 0 (boot processor) >> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges >> cpu0: apic clock running at 105MHz > The clock that determines how long a second is the apic clock, which > we attempt to measure at boot time. However, sometimes the reading is > done wrong which usually results in a multple of the actual frequency. > Actually, it usually results in clocks running at 1/2 or 1/3 speed, > not double speed. But it's the same problem. Your apic clock is > apparently really running at 200MHz. > > There was a fix made to the code quite some time ago which resolved > the issue on real hardware. I haven't seen it since. But Hyper-V is > obviously different. > > There is no fix or change you can make to change the frequency once > determined, but maybe if Hyper-V has some setting for "optimized clock > ticks" or whatever, you can fiddle with it. > > > Hi Ted, thank You for a quick response. Unfortunately I'm not in position to do any changes in the settings. But I've set this value manually in lapic_gettick, and the machine seems to be running fine for now. I know that's not a best possible solution :) Best regards -- MichaÅ Koc
Time keeping problem
Hi All,
I've got a OpenBSD installation on Microsoft Hyper-V, and there is a
strange issue related to time.
Actually the clock seems to be running fine, but all of the sleep
operations expire 2 times too fast.
I.e.:
# date; sleep 60; date
Mon Dec 1 18:23:18 CET 2014
Mon Dec 1 18:23:48 CET 2014
Counting the time with mechanical timer shows "exactly" 30 seconds
instead of 60.
Also other tools, like ping are giving strange time related output,
twice a second.
Disabling ACPI does not help.
Changing kern.timecounter.hardware does not help.
The described behavior happens on 5.5, 5.6, i386 and amd64 and all of
the combinations.
Please help.
Further details:
kern.timecounter.tick=1
kern.timecounter.timestepwarnings=0
kern.timecounter.hardware=acpitimer0
kern.timecounter.choice=i8254(0) acpitimer0(1000) dummy(-100)
5.5 AMD64:
OpenBSD 5.5 (GENERIC) #276: Wed Mar 5 09:57:06 MST 2014
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz ("GenuineIntel"
686-class) 1.41 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,NXE,LONG,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,LAHF
real mem = 2146922496 (2047MB)
avail mem = 2099552256 (2002MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 05/23/12, SMBIOS rev. 2.3 @
0xf8ec0 (216 entries)
bios0: vendor American Megatrends Inc. version "090006" date 05/23/2012
bios0: Microsoft Corporation Virtual Machine
acpi0 at bios0: rev 0
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP WAET SLIC OEM0 SRAT APIC OEMB
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 105MHz
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
ioapic0: misconfigured as apic 1, remapped to apid 0
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0
bios0: ROM list: 0xc/0xc000! 0xcc000/0x800
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82443BX" rev 0x03
piixpcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x01
pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 128-sector PIO, LBA48, 40960MB, 83886080 sectors
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: ATAPI 5/cdrom
removable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
piixpm0 at pci0 dev 7 function 3 "Intel 82371AB Power" rev 0x02: SMBus
disabled
vga1 at pci0 dev 8 function 0 vendor "Microsoft", unknown product 0x5353
rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
de0 at pci0 dev 10 function 0 "DEC 21140" rev 0x20, 21140A pass 2.0:
apic 0 int 11, address
isa0 at piixpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
fd1 at fdc0 drive 1: density unknown
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on wd0a (fbd6bb77ca59c7f5.a) swap on wd0b dump on wd0b
acpi0: PM1 stuck (en 0x101 st 0x1), clearing
5.6 i386:
OpenBSD 5.6-stable (GENERIC) #0: Tue Nov 18 00:41:20 CET 2014
r...@i386.comp.dclog.pl:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz ("GenuineIntel"
686-class) 1.41 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,NXE,LONG,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,LAHF,FSGSBASE,SMEP,ERMS
real mem = 2146922496 (2047MB)
avail mem = 2099408896 (2002MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 05/23/12, SMBIOS rev. 2.3 @
0xf8ec0 (216 entries)
bios0: vendor American Megatrends Inc. version "090006" date 05/23/2012
bios0: Microsoft Corporation Virtual Machine
acpi at bios0 function 0x0 not configured
mpbios0 at bios0: Intel MP Specification 1.4
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 100MHz
mpbios0: bus 0 is type PCI
mpbios0: bus 1 is type ISA
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
i
Re: Freeze with Western Digital Caviar Green HDD
Can't say anything bad about WD Raid Edition drives. Currently I've go over 100 of them without any problems. Thou I've found some of them generating small number of Raw Read Error Rate, but only in 2TB model WDC WD2002FYPS. I've got much worse experience with Seagate My policy is to replace them every 2 years, faulty or not. regards M.K. W dniu 2010-12-15 18:00, Kevin Chadwick pisze: On Sat, 11 Dec 2010 01:23:36 +0100 roberth wrote: sata disk got really crappy since they hit 2TB. (or 1.5TB in Seagates case.) Hitachi have said that some issues were hit when they moved to 2tbs but a new generation of their drives will solve these problems starting with a 3tb version. I've just bought a 2tb WD too, luckily it will only be used for cctv backup from time to time.
Re: re(4)/atom freezes (was Re: [SOLVED] Re: OpenBSD 4.8 freezes on certain activities)
Well,
it looks like the patch did the trick :) thanks a lot :)
shouldn't it get to Tag OpenBSD_4_8, so everyone can benefit ?
correct me if I'm wrong, but re(4) seems to be a popular interface
best regards
M.K.
W dniu 2010-11-12 22:32, Stuart Henderson pisze:
[moving from misc to tech@, reply-to set]
On 2010-11-12, Stuart Henderson wrote:
On 2010-11-11, Micha?? Koc wrote:
Yes, it does.
regards
M.K.
W dniu 2010-11-11 10:53, Stuart Henderson pisze:
On 2010-11-10, Micha?? Koc wrote:
Hi All,
migrating from re to em solved the network problem
With the re(4), does the system recover if you leave it for a couple of minutes?
Interesting... I've seen similar symptoms on my netbook a few times
recently (during p2k10) which haven't happened before, and I haven't
seen it since I got back, the only difference being that I'm mostly
using ral(4) at home and was using re(4) there.
In my case: system just appears to freeze, no response to numlock
etc, cannot enter DDB (typing blind as I'm generally in X and
the machine has no serial port, but no response to ctrl-alt-esc
followed by boot r).
When I get time to look at it I'll try and reproduce it with GENERIC
rather than GENERIC.MP (this is my main machine though and I haven't
had much chance to use it to investigate this yet..) and dig through
my old kernel archive..
IIRC, netblast (in the netrate package) was good at triggering this
(it's the fastest packet source I know of that runs on OpenBSD; about
270Kpps UDP from an opteron 146 + bge running one instance of it).
okay... at first I was having problems reproducing this, until
I hit the machine with a large bunch of *incoming* packets by
running netblast on a faster box.
to repeat this I am doing:
- boot the re(4) box, configure IP addresses, systat mbuf .1
- on a faster machine, pkg_add netrate, netblast $netbook_ip_addr 5 10
(5=packet size, 10=run for 10 seconds)
the following diff reverts MCLGETI for re(4) which stops the
freezes for me. unless there are serious objections or a fix,
I would like to commit this tomorrow as it's better than what
is in-tree.
with MCLGETI and 250Kpps the freeze is almost instant; machine
recovers some time (usually<1min) when traffic is removed.
without MCLGETI at 250Kpps it is obvious that there is starvation
almost instantly (especially with the fast systat updates), but the
machine keeps running normally.
(at first I forgot to disable IPsec - the IPsec gateway for my
netbook is an alix, so I was also able to discover that netblast
is rather good at triggering the vr(4) hangs there which require
ifconfig down+up to recover from - I guess I will be building a
non-MCLGETI vr(4) sometime soon too).
Index: re.c
===
RCS file: /cvs/src/sys/dev/ic/re.c,v
retrieving revision 1.129
diff -u -p -r1.129 re.c
--- re.c5 Oct 2010 08:57:34 - 1.129
+++ re.c12 Nov 2010 18:39:50 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: re.c,v 1.129 2010/10/05 08:57:34 mikeb Exp $ */
+/* $OpenBSD: re.c,v 1.112 2009/07/18 13:21:32 sthen Exp $ */
/*$FreeBSD: if_re.c,v 1.31 2004/09/04 07:54:05 ru Exp $ */
/*
* Copyright (c) 1997, 1998-2003
@@ -162,9 +162,8 @@ static inline void re_set_bufaddr(struct
int re_encap(struct rl_softc *, struct mbuf *, int *);
-intre_newbuf(struct rl_softc *);
+intre_newbuf(struct rl_softc *, int, struct mbuf *);
int re_rx_list_init(struct rl_softc *);
-void re_rx_list_fill(struct rl_softc *);
int re_tx_list_init(struct rl_softc *);
int re_rxeof(struct rl_softc *);
int re_txeof(struct rl_softc *);
@@ -1109,8 +1108,6 @@ re_attach(struct rl_softc *sc, const cha
IFQ_SET_MAXLEN(&ifp->if_snd, RL_TX_QLEN);
IFQ_SET_READY(&ifp->if_snd);
- m_clsetwms(ifp, MCLBYTES, 2, RL_RX_DESC_CNT);
-
ifp->if_capabilities = IFCAP_VLAN_MTU | IFCAP_CSUM_IPv4 |
IFCAP_CSUM_TCPv4 | IFCAP_CSUM_UDPv4;
@@ -1215,18 +1212,28 @@ fail_0:
int
-re_newbuf(struct rl_softc *sc)
+re_newbuf(struct rl_softc *sc, int idx, struct mbuf *m)
{
- struct mbuf *m;
+ struct mbuf *n = NULL;
bus_dmamap_tmap;
struct rl_desc *d;
struct rl_rxsoft *rxs;
u_int32_t cmdstat;
- int error, idx;
+ int error;
- m = MCLGETI(NULL, M_DONTWAIT,&sc->sc_arpcom.ac_if, MCLBYTES);
- if (!m)
- return (ENOBUFS);
+ if (m == NULL) {
+ MGETHDR(n, M_DONTWAIT, MT_DATA);
+ if (n == NULL)
+ return (ENOBUFS);
+
+ MCLGET(n, M_DONTWAIT);
+ if (!(n->m_flags& M_EXT)) {
+ m_freem(n);
+ return (ENOBUFS);
+ }
+ m = n;
+ } else
+ m->m_data = m->m_ext.ext_buf;
/*
* Initialize mbuf length fields and fixup
@@ -1236,15 +1243,13 @@ re_newb
Re: re(4)/atom freezes (was Re: [SOLVED] Re: OpenBSD 4.8 freezes on certain activities)
Hello,
wait a second, I'll be able to test tomorrow, will give the result instantly
best regards
M.K.
W dniu 2010-11-12 22:32, Stuart Henderson pisze:
> [moving from misc to tech@, reply-to set]
> On 2010-11-12, Stuart Henderson wrote:
>> On 2010-11-11, Micha?? Koc wrote:
>>> Yes, it does.
>>>
>>> regards
>>> M.K.
>>>
>>> W dniu 2010-11-11 10:53, Stuart Henderson pisze:
On 2010-11-10, Micha?? Koc wrote:
> Hi All,
>
> migrating from re to em solved the network problem
With the re(4), does the system recover if you leave it for a couple of
minutes?
>>>
>> Interesting... I've seen similar symptoms on my netbook a few times
>> recently (during p2k10) which haven't happened before, and I haven't
>> seen it since I got back, the only difference being that I'm mostly
>> using ral(4) at home and was using re(4) there.
>>
>> In my case: system just appears to freeze, no response to numlock
>> etc, cannot enter DDB (typing blind as I'm generally in X and
>> the machine has no serial port, but no response to ctrl-alt-esc
>> followed by boot r).
>>
>> When I get time to look at it I'll try and reproduce it with GENERIC
>> rather than GENERIC.MP (this is my main machine though and I haven't
>> had much chance to use it to investigate this yet..) and dig through
>> my old kernel archive..
>>
>> IIRC, netblast (in the netrate package) was good at triggering this
>> (it's the fastest packet source I know of that runs on OpenBSD; about
>> 270Kpps UDP from an opteron 146 + bge running one instance of it).
>
> okay... at first I was having problems reproducing this, until
> I hit the machine with a large bunch of *incoming* packets by
> running netblast on a faster box.
>
> to repeat this I am doing:
>
> - boot the re(4) box, configure IP addresses, systat mbuf .1
> - on a faster machine, pkg_add netrate, netblast $netbook_ip_addr 5 10
> (5=packet size, 10=run for 10 seconds)
>
> the following diff reverts MCLGETI for re(4) which stops the
> freezes for me. unless there are serious objections or a fix,
> I would like to commit this tomorrow as it's better than what
> is in-tree.
>
> with MCLGETI and 250Kpps the freeze is almost instant; machine
> recovers some time (usually<1min) when traffic is removed.
>
> without MCLGETI at 250Kpps it is obvious that there is starvation
> almost instantly (especially with the fast systat updates), but the
> machine keeps running normally.
>
> (at first I forgot to disable IPsec - the IPsec gateway for my
> netbook is an alix, so I was also able to discover that netblast
> is rather good at triggering the vr(4) hangs there which require
> ifconfig down+up to recover from - I guess I will be building a
> non-MCLGETI vr(4) sometime soon too).
>
>
> Index: re.c
> ===
> RCS file: /cvs/src/sys/dev/ic/re.c,v
> retrieving revision 1.129
> diff -u -p -r1.129 re.c
> --- re.c 5 Oct 2010 08:57:34 - 1.129
> +++ re.c 12 Nov 2010 18:39:50 -
> @@ -1,4 +1,4 @@
> -/* $OpenBSD: re.c,v 1.129 2010/10/05 08:57:34 mikeb Exp $ */
> +/* $OpenBSD: re.c,v 1.112 2009/07/18 13:21:32 sthen Exp $ */
> /* $FreeBSD: if_re.c,v 1.31 2004/09/04 07:54:05 ru Exp $ */
> /*
>* Copyright (c) 1997, 1998-2003
> @@ -162,9 +162,8 @@ static inline void re_set_bufaddr(struct
>
> int re_encap(struct rl_softc *, struct mbuf *, int *);
>
> -int re_newbuf(struct rl_softc *);
> +int re_newbuf(struct rl_softc *, int, struct mbuf *);
> int re_rx_list_init(struct rl_softc *);
> -void re_rx_list_fill(struct rl_softc *);
> int re_tx_list_init(struct rl_softc *);
> int re_rxeof(struct rl_softc *);
> int re_txeof(struct rl_softc *);
> @@ -1109,8 +1108,6 @@ re_attach(struct rl_softc *sc, const cha
> IFQ_SET_MAXLEN(&ifp->if_snd, RL_TX_QLEN);
> IFQ_SET_READY(&ifp->if_snd);
>
> - m_clsetwms(ifp, MCLBYTES, 2, RL_RX_DESC_CNT);
> -
> ifp->if_capabilities = IFCAP_VLAN_MTU | IFCAP_CSUM_IPv4 |
> IFCAP_CSUM_TCPv4 | IFCAP_CSUM_UDPv4;
>
> @@ -1215,18 +1212,28 @@ fail_0:
>
>
> int
> -re_newbuf(struct rl_softc *sc)
> +re_newbuf(struct rl_softc *sc, int idx, struct mbuf *m)
> {
> - struct mbuf *m;
> + struct mbuf *n = NULL;
> bus_dmamap_tmap;
> struct rl_desc *d;
> struct rl_rxsoft *rxs;
> u_int32_t cmdstat;
> - int error, idx;
> + int error;
>
> - m = MCLGETI(NULL, M_DONTWAIT,&sc->sc_arpcom.ac_if, MCLBYTES);
> - if (!m)
> - return (ENOBUFS);
> + if (m == NULL) {
> + MGETHDR(n, M_DONTWAIT, MT_DATA);
> + if (n == NULL)
> + return (ENOBUFS);
> +
> + MCLGET(n, M_DONTWAIT);
> + if (!(n->m_flags& M_EXT)) {
> + m_freem(n);
> + return (ENOBUFS);
> + }
> + m = n;
> + } else
> + m->m_data = m->m_ext.ext_buf;
>
>
Re: [SOLVED] Re: OpenBSD 4.8 freezes on certain activities
Yes, it does. regards M.K. W dniu 2010-11-11 10:53, Stuart Henderson pisze: On 2010-11-10, Micha?? Koc wrote: Hi All, migrating from re to em solved the network problem With the re(4), does the system recover if you leave it for a couple of minutes?
[SOLVED] Re: OpenBSD 4.8 freezes on certain activities
Hi All,
migrating from re to em solved the network problem
best regards
m.k.
W dniu 2010-11-03 12:17, MichaE Koc pisze:
Hi All,
I've just upgraded two of my OpenBSD machines to 4.8:
hw.machine=i386
hw.model=Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz ("GenuineIntel"
686-class)
hw.product=DG31PR
and
hw.machine=i386
hw.model=Intel(R) Atom(TM) CPU D510 @ 1.66GHz ("GenuineIntel" 686-class)
hw.product=D510MO
Dmesgs are below.
The problem is that they freeze every time I try to:
- rsync two local filesystems on different physical disks - high disk
IO - about 30GB
- run nagios with about 900 probes - hight network IO and ndcpy like
3000 in systat, lots of forks, load average raising to 5 and above
High disk IO freeze occurs about 30 seconds after rsync start and is
permanent.
High network IO freeze occurs several minutes after nagios start and
sometimes machines are responsive for limited time. Pkill nagios
resolves the problem, machine becomes responsive.
In both cases machines behind nat still have internet connectivity.
Local services like ssh or console are unavailable.
Snapshot from 2010-11-02 22:51:00 does not resolve the issue.
The Atom machine freezes much faster than Core2Duo.
any help appreciated
best regards
M.K.
Core2Duo dmesg:
OpenBSD 4.8 (GENERIC.MP) #359: Mon Aug 16 09:16:26 MDT 2010
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz ("GenuineIntel"
686-class) 3.01 GHz
cpu0:
FPU,V86,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,SSSE3,CX16,xTPR,PDCM,SSE4.1
real mem = 3476889600 (3315MB)
avail mem = 3410038784 (3252MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 02/27/08, SMBIOS rev. 2.4 @
0xe8170 (42 entries)
bios0: vendor Intel Corp. version "PRG3110H.86A.0047.2008.0227.1745"
date 02/27/2008
bios0: Intel Corporation DG31PR
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC HPET MCFG
acpi0: wakeup devices P0P1(S3) PS2K(S3) PS2M(S3) UAR1(S3) P0P2(S4)
USB0(S3) USB1(S3) USB2(S3) USB3(S3) EUSB(S3) MC97(S4) PEX0(S4)
PEX1(S4) PEX2(S4) PEX3(S4) SLPB(S4) PWRB(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 333MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz ("GenuineIntel"
686-class) 3 GHz
cpu1:
FPU,V86,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,SSSE3,CX16,xTPR,PDCM,SSE4.1
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 4 (P0P2)
acpiprt2 at acpi0: bus 2 (PEX0)
acpiprt3 at acpi0: bus 3 (PEX1)
acpiprt4 at acpi0: bus -1 (PEX2)
acpiprt5 at acpi0: bus -1 (PEX3)
acpicpu0 at acpi0:, C3, C2, C1, PSS
acpicpu1 at acpi0:, C3, C2, C1, PSS
acpibtn0 at acpi0: SLPB
acpibtn1 at acpi0: PWRB
bios0: ROM list: 0xc/0xb400!
cpu0: Enhanced SpeedStep 3000 MHz: speeds: 2997, 1998 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82G33 Host" rev 0x10
ppb0 at pci0 dev 1 function 0 "Intel 82G33 PCIE" rev 0x10: apic 0 int
16 (irq 11)
pci1 at ppb0 bus 1
vga1 at pci0 dev 2 function 0 "Intel 82G33 Video" rev 0x10
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
intagp0 at vga1
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0 at vga1: apic 0 int 16 (irq 11)
drm0 at inteldrm0
ppb1 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01: apic 0
int 16 (irq 11)
pci2 at ppb1 bus 2
ppb2 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x01: apic 0
int 17 (irq 10)
pci3 at ppb2 bus 3
re0 at pci3 dev 0 function 0 "Realtek 8168" rev 0x01: RTL8168 2
(0x3800), apic 0 int 17 (irq 10), address 00:1c:c0:4f:f5:1c
rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 2
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: apic 0
int 23 (irq 5)
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x01: apic 0
int 19 (irq 3)
uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x01: apic 0
int 18 (irq 7)
uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x01: apic 0
int 16 (irq 11)
ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x01: apic 0
int 23 (irq 5)
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
em0 at pci4 dev 5 function 0 "Intel PRO/1000MT (82546EB)" rev 0x01:
apic 0 int 20 (irq 4), address 00:02:a5:4b:9e:36
em1 at pci4 dev 5 function 1 "Intel PRO/1000MT (82546EB)" rev 0x01:
apic 0 int 21 (irq 11), address 00:02:a5:4b:9e:37
puc0 at pci4
Re: OpenBSD 4.8 freezes on certain activities
Hmmm,
I was a little bit too optimistic.
The hight disk IO seems not to cause problems now, but network io (re
adapter) from nagios(probably) has freezed the Atom machine after
approximately 2 hours.
This is top header right after freeze:
75 processes: 1 running, 70 idle, 4 on processor
CPU0 states: 2.9% user, 0.0% nice, 17.3% system, 51.9% interrupt,
27.9% idle
CPU1 states: 4.6% user, 0.0% nice, 80.2% system, 4.6% interrupt,
10.7% idle
CPU2 states: 25.2% user, 0.0% nice, 54.8% system, 17.0% interrupt,
3.0% idle
CPU3 states: 8.0% user, 0.0% nice, 52.1% system, 18.4% interrupt,
21.5% idle
Memory: Real: 106M/453M act/tot Free: 2794M Swap: 0K/1028M used/tot
Maby it's just too much for Atom ?
best regards
M.K.
W dniu 2010-11-05 20:20, Michay Koc pisze:
Thank You for your time.
The patch seems to resolve both problems on Atom platform. Will check
Core2Duo later.
Thanks once again
Best regard
M.K.
W dniu 2010-11-05 18:36, Bob Beck pisze:
Are you able to try the following? see if it solves your problem.
Index: sys/kern/vfs_bio.c
===
RCS file: /cvs/src/sys/kern/vfs_bio.c,v
retrieving revision 1.126
diff -u -r1.126 vfs_bio.c
--- sys/kern/vfs_bio.c 3 Aug 2010 06:30:19 - 1.126
+++ sys/kern/vfs_bio.c 5 Nov 2010 17:32:44 -
@@ -672,21 +672,10 @@
*/
if (!ISSET(bp->b_flags, B_DELWRI)) {
SET(bp->b_flags, B_DELWRI);
- bp->b_synctime = time_uptime + 35;
s = splbio();
reassignbuf(bp);
splx(s);
curproc->p_stats->p_ru.ru_oublock++;/* XXX */
- } else {
- /*
-* see if this buffer has slacked through the syncer
-* and enforce an async write upon it.
-*/
- if (bp->b_synctime< time_uptime) {
- bawrite(bp);
- return;
- }
- }
/* If this is a tape block, write the block now. */
if (major(bp->b_dev)< nblkdev&&
@@ -727,7 +716,6 @@
if (ISSET(bp->b_flags, B_DELWRI) == 0) {
SET(bp->b_flags, B_DELWRI);
- bp->b_synctime = time_uptime + 35;
reassignbuf(bp);
}
}
On 3 November 2010 05:17, Michay Koc wrote:
Hi All,
I've just upgraded two of my OpenBSD machines to 4.8:
hw.machine=i386
hw.model=Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz ("GenuineIntel"
686-class)
hw.product=DG31PR
and
hw.machine=i386
hw.model=Intel(R) Atom(TM) CPU D510 @ 1.66GHz ("GenuineIntel"
686-class)
hw.product=D510MO
Dmesgs are below.
The problem is that they freeze every time I try to:
- rsync two local filesystems on different physical disks - high
disk IO -
about 30GB
- run nagios with about 900 probes - hight network IO and ndcpy like
3000 in
systat, lots of forks, load average raising to 5 and above
High disk IO freeze occurs about 30 seconds after rsync start and is
permanent.
High network IO freeze occurs several minutes after nagios start and
sometimes machines are responsive for limited time. Pkill nagios
resolves
the problem, machine becomes responsive.
In both cases machines behind nat still have internet connectivity.
Local services like ssh or console are unavailable.
Snapshot from 2010-11-02 22:51:00 does not resolve the issue.
The Atom machine freezes much faster than Core2Duo.
any help appreciated
best regards
M.K.
Core2Duo dmesg:
OpenBSD 4.8 (GENERIC.MP) #359: Mon Aug 16 09:16:26 MDT 2010
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz ("GenuineIntel"
686-class)
3.01 GHz
cpu0:
FPU,V86,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,SSSE3,CX16,xTPR,PDCM,SSE4.1
real mem = 3476889600 (3315MB)
avail mem = 3410038784 (3252MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 02/27/08, SMBIOS rev. 2.4 @
0xe8170
(42 entries)
bios0: vendor Intel Corp. version "PRG3110H.86A.0047.2008.0227.1745"
date
02/27/2008
bios0: Intel Corporation DG31PR
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC HPET MCFG
acpi0: wakeup devices P0P1(S3) PS2K(S3) PS2M(S3) UAR1(S3) P0P2(S4)
USB0(S3)
USB1(S3) USB2(S3) USB3(S3) EUSB(S3) MC97(S4) PEX0(S4) PEX1(S4) PEX2(S4)
PEX3(S4) SLPB(S4) PWRB(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 333MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz ("GenuineIntel"
686-class)
3 GHz
cpu1:
FPU,V86,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,SSSE3,CX16,xTPR,PDCM,SSE4.1
io
Re: OpenBSD 4.8 freezes on certain activities
Thank You for your time.
The patch seems to resolve both problems on Atom platform. Will check
Core2Duo later.
Thanks once again
Best regard
M.K.
W dniu 2010-11-05 18:36, Bob Beck pisze:
Are you able to try the following? see if it solves your problem.
Index: sys/kern/vfs_bio.c
===
RCS file: /cvs/src/sys/kern/vfs_bio.c,v
retrieving revision 1.126
diff -u -r1.126 vfs_bio.c
--- sys/kern/vfs_bio.c 3 Aug 2010 06:30:19 - 1.126
+++ sys/kern/vfs_bio.c 5 Nov 2010 17:32:44 -
@@ -672,21 +672,10 @@
*/
if (!ISSET(bp->b_flags, B_DELWRI)) {
SET(bp->b_flags, B_DELWRI);
- bp->b_synctime = time_uptime + 35;
s = splbio();
reassignbuf(bp);
splx(s);
curproc->p_stats->p_ru.ru_oublock++;/* XXX */
- } else {
- /*
-* see if this buffer has slacked through the syncer
-* and enforce an async write upon it.
-*/
- if (bp->b_synctime< time_uptime) {
- bawrite(bp);
- return;
- }
- }
/* If this is a tape block, write the block now. */
if (major(bp->b_dev)< nblkdev&&
@@ -727,7 +716,6 @@
if (ISSET(bp->b_flags, B_DELWRI) == 0) {
SET(bp->b_flags, B_DELWRI);
- bp->b_synctime = time_uptime + 35;
reassignbuf(bp);
}
}
On 3 November 2010 05:17, Michay Koc wrote:
Hi All,
I've just upgraded two of my OpenBSD machines to 4.8:
hw.machine=i386
hw.model=Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz ("GenuineIntel"
686-class)
hw.product=DG31PR
and
hw.machine=i386
hw.model=Intel(R) Atom(TM) CPU D510 @ 1.66GHz ("GenuineIntel" 686-class)
hw.product=D510MO
Dmesgs are below.
The problem is that they freeze every time I try to:
- rsync two local filesystems on different physical disks - high disk IO -
about 30GB
- run nagios with about 900 probes - hight network IO and ndcpy like 3000 in
systat, lots of forks, load average raising to 5 and above
High disk IO freeze occurs about 30 seconds after rsync start and is
permanent.
High network IO freeze occurs several minutes after nagios start and
sometimes machines are responsive for limited time. Pkill nagios resolves
the problem, machine becomes responsive.
In both cases machines behind nat still have internet connectivity.
Local services like ssh or console are unavailable.
Snapshot from 2010-11-02 22:51:00 does not resolve the issue.
The Atom machine freezes much faster than Core2Duo.
any help appreciated
best regards
M.K.
Core2Duo dmesg:
OpenBSD 4.8 (GENERIC.MP) #359: Mon Aug 16 09:16:26 MDT 2010
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz ("GenuineIntel" 686-class)
3.01 GHz
cpu0:
FPU,V86,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,SSSE3,CX16,xTPR,PDCM,SSE4.1
real mem = 3476889600 (3315MB)
avail mem = 3410038784 (3252MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 02/27/08, SMBIOS rev. 2.4 @ 0xe8170
(42 entries)
bios0: vendor Intel Corp. version "PRG3110H.86A.0047.2008.0227.1745" date
02/27/2008
bios0: Intel Corporation DG31PR
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC HPET MCFG
acpi0: wakeup devices P0P1(S3) PS2K(S3) PS2M(S3) UAR1(S3) P0P2(S4) USB0(S3)
USB1(S3) USB2(S3) USB3(S3) EUSB(S3) MC97(S4) PEX0(S4) PEX1(S4) PEX2(S4)
PEX3(S4) SLPB(S4) PWRB(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 333MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz ("GenuineIntel" 686-class)
3 GHz
cpu1:
FPU,V86,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,SSSE3,CX16,xTPR,PDCM,SSE4.1
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 4 (P0P2)
acpiprt2 at acpi0: bus 2 (PEX0)
acpiprt3 at acpi0: bus 3 (PEX1)
acpiprt4 at acpi0: bus -1 (PEX2)
acpiprt5 at acpi0: bus -1 (PEX3)
acpicpu0 at acpi0:, C3, C2, C1, PSS
acpicpu1 at acpi0:, C3, C2, C1, PSS
acpibtn0 at acpi0: SLPB
acpibtn1 at acpi0: PWRB
bios0: ROM list: 0xc/0xb400!
cpu0: Enhanced SpeedStep 3000 MHz: speeds: 2997, 1998 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82G33 Host" rev 0x10
ppb0 at pci0 dev 1 function 0 "Intel 82G33 PCIE" rev 0x10: apic 0 int 16
(irq 11)
pci1 at ppb0 bus 1
vga1 at pci0 dev 2 function 0 "Intel 82G33 Video" rev 0x10
wsdisplay0 at vga1 mux 1: console (80x25,
OpenBSD 4.8 freezes on certain activities
Hi All,
I've just upgraded two of my OpenBSD machines to 4.8:
hw.machine=i386
hw.model=Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz ("GenuineIntel"
686-class)
hw.product=DG31PR
and
hw.machine=i386
hw.model=Intel(R) Atom(TM) CPU D510 @ 1.66GHz ("GenuineIntel" 686-class)
hw.product=D510MO
Dmesgs are below.
The problem is that they freeze every time I try to:
- rsync two local filesystems on different physical disks - high disk IO
- about 30GB
- run nagios with about 900 probes - hight network IO and ndcpy like
3000 in systat, lots of forks, load average raising to 5 and above
High disk IO freeze occurs about 30 seconds after rsync start and is
permanent.
High network IO freeze occurs several minutes after nagios start and
sometimes machines are responsive for limited time. Pkill nagios
resolves the problem, machine becomes responsive.
In both cases machines behind nat still have internet connectivity.
Local services like ssh or console are unavailable.
Snapshot from 2010-11-02 22:51:00 does not resolve the issue.
The Atom machine freezes much faster than Core2Duo.
any help appreciated
best regards
M.K.
Core2Duo dmesg:
OpenBSD 4.8 (GENERIC.MP) #359: Mon Aug 16 09:16:26 MDT 2010
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz ("GenuineIntel"
686-class) 3.01 GHz
cpu0:
FPU,V86,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,SSSE3,CX16,xTPR,PDCM,SSE4.1
real mem = 3476889600 (3315MB)
avail mem = 3410038784 (3252MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 02/27/08, SMBIOS rev. 2.4 @
0xe8170 (42 entries)
bios0: vendor Intel Corp. version "PRG3110H.86A.0047.2008.0227.1745"
date 02/27/2008
bios0: Intel Corporation DG31PR
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC HPET MCFG
acpi0: wakeup devices P0P1(S3) PS2K(S3) PS2M(S3) UAR1(S3) P0P2(S4)
USB0(S3) USB1(S3) USB2(S3) USB3(S3) EUSB(S3) MC97(S4) PEX0(S4) PEX1(S4)
PEX2(S4) PEX3(S4) SLPB(S4) PWRB(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 333MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz ("GenuineIntel"
686-class) 3 GHz
cpu1:
FPU,V86,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,SSSE3,CX16,xTPR,PDCM,SSE4.1
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 4 (P0P2)
acpiprt2 at acpi0: bus 2 (PEX0)
acpiprt3 at acpi0: bus 3 (PEX1)
acpiprt4 at acpi0: bus -1 (PEX2)
acpiprt5 at acpi0: bus -1 (PEX3)
acpicpu0 at acpi0:, C3, C2, C1, PSS
acpicpu1 at acpi0:, C3, C2, C1, PSS
acpibtn0 at acpi0: SLPB
acpibtn1 at acpi0: PWRB
bios0: ROM list: 0xc/0xb400!
cpu0: Enhanced SpeedStep 3000 MHz: speeds: 2997, 1998 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82G33 Host" rev 0x10
ppb0 at pci0 dev 1 function 0 "Intel 82G33 PCIE" rev 0x10: apic 0 int 16
(irq 11)
pci1 at ppb0 bus 1
vga1 at pci0 dev 2 function 0 "Intel 82G33 Video" rev 0x10
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
intagp0 at vga1
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0 at vga1: apic 0 int 16 (irq 11)
drm0 at inteldrm0
ppb1 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01: apic 0 int
16 (irq 11)
pci2 at ppb1 bus 2
ppb2 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x01: apic 0 int
17 (irq 10)
pci3 at ppb2 bus 3
re0 at pci3 dev 0 function 0 "Realtek 8168" rev 0x01: RTL8168 2
(0x3800), apic 0 int 17 (irq 10), address 00:1c:c0:4f:f5:1c
rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 2
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: apic 0 int
23 (irq 5)
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x01: apic 0 int
19 (irq 3)
uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x01: apic 0 int
18 (irq 7)
uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x01: apic 0 int
16 (irq 11)
ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x01: apic 0 int
23 (irq 5)
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
em0 at pci4 dev 5 function 0 "Intel PRO/1000MT (82546EB)" rev 0x01: apic
0 int 20 (irq 4), address 00:02:a5:4b:9e:36
em1 at pci4 dev 5 function 1 "Intel PRO/1000MT (82546EB)" rev 0x01: apic
0 int 21 (irq 11), address 00:02:a5:4b:9e:37
puc0 at pci4 dev 6 function 0 "NetMos Nm9835" rev 0x01: ports: 2 com, 1 lpt
com3 at puc0 port 0 apic 0 int 21 (irq 11): ns16550a, 16 byte
Ami and OpenBSD 4.4 AMD64 SMP satbility
Hi, I've just tested SRCS28X witch is a ami0 raid controller with OpenBSD 4.4 errata 005 on fallowing architectures: - i386 - i386 SMP - amd64 - amd64 SMP It occurs that dd uf=/dev/zero of=/test to the filesystem mounted on ami0 freezes the system on amd64/SMP only. This behavior is repetitive. Does anyone have a clue what might causing it ? and how to fix it ? I've also tried different SRCS28X bioses, but no luck. If any more information is required, please let mi know. regards M.K.
Apache and probably other problems - OpenBSD 4.4
Hi, I've just set up two 4.4 boxes, i386 and amd64 on same king of hardware. I've started bundled apache and compiled ab from apache 2.2.10 The problem is that ab stops after about 100 requests with error: ab started on local machine: apr_socket_connect(): Connection refused (61) ab started on different machine: apr_connect(): apr_socket_connect(): Operation already in progress (37) ab started with parameters: -c 100 -n 1000 After this experience, I've reinstalled the boxes with OpenBSD 4.3, and the problem is gone... Am I missing something ? is the problem ab related ? ab started with -c 1 does not produce any errors. ab -c 100 -n 1000 to other OpenBSD 4.3 machines works also fine... Also checked with enabled and disabled pf, and with statefull filtering, and even with a help of relayd. I've also compiled squid, and checked it with ab, and the problem remains. Any help appreciated. Regards M.K.
Re: make build fails for OPENBSD_4_4 on i386
is it ?
according to man release:
OPENBSD_x_y_BASE This tag marks the source as it exists on the release
CD-ROM where x is the major release number and y
is the
minor release number.
OPENBSD_x_y This tag is a moving target. It marks the
sources that
belong to the stable branch. This branch only
contains
errata, no new features.
Correct me if I'm wrong, but there is OPENBSD_4_4_BASE and OPENBSD_4_4 i
the CVS repositiory.
So it should be what would be on the CD.
regards
M.K.
Tomas Bodzar pisze:
Beta and build?What a nice type of Sci-Fi ;-)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael
Sent: Friday, August 08, 2008 12:21 PM
To: OpenBSD Misc
Subject: make build fails for OPENBSD_4_4 on i386
===> libreadline
mkdep -a -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libreadline
/usr/src/gnu/lib/libreadline/readline.c
/usr/src/gnu/lib/libreadline/funmap.c
/usr/src/gnu/lib/libreadline/keymaps.c
/usr/src/gnu/lib/libreadline/vi_mode.c
/usr/src/gnu/lib/libreadline/parens.c
/usr/src/gnu/lib/libreadline/rltty.c
/usr/src/gnu/lib/libreadline/complete.c
/usr/src/gnu/lib/libreadline/bind.c
/usr/src/gnu/lib/libreadline/isearch.c
/usr/src/gnu/lib/libreadline/display.c
/usr/src/gnu/lib/libreadline/signals.c
/usr/src/gnu/lib/libreadline/util.c /usr/src/gnu/lib/libreadline/kill.c
/usr/src/gnu/lib/libreadline/undo.c /usr/src/gnu/lib/libreadline/macro.c
/usr/src/gnu/lib/libreadline/input.c
/usr/src/gnu/lib/libreadline/callback.c
/usr/src/gnu/lib/libreadline/terminal.c
/usr/src/gnu/lib/libreadline/xmalloc.c
/usr/src/gnu/lib/libreadline/history.c
/usr/src/gnu/lib/libreadline/histsearch.c
/usr/src/gnu/lib/libreadline/histexpand.c
/usr/src/gnu/lib/libreadline/histfile.c
/usr/src/gnu/lib/libreadline/nls.c /usr/src/gnu/lib/libreadline/search.c
/usr/sr*** Error code 1
Stop in /usr/src/gnu/lib/libreadline (line 12 of /usr/share/mk/bsd.dep.mk).
*** Error code 1
Stop in /usr/src/gnu/lib (line 48 of /usr/share/mk/bsd.subdir.mk).
*** Error code 1
Stop in /usr/src (line 73 of Makefile).
Any ideas?
BELENUS.MP is GENERIC.MP + NTFS + Intel DRM # dmesg OpenBSD 4.4-beta
(BELENUS.MP) #0: Sat Aug 2 11:14:40 CEST 2008
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/BELENUS.MP
cpu0: Intel(R) Pentium(R) D CPU 3.00GHz ("GenuineIntel" 686-class) 3 GHz
cpu0:
FPU,V86,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,EST,CNXT-ID,CX16,xTPR
real mem = 1063378944 (1014MB)
avail mem = 1019830272 (972MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 03/31/06, BIOS32 rev. 0 @ 0xffe90, SMBIOS
rev. 2.3 @ 0xf0450 (73 entries)
bios0: vendor Dell Inc. version "A07" date 03/31/2006
bios0: Dell Inc. OptiPlex GX620
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP SSDT APIC BOOT ASF! MCFG HPET SSDT SSDT SSDT
acpi0: wakeup devices VBTN(S4) PCI0(S5) PCI4(S5) PCI2(S5) PCI3(S5)
PCI1(S5) PCI5(S5) PCI6(S5) MOU_(S3) USB0(S3) USB1(S3) USB2(S3) USB3(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0:
PC-AT compat cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 199MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Pentium(R) D CPU 3.00GHz ("GenuineIntel" 686-class) 3 GHz
cpu1:
FPU,V86,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,EST,CNXT-ID,CX16,xTPR
ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 8 acpihpet0 at acpi0:
14318179 Hz acpiprt0 at acpi0: bus 3 (PCI4)
acpiprt1 at acpi0: bus 1 (PCI2)
acpiprt2 at acpi0: bus 2 (PCI3)
acpiprt3 at acpi0: bus -1 (PCI1)
acpiprt4 at acpi0: bus -1 (PCI5)
acpiprt5 at acpi0: bus -1 (PCI6)
acpiprt6 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: FVS, 3000, 2400 MHz
acpicpu1 at acpi0: FVS, 3000, 2400 MHz
acpibtn0 at acpi0: VBTN
bios0: ROM list: 0xc/0xa800! 0xca800/0x2000! 0xcc800/0x3800 pci0 at mainbus0 bus 0:
configuration mode 1 (no bios) 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
0xe000, size 0x1000 inteldrm0 at vga1
info: [drm] Intel i945G (unit 0)
info: [drm] AGP at 0xe000 256MB
info: [drm] Initialized i915 1.6.0 20080312 "Intel 82945G Video" rev 0x02 at pci0 dev 2
function 1 not configured ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01:
apic 8 int
16 (irq 11)
pci1 at ppb0 bus 1
bge0 at pci1 dev 0 function 0 "Broadcom BCM5751" rev 0x01, BCM5750 A1
(0x4001): apic 8 int 16 (irq 11), address 00:13:72:cf:5d:52 brgphy0 at bge0 phy
1: BCM5
Re: relayd and "src track"
Due to some problems witch patch formatting in mail agent
it is also available at http://www.prime.pl/relayd.diff
regards
MichaE Koc
Pierre-Yves Ritschard pisze:
>> + if (rdr->conf.flags & F_STICKY)
>> + if (ioctl(env->sc_pf->dev, DIOCCLRSRCNODES, 0) == -1)
>> + fatal("sync_table: cannot clear the tree of source
>> tracking nodes");
>> +
>>free(addlist);
>>
>>log_debug("sync_table: table %s: %d added, %d deleted, %d changed",
>>
>>
>
> Good enough for now, it's in. We'll look for a way of clearing
> individual nodes later on.
Re: relayd and "src track"
Hi,
Looking into pf_ioctl.c and pfvar.h I've found that there is an
undocumented (for some unknown reason) IOCTL - DIOCKILLSRCNODES.
Further investigation revealed that it's purpose is to remove single
node from source tracking tree.
So the simplest way is find out what connections should be removed and
kill them. But in sync_table we have only the final table, so
connections to remove
are in the pf table but not in the final table. To find them it is
simplest to get previous table from pf, and subtract from it the final
table.
And then to remove found items from source tracking tree.
That's exactly what is done in the diff below.
best regards
MichaE Koc
Index: pfe_filter.c
===
RCS file: /cvs/src/usr.sbin/relayd/pfe_filter.c,v
retrieving revision 1.27
diff -u -r1.27 pfe_filter.c
--- pfe_filter.c16 May 2008 14:47:58 -1.27
+++ pfe_filter.c17 May 2008 13:46:43 -
@@ -157,8 +157,12 @@
sync_table(struct relayd *env, struct rdr *rdr, struct table *table)
{
int i;
+int j;
+int cs;
struct pfioc_table io;
+struct pfioc_src_node_kill iok;
struct pfr_addr*addlist;
+struct pfr_addr*curlist;
struct sockaddr_in*sain;
struct sockaddr_in6*sain6;
struct host*host;
@@ -179,9 +183,7 @@
memset(&io, 0, sizeof(io));
io.pfrio_esize = sizeof(struct pfr_addr);
-io.pfrio_size = table->up;
io.pfrio_size2 = 0;
-io.pfrio_buffer = addlist;
if (strlcpy(io.pfrio_table.pfrt_anchor, RELAYD_ANCHOR "/",
sizeof(io.pfrio_table.pfrt_anchor)) >= PF_ANCHOR_NAME_SIZE)
goto toolong;
@@ -193,6 +195,28 @@
sizeof(io.pfrio_table.pfrt_name))
goto toolong;
+cs = 0;
+curlist = 0;
+
+if (rdr->conf.flags & F_STICKY) {
+io.pfrio_size = 0;
+io.pfrio_buffer = 0;
+if (ioctl(env->sc_pf->dev, DIOCRGETADDRS, &io) == -1)
+fatal("sync_table: cannot get number of address");
+
+if ((cs = io.pfrio_size)) {
+if ((curlist = calloc(cs, sizeof(*curlist))) == NULL)
+fatal("calloc");
+
+io.pfrio_buffer = curlist;
+if (ioctl(env->sc_pf->dev, DIOCRGETADDRS, &io) == -1)
+fatal("sync_table: cannot get address list");
+}
+}
+
+io.pfrio_size = table->up;
+io.pfrio_buffer = addlist;
+
i = 0;
TAILQ_FOREACH(host, &table->hosts, entry) {
if (host->up != HOST_UP)
@@ -205,6 +229,11 @@
memcpy(&(addlist[i].pfra_ip4addr), &sain->sin_addr,
sizeof(sain->sin_addr));
addlist[i].pfra_net = 32;
+for (j = 0; j < cs; ++j)
+if (!memcmp(&sain->sin_addr,
+&(curlist[j].pfra_ip4addr),
+sizeof(sain->sin_addr)))
+break;
break;
case AF_INET6:
sain6 = (struct sockaddr_in6 *)&host->conf.ss;
@@ -212,11 +241,17 @@
memcpy(&(addlist[i].pfra_ip6addr), &sain6->sin6_addr,
sizeof(sain6->sin6_addr));
addlist[i].pfra_net = 128;
+for (j = 0; j < cs; ++j)
+if (!memcmp(&sain6->sin6_addr,
+&(curlist[j].pfra_ip6addr),
+sizeof(sain6->sin6_addr)))
+break;
break;
default:
fatalx("sync_table: unknown address family");
break;
}
+if (j != cs) curlist[j].pfra_fback = 1;
i++;
}
if (i != table->up)
@@ -224,16 +259,48 @@
if (ioctl(env->sc_pf->dev, DIOCRSETADDRS, &io) == -1)
fatal("sync_table: cannot set address list");
-if (rdr->conf.flags & F_STICKY) {
-if (ioctl(env->sc_pf->dev, DIOCCLRSRCNODES, 0) == -1)
-fatal("sync_table: cannot clear the tree of "
-"source tracking nodes");
-}
free(addlist);
log_debug("sync_table: table %s: %d added, %d deleted, %d changed",
io.pfrio_table.pfrt_name,
io.pfrio_nadd, io.pfrio_ndel, io.pfrio_nchange);
+
+if (cs && (rdr->conf.flags & F_STICKY)) {
+
+memset(&iok.psnk_src, 0, sizeof(iok.psnk_src));
+memset(&iok.psnk_dst, 0xff, sizeof(iok.psnk_dst));
+iok.psnk_src.port_op = PF_OP_NONE;
+iok.psnk_dst.port[0] = rdr->conf.port;
+iok.psnk_dst.neg = 0;
+iok.psnk_dst.port_op = PF_OP_EQ;
+
+for (i = 0; i < cs; ++i)
+if (!curlist[i].pfra_fback) {
+iok.psnk_af = curlist[i].pfra_af;
+switch (iok.psnk_af) {
+case AF_INET:
+memcpy(&iok.psnk_dst.addr.v.a.addr.v4,
+&curlist[i].pfra_ip4addr,
+sizeof(curlist[i].pfra_ip4addr));
+break;
+case AF_INET6:
+memcpy(&iok.psnk_dst.addr.v.a.addr.v6,
+
Re: relayd and "src track"
Hi,
actually it is enough to clear the tree of source tracking nodes right
after syncing tables, so the sticky-address is stored again.
Unfortunately there is one disadvantage, all sources will be flushed, so
some connections can be assigned to different hosts.
But I think it's better then leaving it unattended.
the appropriate diff is below and should work with all versions of
relayd and hoststated with a little change referring to vars naming:
Index: usr.sbin/relayd/pfe_filter.c
===
RCS file: /cvs/src/usr.sbin/relayd/pfe_filter.c,v
retrieving revision 1.26
diff -u -r1.26 pfe_filter.c
--- usr.sbin/relayd/pfe_filter.c7 May 2008 01:49:29 - 1.26
+++ usr.sbin/relayd/pfe_filter.c16 May 2008 13:09:06 -
@@ -225,6 +225,10 @@
if (ioctl(env->sc_pf->dev, DIOCRSETADDRS, &io) == -1)
fatal("sync_table: cannot set address list");
+ if (rdr->conf.flags & F_STICKY)
+ if (ioctl(env->sc_pf->dev, DIOCCLRSRCNODES, 0) == -1)
+ fatal("sync_table: cannot clear the tree of
source tracking nodes");
+
free(addlist);
log_debug("sync_table: table %s: %d added, %d deleted, %d changed",
best regards
MichaE Koc
Per-Olov SjC6holm pisze:
Hi
Is it possible to handle PF "src track" from relayd. If I use "sticky
connections" in relayd (NOT layer 7) and one target host dissappear, then it
seems like "src track" comes into play.
When one target host (for example 10.0.0.1 below) goes down I want to clear
all src track info from PF related to the target host.
Am I missing something in the man pages? suggestions appreciated. If I
remember it right such thing could be done in "ifstated" where a pfctl -"K"
could be done...
TESTfile follows:
[EMAIL PROTECTED]:~#more /etc/relayd.conf
EXT_IP=200.200.200.200
interval 5
timeout 1000
table { 10.0.0.1 , 10.0.0.2 }
redirect www {
listen on $EXT_IP port 80
listen on $EXT_IP port 443
tag RELAYD
sticky-address
forward to timeout 500 port 22 check icmp
}
Thanks in advance
Regards
Per-Olov
--
GPG keyID: 4DB283CE
GPG fingerprint: 45E8 3D0E DE05 B714 D549 45BC CFB4 BBE9 4DB2 83CE
GPG key:
http://keyserv.nic-se.se:11371/pks/lookup?op=get&search=0xCFB4BBE94DB283CE
Re: Intel DQ35MP
Hi, Using drive 0, partition 3. Loading... probing: pc0 apm mem[635K 3573M 16K a20=on] disk: hd0+ >> OpenBSD/i386 BOOT 3.01 boot> machine memory Region 0: type 1 at 0x1000 for 635KB Region 1: type 2 at 0x9fc00 for 1KB Region 2: type 2 at 0xe for 128KB Region 3: type 1 at 0x10 for 3659244KB Region 4: type 4 at 0xdf67b000 for 440KB Region 5: type 1 at 0xdf6e9000 for 16KB Region 6: type 3 at 0xdf6ed000 for 72KB Region 7: type 1 at 0xdf6ff000 for 4KB Low ram: 639KB Hight ram: 3659260KB Total free memory: 3659899KB boot> this comes from Intel D945GTP which also shows this problem. regards M.K. [EMAIL PROTECTED] pisze: > In gmane.os.openbsd.misc, you wrote: > >> I had same problem with DQ965GF, DSDT was overwritten by msgbuf. >> As a quick hack I changed msgbuf size and it solved my problem. I >> haven't had time to debug it further. >> >> Index: sys/arch/i386/include/param.h >> === >> RCS file: /OpenBSD/src/sys/arch/i386/include/param.h,v >> retrieving revision 1.42 >> diff -u -3 -p -r1.42 param.h >> --- sys/arch/i386/include/param.h 1 Oct 2007 12:10:55 - 1.42 >> +++ sys/arch/i386/include/param.h 10 Jan 2008 19:13:18 - >> @@ -97,7 +97,7 @@ >> #defineUSPACE_ALIGN(0) /* u-area alignment 0-none >> */ >> >> #ifndef MSGBUFSIZE >> -#define MSGBUFSIZE 4*NBPG /* default message buffer size */ >> +#define MSGBUFSIZE 2*NBPG /* default message buffer size */ >> #endif >> > > Please send me the output of 'machine memory' at the boot prompt > for this machine. I think I know what is causing this... > > -Toby.
Re: Intel DQ35MP
Hello
I've noticed this problem on many different INTEL motherboard models.
Debugging showed that under the address where acpi structures should be
are actually zeros.
So there is probably some memory mapping problem.
regards
M.K.
Marcos Laufer pisze:
> Hello , i tried updating the BIOS to the newest one, removed one ram stick,
> installed
> latest snapshot and also tried disabling APM as you adviced me.
> When booting with bsd it doesn't recognize the devices just like before.
> Now i also tried booting with bsd.mp instead of bsd , and i get this error:
>
>
> OpenBSD 4.2-current (GENERIC.MP) #539: Tue Jan 8 17:20:15 MST 2008
> [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC.MP
> RTC BIOS diagnostic error 80
> cpu0: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz ("GenuineIntel" 686-class)
> 2.39 GHz
> cpu0:
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
>
> H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,CX16,
> xTPR
> real mem = 1040625664 (992mb)
> avail mem = 998227968 (951mb)
> RTC BIOS diagnostic error 80
> mainbus0 at root
> bios0 at mainbus0: at/286+ BIOS, date 12/10/07, SMBIOS rev. 2.4 @ 0xe2440 (31
> entries)
> bios0: vendor Intel Corp. version "JOQ3510J.86A.0731.2007.1210.2204" date
> 12/10/2007
> bios0: Intel Corporation DQ35MP
> acpi0 at bios0: rev 0panic: malloc: allocation too large
> Stopped atDebugger+0x4: leave
> Debugger(e3ff000,0,d0916b48,2,3ff7) at Debugger+0x4
> panic(d06b38ce,d0916b64,1000,d07b0a20,) at panic+0x63
> malloc(f000ff5b,2,1,d0680060) at malloc+0x76
> acpi_load_table(0,f000ff53,d19cce3c,de3fe000,d19c1f80) at acpi_load_table+0x19
> acpi_loadtables(d19cce00,de3fd020,5,e) at acpi_loadtables+0x95
> acpi_attach(d19cbf80,d19cce00,d0916d50,d19cbf80,0) at acpi_attach+0xb2
> config_attach(d19cbf80,d078b980,d0916d50,d0604eb4) at config_attach+0xfd
> biosattach(d19cbfc0,d19cbf80,d0916e80,d19cbfc0,d02032c9) at biosattach+0x34e
> config_attach(d19cbfc0,d078ab70,d0916e80,d04a6504,d06d6958) at
> config_attach+0xfd
> mainbus_attach(0,d19cbfc0,0,de3f7000,d0915334) at mainbus_attach+0x3d
> RUN AT LEAST ...
>
> Regards,
> Marcos
>
> - Original Message -
> From: "Pierre Riteau" <[EMAIL PROTECTED]>
> To: "Marcos Laufer" <[EMAIL PROTECTED]>
> Cc:
> Sent: Thursday, December 13, 2007 8:55 PM
> Subject: Re: Intel DQ35MP
>
>
> On Dec 13, 2007 9:25 PM, Marcos Laufer <[EMAIL PROTECTED]> wrote:
>
>> Hello,
>>
>> I've just installed OpenBSD current on an Intel DQ35MP motherboard with a
>> Quad
>> processor, this is the
>> dmesg log. Some devices are not recognized (PCI slot, ethernet, etc)
>>
>
> boot -c to go in UKC or config -ef /bsd and use 'disable apm'
> to get acpi to attach. Maybe it will help.
> Also, you can get a newer snapshot.
>
>
>> OpenBSD 4.2-current (GENERIC) #558: Tue Nov 20 10:36:15 MST 2007
>> [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
>> RTC BIOS diagnostic error 80
>> cpu0: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz ("GenuineIntel" 686-class)
>> 2.39 GHz
>> cpu0:
>> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
>> H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,CX16,
>> xTPR
>> real mem = 2097643520 (2000MB)
>> avail mem = 2020409344 (1926MB)
>> RTC BIOS diagnostic error 80
>> mainbus0 at root
>> bios0 at mainbus0: AT/286+ BIOS, date 07/26/07, SMBIOS rev. 2.4 @ 0xe2460 (30
>> entries)
>> bios0: vendor Intel Corp. version "JOQ3510J.86A.0559.2007.0726.0425" date
>> 07/26/2007
>> bios0: Intel Corporation DQ35MP
>> apm0 at bios0: Power Management spec V1.2
>> apm0: battery life expectancy 0%
>> apm0: AC off, battery charge unknown, estimated 0:00 hours
>> pcibios at bios0 function 0x1a not configured
>> bios0: ROM list: 0xc/0xb400! 0xcb800/0x1e00! 0xcd800/0x1000
>> 0xce800/0x1000
>> cpu0 at mainbus0
>> pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
>> pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x29b0 rev
>> 0x02
>> vga1 at pci0 dev 2 function 0 vendor "Intel", unknown product 0x29b2 rev
>> 0x02:
>> aperture at 0x9020, size 0x800
>> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
>> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
>> vendor "Intel", unknown product 0x29b4 (class communications subclass
>> miscellaneous, rev 0x02) at pci0 dev 3 function 0 not configured
>> pciide0 at pci0 dev 3 function 2 vendor "Intel", unknown product 0x29b6 rev
>> 0x02: DMA (unsupported), channel 0 wired to native-PCI, channel 1 wired to
>> native-PCI
>> pciide0: using irq 9 for native-PCI interrupt
>> pciide0: channel 0 ignored (not responding; disabled or no drives?)
>> pciide0: channel 1 ignored (not responding; disabled or no drives?)
>> vendor "Intel", unknown product 0x29b7 (class communications subclass serial,
>> rev 0x02) at pci0 dev 3 function 3 not configured
>> "Intel ICH9 IGP AMT" rev 0x02 at pci0 dev 25 function 0 not configured
Re: Fatal page fault during boot on Toshiba A200 1M7 and X200-21K
Hi, same problem on Toshiba x200-21k, memory tested for 24h by memtest, so I assume it's okey regards M.K. Jack J. Woehr pisze: Possible motherboard hardware problems (PCI controller), or possibly memory problems? (( "pcibios0: bad IRQ table checksum" )) On Dec 21, 2007, at 1:28 PM, Key wrote: Hi, I'm trying to install OpenBSD 4.2 on my Toshiba A200 1M7 (Intel Core2 Duo T7100 1.86Ghz,1024Mb, 160Gb, 12.1", Intel GMA X3100 DO 128Mb, DVD-RW) laptop and almost failed to boot installer from CD. During bootload I see:
Re: Tool for HD analyzing
Peter N. M. Hansteen pisze: > "Leonardo Marques" <[EMAIL PROTECTED]> writes: > > >> I've a HD which are returning a lot of errors. Someone know some good >> tool to analyze this disk and tell me if i've to replace it or if >> exist some way to repair it? >> > > To my mind that kind of errors say "run, don't walk to the store for > replacement". Modern disks remap bad parts away from active use, when > they've run out of remappable space, they start complaining like that. > > For measuring the health of your next hard drive, it's possible > sysutils/smartmontools will do the job. > > What if you have an ata/serialata HD attached to scsi/ahci/jmb ? atactl is useless, will smartmontools work ? redargds M.K.
Re: Intel motherboards and ACPI
Hello, Well, actually I've already tried this without any luck. The problem lies somewhere deeper, I was trying to get at least acpidump working, and what I found is, that RSD PTR looks fine, but under address pointed by rs->addr all I can find are zeroes. May be a problem with physical memory mapping ? or corrupted ACPI (unlikely, on 5 machines same problem) ? regards M.K. Chris Kuethe pisze: http://marc.info/?l=openbsd-tech&m=118975639013313&w=2 On 9/16/07, Micha3 Koc <[EMAIL PROTECTED]> wrote: Hello everyone, I have a bunch of machines based on Intel motherboards, most of them are D945GCNL, but unfortunately I'm not able to use SMP because of ACPI problems. Beside the kernel side problems, acpidump outputs a strange error: RSDT is corrupted. Can someone tell me if there is any chance to get ACPI working ? best regards M.K. [demime 1.01d removed an attachment of type application/x-pkcs7-signature which had a name of smime.p7s]
Re: Intel motherboards and ACPI
Hi, yes, I've already googled for the issue and found this one, but it does not help. I think it is whole another problem. regards M.K. Chris Kuethe pisze: > http://marc.info/?l=openbsd-tech&m=118975639013313&w=2 > > On 9/16/07, Micha3 Koc <[EMAIL PROTECTED]> wrote: > >> Hello everyone, >> >> I have a bunch of machines based on Intel motherboards, most of them are >> D945GCNL, >> but unfortunately I'm not able to use SMP because of ACPI problems. >> Beside the kernel side problems, acpidump outputs a strange error: RSDT >> is corrupted. >> >> Can someone tell me if there is any chance to get ACPI working ? >> >> best regards >> M.K. >> >> [demime 1.01d removed an attachment of type application/x-pkcs7-signature which had a name of smime.p7s] [demime 1.01d removed an attachment of type application/x-pkcs7-signature which had a name of smime.p7s]
Intel motherboards and ACPI
Hello everyone, I have a bunch of machines based on Intel motherboards, most of them are D945GCNL, but unfortunately I'm not able to use SMP because of ACPI problems. Beside the kernel side problems, acpidump outputs a strange error: RSDT is corrupted. Can someone tell me if there is any chance to get ACPI working ? best regards M.K. [demime 1.01d removed an attachment of type application/x-pkcs7-signature which had a name of smime.p7s]
Sensors problem
Hello,
I've a problem with sensors on one of my machines, it seems to be coming
from ichiic slave detection.
The machine is:
INTEL BLKD865GSAL motherboard hw.product=D865GSA
It contains a Winbond W83627EHG chip, witch is the lead-free version of
W83627EHF - supported by OpenBSD (google says they are completely
compatible, even chip id)
But nothing is found.
Could someone please help me with this issue ?
The complete dmesg with ICHIIC_DEBUG enabled:
OpenBSD 4.1 (GENERIC) #10: Sat Mar 31 11:10:52 CEST 2007
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Celeron(R) D CPU 3.06GHz ("GenuineIntel" 686-class) 3.06 GHz
cpu0:
FPU,V86,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,CNXT-ID,CX16,xTPR
real mem = 534540288 (522012K)
avail mem = 480038912 (468788K)
using 4278 buffers containing 26849280 bytes (26220K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+ BIOS, date 05/04/06, BIOS32 rev. 0 @ 0xf0010, SMBIOS
rev. 2.3 @ 0xfba60 (68 entries)
bios0: Intel Corporation D865GSA
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
apm0: flags 30102 dobusy 0 doidle 1
pcibios0 at bios0: rev 3.0 @ 0xf/0x1
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf3d00/176 (9 entries)
pcibios0: PCI Interrupt Router at 000:31:0 ("Intel 82801EB/ER LPC" rev 0x00)
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc/0xa400!
acpi at mainbus0 not configured
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel 82865G/PE/P CPU-I/0-1" rev 0x02
vga1 at pci0 dev 2 function 0 "Intel 82865G Video" rev 0x02: aperture at
0xf000, size 0x800
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
uhci0 at pci0 dev 29 function 0 "Intel 82801EB/ER USB" rev 0x02: irq 11
usb0 at uhci0: USB revision 1.0
uhub0 at usb0
uhub0: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1 at pci0 dev 29 function 1 "Intel 82801EB/ER USB" rev 0x02: irq 5
usb1 at uhci1: USB revision 1.0
uhub1 at usb1
uhub1: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhci2 at pci0 dev 29 function 2 "Intel 82801EB/ER USB" rev 0x02: irq 9
usb2 at uhci2: USB revision 1.0
uhub2 at usb2
uhub2: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
uhci3 at pci0 dev 29 function 3 "Intel 82801EB/ER USB" rev 0x02: irq 11
usb3 at uhci3: USB revision 1.0
uhub3 at usb3
uhub3: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub3: 2 ports with 2 removable, self powered
ehci0 at pci0 dev 29 function 7 "Intel 82801EB/ER USB2" rev 0x02: irq 10
usb4 at ehci0: USB revision 2.0
uhub4 at usb4
uhub4: Intel EHCI root hub, rev 2.00/1.00, addr 1
uhub4: 8 ports with 8 removable, self powered
ppb0 at pci0 dev 30 function 0 "Intel 82801BA AGP" rev 0xc2
pci1 at ppb0 bus 1
re0 at pci1 dev 2 function 0 "Realtek 8169" rev 0x10: RTL8169S (0x0400), irq
12, address 00:30:4f:52:35:ff
rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 0
rl0 at pci1 dev 3 function 0 "Realtek 8139" rev 0x10: irq 10, address
00:19:d1:4d:fa:61
rlphy0 at rl0 phy 0: RTL internal PHY
ichpcib0 at pci0 dev 31 function 0 "Intel 82801EB/ER LPC" rev 0x02
pciide0 at pci0 dev 31 function 2 "Intel 82801EB SATA" rev 0x02: DMA, channel 0
configured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel 1 drive 0:
wd0: 16-sector PIO, LBA48, 157066MB, 321672960 sectors
wd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 5
ichiic0 at pci0 dev 31 function 3 "Intel 82801EB/ER SMBus" rev 0x02: conf
0x0001: irq 12
iic0 at ichiic0
ichiic0: exec: op 1, addr 0x18, cmdlen 1, len 0, flags 0x00
ichiic0: exec: st 0x0
ichiic0: intr st 0x44
ichiic0: exec: op 1, addr 0x1a, cmdlen 1, len 0, flags 0x00
ichiic0: exec: st 0x0
ichiic0: intr st 0x44
ichiic0: exec: op 1, addr 0x20, cmdlen 1, len 0, flags 0x00
ichiic0: exec: st 0x0
ichiic0: intr st 0x44
ichiic0: exec: op 1, addr 0x21, cmdlen 1, len 0, flags 0x00
ichiic0: exec: st 0x0
ichiic0: intr st 0x44
ichiic0: exec: op 1, addr 0x22, cmdlen 1, len 0, flags 0x00
ichiic0: exec: st 0x0
ichiic0: intr st 0x44
ichiic0: exec: op 1, addr 0x23, cmdlen 1, len 0, flags 0x00
ichiic0: exec: st 0x0
ichiic0: intr st 0x44
ichiic0: exec: op 1, addr 0x24, cmdlen 1, len 0, flags 0x00
ichiic0: exec: st 0x0
ichiic0: intr st 0x44
ichiic0: exec: op 1, addr 0x25, cmdlen 1, len 0, flags 0x00
ichiic0: exec: st 0x0
ichiic0: intr st 0x44
ichiic0: exec: op 1, addr 0x26, cmdlen 1, len 0, flags 0x00
ichiic0: exec: st 0x0
ichiic0: intr st 0x44
ichiic0: exec: op 1, addr 0x27, cmdlen 1, len 0, flags 0x00
ichiic0: exec: st 0x0
ichiic0: intr st 0x44
ichiic0: exec: op 1, addr 0x28, cmdlen 1, len 0, flags 0x00
ichiic0: exec: st 0x0
ichiic0: intr st 0x44
ichiic0: exec: op 1, addr 0x29, cmdlen 1, len 0, flags 0x00
ichiic0: exec: st 0x0
ichi
Re: PF & SMP
OpenBSD SMP is based on BigLock, so only one processor at the time can execute kernel code, and IP Stack is kernel side only. As far as I remember. regards M.K. Gustavo Rios napisaE(a): I have the same understanding you have Pachl. I believe OpenBSD IP Stack is not multithreaded implemented. A core developer could deny/confirm such belief. /all the best. On 6/30/06, Clint Pachl <[EMAIL PROTECTED]> wrote: Does PF utilize multiple processors? One of my router/firewalls is a dual Pentium Pro 200. It also runs ftp-proxy, but that's it. Would a PII 400MHz be equivalent, better, or worse? Just curious. From what I understand, the network stack is not threaded, thus multiple processors would not be beneficial. - pachl
OpenBSD Not booting on E7230 chipset
Hello, I tried to boot OpenBSD on E7230 chipset, but no luck so faar. System hangs during device recognition in random moments. Strange thing is that cursor jumps to the center of the screen. Has anyone managed to run OpenBSD on E7230 chipset ? regards M.K. [demime 1.01d removed an attachment of type application/x-pkcs7-signature which had a name of smime.p7s]
Re: 3Ware 9500S-12
Shane J Pearson napisaE(a): Hi MichaE, On 2006.02.24, at 10:24 PM, MichaE Koc wrote: can someone confirm that 3Ware 9500S-12 does or does not work with OpenBSD ? Based on what I last I heard, I think the most important point is that 3Ware the company, does not work with OpenBSD the project. Shane Yes, I know, but actually I've no choices for 12-channel sata raid ( forget about adaptec.) I've go one machine running 3Ware 7506-4LP without any problems and with great performance, but I need more. regards M.K.
3Ware 9500S-12
Hello, can someone confirm that 3Ware 9500S-12 does or does not work with OpenBSD ? I'd also appreciate any suggestion about 12-channel sata raid solutions. Regards M.K.
Re: em0 and SMP problem
Yes, the problem lies in interrupts, I've just tried xl, fxp and rl Nic's, and none of them works as em. Furthermore their interrupts are not showed in vmstat -i. It would be very helpfull if some wise guy could tell me where to look for the problem. Otherwise I'll have to go thru the kernel sources again. Thanks in advance MichaE Koc
Re: em0 and SMP problem
One more question: is ist matter of wrong irq assigment ?? em0 at pci2 dev 2 function 0 "Intel PRO/1000XT (82544EI)" rev 0x02: apic 8 int 9 (irq 9), address: 00:0e:0c:70:c9:52 em1 at pci2 dev 5 function 0 "Intel PRO/1000MT (82546EB)" rev 0x01: apic 8 int 9 (irq 9), address: 00:03:47:32:c8:ca em2 at pci2 dev 5 function 1 "Intel PRO/1000MT (82546EB)" rev 0x01: apic 8 int 9 (irq 9), address: 00:03:47:32:c8:cb everywhere thesame apic int and irq ?? is it ok ? regards MichaE Koc
Re: em0 and SMP problem 3.7 SMP DMESG and ifconfig
ok, When I run GENERIC SMP kernel, the problem persists, I'll privide You a dmesg from GENERIC.SMP tomorrow, but it does not change anytning. There are 3 changes I've made to generic: enable aac, add my aac card to aac_pci so it can be configured, add my ICU to pci_intr so it can be configured. But once again, GENERIC does not change anything. Best regards Micha3 Koc
Re: em0 and SMP problem 3.7 SMP DMESG and ifconfig
OpenBSD 3.7-stable (STORAGE.MP) #1: Sat Jul 2 21:29:32 CEST 2005
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/STORAGE.MP
cpu0: Intel(R) Xeon(TM) CPU 2.66GHz ("GenuineIntel" 686-class) 2.66 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF
real mem = 3220738048 (3145252K)
avail mem = 2931408896 (2862704K)
using 4278 buffers containing 161140736 bytes (157364K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(00) BIOS, date 12/22/04, BIOS32 rev. 0 @ 0xfdb34
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf35a0/320 (18 entries)
pcibios0: PCI Interrupt Router at 000:31:0 ("Intel 82801CA LPC" rev 0x00)
pcibios0: PCI bus #4 is the last bus
bios0: ROM list: 0xc/0x8000 0xc8000/0x4800 0xcc800/0x1000 0xcd800/0x1000
mainbus0: Intel MP Specification (Version 1.4) (INTELS7501HG0)
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 132 MHz
cpu1 at mainbus0: apid 6 (application processor)
cpu1: Intel(R) Xeon(TM) CPU 2.66GHz ("GenuineIntel" 686-class) 2.66 GHz
cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF
mainbus0: bus 0 is type PCI
mainbus0: bus 1 is type PCI
mainbus0: bus 2 is type PCI
mainbus0: bus 3 is type PCI
mainbus0: bus 4 is type PCI
mainbus0: bus 5 is type ISA
ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins
ioapic1 at mainbus0: apid 9 pa 0xfec81000, version 20, 24 pins
ioapic2 at mainbus0: apid 10 pa 0xfec81400, version 20, 24 pins
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel E7501 MCH Host" rev 0x01
"Intel E7500 DRAM" rev 0x01 at pci0 dev 0 function 1 not configured
ppb0 at pci0 dev 3 function 0 "Intel E7500 MCH HI_C vppb 1" rev 0x01
pci1 at ppb0 bus 1
"Intel P64H2 IOxAPIC" rev 0x04 at pci1 dev 28 function 0 not configured
ppb1 at pci1 dev 29 function 0 "Intel 82870P2 P64H2 PCI-PCI" rev 0x04
pci2 at ppb1 bus 2
em0 at pci2 dev 2 function 0 "Intel PRO/1000XT (82544EI)" rev 0x02: apic
8 int 9
em1 at pci2 dev 5 function 0 "Intel PRO/1000MT DP (82546EB)" rev 0x01:
apic 8 in
em2 at pci2 dev 5 function 1 "Intel PRO/1000MT DP (82546EB)" rev 0x01:
apic 8 in
"Intel P64H2 IOxAPIC" rev 0x04 at pci1 dev 30 function 0 not configured
ppb2 at pci1 dev 31 function 0 "Intel 82870P2 P64H2 PCI-PCI" rev 0x04
pci3 at ppb2 bus 3
aac0 at pci3 dev 1 function 0 "Adaptec ASR-2200S" rev 0x01: apic 9 int 4
(irq 9)
aac0: Intel GC80302 IOP 100MHz, 64MB, optional battery not installed (4)
Kernel
scsibus0 at aac0: 64 targets
sd0 at scsibus0 targ 0 lun 0: SCSI2 0/direct
fixed
sd0: 139980MB, 17845 cyl, 255 head, 63 sec, 512 bytes/sec, 286679925 sec
total
ahd0 at pci3 dev 4 function 0 "Adaptec AIC-7902 U320" rev 0x03: apic 9
int 6 (ir
aic7902: U320 Wide Channel A, SCSI Id=7, PCI 33 or 66Mhz, 512 SCBs
scsibus1 at ahd0: 16 targets
st0 at scsibus1 targ 4 lun 0: SCSI2 1/sequential
removabl
st0: density code 0x40, variable blocks, write-enabled
ahd1 at pci3 dev 4 function 1 "Adaptec AIC-7902 U320" rev 0x03: apic 9
int 7 (ir
aic7902: U320 Wide Channel B, SCSI Id=7, PCI 33 or 66Mhz, 512 SCBs
scsibus2 at ahd1: 16 targets
"Intel E7500 MCH HI_C vppb 2" rev 0x01 at pci0 dev 3 function 1 not
configured
ppb3 at pci0 dev 30 function 0 "Intel 82801BA AGP" rev 0x42
pci4 at ppb3 bus 4
vga1 at pci4 dev 12 function 0 "ATI Rage XL" rev 0x27
wsdisplay0 at vga1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ichpcib0 at pci0 dev 31 function 0 "Intel 82801CA LPC" rev 0x02
pciide0 at pci0 dev 31 function 1 "Intel 82801CA IDE" rev 0x02: DMA,
channel 0 c
atapiscsi0 at pciide0 channel 0 drive 0
scsibus3 at atapiscsi0: 2 targets
cd0 at scsibus3 targ 0 lun 0: SCSI0
5/cdrom r
cd0(pciide0:0:0): using PIO mode 4, DMA mode 2
pciide0: channel 1 disabled (no drives)
"Intel 82801CA/CAM SMBus" rev 0x02 at pci0 dev 31 function 3 not configured
isa0 at ichpcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0 (mux 1 ignored for console): console keyboard, using
wsdisplay0
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
midi0 at pcppi0:
sysbeep0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
npx0 at isa0 port 0xf0/16: using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
biomask 0 netmask 0 ttymask 0
pctr: user-level cycle counter enabled
dkcsum: sd0 matched BIOS disk 80
root on sd0a
rootdev=0x400 rrootdev=0xd00 rawdev=0xd02
em0: flags=8843 mtu 1500
address: 00:0e:0c:70:c9:52
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 10.0.5.19 netmask 0xff00 broadcast 10.0.5.255
inet6 fe80::20e:cff:fe70:c952%em0 prefixlen 64 scopeid 0x1
em1: flags=8843 mtu 1500
Re: em0 and SMP problem
Here You have dmesg from 3.6 SP before patch:
I'll provide 3.7 sp, smp, after and before patch tomorrow.
Thank You.
MichaE Koc
OpenBSD 3.6-stable (GENERIC) #0: Mon Mar 7 14:01:06 CET 2005
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Xeon(TM) CPU 2.66GHz ("GenuineIntel" 686-class) 2.66 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,CNXT-ID
real mem = 3220738048 (3145252K)
avail mem = 2931351552 (2862648K)
using 4278 buffers containing 161140736 bytes (157364K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(00) BIOS, date 12/22/04, BIOS32 rev. 0 @ 0xfdb34
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf35a0/320 (18 entries)
pcibios0: no compatible PCI ICU found: ICU vendor 0x8086 product 0x2480
pcibios0: Warning, unable to fix up PCI interrupt routing
pcibios0: PCI bus #4 is the last bus
bios0: ROM list: 0xc/0x8000 0xc8000/0x4800 0xcc800/0x1000 0xcd800/0x1000
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x254c
rev 0x01
"Intel E7500 DRAM" rev 0x01 at pci0 dev 0 function 1 not configured
ppb0 at pci0 dev 3 function 0 "Intel E7500 MCH HI_C vppb 1" rev 0x01
pci1 at ppb0 bus 1
"Intel P64H2 IOxAPIC" rev 0x04 at pci1 dev 28 function 0 not configured
ppb1 at pci1 dev 29 function 0 "Intel 82870P2 P64H2 PCI-PCI" rev 0x04
pci2 at ppb1 bus 2
em0 at pci2 dev 2 function 0 "Intel PRO/1000XT (82544EI)" rev 0x02: irq
9, address: 00:0e:0c:70:c9:52
em1 at pci2 dev 5 function 0 "Intel PRO/1000MT DP (82546EB)" rev 0x01:
irq 9, address: 00:03:47:32:c8:ca
em2 at pci2 dev 5 function 1 "Intel PRO/1000MT DP (82546EB)" rev 0x01:
irq 9, address: 00:03:47:32:c8:cb
"Intel P64H2 IOxAPIC" rev 0x04 at pci1 dev 30 function 0 not configured
ppb2 at pci1 dev 31 function 0 "Intel 82870P2 P64H2 PCI-PCI" rev 0x04
pci3 at ppb2 bus 3
aac0 at pci3 dev 1 function 0 "Adaptec ASR-2200S" rev 0x01: irq 9
aac0: Intel GC80302 IOP 100MHz, 64MB, optional battery not installed (4)
Kernel 4.2-0
scsibus0 at aac0: 64 targets
sd0 at scsibus0 targ 0 lun 0: SCSI2 0/direct
fixed
sd0: 139980MB, 17845 cyl, 255 head, 63 sec, 512 bytes/sec, 286679925 sec
total
ahd0 at pci3 dev 4 function 0 "Adaptec AIC-7902 U320" rev 0x03: irq 9
aic7902: U320 Wide Channel A, SCSI Id=7, PCI 33 or 66Mhz, 512 SCBs
scsibus1 at ahd0: 16 targets
st0 at scsibus1 targ 4 lun 0: SCSI2 1/sequential
removable
st0: density code 0x40, variable blocks, write-enabled
ahd1 at pci3 dev 4 function 1 "Adaptec AIC-7902 U320" rev 0x03: irq 9
aic7902: U320 Wide Channel B, SCSI Id=7, PCI 33 or 66Mhz, 512 SCBs
scsibus2 at ahd1: 16 targets
"Intel E7500 MCH HI_C vppb 2" rev 0x01 at pci0 dev 3 function 1 not
configured
ppb3 at pci0 dev 30 function 0 "Intel 82801BA AGP" rev 0x42
pci4 at ppb3 bus 4
vga1 at pci4 dev 12 function 0 "ATI Rage XL" rev 0x27
wsdisplay0 at vga1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ichpcib0 at pci0 dev 31 function 0 "Intel 82801CA LPC" rev 0x02
pciide0 at pci0 dev 31 function 1 "Intel 82801CA IDE" rev 0x02: DMA,
channel 0 configured to compatibility, channel 1 configured to compatibility
atapiscsi0 at pciide0 channel 0 drive 0
scsibus3 at atapiscsi0: 2 targets
cd0 at scsibus3 targ 0 lun 0: SCSI0
5/cdrom removable
cd0(pciide0:0:0): using PIO mode 4, DMA mode 2
pciide0: channel 1 disabled (no drives)
"Intel 82801CA/CAM SMBus" rev 0x02 at pci0 dev 31 function 3 not configured
isa0 at ichpcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
midi0 at pcppi0:
sysbeep0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
npx0 at isa0 port 0xf0/16: using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
biomask ef65 netmask ef65 ttymask ffe7
pctr: user-level cycle counter enabled
dkcsum: sd0 matched BIOS disk 80
root on sd0a
rootdev=0x400 rrootdev=0xd00 rawdev=0xd02
Re: em0 and SMP problem
Ok,
starting from the beginnig,
The em nics are visible in dmesg and ifconfig.
They do transmit packets as I can see in tcpdump on the destination machine.
But they do not recive any packets.
ie. I ping from SMP machine to dest
on dest I can se echo requests comming from SMP and echo replies going
to SMP.
But SMP does not recive anything back. Actually I can see replies going
to SMP on switch, but not on SMP.
The problem goes away when I disable SMP in kernel.
This looks like some issue witch device polling, maby.
What I did with ICU is:
h/i386/pci/pci_intr_fixup.c
<
Index: sys/arch/i386/pci/pci_intr_fixup.c
===
RCS file: /cvs/src/sys/arch/i386/pci/pci_intr_fixup.c,v
retrieving revision 1.36
diff -u -r1.36 pci_intr_fixup.c
--- sys/arch/i386/pci/pci_intr_fixup.c 2004/09/26 20:17:42 1.36
+++ sys/arch/i386/pci/pci_intr_fixup.c 2005/07/01 22:20:28
@@ -148,6 +148,8 @@
piix_init },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801BAM_LPC,
piix_init },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801CA_LPC,
+ piix_init },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801CAM_LPC,
piix_init },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801DB_LPC,
Thank in advance
MichaE Koc
em0 and SMP problem
Hello all,
I've a problem with em0 (and eventually any other nic connected to the
pci bus) on double Xeon, while I run smp kernel.
I have no idea what could couse it, there was problem with ICU but I've
fixed it as follows:
pcibios0: no compatible PCI ICU found: ICU vendor 0x8086 product 0x2480
pcibios0: Warning, unable to fix up PCI interrupt routing
to
pcibios0: PCI Interrupt Router at 000:31:0 ("Intel 82801CA LPC" rev 0x00)
but that did not fix em0 nic.
The motherboard is IntelB. Server Board SE7501HG2, two em0 onborad, not
working.
Bios upgrade does not change anything.
If someone could point me out where to look for the problem, I would be
extremely thankfull.
I've got 4 machines with this configuration and I hate to run freebsd on
them.
Best regards
Michal Koc
