Re: [OT] Suitable Athlon Motherboard for Linux
Well, I have an Acer AK73 Pro(A), with an Athlon 1.333 GHz (133 FSB). I have never had anuy lockup or data corruption problems. I do run this system as a dual-boot, usually under Win2K :( The system is as follows: Acer AK73 Pro(A) Athlon (C) 1.333 GHz IBM DTLA307060 60G IDE hard drive Creative labs RW1210E CD rewriter IOmega Zip250 Matrox G450 Creative SB Live Value 5.1 D-Link network card (RTL8139) Pretty much the exact equipment that everyone complains about, but I can recompile kernels (fast!), copy large files, play music, and drag windows around in X - without any problems. I haven't used this system under Linux too much, so I can't say for sure that it is much better than other Via-based systems, but it does seem to be better. I haven't done any tweaking to the stock RH7.1 install, except for building a 2.4.4 kernel (I'm on the Win2K boot now - I can't remember if I had Athlon optimizations on or not). There are several things that I did with this system: First, I got a big power supply - 400 watts. This is with 1 hard drive, and only 3 I/O cards. Second, I got one of the AMD retail CPU's. The difference in price was small (maybe 10%), and it includes a GUARANTEED good fan - plus it has a 3-year warrantee. Third, I didn't buy the cheapest motherboard on the market. I have had excellent experiences with Acer products (since the '486 days), and this is one more positive experience for me. Let me know if you would like my kernel .config for experimentation. (not that I have done anything great to it - it just seems to work :) - Steve Joseph Mathewson wrote: [snip] > I can't see much alternative to Via chipsets in the Ahtlon market, other > than all-in-one-graphics-sound-network jobbies that, from previous > experience (namely the i810), are also best avoided. > > Joe. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Suitable Athlon Motherboard for Linux
Well, I have an Acer AK73 Pro(A), with an Athlon 1.333 GHz (133 FSB). I have never had anuy lockup or data corruption problems. I do run this system as a dual-boot, usually under Win2K :( The system is as follows: Acer AK73 Pro(A) Athlon (C) 1.333 GHz IBM DTLA307060 60G IDE hard drive Creative labs RW1210E CD rewriter IOmega Zip250 Matrox G450 Creative SB Live Value 5.1 D-Link network card (RTL8139) Pretty much the exact equipment that everyone complains about, but I can recompile kernels (fast!), copy large files, play music, and drag windows around in X - without any problems. I haven't used this system under Linux too much, so I can't say for sure that it is much better than other Via-based systems, but it does seem to be better. I haven't done any tweaking to the stock RH7.1 install, except for building a 2.4.4 kernel (I'm on the Win2K boot now - I can't remember if I had Athlon optimizations on or not). There are several things that I did with this system: First, I got a big power supply - 400 watts. This is with 1 hard drive, and only 3 I/O cards. Second, I got one of the AMD retail CPU's. The difference in price was small (maybe 10%), and it includes a GUARANTEED good fan - plus it has a 3-year warrantee. Third, I didn't buy the cheapest motherboard on the market. I have had excellent experiences with Acer products (since the '486 days), and this is one more positive experience for me. Let me know if you would like my kernel .config for experimentation. (not that I have done anything great to it - it just seems to work :) - Steve Joseph Mathewson wrote: [snip] I can't see much alternative to Via chipsets in the Ahtlon market, other than all-in-one-graphics-sound-network jobbies that, from previous experience (namely the i810), are also best avoided. Joe. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Exporting new functions from kernel 2.2.14
Well, my rebuild kernel / reboot / recompile module just finished. Unfortunately, the printk warning was still there. I replaced the unconditional #define MODVERSIONS with #include #ifdef CONFIG_MODVERSIONS #define MODVERSIONS #include #endif this is at the top of my source file. (before module.h and linux.h) (as seen somewhere on the web) and it compiles without warnings now. Now all I need is some info on module oparameters and using /proc :) Thanks again. - Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Exporting new functions from kernel 2.2.14
um. duh. Thanks. I guess it helps to know the right FM to R. :) Arthur had pointed out that modules.h should be included, then kernel.h. Is there a place where I can find out more about header file order dependencies? (damn - that sounds like a Microsoft help question) Keith Owens wrote: > Read the very last line of every message on linux-kernel. and to think I used to laugh at people who forgot to do that :) - Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Exporting new functions from kernel 2.2.14
Thanks. Actually, the symbols in question aren't in modules. The kernel is module enabled, but all drivers are being compiled in (this is for an embedded system). My external module (which needs to grab the timer interrupt) is in a separate source tree. Thanks for the printk info - I guess boneheads like me could use a FAQ that tells which order the miscellaneoud include files need to be in. (I had modules.h after linux.h). I changed the order, butI am waiting for a recompile now, so I don't know if the reordering worked. Arthur Naseef wrote: ... > you can edit the .ver file yourself (under /usr/src/linux/include/modules/) > and add entries. This will eliminate the funny versioning, as in: > As far as the printk() warning, you need to make sure your module code > includes the right header files. In this case, I believe you need to grab > after including . > > I hope this helps. > > -art > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Exporting new functions from kernel 2.2.14
Hello, all.
I am writing a pseudo-realtime control system, based on kernel 2.2.14.
The only RT-like task needs to hang off the timer IRQ. I am using
techniques like those in the book "Linux Kernel Internals", by Beck, et
al..
The patches in that book won't apply (they are for 2.1.24 or lower),
plus I want a somewaht different functionality, which brings me to my
question: How can I get (modversions-enabled) functions exported from
arch/i386/kernel/irq.c?
I see in /proc/ksyms that there are some functions exported from there
({enable,disable}_irq, probe_irq_{on,off}, etc.), and they have correct
looking versions.
When I add my new finctions to i386ksyms.c:
EXPORT_SYMBOL(grab_timer_interrupt);
EXPORT_SYMBOL(release_timer_interrupt);
I get names like
grab_timer_interrupt_R__ver_grab_timer_interrupt
release_timer_interrupt_R__ver_release_timer_interrupt
instead of
local_irq_count_R4d40375f
Additionally, when I make a dummy module (a la Alessandro Rubini's
"Hello" module in "Linux Device Drivers"), I get the following warning:
control.c:31: warning: implicit declaration of function
`printk_R1b7d4074'
The module seems to work (it printk's "module loaded" on load and
"module unloaded" on unload), but I suspect that this is because I am
printk()-ing unformatted text strings - only one parameter gets sent.
So, I obviously have missed some basics about:
a) versioning,
b) exporting symbols, and
c) modules.
could soemone please enlighten me, or direct me along the path of
enlightenment :)
Thanks
- Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Exporting new functions from kernel 2.2.14
Hello, all.
I am writing a pseudo-realtime control system, based on kernel 2.2.14.
The only RT-like task needs to hang off the timer IRQ. I am using
techniques like those in the book Linux Kernel Internals, by Beck, et
al..
The patches in that book won't apply (they are for 2.1.24 or lower),
plus I want a somewaht different functionality, which brings me to my
question: How can I get (modversions-enabled) functions exported from
arch/i386/kernel/irq.c?
I see in /proc/ksyms that there are some functions exported from there
({enable,disable}_irq, probe_irq_{on,off}, etc.), and they have correct
looking versions.
When I add my new finctions to i386ksyms.c:
EXPORT_SYMBOL(grab_timer_interrupt);
EXPORT_SYMBOL(release_timer_interrupt);
I get names like
grab_timer_interrupt_R__ver_grab_timer_interrupt
release_timer_interrupt_R__ver_release_timer_interrupt
instead of
local_irq_count_R4d40375f
Additionally, when I make a dummy module (a la Alessandro Rubini's
Hello module in Linux Device Drivers), I get the following warning:
control.c:31: warning: implicit declaration of function
`printk_R1b7d4074'
The module seems to work (it printk's module loaded on load and
module unloaded on unload), but I suspect that this is because I am
printk()-ing unformatted text strings - only one parameter gets sent.
So, I obviously have missed some basics about:
a) versioning,
b) exporting symbols, and
c) modules.
could soemone please enlighten me, or direct me along the path of
enlightenment :)
Thanks
- Steve
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Exporting new functions from kernel 2.2.14
Thanks. Actually, the symbols in question aren't in modules. The kernel is module enabled, but all drivers are being compiled in (this is for an embedded system). My external module (which needs to grab the timer interrupt) is in a separate source tree. Thanks for the printk info - I guess boneheads like me could use a FAQ that tells which order the miscellaneoud include files need to be in. (I had modules.h after linux.h). I changed the order, butI am waiting for a recompile now, so I don't know if the reordering worked. Arthur Naseef wrote: ... you can edit the .ver file yourself (under /usr/src/linux/include/modules/) and add entries. This will eliminate the funny versioning, as in: As far as the printk() warning, you need to make sure your module code includes the right header files. In this case, I believe you need to grab linux/kernel.h after including linux/module.h. I hope this helps. -art - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Exporting new functions from kernel 2.2.14
um. duh. Thanks. I guess it helps to know the right FM to R. :) Arthur had pointed out that modules.h should be included, then kernel.h. Is there a place where I can find out more about header file order dependencies? (damn - that sounds like a Microsoft help question) Keith Owens wrote: Read the very last line of every message on linux-kernel. and to think I used to laugh at people who forgot to do that :) - Steve - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Exporting new functions from kernel 2.2.14
Well, my rebuild kernel / reboot / recompile module just finished. Unfortunately, the printk warning was still there. I replaced the unconditional #define MODVERSIONS with #include linux/config.h #ifdef CONFIG_MODVERSIONS #define MODVERSIONS #include linux/modversions.h #endif this is at the top of my source file. (before module.h and linux.h) (as seen somewhere on the web) and it compiles without warnings now. Now all I need is some info on module oparameters and using /proc :) Thanks again. - Steve - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Interrupting select
"Peter T. Breuer" wrote: [snip]> um, shouldn't you be testing for res==-1, as well? > > specifically that condition and errno==EINTR is how I'd expect > > signals to effect the loop... [snip] > I assumed that "error" is something like trying to watch for a > negative number or zero descriptors, or having a fd_set that doesn't > contain open fd's. The reason I assumed that is because EINTR is not > listed as a possible: > > > ERRORS >EBADF An invalid file descriptor was given in one of the >sets. >EINTR A non blocked signal was caught. umm ^^ - it looks like it's listed here :) >EINVAL n is negative. >ENOMEM select was unable to allocate memory for internal >tables. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Interrupting select
Peter T. Breuer wrote: [snip] um, shouldn't you be testing for res==-1, as well? specifically that condition and errno==EINTR is how I'd expect signals to effect the loop... [snip] I assumed that error is something like trying to watch for a negative number or zero descriptors, or having a fd_set that doesn't contain open fd's. The reason I assumed that is because EINTR is not listed as a possible: ERRORS EBADF An invalid file descriptor was given in one of the sets. EINTR A non blocked signal was caught. umm ^^ - it looks like it's listed here :) EINVAL n is negative. ENOMEM select was unable to allocate memory for internal tables. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: APIC usb MPS 1.4 and the 2.4.2 kernel
Pete Toscano wrote: > > Very interesting. I had not heard about this. Are there any SMP boards > with a VIA chipset that does work well with Linux and USB? I have an > old P2B-DS that I had replace with this board as I needed more PCI > slots. Heck, for that matter are there any SMP boards that work well > with Linux and USB that have six or more PCI slots? > Well, I use an old SuperMicro ( http://www.supermicro.com ) P6DNH board. It has 8 PCI slots, 3 ISA slots, an I960 I2O processor (four of the PCI slots are on a secondary bus), and supports dual Pentium Pro CPUs and 1G RAM (EDO - it's 4 years old). They have newer boards with 6 PCI (64 bit, 66 MHz) + 1 AGP slot. Their boards are very high quality - though you'll pay for the reliability in $$$. -- Stephen Wille Padnos Programmer, Engineer, Problem Solver [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: APIC usb MPS 1.4 and the 2.4.2 kernel
Pete Toscano wrote: Very interesting. I had not heard about this. Are there any SMP boards with a VIA chipset that does work well with Linux and USB? I have an old P2B-DS that I had replace with this board as I needed more PCI slots. Heck, for that matter are there any SMP boards that work well with Linux and USB that have six or more PCI slots? Well, I use an old SuperMicro ( http://www.supermicro.com ) P6DNH board. It has 8 PCI slots, 3 ISA slots, an I960 I2O processor (four of the PCI slots are on a secondary bus), and supports dual Pentium Pro CPUs and 1G RAM (EDO - it's 4 years old). They have newer boards with 6 PCI (64 bit, 66 MHz) + 1 AGP slot. Their boards are very high quality - though you'll pay for the reliability in $$$. -- Stephen Wille Padnos Programmer, Engineer, Problem Solver [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] micro-opt DEBUG_ADD_PAGE
"Richard B. Johnson" wrote: > > On Thu, 8 Feb 2001, Stephen Wille Padnos wrote: > > > "Richard B. Johnson" wrote: > > [snip] > > > Another problem with 'volatile' has to do with pointers. When > > > it's possible for some object to be modified by some external > > > influence, we see: > > > > > > volatile struct whatever *ptr; > > > > > > Now, it's unclear if gcc knows that we don't give a damn about > > > the address contained in 'ptr'. We know that it's not going to > > > change. What we are concerned with are the items within the > > > 'struct whatever'. From what I've seen, gcc just reloads the > > > pointer. > > > [snip] > Yes. My point is that a lot of authors have declared just about everything > 'volatile' `grep volatile /usr/src/linux/drivers/net/*.c`, just to > be "safe". It's likely that there are many hundreds of thousands of > unneeded register-reloads because of this. > > It might be useful for somebody who has a lot of time on his/her > hands to go through some of these drivers. I would be willing to do this (on the slow boat - I don't have THAT much spare time :), but only if we can be sure that the gcc optimizer will correctly handle a normal pointer to volatile data. Your experiences would seem to indicate that the optimizer needs fixing before much effort should be spent on this. -- Stephen Wille Padnos Programmer, Engineer, Problem Solver [EMAIL PROTECTED] - 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: [PATCH] micro-opt DEBUG_ADD_PAGE
"Richard B. Johnson" wrote: [snip] > Another problem with 'volatile' has to do with pointers. When > it's possible for some object to be modified by some external > influence, we see: > > volatile struct whatever *ptr; > > Now, it's unclear if gcc knows that we don't give a damn about > the address contained in 'ptr'. We know that it's not going to > change. What we are concerned with are the items within the > 'struct whatever'. From what I've seen, gcc just reloads the > pointer. > > Cheers, > Dick Johnson > gcc should treat volatile struct whatever *ptr; as a different case than struct whatever * volatile ptr; which is also different from volatile struct whatever * volatile ptr; I think (but can't find my K C book to confirm :) that the first case declares the struct as volatile, and the second case declares the pointer volatile (the third case declares a volatile pointer to a structure with volatile parts). So, the programmer should have the choice, if gcc is dealing with volatile correctly. Of course, that doesn't mean that the authors have made the right choice :) -- Stephen Wille Padnos Programmer, Engineer, Problem Solver [EMAIL PROTECTED] - 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: [PATCH] micro-opt DEBUG_ADD_PAGE
"Richard B. Johnson" wrote: [snip] Another problem with 'volatile' has to do with pointers. When it's possible for some object to be modified by some external influence, we see: volatile struct whatever *ptr; Now, it's unclear if gcc knows that we don't give a damn about the address contained in 'ptr'. We know that it's not going to change. What we are concerned with are the items within the 'struct whatever'. From what I've seen, gcc just reloads the pointer. Cheers, Dick Johnson gcc should treat volatile struct whatever *ptr; as a different case than struct whatever * volatile ptr; which is also different from volatile struct whatever * volatile ptr; I think (but can't find my KR C book to confirm :) that the first case declares the struct as volatile, and the second case declares the pointer volatile (the third case declares a volatile pointer to a structure with volatile parts). So, the programmer should have the choice, if gcc is dealing with volatile correctly. Of course, that doesn't mean that the authors have made the right choice :) -- Stephen Wille Padnos Programmer, Engineer, Problem Solver [EMAIL PROTECTED] - 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: [PATCH] micro-opt DEBUG_ADD_PAGE
"Richard B. Johnson" wrote: On Thu, 8 Feb 2001, Stephen Wille Padnos wrote: "Richard B. Johnson" wrote: [snip] Another problem with 'volatile' has to do with pointers. When it's possible for some object to be modified by some external influence, we see: volatile struct whatever *ptr; Now, it's unclear if gcc knows that we don't give a damn about the address contained in 'ptr'. We know that it's not going to change. What we are concerned with are the items within the 'struct whatever'. From what I've seen, gcc just reloads the pointer. [snip] Yes. My point is that a lot of authors have declared just about everything 'volatile' `grep volatile /usr/src/linux/drivers/net/*.c`, just to be "safe". It's likely that there are many hundreds of thousands of unneeded register-reloads because of this. It might be useful for somebody who has a lot of time on his/her hands to go through some of these drivers. I would be willing to do this (on the slow boat - I don't have THAT much spare time :), but only if we can be sure that the gcc optimizer will correctly handle a normal pointer to volatile data. Your experiences would seem to indicate that the optimizer needs fixing before much effort should be spent on this. -- Stephen Wille Padnos Programmer, Engineer, Problem Solver [EMAIL PROTECTED] - 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: Promise, DMA and RAID5 problems running 2.4.1
"A.Sajjad Zaidi" wrote: > > do you understand that you can't really have raid on ide involving > > two drives on the same channel? > > Is that just because of performance or are there other problems? Its working > fine as it is, but Im considering setting up all drives as masters (2x > ATA-100, 2x ATA-66). It's because IDE is a blocking bus - each drive must complete its' task before the data bus is released for the next IO operation. So, the first drive will finish writing to the disk before the second drive can start. (That's one reason why SCSI is preferred for high end systems - you can "disconnect" from an IO operation to allow other IO's to be sent to other devices on the same bus) -- Stephen Wille Padnos Programmer, Engineer, Problem Solver [EMAIL PROTECTED] - 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: Promise, DMA and RAID5 problems running 2.4.1
"A.Sajjad Zaidi" wrote: do you understand that you can't really have raid on ide involving two drives on the same channel? Is that just because of performance or are there other problems? Its working fine as it is, but Im considering setting up all drives as masters (2x ATA-100, 2x ATA-66). It's because IDE is a blocking bus - each drive must complete its' task before the data bus is released for the next IO operation. So, the first drive will finish writing to the disk before the second drive can start. (That's one reason why SCSI is preferred for high end systems - you can "disconnect" from an IO operation to allow other IO's to be sent to other devices on the same bus) -- Stephen Wille Padnos Programmer, Engineer, Problem Solver [EMAIL PROTECTED] - 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: VIA VT82C686X
Byron Stanoszek wrote: > On Tue, 30 Jan 2001, David D.W. Downey wrote: > > > I removed the ide and ata setting. System is running stably as in no > > kernel crashes, but I am getting daemon and shell crashes. With this > > current kernel I've had 1 kernel crash in about 3 hours as compared to 1 > > every 10 or 15 minutes. Crash, reboot, 10 minutes or so crash, reboot. ect > > ect. > > > > I'm wanting to test something else out. I'm wondering if there isn't some > > hardware issue with the RAM. This particular board will do 1GB of PC133, > > or 2.5GB of PC100. I'm wondering if there isn't something wrong with how > > it reads the speed and the appropriate limitation. It's running stably if > > I only run 768MB of PC133 RAM. But if I run a solid 1GB of PC133 I get > > segfaults and sig11 crashes constantly. All the RAM has been > > professionally tested and certified. > > That definitely sounds like a RAM problem. The system should perform the same > independent of how many RAM chips you put in there (segfault-wise). If you're > still in doubt, you can try booting up with memtest86 and run it for several > hours with only the memory chip that you think might be causing the problem. > Even though the motherboard *should* perform the same regardless of the amount of RAM, it may not. Physically, the refresh needs higher current drive when there are more modules. I have seen a BIOS option to set the DRAM refresh current (RAS, CAS settable to 10 or 16 mA each), but that was only on one motherboard that I can remember - you might want to check for this. - 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: VIA VT82C686X
Byron Stanoszek wrote: On Tue, 30 Jan 2001, David D.W. Downey wrote: I removed the ide and ata setting. System is running stably as in no kernel crashes, but I am getting daemon and shell crashes. With this current kernel I've had 1 kernel crash in about 3 hours as compared to 1 every 10 or 15 minutes. Crash, reboot, 10 minutes or so crash, reboot. ect ect. I'm wanting to test something else out. I'm wondering if there isn't some hardware issue with the RAM. This particular board will do 1GB of PC133, or 2.5GB of PC100. I'm wondering if there isn't something wrong with how it reads the speed and the appropriate limitation. It's running stably if I only run 768MB of PC133 RAM. But if I run a solid 1GB of PC133 I get segfaults and sig11 crashes constantly. All the RAM has been professionally tested and certified. That definitely sounds like a RAM problem. The system should perform the same independent of how many RAM chips you put in there (segfault-wise). If you're still in doubt, you can try booting up with memtest86 and run it for several hours with only the memory chip that you think might be causing the problem. Even though the motherboard *should* perform the same regardless of the amount of RAM, it may not. Physically, the refresh needs higher current drive when there are more modules. I have seen a BIOS option to set the DRAM refresh current (RAS, CAS settable to 10 or 16 mA each), but that was only on one motherboard that I can remember - you might want to check for this. - 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/
