Re: New disk schedulers available for FreeBSD
On Mon, Jan 12, 2009 at 06:45:13PM -0800, Garrett Cooper wrote: > On Mon, Jan 12, 2009 at 2:00 PM, Luigi Rizzo wrote: > > Hi, > > Fabio Checconi and myself have developed a GEOM-based disk scheduler > > for FreeBSD. The scheduler is made of a GEOM kernel module, the > > corresponding userland claas library, and other loadable kernel > > modules that implement the actual scheduling algorithm. > > > > At the URL below you can find a tarball with full sources and > > also a set of pre-built modules/libraries for RELENG_7, to ease testing. > > > >http://feanor.sssup.it/~fabio/freebsd/io_sched/fc_sched.tar.gz > > > > Below you can find the README file that comes with the distribution. > > > > I would encourage people to try it and submit feedback, because the > > initial results are extremely interesting. While I just tried the > > code under RELENG_7/i386, it should build and work on all versions > > that have GEOM (but read below). > > Hi Luigi! > Is this changeset already available in CURRENT? no but the port above should hopefully build under -current as well, unless there are changes in the GEOM ABI. I built it on RELENG_7 and RELENG_6, will try HEAD today. cheers luigi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: zfs not exporting or unmounting
David Ehrmann wrote: # fstat -m /tank I guess I should have used a different flag, but no luck there, either USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME # lsof | grep tank I did fix it. I had a runaway bash process (that kill -s HUP fixed, oddly enough), but why don't any of these commands list the files I have open, even when files really are open? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: New disk schedulers available for FreeBSD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Garrett Cooper wrote: > On Mon, Jan 12, 2009 at 2:00 PM, Luigi Rizzo wrote: >> Hi, >> Fabio Checconi and myself have developed a GEOM-based disk scheduler >> for FreeBSD. The scheduler is made of a GEOM kernel module, the >> corresponding userland claas library, and other loadable kernel >> modules that implement the actual scheduling algorithm. >> >> At the URL below you can find a tarball with full sources and >> also a set of pre-built modules/libraries for RELENG_7, to ease testing. >> >>http://feanor.sssup.it/~fabio/freebsd/io_sched/fc_sched.tar.gz >> >> Below you can find the README file that comes with the distribution. >> >> I would encourage people to try it and submit feedback, because the >> initial results are extremely interesting. While I just tried the >> code under RELENG_7/i386, it should build and work on all versions >> that have GEOM (but read below). > > Hi Luigi! > Is this changeset already available in CURRENT? Not (yet). - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklsKz0ACgkQi+vbBBjt66A0oQCfaB3qBKF7QZ1lDMrSkHCmReUD Di4AoIBQgg/Pe8zKD6Y7TBZO3Mz4pqUj =pCBe -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
On Mon, Jan 12, 2009 at 05:37:39PM +0100, Dimitry Andric wrote:
> On 2009-01-12 07:41, Pyun YongHyeon wrote:
> > I see, Unfortunately the issue was fixed in the end of 7.1-R
> > release process so I wanted to get more exposure before MFC.
> > I'll make sure to MFC to stable/7 after more testing.
>
> I'm also having problems with re's, in my case the interfaces take about
> 10 seconds to come up, if they come up at all. After the interfaces are
> up, half the time no packets go out at all. Usually it helps to bring
> them down via the console, wait about 10 seconds, and then bring them up
> again...
>
It looks like that RTL8169SC users see regression and I vaguely
remember a couple of issues on RTL8169SC. As Jung-uk said in other
post, would yoy try reverting r180519? If that have no effect would
you try attached patch?
> These are the following variant:
>
> FreeBSD 7.1-STABLE #0: Mon Jan 12 14:22:11 CET 2009
> [...]
> re0: port 0xf000-0xf0ff
> mem 0xfdfff000-0xfdfff0ff irq 18 at device 9.0 on pci0
> re0: Chip rev. 0x1800
> re0: MAC rev. 0x
> miibus0: on re0
> rgephy0: PHY 1 on miibus0
> rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
> 1000baseT-FDX, auto
> re0: Ethernet address: 00:30:18:a6:f1:a8
> re0: [FILTER]
> re1: port 0xf200-0xf2ff
> mem 0xfdffe000-0xfdffe0ff irq 19 at device 11.0 on pci0
> re1: Chip rev. 0x1800
> re1: MAC rev. 0x
> miibus1: on re1
> rgephy1: PHY 1 on miibus1
> rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
> 1000baseT-FDX, auto
> re1: Ethernet address: 00:30:18:a6:f1:a9
> re1: [FILTER]
>
> And just FYI, r187080-r187083 that you recently committed (MFCs of
> r184240-184243, r184245, 185575 and r186390), don't seem to change
> anything for this situation. :(
Those MFC are for rl(4), not re(4) so you should see no behavioural
changes in re(4).
--
Regards,
Pyun YongHyeon
Index: sys/dev/re/if_re.c
===
--- sys/dev/re/if_re.c (revision 187123)
+++ sys/dev/re/if_re.c (working copy)
@@ -1295,6 +1295,8 @@
case RL_HWREV_8169_8110SC:
case RL_HWREV_8169_8110SBL:
sc->rl_flags |= RL_FLAG_PHYWAKE | RL_FLAG_PHY8169;
+ if (hw_rev->rl_rev == RL_HWREV_8169_8110SC)
+ sc->rl_flags |= 0x1;
break;
default:
break;
@@ -2504,6 +2506,7 @@
uint32_t align_dummy;
u_char eaddr[ETHER_ADDR_LEN];
} eaddr;
+ int clk66;
RL_LOCK_ASSERT(sc);
@@ -2534,6 +2537,29 @@
} else
cfg |= RL_CPLUSCMD_RXENB | RL_CPLUSCMD_TXENB;
CSR_WRITE_2(sc, RL_CPLUS_CMD, cfg);
+ if ((sc->rl_flags & 0x1) != 0) {
+ clk66 = (CSR_READ_1(sc, RL_CFG2) & RL_CFG2_PCI66MHZ) != 0;
+ switch (CSR_READ_4(sc, RL_TXCFG) & 0xFC80) {
+ case 0x1800:
+ /* 8169/8110SCd */
+ if (clk66 > 0)
+CSR_WRITE_4(sc, 0x7C, 0x000F);
+ else
+CSR_WRITE_4(sc, 0x7C, 0x009F);
+ break;
+ case 0x9800:
+ /* 8169/8110SCe */
+ if (clk66 > 0)
+CSR_WRITE_4(sc, 0x7C, 0x000FFF00);
+ else
+CSR_WRITE_4(sc, 0x7C, 0x009FFF00);
+ break;
+ default:
+ break;
+ }
+ /* Disable interrupt mitigation. */
+ CSR_WRITE_2(sc, 0xE2, 0);
+ }
/*
* Disable TSO if interface MTU size is greater than MSS
* allowed in controller.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
zfs not exporting or unmounting
I tried to export/unmount my zpool: # zpool export tank cannot unmount '/tank': Device busy # zfs unmount /tank cannot unmount '/tank': Device busy but it wouldn't, so, after closing everything that could be using it, I tried again. No luck. Then I tried to see if I forgot something: # fstat -m /tank USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME # lsof | grep tank I'm out of ideas. zpool export -f tank worked last time, but at the expense of taking down one drive in the mirror (it shouldn't have, but it did; I had to resilver it). The one thing: I just did freebsd-update upgrade -r 7.1-RELEASE, and possibly freebsd-update install. Thanks in advance. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: New disk schedulers available for FreeBSD
On Mon, Jan 12, 2009 at 2:00 PM, Luigi Rizzo wrote: > Hi, > Fabio Checconi and myself have developed a GEOM-based disk scheduler > for FreeBSD. The scheduler is made of a GEOM kernel module, the > corresponding userland claas library, and other loadable kernel > modules that implement the actual scheduling algorithm. > > At the URL below you can find a tarball with full sources and > also a set of pre-built modules/libraries for RELENG_7, to ease testing. > >http://feanor.sssup.it/~fabio/freebsd/io_sched/fc_sched.tar.gz > > Below you can find the README file that comes with the distribution. > > I would encourage people to try it and submit feedback, because the > initial results are extremely interesting. While I just tried the > code under RELENG_7/i386, it should build and work on all versions > that have GEOM (but read below). Hi Luigi! Is this changeset already available in CURRENT? Thanks, -Garrett ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[releng_7 tinderbox] failure on sparc64/sparc64
TB --- 2009-01-13 00:31:07 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-01-13 00:31:07 - starting RELENG_7 tinderbox run for sparc64/sparc64 TB --- 2009-01-13 00:31:07 - cleaning the object tree TB --- 2009-01-13 00:31:22 - cvsupping the source tree TB --- 2009-01-13 00:31:22 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/sparc64/sparc64/supfile TB --- 2009-01-13 00:31:32 - building world TB --- 2009-01-13 00:31:32 - MAKEOBJDIRPREFIX=/obj TB --- 2009-01-13 00:31:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-01-13 00:31:32 - TARGET=sparc64 TB --- 2009-01-13 00:31:32 - TARGET_ARCH=sparc64 TB --- 2009-01-13 00:31:32 - TZ=UTC TB --- 2009-01-13 00:31:32 - __MAKE_CONF=/dev/null TB --- 2009-01-13 00:31:32 - cd /src TB --- 2009-01-13 00:31:32 - /usr/bin/make -B buildworld >>> World build started on Tue Jan 13 00:31:34 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jan 13 01:30:14 UTC 2009 TB --- 2009-01-13 01:30:14 - generating LINT kernel config TB --- 2009-01-13 01:30:14 - cd /src/sys/sparc64/conf TB --- 2009-01-13 01:30:14 - /usr/bin/make -B LINT TB --- 2009-01-13 01:30:15 - building LINT kernel TB --- 2009-01-13 01:30:15 - MAKEOBJDIRPREFIX=/obj TB --- 2009-01-13 01:30:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-01-13 01:30:15 - TARGET=sparc64 TB --- 2009-01-13 01:30:15 - TARGET_ARCH=sparc64 TB --- 2009-01-13 01:30:15 - TZ=UTC TB --- 2009-01-13 01:30:15 - __MAKE_CONF=/dev/null TB --- 2009-01-13 01:30:15 - cd /src TB --- 2009-01-13 01:30:15 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jan 13 01:30:15 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/ata/ata_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror ata_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-all.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-card.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-chipset.c /src/sys/dev/ata/ata-chipset.c: In function 'ata_marvell_ident': /src/sys/dev/ata/ata-chipset.c:2558: error: 'MV_61XX' undeclared (first use in this function) /src/sys/dev/ata/ata-chipset.c:2558: error: (Each undeclared identifier is reported only once /src/sys/dev/ata/ata-chipset.c:2558: error: for each function it appears in.) *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-01-13 01:33:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-01-13 01:33:41 - ERROR: failed to build lint kernel TB --- 2009-01-13 0
Re: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
On Monday 12 January 2009 12:21 pm, Sascha Holzleiter wrote: > Walter Venable wrote: > > FreeBSD 7.1 upgrade broke my network access, machine is totally > > offline (powered-on and I can play inside it at the terminal, but > > absolutely 0 network access): > > This happened AFTER make kernel but BEFORE make installworld. I > > think this implies it's a kernel driver issue. > > Hi, > > i see similar problems with a re card: > > r...@pci0:4:7:0: class=0x02 card=0x816710ec chip=0x816710ec > rev=0x10 hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'RTL8169/8110 Family Gigabit Ethernet NIC' > class = network > subclass = ethernet > > After upgrading to 7.1-RELEASE (and also STABLE) the NIC doesn't > seem to receive any frames. I can see the DHCP Requests on the DHCP > Server but the DHCPOFFERS are never seen by the client with the re0 > device. After setting promiscious mode on the interface (i.e. by > tcpdump -ni re0) the interface begins to work fine. > > I've attached a complete dmesg output, but i think the detection > works fine, here the short version: > > re0: port > 0x9c00-0x9cff mem 0xdfdff000-0xdfdff0ff irq 20 at device 7.0 on > pci4 re0: Chip rev. 0x1800 > re0: MAC rev. 0x > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseT, 1000baseT-FDX, auto > re0: Ethernet address: 00:1a:92:35:29:fa > re0: [FILTER] Please revert SVN r180519 (or CVS r1.95.2.22) and try again: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/re/if_re.c.diff?r1=1.95.2.21;r2=1.95.2.22 Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
On Mon, Jan 12, 2009 at 05:11:02PM -0500, FreeBSD wrote: > Pyun YongHyeon a ?crit : > >On Sun, Jan 11, 2009 at 07:22:06PM +0300, Eugene Gladchenko wrote: > > > Walter, > > > > > > Thursday, January 8, 2009, 2:50:40 AM, you wrote: > > > > > > WV> Booting kernel.old, which is 7.0-RELEASE-p7 completely alleviates > > all > > > WV> problems. I believe this roundly confirms that this is a bug in the > > > WV> 7.1-RELEASE re kernel drivers. > > > > > > Does kern/130011 look similar? > > http://www.freebsd.org/cgi/query-pr.cgi?pr=130011 > > > >Do you have RTL8168C controller? If not, it's not related with > >Walter's issue as 7.0-RELEASE didn't have a support for RTL8168C. > > > > > > > > The re driver was really broken in 7.1-RC2 and the fix didn't get to > > 7.1-RELEASE. > > > >If you have re(4) issues, please provide more details such as > >dmesg output, way to reproduce the issue etc. > > > > Hi, > > I have the exact same card and the exact same problem as the PR you > mentionned. > > r...@pci0:3:0:0: class=0x02 card=0x02831028 chip=0x816810ec rev=0x02 > hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > class = network > subclass = ethernet > > > re0: Gigabit Ethernet> port 0xd800-0xd8ff mem > 0xfeaff000-0xfeaf,0xfdff-0xfdff irq 18 at device 0.0 on pci3 > re0: Chip rev. 0x3c00 > re0: MAC rev. 0x0040 > re0: PHY write failed > re0: PHY write failed > re0: MII without any phy! > device_attach: re0 attach returned 6 > > I tried to compile a new kernel with the latest version of the 3 files > listed in the PR: > src/sys/dev/re/if_re.c,v 1.147 2008/12/22 00:46:22 yongari > src/sys/pci/if_rl.c,v 1.170.2.10 2009/01/12 04:10:40 yongari > src/sys/pci/if_rlreg.h,v 1.67.2.16 2009/01/12 03:48:25 yongari > You need lastest if_rl.c and if_rlreg.h as well as if_re.c. > but I get the following error in buildworld: [...] -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: fsck_y_enable: suboptimal/odd?
Andriy Gapon wrote: To me it seems like fsck_y passes suboptimal flags to fsck, it doesn't have to examine each and every filesystem in fstab. I think think this is because it does a quick check first to see if it can run the fsck in background after boot into multi-user mode. If it cannot, then fsck exits and is re-run with fsck -y and runs in foreground mode. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[releng_7 tinderbox] failure on powerpc/powerpc
TB --- 2009-01-12 23:22:06 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-01-12 23:22:06 - starting RELENG_7 tinderbox run for powerpc/powerpc TB --- 2009-01-12 23:22:06 - cleaning the object tree TB --- 2009-01-12 23:22:27 - cvsupping the source tree TB --- 2009-01-12 23:22:27 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/powerpc/powerpc/supfile TB --- 2009-01-12 23:22:37 - building world TB --- 2009-01-12 23:22:37 - MAKEOBJDIRPREFIX=/obj TB --- 2009-01-12 23:22:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-01-12 23:22:37 - TARGET=powerpc TB --- 2009-01-12 23:22:37 - TARGET_ARCH=powerpc TB --- 2009-01-12 23:22:37 - TZ=UTC TB --- 2009-01-12 23:22:37 - __MAKE_CONF=/dev/null TB --- 2009-01-12 23:22:37 - cd /src TB --- 2009-01-12 23:22:37 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 12 23:22:39 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jan 13 00:27:57 UTC 2009 TB --- 2009-01-13 00:27:57 - generating LINT kernel config TB --- 2009-01-13 00:27:57 - cd /src/sys/powerpc/conf TB --- 2009-01-13 00:27:57 - /usr/bin/make -B LINT TB --- 2009-01-13 00:27:57 - building LINT kernel TB --- 2009-01-13 00:27:57 - MAKEOBJDIRPREFIX=/obj TB --- 2009-01-13 00:27:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-01-13 00:27:57 - TARGET=powerpc TB --- 2009-01-13 00:27:57 - TARGET_ARCH=powerpc TB --- 2009-01-13 00:27:57 - TZ=UTC TB --- 2009-01-13 00:27:57 - __MAKE_CONF=/dev/null TB --- 2009-01-13 00:27:57 - cd /src TB --- 2009-01-13 00:27:57 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jan 13 00:27:58 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/ata/ata_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror ata_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-all.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-card.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-chipset.c /src/sys/dev/ata/ata-chipset.c: In function 'ata_marvell_ident': /src/sys/dev/ata/ata-chipset.c:2558: error: 'MV_61XX' undeclared (first use in this function) /src/sys/dev/ata/ata-chipset.c:2558: error: (Each undeclared identifier is reported only once /src/sys/dev/ata/ata-chipset.c:2558: error: for each function it appears in.) *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-01-13 00:31:16 - WARNING: /usr/bin/make returned exit code
Re: ZFSv13 in RELENG7
Ivan Voras wrote: Andrew Snow wrote: Oliver Fromme wrote: On the other hand, 8-current seems to run quite stable at the moment; I have it running on a workstation for several weeks without problems. What date of CURRENT are you running? I tracked down crashes related to changes in SMBFS, but I am still experiencing almost weekly crashes such as machine running out of swap space in the middle of the night for no apparent reason.. Are you running rsync? Are the crashes happenning at about 3 am? (these two questions are unrelated) Yes, running lots of rsync. Also, yes, crashes have happened at night, not sure about 3am specifically, I've noticed more like 4am, 5am. But they always seem to happen when I'm not around. Most of our rsync processes happen at night starting from 7pm and running all night. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Big problems with 7.1 locking up :-(
On Mon, 12 Jan 2009, Garance A Drosihn wrote: He is not eager to do a whole lot of experiments to track down the problem, since this is happening on busy production machines and he can't afford to have a lot of downtime on them (especially now that the semester at RPI has started up). The systems have some large (2 TB) filesystems on them, and the lockups occur in high disk-I/O situations. He's seeing the problem on one system which is a dual CPU quad-core xeon, and another which is a 64 bit P4 with hyperthreading. The one thing in common between the two setups is that the boot drives + a 3ware controller (with its array of RAID disks) is moved from one machine to the other one: I think playing the combinatorics game on compile-time flags, kernel features, etc, is probably not the best way to go about debugging this. Instead, I'd debug this as a kernel hang by breaking into the debugger once it occurs, if possible, and ideally on a serial console. Often times hangs can be debugged looking solely at DDB output, or if possible, a crash dump. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Big problems with 7.1 locking up :-(
On Mon, 12 Jan 2009, Pete French wrote: I'm not sure if you've done this already, but the normal suggestions apply: have you compiled with INVARIANTS/WITNESS/DDB/KDB/BREAK_TO_DEBUGGER, and do any results / panics / etc result? Sometimes these debugging tools are able to convert hangs into panics, which gives us much more ability to debug them. OK, I have now had a machine hand again, with the correct debug options in the kernel. The screen looked like this when I went to restart it: http://toybox.twisted.org.uk/~pete/71_lor2.png It had not, however, dropped into any kind of debugger. Also there appear to me console messages after the lock order reversal - is that normal ? Lock order reversals are warnings of potential deadlock due to a lock cycle, but deadlocks may not actually result, either because it's a false positive (some locking construct that is deadlock free but involves lock cycles), or because a cycle didn't actually form. The message is suggestive, but if you have significant system activity after the message, then it may be unrelated. The machine did stay up for a signifanct amount of time before doing this. I notice that it is more or less identical to the one I posted whenI had WITNESS_KDB in the kernel too, so maybe those results arent entirely suprious after all ? Given it hasnt dropped to a debugger, is there anything else I can try ? Features like WITNESS and INVARIANTS may change the timing of the kernel making certain race conditions less likely; I'd run with them for a bit and see if you can reproduce the hang with them present, as they will make debugging the problem a lot easier, if it's possible. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Big problems with 7.1 locking up :-(
On Mon, 12 Jan 2009, Tomas Randa wrote: I have similar problems. The last "good" kernel I have from stable brach, october the 8. Then in next upgrade, I saw big problems with performance. I tried ULE, 4BSD etc, but nothing helps, only downgrading system back. Now I am trying 7.1-p1 and problems are here again. Mysql is waiting a lot of time with status "waiting for opening table" or "waiting for close tables" I have 32bit FreeBSD with PAE, 1x xeon 5420, supermicro motherboard, areca SATA controller. Could not be problem in "da" device for example? So far, this sounds like a different problem than the one others have been posting about, which involves full system freezes rather than specific processes wedging or responding poorly. I'd suggest starting by using "procstat -k" on the process ID to look at where specific threads are waiting in the kernel. Is it simply that MySQL is being unreasonably slow in certain situations, or does it actually entirely stop operating? If you're able to narrow down the date on the 7.x branch where the problem you're experiencing "begins", that would be most helpful. I'd suggest leaving your userspace on the 8th october, and sliding the kernel forward in a binary search until you've narrowed it down a bit. Obviously, this takes a bit of patience, but narrowing it down could be quite informative. Robert N M Watson Computer Laboratory University of Cambridge Thanks Tomas Randa Garance A Drosihn wrote: At 2:55 PM + 1/12/09, Robert Watson wrote: On Fri, 9 Jan 2009, Garance A Drosihn wrote: At 2:39 PM -0500 1/9/09, Robert Blayzor wrote: On Jan 8, 2009, at 8:58 PM, Pete French wrote: I have a number of HP 1U servers, all of which were running 7.0 perfectly happily. I have been testing 7.1 in it's various incarnations for the last couple of months on our test server and it has performed perfectly. I noticed a problem with 7.0 on a couple of Dell servers. [...] We've since then compiled the kernel under the BSD scheduler to rule that out, and so far so good. Since ULE is now default in 7.1 and not in 7.0, perhaps you can try that? FWIW, the other guy I know who is having this problem had already switched to using ULE under 7.0-release, and did not have any problems with it. So *his* problem was probably not related to SCHED_ULE, unless something has recently changed there. Turns out he hasn't reverted back to 7.0-release just yet, so he's going to try SCHED_4BSD and see if that helps his situation. Scheduler changes always come with some risk of exposing bugs that have existed in the code for a long time but never really manifested themselves. ULE is well shaken-out, having been under development for at least five years, but it is possible that some problems will become visible as a result of the switch. I would encourage people to stick with ULE, but if you're having a stability problem then experimenting with scheduler as a variable that could be triggering the problem may well be useful to help track down the bug. Just to followup on this: My friend did switch back to a 7.1 kernel with SCHED_4BSD, and he still ran into problems. The error messages weren't the same, but errors did happen in the same high disk-I/O situations as the lockup happened with SCHED_ULE. At this point he's fallen back to the 7.0-kernel that he had been running (which also has SCHED_ULE), and all the problems have gone away. So at the moment he's running with a 7.0-ish kernel and the 7.1-release userland, without the hanging problems. So the problem is something in the kernel, but it is *NOT* the scheduler (at least, not in his case). He is not eager to do a whole lot of experiments to track down the problem, since this is happening on busy production machines and he can't afford to have a lot of downtime on them (especially now that the semester at RPI has started up). The systems have some large (2 TB) filesystems on them, and the lockups occur in high disk-I/O situations. He's seeing the problem on one system which is a dual CPU quad-core xeon, and another which is a 64 bit P4 with hyperthreading. The one thing in common between the two setups is that the boot drives + a 3ware controller (with its array of RAID disks) is moved from one machine to the other one: "its a 3ware 9500 12 port model, the boot drive is connected to an ICH6 in IDE mode, and yes, I've run it in single, single with hyper threading, and 8 way mode. All 64 bit." We still have no idea where the problem really is. For all we know, someone spilled a Pepsi on it when he wasn't looking... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
Pyun YongHyeon a écrit : On Sun, Jan 11, 2009 at 07:22:06PM +0300, Eugene Gladchenko wrote: > Walter, > > Thursday, January 8, 2009, 2:50:40 AM, you wrote: > > WV> Booting kernel.old, which is 7.0-RELEASE-p7 completely alleviates all > WV> problems. I believe this roundly confirms that this is a bug in the > WV> 7.1-RELEASE re kernel drivers. > > Does kern/130011 look similar? http://www.freebsd.org/cgi/query-pr.cgi?pr=130011 Do you have RTL8168C controller? If not, it's not related with Walter's issue as 7.0-RELEASE didn't have a support for RTL8168C. > > The re driver was really broken in 7.1-RC2 and the fix didn't get to 7.1-RELEASE. If you have re(4) issues, please provide more details such as dmesg output, way to reproduce the issue etc. Hi, I have the exact same card and the exact same problem as the PR you mentionned. r...@pci0:3:0:0: class=0x02 card=0x02831028 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet re0: Gigabit Ethernet> port 0xd800-0xd8ff mem 0xfeaff000-0xfeaf,0xfdff-0xfdff irq 18 at device 0.0 on pci3 re0: Chip rev. 0x3c00 re0: MAC rev. 0x0040 re0: PHY write failed re0: PHY write failed re0: MII without any phy! device_attach: re0 attach returned 6 I tried to compile a new kernel with the latest version of the 3 files listed in the PR: src/sys/dev/re/if_re.c,v 1.147 2008/12/22 00:46:22 yongari src/sys/pci/if_rl.c,v 1.170.2.10 2009/01/12 04:10:40 yongari src/sys/pci/if_rlreg.h,v 1.67.2.16 2009/01/12 03:48:25 yongari but I get the following error in buildworld: cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /usr/src/sys/dev/re/if_re.c /usr/src/sys/dev/re/if_re.c: In function 're_miibus_statchg': /usr/src/sys/dev/re/if_re.c:594: error: 'RL_FLAG_FASTETHER' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c:594: error: (Each undeclared identifier is reported only once /usr/src/sys/dev/re/if_re.c:594: error: for each function it appears in.) /usr/src/sys/dev/re/if_re.c: In function 're_reset': /usr/src/sys/dev/re/if_re.c:703: error: 'RL_FLAG_PHY8169' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c:705: error: 'RL_FLAG_PHY8110S' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c: In function 're_attach': /usr/src/sys/dev/re/if_re.c:1160: error: 'RL_FLAG_PCIE' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c:1242: error: 'RL_FLAG_FASTETHER' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c:1245: error: 'RL_FLAG_PHY8110S' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c:1256: error: 'RL_FLAG_CMDSTOP' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c:1260: error: 'RL_FLAG_WOLRXENB' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c:1267: error: 'RL_FLAG_MACSLEEP' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c:1292: error: 'RL_FLAG_PHY8169' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c:1362: error: 'RL_MACDBG' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c:1363: error: 'RL_GPIO' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c: In function 're_int_task': /usr/src/sys/dev/re/if_re.c:2184: error: 'RL_FLAG_PCIE' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c: In function 're_stop': /usr/src/sys/dev/re/if_re.c:2908: error: 'RL_FLAG_CMDSTOP' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c:2909: error: 'RL_CMD_STOPREQ' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c: In function 're_resume': /usr/src/sys/dev/re/if_re.c:2989: error: 'RL_FLAG_MACSLEEP' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c:2990: error: 'RL_MACDBG' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c:2991: error: 'RL_GPIO' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c: In function 're_setwol': /usr/src/sys/dev/re/if_re.c:3050: error: 'RL_FLAG_MACSLEEP' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c:3051: error: 'RL_MACDBG' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c:3052: error: 'RL_GPIO' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c:3056: error: 'RL_FLAG_WOLRXENB' undeclared (first use in this function) *
New disk schedulers available for FreeBSD
Hi, Fabio Checconi and myself have developed a GEOM-based disk scheduler for FreeBSD. The scheduler is made of a GEOM kernel module, the corresponding userland claas library, and other loadable kernel modules that implement the actual scheduling algorithm. At the URL below you can find a tarball with full sources and also a set of pre-built modules/libraries for RELENG_7, to ease testing. http://feanor.sssup.it/~fabio/freebsd/io_sched/fc_sched.tar.gz Below you can find the README file that comes with the distribution. I would encourage people to try it and submit feedback, because the initial results are extremely interesting. While I just tried the code under RELENG_7/i386, it should build and work on all versions that have GEOM (but read below). Also the code is quite robust, because most of the difficult tasks (data moving, synchronization, etc.) are handled by GEOM, and the scheduler is only deciding which requests to serve and when. NOTE: The scheduler is designed to be distributed as a port, but it needs an extra field in 'struct bio' and a small change in function g_io_request() to work. Both changes are trivial but need a kernel rebuild. To try this code on AMD64 you do need to patch and rebuild the kernel. On i386, and purely to ease evaluation, we avoid the need for a kernel rebuild by patching one function in-memory (and patching it back when the module is unloaded). cheers luigi and fabio A copy of the README file follows: --- GEOM BASED DISK SCHEDULERS FOR FREEBSD --- This code contains a framework for GEOM-based disk schedulers and a couple of sample scheduling algorithms that use the framework and implement two forms of "anticipatory scheduling" (see below for more details). As a quick example of what this code can give you, try to run "dd", or "tar", or some other code with highly SEQUENTIAL access patterns, together with "cvs" or "cvsup" or other highly RANDOM access patterns (this is not a made-up example: it is pretty common for developers to have one or more apps doing random accesses, and others that do sequential accesses e.g., loading large binaries from disk, checking the integrity of tarballs, watching media streams and so on). These are the results we get on a local machine (AMD BE2400 dual core CPU, SATA 250GB disk): /mnt is a partition mounted on /dev/ad0s1f (or /dev/ad0-sched-s1f when used with the scheduler) cvs:cvs -d /mnt/home/ncvs-local update -Pd /mnt/ports dd-read:dd bs=128k of=/dev/null if=/dev/ad0 (or ad0-sched-) dd-writew dd bs=128k if=/dev/zero of=/mnt/largefile NO SCHEDULERRR SCHEDULER dd cvs dd cvs dd-read only72 MB/s 72 MB/s --- dd-write only 55 MB/s --- 55 MB/s --- dd-read+cvs 6 MB/s ok 30 MB/s ok dd-write+cvs55 MB/s slooow 14 MB/s ok As you can see, when a cvs is running concurrently with dd, the performance drops dramatically, and depending on read or write mode, one of the two is severely penalized. The use of the RR scheduler in this example makes the dd-reader go much faster when competing with cvs, and lets cvs progress when competing with a writer. To try it out: 1. PLEASE READ CAREFULLY THE FOLLOWING: To avoid the need to rebuild a kernel, and just for testing purposes, we implemented a hack which consists in patching one kernel function (g_io_request) so that it executes the marking of "bio's" (I/O requests). Also, the classification info is stored in a rarely used field of struct bio. See details in the file g_sched.c . At the moment the 'patch' hack is only for i386 kernels built with standard flags. For other configurations, you need to manually patch sys/geom/geom_io.c as indicated by the error message that you will get. If you don't like the above, don't run this code. Also note that these hacks are only for testing purpose. If this code ever goes in the tree, it will use the correct approach which is adding a field to 'struct bio' to store the classification info, and modify g_io_request() to call a function to initialize that field. 2. PLEASE MAKE SURE THAT THE DISK THAT YOU WILL BE USING FOR TESTS DOES NOT CONTAIN PRECIOUS DATA. This is experimental code and may fail, especially at this stage. 3. EXTRACT AND BUILD THE PROGRAMS A 'make install' in the directory should work (with root privs), or you can even try the binary modules. If you want to build the modules yourself, look at the Makefile. 4. LOAD THE MODULE, CREATE A GEOM NODE, RUN TESTS kldload gsched_rr # --- configure the scheduler on device ad0 geom sched create -a rr ad0 # -- now you will have entries /dev/ad0-sched- For tests you can do the same as i did above, i.e. run concurrent programs that access
Re: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
Pyun, I was able to perform a full source downgrade to 7.0 and all the problems went away. Curiously, re0 and re1 have reversed names -- what was re0 is now re1, and vice versa. I need my box to be up and working so I can't throw 7.1 on it again. If I can offer any data from 7.0, please let me know. On Wed, Jan 7, 2009 at 9:35 PM, Pyun YongHyeon wrote: > On Wed, Jan 07, 2009 at 09:20:05PM -0500, Walter Venable wrote: > > On Wed, Jan 7, 2009 at 8:50 PM, Pyun YongHyeon wrote: > > > Please show me full dmesg output. > > > > > > > Hi Pyun, > > I have attached the full dmesg output. > > Walter, I need dmesg output of 7.1-RELEASE. > > -- > Regards, > Pyun YongHyeon > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Big problems with 7.1 locking up :-(
> I have similar problems. The last "good" kernel I have from stable brach, > october the 8. Then in next upgrade, I saw big problems with performance. > I tried ULE, 4BSD etc, but nothing helps, only downgrading system back. > > Now I am trying 7.1-p1 and problems are here again. Mysql is waiting a lot > of time with status "waiting for opening table" or "waiting for close > tables" > > I have 32bit FreeBSD with PAE, 1x xeon 5420, supermicro motherboard, areca > SATA controller. Could not be problem in "da" device for example? It was mentioned previous in this thread that CPUTYPE could be an issue. Did you change this if you customized your kernel? -- regards Claus When lenity and cruelty play for a kingdom, the gentler gamester is the soonest winner. Shakespeare ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Big problems with 7.1 locking up :-(
Hello, I have similar problems. The last "good" kernel I have from stable brach, october the 8. Then in next upgrade, I saw big problems with performance. I tried ULE, 4BSD etc, but nothing helps, only downgrading system back. Now I am trying 7.1-p1 and problems are here again. Mysql is waiting a lot of time with status "waiting for opening table" or "waiting for close tables" I have 32bit FreeBSD with PAE, 1x xeon 5420, supermicro motherboard, areca SATA controller. Could not be problem in "da" device for example? Thanks Tomas Randa Garance A Drosihn wrote: At 2:55 PM + 1/12/09, Robert Watson wrote: On Fri, 9 Jan 2009, Garance A Drosihn wrote: At 2:39 PM -0500 1/9/09, Robert Blayzor wrote: On Jan 8, 2009, at 8:58 PM, Pete French wrote: I have a number of HP 1U servers, all of which were running 7.0 perfectly happily. I have been testing 7.1 in it's various incarnations for the last couple of months on our test server and it has performed perfectly. I noticed a problem with 7.0 on a couple of Dell servers. [...] We've since then compiled the kernel under the BSD scheduler to rule that out, and so far so good. Since ULE is now default in 7.1 and not in 7.0, perhaps you can try that? FWIW, the other guy I know who is having this problem had already switched to using ULE under 7.0-release, and did not have any problems with it. So *his* problem was probably not related to SCHED_ULE, unless something has recently changed there. Turns out he hasn't reverted back to 7.0-release just yet, so he's going to try SCHED_4BSD and see if that helps his situation. Scheduler changes always come with some risk of exposing bugs that have existed in the code for a long time but never really manifested themselves. ULE is well shaken-out, having been under development for at least five years, but it is possible that some problems will become visible as a result of the switch. I would encourage people to stick with ULE, but if you're having a stability problem then experimenting with scheduler as a variable that could be triggering the problem may well be useful to help track down the bug. Just to followup on this: My friend did switch back to a 7.1 kernel with SCHED_4BSD, and he still ran into problems. The error messages weren't the same, but errors did happen in the same high disk-I/O situations as the lockup happened with SCHED_ULE. At this point he's fallen back to the 7.0-kernel that he had been running (which also has SCHED_ULE), and all the problems have gone away. So at the moment he's running with a 7.0-ish kernel and the 7.1-release userland, without the hanging problems. So the problem is something in the kernel, but it is *NOT* the scheduler (at least, not in his case). He is not eager to do a whole lot of experiments to track down the problem, since this is happening on busy production machines and he can't afford to have a lot of downtime on them (especially now that the semester at RPI has started up). The systems have some large (2 TB) filesystems on them, and the lockups occur in high disk-I/O situations. He's seeing the problem on one system which is a dual CPU quad-core xeon, and another which is a 64 bit P4 with hyperthreading. The one thing in common between the two setups is that the boot drives + a 3ware controller (with its array of RAID disks) is moved from one machine to the other one: "its a 3ware 9500 12 port model, the boot drive is connected to an ICH6 in IDE mode, and yes, I've run it in single, single with hyper threading, and 8 way mode. All 64 bit." We still have no idea where the problem really is. For all we know, someone spilled a Pepsi on it when he wasn't looking... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: bwi: no DS tssi no OFDM tssi
On Mon, Jan 12, 2009 at 8:08 PM, Neal Hogan wrote: > I installed the firmware stuff from the dragonfly bwi(4) man page, yet I > have the same issue. Is there a way to tell whether the firmware they > provide supports my card? Like I said, I can locate my access point (and > others that are around) and ask for an IP . . . it seems as though I'm so > close. I'm fairly certain that I have all of the avliable bwi(4) bits > installed correctly. > > I dwonloaded and installed the driver and added *if_bwi_load="YES"* in my > loader.conf. I loaded the .ko file (bwi_v3). I downloaded and installed the > firmware from dflyBSD and followed their directions. Yet I get no offer. Is > the fact that I fail to get an offer indicate the firmware incompatinbility? 9 in BCM94306MP indicates that its supports 80211n and as such certainly it is not supported with bwi(4) and reason is that bwi developers do not plan to add support for 4 version firmware (when last time I played with bwi). > Anyway, thanks for you help. > > On Mon, Jan 12, 2009 at 12:32 PM, Paul B. Mahol wrote: >> >> On 1/12/09, Neal Hogan wrote: >> > Hello, >> > >> >I am attempting to get by broadcom wifi card up and running, am sick >> > of >> > trying to get ndis working, and am attempting to use the bwi driver >> > (originating in dragonflyBSD). I'm hoping others here have tried to do >> > the >> > same and have some pointers. I'm using 7.1-RELEASE (system/source are >> > in-sync) and my card is a BCM94306MP. My dmesg is posted below. >> > >> > Bwi(4) is installed and it recognizes my card (*if_bwi_load-"YES"* is in >> > my >> > /etc/rc.conf and *bwi_v3* and *if_bwi* are loaded). I can send a IP >> > request >> > to my WEP encrypted access point. Yet, it doesn't get an offer and says >> > that >> > *no DS tssi* and *no OFDM tssi* Being new to bwi(4) and have never seen >> > references to DS/OFDM tssi, I'm not sure what info to provide. My >> > research >> > is not leading anywhere helpful. Thanks. >> > >> > >> > >> > >> > Copyright (c) 1992-2009 The FreeBSD Project. >> > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> > The Regents of the University of California. All rights reserved. >> > FreeBSD is a registered trademark of The FreeBSD Foundation. >> > FreeBSD 7.1-RELEASE #0: Sat Jan 10 19:07:15 CST 2009 >> > n...@frege.lambdaserver:/usr/obj/usr/src/sys/GENERIC >> > Timecounter "i8254" frequency 1193182 Hz quality 0 >> > CPU: mobile AMD Athlon(tm) XP2400+ (1788.94-MHz 686-class CPU) >> > Origin = "AuthenticAMD" Id = 0x6a0 Stepping = 0 >> > >> > >> > Features=0x383f9ff >> > AMD Features=0xc0480800 >> > real memory = 468647936 (446 MB) >> > avail memory = 444530688 (423 MB) >> > kbd1 at kbdmux0 >> > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, >> > RF5413) >> > acpi0: on motherboard >> > acpi0: [ITHREAD] >> > acpi0: Power Button (fixed) >> > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 >> > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 >> > acpi_ec0: port 0x62,0x66 on acpi0 >> > pcib0: port 0xcf8-0xcff on acpi0 >> > pci_link5: BIOS IRQ 10 for 0.10.INTA is invalid >> > pci0: on pcib0 >> > agp0: on hostb0 >> > pcib1: at device 1.0 on pci0 >> > pci1: on pcib1 >> > vgapci0: port 0x9000-0x90ff mem >> > 0xe000-0xefff,0xd010-0xd010 irq 10 at device 5.0 on >> > pci1 >> > ohci0: mem >> > 0xd0006000-0xd0006fff irq 9 at device 2.0 on pci0 >> > ohci0: [GIANT-LOCKED] >> > ohci0: [ITHREAD] >> > usb0: OHCI version 1.0, legacy support >> > usb0: SMM does not respond, resetting >> > usb0: on ohci0 >> > usb0: USB revision 1.0 >> > uhub0: on >> > usb0 >> > uhub0: 4 ports with 4 removable, self powered >> > pcm0: port 0x8400-0x84ff mem 0xd0007000-0xd0007fff >> > irq 5 at device 6.0 on pci0 >> > pcm0: >> > pcm0: [GIANT-LOCKED] >> > pcm0: [ITHREAD] >> > isab0: at device 7.0 on pci0 >> > isa0: on isab0 >> > pci0: at device 8.0 (no driver attached) >> > bwi0: mem >> > 0xd0004000-0xd0005fff irq 9 at device 9.0 on pci0 >> > bwi0: [ITHREAD] >> > bwi0: regwin: chipcommon (0x800), rev 2, vendor 0x4243 >> > bwi0: BBP: id 0x4306, rev 0x2, pkg 0 >> > bwi0: nregwin 6, cap 0x002a >> > bwi0: regwin: 802.11 MAC (0x812), rev 4, vendor 0x4243 >> > bwi0: has TX stats >> > bwi0: MAC: rev 4 >> > bwi0: regwin: pcmcia (0x80d), rev 1, vendor 0x4243 >> > bwi0: regwin: v90 codec (0x807), rev 1, vendor 0x4243 >> > bwi0: regwin: pci (0x804), rev 7, vendor 0x4243 >> > bwi0: regwin: 802.11 MAC (0x812), rev 4, vendor 0x4243 >> > bwi0: ignore second MAC >> > bwi0: bus rev 0 >> > bwi0: pci is enabled >> > bwi0: card flags 0x000f >> > bwi0: 0th led, act 3, lowact 0 >> > bwi0: 1th led, act 5, lowact 0 >> > bwi0: 2th led, act 4, lowact 0 >> > bwi0: 3th led, act 0, lowact 0 >> > bwi0: 802.11 MAC was already disabled >> > bwi0: PHY is linked >> > bwi0: PHY: type 2, rev 1, ver 1 >> > bwi0: PHY: 802.11G attach >> > bwi0: RF: manu 0x17f, type 0x2050, rev 2 >> > bwi0: bu
Re: bwi: no DS tssi no OFDM tssi
I installed the firmware stuff from the dragonfly bwi(4) man page, yet I have the same issue. Is there a way to tell whether the firmware they provide supports my card? Like I said, I can locate my access point (and others that are around) and ask for an IP . . . it seems as though I'm so close. I'm fairly certain that I have all of the avliable bwi(4) bits installed correctly. I dwonloaded and installed the driver and added *if_bwi_load="YES"* in my loader.conf. I loaded the .ko file (bwi_v3). I downloaded and installed the firmware from dflyBSD and followed their directions. Yet I get no offer. Is the fact that I fail to get an offer indicate the firmware incompatinbility? Anyway, thanks for you help. On Mon, Jan 12, 2009 at 12:32 PM, Paul B. Mahol wrote: > On 1/12/09, Neal Hogan wrote: > > Hello, > > > >I am attempting to get by broadcom wifi card up and running, am sick > of > > trying to get ndis working, and am attempting to use the bwi driver > > (originating in dragonflyBSD). I'm hoping others here have tried to do > the > > same and have some pointers. I'm using 7.1-RELEASE (system/source are > > in-sync) and my card is a BCM94306MP. My dmesg is posted below. > > > > Bwi(4) is installed and it recognizes my card (*if_bwi_load-"YES"* is in > my > > /etc/rc.conf and *bwi_v3* and *if_bwi* are loaded). I can send a IP > request > > to my WEP encrypted access point. Yet, it doesn't get an offer and says > that > > *no DS tssi* and *no OFDM tssi* Being new to bwi(4) and have never seen > > references to DS/OFDM tssi, I'm not sure what info to provide. My > research > > is not leading anywhere helpful. Thanks. > > > > > > > > > > Copyright (c) 1992-2009 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > The Regents of the University of California. All rights reserved. > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > FreeBSD 7.1-RELEASE #0: Sat Jan 10 19:07:15 CST 2009 > > n...@frege.lambdaserver:/usr/obj/usr/src/sys/GENERIC > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > CPU: mobile AMD Athlon(tm) XP2400+ (1788.94-MHz 686-class CPU) > > Origin = "AuthenticAMD" Id = 0x6a0 Stepping = 0 > > > > > Features=0x383f9ff > > AMD Features=0xc0480800 > > real memory = 468647936 (446 MB) > > avail memory = 444530688 (423 MB) > > kbd1 at kbdmux0 > > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, > RF5413) > > acpi0: on motherboard > > acpi0: [ITHREAD] > > acpi0: Power Button (fixed) > > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 > > acpi_ec0: port 0x62,0x66 on acpi0 > > pcib0: port 0xcf8-0xcff on acpi0 > > pci_link5: BIOS IRQ 10 for 0.10.INTA is invalid > > pci0: on pcib0 > > agp0: on hostb0 > > pcib1: at device 1.0 on pci0 > > pci1: on pcib1 > > vgapci0: port 0x9000-0x90ff mem > > 0xe000-0xefff,0xd010-0xd010 irq 10 at device 5.0 on > > pci1 > > ohci0: mem > > 0xd0006000-0xd0006fff irq 9 at device 2.0 on pci0 > > ohci0: [GIANT-LOCKED] > > ohci0: [ITHREAD] > > usb0: OHCI version 1.0, legacy support > > usb0: SMM does not respond, resetting > > usb0: on ohci0 > > usb0: USB revision 1.0 > > uhub0: on usb0 > > uhub0: 4 ports with 4 removable, self powered > > pcm0: port 0x8400-0x84ff mem 0xd0007000-0xd0007fff > > irq 5 at device 6.0 on pci0 > > pcm0: > > pcm0: [GIANT-LOCKED] > > pcm0: [ITHREAD] > > isab0: at device 7.0 on pci0 > > isa0: on isab0 > > pci0: at device 8.0 (no driver attached) > > bwi0: mem > > 0xd0004000-0xd0005fff irq 9 at device 9.0 on pci0 > > bwi0: [ITHREAD] > > bwi0: regwin: chipcommon (0x800), rev 2, vendor 0x4243 > > bwi0: BBP: id 0x4306, rev 0x2, pkg 0 > > bwi0: nregwin 6, cap 0x002a > > bwi0: regwin: 802.11 MAC (0x812), rev 4, vendor 0x4243 > > bwi0: has TX stats > > bwi0: MAC: rev 4 > > bwi0: regwin: pcmcia (0x80d), rev 1, vendor 0x4243 > > bwi0: regwin: v90 codec (0x807), rev 1, vendor 0x4243 > > bwi0: regwin: pci (0x804), rev 7, vendor 0x4243 > > bwi0: regwin: 802.11 MAC (0x812), rev 4, vendor 0x4243 > > bwi0: ignore second MAC > > bwi0: bus rev 0 > > bwi0: pci is enabled > > bwi0: card flags 0x000f > > bwi0: 0th led, act 3, lowact 0 > > bwi0: 1th led, act 5, lowact 0 > > bwi0: 2th led, act 4, lowact 0 > > bwi0: 3th led, act 0, lowact 0 > > bwi0: 802.11 MAC was already disabled > > bwi0: PHY is linked > > bwi0: PHY: type 2, rev 1, ver 1 > > bwi0: PHY: 802.11G attach > > bwi0: RF: manu 0x17f, type 0x2050, rev 2 > > bwi0: bus rev 0 > > bwi0: PHY is linked > > bwi0: 30bit bus space > > bwi0: max txpower from sprom: 57 dBm > > bwi0: invalid antenna gain in sprom > > bwi0: ant gain 8 dBm > > bwi0: region/domain max txpower 76 dBm > > bwi0: max txpower 57 dBm > > bwi0: sprom idle tssi: 0x003e > > bwi0: TSSI-TX power map: > > 71 71 70 70 70 70 70 69 > > 69 69 69 69 68 68 68 67 > > 67 67 66 66 66 66 65 65 > > 65 64 64 64 63 63 63 62 > > 61 61 61 60 59
Re: Big problems with 7.1 locking up :-(
> Just to followup on this: My friend did switch back to a 7.1 kernel with > SCHED_4BSD, and he still ran into problems. The error messages weren't Acually, I dont know if I posted it, but that was the same for me too. The scheduler makes no difference, nor do CPU copile settings. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Big problems with 7.1 locking up :-(
> I'm not sure if you've done this already, but the normal suggestions apply: > have you compiled with INVARIANTS/WITNESS/DDB/KDB/BREAK_TO_DEBUGGER, and do > any results / panics / etc result? Sometimes these debugging tools are able > to convert hangs into panics, which gives us much more ability to debug them. OK, I have now had a machine hand again, with the correct debug options in the kernel. The screen looked like this when I went to restart it: http://toybox.twisted.org.uk/~pete/71_lor2.png It had not, however, dropped into any kind of debugger. Also there appear to me console messages after the lock order reversal - is that normal ? The machine did stay up for a signifanct amount of time before doing this. I notice that it is more or less identical to the one I posted whenI had WITNESS_KDB in the kernel too, so maybe those results arent entirely suprious after all ? Given it hasnt dropped to a debugger, is there anything else I can try ? -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Big problems with 7.1 locking up :-(
At 2:55 PM + 1/12/09, Robert Watson wrote: On Fri, 9 Jan 2009, Garance A Drosihn wrote: At 2:39 PM -0500 1/9/09, Robert Blayzor wrote: On Jan 8, 2009, at 8:58 PM, Pete French wrote: I have a number of HP 1U servers, all of which were running 7.0 perfectly happily. I have been testing 7.1 in it's various incarnations for the last couple of months on our test server and it has performed perfectly. I noticed a problem with 7.0 on a couple of Dell servers. [...] We've since then compiled the kernel under the BSD scheduler to rule that out, and so far so good. Since ULE is now default in 7.1 and not in 7.0, perhaps you can try that? FWIW, the other guy I know who is having this problem had already switched to using ULE under 7.0-release, and did not have any problems with it. So *his* problem was probably not related to SCHED_ULE, unless something has recently changed there. Turns out he hasn't reverted back to 7.0-release just yet, so he's going to try SCHED_4BSD and see if that helps his situation. Scheduler changes always come with some risk of exposing bugs that have existed in the code for a long time but never really manifested themselves. ULE is well shaken-out, having been under development for at least five years, but it is possible that some problems will become visible as a result of the switch. I would encourage people to stick with ULE, but if you're having a stability problem then experimenting with scheduler as a variable that could be triggering the problem may well be useful to help track down the bug. Just to followup on this: My friend did switch back to a 7.1 kernel with SCHED_4BSD, and he still ran into problems. The error messages weren't the same, but errors did happen in the same high disk-I/O situations as the lockup happened with SCHED_ULE. At this point he's fallen back to the 7.0-kernel that he had been running (which also has SCHED_ULE), and all the problems have gone away. So at the moment he's running with a 7.0-ish kernel and the 7.1-release userland, without the hanging problems. So the problem is something in the kernel, but it is *NOT* the scheduler (at least, not in his case). He is not eager to do a whole lot of experiments to track down the problem, since this is happening on busy production machines and he can't afford to have a lot of downtime on them (especially now that the semester at RPI has started up). The systems have some large (2 TB) filesystems on them, and the lockups occur in high disk-I/O situations. He's seeing the problem on one system which is a dual CPU quad-core xeon, and another which is a 64 bit P4 with hyperthreading. The one thing in common between the two setups is that the boot drives + a 3ware controller (with its array of RAID disks) is moved from one machine to the other one: "its a 3ware 9500 12 port model, the boot drive is connected to an ICH6 in IDE mode, and yes, I've run it in single, single with hyper threading, and 8 way mode. All 64 bit." We still have no idea where the problem really is. For all we know, someone spilled a Pepsi on it when he wasn't looking... -- Garance Alistair Drosehn= g...@gilead.netel.rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Instituteor dro...@rpi.edu ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: bwi: no DS tssi no OFDM tssi
firmware_get: failed to load firmware image bwi_v3_ucode4 bwi0: request firmware bwi_v3_ucode4 failed bwi0: bwi_stop looks like here is a problem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: bwi: no DS tssi no OFDM tssi
On 1/12/09, Neal Hogan wrote: > Hello, > >I am attempting to get by broadcom wifi card up and running, am sick of > trying to get ndis working, and am attempting to use the bwi driver > (originating in dragonflyBSD). I'm hoping others here have tried to do the > same and have some pointers. I'm using 7.1-RELEASE (system/source are > in-sync) and my card is a BCM94306MP. My dmesg is posted below. > > Bwi(4) is installed and it recognizes my card (*if_bwi_load-"YES"* is in my > /etc/rc.conf and *bwi_v3* and *if_bwi* are loaded). I can send a IP request > to my WEP encrypted access point. Yet, it doesn't get an offer and says that > *no DS tssi* and *no OFDM tssi* Being new to bwi(4) and have never seen > references to DS/OFDM tssi, I'm not sure what info to provide. My research > is not leading anywhere helpful. Thanks. > > > > > Copyright (c) 1992-2009 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.1-RELEASE #0: Sat Jan 10 19:07:15 CST 2009 > n...@frege.lambdaserver:/usr/obj/usr/src/sys/GENERIC > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: mobile AMD Athlon(tm) XP2400+ (1788.94-MHz 686-class CPU) > Origin = "AuthenticAMD" Id = 0x6a0 Stepping = 0 > > Features=0x383f9ff > AMD Features=0xc0480800 > real memory = 468647936 (446 MB) > avail memory = 444530688 (423 MB) > kbd1 at kbdmux0 > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 > acpi_ec0: port 0x62,0x66 on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci_link5: BIOS IRQ 10 for 0.10.INTA is invalid > pci0: on pcib0 > agp0: on hostb0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > vgapci0: port 0x9000-0x90ff mem > 0xe000-0xefff,0xd010-0xd010 irq 10 at device 5.0 on > pci1 > ohci0: mem > 0xd0006000-0xd0006fff irq 9 at device 2.0 on pci0 > ohci0: [GIANT-LOCKED] > ohci0: [ITHREAD] > usb0: OHCI version 1.0, legacy support > usb0: SMM does not respond, resetting > usb0: on ohci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 4 ports with 4 removable, self powered > pcm0: port 0x8400-0x84ff mem 0xd0007000-0xd0007fff > irq 5 at device 6.0 on pci0 > pcm0: > pcm0: [GIANT-LOCKED] > pcm0: [ITHREAD] > isab0: at device 7.0 on pci0 > isa0: on isab0 > pci0: at device 8.0 (no driver attached) > bwi0: mem > 0xd0004000-0xd0005fff irq 9 at device 9.0 on pci0 > bwi0: [ITHREAD] > bwi0: regwin: chipcommon (0x800), rev 2, vendor 0x4243 > bwi0: BBP: id 0x4306, rev 0x2, pkg 0 > bwi0: nregwin 6, cap 0x002a > bwi0: regwin: 802.11 MAC (0x812), rev 4, vendor 0x4243 > bwi0: has TX stats > bwi0: MAC: rev 4 > bwi0: regwin: pcmcia (0x80d), rev 1, vendor 0x4243 > bwi0: regwin: v90 codec (0x807), rev 1, vendor 0x4243 > bwi0: regwin: pci (0x804), rev 7, vendor 0x4243 > bwi0: regwin: 802.11 MAC (0x812), rev 4, vendor 0x4243 > bwi0: ignore second MAC > bwi0: bus rev 0 > bwi0: pci is enabled > bwi0: card flags 0x000f > bwi0: 0th led, act 3, lowact 0 > bwi0: 1th led, act 5, lowact 0 > bwi0: 2th led, act 4, lowact 0 > bwi0: 3th led, act 0, lowact 0 > bwi0: 802.11 MAC was already disabled > bwi0: PHY is linked > bwi0: PHY: type 2, rev 1, ver 1 > bwi0: PHY: 802.11G attach > bwi0: RF: manu 0x17f, type 0x2050, rev 2 > bwi0: bus rev 0 > bwi0: PHY is linked > bwi0: 30bit bus space > bwi0: max txpower from sprom: 57 dBm > bwi0: invalid antenna gain in sprom > bwi0: ant gain 8 dBm > bwi0: region/domain max txpower 76 dBm > bwi0: max txpower 57 dBm > bwi0: sprom idle tssi: 0x003e > bwi0: TSSI-TX power map: > 71 71 70 70 70 70 70 69 > 69 69 69 69 68 68 68 67 > 67 67 66 66 66 66 65 65 > 65 64 64 64 63 63 63 62 > 61 61 61 60 59 59 58 57 > 57 55 55 54 53 52 51 50 > 49 48 47 44 43 42 39 37 > 35 32 29 26 22 18 14 8 > bwi0: idle tssi0: 62 > bwi0: bus rev 0 > bwi0: locale: 6 > bwi0: WARNING: using obsoleted if_watchdog interface > bwi0: Ethernet address: 00:90:4b:61:02:45 > cbb0: irq 11 at device 10.0 on pci0 > cardbus0: on cbb0 > pccard0: <16-bit PCCard bus> on cbb0 > cbb0: [ITHREAD] > fwohci0: mem > 0xd0009000-0xd00097ff,0xd000-0xd0003fff irq 10 at device 12.0 on > pci0 > fwohci0: [FILTER] > fwohci0: OHCI version 1.10 (ROM=1) > fwohci0: No. of Isochronous channels is 4. > fwohci0: EUI64 00:0d:9d:71:9e:43:0c:6a > fwohci0: Phy 1394a available S400, 1 ports. > fwohci0: Link S400, max_rec 2048 bytes. > firewire0: on fwohci0 > fwe0: on firewire0 > if_fwe0: Fake Ethernet address: 02:0d:9d:43:0c:6a > fwe0: Ethernet address: 02:0d:9d:43:0c:6a > fwip0: on firewire0 > fwip0: Firewire address: 00:0d:9d:71:9e:43:0c:6a @ 0xfffe, > S400, maxrec 2048 > sbp0: on firewire0 > dcons_crom0: on firewire0 > dcons_crom0:
FreeBSD 7.0 kernel panic
Hello, FreeBSD-stable.
Last week I have a lot of kernel panics like:
> [r...@router1 /usr/obj/usr/src/sys/TINCOKERNEL2]# kgdb kernel.debug
> /var/crash/vmcore.20
> [GDB will not be able to debug user-mode threads:
> /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i386-marcel-freebsd".
>
> Unread portion of the kernel message buffer:
> kernel trap 12 with interrupts disabled
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address = 0x9
> fault code = supervisor read, page not present
> instruction pointer = 0x20:0xc079f1af
> stack pointer = 0x28:0xe5697c80
> frame pointer = 0x28:0xe5697cbc
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags= resume, IOPL = 0
> current process = 14 (swi4: clock)
> trap number = 12
> panic: page fault
> cpuid = 0
> Uptime: 51m49s
> Physical memory: 2032 MB
> Dumping 177 MB: 162 146 130 114 98 82 66 50 34 18 2
>
> #0 doadump () at pcpu.h:195
> 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
> (kgdb) bt
> #0 doadump () at pcpu.h:195
> #1 0xc078d1b7 in boot (howto=260) at
> /usr/src/sys/kern/kern_shutdown.c:409
> #2 0xc078d479 in panic (fmt=Variable "fmt" is not available.
> ) at /usr/src/sys/kern/kern_shutdown.c:563
> #3 0xc0a0eaac in trap_fatal (frame=0xe5697c40, eva=9) at
> /usr/src/sys/i386/i386/trap.c:899
> #4 0xc0a0f42f in trap (frame=0xe5697c40) at /usr/src/sys/i386/i386/trap.c:280
> #5 0xc09f565b in calltrap () at
> /usr/src/sys/i386/i386/exception.s:139
> #6 0xc079f1af in softclock (dummy=0x0) at
> /usr/src/sys/kern/kern_timeout.c:202
> #7 0xc076f31b in ithread_loop (arg=0xc5101250) at
> /usr/src/sys/kern/kern_intr.c:1036
> #8 0xc076c119 in fork_exit (callout=0xc076f170 ,
> arg=0xc5101250, frame=0xe5697d38)
> at /usr/src/sys/kern/kern_fork.c:781
> #9 0xc09f56d0 in fork_trampoline () at
> /usr/src/sys/i386/i386/exception.s:205
> (kgdb)
What I should do?
--
С уважением,
L1NYX01D mailto:l1nyx...@googlemail.com
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
bwi: no DS tssi no OFDM tssi
Hello, I am attempting to get by broadcom wifi card up and running, am sick of trying to get ndis working, and am attempting to use the bwi driver (originating in dragonflyBSD). I'm hoping others here have tried to do the same and have some pointers. I'm using 7.1-RELEASE (system/source are in-sync) and my card is a BCM94306MP. My dmesg is posted below. Bwi(4) is installed and it recognizes my card (*if_bwi_load-"YES"* is in my /etc/rc.conf and *bwi_v3* and *if_bwi* are loaded). I can send a IP request to my WEP encrypted access point. Yet, it doesn't get an offer and says that *no DS tssi* and *no OFDM tssi* Being new to bwi(4) and have never seen references to DS/OFDM tssi, I'm not sure what info to provide. My research is not leading anywhere helpful. Thanks. Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-RELEASE #0: Sat Jan 10 19:07:15 CST 2009 n...@frege.lambdaserver:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: mobile AMD Athlon(tm) XP2400+ (1788.94-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x6a0 Stepping = 0 Features=0x383f9ff AMD Features=0xc0480800 real memory = 468647936 (446 MB) avail memory = 444530688 (423 MB) kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci_link5: BIOS IRQ 10 for 0.10.INTA is invalid pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x9000-0x90ff mem 0xe000-0xefff,0xd010-0xd010 irq 10 at device 5.0 on pci1 ohci0: mem 0xd0006000-0xd0006fff irq 9 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 4 ports with 4 removable, self powered pcm0: port 0x8400-0x84ff mem 0xd0007000-0xd0007fff irq 5 at device 6.0 on pci0 pcm0: pcm0: [GIANT-LOCKED] pcm0: [ITHREAD] isab0: at device 7.0 on pci0 isa0: on isab0 pci0: at device 8.0 (no driver attached) bwi0: mem 0xd0004000-0xd0005fff irq 9 at device 9.0 on pci0 bwi0: [ITHREAD] bwi0: regwin: chipcommon (0x800), rev 2, vendor 0x4243 bwi0: BBP: id 0x4306, rev 0x2, pkg 0 bwi0: nregwin 6, cap 0x002a bwi0: regwin: 802.11 MAC (0x812), rev 4, vendor 0x4243 bwi0: has TX stats bwi0: MAC: rev 4 bwi0: regwin: pcmcia (0x80d), rev 1, vendor 0x4243 bwi0: regwin: v90 codec (0x807), rev 1, vendor 0x4243 bwi0: regwin: pci (0x804), rev 7, vendor 0x4243 bwi0: regwin: 802.11 MAC (0x812), rev 4, vendor 0x4243 bwi0: ignore second MAC bwi0: bus rev 0 bwi0: pci is enabled bwi0: card flags 0x000f bwi0: 0th led, act 3, lowact 0 bwi0: 1th led, act 5, lowact 0 bwi0: 2th led, act 4, lowact 0 bwi0: 3th led, act 0, lowact 0 bwi0: 802.11 MAC was already disabled bwi0: PHY is linked bwi0: PHY: type 2, rev 1, ver 1 bwi0: PHY: 802.11G attach bwi0: RF: manu 0x17f, type 0x2050, rev 2 bwi0: bus rev 0 bwi0: PHY is linked bwi0: 30bit bus space bwi0: max txpower from sprom: 57 dBm bwi0: invalid antenna gain in sprom bwi0: ant gain 8 dBm bwi0: region/domain max txpower 76 dBm bwi0: max txpower 57 dBm bwi0: sprom idle tssi: 0x003e bwi0: TSSI-TX power map: 71 71 70 70 70 70 70 69 69 69 69 69 68 68 68 67 67 67 66 66 66 66 65 65 65 64 64 64 63 63 63 62 61 61 61 60 59 59 58 57 57 55 55 54 53 52 51 50 49 48 47 44 43 42 39 37 35 32 29 26 22 18 14 8 bwi0: idle tssi0: 62 bwi0: bus rev 0 bwi0: locale: 6 bwi0: WARNING: using obsoleted if_watchdog interface bwi0: Ethernet address: 00:90:4b:61:02:45 cbb0: irq 11 at device 10.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [ITHREAD] fwohci0: mem 0xd0009000-0xd00097ff,0xd000-0xd0003fff irq 10 at device 12.0 on pci0 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:0d:9d:71:9e:43:0c:6a fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:0d:9d:43:0c:6a fwe0: Ethernet address: 02:0d:9d:43:0c:6a fwip0: on firewire0 fwip0: Firewire address: 00:0d:9d:71:9e:43:0c:6a @ 0xfffe, S400, maxrec 2048 sbp0: on firewire0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x12bc000 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x8080-0x808f at device 16.0 on pci0 atapci0: using PIO transfers above 137GB as workaround for 48bit DMA access bug, expect red
HEADS UP: build changes
r187106 syncs the Makefiles with HEAD so that RELENG_7 has the same set of build knobs. Let me know if you see any oddities that you can trace to this commit. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
Walter Venable wrote: FreeBSD 7.1 upgrade broke my network access, machine is totally offline (powered-on and I can play inside it at the terminal, but absolutely 0 network access): This happened AFTER make kernel but BEFORE make installworld. I think this implies it's a kernel driver issue. Hi, i see similar problems with a re card: r...@pci0:4:7:0: class=0x02 card=0x816710ec chip=0x816710ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8169/8110 Family Gigabit Ethernet NIC' class = network subclass = ethernet After upgrading to 7.1-RELEASE (and also STABLE) the NIC doesn't seem to receive any frames. I can see the DHCP Requests on the DHCP Server but the DHCPOFFERS are never seen by the client with the re0 device. After setting promiscious mode on the interface (i.e. by tcpdump -ni re0) the interface begins to work fine. I've attached a complete dmesg output, but i think the detection works fine, here the short version: re0: port 0x9c00-0x9cff mem 0xdfdff000-0xdfdff0ff irq 20 at device 7.0 on pci4 re0: Chip rev. 0x1800 re0: MAC rev. 0x miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1a:92:35:29:fa re0: [FILTER] Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-STABLE #0: Mon Jan 12 14:18:26 CET 2009 r...@dreamland.office.local:/usr/obj/usr/src/sys/DREAMLAND Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU 6320 @ 1.86GHz (1863.87-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x2010 AMD Features2=0x1 Cores per package: 2 real memory = 2146304000 (2046 MB) avail memory = 2086531072 (1989 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 4 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 10, 7fde (3) failed acpi0: reservation of 0, a (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_hpet0: iomem 0xfe80-0xfe8003ff on acpi0 device_attach: acpi_hpet0 attach returned 12 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib2: irq 27 at device 2.0 on pci0 pci2: on pcib2 vgapci0: port 0xac00-0xac7f mem 0xdc00-0xdcff,0xc000-0xcfff,0xdd00-0xddff irq 24 at device 0.0 on pci2 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io nvidia0: [GIANT-LOCKED] nvidia0: [ITHREAD] pcib3: irq 31 at device 3.0 on pci0 pci3: on pcib3 atapci0: port 0xcc00-0xcc07,0xc800-0xc803,0xc400-0xc407,0xc000-0xc003,0xbc00-0xbc0f mem 0xdfefe000-0xdfef irq 28 at device 0.0 on pci3 atapci0: [ITHREAD] atapci0: AHCI called from vendor specific driver atapci0: AHCI Version 01.00 controller with 2 ports detected ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] atapci1: port 0xfc00-0xfc07,0xf800-0xf803,0xf400-0xf407,0xf000-0xf003,0xec00-0xec0f,0xe800-0xe8ff irq 21 at device 15.0 on pci0 atapci1: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] ata6: on atapci1 ata6: [ITHREAD] atapci2: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe400-0xe40f at device 15.1 on pci0 ata0: on atapci2 ata0: [ITHREAD] ata1: on atapci2 ata1: [ITHREAD] uhci0: port 0xe000-0xe01f irq 20 at device 16.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xdc00-0xdc1f irq 22 at device 16.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xd800-0xd81f irq 21 at device 16.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xd400-0xd41f irq 23 at device 16.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xd000-0xd0ff irq 21 at device 16.4 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uh
Re: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
On 2009-01-12 07:41, Pyun YongHyeon wrote: > I see, Unfortunately the issue was fixed in the end of 7.1-R > release process so I wanted to get more exposure before MFC. > I'll make sure to MFC to stable/7 after more testing. I'm also having problems with re's, in my case the interfaces take about 10 seconds to come up, if they come up at all. After the interfaces are up, half the time no packets go out at all. Usually it helps to bring them down via the console, wait about 10 seconds, and then bring them up again... These are the following variant: FreeBSD 7.1-STABLE #0: Mon Jan 12 14:22:11 CET 2009 [...] re0: port 0xf000-0xf0ff mem 0xfdfff000-0xfdfff0ff irq 18 at device 9.0 on pci0 re0: Chip rev. 0x1800 re0: MAC rev. 0x miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:30:18:a6:f1:a8 re0: [FILTER] re1: port 0xf200-0xf2ff mem 0xfdffe000-0xfdffe0ff irq 19 at device 11.0 on pci0 re1: Chip rev. 0x1800 re1: MAC rev. 0x miibus1: on re1 rgephy1: PHY 1 on miibus1 rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re1: Ethernet address: 00:30:18:a6:f1:a9 re1: [FILTER] And just FYI, r187080-r187083 that you recently committed (MFCs of r184240-184243, r184245, 185575 and r186390), don't seem to change anything for this situation. :( ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Big problems with 7.1 locking up :-(
> I'm not sure if you've done this already, but the normal suggestions apply: > have you compiled with INVARIANTS/WITNESS/DDB/KDB/BREAK_TO_DEBUGGER, and do > any results / panics / etc result? Sometimes these debugging tools are able > to convert hangs into panics, which gives us much more ability to debug them. I did, but it turns out I had an incorrect option in there which made the data I got not relevent. I now have another machine running a kernel with the following config: include GENERIC ident DEBUG options KDB options DDB options SW_WATCHDOG options DEBUG_VFS_LOCKS options MUTEX_DEBUG options WITNESS options LOCK_PROFILING options INVARIANTS options INVARIANT_SUPPORT options DIAGNOSTIC Those should enable me to get some useful output I hope. > If it still hangs rather than panicking, are you able to break into the > debugger on the console? If you're using a video console and not able to get > to the debugger, would it be possible to configure a serial console and use I cant add a sserial console - I am remote enough from most of these machines (Slough) and very remote from the test box (its in the USA!) so I cant get to them physicly. But I do have iLo which lets me use the console and gives me a bit of access to the front. I will check for NMI. Just had another lockup here - my working day has become a succession of running round rebooting servers though iLo at the moment. Will get back to you when the debug one has crashed - I could possibly give you direct access to the iLo console on that if you need it ? -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Big problems with 7.1 locking up :-(
On Sat, 10 Jan 2009, Pete French wrote: FWIW, the other guy I know who is having this problem had already switched to using ULE under 7.0-release, and did not have any problems with it. So *his* problem was probably not related to SCHED_ULE, unless something has recently changed there. Well, one of my machines just locked up again, even with SCHED_4BSD on it, so I am now thinking it is unrelated. The machine has completely locked - no response to pings, no response to keypresses, nor to the power button. There is nothing printed on the console - it is just sitting there with a login prompt :-( This is really not good - these are extremely common servers after all, and I am just running bog standard 7.1 with apache and mysql. This is happening across several different servers, all of which are slight variants on the DL360, so I dont think it is something perculiar to me. I'm not sure if you've done this already, but the normal suggestions apply: have you compiled with INVARIANTS/WITNESS/DDB/KDB/BREAK_TO_DEBUGGER, and do any results / panics / etc result? Sometimes these debugging tools are able to convert hangs into panics, which gives us much more ability to debug them. If it still hangs rather than panicking, are you able to break into the debugger on the console? If you're using a video console and not able to get to the debugger, would it be possible to configure a serial console and use that -- serial breaks are often more successful at getting to the debugger than keyboard breaks. Likewise, I'm not sure if this hardware has an NMI button -- some HP servers have one on the motherboard that you can press -- but that is also potentially a way to get into the debugger the analyze the crash. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Big problems with 7.1 locking up :-(
On Fri, 9 Jan 2009, Garance A Drosihn wrote: At 2:39 PM -0500 1/9/09, Robert Blayzor wrote: On Jan 8, 2009, at 8:58 PM, Pete French wrote: I have a number of HP 1U servers, all of which were running 7.0 perfectly happily. I have been testing 7.1 in it's various incarnations for the last couple of months on our test server and it has performed perfectly. I noticed a problem with 7.0 on a couple of Dell servers. [...] We've since then compiled the kernel under the BSD scheduler to rule that out, and so far so good. Since ULE is now default in 7.1 and not in 7.0, perhaps you can try that? FWIW, the other guy I know who is having this problem had already switched to using ULE under 7.0-release, and did not have any problems with it. So *his* problem was probably not related to SCHED_ULE, unless something has recently changed there. Turns out he hasn't reverted back to 7.0-release just yet, so he's going to try SCHED_4BSD and see if that helps his situation. Scheduler changes always come with some risk of exposing bugs that have existed in the code for a long time but never really manifested themselves. ULE is well shaken-out, having been under development for at least five years, but it is possible that some problems will become visible as a result of the switch. I would encourage people to stick with ULE, but if you're having a stability problem then experimenting with scheduler as a variable that could be triggering the problem may well be useful to help track down the bug. Most of the time the bugs will not be in ULE itself, rather, triggered because ULE will change the ordering or balancing of work in the system, so we should try to avoid situations where people switch to 4BSD from ULE and stick with it rather than getting the underlying problem fixed! Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Big problems with 7.1 locking up :-(
> I've performed five buildworlds decrementing -j from 16 to 6 and I > can't lock up the server. Mine never lock up doing buildworlds either. They only lock up when they are sitting there more of less idle! The machines which have never locked up are the webservers, which are fairly heavlt loaded. The machine which locks up the most frequently is a box sitting there doing nothing but DNS, which is the most lightly loaded of the lot. I am going to roll back to 7.0 on all of the HP machines now, having had yet another day of rebooting locked up machines. I will leave one running 7.1 with the debug options in the kernel to try and get some useful results out of this. All the machines are now running GENERIC with no specail optimisations, CPU types or anything like that. Absolutely out of the box vanilla 7.1/amd64 as far as I know :-( -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Big problems with 7.1 locking up :-(
>> It has performed a buildworld without problems and I'll be doing some >> buildworlds throughout the day. >> >> This is on a HP c-class-blade with 8 GB ram, 2 x quad-core and the >> build-in p200-controller with 64 MB ram. I've performed five buildworlds decrementing -j from 16 to 6 and I can't lock up the server. -- regards Claus When lenity and cruelty play for a kingdom, the gentler gamester is the soonest winner. Shakespeare ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Lock order reversals using bce in 7.1
> You don't want WITNESS_KDB, but WITNESS_SKIPSPIN would probably be > sensible to include. OK, I will take out the WITNESS_KDB. I am reluctant to add in WITNESS_SKIPSPIN though, as I understand it stops witnessing spin locks, is that right ? As the only error message I have ever got out of all fo this explicitly mentioned spinlocks then I'd rather have them monitored. > That's due to WITNESS_KDB and probably unrelated to your problems. OK, will re-do all those tests - and also revert to the correct subject line for this thread (I am not quite sure why I typed a new one, it's a stupid thing to do as it makes it hard to follow). cheers, -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
fsck_y_enable: suboptimal/odd?
System: stable/7 some time before New Year (sorry if this issue has already been acted upon). I have a system with perhaps sufficiently rare configuration: it has fsck_y_enable="YES" and it has multiple filesystems mounted (UFS2), some RW, some RO. Today I had a chance to see fsck_y_enable in action. After a hard-lock followed by a reset normal fsck process started, several filesystems had "expected" inconsistencies and were successfully repaired, and then one filesystem had an unexpected inconsistency (partially truncated inode it was). After that normal fsck process was aborted and "fsck_y" process started. To much of my surprise it started all over - the filesystems that had been just successfully checked were being checked again. Even more - filesystems that had been mounted RO before the reset were also being checked. To me it seems like fsck_y passes suboptimal flags to fsck, it doesn't have to examine each and every filesystem in fstab. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
NFSv4 server
Is there any plans to include NFSv4 server into FreeBSD? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFSv13 in RELENG7
Andrew Snow wrote: > Oliver Fromme wrote: >> On the other hand, 8-current seems to run quite stable at >> the moment; I have it running on a workstation for several >> weeks without problems. > > What date of CURRENT are you running? I tracked down crashes related to > changes in SMBFS, but I am still experiencing almost weekly crashes such > as machine running out of swap space in the middle of the night for no > apparent reason.. Are you running rsync? Are the crashes happenning at about 3 am? (these two questions are unrelated) signature.asc Description: OpenPGP digital signature
Re: ZFSv13 in RELENG7
Andrew Snow wrote: > Oliver Fromme wrote: > > On the other hand, 8-current seems to run quite stable at > > the moment; I have it running on a workstation for several > > weeks without problems. > > What date of CURRENT are you running? I tracked down crashes related to > changes in SMBFS, but I am still experiencing almost weekly crashes such > as machine running out of swap space in the middle of the night for no > apparent reason.. $ uname -rs FreeBSD 8.0-CURRENT-20081128 $ uptime 12:23PM up 25 days, 22:07, 0 users, load averages: 0.00, 0.00, 0.00 I'm not using SMBFS, though. It's a workstation running typical desktop things (xterms, web browser, gimp, sane and similar). Best regards Oliver PS: Just in case someone wonders how to get timestamp suffixes to the kernel version string: I'm using this little script in place of "make kernel": http://www.secnetix.de/olli/scripts/makekernel -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "[...] one observation we can make here is that Python makes an excellent pseudocoding language, with the wonderful attribute that it can actually be executed." -- Bruce Eckel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Big problems with 7.1 locking up :-(
> I've updagraded a test-webserver to 7.1 when it was released. After a > few days I upgraded a production-webserver to 7.1 on Jan. 8'th and it > has been running without any problems. The webserver is not heavily > loaded (load at 2-3 on average). I have made a buildworld -j 8 and it > runs fine. > > If the reported lockup is due to i/o a buildworld will not be able to > reproduce it. > > It has performed a buildworld without problems and I'll be doing some > buildworlds throughout the day. > > This is on a HP c-class-blade with 8 GB ram, 2 x quad-core and the > build-in p200-controller with 64 MB ram. Forgot to add that CPUTYPE=nocona in /etc/make.conf. -- regards Claus When lenity and cruelty play for a kingdom, the gentler gamester is the soonest winner. Shakespeare ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Big problems with 7.1 locking up :-(
>> I am also surprised that this isn't more widely reported, as >> the hardware is very common. The only oddity with ym compile >> is that I set the CPUTYPE to 'core2' - that shouldnt have an effect, but >> I will remove it anyway, just so I am actually building a completely >> vanilla amd64. That way I should have what everyone else has, and since >> I don't see anyone else saying they have isues then maybe mine will >> go away too (fingers crossed) >> >Intel suggests nocona for x86_64 platforms and prescott for x86 > (i386) based platforms on the 4.2 line, because they best matched the > cache size and featureset of the Core2 processors. > >I don't think that core2 support was fully completed in 4.2 (in > fact I believe it was just started), and I don't think that our > binutils supports it properly. > > Some thoughts, > -Garrett I've updagraded a test-webserver to 7.1 when it was released. After a few days I upgraded a production-webserver to 7.1 on Jan. 8'th and it has been running without any problems. The webserver is not heavily loaded (load at 2-3 on average). I have made a buildworld -j 8 and it runs fine. If the reported lockup is due to i/o a buildworld will not be able to reproduce it. It has performed a buildworld without problems and I'll be doing some buildworlds throughout the day. This is on a HP c-class-blade with 8 GB ram, 2 x quad-core and the build-in p200-controller with 64 MB ram. -- regards Claus When lenity and cruelty play for a kingdom, the gentler gamester is the soonest winner. Shakespeare ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: igb on a Nehalem system, buildworld stats
On Fri, Jan 9, 2009 at 6:22 PM, Mars G Miro wrote: > On Fri, Jan 9, 2009 at 6:14 PM, Mars G Miro wrote: >> On Fri, Jan 9, 2009 at 5:15 PM, Jack Vogel wrote: >>> >> [snip] >> >> If you have a back to back connection to another NIC on Port 0, no >> switch, >> does >> it still autoneg to 100? >> Connected back to back w/ another box w/ a GigE NIC, it now does 1000baseTX: igb0: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:c5:db:e2 inet6 fe80::230:48ff:fec5:dbe2%igb0 prefixlen 64 scopeid 0x1 inet 192.168.70.2 netmask 0xff00 broadcast 192.168.70.255 media: Ethernet autoselect (1000baseTX ) status: active But still not without problems. I hafta ifconfig down/up it several times until I can see the other end. W/c is the same for igb1. >>> >>> >>> OK, so you have some switch issue. What do you mean "see the other end", >>> if its back to back and boots up I assume it gets link, if you have the >>> address >>> assigned in rc.conf, and you run tcpdump on the partner do you see the arp >>> when it comes online, and at that point can the other side ping it? >>> >> >> By 'see the other end' , I meant that even if It says 1000baseTX, i >> still can't ping the other end, well not really, as I can now see it >> gots bad chksums: >> >> 1. 001691 00:30:48:c5:db:e2 > ff:ff:ff:ff:ff:ff, ethertype ARP >> (0x0806), length 60: arp who-has 192.168.70.2 tell 192.168.70.2 >> 1. 51 00:30:48:c5:db:e2 > 00:30:48:61:d7:f2, ethertype IPv4 >> (0x0800), length 98: (tos 0x0, ttl 64, id 20346, offset 0, flags >> [none], proto ICMP (1), length 84) 192.168.70.2 > 192.168.70.1: ICMP >> echo request, id 14852, seq 0, length 64 >> 12 00:30:48:61:d7:f2 > 00:30:48:c5:db:e2, ethertype IPv4 (0x0800), >> length 98: (tos 0x0, ttl 64, id 3034, offset 0, flags [none], proto >> ICMP (1), length 84, bad cksum 0 (->617b)!) 192.168.70.1 > >> 192.168.70.2: ICMP echo reply, id 14852, seq 0, length 64 >> 1. 001611 00:30:48:c5:db:e2 > 00:30:48:61:d7:f2, ethertype IPv4 >> (0x0800), length 98: (tos 0x0, ttl 64, id 57773, offset 0, flags >> [none], proto ICMP (1), length 84) 192.168.70.2 > 192.168.70.1: ICMP >> echo request, id 14852, seq 1, length 64 >> 11 00:30:48:61:d7:f2 > 00:30:48:c5:db:e2, ethertype IPv4 (0x0800), >> length 98: (tos 0x0, ttl 64, id 59591, offset 0, flags [none], proto >> ICMP (1), length 84, bad cksum 0 (->848d)!) 192.168.70.1 > >> 192.168.70.2: ICMP echo reply, id 14852, seq 1, length 64 >> >> and this is back to back w/ another box w/ a GigE NIC (nfe, w/c has >> been in production for some time) >> >>> Oh, and what is the link partner hardware? >>> >> >> The switch? it's a Dlink 48-Port DGS-1248T GigE switch. >> >> Thanks. >> > > btw, I tried 200812-CURRENT and CURRENT as of Jan 7 and the behavior > is still the same :-( > > Hi again, We installed Windows 7 BETA on it, and altho the 1st NIC behaves the same way, e.g. if connected to a switch it stays at 100mbps, but if connected back to back w/ another GigE it can stay at 1.0Gbps, I do not get any network problems at all, for both igb NICs. So, something to do w/ the igb driver then ? Thanks. >>> Jack >>> -- cheers mars ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFSv13 in RELENG7
Oliver Fromme wrote: On the other hand, 8-current seems to run quite stable at the moment; I have it running on a workstation for several weeks without problems. What date of CURRENT are you running? I tracked down crashes related to changes in SMBFS, but I am still experiencing almost weekly crashes such as machine running out of swap space in the middle of the night for no apparent reason.. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Lock order reversals using bce in 7.1
On Sun, 2009-01-11 at 17:16 +, Pete French wrote: > Here is a better set of images. This machine was compiled > with the following config file: > > include GENERIC > ident DEBUG > > options KDB > options DDB > options SW_WATCHDOG > options DEBUG_VFS_LOCKS > options MUTEX_DEBUG > options WITNESS > options WITNESS_KDB You don't want WITNESS_KDB, but WITNESS_SKIPSPIN would probably be sensible to include. > options LOCK_PROFILING > options INVARIANTS > options INVARIANT_SUPPORT > options DIAGNOSTIC > > On booting it almost immediately does this: > > http://www.twisted.org.uk/~pete/71_lor.png That's due to WITNESS_KDB and probably unrelated to your problems. Gavin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFSv13 in RELENG7
msnk...@mail.ru wrote: > Is any plans to backport ZFSv13 from CURRENT to RELENG7 branxh or not? AFAIR Pawel explained that he intends to backport it to RELENG7, but it will take some time because it is a huge amount of code. Also, it depends on other merges from -current by other people that are not directly ZFS-related. Therefore the time frame is currently unknown. On the other hand, 8-current seems to run quite stable at the moment; I have it running on a workstation for several weeks without problems. So if you're eager to try ZFS 13, you might consider upgrading to -current. Also note that there are improvements in -current (by Alan Cox) that fix issues related to kmem in 64bit mode (FreeBSD/amd64). ZFS will very much benefit from those improvements; you don't have to tune kmem anymore in order to avoid panics. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Python is executable pseudocode. Perl is executable line noise. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
