insmod error

[Aiace Aquila]

I've a g400 marvel on k6-iii machine, with Linux SUSE 9.2 (kernel 2.6.8).
I compiled modules (version 2.6.9 'couse I didn't find 2.6.8) but when I try
"insmod mga_vid.o" the system tell me :

"insmod: error inserting 'mga_vid.o': -1 Invalid module format"

What can I do?

Thank you for any advice

[Attila Kinali]

On Mon, 07 Mar 2005 00:16:48 +0000

Post by Aiace Aquila
"insmod: error inserting 'mga_vid.o': -1 Invalid module format"
What can I do?

use the right file: mga_vid.ko

Or just type `make install` as root.

Attila Kinali

[Aiace Aquila]

Subject: Re: [MPlayer-matrox] insmod error
Date: Mon, 7 Mar 2005 08:54:14 +0100
On Mon, 07 Mar 2005 00:16:48 +0000

Post by Aiace Aquila
"insmod: error inserting 'mga_vid.o': -1 Invalid module format"
What can I do?

use the right file: mga_vid.ko
Or just type `make install` as root.
Attila Kinali
--
郷に入れば郷に埓え
_______________________________________________
MPlayer-matrox mailing list
http://mplayerhq.hu/mailman/listinfo/mplayer-matrox

[Aiace Aquila]

thank you, but something goes wrong yet:
" # insmod mga_vid.ko
Segmentation fault "

And now?

Subject: Re: [MPlayer-matrox] insmod error
Date: Mon, 7 Mar 2005 08:54:14 +0100
On Mon, 07 Mar 2005 00:16:48 +0000

Post by Aiace Aquila
"insmod: error inserting 'mga_vid.o': -1 Invalid module format"
What can I do?

use the right file: mga_vid.ko
Or just type `make install` as root.
Attila Kinali
--
郷に入れば郷に埓え
_______________________________________________
MPlayer-matrox mailing list
http://mplayerhq.hu/mailman/listinfo/mplayer-matrox

[Attila Kinali]

On Mon, 07 Mar 2005 17:25:08 +0000

Post by Aiace Aquila
" # insmod mga_vid.ko
Segmentation fault "
And now?

1) learn how to debug this stuff an give usable
bugreports. http://www.catb.org/~esr/faqs/smart-questions.html
might be a good starting point.

2) learn how to quote: http://www.river.com/users/share/etiquette/edit.html


Attila Kinali

PS: ofcourse insmod mga_vid.ko works here

[Aiace Aquila]

I'm very happy for you that insmod mga_vid.ko works there, here, no!
Also I thank you for your useful advices, I read them both, so please
forgive my barbaric use of computer. As it written in there, I looked for
help with google, but for my problem I found only answers in asitic
language: please forgive me but really I haven't too much time to learn
chinese.
Sorry, but I can't learn "C" and "ASM" language to correct bugs source
myself: I'd really like it but I really have no time.
I looked into old mplayer threads and only one man had my problem, but no
one answer !
I'm new into Linux world and I feel myself very stupid so I looked again
here :

http://www.mplayerhq.hu/DOCS/HTML/it/video.html#mga_vid

where you can read to use the command "insmod mga_vid.o" and not "insmod
mga_vid.ko":
I'm too much stupid to understand? I'm to much new in linux? Is the
documentation wrong?

I'm very happy if you help me, because I need mplayer for my work, but my
work isn't make mplayer program.

Now, if you don't know how to help me (or you don't want to ) please say it
and don't send me to read any long "netetiquette" or as long as inuseful
"how to..."

Gretings
Aiace.

PS Before nettetiquette some peaple should read the old good "galateo"

Post by Attila Kinali
1) learn how to debug this stuff an give usable
bugreports. http://www.catb.org/~esr/faqs/smart-questions.html
might be a good starting point.
2) learn how to quote: http://www.river.com/users/share/etiquette/edit.html
Attila Kinali
PS: ofcourse insmod mga_vid.ko works here

[Attila Kinali]

On Tue, 08 Mar 2005 17:32:37 +0000

Post by Aiace Aquila
where you can read to use the command "insmod mga_vid.o" and not "insmod
I'm too much stupid to understand? I'm to much new in linux? Is the
documentation wrong?

No, you just did not give any usefull information.

1) did you see something suspicious in dmesg ?
2) can you load other modules ?
3) did you contact suse ?

The problem here is not mga_vid.

Post by Aiace Aquila
I'm very happy if you help me, because I need mplayer for my work, but my
work isn't make mplayer program.

Then you should learn that YOU are asking for something.
Thus YOU have to be polite.
Beside: if you want to have your problem fixed, you can
always pay me to do it.

Post by Aiace Aquila
Now, if you don't know how to help me (or you don't want to ) please say it
and don't send me to read any long "netetiquette" or as long as inuseful
"how to..."

Get a book about linux and how it works on the lower levels.
Ie how the kernel interacts with userspace.

Post by Aiace Aquila
PS Before nettetiquette some peaple should read the old good "galateo"

Sorry, my italian is not good enough for that.

Attila Kinali

[Attila Kinali]

On Tue, 08 Mar 2005 19:46:13 +0100

The kernel 2.6 port isn't officially supported by the mplayer team
(yet). A few people actually care enough about this thing to work on it
and support it.

Well it is somewhat official. It's just that i am not sure
what to do in future. I'd like to get mga_vid into the
kernel, but that needs a lot of clean up and i dont have
currently the time for it. (Note that my 1st priority
DMA code is also still missing).
In the mean time i'd like to get the code into the
cvs, but we have the nice problem that the kernel
changes it API like people their underwear. To provide
backwards compatibility for older kernel versions
(2 or 3 minors back) is a must which cannot be easily
done with cvs, that's why i develop it in my own
svn repo and put snapshots up.

Since this port isn't something "mplayer official" it
also means the documentation on using mga_vid with new kernels, and
especially the translations is useless for you. What you're looking at
are instructions for 2.4 kernels.

If someone has the mood and the time to review the documentation,
feel free to send either me, -matrox or -docs a patch. I'll
look that it gets into cvs.

BTW, mga_vid works like a charm here and has been working like a charm
since 2.6.0-test1. Since 2.6.9 a couple of changes were needed to get
things to build, but nothing major, and it shouldn't prevent things from
working...on a kernel.org kernel that is, who knows what SuSE does with
Replace your distro kernel with one from kernel.org and try with that.
If that doesn't work either then you *might* have hit a bug in mga_vid
(somehow). Else you have to look at the kernel SuSE provides, not us.

I'd rather say insmod is broken.


Attila Kinali

[Ferdinand O. Tempel]

Post by Attila Kinali
Well it is somewhat official. It's just that i am not sure
what to do in future. I'd like to get mga_vid into the
kernel, but that needs a lot of clean up and i dont have
currently the time for it. (Note that my 1st priority
DMA code is also still missing).

I've had a look at your version of the driver, and it looks clean and
compact to me. I can't test the actual driver right now as I don't have
my matrox card handy (I'm at a vacation address). To have this included
in the kernel (though I honestly doubt the kernel devs will accept such
an ugly hack :-) I think a few things need to be done:

- Documentation/CodingStyle
- SysFS support needs to be put back in
- udev support
- Makefile
- Kernel configuration

All of which aren't too hard to do. The first item is just cosmetic, but
to get anything included into the kernel it's very important. I'm not a
great C coder, but isn't a lot of the stuff which now is in mga_vid.c
supposed to reside in the mga_vid.h file? I mean the definitions,
macros, and all that...In other words, a good cosmetic cleanup of the
code and comments (comment blocks should be enclosed by /* ... */, for
instance) would be welcome.

The second item was already there in a crude form, but you seem to have
removed it (even though it worked fine). I noticed most (if not all) the
#ifdef's and such have disappeared, which is a good thing. That's
probably why sysfs also got axed. Though not a great priority (nor do I
think it's actually a requirement for drivers), sysfs can be used to
provide information about the hardware. udev has about the same status,
I don't think it's a requirement for drivers (yet), but still it would
be nice to have it included.

The last two items are more "kernel integration" work. I.e. stuff which
will make the driver be part of the kernel.

I'd be willing to pick some of this stuff as they're likely small
changes and not too specific to the hardware (which I really know
nothing about...). Thoughts?

Post by Attila Kinali
In the mean time i'd like to get the code into the
cvs, but we have the nice problem that the kernel
changes it API like people their underwear. To provide
backwards compatibility for older kernel versions
(2 or 3 minors back) is a must which cannot be easily
done with cvs, that's why i develop it in my own
svn repo and put snapshots up.

Yeah, it's quite annoying to have to follow the whims of the kernel
developers. And it doesn't get easier either, now they want to go to 4
digit kernel versioning. I wonder what they've been smoking lately. Oh
well...the choice is to keep seperate versions around, or again start
using #if's to cater to small changes. Not a very appealing solution. I
don't have any ideas on how to deal with such things. Maybe keeping it
in your SVN and then pushing the latest snapshot to mplayer CVS would be
acceptable?

Anyway, bedtime for bonzo.

Ferdinand O. Tempel

[Attila Kinali]

On Tue, 08 Mar 2005 23:45:22 +0100

Post by Ferdinand O. Tempel
I've had a look at your version of the driver, and it looks clean and
compact to me. I can't test the actual driver right now as I don't have
my matrox card handy (I'm at a vacation address). To have this included
in the kernel (though I honestly doubt the kernel devs will accept such
- Documentation/CodingStyle

That's easy.

Post by Ferdinand O. Tempel
- SysFS support needs to be put back in

AFAIK that's done over the kobjects, didn't had the time
to read all about that.

Post by Ferdinand O. Tempel
- udev support

No clue how this works. I only found docu for users, no
docu how to program for it.

Post by Ferdinand O. Tempel
- Makefile

That's easy with the new Makefile from my .11 version,
just delete all the stuff in the else clause.

Post by Ferdinand O. Tempel
- Kernel configuration

Very easy.


Missing here are:

* fix all race conditions (i know that there is at least one)
* add spinlocks around all critical sections (mostly needed
for smp machines)
* add more sanity checks

Post by Ferdinand O. Tempel
All of which aren't too hard to do. The first item is just cosmetic, but
to get anything included into the kernel it's very important. I'm not a
great C coder, but isn't a lot of the stuff which now is in mga_vid.c
supposed to reside in the mga_vid.h file? I mean the definitions,
macros, and all that...

I don't think so. Most of these defines are used only
inside mga_vid.c and do not to be known outside.
mga_vid.h is mainly a definition of the API for user space
programs.

Post by Ferdinand O. Tempel
In other words, a good cosmetic cleanup of the
code and comments (comment blocks should be enclosed by /* ... */, for
instance) would be welcome.
The second item was already there in a crude form, but you seem to have
removed it (even though it worked fine). I noticed most (if not all) the
#ifdef's and such have disappeared, which is a good thing. That's
probably why sysfs also got axed.

Hmm.. i must have overlooked that one. Otherwise it would have
stayed there.

Post by Ferdinand O. Tempel
Though not a great priority (nor do I
think it's actually a requirement for drivers), sysfs can be used to
provide information about the hardware. udev has about the same status,
I don't think it's a requirement for drivers (yet), but still it would
be nice to have it included.

SysFS has to be done for inclusion as currently some configurations
are done over the read/write interface of the driver, which isnt
exactly nice.

Post by Ferdinand O. Tempel
The last two items are more "kernel integration" work. I.e. stuff which
will make the driver be part of the kernel.
I'd be willing to pick some of this stuff as they're likely small
changes and not too specific to the hardware (which I really know
nothing about...). Thoughts?

Go on! I'll gladly accept all patches that are clean and do what
they are supposed to do. For an idea how a good patch should look
like please read http://www.mplayerhq.hu/DOCS/tech/patches.txt.
In contradiction to that file, i'll accept cosmetic changes,
but if and only if they are separated from functional changes.

Post by Ferdinand O. Tempel
Yeah, it's quite annoying to have to follow the whims of the kernel
developers. And it doesn't get easier either, now they want to go to 4
digit kernel versioning. I wonder what they've been smoking lately. Oh
well...the choice is to keep seperate versions around, or again start
using #if's to cater to small changes.

Nope, i'm not going to add #if's for older kernel versions.
That just makes the code unmaintainable after some time.

Post by Ferdinand O. Tempel
Not a very appealing solution. I
don't have any ideas on how to deal with such things. Maybe keeping it
in your SVN and then pushing the latest snapshot to mplayer CVS would be
acceptable?

Not really. Currently CVS is kept there for the 2.[024] users.
Ok, that code could be tarred and put somewhere as i consider it
"stable" (though it isn't). Alternatively i can put up an svn/darcs
server somewhere public and move mga_vid development there.
But i really don't know what would be best.

Attila Kinali

[Ferdinand O. Tempel]

Post by Attila Kinali

Post by Ferdinand O. Tempel
- udev support

No clue how this works. I only found docu for users, no
docu how to program for it.

Welp, after a short research session it seems that adding SysFS back in
is half the battle for getting udev running too, as udev uses the
information in sysfs (and hotplug events where appropriate) to construct
its device nodes. That's probably why you couldn't find much about it,
all the magic lies in correct information in sysfs and a little program
(udev) to interpret it.

Post by Attila Kinali
* fix all race conditions (i know that there is at least one)
* add spinlocks around all critical sections (mostly needed
for smp machines)
* add more sanity checks

Scary advanced stuff. I'll leave that to a real developer :P

Post by Attila Kinali

Post by Ferdinand O. Tempel
All of which aren't too hard to do. The first item is just cosmetic, but
to get anything included into the kernel it's very important. I'm not a
great C coder, but isn't a lot of the stuff which now is in mga_vid.c
supposed to reside in the mga_vid.h file? I mean the definitions,
macros, and all that...

I don't think so. Most of these defines are used only
inside mga_vid.c and do not to be known outside.
mga_vid.h is mainly a definition of the API for user space
programs.

Makes sense.

Post by Attila Kinali
SysFS has to be done for inclusion as currently some configurations
are done over the read/write interface of the driver, which isnt
exactly nice.

Okay, so SysFS done properly has a bit of priority as it allows for
other stuff to happen too. Maybe it's as easy as adding back the sysfs
support which was already there, but maybe that's too simple. I won't be
able to play with this for two weeks (lacking the hardware, currently),
but since I was meaning to look at udev anyway, this seems like a good
excuse to actually do so.

Post by Attila Kinali
Go on! I'll gladly accept all patches that are clean and do what
they are supposed to do. For an idea how a good patch should look
like please read http://www.mplayerhq.hu/DOCS/tech/patches.txt.
In contradiction to that file, i'll accept cosmetic changes,
but if and only if they are separated from functional changes.

Yeah, I agree. I think it would be best to concentrate on function over
form right now, and clean up later. I'll try to follow the rules :-)

Post by Attila Kinali

Post by Ferdinand O. Tempel
well...the choice is to keep seperate versions around, or again start
using #if's to cater to small changes.

Nope, i'm not going to add #if's for older kernel versions.
That just makes the code unmaintainable after some time.

Bah, annoying. This is one of the cases where de decisions made by
kernel developers make it harder for people to maintain out-of-tree
drivers. Even opensource ones. I wonder if they actually realized that.

Post by Attila Kinali
Ok, that code could be tarred and put somewhere as i consider it
"stable" (though it isn't). Alternatively i can put up an svn/darcs
server somewhere public and move mga_vid development there.
But i really don't know what would be best.

I'll just send patches I have to here and let you handle the details.
Seems the easiest for now.

Ferdinand O. Tempel

[Attila Kinali]

On Wed, 09 Mar 2005 23:52:18 +0100

Post by Ferdinand O. Tempel
Welp, after a short research session it seems that adding SysFS back in
is half the battle for getting udev running too, as udev uses the
information in sysfs (and hotplug events where appropriate) to construct
its device nodes. That's probably why you couldn't find much about it,
all the magic lies in correct information in sysfs and a little program
(udev) to interpret it.

That would explain it. I'll look into that after my exams.

Post by Ferdinand O. Tempel

Post by Attila Kinali
* fix all race conditions (i know that there is at least one)
* add spinlocks around all critical sections (mostly needed
for smp machines)
* add more sanity checks

Scary advanced stuff. I'll leave that to a real developer :P

:)
Don't be scared, these are just a few rules you have to keep
in mind, nothing difficult.

Post by Ferdinand O. Tempel
Okay, so SysFS done properly has a bit of priority as it allows for
other stuff to happen too. Maybe it's as easy as adding back the sysfs
support which was already there, but maybe that's too simple. I won't be
able to play with this for two weeks (lacking the hardware, currently),
but since I was meaning to look at udev anyway, this seems like a good
excuse to actually do so.

I'd appreciate if you could do so.

Post by Ferdinand O. Tempel

Post by Attila Kinali

Post by Ferdinand O. Tempel
well...the choice is to keep seperate versions around, or again start
using #if's to cater to small changes.

Nope, i'm not going to add #if's for older kernel versions.
That just makes the code unmaintainable after some time.

Bah, annoying. This is one of the cases where de decisions made by
kernel developers make it harder for people to maintain out-of-tree
drivers. Even opensource ones. I wonder if they actually realized that.

Yes, they know it very well, but a fast development of the
kernel has for them first priority. And somewhat i have to
agree. For me it makes it just harder to keep up with it,
though Jonathan Corbet does a good job with listing the changes:
http://lwn.net/Articles/2.6-kernel-api/


Attila Kinali

[Ferdinand O. Tempel]

Post by Aiace Aquila
I looked into old mplayer threads and only one man had my problem, but no
one answer !

That's easy, it usually means noone knows or cares.

Post by Aiace Aquila
where you can read to use the command "insmod mga_vid.o" and not "insmod
I'm too much stupid to understand? I'm to much new in linux? Is the
documentation wrong?

The kernel 2.6 port isn't officially supported by the mplayer team
(yet). A few people actually care enough about this thing to work on it
and support it. Since this port isn't something "mplayer official" it
also means the documentation on using mga_vid with new kernels, and
especially the translations is useless for you. What you're looking at
are instructions for 2.4 kernels. What you *should* be doing is properly
install the module (make install helps), run depmod -ae, and then use
*modprobe* to load the module (modprobe mga_vid), not insmod. Not that
the result will differ much from using the insmod method, but at least
you're then using the proper method to load modules.

Oh, and you should be watching your syslog carefully for signs of
indecent behaviour.

Post by Aiace Aquila
I'm very happy if you help me, because I need mplayer for my work, but my
work isn't make mplayer program.

Hmm, convince $work to sponsor the mplayer project? :-)

Post by Aiace Aquila
Now, if you don't know how to help me (or you don't want to ) please say it
and don't send me to read any long "netetiquette" or as long as inuseful
"how to..."

It's hard to help if the problem description isn't very clear. That's
why you were referenced to ESR's faq on how to ask questions.
Admittedly, it's not easy to write proper bug reports. Bickering back
and forth doesn't help either though, so swallow the ego, stop
complaining and start working on getting your problem solved.

BTW, mga_vid works like a charm here and has been working like a charm
since 2.6.0-test1. Since 2.6.9 a couple of changes were needed to get
things to build, but nothing major, and it shouldn't prevent things from
working...on a kernel.org kernel that is, who knows what SuSE does with
its distribution kernels. I think that's the first thing I'd try:
Replace your distro kernel with one from kernel.org and try with that.
If that doesn't work either then you *might* have hit a bug in mga_vid
(somehow). Else you have to look at the kernel SuSE provides, not us.

Regards,

Ferdinand O. Tempel