is this a bug?

is this a bug?

Post by J Sloa » Thu, 09 Aug 2001 12:30:08




> It's a bug in that screwed up compiler redhat shipped with 7.1.

Oh please, not this FUD again.....

jjs

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

is this a bug?

Post by Dr. Kelsey Hudso » Thu, 09 Aug 2001 12:50:06




> > It's a bug in that screwed up compiler redhat shipped with 7.1.
> Oh please, not this FUD again.....

Call it what you wish -- But, if I see something break when using a
certain compiler option versus another compiler option that does not
cause a break, chances are it's a bug in the compiler. After all, the
Athlon support *is* a new feature, is it not?

I don't even know why I bothered replying. Don't feed the trolls... Gotta
watch for those signs....


 Software Engineer
 Compendium Technologies, Inc                               (619) 725-0771
---------------------------------------------------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

is this a bug?

Post by David Weinehal » Thu, 09 Aug 2001 20:00:11





> > > It's a bug in that screwed up compiler redhat shipped with 7.1.

> > Oh please, not this FUD again.....

> Call it what you wish -- But, if I see something break when using a
> certain compiler option versus another compiler option that does not
> cause a break, chances are it's a bug in the compiler. After all, the
> Athlon support *is* a new feature, is it not?

> I don't even know why I bothered replying. Don't feed the trolls... Gotta
> watch for those signs....

Ah, but if you'd been observant you'd have noticed what kind of motherboard
he has (a VIA) and if you have been reading your kernel-list lately,
you'd have known that almost noone has been able to get a Athlon-optimized
kernel to work in a stable manner on those; probably because of the
Athlon-optimizations stressing the hardware too much.

I'd say flakey hardware is the problem here, not the compiler.

/David Weinehall
  _                                                                 _

//  Project MCA Linux hacker        //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

is this a bug?

Post by Alan Co » Thu, 09 Aug 2001 20:10:10


Quote:> > cputype=Athlon I continiusly experienced this crash.When I compiled with
> > cputype=i686 everything went smooth (OS is Redhat 7.1)

> It's a bug in that screwed up compiler redhat shipped with 7.1. AFAIK, the
> only difference between an athlon-specific kernel and an i686-specific
> kernel are the options in the compiler command line when compiling the
> kernel.

Please stop deliberately spreading misinformation. The last thing an end
user with a problem needs is a bigot with an axe to grind lying to them to
make a political point.

Its the classic 'bought the wrong VIA chipset mainboard' problem

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

is this a bug?

Post by Ron Flor » Thu, 09 Aug 2001 22:10:08




> > As you will see in the attached file (it's a dmesg from the boot)
> > I have an 1Ghz athlon cpu with a VIA KT133 on a gigabyte GA-7ZX
> > motherboard with 100mhz SDRAM.When I compiled the kernel with
> > cputype=Athlon I continiusly experienced this crash.When I compiled with
> > cputype=i686 everything went smooth (OS is Redhat 7.1)

> It's a bug in that screwed up compiler redhat shipped with 7.1. AFAIK, the
> only difference between an athlon-specific kernel and an i686-specific
> kernel are the options in the compiler command line when compiling the
> kernel.

 RH has posted updates to many of the gcc-xxx tools, have you installed
the updated compilers and libraries ?

ron
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

is this a bug?

Post by Eric W. Biederm » Sat, 11 Aug 2001 18:30:10



> I have the same motherboard, same chipset, same CPU and the same crash.
> No memory test cpu burn UDMA on/off, replace or remove of components
> did any good.
> Then i replaced the 100mhz SDRAM with a 133mhz and it is 100 % stable since
> then.

> No matter which compiler, kernel version, cputype.
> It simply works now.

Do you happen to have the SDRAM timings of the two sets of DIMMS?
It would be interesting to see what changed besides the clock speed on
the DIMMS.  I'm assuming your PC133 DIMMs are running at at 133Mhz,
and you aren't over clocking anything.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

is this a bug?

Post by Eric W. Biederm » Sun, 12 Aug 2001 01:40:06



> Hi Eric

> The CPU is a 1.1GHz tbird 200MHz FSB and i am running it this way.
> The motherboard can do 100 and 133 MHz but i run
> the SDRAM at 100MHz from the beginning, since i have seen lot's
> of boards with memory problems and i wanted to be on the good side.
> Both, the old 128MB and the new 256MB SDRAM where sold as PC133.
> It is a single DIMM in both cases.

> When i started to sue the SDRAM for the trouble i checked the SPD and found
> the 128MB-PC133 was actually a PC100 with a few steps towards PC66 (major
> brand).

> So i tried a new one that, at least from the SPD, is a real PC133 and suddenly
> ...

> I have tried to kill it

> kernel 2.4.7-xfs from cvs at the moment
> athlon optimisations
> UDMA on ide0 and ide1
> 2 harddrives, 1 cdrom, 1 cd/rw

> since then, but it works, works, works.

> This weekend does not see me at home.
> I will send the timings on sunday/monday.

> What do you expect to get out of this ?

Mostly I am curious about what is going on.  I work on linuxBIOS so
(a) I might just have to figure out if there are software work arounds
    if/when I port to this platform.
(b) I have written enough memory setup code that does SPD on the fly,
    to compute the DIMM timings, that understanding DIMMS and memory
    controllers is one of my areas of competence.

If the ram was really PC100 mislabeled, as PC133 and it was being run
at 133Mhz I can see the problem.  If it was only being run as PC100
I have a problem seeing, why you would have a problem.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. bug in thr_keycreate ? or am I clueless ?

Hi there. I've been working with the solaris thread package and I'm having
some problems with the thr_keycreate function call. This function is used
to create thread specific data. The arguments are a pointer to a  thread_key_t
variable where the created key will be stored and a pointer to a destrucutor
function call. It seems however that thr_keycreate only works properly if
the  thread_key_t is initialized to 0. If it's not then no key will
be created but the function call will not return any error. There is
(to my knowledge) no reference to this kind of beahviour in the manuals, so
is this a bug a feature or am I missing something here ?

The progam below ilustrates what I mean.

The output is :

   Error x1: 22 (EINVAL = 22)
   Error x2: 22 (EINVAL = 22)

and the compile line is :

   cc -g -D _REENTRANT create_thread.c -lthread

I know that  thread_key_t are supposed to be globals and in that case
we can count on them be initialized to 0 ( can we ?) but what if
we want to allocate memory to the key at run time ? do we have to
iniatialize it ?

Thanks for reading

#include <thread.h>
#include <stdlib.h>
#include <errno.h>

main ()
{  

  int ret;
  int data1 = 12345678;
  int data2 = 22345678;
  int data3 = 32345678;
  int data4 = 42345678;

  thread_key_t k1 = 0 , k2 = 0;
  thread_key_t x1 = -1 , x2 = -11;

  ret = thr_keycreate (&k1, NULL);
  ret = thr_setspecific (k1,&data1);
  if (ret != 0)
    printf ("Error k1: %d (EINVAL = %d)\n", ret, EINVAL);

  ret = thr_keycreate (&k2, NULL);
  ret = thr_setspecific (k2,&data2);
  if (ret != 0)
    printf ("Error k2: %d (EINVAL = %d)\n", ret, EINVAL);

  ret = thr_keycreate (&x1, NULL);
  ret = thr_setspecific (x1,&data3);
  if (ret != 0)
    printf ("Error x1: %d (EINVAL = %d)\n", ret, EINVAL);

  ret = thr_keycreate (&x2, NULL);
  ret = thr_setspecific (x2,&data4);
  if (ret != 0)
    printf ("Error x2: %d (EINVAL = %d)\n", ret, EINVAL);

2. News Server @ Sun?

3. Bug in cardbus initialization, or am I missing something?

4. VME & CompactPCI Solaris Drivers

5. Is this a bug or am I ...

6. Newbie: XF86Setup "cant load library"

7. Am I stupid or is this a bug in gcc ?

8. Pro Audio Spectrum 16 SCSI

9. am-utils or kernel bug ?

10. Did I find a bug in egrep or am I misreading the man page?

11. ipchains BUG?? or Am I losing it?

12. syslog full of kernel BUGs - why am I being ignored?

13. Is this a bug or am I loosing it....