On Friday 04 February 2005 9:35 pm, Robert Hancock wrote:
> I've got an Asus A8N-SLI Deluxe motherboard (NVIDIA nForce4 chipset)
> running Fedora Core 3 x86_64. Using the 2.6.9 kernel, the USB 2.0
> devices I have (USB flash card reader and USB pen drive) are detected
> and work fine at USB 2.0 speed. However, in 2.6.10, any USB 2.0 devices
> are not detected at all. If I then rmmod ehci-hcd, they are detected but
> of course only work at USB 1.1 speeds.
>
> Is this something new, or a known problem?
New, and it looks to be an NF4 chipset level issue. You might ask ASUS
what's up with it; that's a new board (got an extra one for me? :), and
this could be something that's fixable with a BIOS update. They'll have
more access to the NVidia errata than either of us, regardless!
> ehci_hcd: block sizes: qh 160 qtd 96 itd 192 sitd 96
> ACPI: PCI Interrupt Link [APCL] enabled at IRQ 20
> ACPI: PCI interrupt 0000:00:02.1[B] -> GSI 20 (level, low) -> IRQ 209
> ehci_hcd 0000:00:02.1: EHCI Host Controller
> ehci_hcd 0000:00:02.1: reset hcs_params 0x10148a dbg=1 cc=1 pcc=4 !ppc
> ports=10
> ehci_hcd 0000:00:02.1: reset portroute 0 0 0 0 0 0 0 0 0 0
OK that's the problem.
This should either be cc=3 (with EHCI at 02:3 and two more OHCIs)
or pcc=10 (or maybe cc=2 pcc=5, etc) ... and in your case it looks
like the issue is that pcc=4 is wrong. NF2 and NF3 were cc=2 pcc=3,
so I'm not sure how NVidia created that particular bug.
> ...
> usb usb1: Product: EHCI Host Controller
> usb usb1: Manufacturer: Linux 2.6.10-1.760_FC3custom ehci_hcd
> usb usb1: SerialNumber: 0000:00:02.1
> usb usb1: hotplug
> usb usb1: adding 1-0:1.0 (config #1, interface 0)
> usb 1-0:1.0: hotplug
> hub 1-0:1.0: usb_probe_interface
> hub 1-0:1.0: usb_probe_interface - got id
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 4 ports detected
This is the behavior that changed. As a workaround for a
different chip, 2.6.10 does the math: CC * PCC < PORTS
indicates the controller is confused.
For that chip (a GeneSys GL880S), CC and PCC are right,
so the workaround adjusts PORTS. But for your NF4, it's
a different bitfield that's wrong, and that workaround
is counterproductive.
This patch should resolve the issue for you.
- Dave
Turns out that a workaround for a different EHCI chip trips up at
least one NForce4 board. Neither controller can multiply right.
--- 1.115/drivers/usb/host/ehci-hcd.c 2005-01-12 19:31:18 -08:00
+++ edited/drivers/usb/host/ehci-hcd.c 2005-02-05 11:12:57 -08:00
@@ -421,8 +421,29 @@
temp = HCS_N_CC(ehci->hcs_params) * HCS_N_PCC(ehci->hcs_params);
temp &= 0x0f;
if (temp && HCS_N_PORTS(ehci->hcs_params) > temp) {
- temp |= (ehci->hcs_params & ~0xf);
- ehci->hcs_params = temp;
+ ehci_dbg (ehci, "bogus port configuration: "
+ "cc=%d * pcc=%d < ports=%d\n",
+ HCS_N_CC(ehci->hcs_params),
+ HCS_N_PCC(ehci->hcs_params),
+ HCS_N_PORTS(ehci->hcs_params));
+
+#ifdef CONFIG_PCI
+ if (hcd->self.controller->bus == &pci_bus_type) {
+ struct pci_dev *pdev;
+
+ pdev = to_pci_dev(hcd->self.controller);
+ switch (pdev->vendor) {
+ case 0x17a0: /* GENESYS */
+ /* GL880S: should be PORTS=2 */
+ temp |= (ehci->hcs_params & ~0xf);
+ ehci->hcs_params = temp;
+ break;
+ case PCI_VENDOR_ID_NVIDIA:
+ /* NF4: should be PCC=10 */
+ break;
+ }
+ }
+#endif
}
/* force HC to halt state */
