Re: dead network on JS21 with tg3 driver after flowcontrol changes
Olaf Hering wrote: > Yes, this patch fixes nfsroot for me. Thanks. > mii-tool is not shipped anymore, even in SLES10. > I assume that ethtool is the replacement? > Thanks. We'll send the patch to DaveM and to stable as well. ethtool can provide some high level link parameters. But in this case, I was trying to use mii-tool to look at the PHY registers to help debug the problem. ethtool would not provide that kind of information. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dead network on JS21 with tg3 driver after flowcontrol changes
On Thu, May 15, Michael Chan wrote: > Matt, I think that's very likely the problem. If we are trying to > establish link in parallel detect mode, the flow control settings may > not match. If we do not enter the if statement to do nothing, we will > keep autonegotiating forever and never establish link. Yes, this patch fixes nfsroot for me. Thanks. mii-tool is not shipped anymore, even in SLES10. I assume that ethtool is the replacement? Olaf ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dead network on JS21 with tg3 driver after flowcontrol changes
On Thu, 2008-05-15 at 10:15 -0700, Matt Carlson wrote:
> If you were to start with the original file, does the following patch
> fix the problem?
>
>
> diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
> index 07b3f77..4c248d7 100644
> --- a/drivers/net/tg3.c
> +++ b/drivers/net/tg3.c
> @@ -3168,8 +3168,7 @@ static int tg3_setup_fiber_mii_phy(struct tg3 *tp, int
> force_reset)
> err |= tg3_readphy(tp, MII_BMCR, &bmcr);
>
> if ((tp->link_config.autoneg == AUTONEG_ENABLE) && !force_reset &&
> - (tp->tg3_flags2 & TG3_FLG2_PARALLEL_DETECT) &&
> - tp->link_config.flowctrl == tp->link_config.active_flowctrl) {
> + (tp->tg3_flags2 & TG3_FLG2_PARALLEL_DETECT)) {
> /* do nothing, just check for link up at the end */
> } else if (tp->link_config.autoneg == AUTONEG_ENABLE) {
> u32 adv, new_adv;
>
Matt, I think that's very likely the problem. If we are trying to
establish link in parallel detect mode, the flow control settings may
not match. If we do not enter the if statement to do nothing, we will
keep autonegotiating forever and never establish link.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dead network on JS21 with tg3 driver after flowcontrol changes
If you were to start with the original file, does the following patch
fix the problem?
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 07b3f77..4c248d7 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -3168,8 +3168,7 @@ static int tg3_setup_fiber_mii_phy(struct tg3 *tp, int
force_reset)
err |= tg3_readphy(tp, MII_BMCR, &bmcr);
if ((tp->link_config.autoneg == AUTONEG_ENABLE) && !force_reset &&
- (tp->tg3_flags2 & TG3_FLG2_PARALLEL_DETECT) &&
-tp->link_config.flowctrl == tp->link_config.active_flowctrl) {
+ (tp->tg3_flags2 & TG3_FLG2_PARALLEL_DETECT)) {
/* do nothing, just check for link up at the end */
} else if (tp->link_config.autoneg == AUTONEG_ENABLE) {
u32 adv, new_adv;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dead network on JS21 with tg3 driver after flowcontrol changes
On Thu, 2008-05-15 at 17:49 +0200, Olaf Hering wrote: > On Thu, May 15, Michael Chan wrote: > > > Olaf Hering wrote: > > > > > Any ideas how to fix this? > > > What info do you need from the system? > > > > Are you using eth0 or eth1? The dmesg below shows that > > link came up on eth1 and IP address from DHCP was received. > > I'm using eth1. > The log was done with the patch reverted. > In that case, please re-apply the patch and provide mii-tool -vvv eth1. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dead network on JS21 with tg3 driver after flowcontrol changes
On Thu, May 15, Michael Chan wrote: > Olaf Hering wrote: > > > Any ideas how to fix this? > > What info do you need from the system? > > Are you using eth0 or eth1? The dmesg below shows that > link came up on eth1 and IP address from DHCP was received. I'm using eth1. The log was done with the patch reverted. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dead network on JS21 with tg3 driver after flowcontrol changes
Olaf Hering wrote: > Any ideas how to fix this? > What info do you need from the system? Are you using eth0 or eth1? The dmesg below shows that link came up on eth1 and IP address from DHCP was received. > Sending DHCP requests .<6>tg3: eth1: Link is up at 1000 Mbps, > full duplex. > tg3: eth1: Flow control is off for TX and off for RX. > ., OK > IP-Config: Got DHCP answer from 10.10.4.97, my address is 10.10.1.110 > IP-Config: Complete: If you're using eth0 and link did not come up, please provide mii-tool -vvv eth0. Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
dead network on JS21 with tg3 driver after flowcontrol changes
Commit ef167e27039eeaea6d3cdd5c547b082e89840bdd ([TG3]: Fix supporting flowctrl code) breaks networking on IBM JS21 blade servers. If I revert this change from 2.6.26-rc2-git4, nfsroot for example will work again. There are no packages submitted, a tcpdump on a different host sees no broadcast messages. Any ideas how to fix this? What info do you need from the system? I started with arch/powerpc/configs/ppc64_defconfig and updated CONFIG_CMDLINE for nfsroot. tg3.c:v3.92 (May 2, 2008) tg3 :10:04.0: enabling device ( -> 0002) eth0: Tigon3 [partno(none) rev 8003 PHY(5780)] (PCIX:133MHz:64-bit) 1000Base-SX Ethernet 00:11:25:c9:07:22 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] WireSpeed[0] TSOcap[1] eth0: dma_rwctrl[76144000] dma_mask[40-bit] tg3 :10:04.1: enabling device ( -> 0002) eth1: Tigon3 [partno(none) rev 8003 PHY(5780)] (PCIX:133MHz:64-bit) 1000Base-SX Ethernet 00:11:25:c9:07:23 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[0] TSOcap[1] eth1: dma_rwctrl[76144000] dma_mask[40-bit] ... full dmesg: Using pSeries machine description Page orders: linear mapping = 24, virtual = 12, io = 12 console [udbg0] enabled Partition configured for 2 cpus. CPU maps initialized for 1 thread per core (thread shift is 0) Starting Linux PPC64 #3 SMP Thu May 15 13:47:10 CEST 2008 - ppc64_pft_size= 0x19 physicalMemorySize= 0x7a00 htab_hash_mask= 0x3 - Initializing cgroup subsys cpuset Linux version 2.6.26-rc2-git4 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070115 (prerelease) (SUSE Linux)) #3 SMP Thu May 15 13:47:10 CEST 2008 [boot]0012 Setup Arch Entering add_active_range(0, 0, 499712) 0 entries of 256 used PCI host bridge /[EMAIL PROTECTED] ranges: IO 0x0100f400..0x0100f43f -> 0x MEM 0x01008000..0x0100efff -> 0x8000 PPC64 nvram contains 8192 bytes Using dedicated idle loop Top of RAM: 0x7a00, Total RAM: 0x7a00 Memory hole size: 0MB Zone PFN ranges: DMA 0 -> 499712 Normal 499712 -> 499712 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -> 499712 On node 0 totalpages: 499712 DMA zone: 6832 pages used for memmap DMA zone: 0 pages reserved DMA zone: 492880 pages, LIFO batch:31 Normal zone: 0 pages used for memmap Movable zone: 0 pages used for memmap [boot]0015 Setup Done Built 1 zonelists in Zone order, mobility grouping on. Total pages: 492880 Kernel command line: debug panic=9 rw root=/dev/nfs nfsroot=10.10.4.97:/data/inst/nfs/olh ip=:eth1:dhcp [boot]0020 XICS Init [boot]0021 XICS Done pic: no ISA interrupt controller PID hash table entries: 4096 (order: 12, 32768 bytes) time_init: decrementer frequency = 14.318000 MHz time_init: processor frequency = 2597.40 MHz clocksource: timebase mult[1175e5e5] shift[22] registered clockevent: decrementer mult[3aa] shift[16] cpu[0] Console: colour dummy device 80x25 console handover: boot [udbg0] -> real [hvc0] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Memory: 1942124k/1998848k available (8288k kernel code, 56096k reserved, 1412k data, 532k bss, 380k init) SLUB: Genslabs=12, HWalign=128, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 Calibrating delay loop... 28.60 BogoMIPS (lpj=57216) Mount-cache hash table entries: 256 clockevent: decrementer mult[3aa] shift[16] cpu[1] Processor 1 found. Brought up 2 CPUs CPU0 attaching sched-domain: domain 0: span 0-1 groups: 0 1 CPU1 attaching sched-domain: domain 0: span 0-1 groups: 1 0 khelper used greatest stack depth: 12896 bytes left khelper used greatest stack depth: 12320 bytes left khelper used greatest stack depth: 11904 bytes left net_namespace: 936 bytes xor: measuring software checksum speed 8regs : 5830.000 MB/sec 8regs_prefetch: 4644.000 MB/sec 32regs: 5751.000 MB/sec 32regs_prefetch: 4601.000 MB/sec xor: using function: 8regs (5830.000 MB/sec) NET: Registered protocol family 16 IBM eBus Device Driver PCI: Probing PCI hardware IOMMU table initialized, virtual merging enabled PCI: Probing PCI hardware done SCSI subsystem initialized libata version 3.00 loaded. usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb NET: Registered protocol family 2 Switched to high resolution mode on CPU 0 Switched to high resolution mode on CPU 1 IP route cache hash table entries: 65536 (order: 7, 524288 bytes) TCP established hash table entries: 262144 (order: 10, 4194304 bytes) TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) TCP: Hash tables configured (established 262144 bind 65536) TCP reno registered NET: Registered protocol family 1 RTAS daemon started Total HugeTLB memory allocated, 0 JFS:
