Re: [PATCH 06/11] net: usb: mcs7830: use new api ethtool_{get|set}_link_ksettings

[poma]

On 16.03.2017 23:18, Philippe Reynes wrote:
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
> 
> As I don't have the hardware, I'd be very pleased if
> someone may test this patch.
> 
> Signed-off-by: Philippe Reynes <trem...@gmail.com>
> ---
>  drivers/net/usb/mcs7830.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/usb/mcs7830.c b/drivers/net/usb/mcs7830.c
> index 4f345bd..5771ff2 100644
> --- a/drivers/net/usb/mcs7830.c
> +++ b/drivers/net/usb/mcs7830.c
> @@ -464,9 +464,9 @@ static void mcs7830_get_regs(struct net_device *net, 
> struct ethtool_regs *regs,
>   .get_link   = usbnet_get_link,
>   .get_msglevel   = usbnet_get_msglevel,
>   .set_msglevel   = usbnet_set_msglevel,
> - .get_settings   = usbnet_get_settings,
> - .set_settings   = usbnet_set_settings,
>   .nway_reset = usbnet_nway_reset,
> + .get_link_ksettings = usbnet_get_link_ksettings,
> + .set_link_ksettings = usbnet_set_link_ksettings,
>  };
>  
>  static const struct net_device_ops mcs7830_netdev_ops = {
> 

$ modinfo mcs7830 usbnet mii -n
/lib/modules/4.11.0-0.rc3.git0.1.fc26.x86_64/updates/mcs7830.ko
/lib/modules/4.11.0-0.rc3.git0.1.fc26.x86_64/updates/usbnet.ko
/lib/modules/4.11.0-0.rc3.git0.1.fc26.x86_64/updates/mii.ko

$ lsmod | grep mcs7830
mcs783016384  0
usbnet 45056  1 mcs7830
mii16384  2 usbnet,mcs7830

$ nmcli -f GENERAL.DRIVER,GENERAL.STATE device show enp0s4f1u4
GENERAL.DRIVER: MOSCHIP usb-ethernet driver
GENERAL.STATE:  100 (connected)

Tested-by: poma <p...@gmail.com>

--
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: crash by cdc_acm driver in kernels 4.8-rc1/5

[poma]

On 21.11.2016 21:23, Wim Osterholt wrote:
> On Mon, Nov 21, 2016 at 04:58:25PM +0100, Wim Osterholt wrote:
>>
>> I didn't find traces of kernel-4.9-rc5 being ran on any of my laptops, so I
>> can't have seen a crash on rc5. It seems rc5 and rc6 is safe now.
> 
> Neither 4.8.10, nor 4.8.9 show the bug.
> It must be a bug ouside cdc_acm that they have fixed. (a late propagation of
> the IRQ-penalty-bug-fix maybe?)
> 
> I'm rebuilding 4.8.8 now.
> 
> Groeten, Wim.
> 


After all the patching and testing I concluded the same, 
breakage came and is gone outside drivers/usb/class/
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/diff/?id=v4.9-rc5=v4.9-rc4

--
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: crash by cdc_acm driver in kernels 4.8-rc1/5

[poma]

On 15.11.2016 01:16, Wim Osterholt wrote:
> On Tue, Oct 18, 2016 at 02:18:43PM +0200, Oliver Neukum wrote:
> 
>> It definitely does not crash and is probed and your .config is not
>> extremely unusual.
> 
> Hmmm.
> 
>> ... Something odd is going on.
> 
> Whell, yes.
> The only thing that appears you'll have to do is unset 'CONFIG_SMP'.
> 
> My machines didn't have the luxury of multicore processors (until recently),
> so there never has been any reason to deliberately switch these options on!
> 
> In the process of searching, many options may have changed. The crash/OOPS
> has now mitigated into just a WARNING with a call trace.
> (Or it could be a totally different bug?)
> After the call trace the device is working normally and a shutdown
> completes to the end now.
> That is with the config given here:
> http://webserver.djo.tudelft.nl/.config-4.9-rc4.OK (CONFIG_SMP=y)
> http://webserver.djo.tudelft.nl/WARNING-4.9-rc4(call trace for C_S unset)
> 
> Tests on other machines with (slightly) different configs all seem to
> confirm that the problems are gone when CONFIG_SMP is set.
> 
> Regards, Wim.
> 
> 

Try retest with mainline 4.9-rc5,
CONFIG_SMP was not crucial[1].

$ grep CONFIG_SMP /boot/config-4.9.0-0.rc5.git0.1.fc26.x86_64*
/boot/config-4.9.0-0.rc5.git0.1.fc26.x86_64:CONFIG_SMP=y
/boot/config-4.9.0-0.rc5.git0.1.fc26.x86_64+debug:CONFIG_SMP=y

[1] https://www.spinics.net/lists/linux-usb/msg148852.html


--
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: cdc_acm: debug - BUG - Oops

[poma]

On 08.11.2016 10:43, poma wrote:
> 
> Helloo!
> 
> Via Master Chef's debug kernel, the device ist kaputt.
> Can you explain why this is happening specifically with the kernel's debug 
> facility.
> 
> $ uname -r
> 4.9.0-0.rc4.git0.1.fc26.x86_64
> 
> $ file /dev/ttyACM0
> /dev/ttyACM0: character special (166/0)
> 
> $ dmesg -t | grep acm
> cdc_acm 2-3:1.0: ttyACM0: USB ACM device
> usbcore: registered new interface driver cdc_acm
> cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
> 
> 
> 
> $ uname -r
> 4.9.0-0.rc4.git0.1.fc26.x86_64+debug
> 
> $ file /dev/ttyACM0
> /dev/ttyACM0: cannot open `/dev/ttyACM0' (No such file or directory)
> 
> $ dmesg -t
> ...
> BUG: unable to handle kernel NULL pointer dereference at 0249
> IP: [] acm_probe+0x4e1/0x11a0 [cdc_acm]
> PGD 0 
> 
> Oops:  [#1] SMP
> Modules linked in: ... cdc_acm(+) ...
> CPU: 2 PID: 374 Comm: systemd-udevd Not tainted 
> 4.9.0-0.rc4.git0.1.fc26.x86_64+debug #1
> ...
> task: 9ae607c6 task.stack: b93740cdc000
> RIP: 0010:[]  [] acm_probe+0x4e1/0x11a0 
> [cdc_acm]
> RSP: 0018:b93740cdf9c0  EFLAGS: 00010202
> RAX: 0246 RBX: 9ae607732800 RCX: 
> RDX: 0040 RSI: 9ae607c60960 RDI: b93740cdf968
> RBP: b93740cdfae8 R08:  R09: 
> R10:  R11:  R12: 9ae607732800
> R13: 9ae607737000 R14:  R15: 9ae6067fb000
> FS:  7f6daa69c8c0() GS:9ae60f80() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 0249 CR3: c7eeb000 CR4: 06e0
> ...
> Call Trace:
>  [] ? sched_clock_cpu+0x90/0xc0
>  [] ? mutex_unlock+0xe/0x10
>  [] ? trace_hardirqs_on_caller+0xf5/0x1b0
>  [] ? trace_hardirqs_on+0xd/0x10
>  [] ? __mutex_unlock_slowpath+0xfa/0x1c0
>  [] usb_probe_interface+0x15f/0x2d0
>  [] driver_probe_device+0x223/0x430
>  [] __driver_attach+0xe3/0xf0
>  [] ? driver_probe_device+0x430/0x430
>  [] bus_for_each_dev+0x73/0xc0
>  [] driver_attach+0x1e/0x20
>  [] bus_add_driver+0x173/0x270
>  [] driver_register+0x60/0xe0
>  [] usb_register_driver+0xaa/0x160
>  [] ? 0xc0462000
>  [] acm_init+0xc2/0x1000 [cdc_acm]
>  [] do_one_initcall+0x50/0x180
>  [] ? rcu_read_lock_sched_held+0x45/0x80
>  [] ? kmem_cache_alloc_trace+0x277/0x2d0
>  [] ? do_init_module+0x27/0x1f1
>  [] do_init_module+0x5f/0x1f1
>  [] load_module+0x2401/0x2b40
>  [] ? __symbol_put+0x70/0x70
>  [] ? sched_clock_cpu+0x90/0xc0
>  [] SYSC_init_module+0x19b/0x1c0
>  [] SyS_init_module+0xe/0x10
>  [] do_syscall_64+0x6c/0x1f0
>  [] entry_SYSCALL64_slow_path+0x25/0x25
> Code: 10 41 89 8f ec 0b 00 00 8d 04 80 c1 e0 02 41 89 87 e0 0b 00 00 48 8b 85 
> 48 ff ff ff 49 89 07 48 8b 85 70 ff ff ff 48 85 c0 74 0b <0f> b6 40 03 41 89 
> 87 f4 0b 00 00 f6 85 50 ff ff ff 04 74 08 41 
> RIP  [] acm_probe+0x4e1/0x11a0 [cdc_acm]
>  RSP 
> CR2: 0249
> ---[ end trace 526abbefa545cbb3 ]---
> 
> 
> 
> $ diff -u /boot/config-4.9.0-0.rc4.git0.1.fc26.x86_64 
> /boot/config-4.9.0-0.rc4.git0.1.fc26.x86_64+debug
> ...
> -# Linux/x86_64 4.9.0-0.rc4.git0.1.fc26.x86_64 Kernel Configuration
> +# Linux/x86_64 4.9.0-0.rc4.git0.1.fc26.x86_64+debug Kernel Configuration
> ...
> -# CONFIG_DEBUG_BLK_CGROUP is not set
> +CONFIG_DEBUG_BLK_CGROUP=y
> ...
> +CONFIG_PERF_USE_VMALLOC=y
> ...
> -# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
> +CONFIG_DEBUG_PERF_USE_VMALLOC=y
> ...
> -# CONFIG_MODULE_FORCE_UNLOAD is not set
> +CONFIG_MODULE_FORCE_UNLOAD=y
> ...
> -CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
> -CONFIG_INLINE_READ_UNLOCK=y
> -CONFIG_INLINE_READ_UNLOCK_IRQ=y
> -CONFIG_INLINE_WRITE_UNLOCK=y
> -CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
> +CONFIG_UNINLINE_SPIN_UNLOCK=y
> -CONFIG_MUTEX_SPIN_ON_OWNER=y
> ...
> +CONFIG_PREEMPT_COUNT=y
> ...
> -# CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK is not set
> +CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y
> ...
> -# CONFIG_ACPI_DEBUG is not set
> +CONFIG_ACPI_DEBUG=y
> ...
> -# CONFIG_CAN_DEBUG_DEVICES is not set
> +CONFIG_CAN_DEBUG_DEVICES=y
> ...
> -# CONFIG_MAC80211_MESSAGE_TRACING is not set
> +CONFIG_MAC80211_MESSAGE_TRACING=y
> ...
> -# CONFIG_CEPH_LIB_PRETTYDEBUG is not set
> +CONFIG_CEPH_LIB_PRETTYDEBUG=y
> ...
> -# CONFIG_DRBD_FAULT_INJECTION is not set
> +CONFIG_DRBD_FAULT_INJECTION=y
> ...
> -# CONFIG_ATH_DEBUG is not set
> +CONFIG_ATH_DEBUG=y
> +# CONFIG_ATH_TRACEPOINTS is not set
> ...
> -# CONFIG_CARL9170_DEBUGFS is not set
&

cdc_acm: debug - BUG - Oops

[poma]

Helloo!

Via Master Chef's debug kernel, the device ist kaputt.
Can you explain why this is happening specifically with the kernel's debug 
facility.

$ uname -r
4.9.0-0.rc4.git0.1.fc26.x86_64

$ file /dev/ttyACM0
/dev/ttyACM0: character special (166/0)

$ dmesg -t | grep acm
cdc_acm 2-3:1.0: ttyACM0: USB ACM device
usbcore: registered new interface driver cdc_acm
cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters



$ uname -r
4.9.0-0.rc4.git0.1.fc26.x86_64+debug

$ file /dev/ttyACM0
/dev/ttyACM0: cannot open `/dev/ttyACM0' (No such file or directory)

$ dmesg -t
...
BUG: unable to handle kernel NULL pointer dereference at 0249
IP: [] acm_probe+0x4e1/0x11a0 [cdc_acm]
PGD 0 

Oops:  [#1] SMP
Modules linked in: ... cdc_acm(+) ...
CPU: 2 PID: 374 Comm: systemd-udevd Not tainted 
4.9.0-0.rc4.git0.1.fc26.x86_64+debug #1
...
task: 9ae607c6 task.stack: b93740cdc000
RIP: 0010:[]  [] acm_probe+0x4e1/0x11a0 
[cdc_acm]
RSP: 0018:b93740cdf9c0  EFLAGS: 00010202
RAX: 0246 RBX: 9ae607732800 RCX: 
RDX: 0040 RSI: 9ae607c60960 RDI: b93740cdf968
RBP: b93740cdfae8 R08:  R09: 
R10:  R11:  R12: 9ae607732800
R13: 9ae607737000 R14:  R15: 9ae6067fb000
FS:  7f6daa69c8c0() GS:9ae60f80() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0249 CR3: c7eeb000 CR4: 06e0
...
Call Trace:
 [] ? sched_clock_cpu+0x90/0xc0
 [] ? mutex_unlock+0xe/0x10
 [] ? trace_hardirqs_on_caller+0xf5/0x1b0
 [] ? trace_hardirqs_on+0xd/0x10
 [] ? __mutex_unlock_slowpath+0xfa/0x1c0
 [] usb_probe_interface+0x15f/0x2d0
 [] driver_probe_device+0x223/0x430
 [] __driver_attach+0xe3/0xf0
 [] ? driver_probe_device+0x430/0x430
 [] bus_for_each_dev+0x73/0xc0
 [] driver_attach+0x1e/0x20
 [] bus_add_driver+0x173/0x270
 [] driver_register+0x60/0xe0
 [] usb_register_driver+0xaa/0x160
 [] ? 0xc0462000
 [] acm_init+0xc2/0x1000 [cdc_acm]
 [] do_one_initcall+0x50/0x180
 [] ? rcu_read_lock_sched_held+0x45/0x80
 [] ? kmem_cache_alloc_trace+0x277/0x2d0
 [] ? do_init_module+0x27/0x1f1
 [] do_init_module+0x5f/0x1f1
 [] load_module+0x2401/0x2b40
 [] ? __symbol_put+0x70/0x70
 [] ? sched_clock_cpu+0x90/0xc0
 [] SYSC_init_module+0x19b/0x1c0
 [] SyS_init_module+0xe/0x10
 [] do_syscall_64+0x6c/0x1f0
 [] entry_SYSCALL64_slow_path+0x25/0x25
Code: 10 41 89 8f ec 0b 00 00 8d 04 80 c1 e0 02 41 89 87 e0 0b 00 00 48 8b 85 
48 ff ff ff 49 89 07 48 8b 85 70 ff ff ff 48 85 c0 74 0b <0f> b6 40 03 41 89 87 
f4 0b 00 00 f6 85 50 ff ff ff 04 74 08 41 
RIP  [] acm_probe+0x4e1/0x11a0 [cdc_acm]
 RSP 
CR2: 0249
---[ end trace 526abbefa545cbb3 ]---



$ diff -u /boot/config-4.9.0-0.rc4.git0.1.fc26.x86_64 
/boot/config-4.9.0-0.rc4.git0.1.fc26.x86_64+debug
...
-# Linux/x86_64 4.9.0-0.rc4.git0.1.fc26.x86_64 Kernel Configuration
+# Linux/x86_64 4.9.0-0.rc4.git0.1.fc26.x86_64+debug Kernel Configuration
...
-# CONFIG_DEBUG_BLK_CGROUP is not set
+CONFIG_DEBUG_BLK_CGROUP=y
...
+CONFIG_PERF_USE_VMALLOC=y
...
-# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
+CONFIG_DEBUG_PERF_USE_VMALLOC=y
...
-# CONFIG_MODULE_FORCE_UNLOAD is not set
+CONFIG_MODULE_FORCE_UNLOAD=y
...
-CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
-CONFIG_INLINE_READ_UNLOCK=y
-CONFIG_INLINE_READ_UNLOCK_IRQ=y
-CONFIG_INLINE_WRITE_UNLOCK=y
-CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
+CONFIG_UNINLINE_SPIN_UNLOCK=y
-CONFIG_MUTEX_SPIN_ON_OWNER=y
...
+CONFIG_PREEMPT_COUNT=y
...
-# CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK is not set
+CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y
...
-# CONFIG_ACPI_DEBUG is not set
+CONFIG_ACPI_DEBUG=y
...
-# CONFIG_CAN_DEBUG_DEVICES is not set
+CONFIG_CAN_DEBUG_DEVICES=y
...
-# CONFIG_MAC80211_MESSAGE_TRACING is not set
+CONFIG_MAC80211_MESSAGE_TRACING=y
...
-# CONFIG_CEPH_LIB_PRETTYDEBUG is not set
+CONFIG_CEPH_LIB_PRETTYDEBUG=y
...
-# CONFIG_DRBD_FAULT_INJECTION is not set
+CONFIG_DRBD_FAULT_INJECTION=y
...
-# CONFIG_ATH_DEBUG is not set
+CONFIG_ATH_DEBUG=y
+# CONFIG_ATH_TRACEPOINTS is not set
...
-# CONFIG_CARL9170_DEBUGFS is not set
+CONFIG_CARL9170_DEBUGFS=y
...
-# CONFIG_IWLWIFI_DEVICE_TRACING is not set
+CONFIG_IWLWIFI_DEVICE_TRACING=y
...
-# CONFIG_RTLWIFI_DEBUG is not set
+CONFIG_RTLWIFI_DEBUG=y
...
-# CONFIG_SPI_DEBUG is not set
+CONFIG_SPI_DEBUG=y
...
-# CONFIG_EDAC_DEBUG is not set
+CONFIG_EDAC_DEBUG=y
...
-# CONFIG_DMADEVICES_DEBUG is not set
+CONFIG_DMADEVICES_DEBUG=y
+# CONFIG_DMADEVICES_VDEBUG is not set
...
-# CONFIG_EFI_TEST is not set
+CONFIG_EFI_TEST=y
...
-# CONFIG_EXT4_DEBUG is not set
+CONFIG_EXT4_DEBUG=y
...
-# CONFIG_JBD2_DEBUG is not set
+CONFIG_JBD2_DEBUG=y
...
-# CONFIG_XFS_WARN is not set
+CONFIG_XFS_WARN=y
...
-# CONFIG_QUOTA_DEBUG is not set
+CONFIG_QUOTA_DEBUG=y
...
-# CONFIG_NFSD_FAULT_INJECTION is not set
+CONFIG_NFSD_FAULT_INJECTION=y
...
-# 

Re: GDM7240 - NULL pointer dereference

[poma]

On 03.04.2016 12:15, Alex wrote:
> Hello,
> [1.] System hang when connecting USB modem (LU150)
> [2.] I'm running 4.4.5 kernel (Arch Linux). When this modem is connected 
> I'm getting below trace in journal and system becomes unusable - lsusb, 
> logout and some other operations lead to a complete hang, the only way 
> out is hardware power off. This modem works perfectly on 4.1.20 kernel - 
> attaching all outputs for both kernels.
...

See if it is related to
http://thread.gmane.org/gmane.linux.usb.general/135626

if so, kernel >= 4.5
i.e.
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/net/usb/cdc_ether.c?h=linux-4.5.y=29c6dd5

--
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: rtl8xxxu 4.4.5(from f23): I get a panic adding a new device to the driver

[poma]

On 17.03.2016 19:02, Jes Sorensen wrote:
> Jes Sorensen  writes:
>> Xose Vazquez Perez  writes:
>>> Hi,
>>>
>>> If I do:
>>> # echo "0bda 8176" > /sys/bus/usb/drivers/rtl8xxxu/new_id
>>
>> Hi Xose,
>>
>> Yes please don't do that. The rtl8xxxu driver relies on the .driver_info
>> field in struct use_device_id to carry information for the different
>> types of devices. If you hot add a device like above, the driver will
>> fail because that field now contains a NULL pointer.
>>
>> I should probably add a check for it in the probe function, but it will
>> simply be there to spit out a warning that it doesn't work to hot add a
>> device like this.
>>
>> If you build it with CONFIG_RTL8XXXU_UNTESTED the 0bda:8176 should be
>> included in the device list.
>>
>> Cheers,
>> Jes
> 
> Hi Xose,
> 
> I added the following patch to my tree to avoid this.
> 
> Cheers,
> Jes
> 
> commit 9202f4947aac1d60084ee79c9b5294eb42ba59dc
> Author: Jes Sorensen 
> Date:   Thu Mar 17 13:53:48 2016 -0400
> 
> rtl8xxxu: Fix OOPS if user tries to add device via /sys
> 
> This driver relies on driver_info in struct usb_device_id, hence
> adding a device via  /sys/bus/usb/drivers/rtl8xxxu/new_id would result
> in a NULL pointer dereference.
> 
> Instead print a message and return -ENODEV
> 
> Reported-by: Xose Vazquez Perez 
> Signed-off-by: Jes Sorensen 
> 
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.c 
> b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.c
> index 8d893f4..55fc00e 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.c
> @@ -9671,6 +9671,15 @@ static int rtl8xxxu_probe(struct usb_interface 
> *interface,
>  
>   udev = usb_get_dev(interface_to_usbdev(interface));
>  
> + if (!id->driver_info) {
> + dev_warn(>dev,
> +  "rtl8xxxu relies on driver_info in struct 
> usb_device_id.\n");
> + dev_warn(>dev,
> +  "Adding a device via 
> /sys/bus/usb/drivers/rtl8xxxu/new_id is not supported!\n");
> + ret = -ENODEV;
> + goto exit;
> + }
> +
>   switch (id->idVendor) {
>   case USB_VENDOR_ID_REALTEK:
>   switch(id->idProduct) {
>


Dynamic adding and removing a new device IDs to a USB device drivers
via /sys/bus/usb/drivers/.../[new_id|remove_id]
https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-bus-usb

is not supported only with rtl8xxxu?


--
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]

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=2PNid=13PFid=56Level=5Conn=4DownTypeID=3GetDown=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=2PNid=13PFid=56Level=5Conn=4DownTypeID=3GetDown=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

[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: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=2PNid=13PFid=56Level=5Conn=4DownTypeID=3GetDown=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=2PNid=13PFid=56Level=5Conn=4DownTypeID=3GetDown=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

[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.

--
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]

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=2PNid=13PFid=56Level=5Conn=4DownTypeID=3GetDown=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=2PNid=13PFid=56Level=5Conn=4DownTypeID=3GetDown=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: Displaylink Attached Display Adapater and Monitor Not Recognized

[poma]

https://lkml.org/lkml/2013/7/23/121

--
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: Slow boot due to USB errors

[poma]

] scsi_device_dev_release_usercontext+0xe6/0x120
 [810a4e67] execute_in_process_context+0x67/0x70
 [8149127c] scsi_device_dev_release+0x1c/0x20
 [814600e2] device_release+0x32/0xa0
 [813560a7] kobject_cleanup+0x77/0x1b0
 [81355f60] kobject_put+0x30/0x60
 [81460407] put_device+0x17/0x20
 [8148268b] scsi_device_put+0x3b/0x50
 [81495e50] scsi_disk_put+0x30/0x50
 [814961b2] sd_release+0x42/0xd0
 [8122489c] __blkdev_put+0x16c/0x1a0
 [8122483e] __blkdev_put+0x10e/0x1a0
 [8122521c] blkdev_put+0x4c/0x120
 [811ebd64] kill_block_super+0x44/0x70
 [811ec06d] deactivate_locked_super+0x3d/0x60
 [811ec636] deactivate_super+0x46/0x60
 [81208dac] mntput_no_expire+0xac/0x140
 [8120a37d] SyS_umount+0x9d/0x110
 [816ff5e9] system_call_fastpath+0x16/0x1b
---[ end trace 6a4cda17930756e9 ]---

BTW 3.15.0-0.rc5.git0.1.fc21.x86_64 doesn't have this bug.


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: Slow boot due to USB errors

[poma]

On 12.05.2014 16:02, Alan Stern wrote:
 On Mon, 12 May 2014, poma wrote:
 
 ...
 initial 64-byte descriptor request timeout
 https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/core/hub.c#n67
 https://www.kernel.org/doc/Documentation/kernel-parameters.txt
 usbcore.initial_descriptor_timeout=
  Co.


 I made several tests concerning the topic and incidentally found one bug. :)
 
 https://bugzilla.redhat.com/show_bug.cgi?id=1096786
 Unplug the device without unmounting, 

 ...
 usb 2-1: USB disconnect, device number 2
 [ cut here ]
 WARNING: CPU: 0 PID: 4692 at fs/sysfs/group.c:216 
 sysfs_remove_group+0x93/0xa0()
 sysfs group 81cb1300 not found for kobject 'target8:0:0'
 CPU: 0 PID: 4692 Comm: umount Not tainted 3.14.3-200.fc20.x86_64 #1
 Call Trace:
  [816ef242] dump_stack+0x45/0x56
  [8108a1bd] warn_slowpath_common+0x7d/0xa0
  [8108a23c] warn_slowpath_fmt+0x5c/0x80
  [81265598] ? kernfs_find_and_get_ns+0x48/0x60
  [81264233] sysfs_remove_group+0x93/0xa0
  [8146b543] dpm_sysfs_remove+0x43/0x50
  [81460b35] device_del+0x45/0x1c0
  [8148deb7] scsi_target_reap_usercontext+0x27/0x40
  [810a4e67] execute_in_process_context+0x67/0x70
  [8148f334] scsi_target_reap+0xc4/0xf0
  [81491366] scsi_device_dev_release_usercontext+0xe6/0x120
  [810a4e67] execute_in_process_context+0x67/0x70
  [8149127c] scsi_device_dev_release+0x1c/0x20
  [814600e2] device_release+0x32/0xa0
  [813560a7] kobject_cleanup+0x77/0x1b0
  [81355f60] kobject_put+0x30/0x60
  [81460407] put_device+0x17/0x20
  [8148268b] scsi_device_put+0x3b/0x50
  [81495e50] scsi_disk_put+0x30/0x50
  [814961b2] sd_release+0x42/0xd0
  [8122489c] __blkdev_put+0x16c/0x1a0
  [8122483e] __blkdev_put+0x10e/0x1a0
  [8122521c] blkdev_put+0x4c/0x120
  [811ebd64] kill_block_super+0x44/0x70
  [811ec06d] deactivate_locked_super+0x3d/0x60
  [811ec636] deactivate_super+0x46/0x60
  [81208dac] mntput_no_expire+0xac/0x140
  [8120a37d] SyS_umount+0x9d/0x110
  [816ff5e9] system_call_fastpath+0x16/0x1b
 ---[ end trace 6a4cda17930756e9 ]---

 BTW 3.15.0-0.rc5.git0.1.fc21.x86_64 doesn't have this bug.
 
 This is a known bug, as you can tell from the fact that it has already 
 been fixed.  (And, as you can tell by looking at the stack dump, the 
 bug was in the SCSI layer rather than the USB layer.)
 
 Alan Stern
 

Ooh yeah!
But only for 3.15!
https://bugzilla.kernel.org/show_bug.cgi?id=69441
https://bugzilla.redhat.com/show_bug.cgi?id=1030988

Is there anything that isn't SCSI emulation? :)


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