Roger Pau Monné <roger.pau <at> citrix.com> writes:> > Hello, > > I've pushed a new branch, pvhvm_v10 that contains a PV IPI > implementation for both amd64 and i386. I've also updated the wiki to > point to the pvhvm_v10 branch: > > http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=shortlog;h=refs/heads/pvhvm_v10> > I've updated my tree to latest HEAD, so now branch pvhvm_v10 is on top > of this commit: > > commit b44da0fb82647f2cfb06f65a6695c7e36c98828c > Author: gber <gber <at> FreeBSD.org> > Date: Thu May 23 12:24:46 2013 +0000 > > Rework and organize pmap_enter_locked() function. > > pmap_enter_locked() implementation was very ambiguous and confusing. > Rearrange it so that each part of the mapping creation is separated. > Avoid walking through the redundant conditions. > Extract vector_page specific PTE setup from normal PTE setting. > > Submitted by: Zbigniew Bodek <zbb <at> semihalf.com> > Sponsored by: The FreeBSD Foundation, Semihalf > > Thanks for the testing, Roger. >Have you (or anyone) done some testing under NetBSD Dom0? I guess its not related, but I'm getting a panic when using SSH. I was able to compile and install the kernel, and booted fine (just needed to adapt fstab, other than that no issues). I've done some tests with ping, ftp, wget, but when I tried SSH (both to the vm and from the vm, I got a panic) ===== PANIC ===xn_txeof: WARNING: response is -1! debug1: SSH2_MSGxn_txeof: WARNING: response is -1! _KEXINIT receivepanic: mbuf already on the free list, but we're trying to free it again! cpuid = 0 KDB: enter: panic [ thread pid 12 tid 100039 ] Stopped at kdb_enter+0x3e: movq $0,kdb_why db> bt Tracing pid 12 tid 100039 td 0xfffffe0008101000 kdb_enter() at kdb_enter+0x3e/frame 0xffffff8095021940 vpanic() at vpanic+0x146/frame 0xffffff8095021980 kassert_panic() at kassert_panic+0x136/frame 0xffffff80950219f0 xn_txeof() at xn_txeof+0x99/frame 0xffffff8095021a40 xn_intr() at xn_intr+0x59/frame 0xffffff8095021b30 intr_event_execute_handlers() at intr_event_execute_handlers+0x90/frame 0xffffff8095021b70 ithread_loop() at ithread_loop+0x148/frame 0xffffff8095021bb0 fork_exit() at fork_exit+0x84/frame 0xffffff8095021bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xffffff8095021bf0 --- trap 0, rip = 0, rsp = 0xffffff8095021cb0, rbp = 0 --- db> == PANIC == I've tried with pvhvm_v10 first, and now with pvhvm_v17, but give me the panic! _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/21/13 17:55, Miguel Clara wrote:> Roger Pau Monné <roger.pau <at> citrix.com> writes: > >> >> Hello, >> >> I've pushed a new branch, pvhvm_v10 that contains a PV IPI >> implementation for both amd64 and i386. I've also updated the >> wiki to point to the pvhvm_v10 branch: >> >> http://xenbits.xen.org/gitweb/?p=people/royger/ > freebsd.git;a=shortlog;h=refs/heads/pvhvm_v10 >> >> I've updated my tree to latest HEAD, so now branch pvhvm_v10 is >> on top of this commit: >> >> commit b44da0fb82647f2cfb06f65a6695c7e36c98828c Author: gber >> <gber <at> FreeBSD.org> Date: Thu May 23 12:24:46 2013 +0000 >> >> Rework and organize pmap_enter_locked() function. >> >> pmap_enter_locked() implementation was very ambiguous and >> confusing. Rearrange it so that each part of the mapping creation >> is separated. Avoid walking through the redundant conditions. >> Extract vector_page specific PTE setup from normal PTE setting. >> >> Submitted by: Zbigniew Bodek <zbb <at> semihalf.com> Sponsored >> by: The FreeBSD Foundation, Semihalf >> >> Thanks for the testing, Roger. >> > > Have you (or anyone) done some testing under NetBSD Dom0? I guess > its not related, but I'm getting a panic when using SSH. > > I was able to compile and install the kernel, and booted fine (just > needed to adapt fstab, other than that no issues). > > I've done some tests with ping, ftp, wget, but when I tried SSH > (both to the vm and from the vm, I got a panic) > > ===== PANIC ==== xn_txeof: WARNING: response is -1! debug1: > SSH2_MSGxn_txeof: WARNING: response is -1! _KEXINIT receivepanic: > mbuf already on the free list, but we're trying to free it again! > cpuid = 0 KDB: enter: panic [ thread pid 12 tid 100039 ] Stopped at > kdb_enter+0x3e: movq $0,kdb_why db> bt Tracing pid 12 tid 100039 > td 0xfffffe0008101000 kdb_enter() at kdb_enter+0x3e/frame > 0xffffff8095021940 vpanic() at vpanic+0x146/frame > 0xffffff8095021980 kassert_panic() at kassert_panic+0x136/frame > 0xffffff80950219f0 xn_txeof() at xn_txeof+0x99/frame > 0xffffff8095021a40 xn_intr() at xn_intr+0x59/frame > 0xffffff8095021b30 intr_event_execute_handlers() at > intr_event_execute_handlers+0x90/frame 0xffffff8095021b70 > ithread_loop() at ithread_loop+0x148/frame 0xffffff8095021bb0 > fork_exit() at fork_exit+0x84/frame 0xffffff8095021bf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xffffff8095021bf0 > --- trap 0, rip = 0, rsp = 0xffffff8095021cb0, rbp = 0 --- db> > > == PANIC ==> > > I've tried with pvhvm_v10 first, and now with pvhvm_v17, *both* > give me the panic! >I also saw this in the core dump logs... not sure if its relevant: ada0: disk error cmd=write 59105570-59105633 status: ffffffff g_vfs_done():ada0p3[WRITE(offset=21671575552, length=32768)]error = 5 xn_txeof: WARNING: response is -1! xn_txeof: WARNING: response is -1!> > > _______________________________________________ Xen-users mailing > list Xen-users@lists.xen.org http://lists.xen.org/xen-users >-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRxLhOAAoJEGKyFhaKt9g3PhcQALdHJAiOJb3pWYNTx5BEiSg9 F6WZ/EGPM0ZmLZPvcBzP3vF/fGhDBFUv2jyvRFvc9/OaYM9zJ3w7o9/mn+C3IKot oubK++OOLRIyuExo/G4MlIFUSYyntxWlPks62QkeheqRclUcTCcJ3hr6i74DRXcb vh3v7NimmCkf+Zsxl5Ie7ct82HK1/fiVakle7T+HcSUET09LSaZZExx6sF+Hb4iH 8dvnAECKqEOnFCiPw+ztKb0d0qsK5fWgXmTQJf7IQM/+gb8CHKyTGK1cPU58vzx7 nRt6vp1Pzt8Z7xvgfpPCZHvQBjLg1iS7+Igi1YN4iaaEBdBoDgbb+9J24PWmsXpH KNsGA3ucu4TqHENzKSzss+JD7bF2XFcs4by4KT4hF4CPYNhHOg3BOwgE8Lc9phzc hDvk1kyRqxld0zhhCBVmQZOGdWPu3Qx5VK1TzgxEGQaHOzyWNwNdc5MBkSx7vsJv QfU+3JPOy3kX21Iln+TGaexC/oVUTlbL3DIwmxkGARLPk+u1IpvrszXAEN5qSCbZ xlLTxPZzegH1+RiQWVw+oHI5yFFGLAwzfxx24mwgYUOU//reOdq+8AhcXwgus80n 72ukUgayQjyhO+b3kcAX2+w4KKD084HUJB+OSGTRYTCmskxnEWEGWBuwDvXomEoE 5b1lWBaQENl65Ps8LzPh =svQc -----END PGP SIGNATURE----- _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
On 21/06/13 19:55, Miguel Clara wrote:> Roger Pau Monné <roger.pau <at> citrix.com> writes: > >> >> Hello, >> >> I've pushed a new branch, pvhvm_v10 that contains a PV IPI >> implementation for both amd64 and i386. I've also updated the wiki to >> point to the pvhvm_v10 branch: >> >> http://xenbits.xen.org/gitweb/?p=people/royger/ > freebsd.git;a=shortlog;h=refs/heads/pvhvm_v10 >> >> I've updated my tree to latest HEAD, so now branch pvhvm_v10 is on top >> of this commit: >> >> commit b44da0fb82647f2cfb06f65a6695c7e36c98828c >> Author: gber <gber <at> FreeBSD.org> >> Date: Thu May 23 12:24:46 2013 +0000 >> >> Rework and organize pmap_enter_locked() function. >> >> pmap_enter_locked() implementation was very ambiguous and confusing. >> Rearrange it so that each part of the mapping creation is separated. >> Avoid walking through the redundant conditions. >> Extract vector_page specific PTE setup from normal PTE setting. >> >> Submitted by: Zbigniew Bodek <zbb <at> semihalf.com> >> Sponsored by: The FreeBSD Foundation, Semihalf >> >> Thanks for the testing, Roger. >> > > Have you (or anyone) done some testing under NetBSD Dom0? I guess its not > related, but I'm getting a panic when using SSH. > > I was able to compile and install the kernel, and booted fine (just needed > to adapt fstab, other than that no issues). > > I've done some tests with ping, ftp, wget, but when I tried SSH (both to > the vm and from the vm, I got a panic) > > ===== PANIC ===> xn_txeof: WARNING: response is -1! > debug1: SSH2_MSGxn_txeof: WARNING: response is -1! > _KEXINIT receivepanic: mbuf already on the free list, but we're trying to > free it again! > cpuid = 0 > KDB: enter: panic > [ thread pid 12 tid 100039 ] > Stopped at kdb_enter+0x3e: movq $0,kdb_why > db> bt > Tracing pid 12 tid 100039 td 0xfffffe0008101000 > kdb_enter() at kdb_enter+0x3e/frame 0xffffff8095021940 > vpanic() at vpanic+0x146/frame 0xffffff8095021980 > kassert_panic() at kassert_panic+0x136/frame 0xffffff80950219f0 > xn_txeof() at xn_txeof+0x99/frame 0xffffff8095021a40 > xn_intr() at xn_intr+0x59/frame 0xffffff8095021b30 > intr_event_execute_handlers() at intr_event_execute_handlers+0x90/frame > 0xffffff8095021b70 > ithread_loop() at ithread_loop+0x148/frame 0xffffff8095021bb0 > fork_exit() at fork_exit+0x84/frame 0xffffff8095021bf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xffffff8095021bf0 > --- trap 0, rip = 0, rsp = 0xffffff8095021cb0, rbp = 0 --- > db> > > == PANIC ==> > > I've tried with pvhvm_v10 first, and now with pvhvm_v17, but give me the > panic!Just to make things clear, this is when using a FreeBSD PVHVM DomU with a NetBSD Dom0 right? and the crash happens in the FreeBSD DomU? Could you try to run a FreeBSD HVM (HEAD) guest without my patches and see if it also crashes? (just to know if this is a regression introduced in my series or a bug that was already there). Roger. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/22/13 07:26, Roger Pau Monné wrote:> On 21/06/13 19:55, Miguel Clara wrote: >> Roger Pau Monné <roger.pau <at> citrix.com> writes: >> >>> >>> Hello, >>> >>> I've pushed a new branch, pvhvm_v10 that contains a PV IPI >>> implementation for both amd64 and i386. I've also updated the >>> wiki to point to the pvhvm_v10 branch: >>> >>> http://xenbits.xen.org/gitweb/?p=people/royger/ >> freebsd.git;a=shortlog;h=refs/heads/pvhvm_v10 >>> >>> I've updated my tree to latest HEAD, so now branch pvhvm_v10 is >>> on top of this commit: >>> >>> commit b44da0fb82647f2cfb06f65a6695c7e36c98828c Author: gber >>> <gber <at> FreeBSD.org> Date: Thu May 23 12:24:46 2013 +0000 >>> >>> Rework and organize pmap_enter_locked() function. >>> >>> pmap_enter_locked() implementation was very ambiguous and >>> confusing. Rearrange it so that each part of the mapping >>> creation is separated. Avoid walking through the redundant >>> conditions. Extract vector_page specific PTE setup from normal >>> PTE setting. >>> >>> Submitted by: Zbigniew Bodek <zbb <at> semihalf.com> >>> Sponsored by: The FreeBSD Foundation, Semihalf >>> >>> Thanks for the testing, Roger. >>> >> >> Have you (or anyone) done some testing under NetBSD Dom0? I guess >> its not related, but I'm getting a panic when using SSH. >> >> I was able to compile and install the kernel, and booted fine >> (just needed to adapt fstab, other than that no issues). >> >> I've done some tests with ping, ftp, wget, but when I tried SSH >> (both to the vm and from the vm, I got a panic) >> >> ===== PANIC ==== xn_txeof: WARNING: response is -1! debug1: >> SSH2_MSGxn_txeof: WARNING: response is -1! _KEXINIT receivepanic: >> mbuf already on the free list, but we're trying to free it >> again! cpuid = 0 KDB: enter: panic [ thread pid 12 tid 100039 ] >> Stopped at kdb_enter+0x3e: movq $0,kdb_why db> bt Tracing >> pid 12 tid 100039 td 0xfffffe0008101000 kdb_enter() at >> kdb_enter+0x3e/frame 0xffffff8095021940 vpanic() at >> vpanic+0x146/frame 0xffffff8095021980 kassert_panic() at >> kassert_panic+0x136/frame 0xffffff80950219f0 xn_txeof() at >> xn_txeof+0x99/frame 0xffffff8095021a40 xn_intr() at >> xn_intr+0x59/frame 0xffffff8095021b30 >> intr_event_execute_handlers() at >> intr_event_execute_handlers+0x90/frame 0xffffff8095021b70 >> ithread_loop() at ithread_loop+0x148/frame 0xffffff8095021bb0 >> fork_exit() at fork_exit+0x84/frame 0xffffff8095021bf0 >> fork_trampoline() at fork_trampoline+0xe/frame >> 0xffffff8095021bf0 --- trap 0, rip = 0, rsp = 0xffffff8095021cb0, >> rbp = 0 --- db> >> >> == PANIC ==>> >> >> I've tried with pvhvm_v10 first, and now with pvhvm_v17, but give >> me the panic! > > Just to make things clear, this is when using a FreeBSD PVHVM DomU > with a NetBSD Dom0 right? and the crash happens in the FreeBSD > DomU? > > Could you try to run a FreeBSD HVM (HEAD) guest without my patches > and see if it also crashes? (just to know if this is a regression > introduced in my series or a bug that was already there). > > Roger. >Yes its FreeBSD PVHVM DomU "under" NetBSD 6.1 Dom0! Do you think that the fact that this is a NetBSD dom0 might be related? I will try without the patches and see what I get! In the mean time I also noticed that trying to "fetch" some URL (ex: fetch https://github.com/KalleDK/plexmediaserver_port/raw/master/tarball/plexmediaserver.tar.gz) give Authorization failed... I've tried a few others, same problem! So its clearly related to the network driver! I will try without you're patches has suggested and post my results! Thanks -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRxfbfAAoJEGKyFhaKt9g305UP/jxBZwGqf/EYgOiszLkWjT/t G5j6K1w3SfSmIPVuAhGV4mETk3wJr879eSF+2jQqASAdO4+UT7WiXxIAE9IwLEE0 Oc4bO9RMzLG2e4f1GarnYgJQykF8b9VpvPZ8ajJziqiC7yHa3CO+6BgQhgk6ibW6 UWvNQP7i39tfC7WjEoiGOx0WpP5967caVFJeN2DFfLCqsxF0LxIhqhDoI5oJ4N8d syjoWvhDVr7WfiK7SGWj1Ztzyu6C3fyXaJe+T5eJoxq5jVZ32xRXe2QdE+eZIUtE lvVog3rBFmh/Cu0PUl83mCWtPqWL0dNcMjJNbz/jMDP+f0XnWM1f30gu4LXRA6By g0+Xd308UBKHa0lbPDKtZqDNOCu6S6w0XIjYo9FYBJu+iVAOBOGGmbIxkZxK4VKK B3BkcN7Shcj7SrFix37IjuBsbJcXZsl9onwrTGUE1gdteTroqWwlV/3v7wicvKGO 7bH5GawGDawSXjs+ke7+ULu4tPrFEYDOC2jg4Joz7wBqCdYwhlfwI+5F02IQvKQh CXgYjBB53szZ6ewbF0dyNnEqd0FBLRvnBCRTuigNvYuq+2Cd2DhxqDjMDkxiUXFR pO1wqWctZeR/vA6dRWAXDjW+VLfxohFj34pYcvoLMFS6niSjCsPUR4O87Ic/Jh1V GpieYTfR0QLbSp0mG74j =yKeD -----END PGP SIGNATURE----- _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/22/13 19:11, Miguel Clara wrote:> On 06/22/13 07:26, Roger Pau Monné wrote: >> On 21/06/13 19:55, Miguel Clara wrote: >>> Roger Pau Monné <roger.pau <at> citrix.com> writes: >>> >>>> >>>> Hello, >>>> >>>> I've pushed a new branch, pvhvm_v10 that contains a PV IPI >>>> implementation for both amd64 and i386. I've also updated >>>> the wiki to point to the pvhvm_v10 branch: >>>> >>>> http://xenbits.xen.org/gitweb/?p=people/royger/ >>> freebsd.git;a=shortlog;h=refs/heads/pvhvm_v10 >>>> >>>> I've updated my tree to latest HEAD, so now branch pvhvm_v10 >>>> is on top of this commit: >>>> >>>> commit b44da0fb82647f2cfb06f65a6695c7e36c98828c Author: gber >>>> <gber <at> FreeBSD.org> Date: Thu May 23 12:24:46 2013 >>>> +0000 >>>> >>>> Rework and organize pmap_enter_locked() function. >>>> >>>> pmap_enter_locked() implementation was very ambiguous and >>>> confusing. Rearrange it so that each part of the mapping >>>> creation is separated. Avoid walking through the redundant >>>> conditions. Extract vector_page specific PTE setup from >>>> normal PTE setting. >>>> >>>> Submitted by: Zbigniew Bodek <zbb <at> semihalf.com> >>>> Sponsored by: The FreeBSD Foundation, Semihalf >>>> >>>> Thanks for the testing, Roger. >>>> >>> >>> Have you (or anyone) done some testing under NetBSD Dom0? I >>> guess its not related, but I'm getting a panic when using SSH. >>> >>> I was able to compile and install the kernel, and booted fine >>> (just needed to adapt fstab, other than that no issues). >>> >>> I've done some tests with ping, ftp, wget, but when I tried >>> SSH (both to the vm and from the vm, I got a panic) >>> >>> ===== PANIC ==== xn_txeof: WARNING: response is -1! debug1: >>> SSH2_MSGxn_txeof: WARNING: response is -1! _KEXINIT >>> receivepanic: mbuf already on the free list, but we're trying >>> to free it again! cpuid = 0 KDB: enter: panic [ thread pid 12 >>> tid 100039 ] Stopped at kdb_enter+0x3e: movq $0,kdb_why >>> db> bt Tracing pid 12 tid 100039 td 0xfffffe0008101000 >>> kdb_enter() at kdb_enter+0x3e/frame 0xffffff8095021940 vpanic() >>> at vpanic+0x146/frame 0xffffff8095021980 kassert_panic() at >>> kassert_panic+0x136/frame 0xffffff80950219f0 xn_txeof() at >>> xn_txeof+0x99/frame 0xffffff8095021a40 xn_intr() at >>> xn_intr+0x59/frame 0xffffff8095021b30 >>> intr_event_execute_handlers() at >>> intr_event_execute_handlers+0x90/frame 0xffffff8095021b70 >>> ithread_loop() at ithread_loop+0x148/frame 0xffffff8095021bb0 >>> fork_exit() at fork_exit+0x84/frame 0xffffff8095021bf0 >>> fork_trampoline() at fork_trampoline+0xe/frame >>> 0xffffff8095021bf0 --- trap 0, rip = 0, rsp >>> 0xffffff8095021cb0, rbp = 0 --- db> >>> >>> == PANIC ==>>> >>> >>> I've tried with pvhvm_v10 first, and now with pvhvm_v17, but >>> give me the panic! > >> Just to make things clear, this is when using a FreeBSD PVHVM >> DomU with a NetBSD Dom0 right? and the crash happens in the >> FreeBSD DomU? > >> Could you try to run a FreeBSD HVM (HEAD) guest without my >> patches and see if it also crashes? (just to know if this is a >> regression introduced in my series or a bug that was already >> there). > >> Roger. > > > Yes its FreeBSD PVHVM DomU "under" NetBSD 6.1 Dom0! > > Do you think that the fact that this is a NetBSD dom0 might be > related? > > > > I will try without the patches and see what I get! > > In the mean time I also noticed that trying to "fetch" some URL > (ex: fetch > https://github.com/KalleDK/plexmediaserver_port/raw/master/tarball/plexmediaserver.tar.gz) > >give Authorization failed... I've tried a few others, same problem!> > So its clearly related to the network driver! > > I will try without you're patches has suggested and post my > results! > > Thanks >Hi, I confirm that with head I have the same problem! So this is defiantly not related to the patches, should I CC this to freebsd-current? Thanks -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRxjglAAoJEGKyFhaKt9g3jr4P/i+YSpRDRMUVzxrdbsUwmNpt NSxx6PZoaReGpmLs9eu5lU+cOUEYb2k7+F+xhlMqJ2URIpyQ61DrHf+Si54eiYHb n8B3GrEi2D1CSKSi0P7MNpan7gZju9UUjgFb1Mb6Z4RFuKAU9iicDsTkk3FWUd6I zmOQUp2o99q8bIAYGHY+ND0upsi+iulsUK9Hhp9CRjGD6Y+0pMcKxhiA2Y9TwX9j 5PTe0D4IRDpyWqCvP8Dq4TNWxQ2z0d5srPMthEQRBJoXEVJ433flELT9NJx4m2KR BiX6Mwnj++b0CSTrvbRqE/chftFjdRiTxQw08sm9hJS9skAovUe2jEmTxLIe6CNH jydGR8wnjwWmKzFkVEBv1EGRRCX4yIRgIFwHigtmTu9rhMDZdOka7Qemds8m/auX ebiYUU+ZKkY+Ap1K7aBFzbmpZ2ZeDAglPUt+PeaidvJi1Hx6Ji32/ElRWQl28V1a FGr0tB8ZzZ7SWU97wao5Is4LBUpmvp6fJClH+QtuxXnR0QPBr7Xx3upkY45aS53r 27LJEaj4SGtbQ+CZpDUZoQptAfkbL5HY636zxs0qd051g5lc2NxcWmHGhdSP4fL+ tuYA26UW3rxMXTWaagQbqCrqFrr3fXEXXfMUwJMIezSB4On1gs7Pg8Hko9MU+J4W htsyKaddpnB4tZjw5sDx =4EuG -----END PGP SIGNATURE----- _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
After discussing this with a friend, it seems the problem is not new... See: http://lists.freebsd.org/pipermail/freebsd-xen/2011-May/000940.html I guess in FreeBSD 9.1 there are no problems, not in older freebsd 10 snapshots has my friend confirmed! So my guess is this is a regression! I also tried to disable rxcsum and txcsum but I get the exact same problem described above.... meaning, no panic, but also no ssh... just hangs! For now I will leave my tests pending, but I''ll be glad to keep testing once this is fixed, If any other details are needed please tell
Miguel Clara <miguelmclara <at> gmail.com> writes:> >> ===== PANIC ==== xn_txeof: WARNING: response is -1! debug1: > >> SSH2_MSGxn_txeof: WARNING: response is -1! _KEXINIT receivepanic: > >> mbuf already on the free list, but we''re trying to free it > >> again! cpuid = 0 KDB: enter: panic [ thread pid 12 tid 100039 ] > >> Stopped at kdb_enter+0x3e: movq $0,kdb_why db> bt Tracing > >> pid 12 tid 100039 td 0xfffffe0008101000 kdb_enter() at > >> kdb_enter+0x3e/frame 0xffffff8095021940 vpanic() at > >> vpanic+0x146/frame 0xffffff8095021980 kassert_panic() at > >> kassert_panic+0x136/frame 0xffffff80950219f0 xn_txeof() at > >> xn_txeof+0x99/frame 0xffffff8095021a40 xn_intr() at > >> xn_intr+0x59/frame 0xffffff8095021b30 > >> intr_event_execute_handlers() at > >> intr_event_execute_handlers+0x90/frame 0xffffff8095021b70 > >> ithread_loop() at ithread_loop+0x148/frame 0xffffff8095021bb0 > >> fork_exit() at fork_exit+0x84/frame 0xffffff8095021bf0 > >> fork_trampoline() at fork_trampoline+0xe/frame > >> 0xffffff8095021bf0 --- trap 0, rip = 0, rsp = 0xffffff8095021cb0, > >> rbp = 0 --- db> > >> > >> == PANIC ==This issue seems to persist in 10-curent, and beta-1, I guess it was never fixed...? I was testing with 10-current and Beta-1 and still have the issue, also in these version XENPV support is enabled by default in GENERIC, so one has to recompile to work at least just in HVM without PV. Seems to be a bad idea to me if things are still not 100% stable, but that''s a subject for another list! Thanks
On 24/06/13 23:06, Miguel Clara wrote:> After discussing this with a friend, it seems the problem is not new... > > See: http://lists.freebsd.org/pipermail/freebsd-xen/2011-May/000940.html > > > I guess in FreeBSD 9.1 there are no problems, not in older freebsd 10 > snapshots has my friend confirmed!Could you bisect the FreeBSD tree to see which change (re-)introduced this issue? There haven''t been many changes to netfront, so it''s not going to take much time.> > So my guess is this is a regression! > > I also tried to disable rxcsum and txcsum but I get the exact same problem > described above.... meaning, no panic, but also no ssh... just hangs! > > For now I will leave my tests pending, but I''ll be glad to keep testing once > this is fixed, If any other details are needed please tell.Also, could you please fill a PR with the details of the issue, so we don''t forget about it. I will try to give it a look as soon as possible, I just need to reproduce the environment.
On 10/18/13 10:06, Roger Pau Monné wrote:> On 24/06/13 23:06, Miguel Clara wrote: >> After discussing this with a friend, it seems the problem is not new... >> >> See: http://lists.freebsd.org/pipermail/freebsd-xen/2011-May/000940.html >> >> >> I guess in FreeBSD 9.1 there are no problems, not in older freebsd 10 >> snapshots has my friend confirmed! > > Could you bisect the FreeBSD tree to see which change (re-)introduced > this issue? There haven''t been many changes to netfront, so it''s not > going to take much time. >http://lists.freebsd.org/pipermail/freebsd-xen/2011-September/001044.html This contains the patch which fixed it back with freebsd 8/9... maybe it helps? But I can also try to test different revisions.>> >> So my guess is this is a regression! >> >> I also tried to disable rxcsum and txcsum but I get the exact same problem >> described above.... meaning, no panic, but also no ssh... just hangs! >> >> For now I will leave my tests pending, but I''ll be glad to keep testing once >> this is fixed, If any other details are needed please tell. > > Also, could you please fill a PR with the details of the issue, so we > don''t forget about it. I will try to give it a look as soon as possible, > I just need to reproduce the environment.pThe PR exists already, reported by Hugo Silva here: http://www.freebsd.org/cgi/query-pr.cgi?pr=143340>-- Melhores Cumprimentos // Best Regards ------------------------------------------------------------------------ Miguel Clara *nix Sys Admin Freelance
On 10/18/13 14:32, Mike C. wrote:> > > On 10/18/13 10:06, Roger Pau Monné wrote: >> On 24/06/13 23:06, Miguel Clara wrote: >>> After discussing this with a friend, it seems the problem is not new... >>> >>> See: http://lists.freebsd.org/pipermail/freebsd-xen/2011-May/000940.html >>> >>> >>> I guess in FreeBSD 9.1 there are no problems, not in older freebsd 10 >>> snapshots has my friend confirmed! >> >> Could you bisect the FreeBSD tree to see which change (re-)introduced >> this issue? There haven''t been many changes to netfront, so it''s not >> going to take much time. >> > > http://lists.freebsd.org/pipermail/freebsd-xen/2011-September/001044.html > > This contains the patch which fixed it back with freebsd 8/9... maybe it > helps? > > But I can also try to test different revisions. > > >>> >>> So my guess is this is a regression! >>> >>> I also tried to disable rxcsum and txcsum but I get the exact same problem >>> described above.... meaning, no panic, but also no ssh... just hangs! >>> >>> For now I will leave my tests pending, but I''ll be glad to keep testing once >>> this is fixed, If any other details are needed please tell. >> >> Also, could you please fill a PR with the details of the issue, so we >> don''t forget about it. I will try to give it a look as soon as possible, >> I just need to reproduce the environment.p > > The PR exists already, reported by Hugo Silva here: > http://www.freebsd.org/cgi/query-pr.cgi?pr=143340 >and the new PRs: http://www.freebsd.org/cgi/query-pr.cgi?pr=182904 http://www.freebsd.org/cgi/query-pr.cgi?pr=182903>> >-- Melhores Cumprimentos // Best Regards ------------------------------------------------------------------------ Miguel Clara *nix Sys Admin Freelance http://www.linkedin.com/in/miguelmclara/ Mike_C_PT <https://twitter.com/Mike_C_PT> http://about.me/miguelmclara ------------------------------------------------------------------------
On 18/10/13 15:32, Mike C. wrote:> > > On 10/18/13 10:06, Roger Pau Monné wrote: >> On 24/06/13 23:06, Miguel Clara wrote: >>> After discussing this with a friend, it seems the problem is not new... >>> >>> See: http://lists.freebsd.org/pipermail/freebsd-xen/2011-May/000940.html >>> >>> >>> I guess in FreeBSD 9.1 there are no problems, not in older freebsd 10 >>> snapshots has my friend confirmed! >> >> Could you bisect the FreeBSD tree to see which change (re-)introduced >> this issue? There haven''t been many changes to netfront, so it''s not >> going to take much time. >> > > http://lists.freebsd.org/pipermail/freebsd-xen/2011-September/001044.html > > This contains the patch which fixed it back with freebsd 8/9... maybe it > helps? > > But I can also try to test different revisions.I''m not sure this is the same problem, this was on a Solaris Dom0 (and was supposedly fixed). It would be quite helpful to know the exact commit that (re)introduced this issue.
On 10/18/13 15:42, Roger Pau Monné wrote:> On 18/10/13 15:32, Mike C. wrote: >> >> >> On 10/18/13 10:06, Roger Pau Monné wrote: >>> On 24/06/13 23:06, Miguel Clara wrote: >>>> After discussing this with a friend, it seems the problem is not new... >>>> >>>> See: http://lists.freebsd.org/pipermail/freebsd-xen/2011-May/000940.html >>>> >>>> >>>> I guess in FreeBSD 9.1 there are no problems, not in older freebsd 10 >>>> snapshots has my friend confirmed! >>> >>> Could you bisect the FreeBSD tree to see which change (re-)introduced >>> this issue? There haven''t been many changes to netfront, so it''s not >>> going to take much time. >>> >> >> http://lists.freebsd.org/pipermail/freebsd-xen/2011-September/001044.html >> >> This contains the patch which fixed it back with freebsd 8/9... maybe it >> helps? >> >> But I can also try to test different revisions. > > I''m not sure this is the same problem, this was on a Solaris Dom0 (and > was supposedly fixed). It would be quite helpful to know the exact > commit that (re)introduced this issue. >Solaris? no... it was on NetBSD too... I''m testing different revisions I think this http://svnweb.freebsd.org/base?view=revision&revision=251297 is the one that reintroduced it, still need to compile it to make sure... on it now :) -- Melhores Cumprimentos // Best Regards ------------------------------------------------------------------------ Miguel Clara *nix Sys Admin Freelance