On 20-02-08 21:13, David P. Reed wrote:
Actually, disparaging things as "one idiotic system" doesn't seem like a
long-term thoughtful process - it's not even accurate.
Whatever we think about systems using port 0x80, fact of the matter is that
they do and outside of legacy stuff that isn't
Actually, disparaging things as "one idiotic system" doesn't seem like a
long-term thoughtful process - it's not even accurate. There are more
such systems that are running code today than the total number of 486
systems ever manufactured. The production rate is $1M/month.
a) ENE chips are
On 20-02-08 18:05, H. Peter Anvin wrote:
Rene Herman wrote:
_Something_ like this would seem to be the only remaining option. It
seems fairly unuseful to #ifdef around that switch statement for
kernels without support for the earlier families, but if you insist...
"Only remaining
Rene Herman wrote:
_Something_ like this would seem to be the only remaining option. It
seems fairly unuseful to #ifdef around that switch statement for kernels
without support for the earlier families, but if you insist...
"Only remaining option" other than the one we've had all along.
On 18-02-08 23:44, H. Peter Anvin wrote:
Rene Herman wrote:
Yes, but generally not any P5+ system is going to need the PIT
delay in the first place meaning it just doesn't matter. There were
the VIA issues with the PIC but unless I missed it not with the PIT.
Uhm, I'm not sure I believe
On 18-02-08 23:44, H. Peter Anvin wrote:
Rene Herman wrote:
Yes, but generally not any P5+ system is going to need the PIT
delay in the first place meaning it just doesn't matter. There were
the VIA issues with the PIC but unless I missed it not with the PIT.
Uhm, I'm not sure I believe
Rene Herman wrote:
_Something_ like this would seem to be the only remaining option. It
seems fairly unuseful to #ifdef around that switch statement for kernels
without support for the earlier families, but if you insist...
Only remaining option other than the one we've had all along.
On 20-02-08 18:05, H. Peter Anvin wrote:
Rene Herman wrote:
_Something_ like this would seem to be the only remaining option. It
seems fairly unuseful to #ifdef around that switch statement for
kernels without support for the earlier families, but if you insist...
Only remaining option
Actually, disparaging things as one idiotic system doesn't seem like a
long-term thoughtful process - it's not even accurate. There are more
such systems that are running code today than the total number of 486
systems ever manufactured. The production rate is $1M/month.
a) ENE chips are
On 20-02-08 21:13, David P. Reed wrote:
Actually, disparaging things as one idiotic system doesn't seem like a
long-term thoughtful process - it's not even accurate.
Whatever we think about systems using port 0x80, fact of the matter is that
they do and outside of legacy stuff that isn't
* David P. Reed <[EMAIL PROTECTED]> wrote:
> x86: use explicit timing delay for pit accesses in kernel and pcspkr
> driver
thanks, applied.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
* David P. Reed [EMAIL PROTECTED] wrote:
x86: use explicit timing delay for pit accesses in kernel and pcspkr
driver
thanks, applied.
Ingo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Rene Herman wrote:
On 18-02-08 23:07, Rene Herman wrote:
On 18-02-08 23:01, H. Peter Anvin wrote:
Rene Herman wrote:
Yes, but generally not any P5+ system is going to need the PIT delay
in the first place meaning it just doesn't matter. There were the
VIA issues with the PIC but unless I
Rene Herman wrote:
Uhm, I'm not sure I believe that's safe.
The PIT is particularly pissy in this case -- the semantics of the PIT
are ill-defined if there hasn't been a PIT clock between two adjacent
accesses, so I fully expect that there are chipsets out there which
will do very bad
On 18-02-08 23:07, Rene Herman wrote:
On 18-02-08 23:01, H. Peter Anvin wrote:
Rene Herman wrote:
Yes, but generally not any P5+ system is going to need the PIT delay
in the first place meaning it just doesn't matter. There were the VIA
issues with the PIC but unless I missed it not with
On 18-02-08 23:01, H. Peter Anvin wrote:
Rene Herman wrote:
Yes, but generally not any P5+ system is going to need the PIT delay
in the first place meaning it just doesn't matter. There were the VIA
issues with the PIC but unless I missed it not with the PIT.
Uhm, I'm not sure I believe
Rene Herman wrote:
Yes, but generally not any P5+ system is going to need the PIT delay in
the first place meaning it just doesn't matter. There were the VIA
issues with the PIC but unless I missed it not with the PIT.
Uhm, I'm not sure I believe that's safe.
The PIT is particularly
On 18-02-08 22:44, H. Peter Anvin wrote:
Rene Herman wrote:
I mean that before the linux kernel used a port 0x80 write as an I/O
delay it used a short jump (two in a row actually...) as such and this
was at the time that it actually ran on the old legacy stuff that is
of most concern here.
Rene Herman wrote:
I mean that before the linux kernel used a port 0x80 write as an I/O
delay it used a short jump (two in a row actually...) as such and this
was at the time that it actually ran on the old legacy stuff that is of
most concern here.
No, if I'm not mistaken, those two jumps
On 18-02-08 22:04, Rene Herman wrote:
On 18-02-08 21:43, H. Peter Anvin wrote:
Rene Herman wrote:
Now with respect to the original pre port 80 "jmp $+2" I/O delay
(which the Pentium obsoleted) I suppose it'll probably be okay even
without fixing that specifically but do note such -- it's a
On 18-02-08 21:43, H. Peter Anvin wrote:
Rene Herman wrote:
Now with respect to the original pre port 80 "jmp $+2" I/O delay
(which the Pentium obsoleted) I suppose it'll probably be okay even
without fixing that specifically but do note such -- it's a vital part
of the problem.
Sorry,
Rene Herman wrote:
Now with respect to the original pre port 80 "jmp $+2" I/O delay (which
the Pentium obsoleted) I suppose it'll probably be okay even without
fixing that specifically but do note such -- it's a vital part of the
problem.
Sorry, that paragraph didn't parse for me.
On 18-02-08 19:58, David P. Reed wrote:
--- linux-2.6.orig/include/asm-x86/i8253.h
+++ linux-2.6/include/asm-x86/i8253.h
@@ -12,7 +12,25 @@ extern struct clock_event_device *global
extern void setup_pit_timer(void);
-#define inb_pit inb_p
-#define outb_pit outb_p
+/* accesses to
On Mon, 18 Feb 2008 13:58:41 -0500 (EST)
"David P. Reed" <[EMAIL PROTECTED]> wrote:
> x86: use explicit timing delay for pit accesses in kernel and pcspkr driver
Both look good to me now
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
x86: use explicit timing delay for pit accesses in kernel and pcspkr driver
pit accesses in i8253.c and pcspkr driver use outb_p for timing.
Fix them to use explicit timing delay for access to PIT,
rather than inb_p/outb_p calls, which use insufficiently explicit
delays (defaulting to port 80
x86: use explicit timing delay for pit accesses in kernel and pcspkr driver
pit accesses in i8253.c and pcspkr driver use outb_p for timing.
Fix them to use explicit timing delay for access to PIT,
rather than inb_p/outb_p calls, which use insufficiently explicit
delays (defaulting to port 80
On Mon, 18 Feb 2008 13:58:41 -0500 (EST)
David P. Reed [EMAIL PROTECTED] wrote:
x86: use explicit timing delay for pit accesses in kernel and pcspkr driver
Both look good to me now
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On 18-02-08 19:58, David P. Reed wrote:
--- linux-2.6.orig/include/asm-x86/i8253.h
+++ linux-2.6/include/asm-x86/i8253.h
@@ -12,7 +12,25 @@ extern struct clock_event_device *global
extern void setup_pit_timer(void);
-#define inb_pit inb_p
-#define outb_pit outb_p
+/* accesses to
Rene Herman wrote:
Now with respect to the original pre port 80 jmp $+2 I/O delay (which
the Pentium obsoleted) I suppose it'll probably be okay even without
fixing that specifically but do note such -- it's a vital part of the
problem.
Sorry, that paragraph didn't parse for me.
On 18-02-08 22:04, Rene Herman wrote:
On 18-02-08 21:43, H. Peter Anvin wrote:
Rene Herman wrote:
Now with respect to the original pre port 80 jmp $+2 I/O delay
(which the Pentium obsoleted) I suppose it'll probably be okay even
without fixing that specifically but do note such -- it's a
On 18-02-08 21:43, H. Peter Anvin wrote:
Rene Herman wrote:
Now with respect to the original pre port 80 jmp $+2 I/O delay
(which the Pentium obsoleted) I suppose it'll probably be okay even
without fixing that specifically but do note such -- it's a vital part
of the problem.
Sorry,
Rene Herman wrote:
I mean that before the linux kernel used a port 0x80 write as an I/O
delay it used a short jump (two in a row actually...) as such and this
was at the time that it actually ran on the old legacy stuff that is of
most concern here.
No, if I'm not mistaken, those two jumps
On 18-02-08 23:01, H. Peter Anvin wrote:
Rene Herman wrote:
Yes, but generally not any P5+ system is going to need the PIT delay
in the first place meaning it just doesn't matter. There were the VIA
issues with the PIC but unless I missed it not with the PIT.
Uhm, I'm not sure I believe
Rene Herman wrote:
Yes, but generally not any P5+ system is going to need the PIT delay in
the first place meaning it just doesn't matter. There were the VIA
issues with the PIC but unless I missed it not with the PIT.
Uhm, I'm not sure I believe that's safe.
The PIT is particularly
On 18-02-08 22:44, H. Peter Anvin wrote:
Rene Herman wrote:
I mean that before the linux kernel used a port 0x80 write as an I/O
delay it used a short jump (two in a row actually...) as such and this
was at the time that it actually ran on the old legacy stuff that is
of most concern here.
Rene Herman wrote:
Uhm, I'm not sure I believe that's safe.
The PIT is particularly pissy in this case -- the semantics of the PIT
are ill-defined if there hasn't been a PIT clock between two adjacent
accesses, so I fully expect that there are chipsets out there which
will do very bad
Rene Herman wrote:
On 18-02-08 23:07, Rene Herman wrote:
On 18-02-08 23:01, H. Peter Anvin wrote:
Rene Herman wrote:
Yes, but generally not any P5+ system is going to need the PIT delay
in the first place meaning it just doesn't matter. There were the
VIA issues with the PIC but unless I
On 18-02-08 23:07, Rene Herman wrote:
On 18-02-08 23:01, H. Peter Anvin wrote:
Rene Herman wrote:
Yes, but generally not any P5+ system is going to need the PIT delay
in the first place meaning it just doesn't matter. There were the VIA
issues with the PIC but unless I missed it not with
38 matches
Mail list logo
