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