# tg3 driver problem with kernel gentoo-sources 2.6.17-r7

## anovadea

Hi,

I've had this problem and it's been bugging me for ages. I have a Broadcom netxtreme 5702X gigabit ethernet controller, which works quite well. The gentoo livecd (2006.0) recognised it fine, and the livecd kernel is fine with it. 

When I compiled my own kernel, I did my research and found that the appropriate driver in the source appears to be tg3. So I compiled it in. The driver worked, except for one problem. It never releases the controller after it shuts down. As a result, if any OS tries to use that controller after that kernel's been using it (either after a cold boot or a warm reboot), the controller isn't available. I have tried the following steps to resolve the problem:

I tried compiling in acpi and apm.

I tried using the genkernel script in case it did anything different.

I tried compiling it as a module.

Checking against this post (which most accurately describes my problems). So I tried acpi=on in my grub.conf, and that failed.

I realise this is probably a trivial error on my part, but I just can't track it down (mainly because this is my first jump into 2.6 kernel land and some of the landscape's changed since 2.4). 

Some possibly relavent output:

lspci

```

00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge00:01.0 PCI bridge: VIA Technologies, Inc. VT8235 PCI Bridge

00:06.0 Mass storage controller: Promise Technology, Inc. PDC20718 (SATA 300 TX4) (rev 02)

00:07.0 Communication controller: Intel Corporation 536EP Data Fax Modem

00:0c.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10)

00:0d.0 RAID bus controller: Promise Technology, Inc. PDC20376 (FastTrak 376) (rev 02)

00:0e.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 46)

00:0f.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5702X Gigabit Ethernet (rev 02)

00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)

00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)

00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)

00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)

00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge

00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)

01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 MX 440] (rev a3)

```

Grub entry

```

title Gentoo Linux NewKernel

    root (hd1,0)

    kernel /kernel-genkernel-x86-2.6.17-gentoo-r7 root=/dev/ram0 init=/linuxrc ramdisk=8192 real_root=/dev/sda9 video=vesafb:ywrap,mtrr vga=794 softlevel=default-newkernel acpi=on

    initrd /initramfs-genkernel-x86-2.6.17-gentoo-r7

```

For the sake of brevity, I'm not putting up my kernel config file on this post, but I've put it on my webspace - http://anovadea.netsoc.com/gentoo/anovadea-kernel-2.6.17-r7-config

So, any glaring reason why the LiveCD version would work and mine wouldn't?

Edit: Also, let's say I experiment further on this, would I be better staying on the old kernel source, or should I upgrade? (i.e. which would probably be less messy for analysis?)

Thanks in advance,

AoifeLast edited by anovadea on Thu Nov 09, 2006 2:04 pm; edited 1 time in total

----------

## yabbadabbadont

I have the exact same controller, same revision even.  (on an ASUS A7V8X motherboard)  Since I currently only have Gentoo on my machine, I can't test to see if I have the same behavior.  However, it would explain problems that I had in the past when trying to install SuSE using their net-install CD.  If for any reason, it didn't detect the NIC when it booted, I would have to do a hard reboot to get it to work.  I could unload and reload the tg3 module without errors, but it just wouldn't work until I hit the reset button.  I'm sorry that I don't have any suggestions for you to try, but at least you know you are not alone.

----------

## anovadea

Thanks.

I think I have a test plan to see if I can whittle down the problem.

Problem is, I need to ask a few stupid questions:

Is the livecd kernel just a gentoo-sources kernel generated by genkernel?

By that I mean, are there any other patches applied?

Moreover, if I take /proc/config.gz and put it in /usr/src/linux and compiled my kernel using that config file, would it work turn out the same kernel (assuming the versions were the same)?

The reason I want to know is, I'm thinking of trying to build that livecd kernel again (which I know works) and then modify options to my tastes to see if it still works. If other patches are applied to the livecd, then I have a complication that I should be aware of.

Thanks for any help anyone can offer,

Aoife

----------

## anovadea

Extra information I gleaned over the weekend.

Problem still persists, but I've noticed some interesting features:

* With acpi=on in grub.conf, that kernel is able to access the nic if the computer is power cycled, but not if rebooted. All versions of linux (LiveCD, custome kernel and an OLD SuSE distro (2.4 based)) can use the card in this case.

* However, regardless of acpi setting, if I use that kernel and power cycle, windows can't use it afterwards, and requires a reboot - this does not happen with the 2006 LiveCD kernel or my old 2.4 distro.

For a while I thought it'd worked because I could use my custom kernel (which I prefer because I have alsa working on it) repeatedly, without needing a reboot to get my nic working, but windows still doesn't work (which isn't just for me - but for the rest of the family)

Does that suggest anything to anyone?

Thanks

Aoife

----------

## yabbadabbadont

I installed (and removed the same day) Debian testing a couple days ago.  I had the same issue with the nic.  I found that I don't have to actually poweroff the computer to reset the nic, I just had to hit the reset button once the system started to reboot.  When I did that, I noticed that the ethernet light on my DSL modem would go off and back on.  If I didn't hit the reset button, the light stayed on through a reboot and the nic wouldn't work.  It's not a solution, but it is quicker than having to power cycle the machine when your family needs to use windows.

----------

## anovadea

Hmm, it's looking more and more like it may be a regression in the kernel. But I have to look a bit closer in order to tell.

What I've done so far

I took the /proc/config.gz from the livecd kernel and plugged it into 2.6.17-r7 and while I got a booting/working kernel, I still had the same problem. (although I didn't need acpi=on for the kernel to be able to see the nic after a reboot from itself back to itself)

So, two kernel source trees and the same config, led to a regression.

My plan from here:

My next step is to get as close as I can to the kernel sources for the livecd build (I think the exact build is off the portage tree, which is unfortunate, so I can't EXACTLY reproduce the kernel), and then rebuild a clone of the livecd, and see if that works. If that doesn't work, it's head-scratching time (I'll be stumped), but if it does, it means that I have a known good that I can test from (because the precompiled kernel is a bit of a black box to me). I can then take my last kernel config (the one I'm fond of, where everything else works), and plug it into those sources and see if it works. If it does work, then I know it's not my config (mostly). 

Also, along side that, I'm going to test the vanilla sources of 2.6.17 to see if that works - in which case I can tell if the regression's in the patches. However I'm not holding up much hope of that, because Debian Testing (according to the package list on their site) runs 2.6.17, which would imply that if it's broken for you there, it's probably broken in the source.

Most of this is me "thinking out loud", but I reckon the process could be of use to people.

Aoife

----------

## MaxxTwayne

Just 5 min ago, i've talked to a friend who has this nic card.

And he told me used the bcm5700-8.3 driver because the tg3 sucked so much (on a RHES4).

hope this could help

----------

## anovadea

Cool. I'll keep that in mind. Any idea where I can find it? I checked broadcom's site (http://www.broadcom.com/support/ethernet_nic/netxtreme.php ), and it only seems to have tg3 drivers on there any more... even in the archive section where they say you can get the bcm5700 drivers.

Aoife

----------

## yabbadabbadont

 *anovadea wrote:*   

> Cool. I'll keep that in mind. Any idea where I can find it? I checked broadcom's site (http://www.broadcom.com/support/ethernet_nic/netxtreme.php ), and it only seems to have tg3 drivers on there any more... even in the archive section where they say you can get the bcm5700 drivers.
> 
> Aoife

 

I'll have to dig out my original motherboard drivers disc, but I know that it contained the linux drivers for the bcm5700.  What I'm not sure about is if they were only for 2.4 kernels...  I'll look and see.

The driver readme says that the source for the module had only been tested with kernels up to 2.4.18....  oh well.

Has anyone checked to see if a bug has been filed against the module wherever kernel bugs are filed?

----------

## anovadea

Re logging the bug: I've had a look, and nothing with tg3 in the title in the drivers section reflects the problem... I think. There are a few things about IRQ handling and the like, but I don't think it's that.

Personally, I'm reluctant to log the regression just yet, as I've not had a chance to test the vanilla sources myself. But once I do that (and also test the latest stable vanilla kernel (from kernel.org) just to see if it's still there, or has been fixed in the meantime) and have figured out roughly where the regression happened, then I'll log one if it's not already been done.

As for the BCM driver, I'm fairly sure there's one for 2.6 but from what I gather the landscape of 2.6 can change quite a lot. Sooo... I'm thinking I might just try and help people make tg3 better, rather than go to the BCM driver (which I can't find yet anyway).

Aoife

----------

## anovadea

Ok, I don't know if this warrants as solved - I've found that version 2.6.15-r1 works fine. I've since started using that.

I'm going to take the latest (stable) kernel from kernel.org and test that, and see if it passes or fails. If it passes, I'll not do anything (except to update this thread) or if it doesn't, I'll test the rc for the next stable release. And if that fails, I'll log a bug (or I might try .16 just in case - because I haven't tested that).

Regardless, a known good version is 2.6.15

Aoife

----------

