The PCI-SCI v1.1-7 Drivers for Dolphin's Scalable Coherent
Interface Adapters have been posted and are available for download
at vger.timpanogas.org:\sci\pci-sci-1.1-7 in tar.gz and RPM
(RedHat Package Manager Formats). This version supports Linux kernels
2.2.X up through 2.4.1. These drivers are released under the
GPL and are freely redistributible.
NOTES:
This release corrects modversion build problems related
to Red Hat's 7.1 Fischer Release. This release also corrects
build problems with the #ident keyword in the SCI source
tree with CVS. Please note that the sci sources will
always assume a stock kernel layout and will point to
/usr/src/linux/include for modversioned includes and files.
For whatever reason, RedHat 7.1 now points to a /usr/src/linux-2.4
tree which breaks drivers built against stock kernel trees.
Also, the GCC 2.96 compiler shipped with RedHat 7.1 is terribly
broken, and does not support #ident lines in the source code,
which also means that RedHat 7.1 will not work properly with
CVS (Code Versioning System) projects that use the #ident
keyword to identify and comment files. It generates
an "unknown keyword" error message. This version of the
sources disables some CVS enablement in order to build properly
on a RedHat 7.1 system with gcc 2.96.
Please also note that the RedHat 7.1 Fischer release with
the Linux 2.4.0 kernel will report bogus .modinfo relocation
warnings generated by the assembler while building some .c files
against the kernel source tree. These messages are a due to
severe bugs previously reported in the gcc 2.96 compiler and
assembler on RedHat versions 7.0 and above (the list for gcc 2.96
keeps growing).
Please direct any comments or bug reports to [email protected]
or [email protected].
Jeff Merkey
Chief Engineer, TRG
On Tue, Feb 06, 2001 at 06:25:01PM -0700, Jeff V. Merkey wrote:
>
> Also, the GCC 2.96 compiler shipped with RedHat 7.1 is terribly
> broken, and does not support #ident lines in the source code,
> which also means that RedHat 7.1 will not work properly with
> CVS (Code Versioning System) projects that use the #ident
> keyword to identify and comment files. It generates
> an "unknown keyword" error message. This version of the
> sources disables some CVS enablement in order to build properly
> on a RedHat 7.1 system with gcc 2.96.
More to add on the gcc 2.96 problems. After compiling a Linux 2.4.1
kernel on gcc 2.91, running SCI benchmarks, then compiling on RedHat
7.1 (Fischer) with gcc 2.96, the 2.96 build DROPPED 30% in throughput
from the gcc 2.91 compiled version on the identical SAME 2.4.1
source tree.
I think RedHat should jetison gcc 2.96 as soon as possible...
Tests run on a PIII system limited to 90 MB/S PCI throughput.
gcc 2.91 on a PIII system in sci_copy mode 85 MB/S
gcc 2.96 in RedHat 7.1 (Fischer) in sci_copy mode 63 MB/S
Jeff
>
On Tue, Feb 06, 2001 at 07:06:24PM -0700, Jeff V. Merkey wrote:
> More to add on the gcc 2.96 problems. After compiling a Linux 2.4.1
> kernel on gcc 2.91, running SCI benchmarks, then compiling on RedHat
> 7.1 (Fischer) with gcc 2.96, the 2.96 build DROPPED 30% in throughput
> from the gcc 2.91 compiled version on the identical SAME 2.4.1
> source tree.
[snip]
Come on Jeff, don't let your annoyance make you a fudder..
The Linux kernel relies on certain undefined behaviors of the compiler to
achieve locality of various types. The optimizer in the GCC 3.0 code tree
is much smarter and is not laying out code the way GCC 2.x did.
So it's very likely that this lossage is caused by poorer cache locality.
After GCC 3 is finalized, it's likely that kernel developers will begin
moving to it, and rethinking how they express such things as branch
probability and code alignment to the compiler. Until then, GCC 3.0
snapshots are NOT the recommended compiler for the linux-kernel and not even
RedHat compilers their kernel's with it. User beware.
It should also be noted that this compiler almost always produces faster user
space code then the older compilers, because almost nothing includes the
type of hand-tweaked C that the kernel uses so often on critical paths, most
of that software uses assembly in such situations.
So.. It's likely that calling your performance issues 'gcc bugs' is about
the same as saying that SGI cc is buggy because it can't compile the kernel.
At least you managed to avoid calling RedHat names. :)
> More to add on the gcc 2.96 problems. After compiling a Linux 2.4.1
> kernel on gcc 2.91, running SCI benchmarks, then compiling on RedHat
> 7.1 (Fischer) with gcc 2.96, the 2.96 build DROPPED 30% in throughput
> from the gcc 2.91 compiled version on the identical SAME 2.4.1
> source tree.
Out of interest, could you run your benchmark test against a "latest snapshot
build" of gcc?
http://www.codesourcery.com/gcc-snapshots/
Cheers,
David
> always assume a stock kernel layout and will point to
> /usr/src/linux/include for modversioned includes and files.
You can't assume that. The big problem is right now nobody has set an
agreed location for kernel sources, you also cant assume they will be
present.
Its something the FHS needs to address eventually (where eventually is sooner
not later)
> Please also note that the RedHat 7.1 Fischer release with
> the Linux 2.4.0 kernel will report bogus .modinfo relocation
> warnings generated by the assembler while building some .c files
> against the kernel source tree. These messages are a due to
> severe bugs previously reported in the gcc 2.96 compiler and
> assembler on RedHat versions 7.0 and above (the list for gcc 2.96
> keeps growing).
Nope. They are due to bugs in the kernel source. The bug in question is
intentionally left in the kernel sources to handle issues with older modutils.
Keith posted 2.4.x patches to drop support for older modutils and in doing so
remove the warning.
Alan
> kernel on gcc 2.91, running SCI benchmarks, then compiling on RedHat
> 7.1 (Fischer) with gcc 2.96, the 2.96 build DROPPED 30% in throughput
> from the gcc 2.91 compiled version on the identical SAME 2.4.1
> source tree.
30% is too big to be caused by a compiler. Way too big.I suggest you review
your code.
On Tue, Feb 06, 2001 at 09:07:31PM -0500, Gregory Maxwell wrote:
> So.. It's likely that calling your performance issues 'gcc bugs' is about
> the same as saying that SGI cc is buggy because it can't compile the kernel.
>
> At least you managed to avoid calling RedHat names. :)
I really have no idea why gcc 2.96 is so troublesome, but for a
commercial release I was somewhat surprised to see the problems
I did. I have heard about some of these problems for quite a
while, but got a chance to see them upclose with the 7.1
release. Hopefully, RedHat will eventually get the issues
smoothed out.
Not supporting #ident for CVS managed code bases would see to
me, at first glance, to be a show stopper to shipping a release
of anything, since many folks need CVS support.
:-)
Jeff
On Wed, Feb 07, 2001 at 09:01:49AM +0000, David Howells wrote:
>
> > More to add on the gcc 2.96 problems. After compiling a Linux 2.4.1
> > kernel on gcc 2.91, running SCI benchmarks, then compiling on RedHat
> > 7.1 (Fischer) with gcc 2.96, the 2.96 build DROPPED 30% in throughput
> > from the gcc 2.91 compiled version on the identical SAME 2.4.1
> > source tree.
>
> Out of interest, could you run your benchmark test against a "latest snapshot
> build" of gcc?
>
> http://www.codesourcery.com/gcc-snapshots/
>
> Cheers,
> David
Sure.
Jeff
On Wed, Feb 07, 2001 at 09:15:39AM +0000, Alan Cox wrote:
> > always assume a stock kernel layout and will point to
> > /usr/src/linux/include for modversioned includes and files.
>
> You can't assume that. The big problem is right now nobody has set an
> agreed location for kernel sources, you also cant assume they will be
> present.
>
I need a way from the RPM utility to determine this without writing some
huge ugly bash script. The 7.1 release is not putting it where uname
will return the correct name string.
> Its something the FHS needs to address eventually (where eventually is sooner
> not later)
>
> > Please also note that the RedHat 7.1 Fischer release with
> > the Linux 2.4.0 kernel will report bogus .modinfo relocation
> > warnings generated by the assembler while building some .c files
> > against the kernel source tree. These messages are a due to
> > severe bugs previously reported in the gcc 2.96 compiler and
> > assembler on RedHat versions 7.0 and above (the list for gcc 2.96
> > keeps growing).
>
> Nope. They are due to bugs in the kernel source. The bug in question is
> intentionally left in the kernel sources to handle issues with older modutils.
> Keith posted 2.4.x patches to drop support for older modutils and in doing so
> remove the warning.
>
> Alan
Hummm. Where are the patches for 2.4 to correct this? They are not posted
with the 7.1 release. They need to be. The compiler not supporting
#ident for CVS is a show stopper, and needs correcting ASAP. How can
someone use CVS properly with this, Alan?
:-)
Jeff
On Wed, Feb 07, 2001 at 09:22:43AM +0000, Alan Cox wrote:
> > kernel on gcc 2.91, running SCI benchmarks, then compiling on RedHat
> > 7.1 (Fischer) with gcc 2.96, the 2.96 build DROPPED 30% in throughput
> > from the gcc 2.91 compiled version on the identical SAME 2.4.1
> > source tree.
>
> 30% is too big to be caused by a compiler. Way too big.I suggest you review
> your code.
I went back and looked at what was being generated. for the sci copy testing,
the MTRR settings are changed to enable write combining, which causes the
PCI bus to burst data whenever the SCI mapped page hits a cache line
during copy operations -- speeds it up by 20-30% over DMA methods using
the same adapters.
I looked into this, and discovered that the gcc 2.96 compiler turned my
rep movsd code into a rep movsb (???) with some evil looking C++ style
jump table in the assembler code that jumped all over the place, which
is what caused the performance test numbers to drop. DMA numbers were
the same on both kernels with the dma_test benchmark -- they were not
with the sci_bench2 program.
They deviated by 30%, indicating that my MTRR write combining optimization
was not working properly in sci copy mode.
Jeff
On Wed, Feb 07, 2001 at 11:08:52AM -0700, Jeff V. Merkey wrote:
> Not supporting #ident for CVS managed code bases would see to
> me, at first glance, to be a show stopper to shipping a release
> of anything, since many folks need CVS support.
Could you please explain what you mean by not supporting #ident?
It works just fine for me in all our gcc packages I've checked.
Jakub
On Wed, Feb 07, 2001 at 12:32:13PM -0500, Jakub Jelinek wrote:
> On Wed, Feb 07, 2001 at 11:08:52AM -0700, Jeff V. Merkey wrote:
> > Not supporting #ident for CVS managed code bases would see to
> > me, at first glance, to be a show stopper to shipping a release
> > of anything, since many folks need CVS support.
>
> Could you please explain what you mean by not supporting #ident?
> It works just fine for me in all our gcc packages I've checked.
>
> Jakub
It returns an "unknown keyword" error message from the sci source base.
Offending source line is in /src/IRM/drv/src/prolog.h in version
1.1-7.
Jeff
Umm, I don't know what compiler you've got etc. Jeff, but I just tried gcc-2.96
(-69) here, and '#ident' is supported and works perfectly. The only way to even
get a warning is to use '-ansi -pedantic' which yields:
junk.c:1:2: warning: ISO C does not allow #ident
I don't think the problem is with gcc, at least not the Red Hat 7.0 version.
Tim
On Wed, Feb 07, 2001 at 11:31:47AM -0700, Jeff V. Merkey wrote:
> On Wed, Feb 07, 2001 at 12:32:13PM -0500, Jakub Jelinek wrote:
> > On Wed, Feb 07, 2001 at 11:08:52AM -0700, Jeff V. Merkey wrote:
> > > Not supporting #ident for CVS managed code bases would see to
> > > me, at first glance, to be a show stopper to shipping a release
> > > of anything, since many folks need CVS support.
> >
> > Could you please explain what you mean by not supporting #ident?
> > It works just fine for me in all our gcc packages I've checked.
> >
> > Jakub
>
> It returns an "unknown keyword" error message from the sci source base.
> Offending source line is in /src/IRM/drv/src/prolog.h in version
> 1.1-7.
>
> Jeff
>
>
>
> -
> 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/
--
Tim Wright - [email protected] or [email protected] or [email protected]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
> Hummm. Where are the patches for 2.4 to correct this? They are not posted
> with the 7.1 release. They need to be. The compiler not supporting
They don't need to be because the thing is just a warning. The kernel has
plenty of warnings and this one is 100% harmless.
> #ident for CVS is a show stopper, and needs correcting ASAP. How can
> someone use CVS properly with this, Alan?
Im using CVS all the time. Im not sure what the #ident thing would be. But
then like everyone else I know I use $ident in comments. JJ will probably
be glad to work on that one
Right now I'm down to one known problem with 2.96 and 2.4.x kernels - which
is that CVS gcc and 2.96 accidentally changed the ABI and broke the bitfield
assumptions in DAC960.c/h. JJ I believe just committed patches for that one
On Wed, Feb 07, 2001 at 07:02:26PM +0000, Alan Cox wrote:
> > Hummm. Where are the patches for 2.4 to correct this? They are not posted
> > with the 7.1 release. They need to be. The compiler not supporting
>
> They don't need to be because the thing is just a warning. The kernel has
> plenty of warnings and this one is 100% harmless.
>
> > #ident for CVS is a show stopper, and needs correcting ASAP. How can
> > someone use CVS properly with this, Alan?
>
> Im using CVS all the time. Im not sure what the #ident thing would be. But
> then like everyone else I know I use $ident in comments. JJ will probably
> be glad to work on that one
I sent him the code and he is running it down. It works great on
gcc 2.91.
Jeff
>
> Right now I'm down to one known problem with 2.96 and 2.4.x kernels - which
> is that CVS gcc and 2.96 accidentally changed the ABI and broke the bitfield
> assumptions in DAC960.c/h. JJ I believe just committed patches for that one
>
:-)
Jeff
> -
> 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/
> I looked into this, and discovered that the gcc 2.96 compiler turned my
> rep movsd code into a rep movsb (???) with some evil looking C++ style
If its hand coded asm then gcc shouldnt have touched it. If its an implicit
memcpy then gcc will generate inline code designed for main memory copying.
Do you have a small example chunk of code showing this ?
> They deviated by 30%, indicating that my MTRR write combining optimization
> was not working properly in sci copy mode.
That would explain the %age certainly. How it happened is the next question
On Wed, Feb 07, 2001 at 07:06:55PM +0000, Alan Cox wrote:
> > I looked into this, and discovered that the gcc 2.96 compiler turned my
> > rep movsd code into a rep movsb (???) with some evil looking C++ style
>
> If its hand coded asm then gcc shouldnt have touched it. If its an implicit
> memcpy then gcc will generate inline code designed for main memory copying.
>
> Do you have a small example chunk of code showing this ?
>
> > They deviated by 30%, indicating that my MTRR write combining optimization
> > was not working properly in sci copy mode.
>
> That would explain the %age certainly. How it happened is the next question
I'll gen some code, and send to you.
:-)
Jeff
> > That would explain the %age certainly. How it happened is the next question
>
> I'll gen some code, and send to you.
Thanks.
On Wed, Feb 07, 2001 at 10:37:19AM -0800, Tim Wright wrote:
> Umm, I don't know what compiler you've got etc. Jeff, but I just tried gcc-2.96
> (-69) here, and '#ident' is supported and works perfectly. The only way to even
> get a warning is to use '-ansi -pedantic' which yields:
> junk.c:1:2: warning: ISO C does not allow #ident
>
> I don't think the problem is with gcc, at least not the Red Hat 7.0 version.
>
> Tim
Try 7.1. This is where I got the errors. They are attached.
Jeff
> In file included from init.c:30:
> ../../prolog.h:344:8: invalid #ident
It doesnt say #ident isnt supported it says your use of it is invalid. What
precisely does that line read ?
On Wed, Feb 07, 2001 at 07:22:19PM +0000, Alan Cox wrote:
> > In file included from init.c:30:
> > ../../prolog.h:344:8: invalid #ident
>
> It doesnt say #ident isnt supported it says your use of it is invalid. What
> precisely does that line read ?
JJ tried it and it worked on some version he was running, but fails on
the 7.1 build. Here is the code that produces the offending messages.
I got an "invalid keyword" (sorry, it was not "unknown" but "invalid", that was
a different error message on gcc 2.96).
Jeff
On Wed, Feb 07, 2001 at 01:24:26PM -0700, Jeff V. Merkey wrote:
Larry,
Please provide to Alan Cox the exact versions and revision levels of
the RedHat 7.1 build used for the SCI testing. Please provide him
any other information he requests concerning the setup of this
system.
Jeff
> On Wed, Feb 07, 2001 at 07:22:19PM +0000, Alan Cox wrote:
> > > In file included from init.c:30:
> > > ../../prolog.h:344:8: invalid #ident
> >
> > It doesnt say #ident isnt supported it says your use of it is invalid. What
> > precisely does that line read ?
>
> JJ tried it and it worked on some version he was running, but fails on
> the 7.1 build. Here is the code that produces the offending messages.
> I got an "invalid keyword" (sorry, it was not "unknown" but "invalid", that was
> a different error message on gcc 2.96).
>
> Jeff
>
>
Larry Angus wrote:
This is the RedHat "fisher" beta, version 7.0.90 available from RedHat
the Kernel is: version 2.4.0-0.99.11
gcc is: version 2.96 release 71 (which came with fisher)
make is: version 3.79.1 release 5 (came with fisher)
glibc is: version 2.2.1 release 3 (also came with fisher)
for further info:
[email protected]
"Jeff V. Merkey" wrote:
> On Wed, Feb 07, 2001 at 01:24:26PM -0700, Jeff V. Merkey wrote:
>
> Larry,
>
> Please provide to Alan Cox the exact versions and revision levels of
> the RedHat 7.1 build used for the SCI testing. Please provide him
> any other information he requests concerning the setup of this
> system.
>
> Jeff
>
> > On Wed, Feb 07, 2001 at 07:22:19PM +0000, Alan Cox wrote:
> > > > In file included from init.c:30:
> > > > ../../prolog.h:344:8: invalid #ident
> > >
> > > It doesnt say #ident isnt supported it says your use of it is invalid. What
> > > precisely does that line read ?
> >
> > JJ tried it and it worked on some version he was running, but fails on
> > the 7.1 build. Here is the code that produces the offending messages.
> > I got an "invalid keyword" (sorry, it was not "unknown" but "invalid", that was
> > a different error message on gcc 2.96).
> >
> > Jeff
> >
> >