This is an old revision of the document!


A PCRE internal error occured. This might be caused by a faulty plugin

<file> (14:07:39) alanshieh: I could not find a KEEP_IT_REAL option in Etherboot 5.4, so I am going to build a call stub into 16:32 protected mode. (14:10:32) alanshieh: Also, I don't know if adding an interface to export segment limits like we talked about is strictly needed; I think it's possible to use a flat (4GB) segment limit, and use the holes in the e820 output from ksyslog() to infer the possible memory that the PXE stack might need to use, and map in those holes from the undi-user program. (14:10:32) alanshieh: I think that might work well for generic PXE stacks that use PIO to talk to the card. (14:12:19) mdc: back (14:12:29) alanshieh: We can find the NIC's PIO and MMIO resources from Linux lspci interfaces, so we don't need to teach the PXE stack to provide that part of the memory map either. (14:14:23) Michael: You'll probably need to run in IOPL 3 anyway, which means no worrying about PIO resources (14:14:26) Michael: Hi Marty (14:14:42) mdc: Hi Michael, Hi All :) (14:15:27) alanshieh: Yeah, the lame NE2K-PCI "PIO for everything design" will probably work out great for the initial part of the development process :-) (14:15:55) alanshieh: I don't have to worry about read/write to 0xc0000000 - 0xffffffff ... (16:26:43) alanshieh: Should I still have a signature between 0-1MB ? 0-9fc00 is marked as "usable" in my e820 map (16:26:48) Michael: what's the chain of control through the boot process now? (16:27:12) alanshieh: grub was giving me grief, so it's out of the loop completely. (16:27:31) alanshieh: It's now (16:27:31) alanshieh: Etherboot (via iso image) => ELF w/ Linux 2.6 => boot linux from HD image (16:28:28) Michael: If Etherboot is loading an ELF image, it won't set up a PXE stack (16:28:38) Michael: because the ELF image wouldn't expect one (16:28:59) alanshieh: Ah (16:29:39) alanshieh: Would doing (16:29:39) alanshieh: Etherboot => pxelinux => Linux 2.6 (16:29:39) alanshieh: set up the stack? (16:30:01) Michael: It would, though pxelinux will probably tear it down. There might be an option to direct pxelinux to keep the PXE stack (16:30:10) Michael: aha (16:30:12) Michael: yes there is (16:30:25) Michael: add "keeppxe" to the kernel command line (16:30:33) Michael: in the pxelinux config file (16:33:27) alanshieh: Ok, giving this a shot... this is a really long test cycle -- at least a minute to boot. I haven't scrubbed my rc.d. (16:36:26) alanshieh: Awesome, that worked. (16:39:33) mdc: hpa strikes again :) (16:39:48) alanshieh: Hunting for pixies...found !PXE at 0009f000...ok, found at 0x9f000 (16:39:48) alanshieh: API 9f00:680 St 9e00:1000 UD 9e00:1000 UC 9f00:ab0 BD 0:0 BC 0:0 (16:39:48) alanshieh: Seems reasonable to me. (16:40:14) Michael: Yes, that looks correct for an Etherboot stack (16:40:26) Michael: no base code, stack and data in same segment (16:40:37) Michael: is the e820 map now not showing this memory? (16:40:40) Michael: (if not, we have a problem) (16:40:46) alanshieh: 0-1MB is still available (16:40:58) alanshieh: I mean "usable" (16:41:05) Michael: that cannot be the case; 640kB-1MB is always reserved (16:41:15) Michael: what is the usable range shown in the kernel log? (16:41:24) alanshieh: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) (16:41:24) alanshieh: BIOS-e820: 0000000000100000 - 0000000007eef040 (usable) (16:41:39) alanshieh: whoops (16:41:46) Michael: whoops? (16:42:02) alanshieh: misread the number of 0s in the first range (16:42:23) Michael: but it still says 9fc00 even when the PXE stack is showing up? (16:42:33) Michael: something is badly wrong if that is the case (16:42:34) alanshieh: yes (16:42:44) Michael: which Etherboot version? (16:43:22) alanshieh: 5.4.2 (16:43:31) Michael: hmmm (16:44:03) Michael: looks as though either (a) the e820 map mangling is broken, or (b) pxelinux is re-intercepting INT 15 for some nefarious purpose of its own (16:44:30) Michael: while our PXE stack is loaded, the memory we occupy should be invisible to all other programs (16:44:39) Michael: that's the only way we guarantee that they won't tread on us (16:44:54) Michael: we hook INT 15 and intercept e820, e801 and 88 (16:46:58) alanshieh: Is there a way for me to bypass pxelinux? (16:47:45) Michael: not that will still cause Etherboot to load a PXE stack (16:49:01) Michael: the code that does the INT 15 handling is in arch/i386/firmware/pcbios/e820mangler.S (16:49:09) Michael: controlled by arch/i386/firmware/pcbios/hidemem.c (16:49:28) Michael: you could put some debugging printf()s in hidemem.c just to check that the mangler is actually being installed (and not uninstalled) (16:50:12) Michael: one possibility is that the "keeppxe" option causes pxelinux to shut down the stack and leave it in memory, rather than leaving the stack active (16:50:20) Michael: we unhook INT 15 when the stack is shut down (16:50:26) Michael: so that would produce the symptom you're seeing (16:50:54) Michael: and would be fairly logical, since leaving a PXE stack running when you start an OS is generally a bad idea (unless you're trying to do exactly what you're doing now) (16:50:55) Michael: :) (16:51:04) alanshieh: heh (16:51:40) alanshieh: Well, I'll need to get my bochs environment working for this. My Etherboot images do serial printout properly in bochs, but not in qemu (16:56:17) alanshieh: Here's what pxelinux does: (16:56:17) alanshieh: http://rafb.net/paste/results/bNrUVe33.html (16:57:15) alanshieh: BTW, what's my e820 map supposed to look like? (17:00:04) Michael: The first region should run from 0 to the start of the PXE stack; 9e000 in your case </file> I fixed the 640KB reporting, but there were other problems:


QR Code
QR Code e820irc:irc_logs_for_e820_issue (generated for current page)