[parisc-linux] strange message with insmod

[parisc-linux] strange message with insmod

[Bruno Vidal]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

	Hi
I've compiled a new kernel (without LVM), everything seems okay.
My dump driver compiled right...but when I use insmod:
hpfrcw12:~# insmod dump
Using /lib/modules/2.4.18-pa35/kernel/drivers/dump/dump.o
r_info 0x29 not handled
r_info 0x29 not handled
r_info 0x29 not handled
r_info 0x29 not handled
r_info 0x29 not handled
r_info 0x29 not handled
r_info 0x29 not handled
r_info 0x29 not handled
hpfrcw12:~# insmod st
Using /lib/modules/2.4.18-pa35/kernel/drivers/scsi/st.o
r_info 0x29 not handled
r_info 0x29 not handled
r_info 0x29 not handled
r_info 0x29 not handled 

So it is not coming from my modules. The modules are loaded,
everything seems okay, but what means this messages ?

	Thanks.

-- 
	Vidal Bruno, (770-4271)
        SSD-HA Team, HP-UX & LINUX Support
	bruno_vidal@admin.france.hp.com

[-- Attachment #2: Card for Bruno Vidal --]
[-- Type: text/x-vcard, Size: 386 bytes --]

begin:vcard 
n:Bruno;VIDAL
tel;fax:01-69-82-60-14
tel;work:01-69-29-42-71
x-mozilla-html:TRUE
url:www.france.hp.com
org:Solution Center
version:2.1
email;internet:bruno_vidal@hp.com
title:Expert Logiciel Environnement Haute Disponibilité
adr;quoted-printable:;;HP France=0D=0A;Z.A de Courtaboeuf;1 Av. du Canada;91947 Les Ulis cedex;France
x-mozilla-cpt:;26208
fn:VIDAL Bruno
end:vcard

Re: [parisc-linux] strange message with insmod

[Richard Hirst]

On Thu, Jun 06, 2002 at 04:33:59PM +0200, Bruno Vidal wrote:
> 	Hi
> I've compiled a new kernel (without LVM), everything seems okay.
> My dump driver compiled right...but when I use insmod:
> hpfrcw12:~# insmod dump
> Using /lib/modules/2.4.18-pa35/kernel/drivers/dump/dump.o
> r_info 0x29 not handled
> ...
> So it is not coming from my modules. The modules are loaded,
> everything seems okay, but what means this messages ?

Some relocation type used in your .o files that modutils doesn't know
how to handle.  Generally modutils only handles the relocation types
that I have seen in modules to date.  New types might crop up as a
result of tool chain changes, or different compiler options, or possibly
kernel code changes might cause the toolchain to generate some other
relocation.

Are you using the standard woody toolchain for hppa?  Can you send me
off list your scsi/st.o, incase I can't reproduce here?

Everything might seem ok, but it could be some code paths or data
accesses wont be handled properly.

Thanks,
  Richard

Re: [parisc-linux] strange message with insmod

[joel.soete]

Quoting Bruno Vidal <bruno_vidal@hpfrcu03.france.hp.com>:

> 	Hi
> I've compiled a new kernel (without LVM), everything seems okay.
> My dump driver compiled right...but when I use insmod:


Great news.

Congratulation,
Joel


-------------------------------------------------
This mail sent through Tiscali Webmail (http://webmail.tiscali.be)

Re: [parisc-linux] strange message with insmod

[Bruno Vidal]

[-- Attachment #1: Type: text/plain, Size: 1611 bytes --]

	Hi
I think I found where the problem is. In order to add debug info
for P4, I've add in the main Makefile: -gdwarf-2. I've remove this
debug option, and now everything is okay. I think that this option is
creating too much debug informations. Does someone has already try
to investiguate a solution in order to add debug information, without
creating soooo much information ?

	Thanks.

Richard Hirst wrote:
> 
> On Thu, Jun 06, 2002 at 04:33:59PM +0200, Bruno Vidal wrote:
> >       Hi
> > I've compiled a new kernel (without LVM), everything seems okay.
> > My dump driver compiled right...but when I use insmod:
> > hpfrcw12:~# insmod dump
> > Using /lib/modules/2.4.18-pa35/kernel/drivers/dump/dump.o
> > r_info 0x29 not handled
> > ...
> > So it is not coming from my modules. The modules are loaded,
> > everything seems okay, but what means this messages ?
> 
> Some relocation type used in your .o files that modutils doesn't know
> how to handle.  Generally modutils only handles the relocation types
> that I have seen in modules to date.  New types might crop up as a
> result of tool chain changes, or different compiler options, or possibly
> kernel code changes might cause the toolchain to generate some other
> relocation.
> 
> Are you using the standard woody toolchain for hppa?  Can you send me
> off list your scsi/st.o, incase I can't reproduce here?
> 
> Everything might seem ok, but it could be some code paths or data
> accesses wont be handled properly.
> 
> Thanks,
>   Richard

-- 
	Vidal Bruno, (770-4271)
        SSD-HA Team, HP-UX & LINUX Support
	bruno_vidal@admin.france.hp.com

[-- Attachment #2: Card for Bruno Vidal --]
[-- Type: text/x-vcard, Size: 386 bytes --]

begin:vcard 
n:Bruno;VIDAL
tel;fax:01-69-82-60-14
tel;work:01-69-29-42-71
x-mozilla-html:TRUE
url:www.france.hp.com
org:Solution Center
version:2.1
email;internet:bruno_vidal@hp.com
title:Expert Logiciel Environnement Haute Disponibilité
adr;quoted-printable:;;HP France=0D=0A;Z.A de Courtaboeuf;1 Av. du Canada;91947 Les Ulis cedex;France
x-mozilla-cpt:;26208
fn:VIDAL Bruno
end:vcard

Re: [parisc-linux] strange message with insmod

[Carlos O'Donell Jr.]

> 	Hi
> I think I found where the problem is. In order to add debug info
> for P4, I've add in the main Makefile: -gdwarf-2. I've remove this
> debug option, and now everything is okay. I think that this option is
> creating too much debug informations. Does someone has already try
> to investiguate a solution in order to add debug information, without
> creating soooo much information ?
> 
> 	Thanks.
>

GCC 3.2 is the only branch that has dwarf2 support for HPPA?
You'll have to live with stabs.

ATM I'm trying to find out why 3.1/3.2 produces slightly twisted
kernel net code, and subsequently causing an oops.

c. 

Re: [parisc-linux] strange message with insmod

[John David Anglin]

> GCC 3.2 is the only branch that has dwarf2 support for HPPA?
> You'll have to live with stabs.

That's not quite true.  You can generate dwarf2 debug information on
previous versions.  3.2 is the first version with working support
for eh frame information.  By working, I mean that the C++ exception
support appears to work for normal exceptions.  I don't really know
if gdb is using this information.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)