Re: usb/179802: [usbdevs] [patch] add u3g for NTT Docomo L-02C
Old Synopsis: u3g for NTT Docomo L-02C New Synopsis: [usbdevs] [patch] add u3g for NTT Docomo L-02C Responsible-Changed-From-To: freebsd-bugs-freebsd-usb Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jun 21 10:32:30 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=179802 ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB ports on Lenovo T400 do not work after a suspend/resume
On Thu, 20 Jun 2013 14:19:21 -0700, Adrian Chadd wrote: Hi, FreeBSD-9 works fine on this Lenovo T400 - except that suspending with no USB devices plugged in result in no ports working after resume. If I have a device plugged in during suspend - on any port - then all the ports work fine after resume. I've attached usbconfig and acpidump output. No acpidump output on -stable or -acpi anyway .. likely best as an URL, if it comes down to ACPI. So the fingerprint reader, camera and bluetooth shown in your usbconfig don't serve as 'USB devices plugged in' in this regard? Do they work ok after resume, or not? here's what is logged in the kernel buffer during suspend and resume: Her'es the suspend: With all but the USB-related stuff dropped, I assume? Jun 20 14:03:34 lucy acpi: suspend at 20130620 14:03:34 Jun 20 14:03:38 lucy kernel: [100031] uhub0: at usbus0, port 1, addr 1 (disconnected) Jun 20 14:03:38 lucy kernel: [100036] uhub1: at usbus1, port 1, addr 1 (disconnected) Jun 20 14:03:38 lucy kernel: ugen1.2: vendor 0x08ff at usbus1 (disconnected) Jun 20 14:03:38 lucy kernel: ugen1.3: Lenovo Computer Corp at usbus1 (disconnected) Jun 20 14:03:38 lucy kernel: [100036] ubt0: at uhub1, port 2, addr 3 (disconnected) Jun 20 14:03:47 lucy kernel: [100041] uhub2: at usbus2, port 1, addr 1 (disconnected) Jun 20 14:03:47 lucy kernel: [100046] uhub3: at usbus3, port 1, addr 1 (disconnected) Jun 20 14:03:47 lucy kernel: ugen3.2: Kingston at usbus3 (disconnected) Jun 20 14:03:47 lucy kernel: [100046] umass0: at uhub3, port 1, addr 2 (disconnected) Jun 20 14:03:47 lucy kernel: (da0:umass-sim0:0:0:0): lost device - 0 outstanding, 1 refs Jun 20 14:03:47 lucy kernel: (da0:umass-sim0:0:0:0): removing device entry Jun 20 14:03:47 lucy kernel: ugen3.3: Chicony Electronics Co., Ltd. at usbus3 (disconnected) Jun 20 14:03:47 lucy kernel: uhci_interrupt: resume detect The last message is news to me. Jun 20 14:03:47 lucy kernel: [100052] uhub4: at usbus4, port 1, addr 1 (disconnected) Jun 20 14:03:47 lucy kernel: [100057] uhub5: at usbus5, port 1, addr 1 (disconnected) Jun 20 14:03:47 lucy kernel: [100062] uhub6: at usbus6, port 1, addr 1 (disconnected) Jun 20 14:03:47 lucy kernel: [100067] uhub7: at usbus7, port 1, addr 1 (disconnected) ..and resume: I wonder what these devices are? Jun 20 14:03:47 lucy kernel: [100095] pci21: failed to set ACPI power state D2 on \_SB_.PCI0.PCI1.CDBS: AE_BAD_PARAMETER Jun 20 14:03:47 lucy kernel: [100095] pci0: failed to set ACPI power state D2 on \_SB_.PCI0.EXP0: AE_BAD_PARAMETER Jun 20 14:03:47 lucy kernel: [100095] pci0: failed to set ACPI power state D2 on \_SB_.PCI0.EXP1: AE_BAD_PARAMETER Jun 20 14:03:47 lucy kernel: [100095] pci0: failed to set ACPI power state D2 on \_SB_.PCI0.EXP3: AE_BAD_PARAMETER Jun 20 14:03:47 lucy kernel: [100095] pci0: failed to set ACPI power state D2 on \_SB_.PCI0.EXP4: AE_BAD_PARAMETER No, the above are still on the suspend path, but logged on resume. I don't know what CDBS or EXP0,1,3,4 are. You've left out something like 'pci0:X:Y:0 Transition from D0 to D2' (or D3) before these ones, right? On 9(.1-R so far) I always get the same sort of messages for the cardbus slots on my T23, eg pci2: failed to set ACPI power state D2 on \_SB_.PCI0.PCI1.CBS0: AE_BAD_PARAMETER, also for CBS1. I've supposed it meant there was no D2 setting for these and they seem to resume alright, later on: pci2: set ACPI power state D0 on \_SB_.PCI0.PCI1.CBS0 ( CBS1) I suppose you'd have lines setting state back to D0 on these, later on? Jun 20 14:03:47 lucy kernel: [100095] acpi0: cleared fixed power button status Jun 20 14:03:47 lucy kernel: uhci_interrupt: resume detect Jun 20 14:03:47 lucy kernel: wakeup from sleeping state (slept 00:00:06) I hope 'slept' message is still in 10, I've seen a few listed without, and they're very handy if there's any resume delay, as I had up to 8.2 (plus exactly 60 seconds) unless I unloaded (in particular) UHCI and reloaded it on resume, needing a kernel w/out uhci, ohci and ehci, loading on boot and unload/reload in rc.suspend/resume. This however was fixed by 9.1 for me, the first release where suspend/resume works flawlessly on the T23. I haven't tried a recent 9-STABLE though. Jun 20 14:03:47 lucy kernel: [100067] uhub0: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus7 Jun 20 14:03:47 lucy kernel: [100046] uhub1: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus3 Jun 20 14:03:47 lucy kernel: [100031] uhub2: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0 Jun 20 14:03:47 lucy kernel: [100036] uhub3: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus1 Jun 20 14:03:47 lucy kernel: [100057] uhub4: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus5 Jun 20 14:03:47 lucy kernel: [100052] uhub5: Intel UHCI
Issues 179505
Any chance I can get someone to look at http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/179505? This was discussed on the list, but sort of tailed off. There is more information in the PR than was ever on the list. Thanks, mike ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Issues 179505
On Fri, 21 Jun 2013 10:28:41 -0500 Mike Meyer m...@mired.org wrote: Any chance I can get someone to look at http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/179505? This was discussed on the list, but sort of tailed off. There is more information in the PR than was ever on the list. What code (sketch) are you running on the Leonardo? According to thise page: http://arduino.cc/en/Guide/ArduinoLeonardo the board only has one mikrocontroller, so unless your program (sketch) on the Leo handles the usb communication, there will be none after the board resets. (if my understanding is correct) HTH -- Torfinn Ingolfsen torfinn.ingolf...@getmail.no ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Issues 179505
On Fri, 21 Jun 2013 19:55:42 +0200 Torfinn Ingolfsen torfinn.ingolf...@getmail.no wrote: On Fri, 21 Jun 2013 10:28:41 -0500 Mike Meyer m...@mired.org wrote: Any chance I can get someone to look at http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/179505? This was discussed on the list, but sort of tailed off. There is more information in the PR than was ever on the list. What code (sketch) are you running on the Leonardo? According to thise page: http://arduino.cc/en/Guide/ArduinoLeonardo the board only has one mikrocontroller, so unless your program (sketch) on the Leo handles the usb communication, there will be none after the board resets. (if my understanding is correct) Ok, it seems like there is a bug / misfeature in SoftSerial on the Leo: http://vort.org/2012/05/25/trouble-softserial-arduino-leonardo/ -- Torfinn Ingolfsen torfinn.ingolf...@getmail.no ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Issues 179505
On Fri, Jun 21, 2013 at 12:55 PM, Torfinn Ingolfsen torfinn.ingolf...@getmail.no wrote: On Fri, 21 Jun 2013 10:28:41 -0500 Mike Meyer m...@mired.org wrote: Any chance I can get someone to look at http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/179505? This was discussed on the list, but sort of tailed off. There is more information in the PR than was ever on the list. What code (sketch) are you running on the Leonardo? According to thise page: http://arduino.cc/en/Guide/ArduinoLeonardo the board only has one mikrocontroller, so unless your program (sketch) on the Leo handles the usb communication, there will be none after the board resets. (if my understanding is correct) I just tried BitLashDemo, which uses the umodem connection to provide an interactive shell on the Arduino. Except it won't work on the leonardo talking to FreeBSD, because it disconnects. The sketch shouldn't matter. If I connect it to Linux running on a VBox VM on FreeBSD, everything works as expected, no matter what sketch is running. I've updated the issue to note this. mike ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/179505: Kernel detaches Arduino Leonardo (and similar) board umodem after the arduino boots
The following reply was made to PR usb/179505; it has been noted by GNATS. From: Mike Meyer m...@mired.org To: bug-follo...@freebsd.org, m...@mired.org Cc: Subject: Re: usb/179505: Kernel detaches Arduino Leonardo (and similar) board umodem after the arduino boots Date: Fri, 21 Jun 2013 13:07:25 -0500 In answer to questions asked (and answered) on the USB mail list: It doesn't matter what sketch is installed on the Leonardo - the umodem goes away even if the sketch tries to use it. The sketch doesn't matter if the board is connected to Linux running on a VBox VM on FreeBSD; the umodem device stays attached after the sketch starts. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Issues 179505
Sorry 'bout the extra emphasis there. Anyway, the problem is not *simply* the sketch code. It could be something in the Arduino bootloader violating a USB spec that Linux doesn't care about and FreeBSD does. But mucking about with the user code on the Arudino (i.e. - sketches) doesn't change anything: I get the same behavior whether it's running a trivial Blink demo (pretty much no libraries used at all) or a complete interactive shell: It works as expected when connected to Linux running on a VBox VM, with the umodem device always being present. If I don't connect it to the VM, the umodem device appears when the board is plugged in or reset, then disappears before the sketch starts running. On Fri, Jun 21, 2013 at 1:10 PM, Mike Meyer m...@mired.org wrote: This would help - if I were using the SoftSerial library The arduino sketch code is *not* the problem. Everything works fine if I just connect the board to a VBox runninng Linux, even on a FreeBSD host. On Fri, Jun 21, 2013 at 1:03 PM, Torfinn Ingolfsen torfinn.ingolf...@getmail.no wrote: On Fri, 21 Jun 2013 19:55:42 +0200 Torfinn Ingolfsen torfinn.ingolf...@getmail.no wrote: On Fri, 21 Jun 2013 10:28:41 -0500 Mike Meyer m...@mired.org wrote: Any chance I can get someone to look at http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/179505? This was discussed on the list, but sort of tailed off. There is more information in the PR than was ever on the list. What code (sketch) are you running on the Leonardo? According to thise page: http://arduino.cc/en/Guide/ArduinoLeonardo the board only has one mikrocontroller, so unless your program (sketch) on the Leo handles the usb communication, there will be none after the board resets. (if my understanding is correct) Ok, it seems like there is a bug / misfeature in SoftSerial on the Leo: http://vort.org/2012/05/25/trouble-softserial-arduino-leonardo/ -- Torfinn Ingolfsen torfinn.ingolf...@getmail.no ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Issues 179505
On 06/21/13 20:17, Mike Meyer wrote: Sorry 'bout the extra emphasis there. Anyway, the problem is not *simply* the sketch code. It could be something in the Arduino bootloader violating a USB spec that Linux doesn't care about and FreeBSD does. But mucking about with the user code on the Arudino (i.e. - sketches) doesn't change anything: I get the same behavior whether it's running a trivial Blink demo (pretty much no libraries used at all) or a complete interactive shell: It works as expected when connected to Linux running on a VBox VM, with the umodem device always being present. If I don't connect it to the VM, the umodem device appears when the board is plugged in or reset, then disappears before the sketch starts running. Hi, I think I have one of these devices at work. I can have a look if I have time next week. Possibly the Arduino needs a fix. Look for so-called spurious VBUS pullup toggling in the software of the Arduino. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Issues 179505
On 21 June 2013 14:07, Hans Petter Selasky h...@bitfrost.no wrote: I think I have one of these devices at work. I can have a look if I have time next week. Possibly the Arduino needs a fix. Look for so-called spurious VBUS pullup toggling in the software of the Arduino. Considering there's a large number of unfixed Arduinos out there and it works fine on Linux, Windows and FreeBSD, I don't think fix the arduino should be the only solution. Just saying, Adrian ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/179802: [usbdevs] [patch] add u3g for NTT Docomo L-02C
Synopsis: [usbdevs] [patch] add u3g for NTT Docomo L-02C Responsible-Changed-From-To: freebsd-usb-remko Responsible-Changed-By: remko Responsible-Changed-When: Fri Jun 21 21:43:51 UTC 2013 Responsible-Changed-Why: Grab http://www.freebsd.org/cgi/query-pr.cgi?pr=179802 ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Issues 179505
On Fri, Jun 21, 2013 at 4:08 PM, Adrian Chadd adr...@freebsd.org wrote: On 21 June 2013 14:07, Hans Petter Selasky h...@bitfrost.no wrote: I think I have one of these devices at work. I can have a look if I have time next week. Possibly the Arduino needs a fix. Look for so-called spurious VBUS pullup toggling in the software of the Arduino. Considering there's a large number of unfixed Arduinos out there and it works fine on Linux, Windows and FreeBSD, I don't think fix the arduino should be the only solution. Did you mean OSX instead of FreeBSD there? While not really optimal, I'd consider it acceptable if the fix were in software, so that the Arduino IDE's burn bootloader menu entry could be used to fix the thing. But fixing things so it just worked would be better. Thanks, mike ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Issues 179505
Heh. yes. I'm just saying. As someone who has hacked on this stuff a bit and watched a lot of people hack on it, if their projects didn't work in freebsd/pcbsd, they'd say fuck it and reinstall Linux. If you'd like to further adoption of this stuff on FreeBSD, we have to work around the brokenness. :( Adrian On 21 June 2013 17:34, Mike Meyer m...@mired.org wrote: On Fri, Jun 21, 2013 at 4:08 PM, Adrian Chadd adr...@freebsd.org wrote: On 21 June 2013 14:07, Hans Petter Selasky h...@bitfrost.no wrote: I think I have one of these devices at work. I can have a look if I have time next week. Possibly the Arduino needs a fix. Look for so-called spurious VBUS pullup toggling in the software of the Arduino. Considering there's a large number of unfixed Arduinos out there and it works fine on Linux, Windows and FreeBSD, I don't think fix the arduino should be the only solution. Did you mean OSX instead of FreeBSD there? While not really optimal, I'd consider it acceptable if the fix were in software, so that the Arduino IDE's burn bootloader menu entry could be used to fix the thing. But fixing things so it just worked would be better. Thanks, mike ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
