Hi all, I moved from 8.0-RELEASE to last week's -STABLE:
$ uname -v
FreeBSD 8.1-STABLE #0: Thu Sep 2 16:38:02 SAST 2010
root@XXXXX:/usr/obj/usr/src/sys/GENERIC
and all seems well except my network card is unusable. On boot up:
em0: <Intel(R) PRO/1000 Network Connection 7.0.5> port 0x3040-0x305f mem
0xe3200000-0xe321ffff,0xe3220000-0xe3220fff irq 10 at device 25.0 on pci0
em0: Setup MSIX failure
em0: [FILTER]
em0: Ethernet address: 00:27:0e:1e:5e:e3
em1: <Intel(R) PRO/1000 Legacy Network Connection 1.0.1> port
0x1000-0x103f mem 0xe3120000-0xe313ffff,0xe3100000-0xe311ffff irq 9 at device
1.0 on pci5
em1: [FILTER]
em1: Ethernet address: 00:1b:21:5b:f2:18
em0 is a PCI 'Intel(R) PRO/1000 GT Desktop Adapter' which worked up
until now.
em1 is onboard which didn't work with 8.0-RELEASE either.
$ ifconfig em0
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC>
ether 00:27:0e:1e:5e:e3
inet XXXXXXXX
media: Ethernet autoselect
status: no carrier
pciconf -lv:
em0@pci0:0:25:0: class=0x020000 card=0x00008086 chip=0x10f08086 rev=0x05
hdr=0x00
vendor = 'Intel Corporation'
class = network
subclass = ethernet
em1@pci0:5:1:0: class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00
vendor = 'Intel Corporation'
device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)'
class = network
subclass = ethernet
(no device listing for em0)
Swapping the PCI card with a PCI-X version gives the same behaviour. Setting
hw.pci.enable_msix and hw.pci.enable_msi to 0 doesn't help in either case.
In the future make sure that you put E1000 or EM in the title otherwise I might miss it, fortunately I looked at this :) I'm on a holiday weekend, I will investigate this tomorrow. Jack On Mon, Sep 6, 2010 at 8:53 AM, Gareth de Vaux <bsd@lordcow.org> wrote:> Hi all, I moved from 8.0-RELEASE to last week's -STABLE: > > $ uname -v > FreeBSD 8.1-STABLE #0: Thu Sep 2 16:38:02 SAST 2010 root@XXXXX > :/usr/obj/usr/src/sys/GENERIC > > and all seems well except my network card is unusable. On boot up: > > em0: <Intel(R) PRO/1000 Network Connection 7.0.5> port 0x3040-0x305f mem > 0xe3200000-0xe321ffff,0xe3220000-0xe3220fff irq 10 at device 25.0 on pci0 > em0: Setup MSIX failure > em0: [FILTER] > em0: Ethernet address: 00:27:0e:1e:5e:e3 > > em1: <Intel(R) PRO/1000 Legacy Network Connection 1.0.1> port 0x1000-0x103f > mem 0xe3120000-0xe313ffff,0xe3100000-0xe311ffff irq 9 at device 1.0 on pci5 > em1: [FILTER] > em1: Ethernet address: 00:1b:21:5b:f2:18 > > > em0 is a PCI 'Intel(R) PRO/1000 GT Desktop Adapter' which worked up until > now. > em1 is onboard which didn't work with 8.0-RELEASE either. > > > $ ifconfig em0 > em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 > > options=219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC> > ether 00:27:0e:1e:5e:e3 > inet XXXXXXXX > media: Ethernet autoselect > status: no carrier > > > pciconf -lv: > > em0@pci0:0:25:0: class=0x020000 card=0x00008086 chip=0x10f08086 > rev=0x05 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > > em1@pci0:5:1:0: class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' > class = network > subclass = ethernet > > (no device listing for em0) > > Swapping the PCI card with a PCI-X version gives the same behaviour. > Setting > hw.pci.enable_msix and hw.pci.enable_msi to 0 doesn't help in either case. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >
perryh@pluto.rain.com wrote:> John Baldwin <jhb@freebsd.org> wrote: >> On Friday, September 10, 2010 2:55:15 am perryh@pluto.rain.com wrote: >>> ... >>> It is arguably a bug to open O_RDWR when only examining things. >> You have to have RDWR permission to issue the ioctl to read config >> registers which pciconf does when examining capabilities. > > So much for avoiding a reboot for <bsd@lordcow.org> (or whatever the > correct address is -- that one bounced), but now it is beginning to > look as if there may be a POLA violation at a lower level. Unless > there are devices out there whose state can be changed by merely > _reading_ (not writing) their configuration registers, I would not > expect to need RDWR permission just to read them.Umm, not all config registers are standardized and devices are free to define device-specific registers with device-specific behavior (many do). Given that, it is quite possible for a device to implement a register that takes action when read (e.g. resets to 0 or clears status bits, etc.). pciconf -l itself does not require RDWR permissions, only -c which does a good bit more work. -- John Baldwin