On Wednesday, March 30, 2011 23:17:53 Adam Stylinski wrote:
> Hello,
>
> This list has helped me before so I'll email again with the hopes that
> somebody has an answer. All is working well with my project, however for
> the life of me I cannot get the interface to inject the raw frames faster
>
On Wed, 30 Mar 2011, YongHyeon PYUN wrote:
Okay, I did a test run with RX checksum, TX checksum and both disabled.
In all three cases the crash occurs within about 20 minutes. I'm either
not sure that age(4) is the problem but it has definedly something to do
with the problem, since with another
On 3/30/11 2:32 PM, Michael Proto wrote:
On Wed, Mar 30, 2011 at 3:43 PM, Kyungsoo Lee wrote:
Hi All,
I want to check UDP on FreeBSD.
I am using IPERF on FreeBSD for wireless testing with Proxim 8470 FC PCMCIA
card on IBM T42 and T61.
When I'm transmitting data from FreeBSD to FreeBSD or Cen
On Thu, Mar 31, 2011 at 09:02:45AM +0200, Bernhard Schmidt wrote:
> On Wednesday, March 30, 2011 23:17:53 Adam Stylinski wrote:
> > Hello,
> >
> > This list has helped me before so I'll email again with the hopes that
> > somebody has an answer. All is working well with my project, however for
>
Hello,
I have upgraded one of my mpd5 based PPPoE access servers from 7.3-RELEASE to
7.4-RELEASE. Just after upgrade, I started getting following errors:
Mar 31 13:48:06 lsm-gw mpd: [B-150] Bundle: Interface ng149 created
Mar 31 13:48:06 lsm-gw mpd: [B-150] can't create ppp node at ".:"->"b150":
On Thursday, March 31, 2011 14:20:33 Adam Stylinski wrote:
> On Thu, Mar 31, 2011 at 09:02:45AM +0200, Bernhard Schmidt wrote:
> > On Wednesday, March 30, 2011 23:17:53 Adam Stylinski wrote:
> > > Hello,
> > >
> > > This list has helped me before so I'll email again with the hopes that
> > > someb
Hi
[let's start a new thread :)]
On Wed, Mar 30, 2011 at 2:22 PM, Jack Vogel wrote:
> Read the code in HEAD, em_local_timer() has a test of ALL the rx queues and
> will schedule a task that refreshes mbufs if they are empty. This has
> exactly the
> same effect as checking for some interrupt cau
On Thu, Mar 31, 2011 at 03:07:15PM +0200, Bernhard Schmidt wrote:
> On Thursday, March 31, 2011 14:20:33 Adam Stylinski wrote:
> > On Thu, Mar 31, 2011 at 09:02:45AM +0200, Bernhard Schmidt wrote:
> > > On Wednesday, March 30, 2011 23:17:53 Adam Stylinski wrote:
> > > > Hello,
> > > >
> > > > This
On Thu, Mar 31, 2011 at 05:35:40PM +0200, Bernhard Schmidt wrote:
> On Thursday, March 31, 2011 17:14:21 Adam Stylinski wrote:
> > On Thu, Mar 31, 2011 at 03:07:15PM +0200, Bernhard Schmidt wrote:
> > > On Thursday, March 31, 2011 14:20:33 Adam Stylinski wrote:
> > > > On Thu, Mar 31, 2011 at 09:02
On Thu, Mar 31, 2011 at 09:05:19AM +0200, Yamagi Burmeister wrote:
> On Wed, 30 Mar 2011, YongHyeon PYUN wrote:
>
> >>Okay, I did a test run with RX checksum, TX checksum and both disabled.
> >>In all three cases the crash occurs within about 20 minutes. I'm either
> >>not sure that age(4) is the
On Thu, 31 Mar 2011, YongHyeon PYUN wrote:
All boxes are quadcore machines with 8GB RAM, running FreeBSD/amd64.
After limiting the memory via hw.physmem to 3GB the problems are gone.
The box is running crashfree for more than 6 hours and has served over
300GB of data via age(4).
Thanks for te
On Thu, Mar 31, 2011 at 08:07:17PM +0200, Yamagi Burmeister wrote:
> On Thu, 31 Mar 2011, YongHyeon PYUN wrote:
>
> >>All boxes are quadcore machines with 8GB RAM, running FreeBSD/amd64.
> >>After limiting the memory via hw.physmem to 3GB the problems are gone.
> >>The box is running crashfree for
On Thu, Mar 31, 2011 at 11:16:52AM -0700, YongHyeon PYUN wrote:
> On Thu, Mar 31, 2011 at 08:07:17PM +0200, Yamagi Burmeister wrote:
> > On Thu, 31 Mar 2011, YongHyeon PYUN wrote:
> >
> > >>All boxes are quadcore machines with 8GB RAM, running FreeBSD/amd64.
> > >>After limiting the memory via hw.
On Thu, 31 Mar 2011, YongHyeon PYUN wrote:
Thanks a lot! It seems the L1 controller has data corruption issue
when 64bit DMA addressing is used. Try this one.
Oops, there was a bug in previous patch.
Try this instead.
Okay, that patch seems to do the trick. This was just a short test run
of
Hi Jack,
On Thu, Mar 31, 2011 at 9:51 AM, Arnaud Lacombe wrote:
> [...]
> I'll remove part of the changes I made to keep only `rx_forced_refill'
> and the associated sysctl, re-run the tests and come back with correct
> value, hopefully in a few hours.
>
Here it is:
# sysctl dev.em.0.%desc
dev.e
So, what is the evidence that the driver is stuck here?
I see that next_to_check != next_to_refresh, which is why the
local timer won't schedule anything. OH, and I also realized there
is a problem with local_timer anyway, it will run rxeof, but that won't help
if you can't enter the loop, so I ne
I have the following config in boot/loader.conf
kern.ipc.nmbclusters="65536"
kern.ipc.nmbjumbop="65536"
and having just tried running a host with that config
the host stopped responding to commands (not even login
worked) and I had to power cycle it.
My situation is that I have a need for a larg
Hi,
On Thu, Mar 31, 2011 at 5:57 PM, Jack Vogel wrote:
> So, what is the evidence that the driver is stuck here?
>
About 800 pps (mostly SYN) present wire but never ever seen on em0,
plus a couple of ARP reply, which still never hit em0, plus the
`missed_packets' count increasing by the same 800
OK, but those are not something present in this data, that was what I'm
asking.
So, you have a hang for which we do not have a certain cause. What does
netstat -m show?
Jack
On Thu, Mar 31, 2011 at 3:15 PM, Arnaud Lacombe wrote:
> Hi,
>
> On Thu, Mar 31, 2011 at 5:57 PM, Jack Vogel wrote:
>
Hi,
On Thu, Mar 31, 2011 at 6:28 PM, Jack Vogel wrote:
> OK, but those are not something present in this data, that was what I'm
> asking.
>
> So, you have a hang for which we do not have a certain cause. What does
> netstat -m show?
>
# netstat -m
3073/74927/78000 mbufs in use (current/cache/to
My validation group has some kind of hang... happens when they use a certain
number
of clients each running a stress test to the SUT, its like this, no real
handle on what's
wrong, if I knew what was wrong it would be half way or more to fixing it :)
The evidence shows you have hit the max cluster
On Wed, Mar 30, 2011 at 08:38 -0400, John Baldwin wrote:
> There is at least one case I know of related to a bug I reported earlier
> where a window probe from a remote connection can cause rcv_nxt to advance
> past rcv_adv by one. However, I think we want to know about those cases,
> and we shoul
You know what Arnaud, I've looked at the numbers again, and I suddenly saw
that next_to_check and next_to_refresh are NOT in a good state, exactly the
opposite, check is BEHIND refresh, which means the whole ring is empty, the
HEAD (next_to_check) is pointing at 929, but next_to_refresh is at 930,
I know how I'm going to handle this, am formulating code for it, should have
a
something that can be tested tomorrow, time to head out for the night..
Essentially, rather than just looking for equality, I will calculate the
number
of unrefreshed mbufs given the check/refresh values, and then call
24 matches
Mail list logo
