"Albert D. Cahalan" wrote:
>
> Hans Reiser writes:
> > Alan Cox wrote:
> >> [Ablert Cahalan]
>
> >>> In an __init function, have some code that will trigger the bug.
> >>> This can be used to disable Reiserfs if the compiler was bad.
> >>> Then the admin gets a printk() and the Reiserfs mount fa
Hans Reiser writes:
> Alan Cox wrote:
>> [Ablert Cahalan]
>>> In an __init function, have some code that will trigger the bug.
>>> This can be used to disable Reiserfs if the compiler was bad.
>>> Then the admin gets a printk() and the Reiserfs mount fails.
>>
>> Thats actually quite doable. I'll
> Since egcs-1.1.2 and gcc 2.95 miscompile the kernel strstr code dont forget
> to stop those being used as well. Oh look you'll need CVS gcc to build the
> kernel... ah but wait that misbuilds DAC960.c...
How did you come to the conclusion that egcs-1.1.2 miscompiles the kernel?
I am using gcc ve
Oh believe ,e I agree. But here we run into the dilbert principal and we
really should be sarter than the IT Diredtor that makes stupid decisions and overrides
thier admins with insane schedules that prevent a full reading of the docs. 8-(
Believe me, it's far more common a situation th
On Mon, 5 Feb 2001, Hans Reiser wrote:
> Alan Cox wrote:
> >
> > > In an __init function, have some code that will trigger the bug.
> > > This can be used to disable Reiserfs if the compiler was bad.
> > > Then the admin gets a printk() and the Reiserfs mount fails.
> >
> > Thats actually quite
Alan Cox wrote:
>
> > > I was thinking boot time.
> > and if reiserfs is the root partition? You really want to make them reboot to
> > the old kernel and recompile rather than making them just recompile?
>
> I want to make sure they get a sane clear message telling them where to
> find the cor
On Mon, 5 Feb 2001, Hans Reiser wrote:
> and if reiserfs is the root partition? You really want to make them reboot to
> the old kernel and recompile rather than making them just recompile?
>
> Stop trying to blame something other than the compiler, it is ridiculous.
Blaming the compiler is one
> > I was thinking boot time.
> and if reiserfs is the root partition? You really want to make them reboot to
> the old kernel and recompile rather than making them just recompile?
I want to make sure they get a sane clear message telling them where to
find the correct compiler and that they did
Alan Cox wrote:
>
> > > Thats actually quite doable. I'll see about dropping the test into -ac that
> > > way.
> > NO!! It should NOT fail at mount time, it should fail at compile time.
>
> I was thinking boot time.
and if reiserfs is the root partition? You really want to make them reb
> > Thats actually quite doable. I'll see about dropping the test into -ac that
> > way.
> NO!! It should NOT fail at mount time, it should fail at compile time.
I was thinking boot time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Alan Cox wrote:
>
> > No. There are *many* other compilers out there which are much *more* broken
> > then anything RedHat has recently shipped. Unfortunatly, there is no easy
> > way to accuratly test for such bugs (because once they can be boiled down to
> > a simple test they are very rapidly
Alan Cox wrote:
>
> > In an __init function, have some code that will trigger the bug.
> > This can be used to disable Reiserfs if the compiler was bad.
> > Then the admin gets a printk() and the Reiserfs mount fails.
>
> Thats actually quite doable. I'll see about dropping the test into -ac tha
Alan Cox wrote:
>
> > administrator that has worked in large multi hundred million dollar compani=
> > es where 1 hour of downtime =3D=3D $75,000 in lost income proactive prevent=
> > ion IS the right answer. If the gcc people need to compile with the .96 rh =
> > version then they can apply a re
> No. There are *many* other compilers out there which are much *more* broken
> then anything RedHat has recently shipped. Unfortunatly, there is no easy
> way to accuratly test for such bugs (because once they can be boiled down to
> a simple test they are very rapidly fixed, what's left is voodo
> In an __init function, have some code that will trigger the bug.
> This can be used to disable Reiserfs if the compiler was bad.
> Then the admin gets a printk() and the Reiserfs mount fails.
Thats actually quite doable. I'll see about dropping the test into -ac that
way.
-
To unsubscribe from
> administrator that has worked in large multi hundred million dollar compani=
> es where 1 hour of downtime =3D=3D $75,000 in lost income proactive prevent=
> ion IS the right answer. If the gcc people need to compile with the .96 rh =
> version then they can apply a removal patch hans provides i
On Sun, Feb 04, 2001 at 08:50:13PM -0600, Brian Wolfe wrote:
[snip]
> From the debate raging here is what I gathered is acceptable
>
> make it blow up fataly and immediatly if it detects Red Hat + gcc
>2.96-red_hat_broken(forgot version num)
> make it provide a URL to get the patch to
Brian Wolfe writes:
> I hate to say it but I think Hans might have the right answer here.
> As an administrator that has worked in large multi hundred million
> dollar companies where 1 hour of downtime == $75,000 in lost income
...
> From the debate raging here is what I gathered is acceptable..
I hate to say it but I think Hans might have the right answer here. As an
administrator that has worked in large multi hundred million dollar companies where 1
hour of downtime == $75,000 in lost income proactive prevention IS the right answer.
If the gcc people need to compile with the
> > can bracket his code in 'if [ $TRUSTED = "y" ] ... fi', so if some driver-fs
> > fails with untrusted compilers it is just not selectable.
>
> What kind of crap is this?
> It is not the kernel's job to work around RedHat bugs.
The kernel actually works round gcc 2.7.2, egcs-1.1.2 and gcc-2.9
On Sat, 03 Feb 2001 00:57:45 -0800, David Ford <[EMAIL PROTECTED]>
wrote:
>How about a simple patch to the top level makefile that checks the gcc
>version then prints a distinct message ..'this compiler hasn't been approved
>for compiling the kernel', sleeping for one second, then continuing on.
Alan Cox writes:
> [Albert Cahalan]
>> David Woodhouse writes:
>>> -a "$CC" = "gcc"
>>
>> Not worth it; they should upgrade the local gcc too.
>> If anything, they are getting a reminder that they need.
>
> The local gcc has no bearing on the compiler. The local
> compiler might not even be gcc
Thus spake J . A . Magallon ([EMAIL PROTECTED]):
> > How about a simple patch to the top level makefile that checks the gcc
> > version then prints a distinct message ..'this compiler hasn't been approved
> > for compiling the kernel', sleeping for one second, then continuing on. This
> > solutio
On 02.03 David Ford wrote:
> How about a simple patch to the top level makefile that checks the gcc
> version then prints a distinct message ..'this compiler hasn't been approved
> for compiling the kernel', sleeping for one second, then continuing on. This
> solution doesn't stop compiling and
> David Woodhouse writes:
>
> > -a "$CC" = "gcc"
>
> Not worth it; they should upgrade the local gcc too.
> If anything, they are getting a reminder that they need.
The local gcc has no bearing on the compiler. The local compiler might not
even be gcc - eg if they are cross building off non L
David Woodhouse writes:
> -a "$CC" = "gcc"
Not worth it; they should upgrade the local gcc too.
If anything, they are getting a reminder that they need.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at
On Fri, 2 Feb 2001, Alan Cox wrote:
> if [ -e /bin/rpm ]; then
> X=`rpm -q gcc`
> if [ "$X" = "gcc-2.96-54" ]; then
> echo "*** GCC 2.96-54 will miscompile Reiserfs. Please update your
>compiler"
> echo "See http://www.redhat.com/support/errata/RHB
On Sat, Feb 03, 2001 at 04:25:20AM +, Paul Jakma wrote:
> On Fri, 2 Feb 2001, Jakub Jelinek wrote:
>
> > You can do:
> > if [ "$CC" = gcc ]; then
> > echo 'inline void f(unsigned int n){int
>i,j=-1;for(i=0;i<10&&j<0;i++)if((1UL< > test.c
> > gcc -O2 -o test test.c
> > if ./test; then e
On 02.03 Paul Jakma wrote:
>
> didn't barf here with 2.96-70.
>
Does not barf nor 1 nor 0. Check return core (ie, echo $?).
--
J.A. Magallon $> cd pub
mailto:[EMAIL PROTECTED] $> more beer
Linux we
How about a simple patch to the top level makefile that checks the gcc
version then prints a distinct message ..'this compiler hasn't been approved
for compiling the kernel', sleeping for one second, then continuing on. This
solution doesn't stop compiling and makes a visible indicator without fo
> > compiler (e.g. on sparc64). This test will barf on gcc-2.96 up to -67 and
> > Jakub
>
> ehhmm..
>
> didn't barf here with 2.96-70.
Which is correct
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FA
> Please, do not do so. That depends on the PACKAGE name and version, and there
> is no standard way of versioning a patched gcc.
> The -54 is a RH'ism, for example Mandrake Cooker includes patches from
> different sources, and gcc is versioned like
>
> werewolf:~# rpm -q gcc
> gcc-2.96-0.33mdk
On Fri, 2 Feb 2001, Jakub Jelinek wrote:
> You can do:
> if [ "$CC" = gcc ]; then
> echo 'inline void f(unsigned int n){int
>i,j=-1;for(i=0;i<10&&j<0;i++)if((1UL< > test.c
> gcc -O2 -o test test.c
> if ./test; then echo "*** Please don't use this compiler to compile kernel"; fi
> rm -f t
Ion Badulescu <[EMAIL PROTECTED]> writes:
> On Fri, 2 Feb 2001, Alan Cox wrote:
>
> > Oh I can see why Hans wants to cut down his bug reporting load. I can also
> > say from experience it wont work. If you put #error in then everyone will
> > mail him and complain it doesnt build, if you put #wa
On Sat, 3 Feb 2001, Hans Reiser wrote:
> Alan Cox wrote:
> >
> > > It makes sense to refuse to build a piece of the kernel if it break's
> > > a machine - anything else is a timebomb waiting to explode.
> >
> > The logical conclusion of that is to replace the entire kernel tree with
> >
> > #er
On Fri, Feb 02, 2001 at 02:58:14PM -0800, [EMAIL PROTECTED] wrote:
> Now, it seems to me, as long as the ReiserFS folks are going to be getting the
> bulk of the extra work(/mail/whatever) out of this, and they've been advised
> of the risks to their own person and are ok with that (which they
On Sat, Feb 03, 2001 at 12:40:03AM +0100, J . A . Magallon wrote:
> Please, do not do so. That depends on the PACKAGE name and version, and there
> is no standard way of versioning a patched gcc.
> The -54 is a RH'ism, for example Mandrake Cooker includes patches from
> different sources, and gcc
I would agree with you, and I was about to write something saying that trusting
that rpm is installed is bad, except that then I realized, only RedHat made this
error, and only RedHat installs need this protection.
Now, if we want to have a more general bad gcc's list, and we envision this code
e
On 02.02 Hans Reiser wrote:
> Alan Cox wrote:
> > Run a small shell check and let it fail if the shell stuff errors.
> >
> > The fragment you want is
> >
> > if [ -e /bin/rpm ]; then
> > X=`rpm -q gcc`
> > if [ "$X" = "gcc-2.96-54" ]; then
> > echo "*** GCC 2.96-
On Sat, Feb 03, 2001 at 01:03:00AM +0300, Hans Reiser wrote:
> My design objective in ReiserFS is not to say that it wasn't my fault they had
> that bug because they are so ignorant about a filesystem that
> really isn't very important to them unless it screws up. My design objective is
> to ensu
On Sat, 3 Feb 2001, Hans Reiser wrote:
> That said, my opinion is that bug reporting load is not as important as bug
> avoidance, but I understand your position has merit to it also.
If you do it, at least restrict it to 2.96.0. Maybe Red Hat will see the
light and release a fixed 2.96.1...
Ion
On Fri, 2 Feb 2001 16:39:18 -0500 (EST),
Alan Cox <[EMAIL PROTECTED]> wrote:
>Large numbers of people routinely build the kernel with 'unsupported' compilers
gcc version 2.96-ia64-000717 snap 001117 - works for me doing cross
compile from ia32 to ia64. Anybody adding #ifdef, please include thi
Alan Cox wrote:
>
> > > their kernel, something putting #ifdefs all over it will mean they have to
> > > mess around to fix too.
> > >
> > A moment of precision here. We won't test to see if the right compiler is used,
> > we will just test for the wrong one.
>
> Ok that makes a lot more sense
Alan Cox wrote:
>
> > It makes sense to refuse to build a piece of the kernel if it break's
> > a machine - anything else is a timebomb waiting to explode.
>
> The logical conclusion of that is to replace the entire kernel tree with
>
> #error "compiler or program might have a bug. Aborting"
N
> my convenience matters as much as that of the users. I don't want to use
> #ifdefs, I want it to die explosively and verbosely informatively. make isn't
> the most natural language for that, but I am sure Yura can find a way.
Run a small shell check and let it fail if the shell stuff errors.
> > their kernel, something putting #ifdefs all over it will mean they have to
> > mess around to fix too.
> >
> A moment of precision here. We won't test to see if the right compiler is used,
> we will just test for the wrong one.
Ok that makes a lot more sense
-
To unsubscribe from this list
Alan Cox wrote:
>
> > As it stands, there is no way to determine programatically whether
> > gcc-2.96 is broken or now. The only way to do it is to check the RPM
> > version -- which, needless to say, is a bit difficult to do from the
> > C code about to be compiled. So I can't really blame Hans
Alan Cox wrote:
>
> > my convenience matters as much as that of the users. I don't want to use
> > #ifdefs, I want it to die explosively and verbosely informatively. make isn't
> > the most natural language for that, but I am sure Yura can find a way.
>
> Run a small shell check and let it fai
On Fri, Feb 02, 2001 at 09:57:39PM +, Alan Cox wrote:
: > As it stands, there is no way to determine programatically whether
: > gcc-2.96 is broken or now. The only way to do it is to check the RPM
: > version -- which, needless to say, is a bit difficult to do from the
: > C code about to be
Alan Cox wrote:
>
> > Users cannot use gcc 2.96 as shipped in RedHat 7.0 if they want to use
> > reiserfs. It is that simple. How can you even consider defending allowing the
> > use of it without requiring a positive affirmation by the user that they don't
> > know what they are doing and want
> As it stands, there is no way to determine programatically whether
> gcc-2.96 is broken or now. The only way to do it is to check the RPM
> version -- which, needless to say, is a bit difficult to do from the
> C code about to be compiled. So I can't really blame Hans if he decides
> to outlaw g
Lets not go overboard Alan ;-)
> > It makes sense to refuse to build a piece of the kernel if it break's
> > a machine - anything else is a timebomb waiting to explode.
>
> The logical conclusion of that is to replace the entire kernel tree with
>
> #error "compiler or program might have a bug
> It makes sense to refuse to build a piece of the kernel if it break's
> a machine - anything else is a timebomb waiting to explode.
The logical conclusion of that is to replace the entire kernel tree with
#error "compiler or program might have a bug. Aborting"
The kernel is NOT some US home
My last comment on this...
It makes sense to refuse to build a piece of the kernel if it break's
a machine - anything else is a timebomb waiting to explode.
I feel politics are at play here...I don't really care who's bug it is -
all I know is using pre 2.96 fixes it and everyone needs to be a
> Users cannot use gcc 2.96 as shipped in RedHat 7.0 if they want to use
> reiserfs. It is that simple. How can you even consider defending allowing the
> use of it without requiring a positive affirmation by the user that they don't
> know what they are doing and want to do it anyway?:-) I cou
On Fri, 2 Feb 2001 16:46:45 + (GMT), Alan Cox <[EMAIL PROTECTED]> wrote:
>> :It is the original one. I'll try with the -69:
>> :
>> With 2.96-69 the reiserfs seems to work well.
>> Sorry for the confusion, I forgot to upgrade the gcc on my machine.
>
> Excellent. Im just glad to kno
Alan Cox wrote:
>
> > So, did Linus say no? If not, let's ask him with a patch. Quite simply,
> > neither we nor the users should be burdened with this, and the patch removes
> > the burden.
>
> Since egcs-1.1.2 and gcc 2.95 miscompile the kernel strstr code dont forget
> to stop those being u
> So, did Linus say no? If not, let's ask him with a patch. Quite simply,
> neither we nor the users should be burdened with this, and the patch removes
> the burden.
Since egcs-1.1.2 and gcc 2.95 miscompile the kernel strstr code dont forget
to stop those being used as well. Oh look you'll nee
Chris Mason wrote:
> Hans, decisions about proper compilers should not be made in each
> individual part of the kernel. If unpatched gcc 2.96 is getting reiserfs
broke is broke. If you use reiserfs, DO NOT use 2.96. Period. Nobody gains
by letting a single user make this mistake.
> wrong
> : It is the original one. I'll try with the -69:
> :
> With 2.96-69 the reiserfs seems to work well.
> Sorry for the confusion, I forgot to upgrade the gcc on my machine.
Excellent. Im just glad to know its a fixed bug.
-
To unsubscribe from this list: send the line "unsubscribe linu
Jan Kasprzak wrote:
: :
: : 2.96-69 should be ok (thats the one I've been using without trouble). The
: : original one with RH 7.0 off the CD does miscompile a few kernel things.
:
: It is the original one. I'll try with the -69:
:
With 2.96-69 the reiserfs seems to work well.
So
On Friday, February 02, 2001 12:26:52 PM + Alan Cox
<[EMAIL PROTECTED]> wrote:
>> This is why our next patch will detect the use of gcc 2.96, and
>> complain, in the reiserfs Makefile.
>
> What makes you think its gcc 2.96 ?
>
We have had many reports of exactly this symlink problem, and
> > What makes you think its gcc 2.96 ?
>
> We have had many reports of exactly this symlink problem, and each time it
> was a redhat user with a gcc 2.96, and switching to kgcc fixed it. We have
> one report (now two with Alan's) that 2.96-69 does not show this crash.
Ok. That would make sens
Alan Cox wrote:
: > Hans Reiser wrote:
: >: This is why our next patch will detect the use of gcc 2.96, and complain, in the
: >: reiserfs Makefile.
: >:
: > OK, thanks. It works with older compiler (altough I use gcc 2.96
: > for a long time for compiling various 2.[34] kernels without probl
> Hans Reiser wrote:
> : This is why our next patch will detect the use of gcc 2.96, and complain, in the
> : reiserfs Makefile.
> :
> OK, thanks. It works with older compiler (altough I use gcc 2.96
> for a long time for compiling various 2.[34] kernels without problem).
Ok which 2.96 com
> This is why our next patch will detect the use of gcc 2.96, and complain, in the
> reiserfs Makefile.
What makes you think its gcc 2.96 ?
If the person concerned can clarify what they built with (2.96-69 or
egcs-1.1.2 (kgcc)), that would be useful.
I've certainly done the Reiserfs testing I d
Hans Reiser wrote:
: This is why our next patch will detect the use of gcc 2.96, and complain, in the
: reiserfs Makefile.
:
OK, thanks. It works with older compiler (altough I use gcc 2.96
for a long time for compiling various 2.[34] kernels without problem).
-Yenya
--
\ Jan "Yenya" K
This is why our next patch will detect the use of gcc 2.96, and complain, in the
reiserfs Makefile.
Hans
Jan Kasprzak wrote:
>
> Hello,
>
> with ReiserFS support in 2.4.1 I have decided to give it a try.
> I created a filesystem on a spare partition, mounted it as /mnt,
> and t
Hello,
with ReiserFS support in 2.4.1 I have decided to give it a try.
I created a filesystem on a spare partition, mounted it as /mnt,
and tried to use it. The kernel crashed - I am able to reproduce it
with the following steps:
- boot linux with init=/bin/bash
- [optional] /sbi
69 matches
Mail list logo
