Thread: [Etherboot-developers] I've just checked and ...
Brought to you by:
marty_connor,
stefanhajnoczi
Menu
▾
▴
etherboot-developers
|
From: Ronald G M. <rmi...@la...> - 2002-08-28 22:31:19
|
The 5.0.5 timer.[ch] is identical it seems with the 5.0.7 version. So my 5.0.5 version should be fine with 5.0.7. My version has the "don't use timer2" patch. I am attaching it for all of you to take a look see and comment. I think this might help with my current problems as Smartcore systems don't actually have a TIMER2 -- all timeouts go to 0. ron |
|
From: Eric W B. <ebi...@ln...> - 2002-08-29 23:44:41
|
Ronald G Minnich <rmi...@la...> writes: > The 5.0.5 timer.[ch] is identical it seems with the 5.0.7 version. So my > 5.0.5 version should be fine with 5.0.7. My version has the "don't use > timer2" patch. I am attaching it for all of you to take a look see and > comment. I think this might help with my current problems as Smartcore > systems don't actually have a TIMER2 -- all timeouts go to 0. That certainly looks like a piece of it. Given the rough granularity of i/o to port 0x80. I would rather calibrate the counter on something more precise, if I had the option. Does Linux need a special patch to run on the smartcore? Or how does it calibrate the tsc? Beyond the calibration issues it looks like a good idea. When I have a moment I will see what I can do about incorporating this into 5.1.x. Eric |
|
From: Ronald G M. <rmi...@la...> - 2002-08-30 01:14:15
|
On 29 Aug 2002, Eric W Biederman wrote: > That certainly looks like a piece of it. Given the rough granularity > of i/o to port 0x80. I would rather calibrate the counter on > something more precise, if I had the option. I wish I could think of something. > Does Linux need a special patch to run on the smartcore? Or how does > it calibrate the tsc? You know, I don't know. We just diagnosed the problem and applied this fix, and linux seemed to be happy. I never looked at this. Now you've made me curious :-) ron |
|
From: <ebi...@ln...> - 2002-08-30 04:12:41
|
Ronald G Minnich <rmi...@la...> writes: > On 29 Aug 2002, Eric W Biederman wrote: > > > That certainly looks like a piece of it. Given the rough granularity > > of i/o to port 0x80. I would rather calibrate the counter on > > something more precise, if I had the option. > > I wish I could think of something. > > > Does Linux need a special patch to run on the smartcore? Or how does > > it calibrate the tsc? > > You know, I don't know. We just diagnosed the problem and applied this > fix, and linux seemed to be happy. I never looked at this. Now you've made > me curious :-) If Linux has something fairly universal for x86 we can use that, otherwise I want a config option. As much as possible I prefer precise delays, so that things work as much the same as possible between different machines. Already the user base is spread out enough it can be a challenge to reproduce another users problems. Eric |
|
From: Ronald G M. <rmi...@la...> - 2002-08-30 13:08:21
|
On 29 Aug 2002, Eric W. Biederman wrote: > > > Does Linux need a special patch to run on the smartcore? Or how does > > > it calibrate the tsc? > > > > You know, I don't know. We just diagnosed the problem and applied this > > fix, and linux seemed to be happy. I never looked at this. Now you've made > > me curious :-) > > If Linux has something fairly universal for x86 we can use that, > otherwise I want a config option. If you mean for etherboot, that timer.c code I sent in has two modes op operation: - Plain 'ol TIMER2 mode, which is the default - The other mode, creating timing by POST to port 0x80, enabled by: CONFIG_NO_TIMER2 Does that fit the requirement? ron |
|
From: Eric W B. <ebi...@ln...> - 2002-08-31 06:07:11
|
Ronald G Minnich <rmi...@la...> writes: > The 5.0.5 timer.[ch] is identical it seems with the 5.0.7 version. So my > 5.0.5 version should be fine with 5.0.7. My version has the "don't use > timer2" patch. I am attaching it for all of you to take a look see and > comment. I think this might help with my current problems as Smartcore > systems don't actually have a TIMER2 -- all timeouts go to 0. > > ron Ron in playing with this code I wanted to see how accurate it's estimates were. > // this is the "no timer2" version. > // to calibrate tsc, we get a TSC reading, then to 1,000,000 outbs to port 0x80 > // then we read TSC again, and divide the difference by 1,000,000 > // we have found on a wide range of machines that this gives us a a good > microsecond value > > // to +- 10%. On a dual AMD 1.6 Ghz box, it gives us .97 microseconds, and on a > > // 267 Mhz. p5, it gives us 1.1 microseconds. > // also, since gcc now supports long long, we use that. > // also no unsigned long long / operator, so we play games. > // about the only thing you can do with long longs, it seems, is return them and > assign them. I am getting a reading of about 1.37 to 1.4 microseconds for an outb, on a dual 2.4 Xeon. I guess this isn't too bad as the delays will take longer than expected with an estimate of 1.0 microsecond per outb. But the estimate is so inaccurate at + 40% that I'm not really certain it is useful. Eric |
|
From: Ronald G M. <rmi...@la...> - 2002-08-31 15:13:50
|
On 31 Aug 2002, Eric W Biederman wrote: > I am getting a reading of about 1.37 to 1.4 microseconds for an outb, > on a dual 2.4 Xeon. shucks. It was too good to last. I was ok with +- 10%, but 40%? Anyway, I'll see if there's something else we can do. But I think you might want to leave this in for the "if all else fails" case. time for plan b. ron |
|
From: <ebi...@ln...> - 2002-09-01 08:55:09
|
Ronald G Minnich <rmi...@la...> writes: > On 31 Aug 2002, Eric W Biederman wrote: > > > I am getting a reading of about 1.37 to 1.4 microseconds for an outb, > > on a dual 2.4 Xeon. > > shucks. It was too good to last. I was ok with +- 10%, but 40%? > > Anyway, I'll see if there's something else we can do. But I think you > might want to leave this in for the "if all else fails" case. > > time for plan b. I will keep it around but I would definitely like something better. Eric |
