onboard NIC: Attansic L2

[Les]

On Mon, 2008-01-28 at 15:01 -0800, Dan Thurman wrote:
> On Monday 28 January 2008 01:54:16 pm Rick Stevens wrote:
> > On Mon, 2008-01-28 at 13:07 -0800, Dan Thurman wrote:
> > > Folks,
> > >
> > > Motherboard: P5GC-MX/1333,  onboard Attansic L2 NIC chip
> > >
> > > Earlier I reported a nightmarish experience trying to get my onboard
> > > Attansic L2 NIC working after compiling the source code for it,
> > > installing it, and so on and could not figure out why the NIC was not
> > > turning on the phyiscal link.
> > >
> > > I think I understand the symptoms but not the underlying cause.
> > >
> > > I reported in my earlier post, that I blamed the twisted pair cable but
> > > it turns out this was not the problem.  The cabled is fine.  I had to go
> > > to my garbage can to retrieve the cable I almost threw out.
> > >
> > > I can repeatedly prove (at least to myself), that under a multiboot
> > > situation, if you boot using w2000/XP, M$ turns ON/OFF/ON the link when
> > > coming up and when it is shutdown/rebooted, it disables the link.  It
> > > somehow turns the NIC OFF on reboot/shutdown.
> > >
> > > When you bootup Fedora, Fedora goes along as it normally does, probes
> > > eth0, but FAILS to turn ON the link.  You CANNOT get Fedora to bring up
> > > the link no matter what you do. The ONLY way to get the link back is to
> > > physically power off the power supply because the motherboard always
> > > get's it's power unless the PS itself is turned off and until the power
> > > drains out.
> > >
> > > Only then, you can bring up Fedora's OS and get the NIC link to work.
> > >
> > > I wonder if M$ plugs microcode into the Attansic L2 chip that renders
> > > Fedora unable to turn on the link OR the code is missing from the Fedora
> > > networking process to turn ON the link.
> > >
> > > Can someone in development look into this and let me know what is going
> > > on?
> > >
> > > At the moment, I have a temporary solution for now but I'd like to make
> > > sure no other helpless chap faces this problem like I did for weeks
> > > trying to figure this out.
> >
> > Does "iwconfig wlan0 txpower on" turn on your card?  Is there a modprobe
> > option you need?  "modinfo name-of-driver" should show you those.  On my
> > iwl4965, there's an option:
> >         options iwl4965 disable=1
> > which would turn off the radio.  By default it's on ("disable=0").
> > Perhaps yours is backwards?
> 
> Thanks for responding.
> 
> The following are the only published options available and none of them sets 
> the link on or off as far as I can tell.  I will try options atl2 MediaType=0
> and see if this helps.  The NIC is not a wireless NIC so that won't work for 
> me.
> 
> Attansic L2 Options:
> ============
> MediaType
> Valid Range: 0-4
> 	0    - auto-negotiate at all supported speeds
> 	1    - only link at 100Mbps Full Duplex
> 	2    - only link at 100Mbps Half Duplex
> 	3    - only link at 10Mbps Full Duplex
> 	4    - only link at 10Mbps Half Duplex
> Default Value: 0
>     MediaType forces the line speed/duplex to the specified value in 
>     megabits per second(Mbps). If this parameter is not specified or is set 
>     to 0 and the link partner is set to auto-negotiate, the board will 
>     auto-detect the correct speed. 
> 
> IntModTimer
> Valid Range: 50-65000
> Default Value: 100
>     This value represents the minmum interval between interrupts controller 
>     generated. 
> 
> RxMemBlock
> Valid Range: 16-512 
> Default Value: 64
>     This value is the number of receice memory block allocated by the driver. 
>     Increasing this value allows the driver to buffer more incoming packets. 
>     Each memory block is 1536 bytes.
> 
>     NOTE: Depending on the available system resources, the request for a
>     higher number of receive descriptors may be denied.  In this case,
>     use a lower number.
> 
> TxMemSize
> Valid Range: 4-64
> Default Value: 8
>     This value is the number KB of transmit memory allocated by the driver. 
>     Increasing this value allows the driver to queue more transmits.
> 
>     NOTE: Depending on the available system resources, the request for a
>     higher number of transmit descriptors may be denied.  In this case,
>     use a lower number.
> 
> FlashVendor
> Valid Range: 0-2
> Default Value: 0
>     This value standards on vendor of spi flash used by the adapter.
>     0 for Atmel, 1 for SST, 2 for ST
> 
Hi, Dan,
	Some hardware has the clock bit for latching registers in the same word
as the power bit.  This results in some devices requiring that
particular register to be written with the desired action (on or off)
and then written again to flop the clocking bit.  I suspect from your
description that the software writer for Microsoft discovered that for
your particular hardware and that would explain the action you see.
However I cannot confirm that, and most likely the specs for the chip
would not include that detail without a great deal of interpolation of
the description or "typical use software" that most vendors supply to
the OEM's.  In fact you and I may not even be able to access the low
level spec, because the companies treat these things as trade secrets
and proprietary information, since knowing the registers and operating
sequences give one a good idea of the internal organization of the
parts, and that is competitive information in the high tech world.

	What I am saying is that the Great Satan is probably not the reason for
the behavior you are seeing.

Regards,
Les H