From owner-freebsd-hackers Sun Sep 20 10:40:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA01180 for freebsd-hackers-outgoing; Sun, 20 Sep 1998 10:40:32 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id KAA01170 for ; Sun, 20 Sep 1998 10:40:27 -0700 (PDT) (envelope-from wpaul@skynet.ctr.columbia.edu) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id NAA21711 for hackers@freebsd.org; Sun, 20 Sep 1998 13:45:26 -0400 From: Bill Paul Message-Id: <199809201745.NAA21711@skynet.ctr.columbia.edu> Subject: malloc()ing 64K physically contiguous buffer in kernel To: hackers@FreeBSD.ORG Date: Sun, 20 Sep 1998 13:45:24 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Grrr.... this is a question which has probably been asked many times before and I feel really silly asking it now. Unfortunately, I've been pushed into a corner by this crappy RealTek fast ethernet card. To make the RealTek 8129/8139 receiver work, I need to allocate a buffer of either 8, 16, 32 or 64K to act as a receive buffer. The card DMAs packets into this buffer until it reaches the end, then wraps back to the top. I initially programmed the card to use a 64K buffer, but I noticed that I was only able to receive about 16K worth of packets before everything ground to a halt. The card was still generating interrupts indicating that packets were still being received but there didn't seem to be any new packet data in the buffer region after the first 16K. This confused the heck out of me for a while, and I was convinced that I'd programmed the card wrong but couldn't see how. Then it dawned on me that although malloc() was giving me 64K of space to play with, it probably hadn't actually allocated 64K worth of contiguous pages. In other words, the first 4 pages are mapped contiguosly in memory, but the next 4K page after that is probably somewhere else off in physical memory. But the card doesn't know that, so it's probably DMAing into some unknown location in RAM and it's only by pure coincidence that it isn't scribbling all over the guts of the kernel and causing a panic. Unfortunately, the stinking hardware will not allow one to specify a buffer size smaller than 8K, and since the page size on x86 is 4K, there's no way to be sure that malloc() will return any more than 4K of contiguously mapped space. (I'm not even sure why I can even get 16K.) So: is there some way to allocate 64K of contiguous memory? Or even 8/16/32K? As long as I can hit one of the allowed buffer sizes I'll be happy, although I wanted 64K in order to reduce the likelyhood of receiver overruns. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message