Re: tg3 broken on 2.6.17-rc5-mm3

Re: tg3 broken on 2.6.17-rc5-mm3

[Michael Chan]

On Wed, 2006-06-07 at 17:11 -0600, Bjorn Helgaas wrote:
> Something changed between 2.6.17-rc5-mm2 and -mm3 that broke tg3
> on my HP DL360:
> 
> 2.6.17-rc5-mm2:
>   tg3.c:v3.59 (May 26, 2006)
>   ACPI: PCI Interrupt 0000:01:02.0[A] -> GSI 30 (level, low) -> IRQ 177
>   eth0: Tigon3 [partno(N/A) rev 1002 PHY(5703)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:0e:7f:b4:69:94
>   eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1] 
>   eth0: dma_rwctrl[769f4000] dma_mask[64-bit]
> 
> 2.6.17-rc5-mm3 (with a bit of debug showing tg3_read_mem result):
>   tg3.c:v3.59 (May 26, 2006)
>   ACPI: PCI Interrupt 0000:01:02.0[A] -> GSI 30 (level, low) -> IRQ 177
>   tg3_get_eeprom_hw_cfg:
>   tg3_get_eeprom_hw_cfg: val 0xffffffff (magic 0x4b657654)
>   tg3_phy_probe: after readphy, err -16 hw_phy_id 0x0
>   tg3_phy_probe: phy_id 0xffffffff
>   lookup_by_subsys: vendor 0xe11 dev 0xcb
>   tg3: (0000:01:02.0) phy probe failed, err -19
>   tg3: Problem fetching invariants of chip, aborting.

My suspicion is that either the memory enable bit in PCI config register
4 is not set or the power state in PCI config register 0x4c is D3hot.
Any of these conditions will cause MMIO registers to return 0xffffffff.

Try reading config registers 0x4 and 0x4c to see what the values are.

Thanks.

tg3 broken on 2.6.17-rc5-mm3

[Bjorn Helgaas]

Something changed between 2.6.17-rc5-mm2 and -mm3 that broke tg3
on my HP DL360:

2.6.17-rc5-mm2:
  tg3.c:v3.59 (May 26, 2006)
  ACPI: PCI Interrupt 0000:01:02.0[A] -> GSI 30 (level, low) -> IRQ 177
  eth0: Tigon3 [partno(N/A) rev 1002 PHY(5703)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:0e:7f:b4:69:94
  eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1] 
  eth0: dma_rwctrl[769f4000] dma_mask[64-bit]

2.6.17-rc5-mm3 (with a bit of debug showing tg3_read_mem result):
  tg3.c:v3.59 (May 26, 2006)
  ACPI: PCI Interrupt 0000:01:02.0[A] -> GSI 30 (level, low) -> IRQ 177
  tg3_get_eeprom_hw_cfg:
  tg3_get_eeprom_hw_cfg: val 0xffffffff (magic 0x4b657654)
  tg3_phy_probe: after readphy, err -16 hw_phy_id 0x0
  tg3_phy_probe: phy_id 0xffffffff
  lookup_by_subsys: vendor 0xe11 dev 0xcb
  tg3: (0000:01:02.0) phy probe failed, err -19
  tg3: Problem fetching invariants of chip, aborting.

The tg3 driver itself didn't change, so it must be some other PCI
change or something.  The only other PCI device I have (a Smart
Array with cciss driver) works fine.

I'll try to narrow down the problem tomorrow, but I'll post this in
case it's obvious to somebody.

Bjorn

Re: tg3 broken on 2.6.17-rc5-mm3

[Andrew Morton]

On Wed, 7 Jun 2006 17:11:06 -0600
Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:

> Something changed between 2.6.17-rc5-mm2 and -mm3 that broke tg3
> on my HP DL360:
> 
> 2.6.17-rc5-mm2:
>   tg3.c:v3.59 (May 26, 2006)
>   ACPI: PCI Interrupt 0000:01:02.0[A] -> GSI 30 (level, low) -> IRQ 177
>   eth0: Tigon3 [partno(N/A) rev 1002 PHY(5703)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:0e:7f:b4:69:94
>   eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1] 
>   eth0: dma_rwctrl[769f4000] dma_mask[64-bit]
> 
> 2.6.17-rc5-mm3 (with a bit of debug showing tg3_read_mem result):
>   tg3.c:v3.59 (May 26, 2006)
>   ACPI: PCI Interrupt 0000:01:02.0[A] -> GSI 30 (level, low) -> IRQ 177
>   tg3_get_eeprom_hw_cfg:
>   tg3_get_eeprom_hw_cfg: val 0xffffffff (magic 0x4b657654)
>   tg3_phy_probe: after readphy, err -16 hw_phy_id 0x0
>   tg3_phy_probe: phy_id 0xffffffff
>   lookup_by_subsys: vendor 0xe11 dev 0xcb
>   tg3: (0000:01:02.0) phy probe failed, err -19
>   tg3: Problem fetching invariants of chip, aborting.
> 
> The tg3 driver itself didn't change, so it must be some other PCI
> change or something.  The only other PCI device I have (a Smart
> Array with cciss driver) works fine.
> 
> I'll try to narrow down the problem tomorrow, but I'll post this in
> case it's obvious to somebody.
> 

fwiw, tg3 on powermac g5 works OK with rc6-mm1.

Re: tg3 broken on 2.6.17-rc5-mm3

[Frederik Deweerdt]

On Wed, Jun 07, 2006 at 05:11:06PM -0600, Bjorn Helgaas wrote:
> I'll try to narrow down the problem tomorrow, but I'll post this in
> case it's obvious to somebody.
> 
FYI, it was OK for me on x86 with both rc5-mm2 and rc5-mm3 (dmesg from mm3)
[   20.749964] tg3.c:v3.59 (May 26, 2006)
[   20.749993] ACPI (acpi_bus-0192): Device `NIC]is not power manageable [20060310]
[   20.750008] ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 16
[   20.750023] PCI: Setting latency timer of device 0000:02:00.0 to 64
[   20.788136] eth0: Tigon3 [partno(BCM95751) rev 4001 PHY(5750)] (PCI Express) 10/100/1000BaseT Ethernet 00:14:22:c6:f6:a0

Regards,
Frederik

Re: tg3 broken on 2.6.17-rc5-mm3

[H. Peter Anvin]

Bjorn Helgaas wrote:
> On Wednesday 07 June 2006 17:11, Bjorn Helgaas wrote:
>> Something changed between 2.6.17-rc5-mm2 and -mm3 that broke tg3
>> on my HP DL360:
> 
> and the specific change that broke it seems to be:
>   gregkh-pci-pci-ignore-pre-set-64-bit-bars-on-32-bit-platforms.patch.
> 
> pci_read:  0000:01:02.0 reg 0x10 len 4 val 0xf7ef0004
> pci_write: 0000:01:02.0 reg 0x10 len 4 val 0xffffffff
> pci_read:  0000:01:02.0 reg 0x10 len 4 val 0xffff0004
> pci_write: 0000:01:02.0 reg 0x10 len 4 val 0xf7ef0004
> pci_read:  0000:01:02.0 reg 0x14 len 4 val 0x0000
> pci_write: 0000:01:02.0 reg 0x14 len 4 val 0xffffffff
> pci_read:  0000:01:02.0 reg 0x14 len 4 val 0xffffffff
> pci_write: 0000:01:02.0 reg 0x14 len 4 val 0x0000

... this is a 64-bit BAR preset with a 16-bit mask, preset
to the valid 32-bit address 0x0000_0000_f7ef_0000.

> pci_write: 0000:01:02.0 reg 0x10 len 4 val 0x0004  <=== looks questionable
> pci_write: 0000:01:02.0 reg 0x14 len 4 val 0x0000

... here the algorithm thinks the addrss is above 4 GB and disables it. 
  It should re-enable it when the device is turned back on, though; if 
it doesn't that's very strange.

Anyway, the error seems to be that the line:

+			} else if (l) {

... should be ...

+			} else if (lhi) {

... since l contains the lower half of the pre-set address at that 
point, and lhi is the upper half.

	-hpa

Re: tg3 broken on 2.6.17-rc5-mm3

[Bjorn Helgaas]

On Thursday 08 June 2006 23:03, H. Peter Anvin wrote:
> Bjorn Helgaas wrote:
> > On Wednesday 07 June 2006 17:11, Bjorn Helgaas wrote:
> >> Something changed between 2.6.17-rc5-mm2 and -mm3 that broke tg3
> >> on my HP DL360:
> > 
> > and the specific change that broke it seems to be:
> >   gregkh-pci-pci-ignore-pre-set-64-bit-bars-on-32-bit-platforms.patch.
> > 
> > pci_read:  0000:01:02.0 reg 0x10 len 4 val 0xf7ef0004
> > pci_write: 0000:01:02.0 reg 0x10 len 4 val 0xffffffff
> > pci_read:  0000:01:02.0 reg 0x10 len 4 val 0xffff0004
> > pci_write: 0000:01:02.0 reg 0x10 len 4 val 0xf7ef0004
> > pci_read:  0000:01:02.0 reg 0x14 len 4 val 0x0000
> > pci_write: 0000:01:02.0 reg 0x14 len 4 val 0xffffffff
> > pci_read:  0000:01:02.0 reg 0x14 len 4 val 0xffffffff
> > pci_write: 0000:01:02.0 reg 0x14 len 4 val 0x0000
> 
> ... this is a 64-bit BAR preset with a 16-bit mask, preset
> to the valid 32-bit address 0x0000_0000_f7ef_0000.
> 
> > pci_write: 0000:01:02.0 reg 0x10 len 4 val 0x0004  <=== looks questionable
> > pci_write: 0000:01:02.0 reg 0x14 len 4 val 0x0000
> 
> ... here the algorithm thinks the addrss is above 4 GB and disables it. 
>   It should re-enable it when the device is turned back on, though; if 
> it doesn't that's very strange.
> 
> Anyway, the error seems to be that the line:
> 
> +			} else if (l) {
> 
> ... should be ...
> 
> +			} else if (lhi) {
> 
> ... since l contains the lower half of the pre-set address at that 
> point, and lhi is the upper half.

The patch below indeed fixes the problem.  You can have my
"signed-off" if you want (though you supplied the fix above),
but can you please write the description?  I'm too lazy to
puzzle it all out and you understand it already anyway :-)


Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>

Index: rc5-mm3/drivers/pci/probe.c
===================================================================
--- rc5-mm3.orig/drivers/pci/probe.c	2006-06-09 09:40:51.000000000 -0600
+++ rc5-mm3/drivers/pci/probe.c	2006-06-09 09:42:35.000000000 -0600
@@ -199,7 +199,7 @@
 				printk(KERN_ERR "PCI: Unable to handle 64-bit BAR for device %s\n", pci_name(dev));
 				res->start = 0;
 				res->flags = 0;
-			} else if (l) {
+			} else if (lhi) {
 				/* 64-bit wide address, treat as disabled */
 				pci_write_config_dword(dev, reg, l & ~(u32)PCI_BASE_ADDRESS_MEM_MASK);
 				pci_write_config_dword(dev, reg+4, 0);

[PATCH] fix to pci ignore pre-set 64-bit bars on 32-bit platforms

[H. Peter Anvin]

[-- Attachment #1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #2: pci-fix.txt --]
[-- Type: text/plain, Size: 1322 bytes --]

From: Bjorn Helgaas <bjorn.helgaas@hp.com>

When we detect a 64-bit pre-set address in a BAR on a 32-bit platform,
we disable it and treat it as if it had been unset, thus allowing the
general address assignment code to assign a new address to it when the
device is enabled.  This can happen either if the firmware assigns
64-bit addresses; additionally, some cards have been found "in the
wild" which do not come out of reset with all the BAR registers set to
zero.

Unfortunately, the patch that implemented this tested the low part of
the address instead of the high part of the address.  This patch fixes
that.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>

Index: rc5-mm3/drivers/pci/probe.c
===================================================================
--- rc5-mm3.orig/drivers/pci/probe.c	2006-06-09 09:40:51.000000000 -0600
+++ rc5-mm3/drivers/pci/probe.c	2006-06-09 09:42:35.000000000 -0600
@@ -199,7 +199,7 @@
 				printk(KERN_ERR "PCI: Unable to handle 64-bit BAR for device %s\n", pci_name(dev));
 				res->start = 0;
 				res->flags = 0;
-			} else if (l) {
+			} else if (lhi) {
 				/* 64-bit wide address, treat as disabled */
 				pci_write_config_dword(dev, reg, l & ~(u32)PCI_BASE_ADDRESS_MEM_MASK);
 				pci_write_config_dword(dev, reg+4, 0);