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.

41. 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/msg01372.html (10,325 bytes)

42. 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/msg01381.html (10,795 bytes)

43. 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/msg01383.html (10,568 bytes)

44. 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/msg01387.html (11,948 bytes)

45. 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/msg01389.html (10,895 bytes)

46. 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/msg01392.html (12,045 bytes)

47. 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/msg01394.html (12,758 bytes)

48. 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/msg01427.html (10,087 bytes)

49. 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/msg01428.html (9,378 bytes)

50. 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/msg01453.html (10,682 bytes)

51. Re: Mystery packet killing tg3 (score: 1)
Author: Peter Buckingham <peter@xxxxxxxxxxxx>
Date: Wed, 04 May 2005 11:44:53 -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 unmappe
/archives/netdev/2005-05/msg01455.html (10,861 bytes)

52. 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/msg01457.html (40,885 bytes)

53. 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/msg01462.html (10,652 bytes)

54. 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/msg01463.html (10,432 bytes)

55. Re: Mystery packet killing tg3 (score: 1)
Author: Andi Kleen <ak@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/msg01481.html (10,693 bytes)

56. Re: Mystery packet killing tg3 (score: 1)
Author: Stephen Hemminger <shemminger@xxxxxxxx>
Date: Thu, 05 May 2005 09:20:25 -0700
One of the osdl e1000's in the lab is an IBM rebranded card that although it uses a 64bit slot, is really only 32bit
/archives/netdev/2005-05/msg01494.html (11,110 bytes)

57. Re: Mystery packet killing tg3 (score: 1)
Author: Peter Buckingham <peter@xxxxxxxxxxxx>
Date: Thu, 05 May 2005 10:09:55 -0700
that was my initial impression too :-( basically what happens is when there is more that 4GB of RAM in this system packets will start disappearing. ie ping will drop packets. Initially our bios was n
/archives/netdev/2005-05/msg01497.html (19,525 bytes)

58. Re: Mystery packet killing tg3 (score: 1)
Author: Rick Jones <rick.jones2@xxxxxx>
Date: Thu, 05 May 2005 10:32:16 -0700
"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. that was my initial impr
/archives/netdev/2005-05/msg01498.html (11,056 bytes)

59. Re: Mystery packet killing tg3 (score: 1)
Author: Peter Buckingham <peter@xxxxxxxxxxxx>
Date: Thu, 05 May 2005 10:38:27 -0700
this is the one we're using. in the next generation of our system we'll definitely be using a 64bit part... peter 0000:05:07.0 Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller
/archives/netdev/2005-05/msg01499.html (12,066 bytes)

60. Re: Mystery packet killing tg3 (score: 1)
Author: John Heffner <jheffner@xxxxxxx>
Date: Thu, 5 May 2005 13:45:35 -0400
From a zx2000: 0000:a0:03.0 Ethernet controller: Intel Corp. 82540EM Gigabit Ethernet Controller (rev 02) Subsystem: Hewlett-Packard Company: Unknown device 1274 Flags: bus master, 66MHz, medium devs
/archives/netdev/2005-05/msg01501.html (10,966 bytes)

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