Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 1 Dec 2006 12:25:02 -0500
From:      John Baldwin <jhb@freebsd.org>
To:        "Stephane E. Potvin" <sepotvin@videotron.ca>
Cc:        freebsd-current@freebsd.org, Doug Barton <dougb@freebsd.org>
Subject:   Re: EHCI problem on -current, and unknown devs
Message-ID:  <200612011225.02780.jhb@freebsd.org>
In-Reply-To: <456FA276.6050706@videotron.ca>
References:  <4564996D.50808@FreeBSD.org> <200611301443.31419.jhb@freebsd.org> <456FA276.6050706@videotron.ca>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 30 November 2006 22:33, Stephane E. Potvin wrote:
> John Baldwin wrote:
> > On Wednesday 29 November 2006 17:39, Stephane E. Potvin wrote:
> >> John Baldwin wrote:
> >>> On Thursday 16 November 2006 03:34, 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
> >>>> @@ -170,7 +170,7 @@
> >>>>
> >>>>          /* 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.
> >>> It is needed to avoid overlaps.  Can you show me which 
> > rman_manage_region() is 
> >>> breaking?  Rather, enable the DPRINTF() in rman_manage_region() and 
> > provide 
> >>> the output?
> >>>
> >> Here's the output of booting an unmodified kernel with debug.rman_debug=1
> > 
> > Try this:
> > 
> 
> I had to modify the patch a little to make it compile:
> 
> When I try to boot after patching nearly all the drivers fail to 
> allocate their resources, making the laptop unable to mount root as the 
> ata driver failed to attach. I can't provide any log yet as I don't have 
> a serial port on the laptop to grab the output.

Sign bug on my part.  try this:

Index: subr_rman.c
===================================================================
RCS file: /usr/cvs/src/sys/kern/subr_rman.c,v
retrieving revision 1.53
diff -u -r1.53 subr_rman.c
--- subr_rman.c 11 Sep 2006 19:31:52 -0000      1.53
+++ subr_rman.c 1 Dec 2006 17:22:25 -0000
@@ -61,6 +61,7 @@
 #include <sys/param.h>
 #include <sys/systm.h>
 #include <sys/kernel.h>
+#include <sys/limits.h>
 #include <sys/lock.h>
 #include <sys/malloc.h>
 #include <sys/mutex.h>
@@ -169,10 +170,12 @@
        mtx_lock(rm->rm_mtx);

        /* Skip entries before us. */
-       for (s = TAILQ_FIRST(&rm->rm_list);
-            s && s->r_end + 1 < r->r_start;
-            s = TAILQ_NEXT(s, r_link))
-               ;
+       TAILQ_FOREACH(s, &rm->rm_link, r_link) {
+               if (s->r_end == ULONG_MAX)
+                       break;
+               if (s->r_end + 1 >= r->r_start)
+                       break;
+       }

        /* If we ran off the end of the list, insert at the tail. */
        if (s == NULL) {

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200612011225.02780.jhb>