* Re: [net-next 1/4] stmmac: modify and improve the bus_setup platform callback
From: Giuseppe CAVALLARO @ 2012-05-23 6:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20120523.014359.1912436981409831773.davem@davemloft.net>
Hello David
On 5/23/2012 7:43 AM, David Miller wrote:
>
> As I stated the other day, the net-next tree is closed, therefore only
> bug fixes are appropriate at this time.
Ok, so only these patches shouldbe considered:
stmmac: update driver's doc
stmmac: remove two useless initialisation
stmmac: remove two useless initialisation
and
stmmac: fix driver Kconfig when built as module
This is attached to another thread and under review.
> If there are bug fixes you want integrated in this series, you need
> to seperate them out and submit them only at this time.
Thanks, I'm resending them again for net.git.
> When net-next opens back up you can submit the rest.
I'll only resend the following patch (that should be stay in next repo)
later:
stmmac: modify and improve the bus_setup platform callback
Regards
Peppe
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* Re: [PATCH] ipv4: fix the rcu race between free_fib_info and ip_route_output_slow
From: Yanmin Zhang @ 2012-05-23 6:15 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, kunx.jiang, netdev, linux-kernel
In-Reply-To: <1337749339.3361.1655.camel@edumazet-glaptop>
On Wed, 2012-05-23 at 07:02 +0200, Eric Dumazet wrote:
> On Wed, 2012-05-23 at 12:54 +0800, Yanmin Zhang wrote:
>
> > > fi->fib_dev (aka fib_nh[0].nh_dev) need full RCU protection.
> > The new patch posted at https://lkml.org/lkml/2012/5/22/558 does move the
> > resetting to RCU protection.
>
> Its not enough.
>
> We must take care that all users are in a RCU protected region.
>
> They might be already, but a full check is needed.
>
> For example
>
> net/ipv4/fib_trie.c:2563: fi->fib_dev ? fi->fib_dev->name : "*"
>
> looks to be safe (because already in a rcu_read_lock())
>
> But its not.
>
> Right thing would be to do :
>
> struct net_device *ndev = rcu_dereference(fi->fib_dev)
>
> ...
> ndev ? ndev->name : "*"
Thanks for the pointer.
Besides fi->fib_dev here, we need check fi->fib_hash, fi->fib_lhash,
and nexthop_nh->nh_hash.
Yanmin
^ permalink raw reply
* Re: [PATCH] rfkill: Add handling when rfkill's type is RFKILL_TYPE_ALL.
From: Alex Hung @ 2012-05-23 6:12 UTC (permalink / raw)
To: Johannes Berg; +Cc: linville, davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <1337712399.4470.5.camel@jlt3.sipsolutions.net>
On 05/23/2012 02:46 AM, Johannes Berg wrote:
> On Mon, 2012-05-21 at 16:37 +0800, Alex Hung wrote:
>> This rfkill type is supposed to be able to toggles the status of all wireless
>> devices; however, no wireless devices will register itself with type
>> RFKILL_TYPE_ALL and thus it was previously ignored in __rfkill_switch_all.
>>
>> Signed-off-by: Alex Hung<alex.hung@canonical.com>
>> ---
>> net/rfkill/core.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/net/rfkill/core.c b/net/rfkill/core.c
>> index 5be1957..84dd71a 100644
>> --- a/net/rfkill/core.c
>> +++ b/net/rfkill/core.c
>> @@ -324,7 +324,7 @@ static void __rfkill_switch_all(const enum rfkill_type type, bool blocked)
>>
>> rfkill_global_states[type].cur = blocked;
>> list_for_each_entry(rfkill,&rfkill_list, node) {
>> - if (rfkill->type != type)
>> + if (rfkill->type != type&& type != RFKILL_TYPE_ALL)
>> continue;
>
> Sorry, I accidentally replied to this in private and then Alex replied
> but it all got lost.
>
> He said he was going to change the eeepc use KEY_RFKILL instead of
> KEY_WLAN to switch all types...
>
> So I guess what this change really does is make __rfkill_switch_all() be
> able to not only switch all devices of a given type, but also be able to
> switch all devices of all types.
>
> Alex, can you please rewrite the commit log to make that clearer?
>
> johannes
>
Thanks for your feedback, I re-wrote the comments to clarify the changes
and re-submitted.
Cheers,
Alex Hung
^ permalink raw reply
* [PATCH] rfkill: Add the capability to switch all devices of all type in __rfkill_switch_all().
From: Alex Hung @ 2012-05-23 6:11 UTC (permalink / raw)
To: linville, johannes, davem, linux-wireless, netdev, linux-kernel,
alex.hung
__rfkill_switch_all() switches the state of devices of a given type; however,
it does not switch devices of all type (RFKILL_TYPE_ALL). As a result, it
ignores the keycode "KEY_RFKILL" from another module, i.e. eeepc-wmi.
This fix is to make __rfkill_switch_all() to be able to switch not only
devices of a given type but also all devices.
Signed-off-by: Alex Hung <alex.hung@canonical.com>
---
net/rfkill/core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 5be1957..84dd71a 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -324,7 +324,7 @@ static void __rfkill_switch_all(const enum rfkill_type type, bool blocked)
rfkill_global_states[type].cur = blocked;
list_for_each_entry(rfkill, &rfkill_list, node) {
- if (rfkill->type != type)
+ if (rfkill->type != type && type != RFKILL_TYPE_ALL)
continue;
rfkill_set_block(rfkill, blocked);
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 2/3] drivers: net: ethernet: stmmac: fix failure in module test
From: Giuseppe CAVALLARO @ 2012-05-23 6:08 UTC (permalink / raw)
To: Bob Liu; +Cc: davem, francesco.virlinzi, rayagond, sr, netdev,
uclinux-dist-devel
In-Reply-To: <CAA_GA1fNJCT=qfuHDkNrBdeZd8wiR30MPBdtUVuAv+ZY+zMH_g@mail.gmail.com>
On 5/23/2012 7:09 AM, Bob Liu wrote:
> Hi Peppe,
>
> On Tue, May 22, 2012 at 8:51 PM, Giuseppe CAVALLARO
> <peppe.cavallaro@st.com> wrote:
>> On 5/22/2012 9:38 AM, Bob Liu wrote:
>>> Module can't be compiled and installed in current Makefile.
>>
>> I've just seen that I can generate the stmmac.ko on ARM and also on x86
>> with my configuration.
>>
>> Can you post here you build failure?
>>
>> In the meantime I'll test the module on ARM soon.
>
> Yes, stmmac.ko can be generated, but stmmac_platform.c won't be built.
> which cause net device can't be probed.
Yes you are perfectly right!
I've just sent a patch following Ben's advice.
Also not clear if/how to build this as a system which supports both PCI
and platform versions of the driver. So the patch makes them mutually
exclusive.
Thanks a lot
peppe
>
>>
>> peppe
>>
>>>
>>> Signed-off-by: Bob Liu <lliubbo@gmail.com>
>>> ---
>>> drivers/net/ethernet/stmicro/stmmac/Makefile | 12 ++++++------
>>> 1 files changed, 6 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
>>> index bc965ac..4b50922 100644
>>> --- a/drivers/net/ethernet/stmicro/stmmac/Makefile
>>> +++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
>>> @@ -1,10 +1,10 @@
>>> obj-$(CONFIG_STMMAC_ETH) += stmmac.o
>>> -stmmac-$(CONFIG_STMMAC_TIMER) += stmmac_timer.o
>>> -stmmac-$(CONFIG_STMMAC_RING) += ring_mode.o
>>> -stmmac-$(CONFIG_STMMAC_CHAINED) += chain_mode.o
>>> -stmmac-$(CONFIG_STMMAC_PLATFORM) += stmmac_platform.o
>>> -stmmac-$(CONFIG_STMMAC_PCI) += stmmac_pci.o
>>> +stmmac-$(CONFIG_STMMAC_TIMER:m=y) += stmmac_timer.o
>>> +stmmac-$(CONFIG_STMMAC_RING:m=y) += ring_mode.o
>>> +stmmac-$(CONFIG_STMMAC_CHAINED:m=y) += chain_mode.o
>>> +stmmac-$(CONFIG_STMMAC_PLATFORM:m=y) += stmmac_platform.o
>>> +stmmac-$(CONFIG_STMMAC_PCI:m=y) += stmmac_pci.o
>>> stmmac-objs:= stmmac_main.o stmmac_ethtool.o stmmac_mdio.o \
>>> dwmac_lib.o dwmac1000_core.o dwmac1000_dma.o \
>>> dwmac100_core.o dwmac100_dma.o enh_desc.o norm_desc.o \
>>> - mmc_core.o $(stmmac-y)
>>> + mmc_core.o
>>
>
^ permalink raw reply
* [net] stmmac: fix driver Kconfig when built as module
From: Giuseppe CAVALLARO @ 2012-05-23 6:05 UTC (permalink / raw)
To: netdev; +Cc: bhutchings, lliubbo, Giuseppe Cavallaro, Rayagond Kokatanur
In-Reply-To: <1337672336-7378-2-git-send-email-lliubbo@gmail.com>
This patches fixes the driver when built as dyn module.
In fact the platform part cannot be built and the probe fails
(thanks to Bob Liu that reported this bug).
The patch also makes the selection of Platform and PCI parts
mutually exclusive.
Reported-by: Bob Liu <lliubbo@gmail.com>
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
cc: Rayagond Kokatanur <rayagond@vayavyalabs.com>
---
drivers/net/ethernet/stmicro/stmmac/Kconfig | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 0364283..3318b32 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -12,10 +12,12 @@ config STMMAC_ETH
if STMMAC_ETH
+choice
+ prompt "STMMAC bus support"
+
config STMMAC_PLATFORM
- tristate "STMMAC platform bus support"
+ bool "Platform bus support"
depends on STMMAC_ETH
- default y
---help---
This selects the platform specific bus support for
the stmmac device driver. This is the driver used
@@ -26,7 +28,7 @@ config STMMAC_PLATFORM
If unsure, say N.
config STMMAC_PCI
- tristate "STMMAC support on PCI bus (EXPERIMENTAL)"
+ bool "PCI bus support (EXPERIMENTAL)"
depends on STMMAC_ETH && PCI && EXPERIMENTAL
---help---
This is to select the Synopsys DWMAC available on PCI devices,
@@ -36,6 +38,7 @@ config STMMAC_PCI
D1215994A VIRTEX FPGA board.
If unsure, say N.
+endchoice
config STMMAC_DEBUG_FS
bool "Enable monitoring via sysFS "
--
1.7.4.4
^ permalink raw reply related
* Re: [net-next 1/4] stmmac: modify and improve the bus_setup platform callback
From: David Miller @ 2012-05-23 5:43 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <1337751619-21941-1-git-send-email-peppe.cavallaro@st.com>
As I stated the other day, the net-next tree is closed, therefore only
bug fixes are appropriate at this time.
If there are bug fixes you want integrated in this series, you need
to seperate them out and submit them only at this time.
When net-next opens back up you can submit the rest.
^ permalink raw reply
* [net-next 4/4] stmmac: update driver's doc
From: Giuseppe CAVALLARO @ 2012-05-23 5:40 UTC (permalink / raw)
To: netdev; +Cc: Giuseppe Cavallaro
In-Reply-To: <1337751619-21941-1-git-send-email-peppe.cavallaro@st.com>
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
Documentation/networking/stmmac.txt | 47 ++++++++++++++++++++---------------
1 files changed, 27 insertions(+), 20 deletions(-)
diff --git a/Documentation/networking/stmmac.txt b/Documentation/networking/stmmac.txt
index 20c01bf..b71f960 100644
--- a/Documentation/networking/stmmac.txt
+++ b/Documentation/networking/stmmac.txt
@@ -10,8 +10,8 @@ Currently this network device driver is for all STM embedded MAC/GMAC
(i.e. 7xxx/5xxx SoCs), SPEAr (arm), Loongson1B (mips) and XLINX XC2V3000
FF1152AMT0221 D1215994A VIRTEX FPGA board.
-DWC Ether MAC 10/100/1000 Universal version 3.60a (and older) and DWC Ether MAC 10/100
-Universal version 4.0 have been used for developing this driver.
+DWC Ether MAC 10/100/1000 Universal version 3.60a (and older) and DWC Ether
+MAC 10/100 Universal version 4.0 have been used for developing this driver.
This driver supports both the platform bus and PCI.
@@ -54,27 +54,27 @@ net_device structure enabling the scatter/gather feature.
When one or more packets are received, an interrupt happens. The interrupts
are not queued so the driver has to scan all the descriptors in the ring during
the receive process.
-This is based on NAPI so the interrupt handler signals only if there is work to be
-done, and it exits.
+This is based on NAPI so the interrupt handler signals only if there is work
+to be done, and it exits.
Then the poll method will be scheduled at some future point.
The incoming packets are stored, by the DMA, in a list of pre-allocated socket
buffers in order to avoid the memcpy (Zero-copy).
4.3) Timer-Driver Interrupt
-Instead of having the device that asynchronously notifies the frame receptions, the
-driver configures a timer to generate an interrupt at regular intervals.
-Based on the granularity of the timer, the frames that are received by the device
-will experience different levels of latency. Some NICs have dedicated timer
-device to perform this task. STMMAC can use either the RTC device or the TMU
-channel 2 on STLinux platforms.
+Instead of having the device that asynchronously notifies the frame receptions,
+the driver configures a timer to generate an interrupt at regular intervals.
+Based on the granularity of the timer, the frames that are received by the
+device will experience different levels of latency. Some NICs have dedicated
+timer device to perform this task. STMMAC can use either the RTC device or the
+TMU channel 2 on STLinux platforms.
The timers frequency can be passed to the driver as parameter; when change it,
take care of both hardware capability and network stability/performance impact.
-Several performance tests on STM platforms showed this optimisation allows to spare
-the CPU while having the maximum throughput.
+Several performance tests on STM platforms showed this optimisation allows to
+spare the CPU while having the maximum throughput.
4.4) WOL
-Wake up on Lan feature through Magic and Unicast frames are supported for the GMAC
-core.
+Wake up on Lan feature through Magic and Unicast frames are supported for the
+GMAC core.
4.5) DMA descriptors
Driver handles both normal and enhanced descriptors. The latter has been only
@@ -106,7 +106,8 @@ Several driver's information can be passed through the platform
These are included in the include/linux/stmmac.h header file
and detailed below as well:
- struct plat_stmmacenet_data {
+struct plat_stmmacenet_data {
+ char *phy_bus_name;
int bus_id;
int phy_addr;
int interface;
@@ -122,21 +123,27 @@ and detailed below as well:
int force_sf_dma_mode;
void (*fix_mac_speed)(void *priv, unsigned int speed);
void *(*bus_setup)(void __iomem *ioaddr, struct device *dev, void *d);
+ void *bus_data;
int (*init)(struct platform_device *pdev);
void (*exit)(struct platform_device *pdev);
+ void *custom_cfg;
+ void *custom_data;
void *bsp_priv;
- };
+};
Where:
+ o phy_bus_name: phy bus name to attach to the stmmac.
o bus_id: bus identifier.
o phy_addr: the physical address can be passed from the platform.
If it is set to -1 the driver will automatically
detect it at run-time by probing all the 32 addresses.
o interface: PHY device's interface.
o mdio_bus_data: specific platform fields for the MDIO bus.
- o pbl: the Programmable Burst Length is maximum number of beats to
+ o dma_cfg: internal DMA parameters
+ o pbl: the Programmable Burst Length is maximum number of beats to
be transferred in one DMA transaction.
GMAC also enables the 4xPBL by default.
+ o fixed_burst/mixed_burst/burst_len
o clk_csr: fixed CSR Clock range selection.
o has_gmac: uses the GMAC core.
o enh_desc: if sets the MAC will use the enhanced descriptor structure.
@@ -161,8 +168,9 @@ Where:
this is sometime necessary on some platforms (e.g. ST boxes)
where the HW needs to have set some PIO lines or system cfg
registers.
- o custom_cfg: this is a custom configuration that can be passed while
- initialising the resources.
+ o custom_cfg/custom_data: this is a custom configuration that can be passed
+ while initialising the resources.
+ o bsp_priv: another private poiter.
For MDIO bus The we have:
@@ -181,7 +189,6 @@ Where:
o irqs: list of IRQs, one per PHY.
o probed_phy_irq: if irqs is NULL, use this for probed PHY.
-
For DMA engine we have the following internal fields that should be
tuned according to the HW capabilities.
--
1.7.4.4
^ permalink raw reply related
* [net-next 3/4] stmmac: fix driver's doc when run kernel-doc script
From: Giuseppe CAVALLARO @ 2012-05-23 5:40 UTC (permalink / raw)
To: netdev; +Cc: Giuseppe Cavallaro
In-Reply-To: <1337751619-21941-1-git-send-email-peppe.cavallaro@st.com>
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index b942ed4..fd8bafc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -833,8 +833,9 @@ static u32 stmmac_get_synopsys_id(struct stmmac_priv *priv)
/**
* stmmac_selec_desc_mode
- * @dev : device pointer
- * Description: select the Enhanced/Alternate or Normal descriptors */
+ * @priv : private structure
+ * Description: select the Enhanced/Alternate or Normal descriptors
+ */
static void stmmac_selec_desc_mode(struct stmmac_priv *priv)
{
if (priv->plat->enh_desc) {
@@ -1856,6 +1857,8 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
/**
* stmmac_dvr_probe
* @device: device pointer
+ * @plat_dat: platform data pointer
+ * @addr: iobase memory address
* Description: this is the main probe function used to
* call the alloc_etherdev, allocate the priv structure.
*/
--
1.7.4.4
^ permalink raw reply related
* [net-next 2/4] stmmac: remove two useless initialisation
From: Giuseppe CAVALLARO @ 2012-05-23 5:40 UTC (permalink / raw)
To: netdev; +Cc: Giuseppe Cavallaro
In-Reply-To: <1337751619-21941-1-git-send-email-peppe.cavallaro@st.com>
This patch removes two useful initialisation in the
stmmac_rx and stmmac_tx function.
In the former, count var was already reset and in the
stmmac_tx we only need to increment the dirty pointer
w/o setting the entry var.
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 2fc5462..b942ed4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -677,7 +677,7 @@ static void stmmac_tx(struct stmmac_priv *priv)
priv->hw->desc->release_tx_desc(p);
- entry = (++priv->dirty_tx) % txsize;
+ priv->dirty_tx++;
}
if (unlikely(netif_queue_stopped(priv->dev) &&
stmmac_tx_avail(priv) > STMMAC_TX_THRESH(priv))) {
@@ -1303,7 +1303,6 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit)
display_ring(priv->dma_rx, rxsize);
}
#endif
- count = 0;
while (!priv->hw->desc->get_rx_owner(p)) {
int status;
--
1.7.4.4
^ permalink raw reply related
* [net-next 1/4] stmmac: modify and improve the bus_setup platform callback
From: Giuseppe CAVALLARO @ 2012-05-23 5:40 UTC (permalink / raw)
To: netdev; +Cc: Giuseppe Cavallaro
This patch modifies and improves the bus_setup callback now
by passing extra parameters that can help on more complex
platforms that require more custom settings.
The patch also updates the documentation.
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
Documentation/networking/stmmac.txt | 3 ++-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 19 +++++++++++++++----
include/linux/stmmac.h | 3 ++-
3 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/Documentation/networking/stmmac.txt b/Documentation/networking/stmmac.txt
index ab1e8d7..20c01bf 100644
--- a/Documentation/networking/stmmac.txt
+++ b/Documentation/networking/stmmac.txt
@@ -121,7 +121,7 @@ and detailed below as well:
int pmt;
int force_sf_dma_mode;
void (*fix_mac_speed)(void *priv, unsigned int speed);
- void (*bus_setup)(void __iomem *ioaddr);
+ void *(*bus_setup)(void __iomem *ioaddr, struct device *dev, void *d);
int (*init)(struct platform_device *pdev);
void (*exit)(struct platform_device *pdev);
void *bsp_priv;
@@ -156,6 +156,7 @@ Where:
o bus_setup: perform HW setup of the bus. For example, on some ST platforms
this field is used to configure the AMBA bridge to generate more
efficient STBus traffic.
+ o bus_data: saved custom data for custom bus setting.
o init/exit: callbacks used for calling a custom initialisation;
this is sometime necessary on some platforms (e.g. ST boxes)
where the HW needs to have set some PIO lines or system cfg
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 7096633..2fc5462 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -999,10 +999,6 @@ static int stmmac_open(struct net_device *dev)
/* Copy the MAC addr into the HW */
priv->hw->mac->set_umac_addr(priv->ioaddr, dev->dev_addr, 0);
- /* If required, perform hw setup of the bus. */
- if (priv->plat->bus_setup)
- priv->plat->bus_setup(priv->ioaddr);
-
/* Initialize the MAC Core */
priv->hw->mac->core_init(priv->ioaddr);
@@ -1949,6 +1945,15 @@ struct stmmac_priv *stmmac_dvr_probe(struct device *device,
goto error;
}
+ /* On some platforms, is is possible to perform some hw setup of the bus
+ * and this is done by calling the bus_setup (when implemented).
+ * Data from bus_setup can be saved in the patform structure to be
+ * restored when resume for example form standby.
+ */
+ if (priv->plat->bus_setup)
+ priv->plat->bus_data =
+ priv->plat->bus_setup(priv->ioaddr, priv->device,
+ priv->plat->bus_data);
return priv;
error:
@@ -2057,6 +2062,8 @@ int stmmac_resume(struct net_device *ndev)
priv->hw->dma->start_tx(priv->ioaddr);
priv->hw->dma->start_rx(priv->ioaddr);
+ priv->plat->bus_data = priv->plat->bus_setup(priv->ioaddr, priv->device,
+ priv->plat->bus_data);
#ifdef CONFIG_STMMAC_TIMER
if (likely(priv->tm->enable))
priv->tm->timer_start(tmrate);
@@ -2083,9 +2090,13 @@ int stmmac_freeze(struct net_device *ndev)
int stmmac_restore(struct net_device *ndev)
{
+ struct stmmac_priv *priv = netdev_priv(ndev);
+
if (!ndev || !netif_running(ndev))
return 0;
+ priv->plat->bus_data = priv->plat->bus_setup(priv->ioaddr, priv->device,
+ priv->plat->bus_data);
return stmmac_open(ndev);
}
#endif /* CONFIG_PM */
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index b69bdb1..cf03968 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -106,7 +106,8 @@ struct plat_stmmacenet_data {
int pmt;
int force_sf_dma_mode;
void (*fix_mac_speed)(void *priv, unsigned int speed);
- void (*bus_setup)(void __iomem *ioaddr);
+ void *(*bus_setup)(void __iomem *ioaddr, struct device *dev, void *d);
+ void *bus_data;
int (*init)(struct platform_device *pdev);
void (*exit)(struct platform_device *pdev);
void *custom_cfg;
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH 2/3] drivers: net: ethernet: stmmac: fix failure in module test
From: Bob Liu @ 2012-05-23 5:09 UTC (permalink / raw)
To: Giuseppe CAVALLARO
Cc: davem, francesco.virlinzi, rayagond, sr, netdev,
uclinux-dist-devel
In-Reply-To: <4FBB8BBD.8010208@st.com>
Hi Peppe,
On Tue, May 22, 2012 at 8:51 PM, Giuseppe CAVALLARO
<peppe.cavallaro@st.com> wrote:
> On 5/22/2012 9:38 AM, Bob Liu wrote:
>> Module can't be compiled and installed in current Makefile.
>
> I've just seen that I can generate the stmmac.ko on ARM and also on x86
> with my configuration.
>
> Can you post here you build failure?
>
> In the meantime I'll test the module on ARM soon.
Yes, stmmac.ko can be generated, but stmmac_platform.c won't be built.
which cause net device can't be probed.
>
> peppe
>
>>
>> Signed-off-by: Bob Liu <lliubbo@gmail.com>
>> ---
>> drivers/net/ethernet/stmicro/stmmac/Makefile | 12 ++++++------
>> 1 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
>> index bc965ac..4b50922 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/Makefile
>> +++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
>> @@ -1,10 +1,10 @@
>> obj-$(CONFIG_STMMAC_ETH) += stmmac.o
>> -stmmac-$(CONFIG_STMMAC_TIMER) += stmmac_timer.o
>> -stmmac-$(CONFIG_STMMAC_RING) += ring_mode.o
>> -stmmac-$(CONFIG_STMMAC_CHAINED) += chain_mode.o
>> -stmmac-$(CONFIG_STMMAC_PLATFORM) += stmmac_platform.o
>> -stmmac-$(CONFIG_STMMAC_PCI) += stmmac_pci.o
>> +stmmac-$(CONFIG_STMMAC_TIMER:m=y) += stmmac_timer.o
>> +stmmac-$(CONFIG_STMMAC_RING:m=y) += ring_mode.o
>> +stmmac-$(CONFIG_STMMAC_CHAINED:m=y) += chain_mode.o
>> +stmmac-$(CONFIG_STMMAC_PLATFORM:m=y) += stmmac_platform.o
>> +stmmac-$(CONFIG_STMMAC_PCI:m=y) += stmmac_pci.o
>> stmmac-objs:= stmmac_main.o stmmac_ethtool.o stmmac_mdio.o \
>> dwmac_lib.o dwmac1000_core.o dwmac1000_dma.o \
>> dwmac100_core.o dwmac100_dma.o enh_desc.o norm_desc.o \
>> - mmc_core.o $(stmmac-y)
>> + mmc_core.o
>
--
Thanks,
--Bob
^ permalink raw reply
* Re: [PATCH] ipv4: fix the rcu race between free_fib_info and ip_route_output_slow
From: Eric Dumazet @ 2012-05-23 5:08 UTC (permalink / raw)
To: Yanmin Zhang; +Cc: David Miller, kunx.jiang, netdev, linux-kernel
In-Reply-To: <1337748069.14538.181.camel@ymzhang.sh.intel.com>
On Wed, 2012-05-23 at 12:41 +0800, Yanmin Zhang wrote:
> We did test it. But it's hard to reproduce it. We hit it the issue
> for a couple of times when running MTBF testing on Android smart phone.
> Mostly, it happens after MTBF runs for more than 12 hours. To releasing
> the product, MTBF testing should run for hundreds of hours. This bug
> blocks it.
>
I have an idea how to trigger this in my test machine.
> We would submit it formally and also run more testing.
>
> Sorry for taking you too much time.
Hey, you fix a bug, take your time and dont worry.
Thanks
^ permalink raw reply
* Re: [PATCH] ipv4: fix the rcu race between free_fib_info and ip_route_output_slow
From: Eric Dumazet @ 2012-05-23 5:02 UTC (permalink / raw)
To: Yanmin Zhang; +Cc: David Miller, kunx.jiang, netdev, linux-kernel
In-Reply-To: <1337748897.14538.184.camel@ymzhang.sh.intel.com>
On Wed, 2012-05-23 at 12:54 +0800, Yanmin Zhang wrote:
> > fi->fib_dev (aka fib_nh[0].nh_dev) need full RCU protection.
> The new patch posted at https://lkml.org/lkml/2012/5/22/558 does move the
> resetting to RCU protection.
Its not enough.
We must take care that all users are in a RCU protected region.
They might be already, but a full check is needed.
For example
net/ipv4/fib_trie.c:2563: fi->fib_dev ? fi->fib_dev->name : "*"
looks to be safe (because already in a rcu_read_lock())
But its not.
Right thing would be to do :
struct net_device *ndev = rcu_dereference(fi->fib_dev)
...
ndev ? ndev->name : "*"
^ permalink raw reply
* Re: [PATCH] ipv4: fix the rcu race between free_fib_info and ip_route_output_slow
From: Yanmin Zhang @ 2012-05-23 4:54 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, kunx.jiang, netdev, linux-kernel
In-Reply-To: <1337747829.3361.1599.camel@edumazet-glaptop>
On Wed, 2012-05-23 at 06:37 +0200, Eric Dumazet wrote:
> On Tue, 2012-05-22 at 23:23 -0400, David Miller wrote:
> > From: Yanmin Zhang <yanmin_zhang@linux.intel.com>
> > Date: Wed, 23 May 2012 11:02:03 +0800
> >
> > > 1) Why does free_fib_info call call_rcu instead of releasing fi directly?
> > > I assume other cpu might be accessing it. nexthop_nh->nh_dev is in fi.
> > > If other cpu are accessing it, here resetting to NULL would cause other
> > > cpu panic.
> >
> > Because fib trie lookups are done with RCU locking, therefore we must
> > use RCU freeing to release the object.
> >
> > What I was trying to impart to you is that removing the NULL
> > assignment is wrong and that an alternative fix is warranted (hint:
> > consider moving something into the RCU release).
> > --
>
> Its more than that I'm afraid.
>
> fi->fib_dev (aka fib_nh[0].nh_dev) need full RCU protection.
The new patch posted at https://lkml.org/lkml/2012/5/22/558 does move the
resetting to RCU protection.
>
> Also the "fib_info_cnt--;" must stay in free_fib_info() (so that it is
> protected by RTNL)
We would move "fib_info_cnt--;" back to free_fib_info.
Thanks,
Yanmin
^ permalink raw reply
* Re: [PATCH] ipv4: fix the rcu race between free_fib_info and ip_route_output_slow
From: Yanmin Zhang @ 2012-05-23 4:41 UTC (permalink / raw)
To: David Miller; +Cc: kunx.jiang, netdev, linux-kernel
In-Reply-To: <20120522.234920.1047532847473945281.davem@davemloft.net>
On Tue, 2012-05-22 at 23:49 -0400, David Miller wrote:
> From: Yanmin Zhang <yanmin_zhang@linux.intel.com>
> Date: Wed, 23 May 2012 11:30:41 +0800
>
> > How about the new patch posted in the end of previous reply? It does move the
> > the resetting to RCU release.
> > https://lkml.org/lkml/2012/5/22/558?
>
> If you test it and submit it formally I'll probably apply it.
We did test it. But it's hard to reproduce it. We hit it the issue
for a couple of times when running MTBF testing on Android smart phone.
Mostly, it happens after MTBF runs for more than 12 hours. To releasing
the product, MTBF testing should run for hundreds of hours. This bug
blocks it.
We would submit it formally and also run more testing.
Sorry for taking you too much time.
^ permalink raw reply
* Re: [PATCH] ipv4: fix the rcu race between free_fib_info and ip_route_output_slow
From: Eric Dumazet @ 2012-05-23 4:37 UTC (permalink / raw)
To: David Miller; +Cc: yanmin_zhang, kunx.jiang, netdev, linux-kernel
In-Reply-To: <20120522.232310.911242148705021745.davem@davemloft.net>
On Tue, 2012-05-22 at 23:23 -0400, David Miller wrote:
> From: Yanmin Zhang <yanmin_zhang@linux.intel.com>
> Date: Wed, 23 May 2012 11:02:03 +0800
>
> > 1) Why does free_fib_info call call_rcu instead of releasing fi directly?
> > I assume other cpu might be accessing it. nexthop_nh->nh_dev is in fi.
> > If other cpu are accessing it, here resetting to NULL would cause other
> > cpu panic.
>
> Because fib trie lookups are done with RCU locking, therefore we must
> use RCU freeing to release the object.
>
> What I was trying to impart to you is that removing the NULL
> assignment is wrong and that an alternative fix is warranted (hint:
> consider moving something into the RCU release).
> --
Its more than that I'm afraid.
fi->fib_dev (aka fib_nh[0].nh_dev) need full RCU protection.
Also the "fib_info_cnt--;" must stay in free_fib_info() (so that it is
protected by RTNL)
^ permalink raw reply
* Re: [PATCH] ipv4: fix the rcu race between free_fib_info and ip_route_output_slow
From: David Miller @ 2012-05-23 3:49 UTC (permalink / raw)
To: yanmin_zhang; +Cc: kunx.jiang, netdev, linux-kernel
In-Reply-To: <1337743841.14538.178.camel@ymzhang.sh.intel.com>
From: Yanmin Zhang <yanmin_zhang@linux.intel.com>
Date: Wed, 23 May 2012 11:30:41 +0800
> How about the new patch posted in the end of previous reply? It does move the
> the resetting to RCU release.
> https://lkml.org/lkml/2012/5/22/558?
If you test it and submit it formally I'll probably apply it.
^ permalink raw reply
* Re: [PATCH] ipv4: fix the rcu race between free_fib_info and ip_route_output_slow
From: Yanmin Zhang @ 2012-05-23 3:30 UTC (permalink / raw)
To: David Miller; +Cc: kunx.jiang, netdev, linux-kernel
In-Reply-To: <20120522.232310.911242148705021745.davem@davemloft.net>
On Tue, 2012-05-22 at 23:23 -0400, David Miller wrote:
> From: Yanmin Zhang <yanmin_zhang@linux.intel.com>
> Date: Wed, 23 May 2012 11:02:03 +0800
>
> > 1) Why does free_fib_info call call_rcu instead of releasing fi directly?
> > I assume other cpu might be accessing it. nexthop_nh->nh_dev is in fi.
> > If other cpu are accessing it, here resetting to NULL would cause other
> > cpu panic.
>
> Because fib trie lookups are done with RCU locking, therefore we must
> use RCU freeing to release the object.
>
> What I was trying to impart to you is that removing the NULL
> assignment is wrong and that an alternative fix is warranted (hint:
> consider moving something into the RCU release).
Thanks for the explanation.
How about the new patch posted in the end of previous reply? It does move the
the resetting to RCU release.
https://lkml.org/lkml/2012/5/22/558?
^ permalink raw reply
* Re: [PATCH] ipv4: fix the rcu race between free_fib_info and ip_route_output_slow
From: David Miller @ 2012-05-23 3:23 UTC (permalink / raw)
To: yanmin_zhang; +Cc: kunx.jiang, netdev, linux-kernel
In-Reply-To: <1337742123.14538.175.camel@ymzhang.sh.intel.com>
From: Yanmin Zhang <yanmin_zhang@linux.intel.com>
Date: Wed, 23 May 2012 11:02:03 +0800
> 1) Why does free_fib_info call call_rcu instead of releasing fi directly?
> I assume other cpu might be accessing it. nexthop_nh->nh_dev is in fi.
> If other cpu are accessing it, here resetting to NULL would cause other
> cpu panic.
Because fib trie lookups are done with RCU locking, therefore we must
use RCU freeing to release the object.
What I was trying to impart to you is that removing the NULL
assignment is wrong and that an alternative fix is warranted (hint:
consider moving something into the RCU release).
^ permalink raw reply
* Re: [PATCH] ipv4: fix the rcu race between free_fib_info and ip_route_output_slow
From: Yanmin Zhang @ 2012-05-23 3:02 UTC (permalink / raw)
To: David Miller; +Cc: kunx.jiang, netdev, linux-kernel
In-Reply-To: <20120522.151554.106838106733194160.davem@davemloft.net>
On Tue, 2012-05-22 at 15:15 -0400, David Miller wrote:
> From: "kun.jiang" <kunx.jiang@intel.com>
> Date: Tue, 22 May 2012 17:48:53 +0800
>
> > From: Yanmin Zhang <yanmin_zhang@linux.intel.com>
> >
> > We hit a kernel OOPS.
> ...
> > In function free_fib_info, we don't reset nexthop_nh->nh_dev to NULL before releasing
> > nh_dev. kfree_rcu(fi, rcu) would release the whole area.
> >
> > Signed-off-by: Yanmin Zhang <yanmin_zhang@linux.intel.com>
> > Signed-off-by: Kun Jiang <kunx.jiang@intel.com>
>
> This isn't a fix. You're keeping around a pointer to a completely
> released object, which is therefore illegal to dereference.
>
> That's why we must set it to NULL, to catch such illegal accesses.
Thanks for the comments. The network stack in kernel is complicated.
Questions:
1) Why does free_fib_info call call_rcu instead of releasing fi directly?
I assume other cpu might be accessing it. nexthop_nh->nh_dev is in fi.
If other cpu are accessing it, here resetting to NULL would cause other
cpu panic.
void free_fib_info(struct fib_info *fi)
{
if (fi->fib_dead == 0) {
pr_warn("Freeing alive fib_info %p\n", fi);
return;
}
change_nexthops(fi) {
if (nexthop_nh->nh_dev)
dev_put(nexthop_nh->nh_dev);
nexthop_nh->nh_dev = NULL;
} endfor_nexthops(fi);
fib_info_cnt--;
release_net(fi->fib_net);
call_rcu(&fi->rcu, free_fib_info_rcu); <=====rcu
}
2) dev_put is to decrease the counter and doesn't release nh_dev.
If 2) is incorrect, how about below solution? It delays the resetting
in rcu.
================
We hit a kernel OOPS.
<3>[23898.789643] BUG: sleeping function called from invalid context at
/data/buildbot/workdir/ics/hardware/intel/linux-2.6/arch/x86/mm/fault.c:1103
<3>[23898.862215] in_atomic(): 0, irqs_disabled(): 0, pid: 10526, name:
Thread-6683
<4>[23898.967805] HSU serial 0000:00:05.1: 0000:00:05.2:HSU serial prevented me
to suspend...
<4>[23899.258526] Pid: 10526, comm: Thread-6683 Tainted: G W
3.0.8-137685-ge7742f9 #1
<4>[23899.357404] HSU serial 0000:00:05.1: 0000:00:05.2:HSU serial prevented me
to suspend...
<4>[23899.904225] Call Trace:
<4>[23899.989209] [<c1227f50>] ? pgtable_bad+0x130/0x130
<4>[23900.000416] [<c1238c2a>] __might_sleep+0x10a/0x110
<4>[23900.007357] [<c1228021>] do_page_fault+0xd1/0x3c0
<4>[23900.013764] [<c18e9ba9>] ? restore_all+0xf/0xf
<4>[23900.024024] [<c17c007b>] ? napi_complete+0x8b/0x690
<4>[23900.029297] [<c1227f50>] ? pgtable_bad+0x130/0x130
<4>[23900.123739] [<c1227f50>] ? pgtable_bad+0x130/0x130
<4>[23900.128955] [<c18ea0c3>] error_code+0x5f/0x64
<4>[23900.133466] [<c1227f50>] ? pgtable_bad+0x130/0x130
<4>[23900.138450] [<c17f6298>] ? __ip_route_output_key+0x698/0x7c0
<4>[23900.144312] [<c17f5f8d>] ? __ip_route_output_key+0x38d/0x7c0
<4>[23900.150730] [<c17f63df>] ip_route_output_flow+0x1f/0x60
<4>[23900.156261] [<c181de58>] ip4_datagram_connect+0x188/0x2b0
<4>[23900.161960] [<c18e981f>] ? _raw_spin_unlock_bh+0x1f/0x30
<4>[23900.167834] [<c18298d6>] inet_dgram_connect+0x36/0x80
<4>[23900.173224] [<c14f9e88>] ? _copy_from_user+0x48/0x140
<4>[23900.178817] [<c17ab9da>] sys_connect+0x9a/0xd0
<4>[23900.183538] [<c132e93c>] ? alloc_file+0xdc/0x240
<4>[23900.189111] [<c123925d>] ? sub_preempt_count+0x3d/0x50
Function free_fib_info resets nexthop_nh->nh_dev to NULL before releasing
fi. Other cpu might be accessing fi. Fixing it by delaying the resetting.
Signed-off-by: Yanmin Zhang <yanmin_zhang@linux.intel.com>
Signed-off-by: Kun Jiang <kunx.jiang@intel.com>
---
net/ipv4/fib_semantics.c | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index 5063fa3..56d8a97 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -145,6 +145,14 @@ static void free_fib_info_rcu(struct rcu_head *head)
{
struct fib_info *fi = container_of(head, struct fib_info, rcu);
+ change_nexthops(fi) {
+ if (nexthop_nh->nh_dev)
+ dev_put(nexthop_nh->nh_dev);
+ nexthop_nh->nh_dev = NULL;
+ } endfor_nexthops(fi);
+
+ fib_info_cnt--;
+ release_net(fi->fib_net);
if (fi->fib_metrics != (u32 *) dst_default_metrics)
kfree(fi->fib_metrics);
kfree(fi);
@@ -156,13 +164,6 @@ void free_fib_info(struct fib_info *fi)
pr_warn("Freeing alive fib_info %p\n", fi);
return;
}
- change_nexthops(fi) {
- if (nexthop_nh->nh_dev)
- dev_put(nexthop_nh->nh_dev);
- nexthop_nh->nh_dev = NULL;
- } endfor_nexthops(fi);
- fib_info_cnt--;
- release_net(fi->fib_net);
call_rcu(&fi->rcu, free_fib_info_rcu);
}
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH] if: restore token ring ARP type to header
From: Stephen Hemminger @ 2012-05-23 2:34 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: David Miller, netdev
In-Reply-To: <CAP=VYLqMGeFvy8O_zLi+sEP0t6p5M8f_x7d0g1XGkLHdVUVzUg@mail.gmail.com>
On Tue, 22 May 2012 22:28:28 -0400
Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
> On Tue, May 22, 2012 at 5:01 PM, Stephen Hemminger
> <shemminger@vyatta.com> wrote:
> > Recent removal of Token Ring breaks the build of iproute2.
> >
> > Even though Token Ring support is gone from the kernel, it is worth
> > keeping the the definition of the TR ARP type to avoid breaking
> > userspace programs that use this file.
>
> Thanks Stephen, I was trying to force errors in kernel builds by
> doing these kinds of define changes while doing my delete tests.
>
> But I was not doing userspace builds, however....
>
> Looking back at the changes I've made, the only thing similar that
> I can see is the ipx.h changes:
>
> diff --git a/include/linux/ipx.h b/include/linux/ipx.h
> index 3d48014..8f02439 100644
> --- a/include/linux/ipx.h
> +++ b/include/linux/ipx.h
> @@ -38,7 +38,7 @@ struct ipx_interface_definition {
> #define IPX_FRAME_8022 2
> #define IPX_FRAME_ETHERII 3
> #define IPX_FRAME_8023 4
> -#define IPX_FRAME_TR_8022 5 /* obsolete */
> +/* obsolete token ring was 5 */
> unsigned char ipx_special;
> #define IPX_SPECIAL_NONE 0
> #define IPX_PRIMARY 1
>
> Please let me/netdev know if the above also happens to trigger any
> sort of userspace fallout, and we'll fix it up ASAP.
>
> Thanks,
> Paul.
Assume any header processed as part of 'make headers_install' is
part of kernel API and must not get broken. Therefor ipx.h
must be fixed as well. Local debug stuff should not be committed
to upstream repository!
^ permalink raw reply
* Re: [PATCH] if: restore token ring ARP type to header
From: Paul Gortmaker @ 2012-05-23 2:28 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20120522140105.284c28cd@nehalam.linuxnetplumber.net>
On Tue, May 22, 2012 at 5:01 PM, Stephen Hemminger
<shemminger@vyatta.com> wrote:
> Recent removal of Token Ring breaks the build of iproute2.
>
> Even though Token Ring support is gone from the kernel, it is worth
> keeping the the definition of the TR ARP type to avoid breaking
> userspace programs that use this file.
Thanks Stephen, I was trying to force errors in kernel builds by
doing these kinds of define changes while doing my delete tests.
But I was not doing userspace builds, however....
Looking back at the changes I've made, the only thing similar that
I can see is the ipx.h changes:
diff --git a/include/linux/ipx.h b/include/linux/ipx.h
index 3d48014..8f02439 100644
--- a/include/linux/ipx.h
+++ b/include/linux/ipx.h
@@ -38,7 +38,7 @@ struct ipx_interface_definition {
#define IPX_FRAME_8022 2
#define IPX_FRAME_ETHERII 3
#define IPX_FRAME_8023 4
-#define IPX_FRAME_TR_8022 5 /* obsolete */
+/* obsolete token ring was 5 */
unsigned char ipx_special;
#define IPX_SPECIAL_NONE 0
#define IPX_PRIMARY 1
Please let me/netdev know if the above also happens to trigger any
sort of userspace fallout, and we'll fix it up ASAP.
Thanks,
Paul.
^ permalink raw reply related
* Re: [PATCH iproute2] tc_codel: Controlled Delay AQM
From: Vijay Subramanian @ 2012-05-23 2:05 UTC (permalink / raw)
To: Dave Taht; +Cc: Stephen Hemminger, Eric Dumazet, netdev, Dave Taht
In-Reply-To: <CAA93jw5oOz38UHsp2UODJcbn9uDz34RfPSNCE-qE-7BKoshLtA@mail.gmail.com>
On 22 May 2012 16:59, Dave Taht <dave.taht@gmail.com> wrote:
> I promised eric I'd write the two man pages.
>
> I also promised myself a vacation. The last year has been a long hard
> road. If someone
> hasn't got to writing the man pages by the time I get back from lupin,
> I'll write it.
>
Dave,
I can volunteer to write the man page. I have been looking at some of
the iproute2 code and the corresponding parts in the kernel and
writing the man page would be a good learning process I think. I will
try to come up with a version for you to review shortly.
Regards,
Vijay
^ permalink raw reply
* Re: NETDEV WATCHDOG: %s (%s): transmit queue %u timed out
From: George Spelvin @ 2012-05-23 1:53 UTC (permalink / raw)
To: davej, linux; +Cc: kernel-team, netdev
In-Reply-To: <20120523012640.GB15255@redhat.com>
> We seem to be seeing more and more of these (across a range of different NICs)
> https://bugzilla.redhat.com/showdependencytree.cgi?id=702723&hide_resolved=1
> has a bunch of duplicated bugs sorted into per-nic reports.
Thank yoou for rhe response.
Unfortunately, the last reboot was on Feb. 26, and the kernel logs don't go back that far,
so I'm not sure if 3.3-rc5 reported this priblem or not.
^ permalink raw reply
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