Re: tenth post about PCI code, need help

Re: tenth post about PCI code, need help

[Ray Lee]

> 1. which device is at port address 0xCFB? (please note, NOT 0xCF8)

0xcfb ('bee') is the fourth byte of the 32 bit register that sits/starts
at 0xcf8 ('eight'). Note the difference in the code between the outb and
outl calls.

To answer your other questions, I think you'd have better luck reading
the spec for the x86 pc-style PCI bridge chip, rather than the (generic)
PCI v2.0 spec itself. The spec for the actual chip is always the final
authority for what's going on. (Unless, of course, it's wrong...)

Ray

Re: tenth post about PCI code, need help

[Richard B. Johnson]

On 8 Jan 2003, Ray Lee wrote:

> > 1. which device is at port address 0xCFB? (please note, NOT 0xCF8)
> 
> 0xcfb ('bee') is the fourth byte of the 32 bit register that sits/starts
> at 0xcf8 ('eight'). Note the difference in the code between the outb and
> outl calls.
> 
> To answer your other questions, I think you'd have better luck reading
> the spec for the x86 pc-style PCI bridge chip, rather than the (generic)
> PCI v2.0 spec itself. The spec for the actual chip is always the final
> authority for what's going on. (Unless, of course, it's wrong...)
> 
> Ray
> 

The problem is that he's discovered something that's not supposed
to be in the code. Only 32-bit accesses are supposed to be made to
the PCI controller ports. He has discovered that somebody has made
some 8-bit accesses that will not become configuration 'transactions'
because they are not 32 bits. According to the spec, such accesses
become direct I/O to some underlying device. So, if some underlying
device shares the same I/O address space as the PCI device, that
machine is broken.

FYI, the mechanism by which ix86 hardware determines if the PCI
port access is a configuration read or configuration write is
the 32-bit access. Any other access cannot be interpreted by
the hardware as a configuration transaction. (Page 321., 
"Into to configuration Mechanisms", PCI System Architecture,
ISBN 0-201-30974-2)


It is possible that somebody had a bad board and found that writing
some junk to this port 'fixed' something. If this is so, then the
code needs some comments. Otherwise, the non-32bit accesses should
be removed.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.

Re: tenth post about PCI code, need help

[Ray Lee]

On Wed, 2003-01-08 at 10:49, Richard B. Johnson wrote:
> The problem is that he's discovered something that's not supposed
> to be in the code. Only 32-bit accesses are supposed to be made to
> the PCI controller ports.

<shrug> Okay, I withdraw my interpretation. Since I had to rewrite
arch/ppc/kernel/qspan_pci.c recently, I felt mildly qualified to offer
an opinion, but obviously I was wrong :-).

Ray

Re: tenth post about PCI code, need help

[H. Peter Anvin]

Followup to:  <Pine.LNX.3.95.1030108132812.28791A-100000@chaos.analogic.com>
By author:    "Richard B. Johnson" <root@chaos.analogic.com>
In newsgroup: linux.dev.kernel
> 
> The problem is that he's discovered something that's not supposed
> to be in the code. Only 32-bit accesses are supposed to be made to
> the PCI controller ports. He has discovered that somebody has made
> some 8-bit accesses that will not become configuration 'transactions'
> because they are not 32 bits.
> 

Right.  That's what the code is checking for.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: tenth post about PCI code, need help

[Richard B. Johnson]

On 8 Jan 2003, H. Peter Anvin wrote:

> Followup to:  <Pine.LNX.3.95.1030108132812.28791A-100000@chaos.analogic.com>
> By author:    "Richard B. Johnson" <root@chaos.analogic.com>
> In newsgroup: linux.dev.kernel
> > 
> > The problem is that he's discovered something that's not supposed
> > to be in the code. Only 32-bit accesses are supposed to be made to
> > the PCI controller ports. He has discovered that somebody has made
> > some 8-bit accesses that will not become configuration 'transactions'
> > because they are not 32 bits.
> > 
> 
> Right.  That's what the code is checking for.
> 
> 	-hpa

Somebody is very lucky the designer of the bus interface state-machine
let him get away with it. This is a borderline "insane instruction" that
could, on some (future?) machine, require a power-off to recover. This is
NotGood(tm). It's like testing a fuse by shorting out a circuit. If it
works, the circuit no longer works. If I doesn't, the circuit no longer
works. Some things should not be tested.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.

Re: tenth post about PCI code, need help

[H. Peter Anvin]

Richard B. Johnson wrote:
> On 8 Jan 2003, H. Peter Anvin wrote:
> 
> 
>>Followup to:  <Pine.LNX.3.95.1030108132812.28791A-100000@chaos.analogic.com>
>>By author:    "Richard B. Johnson" <root@chaos.analogic.com>
>>In newsgroup: linux.dev.kernel
>>
>>>The problem is that he's discovered something that's not supposed
>>>to be in the code. Only 32-bit accesses are supposed to be made to
>>>the PCI controller ports. He has discovered that somebody has made
>>>some 8-bit accesses that will not become configuration 'transactions'
>>>because they are not 32 bits.
>>>
>>
>>Right.  That's what the code is checking for.
>>
>>	-hpa
> 
> Somebody is very lucky the designer of the bus interface state-machine
> let him get away with it. This is a borderline "insane instruction" that
> could, on some (future?) machine, require a power-off to recover. This is
> NotGood(tm). It's like testing a fuse by shorting out a circuit. If it
> works, the circuit no longer works. If I doesn't, the circuit no longer
> works. Some things should not be tested.
> 

If so, we will get an bug report rather than mysterious strange
behaviour.  This is a good thing.  (Amusingly enough, exactly this code
in the Linux kernel actually found a bug in one of the very early
versions of the Transmeta northbridge.  It was fixed in firmware.)

	-hpa

tenth post about PCI code, need help

[fretre lewis]

hi,
  first, I have to say sorry for my 10th posting the same question , I hope 
someone can answer it indeed, it seem too difficult for me.


  I am learning code pci_check_direct(), at arch/i386/kernel/pci-pc.c

the PCI spec v2.0 say: ( page32)

"Anytime a host bridge sees a full DWORD I/O write from the host to
CONFIG_ADDRESS, the bridge must latch the data into its CONFIG_ADDRESS
register. On full DWORD I/O reads to CONFIG_ADDRESS,the bridge must return
the
data in CONFIG_ADDRESS. Any other types of accesses to this
address(non-DWORD)
have no effect on CONFIG_ADDRESS and are excuted as normal I/O transaction
on PCI bus......"

CONFIG_ADDRESS = 0xCF8
CONFIG_DATA = 0xCFC

so I think "outb (0x01, 0xCFB);" just is a normal write operation to a 
device at port address 0xCFB not a configuration type operation(maybe 
wrong,fix me), then my questions are:

1. which device is at port address 0xCFB? (please note, NOT 0xCF8)

2. what is meaning of the writing operation "outb (0x01, 0xCFB);" for THIS
device?, it'seem that PCI spec v2.0 not say anything about it?

3. why need "outb (0x01, 0xCFB);" before configuration operation "outl
(0x80000000, 0xCF8);" if check configuration type 1? and why need "outb
(0x00, 0xCFB);" before "outb (0x00, 0xCF8);" if check configuration type 2?

please help me, thanks a lot.

406 static struct pci_ops * __devinit pci_check_direct(void)
407 {
408         unsigned int tmp;
409         unsigned long flags;
410
411         __save_flags(flags); __cli();
412
413         /*
414          * Check if configuration type 1 works.
415          */
416         if (pci_probe & PCI_PROBE_CONF1) {
417                 outb (0x01, 0xCFB);  <<<=========
418                 tmp = inl (0xCF8);
419                 outl (0x80000000, 0xCF8);
420                 if (inl (0xCF8) == 0x80000000 &&
421                     pci_sanity_check(&pci_direct_conf1)) {
422                         outl (tmp, 0xCF8);
423                         __restore_flags(flags);
424                         printk(KERN_INFO "PCI: Using configuration type
1\n");
425                         request_region(0xCF8, 8, "PCI conf1");
426                         return &pci_direct_conf1;
427                 }
428                 outl (tmp, 0xCF8);
429         }
430
431         /*
432          * Check if configuration type 2 works.
433          */
434         if (pci_probe & PCI_PROBE_CONF2) {
435                 outb (0x00, 0xCFB);   <<<=========
436                 outb (0x00, 0xCF8);
437                 outb (0x00, 0xCFA);
438                 if (inb (0xCF8) == 0x00 && inb (0xCFA) == 0x00 &&
439                     pci_sanity_check(&pci_direct_conf2)) {
440                         __restore_flags(flags);
441                         printk(KERN_INFO "PCI: Using configuration type
2\n");
442                         request_region(0xCF8, 4, "PCI conf2");
443                         return &pci_direct_conf2;
444                 }
445         }
446
447         __restore_flags(flags);
448         return NULL;
449 }
450
451 #endif



_________________________________________________________________
MSN 8: advanced junk mail protection and 2 months FREE*. 
http://join.msn.com/?page=features/junkmail