Re: network freeze with nforce-A939 integrated rhine card
On Fri, 12 May 2006, David Lang wrote: On Fri, 12 May 2006, Roger Luethi wrote: On Thu, 11 May 2006 22:59:44 -0700, David Lang wrote: I haven't had time to go back and find where is started (my prior kernel was 2.6.15-rc7), but with 2.6.17-rc1/2/3/4 I've been running into a problem where when transfering large amounts of data (trying to ftp a TB where is started sounds as if it used to work at some point. In your second posting, however, you note that the problem goes back at least to 2.6.13. So are there any kernels known not to exhibit the problem you described? when I posted this origionally I thought it was new in 2.6.17-rc, however since my testing with older kernels hasn't found me a working one yet I suspect that other factors have been involved with makeing it work. these failures have been on multi-gig files ftp'd from the raid array on my machine to the raid array on the replacement machine. In the past I've sucessfully transfered similar sized files to/from my tivo (slow network), my laptop (slow drive), and smaller sets of files to single drives on other systems (7200rpm drives, but not to arrays). as I type this I'm starting a test going from a single drive on this machine to the raid array on the remote machine to transfer ~84G of data. My suspicion is that this is going to work. I just confirmed this, I was able to transfer 84G with no trouble starting from /dev/hdb, but starting from /dev/md0 the nic hung in less then 3G a good boot logs eth0: VIA Rhine II at 0xe8121000, 00:11:5b:f4:14:a3, IRQ 17. eth0: MII PHY found at address 1, status 0x7869 advertising 05e1 Link cde1. [EMAIL PROTECTED]:~# ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: d Current message level: 0x0001 (1) Link detected: yes David Lang - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: network freeze with nforce-A939 integrated rhine card
On Sat, 13 May 2006, David Lang wrote: On Fri, 12 May 2006, David Lang wrote: On Fri, 12 May 2006, Roger Luethi wrote: On Thu, 11 May 2006 22:59:44 -0700, David Lang wrote: I just confirmed this, I was able to transfer 84G with no trouble starting from /dev/hdb, but starting from /dev/md0 the nic hung in less then 3G a good boot logs eth0: VIA Rhine II at 0xe8121000, 00:11:5b:f4:14:a3, IRQ 17. eth0: MII PHY found at address 1, status 0x7869 advertising 05e1 Link cde1. [EMAIL PROTECTED]:~# ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: d Current message level: 0x0001 (1) Link detected: yes and here's what I get when it's hung from syslog when it hangs May 13 01:58:17 david kernel: attempt to access beyond end of device May 13 01:58:17 david kernel: md0: rw=0, want=8708129352, limit=2188035584 May 13 01:58:17 david kernel: attempt to access beyond end of device May 13 01:58:17 david kernel: md0: rw=0, want=7768925008, limit=2188035584 May 13 02:13:50 david ntpd[2589]: time reset +0.699871 s May 13 02:16:51 david kernel: eth0: link down from ethtool Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Advertised auto-negotiation: Yes Speed: 10Mb/s Duplex: Half Port: MII PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: d Current message level: 0x0001 (1) Link detected: no from the boot with it hung. eth0: VIA Rhine II at 0xe8121000, 00:11:5b:f4:14:a3, IRQ 17. eth0: MII PHY found at address 1, status 0x7849 advertising 05e1 Link . David Lang - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
network freeze with nforce-A939 integrated rhine card
I haven't had time to go back and find where is started (my prior kernel was 2.6.15-rc7), but with 2.6.17-rc1/2/3/4 I've been running into a problem where when transfering large amounts of data (trying to ftp a TB or so of data off of the box to my new server it will run for a while (as little as 1G, as much as 45G) and then the network card will shut down. when I say shut down I mean that it looses link and requires powering down the box (hard power down, not just power off from the front panel), disabling the network card in the BIOS, booting (as far as lilo is enough), powering down again, enabling the card and booting again. there is no indication of trouble before the halt (it's transfering at full speed), the only think in the log is May 11 22:23:57 david kernel: eth0: link down May 11 22:24:00 david kernel: eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1 May 11 22:24:22 david kernel: eth0: link down if I don't do the disable/enable in the bios cycle and just power cycle the system the card does not initialize properly (ethtool reports autonegotiation disabled, 10Mb. will generate an 'unsupported' error if I try to enable the card) the system is x86_64 64 bit kernel with 32 bit userspace lspci report [EMAIL PROTECTED]:~$ /sbin/lspci 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0204 00:00.1 Host bridge: VIA Technologies, Inc.: Unknown device 1204 00:00.2 Host bridge: VIA Technologies, Inc.: Unknown device 2204 00:00.3 Host bridge: VIA Technologies, Inc.: Unknown device 3204 00:00.4 Host bridge: VIA Technologies, Inc.: Unknown device 4204 00:00.7 Host bridge: VIA Technologies, Inc.: Unknown device 7204 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800 South] 00:08.0 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07) 00:08.1 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07) 00:0a.0 Ethernet controller: Olicom OC-2326 (rev 01) 00:0f.0 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C/VT8235 PIPC Bus Master IDE (rev 06) 00:10.0 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 81) 00:10.1 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 81) 00:10.2 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 81) 00:10.3 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 81) 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [K8T800 South] 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 78) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (rev 01) config is attached David Lang config.gz Description: Binary data
Re: network freeze with nforce-A939 integrated rhine card
On Thu, 11 May 2006 22:59:44 -0700, David Lang wrote: I haven't had time to go back and find where is started (my prior kernel was 2.6.15-rc7), but with 2.6.17-rc1/2/3/4 I've been running into a problem where when transfering large amounts of data (trying to ftp a TB where is started sounds as if it used to work at some point. In your second posting, however, you note that the problem goes back at least to 2.6.13. So are there any kernels known not to exhibit the problem you described? when I say shut down I mean that it looses link and requires powering down the box (hard power down, not just power off from the front panel), disabling the network card in the BIOS, booting (as far as lilo is enough), powering down again, enabling the card and booting again. So there are two problem areas: 1) the chip hangs itself without the driver noticing and 2) the BIOS fails to bring the chip back to life afterwards. there is no indication of trouble before the halt (it's transfering at full speed), the only think in the log is May 11 22:23:57 david kernel: eth0: link down May 11 22:24:00 david kernel: eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1 May 11 22:24:22 david kernel: eth0: link down if I don't do the disable/enable in the bios cycle and just power cycle the system the card does not initialize properly (ethtool reports autonegotiation disabled, 10Mb. will generate an 'unsupported' error if I try to enable the card) Any difference in the kernel log when booting with (or ethtooling) a comatose chip? [EMAIL PROTECTED]:~$ /sbin/lspci 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0204 00:00.1 Host bridge: VIA Technologies, Inc.: Unknown device 1204 00:00.2 Host bridge: VIA Technologies, Inc.: Unknown device 2204 00:00.3 Host bridge: VIA Technologies, Inc.: Unknown device 3204 00:00.4 Host bridge: VIA Technologies, Inc.: Unknown device 4204 00:00.7 Host bridge: VIA Technologies, Inc.: Unknown device 7204 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800 South] 00:08.0 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07) 00:08.1 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07) 00:0a.0 Ethernet controller: Olicom OC-2326 (rev 01) 00:0f.0 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C/VT8235 PIPC Bus Master IDE (rev 06) 00:10.0 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 81) 00:10.1 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 81) 00:10.2 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 81) 00:10.3 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 81) 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [K8T800 South] 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 78) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (rev 01) Odd. This doesn't look at all like the list I'd expect from an nforce-A939. I thought Nvidia devices featured rather prominently in the device lists of nforce-based boards!? Roger - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: network freeze with nforce-A939 integrated rhine card
On Fri, 12 May 2006, Roger Luethi wrote: On Thu, 11 May 2006 22:59:44 -0700, David Lang wrote: I haven't had time to go back and find where is started (my prior kernel was 2.6.15-rc7), but with 2.6.17-rc1/2/3/4 I've been running into a problem where when transfering large amounts of data (trying to ftp a TB where is started sounds as if it used to work at some point. In your second posting, however, you note that the problem goes back at least to 2.6.13. So are there any kernels known not to exhibit the problem you described? when I posted this origionally I thought it was new in 2.6.17-rc, however since my testing with older kernels hasn't found me a working one yet I suspect that other factors have been involved with makeing it work. these failures have been on multi-gig files ftp'd from the raid array on my machine to the raid array on the replacement machine. In the past I've sucessfully transfered similar sized files to/from my tivo (slow network), my laptop (slow drive), and smaller sets of files to single drives on other systems (7200rpm drives, but not to arrays). as I type this I'm starting a test going from a single drive on this machine to the raid array on the remote machine to transfer ~84G of data. My suspicion is that this is going to work. when I say shut down I mean that it looses link and requires powering down the box (hard power down, not just power off from the front panel), disabling the network card in the BIOS, booting (as far as lilo is enough), powering down again, enabling the card and booting again. So there are two problem areas: 1) the chip hangs itself without the driver noticing and 2) the BIOS fails to bring the chip back to life afterwards. yes there is no indication of trouble before the halt (it's transfering at full speed), the only think in the log is May 11 22:23:57 david kernel: eth0: link down May 11 22:24:00 david kernel: eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1 May 11 22:24:22 david kernel: eth0: link down if I don't do the disable/enable in the bios cycle and just power cycle the system the card does not initialize properly (ethtool reports autonegotiation disabled, 10Mb. will generate an 'unsupported' error if I try to enable the card) Any difference in the kernel log when booting with (or ethtooling) a comatose chip? I haven't checked the boot logs, I'll do that. ethtool hasn't generated any logs that I've seen. after the current transfer finishes I'll trigger the bug and test this. [EMAIL PROTECTED]:~$ /sbin/lspci 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0204 00:00.1 Host bridge: VIA Technologies, Inc.: Unknown device 1204 00:00.2 Host bridge: VIA Technologies, Inc.: Unknown device 2204 00:00.3 Host bridge: VIA Technologies, Inc.: Unknown device 3204 00:00.4 Host bridge: VIA Technologies, Inc.: Unknown device 4204 00:00.7 Host bridge: VIA Technologies, Inc.: Unknown device 7204 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800 South] 00:08.0 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07) 00:08.1 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07) 00:0a.0 Ethernet controller: Olicom OC-2326 (rev 01) 00:0f.0 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C/VT8235 PIPC Bus Master IDE (rev 06) 00:10.0 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 81) 00:10.1 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 81) 00:10.2 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 81) 00:10.3 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 81) 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [K8T800 South] 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 78) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (rev 01) Odd. This doesn't look at all like the list I'd expect from an nforce-A939. I thought Nvidia devices featured rather prominently in the device lists of nforce-based boards!? you're right, it's the new server that has the nforce board. I'll have to check the motherboard version when I reboot it. David Lang - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
