Re: Removing IPv6 address causes all IPv6 traffic to stop working
The routes are not affected. the strangest thing I find that the host and jails are accessible from outside, and it can reach outside hosts via v6, but everything that's staying on the server fails. Alan Somers wrote: > How did you assign the jails' IPv6 addresses in the first place? The usual > way is to assign them as /128 aliases, in which case the command to remove > them would include a "/128", not "/48". I think when you're deleting a > "/48" you're also removing some routes that the jail host is using. > -Alan > > On Thu, Jul 12, 2018 at 4:30 PM, Frank de Bot (lists) > wrote: > >> On a older server running FreeBSD 10.2 i have a number of jails. For >> migration to FreeBSD I'm planning to shutdown the jail, move the data to >> the new server and spin up the jail there. IP addresses are alse moved. >> >> When I remove an IPv6 address with the following command 'ifconfig em0 >> inet6 v6address/48 delete', all IPv6 traffic on the server stops >> working. I can reach IPv6 from outside to the server and from the server >> to outside, but everything on the server (jail to jail for example) >> immediatly stops working. IPv4 works normally >> Unfortunately it's not feasible to bing-bang migrate everything, >> ignoring ipv6 is not possible because a lot of the jails interact with >> each other with ipv6 (some even exclusivly) >> >> What can cause this? >> >> >> Regards, >> >> Frank de Bot >> ___ >> freebsd-stable@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >> > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Removing IPv6 address causes all IPv6 traffic to stop working
On a older server running FreeBSD 10.2 i have a number of jails. For migration to FreeBSD I'm planning to shutdown the jail, move the data to the new server and spin up the jail there. IP addresses are alse moved. When I remove an IPv6 address with the following command 'ifconfig em0 inet6 v6address/48 delete', all IPv6 traffic on the server stops working. I can reach IPv6 from outside to the server and from the server to outside, but everything on the server (jail to jail for example) immediatly stops working. IPv4 works normally Unfortunately it's not feasible to bing-bang migrate everything, ignoring ipv6 is not possible because a lot of the jails interact with each other with ipv6 (some even exclusivly) What can cause this? Regards, Frank de Bot ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Only 1 initiator per target
Hi, Is it possible to limit the number of initiators connected to a target to 1 besides the 'initiator-name' config on the target? All servers should be able to connect, but for safety I want to prevent a second initiator from connecting to that target. A single iniator should be able to connect several times if they use multi-path. Regards, Frank de Bot ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Reloading iscsi target, iscsi initiator panics
Frank de Bot wrote:
> Edward Tomasz Napierała wrote:
>> On 1015T2005, Frank de Bot (lists) wrote:
>>> Edward Tomasz Napierała wrote:
>>>> On 1014T2316, Frank de Bot (lists) wrote:
>>>>> Hello,
>>>>>
>>>>> I have a FreeBSD 10.2 server running as iSCSI target. Another FreeBSD
>>>>> 10.2 is an initiator and has several targets used.
>>>>>
>>>>> When I add a target and reload its config with 'service ctld reload',
>>>>> the FreeBSD initiator server panics. It's reproducable (I have a
>>>>> coredump, but I think it's clear what the problem is)
>>>>
>>>> How easy it is to reproduce, eg. does it happen about every time?
>>>> Could you paste the backtrace?
>>>
>>> The first time I didn't understand what happened, the second time I
>>> could relate it directly to the reloading of ctld on the iSCSI, within
>>> moments the server paniced.
>>>
>>> I got 2 backtraces:
>>>
>>> First one:
>>>
>>> Fatal trap 12: page fault while in kernel mode
>>> cpuid = 1; softdep_deallocate_dependencies: got error 6 while accessing
>>
>> This is the FFS on the initiator side panicing because the device it's
>> on went away. The softupdates code can't handle that very well.
>>
>> I have no idea why the devices went away and then reappeared, as visible
>> in the logs. What has the changed in the ctl.conf? Do you have any
>> iscsi-related sysctls set on the initiator side?
>>
>
> I've added a new target in the ctl.conf . On the linux server I also see
> a brief disconnect, but a reconnect is handled well.
>
> I haven't set any sysctl's related to iscsi
>
> My ctl.conf is (again anonymized):
>
> auth-group my-auth {
> chap "myiscsi" "verysecret"
> }
> portal-group pg0 {
> discovery-auth-group my-auth
> listen 10.13.37.2
> }
>
> target iqn.2015-03.lan.my.nas:vmstorage-29 {
> auth-group my-auth
> portal-group pg0
> lun 0 {
> path /tank/images/iscsi/vmstorage-29/vmstorage-29.img
> size 20484M
> blocksize 4096
> option unmap on
> }
> }
>
> target iqn.2015-03.lan.my.nas:vmstorage-44 {
> auth-group my-auth
> portal-group pg0
> lun 0 {
> path /tank/images/iscsi/vmstorage-44/vmstorage-44.img
> size 102404M
> blocksize 4096
> option unmap on
> }
> }
>
> target iqn.2015-03.lan.my.nas:keyserver.my.nl {
> auth-group my-auth
> portal-group pg0
> lun 0 {
> path /dev/zvol/tank/hosting_images/keyserver.my.nl
> blocksize 4096
> option unmap on
> }
> }
>
> the vmstorage-44 is last added to the config
>
I've started up my test environment, but I could not reproduce is there.
When reloading the target, a
SCSI sense: UNIT ATTENTION asc:3f,e (Reported LUNs data has changed) is
reported, but no device is destroyed. All servers are running the same
kernel and userland 10.2-RELEASE FreeBSD 10.2-RELEASE #0 r28
What can those device disconnects cause?
>
>
>> ___
>> freebsd-stable@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>>
>
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Reloading iscsi target, iscsi initiator panics
Edward Tomasz Napierała wrote: > On 1014T2316, Frank de Bot (lists) wrote: >> Hello, >> >> I have a FreeBSD 10.2 server running as iSCSI target. Another FreeBSD >> 10.2 is an initiator and has several targets used. >> >> When I add a target and reload its config with 'service ctld reload', >> the FreeBSD initiator server panics. It's reproducable (I have a >> coredump, but I think it's clear what the problem is) > > How easy it is to reproduce, eg. does it happen about every time? > Could you paste the backtrace? The first time I didn't understand what happened, the second time I could relate it directly to the reloading of ctld on the iSCSI, within moments the server paniced. I got 2 backtraces: First one: Fatal trap 12: page fault while in kernel mode cpuid = 1; softdep_deallocate_dependencies: got error 6 while accessing filesystem apic id = 01 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0x808a86b5 stack pointer = 0x28:0xfe023b5f1200 frame pointer = 0x28:0xfe023b5f1260 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 42663 (php) trap number = 12 panic: page fault cpuid = 1 KDB: stack backtrace: #0 0x80984e30 at kdb_backtrace+0x60 #1 0x809489e6 at vpanic+0x126 #2 0x809488b3 at panic+0x43 #3 0x80d4aadb at trap_fatal+0x36b #4 0x80d4addd at trap_pfault+0x2ed #5 0x80d4a47a at trap+0x47a #6 0x80d307f2 at calltrap+0x8 #7 0x80b73208 at ffs_blkfree+0x168 #8 0x80b8c747 at handle_workitem_freefrag+0x127 #9 0x80b73e28 at ffs_reallocblks+0xc08 #10 0x80e74117 at VOP_REALLOCBLKS_APV+0xa7 #11 0x809da65b at cluster_write+0x3eb #12 0x80ba4dcb at ffs_write+0x45b #13 0x80e72495 at VOP_WRITE_APV+0x145 #14 0x809fc3f9 at vn_write+0x259 #15 0x809fc632 at vn_io_fault_doio+0x22 #16 0x809fa17c at vn_io_fault1+0x7c #17 0x809f864b at vn_io_fault+0x18b Uptime: 16d1h28m10s (da3:iscsi10:0:0:0): Synchronize cache failed Dumping 1154 out of 8163 MB:..2%..12%..21%..31%..41%..52%..61%..71%..81%..91% Second: Device resolver went missing before all of the data could be written to it; expect data loss. /dev: got error 6 while accessing filesystem panic: softdep_deallocate_dependencies: dangling deps cpuid = 0 KDB: stack backtrace: #0 0x80984e30 at kdb_backtrace+0x60 #1 0x809489e6 at vpanic+0x126 #2 0x809488b3 at panic+0x43 #3 0x80b866da at softdep_deallocate_dependencies+0x6a #4 0x809d1d95 at brelse+0x145 #5 0x809e9ee7 at flushbuflist+0x137 #6 0x809e9b5b at bufobj_invalbuf+0x1cb #7 0x809ec4be at vgonel+0x17e #8 0x809ec8ec at vgone+0x4c #9 0x8082b4e8 at devfs_delete+0x218 #10 0x8082b95c at devfs_populate_loop+0x1fc #11 0x8082b74a at devfs_populate+0x2a #12 0x8082fa6b at devfs_populate_vp+0x9b #13 0x808303bc at devfs_lookup+0x2c #14 0x80e71621 at VOP_LOOKUP_APV+0xa1 #15 0x809e0951 at lookup+0x5a1 #16 0x809e00b4 at namei+0x4d4 #17 0x809f9135 at vn_open_cred+0xd5 Uptime: 38m45s (da3:iscsi4:0:0:0): Synchronize cache failed (da4:iscsi5:0:0:0): Synchronize cache failed Dumping 815 out of 8163 MB:..2%..12%..22%..32%..42%..52%..61%..71%..81%..91% I've put the whole core.txt.%d files here (with my ip addresses and hostnames anonymized): - http://frankdebot.nl/tmp/core.txt.0 - http://frankdebot.nl/tmp/core.txt.1 > > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Reloading iscsi target, iscsi initiator panics
Hello, I have a FreeBSD 10.2 server running as iSCSI target. Another FreeBSD 10.2 is an initiator and has several targets used. When I add a target and reload its config with 'service ctld reload', the FreeBSD initiator server panics. It's reproducable (I have a coredump, but I think it's clear what the problem is) How can I have the target reloads it config, without all initiators crashing? Right before the crash the iscsi session drops and reinits Regards, Frank de Bot Related dmesg from the initiator: Oct 14 20:59:49 host004 kernel: (da0:iscsi1:0:0:0): WRITE(10). CDB: 2a 00 00 29 93 c0 00 00 08 00 Oct 14 20:59:49 host004 kernel: (da0:iscsi1:0:0:0): CAM status: SCSI Status Error Oct 14 20:59:49 host004 kernel: (da0:iscsi1:0:0:0): SCSI status: Check Condition Oct 14 20:59:49 host004 kernel: (da0:iscsi1:0:0:0): SCSI sense: UNIT ATTENTION asc:3f,e (Reported LUNs data has changed) Oct 14 20:59:49 host004 kernel: (da0:iscsi1:0:0:0): Retrying command (per sense data) Oct 14 20:59:49 host004 kernel: da0 at iscsi1 bus 0 scbus7 target 0 lun 0 Oct 14 20:59:49 host004 kernel: da0: s/n MYSERIAL 2 detached Oct 14 20:59:49 host004 kernel: (da0:iscsi1:0:0:0): Periph destroyed Oct 14 20:59:49 host004 kernel: da0 at iscsi1 bus 0 scbus7 target 0 lun 0 Oct 14 20:59:49 host004 kernel: da0: Fixed Direct Access SPC-4 SCSI device Oct 14 20:59:49 host004 kernel: da0: Serial Number MYSERIAL 2 Oct 14 20:59:49 host004 kernel: da0: 150.000MB/s transfers Oct 14 20:59:49 host004 kernel: da0: Command Queueing enabled Oct 14 20:59:49 host004 kernel: da0: 20480MB (5242880 4096 byte sectors: 255H 63S/T 326C) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: em0 and em1 watchdog timed out
The connection is fine when working without lagg/lacp. As soon I configure it, on load it the network devices will have watchdog timeouts. The switch I use is a HP 1810-24G, PL.1.9 One of the other threads mentioned he used an other router (/switch) and problems didn't occur anymore. Unfortunately I don't have an other switch lying around to test with. Frank Frank de Bot (lists) wrote: > FreeBSD 10.2 r28 . The drivers is Intel(R) PRO/1000 Network > Connection 7.4.2 I will start some tests without lagg configured. > > > Regards, > > Frank de Bot > > > Jack Vogel wrote: >> You missed the all-important details: OS version, driver version. >> And another question I can think of, do these interfaces watchdog if they >> are not configured with lagg? >> >> Cheers, >> >> Jack >> >> >> On Fri, Oct 2, 2015 at 10:37 AM, Frank de Bot (lists) <li...@searchy.net> >> wrote: >> >>> On a server I have 2 interfaces configured in a lagg. It seemed to be >>> running stable until now (about a week), both interfaces repeatable go >>> down after a watchdog timeout. >>> >>> Output from /var/log/messages >>> >>> Oct 2 10:15:11 nas kernel: em0: Watchdog timeout Queue[0]-- resetting >>> Oct 2 10:15:11 nas kernel: Interface is RUNNING and ACTIVE >>> Oct 2 10:15:11 nas kernel: em0: TX Queue 0 -- >>> Oct 2 10:15:11 nas kernel: em0: hw tdh = 804, hw tdt = 905 >>> Oct 2 10:15:11 nas kernel: em0: Tx Queue Status = -2147483648 >>> Oct 2 10:15:11 nas kernel: em0: TX descriptors avail = 915 >>> Oct 2 10:15:11 nas kernel: em0: Tx Descriptors avail failure = 0 >>> Oct 2 10:15:11 nas kernel: em0: RX Queue 0 -- >>> Oct 2 10:15:11 nas kernel: em0: hw rdh = 912, hw rdt = 911 >>> Oct 2 10:15:11 nas kernel: em0: RX discarded packets = 0 >>> Oct 2 10:15:11 nas kernel: em0: RX Next to Check = 912 >>> Oct 2 10:15:11 nas kernel: em0: RX Next to Refresh = 911 >>> Oct 2 10:15:11 nas kernel: em0: link state changed to DOWN >>> Oct 2 10:15:13 nas kernel: em0: link state changed to UP >>> Oct 2 10:15:13 nas devd: Executing '/etc/rc.d/dhclient quietstart em0' >>> Oct 2 10:21:56 nas kernel: em1: Interface stopped DISTRIBUTING, >>> possible flapping >>> Oct 2 10:21:59 nas kernel: em1: Watchdog timeout Queue[0]-- resetting >>> Oct 2 10:21:59 nas kernel: Interface is RUNNING and ACTIVE >>> Oct 2 10:21:59 nas kernel: em1: TX Queue 0 -- >>> Oct 2 10:21:59 nas kernel: em1: hw tdh = 686, hw tdt = 806 >>> Oct 2 10:21:59 nas kernel: em1: Tx Queue Status = -2147483648 >>> Oct 2 10:21:59 nas kernel: em1: TX descriptors avail = 896 >>> Oct 2 10:21:59 nas kernel: em1: Tx Descriptors avail failure = 0 >>> Oct 2 10:21:59 nas kernel: em1: RX Queue 0 -- >>> Oct 2 10:21:59 nas kernel: em1: hw rdh = 167, hw rdt = 166 >>> Oct 2 10:21:59 nas kernel: em1: RX discarded packets = 0 >>> Oct 2 10:21:59 nas kernel: em1: RX Next to Check = 167 >>> Oct 2 10:21:59 nas kernel: em1: RX Next to Refresh = 166 >>> Oct 2 10:21:59 nas kernel: em1: link state changed to DOWN >>> Oct 2 10:22:02 nas kernel: em1: link state changed to UP >>> Oct 2 10:22:02 nas devd: Executing '/etc/rc.d/dhclient quietstart em1' >>> >>> it seems to occur when the interface are loaded. On the same server I >>> also have a PCI card, the same issue occurs here. em0 and em1 are both >>> onboard 80003ES2LAN. the PCI card is 82571EB. >>> >>> I've found different threads, but I couldn't manage to find a fix for >>> this. >>> >>> What else can be wrong? >>> >>> Regards, >>> >>> Frank de Bot >>> ___ >>> freebsd-stable@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >>> >> ___ >> freebsd-stable@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >> > > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: em0 and em1 watchdog timed out
FreeBSD 10.2 r28 . The drivers is Intel(R) PRO/1000 Network Connection 7.4.2 I will start some tests without lagg configured. Regards, Frank de Bot Jack Vogel wrote: > You missed the all-important details: OS version, driver version. > And another question I can think of, do these interfaces watchdog if they > are not configured with lagg? > > Cheers, > > Jack > > > On Fri, Oct 2, 2015 at 10:37 AM, Frank de Bot (lists) <li...@searchy.net> > wrote: > >> On a server I have 2 interfaces configured in a lagg. It seemed to be >> running stable until now (about a week), both interfaces repeatable go >> down after a watchdog timeout. >> >> Output from /var/log/messages >> >> Oct 2 10:15:11 nas kernel: em0: Watchdog timeout Queue[0]-- resetting >> Oct 2 10:15:11 nas kernel: Interface is RUNNING and ACTIVE >> Oct 2 10:15:11 nas kernel: em0: TX Queue 0 -- >> Oct 2 10:15:11 nas kernel: em0: hw tdh = 804, hw tdt = 905 >> Oct 2 10:15:11 nas kernel: em0: Tx Queue Status = -2147483648 >> Oct 2 10:15:11 nas kernel: em0: TX descriptors avail = 915 >> Oct 2 10:15:11 nas kernel: em0: Tx Descriptors avail failure = 0 >> Oct 2 10:15:11 nas kernel: em0: RX Queue 0 -- >> Oct 2 10:15:11 nas kernel: em0: hw rdh = 912, hw rdt = 911 >> Oct 2 10:15:11 nas kernel: em0: RX discarded packets = 0 >> Oct 2 10:15:11 nas kernel: em0: RX Next to Check = 912 >> Oct 2 10:15:11 nas kernel: em0: RX Next to Refresh = 911 >> Oct 2 10:15:11 nas kernel: em0: link state changed to DOWN >> Oct 2 10:15:13 nas kernel: em0: link state changed to UP >> Oct 2 10:15:13 nas devd: Executing '/etc/rc.d/dhclient quietstart em0' >> Oct 2 10:21:56 nas kernel: em1: Interface stopped DISTRIBUTING, >> possible flapping >> Oct 2 10:21:59 nas kernel: em1: Watchdog timeout Queue[0]-- resetting >> Oct 2 10:21:59 nas kernel: Interface is RUNNING and ACTIVE >> Oct 2 10:21:59 nas kernel: em1: TX Queue 0 -- >> Oct 2 10:21:59 nas kernel: em1: hw tdh = 686, hw tdt = 806 >> Oct 2 10:21:59 nas kernel: em1: Tx Queue Status = -2147483648 >> Oct 2 10:21:59 nas kernel: em1: TX descriptors avail = 896 >> Oct 2 10:21:59 nas kernel: em1: Tx Descriptors avail failure = 0 >> Oct 2 10:21:59 nas kernel: em1: RX Queue 0 -- >> Oct 2 10:21:59 nas kernel: em1: hw rdh = 167, hw rdt = 166 >> Oct 2 10:21:59 nas kernel: em1: RX discarded packets = 0 >> Oct 2 10:21:59 nas kernel: em1: RX Next to Check = 167 >> Oct 2 10:21:59 nas kernel: em1: RX Next to Refresh = 166 >> Oct 2 10:21:59 nas kernel: em1: link state changed to DOWN >> Oct 2 10:22:02 nas kernel: em1: link state changed to UP >> Oct 2 10:22:02 nas devd: Executing '/etc/rc.d/dhclient quietstart em1' >> >> it seems to occur when the interface are loaded. On the same server I >> also have a PCI card, the same issue occurs here. em0 and em1 are both >> onboard 80003ES2LAN. the PCI card is 82571EB. >> >> I've found different threads, but I couldn't manage to find a fix for >> this. >> >> What else can be wrong? >> >> Regards, >> >> Frank de Bot >> ___ >> freebsd-stable@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >> > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
em0 and em1 watchdog timed out
On a server I have 2 interfaces configured in a lagg. It seemed to be running stable until now (about a week), both interfaces repeatable go down after a watchdog timeout. Output from /var/log/messages Oct 2 10:15:11 nas kernel: em0: Watchdog timeout Queue[0]-- resetting Oct 2 10:15:11 nas kernel: Interface is RUNNING and ACTIVE Oct 2 10:15:11 nas kernel: em0: TX Queue 0 -- Oct 2 10:15:11 nas kernel: em0: hw tdh = 804, hw tdt = 905 Oct 2 10:15:11 nas kernel: em0: Tx Queue Status = -2147483648 Oct 2 10:15:11 nas kernel: em0: TX descriptors avail = 915 Oct 2 10:15:11 nas kernel: em0: Tx Descriptors avail failure = 0 Oct 2 10:15:11 nas kernel: em0: RX Queue 0 -- Oct 2 10:15:11 nas kernel: em0: hw rdh = 912, hw rdt = 911 Oct 2 10:15:11 nas kernel: em0: RX discarded packets = 0 Oct 2 10:15:11 nas kernel: em0: RX Next to Check = 912 Oct 2 10:15:11 nas kernel: em0: RX Next to Refresh = 911 Oct 2 10:15:11 nas kernel: em0: link state changed to DOWN Oct 2 10:15:13 nas kernel: em0: link state changed to UP Oct 2 10:15:13 nas devd: Executing '/etc/rc.d/dhclient quietstart em0' Oct 2 10:21:56 nas kernel: em1: Interface stopped DISTRIBUTING, possible flapping Oct 2 10:21:59 nas kernel: em1: Watchdog timeout Queue[0]-- resetting Oct 2 10:21:59 nas kernel: Interface is RUNNING and ACTIVE Oct 2 10:21:59 nas kernel: em1: TX Queue 0 -- Oct 2 10:21:59 nas kernel: em1: hw tdh = 686, hw tdt = 806 Oct 2 10:21:59 nas kernel: em1: Tx Queue Status = -2147483648 Oct 2 10:21:59 nas kernel: em1: TX descriptors avail = 896 Oct 2 10:21:59 nas kernel: em1: Tx Descriptors avail failure = 0 Oct 2 10:21:59 nas kernel: em1: RX Queue 0 -- Oct 2 10:21:59 nas kernel: em1: hw rdh = 167, hw rdt = 166 Oct 2 10:21:59 nas kernel: em1: RX discarded packets = 0 Oct 2 10:21:59 nas kernel: em1: RX Next to Check = 167 Oct 2 10:21:59 nas kernel: em1: RX Next to Refresh = 166 Oct 2 10:21:59 nas kernel: em1: link state changed to DOWN Oct 2 10:22:02 nas kernel: em1: link state changed to UP Oct 2 10:22:02 nas devd: Executing '/etc/rc.d/dhclient quietstart em1' it seems to occur when the interface are loaded. On the same server I also have a PCI card, the same issue occurs here. em0 and em1 are both onboard 80003ES2LAN. the PCI card is 82571EB. I've found different threads, but I couldn't manage to find a fix for this. What else can be wrong? Regards, Frank de Bot ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
NFS Client changing it's source address? (FreeBSD 10.2)
Hello, I have a server running FreeBSD 10.2. It has several NFS mounts. Frequently my NFS mount hang (v3). After a little investigation it looks like FreeBSD has chosen a wrong source address for it's connections and all packets are departing from the wrong interface. Sockstat output: [root@host004 ~]# sockstat -4 | grep 2049 root ssh14689 3 tcp4 10.4.2.4:2049910.4.2.5:22 ?? ? ? tcp4 10.13.37.4:67210.13.37.2:2049 ?? ? ? tcp4 79.x.x.210:90510.13.37.2:2049 ?? ? ? tcp4 79.x.x.210:99210.13.37.2:2049 tcpdump confirms nfs connection are trying to get out via the 79.x.x.x interface My fstab for the nfs mounts look like: 10.13.37.2:/tank/hostingbase /opt/jails/hostingbase nfs nfsv3,ro,noatime,async,noauto0 0 /opt/jails/hostingbase /opt/jails/test01 nullfs ro,noatime,noauto 0 0 10.13.37.2:/tank/hosting/test /opt/jails/test01/opt nfs nfsv3,noatime,async,rw,noauto 0 0 tmpfs /opt/jails/test01/shm tmpfs rw,size=51200,noauto 0 0 /opt/jails/hostingbase /opt/jails/test2 nullfs ro,noatime,noauto 0 0 10.13.37.2:/tank/hosting/test2 /opt/jails/test2/opt nfs nfsv3,noatime,async,rw,noauto 0 0 tmpfs /opt/jails/test2/shm tmpfs rw,size=51200,noauto 0 0 The change of source address looks to be happening after a nfs connection is re-established. At first everything works, I leave the server idling (it's a test server) and after that the mounts are hanging 10.2-RELEASE #0 r28 is the current running version. Regards, Frank de Bot ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Multiple IP/subnet in jail, source address for connections
Hello, I'm trying to have jail with a public and a private IP address. Both are on the same interface. The public is called 79.x.x.213 and private 10.4.3.6 Out from ifconfig within the jail is: inet 79.x.x.213 netmask 0x broadcast 79.x.x.213 inet 10.4.3.6 netmask 0x broadcast 10.4.3.6 When I try to reach a host on the 10.4.3.0/24 network, it will use the source address 79.x.x.123 (seen with tcpdump) When done outside of the jail on the server, it does have the right source address. How can I get my jail to have the right source address? Some tools provide a way to define a source address, like telnet -s, but it's not workable. Frank de Bot ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
kernel process [nfscl] high cpu
Hi,
On a 10.1-RELEASE-p9 server I have several NFS mounts used for a jail.
Because it's a server only to test, there is a low load. But the [nfscl]
process is hogging a CPU after a while. This happens pretty fast, within
1 or 2 days. I'm noticing the high CPU of the process when I want to do
some test after a little while (those 1 or 2 days).
My jail.conf look like:
exec.start = /bin/sh /etc/rc;
exec.stop = /bin/sh /etc/rc.shutdown;
exec.clean;
mount.devfs;
exec.consolelog = /var/log/jail.$name.log;
#mount.fstab = /usr/local/etc/jail.fstab.$name;
test01 {
host.hostname = test01_hosting;
ip4.addr = somepublicaddress;
ip4.addr += someprivateaddress;
mount = 10.13.37.2:/tank/hostingbase /opt/jails/test01
nfs nfsv4,minorversion=1,pnfs,ro,noatime0 0;
mount += 10.13.37.2:/tank/hosting/test
/opt/jails/test01/opt nfs nfsv4,minorversion=1,pnfs,noatime
0 0;
path = /opt/jails/test01;
}
Last test was with NFS 4.1, I also worked with NFS 4.(0) with the same
result. In the readonly nfs share there are symbolic links point to the
read-write share for logging, storing .run files, etc. When I monitor my
network interface with tcpdump, there is little nfs traffic, only when I
do try to access the shares there is activity.
What is causing nfscl to run around in circles, hogging the CPU (it
makes the system slow to respond too) or how can I found out what's the
cause?
Regards,
Frank de Bot
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS L2arc 16.0E size
Frank de Bot (lists) wrote: Hello, I have a FreeBSD 10.1 system with a raidz2 zfs configuration with 2ssd's for l2arc . It is running '10.1-STABLE FreeBSD 10.1-STABLE #0 r278805' Currently I'm running tests before it can go to production, but I have the following issue. After a while the l2arc devices indicate 16.0E free space and it starts 'consuming' more than it can hold I've tried to 'debug' with dtrace, I found out different things: - l2arc_write_buffers sometimes caused the vdev-vdev_stat.vs_alloc to grow larger than vdev-vdev_asize. - l2arc_dev-l2ad_end is larger than vdev-vdev_asize - At some point l2arc_eviction isn't doing anything, but l2ard_dev-l2ad_evict is higher than l2ard_dev-l2ad_hand . taddr is matching l2ard_dev-l2ad_evict . I would assume it should evict that space. l2arc_write_buffers will continue because there seems te be room enough, I guess this would be caused by vdev_asize - vs_alloc is negative and indicating a 16.0E freespace. It could be that I'm assuming wrong things or interpret things wrong. Please let me know. Frank de Bot ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
