From: Bernd Krumboeck <krumboeck@universalnet.at>
To: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: "linux-can@vger.kernel.org" <linux-can@vger.kernel.org>,
Gediminas Simanskis <gediminas@8devices.com>
Subject: Re: usb_8dev: Initialisation issue with powered USB 2.0 hub
Date: Sat, 14 Feb 2015 09:17:39 +0100 [thread overview]
Message-ID: <54DF04A3.1010602@universalnet.at> (raw)
In-Reply-To: <54D90CA7.50302@hartkopp.net>
Hi Oliver!
I was able to reconstruct, but I think it is not a driver problem (at least not only).
Tested hard- and software:
Wiregate (ALIX 1E Board) with Conrad selfpowered USB hub.
Kernel 3.5.1 with latest driver from pre-3.3 branch.
Links for Details:
http://www.pcengines.ch/alix1e.htm
http://www.conrad.at/ce/de/product/971592/7-Port-USB-20-Hub-Metallgehaeuse-zur-Wandmontage-CE-Schwarz?ref=searchDetail
Steps of my test:
1) Disconnnect USB hub from System:
System removed the network interface (expected behavior)
2) Reconnect USB Hub to System:
LED is still green. Startup device again. Everything looks normal, except we don't receive CAN messages.
Sending messages was not tested, because of missing test environment.
3) Rebooted the System:
LED is still green. Everything looks normal, except we don't receive CAN messages.
4) Unbind USB device (echo "1-4.1.2" > /sys/bus/usb/drivers/usb/unbind):
Unbind worked as expected: LED becomes red.
Following message appears in the kernel log:
[ 356.897524] usb_8dev 1-4.1.2:1.0: can0: device disconnected
5) Bind USB device (echo "1-4.1.2" > /sys/bus/usb/drivers/usb/bind):
LED stays red. This is not an expected behavior.
Following message appears in the kernel log:
[ 392.584273] usb_8dev 1-4.1.2:1.0: can0: no command message answer
[ 392.584427] usb_8dev 1-4.1.2:1.0: can0: can't get firmware version
[ 392.585276] usb_8dev: probe of 1-4.1.2:1.0 failed with error -110
I often use this rebind procedure for hanging (unresponsive) Huawai 3G sticks. First time this does not work.
6) Disconnect USB2CAN adapter from hub. Reconnect the adapter:
LED becomes green. Everything works as expected.
Conclusion:
At this time I assume it is a firmware issue. At least the rebind procedure should work, if everything else didn't.
Not tested workaround:
Probably it helps to send a reset command in the driver before startup, but I didn't test.
PS: I had some kernel crashes with "Intel Corporation 82801I (ICH9 Family)" usb controller.
regards,
Bernd
Am 2015-02-09 um 20:38 schrieb Oliver Hartkopp:
> Hi Bernd,
>
> On 09.02.2015 20:30, Bernd Krumboeck wrote:
>
>> I will try to test, when I have some time (in about two weeks).
>
> I'm looking forward to it ...
>
>> The kernel crash should not happen with newer kernel/driver versions.
>> So I'll ignore until I get an exact version number.
>
> Ok. I'll ask the colleague and check the patch status of his kernel.
>
> Thanks,
> Oliver
>
>>
>>
>>
>> Am 2015-02-05 um 19:03 schrieb Oliver Hartkopp:
>>> Hi Bernd,
>>>
>>> i got an error report from a colleague today who is using the USB2CAN from
>>> 8devices behind a self powered USB2.0 hub.
>>>
>>> The way to get into the problem:
>>>
>>> 1. Connect a self powered USB hub with attached USB2CAN to the host:
>>>
>>>
>>> [ 502.464008] usb 3-2: new high-speed USB device number 8 using xhci_hcd
>>> [ 502.593336] usb 3-2: New USB device found, idVendor=05e3, idProduct=0608
>>> [ 502.593339] usb 3-2: New USB device strings: Mfr=0, Product=1,
>>> SerialNumber=0
>>> [ 502.593341] usb 3-2: Product: USB2.0 Hub
>>> [ 502.593863] hub 3-2:1.0: USB hub found
>>> [ 502.594124] hub 3-2:1.0: 4 ports detected
>>> [ 502.864710] usb 3-2.1: new full-speed USB device number 9 using xhci_hcd
>>> [ 502.955087] usb 3-2.1: New USB device found, idVendor=0483, idProduct=1234
>>> [ 502.955097] usb 3-2.1: New USB device strings: Mfr=1, Product=2,
>>> SerialNumber=3
>>> [ 502.955102] usb 3-2.1: Product: USB2CAN converter
>>> [ 502.955106] usb 3-2.1: Manufacturer: edevices
>>> [ 502.955110] usb 3-2.1: SerialNumber: ED000215
>>> [ 502.956739] usb_8dev 3-2.1:1.0 can0: firmware: 1.5, hardware: 255.255
>>>
>>> (everything is fine - USB2CAN LED is RED)
>>>
>>> # ip -det link show can0
>>> 21: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group
>>> default qlen 10
>>> link/can promiscuity 0
>>> can state STOPPED (berr-counter tx 0 rx 0) restart-ms 0
>>> usb_8dev: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp-inc 1
>>> clock 32000000
>>> # ip link set can0 type can bitrate 500000
>>> # ifconfig can0 up
>>>
>>> (still everything is fine - USB2CAN LED is GREEN)
>>>
>>> Adapter works as expected. It can send and receive CAN frames.
>>>
>>> 2. Now unplug the powered hub from the PC:
>>>
>>> [ 680.841130] usb_8dev 3-2.1:1.0 can0: Rx URB aborted (-71)
>>> [ 680.841212] usb_8dev 3-2.1:1.0 can0: Rx URB aborted (-71)
>>> [ 680.841252] usb_8dev 3-2.1:1.0 can0: Rx URB aborted (-71)
>>> [ 680.841308] usb_8dev 3-2.1:1.0 can0: Rx URB aborted (-71)
>>> [ 680.841352] usb_8dev 3-2.1:1.0 can0: Rx URB aborted (-71)
>>> [ 680.841377] usb 3-2: USB disconnect, device number 8
>>> [ 680.841385] usb 3-2.1: USB disconnect, device number 9
>>> [ 680.841388] usb_8dev 3-2.1:1.0 can0: Rx URB aborted (-71)
>>> [ 680.843607] usb_8dev 3-2.1:1.0 can0: device disconnected
>>> [ 680.843634] usb_8dev 3-2.1:1.0 can0: sending command message failed
>>> [ 680.843639] usb_8dev 3-2.1:1.0 can0: couldn't stop device
>>>
>>> The USB2CAN LED remains GREEN - as the adapter is still powered.
>>>
>>> 3. Now plug the powered hub into the PC again:
>>>
>>> [ 705.799101] usb 3-2: new high-speed USB device number 10 using xhci_hcd
>>> [ 705.928881] usb 3-2: New USB device found, idVendor=05e3, idProduct=0608
>>> [ 705.928891] usb 3-2: New USB device strings: Mfr=0, Product=1,
>>> SerialNumber=0
>>> [ 705.928895] usb 3-2: Product: USB2.0 Hub
>>> [ 705.929871] hub 3-2:1.0: USB hub found
>>> [ 705.930191] hub 3-2:1.0: 4 ports detected
>>> [ 706.203831] usb 3-2.1: new full-speed USB device number 11 using xhci_hcd
>>> [ 706.294249] usb 3-2.1: New USB device found, idVendor=0483, idProduct=1234
>>> [ 706.294259] usb 3-2.1: New USB device strings: Mfr=1, Product=2,
>>> SerialNumber=3
>>> [ 706.294264] usb 3-2.1: Product: USB2CAN converter
>>> [ 706.294268] usb 3-2.1: Manufacturer: edevices
>>> [ 706.294271] usb 3-2.1: SerialNumber: ED000215
>>> [ 706.296097] usb_8dev 3-2.1:1.0 can0: firmware: 1.5, hardware: 255.255
>>>
>>> The USB2CAN LED remains GREEN - as the adapter is still powered.
>>> But the CAN netdevice is not configured:
>>>
>>> # ip -det link show can0
>>> 21: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group
>>> default qlen 10
>>> link/can promiscuity 0
>>> can state STOPPED (berr-counter tx 0 rx 0) restart-ms 0
>>> usb_8dev: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp-inc 1
>>> clock 32000000
>>>
>>> After setting the bitrate again & putting the interface up:
>>>
>>> # ip link set can0 type can bitrate 500000
>>> # ifconfig can0 up
>>>
>>> The USB2CAN LED remains GREEN.
>>>
>>> But from this point the USB2CAN adapter can only *send* CAN frames but it
>>> can not
>>> receive any frames. Btw. the CAN controller inside the USB2CAN properly
>>> acknowledges
>>> the CAN frames on the bus (without making them visible on the host).
>>>
>>> Any idea how to fix the initialization in this warm start scenario?
>>>
>>> My colleague also reported kernel crashes which I wasn't able to reproduce.
>>> I used a 3.19.0-rc7 here - don't know what my colleague was using.
>>>
>>> Best regards,
>>> Oliver
>>>
>>
next prev parent reply other threads:[~2015-02-14 8:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-05 18:03 usb_8dev: Initialisation issue with powered USB 2.0 hub Oliver Hartkopp
2015-02-09 19:30 ` Bernd Krumboeck
2015-02-09 19:38 ` Oliver Hartkopp
2015-02-14 8:17 ` Bernd Krumboeck [this message]
2015-02-16 6:36 ` Oliver Hartkopp
2015-02-16 17:12 ` Gediminas Simanskis
2015-02-17 6:19 ` Oliver Hartkopp
2015-02-17 10:51 ` Gediminas Simanskis
2015-02-17 18:15 ` Bernd Krumboeck
2015-02-26 9:41 ` Oliver Hartkopp
2015-11-13 20:20 ` [SOLVED] " Oliver Hartkopp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54DF04A3.1010602@universalnet.at \
--to=krumboeck@universalnet.at \
--cc=gediminas@8devices.com \
--cc=linux-can@vger.kernel.org \
--cc=socketcan@hartkopp.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).