noisy smbus?
-----邮件原件----- 发件人: ebiederman@lnxi.com [mailto:ebiederman@lnxi.com] 发送时间: 2003年11月18日 15:17 收件人: Stefan Reinauer 抄送: YhLu; 'linuxbios@clustermatic.org' 主题: Re: About Hardreset on Opteron MB
Stefan Reinauer stepan@suse.de writes:
- YhLu YhLu@tyan.com [031118 22:50]:
I have checked the latest code again for Opteron MB. The MB still needs
to
reset three times to get it done.
Can we only reset the MB only time to make the HT work at the need speed/width?
It should be enough to set a global variable "reset_needed" (maybe even in CMOS) and check this, probably after all device drivers have been executed and thus had the chance to set that flag.
I mean only enable the reset in PCI: 00:19.3 init NB: Function 3 Misc Control.. resetting cpu
When changing the parameters on Solo I always got it to one of the reboots - My best result was to get it to the Misc Control reset before it would hang hard.
Reducing the number of reboots definitely needs to happen. I only coded the way it is currently because that generates obviously correct code.
Right now I am looking at how to reduce problems when a board has a noisy smbus. So far I have not seen a single board without one. In the noisy smbus the more traffic you have the more chances there are you will have problems because of it.
So it might make sense to set everything up in a very early pass before memory reset. Reset the system, and then let the existing resets will not trigger.
Either that or Stefans delayed scheme. At this point I am not certain which will be easier to maintain. If we do implement the delayed reset I want to move the memory clear code up into the generic framework so we don't have to clear memory twice. But if we can get the resets over with before we initialize memory we are in better shape. That plus something like the kernels quirk interface to handle the various know bits of buggy hardware and we should be ok.
Eric
YhLu YhLu@tyan.com writes:
noisy smbus?
smbus or i2c or iic whichever name you want.
Think what happens when you try to read the serial SPD eeprom on the memory and the read fails or the smbus locks up. Basically random peculiar failures.
It depends but when pushing the boot failure rate down from 1 in 100 to 1 in 1000 this is the most common issue that crops up.
This is one of the reason my smbus read code has a timeout on it.
Eric