If you overclock, you are on your own. IIRC I've used 13,3 MHz for some time
Defaulting to 8 MHz and offering an option to set another clock speed

(like idebus=) should be OK.
--

On Mon, 07 Jan 2008 20:38:09 +0100
That would not be overclocking, rather that the hardware designer would

have determined that on that specific hardware design, all peripherals

are able to run at 12MHz.  
Also note that on some other system the hardware designer might have

decided to have a slower ISA clock, to save power, fulfil some EMI
Sounds like a big regression to have to start using a command line

option, when the current state of affairs is "it just works".
  /Christer

--

The formalization of the ISA bus which was part of the EISA

specification settled on 8.33 MHz maximum nominal frequency.  There

were, however, some earlier designs which used up to 12 MHz nominal; I'm

not sure if that applied to 386s though.
	-hpa

--

I've used up to 13,3 MHz on my 386DX40, but it was way out of spec and

I had to use a lower PIO mode to compensate. IIRC, one of my cards forced

me to settle for 10 MHz. Wikipedia claims there were systems having

16 MHz ISA bus, and systems underclocking themselves when accessing ISA.

I remember having optional and mandatory waitstates, too, but I'm not

100 % sure it was on ISA. I think they were ...
But overclocking is not the problem for udelay, it would err to the safe

side. The problem would be a BUS having < 8 MHz, and since the days of

80286, they are hard to find. IMO having an option to set the bus speed

for those systems should be enough.
--

knghtbrd:<JHM> AIX - the Unix from the universe where Spock has a beard.

--

If you get it wrong you risk data corruption. Not good, not clever, not

appropriate. Basically the use of port 0x80 is the right thing to do for

ISA devices and as 15 odd years of use has shown works reliably and

solidly for ISA systems.
Alan

--

As long as there is no port 80 card or a similar device using it. If

there is a port 80 card, ISA acess needing the delay does break, cause

the data corruption you fear and does cause this thread to be started.

Pest, Cholera ...
OTOH, maybe the 6-MHz-delay is the same as the 8-MHz-delay, and the kernel

parameter is not needed.

--

Fun things to slip into your budget

A Romulan Cloaking device:

	The PHB won't know what it is but will be to chicken to ask

--

Such cards are very unusual on ISA machines and it hasn't been a problem

in fifteen years. All the alternatives are vastly higher risk

--

There might have been a few 386/20's clocking the ISA bus at ­­÷3

(6.67 MHz) rather than ÷2 (10 MHz) or ÷2.5 (8 MHz).
	-hpa

--

Yes, and the remaining users should set the kernel option. Both of them.

The question is: How will they be told about the new kernel option?

--=20

A man inserted an advertisement in the classified: Wife Wanted."

The next day he received a hundred letters. They all said the

same thing: "You can have mine."

What exactly are you guys still talking about? Alan is looking at drivers

and finds that in them outb_p is generally correct and correctly specified

in bus-clocks for at least some (8390 was quoted). In those legacy drivers,

the _p ops can simply stay and can use the 15-year old proven 0x80 outb.
(with molnar suggesting they be renamed isa_in/outb_p and me suggesting that

if someone would be doing _that_ they might as well split them manually in

outb(); slow_down_io() possibly renaming slow_down_io() to isa_io_delay() or

similar).
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?
Rene.
--

PIT is problematic because the PIT may be necessary for udelay setup.
	-hpa

--

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

in a much earlier message.
This is the MOST reliable way to use the PIT early in boot, on a PC

compatible.  God knows how one should do it on a Macintosh running a

386/20  :-).   But the ONLY old bat-PIT machines are, thank god, PC

compatible, maybe.
--

And as I've said before we don't know if we have a PC BIOS. If we are

running from a kexec or on a Macintoy with EFI or an Xbox we may not.
As per previous discussions for the PIT we can simply guess a safe

initial udelay value and then tune the real one.
Alan

--

Yes, can initialise loops_per_jiffy conservatively. Just didn't quite get

why you guys are talking about an ISA bus speed parameter.
Rene.
Rene.

--

If the ISA bus is below 8 MHz, we might need a longer delay. If we default

to the longer delay, the delay will be too long for more than 99,99 % of

all systems, not counting i586+. Especially if the driver is fine-tuned to

give maximum throughput, this may be bad.
OTOH, the DOS drivers I heared about use delays and would break on

underclocked ISA busses if the n * ISA_HZ delay was needed. Maybe

somebody having a configurable ISA bus speed and some problematic

chips can test it ...
--

Fun things to slip into your budget

"I [Meow Cat] sliped in 'Legal fees for firing Jim (Jim's my [his] boss).'

Jim approved the budget and was fired when upper management saw the budget."

--

I've been looking at DOS reference drivers - they almost all use I/O port

based delays.
--

Yes, and I repeat -- old legacy ISA drivers can stay as they are. They've

been doing what they've been doing for 15 years and given that the systems

that break don't use them there is no practical upside to changing them and

a big downside particularly with respect to difficulty of testing.
A somewhat overly long delay shouldn't be particularly problematic for the

few remaining legacy hardware users _outside_ drivers/
Rene.

--

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 installed in certain machines and still run reliably that

the industry learned a lesson.  That doesn't mean that LPCs don't run at

12 MHz, but if they do, they don't have old 8 bit punky cards plugged

into them for lots of practical reasons.  (I have whole drawers full of

such old cards, trying to figure out an environmentally responsible way

to get rid of them - even third world countries would be fools to make

machiens with them).
I can't believe that we are not supporting today's machines correctly

because we are still trying to be compatible with a few (at most a

hundre thousand were manufactured!  Much less still functioning or

running Linux) machines.
Now I understand that PC/104 machines and other things are very non PC

compatible, but are x86 processor architectures.  Do they even run x86

under 2.6.24?
Perhaps the rational solution here is to declare x86 the architecture

for "relics" and develop a merged architecture called "modern machines"

to include only those PCs that have been made to work since, say, the

release of (cough) WIndows 2000?
--

It wasn't about clone makers speeding up their busses. The ISA bus

originally ran at the CPU clock - 4.77/8/6/10 .. etc. Quite a few board

makers assumed 8MHz and while faster isn't a big problem at 8bit trying

to do the 8/16 bit decode with logic chips at 8MHz is quite tight and

above that generally broke. 8bit tends to work fine because you've got a
It is about supporting this properly. Properly for ISA devices means
Linux runs on x86, it isn't limited to PC type architectures at all. We
No point. We've got the 64bit kernel for that. That is a much saner

boundary to throw out all the nutty stuff.
Alan

--

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 machine had some issues

with port 80 which was by design handled by the ENE KBC device on its

motherboard.   He said the ENE was a very desirable chipset for AMD

designs recommended by Quanta.  Richard Smith of OLPC explained to me

how the KB3700 they use works, and that they use the KB3700 to send POST

codes out over a serial link during boot up.
This gave me a reason to take apart my laptop, to discover that it has

an ENE KB3920 B0 as its EC and KBC.  The port interface for the KB3920

includes listening to port 80 which is then made available to firmware

on the EC.  It is recognized and decoded on the LPC bus, only for

writes, and optionally can generate an interrupt in the 8051.
Dumping both the ENE chip, and looking at the DSDT.dsl for my machine, I

discovered that port 80 is used as an additional parameter for various

DSDT methods that communicate to the EC, when it is operating in ACPI mode.
More work is in progress as I play around with this.  But the key thing

is that ACPI and perhaps SMM both use port 80 as part of the base

function of the chipset.
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.
This should make no difference here: it's just one more reason to stop

using port 80 for delays on modern machines.
--

And shoot the designer of this particular microcontroller firmware.
	-hpa

--

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 Chinese ODM

firms, coupled with Microsoft WinHEC and Intel folks.  At least they

follow the rules and their ACPI and BIOS code say that they are using

port 80 very clearly if you use PnP and ACPI properly.  And in the old

days, you were "supposed" to use the system BIOS to talk to things like

the PIT that had timing issues, not write your own code.
Or perhaps the ACPI spec should specify a timing loop spec and precisely

specify the desired timing after accessing an I/O port till that device

has properly "acted" on that operation.
The idea that Port 80 was "unused" and appropriate for delay purposes

elicited skepticism by Linus that is recorded for posterity in the

comments of the relevant Linux include files - especially since it was

clearly "used" for non-delay purposes, by cards that could be plugged

into a PCI (fast), not just an 8-bit ISA, bus.
Perhaps we should declare the world of ACPI systems a separate "arch"

from the world of l'ancien regime where folklore about which ports were

used for what ruled.   I lived through those old days, and they were not

wonderful, either.
The world sucks, and Linux is supposed to be able to adapt to that

world, suckitude and all.
--

Does anyone know what port does Windows use? I'm pretty sure that it isn't 80h

as I run Windows 98 often with port 80h debug card inserted. The last POST

code set by BIOS usually remains on the display and only changes when BIOS

does something like suspend/resume. IIRC, there was a program that was able

to display temperature from onboard sensors on the port 80h display that's

integrated on some mainboards.
--

Ondrej Zary

--

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 be tested.
Almost all of the issues in Linux where _p operations are used are (or

should be) historical - IMO.
--

Windows XP can run on a machine with ISA slot(s) and has built-in drivers for

some plug&play ISA cards - e.g. the famous 3Com EtherLink III. I think that 
--

Ondrej Zary

--

The NE2K-driver went missing in W2K. BTDT.

--

Anyone can speak Troll. All you have to do is point and grunt.

	-- Fred Weasley

--

Haven't tried personally but it seems to work accroding to this

http://www.windowsnetworking.com/articles_tutorials/wxpne2k.html - and it can

be made to work even with non-PnP cards.
--

Ondrej Zary

--

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 full flag in a tight loop, with no delay code at all.  And

if you need to time things, just call a timing loop subroutine that you

calibrate at boot time.

I wrote DOS drivers for NE2000's on the ISA bus when they were brand new

designs from Novell without such kludges as writes to I/O port 80.  I

don't remember writing a driver for the 3com devices - probably didn't,

because 3Com's cards were expensive at the time.
In any case, Linux *did* adopt this port 80 strategy - I'm sure all

concerned thought it was frightfully clever at the time.  Linus

expressed his skepticism in the comments in io.h.  The problem is to

safely move away from it toward a proper strategy that doesn't depend on

"bus aborts" which would trigger machine checks if they were properly

enabled.
--

On Tue, 08 Jan 2008 13:44:54 -0500
Now you're totally confusing things.  You're talking about looking at

bits in a register to see if a transmit register is empty.

That's easy.
The delays needed for the Intel M8259 and M8253 say that you're not

even allowed to access the registers _at_ _all_ for some time after a

register access.  If you do a write to a register immediately followed

by any access, including a read of the status register, you can corrupt

the state of the chip.
And the Intel chips are not the only ones with that kind of brain

damage.  But what makes the 8259 and 8253 a big problem is that every

modern PC has a descendant of those chips in them.  The discrete Intel

chips or clones got aggregated into Super I/O chips, and the Super I/O

chips were put on a LPC bus (an ISA bus with another name) or

integrated into the southbrige.  And the "if it ain't broken, don't fix

it" mantra probably means that some modern chipsets are still using

exactly the same internal design as the 25 year old chips and will

still be subject to some of those ancient limitations.
  /Christer

--

Not true.  Even on the original IBM 5150 PC, the 8259 on the motherboard

accepted back to back  OUT and IN instructions, and it would NOT trash

the chip state.  You can read the original IBM BIOS code if you like.  I

don't remember about the 8253's timing.  I doubt the chip's state would

be corrupted in any way. The data and address lines were the same data

and address lines that the microprocessor used to access memory - it

Register compatible.  Not  the same chips or even the same  masks or

Don't try to teach your grandmother to suck eggs: I've been programming

PC compatibles since probably before you were able to do long division -

including writing code on the first prototype IBM PCs, the first

pre-manufacturing PC-ATs, and zillions of clones.  (and I was also

involved in designing hardware including the so-called "Lotus Intel"

expanded memory cards and the original PC cards)  The 8259 PIC is an

*interrupt controller*. It was NEVER present in a Super I/O chip, or an

LPC chip.  Its functionality was absorbed into the chipsets that control

Oh, come on.  Give the VLSI designers some credit for brains.   The CAD

tools used to design the 8259 and 8253 were so primitive you couldn't

even get a chip manufactured with designs from that era today.  When

people design chips today they do it with simulators that can't even

work, and testers that run from test suites that were not available at

the time.

--

On Tue, 08 Jan 2008 15:28:03 -0500
No, but somehow people keep making similar mistakes.  The DEC HiNote

needed outb_p to function correctly?  That was definitely a much more

modern design than the original PC and most probably did not use any

discrete Intel chips, but the same timing problems were there.  I belive
Argument by personal authority.  Thats good.  I guess that's why you

don't seem to understand the difference between reading the serial port

status register and not being allowed to access a register at all

due to such this as the 4 cycle delay you quoted yourself from the 8390

data sheet, and similar issues with the I8253 that I quoted from its
Yup, sorry about that, it got integrated into some other chip instead.

I was thinking of another timer, the RTC which is usually a part of the

Super I/O. And which is yet another troublesome area since apparently a

lot of chipsets have problems with it.  But the sequence is the same,

discrete chips get aggregated into larger chips. Sometimes the

sometimes old macrocells are reused, sometimes they are redesigned from
And they still keep making the same mistakes...  Registers that require

wait states before being read again, register that assume that there

are going to be some spare cycles between each access so that some

internal logic has time to update, registers that would have needed a

one byte FIFO to avoid DMA overruns (I'd almost forgotten about that

specific bug on SPI controller of the Samsung 2410, but it bit me last

week and I only managed to chase it down properly yesterday), and so on.
I'm quite impressed with what some VLSI designers manage to do.  I just

saw a company roll out a completely new ARM9 design with lots of fun

stuff and as far as I know they only made one single mistake on that

chip.  On the other hand, on other designs you can see how the same old

macrocell has been reused long past the "best before" date, because

some bugs crop up over and over again.  
  /Christer

--

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 back in my home office), code that others wrote at the time,

and documentation from vendors that come from my personal experiences.

That doesn't mean I'm always right - always happy to learn something

new.  Just don't condescend to a 55 year old who has been writing

operating systems, compilers, and designing hardware for almost 40 years

professionally (yes, I got my first job at 16 writing FORTRAN code to

If you read what I said carefully, I said that the 8390 was a very

special case.   The "chip select" problem it experienced was pretty much

unique among boards of the time.  Those of us who looked at its design

and had any experience designing hardware for buses like the unibus or

even the buses on PDP-8's and DG machines thought it had to be a joke.

Of course it saved money per board, so it beat the 3Com boards on price

- and you could program it after a fashion.  So it involved "cheaping out".
The normal timing problem was that an out or in operation to a board or

chip required some time to elapse before the chip performed the side

effects internally so that the next operation to it would have an

effect.  This is exactly the reason why most chips and boards are

designed to either have a polling of a flag indicate operation

completion.  The serial "buffer empty" flag is the simplest possible

explanatory example of such handshaking that came to mind (writing a

character to a serial output device twice often leads to surprises,

unless you wait for the previous character to clock out).  See my

The 8253 was a motherboard chip.  I am not sure it had any timing

problems with its electrical signalling.  I just don't remember.  The

The RTC has very well documented timing requirements.  But none of the

spec sheets, nor my experience with it, me...
[ message continues ]

3C503 needs delays for some setups according to the docs. I can't tell

you how the 3COM drivers did it as that was a different bit of 3com to

the bit I worked for. From the rest of 3Com I saw probably utterly

vilely ;)
Later 3Com stuff was either sane (3c509 etc) or used whacko intel chips

(3c507/27) which had their own special breed of insanity to replace
No. The problem is that certain people, unfortunately those who know

nothing about ISA related bus systems, keep trying to confuse ISA delay

logic with core chip logic and end up trying to solve both a problem and a

non-problem in one, creating a nasty mess in the process.
Alan

--

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 anymore. But mere curiosity on my part is not worth spending a

lot of time on - I know you are super busy.   If there's a copy online

I agree that the problems of chip logic and ISA delay are all tangled

up, probably more than need be.  I hope that the solution turns out to

simplify matters, and hopefully to document the intention of the

resulting code sections a bit more clearly for the future.

--

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 vested interest in this, both as the owner of an

affected HP dv9210us laptop and as a maintainer of paravirt code - and

would like 64-bit Linux code to stop using I/O to port 0x80 in both

cases (as I suspect would every other person involved with

virtualization).
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).  This means

simultaneous execution of two virtual machines can interleave port 0x80

values or share data with a hardware provided covert channel.  This

means KVM should be trapping port 0x80 access, which is really

expensive, or alternatively, Linux should not be using port 0x80 for

timing bus access on modern (64-bit) hardware.
I've tried to follow this thread, but with all the jabs, 1-ups, and

obscure legacy hardware pageantry going on, it isn't clear what we're

really doing.
Thanks,
Zach
--

On Tue, 08 Jan 2008 18:52:42 -0800
I belive Alan Cox is doing a review of some drivers, to see if they

actually need the I/O port delay.  A lot of drivers probably use outb_p

just because it was copy-pasted from some other driver and it can be

removed.  Alan's review has also brought to light a lack of locking in

some drivers, so I think Alan has been adding proper locking to some of

the watchdog drivers.
Most old ISA only device drivers can keep using OUT 80h.  They are not

used on modern machines and it's better to keep them unchanged to avoid

unneccesary incompatibilities.
As far as I know, the 8253 PIT timer code needs outb_p on some older

platform, and this is one of the most troublesome since the same PIT

controller (or a register compatible one) has been used since the

original IBM PC, and it is frequently executed code.  Ingo Molnar has

done an alternate implementation of the PIT clock source which uses

udelay instead of OUT 80h to delay accesses to the ports. The kernel

could make a choice of which variant to use based on the DMI year, if

compiling for x86_64, or something similar.  Maybe have a command line

option too.
The keyboard controller on some platform needs the delay, and the same

driver is used on both ancient and modern systems, I think it can be

changed to udelay since it's not so time critical code.
The 8259 interrupt controller on some platform needs the delay, I think

it can be changed to udelay since it's only some setup code that uses

outb_p.  I guess there are time critical accesses to the interrupt

controller from assembly code somewhere to acknowledge interrupts, and

that code needs a review.
The floppy controller code uses outb_p.  Even though there might be

floppy controllers on modern systems, I'd rather leave the floppy code

alone since it's supposed to be very fragile.  If you still use

floppies you deserve what you get.
Some specific drivers, such as drivers for 8390 or 8390 clone based

network cards are also a bit troublesome, they ...
[ message continues ]

Yes, Alan should be considered to be in the driver seat here (and current 
Just udelay() should be fine after "fixing" udelay() to be somewhat usefully 
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 point that udelay() is sensible.
Floppies forever. In practice, leaving it alone isn't going to matter, but

in that same practice changing it to udelay() probably doesn't either. The

ones to leave alone are the ones that are clumsy/impossible to test and the 
... or simply deleted. The current outb_p is "outb; slow_down_io" as a macro

so that with this you also get no binary changes, making it rather easy to

prove that things do not change timing in cases where you keep the delay.
Based on specific DMI strings this can be limited to tested machines (as in 
... destroying DX while it's at it meaning this might (will) also need DX

reloads. Not an argument versus a function call, but an argument versus the 
Not so much it seems. Only that the only reason for the outb_p slit is an

API one. Molnar wants the API cleaned up to make sure no new users of outb_p

creep in, and being explkicit abhout what it that you're doing is going to

take care of that.
If simple outb_p() deprecation is considered enough instead, no need to

touch anything in drivers/, only changes to "outb(); udelay()" outside drivers/.
I'd let Alan decide here.
Thanks for the roundup.
Rene.

--

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
Agree.
Zach
--

I don't think the latter statement was true - AFAIR there are Alphas 
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
--

See subject line.
	-hpa

--

Why should the bitsize of the CPU matter for this?  It seems one of the

less meaningful keys for this.
Second, as I have mentioned, I don't believe this is really the case,

especially not for the PIT, which is still present -- the PIT

*semantics* has explicit timing constraints.
Third, you still have ISA devices, they're just called LPC or PC104

devices these days.
	-hpa

--

On Wed, 09 Jan 2008 10:18:11 -0800
Or PCMCIA.  I'm still a happy user of a Zyxel ZyAIR 100B, it's one of

the most stable cards Wifi I've got running under Linux.   :-)
  /Christer

--

Yes, but you hardly want a situation where the machine works booting a

32-bit kernel and not a 64-bit kernel, or vice versa.
Furthermore, it's not so much about "modern" versus "old", it is about

picking a certain set of bugs.
	-hpa

--

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 devices in their _CRS

settings in ACPI during ACPI PnP startup should be reserved (or

checked), and any drivers that still use port 80 implicitly should

reserve that port.
This may be too late in the boot process to make a decision not to use

port 80, and it

doesn't help decide a strategy to use an alternate port (0xED happens to

"work" on the dv9000 machines in the sense that it generates a bus

timeout on LPC, but there is no guarantee that 0xED is free on any

particular motherboard, and "unusedness" is not declared in any

BIOS/ACPI tables) or to use a udelay-based iodelay (but there is nothing

in the BIOS tables that suggest the right delays for various I/O ports

if any modern parts need them...which I question, but can't prove a

negative in general).
However, doing the reservations on such resources could generate a

warning that would help diagnose new current and future

designs including devices like the ENE KB3920 that have a port that is

defaulted to port 80 and routed to the EC for functions that the

firmware and ACPI can agree to do.  Or any other ports used in new ways

and properly notified to the OS via the now-standard Wintel BIOS functions.
I don't know if /proc/ioports is being maintained, but the fact that it

doesn't contain all of those PNP0C02 resources known on my machine seems

to be a bug - which I am happy to code a patch or two for as a

contribution back to Linux, if it isn't on the way out as the /sys

hierarchy does a better job.

/sys/bus/pnp/... does get built properly and has port 80 described

properly - not as a DMA port, but as a port in use by device 05:00,

which is the motherboard resource catchall.  Thus the patch would be small.
--

That's funny, because there is definitely no guarantee that you get back

what you read (well, perhaps there is on Apple.)
	-hpa

--

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 works on just about every PC platform.  Except, apparently,

my laptop.
Zach
--

The port 80 problem was discovered by me, after months of "bisecting"

the running code around a problem with hanging when using hwclock in

64-bit mode when ACPI is on.  So it kills my laptop, too, and many

currentlaptop motherboards designed by Quanta for HP and Compaq (dv6000,

dv9000, tx1000, apparently)
In the last couple of weeks, I was able with luck to discover that the

problem is the ENE KB3920 chip, which is the "big brother" of the KB3700

chip included in the OLPC XO "$100 laptop" made also by Quanta.  I

verified this by taking my laptop apart - a fun and risky experience.

Didn't break any connectors, but I don't recommend it for those who are

not experienced disassembling laptops and cellphones, etc.  The KB3920

contains an EC, an SMBus, a KBC, some watchdog timers, and a variety of

other functions that keep the laptop going, coordinating the

relationships among various peripherals.  The firmware is part standard

from ENE, part OEM-specific, in this case coded by Quanta or a BIOS

subcontractor.
You can read the specsheet for the KB3700 online at laptop.org, since

the specs of the laptop are "open".  The 3920's spec is confidential.

And the firmware is confidential as well for both the 3700 and 3920.

Clues as to what it does can be gleaned by reading the disassembler

output of the DSDT code in the particular laptops - though the SMM BIOS

probably also talks to it.
Modern machines have many subsystems, and the ACPI and SMBIOS coordinate

to run them; blade servers also have drawer controllers and backplane

management buses.  The part that runs Linux is only part of the machine.
Your laptop isn't an aberration.  It's part of the new generation of

evolved machines that take advantage of the capabilities of ACPI and

SMBIOS and DMI standards that are becoming core parts of the market.
--

Thanks very much for that - I was debugging this for a while too, and
I beg to differ.  I managed to turn the thing into a brick by upgrading

the BIOS (with the correct image, no less) in an attempt to fix it.  I

just got it back from repair.  I'm not sure that is positive

evolutionary development, but it certainly does make my laptop an

aberration :)
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.
Zach
--

Might not give you a "proper" delay though. 0xed should be a better choice...
Rene.

--

Not entirely unusable. You can recover silently from the machine check

if it was one of the known accesses to the 'unused port'. It certainly

achieves a delay :)
On ppc32 we recover from the machine check if it was any inb/outb --

mostly to work around crappy drivers developed on i386, I believe.
--

dwmw2
--

I'm sure that's what the driver writers had in mind.  ;-)
And 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 least

Microsoft doesn't have a patent on using port 80 for delay purposes. :-)
--

This use of port 80 (or insert some other random number) is a croc of

hackery of the most inexperienced kind.  The task to be performed is to

delay for some period, and I think it's a mix of bloody mindedness and

fear of unfamiliar code and specification that explains why a delay is

not being coded.  Lest we forget, someone who should know better said

that an OUT is used because you don't know how long the delay should be

on any specific machine.  What rubbish.
For what it's worth, I would oppose any attempt to ammend ACPI

specifications in the way described above.  It's bad enough to have that

embarrassing and unseemly hack in Linux.  It would be so much worse to

enshrine the practice as industry standard practice.
I won't even mention the many instances of these delays where no delay

is what properly is needed.  Performance?  Who cares about performance?

--

On Thu, 17 Jan 2008 01:06:24 +1030
Wrong. It's a careful designed solution used by all sorts of code for

over 15 years.
 The task to be performed is to delay for some period
Wrong, it is for some number of bus clocks which is why I/O cycles are
Correctness, who needs correctness ?
Alan

--

It's not careful: it's a croc.  It's an ugly hack, an abuse of process,

Wrong.  It's a delay.  It's a delay measured in I/O cycles, but still a

delay.  Doing I/O to get a delay, even if the delay is intended to be

measured in I/O cycles, is hackery of the most inexperienced sort.  It's

the sort of thing junior programmers get boxed in the ear for.  There's

no satisfactory reason to do it that way.
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

Wrong again.  Of course one knows how long the delay should be.  The bus

speed is known.  The specifications of the hardware is known.  Do the

math you (the programmer writing the driver, not Alan) lazy sluggard,

and use a delay.  It baffles commonsense to say you don't know how long

Well, frankly, the development process could stand a little more of it.
The sooner we stop denying that this is a hack, the sooner we can fix it.

--

And the only instruction that is synchronized to the bus in question is
Wrong again. ISA bus speed is neither defined precisely, nor visible in a

system portable fashion.
I'm so glad you have nothing better to do than troll, if you

actually wrote code I'd be worried it might get into something people

used.
Alan

--

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
You say, "system portable," but I think you mean, "automatically

determined."  We don't have to define this value automatically, if
I'm not trolling.  You know this is true because many people perceive

this to be a problem.  I'm working on fixing it.  Not all Linux problems

are solvable by diving into code, and there is anecdotal evidence to

believe this one has big performance considerations.  I don't understand
Speaking of writing code: I remember working on a bluetooth Oops.

Lacking the hardware, I went to you for advice on how to get it before

someone for testing.  You never replied.

--

The characteristics of the bus are not known. It could be anything

between 6 and about 16MHz. The way you read the bus clock is system

dependant.
The underlying problem is really that over time some of the hardware has

moved from the ISA world into the chipsets. That is why I sent Ingo the

patches for inb_pit/inb_pic and to split ISA 8390 and non ISA 8390

support. Someone has to tackle the CMOS but we are then in a position to

relegant port 0x80 timing use to ISA systems where it is fine.
Alan

--

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 the characteristics of the bus on a given machine vary for

reasons other than user selection?
The fact that busses run at different speeds on different machines is

not a problem because the delay value can be determined for each given

machine.
The question is, for a given machine, can we determine a delay value

instead of using a junk I/O?

--

They vary based on the CPU clock, the dividers from PCI to ISA on PCI

based boxes, and on the ISA only ones often on the CPU speed.
Unfortunately the way you control that divider or read it is chipset

specific. Nor would it be reasonable to expect the end user to set it.
The question (for ISA peripherals) is "why bother", and with the 8390

patch there are one or two dubious PCI driver users of _p left but not

much else that isn't ISA or chipset logic. The question for chipset logic

where it has become integrated is "can we get rid of it for some devices,

if not what can we use instead"
Alan

--

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. Both hpa and alan are in this thread and everyone else

can be ignored on the issue.
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.
Rene.

--

Rather than this incredible rudeness, why don't you direct your energy

towards convincing Alan of this.  He's the hold-out.

--

No he isn't and that's why I'm rude -- everything needs to be repeated over

and over and over again. Read the thread(s). You didn't limit your reply to

chipset logic and Alan even already submitted patches to isolate the delay

for the chipset logic (PIC and PIT that is) where the expectation is that a

simple udelay() will suffice.
We've already talked about ISA bus speed, and how it's not in a sane sense

portably determinable, we've already talked about kernel parameters, about

udelay and it's usefulness in early boot, about how your rude "Junk I/O" is

exactly what is needed for some ISA devices and so on...
In fact, we're blue in the face from talking about it. So say something

useful or go away.
Rene

--

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.
The problem is that _p is widely used for non-ISA devices.  For example,

a quick grep reveals the following (and more) all use outb_p:
    ./i2c/busses/i2c-amd756.c

    ./i2c/busses/i2c-ali1535.c

    ./i2c/busses/i2c-ali15x3.c

    ./i2c/busses/i2c-i801.c

    ./i2c/busses/i2c-piix4.c

    ./i2c/busses/i2c-viapro.c

    ./i2c/busses/i2c-nforce2.c

    ./i2c/busses/i2c-ali1563.c

    ./telephony/ixj.c

    ./char/pc8736x_gpio.c

    ./char/epca.c

    ./char/dtlk.c

    ./char/watchdog/w83697hf_wdt.c

    ./char/watchdog/wafer5823wdt.c

    ./char/watchdog/wdt.c

    ./char/watchdog/sc1200wdt.c

    ./char/watchdog/pc87413_wdt.c

    ./char/watchdog/wdt_pci.c

    ./char/watchdog/w83977f_wdt.c

    ./char/watchdog/pcwd_pci.c

    ./char/watchdog/w83877f_wdt.c

    ./char/watchdog/mixcomwd.c

    ./char/watchdog/w83627hf_wdt.c

    ./char/watchdog/advantechwdt.c

    ./char/watchdog/ib700wdt.c

    ./char/watchdog/pcwd.c

    ./char/watchdog/wdt977.c

    ./char/rocket_int.h

    ./char/sonypi.c
Most of these go nowhere near the ISA bus.  This has been said before,

but perhaps you missed that.  Which is another reason to use good

manners, isn't it?
I think I'm saying something useful.  I'll keep an eye out for your

humble apology.  (Are you big enough to give one?)   In the mean time,

perhaps you'll follow your own advice and say something useful or go

away.  :-p
I hope you'll see this in the positive and constructive light that it is

intended.

--

Yes, we know, it's being fixed. Piss off.
Rene.

--

Golly, you don't think so? Just commenting on his local hack. Port 0x84 is

inside the (reserved) DMA page register range and stands a better chance of

not being echoed onto ISA by various chipsets than 0xed does due to that.
Yes -- on a sane machine it's all useless anyway and with all sane machines

this discussion would've ended quite some time ago already. It's the insane,

obsolete legacy junk that's the problem.
Rene.

--

An ISA/LPC bus timeout is fulfilled by the bridge so doesn't cause an MCE.
Alan

--

Good possibility, but the documentation on HyperTransport suggests

otherwise, even for LPC bridges in this particular modern world of

AMD64. I might do the experiment someday to see if my LPC bridge is

implemented in a way that does or doesn't support enabling MCE's. Could

be different between Intel and AMD - I haven't had reason to pore over

the Intel chipset specs, since my poking into all this stuff has been

driven by my personal machine's issues, and it's not got any Intel

compatible parts.

--

If you have a subtractive decoding bridge you will have completion on HT.
	-hpa

--

They say you must allow 4 bus clocks for the address decode. They don't
Not that I know of. There may be. A good general source of info is Russ

Nelson's old DOS packet driver collection.
--

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 between checking the

CRDA addresses to see if a dummy "remote read" has been executed., and

in regard perhaps to other card IO register loops: 
    TIME BETWEEN CHIP SELECTS
    The SNIC requires that successive chip selects be no

    closer

    than 4 bus clocks (BSCK) together. If the condition is

    violat-

    ed the SNIC may glitch ACK. CPUs that operate from pipe-

    lined instructions (i e 386) or have a cache (i e 486) can

    execute consecutive I O cycles very quickly The solution is

    to delay the execution of consecutive I O cycles by either

    breaking the pipeline or forcing the CPU to access outside

    its cache.
The NE2000 as I recall had no special logic on the board to protect the

chip from successive chip selects that were too close - which is the

reason for the problem. Clearly an out to port 80 takes more than 4 ISA

bus clocks, so that works if the NE2000 is on the ISA bus,   On the

other hand, there are other ways to delay more than 4 ISA bus clocks.

And as you say, one needs a delay for this chip that relates to the

chip's card's bus's clock speed, not absolute time.
--