[releng_7 tinderbox] failure on amd64/amd64
TB --- 2008-01-19 08:22:43 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-01-19 08:22:43 - starting RELENG_7 tinderbox run for amd64/amd64 TB --- 2008-01-19 08:22:43 - cleaning the object tree TB --- 2008-01-19 08:22:45 - cvsupping the source tree TB --- 2008-01-19 08:22:45 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/amd64/amd64/supfile TB --- 2008-01-19 08:22:50 - building world (CFLAGS=-O2 -pipe) TB --- 2008-01-19 08:22:50 - cd /src TB --- 2008-01-19 08:22:50 - /usr/bin/make -B buildworld World build started on Sat Jan 19 08:22:51 UTC 2008 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 [...] === lib/libpam/modules/pam_rootok (buildincludes) === lib/libpam/modules/pam_securetty (buildincludes) === lib/libpam/modules/pam_self (buildincludes) === lib/libpam/modules/pam_ssh (buildincludes) === lib/libpam/modules/pam_tacplus (buildincludes) === lib/libpam/modules/pam_unix (buildincludes) === lib/libpam/libpam (buildincludes) make: don't know how to make security/openpam_attr.h. Stop *** Error code 2 Stop in /src/lib/libpam. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-01-19 08:34:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-01-19 08:34:07 - ERROR: failed to build world TB --- 2008-01-19 08:34:07 - tinderbox aborted TB --- 577.64 user 49.77 system 684.02 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-amd64-amd64.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[releng_7 tinderbox] failure on i386/i386
TB --- 2008-01-19 08:34:08 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-01-19 08:34:08 - starting RELENG_7 tinderbox run for i386/i386 TB --- 2008-01-19 08:34:08 - cleaning the object tree TB --- 2008-01-19 08:34:10 - cvsupping the source tree TB --- 2008-01-19 08:34:10 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile TB --- 2008-01-19 08:34:16 - building world (CFLAGS=-O2 -pipe) TB --- 2008-01-19 08:34:16 - cd /src TB --- 2008-01-19 08:34:16 - /usr/bin/make -B buildworld World build started on Sat Jan 19 08:34:16 UTC 2008 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 [...] === lib/libpam/modules/pam_rootok (buildincludes) === lib/libpam/modules/pam_securetty (buildincludes) === lib/libpam/modules/pam_self (buildincludes) === lib/libpam/modules/pam_ssh (buildincludes) === lib/libpam/modules/pam_tacplus (buildincludes) === lib/libpam/modules/pam_unix (buildincludes) === lib/libpam/libpam (buildincludes) make: don't know how to make security/openpam_attr.h. Stop *** Error code 2 Stop in /src/lib/libpam. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-01-19 08:44:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-01-19 08:44:48 - ERROR: failed to build world TB --- 2008-01-19 08:44:48 - tinderbox aborted TB --- 532.79 user 42.16 system 640.95 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-i386.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[releng_7 tinderbox] failure on i386/pc98
TB --- 2008-01-19 08:44:49 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-01-19 08:44:49 - starting RELENG_7 tinderbox run for i386/pc98 TB --- 2008-01-19 08:44:49 - cleaning the object tree TB --- 2008-01-19 08:44:53 - cvsupping the source tree TB --- 2008-01-19 08:44:53 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/pc98/supfile TB --- 2008-01-19 08:44:58 - building world (CFLAGS=-O2 -pipe) TB --- 2008-01-19 08:44:58 - cd /src TB --- 2008-01-19 08:44:58 - /usr/bin/make -B buildworld World build started on Sat Jan 19 08:44:59 UTC 2008 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 [...] === lib/libpam/modules/pam_rootok (buildincludes) === lib/libpam/modules/pam_securetty (buildincludes) === lib/libpam/modules/pam_self (buildincludes) === lib/libpam/modules/pam_ssh (buildincludes) === lib/libpam/modules/pam_tacplus (buildincludes) === lib/libpam/modules/pam_unix (buildincludes) === lib/libpam/libpam (buildincludes) make: don't know how to make security/openpam_attr.h. Stop *** Error code 2 Stop in /src/lib/libpam. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-01-19 08:55:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-01-19 08:55:39 - ERROR: failed to build world TB --- 2008-01-19 08:55:39 - tinderbox aborted TB --- 532.77 user 41.67 system 650.78 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-pc98.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[releng_7 tinderbox] failure on ia64/ia64
TB --- 2008-01-19 08:55:40 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-01-19 08:55:40 - starting RELENG_7 tinderbox run for ia64/ia64 TB --- 2008-01-19 08:55:40 - cleaning the object tree TB --- 2008-01-19 08:55:43 - cvsupping the source tree TB --- 2008-01-19 08:55:43 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/ia64/ia64/supfile TB --- 2008-01-19 08:55:48 - building world (CFLAGS=-O2 -pipe) TB --- 2008-01-19 08:55:48 - cd /src TB --- 2008-01-19 08:55:48 - /usr/bin/make -B buildworld World build started on Sat Jan 19 08:55:49 UTC 2008 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 [...] === lib/libpam/modules/pam_rootok (buildincludes) === lib/libpam/modules/pam_securetty (buildincludes) === lib/libpam/modules/pam_self (buildincludes) === lib/libpam/modules/pam_ssh (buildincludes) === lib/libpam/modules/pam_tacplus (buildincludes) === lib/libpam/modules/pam_unix (buildincludes) === lib/libpam/libpam (buildincludes) make: don't know how to make security/openpam_attr.h. Stop *** Error code 2 Stop in /src/lib/libpam. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-01-19 09:05:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-01-19 09:05:38 - ERROR: failed to build world TB --- 2008-01-19 09:05:38 - tinderbox aborted TB --- 507.55 user 40.97 system 598.97 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-ia64-ia64.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[releng_7 tinderbox] failure on powerpc/powerpc
TB --- 2008-01-19 09:05:39 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-01-19 09:05:39 - starting RELENG_7 tinderbox run for powerpc/powerpc TB --- 2008-01-19 09:05:39 - cleaning the object tree TB --- 2008-01-19 09:05:41 - cvsupping the source tree TB --- 2008-01-19 09:05:41 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/powerpc/powerpc/supfile TB --- 2008-01-19 09:05:46 - building world (CFLAGS=-O2 -pipe) TB --- 2008-01-19 09:05:46 - cd /src TB --- 2008-01-19 09:05:46 - /usr/bin/make -B buildworld World build started on Sat Jan 19 09:05:47 UTC 2008 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 [...] === lib/libpam/modules/pam_rootok (buildincludes) === lib/libpam/modules/pam_securetty (buildincludes) === lib/libpam/modules/pam_self (buildincludes) === lib/libpam/modules/pam_ssh (buildincludes) === lib/libpam/modules/pam_tacplus (buildincludes) === lib/libpam/modules/pam_unix (buildincludes) === lib/libpam/libpam (buildincludes) make: don't know how to make security/openpam_attr.h. Stop *** Error code 2 Stop in /src/lib/libpam. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-01-19 09:16:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-01-19 09:16:21 - ERROR: failed to build world TB --- 2008-01-19 09:16:21 - tinderbox aborted TB --- 532.64 user 42.02 system 642.79 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-powerpc-powerpc.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[releng_7 tinderbox] failure on sparc64/sparc64
TB --- 2008-01-19 09:16:22 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-01-19 09:16:22 - starting RELENG_7 tinderbox run for sparc64/sparc64 TB --- 2008-01-19 09:16:22 - cleaning the object tree TB --- 2008-01-19 09:16:31 - cvsupping the source tree TB --- 2008-01-19 09:16:31 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/sparc64/sparc64/supfile TB --- 2008-01-19 09:16:38 - building world (CFLAGS=-O2 -pipe) TB --- 2008-01-19 09:16:38 - cd /src TB --- 2008-01-19 09:16:38 - /usr/bin/make -B buildworld World build started on Sat Jan 19 09:16:39 UTC 2008 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 [...] === lib/libpam/modules/pam_rootok (buildincludes) === lib/libpam/modules/pam_securetty (buildincludes) === lib/libpam/modules/pam_self (buildincludes) === lib/libpam/modules/pam_ssh (buildincludes) === lib/libpam/modules/pam_tacplus (buildincludes) === lib/libpam/modules/pam_unix (buildincludes) === lib/libpam/libpam (buildincludes) make: don't know how to make security/openpam_attr.h. Stop *** Error code 2 Stop in /src/lib/libpam. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-01-19 09:26:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-01-19 09:26:33 - ERROR: failed to build world TB --- 2008-01-19 09:26:33 - tinderbox aborted TB --- 448.73 user 41.09 system 611.18 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-sparc64-sparc64.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PCI MSI (was Re: What current Dell Systems are supported/work)
in message [EMAIL PROTECTED], wrote John Baldwin thusly... On Friday 18 January 2008 08:50:31 am John Baldwin wrote: On Friday 18 January 2008 05:30:06 am Parv wrote: There was no page fault or trap 12 message when the panic happened. After some of messages are printed (as in dmesg), kdb is entered ... ioapic0: Assigning PCI IRQ 23 to local APIC 1 msi: Assigning MSI IRQ 256 to local APIC 0 panic: blockabke sleep block (sleep mutex) msi @ /misc/src-6/sys/i386/i386/msi.c:381 cpuid: 0 kdb: stack backtrace kbd_backtrace( c0adc531,0,c0abaafd,c1020c34,c0bab700,...) at ... \ [I skipped from here to the db prompt] ... Tomorrow, rather later today, I will type up the trace output. Please let me know if you would like to see any other output that I could possibly provide. This is good enough for me to see the bug, I'll work on fixing it. There are some locking changes in the x86 interrupt code I need to MFC. Try this patch: ... Thanks much John. Your patch allowed my computer to resume normal operation without disabling MSI via hw.pci.enable_msi*. Lest I forget, mahalo for saving me from typing up the trace output. - Parv -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ipfwpcap in 6.3 ?
Hi! In http://www.freebsd.org/releases/6.3R/relnotes-i386.html ipfwpcap(8) is mentioned, but I can't find it after the upgrade ? -- [EMAIL PROTECTED]+49 171 310137212 years to go ! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic when copying to ext2fs
I have tried these options in the config, but with same results (unstoppable dump and crash): makeoptions DEBUG=-g options WITNESS options WITNESS_KDB options KDB options KDB_TRACE options DIAGNOSTIC options KDB options DDB options GDB options INVARIANTS options INVARIANT_SUPPORT options DEBUG_LOCKS options DEBUG_VFS_LOCKS I haven't tried debugging via serial port, however. And the problem can be reproduced on ext2fs volume of any size. Next step would be original GENERIC config. Jakub On Sat, 19 Jan 2008 00:12:18 +0100 Kris Kennaway [EMAIL PROTECTED] wrote: Jakub Siroky wrote: I have two large ext2fs partitions (368 and 313GB) to hold data shared between several OSes. While there were no problems on 6-STABLE branch I was quite disappointed after upgrade to 7-STABLE. Whenever I copy/write to ext2fs partition the system freezes totally without crashdump. So I set debugging settings to kernel config (DEBUG,WITNESS,..) and in console I reproduced error situation ending with full screen of unstoppable running text with lot of memory addresses and a few recognisable words: 'new block bit set for ext already' - again with no crashdump. Then I have formatted 1GB partition with ext2fs and the problem on this small partition appears only sometimes. 1) Please wrap your lines so your emails can be easily read. 2) Check the developer's handbook, it explains how to configure the debugger so you can investigate this further. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nscd again
Hi Denis, Several things: 1. You definitely can't use cache for *_compat sources. I mean lines like group_compat: cache nis aren't supported. 2. Cache should work ok with the configuration you've mentioned in your first example, i.e.: group: cache compat. Just checking - why do you think that cache isn't working? The correct way to determine it is to perform the same query twice. During the first pass (when query is not cached), the request will be processed by NIS module and you'll have all the NIS-related stuff in the logs. On the second pass the request should be handled by scd module - and you shouldn't see any activity in NIS logs. It would be great to see the debug log (with nscd log turned on) separately - for the first and the second pass. It would help to find the error in nscd, if there is one. With best regards, Michael Bushkov On Jan 17, 2008, at 9:55 PM, Denis Barov wrote: Hello! I found some strange behaviour of NIS/nscd when NIS in compat mode. In /etc/nsswitch.conf I have: netgroup: cache compat passwd: cache compat group:cache compat #group_compat: cache nis #passwd_compat:cache nis in /etc/nscd.conf: #nscd.conf threads 16 enable-cache passwd yes keep-hot-count passwd 20480 positive-time-to-live passwd 36000 enable-cache group yes keep-hot-count group 20480 positive-time-to-live group 36000 enable-cache group_compat yes keep-hot-count group_compat 20480 positive-time-to-live group.byname 36000 enable-cache passwd_compat yes keep-hot-count passwd_compat 20480 positive-time-to-live passwd_compat 36000 enable-cache netgroup yes keep-hot-count netgroup 20480 positive-time-to-live netgroup 36000 But, when I do some actions on NIS-client host (host with ypbind), host ignoring cached data. In ypserv debug log: ... ypserv: retrieving next key, previous was: [XXX] ypserv: result of lookup: key: [X] data: [XX:*:1168:] ypserv: procedure ypproc_next called from XXX.XXX.XXX.XXX:739 ypserv: client is referencing map group.byname. ypserv: retrieving next key, previous was: [XXX] ypserv: result of lookup: key: [baytin] data: [XX:*:1220:] ypserv: procedure ypproc_next called from XXX.XXX.XXX.XXX:739 ypserv: client is referencing map group.byname. ypserv: retrieving next key, previous was: [XX] ypserv: result of lookup: key: [] data: [:*:3012:] ypserv: procedure ypproc_next called from XXX.XXX.XXX.XXX:739 ypserv: client is referencing map group.byname. ypserv: retrieving next key, previous was: [] ypserv: result of lookup: key: [XXX] data: [XXX:*:3021:] ypserv: procedure ypproc_next called from XXX.XXX.XXX.XXX:739 ypserv: client is referencing map group.byname. ypserv: retrieving next key, previous was: [XXX] ypserv: result of lookup: key: [vereschagin] data: [XXX:*: 3024:] ypserv: procedure ypproc_next called from XXX.XXX.XXX.XXX:739 ypserv: client is referencing map group.byname. ypserv: retrieving next key, previous was: [XXX] ... If I set in nsswitch.conf: netgroup: cache compat passwd: cache compat group:cache compat group_compat: cache nis passwd_compat:cache nis I have other errors: Jan 17 21:53:13 mfas002 sudo: NSSWITCH(nss_method_lookup): cache, passwd_compat, setpwent, not found Jan 17 21:53:15 mfas002 sudo: NSSWITCH(nss_method_lookup): cache, group_compat, setgrent, not found Jan 17 21:53:15 mfas002 sudo: NSSWITCH(nss_method_lookup): cache, group_compat, getgrent_r, not found Jan 17 21:53:15 mfas002 last message repeated 197 times Jan 17 21:53:15 mfas002 sudo: NSSWITCH(nss_method_lookup): cache, group_compat, endgrent, not found Jan 17 21:53:15 mfas002 sudo: NSSWITCH(nss_method_lookup): cache, passwd_compat, endpwent, not found Jan 17 21:53:15 mfas002 sudo: NSSWITCH(nss_method_lookup): cache, group_compat, endgrent, not found Seems group_compat and passwd_compat databases can't operate with cache sourse. Is that true? -- Denis Barov| /\ Yandex WEB-Search Administration Team | \ / ASCII Ribbon Campaign phone: : +7 (495) 739-70-00 add. 7154 | X NO HTML/RTF in e-mail e-mail: [EMAIL PROTECTED] | / \ NO Word docs in e-mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic when copying to ext2fs
Jakub Siroky wrote: I have tried these options in the config, but with same results (unstoppable dump and crash): makeoptions DEBUG=-g options WITNESS options WITNESS_KDB options KDB options KDB_TRACE options DIAGNOSTIC options KDB options DDB options GDB options INVARIANTS options INVARIANT_SUPPORT options DEBUG_LOCKS options DEBUG_VFS_LOCKS I haven't tried debugging via serial port, however. And the problem can be reproduced on ext2fs volume of any size. Next step would be original GENERIC config. What do you mean by unstoppable? Can you not break to DDB from the console? Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Questions about building the world
On 1/19/08, Vlad GALU [EMAIL PROTECTED] wrote: 1. I noticed the WITHOUT_SSP switch in src.conf(5). Does this mean that Propolice is currently used by default? 2. For debugging purposes, I'd like to rebuild my whole world with debugging symbols. Adding -g to the flags in make.conf seemed to do the trink until right before the installation of the new files. Doing a nm on libc.so.7 yielded all the symbols, as expected. However, after performing the installworld, the library was stripped. Is there a switch to prevent stripping too? Seems that DEBUG_FLAGS=-g in src.conf did the trick. I should have RTFM. -- Mahnahmahnah! -- Mahnahmahnah! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Questions about building the world
1. I noticed the WITHOUT_SSP switch in src.conf(5). Does this mean that Propolice is currently used by default? 2. For debugging purposes, I'd like to rebuild my whole world with debugging symbols. Adding -g to the flags in make.conf seemed to do the trink until right before the installation of the new files. Doing a nm on libc.so.7 yielded all the symbols, as expected. However, after performing the installworld, the library was stripped. Is there a switch to prevent stripping too? -- Mahnahmahnah! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0-PRERELEASE desktop system periodically freezes momentarily
Kris, I caught this one during what I'd class as normal usage, with a handful of apps open, and no glxgears or other glx apps (intentionally) running. It shows Epiphany getting cpu solidly for 2 seconds! If you crank up the ticks per pixel and scroll to the end you can't miss it. This typifies an event that occurs regularly for me in my normal desktop use, albeit I normally use firefox with a large number of windows and tabs open. I'd long suspected that firefox might be involved in some of the pauses I've been experiencing. I'm quite chuffed about getting this one. http://au.dyndns.ws/public/ktr-sched-200801192346.out.bz2 Wayne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic when copying to ext2fs
No, I cannot. While in normal operation the Ctrl+Alt+Esc on console brings debugger screen, in this crash condition even the NumLock does not work. Jakub On Sat, 19 Jan 2008 14:52:08 +0100 Kris Kennaway [EMAIL PROTECTED] wrote: Jakub Siroky wrote: I have tried these options in the config, but with same results (unstoppable dump and crash): makeoptions DEBUG=-g options WITNESS options WITNESS_KDB options KDB options KDB_TRACE options DIAGNOSTIC options KDB options DDB options GDB options INVARIANTS options INVARIANT_SUPPORT options DEBUG_LOCKS options DEBUG_VFS_LOCKS I haven't tried debugging via serial port, however. And the problem can be reproduced on ext2fs volume of any size. Next step would be original GENERIC config. What do you mean by unstoppable? Can you not break to DDB from the console? Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: infinite loop when copying to ext2fs
Jakub Siroky wrote: I have two large ext2fs partitions (368 and 313GB) to hold data shared between several OSes. While there were no problems on 6-STABLE branch I was quite disappointed after upgrade to 7-STABLE. Whenever I copy/write to ext2fs partition the system freezes totally without crashdump. So I set debugging settings to kernel config (DEBUG,WITNESS,..) and in console I reproduced error situation ending with full screen of unstoppable running text with lot of memory addresses and a few recognisable words: 'new block bit set for ext already' - again with no crashdump. Then I have formatted 1GB partition with ext2fs and the problem on this small partition appears only sometimes. OK, I am able to reproduce this. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
7-stable: apache+php5 in a jail?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have an issue with apache and php5 inside a jail on 7-stable where the executable simply dumps core on start-up in the threading library. I've recompiled everything inside and outside the jail but the behaviour remains the same :-( I have no idea how to go about debugging this .. any helpful suggestions welcome .. #0 0x28c4cac8 in ?? () from /lib/libthr.so.3 [New Thread 0x282b9500 (LWP 100378)] (gdb) bt #0 0x28c4cac8 in ?? () from /lib/libthr.so.3 #1 0x2818f65c in getprotoent_r () from /lib/libc.so.7 #2 0x2812ba87 in getprotobyname () from /lib/libc.so.7 #3 0x28bf1cd7 in zm_startup_sockets () from /usr/local/lib/php/20060613/sockets.so #4 0x287d5f30 in zend_startup_module_ex () from /usr/local/libexec/apache/libphp5.so #5 0x287dac0c in zend_hash_apply () from /usr/local/libexec/apache/libphp5.so #6 0x287d497c in zend_startup_modules () from /usr/local/libexec/apache/libphp5.so #7 0x28792bed in php_module_startup () from /usr/local/libexec/apache/libphp5.so #8 0x28849453 in php_apache_startup () from /usr/local/libexec/apache/libphp5.so #9 0x288dd180 in apache_functions () from /usr/local/libexec/apache/libphp5.so #10 0x0001 in ?? () #11 0x in ?? () #12 0x0001 in ?? () #13 0x288dcf60 in php_commands () from /usr/local/libexec/apache/libphp5.so #14 0xbfbfca78 in ?? () #15 0x2884969f in php_init_handler () from /usr/local/libexec/apache/libphp5.so #16 0x in ?? () #17 0x288496b0 in php_init_handler () from /usr/local/libexec/apache/libphp5.so #18 0x in ?? () #19 0x28204010 in ?? () #20 0xbfbfcaa8 in ?? () #21 0x080545c9 in ap_init_modules () Previous frame inner to this frame (corrupt stack?) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAkeSHF0ACgkQQv9rrgRC1JL4bgCfb5ri0Xw2XF5PUbi2liyzu7yO oQkAoIQhTKTLx+kdttWs2eYy1IT4IvEd =55w2 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nscd again
Michael Bushkov wrote: Hi Denis, Several things: 1. You definitely can't use cache for *_compat sources. I mean lines like group_compat: cache nis aren't supported. This should be mentioned in the man page. To me it also speaks to the need for a default /etc/nsswitch.conf with comments. It is way too easy to misconfigure this stuff. Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0-PRERELEASE desktop system periodically freezes momentarily
Kris, Another one, this time xorg for 2 seconds, approximately in the middle. I'm feeling inclined to doubt the validity of this and the previous data set, however. Looking at the tail end of each of the events in question, there is clearly activity on other processes before the supposedly long exclusive cpu event terminates. Unless this is some limitation of the schedgraph.py script, or the ktr logging mechanism, etc., then this must surely indicate that they are not valid captures? I am all the more inclined to question them because the very next capture/dump I did after the previous set was captured looked so similar to it that I felt prompted to do a diff between the files and found that they contained identical lines for the most part, with only approx every nth line being different (for n=about 4 or so - I don't recall exactly and unfortunately didn't keep that particular one). Is it sufficient to just set debug.ktr.mask to resume capturing, or is it necessary to set debug.ktr.clear? (Note that so far there has always a substantial time interval between setting the mask and clearing it again, at least some minutes and usually much more, so I've assumed that there's plenty of logging occurring to over-write the previous contents). I should also have mentioned that I'm getting these messages periodically: ums0: at uhub0 port 2 (addr 2) disconnected ums0: detached ums0: B16_b_02 USB-PS/2 Optical Mouse, class 0/0, rev 2.00/98.02, addr 2 on uhub0 ums0: 8 buttons and Z dir. which for the moment I'm assuming are related to running the KTR-enabled kernel as I can't recall seeing these previously. http://au.dyndns.ws/public/ktr-sched-200801200336.out.bz2 Wayne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Swapping caused by very large (regular) file size
* Thomas Hurst ([EMAIL PROTECTED]) wrote: * Kris Kennaway ([EMAIL PROTECTED]) wrote: Excellent. I've been seeing this behavior for a long time, mostly on backup runs (RAID-1 amr SATA - 1 disk Marvell ata). It's pretty odd seeing a system with 8G of memory, 60% of which is just cache, swap out half a dozen things for no apparant reason. And to think, people on FreeNode ##freebsd just insisted I had a misconfigured system ;) 7 does indeed seem to resolve this. Also, no sign of corruption on my Marvell 88SX6081, at least during serial read tests. I'll test with a level 0 dump tonight; my writes go via tee to the filesystem and sha1(1) so I should pick up any silent corruption. Doh: http://voi.aagh.net/voi.nightsdawn.sf-swap-day.png Making a 100GB dump of /usr, then making a par2 set results in minor paging activity all through it. Running sha1 over the dump has a similar effect. It settles around 2.5MB swap now, though; 6 would quickly settle around 10MB, so it does appear to be improved somewhat; top isn't showing fetchmail and friends as swapped for instance. This is off a single ata(4) disk, which peaks around 65MB/s. sha1 file results match that from the dump|tee file|sha1 file.sha1 at least :) -- Thomas 'Freaky' Hurst http://hur.st/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nscd again
On Jan 19, 2008, at 7:26 PM, Doug Barton wrote: Michael Bushkov wrote: Hi Denis, Several things: 1. You definitely can't use cache for *_compat sources. I mean lines like group_compat: cache nis aren't supported. This should be mentioned in the man page. To me it also speaks to the need for a default /etc/nsswitch.conf with comments. It is way too easy to misconfigure this stuff. Agreed. I'll fix the man page. With best regards, Michael Bushkov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Swapping caused by very large (regular) file size
Thomas Hurst wrote: * Thomas Hurst ([EMAIL PROTECTED]) wrote: * Kris Kennaway ([EMAIL PROTECTED]) wrote: Excellent. I've been seeing this behavior for a long time, mostly on backup runs (RAID-1 amr SATA - 1 disk Marvell ata). It's pretty odd seeing a system with 8G of memory, 60% of which is just cache, swap out half a dozen things for no apparant reason. And to think, people on FreeNode ##freebsd just insisted I had a misconfigured system ;) 7 does indeed seem to resolve this. Also, no sign of corruption on my Marvell 88SX6081, at least during serial read tests. I'll test with a level 0 dump tonight; my writes go via tee to the filesystem and sha1(1) so I should pick up any silent corruption. Doh: http://voi.aagh.net/voi.nightsdawn.sf-swap-day.png Making a 100GB dump of /usr, then making a par2 set results in minor paging activity all through it. Running sha1 over the dump has a similar effect. It settles around 2.5MB swap now, though; 6 would quickly settle around 10MB, so it does appear to be improved somewhat; top isn't showing fetchmail and friends as swapped for instance. This is off a single ata(4) disk, which peaks around 65MB/s. sha1 file results match that from the dump|tee file|sha1 file.sha1 at least :) I don't understand your test procedure, can you elaborate? Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Swapping caused by very large (regular) file size
Thomas Hurst wrote:
* Kris Kennaway ([EMAIL PROTECTED]) wrote:
I don't understand your test procedure, can you elaborate?
The spikes from last night are from:
(/sbin/dump -$level -LuaC128 -f - $fs | /usr/bin/tee ${target} |
/sbin/sha1 ${target}.sha1)
Followed by:
nice -n 19 /home/freaky/bin/par2 c -t+ -r5 -m256 ${target}
Graphs from this run clearly slow a modest amount of paging activity
while it occurs; you can see the other graphs here:
http://voi.aagh.net/backupmunin/
More simply, it can be reproduced by doing this:
-# swapoff -a # clear swap
-# swapon -a
-# top |grep -A1 Mem
Mem: 1371M Active, 5727M Inact, 416M Wired, 271M Cache, 214M Buf, 124M
Free
Swap: 10G Total, 10G Free
-# ls -l voi_20080119_#usr.dmp.0
-rw-r--r--1 root wheel106527672320 Jan 19 05:27
voi_20080119_#usr.dmp.0
-# cat voi_20080119_#usr.dmp.0 /dev/null
-% sleep 20 top |grep -A1 Mem
Mem: 1407M Active, 5789M Inact, 431M Wired, 272M Cache, 214M Buf, 8580K
Free
Swap: 10G Total, 400K Used, 10G Free
The system's occasionally deciding to swap pages out rather than recycle
something from the huge pool of inactive/cache memory (which atm will be
mostly cached pages from this file, since this is my second test run;
the first took longer to ramp up).
-% uname -a
FreeBSD voi.nightsdawn.sf 7.0-RC1 FreeBSD 7.0-RC1 #0: Wed Jan 16
14:56:50 GMT 2008
Thanks, I will try to reproduce.
Kris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Swapping caused by very large (regular) file size
* Kris Kennaway ([EMAIL PROTECTED]) wrote:
I don't understand your test procedure, can you elaborate?
The spikes from last night are from:
(/sbin/dump -$level -LuaC128 -f - $fs | /usr/bin/tee ${target} |
/sbin/sha1 ${target}.sha1)
Followed by:
nice -n 19 /home/freaky/bin/par2 c -t+ -r5 -m256 ${target}
Graphs from this run clearly slow a modest amount of paging activity
while it occurs; you can see the other graphs here:
http://voi.aagh.net/backupmunin/
More simply, it can be reproduced by doing this:
-# swapoff -a # clear swap
-# swapon -a
-# top |grep -A1 Mem
Mem: 1371M Active, 5727M Inact, 416M Wired, 271M Cache, 214M Buf, 124M
Free
Swap: 10G Total, 10G Free
-# ls -l voi_20080119_#usr.dmp.0
-rw-r--r--1 root wheel106527672320 Jan 19 05:27
voi_20080119_#usr.dmp.0
-# cat voi_20080119_#usr.dmp.0 /dev/null
-% sleep 20 top |grep -A1 Mem
Mem: 1407M Active, 5789M Inact, 431M Wired, 272M Cache, 214M Buf, 8580K
Free
Swap: 10G Total, 400K Used, 10G Free
The system's occasionally deciding to swap pages out rather than recycle
something from the huge pool of inactive/cache memory (which atm will be
mostly cached pages from this file, since this is my second test run;
the first took longer to ramp up).
-% uname -a
FreeBSD voi.nightsdawn.sf 7.0-RC1 FreeBSD 7.0-RC1 #0: Wed Jan 16
14:56:50 GMT 2008
--
Thomas 'Freaky' Hurst
http://hur.st/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
nscd for STABLE_6_3?
Hi there, is there a nscd or something similar to nscd (cached) for the current STABLE_6_3? I'm interested in caching nsswitch (pgsql) queries so I can stop overloading the pg server. any ideas/experience? Cheers, valqk. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
7-STABLE broke drscheme in week between 4 and 11 Jan
Hi there, I'm still working on debugging this myself, but thought that a few more experienced eyes might be able to help me. I'm tracking 7-STABLE on my amd64 system, but something happened a couple of weeks ago that broke lang/drscheme. I've been doing a bit of regressing and testing, and have found that a mred executable built against a 7-STABLE checkout of 2008.01.04.00.00.00 works fine, but the exact same binary crashes with a SEGV on a kernel check-out of 2008.01.11.00.00.00. It's a bit hard to debug, because the code in question is a twisty maze of macros, #ifs and inlines, because it's in the garbage collector, and that's quite platform-sensitive. Anyway, the last part of the ktrace of the broken version (the earlier parts are just loading up shared libraries) looks like: (I sedded the ^pid out, so that I could get a better look at it with diff (meld, actually: it's nice)). mredid mred RET mmap 5496832/0x80053e000 mredid mred CALL mmap(0,0x20,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0x,0) mredid mred RET mmap 57888768/0x803735000 mredid mred CALL munmap(0x803735000,0xcb000) mredid mred RET munmap 0 mredid mred CALL munmap(0x80390,0x35000) mredid mred RET munmap 0 mredid mred CALL thr_self(0x803801120) mredid mred RET thr_self 0 mredid mred CALL mmap(0x7fbff000,0x1000,PROT_NONE,MAP_ANON,0x,0) mredid mred RET mmap -4198400/0x7fbff000 mredid mred CALL thr_set_name(0x1875d,0x802de3800) mredid mred RET thr_set_name 0 mredid mred CALL rtprio_thread(0,0x1875d,0x7fffe110) mredid mred RET rtprio_thread 0 mredid mred CALL sysarch(0x81,0x7fffe130) mredid mred RET sysarch 0 mredid mred CALL sigprocmask(SIG_SETMASK,0x7fffe150,0x7fffe140) mredid mred RET sigprocmask 0 mredid mred CALL sigaction(SIG 32,0x7fffe110,0) mredid mred RET sigaction 0 mredid mred CALL sigprocmask(SIG_SETMASK,0x7fffe140,0) mredid mred RET sigprocmask 0 mredid mred CALL sigprocmask(SIG_BLOCK,0x800633cc0,0x7fffe190) mredid mred RET sigprocmask 0 mredid mred CALL sigprocmask(SIG_SETMASK,0x800633cd0,0) mredid mred RET sigprocmask 0 mredid mred CALL getrlimit(RLIMIT_DATA,0x7fffe3a0) mredid mred RET getrlimit 0 mredid mred CALL mmap(0,0x104000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0x,0) mredid mred RET mmap 59768832/0x80390 mredid mred PSIG SIGSEGV SIG_DFL mredid mred NAMI mred.core The equivalent section of the version from 4 Jan (that works fine) looks like: mredid mred RET mmap 5496832/0x80053e000 mredid mred CALL mmap(0,0x20,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0x,0) mredid mred RET mmap 57835520/0x803728000 mredid mred CALL munmap(0x803728000,0xd8000) mredid mred RET munmap 0 mredid mred CALL munmap(0x80390,0x28000) mredid mred RET munmap 0 mredid mred CALL thr_self(0x803801120) mredid mred RET thr_self 0 mredid mred CALL mmap(0x7fbff000,0x1000,PROT_NONE,MAP_ANON,0x,0) mredid mred RET mmap -4198400/0x7fbff000 mredid mred CALL thr_set_name(0x187ba,0x802dd6800) mredid mred RET thr_set_name 0 mredid mred CALL rtprio_thread(0,0x187ba,0x7fffe0f0) mredid mred RET rtprio_thread 0 mredid mred CALL sysarch(0x81,0x7fffe110) mredid mred RET sysarch 0 mredid mred CALL sigprocmask(SIG_SETMASK,0x7fffe130,0x7fffe120) mredid mred RET sigprocmask 0 mredid mred CALL sigaction(SIG 32,0x7fffe0f0,0) mredid mred RET sigaction 0 mredid mred CALL sigprocmask(SIG_SETMASK,0x7fffe120,0) mredid mred RET sigprocmask 0 mredid mred CALL sigprocmask(SIG_BLOCK,0x800633cc0,0x7fffe170) mredid mred RET sigprocmask 0 mredid mred CALL sigprocmask(SIG_SETMASK,0x800633cd0,0) mredid mred RET sigprocmask 0 mredid mred CALL getrlimit(RLIMIT_DATA,0x7fffe380) mredid mred RET getrlimit 0 mredid mred CALL mmap(0,0x104000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0x,0) mredid mred RET mmap 59768832/0x80390 mredid mred CALL mmap(0,0x30,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0x,0) mredid mred RET mmap 60833792/0x803a04000 mredid mred CALL munmap(0x803a04000,0xfc000) mredid mred RET munmap 0 mredid mred CALL munmap(0x803d0,0x4000) mredid mred RET munmap 0 mredid mred CALL sigaction(SIGSEGV,0x7fffe360,0x7fffe340) mredid mred RET sigaction 0 mredid mred CALL __sysctl(0x7fffd8f0,0x2,0x7fffd950,0x7fffd8e8,0,0) mredid mred RET __sysctl 0 mredid mred CALL socket(PF_LOCAL,SOCK_STREAM,0) mredid mred RET socket 3 mredid mred CALL __sysctl(0x7fffd910,0x2,0x7fffd970,0x7fffd908,0,0) mredid mred RET __sysctl 0 mredid mred CALL
patch for review: ATI SB600 SATA AHCI
Hi!
I've done the following local changes to get the ATA controller being
correctly detected and initialized as an AHCI controller on an HP
6715b notebook using ATI SB-600 chipset. With stock kernel, the ATA
controller is being recognized as a generic ATA controller and devices
being driven in UDMA-33 mode.
With the following patch, the controller is being initialized in AHCI
mode and devices being set to SATA-150/300 mode.
atapci0: ATI IXP600 SATA300 controller port
0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f
mem 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0
atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x5020
atapci0: Reserved 0x400 bytes for rid 0x24 type 3 at 0xd0609000
atapci0: [MPSAFE]
atapci0: [ITHREAD]
atapci0: AHCI Version 01.10 controller with 4 ports detected
%atacontrol mode ad4
current mode = SATA150
My patch has been tested on RELENG_7 as of 2008-01-19. Please review,
check and test if possible. Should work on 8-CURRENT, too.
If nobody complains until tuesday (2008-01-22), I'll file a PR for
that patch.
Volker
--- sys/dev/ata/ata-chipset.c.orig 2008-01-20 03:22:37.0
+0100
+++ sys/dev/ata/ata-chipset.c 2008-01-20 03:30:03.0 +0100
@@ -1348,6 +1348,7 @@
{ ATA_ATI_IXP400_S1, 0x00, SIIMEMIO, 0, ATA_SA150, IXP400 },
{ ATA_ATI_IXP400_S2, 0x00, SIIMEMIO, 0, ATA_SA150, IXP400 },
{ ATA_ATI_IXP600,0x00, 0,0, ATA_UDMA6, IXP600 },
+ { ATA_ATI_IXP600_S1, 0x00, 0, AHCI, ATA_SA300, IXP600 },
{ ATA_ATI_IXP700,0x00, 0,0, ATA_UDMA6, IXP700 },
{ 0, 0, 0, 0, 0, 0}};
@@ -1360,7 +1361,10 @@
if (ctlr-chip-cfg1 SIIMEMIO)
ctlr-chipinit = ata_sii_chipinit;
else
- ctlr-chipinit = ata_ati_chipinit;
+ if (ctlr-chip-cfg2 AHCI)
+ ctlr-chipinit = ata_ahci_chipinit;
+ else
+ ctlr-chipinit = ata_ati_chipinit;
return 0;
}
--- sys/dev/ata/ata-pci.h.orig 2008-01-20 03:22:28.0 +0100
+++ sys/dev/ata/ata-pci.h 2008-01-20 03:23:56.0 +0100
@@ -104,6 +104,7 @@
#define ATA_ATI_IXP400_S1 0x43791002
#define ATA_ATI_IXP400_S2 0x437a1002
#define ATA_ATI_IXP600 0x438c1002
+#define ATA_ATI_IXP600_S1 0x43801002
#define ATA_ATI_IXP700 0x439c1002
#define ATA_CENATEK_ID 0x16ca
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
