* Jeremy Chadwick (free...@jdc.parodius.com) wrote:
> It's been mentioned in the past that for "simple" SATA expansion cards,
> a good/affordable choice at this point are cards using the Silicon Image
> 3124/3132/3531 chips (driven by the siis(4) driver). Avoid the 3112.
>
> The reason I say tha
On Sunday 07 March 2010 00:32:21 Jeremy Chadwick wrote:
> On Sat, Mar 06, 2010 at 02:56:07PM -0800, Nick Rogers wrote:
> > ALTQ + RELENG_8 + em(4) will not work at the moment. It does not matter
> > what your PF ruleset looks like or how much traffic you are pushing. The
> > packets that transit th
On Sun, Mar 07, 2010 at 01:28:13AM +, Thomas Hurst wrote:
> * Steven Hartland (kill...@multiplay.co.uk) wrote:
>
> > If that's a supermicro then em3 is usually the IPMI shared card so perhaps
> > that's the cause?
>
> No, it's a Tyan K8WE:
>
> http://www.tyan.com/archive/products/html/thund
* Steven Hartland (kill...@multiplay.co.uk) wrote:
> If that's a supermicro then em3 is usually the IPMI shared card so perhaps
> that's the cause?
No, it's a Tyan K8WE:
http://www.tyan.com/archive/products/html/thunderk8we.html
With a quad port Intel NIC in one of the 133MHz PCI-X slots. The
On Sat, Mar 06, 2010 at 02:56:07PM -0800, Nick Rogers wrote:
> ALTQ + RELENG_8 + em(4) will not work at the moment. It does not matter what
> your PF ruleset looks like or how much traffic you are pushing. The packets
> that transit the em interface simply never make it to the ALTQ queues (not
> ev
ALTQ + RELENG_8 + em(4) will not work at the moment. It does not matter what
your PF ruleset looks like or how much traffic you are pushing. The packets
that transit the em interface simply never make it to the ALTQ queues (not
even the interface's root queue). Thus any kind of bandwidth rate limit
If that's a supermicro then em3 is usually the IPMI shared card so perhaps
that's the cause?
- Original Message -
From: "Thomas Hurst"
Interestingly I can pull 30-60MB/s to/from em0 (LAN) without any
problems, but pulling 5MB/s from em3 has repeatedly led to the interface
just going si
On Sat, Mar 06, 2010 at 12:08:22PM -0800, Nick Rogers wrote:
> Yes, this was the first em(4) problem I ran into when upgrading from
> 7.2-RELEASE to 8.0-RELEASE. Yourself and others on another thread eventually
> recommended turning off TSO and what not. I never had a chance to thoroughly
> test th
Yes, this was the first em(4) problem I ran into when upgrading from
7.2-RELEASE to 8.0-RELEASE. Yourself and others on another thread eventually
recommended turning off TSO and what not. I never had a chance to thoroughly
test this solution on this particular hardware because we had already
switch
I need a bit more context Nick. Is this a card that has been non-problematic
on older releases and just showed a problem with 8.0 REL?
Regards,
Jack
On Sat, Mar 6, 2010 at 10:00 AM, Thomas Hurst wrote:
> * Jack Vogel (jfvo...@gmail.com) wrote:
>
> > Its using MSI? Given that its PCI-X I have
* Jack Vogel (jfvo...@gmail.com) wrote:
> Its using MSI? Given that its PCI-X I have no idea how robust MSI is,
> how bout you compile it with that disabled, use legacy IRQ and see
> if that makes any diff.
I'm seeing similar issues with a quad port 82546EB card, and they're not
using MSI as far
Its using MSI? Given that its PCI-X I have no idea how robust MSI is,
how bout you compile it with that disabled, use legacy IRQ and see
if that makes any diff.
Using TSO on anything pre-PCI Express is a bad idea, probably why
its gotten a bad rep in the em driver.
I have a driver in the works th
I'm still having a problem where an em(4) interface mysteriously "hangs" and
mostly stops sending/receiving packets until I issue an ifconfig emX down
followed by an ifconfig emX up, which fixes the problem for some amount of
time. Traffic on the interface is about a consistent 3mb/s.
One interes
13 matches
Mail list logo
