When trying to use doscmd on 8-stable, all I get is:
Error mapping HMA, HMA disabled: : Invalid argument
Segmentation fault (core dumped)
The segfault happens at the end of mem_init(), when the allocated DOS
memory (which is located at virtual address 0) is attempted to be
written to. Apparently, the mmap() failure that causes the "HMA
disabled" message is actually a fatal error rather than a benign one
the could be ignored, as it results in no valid DOS memory allocation
at all.
Right now, the only older system I could test it against uses FreeBSD
5.x, where the mmap() works as expected. So does anyone have an idea
why this mmap() call:
if (mmap((caddr_t)0x000000, 0x100000,
PROT_EXEC | PROT_READ | PROT_WRITE,
MAP_ANON | MAP_FIXED | MAP_SHARED,
-1, 0) == MAP_FAILED) {
perror("Error mapping HMA, HMA disabled: ");
HMA_a20 = -1;
close(HMA_fd_off);
close(HMA_fd_on);
return;
}
yields an EINVAL now under 8-stable?
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
On Wed, Jun 15, 2011 at 03:57:05PM +0200, Joerg Wunsch wrote:> When trying to use doscmd on 8-stable, all I get is: > > Error mapping HMA, HMA disabled: : Invalid argument > Segmentation fault (core dumped) > > The segfault happens at the end of mem_init(), when the allocated DOS > memory (which is located at virtual address 0) is attempted to be > written to. Apparently, the mmap() failure that causes the "HMA > disabled" message is actually a fatal error rather than a benign one > the could be ignored, as it results in no valid DOS memory allocation > at all. > > Right now, the only older system I could test it against uses FreeBSD > 5.x, where the mmap() works as expected. So does anyone have an idea > why this mmap() call: > > if (mmap((caddr_t)0x000000, 0x100000, > PROT_EXEC | PROT_READ | PROT_WRITE, > MAP_ANON | MAP_FIXED | MAP_SHARED, > -1, 0) == MAP_FAILED) { > perror("Error mapping HMA, HMA disabled: "); > HMA_a20 = -1; > close(HMA_fd_off); > close(HMA_fd_on); > return; > } > > yields an EINVAL now under 8-stable?Based on what I can determine from the mmap(2) man page: MAP_FIXED Do not permit the system to select a different address than the one specified. If the specified address can- not be used, mmap() will fail. If MAP_FIXED is speci- fied, addr must be a multiple of the pagesize. If a MAP_FIXED request is successful, the mapping estab- lished by mmap() replaces any previous mappings for the process' pages in the range from addr to addr + len. Use of this option is discouraged. [EINVAL] MAP_FIXED was specified and the addr argument was not page aligned, or part of the desired address space resides out of the valid address space for a user process. I imagine that the page size ordeal is probably what's biting you. Now, I'm not sure if page size in that above context refers to "kernel page size" (e.g. hw.pagesizes or hw.pagesize) or if it refers to "a page of memory" as in what libc/malloc uses. I'm not sure why a person would need or want MAP_FIXED in this situation; why can't they just take the result of mmap() (a void *) and use that as a base address offset instead of assuming zero in their software? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |
On Wed, Jun 15, 2011 at 03:57:05PM +0200, Joerg Wunsch wrote:> When trying to use doscmd on 8-stable, all I get is: > > Error mapping HMA, HMA disabled: : Invalid argument > Segmentation fault (core dumped) > > The segfault happens at the end of mem_init(), when the allocated DOS > memory (which is located at virtual address 0) is attempted to be > written to. Apparently, the mmap() failure that causes the "HMA > disabled" message is actually a fatal error rather than a benign one > the could be ignored, as it results in no valid DOS memory allocation > at all. > > Right now, the only older system I could test it against uses FreeBSD > 5.x, where the mmap() works as expected. So does anyone have an idea > why this mmap() call: > > if (mmap((caddr_t)0x000000, 0x100000, > PROT_EXEC | PROT_READ | PROT_WRITE, > MAP_ANON | MAP_FIXED | MAP_SHARED, > -1, 0) == MAP_FAILED) { > perror("Error mapping HMA, HMA disabled: "); > HMA_a20 = -1; > close(HMA_fd_off); > close(HMA_fd_on); > return; > } > > yields an EINVAL now under 8-stable?Do sysctl security.bsd.map_at_zero=1 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20110615/f662cd6c/attachment.pgp
Hi Joerg, Flip security.bsd**.map_at_zero to 1. On Wed, Jun 15, 2011 at 3:57 PM, Joerg Wunsch < freebsd-stable@uriah.heep.sax.de> wrote:> When trying to use doscmd on 8-stable, all I get is: > > Error mapping HMA, HMA disabled: : Invalid argument > Segmentation fault (core dumped) > > The segfault happens at the end of mem_init(), when the allocated DOS > memory (which is located at virtual address 0) is attempted to be > written to. Apparently, the mmap() failure that causes the "HMA > disabled" message is actually a fatal error rather than a benign one > the could be ignored, as it results in no valid DOS memory allocation > at all. > > Right now, the only older system I could test it against uses FreeBSD > 5.x, where the mmap() works as expected. So does anyone have an idea > why this mmap() call: > > if (mmap((caddr_t)0x000000, 0x100000, > PROT_EXEC | PROT_READ | PROT_WRITE, > MAP_ANON | MAP_FIXED | MAP_SHARED, > -1, 0) == MAP_FAILED) { > perror("Error mapping HMA, HMA disabled: "); > HMA_a20 = -1; > close(HMA_fd_off); > close(HMA_fd_on); > return; > } > > yields an EINVAL now under 8-stable? > > -- > cheers, J"org .-.-. --... ...-- -.. . DL8DTL > > http://www.sax.de/~joerg/ NIC: JW11-RIPE > Never trust an operating system you don't have sources for. ;-) > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >-- Good, fast & cheap. Pick any two.