Re: usb mouse issue
Donald Allen donaldcal...@gmail.com wrote: On Sun, Sep 26, 2010 at 8:01 AM, Hans Petter Selasky hsela...@c2i.netwrote: On Sunday 26 September 2010 13:51:14 Donald Allen wrote: I am running 8.1 RELEASE on a Thinkpad X61. I have a wired Microsoft usb mouse plugged into it. I have hal and dbus running, and when I start X, everything is fine. However, if I shut down the X server and restart it (via startx), the mouse no longer works, but the laptop's trackpoint device does work. If I unplug and re-plug the mouse, it now works. Again, as with my report on the usb disks, neither Linux nor OpenBSD exhibit this behavior on this hardware. I am quite happy with X server compiled WITHOUT_HAL=true. While I can't hotplug my USB mouse (I am using a Sony Vaio laptop with internal touchpad) the good thing is that once I plug it in before X server starts I can freely unplug and re-plug it again as necessary. Can you try that to figure out wheter it's really a HAL issue as suggested by HPS? //Marcin ___ 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 drives still don't work correctly
Donald Allen donaldcal...@gmail.com wrote: After the above, if I remove the USB connector and plug it back in, X freezes (the cursor moves with the mouse, but no response to clicks, or to keyboard gestures) until I remove the connector. Can you try this without running X (or just switch to the first text console with Ctrl-Alt-F1) before you do the test. When you unplug, what happens? Do you get kernel panic or the system just freezes? //Marcin ___ 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_VERBOSE and vendor-/productnames
Dnia 14.09.2010 Alexander Best arun...@freebsd.org napisał/a: http://www.mail-archive.com/freebsd-curr...@freebsd.org/msg124948.html). If we don't have to GPL the resulting .h and .c files. The contents of the database and the generated files can be distributed under the terms of either the GNU General Public License (version 2 or later) or of the 3-clause BSD License. Which constitutes probably a legal bullshit, since work created by a computer (not a human author) cannot by copyrighted. Byt well. --Marcin ___ 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/149283: avrdude unable to talk to Arduino board (via uftdi)
The problem got solved. I got: hw.usb.ucom.cons_unit=0 Resetting this value to -1 enabled the communication. The problem was because ucom_get_data() didn't fetch user-supplied data. Please close this PR. --Marcin ___ 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/149283: avrdude unable to talk to Arduino board (via uftdi)
The following reply was made to PR usb/149283; it has been noted by GNATS. From: Marcin Cieslak sa...@saper.info To: freebsd-gnats-sub...@freebsd.org Cc: freebsd-usb@freebsd.org Subject: Re: usb/149283: avrdude unable to talk to Arduino board (via uftdi) Date: Tue, 10 Aug 2010 15:15:58 + The problem got solved. I got: hw.usb.ucom.cons_unit=0 Resetting this value to -1 enabled the communication. The problem was because ucom_get_data() didn't fetch user-supplied data. Please close this PR. --Marcin ___ 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/149283: avrdude unable to talk to Arduino board (via uftdi)
The following reply was made to PR usb/149283; it has been noted by GNATS. From: Marcin Cieslak sa...@saper.info To: Hans Petter Selasky hsela...@c2i.net Cc: freebsd-usb@freebsd.org, freebsd-gnats-sub...@freebsd.org Subject: Re: usb/149283: avrdude unable to talk to Arduino board (via uftdi) Date: Thu, 5 Aug 2010 09:35:10 + On Wed, 4 Aug 2010, Hans Petter Selasky wrote: You can try to comment out: /* clear stall at first run */ mtx_lock(sc-sc_mtx); usbd_xfer_set_stall(sc-sc_xfer[UFTDI_BULK_DT_WR]); usbd_xfer_set_stall(sc-sc_xfer[UFTDI_BULK_DT_RD]); mtx_unlock(sc-sc_mtx); In uftdi_attach in sys/dev/usb/serial/uftdi.c. That did not fix it ... --Marcin ___ 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
avrdude unable to talk to Arduino board (via uftdi)
Submitter-Id: current-users Originator:Marcin Cieslak Confidential: no Synopsis: avrdude unable to talk to Arduino board (via uftdi) Severity: serious Priority: medium Category: usb Class: sw-bug Release: FreeBSD 9.0-CURRENT amd64 Environment: System: FreeBSD radziecki.saper.info 9.0-CURRENT FreeBSD 9.0-CURRENT #5 r206987: Tue Apr 27 20:45:03 CEST 2010 sa...@radziecki.saper.info:/usr/obj/usr/src/sys/VAIO amd64 avrdude-5.10 installed from ports, using default /usr/local/etc/avrdude.conf Arduino Duemilanove board with ATMega328 processor. Using Arduino USB interface, appearing as uftdi: # usbconfig -d ugen4.3 dump_device_desc ugen4.3: FT232R USB UART FTDI at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0008 idVendor = 0x0403 idProduct = 0x6001 bcdDevice = 0x0600 iManufacturer = 0x0001 FTDI iProduct = 0x0002 FT232R USB UART iSerialNumber = 0x0003 A8008pRI bNumConfigurations = 0x0001 # usbconfig -d ugen4.3 dump_all_config_desc ugen4.3: FT232R USB UART FTDI at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0020 bNumInterfaces = 0x0001 bConfigurationValue = 0x0001 iConfiguration = 0x no string bmAttributes = 0x00a0 bMaxPower = 0x002d Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x bAlternateSetting = 0x bNumEndpoints = 0x0002 bInterfaceClass = 0x00ff bInterfaceSubClass = 0x00ff bInterfaceProtocol = 0x00ff iInterface = 0x0002 FT232R USB UART Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 IN bmAttributes = 0x0002 BULK wMaxPacketSize = 0x0040 bInterval = 0x bRefresh = 0x bSynchAddress = 0x Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0002 OUT bmAttributes = 0x0002 BULK wMaxPacketSize = 0x0040 bInterval = 0x bRefresh = 0x bSynchAddress = 0x Description: Any attempt to contact the board using avrdude fails. Checked with the same hardware (dual-boot) and Microsoft Vista (with arduino-0018 IDE) and the board can be contacted and programmed without any problems. Syslog with: hw.usb.ucom.debug: 15 hw.usb.uftdi.debug: 15 avrdude -c arduino -p m328p -P /dev/cuaU0 Aug 4 18:10:04 radziecki saper: Connecting board Aug 4 18:10:07 radziecki kernel: ugen4.3: FTDI at usbus4 Aug 4 18:10:07 radziecki kernel: uftdi0: FT232R USB UART on usbus4 Aug 4 18:10:07 radziecki kernel: uftdi_attach: Aug 4 18:10:07 radziecki kernel: ucom_attach_tty: tp = 0xff0003cd8400, unit = 0 Aug 4 18:10:07 radziecki kernel: ucom_attach_tty: ttycreate: U0 Aug 4 18:10:07 radziecki kernel: ucom_open: tp = 0xff0003cd8400 Aug 4 18:10:07 radziecki kernel: ucom_dtr: onoff = 1 Aug 4 18:10:07 radziecki kernel: ucom_line_state: on=0x01, off=0x00 Aug 4 18:10:07 radziecki kernel: ucom_rts: onoff = 1 Aug 4 18:10:07 radziecki kernel: ucom_line_state: on=0x02, off=0x00 Aug 4 18:10:07 radziecki kernel: ucom_ring: onoff = 0 Aug 4 18:10:07 radziecki kernel: ucom_line_state: on=0x00, off=0x08 Aug 4 18:10:07 radziecki kernel: ucom_break: onoff = 0 Aug 4 18:10:07 radziecki kernel: ucom_line_state: on=0x00, off=0x04 Aug 4 18:10:07 radziecki kernel: ucom_param: sc = 0xff0003cd9458 Aug 4 18:10:07 radziecki kernel: uftdi_pre_param: Aug 4 18:10:07 radziecki kernel: ucom_cfg_open: Aug 4 18:10:07 radziecki kernel: uftdi_cfg_open: uftdi_cfg_param: Aug 4 18:10:46 radziecki saper: Starting avrdude Aug 4 18:10:48 radziecki kernel: ucom_param: sc = 0xff0003cd9458 Aug 4 18:10:48 radziecki kernel: uftdi_pre_param: Aug 4 18:10:48 radziecki kernel: ucom_dtr: onoff = 1 Aug 4 18:10:48 radziecki kernel: ucom_line_state: on=0x01, off=0x00 Aug 4 18:10:48 radziecki kernel: ucom_rts: onoff = 1 Aug 4 18:10:48 radziecki kernel: ucom_line_state: on=0x02, off=0x00 Aug 4 18:10:48 radziecki kernel: uftdi_cfg_param: Aug 4 18:10:48 radziecki kernel: ucom_ioctl: cmd = 0x402c7413 Aug 4 18:10:48 radziecki kernel: ucom_ioctl: cmd = 0x402c7413 Aug 4 18:10:48 radziecki kernel: ucom_ioctl: cmd = 0x802c7414 Aug 4 18:10:48 radziecki kernel: ucom_param: sc = 0xff0003cd9458 Aug 4 18:10:48 radziecki kernel: uftdi_pre_param: Aug 4 18:10:48 radziecki kernel: ucom_ioctl: cmd = 0x8004667e Aug 4 18:10:48 radziecki kernel: ucom_ioctl: cmd = 0x8004667d Aug 4 18:10:48 radziecki kernel: ucom_ioctl: cmd = 0x4004746a Aug 4 18:10:48 radziecki kernel: ucom_ioctl: cmd = 0x8004746d Aug 4 18:10:48 radziecki kernel: ucom_dtr: onoff = 1 Aug 4 18:10:48
Re: usb/149283: avrdude unable to talk to Arduino board (via uftdi)
On Wed, 4 Aug 2010, Joerg Wunsch wrote: As Marcin Cieslak wrote: Checked with the same hardware (dual-boot) and Microsoft Vista (with arduino-0018 IDE) and the board can be contacted and programmed without any problems. Your check on Windows has been using a stock AVRDUDE (e.g., a WinAVR compilation), too? Or another tool? On Windows I have used arduino Java IDE. Arduino IDE distribution actually includes a whole WinAVR stack including avrdude.exe, but I didn't pay attention what is actually used. I will reboot to Windows now and check the commandline invocation. On FreeBSD arduino the Java IDE tries to use avrdude and fails the same was as from commandline. IIRC, the Arduino bootloader requires some special tricks in order to talk to it. I think AVRDUDE v5.10 still lacks that feature. Could you try the SVN version of AVRDUDE? AVRDUDE is mentioned for example here http://www.arduino.cc/playground/FreeBSD/CLI as the tool to use. I have tried -c arduino or -c stk500v1 with trunk and I get still the same affect as with 5.10 (Programmer timeout). What maybe important: TX/RX LED on the board don't react at all when trying to use avrdude (there is only a single blink on firmware LED - which means bootloader start). With Windows - TX/RX indicated clearly some activity. (I don't see a GNATS ID in the subject. Has this been actually filed via send-pr?) Hm, yes, sorry... You were copied on the original send-pr. --Marcin ___ 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/149283: avrdude unable to talk to Arduino board (via uftdi)
The following reply was made to PR usb/149283; it has been noted by GNATS. From: Marcin Cieslak sa...@saper.info To: Joerg Wunsch joerg_wun...@uriah.heep.sax.de Cc: freebsd-gnats-sub...@freebsd.org, freebsd-usb@freebsd.org Subject: Re: usb/149283: avrdude unable to talk to Arduino board (via uftdi) Date: Wed, 4 Aug 2010 20:21:32 + On Wed, 4 Aug 2010, Joerg Wunsch wrote: As Marcin Cieslak wrote: Checked with the same hardware (dual-boot) and Microsoft Vista (with arduino-0018 IDE) and the board can be contacted and programmed without any problems. Your check on Windows has been using a stock AVRDUDE (e.g., a WinAVR compilation), too? Or another tool? On Windows I have used arduino Java IDE. Arduino IDE distribution actually includes a whole WinAVR stack including avrdude.exe, but I didn't pay attention what is actually used. I will reboot to Windows now and check the commandline invocation. On FreeBSD arduino the Java IDE tries to use avrdude and fails the same was as from commandline. IIRC, the Arduino bootloader requires some special tricks in order to talk to it. I think AVRDUDE v5.10 still lacks that feature. Could you try the SVN version of AVRDUDE? AVRDUDE is mentioned for example here http://www.arduino.cc/playground/FreeBSD/CLI as the tool to use. I have tried -c arduino or -c stk500v1 with trunk and I get still the same affect as with 5.10 (Programmer timeout). What maybe important: TX/RX LED on the board don't react at all when trying to use avrdude (there is only a single blink on firmware LED - which means bootloader start). With Windows - TX/RX indicated clearly some activity. (I don't see a GNATS ID in the subject. Has this been actually filed via send-pr?) Hm, yes, sorry... You were copied on the original send-pr. --Marcin ___ 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: Problem with PPP ( CDMA modem Cmotech CCU550)
Miguel Vásquez. wrote: Jun 14 19:37:52 pdt21a ppp[1066]: tun0: IPCP: deflink: RecvConfigAck(2) state = Ack-Sent Jun 14 19:37:52 pdt21a ppp[1066]: tun0: IPCP: IPADDR[6] 190.76.3.253 Jun 14 19:37:52 pdt21a ppp[1066]: tun0: IPCP: PRIDNS[6] 200.44.32.12 Jun 14 19:37:52 pdt21a ppp[1066]: tun0: IPCP: SECDNS[6] 200.11.248.12 Jun 14 19:37:52 pdt21a ppp[1066]: tun0: IPCP: deflink: State change Ack-Sent -- Opened Jun 14 19:37:52 pdt21a ppp[1066]: tun0: IPCP: deflink: LayerUp. Jun 14 19:37:52 pdt21a ppp[1066]: tun0: IPCP: myaddr 190.76.3.253 hisaddr = 192.168.17.130 Jun 14 19:37:52 pdt21a ppp[1066]: tun0: Warning: 0.0.0.0/0: Change route failed: errno: No such process Enviado desde Correo Yahoo! La bandeja de entrada más inteligente. Do you get the default route properly set? What netstat -rn says after you connect? --Marcin signature.asc Description: OpenPGP digital signature
Re: sierra wireless compass 597 aircard (Was: Documentation)
Fredrik Lindberg wrote: This should be enough to switch the device, given that pass0 is the modem (use camcontrol devlist) camcontrol cmd pass0 -c “01 00 00 00 00 00″ -i 1 i1 camcontrol might give you an error but the device will be switched. Note that this is ONLY for Option based devices, I don't know about the Sierra ones but the linux usb_modeswitch tool might be a good start. Yes, this is option-specific. Last time I tried this command, it panics the system. That's why I patched umass to do this for me at the attach time. However, feel free to try other patches since they are not option-specific in any way. --Marcin signature.asc Description: OpenPGP digital signature
Re: sierra wireless compass 597 aircard (Was: Documentation)
Steve Clark wrote:
Is there any detailed documentation on the FreeBSD usb device driver
api?
This chapter helped me a lot to understand how this all works:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/usb.html
I sort of have it working by hacking ubsa.c to look for the sierra
vendor id and product id of 0xfff in
the usb_match function and return match. Then in the usb_attach code I
look again for the vendor and
product id of 0xfff and then send the control message to put it in modem
mode.
if ( uaa-vendor == USB_VENDOR_SIERRA uaa-product == 0xfff )
It maybe a good idea to add 0xFFF to the usbdevs.
Does the umass driver attach to the 0xFFF device? I would recommend
adding this as a quirk to umass.c then.
There are patches attached (ubsa.c_patch, umass_c.patch, usbdevs.patch)
I am using to kill the zeroconf CD on the UMTS. They do not always
work - i.e. umass_attach does not wait until the device is really
detached. But setting USB_DEBUG helps :-)
{
ubsa_request_real( sc, 0x0b, 1, 0x40 );
ucom-sc_dying = 1;
goto error;
}
This puts in modem mode with product id of 0x0023 which i have plugged
into usbdevs and also put in ubsa.c
so now I get a ucom device and can successfully run ppp. The problem I
am running into now is sometime after
it remove the device I will get a page fault panic in the kernel.
What kind of panic is this?
I think it is related to the sending the
control_message - something is not cleaned up when I goto error in the
USB_ATTACH function.
http://www.freebsd.org/cgi/query-pr.cgi?pr=121755
There are two patches, one to ohci_pci.c, the other to usb_subr.c. One
of them is not correct - after kldunloading the module you may run into
problems. But it makes everyday life easier - at least you can remove
the card and re-insert.
And finally, you will need something to increase your ubsa buffers, I am
using the ubsa.c_buffers_patch attached. (Crude, but cleaner than
http://www.freebsd.org/cgi/query-pr.cgi?pr=119227)
--Marcin
--- /sys/dev/usb/ubsa.c 2007-06-22 07:56:05.0 +0200
+++ ubsa.c 2008-01-03 11:53:09.740739801 +0100
@@ -232,6 +232,8 @@
{ USB_VENDOR_OPTION, USB_PRODUCT_OPTION_GT3GQUAD },
/* Option GlobeTrotter 3G+ */
{ USB_VENDOR_OPTION, USB_PRODUCT_OPTION_GT3GPLUS },
+ /* Option GlobeTrotter Max 3.6 */
+ { USB_VENDOR_OPTION, USB_PRODUCT_OPTION_GTMAX36 },
/* Huawei Mobile */
{ USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_MOBILE },
{ 0, 0 }
--- /sys/dev/usb/umass.c2007-07-05 07:26:08.0 +0200
+++ umass.c 2008-01-03 11:53:13.592156965 +0100
@@ -323,6 +323,8 @@
* sector number.
*/
# define READ_CAPACITY_OFFBY1 0x2000
+ /* Needs to be initialised the Qualcomm way */
+# define TURNOFF_FLASH0x4000
};
static struct umass_devdescr_t umass_devdescrs[] = {
@@ -636,6 +638,10 @@
UMASS_PROTO_SCSI | UMASS_PROTO_BBB,
IGNORE_RESIDUE | NO_START_STOP
},
+ { USB_VENDOR_QUALCOMM2, USB_PRODUCT_QUALCOMM2_MMC, RID_WILDCARD,
+ UMASS_PROTO_SCSI | UMASS_PROTO_BBB,
+ TURNOFF_FLASH
+ },
{ USB_VENDOR_SAMSUNG, USB_PRODUCT_SAMSUNG_YP_U2, RID_WILDCARD,
UMASS_PROTO_SCSI | UMASS_PROTO_BBB,
SHUTTLE_INIT | NO_GETMAXLUN
@@ -1027,6 +1033,8 @@
/* quirk functions */
static void umass_init_shuttle (struct umass_softc *sc);
+static void umass_turnoff_flash (struct umass_softc *sc);
+static void umass_turnoff_flash_cb(struct umass_softc *sc, void *priv, int
residue, int status);
/* generic transfer functions */
static usbd_status umass_setup_transfer(struct umass_softc *sc,
@@ -1472,6 +1480,13 @@
if (sc-quirks SHUTTLE_INIT)
umass_init_shuttle(sc);
+ if (sc-quirks TURNOFF_FLASH) {
+ DPRINTF(UDMASS_USB, (%s: Detaching MMC\n,
+ device_get_nameunit(sc-sc_dev)));
+ umass_turnoff_flash(sc);
+ umass_detach(self);
+ return ENXIO;
+ }
/* Get the maximum LUN supported by the device.
*/
@@ -1576,6 +1591,21 @@
device_get_nameunit(sc-sc_dev), status[0], status[1]));
}
+static void
+umass_turnoff_flash(struct umass_softc *sc)
+{
+ static uint8_t cmd[] = { 0x01, 0x00, 0x00, 0x00, 0x00, 0x00 };
+ umass_bbb_transfer(sc, 0, cmd, sizeof(cmd),
+ NULL, 0, DIR_NONE, 0,
+ umass_turnoff_flash_cb, NULL);
+}
+
+static void
+umass_turnoff_flash_cb(struct umass_softc *sc, void *priv, int residue, int
status)
+{
+ /* Do nothing */
+}
+
/*
* Generic functions to handle transfers
*/
--- ubsa.c.orig 2008-03-08 04:22:00.333020955 +0100
+++ ubsa.c 2008-03-12 01:20:07.045184146 +0100
@@ -360,15 +360,15 @@
if (UE_GET_DIR(ed-bEndpointAddress) == UE_DIR_IN
usb/123351: Add Reiner SCT cyberJack, Omnikey [26]020, Fujitsu Siemens SCR to usbdevs
Number: 123351 Category: usb Synopsis: Add Reiner SCT cyberJack, Omnikey [26]020, Fujitsu Siemens SCR to usbdevs Confidential: no Severity: non-critical Priority: high Responsible:freebsd-usb State: open Quarter: Keywords: Date-Required: Class: change-request Submitter-Id: current-users Arrival-Date: Sat May 03 00:50:04 UTC 2008 Closed-Date: Last-Modified: Originator: Marcin Cieslak Release:FreeBSD 7.0-STABLE amd64 Organization: Environment: System: FreeBSD radziecki.saper.info 7.0-STABLE FreeBSD 7.0-STABLE #3: Wed Mar 26 00:33:58 CET 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/VAIO amd64 Description: Add some smart-card readers to usbdevs file. I am working on a driver for them and I need to clean up my local usbdevs patches :) How-To-Repeat: Fix: Index: usbdevs === RCS file: /usr/home/ncvs/src/sys/dev/usb/usbdevs,v retrieving revision 1.328.2.9 diff -u -r1.328.2.9 usbdevs --- usbdevs 25 Apr 2008 16:40:18 - 1.328.2.9 +++ usbdevs 3 May 2008 00:43:32 - @@ -365,6 +365,7 @@ vendor AUREAL 0x0755 Aureal Semiconductor vendor MIDIMAN 0x0763 Midiman vendor SURECOM 0x0769 Surecom Technology +vendor OMNIKEY 0x076b Omnikey vendor LINKSYS20x077b Linksys vendor GRIFFIN 0x077d Griffin Technology vendor SANDISK 0x0781 SanDisk @@ -427,6 +428,7 @@ vendor 2WIRE 0x08c8 2Wire vendor AIPTEK 0x08ca AIPTEK International vendor SMARTBRIDGES0x08d1 SmartBridges +vendor FUJITSUSIEMENS 0x08d4 Fujitsu-Siemens vendor BILLIONTON 0x08dd Billionton Systems vendor EXTENDED0x08e9 Extended Systems vendor MSYSTEMS0x08ec M-Systems @@ -499,6 +501,7 @@ vendor AGATE 0x0c08 Agate Technologies vendor DMI 0x0c0b DMI vendor MICRODIA0x0c45 Chicony +vendor REINERSCT 0x0c4b Reiner-SCT vendor SEALEVEL0x0c52 Sealevel System vendor LUWEN 0x0c76 Luwen vendor KYOCERA20x0c88 Kyocera Wireless Corp. @@ -1257,6 +1260,9 @@ /* Fujitsu protducts */ product FUJITSU AH_F401U 0x105b AH-F401U Air H device +/* Fujitsu-Siemens protducts */ +product FUJITSUSIEMENS SCR 0x0009 Fujitsu-Siemens SCR USB Reader + /* Garmin products */ product GARMIN IQUE_3600 0x0004 iQue 3600 @@ -1787,6 +1793,10 @@ product OLYMPUS C1 0x0102 C-1 Digital Camera product OLYMPUS C700 0x0105 C-700 Ultra Zoom +/* Omnikey products */ +product OMNIKEY CM2020 0x0596 Omnikey Cardman 2020 +product OMNIKEY CM6020 0x1784 Omnikey Cardman 6020 + /* OmniVision Technologies, Inc. products */ product OMNIVISION OV511 0x0511 OV511 Camera product OMNIVISION OV511PLUS 0xa511 OV511+ Camera @@ -1954,6 +1964,9 @@ /* Green House and CompUSA OEM this part */ product REALTEK USBKR100 0x8150 USBKR100 USB Ethernet +/* Reiner-SCT products */ +product REINERSCT CYBERJACK_ECOM 0x0100 e-com cyberjack + /* Roland products */ product ROLAND UM1 0x0009 UM-1 MIDI I/F product ROLAND UM880N 0x0014 EDIROL UM-880 MIDI I/F (native) Release-Note: Audit-Trail: Unformatted: ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
usb/123352: Add Option GTMAX3.6/7.2 and Quallcomm MMC module device identifiiers to usbdevs
Number: 123352 Category: usb Synopsis: Add Option GTMAX3.6/7.2 and Quallcomm MMC module device identifiiers to usbdevs Confidential: no Severity: non-critical Priority: high Responsible:freebsd-usb State: open Quarter: Keywords: Date-Required: Class: change-request Submitter-Id: current-users Arrival-Date: Sat May 03 01:00:05 UTC 2008 Closed-Date: Last-Modified: Originator: Marcin Cieslak Release:FreeBSD 7.0-STABLE amd64 Organization: Environment: System: FreeBSD radziecki.saper.info 7.0-STABLE FreeBSD 7.0-STABLE #3: Wed Mar 26 00:33:58 CET 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/VAIO amd64 Description: I am have a preliminary set of patches to support Option GTMAX3.6/7.2 and to kill the MMC module containing ZeroConf CD with Windows drivers. In the meantime I need to clean up my local usbdevs patches :-) How-To-Repeat: Fix: Index: usbdevs === RCS file: /usr/home/ncvs/src/sys/dev/usb/usbdevs,v retrieving revision 1.328.2.9 diff -u -r1.328.2.9 usbdevs --- usbdevs 25 Apr 2008 16:40:18 - 1.328.2.9 +++ usbdevs 3 May 2008 00:47:58 - @@ -1,4 +1,4 @@ -$FreeBSD: src/sys/dev/usb/usbdevs,v 1.328.2.9 2008/04/25 16:40:18 sam Exp $ +$FreeBSD: src/sys/dev/usb/usbdevs,v 1.328 2007/10/05 07:26:39 luigi Exp $ /* $NetBSD: usbdevs,v 1.392 2004/12/29 08:38:44 imp Exp $ */ /*- @@ -1807,6 +1807,7 @@ product OPTION GT3G0x6000 GlobeTrotter 3G datacard product OPTION GT3GQUAD0x6300 GlobeTrotter 3G QUAD datacard product OPTION GT3GPLUS0x6600 GlobeTrotter 3G+ datacard +product OPTION GTMAX36 0x6701 GlobeTrotter MAX 3.6/7.2 /* OQO */ product OQO WIFI01 0x0002 model 01 WiFi interface @@ -1926,6 +1927,7 @@ /* Qualcomm products */ product QUALCOMM CDMA_MSM 0x6000 CDMA Technologies MSM phone +product QUALCOMM2 MMC 0x1000 MMC on various UMTS devices product QUALCOMM2 RWT_FCT 0x3100 RWT FCT-CDMA 2000 1xRTT modem product QUALCOMM2 CDMA_MSM 0x3196 CDMA Technologies MSM modem product QUALCOMMINC CDMA_MSM 0x0001 CDMA Technologies MSM modem Release-Note: Audit-Trail: Unformatted: ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Motorola A41x/V32x driver
sergio wrote: Need driver Provide information signature.asc Description: OpenPGP digital signature
Re: sierra wireless compass 597 aircard
Steve Clark wrote: Hello List, I am trying to get the above usb device to work on 6.x. It is a bit unusual in the fact that when it is first inserted it comes up in installer mode looking like a fake cd drive with the software on it for windoze. It has to have a control message sent to it to put it in modem mode. Can you install sysutils/udesc_dump from ports and post the output here? I have solved the fake CD problem for the Option Globetrotter GTMax+ card by patching the umass driver. --Marcin signature.asc Description: OpenPGP digital signature
Re: usb/122992: MotoROKR Z6 Phone not recognised by umass as USB disk.
The following reply was made to PR usb/122992; it has been noted by GNATS. From: Marcin Cieslak [EMAIL PROTECTED] To: [EMAIL PROTECTED], Charles Neubauer [EMAIL PROTECTED] Cc: Subject: Re: usb/122992: MotoROKR Z6 Phone not recognised by umass as USB disk. Date: Sun, 27 Apr 2008 16:45:38 +0200 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --enigFCDCD3B9868642ABEAC9FAB0 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: quoted-printable Can you install misc/udesc_dump port and attach the output once the=20 phone is connected? --=20 Marcin Cieslak // [EMAIL PROTECTED] --enigFCDCD3B9868642ABEAC9FAB0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc -BEGIN PGP SIGNATURE- iQCVAwUBSBSRlT2W2v2wY27ZAQMSwgQAmbnlZxLYW9cdwtVU8/eld6VzV6iax2Ew UCqsl0K8Y57kIYysEY+bZHv7p89Y3R1EUGHfFw/5qsAGfjvRf1B/izjqY3keDBw+ V0dyQXo/IOi4VFNYACmTTc/YZiSoompTqjhVr3kEtdc4pSzs6/Z77VF12Y3F1Lu+ yPnVLboO8Co= =V8cp -END PGP SIGNATURE- --enigFCDCD3B9868642ABEAC9FAB0-- ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/122992: MotoROKR Z6 Phone not recognised by umass as USB disk.
The following reply was made to PR usb/122992; it has been noted by GNATS. From: Marcin Cieslak [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: usb/122992: MotoROKR Z6 Phone not recognised by umass as USB disk. Date: Tue, 22 Apr 2008 20:07:35 +0200 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --enig35202659B68540ED1FB4BDF5 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: quoted-printable The bug mentioned is this: http://bugs.gentoo.org/attachment.cgi?id=3D145870 It would be nice if you could provide your real email address - without=20 feedback we will need to close this bug as invalid. --=20 Marcin Cieslak // [EMAIL PROTECTED] --enig35202659B68540ED1FB4BDF5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc -BEGIN PGP SIGNATURE- iQCVAwUBSA4paj2W2v2wY27ZAQP3nAP/TbmIqdGnAUQDP7J35+z3pmir/XfUngL8 +dIkZjb7B7GRnvL5KLt/nP59n07YtAzT7amydXot8743E50eCND74jS2ecsd1v3n vjMts9M3CPfArxtLpzj/u+XSgR2JSOqGwYOpwGKUww4TLN+03bGhTRDXkJgdwVGJ d8giz6DAdPQ= =rS6B -END PGP SIGNATURE- --enig35202659B68540ED1FB4BDF5-- ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MP3 Player not recognized by USB stack
Peter Jeremy wrote: I am getting timeouts and I/O errors when I connect my MP3 player to my desktop. The MP3 player works OK on my laptop. Both are running 7-stable/amd64 from about a month ago. The MP3 player does require adding a new vendor to usbdevs and a SCSI quirk but this has been done on both systems. Can anyone suggest where to start investigating? Is your laptop also using ehci? Can you nuke ehci driver on your desktop and see if this works? --Marcin signature.asc Description: OpenPGP digital signature
Re: USB wired mouse not working
Fabio Pennati wrote: I installed FreeBSD Release 7.0 stable from ftp. I found the following problems: 1) I can boot only in rescue mode; all other options result in an hang. This could not be a problem if there is not influence on problem no.2 below. I am afraid the second problem may be related to your kernel hang in the first place. Can you post the output of your dmesg command? What kind of machine is this. Is it fresh install or update/overwrite of something else? 2) The USB mouse do not work at all, also if it is recognized during boot (it is configured as standard in /etc/devd.conf) and a proper moused process is started. The mouse is seen as usb generic device, sysmouse protocol on port /dev/ums0. I checked also with usbdevs command ant it appears normally on the usb hub. Can you post the kernel logs when the mouse is attached? I have (I think) similar setup - a laptop with external mouse. I have two processes running: % ps ax |grep moused 583 ?? Is 0:51,41 /usr/sbin/moused -p /dev/ums0 -t auto -I /var/run/moused.ums0.pid 1270 ?? Rs 0:31,96 /usr/sbin/moused -3 -p /dev/psm0 -t auto So should you also have. Can you recompile the kernel with USB_DEBUG set and set the following variables at boot: hw.usb.uhci.debug=6 hw.usb.ohci.debug=6 hw.usb.ums.debug=10 You may want to remove all usb-devices from the kernel and load them as modules in /boot/loader.conf: usb_load=YES ugen_load=YES uhid_load=YES ukbd_load=YES ulpt_load=YES ums_load=YES cdce_load=YES ubsa_load=YES uplcom_load=YES ng_ubt_load=YES umass_load=YES uscanner_load=YES This is will make applying patches easier (you can set USB_DEBUG then in /etc/make.conf or in the appropriate /sys/modules/module/Makefile with: DEBUG_FLAGS=-g -DUSB_DEBUG --Marcin signature.asc Description: OpenPGP digital signature
Re: help porting linux fxload app (#include usbdevice_fs.h)
Steve Franks wrote: Hi, I have a need for fxload. I think I've narrowed the issues down to the following (namely USBDEVFS_CONTROL) , so if someone could give me a leg up on that, I'd be grateful. FreeBSD includes a predecessor EZload, but I don't think it works with recent devices as the hardware technology has been sold to another company (cypress)... I think it's USB_DO_REQUEST. Look at ezload code, it's very clean. Actually, what does fxload do more then ezload? Ezload looks very clean and maybe it should be just updated for your needs? --Marcin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/122119: [umass] umass device causes creation of daX but not daXsX entries; CAM error
The following reply was made to PR usb/122119; it has been noted by GNATS.
From: Marcin Cieslak [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc:
Subject: Re: usb/122119: [umass] umass device causes creation of daX but not
daXsX entries; CAM error
Date: Thu, 27 Mar 2008 14:46:15 +0100
This is a cryptographically signed message in MIME format.
--ms070104060701020306070708
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: 7bit
That's interesting.
I have an Option Globetrotter GTMAX 7.2 3G card that also includes a
so-called Zero Configuration feature that identifies as:
Mar 27 14:33:12 radziecki kernel: umass2: Qualcomm, Incorporated USB
MMC Storage, class 0/0, rev 1.10/0.00, addr 2 on uhub7
Mar 27 14:33:12 radziecki kernel: umass2: SCSI over Bulk-Only; quirks =
0x
Mar 27 14:33:12 radziecki kernel: umass2:3:2:-1: Attached to scbus3
Mar 27 14:33:12 radziecki kernel: cd0 at umass-sim2 bus 2 target 0 lun 0
Mar 27 14:33:12 radziecki kernel: cd0: GT HSDPA Modem 3.00 Removable
CD-ROM SCSI-2 device
Mar 27 14:33:12 radziecki kernel: cd0: 1.000MB/s transfers
Mar 27 14:33:12 radziecki kernel: cd0: Attempt to query device size
failed: NOT READY, Medium not present
but for me this is just a CD-ROM device, and it works. It is also
read-only.
1) This will not fix your issue but can you try umass.c and usbdevs (no
need to install ubsa.c) patches from:
http://akson.sgh.waw.pl/~saper/FreeBSD/gt/zeroconf/
I wonder what happens to your system after this :)
2) Can you compile your umass module with -DUSB_DEBUG and set
sysctl hw.usb.umass.debug=3342336
To set -DUSB_DEBUG the easiest way is to apply
Index: Makefile
===
RCS file: /usr/home/ncvs/src/sys/modules/umass/Makefile,v
retrieving revision 1.14
diff -u -r1.14 Makefile
--- Makefile4 Jun 2005 10:58:38 - 1.14
+++ Makefile19 Mar 2008 00:18:31 -
@@ -2,6 +2,8 @@
.PATH: ${.CURDIR}/../../dev/usb
+DEBUG_FLAGS=-g -DUSB_DEBUG
+
KMOD= umass
SRCS= bus_if.h device_if.h \
opt_usb.h opt_cam.h opt_scsi.h \
and then
cd /sys/modules/umass
make obj all
And make load as root
Provided you don't have umass in your kernel already.
--
Marcin Cieslak // [EMAIL PROTECTED]
--ms070104060701020306070708
Content-Type: application/x-pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINLDCC
A+wwggNVoAMCAQICDwDENwABAALlou1Djx5XszANBgkqhkiG9w0BAQUFADCBvDELMAkGA1UE
BhMCREUxEDAOBgNVBAgTB0hhbWJ1cmcxEDAOBgNVBAcTB0hhbWJ1cmcxOjA4BgNVBAoTMVRD
IFRydXN0Q2VudGVyIGZvciBTZWN1cml0eSBpbiBEYXRhIE5ldHdvcmtzIEdtYkgxIjAgBgNV
BAsTGVRDIFRydXN0Q2VudGVyIENsYXNzIDEgQ0ExKTAnBgkqhkiG9w0BCQEWGmNlcnRpZmlj
YXRlQHRydXN0Y2VudGVyLmRlMB4XDTA3MDkyNjA3MjQwOVoXDTEwMTIzMTIyNTk1OVowfTEL
MAkGA1UEBhMCREUxHDAaBgNVBAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRD
IFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0ExKTAnBgNVBAMTIFRDIFRydXN0Q2VudGVyIENs
YXNzIDEgTDEgQ0EgSUlJMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDt9kYre5b9JKbN
j5LffhGsiGlfobkfluO2XqPLzKoMOnduw9+sfHUINrW76Y9B02KC9vF3SDmxbIM4fKM3+7k/
dKzb0zI4w66PBHx+5CqeykhMm8sQaI4EpOUu7tWVfH8ZGHT9UpbVG17+Gi4znxxb/T9+IuB2
Q/qr0ZJ5tR/7hwIDAQABo4IBLDCCASgwVwYIKwYBBQUHAQEESzBJMEcGCCsGAQUFBzAChjto
dHRwOi8vd3d3LnRydXN0Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjY2xhc3Mx
LmNydDASBgNVHRMBAf8ECDAGAQH/AgEAMEoGA1UdIARDMEEwPwYJKoIUACwBAQEBMDIwMAYI
KwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAOBgNVHQ8B
Af8EBAMCAQYwHQYDVR0OBBYEFP2u3ZGgztA5KkvvKMwSnk9+FKp1MD4GA1UdHwQ3MDUwM6Ax
oC+GLWh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjY2xhc3MxLmNybDANBgkq
hkiG9w0BAQUFAAOBgQBe8NTmpp39KWyazqfbPAUwvRv/TEpem4Xy4Gsr8t4RGG9ExKT/ktfF
i2tXO+7LpTmJTbvQ+qHoxkBlmhD1oVVUn2zSIq372vfPvFoFtkvFatpmHDVucTm1vVfeq1t3
yDsvs3WLicz5jT4MSV5EFBaGMgaKjgAIU0NOMXSadvg1FDCCBJowggQDoAMCAQICDgUfAAEA
AvxW+cGq7sagMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBU
cnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENB
MSkwJwYDVQQDEyBUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBIElJSTAeFw0wODAzMDcy
MDIxMDNaFw0wOTAzMDgyMDIxMDNaMEcxCzAJBgNVBAYTAlBMMRcwFQYDVQQDEw5NYXJjaW4g
Q2llc2xhazEfMB0GCSqGSIb3DQEJARYQc2FwZXJAc2FwZXIuaW5mbzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAK3oFWv4v2/dMWsFZXLuYxM6ZZI6uYqyNG0ujmdyYmnHcvZ3
fCRdi9B707aH9qaupD57QeCtAxiFfQkuGt5ySspUp6U039qmS6FfZOQ/FQMYaB0BFNTs2rmq
iqcHG27nOYBFRjRCjAxAeOla8a4HeTHUZ4Ur4cS27mV03dPfUCU+tgLmqg0LrqK5yXZVQhw8
T/kVkXuh9OkQyq4TS4IFtVmcnaDwtF8TH7SlkrZaNRyJPB/zN9pneza97p0kwyIhQkKi2gs9
jdzNGNJRrpyl2rEPYaolJwJvH9dbg1J4+UugwZa7+Os252e+KAP58CUdH7VCs/k/Hd/NEg4j
1ODPv5MCAwEAAaOCAc0wggHJMIGZBggrBgEFBQcBAQSBjDCBiTBSBggrBgEFBQcwAoZGaHR0
cDovL3d3dy50cnVzdGNlbnRlci5kZS9jZXJ0c2VydmljZXMvY2FjZXJ0cy90Y19jbGFzczFf
Re: strange statistics about ohci with systat
Andrei Kolu wrote: Anyone notice anything strange here? Why ohci (usb) got so huge number of interrupts? I have no usb devices connected to this box at all. (...) uhub3: vendor 0x0557 product 0x7000, class 9/0, rev 1.10/1.00, addr 2 on uhub0 uhub3: 4 ports with 4 removable, self powered ukbd0: ATEN CS-1734A V3.4.331, class 0/0, rev 1.10/1.00, addr 3 on uhub3 kbd2 at ukbd0 ums0: ATEN CS-1734A V3.4.331, class 0/0, rev 1.10/1.00, addr 3 on uhub3 ums0: 5 buttons and Z dir. Maybe you have an USB keyboard and mouse? --Marcin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/110988: [umass] [patch] Handling of quirk IGNORE_RESIDUE is umass.c is broken
I am using ICY BOX IB-220U-Wh device with 7.0-PRERELEASE on amd64 and everything works fine without need for quirks. --Marcin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/110988: [umass] [patch] Handling of quirk IGNORE_RESIDUE is umass.c is broken
The following reply was made to PR usb/110988; it has been noted by GNATS. From: Marcin Cieslak [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: usb/110988: [umass] [patch] Handling of quirk IGNORE_RESIDUE is umass.c is broken Date: Wed, 19 Mar 2008 18:35:08 +0100 I am using ICY BOX IB-220U-Wh device with 7.0-PRERELEASE on amd64 and everything works fine without need for quirks. --Marcin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB Smart card reader/writer problem
Vladimir Terziev wrote: Hi, The communication with the device gets stuck on BULK-OUT operations. write(2) calls to /dev/ugenX.2 hang forever despite the timeout set with USB_SET_TIMEOUT. Is it possible to have all USB modules recompiled with USB_DEBUG and set some sysctl's like hw.usb.ohci.debug, hw.usb.uhci.debug (whatever your controller is), hw.usb.debug to some values greater than 0 and see the resulting log? --Marcin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
usb/121755: [patch] Fix panic after ohci/uhub cardbus device eject
Number: 121755
Category: usb
Synopsis: [patch] Fix panic after ohci/uhub cardbus device eject
Confidential: no
Severity: critical
Priority: high
Responsible:freebsd-usb
State: open
Quarter:
Keywords:
Date-Required:
Class: sw-bug
Submitter-Id: current-users
Arrival-Date: Sun Mar 16 03:20:02 UTC 2008
Closed-Date:
Last-Modified:
Originator: Marcin Cieslak
Release:FreeBSD 7.0-PRERELEASE amd64
Organization:
Environment:
System: FreeBSD radziecki.saper.info 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #9:
Sat Jan 26 01:36:13 CET 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/VAIO amd64
Description:
When ejecting Cardbus card implementing OHCI inteface, one may get
panic: ohci_rem_ed: ED not found
or
ucom0: detached
(null): at uhub4 port 1 (addr 2) disconnected
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x400
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc0661e84
stack pointer = 0x28:0xd4d63b4c
frame pointer = 0x28:0xd4d63b6c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 31 (cbb0 event thread)
[thread pid 31 tid 100027 ]
Stopped at kobj_delete+0x14: movl0x400(%eax),%ebx
when unplugging the device, as reported in this thread:
http://thread.gmane.org/gmane.os.freebsd.current/92196
http://thread.gmane.org/gmane.os.freebsd.current/92196/focus=100202
How-To-Repeat:
Try removing Option GTMAX 7.2 3G UMTS modem device (also reported with HUAWEI
datacards).
Fix:
First patch fixes the ohci_rem_ed panic, the next one fixes the kobj_delete
problem.
Index: ohci_pci.c
===
RCS file: /usr/home/ncvs/src/sys/dev/usb/ohci_pci.c,v
retrieving revision 1.50
diff -u -u -r1.50 ohci_pci.c
--- ohci_pci.c 21 Jun 2007 14:42:33 - 1.50
+++ ohci_pci.c 16 Mar 2008 01:33:07 -
@@ -348,6 +348,11 @@
{
ohci_softc_t *sc = device_get_softc(self);
+ if (sc-sc_bus.bdev) {
+ device_delete_child(self, sc-sc_bus.bdev);
+ sc-sc_bus.bdev = NULL;
+ }
+
if (sc-sc_flags OHCI_SCFLG_DONEINIT) {
ohci_detach(sc, 0);
sc-sc_flags = ~OHCI_SCFLG_DONEINIT;
@@ -367,10 +372,6 @@
err);
sc-ih = NULL;
}
- if (sc-sc_bus.bdev) {
- device_delete_child(self, sc-sc_bus.bdev);
- sc-sc_bus.bdev = NULL;
- }
if (sc-irq_res) {
bus_release_resource(self, SYS_RES_IRQ, 0, sc-irq_res);
sc-irq_res = NULL;
Index: usb_subr.c
===
RCS file: /usr/home/ncvs/src/sys/dev/usb/usb_subr.c,v
retrieving revision 1.95
diff -u -u -r1.95 usb_subr.c
--- usb_subr.c 30 Jun 2007 20:18:44 - 1.95
+++ usb_subr.c 16 Mar 2008 02:51:05 -
@@ -1379,8 +1379,6 @@
device_get_ivars(dev-subdevs[i]);
device_detach(dev-subdevs[i]);
free(uaap, M_USB);
- device_delete_child(device_get_parent(dev-subdevs[i]),
- dev-subdevs[i]);
dev-subdevs[i] = NULL;
}
}
Release-Note:
Audit-Trail:
Unformatted:
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB prevents system from powering off and ucom prevents usb from being unloaded - ideas?
Michael Nottebrock wrote: Subject line is the executive summary of my problem: I have a box with an Intel 945GC A2 chipset that will not poweroff on shutdown if the usb kernel module is loaded (or statically compiled into the kernel). Unloading the usb kernel modules sometime during shutdown (I hacked the usbd rc script for this) to work around the problem helped until I needed to hook up another device which uses ucom(4) to the machine. On kldunload, ucom claims to detach, but remains loaded and subsequent kldunload attempts trigger the error kldunload: attempt to unload file that was loaded by the kernel. The stuck ucom in turn prevents usb from getting unloaded and the machine cannot poweroff. Any other module loaded that requires ucom? % grep MODULE_DEPEND /sys/dev/usb/* | grep UCOM_PREFVER | grep -v -i orig uark.c:MODULE_DEPEND(uark, ucom, UCOM_MINVER, UCOM_PREFVER, UCOM_MAXVER); ubsa.c:MODULE_DEPEND(ubsa, ucom, UCOM_MINVER, UCOM_PREFVER, UCOM_MAXVER); ufoma.c:MODULE_DEPEND(ufoma, ucom, UCOM_MINVER, UCOM_PREFVER, UCOM_MAXVER); uftdi.c:MODULE_DEPEND(uftdi, ucom,UCOM_MINVER, UCOM_PREFVER, UCOM_MAXVER); uipaq.c:MODULE_DEPEND(uipaq, ucom, UCOM_MINVER, UCOM_PREFVER, UCOM_MAXVER); umct.c:MODULE_DEPEND(umct, ucom, UCOM_MINVER, UCOM_PREFVER, UCOM_MAXVER); umodem.c:MODULE_DEPEND(umodem, ucom, UCOM_MINVER, UCOM_PREFVER, UCOM_MAXVER); uplcom.c:MODULE_DEPEND(uplcom, ucom, UCOM_MINVER, UCOM_PREFVER, UCOM_MAXVER); uvisor.c:MODULE_DEPEND(uvisor, ucom, UCOM_MINVER, UCOM_PREFVER, UCOM_MAXVER); uvscom.c:MODULE_DEPEND(uvscom, ucom, UCOM_MINVER, UCOM_PREFVER, UCOM_MAXVER); --Marcin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/117075 and Samsung YP-U3
R.Mahmatkhanov wrote: # mount_msdosfs /dev/da0 /home/manager/mnt/ # when i unplug the player from a system: Jan 16 00:03:59 nx7400 kernel: GEOM_LABEL: Label msdosfs/YP -U3 removed. Jan 16 00:10:17 nx7400 kernel: GEOM_LABEL: Label for provider da0 is msdosfs/YP -U3. The only trouble is - i have not actually have the da0s1 device, just da0 - is this normal? Can please anybody consider to commit this? Yes. It does not has to have partition table. I have some USB sticks formatted like harddisks with partitions - and some without. --Marcin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BlackBerry (Re: using libusb)
Duane H Hesser wrote: The only work-around is to not have umass, etcetera in your kernel, but that sucks, because one may want to be able to access /some/ devices as mass-storage, and some others as merely generics... A similar problem occurs to many of us who have HP printers which hook up (quite properly, it seems to me) on ulpt0. Mine also hooks up on umass0 (to service the flash memory card slots), and would hook up on uscanner0, too, if uscanner.c were modified to recognize it. If we want to use HP's software (HPLIP) to drive the printer we must arrange arrange for it to be ugen. Maybe we should move to the model where we attach drivers to interfaces or even particular endpoints? What about sharing the control endpoint? Did NetBSD do any progress in this area? (I can see their current USB and Bluetooth stacks are more advanced then ours). And what wonders me most - we are lucky if we end up with a standard tty or storage interface in the end, but what userland interface should we give for example to SANE? sanei_usb interface defines : usb_write_bulk, that goes as a simple write() to our /dev/uscanner, usb_read_bulk - simple read(), usb_read_int (not supported with /dev/uscanner), usb_control_msg that sends a message to a control pipe (USB_DO_REQUEST of ugen, available to uscanner only if you patch it). My scanner (HP3300C) needs to talk to the control pipe to read/write its registers for example. --Marcin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: uscanner and ulpt over the same connection (Re: BlackBerry)
Mikhail Teterin wrote: четвер 10 січень 2008 05:03 по, Duane H Hesser Ви написали: A similar problem occurs to many of us who have HP printers which hook up (quite properly, it seems to me) on ulpt0. Mine also hooks up on umass0 (to service the flash memory card slots), and would hook up on uscanner0, too, if uscanner.c were modified to recognize it. If we want to use HP's software (HPLIP) to drive the printer we must arrange arrange for it to be ugen. I think must arrange to be ugen is I think too much - shouldn't we say should we make this interface think it is talking via libusb to the proper endpoint? I guess there are two problems with getting libusb-only applications to work on whatever shiny new USB stack we come up: 1. Get the scanning and device detection properly 2. Provide nice way to use control and interrupt endpoints using FreeBSD syscalls. I've had a quick look at sane, libgphoto2 and hplip they don't really use all very complicated logic - they just plain write to the pipes. For sane it is a matter of getting sanei_usb interface right - for libgphoto2 everything is in one file only (libgphoto2_port/usb/libusb.c), hplip has interesting stuff in io/hpmud/musb.c. I think those above are two different problems - solving #1 in a nice way - for example by doing bus enumeration usb(4) controller interface and then access provided via FreeBSD devices - will allow us to keep existing /dev/umassX naming scheme without the need to provide raw /dev/usbX.Y.Z access. I think it is realistic to have our own libusb (API-compatible but does not have to be related to the original project). If both are currently available via the same USB cable, then it is already a good improvement /and/ it should be easy to add ugen to the mix too -- we might not need to wait for Hans' full and comprehensive rework to get this... I have looked at the berry code and what I see is that most of the controller.cc and usbwrap.cc job is already done by the FreeBSD kernel and actually we probably might need a tiny Blackberry driver doing something like probe.cc and plug this easily into the application. A real test how nice is C++ object encapsulation :-) Can you send the udesc_dump (in ports/sysutils) output of a Blackberry and multifunction HP devices? My dream solution for control/interface would be if we could provide chipset-specific interface on top of our stack like ECP (/dev/uprinter0.ecp or whatever) or chipset support (/dev/uniash0), providing just write register and read register like operations. --Marcin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
