Date: Sun, 3 Aug 2008 12:56:27 +0200 From: Ulrich Spoerlein <uspoerlein@gmail.com> To: Pyun YongHyeon <pyunyh@gmail.com> Cc: freebsd-current@FreeBSD.org Subject: Re: Call for bfe(4) testers. Message-ID: <20080803105627.GD1555@roadrunner.spoerlein.net> In-Reply-To: <20080803081730.GA18731@cdnetworks.co.kr> References: <20080730113449.GD407@cdnetworks.co.kr> <20080802092830.GA1552@roadrunner.spoerlein.net> <20080803081730.GA18731@cdnetworks.co.kr>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080803105627.GD1555>