On 18-01-08 14:37, David Newall wrote:
The problem is that _p is widely used for non-ISA devices.
Yes, we know, it's being fixed. Piss off.
Rene.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at ht
Rene,
Here is why you shouldn't leap so quickly to rudeness. Everything is
being repeated over and over and over again (as you put it) because
people like you shout down people like me without making any apparent
effort to understand the truth of the problem.
Rene Herman wrote:
> We've already
On 17-01-08 22:58, David Newall wrote:
Rene Herman wrote:
Over the course of a 100 messages or so in this thread it's been
determined that the best course of action is to keep the out for ISA
and replace it with udelay() for chipset logic. Now go away.
Rather than this incredible rudeness,
Rene Herman wrote:
> Over the course of a 100 messages or so in this thread it's been
> determined that the best course of action is to keep the out for ISA
> and replace it with udelay() for chipset logic. Now go away.
Rather than this incredible rudeness, why don't you direct your energy
toward
> In the early days of clone PCs, as you know but perhaps many on this
> list might not, the bus speed could be changed, but this was
> user-selectable. For such a machine, delay values can be pre-calculated
> for each bus speed, and a kernel parameter set accordingly. Or are you
> saying that th
On 17-01-08 14:36, David Newall wrote:
In the early days of clone PCs, as you know but perhaps many on this
list might not
I'm so incredibly sick of this fucking thread. We've had enough legacy farts
coming out of the woodwork advertising their own massive experience and
cluelessness by now.
Alan Cox wrote:
>> This is a timing issue, isn't it? How are we synchronising, other than
>> by delaying for a (bus-dependant) period? The characteristics of each
>> bus are known so a number can be assigned for "one bus cycle", without
>> having to use the bus.
>>
>
> The characteristics of
> This is a timing issue, isn't it? How are we synchronising, other than
> by delaying for a (bus-dependant) period? The characteristics of each
> bus are known so a number can be assigned for "one bus cycle", without
> having to use the bus.
The characteristics of the bus are not known. It coul
Alan Cox wrote:
>> If the hardware required an intermediate junk I/O, that would be a
>> reason to do one, but it doesn't, does it? It requires a delay. It's
>> written thus in all of the application notes.
>>
>
> And the only instruction that is synchronized to the bus in question is
> an I
> If the hardware required an intermediate junk I/O, that would be a
> reason to do one, but it doesn't, does it? It requires a delay. It's
> written thus in all of the application notes.
And the only instruction that is synchronized to the bus in question is
an I/O instruction.
> Wrong again.
Alan Cox wrote:
> On Thu, 17 Jan 2008 01:06:24 +1030
> David Newall <[EMAIL PROTECTED]> wrote:
>
>
>> This use of port 80 (or insert some other random number) is a croc of
>> hackery of the most inexperienced kind.
>>
>
> Wrong. It's a careful designed solution used by all sorts of code fo
On Thu, 17 Jan 2008 01:06:24 +1030
David Newall <[EMAIL PROTECTED]> wrote:
> This use of port 80 (or insert some other random number) is a croc of
> hackery of the most inexperienced kind.
Wrong. It's a careful designed solution used by all sorts of code for
over 15 years.
The task to be perfo
David P. Reed wrote:
> I think we probably have a great shot at getting Intel, Microsoft, HP,
> et al.. to add a feature for Linux to one of the ACPI table
> specifications that define an "unused port for delay purposes" field
> in the ACPI 4.0 spec, and retrofit it into PC/104 machine BIOSes. At
David Woodhouse wrote:
On Fri, 2008-01-11 at 09:35 -0500, David P. Reed wrote:
Using any "unused port" for a delay means that the machine check
feature is wasted and utterly unusable.
Not entirely unusable. You can recover silently from the machine check
if it was one of the known ac
On Fri, 2008-01-11 at 09:35 -0500, David P. Reed wrote:
> Using any "unused port" for a delay means that the machine check
> feature is wasted and utterly unusable.
Not entirely unusable. You can recover silently from the machine check
if it was one of the known accesses to the 'unused port'. I
David P. Reed wrote:
Alan Cox wrote:
bus abort on the LPC bus". More problematic is that I would think
some people might want to turn on the AMD feature that generates
machine checks if a bus timeout happens. The whole point of machine
checks is
An ISA/LPC bus timeout is fulfilled b
Alan Cox wrote:
bus abort on the LPC bus". More problematic is that I would think some
people might want to turn on the AMD feature that generates machine
checks if a bus timeout happens. The whole point of machine checks is
An ISA/LPC bus timeout is fulfilled by the bridge so doesn'
On 11-01-08 15:35, David P. Reed wrote:
Rene Herman wrote:
On 11-01-08 02:36, Zachary Amsden wrote:
FWIW, I fixed the problem locally by recompiling, changing port 80 to
port 84 in io.h; works great, and doesn't conflict with any occupied
ports.
Might not give you a "proper" delay though.
> bus abort on the LPC bus". More problematic is that I would think some
> people might want to turn on the AMD feature that generates machine
> checks if a bus timeout happens. The whole point of machine checks is
An ISA/LPC bus timeout is fulfilled by the bridge so doesn't cause an MCE.
Rene Herman wrote:
On 11-01-08 02:36, Zachary Amsden wrote:
FWIW, I fixed the problem locally by recompiling, changing port 80 to
port 84 in io.h; works great, and doesn't conflict with any occupied
ports.
Might not give you a "proper" delay though. 0xed should be a better
choice...
I d
On 11-01-08 02:36, Zachary Amsden wrote:
FWIW, I fixed the problem locally by recompiling, changing port 80 to
port 84 in io.h; works great, and doesn't conflict with any occupied
ports.
Might not give you a "proper" delay though. 0xed should be a better choice...
Rene.
--
To unsubscribe fro
On Wed, 2008-01-09 at 17:22 -0500, David P. Reed wrote:
> Zachary Amsden wrote:
> >
> > According to Phoenix Technologies book "System BIOS for IBM PCs,
> > Compatibles and EISA Computers, 2nd Edition", the I/O port list gives
> >
> > port 0080h R/W Extra page register (temporary storage)
> >
>
Rene Herman wrote:
On 10-01-08 01:37, Robert Hancock wrote:
I agree. In this case the BIOS on these laptops is trying to tell us
"port 80 is used for our purposes, do not touch it". We should be
listening.
Listening is fine but what are you going to do after you have
listened? Right, not
On 10-01-08 01:37, Robert Hancock wrote:
David P. Reed wrote:
I have a small suggestion in mind that might be helpful in the future:
the "motherboard resources" discovered as PNP0C02 devices in their _CRS
settings in ACPI during ACPI PnP startup should be reserved (or
checked), and any drive
David P. Reed wrote:
Christer Weinigel wrote:
Did I miss anyting?
Nothing that seems *crucial* going forward for Linux. The fate of
"legacy machines" is really important to get right.
I have a small suggestion in mind that might be helpful in the future:
the "motherboard resources" disc
Zachary Amsden wrote:
According to Phoenix Technologies book "System BIOS for IBM PCs,
Compatibles and EISA Computers, 2nd Edition", the I/O port list gives
port 0080h R/W Extra page register (temporary storage)
Despite looking, I've never seen it documented anywhere else, but I
believe it
Christer Weinigel wrote:
On Wed, 09 Jan 2008 10:18:11 -0800
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
Zachary Amsden wrote:
I'm speaking specifically in terms of 64-bit platforms here.
Shouldn't we unconditionally drop outb_p doing extra port I/O on
64-bit architectures? Especially consider
On Tue, 2008-01-08 at 21:19 -0800, H. Peter Anvin wrote:
> Zachary Amsden wrote:
> >
> > BTW, it isn't ever safe to pass port 0x80 through to hardware from a
> > virtual machine; some OSes use port 0x80 as a hardware available scratch
> > register (I believe Darwin/x86 did/does this during boot).
On Wed, 09 Jan 2008 10:18:11 -0800
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Zachary Amsden wrote:
> >
> > I'm speaking specifically in terms of 64-bit platforms here.
> > Shouldn't we unconditionally drop outb_p doing extra port I/O on
> > 64-bit architectures? Especially considering they d
Adrian Bunk wrote:
I don't think the latter statement was true - AFAIR there are Alphas
with ISA slots.
See subject line.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vge
On Wed, Jan 09, 2008 at 10:17:24AM -0800, Zachary Amsden wrote:
> On Wed, 2008-01-09 at 16:27 +0100, Rene Herman wrote:
> > On 09-01-08 06:30, Christer Weinigel wrote:
> > I'd not expect very time crtical. The current outb_p use gives a delay
> > somewhere between .5 and 2 microseconds as per earl
Zachary Amsden wrote:
I'm speaking specifically in terms of 64-bit platforms here. Shouldn't
we unconditionally drop outb_p doing extra port I/O on 64-bit
architectures? Especially considering they don't even have an ISA bus
where the decode timing could even matter?
Why should the bitsize
On Wed, 2008-01-09 at 16:27 +0100, Rene Herman wrote:
> On 09-01-08 06:30, Christer Weinigel wrote:
> I'd not expect very time crtical. The current outb_p use gives a delay
> somewhere between .5 and 2 microseconds as per earlier survey meaning a
> udelay(1) or 2 would be enough -- again, at the
On 09-01-08 06:30, Christer Weinigel wrote:
On Tue, 08 Jan 2008 18:52:42 -0800
Zachary Amsden <[EMAIL PROTECTED]> wrote:
What is the outcome of this thread? Are we going to use timing based
port delays, or can we finally drop these things entirely on 64-bit
architectures?
I a have a doubly
Christer Weinigel wrote:
Did I miss anyting?
Nothing that seems *crucial* going forward for Linux. The fate of
"legacy machines" is really important to get right.
I have a small suggestion in mind that might be helpful in the future:
the "motherboard resources" discovered as PNP0C02 devi
On Tue, 08 Jan 2008 18:52:42 -0800
Zachary Amsden <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-01-08 at 14:15 -0500, David P. Reed wrote:
> > Alan Cox wrote:
> > > The natsemi docs here say otherwise. I trust them not you.
> > >
> > As well you should. I am honestly curious (for my own satisfactio
Zachary Amsden wrote:
BTW, it isn't ever safe to pass port 0x80 through to hardware from a
virtual machine; some OSes use port 0x80 as a hardware available scratch
register (I believe Darwin/x86 did/does this during boot).
That's funny, because there is definitely no guarantee that you get bac
On Tue, 2008-01-08 at 14:15 -0500, David P. Reed wrote:
> Alan Cox wrote:
> > The natsemi docs here say otherwise. I trust them not you.
> >
> As well you should. I am honestly curious (for my own satisfaction) as
> to what the natsemi docs say the delay code should do (can't imagine
> they s
Christer Weinigel wrote:
Argument by personal authority. Thats good.
There is no other kind of argument. Are you claiming supernatural
authority drives your typing fingers, or is your argument based on what
you think you know? I have piles of code that I wrote, spec sheets (now
that I'm bac
On Tue, 08 Jan 2008 15:28:03 -0500
"David P. Reed" <[EMAIL PROTECTED]> wrote:
> Register compatible. Not the same chips or even the same masks or
> timing requirements.
No, but somehow people keep making similar mistakes. The DEC HiNote
needed outb_p to function correctly? That was definite
Christer Weinigel wrote:
There is no need to use io writes to supposedly/theoretically "unused
ports" to make drivers work on any bus.
ISA included! You can, for example, wait for an ISA bus serial
adapter to put out its next character by looping reading the port
that has the output buffer ful
Alan -
I dug up a DP83901A SNIC datasheet in a quick Google search, while that
wasn't the only such chip, it was one of them. I can forward the PDF
(the www.alldatasheet.com site dynamically creates the download URL), if
anyone wants it.
The relevant passage says, in regard to delaying betwee
On Tue, 08 Jan 2008 13:44:54 -0500
"David P. Reed" <[EMAIL PROTECTED]> wrote:
> Ondrej Zary wrote:
> > On Tuesday 08 January 2008 18:24:02 David P. Reed wrote:
> >
> >> Windows these days does delays with timing loops or the
> >> scheduler. It doesn't use a "port". Also, Windows XP only
> >>
> As well you should. I am honestly curious (for my own satisfaction) as
> to what the natsemi docs say the delay code should do (can't imagine
> they say "use io port 80 because it is unused"). I don't have any
They say you must allow 4 bus clocks for the address decode. They don't
deal with
Alan Cox wrote:
The natsemi docs here say otherwise. I trust them not you.
As well you should. I am honestly curious (for my own satisfaction) as
to what the natsemi docs say the delay code should do (can't imagine
they say "use io port 80 because it is unused"). I don't have any
copies a
On Tuesday 08 January 2008 19:51:41 Bodo Eggert wrote:
> On Tue, 8 Jan 2008, Ondrej Zary wrote:
> > On Tuesday 08 January 2008 18:24:02 David P. Reed wrote:
> > > Windows these days does delays with timing loops or the scheduler. It
> > > doesn't use a "port". Also, Windows XP only supports machi
On Tue, 8 Jan 2008, Ondrej Zary wrote:
> On Tuesday 08 January 2008 18:24:02 David P. Reed wrote:
> > Windows these days does delays with timing loops or the scheduler. It
> > doesn't use a "port". Also, Windows XP only supports machines that tend
> > not to have timing problems that use delays.
> There is no need to use io writes to supposedly/theoretically "unused
> ports" to make drivers work on any bus.
The natsemi docs here say otherwise. I trust them not you.
> don't remember writing a driver for the 3com devices - probably didn't,
> because 3Com's cards were expensive at the tim
Ondrej Zary wrote:
On Tuesday 08 January 2008 18:24:02 David P. Reed wrote:
Windows these days does delays with timing loops or the scheduler. It
doesn't use a "port". Also, Windows XP only supports machines that tend
not to have timing problems that use delays. Instead, if a device take
On Tuesday 08 January 2008 18:24:02 David P. Reed wrote:
> Windows these days does delays with timing loops or the scheduler. It
> doesn't use a "port". Also, Windows XP only supports machines that tend
> not to have timing problems that use delays. Instead, if a device takes
> a while to respon
Windows these days does delays with timing loops or the scheduler. It
doesn't use a "port". Also, Windows XP only supports machines that tend
not to have timing problems that use delays. Instead, if a device takes
a while to respond, it has a "busy bit" in some port or memory slot that
can b
On Tuesday 08 January 2008 02:38:15 David P. Reed wrote:
> H. Peter Anvin wrote:
> > And shoot the designer of this particular microcontroller firmware.
>
> Well, some days I want to shoot the "designer" of the entire Wintel
> architecture... it's not exactly "designed" by anybody of course, and
>
> The last time I heard of a 12 MHz bus in a PC system was in the days of
> the PC-AT, when some clone makers sped up their buses (pre PCI!!!) in an
> attempt to allow adapter card *memory* to run at the 12 MHz speed.
It wasn't about clone makers speeding up their busses. The ISA bus
originally
The last time I heard of a 12 MHz bus in a PC system was in the days of
the PC-AT, when some clone makers sped up their buses (pre PCI!!!) in an
attempt to allow adapter card *memory* to run at the 12 MHz speed.
This caused so many industry-wide problems with adapter cards that
couldn't be ins
> The PIT usage for calibrating the delay loop can be moderated, if need
> by, by using the PC BIOS which by definition uses the PIT correctly it
> its int 15 function 83 call.. Just do it before coming up in a state
> where the PC BIOS int 15h calls no longer work. I gave code to do this
>
H. Peter Anvin wrote:
And shoot the designer of this particular microcontroller firmware.
Well, some days I want to shoot the "designer" of the entire Wintel
architecture... it's not exactly "designed" by anybody of course, and
today it's created largely by a collection of Taiwanese and Ch
David P. Reed wrote:
And actually, if I had looked at the /sys/bus/pnp definitions, rather
than /proc/ioports, I would have noticed that port 80 was part of a
PNP0C02 resource set. That means exactly one thing: ACPI says that
port 80 is NOT free to be used, for delays or anything else.
T
On another topic. I have indeed determined what device uses port 80 on
Quanta AMD64 laptops from HP.
I had lunch with Jim Gettys of OLPC a week ago; he's an old friend since
he worked on the original X windows system. After telling him my story
about port 80, he mentioned that the OLPC XO m
H. Peter Anvin wrote:
Rene Herman wrote:
Is this only about the ones then left for things like legacy PIC and
PIT? Does anyone care about just sticking in a udelay(2) (or 1) there
as a replacement and call it a day?
PIT is problematic because the PIT may be necessary for udelay setup.
* David P. Reed <[EMAIL PROTECTED]> wrote:
> FYI - another quirky Quanta motherboard from HP, with DMI readings reported
> to me.
> Using port80.c, I could hard lock a HP Pavilion tx1000 laptop on the
> first go. This was with ubuntu hardy's stock kernel (a 2.6.24-rc)
>
>> dmidecode -s baseboa
FYI - another quirky Quanta motherboard from HP, with DMI readings
reported to me.
Original Message
Date: Wed, 2 Jan 2008 16:23:27 +1030
From: Joel Stanley <[EMAIL PROTECTED]>
To: David P. Reed <[EMAIL PROTECTED]>
Subject:Re: [PATCH] Option to disable AMD C1E (a
61 matches
Mail list logo
