On 11-12-07 18:00, David P. Reed wrote:
Which port do you want me to test?
Oh, thought your previous reply was already responding to this. The other
diagnostic port, 0xed. The point is not so much that it's going to be a
good alternate solution but to exclude it being a possible solution.
On 11-12-07 18:04, Rene Herman wrote:
On 11-12-07 18:00, David P. Reed wrote:
Which port do you want me to test?
Oh, thought your previous reply was already responding to this. The
other diagnostic port, 0xed. The point is not so much that it's going
to be a good alternate solution but to
below, from a list of those I needed to patch to eliminate refs to _b
calls) or arch specific code (also listed below), who might know why the
_p macros are actually needed (for any platform)?
Because the controllers were historically slower than the CPU and thus
clocked at half bus speed.
Hi!
Anyways it looks like the discussion here is going in a
a loop. I had hoped David would post his test results with
another port so that we know for sure that the bus aborts (and not port
80) is the problem on his box. But it looks like
he doesn't want to do this. Still removing the bus
On Tue 2007-12-11 18:04:32, Rene Herman wrote:
On 11-12-07 18:00, David P. Reed wrote:
Which port do you want me to test?
Oh, thought your previous reply was already responding to this. The other
diagnostic port, 0xed. The point is not so much that it's going to be a
good alternate
Alan Cox wrote:
The vga driver is somewhat misnamed. In console mode we handle everything
back to MDA/HGA and some HGA adapters do need delays.
No they don't. I really, really, really know this for a fact. I wrote
ASM drivers for every early video adapter and ran them all through
Hi!
a spec sheet, or even better a machine. I may have an original PC-XT
still lying around in the attic, don't know if I can fire it up, but it had
such graphics cards. I also have several early high-speed clones that were
overclocked.
PC-XT does not count ... it needs to be 386
On 11-12-07 20:16, Pavel Machek wrote:
Pavel Machek already posted one. His udelay(8) wants to be less -- 1 or to
be safe perhaps 2.
http://lkml.org/lkml/2007/12/9/131
2 at least; that's how long outb(0x80) takes on one of my
machines. Actually, ISA can go down to 4MHz, so maybe we should
On 11-12-07 20:16, Pavel Machek wrote:
Pavel Machek already posted one. His udelay(8) wants to be less -- 1 or to
be safe perhaps 2.
http://lkml.org/lkml/2007/12/9/131
2 at least; that's how long outb(0x80) takes on one of my
machines. Actually, ISA can go down to 4MHz, so maybe we should
On 11-12-07 20:16, Pavel Machek wrote:
Pavel Machek already posted one. His udelay(8) wants to be less -- 1 or to
be safe perhaps 2.
http://lkml.org/lkml/2007/12/9/131
2 at least; that's how long outb(0x80) takes on one of my
machines. Actually, ISA can go down to 4MHz, so maybe we should
On 11-12-07 20:16, Pavel Machek wrote:
Pavel Machek already posted one. His udelay(8) wants to be less -- 1 or to
be safe perhaps 2.
http://lkml.org/lkml/2007/12/9/131
2 at least; that's how long outb(0x80) takes on one of my
machines. Actually, ISA can go down to 4MHz, so maybe we should
And if you choose to be such an insulting
Fine. I won't bother submitting patches to fix this because I don't seem
to care any more. The only person who is suffering seems to have an
attitude problem and the only people I work for with attitude problems
are customers of my employer.
Alan
On Tue, 11 Dec 2007, David P. Reed wrote:
Alan Cox wrote:
The vga driver is somewhat misnamed. In console mode we handle everything
back to MDA/HGA and some HGA adapters do need delays.
No they don't. I really, really, really know this for a fact. I wrote
ASM drivers for every early
On 11-12-07 21:27, linux-os (Dick Johnson) wrote:
I didn't know you worked in Boca Raton for Don Estrage on
the IBM 5150. I must have missed you --somehow.
Frankly, if there ever was a good reason for _not_ merging i386 and x86-64
it would've been having an escape from these kinds of
Dick - I didn't work for Don in Boca. I did know him, having met with
him several times when he was still alive. I worked from 1979-1985 as a
consultant and eventually VP RD, at Software Arts in Cambridge, MA, and
there was a machine we developed the first IBM Visicalc for, in a locked
room
1) I found in a book, the Undocumented PC, that I have lying around that
the pause recommended for some old adapter chips on the ISA bus was 1
usec. The book carefully points out on various models of PCs how many
short jumps are required to implement 1 usec, and suggests that for
faster
Hi,
On Tue, 11 Dec 2007 12:12:59 +1030
David Newall <[EMAIL PROTECTED]> wrote:
> H. Peter Anvin wrote:
> > David Newall wrote:
> >
> > I think a single ISA bus transaction is 1 µs, so two of them back to
> > back should be 2 µs, not 8 µs...
>
> Exactly. You think it's 2us, but the
On 11-12-07 02:25, H. Peter Anvin wrote:
David Newall wrote:
Where did the 8us delay come from? The documentation and source is
careful not to say how long the delay is. Would changing it to, say
1us, be technically wrong? Is code that requires 8us correct?
I think a single ISA bus
Alan Cox wrote:
In any case, my machine does not have an ISA bus. Why should it? It's
a laptop!
Yes it does. The branding spec said "No ISA bus" so it was renamed "LPC"
and hidden internally, but its alive and well.
Well that, plus it was serialized and uses PCI electricals and timing,
Andi Kleen wrote:
My machine in question, for example, needs no waiting within CMOS_READs
at all. And I doubt any other chip/device needs waiting that isn't
I don't know about CMOS, but there were definitely some not too ancient
systems (let's say not more than 10 years) who required IO
David Newall wrote:
Exactly. You think it's 2us, but the documentation doesn't say. The _p
functions are generic inasmuch as they provide an unspecified delay.
Drivers which work across platforms, and which use _p, therefore have
different delays on different platforms. Should the length
David Newall wrote:
H. Peter Anvin wrote:
David Newall wrote:
Where did the 8us delay come from? The documentation and source is
careful not to say how long the delay is. Would changing it to, say
1us, be technically wrong? Is code that requires 8us correct?
I think a single ISA bus
H. Peter Anvin wrote:
David Newall wrote:
Where did the 8us delay come from? The documentation and source is
careful not to say how long the delay is. Would changing it to, say
1us, be technically wrong? Is code that requires 8us correct?
I think a single ISA bus transaction is 1 µs, so
David Newall wrote:
Where did the 8us delay come from? The documentation and source is
careful not to say how long the delay is. Would changing it to, say
1us, be technically wrong? Is code that requires 8us correct?
I think a single ISA bus transaction is 1 µs, so two of them back to
Where did the 8us delay come from? The documentation and source is
careful not to say how long the delay is. Would changing it to, say
1us, be technically wrong? Is code that requires 8us correct?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Rene Herman wrote:
By the way, David, it would be interesting if you could test 0xed. If
your problem is some piece of hardware getting upset at LPC bus aborts
it's not going to matter and we'd know an outb delay is just not an
option on your system at least. You said you could quickly
On Monday 10 December 2007 12:30:53 Krzysztof Halasa wrote:
> Rene Herman <[EMAIL PROTECTED]> writes:
> > Alan, did you double-check that 8 us? I tried to but I seem to not
> > have trustworthy documentation.
>
> I remember 16-bit CPU-driven ISA was able to do 2-3 MB/s transfers,
> that means at
On 10-12-07 12:30, Krzysztof Halasa wrote:
Rene Herman <[EMAIL PROTECTED]> writes:
Alan, did you double-check that 8 us? I tried to but I seem to not
have trustworthy documentation.
I remember 16-bit CPU-driven ISA was able to do 2-3 MB/s transfers,
that means at least 1 Maccesses/second =
> Really?
>
> udelay() seems to use
> ... cpu_data(raw_smp_processor_id()).loops_per_jiffy ..
Ok that should be a good safety
>
> ..so it seems that bug trap is already there... because
> raw_smp_processor_id() will probably just oops...
And I double checked my docs - they say 8 cycles - 1uS
Rene Herman <[EMAIL PROTECTED]> writes:
> Alan, did you double-check that 8 us? I tried to but I seem to not
> have trustworthy documentation.
I remember 16-bit CPU-driven ISA was able to do 2-3 MB/s transfers,
that means at least 1 Maccesses/second = up to 1 microsecond/access.
Perhaps IO
Rene Herman [EMAIL PROTECTED] writes:
Alan, did you double-check that 8 us? I tried to but I seem to not
have trustworthy documentation.
I remember 16-bit CPU-driven ISA was able to do 2-3 MB/s transfers,
that means at least 1 Maccesses/second = up to 1 microsecond/access.
Perhaps IO ports
Really?
udelay() seems to use
... cpu_data(raw_smp_processor_id()).loops_per_jiffy ..
Ok that should be a good safety
..so it seems that bug trap is already there... because
raw_smp_processor_id() will probably just oops...
And I double checked my docs - they say 8 cycles - 1uS
On 10-12-07 12:30, Krzysztof Halasa wrote:
Rene Herman [EMAIL PROTECTED] writes:
Alan, did you double-check that 8 us? I tried to but I seem to not
have trustworthy documentation.
I remember 16-bit CPU-driven ISA was able to do 2-3 MB/s transfers,
that means at least 1 Maccesses/second = up
On Monday 10 December 2007 12:30:53 Krzysztof Halasa wrote:
Rene Herman [EMAIL PROTECTED] writes:
Alan, did you double-check that 8 us? I tried to but I seem to not
have trustworthy documentation.
I remember 16-bit CPU-driven ISA was able to do 2-3 MB/s transfers,
that means at least 1
Rene Herman wrote:
By the way, David, it would be interesting if you could test 0xed. If
your problem is some piece of hardware getting upset at LPC bus aborts
it's not going to matter and we'd know an outb delay is just not an
option on your system at least. You said you could quickly
Where did the 8us delay come from? The documentation and source is
careful not to say how long the delay is. Would changing it to, say
1us, be technically wrong? Is code that requires 8us correct?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
David Newall wrote:
Where did the 8us delay come from? The documentation and source is
careful not to say how long the delay is. Would changing it to, say
1us, be technically wrong? Is code that requires 8us correct?
I think a single ISA bus transaction is 1 µs, so two of them back to
H. Peter Anvin wrote:
David Newall wrote:
Where did the 8us delay come from? The documentation and source is
careful not to say how long the delay is. Would changing it to, say
1us, be technically wrong? Is code that requires 8us correct?
I think a single ISA bus transaction is 1 µs, so
David Newall wrote:
H. Peter Anvin wrote:
David Newall wrote:
Where did the 8us delay come from? The documentation and source is
careful not to say how long the delay is. Would changing it to, say
1us, be technically wrong? Is code that requires 8us correct?
I think a single ISA bus
David Newall wrote:
Exactly. You think it's 2us, but the documentation doesn't say. The _p
functions are generic inasmuch as they provide an unspecified delay.
Drivers which work across platforms, and which use _p, therefore have
different delays on different platforms. Should the length
Andi Kleen wrote:
My machine in question, for example, needs no waiting within CMOS_READs
at all. And I doubt any other chip/device needs waiting that isn't
I don't know about CMOS, but there were definitely some not too ancient
systems (let's say not more than 10 years) who required IO
Alan Cox wrote:
In any case, my machine does not have an ISA bus. Why should it? It's
a laptop!
Yes it does. The branding spec said No ISA bus so it was renamed LPC
and hidden internally, but its alive and well.
Well that, plus it was serialized and uses PCI electricals and timing,
hence
On 11-12-07 02:25, H. Peter Anvin wrote:
David Newall wrote:
Where did the 8us delay come from? The documentation and source is
careful not to say how long the delay is. Would changing it to, say
1us, be technically wrong? Is code that requires 8us correct?
I think a single ISA bus
Hi,
On Tue, 11 Dec 2007 12:12:59 +1030
David Newall [EMAIL PROTECTED] wrote:
H. Peter Anvin wrote:
David Newall wrote:
I think a single ISA bus transaction is 1 µs, so two of them back to
back should be 2 µs, not 8 µs...
Exactly. You think it's 2us, but the documentation doesn't
On 09-12-07 22:25, Pavel Machek wrote:
On Sun 2007-12-09 17:59:08, Andi Kleen wrote:
Yes, i guess switching to udelay at least on newer systems would
be a good idea. I'm not quite sure about systems without TSC though.
Something like this? (Warning, will not probably even compile on
On Sun 2007-12-09 22:29:28, Alan Cox wrote:
> On Sun, 9 Dec 2007 22:25:13 +0100
> Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> > On Sun 2007-12-09 17:59:08, Andi Kleen wrote:
> > > > I mean, we expect 8usec delay -- historical ISA timing -- but when
> > > > _PCI_ card with leds is inserted, it is
On Sun, 9 Dec 2007 22:25:13 +0100
Pavel Machek <[EMAIL PROTECTED]> wrote:
> On Sun 2007-12-09 17:59:08, Andi Kleen wrote:
> > > I mean, we expect 8usec delay -- historical ISA timing -- but when
> > > _PCI_ card with leds is inserted, it is likely to be faster than old
> > > ISA, right?
> >
> >
On Sun 2007-12-09 17:59:08, Andi Kleen wrote:
> > I mean, we expect 8usec delay -- historical ISA timing -- but when
> > _PCI_ card with leds is inserted, it is likely to be faster than old
> > ISA, right?
>
> Yes, i guess switching to udelay at least on newer systems would
> be a good idea. I'm
On Sat 2007-12-08 14:25:02, David P. Reed wrote:
>
>
> Alan Cox wrote:
> >
> >0x80 should be fine for anything PC compatible anyway,
> >its specifically
> >reserved as a debug port and supported for *exactly*
> >that purpose by
> >many chipsets.
> >
> >
> Disagree. The definitions of PC
> I mean, we expect 8usec delay -- historical ISA timing -- but when
> _PCI_ card with leds is inserted, it is likely to be faster than old
> ISA, right?
Yes, i guess switching to udelay at least on newer systems would
be a good idea. I'm not quite sure about systems without TSC though.
-Andi
On Sunday 09 December 2007 13:54:58 you wrote:
> Hi!
>
> > > modern CPU compared to the bus. But the delay really needs to be
> > > something that is about IO port speed. Ok in theory you could try to
> > > measure a outb using RDTSC and then use udelay, but first you would
> > > need
> >
> > You
* Pavel Machek ([EMAIL PROTECTED]) wrote:
> Hi!
> Actually, I've seen few pci cards with leds on port 0x80, and I
> wonder: is our outb_p really correct?
>
> I mean, we expect 8usec delay -- historical ISA timing -- but when
> _PCI_ card with leds is inserted, it is likely to be faster than old
Hi!
> > modern CPU compared to the bus. But the delay really needs to be something
> > that is about IO port speed. Ok in theory you could try to measure
> > a outb using RDTSC and then use udelay, but first you would need
>
> You don't need to. Port 0x80 historically is about 8uS so just
Hi!
modern CPU compared to the bus. But the delay really needs to be something
that is about IO port speed. Ok in theory you could try to measure
a outb using RDTSC and then use udelay, but first you would need
You don't need to. Port 0x80 historically is about 8uS so just udelay(8)
and
* Pavel Machek ([EMAIL PROTECTED]) wrote:
Hi!
Actually, I've seen few pci cards with leds on port 0x80, and I
wonder: is our outb_p really correct?
I mean, we expect 8usec delay -- historical ISA timing -- but when
_PCI_ card with leds is inserted, it is likely to be faster than old
ISA,
On Sunday 09 December 2007 13:54:58 you wrote:
Hi!
modern CPU compared to the bus. But the delay really needs to be
something that is about IO port speed. Ok in theory you could try to
measure a outb using RDTSC and then use udelay, but first you would
need
You don't need to.
I mean, we expect 8usec delay -- historical ISA timing -- but when
_PCI_ card with leds is inserted, it is likely to be faster than old
ISA, right?
Yes, i guess switching to udelay at least on newer systems would
be a good idea. I'm not quite sure about systems without TSC though.
-Andi
--
On Sat 2007-12-08 14:25:02, David P. Reed wrote:
Alan Cox wrote:
0x80 should be fine for anything PC compatible anyway,
its specifically
reserved as a debug port and supported for *exactly*
that purpose by
many chipsets.
Disagree. The definitions of PC compatible are quite
On Sun 2007-12-09 17:59:08, Andi Kleen wrote:
I mean, we expect 8usec delay -- historical ISA timing -- but when
_PCI_ card with leds is inserted, it is likely to be faster than old
ISA, right?
Yes, i guess switching to udelay at least on newer systems would
be a good idea. I'm not
On Sun, 9 Dec 2007 22:25:13 +0100
Pavel Machek [EMAIL PROTECTED] wrote:
On Sun 2007-12-09 17:59:08, Andi Kleen wrote:
I mean, we expect 8usec delay -- historical ISA timing -- but when
_PCI_ card with leds is inserted, it is likely to be faster than old
ISA, right?
Yes, i guess
On Sun 2007-12-09 22:29:28, Alan Cox wrote:
On Sun, 9 Dec 2007 22:25:13 +0100
Pavel Machek [EMAIL PROTECTED] wrote:
On Sun 2007-12-09 17:59:08, Andi Kleen wrote:
I mean, we expect 8usec delay -- historical ISA timing -- but when
_PCI_ card with leds is inserted, it is likely to be
On 09-12-07 22:25, Pavel Machek wrote:
On Sun 2007-12-09 17:59:08, Andi Kleen wrote:
Yes, i guess switching to udelay at least on newer systems would
be a good idea. I'm not quite sure about systems without TSC though.
Something like this? (Warning, will not probably even compile on
On 08-12-07 20:25, David P. Reed wrote:
In any case, my machine does not have an ISA bus. Why should it? It's
a laptop!
A bus is not something with expansion slots. Your machine has an ISA bus, or
LPC rather, if only to hang its BIOS of. That earlier report about BIOS
chips shitting
> The point here is that Linux is NOT using a defined-to-be "unused"
> port. It IS using the "diagnostic" port, and talking to a diagnostic
> device that *is* used, and may be present.
Just like millions of other pieces of software from the same era.
> 2) Start a background task with the
I am going to do a test on another "unused" port.
However, I realized as I was thinking about this. 0x80 is the
"diagnostic device" port. It is not an "unused" port.
Normally, Linux would support a device like the diagnostic device by
providing a character device, called
> In any case, my machine does not have an ISA bus. Why should it? It's
> a laptop!
Yes it does. The branding spec said "No ISA bus" so it was renamed "LPC"
and hidden internally, but its alive and well.
> has already serviced the bus and delivered data! Why put many
> microseconds into the
On Sat, Dec 08, 2007 at 02:25:02PM -0500, David P. Reed wrote:
>
>
> Alan Cox wrote:
> >
> >0x80 should be fine for anything PC compatible anyway, its specifically
> >reserved as a debug port and supported for *exactly* that purpose by
> >many chipsets.
> >
> >
> Disagree. The definitions of
Alan Cox wrote:
0x80 should be fine for anything PC compatible anyway, its specifically
reserved as a debug port and supported for *exactly* that purpose by
many chipsets.
Disagree. The definitions of PC compatible are quite problematic. I
have the advantage over some of you young
Alan Cox wrote:
0x80 should be fine for anything PC compatible anyway, its specifically
reserved as a debug port and supported for *exactly* that purpose by
many chipsets.
Disagree. The definitions of PC compatible are quite problematic. I
have the advantage over some of you young
On Sat, Dec 08, 2007 at 02:25:02PM -0500, David P. Reed wrote:
Alan Cox wrote:
0x80 should be fine for anything PC compatible anyway, its specifically
reserved as a debug port and supported for *exactly* that purpose by
many chipsets.
Disagree. The definitions of PC compatible are
In any case, my machine does not have an ISA bus. Why should it? It's
a laptop!
Yes it does. The branding spec said No ISA bus so it was renamed LPC
and hidden internally, but its alive and well.
has already serviced the bus and delivered data! Why put many
microseconds into the bus,
I am going to do a test on another unused port.
However, I realized as I was thinking about this. 0x80 is the
diagnostic device port. It is not an unused port.
Normally, Linux would support a device like the diagnostic device by
providing a character device, called /dev/post-diagnosis
The point here is that Linux is NOT using a defined-to-be unused
port. It IS using the diagnostic port, and talking to a diagnostic
device that *is* used, and may be present.
Just like millions of other pieces of software from the same era.
2) Start a background task with the maintainers
On 08-12-07 20:25, David P. Reed wrote:
In any case, my machine does not have an ISA bus. Why should it? It's
a laptop!
A bus is not something with expansion slots. Your machine has an ISA bus, or
LPC rather, if only to hang its BIOS of. That earlier report about BIOS
chips shitting
On Wed, Dec 05, 2007 at 11:10:39AM +, Pavel Machek wrote:
> On Fri 2007-12-07 09:50:26, David P. Reed wrote:
> > My machine in question, for example, needs no waiting
> > within CMOS_READs at all. And I doubt any other
> > chip/device needs waiting that isn't already provided by
> > the
> > 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
On Fri 2007-12-07 09:50:26, David P. Reed wrote:
> My machine in question, for example, needs no waiting
> within CMOS_READs at all. And I doubt any other
> chip/device needs waiting that isn't already provided by
> the bus. the i/o to port 80 is very, very odd in this
> context. Actually,
On 07-12-07 19:42, Alan Cox wrote:
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)
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
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 delay is conservative enough before the
How would you make it conservative
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
> 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
that can execute multiple jumps per cycle?
-Andi
--
To unsubscribe from
On 07-12-07 16:43, Rene Herman wrote:
On 07-12-07 15:54, Andi Kleen wrote:
My machine in question, for example, needs no waiting within
CMOS_READs at all. And I doubt any other chip/device needs waiting
that isn't
I don't know about CMOS, but there were definitely some not too ancient
> modern CPU compared to the bus. But the delay really needs to be something
> that is about IO port speed. Ok in theory you could try to measure
> a outb using RDTSC and then use udelay, but first you would need
You don't need to. Port 0x80 historically is about 8uS so just udelay(8)
and make
On 07-12-07 15:54, Andi Kleen wrote:
My machine in question, for example, needs no waiting within CMOS_READs
at all. And I doubt any other chip/device needs waiting that isn't
I don't know about CMOS, but there were definitely some not too ancient
systems (let's say not more than 10 years)
> My machine in question, for example, needs no waiting within CMOS_READs
> at all. And I doubt any other chip/device needs waiting that isn't
I don't know about CMOS, but there were definitely some not too ancient
systems (let's say not more than 10 years) who required IO delays in the
Andi Kleen wrote:
Changing the delay instruction sequence from the outb to short jumps
might be the safe thing.
I don't think that makes sense to do on anything modern. The trouble
is that the jumps will effectively execute near "infinitely fast" on any
modern CPU compared to the bus. But the
Rene Herman <[EMAIL PROTECTED]> writes:
>
> If there are no sensible fixes, an 0x80/0xed choice could I assume be
> hung of DMI or something (if that _is_ parsed soon enough).
Another possibility would be to key this off DMI year (or existence
of DMI year since old systems don't have it). I guess
"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.
Andi Kleen wrote:
Changing the delay instruction sequence from the outb to short jumps
might be the safe thing.
I don't think that makes sense to do on anything modern. The trouble
is that the jumps will effectively execute near infinitely fast on any
modern CPU compared to the bus. But the
My machine in question, for example, needs no waiting within CMOS_READs
at all. And I doubt any other chip/device needs waiting that isn't
I don't know about CMOS, but there were definitely some not too ancient
systems (let's say not more than 10 years) who required IO delays in the
floppy
On 07-12-07 16:43, Rene Herman wrote:
On 07-12-07 15:54, Andi Kleen wrote:
My machine in question, for example, needs no waiting within
CMOS_READs at all. And I doubt any other chip/device needs waiting
that isn't
I don't know about CMOS, but there were definitely some not too ancient
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
that can execute multiple jumps per cycle?
-Andi
--
To unsubscribe from
Rene Herman [EMAIL PROTECTED] writes:
If there are no sensible fixes, an 0x80/0xed choice could I assume be
hung of DMI or something (if that _is_ parsed soon enough).
Another possibility would be to key this off DMI year (or existence
of DMI year since old systems don't have it). I guess it
On 07-12-07 15:54, Andi Kleen wrote:
My machine in question, for example, needs no waiting within CMOS_READs
at all. And I doubt any other chip/device needs waiting that isn't
I don't know about CMOS, but there were definitely some not too ancient
systems (let's say not more than 10 years)
modern CPU compared to the bus. But the delay really needs to be something
that is about IO port speed. Ok in theory you could try to measure
a outb using RDTSC and then use udelay, but first you would need
You don't need to. Port 0x80 historically is about 8uS so just udelay(8)
and make sure
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 delay is conservative enough before the
How would you make it conservative
On Wed, Dec 05, 2007 at 11:10:39AM +, Pavel Machek wrote:
On Fri 2007-12-07 09:50:26, David P. Reed wrote:
My machine in question, for example, needs no waiting
within CMOS_READs at all. And I doubt any other
chip/device needs waiting that isn't already provided by
the bus. the
On Fri 2007-12-07 09:50:26, David P. Reed wrote:
My machine in question, for example, needs no waiting
within CMOS_READs at all. And I doubt any other
chip/device needs waiting that isn't already provided by
the bus. the i/o to port 80 is very, very odd in this
context. Actually,
On 07-12-07 19:42, Alan Cox wrote:
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
101 - 200 of 218 matches
Mail list logo
