On Feb 4, 2008, at 6:19 PM, David Young wrote:

> On Mon, Feb 04, 2008 at 02:01:38PM +0100, Julio M. Merino Vidal wrote:
>> On Jan 14, 2008, at 7:44 PM, David Young wrote:
>>
>>>
>>> Module Name:	src
>>> Committed By:	dyoung
>>> Date:		Mon Jan 14 18:44:18 UTC 2008
>>>
>>> Modified Files:
>>> 	src/sys/arch/x86/pci: pci_machdep.c
>>>
>>> Log Message:
>>> KASSERT() that reads/writes from/to PCI configuration space are
>>> aligned on 32-bit boundaries.
>>
>> This breaks the mpt(4) driver and does not let NetBSD/amd64 boot
>> successfully in VMware Fusion.  The machine seems to emulate a
>> 53C1030 chip, and sys/dev/pci/mpt_pci.c has:
>>
>> 	if ((PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_SYMBIOS_1030) &&
>> 	    (PCI_REVISION(pa->pa_class) < 0x08)) {
>> 		aprint_normal("%s: applying 1030 quirk\n",
>> 		    mpt->sc_dev.dv_xname);
>> 		reg = pci_conf_read(pa->pa_pc, pa->pa_tag, 0x6a);
>> 		reg &= 0x8f;
>> 		pci_conf_write(pa->pa_pc, pa->pa_tag, 0x6a, reg);
>> 	}
>>
>> Note the 0x6a register value in there, which will trigger the
>> assertion you added.  I've been looking around to see if that value
>> is correct, but the only thing I found is the Linux code which does
>> the same as us (maybe we borrowed the fix from there in the first
>> place, or the other way around).
>>
>> Any idea on how to resolve this?
>
> There are two ways to resolve it.  You can delete that code, since  
> both
> the read and the write probably failed.  Or, you can read 0x68, apply
> mask 0x008f0000, and write back to 0x68, which seems to be intended.

Hm.  0xbf0000 or 0xbfffff?  The fix joerg@ committed used the latter  
mask.