Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Nov 1996 21:02:10 +0100
From:      se@zpr.uni-koeln.de (Stefan Esser)
To:        durian@plutotech.com (Mike Durian)
Cc:        se@zpr.uni-koeln.de (Stefan Esser), freebsd-hackers@freebsd.org
Subject:   Re: small bugs in pci code
Message-ID:  <199611122003.VAA24764@x14.mi.uni-koeln.de>
In-Reply-To: <199611112241.PAA04235@pluto.plutotech.com>; from Mike Durian on Nov 11, 1996 15:41:11 -0700
References:  <199611112241.PAA04235@pluto.plutotech.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Mike Durian writes:
> On Mon, 11 Nov 1996 23:04:38 +0100, se@zpr.uni-koeln.de (Stefan Esser) wrote:
> >
> >Well, the PCI probe in your boot message logs looks different
> >from everything I've seen before :-)
> 
>   We've certainly made some inhouse changes, but not much to the generic
> pci code.  You can ignore all those strange ISA devices at the end.
> They're for some of our custom devices, and aren't even found on this
> machine (despite some of the false positives).  This output is from
> /var/log/messages, not dmesg(8).
> 
> >Please boot the same kernel (with your debug printf()s) again,
> >but this time with the "-v" option at the "Boot: " prompt.
> 
>   Here you go.  It looks like the mistaken i/o maps are from expansion
> ROM maps.  I still don't know about the DEC thing.

Thanks! And I think I found something interesting ...

Could you please let me know the value of PCI_MAP_REG_END 
that is defined in your version of /sys/pci/pcireg.h ?

(It should be 0x28, in order to make the following for loop
do the right thing:

	for (reg=PCI_MAP_REG_START;reg<PCI_MAP_REG_END;reg+=4)
)

> Nov 11 15:28:15 shane /kernel: ahc0 <Adaptec 2940 Ultra SCSI host adapter> rev 0 int a irq 11 on pci0:20
> Nov 11 15:28:15 shane /kernel: 	vendor = 0x9004, device = 0x8178
> Nov 11 15:28:16 shane /kernel: map = 0xfc01, data = 0xffffff01
> Nov 11 15:28:16 shane /kernel: case 1,5: i/o addr = 0xfc00, size = 0x100
> Nov 11 15:28:16 shane /kernel: 	mapreg[10] type=1 addr=0000fc00 size=0100.
> Nov 11 15:28:16 shane /kernel: map = 0xffbdf000, data = 0xfffff000
> Nov 11 15:28:16 shane /kernel: case 0,2,4: i/o addr = 0xffbdf000, size = 0x1000
> Nov 11 15:28:17 shane /kernel: 	mapreg[14] type=0 addr=ffbdf000 size=1000.

Everything is fine so far ...

> Nov 11 15:28:17 shane /kernel: map = 0xffbc0000, data = 0xffff0001
> Nov 11 15:28:17 shane /kernel: case 1,5: i/o addr = 0xffbc0000, size = 0x10000
> Nov 11 15:28:17 shane /kernel: 	mapreg[30] type=0 addr=ffbc0000 size=10000.

Hmmm, what's that ?
A map register at 0x30 in config space ???

> Nov 11 15:28:17 shane /kernel: 	reg16: ioaddr=0xfc00 size=0x100
> Nov 11 15:28:17 shane /kernel: 	reg48: virtual=0xf4951000 physical=0xffbc0000 size=0x10000
> Nov 11 15:28:18 shane /kernel: rom_reg=ffbc0001

Yes, it is a ROM, and the LSB is an enable ...
And it is NOT allowed to be enabled while the adapter is used,
or bad things may happen!

> Nov 11 15:28:22 shane /kernel: map = 0xffbe0000, data = 0xffff0001
> Nov 11 15:28:22 shane /kernel: case 1,5: i/o addr = 0xffbe0000, size = 0x10000
> Nov 11 15:28:22 shane /kernel: 	mapreg[30] type=0 addr=ffbe0000 size=10000.
> Nov 11 15:28:22 shane /kernel: de0 <Digital DC21140A Fast Ethernet> rev 32 int a irq 15 on pci0:17
> Nov 11 15:28:23 shane /kernel: 	vendor = 0x1011, device = 0x0009
> Nov 11 15:28:23 shane /kernel: map = 0xf881, data = 0xffffff81
> Nov 11 15:28:23 shane /kernel: case 1,5: i/o addr = 0xf880, size = 0x80
> Nov 11 15:28:23 shane /kernel: 	mapreg[10] type=1 addr=0000f880 size=0080.
> Nov 11 15:28:23 shane /kernel: map = 0xffbdef80, data = 0xffffff80
> Nov 11 15:28:23 shane /kernel: case 0,2,4: i/o addr = 0xffbdef80, size = 0x80
> Nov 11 15:28:23 shane /kernel: 	mapreg[14] type=0 addr=ffbdef80 size=0080.
> Nov 11 15:28:23 shane /kernel: map = 0x500a1011, data = 0x500a1011
> Nov 11 15:28:23 shane /kernel: case 1,5: i/o addr = 0x500a1010, size = 0x10
> Nov 11 15:28:23 shane /kernel: 	mapreg[2c] type=1 addr=500a1010 size=0010.

Hmmm, that one is interesting, too: This is the subvendor data 
register, and your card is the first one I see has that register 
implemented and set to a value not equal 0.

> Nov 11 15:28:24 shane /kernel: map = 0xffb40000, data = 0xfffc0001
> Nov 11 15:28:24 shane /kernel: case 1,5: i/o addr = 0xffb40000, size = 0x40000
> Nov 11 15:28:24 shane /kernel: 	mapreg[30] type=0 addr=ffb40000 size=40000.
> Nov 11 15:28:24 shane /kernel: 	reg16: ioaddr=0xf880 size=0x80

Ok, the rest just repeated, what we already know:

On your system, the probe for PCI map registers (which should be
limited to the range 0x10 to 0x24 (+3)) does not stop when it has
completed looking at the defined registers. And it does bad things,
when it walks over all the higher numbered registers and writes a
0xffffffff probe value into them !

Please check why this happens on your system. I can't reprocuce it 
here ...

Regards, STefan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611122003.VAA24764>