Hi Jeff,
Yes it's me again, the one-and-only guy who needs to do an ifconfig down/up
cycle to get his Broadcom BCM5702 Gigabit Ethernet (rev 02) chip to work after
every reboot. (ASUS A7V8X mobo)
I just downloaded, compiled, and installed the current driver from Broadcom's
website (bcm5700-7.1.22.tar.gz) and it WORKS! On the first try...
I admit this is the first time I've attempted this, so I can't say what exactly
fixed this long-standing bug, or when it was fixed by Broadcom.
I'm sorry I don't have the expertise to debug this problem by myself, but I
would be more than pleased to try any experiments you can think of in order
to get this annoying bug fixed.
Can you suggest any tests or patches I could try in order to fix the current
tg3 driver? It's been almost a year now that I've been dealing with this
silly bug! Any help would be gratefully received!
Thanks.
David S. Miller wrote:
> On Tue, 16 Mar 2004 15:21:40 -0800
> walt <[email protected]> wrote:
>
>
>>...this is the first time I've tried the driver from Broadcom, so I can't
>> tell you when it was fixed...
>
>
> The current driver in the current 2.4.x and 2.6.x pre-release trees should
> have this bug fixed in the tg3 driver.
I admit I seem to be the only one still complaining, so I suspect I must have
a mobo with a rare chip type. The bug is definitely *not* fixed for me, as of
today's latests changesets from Linus.
The problem lies in the way the chip is initialized on bootup, clearly, because
doing ifconfig down/up changes a few bytes of memory and starts things working
until the next reboot.
Here is a before/after diff of lspci -xxx. You can see that byte 0x94 has been
reset by the ifconfig down/up:
#diff before after
83,89c83,89
< 90: 09 02 00 01 01 00 00 00 00 00 00 00 c8 00 00 00
< a0: 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00
< b0: 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00
< c0: 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00
< d0: 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00
< e0: 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00
< f0: 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00
---
> 90: 09 02 00 01 00 00 00 00 00 00 00 00 c8 00 00 00
> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
I wish I had the expertise to figure out what code is responsible
for resetting that bit, but alas I don't.
If you could give me even a hint of what sections of the tg3 code
to look at I might be able to pick it up from there -- e.g. what
part of the driver code would be exercised by 'ifconfig down' that
isn't done by the 'ifconfig up' at bootup.
Hmmm, I think the common denominator is that all the people still
seeing this problem have 5704 chips. I'll look into this... thanks.
David S. Miller wrote:
> Hmmm, I think the common denominator is that all the people still
> seeing this problem have 5704 chips...
Well, not quite all -- mine is a 5702 rev2 ;-)
> I'll look into this... thanks.
And thanks to you, too. If I can test patches or do any debugging please
let me know.
I have a similar problem with 5704 rev 3 where I need to transmit
something over the card before it wakes up after boot.
looking at the traffic light, I see lots of traffic during the boot, until
the driver initializes, at which time nothing is received until I initiate
traffic out the card.
David Lang
On Wed, 17 Mar 2004, walt wrote:
> Date: Wed, 17 Mar 2004 15:14:17 -0800
> From: walt <[email protected]>
> To: David S. Miller <[email protected]>
> Cc: [email protected], [email protected]
> Subject: Re: Broadcom gigabit solution for Jeff.
>
> David S. Miller wrote:
> > Hmmm, I think the common denominator is that all the people still
> > seeing this problem have 5704 chips...
>
> Well, not quite all -- mine is a 5702 rev2 ;-)
>
>
> > I'll look into this... thanks.
>
> And thanks to you, too. If I can test patches or do any debugging please
> let me know.
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan