At 5:35 PM -0500 12/5/04, Tim Kelly wrote:
>I'm not sure if the am79c950.c routines were
>getting picked up or the caller was just bailing. In any event, I recall
>that there was a problem on early PCI Macs that the AAUI connector had
>priority over the 10BaseT connection, so if either IFM_MANUAL was used or
>the media change routine wasn't properly linked, the chip probably
>defaulted to AAUI. I made the API match on the two routines and made the
>default be 10BaseT. I left the old stuff in and put the new stuff inside
>#ifdef IFM, so you can test before and after.

Well, since this kept bothering me, and since I'm a bit spooked from seeing
traffic on sip*, I'm going back and dotting my t's and crossing my i's. I'm
not sure exactly what the real fix is, but I can say that it works.

With GENERIC, if I specify the media type (10BaseT) in /etc/ifconfig.mc0,
the interface is sluggish. If I undo my patch via commenting out IFM, and
leave 10BaseT in /etc/ifconfig.mc0, the interface is sluggish. In both
cases, I get the ifconfig: SIOCSIFMEDIA: Invalid argument message. However,
if I then ifconfig manually without specifying the media type on my MP
kernel with everything else I've done except the mc patch, the interface
comes up just fine. If I do this with GENERIC, there is no difference. If I
boot without the media 10BaseT argument in /etc/ifconfig.mc0, in neither
case does manually bringing up the interface work.

If I boot my MP kernel and whether I specify 10BaseT or not, it comes up
just fine, and because of how I set the default, it comes up 10BaseT when
it is not specified.

I think the problem has something to do with how the am79c950.c code
initializes the chip when the media type is invalid. With the patch I
posted, the media change and status routines are ensured they are the ones
already in if_mc.c, and it seems to work. I just can't specifically
identify the exact difference. If this patch fails to fix other mc*
devices, please let me know.

thanks,
tim