On Thu, Jul 14, 2005 at 02:25:43PM +0200, Arjan van de Ven wrote:
pure luck. NPTL threading uses it to store a pointer to per thread info
structure; other threading (linuxthreads) may have stored a pid there to
identify the internal thread. nptl is 2.6 only so you might have
switched
On Fri, Jul 08, 2005 at 06:42:53PM +0100, Alistair John Strachan wrote:
> > btw., which gcc version are you using?
>
> Not the GCC version known to bloat stacks ;-)
>
> 3.4.4, on both my machines. I'm not touching 4.x until 4.0.1 is released with
> the miscompiled-code fixes.
GCC 4.0.x bloats
On Fri, Jul 08, 2005 at 06:42:53PM +0100, Alistair John Strachan wrote:
btw., which gcc version are you using?
Not the GCC version known to bloat stacks ;-)
3.4.4, on both my machines. I'm not touching 4.x until 4.0.1 is released with
the miscompiled-code fixes.
GCC 4.0.x bloats stacks
On Thu, Jul 07, 2005 at 02:13:02PM +0200, Paolo Ornati wrote:
> You need to tell GCC to use "libmqueue"... something like this:
>
> gcc -Wall -O2 -o prog prog.c -lmqueue
If you have glibc 2.3.4 or later, you should use -lrt instead.
Jakub
-
To unsubscribe from this list: send the
On Thu, Jul 07, 2005 at 02:13:02PM +0200, Paolo Ornati wrote:
You need to tell GCC to use libmqueue... something like this:
gcc -Wall -O2 -o prog prog.c -lmqueue
If you have glibc 2.3.4 or later, you should use -lrt instead.
Jakub
-
To unsubscribe from this list: send the line
On Tue, Mar 29, 2005 at 05:37:06PM +0300, Denis Vlasenko wrote:
> typedef unsigned int size_t;
>
> static inline void * __memcpy(void * to, const void * from, size_t n)
> {
> int d0, d1, d2;
> __asm__ __volatile__(
> "rep ; movsl\n\t"
> "testb $2,%b4\n\t"
> "je 1f\n\t"
>
On Tue, Mar 29, 2005 at 05:37:06PM +0300, Denis Vlasenko wrote:
typedef unsigned int size_t;
static inline void * __memcpy(void * to, const void * from, size_t n)
{
int d0, d1, d2;
__asm__ __volatile__(
rep ; movsl\n\t
testb $2,%b4\n\t
je 1f\n\t
movsw\n
On Wed, Mar 23, 2005 at 05:12:59AM -0800, [EMAIL PROTECTED] wrote:
> the hang occurs during an attempted thread cancel+join. we know from
> strace that one thread calls tgkill() on the other. the other thread is
> blocked in a poll call on a FIFO. after tgkill, the first thread enters a
> futex
On Wed, Mar 23, 2005 at 05:12:59AM -0800, [EMAIL PROTECTED] wrote:
the hang occurs during an attempted thread cancel+join. we know from
strace that one thread calls tgkill() on the other. the other thread is
blocked in a poll call on a FIFO. after tgkill, the first thread enters a
futex wait,
On Tue, Mar 22, 2005 at 12:30:53AM -0500, Lee Revell wrote:
> On Mon, 2005-03-21 at 21:08 -0800, Andrew Morton wrote:
> > Jamie Lokier <[EMAIL PROTECTED]> wrote:
> > >
> > > The most recent messages under "Futex queue_me/get_user ordering",
>
On Tue, Mar 22, 2005 at 12:30:53AM -0500, Lee Revell wrote:
On Mon, 2005-03-21 at 21:08 -0800, Andrew Morton wrote:
Jamie Lokier [EMAIL PROTECTED] wrote:
The most recent messages under Futex queue_me/get_user ordering,
with a patch from Jakub Jelinek will fix this problem by changing
On Thu, Mar 17, 2005 at 03:20:31PM +, Jamie Lokier wrote:
> > [numerous instances of...]
> > + preempt_check_resched();
>
> Not required. The spin unlocks will do this.
Here is updated patch with those removed (all of them are preceeded
by spin_unlock) and out_unqueue label and following
On Thu, Mar 17, 2005 at 03:20:31PM +, Jamie Lokier wrote:
[numerous instances of...]
+ preempt_check_resched();
Not required. The spin unlocks will do this.
Here is updated patch with those removed (all of them are preceeded
by spin_unlock) and out_unqueue label and following unused
On Thu, Mar 17, 2005 at 03:20:31PM +, Jamie Lokier wrote:
> If you change futex_wait to be "atomic", and then have userspace locks
> which _depend_ on that atomicity, it becomes impossible to wait on
> multiple of those locks, or make poll-driven state machines which can
> wait on those locks.
On Thu, Nov 18, 2004 at 02:47:26PM -0500, Jakub Jelinek wrote:
> The scenario described in futex_wait-fix.patch IMHO can happen even
> if all calls to pthread_cond_signal are done with mutex held around it, i.e.
> A B X Y
> pthrea
On Thu, Nov 18, 2004 at 02:47:26PM -0500, Jakub Jelinek wrote:
The scenario described in futex_wait-fix.patch IMHO can happen even
if all calls to pthread_cond_signal are done with mutex held around it, i.e.
A B X Y
pthread_mutex_lock (mtx
On Thu, Mar 17, 2005 at 03:20:31PM +, Jamie Lokier wrote:
If you change futex_wait to be atomic, and then have userspace locks
which _depend_ on that atomicity, it becomes impossible to wait on
multiple of those locks, or make poll-driven state machines which can
wait on those locks.
The
On Thu, Feb 24, 2005 at 04:08:47PM +0100, Mikael Pettersson wrote:
> _However_, the 0k data message is due to a gcc-4.0 bug, and below
> you'll find a test program which illustrates it.
http://gcc.gnu.org/PR20196
Jakub
-
To unsubscribe from this list: send the line "unsubscribe
On Thu, Feb 24, 2005 at 04:08:47PM +0100, Mikael Pettersson wrote:
> /* gcc4bug.c
> * Written by Mikael Pettersson <[EMAIL PROTECTED]>, 2005-02-24.
...
Reproduced, thanks for the testcase. Looking into it...
Jakub
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Thu, Feb 24, 2005 at 04:08:47PM +0100, Mikael Pettersson wrote:
/* gcc4bug.c
* Written by Mikael Pettersson [EMAIL PROTECTED], 2005-02-24.
...
Reproduced, thanks for the testcase. Looking into it...
Jakub
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
On Thu, Feb 24, 2005 at 04:08:47PM +0100, Mikael Pettersson wrote:
_However_, the 0k data message is due to a gcc-4.0 bug, and below
you'll find a test program which illustrates it.
http://gcc.gnu.org/PR20196
Jakub
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Sat, Jan 29, 2005 at 01:31:46AM -0500, John Richard Moser wrote:
> Finally, although an NX stack is nice, you should probably take into
> account IBM's stack smash protector, ProPolice. Any attack that can
> evade SSP reliably can evade an NX stack; but ProPolice protects from
> other
On Sat, Jan 29, 2005 at 01:31:46AM -0500, John Richard Moser wrote:
Finally, although an NX stack is nice, you should probably take into
account IBM's stack smash protector, ProPolice. Any attack that can
evade SSP reliably can evade an NX stack; but ProPolice protects from
other overflows.
Hi!
Apparently all kernel scripts only have .rodata and not also .rodata.* input
sections in it.
This has been no problem so far, but since binutils and gcc support SHF_MERGE
sections (so that string constant (and other constant too) duplicates can be
removed at link time) the compiler creates
Hi!
There is a bug in binfmt_elf.c if the dynamic linker has non-zero base vaddr
(e.g. if it is prelinked). The issue is that in such case ld-linux.so.2 is
loaded at ELF_ET_DYN_BASE + p_vaddr instead of ELF_ET_DYN_BASE, on some
architectures into non-desirable places in virtual memory.
Best
Hi!
There is a bug in binfmt_elf.c if the dynamic linker has non-zero base vaddr
(e.g. if it is prelinked). The issue is that in such case ld-linux.so.2 is
loaded at ELF_ET_DYN_BASE + p_vaddr instead of ELF_ET_DYN_BASE, on some
architectures into non-desirable places in virtual memory.
Best
Hi!
Apparently all kernel scripts only have .rodata and not also .rodata.* input
sections in it.
This has been no problem so far, but since binutils and gcc support SHF_MERGE
sections (so that string constant (and other constant too) duplicates can be
removed at link time) the compiler creates
On Tue, Apr 24, 2001 at 11:46:20AM -0500, Tom Brusehaver (N-Sysdyne Corporation) wrote:
>
> I have been chasing all around trying to find out why
> shm_open always returns ENOSYS. It is implemented
> in glibc-2.2.2, and seems the 2.4.3 kernel knows about
> shmfs.
>
> It seems the file
On Tue, Apr 10, 2001 at 03:11:05AM -0700, Dawson Engler wrote:
> As a side question: is it still true that verify_area's must be done before
> any use of __put_user/__get_user/__copy_from_user/etc?
I believe so, at least in generic code.
In architecture specific code (non-i386) it is usually
On Tue, Apr 10, 2001 at 03:11:05AM -0700, Dawson Engler wrote:
As a side question: is it still true that verify_area's must be done before
any use of __put_user/__get_user/__copy_from_user/etc?
I believe so, at least in generic code.
In architecture specific code (non-i386) it is usually
On Mon, Apr 02, 2001 at 09:54:25AM -0300, Gustavo Niemeyer wrote:
> Hi Richard! Hi Dennis!
>
> > I tracked this down to a corrupt jumptable somewhere in the pthreads
> > part of the libc (didnt have the source handy at that time, though). So
> > I think this is a libc bug (version does not
On Mon, Apr 02, 2001 at 09:54:25AM -0300, Gustavo Niemeyer wrote:
Hi Richard! Hi Dennis!
I tracked this down to a corrupt jumptable somewhere in the pthreads
part of the libc (didnt have the source handy at that time, though). So
I think this is a libc bug (version does not matter) - I
On Mon, Feb 26, 2001 at 05:15:28PM +, Alan Cox wrote:
> > I think I heve found a bug in gcc. I have tried both egcs 1.1.2 (gcc
> > 2.91.66) and gcc 2.95.2 versions.
> >
> > I am attaching you a simplified test program ('bug.c', a really simple
> > program).
>
> Well gcc-bugs would be the
On Tue, Feb 20, 2001 at 02:51:24PM +1300, Chris Wedgwood wrote:
> Why isn't there a sendfile64?
>
> because nobody has implemented on -- arguably it's not needed; the
> different between:
>
> sendfile64(...)
>
> and
>
> while(blah){
> sendfile( ... 1G or so ...)
On Tue, Feb 20, 2001 at 02:51:24PM +1300, Chris Wedgwood wrote:
Why isn't there a sendfile64?
because nobody has implemented on -- arguably it's not needed; the
different between:
sendfile64(...)
and
while(blah){
sendfile( ... 1G or so ...)
}
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
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
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&<0;i++)if((1UL< >
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;i10j0;i++)if((1ULi)==n)j=i;if(j0)exit(0);}main(){f(64);exit(1);}'
test.c
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
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 is
On Tue, Jan 16, 2001 at 10:05:06AM -0500, David L. Parsley wrote:
> Felix von Leitner wrote:
> > > close (0);
> > > close (1);
> > > close (2);
> > > open ("/dev/console", O_RDWR);
> > > dup ();
> > > dup ();
> >
> > So it's not actually part of POSIX, it's just to get around fixing
On Tue, Jan 16, 2001 at 10:05:06AM -0500, David L. Parsley wrote:
Felix von Leitner wrote:
close (0);
close (1);
close (2);
open ("/dev/console", O_RDWR);
dup ();
dup ();
So it's not actually part of POSIX, it's just to get around fixing
legacy code? ;-)
On Fri, Dec 29, 2000 at 10:54:38AM +0100, Ulrich Windl wrote:
> Hello,
>
> I noticed (with some inspiration from Andy Kleen) that some asm()
> instructions for the ia32 use the "g" constraint for "mull", where my
> Intel 386 Assembly Language Manual suggests the "MUL" instruction needs
> an
On Fri, Dec 29, 2000 at 10:54:38AM +0100, Ulrich Windl wrote:
Hello,
I noticed (with some inspiration from Andy Kleen) that some asm()
instructions for the ia32 use the "g" constraint for "mull", where my
Intel 386 Assembly Language Manual suggests the "MUL" instruction needs
an r/m
On Thu, Dec 14, 2000 at 11:11:28AM -0800, Linus Torvalds wrote:
> user applications and (b) gcc-2.96 is so broken that it requires special
> libraries for C++ vtable chunks handling that is different, so the
> _working_ gcc can only be used with programs that do not need such
> library support.
On Thu, Dec 14, 2000 at 04:42:03AM -0800, Clayton Weaver wrote:
> There has a been a thread on the teTeX mailing list the last few days
> about a (RedHat, but probably more general than just their rpms)
> gcc-2.9.6 w/glibc-2.2.x bug. At -O2, it can miscompile
>
> unsigned varname; /* "unsigned
On Thu, Dec 14, 2000 at 04:42:03AM -0800, Clayton Weaver wrote:
There has a been a thread on the teTeX mailing list the last few days
about a (RedHat, but probably more general than just their rpms)
gcc-2.9.6 w/glibc-2.2.x bug. At -O2, it can miscompile
unsigned varname; /* "unsigned int
On Thu, Dec 14, 2000 at 11:11:28AM -0800, Linus Torvalds wrote:
user applications and (b) gcc-2.96 is so broken that it requires special
libraries for C++ vtable chunks handling that is different, so the
_working_ gcc can only be used with programs that do not need such
library support.
On Mon, Nov 27, 2000 at 05:48:28PM +0100, Jes Sorensen wrote:
> > "Keith" == Keith Owens <[EMAIL PROTECTED]> writes:
>
> Keith> On Sun, 26 Nov 2000 16:36:55 -0700, "Jeff V. Merkey"
> Keith> <[EMAIL PROTECTED]> wrote:
> >> Keith,
> >>
> >> Please consider the attached patch for inclusion in
On Mon, Nov 27, 2000 at 05:48:28PM +0100, Jes Sorensen wrote:
"Keith" == Keith Owens [EMAIL PROTECTED] writes:
Keith On Sun, 26 Nov 2000 16:36:55 -0700, "Jeff V. Merkey"
Keith [EMAIL PROTECTED] wrote:
Keith,
Please consider the attached patch for inclusion in all future
versions of
On Mon, Nov 27, 2000 at 09:54:57AM +1100, Keith Owens wrote:
> On Sun, 26 Nov 2000 07:30:44 -0800,
> "Adam J. Richter" <[EMAIL PROTECTED]> wrote:
> > In reading include/linux/init.h, I was surprised to discover
> >that __init{,data} expands to nothing when compiling a module.
> >I was
On Mon, Nov 27, 2000 at 09:54:57AM +1100, Keith Owens wrote:
On Sun, 26 Nov 2000 07:30:44 -0800,
"Adam J. Richter" [EMAIL PROTECTED] wrote:
In reading include/linux/init.h, I was surprised to discover
that __init{,data} expands to nothing when compiling a module.
I was wondering if
On Fri, Nov 24, 2000 at 06:20:33AM +0100, [EMAIL PROTECTED] wrote:
> >> ... RedHat's GCC snapshot "2.96" handles this case just fine.
>
> > Now, if you can isolate the relevant part of the diff between
> > 2.95.2 and RH 2.96...
>
> Maybe I have to be more precise in the statement "gcc 2.95.2 is
On Fri, Nov 24, 2000 at 06:20:33AM +0100, [EMAIL PROTECTED] wrote:
... RedHat's GCC snapshot "2.96" handles this case just fine.
Now, if you can isolate the relevant part of the diff between
2.95.2 and RH 2.96...
Maybe I have to be more precise in the statement "gcc 2.95.2 is buggy".
On Tue, Nov 21, 2000 at 06:02:35AM -0600, Peter Samuelson wrote:
>
> While trying to clean up some code recently (CONFIG_MCA, hi Jeff), I
> discovered that gcc 2.95.2 (i386) does not remove dead string
> constants:
>
> void foo (void)
> {
> if (0)
> printk(KERN_INFO "bar");
> }
On Tue, Nov 21, 2000 at 06:02:35AM -0600, Peter Samuelson wrote:
While trying to clean up some code recently (CONFIG_MCA, hi Jeff), I
discovered that gcc 2.95.2 (i386) does not remove dead string
constants:
void foo (void)
{
if (0)
printk(KERN_INFO "bar");
}
On Sun, Nov 19, 2000 at 07:24:16PM +0900, GOTO Masanori wrote:
> At Mon, 13 Nov 2000 11:13:19 -0500,
> Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> > ago were done in the kernel, POSIX message queue passing is not doable in
> > userland without kernel help either (I have a
On Sun, Nov 19, 2000 at 07:24:16PM +0900, GOTO Masanori wrote:
At Mon, 13 Nov 2000 11:13:19 -0500,
Jakub Jelinek [EMAIL PROTECTED] wrote:
ago were done in the kernel, POSIX message queue passing is not doable in
userland without kernel help either (I have a message queue filesystem
kernel
On Tue, Nov 14, 2000 at 10:42:41AM +, Malcolm Beattie wrote:
> Keith Owens writes:
> > All these patches against request_module are attacking the problem at
> > the wrong point. The kernel can request any module name it likes,
> > using any string it likes, as long as the kernel generates
On Tue, Nov 14, 2000 at 10:42:41AM +, Malcolm Beattie wrote:
Keith Owens writes:
All these patches against request_module are attacking the problem at
the wrong point. The kernel can request any module name it likes,
using any string it likes, as long as the kernel generates the name.
On Mon, Nov 13, 2000 at 11:00:09AM -0500, Jeff Garzik wrote:
> [EMAIL PROTECTED] wrote:
> > Sorry if this is a FAQ, but I've searched the archives for this list
> > (http://www.uwsg.iu.edu/hypermail/linux/kernel/) and only come with references
> > from 1996!
> >
> > What is the state of
On Mon, Nov 13, 2000 at 11:00:09AM -0500, Jeff Garzik wrote:
[EMAIL PROTECTED] wrote:
Sorry if this is a FAQ, but I've searched the archives for this list
(http://www.uwsg.iu.edu/hypermail/linux/kernel/) and only come with references
from 1996!
What is the state of Posix-compliant
On Sun, Nov 05, 2000 at 01:52:24PM -0700, Tim Riker wrote:
> Alan,
>
> Perhaps I did not explain myself, or perhaps I misunderstand your
> comments. I was responding to a comment that we could just copy some of
> the optimizations from Pro64 over into gcc.
That's hard to do, because the whole
On Sun, Nov 05, 2000 at 01:52:24PM -0700, Tim Riker wrote:
Alan,
Perhaps I did not explain myself, or perhaps I misunderstand your
comments. I was responding to a comment that we could just copy some of
the optimizations from Pro64 over into gcc.
That's hard to do, because the whole gcc
On Wed, Nov 01, 2000 at 04:54:18PM -0700, Cort Dougan wrote:
> Since you're setting yourself up as a proponent of this can you explain why
> RedHat includes a compiler that doesn't work with the kernel? Don't get
It actually does not compile only 2.2 kernels unless they are patched (the
patches
On Wed, Nov 01, 2000 at 04:54:18PM -0700, Cort Dougan wrote:
Since you're setting yourself up as a proponent of this can you explain why
RedHat includes a compiler that doesn't work with the kernel? Don't get
It actually does not compile only 2.2 kernels unless they are patched (the
patches
On Mon, Oct 30, 2000 at 05:50:07PM -0300, Horst von Brand wrote:
> Martin Dalecki <[EMAIL PROTECTED]> said:
> > Peter Samuelson wrote:
>
> [...]
>
> > > * Red Hat "2.96" or CVS 2.97 will probably break any known kernel.
>
> > Works fine for me and 2.4.0-test10-pre5... however there are tons of
On Mon, Oct 30, 2000 at 03:01:16PM +0100, Martin Dalecki wrote:
> Horst von Brand wrote:
> >
> > Red Hat 7.0, i686, gcc-20001027 (Yes, I know. Just to flush out bugs on
> > both sides).
> >
> > abs() is used at least in:
> >
> > arch/i386/kernel/time.c
> > drivers/md/raid1.c
> >
On Mon, Oct 30, 2000 at 03:01:16PM +0100, Martin Dalecki wrote:
Horst von Brand wrote:
Red Hat 7.0, i686, gcc-20001027 (Yes, I know. Just to flush out bugs on
both sides).
abs() is used at least in:
arch/i386/kernel/time.c
drivers/md/raid1.c
drivers/sound/sb_ess.c
gcc
On Mon, Oct 30, 2000 at 05:50:07PM -0300, Horst von Brand wrote:
Martin Dalecki [EMAIL PROTECTED] said:
Peter Samuelson wrote:
[...]
* Red Hat "2.96" or CVS 2.97 will probably break any known kernel.
Works fine for me and 2.4.0-test10-pre5... however there are tons of
On Mon, Oct 23, 2000 at 12:06:31PM +, David Wragg wrote:
> Gregory Maxwell <[EMAIL PROTECTED]> writes:
> > If 2.96 is broken, I'd appreciate it if you would describe the breakage.
>
> As in the RedHat 2.96? Try compiling the following on RedHat 7.0 x86
> with "gcc -O2" and take a look at
On Mon, Oct 23, 2000 at 12:06:31PM +, David Wragg wrote:
Gregory Maxwell [EMAIL PROTECTED] writes:
If 2.96 is broken, I'd appreciate it if you would describe the breakage.
As in the RedHat 2.96? Try compiling the following on RedHat 7.0 x86
with "gcc -O2" and take a look at the
On Fri, Oct 13, 2000 at 02:17:23PM -0700, Richard Henderson wrote:
> On Fri, Oct 13, 2000 at 12:45:47PM +0100, Alan Cox wrote:
> > Can we always be sure the rss will fit in an atomic_t - is it > 32bits on the
> > ultrsparc/alpha ?
>
> It is not.
It is not even 32bit on sparc32 (24bit only).
On Thu, Oct 12, 2000 at 11:38:11AM -0400, Yong Chi wrote:
> Hopefully this will do for SMP locks. =)
Holding a spinlock for this long (especially when you might sleep there in two
places (interruptible_sleep_on, put_user)) is basically a bad idea.
spinlocks are designed to be holded only for
On Thu, Oct 12, 2000 at 11:38:11AM -0400, Yong Chi wrote:
Hopefully this will do for SMP locks. =)
Holding a spinlock for this long (especially when you might sleep there in two
places (interruptible_sleep_on, put_user)) is basically a bad idea.
spinlocks are designed to be holded only for
On Tue, Oct 10, 2000 at 11:32:43PM -0500, Gnea wrote:
>
> On Tue, 10 Oct 2000 19:56:46 -0400 (EDT), jamal blurted forth:
>
> >
> > Ted,
> >
> > Please add this to your list. Linux is unusable in these machines.
> > I have cc'ed Martin and Linus because they play in that PCI area.
>
>
On Tue, Oct 10, 2000 at 11:32:43PM -0500, Gnea wrote:
On Tue, 10 Oct 2000 19:56:46 -0400 (EDT), jamal blurted forth:
Ted,
Please add this to your list. Linux is unusable in these machines.
I have cc'ed Martin and Linus because they play in that PCI area.
erm, looking at
On Tue, Oct 03, 2000 at 11:12:24PM -0700, [EMAIL PROTECTED] wrote:
> No, better yet,
> what is a good version to use when porting to a new processor (actually
> an old processor)? I've pulled the source to gcc (2.95.2) and binutils
> (2.10) in prep for a port to a new/old machine. If these
On Tue, Oct 03, 2000 at 11:12:24PM -0700, [EMAIL PROTECTED] wrote:
No, better yet,
what is a good version to use when porting to a new processor (actually
an old processor)? I've pulled the source to gcc (2.95.2) and binutils
(2.10) in prep for a port to a new/old machine. If these versions
On Tue, Oct 03, 2000 at 10:41:57PM -0700, Dr. Kelsey Hudson wrote:
> > Question is, is this still broken on -test9-final or did
> > the fix Linus merged earlier today get rid of your problems?
>
> Let me try this and find out...
...
> making dep...
>
> ::curses his SS20 for being so SLOW!::
> I
On Fri, Sep 29, 2000 at 11:09:33AM +, Stephen Torri wrote:
> I get the following message compiling 2.4.0-test6 or test8 on a RedHat 7
> system. "/usr/src/linux/include/asm/apic.h:13:29: warning: nothing can be
> posted after this token". Is this an issue with apic?
Yes, this one is apic.h
On Fri, Sep 29, 2000 at 11:09:33AM +, Stephen Torri wrote:
I get the following message compiling 2.4.0-test6 or test8 on a RedHat 7
system. "/usr/src/linux/include/asm/apic.h:13:29: warning: nothing can be
posted after this token". Is this an issue with apic?
Yes, this one is apic.h bug
On Tue, Oct 03, 2000 at 10:41:57PM -0700, Dr. Kelsey Hudson wrote:
Question is, is this still broken on -test9-final or did
the fix Linus merged earlier today get rid of your problems?
Let me try this and find out...
...
making dep...
::curses his SS20 for being so SLOW!::
I need
On Tue, Sep 26, 2000 at 05:42:59PM +0200, Mads Martin Joergensen wrote:
> * Timur Tabi <[EMAIL PROTECTED]> [Sep 26. 2000 17:36]:
> > > Maybe this can be fixed for 2.96, but it breaks badly elsewhere (doesn't
> > > compile; kernel builds but hangs/crashes at boot; kernel appears to work
> > > fine
On Tue, Sep 26, 2000 at 08:20:49AM +0200, Michael N. Lipp wrote:
> Hi,
>
> I can't compile the latest linux kernel with the latest gcc due to a
> strange define in checksum.S. The gcc preprocessor complains about
> the usage of elipses in the macros
>
> #define SRC(y...) \
>
On Tue, Sep 26, 2000 at 05:42:59PM +0200, Mads Martin Joergensen wrote:
* Timur Tabi [EMAIL PROTECTED] [Sep 26. 2000 17:36]:
Maybe this can be fixed for 2.96, but it breaks badly elsewhere (doesn't
compile; kernel builds but hangs/crashes at boot; kernel appears to work
fine while it is
On Tue, Sep 12, 2000 at 03:12:34PM +0100, Alan Cox wrote:
> > I need support for files larger than 2GB. What's the status for that ?
>
> 2.2 + patches or 2.4 test and glibc 2.1.9x
And make sure the utilities you want to work with those 2GB+ files were
compiled with -D_FILE_OFFSET_BITS=64
On Tue, Sep 12, 2000 at 03:12:34PM +0100, Alan Cox wrote:
I need support for files larger than 2GB. What's the status for that ?
2.2 + patches or 2.4 test and glibc 2.1.9x
And make sure the utilities you want to work with those 2GB+ files were
compiled with -D_FILE_OFFSET_BITS=64 (check
On Thu, Sep 07, 2000 at 08:53:29AM +1100, Keith Owens wrote:
> On Wed, 6 Sep 2000 21:49:44 +0100 (BST),
> Alan Cox <[EMAIL PROTECTED]> wrote:
> >Use a different gcc. There are reasons people shipping 2.96 for intel x86 also
> >include egcs. The kernel isnt ready for 2.96
>
> Out of curiousity,
On Wed, Sep 06, 2000 at 10:05:46PM +0200, [EMAIL PROTECTED] wrote:
>
> I'm trying to compile 2.2.17 with gcc 2.96, and it shows a lot of
> warnings like this in several files.
First of all, you should not use gcc 2.96 for 2.2.x kernel compiles, only
2.4 should work.
> warning: pasting would
On Thu, Sep 07, 2000 at 08:53:29AM +1100, Keith Owens wrote:
On Wed, 6 Sep 2000 21:49:44 +0100 (BST),
Alan Cox [EMAIL PROTECTED] wrote:
Use a different gcc. There are reasons people shipping 2.96 for intel x86 also
include egcs. The kernel isnt ready for 2.96
Out of curiousity, which
201 - 292 of 292 matches
Mail list logo
