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