The problem is the following:
I AM A NEWBIE!!!
Well i had some questions about the linux kernel compilation and some of you
gave me some real goos answeres, however, there is an issue which keeps
buzzing my head and that i can't understand!
Some one told me i should edit the loop.c file and even tried to explained me
why but i couldn't understand.
He said something about my new kernel wouldn't be able to compile if two or
three lines weren't comented!
I didn't understand this fact so i would like to know why should i edit the
/usr/src/linux/drivers/block/loop.c file!!!!
Plz some one explain me this fact.
tks for your attention, Astinus
If i wasn't explicit enough plz tell me! So i can reformulate my e-mail post!
once again tks for your attention.
* Miguel Maria Godinho de Matos ([email protected]) wrote:
> The problem is the following:
>
> I AM A NEWBIE!!!
>
> Well i had some questions about the linux kernel compilation and some of you
> gave me some real goos answeres, however, there is an issue which keeps
> buzzing my head and that i can't understand!
>
> Some one told me i should edit the loop.c file and even tried to explained me
> why but i couldn't understand.
the code in loop.c references a function deactivate_page() which was
removed from the kernel. for more details, read this thread:
http://marc.theaimsgroup.com/?t=100500866500001&w=2&r=1
cheers,
-chris
On Tue, 20 Nov 2001, Miguel Maria Godinho de Matos wrote:
> The problem is the following:
>
> Some one told me i should edit the loop.c file and even tried to explained me
> why but i couldn't understand.
>
> He said something about my new kernel wouldn't be able to compile if two or
> three lines weren't comented!
>
> I didn't understand this fact so i would like to know why should i edit the
> /usr/src/linux/drivers/block/loop.c file!!!!
What lines did he want you to comment out? Tell us more! I don't think you
would need to.
Ryan M. McConahy
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
"Ryan M. McConahy" wrote:
> On Tue, 20 Nov 2001, Miguel Maria Godinho de Matos wrote:
>
> > The problem is the following:
> >
> > Some one told me i should edit the loop.c file and even tried to explained me
> > why but i couldn't understand.
> >
> > He said something about my new kernel wouldn't be able to compile if two or
> > three lines weren't comented!
> >
> > I didn't understand this fact so i would like to know why should i edit the
> > /usr/src/linux/drivers/block/loop.c file!!!!
>
> What lines did he want you to comment out? Tell us more! I don't think you
> would need to.
He's doubtless referring to the deactivate_page()
thing that's been talked to death on this list for
the past 2 weeks...
Better solution is go to 2.4.15-pre7, which has
fixes for that and many other things as well -
Then again, it sure looks like 2.4.15-final is RSN.
cu
jjs
What version of the kernel are you trying to compile?
Miguel Maria Godinho de Matos wrote:
>
> The problem is the following:
>
> I AM A NEWBIE!!!
>
> Well i had some questions about the linux kernel compilation and some of you
> gave me some real goos answeres, however, there is an issue which keeps
> buzzing my head and that i can't understand!
>
> Some one told me i should edit the loop.c file and even tried to explained me
> why but i couldn't understand.
>
> He said something about my new kernel wouldn't be able to compile if two or
> three lines weren't comented!
>
> I didn't understand this fact so i would like to know why should i edit the
> /usr/src/linux/drivers/block/loop.c file!!!!
>
> Plz some one explain me this fact.
>
> tks for your attention, Astinus
>
> If i wasn't explicit enough plz tell me! So i can reformulate my e-mail post!
>
> once again tks for your attention.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Hi all,
Just a thought. Don't shoot the messenger/idiot that thought of it.
>He's doubtless referring to the deactivate_page()
>thing that's been talked to death on this list for
>the past 2 weeks...
I'm getting rather annoyed with the same problem being reported/asked about
over and over again...
Is there - or would it be nice it it would be here - a list of recent
compilation problems encountered with stock kernels (and what to do about
it)? (see the loop.c thingy recently, and other problems with other stock
kernels). So we could just point the people to that thing instead of having
these 'discussions' over and over again...
It could be about only the 'full' versions, or maybe the 'pre' kernels too...
Maybe it would even be possible to add keywords to the filtering procs of
the lkml, so that those persons would get a sort of -automatic- email on
the subject...
Just a thought...
DK
Richard Gooch tried this a year or two ago; it's the sort of thing which
readily goes stale.
Maybe it should just be a FAQ: "Why doesn't Linux compile?" "'Cos even the
Gods are sometimes human. Check the mailing list archives for a patch."
At 08:28 +0100 DevilKin wrote:
>>He's doubtless referring to the deactivate_page()
>Is there - or would it be nice it it would be here - a list of recent
>compilation problems encountered with stock kernels (and what to do about
>it)? (see the loop.c thingy recently, and other problems with other stock
>kernels). So we could just point the people to that thing instead of having
>these 'discussions' over and over again...
"DevilKin" <[email protected]> wrote in message
news:[email protected]...
> Hi all,
>
> Just a thought. Don't shoot the messenger/idiot that thought of it.
>
> >He's doubtless referring to the deactivate_page()
> >thing that's been talked to death on this list for
> >the past 2 weeks...
> I'm getting rather annoyed with the same problem being reported/asked
about
> over and over again...
>
> Is there - or would it be nice it it would be here - a list of recent
> compilation problems encountered with stock kernels (and what to do about
> it)? (see the loop.c thingy recently, and other problems with other stock
> kernels). So we could just point the people to that thing instead of
having
> these 'discussions' over and over again...
Good suggestion. Unfortunately, many people obviously do not take the time
to read the newsgroup before they post, so what do you propose will be the
mechanism to encourage them to lookup existing issues?
Rob
At 10:10 AM 21/11/01 +0100, Rob Turk wrote:
>Good suggestion. Unfortunately, many people obviously do not take the time
>to read the newsgroup before they post, so what do you propose will be the
>mechanism to encourage them to lookup existing issues?
Why not do it like the current Changelog, put it in the kernel repository,
and make sure it hits all the mirrors. A little selective advertising (eg:
someone mention it on slashdot, newsforge, debianplanet, etc), and people
will start using it. Just suffix the file with the version number, just
like the Changelog. Because the file will be small, it's possible that some
mirrors will get quick updates before they get the kernel itself. This
covers all the version specific problems at least.
Stuart Young - [email protected]
(aka Cefiar) - [email protected]
[All opinions expressed in the above message are my]
[own and not necessarily the views of my employer..]
"Stuart Young" <[email protected]> wrote in message
news:[email protected]...
> At 10:10 AM 21/11/01 +0100, Rob Turk wrote:
> >Good suggestion. Unfortunately, many people obviously do not take the time
> >to read the newsgroup before they post, so what do you propose will be the
> >mechanism to encourage them to lookup existing issues?
>
> Why not do it like the current Changelog, put it in the kernel repository,
> and make sure it hits all the mirrors. A little selective advertising (eg:
> someone mention it on slashdot, newsforge, debianplanet, etc), and people
> will start using it. Just suffix the file with the version number, just
> like the Changelog. Because the file will be small, it's possible that some
> mirrors will get quick updates before they get the kernel itself. This
> covers all the version specific problems at least.
>
>
> Stuart Young - [email protected]
> (aka Cefiar) - [email protected]
>
Most of the people which post without reading previous entries in the newsgroup
will also not read FRB (Frequently Reported Bugs) files. I actually got a great
suggestion in from Martin Bene. He suggests putting a last line in the build
process which always shows up if a failure occurs during kernel compiles.
Something along the lines of 'Your kernel failed to build. Check
http://www.where-ever-the-buglist-is.org for known issues with your kernel. Post your
problem on the kernel list if this is not a FRB'. Is this something that can be
done easily?
As a suggestion for such a web site, it would probably help if people who see
'their' bug present could file a description under the frb on such a web site,
to help developers figure out how many people are impacted and maybe to
correlate the circumstances.
Rob
At 08:07 AM 22/11/01 +0100, Rob Turk wrote:
>"Stuart Young" <[email protected]> wrote:
> > Why not do it like the current Changelog, put it in the kernel
> > repository, and make sure it hits all the mirrors. A little
> > selective advertising (eg: someone mention it on slashdot,
> > newsforge, debianplanet, etc), and people will start using it.
> > Just suffix the file with the version number, just like the
> > Changelog. Because the file will be small, it's possible that some
> > mirrors will get quick updates before they get the kernel itself.
> > This covers all the version specific problems at least.
>
>Most of the people which post without reading previous entries in the
>newsgroupwill also not read FRB (Frequently Reported Bugs) files. I
>actually got a greatsuggestion in from Martin Bene. He suggests putting a
>last line in the build process which always shows up if a failure occurs
>during kernel compiles.
>Something along the lines of 'Your kernel failed to build. Check
>http://www.where-ever-the-buglist-is.org for known issues with your kernel. Post
>your problem on the kernel list if this is not a FRB'. Is this something
>that can be done easily?
That's a good idea, but not mutually exclusive of what I was suggesting.
If fact, the two work quite well together, as the web reference (on failed
compile) could point to the file I'm suggesting on the kernel mirrors. And
it's hardly an issue to pull all the version info out of the kernel to
provide a version number on the end of the file.
At the bottom of the file, have ANOTHER link to a generic FAQ about
compilation problems (which covers all the major things like forgetting to
install an assembler, the broken old build stuff, 'make dep' before
compiling modules, etc). The FAQ could be on the kernel mirrors as well
(and I don't see why not, as this is all kernel related, and definitely a
resource that needs to be in more than one place).
AMC Enterprises P/L - Stuart Young
First Floor - Network and Systems Admin
3 Chesterville Rd - [email protected]
Cheltenham Vic 3192 - Ph: (03) 9584-2700
http://www.amc.com.au/ - Fax: (03) 9584-2755
On Nov 23, 2001 11:03 +1100, Stuart Young wrote:
> >Something along the lines of 'Your kernel failed to build. Check
> >http://www.where-ever-the-buglist-is.org for known issues with your kernel. Post
> >your problem on the kernel list if this is not a FRB'. Is this something
> >that can be done easily?
>
> At the bottom of the file, have ANOTHER link to a generic FAQ about
> compilation problems (which covers all the major things like forgetting to
> install an assembler, the broken old build stuff, 'make dep' before
> compiling modules, etc). The FAQ could be on the kernel mirrors as well
> (and I don't see why not, as this is all kernel related, and definitely a
> resource that needs to be in more than one place).
Yes!!!! Anything to reduce the number of repeat problems reported is
good in my books. It might also hold a pointer to Linus' (or Marcello's)
-pre patch area, with a warning that they are not for everyone.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
Andreas Dilger writes:
> On Nov 23, 2001 11:03 +1100, Stuart Young wrote:
> > >Something along the lines of 'Your kernel failed to build. Check
> > >http://www.where-ever-the-buglist-is.org for known issues with your kernel. Post
> > >your problem on the kernel list if this is not a FRB'. Is this something
> > >that can be done easily?
> >
> > At the bottom of the file, have ANOTHER link to a generic FAQ about
> > compilation problems (which covers all the major things like forgetting to
> > install an assembler, the broken old build stuff, 'make dep' before
> > compiling modules, etc). The FAQ could be on the kernel mirrors as well
> > (and I don't see why not, as this is all kernel related, and definitely a
> > resource that needs to be in more than one place).
>
> Yes!!!! Anything to reduce the number of repeat problems reported
> is good in my books. It might also hold a pointer to Linus' (or
> Marcello's) -pre patch area, with a warning that they are not for
> everyone.
Well, the FAQ is supposed to answer these questions. There's a whole
section on compile problems. Do we need another FAQ?
However, I could easily upload the FAQ to kernel.org at the same time
as I upload to tux.org, since I've already got an area there. Would
this be useful? If so, then perhaps Linus could put in a symbolic link
so that ftp.kernel.org:/pub/linux/kernel/faq.html points to:
"people/rgooch/faq.html", so that it's visible from the top level.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
Em Thu, Nov 22, 2001 at 06:16:08PM -0700, Richard Gooch escreveu:
> However, I could easily upload the FAQ to kernel.org at the same time
> as I upload to tux.org, since I've already got an area there. Would
> this be useful? If so, then perhaps Linus could put in a symbolic link
> so that ftp.kernel.org:/pub/linux/kernel/faq.html points to:
> "people/rgooch/faq.html", so that it's visible from the top level.
I think that this indeed is a very good idea.
- Arnaldo
Arnaldo Carvalho de Melo writes:
> Em Thu, Nov 22, 2001 at 06:16:08PM -0700, Richard Gooch escreveu:
> > However, I could easily upload the FAQ to kernel.org at the same time
> > as I upload to tux.org, since I've already got an area there. Would
> > this be useful? If so, then perhaps Linus could put in a symbolic link
> > so that ftp.kernel.org:/pub/linux/kernel/faq.html points to:
> > "people/rgooch/faq.html", so that it's visible from the top level.
>
> I think that this indeed is a very good idea.
So, we just need to convince Linus to put that symlink in :-)
Linus: are you happy with this idea?
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
On Nov 22, 2001 18:16 -0700, Richard Gooch wrote:
> Andreas Dilger writes:
> > On Nov 23, 2001 11:03 +1100, Stuart Young wrote:
> > > >Something along the lines of 'Your kernel failed to build. Check
> > > >http://www.where-ever-the-buglist-is.org for known issues with your kernel.
> > > >Post your problem on the kernel list if this is not a FRB'. Is this
> > > >something that can be done easily?
> > >
> > > At the bottom of the file, have ANOTHER link to a generic FAQ about
> > > compilation problems (which covers all the major things like forgetting
> > > to install an assembler, the broken old build stuff, 'make dep' before
> > > compiling modules, etc). The FAQ could be on the kernel mirrors as well
> > > (and I don't see why not, as this is all kernel related, and definitely a
> > > resource that needs to be in more than one place).
> >
> > Yes!!!! Anything to reduce the number of repeat problems reported
> > is good in my books. It might also hold a pointer to Linus' (or
> > Marcello's) -pre patch area, with a warning that they are not for
> > everyone.
>
> Well, the FAQ is supposed to answer these questions. There's a whole
> section on compile problems. Do we need another FAQ?
Well, you've seen how many times Keith points people to the FAQ on
module versions, after they post to the list first. You only see
the FAQ URL at the bottom of the emails if you have previously read
the mailing list, which most haven't.
> However, I could easily upload the FAQ to kernel.org at the same time
> as I upload to tux.org, since I've already got an area there. Would
> this be useful? If so, then perhaps Linus could put in a symbolic link
> so that ftp.kernel.org:/pub/linux/kernel/faq.html points to:
> "people/rgooch/faq.html", so that it's visible from the top level.
It would be nice if the section of compile problems could be linked to
separately, so people don't have to read the whole FAQ to read about
their specific problem. While reading the whole thing is not a bad idea,
it _is_ fairly long.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
Andreas Dilger writes:
> On Nov 22, 2001 18:16 -0700, Richard Gooch wrote:
> > Well, the FAQ is supposed to answer these questions. There's a whole
> > section on compile problems. Do we need another FAQ?
>
> Well, you've seen how many times Keith points people to the FAQ on
> module versions, after they post to the list first. You only see
> the FAQ URL at the bottom of the emails if you have previously read
> the mailing list, which most haven't.
Yeah. While the welcome message has a link to the FAQ, that doesn't
help for people who post without subscribing.
> > However, I could easily upload the FAQ to kernel.org at the same time
> > as I upload to tux.org, since I've already got an area there. Would
> > this be useful? If so, then perhaps Linus could put in a symbolic link
> > so that ftp.kernel.org:/pub/linux/kernel/faq.html points to:
> > "people/rgooch/faq.html", so that it's visible from the top level.
>
> It would be nice if the section of compile problems could be linked
> to separately, so people don't have to read the whole FAQ to read
> about their specific problem. While reading the whole thing is not
> a bad idea, it _is_ fairly long.
That would be easy to do with the WWW pages on http://www.kernel.org. Is that
what you had in mind?
However, you can easily end up with a growing list of "hotlinks" into
the FAQ, as someone decides some piece of information is really
important. As soon as you have one hotlink, you open the door for
many. Besides, the FAQ *does* have a contents list (with links).
People should be using that.
Ultimately, there's only so much you can do against human laziness.
I know, because I'm lazy too :-) I'd rather fiddle with the controls
of a new VCR than read the manual, or type "make" before reading the
README.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
On Thu, 22 Nov 2001 21:22:49 -0700,
Andreas Dilger <[email protected]> wrote:
>Well, you've seen how many times Keith points people to the FAQ on
>module versions, after they post to the list first. You only see
>the FAQ URL at the bottom of the emails if you have previously read
>the mailing list, which most haven't.
kbuild 2.5:
Starting phase 4 (build) for installable
CC drivers/usb/hpusbscsi.o
... gcc error messages ...
make[1]: *** [drivers/usb/hpusbscsi.o] Error 1
Kernel build failed. Please read the FAQ at http://www.tux.org/lkml/ before sending a bug report
make: *** [phase4] Error 1
"Richard Gooch" <[email protected]> wrote in message
news:[email protected]...
> Andreas Dilger writes:
> > On Nov 23, 2001 11:03 +1100, Stuart Young wrote:
> > > >Something along the lines of 'Your kernel failed to build. Check
> > > >http://www.where-ever-the-buglist-is.org for known issues with your kernel. Post
> > > >your problem on the kernel list if this is not a FRB'. Is this something
> > > >that can be done easily?
> > >
> > > At the bottom of the file, have ANOTHER link to a generic FAQ about
> > > compilation problems (which covers all the major things like forgetting to
> > > install an assembler, the broken old build stuff, 'make dep' before
> > > compiling modules, etc). The FAQ could be on the kernel mirrors as well
> > > (and I don't see why not, as this is all kernel related, and definitely a
> > > resource that needs to be in more than one place).
> >
> > Yes!!!! Anything to reduce the number of repeat problems reported
> > is good in my books. It might also hold a pointer to Linus' (or
> > Marcello's) -pre patch area, with a warning that they are not for
> > everyone.
>
> Well, the FAQ is supposed to answer these questions. There's a whole
> section on compile problems. Do we need another FAQ?
>
No, we do not need another FAQ. But we could certainly use a few more *pointers*
to the existing ones.
Rob
On Wed, Nov 21, 2001 at 08:28:58AM +0100, DevilKin wrote:
> Hi all,
>
> Just a thought. Don't shoot the messenger/idiot that thought of it.
>
> >He's doubtless referring to the deactivate_page()
> >thing that's been talked to death on this list for
> >the past 2 weeks...
> I'm getting rather annoyed with the same problem being reported/asked about
> over and over again...
>
> Is there - or would it be nice it it would be here - a list of recent
> compilation problems encountered with stock kernels (and what to do about
> it)? (see the loop.c thingy recently, and other problems with other stock
> kernels). So we could just point the people to that thing instead of having
> these 'discussions' over and over again...
>
> It could be about only the 'full' versions, or maybe the 'pre' kernels
> too...
>
> Maybe it would even be possible to add keywords to the filtering procs of
> the lkml, so that those persons would get a sort of -automatic- email on
> the subject...
>
> Just a thought...
>
I'm sorry, but the posts that are flooding the list are well deserved.
It is a great way to encourage more testing before a new "stable" kernel is
released.
I don't like it as much as anyone else, but it is a great motivator.
Don't fix it, this system is working the way it should. Most people
will just post anyway.
Mike
On Wed, 21 Nov 2001, Miguel Maria Godinho de Matos wrote:
> The problem is the following:
>
> I AM A NEWBIE!!!
>
> Well i had some questions about the linux kernel compilation and some of you
> gave me some real goos answeres, however, there is an issue which keeps
> buzzing my head and that i can't understand!
>
> Some one told me i should edit the loop.c file and even tried to explained me
> why but i couldn't understand.
>
> He said something about my new kernel wouldn't be able to compile if two or
> three lines weren't comented!
>
> I didn't understand this fact so i would like to know why should i edit the
> /usr/src/linux/drivers/block/loop.c file!!!!
You should edit out those lines because your kernel will not compile
unless you do so.
Those lines are not supposed to be there and need to be removed. They are
left over from an earlier version of the kernel and are not only not
required but prevent compilation.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.