Re: NETDEV WATCHDOG: internal(r8152): transmit queue 0 timed out

Re: NETDEV WATCHDOG: internal(r8152): transmit queue 0 timed out

[poma]

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.

RE: NETDEV WATCHDOG: internal(r8152): transmit queue 0 timed out

[Hayes Wang]

 poma [mailto:pomidorabelisima-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] 
> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NETDEV WATCHDOG: internal(r8152): transmit queue 0 timed out

[poma]

On 16.01.2015 10:37, Hayes Wang wrote:
>  poma [mailto:pomidorabelisima@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

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: NETDEV WATCHDOG: internal(r8152): transmit queue 0 timed out

[sean darcy]

On 01/16/2015 07:09 AM, poma wrote:
> On 16.01.2015 10:37, Hayes Wang wrote:
>>   poma [mailto:pomidorabelisima@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, will do.

In the meantime, here's the kernel log showing the timeout, the removal 
of the usb ethernet adapter, and it's reinsertion:


Jan 15 00:15:18 kernel: r8152 2-1:1.0 internal: Tx timeout
Jan 15 00:15:23 kernel: r8152 2-1:1.0 internal: Tx timeout
Jan 15 00:15:29 kernel: usb 2-1: USB disconnect, device number 4
Jan 15 00:15:29 kernel: r8152 2-1:1.0 internal: Tx status -108
.....................
Jan 15 00:15:29 kernel: r8152 2-1:1.0 internal: Tx status -108
Jan 15 00:15:29 kernel: r8152 2-1:1.0 internal: Tx status -108
Jan 15 00:15:31 kernel: usb 2-1: new high-speed USB device number 5 
using ehci-pci
Jan 15 00:15:31 kernel: usb 2-1: New USB device found, idVendor=0bda, 
idProduct=8152
Jan 15 00:15:31 kernel: usb 2-1: New USB device strings: Mfr=1, 
Product=2, SerialNumber=3
Jan 15 00:15:31 kernel: usb 2-1: Product: USB 10/100 LAN
Jan 15 00:15:31 kernel: usb 2-1: Manufacturer: CE-LINK
Jan 15 00:15:31 kernel: usb 2-1: SerialNumber: ...........
Jan 15 00:15:31 kernel: usb 2-1: reset high-speed USB device number 5 
using ehci-pci
Jan 15 00:15:31 kernel: r8152 2-1:1.0 eth0: v1.06.1 (2014/10/01)
Jan 15 00:15:32 kernel: r8152 2-1:1.0 internal: renamed from eth0
Jan 15 00:15:32 systemd-udevd[12869]: renamed network interface eth0 to 
internal
Jan 15 00:15:32 kernel: IPv6: ADDRCONF(NETDEV_UP): internal: link is not 
ready
Jan 15 00:15:34 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): internal: link 
becomes ready


-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: NETDEV WATCHDOG: internal(r8152): transmit queue 0 timed out

[sean darcy]

On 01/16/2015 07:09 AM, poma wrote:
> On 16.01.2015 10:37, Hayes Wang wrote:
>>   poma [mailto:pomidorabelisima@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 
know that this module has been incorporated in the running kernel. 
modinfo doesn't give any version info.

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

Thanks for all your help.

sean

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: NETDEV WATCHDOG: internal(r8152): transmit queue 0 timed out

[poma]

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:pomidorabelisima@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



-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: NETDEV WATCHDOG: internal(r8152): transmit queue 0 timed out

[poma]

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:pomidorabelisima-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
>>>>> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html