David P. Reed [EMAIL PROTECTED] writes:
ANy help/suggestions?
Use a variable for the port and and do a early quirk to change
the port to something safe on your chipset?
Ok there might be code using outb_p() before the early quirks,
but should be possible to find using instrumentation.
Also
8uS is an ISA bus transaction.
You very likely know better but just in case you're confused -- I thought it
was 8 cycles...
I'll double check. Its a long time since I stuck a scope on an ISA bus
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
On Fri, 07 Dec 2007 19:45:25 +0100
Rene Herman [EMAIL PROTECTED] wrote:
On 07-12-07 18:19, Alan Cox wrote:
On Fri, 7 Dec 2007 17:31:16 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
You don't need to. Port 0x80 historically is about 8uS so just udelay(8)
and make sure the initial default
On Fri, 7 Dec 2007 17:31:16 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
You don't need to. Port 0x80 historically is about 8uS so just udelay(8)
and make sure the initial default delay is conservative enough before the
How would you make it conservative enough handling let's say a 6Ghz CPU
On 07-12-07 08:17, Rene Herman wrote:
On 07-12-07 06:54, David P. Reed wrote:
Pardon my ignorance, but is port 0xed really safe to push an out cycle
at across the entire x86_64 family?
Please do not top-post. Who knows, probably not. You just experienced
that 0x80 is apparently not safe
On 07-12-07 06:54, David P. Reed wrote:
Pardon my ignorance, but is port 0xed really safe to push an out cycle
at across the entire x86_64 family?
Please do not top-post. Who knows, probably not. You just experienced that
0x80 is apparently not safe for you and that one's the conventional
Pardon my ignorance, but is port 0xed really safe to push an out cycle
at across the entire x86_64 family? How long must real _p pauses be in
reality? (and who cares about what the code calls "really slow i/o").
Why are we waiting at all? I read the comments in io_64.h, and am a bit
On 07-12-07 01:23, Robert Hancock wrote:
David P. Reed wrote:
After much, much testing (months, off and on, pursuing hypotheses),
I've discovered that the use of "outb al,0x80" instructions to "delay"
after inb and outb instructions causes solid freezes on my HP dv9000z
laptop, when ACPI is
David P. Reed wrote:
After much, much testing (months, off and on, pursuing hypotheses), I've
discovered that the use of "outb al,0x80" instructions to "delay" after
inb and outb instructions causes solid freezes on my HP dv9000z laptop,
when ACPI is enabled.
It takes a fair number of out's
> Changing the delay instruction sequence from the outb to short jumps
> might be the safe thing. But Linus, et al. may have experience with
> that on other architectures like older Pentiums etc.
Post boot we can use udelay() for this. Earlier I guess we could use
udelay and make sure it
After much, much testing (months, off and on, pursuing hypotheses), I've
discovered that the use of "outb al,0x80" instructions to "delay" after
inb and outb instructions causes solid freezes on my HP dv9000z laptop,
when ACPI is enabled.
It takes a fair number of out's to 0x80, but the hard
After much, much testing (months, off and on, pursuing hypotheses), I've
discovered that the use of outb al,0x80 instructions to delay after
inb and outb instructions causes solid freezes on my HP dv9000z laptop,
when ACPI is enabled.
It takes a fair number of out's to 0x80, but the hard
Changing the delay instruction sequence from the outb to short jumps
might be the safe thing. But Linus, et al. may have experience with
that on other architectures like older Pentiums etc.
Post boot we can use udelay() for this. Earlier I guess we could use
udelay and make sure it starts
David P. Reed wrote:
After much, much testing (months, off and on, pursuing hypotheses), I've
discovered that the use of outb al,0x80 instructions to delay after
inb and outb instructions causes solid freezes on my HP dv9000z laptop,
when ACPI is enabled.
It takes a fair number of out's to
On 07-12-07 01:23, Robert Hancock wrote:
David P. Reed wrote:
After much, much testing (months, off and on, pursuing hypotheses),
I've discovered that the use of outb al,0x80 instructions to delay
after inb and outb instructions causes solid freezes on my HP dv9000z
laptop, when ACPI is
Pardon my ignorance, but is port 0xed really safe to push an out cycle
at across the entire x86_64 family? How long must real _p pauses be in
reality? (and who cares about what the code calls really slow i/o).
Why are we waiting at all? I read the comments in io_64.h, and am a bit
On 07-12-07 08:17, Rene Herman wrote:
On 07-12-07 06:54, David P. Reed wrote:
Pardon my ignorance, but is port 0xed really safe to push an out cycle
at across the entire x86_64 family?
Please do not top-post. Who knows, probably not. You just experienced
that 0x80 is apparently not safe
On 07-12-07 06:54, David P. Reed wrote:
Pardon my ignorance, but is port 0xed really safe to push an out cycle
at across the entire x86_64 family?
Please do not top-post. Who knows, probably not. You just experienced that
0x80 is apparently not safe for you and that one's the conventional
201 - 218 of 218 matches
Mail list logo
