Re: Compile error: DRM without AGP in 2.4.0
On Thursday, 11. January 2001 19:18, Matthew D. Pitts wrote: > Robert, > > > On Thu, 11 Jan 2001, Giacomo Catenazzi spoke: > > > Here a valid configuration (no AGP, but all DRM set) > > > compiling [2.4.0]: > > > [...] > > > > DRM requires AGPGART. > > What if your motherboard doesn't have an AGP slot? I'm running an older > Micro Star pentium with a ATI All-in-Wonder with the Rage 128 chipset. > > Matthew > [EMAIL PROTECTED] Hi, then you are out of luck, until the pcigart is finished. Or use another vidcard like the voodoo. IMHO they don't need AGPGART. Greetings, Michael - 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: Compile error: DRM without AGP in 2.4.0
On Thursday, 11. January 2001 19:18, Matthew D. Pitts wrote: Robert, On Thu, 11 Jan 2001, Giacomo Catenazzi spoke: Here a valid configuration (no AGP, but all DRM set) compiling [2.4.0]: [...] DRM requires AGPGART. What if your motherboard doesn't have an AGP slot? I'm running an older Micro Star pentium with a ATI All-in-Wonder with the Rage 128 chipset. Matthew [EMAIL PROTECTED] Hi, then you are out of luck, until the pcigart is finished. Or use another vidcard like the voodoo. IMHO they don't need AGPGART. Greetings, Michael - 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/
is there something odd in the aic7xxx driver ?
Hi all, I am experiencing problem with the latest test kernels and my adaptec 2940uw and one ibm hdd. Thing is that during times the machine simply reboots without apparent reasons. Nothing shows up, to my knowledge in /var/log or other places. This is with the kernel compiled with gcc 2.95.2 on debian woody. Using Gibbs respectively the adaptec driver I haven't had this behaviour in weeks, or better to say, not once. The machine is up 24/7 but not under very high load. The times it failed have mostly been under more or less heavy i/o like compiling several kernels at a time. Are others experiencing similar behaviours ? Greetings Michael Meding System is kt-133 with mga g400, duron800 adaptec 2940uw with latest bios. Further information upon request. - 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/
is there something odd in the aic7xxx driver ?
Hi all, I am experiencing problem with the latest test kernels and my adaptec 2940uw and one ibm hdd. Thing is that during times the machine simply reboots without apparent reasons. Nothing shows up, to my knowledge in /var/log or other places. This is with the kernel compiled with gcc 2.95.2 on debian woody. Using Gibbs respectively the adaptec driver I haven't had this behaviour in weeks, or better to say, not once. The machine is up 24/7 but not under very high load. The times it failed have mostly been under more or less heavy i/o like compiling several kernels at a time. Are others experiencing similar behaviours ? Greetings Michael Meding System is kt-133 with mga g400, duron800 adaptec 2940uw with latest bios. Further information upon request. - 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: aic7xxx version status for 2.4.0test ? -- ignore last post
Hi all, sorry, next time I should at least do sanity checks on my own email. Of course 5.2.1 as in latest-test is newer than 5.1.something. Just did a quick look in the source and on Dougs site and mixed the version numbers up. Stupid me! Greetings, Michael Meding - 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/
aic7xxx version status for 2.4.0test ?
Hi all, am I right that the aic7xx version in latest test is 5.2.1 ? Is there a reason why this is not up to date to Doug Ledfords 5.1.31 ? TIA With best regards Michael Meding - 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/
aic7xxx version status for 2.4.0test ?
Hi all, am I right that the aic7xx version in latest test is 5.2.1 ? Is there a reason why this is not up to date to Doug Ledfords 5.1.31 ? TIA With best regards Michael Meding - 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: aic7xxx version status for 2.4.0test ? -- ignore last post
Hi all, sorry, next time I should at least do sanity checks on my own email. Of course 5.2.1 as in latest-test is newer than 5.1.something. Just did a quick look in the source and on Dougs site and mixed the version numbers up. Stupid me! Greetings, Michael Meding - 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: Freeze on FPU exception with Athlon
Hi,
I am using test10-pre5 on Duron.
>
> I couldn't get it to freeze. I tried it with asm("fldcw %0": :"m" (0))
> and with fesetenv() using gcc -lm to link it. I have glibc-2.1.2,
> egcs 2.91.66, and 2.4.0-test10.
>
> Regards,
> Adrian
Same here except gcc-2.95.2 and glibc 2.13. I got an floating point
expeption. No freeze here.
Greetings
Michael Meding
-
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: Freeze on FPU exception with Athlon
Hi,
I am using test10-pre5 on Duron.
I couldn't get it to freeze. I tried it with asm("fldcw %0": :"m" (0))
and with fesetenv() using gcc -lm to link it. I have glibc-2.1.2,
egcs 2.91.66, and 2.4.0-test10.
Regards,
Adrian
Same here except gcc-2.95.2 and glibc 2.13. I got an floating point
expeption. No freeze here.
Greetings
Michael Meding
-
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: Oops on booting stock RH6
Hi Alison, > The system crashes on boot of the linux partition. Unfortunately, this > does mean that we haven't been able to run ksymoops or get any of the > system files, so all we've got is what's on screen, including any > visible system messages before that point. I guess this is not the case. YOu should see system messages and the system hanging on the later described issue. > (Obviously, the stock CDROM > kernel boots fine, as we can install linux in the first place.) Exactly, wondered why ? 2.2.14BOOT is not trying to disable the serial number while 2.2.14 is. This hang then there. > > We have swapped out the motherboard and CPU with others of the same > model, with no effect; we have also tried different RAM (and another > install of RH6.2 on another hard drive) with no success. Plus multiple > reinstalls, etc., etc. We're beginning to look narrowly at the power > supply, by this point... :) Actually, just use a boot disk or a recent SUSE cd for that matter, boot the installed system, recompile the kernel without "disable cpuid serial" and you are all set. > > Without proper info, it's a stab in the dark, but has anyone seen > something like this before? > > TIA... By the way, that's what redhat support is for. They should have told you that there is an issue with the supplied kernel and durons and thunderbirds. I guess this is OT on the LKML. Anyway, my suggestion should work, since it worked for me. Greetings Michael - 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: Kernel 2.2.18 and GCC versions
Igmar Palsenberg wrote: > > > > I will use 2.95.2, so that egcs seems to not being able to build 18-preX. > > > > egcs-1.1.2 builds 2.2.18pre. I know this because thats the compiler I use > > to build it. Its also the recommended compiler. 2.95 is still 'probably works'. > > In truth I think 2.95 is now at the point where if anything kernel side is > > broken it must be fairly obscure or a little used driver > > It builds up to 2.2.17 fine here. Haven't tried 18pre 2.95.2 builds 2.2.18pre15 latest and aa1 patch on top with optimization for PPRO on duron. Running a day now. Greetings Michael Meding - 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: Kernel 2.2.18 and GCC versions
Igmar Palsenberg wrote: I will use 2.95.2, so that egcs seems to not being able to build 18-preX. egcs-1.1.2 builds 2.2.18pre. I know this because thats the compiler I use to build it. Its also the recommended compiler. 2.95 is still 'probably works'. In truth I think 2.95 is now at the point where if anything kernel side is broken it must be fairly obscure or a little used driver It builds up to 2.2.17 fine here. Haven't tried 18pre 2.95.2 builds 2.2.18pre15 latest and aa1 patch on top with optimization for PPRO on duron. Running a day now. Greetings Michael Meding - 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: [OT] Linux running on an AMD Duron-700Mhz
Hi there, redhat 6.2 will (should) install on this system. Maybe you have to use the upgraded driver / update disk and maybe you have to use text install. However, the installed kernel will fail during boot because it tries to disable the cpuid serial number on your system (of course there isn't one). The 2.2.14BOOT kernels supplied with the system should work, however I didn't found a way to fire them up after installing due to the fact that they are not configured in lilo. After installing I used a SUSE cd to boot the installed system with the kernel supplied on the cd by suse ;-). That worked. You then just have to recompile the kernel without the cpuid serial disable. That worked. Maybe Mandrake suffers from the same "bug" that it tries to disable the serial :-). I do not have personal experience with this distro. No problems whatsoever made debian potato 2.2. Fairly easy install (text based). Just tested this distro as of now a couple of minutes. Suse will work also I guess (since the boot cd worked). > I know that this is a fairly "recent" system and as such the hardware > support in the kernels distributed with the distros aren't necessarily up > to date. Wanted to find out from others on this list who are running > Durons what distro they're running so that I can try to get this machine up > and going again. Please reply off-list to "[EMAIL PROTECTED]". System here is Duron on MSI-6330 KT7PRO with Adaptec AHA-2940UW and Matrox G400. Greetings Michael - 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: [OT] Linux running on an AMD Duron-700Mhz
Hi there, redhat 6.2 will (should) install on this system. Maybe you have to use the upgraded driver / update disk and maybe you have to use text install. However, the installed kernel will fail during boot because it tries to disable the cpuid serial number on your system (of course there isn't one). The 2.2.14BOOT kernels supplied with the system should work, however I didn't found a way to fire them up after installing due to the fact that they are not configured in lilo. After installing I used a SUSE cd to boot the installed system with the kernel supplied on the cd by suse ;-). That worked. You then just have to recompile the kernel without the cpuid serial disable. That worked. Maybe Mandrake suffers from the same "bug" that it tries to disable the serial :-). I do not have personal experience with this distro. No problems whatsoever made debian potato 2.2. Fairly easy install (text based). Just tested this distro as of now a couple of minutes. Suse will work also I guess (since the boot cd worked). I know that this is a fairly "recent" system and as such the hardware support in the kernels distributed with the distros aren't necessarily up to date. Wanted to find out from others on this list who are running Durons what distro they're running so that I can try to get this machine up and going again. Please reply off-list to "[EMAIL PROTECTED]". System here is Duron on MSI-6330 KT7PRO with Adaptec AHA-2940UW and Matrox G400. Greetings Michael - 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: 2.4.0-pre9: mga drm still not working
Hi there, just a side note. It is recommended that you use the mga.o from dri tree anyway... not the one from the kernel tree. That won't help much about the underlying problem with the loading order but since there is no way to compile the mga.o in from the dri tree the problem itself vanishes ;-) Greetings Michael - 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: 2.4.0-pre9: mga drm still not working
Hi there, just a side note. It is recommended that you use the mga.o from dri tree anyway... not the one from the kernel tree. That won't help much about the underlying problem with the loading order but since there is no way to compile the mga.o in from the dri tree the problem itself vanishes ;-) Greetings Michael - 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: Why does everyone hate gcc 2.95?
Hi there, > I hate it because it compiles much more slowly than 2.72 and for > my purposes, Hm, have not checked that. Did you do benchmarks here ? at least, the resulting code is not any faster on > any of the following platforms: x86, SPARC, MIPS, PA-RISC, and Alpha. Hm, quick check of dgemm or also testgart or gears gives me a 10 to 20 percent increase in speed when compiling with -mcpu=pentium -O2 as switches for both runs on my duron. All this reasons are not showing that gcc-2.95.2 is somehow broken. Please enlighten me. With best regards Michael Larry McVoy schrieb: > > On Wed, Oct 04, 2000 at 04:28:41AM +, John Anthony Kazos Jr. wrote: > > What does everyone have against gcc 2.95 on this list? I've been > > compiling kernels successfully (read: not one single (ever) error > > in compilation) with gcc 2.95.2 for more than a year now. What's the > > big deal? > > [Fix your mail program to put in carriage returns at 72 columns, please] > > I hate it because it compiles much more slowly than 2.72 and for > my purposes, at least, the resulting code is not any faster on > any of the following platforms: x86, SPARC, MIPS, PA-RISC, and Alpha. > I ran a bunch of tests with both on the BitKeeper source base, about > 100K lines of code or so, and then ran the regressions as well as some > hand picked tests. No faster. Just compiles slower. Add to that > some distributions BRAINDEAD default of havving colorgcc be the default > compiler (can you say fork perl to fork gcc? Can you say STUPID?), and > you start to understand why the first thing I do is remove all that > garbage and put back a reasonable compiler. > > I'm not impressed. > -- > --- > Larry McVoy lm at bitmover.com http://www.bitmover.com/lm > - > 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/ - 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: Why does everyone hate gcc 2.95?
Hi there, I hate it because it compiles much more slowly than 2.72 and for my purposes, Hm, have not checked that. Did you do benchmarks here ? at least, the resulting code is not any faster on any of the following platforms: x86, SPARC, MIPS, PA-RISC, and Alpha. Hm, quick check of dgemm or also testgart or gears gives me a 10 to 20 percent increase in speed when compiling with -mcpu=pentium -O2 as switches for both runs on my duron. All this reasons are not showing that gcc-2.95.2 is somehow broken. Please enlighten me. With best regards Michael Larry McVoy schrieb: On Wed, Oct 04, 2000 at 04:28:41AM +, John Anthony Kazos Jr. wrote: What does everyone have against gcc 2.95 on this list? I've been compiling kernels successfully (read: not one single (ever) error in compilation) with gcc 2.95.2 for more than a year now. What's the big deal? [Fix your mail program to put in carriage returns at 72 columns, please] I hate it because it compiles much more slowly than 2.72 and for my purposes, at least, the resulting code is not any faster on any of the following platforms: x86, SPARC, MIPS, PA-RISC, and Alpha. I ran a bunch of tests with both on the BitKeeper source base, about 100K lines of code or so, and then ran the regressions as well as some hand picked tests. No faster. Just compiles slower. Add to that some distributions BRAINDEAD default of havving colorgcc be the default compiler (can you say fork perl to fork gcc? Can you say STUPID?), and you start to understand why the first thing I do is remove all that garbage and put back a reasonable compiler. I'm not impressed. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - 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/ - 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: What is up with Redhat 7.0?
Hi there, it is totally funny, how technical based discussion, and one of those was the discussion wether using a unpublished non existent compiler and a non existent release was a good idea or not , became suddenly a type of self presentating thread. > And severely biased groundless pointless Red Hat bashing does? It is, rather a fun read though. Mike, Igmar and whomever thinks that adding the finger pointing to this are showing this here. For you Mike, do you think that, from the support point of view using this compiler set was a good idea ? You suddenly have and will have more of this request for support on the lkml like the initial "bashing (bending your words here) the "what's up with redhat"" but merely because there has been no good communication of what is included and why and how to get around the limitations by redhat. It is fact that the compiler isn't published by gcc. Maybe cygnus is supporting this "made up release" but gcc is not as far as I know. There is simply no thing as a gcc-2.96, and it doesn't matter wether it is binary or source compatible or not. The users think hey, here is a release redhat have and others don't. This is simply the way one would expect from Redmond based companies. Same with the glibc. And I do have some support for the people arguing in some kind of conspiracy based thinking that redhat tries to "fork" GNU/Linux in kind of way because of their market influence at the moment and therefore extending this market power into the future with an incompatible distribution. People from redhat here talk about "innovation" but hey, they didn't even were able to get the fixes for the libraries enlightenment was based on into in a timely manner. And users were stick with the old buggy ones. There are a lot other examples here. Take the Duron (Thunderbird?) issue. Same stuff here. So I really take Alan's and others words (and credibility) for it that redhat-gcc-2.96 is worth the hassle, smae as the beta--redhat-glibc2.2. But sometimes redhat really makes me wonder, especially looking into their arguing (and that of it's employees) why certain things aren't integrated in their distribution (reiserfs anybody?) Especially since some people are desperately trying to banish it from the kernel, beeing there technical arguments or not. It really is funny that some things don't get integrated while others which are unstable and highly experimental are. Sometimes I think that there are more political reasons than technical. It is a big step for a company that was always using rather old versions of the included software now is going out and using "beta-stuff-in-terms-or-releases" in their new distribution. Is it now the time for marketeers ? What is, however, is fascinating me is that the tidal waves are getting higher and easily personal here. That seems to prove that there is more into this than just technical reasoning. With best regards Michael Meding - 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: What is up with Redhat 7.0?
Hi there, it is totally funny, how technical based discussion, and one of those was the discussion wether using a unpublished non existent compiler and a non existent release was a good idea or not , became suddenly a type of self presentating thread. And severely biased groundless pointless Red Hat bashing does? It is, rather a fun read though. Mike, Igmar and whomever thinks that adding the finger pointing to this are showing this here. For you Mike, do you think that, from the support point of view using this compiler set was a good idea ? You suddenly have and will have more of this request for support on the lkml like the initial "bashing (bending your words here) the "what's up with redhat"" but merely because there has been no good communication of what is included and why and how to get around the limitations by redhat. It is fact that the compiler isn't published by gcc. Maybe cygnus is supporting this "made up release" but gcc is not as far as I know. There is simply no thing as a gcc-2.96, and it doesn't matter wether it is binary or source compatible or not. The users think hey, here is a release redhat have and others don't. This is simply the way one would expect from Redmond based companies. Same with the glibc. And I do have some support for the people arguing in some kind of conspiracy based thinking that redhat tries to "fork" GNU/Linux in kind of way because of their market influence at the moment and therefore extending this market power into the future with an incompatible distribution. People from redhat here talk about "innovation" but hey, they didn't even were able to get the fixes for the libraries enlightenment was based on into in a timely manner. And users were stick with the old buggy ones. There are a lot other examples here. Take the Duron (Thunderbird?) issue. Same stuff here. So I really take Alan's and others words (and credibility) for it that redhat-gcc-2.96 is worth the hassle, smae as the beta--redhat-glibc2.2. But sometimes redhat really makes me wonder, especially looking into their arguing (and that of it's employees) why certain things aren't integrated in their distribution (reiserfs anybody?) Especially since some people are desperately trying to banish it from the kernel, beeing there technical arguments or not. It really is funny that some things don't get integrated while others which are unstable and highly experimental are. Sometimes I think that there are more political reasons than technical. It is a big step for a company that was always using rather old versions of the included software now is going out and using "beta-stuff-in-terms-or-releases" in their new distribution. Is it now the time for marketeers ? What is, however, is fascinating me is that the tidal waves are getting higher and easily personal here. That seems to prove that there is more into this than just technical reasoning. With best regards Michael Meding - 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: What is up with Redhat 7.0?
Hi Martin, > WHAT? Are you nuts - they pay breed for many of the core kernel > developers - I think if they didn't those would actually > have entierly stopped working on Linux otherwise just after finishing > scool and going into the real world out there. You can't hardly call > this behaviour *demanging*!!! And then there is Alan himself! Sure, and we do not have any demand for higly skilled, motivated kernel developers ? If redhat wouldn't have employed then somebody else would and maybe redhat wouldn't be in the situation of having access to their knowledge and their support when it comes to really tricky solutions. I don't think your point holds. They do not employ the developers out of pure altruism. They have a knowledgetransfer and they can use that for their support. They do earn their money with consulting. Or least to say, that is where the real money should come from. Greetings Michael - 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: What is up with Redhat 7.0?
Hi Martin, WHAT? Are you nuts - they pay breed for many of the core kernel developers - I think if they didn't those would actually have entierly stopped working on Linux otherwise just after finishing scool and going into the real world out there. You can't hardly call this behaviour *demanging*!!! And then there is Alan himself! Sure, and we do not have any demand for higly skilled, motivated kernel developers ? If redhat wouldn't have employed then somebody else would and maybe redhat wouldn't be in the situation of having access to their knowledge and their support when it comes to really tricky solutions. I don't think your point holds. They do not employ the developers out of pure altruism. They have a knowledgetransfer and they can use that for their support. They do earn their money with consulting. Or least to say, that is where the real money should come from. Greetings Michael - 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: What is up with Redhat 7.0?
Hi there, you have of course used kgcc for the compile job ? 2.96 maybe is chewing the kernel source a little bit too well. Did you edit the makefiles to use kgcc instead of gcc ? Greetings Michael - 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: What is up with Redhat 7.0?
Hi there, you have of course used kgcc for the compile job ? 2.96 maybe is chewing the kernel source a little bit too well. Did you edit the makefiles to use kgcc instead of gcc ? Greetings Michael - 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: spontaneous reboots 2.4.0-test9-ore7
Hi there, I forgot to mention that I either get reboots or lockups when I put little stress on the machine (like compiling dri code and wine and open a lot of netscapes). Greetings Michael - 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/
spontaneous reboots 2.4.0-test9-ore7
Hi all, my system keeps rebooting without motivation. During the reboots XF4.01 was running and a compile job in the backround. System is a AMD duron which is overclocked to (600) 800. However this system was running fine the last days throughout with earlier test9 kernels. So I guess this is not the reason. System was rebooting no matter if kernel was compiled for i386 or Athlon. Please see attached information. Greetings Michael PS: At least it is not eating my filesystem like in those ancient 2.3.xx days. Linux version 2.4.0-test9 (root@HAL) (gcc version 2.95.2 19991024 (release)) #3 Mit Sep 27 23:38:29 CEST 2000 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 0001 @ (reserved) BIOS-e820: 07f0 @ 0010 (usable) On node 0 totalpages: 32768 zone(0): 4096 pages. zone(1): 28672 pages. zone(2): 0 pages. Kernel command line: auto BOOT_IMAGE=linux ro root=805 agp_try_unsupported=1 Initializing CPU#0 Detected 800.039 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1595.80 BogoMIPS Memory: 126084k/131072k available (1778k kernel code, 4600k reserved, 137k data, 216k init, 0k highmem) Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) VFS: Diskquotas version dquot_6.4.0 initialized CPU: L1 I Cache: 64K L1 D Cache: 64K (64 bytes/line) CPU: L2 Cache: 64K CPU: AMD Duron(tm) Processor stepping 00 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.36 (2221) Richard Gooch ([EMAIL PROTECTED]) PCI: PCI BIOS revision 2.10 entry at 0xfb250, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware isapnp: Scanning for Pnp cards... isapnp: No Plug & Play device found Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 1024 buckets, 8Kbytes TCP: Hash tables configured (established 8192 bind 8192) Initializing RT netlink socket Starting kswapd v1.8 0x378: FIFO is 16 bytes 0x378: writeIntrThreshold is 8 0x378: readIntrThreshold is 8 0x378: PWord is 8 bits 0x378: Interrupts are ISA-Pulses 0x378: possible IRQ conflict! 0x378: ECP port cfgA=0x10 cfgB=0x00 0x378: ECP settings irq= dma= parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA] parport0: cpp_daisy: aa5500ff(00) parport0: assign_addrs: aa5500ff(00) parport0: No more nibble data (0 bytes) parport0: cpp_daisy: aa5500ff(00) parport0: assign_addrs: aa5500ff(00) parport0: Legacy device parport_pc: Via 686A parallel port: io=0x378, irq=7, dma=3 i2c-core.o: i2c core module i2c-dev.o: i2c /dev entries driver module i2c-core.o: driver i2c-dev dummy driver registered. pty: 256 Unix98 ptys configured lp0: using parport0 (interrupt-driven). RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller on PCI bus 00 dev 39 VP_IDE: chipset revision 16 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: neither IDE port enabled (BIOS) Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 Loading I2O Core - (c) Copyright 1999 Red Hat Software Linux I2O PCI support (c) 1999 Red Hat Software. i2o: Checking for PCI I2O controllers... I2O configuration manager v 0.04. (C) Copyright 1999 Red Hat Software I2O Block Storage OSM v0.9 (c) Copyright 1999, 2000 Red Hat Software. I2O LAN OSM (C) 1999 University of Helsinki. Serial driver version 5.02 (2000-08-09) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A Real Time Clock Driver v1.10c 8139too Fast Ethernet driver 0.9.10 loaded eth0: RealTek RTL8139 Fast Ethernet at 0xc880, 00:e0:7d:72:d3:80, IRQ 11 eth0: Identified 8139 chip type 'RTL-8139A' atp.c:v1.09 8/9/2000 Donald Becker <[EMAIL PROTECTED]> http://www.scyld.com/network/atp.html Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 96M agpgart: Detected Via Apollo Pro KT133 chipset agpgart: AGP aperture is 64M @ 0xd000 (scsi0) found at PCI 0/14/0 (scsi0) Wide Channel, SCSI ID=7, 16/255 SCBs (scsi0) Downloading sequencer code... 422 instructions downloaded scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0 (scsi0:0:0:0) Synchronous at 40.0 Mbyte/sec, offset 8. Vendor: IBM Model: DDRS-39130D Rev: DC1B Type: Direct-Access
spontaneous reboots 2.4.0-test9-ore7
Hi all, my system keeps rebooting without motivation. During the reboots XF4.01 was running and a compile job in the backround. System is a AMD duron which is overclocked to (600) 800. However this system was running fine the last days throughout with earlier test9 kernels. So I guess this is not the reason. System was rebooting no matter if kernel was compiled for i386 or Athlon. Please see attached information. Greetings Michael PS: At least it is not eating my filesystem like in those ancient 2.3.xx days. Linux version 2.4.0-test9 (root@HAL) (gcc version 2.95.2 19991024 (release)) #3 Mit Sep 27 23:38:29 CEST 2000 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 0001 @ (reserved) BIOS-e820: 07f0 @ 0010 (usable) On node 0 totalpages: 32768 zone(0): 4096 pages. zone(1): 28672 pages. zone(2): 0 pages. Kernel command line: auto BOOT_IMAGE=linux ro root=805 agp_try_unsupported=1 Initializing CPU#0 Detected 800.039 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1595.80 BogoMIPS Memory: 126084k/131072k available (1778k kernel code, 4600k reserved, 137k data, 216k init, 0k highmem) Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) VFS: Diskquotas version dquot_6.4.0 initialized CPU: L1 I Cache: 64K L1 D Cache: 64K (64 bytes/line) CPU: L2 Cache: 64K CPU: AMD Duron(tm) Processor stepping 00 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.36 (2221) Richard Gooch ([EMAIL PROTECTED]) PCI: PCI BIOS revision 2.10 entry at 0xfb250, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware isapnp: Scanning for Pnp cards... isapnp: No Plug Play device found Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 1024 buckets, 8Kbytes TCP: Hash tables configured (established 8192 bind 8192) Initializing RT netlink socket Starting kswapd v1.8 0x378: FIFO is 16 bytes 0x378: writeIntrThreshold is 8 0x378: readIntrThreshold is 8 0x378: PWord is 8 bits 0x378: Interrupts are ISA-Pulses 0x378: possible IRQ conflict! 0x378: ECP port cfgA=0x10 cfgB=0x00 0x378: ECP settings irq=none or set by other means dma=none or set by other means parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA] parport0: cpp_daisy: aa5500ff(00) parport0: assign_addrs: aa5500ff(00) parport0: No more nibble data (0 bytes) parport0: cpp_daisy: aa5500ff(00) parport0: assign_addrs: aa5500ff(00) parport0: Legacy device parport_pc: Via 686A parallel port: io=0x378, irq=7, dma=3 i2c-core.o: i2c core module i2c-dev.o: i2c /dev entries driver module i2c-core.o: driver i2c-dev dummy driver registered. pty: 256 Unix98 ptys configured lp0: using parport0 (interrupt-driven). RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller on PCI bus 00 dev 39 VP_IDE: chipset revision 16 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: neither IDE port enabled (BIOS) Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 Loading I2O Core - (c) Copyright 1999 Red Hat Software Linux I2O PCI support (c) 1999 Red Hat Software. i2o: Checking for PCI I2O controllers... I2O configuration manager v 0.04. (C) Copyright 1999 Red Hat Software I2O Block Storage OSM v0.9 (c) Copyright 1999, 2000 Red Hat Software. I2O LAN OSM (C) 1999 University of Helsinki. Serial driver version 5.02 (2000-08-09) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A Real Time Clock Driver v1.10c 8139too Fast Ethernet driver 0.9.10 loaded eth0: RealTek RTL8139 Fast Ethernet at 0xc880, 00:e0:7d:72:d3:80, IRQ 11 eth0: Identified 8139 chip type 'RTL-8139A' atp.c:v1.09 8/9/2000 Donald Becker [EMAIL PROTECTED] http://www.scyld.com/network/atp.html Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 96M agpgart: Detected Via Apollo Pro KT133 chipset agpgart: AGP aperture is 64M @ 0xd000 (scsi0) Adaptec AHA-294X Ultra SCSI host adapter found at PCI 0/14/0 (scsi0) Wide Channel, SCSI ID=7, 16/255 SCBs (scsi0) Downloading sequencer code... 422 instructions downloaded scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0 Adaptec AHA-294X Ultra SCSI host adapter (scsi0:0:0:0)
Re: spontaneous reboots 2.4.0-test9-ore7
Hi there, I forgot to mention that I either get reboots or lockups when I put little stress on the machine (like compiling dri code and wine and open a lot of netscapes). Greetings Michael - 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/
Kernel 2.4.0-test9-pre2 is not performing well and swapping a lot compared to test7
Hi there, first I have to admit I can't as of now back up my expirience with benchmarks. But the new memory management introduced by Rik seems to not stand up performance wise. I use here a simple set up on a duron with 128mb and a kt-133 chipset with scsi aha2940 on an otherwise (gcc-2.95.2) almost stock redhat 6.2 with xf4.01 and latest dri code. After a couple of hours the system seems to swap out more stuff and while using netscape-communicator all the time the machine gets slower and slower. An easy compile job, which under test7 was barely noticeable now seems to slow everything down to a total new extend. The compile jobs (like compiling the dri tree which as said isn't really slowing down the system normally) even slow down moving windows or minimizing windows while under x. After all I doo not know how to prove that, I gladly accept hints here. I will gladly send other specs about my system upon request to interesting parties. With best regards Michael Meding - 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/
Kernel 2.4.0-test9-pre2 is not performing well and swapping a lot compared to test7
Hi there, first I have to admit I can't as of now back up my expirience with benchmarks. But the new memory management introduced by Rik seems to not stand up performance wise. I use here a simple set up on a duron with 128mb and a kt-133 chipset with scsi aha2940 on an otherwise (gcc-2.95.2) almost stock redhat 6.2 with xf4.01 and latest dri code. After a couple of hours the system seems to swap out more stuff and while using netscape-communicator all the time the machine gets slower and slower. An easy compile job, which under test7 was barely noticeable now seems to slow everything down to a total new extend. The compile jobs (like compiling the dri tree which as said isn't really slowing down the system normally) even slow down moving windows or minimizing windows while under x. After all I doo not know how to prove that, I gladly accept hints here. I will gladly send other specs about my system upon request to interesting parties. With best regards Michael Meding - 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: Fw: linux-2.0.39-pre-8 Compile error
Here you will find patch 2.54 : ftp://ftp.gnu.org/pub/gnu/patch/ Greetings Michael - 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/
