Re: usb/132066: [ukbd] Keyboard failure USB keyboard DELL 760
The following reply was made to PR usb/132066; it has been noted by GNATS. From: Gavin Atkinson To: bug-follo...@freebsd.org Cc: Subject: Re: usb/132066: [ukbd] Keyboard failure USB keyboard DELL 760 Date: Wed, 25 Feb 2009 10:49:35 + Forwarded Message From: Judah Levine Date: Tue, 24 Feb 2009 10:53:40 -0700 Hello, >To submitter: Can you please give the output of "usbdevs -v"? Controller /dev/usb0: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 powered Controller /dev/usb1: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 powered Controller /dev/usb2: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 powered Controller /dev/usb3: addr 1: high speed, self powered, config 1, EHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 powered port 3 powered port 4 powered port 5 powered port 6 powered Controller /dev/usb4: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 addr 2: low speed, power 70 mA, config 1, Dell USB Keyboard(0x2105), Dell(0x413c), rev 3.52 port 2 addr 3: low speed, power 100 mA, config 1, Optical USB Mouse(0xc016), Logitech(0x046d), rev 3.40 Controller /dev/usb5: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 powered Controller /dev/usb6: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 powered Controller /dev/usb7: addr 1: high speed, self powered, config 1, EHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 powered port 3 powered port 4 powered port 5 powered port 6 powered >and supply the output of "dmesg |grep -A 2 -B 2 kbd" ioapic0 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard -- pmtimer0 on isa0 orm0: at iomem 0xc-0xcc7ff,0xcc800-0xce7ff,0xce800-0xc on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 -- sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 ukbd0: Dell Dell USB Keyboard, rev 1.10/3.52, addr 2, iclass 3/1 kbd2 at ukbd0 ums0: Logitech Optical USB Mouse, rev 2.00/3.40, addr 3, iclass 3/1 ums0: 3 buttons and Z dir. Judah Levine Time and Frequency Division NIST Boulder ___ 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/132066: [ukbd] Keyboard failure USB keyboard DELL 760
The following reply was made to PR usb/132066; it has been noted by GNATS. From: Gavin Atkinson To: bug-follo...@freebsd.org Cc: Subject: Re: usb/132066: [ukbd] Keyboard failure USB keyboard DELL 760 Date: Fri, 20 Mar 2009 14:33:36 + Forwarded Message From: Judah Levine To: ga...@freebsd.org, freebsd-usb@FreeBSD.org Cc: f...@nist.gov Subject: Re: usb/132066: [ukbd] Keyboard failure USB keyboard DELL 760 Date: Fri, 13 Mar 2009 10:14:33 -0600 Hello, I have fixed this problem, but I don't understand why it works. I made the following changes to the config file and re-built the kernel: 1. remove device atkb 2. add device puc 3. add: options UKBD_DFLT_KEYMAP options UKBD_DFLT_KEYMAP=us.unix I have installed the same software with USB keyboards on many different systems, and this is the first time that I had to do this. The system now works correctly both using the command-line and X-windows. Is it possible that the keyboard is not being recognized correctly during the bootstrap process? Judah Levine Time and Frequency Division NIST Boulder ___ 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 thermometer - TEMPer - FreeBSD
On Tue, 14 Apr 2009, Torfinn Ingolfsen wrote: I got a new usb gadget, a TEMPer[1]. According to info on the net, this thermometer is a I2C device hooked up to a usb serial chip[2, 3]. The usb-to-serial chip is a WinChipHead 340 / 341, so that should work with the uchcom[4] driver. There was discussion about MFC'in this driver to RELENG_7 in february last year[5], but it doesn't seem to have happened. I tried garbbing the uchcom driver files from cvsweb and compiling the driver on my RELENG_7, but that didn't work. RELENG_7 as in r...@kg-work2# uname -a FreeBSD kg-work2.kg4.no 7.1-STABLE FreeBSD 7.1-STABLE #4: Sun Feb 8 20:56:08 CET 2009 r...@kg-work2.kg4.no:/usr/obj/usr/src/sys/SX270 i386 You don't say from what point in time you grabbed the driver from HEAD, but two major changes have happened in HEAD over the last few months that may well hinder your progress somewhat: The USB stack and drivers have been entirely replaced with a new USB stack, and the TTY subsystem has been heavily changed so that it no longer uses the Giant lock. Looking at the driver, I'm not sure if the latter will actually cause any problems for you, but the former will, so I'd recommend that you start with the uchcom source from before the new USB stack import: http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/sys/dev/usb/Attic/uchcom.c?rev=1.1;content-type=text%2Fplain I wouldn't be too surprised if you find that compiles and works as-is. Gavin ___ 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"
USB panic on 8.0/arm
Hi all, I have an NSLU2, which I am netbooting. I've been doing most of my work on it with USB removed from the kernel because the old stack would always panic. I've recently been trying the new USB stack, and have found that it still panics most of the time on boot. But not all the time. Firstly, please note that the version of Linux that was installed onto this hardware when I got it (not the factory installed OS, though) also seems to have problems most of the time with the USB controller, so I guess there is a chance that this is a hardware problem. That said, here are the symptoms: No USB in kernel, boots fine every time. New USB stack in the kernel: Just once, I've seen it probe and attach just fine. Here's proof: [snip] real memory = 33554432 (32 MB) avail memory = 25829376 (24 MB) ixp0: on motherboard ixp0: 37603 pcib0: on ixp0 pci0: on pcib0 ohci0: irq 28 at device 1.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ohci1: irq 27 at device 1.1 on pci0 ohci1: [ITHREAD] usbus1: on ohci1 ehci0: irq 26 at device 1.2 on pci0 ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: on ehci0 ixpclk0: on ixp0 [snip] Every other time I've booted with USB compiled in, I'll get a panic: RedBoot> go KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #5: Fri May 8 16:28:01 BST 2009 r...@buffy.york.ac.uk:/usr/obj/arm/usr/src-test/sys/NSLU CPU: IXP425 266MHz rev 1 (ARMv5TE) (XScale core) DC enabled IC enabled WB enabled LABT branch prediction enabled 32KB/32B 32-way Instruction cache 32KB/32B 32-way write-back-locking Data cache real memory = 33554432 (32 MB) avail memory = 25829376 (24 MB) ixp0: on motherboard ixp0: 37603 pcib0: on ixp0 pci0: on pcib0 ohci0: irq 28 at device 1.0 on pci0 ohci0: [ITHREAD] Fatal kernel mode data abort: 'External Linefetch Abort (P)' trapframe: 0xc00fbafc FSR=0406, FAR=Invalid, spsr=60d3 r0 =c0ae4000, r1 =f800, r2 =0034, r3 =c0ae407c r4 =1270, r5 =1278, r6 =1274, r7 =0003 r8 =1140, r9 =c0ae5000, r10=1140, r11=c00fbb88 r12=c0ae407c, ssp=c00fbb48, slr=c023c14c, pc =c023c148 [thread pid 0 tid 10 ] Stopped at ohci_suspend+0x140c:ldr r15, [r3, #0x024] db> bt Tracing pid 0 tid 10 td 0xc04fd110 db_trace_thread() at db_trace_thread+0xc scp=0xc041ee94 rlv=0xc0213778 (db_command_init+0x4c8) rsp=0xc00fb7f4 rfp=0xc00fb810 r10=0x0001 r9=0xc0503bd8 r8=0xc04fa75c r7=0x0062 r6=0x0002 r5=0x0010 r4=0xc04fd110 db_command_init() at db_command_init+0x3f0 scp=0xc02136a0 rlv=0xc0213008 (db_skip_to_eol+0x49c) rsp=0xc00fb814 rfp=0xc00fb8b8 r5=0x r4=0xc04cf0c0 db_skip_to_eol() at db_skip_to_eol+0x1d0 scp=0xc0212d3c rlv=0xc0213174 (db_command_loop+0x60) rsp=0xc00fb8bc rfp=0xc00fb8c8 r10=0x r8=0x0406 r7=0xc00fbafc r6=0xc0503bd0 r5=0x60d3 r4=0xc00fb8d4 db_command_loop() at db_command_loop+0xc scp=0xc0213120 rlv=0xc02153b0 (X_db_sym_numargs+0xf4) rsp=0xc00fb8cc rfp=0xc00fb9e8 X_db_sym_numargs() at X_db_sym_numargs+0x14 scp=0xc02152d0 rlv=0xc02cf8e8 (kdb_trap+0xa4) rsp=0xc00fb9ec rfp=0xc00fba14 r4=0x00c0 kdb_trap() at kdb_trap+0xc scp=0xc02cf850 rlv=0xc042e844 (badaddr_read+0x280) rsp=0xc00fba18 rfp=0xc00fba34 r10=0xc00fbef8 r9=0x r8=0xc00fbafc r7=0x0406 r6=0x r5=0x0406 r4=0xc00fbafc badaddr_read() at badaddr_read+0xfc scp=0xc042e6c0 rlv=0xc042ec08 (prefetch_abort_handler+0x36c) rsp=0xc00fba38 rfp=0xc00fba58 r6=0xc04fd110 r5=0xc00fbef8 r4=0xc00fbafc prefetch_abort_handler() at prefetch_abort_handler+0x2a4 scp=0xc042eb40 rlv=0xc042edd4 (data_abort_handler+0x110) rsp=0xc00fba5c rfp=0xc00fbaf8 r7=0xc04fd110 r6=0x1274 r5=0x1004 r4=0xc05189ec data_abort_handler() at data_abort_handler+0xc scp=0xc042ecd0 rlv=0xc04208dc (address_exception_entry+0x50) rsp=0xc00fbafc rfp=0xc00fbb88 r10=0x1140 r9=0xc0ae5000 r8=0x1140 r7=0x0003 r6=0x1274 r5=0x1004 r4=0x0107 ohci_suspend() at ohci_suspend+0x1138 scp=0xc023be74 rlv=0xc023ccc0 (ohci_init+0x208) rsp=0xc00fbb8c rfp=0xc00fbbc4 r10=0x1140 r9=0x0006 r8=0x1140 r7=0xc0ae5aa0 r6=0x r5=0xc0ae5000 r4=0x ohci_init() at ohci_init+0xc scp=0xc023cac4 rlv=0xc023e6ac (ohci_interrupt+0x1990) rsp=0xc00fbbc8 rfp=0xc00fbc00 r10=0xc0ae5aa0 r9=0x0009 r8=0xc0a9ee80 r7=0xc0ae5000 r6=0x1154 r5=0x1150 r4=0x1268 ohci_interrupt() at ohci_interrupt+0x1380 scp=0xc023e09c rlv=0xc02c9fb0 (device_attach+0x2c8) rsp=0xc00fbc04 rfp=0xc00
Re: USB panic on 8.0/arm
On Tue, 12 May 2009, Hans Petter Selasky wrote: On Tuesday 12 May 2009, Gavin Atkinson wrote: Hi all, I have an NSLU2, which I am netbooting. I've been doing most of my work on it with USB removed from the kernel because the old stack would always panic. I've recently been trying the new USB stack, and have found that it still panics most of the time on boot. But not all the time. In : src/sys/dev/usb/controller/ohci_pci.c Can you try to move the pci busmaster enable call further down in the attach routine, until the I/O resources are setup, then add before enable busmaster: #define OBARR(sc) bus_space_barrier((sc)->sc_io_tag, (sc)->sc_io_hdl, 0, (sc)->sc_io_size, \ BUS_SPACE_BARRIER_READ|BUS_SPACE_BARRIER_WRITE) #define OWRITE1(sc, r, x) \ do { OBARR(sc); bus_space_write_1((sc)->sc_io_tag, (sc)->sc_io_hdl, (r), (x)); } while (0) OWRITE4(sc, OHCI_COMMAND_STATUS, OHCI_HCR); /* Reset HC */ I'm not sure if it helps. It's just a guess. I'm assuming you meant to use the "OWRITE4" macro rather than OWRITE1 as that's what is used when accessing that register everywhere else. Assuming that is the case, I'm afraid the patch (below) makes no difference. Any other ideas? Thanks, Gavin Index: src-head/sys/dev/usb/controller/ohci_pci.c === RCS file: /home/ncvs/src/sys/dev/usb/controller/ohci_pci.c,v retrieving revision 1.5 diff -u -r1.5 ohci_pci.c --- src-head/sys/dev/usb/controller/ohci_pci.c 6 Apr 2009 00:32:54 - 1.5 +++ src-head/sys/dev/usb/controller/ohci_pci.c 12 May 2009 20:24:00 - @@ -205,7 +205,7 @@ } sc->sc_dev = self; - pci_enable_busmaster(self); +/* pci_enable_busmaster(self); */ /* * Some Sun PCIO-2 USB controllers have their intpin register @@ -239,6 +239,17 @@ } device_set_ivars(sc->sc_bus.bdev, &sc->sc_bus); + +#define OBARR(sc) bus_space_barrier((sc)->sc_io_tag, (sc)->sc_io_hdl, 0, (sc)->sc_io_size, \ +BUS_SPACE_BARRIER_READ|BUS_SPACE_BARRIER_WRITE) +#define OWRITE4(sc, r, x) \ + do { OBARR(sc); bus_space_write_4((sc)->sc_io_tag, (sc)->sc_io_hdl, (r), (x)); } while (0) + +OWRITE4(sc, OHCI_COMMAND_STATUS, OHCI_HCR); /* Reset HC */ + + pci_enable_busmaster(self); + + /* * ohci_pci_match will never return NULL if ohci_pci_probe * succeeded ___ 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: aue0 detected as ue0 on 8.0-RC2
[freebsd-current cc'd, as that was where the thread started, but this probably belongs on -usb, replies should go there] On Sat, 2009-10-31 at 21:59 +0100, Rick van der Zwet wrote: > The first net interface of a aue(4) define used to be called aue0 > afaik. But is now called ue0 (declared in usb/net/usb_ethernet.c). (no > sign of ue(4) btw). > > I was looking in the UPDATING, man, mailinglists freebsd-usb@ and > freebsd-curr...@. But I could not find the reason why the naming > convention on this aue differs from the regular stuff, anybody? > > /Rick > > quick# dmesg | tail -8 > ugen1.3: at usbus1 > aue0: on usbus1 > miibus1: on aue0 > ukphy0: PHY 1 on miibus1 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ue0: on aue0 > ue0: Ethernet address: 00:00:e8:00:11:36 > ue0: link state changed to DOWN > > quick# ifconfig -l > bfe0 lo0 ue0 Hmm, this looks like a serious bug, possibly in the new USB subsystem (HPS CC'd). I've got an axe(4) device, which also does the same: ugen7.3: at usbus7 axe0: on usbus7 axe0: PHYADDR 0xe0:0x10 miibus1: on axe0 ukphy0: PHY 16 on miibus1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on axe0 ue0: Ethernet address: 00:50:b6:05:57:a7 ue0: link state changed to DOWN Gavin ___ 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/146871: [usbdevs] [usb8] [patch] provide descriprive string for D-Link DUB-7H USB hub
The following reply was made to PR usb/146871; it has been noted by GNATS. From: Gavin Atkinson To: bug-follo...@freebsd.org Cc: Subject: Re: usb/146871: [usbdevs] [usb8] [patch] provide descriprive string for D-Link DUB-7H USB hub Date: Sun, 25 Jul 2010 12:45:33 +0100 (BST) HPS reports that this is already in the USB p4 tree, but not yet in SVN. ___ 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/134193: System freeze on usb MP3 player insertion
The following reply was made to PR usb/134193; it has been noted by GNATS. From: Gavin Atkinson To: bug-follo...@freebsd.org Cc: Subject: Re: usb/134193: System freeze on usb MP3 player insertion Date: Mon, 26 Jul 2010 21:25:20 +0100 (BST) The usb/usbdevs part of the patch has been committed, but the quirk has only been committed to p4 so far. ___ 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"
USB suspend/resume
Hi all, I've been trying to get a IBM ThinkPad X60 suspend/resume working correctly, and discovered that with uhci loaded, the machine would hang on resume. This is on head, but I believe this is aslo the cause of the laptop not resuming on stable/8. It turns out that this is because we sleep in the resume path. The resume path appears to run with interrupts disabled, and as a result we never wake up. A comment above uhci_suspend() saggests similar: /* NOTE: suspend/resume is called from * interrupt context and cannot sleep! However, we do sleep. We call usb_pause_mtx() several times during both tthe suspend and resume path, and on resume this is fatal. usb_pause_mtx() will use DELAY() when called before the machine has finished booting (ie cold != 0), but will call pause() once booted. To prove this, I've tested the following gross hack, which fixes suspend/resume on the ThinkPad X60: Index: sys/dev/usb/controller/ehci_pci.c === --- sys/dev/usb/controller/ehci_pci.c (revision 222417) +++ sys/dev/usb/controller/ehci_pci.c (working copy) @@ -118,10 +118,16 @@ ehci_pci_resume(device_t self) { ehci_softc_t *sc = device_get_softc(self); + int mycold; + mycold = cold; + cold = 1; + ehci_pci_takecontroller(self); ehci_resume(sc); + cold = mycold; + bus_generic_resume(self); return (0); Index: sys/dev/usb/controller/uhci_pci.c === --- sys/dev/usb/controller/uhci_pci.c (revision 222417) +++ sys/dev/usb/controller/uhci_pci.c (working copy) @@ -104,11 +104,17 @@ uhci_pci_resume(device_t self) { uhci_softc_t *sc = device_get_softc(self); + int mycold; + mycold = cold; + cold = 1; + pci_write_config(self, PCI_LEGSUP, PCI_LEGSUP_USBPIRQDEN, 2); uhci_resume(sc); + cold = mycold; + bus_generic_resume(self); return (0); } The above hack fixes this X60 and allows suspend/resume to work, and USB devices work perfectly after the suspend/resume. Other controllers look like they may also be affected - at least ohci does the same. So, I guess my question to the USB experts is: What is the correct fix? I see two possibilities: 1) Have a variable somewhere called "suspres" or similar, which is set at the start of the suspend, and cleared at the end of the resume. usb_pause_mtx() then changes it's behaviour on (cold || suspres). This may have to be a global variable, being incremented on suspend and decremented on resume, as we don't pass a softc into usb_pause_mtx(), however then we have issues relating to when one controller suspends before the others, or resume before the others. 2) Kick off a separate task to do the resume. Problems with this is thet it doesn't fix the suspend path, but also that we may need to rely on USB being back before the rest of the resume completes. (What happens if we have / or another filesystem mounted from a USB device?) I guess #1 is the simplest solution, and should have fewest side effects, however it does mean that every attachment would need to be modified in order to set and clear the variable. It sort of feels like this should be handled more centrally, but I'm not sure of the best way to achieve this. Any [other] suggestions? Gavin ___ 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: FreeBSD does not recognize USB devices in INTEL D102GGC2 motherboard
On Sat, 4 Jun 2011, Edgar Velasquez Mercado wrote: > Hi everyone: > I have a machine with Intel D102GGC2 motherboard running FreeBSD 8.2, it is > not able to recognize any USB device, how could I fix that? Can you provide the output of "pciconf -lv" please? Gavin ___ 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 suspend/resume
On Sat, 4 Jun 2011, Hans Petter Selasky wrote: > On Saturday 04 June 2011 19:08:22 Gavin Atkinson wrote: > > Hi all, > > > > I've been trying to get a IBM ThinkPad X60 suspend/resume working > > correctly, and discovered that with uhci loaded, the machine would hang on > > resume. This is on head, but I believe this is aslo the cause of the > > laptop not resuming on stable/8. > > > > It turns out that this is because we sleep in the resume path. The resume > > path appears to run with interrupts disabled, and as a result we never > > wake up. A comment above uhci_suspend() saggests similar: > > > > /* NOTE: suspend/resume is called from > > * interrupt context and cannot sleep! > > > > However, we do sleep. We call usb_pause_mtx() several times during both > > tthe suspend and resume path, and on resume this is fatal. > > usb_pause_mtx() will use DELAY() when called before the machine has > > finished booting (ie cold != 0), but will call pause() once booted. > > [snip] > > > > So, I guess my question to the USB experts is: What is the correct fix? > > I see two possibilities: > > > > 1) Have a variable somewhere called "suspres" or similar, which is set at > >the start of the suspend, and cleared at the end of the resume. > >usb_pause_mtx() then changes it's behaviour on (cold || suspres). > >This may have to be a global variable, being incremented on suspend and > >decremented on resume, as we don't pass a softc into usb_pause_mtx(), > >however then we have issues relating to when one controller suspends > >before the others, or resume before the others. > > > > 2) Kick off a separate task to do the resume. Problems with this is thet > >it doesn't fix the suspend path, but also that we may need to rely on > >USB being back before the rest of the resume completes. (What happens > >if we have / or another filesystem mounted from a USB device?) > > > > I guess #1 is the simplest solution, and should have fewest side effects, > > however it does mean that every attachment would need to be modified in > > order to set and clear the variable. It sort of feels like this should be > > handled more centrally, but I'm not sure of the best way to achieve this. > > > > Where is it documented that the resume/suspend callbacks are not run from a > thread context? As far as I can tell, it does run in a thread context. I've not found any specific documentation saying what can and cannot be done during suspend/resume, other than that comment in uhci.c above uhci_suspend(). Do you have any idea where you got that information from? The old stack had this comment: * We need to switch to polling mode here, because this routine is * called from an interrupt context. This is all right since we * are almost suspended anyway. It was purely based on htat comment that I investigated the possibility that this was related to pause(). I believe that the reason that this works on some machines but not this one right now is purely down to the order in which things are brought back. On this laptop, hpet(4) is resumed after the USB busses. Presumably from that point onwards, it is possible to sleep for a length of time? I'm not sure. Before that, pause() hangs indefinitely, waiting for an interrupt that never happens. This is just a theory - I've not proved it conclusively yet. I'm sort of hoping that somebody who knows more about suspend/resume can offer some pointers here. Gavin ___ 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/107642: [patch] add Ralink Technology RT2501 USB/RT2601USB chipset driver from OpenBSD
The following reply was made to PR usb/107642; it has been noted by GNATS. From: Gavin Atkinson <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: usb/107642: [patch] add Ralink Technology RT2501 USB/RT2601USB chipset driver from OpenBSD Date: Wed, 16 May 2007 18:10:48 +0100 This driver has been imported to HEAD as src/sys/dev/usb/if_rum.c etc on Sun May 6 10:07:20 2007. Thanks for your submission! ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb/107128: [usb] panic while accessing usb msdos flashkey
The following reply was made to PR usb/107128; it has been noted by GNATS. From: Gavin Atkinson <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: usb/107128: [usb] panic while accessing usb msdos flashkey Date: Fri, 18 May 2007 16:47:05 +0100 This is a duplicate of usb/107116 and should be closed. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb/107116: [usb] panic while accessing usb msdos pccard
The following reply was made to PR usb/107116; it has been noted by GNATS. From: Gavin Atkinson <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: usb/107116: [usb] panic while accessing usb msdos pccard Date: Fri, 18 May 2007 16:54:35 +0100 Hi, It looks like this problem is related to the contents of the filesystem, which may either be corrupted or which FreeBSD may for some reason not be able to handle. Do you still have the memory stick, and cam you still recreate the issue? Thanks, Gavin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb/112460: ehci USB 2.0 doesn't work on nforce4
The following reply was made to PR usb/112460; it has been noted by GNATS. From: Gavin Atkinson <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: usb/112460: ehci USB 2.0 doesn't work on nforce4 Date: Mon, 21 May 2007 19:02:10 +0100 Duplicate of usb/112461, other PR has more information. This one should be closed. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb/112569: USB mode may wrong when mounting psp
The following reply was made to PR usb/112569; it has been noted by GNATS. From: Gavin Atkinson <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: usb/112569: USB mode may wrong when mounting psp Date: Tue, 22 May 2007 15:04:31 +0100 This PR is a duplicate of usb/112568 and should be closed. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb/112161: [usbdevs] [patch] Option N.V. Fusion UMTS Quad-GPRS
Synopsis: [usbdevs] [patch] Option N.V. Fusion UMTS Quad-GPRS State-Changed-From-To: open->closed State-Changed-By: gavin State-Changed-When: Fri Jun 8 12:16:33 UTC 2007 State-Changed-Why: Patch committed by kevlo@ to HEAD (ubsa.c 1.20 / usbdevs 1.276) and MFC'd http://www.freebsd.org/cgi/query-pr.cgi?pr=112161 ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb/74453: Q-lity CD-RW USB ECW-043 (ScanLogic SL11R chipset) does not work
Synopsis: Q-lity CD-RW USB ECW-043 (ScanLogic SL11R chipset) does not work State-Changed-From-To: open->feedback State-Changed-By: gavin State-Changed-When: Thu Jun 14 17:49:00 UTC 2007 State-Changed-Why: To submitter: Is this still a problem on more recent versions of FreeBSD? Have you tried the suggestion in the PR of using the WRONG_CSWSIG quirk? http://www.freebsd.org/cgi/query-pr.cgi?pr=74453 ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb/79140: [patch] WD Firewire/USB Combo hangs under load on USB interface.
Old Synopsis: WD Firewire/USB Combo hangs under load on USB interface. New Synopsis: [patch] WD Firewire/USB Combo hangs under load on USB interface. State-Changed-From-To: open->feedback State-Changed-By: gavin State-Changed-When: Mon Jun 18 16:25:27 UTC 2007 State-Changed-Why: To submitter: Is this still an issue with more recent versions of FreeBSD? The quirk you have submitted looks reasonable, can I confirm that this patch works well for you? http://www.freebsd.org/cgi/query-pr.cgi?pr=79140 ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb/78989: please add USB keyboard support to install CD's
Synopsis: please add USB keyboard support to install CD's State-Changed-From-To: open->feedback State-Changed-By: gavin State-Changed-When: Mon Jun 18 16:27:45 UTC 2007 State-Changed-Why: To submitter: I believe USB keyboards have been supported during install for a while now (possibly 6.0 or before). Is this still a problem for you on recent versions of FreeBSD? http://www.freebsd.org/cgi/query-pr.cgi?pr=78989 ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb/74453: Q-lity CD-RW USB ECW-043 (ScanLogic SL11R chipset) does not work
The following reply was made to PR usb/74453; it has been noted by GNATS. From: Gavin Atkinson <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Subject: Re: usb/74453: Q-lity CD-RW USB ECW-043 (ScanLogic SL11R chipset) does not work Date: Fri, 22 Jun 2007 14:28:37 +0100 For the audit-trail: Forwarded Message From: Federico Galvez-Durand Besnard <[EMAIL PROTECTED]> Date: Fri, 22 Jun 2007 11:23:34 +0200 Yes, it is still the same problem: Begin Follow-up camelot# uname -a FreeBSD camelot.local 6.2-RELEASE-p5 FreeBSD 6.2-RELEASE-p5 #0: Thu Jun 21 19:23:02 CEST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CAMELOT i386 camelot# dmesg | grep umass0 umass0: ScanLogic USBIDE ScanLogic USBIDE, rev 1.10/2.61, addr 2 umass0: Invalid CSW: tag 849 should be 1 umass0: Invalid CSW: tag 849 should be 2 umass0: Invalid CSW: tag 849 should be 3 umass0: Invalid CSW: tag 849 should be 4 umass0: Invalid CSW: tag 849 should be 5 umass0: Invalid CSW: tag 849 should be 6 (da0:umass-sim0:0:0:0): got CAM status 0x4 (da0:umass-sim0:0:0:0): fatal error, failed to attach to device (da0:umass-sim0:0:0:0): lost device umass0: Invalid CSW: tag 849 should be 7 umass0: Invalid CSW: tag 849 should be 8 umass0: Invalid CSW: tag 849 should be 9 umass0: Invalid CSW: tag 849 should be 10 umass0: Invalid CSW: tag 849 should be 11 (da0:umass-sim0:0:0:0): removing device entry Opened disk da0 -> 5 [EMAIL PROTECTED] camcontrol devlist -v scbus0 on ata0 bus 0: < > at scbus0 target -1 lun -1 () scbus1 on ata1 bus 0: at scbus1 target 0 lun 0 (pass0,cd0) < > at scbus1 target -1 lun -1 () scbus2 on umass-sim0 bus 0: < > at scbus2 target 0 lun 0 (pass1) scbus-1 on xpt0 bus 0: < > at scbus-1 target -1 lun -1 (xpt0) [EMAIL PROTECTED] usbdevs -v Controller /dev/usb0: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 addr 2: full speed, self powered, config 1, ScanLogic USBIDE(0x0002), ScanLogic USBIDE(0x04ce), rev 2.61 port 2 powered [EMAIL PROTECTED] diff -u umass.c.orig /usr/src/sys/dev/usb/umass.c --- umass.c.origThu Jun 21 19:02:27 2007 +++ /usr/src/sys/dev/usb/umass.cThu Jun 21 19:02:58 2007 @@ -460,7 +460,7 @@ }, { USB_VENDOR_SCANLOGIC, USB_PRODUCT_SCANLOGIC_SL11R, RID_WILDCARD, UMASS_PROTO_ATAPI | UMASS_PROTO_BBB, - NO_INQUIRY + NO_INQUIRY | WRONG_CSWSIG }, { USB_VENDOR_SHUTTLE, USB_PRODUCT_SHUTTLE_EUSB, RID_WILDCARD, UMASS_PROTO_ATAPI | UMASS_PROTO_CBI_I, End Follow-up Some comments: This was my original post: http://lists.freebsd.org/mailman/htdig/freebsd-usb/2004-December/000318.html I went through my files and found some work I did and reported to this list: http://lists.freebsd.org/mailman/htdig/freebsd-usb/2005-February/000660.html As far as I remember, I managed to mount this CDROM and use it in RO mode. I could not make the kernel recognise it as a RW device. At that time, I got many cheap working flash drives > 512MB and a new machine, so this machine ([EMAIL PROTECTED]/384MB mem) was assigned to a mission in which backup on CD was no longer necessary. This hacking was no longer a priority. And now I guess I did not report my work in the right way because I can't see these messages: http://lists.freebsd.org/mailman/htdig/freebsd-usb/2004-December/000318.html http://lists.freebsd.org/mailman/htdig/freebsd-usb/2005-February/000660.html linked to my orginial PR: Number:74453 Category:usb Synopsis:Q-lity CD-RW USB ECW-043 (ScanLogic SL11R chipset) does not work Severity:non-critical Priority:low Responsible:freebsd-usb@FreeBSD.org State:feedback Class:sw-bug Arrival-Date:Sat Nov 27 17:30:24 GMT 2004 Closed-Date: Last-Modified:Thu Jun 14 17:50:21 GMT 2007 Originator:Federico Besnard Release:5.3 Stable I need to pay more attention on how to handle a PR. Thanks. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb/83022: ALI USB 2.0 EHCI Controller is not detected
Synopsis: ALI USB 2.0 EHCI Controller is not detected State-Changed-From-To: open->feedback State-Changed-By: gavin State-Changed-When: Fri Jun 22 13:24:25 UTC 2007 State-Changed-Why: To submitter: Is this still an issue for you on more recent versions of FreeBSD? http://www.freebsd.org/cgi/query-pr.cgi?pr=83022 ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb/83022: ALI USB 2.0 EHCI Controller is not detected
Synopsis: ALI USB 2.0 EHCI Controller is not detected State-Changed-From-To: feedback->closed State-Changed-By: gavin State-Changed-When: Tue Jun 26 21:51:48 UTC 2007 State-Changed-Why: Submitter reports (in private email) that this is now resolved http://www.freebsd.org/cgi/query-pr.cgi?pr=83022 ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb/118485: [usbdevs] [patch] Logitech Headset Workaround
The following reply was made to PR usb/118485; it has been noted by GNATS. From: Gavin Atkinson <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Subject: Re: usb/118485: [usbdevs] [patch] Logitech Headset Workaround Date: Sun, 22 Jun 2008 21:29:23 +0100 (BST) Updated patch, with the entry sorted correctly and with better whitespacing (although the whitespace in both files is anything but unified) Index: src/sys/dev/usb/usbdevs === RCS file: /usr/ncvs/src/sys/dev/usb/usbdevs,v retrieving revision 1.360 diff -u -r1.360 usbdevs --- src/sys/dev/usb/usbdevs13 Jun 2008 02:02:21 - 1.360 +++ src/sys/dev/usb/usbdevs22 Jun 2008 20:25:01 - @@ -1581,6 +1581,7 @@ product LOGITECH QUICKCAMPRO 0x0810 QuickCam Pro product LOGITECH QUICKCAMEXP 0x0840 QuickCam Express product LOGITECH QUICKCAM0x0850 QuickCam +product LOGITECH HS0A01 0x0a01 USB Head Set product LOGITECH N43 0xc000 N43 product LOGITECH N48 0xc001 N48 mouse product LOGITECH MBA47 0xc002 M-BA47 mouse Index: src/sys/dev/usb/usb_quirks.c === RCS file: /usr/ncvs/src/sys/dev/usb/usb_quirks.c,v retrieving revision 1.65 diff -u -r1.65 usb_quirks.c --- src/sys/dev/usb/usb_quirks.c 14 Mar 2008 15:59:30 - 1.65 +++ src/sys/dev/usb/usb_quirks.c 22 Jun 2008 20:25:01 - @@ -75,6 +75,7 @@ { USB_VENDOR_SILICONPORTALS, USB_PRODUCT_SILICONPORTALS_YAPPHONE, 0x100, { UQ_AU_INP_ASYNC }}, { USB_VENDOR_LOGITECH, USB_PRODUCT_LOGITECH_UN53B, ANY, { UQ_NO_STRINGS }}, + { USB_VENDOR_LOGITECH, USB_PRODUCT_LOGITECH_HS0A01, ANY, { UQ_AU_INP_ASYNC }}, /* XXX These should have a revision number, but I don't know what they are. */ { USB_VENDOR_HP, USB_PRODUCT_HP_895C, ANY, { UQ_BROKEN_BIDIR }}, { USB_VENDOR_HP, USB_PRODUCT_HP_880C, ANY, { UQ_BROKEN_BIDIR }}, ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb/119150: [usbdevs] [patch] new usbdevs for CDMA 1xEVDO devices
The following reply was made to PR usb/119150; it has been noted by GNATS. From: Gavin Atkinson <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Subject: Re: usb/119150: [usbdevs] [patch] new usbdevs for CDMA 1xEVDO devices Date: Sun, 22 Jun 2008 21:50:16 +0100 (BST) Updated patch, against HEAD. Since the PR was submitted, the vendor ID has already been assigned the name QUALCOMMINC, so reflect that change in the patch also. Index: src/sys/dev/usb/usbdevs === RCS file: /usr/ncvs/src/sys/dev/usb/usbdevs,v retrieving revision 1.360 diff -u -r1.360 usbdevs --- src/sys/dev/usb/usbdevs13 Jun 2008 02:02:21 - 1.360 +++ src/sys/dev/usb/usbdevs22 Jun 2008 20:48:13 - @@ -522,6 +522,7 @@ vendor FOSSIL0x0e67 Fossil, Inc vendor GMATE 0x0e7e G.Mate, Inc vendor OTI 0x0ea0 Ours Technology +vendor YISO 0x0eab Yiso Wireless Co. vendor PILOTECH 0x0eaf Pilotech vendor NOVATECH 0x0eb0 NovaTech vendor ITEGNO0x0eba iTegno @@ -1956,6 +1957,7 @@ product QUALCOMM2 RWT_FCT0x3100 RWT FCT-CDMA 2000 1xRTT modem product QUALCOMM2 CDMA_MSM 0x3196 CDMA Technologies MSM modem product QUALCOMMINC CDMA_MSM 0x0001 CDMA Technologies MSM modem +product QUALCOMMINC AC87000xfffe CDMA 1xEVDO USB modem /* Qtronix products */ product QTRONIX 980N 0x2011 Scorpion-980N keyboard @@ -2382,6 +2384,9 @@ product YANO U640MO 0x0101 U640MO-03 product YANO FW800HD 0x05fc METALWEAR-HDD +/* Yiso Wireless Co. products */ +product YISO C893 0xc893 CDMA 2000 1xEVDO PC Card + /* Z-Com products */ product ZCOM M4Y750 0x0001 M4Y-750 product ZCOM XI725 0x0002 XI-725/726 ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb/126845: Cyberpower UPS is attached as uhid instead of ugen
The following reply was made to PR usb/126845; it has been noted by GNATS. From: Gavin Atkinson <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Mattias Lindgren <[EMAIL PROTECTED]> Subject: Re: usb/126845: Cyberpower UPS is attached as uhid instead of ugen Date: Tue, 26 Aug 2008 11:08:43 +0100 (BST) Can you try this patch please? Index: src/sys/dev/usb/usb_quirks.c === RCS file: /home/ncvs/src/sys/dev/usb/usb_quirks.c,v retrieving revision 1.63.2.2 diff -u -r1.63.2.2 usb_quirks.c --- src/sys/dev/usb/usb_quirks.c 12 Aug 2008 19:40:18 - 1.63.2.2 +++ src/sys/dev/usb/usb_quirks.c 26 Aug 2008 10:05:03 - @@ -96,6 +96,8 @@ ANY, { UQ_HID_IGNORE }}, { USB_VENDOR_BELKIN, USB_PRODUCT_BELKIN_F6C550AVR, ANY, { UQ_HID_IGNORE }}, + { USB_VENDOR_CYBERPOWER, USB_PRODUCT_CYBERPOWER_1500CAVRLCD, + ANY, { UQ_HID_IGNORE }}, { USB_VENDOR_DELORME, USB_PRODUCT_DELORME_EARTHMATE, ANY, { UQ_HID_IGNORE }}, { USB_VENDOR_ITUNERNET, USB_PRODUCT_ITUNERNET_USBLCD2X20, Index: src/sys/dev/usb/usbdevs === RCS file: /home/ncvs/src/sys/dev/usb/usbdevs,v retrieving revision 1.328.2.16 diff -u -r1.328.2.16 usbdevs --- src/sys/dev/usb/usbdevs19 Aug 2008 01:51:37 - 1.328.2.16 +++ src/sys/dev/usb/usbdevs26 Aug 2008 10:04:01 - @@ -364,6 +364,7 @@ vendor DIGITALSTREAM 0x074e Digital Stream vendor AUREAL0x0755 Aureal Semiconductor vendor MIDIMAN 0x0763 Midiman +vendor CYBERPOWER 0x0764 CyberPower vendor SURECOM 0x0769 Surecom Technology vendor LINKSYS2 0x077b Linksys vendor GRIFFIN 0x077d Griffin Technology @@ -1063,6 +1064,9 @@ product CURITEL HX57XB 0x2101 CDMA 2000 1xRTT USB modem (HX-570/575B/PR-600) product CURITEL PC5740 0x3701 Broadband Wireless modem +/* CyberPower products */ +product CYBERPOWER 1500CAVRLCD0x0501 1500CAVRLCD + /* CyberTAN Technology products */ product CYBERTAN TG54USB 0x1666 TG54USB ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb/126845: Cyberpower UPS is attached as uhid instead of ugen
On Tue, 2008-08-26 at 09:56 -0600, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Gavin Atkinson <[EMAIL PROTECTED]> writes: > : +vendor CYBERPOWER 0x0764 CyberPower > > 0x764 is 1892 decimal and listed in the usb database as: > > 1892|Cyber Power Systems, Inc. > > So maybe that's what should be where "CyberPower" is now? Thanks for noticing! I always forget that list is in decimal whenever I grep it. The submitter wanted extra info on how to apply it, so I've given them an updated patch, and I'll check through the other patches I've made to make sure I didn't make the same mistake with any of them. Gavin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb/126845: Cyberpower UPS is attached as uhid instead of ugen
The following reply was made to PR usb/126845; it has been noted by GNATS. From: Gavin Atkinson <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Subject: Re: usb/126845: Cyberpower UPS is attached as uhid instead of ugen Date: Wed, 27 Aug 2008 12:02:41 +0100 --=-NPzv00iMx66t2hTUfOpS Content-Type: text/plain Content-Transfer-Encoding: 7bit Submitter confirms that the attached patch fixes things for him. (Patch slightly updated to match the official company name as registered in usb.if) --=-NPzv00iMx66t2hTUfOpS Content-Disposition: attachment; filename=126845.diff Content-Transfer-Encoding: base64 Content-Type: text/x-patch; name=126845.diff; charset=ASCII SW5kZXg6IHNyYy9zeXMvZGV2L3VzYi91c2JfcXVpcmtzLmMNCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJDUyBmaWxl OiAvaG9tZS9uY3ZzL3NyYy9zeXMvZGV2L3VzYi91c2JfcXVpcmtzLmMsdg0KcmV0cmlldmluZyBy ZXZpc2lvbiAxLjYzLjQuMQ0KZGlmZiAtdSAtcjEuNjMuNC4xIHVzYl9xdWlya3MuYw0KLS0tIHNy Yy9zeXMvZGV2L3VzYi91c2JfcXVpcmtzLmMJNyBKYW4gMjAwOCAyMzoxMjo0NSAtMDAwMAkxLjYz LjQuMQ0KKysrIHNyYy9zeXMvZGV2L3VzYi91c2JfcXVpcmtzLmMJMjYgQXVnIDIwMDggMTc6NDQ6 MDkgLTAwMDANCkBAIC05Niw2ICs5Niw4IEBADQogCUFOWSwgeyBVUV9ISURfSUdOT1JFIH19LA0K ICB7IFVTQl9WRU5ET1JfQkVMS0lOLCBVU0JfUFJPRFVDVF9CRUxLSU5fRjZDNTUwQVZSLA0KIAlB TlksIHsgVVFfSElEX0lHTk9SRSB9fSwNCisgeyBVU0JfVkVORE9SX0NZQkVSUE9XRVIsIFVTQl9Q Uk9EVUNUX0NZQkVSUE9XRVJfMTUwMENBVlJMQ0QsDQorCUFOWSwgeyBVUV9ISURfSUdOT1JFIH19 LA0KICB7IFVTQl9WRU5ET1JfREVMT1JNRSwgVVNCX1BST0RVQ1RfREVMT1JNRV9FQVJUSE1BVEUs DQogCUFOWSwgeyBVUV9ISURfSUdOT1JFIH19LA0KICB7IFVTQl9WRU5ET1JfSVRVTkVSTkVULCBV U0JfUFJPRFVDVF9JVFVORVJORVRfVVNCTENEMlgyMCwNCkluZGV4OiBzcmMvc3lzL2Rldi91c2Iv dXNiZGV2cw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3N5cy9kZXYvdXNi L3VzYmRldnMsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjMyOC4yLjEuMi4xDQpkaWZmIC11IC1y MS4zMjguMi4xLjIuMSB1c2JkZXZzDQotLS0gc3JjL3N5cy9kZXYvdXNiL3VzYmRldnMJNyBKYW4g MjAwOCAyMzoxMjo0NSAtMDAwMAkxLjMyOC4yLjEuMi4xDQorKysgc3JjL3N5cy9kZXYvdXNiL3Vz YmRldnMJMjYgQXVnIDIwMDggMTc6NDQ6MDkgLTAwMDANCkBAIC0zNjQsNiArMzY0LDcgQEANCiB2 ZW5kb3IgRElHSVRBTFNUUkVBTQkweDA3NGUJRGlnaXRhbCBTdHJlYW0NCiB2ZW5kb3IgQVVSRUFM CQkweDA3NTUJQXVyZWFsIFNlbWljb25kdWN0b3INCiB2ZW5kb3IgTUlESU1BTgkJMHgwNzYzCU1p ZGltYW4NCit2ZW5kb3IgQ1lCRVJQT1dFUgkweDA3NjQJQ3liZXIgUG93ZXIgU3lzdGVtcywgSW5j Lg0KIHZlbmRvciBTVVJFQ09NCQkweDA3NjkJU3VyZWNvbSBUZWNobm9sb2d5DQogdmVuZG9yIExJ TktTWVMyCQkweDA3N2IJTGlua3N5cw0KIHZlbmRvciBHUklGRklOCQkweDA3N2QJR3JpZmZpbiBU ZWNobm9sb2d5DQpAQCAtMTA1Niw2ICsxMDU3LDkgQEANCiBwcm9kdWN0IENVUklURUwgSFg1N1hC CQkweDIxMDEJQ0RNQSAyMDAwIDF4UlRUIFVTQiBtb2RlbSAoSFgtNTcwLzU3NUIvUFItNjAwKQ0K IHByb2R1Y3QgQ1VSSVRFTCBQQzU3NDAJCTB4MzcwMQlCcm9hZGJhbmQgV2lyZWxlc3MgbW9kZW0N CiANCisvKiBDeWJlclBvd2VyIHByb2R1Y3RzICovDQorcHJvZHVjdCBDWUJFUlBPV0VSIDE1MDBD QVZSTENECTB4MDUwMQkxNTAwQ0FWUkxDRA0KKw0KIC8qIEN5YmVyVEFOIFRlY2hub2xvZ3kgcHJv ZHVjdHMgKi8NCiBwcm9kdWN0IENZQkVSVEFOIFRHNTRVU0IJMHgxNjY2CVRHNTRVU0INCiANCg== --=-NPzv00iMx66t2hTUfOpS-- ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
usb/126927: [zyd] [patch] Support ZyDAS G202
>Number: 126927 >Category: usb >Synopsis: [zyd] [patch] Support ZyDAS G202 >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-usb >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Aug 28 21:20:01 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Gavin Atkinson >Release:FreeBSD 7.0-STABLE amd64 >Organization: >Environment: System: FreeBSD buffy.york.ac.uk 7.0-STABLE FreeBSD 7.0-STABLE #3: Fri Jun 20 09:21:51 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC amd64 >Description: Add support for the USB dongle I've got in my hand >How-To-Repeat: Take adapter out of my hand. Plug adapter into my laptop. >Fix: --- zyd_g202.diff begins here --- Index: src/sys/dev/usb/if_zyd.c === RCS file: /home/ncvs/src/sys/dev/usb/if_zyd.c,v retrieving revision 1.18 diff -u -r1.18 if_zyd.c --- src/sys/dev/usb/if_zyd.c7 Jun 2008 18:38:02 - 1.18 +++ src/sys/dev/usb/if_zyd.c13 Aug 2008 17:29:35 - @@ -140,6 +140,7 @@ ZYD_ZD1211B_DEV(VTECH, ZD1211B), ZYD_ZD1211B_DEV(ZCOM, ZD1211B), ZYD_ZD1211B_DEV(ZYDAS, ZD1211B), + ZYD_ZD1211B_DEV(ZYXEL, G202), ZYD_ZD1211B_DEV(ZYXEL, M202), ZYD_ZD1211B_DEV(ZYXEL, G220V2), }; Index: src/sys/dev/usb/usbdevs === RCS file: /home/ncvs/src/sys/dev/usb/usbdevs,v retrieving revision 1.367 diff -u -r1.367 usbdevs --- src/sys/dev/usb/usbdevs 21 Aug 2008 20:37:38 - 1.367 +++ src/sys/dev/usb/usbdevs 28 Aug 2008 20:12:09 - @@ -2440,3 +2440,4 @@ product ZYXEL AG225H 0x3409 AG-225H product ZYXEL M202 0x340a M-202 product ZYXEL G220V2 0x340f G-220 v2 +product ZYXEL G202 0x3410 G-202 --- zyd_g202.diff ends here --- >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/127543: [patch] [ubsa] Support Option Globetrotter HSDPA modem
>Number: 127543 >Category: usb >Synopsis: [patch] [ubsa] Support Option Globetrotter HSDPA modem >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-usb >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Sep 22 15:30:02 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Gavin Atkinson >Release:FreeBSD 8.0-CURRENT amd64 >Organization: >Environment: System: FreeBSD blade32.york.ac.uk 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Mon Aug 18 14:12:25 BST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/B32 amd64 >Description: Add support for the USB HSDPA modem found in the Sony VGN-TZ31WN laptop, amongst others. >How-To-Repeat: N/A >Fix: Note that I've taken the name "Scorpion" from the Linux driver, which also contains a multitude of other product IDs we may want to port across wholesale. Note also that this patch is against -HEAD but has actually only been tested against RELENG_7. I don't believe there are any changes between the two that would mean this didn't work on -HEAD, however. --- hsdpa.diff begins here --- Index: src/sys/dev/usb/ubsa.c === RCS file: /home/ncvs/src/sys/dev/usb/ubsa.c,v retrieving revision 1.40 diff -u -r1.40 ubsa.c --- src/sys/dev/usb/ubsa.c 14 Sep 2008 15:21:22 - 1.40 +++ src/sys/dev/usb/ubsa.c 22 Sep 2008 12:49:27 - @@ -238,6 +238,8 @@ { USB_VENDOR_OPTION, USB_PRODUCT_OPTION_GT3GPLUS }, /* Option GlobeTrotter Max 3.6 */ { USB_VENDOR_OPTION, USB_PRODUCT_OPTION_GTMAX36 }, + /* Option GlobeTrotter HSDPA */ + { USB_VENDOR_OPTION, USB_PRODUCT_OPTION_SCORPION }, /* Huawei Mobile */ { USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_MOBILE }, { USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_E270 }, Index: src/sys/dev/usb/usbdevs === RCS file: /home/ncvs/src/sys/dev/usb/usbdevs,v retrieving revision 1.372 diff -u -r1.372 usbdevs --- src/sys/dev/usb/usbdevs 19 Sep 2008 09:04:06 - 1.372 +++ src/sys/dev/usb/usbdevs 22 Sep 2008 12:49:27 - @@ -1871,6 +1871,7 @@ product OPTION GT3GQUAD0x6300 GlobeTrotter 3G QUAD datacard product OPTION GT3GPLUS0x6600 GlobeTrotter 3G+ datacard product OPTION GTMAX36 0x6701 GlobeTrotter Max 3.6 Modem +product OPTION SCORPION0x6901 GlobeTrotter HSDPA Modem /* OQO */ product OQO WIFI01 0x0002 model 01 WiFi interface --- hsdpa.diff ends here --- >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: HEADSUP usb2/usb4bsd to become default in GENERIC
On Sat, 2009-02-07 at 21:21 -0800, Alfred Perlstein wrote: > * Maxim Sobolev [090206 01:50] wrote: > > Alfred Perlstein wrote: > > > - Update GENERIC to use usb2 device names. > > > > Wasn't there a plan to rename usb2 devices to match oldusb names (where > > applicable) once oldusb had been killed? I don't see it in the list. > > Probably, although coming from the other side as a user I find it pretty > annoying when there's somewhat gratuitous changes to the kernel config > files that I don't really care about that cause my kernels to break. The vast majority of our users do not run -CURRENT, and so haven't had to change config files yet. One day, those users will be migrating from 7.x to 8.x, and shouldn't need to change their kernel config for a "somewhat gratuitous change". Your argument only works if people had already had to change their config files once (usb -> usb2), and that by renaming these back they will have to change their kernel config back. Only people running -CURRENT will end up having to do this twice (or indeed at all) if the rename takes place, end users will not need to do it at all. > Basically, calling it usb2 isn't as bad as renaming it back to "usb" > as it's less disruptive in my book. Again, I disagree. Gavin ___ 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"