Subject: Re: if_mec stability on O2
To: Martin Husemann <martin@NetBSD.org>
From: Jared D. McNeill <jmcneill@invisible.ca>
List: port-sgimips
Date: 04/14/2007 08:56:41
On 14-Apr-07, at 7:29 AM, Martin Husemann wrote:

> On Wed, Apr 11, 2007 at 07:56:52AM -0400, Jared D. McNeill wrote:
>> This is when the real problem started happening -- I can't seem to
>> bring the mec interface up. I get a strange semi-hang from doing  
>> this:
>>
>> 	o2# ifconfig mec0 up
>> 	o2# ifconfig mec0 inet 192.168.10.20 netmask 255.255.255.0
>> 	<semi-hang>
>>
>> I call it a semi-hang because the keyboard still emits characters to
>> the screen etc, but I can't for example switch virtual consoles,
>> enter DDB, or ^C ifconfig.
>
> Ok, I see the same for -current, but not with a kernel from some time
> last week.

There's a comment in an #if 0'd section of mace.c that sounds like a  
good clue:

	/*
	 * There's something deeply wrong with the alloc() routine -- it
	 * returns a pointer to memory that is used by the kernel i/o
	 * buffers.  Disable for now.
	 */

	if ((bus_dmamem_alloc(sc->dmat, 32768, PAGE_SIZE, 32768,
	    &sc->seg, 1, &sc->nsegs, BUS_DMA_NOWAIT)) != 0) {
		printf(": unable to allocate DMA memory\n");
		return;
	}

If that's the case, maybe it's a fluke that if_mec ever worked? Since  
crmfb attaches earlier, it would be forcing if_mec to a different  
spot in the i/o buffer region... Do you see the same if_mec behaviour  
with a serial console and today's -current?

Cheers,
Jared