Re: NETDEV WATCHDOG: internal(r8152): transmit queue 0 timed out
On 17.01.2015 09:56, poma wrote: > On 17.01.2015 00:57, sean darcy wrote: >> On 01/16/2015 07:09 AM, poma wrote: >>> On 16.01.2015 10:37, Hayes Wang wrote: poma [mailto:pomidorabelis...@gmail.com] > Sent: Friday, January 16, 2015 4:25 PM [...] >> This looks like a USB problem. Is there a way to get usb (or >> NetworkManager) to reinitialize the driver when this happens? > > I would ask these people for advice, therefore. Our hw engineers need to analyse the behavior of the device. However, I don't think you have such instrument to provide the required information. If we don't know the reason, we couldn't give you the proper solution. Besides, your solution would work if and only if reloading the driver is helpful. The issue have to debug from the hardware, and I have no idea about what the software could do before analysing the hw. Maybe you could try the following driver first to check if it is useful. http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=2&PNid=13&PFid=56&Level=5&Conn=4&DownTypeID=3&GetDown=false Best Regards, Hayes >>> >>> Thanks for your response, Mr. Hayes. >>> >>> Mr. Sean, please download and check if "timeout" is still present with >>> built RTL8153 module from REALTEK site, as Mr. Hayes proposed. >>> http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=2&PNid=13&PFid=56&Level=5&Conn=4&DownTypeID=3&GetDown=false#2 >>> r8152.53-2.03.0.tar.bz2 >>> >>> Procedure - should be equal for both, Fedora 21 & 20: >>> >>> $ uname -r >>> 3.17.8-300.fc21.x86_64 >>> >>> $ su -c 'yum install kernel-devel' >>> >>> $ tar xf r8152.53-2.03.0.tar.bz2 >>> $ cd r8152-2.03.0/ >>> $ make >>> $ su >>> >>> # cp 50-usb-realtek-net.rules /etc/udev/rules.d/ >>> # udevadm trigger --action=add >>> >>> # modprobe -rv r8152 >>> # cp r8152.ko /lib/modules/$(uname -r)/updates/ >>> # depmod >>> # modprobe -v r8152 >>> >>> >>> poma >>> >> OK. Did all that. Now to see if I get the same problem over the next >> couple of weeks. >> >> I'd never heard about the updates subfolder in modules. Very slick. >> >> But when I update the kernel, I get to do this again correct? How will I > > $ cd r8152-2.03.0/ > $ make clean > $ make > $ su > > # cp r8152.ko /lib/modules/$(uname -r)/updates/ > # depmod > # modprobe -v r8152 > > is part of the procedure necessary for a new i.e. an upgraded kernel. > > >> know that this module has been incorporated in the running kernel. >> modinfo doesn't give any version info. >> > > $ modinfo r8152 -n > > will show the module considered for loading. > > >> BTW, I'm not sure what modprobe --dump-modversions is supposed to do, >> but it doesn't: >> >> #modprobe --dump-modversions r8152 >> modprobe: FATAL: Module r8152 not found. >> # modprobe --dump-modversions r8152.ko >> modprobe: FATAL: Module r8152.ko not found. >> #lsmod | grep 8152 >> r8152 49646 0 >> > > "--dump-modversions" will probably show the same error for any module. > > >> Thanks for all your help. >> >> sean >> > > YW > > > Mr. Sean, is your problem with r8152 resolved, are "kernel: r8152 2-2:1.0 internal: Tx timeout" still present? -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: NETDEV WATCHDOG: internal(r8152): transmit queue 0 timed out
On 17.01.2015 00:57, sean darcy wrote: > On 01/16/2015 07:09 AM, poma wrote: >> On 16.01.2015 10:37, Hayes Wang wrote: >>> poma [mailto:pomidorabelis...@gmail.com] Sent: Friday, January 16, 2015 4:25 PM >>> [...] > This looks like a USB problem. Is there a way to get usb (or > NetworkManager) to reinitialize the driver when this happens? I would ask these people for advice, therefore. >>> >>> Our hw engineers need to analyse the behavior of the device. >>> However, I don't think you have such instrument to provide >>> the required information. If we don't know the reason, we >>> couldn't give you the proper solution. Besides, your solution >>> would work if and only if reloading the driver is helpful. >>> >>> The issue have to debug from the hardware, and I have no idea >>> about what the software could do before analysing the hw. Maybe >>> you could try the following driver first to check if it is useful. >>> >>> http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=2&PNid=13&PFid=56&Level=5&Conn=4&DownTypeID=3&GetDown=false >>> >>> Best Regards, >>> Hayes >>> >> >> Thanks for your response, Mr. Hayes. >> >> Mr. Sean, please download and check if "timeout" is still present with built >> RTL8153 module from REALTEK site, as Mr. Hayes proposed. >> http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=2&PNid=13&PFid=56&Level=5&Conn=4&DownTypeID=3&GetDown=false#2 >> r8152.53-2.03.0.tar.bz2 >> >> Procedure - should be equal for both, Fedora 21 & 20: >> >> $ uname -r >> 3.17.8-300.fc21.x86_64 >> >> $ su -c 'yum install kernel-devel' >> >> $ tar xf r8152.53-2.03.0.tar.bz2 >> $ cd r8152-2.03.0/ >> $ make >> $ su >> >> # cp 50-usb-realtek-net.rules /etc/udev/rules.d/ >> # udevadm trigger --action=add >> >> # modprobe -rv r8152 >> # cp r8152.ko /lib/modules/$(uname -r)/updates/ >> # depmod >> # modprobe -v r8152 >> >> >> poma >> > OK. Did all that. Now to see if I get the same problem over the next > couple of weeks. > > I'd never heard about the updates subfolder in modules. Very slick. > > But when I update the kernel, I get to do this again correct? How will I $ cd r8152-2.03.0/ $ make clean $ make $ su # cp r8152.ko /lib/modules/$(uname -r)/updates/ # depmod # modprobe -v r8152 is part of the procedure necessary for a new i.e. an upgraded kernel. > know that this module has been incorporated in the running kernel. > modinfo doesn't give any version info. > $ modinfo r8152 -n will show the module considered for loading. > BTW, I'm not sure what modprobe --dump-modversions is supposed to do, > but it doesn't: > > #modprobe --dump-modversions r8152 > modprobe: FATAL: Module r8152 not found. > # modprobe --dump-modversions r8152.ko > modprobe: FATAL: Module r8152.ko not found. > #lsmod | grep 8152 > r8152 49646 0 > "--dump-modversions" will probably show the same error for any module. > Thanks for all your help. > > sean > YW -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: NETDEV WATCHDOG: internal(r8152): transmit queue 0 timed out
On 16.01.2015 10:37, Hayes Wang wrote: > poma [mailto:pomidorabelis...@gmail.com] >> Sent: Friday, January 16, 2015 4:25 PM > [...] >>> This looks like a USB problem. Is there a way to get usb (or >>> NetworkManager) to reinitialize the driver when this happens? >> >> I would ask these people for advice, therefore. > > Our hw engineers need to analyse the behavior of the device. > However, I don't think you have such instrument to provide > the required information. If we don't know the reason, we > couldn't give you the proper solution. Besides, your solution > would work if and only if reloading the driver is helpful. > > The issue have to debug from the hardware, and I have no idea > about what the software could do before analysing the hw. Maybe > you could try the following driver first to check if it is useful. > > http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=2&PNid=13&PFid=56&Level=5&Conn=4&DownTypeID=3&GetDown=false > > Best Regards, > Hayes > Thanks for your response, Mr. Hayes. Mr. Sean, please download and check if "timeout" is still present with built RTL8153 module from REALTEK site, as Mr. Hayes proposed. http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=2&PNid=13&PFid=56&Level=5&Conn=4&DownTypeID=3&GetDown=false#2 r8152.53-2.03.0.tar.bz2 Procedure - should be equal for both, Fedora 21 & 20: $ uname -r 3.17.8-300.fc21.x86_64 $ su -c 'yum install kernel-devel' $ tar xf r8152.53-2.03.0.tar.bz2 $ cd r8152-2.03.0/ $ make $ su # cp 50-usb-realtek-net.rules /etc/udev/rules.d/ # udevadm trigger --action=add # modprobe -rv r8152 # cp r8152.ko /lib/modules/$(uname -r)/updates/ # depmod # modprobe -v r8152 poma -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: NETDEV WATCHDOG: internal(r8152): transmit queue 0 timed out
poma [mailto:pomidorabelis...@gmail.com] > Sent: Friday, January 16, 2015 4:25 PM [...] > > This looks like a USB problem. Is there a way to get usb (or > > NetworkManager) to reinitialize the driver when this happens? > > I would ask these people for advice, therefore. Our hw engineers need to analyse the behavior of the device. However, I don't think you have such instrument to provide the required information. If we don't know the reason, we couldn't give you the proper solution. Besides, your solution would work if and only if reloading the driver is helpful. The issue have to debug from the hardware, and I have no idea about what the software could do before analysing the hw. Maybe you could try the following driver first to check if it is useful. http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=2&PNid=13&PFid=56&Level=5&Conn=4&DownTypeID=3&GetDown=false Best Regards, Hayes -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: NETDEV WATCHDOG: internal(r8152): transmit queue 0 timed out
On 16.01.2015 00:38, sean darcy wrote: > I've got F20 on an old laptop I'm using as a router. The external > interface uses the RJ45 port. The internal uses a USB ethernet adapter. > Every 2-3 weeks, the internal USB adapter fails. I can fix it by just > moving it to the other USB port. In another 2-3 weeks, it will fail > again, and I move it back to the original USB port, and so on. > > No problems with the external RJ45 interface. > > The logs aren't very helpful: > > 12:39:22 kernel: NETDEV WATCHDOG: internal (r8152): transmit queue 0 > timed out > 12:39:22 kernel: Modules linked in: xt_conntrack xt_nat ipt_MASQUERADE > xt_DSCP iptable_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 > nf_nat_ipv4 iptable_raw sch_pie nf_nat_sip nf_nat nf_conntrack_sip > nf_conntrack bnep bluetooth arc4 snd_hda_codec_hdmi > snd_hda_codec_realtek b43 bcma snd_hda_codec_generic snd_hda_intel > snd_hda_controller mac80211 snd_hda_codec uvcvideo snd_hwdep snd_seq > snd_seq_device coretemp sdhci_pci snd_pcm acer_wmi videobuf2_vmalloc > cfg80211 sparse_keymap microcode sdhci videobuf2_memops iTCO_wdt > videobuf2_core rfkill iTCO_vendor_support v4l2_common tg3 ssb cdc_ether > ptp joydev pps_core usbnet videodev media i2c_i801 serio_raw mmc_core > irda r8152 lpc_ich shpchp tifm_7xx1 snd_timer snd soundcore mfd_core > tifm_core crc_ccitt wmi mii acpi_cpufreq firewire_ohci firewire_core > crc_itu_t > 12:39:22 kernel: r8152 2-2:1.0 internal: Tx timeout > 12:39:23 kernel: r8152 2-2:1.0 internal: Tx timeout > 12:39:24 kernel: r8152 2-2:1.0 internal: Tx timeout > .. > > This looks like a USB problem. Is there a way to get usb (or > NetworkManager) to reinitialize the driver when this happens? > > sean > > I would ask these people for advice, therefore. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
