Re: Call for bfe(4) testers.

On Sun, 03.08.2008 at 17:17:30 +0900, Pyun YongHyeon wrote:
> On Sat, Aug 02, 2008 at 11:28:30AM +0200, Ulrich Spoerlein wrote:
> > On Wed, 30.07.2008 at 20:34:49 +0900, Pyun YongHyeon wrote:
> > > If you have one of bfe(4) hardwares please give it try and let me
> > > know how it goes. The latest bfe(4) can be found at the following
> > > URL.
> > > http://people.freebsd.org/~yongari/bfe/if_bfe.c
> > > http://people.freebsd.org/~yongari/bfe/if_bfereg.h
> > 
> > Hi Pyun,
> > 
> > I recompiled a fresh RELENG_7 kernel with the files above, and it led to
> > a panic, shortly after the system was up. I can't provide you with a
> > dump for now, but here's the handwritten backtrace:
> > 
> > last dmesg: no toe capability of 0xc421d800
> > trace:
> >         device_is_attached
> >         cf_set_method
> >         cpufreq_curr_sysctl
> >         sysctl_root
> >         userland_sysctl
> > 
> 
> I can't reproduce this and the backtrace does not seem to be
> related with bfe(4). Did bfe(40 spew some error messages?

Not directly, there are lots of

no toe capability on 0xc422b000
no toe capability on 0xc422b000
no toe capability on 0xc40abc00
no toe capability on 0xc422b000
no toe capability on 0xc40abc00
no toe capability on 0xc422b000
no toe capability on 0xc40abc00
no toe capability on 0xc422b000
no toe capability on 0xc40abc00
no toe capability on 0xc422b000
no toe capability on 0xc40abc00
no toe capability on 0xc40abc00

messages, but they don't seem the culprit. The stats sysctl also works
fine, here's a sample output:
bfe0 statistics:
Transmit good octets : 202779
Transmit good frames : 1884
Transmit octets : 202779
Transmit frames : 1884
Transmit broadcast frames : 4
Transmit multicast frames : 4
Transmit frames 64 bytes : 28
Transmit frames 65 to 127 bytes : 1741
Transmit frames 128 to 255 bytes : 63
Transmit frames 256 to 511 bytes : 52
Transmit frames 512 to 1023 bytes : 0
Transmit frames 1024 to max bytes : 0
Transmit jabber errors : 0
Transmit oversized frames : 0
Transmit fragmented frames : 0
Transmit underruns : 0
Transmit total collisions : 0
Transmit single collisions : 0
Transmit multiple collisions : 0
Transmit excess collisions : 0
Transmit late collisions : 0
Transmit deferrals : 0
Transmit carrier losts : 0
Transmit pause frames : 0
Receive good octets : 210840
Receive good frames : 1465
Receive octets : 210840
Receive frames : 1465
Receive broadcast frames : 0
Receive multicast frames : 0
Receive frames 64 bytes : 1
Receive frames 65 to 127 bytes : 1289
Receive frames 128 to 255 bytes : 122
Receive frames 256 to 511 bytes : 17
Receive frames 512 to 1023 bytes : 0
Receive frames 1024 to max bytes : 36
Receive jabber errors : 0
Receive oversized frames : 0
Receive fragmented frames : 0
Receive missed frames : 0
Receive CRC align errors : 0
Receive undersized frames : 0
Receive CRC errors : 0
Receive align errors : 0
Receive symbol errors : 0
Receive pause frames : 0
Receive control frames : 0

I have this device:
dev.bfe.0.%desc: Broadcom BCM4401 Fast Ethernet
dev.bfe.0.%driver: bfe
dev.bfe.0.%location: slot=0 function=0
dev.bfe.0.%pnpinfo: vendor=0x14e4 device=0x4401 subvendor=0x1028 subdevice=0x8127 class=0x020000
dev.bfe.0.%parent: pci2
dev.miibus.0.%parent: bfe0


bfe(4) even works for some minutes, then the machine panics because of
powerd(8) (????)

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x38
fault code              = supervisor read, page not present
instruction pointer     = 0x20:0xc058ec16
stack pointer           = 0x28:0xfb7b6ac8
frame pointer           = 0x28:0xfb7b6ac8
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 1327 (powerd)

(the backtrace didn't make it into the text minidump)

> > If you need more info, I'll crash the machine again, I'm also happy to
> > test further patches.
> 
> Would you enable DDB/KDB in kernel get a backtrace again?

I should have set this up correctly now, but I think the issue is
somewhere else. I'll recompile a clean kernel and test this one first.

Cheers,
Ulrich Spoerlein
-- 
It is better to remain silent and be thought a fool,
than to speak, and remove all doubt.