RE: 6.2-RELEASE em0 watchdog timeouts -- sometimes (w/ partial workaround)
Hello. This is Yutaka. I am unskilled using english. If you don't understand my english , please teach for me. I came from FreeBSD-users-jp (Japanese mailing-list) which has been guidanced. http://home.jp.freebsd.org/cgi-bin/showmail/FreeBSD-users-jp/90318 This thired. > 6.2-RELEASE em0 watchdog timeouts -- sometimes (w/ partial workaround) Mike > Andrews > * 6.2-RELEASE em0 watchdog timeouts -- sometimes (w/ partial workaround) > Jack Vogel > o 6.2-RELEASE em0 watchdog timeouts -- sometimes (w/ partial > workaround) Mike Andrews > o 6.2-RELEASE em0 watchdog timeouts -- sometimes (w/ partial > workaround) Jeremy Chadwick > + 6.2-RELEASE em0 watchdog timeouts -- sometimes (w/ partial > workaround) Jack Vogel > # 6.2-RELEASE em0 watchdog timeouts -- sometimes (w/ > partial workaround) John Baldwin > o 6.2-RELEASE em0 watchdog timeouts -- sometimes (w/ partial > workaround) Mike Andrews I know this phenomenon. My environment generate it. Changed setting with problem has improved. I was setting disable USB in BIOS. Having been generated problem by 3 times after reboot. however, no-problem last 3 days. enable USB, this problem 4-10 times per hour. disable USB, this problem 3 times after reboot. # pciconf -l -v [EMAIL PROTECTED]:8:0: class=0x02 card=0x002e8086 chip=0x100e8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82540EM Gigabit Ethernet Controller' class= network subclass = ethernet disable USB, dmesg.boot log. Copyright (c) 1992-2007 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 6.2-RELEASE #0: Sat Jan 20 12:12:56 JST 2007 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/NATBOX ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Sempron(tm) (1403.19-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x681 Stepping = 1 Features=0x383fbff AMD Features=0xc0480800 real memory = 805240832 (767 MB) avail memory = 774430720 (738 MB) ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xe000-0xe7ff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci0: at device 5.0 (no driver attached) atapci0: port 0xec00-0xec7f,0xe800-0xe8ff mem 0xdfffb000-0xdfffbfff,0xdffc-0xdffd irq 17 at device 6.0 on pci0 ata2: on atapci0 ata3: on atapci0 ata4: on atapci0 ata5: on atapci0 em0: port 0xe400-0xe43f mem 0xdff8-0xdff9,0xdff6-0xdff7 irq 18 at device 8.0 on pci0 em0: Ethernet address: 00:07:e9:xx:x:xx xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xe000-0xe07f mem 0xdfffaf80-0xdfffafff irq 17 at device 10.0 on pci0 miibus0: on xl0 xlphy0: <3Com internal media interface> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:10:5a:xx:xx:xx atapci1: port 0xdc00-0xdc07,0xd800-0xd803,0xd400-0xd407,0xd000-0xd003,0xcc00-0xcc0f,0xc800-0xc8ff irq 20 at device 15.0 on pci0 ata6: on atapci1 ata7: on atapci1 atapci2: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 15.1 on pci0 ata0: on atapci2 ata1: on atapci2 isab0: at device 17.0 on pci0 isa0: on isab0 pci0: at device 17.5 (no driver attached) acpi_button1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 fdc0: port 0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: port 0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 pmtimer0 on isa0 orm0: at iomem 0xc-0xc7fff,0xc8000-0xccfff,0xcd000-0xce7ff,0xe-0xe0fff on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Thank you. -- NISHIMURA,Yutaka. <[EMAIL PROTECTED]> ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe,
Re: 6.2-RELEASE em0 watchdog timeouts -- sometimes (w/ partial workaround)
On Tuesday 16 January 2007 22:07, Jack Vogel wrote: > On 1/16/07, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > > On Tue, Jan 16, 2007 at 10:53:04AM -0800, Jack Vogel wrote: > > > There are some management related issues with this NIC, first if you > > > have not done so make a DOS bootable device, and run this app I > > > am enclosing, it fixes the prom setting that is wrong on some devices. > > > It will do no harm, and it may solve things. > > > > Jack, > > > > Can you expand on what this application changes in the PROM? I have > > an Intel motherboard which suffers from similar to what the OP has > > reported (em0 watchdog timeouts), and was curious what the utility > > does before firing up the board and trying it. Others may be curious > > to know, too. > > Hmmm, I'm rusty on this, its now been a year or more since I was > first involved in the details, so I may need to amend this later :) > > But from memory, the issue is the value programmed into the MANC > register by the PROM, I don't remember what bit it was, but one bit > is mistakenly set, it causes the hardware to incorrectly intercept some > packets. > > I was snowbound today, but I'll doublecheck on the detail tomorrow > and amend if needed. > > Everyone note that this ONLY effects an 82573 NIC, so make sure of > that before anything else. Is this the IPMI/ASF stuff? If so, you can also work around it by adding 'net.inet.ip.portrange.lowlast=665' to /etc/sysctl.conf. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.2-RELEASE em0 watchdog timeouts -- sometimes (w/ partial workaround)
Jack Vogel wrote: On 1/16/07, Mike Andrews <[EMAIL PROTECTED]> wrote: I have a strange issue with em0 watchdog timeouts that I think is not the same as the ones everyone was having during the 6.2 beta cycle... I have six systems, each with two Intel GigE ports onboard: Systems A and B: Supermicro PDSMi+ Systems C and D: Supermicro PDSMi (without the plus) >>[snip] Several times a day, em0 will go down, give a watchdog timeout error on the console, then come right back up on its own a few seconds later. But here's the weird twist: it ONLY happens on systems A and B, and ONLY when running at gigabit speed. If I knock the two switch ports down to 100 meg, the problem goes away. [snip] There are some management related issues with this NIC, first if you have not done so make a DOS bootable device, and run this app I am enclosing, it fixes the prom setting that is wrong on some devices. It will do no harm, and it may solve things. Let me know if it does fix it please. No problems since running that tool almost 24 hours ago. Looks like a fix. Thanks again! -- Mike Andrews * [EMAIL PROTECTED] * http://www.bit0.com It's not news, it's Fark.com. Carpe cavy! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.2-RELEASE em0 watchdog timeouts -- sometimes (w/ partial workaround)
On 1/16/07, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: On Tue, Jan 16, 2007 at 10:53:04AM -0800, Jack Vogel wrote: > There are some management related issues with this NIC, first if you > have not done so make a DOS bootable device, and run this app I > am enclosing, it fixes the prom setting that is wrong on some devices. > It will do no harm, and it may solve things. Jack, Can you expand on what this application changes in the PROM? I have an Intel motherboard which suffers from similar to what the OP has reported (em0 watchdog timeouts), and was curious what the utility does before firing up the board and trying it. Others may be curious to know, too. Hmmm, I'm rusty on this, its now been a year or more since I was first involved in the details, so I may need to amend this later :) But from memory, the issue is the value programmed into the MANC register by the PROM, I don't remember what bit it was, but one bit is mistakenly set, it causes the hardware to incorrectly intercept some packets. I was snowbound today, but I'll doublecheck on the detail tomorrow and amend if needed. Everyone note that this ONLY effects an 82573 NIC, so make sure of that before anything else. Cheers, Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.2-RELEASE em0 watchdog timeouts -- sometimes (w/ partial workaround)
On Tue, Jan 16, 2007 at 10:53:04AM -0800, Jack Vogel wrote: > There are some management related issues with this NIC, first if you > have not done so make a DOS bootable device, and run this app I > am enclosing, it fixes the prom setting that is wrong on some devices. > It will do no harm, and it may solve things. Jack, Can you expand on what this application changes in the PROM? I have an Intel motherboard which suffers from similar to what the OP has reported (em0 watchdog timeouts), and was curious what the utility does before firing up the board and trying it. Others may be curious to know, too. Thanks, as always. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.2-RELEASE em0 watchdog timeouts -- sometimes (w/ partial workaround)
Jack Vogel wrote: On 1/16/07, Mike Andrews <[EMAIL PROTECTED]> wrote: I have a strange issue with em0 watchdog timeouts that I think is not the same as the ones everyone was having during the 6.2 beta cycle... I have six systems, each with two Intel GigE ports onboard: Systems A and B: Supermicro PDSMi+ Systems C and D: Supermicro PDSMi (without the plus) [snip] Several times a day, em0 will go down, give a watchdog timeout error on the console, then come right back up on its own a few seconds later. But here's the weird twist: it ONLY happens on systems A and B, and ONLY when running at gigabit speed. If I knock the two switch ports down to 100 meg, the problem goes away. [snip] There are some management related issues with this NIC, first if you have not done so make a DOS bootable device, and run this app I am enclosing, it fixes the prom setting that is wrong on some devices. It will do no harm, and it may solve things. Let me know if it does fix it please. So far it seems like it DID fix it, but give me another day or two to watch it to be sure. Thanks! FYI, it only changed the PROM on the first NIC on each PDSMi+ box; it said the second NIC was fine. (But since the first NIC was the one I was having trouble with...) I ran it on the older PDSMi boxes and it said it changed both NICs on those, even though they were (and still are) working fine. -- Mike Andrews * [EMAIL PROTECTED] * http://www.bit0.com It's not news, it's Fark.com. Carpe cavy! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
