|
Bugzilla – Full Text Bug Listing |
| Summary: | autoyast choses wrong kernel during installation | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Frank Steiner <fsteiner-news> |
| Component: | AutoYaST | Assignee: | Jiri Srain <jsrain> |
| Status: | RESOLVED WONTFIX | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | ug |
| Version: | RC 1 | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | All | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | yast2 logfiles | ||
|
Description
Frank Steiner
2005-09-28 11:41:28 UTC
Created attachment 51043 [details]
yast2 logfiles
Jiri, I'm not sure if this is a bug in on of your components but I don't think it's in the autoyast code. I already sent you a link to the autoyast mailinglist archive where this problem was reported. Well, here is the official bug, so you can ignore my mail. This is generic problem, it affects also plain installation.
Hubert, what is the size limit for need for bigsmp kernel? In the YaST
sources, it is used if total size of physical mejory (returned by hwinfo) is
>= 0x0C0000000 (the comment in sources points to bug suse40792).
What's the status with current kernels?
At least for regular i386 machines the choice of the kernel would still be correct. With 4 GB of memory you need the bigsmp kernel. Don't know however how things are with x86_64. Maybe Andi can comment here. The 0xc0000000 heuristic for 32bit is still not quite correct. What counts is if there is any physical address of memory beyond 4GB, and there are some extreme cases like e.g. a 3GB machine has 2GB RAM 2GB PCI hole 1GB RAM so the last 1GB are beyond 4GB. That would need bigsmp too. A really reliable detection would be to ask the BIOS for the e820 map and check for the highest E820_RAM address or parse the e820 map the kernel prints at the beginning of boot.msg and check for the highest RAM address there (parsing the kernel way would be more reliable because it knows many tricks to get the information even on broken or outdated BIOS) Actually it might even sense to check for any mapping there, it's possible that BIOS puts PCI mappings beyond 4GB in the future. So if there is any e820 entry > 0xffffffff bigsmp should be used. At some point we'll also need to handle memory hotplug, for that likely ACPI SRAT would need to be parsed too (it has a special flag for "possible future memory area"). On 64bit there is no practical memory limit in any kernel. OK, the question is what should I do. If the reporter did real 64-bit installation, he would have got the only x86_64 kernel. So, this bug is about 32-bit software on 64-bit hardware. Do you think I should somehow enhance the heuristics (and could you clearly specify how to do it), or just close it as WONTFIX? I spelled out the heuristic for 32bit in detail in comment #5 Regarding "32bit software on 64bit hardware" :- a x86-64 system is a full x86 system, so there shouldn't be any difference here. What I described for 32bit applies fully when a 32bit kernel runs on it. For 64bit kernels there is no heuristic regarding memory size. All kernels handle all memory. OK. Steffen, is there a way to get the information soecified via comment #5 via hwinfo? It parses the kernel messages it but adds the e820 areas up. I can return the highest value, no problem. Andreas, do count 'reserved' areas, too? Reserved doesn't count. As this is happening on 10.0 I'll just close this bug WONTFIX now. Please feel free to retest on 10.1 >= beta9 and reopen in case this bugs persists there. |