Re: [PATCH 4/6] sfxge: add counter for Tx errors returned from if_transmit
On Mar 18, 2014, at 22:44, Andrew Rybchenko andrew.rybche...@oktetlabs.ru wrote: Is the any best practice how to send patches to mailing list? I believe this is not documented anywhere, but it's best to send patches as attachments. -- Rui Paulo ___ 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: DCTCP implementation
On Sun, Mar 30, 2014 at 10:37 PM, Midori Kato kat...@sfc.wide.ad.jp wrote: Hi FreeBSD developpers, I'm Midori Kato. I'm working on the DCTCP implementation in the FreeBSD with Lars Eggert. I mail you because I would like to ask you a code review and testing. The attached patch is not good enough to test our code. Please give me your message. I will send an ECN marking implmenetation in dummynet and test scripts personally to you. Hi Midori, Thank you for your work and I'd like to test this. Please let me know how you setup the dummynet testing cluster and I'll try it. cheers, Hiren ccing gnn@ as he was also asking for the same (testing details). ___ 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, Mar 31, 2014 at 07:57:28AM -0700, Chris H wrote: On Sun, Mar 30, 2014 at 01:12:20PM -0700, chr...@ultimatedns.net wrote: Greetings, I'm not sure whether this best belonged on net@, or stable@ so I'm using both. :) I'm testing both releng_9, and MB, and I encountered a new message I don't usually see using the nfe(4) driver: miibus0: mii_mediachg: can't handle non-zero PHY instance 1 ... miibus0: mii_mediachg: can't handle non-zero PHY instance 31 Truncated for brevity (31 lines in total; 1-31). I don't know how interpret this. An issue with my version of the driver, or the hardware itself? This occurred with both GENERIC, as well as my custom kernel. Would you show me the dmesg output? Happily: Calibrating TSC clock ... TSC clock: 3231132841 Hz CPU: AMD Sempron(tm) 140 Processor (3231.13-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x100f62 Family = 0x10 Model = 0x6 Stepping = 2 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 Features2=0x802009SSE3,MON,CX16,POPCNT AMD Features=0xee500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow! AMD Features2=0x37fdLAHF,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT [...] nfe0: NVIDIA nForce MCP61 Networking Adapter port 0xe480-0xe487 mem 0xdff7d000-0xdff7dfff irq 20 at device 7.0 on pci0 nfe0: attempting to allocate 8 MSI vectors (8 supported) msi: routing MSI IRQ 257 to local APIC 0 vector 56 msi: routing MSI IRQ 258 to local APIC 0 vector 57 msi: routing MSI IRQ 259 to local APIC 0 vector 58 msi: routing MSI IRQ 260 to local APIC 0 vector 59 msi: routing MSI IRQ 261 to local APIC 0 vector 60 msi: routing MSI IRQ 262 to local APIC 0 vector 61 msi: routing MSI IRQ 263 to local APIC 0 vector 62 msi: routing MSI IRQ 264 to local APIC 0 vector 63 nfe0: using IRQs 257-264 for MSI nfe0: Using 8 MSI messages miibus0: MII bus on nfe0 rlphy0: RTL8201L 10/100 media interface PHY 0 on miibus0 rlphy0: OUI 0x04, model 0x0020, rev. 1 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy1: RTL8201L 10/100 media interface PHY 1 on miibus0 rlphy1: OUI 0x04, model 0x0020, rev. 1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow [...] rlphy30: RTL8201L 10/100 media interface PHY 30 on miibus0 rlphy30: OUI 0x04, model 0x0020, rev. 1 rlphy30: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy31: RTL8201L 10/100 media interface PHY 31 on miibus0 rlphy31: OUI 0x04, model 0x0020, rev. 1 rlphy31: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow nfe0: bpf attached nfe0: Ethernet address: 40:61:86:cd:44:97 mii(4) thinks it has 32 PHYs and this is the reason why mii(4) complains. Due to unknown reason, accessing PHY registers in device probe stage got valid response which in turn makes the driver think there are 32 PHYs. Did you ever see this this kind of message on old FreeBSD release? Or could you try cold-boot and see whether it makes any difference? ___ 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: DCTCP implementation
Hi, On 2014-3-31, at 7:37, Midori Kato kat...@sfc.wide.ad.jp wrote: I will send an ECN marking implmenetation in dummynet and test scripts personally to you. I think you can send the dummynet ECN patch also to the list. I know Luigi is reviewing it for a merge, but that lets people play with it already. Lars signature.asc Description: Message signed with OpenPGP using GPGMail
Re: FreeBSD 10-STABLE and CARP states
PING On 31 mar 2014, at 22:21, mxb m...@alumni.chalmers.se wrote: Manually setting net.inet.carp.demotion brought BOTH VHIDs in desired state. pfsync bulk update seems to not put everything back as it should. lagg0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 9000 options=8407bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO ether 00:25:90:e3:71:f2 inet 172.16.0.234 netmask 0xf800 broadcast 172.16.7.255 inet6 fe80::225:90ff:fee3:71f2%lagg0 prefixlen 64 scopeid 0x5 inet 172.16.0.231 netmask 0xf800 broadcast 172.16.7.255 vhid 201 inet 172.16.0.233 netmask 0xf800 broadcast 172.16.7.255 vhid 202 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect status: active carp: MASTER vhid 201 advbase 1 advskew 1 carp: BACKUP vhid 202 advbase 5 advskew 100 laggproto lacp lagghash l2,l3,l4 laggport: ix1 flags=1cACTIVE,COLLECTING,DISTRIBUTING laggport: ix0 flags=1cACTIVE,COLLECTING,DISTRIBUTING On 31 mar 2014, at 20:42, mxb m...@alumni.chalmers.se wrote: Hi list, hopefully this is the right place to have my question regarding CARP on 10-STABLE. I have two nodes with following setup(node1): lagg0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 9000 options=8407bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO ether 00:25:90:e3:71:f2 inet 172.16.0.234 netmask 0xf800 broadcast 172.16.7.255 inet6 fe80::225:90ff:fee3:71f2%lagg0 prefixlen 64 scopeid 0x5 inet 172.16.0.231 netmask 0xf800 broadcast 172.16.7.255 vhid 201 inet 172.16.0.233 netmask 0xf800 broadcast 172.16.7.255 vhid 202 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect status: active carp: BACKUP vhid 201 advbase 1 advskew 1 carp: BACKUP vhid 202 advbase 5 advskew 100 laggproto lacp lagghash l2,l3,l4 laggport: ix1 flags=1cACTIVE,COLLECTING,DISTRIBUTING laggport: ix0 flags=1cACTIVE,COLLECTING,DISTRIBUTING net.inet.carp.preempt=1 on both nodes. as well as PSYNC as this: pfsync0: flags=41UP,RUNNING metric 0 mtu 1500 pfsync: syncdev: vlan22 syncpeer: 10.22.22.2 maxupd: 128 defer: off The problem is (if it is not clear from the ifconfig-output for the lagg0) the state of VHID 201. Node2 with advskew of 100 is currently MASTER, but it SHOULD NOT as of setup. Am I hitting a bug or doing something wrong? I also have noted that after the pfsync bulk update the demotion counter never setts to 0, but stays on 480, thus preventing node1 become a MASTER 201(?). Or is this a normal behavior? Regards, mxb ___ 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: questions about (system) dhclient
On Mon, Mar 31, 2014 at 4:31 PM, Robert Huff roberth...@rcn.com wrote: [Please keep me CC'd as I am not subscribed. Thanks.] I have a system, running r263263, where dhclient is misbehaving. (Yes - this is CURRENT, but I have no reason to believe this inherently a version-specific issue. I am also on current@, and nothing like this has been reported.) The system has an Intel Pro/1000 ethernet card, em0, connected to a Arris CM820 cable modem. This is the relevant portion of dhclient.conf: http://users.rcn.com/dhclient.conf Upon execution, I get this: http://users.rcn.com/roberthuff/dhcp_offer The conversation between a DHCP server and client consists of the initial DHCP DISCOVER request from the client broadcasted to the network to which a DHCP ACK is expected in reply from an available DHCP server. Upon receipt of DHCP ACK, the client sends another DHCP DISCOVER to the server asking for configuration information necessary to initialize networking. The server's response is a DHCP OFFER containing all the information requested by the client. I illustrate this in a sequence diagram describing a PXE workflow for FreeBSD installation at http://hostileadmin.com/images/FreeBSD_PXE_Install_Workflow.gif. The first four steps in the sequence is the workflow's first DHCP conversation. This output suggests only half of the conversation was completed. The client doesn't appear to have sent the second DHCP DISCOVER and thusly did not receive configuration information from the server. Have you ran packet captures to determine whether or not the whole conversation is occurring? -- Take care Rick Miller ___ 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: questions about (system) dhclient
Hello Robert, Rick and FreeBSD friends, On Tue, Apr 01, 2014 at 08:48:21AM -0400, Rick Miller wrote: On Mon, Mar 31, 2014 at 4:31 PM, Robert Huff roberth...@rcn.com wrote: [Please keep me CC'd as I am not subscribed. Thanks.] I have a system, running r263263, where dhclient is misbehaving. (Yes - this is CURRENT, but I have no reason to believe this inherently a version-specific issue. I am also on current@, and nothing like this has been reported.) The system has an Intel Pro/1000 ethernet card, em0, connected to a Arris CM820 cable modem. This is the relevant portion of dhclient.conf: http://users.rcn.com/dhclient.conf Upon execution, I get this: http://users.rcn.com/roberthuff/dhcp_offer The conversation between a DHCP server and client consists of the initial DHCP DISCOVER request from the client broadcasted to the network to which a DHCP ACK is expected in reply from an available DHCP server. Upon receipt of DHCP ACK, the client sends another DHCP DISCOVER to the server asking for configuration information necessary to initialize networking. The server's response is a DHCP OFFER containing all the information requested by the client. I illustrate this in a sequence diagram describing a PXE workflow for FreeBSD installation at http://hostileadmin.com/images/FreeBSD_PXE_Install_Workflow.gif. The first four steps in the sequence is the workflow's first DHCP conversation. This output suggests only half of the conversation was completed. The client doesn't appear to have sent the second DHCP DISCOVER and thusly did not receive configuration information from the server. Have you ran packet captures to determine whether or not the whole conversation is occurring? -- Take care Rick Miller ___ 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 Does em0 supports TSO? and do you have ipfw running at the same time? run ifconfig em0 and look for TSO! I had some issues with bge0 and TSO. I noticed that both, natd and, most importantly for your problem, dhcpd were increasingly using CPU load when an error occurred by sending an e-mail above a particular size. I figured out via the help of freebsd friends that ipfw and TSO are not compatible. Disabling TSO4 on bge0 solved the issue with sendmail and the CPU load of natd and dhcpd. Maybe you are facing a similar problem. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans e-mail: wi...@offermans.rompen.nl Powered by (__) \\\'',) \/ \ ^ .\._/_) www.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: questions about (system) dhclient
On Apr 1, 2014, at 7:48 AM, Rick Miller vmil...@hostileadmin.com wrote: On Mon, Mar 31, 2014 at 4:31 PM, Robert Huff roberth...@rcn.com wrote: [Please keep me CC'd as I am not subscribed. Thanks.] I have a system, running r263263, where dhclient is misbehaving. (Yes - this is CURRENT, but I have no reason to believe this inherently a version-specific issue. I am also on current@, and nothing like this has been reported.) The system has an Intel Pro/1000 ethernet card, em0, connected to a Arris CM820 cable modem. This is the relevant portion of dhclient.conf: http://users.rcn.com/dhclient.conf Upon execution, I get this: http://users.rcn.com/roberthuff/dhcp_offer The conversation between a DHCP server and client consists of the initial DHCP DISCOVER request from the client broadcasted to the network to which a DHCP ACK is expected in reply from an available DHCP server. Upon receipt of DHCP ACK, the client sends another DHCP DISCOVER to the server asking for configuration information necessary to initialize networking. The server's response is a DHCP OFFER containing all the information requested by the client. I illustrate this in a sequence diagram describing a PXE workflow for FreeBSD installation at http://hostileadmin.com/images/FreeBSD_PXE_Install_Workflow.gif. The first four steps in the sequence is the workflow's first DHCP conversation. The description of the DHCP packet flow is incorrect. DHCP packet flow is the following for clients requesting a new lease. Diagram below copied from RFC 2131. For clients renewing a lease, only the REQUEST and ACK steps are done. Server Client Server (not selected)(selected) v v v | | | | Begins initialization | | | | | _/|\ | |/DHCPDISCOVER | DHCPDISCOVER \| | | | Determines | Determines configuration| configuration | | | |\ | / | | \| /DHCPOFFER | | DHCPOFFER\ |/ | | \ || | Collects replies| | \|| | Selects configuration | | | | | _/|\ | |/ DHCPREQUEST | DHCPREQUEST\ | | | | | | Commits configuration | | | | | _/| | |/ DHCPACK | | | | |Initialization complete| | | | . . . . . . | | | | Graceful shutdown| | | | | |\ | | | DHCPRELEASE \| | | | | |Discards lease | | | v v v Figure 3: Timeline diagram of messages exchanged between DHCP client and servers when allocating a new network address -- DaveD ___ 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: questions about (system) dhclient
Willy Offermans wi...@offermans.rompen.nl Does em0 supports TSO? No: see http://users.rcn.com/roberthuff/dhc_ifconfig;. Or at least it's not enabled. and do you have ipfw running at the same time? Yes ... but this setup has been running with the same ipfw rules for years. The only change is the version of the system. (Which _might_ make this a problem for current@, but I want to eliminate other possibilities first.) I figured out via the help of freebsd friends that ipfw and TSO are not compatible. Disabling TSO4 on bge0 solved the issue with sendmail Um - what issue with sendmail? I did a packet-dump; greping for dhcp produces http://users.rcn.com/roberthuff/tdump2.txt;. (The full dump is 1.7 mbytes, and I don't have a place to make it public.) If there's something else I should be looking for, please let me know. Respectfully Robert Huff ___ 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: questions about (system) dhclient
Dave Duchscher writes: The description of the DHCP packet flow is incorrect. DHCP packet flow is the following for clients requesting a new lease. Diagram below copied from RFC 2131. For clients renewing a lease, only the REQUEST and ACK steps are done. Server Client Server (not selected)(selected) v v v | | | | Begins initialization | | | | | _/|\ | |/DHCPDISCOVER | DHCPDISCOVER \| | | | Determines | Determines configuration| configuration | | | |\ | / | | \| /DHCPOFFER | | DHCPOFFER\ |/ | | \ || | Collects replies| | \|| | Selects configuration | | | | | _/|\ | |/ DHCPREQUEST | DHCPREQUEST\ | | | | | | Commits configuration | | | | | _/| | |/ DHCPACK | | | | |Initialization complete| | | | . . . . . . | | | | Graceful shutdown| | | | | |\ | | | DHCPRELEASE \| | | | | |Discards lease | | | v v v Synopsis of my (apparent) problem: DISCOVER, OFFER, REQUEST, and ACKNOWLEDGEMENT all happen correctly ... but the information doesn't make it to ifconfig or the routing table. Robert Huff ___ 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: questions about (system) dhclient
On Tue, Apr 1, 2014 at 10:46 AM, Dave Duchscher da...@tamu.edu wrote: On Apr 1, 2014, at 7:48 AM, Rick Miller vmil...@hostileadmin.com wrote: The conversation between a DHCP server and client consists of the initial DHCP DISCOVER request from the client broadcasted to the network to which a DHCP ACK is expected in reply from an available DHCP server. Upon receipt of DHCP ACK, the client sends another DHCP DISCOVER to the server asking for configuration information necessary to initialize networking. The server's response is a DHCP OFFER containing all the information requested by the client. I illustrate this in a sequence diagram describing a PXE workflow for FreeBSD installation at http://hostileadmin.com/images/FreeBSD_PXE_Install_Workflow.gif. The first four steps in the sequence is the workflow's first DHCP conversation. The description of the DHCP packet flow is incorrect. DHCP packet flow is the following for clients requesting a new lease. Diagram below copied from RFC 2131. For clients renewing a lease, only the REQUEST and ACK steps are done. Thanks, Dave...I did mix up the terminology. -- Take care Rick Miller ___ 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, Mar 31, 2014 at 07:57:28AM -0700, Chris H wrote: On Sun, Mar 30, 2014 at 01:12:20PM -0700, chr...@ultimatedns.net wrote: Greetings, I'm not sure whether this best belonged on net@, or stable@ so I'm using both. :) I'm testing both releng_9, and MB, and I encountered a new message I don't usually see using the nfe(4) driver: miibus0: mii_mediachg: can't handle non-zero PHY instance 1 ... miibus0: mii_mediachg: can't handle non-zero PHY instance 31 Truncated for brevity (31 lines in total; 1-31). I don't know how interpret this. An issue with my version of the driver, or the hardware itself? This occurred with both GENERIC, as well as my custom kernel. Would you show me the dmesg output? Happily: Calibrating TSC clock ... TSC clock: 3231132841 Hz CPU: AMD Sempron(tm) 140 Processor (3231.13-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x100f62 Family = 0x10 Model = 0x6 Stepping = 2 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 Features2=0x802009SSE3,MON,CX16,POPCNT AMD Features=0xee500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow! AMD Features2=0x37fdLAHF,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT [...] nfe0: NVIDIA nForce MCP61 Networking Adapter port 0xe480-0xe487 mem 0xdff7d000-0xdff7dfff irq 20 at device 7.0 on pci0 nfe0: attempting to allocate 8 MSI vectors (8 supported) msi: routing MSI IRQ 257 to local APIC 0 vector 56 msi: routing MSI IRQ 258 to local APIC 0 vector 57 msi: routing MSI IRQ 259 to local APIC 0 vector 58 msi: routing MSI IRQ 260 to local APIC 0 vector 59 msi: routing MSI IRQ 261 to local APIC 0 vector 60 msi: routing MSI IRQ 262 to local APIC 0 vector 61 msi: routing MSI IRQ 263 to local APIC 0 vector 62 msi: routing MSI IRQ 264 to local APIC 0 vector 63 nfe0: using IRQs 257-264 for MSI nfe0: Using 8 MSI messages miibus0: MII bus on nfe0 rlphy0: RTL8201L 10/100 media interface PHY 0 on miibus0 rlphy0: OUI 0x04, model 0x0020, rev. 1 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy1: RTL8201L 10/100 media interface PHY 1 on miibus0 rlphy1: OUI 0x04, model 0x0020, rev. 1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow [...] rlphy30: RTL8201L 10/100 media interface PHY 30 on miibus0 rlphy30: OUI 0x04, model 0x0020, rev. 1 rlphy30: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy31: RTL8201L 10/100 media interface PHY 31 on miibus0 rlphy31: OUI 0x04, model 0x0020, rev. 1 rlphy31: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow nfe0: bpf attached nfe0: Ethernet address: 40:61:86:cd:44:97 mii(4) thinks it has 32 PHYs and this is the reason why mii(4) complains. Due to unknown reason, accessing PHY registers in device probe stage got valid response which in turn makes the driver think there are 32 PHYs. Did you ever see this this kind of message on old FreeBSD release? Or could you try cold-boot and see whether it makes any difference? Greetings, and thank you for taking the time to respond. I downloaded, and booted to the 8.4-memstick. Droped to FIXIT, and captured the dmesg(8) output. I don't know how much of it you need, so I am including it all: Table 'FACP' at 0x6ffa0200 Table 'APIC' at 0x6ffa0390 APIC: Found table at 0x6ffa0390 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 129 ACPI ID 2: disabled MADT: Found CPU APIC ID 130 ACPI ID 3: disabled MADT: Found CPU APIC ID 131 ACPI ID 4: disabled MADT: Found CPU APIC ID 132 ACPI ID 5: disabled MADT: Found CPU APIC ID 133 ACPI ID 6: disabled Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.4-RELEASE #0 r251259: Sun Jun 2 21:26:57 UTC 2013 r...@bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 gcc version 4.2.1 20070831 patched [FreeBSD] Preloaded elf kernel /boot/kernel/kernel at 0x8146d000. Preloaded mfs_root /boot/mfsroot at 0x8146d200. Timecounter i8254 frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 3231096596 Hz CPU: AMD Sempron(tm) 140 Processor (3231.10-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x100f62 Family = 10 Model = 6 Stepping = 2 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 Features2=0x802009SSE3,MON,CX16,POPCNT AMD Features=0xee500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow! AMD Features2=0x37fdLAHF,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT TSC: P-state invariant L1 2MB data TLB: 48 entries, fully associative L1 2MB instruction TLB: 16 entries, fully
Re: miibus0: mii_mediachg: can't handle non-zero PHY instance 31
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 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy2: RTL8201L 10/100 media interface PHY 2 on miibus0 rlphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy3: RTL8201L 10/100 media interface PHY 3 on miibus0 rlphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy4: RTL8201L 10/100 media interface PHY 4 on miibus0 rlphy4: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy5: RTL8201L 10/100 media interface PHY 5 on miibus0 rlphy5: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy6: RTL8201L 10/100 media interface PHY 6 on miibus0 rlphy6: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy7: RTL8201L 10/100 media interface PHY 7 on miibus0 rlphy7: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy8: RTL8201L 10/100 media interface PHY 8 on miibus0 rlphy8: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy9: RTL8201L 10/100 media interface PHY 9 on miibus0 rlphy9: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy10: RTL8201L 10/100 media interface PHY 10 on miibus0 rlphy10: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy11: RTL8201L 10/100 media interface PHY 11 on miibus0 rlphy11: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy12: RTL8201L 10/100 media interface PHY 12 on miibus0 rlphy12: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy13: RTL8201L 10/100 media interface PHY 13 on miibus0 rlphy13: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy14: RTL8201L 10/100 media interface PHY 14 on miibus0 rlphy14: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy15: RTL8201L 10/100 media interface PHY 15 on miibus0 rlphy15: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy16: RTL8201L 10/100 media interface PHY 16 on miibus0 rlphy16: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy17: RTL8201L 10/100 media interface PHY 17 on miibus0 rlphy17: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy18: RTL8201L 10/100 media interface PHY 18 on miibus0 rlphy18: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy19: RTL8201L 10/100 media interface PHY 19 on miibus0 rlphy19: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy20: RTL8201L 10/100 media interface PHY 20 on miibus0 rlphy20: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy21: RTL8201L 10/100 media interface PHY 21 on miibus0 rlphy21: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy22: RTL8201L 10/100 media interface PHY 22 on miibus0 rlphy22: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy23: RTL8201L 10/100 media interface PHY 23 on miibus0 rlphy23: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy24: RTL8201L 10/100 media interface PHY 24 on miibus0 rlphy24: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy25: RTL8201L 10/100 media interface PHY 25 on miibus0 rlphy25: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy26: RTL8201L 10/100 media interface PHY 26 on miibus0 rlphy26: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy27: RTL8201L 10/100 media interface PHY 27 on miibus0 rlphy27: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy28: RTL8201L 10/100 media interface PHY 28 on miibus0 rlphy28: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy29: RTL8201L 10/100 media interface PHY 29 on miibus0 rlphy29: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy30: RTL8201L 10/100 media interface PHY 30 on miibus0 rlphy30: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy31: RTL8201L 10/100 media interface PHY 31 on miibus0 rlphy31: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow [...] 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
Re: miibus0: mii_mediachg: can't handle non-zero PHY instance 31
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. Thank you again, for your helpful reply. I'll report back with my findings. --Chris -- Ian ___ 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 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. Thank you again, for your helpful reply. I'll report back with my findings. --Chris OK. As promised. Here's the results. For the record, I used the following in loader.conf(5): hint.miibus.0.phymask=0x0001 Here's the output (minus the sound card stuff): Syncing disks, vnodes remaining...8 8 4 4 1 0 1 1 1 1 0 0 done All buffers synced. Table 'FACP' at 0x6ffa0200 Table 'APIC' at 0x6ffa0390 APIC: Found table at 0x6ffa0390 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 129 ACPI ID 2: disabled MADT: Found CPU APIC ID 130 ACPI ID 3: disabled MADT: Found CPU APIC ID 131 ACPI ID 4: disabled MADT: Found CPU APIC ID 132 ACPI ID 5: disabled MADT: Found CPU APIC ID 133 ACPI ID 6: disabled Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.2-STABLE #0 r263756: Wed Mar 26 11:28:10 PDT 2014 root@demon0:/usr/obj/usr/src/sys/DEMON0 amd64 gcc version 4.2.1 20070831 patched [FreeBSD] Preloaded elf kernel /boot/kernel/kernel at 0x81d9d000. Preloaded elf obj module /boot/kernel/linux.ko at 0x81d9d200. Preloaded elf obj module /boot/modules/nvidia.ko at 0x81d9db28. Calibrating TSC clock ... TSC clock: 3231148565 Hz CPU: AMD Sempron(tm) 140 Processor (3231.15-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x100f62 Family = 0x10 Model = 0x6 Stepping = 2 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 Features2=0x802009SSE3,MON,CX16,POPCNT AMD Features=0xee500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow! AMD Features2=0x37fdLAHF,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT TSC: P-state invariant L1 2MB data TLB: 48 entries, fully associative L1 2MB instruction TLB: 16 entries, fully associative L1 4KB data TLB: 48 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB data TLB: 128 entries, 2-way associative L2 2MB instruction TLB: 0 entries, 2-way associative L2 4KB data TLB: 512 entries, 4-way associative L2 4KB instruction TLB: 512 entries, 4-way associative L2 unified cache: 1024 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative real memory = 2147483648 (2048 MB) Physical memory chunk(s): 0x0001 - 0x0009bfff, 573440 bytes (140 pages) 0x0010 - 0x001f, 1048576 bytes (256 pages) 0x01dcc000 - 0x6cab2fff, 1791913984 bytes (437479 pages) avail memory = 1777266688 (1694 MB) INTR: Adding local APIC 0 as a target Event timer LAPIC quality 400 ACPI APIC Table: 7309MS A7309200 x86bios: IVT 0x00-0x0004ff at 0xfe00 x86bios: SSEG 0x098000-0x098fff at 0xff8000226000 x86bios: EBDA 0x09f000-0x09 at 0xfe09f000 x86bios: ROM 0x0a-0x0fefff at 0xfe0a APIC: CPU 0 has ACPI ID 1 ULE: setup cpu 0 ACPI: RSDP 0xfaab0 00014 (v00 ACPIAM) ACPI: RSDT 0x6ffa 00048 (v01 7309MS A7309200 20101122 MSFT 0097) ACPI: FACP 0x6ffa0200 00084 (v01 7309MS A7309200 20101122 MSFT 0097) ACPI: DSDT 0x6ffa04b0 0503B (v01 A7309 A7309200 0200 INTL 20051117) ACPI: FACS 0x6ffae000 00040 ACPI: APIC 0x6ffa0390 00090 (v01 7309MS A7309200 20101122 MSFT 0097) ACPI: MCFG 0x6ffa0420 0003C (v01 7309MS OEMMCFG 20101122 MSFT 0097) ACPI: WDRT 0x6ffa0460 00047 (v01 7309MS NV-WDRT 20101122 MSFT 0097) ACPI: OEMB 0x6ffae040 00072 (v01 7309MS A7309200 20101122 MSFT 0097) ACPI: SRAT 0x6ffaa4b0 00090 (v03 AMDFAM_F_10 0002 AMD 0001) ACPI: MSCT 0x6ffaa540 0004E (v01 A M I OEMBOARD 0001
Re: miibus0: mii_mediachg: can't handle non-zero PHY instance 31
On Apr 1, 2014, at 12:58 AM, Yonghyeon PYUN pyu...@gmail.com wrote: On Mon, Mar 31, 2014 at 07:57:28AM -0700, Chris H wrote: On Sun, Mar 30, 2014 at 01:12:20PM -0700, chr...@ultimatedns.net wrote: Greetings, I'm not sure whether this best belonged on net@, or stable@ so I'm using both. :) I'm testing both releng_9, and MB, and I encountered a new message I don't usually see using the nfe(4) driver: miibus0: mii_mediachg: can't handle non-zero PHY instance 1 ... miibus0: mii_mediachg: can't handle non-zero PHY instance 31 Truncated for brevity (31 lines in total; 1-31). I don't know how interpret this. An issue with my version of the driver, or the hardware itself? This occurred with both GENERIC, as well as my custom kernel. Would you show me the dmesg output? Happily: Calibrating TSC clock ... TSC clock: 3231132841 Hz CPU: AMD Sempron(tm) 140 Processor (3231.13-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x100f62 Family = 0x10 Model = 0x6 Stepping = 2 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 Features2=0x802009SSE3,MON,CX16,POPCNT AMD Features=0xee500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow! AMD Features2=0x37fdLAHF,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT [...] nfe0: NVIDIA nForce MCP61 Networking Adapter port 0xe480-0xe487 mem 0xdff7d000-0xdff7dfff irq 20 at device 7.0 on pci0 nfe0: attempting to allocate 8 MSI vectors (8 supported) msi: routing MSI IRQ 257 to local APIC 0 vector 56 msi: routing MSI IRQ 258 to local APIC 0 vector 57 msi: routing MSI IRQ 259 to local APIC 0 vector 58 msi: routing MSI IRQ 260 to local APIC 0 vector 59 msi: routing MSI IRQ 261 to local APIC 0 vector 60 msi: routing MSI IRQ 262 to local APIC 0 vector 61 msi: routing MSI IRQ 263 to local APIC 0 vector 62 msi: routing MSI IRQ 264 to local APIC 0 vector 63 nfe0: using IRQs 257-264 for MSI nfe0: Using 8 MSI messages miibus0: MII bus on nfe0 rlphy0: RTL8201L 10/100 media interface PHY 0 on miibus0 rlphy0: OUI 0x04, model 0x0020, rev. 1 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy1: RTL8201L 10/100 media interface PHY 1 on miibus0 rlphy1: OUI 0x04, model 0x0020, rev. 1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow [...] rlphy30: RTL8201L 10/100 media interface PHY 30 on miibus0 rlphy30: OUI 0x04, model 0x0020, rev. 1 rlphy30: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy31: RTL8201L 10/100 media interface PHY 31 on miibus0 rlphy31: OUI 0x04, model 0x0020, rev. 1 rlphy31: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow nfe0: bpf attached nfe0: Ethernet address: 40:61:86:cd:44:97 mii(4) thinks it has 32 PHYs and this is the reason why mii(4) complains. Due to unknown reason, accessing PHY registers in device probe stage got valid response which in turn makes the driver think there are 32 PHYs. Did you ever see this this kind of message on old FreeBSD release? Or could you try cold-boot and see whether it makes any difference? I’ve seen this a few times when the resources were AFU on CardBus cards.. But never this coherently… I’ve also seen it during early bring up when I got the MII address wrong, but you should be well past that with the rl driver :) The voices in Bill Paul’s head from that are almost old enough to collect retirement... Warner ___ 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 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'? ___ 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 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. --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
Gigabyte BIOS/UEFI and WOL
So far I've tried and failed to get a Gigabyte GA-Z68A-D3H-B3 to wake from the network. It had the most recent BIOS (F13), which did not have a WOL option. A UEFI BIOS is available, so I've installed that, and still failed to get it to wake up. There are a bewildering number of undocumented options, none of which mentions WOL. Adding an Intel PCI card made no difference. The card LEDs are on when the system is off, but it still doesn't wake up. Once manually started, the system works fine, and ifconfig shows WOL_MAGIC. Any suggestions on things to try? I'm open to going back to a normal BIOS... if it will let me. It runs fine either way. ___ 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 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.
--Chris
Index: sys/dev/nfe/if_nfe.c
===
--- sys/dev/nfe/if_nfe.c (revision 264031)
+++ sys/dev/nfe/if_nfe.c (working copy)
@@ -79,6 +79,7 @@ static int nfe_suspend(device_t);
static int nfe_resume(device_t);
static int nfe_shutdown(device_t);
static int nfe_can_use_msix(struct nfe_softc *);
+static int nfe_detect_msik9(struct nfe_softc *);
static void nfe_power(struct nfe_softc *);
static int nfe_miibus_readreg(device_t, int, int);
static int nfe_miibus_writereg(device_t, int, int, int);
@@ -334,13 +335,38 @@ nfe_alloc_msix(struct nfe_softc *sc, int count)
}
}
+
static int
+nfe_detect_msik9(struct nfe_softc *sc)
+{
+ static char *maker = MSI;
+ static char *product = K9N6PGM2-V2 (MS-7309);
+ char *m, *p;
+ int found;
+
+ found = 0;
+ m = getenv(smbios.planar.maker);
+ p = getenv(smbios.planar.product);
+ if (m != NULL p != NULL) {
+ if (strcmp(m, maker) == 0 strcmp(p, product) == 0)
+ found = 1;
+ }
+ if (m != NULL)
+ freeenv(m);
+ if (p != NULL)
+ freeenv(p);
+
+ return (found);
+}
+
+
+static int
nfe_attach(device_t dev)
{
struct nfe_softc *sc;
struct ifnet *ifp;
bus_addr_t dma_addr_max;
- int error = 0, i, msic, reg, rid;
+ int error = 0, i, msic, phyloc, reg, rid;
sc = device_get_softc(dev);
sc-nfe_dev = dev;
@@ -608,8 +634,13 @@ nfe_attach(device_t dev)
#endif
/* Do MII setup */
+ phyloc = MII_PHY_ANY;
+ if (sc-nfe_devid == PCI_PRODUCT_NVIDIA_MCP61_LAN1) {
+ if (nfe_detect_msik9(sc) != 0)
+ phyloc = 0;
+ }
error = mii_attach(dev, sc-nfe_miibus, ifp, nfe_ifmedia_upd,
- nfe_ifmedia_sts, BMSR_DEFCAPMASK, MII_PHY_ANY, MII_OFFSET_ANY,
+ nfe_ifmedia_sts, BMSR_DEFCAPMASK, phyloc, MII_OFFSET_ANY,
MIIF_DOPAUSE);
if (error != 0) {
device_printf(dev, attaching PHYs failed\n);
___
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: Gigabyte BIOS/UEFI and WOL
On Tue, 1 Apr 2014, Warren Block wrote: So far I've tried and failed to get a Gigabyte GA-Z68A-D3H-B3 to wake from the network. It had the most recent BIOS (F13), which did not have a WOL option. A UEFI BIOS is available, so I've installed that, and still failed to get it to wake up. There are a bewildering number of undocumented options, none of which mentions WOL. Adding an Intel PCI card made no difference. The card LEDs are on when the system is off, but it still doesn't wake up. Once manually started, the system works fine, and ifconfig shows WOL_MAGIC. Any suggestions on things to try? I'm open to going back to a normal BIOS... if it will let me. It runs fine either way. And of course I tried it one more time out of desperation and it worked. I'll document the settings ...if they work again. ___ 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: 9.2 ixgbe tx queue hang
Hi, Rick, Does these patches will commit to the stable soon, or I had to patch it manually? Regards Simon 于 14-3-28 6:44, Rick Macklem 写道: Christopher Forgeron wrote: On Wed, Mar 26, 2014 at 9:35 PM, Rick Macklem rmack...@uoguelph.ca wrote: I've suggested in the other thread what you suggested in a recent post...ie. to change the default, at least until the propagation of driver set values is resolved. rick I wonder if we need to worry about propagating values up from the sub-if's - Setting the default in if.c means this is set for all if's, and it's a simple 1 line code change. If a specific 'if' needs a different value, it can be set before ether_attach() is called. I'm more concerned with the equation we use to calculate if_hw_tsomax - Are we considering the right variables? Are we thinking on the wrong OSI layer for headers? Well, I'm pragmatic (which means I mostly care about some fix that works), but it seems to me that: - The problem is that some TSO enabled network drivers/hardware can only handle 32 transmit segments (or 32 mbufs in the chain for the TSO packet to be transmitted, if that is clearer). -- Since the problem is in certain drivers, it seems that those drivers should be where the long term fix goes. -- Since some hardware can't handle more than 32, it seems that the driver should be able to specify that limit, which tcp_output() can then apply. I have an untested patch that does this by adding if_hw_tsomaxseg. (The attachment called tsomaxseg.patch.) Changing if_hw_tsomax or its default value is just a hack that gets tcp_output() to apply a limit that the driver can then fix to 32 mbufs in the chain via m_defrag(). Since if_hw_tsomax (and if_hw_tsomaxseg in the untested patch) aren't propagated up through lagg, that needs to be fixed. (Yet another attached untested patch called lagg.patch.) As I said before, I don't see these patches getting tested/reviewed etc in time for 9.3, so I think reducing the default value of if_hw_tsomax is a reasonable short term hack to work around the problem. (And it sounds like Pyun YongHyeon has volunteered to fix many of the drivers, where the 32 limit isn't a hardware one.) rick ___ 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
