2006-01-05 00:36:56

by Krzysztof Baranowski

[permalink] [raw]
Subject: PCI DEVICE ID PROBLEM and Intel Intergrated eth card - a bios bug (?)

Hi

Im using a PC BOX with Intel P4 HT processor on Gigabyte
GA-8KNXP Rev 2.x) which features Integrated Intel? PRO/1000
CT Network Card. All worked fine on both Linux & Win.
However I recently upgraded BIOS on this MB to the latest
version FK from (not sure now) FH or FJ version (reference
link below).

http://tw.giga-byte.com/Motherboard/Support/BIOS/BIOS_GA-8KNXP%20(Rev%202.x)_More.htm

After the upgrade my network card disappeared from both Linux and Win.

After short investigation I noticed one strange incosistency. Under
the new BIOS the PCI device is reported as PCI VENDOR ID 1459 (
which is gigabyte) DEV_ID 1019. However Windows driver for this
card (the lates from both intel and gigabyte) is looking for
VENDOR_ID 8086 (intel).

I havent booted to Linux yet, just dicovered the thing, but
after looking through the source of Linux E1000 driver in
e1000_main.c in struct pci_device_id is only looking for
Intel vendor device 8086, so the problem is still valid
I guess.

Please Cc when replying as I dont subscribe the list.

Best regards
Kris



2006-01-05 02:56:32

by Jesse Brandeburg

[permalink] [raw]
Subject: Re: PCI DEVICE ID PROBLEM and Intel Intergrated eth card - a bios bug (?)

On 1/4/06, Krzysztof Baranowski <[email protected]> wrote:
<snip>
> After the upgrade my network card disappeared from both Linux and Win.
>
> After short investigation I noticed one strange incosistency. Under
> the new BIOS the PCI device is reported as PCI VENDOR ID 1459 (
> which is gigabyte) DEV_ID 1019. However Windows driver for this
> card (the lates from both intel and gigabyte) is looking for
> VENDOR_ID 8086 (intel).

IMO, gigabyte should not have changed the vendor id. Effectively
they've said they will be the only ones supporting this hardware (not
intel). Generally subvendor and subdevice ids should be the only
thing changed by OEMs. Since it was changed by a bios upgrade i bet
its a bios bug and should be reported to gigabyte.

Until then you can hack your local kernel to get around it, but the
e1000 driver probably shouldn't change to support this device ID.

also, this is LKML and mentioning windows is just flame bait. :-)

jesse