Re: miibus0: mii_mediachg: can't handle non-zero PHY instance 31
On Sun, Apr 06, 2014 at 10:49:27PM -0700, Chris H wrote: On Thu, Apr 03, 2014 at 01:18:19PM -0700, Chris H wrote: On Tue, Apr 01, 2014 at 05:53:51PM -0700, Chris H wrote: On Tue, Apr 01, 2014 at 01:40:58PM -0700, Chris H wrote: On Tue, 2014-04-01 at 13:19 -0700, Chris H wrote: [...] miibus0: MII bus on nfe0 rlphy0: RTL8201L 10/100 media interface PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy1: RTL8201L 10/100 media interface PHY 1 on miibus0 [...]---big-snip--8--- miibus0: mii_mediachg: can't handle non-zero PHY instance 1 As you can see, it looks much the same. I have no idea what I should do to better inform the driver/kernel how to better handle it. Or is it the driver, itself? Thank you again, for your thoughtful response. --Chris I think the way to fix a phy that responds at all addresses is to set a hint in loader.conf masking out the ones that aren't real, like so: hint.miibus.0.phymask=1 You might be able to set =0x0001 to make it more clear it's a bitmask, but I'm not sure of that. Thank you very much for the hint. I'll give it a shot. Any idea why this is happening? I have 4 other MB's using the Nvidia chipset, and the nfe(4) driver. But they don't respond this way. If some nfe(4) variants badly behave in probing stage, this should be handled by driver. We already have too many hints and tunables and I don't think most users know that. In addition, adding additional NIC may change miibus instance number. Could you show me the output of 'kenv | grep smbios'? Yes, of course. Here it is: smbios.bios.reldate=11/22/2010 smbios.bios.vendor=American Megatrends Inc. smbios.bios.version=V2.7 smbios.chassis.maker=MSI smbios.chassis.serial=To Be Filled By O.E.M. smbios.chassis.tag=To Be Filled By O.E.M. smbios.chassis.version=2.0 smbios.memory.enabled=2097152 smbios.planar.maker=MSI smbios.planar.product=K9N6PGM2-V2 (MS-7309) smbios.planar.serial=To be filled by O.E.M. smbios.planar.version=2.0 smbios.socket.enabled=1 smbios.socket.populated=1 smbios.system.maker=MSI smbios.system.product=MS-7309 smbios.system.serial=To Be Filled By O.E.M. smbios.system.uuid=----406186cd4497 smbios.system.version=2.0 smbios.version=2.6 Hope this helps, and thank you for all your time, and trouble. Thanks for the info. Try attached patch and let me know how it works. Make sure to remove the hint(hint.miibus.0.phymask=1) set in loader.conf before testing it. Hello, and thanks for all the attention. Sorry for the delay. I chose to perform a dump(8) before attempting the KERn rebuild with the patch. But the kernel threw a read error message on one of the drives. So I had to sort out the problem on the drive before I could complete the dump. Then, of course I had to reslice, and format another drive to replace the ailing one, before I could perform a restore(8), and start the nfe patch; build install kernel. Weird; the drive had only a few hours on it. Well, anyway. The patch applied cleanly. So I built, and installed a new kernel with it. X's out the hint.miibus.0.phymask=0x0001 in loader.conf(5), and bounced the box. Bad news: miibus0: mii_mediachg: can't handle non-zero PHY instance 31 miibus0: mii_mediachg: can't handle non-zero PHY instance 30 miibus0: mii_mediachg: can't handle non-zero PHY instance 29 miibus0: mii_mediachg: can't handle non-zero PHY instance 28 miibus0: mii_mediachg: can't handle non-zero PHY instance 27 miibus0: mii_mediachg: can't handle non-zero PHY instance 26 miibus0: mii_mediachg: can't handle non-zero PHY instance 25 miibus0: mii_mediachg: can't handle non-zero PHY instance 24 miibus0: mii_mediachg: can't handle non-zero PHY instance 23 miibus0: mii_mediachg: can't handle non-zero PHY instance 22 miibus0: mii_mediachg: can't handle non-zero PHY instance 21 miibus0: mii_mediachg: can't handle non-zero PHY instance 20 miibus0: mii_mediachg: can't handle non-zero PHY instance 19 miibus0: mii_mediachg: can't handle non-zero PHY instance 18 miibus0: mii_mediachg: can't handle non-zero PHY instance 17 miibus0: mii_mediachg: can't handle non-zero PHY instance 16 miibus0: mii_mediachg: can't handle non-zero PHY instance 15 miibus0: mii_mediachg: can't handle non-zero PHY instance 14 miibus0: mii_mediachg: can't handle non-zero PHY instance 13 miibus0: mii_mediachg: can't handle non-zero PHY instance 12 miibus0: mii_mediachg: can't handle non-zero PHY instance 11 miibus0: mii_mediachg: can't handle non-zero PHY instance 10 miibus0: mii_mediachg: can't handle non-zero PHY instance 9 miibus0: mii_mediachg: can't handle non-zero PHY instance 8 miibus0: mii_mediachg: can't
Re: re0: watchdog timeout
Yonghyeon PYUN schreef op 7-4-2014 3:22: On Sun, Apr 06, 2014 at 07:37:08PM -0400, Rick Macklem wrote: Frank Volf wrote: Hello, I'm experiencing watchdog timeouts with my Realtek interface card. I'm using a fairly new system (Shuttle DS47), running FreeBSD 10-STABLE. For this shuttle a patch has been recently committed to SVN to make this card work at all (revision *262391* http://svnweb.freebsd.org/base?view=revisionrevision=262391). The timeout is only experienced under heavy network load (the system is running a bacula backup server that backups to NFS connected storage), and typically large full backups trigger this. Normal traffic works fine (this system is e.g. also my firewall to the Internet). Since you mention NFS, you could try disabling TSO on the interface and see if that helps. (I'm beginning to feel like a parrot saying this, but...) If you care about why it might help, read this email thread: http://docs.FreeBSD.org/cgi/mid.cgi?1850411724.1687820.1395621539316.JavaMail.root If it happens to help, please email again, since there are probably better ways to fix the problem than disabling TSO. re(4) controllers support TSO but it was disabled long time ago(r217832). It's still allowed to enable TSO but users have to explicitly enable it with ifconfig. If Frank didn't explicitly enable TSO on the box, TSO may have nothing to do with watchdog timeout, I guess. I haven't explicitly enabled TSO, the only option that has been explicitly set is -vlanhwtag, here is the interface config: re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8208bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE ether 80:ee:73:77:e9:ab nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active Regards, Frank ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: re0: watchdog timeout
On Mon, Apr 07, 2014 at 08:09:04AM +0200, Frank Volf wrote: Yonghyeon PYUN schreef op 7-4-2014 3:22: On Sun, Apr 06, 2014 at 07:37:08PM -0400, Rick Macklem wrote: Frank Volf wrote: Hello, I'm experiencing watchdog timeouts with my Realtek interface card. I'm using a fairly new system (Shuttle DS47), running FreeBSD 10-STABLE. For this shuttle a patch has been recently committed to SVN to make this card work at all (revision *262391* http://svnweb.freebsd.org/base?view=revisionrevision=262391). The timeout is only experienced under heavy network load (the system is running a bacula backup server that backups to NFS connected storage), and typically large full backups trigger this. Normal traffic works fine (this system is e.g. also my firewall to the Internet). Since you mention NFS, you could try disabling TSO on the interface and see if that helps. (I'm beginning to feel like a parrot saying this, but...) If you care about why it might help, read this email thread: http://docs.FreeBSD.org/cgi/mid.cgi?1850411724.1687820.1395621539316.JavaMail.root If it happens to help, please email again, since there are probably better ways to fix the problem than disabling TSO. re(4) controllers support TSO but it was disabled long time ago(r217832). It's still allowed to enable TSO but users have to explicitly enable it with ifconfig. If Frank didn't explicitly enable TSO on the box, TSO may have nothing to do with watchdog timeout, I guess. I haven't explicitly enabled TSO, the only option that has been explicitly set is -vlanhwtag, here is the interface config: re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8208bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE ether 80:ee:73:77:e9:ab nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active It would be even better to know your network configuration. I'm not sure why you have to disable VLAN hardware tagging. But given that you've disabled it, could you also try disabling VLAN hardware checksum offloading? Regards, Frank ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
may some issue related to lo0 or socket
Hi,lists, I ran a forward squid instance and a haproxy instanse on one FreeBSD 9.1 box, it's works fine. When I upgraded it to 10-stable, I found I can't buffer videos normally unless I set tcp_recv_bufsize to a higher value, eg. 32768. The squid instance forward http request to the haproxy and accept the response from the haproxy via lo0. I think maybe there is some issue, I have tried upgraded the os to r264098 and disable lo0's csum, but it's not helped. How can I investigate the issue deeply ? Regards Simon ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: panic in -HEAD multicast code
Hi Adrian, On 07/04/14 04:58, Adrian Chadd wrote: I'm seeing a panic in the multicast code path. I reproduce this by trying to browse network sharing on VLC. The panic: http://people.freebsd.org/~adrian/ath/core.txt.0 Any ideas? We believe this issue is due to a race condition in multicast code. We found it tracking down another unrelated bug: http://www.freebsd.org/cgi/query-pr.cgi?pr=185043 See provided details on this race condition in PR description section starting with: With even this patch in place, we have further found a subsequent race condition that In short, it looks like a race between a thread setting/allocating a new multicast address on an interface and calling: inp_setmoptions() - inp_join_group() - inp_join_group_locked() - in_getmulti() and a thread detaching this interface, purging all associated multicast addresses and calling: if_detach() - if_detach_internal() - if_purgemaddrs() - if_delmulti_locked() - if_freemulti() However, we did not find a way to fix it without unwanted side effects and we asked for comments/ideas. -- Julien ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Current problem reports assigned to freebsd-net@FreeBSD.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o kern/188245 net[vlan] Critical vlan problem with OpenBGP o bin/187835 netngctl(8) strange behavior when adding more than 530 vl o kern/187341 net[netinet] [patch] CARP addresses in backup state shoul o kern/187258 net[bxe] BCM57810 bxe(4) unstable/fails to initialize o kern/187194 netServer hangs if -arp is present on an IP address o kern/187068 net[em] network data slow/stops with em driver o kern/186949 net[re] re0 driver crashes under load every 10-20 minutes o kern/186872 net[msk] Upgrade from 9.2 to 10, msk0 watchdog timeout [r o kern/185496 net[re] RTL8169 doesn't receive unicast ethernet packets o kern/185427 net[igb] freebsd 8.4, 9.1 and 9.2 panic Double-Fault with o kern/185387 net[axe] if_axe usb ethernet interface no ssh, no http wi o kern/185023 net[tun] Closing tunn interface deconfigures IP address o kern/185022 net[tun] ls /dev/tunn creates tunn interface o kern/184311 net[bge] [panic] kernel panic with bge(4) on SunFire X210 o kern/184084 net[ral] kernel crash by ral (RT3090) o bin/183687 net[patch] route(8): route add -net 172.20 add wrong host a kern/183666 netCompiled-in bxe(4) breaks kgzip(1) kernel p kern/183659 net[tcp] ]TCP stack lock contention with short-lived conn o conf/183407 net[rc.d] [patch] Routing restart returns non-zero exitco o kern/183391 net[oce] 10gigabit networking problems with Emulex OCE 11 o kern/182917 net[igb] strange out traffic with igb interfaces o kern/182665 net[wlan] Kernel panic when creating second wlandev. o kern/182382 net[tcp] sysctl to set TCP CC method on BIG ENDIAN system o kern/182297 net[cm] ArcNet driver fails to detect the link address - o kern/182212 net[patch] [ng_mppc] ng_mppc(4) blocks on network errors o kern/181970 net[re] LAN Realtek® 8111G is not supported by re driver o kern/181931 net[vlan] [lagg] vlan over lagg over mlxen crashes the ke o kern/181741 net[kernel] [patch] Packet loss when 'control' messages a o kern/181703 net[re] [patch] Fix Realtek 8111G Ethernet controller not o kern/181657 net[bpf] [patch] BPF_COP/BPF_COPX instruction reservation o kern/181257 net[bge] bge link status change o kern/181236 net[igb] igb driver unstable work o kern/180893 net[if_ethersubr] [patch] Packets received with own LLADD o kern/180844 net[panic] [re] Intermittent panic (re driver?) f kern/180775 net[bxe] if_bxe driver broken with Broadcom BCM57711 card o kern/180722 net[bluetooth] bluetooth takes 30-50 attempts to pair to s kern/180468 net[request] LOCAL_PEERCRED support for PF_INET o kern/180065 net[netinet6] [patch] Multicast loopback to own host brok o kern/179926 net[lacp] [patch] active aggregator selection bug o kern/179824 net[ixgbe] System (9.1-p4) hangs on heavy ixgbe network t o kern/179733 net[lagg] [patch] interface loses capabilities when proto o kern/179429 net[tap] STP enabled tap bridge a kern/179264 net[vimage] [pf] Core dump with Packet filter and VIMAGE o kern/178947 net[arp] arp rejecting not working o kern/178782 net[ixgbe] 82599EB SFP does not work with passthrough und o kern/178612 net[run] kernel panic due the problems with run driver o kern/178079 net[tcp] Switching TCP CC algorithm panics on sparc64 wit s kern/178071 netFreeBSD unable to recongize Kontron (Industrial Comput o kern/177905 net[xl] [panic] ifmedia_set when pluging CardBus LAN card o kern/177618 net[bridge] Problem with bridge firewall with trunk ports o kern/177402 net[igb] [pf] problem with ethernet driver igb + pf / alt o kern/177400 net[jme] JMC25x 1000baseT establishment issues o kern/177366 net[ieee80211] negative malloc(9) statistics for 80211nod f kern/177362 net[netinet] [patch] Wrong control used to return TOS o kern/177194 net[netgraph] Unnamed netgraph nodes for vlan interfaces o kern/177184 net[bge] [patch] enable wake on lan o kern/177139 net[igb] igb drops ethernet ports 2 and 3 o kern/176884 net[re] re0 flapping up/down o kern/176671 net[epair] MAC address for epair device not unique o kern/176420 net[kernel] [patch] incorrect errno for LOCAL_PEERCRED o kern/176419 net[kernel] [patch]
Re: Multihomed system with jails routing issues
On Fri, Apr 4, 2014 at 8:22 PM, Chris Smith ch...@nevermind.co.nz wrote: Hi All, I have a system with 1 network interface with 2 extra VLANs off it and I'm having some trouble getting the routing working correctly with it and jails. bge0 - management - 10.71.100.0/24 bge0.101 - LAN- 10.71.101.0/24 bge0.103 - DMZ- 10.71.101.0/24 Here's what I want to achieve... Host: I want the host system to only listen on one interface, bge0. I want NO ip addresses of the host on the vlan interfaces. The only service it will be exposing is its sshd. The management address for this system is 10.71.100.50. Jails: The system will also host a variety of jails, each with an IP either on the LAN or DMZ. I am using ezjail to manage the jails. Router: There is a router at the .254 address of every subnet that can route between each network. I set up jail1 on bge0.101 with the IP 10.71.101.51. Since the host does not have an address configured on bge0.101, I configured the jail address as /24 instead of the default /32. My issues: * If I do not configure the jail as a /24 (e.g. /32), the LAN cannot communicate with the jail. * When the jail is up and 10.71.101.51/24 is active, SSHing from the LAN to the mgmt interface via the router fails, as the host tries to send return traffic via the bge0.101 interface, even though traffic arrived via the bge0 interface. So I did a whole lot of research for people having these apparently problems, and decided to try the multiple routing table/fib approach. So I recompiled my kernel, configured fib 1 with the LAN interface route (setfib route add 10.71.101.0/24 -iface bge0.101), set the jail fib and set the tunable net.addr_all_fibs = 0. I still can't get this working correctly. ezjail still seems to add the interface route to fib 0 by default (but it won't if i run ezjail with the setfib 1 command). Routing is very broken when you use multiple FIBs and set net.addr_all_fibs=0. See bugs http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/167947 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/187549 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/187550 http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/187551 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/187552 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/187553 http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/187699 I'm actively working on fixing the above, but getting consensus on the solution is slow. If you can't solve your problem without using multiple FIBs, I will suggest a set of patches that may help you. I will need 1) Your ifconfig_bge0 etc lines from /etc/rc.conf 2) The output for setfib X netstat -rn -f inet for each fib in use. 3) The rc.conf lines for any manually create routes that you're using, for example gateways. Also you may want to look at this possibly relevant bug. I'm not involved with this one: http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/181794 -Alan Using FIB 1 and trying to ping hosts on the LAN gives an error like: sendto failed: invalid argument. Does anybody have any best practices for doing this, or anything else I can try? I'm happy to share/pastebin any configuration and I've tried most things I've found on the internet. I'm using FreeBSD 10.0 with a custom kernel for multiple routing tables. Thanks in advance! Chris. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: miibus0: mii_mediachg: can't handle non-zero PHY instance 31
On Sun, Apr 06, 2014 at 10:49:27PM -0700, Chris H wrote: On Thu, Apr 03, 2014 at 01:18:19PM -0700, Chris H wrote: On Tue, Apr 01, 2014 at 05:53:51PM -0700, Chris H wrote: On Tue, Apr 01, 2014 at 01:40:58PM -0700, Chris H wrote: On Tue, 2014-04-01 at 13:19 -0700, Chris H wrote: [...] miibus0: MII bus on nfe0 rlphy0: RTL8201L 10/100 media interface PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy1: RTL8201L 10/100 media interface PHY 1 on miibus0 [...]---big-snip--8--- miibus0: mii_mediachg: can't handle non-zero PHY instance 1 As you can see, it looks much the same. I have no idea what I should do to better inform the driver/kernel how to better handle it. Or is it the driver, itself? Thank you again, for your thoughtful response. --Chris I think the way to fix a phy that responds at all addresses is to set a hint in loader.conf masking out the ones that aren't real, like so: hint.miibus.0.phymask=1 You might be able to set =0x0001 to make it more clear it's a bitmask, but I'm not sure of that. Thank you very much for the hint. I'll give it a shot. Any idea why this is happening? I have 4 other MB's using the Nvidia chipset, and the nfe(4) driver. But they don't respond this way. If some nfe(4) variants badly behave in probing stage, this should be handled by driver. We already have too many hints and tunables and I don't think most users know that. In addition, adding additional NIC may change miibus instance number. Could you show me the output of 'kenv | grep smbios'? Yes, of course. Here it is: smbios.bios.reldate=11/22/2010 smbios.bios.vendor=American Megatrends Inc. smbios.bios.version=V2.7 smbios.chassis.maker=MSI smbios.chassis.serial=To Be Filled By O.E.M. smbios.chassis.tag=To Be Filled By O.E.M. smbios.chassis.version=2.0 smbios.memory.enabled=2097152 smbios.planar.maker=MSI smbios.planar.product=K9N6PGM2-V2 (MS-7309) smbios.planar.serial=To be filled by O.E.M. smbios.planar.version=2.0 smbios.socket.enabled=1 smbios.socket.populated=1 smbios.system.maker=MSI smbios.system.product=MS-7309 smbios.system.serial=To Be Filled By O.E.M. smbios.system.uuid=----406186cd4497 smbios.system.version=2.0 smbios.version=2.6 Hope this helps, and thank you for all your time, and trouble. Thanks for the info. Try attached patch and let me know how it works. Make sure to remove the hint(hint.miibus.0.phymask=1) set in loader.conf before testing it. Hello, and thanks for all the attention. Sorry for the delay. I chose to perform a dump(8) before attempting the KERn rebuild with the patch. But the kernel threw a read error message on one of the drives. So I had to sort out the problem on the drive before I could complete the dump. Then, of course I had to reslice, and format another drive to replace the ailing one, before I could perform a restore(8), and start the nfe patch; build install kernel. Weird; the drive had only a few hours on it. Well, anyway. The patch applied cleanly. So I built, and installed a new kernel with it. X's out the hint.miibus.0.phymask=0x0001 in loader.conf(5), and bounced the box. Bad news: miibus0: mii_mediachg: can't handle non-zero PHY instance 31 miibus0: mii_mediachg: can't handle non-zero PHY instance 30 miibus0: mii_mediachg: can't handle non-zero PHY instance 29 miibus0: mii_mediachg: can't handle non-zero PHY instance 28 miibus0: mii_mediachg: can't handle non-zero PHY instance 27 miibus0: mii_mediachg: can't handle non-zero PHY instance 26 miibus0: mii_mediachg: can't handle non-zero PHY instance 25 miibus0: mii_mediachg: can't handle non-zero PHY instance 24 miibus0: mii_mediachg: can't handle non-zero PHY instance 23 miibus0: mii_mediachg: can't handle non-zero PHY instance 22 miibus0: mii_mediachg: can't handle non-zero PHY instance 21 miibus0: mii_mediachg: can't handle non-zero PHY instance 20 miibus0: mii_mediachg: can't handle non-zero PHY instance 19 miibus0: mii_mediachg: can't handle non-zero PHY instance 18 miibus0: mii_mediachg: can't handle non-zero PHY instance 17 miibus0: mii_mediachg: can't handle non-zero PHY instance 16 miibus0: mii_mediachg: can't handle non-zero PHY instance 15 miibus0: mii_mediachg: can't handle non-zero PHY instance 14 miibus0: mii_mediachg: can't handle non-zero PHY instance 13 miibus0: mii_mediachg: can't handle non-zero PHY instance 12 miibus0: mii_mediachg: can't handle non-zero PHY instance 11 miibus0: mii_mediachg: can't handle non-zero PHY instance 10 miibus0: mii_mediachg: can't handle non-zero PHY instance 9 miibus0: mii_mediachg: can't handle non-zero PHY instance 8 miibus0:
Re: re0: watchdog timeout
Yonghyeon PYUN schreef op 7-4-2014 10:32: It would be even better to know your network configuration. I'm not sure why you have to disable VLAN hardware tagging. But given that you've disabled it, could you also try disabling VLAN hardware checksum offloading? Hi, The reason that I disable VLAN hardware tagging is that the system does not work with it enabled. To show this, see the following transcript (on a freshly booted system): Script started on Mon Apr 7 20:30:43 2014 root@drawbridge:~ # ifconfig re0 re0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8209bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE ether 80:ee:73:77:e9:ab nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTX full-duplex) status: active root@drawbridge:~ # ifconfig re0.10 re0.10: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=3RXCSUM,TXCSUM ether 80:ee:73:77:e9:ab inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 inet6 fe80::82ee:73ff:fe77:e9ab%re0.10 prefixlen 64 scopeid 0x5 inet6 2001:470:7af9:10::1 prefixlen 64 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTX full-duplex) status: active vlan: 10 parent interface: re0 root@drawbridge:~ # ping 192.168.1.2 PING 192.168.1.2 (192.168.1.2): 56 data bytes ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down ^C --- 192.168.1.2 ping statistics --- 9 packets transmitted, 0 packets received, 100.0% packet loss root@drawbridge:~ # ifconfig re0 -vlanhwtag root@drawbridge:~ # ifconfig re0 down root@drawbridge:~ # ifconfig re0 up root@drawbridge:~ # ifconfig re0 re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8208bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE ether 80:ee:73:77:e9:ab nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active root@drawbridge:~ # ifconfig re0.10 re0.10: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 80:ee:73:77:e9:ab inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 inet6 fe80::82ee:73ff:fe77:e9ab%re0.10 prefixlen 64 scopeid 0x5 inet6 2001:470:7af9:10::1 prefixlen 64 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active vlan: 10 parent interface: re0 root@drawbridge:~ # ping 192.168.1.2 PING 192.168.1.2 (192.168.1.2): 56 data bytes 64 bytes from 192.168.1.2: icmp_seq=0 ttl=64 time=0.250 ms 64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.232 ms 64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.283 ms 64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.238 ms 64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=0.138 ms 64 bytes from 192.168.1.2: icmp_seq=5 ttl=64 time=0.217 ms ^C --- 192.168.1.2 ping statistics --- 6 packets transmitted, 6 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.138/0.226/0.283/0.044 ms root@drawbridge:~ # exit Script done on Mon Apr 7 20:32:27 2014 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: re0: watchdog timeout
Yonghyeon PYUN schreef op 7-4-2014 10:32: It would be even better to know your network configuration. I'm not sure why you have to disable VLAN hardware tagging. But given that you've disabled it, could you also try disabling VLAN hardware checksum offloading? HI Again, Sorry, forgot to answer the second part of your question, the disabling of VLAN hardware checksum. I can't get that to work, it won't enable even though the command has been accepted. Regards, Frank Script started on Mon Apr 7 20:46:33 2014 root@drawbridge:~ # ifconfig re0 re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8208bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE ether 80:ee:73:77:e9:ab nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active root@drawbridge:~ # ifconfig re0 -vlanhwcsum root@drawbridge:~ # ifconfig re0 down root@drawbridge:~ # ifconfig re0 up root@drawbridge:~ # ifconfig re0 re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8208bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE ether 80:ee:73:77:e9:ab nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active root@drawbridge:~ # exit exit Script done on Mon Apr 7 20:47:18 2014 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: ipfw / routing issue on 9.2-RELEASE
On Wed, Mar 26, 2014 at 5:42 PM, Andreas Nilsson andrn...@gmail.com wrote: ... snip ... I'm wondering what's happening on the outbound path, most of your rules handle inbound (to kernel) and it seems that rule 65535 deals with most outbound, except those specifically acting on both paths. So do I :) Maybe try adding to the above: ipfw add 63510 count log ip from table(1) to any out recv table(8) and ipfw add 64510 count log ip from table(1) to any out recv table(8) which should catch them on the outbound path before the default rule; outbound packets have both receive and transmit interfaces available. They never get that far :( Those rules log nothing. So I see the packet coming in, triggering the skipto, triggering the count log ... in recv but not the count log ... out. I guess you're sure that these packets are actually going out to some external address, not a localhost or alias address (which of course are received and not sent out anywhere)? Yes, when the go through they go to external address, which is in the routing table. I guess the above new log lines should show the interface (if any) these packets are leaving on, after routing (maybe a routing issue?) Good luck hunting. If in doubt, throw ever more logging at it! :) And please let the list know if you solve it - or not! cheers, Ian To make it even more interesting, it tested this on another machine, where I'm unable to reproduce this problem. I'm thinking that a reboot might help, but this is kind of fascinating so I would like to actually find the cause. I will investigate further. Best regards Andreas And now it happened on another machine, but different type of traffic. Traffic triggering the divert rule work fine, some traffic not triggering the divert rule does not. After everything works as expected. Before reboot I flushed the firewall so that only default rule was in play ( allow all from any to any ), and then *no* traffic for that destination went out of the box. There are something like ~1000 routes in the routing table. Routes are added and removed according to some triggers, so during uptime of the machine there is a bit of messing with the routing table. At this stage I'm at a loss on how to continue investigating this, so I'll just implement the forwarding via fwd rules in ipfw and altogether ignore the routing table. Best regards Andreas Ok, found the culprit: -# $FreeBSD: releng/9.1/etc/rc.d/netif 212579 2010-09-13 19:55:40Z hrs $ +# $FreeBSD: releng/9.2/etc/rc.d/netif 253238 2013-07-12 01:34:24Z hrs $ + if [ -f /etc/rc.d/routing -a -n $cmdifn ] ; then + for _if in $cmdifn; do + /etc/rc.d/routing start any $_if + done + fi etc/rc.d/routing enforces gateway_enable setting in rc.conf which does not play well with setting net.inet.ip.forwarding=1 in sysctl.conf directly. Very annoying. I can find nothing i UPDATING on the subject. Even more annoying. Best regards Andreas ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: miibus0: mii_mediachg: can't handle non-zero PHY instance 31
On Mon, Apr 07, 2014 at 09:40:53AM -0700, Chris H wrote: On Sun, Apr 06, 2014 at 10:49:27PM -0700, Chris H wrote: On Thu, Apr 03, 2014 at 01:18:19PM -0700, Chris H wrote: On Tue, Apr 01, 2014 at 05:53:51PM -0700, Chris H wrote: On Tue, Apr 01, 2014 at 01:40:58PM -0700, Chris H wrote: On Tue, 2014-04-01 at 13:19 -0700, Chris H wrote: [...] miibus0: MII bus on nfe0 rlphy0: RTL8201L 10/100 media interface PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy1: RTL8201L 10/100 media interface PHY 1 on miibus0 [...]---big-snip--8--- miibus0: mii_mediachg: can't handle non-zero PHY instance 1 As you can see, it looks much the same. I have no idea what I should do to better inform the driver/kernel how to better handle it. Or is it the driver, itself? Thank you again, for your thoughtful response. --Chris I think the way to fix a phy that responds at all addresses is to set a hint in loader.conf masking out the ones that aren't real, like so: hint.miibus.0.phymask=1 You might be able to set =0x0001 to make it more clear it's a bitmask, but I'm not sure of that. Thank you very much for the hint. I'll give it a shot. Any idea why this is happening? I have 4 other MB's using the Nvidia chipset, and the nfe(4) driver. But they don't respond this way. If some nfe(4) variants badly behave in probing stage, this should be handled by driver. We already have too many hints and tunables and I don't think most users know that. In addition, adding additional NIC may change miibus instance number. Could you show me the output of 'kenv | grep smbios'? Yes, of course. Here it is: smbios.bios.reldate=11/22/2010 smbios.bios.vendor=American Megatrends Inc. smbios.bios.version=V2.7 smbios.chassis.maker=MSI smbios.chassis.serial=To Be Filled By O.E.M. smbios.chassis.tag=To Be Filled By O.E.M. smbios.chassis.version=2.0 smbios.memory.enabled=2097152 smbios.planar.maker=MSI smbios.planar.product=K9N6PGM2-V2 (MS-7309) smbios.planar.serial=To be filled by O.E.M. smbios.planar.version=2.0 smbios.socket.enabled=1 smbios.socket.populated=1 smbios.system.maker=MSI smbios.system.product=MS-7309 smbios.system.serial=To Be Filled By O.E.M. smbios.system.uuid=----406186cd4497 smbios.system.version=2.0 smbios.version=2.6 Hope this helps, and thank you for all your time, and trouble. Thanks for the info. Try attached patch and let me know how it works. Make sure to remove the hint(hint.miibus.0.phymask=1) set in loader.conf before testing it. Hello, and thanks for all the attention. Sorry for the delay. I chose to perform a dump(8) before attempting the KERn rebuild with the patch. But the kernel threw a read error message on one of the drives. So I had to sort out the problem on the drive before I could complete the dump. Then, of course I had to reslice, and format another drive to replace the ailing one, before I could perform a restore(8), and start the nfe patch; build install kernel. Weird; the drive had only a few hours on it. Well, anyway. The patch applied cleanly. So I built, and installed a new kernel with it. X's out the hint.miibus.0.phymask=0x0001 in loader.conf(5), and bounced the box. Bad news: miibus0: mii_mediachg: can't handle non-zero PHY instance 31 miibus0: mii_mediachg: can't handle non-zero PHY instance 30 miibus0: mii_mediachg: can't handle non-zero PHY instance 29 miibus0: mii_mediachg: can't handle non-zero PHY instance 28 miibus0: mii_mediachg: can't handle non-zero PHY instance 27 miibus0: mii_mediachg: can't handle non-zero PHY instance 26 miibus0: mii_mediachg: can't handle non-zero PHY instance 25 miibus0: mii_mediachg: can't handle non-zero PHY instance 24 miibus0: mii_mediachg: can't handle non-zero PHY instance 23 miibus0: mii_mediachg: can't handle non-zero PHY instance 22 miibus0: mii_mediachg: can't handle non-zero PHY instance 21 miibus0: mii_mediachg: can't handle non-zero PHY instance 20 miibus0: mii_mediachg: can't handle non-zero PHY instance 19 miibus0: mii_mediachg: can't handle non-zero PHY instance 18 miibus0: mii_mediachg: can't handle non-zero PHY instance 17 miibus0: mii_mediachg: can't handle non-zero PHY instance 16 miibus0: mii_mediachg: can't handle non-zero PHY instance 15 miibus0: mii_mediachg: can't handle non-zero PHY instance 14 miibus0: mii_mediachg: can't handle non-zero PHY instance 13 miibus0: mii_mediachg: can't handle non-zero PHY instance 12 miibus0: mii_mediachg: can't handle non-zero PHY instance 11 miibus0: mii_mediachg: can't
Re: re0: watchdog timeout
On Mon, Apr 07, 2014 at 08:45:00PM +0200, Frank Volf wrote: Yonghyeon PYUN schreef op 7-4-2014 10:32: It would be even better to know your network configuration. I'm not sure why you have to disable VLAN hardware tagging. But given that you've disabled it, could you also try disabling VLAN hardware checksum offloading? Hi, The reason that I disable VLAN hardware tagging is that the system does not work with it enabled. To show this, see the following transcript (on a freshly booted system): [...] Okat, I'll check VLAN hardware tagging with RTL8168G but watchdog timeout is different issue. I have no idea why this happens at this moment but I'll let you know if I find a clue. Anyway, thanks for reporting. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
