On Sunday 04 November 2007 23:53:57 Sarton O'Brien wrote:
> On Mon, 5 Nov 2007 08:24:54 am Marcin Michal Jessa wrote:
> > Hi guys.
> >
> > I have a Dell Latitude D620 with Broadcom BCM5752 nic which does not
> > work on 4.0RC2, RC3 and CURRENT.
> > By not working I mean it does not receive or send any traffic. I can
> > assign IP to the interface but I cannot even ping it locally.
> >
> > On 3.1 the driver works fine with GENERIC install kernel where it uses
> > ukphy:
> > ukphy0 at bge0 phy 1: Generic IEEE 802.3u media interface
> > ukphy0: OUI 0x001018, model 0x0010, rev. 0
> > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
> > 1000baseT-FDX, auto
> >
> > on 4.0 RC2 and RC3 and CURRENT it uses brgphy and does not work giving
> > following messages:
> > bge0: watchdog timeout - resetting
> > bge0: block failed to stop: reg 0x1400, bit 0x00000002
> >
> > I compiled my kernel disabling brgphy hoping to make it work like with
> > 3.1 but it unfortunately did not.
> > The output of dmesg reported following:
> > ukphy0 at bge0 phy 1: Generic IEEE 802.3u media interface
> > ukphy0: BCM5752 1000BASE-T media interface (OUI 0x001018, model 0x0010),
> > rev. 0
> > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
> > 1000baseT-FDX, auto
> >
> > Any ideas/fixes?
>
> The bge driver has seen quite few revisions in the last 6 months with
> varied reports of it working for some and not working for others.
>
> It may be worth while providing the entire dmesg under current.
>
> I have:
>
> pci4 at ppb3 bus 4ppb3: added to list as bus 4
>
> pci4: i/o space, memory space enabled
> bge0 at pci4 dev 0 function 0: Broadcom BCM5754 Gigabit Ethernet
> ioapic0: int17 1a9a8<vector=a8,delmode=1,logical,actlo,level,masked,dest=0>
> 3000000<target=3>
> bge0: interrupting at ioapic0 pin 17, event channel 3
> bge0: ASIC BCM5754/5787 A2 (0xb002), Ethernet address 00:13:72:39:7e:e3
> bge0: setting short Tx thresholds
> brgphy0 at bge0 phy 1: BCM5754/5787 1000BASE-T media interface, rev. 0
> brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
> 1000baseT-FDX, auto
> uhci0 at pci0 dev 29 function 0: Intel 82801GB/GR USB UHCI Controller (rev.
> 0x01)
>
> On a dell sc440 with:
>
> NetBSD xen.cre.local 4.99.33 NetBSD 4.99.33 (XEN3_DOM0) #0: Sun Oct 14
> 00:49:25 EST 2007
> root@gogeta2.internal:/usr/obj/sys/arch/i386/compile/XEN3_DOM0 i386
>
> Which previously didn't work ... and may still not .... best to test now I
> suppose ...
>
> OK, it appears to be working but I'm sure when I configured a bridge and
> added the interface it was not responding, hence the reason I am still
> using an rtk0.
>
> I'll try and test it further and if possible install the latest kernel but
> without putting it under load it appears to work. I know it's a different
> model but the entire BCM5x series has had issues so hopefully there isn't
> much left to tie up. With any luck, this info, combined with your dmesg
> output may aide someone in identifying the issue.
>
> Also, just to note ... ioapic, acpi and smp can be buggy on a variety of
> late model systems ... assuming you are using a generic.mp kernel,
> disabling some may assist but I'd say ioapic is required based on my dmesg.
>
> Sarton


It seems like ACPI was the cause of the evil. My nic worked again when I 
booted kernel with ACPI disabled in it.
Do you still need my dmesgs ? I have one for 3.1, one for 4.0RC3 with 
acpi enabled and one with working current.

Marcin.

-- 
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115), 
10);'