For reasons I won't go into to much, the kernel dumping stuff to port 80 is causing me problems as I use port 80 for something else (some homebrew hardware plugged into my PCI bus) Generally port 80 is only used by the post code in the Bios to output debugging information. When I built my hardware I assumed that after post was complete nothing would be written to 0x80 so it was safe for me to use. Well with any other OS that is true, but Linus has done a dirty hack to fix I/O timing in the kernel. I love having the kernel source :o) Found this gem in /usr/src/linux/include/asm/io.h * Thanks to James van Artsdalen for a better timing-fix than * the two short jumps: using outb's to a nonexistent port seems * to guarantee better timings even on fast machines. * * On the other hand, I'd like to be sure of a non-existent port: * I feel a bit unsafe about using 0x80 (should be safe, though) * * Linus */ #ifdef SLOW_IO_BY_JUMPING #define __SLOW_DOWN_IO "\njmp 1f\n1:\tjmp 1f\n1:" #else #define __SLOW_DOWN_IO "\noutb %%al,$0x80" #endif #ifdef REALLY_SLOW_IO #define __FULL_SLOW_DOWN_IO __SLOW_DOWN_IO __SLOW_DOWN_IO __SLOW_DOWN_IO __SLOW_DOWN_IO #else #define __FULL_SLOW_DOWN_IO __SLOW_DOWN_IO #endif Can any of you think of any other port I can get the kernel to write this to that would have the same effect of slowing down I/O but wouldn't be used by any other hardware ? I've got to re-compile the kernel anyway (to sort out ATM support once and for all on my machine) and I want to add the preemptive patch as well Of course the "better" way would be to fix my hardware, but the only way I can do that is to recode the PIC (microcontroller) I am using but at the moment I can't find the PIC source and it would take me a long time to rewrite. Wayne
Hi Wayne There are a number of holes in the IO map that you could use - The game adaptor port at 0x200-0x20f is one. Another space that is unlikely to be use is at 0x2e2-0x2e3 which is listed as "Data Acquisition Adaptor". Two other options for you to consider.. 1) Use dummy jumps as in SLOW_IO_BY_JUMPING 2) use a nanosleep or esleep call, a 4uSec delay should be enough. Regards, Paul. On Sunday 22 Sep 2002 1:09 pm, Wayne Stallwood wrote:
Can any of you think of any other port I can get the kernel to write this to that would have the same effect of slowing down I/O but wouldn't be used by any other hardware ?
Thanks, 0x2e2 it is then, When I get a moment I'll give this a go. I thought that a sleep call would be the obvious solution, but I keep thinking that there is a reason Linus didn't do this, I was put off the dummy jumps as Linus infers that this causes a problem on faster machines, given that this was written at a time when a P500 was a fast machine and I am sitting on a 1Ghz Athlon I think there may be some issue with doing this. Anyway cheers, I'll let you know if it works. On Sunday 22 September 2002 12:36, Paul wrote:
Hi Wayne
There are a number of holes in the IO map that you could use - The game adaptor port at 0x200-0x20f is one. Another space that is unlikely to be use is at 0x2e2-0x2e3 which is listed as "Data Acquisition Adaptor".
Two other options for you to consider.. 1) Use dummy jumps as in SLOW_IO_BY_JUMPING 2) use a nanosleep or esleep call, a 4uSec delay should be enough.
Regards, Paul.
On Sunday 22 Sep 2002 1:09 pm, Wayne Stallwood wrote:
Can any of you think of any other port I can get the kernel to write this to that would have the same effect of slowing down I/O but wouldn't be used by any other hardware ?
_______________________________________________ main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
Like all good things this was best done after a few pints down the pub :o) Anyway Paul's suggestion of moving the garbage data from 0x80 to the Data Acquisition ports on 0x2e2-0x2e3 worked beautifully (I changed it to 0x2e2), and so far I have seen no side effects on my system....Thanks Paul Wayne On Sunday 22 September 2002 20:15, Wayne Stallwood wrote:
Thanks, 0x2e2 it is then, When I get a moment I'll give this a go.
I thought that a sleep call would be the obvious solution, but I keep thinking that there is a reason Linus didn't do this, I was put off the dummy jumps as Linus infers that this causes a problem on faster machines, given that this was written at a time when a P500 was a fast machine and I am sitting on a 1Ghz Athlon I think there may be some issue with doing this.
Anyway cheers, I'll let you know if it works.
On Sunday 22 September 2002 12:36, Paul wrote:
Hi Wayne
There are a number of holes in the IO map that you could use - The game adaptor port at 0x200-0x20f is one. Another space that is unlikely to be use is at 0x2e2-0x2e3 which is listed as "Data Acquisition Adaptor".
Two other options for you to consider.. 1) Use dummy jumps as in SLOW_IO_BY_JUMPING 2) use a nanosleep or esleep call, a 4uSec delay should be enough.
Regards, Paul.
On Sunday 22 Sep 2002 1:09 pm, Wayne Stallwood wrote:
Can any of you think of any other port I can get the kernel to write this to that would have the same effect of slowing down I/O but wouldn't be used by any other hardware ?
_______________________________________________ main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
_______________________________________________ main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
Why don't you ask Linus himself, or at least post it to the LKML ? The comment suggests he wasn't totally happy with the solution, he'd probably like to hear from anyone it has bitten. (of cause moving it to port 0x2E2 is likely to bite someone else). The worst he can do is ignore you 8-) Mike On Sun, 2002-09-22 at 21:15, Wayne Stallwood wrote:
Thanks, 0x2e2 it is then, When I get a moment I'll give this a go.
I thought that a sleep call would be the obvious solution, but I keep thinking that there is a reason Linus didn't do this, I was put off the dummy jumps as Linus infers that this causes a problem on faster machines, given that this was written at a time when a P500 was a fast machine and I am sitting on a 1Ghz Athlon I think there may be some issue with doing this.
Anyway cheers, I'll let you know if it works.
On Sunday 22 September 2002 12:36, Paul wrote:
Hi Wayne
There are a number of holes in the IO map that you could use - The game adaptor port at 0x200-0x20f is one. Another space that is unlikely to be use is at 0x2e2-0x2e3 which is listed as "Data Acquisition Adaptor".
Two other options for you to consider.. 1) Use dummy jumps as in SLOW_IO_BY_JUMPING 2) use a nanosleep or esleep call, a 4uSec delay should be enough.
Regards, Paul.
On Sunday 22 Sep 2002 1:09 pm, Wayne Stallwood wrote:
Can any of you think of any other port I can get the kernel to write this to that would have the same effect of slowing down I/O but wouldn't be used by any other hardware ?
_______________________________________________ main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
_______________________________________________ main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
Good idea, Mail being written right now :o) On Sunday 22 September 2002 22:52, Mike Lincoln wrote:
Why don't you ask Linus himself, or at least post it to the LKML ? The comment suggests he wasn't totally happy with the solution, he'd probably like to hear from anyone it has bitten. (of cause moving it to port 0x2E2 is likely to bite someone else).
The worst he can do is ignore you 8-)
Mike
On Sun, 2002-09-22 at 21:15, Wayne Stallwood wrote:
Thanks, 0x2e2 it is then, When I get a moment I'll give this a go.
I thought that a sleep call would be the obvious solution, but I keep thinking that there is a reason Linus didn't do this, I was put off the dummy jumps as Linus infers that this causes a problem on faster machines, given that this was written at a time when a P500 was a fast machine and I am sitting on a 1Ghz Athlon I think there may be some issue with doing this.
Anyway cheers, I'll let you know if it works.
On Sunday 22 September 2002 12:36, Paul wrote:
Hi Wayne
There are a number of holes in the IO map that you could use - The game adaptor port at 0x200-0x20f is one. Another space that is unlikely to be use is at 0x2e2-0x2e3 which is listed as "Data Acquisition Adaptor".
Two other options for you to consider.. 1) Use dummy jumps as in SLOW_IO_BY_JUMPING 2) use a nanosleep or esleep call, a 4uSec delay should be enough.
Regards, Paul.
On Sunday 22 Sep 2002 1:09 pm, Wayne Stallwood wrote:
Can any of you think of any other port I can get the kernel to write this to that would have the same effect of slowing down I/O but wouldn't be used by any other hardware ?
_______________________________________________ main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
_______________________________________________ main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
_______________________________________________ main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
Hi Wayne Another alternative to generating a delay of a fixed period would be to use the 8254 or the APIC timer - Neither is a portable solution, and both liable to lcoking up the system if you are not carefull. On balance, perhaps dummy IO writes is the easiest method... On the other hand, a software loop might avoid any IO conflicts.. extern unsigned long cpu_khz; /* clock frequency exported by the kernel */ /* grep /boot/System.map for it - It should be there for 2.4.x kernels. */ for (t=0; t<(time_delay/cpu_khz; t++) ; Regards, Paul. On Sunday 22 Sep 2002 9:15 pm, Wayne Stallwood wrote:
I thought that a sleep call would be the obvious solution, but I keep thinking that there is a reason Linus didn't do this, I was put off the dummy jumps as Linus infers that this causes a problem on faster machines, given that this was written at a time when a P500 was a fast machine and I am sitting on a 1Ghz Athlon I think there may be some issue with doing this.
How about rather than getting the cpu_khz from the system map, using the Bogomips value, Isn't the kernel already aware of this (I thought it used bogomips for some other timing) But I may give your suggestion a go anyway Cheers Wayne On Sunday 22 September 2002 23:09, Paul wrote:
Hi Wayne
Another alternative to generating a delay of a fixed period would be to use the 8254 or the APIC timer - Neither is a portable solution, and both liable to lcoking up the system if you are not carefull. On balance, perhaps dummy IO writes is the easiest method...
On the other hand, a software loop might avoid any IO conflicts..
extern unsigned long cpu_khz; /* clock frequency exported by the kernel */ /* grep /boot/System.map for it - It should be there for 2.4.x kernels. */ for (t=0; t<(time_delay/cpu_khz; t++) ;
Regards, Paul.
On Sunday 22 Sep 2002 9:15 pm, Wayne Stallwood wrote:
I thought that a sleep call would be the obvious solution, but I keep thinking that there is a reason Linus didn't do this, I was put off the dummy jumps as Linus infers that this causes a problem on faster machines, given that this was written at a time when a P500 was a fast machine and I am sitting on a 1Ghz Athlon I think there may be some issue with doing this.
_______________________________________________ main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
Hi Wayne Possibly a slight misunderstanding - cpu_khz along with all the other symbols exported by the kernel should be listed in System.map (symbols exported by a loaded module will be in /proc/ksyms as I understand the kernel). Simply declaring cpu_khz as extern should be sufficient within a kernel module. As allways with linux, there is more than one way of doing things. If writes to an unused IO address is sufficient to do what is required, perhaps software loops are best avoided. On Monday 23 Sep 2002 2:07 am, Wayne Stallwood wrote:
How about rather than getting the cpu_khz from the system map, using the Bogomips value, Isn't the kernel already aware of this (I thought it used bogomips for some other timing)
Ahhhh (a dim light flickers on) Cheers Wayne On Monday 23 September 2002 22:36, Paul wrote:
Hi Wayne
Possibly a slight misunderstanding - cpu_khz along with all the other symbols exported by the kernel should be listed in System.map (symbols exported by a loaded module will be in /proc/ksyms as I understand the kernel). Simply declaring cpu_khz as extern should be sufficient within a kernel module.
As allways with linux, there is more than one way of doing things. If writes to an unused IO address is sufficient to do what is required, perhaps software loops are best avoided.
On Monday 23 Sep 2002 2:07 am, Wayne Stallwood wrote:
How about rather than getting the cpu_khz from the system map, using the Bogomips value, Isn't the kernel already aware of this (I thought it used bogomips for some other timing)
_______________________________________________ main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
participants (3)
-
Mike Lincoln -
Paul -
Wayne Stallwood