Re: [ath] more updates; please test (especially if you're using an AR9280)
Adrian Chadd wrote: > On 23 January 2011 23:03, Adrian Chadd wrote: > > I've done a few updates to the ath driver today. In particular, I've > > updated the register initvals used to program the AR9280. It's making > > my AR9280 here behave a lot better. > > Just as a followup - it's a -lot- better. I can't stress how much > better my AR9280 is behaving after the updates to the initvals. > > Beforehand the AR9280 would lock up after 2-3 minutes in monitor mode, > and whilst in that mode it'd miss a lot of RX packets. After the > initval update, it's been happily receiving in monitor mode for > 30 > minutes. I'm quite shocked. :) I agree. I had several lockups this morning (bb hangs) and the wlan0 interface refused to destroy and create after that. Since updating, it's been stable for the last hour. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on powerpc64/powerpc
TB --- 2011-01-24 08:59:41 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-01-24 08:59:41 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-01-24 08:59:41 - cleaning the object tree TB --- 2011-01-24 08:59:46 - cvsupping the source tree TB --- 2011-01-24 08:59:46 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-01-24 08:59:57 - building world TB --- 2011-01-24 08:59:57 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-24 08:59:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-24 08:59:57 - TARGET=powerpc TB --- 2011-01-24 08:59:57 - TARGET_ARCH=powerpc64 TB --- 2011-01-24 08:59:57 - TZ=UTC TB --- 2011-01-24 08:59:57 - __MAKE_CONF=/dev/null TB --- 2011-01-24 08:59:57 - cd /src TB --- 2011-01-24 08:59:57 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 24 08:59:57 UTC 2011 >>> 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 [...] ===> lib/libkvm (obj,depend,all,install) rm -f .depend mkdep -f .depend -a-DLIBC_SCCS -I/src/lib/libkvm /src/lib/libkvm/kvm.c /src/lib/libkvm/kvm_powerpc64.c /src/lib/libkvm/kvm_cptime.c /src/lib/libkvm/kvm_file.c /src/lib/libkvm/kvm_getloadavg.c /src/lib/libkvm/kvm_getswapinfo.c /src/lib/libkvm/kvm_pcpu.c /src/lib/libkvm/kvm_proc.c /src/lib/libkvm/kvm_vnet.c cc -O2 -pipe -DLIBC_SCCS -I/src/lib/libkvm -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libkvm/kvm.c cc -O2 -pipe -DLIBC_SCCS -I/src/lib/libkvm -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libkvm/kvm_powerpc64.c cc1: warnings being treated as errors /src/lib/libkvm/kvm_powerpc64.c: In function 'dump_header_size': /src/lib/libkvm/kvm_powerpc64.c:81: warning: implicit declaration of function 'strcmp' *** Error code 1 Stop in /src/lib/libkvm. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-01-24 09:20:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-01-24 09:20:29 - ERROR: failed to build world TB --- 2011-01-24 09:20:29 - 957.01 user 186.99 system 1247.53 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [ath] more updates; please test (especially if you're using an AR9280)
On 24 January 2011 17:06, Ian FREISLICH wrote: > > Beforehand the AR9280 would lock up after 2-3 minutes in monitor mode, > > and whilst in that mode it'd miss a lot of RX packets. After the > > initval update, it's been happily receiving in monitor mode for > 30 > > minutes. I'm quite shocked. :) > > I agree. I had several lockups this morning (bb hangs) and the > wlan0 interface refused to destroy and create after that. Since > updating, it's been stable for the last hour. I think I have you to blame/thank for the AR9280, right? :) Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: why panic(9) ?
On Sun, 23 Jan 2011 19:28:30 -0800 Doug Barton wrote: > On 01/23/2011 15:00, David Demelier wrote: > > In any case, when panic occurs, switching display to the tty can be > > great. Why not a sysctl like kern.tty_on_panic? Because when you're > > running X and a panic occurs not everybody understand what happens. > > Putting the following in /etc/sysctl.conf can help: > > debug.debugger_on_panic=0 > > The reason being that sometimes when you panic in X the system is > attempting to drop to the debugger, but can't, which is why it hangs. > For what it's worth this appears to be the default on -current. -- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [ath] more updates; please test (especially if you're using an AR9280)
Adrian Chadd wrote: > On 24 January 2011 17:06, Ian FREISLICH wrote: > > > > Beforehand the AR9280 would lock up after 2-3 minutes in monitor mode, > > > and whilst in that mode it'd miss a lot of RX packets. After the > > > initval update, it's been happily receiving in monitor mode for > 30 > > > minutes. I'm quite shocked. :) > > > > I agree. =A0I had several lockups this morning (bb hangs) and the > > wlan0 interface refused to destroy and create after that. =A0Since > > updating, it's been stable for the last hour. > > I think I have you to blame/thank for the AR9280, right? :) You do :) I sent you the AR5B95 AR9281 Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD-current kernel can not be built
Yes, the file has been reverted in repository. Thank you. :-) Best regards, lz On 01/24/2011 03:46 PM, Adrian Chadd wrote: .. I must've fat-fingered one of my commits. That's a local option of mine that shouldn't be in the tree. I'll revert it now. Thanks, ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [ath] more updates; please test (especially if you're using an AR9280)
On 24 January 2011 06:31, Ian FREISLICH wrote: >> I think I have you to blame/thank for the AR9280, right? :) > > You do :) I sent you the AR5B95 AR9281 It's an AR9281, not an AR9280? Hm. I wonder what the differences are. Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
amd64 build fails within ESXi guest
I'm trying to build HEAD within an ESXi guest system, and the build errors while building the boot code. I've attached the tail end of the log. The host is a Dell Vostro 230 with CPU: Intel(R) Core(TM)2 Quad CPUQ8400 @ 2.66GHz (2659.61-MHz K8-class CPU) and the guest is allocated 256MB of RAM. This is ESXi 4.1.0. ===> sys/boot/i386/libi386 (all) cc -fPIC -DLOADER_NFS_SUPPORT -DCOMPORT=0x3f8 -DCOMSPEED=9600 -DSMBIOS_SERIAL_NUMBERS -DLOADER_GPT_SUPPORT -DTERM_EMU -Dalloca=__builtin_alloca -I/usr/src/sys/boot/i386/libi386/../../common -I/usr/src/sys/boot/i386/libi386/../btx/lib -I/usr/src/sys/boot/i386/libi386/../../../contrib/dev/acpica/include -I/usr/src/sys/boot/i386/libi386/../../.. -I. -I/usr/src/sys/boot/i386/libi386/../../../../lib/libstand/ -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32 -march=i386 -std=gnu99 -c /usr/src/sys/boot/i386/libi386/biosacpi.c cc -fPIC -DLOADER_NFS_SUPPORT -DCOMPORT=0x3f8 -DCOMSPEED=9600 -DSMBIOS_SERIAL_NUMBERS -DLOADER_GPT_SUPPORT -DTERM_EMU -Dalloca=__builtin_alloca -I/usr/src/sys/boot/i386/libi386/../../common -I/usr/src/sys/boot/i386/libi386/../btx/lib -I/usr/src/sys/boot/i386/libi386/../../../contrib/dev/acpica/include -I/usr/src/sys/boot/i386/libi386/../../.. -I. -I/usr/src/sys/boot/i386/libi386/../../../../lib/libstand/ -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32 -march=i386 -std=gnu99 -c /usr/src/sys/boot/i386/libi386/bioscd.c cc -fPIC -DLOADER_NFS_SUPPORT -DCOMPORT=0x3f8 -DCOMSPEED=9600 -DSMBIOS_SERIAL_NUMBERS -DLOADER_GPT_SUPPORT -DTERM_EMU -Dalloca=__builtin_alloca -I/usr/src/sys/boot/i386/libi386/../../common -I/usr/src/sys/boot/i386/libi386/../btx/lib -I/usr/src/sys/boot/i386/libi386/../../../contrib/dev/acpica/include -I/usr/src/sys/boot/i386/libi386/../../.. -I. -I/usr/src/sys/boot/i386/libi386/../../../../lib/libstand/ -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32 -march=i386 -std=gnu99 -c /usr/src/sys/boot/i386/libi386/biosdisk.c cc -fPIC -DLOADER_NFS_SUPPORT -DCOMPORT=0x3f8 -DCOMSPEED=9600 -DSMBIOS_SERIAL_NUMBERS -DLOADER_GPT_SUPPORT -DTERM_EMU -Dalloca=__builtin_alloca -I/usr/src/sys/boot/i386/libi386/../../common -I/usr/src/sys/boot/i386/libi386/../btx/lib -I/usr/src/sys/boot/i386/libi386/../../../contrib/dev/acpica/include -I/usr/src/sys/boot/i386/libi386/../../.. -I. -I/usr/src/sys/boot/i386/libi386/../../../../lib/libstand/ -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32 -march=i386 -std=gnu99 -c /usr/src/sys/boot/i386/libi386/biosmem.c cc -fPIC -DLOADER_NFS_SUPPORT -DCOMPORT=0x3f8 -DCOMSPEED=9600 -DSMBIOS_SERIAL_NUMBERS -DLOADER_GPT_SUPPORT -DTERM_EMU -Dalloca=__builtin_alloca -I/usr/src/sys/boot/i386/libi386/../../common -I/usr/src/sys/boot/i386/libi386/../btx/lib -I/usr/src/sys/boot/i386/libi386/../../../contrib/dev/acpica/include -I/usr/src/sys/boot/i386/libi386/../../.. -I. -I/usr/src/sys/boot/i386/libi386/../../../../lib/libstand/ -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32 -march=i386 -std=gnu99 -c /usr/src/sys/boot/i386/libi386/biospnp.c cc -fPIC -DLOADER_NFS_SUPPORT -DCOMPORT=0x3f8 -DCOMSPEED=9600 -DSMBIOS_SERIAL_NUMBERS -DLOADER_GPT_SUPPORT -DTERM_EMU -Dalloca=__builtin_alloca -I/usr/src/sys/boot/i386/libi386/../../common -I/usr/src/sys/boot/i386/libi386/../btx/lib -I/usr/src/sys/boot/i386/libi386/../../../contrib/dev/acpica/include -I/usr/src/sys/boot/i386/libi386/../../.. -I. -I/usr/src/sys/boot/i386/libi386/../../../../lib/libstand/ -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32 -march=i386 -std=gnu99 -c /usr/src/sys/boot/i386/libi386/biospci.c cc -fPIC -DLOADER_NFS_SUPPORT -DCOMPORT=0x3f8 -DCOMSPEED=9600 -DSMBIOS_SERIAL_NUMBERS -DLOADER_GPT_SUPPORT -DTERM_EMU -Dalloca=__builtin_alloca -I/usr/src/sys/boot/i386/libi386/../../common -I/usr/src/sys/boot/i386/libi386/../btx/lib -I/usr/src/sys/boot/i386/libi386/../../../contrib/dev/acpica/include -I/usr/src/sys/boot/i386/libi386/../../.. -I. -I/usr/src/sys/boot/i386/libi386/../../../../lib/libstand/ -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32 -march=i386 -std=gnu99 -c /usr/src/sys/boot/i386/libi386/biossmap.c cc -fPIC -DLOADER_NFS_SUPPORT -DCOMPORT=0x3f8 -DCOMSPEED=9600 -DSMBIOS_SERIAL_NUMBERS -DLOADER_GPT_SUPPORT -DTERM_EMU -Dalloca=__builtin_alloca -I/usr/src/sys/boot/i386/libi386/../../common -I/usr/src/sys/boot/i386/libi386/../btx/lib -I/usr/src/sys/boot/i386/libi386/../../../contrib/dev/acpica/include -I/usr/src/sys/boot/i386/libi386/../../.. -I. -I/usr/src/sys/boot/i386/libi386/../../../../lib/libstand/ -ffreestandi
RE: My ZFS v28 Testing Experience
Unfortunately, this didn't make a difference. There is no signifigant change in the benchmarks with the new compile. I do have a lot of CPU power at hand, so it doesn't look to be bound there at all. Possibly, that's one of the issues. I'm running 2 new Xeon X5660's so there's 6x2 (12) physical, 12x2 (24) virtual cores present to FreeBSD. How well is scheduling being handled on this processor architecture? At this stage, I can't say with any confidence that it _is_ ZFS at fault here, because I'm involving NFS and the ix driver substantially. I just know that NFS to a ZFS share on Solaris 11 Express is wildly faster than FreeBSD 9.0, regardless of tweaks. Now, there may be some extra debug within the NFS code that is the issue here, I'm not sure at this stage. I could also play with iSCSI instead, or the raw ZFS filesystem instead, but my needs involve NFS+ZFS, so that's my main test environment. I'm not using the new NFSv4 code. Let me know if there is something you'd like to test or know more about on my setup - I'll be running FreeBSD for about a week on this box (finishing up some last bits of work that I need it for), then I'm back to Solaris 11 Express for the next few months. I may end up having to build a separate box so I'm more easily able to test this configuration. I'd like to say with more confidence where the speed is going, because I feel FreeBSD deserves to be top-notch, and right now I'm only raising issues that aren't exact enough to work on. -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@freebsd.org] On Behalf Of Chris Forgeron Sent: Saturday, January 22, 2011 3:09 PM To: Pawel Jakub Dawidek Cc: freebsd...@freebsd.org; freebsd-current@freebsd.org Subject: RE: My ZFS v28 Testing Experience >Before we go any further could you please confirm that you commented out this >line in sys/modules/zfs/Makefile: > > CFLAGS+=-DDEBUG=1 > >This turns all kind of ZFS debugging and slows it down a lot, but for the >correctness testing is invaluable. This will >be turned off once we import ZFS >into FreeBSD-CURRENT. Ah! I did not do this. My bad, I've made the edit, and will be recompiling today to see the differences this makes. I will also clone my disk, turn witness and full debug back on, and then try and find out where my problems importing a pool with multiple cache/log devices comes from. It's quite possible it's not hanging, just taking forever, and I'm impatient and not letting it sit for a n hour to see if it completes. Will report back once I have numbers. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: amd64 build fails within ESXi guest
On Mon, Jan 24, 2011 at 8:25 AM, Eric Crist wrote:
> I'm trying to build HEAD within an ESXi guest system, and the build errors
> while building the boot code. I've attached the tail end of the log. The
> host is a Dell Vostro 230 with CPU: Intel(R) Core(TM)2 Quad CPU Q8400 @
> 2.66GHz (2659.61-MHz K8-class CPU) and the guest is allocated 256MB of RAM.
> This is ESXi 4.1.0.
>
Locally we've been building the amd64 kernel with a few different
flags and ran into this in our kernel build.
Try this definition of do_cpuid instead:
static __inline void
do_cpuid(u_int ax, u_int *p)
{
#if 0
/*
* Isilon: get a compile error on a new hwpmc file:
/data/sb/BR_HAB_BSDMERGE_STABLE7/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_core.c:
In function 'pmc_core_initialize':
./machine/cpufunc.h:111: error: can't find a register in class 'BREG'
while reloading 'asm'
./machine/cpufunc.h:111: error: 'asm' operand has impossible constraints
This presumably has to do with -fPIC. See
http://sam.zoy.org/blog/2007-04-13-shlib-with-non-pic-code-have-inline-assembly-and-pic-mix-well
for this workaround.
*/
__asm __volatile("cpuid"
: "=a" (p[0]), "=b" (p[1]), "=c" (p[2]), "=d" (p[3])
: "0" (ax));
#else
__asm __volatile("push %%ebx \n\t" /* save %ebx */
"cpuid\n\t"
"movl %%ebx, %1 \n\t" /* save what cpuid just put in
%ebx */
"pop %%ebx\n\t" /* restore the old %ebx */
: "=a" (p[0]), "=m" (p[1]), "=c" (p[2]), "=d" (p[3])
: "a"(ax)
: "cc");
#endif
}
Note that using =r for the constraint on p[1] isn't sufficient as once
in a while the compiler has chosen %ebx, which then leads to garbage
in the register after the pop.
Thanks,
matthew
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [head tinderbox] failure on amd64/amd64
On 24 Jan 2011, at 06:16, Peter Jeremy wrote: > On 2011-Jan-21 20:01:32 +0100, "Simon L. B. Nielsen" wrote: >> Perhaps we should just set the tinderbox up to sync directly of cvsup-master >> instead if that makes it more useful? > > Can cvsup-master still lose atomicity of commits? I suspect it can, Yes, there would not be a change in that - there is no simple way around that with current infrastructure (as fixing that wold mean doing evil hacks around cvs etc.) The only thing you would gain by using cvsup-master to pull sources is lower lag time between what tinderboxes build and what's in src/ VCS. > in which case syncing directly off the SVN master would seem a better > approach. Better yes, but that's not a simple configuration change like switching to using cvsup-master is, and unfortunately I have plenty of more interesting projects than changing tinderbox code :-). PS. for other people not being Peter Jeremy :) - no, I'm not going to consider git or going to consider discussing it - see above :-). -- Simon L. B. Nielsen ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[ath] AR9285 / AR2427 testers needed!
Hi all, I've just updated the ath HAL with some updates. I've updated the register initvals for the AR9285 and derivatives, and I've also updated the EEPROM format to be correct. I'd really appreciate some testing by those of you with AR9285/AR2427 NICs. Please let me know if things are better or worse. To AR2427 users - I'm currently using an AR2427 in another EEEPC and it's been rock solid for me for at least 30 minutes! :) Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
