/* Please CC me in any response, I'm not on LKML or the x86 list */
Hi all, I'm afraid "perl scripts/get_maintainer.pl -f arch/x86/boot/compressed/misc.c"
has pointed to you as the people to report this to.. ;-)
I've got an ancient Olivetti Netstrada, a deskside server
system with quad Pentium Pro 200MHz processors, 256MB RAM,
dual power supplies and five 4GB SCSI drives. I've been
trying to get a newer distro on for a little while and you
can read the backstory elsewhere [1].
Current problem is that I am unable to get either 2.6.38.3
or 2.6.39-rc4 (or the Debian Squeeze 686 and 486 2.6.32 based
kernels) to boot, the final message I see is:
Booting the kernel.
The 2.6.18 based kernel from Debian Etch works with no problems,
but the Lenny 2.6.26 based kernel panics when decompressing the
initramfs claiming it's out of memory.
So far I've tried with a combination of 2.6.38.3 and 2.6.39-rc4:
1) A config based upon Debian's 2.6.32 kernel
2) A minimal config starting from an "allnoconfig" base.
3) An "allnoconfig" with the processor set to Pentium Pro
and with all the "panic on hang" type checks turned on
and the "panic=30" boot option.
4) An "allnoconfig" with verbose debug and boot messages
and the processor set to i386.
All result in the same behaviour and I'm somewhat at a loss
as to how to debug this further, being a sysadmin rather than
a real kernel hacker. :-(
I've attached the 2.6.39-rc4 kernel config from point 4, and
the kernel config for the working Debian kernel (2.6.18-6-686).
I've also attached the contents of /proc/cpuinfo, /proc/io*,
/proc/scsi/scsi, /proc/modules and the output of lspci -vvv
and of dmesg from Debian Sarge running the Debian Etch kernel
(2.6.18-6-686).
This box has given me good service over the past 8 years or
so and I'd hate to have to retire it now due to this when I
feel Linux should still work on it..
Any ideas please ?
All the best,
Chris
[1] - http://www.csamuel.org/2011/04/22/modern-kernels-fail-to-boot-on-old-quad-processor-pentium-pro-server
--
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP
* Chris Samuel <[email protected]> wrote:
> This box has given me good service over the past 8 years or
> so and I'd hate to have to retire it now due to this when I
> feel Linux should still work on it..
>
> Any ideas please ?
Have you tried the earlyprintk=vga boot parameter yet? Maybe that shows more
than just a silent hang ...
Other than that, do you have some other box where you can build bzImages for
this system in reasonable time? If yes then you might be able to bisect to the
commit that broke it.
Thanks,
Ingo
> All result in the same behaviour and I'm somewhat at a loss
> as to how to debug this further, being a sysadmin rather than
> a real kernel hacker. :-(
>
> I've attached the 2.6.39-rc4 kernel config from point 4, and
> the kernel config for the working Debian kernel (2.6.18-6-686).
>
> I've also attached the contents of /proc/cpuinfo, /proc/io*,
> /proc/scsi/scsi, /proc/modules and the output of lspci -vvv
> and of dmesg from Debian Sarge running the Debian Etch kernel
> (2.6.18-6-686).
>
> This box has given me good service over the past 8 years or
> so and I'd hate to have to retire it now due to this when I
> feel Linux should still work on it..
>
> Any ideas please ?
earlyprintk=vga
(or better yet earlyprintk=ttyS0 and a serial port)
There are a couple of PPro funnies - there's an area of memory that
must be excluded due to a chip errata and I seem to remember some PPro
boxes also having slightly quirking E820 (BIOS memory reporting behaviour)
Alan
On Fri, Apr 22, 2011 at 6:46 AM, Ingo Molnar <[email protected]> wrote:
>
> * Chris Samuel <[email protected]> wrote:
>
>> This box has given me good service over the past 8 years or
>> so and I'd hate to have to retire it now due to this when I
>> feel Linux should still work on it..
>>
>> Any ideas please ?
>
> Have you tried the earlyprintk=vga boot parameter yet? Maybe that shows more
> than just a silent hang ...
>
> Other than that, do you have some other box where you can build bzImages for
> this system in reasonable time? If yes then you might be able to bisect to the
> commit that broke it.
with Chris's config for 2.6.39-rc4, current tip tree says:
kernel/sched.c: In function ?sched_init?:
kernel/sched.c:7845:28: error: ?load_balance_tmpmask? undeclared
(first use in this function)
kernel/sched.c:7845:28: note: each undeclared identifier is reported
only once for each function it appears in
kernel/sched.c:7845:3: warning: type defaults to ?int? in type name
kernel/sched.c:7845:28: warning: initialization makes pointer from
integer without a cast
kernel/sched.c:7845:3: warning: type defaults to ?int? in type name
* Yinghai Lu <[email protected]> wrote:
> with Chris's config for 2.6.39-rc4, current tip tree says:
>
> kernel/sched.c: In function ‘sched_init’:
> kernel/sched.c:7845:28: error: ‘load_balance_tmpmask’ undeclared
> (first use in this function)
> kernel/sched.c:7845:28: note: each undeclared identifier is reported
> only once for each function it appears in
> kernel/sched.c:7845:3: warning: type defaults to ‘int’ in type name
> kernel/sched.c:7845:28: warning: initialization makes pointer from
> integer without a cast
> kernel/sched.c:7845:3: warning: type defaults to ‘int’ in type name
Which sha1? It builds fine here on:
ae1e16c: Merge branch 'perf/urgent'
Thanks,
Ingo
On 04/22/2011 12:29 PM, Ingo Molnar wrote:
>
> * Yinghai Lu <[email protected]> wrote:
>
>> with Chris's config for 2.6.39-rc4, current tip tree says:
>>
>> kernel/sched.c: In function ‘sched_init’:
>> kernel/sched.c:7845:28: error: ‘load_balance_tmpmask’ undeclared
>> (first use in this function)
>> kernel/sched.c:7845:28: note: each undeclared identifier is reported
>> only once for each function it appears in
>> kernel/sched.c:7845:3: warning: type defaults to ‘int’ in type name
>> kernel/sched.c:7845:28: warning: initialization makes pointer from
>> integer without a cast
>> kernel/sched.c:7845:3: warning: type defaults to ‘int’ in type name
>
> Which sha1? It builds fine here on:
>
> ae1e16c: Merge branch 'perf/urgent'
>
one local patch caused the problem.
Index: linux-2.6/kernel/sched.c
===================================================================
--- linux-2.6.orig/kernel/sched.c
+++ linux-2.6/kernel/sched.c
@@ -7808,9 +7808,6 @@ void __init sched_init(void)
#ifdef CONFIG_RT_GROUP_SCHED
alloc_size += 2 * nr_cpu_ids * sizeof(void **);
#endif
-#ifdef CONFIG_CPUMASK_OFFSTACK
- alloc_size += num_possible_cpus() * cpumask_size();
-#endif
if (alloc_size) {
ptr = (unsigned long)kzalloc(alloc_size, GFP_NOWAIT);
@@ -7830,14 +7827,12 @@ void __init sched_init(void)
ptr += nr_cpu_ids * sizeof(void **);
#endif /* CONFIG_RT_GROUP_SCHED */
-#ifdef CONFIG_CPUMASK_OFFSTACK
- for_each_possible_cpu(i) {
- per_cpu(load_balance_tmpmask, i) = (void *)ptr;
- ptr += cpumask_size();
- }
-#endif /* CONFIG_CPUMASK_OFFSTACK */
}
+ for_each_possible_cpu(i)
+ zalloc_cpumask_var_node(&per_cpu(load_balance_tmpmask, i),
+ GFP_NOWAIT, cpu_to_node(i));
+
#ifdef CONFIG_SMP
init_defrootdomain();
#endif
Sorry for noisy.
Thanks
Yinghai
Syt mae Alan! ;-)
On Sat, 23 Apr 2011 02:34:22 AM Alan Cox wrote:
> earlyprintk=vga
Ahh, that's a new one on me, and it reveals that the kernel
has gone from 2.6.18 detecting:
256MB LOWMEM available.
to 2.6.39-rc4 detecting:
16MB LOWMEM available.
That would explain an awful lot..
> (or better yet earlyprintk=ttyS0 and a serial port)
Hmm, I might still have a null modem cable hanging around..
> There are a couple of PPro funnies - there's an area of memory that
> must be excluded due to a chip errata and I seem to remember some
> PPro boxes also having slightly quirking E820 (BIOS memory
> reporting behaviour)
Sigh, that's just reminded me that a couple of years ago I
had a private discussion with H. Peter Anvin about 2.6.25
panic'ing on boot with:
initrd extends beyond end of memory (0x0ffef173 > ox01000000)
He gave me a modified syslinux to dump out memory information
and it reported:
INT 15h = f000:f859 DOS RAM: 638K (0x9f800) INT 12h: 638K (0x9f800)
INT 15 88: 0x3c00 (15360K) INT 15 E801: 0x0000 (0K) 0x0000 (0K)
He responded with:
# Right... you have a system dependent on E801, and somehow E801
# returns crap.
#
# I'm going to cook up a modified meminfo.c32 for you and see if
# we can't track this down.
Unfortunately nothing happened and when I prodded him it turned
out he'd been too busy, so I just kept on running old kernels
from that point on and completely forgot about why. :-(
Hope life is still good in Abertawe!
Chris
--
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP
Hi Ingo,
On Fri, 22 Apr 2011 11:46:48 PM Ingo Molnar wrote:
> Have you tried the earlyprintk=vga boot parameter yet? Maybe that
> shows more than just a silent hang ...
Thanks for that, just responded to Alan's email mentioning the
same option - I'd not come stumbled across it before. It reveals
the cause is the kernel misdetecting the amount of LOWMEM as 16MB
and, I suspect, is the same issue as I had an offlist conversation
with H. Peter Anvin with in 2008 which tailed off due to work
pressure on his part. There are more details in my response to Alan.
> Other than that, do you have some other box where you can build
> bzImages for this system in reasonable time? If yes then you
> might be able to bisect to the commit that broke it.
I can indeed, I'm lucky enough to be able to build that image
in about 4 minutes on my production desktop. Is that still of
use given that there's now a better view of what's going on ?
All the best,
Chris
--
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP
> Sigh, that's just reminded me that a couple of years ago I
> had a private discussion with H. Peter Anvin about 2.6.25
> panic'ing on boot with:
>
> initrd extends beyond end of memory (0x0ffef173 > ox01000000)
>
> He gave me a modified syslinux to dump out memory information
> and it reported:
>
> INT 15h = f000:f859 DOS RAM: 638K (0x9f800) INT 12h: 638K (0x9f800)
> INT 15 88: 0x3c00 (15360K) INT 15 E801: 0x0000 (0K) 0x0000 (0K)
>
> He responded with:
>
> # Right... you have a system dependent on E801, and somehow E801
> # returns crap.
> #
> # I'm going to cook up a modified meminfo.c32 for you and see if
> # we can't track this down.
This is a stupid BIOS, but do you know if it used E820 in? the old kernel?
I wonder if this has something to do with the changes made to support ACPI 3.0 changes to E820?
This would be easy to diagnose with DOS DEBUG with no himem.sys loaded.
Yuhong Bao
-
On Sat, 23 Apr 2011 11:28:20 AM Yuhong Bao wrote:
> This is a stupid BIOS,
I won't argue with that, it is at least 15 years old..
> but do you know if it used E820 in the old kernel?
No, it was using E801:
BIOS-provided physical RAM map:
BIOS-e801: 0000000000000000 - 000000000009f000 (usable)
BIOS-e801: 0000000000100000 - 0000000010000000 (usable)
The new kernel has the '1' in the top end of the second
part being one place to the right:
BIOS-provided physical RAM map:
BIOS-e801: 0000000000000000 - 000000000009f000 (usable)
BIOS-e801: 0000000000100000 - 0000000001000000 (usable)
> I wonder if this has something to do with the changes made
> to support ACPI 3.0 changes to E820?
I suspect not, given it's not using E820. But could be wrong. ;-)
> This would be easy to diagnose with DOS DEBUG with no himem.sys
> loaded.
Would be happy to try with some instructions if it would help.
cheers,
Chris
--
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP
On Sat, 23 Apr 2011 10:53:31 AM H. Peter Anvin wrote:
> Sorry, I had forgotten... let's see if we can't make this happen.
Thanks and not a problem, my fault for having let it lapse in 2008!
--
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP
If it was really BIOS-e801 and not BIOS-88 returning this, looks like this is probably a kernel bug in the parsing of the results.
> > This would be easy to diagnose with DOS DEBUG with no himem.sys
> > loaded.
>
> Would be happy to try with some instructions if it would help.
Enter these instructions using the A command and execute with the T command:
mov AX, E801
INT 15
INT 3
And provide the results of the AX, BX, CX, and DX registers after the INT 15h.
Yuhong Bao -
On 04/22/2011 06:28 PM, Yuhong Bao wrote:
>
> This is a stupid BIOS, but do you know if it used E820 in the old kernel?
> I wonder if this has something to do with the changes made to support ACPI 3.0 changes to E820?
> This would be easy to diagnose with DOS DEBUG with no himem.sys loaded.
>
> Yuhong Bao
>
I suspect this broke during the rewrite of the setup code to C in 2007.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On 04/22/2011 06:46 PM, Yuhong Bao wrote:
>
> If it was really BIOS-e801 and not BIOS-88 returning this, looks like this is probably a kernel bug in the parsing of the results.
>>> This would be easy to diagnose with DOS DEBUG with no himem.sys
>>> loaded.
>>
>> Would be happy to try with some instructions if it would help.
> Enter these instructions using the A command and execute with the T command:
> mov AX, E801
> INT 15
> INT 3
> And provide the results of the AX, BX, CX, and DX registers after the INT 15h.
>
Executing these from DOS DEBUG won't give you real results, because DOS
intercepts this call.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
> Executing these from DOS DEBUG won't give you real results, because DOS
> intercepts this call.
Which is why I said to do it without himem.sys loaded in a previous email.
Yuhong Bao
-
On Sat, 23 Apr 2011 11:46:13 AM Yuhong Bao wrote:
> > Would be happy to try with some instructions if it would help.
>
> Enter these instructions using the A command and execute with the T
> command: mov AX, E801
> INT 15
> INT 3
> And provide the results of the AX, BX, CX, and DX registers after
> the INT 15h.
I should have asked previously - is this possible with FreeDOS ?
I don't have an DOS media myself.
--
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP
On Sat, 23 Apr 2011 11:46:13 AM Yuhong Bao wrote:
> Enter these instructions using the A command and execute with the T
> command: mov AX, E801
> INT 15
> INT 3
>
> And provide the results of the AX, BX, CX, and DX registers after
> the INT 15h.
OK, so I'm a novice so I'll recap what I did. Starting with FreeDOS
boot floppy and copied debug.com and debug98.com to the FreeDOS
directory on it. Booted from the floppy, selected option 2 (safe
mode, no drivers loaded). Typed debug and then:
- A
2890:0100 mov AX, E801
2890:0103 int 15
2890:0105 int 3
2890:0106
- t
AX=E801 BX=0000 CX=0000 DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000
DS=2890 ES=2890 SS=2890 CS=2890 IP=0103 NV UP DI PL NZ NA PO NC
2890:0103 CD15 INT 15
-
Does that look correct ? I presume it was just <enter> to leave
the 'A' mode to go back to the command mode ?
cheers,
Chris
--
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP
On Sat, 23 Apr 2011 12:03:55 PM H. Peter Anvin wrote:
> I suspect this broke during the rewrite of the setup code to
> C in 2007.
Looking at arch/x86/boot/memory.c I see the snipped:
} else {
/*
* This ignores memory above 16MB if we have a memory
* hole there. If someone actually finds a machine
* with a memory hole at 16MB and no support for
* 0E820h they should probably generate a fake e820
* map.
*/
boot_params.alt_mem_k = oreg.ax;
}
Could this be what's going on ? Or am I just grasping at straws ? :-)
cheers,
Chris
--
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP
On Sat, 23 Apr 2011 10:16:18 +1000
Chris Samuel <[email protected]> wrote:
> Syt mae Alan! ;-)
G'day ;)
> Ahh, that's a new one on me, and it reveals that the kernel
> has gone from 2.6.18 detecting:
>
> 256MB LOWMEM available.
>
> to 2.6.39-rc4 detecting:
>
> 16MB LOWMEM available.
>
> That would explain an awful lot..
Could be something has disturbed its memory detect or could be a bug in
the PPro memory quirk.
If you boot with mem= and force the memory size what happens ?
> INT 15h = f000:f859 DOS RAM: 638K (0x9f800) INT 12h: 638K (0x9f800)
> INT 15 88: 0x3c00 (15360K) INT 15 E801: 0x0000 (0K) 0x0000 (0K)
Ah.. do you have a BIOS setting called something like OS/2 compatibility ?
> Hope life is still good in Abertawe!
This part of the world has changed rather a lot. Not sure you'd recognize
half of it.
Alan
On Sat, 23 Apr 2011 07:35:36 PM Alan Cox wrote:
> On Sat, 23 Apr 2011 10:16:18 +1000
> Chris Samuel <[email protected]> wrote:
> > Syt mae Alan! ;-)
>
> G'day ;)
Touch?!
> > That would explain an awful lot..
>
> Could be something has disturbed its memory detect or could be a
> bug in the PPro memory quirk.
>
> If you boot with mem= and force the memory size what happens ?
Same behaviour I'm afraid, hangs claiming 16MB of LOWMEM. :-(
> > INT 15h = f000:f859 DOS RAM: 638K (0x9f800) INT 12h: 638K
> > (0x9f800) INT 15 88: 0x3c00 (15360K) INT 15 E801: 0x0000 (0K)
> > 0x0000 (0K)
>
> Ah.. do you have a BIOS setting called something like OS/2
> compatibility ?
That's the really odd thing, I am yet to find a way to access
the BIOS settings on this beast. I've tried the usual DEL, F2
and F1 with no success and there is no prompt I've ever seen
to offer access to one. I do have a ZIP file that contains
the last BIOS upgrade for it that was released so I'll see if
I can make that bootable and see if that reveals any options.
> > Hope life is still good in Abertawe!
>
> This part of the world has changed rather a lot. Not sure
> you'd recognize half of it.
I can imagine, it's been a while since I've been back in
South Wales!
Take care,
Chris
--
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP
Hi Alan,
On Sat, 23 Apr 2011 08:35:59 PM Chris Samuel wrote:
> On Sat, 23 Apr 2011 07:35:36 PM Alan Cox wrote:
>
> > Ah.. do you have a BIOS setting called something like OS/2
> > compatibility ?
>
> That's the really odd thing, I am yet to find a way to access
> the BIOS settings on this beast. I've tried the usual DEL, F2
> and F1 with no success and there is no prompt I've ever seen
> to offer access to one. I do have a ZIP file that contains
> the last BIOS upgrade for it that was released so I'll see if
> I can make that bootable and see if that reveals any options.
OK, that ZIP file doesn't have a BIOS but it did have a BIOS
configuration program. I have a "Primary Operating System"
option which is currently:
UNIX, Novell, Windows NT, OS/2, Other (Multi-Processor)
The alternatives for that option are:
UNIX, Novell, Windows NT, Others (Single-Processor)
DOS, OS/2
The README accompanying the ZIP says:
# Due to a PentiumPro bug the BIOS need to know if a Multi-Processor
# or Single Processor Operating System is installed to correctly
# set-up the local APIC and MP table.
The only other options that seem like they might be relevant are:
Extended Memory Above 64MB Support - Enabled
Video Shadowing - Shadowed at C000: and C400:
As regards memory it reports:
Base Memory: 640KB
Extended Memory (Contiguous): 255MB
Extended Memory (Non-contiguous): 0KB
Anything ring any bells there ?
cheers,
Chris
--
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP
On Sat, 23 Apr 2011 07:35:36 PM Alan Cox wrote:
> If you boot with mem= and force the memory size what happens ?
Using memmap=636K@0 memmap=255M@1M (from just naively converting
the e801 numbers from the 2.6.18 boot) it appears to get past that
issue and then panic because of no root filesystem (unsurprisingly
as it's based on an allnoconfig config).
Trying the same with the Debian Squeeze 2.6.32 based kernel results
in it not panic'ing when unpacking the initramfs but there are many
complaints about IRQ's happening and nobody caring and the system
ends up shutting itself down due to timing out bringing up the root
filesystem from the software RAID.
I'll be away from email for a few days now because of the Easter
holidays here, but I'll catch up when I'm back.
All the best, and thanks to everyone for the help so far!
Chris
--
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP