Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 12 Oct 2006 17:45:29 +0100
From:      Tom Judge <tom@tomjudge.com>
To:        Scott Long <scottl@samsco.org>
Cc:        stable@freebsd.org, davidch@broadcom.com, Bill Moran <wmoran@collaborativefusion.com>, netops@collaborativefusion.com, glebius@freebsd.org, kris@obsecurity.org
Subject:   Re: bce issues still outstanding
Message-ID:  <452E7129.2000105@tomjudge.com>
In-Reply-To: <452D0986.3020902@samsco.org>
References:  <20061011093139.df4b6fbf.wmoran@collaborativefusion.com> <452D0986.3020902@samsco.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Scott Long wrote:
> Bill Moran wrote:
>> I've copied many of the people who I've been working with directly on
>> this issue.
>>
>> Can anyone provide a status update on these problems?  Discussion seems
>> to have stopped since Oct 5.
>>
>> Any new patches to test?
>>
>
> I'm actively working on fixing the driver right now.
>
> Scott
>

If there are any patches you want testing I have 3 very expensive 
paperweights sat around the office at the moment in the form of Dell 
PE2950's with twin adapters in them:

bce0: <Broadcom NetXtreme II BCM5708 1000Base-T (B1), v0.9.6> mem 
0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci9
bce0: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz
miibus0: <MII bus> on bce0
brgphy0: <BCM5708C 10/100/1000baseTX PHY> on miibus0
brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 
1000baseTX-FDX, auto
bce0: Ethernet address: 00:13:72:60:35:8a


bce1: <Broadcom NetXtreme II BCM5708 1000Base-T (B1), v0.9.6> mem 
0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci5
bce1: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz
miibus1: <MII bus> on bce1
brgphy1: <BCM5708C 10/100/1000baseTX PHY> on miibus1
brgphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 
1000baseTX-FDX, auto
bce1: Ethernet address: 00:13:72:60:35:88

The easiest way to cause the watchdog time out on these systems is to 
write a file larger than 50Mb to an NFS file system that is mounted over 
UDP (TCP doesn't cause the time out strangely).  From the testing I have 
done the timeout is triggered when arround 49Mb has been copied to the 
NFS server. Perhaps this could suggest a bug in the udp packet checksum 
offload code?

I have 2 systems available to test on right now,  one running code from 
RELENG_6 just after beta2 was announced, and one cvsup'd from the uk 
mirror today.

The kernels are compiled with:

option INVARIANTS
option INVARIANT_SUPPORT

However this doesn't cause a kernel panic.

Let me know if you need any more information.

Tom



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?452E7129.2000105>