RE: SubVendorID, take 2

[Pierre-Yves Santerre <pierreys@MICROSOFT.com>]

Sorry for the confusion. Wherever I used SubVendorId, I meant
SubSystemId (ie the full DWORD at 0x2C). Revision does refer to the BYTE
at 0x8.

> -----Original Message-----
> From:	Eric Rehm [SMTP:eric@equator.com]
> Sent:	Thursday, May 29, 1997 6:36 AM
> To:	Pierre-Yves Santerre; 'PCI SIG List'
> Subject:	RE: SubVendorID, take 2
> 
> Pierre-Yves,
> 
> Please claify, since the message below and other MS docs (e.g., 
> http://www.microsoft.com/hwdev/busbios/idpnp.htm) are unclear.
> 
> * When you say that "SubVendorId" is part of the devnode ID in
> Memphis, 
> do you mean that you use:
> 
> 1) The entire DWORD config register at offset 0x2C?
>    This implies you use *both* the SubsystemVendorId (WORD @ 0x2C) and
> 
>    SubSystemId (WORD @ offset 0x2E).
> 
> ...OR...
> 
> 2) Just the WORD config register SubsystemVendorID at offset 0x2C?
>    This implies that you IGNORE the WORD value in SubsystemID at
> offset 0x2E).
> 
> The reason I'm confused is that this portion of the devnode ID has
> eight 
> HEX digits in the Memphis registry, implying that both WORD regsters
> (0x2C, 0x2E) 
> are used:
> 
> 		SUBSYS_00000000
> 
> * With respect to "Revision", do you mean the BYTE configuration
> register at offset 0x08?
> 
> /eric rehm
> Equator Technologies, Inc.
> Seattle, WA
> eric@equator.com
> 
> 
> ----------
> From: 	Pierre-Yves Santerre
> Sent: 	Tuesday, May 27, 1997 7:15 PM
> To: 	Mailing List Recipients
> Subject: 	SubVendorID, take 2
> 
> In the next version of Windows 95 (aka memphis), we now use both
> SubVendorId and revision has part of the devnode ID name. This is so
> that if the user remove a card made by ABC and replace it (in the same
> slot) with a card by DEF, both using XYZ chipset, we do notice the
> swap.
> We wouldn't in windows 95 even with SubVenDorId, as it was just use
> for
> the driver selection and device name, not for the instance creation.
> 
> However, we are seeing a number of PCI cards having a writeable
> SubVendorID and being written by the BIOS of those cards. This create
> a
> severe problem in memphis:
> 
> A secondary video card is normally not posted by BIOS.
> We read the SubVendorId to create the devnode: at this point it is 0.
> We realize the device is new, so we wait until GUI and start the
> installation process.
> We search the INFs (and prompt for floppy) based on hardware IDs that
> have a 0 SubVendorId. So we install driver based on just the
> VenID/DevId/Rev.
> The driver tells VDD whether mode switch requires int 10h or not.
> If the driver require int 10h, we do some magic to enable the card and
> post the ROM in V86 mode.
> 	that ROM then populate the SubVendorId, about a minute too
> late...
> 	On a subsequent reenumeration (user hit refresh in device
> manager, machine docks/undock/suspend, user install a printer, etc)
> CONFIGMG gets told to hard remove
> PCI\VEN_{XYZ}&DEV_{XYZ'}&SUBSYS_000000000&REV_{XYZ"}\... and create a
> brand spanking new devnode with ID
> PCI\VEN_{XYZ}&DEV_{XYZ'}&SUBSYS_{DEF}&REV_{XYZ"}\... That second
> devnode
> gets installed, most likely surprising the user in the process, and
> from
> then on, when the machine boot we load one instance of the driver and
> replace it with another instance when reenumeration of the PCI bus
> occur.This leads to many problems.
> 
> The solution for memphis is to have a list of chipsets that exhibit
> this
> behavior (SubVendorId being written by ROM post code). For these
> cards,
> I will make an INF entry to override the use of SubVendorId,
> considering
> it to always be 0. I encourage you to send hardware to Nick Dimmitt so
> that we can test cards with this behavior.
> 
> Please reply to me with the Vendor ID/Device ID of cards that have the
> SubVendorId being written by ROM post code, so that I can create this
> list.
> 
> Pierre-Yves Santerre
> Win 9x PnP Dude
> 
> Nick Dimmitt
> Building 27 South, #3080
> 1 Microsoft Way,
> Redmond, WA
> 98052-6399
>  
> 
> 
> 
›$