Bug 27203 - PXE initrd download to the wrong memory space
PXE initrd download to the wrong memory space
Status: CLOSED DUPLICATE of bug 11773
Product: Red Hat Linux
Classification: Retired
Component: pxe (Show other bugs)
7.0
i386 Linux
high Severity high
: ---
: ---
Assigned To: Elliot Lee
Brock Organ
:
: 18277 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-02-12 16:26 EST by Michael Johnson
Modified: 2005-10-31 17:00 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-08-08 01:08:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michael Johnson 2001-02-12 16:26:55 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.17-14 i686)


On a server with > 2Gig RAM I am getting the following messages:
initrd already destroyed by paging_init!
initrd overwritten (0x4faf0000 < 0xc19bdc98) - disabling it.
RAMDISK: Couldn't find valid RAM disk image starting at 0.
Invalid session number or type of track
Kernel panic: VFS: Unable to mount root fs on 01:01

On inspection it appears that pxe-linux/nbp.linux/download.c is loading the
initrd image into a place the kernel doesn't expect it.

PXELINUX(part of the syslinux package) implies that there is an upper bound
on the address that initrd can be loaded into, specifically 0x038000000. 
download.c does not take this into account.

I do not know enough about the kernel's memory model to know if this is the
"right thing to do".  Hopefully someone can use this information to verify
that this is the problem. 

If it is the problem, the following patch may work.  I have successfully
tried it on the failing server.

*** download.c	Thu Sep 23 17:58:21 1999
--- /tmp/downloadpatch/download.c	Mon Feb 12 12:07:50 2001
*************** t_IP sip;
*** 95,100 ****
--- 95,102 ----
          t_PXE_MTFTP_TMOUT *mtftp_tmout;
          t_PXE_MTFTP_DELAY *mtftp_delay;
  
+         unsigned long mem_size = 0;
+ 
          if (bootfile = find_dhcp_tag(&reply, 67, 0)) {
                  strncpy(dl_fname, bootfile->buf, bootfile->len);
                  dl_fname[bootfile->len] = 0;
*************** t_IP sip;
*** 116,122 ****
  
          initrd_size = 4 * 1024L * 1024L;
  
!         initrd_addr = (get_memsize() - 1024L) * 1024L - initrd_size;
  
          cll();
          bputs("Downloading initrd image...\n");
--- 118,129 ----
  
          initrd_size = 4 * 1024L * 1024L;
  
!         mem_size = get_memsize();
!         if (mem_size > 0x038000000) {
!                 initrd_addr = 0x038000000 - initrd_size;
!         } else {
!                 initrd_addr = (mem_size - 1024L) * 1024L - initrd_size;
!         }
  
          cll();
          bputs("Downloading initrd image...\n");



Reproducible: Always
Steps to Reproduce:
1. Use PXE to boot a server with > 2Gig RAM.
2.
3.
	

Actual Results:  ...
mapped APIC to ffffe000 (fee00000)
mapped IOAPIC to ffffd000 (fec00000)
mapped IOAPIC to ffffc000 (fec01000)
initrd already destroyed by paging_init!
Detected 700084 kHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1395.92 BogoMIPS
initrd overwritten (0x4faf0000 < 0xc19bdc98) - disabling it.
...
RAMDISK: Couldn't find valid RAM disk image starting at 0.
Invalid session number or type of track
Kernel panic: VFS: Unable to mount root fs on 01:01

Expected Results:  The boot should have completed.

I have tried booting kernels with BIGMEM turned on and off, as well as 2
gig support.  All showed the same result.
Comment 1 Michael Johnson 2001-02-12 17:29:43 EST
Opps, wrong patch file.  The patch should read:

*** download.c	Thu Sep 23 17:58:21 1999
--- /tmp/downloadpatch/download.c	Mon Feb 12 13:35:52 2001
*************** t_IP sip;
*** 95,100 ****
--- 95,102 ----
          t_PXE_MTFTP_TMOUT *mtftp_tmout;
          t_PXE_MTFTP_DELAY *mtftp_delay;
  
+         unsigned long mem_size = 0;
+ 
          if (bootfile = find_dhcp_tag(&reply, 67, 0)) {
                  strncpy(dl_fname, bootfile->buf, bootfile->len);
                  dl_fname[bootfile->len] = 0;
*************** t_IP sip;
*** 116,122 ****
  
          initrd_size = 4 * 1024L * 1024L;
  
!         initrd_addr = (get_memsize() - 1024L) * 1024L - initrd_size;
  
          cll();
--- 118,129 ----
  
          initrd_size = 4 * 1024L * 1024L;
  
!         mem_size = (get_memsize() - 1024L) * 1024L;
!         if (mem_size > 0x038000000) {
!                 initrd_addr = 0x038000000 - initrd_size;
!         } else {
!                 initrd_addr = mem_size - initrd_size;
!         }
  
          cll();
          bputs("Downloading initrd image...\n");

          bputs("Downloading initrd image...\n");
Comment 2 Michael Johnson 2001-02-12 17:31:31 EST
Let's try that again, it pasted wrong...

*** download.c	Thu Sep 23 17:58:21 1999
--- /tmp/downloadpatch/download.c	Mon Feb 12 13:35:52 2001
*************** t_IP sip;
*** 95,100 ****
--- 95,102 ----
          t_PXE_MTFTP_TMOUT *mtftp_tmout;
          t_PXE_MTFTP_DELAY *mtftp_delay;
  
+         unsigned long mem_size = 0;
+ 
          if (bootfile = find_dhcp_tag(&reply, 67, 0)) {
                  strncpy(dl_fname, bootfile->buf, bootfile->len);
                  dl_fname[bootfile->len] = 0;
*************** t_IP sip;
*** 116,122 ****
  
          initrd_size = 4 * 1024L * 1024L;
  
!         initrd_addr = (get_memsize() - 1024L) * 1024L - initrd_size;
  
          cll();
          bputs("Downloading initrd image...\n");
--- 118,129 ----
  
          initrd_size = 4 * 1024L * 1024L;
  
!         mem_size = (get_memsize() - 1024L) * 1024L;
!         if (mem_size > 0x038000000) {
!                 initrd_addr = 0x038000000 - initrd_size;
!         } else {
!                 initrd_addr = mem_size - initrd_size;
!         }
  
          cll();
          bputs("Downloading initrd image...\n");

Comment 3 Elliot Lee 2001-08-08 00:59:17 EDT
Whee a patch, must apply.

Apologies for the unresponsiveness of the previous pxe maintainer...
Comment 4 Elliot Lee 2001-08-08 01:08:44 EDT
*** Bug 18277 has been marked as a duplicate of this bug. ***
Comment 5 Elliot Lee 2001-08-26 16:11:08 EDT

*** This bug has been marked as a duplicate of 11773 ***

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