Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 11 Jun 2007 09:20:01 +0200
From:      Hans Petter Selasky <hselasky@c2i.net>
To:        Julian Elischer <julian@elischer.org>
Cc:        freebsd-usb@freebsd.org
Subject:   Re: 31st address line sometimes not used on EHCI/UHCI/OHCI
Message-ID:  <200706110920.01234.hselasky@c2i.net>
In-Reply-To: <465A8BF0.6050808@elischer.org>
References:  <200705272235.46048.hselasky@c2i.net> <20070528075022.GZ4602@funkthat.com> <465A8BF0.6050808@elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 28 May 2007 09:59, Julian Elischer wrote:
> John-Mark Gurney wrote:
> > Hans Petter Selasky wrote this message on Mon, May 28, 2007 at 08:53 
+0200:
> >> On Sunday 27 May 2007 23:53, John-Mark Gurney wrote:
> >>> Hans Petter Selasky wrote this message on Sun, May 27, 2007 at 22:35 
+0200:
> >>>> I've got some reports back that some USB host controllers do not
> >>>> support transferring memory from a location higher than 2GB.
> >>>>
> >>>> What should we do about this?
> >>>>
> >>>> Should we limit all USB DMA allocations to the lower 2GB of the
> >>>> memory?
> >>>
> >>> No, a quirk table should be setup and pass the restriction to bus_dma
> >>> at tag initalization time when a broken controller is detected..
> >>
> >> Yes, I can do that. But I am also thinking about a static quirk, like a
> >> sysctl you can set at boot time.
> >
> > The only issue w/ this is that it would also effect add in USB PCI cards
> > that aren't effected by the bug...  Which means a sysctl would limit the
> > hardware to the lowest common denominator...
> >
> >> I hope that this is not a wide-spread problem.
> >>
> >> And I am not surprised that hardware manufacturers are not specification
> >> compliant, which really makes me wonder if they support a true 64-bit
> >> address bus on the EHCI controller at all. I would maybe cost too much
> >> money? And therefore we should just stick with 32-bit addressing on
> >> 32-bit platforms aswell.
> >
> > Don't forget we have PAE for i386...  so restricting to 32bit addressing
> > for i386 would have an impact...
> >
> > As for it being an intermediate bus being the issue, I'd be surprised
> > as that would mean that pci bridge to the USB controller is seriously
> > broken...  At least dealing w/ a intermediate bus is easier now that
> > was have bus_get_dma_tag...
>
> I'd rather it were a screwed up MB than a screwed up chip :-)


Ok. Here are the PCI ID's:

ohci0@pci0:11:0:        class=0x0c0310 card=0x818a1043 chip=0x003b10de 
rev=0xa1 hdr=0x00
    vendor     = 'NVIDIA Corporation'
    device     = 'MCP04 USB Controller'
    class      = serial bus
    subclass   = USB
ohci1@pci0:11:1:        class=0x0c0310 card=0x818a1043 chip=0x003b10de 
rev=0xa1 hdr=0x00
    vendor     = 'NVIDIA Corporation'
    device     = 'MCP04 USB Controller'
    class      = serial bus
    subclass   = USB
ehci0@pci0:11:2:        class=0x0c0320 card=0x818a1043 chip=0x003c10de 
rev=0xa2 hdr=0x00
    vendor     = 'NVIDIA Corporation'
    device     = 'MCP04 USB Controller'
    class      = serial bus
    subclass   = USB
ohci2@pci2:7:0: class=0x0c0310 card=0x00351033 chip=0x00351033 rev=0x41 
hdr=0x00
    vendor     = 'NEC Electronics Hong Kong'
    device     = 'uPD9210FGC-7EA / <B5>PD720101 USB 1.0 Host Controller (OHCI 
compliant)'
    class      = serial bus
    subclass   = USB
ohci3@pci2:7:1: class=0x0c0310 card=0x00351033 chip=0x00351033 rev=0x41 
hdr=0x00
    vendor     = 'NEC Electronics Hong Kong'
    device     = 'uPD9210FGC-7EA / <B5>PD720101 USB 1.0 Host Controller (OHCI 
compliant)'
    class      = serial bus
    subclass   = USB
ehci1@pci2:7:2: class=0x0c0320 card=0x29280e55 chip=0x00e01033 rev=0x02 
hdr=0x00
    vendor     = 'NEC Electronics Hong Kong'
    device     = 'uPD720100A/101 USB 2.0 Enhanced Host Controller'
    class      = serial bus
    subclass   = USB

Can anyone find out if the USB hardware or the mainboard is not supporting 32 
address lines from the text above?

--HPS



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