2.4.0-test5 builds fine here. try 'make clean' then 'make config' and
make certain you don't have any of your previous Linux's files in the
same tree (i.e. make certain you did not overwrite an existing tree and
might be pointing to an invalid .config file or something).
:-)
Jeff
"Jeff V. Merkey" wrote:
>
> Yipes! Let me try to build the latest and see what happenes. You may
> want to try an earlier 2.4.X-test if this one's busted -- the
> lead(bleed)ing edge you know ....
>
> :-)
>
> Jeff
>
> marek@foundmoney.com wrote:
> >
> > To make matters worse, I downloaded 2.4.test5 to see how many more clients I can bench
> > press against this box, but
> >
> > I get this when I do make bzImage ( I did do make menuconfig and make dep before
> > ofcourse)
> >
> > gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
> > -fomit-frame-pointer -pipe -march=i686 -fno-strict-aliasing -c -o tdfx_drv.o
> > tdfx_drv.c
> > tdfx_drv.c: In function `tdfx_lock':
> > tdfx_drv.c:626: structure has no member named `priority'
> > tdfx_drv.c:626: `DEF_PRIORITY' undeclared (first use in this function)
> > tdfx_drv.c:626: (Each undeclared identifier is reported only once
> > tdfx_drv.c:626: for each function it appears in.)
> > tdfx_drv.c: In function `tdfx_unlock':
> > tdfx_drv.c:672: structure has no member named `priority'
> > tdfx_drv.c:672: `DEF_PRIORITY' undeclared (first use in this function)
> > make[4]: *** [tdfx_drv.o] Error 1
> > make[4]: Leaving directory `/usr/src/linux/drivers/char/drm'
> > make[3]: *** [first_rule] Error 2
> > make[3]: Leaving directory `/usr/src/linux/drivers/char/drm'
> > make[2]: *** [_subdir_drm] Error 2
> > make[2]: Leaving directory `/usr/src/linux/drivers/char'
> > make[1]: *** [_subdir_char] Error 2
> > make[1]: Leaving directory `/usr/src/linux/drivers'
> > make: *** [_dir_drivers] Error 2
> >
> > "Jeff V. Merkey" wrote:
> >
> > > I stand corrected. Looks like smbfs in 2.2.X uses a long long *
> > > (loff_t) so this should work.
> > >
> > > :-)
> > >
> > > Jeff
> > >
> > > "Jeff V. Merkey" wrote:
> > > >
> > > > Alan Cox wrote:
> > > > >
> > > > > > Dear Al, Linus, and Alan -- 2GB liit is probably something to look at
> > > > > > expanding in the future to support these huge SQL server database files.
> > > > >
> > > > > Indeed. Thats why there are 2.2 patches and 2.4test already zapped it. I think
> > > > > the limit is now about 1Tb for a file and hit due to block layer limits
> > > >
> > > > But not for everything. The 2.2.X VFS is limited to 2GB (since the fs
> > > > drivers were coded this way). I treat the off_t field as an unsigned
> > > > long so I'm at 4GB. 2.4.X does support big files, but this guy was
> > > > asking about "commercial" linux distributions he could get his hands on,
> > > > and most folks are still on 2.2.X. Some of the FS drivers treat this
> > > > field as a signed long in 2.2.X.
> > > >
> > > > I've known about the LargeFS patches for some time, but do they, for
> > > > example, let someone using ncpfs read and write a 4GB file on a NetWare
> > > > server? No, they don't because the read() and write() functions are
> > > > limited to 2GB in 2.2.X. This support is for EXT% variants and isn't
> > > > global across all the fs's. He has to get the data to the system
> > > > somehow, and it's a good bet he will be using a network to do it. Which
> > > > client can support copying of a 3.4GB file on Linux in the question--
> > > > SMBFS since it's an NT server -- I don't think so? Since the VFS is
> > > > limited to 2GB, I guess he can install large FS support, then stare at
> > > > the system and wonder how to get the file onto it.
> > > >
> > > > :-)
> > > >
> > > > Jeff
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.rutgers.edu
> > Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:35 EST