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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <54BA23CE.70001@gmail.com>
Date:	Sat, 17 Jan 2015 09:56:46 +0100
From:	poma <pomidorabelisima@...il.com>
To:	Community support for Fedora users <users@...ts.fedoraproject.org>
CC:	netdev@...r.kernel.org, linux-usb@...r.kernel.org
Subject: 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:pomidorabelisima@...il.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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html