Re: MSI failure on nForce 430 (WAS: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression))
On Fri, Feb 02, 2007 at 09:25:38AM -0800, Auke Kok wrote: > Adrian Bunk wrote: > > On Sat, Jan 20, 2007 at 02:34:37PM -0500, Adam Kropelin wrote: > >> (cc: list trimmed and thread moved to linux-pci) > >> > >> I have a PCI-E e1000 card that does not see interrupts on 2.6.20-rc5 > >> unless CONFIG_PCI_MSI is disabled. An e1000 maintainer indicated that > >> the PHY state is correct, it's just that the interrupt is not getting > >> thru to the kernel. Interestingly, on 2.6.19 PHY interrupts get thru ok > >> with MSI enabled (link status responds appropriately) but packet tx > >> fails with timeout errors, implying that perhaps MAC interrupts are not > >> arriving. > >> > >> I've attached the contents dmesg, 'lspci -vvv', and 'cat > >> /proc/interrupts' from 2.6.20-rc5. > >> > >> This is an nForce 430 based chipset on a Dell E521 which has had > >> interrupt routing issues before. Prior to 2.6.19 it had to be booted > >> with 'noapic' in order to come up at all. It also had USB lockup > >> problems until I applied the latest BIOS update (v1.1.4). So a BIOS > >> interrupt routing bug with MSI is not out of the question. > >> > >> I'm happy to gather more data or run tests... > > > > Was this regression fixed by Eric's patch that is included in -rc7? > > no, this is a different issue afaics. Eric's patch solves a msi vector leak > where MSI's were no longer recovered after all 256 of them were handed out. > The > issue here seems to be a very different regression (no vector at all or > vector > not setup correctly to begin with). > > I do suggest re-testing the issue with 2.6.20rc7, but it's unlikely it fixes > the > problem for Adam. Your thought is correct: 2.6.20-rc7 still fails. --Adam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MSI failure on nForce 430 (WAS: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression))
Adrian Bunk wrote: On Sat, Jan 20, 2007 at 02:34:37PM -0500, Adam Kropelin wrote: (cc: list trimmed and thread moved to linux-pci) I have a PCI-E e1000 card that does not see interrupts on 2.6.20-rc5 unless CONFIG_PCI_MSI is disabled. An e1000 maintainer indicated that the PHY state is correct, it's just that the interrupt is not getting thru to the kernel. Interestingly, on 2.6.19 PHY interrupts get thru ok with MSI enabled (link status responds appropriately) but packet tx fails with timeout errors, implying that perhaps MAC interrupts are not arriving. I've attached the contents dmesg, 'lspci -vvv', and 'cat /proc/interrupts' from 2.6.20-rc5. This is an nForce 430 based chipset on a Dell E521 which has had interrupt routing issues before. Prior to 2.6.19 it had to be booted with 'noapic' in order to come up at all. It also had USB lockup problems until I applied the latest BIOS update (v1.1.4). So a BIOS interrupt routing bug with MSI is not out of the question. I'm happy to gather more data or run tests... Was this regression fixed by Eric's patch that is included in -rc7? no, this is a different issue afaics. Eric's patch solves a msi vector leak where MSI's were no longer recovered after all 256 of them were handed out. The issue here seems to be a very different regression (no vector at all or vector not setup correctly to begin with). I do suggest re-testing the issue with 2.6.20rc7, but it's unlikely it fixes the problem for Adam. The same issue was reported 2/3 days ago by another user basically too (no interrupts at all arriving with MSI enabled). Cheers, Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MSI failure on nForce 430 (WAS: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression))
On Sat, Jan 20, 2007 at 02:34:37PM -0500, Adam Kropelin wrote: > (cc: list trimmed and thread moved to linux-pci) > > I have a PCI-E e1000 card that does not see interrupts on 2.6.20-rc5 > unless CONFIG_PCI_MSI is disabled. An e1000 maintainer indicated that > the PHY state is correct, it's just that the interrupt is not getting > thru to the kernel. Interestingly, on 2.6.19 PHY interrupts get thru ok > with MSI enabled (link status responds appropriately) but packet tx > fails with timeout errors, implying that perhaps MAC interrupts are not > arriving. > > I've attached the contents dmesg, 'lspci -vvv', and 'cat > /proc/interrupts' from 2.6.20-rc5. > > This is an nForce 430 based chipset on a Dell E521 which has had > interrupt routing issues before. Prior to 2.6.19 it had to be booted > with 'noapic' in order to come up at all. It also had USB lockup > problems until I applied the latest BIOS update (v1.1.4). So a BIOS > interrupt routing bug with MSI is not out of the question. > > I'm happy to gather more data or run tests... Was this regression fixed by Eric's patch that is included in -rc7? > --Adam cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MSI failure on nForce 430 (WAS: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression))
Adam Kropelin wrote: I've attached the contents dmesg, 'lspci -vvv', and 'cat /proc/interrupts' from 2.6.20-rc5. Actually attached this time. --Adam proc-irq-2.6.20-rc5 Description: Binary data dmesg-2.6.20-rc5 Description: Binary data lspci-2.6.20-rc5 Description: Binary data
MSI failure on nForce 430 (WAS: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression))
(cc: list trimmed and thread moved to linux-pci) I have a PCI-E e1000 card that does not see interrupts on 2.6.20-rc5 unless CONFIG_PCI_MSI is disabled. An e1000 maintainer indicated that the PHY state is correct, it's just that the interrupt is not getting thru to the kernel. Interestingly, on 2.6.19 PHY interrupts get thru ok with MSI enabled (link status responds appropriately) but packet tx fails with timeout errors, implying that perhaps MAC interrupts are not arriving. I've attached the contents dmesg, 'lspci -vvv', and 'cat /proc/interrupts' from 2.6.20-rc5. This is an nForce 430 based chipset on a Dell E521 which has had interrupt routing issues before. Prior to 2.6.19 it had to be booted with 'noapic' in order to come up at all. It also had USB lockup problems until I applied the latest BIOS update (v1.1.4). So a BIOS interrupt routing bug with MSI is not out of the question. I'm happy to gather more data or run tests... --Adam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression)
Adam Kropelin wrote: Auke Kok wrote: Adam Kropelin wrote: I haven't been able to test rc5-mm yet because it won't boot on this box. Applying git-e1000 directly to -rc4 or -rc5 results in a number of rejects that I'm not sure how to fix. Some are obvious, but the others I'm unsure of. that won't work. You either need to start with 2.6.20-rc5 (and pull the changes pending merge in netdev-2.6 from Jeff Garzik), I thought that's what I was doing when I applied git-e1000 to 2.6.20-rc5, but I guess not. or start with 2.6.20-rc4-mm1 and manually apply that patch I sent out on monday. A different combination of either of these two will not work, as they are completely different drivers. I'll try to work something out. can you include `ethtool ethX` output of the link down message and `ethtool -d ethX` as well? I'll need to dig up an 82572 and see what's up with that, I've not seen that problem before. ethtool output attached. that clearly shows that the PHY detected link up status and that all is well as far as the driver and NIC is concerned. This bug really needs to be moved to linux-pci where the folks who know interrupt handling best can handle it. Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression)
Auke Kok wrote: Adam Kropelin wrote: I haven't been able to test rc5-mm yet because it won't boot on this box. Applying git-e1000 directly to -rc4 or -rc5 results in a number of rejects that I'm not sure how to fix. Some are obvious, but the others I'm unsure of. that won't work. You either need to start with 2.6.20-rc5 (and pull the changes pending merge in netdev-2.6 from Jeff Garzik), I thought that's what I was doing when I applied git-e1000 to 2.6.20-rc5, but I guess not. or start with 2.6.20-rc4-mm1 and manually apply that patch I sent out on monday. A different combination of either of these two will not work, as they are completely different drivers. I'll try to work something out. can you include `ethtool ethX` output of the link down message and `ethtool -d ethX` as well? I'll need to dig up an 82572 and see what's up with that, I've not seen that problem before. ethtool output attached. More importantly, I suspect that *again* the issue is caused by interrupts not arriving or getting lost. Smells that way to me, too. Can you try running with MSI disabled in your kernel config? That fixes it! The link comes up and tx/rx works well. I get about 300 Mbps using default iperf settings with a nearby windows box. FYI the driver gives an interrupt to signal to the driver that link is up. no interrupt == no link detected. So that explains the symptom. Yep, makes sense. I've worked with a number of PHYs like that. --Adam ethtool-eth1 Description: Binary data ethtool-d-eth1 Description: Binary data
Re: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression)
Adam Kropelin wrote: Auke Kok wrote: Adam Kropelin wrote: I am experiencing the no-link issue on a 82572EI single port copper PCI-E card. I've only tried 2.6.20-rc5, so I cannot tell if this is a regression or not yet. Will test older kernel soon. Can provide details/logs if you want 'em. we've already established that Allen's issue is not due to the driver and caused by interrupts being mal-assigned on his system, possibly a pci subsystem bug. You also have a completely different board (82572EI instead of 82571EB), so I'd like to see the usual debugging info as well as hearing from you whether 2.6.19.any works correctly. On 2.6.19 the link status is working (follows cable plug/unplug), but no tx or rx packets get thru. Attempts to transmit occasionally result in tx timed out errors in dmesg, but I cannot seem to generate these at will. On 2.6.20-rc5, the link status does not work (link is always down), and as expected no tx or rx. No tx timed out errors this time, presumably because it thinks the link is down. Note that both the switch and the LEDs on the NIC indicate a good 1000 Mbps link. dmesg, 'cat /proc/interrupts', and 'lspci -vvv' attached for 2.6.20-rc5. The data from 2.6.19 is essentially the same. at least your interrupts look sane. I see you are using MSI, but no interrupts arrive at neither OS nor driver. On top of that I posted a patch to rc5-mm yesterday that fixes a few significant bugs in the rc5-mm driver, so please apply that patch too before trying, so we're not wasting our time finding old bugs ;) I haven't been able to test rc5-mm yet because it won't boot on this box. Applying git-e1000 directly to -rc4 or -rc5 results in a number of rejects that I'm not sure how to fix. Some are obvious, but the others I'm unsure of. that won't work. You either need to start with 2.6.20-rc5 (and pull the changes pending merge in netdev-2.6 from Jeff Garzik), or start with 2.6.20-rc4-mm1 and manually apply that patch I sent out on monday. A different combination of either of these two will not work, as they are completely different drivers. can you include `ethtool ethX` output of the link down message and `ethtool -d ethX` as well? I'll need to dig up an 82572 and see what's up with that, I've not seen that problem before. More importantly, I suspect that *again* the issue is caused by interrupts not arriving or getting lost. Can you try running with MSI disabled in your kernel config? FYI the driver gives an interrupt to signal to the driver that link is up. no interrupt == no link detected. So that explains the symptom. Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression)
Auke Kok wrote: Adam Kropelin wrote: I am experiencing the no-link issue on a 82572EI single port copper PCI-E card. I've only tried 2.6.20-rc5, so I cannot tell if this is a regression or not yet. Will test older kernel soon. Can provide details/logs if you want 'em. we've already established that Allen's issue is not due to the driver and caused by interrupts being mal-assigned on his system, possibly a pci subsystem bug. You also have a completely different board (82572EI instead of 82571EB), so I'd like to see the usual debugging info as well as hearing from you whether 2.6.19.any works correctly. On 2.6.19 the link status is working (follows cable plug/unplug), but no tx or rx packets get thru. Attempts to transmit occasionally result in tx timed out errors in dmesg, but I cannot seem to generate these at will. On 2.6.20-rc5, the link status does not work (link is always down), and as expected no tx or rx. No tx timed out errors this time, presumably because it thinks the link is down. Note that both the switch and the LEDs on the NIC indicate a good 1000 Mbps link. dmesg, 'cat /proc/interrupts', and 'lspci -vvv' attached for 2.6.20-rc5. The data from 2.6.19 is essentially the same. On top of that I posted a patch to rc5-mm yesterday that fixes a few significant bugs in the rc5-mm driver, so please apply that patch too before trying, so we're not wasting our time finding old bugs ;) I haven't been able to test rc5-mm yet because it won't boot on this box. Applying git-e1000 directly to -rc4 or -rc5 results in a number of rejects that I'm not sure how to fix. Some are obvious, but the others I'm unsure of. --Adam dmesg-2.6.20-rc5 Description: Binary data lspci-2.6.20-rc5 Description: Binary data proc-irq-2.6.20-rc5 Description: Binary data
Re: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression)
Adam Kropelin wrote: Allen Parker wrote: Allen Parker wrote: 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 I am experiencing the no-link issue on a 82572EI single port copper PCI-E card. I've only tried 2.6.20-rc5, so I cannot tell if this is a regression or not yet. Will test older kernel soon. Can provide details/logs if you want 'em. we've already established that Allen's issue is not due to the driver and caused by interrupts being mal-assigned on his system, possibly a pci subsystem bug. You also have a completely different board (82572EI instead of 82571EB), so I'd like to see the usual debugging info as well as hearing from you whether 2.6.19.any works correctly. On top of that I posted a patch to rc5-mm yesterday that fixes a few significant bugs in the rc5-mm driver, so please apply that patch too before trying, so we're not wasting our time finding old bugs ;) Cheers, Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression)
> Allen Parker wrote: >> Allen Parker wrote: >>> 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 I am experiencing the no-link issue on a 82572EI single port copper PCI-E card. I've only tried 2.6.20-rc5, so I cannot tell if this is a regression or not yet. Will test older kernel soon. Can provide details/logs if you want 'em. --Adam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression)
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 8129 8723 PCI-MSI-edge eth3 > 499: 0 42122 17135 PCI-MSI-edge eth2 > 500: 0 192751418326 PCI-MSI-edge eth1 > 501: 0 0 0 0 PCI-MSI-edge eth1 > 502: 0414 26 25227 PCI-MSI-edge eth1 > 503: 0 372641418695 PCI-MSI-edge eth0 > 504: 0 0 0139 PCI-MSI-edge eth0 > 505: 0 6714 22806 PCI-MSI-edge eth0 > NMI:275207225262 > LOC:3531851353182935318053531778 > 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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression)
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 8129 8723 PCI-MSI-edge eth3 499: 0 42122 17135 PCI-MSI-edge eth2 500: 0 192751418326 PCI-MSI-edge eth1 501: 0 0 0 0 PCI-MSI-edge eth1 502: 0414 26 25227 PCI-MSI-edge eth1 503: 0 372641418695 PCI-MSI-edge eth0 504: 0 0 0139 PCI-MSI-edge eth0 505: 0 6714 22806 PCI-MSI-edge eth0 NMI:275207225262 LOC:3531851353182935318053531778 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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression)
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. 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) 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression)
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. 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) 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
