Bug 379201

Summary: Hardware freezes on Dell Optiplex 320 while booting
Product: [Fedora] Fedora Reporter: Jay Turner <jturner>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 8CC: aaron.innes, aneil2, chris.brown, clmoxley, craigwhite, eric.caron, kelsey, linux-bugs, pawsa, srevivo, tomc, z
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-01-09 07:24:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
New output of dmidecode after BIOS update from Dell none

Description Lubomir Kundrak 2007-11-13 00:24:39 UTC
+++ This bug was initially created as a clone of Bug #219715 +++

[...snip...]

-- Additional comment from craigwhite on 2007-11-12 18:32 EST --
Nothing has changed on Fedora 8 - in fact, it's gotten worse.

I could use Fedora 7 x86_64 without any special boot parameters but of course,
grub never worked but lilo has indeed worked. All of my mentions here refer only
to x86_64 as I gave up trying to run i386 on these systems a while back.

Upgraded to Fedora 8 and simply cannot even boot from Rescue disc - it hangs
with an error...

PCI: MSI quirk detected. MSI deactivated
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
ACPI Exception (processor_core-0819): AE_NOT_FOUND, Processor Device is not
present [20070126]
*** last line repeats 2 more times ***
Real Time Clock Driver v1.12ac
Non-volatile memory driver v1.2
Linux apgart interface v0.102
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled

and there it stops...never proceeds.

The only way I've been able to get Fedora 8 Linux Rescue CD or CD Image from
boot.iso to boot is to pass 'acpi=off'

I will attach dmidecode and lspci 

-- Additional comment from craigwhite on 2007-11-12 18:33 EST --
Created an attachment (id=256041)
output of dmidecode on Dell Optiplex 320


-- Additional comment from craigwhite on 2007-11-12 18:34 EST --
Created an attachment (id=256051)
output of lspci -vv from Dell Optiplex 320


-- Additional comment from craigwhite on 2007-11-12 18:40 EST --
I'm gonna vent a bit here...

This isn't getting fixed. See bugzilla 219043 
https://bugzilla.redhat.com/show_bug.cgi?id=219043

This all began on Fedora 5 (Fedora 6 for me) and continued on Fedora 7 and now
has gotten worse in Fedora 8

Grub has NEVER worked on these Dell Optiplexes...as far as I can tell, for
anyone ever. I am using Lilo-22.8

I could get i386 working only if I passed ridiculous kernel parameters such as
pci=nomsi all-generic-ide but until Fedora 8 (2.6.23.1-49.fc8) I didn't have to
sacrifice the unborn on x86_64. Now it requires both Lilo and apci=off

PLEASE - PLEASE - PLEASE do something

Comment 1 Craig White 2007-11-13 00:54:41 UTC
just adding myself to cc

Comment 2 Chuck Ebbert 2007-11-13 19:59:19 UTC
acpi=off is almost never needed. See:

  https://fedoraproject.org/wiki/KernelCommonProblems



Comment 3 Craig White 2007-11-13 21:33:33 UTC
Replying to <a
href="https://bugzilla.redhat.com/show_bug.cgi?id=379201#c2">Comment #2</a>

comments pertain to Fedora 8-x86_64 rescue disk boot

* pci=noacpi
  gets further, but hangs after 'running /sbin/loader' (i.e. mounts /proc, /dev,
 /dev/pts, /sys remounts root filesystem, mounts /tmp, running install...)

* nolapic
  hangs somewhere else in boot process - harder to identify but if pressed, I
will describe

* noapic
  hangs exactly at same place as if I didn't append noapic to kernel parameters

* noapictimer
  hangs exactly the same place as pci=noacpi

* earlyprintk=vga
  hangs exactly the same place as original bug report

* edd=skipmbr
  hangs exactly the same place as original bug report

* edd=off
  hangs exactly the same place as original bug report

* clocksource=acpi_pm nohz=off highres=off
  boots (slow like acpi=off)

* nohz=off highres=off
  hangs same as pci=noacpi

* clocksource=acpi_pm nohz=off
  hangs per my original bug report

* clocksource=acpi_pm highres=off
  boots (slow like acpi=off)

I'm trying to work with you guys - specific needs?

Comment 4 Chuck Ebbert 2007-11-13 21:47:17 UTC
(In reply to comment #3)
> Replying to <a
> href="https://bugzilla.redhat.com/show_bug.cgi?id=379201#c2">Comment #2</a>
> 
> comments pertain to Fedora 8-x86_64 rescue disk boot
> 
> * pci=noacpi
>   gets further, but hangs after 'running /sbin/loader' (i.e. mounts /proc, /dev,
>  /dev/pts, /sys remounts root filesystem, mounts /tmp, running install...)
> 

possibly:
pci=noacpi clocksource=acpi_pm

> * clocksource=acpi_pm highres=off
>  boots (slow like acpi=off)

How slow?


Comment 5 Craig White 2007-11-13 21:58:34 UTC
* pci=noacpi clocksource=acpi_pm

  seems to be the best combination of all

How slow?

  hard to say exactly because I am used to kickstart installs and nor really in
tune with what should be the speed and so it may actually take a long time to
read the rescue loader code off CD (perhaps 90 seconds until first question
about keyboard/language).

Thanks

Comment 6 Craig White 2007-11-13 22:12:47 UTC
As to the 'mighty big hammer' of acpi=off...

Appending 'pci=noacpi clocksource=acpi_pm' to kernel parameters of grub doesn't
fix grub boot issues and I understand that this is kernel bugzilla and not
overly interested in grub issues.

Appending 'pci=noacpi clocksource=acpi_pm' to kernel parameters on lilo.conf
does indeed boot and seems to run fairly well on initial testing (speed, startup
daemon spew).

Perhaps speed issue only relates to CD which I may fail to anticipate the speed
of reading from resuce CD.

Craig

Comment 7 Chuck Ebbert 2007-11-13 22:50:40 UTC
(In reply to comment #6)
> Appending 'pci=noacpi clocksource=acpi_pm' to kernel parameters of grub doesn't
> fix grub boot issues and I understand that this is kernel bugzilla and not
> overly interested in grub issues.
> 

not really, but have you reinstalled the latest grub? The package may get
updated on the filesystem, but does not automatically get installed to the boot
sector.


Comment 8 Craig White 2007-11-13 23:38:59 UTC
not exactly sure what you are telling me (#7)

grub is 0.97-19.x86_64

I do execute

grub-install /dev/sda

and it reports back that if my /dev/sda is [hd0], I'm good to go

it never does boot stage 1.5 (I think is where it stops).

do I need to do something other than 'grub-install /dev/sda' ?

Obviously, I am running 'lilo -v' after all attempts at getting grub to work fail.

Comment 9 Craig White 2007-11-14 19:16:41 UTC
Created attachment 258581 [details]
New output of dmidecode after BIOS update from Dell

output of diff -u from new run of dmidecode after BIOS update and previously
uploaded dmidecode

$ diff -u ~/dmidecode.txt ~/Desktop/dmidecode.txt
--- /home/storage/users/craig/dmidecode.txt	2007-11-14 12:10:58.000000000
-0700
+++ /home/storage/users/craig/Desktop/dmidecode.txt	2007-11-14
12:12:39.000000000 -0700
@@ -1,6 +1,6 @@
 # dmidecode 2.7
 SMBIOS 2.3 present.
-68 structures occupying 2298 bytes.
+68 structures occupying 2297 bytes.
 Table at 0x000F0450.

 Handle 0xDA00, DMI type 218, 35 bytes.
@@ -20,8 +20,8 @@
 Handle 0x0000, DMI type 0, 24 bytes.
 BIOS Information
	Vendor: Dell Inc.
-	Version: 1.1.10
-	Release Date: 09/13/2007
+	Version: 1.1.5
+	Release Date: 03/27/2007
	Address: 0xF0000
	Runtime Size: 64 kB
	ROM Size: 512 kB
@@ -586,7 +586,7 @@
 Handle 0xDE00, DMI type 222, 13 bytes.
 OEM-specific Type
	Header and Data:
-		DE 0D 00 DE C1 01 00 00 07 11 13 09 03
+		DE 0D 00 DE C1 01 FF FF 00 00 00 00 00

 Handle 0x7F00, DMI type 127, 4 bytes.
 End Of Table

Comment 10 Craig White 2007-11-14 19:18:21 UTC
I'll work out grub issues elsewhere, I am interested to see if we can make some
progress on this chipset combination - absolutely latest BIOS from Dell
installed - thanks

Comment 11 Craig White 2007-11-21 18:58:33 UTC
Is there any hope for 2.6.23 kernel to be able to boot on these systems without
the need for kernel parameters 'pci=noacpi clocksource=acpi_pm' ?

Is there any more information I can provide while I still have one of these
desktop systems on my desk?

Comment 12 C Lance Moxley 2008-01-17 15:03:30 UTC
Dell released BIOS 1.1.11 last week. With that installed, the only kernel
parameter I needed to get Fedora 8 (2.6.23.9-85.fc8) to boot was
clocksource=acpi_pm. With that I now actually see 2 CPU's via hyperthreading.
Before I had to use pci=noacpi also and that made the kernel only see one CPU. 

This is on an already installed system using lilo to boot.

Comment 14 Bug Zapper 2008-11-26 08:23:07 UTC
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 15 Bug Zapper 2009-01-09 07:24:32 UTC
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 16 Aaron Innes 2009-01-09 18:25:51 UTC
In testing Fedora 10, I tried to run a live CD to install on a Dell Optiplex 320 with an intel chipset. The live cd would not boot past 'Loading initrd0.img....ready.' It gets here and hangs each time. I tested the same CD on several other dell PC's including an optiplex 330, Vostro 1500 notebook and a Lattitude D830 notebook. The cd will load successfully and I can install the OS successfully on each of these machines, except the 320.

The 320 has the most up to date BIOS available and all the hardware passes testing. What else can I provide that would be helpful?