Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!metro!sequoia!ultima!kralizec.zeta.org.au!kralizec.zeta.org.au!not-for-mail From: bde@kralizec.zeta.org.au (Bruce Evans) Newsgroups: comp.os.386bsd.questions Subject: Re: KERNEL PANIC ANYONE Date: 19 Jul 1993 01:57:40 +1000 Organization: Kralizec Dialup Unix Sydney: +61-2-837-1183 V.32bis Lines: 39 Message-ID: <22brtkINNi99@kralizec.zeta.org.au> References: <22222@durer.cme.nist.gov> <1993Jul12.180752.29982@prepress.com> <GENE.93Jul14074659@stark.uucp> <CA8wL9.7G4@veda.is> <GENE.93Jul17074743@stark.uucp> NNTP-Posting-Host: kralizec.zeta.org.au In <GENE.93Jul17074743@stark.uucp> gene@cs.sunysb.edu!stark (Gene Stark) writes: >In article <CA8wL9.7G4@veda.is> adam@veda.is (Adam David) writes: > It is also possible to use 'size' to determine kernel size, if the hex value > does not go above 99000 it is alright. Since patchkit 0.2.4 the boot code is > changed so that if the kernel is too big it will not try to run. >This is wrong. Julian's bootblocks print the message: "Loader overlaps BSS, >kernel must bzero." Referring to the kernel file "/sys/i386/i386/locore.s", >we find the following comment: [comment I wrote last year] > * XXX - wdboot clears the bss after testing that this is safe. > * This is too wasteful - memory below 640K is scarce. The boot > * program should check: > * text+data <= &stack_variable - more_space_for_stack > * text+data+bss+pad+space_for_page_tables <= end_of_memory I'm not sure about this any more. Anyway, wdboot does't check things carefully enough. > * Oops, the gdt is in the carcass of the boot program so clearing > * the rest of memory is still not possible. > */ This comment probably only applies if you have my debugger (only I have it). The kernel itself doesn't access the gdt (it doesn't load any segment registers until after a new gdt is set up). >Notice the last line. I can say from sore experience that the kernel does >*NOT* reliably bzero all the BSS when it overlaps the loader. Build kernels >with BSS beyond 0xFE090000 at your own risk! Maybe that problem I noticed with the DMA bounce buffer at 0xFE098000? Together with the extra 7 pages for the initial page table, this would make the limit 0xFE091000. -- Bruce Evans bde@kralizec.zeta.org.au