Date: Wed, 15 Jul 2009 10:22:04 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Florian Smeets <flo@kasimir.com> Cc: Luiz Otavio O Souza <lists.br@gmail.com>, current@FreeBSD.org Subject: Re: Rebuild all network-related kernel modules on 8-current due to vnet allocator change Message-ID: <alpine.BSF.2.00.0907151020590.54568@fledge.watson.org> In-Reply-To: <4A5D9C51.7070708@kasimir.com> References: <alpine.BSF.2.00.0907150016260.54568@fledge.watson.org> <05461E04E6BD4477A879553178599F6E@adnote989> <8026EC1942CE4C128F168BBBFD987B27@adnote989> <alpine.BSF.2.00.0907150958250.54568@fledge.watson.org> <4A5D9C51.7070708@kasimir.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 15 Jul 2009, Florian Smeets wrote: >>>> My kernel don't have any VIMAGE options. >>>> >>>> The system is working flawless before the upgrade. >>>> >>>> If you need any/more information about this, just let me know. >>> >>> I've just commented out the panic() in link_elf_obj.c and now i'm able to >>> create vlans again. >> >> This assertion may well be too conservative -- is there any chance you have >> a kernel built with the DTrace CTF support? It may be using progbits, in >> which case removing the assertion is the right solution. I'll test this >> hypothesis. > > i'm also seeing this panic, it happens when zfs.ko is loaded in my case. I > don't have anything DTrace CTF related in my kernel. OK. I'm not able to reproduce it here, but clearly there must be some ELF/etc case I haven't thought of or understood. I've committed a removal of the assertion, r195707 and will debug it offline, we can re-add it if I come up with a more refined/useful version. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0907151020590.54568>