Re: [pfSense Support] em0: Watchdog timeout -- resetting

2009-01-06 Thread Paul Mansfield
Nathan Eisenberg wrote:
> I ran the script in a linux environment, and received "No appropriate 
> hardware found for this fixup".

hmm. I presume you've tried turning off APM and ACPI, disabling serial
ports, parallel port, and indeed disabling any hardware not absolutely
essential in order to avoid sharing interrupts on the cards?

disabled TOE/hardware checksum offloading (advanced menu)?

> 
> I don't know if I mentioned it previously, but the model number of this card 
> is EXPI9404PTL.


googling for that model and variants of "fault, fail, problem" doesn't
turn up much.

-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com

Commercial support available - https://portal.pfsense.org



RE: AW: [pfSense Support] em0: Watchdog timeout -- resetting

2009-01-06 Thread Nathan Eisenberg
Just thought I'd update with what I'm doing on this issue; since this list is 
indexed, maybe this breadcrumb trail will help out another poor sap along the 
way.

Tomorrow, I plan to explore the following.  I'm not sure why these would cause 
issues, but grasping at straws is good for the soul.
-Checksum offloading (disable per 
http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&ProductID=2788&DwnldID=11848&strOSs=38&OSFullName=OS%20Independent&lang=eng)
- TSO (disable per above link)
- Polling (tweak and toggle per above link)
- Try SMP Kernel (Why not?)
- Update to latest BIOS (That document also mentions an 'update to the latest 
BIOS', and references the Linux Firmware Kit project.  
http://linuxfirmwarekit.org/ - the difference is only a revision code, but 
perhaps the fix is in there.  SuperMicro's BIOS update release notes apparently 
require an NDA (Why!?))

Running OpenBSD latest (4.4), I discovered that I don't receive watchdog 
timeouts - instead, I am just seeing extremely poor performance (70kbps), where 
the onboard NICs deliver the expected near-wirespeed.

Will update.

Thank You,
Nathan Eisenberg
Sr. Systems Administrator
Atlas Networks, LLC
Atlas Networks is an Atlas Accelerator Company


-Original Message-
From: Nathan Eisenberg [mailto:nat...@atlasnetworks.us] 
Sent: Monday, January 05, 2009 5:32 PM
To: 'support@pfsense.com'
Subject: RE: AW: [pfSense Support] em0: Watchdog timeout -- resetting

Any thoughts on a next step in troubleshooting?  I'm running out of ideas.  
Setting the port speed and duplex has no effect.

Thank You,
Nathan Eisenberg
Sr. Systems Administrator
Atlas Networks, LLC
Atlas Networks is an Atlas Accelerator Company


-Original Message-
From: cbuech...@gmail.com [mailto:cbuech...@gmail.com] On Behalf Of Chris 
Buechler
Sent: Monday, January 05, 2009 5:14 PM
To: support@pfsense.com
Subject: Re: AW: [pfSense Support] em0: Watchdog timeout -- resetting

On Mon, Jan 5, 2009 at 2:02 PM, Nathan Eisenberg
 wrote:
>
> Admittedly, I did not expect to run into hardware/driver issues when I was 
> buying these NICs.  :(  In fact, that's exactly the reason I
> went with Intel HW in the first place.
>

Usually that's an accurate assessment. This card is newer than the
driver in FreeBSD 7.0 though. And it might not be network driver
related at all, might be specific to some other hardware component in
relation or combination with that card.

-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com

Commercial support available - https://portal.pfsense.org





-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com

Commercial support available - https://portal.pfsense.org





-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com

Commercial support available - https://portal.pfsense.org



Re: AW: [pfSense Support] em0: Watchdog timeout -- resetting

2009-01-05 Thread Chris Buechler
On Mon, Jan 5, 2009 at 8:32 PM, Nathan Eisenberg
 wrote:
> Any thoughts on a next step in troubleshooting?
>

As I suggested earlier in this thread:

http://doc.pfsense.org/index.php/Policy_on_FreeBSD_issues

"Most frequently these issues are driver bugs. We do not have any
developers who work on drivers in FreeBSD, and cannot assist with such
issues. In these cases, we suggest installing a stock FreeBSD 7.0
release on your hardware, replicating the problem, and reporting it to
the appropriate FreeBSD list. This is the only way your problem will
be resolved, and even at that will only be resolved in future
releases. Alternatively, use different hardware."

You may be able to get away with posting questions to freebsd-net
using pfSense since it's close to the same as 7.0 release, with no
kernel changes related to network drivers.

My guess is you would be asked to try 7.1, or RELENG_7, or HEAD to see
if the problems persist there. You won't be able to easily do that
without running a stock FreeBSD. My guess is this is something
specific to this new card that's been addressed with a newer driver,
which probably isn't able to be reasonably added to a pfSense install.
 Hence you may be stuck for the time being.

You can try 2.0, which is based on FreeBSD 7.1 and see if that makes
any difference.

Aside from that, I'm out of suggestions aside from going to the
freebsd-net list and hoping the Intel employee who works on the em
driver and posts there will offer some suggestions.

-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com

Commercial support available - https://portal.pfsense.org



RE: AW: [pfSense Support] em0: Watchdog timeout -- resetting

2009-01-05 Thread Nathan Eisenberg
Any thoughts on a next step in troubleshooting?  I'm running out of ideas.  
Setting the port speed and duplex has no effect.

Thank You,
Nathan Eisenberg
Sr. Systems Administrator
Atlas Networks, LLC
Atlas Networks is an Atlas Accelerator Company


-Original Message-
From: cbuech...@gmail.com [mailto:cbuech...@gmail.com] On Behalf Of Chris 
Buechler
Sent: Monday, January 05, 2009 5:14 PM
To: support@pfsense.com
Subject: Re: AW: [pfSense Support] em0: Watchdog timeout -- resetting

On Mon, Jan 5, 2009 at 2:02 PM, Nathan Eisenberg
 wrote:
>
> Admittedly, I did not expect to run into hardware/driver issues when I was 
> buying these NICs.  :(  In fact, that's exactly the reason I
> went with Intel HW in the first place.
>

Usually that's an accurate assessment. This card is newer than the
driver in FreeBSD 7.0 though. And it might not be network driver
related at all, might be specific to some other hardware component in
relation or combination with that card.

-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com

Commercial support available - https://portal.pfsense.org





-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com

Commercial support available - https://portal.pfsense.org



Re: AW: [pfSense Support] em0: Watchdog timeout -- resetting

2009-01-05 Thread Chris Buechler
On Mon, Jan 5, 2009 at 2:02 PM, Nathan Eisenberg
 wrote:
>
> Admittedly, I did not expect to run into hardware/driver issues when I was 
> buying these NICs.  :(  In fact, that's exactly the reason I
> went with Intel HW in the first place.
>

Usually that's an accurate assessment. This card is newer than the
driver in FreeBSD 7.0 though. And it might not be network driver
related at all, might be specific to some other hardware component in
relation or combination with that card.

-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com

Commercial support available - https://portal.pfsense.org



RE: [pfSense Support] em0: Watchdog timeout -- resetting

2009-01-05 Thread Nathan Eisenberg
I ran the script in a linux environment, and received "No appropriate hardware 
found for this fixup".

I don't know if I mentioned it previously, but the model number of this card is 
EXPI9404PTL.

Thank You,
Nathan Eisenberg
Sr. Systems Administrator
Atlas Networks, LLC
Atlas Networks is an Atlas Accelerator Company


-Original Message-
From: Paul Mansfield [mailto:it-admin-pfse...@taptu.com] 
Sent: Monday, January 05, 2009 3:26 AM
To: support@pfsense.com
Subject: Re: [pfSense Support] em0: Watchdog timeout -- resetting

Paul M wrote:
> linux - there used to be a problem with the e1000 driver when power
> saving is enabled in the e1000's eeprom. the fix worked, and I applied
> it by booting a linux rescue disk and ran the eeprom fix program that I
> got from the e1000 sourceforce website; their wiki seems to have
> disappeared so I can't find the script, so I've placed a copy here:
> http://www.zaurus.org.uk/download/scripts/fixeep-82573-dspd.sh
> 
> if you have the problem on linux you get "detected tx unit hang" thus:
> http://sourceforge.net/tracker/index.php?func=detail&aid=1463045&group_id=42302&atid=447449


p.s. I believe that in theory Intel and manufacturers using their e1000
chips were supposed to be turning this off.

p.p.s. I don't think there's any equivalent of "ethtool -e eth0" for
freebsd, so you can't run that script directly on pfsense/freebsd. If
there were, you'd get this:

# ethtool -e eth5
Offset  Values
--  --
0x  00 e0 81 4b 53 b7 30 0b 47 f6 02 10 ff ff ff ff
0x0010  ff ff ff ff 6b 22 91 51 f1 10 8b 10 86 80 df ac
0x0020  21 00 02 20 04 7e 00 00 00 10 d8 00 00 00 00 27
0x0030  c9 6c 50 31 22 07 0b 04 84 09 00 00 00 c0 07 06

-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com

Commercial support available - https://portal.pfsense.org





-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com

Commercial support available - https://portal.pfsense.org



AW: AW: [pfSense Support] em0: Watchdog timeout -- resetting

2009-01-05 Thread Fuchs, Martin
That's true, but I know some cases where I used Intel cards 1000 MBit and had 
this problem...
Therefore I said "sometimes this helps..." (even a pfsense-system but with a hp 
switch)
Of course it's better to use autodetect, but it's worth a try...

Regards,

Martin

-Ursprüngliche Nachricht-
Von: Paul Mansfield [mailto:it-admin-pfse...@taptu.com] 
Gesendet: Montag, 5. Januar 2009 12:01
An: support@pfsense.com
Betreff: Re: AW: [pfSense Support] em0: Watchdog timeout -- resetting


Fuchs, Martin wrote:
> And perhaps try to set the port speed in pfsense AND the switch, e.g. 
> 1000MBit FD...
> Sometimes this helps, too

Once you start setting port speeds to fix rates and duplex you're going
down a long and slippery slope, it's best to avoid it unless there's a
proven good reason!

> -Ursprüngliche Nachricht-
> Von: apiase...@midatlanticbb.com [mailto:apiase...@midatlanticbb.com] 
> Can't help with your pfsense problem, but it might help to configure 
> this on your switch.
> 
> "spanning-tree portfast" Configured on your cisco switch will change the 
> port to a forwarding state immediately.

this might help hide the symptom of the interface bouncing but isn't
really a cure

-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com

Commercial support available - https://portal.pfsense.org



-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com

Commercial support available - https://portal.pfsense.org



RE: AW: [pfSense Support] em0: Watchdog timeout -- resetting

2009-01-05 Thread Nathan Eisenberg
I agree with both of your statements.  The portfast option isn't a solution, 
but it does make debugging this issue a lot less painful.  

Admittedly, I did not expect to run into hardware/driver issues when I was 
buying these NICs.  :(  In fact, that's exactly the reason I went with Intel HW 
in the first place.

Thank You,
Nathan Eisenberg
Sr. Systems Administrator
Atlas Networks, LLC
Atlas Networks is an Atlas Accelerator Company

-Original Message-
From: Paul Mansfield [mailto:it-admin-pfse...@taptu.com] 
Sent: Monday, January 05, 2009 3:01 AM
To: support@pfsense.com
Subject: Re: AW: [pfSense Support] em0: Watchdog timeout -- resetting


Fuchs, Martin wrote:
> And perhaps try to set the port speed in pfsense AND the switch, e.g. 
> 1000MBit FD...
> Sometimes this helps, too

Once you start setting port speeds to fix rates and duplex you're going
down a long and slippery slope, it's best to avoid it unless there's a
proven good reason!

> -Ursprüngliche Nachricht-
> Von: apiase...@midatlanticbb.com [mailto:apiase...@midatlanticbb.com] 
> Can't help with your pfsense problem, but it might help to configure 
> this on your switch.
> 
> "spanning-tree portfast" Configured on your cisco switch will change the 
> port to a forwarding state immediately.

this might help hide the symptom of the interface bouncing but isn't
really a cure

-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com

Commercial support available - https://portal.pfsense.org






-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com

Commercial support available - https://portal.pfsense.org



Re: [pfSense Support] em0: Watchdog timeout -- resetting

2009-01-05 Thread Paul Mansfield
Paul M wrote:
> linux - there used to be a problem with the e1000 driver when power
> saving is enabled in the e1000's eeprom. the fix worked, and I applied
> it by booting a linux rescue disk and ran the eeprom fix program that I
> got from the e1000 sourceforce website; their wiki seems to have
> disappeared so I can't find the script, so I've placed a copy here:
> http://www.zaurus.org.uk/download/scripts/fixeep-82573-dspd.sh
> 
> if you have the problem on linux you get "detected tx unit hang" thus:
> http://sourceforge.net/tracker/index.php?func=detail&aid=1463045&group_id=42302&atid=447449


p.s. I believe that in theory Intel and manufacturers using their e1000
chips were supposed to be turning this off.

p.p.s. I don't think there's any equivalent of "ethtool -e eth0" for
freebsd, so you can't run that script directly on pfsense/freebsd. If
there were, you'd get this:

# ethtool -e eth5
Offset  Values
--  --
0x  00 e0 81 4b 53 b7 30 0b 47 f6 02 10 ff ff ff ff
0x0010  ff ff ff ff 6b 22 91 51 f1 10 8b 10 86 80 df ac
0x0020  21 00 02 20 04 7e 00 00 00 10 d8 00 00 00 00 27
0x0030  c9 6c 50 31 22 07 0b 04 84 09 00 00 00 c0 07 06

-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com

Commercial support available - https://portal.pfsense.org



Re: AW: [pfSense Support] em0: Watchdog timeout -- resetting

2009-01-05 Thread Paul Mansfield

Fuchs, Martin wrote:
> And perhaps try to set the port speed in pfsense AND the switch, e.g. 
> 1000MBit FD...
> Sometimes this helps, too

Once you start setting port speeds to fix rates and duplex you're going
down a long and slippery slope, it's best to avoid it unless there's a
proven good reason!

> -Ursprüngliche Nachricht-
> Von: apiase...@midatlanticbb.com [mailto:apiase...@midatlanticbb.com] 
> Can't help with your pfsense problem, but it might help to configure 
> this on your switch.
> 
> "spanning-tree portfast" Configured on your cisco switch will change the 
> port to a forwarding state immediately.

this might help hide the symptom of the interface bouncing but isn't
really a cure

-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com

Commercial support available - https://portal.pfsense.org



Re: [pfSense Support] em0: Watchdog timeout -- resetting

2009-01-04 Thread Paul M
Nathan Eisenberg wrote:
> The error I am seeing is "em0: Watchdog Timeout -- Resetting", which
> seems to have several root causes.  I have tried disabling ACPI, both in


we had this, it was very odd, it only started happening when we upgraded
the bios on a tyan motherboard to fix other problems, the firewalls had
never shown the problem before.

in desperation we tried a fix which we'd only ever previously used for
linux - there used to be a problem with the e1000 driver when power
saving is enabled in the e1000's eeprom. the fix worked, and I applied
it by booting a linux rescue disk and ran the eeprom fix program that I
got from the e1000 sourceforce website; their wiki seems to have
disappeared so I can't find the script, so I've placed a copy here:
http://www.zaurus.org.uk/download/scripts/fixeep-82573-dspd.sh

if you have the problem on linux you get "detected tx unit hang" thus:
http://sourceforge.net/tracker/index.php?func=detail&aid=1463045&group_id=42302&atid=447449



-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com

Commercial support available - https://portal.pfsense.org



Re: [pfSense Support] em0: Watchdog timeout -- resetting

2009-01-04 Thread Chris Buechler
On Sun, Jan 4, 2009 at 10:39 AM, k_o_l  wrote:
> Try configuring the "portfast"  feature on the cisco switch for all ports
> connecting to the FW. This should move the ports from disabled to forwarding
> without going through all the spanning tree stages which could take up to 50
> sec.
>

It will, but it *won't* change the fact that the link up/down is
caused by a driver bug, not the switch.

-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com

Commercial support available - https://portal.pfsense.org



AW: [pfSense Support] em0: Watchdog timeout -- resetting

2009-01-04 Thread Fuchs, Martin
And perhaps try to set the port speed in pfsense AND the switch, e.g. 1000MBit 
FD...
Sometimes this helps, too

Regards,

Martin

-Ursprüngliche Nachricht-
Von: apiase...@midatlanticbb.com [mailto:apiase...@midatlanticbb.com] 
Gesendet: Sonntag, 4. Januar 2009 04:17
An: support@pfsense.com
Betreff: Re: [pfSense Support] em0: Watchdog timeout -- resetting

Can't help with your pfsense problem, but it might help to configure 
this on your switch.

"spanning-tree portfast" Configured on your cisco switch will change the 
port to a forwarding state immediately.

Nathan Eisenberg wrote:
>
> Hello,
>
>  
>
> I am deploying a new set of firewall boxes using PFSense 1.2.1.  These 
> boxes have 4GB of RAM, Intel Quad Core CPUs, and a PCI-E Intel 4 Port 
> 10/100/1000 NIC (em0-3) in addition to the 2 onboard 10/100/1000 NICs 
> (em4-5).
>
>  
>
> The Intel NIC seems to go to pieces whenever load is passed through 
> it; the two onboard NICs do fine.   Since I'm using a Cisco switch, 
> the port takes about 30 seconds to start forwarding packets after the 
> issue passes.  I've seen this on my home PFSense box, as well 
> (completely different hardware config), but since I'm not using a 
> Cisco switch at home, I don't notice its effects as severely.
>
>  
>
> The error I am seeing is "em0: Watchdog Timeout -- Resetting", which 
> seems to have several root causes.  I have tried disabling ACPI, both 
> in the BIOS, and in the bootloader.  I have disabled all nonessential 
> devices in the BIOS (except USB), and swapped all cables out (they're 
> all brand new CAT6).  The problem occurs if em0 is connected to a 
> switch, or to my laptop via crossover.  After three hours of Googling, 
> I am stumped.
>
>  
>
> Help?
>
>  
>
> dmesg follows (although em0 and em1 have been replaced with em4 and 
> em5 temporarily).
>
>  
>
> $ dmesg
>
> Copyright (c) 1992-2008 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.0-RELEASE-p7 #0: Thu Dec 25 14:39:15 EST 2008
>
> 
> sullr...@freebsd7-releng_1_2_1.pfsense.org:/usr/obj.pfSense/usr/src/sys/pfSense_SMP.7
>  
> <mailto:sullr...@freebsd7-releng_1_2_1.pfsense.org:/usr/obj.pfSense/usr/src/sys/pfSense_SMP.7>
>
> Timecounter "i8254" frequency 1193182 Hz quality 0
>
> CPU: Intel(R) Xeon(R) CPU   E5410  @ 2.33GHz (2333.43-MHz 
> 686-class CPU)
>
>   Origin = "GenuineIntel"  Id = 0x1067a  Stepping = 10
>
>   
> Features=0xbfebfbff
>
>   
> Features2=0x40ce3bd,>
>
>   AMD Features=0x2010
>
>   AMD Features2=0x1
>
>   Cores per package: 4
>
> real memory  = 2146467840 (2047 MB)
>
> avail memory = 2090897408 (1994 MB)
>
> MPTable: 
>
> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
>
>  cpu0 (BSP): APIC ID:  0
>
>  cpu1 (AP): APIC ID:  1
>
>  cpu2 (AP): APIC ID:  2
>
>  cpu3 (AP): APIC ID:  3
>
> ioapic0: Assuming intbase of 0
>
> ioapic1: Assuming intbase of 24
>
> ioapic0  irqs 0-23 on motherboard
>
> ioapic1  irqs 24-47 on motherboard
>
> wlan: mac acl policy registered
>
> kbd1 at kbdmux0
>
> ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
>
> hptrr: HPT RocketRAID controller driver v1.1 (Dec 25 2008 14:38:55)
>
> cryptosoft0:  on motherboard
>
> cpu0 on motherboard
>
> est0:  on cpu0
>
> est: CPU supports Enhanced Speedstep, but is not recognized.
>
> est: cpu_vendor GenuineIntel, msr 721072106000721
>
> device_attach: est0 attach returned 6
>
> p4tcc0:  on cpu0
>
> cpu1 on motherboard
>
> est1:  on cpu1
>
> est: CPU supports Enhanced Speedstep, but is not recognized.
>
> est: cpu_vendor GenuineIntel, msr 721072106000721
>
> device_attach: est1 attach returned 6
>
> p4tcc1:  on cpu1
>
> cpu2 on motherboard
>
> est2:  on cpu2
>
> est: CPU supports Enhanced Speedstep, but is not recognized.
>
> est: cpu_vendor GenuineIntel, msr 721072106000721
>
> device_attach: est2 attach returned 6
>
> p4tcc2:  on cpu2
>
> cpu3 on motherboard
>
> est3:  on cpu3
>
> est: CPU supports Enhanced Speedstep, but is not recognized.
>
> est: cpu_vendor GenuineIntel, msr 721072106000721
>
> device_attach: est3 attach returned 6
>
> p4tcc3:  on cpu3
>
> pcib0:  pcibus 0 on motherboard
>
> pci0:  on pcib0
>
> pcib1:  irq 24 at device 1.0 on pci0
>
> pci1:  on pcib1
>
> p

Re: [pfSense Support] em0: Watchdog timeout -- resetting

2009-01-04 Thread Chris Buechler
On Sat, Jan 3, 2009 at 8:50 PM, Nathan Eisenberg
 wrote:
>
> The error I am seeing is "em0: Watchdog Timeout -- Resetting", which seems
> to have several root causes.  I have tried disabling ACPI, both in the BIOS,
> and in the bootloader.  I have disabled all nonessential devices in the BIOS
> (except USB), and swapped all cables out (they're all brand new CAT6).  The
> problem occurs if em0 is connected to a switch, or to my laptop via
> crossover.  After three hours of Googling, I am stumped.
>

This is a driver or FreeBSD issue of some sort.  See:
http://doc.pfsense.org/index.php/Policy_on_FreeBSD_issues

-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com

Commercial support available - https://portal.pfsense.org



Re: [pfSense Support] em0: Watchdog timeout -- resetting

2009-01-03 Thread apiase...@midatlanticbb.com
Can't help with your pfsense problem, but it might help to configure 
this on your switch.


"spanning-tree portfast" Configured on your cisco switch will change the 
port to a forwarding state immediately.


Nathan Eisenberg wrote:


Hello,

 

I am deploying a new set of firewall boxes using PFSense 1.2.1.  These 
boxes have 4GB of RAM, Intel Quad Core CPUs, and a PCI-E Intel 4 Port 
10/100/1000 NIC (em0-3) in addition to the 2 onboard 10/100/1000 NICs 
(em4-5).


 

The Intel NIC seems to go to pieces whenever load is passed through 
it; the two onboard NICs do fine.   Since I'm using a Cisco switch, 
the port takes about 30 seconds to start forwarding packets after the 
issue passes.  I've seen this on my home PFSense box, as well 
(completely different hardware config), but since I'm not using a 
Cisco switch at home, I don't notice its effects as severely.


 

The error I am seeing is "em0: Watchdog Timeout -- Resetting", which 
seems to have several root causes.  I have tried disabling ACPI, both 
in the BIOS, and in the bootloader.  I have disabled all nonessential 
devices in the BIOS (except USB), and swapped all cables out (they're 
all brand new CAT6).  The problem occurs if em0 is connected to a 
switch, or to my laptop via crossover.  After three hours of Googling, 
I am stumped.


 


Help?

 

dmesg follows (although em0 and em1 have been replaced with em4 and 
em5 temporarily).


 


$ dmesg

Copyright (c) 1992-2008 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.0-RELEASE-p7 #0: Thu Dec 25 14:39:15 EST 2008


sullr...@freebsd7-releng_1_2_1.pfsense.org:/usr/obj.pfSense/usr/src/sys/pfSense_SMP.7 



Timecounter "i8254" frequency 1193182 Hz quality 0

CPU: Intel(R) Xeon(R) CPU   E5410  @ 2.33GHz (2333.43-MHz 
686-class CPU)


  Origin = "GenuineIntel"  Id = 0x1067a  Stepping = 10

  
Features=0xbfebfbff


  
Features2=0x40ce3bd,>


  AMD Features=0x2010

  AMD Features2=0x1

  Cores per package: 4

real memory  = 2146467840 (2047 MB)

avail memory = 2090897408 (1994 MB)

MPTable: 

FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs

 cpu0 (BSP): APIC ID:  0

 cpu1 (AP): APIC ID:  1

 cpu2 (AP): APIC ID:  2

 cpu3 (AP): APIC ID:  3

ioapic0: Assuming intbase of 0

ioapic1: Assuming intbase of 24

ioapic0  irqs 0-23 on motherboard

ioapic1  irqs 24-47 on motherboard

wlan: mac acl policy registered

kbd1 at kbdmux0

ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)

hptrr: HPT RocketRAID controller driver v1.1 (Dec 25 2008 14:38:55)

cryptosoft0:  on motherboard

cpu0 on motherboard

est0:  on cpu0

est: CPU supports Enhanced Speedstep, but is not recognized.

est: cpu_vendor GenuineIntel, msr 721072106000721

device_attach: est0 attach returned 6

p4tcc0:  on cpu0

cpu1 on motherboard

est1:  on cpu1

est: CPU supports Enhanced Speedstep, but is not recognized.

est: cpu_vendor GenuineIntel, msr 721072106000721

device_attach: est1 attach returned 6

p4tcc1:  on cpu1

cpu2 on motherboard

est2:  on cpu2

est: CPU supports Enhanced Speedstep, but is not recognized.

est: cpu_vendor GenuineIntel, msr 721072106000721

device_attach: est2 attach returned 6

p4tcc2:  on cpu2

cpu3 on motherboard

est3:  on cpu3

est: CPU supports Enhanced Speedstep, but is not recognized.

est: cpu_vendor GenuineIntel, msr 721072106000721

device_attach: est3 attach returned 6

p4tcc3:  on cpu3

pcib0:  pcibus 0 on motherboard

pci0:  on pcib0

pcib1:  irq 24 at device 1.0 on pci0

pci1:  on pcib1

pcib2:  at device 0.0 on pci1

pci2:  on pcib2

pcib3:  at device 2.0 on pci2

pci3:  on pcib3

pcib3: unable to route slot 0 INTB

em0:  port 
0x2000-0x201f mem 0xd802-0xd803,0xd800-0xd801 irq 11 
at device 0.0 on pci3


em0: Using MSI interrupt

em0: Ethernet address: 00:15:17:90:09:c1

em0: [FILTER]

em1:  port 
0x2020-0x203f mem 0xd806-0xd807,0xd804-0xd805 irq 28 
at device 0.1 on pci3


em1: Using MSI interrupt

em1: Ethernet address: 00:15:17:90:09:c0

em1: [FILTER]

pcib4:  at device 4.0 on pci2

pci4:  on pcib4

pcib4: unable to route slot 0 INTB

em2:  port 
0x3000-0x301f mem 0xd812-0xd813,0xd810-0xd811 irq 11 
at device 0.0 on pci4


em2: Using MSI interrupt

em2: Ethernet address: 00:15:17:90:09:c3

em2: [FILTER]

em3:  port 
0x3020-0x303f mem 0xd816-0xd817,0xd814-0xd815 irq 28 
at device 0.1 on pci4


em3: Using MSI interrupt

em3: Ethernet address: 00:15:17:90:09:c2

em3: [FILTER]

pcib5:  irq 28 at device 5.0 on pci0

pci5:  on pcib5

pcib6:  irq 28 at device 0.0 on pci5

pci6:  on pcib6

pcib6: unable to route slot 0 INTA

pcib7:  irq 11 at device 0.0 on pci6

pci7:  on pcib7

pcib8:  irq 44 at device 2.0 o

[pfSense Support] em0: Watchdog timeout -- resetting

2009-01-03 Thread Nathan Eisenberg








Hello,

 

I am deploying a new set of firewall boxes using PFSense
1.2.1.  These boxes have 4GB of RAM, Intel Quad Core CPUs, and a PCI-E
Intel 4 Port 10/100/1000 NIC (em0-3) in addition to the 2 onboard 10/100/1000
NICs (em4-5).

 

The Intel NIC seems to go to pieces whenever load is passed
through it; the two onboard NICs do fine.   Since I'm using a Cisco
switch, the port takes about 30 seconds to start forwarding packets after the
issue passes.  I've seen this on my home PFSense box, as well (completely
different hardware config), but since I'm not using a Cisco switch at home, I
don't notice its effects as severely.

 

The error I am seeing is "em0: Watchdog Timeout --
Resetting", which seems to have several root causes.  I have tried
disabling ACPI, both in the BIOS, and in the bootloader.  I have disabled
all nonessential devices in the BIOS (except USB), and swapped all cables out
(they're all brand new CAT6).  The problem occurs if em0 is connected to a
switch, or to my laptop via crossover.  After three hours of Googling, I
am stumped.

 

Help?

 

dmesg follows (although em0 and em1 have been replaced with
em4 and em5 temporarily).

 

$ dmesg

Copyright (c) 1992-2008 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.0-RELEASE-p7 #0: Thu Dec 25 14:39:15 EST 2008

    sullr...@freebsd7-releng_1_2_1.pfsense.org:/usr/obj.pfSense/usr/src/sys/pfSense_SMP.7

Timecounter "i8254" frequency 1193182 Hz quality 0

CPU: Intel(R) Xeon(R)
CPU   E5410  @
2.33GHz (2333.43-MHz 686-class CPU)

  Origin = "GenuineIntel"  Id =
0x1067a  Stepping = 10

 
Features=0xbfebfbff

  Features2=0x40ce3bd,>

  AMD Features=0x2010

  AMD Features2=0x1

  Cores per package: 4

real memory  = 2146467840 (2047 MB)

avail memory = 2090897408 (1994 MB)

MPTable: 

FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs

 cpu0 (BSP): APIC ID:  0

 cpu1 (AP): APIC ID:  1

 cpu2 (AP): APIC ID:  2

 cpu3 (AP): APIC ID:  3

ioapic0: Assuming intbase of 0

ioapic1: Assuming intbase of 24

ioapic0  irqs 0-23 on motherboard

ioapic1  irqs 24-47 on motherboard

wlan: mac acl policy registered

kbd1 at kbdmux0

ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112,
RF2413, RF5413)

hptrr: HPT RocketRAID controller driver v1.1 (Dec 25 2008 14:38:55)

cryptosoft0:  on motherboard

cpu0 on motherboard

est0:  on cpu0

est: CPU supports Enhanced Speedstep, but is not recognized.

est: cpu_vendor GenuineIntel, msr 721072106000721

device_attach: est0 attach returned 6

p4tcc0:  on cpu0

cpu1 on motherboard

est1:  on cpu1

est: CPU supports Enhanced Speedstep, but is not recognized.

est: cpu_vendor GenuineIntel, msr 721072106000721

device_attach: est1 attach returned 6

p4tcc1:  on cpu1

cpu2 on motherboard

est2:  on cpu2

est: CPU supports Enhanced Speedstep, but is not recognized.

est: cpu_vendor GenuineIntel, msr 721072106000721

device_attach: est2 attach returned 6

p4tcc2:  on cpu2

cpu3 on motherboard

est3:  on cpu3

est: CPU supports Enhanced Speedstep, but is not recognized.

est: cpu_vendor GenuineIntel, msr 721072106000721

device_attach: est3 attach returned 6

p4tcc3:  on cpu3

pcib0:  pcibus 0 on
motherboard

pci0:  on pcib0

pcib1:  irq 24 at device 1.0 on pci0

pci1:  on pcib1

pcib2:  at device 0.0 on pci1

pci2:  on pcib2

pcib3:  at device 2.0 on pci2

pci3:  on pcib3

pcib3: unable to route slot 0 INTB

em0:  port 0x2000-0x201f mem 0xd802-0xd803,0xd800-0xd801
irq 11 at device 0.0 on pci3

em0: Using MSI interrupt

em0: Ethernet address: 00:15:17:90:09:c1

em0: [FILTER]

em1:  port 0x2020-0x203f mem 0xd806-0xd807,0xd804-0xd805
irq 28 at device 0.1 on pci3

em1: Using MSI interrupt

em1: Ethernet address: 00:15:17:90:09:c0

em1: [FILTER]

pcib4:  at device 4.0 on pci2

pci4:  on pcib4

pcib4: unable to route slot 0 INTB

em2:  port 0x3000-0x301f mem 0xd812-0xd813,0xd810-0xd811
irq 11 at device 0.0 on pci4

em2: Using MSI interrupt

em2: Ethernet address: 00:15:17:90:09:c3

em2: [FILTER]

em3:  port 0x3020-0x303f mem 0xd816-0xd817,0xd814-0xd815
irq 28 at device 0.1 on pci4

em3: Using MSI interrupt

em3: Ethernet address: 00:15:17:90:09:c2

em3: [FILTER]

pcib5:  irq 28 at device 5.0 on pci0

pci5:  on pcib5

pcib6:  irq 28 at device 0.0
on pci5

pci6:  on pcib6

pcib6: unable to route slot 0 INTA

pcib7:  irq 11 at device 0.0 on pci6

pci7:  on pcib7

pcib8:  irq 44 at device 2.0
on pci6

pci8:  on pcib8

em4:  port 0x4000-0x401f mem 0xd822-0xd823,0xd820-0xd821
irq 44 at device 0.0 on pci8

em4: Using MSI interrupt

em4: Ethernet address: 00:30:48:c4:98:4c

em4: [FILTER]

em5:  port 0x4020-0x403f mem 0xd826-0xd827,0xd824-0xd825
irq 40 at device 0.1 on pci8

em5: Using MSI interrupt

em5: Ethernet address: 00: