On Mon, 2008-01-28 at 17:47 -0800, Dan Thurman wrote:
> On Monday 28 January 2008 03:32:16 pm Rick Stevens wrote:
> > 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
> >
> > Was that the output of "modinfo attansic" or something from the source?
> > Seems rather, uh, verbose for a modinfo listing.
>
> No, the above list was taken from the man pages. Here is the modinfo:
>
> + modinfo atl2
> filename: /lib/modules/2.6.23.14-107.fc8/kernel/drivers/net/atl2/atl2.ko
> version: 1.0.40.2
> license: GPL
> description: Attansic 100M Ethernet Network Driver
> author: Attansic Corporation, <xiong_huang@xxxxxxxxxxxx>
> srcversion: D8048A65425274B2609FDD5
> alias: pci:v00001969d00002048sv*sd*bc*sc*i*
> depends:
> vermagic: 2.6.23.14-107.fc8 SMP mod_unload 686 4KSTACKS
> parm: TxMemSize:Bytes of Transmit Memory (array of int)
> parm: RxMemBlock:Number of receive memory block (array of int)
> parm: MediaType:MediaType Select (array of int)
> parm: IntModTimer:Interrupt Moderator Timer (array of int)
> parm: FlashVendor:SPI Flash Vendor (array of int)
> parm: copybreak:Maximum size of packet that is copied to a new
> buffer on receive (uint)
Ok, that's weird. Both of them indicate the same thing. The
"MediaType" option sure as heck doesn't sound like a wireless thing.
I've yet to see a wireless that can do 100Mbps. That's a 100Base-T
(wired) type of thing. I suspect this ain't the right driver for your
card (driver appears to be for a hard wired NIC, not a wireless).
----------------------------------------------------------------------
- Rick Stevens, Principal Engineer rstevens@xxxxxxxxxxxx -
- CDN Systems, Internap, Inc. http://www.internap.com -
- -
- Okay, who put a "stop payment" on my reality check? -
----------------------------------------------------------------------
