hello l4 hackers, i'm experimenting with ankh and so far failed to successfully ping morpork from my host machine. it seems that receive() blocks at wait_for_data() indefinitely. i can see irq activity on displayed on screen but wait_for_data() does not unblock. i appreciate any help or ideas... software version: l4re revision r63 (2014-02-28) gcc version 4.8.2 qemu version 1.7.0 qemu command: qemu -cpu core2duo -m 128 -cdrom ./morpork.iso \ -net nic,vlan=0,macaddr=00:e0:4c:c6:45:f4,model=rtl8139 -net tap,vlan=0,ifname=tap0 -serial stdio ping command: arping -i tap0 00:E0:4C:C6:45:F4 output: [32mankh | Initialized DDELinux 2.6 [0m [32mankh | <6>net_namespace: 636 bytes [0m [32mankh | Initializing DDE page cache [0m [32mankh | ddekit_pci_init [0m [32mankh | pci bus constructor [0m [32mankh | PCI: L4 root bridge is device 31ca0 [0m [32mankh | pci_irq_enable: [36mdev 0x118004 [0m [0m [32mankh | pci_irq_enable: [36mirq 11, pin 1, devfn 0 [0m [0m [32mankh | ddekit_pci_irq_enable: [32;1mdevfn 0, pin 0 [0m [0m [32mankh | ddekit_pci_irq_enable: [32;1ml4vbus_pci_irq_enable() = 11 [0m [0m [32mankh | IRQ: set irq type of 11 to 4 [0m [32mankh | l4dde26_register_rx_callback: [36mNew rx callback @ 0x1000200. [0m [0m [32mankh | Softirq daemon starting [0m [32mankh | init_wq_head [0m [32mankh | <6>8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004) [0m [32mankh | pci_irq_enable: [36mdev 0x118004 [0m [0m [32mankh | pci_irq_enable: [36mirq 11, pin 1, devfn 0 [0m [0m [32mankh | ddekit_pci_irq_enable: [32;1mdevfn 0, pin 0 [0m [0m [32mankh | ddekit_pci_irq_enable: [32;1ml4vbus_pci_irq_enable() = 11 [0m [0m [32mankh | IRQ: set irq type of 11 to 4 [0m [32mankh | enable_dev: 0 [0m [32mankh | <6>eth0: RTL-8139C+ at 0x109000, 0x11615cM, IRQ 11 [0m [32mankh | unimplemented: pci_set_master [0m [32mankh | <6>pcnet32.c:v1.35 21.Apr.2008 tsbogend@alpha.franken.de [0m [32mankh | <6>Intel(R) PRO/1000 Network Driver - version 7.3.21-k3-NAPI [0m [32mankh | <6>Copyright (c) 1999-2006 Intel Corporation. [0m [32mankh | open_network_devices() [0m [32mankh | opening lo [0m [32mankh | <6>device lo entered promiscuous mode [0m [32mankh | set interface to promiscuous mode. [0m [32mankh | opening eth0 [0m [32mankh | <6>device eth0 entered promiscuous mode [0m [32mankh | set interface to promiscuous mode. [0m [32mankh | Thread 0x85 for IRQ 11 [0m [32mankh | <6>eth0: link up, 100Mbps, full-duplex, lpa 0x05E1 [0m [32mankh | Opened 2 network devices. [0m [32mankh | lo IRQ: 0x00 MAC: 00:00:00:00:00:00 MTU: 16436 [0m [32mankh | eth0 IRQ: 0x0B MAC: 00:E0:4C:C6:45:F4 MTU: 1500 [0m [32mankh | Registered @ registry. [0m [32mankh | Gooood Morning Ankh-Morpoooooork! TID = 0x5a [0m [32mankh | Creating session factory. [0m [32mankh | Configuration: debug,promisc,device=eth0,shm=shm_morpork,bufsize=16384,phys_mac [0m [32mankh | Debug mode ON. [0m [32mankh | Using promiscuous mode. [0m [32mankh | Device 'eth0' requested. [0m [32mankh | SHM area 'shm_morpork' requested. [0m [32mankh | Buffer size: 16384 [0m [32mankh | Physical MAC requested. [0m [32mankh | shmc_create: 0 [0m [32mankh | Created shmc area 'shm_morpork' [0m [32mankh | Assigning MAC address: 00:E0:4C:C6:45:F4 [0m [36mmorpork | Using shm area: 'shm_morpork' [0m [36mmorpork | argv[2] = '16384' [0m [36mmorpork | My TID = 0x93 [0m [36mmorpork | Attached shm area 'shm_morpork': 0 [0m [36mmorpork | add_chunk: area 0x10555c0, name 'tx_ring', size 16420 [0m [36mmorpork | SND: signal RX 9b, TX 9c [0m [36mmorpork | buf @ 0x301c, area 0x10555c0 (shm_morpork), size 16420 [0m [36mmorpork | owner 0, name tx_ring, signal tx_signal [0m [36mmorpork | head @ 0x103030, lock state 'unlocked', data size 16384 [0m [36mmorpork | next_rd 0 next_wr 0 filled 0, data @ 0x103051 [0m [36mmorpork | add_chunk: area 0x10555c0, name 'rx_ring', size 16420 [0m [36mmorpork | SND: signal RX 9d, TX 9e [0m [36mmorpork | buf @ 0x3074, area 0x10555c0 (shm_morpork), size 16420 [0m [36mmorpork | owner 0, name rx_ring, signal rx_signal [0m [36mmorpork | head @ 0x10707c, lock state 'unlocked', data size 16384 [0m [36mmorpork | next_rd 0 next_wr 0 filled 0, data @ 0x10709d [0m [36mmorpork | SEND RB @ 0x3018 RECV RB @ 0x3070 INFO @ 0x30c8 [0m [32mankh | l4shmc_attach("shm_morpork") = 0 [0m [32mankh | Shm_chunk::get(0xcf98, "info", 36) [0m [32mankh | ... = 0xcec8 [0m [32mankh | RCV: signal RX 9d, TX 9e [0m [32mankh | RCV: buf size 16420 [0m [32mankh | buf @ 0xcd3c, area 0xcf98 (shm_morpork), size 16420 [0m [32mankh | owner 0, name rx_ring, signal rx_signal [0m [32mankh | head @ 0x16c07c, lock state 'unlocked', data size 16384 [0m [32mankh | next_rd 0 next_wr 0 filled 0, data @ 0x16c09d [0m [32mankh | SND: attaching to signal 9e (443000) [0m [32mankh | buf @ 0x16c07c [0m [36mmorpork | activated Ankh connection. [0m [32mankh | xmit thread started, data @ 0xcf38, TID: 0xa0 [0m [32mankh | RCV: signal RX 9b, TX 9c [0m [32mankh | RCV: buf size 16420 [0m [32mankh | buf @ 0xcf04, area 0xcf98 (shm_morpork), size 16420 [0m [32mankh | owner ffffffff, name tx_ring, signal tx_signal [0m [32mankh | head @ 0x168030, lock state 'unlocked', data size 16384 [0m [32mankh | next_rd 0 next_wr 0 filled 0, data @ 0x168051 [0m [32mankh | RCV: attaching to signal 9b (448000) [0m [32mankh | 16384 ... 16384 [0m [36mmorpork | RCV: signal RX 9b, TX 9c [0m [36mmorpork | RCV: buf size 16420 [0m [36mmorpork | buf @ 0x3114, area 0x10555c0 (shm_morpork), size 16420 [0m [36mmorpork | owner 0, name tx_ring, signal tx_signal [0m [36mmorpork | head @ 0x103030, lock state 'unlocked', data size 16384 [0m [36mmorpork | next_rd 0 next_wr 0 filled 0, data @ 0x103051 [0m [36mmorpork | SND: attaching to signal 9c (41c000) [0m [36mmorpork | buf @ 0x103030 [0m [36mmorpork | sender: 0x3100 [0m [36mmorpork | RCV: signal RX 9d, TX 9e [0m [36mmorpork | RCV: buf size 16420 [0m [36mmorpork | buf @ 0x317c, area 0x10555c0 (shm_morpork), size 16420 [0m [36mmorpork | owner 0, name rx_ring, signal rx_signal [0m [36mmorpork | head @ 0x10707c, lock state 'unlocked', data size 16384 [0m [36mmorpork | next_rd 0 next_wr 0 filled 0, data @ 0x10709d [0m [36mmorpork | RCV: attaching to signal 9d (41e000) [0m [36mmorpork | receiver: 0x3168 [0m [36mmorpork | Got assigned MAC: 00:E0:4C:C6:45:F4 [0m [36mmorpork | info @ 0x10b0c8 [0m [36mmorpork | 00:E0:4C:C6:45:F4 MTU 1500 [0m [36mmorpork | RX packets: 0 dropped: 0 [0m [36mmorpork | TX packets: 0 dropped: 0 [0m [36mmorpork | RX bytes: 0 TX bytes: 0 [0m [36mmorpork | recv->wait_for_data(); [0m kind regards, ayad
Hi, On Mon Mar 31, 2014 at 02:26:54 +0200, Ayad Mostafa wrote:
i'm experimenting with ankh and so far failed to successfully ping morpork from my host machine. it seems that receive() blocks at wait_for_data() indefinitely. i can see irq activity on displayed on screen but wait_for_data() does not unblock.
I fear I cannot really help here. What you could try to check is whether the corresponding trigger functionality for the wait_for_data() is actually called to see if that might be a possible reason why this function is not returning. Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
hi, well tracing along the irq handling path i ended up here if (status & DescOwn) { break; } in 8139cp.c, cp_rx_poll(). which doesn't say much except that the "Descriptor is owned by NIC"... kind regards, ayad On Tuesday, April 01, 2014 11:44:48 PM Adam Lackorzynski wrote:
Hi,
On Mon Mar 31, 2014 at 02:26:54 +0200, Ayad Mostafa wrote:
i'm experimenting with ankh and so far failed to successfully ping morpork from my host machine. it seems that receive() blocks at wait_for_data() indefinitely. i can see irq activity on displayed on screen but wait_for_data() does not unblock.
I fear I cannot really help here. What you could try to check is whether the corresponding trigger functionality for the wait_for_data() is actually called to see if that might be a possible reason why this function is not returning.
Adam
On Thu Apr 03, 2014 at 04:21:56 +0200, Ayad Mostafa wrote:
hi,
well tracing along the irq handling path i ended up here if (status & DescOwn) { break; } in 8139cp.c, cp_rx_poll().
which doesn't say much except that the "Descriptor is owned by NIC"...
So it's looping in the while loop all the time while polling the NIC? That would be strange as at some point there should be no more packets to process. Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
Dear Adam,
So it's looping in the while loop all the time while polling the NIC? That would be strange as at some point there should be no more packets to process. it doesn't process any packets. it just enters the loop and breaks at (status & DescOwn). which is weird... and i even tried other cards but so far all behavior is the same.
what i observed so far: - device raises irq -> irq_interrupt() -> schedule a softirq - __do_softirq -> napi->poll(in this case cp_rx_poll()) - cp_rx_poll fails to call cp_rx_skb() best regards, ayad On Thursday, April 03, 2014 10:10:57 PM Adam Lackorzynski wrote:
On Thu Apr 03, 2014 at 04:21:56 +0200, Ayad Mostafa wrote:
hi,
well tracing along the irq handling path i ended up here
if (status & DescOwn) {
break;
}
in 8139cp.c, cp_rx_poll().
which doesn't say much except that the "Descriptor is owned by NIC"...
So it's looping in the while loop all the time while polling the NIC? That would be strange as at some point there should be no more packets to process.
Adam
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07.04.2014 14:42, Ayad Mostafa wrote:
Dear Adam,
So it's looping in the while loop all the time while polling the NIC? That would be strange as at some point there should be no more packets to process. it doesn't process any packets. it just enters the loop and breaks at (status & DescOwn). which is weird... and i even tried other cards but so far all behavior is the same.
Does this mean you also tried non-RTL8139 NICs? Does this happen in qemu if you use for instance the emulated e1000? Bjoern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlNCo58ACgkQP5ijxgQLUNmsEwCglqcgaWisHHuUlXd3gbMG4g3V p50AnRTFw8KWZVfQU/vdbEBlxkPHCSub =lL2J -----END PGP SIGNATURE-----
Hello Bjoern,
Does this mean you also tried non-RTL8139 NICs? Does this happen in qemu if you use for instance the emulated e1000? exactly, but with the e1000, the e1000_clean_rx_irq() does not call netif_receive_skb() because rx_desc->status is always zero.
<irq trigger> dde/linux26/lib/src/arch/l4/irq.c, irq_handler: irq 0xb ankh/server/netlib/e1000/e1000_main.c e1000_intr dde/linux26/linux-headers/linux/netdevice.h netif_rx_schedule_prep dde/linux26/linux-headers/linux/netdevice.h napi_schedule_prep dde/linux26/lib/src/arch/l4/irq.c irq_handler: return: IRQ_HANDLED dde/linux26/lib/src/arch/l4/irq.c,71 local_softirq_pending <softirq trigger> dde/linux26/lib/src/arch/l4/irq.c irq_handler: irq 0xb dde/linux26/lib/src/arch/l4/softirq.c __do_softirq ankh/server/netlib/e1000/e1000_main.c e1000_intr dde/linux26/lib/src/arch/l4/softirq.c __do_softirq dde/linux26/lib/src/arch/l4/irq.c irq_handler: return: IRQ_NONE dde/linux26/lib/src/net/core/dev.c net_rx_action dde/linux26/lib/src/arch/l4/irq.c local_softirq_pending dde/linux26/lib/src/net/core/dev.c net_rx_action ankh/server/netlib/e1000/e1000_main.c e1000_clean ankh/server/netlib/e1000/e1000_main.c e1000_clean_tx_irq ankh/server/netlib/e1000/e1000_main.c e1000_clean_rx_irq ankh/server/netlib/e1000/e1000_main.c e1000_clean_rx_irq, status 0 ankh/server/netlib/e1000/e1000_main.c e1000_set_itr ankh/server/netlib/e1000/e1000_main.c e1000_update_itr ankh/server/netlib/e1000/e1000_main.c e1000_update_itr dde/linux26/lib/src/net/core/dev.c __napi_complete ankh/server/netlib/e1000/e1000_main.c e1000_irq_enable best regards, ayad On Monday, April 07, 2014 03:09:51 PM Björn Döbel wrote:
On 07.04.2014 14:42, Ayad Mostafa wrote:
Dear Adam,
So it's looping in the while loop all the time while polling the NIC? That would be strange as at some point there should be no more packets to process.
it doesn't process any packets. it just enters the loop and breaks at (status & DescOwn). which is weird... and i even tried other cards but so far all behavior is the same.
Does this mean you also tried non-RTL8139 NICs? Does this happen in qemu if you use for instance the emulated e1000?
Bjoern
_______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Ayad,
Does this mean you also tried non-RTL8139 NICs? Does this happen in qemu if you use for instance the emulated e1000? exactly, but with the e1000, the e1000_clean_rx_irq() does not call netif_receive_skb() because rx_desc->status is always zero.
Good news: I was able to reproduce your problem. Bad news: I'm still at loss about what is going wrong there. * The setup seems to work with qemu when I use the NE2K driver and qemu's ne2k_pci NIC. Can you confirm that? * Did you by any chance try this setup on a physical machine, too? Bjoern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlNDuvEACgkQP5ijxgQLUNnCCgCfaP6ZWxogB+ZFTj9q8tWaYNmy 9PoAn17jFmBQXQ7wWOYgQCHtL3cGd7i1 =+AU/ -----END PGP SIGNATURE-----
Hi Bjoern,
* The setup seems to work with qemu when I use the NE2K driver and qemu's ne2k_pci NIC. Can you confirm that? surprisingly, it works...
* Did you by any chance try this setup on a physical machine, too? not yet.
thanks for tip regarding NE2K... best regards, ayad On Tuesday, April 08, 2014 11:01:37 AM Björn Döbel wrote:
Hi Ayad,
Does this mean you also tried non-RTL8139 NICs? Does this happen in qemu if you use for instance the emulated e1000?
exactly, but with the e1000, the e1000_clean_rx_irq() does not call
netif_receive_skb() because rx_desc->status is always zero.
Good news: I was able to reproduce your problem.
Bad news: I'm still at loss about what is going wrong there.
* The setup seems to work with qemu when I use the NE2K driver and qemu's ne2k_pci NIC. Can you confirm that?
* Did you by any chance try this setup on a physical machine, too?
Bjoern
_______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
participants (3)
-
Adam Lackorzynski -
Ayad Mostafa -
Björn Döbel