Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 than you would ever expect. Brian On Mon, Feb 05, 2001 at 11:55:16AM +, 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 removal patch hans provides in the crash mess= > > age. This makes it easy to remove the safeguard and blow yourself up at wil= > > l after being suitibly called a dumbass. > > With all due respect, if you are running $75,000/hr of lost income (which btw > is small fry to a lot of folks) shouldn't you have an engineering team who > a) read the documentation. > b) run tests before rolling out software > > Alan - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 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. A simple "make test" to run this sort of automated sanity check would be good, I think? James. - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 fixed, what's left is voodoo). > > The problem isn't so much that compilers get bugs and they get fixed as > soon as a good test case pops up, its that end users don't habitually check > for a compiler update. Being able to say 'look go get a new compiler' is > productive. Especially as the kernel can panic with a URL ;) > > Alan Here we agree. Hans - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 that > way. NO!! It should NOT fail at mount time, it should fail at compile time. Hans - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 removal patch hans provides in the crash mess= > > age. This makes it easy to remove the safeguard and blow yourself up at wil= > > l after being suitibly called a dumbass. > > With all due respect, if you are running $75,000/hr of lost income (which btw > is small fry to a lot of folks) shouldn't you have an engineering team who > a) read the documentation. > b) run tests before rolling out software > > Alan Think of it as being like gun safety. You don't seek to develop habits that protect you when you are awake and alert and paying attention, you strongly seek to develop the sort of habits that will protect you if for one moment your attention wanders and you do something completely stupid. Oh dear, there may be some cultural translation difficulty with this example.:-) User protection is a variant on that. To have an attitude that if the user was only alert and intelligent at the moment and as educated as you are in how to compile a kernel, this is just, ahem, not right. All things must be kept in balance though, and not taken to extremes. But when the number of users complaining exceeds some amount relative to the cost to protect them, they should be protected from their lack of education in what distro to not trust the compiler on. You can go ahead and write software for the always alert and always intelligent and never too hasty and always read the README users, and I'll be happy with having the rest of the market for ReiserFS.:-) Hans - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
> 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 voodoo). The problem isn't so much that compilers get bugs and they get fixed as soon as a good test case pops up, its that end users don't habitually check for a compiler update. Being able to say 'look go get a new compiler' is productive. Especially as the kernel can panic with a URL ;) Alan - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
> 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 this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
> 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 in the crash mess= > age. This makes it easy to remove the safeguard and blow yourself up at wil= > l after being suitibly called a dumbass. With all due respect, if you are running $75,000/hr of lost income (which btw is small fry to a lot of folks) shouldn't you have an engineering team who a) read the documentation. b) run tests before rolling out software Alan - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 in the crash mess= age. This makes it easy to remove the safeguard and blow yourself up at wil= l after being suitibly called a dumbass. With all due respect, if you are running $75,000/hr of lost income (which btw is small fry to a lot of folks) shouldn't you have an engineering team who a) read the documentation. b) run tests before rolling out software Alan - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 voodoo). The problem isn't so much that compilers get bugs and they get fixed as soon as a good test case pops up, its that end users don't habitually check for a compiler update. Being able to say 'look go get a new compiler' is productive. Especially as the kernel can panic with a URL ;) Alan - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 removal patch hans provides in the crash mess= age. This makes it easy to remove the safeguard and blow yourself up at wil= l after being suitibly called a dumbass. With all due respect, if you are running $75,000/hr of lost income (which btw is small fry to a lot of folks) shouldn't you have an engineering team who a) read the documentation. b) run tests before rolling out software Alan Think of it as being like gun safety. You don't seek to develop habits that protect you when you are awake and alert and paying attention, you strongly seek to develop the sort of habits that will protect you if for one moment your attention wanders and you do something completely stupid. Oh dear, there may be some cultural translation difficulty with this example.:-) User protection is a variant on that. To have an attitude that if the user was only alert and intelligent at the moment and as educated as you are in how to compile a kernel, this is just, ahem, not right. All things must be kept in balance though, and not taken to extremes. But when the number of users complaining exceeds some amount relative to the cost to protect them, they should be protected from their lack of education in what distro to not trust the compiler on. You can go ahead and write software for the always alert and always intelligent and never too hasty and always read the README users, and I'll be happy with having the rest of the market for ReiserFS.:-) Hans - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 that way. NO!! It should NOT fail at mount time, it should fail at compile time. Hans - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 fixed, what's left is voodoo). The problem isn't so much that compilers get bugs and they get fixed as soon as a good test case pops up, its that end users don't habitually check for a compiler update. Being able to say 'look go get a new compiler' is productive. Especially as the kernel can panic with a URL ;) Alan Here we agree. Hans - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 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. A simple "make test" to run this sort of automated sanity check would be good, I think? James. - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 than you would ever expect. Brian On Mon, Feb 05, 2001 at 11:55:16AM +, 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 removal patch hans provides in the crash mess= age. This makes it easy to remove the safeguard and blow yourself up at wil= l after being suitibly called a dumbass. With all due respect, if you are running $75,000/hr of lost income (which btw is small fry to a lot of folks) shouldn't you have an engineering team who a) read the documentation. b) run tests before rolling out software Alan - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 remove this safeguard if you really want >this. > > The fatal crash should be VERY carefull to only trigger on a redhat system >with the broken compiler. And to satisfy your agument that people may need to be able >to use it, provide a reverse patch to remove this safeguard in one easy cat file | >patch. 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 voodoo). - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 > > 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 remove this safeguard if you really want this. > > The fatal crash should be VERY carefull to only trigger on a redhat > system with the broken compiler. And to satisfy your agument that > people may need to be able to use it, provide a reverse patch to > remove this safeguard in one easy cat file | patch. There is another way: directly test for the bug. 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. - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
> > 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.95 bugs, but in this case having some CONFIG option and all the glue for it isnt right especially because there _is_ a fixed compiler and the documentation tells you to use 1.1.2 or 2.95 anyway - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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.95 bugs, but in this case having some CONFIG option and all the glue for it isnt right especially because there _is_ a fixed compiler and the documentation tells you to use 1.1.2 or 2.95 anyway - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 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 remove this safeguard if you really want this. The fatal crash should be VERY carefull to only trigger on a redhat system with the broken compiler. And to satisfy your agument that people may need to be able to use it, provide a reverse patch to remove this safeguard in one easy cat file | patch. There is another way: directly test for the bug. 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. - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 remove this safeguard if you really want this. The fatal crash should be VERY carefull to only trigger on a redhat system with the broken compiler. And to satisfy your agument that people may need to be able to use it, provide a reverse patch to remove this safeguard in one easy cat file | patch. 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 voodoo). - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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. This >solution doesn't stop compiling and makes a visible indicator without forcing >anything. A while ago I worked up a nasty bit of make logic which prompted the user for yes or no... and then did one thing or the other. You could ask the user if he REALLY wants to continue and wait for a response. Following is the model code... John Alvord = _ECHO=@ all: t0 t1 t2 t3 t4 t5 t6 # prompt for input, must be in a separate rule to unbuffer terminal # output. t0: $(_ECHO)echo Enter Y or N: \\c # capture a line of terminal input, copy to a file, tell user t1: $(_ECHO)echo $(shell read ans; echo ans) > ans $(_ECHO)echo The answer is \\c $(_ECHO)cat ans # take first character of answer, upper case, store in another file # then create two files, one for yes and one for no # the || exit 0 is to mask the potential grep error, which # would result in an error message even a - was used to ignore error # and continue. The result is two files, which may be zero byte t2: $(_ECHO)cat ans | cut -c 1-1 | tr 'a-z' 'A-Z' >ans1 $(_ECHO)rm -f ansy $(_ECHO)rm -f ansn $(_ECHO)grep Y ans1 > ansy || exit 0 $(_ECHO)grep N ans1 > ansn || exit 0 # Check for case where neither answer file is > 0 bytes t3: $(_ECHO)test -s ansy || test -s ansn && exit 0; \ echo Answer [$(shell cat ans)] is neither Y or N! && exit 1 # handle Yes case. Exit if Y answer file is 0 bytes or missing t4: $(_ECHO)test ! -s ansy && exit 0; \ echo in YES processing # handle No case t5: $(_ECHO)test ! -s ansn && exit 0; \ echo in NO processing # remove files used during processing t6: $(_ECHO)rm -f ans $(_ECHO)rm -f ans1 $(_ECHO)rm -f ansn $(_ECHO)rm -f ansy - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 > > solution doesn't stop compiling and makes a visible indicator without forcing > > anything. > Or a config option like CONFIG_TRUSTED_COMPILER, and everyone that wants > 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. If RedHat ships a broken compiler, it is their responsibility to tell their customers and provide a working one. This kind of compatibility crap has caused commercial Unices to suffocate in their own bloat. We don't need this. And we don't want this. Felix - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 makes a visible indicator without forcing > anything. > Or a config option like CONFIG_TRUSTED_COMPILER, and everyone that wants can bracket his code in 'if [ $TRUSTED = "y" ] ... fi', so if some driver-fs fails with untrusted compilers it is just not selectable. -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.4.1-ac1 #2 SMP Fri Feb 2 00:19:04 CET 2001 i686 - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 forcing
anything.
Sample attached.
-d
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 if he decides
> > to outlaw gcc-2.96[.0] for reiserfs compiles.
>
> 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 #warning in nobody will
> read it and if you dont put anything in you get the odd bug report anyway.
>
> Basically you can't win and unfortunately a shrink wrap forcing the user
> to read the README file for the kernel violates the GPL ..
>
> Jaded, me ?
>
> Alan
--
There is a natural aristocracy among men. The grounds of this are virtue and
talents. Thomas Jefferson
The good thing about standards is that there are so many to choose from. Andrew S.
Tanenbaum
--- Makefile.orig Sat Feb 3 00:48:26 2001
+++ MakefileSat Feb 3 00:45:00 2001
@@ -253,11 +253,23 @@
-o vmlinux
$(NM) vmlinux | grep -v '\(compiled\)\|\(\.o$$\)\|\( [aUw]
\)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' | sort > System.map
-symlinks:
+symlinks: gccversioncheck
rm -f include/asm
( cd include ; ln -sf asm-$(ARCH) asm)
@if [ ! -d include/linux/modules ]; then \
mkdir include/linux/modules; \
+ fi
+
+gccversioncheck:
+ @gccversion=`${HOSTCC} --version`;\
+ echo Using gcc version: $$gccversion;\
+ if [ "x$${gccversion}" != "x2.95.2" ]; then \
+ echo
+""; \
+ echo "*** This compiler version is not approved for compiling the
+kernel"; \
+ echo "*** version: " $$HOSTCC $$gccversion ; \
+ echo "*** Please consider this when reporting bugs" ;\
+ echo
+""; \
+ sleep 1; \
fi
oldconfig: symlinks
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 forcing
anything.
Sample attached.
-d
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 if he decides
to outlaw gcc-2.96[.0] for reiserfs compiles.
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 #warning in nobody will
read it and if you dont put anything in you get the odd bug report anyway.
Basically you can't win and unfortunately a shrink wrap forcing the user
to read the README file for the kernel violates the GPL ..
Jaded, me ?
Alan
--
There is a natural aristocracy among men. The grounds of this are virtue and
talents. Thomas Jefferson
The good thing about standards is that there are so many to choose from. Andrew S.
Tanenbaum
--- Makefile.orig Sat Feb 3 00:48:26 2001
+++ MakefileSat Feb 3 00:45:00 2001
@@ -253,11 +253,23 @@
-o vmlinux
$(NM) vmlinux | grep -v '\(compiled\)\|\(\.o$$\)\|\( [aUw]
\)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' | sort System.map
-symlinks:
+symlinks: gccversioncheck
rm -f include/asm
( cd include ; ln -sf asm-$(ARCH) asm)
@if [ ! -d include/linux/modules ]; then \
mkdir include/linux/modules; \
+ fi
+
+gccversioncheck:
+ @gccversion=`${HOSTCC} --version`;\
+ echo Using gcc version: $$gccversion;\
+ if [ "x$${gccversion}" != "x2.95.2" ]; then \
+ echo
+""; \
+ echo "*** This compiler version is not approved for compiling the
+kernel"; \
+ echo "*** version: " $$HOSTCC $$gccversion ; \
+ echo "*** Please consider this when reporting bugs" ;\
+ echo
+""; \
+ sleep 1; \
fi
oldconfig: symlinks
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 makes a visible indicator without forcing anything. Or a config option like CONFIG_TRUSTED_COMPILER, and everyone that wants can bracket his code in 'if [ $TRUSTED = "y" ] ... fi', so if some driver-fs fails with untrusted compilers it is just not selectable. -- J.A. Magallon $ cd pub mailto:[EMAIL PROTECTED] $ more beer Linux werewolf 2.4.1-ac1 #2 SMP Fri Feb 2 00:19:04 CET 2001 i686 - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 solution doesn't stop compiling and makes a visible indicator without forcing anything. Or a config option like CONFIG_TRUSTED_COMPILER, and everyone that wants 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. If RedHat ships a broken compiler, it is their responsibility to tell their customers and provide a working one. This kind of compatibility crap has caused commercial Unices to suffocate in their own bloat. We don't need this. And we don't want this. Felix - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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. This solution doesn't stop compiling and makes a visible indicator without forcing anything. A while ago I worked up a nasty bit of make logic which prompted the user for yes or no... and then did one thing or the other. You could ask the user if he REALLY wants to continue and wait for a response. Following is the model code... John Alvord = _ECHO=@ all: t0 t1 t2 t3 t4 t5 t6 # prompt for input, must be in a separate rule to unbuffer terminal # output. t0: $(_ECHO)echo Enter Y or N: \\c # capture a line of terminal input, copy to a file, tell user t1: $(_ECHO)echo $(shell read ans; echo ans) ans $(_ECHO)echo The answer is \\c $(_ECHO)cat ans # take first character of answer, upper case, store in another file # then create two files, one for yes and one for no # the || exit 0 is to mask the potential grep error, which # would result in an error message even a - was used to ignore error # and continue. The result is two files, which may be zero byte t2: $(_ECHO)cat ans | cut -c 1-1 | tr 'a-z' 'A-Z' ans1 $(_ECHO)rm -f ansy $(_ECHO)rm -f ansn $(_ECHO)grep Y ans1 ansy || exit 0 $(_ECHO)grep N ans1 ansn || exit 0 # Check for case where neither answer file is 0 bytes t3: $(_ECHO)test -s ansy || test -s ansn exit 0; \ echo Answer [$(shell cat ans)] is neither Y or N! exit 1 # handle Yes case. Exit if Y answer file is 0 bytes or missing t4: $(_ECHO)test ! -s ansy exit 0; \ echo in YES processing # handle No case t5: $(_ECHO)test ! -s ansn exit 0; \ echo in NO processing # remove files used during processing t6: $(_ECHO)rm -f ans $(_ECHO)rm -f ans1 $(_ECHO)rm -f ansn $(_ECHO)rm -f ansy - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 if he decides > > to outlaw gcc-2.96[.0] for reiserfs compiles. > > 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 #warning in nobody will > read it and if you dont put anything in you get the odd bug report anyway. > > Basically you can't win and unfortunately a shrink wrap forcing the user > to read the README file for the kernel violates the GPL .. > > Jaded, me ? > > Alan I fear that you are speaking from experience about the complaints it doesn't build, and that there is a strong element of truth in what you say. 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. Hans - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 compiled. So I can't really blame Hans if he decides : > to outlaw gcc-2.96[.0] for reiserfs compiles. : : 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 #warning in nobody will : read it and if you dont put anything in you get the odd bug report anyway. : : Basically you can't win and unfortunately a shrink wrap forcing the user : to read the README file for the kernel violates the GPL .. Alan, as a user (one of those few that actually read documentation), I think it is a good idea to stop people from hurting their data by using the wrong compiler and assuming everything is ok until shit happens. As you explained, one either gets the bug reports or the complaints that $SOURCE doesn't compile. The work for the developers might be about the same size, the impact on the users' side is less destructive, though. Arthur -- arthur dot erhardt at pit dot physik dot uni dash tuebingen dot de *pgp key available* dg7sea A physicist is an atom's way of knowing about atoms. - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
> 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 gcc-2.96[.0] for reiserfs compiles. 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 #warning in nobody will read it and if you dont put anything in you get the odd bug report anyway. Basically you can't win and unfortunately a shrink wrap forcing the user to read the README file for the kernel violates the GPL .. Jaded, me ? Alan - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 know its a fixed bug. Yes. But since Red Hat took upon themselves to define "gcc 2.96", they should have created a new patchlevel (2.96.1) for their fixed compiler. 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 gcc-2.96[.0] for reiserfs compiles. Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
> : 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 linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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. Sorry for the confusion, I forgot to upgrade the gcc on my machine. -Yenya -- \ Jan "Yenya" Kasprzakhttp://www.fi.muni.cz/~kas/ \\ PGP: finger kas at aisa.fi.muni.cz 0D99A7FB206605D7 8B35FCDE05B18A5E // \\\ Czech Linux Homepage: http://www.linux.cz/ /// > Is there anything else I can contribute? -- The latitude and longtitude of the bios writers current position, and a ballistic missile. (Alan Cox) - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 problem). : : Ok which 2.96 compiler do you have. I need to get this one chased down since : its probably also going to be in the current gcc CVS branches heading for 3.0 : : 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: $ rpm -q gcc gcc -gcc-2.96-54 $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 2731 (Red Hat Linux 7.0) -Yenya -- \ Jan "Yenya" Kasprzakhttp://www.fi.muni.cz/~kas/ \\ PGP: finger kas at aisa.fi.muni.cz 0D99A7FB206605D7 8B35FCDE05B18A5E // \\\ Czech Linux Homepage: http://www.linux.cz/ /// > Is there anything else I can contribute? -- The latitude and longtitude of the bios writers current position, and a ballistic missile. (Alan Cox) - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
> 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 compiler do you have. I need to get this one chased down since its probably also going to be in the current gcc CVS branches heading for 3.0 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. - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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" Kasprzakhttp://www.fi.muni.cz/~kas/ \\ PGP: finger kas at aisa.fi.muni.cz 0D99A7FB206605D7 8B35FCDE05B18A5E // \\\ Czech Linux Homepage: http://www.linux.cz/ /// > Is there anything else I can contribute? -- The latitude and longtitude of the bios writers current position, and a ballistic missile. (Alan Cox) - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 tried to use it. The kernel crashed - I am able to reproduce it > with the following steps: > > - boot linux with init=/bin/bash > - [optional] /sbin/mkreiserfs /dev/hdd1 (it can be reproduced even > on freshly created FS) > - mount -t reiserfs /dev/hdd1 /mnt > - cp -arv /usr /mnt > > I am attaching the details, feel free to ask for more information, > if you want it. Please Cc: me in any reply. > > Oops is a NULL pointer dereference at address 0010, > EIP is c017c7c3 (in check_leaf), EFLAGS is 00010292, Process is "cp", > Code: 8b 52 10 ff d2 59 5b 8b 54 24 14 8b 42 34 89 c7 0f b7 47 02, > Call trace is the following: > c015f459 (in do_balance) > c0179466 (in fix_nodes) > c0179476 (also in fix_nodes) > c018612c (in reiserfs_insert_item) > c0173cb4 (near the end of reiserfs_new_symlink) > c0174170 (in reiserfs_new_inode) > c0170cbd (in reiserfs_symlink) > c0142a45 (in d_alloc) > c013c825 (in vfs_symlink) > c013c8de (in sys_symlink) > c0109023 (in system_call) > > All numbers are written by hand from the screen, so there may > be a minor mistakes. Looking at the cp output, it seems it crashed > while copying the symlink "/usr/bin/sgml2xml -> osx" to /mnt/bin. > > My computer is almost generic Red Hat 7.0 with all updates. > Hardware is K6-2 @523 MHz, 128M RAM, VIA VT82C598 north bridge. > > I tried to create ext2 filesystem on /dev/hdd1, and then > cp -arv /usr /mnt worked fine. > > The kernel config (grep '=[ym]' /usr/src/linux/.config) is the > following (no modules were loadaed, though): > > CONFIG_X86=y > CONFIG_ISA=y > CONFIG_UID16=y > CONFIG_EXPERIMENTAL=y > CONFIG_MODULES=y > CONFIG_KMOD=y > CONFIG_MK6=y > CONFIG_X86_WP_WORKS_OK=y > CONFIG_X86_INVLPG=y > CONFIG_X86_CMPXCHG=y > CONFIG_X86_BSWAP=y > CONFIG_X86_POPAD_OK=y > CONFIG_X86_ALIGNMENT_16=y > CONFIG_X86_TSC=y > CONFIG_X86_USE_PPRO_CHECKSUM=y > CONFIG_NOHIGHMEM=y > CONFIG_MTRR=y > CONFIG_NET=y > CONFIG_PCI=y > CONFIG_PCI_GOANY=y > CONFIG_PCI_BIOS=y > CONFIG_PCI_DIRECT=y > CONFIG_HOTPLUG=y > CONFIG_PCMCIA=y > CONFIG_CARDBUS=y > CONFIG_SYSVIPC=y > CONFIG_SYSCTL=y > CONFIG_KCORE_ELF=y > CONFIG_BINFMT_AOUT=m > CONFIG_BINFMT_ELF=y > CONFIG_BINFMT_MISC=y > CONFIG_PARPORT=m > CONFIG_PARPORT_PC=m > CONFIG_PARPORT_PC_FIFO=y > CONFIG_PARPORT_PC_SUPERIO=y > CONFIG_PARPORT_1284=y > CONFIG_BLK_DEV_FD=m > CONFIG_BLK_DEV_LOOP=m > CONFIG_PACKET=y > CONFIG_PACKET_MMAP=y > CONFIG_NETLINK=y > CONFIG_RTNETLINK=y > CONFIG_UNIX=y > CONFIG_INET=y > CONFIG_INET_ECN=y > CONFIG_IPV6=m > CONFIG_IPV6_EUI64=y > CONFIG_IDE=y > CONFIG_BLK_DEV_IDE=y > CONFIG_BLK_DEV_IDEDISK=y > CONFIG_IDEDISK_MULTI_MODE=y > CONFIG_BLK_DEV_IDECS=m > CONFIG_BLK_DEV_IDECD=m > CONFIG_BLK_DEV_IDEPCI=y > CONFIG_IDEPCI_SHARE_IRQ=y > CONFIG_BLK_DEV_IDEDMA_PCI=y > CONFIG_IDEDMA_PCI_AUTO=y > CONFIG_BLK_DEV_IDEDMA=y > CONFIG_IDEDMA_PCI_WIP=y > CONFIG_IDEDMA_NEW_DRIVE_LISTINGS=y > CONFIG_BLK_DEV_VIA82CXXX=y > CONFIG_IDEDMA_AUTO=y > CONFIG_BLK_DEV_IDE_MODES=y > CONFIG_NETDEVICES=y > CONFIG_NET_ETHERNET=y > CONFIG_NET_VENDOR_3COM=y > CONFIG_VORTEX=y > CONFIG_HAMACHI=m > CONFIG_PPP=m > CONFIG_PPP_ASYNC=m > CONFIG_PPP_DEFLATE=m > CONFIG_PPP_BSDCOMP=m > CONFIG_WAN=y > CONFIG_COSA=m > CONFIG_VT=y > CONFIG_VT_CONSOLE=y > CONFIG_SERIAL=y > CONFIG_UNIX98_PTYS=y > CONFIG_PRINTER=m > CONFIG_MOUSE=y > CONFIG_PSMOUSE=y > CONFIG_NVRAM=m > CONFIG_RTC=m > CONFIG_AGP=y > CONFIG_AGP_VIA=y > CONFIG_DRM=y > CONFIG_DRM_MGA=y > CONFIG_PCMCIA_SERIAL=y > CONFIG_AUTOFS4_FS=y > CONFIG_REISERFS_FS=y > CONFIG_REISERFS_CHECK=y > CONFIG_ISO9660_FS=m > CONFIG_PROC_FS=y > CONFIG_DEVPTS_FS=y > CONFIG_EXT2_FS=y > CONFIG_CODA_FS=m > CONFIG_NFS_FS=y > CONFIG_NFS_V3=y > CONFIG_NFSD=m > CONFIG_NFSD_V3=y > CONFIG_SUNRPC=y > CONFIG_LOCKD=y > CONFIG_LOCKD_V4=y > CONFIG_MSDOS_PARTITION=y > CONFIG_VGA_CONSOLE=y > CONFIG_VIDEO_SELECT=y > CONFIG_SOUND=y > CONFIG_SOUND_ES1371=y > CONFIG_USB=m > CONFIG_USB_DEVICEFS=y > CONFIG_USB_UHCI=m > CONFIG_USB_AUDIO=m > CONFIG_USB_SCANNER=m > > The dmesg output: > > Linux version 2.4.1 ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red Hat >Linux 7.0)) #2 Fri Feb 2 11:46:21 CET 2001 > BIOS-provided physical RAM map: > BIOS-e820: 0009fc00 @ (usable) > BIOS-e820: 0400 @ 0009fc00 (usable) > BIOS-e820: 0001 @ 000f (reserved) > BIOS-e820: 0001 @ (reserved) > BIOS-e820: 07ef @ 0010 (usable) > BIOS-e820: d000 @ 07ff3000 (ACPI data) > BIOS-e820: 3000 @ 07ff (ACPI NVS) > On node 0 totalpages: 32752 >
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 tried to use it. The kernel crashed - I am able to reproduce it with the following steps: - boot linux with init=/bin/bash - [optional] /sbin/mkreiserfs /dev/hdd1 (it can be reproduced even on freshly created FS) - mount -t reiserfs /dev/hdd1 /mnt - cp -arv /usr /mnt I am attaching the details, feel free to ask for more information, if you want it. Please Cc: me in any reply. Oops is a NULL pointer dereference at address 0010, EIP is c017c7c3 (in check_leaf), EFLAGS is 00010292, Process is "cp", Code: 8b 52 10 ff d2 59 5b 8b 54 24 14 8b 42 34 89 c7 0f b7 47 02, Call trace is the following: c015f459 (in do_balance) c0179466 (in fix_nodes) c0179476 (also in fix_nodes) c018612c (in reiserfs_insert_item) c0173cb4 (near the end of reiserfs_new_symlink) c0174170 (in reiserfs_new_inode) c0170cbd (in reiserfs_symlink) c0142a45 (in d_alloc) c013c825 (in vfs_symlink) c013c8de (in sys_symlink) c0109023 (in system_call) All numbers are written by hand from the screen, so there may be a minor mistakes. Looking at the cp output, it seems it crashed while copying the symlink "/usr/bin/sgml2xml - osx" to /mnt/bin. My computer is almost generic Red Hat 7.0 with all updates. Hardware is K6-2 @523 MHz, 128M RAM, VIA VT82C598 north bridge. I tried to create ext2 filesystem on /dev/hdd1, and then cp -arv /usr /mnt worked fine. The kernel config (grep '=[ym]' /usr/src/linux/.config) is the following (no modules were loadaed, though): CONFIG_X86=y CONFIG_ISA=y CONFIG_UID16=y CONFIG_EXPERIMENTAL=y CONFIG_MODULES=y CONFIG_KMOD=y CONFIG_MK6=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_ALIGNMENT_16=y CONFIG_X86_TSC=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_NOHIGHMEM=y CONFIG_MTRR=y CONFIG_NET=y CONFIG_PCI=y CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_HOTPLUG=y CONFIG_PCMCIA=y CONFIG_CARDBUS=y CONFIG_SYSVIPC=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_FIFO=y CONFIG_PARPORT_PC_SUPERIO=y CONFIG_PARPORT_1284=y CONFIG_BLK_DEV_FD=m CONFIG_BLK_DEV_LOOP=m CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_INET_ECN=y CONFIG_IPV6=m CONFIG_IPV6_EUI64=y CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y CONFIG_BLK_DEV_IDECS=m CONFIG_BLK_DEV_IDECD=m CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_IDEDMA=y CONFIG_IDEDMA_PCI_WIP=y CONFIG_IDEDMA_NEW_DRIVE_LISTINGS=y CONFIG_BLK_DEV_VIA82CXXX=y CONFIG_IDEDMA_AUTO=y CONFIG_BLK_DEV_IDE_MODES=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_VENDOR_3COM=y CONFIG_VORTEX=y CONFIG_HAMACHI=m CONFIG_PPP=m CONFIG_PPP_ASYNC=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_WAN=y CONFIG_COSA=m CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y CONFIG_UNIX98_PTYS=y CONFIG_PRINTER=m CONFIG_MOUSE=y CONFIG_PSMOUSE=y CONFIG_NVRAM=m CONFIG_RTC=m CONFIG_AGP=y CONFIG_AGP_VIA=y CONFIG_DRM=y CONFIG_DRM_MGA=y CONFIG_PCMCIA_SERIAL=y CONFIG_AUTOFS4_FS=y CONFIG_REISERFS_FS=y CONFIG_REISERFS_CHECK=y CONFIG_ISO9660_FS=m CONFIG_PROC_FS=y CONFIG_DEVPTS_FS=y CONFIG_EXT2_FS=y CONFIG_CODA_FS=m CONFIG_NFS_FS=y CONFIG_NFS_V3=y CONFIG_NFSD=m CONFIG_NFSD_V3=y CONFIG_SUNRPC=y CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_MSDOS_PARTITION=y CONFIG_VGA_CONSOLE=y CONFIG_VIDEO_SELECT=y CONFIG_SOUND=y CONFIG_SOUND_ES1371=y CONFIG_USB=m CONFIG_USB_DEVICEFS=y CONFIG_USB_UHCI=m CONFIG_USB_AUDIO=m CONFIG_USB_SCANNER=m The dmesg output: Linux version 2.4.1 ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red Hat Linux 7.0)) #2 Fri Feb 2 11:46:21 CET 2001 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (usable) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 0001 @ (reserved) BIOS-e820: 07ef @ 0010 (usable) BIOS-e820: d000 @ 07ff3000 (ACPI data) BIOS-e820: 3000 @ 07ff (ACPI NVS) On node 0 totalpages: 32752 zone(0): 4096 pages. zone(1): 28656 pages. zone(2): 0 pages. Kernel command line: auto BOOT_IMAGE=linux ro root=301 BOOT_FILE=/boot/linux no-hlt Initializing CPU#0
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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" Kasprzak kas at fi.muni.cz http://www.fi.muni.cz/~kas/ \\ PGP: finger kas at aisa.fi.muni.cz 0D99A7FB206605D7 8B35FCDE05B18A5E // \\\ Czech Linux Homepage: http://www.linux.cz/ /// Is there anything else I can contribute? -- The latitude and longtitude of the bios writers current position, and a ballistic missile. (Alan Cox) - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 compiler do you have. I need to get this one chased down since its probably also going to be in the current gcc CVS branches heading for 3.0 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. - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 problem). : : Ok which 2.96 compiler do you have. I need to get this one chased down since : its probably also going to be in the current gcc CVS branches heading for 3.0 : : 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: $ rpm -q gcc gcc -gcc-2.96-54 $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 2731 (Red Hat Linux 7.0) -Yenya -- \ Jan "Yenya" Kasprzak kas at fi.muni.cz http://www.fi.muni.cz/~kas/ \\ PGP: finger kas at aisa.fi.muni.cz 0D99A7FB206605D7 8B35FCDE05B18A5E // \\\ Czech Linux Homepage: http://www.linux.cz/ /// Is there anything else I can contribute? -- The latitude and longtitude of the bios writers current position, and a ballistic missile. (Alan Cox) - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
: 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 linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 know its a fixed bug. Yes. But since Red Hat took upon themselves to define "gcc 2.96", they should have created a new patchlevel (2.96.1) for their fixed compiler. 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 gcc-2.96[.0] for reiserfs compiles. Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 gcc-2.96[.0] for reiserfs compiles. 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 #warning in nobody will read it and if you dont put anything in you get the odd bug report anyway. Basically you can't win and unfortunately a shrink wrap forcing the user to read the README file for the kernel violates the GPL .. Jaded, me ? Alan - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 compiled. So I can't really blame Hans if he decides : to outlaw gcc-2.96[.0] for reiserfs compiles. : : 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 #warning in nobody will : read it and if you dont put anything in you get the odd bug report anyway. : : Basically you can't win and unfortunately a shrink wrap forcing the user : to read the README file for the kernel violates the GPL .. Alan, as a user (one of those few that actually read documentation), I think it is a good idea to stop people from hurting their data by using the wrong compiler and assuming everything is ok until shit happens. As you explained, one either gets the bug reports or the complaints that $SOURCE doesn't compile. The work for the developers might be about the same size, the impact on the users' side is less destructive, though. Arthur -- arthur dot erhardt at pit dot physik dot uni dash tuebingen dot de *pgp key available* dg7sea A physicist is an atom's way of knowing about atoms. - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 if he decides to outlaw gcc-2.96[.0] for reiserfs compiles. 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 #warning in nobody will read it and if you dont put anything in you get the odd bug report anyway. Basically you can't win and unfortunately a shrink wrap forcing the user to read the README file for the kernel violates the GPL .. Jaded, me ? Alan I fear that you are speaking from experience about the complaints it doesn't build, and that there is a strong element of truth in what you say. 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. Hans - 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 http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
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 -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - 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 http://www.tux.org/lkml/
