Re: uhci-hcd oops with 2.4.27/ intel D845GLVA

[Pete Zaitcev]

On Tue, 10 Aug 2004 14:10:42 -0300
Marcelo Tosatti <marcelo.tosatti@xxxxxxxxxxxx> wrote:

> And I'm unable to find the message you are responding to, 
> can you please forward me it?

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=2rhs2-6H8-11%40gated-at.bofh.it

The "uhci-hcd in 2.4.27" was launched by Nick, Kai simply reused that
header. I should note when I saw "uhci-hcd" I automatically ignored it,
because there's no uhci-hcd in 2.4.

> ehci_hcd 00:1d.7:  Bios handoff failed (104, 1010001)
> unable to handle kernel NULL pointer dereference at virtual address 00000048

This is a clue. I know that EHCI goes belly up if it fails to execute
the handoff.

The attached ought to fix Nick up (no way to tell about Kai because his
report had no data). It consists of two things. First, it fixes the
oops in the scan_async. Second, it prevents the oops from happening by
ignoring the handoff failure (as the old code did, in effect). Either
one should be sufficient, but this is why I use both. The if around
scan_async is the right fix, so it's there on merit. However, it yields
a non-working EHCI if your BIOS is buggy.

I know that David Brownlee disagrees with writing zero into the
configuration space, but it looks safer to me, because old code
did write that zero.

-- Pete

--- linux-2.4.27/drivers/usb/host/ehci-hcd.c	2004-08-10 13:43:36.691040600 -0700
+++ linux-2.4.21-17.EL-usb1/drivers/usb/host/ehci-hcd.c	2004-07-30 16:21:12.000000000 -0700
@@ -303,7 +302,8 @@
 		if (cap & (1 << 16)) {
 			ehci_err (ehci, "BIOS handoff failed (%d, %04x)\n",
 				where, cap);
-			return 1;
+			pci_write_config_dword (ehci->hcd.pdev, where, 0);
+			return 0;
 		} 
 		ehci_dbg (ehci, "BIOS handoff succeeded\n");
 	}
@@ -547,7 +547,8 @@
 
 	/* root hub is shut down separately (first, when possible) */
 	spin_lock_irq (&ehci->lock);
-	ehci_work (ehci, NULL);
+	if (ehci->async)
+		ehci_work (ehci, NULL);
 	spin_unlock_irq (&ehci->lock);
 	ehci_mem_cleanup (ehci);
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/