On Mon 2007-12-17 15:42:51, Ingo Molnar wrote:
>
> * Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> > > > > ./char/epca.c
> > > > > ./char/sonypi.c
> > > > > ./scsi/megaraid.c
> > > > > ./ide/pci/serverworks.c
> > > > > ./ide/pci/cmd640.c
> > > > > ./input/mouse/pc110pad.c
> > >
> > > You are
On Mon 2007-12-17 15:42:51, Ingo Molnar wrote:
* Pavel Machek [EMAIL PROTECTED] wrote:
./char/epca.c
./char/sonypi.c
./scsi/megaraid.c
./ide/pci/serverworks.c
./ide/pci/cmd640.c
./input/mouse/pc110pad.c
You are missing some watchdogs at least ?
I
* Pavel Machek <[EMAIL PROTECTED]> wrote:
> > > > ./char/epca.c
> > > > ./char/sonypi.c
> > > > ./scsi/megaraid.c
> > > > ./ide/pci/serverworks.c
> > > > ./ide/pci/cmd640.c
> > > > ./input/mouse/pc110pad.c
> >
> > You are missing some watchdogs at least ?
>
> I snipped them, I only wanted to
* Pavel Machek [EMAIL PROTECTED] wrote:
./char/epca.c
./char/sonypi.c
./scsi/megaraid.c
./ide/pci/serverworks.c
./ide/pci/cmd640.c
./input/mouse/pc110pad.c
You are missing some watchdogs at least ?
I snipped them, I only wanted to comment that pc110pad.c looks
On Mon 2007-12-17 00:03:01, Alan Cox wrote:
> On Sun, 16 Dec 2007 22:26:33 +0100
> Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> > On Fri 2007-12-14 15:33:28, Ingo Molnar wrote:
> > >
> > > * Alan Cox <[EMAIL PROTECTED]> wrote:
> > >
> > > > There is another reason we can't just do a dumb
> /*
> * We try to avoid enabling the hardware if it's not
> * there, but we don't know how to test. But we do know
> * that the PC110 is not a PCI system. So if we find any
> * PCI devices in the machine, we don't have a PC110.
> */
The pc110 pad device is ISA. Its an ISA bus 486 box
Alan
On Sun, 16 Dec 2007 22:26:33 +0100
Pavel Machek <[EMAIL PROTECTED]> wrote:
> On Fri 2007-12-14 15:33:28, Ingo Molnar wrote:
> >
> > * Alan Cox <[EMAIL PROTECTED]> wrote:
> >
> > > There is another reason we can't just do a dumb changeover - two
> > > actually
> > >
> > > #1: Some drivers are
On Fri 2007-12-14 15:33:28, Ingo Molnar wrote:
>
> * Alan Cox <[EMAIL PROTECTED]> wrote:
>
> > There is another reason we can't just do a dumb changeover - two
> > actually
> >
> > #1: Some drivers are using inb_p/outb_p in PCI cases which are going
> > #to cause PCI posting changes. Most are
/*
* We try to avoid enabling the hardware if it's not
* there, but we don't know how to test. But we do know
* that the PC110 is not a PCI system. So if we find any
* PCI devices in the machine, we don't have a PC110.
*/
The pc110 pad device is ISA. Its an ISA bus 486 box
Alan
--
To
On Sun, 16 Dec 2007 22:26:33 +0100
Pavel Machek [EMAIL PROTECTED] wrote:
On Fri 2007-12-14 15:33:28, Ingo Molnar wrote:
* Alan Cox [EMAIL PROTECTED] wrote:
There is another reason we can't just do a dumb changeover - two
actually
#1: Some drivers are using inb_p/outb_p in
On Mon 2007-12-17 00:03:01, Alan Cox wrote:
On Sun, 16 Dec 2007 22:26:33 +0100
Pavel Machek [EMAIL PROTECTED] wrote:
On Fri 2007-12-14 15:33:28, Ingo Molnar wrote:
* Alan Cox [EMAIL PROTECTED] wrote:
There is another reason we can't just do a dumb changeover - two
On Fri 2007-12-14 15:33:28, Ingo Molnar wrote:
* Alan Cox [EMAIL PROTECTED] wrote:
There is another reason we can't just do a dumb changeover - two
actually
#1: Some drivers are using inb_p/outb_p in PCI cases which are going
#to cause PCI posting changes. Most are probably just
On Thu, 13 Dec 2007 20:50:33 -0500
"David P. Reed" <[EMAIL PROTECTED]> wrote:
> Simulating 1 microsecond delays (assuming LPC meets that goal for 0x80)
> is "absolutely correct" for devices provided on PCI-X running on 3 GHz
> or greater machines?
Yes - the LPC bus clock doesn't change for the
* Alan Cox <[EMAIL PROTECTED]> wrote:
> There is another reason we can't just do a dumb changeover - two
> actually
>
> #1: Some drivers are using inb_p/outb_p in PCI cases which are going
> #to cause PCI posting changes. Most are probably just wrong in the
> #first place but they need hand
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > Why is TSC significant? udelay() based on bogomips seems to be good
> > enough...?
>
> Maybe I'm not sure how accurate it really is on non TSC system. On the
> other hand it is unclear that the port 80 IO is always the same time
> so it's probably
* Alan Cox [EMAIL PROTECTED] wrote:
There is another reason we can't just do a dumb changeover - two
actually
#1: Some drivers are using inb_p/outb_p in PCI cases which are going
#to cause PCI posting changes. Most are probably just wrong in the
#first place but they need hand checking
* Andi Kleen [EMAIL PROTECTED] wrote:
Why is TSC significant? udelay() based on bogomips seems to be good
enough...?
Maybe I'm not sure how accurate it really is on non TSC system. On the
other hand it is unclear that the port 80 IO is always the same time
so it's probably ok to vary
On Thu, 13 Dec 2007 20:50:33 -0500
David P. Reed [EMAIL PROTECTED] wrote:
Simulating 1 microsecond delays (assuming LPC meets that goal for 0x80)
is absolutely correct for devices provided on PCI-X running on 3 GHz
or greater machines?
Yes - the LPC bus clock doesn't change for the CPU
Simulating 1 microsecond delays (assuming LPC meets that goal for 0x80)
is "absolutely correct" for devices provided on PCI-X running on 3 GHz
or greater machines?
Well, you are entitled to your opinion. Seems likely that reading the
timing specs of such a chipset might be correct, and
On Thu, 13 Dec 2007 08:13:29 -0500
"David P. Reed" <[EMAIL PROTECTED]> wrote:
> Perhaps what was meant is that ISA-tuned timings make little sense on
> devices that are part of the chipset or on the PCI or PCI-X buses?
No.
ISA as LPC bus is alive and well inside and outside chipsets. Welcome
Perhaps what was meant is that ISA-tuned timings make little sense on
devices that are part of the chipset or on the PCI or PCI-X buses?
On the other hand, since we don't know in many cases whether the "_p"
was supposed to mean "the time it takes to execute an "out al,80h" on
whatever bus
Perhaps what was meant is that ISA-tuned timings make little sense on
devices that are part of the chipset or on the PCI or PCI-X buses?
On the other hand, since we don't know in many cases whether the _p
was supposed to mean the time it takes to execute an out al,80h on
whatever bus
On Thu, 13 Dec 2007 08:13:29 -0500
David P. Reed [EMAIL PROTECTED] wrote:
Perhaps what was meant is that ISA-tuned timings make little sense on
devices that are part of the chipset or on the PCI or PCI-X buses?
No.
ISA as LPC bus is alive and well inside and outside chipsets. Welcome to
Simulating 1 microsecond delays (assuming LPC meets that goal for 0x80)
is absolutely correct for devices provided on PCI-X running on 3 GHz
or greater machines?
Well, you are entitled to your opinion. Seems likely that reading the
timing specs of such a chipset might be correct, and
> Yes, it's now clear that all of this is so. Regrettably, it's used in
> dozens of drivers, most having nothing to do with an ISA/LPC bus.
>
> If it really is specific to the ISA architecture, then it should only be
> used in architecture specific code.
ISA/LPC is not architecture specific.
Alan Cox wrote:
without need. Not surprising since it has such a vague specific
meaning. One could say, Linux on i386 is liberally sprinkled with
"vague specific" ? sorry don't follow you.
The _p variants are a universal fixture, defined as ending with a pause,
but without
There is another reason we can't just do a dumb changeover - two actually
#1: Some drivers are using inb_p/outb_p in PCI cases which are going to
cause PCI posting changes. Most are probably just wrong in the first
place but they need hand checking
#2: We've got SMP cases that only 'work'
On Tue, 11 Dec 2007, David P. Reed wrote:
> 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
On Tue, 11 Dec 2007, David P. Reed wrote:
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
There is another reason we can't just do a dumb changeover - two actually
#1: Some drivers are using inb_p/outb_p in PCI cases which are going to
cause PCI posting changes. Most are probably just wrong in the first
place but they need hand checking
#2: We've got SMP cases that only 'work'
Alan Cox wrote:
without need. Not surprising since it has such a vague specific
meaning. One could say, Linux on i386 is liberally sprinkled with
vague specific ? sorry don't follow you.
The _p variants are a universal fixture, defined as ending with a pause,
but without
Yes, it's now clear that all of this is so. Regrettably, it's used in
dozens of drivers, most having nothing to do with an ISA/LPC bus.
If it really is specific to the ISA architecture, then it should only be
used in architecture specific code.
ISA/LPC is not architecture specific. In
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
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 R, at Software Arts in Cambridge, MA, and
there was a machine we developed the first IBM Visicalc for, in a locked
room
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
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
>> 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 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
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
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
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
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
> 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
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
David P. Reed wrote:
I do remind all that 0x80 is a BIOS-specific standard, and is per BIOS -
other ports have been used in the history of the IBM PC family by some
vendors, and some machines have used it for DMA port mapping!!
Correction: ALL machines use it for DMA port mapping. The port
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.
Rene Herman wrote:
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
On 11-12-07 17:58, David P. Reed wrote:
I do remind all that 0x80 is a BIOS-specific standard, and is per BIOS
There's lots of things concerning the PC that is documented nowhere and is
still true. Did you test 0xed?
Rene.
--
To unsubscribe from this list: send the line "unsubscribe
Which port do you want me to test? Also, I can run the timing test on
my machine if you share the source code so I can build it.
Rene Herman wrote:
On 11-12-07 17:30, Andi Kleen wrote:
Anyways it looks like the discussion here is going in a
a loop. I had hoped David would post his test
As the person who started this thread, I'm still puzzled by two things:
1) is there anyone out there who wrote one of these drivers (most listed
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
On 11-12-07 17:30, Andi Kleen wrote:
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
On 11-12-07 17:32, John Stoffel wrote:
Here's my results on a PIII Xeon, 550mhz, 440GX chipset, and an ISA
slot, which until recently was actually used with an 8 port serial
card:
jfsnew:~/src> sudo ./port80
out: 729
in : 348
jfsnew:~/src> sudo ./port80
out: 729
in : 354
jfsnew:~/src> sudo
Here's my results on a PIII Xeon, 550mhz, 440GX chipset, and an ISA
slot, which until recently was actually used with an 8 port serial
card:
jfsnew:~/src> sudo ./port80
out: 729
in : 348
jfsnew:~/src> sudo ./port80
out: 729
in : 354
jfsnew:~/src> sudo ./port80
out: 729
in : 350
jfsnew:~/src>
> Most, probably most-all, of the delays to port operations
> on modern ix86 machines are not needed at all. Certainly
We know this. The problem is that there is no good known way to
figure out which machines need it. Also it is typically
slow hardware anyways -- the most time critical is
On 11-12-07 16:37, Paul Rolland wrote:
Great, thanks for the quick replies.
That last one below especially is quite a bit more than 1. As said before,
most hardware isn't in fact going to need anything but I suppose udelay(2)
might be the "safer" replacement for the outb then...
On Tue, 11
On Tue, 11 Dec 2007, David Newall wrote:
> Rene Herman wrote:
>> This particular discussion isn't about anything in general but solely
>> about the delay an outb_p gives you on x86 since what is under
>> discussion is not using an output to port 0x80 on that platform to
>> generate it.
>
> That
Hello,
On Tue, 11 Dec 2007 16:28:56 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
> On 11-12-07 15:15, Rene Herman wrote:
>
> > On 11-12-07 14:32, Paul Rolland wrote:
> >
> This might be a bit more constant, I suppose. This serialises with cpuid.
> Don't see a difference locally, but perhaps
On 11-12-07 15:15, Rene Herman wrote:
On 11-12-07 14:32, Paul Rolland wrote:
On 11-12-07 13:08, David Newall wrote:
Rene Herman wrote:
(*) some local testing shows it to be almost exactly that for both
out and in on my own PC -- a little over. If anyone cares, see
attached little test
On Sat, Dec 08, 2007 at 02:25:02PM -0500, David P. Reed wrote:
> In any case, my machine does not have an ISA bus. Why should it? It's
> a laptop!
Really? Are you sure? How does the CPU talk to the BIOS? How about
the parallel port if you have one? (I will assume you have no serial
ports
> That could be true if outb_p were used only in architecture dependent
> code, but it's not. It's used in drivers that are supposed to run on
> all sorts of platforms. Why does a megaraid controller need delays on
> i386 but not on Sparc, PowerPC, Alpha and others? Is it buggy on most
>
On 11-12-07 14:32, Paul Rolland wrote:
On 11-12-07 13:08, David Newall wrote:
Rene Herman wrote:
(*) some local testing shows it to be almost exactly that for both out and
in on my own PC -- a little over. If anyone cares, see attached little test
program. The "little over" I don't worry
On 11-12-07 14:50, David Newall wrote:
Rene Herman wrote:
This particular discussion isn't about anything in general but solely
about the delay an outb_p gives you on x86 since what is under
discussion is not using an output to port 0x80 on that platform to
generate it.
That could be
Rene Herman wrote:
This particular discussion isn't about anything in general but solely
about the delay an outb_p gives you on x86 since what is under
discussion is not using an output to port 0x80 on that platform to
generate it.
That could be true if outb_p were used only in architecture
On Tue, Dec 11, 2007 at 02:47:25PM +0100, Pavel Machek wrote:
> On Tue 2007-12-11 14:32:49, Andi Kleen wrote:
> > > The LPC bus behaviour is absolutely and precisely defined. The timing of
> > > the inb is defined in bus clocks which is perfect as the devices needing
> > > delay are running at a
On Tue 2007-12-11 14:32:49, Andi Kleen wrote:
> > The LPC bus behaviour is absolutely and precisely defined. The timing of
> > the inb is defined in bus clocks which is perfect as the devices needing
> > delay are running at a fraction of busclock usually busclock/2.
> >
> > Older processors did
Hello,
On Tue, 11 Dec 2007 14:16:01 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
> On 11-12-07 13:08, David Newall wrote:
>
> > Rene Herman wrote:
> (*) some local testing shows it to be almost exactly that for both out and
> in on my own PC -- a little over. If anyone cares, see attached
> The LPC bus behaviour is absolutely and precisely defined. The timing of
> the inb is defined in bus clocks which is perfect as the devices needing
> delay are running at a fraction of busclock usually busclock/2.
>
> Older processors did not have a high precision timer so you couldn't
>
> I really *hate* the idea that access to non-present hardware is used to
> generate a delay. That sucks so badly. It's worthy of a school-aged
> hacker, not of a world-leading operating system. It's so not
> best-practice that it's worst-practice.
Actually its very good practice.
The LPC
On 11-12-07 13:08, David Newall wrote:
Rene Herman wrote:
On 11-12-07 08:40, Paul Rolland wrote:
Well, if the delay is so much unspecified, what about _reading_ port
0x80 ?
Will the delay be shorter ?
The delay is completely and fully specified in terms of the ISA/LPC clock
That would
Rene Herman wrote:
On 11-12-07 08:40, Paul Rolland wrote:
Well, if the delay is so much unspecified, what about _reading_ port
0x80 ?
Will the delay be shorter ?
The delay is completely and fully specified in terms of the ISA/LPC clock
That would be the delay on the i386 (sic)
On 11-12-07 08:40, Paul Rolland wrote:
Well, if the delay is so much unspecified, what about _reading_ port 0x80 ?
Will the delay be shorter ?
The delay is completely and fully specified in terms of the ISA/LPC clock
which certainly for anything modern means a fixed, unchanging value
On 11-12-07 08:40, Paul Rolland wrote:
Well, if the delay is so much unspecified, what about _reading_ port 0x80 ?
Will the delay be shorter ?
The delay is completely and fully specified in terms of the ISA/LPC clock
which certainly for anything modern means a fixed, unchanging value
Rene Herman wrote:
On 11-12-07 08:40, Paul Rolland wrote:
Well, if the delay is so much unspecified, what about _reading_ port
0x80 ?
Will the delay be shorter ?
The delay is completely and fully specified in terms of the ISA/LPC clock
That would be the delay on the i386 (sic)
On 11-12-07 13:08, David Newall wrote:
Rene Herman wrote:
On 11-12-07 08:40, Paul Rolland wrote:
Well, if the delay is so much unspecified, what about _reading_ port
0x80 ?
Will the delay be shorter ?
The delay is completely and fully specified in terms of the ISA/LPC clock
That would
The LPC bus behaviour is absolutely and precisely defined. The timing of
the inb is defined in bus clocks which is perfect as the devices needing
delay are running at a fraction of busclock usually busclock/2.
Older processors did not have a high precision timer so you couldn't
calibrate
Hello,
On Tue, 11 Dec 2007 14:16:01 +0100
Rene Herman [EMAIL PROTECTED] wrote:
On 11-12-07 13:08, David Newall wrote:
Rene Herman wrote:
(*) some local testing shows it to be almost exactly that for both out and
in on my own PC -- a little over. If anyone cares, see attached little test
I really *hate* the idea that access to non-present hardware is used to
generate a delay. That sucks so badly. It's worthy of a school-aged
hacker, not of a world-leading operating system. It's so not
best-practice that it's worst-practice.
Actually its very good practice.
The LPC bus
On Tue, Dec 11, 2007 at 02:47:25PM +0100, Pavel Machek wrote:
On Tue 2007-12-11 14:32:49, Andi Kleen wrote:
The LPC bus behaviour is absolutely and precisely defined. The timing of
the inb is defined in bus clocks which is perfect as the devices needing
delay are running at a fraction of
Rene Herman wrote:
This particular discussion isn't about anything in general but solely
about the delay an outb_p gives you on x86 since what is under
discussion is not using an output to port 0x80 on that platform to
generate it.
That could be true if outb_p were used only in architecture
On Tue 2007-12-11 14:32:49, Andi Kleen wrote:
The LPC bus behaviour is absolutely and precisely defined. The timing of
the inb is defined in bus clocks which is perfect as the devices needing
delay are running at a fraction of busclock usually busclock/2.
Older processors did not have a
On 11-12-07 14:50, David Newall wrote:
Rene Herman wrote:
This particular discussion isn't about anything in general but solely
about the delay an outb_p gives you on x86 since what is under
discussion is not using an output to port 0x80 on that platform to
generate it.
That could be
On 11-12-07 14:32, Paul Rolland wrote:
On 11-12-07 13:08, David Newall wrote:
Rene Herman wrote:
(*) some local testing shows it to be almost exactly that for both out and
in on my own PC -- a little over. If anyone cares, see attached little test
program. The little over I don't worry
That could be true if outb_p were used only in architecture dependent
code, but it's not. It's used in drivers that are supposed to run on
all sorts of platforms. Why does a megaraid controller need delays on
i386 but not on Sparc, PowerPC, Alpha and others? Is it buggy on most
On Sat, Dec 08, 2007 at 02:25:02PM -0500, David P. Reed wrote:
In any case, my machine does not have an ISA bus. Why should it? It's
a laptop!
Really? Are you sure? How does the CPU talk to the BIOS? How about
the parallel port if you have one? (I will assume you have no serial
ports
On 11-12-07 15:15, Rene Herman wrote:
On 11-12-07 14:32, Paul Rolland wrote:
On 11-12-07 13:08, David Newall wrote:
Rene Herman wrote:
(*) some local testing shows it to be almost exactly that for both
out and in on my own PC -- a little over. If anyone cares, see
attached little test
Hello,
On Tue, 11 Dec 2007 16:28:56 +0100
Rene Herman [EMAIL PROTECTED] wrote:
On 11-12-07 15:15, Rene Herman wrote:
On 11-12-07 14:32, Paul Rolland wrote:
This might be a bit more constant, I suppose. This serialises with cpuid.
Don't see a difference locally, but perhaps you do.
On Tue, 11 Dec 2007, David Newall wrote:
Rene Herman wrote:
This particular discussion isn't about anything in general but solely
about the delay an outb_p gives you on x86 since what is under
discussion is not using an output to port 0x80 on that platform to
generate it.
That could be
On 11-12-07 16:37, Paul Rolland wrote:
Great, thanks for the quick replies.
That last one below especially is quite a bit more than 1. As said before,
most hardware isn't in fact going to need anything but I suppose udelay(2)
might be the safer replacement for the outb then...
On Tue, 11
Most, probably most-all, of the delays to port operations
on modern ix86 machines are not needed at all. Certainly
We know this. The problem is that there is no good known way to
figure out which machines need it. Also it is typically
slow hardware anyways -- the most time critical is
Here's my results on a PIII Xeon, 550mhz, 440GX chipset, and an ISA
slot, which until recently was actually used with an 8 port serial
card:
jfsnew:~/src sudo ./port80
out: 729
in : 348
jfsnew:~/src sudo ./port80
out: 729
in : 354
jfsnew:~/src sudo ./port80
out: 729
in : 350
jfsnew:~/src sudo
On 11-12-07 17:32, John Stoffel wrote:
Here's my results on a PIII Xeon, 550mhz, 440GX chipset, and an ISA
slot, which until recently was actually used with an 8 port serial
card:
jfsnew:~/src sudo ./port80
out: 729
in : 348
jfsnew:~/src sudo ./port80
out: 729
in : 354
jfsnew:~/src sudo
On 11-12-07 17:30, Andi Kleen wrote:
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
As the person who started this thread, I'm still puzzled by two things:
1) is there anyone out there who wrote one of these drivers (most listed
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
Which port do you want me to test? Also, I can run the timing test on
my machine if you share the source code so I can build it.
Rene Herman wrote:
On 11-12-07 17:30, Andi Kleen wrote:
Anyways it looks like the discussion here is going in a
a loop. I had hoped David would post his test
Rene Herman wrote:
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
On 11-12-07 17:58, David P. Reed wrote:
I do remind all that 0x80 is a BIOS-specific standard, and is per BIOS
There's lots of things concerning the PC that is documented nowhere and is
still true. Did you test 0xed?
Rene.
--
To unsubscribe from this list: send the line unsubscribe
David P. Reed wrote:
I do remind all that 0x80 is a BIOS-specific standard, and is per BIOS -
other ports have been used in the history of the IBM PC family by some
vendors, and some machines have used it for DMA port mapping!!
Correction: ALL machines use it for DMA port mapping. The port
1 - 100 of 218 matches
Mail list logo
