Re: MSIX failure
On Fri 2010-09-10 (10:43), Jack Vogel wrote: No, not the add-on adapter, i have no trouble finding those, what I want to know about is the details about the system that has em0 LOM, only way to check on that is to have the whole enchilada :) Ah right. These are snippets from dmidecode, is this enough? Handle 0x, DMI type 4, 35 bytes Processor Information Socket Designation: LGA 1156 Type: Central Processor Family: Other Manufacturer: Intel(R) Corporation ID: E5 06 01 00 FF FB EB BF Version: Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz Voltage: 1.1 V External Clock: 133 MHz Max Speed: 4000 MHz Current Speed: 2668 MHz Status: Populated, Enabled Upgrade: Other L1 Cache Handle: 0x0004 L2 Cache Handle: 0x0003 L3 Cache Handle: 0x0001 Serial Number: Not Specified Asset Tag: Not Specified Part Number: Not Specified Handle 0x0007, DMI type 2, 20 bytes Base Board Information Manufacturer: Intel Corporation Product Name: DP55WB Version: AAE64798-206 Serial Number: AZWB005003A3 Asset Tag: Base Board Asset Tag Features: Board is a hosting board Board is replaceable Location In Chassis: Base Board Chassis Location Chassis Handle: 0x0008 Type: Unknown Contained Object Handles: 0 Handle 0x0010, DMI type 10, 6 bytes On Board Device Information Type: Ethernet Status: Enabled Description: Intel(R) 82578DC Gigabit Network Connection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
We don't deal with desktop systems that much in my group, it was pointed out by a coworker that the BIOS has settings that could disable MSI, please check out how yours is set. Jack On Mon, Sep 13, 2010 at 7:42 AM, Gareth de Vaux b...@lordcow.org wrote: On Fri 2010-09-10 (10:43), Jack Vogel wrote: No, not the add-on adapter, i have no trouble finding those, what I want to know about is the details about the system that has em0 LOM, only way to check on that is to have the whole enchilada :) Ah right. These are snippets from dmidecode, is this enough? Handle 0x, DMI type 4, 35 bytes Processor Information Socket Designation: LGA 1156 Type: Central Processor Family: Other Manufacturer: Intel(R) Corporation ID: E5 06 01 00 FF FB EB BF Version: Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz Voltage: 1.1 V External Clock: 133 MHz Max Speed: 4000 MHz Current Speed: 2668 MHz Status: Populated, Enabled Upgrade: Other L1 Cache Handle: 0x0004 L2 Cache Handle: 0x0003 L3 Cache Handle: 0x0001 Serial Number: Not Specified Asset Tag: Not Specified Part Number: Not Specified Handle 0x0007, DMI type 2, 20 bytes Base Board Information Manufacturer: Intel Corporation Product Name: DP55WB Version: AAE64798-206 Serial Number: AZWB005003A3 Asset Tag: Base Board Asset Tag Features: Board is a hosting board Board is replaceable Location In Chassis: Base Board Chassis Location Chassis Handle: 0x0008 Type: Unknown Contained Object Handles: 0 Handle 0x0010, DMI type 10, 6 bytes On Board Device Information Type: Ethernet Status: Enabled Description: Intel(R) 82578DC Gigabit Network Connection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
On Fri 2010-09-10 (10:41), Gareth de Vaux wrote: Gareth, set hw.pci.honor_msi_blacklist=0, you'll have to do that at boot btw. Ok, I'll have to get back to you in a day or 2 when I reboot. Done: $ sysctl -a | grep msi hw.bce.msi_enable: 1 hw.pci.honor_msi_blacklist: 0 hw.pci.enable_msix: 1 hw.pci.enable_msi: 1 I get the same MSIX failure message though. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
On Thu 2010-09-09 (17:00), Gareth de Vaux wrote: On Thu 2010-09-09 (16:54), Kurt Jaeger wrote: -c asks for pci device capabilities, which are read in /usr/src/usr.sbin/pciconf/pciconf.c:177 with O_RDWR Ah. I'll have to schedule a reboot then .. pciconf -lcv, onboard: e...@pci0:0:25:0:class=0x02 card=0x8086 chip=0x10f08086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 13[e0] = PCI Advanced Features: FLR TP add-on: e...@pci0:5:1:0: class=0x02 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
On Sun, Sep 12, 2010 at 1:15 AM, Gareth de Vaux b...@lordcow.org wrote: On Fri 2010-09-10 (10:41), Gareth de Vaux wrote: Gareth, set hw.pci.honor_msi_blacklist=0, you'll have to do that at boot btw. Ok, I'll have to get back to you in a day or 2 when I reboot. Done: $ sysctl -a | grep msi hw.bce.msi_enable: 1 hw.pci.honor_msi_blacklist: 0 hw.pci.enable_msix: 1 hw.pci.enable_msi: 1 I get the same MSIX failure message though. Ya, that's what I suspected, it just means the failure is not because your system is blacklisted. You still have not given me what I need to help: the exact details of the system, I don't need to see the pciconf of the NIC, I need to know about the motherboard/chipset its on. Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
John Baldwin j...@freebsd.org wrote: On Friday, September 10, 2010 2:55:15 am per...@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 b...@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. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
per...@pluto.rain.com wrote: John Baldwin j...@freebsd.org wrote: On Friday, September 10, 2010 2:55:15 am per...@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 b...@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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
Gareth de Vaux b...@lordcow.org wrote: On Thu 2010-09-09 (16:54), Kurt Jaeger wrote: -c asks for pci device capabilities, which are read in /usr/src/usr.sbin/pciconf/pciconf.c:177 with O_RDWR Ah. I'll have to schedule a reboot then .. or hack on pciconf.c to not request more permission than it needs. It is arguably a bug to open O_RDWR when only examining things. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
On Thu 2010-09-09 (13:48), Jack Vogel wrote: Gareth's email bouncing for anybody else or is it just me? Yes sorry I disabled this alias after picking up years of spam on the mailman archives. I assumed people would primarily reply to the list. I've re-enabled it for now. Gareth, set hw.pci.honor_msi_blacklist=0, you'll have to do that at boot btw. Ok, I'll have to get back to you in a day or 2 when I reboot. Tell me more exactly the make/model of the hardware so I might try to get my hands on one? I can't tell much more from here, the card came from the datacentre's reserve when I was fighting with the onboard. The larger lettering on the card itself was just 'Intel(R) PRO/1000 GT Desktop Adapter'. I didn't note down the smaller model-type numbers. Is this http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/058748.html not enough? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
On Fri 2010-09-10 (10:41), Gareth de Vaux wrote: http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/058748.html Just to reiterate - those are the specs of the PCI card that doesn't work. The PCI card doesn't come up with MSIX failures. The onboard has the MSIX failures but continues to work as you say. These are the comparative specs for the onboard: kernel: em0: Intel(R) PRO/1000 Network Connection 7.0.5 port 0x3040-0x305f mem 0xe320-0xe321,0xe322-0xe3220fff irq 10 at device 25.0 on pci0 kernel: em0: Setup MSIX failure kernel: em0: [FILTER] kernel: em0: Ethernet address: 00:27:0e:1e:5e:e3 $ ifconfig em0 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC ether 00:27:0e:1e:5e:e3 inet media: Ethernet autoselect (100baseTX full-duplex) status: active pciconf -lv: e...@pci0:0:25:0:class=0x02 card=0x8086 chip=0x10f08086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
On Friday, September 10, 2010 2:55:15 am per...@pluto.rain.com wrote: Gareth de Vaux b...@lordcow.org wrote: On Thu 2010-09-09 (16:54), Kurt Jaeger wrote: -c asks for pci device capabilities, which are read in /usr/src/usr.sbin/pciconf/pciconf.c:177 with O_RDWR Ah. I'll have to schedule a reboot then .. or hack on pciconf.c to not request more permission than it needs. 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. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
On Fri, Sep 10, 2010 at 1:41 AM, Gareth de Vaux b...@lordcow.org wrote: On Thu 2010-09-09 (13:48), Jack Vogel wrote: Gareth's email bouncing for anybody else or is it just me? Yes sorry I disabled this alias after picking up years of spam on the mailman archives. I assumed people would primarily reply to the list. I've re-enabled it for now. Gareth, set hw.pci.honor_msi_blacklist=0, you'll have to do that at boot btw. Ok, I'll have to get back to you in a day or 2 when I reboot. Tell me more exactly the make/model of the hardware so I might try to get my hands on one? I can't tell much more from here, the card came from the datacentre's reserve when I was fighting with the onboard. The larger lettering on the card itself was just 'Intel(R) PRO/1000 GT Desktop Adapter'. I didn't note down the smaller model-type numbers. Is this http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/058748.html not enough? No, not the add-on adapter, i have no trouble finding those, what I want to know about is the details about the system that has em0 LOM, only way to check on that is to have the whole enchilada :) Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
On Wed 2010-09-08 (09:41), Jack Vogel wrote: This is what'd I'd expect, the onboard is PCH chipset, support was not in 8.0, but as I said, in 8.1 (and hence stable/8) it is supported, and it should work. I've just paid the machine a visit and yes, MSIX fails on the onboard but the device still works. The PCI card however doesn't work, whereas it did when using 8.0-RELEASE. (There is occasional activity from tcpdump). I'm able to use the onboard so I can survive, but FYI, the PCI card output: kernel: em1: Intel(R) PRO/1000 Legacy Network Connection 1.0.1 port 0x1000-0x103f mem 0xe312-0xe313,0xe310-0xe311 irq 9 at device 1.0 on pci5 kernel: em1: [FILTER] kernel: em1: Ethernet address: 00:1b:21:5b:f2:18 (no MSIX failure here, or in 8.0-RELEASE) $ ifconfig em1 em1: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500 options=209bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC ether 00:1b:21:5b:f2:18 media: Ethernet autoselect status: no carrier pciconf -lv: e...@pci0:5:1:0: class=0x02 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' class = network subclass = ethernet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
On Thu, Sep 09, 2010 at 02:54:01PM +0200, Gareth de Vaux wrote: On Wed 2010-09-08 (09:41), Jack Vogel wrote: This is what'd I'd expect, the onboard is PCH chipset, support was not in 8.0, but as I said, in 8.1 (and hence stable/8) it is supported, and it should work. I've just paid the machine a visit and yes, MSIX fails on the onboard but the device still works. The PCI card however doesn't work, whereas it did when using 8.0-RELEASE. (There is occasional activity from tcpdump). I'm able to use the onboard so I can survive, but FYI, the PCI card output: kernel: em1: Intel(R) PRO/1000 Legacy Network Connection 1.0.1 port 0x1000-0x103f mem 0xe312-0xe313,0xe310-0xe311 irq 9 at device 1.0 on pci5 kernel: em1: [FILTER] kernel: em1: Ethernet address: 00:1b:21:5b:f2:18 (no MSIX failure here, or in 8.0-RELEASE) $ ifconfig em1 em1: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500 options=209bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC ether 00:1b:21:5b:f2:18 media: Ethernet autoselect status: no carrier pciconf -lv: e...@pci0:5:1:0: class=0x02 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' class = network subclass = ethernet Can you add the -c flag to your pciconf command? Thanks. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
On Thu 2010-09-09 (06:13), Jeremy Chadwick wrote: Can you add the -c flag to your pciconf command? Thanks. Forbidden? # pciconf -lvc pciconf: /dev/pci: Operation not permitted # pciconf -lc pciconf: /dev/pci: Operation not permitted # ls -l /dev/pci crw-r--r-- 1 root wheel0, 9 Sep 9 11:55 /dev/pci ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
On Thu, Sep 09, 2010 at 03:25:19PM +0200, Gareth de Vaux wrote: On Thu 2010-09-09 (06:13), Jeremy Chadwick wrote: Can you add the -c flag to your pciconf command? Thanks. Forbidden? # pciconf -lvc pciconf: /dev/pci: Operation not permitted # pciconf -lc pciconf: /dev/pci: Operation not permitted # ls -l /dev/pci crw-r--r-- 1 root wheel0, 9 Sep 9 11:55 /dev/pci You need to be root to use the -c flag. Despite your prompt, I don't think you're root. Reproduction: $ id uid=1000(jdc) gid=1000(users) groups=1000(users),0(wheel) $ pciconf -lv | wc -l 114 $ pciconf -lc pciconf: /dev/pci: Permission denied $ sudo -i box# id uid=0(root) gid=0(wheel) groups=0(wheel),5(operator) box# pciconf -lc | wc -l 73 -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
On Thu 2010-09-09 (07:02), Jeremy Chadwick wrote: You need to be root to use the -c flag. Despite your prompt, I don't think you're root. Reproduction: That was as root, # id uid=0(root) gid=0(wheel) groups=0(wheel),5(operator) # pciconf -lc pciconf: /dev/pci: Operation not permitted ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
On Thu, Sep 09, 2010 at 04:22:26PM +0200, Gareth de Vaux wrote: On Thu 2010-09-09 (07:02), Jeremy Chadwick wrote: You need to be root to use the -c flag. Despite your prompt, I don't think you're root. Reproduction: That was as root, # id uid=0(root) gid=0(wheel) groups=0(wheel),5(operator) # pciconf -lc pciconf: /dev/pci: Operation not permitted Is this within a jail or something else along those lines? I can't reproduce the problem otherwise. Frustrating! Someone else on the list might have ideas as to what could cause this. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
On Thu 2010-09-09 (07:24), Jeremy Chadwick wrote: Is this within a jail or something else along those lines? I can't reproduce the problem otherwise. Frustrating! Someone else on the list might have ideas as to what could cause this. Nope, this's a normal host. I've got securelevel on 1, but doubt that would affect this? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
Hi! Is this within a jail or something else along those lines? I can't reproduce the problem otherwise. Frustrating! Someone else on the list might have ideas as to what could cause this. Nope, this's a normal host. I've got securelevel on 1, but doubt that would affect this? I assume it affects it. http://www.freebsd.org/doc/en/books/faq/security.html#SECURELEVEL Basically, when the securelevel is positive, the kernel restricts certain tasks; not even the superuser (i.e., root) is allowed to do them. There: # Write to kernel memory via /dev/mem and /dev/kmem. So I assume it also restricts reading /dev/kmem ? -- p...@opsec.eu+49 171 310137210 years to go ! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
On Thu, Sep 9, 2010 at 4:22 PM, Gareth de Vaux b...@lordcow.org wrote: On Thu 2010-09-09 (07:02), Jeremy Chadwick wrote: You need to be root to use the -c flag. Despite your prompt, I don't think you're root. Reproduction: That was as root, # id uid=0(root) gid=0(wheel) groups=0(wheel),5(operator) # pciconf -lc pciconf: /dev/pci: Operation not permitted ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org perhaps you should lower your kernel securelevel? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
Hi! Is this within a jail or something else along those lines? I can't reproduce the problem otherwise. Frustrating! Someone else on the list might have ideas as to what could cause this. Nope, this's a normal host. I've got securelevel on 1, but doubt that would affect this? I assume it affects it. http://www.freebsd.org/doc/en/books/faq/security.html#SECURELEVEL Basically, when the securelevel is positive, the kernel restricts certain tasks; not even the superuser (i.e., root) is allowed to do them. There: # Write to kernel memory via /dev/mem and /dev/kmem. So I assume it also restricts reading /dev/kmem ? -c asks for pci device capabilities, which are read in /usr/src/usr.sbin/pciconf/pciconf.c:177 with O_RDWR I guess that's it. -- p...@opsec.eu+49 171 310137210 years to go ! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
Jeremy Chadwick wrote: On Thu, Sep 09, 2010 at 04:22:26PM +0200, Gareth de Vaux wrote: On Thu 2010-09-09 (07:02), Jeremy Chadwick wrote: You need to be root to use the -c flag. Despite your prompt, I don't think you're root. Reproduction: That was as root, # id uid=0(root) gid=0(wheel) groups=0(wheel),5(operator) # pciconf -lc pciconf: /dev/pci: Operation not permitted Is this within a jail or something else along those lines? I can't reproduce the problem otherwise. Frustrating! Someone else on the list might have ideas as to what could cause this. A kern.securelevel of 1 or higher would also cause this to happen. -Boris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
On Thu 2010-09-09 (16:54), Kurt Jaeger wrote: -c asks for pci device capabilities, which are read in /usr/src/usr.sbin/pciconf/pciconf.c:177 with O_RDWR Ah. I'll have to schedule a reboot then .. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
On Thu, Sep 9, 2010 at 7:33 AM, Kurt Jaeger p...@opsec.eu wrote: Hi! Is this within a jail or something else along those lines? I can't reproduce the problem otherwise. Frustrating! Someone else on the list might have ideas as to what could cause this. Nope, this's a normal host. I've got securelevel on 1, but doubt that would affect this? I assume it affects it. http://www.freebsd.org/doc/en/books/faq/security.html#SECURELEVEL Basically, when the securelevel is positive, the kernel restricts certain tasks; not even the superuser (i.e., root) is allowed to do them. There: # Write to kernel memory via /dev/mem and /dev/kmem. So I assume it also restricts reading /dev/kmem ? OH YUCK, another root isn't really root, so is it also possibly the reason for the MSIX failure?? Is this pile, er feature, on by default? Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
Hi! Basically, when the securelevel is positive, the kernel restricts certain tasks; not even the superuser (i.e., root) is allowed to do them. OH YUCK, another root isn't really root, so is it also possibly the reason for the MSIX failure?? Is this pile, er feature, on by default? No, not by default. -- p...@opsec.eu+49 171 310137210 years to go ! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
On Thu, Sep 9, 2010 at 11:37 AM, John Baldwin j...@freebsd.org wrote: On Thursday, September 09, 2010 12:41:07 pm Jack Vogel wrote: On Thu, Sep 9, 2010 at 7:33 AM, Kurt Jaeger p...@opsec.eu wrote: Hi! Is this within a jail or something else along those lines? I can't reproduce the problem otherwise. Frustrating! Someone else on the list might have ideas as to what could cause this. Nope, this's a normal host. I've got securelevel on 1, but doubt that would affect this? I assume it affects it. http://www.freebsd.org/doc/en/books/faq/security.html#SECURELEVEL Basically, when the securelevel is positive, the kernel restricts certain tasks; not even the superuser (i.e., root) is allowed to do them. There: # Write to kernel memory via /dev/mem and /dev/kmem. So I assume it also restricts reading /dev/kmem ? OH YUCK, another root isn't really root, so is it also possibly the reason for the MSIX failure?? Is this pile, er feature, on by default? securelevel does not affect any of the MSI/MSI-X bits. Well then there's something else funny going on with that hardware, as at least MSI should work with the chipset, I am not able to get that exact skew from what I am told. Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
Gareth's email bouncing for anybody else or is it just me? Gareth, set hw.pci.honor_msi_blacklist=0, you'll have to do that at boot btw. Tell me more exactly the make/model of the hardware so I might try to get my hands on one? Jack On Thu, Sep 9, 2010 at 1:20 PM, John Baldwin j...@freebsd.org wrote: On Thursday, September 09, 2010 3:04:27 pm Jack Vogel wrote: On Thu, Sep 9, 2010 at 11:37 AM, John Baldwin j...@freebsd.org wrote: On Thursday, September 09, 2010 12:41:07 pm Jack Vogel wrote: On Thu, Sep 9, 2010 at 7:33 AM, Kurt Jaeger p...@opsec.eu wrote: Hi! Is this within a jail or something else along those lines? I can't reproduce the problem otherwise. Frustrating! Someone else on the list might have ideas as to what could cause this. Nope, this's a normal host. I've got securelevel on 1, but doubt that would affect this? I assume it affects it. http://www.freebsd.org/doc/en/books/faq/security.html#SECURELEVEL Basically, when the securelevel is positive, the kernel restricts certain tasks; not even the superuser (i.e., root) is allowed to do them. There: # Write to kernel memory via /dev/mem and /dev/kmem. So I assume it also restricts reading /dev/kmem ? OH YUCK, another root isn't really root, so is it also possibly the reason for the MSIX failure?? Is this pile, er feature, on by default? securelevel does not affect any of the MSI/MSI-X bits. Well then there's something else funny going on with that hardware, as at least MSI should work with the chipset, I am not able to get that exact skew from what I am told. I think the first would be to disable the MSI blacklists via a tunable to see if that enables MSI. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
On Thursday, September 09, 2010 12:41:07 pm Jack Vogel wrote: On Thu, Sep 9, 2010 at 7:33 AM, Kurt Jaeger p...@opsec.eu wrote: Hi! Is this within a jail or something else along those lines? I can't reproduce the problem otherwise. Frustrating! Someone else on the list might have ideas as to what could cause this. Nope, this's a normal host. I've got securelevel on 1, but doubt that would affect this? I assume it affects it. http://www.freebsd.org/doc/en/books/faq/security.html#SECURELEVEL Basically, when the securelevel is positive, the kernel restricts certain tasks; not even the superuser (i.e., root) is allowed to do them. There: # Write to kernel memory via /dev/mem and /dev/kmem. So I assume it also restricts reading /dev/kmem ? OH YUCK, another root isn't really root, so is it also possibly the reason for the MSIX failure?? Is this pile, er feature, on by default? securelevel does not affect any of the MSI/MSI-X bits. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
On Thursday, September 09, 2010 3:04:27 pm Jack Vogel wrote: On Thu, Sep 9, 2010 at 11:37 AM, John Baldwin j...@freebsd.org wrote: On Thursday, September 09, 2010 12:41:07 pm Jack Vogel wrote: On Thu, Sep 9, 2010 at 7:33 AM, Kurt Jaeger p...@opsec.eu wrote: Hi! Is this within a jail or something else along those lines? I can't reproduce the problem otherwise. Frustrating! Someone else on the list might have ideas as to what could cause this. Nope, this's a normal host. I've got securelevel on 1, but doubt that would affect this? I assume it affects it. http://www.freebsd.org/doc/en/books/faq/security.html#SECURELEVEL Basically, when the securelevel is positive, the kernel restricts certain tasks; not even the superuser (i.e., root) is allowed to do them. There: # Write to kernel memory via /dev/mem and /dev/kmem. So I assume it also restricts reading /dev/kmem ? OH YUCK, another root isn't really root, so is it also possibly the reason for the MSIX failure?? Is this pile, er feature, on by default? securelevel does not affect any of the MSI/MSI-X bits. Well then there's something else funny going on with that hardware, as at least MSI should work with the chipset, I am not able to get that exact skew from what I am told. I think the first would be to disable the MSI blacklists via a tunable to see if that enables MSI. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
On Tue 2010-09-07 (10:00), Jack Vogel wrote: First off, this device was not supported in 8.0 REL, what were you running that last worked? Hey, I was running 8.0 REL and it worked. I installed the system from the 8.0 .iso, but the onboard card didn't work. I added the PCI card and it worked. Do you have MSI disabled on this system of yours, the reason for this message is that both MSIX and MSI setup failed, your device should succeed with MSI. I didn't do anything to disable it I think. $ sysctl -a | grep msi hw.bce.msi_enable: 1 hw.pci.honor_msi_blacklist: 1 hw.pci.enable_msix: 1 hw.pci.enable_msi: 1 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
On Tue 2010-09-07 (13:25), Jack Vogel wrote: I've looked at the code, this message was misleading, what really happens is that the driver fails to be able to setup either MSIX OR MSI, when this happens it will fall back and use a Legacy interrupt, so its non-fatal and the device should work anyway. The only real reason you should see this is a) you used sysctl and turned msi and msix off, or b) a real hardware problem in the chipset has caused the failure. All devices em drives (as opposed to lem) are PCI Express and so by definition they have MSI and MSIX available. Ok I think I got my cards mixed up - in my original mail em1 is the PCI card and em0 is the onboard, sorry. I guessed the numbering may not have been as expected while trying to fix the issue, but I might not have fully tested this at the time. So here's the situation after looking through older kernel logs: I installed 8.0-RELEASE, the onboard card didn't work - the kernel didn't even pick it up, and ifconfig only showed the lo0 device. I added the PCI Intel(R) PRO/1000 GT card (Gigabit Ethernet Controller (Copper) rev 5 (82541PI)) - this worked and came up as em0. Last week I moved to -STABLE, GENERIC kernel. The kernel now detects both cards, with the kernel messages in my original mail. Whether either works I'm not completely sure, I'll need to get to the machine physically and switch cables/cards/configurations first. I didn't turn off msi/msix with sysctl (except when debugging in my original mail). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
This is what'd I'd expect, the onboard is PCH chipset, support was not in 8.0, but as I said, in 8.1 (and hence stable/8) it is supported, and it should work. I do not know why you don't have MSI support, but it should still work with Legacy interrupts. Jack On Wed, Sep 8, 2010 at 2:40 AM, Gareth de Vaux b...@lordcow.org wrote: On Tue 2010-09-07 (13:25), Jack Vogel wrote: I've looked at the code, this message was misleading, what really happens is that the driver fails to be able to setup either MSIX OR MSI, when this happens it will fall back and use a Legacy interrupt, so its non-fatal and the device should work anyway. The only real reason you should see this is a) you used sysctl and turned msi and msix off, or b) a real hardware problem in the chipset has caused the failure. All devices em drives (as opposed to lem) are PCI Express and so by definition they have MSI and MSIX available. Ok I think I got my cards mixed up - in my original mail em1 is the PCI card and em0 is the onboard, sorry. I guessed the numbering may not have been as expected while trying to fix the issue, but I might not have fully tested this at the time. So here's the situation after looking through older kernel logs: I installed 8.0-RELEASE, the onboard card didn't work - the kernel didn't even pick it up, and ifconfig only showed the lo0 device. I added the PCI Intel(R) PRO/1000 GT card (Gigabit Ethernet Controller (Copper) rev 5 (82541PI)) - this worked and came up as em0. Last week I moved to -STABLE, GENERIC kernel. The kernel now detects both cards, with the kernel messages in my original mail. Whether either works I'm not completely sure, I'll need to get to the machine physically and switch cables/cards/configurations first. I didn't turn off msi/msix with sysctl (except when debugging in my original mail). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
Email to Gareth de Vaux is bouncing :( First off, this device was not supported in 8.0 REL, what were you running that last worked? Do you have MSI disabled on this system of yours, the reason for this message is that both MSIX and MSI setup failed, your device should succeed with MSI. Tell me more about the system please? Jack On Mon, Sep 6, 2010 at 11:36 AM, Jack Vogel jfvo...@gmail.com wrote: 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 b...@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 r...@x :/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 0xe320-0xe321,0xe322-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 0xe312-0xe313,0xe310-0xe311 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=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC ether 00:27:0e:1e:5e:e3 inet media: Ethernet autoselect status: no carrier pciconf -lv: e...@pci0:0:25:0:class=0x02 card=0x8086 chip=0x10f08086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet e...@pci0:5:1:0: class=0x02 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-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
I've looked at the code, this message was misleading, what really happens is that the driver fails to be able to setup either MSIX OR MSI, when this happens it will fall back and use a Legacy interrupt, so its non-fatal and the device should work anyway. The only real reason you should see this is a) you used sysctl and turned msi and msix off, or b) a real hardware problem in the chipset has caused the failure. All devices em drives (as opposed to lem) are PCI Express and so by definition they have MSI and MSIX available. I have just checked in a new delta to em in HEAD that corrects some other issues, and I have added a changed message that will be less confusing. Regards, Jack On Tue, Sep 7, 2010 at 10:00 AM, Jack Vogel jfvo...@gmail.com wrote: Email to Gareth de Vaux is bouncing :( First off, this device was not supported in 8.0 REL, what were you running that last worked? Do you have MSI disabled on this system of yours, the reason for this message is that both MSIX and MSI setup failed, your device should succeed with MSI. Tell me more about the system please? Jack On Mon, Sep 6, 2010 at 11:36 AM, Jack Vogel jfvo...@gmail.com wrote: 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 b...@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 r...@x :/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 0xe320-0xe321,0xe322-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 0xe312-0xe313,0xe310-0xe311 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=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC ether 00:27:0e:1e:5e:e3 inet media: Ethernet autoselect status: no carrier pciconf -lv: e...@pci0:0:25:0:class=0x02 card=0x8086 chip=0x10f08086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet e...@pci0:5:1:0: class=0x02 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-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MSIX failure
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 b...@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 r...@x :/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 0xe320-0xe321,0xe322-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 0xe312-0xe313,0xe310-0xe311 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=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC ether 00:27:0e:1e:5e:e3 inet media: Ethernet autoselect status: no carrier pciconf -lv: e...@pci0:0:25:0:class=0x02 card=0x8086 chip=0x10f08086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet e...@pci0:5:1:0: class=0x02 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-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
