Re: Re: reproducible kernel crash with quota

Hello everyone, I made a mistake testing the two patches. The two patches solve the problem. The kernel then no longer seems to crash. Thank you for your efforts Regards Uwe On Thu, 21 Apr 2022, J. Hannken-Illjes wrote: Date: Thu, 21 Apr 2022 14:09:03 +0200 From: J. Hannken-Illjes To:

Re: Re: reproducible kernel crash with quota

On Thu, 21 Apr 2022, J. Hannken-Illjes wrote: Date: Thu, 21 Apr 2022 14:09:03 +0200 From: J. Hannken-Illjes To: 6b...@6bone.informatik.uni-leipzig.de Cc: current-users@netbsd.org, Manuel Bouyer Subject: [Extern] Re: reproducible kernel crash with quota On 21. Apr 2022, at 00:36,

Re: Re: reproducible kernel crash with quota

On Wed, 20 Apr 2022, J. Hannken-Illjes wrote: Date: Wed, 20 Apr 2022 22:19:30 +0200 From: J. Hannken-Illjes To: 6b...@6bone.informatik.uni-leipzig.de Cc: current-users@netbsd.org, Manuel Bouyer Subject: [Extern] Re: reproducible kernel crash with quota On 20. Apr 2022, at 22:10,

Re: Re: reproducible kernel crash with quota

On Tue, 19 Apr 2022, J. Hannken-Illjes wrote: Date: Tue, 19 Apr 2022 11:07:48 +0200 From: J. Hannken-Illjes To: 6b...@6bone.informatik.uni-leipzig.de Cc: current-users@netbsd.org, Manuel Bouyer Subject: [Extern] Re: reproducible kernel crash with quota On 19. Apr 2022, at 08:38,

Re: Re: reproducible kernel crash with quota

On Thu, 14 Apr 2022, J. Hannken-Illjes wrote: Date: Thu, 14 Apr 2022 13:09:02 +0200 From: J. Hannken-Illjes To: 6b...@6bone.informatik.uni-leipzig.de Cc: current-users@netbsd.org, Manuel Bouyer Subject: [Extern] Re: reproducible kernel crash with quota On 12. Apr 2022, at 08:52,

reproducible kernel crash with quota

Hello, since I already have some open bugs with reproducible kernel crashes, I'm only writing this to the mailing list. how to reproduce the crash: /etc/rc.d/quota restart dmesg: [ 412.047595] panic: kernel diagnostic assertion "dq->dq_ump->um_quotas[dq->dq _type] != vp" failed: file

Re: Re: Crash on various Supermicro motherboards

Here is the CPU type: https://speicherwolke.uni-leipzig.de/index.php/s/SM6LQqKPqKYeCqM Regards Uwe On Thu, 7 Apr 2022, Christos Zoulas wrote: Date: Thu, 7 Apr 2022 20:36:26 - (UTC) From: Christos Zoulas To: current-users@netbsd.org Subject: [Extern] Re: Crash on various Supermicro

Re: Re: Re: Crash on various Supermicro motherboards

Hello, I now have the backtrace: https://speicherwolke.uni-leipzig.de/index.php/s/cFXAbL6axwHpKkL Thank you for your efforts Regards Uwe On Wed, 23 Mar 2022, Paul Goyette wrote: Date: Wed, 23 Mar 2022 14:19:50 -0700 (PDT) From: Paul Goyette To: 6b...@6bone.informatik.uni-leipzig.de Cc:

Re: Re: Crash on various Supermicro motherboards

On Wed, 23 Mar 2022, Paul Goyette wrote: Date: Wed, 23 Mar 2022 08:50:03 -0700 (PDT) From: Paul Goyette To: 6b...@6bone.informatik.uni-leipzig.de Cc: current-users@netbsd.org Subject: [Extern] Re: Crash on various Supermicro motherboards On Wed, 23 Mar 2022,

Crash on various Supermicro motherboards

Hello, When trying to install netbsd-current on different Supermicro servers, reproducible crashes occur. A concrete example: Serverboard: Supermicro X11DPL-i Bios Version 3.1 If the bios option "Extended APIC" is disabled, everything works as expected. If the option is activated, the

Re: Re: reproducible kernel crash with the agr interface

Hello, for me the lagg interface works perfectly. Thanks for the tip. Regards Uwe On Mon, 21 Feb 2022, Shoichi Yamaguchi wrote: Date: Mon, 21 Feb 2022 16:18:59 +0900 From: Shoichi Yamaguchi To: 6b...@6bone.informatik.uni-leipzig.de Cc: current-users@netbsd.org Subject: [Extern] Re:

reproducible kernel crash with the agr interface

Hello, I have a system with bnx and wm interfaces. When I try the following the kernel crashes. ifconfig agr0 create ifconfig agr0 agrport wm1 ifconfig agr0 -agrport wm1 ifconfig agr0 agrport bnx1 ->dump [ 22261.159501] panic: kernel diagnostic assertion "ifp->if_hwdl == NULL" failed: file

Re: Re: Re: Bug or no Bug?

Hello, Since the server doesn't have an Nvidia graphics card, I tried to find another cause. In my case the problem seems to occur when starting the bnx* network interface. If LOCKDEBUG is enabled in the kernel, the kernel crashes when the bnx* network card is activated. With LOCKDEBUG and

Re: Re: Bug or no Bug?

Hello, the kernel crashes during the boot process after enabling the network. At this point no dump files have been written. As first step I have created a clip from the crash: https://speicherwolke.uni-leipzig.de/index.php/s/jFpEa5TAnJAmEcF As soon as I get a usable crashfile I will make

Bug or no Bug?

Hello, I have installed the 9.99.xx kernel on several systems. On most systems there are no problems. On a Dell 2800, the kernel crashes during boot. The problem only occurs if the option LOCKDEBUG is set. options LOCKDEBUG # expensive locking checks/support Should a bug

crash at MegaRAID SAS 9341-8i

Hi there, could someone take a look at the kern/56669 issue? I tested different kernels on different days. The problem can be reproduced in a short time. An SSD is also installed in the server. If you only work on the SSD (no MegaRAID) the problem does not occur. So I suspect there is a

Re: Re: netbsd-9.99.93 crash

On Sat, 22 Jan 2022, Martin Husemann wrote: Date: Sat, 22 Jan 2022 08:36:22 + From: Martin Husemann To: Christos Zoulas Cc: current-users@netbsd.org Subject: [Extern] Re: netbsd-9.99.93 crash On Mon, Jan 10, 2022 at 10:18:02PM -, Christos Zoulas wrote: In article ,

Re: Re: netbsd-9.99.93 crash

Hello, I think the problem is not fixed yet. At the moment I can't boot my server to test. Regards Uwe On Sat, 22 Jan 2022, Martin Husemann wrote: Date: Sat, 22 Jan 2022 08:36:22 + From: Martin Husemann To: Christos Zoulas Cc: current-users@netbsd.org Subject: [Extern] Re:

Re: Re: netbsd-9.99.93 crash

Does that help? Regards Uwe (gdb) list *(0x80ea0a90) 0x80ea0a90 is in doifioctl (/usr/src/sys/net/if.c:3494). 3489} 3490} 3491 3492oif_flags = ifp->if_flags; 3493 3494KERNEL_LOCK_UNLESS_IFP_MPSAFE(ifp); 3495

netbsd-9.99.93 crash

Hi there, when starting the network the kernel crashes. Does anyone have an idea what the problem could be? Thank you for your efforts Regards Uwe dmesg -M netbsd.14.core -N netbsd.14 ... [28.382481] boot device: sd0 [28.382481] root on sd0a dumps on sd0b [28.382481]

NetBSD 9.0 RC1 compile error

Hello, with enabled DEBUG: --- if_ena.o --- /usr/src/sys/dev/pci/if_ena.c: In function 'ena_request_io_irq': /usr/src/sys/dev/pci/if_ena.c:2089:7: error: unused variable 'irq_slot' [-Werror=unused-variable] int irq_slot = i + irq_off; ^~~~ Regards Uwe

Intel XXV710-DA2 / ixl

Hi, I have a server with an INTEL XXV710-DA2 network card. Unfortunately, NetBSD does not support this card. On the mailing list I read that other users have asked for support for this card. Would anyone be able to port the ixl driver from FreeBSD? I could offer access to an unused server

support for Intel NIC

Hello, is it planed to add the support for Intel NIC XXV710-DA2 (vendor 8086, product 0x158b)? Thank you for your efforts Regards Uwe

Network questions

Hello, We run a NetBSD router for our network. The router has two Layer 3 uplinks (quagga / ospf) to the provider. The router also has two Layer-3 links (quagga / ospf) to the Datacenter. The provider offers us two lines (active / active). Unfortunately we can not use them in upstream

Re: netbsd-8 crash

On Sun, 5 Aug 2018, Christos Zoulas wrote: Also, are there other print messages on the console? The dump is written automatically. Messages on the console are lost. Since it's a productive server, I can not change the behavior. The server must be available again as soon as possible after a

Re: netbsd-8 crash

On Sat, 4 Aug 2018, Martin Husemann wrote: Looks like a bug in the ciss driver. /* if never got a chance to be done above... */ if (ccb->ccb_state != CISS_CCB_FREE) { KASSERT(error); ccb->ccb_err.cmd_stat =

netbsd-8 crash

Hello, With high CPU load netbsd-8 crashes from time to time. The crashinfo is not written correctly in every case. Eg crashinfo 8. -rw--- 1 root wheel 614974272 Aug 3 08:59 netbsd.8.core.gz -rw--- 1 root wheel 0 Aug 3 08:59 netbsd.8.gz -rw--- 1 root wheel

Re: ixg tester needed (was Re: Problems with netbsd-8 RC1 and ixg drivers (?))

Hello, I have applied http://www.netbsd.org/~msaitoh/ixgbe-eitr-20180522-0.dif and http://www.netbsd.org/~msaitoh/ixgbe-norearm-20180530-0.dif to netbsd-8 RC1. With these patches the problem seems to be solved. Thank you for your efforts Regards Uwe On Fri, 1 Jun 2018,

Re: ixg tester needed (was Re: Problems with netbsd-8 RC1 and ixg drivers (?))

Hello, I have tested the the patch with netbsd-8. The problem is not solved. Regards Uwe On Mon, 28 May 2018, Masanobu SAITOH wrote: Date: Mon, 28 May 2018 17:10:02 +0900 From: Masanobu SAITOH To: Martin Husemann , 6b...@6bone.informatik.uni-leipzig.de, current-users@netbsd.org Cc:

Problems with netbsd-8 RC1 and ixg drivers (?)

Hello, At the weekend I tried to update to a current version of netbsd-8 rc1. After the restart, the kernel will work for a few hours. After that, no packets will arrive at the network card. The server is running normally. No hints in dmesg. Some network programs report issues: zebra[371]:

Re: nfs client issue at netbsd-8

On Wed, 28 Mar 2018, Manuel Bouyer wrote: On Wed, Mar 28, 2018 at 06:23:56PM +0200, 6b...@6bone.informatik.uni-leipzig.de wrote: I changed from 1.88.2.10 to 1.88.2.13. The problem was not solved. I have also tested the onboeard network card. After a few hours, the problem also occurred here.

Re: nfs client issue at netbsd-8

On Fri, 23 Mar 2018, SAITOH Masanobu wrote: How old is your kernel? If your kernel's ixgbe.c is older than 1.88.2.13 please update the latest netbsd-8 and try. 1.88.2.13 (and 1.88.2.10) fixed serious interrupt problem. I changed from 1.88.2.10 to 1.88.2.13. The problem was not solved. I

Re: nfs client issue at netbsd-8

On Tue, 20 Mar 2018, Martin Husemann wrote: Which network driver is used on the client? ixg0 at pci8 dev 0 function 0: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 3.2.12-k ixg0: device 82599EB ixg0: ETrackID 830d ixg0: for TX/RX, interrupting at msix0 vec 0, bound queue 0

nfs client issue at netbsd-8

Hello, I have problems with the nfs-client under netbsd-8. In principle, the nfs works. Some time after an nfs share is mounted, there are network breaks on the client. The following ping from the outside on the client shows the phenomenon. ... 64 bytes from 139.18.xx.yy: icmp_seq=6496

NetBSD 8.0_BETA / snmpd

Hello, I'm running NetBSD 8.0_BETA with the kernel from the end of August. There's no problem. Today I compiled the 8.0_BETA kernel from the current CVS resources. The kernel is running, but the snmpd does not work anymore. The snmpd process is running, netstat shows a listen on port 161.

Re: netbsd-8 crash in ixg driver during booting

On Thu, 16 Nov 2017, Masanobu SAITOH wrote: This problem is different from ixg(4)'s problem. I'll now working to fix this softint related problem. This problem is caused by some devices which uses a lot of softint, could you tell me the machine's spec? e.g.: number of port of wm(4)

Re: netbsd-8 crash in ixg driver during booting

Does your machine boot with the latest -current? I have tested the current sources from tonignt. https://suse.uni-leipzig.de/crash/crash-current1.jpg https://suse.uni-leipzig.de/crash/crash-current2.jpg Regards Uwe

Re: netbsd-8 crash in ixg driver during booting

On Sun, 12 Nov 2017, SAITOH Masanobu wrote: Hello, I checked out the current-cvs-source from this morning. I can't compile it because of an error: --- streambuf-inst.o --- # compile libstdc++-v3/streambuf-inst.o /usr/src/obj/tooldir.NetBSD-8.0_BETA-amd64/bin/x86_64--netbsd-c++

netbsd-8 crash in ixg driver during booting

the current version of netbsd-8 crashes while booting during the initialization of the network driver. https://suse.uni-leipzig.de/crash/crash1.jpg https://suse.uni-leipzig.de/crash/crash2.jpg https://suse.uni-leipzig.de/crash/crash3.jpg My old kernel from August 2017 did not have the problem

Re: problems with vlan interface counters (NetBSD 8.0_BETA)

Hello, I was not in the office for three weeks and can only answer today. I have tested the netbsd-8 sources of yesterday. The problem is solved. Thank you for your efforts Regards Uwe On Wed, 9 Aug 2017, Kengo NAKAHARA wrote: Date: Wed, 9 Aug 2017 15:36:15 +0900 From: Kengo NAKAHARA

problems with vlan interface counters (NetBSD 8.0_BETA)

Hello, The interface counters of vlan interface do not count: bash-4.4# ifconfig -v vlan8 vlan8: flags=0x8843 mtu 1500 capabilities=7ff80

bad counter for ixg* interfaces

Hello, ifconfig -v ixg0 shows: ixg0: flags=8843 mtu 1500 capabilities=fff80 capabilities=fff80

Re: npf bug(?)

On Mon, 10 Apr 2017, Christos Zoulas wrote: Npf just calls "error = ip_reass_packet(mp, ip)" and if that fails it increments NPF_STAT_REASSFAIL. Since it uses the same exact call the regular ip stack uses, I would expect that: NPF_STAT_REASSFAIL = IP_STAT_BADFRAGS + IP_STAT_RCVMEMDROP;

Re: npf bug(?)

On Sun, 9 Apr 2017, Christos Zoulas wrote: Perhaps you get a lot of dup fragments? netstat -s should show you the stack's reassembly and fragment stats. Perhaps those agree with what npf shows? Currently the patch is active. That's why I have no npf statistics. The netstat statistics seem to

Re: npf bug(?)

On Thu, 6 Apr 2017, Christos Zoulas wrote: | Thanks for the patch. For me it works very well. Well, the question is do you need it? I.e. why don't you let the v4 traffic flow through npf? Is it a performance issue or doesn't npf do reassembly correctly? I'm not sure if the reassembling

Re: npf bug(?)

On Mon, 3 Apr 2017, Christos Zoulas wrote: Here's a rough patch that kills v4 processing. christos Thanks for the patch. For me it works very well. Is this a special solution just for me or will the patch be part of the current kernel. Regards Uwe

Re: npf bug(?)

On Sun, 2 Apr 2017, Christos Zoulas wrote: I am trying to understand the use case here: 1. you want to have V4 DNS and 6to4 service that can generate V4 fragments 2. you want V4 fragments dropped. 3. you can't put V4 rules in your firewall to restrict traffic to only those services. Is that

Re: reproducible kernel crash in NetBSD 7.1_RC1

On Mon, 23 Jan 2017, Christos Zoulas wrote: Date: Mon, 23 Jan 2017 19:35:06 + (UTC) From: Christos Zoulas To: current-users@netbsd.org Subject: Re: reproducible kernel crash in NetBSD 7.1_RC1 I think that the vlan creation/removal code is racy even under /current.

Re: configure vlan-if jumbo mtu crashs kernel

On Fri, 18 Nov 2016, Joerg Sonnenberger wrote: Date: Fri, 18 Nov 2016 16:26:49 +0100 From: Joerg Sonnenberger To: current-users@netbsd.org Subject: Re: configure vlan-if jumbo mtu crashs kernel On Fri, Nov 18, 2016 at 02:35:03PM +0100, 6b...@6bone.informatik.uni-leipzig.de

configure vlan-if jumbo mtu crashs kernel

hello, in some networks we are working with jumbo mtu's. If I configure the mtu to the native interface all works fine. ifconfig ixg1 mtu 9000 (no problem) but ifconfig vlan850 ip4csum tcp4csum udp4csum tcp6csum udp6csum ip4csum-tx ip4csum-rx tcp4csum-tx tcp4csum-rx udp4csum-tx udp4csum-rx

multipath fibre channel

Hello, I want to configure multipath for a fibre channel storage. I need only the availability, not the performance. For netbsd I have not found any documentation on this subject. Is multipath possible for FC storages? If not, it is possible / useful fo use a software raid1 over both paths?

Re: nfs client kernel crash

On Fri, 17 Jun 2016, Christos Zoulas wrote: | I am mounting with: nosuid,userquota,rw,tcp,soft,intr | | Is this a problem? Yes :-), I'd get rid of "soft" first. christos I changed the nfs options to: userquota,nosuid,rw,tcp,bg The message is still there. Regards Uwe

Re: nfs client kernel crash

On Tue, 14 Jun 2016, Christos Zoulas wrote: On Jun 14, 2:07pm, 6b...@6bone.informatik.uni-leipzig.de (6b...@6bone.informatik.uni-leipzig.de) wrote: -- Subject: Re: nfs client kernel crash | On Tue, 14 Jun 2016, Christos Zoulas wrote: | | > Yes, that helps. No crash though? | | So far, no

Re: nfs client kernel crash

On Tue, 14 Jun 2016, Christos Zoulas wrote: Yes, that helps. No crash though? So far, no crash. But this often takes several days. Uwe

Re: nfs client kernel crash

On Tue, 14 Jun 2016, 6b...@6bone.informatik.uni-leipzig.de wrote: I applied the patch. For testing I have started a "rm -rf" on a large directory tree. dmesg reports: nfs server 172.18.86.13:/vol/vol_bsd_2: is alive again nfs server 172.18.86.13:/vol/vol_bsd_2: not responding nfs server

Re: nfs client kernel crash

On Mon, 13 Jun 2016, Christos Zoulas wrote: Can you try this? The first one might not apply cleanly since I changed the loop, but it should work just the same if you put the spl stuff around the old loop. I applied the patch. For testing I have started a "rm -rf" on a large directory tree.

Re: nfs client kernel crash

On Sat, 4 Jun 2016, Christos Zoulas wrote: | The PR/50432 may describe the same problem. Thanks! christos A few weeks ago I changed the storage of our netbsd mirror to nfs. Since the change, the mirror crashes regularly. There are also other problems with the nfs. So the mirror is not

Re: nfs client kernel crash

On Thu, 2 Jun 2016, Christos Zoulas wrote: | The PR is for netbsd-5 and is some years old. Do it make sense to create a | new bug report for netbsd-7? Sure, and close 40491 saying superceded by the new one. I have opened a new bug-report (kern/51215). The PR kern/40491 is already closed.

Re: nfs client kernel crash

On Thu, 2 Jun 2016, Christos Zoulas wrote: Date: Thu, 2 Jun 2016 00:07:48 + (UTC) From: Christos Zoulas To: current-users@netbsd.org Subject: Re: nfs client kernel crash In article ,

nfs client kernel crash

hello in rare cases, under high load the nfs client crashs: 0x8068630f in cpu_reboot (howto=howto@entry=260, bootstr=bootstr@entry=0x0) at /usr/src/sys/arch/amd64/amd64/machdep.c:671 671 dumpsys(); (gdb) bt #0 0x8068630f in cpu_reboot

Re: high cpu load with tcpdump

On Mon, 29 Feb 2016, Christos Zoulas wrote: This tcpdump ktrace is when bind is running, right? What happens if you stop it? How does the ktrace look then? Or once you start bind, tcpdump goes nuts and stays that way? You're right. When tcpdump is started after the bind, tcpdump caused

Re: high cpu load with tcpdump

On Mon, 29 Feb 2016, Christos Zoulas wrote: | Hello, | | the problem occurs only on one of my servers. I tried to find the | difference. It is the bind9 (bind-9.10.3pl3). If I stop the bind9, tcpdump | works without problems. When I restart the bind9, the CPU load goes back | to 100%. | | Is it

Re: high cpu load with tcpdump

On Sat, 27 Feb 2016, 6b...@6bone.informatik.uni-leipzig.de wrote: Date: Sat, 27 Feb 2016 23:52:24 +0100 (CET) From: 6b...@6bone.informatik.uni-leipzig.de To: Joerg Sonnenberger Cc: current-users@netbsd.org Subject: Re: high cpu load with tcpdump On Sat, 27 Feb 2016,

Re: high cpu load with tcpdump

On Sat, 27 Feb 2016, Joerg Sonnenberger wrote: fstat should tell you what the file descriptor is, I just want to identify what device seems to have the trouble. You're right. USER CMD PID FD MOUNT INUM MODE SZ|DV R/W _tcpdump tcpdump 823 root /

Re: high cpu load with tcpdump

On Sat, 27 Feb 2016, Joerg Sonnenberger wrote: Date: Sat, 27 Feb 2016 20:38:37 +0100 From: Joerg Sonnenberger To: current-users@netbsd.org Subject: Re: high cpu load with tcpdump On Sat, Feb 27, 2016 at 08:18:41PM +0100, 6b...@6bone.informatik.uni-leipzig.de wrote:

Re: high cpu load with tcpdump

On Fri, 26 Feb 2016, Christos Zoulas wrote: Date: Fri, 26 Feb 2016 14:52:46 + (UTC) From: Christos Zoulas To: current-users@netbsd.org Subject: Re: high cpu load with tcpdump In article ,

high cpu load with tcpdump

Hello, On my router tcpdump uses always 100% CPU. PID USERNAME PRI NICE SIZE RES STATE TIME WCPUCPU COMMAND 3403 _tcpdump 38019M 3016K RUN/6 0:24 98.08% 70.02% tcpdump 0 root 00 0K 1182M CPU/7 49:35 0.00% 3.76% [system] The problem also

Re: nfs client and quota

On Mon, 25 Jan 2016, Manuel Bouyer wrote: Date: Mon, 25 Jan 2016 15:28:49 +0100 From: Manuel Bouyer To: 6b...@6bone.informatik.uni-leipzig.de Cc: current-users@netbsd.org Subject: Re: nfs client and quota On Mon, Jan 25, 2016 at 02:57:08PM +0100,

Re: nfs client and quota

Where can I find the file getnfsquota.c? "find /usr/src/ -name getnfsquota.c -type f" reports no result. Regards Uwe On Tue, 19 Jan 2016, Manuel Bouyer wrote: Date: Tue, 19 Jan 2016 09:29:34 +0100 From: Manuel Bouyer To: 6b...@6bone.informatik.uni-leipzig.de Cc:

Re: nfs client and quota

On Tue, 19 Jan 2016, Manuel Bouyer wrote: Date: Tue, 19 Jan 2016 09:01:10 +0100 From: Manuel Bouyer To: 6b...@6bone.informatik.uni-leipzig.de Cc: current-users@netbsd.org Subject: Re: nfs client and quota On Tue, Jan 19, 2016 at 08:23:37AM +0100,

nfs client and quota

hello, I am trying to display the quota on a nfs client. The nfs server is a Netapp. With a Linux client all works fine. NetBSD-7 does not show anything. At boot time the nfs client starts the following services: rpcbind=YES nfs_client=YES lockd=YES statd=YES There is no firewall running.

netbsd-7 crash

hello, my NetBSD routers today crashed after about 3 months update. To me it looks like an error in the network code. Maybe someone can see something more accurate in the dump. If more information is needed, I have the crashdump and the kernel with debug information. Regards Uwe

Re: agr issue in netbsd-7

On Wed, 19 Aug 2015, Havard Eidnes wrote: In the meantime, perhaps someone of you could file a PR? (so this doesn't get lost in the archives...) Done, PR#50155. Regards, - Håvard Hello, is there a possibility that the problem will be solved in the near future? The workaround described

Re: netbsd-7 quota issue

On Fri, 11 Dec 2015, Manuel Bouyer wrote: On Fri, Dec 11, 2015 at 03:15:06PM +0100, 6b...@6bone.informatik.uni-leipzig.de wrote: I'am trying to activate quota on a NetBSD-7 system, but the startup script returns an exit code of 1. [running /etc/rc.d/quota] Checking quotas: done.

agr issue in netbsd-7

hello, I tried to configure a port channel (agr0). When I configure the port channel only with bnx0 or only with bnx1 everything works. If I use bnx0 and bnx1, the Cisco switch sets one of the two links to suspended mode. bnx0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500

Re: question to stf interface (current)

On Sun, 31 May 2015, Christos Zoulas wrote: Let's keep monitoring it, and perhaps we can run a tcpdump to capture the exact packet and see what it contains... It took some time, but now I, I identified the packets. Responses to DNS requests generate error messages. There are only DNS

Re: question to stf interface (current)

On Thu, 28 May 2015, Christos Zoulas wrote: Date: Thu, 28 May 2015 09:30:10 -0400 From: Christos Zoulas chris...@zoulas.com To: 6b...@6bone.informatik.uni-leipzig.de Cc: current-users@netbsd.org Subject: Re: question to stf interface (current) On May 28, 3:13pm,

question to stf interface (current)

Hello, I provide an 6to4 router and use the stf interface. ifconfig stf0 stf0: flags=1UP mtu 1280 inet6 2002:8b12:1921:: prefixlen 16 dmesg now reports regularly errors. For example, nd6_storelladdr: bad gateway address type inet6: 2002:8b12:1921:: for dst

Kernel RNG ???

Hello, dmesg reported: Kernel RNG 2105 0 2 runs test FAILURE: too many runs of 3 1s (728 723) cprng 2105 0 2: failed statistical RNG test Any ideas what could be the problem? kernel version: NetBSD 7.99.9 distribution: netbsd-7 (version May 11) Regards Uwe

Re: current status of ixg(4)

On Tue, 7 Apr 2015, Justin Cormack wrote: Try the sysctls, there is a maximum interrupt rate, hw.ixgbe.max_interrupt_rate Justin Sure that the value exists at netbsd? # sysctl -a | grep ixg0 net.interfaces.ixg0.sndq.len = 0 net.interfaces.ixg0.sndq.maxlen = 2046

Re: current status of ixg(4)

On Wed, 8 Apr 2015, SAITOH Masanobu wrote: Use new one: http://www.netbsd.org/~msaitoh/ixg-20150407-1.dif After a first test, it looks as if the interrupt throttling now works (better). Regards Uwe

Re: current status of ixg(4)

On Fri, 27 Mar 2015, Masanobu SAITOH wrote: This change have commited now. New patch: http://www.netbsd.org/~msaitoh/ixg-20150327-0.dif I have tested the patch and found no problems. My server (HP G5) can handle with the new driver package rates up to 200,000 packets per second.

Re: current status of ixg(4)

On Wed, 25 Mar 2015, SAITOH Masanobu wrote: Did you really applied this patch? Upps... I tried to apply the patch against the -current sources where I have applied http://www.netbsd.org/~msaitoh/ixg-20150321-0.dif before # patch vlan.patch Hmm... Looks like a unified diff to me... The

Re: current status of ixg(4)

On Mon, 23 Mar 2015, Masanobu SAITOH wrote: Is this problem filed PR? If not, could you file a PR? Could you test with this patch? The path dosn't solve the problem. Here the requested information: HW: 023:00:0: Intel 82599 (SFP+) 10 GbE Controller (ethernet network, revision 0x01)

Re: current status of ixg(4)

On Fri, 20 Mar 2015, Masanobu SAITOH wrote: Date: Fri, 20 Mar 2015 17:38:03 +0900 From: Masanobu SAITOH msai...@execsw.org To: current-users@NetBSD.org Cc: msai...@execsw.org Subject: current status of ixg(4) Hello. Yesterday, I commited some changes to ixg(4) on -current.

Re: current status of ixg(4)

On Sat, 21 Mar 2015, SAITOH Masanobu wrote: New patch: http://www.netbsd.org/~msaitoh/ixg-20150321-0.dif Could you try with this patch again? Now the patch works, but I found a problem with vlan interfaces. You can create a vlan interface with: ifconfig vlan8 create ifconfig vlan8

Re: DoS attack against TCP services

On Fri, 13 Feb 2015, Christos Zoulas wrote: I tried adding show callout to crash(8) but it is not useful because the pointers move too quickly. OTOH, next time this happens you can enter ddb on your machine and type show callout and see if that sheds any light to the expired and not fired

Re: DoS attack against TCP services

On Sat, 28 Feb 2015, J. Hannken-Illjes wrote: This one looks bad. Which thread holds proc_lock? Helps this? https://www.ipv6.uni-leipzig.de/proc_lock.png Regards Uwe

Re: DoS attack against TCP services

On Sat, 28 Feb 2015, Christos Zoulas wrote: Yes, that's a good start but we need to find which process that lwp belongs to. I'm not sure what the best course of action is. The machine is still running. Should you try to get the information from the current system or force a dump and analyze

Re: DoS attack against TCP services

On Sat, 28 Feb 2015, Christos Zoulas wrote: Good idea. You can use crash, ps and see what each process is holding... christos Here the output from crash and ps gate# crash Crash version 7.0_BETA, image version 7.99.5. WARNING: versions differ, you may not be able to examine this image.

intel nic (ixgbe driver) and vlan interfaces

Hello, I use an Intel 10GbE card with ixgbe driver. My configuration is as follows: cat ifconfig.ixg0 up cat ifconfig.vlan103 create vlan 103 vlanif ixg0 up The following settings in rc.conf work without problems: cat /etc/rc.conf ... auto_ifconfig=NO net_interfaces=vlan103 ixg0 With

Re: DoS attack against TCP services

On Wed, 4 Feb 2015, Sverre Froyen wrote: I'd also look at the open descriptors of the named process (although they should be closed at this time, since TIME_WAIT means closed on this side, and waiting for the 4 minutes to expire before killing the connection)... Also I'd record that

Re: DoS attack against TCP services

On Fri, 6 Feb 2015, Robert Elz wrote: What's more, it seems peculiar to your system, as no-one else seems to be reporting similar problems. So I'd be investigating how the timers are working (or are not working) in the kernel - perhaps even try selecting a different timer. Just to make

Re: DoS attack against TCP services

On Sat, 7 Feb 2015, Greg Troxel wrote: I don't know; I will take look, but in this case the connections are initiated by the inflicted system. And so far we don't have any traces showing packets that look like attacks. There must be no attack, yes. However, it is described that the attack

Re: DoS attack against TCP services

On Fri, 6 Feb 2015, Robert Elz wrote: I assume that time (as seen from user processes) is functioning correctly? ndp -a shows: ... 2001:638:902:2000:290:f5ff:fe39:3815 00:90:f5:39:38:15 vlan14 23h27m30s S 2001:638:902:2000:565:50de:c658:60cc 90:b1:1c:a6:b5:99 vlan14 expired R

Re: DoS attack against TCP services

On Fri, 6 Feb 2015, Robert Elz wrote: What's more, it seems peculiar to your system, as no-one else seems to be reporting similar problems. So I'd be investigating how the timers are working (or are not working) in the kernel - perhaps even try selecting a different timer. I wonder also

Re: DoS attack against TCP services

Yes, I am sure that the most TIME_WAIT connections stay forever. I cannot say for sure that no TIME_WAIT connection is removed. But I can say, that some example connections have been existing for more than 5 hours. Regards Uwe On Wed, 4 Feb 2015, Johnny Billquist wrote: Date: Wed, 04 Feb

Re: DoS attack against TCP services

Now the server has over 5000 TIME_WAIT connections. netstat -a -n | grep TIME_WAIT tcp0 0 139.18.25.33.59256 198.6.1.83.53 TIME_WAIT tcp0 0 139.18.25.33.59257 77.222.50.250.53 TIME_WAIT tcp0 0 139.18.25.33.59258

Re: DoS attack against TCP services

Hello, The problem occurred again. The kernel has over 3,000 connections in TIME_WAIT state. The compounds are after an hour wait not disappeared. There are more and more connections in the TIME_WAIT state. My settings are: net.inet.tcp.mslt.enable = 1 net.inet.tcp.mslt.loopback = 2

Re: DoS attack against TCP services

On Mon, 19 Jan 2015, Michael van Elst wrote: Date: Mon, 19 Jan 2015 09:24:02 + (UTC) From: Michael van Elst mlel...@serpens.de To: current-users@netbsd.org Newsgroups: lists.netbsd.current-users Subject: Re: DoS attack against TCP services 6b...@6bone.informatik.uni-leipzig.de writes:

  1   2   >