Anyone have a motherboard that uses the nForce4 chipset and running under SuSe 9.3? Just want to confirm it's support before purchasing. Thank you, Brad Dameron SeaTab Software www.seatab.com
Brad: My experience is that nVidia chips are quite well supported on SUSE. NVidia even produces their own Linux drivers freely available at their web site. Chuck Davis On Tuesday 22 November 2005 14:02, Brad Dameron wrote:
Anyone have a motherboard that uses the nForce4 chipset and running under SuSe 9.3? Just want to confirm it's support before purchasing.
Thank you, Brad Dameron SeaTab Software www.seatab.com
On 23/11/05, Brad Dameron
Anyone have a motherboard that uses the nForce4 chipset and running under SuSe 9.3? Just want to confirm it's support before purchasing.
Thank you, Brad Dameron SeaTab Software www.seatab.com
We were getting kernel panics with an nForce4 chipset with suse 9.3 and 10.0 and Centos 4.2 FWIW. Our RAID wouldn't work. Turned out to be an issue with nForce4 which is now fixed due to a beta bios update for the mainboard from a our friendly and very response vendor... "the original NVIDIA nForce4 SLI chipset BIOS has the problem after Bridge IRQ routing" http://60.248.88.210/faq/index.php?action=article&cat_id=004&id=32&lang=en&highlight=nvidia HTH, matt.
* Brad Dameron (brad@seatab.com) [20051122 23:04]:
Anyone have a motherboard that uses the nForce4 chipset and running under SuSe 9.3? Just want to confirm it's support before purchasing.
I have been using a nForce4 mobo (MSI Neo4 Platinum) under both 9.3 and 10.0 the only thing not working reliably is the nForce Ethernet port. But as this mobo also has a second Ethernet port driven by a Marvel Yukon chip, this didn't bother me much. Philipp
On Thursday 24 November 2005 16:45, Philipp Thomas wrote:
I have been using a nForce4 mobo (MSI Neo4 Platinum) under both 9.3 and 10.0 the only thing not working reliably is the nForce Ethernet port. But as this mobo also has a second Ethernet port driven by a Marvel Yukon chip, this didn't bother me much.
I've seven nForce4 PCs (ASUS A8N-E), and no problem with the Ethernet ports (all communicate with >100MB/s when using netcat). I use the reverse engineered nforce driver, which is default in SuSE 10.0 (i.e. no manual interference to get the network right). I have to set clock=pmtmr to get a sufficiently stable clock for ntp on four of the seven boards, but that may be due to having dual-core Athlons in them (TSC and clock stepping conflicts?). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
On Thursday 24 November 2005 17:01, Bernd Paysan wrote:
I have to set clock=pmtmr to get a sufficiently stable clock for ntp on four of the seven boards, but that may be due to having dual-core Athlons in them (TSC and clock stepping conflicts?).
To be a bit more precise: All of them have dual-cores inside, but three had an acceptable drift with default PIT/TSC timing (less than 500ppm). One even has comparable accuracy to the pmtmr ones. They all sync to a single local ntp stratum 2 server, which has a HPET based timing (a dual-opteron server). That's the only board I've ever seen in years where I can't use PIT/TSC (on four out of seven!). There are several other Linux PCs in the office, and two at home, and all work fine with PIT/TSC, except the dual-Opteron system (running SuSE 9.3), which needs the HPET timer, since the TSC based timekeeping doesn't work with different CPUs having different speeds. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
On Thursday 24 November 2005 21:36, Bernd Paysan wrote:
That's the only board I've ever seen in years where I can't use PIT/TSC (on four out of seven!). There are several other Linux PCs in the office, and two at home, and all work fine with PIT/TSC, except the dual-Opteron system (running SuSE 9.3), which needs the HPET timer, since the TSC based timekeeping doesn't work with different CPUs having different speeds.
After a bit more investigation, it turned out that it is indeed the TSC-problem with dual cores. Setting the option "clock=pmtmr notsc" is mandatory on a dual-core Athlon, despite the TSC desynchronization is very small over time. What I don't understand is why there is any TSC desynchronization at all. The two cores run at the same frequency all the time, anyway (you can't set one to 1GHz and the other to 2GHz via Cool'n'Quiet). That's why the problem doesn't show up for a while, and some random component is necessary to see the full effect. Conclusion: You can't rely on the TSC if you have more than one CPU, and a power-saving policy in effect. It would be better to switch the stuff off automatically in that case - until AMD and Intel deliver CPUs with synchronized TSCs next year. Or to resynchronize the TSCs after each frequency change (using the PIT or PM timer as reference then). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
Am So 27.11.2005 00:26 schrieb Bernd Paysan
On Thursday 24 November 2005 21:36, Bernd Paysan wrote:
That's the only board I've ever seen in years where I can't use PIT/TSC (on four out of seven!). There are several other Linux PCs in the office, and two at home, and all work fine with PIT/TSC, except the dual-Opteron system (running SuSE 9.3), which needs the HPET timer, since the TSC based timekeeping doesn't work with different CPUs having different speeds.
After a bit more investigation, it turned out that it is indeed the TSC-problem with dual cores. Setting the option "clock=pmtmr notsc" is mandatory on a dual-core Athlon, despite the TSC desynchronization is very small over time.
clock=pmtmr is a nop on 64bit kernels (or rather you created a "clock" variable in init's environment). The 10.0 CD kernel indeed needs notsc on single socket dual core AMD to avoid a small drift, the next update kernel will automatically enable that. All kernels from other releases should be ok.
What I don't understand is why there is any TSC desynchronization at all. The two cores run at the same frequency all the time, anyway (you can't set one to 1GHz and the other to 2GHz via Cool'n'Quiet). That's why the problem doesn't show up for a while, and some random component is necessary to see the full effect.
There is a small loss in the TSC when the cores enter/exit HLT. Depending on the workload this can add up and lead to slow drift.
Conclusion: You can't rely on the TSC if you have more than one CPU, and a power-saving policy in effect.
It depends on the system. On most Intel systems the TSC is fully synchronized for once. And the HLT loss has also nothing to do with powernow P states (if that is what you mean with "power saving policy"), but is related to C states.
It would be better to switch the stuff off automatically in that case -
That is already done now.
until AMD and Intel deliver CPUs with synchronized TSCs next year.
All 64bit Intel CPUs already have synchronized TSCs.
Or to resynchronize the TSCs after each frequency change (using the PIT or PM timer as reference then).
You're misunderstanding the issue I think. CPU frequency scaling is already handled properly at runtime. -Andi
Hi Andreas, Can I clarify something, clock=pmtmr is a "nop"? Does this mean that the argument is not recognised by the kernel, and therefore ignored? So notsc is the *only* thing that will make a difference in SuSE10? Frequency scaling, this is something that is done by powersaved? And wasn't being done correctly? What were the implications of this? I have followed the the fix suggested by Bernd in the thread "Re: [suse-amd64] BUG in powersaved: cpufreq unreliable with Athlon64 X2 (dual core)", but haven't really noticed any difference in my machine. Last thing, should we consider AMD64X2 CPUs to be faulty? By that, I mean that if there is a revised version of the CPU in the pipeline which fixes these timing issues, should we be asking AMD for replacements? Best wishes, Jon. Andreas Kleen wrote:
Am So 27.11.2005 00:26 schrieb Bernd Paysan
: On Thursday 24 November 2005 21:36, Bernd Paysan wrote:
That's the only board I've ever seen in years where I can't use PIT/TSC (on four out of seven!). There are several other Linux PCs in the office, and two at home, and all work fine with PIT/TSC, except the dual-Opteron system (running SuSE 9.3), which needs the HPET timer, since the TSC based timekeeping doesn't work with different CPUs having different speeds.
After a bit more investigation, it turned out that it is indeed the TSC-problem with dual cores. Setting the option "clock=pmtmr notsc" is mandatory on a dual-core Athlon, despite the TSC desynchronization is very small over time.
clock=pmtmr is a nop on 64bit kernels (or rather you created a "clock" variable in init's environment). The 10.0 CD kernel indeed needs notsc on single socket dual core AMD to avoid a small drift, the next update kernel will automatically enable that. All kernels from other releases should be ok.
What I don't understand is why there is any TSC desynchronization at all. The two cores run at the same frequency all the time, anyway (you can't set one to 1GHz and the other to 2GHz via Cool'n'Quiet). That's why the problem doesn't show up for a while, and some random component is necessary to see the full effect.
There is a small loss in the TSC when the cores enter/exit HLT. Depending on the workload this can add up and lead to slow drift.
Conclusion: You can't rely on the TSC if you have more than one CPU, and a power-saving policy in effect.
It depends on the system. On most Intel systems the TSC is fully synchronized for once. And the HLT loss has also nothing to do with powernow P states (if that is what you mean with "power saving policy"), but is related to C states.
It would be better to switch the stuff off automatically in that case -
That is already done now.
until AMD and Intel deliver CPUs with synchronized TSCs next year.
All 64bit Intel CPUs already have synchronized TSCs.
Or to resynchronize the TSCs after each frequency change (using the PIT or PM timer as reference then).
You're misunderstanding the issue I think. CPU frequency scaling is already handled properly at runtime.
-Andi
-- Jonathan Brooks (Ph.D.) Research Assistant. PaIN Group, Department of Human Anatomy & Genetics, University of Oxford, South Parks Road, Oxford, OX1 3QX tel: +44(0)1865-282654 fax: +44(0)1865-282656 web: http://www.fmrib.ox.ac.uk/~jon
On Mon, Nov 28, 2005 at 04:17:47PM +0000, Jonathan Brooks wrote:
Can I clarify something, clock=pmtmr is a "nop"? Does this mean that the argument is not recognised by the kernel, and therefore ignored? So notsc is the *only* thing that will make a difference in SuSE10?
That is what I wrote yes. (for 64bit, it's a valid 32bit argument)
Frequency scaling, this is something that is done by powersaved? And
Yes.
wasn't being done correctly? What were the implications of this? I have
It's done correctly. Bernd's mistake was to think it was related to it (there are some other timer issues mostly on a few broken laptops related to it, but not that one)
followed the the fix suggested by Bernd in the thread "Re: [suse-amd64] BUG in powersaved: cpufreq unreliable with Athlon64 X2 (dual core)", but haven't really noticed any difference in my machine.
Last thing, should we consider AMD64X2 CPUs to be faulty? By that, I mean that if there is a revised version of the CPU in the pipeline which fixes these timing issues, should we be asking AMD for replacements?
No, in this case it was just an overeager software optimization. But they don't guarantee that the TSCs are synchronized, so software was wrong in assuming that. The update kernel will use the slower but safer timer access which avoid this. Basically it just sets notsc automatically in this case. -Andi P.S.: AFAIK as I know this is the only timer problem that is actually to blame on software. All the others are just various hardware bugs that the kernel just hasn't properly work arounded yet. Please don't ask me for details.
I've seven nForce4 PCs (ASUS A8N-E), and no problem with the Ethernet ports (all communicate with >100MB/s when using netcat).
Mobo specs usually mention some PHY chip in connection with the gigabit ethernet. Common is something marvell, and CICADA8201. Does this PHY thing affect the kernel device driver at all, or is it some kind of line transceiver like the historic MC1488/89 for RS232C? Because if it doesn't affect the software, one can conclude that the gigabit ethernet on nforce4 chipset mobos works reliably with 10.0. Did you test all the other peripherals on this Asus A8N-E? Specifically, does SATA work OOTB? How about lm_sensors? Thanks, Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
On Friday 25 November 2005 00:41, Volker Kuhlmann wrote:
I've seven nForce4 PCs (ASUS A8N-E), and no problem with the Ethernet ports (all communicate with >100MB/s when using netcat).
Mobo specs usually mention some PHY chip in connection with the gigabit ethernet. Common is something marvell, and CICADA8201. Does this PHY thing affect the kernel device driver at all, or is it some kind of line transceiver like the historic MC1488/89 for RS232C?
The PHY chip really is just a transceiver. Ethernet uses a rather high voltage, so you can't connect a modern chip (with maximum 3.3V IO voltage) directly. I don't see any reason how the PHY chip can affect the software layer.
Because if it doesn't affect the software, one can conclude that the gigabit ethernet on nforce4 chipset mobos works reliably with 10.0.
Did you test all the other peripherals on this Asus A8N-E? Specifically, does SATA work OOTB? How about lm_sensors?
Yes, SATA works OOTB, and if you insmod it87 and i2c_isa, sensors works, too (needs a bit tweaking, if you want meaningful measurements). Audio works fine, too, as well as USB. The only untested peripheral is the floppy controller - who needs a floppy drive today, anyway (ok, people who want to install Windows on a SATA drive, but who wants to do that ;-). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
Am Fr 25.11.2005 11:10 schrieb Bernd Paysan
On Friday 25 November 2005 00:41, Volker Kuhlmann wrote:
I've seven nForce4 PCs (ASUS A8N-E), and no problem with the Ethernet ports (all communicate with >100MB/s when using netcat).
Mobo specs usually mention some PHY chip in connection with the gigabit ethernet. Common is something marvell, and CICADA8201. Does this PHY thing affect the kernel device driver at all, or is it some kind of line transceiver like the historic MC1488/89 for RS232C?
The PHY chip really is just a transceiver. Ethernet uses a rather high voltage, so you can't connect a modern chip (with maximum 3.3V IO voltage) directly. I don't see any reason how the PHY chip can affect the software layer.
The driver has to program the PHY to correctly set up link speeds and auto negotation. While the Ethernet PHY software interface is in theory standardized in practice there are differences in the programming interfaces between the different PHYs. So occasionally you need driver changes for a new PHY.
Because if it doesn't affect the software, one can conclude that the gigabit ethernet on nforce4 chipset mobos works reliably with 10.0.
It normally should. -Andi
participants (9)
-
Andi Kleen
-
Andreas Kleen
-
Bernd Paysan
-
Brad Dameron
-
Chuck Davis
-
Jonathan Brooks
-
Matt Hurd
-
Philipp Thomas
-
Volker Kuhlmann