Synopsis: 5.4 system with SMP and IPFW crashes under load (mbuf underrun)
State-Changed-From-To: suspended->closed
State-Changed-By: brucec
State-Changed-When: Wed Jul 21 22:30:29 UTC 2010
State-Changed-Why:
FreeBSD 5.x is no longer supported.
http://www.freebsd.org/cgi/query-pr.cgi?pr=87094
__
On Wed, Jul 21, 2010 at 10:03:32PM +0200, Kurt Jaeger wrote:
> Hi!
>
> > > http://opsec.eu/backup/alc-bug/dmesg.boot-verbose
>
> > One odd thing is alc(4) failed to read station address from EEPROM.
> > So alc(4) assumed BIOS correctly programmed station address but the
> > station address looks
Hi!
> > http://opsec.eu/backup/alc-bug/dmesg.boot-verbose
> One odd thing is alc(4) failed to read station address from EEPROM.
> So alc(4) assumed BIOS correctly programmed station address but the
> station address looks wrong to me.
> How about cold booting? Does other OS also report the same
On Wed, Jul 21, 2010 at 07:06:05PM +0200, Kurt Jaeger wrote:
> Hi!
>
> > > > A reboot with connected cable follows this evening.
> > >
> > > A reboot with connected cable was booting successfully.
>
> > Would you show me verbose dmesg output?
> > With verbose boot alc(4) will show additional inf
Hi!
> > > A reboot with connected cable follows this evening.
> >
> > A reboot with connected cable was booting successfully.
> Would you show me verbose dmesg output?
> With verbose boot alc(4) will show additional information which may
> help to narrow down the issue.
http://opsec.eu/backup/a
On Wed, Jul 21, 2010 at 08:32:34AM +0200, Kurt Jaeger wrote:
> Hi!
>
> > A reboot with connected cable follows this evening.
>
> A reboot with connected cable was booting successfully.
>
Would you show me verbose dmesg output?
With verbose boot alc(4) will show additional information which may
Synopsis: 5.4 system with SMP and IPFW crashes under load (mbuf underrun)
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: brucec
Responsible-Changed-When: Wed Jul 21 16:35:28 UTC 2010
Responsible-Changed-Why:
Over to maintainer(s).
http://www.freebsd.org/cgi/query-
Synopsis: [mbuf] [patch] Reference count computing isn't correct when more than
one threads call function m_copypacket
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: brucec
Responsible-Changed-When: Wed Jul 21 16:33:57 UTC 2010
Responsible-Changed-Why:
Over to mai
Synopsis: [panic] 8.1-RELEASE "panic: sbdrop" and "panic: sbsndptr: sockbuf _
and mbuf _ clashing" under heavy load
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: brucec
Responsible-Changed-When: Wed Jul 21 16:30:32 UTC 2010
Responsible-Changed-Why:
Over to mainta
On 2010-07-21 02:21, Patrick Mahan wrote:
> I am the first to admit I don't understand ALTQ and it's impact on QoS but
> that said, I am trying to learn.
>
> I have the following three systems. All systems are running FreeBSD
> 8.0-p2 Release.
> I am attempting to learn how AltQ can be used to
In your setup, the data is flowing from the iperf client (sender) on
NPX4 to the iperf server (receiver) on NPX1.
Apply the queue on the interface on NPX3 where the data is flowing
out, i.e. the interface facing NPX1. Queueing applies to outgoing
packets of an interface, not incoming packets.
It
It's hard to believe it's switch's problem or unicast issue,
because all the 82576/82571 NICs are on the same switch.
I even have done a testing.
I put one 82571 and one 82576 card in the same machine. And all of the
NICs are plugged into a same switch. And they are not configued
any IP address,
12 matches
Mail list logo
