Call for bfe(4) testers.
Pyun YongHyeon
pyunyh at gmail.com
Mon Aug 4 01:04:17 UTC 2008
On Sun, Aug 03, 2008 at 12:56:27PM +0200, Ulrich Spoerlein wrote:
> 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
I think kmacy@ fixed this. Please update again.
> 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)
>
>From this and the fault address 0x38 above suggests cpufreq(4)
dereferenced a NULL pointer. It seems powered(4) tried to set CPU
frequency and encountered page fault. Full backtrace would be
great help.
> (the backtrace didn't make it into the text minidump)
Hmm, this looks different issue.
>
> > > 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.
>
I'm not familiar with cpufreq(4) but jhb@ may help you.
--
Regards,
Pyun YongHyeon
More information about the freebsd-current
mailing list