cc'ing "Mr. rman," jhb, since this was his change. Stephane E. Potvin wrote: > Doug Barton wrote: >> [ No response from the -usb list, so I'll try here. ] >> >> Howdy, >> >> I have a new Dell Latitude D620, and using recent -current I get this: >> >> ehci0: <Intel 82801GB/R (ICH7) USB 2.0 controller> mem >> 0xffa80000-0xffa803ff irq 20 at device 29.7 on pci0 >> ehci0: Could not map memory >> device_attach: ehci0 attach returned 6 >> >> FWIW, I also saw a user on the -stable list report this same problem. >> I'm assuming this is bad, but what to do about it? >> >> >> I'm also getting some unknown devices: >> >> uhub4: <vendor 0x413c product 0xa005, class 9/0, rev 2.00/50.18, addr >> 2> on uhub0 >> uhub5: <vendor 0x0b97 product 0x7761, class 9/0, rev 1.10/1.10, addr >> 3> on uhub4 >> ugen2: <vendor 0x413c product 0x8103, class 224/1, rev 2.00/24.22, >> addr 6> on uhub4 >> uhub6: <vendor 0x413c product 0x0058, class 9/0, rev 2.00/0.00, addr >> 2> on uhub3 >> >> Vendor ID 0x413c is Dell, and is already in the usbdevs file. The >> other vendor is O2, and I got their ID for the attached patch from the >> list at http://www.usb.org/developers/tools. The 0x0058 device is >> already in our usbdevs file, it's the port replicator (docking >> station) that the laptop is plugged into currently. I added the 0x8103 >> device in the attached patch based on an entry in the NetBSD usbdevs >> file. (The entry makes sense to me as well, since I have one of those.) >> >> So I have two questions ... for the devices (and vendors) that are >> already in my local usbdevs file, why are they still showing up by ID? >> And how do I find the device IDs for the two unknown devices? I >> imagine that the O2 device is related to my built in smart card >> reader, not sure about the other one. >> > > Hi Doug, > > I had the same problem with my Dell Inspiron 9400 and fixed it using the > following patch: > > Index: sys/kern/subr_rman.c > =================================================================== > RCS file: /home/FreeBSD/ncvs/src/sys/kern/subr_rman.c,v > retrieving revision 1.53 > diff -u -r1.53 subr_rman.c > --- sys/kern/subr_rman.c 11 Sep 2006 19:31:52 -0000 1.53 > +++ sys/kern/subr_rman.c 2 Nov 2006 03:05:34 -0000 > _at__at_ -170,7 +170,7 _at__at_ > > /* Skip entries before us. */ > for (s = TAILQ_FIRST(&rm->rm_list); > - s && s->r_end + 1 < r->r_start; > + s && s->r_end < r->r_start; > s = TAILQ_NEXT(s, r_link)) > ; > > This code was added in revision 1.53 when support for intelligent > merging was added. When r_end is equal to UINT_MAX, adding one will > cause it to overflow, creating quite a mess in the entries ordering. I'm > not sure the fix I did is completely correct as I didn't had time to > check if the +1 is needed at all in this case. At least it fixed the > problem for me. Works for me too. I've attached what dmesg for EHCI and 'usbdevs -v' look like after applying this patch. Still interested in the unknown devices though, if anyone has insight into that issue. Doug -- This .signature sanitized for your protection ehci0: <Intel 82801GB/R (ICH7) USB 2.0 controller> mem 0xffa80000-0xffa803ff irq 20 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: <Intel 82801GB/R (ICH7) USB 2.0 controller> on ehci0 uhub4: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb4 Controller /dev/usb0: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 1.00 port 1 powered port 2 powered Controller /dev/usb1: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 1.00 port 1 powered port 2 powered Controller /dev/usb2: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 1.00 port 1 powered port 2 powered Controller /dev/usb3: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 1.00 port 1 powered port 2 powered Controller /dev/usb4: addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), Intel(0x0000), rev 1.00 port 1 powered port 2 addr 2: high speed, self powered, config 1, product 0xa005(0xa005), vendor 0x413c(0x413c), rev 50.18 port 1 powered port 2 powered port 3 addr 3: full speed, power 200 mA, config 1, product 0x7761(0x7761), vendor 0x0b97(0x0b97), rev 1.10 port 1 addr 4: full speed, power 100 mA, config 1, Biometric Coprocessor(0x2016), STMicroelectronics(0x0483), rev 0.01 port 2 addr 5: full speed, self powered, config 1, O2Micro CCID SC Reader(0x7762), O2(0x0b97), rev 1.10 port 3 powered port 4 addr 6: full speed, self powered, config 1, product 0x8103(0x8103), vendor 0x413c(0x413c), rev 24.22 port 3 powered port 4 powered port 5 powered port 6 powered port 7 powered port 8 addr 7: high speed, self powered, config 1, product 0x0058(0x0058), vendor 0x413c(0x413c), rev 0.00 port 1 addr 8: high speed, self powered, config 1, USB2.0 Hub Controller(0x0058), NEC Corporation(0x0409), rev 1.00 port 1 powered port 2 powered port 3 powered port 4 powered port 2 powered port 3 addr 9: low speed, power 100 mA, config 1, Trackball(0xc404), Logitech(0x046d), rev 2.20 port 4 poweredReceived on Wed Nov 22 2006 - 23:54:05 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:03 UTC