Date: Fri, 27 Aug 2004 08:00:47 +0100 From: Mark Murray <mark@grondar.org> To: obrien@FreeBSD.ORG Cc: cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/dev/acpica acpi.c acpi_resource.c acpivar.h Message-ID: <200408270700.i7R70lDZ039371@grimreaper.grondar.org> In-Reply-To: Your message of "Thu, 26 Aug 2004 11:06:21 PDT." <20040826180621.GA16885@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"David O'Brien" writes: > > > You know I would also, and many others on freebsd-amd64. > > > The point is "asking". :-) > > > > Cool. I've made some changes to the random, mem and io modules to > > try to prevent the double-loaded module panic. Could you please see > > if this works for amd64? > > quynh# kldload /boot/kernel/random.ko > kldload: can't load /boot/kernel/random.ko: Exec format error > quynh# kldload /boot/kernel/mem.ko > kldload: can't load /boot/kernel/mem.ko: Exec format error > quynh# kldload /boot/kernel/io.ko > kldload: can't load /boot/kernel/io.ko: Exec format error > quynh# kldload /boot/kernel/if_xl.ko > quynh# > > the error message is a little weird (and deceiving) when one of these > .ko's doesn't load; but this is orders of orders of magnitude better than > panicing. 8-) Yeah. Just to confirm, all three of the above modules were built into the kernel, right? The solution was to add a module version to the modules. Why not having a version is not an error beats me. (I wonder if it is possible to make this the case?) > thanks for fixing this! No problem. But the real fix IMO is to not allow the broken modules to be made in the first place. It was pure, blind luck that enabled me to stumble onto this solution. :-) M -- Mark Murray iumop ap!sdn w,I idlaH
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200408270700.i7R70lDZ039371>