upt ]---
>>>>
>>>> I have fully reproducible setup for this issue. Reverting it together
>>>> with f8321fa75102 ("virtio_net: Fix napi_skb_cache_put warning") (due to
>>>> some code dependencies) fixes this issue on top of Linux v6.11-rc1 and
>>>> recent linux-next releases. Let me know if I can help debugging this
>>>> issue further and help fixing.
>>> Will fix this tomorrow. In the meantime, could you provide full
>>> reproduce steps?
>> Well, it is easy to reproduce it simply by calling
>>
>> # time rtcwake -s10 -mmem
>>
>> a few times and sooner or later it will cause a kernel panic.
> I found the problem. Following patch will help:
>
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 3f10c72743e9..c6af18948092 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -2867,8 +2867,8 @@ static int virtnet_enable_queue_pair(struct
> virtnet_info *vi, int qp_index)
> if (err < 0)
> goto err_xdp_reg_mem_model;
>
> - virtnet_napi_enable(vi->rq[qp_index].vq, &vi->rq[qp_index].napi);
> netdev_tx_reset_queue(netdev_get_tx_queue(vi->dev, qp_index));
> + virtnet_napi_enable(vi->rq[qp_index].vq, &vi->rq[qp_index].napi);
> virtnet_napi_tx_enable(vi, vi->sq[qp_index].vq, &vi->sq[qp_index].napi);
>
> return 0;
>
>
> Will submit the patch in a jiff. Thanks!
Confirmed. The above change fixed this issue in my tests.
Feel free to add:
Reported-by: Marek Szyprowski
Tested-by: Marek Szyprowski
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
pm_suspend from state_store+0x68/0xc8
>> state_store from kernfs_fop_write_iter+0x10c/0x1cc
>> kernfs_fop_write_iter from vfs_write+0x2b0/0x3dc
>> vfs_write from ksys_write+0x5c/0xd4
>> ksys_write from ret_fast_syscall+0x0/0x54
>> Exception stack(0xe8bf1fa8 t
ng: Fatal exception in interrupt
---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
I have fully reproducible setup for this issue. Reverting it together
with f8321fa75102 ("virtio_net: Fix napi_skb_cache_put warning") (due to
some code dependencies) fixes this i
it(). Additionally, checking of
> priv->dma_cap.fpesel is added before calling stmmac_fpe_link_state_handle()
> as only FPE supported SoC is allowed to call the function.
>
> Below is the kernel panic dump reported by Marek Szyprowski
> :
>
> meson8b-dwmac ff3f.ethernet eth0: PHY [0.
be done after FPE handshake
> + * is success.
> + */
> + priv->plat->fpe_cfg->enable = fpe;
>
> ret = stmmac_est_configure(priv, priv->ioaddr, priv->plat->est,
> priv->plat->clk_ptp_rate);
> @@ -845,12 +853,29 @@ static int tc_setup_taprio(struct stmmac_priv *priv,
> }
>
> netdev_info(priv->dev, "configured EST\n");
> +
> + if (fpe) {
> + stmmac_fpe_handshake(priv, true);
> + netdev_info(priv->dev, "start FPE handshake\n");
> + }
> +
> return 0;
>
> disable:
> priv->plat->est->enable = false;
> stmmac_est_configure(priv, priv->ioaddr, priv->plat->est,
>priv->plat->clk_ptp_rate);
> +
> + priv->plat->fpe_cfg->enable = false;
> + stmmac_fpe_configure(priv, priv->ioaddr,
> + priv->plat->tx_queues_to_use,
> + priv->plat->rx_queues_to_use,
> + false);
> + netdev_info(priv->dev, "disabled FPE\n");
> +
> + stmmac_fpe_handshake(priv, false);
> + netdev_info(priv->dev, "stop FPE handshake\n");
> +
> return ret;
> }
>
> diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
> index 10abc80b601e..072f269b1618 100644
> --- a/include/linux/stmmac.h
> +++ b/include/linux/stmmac.h
> @@ -144,6 +144,32 @@ struct stmmac_txq_cfg {
> int tbs_en;
> };
>
> +/* FPE link state */
> +enum stmmac_fpe_state {
> + FPE_STATE_OFF = 0,
> + FPE_STATE_CAPABLE = 1,
> + FPE_STATE_ENTERING_ON = 2,
> + FPE_STATE_ON = 3,
> +};
> +
> +/* FPE link-partner hand-shaking mPacket type */
> +enum stmmac_mpacket_type {
> + MPACKET_VERIFY = 0,
> + MPACKET_RESPONSE = 1,
> +};
> +
> +enum stmmac_fpe_task_state_t {
> + __FPE_REMOVING,
> + __FPE_TASK_SCHED,
> +};
> +
> +struct stmmac_fpe_cfg {
> + bool enable;/* FPE enable */
> + bool hs_enable; /* FPE handshake enable */
> + enum stmmac_fpe_state lp_fpe_state; /* Link Partner FPE state */
> + enum stmmac_fpe_state lo_fpe_state; /* Local station FPE state */
> +};
> +
> struct plat_stmmacenet_data {
> int bus_id;
> int phy_addr;
> @@ -155,6 +181,7 @@ struct plat_stmmacenet_data {
> struct device_node *mdio_node;
> struct stmmac_dma_cfg *dma_cfg;
> struct stmmac_est *est;
> + struct stmmac_fpe_cfg *fpe_cfg;
> int clk_csr;
> int has_gmac;
> int enh_desc;
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
0x14/0x38)
Exception stack(0xc1cedfb0 to 0xc1cedff8)
...
---[ end trace c04a86d3eb55e7cb ]---
mwifiex_sdio mmc3:0001:1: info: MWIFIEX VERSION: mwifiex 1.0 (14.68.29.p59)
mwifiex_sdio mmc3:0001:1: driver_version = mwifiex 1.0 (14.68.29.p59)
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
9f5fd5f 100644
> --- a/net/wireless/core.c
> +++ b/net/wireless/core.c
> @@ -1333,7 +1333,6 @@ int cfg80211_register_netdevice(struct net_device *dev)
> int ret;
>
> ASSERT_RTNL();
> - lockdep_assert_held(&rdev->wiphy.mtx);
>
> if (WARN_ON(!wdev))
> return -EINVAL;
>
Right, this finally fixed all the issues.
Tested-by: Marek Szyprowski
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
30c/0x888)
[] (process_one_work) from [] (worker_thread+0x58/0x594)
[] (worker_thread) from [] (kthread+0x154/0x19c)
[] (kthread) from [] (ret_from_fork+0x14/0x38)
Exception stack(0xdeccbfb0 to 0xdeccbff8)
...
> ...
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
ECM mode for RTL8153")
> Reported-by: Marek Szyprowski
> Signed-off-by: Hayes Wang
Yes, this looks like a proper fix.
Tested-by: Marek Szyprowski
> ---
> v2:
> Use a separate Kconfig entry for r8153_ecm with proper dependencies.
>
> drivers/net/usb/Kconfig | 9 ++
ECM mode for RTL8153")
> Reported-by: Marek Szyprowski
> Signed-off-by: Hayes Wang
Yes, this fixes this issue, although I would prefer a separate Kconfig
entry for r8153_ecm with proper dependencies instead of this ifdefs in
Makefile.
Tested-by: Marek Szyprowski
> ---
sb/r8152.c | 30 +--
> drivers/net/usb/r8153_ecm.c | 162
> include/linux/usb/r8152.h | 37
> 4 files changed, 204 insertions(+), 27 deletions(-)
> create mode 100644 drivers/net/usb/r8153_ecm.c
> create mode 100644 include/linux/us
66f7e06a6b ("net: stmmac: add ethtool support for get/set channels")
Signed-off-by: Marek Szyprowski
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/
7; failed
make[3]: *** [drivers/net/ethernet/asix] Error 2
scripts/Makefile.build:500: recipe for target 'drivers/net/ethernet' failed
make[2]: *** [drivers/net/ethernet] Error 2
scripts/Makefile.build:500: recipe for target 'drivers/net' failed
make[1]: *** [drivers/net] Error 2
> ...
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
h_mount, sys_watch_mount)
#undef __NR_syscalls
-#define __NR_syscalls 441
+#define __NR_syscalls 442
/*
* 32 bit systems traditionally used different
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
On 29.08.2020 16:29, Krzysztof Kozlowski wrote:
> Since "s3fwrn5" is not a valid vendor prefix, use new GPIO properties
> instead of the deprecated.
>
> Signed-off-by: Krzysztof Kozlowski
Tested-by: Marek Szyprowski
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm
troduce
> properly named properties for these GPIOs but still support deprecated
> ones.
>
> Signed-off-by: Krzysztof Kozlowski
Tested-by: Marek Szyprowski
> ---
> drivers/nfc/s3fwrn5/i2c.c | 20 ++--
> 1 file changed, 14 insertions(+), 6 deletions(-)
>
is legacy thing to be removed one day...
Maybe it would make more sense to convert the few remaining drivers to
regular dma_map_page()/dma_sync_*()/dma_unmap_page() or have I missed
something?
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
> family to the core_initcall and comes after the netlink protocol
> initialization.
>
> Signed-off-by: Daniel Lezcano
I confirm, that this change together with the thermal subsystem initcall
change fixes the issue observed in linux-next for the last few days.
Tested-by: Marek Szyp
Hi Florian,
On 11.05.2020 20:19, Florian Fainelli wrote:
> On 5/11/2020 12:21 AM, Marek Szyprowski wrote:
>> On 09.05.2020 00:32, Florian Fainelli wrote:
>>> The GENET controller on the Raspberry Pi 4 (2711) is typically
>>> interfaced with an external Broadcom
get a chance to have the dedicated Broadcom PHY
> driver (CONFIG_BROADCOM_PHY) enabled for this to happen.
>
> Fixes: 402482a6a78e ("net: bcmgenet: Clear ID_MODE_DIS in EXT_RGMII_OOB_CTRL
> when not needed")
> Reported-by: Marek Szyprowski
> Signed-off-by: Florian F
Hi Florian,
On 07.05.2020 17:54, Florian Fainelli wrote:
> On 5/7/2020 3:03 AM, Marek Szyprowski wrote:
>> On 07.05.2020 11:46, Marek Szyprowski wrote:
>>> On 25.02.2020 14:11, Nicolas Saenz Julienne wrote:
>>>> Outdated Raspberry Pi 4 firmware might configure
Hi
On 07.05.2020 11:46, Marek Szyprowski wrote:
> On 25.02.2020 14:11, Nicolas Saenz Julienne wrote:
>> Outdated Raspberry Pi 4 firmware might configure the external PHY as
>> rgmii although the kernel currently sets it as rgmii-rxid. This makes
>> connections unreliable a
ev, bool init)
>*/
> if (priv->ext_phy) {
> reg = bcmgenet_ext_readl(priv, EXT_RGMII_OOB_CTRL);
> + reg &= ~ID_MODE_DIS;
> reg |= id_mode_dis;
> if (GENET_IS_V1(priv) || GENET_IS_V2(priv) || GENET_IS_V3(priv))
> reg |= RGMII_MODE_EN_V123;
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
; -#endif
> +int driver_deferred_probe_timeout;
> EXPORT_SYMBOL_GPL(driver_deferred_probe_timeout);
>
> static int __init deferred_probe_timeout_setup(char *str)
> @@ -266,7 +257,7 @@ int driver_deferred_probe_check_state(struct device *dev)
> return -ENODEV;
> }
>
> - if (!driver_deferred_probe_timeout) {
> + if (!driver_deferred_probe_timeout && initcalls_done) {
> dev_WARN(dev, "deferred probe timeout, ignoring dependency");
> return -ETIMEDOUT;
> }
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
6,11 @@ static int rtl8152_open(struct net_device *netdev)
> struct r8152 *tp = netdev_priv(netdev);
> int res = 0;
>
> + if (work_busy(&tp->hw_phy_work.work) & WORK_BUSY_PENDING) {
> + cancel_delayed_work_sync(&tp->hw_phy_work);
> + rtl_hw_phy_work_func_t(&tp->hw_phy_work.work);
> + }
> +
> res = alloc_all_mem(tp);
> if (res)
> goto out;
> @@ -4844,6 +5537,9 @@ static void rtl8152_get_drvinfo(struct net_device
> *netdev,
> strlcpy(info->driver, MODULENAME, sizeof(info->driver));
> strlcpy(info->version, DRIVER_VERSION, sizeof(info->version));
> usb_make_path(tp->udev, info->bus_info, sizeof(info->bus_info));
> + if (!IS_ERR_OR_NULL(tp->rtl_fw.fw))
> + strlcpy(info->fw_version, tp->rtl_fw.version,
> + sizeof(info->fw_version));
> }
>
> static
> @@ -5468,6 +6164,47 @@ static int rtl_ops_init(struct r8152 *tp)
> return ret;
> }
>
> +#define FIRMWARE_8153A_2 "rtl_nic/rtl8153a-2.fw"
> +#define FIRMWARE_8153A_3 "rtl_nic/rtl8153a-3.fw"
> +#define FIRMWARE_8153A_4 "rtl_nic/rtl8153a-4.fw"
> +#define FIRMWARE_8153B_2 "rtl_nic/rtl8153b-2.fw"
> +
> +MODULE_FIRMWARE(FIRMWARE_8153A_2);
> +MODULE_FIRMWARE(FIRMWARE_8153A_3);
> +MODULE_FIRMWARE(FIRMWARE_8153A_4);
> +MODULE_FIRMWARE(FIRMWARE_8153B_2);
> +
> +static int rtl_fw_init(struct r8152 *tp)
> +{
> + struct rtl_fw *rtl_fw = &tp->rtl_fw;
> +
> + switch (tp->version) {
> + case RTL_VER_04:
> + rtl_fw->fw_name = FIRMWARE_8153A_2;
> + rtl_fw->pre_fw = r8153_pre_firmware_1;
> + rtl_fw->post_fw = r8153_post_firmware_1;
> + break;
> + case RTL_VER_05:
> + rtl_fw->fw_name = FIRMWARE_8153A_3;
> + rtl_fw->pre_fw = r8153_pre_firmware_2;
> + rtl_fw->post_fw = r8153_post_firmware_2;
> + break;
> + case RTL_VER_06:
> + rtl_fw->fw_name = FIRMWARE_8153A_4;
> + rtl_fw->post_fw = r8153_post_firmware_3;
> + break;
> + case RTL_VER_09:
> + rtl_fw->fw_name = FIRMWARE_8153B_2;
> + rtl_fw->pre_fw = r8153b_pre_firmware_1;
> + rtl_fw->post_fw = r8153b_post_firmware_1;
> + break;
> + default:
> + break;
> + }
> +
> + return 0;
> +}
> +
> static u8 rtl_get_version(struct usb_interface *intf)
> {
> struct usb_device *udev = interface_to_usbdev(intf);
> @@ -5575,6 +6312,8 @@ static int rtl8152_probe(struct usb_interface *intf,
> if (ret)
> goto out;
>
> + rtl_fw_init(tp);
> +
> mutex_init(&tp->control);
> INIT_DELAYED_WORK(&tp->schedule, rtl_work_func_t);
> INIT_DELAYED_WORK(&tp->hw_phy_work, rtl_hw_phy_work_func_t);
> @@ -5646,6 +6385,10 @@ static int rtl8152_probe(struct usb_interface *intf,
> intf->needs_remote_wakeup = 1;
>
> tp->rtl_ops.init(tp);
> +#if IS_BUILTIN(CONFIG_USB_RTL8152)
> + /* Retry in case request_firmware() is not ready yet. */
> + tp->rtl_fw.retry = true;
> +#endif
> queue_delayed_work(system_long_wq, &tp->hw_phy_work, 0);
> set_ethernet_addr(tp);
>
> @@ -5691,6 +6434,7 @@ static void rtl8152_disconnect(struct usb_interface
> *intf)
> tasklet_kill(&tp->tx_tl);
> cancel_delayed_work_sync(&tp->hw_phy_work);
> tp->rtl_ops.unload(tp);
> + rtl8152_release_firmware(tp);
> free_netdev(tp->netdev);
> }
> }
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
guaranteed for some hardware.
Does it mean that the fix proposed by Eric is not the proper solution?
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Hi Eric,
On 2018-02-27 15:07, Eric Dumazet wrote:
On Tue, 2018-02-27 at 08:26 +0100, Marek Szyprowski wrote:
I've noticed that USBnet/ASIX AX88772B USB driver produces deplock kernel
warning ("inconsistent lock state") on Chromebook2 Peach-PIT board. No
special activity is need
Hi Oliver,
On 2018-02-27 11:37, Oliver Neukum wrote:
Am Dienstag, den 27.02.2018, 08:26 +0100 schrieb Marek Szyprowski:
I've noticed that USBnet/ASIX AX88772B USB driver produces deplock kernel
warning ("inconsistent lock state") on Chromebook2 Peach-PIT board. No
Is that 32
18.160704] [] (__schedule) from []
(schedule_idle+0x2c/0x78)
[ 18.160711] [] (schedule_idle) from []
(cpu_startup_entry+0x18/0x1c)
[ 18.200726] [] (cpu_startup_entry) from []
(start_kernel+0x394/0x400)
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Hi Christoph,
On 2017-06-20 15:16, Christoph Hellwig wrote:
On Tue, Jun 20, 2017 at 11:04:00PM +1000, Stephen Rothwell wrote:
git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git#dma-mapping-next
Contacts: Marek Szyprowski and Kyungmin Park (cc'd)
I have called your tree dma-ma
30 matches
Mail list logo
