Wow! A hole in linuxbios PCI mastery setup?

ollie lho ollie at sis.com.tw
Mon Jan 13 21:25:00 CET 2003


On Tue, 2003-01-14 at 09:32, Kevin Hester wrote:
> Hi all,
> 
> I think I've noticed a general linux-BIOS problem: Some PCI devices are not 
> being enabled for bus mastery!  Let me more clearly explain the context:
> 
> 1) According to my handy PCI book: All bus master capable PCI devices must 
> implement bit 2 of the command register.
> 2) Most devices that implement this bit power up default to 1.  This is good, 
> because linuxbios has not been setting this bit to 1.
> 3) A user reported a problem with a 802.11b card, and upon investigation I 
> discovered the chip used on this card does not default to a 1 for bus master 
> enable.  (See attached lspci output)
> 

According to PCI Spec Rev. 2.2:
	Bit 2: Controls a device's ability to act as a master on the PCI 	bus.
A value of 0 diable the device from generating PCI accesses
	A value of 1 allows the device to behave as a bus master. State
	after RST# is 0.

So, if bit 2 of a device has power up default value of 1, it is 
implemented incorrectly.

> After some testing, I realized that the same card on a non LinuxBIOS based 
> machine works correctly - i.e. by the time the kernel is up I see that this 
> bus master enable bit is 1.  I know that the Award BIOS on this second 
> machine must have set this bus master enable bit - because the kernel and 
> drivers are identical.  I verified this by dumping the appropriate config 
> registers early on in kernel start-up.
> 

It is a bug of the the device driver. Take a look at other well behaved
drivers (like sis900.c). The driver have to call pci_set_master by
itself during the driver init phase.

> My theory is that the Award BIOS is doing something that we are not: During 
> the IO/Mem space assignment process it is setting the bus master bit for most 
> devices.  By "most devices" I mean any device that is not behind a bridge 
> that inhibits bus mastery.  My PCI Sys Arch book (by Shanley and Anderson) 
> says that some crummy bridges may not support bus mastery (i.e. they have a 
> bit 2 of the command register that always reads as zero).  If a device is 
> behind a bridge that does not support mastery, it must have its mastery bit 
> cleared.
> 

If the bridge can not forward bus master cycle, there is virtually no 
way for the bus master devices behind it to work properly. Those devices
does not have both "pio" and "dma" modes generally.

> Does anyone have a copy of the $$$ PCI architecture spec so they can check 
> this?  My PCI System Architecture book is vague on the topic.
> 

The spec is vague on this too. 

-- 
ollie lho <ollie at sis.com.tw>




More information about the coreboot mailing list