Re: Re: AMD thunderbird oops
Well considering the other night the power supply went dead, I think that is part of the problem. It is brand new, and I am being sent another one (free of course). I also had my mb loaded at the time (scsi cd-rw, cdrom, internal zip, floppy, 1 hd, Sound card, video, modem, NIC, scsi card) but my last tyan was fine with that load it may be a kt7a thing. Several people said that random (keyword here) oopses are more often a hardware thing. I wonder if the kt7a is going to be able to perform fully loaded.. is anyone running one fully loaded? 4 ide drives, 2 floppy, (5 pci and 1 isa) or 6pci, agp, 512MEG+ RAM? Joe Dave Jones <[EMAIL PROTECTED]> wrote: > On Tue, 26 Jun 2001, Alan Cox wrote: > My current speculation is that the sdram setup on some of these boards can't > actually take the full CPU spec caused by these hand tuned routines. There is > some evidence to support that as several other boards only work with Athlon > optimisation if you set the BIOS options to 'conservative' not 'optimised' Interesting, and plausable theory. It would be more interesting to see register dumps of the memory timing registers on both good and bad systems, to see if this is the case. Unfortunatly afair the register level specs of all the affected chipsets are not available. regards, Dave. -- | Dave Jones.http://www.suse.de/~davej | SuSE Labs - 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: Re: AMD thunderbird oops
Well considering the other night the power supply went dead, I think that is part of the problem. It is brand new, and I am being sent another one (free of course). I also had my mb loaded at the time (scsi cd-rw, cdrom, internal zip, floppy, 1 hd, Sound card, video, modem, NIC, scsi card) but my last tyan was fine with that load it may be a kt7a thing. Several people said that random (keyword here) oopses are more often a hardware thing. I wonder if the kt7a is going to be able to perform fully loaded.. is anyone running one fully loaded? 4 ide drives, 2 floppy, (5 pci and 1 isa) or 6pci, agp, 512MEG+ RAM? Joe Dave Jones [EMAIL PROTECTED] wrote: On Tue, 26 Jun 2001, Alan Cox wrote: My current speculation is that the sdram setup on some of these boards can't actually take the full CPU spec caused by these hand tuned routines. There is some evidence to support that as several other boards only work with Athlon optimisation if you set the BIOS options to 'conservative' not 'optimised' Interesting, and plausable theory. It would be more interesting to see register dumps of the memory timing registers on both good and bad systems, to see if this is the case. Unfortunatly afair the register level specs of all the affected chipsets are not available. regards, Dave. -- | Dave Jones.http://www.suse.de/~davej | SuSE Labs - 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: Re: AMD thunderbird oops
Thanks, I have a heat sink and it is huge about 2 inches, plus fan. Plus another 4" fan in the case. (real nice case). I think it is the memory, as yesterday my gcc was bombing with 'internel compiler error', which is usually a good mem tester. So I started setting mem=64m and things worked better and the install went all the way through. I think I need to slow my drams down a bit or add some delay in the bios settings. The oops says something like 'kernel null pointer at address 0x00'. How do I 'catch' the output of an oops when the filesystem goes and I get ext2fs errors and am forced to reboot and manually run e2fsck? Lastly with the mem=64M or mem=128M when I do a make dep, I get an error message that says Error 'missing seperator'. What does that mean? It stops in the drivers/net dir when I get this message? Thanks Joe Alan Cox <[EMAIL PROTECTED]> wrote: > > I just upgradede my system to an 1200Mhz AMD Athlon Thundirbird (266Mhz FSB) >processor / 512Meg of RAM, and an Asus kt7a motherboard. > > It is oppsing left and right. I recompiled the kernel with Athelon as the CPU but >keep getting these oopses.. > > I also get these same problems while trying to install RH 7.1 > > Anyone know is this a supported processor / MB and has anyone had these problems? Random oopses normally indicate faulty board cpu or ram (and the fault may even just be overheating or dimms not in the sockets cleanly). I doubt its the board design or model that is the problem, you probably jut have a faulty component somewhere if its oopsing randomly even during installs and stuff memtest86, and heatsink compound may be your best friends - 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: Re: AMD thunderbird oops
Thanks, I have a heat sink and it is huge about 2 inches, plus fan. Plus another 4 fan in the case. (real nice case). I think it is the memory, as yesterday my gcc was bombing with 'internel compiler error', which is usually a good mem tester. So I started setting mem=64m and things worked better and the install went all the way through. I think I need to slow my drams down a bit or add some delay in the bios settings. The oops says something like 'kernel null pointer at address 0x00'. How do I 'catch' the output of an oops when the filesystem goes and I get ext2fs errors and am forced to reboot and manually run e2fsck? Lastly with the mem=64M or mem=128M when I do a make dep, I get an error message that says Error 'missing seperator'. What does that mean? It stops in the drivers/net dir when I get this message? Thanks Joe Alan Cox [EMAIL PROTECTED] wrote: I just upgradede my system to an 1200Mhz AMD Athlon Thundirbird (266Mhz FSB) processor / 512Meg of RAM, and an Asus kt7a motherboard. It is oppsing left and right. I recompiled the kernel with Athelon as the CPU but keep getting these oopses.. I also get these same problems while trying to install RH 7.1 Anyone know is this a supported processor / MB and has anyone had these problems? Random oopses normally indicate faulty board cpu or ram (and the fault may even just be overheating or dimms not in the sockets cleanly). I doubt its the board design or model that is the problem, you probably jut have a faulty component somewhere if its oopsing randomly even during installs and stuff memtest86, and heatsink compound may be your best friends - 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/
AMD thunderbird oops
I just upgradede my system to an 1200Mhz AMD Athlon Thundirbird (266Mhz FSB) processor / 512Meg of RAM, and an Asus kt7a motherboard. It is oppsing left and right. I recompiled the kernel with Athelon as the CPU but keep getting these oopses.. I also get these same problems while trying to install RH 7.1 Anyone know is this a supported processor / MB and has anyone had these problems? Joe please cc me as I am not on this list. - 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/
AMD thunderbird oops
I just upgradede my system to an 1200Mhz AMD Athlon Thundirbird (266Mhz FSB) processor / 512Meg of RAM, and an Asus kt7a motherboard. It is oppsing left and right. I recompiled the kernel with Athelon as the CPU but keep getting these oopses.. I also get these same problems while trying to install RH 7.1 Anyone know is this a supported processor / MB and has anyone had these problems? Joe please cc me as I am not on this list. - 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: Re: /proc & xml data
Um, I'd have to say that putting one value in a file with a directory as a grouping would probably be a nightmare to maintain as well as navigate through. In essance you could end up with more files in the /proc than on the rest of the filesystem filesystem (excluding the /dev dir). It would start to have the whole proc tree look like something from /proc/sys/net/ipv4. Although the /proc/sys/net/ipv4 probably needs to have one value in a file as some of these are settable on from the console, other fiels that are not changable (like /proc/meminfo, proc/cpuinfo etc) would be a waste in one value per file. Isn't the /proc supposed to be a 'friendly' interface into the kernel? Anyway it was a more of a question. > I > was wondering if anyone had ever considered storing some of the data in > xml format rather than its current format? Things like /proc/meminfo > and cpuinfo may work good in this format as then it would be easy to > write a generic xml parser that could then be used to parse any of the > data. "MemTotal: %8lu kB\n" > > In the case of the meminfo it would be a matter of changing the lines in > fs/proc/array.c function get_meminfo(char * buffer) from > > "MemTotal: %8lu kB\n" > > to something like > > "%8lu kB\n" The general consensus is that if we have a major reorganization, in proc the rule will be one value per file. And let directories do the grouping. Eric - 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: Re: /proc xml data
Um, I'd have to say that putting one value in a file with a directory as a grouping would probably be a nightmare to maintain as well as navigate through. In essance you could end up with more files in the /proc than on the rest of the filesystem filesystem (excluding the /dev dir). It would start to have the whole proc tree look like something from /proc/sys/net/ipv4. Although the /proc/sys/net/ipv4 probably needs to have one value in a file as some of these are settable on from the console, other fiels that are not changable (like /proc/meminfo, proc/cpuinfo etc) would be a waste in one value per file. Isn't the /proc supposed to be a 'friendly' interface into the kernel? Anyway it was a more of a question. I was wondering if anyone had ever considered storing some of the data in xml format rather than its current format? Things like /proc/meminfo and cpuinfo may work good in this format as then it would be easy to write a generic xml parser that could then be used to parse any of the data. "MemTotal: %8lu kB\n" In the case of the meminfo it would be a matter of changing the lines in fs/proc/array.c function get_meminfo(char * buffer) from "MemTotal: %8lu kB\n" to something like "%8lu kB\n" The general consensus is that if we have a major reorganization, in proc the rule will be one value per file. And let directories do the grouping. Eric - 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/
