u3g (4) device after boot/reboot without re-plugged
Possible to get to work correctly a usb 3g modem after boot / reboot without re-plugged? -- WBR, Konstantin V. Krotov CJSs Information Systems mailto: k...@insysnet.ru ___ 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: u3g (4) device after boot/reboot without re-plugged
On Monday 21 February 2011 14:24:28 Konstantin V. Krotov wrote: Possible to get to work correctly a usb 3g modem after boot / reboot without re-plugged? Can you dump the device descriptor of your device? You could try: usbconfig -d X.Y reset --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: New uhso(4) device: Globetrotter HSUPA Modem Option N.V.
On Mon, Feb 21, 2011 at 11:30 AM, Fredrik Lindberg f...@shapeshifter.se wrote: On 02/18/2011 01:58 AM, Brandon Gooch wrote: I've recently got my hands on an Option N.V. Globetrotter HSUPA Modem, rev 2.00/0.00, addr 2. [...] Also, I tried doing something like this (as per the uhso(4) man page): brandon@x300:~$ sudo cu -l /dev/cuaU2 Connected uhso2: failed to set ctrl line state to 0x01: USB_ERR_TIMEOUT uhso2: failed to set ctrl line state to 0x03: USB_ERR_TIMEOUT ޭ���T+CGDCONT=1,, OK uhso1: failed to set ctrl line state to 0x01: USB_ERR_TIMEOUT uhso1: failed to set ctrl line state to 0x03: USB_ERR_TIMEOUT _OWANCALL: 1, 1 aޭ��aޭ��Aޭ��Aޭ��Aޭ��Aޭ��Aޭ��Aޭ�ޭ��Aޭ�ޭ�� That's where I'm stuck. -Brandon Hmm. Not sure whats going on here. Could you try the other serial ports (except the diagnostic one) with cu or minicom and see if you get the same result with those? Fredrik I did, but seemed to get no response at all from the others, or couldn't connect. I sent an updated message with debugging turned on, not sure if you got it, I can re-send if needed. Thanks for helping out with this, the device in question is the model we are now getting here at the university for our ATT mobile broadband accounts. I may be able to try out a recent Ubuntu or Fedora to see what's happening there, but it could be a couple of days... -Brandon ___ 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: New uhso(4) device: Globetrotter HSUPA Modem Option N.V.
On 02/21/2011 07:28 PM, Brandon Gooch wrote: On Mon, Feb 21, 2011 at 11:30 AM, Fredrik Lindbergf...@shapeshifter.se wrote: On 02/18/2011 01:58 AM, Brandon Gooch wrote: I've recently got my hands on an Option N.V. Globetrotter HSUPA Modem, rev 2.00/0.00, addr 2. [...] Also, I tried doing something like this (as per the uhso(4) man page): brandon@x300:~$ sudo cu -l /dev/cuaU2 Connected uhso2: failed to set ctrl line state to 0x01: USB_ERR_TIMEOUT uhso2: failed to set ctrl line state to 0x03: USB_ERR_TIMEOUT ޭ���T+CGDCONT=1,, OK uhso1: failed to set ctrl line state to 0x01: USB_ERR_TIMEOUT uhso1: failed to set ctrl line state to 0x03: USB_ERR_TIMEOUT _OWANCALL: 1, 1 aޭ��aޭ��Aޭ��Aޭ��Aޭ��Aޭ��Aޭ��Aޭ�ޭ��Aޭ�ޭ�� That's where I'm stuck. Hmm. Not sure whats going on here. Could you try the other serial ports (except the diagnostic one) with cu or minicom and see if you get the same result with those? I did, but seemed to get no response at all from the others, or couldn't connect. I sent an updated message with debugging turned on, not sure if you got it, I can re-send if needed. Thanks for helping out with this, the device in question is the model we are now getting here at the university for our ATT mobile broadband accounts. I may be able to try out a recent Ubuntu or Fedora to see what's happening there, but it could be a couple of days... Yeah, I got that message. Not connecting and not getting an serial console is a bit different. From the output above it looks like random garbage on the serial port. Try connecting to all different serial ports (without uhsoctl running) with minicom or cu and try typing ATenter. (The diagnostic port doesn't work, so skip that one). Fredrik ___ 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: New uhso(4) device: Globetrotter HSUPA Modem Option N.V.
On Mon, Feb 21, 2011 at 12:54 PM, Fredrik Lindberg f...@shapeshifter.se wrote: On 02/21/2011 07:28 PM, Brandon Gooch wrote: On Mon, Feb 21, 2011 at 11:30 AM, Fredrik Lindbergf...@shapeshifter.se wrote: On 02/18/2011 01:58 AM, Brandon Gooch wrote: I've recently got my hands on an Option N.V. Globetrotter HSUPA Modem, rev 2.00/0.00, addr 2. [...] Also, I tried doing something like this (as per the uhso(4) man page): brandon@x300:~$ sudo cu -l /dev/cuaU2 Connected uhso2: failed to set ctrl line state to 0x01: USB_ERR_TIMEOUT uhso2: failed to set ctrl line state to 0x03: USB_ERR_TIMEOUT ޭ���T+CGDCONT=1,, OK uhso1: failed to set ctrl line state to 0x01: USB_ERR_TIMEOUT uhso1: failed to set ctrl line state to 0x03: USB_ERR_TIMEOUT _OWANCALL: 1, 1 aޭ��aޭ��Aޭ��Aޭ��Aޭ��Aޭ��Aޭ��Aޭ�ޭ��Aޭ�ޭ�� That's where I'm stuck. Hmm. Not sure whats going on here. Could you try the other serial ports (except the diagnostic one) with cu or minicom and see if you get the same result with those? I did, but seemed to get no response at all from the others, or couldn't connect. I sent an updated message with debugging turned on, not sure if you got it, I can re-send if needed. Thanks for helping out with this, the device in question is the model we are now getting here at the university for our ATT mobile broadband accounts. I may be able to try out a recent Ubuntu or Fedora to see what's happening there, but it could be a couple of days... Yeah, I got that message. Not connecting and not getting an serial console is a bit different. From the output above it looks like random garbage on the serial port. Try connecting to all different serial ports (without uhsoctl running) with minicom or cu and try typing ATenter. (The diagnostic port doesn't work, so skip that one). Fredrik OK, I have a kernel without VIMAGE running. Here's a run-down of the serial port connection attempts: - uhso0: Diagnostic port at cuaU0 - As per your instructions, I skipped it. - uhso1: Application port at cuaU1 - # cu -l /dev/cuaU1 AT Connected [GARBAGE RETURNED] - uhso2: Control port at cuaU2 - # cu -l /dev/cuaU2 Connected ...but then doesn't allow character input at all. - uhso4: Modem port at cuaU4 - # cu -l /dev/cuaU2 AT [NOTHING RETURNED] ...and any subsequent sequence of characters does nothing. Let me know if you'd like me to try anything else. -Brandon ___ 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: New uhso(4) device: Globetrotter HSUPA Modem Option N.V.
On Mon, Feb 21, 2011 at 3:57 PM, Bjoern A. Zeeb b...@freebsd.org wrote:
On Mon, 21 Feb 2011, Brandon Gooch wrote:
On Mon, Feb 21, 2011 at 1:28 PM, Brandon Gooch
jamesbrandongo...@gmail.com wrote:
Yeah, I got that message. Not connecting and not getting an serial
console is a bit different. From the output above it looks like
random garbage on the serial port.
Try connecting to all different serial ports (without uhsoctl running)
with minicom or cu and try typing ATenter. (The diagnostic port
doesn't work, so skip that one).
I just encountered a panic when the driver attaches after plugging in
the device.
The panic stems from uhso_attach(), and seems due to my kernel having
the VIMAGE option compiled in -- it doesn't panic on my non-VIMAGE
kernel (which I need to rebuild to continue helping debug).
I'm trying to get a textdump ATM...
Looks like I exceeded the VNET if_indexlim in /usr/src/sys/net/if.c on
line 190:
static VNET_DEFINE(int, if_indexlim) = 8;
Maybe I'll bump it up and give it another go...
Bjoern, is there any reason I shouldn't be able to increase the number
from 8 to say, 16?
I am lacking context reading about serial ports and network
interfaces.
I apologize for just blurting this out at you, my bad. I get a
little anxious sometimes :{
If you create a network interface from USB you are currently running
into the problem that CURVNETs are not properly setup. The indexlim,
should just increase itself up to 64k if needed - see if_grow() in
if.c.
...and of course, I sound like a dork again for making absurd
assertions about code I know nothing about LOL :)
It totally slipped my mind that all of the bits are not yet in the
tree to allow adding interfaces after the kernel is already running --
patience, patience...
-Brandon
___
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: libusb performance on 8.1
On 19/02/2011, at 1:38, Hans Petter Selasky wrote: Which harddisk driver are you using? ATA? Yes. My guess would be that taskqueues() in the HDD drivers are using swi-queues, instead of ordinary lower-priority queues. For example in sys/dev/ata I found: TASK_INIT(request-task, 0, ata_completed, request); ATA_DEBUG_RQ(request, finish taskqueue_swi); taskqueue_enqueue(taskqueue_swi, request-task); Which should perhaps just be taskqueue_thread instead of taskqueue_swi. I'll try changing it and seeing if it improves things. I've noticed during USB debugging that if certain non-DATA-xfer SCSI commands take time to complete, the whole system is waiting apparently, at least X11. This might indicate that synchronous code is being run from interrupt context. Interesting.. Although in the dual core case I wouldn't have thought it would be a huge deal would it? I had to give the dual core system I was using for testing back so I am currently using a single core with a non-ACHI capable chipset. I'll try and get access to the previous system again for some more testing. Do you have any suggestions for how I can find out exactly where it's sleeping in libusb? Or I suppose once it's in the kernel.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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
