I'll take a look. I've been running this code, so I (obviously) didn't see any
failure.
They've just updated ixgbe on sourceforge, so I'm spinning a new patch that
will work with that driver. I'll probably get that out tomorrow. I'll
double-check to make sure we're not allocating memory before the queue is
activated.
-Mitch
>-----Original Message-----
>From: Santos, Jose Renato G [mailto:joserenato.santos@xxxxxx]
>Sent: Wednesday, January 21, 2009 4:17 PM
>To: Williams, Mitch A; xen-devel@xxxxxxxxxxxxxxxxxxx
>Cc: steven.smith@xxxxxxxxxxxxx; Ronciak, John
>Subject: RE: [Xen-devel] RFC: Xen VMDq patch for ixgbe
>
>
>Mitch,
>
>It seems this last patch is not working properly
>I get a kernel panic when the driver module loads (see panic
>message below).
>Apparently the driver is trying to allocate guest memory
>(vmq_alloc_skb()) before the queue is allocated to a guest
>(there is no guest running when the ixgbe module is loaded).
>This is probably something easy to fix
>
>I am able to use the previous version of the patch (version
>1.3.31.3 attached) with no problem. Not sure what changed from
>version 1.3.31.3 to this new version 1.3.47. I am also
>attaching the buggy patch for version 1.3.47 that I am using
>so you can verify if I am using the right patch ...
>
>Could you please take a look at this?
>
>Thanks
>
>Renato
>
>=====================================
>
>Unable to handle kernel paging request at 0000000000007800 RIP:
> [<ffffffff804600a4>] vmq_alloc_skb+0x64/0x1f0
>PGD 79807067 PUD 79710067 PMD 0
>Oops: 0000 [1] SMP
>CPU 0
>Modules linked in: video thermal fan button battery asus_acpi ac ixgbe
>Pid: 0, comm: swapper Not tainted 2.6.18.8-xen0 #73
>RIP: e030:[<ffffffff804600a4>] [<ffffffff804600a4>]
>vmq_alloc_skb+0x64/0x1f0
>RSP: e02b:ffffffff80793ca0 EFLAGS: 00010206
>RAX: ffff88007acc5dd8 RBX: 0000000000000000 RCX: 0000000000080000
>RDX: ffff88007b5d7740 RSI: 0000000000000001 RDI: ffff88007a450000
>RBP: ffffffff80793cd0 R08: 0000000000000001 R09: ffff88007a450c80
>R10: 000000000000003f R11: 000000000000012c R12: 0000000000007800
>R13: 0000000000000000 R14: 0000000000000500 R15: 00000000000005f4
>FS: 00002ba4a6b1eda0(0000) GS:ffffffff80737000(0000)
>knlGS:0000000000000000
>CS: e033 DS: 0000 ES: 0000
>Process swapper (pid: 0, threadinfo ffffffff8074c000, task
>ffffffff8064d440)
>Stack: ffff88007a450000 ffffc200118f0000 0000000000000000
>0000000000000000
> ffff88007b279070 ffff88007a450500 ffffffff80793d30 ffffffff88000d2f
> 000003ff80793d50 ffff880075df0000 ffff88007a450000 ffff88007fe90800
>Call Trace:
> <IRQ> [<ffffffff88000d2f>] :ixgbe:ixgbe_alloc_rx_buffers+0x15f/0x2e0
> [<ffffffff8800320b>] :ixgbe:ixgbe_clean_rx_irq+0x9eb/0xaa0
> [<ffffffff8800798e>] :ixgbe:ixgbe_clean_rxonly_many+0xbe/0x210
> [<ffffffff8800de3e>] :ixgbe:__kc_adapter_clean+0x2e/0x50
> [<ffffffff8052eba4>] net_rx_action+0xc4/0x1c0
> [<ffffffff80239eec>] __do_softirq+0x9c/0x140
> [<ffffffff8020b604>] call_softirq+0x1c/0x28
> [<ffffffff8020d7cc>] do_softirq+0x6c/0x100
> [<ffffffff80239d48>] irq_exit+0x48/0x50
> [<ffffffff80430b92>] evtchn_do_upcall+0x232/0x250
> [<ffffffff8020b13a>] do_hypervisor_callback+0x1e/0x2c
> <EOI> [<ffffffff802063aa>] hypercall_page+0x3aa/0x1000
> [<ffffffff802063aa>] hypercall_page+0x3aa/0x1000
> [<ffffffff8020eed2>] raw_safe_halt+0xc2/0xf0
> [<ffffffff80209b15>] xen_idle+0x75/0x90
> [<ffffffff8020926a>] cpu_idle+0xba/0xe0
> [<ffffffff802073b6>] rest_init+0x26/0x30
> [<ffffffff807568f5>] start_kernel+0x265/0x270
> [<ffffffff8075623d>] _sinittext+0x23d/0x250
>
>
>Code: 4d 39 a6 00 73 00 00 4d 8d ae e8 72 00 00 0f 84 58 01 00 00
>RIP [<ffffffff804600a4>] vmq_alloc_skb+0x64/0x1f0
> RSP <ffffffff80793ca0>
>CR2: 0000000000007800
> <0>Kernel panic - not syncing: Aiee, killing interrupt handler!
> (XEN) Domain 0 crashed: 'noreboot' set - not rebooting.
>
>
>> -----Original Message-----
>> From: Williams, Mitch A [mailto:mitch.a.williams@xxxxxxxxx]
>> Sent: Friday, January 16, 2009 3:57 PM
>> To: Williams, Mitch A; xen-devel@xxxxxxxxxxxxxxxxxxx
>> Cc: steven.smith@xxxxxxxxxxxxx; Ronciak, John; Santos, Jose Renato G
>> Subject: RE: [Xen-devel] RFC: Xen VMDq patch for ixgbe
>>
>> Whoops! Attached the wrong patch file. Please use this one.
>>
>> Sorry for the confusion.
>> -Mitch
>>
>> >-----Original Message-----
>> >From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>> >[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Mitch
>> >Williams
>> >Sent: Friday, January 16, 2009 3:06 PM
>> >To: xen-devel@xxxxxxxxxxxxxxxxxxx
>> >Cc: steven.smith@xxxxxxxxxxxxx; Ronciak, John;
>> joserenato.santos@xxxxxx
>> >Subject: [Xen-devel] RFC: Xen VMDq patch for ixgbe
>> >
>> >Attached is a patch to enable Xen VMDq (AKA Netchannel2
>vmq) for the
>> >ixgbe driver. This is intended for testing and development
>purposes
>> >and should not be considered to be production-quality code.
>> >
>> >Please note that this does NOT apply to the Xen Linux kernel; it
>> >applies to the ixgbe 1.3.47 release, available from
>> >http://sourceforge.net/projects/e1000/. You'll obviously
>> also need an
>> >Intel 82598-based 10 Gigabit network card and some sort of link
>> >partner. This will build against the current Netchannel2 source
>> >available from http:xenbits.xen.org/ext/netchannel2.
>You'll need to
>> >enable "Net channel 2 support for multi-queue devices" in
>> your kernel
>> >config.
>> >
>> >To enable VMDq functionality, load the driver with the command-line
>> >parameter VMDQ=<num queues>, as in:
>> >
>> >$ insmod ~/ixgbe-1.3.47/src/ixgbe.ko VMDQ=8
>> >
>> >You can then set up PV domains to use the device by
>> modifying your VM
>> >configuration file from
>> > vif = [ '<whatever>' ]
>> >to
>> > vif2 = [ 'pdev=<netdev>' ]
>> >where <netdev> is the interface name for your 82598 board,
>> e.g peth0 in
>> >dom0.
>> >
>> >Known issues (at least, known by me):
>> >1) Must manually attach bridge device after starting domU vm.
>> >Netchannel2 backend devices show up as ethNN, not vifN.M, so the
>> >scripts don't automatically attach the interface. Once your
>> VM starts,
>> >do ifconfig -a to see which new interface got added. Then
>> use "brctl
>> >addif" to add this new interface the the bridge.
>> >2) No broadcast replication. This is a big one. Incoming
>> broadcasts
>> >will ONLY go to dom0. This means that your VMs can send ARP
>> requests
>> >and initiate IP sessions to outside machines, but outside machines
>> >cannot initiate connections because the ARP requests don't
>go to the
>> >domU VMs.
>> >3) No loopback. VMs cannot communicate with other VMs (including
>> >dom0) on the same machine.
>> >
>> >Once I get this out, I'll start working on a proper backport of the
>> >driver into the Xen kernel (2.6.18.8) tree. I'll remove as
>> much of the
>> >compatibility cruft as is prudent and properly integrate it into
>> >the Kbuild stuff. When that's done, I'll send a complete
>> patchset to
>> >this list, including signed-off-by lines which can then be
>> checked in
>> >to Mercurial.
>> >
>> >Please review and comment, and if possible test.
>> >
>> >Thanks,
>> >Mitch
>> >
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home