Bug 36644 - (BIOS ?)installer hangs on laptop CD-ROM spindown
(BIOS ?)installer hangs on laptop CD-ROM spindown
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.2
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-04-19 09:36 EDT by Russ Wright
Modified: 2008-08-01 12:22 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:38:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Russ Wright 2001-04-19 09:36:58 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)


When attempting to install RH 7.1 on a Toshiba 1605 CDS laptop installer 
hangs when the CD-ROM does a spin down

Reproducible: Always
Steps to Reproduce:
1.Start installer on the Laptop by booting from CD #1 
2.Can choose text or graphical doesn't matter
2.Wait a few moments for the CD-ROM to Spin down
3.System Locks
	

Actual Results:  Well, the first time it wiped out my laptop hardrive. 
(very bad) Every time after that it leaves my laptop in an unusable 
state.  Upon reboot I get Kernel Panic messages and must reload RH 7.0

Expected Results:  The system should install, and as in the RH 7.0 install 
the CD-ROM will spin-up after I hit the next button.

There is a message I can sometimes catch while the installer is loading 
something like: No IRQ known for interrupt pin A of device 01:00.0. Please 
try using pci=biosirq.

I went to the Kernel archives and did a search on "pci=biosirq" and found 
this message from Linus about a similar topic thought it might be useful.

Regards
Russ

-------
PCI irq routing..
From: Linus Torvalds (torvalds@transmeta.com)
Date: Tue Dec 05 2000 - 18:04:24 EST 

Ok, I now have two confirmations from independent people (Adam Richter and 
Kai Germaschewski) who have completely different hardware, but have the 
same problem: irq routing seems to not work for them. 


In both cases it is because the PCI device config space already has an 
entry for the interrupt, but the interrupt is apparently not actually 
routed on the irq router. 


WHY this happens is unclear, but it could be several reasons: 
 - undocumented "Plug'n'Play OS true behaviour" 
 - BIOS bugs. 'nuff said. 
 - warm-booting from an OS that _does_ set the interrupt routing, 
   and also sets the PCI config space thing 


The problem can be fairly easily fixed by just removing the test for 
whether "pci->dev" has already got set. This, btw, is important for 
another reason too - there is nothing that says that a sleep event 
wouldn't turn off the irq routing, so we _have_ to have some way of 
forcing the interrupt routing to take effect even if we already think we 
have the correct irq. 


However, Martin is certainly also right in claiming that there might be 
bugs the "other" way, and just completely dismissing the irq we already 
are claimed to have would be bad. 


This is my current suggested patch for the problem. 

Adam, Kai, can you verify that it fixes the issues on your systems? 

Anybody else who has had problems with PCI interrupt routing (tends to 
be "new" devices like CardBus, ACPI, USB etc), can you verify that this 
either fixes things or at least doesn't break a setup that had started 
working earlier.. 


Martin, what do you think? We definitely need something like this, but 
maybe we could add a few more sanity-tests? 


                        Linus 



----
--- v2.4.0-test11/linux/arch/i386/kernel/pci-irq.c	Sun Nov 19 
18:44:03 2000
+++ linux/arch/i386/kernel/pci-irq.c	Tue Dec  5 14:38:13 2000
@@ -405,9 +424,12 @@
 	DBG(" -> PIRQ %02x, mask %04x, excl %04x", pirq, mask, pirq_table-
>exclusive_irqs);
 	mask &= pcibios_irq_mask;
 
-	/* Find the best IRQ to assign */
-	newirq = 0;
-	if (assign) {
+	/*
+	 * Find the best IRQ to assign: use the one
+	 * reported by the device if possible.
+	 */
+	newirq = dev->irq;
+	if (!newirq && assign) {
 		for (i = 0; i < 16; i++) {
 			if (!(mask & (1 << i)))
 				continue;
@@ -417,16 +439,22 @@
 				newirq = i;
 			}
 		}
-		DBG(" -> newirq=%d", newirq);
 	}
+	DBG(" -> newirq=%d", newirq);
 
 	/* Try to get current IRQ */
 	if (r->get && (irq = r->get(pirq_router_dev, d, pirq))) {
 		DBG(" -> got IRQ %d\n", irq);
 		msg = "Found";
+		/* We refuse to override the dev->irq information. Give a 
warning! */
+	    	if (dev->irq && dev->irq != irq) {
+	    		printk("IRQ routing conflict in pirq table! 
Try 'pci=autoirq'\n");
+	    		return 0;
+	    	}
 	} else if (newirq && r->set && (dev->class >> 8) != 
PCI_CLASS_DISPLAY_VGA) {
 		DBG(" -> assigning IRQ %d", newirq);
 		if (r->set(pirq_router_dev, d, pirq, newirq)) {
+			eisa_set_level_irq(newirq);
 			DBG(" ... OK\n");
 			msg = "Assigned";
 			irq = newirq;
@@ -556,19 +584,17 @@
 
 void pcibios_enable_irq(struct pci_dev *dev)
 {
-	if (!dev->irq) {
-		u8 pin;
-		pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin);
-		if (pin && !pcibios_lookup_irq(dev, 1)) {
-			char *msg;
-			if (io_apic_assign_pci_irqs)
-				msg = " Probably buggy MP table.";
-			else if (pci_probe & PCI_BIOS_IRQ_SCAN)
-				msg = "";
-			else
-				msg = " Please try using pci=biosirq.";
-			printk(KERN_WARNING "PCI: No IRQ known for 
interrupt pin %c of device %s.%s\n",
-			       'A' + pin - 1, dev->slot_name, msg);
-		}
+	u8 pin;
+	pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin);
+	if (pin && !pcibios_lookup_irq(dev, 1) && !dev->irq) {
+		char *msg;
+		if (io_apic_assign_pci_irqs)
+			msg = " Probably buggy MP table.";
+		else if (pci_probe & PCI_BIOS_IRQ_SCAN)
+			msg = "";
+		else
+			msg = " Please try using pci=biosirq.";
+		printk(KERN_WARNING "PCI: No IRQ known for interrupt pin %
c of device %s.%s\n",
+		       'A' + pin - 1, dev->slot_name, msg);
 	}
 }
-
Comment 1 Brent Fox 2001-04-19 16:47:03 EDT
This sounds like a kernel problem.  Changing component.
Comment 2 Arjan van de Ven 2001-04-20 16:18:28 EDT
Could you please try adding "ide=nodma" to the initial prompt of the installer
(the very first one)?
Comment 3 Russ Wright 2001-04-21 22:43:53 EDT
OK I tried it.  Perhaps I am doing something wrong?
1. Booted from the CD-ROM 
2 at the prompt -> boot: ide=nodma
3. Got the message " Could not find kernel image: ide=nodm.a"
Russ
Comment 4 Arjan van de Ven 2001-04-22 04:45:05 EDT
I'm sorry I was unclear. That should be 
"linux ide=nodma" or "text ide=nodma"
Comment 5 Russ Wright 2001-04-22 08:49:18 EDT
I tried the option as follows:
1.boot:Linux ide=nodma
2.I chose Laptop install and accepted the defaults except video which I 
selected 4MB of RAM. and I configured X with a generic LCD panel 800X600 16 bit 
color.
3. The installer got pretty far then it stuck on XFree86-4.0.3-5 which was 
package 280 of 472
4. As best I can tell the installer hung when the cpu fan kicked in... not sure 
though.

I'm looking at the laptop right now and the hard drive access light is on 
solid, the fan won't shut off and the screen is frozen.  I let it sit for at 
least 10 minutes to make sure it was really frozen.

I attempted to switch screens (CTRL-ALT-F1 etc), force a reboot (CTRL-ALT-DEL) 
and none of that worked.

I finally powered off by holding down the power button to force power off.

ATTEMPT 2
I powered back up and I tried again using -> boot:text ide=nodma
Although the hard drive is now a mess and is only a partial install and I don't 
expect success. (perhaps this is a different issue when RH 7.1 won't install 
after a failed install?)

I only got to the "Welcome to Red Hat Linux!" screen and it locked solid.

ATTEMPT 3
I tried again using -> boot:text ide=nodma,pci=biosirq
(I think the second option really did nothing)
I carefully watched the activity of the laptop.  It seems that the lockup 
happens on about the second or third screen after anaconda loads and seems 
associated with the cd-rom spinning down a couple of times.  If I work fast and 
keep the cd-rom spinning I can get further in the install.

I'll reload RH 7.0 and leave the machine pristine until I hear from you.

Regards
Russ

Comment 6 Russ Wright 2001-04-22 22:23:44 EDT
OK I tried again. I got further and made a discovery.  Even with the ide=nodma 
option I can now say without a doubt that the install locks up when the CPU fan 
kicks on
Steps to recreate
1. Boot from the CD
2. Enter the option ->boot:Linux ide=nodma
3. accept default laptop install and let it run.
4. When the cpu fan kicks on the system locks.

I tried it twice several hours apart and as soon as the fan kicked in it froze.



Comment 7 Arjan van de Ven 2001-04-23 09:03:11 EDT
To get things clear: the very first time the fan kicks in it freezes ?
Comment 8 Russ Wright 2001-04-23 09:17:09 EDT
You are correct.  The first time the fan kicks in the installation freezes.
Comment 9 Russ Wright 2001-04-30 12:18:57 EDT
Folks,

I tried the process again and yes even with the boot:Linux ide=nodma option as 
soon as the cooling fan kicks for the first time the installation freezes.  I 
can reproduce the problem every time.  I was thinking of trying a custom boot 
disk and use the "fan" tool to force my fan to be always on during the 
install.  I don't know if that will work though.

Russ
Comment 10 Russ Wright 2001-07-20 15:40:48 EDT
Ladies and Gents

I've not heard anything on this issue and I cannot get past this bug to install 
RH 7.1.  Have you found a solution?

Regards
Russ
Comment 11 Andrew J. Gristina 2001-10-09 20:44:23 EDT
It is reproduceable on my Toshiba 1625CDT as well (at two or three bios 
versions of the Toshiba I tried the latest and the one from 2/2000 because I 
thought it was bios related. 

I tried the nodma, because that was what I initially thought it was. I thought 
rwrigh10 was crazy to suggest the processor fan.   Because mine never hung 
during lilo, anaconda, or xconfig, it always hung during RPM copy.  But now 
I've tested it and it will hang immediately when the fan starts on the cpu (all 
you have to do is wait at a stage until it the fan starts).

-Andrew

PS.  I'm going to try to install this evening outside when it is cold and 
upgrade the kernel to see if it goes away.

-Andrew G.
Comment 12 Russ Wright 2001-10-09 21:29:24 EDT
Andrew

Thanks for confirming that I am not insane.. well at least on this issue.  I 
have found a work around. This may not be the only solution but it works.  I 
downloaded a copy of Mandrake 8.1 linux and it installs flawlessly.  I would 
LOVE to install RH but it just will not work.

Regards
Russ
Comment 13 Andrew J. Gristina 2001-10-10 14:48:02 EDT
Must be the kernel...

RH 7.1 ships with 2.4.2 (?) and Mandrake 8.1 ships with 2.4.8 (?) because it
does look like a kernel lock.

I will try the kernel upgrade, or perhaps wait for RH 7.2 (should be out any
minute and have a more current kernel).

Thanks for the work around Russ.

-Andrew G.
Comment 14 Andrew J. Gristina 2001-10-24 13:22:28 EDT
Still b0rked on RedHat 7.2.  The only reliable way to get redhat on this laptop
is to use a 2.2.x kernel.   Should I submit a bug for RedHat 7.2 for install on
Toshiba 16XX series or not?

It looks like it should be fixed in 2.4.8 or later, but I haven't compiled
kernel from scratch on 7.0 yet. I will try that next.

-Andrew Gristina
Comment 15 Bugzilla owner 2004-09-30 11:38:57 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

Note You need to log in before you can comment on or make changes to this bug.