On Fri, Jun 02, 2006 at 04:16:08PM +0200, Patrick McHardy wrote:
> Which network driver are you using?
I've seen it with two completely different NICs at the sender side:
:02:08.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro
100] (rev 05)
:02:00.0 Ethernet controller: Br
Frank van Maarseveen wrote:
> The 2.6.13.2 data is inconsistent. The bug appears to be present there at
> well after closer examination. So there must be another factor involved
> because I have at least one case logged where 2.6.13.2 did work (the
> "sirkka" log in my previous mail). Applying your
On Fri, Jun 02, 2006 at 02:35:59PM +0200, me wrote:
[...]
> This is a tcpdump done after rebooting "posio"
> to 2.6.13.2 showing how it should have looked:
[snip]
The 2.6.13.2 data is inconsistent. The bug appears to be present there at
well after closer examination. So there must be another fa
On Thu, Jun 01, 2006 at 07:34:47PM +0200, Patrick McHardy wrote:
> Frank van Maarseveen wrote:
> > ok, now "tc -s -d qdisc show" says (after noticing missing netconsole
> > packets):
> >
> > qdisc pfifo_fast 0: dev eth0 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1
> > 1
> > Sent 155031 bytes 2
Frank van Maarseveen wrote:
> ok, now "tc -s -d qdisc show" says (after noticing missing netconsole
> packets):
>
> qdisc pfifo_fast 0: dev eth0 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
> Sent 155031 bytes 2067 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
Mhh n
On Wed, May 31, 2006 at 07:46:20PM +0200, Patrick McHardy wrote:
[...]
> > ip -s link doesn't show any
> > dropped packets so far with any patch and I don't use traffic control
> > that I'm aware of. But I'm not sure what to make of "tc" output, maybe
> > because CONFIG_SHAPER is not set:
> >
>
On Wed, May 31, 2006 at 07:46:20PM +0200, Patrick McHardy wrote:
> Frank van Maarseveen wrote:
> > On Wed, May 31, 2006 at 06:36:35PM +0200, Patrick McHardy wrote:
> >
> >>The messages might get dropped when the output queue is full.
> >>Does one of the drop counters shown by "ip -s link list"
> >
Frank van Maarseveen wrote:
> On Wed, May 31, 2006 at 06:36:35PM +0200, Patrick McHardy wrote:
>
>>The messages might get dropped when the output queue is full.
>>Does one of the drop counters shown by "ip -s link list"
>>and "tc -s -d qdisc show" increase (the other counts might also
>>give some
On Wed, May 31, 2006 at 06:36:35PM +0200, Patrick McHardy wrote:
[...]
> > "protocol is buggy" is gone. The other problem is still there.
>
>
> The messages might get dropped when the output queue is full.
> Does one of the drop counters shown by "ip -s link list"
> and "tc -s -d qdisc sho
Frank van Maarseveen wrote:
> On Wed, May 31, 2006 at 04:57:13PM +0200, Patrick McHardy wrote:
>
>>The message means that there was recursion and netpoll fell back
>>to dev_queue_xmit This patch should fix the "protocol is buggy"
>>messages, netpoll didn't set skb->nh.raw. Please try if it also
>>
On Wed, May 31, 2006 at 04:57:13PM +0200, Patrick McHardy wrote:
> Frank van Maarseveen wrote:
> > I have two machines named "porvoo" and "espoo". The first one
> > has netconsole configured to send kernel messages to UDP port 514
> > (a.k.a. syslog) on the other machine.
> >
> > Somewhere between
Frank van Maarseveen wrote:
> I have two machines named "porvoo" and "espoo". The first one
> has netconsole configured to send kernel messages to UDP port 514
> (a.k.a. syslog) on the other machine.
>
> Somewhere between 2.6.13.2 and 2.6.17-rc4 there is a regression causing
> the netconsole messa
12 matches
Mail list logo
