search for: ip_queue_xmit

...t; 0000000000000000 ffffffff8127743d 0000000000000000 ffff88001ecd0cfc [469390.126954] Call Trace: [469390.126963] [<ffffffff81255a20>] ? neigh_resolve_output+0x1ff/0x284 [469390.126974] [<ffffffff8127743d>] ? ip_finish_output2+0x1d6/0x22b [469390.126983] [<ffffffff8127708f>] ? ip_queue_xmit+0x311/0x386 [469390.126994] [<ffffffff8100dc35>] ? xen_force_evtchn_callback+0x9/0xa [469390.127003] [<ffffffff8100e242>] ? check_events+0x12/0x20 [469390.127013] [<ffffffff81287a47>] ? tcp_transmit_skb+0x648/0x687 [469390.127022] [<ffffffff8100e242>] ? check_events+0x12...

...t; 0000000000000000 ffffffff8127743d 0000000000000000 ffff88001ecd0cfc [469390.126954] Call Trace: [469390.126963] [<ffffffff81255a20>] ? neigh_resolve_output+0x1ff/0x284 [469390.126974] [<ffffffff8127743d>] ? ip_finish_output2+0x1d6/0x22b [469390.126983] [<ffffffff8127708f>] ? ip_queue_xmit+0x311/0x386 [469390.126994] [<ffffffff8100dc35>] ? xen_force_evtchn_callback+0x9/0xa [469390.127003] [<ffffffff8100e242>] ? check_events+0x12/0x20 [469390.127013] [<ffffffff81287a47>] ? tcp_transmit_skb+0x648/0x687 [469390.127022] [<ffffffff8100e242>] ? check_events+0x12...

...start_xmit+0x346/0x600 > [ 8.644123] [<000000000052a43c>] sch_direct_xmit+0xe8/0x1e8 > [ 8.644126] [<0000000000505be8>] __dev_queue_xmit+0x214/0x4ec > [ 8.644131] [<000000000054a476>] ip_finish_output+0x436/0x90c > [ 8.644134] [<000000000054b7c0>] ip_queue_xmit+0x170/0x3e8 > [ 8.644137] [<00000000005636ca>] tcp_transmit_skb+0x462/0x984 > [ 8.644140] [<0000000000564870>] tcp_write_xmit+0x220/0xd0c > [ 8.644143] [<00000000005653a2>] tcp_push_one+0x46/0x58 > [ 8.644145] [<00000000005568b4>] tcp_sendmsg+0xb7...

...start_xmit+0x346/0x600 > [ 8.644123] [<000000000052a43c>] sch_direct_xmit+0xe8/0x1e8 > [ 8.644126] [<0000000000505be8>] __dev_queue_xmit+0x214/0x4ec > [ 8.644131] [<000000000054a476>] ip_finish_output+0x436/0x90c > [ 8.644134] [<000000000054b7c0>] ip_queue_xmit+0x170/0x3e8 > [ 8.644137] [<00000000005636ca>] tcp_transmit_skb+0x462/0x984 > [ 8.644140] [<0000000000564870>] tcp_write_xmit+0x220/0xd0c > [ 8.644143] [<00000000005653a2>] tcp_push_one+0x46/0x58 > [ 8.644145] [<00000000005568b4>] tcp_sendmsg+0xb7...

...and skb->priority fields are both zero. As a result control falls through until the default class is selected. The small test I am using is that my application simply sets all of the outgoing data to a single priority. And it is not set to the default :-) I have tracked it down as far as the ip_queue_xmit function in net/ipv4/ip_output.c. There the skb->priority and the skb->sk field are correct however we go through the NF_HOOK, which is where I got lost. There is no reason I can think of that a socket should lose any of it''s options between these two points in the code. Could so...

.../0x600 >> [ 8.644123] [<000000000052a43c>] sch_direct_xmit+0xe8/0x1e8 >> [ 8.644126] [<0000000000505be8>] __dev_queue_xmit+0x214/0x4ec >> [ 8.644131] [<000000000054a476>] ip_finish_output+0x436/0x90c >> [ 8.644134] [<000000000054b7c0>] ip_queue_xmit+0x170/0x3e8 >> [ 8.644137] [<00000000005636ca>] tcp_transmit_skb+0x462/0x984 >> [ 8.644140] [<0000000000564870>] tcp_write_xmit+0x220/0xd0c >> [ 8.644143] [<00000000005653a2>] tcp_push_one+0x46/0x58 >> [ 8.644145] [<00000000005568b4>]...

...310.079313] ? __read_once_size_nocheck.constprop.7+0x20/0x20 > > [ 310.080265] ? sock_prot_inuse_add+0xa0/0xa0 > > [ 310.081097] ? memcpy+0x45/0x50 > > [ 310.081850] ? __copy_skb_header+0x1fa/0x280 > > [ 310.082676] ip_local_out+0x70/0x90 > > [ 310.083448] ip_queue_xmit+0x8a1/0x22a0 > > [ 310.084236] ? ip_build_and_send_pkt+0xe80/0xe80 > > [ 310.085079] ? tcp_v4_md5_lookup+0x13/0x20 > > [ 310.085884] tcp_transmit_skb+0x187a/0x3e00 > > [ 310.086696] ? __tcp_select_window+0xaf0/0xaf0 > > [ 310.087524] ? sock_sendmsg+0xba/0xf0...

...310.079313] ? __read_once_size_nocheck.constprop.7+0x20/0x20 > > [ 310.080265] ? sock_prot_inuse_add+0xa0/0xa0 > > [ 310.081097] ? memcpy+0x45/0x50 > > [ 310.081850] ? __copy_skb_header+0x1fa/0x280 > > [ 310.082676] ip_local_out+0x70/0x90 > > [ 310.083448] ip_queue_xmit+0x8a1/0x22a0 > > [ 310.084236] ? ip_build_and_send_pkt+0xe80/0xe80 > > [ 310.085079] ? tcp_v4_md5_lookup+0x13/0x20 > > [ 310.085884] tcp_transmit_skb+0x187a/0x3e00 > > [ 310.086696] ? __tcp_select_window+0xaf0/0xaf0 > > [ 310.087524] ? sock_sendmsg+0xba/0xf0...

...0571a>] dev_hard_start_xmit+0x346/0x600 [ 8.644123] [<000000000052a43c>] sch_direct_xmit+0xe8/0x1e8 [ 8.644126] [<0000000000505be8>] __dev_queue_xmit+0x214/0x4ec [ 8.644131] [<000000000054a476>] ip_finish_output+0x436/0x90c [ 8.644134] [<000000000054b7c0>] ip_queue_xmit+0x170/0x3e8 [ 8.644137] [<00000000005636ca>] tcp_transmit_skb+0x462/0x984 [ 8.644140] [<0000000000564870>] tcp_write_xmit+0x220/0xd0c [ 8.644143] [<00000000005653a2>] tcp_push_one+0x46/0x58 [ 8.644145] [<00000000005568b4>] tcp_sendmsg+0xb7c/0xc9c [ 8.64414...

..._neigh_event_send+0x18d/0x200 > [<ffffffff81449a42>] neigh_resolve_output+0x162/0x1b0 > [<ffffffff81477046>] ip_finish_output+0x146/0x320 > [<ffffffff814754a5>] ip_output+0x85/0xd0 > [<ffffffff814758d9>] ip_local_out+0x29/0x30 > [<ffffffff814761e0>] ip_queue_xmit+0x1c0/0x3d0 > [<ffffffff8148d3ef>] tcp_transmit_skb+0x40f/0x520 > [<ffffffff8148e5ff>] tcp_retransmit_skb+0x16f/0x2e0 > [<ffffffff814908c0>] ? tcp_retransmit_timer+0x4a0/0x4a0 > [<ffffffff814905ad>] tcp_retransmit_timer+0x18d/0x4a0 > [<ffffffff814908c0...

Hi, I have 2 servers which are connected to a gateway machine. The gateway and one server are running Linux 2.6.16.2, while the third machine is running 2.6.16.5. The two ethernet ports on the gateway which are connected to the servers are combined into a single ethernet bridge device. Ever since 2.6.16, I have noticed that I can no longer cross-mount the two servers' /home directories via

Hi, We are trying to validate Asterisk as a media gateway PRI <-> SIP with two T400P (8 T1s) per box. The first experience with BOX1 (Compaq, 2.53 GHz, 1 Gb RAM) and just one T400P was encouraging - on the load test with 3 T1s worth of calls we had on average 75% idle CPU. Not so with BOX2 (Dell, single 2.6 GHz Xeon, 1 Gb RAM, 2 T400P) and BOX3 (Dell, dual 2.6 GHz Xeon, 2 Gb RAM, 2 T400P,

This fixes virtio on Xen guests as well as on any other platform that uses virtio_pci on which physical addresses don't match bus addresses. This can be tested with: virtme-run --xen xen --kimg arch/x86/boot/bzImage --console using virtme from here: https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git Without these patches, the guest hangs forever. With these patches,

This fixes virtio on Xen guests as well as on any other platform that uses virtio_pci on which physical addresses don't match bus addresses. This can be tested with: virtme-run --xen xen --kimg arch/x86/boot/bzImage --console using virtme from here: https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git Without these patches, the guest hangs forever. With these patches,

Hi Ian, Today i fired up an old VM with a bittorrent client, trying to download some torrents. I seem to be hitting the unlikely case of "xennet: skb rides the rocket: xx slots" and this results in some dropped packets in domU, I don''t see any warnings in dom0. I have added some extra info, but i don''t have enough knowledge if this could/should be prevented from

...tput2+0xece/0x1460 net/ipv4/ip_output.c:229 ip_finish_output+0x85e/0xd10 net/ipv4/ip_output.c:317 NF_HOOK_COND include/linux/netfilter.h:239 [inline] ip_output+0x1cc/0x860 net/ipv4/ip_output.c:405 dst_output include/net/dst.h:460 [inline] ip_local_out+0x95/0x160 net/ipv4/ip_output.c:124 ip_queue_xmit+0x8c6/0x18e0 net/ipv4/ip_output.c:504 tcp_transmit_skb+0x1b12/0x38b0 net/ipv4/tcp_output.c:1176 tcp_write_xmit+0x680/0x5190 net/ipv4/tcp_output.c:2367 __tcp_push_pending_frames+0xa0/0x250 net/ipv4/tcp_output.c:2543 tcp_push+0x538/0x770 net/ipv4/tcp.c:730 tcp_sendmsg_locked+0x2663/0x3b30 n...