Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Mystery\s+packet\s+killing\s+tg3\s*$/: 70 ]

Total 70 documents matching your query.

1. Mystery packet killing tg3 (score: 1)
Author: Stephen Hemminger <shemminger@xxxxxxxx>
Date: Mon, 2 May 2005 16:24:05 -0700
While I was on vacation, OSDL did some networking changes that seems to aggravate some existing bug in the tg3 driver. Could be some VLAN related garbage, not sure. System is 2 CPU AMD64 and the tg3
/archives/netdev/2005-05/msg00035.html (8,295 bytes)

2. Re: Mystery packet killing tg3 (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Mon, 2 May 2005 20:02:51 -0700
This usually means that there is some DMA corruption. For example, some bug in the x86_64 IOMMU code or similar causes a bogus DMA address to be fed to the tg3 or even worse a DMA mapping is unmapped
/archives/netdev/2005-05/msg00043.html (9,779 bytes)

3. Re: Mystery packet killing tg3 (score: 1)
Author: Stephen Hemminger <shemminger@xxxxxxxx>
Date: Tue, 3 May 2005 14:05:28 -0700
Added call to tg_dump_state() tg3: tg3_stop_block timed out, ofs=4000 enable_bit=2 DEBUG: PCI status [02b0] TG3PCI state[000010e2] DEBUG: MAC_MODE[00c04c08] MAC_STATUS[00400003] MAC_EVENT[00001000] M
/archives/netdev/2005-05/msg00072.html (22,320 bytes)

4. Re: Mystery packet killing tg3 (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Tue, 3 May 2005 14:13:14 -0700
Buggy 8131 APIC, does the drivers/pci/quirks.c:quirk_amd_8131_ioapic() message: PCI: MSI quirk detected. pci_msi_quirk set. trigger? MSI support recently got added to the tg3.c driver, but it should
/archives/netdev/2005-05/msg00073.html (9,298 bytes)

5. Re: Mystery packet killing tg3 (score: 1)
Author: Stephen Hemminger <shemminger@xxxxxxxx>
Date: Tue, 3 May 2005 14:29:52 -0700
yes. that is there. There is no call to pci_enable_msi in the 2.6.12-rc3 source
/archives/netdev/2005-05/msg00074.html (10,025 bytes)

6. Re: Mystery packet killing tg3 (score: 1)
Author: "Michael Chan" <mchan@xxxxxxxxxxxx>
Date: Tue, 03 May 2005 13:41:47 -0700
MSI is buggy on 5703 and tg3 will not enable MSI on that chip. MSI only works on the latest PCI Express chips.
/archives/netdev/2005-05/msg00083.html (10,152 bytes)

7. Re: Mystery packet killing tg3 (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Tue, 3 May 2005 15:03:33 -0700
Ok, and he has a pre-MSI copy of the tg3 driver anyways. Michael, there were no master/target abort bits set in the PCI status register from his dump. If one of the DMA units locks up on the tg3, wil
/archives/netdev/2005-05/msg00092.html (10,537 bytes)

8. Re: Mystery packet killing tg3 (score: 1)
Author: "Michael Chan" <mchan@xxxxxxxxxxxx>
Date: Tue, 03 May 2005 14:28:10 -0700
I believe so. Also, the DMA read and write status registers showed all zeros, meaning there were no DMA related errors: DEBUG: RDMAC_MODE[000003fc] RDMAC_STATUS[00000000] DEBUG: WDMAC_MODE[000003fc]
/archives/netdev/2005-05/msg00094.html (10,297 bytes)

9. Re: Mystery packet killing tg3 (score: 1)
Author: Stephen Hemminger <shemminger@xxxxxxxx>
Date: Tue, 3 May 2005 15:45:00 -0700
No, I forced it to always be true and still dies (when taking network down).
/archives/netdev/2005-05/msg00098.html (11,677 bytes)

10. Re: Mystery packet killing tg3 (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Tue, 3 May 2005 15:39:54 -0700
You're reproducing this pretty fast. Does the link jam up, or are you just simply downing the interface and the stop block messages are printed out? If it jams up, what kind of traffic are you using
/archives/netdev/2005-05/msg00100.html (10,599 bytes)

11. Re: Mystery packet killing tg3 (score: 1)
Author: Stephen Hemminger <shemminger@xxxxxxxx>
Date: Tue, 3 May 2005 15:59:11 -0700
Initially, it reproduced everytime link came up, we reconfigured the VLAN to have a mirror port into a laptop to try and capture what was happening, but when we did that the bootup problem went away.
/archives/netdev/2005-05/msg00103.html (11,706 bytes)

12. Re: Mystery packet killing tg3 (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Tue, 3 May 2005 15:53:55 -0700
Right, I noticed that too. Stephen says that trying to force enable the mailbox write reordering workaround doesn't solve the problem either. I wonder exactly how it would show up if the x86_64 port
/archives/netdev/2005-05/msg00105.html (12,402 bytes)

13. RE: Mystery packet killing tg3 (score: 1)
Author: "Michael Chan" <mchan@xxxxxxxxxxxx>
Date: Tue, 3 May 2005 23:09:15 -0700
The 5703 related settings in tg3 seem ok to me too. If Stephen says the stop_block error happens during normal ifdown and traffic was otherwise working fine before ifdown, then I think it may not eve
/archives/netdev/2005-05/msg00138.html (10,087 bytes)

14. RE: Mystery packet killing tg3 (score: 1)
Author: "Michael Chan" <mchan@xxxxxxxxxxxx>
Date: Tue, 3 May 2005 23:27:38 -0700
During initial dev_open, the TG3_FLAG_INIT_COMPLETE flag is not set so tg3_reset_hw() should not call tg3_abort_hw() where the stop_block calls are made. So there should be no stop_block errors. I th
/archives/netdev/2005-05/msg00139.html (9,378 bytes)

15. Re: Mystery packet killing tg3 (score: 1)
Author: Andi Kleen <ak@xxxxxx>
Date: Wed, 04 May 2005 20:30:00 +0200
IOMMU code on x86-64 should be never active unless Stephen used IOMMU_DEBUG or iommu=force. THat is because the tg3 is a 64bit capable device and should always use bypass. You could just buy one ,-)
/archives/netdev/2005-05/msg00164.html (10,577 bytes)

16. Re: Mystery packet killing tg3 (score: 1)
Author: Peter Buckingham <peter@xxxxxxxxxxxx>
Date: Wed, 04 May 2005 11:44:53 -0700
Andi Kleen wrote: "David S. Miller" <davem@xxxxxxxxxxxxx> writes: This usually means that there is some DMA corruption. For example, some bug in the x86_64 IOMMU code or similar causes a bogus DMA ad
/archives/netdev/2005-05/msg00166.html (10,726 bytes)

17. Re: Mystery packet killing tg3 (score: 1)
Author: Stephen Hemminger <shemminger@xxxxxxxx>
Date: Wed, 4 May 2005 12:41:36 -0700
FYI the config of the system: CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_MMU=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONF
/archives/netdev/2005-05/msg00168.html (40,773 bytes)

18. Re: Mystery packet killing tg3 (score: 1)
Author: Stephen Hemminger <shemminger@xxxxxxxx>
Date: Wed, 4 May 2005 15:51:43 -0700
It seems that dhclient was failing on bootup then taking the device down. When the device down happened it got the tg3_stop_block from Call Trace:<ffffffff880178a9>{:tg3:tg3_stop_block+185} <ffffffff
/archives/netdev/2005-05/msg00173.html (10,556 bytes)

19. Re: Mystery packet killing tg3 (score: 1)
Author: "Michael Chan" <mchan@xxxxxxxxxxxx>
Date: Wed, 04 May 2005 15:30:22 -0700
This makes sense. Before the dhclient closes the device, was the device functioning properly? If not, was it not sending or not receiving? If the device was functioning properly prior to the close, m
/archives/netdev/2005-05/msg00174.html (10,322 bytes)

20. Re: Mystery packet killing tg3 (score: 1)
Author: xxxxxx>
Date: Thu, 5 May 2005 13:43:27 +0200
"32bit e1000"? How did you get such a beast? AFAIK all e1000s are 64bit address capable. Please supply a full boot log without iommu=force and describe what happens exactly. -Andi
/archives/netdev/2005-05/msg00192.html (10,555 bytes)

Current List: 1 - 20
Page: [1] [2] [3] [4]
This search system is powered by Namazu