lkml.org 
[lkml]   [2007]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
Just a thought for a way to fix the "very early" timing needed to set up 
udelay to work in a way that works on all machines. Perhaps we haven't
exploited the BIOS enough: The PC BIOS since the PC AT (286) has
always had a standard "countdown timer" way to delay for n microseconds,
which as far as I know still works. This can be used to measure the
speed of a delay loop, without using ANY in/out instructions directly
(the ones in the BIOS are presumably correctly delayed...).

So first thing in the boot sequence, one can calibrate a timing loop
using this technique, and save the value to be used for all the "early"
stuff.

Here's skeleton code from old ASM code I found lying around in my
archives to use BIOS to measure how many unrolled short jumps can
execute in 10 msec. Note that it can run without knowing anything
whatsoever about port timing.

haltbyte db 0

calibrate:
les bx,haltbyte ; address of halt flag into es:bx
mov ax,8300h
sub cx,cx
mov dx,10000 ; 10 msec. in cx:dx
int 15h
jc bad
sub dx,dx
sub cx,cx ; decrement counter in dx:cx
tloop:
jmp short $+2 ; 10 short jmps
jmp short $+2
jmp short $+2
jmp short $+2
jmp short $+2
jmp short $+2
jmp short $+2
jmp short $+2
jmp short $+2
test haltbyte
loopz tloop
jnz done
dec dx
jnz tloop

" overflowed 32 bits ... never happens, cancel BIOS event wait.
mov ax,8301h
int 15h
jmp error

done:
mov ax,cx
negl
" here dx:ax contains 32 bit loop count corresponding to 10 msec.
ret ; return 32-bit value


Doc on function 83h of int 15h should be available online.


Alan Cox wrote:
> On Fri, 14 Dec 2007 14:13:46 -0800
> "H. Peter Anvin" <hpa@zytor.com> wrote:
>
>
>> Pavel Machek wrote:
>>
>>> On Fri 2007-12-14 10:02:57, H. Peter Anvin wrote:
>>>
>>>> Ingo Molnar wrote:
>>>>
>>>>> wow, cool fix! (I remember that there were other systems as well that are
>>>>> affected by port 0x80 muckery - i thought we had removed port 0x80
>>>>> accesses long ago.)
>>>>> how about the simpler fix below, as a first-level approach? We can then
>>>>> remove the _p in/out sequences after this.
>>>>>
>>>> I believe this will suffer from the issue that was raised: this will use
>>>> udelay() long before loop calibration (and no, we can't just "be
>>>> conservative" since there is no "conservative" value we can use.)
>>>>
>>> ?? Just initialize bogomips to 6GHz equivalent... and we are fine
>>> until 6GHz cpus come out.
>>>
>> How long will that take to boot on a 386?
>>
>
> Well the dumb approach to fix that would seem to be to initialise it to
>
> cpu->family 3 -> 50MHz 4 -> 300Mhz 5-> etc...
>
> Alan
>
>


\
 
 \ /
  Last update: 2007-12-15 04:07    [W:0.169 / U:0.496 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site