Re: bge problems under 7.2-PRERELEASE
Hello, On Fri, May 29, 2009 at 8:16 PM, Marius Stroblmar...@alchemy.franken.de wrote: On Fri, May 29, 2009 at 08:02:42PM +0200, Henri-Pierre Charles wrote: Hello Guys On Thu, Apr 23, 2009 at 10:05 PM, Jeff Blank jb000...@mr-happy.com wrote: On Thu, Apr 23, 2009 at 07:19:49PM +0200, Marius Strobl wrote: So in combination with the low number of problem reports this really doesn't look like a generic problem of this Broadcom hardware or bge(4) and I just can suggest to disable MSI by setting the hw.pci.enable_msi tuneable to 0 for now. Great, this does the trick, and I'm now running today's RELENG_7. Thanks for your help, and let me know if ever you'd like me to help test possible fixes. I have the same computer (Dell optiplex 740) but the sysctl turnaround doesn't work, the bge interface seem up but no interruptions. I have to download / recompile with sys/dev/bge/if_bge.c rev 1.198.2.13 and sys/dev/pci/pci.c rev 1.355.2.6 Is there anything else to try ? You need to set hw.pci.enable_msi in the loader f.e. via loader.conf rather than the corresponding sysctl as the latter has no effect during boot. Ok, thanks it works. -- HPC ___ 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: bge problems under 7.2-PRERELEASE
Hello Guys On Thu, Apr 23, 2009 at 10:05 PM, Jeff Blank jb000...@mr-happy.com wrote: On Thu, Apr 23, 2009 at 07:19:49PM +0200, Marius Strobl wrote: So in combination with the low number of problem reports this really doesn't look like a generic problem of this Broadcom hardware or bge(4) and I just can suggest to disable MSI by setting the hw.pci.enable_msi tuneable to 0 for now. Great, this does the trick, and I'm now running today's RELENG_7. Thanks for your help, and let me know if ever you'd like me to help test possible fixes. I have the same computer (Dell optiplex 740) but the sysctl turnaround doesn't work, the bge interface seem up but no interruptions. I have to download / recompile with sys/dev/bge/if_bge.c rev 1.198.2.13 and sys/dev/pci/pci.c rev 1.355.2.6 Is there anything else to try ? H-P -- HPC ___ 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: bge problems under 7.2-PRERELEASE
On Fri, May 29, 2009 at 08:02:42PM +0200, Henri-Pierre Charles wrote: Hello Guys On Thu, Apr 23, 2009 at 10:05 PM, Jeff Blank jb000...@mr-happy.com wrote: On Thu, Apr 23, 2009 at 07:19:49PM +0200, Marius Strobl wrote: So in combination with the low number of problem reports this really doesn't look like a generic problem of this Broadcom hardware or bge(4) and I just can suggest to disable MSI by setting the hw.pci.enable_msi tuneable to 0 for now. Great, this does the trick, and I'm now running today's RELENG_7. Thanks for your help, and let me know if ever you'd like me to help test possible fixes. I have the same computer (Dell optiplex 740) but the sysctl turnaround doesn't work, the bge interface seem up but no interruptions. I have to download / recompile with sys/dev/bge/if_bge.c rev 1.198.2.13 and sys/dev/pci/pci.c rev 1.355.2.6 Is there anything else to try ? You need to set hw.pci.enable_msi in the loader f.e. via loader.conf rather than the corresponding sysctl as the latter has no effect during boot. Marius ___ 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: bge problems under 7.2-PRERELEASE
On Wed, 22 Apr 2009, Marius Strobl wrote: On Wed, Apr 22, 2009 at 11:06:12AM -0400, Jeff Blank wrote: On Tue, Apr 21, 2009 at 09:55:10PM +0200, Marius Strobl wrote: Use the sources you have but plug in sys/dev/bge/if_bge.c rev 1.198.2.13 and sys/dev/pci/pci.c rev 1.355.2.6, this combination should work. correct. Then update if_bge.c to rev 1.198.2.14 and check whether things still work, this causes the problem to resurface. David, this is the second report that using MSI with a BCM5754/ chip=0x167a14e4 results in no interrupts, is there any errata about this? Thanks, Marius I wanted to upgrade my stable and but now am afraid to reboot with the new kernel as I've got one of these bge0 cards. dmesg reveals: brgphy0: BCM5750 10/100/1000baseTX PHY PHY 1 on miibus0 a different version of BCM, not BCM 5754 and the log of cvsup shows: Edit src/sys/dev/bge/if_bge.c Add delta 1.198.2.12 2009.01.15.20.13.22 marius Add delta 1.198.2.13 2009.01.15.20.19.53 marius Add delta 1.198.2.14 2009.01.15.20.23.38 marius Add delta 1.198.2.15 2009.03.19.16.44.37 marius Add delta 1.198.2.16 2009.03.23.20.53.38 marius Add delta 1.198.2.17 2009.03.27.21.21.22 marius Would you advise using the old kernel? Should I have posted to -questions? Annelise ___ 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: bge problems under 7.2-PRERELEASE
On Thu, Apr 23, 2009 at 12:41:36AM -0700, Annelise Anderson wrote: I wanted to upgrade my stable and but now am afraid to reboot with the new kernel as I've got one of these bge0 cards. You should be able to back out fairly easily in case of most problems. When you reboot to single-user mode with the new kernel, you can test whatever you think you need to (device presence/functionality, networking, etc) before installing world. If you don't like the results, just rename or delete /boot/kernel, rename /boot/kernel.old to /boot/kernel, and reboot, no damage done (usually). dmesg reveals: brgphy0: BCM5750 10/100/1000baseTX PHY PHY 1 on miibus0 a different version of BCM, not BCM 5754 I can't speak authoritatively, but I expect you're fine. My problem appears to have a very narrow scope. Jeff ___ 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: bge problems under 7.2-PRERELEASE
On Wed, Apr 22, 2009 at 11:06:12AM -0400, Jeff Blank wrote: On Tue, Apr 21, 2009 at 09:55:10PM +0200, Marius Strobl wrote: Use the sources you have but plug in sys/dev/bge/if_bge.c rev 1.198.2.13 and sys/dev/pci/pci.c rev 1.355.2.6, this combination should work. correct. Then update if_bge.c to rev 1.198.2.14 and check whether things still work, this causes the problem to resurface. FYI, I've found a notebook equipped with the exact same Broadcom chip and ASIC revision but which works without problems with current sources. So in combination with the low number of problem reports this really doesn't look like a generic problem of this Broadcom hardware or bge(4) and I just can suggest to disable MSI by setting the hw.pci.enable_msi tuneable to 0 for now. As David pointed out this might be a problem with the Nvidia chipset. Linux seems to have a workaround related to this but I still need to check that in detail. Marius ___ 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: bge problems under 7.2-PRERELEASE
On Thu, Apr 23, 2009 at 07:19:49PM +0200, Marius Strobl wrote: So in combination with the low number of problem reports this really doesn't look like a generic problem of this Broadcom hardware or bge(4) and I just can suggest to disable MSI by setting the hw.pci.enable_msi tuneable to 0 for now. Great, this does the trick, and I'm now running today's RELENG_7. Thanks for your help, and let me know if ever you'd like me to help test possible fixes. Jeff ___ 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: bge problems under 7.2-PRERELEASE
On Tue, Apr 21, 2009 at 09:55:10PM +0200, Marius Strobl wrote: Use the sources you have but plug in sys/dev/bge/if_bge.c rev 1.198.2.13 and sys/dev/pci/pci.c rev 1.355.2.6, this combination should work. correct. Then update if_bge.c to rev 1.198.2.14 and check whether things still work, this causes the problem to resurface. Jeff ___ 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: bge problems under 7.2-PRERELEASE
On Wed, Apr 22, 2009 at 11:06:12AM -0400, Jeff Blank wrote: On Tue, Apr 21, 2009 at 09:55:10PM +0200, Marius Strobl wrote: Use the sources you have but plug in sys/dev/bge/if_bge.c rev 1.198.2.13 and sys/dev/pci/pci.c rev 1.355.2.6, this combination should work. correct. Then update if_bge.c to rev 1.198.2.14 and check whether things still work, this causes the problem to resurface. David, this is the second report that using MSI with a BCM5754/ chip=0x167a14e4 results in no interrupts, is there any errata about this? Thanks, Marius ___ 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: bge problems under 7.2-PRERELEASE
On Wed, Apr 22, 2009 at 01:21:58PM -0700, David Christensen wrote: Then update if_bge.c to rev 1.198.2.14 and check whether things still work, this causes the problem to resurface. David, this is the second report that using MSI with a BCM5754/ chip=0x167a14e4 results in no interrupts, is there any errata about this? Nope, no errata for MSI on the 5754, nor can I recall any MSI problems on any of the PCIe based devices. Do the systems share a common root complex that might be the source of the issue? This one useses a: no...@pci0:0:0:0: class=0x05 card=0x02f010de chip=0x02f010de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Host Bridge' class = memory subclass = RAM At least Linux doesn't seem to avoid using MSI with these. I didn't get any further regarding the other report so far. Marius ___ 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: bge problems under 7.2-PRERELEASE
Then update if_bge.c to rev 1.198.2.14 and check whether things still work, this causes the problem to resurface. David, this is the second report that using MSI with a BCM5754/ chip=0x167a14e4 results in no interrupts, is there any errata about this? Nope, no errata for MSI on the 5754, nor can I recall any MSI problems on any of the PCIe based devices. Do the systems share a common root complex that might be the source of the issue? Dave ___ 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: bge problems under 7.2-PRERELEASE
this is the second report that using MSI with a BCM5754/ chip=0x167a14e4 results in no interrupts, is there any errata about this? Nope, no errata for MSI on the 5754, nor can I recall any MSI problems on any of the PCIe based devices. Do the systems share a common root complex that might be the source of the issue? This one useses a: no...@pci0:0:0:0: class=0x05 card=0x02f010de chip=0x02f010de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Host Bridge' class = memory subclass = RAM At least Linux doesn't seem to avoid using MSI with these. I didn't get any further regarding the other report so far. Are there any other errors reported by the 5754 such as a PCIe completion timeout in the Advanced Error Uncorrectable Status Register? I recall an issue with another Nvidia chipset and the 5754 where the system BIOS incorrectly configured the Hypertransport unitID field to a value of 0x20 which would prevent our diagnostics from running. PCI configuration and memory-mapped I/O worked correctly but DMA operations such as sending RX'd frames would fail. MSI might fall into this latter category and could be causing this error. The important thing would be to check for a Completion Timeout in the 5754. Dave ___ 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: bge problems under 7.2-PRERELEASE
On Mon, Apr 20, 2009 at 04:46:38PM -0400, Jeff Blank wrote: Hi, csup today around 13:00 UTC. 'make buildworld', 'make buildkernel', 'make installkernel', reboot to single-user. # ifconfig bge0 141.219.5.33/22 up # ping 141.219.4.1 PING 141.219.4.1 (141.219.4.1): 56 data bytes ^C --- 141.219.4.1 ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss # ifconfig bge0 bge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM ether 00:1e:c9:44:30:14 inet6 fe80::21e:c9ff:fe44:3014%bge0 prefixlen 64 scopeid 0x1 inet 141.219.5.33 netmask 0xfc00 broadcast 141.219.7.255 media: Ethernet autoselect (100baseTX full-duplex) status: active I have no trouble with networking using a kernel from 20090115. This Does that working kernel include r187309 (if_bge.c rev 1.198.2.14)? If it predates it could you please check whether this is the change which breaks things for you? is a Dell Optiplex 740, about 9 months old. make.conf and src.conf are below. dmesg and pciconf output are attached. I ran 'tcpdump -i bge0 -nn' while pinging, and this captured no packets, not even this host's ARP broadcasts. I also encountered this problem in late March as well, just after RELENG_7 became 7.2-PRERELEASE, but couldn't find time to put this information together. If there's anything else I can run to troubleshoot this, please let me know. thank you, Jeff Blank /etc/make.conf: CPUTYPE ?= k8 WITHOUT_NLS=true [port-specific options elided for brevity] /etc/src.conf: WITHOUT_ATM=true WITHOUT_GPIB=true WITHOUT_I4B=true WITHOUT_IPFILTER=true WITHOUT_IPFW=true WITHOUT_IPX=true WITHOUT_LIB32=true WITHOUT_NCP=true WITHOUT_NDIS=true WITHOUT_PPP=true WITHOUT_QUOTAS=true WITHOUT_RCMDS=true WITHOUT_SENDMAIL=true WITHOUT_SLIP=true WITHOUT_WIRELESS=true # dmesg Copyright (c) 1992-2009 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 7.2-PRERELEASE #0: Mon Apr 20 12:27:26 EDT 2009 r...@bender.tc.mtu.edu:/usr/obj/usr/src/sys/GENERIC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5600+ (2906.08-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x60fb2 Stepping = 2 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x2001SSE3,CX16 AMD Features=0xea500800SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow! AMD Features2=0x11fLAHF,CMP,SVM,ExtAPIC,CR8,Prefetch TSC: P-state invariant Cores per package: 2 usable memory = 4278718464 (4080 MB) avail memory = 4098314240 (3908 MB) ACPI APIC Table: DELL bMk FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ ioapic0: Changing APIC ID to 4 ioapic0 Version 1.1 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: DELL bMk on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, bfdd (3) failed Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 acpi_hpet0: High Precision Event Timer iomem 0xfeff-0xfeff03ff on acpi0 Timecounter HPET frequency 2500 Hz quality 900 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: memory, RAM at device 0.0 (no driver attached) pci0: memory, RAM at device 0.1 (no driver attached) pci0: memory, RAM at device 0.2 (no driver attached) pci0: memory, RAM at device 0.3 (no driver attached) pci0: memory, RAM at device 0.4 (no driver attached) pci0: memory, RAM at device 0.5 (no driver attached) pci0: memory, RAM at device 0.6 (no driver attached) pci0: memory, RAM at device 0.7 (no driver attached) pcib1: ACPI PCI-PCI bridge at device 2.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 3.0 on pci0 pci2: ACPI PCI bus on pcib2 bge0: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0xb002 mem 0xfd8f-0xfd8f irq 16 at device 0.0 on pci2 miibus0: MII bus on bge0 brgphy0: BCM5787 10/100/1000baseTX PHY PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:1e:c9:44:30:14 bge0: [ITHREAD] pcib3: ACPI PCI-PCI bridge at device 4.0 on pci0 pci3: ACPI PCI bus on pcib3 vgapci0: VGA-compatible display port 0xbc00-0xbcff mem
Re: bge problems under 7.2-PRERELEASE
On Tue, Apr 21, 2009 at 08:49:24PM +0200, Marius Strobl wrote: On Mon, Apr 20, 2009 at 04:46:38PM -0400, Jeff Blank wrote: I have no trouble with networking using a kernel from 20090115. This Does that working kernel include r187309 (if_bge.c rev 1.198.2.14)? nope, 1.198.2.11. If it predates it could you please check whether this is the change which breaks things for you? what's the best way to go about this? I no longer have the source tree from the working kernel. should I plug 1.198.2.11 into the sources I have and then try .14? any other files I'd need previous revisions of? or is there a different, better way to go about it? (I don't know much about time-travelling through source.) thanks, Jeff ___ 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: bge problems under 7.2-PRERELEASE
On Tue, Apr 21, 2009 at 03:31:29PM -0400, Jeff Blank wrote: On Tue, Apr 21, 2009 at 08:49:24PM +0200, Marius Strobl wrote: On Mon, Apr 20, 2009 at 04:46:38PM -0400, Jeff Blank wrote: I have no trouble with networking using a kernel from 20090115. This Does that working kernel include r187309 (if_bge.c rev 1.198.2.14)? nope, 1.198.2.11. If it predates it could you please check whether this is the change which breaks things for you? what's the best way to go about this? I no longer have the source tree from the working kernel. should I plug 1.198.2.11 into the sources I have and then try .14? any other files I'd need previous revisions of? or is there a different, better way to go about it? (I don't know much about time-travelling through source.) Use the sources you have but plug in sys/dev/bge/if_bge.c rev 1.198.2.13 and sys/dev/pci/pci.c rev 1.355.2.6, this combination should work. Then update if_bge.c to rev 1.198.2.14 and check whether things still work, if they do revert to pci.c rev 1.355.2.9 and check again. Marius ___ 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
