El 19/02/15 a les 21.02, Gleb Smirnoff ha escrit:
> On Thu, Feb 19, 2015 at 07:47:18PM +0100, Roger Pau Monné wrote:
> R> El 19/02/15 a les 2.19, Gleb Smirnoff ha escrit:
> R> > Author: glebius
> R> > Date: Thu Feb 19 01:19:42 2015
> R> > New Revision: 278977
> R> > URL: https://svnweb.freebsd.org/changeset/base/278977
> R> >
> R> > Log:
> R> > Provide a set of inline functions to manage simple mbuf(9) queues,
> based
> R> > on queue(3)'s STAILQ. Utilize them in cxgb(4) and Xen, deleting home
> R> > grown implementations.
> R> >
> R> > Sponsored by: Netflix
> R> > Sponsored by: Nginx, Inc.
> R>
> R> Have you tested this commit on Xen? I'm getting the following:
> R>
> R> xn0: <Virtual Network Interface> at device/vif/0 on xenbusb_front0
> R> xn0: Ethernet address: 00:16:3e:51:85:e3
> R> xenbusb_back0: <Xen Backend Devices> on xenstore0
> R> xbd0: Back-end specified ring-pages of 15 is not a power of 2. Limited to
> 8.
> R> xn0: backend features: feature-sg feature-gso-tcp4
> R> panic: no mbufs processed
> R> cpuid = 0
> R> KDB: stack backtrace:
> R> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfffffe007adc3920
> R> vpanic() at vpanic+0x189/frame 0xfffffe007adc39a0
> R> kassert_panic() at kassert_panic+0x132/frame 0xfffffe007adc3a10
> R> network_alloc_rx_buffers() at network_alloc_rx_buffers+0x439/frame
> 0xfffffe007adc3ac0
> R> network_connect() at network_connect+0xac1/frame 0xfffffe007adc3b50
> R> netfront_backend_changed() at netfront_backend_changed+0xed/frame
> 0xfffffe007adc3b90
> R> xenwatch_thread() at xenwatch_thread+0x1a2/frame 0xfffffe007adc3bb0
> R> fork_exit() at fork_exit+0x84/frame 0xfffffe007adc3bf0
> R> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe007adc3bf0
> R> --- trap 0, rip = 0, rsp = 0xfffffe007adc3cb0, rbp = 0 ---
> R> KDB: enter: panic
> R> [ thread pid 15 tid 100038 ]
> R> Stopped at kdb_enter+0x3e: movq $0,kdb_why
>
> I guess the problem is that the queue limit isn't initialized. Please
> try the attached patch.
>
> The problem with older mbufq was that it doesn't have any sane limit
> on it. So, converting to new, I simply put INT_MAX, which is ugly.
>
> I'd appreciate if you fix mbufq_init()s in netfront.c to some appropriate
> values.
Hello,
I've tried the attached patch and now I get a different panic:
[...]
xn0: <Virtual Network Interface> at device/vif/0 on xenbusb_front0
xn0: Ethernet address: 00:16:3e:0a:80:c2
xenbusb_back0: <Xen Backend Devices> on xenstore0
xbd0: Back-end specified ring-pages of 15 is not a power of 2. Limited to 8.
xn0: backend features: feature-sg feature-gso-tcp4
xbd0:
Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x20:0xffffffff80b0c60b
stack pointer = 0x28:0xfffffe0096c18960
frame pointer = 0x28:0xfffffe0096c18a30
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 12 (irq778: xn0)
[ thread pid 12 tid 100052 ]
Stopped at tcp_lro_rx+0x1b: movw 0xc(%rbx),%r15w
db> bt
Tracing pid 12 tid 100052 td 0xfffff80002da2940
tcp_lro_rx() at tcp_lro_rx+0x1b/frame 0xfffffe0096c18a30
xn_intr() at xn_intr+0xa12/frame 0xfffffe0096c18b30
intr_event_execute_handlers() at intr_event_execute_handlers+0xe1/frame
0xfffffe0096c18b70
ithread_loop() at ithread_loop+0xac/frame 0xfffffe0096c18bb0
fork_exit() at fork_exit+0x84/frame 0xfffffe0096c18bf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0096c18bf0
--- trap 0, rip = 0, rsp = 0xfffffe0096c18cb0, rbp = 0 ---
db>
addr2line however seems to be unable to resolve the IP address
to a line number:
# addr2line -e /boot/kernel/kernel ffffffff80b0c60b
??:0
Roger.
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
