|
Bugzilla – Full Text Bug Listing |
| Summary: | installation system freezes on compaq proliant 6400r | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 10.2 | Reporter: | Per Jessen <per> |
| Component: | Installation | Assignee: | Thomas Renninger <trenn> |
| Status: | RESOLVED WONTFIX | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Normal | ||
| Priority: | P5 - None | ||
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | i686 | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
Output from lspci
Ouptut from hwinfo console output output from dmidecode |
||
|
Description
Per Jessen
2006-09-07 15:34:19 UTC
Created attachment 98121 [details]
Output from lspci
Created attachment 98123 [details]
Ouptut from hwinfo
Yeah,when I install 10.2 Alpha 4,it hangs at the same staus and I get the same message. but my PC is not compaq proliant 6400r,it is: P4 2.4GHz,512 RAM,ATI 9000 video card,reltek 8139 network card,two harddisks,DVD-ROM Can you provide the full output of the kernel when it hangs? Created attachment 98662 [details]
console output
This is the console output captured over a serial connection.
*** This bug has been marked as a duplicate of bug 202079 *** I'm reopening this as I don't quite see why it is a duplicate of the K6 issue in bug 202079, especially when it can be sorted out by specifying maxcpus=0 (inspired by bug 210978). Does alpha5 fix the issue for you, or not? Greg seemed to think that this was caused by the same binutils error. Alpha5 does not fix the problem - the system will still hang in the same place if booted without additional kernel options. But at least I have the workaround of using "maxcpus=0" to get the installation to boot. I see. Andi, do you have an idea? It seems the MP-table is corrupt and confusing Linux. Is the workaround the best path, or should we fix the kernel to cope? FYI - 10.2 beta2 shows the same behaviour. Same issue with the MP/ACPI tables. Can you try apic boot param pls. Wrong, please try acpi=force (possibly also apic). I expect the BIOS misses dmi information and gets therefore acpi and apic blacklisted. Before 10.2, when BIOS dmi info was missing the Date field, it was still booted acpi=on, this changed and it's now expected that machine is quite old when dmi's DATE field is missing. If this is the case, a BIOS update might help... OK, I tried "apic=force" and it worked. I also tried with "acpi=force" which didn't work. Can you send dmidecode output, pls. I expect your BIOS' dmi information is buggy, therefore you machine gets wrongly blacklisted, we should be able to see this with dmidecode output. Is there a new BIOS available for this machine? Created attachment 114068 [details]
output from dmidecode
The machine is already running on the most recent BIOS version.
Your dmi information is buggy. It does not include a date and therefore your machine gets blacklisted to not use apic. It also has not the "Intel" as vendor string... Is there a BIOS update available? No, as I already wrote this machine is running on the most recent BIOS. One thing I don't understand is - why is this ONLY a problem during installation, whereas the system works/boots perfectly fine afterwards? If you booted failsafe or if you added other boot parameters into the boot options line at installation, they will get written to /boot/grub/menu.lst and also get used later, maybe it's that? Andi, this one has a P4 2.4GHz (->means not that old). But seem to miss dmi date string (cmp. with comment #18). apic=force fixes it. I'd suggest to use apic or acpi if dmi info is missing. There should be more and more machines needing it. This would also make more sense with failsafe options? If you agree, I can come up with a patch. If not, we should close this one? To comment #21 - good suggestion, but the machine is booted over etherboot and PXE with options = "noresume and noacpi". Andi, FYI: This one has no date in dmi info and therefore needs acpi=force. -> BIOS bug, going to close as won't fix. I still wonder whether we should go the old way: if no date available -> acpi=on like that new machines without date in dmi info will boot correctly, failsafe on old machines will also work. |