I have a PCI-E pro/1000 MT Quad Port adapter, which works quite well
under 2.6.19.2 but fails to see link under 2.6.20-rc5. Earlier today I
reported this to [email protected], but thought I should get the
word out in case someone else is testing this kernel on this nic chipset.
Due to changes between 2.6.19.2 and 2.6.20, Intel driver 7.3.20 will not
compile for 2.6.20, nor will the 2.6.19.2 in-tree driver.
Error output:
CC [M] drivers/net/e1000/e1000_main.o
drivers/net/e1000/e1000_main.c:1132:45: error: macro "INIT_WORK" passed
3 arguments, but takes just 2
drivers/net/e1000/e1000_main.c: In function 'e1000_probe':
drivers/net/e1000/e1000_main.c:1131: error: 'INIT_WORK' undeclared
(first use in this function)
drivers/net/e1000/e1000_main.c:1131: error: (Each undeclared identifier
is reported only once
drivers/net/e1000/e1000_main.c:1131: error: for each function it appears
in.)
make[3]: *** [drivers/net/e1000/e1000_main.o] Error 1
lspci -nn output (quad port):
09:00.0 Ethernet controller [0200]: Intel Corporation 82571EB Gigabit
Ethernet Controller [8086:10a4] (rev 06)
09:00.1 Ethernet controller [0200]: Intel Corporation 82571EB Gigabit
Ethernet Controller [8086:10a4] (rev 06)
0a:00.0 Ethernet controller [0200]: Intel Corporation 82571EB Gigabit
Ethernet Controller [8086:10a4] (rev 06)
0a:00.1 Ethernet controller [0200]: Intel Corporation 82571EB Gigabit
Ethernet Controller [8086:10a4] (rev 06)
lspci -nn output (dual port):
07:00.0 Ethernet controller [0200]: Intel Corporation 82571EB Gigabit
Ethernet Controller [8086:105e] (rev 06)
07:00.1 Ethernet controller [0200]: Intel Corporation 82571EB Gigabit
Ethernet Controller [8086:105e] (rev 06)
From what I've been able to gather, other Intel Pro/1000 chipsets work
fine in 2.6.20-rc5. If the e1000 guys need any assistance testing, I'll
be more than happy to volunteer myself as a guinea pig for patches.
Allen Parker
Allen Parker wrote:
> I have a PCI-E pro/1000 MT Quad Port adapter, which works quite well
> under 2.6.19.2 but fails to see link under 2.6.20-rc5. Earlier today I
> reported this to [email protected], but thought I should get the
> word out in case someone else is testing this kernel on this nic chipset.
>
> Due to changes between 2.6.19.2 and 2.6.20, Intel driver 7.3.20 will not
> compile for 2.6.20, nor will the 2.6.19.2 in-tree driver.
>
<snip, worthless>
Affected chipset:
> lspci -nn output (quad port):
> 09:00.0 Ethernet controller [0200]: Intel Corporation 82571EB Gigabit
> Ethernet Controller [8086:10a4] (rev 06)
> lspci -nn output (dual port):
> 07:00.0 Ethernet controller [0200]: Intel Corporation 82571EB Gigabit
> Ethernet Controller [8086:105e] (rev 06)
<snip, readability>
> From what I've been able to gather, other Intel Pro/1000 chipsets work
> fine in 2.6.20-rc5. If the e1000 guys need any assistance testing, I'll
> be more than happy to volunteer myself as a guinea pig for patches.
I wasn't aware that I was supposed to post this as a regression, so
changed the subject, hoping that someone will pick this up and run with
it. Primary issue being that link is not seen on this chipset under
2.6.20-rc5 via in-tree e1000 driver, despite multiple cycles of ifconfig
$eth up && ethtool $eth | grep link && ifconfig $eth down. Tested on 2
machines with identical hardware.
Allen Parker
Allen Parker wrote:
> Allen Parker wrote:
>> I have a PCI-E pro/1000 MT Quad Port adapter, which works quite well
>> under 2.6.19.2 but fails to see link under 2.6.20-rc5. Earlier today I
>> reported this to [email protected], but thought I should get
>> the word out in case someone else is testing this kernel on this nic
>> chipset.
>>
>> Due to changes between 2.6.19.2 and 2.6.20, Intel driver 7.3.20 will
>> not compile for 2.6.20, nor will the 2.6.19.2 in-tree driver.
>>
> <snip, worthless>
> Affected chipset:
>> lspci -nn output (quad port):
>> 09:00.0 Ethernet controller [0200]: Intel Corporation 82571EB Gigabit
>> Ethernet Controller [8086:10a4] (rev 06)
>> lspci -nn output (dual port):
>> 07:00.0 Ethernet controller [0200]: Intel Corporation 82571EB Gigabit
>> Ethernet Controller [8086:105e] (rev 06)
> <snip, readability>
>
>> From what I've been able to gather, other Intel Pro/1000 chipsets
>> work fine in 2.6.20-rc5. If the e1000 guys need any assistance
>> testing, I'll be more than happy to volunteer myself as a guinea pig
>> for patches.
>
> I wasn't aware that I was supposed to post this as a regression, so
> changed the subject, hoping that someone will pick this up and run with
> it. Primary issue being that link is not seen on this chipset under
> 2.6.20-rc5 via in-tree e1000 driver, despite multiple cycles of ifconfig
> $eth up && ethtool $eth | grep link && ifconfig $eth down. Tested on 2
> machines with identical hardware.
I asked Allen to report this here. I'm working on the issue as we speak but for now I'll
treat the link issue as a known regression once I confirm it. If others have seen it
then I'd like to know ASAP of course ;)
Cheers,
Auke
On 1/16/07, Allen Parker <[email protected]> wrote:
> Allen Parker wrote:
> > I have a PCI-E pro/1000 MT Quad Port adapter, which works quite well
> > under 2.6.19.2 but fails to see link under 2.6.20-rc5. Earlier today I
> > reported this to [email protected], but thought I should get the
> > word out in case someone else is testing this kernel on this nic chipset.
Upon some further investigation with Allen, I got this info, and it
appears that his system is not freeing MSI irq's correctly.
from our discussion:
> Allen wrote:
>> Jesse Brandeburg wrote:
>> I believe you may have an interrupt delivery problem, due to kernel
>> changes. When you don't get interrupts delivered correctly, you may
>> not achieve link up.
>>
>> you can try disabling CONFIG_PCI_MSI in the kernel, as another
>> trouble shooting step. Also, what model motherboard/machine are you
>> using, and please check to make sure your BIOS is up to date.
>
> CONFIG_PCI_MSI seems to fix it as well, however, i'm not sure about
> possible performance implications with leaving it turned off.
>
> Tyan S2927G2NR w/ 2x Opteron 2210 bios rev 1.02 iirc
Also, here is an excerpt of his his proc/interrupts
Allen Parker wrote:
CPU0 CPU1 CPU2 CPU3
498: 1 8 129 8723 PCI-MSI-edge eth3
499: 0 42 122 17135 PCI-MSI-edge eth2
500: 0 19 275 1418326 PCI-MSI-edge eth1
501: 0 0 0 0 PCI-MSI-edge eth1
502: 0 414 26 25227 PCI-MSI-edge eth1
503: 0 37 264 1418695 PCI-MSI-edge eth0
504: 0 0 0 139 PCI-MSI-edge eth0
505: 0 6 714 22806 PCI-MSI-edge eth0
NMI: 275 207 225 262
LOC:3531851 3531829 3531805 3531778
ERR: 0
The disturbing bit is that on this Hypertransport to PCIe system, his
interrupts appear to be getting registered multiple times on different
IRQ numbers.
help?
added Linux-pci
Jesse Brandeburg wrote:
> On 1/16/07, Allen Parker <[email protected]> wrote:
>> Allen Parker wrote:
>>> I have a PCI-E pro/1000 MT Quad Port adapter, which works quite well
>>> under 2.6.19.2 but fails to see link under 2.6.20-rc5. Earlier
>>> today I reported this to [email protected], but thought I
>>> should get the word out in case someone else is testing this kernel
>>> on this nic chipset.
>
> Upon some further investigation with Allen, I got this info, and it
> appears that his system is not freeing MSI irq's correctly.
>
> from our discussion:
>> Allen wrote:
>>> Jesse Brandeburg wrote:
>>> I believe you may have an interrupt delivery problem, due to kernel
>>> changes. When you don't get interrupts delivered correctly, you may
>>> not achieve link up.
>>>
>>> you can try disabling CONFIG_PCI_MSI in the kernel, as another
>>> trouble shooting step. Also, what model motherboard/machine are you
>>> using, and please check to make sure your BIOS is up to date.
>>
>> CONFIG_PCI_MSI seems to fix it as well, however, i'm not sure about
>> possible performance implications with leaving it turned off.
>>
>> Tyan S2927G2NR w/ 2x Opteron 2210 bios rev 1.02 iirc
>
> Also, here is an excerpt of his his proc/interrupts
> Allen Parker wrote:
> CPU0 CPU1 CPU2 CPU3
> 498: 1 8 129 8723 PCI-MSI-edge eth3
> 499: 0 42 122 17135 PCI-MSI-edge eth2
> 500: 0 19 275 1418326 PCI-MSI-edge eth1
> 501: 0 0 0 0 PCI-MSI-edge eth1
> 502: 0 414 26 25227 PCI-MSI-edge eth1
> 503: 0 37 264 1418695 PCI-MSI-edge eth0
> 504: 0 0 0 139 PCI-MSI-edge eth0
> 505: 0 6 714 22806 PCI-MSI-edge eth0
> NMI: 275 207 225 262
> LOC:3531851 3531829 3531805 3531778
> ERR: 0
>
> The disturbing bit is that on this Hypertransport to PCIe system, his
> interrupts appear to be getting registered multiple times on different
> IRQ numbers.
>
> help?