Skip to contentSkip to conversation

uhci-hcd oops with 2.4.27/ intel D845GLVA

DISCUSSION Kai Militzer 5 participants 8 messages Aug 10, 2004 – Aug 11, 2004 1 message not in the archive

Subsystems (2)
USB USB ehci driver
lore
Share & tools
lore

Kai Militzer

author
#0 lore raw

Hello everyone!

Quoted 3 lines

I unable to boot due to a kernel oops on my D845GLVA. This worked fine in 2.4.26, but with the same (well, except for the new features) config 2.4.27 does not.

I've got the same problem here. Did an make oldconfig from a 2.4.26 config, booted and the systems made an oops.

Problem is, that the system is production and I can't test, where the problem is in special. We had two reboots already and even that is nearly too much.

Best regards

Kai

Signature · 4 lines
Kai Militzer                 WESTEND GmbH  |  Internet-Business-Provider
Technik                      CISCO Systems Partner - Authorized Reseller
                             Lütticher Straße 10      Tel 0241/701333-11
[email protected]               D-52064 Aachen              Fax 0241/911879
#1 lore raw
Quoted 6 lines · Kai Militzer

Hello everyone!

Quoted 3 lines

I unable to boot due to a kernel oops on my D845GLVA. This worked fine in 2.4.26, but with the same (well, except for the new features) config 2.4.27 does not.

Quoted 6 lines

I've got the same problem here. Did an make oldconfig from a 2.4.26 config, booted and the systems made an oops.

Problem is, that the system is production and I can't test, where the problem is in special. We had two reboots already and even that is nearly too much.

Kai,

Can you please post the oops message?

Thats the only way we can try fix it.

#2 lore raw
Quoted 14 lines · Marcelo Tosatti
Quoted 6 lines · Kai Militzer

Hello everyone!

Quoted 3 lines

I unable to boot due to a kernel oops on my D845GLVA. This worked fine in 2.4.26, but with the same (well, except for the new features) config 2.4.27 does not.

Quoted 6 lines

I've got the same problem here. Did an make oldconfig from a 2.4.26 config, booted and the systems made an oops.

Problem is, that the system is production and I can't test, where the problem is in special. We had two reboots already and even that is nearly too much.

Quoted 5 lines

Kai,

Can you please post the oops message?

Thats the only way we can try fix it.

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

#4 lore raw
Quoted 2 lines · On Tue, 10 Aug 2004 14:10:42 -0300 Marcelo Tosatti…

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.

Quoted 2 lines

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

drivers/usb/host/ehci-hcd.c +4 -2
@@ -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);
#5 lore raw
Quoted 4 lines · Pete Zaitcev

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.

That's a NOP, ehci->async must never be null.

What oops? The original post didn't include a stack...

Quoted 4 lines

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.

Erm, no that's a NOP.

Quoted 2 lines

However, it yields
a non-working EHCI if your BIOS is buggy.

Depends on the particular bug you're hypothesizing is in the BIOS ... the original bug was fixed by Dell's patch on at least two different motherboards. So you seem to want a slightly different BIOS bug to be worked around ...

Quoted 3 lines

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.

Dave who? :)

Actually, I don't recall anyone providing a patch that addressing that second type of BIOS bug before. Makes sense to me to fall back to that old Linux bug; why not!

- Dave

Quoted 4 lines

-- Pete

--- linux-2.4.27/drivers/usb/host/ehci-hcd.c 2004-08-10 13:43:36.691040600

-0700

Quoted 1 line

+++ linux-2.4.21-17.EL-usb1/drivers/usb/host/ehci-hcd.c 2004-07-30

16:21:12.000000000 -0700

Quoted 21 lines
drivers/usb/host/ehci-hcd.c +4 -2
@@ -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);
#6 lore raw
Quoted 3 lines · On Tue, 10 Aug 2004 21:37:26 -0700 David Brownell <[email protected]> wrote:
Quoted 1 line

First, it fixes the oops in the scan_async.

That's a NOP, ehci->async must never be null.

This is news. I received this patch FROM YOU. And I shipped it with RHEL3 U3. And now it's a nop? What gives?! By the way, it's verified to fix the oops when handoff fails.

Quoted 9 lines

drivers/usb/host/ehci-hcd.c line 552

Quoted 9 lines

+++ linux-2.4.21-17.EL-usb1/drivers/usb/host/ehci-hcd.c 2004-07-30 16:21:12.000000000 -0700

drivers/usb/host/ehci-hcd.c +2 -1
@@ -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);

Please look at this:
http://www.ussg.iu.edu/hypermail/linux/kernel/0404.2/0156.html

-- Pete

P.S. Sorry to get your name wrong, David.

#7 lore raw
Quoted 10 lines · Pete Zaitcev
Quoted 3 lines · On Tue, 10 Aug 2004 21:37:26 -0700 David Brownell <[email protected]> wrote:
Quoted 1 line

First, it fixes the oops in the scan_async.

That's a NOP, ehci->async must never be null.

This is news. I received this patch FROM YOU. And I shipped it with RHEL3 U3. And now it's a nop? What gives?! By the way, it's verified to fix the oops when handoff fails.

I see what was going on -- that patch somehow got lost. It normally never IS null, except on an exotic fault path during initialization. Which of course nobody ever sees ... right :)

- Dave

Quoted 1 line
Quoted 1 line
Quoted 1 line

+++ linux-2.4.21-17.EL-usb1/drivers/usb/host/ehci-hcd.c 2004-07-30

16:21:12.000000000 -0700

Quoted 16 lines
Quoted 8 lines

drivers/usb/host/ehci-hcd.c line 552

Quoted 8 lines
drivers/usb/host/ehci-hcd.c +2 -1
@@ -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);

Please look at this:
http://www.ussg.iu.edu/hypermail/linux/kernel/0404.2/0156.html

-- Pete

P.S. Sorry to get your name wrong, David.

#8 lore raw
In reply to Pete Zaitcev
Quoted 4 lines

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.

sorry about the incorrect subject, I was in a hurry to get to work...

In any event now the kernel will boot fine. I haven't really tested the usb, but of course the really important thing is that the kernel doesn't crash :)