Re: www/chromium crashing whole system
On 15 Nov 2010, at 22:19, Alexander Best wrote: > thanks for all your help. i've recently switched to chromium 6.0.472.63 > and so far my computer has been very stable. > > if i experience more lock ups i'll let you know and try to figure out a way to > gain access to some more debugging data. I'd prefer we try to figure out why your system was crashing now -- the kernel bug has not gone away just because Chromium is no longer triggering it. Working around the bug means someone else gets to run into it later -- perhaps when it's 9.0-RELEASE rather than 9-CURRENT... Robert___ 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"
[Call for Tests] PAT issue on Apple hardware
Often times I hear complaints like "my Mac hangs after upgrading to
8.1" or "snapshot CD hangs on my brand new Mac". I know some of
these complaints started happening when we switched to new PAT
layout. It is so puzzling because it never happened on non-Apple
hardware, AFAIK. I really like to fix this problem but I cannot
afford a Mac. :-P
If you are one of those lucky people, please test the attached patch
and report your hardware model and any improvement or regression.
Also, I added a new tunable "vm.pmap.pat_works" so that you can turn
it off from loader (i.e., "set vm.pmap.pat_works=0") and restore old
behaviour without recompiling a new kernel.
Thanks in advance!
Jung-uk Kim
Index: sys/amd64/amd64/pmap.c
===
--- sys/amd64/amd64/pmap.c (revision 215352)
+++ sys/amd64/amd64/pmap.c (working copy)
@@ -180,10 +180,13 @@ static vm_paddr_t dmaplimit;
vm_offset_t kernel_vm_end = VM_MIN_KERNEL_ADDRESS;
pt_entry_t pg_nx;
-static int pat_works = 0; /* Is page attribute table sane? */
-
SYSCTL_NODE(_vm, OID_AUTO, pmap, CTLFLAG_RD, 0, "VM/pmap parameters");
+static int pat_works = 1;
+TUNABLE_INT("vm.pmap.pat_works", &pat_works);
+SYSCTL_INT(_vm_pmap, OID_AUTO, pat_works, CTLFLAG_RDTUN, &pat_works, 1,
+"Is page attribute table fully functional?");
+
static int pg_ps_enabled = 1;
SYSCTL_INT(_vm_pmap, OID_AUTO, pg_ps_enabled, CTLFLAG_RDTUN, &pg_ps_enabled, 0,
"Are large page mappings enabled?");
@@ -609,35 +612,15 @@ void
pmap_init_pat(void)
{
uint64_t pat_msr;
- char *sysenv;
- static int pat_tested = 0;
/* Bail if this CPU doesn't implement PAT. */
if (!(cpu_feature & CPUID_PAT))
panic("no PAT??");
- /*
-* Some Apple Macs based on nVidia chipsets cannot enter ACPI mode
-* via SMI# when we use upper 4 PAT entries for unknown reason.
-*/
- if (!pat_tested) {
- pat_works = 1;
- sysenv = getenv("smbios.system.product");
- if (sysenv != NULL) {
- if (strncmp(sysenv, "MacBook5,1", 10) == 0 ||
- strncmp(sysenv, "MacBookPro5,5", 13) == 0 ||
- strncmp(sysenv, "Macmini3,1", 10) == 0 ||
- strncmp(sysenv, "iMac9,1", 7) == 0)
- pat_works = 0;
- freeenv(sysenv);
- }
- pat_tested = 1;
- }
-
/* Initialize default PAT entries. */
pat_msr = PAT_VALUE(0, PAT_WRITE_BACK) |
PAT_VALUE(1, PAT_WRITE_THROUGH) |
- PAT_VALUE(2, PAT_UNCACHED) |
+ PAT_VALUE(2, PAT_WRITE_COMBINING) |
PAT_VALUE(3, PAT_UNCACHEABLE) |
PAT_VALUE(4, PAT_WRITE_BACK) |
PAT_VALUE(5, PAT_WRITE_THROUGH) |
@@ -646,19 +629,10 @@ pmap_init_pat(void)
if (pat_works) {
/*
-* Leave the indices 0-3 at the default of WB, WT, UC-, and UC.
-* Program 4 and 5 as WP and WC.
-* Leave 6 and 7 as UC- and UC.
+* Just replace PAT Index 5 with WP instead of WT.
*/
- pat_msr &= ~(PAT_MASK(4) | PAT_MASK(5));
- pat_msr |= PAT_VALUE(4, PAT_WRITE_PROTECTED) |
- PAT_VALUE(5, PAT_WRITE_COMBINING);
- } else {
- /*
-* Just replace PAT Index 2 with WC instead of UC-.
-*/
- pat_msr &= ~PAT_MASK(2);
- pat_msr |= PAT_VALUE(2, PAT_WRITE_COMBINING);
+ pat_msr &= ~PAT_MASK(5);
+ pat_msr |= PAT_VALUE(5, PAT_WRITE_PROTECTED);
}
wrmsr(MSR_PAT, pat_msr);
}
@@ -829,13 +803,13 @@ pmap_cache_bits(int mode, boolean_t is_pde)
pat_index = 0;
break;
case PAT_UNCACHED:
- pat_index = 2;
+ pat_index = 6;
break;
case PAT_WRITE_COMBINING:
- pat_index = 5;
+ pat_index = 2;
break;
case PAT_WRITE_PROTECTED:
- pat_index = 4;
+ pat_index = 5;
break;
default:
panic("Unknown caching mode %d\n", mode);
Index: sys/i386/i386/pmap.c
===
--- sys/i386/i386/pmap.c(revision 215352)
+++ sys/i386/i386/pmap.c(working copy)
@@ -217,10 +217,13 @@ pt_entry_t pg_nx;
static uma_zone_t pdptzone;
#endif
-static int pat_works = 0; /* Is page attribute table sane? */
-
SYSCTL_NODE(_vm, OID_AUTO, pmap, CTLFLAG_RD, 0, "VM/pmap parameters");
+static int pat_works = 1;
+TUNABLE_INT("vm.pmap.pat_works", &pat_works);
+SYSCTL_INT(_v
Re: www/chromium crashing whole system
On Sat, 13 Nov 2010 14:17:35 -0800, Julian Elischer wrote: > On 11/13/10 2:08 PM, Robert Watson wrote: >> >> If regular crashdumps appear unreliable, try setting up a textdump with >> an automatic reboot, that might provde more reliable (small chance, but >> it could). > > we did have some people working on an ethernet version of the > dcons/remote debugging stuff > I guess it only supports a small subset of ethernet chips though.. > Anyone know the status of that work? > I don't know about ethernet dump but how about simply dumping memory after reset ? See: - http://en.wikipedia.org/wiki/Cold_boot_attack - http://citp.princeton.edu/memory/ - http://www.mcgrewsecurity.com/tools/msramdmp/ Last link contains a tool to dump memory to usb disk after reset. If kgdb works with raw memory dumps, it may already work. This has the potential to solve all tricky debugging cases without needing firewire. A boot time kernel option to avoid certain memory areas which are overwritten during boot by bios and ram dumping tool could be useful or maybe necessary. It can even be completely automated, eg. if kernel would maintain some kind of "RAM dirty" flag, then during boot something (loader or kernel) would check for it and perform dump if needed. Another idea worth implementing or at least adding to project ideas list is to implement everything that is currently possible with serial (boot0, loader, kernel console, ddb) over EHCI debug port: - http://www.coreboot.org/EHCI_Debug_Port ___ 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: Broadcom BCM4310 USB Controller (Wifi)
On 11/15/10, Alberto Villa wrote: > On Wed, Oct 27, 2010 at 3:36 PM, Paul B Mahol wrote: >> Currently amd64 is broken with some/most drivers. Drivers appears to >> use fpu registers. >> I dunno how it ever worked, probably original developer(s) never >> encountered drivers which use fpu registers. >> >> I will probably fix amd64 support in this year. > > so, i've tried the ndis driver with amd64 and it paniced, as you said. > do you have any idea on when you're gonna fix this? i need to know if > i can keep amd64 and wait for a fix (in short time) or if i have to > install i386 temporarily... Feel free to test code at: gitorious.org/NDISulator github.com/richardpl/NDISulator The code is developed on CURRENT. But with small changes it can be compiled on STABLE too. Just now I have only one tester (and that is without counting me). ___ 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: Broadcom BCM4310 USB Controller (Wifi)
On Wed, Oct 27, 2010 at 3:36 PM, Paul B Mahol wrote: > Currently amd64 is broken with some/most drivers. Drivers appears to > use fpu registers. > I dunno how it ever worked, probably original developer(s) never > encountered drivers which use fpu registers. > > I will probably fix amd64 support in this year. so, i've tried the ndis driver with amd64 and it paniced, as you said. do you have any idea on when you're gonna fix this? i need to know if i can keep amd64 and wait for a fix (in short time) or if i have to install i386 temporarily... thanks -- Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla ___ 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: www/chromium crashing whole system
On Sat Nov 13 10, Julian Elischer wrote: > On 11/13/10 2:13 PM, Robert Watson wrote: > > > >On Sat, 13 Nov 2010, Garrett Cooper wrote: > > > >> Isn't there also DEADLKRES that might be helpful in this case (if > >>Alex is really dealing with a livelock in the kernel)...? > > > >The deadlock resolver is compiled into the GENERIC kernel on > >-CURRENT, so I'm assuming it hasn't helped (or perhaps is even part > >of the problem). I think the best thing to do at this point is to > >try to get into DDB. Of the schemes I suggested to work around the > >X11 issue, switching to a virtual console before starting Chromium > >may work best, since it will continue to use the local X server, etc. > An alternate way of handling this: > Turn on the VNC X server and use that from a remote place, leaving the > console free. thanks for all your help. i've recently switched to chromium 6.0.472.63 and so far my computer has been very stable. if i experience more lock ups i'll let you know and try to figure out a way to gain access to some more debugging data. cheers. alex > > > >Robert > >___ > >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" > > -- a13x ___ 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 --- 2010-11-15 21:02:51 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-15 21:02:51 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-11-15 21:02:51 - cleaning the object tree TB --- 2010-11-15 21:02:54 - cvsupping the source tree TB --- 2010-11-15 21:02:54 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-11-15 21:03:32 - building world TB --- 2010-11-15 21:03:32 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-15 21:03:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-15 21:03:32 - TARGET=powerpc TB --- 2010-11-15 21:03:32 - TARGET_ARCH=powerpc64 TB --- 2010-11-15 21:03:32 - TZ=UTC TB --- 2010-11-15 21:03:32 - __MAKE_CONF=/dev/null TB --- 2010-11-15 21:03:32 - cd /src TB --- 2010-11-15 21:03:32 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 15 21:03:32 UTC 2010 >>> 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 -- cd /src; MAKEOBJDIRPREFIX=/obj/powerpc.powerpc64 MACHINE_ARCH=powerpc64 MACHINE=powerpc CPUTYPE= GROFF_BIN_PATH=/obj/powerpc.powerpc64/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/obj/powerpc.powerpc64/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/obj/powerpc.powerpc64/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/obj/powerpc.powerpc64/src/tmp VERSION="FreeBSD 8.0-STABLE amd64 800504" INSTALL="sh /src/tools/install.sh" PATH=/obj/powerpc.powerpc64/src/tmp/legacy/usr/sbin:/obj/powerpc.powerpc64/src/tmp/legacy/usr/bin:/obj/powerpc.powerpc64/src/tmp/legacy/usr/games:/obj/powerpc.powerpc64/src/tmp/usr/sbin:/obj/powerpc.powerpc64/src/tmp/usr/bin:/obj/powerpc.powerpc64/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin /usr/bin/make -f Makefile.inc1 DESTDIR=/obj/powerpc.powerpc64/src/tmp -DNO_FSCHG -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN -DWITHOUT_PROFILE libraries cd /src; /usr/bin/make -f Makefile.inc1 _prereq_libs; /usr/bin/make -f Makefile.inc1 _startup_libs; /usr/bin/make -f Makefile.inc1 _prebuild_libs; /usr/bin/make -f Makefile.inc1 _generic_libs; ===> gnu/lib/libssp/libssp_nonshared (obj,depend,all,install) rm -f .depend mkdep -f .depend -a-DHAVE_CONFIG_H -I/src/gnu/lib/libssp/libssp_nonshared/.. -I/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp -I/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/include -DPIC /src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp/ssp-local.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libssp/libssp_nonshared/.. -I/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp -I/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/include -fPIC -DPIC -fvisibility=hidden -std=gnu99 -fstack-protector -c /src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp/ssp-local.c Assembler messages: FATAL: can't create ssp-local.o: Invalid bfd target *** Error code 2 Stop in /src/gnu/lib/libssp/libssp_nonshared. *** 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 --- 2010-11-15 21:16:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-15 21:16:15 - ERROR: failed to build world TB --- 2010-11-15 21:16:15 - 584.23 user 114.09 system 803.44 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: sleep bug in taskqueue(9)
On Friday, November 12, 2010 4:24:51 pm m...@freebsd.org wrote: > On Fri, Nov 12, 2010 at 12:25 PM, Hans Petter Selasky wrote: > > On Friday 12 November 2010 17:38:38 m...@freebsd.org wrote: > >> On Fri, Nov 12, 2010 at 6:23 AM, Hans Petter Selasky > > wrote: > >> > On Friday 12 November 2010 15:18:46 m...@freebsd.org wrote: > >> >> On Fri, Nov 12, 2010 at 12:56 AM, Hans Petter Selasky > >> > > >> > wrote: > >> >> > On Thursday 29 April 2010 01:59:58 Matthew Fleming wrote: > >> >> >> It looks to me like taskqueue_drain(taskqueue_thread, foo) will not > >> >> >> correctly detect whether or not a task is currently running. The > >> >> >> check is against a field in the taskqueue struct, but for the > >> >> >> taskqueue_thread queue with more than one thread, multiple threads > >> >> >> can simultaneously be running a task, thus stomping over the > >> >> >> tq_running field. > >> >> >> > >> >> >> I have not seen any problem with the code as-is in actual use, so > >> >> >> this is purely an inspection bug. > >> >> >> > >> >> >> The following patch should fix the problem. Because it changes the > >> >> >> size of struct task I'm not sure if it would be suitable for MFC. > >> >> > > >> >> > 1) The u_char is going to leave a hole in that structure on ARM > >> >> > platforms for example. > >> >> > > >> >> > 2) The existing taskqueue implementation also has a missing check for > >> >> > the pending count wrapping to zero. I.E. it should stick at 0x > >> >> > and not wrap to 0. > >> >> > >> >> This commit mail is rather old, and this fix was incorrect, because > >> >> the task cannot be referenced after it has been run. Some task > >> >> handlers will free the task as part of the handler. > >> > > >> > Ok, maybe the e-mail got stuck somewhere. Have you fixed the above > >> > mentioned issues in a newer patch? > >> > >> If you look at the file history for subr_taskqueue.c: > >> > >> http://svn.freebsd.org/viewvc/base/head/sys/kern/subr_taskqueue.c > >> > >> You will see quite a few commits by me. The most recent relating to > >> detecting if a task is running is being MFC'd today: > > > > Yes, and I see that this code needs an overflow check, which is one of the > > issues still not fixed: > > You keep bringing this up. It is not a new issue. It is not a bug in > any of the patches. It is extremely unlikely that a task will be > queued 65536 times before execution. It is more worthy of an assert > rather than a check, because if a task is enqueued that many times > without being run then there's likely a stuck task in the queue. > > The patch you posted will lie as well, so I would not consider it > sufficient if someone wanted to address the issue. I agree it should be an assert. -- John Baldwin ___ 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: world build stuck in gnu for about a week for me.
eculp writes: > Thanks, Andreas. With a new cvsup this morning it now stops at a > different point for me: > > > Making grotty.1 from > /usr/src/gnu/usr.bin/groff/src/devices/grotty/../../../../../../contrib/groff/src/devices/grotty/grotty.man > gzip -cn grotty.1 > grotty.1.gz > ===> gnu/usr.bin/groff/src/preproc (all) > ===> gnu/usr.bin/groff/src/preproc/eqn (all) > c++ -O2 -pipe > -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/preproc/eqn > -I. -DHAVE_CONFIG_H > -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/include > -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../src/include > -fstack-protector -fno-rtti -fno-exceptions -c eqn.cpp > y.tab.c: In function 'int yygrowstack()': > y.tab.c:703: error: invalid conversion from 'void*' to 'short int*' > y.tab.c:709: error: invalid conversion from 'void*' to 'YYSTYPE*' > *** Error code 1 If you have r214990 try to reinstall yacc(1) before buildworld. $ make all install -C usr.bin/yacc ___ 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: world build stuck in gnu for about a week for me.
Quoting Andreas Tobler : On 14.11.10 16:40, eculp wrote: I build world several times a week on this machine: 9.0-CURRENT FreeBSD 9.0-CURRENT #126: Mon Nov 8 07:22:49 CST 2010 Since the above build I have not been able to get past gnu. Today it broke at gdb : ===> gnu/usr.bin/dialog (cleandir) ===> gnu/usr.bin/dialog/TESTS (cleandir) ===> gnu/usr.bin/diff (cleandir) ===> gnu/usr.bin/diff/doc (cleandir) rm -f diff.info diff.info.gz ===> gnu/usr.bin/diff3 (cleandir) ===> gnu/usr.bin/gdb (cleandir) ===> gnu/usr.bin/gdb/doc (cleandir) ===> gnu/usr.bin/gdb/libgdb (cleandir) Unclosed substitution for TARGET_ARCH (/ missing) This one was fixed today: http://svn.freebsd.org/viewvc/base?view=revision&revision=215292 Gruss, Andreas Thanks, Andreas. With a new cvsup this morning it now stops at a different point for me: Making grotty.1 from /usr/src/gnu/usr.bin/groff/src/devices/grotty/../../../../../../contrib/groff/src/devices/grotty/grotty.man gzip -cn grotty.1 > grotty.1.gz ===> gnu/usr.bin/groff/src/preproc (all) ===> gnu/usr.bin/groff/src/preproc/eqn (all) c++ -O2 -pipe -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/preproc/eqn -I. -DHAVE_CONFIG_H -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/include -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../src/include -fstack-protector -fno-rtti -fno-exceptions -c eqn.cpp y.tab.c: In function 'int yygrowstack()': y.tab.c:703: error: invalid conversion from 'void*' to 'short int*' y.tab.c:709: error: invalid conversion from 'void*' to 'YYSTYPE*' *** Error code 1 Stop in /usr/src/gnu/usr.bin/groff/src/preproc/eqn. *** Error code 1 Stop in /usr/src/gnu/usr.bin/groff/src/preproc. *** Error code 1 Stop in /usr/src/gnu/usr.bin/groff/src. *** Error code 1 Stop in /usr/src/gnu/usr.bin/groff. *** Error code 1 Stop in /usr/src/gnu/usr.bin. *** Error code 1 Stop in /usr/src/gnu. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. ed ___ 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"
