Bug 104817 - Machine hangs during boot after ide0 is detected
Summary: Machine hangs during boot after ide0 is detected
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux Beta
Classification: Retired
Component: kernel
Version: beta1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks: CambridgeBlocker
TreeView+ depends on / blocked
 
Reported: 2003-09-22 15:44 UTC by Tom Diehl
Modified: 2015-01-04 22:03 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-11-25 07:25:23 UTC
Embargoed:


Attachments (Terms of Use)
dmesg from normal boot (8.99 KB, text/plain)
2003-09-22 15:50 UTC, Tom Diehl
no flags Details

Description Tom Diehl 2003-09-22 15:44:58 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703

Description of problem:
At boot time the machine hangs. The last message I see on the machine is ide0 at
0x1f0-0x1f7,0x3f6 on irq 14. If I switch to kernel-2.4.21-20.1.2024.2.1.nptl the
machine comes up and plays. I tried acpi=off but no change. This is a 1.2 gig
athlon with 512 megs of memory.

Let me know what other info you need to troubleshoot this.

Version-Release number of selected component (if applicable):
kernel-2.4.22-1.2051.nptl

How reproducible:
Always

Steps to Reproduce:
1. boot the machine with the 2.4.22-1.2051.nptl kernel

    

Actual Results:  hangs after the message: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14

Expected Results:  normal boot up

Additional info:

lspci follows:
(tigger pts2) # lspci
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
00:07.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 06)
00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 16)
00:07.3 USB Controller: VIA Technologies, Inc. USB (rev 16)
00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
00:0d.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 30)
00:13.0 Unknown mass storage controller: Triones Technologies, Inc.
HPT366/368/370/370A/372 (rev 04)
01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 PF/PRO AGP 4x TMDS
(tigger pts2) #

Comment 1 Tom Diehl 2003-09-22 15:50:24 UTC
Created attachment 94629 [details]
dmesg from normal boot

This is from a normal boot.

Comment 2 Dave Jones 2003-09-22 16:14:34 UTC
Try booting with acpi=on. Behaviour changed, so it's no longer turned on by
default.  If this works, can you attach the output of dmidecode so we can add it
to the list to 'automatically turn on' ?


Comment 3 Tom Diehl 2003-09-22 17:38:00 UTC
Booted with acpi=on. Still hangs. the only difference is it stops at this line:
hdh: CD-916E/ATK, ATAPI CD/DVD-ROM drive
instead of the line listed in the original report.

Do you still want dmidecode??

Comment 4 Dave Jones 2003-09-22 21:03:04 UTC
try acpi=on pci=noacpi


Comment 5 Tom Diehl 2003-09-22 22:55:32 UTC
Still no joy. Exactly the same results as with acpi=on.

Comment 6 Tom Diehl 2003-09-24 20:14:57 UTC
Tried 2.4.22-1.2061.nptl with acpi=on and acpi=on pci=noacpi. No change, it
still hangs. Any other suggestions or am I hosed??

Comment 7 Michael K. Johnson 2003-10-22 15:32:14 UTC
From: Alexander Viro <aviro>

On the off-chance that it's the same issue with IRQ...  Replace
                desc->status &= ~(IRQ_DISABLED | IRQ_AUTODETECT | IRQ_WAITING);
with
                desc->status &= ~(IRQ_DISABLED | IRQ_AUTODETECT |
                                  IRQ_WAITING | IRQ_INPROGRESS);
in setup_irq() and see if it helps.
                                                                                
2.4 used to get very upset if we got an irq at the time when it was
enabled but had no handler registered and IDE code has a wide window
where that is true.  If irq happened in that interval, it got stuck
forever, which hung the box as soon as we tried to do anything.
                                                                                
Note that minor changes in other places might have affected the timings
getting the irq hit us in critical interval.  Fix (along the lines of
suggested above) went into Marcelo's tree recently.  The bug used to hit
us on at least two models (both Alpha-based - DS10 and Miata, but a lot
of other platforms have the same issue), so it's not a pure theory.


Comment 8 Tom Diehl 2003-10-23 02:58:23 UTC
Is there something a Non-programmer can test??

Comment 9 Michael K. Johnson 2003-10-23 13:10:28 UTC
Yes, apparantly the most recent rawhide kernels have this change in them
already, so grab the latest kernel from rawhide and test.

Thanks!

Comment 10 Tom Diehl 2003-10-27 05:00:07 UTC
Tried the 2108 kernel with acpi=on, acpi=on pci=noacpi and with acpi off and no
joy. It hangs at exactly the same place. Any other ideas?? Is there some more
info I can provide that would help figure this out??

Comment 11 Michael K. Johnson 2003-10-27 16:05:26 UTC
It would be really great if we could find one (or better yet, more than
one) other piece of hardware that is exhibiting the same symptoms so that
we could start looking for commonality between them to pinpoint the problem.


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