This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Error removing module: Device or resource busy
On Wed, Jan 25, 2012 at 05:34:01PM -0800, Josh Stone wrote:
> On 01/25/2012 04:29 PM, Chris Dunlop wrote:
> >> Could you save/compare the same script compiled on one machine
> >> vs. the other, so we can try to figure out what makes the two
> >> gcc versions incompatible in this way?
> >
> > See below. Nothing too interesting in the text differences to my gcc-illiterate eye.
> [...]
> > +-DCC_HAVE_ASM_GOTO
>
> This is it. With that defined, jump_label.h defines HAVE_JUMP_LABEL,
> which enables this part of struct module in module.h:
>
> #ifdef HAVE_JUMP_LABEL
> struct jump_entry *jump_entries;
> unsigned int num_jump_entries;
> #endif
>
> Compiling with/without that means everything after is shifted, including
> the CONFIG_MODULE_UNLOAD stuff. You can also compare this with the dump
> given by dwarves pahole.
>
> It would probably work to just turn off CONFIG_JUMP_LABEL altogether, so
> it's not attempted on either compiler. I'd be worried about other
> hidden incompatibilities cropping up though. I don't see any other
> struct differences with pahole except jump_label stuff, but that doesn't
> comfort me much.
I'm currently playing with enough newness, I don't think I'm
quite ready for possible "hidden incompatibilities" at this
point!
> So the easiest thing would be for you to compile the kernel with the
> target system's own compiler, so everything matches. :)
Where's the fun in that?? :-)
> If you keep the mismatch, we do have a couple of options to make it
> easier to compile stap modules on one and run on the other. One is the
> --use-server mode, where stap running on the target will query a network
> service running on the compile machine to build for it. The other is
> the --remote mode, where stap running on the compile machine will build
> the module locally, then send it over ssh to run on the target and
> collect the output.
I'm currently using "stap -p4" and a manual scp to the remote
host, so --remote would be perfect, except I get:
$ stap --remote debhost -m stap_test -r ~/git/linux-build/${kv} -e 'probe begin {printf("foo\n"); exit()}'
WARNING: kernel release/architecture mismatch with host forces last-pass 4.
stap_test.ko
...and it stops at pass 4 as warned.