Re: /usr/bin/tar creates invalid lib file
26.03.2012 03:25, Tim Kientzle пишет: On Mar 25, 2012, at 2:43 PM, Gleb Kurtsou wrote: On (25/03/2012 10:53), Tim Kientzle wrote: On Mar 25, 2012, at 5:53 AM, Boris Samorodov wrote: On 24.03.2012 21:00, Tim Kientzle wrote: On Mar 23, 2012, at 9:51 PM, Boris Samorodov wrote: Can you send me the output of: tar -cvf /tmp/test.tar /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1 (A tar archive containing only that one source file.) This looks similar to a bug that we found in libarchive recently I didn't think that bug impacted FreeBSD, but I may have been wrong…. if it did, it will be obvious from the structure of the created archive. The following file is extracted after tarring: - % hd libnspr4.so.1 32 0a 30 0a 30 0a 32 34 31 39 37 31 0a 30 0a 00 |2.0.0.241971.0..| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0200 - The tar file itself attached (3KB in length). Ugh. I'll probably need your help to diagnose this more precisely. Here is the root problem: tar thinks this is a sparse file with nothing in it.On FreeBSD, bsdtar now uses lseek(SEEK_HOLE) to identify holes in the file. For some reason, bsdtar is storing this file as just one big hole. I experience a related issue. lseek(SEEK_HOLE) error checks are too strict. Files are not added to archive if lseek(SEEK_HOLE) fails. Ignoring lseek(SEEK_HOLE) at least in ENOTTY case would be preferable. This has already been fixed upstream. I'll get the fix merged soon… Boris: What filesystem are you using? zfs -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: /usr/bin/tar creates invalid lib file
on 26/03/2012 11:04 Boris Samorodov said the following: 26.03.2012 03:25, Tim Kientzle пишет: Boris: What filesystem are you using? zfs Could this particular instance of the problem be triggered by http://www.freebsd.org/cgi/query-pr.cgi?pr=164445 ? -- Andriy Gapon ___ 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 i386/i386
TB --- 2012-03-26 07:00:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-03-26 07:00:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-03-26 07:00:00 - cleaning the object tree TB --- 2012-03-26 07:00:04 - cvsupping the source tree TB --- 2012-03-26 07:00:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-03-26 07:06:33 - building world TB --- 2012-03-26 07:06:33 - CROSS_BUILD_TESTING=YES TB --- 2012-03-26 07:06:33 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-26 07:06:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-26 07:06:33 - SRCCONF=/dev/null TB --- 2012-03-26 07:06:33 - TARGET=i386 TB --- 2012-03-26 07:06:33 - TARGET_ARCH=i386 TB --- 2012-03-26 07:06:33 - TZ=UTC TB --- 2012-03-26 07:06:33 - __MAKE_CONF=/dev/null TB --- 2012-03-26 07:06:33 - cd /src TB --- 2012-03-26 07:06:33 - /usr/bin/make -B buildworld World build started on Mon Mar 26 07:06:34 UTC 2012 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 Mon Mar 26 09:14:26 UTC 2012 TB --- 2012-03-26 09:14:26 - generating LINT kernel config TB --- 2012-03-26 09:14:26 - cd /src/sys/i386/conf TB --- 2012-03-26 09:14:26 - /usr/bin/make -B LINT TB --- 2012-03-26 09:14:26 - cd /src/sys/i386/conf TB --- 2012-03-26 09:14:26 - /usr/sbin/config -m LINT TB --- 2012-03-26 09:14:27 - building LINT kernel TB --- 2012-03-26 09:14:27 - CROSS_BUILD_TESTING=YES TB --- 2012-03-26 09:14:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-26 09:14:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-26 09:14:27 - SRCCONF=/dev/null TB --- 2012-03-26 09:14:27 - TARGET=i386 TB --- 2012-03-26 09:14:27 - TARGET_ARCH=i386 TB --- 2012-03-26 09:14:27 - TZ=UTC TB --- 2012-03-26 09:14:27 - __MAKE_CONF=/dev/null TB --- 2012-03-26 09:14:27 - cd /src TB --- 2012-03-26 09:14:27 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Mon Mar 26 09:14:27 UTC 2012 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 [...] /src/sys/dev/arcmsr/arcmsr.h:42:8: error: macro names must be identifiers /src/sys/dev/arcmsr/arcmsr.h:43:2: error: invalid preprocessing directive #denine /src/sys/dev/arcmsr/arcmsr.h:52:2: error: invalid preprocessing directive #defino /src/sys/dev/arcmsr/arcmsr.h:93:2: error: invalid preprocessing directive #lefine /src/sys/dev/arcmsr/arcmsr.h:118:2: error: invalid preprocessing directive #tefine /src/sys/dev/arcmsr/arcmsr.h:138:2: error: invalid preprocessing directive #denine /src/sys/dev/arcmsr/arcmsr.h:148:2: error: invalid preprocessing directive #dofine mkdep: compile failed *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-03-26 09:16:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-03-26 09:16:28 - ERROR: failed to build LINT kernel TB --- 2012-03-26 09:16:28 - 6365.83 user 902.15 system 8187.55 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.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: LSI supported mps(4) driver available
On Mar 26, 2012 3:43 AM, Garrett Cooper yaneg...@gmail.com wrote: On Sun, Mar 25, 2012 at 5:16 AM, Matt Thyer matt.th...@gmail.com wrote: On 21 January 2012 09:58, Kenneth D. Merry k...@freebsd.org wrote: On Fri, Jan 20, 2012 at 23:14:20 -, Steven Hartland wrote: - Original Message - From: Kenneth D. Merry k...@freebsd.org To: freebsd-s...@freebsd.org; freebsd-current@freebsd.org Sent: Friday, January 20, 2012 8:44 PM Subject: LSI supported mps(4) driver available The LSI-supported version of the mps(4) driver that supports their 6Gb SAS HBAs as well as WarpDrive controllers, is available here: http://people.freebsd.org/~ken/lsi/mps_lsi.20120120.1.txt I plan to check it in to head next week, and then MFC it into stable/9 a week after that most likely. Great to see this being done, thanks to everyone! Be even better to see this MFC'ed to 8.x as well if all goes well. Do you think this will possible? Yes, that should be doable as well. It's unlikely that all of the CAM changes will get merged back, but the driver itself shouldn't be a problem. Ken Has this driver been MFC to 8-STABLE yet ? I'm asking because I updated my NAS on the 4th of March from 8-STABLE r225723 to r232477 and am now seeing 157,000 interrupts per second on irq 16 where my SuperMicro AOC-USAS2-L8i resides (this card uses the LSI SAS2008 chip). More details are in a thread on the freebsd-stable mailing list entitled 157k interrupts per second causing 60% CPU load on idle system. The first message is here: http://www.freebsd.org/cgi/getmsg.cgi?fetch=152290+156717+/usr/local/www/db/text/2012/freebsd-stable/20120325.freebsd-stable If this new driver isn't in 8-STABLE yet I think I'll try upgrading the whole system to 9-STABLE. Be sure to update your firmware beforehand. v11 firmware from LSI (or the OEM vendor) is required in order for all drives to be detected in FreeBSD in certain configs. Cheers, -Garrett After encountering this problem I updated my firmware from phase 7 to phase 11 but this did not fix things. My question is: Is the LSI driver even in 8-STABLE yet?. If not I'll upgrade to 9-STABLE to get the new driver. If it is, then I want to downgrade to just before it came in to see if this high interrupt rate problem is fixed. ___ 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 mips/mips
TB --- 2012-03-26 09:16:28 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-03-26 09:16:28 - starting HEAD tinderbox run for mips/mips TB --- 2012-03-26 09:16:28 - cleaning the object tree TB --- 2012-03-26 09:16:31 - cvsupping the source tree TB --- 2012-03-26 09:16:31 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-03-26 09:16:42 - building world TB --- 2012-03-26 09:16:42 - CROSS_BUILD_TESTING=YES TB --- 2012-03-26 09:16:42 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-26 09:16:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-26 09:16:42 - SRCCONF=/dev/null TB --- 2012-03-26 09:16:42 - TARGET=mips TB --- 2012-03-26 09:16:42 - TARGET_ARCH=mips TB --- 2012-03-26 09:16:42 - TZ=UTC TB --- 2012-03-26 09:16:42 - __MAKE_CONF=/dev/null TB --- 2012-03-26 09:16:42 - cd /src TB --- 2012-03-26 09:16:42 - /usr/bin/make -B buildworld World build started on Mon Mar 26 09:16:43 UTC 2012 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 [...] cc -O -pipe -G0 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/roken -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kfd/../../include -std=gnu99 -c /src/kerberos5/libexec/kfd/../../../crypto/heimdal/appl/kf/kfd.c cc -O -pipe -G0 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/roken -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kfd/../../include -std=gnu99 -o kfd kfd.o -lkrb5 -lroken -lasn1 -lcrypto -lcrypt /obj/mips.mipsel/src/kerberos5/libexec/kfd/../../lib/libvers/libvers.a gzip -cn /src/kerberos5/libexec/kfd/../../../crypto/heimdal/appl/kf/kfd.8 kfd.8.gz === kerberos5/libexec/kimpersonate (all) cc -O -pipe -G0 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/hx509 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kimpersonate/../../include -std=gnu99 -c /src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/kuser/kimpersonate.c cc -O -pipe -G0 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/hx509 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kimpersonate/../../include -std=gnu99 -o kimpersonate kimpersonate.o -lkafs5 -lkrb5 -lheimntlm -lroken -lasn1 -lcrypto -lcrypt /obj/mips.mipsel/src/kerberos5/libexec/kimpersonate/../../lib/libvers/libvers.a /obj/mips.mipsel/src/tmp/usr/bin/ld: /obj/mips.mipsel/src/tmp/usr/lib/libkafs5.so symbol number 13 references nonexistent SHT_SYMTAB_SHNDX section /obj/mips.mipsel/src/tmp/usr/lib/libkafs5.so: could not read symbols: File format not recognized *** Error code 1 Stop in /src/kerberos5/libexec/kimpersonate. *** Error code 1 Stop in /src/kerberos5/libexec. *** Error code 1 Stop in /src/kerberos5. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-03-26 10:05:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-03-26 10:05:57 - ERROR: failed to build world TB --- 2012-03-26 10:05:57 - 2060.11 user 447.48 system 2968.43 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.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: /usr/bin/tar creates invalid lib file
On 26.03.2012 12:42, Andriy Gapon wrote: on 26/03/2012 11:04 Boris Samorodov said the following: 26.03.2012 03:25, Tim Kientzle пишет: Boris: What filesystem are you using? zfs Could this particular instance of the problem be triggered by http://www.freebsd.org/cgi/query-pr.cgi?pr=164445 Hm, I use i386: - % uname -a FreeBSD bsam.wart.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r232957: Wed Mar 14 14:14:49 SAMT 2012 b...@bsam.wart.ru:/usr/obj/usr/src/sys/BBX i386 - -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: /usr/bin/tar creates invalid lib file
on 26/03/2012 13:30 Boris Samorodov said the following: On 26.03.2012 12:42, Andriy Gapon wrote: on 26/03/2012 11:04 Boris Samorodov said the following: 26.03.2012 03:25, Tim Kientzle пишет: Boris: What filesystem are you using? zfs Could this particular instance of the problem be triggered by http://www.freebsd.org/cgi/query-pr.cgi?pr=164445 Hm, I use i386: - % uname -a FreeBSD bsam.wart.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r232957: Wed Mar 14 14:14:49 SAMT 2012 b...@bsam.wart.ru:/usr/obj/usr/src/sys/BBX i386 - Hm, does that make any difference? :-) -- Andriy Gapon ___ 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: /usr/bin/tar creates invalid lib file
On 26.03.2012 15:36, Andriy Gapon wrote: on 26/03/2012 13:30 Boris Samorodov said the following: On 26.03.2012 12:42, Andriy Gapon wrote: on 26/03/2012 11:04 Boris Samorodov said the following: 26.03.2012 03:25, Tim Kientzle пишет: Boris: What filesystem are you using? zfs Could this particular instance of the problem be triggered by http://www.freebsd.org/cgi/query-pr.cgi?pr=164445 Hm, I use i386: - % uname -a FreeBSD bsam.wart.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r232957: Wed Mar 14 14:14:49 SAMT 2012 b...@bsam.wart.ru:/usr/obj/usr/src/sys/BBX i386 - Hm, does that make any difference? :-) I may misunderstand the PR but it seems to me that the discussion was about amd64. Other than that looks familiar. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: Virtual Manager Vacancy
On 3/25/2012 9:35 PM, Super Bisquit wrote: I'm a retired 69 year old pregnant male looking for part-time work during my career break. I'm not a pregnant male, I just look like it ouch. :( Chuck ___ 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: /usr/bin/tar creates invalid lib file
on 26/03/2012 15:01 Boris Samorodov said the following: On 26.03.2012 15:36, Andriy Gapon wrote: on 26/03/2012 13:30 Boris Samorodov said the following: On 26.03.2012 12:42, Andriy Gapon wrote: on 26/03/2012 11:04 Boris Samorodov said the following: 26.03.2012 03:25, Tim Kientzle пишет: Boris: What filesystem are you using? zfs Could this particular instance of the problem be triggered by http://www.freebsd.org/cgi/query-pr.cgi?pr=164445 Hm, I use i386: - % uname -a FreeBSD bsam.wart.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r232957: Wed Mar 14 14:14:49 SAMT 2012 b...@bsam.wart.ru:/usr/obj/usr/src/sys/BBX i386 - Hm, does that make any difference? :-) I may misunderstand the PR but it seems to me that the discussion was about amd64. Other than that looks familiar. My impression is that the PR compared FreeBSD pre-ZFSv28 and ZFSv28 behavior, i386 vs amd64 seems to be a bit of noise in the signal. -- Andriy Gapon ___ 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 amd64/amd64
TB --- 2012-03-26 07:00:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-03-26 07:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-03-26 07:00:00 - cleaning the object tree TB --- 2012-03-26 07:00:00 - cvsupping the source tree TB --- 2012-03-26 07:00:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2012-03-26 07:00:14 - building world TB --- 2012-03-26 07:00:14 - CROSS_BUILD_TESTING=YES TB --- 2012-03-26 07:00:14 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-26 07:00:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-26 07:00:14 - SRCCONF=/dev/null TB --- 2012-03-26 07:00:14 - TARGET=amd64 TB --- 2012-03-26 07:00:14 - TARGET_ARCH=amd64 TB --- 2012-03-26 07:00:14 - TZ=UTC TB --- 2012-03-26 07:00:14 - __MAKE_CONF=/dev/null TB --- 2012-03-26 07:00:14 - cd /src TB --- 2012-03-26 07:00:14 - /usr/bin/make -B buildworld World build started on Mon Mar 26 07:00:14 UTC 2012 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 stage 5.1: building 32 bit shim libraries World build completed on Mon Mar 26 09:38:44 UTC 2012 TB --- 2012-03-26 09:38:44 - generating LINT kernel config TB --- 2012-03-26 09:38:44 - cd /src/sys/amd64/conf TB --- 2012-03-26 09:38:44 - /usr/bin/make -B LINT TB --- 2012-03-26 09:38:44 - cd /src/sys/amd64/conf TB --- 2012-03-26 09:38:44 - /usr/sbin/config -m LINT TB --- 2012-03-26 09:38:44 - building LINT kernel TB --- 2012-03-26 09:38:44 - CROSS_BUILD_TESTING=YES TB --- 2012-03-26 09:38:44 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-26 09:38:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-26 09:38:44 - SRCCONF=/dev/null TB --- 2012-03-26 09:38:44 - TARGET=amd64 TB --- 2012-03-26 09:38:44 - TARGET_ARCH=amd64 TB --- 2012-03-26 09:38:44 - TZ=UTC TB --- 2012-03-26 09:38:44 - __MAKE_CONF=/dev/null TB --- 2012-03-26 09:38:44 - cd /src TB --- 2012-03-26 09:38:44 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Mon Mar 26 09:38:44 UTC 2012 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 Kernel build for LINT completed on Mon Mar 26 10:09:50 UTC 2012 TB --- 2012-03-26 10:09:50 - cd /src/sys/amd64/conf TB --- 2012-03-26 10:09:50 - /usr/sbin/config -m LINT-NOINET TB --- 2012-03-26 10:09:50 - building LINT-NOINET kernel TB --- 2012-03-26 10:09:50 - CROSS_BUILD_TESTING=YES TB --- 2012-03-26 10:09:50 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-26 10:09:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-26 10:09:50 - SRCCONF=/dev/null TB --- 2012-03-26 10:09:50 - TARGET=amd64 TB --- 2012-03-26 10:09:50 - TARGET_ARCH=amd64 TB --- 2012-03-26 10:09:50 - TZ=UTC TB --- 2012-03-26 10:09:50 - __MAKE_CONF=/dev/null TB --- 2012-03-26 10:09:50 - cd /src TB --- 2012-03-26 10:09:50 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Mon Mar 26 10:09:50 UTC 2012 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 Kernel build for LINT-NOINET completed on Mon Mar 26 10:37:41 UTC 2012 TB --- 2012-03-26 10:37:41 - cd /src/sys/amd64/conf TB --- 2012-03-26 10:37:41 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-03-26 10:37:41 - building LINT-NOINET6 kernel TB --- 2012-03-26 10:37:41 - CROSS_BUILD_TESTING=YES TB --- 2012-03-26 10:37:41 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-26 10:37:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-26 10:37:41 - SRCCONF=/dev/null TB --- 2012-03-26 10:37:41 - TARGET=amd64 TB --- 2012-03-26 10:37:41 - TARGET_ARCH=amd64 TB --- 2012-03-26 10:37:41 - TZ=UTC TB --- 2012-03-26 10:37:41 - __MAKE_CONF=/dev/null TB --- 2012-03-26 10:37:41 - cd /src TB --- 2012-03-26 10:37:41 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 Kernel build for LINT-NOINET6 started on Mon Mar 26 10:37:41 UTC 2012 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 Kernel build for LINT-NOINET6 completed on Mon Mar 26 11:06:25 UTC 2012 TB --- 2012-03-26 11:06:25 - cd /src/sys/amd64/conf TB --- 2012-03-26 11:06:25 - /usr/sbin/config -m LINT-NOIP TB --- 2012-03-26 11:06:25 - building LINT-NOIP kernel TB --- 2012-03-26 11:06:25 - CROSS_BUILD_TESTING=YES TB --- 2012-03-26 11:06:25 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-26 11:06:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-26 11:06:25 - SRCCONF=/dev/null TB ---
Re: Virtual Manager Vacancy
El día Monday, March 26, 2012 a las 07:12:20AM -0500, Chuck Burns escribió: On 3/25/2012 9:35 PM, Super Bisquit wrote: I'm a retired 69 year old pregnant male looking for part-time work during my career break. I'm not a pregnant male, I just look like it ouch. :( Despite of joking, could someone block those SPAMMERS in the FreeBSD mailing lists; looking into the header it seems that we do not run SpamAssassin :-( This shit SPAMMER targeted all FreeBSD lists this morning. Thanks matthias -- Matthias Apitz e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ 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: LSI supported mps(4) driver available
On Mon, Mar 26, 2012 at 08:05:59PM +1030, Matt Thyer wrote: On Mar 26, 2012 3:43 AM, Garrett Cooper yaneg...@gmail.com wrote: On Sun, Mar 25, 2012 at 5:16 AM, Matt Thyer matt.th...@gmail.com wrote: On 21 January 2012 09:58, Kenneth D. Merry k...@freebsd.org wrote: On Fri, Jan 20, 2012 at 23:14:20 -, Steven Hartland wrote: - Original Message - From: Kenneth D. Merry k...@freebsd.org To: freebsd-s...@freebsd.org; freebsd-current@freebsd.org Sent: Friday, January 20, 2012 8:44 PM Subject: LSI supported mps(4) driver available The LSI-supported version of the mps(4) driver that supports their 6Gb SAS HBAs as well as WarpDrive controllers, is available here: http://people.freebsd.org/~ken/lsi/mps_lsi.20120120.1.txt I plan to check it in to head next week, and then MFC it into stable/9 a week after that most likely. Great to see this being done, thanks to everyone! Be even better to see this MFC'ed to 8.x as well if all goes well. Do you think this will possible? Yes, that should be doable as well. It's unlikely that all of the CAM changes will get merged back, but the driver itself shouldn't be a problem. Ken Has this driver been MFC to 8-STABLE yet ? I'm asking because I updated my NAS on the 4th of March from 8-STABLE r225723 to r232477 and am now seeing 157,000 interrupts per second on irq 16 where my SuperMicro AOC-USAS2-L8i resides (this card uses the LSI SAS2008 chip). More details are in a thread on the freebsd-stable mailing list entitled 157k interrupts per second causing 60% CPU load on idle system. The first message is here: http://www.freebsd.org/cgi/getmsg.cgi?fetch=152290+156717+/usr/local/www/db/text/2012/freebsd-stable/20120325.freebsd-stable If this new driver isn't in 8-STABLE yet I think I'll try upgrading the whole system to 9-STABLE. Be sure to update your firmware beforehand. v11 firmware from LSI (or the OEM vendor) is required in order for all drives to be detected in FreeBSD in certain configs. Cheers, -Garrett After encountering this problem I updated my firmware from phase 7 to phase 11 but this did not fix things. My question is: Is the LSI driver even in 8-STABLE yet?. If not I'll upgrade to 9-STABLE to get the new driver. If it is, then I want to downgrade to just before it came in to see if this high interrupt rate problem is fixed. I'm no export in svn, however: http://svnweb.freebsd.org/base?view=revisionamp;revision=230922 would appear to suggest that the new driver is in 8-Stable Gary ___ 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: general protection fault panic
On Friday, March 23, 2012 6:23:13 pm Steve Kargl wrote: Haven't seen one of these in a long time. %uname -a FreeBSD troutmask.apl.washington.edu 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r233282: Wed Mar 21 12:39:16 PDT 2012 ka...@troutmask.apl.washington.edu:/usr/obj/usr/src/sys/SPEW amd64 Hand transcribed Fatal trap 9: general protection fault while in kernel mode cpuid = 1; apic id = 01 instruction pointer = 0x20:0x80570b89 Can you run gdb on your kernel.debug and 'l *' this address? stack pointer = 0x28:0xff82327b4860 frame pointer = 0x28:0xff82327b4870 code segment= base 0x0, limit 0xf, type 0x1b = DPL0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1456 (ps) trap number = 9 panic: general protection fault cpuid = 1 The system then tries to reboot without dropping into the debugger. -- 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
[head tinderbox] failure on i386/pc98
TB --- 2012-03-26 13:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-03-26 13:20:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-03-26 13:20:00 - cleaning the object tree TB --- 2012-03-26 13:20:00 - cvsupping the source tree TB --- 2012-03-26 13:20:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-03-26 13:20:19 - building world TB --- 2012-03-26 13:20:19 - CROSS_BUILD_TESTING=YES TB --- 2012-03-26 13:20:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-26 13:20:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-26 13:20:19 - SRCCONF=/dev/null TB --- 2012-03-26 13:20:19 - TARGET=pc98 TB --- 2012-03-26 13:20:19 - TARGET_ARCH=i386 TB --- 2012-03-26 13:20:19 - TZ=UTC TB --- 2012-03-26 13:20:19 - __MAKE_CONF=/dev/null TB --- 2012-03-26 13:20:19 - cd /src TB --- 2012-03-26 13:20:19 - /usr/bin/make -B buildworld World build started on Mon Mar 26 13:20:20 UTC 2012 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 Mon Mar 26 15:23:20 UTC 2012 TB --- 2012-03-26 15:23:20 - generating LINT kernel config TB --- 2012-03-26 15:23:20 - cd /src/sys/pc98/conf TB --- 2012-03-26 15:23:20 - /usr/bin/make -B LINT TB --- 2012-03-26 15:23:20 - cd /src/sys/pc98/conf TB --- 2012-03-26 15:23:20 - /usr/sbin/config -m LINT TB --- 2012-03-26 15:23:20 - building LINT kernel TB --- 2012-03-26 15:23:20 - CROSS_BUILD_TESTING=YES TB --- 2012-03-26 15:23:20 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-26 15:23:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-26 15:23:20 - SRCCONF=/dev/null TB --- 2012-03-26 15:23:20 - TARGET=pc98 TB --- 2012-03-26 15:23:20 - TARGET_ARCH=i386 TB --- 2012-03-26 15:23:20 - TZ=UTC TB --- 2012-03-26 15:23:20 - __MAKE_CONF=/dev/null TB --- 2012-03-26 15:23:20 - cd /src TB --- 2012-03-26 15:23:20 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Mon Mar 26 15:23:20 UTC 2012 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 [...] ./i386/cpufunc.h:42:2: error: #error this file needs sys/cdefs.h as a prerequisite /src/sys/fs/ext2fs/ext2_bmap.c:39:2: error: invalid preprocessing directive #includ /src/sys/fs/ext2fs/ext2_bmap.c:40:21: error: sys/buf.l: No such file or directory /src/sys/fs/ext2fs/ext2_bmap.c:42:2: error: invalid preprocessing directive #includ /src/sys/fs/ext2fs/ext2_bmap.c:44:29: error: sys/resourcevar~h: No such file or directory /src/sys/fs/ext2fs/ext2_bmap.c:49:34: error: þs/ext2fs/ext2_mount.h: No such file or directory /src/sys/fs/ext2fs/ext2_bmap.c:50:2: error: invalid preprocessing directive #includex mkdep: compile failed *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-03-26 15:24:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-03-26 15:24:53 - ERROR: failed to build LINT kernel TB --- 2012-03-26 15:24:53 - 6122.20 user 884.39 system 7493.06 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.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
[head tinderbox] failure on i386/i386
TB --- 2012-03-26 13:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-03-26 13:20:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-03-26 13:20:00 - cleaning the object tree TB --- 2012-03-26 13:20:05 - cvsupping the source tree TB --- 2012-03-26 13:20:05 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-03-26 13:20:46 - building world TB --- 2012-03-26 13:20:46 - CROSS_BUILD_TESTING=YES TB --- 2012-03-26 13:20:46 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-26 13:20:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-26 13:20:46 - SRCCONF=/dev/null TB --- 2012-03-26 13:20:46 - TARGET=i386 TB --- 2012-03-26 13:20:46 - TARGET_ARCH=i386 TB --- 2012-03-26 13:20:46 - TZ=UTC TB --- 2012-03-26 13:20:46 - __MAKE_CONF=/dev/null TB --- 2012-03-26 13:20:46 - cd /src TB --- 2012-03-26 13:20:46 - /usr/bin/make -B buildworld World build started on Mon Mar 26 13:20:47 UTC 2012 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 Mon Mar 26 15:24:16 UTC 2012 TB --- 2012-03-26 15:24:16 - generating LINT kernel config TB --- 2012-03-26 15:24:16 - cd /src/sys/i386/conf TB --- 2012-03-26 15:24:16 - /usr/bin/make -B LINT TB --- 2012-03-26 15:24:16 - cd /src/sys/i386/conf TB --- 2012-03-26 15:24:16 - /usr/sbin/config -m LINT TB --- 2012-03-26 15:24:16 - building LINT kernel TB --- 2012-03-26 15:24:16 - CROSS_BUILD_TESTING=YES TB --- 2012-03-26 15:24:16 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-26 15:24:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-26 15:24:16 - SRCCONF=/dev/null TB --- 2012-03-26 15:24:16 - TARGET=i386 TB --- 2012-03-26 15:24:16 - TARGET_ARCH=i386 TB --- 2012-03-26 15:24:16 - TZ=UTC TB --- 2012-03-26 15:24:16 - __MAKE_CONF=/dev/null TB --- 2012-03-26 15:24:16 - cd /src TB --- 2012-03-26 15:24:16 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Mon Mar 26 15:24:16 UTC 2012 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 [...] /src/sys/dev/arcmsr/arcmsr.h:42:8: error: macro names must be identifiers /src/sys/dev/arcmsr/arcmsr.h:43:2: error: invalid preprocessing directive #denine /src/sys/dev/arcmsr/arcmsr.h:52:2: error: invalid preprocessing directive #defino /src/sys/dev/arcmsr/arcmsr.h:93:2: error: invalid preprocessing directive #lefine /src/sys/dev/arcmsr/arcmsr.h:118:2: error: invalid preprocessing directive #tefine /src/sys/dev/arcmsr/arcmsr.h:138:2: error: invalid preprocessing directive #denine /src/sys/dev/arcmsr/arcmsr.h:148:2: error: invalid preprocessing directive #dofine mkdep: compile failed *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-03-26 15:26:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-03-26 15:26:16 - ERROR: failed to build LINT kernel TB --- 2012-03-26 15:26:16 - 6174.59 user 895.30 system 7575.91 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.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
[head tinderbox] failure on ia64/ia64
TB --- 2012-03-26 15:19:45 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-03-26 15:19:45 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-03-26 15:19:45 - cleaning the object tree TB --- 2012-03-26 15:19:45 - cvsupping the source tree TB --- 2012-03-26 15:19:45 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2012-03-26 15:20:03 - building world TB --- 2012-03-26 15:20:03 - CROSS_BUILD_TESTING=YES TB --- 2012-03-26 15:20:03 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-26 15:20:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-26 15:20:03 - SRCCONF=/dev/null TB --- 2012-03-26 15:20:03 - TARGET=ia64 TB --- 2012-03-26 15:20:03 - TARGET_ARCH=ia64 TB --- 2012-03-26 15:20:03 - TZ=UTC TB --- 2012-03-26 15:20:03 - __MAKE_CONF=/dev/null TB --- 2012-03-26 15:20:03 - cd /src TB --- 2012-03-26 15:20:03 - /usr/bin/make -B buildworld World build started on Mon Mar 26 15:20:04 UTC 2012 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 [...] /obj/ia64.ia64/src/tmp/usr/include/sys/ipc.h:103:2: error: invalid preprocessing directive #defino /obj/ia64.ia64/src/tmp/usr/include/sys/ipc.h:142:2: error: #endif without #if In file included from /obj/ia64.ia64/src/tmp/usr/include/sys/sem.h:13, from /src/lib/libc/gen/semctl.c:36: /obj/ia64.ia64/src/tmp/usr/include/sys/ipc.h:82:2: error: #endif without #if /obj/ia64.ia64/src/tmp/usr/include/sys/ipc.h:103:2: error: invalid preprocessing directive #defino /obj/ia64.ia64/src/tmp/usr/include/sys/ipc.h:142:2: error: #endif without #if mkdep: compile failed *** Error code 1 Stop in /src/lib/libc. *** 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 --- 2012-03-26 15:30:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-03-26 15:30:31 - ERROR: failed to build world TB --- 2012-03-26 15:30:31 - 486.22 user 75.25 system 646.59 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.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: general protection fault panic
On Mon, Mar 26, 2012 at 10:59:35AM -0400, John Baldwin wrote:
On Friday, March 23, 2012 6:23:13 pm Steve Kargl wrote:
Haven't seen one of these in a long time.
%uname -a
FreeBSD troutmask.apl.washington.edu 10.0-CURRENT FreeBSD
10.0-CURRENT #0 r233282: Wed Mar 21 12:39:16 PDT 2012
ka...@troutmask.apl.washington.edu:/usr/obj/usr/src/sys/SPEW amd64
Hand transcribed
Fatal trap 9: general protection fault while in kernel mode
cpuid = 1; apic id = 01
instruction pointer = 0x20:0x80570b89
Can you run gdb on your kernel.debug and 'l *' this address?
Unfortunately, I don't have that kernel.debug anymore. I saw
that alc had committed a few changes, so updated the kernel.
I do have the kernel and kernel.symbol files. Loading
kernel.symbol into gdb shows
(gdb) l *0x80570b89
0x80570b89 is in strcmp (/usr/src/sys/libkern/strcmp.c:45).
40 */
41 int
42 strcmp(s1, s2)
43 register const char *s1, *s2;
44 {
45 while (*s1 == *s2++)
46 if (*s1++ == 0)
47 return (0);
48 return (*(const unsigned char *)s1 - *(const unsigned char
*)(s2 - 1));
49 }
Don't know if the above helps or is a red-herring.
I may be able to reproduce the crash. I give it a try in a
few moments.
--
Steve
___
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: /usr/bin/tar creates invalid lib file
On Mar 26, 2012, at 1:42 AM, Andriy Gapon wrote: on 26/03/2012 11:04 Boris Samorodov said the following: 26.03.2012 03:25, Tim Kientzle пишет: Boris: What filesystem are you using? zfs Could this particular instance of the problem be triggered by http://www.freebsd.org/cgi/query-pr.cgi?pr=164445 ? Yes, that could definitely be related. It will take me a day or two to get a fix into libarchive. Tim ___ 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: general protection fault panic
On Mon, Mar 26, 2012 at 08:43:59AM -0700, Steve Kargl wrote:
On Mon, Mar 26, 2012 at 10:59:35AM -0400, John Baldwin wrote:
On Friday, March 23, 2012 6:23:13 pm Steve Kargl wrote:
Haven't seen one of these in a long time.
%uname -a
FreeBSD troutmask.apl.washington.edu 10.0-CURRENT FreeBSD
10.0-CURRENT #0 r233282: Wed Mar 21 12:39:16 PDT 2012
ka...@troutmask.apl.washington.edu:/usr/obj/usr/src/sys/SPEW amd64
Hand transcribed
Fatal trap 9: general protection fault while in kernel mode
cpuid = 1; apic id = 01
instruction pointer = 0x20:0x80570b89
Can you run gdb on your kernel.debug and 'l *' this address?
Unfortunately, I don't have that kernel.debug anymore. I saw
that alc had committed a few changes, so updated the kernel.
I do have the kernel and kernel.symbol files. Loading
kernel.symbol into gdb shows
(gdb) l *0x80570b89
0x80570b89 is in strcmp (/usr/src/sys/libkern/strcmp.c:45).
40 */
41 int
42 strcmp(s1, s2)
43 register const char *s1, *s2;
44 {
45 while (*s1 == *s2++)
46 if (*s1++ == 0)
47 return (0);
48 return (*(const unsigned char *)s1 - *(const unsigned char
*)(s2 - 1));
49 }
Don't know if the above helps or is a red-herring.
I may be able to reproduce the crash. I give it a try in a
few moments.
The above gdb is probably a red-herring. I can 100%
reproduce the panic with
1) Insert old MS-formatted floppy into drive.
2) mount_msdosfs /dev/fd0 /mnt
%kgdb /usr/obj/usr/src/sys/SPEW/kernel.debug vmcore.0
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 = 0x33
fault code = supervisor write data, page not present
instruction pointer = 0x20:0x80751232
stack pointer = 0x28:0xff8000229a50
frame pointer = 0x28:0xff8000229b30
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= resume, IOPL = 0
current process = 10 (idle: cpu0)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 2d16h49m51s
Dumping 1209 out of 8116 MB:..2%..11%..22%..31%..42%..51%..61%..71%..81%..92%
Reading symbols from /usr/local/libexec/linux_adobe/linux_adobe.ko...done.
Loaded symbols for /usr/local/libexec/linux_adobe/linux_adobe.ko
#0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:268
268 if (textdump textdump_pending) {
(kgdb) bt
#0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:268
#1 0x804c8140 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:454
#2 0x804c8617 in panic (fmt=0x0)
at /usr/src/sys/kern/kern_shutdown.c:642
#3 0x806f6180 in trap_fatal (frame=0xc, eva=Variable eva is not
available.
)
at /usr/src/sys/amd64/amd64/trap.c:838
#4 0x806f64ff in trap_pfault (frame=0xff80002299a0, usermode=0)
at /usr/src/sys/amd64/amd64/trap.c:755
#5 0x806f69ee in trap (frame=0xff80002299a0)
at /usr/src/sys/amd64/amd64/trap.c:454
#6 0x806e12bf in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:228
#7 0x80751232 in lapic_handle_intr (vector=51,
frame=0xff8000229a70)
at /usr/src/sys/x86/x86/local_apic.c:777
#8 0x1008 in ?? ()
#9 0xff8000229b54 in ?? ()
#9 0xff8000229b54 in ?? ()
#10 0x in ?? ()
#11 0x100b in ?? ()
#12 0x in ?? ()
#13 0x in ?? ()
#14 0x in ?? ()
#15 0x in ?? ()
#16 0xff8000229b30 in ?? ()
#17 0x in ?? ()
#18 0x in ?? ()
#19 0xfe00032e3600 in ?? ()
#20 0xfe00032e3628 in ?? ()
#21 0xff8000229c40 in ?? ()
#22 0x in ?? ()
#23 0x001b0013032e3628 in ?? ()
#24 0xff8000229c40 in ?? ()
#25 0x003b003b0001 in ?? ()
#26 0xff8000229b30 in ?? ()
#27 0x806dc186 in acpi_cpu_c1 ()
at /usr/src/sys/amd64/acpica/acpi_machdep.c:97
(kgdb) l *0x80751232
0x80751232 is in lapic_handle_intr
(/usr/src/sys/x86/x86/local_apic.c:777).
772 lapic-eoi = 0;
773 }
774
775 void
776 lapic_handle_intr(int vector, struct trapframe *frame)
777 {
778 struct intsrc *isrc;
779
780 isrc = intr_lookup_source(apic_idt_to_irq(PCPU_GET(apic_id),
781 vector));
--
Steve
___
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: ACPI refcount increasing
On Monday 26 March 2012 01:42 am, Poul-Henning Kamp wrote: I tried -current as of approx one day ago and was greeted with a kernel printf flooding the screen with something about a ACPI(?) mutex(?) refcount increasing. I were unable to divine any identifying info from the messages because the screen scrolled too fast and the message was longer than the width of the screen. I were unable to get a core-dump and had to reset the laptop (Lenovo T400s) I am well aware of the issue and identified the regression was introduced in these changes: http://svnweb.freebsd.org/base/head/sys/contrib/dev/acpica/components/namespace/nspredef.c?r1=231844r2=233250view=patch http://svnweb.freebsd.org/base/head/sys/contrib/dev/acpica/components/namespace/nsrepair.c?r1=231844r2=233250view=patch http://svnweb.freebsd.org/base/head/sys/contrib/dev/acpica/include/aclocal.h?r1=229989r2=233250view=patch http://svnweb.freebsd.org/base/head/sys/contrib/dev/acpica/include/acnamesp.h?r1=229989r2=233250view=patch I notified the upstream maintainers and they are working very hard to correct the issue ATM. I'll update ACPICA as soon as they find a fix but please revert the changes for now if you are in hurry. Sorry for the breakage, Jung-uk Kim ___ 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: ACPI refcount increasing
On 26/03/2012 06:42, Poul-Henning Kamp wrote:
I tried -current as of approx one day ago and was greeted with a
kernel printf flooding the screen with something about a ACPI(?)
mutex(?) refcount increasing.
I got the same when I built a new kernel last Thursday.
Sevan
panic: from debugger
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 amd64-marcel-freebsd...
Unread portion of the kernel message buffer:
ACPI Warning: Large Reference Count (0xAA1) in object 0xfe000aa1e080
(20120320/utdelete-491)
ACPI Warning: Large Reference Count (0xAA1) in object 0xfe00055c2700
(20120320/utdelete-491)
ACPI Warning: Large Reference Count (0xAA1) in object 0xfe000aa1e180
(20120320/utdelete-491)
ACPI Warning: Large Reference Count (0xAA2) in object 0xfe000aa1e080
(20120320/utdelete-491)
ACPI Warning: Large Reference Count (0xAA2) in object 0xfe00055c2700
(20120320/utdelete-491)
ACPI Warning: Large Reference Count (0xAA2) in object 0xfe000aa1e180
(20120320/utdelete-491)
ACPI Warning: Large Reference Count (0xAA3) in object 0xfe000aa1e080
(20120320/utdelete-491)
ACPI Warning: Large Reference Count (0xAA3) in object 0xfe00055c2700
(20120320/utdelete-491)
ACPI Warning: Large Reference Count (0xAA3) in object 0xfe000aa1e180
(20120320/utdelete-491)
ACPI Warning: Large Reference Count (0xAA4) in object 0xfe000aa1e080
(20120320/utdelete-491)
ACPI Warning: Large Reference Count (0xAA4) in object 0xfe00055c2700
(20120320/utdelete-491)
ACPI Warning: Large Reference Count (0xAA4) in object 0xfe000aa1e180
(20120320/utdelete-491)
ACPI Warning: Large Reference Count (0xAA3) in object 0xfe000aa1e080
(20120320/utdelete-491)
ACPI Warning: Large Reference Count (0xAA3) in object 0xfe00055c2700
(20120320/utdelete-491)
ACPI Warning: Large Reference Count (0xAA3) in object 0xfe000aa1e180
(20120320/utdelete-491)
ACPI Warning: Large Reference Count (0xAA1) in object 0xfe00055c2a00
(20120320/utdelete-491)
ACPI Warning: Large Reference Count (0xAA2) in object 0xfe000aa1e080
(20120320/utdelete-491)
ACPI Warning: Large Reference Count (0xAA2) in object 0xfe00055c2700
(20120320/utdelete-491)
ACPI Warning: Large Reference Count (0xAA2) in object 0xfe000aa1e180
(20120320/utdelete-491)
ACPI Warning: Large Reference Count (0xAA2) in object 0xfe00055c2a00
(20120320/utdelete-491)
ACPI Warning: Large Reference Count (0xAA3) in object 0xfe000aa1e080
(20120320/utdelete-491)
ACPI Warning: Large Reference Count (0xAA3) in object 0xfe00055c2700
(20120320/utdelete-491)
ACPI Warning: Large Reference Count (0xAA3) in object 0xfe000aa1e180
(20120320/utdelete-491)
ACPI Warning: Large Reference Count (0xAA1) in object 0xfe00055c2a00
(20120320/utdelete-491)
ACPI Warning: Large Reference Count (0xAA2) in object 0xfe000aa1e080
(20120320/utdelete-491)
ACPI Warning: Large Reference Count (0xAA2) in object 0xfe00055c2700
(20120320/utdelete-491)
ACPI Warning: Large Reference Count (0xAA2) in object 0xfe000aa1e180
(20120320/utdelete-491)
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x11
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x80329680
stack pointer = 0x28:0xff8230107620
frame pointer = 0x28:0xff8230107640
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1583 (hald)
Uptime: 5m12s
Dumping 482 out of 8095 MB:..4%..14%..24%..34%..44%..54%..63%..73%..83%..93%
Reading symbols from /boot/kernel/zfs.ko...Reading symbols from
/bootdir/boot/kernel/zfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/zfs.ko
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from
/bootdir/boot/kernel/opensolaris.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/opensolaris.ko
Reading symbols from /boot/kernel/acpi_ibm.ko...Reading symbols from
/bootdir/boot/kernel/acpi_ibm.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/acpi_ibm.ko
Reading symbols from /boot/kernel/sem.ko...Reading symbols from
/bootdir/boot/kernel/sem.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/sem.ko
#0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:268
268 if (textdump textdump_pending) {
(kgdb) #0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:268
#1 0x808ae1c1 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:454
#2 0x808ae692 in panic
Re: general protection fault panic
On Monday, March 26, 2012 12:21:29 pm Steve Kargl wrote:
On Mon, Mar 26, 2012 at 08:43:59AM -0700, Steve Kargl wrote:
On Mon, Mar 26, 2012 at 10:59:35AM -0400, John Baldwin wrote:
On Friday, March 23, 2012 6:23:13 pm Steve Kargl wrote:
Haven't seen one of these in a long time.
%uname -a
FreeBSD troutmask.apl.washington.edu 10.0-CURRENT FreeBSD
10.0-CURRENT #0 r233282: Wed Mar 21 12:39:16 PDT 2012
ka...@troutmask.apl.washington.edu:/usr/obj/usr/src/sys/SPEW amd64
Hand transcribed
Fatal trap 9: general protection fault while in kernel mode
cpuid = 1; apic id = 01
instruction pointer = 0x20:0x80570b89
Can you run gdb on your kernel.debug and 'l *' this address?
Unfortunately, I don't have that kernel.debug anymore. I saw
that alc had committed a few changes, so updated the kernel.
I do have the kernel and kernel.symbol files. Loading
kernel.symbol into gdb shows
(gdb) l *0x80570b89
0x80570b89 is in strcmp (/usr/src/sys/libkern/strcmp.c:45).
40 */
41 int
42 strcmp(s1, s2)
43 register const char *s1, *s2;
44 {
45 while (*s1 == *s2++)
46 if (*s1++ == 0)
47 return (0);
48 return (*(const unsigned char *)s1 - *(const unsigned char
*)(s2 - 1));
49 }
Don't know if the above helps or is a red-herring.
I may be able to reproduce the crash. I give it a try in a
few moments.
The above gdb is probably a red-herring. I can 100%
reproduce the panic with
1) Insert old MS-formatted floppy into drive.
2) mount_msdosfs /dev/fd0 /mnt
%kgdb /usr/obj/usr/src/sys/SPEW/kernel.debug vmcore.0
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 = 0x33
fault code = supervisor write data, page not present
instruction pointer = 0x20:0x80751232
stack pointer = 0x28:0xff8000229a50
frame pointer = 0x28:0xff8000229b30
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= resume, IOPL = 0
current process = 10 (idle: cpu0)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 2d16h49m51s
Dumping 1209 out of 8116
MB:..2%..11%..22%..31%..42%..51%..61%..71%..81%..92%
Reading symbols from /usr/local/libexec/linux_adobe/linux_adobe.ko...done.
Loaded symbols for /usr/local/libexec/linux_adobe/linux_adobe.ko
#0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:268
268 if (textdump textdump_pending) {
(kgdb) bt
#0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:268
#1 0x804c8140 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:454
#2 0x804c8617 in panic (fmt=0x0)
at /usr/src/sys/kern/kern_shutdown.c:642
#3 0x806f6180 in trap_fatal (frame=0xc, eva=Variable eva is not
available.
)
at /usr/src/sys/amd64/amd64/trap.c:838
#4 0x806f64ff in trap_pfault (frame=0xff80002299a0, usermode=0)
at /usr/src/sys/amd64/amd64/trap.c:755
#5 0x806f69ee in trap (frame=0xff80002299a0)
at /usr/src/sys/amd64/amd64/trap.c:454
#6 0x806e12bf in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:228
#7 0x80751232 in lapic_handle_intr (vector=51,
frame=0xff8000229a70)
at /usr/src/sys/x86/x86/local_apic.c:777
#8 0x1008 in ?? ()
#9 0xff8000229b54 in ?? ()
#9 0xff8000229b54 in ?? ()
#10 0x in ?? ()
#11 0x100b in ?? ()
#12 0x in ?? ()
#13 0x in ?? ()
#14 0x in ?? ()
#15 0x in ?? ()
#16 0xff8000229b30 in ?? ()
#17 0x in ?? ()
#18 0x in ?? ()
#19 0xfe00032e3600 in ?? ()
#20 0xfe00032e3628 in ?? ()
#21 0xff8000229c40 in ?? ()
#22 0x in ?? ()
#23 0x001b0013032e3628 in ?? ()
#24 0xff8000229c40 in ?? ()
#25 0x003b003b0001 in ?? ()
#26 0xff8000229b30 in ?? ()
#27 0x806dc186 in acpi_cpu_c1 ()
at /usr/src/sys/amd64/acpica/acpi_machdep.c:97
(kgdb) l *0x80751232
0x80751232 is in lapic_handle_intr
(/usr/src/sys/x86/x86/local_apic.c:777).
772 lapic-eoi = 0;
773 }
774
775 void
776 lapic_handle_intr(int vector, struct trapframe *frame)
777 {
778 struct intsrc *isrc;
779
780 isrc = intr_lookup_source(apic_idt_to_irq(PCPU_GET(apic_id),
781 vector));
H. Odd. I don't think that should generate a fault. (But now I wonder
about stray IRQ 0 messages I now see on boot.)
You know your APIC ID is 0, so you should be able
Re: general protection fault panic
On Mon, Mar 26, 2012 at 01:18:37PM -0400, John Baldwin wrote: On Monday, March 26, 2012 12:21:29 pm Steve Kargl wrote: You know your APIC ID is 0, so you should be able to find the IRQ for vector 51 from here in apic_idt_to_irq(): irq = lapics[apic_id].la_ioint_irqs[vector - APIC_IO_INTS]; Your apic_id is 0, and APIC_IO_INTS is 48, so you should be able to do this in kgdb: p lapics[0].la_ioint_irqs[3] That should give you an index, and intr_lookup_source() just does an array lookup. However, I'd be curious to see what the assembly looks like (x/10i $rip at this frame). (kgdb) p lapics[0].la_ioint_irqs[3] $1 = 16 (kgdb) frame 27 #27 0x806dc186 in acpi_cpu_c1 () at /usr/src/sys/amd64/acpica/acpi_machdep.c:97 97 __asm __volatile(sti; hlt); (kgdb) x/10i $rip 0x806dc186 acpi_cpu_c1+6: leaveq 0x806dc187 acpi_cpu_c1+7: retq 0x806dc188 acpi_cpu_c1+8: nopl 0x0(%rax,%rax,1) 0x806dc190 nexus_acpi_attach: push %rbp 0x806dc191 nexus_acpi_attach+1: mov%rsp,%rbp 0x806dc194 nexus_acpi_attach+4: push %r12 0x806dc196 nexus_acpi_attach+6: push %rbx 0x806dc197 nexus_acpi_attach+7: mov%rdi,%rbx 0x806dc19a nexus_acpi_attach+10: callq 0x807551b0 nexus_init_resources 0x806dc19f nexus_acpi_attach+15: mov%rbx,%rdi In another email thread, it appears that jkim is chasing down some issues with the latest ACPI code. Perhaps, this is related? If it helps, I'll put kernel.debug and vmcore.0 at http://troutmask.apl.washington.edu/~kargl/jhb -- Steve ___ 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: general protection fault panic
On Mon, Mar 26, 2012 at 10:41 AM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Mon, Mar 26, 2012 at 01:18:37PM -0400, John Baldwin wrote: On Monday, March 26, 2012 12:21:29 pm Steve Kargl wrote: You know your APIC ID is 0, so you should be able to find the IRQ for vector 51 from here in apic_idt_to_irq(): irq = lapics[apic_id].la_ioint_irqs[vector - APIC_IO_INTS]; Your apic_id is 0, and APIC_IO_INTS is 48, so you should be able to do this in kgdb: p lapics[0].la_ioint_irqs[3] That should give you an index, and intr_lookup_source() just does an array lookup. However, I'd be curious to see what the assembly looks like (x/10i $rip at this frame). (kgdb) p lapics[0].la_ioint_irqs[3] $1 = 16 (kgdb) frame 27 #27 0x806dc186 in acpi_cpu_c1 () at /usr/src/sys/amd64/acpica/acpi_machdep.c:97 97 __asm __volatile(sti; hlt); (kgdb) x/10i $rip 0x806dc186 acpi_cpu_c1+6: leaveq 0x806dc187 acpi_cpu_c1+7: retq 0x806dc188 acpi_cpu_c1+8: nopl 0x0(%rax,%rax,1) 0x806dc190 nexus_acpi_attach: push %rbp 0x806dc191 nexus_acpi_attach+1: mov %rsp,%rbp 0x806dc194 nexus_acpi_attach+4: push %r12 0x806dc196 nexus_acpi_attach+6: push %rbx 0x806dc197 nexus_acpi_attach+7: mov %rdi,%rbx 0x806dc19a nexus_acpi_attach+10: callq 0x807551b0 nexus_init_resources 0x806dc19f nexus_acpi_attach+15: mov %rbx,%rdi In another email thread, it appears that jkim is chasing down some issues with the latest ACPI code. Perhaps, this is related? If it helps, I'll put kernel.debug and vmcore.0 at http://troutmask.apl.washington.edu/~kargl/jhb -- Steve ___ 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 Just in case it's related: I'm seeing the following error on my -current system when building with clang: clang -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 -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OP TION_HEADERS -include opt_global.h -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /usr/src/sys/ x86/x86/local_apic.c /usr/src/sys/x86/x86/local_apic.c:312:2: error: array index of '-16' indexes before the beginning of the array [-Werror,-Warray-bounds] lapics[apic_id].la_ioint_irqs[IDT_DTRACE_RET - APIC_IO_INTS] = ^ ~ /usr/src/sys/x86/x86/local_apic.c:123:2: note: array 'la_ioint_irqs' declared here int la_ioint_irqs[APIC_NUM_IOINTS + 1]; ^ 1 error generated. *** [local_apic.o] Error code 1 -- Jos Backus jos at catnook.com ___ 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: general protection fault panic
On Monday, March 26, 2012 1:41:55 pm Steve Kargl wrote: On Mon, Mar 26, 2012 at 01:18:37PM -0400, John Baldwin wrote: On Monday, March 26, 2012 12:21:29 pm Steve Kargl wrote: You know your APIC ID is 0, so you should be able to find the IRQ for vector 51 from here in apic_idt_to_irq(): irq = lapics[apic_id].la_ioint_irqs[vector - APIC_IO_INTS]; Your apic_id is 0, and APIC_IO_INTS is 48, so you should be able to do this in kgdb: p lapics[0].la_ioint_irqs[3] That should give you an index, and intr_lookup_source() just does an array lookup. However, I'd be curious to see what the assembly looks like (x/10i $rip at this frame). (kgdb) p lapics[0].la_ioint_irqs[3] $1 = 16 (kgdb) frame 27 #27 0x806dc186 in acpi_cpu_c1 () at /usr/src/sys/amd64/acpica/acpi_machdep.c:97 Sorry, I meant down at the frame that faulted (frame 7 in this case). -- 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: general protection fault panic
On Mon, Mar 26, 2012 at 01:53:25PM -0400, John Baldwin wrote:
On Monday, March 26, 2012 1:41:55 pm Steve Kargl wrote:
On Mon, Mar 26, 2012 at 01:18:37PM -0400, John Baldwin wrote:
On Monday, March 26, 2012 12:21:29 pm Steve Kargl wrote:
You know your APIC ID is 0, so you should be able to find the IRQ for
vector
51 from here in apic_idt_to_irq():
irq = lapics[apic_id].la_ioint_irqs[vector - APIC_IO_INTS];
Your apic_id is 0, and APIC_IO_INTS is 48, so you should be able to do
this
in kgdb:
p lapics[0].la_ioint_irqs[3]
That should give you an index, and intr_lookup_source() just does an array
lookup. However, I'd be curious to see what the assembly looks like
(x/10i $rip at this frame).
(kgdb) p lapics[0].la_ioint_irqs[3]
$1 = 16
(kgdb) frame 27
#27 0x806dc186 in acpi_cpu_c1 ()
at /usr/src/sys/amd64/acpica/acpi_machdep.c:97
Sorry, I meant down at the frame that faulted (frame 7 in this case).
(kgdb) frame 7
#7 0x80751232 in lapic_handle_intr (vector=51,
frame=0xff8000229a70) at /usr/src/sys/x86/x86/local_apic.c:777
777 {
(kgdb) x/10i $rip
0x80751232 lapic_handle_intr+2: stos %eax,%es:(%rdi)
0x80751233 lapic_handle_intr+3: (bad)
0x80751234 lapic_handle_intr+4: pop%rbp
0x80751235 lapic_handle_intr+5: pop%rsi
0x80751236 lapic_handle_intr+6: fsubr %st(3),%st
0x80751238 lapic_handle_intr+8: (bad)
0x80751239 lapic_handle_intr+9: or $0xac1ae6b3,%eax
0x8075123e lapic_handle_intr+14: out%eax,$0x19
0x80751240 lapic_handle_intr+16:
jl 0x8075125e lapic_handle_intr+46
0x80751242 lapic_handle_intr+18: adc%r12d,0xc6aa671(%rdi)
--
Steve
___
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: general protection fault panic
On Monday, March 26, 2012 1:59:18 pm Steve Kargl wrote:
On Mon, Mar 26, 2012 at 01:53:25PM -0400, John Baldwin wrote:
On Monday, March 26, 2012 1:41:55 pm Steve Kargl wrote:
On Mon, Mar 26, 2012 at 01:18:37PM -0400, John Baldwin wrote:
On Monday, March 26, 2012 12:21:29 pm Steve Kargl wrote:
You know your APIC ID is 0, so you should be able to find the IRQ for
vector
51 from here in apic_idt_to_irq():
irq = lapics[apic_id].la_ioint_irqs[vector - APIC_IO_INTS];
Your apic_id is 0, and APIC_IO_INTS is 48, so you should be able to do
this
in kgdb:
p lapics[0].la_ioint_irqs[3]
That should give you an index, and intr_lookup_source() just does an
array
lookup. However, I'd be curious to see what the assembly looks like
(x/10i $rip at this frame).
(kgdb) p lapics[0].la_ioint_irqs[3]
$1 = 16
(kgdb) frame 27
#27 0x806dc186 in acpi_cpu_c1 ()
at /usr/src/sys/amd64/acpica/acpi_machdep.c:97
Sorry, I meant down at the frame that faulted (frame 7 in this case).
(kgdb) frame 7
#7 0x80751232 in lapic_handle_intr (vector=51,
frame=0xff8000229a70) at /usr/src/sys/x86/x86/local_apic.c:777
777 {
(kgdb) x/10i $rip
0x80751232 lapic_handle_intr+2: stos %eax,%es:(%rdi)
0x80751233 lapic_handle_intr+3: (bad)
0x80751234 lapic_handle_intr+4: pop%rbp
0x80751235 lapic_handle_intr+5: pop%rsi
0x80751236 lapic_handle_intr+6: fsubr %st(3),%st
0x80751238 lapic_handle_intr+8: (bad)
0x80751239 lapic_handle_intr+9: or $0xac1ae6b3,%eax
0x8075123e lapic_handle_intr+14: out%eax,$0x19
0x80751240 lapic_handle_intr+16:
jl 0x8075125e lapic_handle_intr+46
0x80751242 lapic_handle_intr+18: adc%r12d,0xc6aa671(%rdi)
Looks like the instruction pointer is busted. Try doing 'x/10i
lapic_handle_intr'.
I suspect you will not see 'lapic_handle_intr+2' as a valid instruction offset.
:(
--
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: general protection fault panic
On Monday, March 26, 2012 1:51:59 pm Jos Backus wrote: On Mon, Mar 26, 2012 at 10:41 AM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Mon, Mar 26, 2012 at 01:18:37PM -0400, John Baldwin wrote: On Monday, March 26, 2012 12:21:29 pm Steve Kargl wrote: You know your APIC ID is 0, so you should be able to find the IRQ for vector 51 from here in apic_idt_to_irq(): irq = lapics[apic_id].la_ioint_irqs[vector - APIC_IO_INTS]; Your apic_id is 0, and APIC_IO_INTS is 48, so you should be able to do this in kgdb: p lapics[0].la_ioint_irqs[3] That should give you an index, and intr_lookup_source() just does an array lookup. However, I'd be curious to see what the assembly looks like (x/10i $rip at this frame). (kgdb) p lapics[0].la_ioint_irqs[3] $1 = 16 (kgdb) frame 27 #27 0x806dc186 in acpi_cpu_c1 () at /usr/src/sys/amd64/acpica/acpi_machdep.c:97 97 __asm __volatile(sti; hlt); (kgdb) x/10i $rip 0x806dc186 acpi_cpu_c1+6: leaveq 0x806dc187 acpi_cpu_c1+7: retq 0x806dc188 acpi_cpu_c1+8: nopl 0x0(%rax,%rax,1) 0x806dc190 nexus_acpi_attach: push %rbp 0x806dc191 nexus_acpi_attach+1: mov%rsp,%rbp 0x806dc194 nexus_acpi_attach+4: push %r12 0x806dc196 nexus_acpi_attach+6: push %rbx 0x806dc197 nexus_acpi_attach+7: mov%rdi,%rbx 0x806dc19a nexus_acpi_attach+10: callq 0x807551b0 nexus_init_resources 0x806dc19f nexus_acpi_attach+15: mov%rbx,%rdi In another email thread, it appears that jkim is chasing down some issues with the latest ACPI code. Perhaps, this is related? If it helps, I'll put kernel.debug and vmcore.0 at http://troutmask.apl.washington.edu/~kargl/jhb -- Steve ___ 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 Just in case it's related: I'm seeing the following error on my -current system when building with clang: clang -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 -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OP TION_HEADERS -include opt_global.h -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /usr/src/sys/ x86/x86/local_apic.c /usr/src/sys/x86/x86/local_apic.c:312:2: error: array index of '-16' indexes before the beginning of the array [-Werror,-Warray-bounds] lapics[apic_id].la_ioint_irqs[IDT_DTRACE_RET - APIC_IO_INTS] = ^ ~ /usr/src/sys/x86/x86/local_apic.c:123:2: note: array 'la_ioint_irqs' declared here int la_ioint_irqs[APIC_NUM_IOINTS + 1]; ^ 1 error generated. *** [local_apic.o] Error code 1 No, that is just a straight up bug from when IDT_DTRACE_RET was changed to 0x20 from some high number. Hmm, I wonder how the person who did that chose 0x20 since 0x20 is mapped to the 8259A IRQ 0 and may not really be safe to use. :( We can come up with a different number (which at that point would make the relevant code in local_apic.c valid again). This should not be related to Steve's issue though I believe. -- 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: general protection fault panic
On Mon, Mar 26, 2012 at 1:29 PM, John Baldwin j...@freebsd.org wrote: On Monday, March 26, 2012 1:51:59 pm Jos Backus wrote: On Mon, Mar 26, 2012 at 10:41 AM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Mon, Mar 26, 2012 at 01:18:37PM -0400, John Baldwin wrote: On Monday, March 26, 2012 12:21:29 pm Steve Kargl wrote: You know your APIC ID is 0, so you should be able to find the IRQ for vector 51 from here in apic_idt_to_irq(): irq = lapics[apic_id].la_ioint_irqs[vector - APIC_IO_INTS]; Your apic_id is 0, and APIC_IO_INTS is 48, so you should be able to do this in kgdb: p lapics[0].la_ioint_irqs[3] That should give you an index, and intr_lookup_source() just does an array lookup. However, I'd be curious to see what the assembly looks like (x/10i $rip at this frame). (kgdb) p lapics[0].la_ioint_irqs[3] $1 = 16 (kgdb) frame 27 #27 0x806dc186 in acpi_cpu_c1 () at /usr/src/sys/amd64/acpica/acpi_machdep.c:97 97 __asm __volatile(sti; hlt); (kgdb) x/10i $rip 0x806dc186 acpi_cpu_c1+6: leaveq 0x806dc187 acpi_cpu_c1+7: retq 0x806dc188 acpi_cpu_c1+8: nopl 0x0(%rax,%rax,1) 0x806dc190 nexus_acpi_attach: push %rbp 0x806dc191 nexus_acpi_attach+1: mov %rsp,%rbp 0x806dc194 nexus_acpi_attach+4: push %r12 0x806dc196 nexus_acpi_attach+6: push %rbx 0x806dc197 nexus_acpi_attach+7: mov %rdi,%rbx 0x806dc19a nexus_acpi_attach+10: callq 0x807551b0 nexus_init_resources 0x806dc19f nexus_acpi_attach+15: mov %rbx,%rdi In another email thread, it appears that jkim is chasing down some issues with the latest ACPI code. Perhaps, this is related? If it helps, I'll put kernel.debug and vmcore.0 at http://troutmask.apl.washington.edu/~kargl/jhb -- Steve ___ 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 Just in case it's related: I'm seeing the following error on my -current system when building with clang: clang -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 -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OP TION_HEADERS -include opt_global.h -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /usr/src/sys/ x86/x86/local_apic.c /usr/src/sys/x86/x86/local_apic.c:312:2: error: array index of '-16' indexes before the beginning of the array [-Werror,-Warray-bounds] lapics[apic_id].la_ioint_irqs[IDT_DTRACE_RET - APIC_IO_INTS] = ^ ~ /usr/src/sys/x86/x86/local_apic.c:123:2: note: array 'la_ioint_irqs' declared here int la_ioint_irqs[APIC_NUM_IOINTS + 1]; ^ 1 error generated. *** [local_apic.o] Error code 1 No, that is just a straight up bug from when IDT_DTRACE_RET was changed to 0x20 from some high number. Hmm, I wonder how the person who did that chose 0x20 since 0x20 is mapped to the 8259A IRQ 0 and may not really be safe to use. :( We can come up with a different number (which at that point would make the relevant code in local_apic.c valid again). This should not be related to Steve's issue though I believe. Okay, thanks for looking into this, John. Cheers, Jos -- Jos Backus jos at catnook.com ___ 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: general protection fault panic
On Mon, Mar 26, 2012 at 04:17:50PM -0400, John Baldwin wrote:
On Monday, March 26, 2012 1:59:18 pm Steve Kargl wrote:
On Mon, Mar 26, 2012 at 01:53:25PM -0400, John Baldwin wrote:
On Monday, March 26, 2012 1:41:55 pm Steve Kargl wrote:
On Mon, Mar 26, 2012 at 01:18:37PM -0400, John Baldwin wrote:
On Monday, March 26, 2012 12:21:29 pm Steve Kargl wrote:
You know your APIC ID is 0, so you should be able to find the IRQ for
vector
51 from here in apic_idt_to_irq():
irq = lapics[apic_id].la_ioint_irqs[vector - APIC_IO_INTS];
Your apic_id is 0, and APIC_IO_INTS is 48, so you should be able to
do this
in kgdb:
p lapics[0].la_ioint_irqs[3]
That should give you an index, and intr_lookup_source() just does an
array
lookup. However, I'd be curious to see what the assembly looks like
(x/10i $rip at this frame).
(kgdb) p lapics[0].la_ioint_irqs[3]
$1 = 16
(kgdb) frame 27
#27 0x806dc186 in acpi_cpu_c1 ()
at /usr/src/sys/amd64/acpica/acpi_machdep.c:97
Sorry, I meant down at the frame that faulted (frame 7 in this case).
(kgdb) frame 7
#7 0x80751232 in lapic_handle_intr (vector=51,
frame=0xff8000229a70) at /usr/src/sys/x86/x86/local_apic.c:777
777 {
(kgdb) x/10i $rip
0x80751232 lapic_handle_intr+2: stos %eax,%es:(%rdi)
0x80751233 lapic_handle_intr+3: (bad)
0x80751234 lapic_handle_intr+4: pop%rbp
0x80751235 lapic_handle_intr+5: pop%rsi
0x80751236 lapic_handle_intr+6: fsubr %st(3),%st
0x80751238 lapic_handle_intr+8: (bad)
0x80751239 lapic_handle_intr+9: or $0xac1ae6b3,%eax
0x8075123e lapic_handle_intr+14: out%eax,$0x19
0x80751240 lapic_handle_intr+16:
jl 0x8075125e lapic_handle_intr+46
0x80751242 lapic_handle_intr+18: adc%r12d,0xc6aa671(%rdi)
Looks like the instruction pointer is busted. Try doing 'x/10i
lapic_handle_intr'.
I suspect you will not see 'lapic_handle_intr+2' as a valid instruction
offset. :(
I'm assuming you want this in frame 7
(kgdb) frame 7
#7 0x80751232 in lapic_handle_intr (vector=51,
frame=0xff8000229a70) at /usr/src/sys/x86/x86/local_apic.c:777
(kgdb) x/10i lapic_handle_intr
0x80751230 lapic_handle_intr: sbb$0xa7,%al
0x80751232 lapic_handle_intr+2: stos %eax,%es:(%rdi)
0x80751233 lapic_handle_intr+3: (bad)
0x80751234 lapic_handle_intr+4: pop%rbp
0x80751235 lapic_handle_intr+5: pop%rsi
0x80751236 lapic_handle_intr+6: fsubr %st(3),%st
0x80751238 lapic_handle_intr+8: (bad)
0x80751239 lapic_handle_intr+9: or $0xac1ae6b3,%eax
0x8075123e lapic_handle_intr+14: out%eax,$0x19
0x80751240 lapic_handle_intr+16:
jl 0x8075125e lapic_handle_intr+46
--
Steve
___
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: DTrace/MIPS port
On 01/03/2012 1:49 PM, Oleksandr Tymoshenko wrote: Hello, Last few weeks I've been working on DTrace port for MIPS architecture. I believe that project reached the stage when it's ready for public review/testing before going into the tree. Patch and some information could be found here: http://people.freebsd.org/~gonzo/mips/dtrace/ I'd appreciate review/testing from interested parties and if there are no major roadblocks the plan is to commit this patch sometime next week. These changes are now committed into the FreeBSD HEAD branch ___ 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: DTrace/MIPS port
On 26 March 2012 15:01, Oleksandr Tymoshenko go...@freebsd.org wrote: These changes are now committed into the FreeBSD HEAD branch Great work! 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
Updating the tuning man page
As some of you may know there is/was an effort to rewrite the tuning man page at http://wiki.freebsd.org/SystemTuning . At the moment it seems to have a lot of content with questions and unconfirmed data. Any effort spent on improving the page would go a long way to improving the documentation. If we could get this wiki page (editable by anyone) into a decent shape I'd be happy to turn it into a mdoc patch and commit it. Feel free to just remove old information and replace it with modern content. There is no need to mark up your specific changes - I'll deal with that when I write up the patch. Feel free to email me with any questions. -- Eitan Adler ___ 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: Updating the tuning man page
On Mon, Mar 26, 2012 at 8:55 PM, Eitan Adler li...@eitanadler.com wrote: As some of you may know there is/was an effort to rewrite the tuning man page at http://wiki.freebsd.org/SystemTuning . At the moment it seems to have a lot of content with questions and unconfirmed data. Any effort spent on improving the page would go a long way to improving the documentation. If we could get this wiki page (editable by anyone) into a decent shape I'd be happy to turn it into a mdoc patch and commit it. Feel free to just remove old information and replace it with modern content. There is no need to mark up your specific changes - I'll deal with that when I write up the patch. Feel free to email me with any questions. Should tuning include discussion of tuning for power management? Even server operators are becoming aware of the need for power management and the only really good information on it is mav's excellent wiki page. From queries about the subject, most people really don't understand the concepts and do the wrong thing. Frankly, FreeBSD does the wrong thing by default, as mav pointed out. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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
