* possible routing table cache bug for mtu/advmss attributes in Linux 3.0.4
From: David Madore @ 2011-09-01 21:46 UTC (permalink / raw)
To: Linux Netdev Mailing-List
Hi,
I believe I've found a bug in the routing cache (perhaps only for
IPv6) in Linux 3.0.4. Since I'm uncertain about the diagnosis, I'm
posting here for guidance as to how to proceed.
In a nutshell, the problem is this: my (manually entered) routing
tables specify an explicit MTU/MSS for certain IPv6 routes, and after
upgrading from 2.6.38.7 to 3.0.4, I found that this MTU/MSS setting is
sometimes ignored. More precisely, it seems that connecting to a host
through the route in question causes a routing cache entry to be
created, and it is when this cache entry expires that the route
forgets the MTU/MSS setting. (It may also be relevant that in my case
the route belongs to a routing table other than "main".)
In more details: my routing tables contains the following:
vega david ~ $ sudo ip -6 rule show
0: from all lookup local
32766: from all lookup main
40000: from 2002::/16 lookup 2002
40100: from all lookup 2001
vega david ~ $ sudo ip -6 route show table 2001
2002::/16 via ::192.88.99.1 dev tun6to4 metric 512 mtu 1466 advmss 1406
2000::/3 dev ppp0 metric 64 mtu 1466 advmss 1406
Initially, trying to get the route to 2001:41d0:1:a431::1 correctly
returns route with the mtu and advmss values I entered:
vega david ~ $ sudo ip route get 2001:41d0:1:a431::1
2001:41d0:1:a431::1 from :: via 2001:41d0:1:a431::1 dev ppp0 src 2001:7a8:78ae::1 metric 0
cache mtu 1466 advmss 1406
Now I start an ssh connection to 2001:41d0:1:a431::1, close it
immediately, and fetch the route again:
vega david ~ $ sudo ip route get 2001:41d0:1:a431::1
2001:41d0:1:a431::1 from :: via 2001:41d0:1:a431::1 dev ppp0 src 2001:7a8:78ae::1 metric 0
cache mtu 1466 rtt 37ms rttvar 37ms cwnd 10 advmss 1406
This is still correct. But if I wait a few seconds (doing nothing)
for these data to expire, they seems to take the mtu and advmss values
away with them:
vega david ~ $ sudo ip route get 2001:41d0:1:a431::1
2001:41d0:1:a431::1 from :: via 2001:41d0:1:a431::1 dev ppp0 src 2001:7a8:78ae::1 metric 0
cache
(note the empty "cache" line and the absence of mtu/advmss settings).
This is not just wrongly reported: the route really is wrong, and
opening a TCP connection at this stage will use a wrong MSS (and
freeze on large packets, because my Internet provider is worthless,
but that's another story). At some point the route seems to return to
normal, but I couldn't figure out what causes this exactly.
In case it's uesful, my kernel config is on <URL:
http://www.madore.org/~david/.tmp/config-3.0.4-vega
>.
Any thoughts?
--
David A. Madore
( http://www.madore.org/~david/ )
^ permalink raw reply
* Re: [PATCH] net: Prefer non link-local source addresses
From: David Lamparter @ 2011-09-01 21:56 UTC (permalink / raw)
To: Jeff Harris
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <1314908454-14359-1-git-send-email-jeff_harris@kentrox.com>
On Thu, Sep 01, 2011 at 04:20:54PM -0400, Jeff Harris wrote:
> Section 2.6.1 of RFC 3927 specifies that if link-local and routable addresses
> are available on an interface, a routable address is preferred. Update the
> IPv4 source address selection algorithm to use a 169.254.x.x address only if
> another matching address is not found.
> + if (ipv4_is_linklocal_169(ifa->ifa_address)) {
> + lladdr = ifa->ifa_local;
> + continue;
> + }
IP addresses have a scope field:
# ip -4 a l eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
inet 10.0.0.1/24 brd 10.0.0.255 scope link eth0
inet 172.22.80.50/25 brd 172.22.80.127 scope global eth0
would it not make sense to use to use that field instead?
-David
^ permalink raw reply
* Re: [PATCH] dev_ioctl should return -EINVAL for unknown ioctl instead of -ENOTTY
From: Wang Sheng-Hui @ 2011-09-01 22:00 UTC (permalink / raw)
To: Ben Hutchings; +Cc: davem, netdev, linux-kernel
In-Reply-To: <1314891670.2733.12.camel@bwh-desktop>
On 2011年09月01日 23:41, Ben Hutchings wrote:
> On Thu, 2011-09-01 at 22:52 +0800, Wang Sheng-Hui wrote:
>> The patch is against 3.1-rc3.
>>
>> Signed-off-by: Wang Sheng-Hui <shhuiw@gmail.com>
>> ---
>> net/core/dev.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 17d67b5..de6033c 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -5092,7 +5092,7 @@ int dev_ioctl(struct net *net, unsigned int cmd, void __user *arg)
>> /* Take care of Wireless Extensions */
>> if (cmd >= SIOCIWFIRST && cmd <= SIOCIWLAST)
>> return wext_handle_ioctl(net, &ifr, cmd, arg);
>> - return -ENOTTY;
>> + return -EINVAL;
>> }
>> }
>>
>
> Whereas, Linus Torvalds wrote in
> <BANLkTin=PTbTwBR2s+owMLy+GmKigeoYvg@mail.gmail.com>:
> [...]
>> The correct error code for "I don't understand this ioctl" is ENOTTY.
>> The naming may be odd, but you should think of that error value as a
>> "unrecognized ioctl number, you're feeding me random numbers that I
>> don't understand and I assume for historical reasons that you tried to
>> do some tty operation on me".
> [...]
>
> (Not that we are consistent about using ENOTTY in networking now.)
>
> Ben.
>
Got it. Thanks.
^ permalink raw reply
* [PATCH] iPhone 4 Verizon CDMA USB Product ID add
From: Kavan Smith @ 2011-09-01 22:01 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-usb-u79uwXL29TY76Z2rM5mHXA
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Kavan Smith
Add USB product ID for iPhone 4 CDMA Verizon
Tested on at least 2 devices
Signed-off-by: Kavan Smith <kavansmith82-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/net/usb/ipheth.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/usb/ipheth.c b/drivers/net/usb/ipheth.c
index 15772b1..13c1f04 100644
--- a/drivers/net/usb/ipheth.c
+++ b/drivers/net/usb/ipheth.c
@@ -59,6 +59,7 @@
#define USB_PRODUCT_IPHONE_3G 0x1292
#define USB_PRODUCT_IPHONE_3GS 0x1294
#define USB_PRODUCT_IPHONE_4 0x1297
+#define USB_PRODUCT_IPHONE_4_VZW 0x129c
#define IPHETH_USBINTF_CLASS 255
#define IPHETH_USBINTF_SUBCLASS 253
@@ -98,6 +99,10 @@ static struct usb_device_id ipheth_table[] = {
USB_VENDOR_APPLE, USB_PRODUCT_IPHONE_4,
IPHETH_USBINTF_CLASS, IPHETH_USBINTF_SUBCLASS,
IPHETH_USBINTF_PROTO) },
+ { USB_DEVICE_AND_INTERFACE_INFO(
+ USB_VENDOR_APPLE, USB_PRODUCT_IPHONE_4_VZW,
+ IPHETH_USBINTF_CLASS, IPHETH_USBINTF_SUBCLASS,
+ IPHETH_USBINTF_PROTO) },
{ }
};
MODULE_DEVICE_TABLE(usb, ipheth_table);
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH net 1/2] Revert "sfc: Use write-combining to reduce TX latency" and follow-ups
From: Ben Hutchings @ 2011-09-01 22:09 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
This reverts commits 65f0b417dee94f779ce9b77102b7d73c93723b39,
d88d6b05fee3cc78e5b0273eb58c31201dcc6b76,
fcfa060468a4edcf776f0c1211d826d5de1668c1,
747df2258b1b9a2e25929ef496262c339c380009 and
867955f5682f7157fdafe8670804b9f8ea077bc7.
Depending on the processor model, write-combining may result in
reordering that the NIC will not tolerate. This typically results
in a DMA error event and reset by the driver, logged as:
sfc 0000:0e:00.0: eth2: TX DMA Q reports TX_EV_PKT_ERR.
sfc 0000:0e:00.0: eth2: resetting (ALL)
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
Please queue this for 3.0.y as well.
Ben.
drivers/net/sfc/efx.c | 18 +--------------
drivers/net/sfc/io.h | 15 +++---------
drivers/net/sfc/mcdi.c | 46 +++++++++++++++-------------------------
drivers/net/sfc/nic.c | 7 ------
drivers/net/sfc/nic.h | 2 -
drivers/net/sfc/siena.c | 25 +++------------------
drivers/net/sfc/workarounds.h | 2 -
7 files changed, 27 insertions(+), 88 deletions(-)
diff --git a/drivers/net/sfc/efx.c b/drivers/net/sfc/efx.c
index faca764..b59abc7 100644
--- a/drivers/net/sfc/efx.c
+++ b/drivers/net/sfc/efx.c
@@ -1050,7 +1050,6 @@ static int efx_init_io(struct efx_nic *efx)
{
struct pci_dev *pci_dev = efx->pci_dev;
dma_addr_t dma_mask = efx->type->max_dma_mask;
- bool use_wc;
int rc;
netif_dbg(efx, probe, efx->net_dev, "initialising I/O\n");
@@ -1101,21 +1100,8 @@ static int efx_init_io(struct efx_nic *efx)
rc = -EIO;
goto fail3;
}
-
- /* bug22643: If SR-IOV is enabled then tx push over a write combined
- * mapping is unsafe. We need to disable write combining in this case.
- * MSI is unsupported when SR-IOV is enabled, and the firmware will
- * have removed the MSI capability. So write combining is safe if
- * there is an MSI capability.
- */
- use_wc = (!EFX_WORKAROUND_22643(efx) ||
- pci_find_capability(pci_dev, PCI_CAP_ID_MSI));
- if (use_wc)
- efx->membase = ioremap_wc(efx->membase_phys,
- efx->type->mem_map_size);
- else
- efx->membase = ioremap_nocache(efx->membase_phys,
- efx->type->mem_map_size);
+ efx->membase = ioremap_nocache(efx->membase_phys,
+ efx->type->mem_map_size);
if (!efx->membase) {
netif_err(efx, probe, efx->net_dev,
"could not map memory BAR at %llx+%x\n",
diff --git a/drivers/net/sfc/io.h b/drivers/net/sfc/io.h
index cc97880..dc45110 100644
--- a/drivers/net/sfc/io.h
+++ b/drivers/net/sfc/io.h
@@ -48,9 +48,9 @@
* replacing the low 96 bits with zero does not affect functionality.
* - If the host writes to the last dword address of such a register
* (i.e. the high 32 bits) the underlying register will always be
- * written. If the collector and the current write together do not
- * provide values for all 128 bits of the register, the low 96 bits
- * will be written as zero.
+ * written. If the collector does not hold values for the low 96
+ * bits of the register, they will be written as zero. Writing to
+ * the last qword does not have this effect and must not be done.
* - If the host writes to the address of any other part of such a
* register while the collector already holds values for some other
* register, the write is discarded and the collector maintains its
@@ -103,7 +103,6 @@ static inline void efx_writeo(struct efx_nic *efx, efx_oword_t *value,
_efx_writed(efx, value->u32[2], reg + 8);
_efx_writed(efx, value->u32[3], reg + 12);
#endif
- wmb();
mmiowb();
spin_unlock_irqrestore(&efx->biu_lock, flags);
}
@@ -126,7 +125,6 @@ static inline void efx_sram_writeq(struct efx_nic *efx, void __iomem *membase,
__raw_writel((__force u32)value->u32[0], membase + addr);
__raw_writel((__force u32)value->u32[1], membase + addr + 4);
#endif
- wmb();
mmiowb();
spin_unlock_irqrestore(&efx->biu_lock, flags);
}
@@ -141,7 +139,6 @@ static inline void efx_writed(struct efx_nic *efx, efx_dword_t *value,
/* No lock required */
_efx_writed(efx, value->u32[0], reg);
- wmb();
}
/* Read a 128-bit CSR, locking as appropriate. */
@@ -152,7 +149,6 @@ static inline void efx_reado(struct efx_nic *efx, efx_oword_t *value,
spin_lock_irqsave(&efx->biu_lock, flags);
value->u32[0] = _efx_readd(efx, reg + 0);
- rmb();
value->u32[1] = _efx_readd(efx, reg + 4);
value->u32[2] = _efx_readd(efx, reg + 8);
value->u32[3] = _efx_readd(efx, reg + 12);
@@ -175,7 +171,6 @@ static inline void efx_sram_readq(struct efx_nic *efx, void __iomem *membase,
value->u64[0] = (__force __le64)__raw_readq(membase + addr);
#else
value->u32[0] = (__force __le32)__raw_readl(membase + addr);
- rmb();
value->u32[1] = (__force __le32)__raw_readl(membase + addr + 4);
#endif
spin_unlock_irqrestore(&efx->biu_lock, flags);
@@ -242,14 +237,12 @@ static inline void _efx_writeo_page(struct efx_nic *efx, efx_oword_t *value,
#ifdef EFX_USE_QWORD_IO
_efx_writeq(efx, value->u64[0], reg + 0);
- _efx_writeq(efx, value->u64[1], reg + 8);
#else
_efx_writed(efx, value->u32[0], reg + 0);
_efx_writed(efx, value->u32[1], reg + 4);
+#endif
_efx_writed(efx, value->u32[2], reg + 8);
_efx_writed(efx, value->u32[3], reg + 12);
-#endif
- wmb();
}
#define efx_writeo_page(efx, value, reg, page) \
_efx_writeo_page(efx, value, \
diff --git a/drivers/net/sfc/mcdi.c b/drivers/net/sfc/mcdi.c
index 3dd45ed..81a4253 100644
--- a/drivers/net/sfc/mcdi.c
+++ b/drivers/net/sfc/mcdi.c
@@ -50,20 +50,6 @@ static inline struct efx_mcdi_iface *efx_mcdi(struct efx_nic *efx)
return &nic_data->mcdi;
}
-static inline void
-efx_mcdi_readd(struct efx_nic *efx, efx_dword_t *value, unsigned reg)
-{
- struct siena_nic_data *nic_data = efx->nic_data;
- value->u32[0] = (__force __le32)__raw_readl(nic_data->mcdi_smem + reg);
-}
-
-static inline void
-efx_mcdi_writed(struct efx_nic *efx, const efx_dword_t *value, unsigned reg)
-{
- struct siena_nic_data *nic_data = efx->nic_data;
- __raw_writel((__force u32)value->u32[0], nic_data->mcdi_smem + reg);
-}
-
void efx_mcdi_init(struct efx_nic *efx)
{
struct efx_mcdi_iface *mcdi;
@@ -84,8 +70,8 @@ static void efx_mcdi_copyin(struct efx_nic *efx, unsigned cmd,
const u8 *inbuf, size_t inlen)
{
struct efx_mcdi_iface *mcdi = efx_mcdi(efx);
- unsigned pdu = MCDI_PDU(efx);
- unsigned doorbell = MCDI_DOORBELL(efx);
+ unsigned pdu = FR_CZ_MC_TREG_SMEM + MCDI_PDU(efx);
+ unsigned doorbell = FR_CZ_MC_TREG_SMEM + MCDI_DOORBELL(efx);
unsigned int i;
efx_dword_t hdr;
u32 xflags, seqno;
@@ -106,28 +92,29 @@ static void efx_mcdi_copyin(struct efx_nic *efx, unsigned cmd,
MCDI_HEADER_SEQ, seqno,
MCDI_HEADER_XFLAGS, xflags);
- efx_mcdi_writed(efx, &hdr, pdu);
+ efx_writed(efx, &hdr, pdu);
for (i = 0; i < inlen; i += 4)
- efx_mcdi_writed(efx, (const efx_dword_t *)(inbuf + i),
- pdu + 4 + i);
+ _efx_writed(efx, *((__le32 *)(inbuf + i)), pdu + 4 + i);
+
+ /* Ensure the payload is written out before the header */
+ wmb();
/* ring the doorbell with a distinctive value */
- EFX_POPULATE_DWORD_1(hdr, EFX_DWORD_0, 0x45789abc);
- efx_mcdi_writed(efx, &hdr, doorbell);
+ _efx_writed(efx, (__force __le32) 0x45789abc, doorbell);
}
static void efx_mcdi_copyout(struct efx_nic *efx, u8 *outbuf, size_t outlen)
{
struct efx_mcdi_iface *mcdi = efx_mcdi(efx);
- unsigned int pdu = MCDI_PDU(efx);
+ unsigned int pdu = FR_CZ_MC_TREG_SMEM + MCDI_PDU(efx);
int i;
BUG_ON(atomic_read(&mcdi->state) == MCDI_STATE_QUIESCENT);
BUG_ON(outlen & 3 || outlen >= 0x100);
for (i = 0; i < outlen; i += 4)
- efx_mcdi_readd(efx, (efx_dword_t *)(outbuf + i), pdu + 4 + i);
+ *((__le32 *)(outbuf + i)) = _efx_readd(efx, pdu + 4 + i);
}
static int efx_mcdi_poll(struct efx_nic *efx)
@@ -135,7 +122,7 @@ static int efx_mcdi_poll(struct efx_nic *efx)
struct efx_mcdi_iface *mcdi = efx_mcdi(efx);
unsigned int time, finish;
unsigned int respseq, respcmd, error;
- unsigned int pdu = MCDI_PDU(efx);
+ unsigned int pdu = FR_CZ_MC_TREG_SMEM + MCDI_PDU(efx);
unsigned int rc, spins;
efx_dword_t reg;
@@ -161,7 +148,8 @@ static int efx_mcdi_poll(struct efx_nic *efx)
time = get_seconds();
- efx_mcdi_readd(efx, ®, pdu);
+ rmb();
+ efx_readd(efx, ®, pdu);
/* All 1's indicates that shared memory is in reset (and is
* not a valid header). Wait for it to come out reset before
@@ -188,7 +176,7 @@ static int efx_mcdi_poll(struct efx_nic *efx)
respseq, mcdi->seqno);
rc = EIO;
} else if (error) {
- efx_mcdi_readd(efx, ®, pdu + 4);
+ efx_readd(efx, ®, pdu + 4);
switch (EFX_DWORD_FIELD(reg, EFX_DWORD_0)) {
#define TRANSLATE_ERROR(name) \
case MC_CMD_ERR_ ## name: \
@@ -222,21 +210,21 @@ out:
/* Test and clear MC-rebooted flag for this port/function */
int efx_mcdi_poll_reboot(struct efx_nic *efx)
{
- unsigned int addr = MCDI_REBOOT_FLAG(efx);
+ unsigned int addr = FR_CZ_MC_TREG_SMEM + MCDI_REBOOT_FLAG(efx);
efx_dword_t reg;
uint32_t value;
if (efx_nic_rev(efx) < EFX_REV_SIENA_A0)
return false;
- efx_mcdi_readd(efx, ®, addr);
+ efx_readd(efx, ®, addr);
value = EFX_DWORD_FIELD(reg, EFX_DWORD_0);
if (value == 0)
return 0;
EFX_ZERO_DWORD(reg);
- efx_mcdi_writed(efx, ®, addr);
+ efx_writed(efx, ®, addr);
if (value == MC_STATUS_DWORD_ASSERT)
return -EINTR;
diff --git a/drivers/net/sfc/nic.c b/drivers/net/sfc/nic.c
index bafa23a..3edfbaf 100644
--- a/drivers/net/sfc/nic.c
+++ b/drivers/net/sfc/nic.c
@@ -1936,13 +1936,6 @@ void efx_nic_get_regs(struct efx_nic *efx, void *buf)
size = min_t(size_t, table->step, 16);
- if (table->offset >= efx->type->mem_map_size) {
- /* No longer mapped; return dummy data */
- memcpy(buf, "\xde\xc0\xad\xde", 4);
- buf += table->rows * size;
- continue;
- }
-
for (i = 0; i < table->rows; i++) {
switch (table->step) {
case 4: /* 32-bit register or SRAM */
diff --git a/drivers/net/sfc/nic.h b/drivers/net/sfc/nic.h
index 4bd1f28..7443f99 100644
--- a/drivers/net/sfc/nic.h
+++ b/drivers/net/sfc/nic.h
@@ -143,12 +143,10 @@ static inline struct falcon_board *falcon_board(struct efx_nic *efx)
/**
* struct siena_nic_data - Siena NIC state
* @mcdi: Management-Controller-to-Driver Interface
- * @mcdi_smem: MCDI shared memory mapping. The mapping is always uncacheable.
* @wol_filter_id: Wake-on-LAN packet filter id
*/
struct siena_nic_data {
struct efx_mcdi_iface mcdi;
- void __iomem *mcdi_smem;
int wol_filter_id;
};
diff --git a/drivers/net/sfc/siena.c b/drivers/net/sfc/siena.c
index 5735e84..2c3bd93 100644
--- a/drivers/net/sfc/siena.c
+++ b/drivers/net/sfc/siena.c
@@ -250,26 +250,12 @@ static int siena_probe_nic(struct efx_nic *efx)
efx_reado(efx, ®, FR_AZ_CS_DEBUG);
efx->net_dev->dev_id = EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1;
- /* Initialise MCDI */
- nic_data->mcdi_smem = ioremap_nocache(efx->membase_phys +
- FR_CZ_MC_TREG_SMEM,
- FR_CZ_MC_TREG_SMEM_STEP *
- FR_CZ_MC_TREG_SMEM_ROWS);
- if (!nic_data->mcdi_smem) {
- netif_err(efx, probe, efx->net_dev,
- "could not map MCDI at %llx+%x\n",
- (unsigned long long)efx->membase_phys +
- FR_CZ_MC_TREG_SMEM,
- FR_CZ_MC_TREG_SMEM_STEP * FR_CZ_MC_TREG_SMEM_ROWS);
- rc = -ENOMEM;
- goto fail1;
- }
efx_mcdi_init(efx);
/* Recover from a failed assertion before probing */
rc = efx_mcdi_handle_assertion(efx);
if (rc)
- goto fail2;
+ goto fail1;
/* Let the BMC know that the driver is now in charge of link and
* filter settings. We must do this before we reset the NIC */
@@ -324,7 +310,6 @@ fail4:
fail3:
efx_mcdi_drv_attach(efx, false, NULL);
fail2:
- iounmap(nic_data->mcdi_smem);
fail1:
kfree(efx->nic_data);
return rc;
@@ -404,8 +389,6 @@ static int siena_init_nic(struct efx_nic *efx)
static void siena_remove_nic(struct efx_nic *efx)
{
- struct siena_nic_data *nic_data = efx->nic_data;
-
efx_nic_free_buffer(efx, &efx->irq_status);
siena_reset_hw(efx, RESET_TYPE_ALL);
@@ -415,8 +398,7 @@ static void siena_remove_nic(struct efx_nic *efx)
efx_mcdi_drv_attach(efx, false, NULL);
/* Tear down the private nic state */
- iounmap(nic_data->mcdi_smem);
- kfree(nic_data);
+ kfree(efx->nic_data);
efx->nic_data = NULL;
}
@@ -656,7 +638,8 @@ const struct efx_nic_type siena_a0_nic_type = {
.default_mac_ops = &efx_mcdi_mac_operations,
.revision = EFX_REV_SIENA_A0,
- .mem_map_size = FR_CZ_MC_TREG_SMEM, /* MC_TREG_SMEM mapped separately */
+ .mem_map_size = (FR_CZ_MC_TREG_SMEM +
+ FR_CZ_MC_TREG_SMEM_STEP * FR_CZ_MC_TREG_SMEM_ROWS),
.txd_ptr_tbl_base = FR_BZ_TX_DESC_PTR_TBL,
.rxd_ptr_tbl_base = FR_BZ_RX_DESC_PTR_TBL,
.buf_tbl_base = FR_BZ_BUF_FULL_TBL,
diff --git a/drivers/net/sfc/workarounds.h b/drivers/net/sfc/workarounds.h
index 99ff114..e4dd3a7 100644
--- a/drivers/net/sfc/workarounds.h
+++ b/drivers/net/sfc/workarounds.h
@@ -38,8 +38,6 @@
#define EFX_WORKAROUND_15783 EFX_WORKAROUND_ALWAYS
/* Legacy interrupt storm when interrupt fifo fills */
#define EFX_WORKAROUND_17213 EFX_WORKAROUND_SIENA
-/* Write combining and sriov=enabled are incompatible */
-#define EFX_WORKAROUND_22643 EFX_WORKAROUND_SIENA
/* Spurious parity errors in TSORT buffers */
#define EFX_WORKAROUND_5129 EFX_WORKAROUND_FALCON_A
--
1.7.4.4
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* Re: [PATCH] net: Prefer non link-local source addresses
From: Julian Anastasov @ 2011-09-01 22:14 UTC (permalink / raw)
To: Jeff Harris
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <1314908454-14359-1-git-send-email-jeff_harris@kentrox.com>
Hello,
On Thu, 1 Sep 2011, Jeff Harris wrote:
> Section 2.6.1 of RFC 3927 specifies that if link-local and routable addresses
> are available on an interface, a routable address is preferred. Update the
> IPv4 source address selection algorithm to use a 169.254.x.x address only if
> another matching address is not found.
>
> Tested combinations of configured IP addresses with and without link-local to
> verify a link-local address was chosen only if no routable address was
> present.
As David Lamparter already said, isn't the scope value
suitable for this purpose? Eg.
ip addr add 169.254.5.5/16 brd + dev eth0 scope link
iproute2 already has function default_scope() in
ip/ipaddress.c that assigns scope if it is not specified
while adding address. May be we can add RT_SCOPE_LINK for
169.254 there?
Another such place is inet_set_ifa() in
net/ipv4/devinet.c where we can assign scope, so that
ifconfig works too.
I see also that net/ipv6/addrconf.c (sit_add_v4_addrs)
avoids link-local addresses. What I mean is that the scope
can be checked at many places and it is a mechanism that
already works.
As result, we will not complicate inet_select_addr.
> Signed-off-by: Jeff Harris <jeff_harris@kentrox.com>
> ---
> net/ipv4/devinet.c | 18 ++++++++++++++++--
> 1 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
> index bc19bd0..70ddf37 100644
> --- a/net/ipv4/devinet.c
> +++ b/net/ipv4/devinet.c
> @@ -965,6 +965,8 @@ out:
> __be32 inet_select_addr(const struct net_device *dev, __be32 dst, int scope)
> {
> __be32 addr = 0;
> + __be32 lladdr = 0;
> + __be32 firstaddr = 0;
> struct in_device *in_dev;
> struct net *net = dev_net(dev);
>
> @@ -977,15 +979,27 @@ __be32 inet_select_addr(const struct net_device *dev, __be32 dst, int scope)
> if (ifa->ifa_scope > scope)
> continue;
> if (!dst || inet_ifa_match(dst, ifa)) {
> + if (ipv4_is_linklocal_169(ifa->ifa_address)) {
> + lladdr = ifa->ifa_local;
> + continue;
> + }
> addr = ifa->ifa_local;
> break;
> }
> - if (!addr)
> - addr = ifa->ifa_local;
> + if (!firstaddr)
> + firstaddr = ifa->ifa_local;
> } endfor_ifa(in_dev);
>
> if (addr)
> goto out_unlock;
> + if (lladdr) {
> + addr = lladdr;
> + goto out_unlock;
> + }
> + if (firstaddr) {
> + addr = firstaddr;
> + goto out_unlock;
> + }
> no_in_dev:
>
> /* Not loopback addresses on loopback should be preferred
> --
> 1.7.0.5
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* [PATCH net 2/2] sfc: Use 64-bit writes for TX push where possible
From: Ben Hutchings @ 2011-09-01 22:09 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
This was originally done as part of commit
65f0b417dee94f779ce9b77102b7d73c93723b39 ("sfc: Use write-combining to
reduce TX latency"), but that had to be reverted.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/sfc/io.h | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/sfc/io.h b/drivers/net/sfc/io.h
index dc45110..751d1ec 100644
--- a/drivers/net/sfc/io.h
+++ b/drivers/net/sfc/io.h
@@ -48,9 +48,9 @@
* replacing the low 96 bits with zero does not affect functionality.
* - If the host writes to the last dword address of such a register
* (i.e. the high 32 bits) the underlying register will always be
- * written. If the collector does not hold values for the low 96
- * bits of the register, they will be written as zero. Writing to
- * the last qword does not have this effect and must not be done.
+ * written. If the collector and the current write together do not
+ * provide values for all 128 bits of the register, the low 96 bits
+ * will be written as zero.
* - If the host writes to the address of any other part of such a
* register while the collector already holds values for some other
* register, the write is discarded and the collector maintains its
@@ -237,12 +237,13 @@ static inline void _efx_writeo_page(struct efx_nic *efx, efx_oword_t *value,
#ifdef EFX_USE_QWORD_IO
_efx_writeq(efx, value->u64[0], reg + 0);
+ _efx_writeq(efx, value->u64[1], reg + 8);
#else
_efx_writed(efx, value->u32[0], reg + 0);
_efx_writed(efx, value->u32[1], reg + 4);
-#endif
_efx_writed(efx, value->u32[2], reg + 8);
_efx_writed(efx, value->u32[3], reg + 12);
+#endif
}
#define efx_writeo_page(efx, value, reg, page) \
_efx_writeo_page(efx, value, \
--
1.7.4.4
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* Re: [PATCH] iPhone 4 Verizon CDMA USB Product ID add
From: David Miller @ 2011-09-01 22:10 UTC (permalink / raw)
To: kavansmith82-Re5JQEeQqe8AvxtiuMwx3w
Cc: gregkh-l3A5Bk7waGM, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1314914492-11542-1-git-send-email-kavansmith82-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Kavan Smith <kavansmith82-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Thu, 1 Sep 2011 15:01:32 -0700
> Add USB product ID for iPhone 4 CDMA Verizon
> Tested on at least 2 devices
>
> Signed-off-by: Kavan Smith <kavansmith82-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
I've seen your previous submission already, you don't need
to send this again.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Bugme-new] [Bug 42132] New: Support BCM5750M in tg3
From: Andrew Morton @ 2011-09-01 23:40 UTC (permalink / raw)
To: netdev, Matt Carlson; +Cc: bugme-daemon, Benjamin Li, Michael Chan, stack.box
In-Reply-To: <bug-42132-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Wed, 31 Aug 2011 18:18:40 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=42132
>
> Summary: Support BCM5750M in tg3
> Product: Drivers
> Version: 2.5
> Kernel Version: 3.0.3
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Network
> AssignedTo: drivers_network@kernel-bugs.osdl.org
> ReportedBy: stack.box@gmail.com
> Regression: Yes
>
>
> I have a notebook (HP TC4400) which has a BCM5750 ethernet card inside. The
> ouput of lspci is:
>
> 08:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5750M
> Gigabit Ethernet [14e4:167c]
>
> Commit 67b284d476bcb3d100e946da23d6cf9acfd0465c removed the support for this
> device.
>
67b284d476bcb3d100 says "These devices were never released to the public".
> I wish to have the support for this network card back again. Thanks!
oops ;)
^ permalink raw reply
* Re: [Bugme-new] [Bug 42132] New: Support BCM5750M in tg3
From: Francesco Piccinno @ 2011-09-02 0:02 UTC (permalink / raw)
To: Andrew Morton
Cc: netdev, Matt Carlson, bugme-daemon, Benjamin Li, Michael Chan
In-Reply-To: <20110901164011.baa9a8b8.akpm@linux-foundation.org>
I know but apparently my laptop was lucky enough :)
Any chance to have the support for this card back?
On Fri, Sep 2, 2011 at 1:40 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Wed, 31 Aug 2011 18:18:40 GMT
> bugzilla-daemon@bugzilla.kernel.org wrote:
>
>> https://bugzilla.kernel.org/show_bug.cgi?id=42132
>>
>> Summary: Support BCM5750M in tg3
>> Product: Drivers
>> Version: 2.5
>> Kernel Version: 3.0.3
>> Platform: All
>> OS/Version: Linux
>> Tree: Mainline
>> Status: NEW
>> Severity: normal
>> Priority: P1
>> Component: Network
>> AssignedTo: drivers_network@kernel-bugs.osdl.org
>> ReportedBy: stack.box@gmail.com
>> Regression: Yes
>>
>>
>> I have a notebook (HP TC4400) which has a BCM5750 ethernet card inside. The
>> ouput of lspci is:
>>
>> 08:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5750M
>> Gigabit Ethernet [14e4:167c]
>>
>> Commit 67b284d476bcb3d100e946da23d6cf9acfd0465c removed the support for this
>> device.
>>
>
> 67b284d476bcb3d100 says "These devices were never released to the public".
>
>> I wish to have the support for this network card back again. Thanks!
>
> oops ;)
>
^ permalink raw reply
* Re: [Bugme-new] [Bug 42132] New: Support BCM5750M in tg3
From: Matt Carlson @ 2011-09-02 0:06 UTC (permalink / raw)
To: Andrew Morton
Cc: netdev@vger.kernel.org, Matthew Carlson,
bugme-daemon@bugzilla.kernel.org, Benjamin Li, Michael Chan,
stack.box@gmail.com
In-Reply-To: <20110901164011.baa9a8b8.akpm@linux-foundation.org>
On Thu, Sep 01, 2011 at 04:40:11PM -0700, Andrew Morton wrote:
>
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Wed, 31 Aug 2011 18:18:40 GMT
> bugzilla-daemon@bugzilla.kernel.org wrote:
>
> > https://bugzilla.kernel.org/show_bug.cgi?id=42132
> >
> > Summary: Support BCM5750M in tg3
> > Product: Drivers
> > Version: 2.5
> > Kernel Version: 3.0.3
> > Platform: All
> > OS/Version: Linux
> > Tree: Mainline
> > Status: NEW
> > Severity: normal
> > Priority: P1
> > Component: Network
> > AssignedTo: drivers_network@kernel-bugs.osdl.org
> > ReportedBy: stack.box@gmail.com
> > Regression: Yes
> >
> >
> > I have a notebook (HP TC4400) which has a BCM5750 ethernet card inside. The
> > ouput of lspci is:
> >
> > 08:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5750M
> > Gigabit Ethernet [14e4:167c]
> >
> > Commit 67b284d476bcb3d100e946da23d6cf9acfd0465c removed the support for this
> > device.
> >
>
> 67b284d476bcb3d100 says "These devices were never released to the public".
>
> > I wish to have the support for this network card back again. Thanks!
>
> oops ;)
Really? All the TC4400 documentation I find says it uses a bcm5753M on a
PCIe bus. Can you post the full output of 'lspci -vvv -s 08:00.0' ?
^ permalink raw reply
* Re: interface information for recvd packet
From: Viral Mehta @ 2011-09-02 0:07 UTC (permalink / raw)
To: netdev
In-Reply-To: <CANX6Dan5bdA-3wSiyAaQmOV6DHArxjknUFpR-s8coA9Yjx2N8A@mail.gmail.com>
Hi,
On Thu, Sep 1, 2011 at 3:40 PM, Viral Mehta <viral.vkm@gmail.com> wrote:
> On Tue, Aug 30, 2011 at 11:55 AM, Viral Mehta <viral.vkm@gmail.com> wrote:
>> 2. I was looking at net/ipv4/tcp.c and in function tcp_recvmsg(); I am
>> trying to get interface name by accessing sk_buff->dev->name
>
> I tried printing address of SKBs, but it gives different address in
> NIC driver and tcp.c
> My understanding is, struct sk_buff* remains same through out all
> layers i.e., NIC driver allocates it after receving frame
> and same is passed till TCP layer. But, apparently looks I am wrong
> from the prints that I have put.
>
> Can someone shed some light ?
>
Sorry for the noise. Also I got why nobody replied to my question :-)
Anyway, I was doing silly mistake while debugging the things; my
printks were at wrong place.
And everything works as expected and as per my understanding....
^ permalink raw reply
* [PATCH 1/3] pch_gbe: fixed the issue which receives an unnecessary packet.
From: Toshiharu Okada @ 2011-09-02 0:20 UTC (permalink / raw)
To: netdev, linux-kernel, eric.dumazet, davem
Cc: qi.wang, yong.y.wang, joel.clark, kok.howg.ewe, tomoya-linux,
Toshiharu Okada
This patch fixed the issue which receives an unnecessary packet before link
When using PHY of GMII, an unnecessary packet is received,
And it becomes impossible to receive a packet after link up.
Signed-off-by: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
---
drivers/net/pch_gbe/pch_gbe_main.c | 21 ++++++++++++++-------
1 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/net/pch_gbe/pch_gbe_main.c b/drivers/net/pch_gbe/pch_gbe_main.c
index eac3c5c..48ff87c 100644
--- a/drivers/net/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/pch_gbe/pch_gbe_main.c
@@ -717,13 +717,6 @@ static void pch_gbe_configure_rx(struct pch_gbe_adapter *adapter)
iowrite32(rdba, &hw->reg->RX_DSC_BASE);
iowrite32(rdlen, &hw->reg->RX_DSC_SIZE);
iowrite32((rdba + rdlen), &hw->reg->RX_DSC_SW_P);
-
- /* Enables Receive DMA */
- rxdma = ioread32(&hw->reg->DMA_CTRL);
- rxdma |= PCH_GBE_RX_DMA_EN;
- iowrite32(rxdma, &hw->reg->DMA_CTRL);
- /* Enables Receive */
- iowrite32(PCH_GBE_MRE_MAC_RX_EN, &hw->reg->MAC_RX_EN);
}
/**
@@ -1097,6 +1090,19 @@ void pch_gbe_update_stats(struct pch_gbe_adapter *adapter)
spin_unlock_irqrestore(&adapter->stats_lock, flags);
}
+static void pch_gbe_start_receive(struct pch_gbe_hw *hw)
+{
+ u32 rxdma;
+
+ /* Enables Receive DMA */
+ rxdma = ioread32(&hw->reg->DMA_CTRL);
+ rxdma |= PCH_GBE_RX_DMA_EN;
+ iowrite32(rxdma, &hw->reg->DMA_CTRL);
+ /* Enables Receive */
+ iowrite32(PCH_GBE_MRE_MAC_RX_EN, &hw->reg->MAC_RX_EN);
+ return;
+}
+
/**
* pch_gbe_intr - Interrupt Handler
* @irq: Interrupt number
@@ -1717,6 +1723,7 @@ int pch_gbe_up(struct pch_gbe_adapter *adapter)
pch_gbe_alloc_tx_buffers(adapter, tx_ring);
pch_gbe_alloc_rx_buffers(adapter, rx_ring, rx_ring->count);
adapter->tx_queue_len = netdev->tx_queue_len;
+ pch_gbe_start_receive(&adapter->hw);
mod_timer(&adapter->watchdog_timer, jiffies);
--
1.7.4.4
^ permalink raw reply related
* [PATCH 3/3] pch_gbe: support ML7831 IOH
From: Toshiharu Okada @ 2011-09-02 0:20 UTC (permalink / raw)
To: netdev, linux-kernel, eric.dumazet, davem
Cc: qi.wang, yong.y.wang, joel.clark, kok.howg.ewe, tomoya-linux,
Toshiharu Okada
In-Reply-To: <1314922809-4041-1-git-send-email-toshiharu-linux@dsn.okisemi.com>
Support new device OKI SEMICONDUCTOR ML7831 IOH(Input/Output Hub)
ML7831 is for general purpose use.
ML7831 is companion chip for Intel Atom E6xx series.
ML7831 is completely compatible for Intel EG20T PCH.
Signed-off-by: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
---
drivers/net/Kconfig | 11 ++++++-----
drivers/net/pch_gbe/pch_gbe_main.c | 10 ++++++++++
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 8d0314d..a44874e 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2535,7 +2535,7 @@ config S6GMAC
source "drivers/net/stmmac/Kconfig"
config PCH_GBE
- tristate "Intel EG20T PCH / OKI SEMICONDUCTOR ML7223 IOH GbE"
+ tristate "Intel EG20T PCH/OKI SEMICONDUCTOR IOH(ML7223/ML7831) GbE"
depends on PCI
select MII
---help---
@@ -2548,10 +2548,11 @@ config PCH_GBE
This driver enables Gigabit Ethernet function.
This driver also can be used for OKI SEMICONDUCTOR IOH(Input/
- Output Hub), ML7223.
- ML7223 IOH is for MP(Media Phone) use.
- ML7223 is companion chip for Intel Atom E6xx series.
- ML7223 is completely compatible for Intel EG20T PCH.
+ Output Hub), ML7223/ML7831.
+ ML7223 IOH is for MP(Media Phone) use. ML7831 IOH is for general
+ purpose use.
+ ML7223/ML7831 is companion chip for Intel Atom E6xx series.
+ ML7223/ML7831 is completely compatible for Intel EG20T PCH.
config FTGMAC100
tristate "Faraday FTGMAC100 Gigabit Ethernet support"
diff --git a/drivers/net/pch_gbe/pch_gbe_main.c b/drivers/net/pch_gbe/pch_gbe_main.c
index 39ce0ee..567ff10 100644
--- a/drivers/net/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/pch_gbe/pch_gbe_main.c
@@ -39,6 +39,9 @@ const char pch_driver_version[] = DRV_VERSION;
#define PCI_VENDOR_ID_ROHM 0x10db
#define PCI_DEVICE_ID_ROHM_ML7223_GBE 0x8013
+/* Macros for ML7831 */
+#define PCI_DEVICE_ID_ROHM_ML7831_GBE 0x8802
+
#define PCH_GBE_TX_WEIGHT 64
#define PCH_GBE_RX_WEIGHT 64
#define PCH_GBE_RX_BUFFER_WRITE 16
@@ -2526,6 +2529,13 @@ static DEFINE_PCI_DEVICE_TABLE(pch_gbe_pcidev_id) = {
.class = (PCI_CLASS_NETWORK_ETHERNET << 8),
.class_mask = (0xFFFF00)
},
+ {.vendor = PCI_VENDOR_ID_ROHM,
+ .device = PCI_DEVICE_ID_ROHM_ML7831_GBE,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_ANY_ID,
+ .class = (PCI_CLASS_NETWORK_ETHERNET << 8),
+ .class_mask = (0xFFFF00)
+ },
/* required last entry */
{0}
};
--
1.7.4.4
^ permalink raw reply related
* [PATCH 2/3] pch_gbe: added the process of FIFO over run error
From: Toshiharu Okada @ 2011-09-02 0:20 UTC (permalink / raw)
To: netdev, linux-kernel, eric.dumazet, davem
Cc: qi.wang, yong.y.wang, joel.clark, kok.howg.ewe, tomoya-linux,
Toshiharu Okada
In-Reply-To: <1314922809-4041-1-git-send-email-toshiharu-linux@dsn.okisemi.com>
This patch added the processing which should be done to hardware,
when a FIFO over run error occurred.
Signed-off-by: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
---
drivers/net/pch_gbe/pch_gbe.h | 12 ++-
drivers/net/pch_gbe/pch_gbe_main.c | 273 ++++++++++++++++++++++--------------
2 files changed, 180 insertions(+), 105 deletions(-)
diff --git a/drivers/net/pch_gbe/pch_gbe.h b/drivers/net/pch_gbe/pch_gbe.h
index 59fac77..a09a071 100644
--- a/drivers/net/pch_gbe/pch_gbe.h
+++ b/drivers/net/pch_gbe/pch_gbe.h
@@ -127,8 +127,8 @@ struct pch_gbe_regs {
/* Reset */
#define PCH_GBE_ALL_RST 0x80000000 /* All reset */
-#define PCH_GBE_TX_RST 0x40000000 /* TX MAC, TX FIFO, TX DMA reset */
-#define PCH_GBE_RX_RST 0x04000000 /* RX MAC, RX FIFO, RX DMA reset */
+#define PCH_GBE_TX_RST 0x00008000 /* TX MAC, TX FIFO, TX DMA reset */
+#define PCH_GBE_RX_RST 0x00004000 /* RX MAC, RX FIFO, RX DMA reset */
/* TCP/IP Accelerator Control */
#define PCH_GBE_EX_LIST_EN 0x00000008 /* External List Enable */
@@ -276,6 +276,9 @@ struct pch_gbe_regs {
#define PCH_GBE_RX_DMA_EN 0x00000002 /* Enables Receive DMA */
#define PCH_GBE_TX_DMA_EN 0x00000001 /* Enables Transmission DMA */
+/* RX DMA STATUS */
+#define PCH_GBE_IDLE_CHECK 0xFFFFFFFE
+
/* Wake On LAN Status */
#define PCH_GBE_WLS_BR 0x00000008 /* Broadcas Address */
#define PCH_GBE_WLS_MLT 0x00000004 /* Multicast Address */
@@ -471,6 +474,7 @@ struct pch_gbe_tx_desc {
struct pch_gbe_buffer {
struct sk_buff *skb;
dma_addr_t dma;
+ unsigned char *rx_buffer;
unsigned long time_stamp;
u16 length;
bool mapped;
@@ -511,6 +515,9 @@ struct pch_gbe_tx_ring {
struct pch_gbe_rx_ring {
struct pch_gbe_rx_desc *desc;
dma_addr_t dma;
+ unsigned char *rx_buff_pool;
+ dma_addr_t rx_buff_pool_logic;
+ unsigned int rx_buff_pool_size;
unsigned int size;
unsigned int count;
unsigned int next_to_use;
@@ -622,6 +629,7 @@ struct pch_gbe_adapter {
unsigned long rx_buffer_len;
unsigned long tx_queue_len;
bool have_msi;
+ bool rx_stop_flag;
};
extern const char pch_driver_version[];
diff --git a/drivers/net/pch_gbe/pch_gbe_main.c b/drivers/net/pch_gbe/pch_gbe_main.c
index 48ff87c..39ce0ee 100644
--- a/drivers/net/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/pch_gbe/pch_gbe_main.c
@@ -20,7 +20,6 @@
#include "pch_gbe.h"
#include "pch_gbe_api.h"
-#include <linux/prefetch.h>
#define DRV_VERSION "1.00"
const char pch_driver_version[] = DRV_VERSION;
@@ -34,6 +33,7 @@ const char pch_driver_version[] = DRV_VERSION;
#define PCH_GBE_WATCHDOG_PERIOD (1 * HZ) /* watchdog time */
#define PCH_GBE_COPYBREAK_DEFAULT 256
#define PCH_GBE_PCI_BAR 1
+#define PCH_GBE_RESERVE_MEMORY 0x200000 /* 2MB */
/* Macros for ML7223 */
#define PCI_VENDOR_ID_ROHM 0x10db
@@ -52,6 +52,7 @@ const char pch_driver_version[] = DRV_VERSION;
)
/* Ethertype field values */
+#define PCH_GBE_MAX_RX_BUFFER_SIZE 0x2880
#define PCH_GBE_MAX_JUMBO_FRAME_SIZE 10318
#define PCH_GBE_FRAME_SIZE_2048 2048
#define PCH_GBE_FRAME_SIZE_4096 4096
@@ -83,10 +84,12 @@ const char pch_driver_version[] = DRV_VERSION;
#define PCH_GBE_INT_ENABLE_MASK ( \
PCH_GBE_INT_RX_DMA_CMPLT | \
PCH_GBE_INT_RX_DSC_EMP | \
+ PCH_GBE_INT_RX_FIFO_ERR | \
PCH_GBE_INT_WOL_DET | \
PCH_GBE_INT_TX_CMPLT \
)
+#define PCH_GBE_INT_DISABLE_ALL 0
static unsigned int copybreak __read_mostly = PCH_GBE_COPYBREAK_DEFAULT;
@@ -138,6 +141,27 @@ static void pch_gbe_wait_clr_bit(void *reg, u32 bit)
if (!tmp)
pr_err("Error: busy bit is not cleared\n");
}
+
+/**
+ * pch_gbe_wait_clr_bit_irq - Wait to clear a bit for interrupt context
+ * @reg: Pointer of register
+ * @busy: Busy bit
+ */
+static int pch_gbe_wait_clr_bit_irq(void *reg, u32 bit)
+{
+ u32 tmp;
+ int ret = -1;
+ /* wait busy */
+ tmp = 20;
+ while ((ioread32(reg) & bit) && --tmp)
+ udelay(5);
+ if (!tmp)
+ pr_err("Error: busy bit is not cleared\n");
+ else
+ ret = 0;
+ return ret;
+}
+
/**
* pch_gbe_mac_mar_set - Set MAC address register
* @hw: Pointer to the HW structure
@@ -189,6 +213,17 @@ static void pch_gbe_mac_reset_hw(struct pch_gbe_hw *hw)
return;
}
+static void pch_gbe_mac_reset_rx(struct pch_gbe_hw *hw)
+{
+ /* Read the MAC address. and store to the private data */
+ pch_gbe_mac_read_mac_addr(hw);
+ iowrite32(PCH_GBE_RX_RST, &hw->reg->RESET);
+ pch_gbe_wait_clr_bit_irq(&hw->reg->RESET, PCH_GBE_RX_RST);
+ /* Setup the MAC address */
+ pch_gbe_mac_mar_set(hw, hw->mac.addr, 0);
+ return;
+}
+
/**
* pch_gbe_mac_init_rx_addrs - Initialize receive address's
* @hw: Pointer to the HW structure
@@ -671,13 +706,8 @@ static void pch_gbe_setup_rctl(struct pch_gbe_adapter *adapter)
tcpip = ioread32(&hw->reg->TCPIP_ACC);
- if (netdev->features & NETIF_F_RXCSUM) {
- tcpip &= ~PCH_GBE_RX_TCPIPACC_OFF;
- tcpip |= PCH_GBE_RX_TCPIPACC_EN;
- } else {
- tcpip |= PCH_GBE_RX_TCPIPACC_OFF;
- tcpip &= ~PCH_GBE_RX_TCPIPACC_EN;
- }
+ tcpip |= PCH_GBE_RX_TCPIPACC_OFF;
+ tcpip &= ~PCH_GBE_RX_TCPIPACC_EN;
iowrite32(tcpip, &hw->reg->TCPIP_ACC);
return;
}
@@ -1090,6 +1120,35 @@ void pch_gbe_update_stats(struct pch_gbe_adapter *adapter)
spin_unlock_irqrestore(&adapter->stats_lock, flags);
}
+static void pch_gbe_stop_receive(struct pch_gbe_adapter *adapter)
+{
+ struct pch_gbe_hw *hw = &adapter->hw;
+ u32 rxdma;
+ u16 value;
+ int ret;
+
+ /* Disable Receive DMA */
+ rxdma = ioread32(&hw->reg->DMA_CTRL);
+ rxdma &= ~PCH_GBE_RX_DMA_EN;
+ iowrite32(rxdma, &hw->reg->DMA_CTRL);
+ /* Wait Rx DMA BUS is IDLE */
+ ret = pch_gbe_wait_clr_bit_irq(&hw->reg->RX_DMA_ST, PCH_GBE_IDLE_CHECK);
+ if (ret) {
+ /* Disable Bus master */
+ pci_read_config_word(adapter->pdev, PCI_COMMAND, &value);
+ value &= ~PCI_COMMAND_MASTER;
+ pci_write_config_word(adapter->pdev, PCI_COMMAND, value);
+ /* Stop Receive */
+ pch_gbe_mac_reset_rx(hw);
+ /* Enable Bus master */
+ value |= PCI_COMMAND_MASTER;
+ pci_write_config_word(adapter->pdev, PCI_COMMAND, value);
+ } else {
+ /* Stop Receive */
+ pch_gbe_mac_reset_rx(hw);
+ }
+}
+
static void pch_gbe_start_receive(struct pch_gbe_hw *hw)
{
u32 rxdma;
@@ -1129,7 +1188,15 @@ static irqreturn_t pch_gbe_intr(int irq, void *data)
if (int_st & PCH_GBE_INT_RX_FRAME_ERR)
adapter->stats.intr_rx_frame_err_count++;
if (int_st & PCH_GBE_INT_RX_FIFO_ERR)
- adapter->stats.intr_rx_fifo_err_count++;
+ if (!adapter->rx_stop_flag) {
+ adapter->stats.intr_rx_fifo_err_count++;
+ pr_debug("Rx fifo over run\n");
+ adapter->rx_stop_flag = true;
+ int_en = ioread32(&hw->reg->INT_EN);
+ iowrite32((int_en & ~PCH_GBE_INT_RX_FIFO_ERR),
+ &hw->reg->INT_EN);
+ pch_gbe_stop_receive(adapter);
+ }
if (int_st & PCH_GBE_INT_RX_DMA_ERR)
adapter->stats.intr_rx_dma_err_count++;
if (int_st & PCH_GBE_INT_TX_FIFO_ERR)
@@ -1141,7 +1208,7 @@ static irqreturn_t pch_gbe_intr(int irq, void *data)
/* When Rx descriptor is empty */
if ((int_st & PCH_GBE_INT_RX_DSC_EMP)) {
adapter->stats.intr_rx_dsc_empty_count++;
- pr_err("Rx descriptor is empty\n");
+ pr_debug("Rx descriptor is empty\n");
int_en = ioread32(&hw->reg->INT_EN);
iowrite32((int_en & ~PCH_GBE_INT_RX_DSC_EMP), &hw->reg->INT_EN);
if (hw->mac.tx_fc_enable) {
@@ -1191,29 +1258,23 @@ pch_gbe_alloc_rx_buffers(struct pch_gbe_adapter *adapter,
unsigned int i;
unsigned int bufsz;
- bufsz = adapter->rx_buffer_len + PCH_GBE_DMA_ALIGN;
+ bufsz = adapter->rx_buffer_len + NET_IP_ALIGN;
i = rx_ring->next_to_use;
while ((cleaned_count--)) {
buffer_info = &rx_ring->buffer_info[i];
- skb = buffer_info->skb;
- if (skb) {
- skb_trim(skb, 0);
- } else {
- skb = netdev_alloc_skb(netdev, bufsz);
- if (unlikely(!skb)) {
- /* Better luck next round */
- adapter->stats.rx_alloc_buff_failed++;
- break;
- }
- /* 64byte align */
- skb_reserve(skb, PCH_GBE_DMA_ALIGN);
-
- buffer_info->skb = skb;
- buffer_info->length = adapter->rx_buffer_len;
+ skb = netdev_alloc_skb(netdev, bufsz);
+ if (unlikely(!skb)) {
+ /* Better luck next round */
+ adapter->stats.rx_alloc_buff_failed++;
+ break;
}
+ /* align */
+ skb_reserve(skb, NET_IP_ALIGN);
+ buffer_info->skb = skb;
+
buffer_info->dma = dma_map_single(&pdev->dev,
- skb->data,
+ buffer_info->rx_buffer,
buffer_info->length,
DMA_FROM_DEVICE);
if (dma_mapping_error(&adapter->pdev->dev, buffer_info->dma)) {
@@ -1246,6 +1307,36 @@ pch_gbe_alloc_rx_buffers(struct pch_gbe_adapter *adapter,
return;
}
+static int
+pch_gbe_alloc_rx_buffers_pool(struct pch_gbe_adapter *adapter,
+ struct pch_gbe_rx_ring *rx_ring, int cleaned_count)
+{
+ struct pci_dev *pdev = adapter->pdev;
+ struct pch_gbe_buffer *buffer_info;
+ unsigned int i;
+ unsigned int bufsz;
+ unsigned int size;
+
+ bufsz = adapter->rx_buffer_len;
+
+ size = rx_ring->count * bufsz + PCH_GBE_RESERVE_MEMORY;
+ rx_ring->rx_buff_pool = dma_alloc_coherent(&pdev->dev, size,
+ &rx_ring->rx_buff_pool_logic,
+ GFP_KERNEL);
+ if (!rx_ring->rx_buff_pool) {
+ pr_err("Unable to allocate memory for the receive poll buffer\n");
+ return -ENOMEM;
+ }
+ memset(rx_ring->rx_buff_pool, 0, size);
+ rx_ring->rx_buff_pool_size = size;
+ for (i = 0; i < rx_ring->count; i++) {
+ buffer_info = &rx_ring->buffer_info[i];
+ buffer_info->rx_buffer = rx_ring->rx_buff_pool + bufsz * i;
+ buffer_info->length = bufsz;
+ }
+ return 0;
+}
+
/**
* pch_gbe_alloc_tx_buffers - Allocate transmit buffers
* @adapter: Board private structure
@@ -1386,7 +1477,7 @@ pch_gbe_clean_rx(struct pch_gbe_adapter *adapter,
unsigned int i;
unsigned int cleaned_count = 0;
bool cleaned = false;
- struct sk_buff *skb, *new_skb;
+ struct sk_buff *skb;
u8 dma_status;
u16 gbec_status;
u32 tcp_ip_status;
@@ -1407,13 +1498,12 @@ pch_gbe_clean_rx(struct pch_gbe_adapter *adapter,
rx_desc->gbec_status = DSC_INIT16;
buffer_info = &rx_ring->buffer_info[i];
skb = buffer_info->skb;
+ buffer_info->skb = NULL;
/* unmap dma */
dma_unmap_single(&pdev->dev, buffer_info->dma,
buffer_info->length, DMA_FROM_DEVICE);
buffer_info->mapped = false;
- /* Prefetch the packet */
- prefetch(skb->data);
pr_debug("RxDecNo = 0x%04x Status[DMA:0x%02x GBE:0x%04x "
"TCP:0x%08x] BufInf = 0x%p\n",
@@ -1433,70 +1523,16 @@ pch_gbe_clean_rx(struct pch_gbe_adapter *adapter,
pr_err("Receive CRC Error\n");
} else {
/* get receive length */
- /* length convert[-3] */
- length = (rx_desc->rx_words_eob) - 3;
-
- /* Decide the data conversion method */
- if (!(netdev->features & NETIF_F_RXCSUM)) {
- /* [Header:14][payload] */
- if (NET_IP_ALIGN) {
- /* Because alignment differs,
- * the new_skb is newly allocated,
- * and data is copied to new_skb.*/
- new_skb = netdev_alloc_skb(netdev,
- length + NET_IP_ALIGN);
- if (!new_skb) {
- /* dorrop error */
- pr_err("New skb allocation "
- "Error\n");
- goto dorrop;
- }
- skb_reserve(new_skb, NET_IP_ALIGN);
- memcpy(new_skb->data, skb->data,
- length);
- skb = new_skb;
- } else {
- /* DMA buffer is used as SKB as it is.*/
- buffer_info->skb = NULL;
- }
- } else {
- /* [Header:14][padding:2][payload] */
- /* The length includes padding length */
- length = length - PCH_GBE_DMA_PADDING;
- if ((length < copybreak) ||
- (NET_IP_ALIGN != PCH_GBE_DMA_PADDING)) {
- /* Because alignment differs,
- * the new_skb is newly allocated,
- * and data is copied to new_skb.
- * Padding data is deleted
- * at the time of a copy.*/
- new_skb = netdev_alloc_skb(netdev,
- length + NET_IP_ALIGN);
- if (!new_skb) {
- /* dorrop error */
- pr_err("New skb allocation "
- "Error\n");
- goto dorrop;
- }
- skb_reserve(new_skb, NET_IP_ALIGN);
- memcpy(new_skb->data, skb->data,
- ETH_HLEN);
- memcpy(&new_skb->data[ETH_HLEN],
- &skb->data[ETH_HLEN +
- PCH_GBE_DMA_PADDING],
- length - ETH_HLEN);
- skb = new_skb;
- } else {
- /* Padding data is deleted
- * by moving header data.*/
- memmove(&skb->data[PCH_GBE_DMA_PADDING],
- &skb->data[0], ETH_HLEN);
- skb_reserve(skb, NET_IP_ALIGN);
- buffer_info->skb = NULL;
- }
- }
- /* The length includes FCS length */
- length = length - ETH_FCS_LEN;
+ /* length convert[-3], length includes FCS length */
+ length = (rx_desc->rx_words_eob) - 3 - ETH_FCS_LEN;
+ if (rx_desc->rx_words_eob & 0x02)
+ length = length - 4;
+ /*
+ * buffer_info->rx_buffer: [Header:14][payload]
+ * skb->data: [Reserve:2][Header:14][payload]
+ */
+ memcpy(skb->data, buffer_info->rx_buffer, length);
+
/* update status of driver */
adapter->stats.rx_bytes += length;
adapter->stats.rx_packets++;
@@ -1515,7 +1551,6 @@ pch_gbe_clean_rx(struct pch_gbe_adapter *adapter,
pr_debug("Receive skb->ip_summed: %d length: %d\n",
skb->ip_summed, length);
}
-dorrop:
/* return some buffers to hardware, one at a time is too slow */
if (unlikely(cleaned_count >= PCH_GBE_RX_BUFFER_WRITE)) {
pch_gbe_alloc_rx_buffers(adapter, rx_ring,
@@ -1720,6 +1755,11 @@ int pch_gbe_up(struct pch_gbe_adapter *adapter)
pr_err("Error: can't bring device up\n");
return err;
}
+ err = pch_gbe_alloc_rx_buffers_pool(adapter, rx_ring, rx_ring->count);
+ if (err) {
+ pr_err("Error: can't bring device up\n");
+ return err;
+ }
pch_gbe_alloc_tx_buffers(adapter, tx_ring);
pch_gbe_alloc_rx_buffers(adapter, rx_ring, rx_ring->count);
adapter->tx_queue_len = netdev->tx_queue_len;
@@ -1741,6 +1781,7 @@ int pch_gbe_up(struct pch_gbe_adapter *adapter)
void pch_gbe_down(struct pch_gbe_adapter *adapter)
{
struct net_device *netdev = adapter->netdev;
+ struct pch_gbe_rx_ring *rx_ring = adapter->rx_ring;
/* signal that we're down so the interrupt handler does not
* reschedule our watchdog timer */
@@ -1759,6 +1800,12 @@ void pch_gbe_down(struct pch_gbe_adapter *adapter)
pch_gbe_reset(adapter);
pch_gbe_clean_tx_ring(adapter, adapter->tx_ring);
pch_gbe_clean_rx_ring(adapter, adapter->rx_ring);
+
+ pci_free_consistent(adapter->pdev, rx_ring->rx_buff_pool_size,
+ rx_ring->rx_buff_pool, rx_ring->rx_buff_pool_logic);
+ rx_ring->rx_buff_pool_logic = 0;
+ rx_ring->rx_buff_pool_size = 0;
+ rx_ring->rx_buff_pool = NULL;
}
/**
@@ -2011,6 +2058,8 @@ static int pch_gbe_change_mtu(struct net_device *netdev, int new_mtu)
{
struct pch_gbe_adapter *adapter = netdev_priv(netdev);
int max_frame;
+ unsigned long old_rx_buffer_len = adapter->rx_buffer_len;
+ int err;
max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
if ((max_frame < ETH_ZLEN + ETH_FCS_LEN) ||
@@ -2025,14 +2074,24 @@ static int pch_gbe_change_mtu(struct net_device *netdev, int new_mtu)
else if (max_frame <= PCH_GBE_FRAME_SIZE_8192)
adapter->rx_buffer_len = PCH_GBE_FRAME_SIZE_8192;
else
- adapter->rx_buffer_len = PCH_GBE_MAX_JUMBO_FRAME_SIZE;
- netdev->mtu = new_mtu;
- adapter->hw.mac.max_frame_size = max_frame;
+ adapter->rx_buffer_len = PCH_GBE_MAX_RX_BUFFER_SIZE;
- if (netif_running(netdev))
- pch_gbe_reinit_locked(adapter);
- else
+ if (netif_running(netdev)) {
+ pch_gbe_down(adapter);
+ err = pch_gbe_up(adapter);
+ if (err) {
+ adapter->rx_buffer_len = old_rx_buffer_len;
+ pch_gbe_up(adapter);
+ return -ENOMEM;
+ } else {
+ netdev->mtu = new_mtu;
+ adapter->hw.mac.max_frame_size = max_frame;
+ }
+ } else {
pch_gbe_reset(adapter);
+ netdev->mtu = new_mtu;
+ adapter->hw.mac.max_frame_size = max_frame;
+ }
pr_debug("max_frame : %d rx_buffer_len : %d mtu : %d max_frame_size : %d\n",
max_frame, (u32) adapter->rx_buffer_len, netdev->mtu,
@@ -2110,6 +2169,7 @@ static int pch_gbe_napi_poll(struct napi_struct *napi, int budget)
int work_done = 0;
bool poll_end_flag = false;
bool cleaned = false;
+ u32 int_en;
pr_debug("budget : %d\n", budget);
@@ -2117,8 +2177,15 @@ static int pch_gbe_napi_poll(struct napi_struct *napi, int budget)
if (!netif_carrier_ok(netdev)) {
poll_end_flag = true;
} else {
- cleaned = pch_gbe_clean_tx(adapter, adapter->tx_ring);
pch_gbe_clean_rx(adapter, adapter->rx_ring, &work_done, budget);
+ if (adapter->rx_stop_flag) {
+ adapter->rx_stop_flag = false;
+ pch_gbe_start_receive(&adapter->hw);
+ int_en = ioread32(&adapter->hw.reg->INT_EN);
+ iowrite32((int_en | PCH_GBE_INT_RX_FIFO_ERR),
+ &adapter->hw.reg->INT_EN);
+ }
+ cleaned = pch_gbe_clean_tx(adapter, adapter->tx_ring);
if (cleaned)
work_done = budget;
--
1.7.4.4
^ permalink raw reply related
* Re: [next] unix stream crashes
From: Valdis.Kletnieks @ 2011-09-02 0:49 UTC (permalink / raw)
To: Jiri Slaby; +Cc: tim.c.chen, David S. Miller, ML netdev, LKML
In-Reply-To: <4E5FEF28.60406@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 714 bytes --]
On Thu, 01 Sep 2011 22:46:32 +0200, Jiri Slaby said:
> Hi,
>
> my box 100% crashes when booting. It's both in unix socket recv and send
> paths. I've reverted 0856a30409 (Scm: Remove unnecessary pid &
> credential references in Unix socket's send and receive path) and it
> seems to help.
>
> The oops:
> http://www.fi.muni.cz/~xslaby/sklad/panics/af_unix_crash.png
I was seeing a 100% repeatable crash with the X server starting as well, but
wasn't able to get a traceback because my X server was doing the modeset before
it crashed (so all I got was a black screen) and netconsole is busticated for
me. I can confirm that reverting that one commit allows my box to boot and get
X up and running as well.
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* Re: [Bugme-new] [Bug 42132] New: Support BCM5750M in tg3
From: Francesco Piccinno @ 2011-09-02 0:48 UTC (permalink / raw)
To: Matt Carlson
Cc: Andrew Morton, netdev@vger.kernel.org,
bugme-daemon@bugzilla.kernel.org, Benjamin Li, Michael Chan
In-Reply-To: <20110902000646.GA4910@mcarlson.broadcom.com>
Yes sure.
# lspci -vvv -s 08:00.0
08:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5750M
Gigabit Ethernet
Subsystem: Broadcom Corporation NetXtreme BCM5750M Gigabit Ethernet
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 10
Region 0: Memory at f4100000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [48] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [50] Vital Product Data
pcilib: sysfs_read_vpd: read failed: Connection timed out
Not readable
Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
Address: 5149526521410124 Data: 8b60
Capabilities: [d0] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE- FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 <4us, L1 <64us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive-
BWMgmt- ABWMgmt-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [13c v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [160 v1] Device Serial Number 00-00-00-ff-fe-00-00-00
Serial number is CND71700K6.
--
Best regards,
Francesco Piccinno
On Fri, Sep 2, 2011 at 2:06 AM, Matt Carlson <mcarlson@broadcom.com> wrote:
> On Thu, Sep 01, 2011 at 04:40:11PM -0700, Andrew Morton wrote:
>>
>> (switched to email. Please respond via emailed reply-to-all, not via the
>> bugzilla web interface).
>>
>> On Wed, 31 Aug 2011 18:18:40 GMT
>> bugzilla-daemon@bugzilla.kernel.org wrote:
>>
>> > https://bugzilla.kernel.org/show_bug.cgi?id=42132
>> >
>> > Summary: Support BCM5750M in tg3
>> > Product: Drivers
>> > Version: 2.5
>> > Kernel Version: 3.0.3
>> > Platform: All
>> > OS/Version: Linux
>> > Tree: Mainline
>> > Status: NEW
>> > Severity: normal
>> > Priority: P1
>> > Component: Network
>> > AssignedTo: drivers_network@kernel-bugs.osdl.org
>> > ReportedBy: stack.box@gmail.com
>> > Regression: Yes
>> >
>> >
>> > I have a notebook (HP TC4400) which has a BCM5750 ethernet card inside. The
>> > ouput of lspci is:
>> >
>> > 08:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5750M
>> > Gigabit Ethernet [14e4:167c]
>> >
>> > Commit 67b284d476bcb3d100e946da23d6cf9acfd0465c removed the support for this
>> > device.
>> >
>>
>> 67b284d476bcb3d100 says "These devices were never released to the public".
>>
>> > I wish to have the support for this network card back again. Thanks!
>>
>> oops ;)
>
> Really? All the TC4400 documentation I find says it uses a bcm5753M on a
> PCIe bus. Can you post the full output of 'lspci -vvv -s 08:00.0' ?
>
>
^ permalink raw reply
* Re: [Bugme-new] [Bug 42132] New: Support BCM5750M in tg3
From: Matt Carlson @ 2011-09-02 1:04 UTC (permalink / raw)
To: Francesco Piccinno
Cc: Matthew Carlson, Andrew Morton, netdev@vger.kernel.org,
bugme-daemon@bugzilla.kernel.org, Benjamin Li, Michael Chan
In-Reply-To: <CAA7bCn6DRmoqhHGBOAkaDqCdiYwrjPGuaYcck7n4+o3Lm10w2g@mail.gmail.com>
It's showing up on lspci as a PCIe device, so it can't be the 5750M.
The bcm5750M is a pci device.
I'm wondering if bootcode is failing. Do you see any messages in your
syslogs that say "No firmware running"?
Can you post the output of 'ethtool -i ethX'?
On Thu, Sep 01, 2011 at 05:48:50PM -0700, Francesco Piccinno wrote:
> Yes sure.
>
> # lspci -vvv -s 08:00.0
> 08:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5750M
> Gigabit Ethernet
> Subsystem: Broadcom Corporation NetXtreme BCM5750M Gigabit Ethernet
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 10
> Region 0: Memory at f4100000 (64-bit, non-prefetchable) [size=64K]
> Capabilities: [48] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
> Capabilities: [50] Vital Product Data
> pcilib: sysfs_read_vpd: read failed: Connection timed out
> Not readable
> Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
> Address: 5149526521410124 Data: 8b60
> Capabilities: [d0] Express (v1) Endpoint, MSI 00
> DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
> ExtTag+ AttnBtn- AttnInd- PwrInd- RBE- FLReset-
> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
> MaxPayload 128 bytes, MaxReadReq 512 bytes
> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 <4us, L1 <64us
> ClockPM- Surprise- LLActRep- BwNot-
> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive-
> BWMgmt- ABWMgmt-
> Capabilities: [100 v1] Advanced Error Reporting
> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
> MalfTLP- ECRC- UnsupReq- ACSViol-
> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
> MalfTLP- ECRC- UnsupReq- ACSViol-
> UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
> MalfTLP+ ECRC- UnsupReq- ACSViol-
> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
> AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
> Capabilities: [13c v1] Virtual Channel
> Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
> Arb: Fixed- WRR32- WRR64- WRR128-
> Ctrl: ArbSelect=Fixed
> Status: InProgress-
> VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
> Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
> Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
> Status: NegoPending- InProgress-
> Capabilities: [160 v1] Device Serial Number 00-00-00-ff-fe-00-00-00
>
> Serial number is CND71700K6.
> --
> Best regards,
> Francesco Piccinno
>
>
>
> On Fri, Sep 2, 2011 at 2:06 AM, Matt Carlson <mcarlson@broadcom.com> wrote:
> > On Thu, Sep 01, 2011 at 04:40:11PM -0700, Andrew Morton wrote:
> >>
> >> (switched to email. ??Please respond via emailed reply-to-all, not via the
> >> bugzilla web interface).
> >>
> >> On Wed, 31 Aug 2011 18:18:40 GMT
> >> bugzilla-daemon@bugzilla.kernel.org wrote:
> >>
> >> > https://bugzilla.kernel.org/show_bug.cgi?id=42132
> >> >
> >> > ?? ?? ?? ?? ?? ??Summary: Support BCM5750M in tg3
> >> > ?? ?? ?? ?? ?? ??Product: Drivers
> >> > ?? ?? ?? ?? ?? ??Version: 2.5
> >> > ?? ?? Kernel Version: 3.0.3
> >> > ?? ?? ?? ?? ?? Platform: All
> >> > ?? ?? ?? ?? OS/Version: Linux
> >> > ?? ?? ?? ?? ?? ?? ?? Tree: Mainline
> >> > ?? ?? ?? ?? ?? ?? Status: NEW
> >> > ?? ?? ?? ?? ?? Severity: normal
> >> > ?? ?? ?? ?? ?? Priority: P1
> >> > ?? ?? ?? ?? ??Component: Network
> >> > ?? ?? ?? ?? AssignedTo: drivers_network@kernel-bugs.osdl.org
> >> > ?? ?? ?? ?? ReportedBy: stack.box@gmail.com
> >> > ?? ?? ?? ?? Regression: Yes
> >> >
> >> >
> >> > I have a notebook (HP TC4400) which has a BCM5750 ethernet card inside. The
> >> > ouput of lspci is:
> >> >
> >> > 08:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5750M
> >> > Gigabit Ethernet [14e4:167c]
> >> >
> >> > Commit 67b284d476bcb3d100e946da23d6cf9acfd0465c removed the support for this
> >> > device.
> >> >
> >>
> >> 67b284d476bcb3d100 says "These devices were never released to the public".
> >>
> >> > I wish to have the support for this network card back again. Thanks!
> >>
> >> oops ;)
> >
> > Really? ??All the TC4400 documentation I find says it uses a bcm5753M on a
> > PCIe bus. ??Can you post the full output of 'lspci -vvv -s 08:00.0' ?
> >
> >
>
^ permalink raw reply
* Re: [Bugme-new] [Bug 42132] New: Support BCM5750M in tg3
From: Francesco Piccinno @ 2011-09-02 1:14 UTC (permalink / raw)
To: Matt Carlson
Cc: Andrew Morton, netdev@vger.kernel.org,
bugme-daemon@bugzilla.kernel.org, Benjamin Li, Michael Chan
In-Reply-To: <20110902010431.GA5105@mcarlson.broadcom.com>
The only message I get regarding the firmware is the following:
[51503.038205] pci 0000:08:00.0: vpd r/w failed. This is likely a
firmware bug on this device. Contact the card vendor for a firmware
update.
Unfortunately I can not post the output of ethtool since the interface
is not available. Shall I recompile the tg3 module with the proper
patch and post the output?
--
Best regards,
Francesco Piccinno
On Fri, Sep 2, 2011 at 3:04 AM, Matt Carlson <mcarlson@broadcom.com> wrote:
> It's showing up on lspci as a PCIe device, so it can't be the 5750M.
> The bcm5750M is a pci device.
>
> I'm wondering if bootcode is failing. Do you see any messages in your
> syslogs that say "No firmware running"?
>
> Can you post the output of 'ethtool -i ethX'?
>
> On Thu, Sep 01, 2011 at 05:48:50PM -0700, Francesco Piccinno wrote:
>> Yes sure.
>>
>> # lspci -vvv -s 08:00.0
>> 08:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5750M
>> Gigabit Ethernet
>> Subsystem: Broadcom Corporation NetXtreme BCM5750M Gigabit Ethernet
>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>> Stepping- SERR- FastB2B- DisINTx-
>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>> Latency: 0, Cache Line Size: 64 bytes
>> Interrupt: pin A routed to IRQ 10
>> Region 0: Memory at f4100000 (64-bit, non-prefetchable) [size=64K]
>> Capabilities: [48] Power Management version 2
>> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
>> Capabilities: [50] Vital Product Data
>> pcilib: sysfs_read_vpd: read failed: Connection timed out
>> Not readable
>> Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
>> Address: 5149526521410124 Data: 8b60
>> Capabilities: [d0] Express (v1) Endpoint, MSI 00
>> DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
>> ExtTag+ AttnBtn- AttnInd- PwrInd- RBE- FLReset-
>> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
>> MaxPayload 128 bytes, MaxReadReq 512 bytes
>> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
>> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 <4us, L1 <64us
>> ClockPM- Surprise- LLActRep- BwNot-
>> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive-
>> BWMgmt- ABWMgmt-
>> Capabilities: [100 v1] Advanced Error Reporting
>> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
>> MalfTLP- ECRC- UnsupReq- ACSViol-
>> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
>> MalfTLP- ECRC- UnsupReq- ACSViol-
>> UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
>> MalfTLP+ ECRC- UnsupReq- ACSViol-
>> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
>> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
>> AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
>> Capabilities: [13c v1] Virtual Channel
>> Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
>> Arb: Fixed- WRR32- WRR64- WRR128-
>> Ctrl: ArbSelect=Fixed
>> Status: InProgress-
>> VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
>> Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
>> Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
>> Status: NegoPending- InProgress-
>> Capabilities: [160 v1] Device Serial Number 00-00-00-ff-fe-00-00-00
>>
>> Serial number is CND71700K6.
>> --
>> Best regards,
>> Francesco Piccinno
>>
>>
>>
>> On Fri, Sep 2, 2011 at 2:06 AM, Matt Carlson <mcarlson@broadcom.com> wrote:
>> > On Thu, Sep 01, 2011 at 04:40:11PM -0700, Andrew Morton wrote:
>> >>
>> >> (switched to email. ??Please respond via emailed reply-to-all, not via the
>> >> bugzilla web interface).
>> >>
>> >> On Wed, 31 Aug 2011 18:18:40 GMT
>> >> bugzilla-daemon@bugzilla.kernel.org wrote:
>> >>
>> >> > https://bugzilla.kernel.org/show_bug.cgi?id=42132
>> >> >
>> >> > ?? ?? ?? ?? ?? ??Summary: Support BCM5750M in tg3
>> >> > ?? ?? ?? ?? ?? ??Product: Drivers
>> >> > ?? ?? ?? ?? ?? ??Version: 2.5
>> >> > ?? ?? Kernel Version: 3.0.3
>> >> > ?? ?? ?? ?? ?? Platform: All
>> >> > ?? ?? ?? ?? OS/Version: Linux
>> >> > ?? ?? ?? ?? ?? ?? ?? Tree: Mainline
>> >> > ?? ?? ?? ?? ?? ?? Status: NEW
>> >> > ?? ?? ?? ?? ?? Severity: normal
>> >> > ?? ?? ?? ?? ?? Priority: P1
>> >> > ?? ?? ?? ?? ??Component: Network
>> >> > ?? ?? ?? ?? AssignedTo: drivers_network@kernel-bugs.osdl.org
>> >> > ?? ?? ?? ?? ReportedBy: stack.box@gmail.com
>> >> > ?? ?? ?? ?? Regression: Yes
>> >> >
>> >> >
>> >> > I have a notebook (HP TC4400) which has a BCM5750 ethernet card inside. The
>> >> > ouput of lspci is:
>> >> >
>> >> > 08:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5750M
>> >> > Gigabit Ethernet [14e4:167c]
>> >> >
>> >> > Commit 67b284d476bcb3d100e946da23d6cf9acfd0465c removed the support for this
>> >> > device.
>> >> >
>> >>
>> >> 67b284d476bcb3d100 says "These devices were never released to the public".
>> >>
>> >> > I wish to have the support for this network card back again. Thanks!
>> >>
>> >> oops ;)
>> >
>> > Really? ??All the TC4400 documentation I find says it uses a bcm5753M on a
>> > PCIe bus. ??Can you post the full output of 'lspci -vvv -s 08:00.0' ?
>> >
>> >
>>
>
>
^ permalink raw reply
* Re: [Bugme-new] [Bug 42132] New: Support BCM5750M in tg3
From: Matt Carlson @ 2011-09-02 1:25 UTC (permalink / raw)
To: Francesco Piccinno
Cc: Matthew Carlson, Andrew Morton, netdev@vger.kernel.org,
bugme-daemon@bugzilla.kernel.org, Benjamin Li, Michael Chan
In-Reply-To: <CAA7bCn7Au+-QEa7hTwO_P_mnL1w5TiGPz4Wsm0CxtoqT3FDBbQ@mail.gmail.com>
Yes. Sorry. Please revert that patch. If you really had a bcm5750,
you'd need to revert another patch too, but let's see where we stand
before going down that road.
On Thu, Sep 01, 2011 at 06:14:57PM -0700, Francesco Piccinno wrote:
> The only message I get regarding the firmware is the following:
>
> [51503.038205] pci 0000:08:00.0: vpd r/w failed. This is likely a
> firmware bug on this device. Contact the card vendor for a firmware
> update.
>
> Unfortunately I can not post the output of ethtool since the interface
> is not available. Shall I recompile the tg3 module with the proper
> patch and post the output?
>
> --
> Best regards,
> Francesco Piccinno
>
> On Fri, Sep 2, 2011 at 3:04 AM, Matt Carlson <mcarlson@broadcom.com> wrote:
> > It's showing up on lspci as a PCIe device, so it can't be the 5750M.
> > The bcm5750M is a pci device.
> >
> > I'm wondering if bootcode is failing. ??Do you see any messages in your
> > syslogs that say "No firmware running"?
> >
> > Can you post the output of 'ethtool -i ethX'?
> >
> > On Thu, Sep 01, 2011 at 05:48:50PM -0700, Francesco Piccinno wrote:
> >> Yes sure.
> >>
> >> # lspci -vvv -s 08:00.0
> >> 08:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5750M
> >> Gigabit Ethernet
> >> ?? ?? ?? Subsystem: Broadcom Corporation NetXtreme BCM5750M Gigabit Ethernet
> >> ?? ?? ?? Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> >> Stepping- SERR- FastB2B- DisINTx-
> >> ?? ?? ?? Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> >> <TAbort- <MAbort- >SERR- <PERR- INTx-
> >> ?? ?? ?? Latency: 0, Cache Line Size: 64 bytes
> >> ?? ?? ?? Interrupt: pin A routed to IRQ 10
> >> ?? ?? ?? Region 0: Memory at f4100000 (64-bit, non-prefetchable) [size=64K]
> >> ?? ?? ?? Capabilities: [48] Power Management version 2
> >> ?? ?? ?? ?? ?? ?? ?? Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
> >> ?? ?? ?? ?? ?? ?? ?? Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
> >> ?? ?? ?? Capabilities: [50] Vital Product Data
> >> pcilib: sysfs_read_vpd: read failed: Connection timed out
> >> ?? ?? ?? ?? ?? ?? ?? Not readable
> >> ?? ?? ?? Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
> >> ?? ?? ?? ?? ?? ?? ?? Address: 5149526521410124 ??Data: 8b60
> >> ?? ?? ?? Capabilities: [d0] Express (v1) Endpoint, MSI 00
> >> ?? ?? ?? ?? ?? ?? ?? DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ExtTag+ AttnBtn- AttnInd- PwrInd- RBE- FLReset-
> >> ?? ?? ?? ?? ?? ?? ?? DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? MaxPayload 128 bytes, MaxReadReq 512 bytes
> >> ?? ?? ?? ?? ?? ?? ?? DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
> >> ?? ?? ?? ?? ?? ?? ?? LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 <4us, L1 <64us
> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ClockPM- Surprise- LLActRep- BwNot-
> >> ?? ?? ?? ?? ?? ?? ?? LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> >> ?? ?? ?? ?? ?? ?? ?? LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive-
> >> BWMgmt- ABWMgmt-
> >> ?? ?? ?? Capabilities: [100 v1] Advanced Error Reporting
> >> ?? ?? ?? ?? ?? ?? ?? UESta: ??DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
> >> MalfTLP- ECRC- UnsupReq- ACSViol-
> >> ?? ?? ?? ?? ?? ?? ?? UEMsk: ??DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
> >> MalfTLP- ECRC- UnsupReq- ACSViol-
> >> ?? ?? ?? ?? ?? ?? ?? UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
> >> MalfTLP+ ECRC- UnsupReq- ACSViol-
> >> ?? ?? ?? ?? ?? ?? ?? CESta: ??RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
> >> ?? ?? ?? ?? ?? ?? ?? CEMsk: ??RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
> >> ?? ?? ?? ?? ?? ?? ?? AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
> >> ?? ?? ?? Capabilities: [13c v1] Virtual Channel
> >> ?? ?? ?? ?? ?? ?? ?? Caps: ?? LPEVC=0 RefClk=100ns PATEntryBits=1
> >> ?? ?? ?? ?? ?? ?? ?? Arb: ?? ??Fixed- WRR32- WRR64- WRR128-
> >> ?? ?? ?? ?? ?? ?? ?? Ctrl: ?? ArbSelect=Fixed
> >> ?? ?? ?? ?? ?? ?? ?? Status: InProgress-
> >> ?? ?? ?? ?? ?? ?? ?? VC0: ?? ??Caps: ?? PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? Arb: ?? ??Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? Ctrl: ?? Enable+ ID=0 ArbSelect=Fixed TC/VC=01
> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? Status: NegoPending- InProgress-
> >> ?? ?? ?? Capabilities: [160 v1] Device Serial Number 00-00-00-ff-fe-00-00-00
> >>
> >> Serial number is CND71700K6.
> >> --
> >> Best regards,
> >> Francesco Piccinno
> >>
> >>
> >>
> >> On Fri, Sep 2, 2011 at 2:06 AM, Matt Carlson <mcarlson@broadcom.com> wrote:
> >> > On Thu, Sep 01, 2011 at 04:40:11PM -0700, Andrew Morton wrote:
> >> >>
> >> >> (switched to email. ??Please respond via emailed reply-to-all, not via the
> >> >> bugzilla web interface).
> >> >>
> >> >> On Wed, 31 Aug 2011 18:18:40 GMT
> >> >> bugzilla-daemon@bugzilla.kernel.org wrote:
> >> >>
> >> >> > https://bugzilla.kernel.org/show_bug.cgi?id=42132
> >> >> >
> >> >> > ?? ?? ?? ?? ?? ??Summary: Support BCM5750M in tg3
> >> >> > ?? ?? ?? ?? ?? ??Product: Drivers
> >> >> > ?? ?? ?? ?? ?? ??Version: 2.5
> >> >> > ?? ?? Kernel Version: 3.0.3
> >> >> > ?? ?? ?? ?? ?? Platform: All
> >> >> > ?? ?? ?? ?? OS/Version: Linux
> >> >> > ?? ?? ?? ?? ?? ?? ?? Tree: Mainline
> >> >> > ?? ?? ?? ?? ?? ?? Status: NEW
> >> >> > ?? ?? ?? ?? ?? Severity: normal
> >> >> > ?? ?? ?? ?? ?? Priority: P1
> >> >> > ?? ?? ?? ?? ??Component: Network
> >> >> > ?? ?? ?? ?? AssignedTo: drivers_network@kernel-bugs.osdl.org
> >> >> > ?? ?? ?? ?? ReportedBy: stack.box@gmail.com
> >> >> > ?? ?? ?? ?? Regression: Yes
> >> >> >
> >> >> >
> >> >> > I have a notebook (HP TC4400) which has a BCM5750 ethernet card inside. The
> >> >> > ouput of lspci is:
> >> >> >
> >> >> > 08:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5750M
> >> >> > Gigabit Ethernet [14e4:167c]
> >> >> >
> >> >> > Commit 67b284d476bcb3d100e946da23d6cf9acfd0465c removed the support for this
> >> >> > device.
> >> >> >
> >> >>
> >> >> 67b284d476bcb3d100 says "These devices were never released to the public".
> >> >>
> >> >> > I wish to have the support for this network card back again. Thanks!
> >> >>
> >> >> oops ;)
> >> >
> >> > Really? ??All the TC4400 documentation I find says it uses a bcm5753M on a
> >> > PCIe bus. ??Can you post the full output of 'lspci -vvv -s 08:00.0' ?
> >> >
> >> >
> >>
> >
> >
>
^ permalink raw reply
* Re: [next] unix stream crashes
From: Tim Chen @ 2011-09-02 1:40 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: Jiri Slaby, David S. Miller, ML netdev, LKML
In-Reply-To: <3179.1314924559@turing-police.cc.vt.edu>
On Thu, 2011-09-01 at 20:49 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Thu, 01 Sep 2011 22:46:32 +0200, Jiri Slaby said:
> > Hi,
> >
> > my box 100% crashes when booting. It's both in unix socket recv and send
> > paths. I've reverted 0856a30409 (Scm: Remove unnecessary pid &
> > credential references in Unix socket's send and receive path) and it
> > seems to help.
> >
> > The oops:
> > http://www.fi.muni.cz/~xslaby/sklad/panics/af_unix_crash.png
>
> I was seeing a 100% repeatable crash with the X server starting as well, but
> wasn't able to get a traceback because my X server was doing the modeset before
> it crashed (so all I got was a black screen) and netconsole is busticated for
> me. I can confirm that reverting that one commit allows my box to boot and get
> X up and running as well.
>
Yes, Jiri's log does indicate that something went wrong when releasing
the skb, most likely due to changes in the pid and credentials ref
count. Unfortunately, I cannot duplicate the problem on my system. Any
info on your system to help me debug will be appreciated. I'll try to
take another look at the patch tomorrow.
Tim
^ permalink raw reply
* [PATCH net-next-2.6 ] Fix overflow of socket buffer in sunrpc
From: Mitsuo Hayasaka @ 2011-09-02 3:41 UTC (permalink / raw)
To: Trond Myklebust, J. Bruce Fields, Neil Brown, David S. Miller
Cc: linux-nfs, netdev, linux-kernel, yrl.pp-manager.tt,
Mitsuo Hayasaka, Trond Myklebust, J. Bruce Fields, Neil Brown,
David S. Miller
The sk_sndbuf and sk_rcvbuf fields of struct sock are sizes of send and
receive socket buffers respectively, and are defined as integer.
The sunrpc which is used in NFSD and any other applications can change them
via svc_sock_setbufsize(). It, however, sets them as unsigned integer and
may cause overflow of integer. This leads to a degradation of networking
capability.
This patch adds integer-overflow check into svc_sock_setbufsize() before
both fields are set, and limits their maximum sizes to INT_MAX.
Signed-off-by: Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Neil Brown <neilb@suse.de>
Cc: "David S. Miller" <davem@davemloft.net>
---
net/sunrpc/svcsock.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
index 767d494..bd66775 100644
--- a/net/sunrpc/svcsock.c
+++ b/net/sunrpc/svcsock.c
@@ -54,6 +54,7 @@
#include "sunrpc.h"
#define RPCDBG_FACILITY RPCDBG_SVCXPRT
+#define MAX_SKBUFSIZ INT_MAX
static struct svc_sock *svc_setup_socket(struct svc_serv *, struct socket *,
@@ -435,6 +436,11 @@ static void svc_sock_setbufsize(struct socket *sock, unsigned int snd,
* on not having CAP_SYS_RESOURCE or similar, we go direct...
* DaveM said I could!
*/
+ if (snd > MAX_SKBUFSIZ/2)
+ snd = MAX_SKBUFSIZ/2;
+ if (rcv > MAX_SKBUFSIZ/2)
+ rcv = MAX_SKBUFSIZ/2;
+
lock_sock(sock->sk);
sock->sk->sk_sndbuf = snd * 2;
sock->sk->sk_rcvbuf = rcv * 2;
^ permalink raw reply related
* Re: linux-next 20110831 - netconsole startup issue
From: Américo Wang @ 2011-09-02 5:54 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: David S. Miller, netdev, linux-kernel
In-Reply-To: <5187.1314890079@turing-police.cc.vt.edu>
On Thu, Sep 1, 2011 at 11:14 PM, <Valdis.Kletnieks@vt.edu> wrote:
> Chasing a kernel panic in linux-next, and hit an unrelated issue
> starting up netconsole that's bogging me down.
>
> On linux-next-20110823, I had this:
>
> [ 7.078099] e1000e: Intel(R) PRO/1000 Network Driver - 1.5.1-k
> [ 7.078102] e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
> [ 7.078158] e1000e 0000:00:19.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
> [ 7.078171] e1000e 0000:00:19.0: setting latency timer to 64
> [ 7.078354] e1000e 0000:00:19.0: irq 46 for MSI/MSI-X
> [ 7.269439] e1000e 0000:00:19.0: eth0: (PCI Express:2.5GT/s:Width x1) 00:21:70:de:b6:fd
> [ 7.269443] e1000e 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
> [ 7.269469] e1000e 0000:00:19.0: eth0: MAC: 7, PHY: 8, PBA No: 4003FF-0FF
> [ 7.293569] netconsole: network logging started
>
> Bring up the ethernet, then the console. Works great,
>
> However, on -20110831, I get this:
>
> [ 0.983149] netconsole: local port 9909
> [ 0.983254] netconsole: local IP 128.173.14.107
> [ 0.983358] netconsole: interface 'eth0'
> [ 0.983461] netconsole: remote port 9909
> [ 0.983564] netconsole: remote IP 128.173.14.108
> [ 0.983668] netconsole: remote ethernet address 00:14:22:5a:79:d3
> [ 0.983776] netconsole: eth0 doesn't exist, aborting.
> [ 0.983897] netconsole: cleaning up
> [ 1.176429] e1000e 0000:00:19.0: eth0: (PCI Express:2.5GT/s:Width x1) 00:21:70:de:b6:fd
> [ 1.176557] e1000e 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
> [ 1.176688] e1000e 0000:00:19.0: eth0: MAC: 7, PHY: 8, PBA No: 4003FF-0FF
>
> Whoops. No netconsole.
This is because your eth0 came up after netconsole, I guess
you need to wait for some seconds to let eth0 come up before
activating netconsole.
But I don't see any changes of netconsole between 20110823
and 20110831...
^ permalink raw reply
* Re: commit 1faa4356 breaks IPv6 assignment on libvirtd
From: Ang Way Chuang @ 2011-09-02 5:57 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Achmad Basuki
In-Reply-To: <20110901085126.76cdda54@nehalam.ftrdhcpuser.net>
On 02/09/11 00:51, Stephen Hemminger wrote:
> On Thu, 01 Sep 2011 23:42:42 +0900
> Ang Way Chuang <wcang@sfc.wide.ad.jp> wrote:
>
>> Hi all,
>>
>> Commit 1faa4356 break IPv6 assignment on libvirtd. The configuration for my VM bridge network is as such:
>>
>> <network>
>> <name>default</name>
>> <forward mode='nat'/>
>> <bridge name='virbr0' stp='on' delay='0' />
>> <ip address='192.168.122.1' netmask='255.255.255.0'>
>> <dhcp>
>> <range start='192.168.122.2' end='192.168.122.254' />
>> </dhcp>
>> </ip>
>> <ip family='ipv6' address='2001:d30:113:504::1' prefix='64'>
>> </ip>
>> </network>
>>
>> This configuration worked fine on kernel 2.6.38. Updating my distro kernel broke the setup. My colleague
>> and I traced the problem and found that libvirtd failed because there wasn't any carrier on virbr0 interface
>> due to the change introduced by that commit. How can this be fixed? Thanks in advance.
>>
>> Regards,
>> Ang Way Chuang
> The issue is that address is assigned to a bridge device with no ports.
> IPv6 needs carrier to do duplicate address detection. Without any ports
> the DAD will always succeed, and there is a possibility that when ports
> are later added to the bridge the address actually is a duplicate.
>
> A couple of possible options are:
> 1. Default to carrier on in bridge when there are no ports.
> The downside with this is that IPv6 DAD is being fooled.
I understand the point you raised. I think the same address duplication issue
is possible with IPv4. But any fix shouldn't break user space application.
>
> 2. Change libvirt to allow turning off DAD. This is controlled
> in kernel by writing 0 to /proc/sys/net/ipv6/conf/virbr0/accept_dad
This won't fix the problem.
Here is the full analysis of the event from my observation, but please take it with
a grain of salt because I don't understand the internal of libvirtd.
# virsh net-start default
would create virbr0 with IPv6 address assigned, but with no carrier. dnsmasq would be called
with the following arguments.
/usr/sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --listen-address 192.168.122.1 --listen-address 2001:d30:113:504::1 --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-lease-max=253 --dhcp-no-override
Attempts from dnsmasq to bind to IPv6 failed. Here is the abridged version of strace output
from dnsmasq:
socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 7
setsockopt(7, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
fcntl(7, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(7, F_SETFL, O_RDWR|O_NONBLOCK) = 0
setsockopt(7, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0
bind(7, {sa_family=AF_INET6, sin6_port=htons(53), inet_pton(AF_INET6, "2001:d30:113:555::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=11}, 28) = -1 EADDRNOTAVAIL (Cannot assign requested address)
I am not sure why bind failed in this case. When dnsmasq failed to bind, virsh took down virbr0 and exit.
1. Is that the correct behaviour? Maybe modifying the code that deals with bind can resolve this problem, but
will it cause any other problem?
2. If option 1 is too troublesome, maybe carrier should be turn on for bridge vif by default.
Regards,
Ang Way Chuang
^ permalink raw reply
* [PATCH net-next v3 3/4] r8169: fix the reset setting for 8111evl
From: Hayes Wang @ 2011-09-02 6:23 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
In-Reply-To: <1314944631-5005-1-git-send-email-hayeswang@realtek.com>
rtl8111evl should stop any TLP requirement before resetting by
enabling register 0x37 bit 7.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index db5ab2c..175c769 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -3997,6 +3997,7 @@ static void rtl8169_hw_reset(struct rtl8169_private *tp)
while (RTL_R8(TxPoll) & NPQ)
udelay(20);
} else if (tp->mac_version == RTL_GIGA_MAC_VER_34) {
+ RTL_W8(ChipCmd, RTL_R8(ChipCmd) | StopReq);
while (!(RTL_R32(TxConfig) & TXCFG_EMPTY))
udelay(100);
} else {
--
1.7.6
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox