Still getting this newsletter. Please UNSUBSCRIBE! ___________________________________________________________
Begin forwarded message: From: freebsd-bugs-requ...@freebsd.org<mailto:freebsd-bugs-requ...@freebsd.org> Subject: freebsd-bugs Digest, Vol 399, Issue 9 Date: November 19, 2010 6:00:25 AM CST To: freebsd-bugs@freebsd.org<mailto:freebsd-bugs@freebsd.org> Reply-To: freebsd-bugs@freebsd.org<mailto:freebsd-bugs@freebsd.org> Send freebsd-bugs mailing list submissions to freebsd-bugs@freebsd.org<mailto:freebsd-bugs@freebsd.org> To subscribe or unsubscribe via the World Wide Web, visit http://lists.freebsd.org/mailman/listinfo/freebsd-bugs or, via email, send a message with subject or body 'help' to freebsd-bugs-requ...@freebsd.org<mailto:freebsd-bugs-requ...@freebsd.org> You can reach the person managing the list at freebsd-bugs-ow...@freebsd.org<mailto:freebsd-bugs-ow...@freebsd.org> When replying, please edit your Subject line so it is more specific than "Re: Contents of freebsd-bugs digest..." Today's Topics: 1. kern/152363: Apache can not serve images from TMPFS (Karlo Luiten) 2. Re: kern/152363: Apache can not serve images from TMPFS (Mateusz Guzik) 3. Re: ports/152361: [PATCH] multimedia/playd update (lini...@freebsd.org<mailto:lini...@freebsd.org>) 4. Re: misc/152296: wrong message when trying to checkout using old repository path (arun...@freebsd.org<mailto:arun...@freebsd.org>) 5. Re: kern/152360: [dummynet] [panic] Crash related to dummynet. (lini...@freebsd.org<mailto:lini...@freebsd.org>) 6. Re: kern/69066: [panic] nmdm(4) page fault when slattach on a null modem device (j...@freebsd.org<mailto:j...@freebsd.org>) 7. Re: misc/152296: wrong message when trying to checkout using old repository path (Eir Nym) 8. Re: kern/145999: [request] optional offset for `mdconfig -t vnode' (Mateusz Guzik) 9. Re: kern/79295: umount oddity with NFS (fwe) over VIA Fire II card (j...@freebsd.org<mailto:j...@freebsd.org>) 10. Re: kern/85450: [ata] [panic] subdisk6 detached (appears to be a sata problem, SiI 3112) (j...@freebsd.org<mailto:j...@freebsd.org>) 11. kern/152378: [sound][patch] Update snd_envy24ht to be MPSAFE and use 32-bit DMA addresses (Jason Harmening) 12. Re: kern/152378: [sound][patch] Update snd_envy24ht to be MPSAFE and use 32-bit DMA addresses (arun...@freebsd.org<mailto:arun...@freebsd.org>) 13. bin/152385: ee(1) has different keybindings in the livefs environment (Bruce Cran) 14. Re: bin/38727: [patch] mptable(1) should complain about garbage arguments (arun...@freebsd.org<mailto:arun...@freebsd.org>) 15. Re: bin/38727: [patch] mptable(1) should complain about garbage arguments (Alexander Best) 16. Re: kern/145385: [cpu] Logical processor cannot be disabled for some SMT-enabled Intel procs (Garrett Cooper) 17. Re: kern/145385: [cpu] Logical processor cannot be disabled for some SMT-enabled Intel procs (Garrett Cooper) 18. Re: kern/145385: [cpu] Logical processor cannot be disabled for some SMT-enabled Intel procs (Andriy Gapon) ---------------------------------------------------------------------- Message: 1 Date: Thu, 18 Nov 2010 14:27:14 +0100 (CET) From: Karlo Luiten <ka...@anywi.com<mailto:ka...@anywi.com>> Subject: kern/152363: Apache can not serve images from TMPFS To: freebsd-gnats-sub...@freebsd.org<mailto:freebsd-gnats-sub...@freebsd.org> Message-ID: <20101118132714.32ad229b...@arenal.anywi.com<mailto:20101118132714.32ad229b...@arenal.anywi.com>> Number: 152363 Category: kern Synopsis: Apache can not serve images from TMPFS Confidential: no Severity: non-critical Priority: high Responsible: freebsd-bugs State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Thu Nov 18 13:50:06 UTC 2010 Closed-Date: Last-Modified: Originator: Karlo Luiten Release: FreeBSD 8.1-STABLE amd64 Organization: AnyWi Technologies Environment: System: FreeBSD arenal.anywi.com<http://arenal.anywi.com/> 8.1-STABLE FreeBSD 8.1-STABLE #0: Mon Sep 13 15:48:43 CEST 2010 r...@arenal.anywi.com:/usr/obj/usr/src/sys/ARENAL amd64 Description: When /tmp is mounted via TMPFS, and an apache virtualhost is set up to serve images from a directory within /tmp (documentroot), images are not displayed proberly in browsers (Opera,Chrome). Tested with .jpg. 1st line of hexdump of original file: 0000000 d8ff e0ff 1000 464a 4649 0100 0001 0100 1st lines of hexdump of apache-served file: 0000000 0000 0000 0000 0000 0000 0000 0000 0000 * 0000140 8600 0065 0008 0000 2200 0053 0008 0000 How-To-Repeat: Mount tmpfs: (/etc/fstab): tmpfs /tmp tmpfs rw,size=536870912,mode=01777 0 0 Setup a virtualhost within Apache with document root /tmp/any_dir Place a jpg file in this directory, try to access it Fix: None (use mdconfig disk instead of tmpfs). Release-Note: Audit-Trail: Unformatted: ------------------------------ Message: 2 Date: Thu, 18 Nov 2010 14:30:14 GMT From: Mateusz Guzik <mjgu...@gmail.com<mailto:mjgu...@gmail.com>> Subject: Re: kern/152363: Apache can not serve images from TMPFS To: freebsd-bugs@FreeBSD.org<mailto:freebsd-bugs@FreeBSD.org> Message-ID: <201011181430.oaieuebd092...@freefall.freebsd.org<mailto:201011181430.oaieuebd092...@freefall.freebsd.org>> The following reply was made to PR kern/152363; it has been noted by GNATS. From: Mateusz Guzik <mjgu...@gmail.com<mailto:mjgu...@gmail.com>> To: bug-follo...@freebsd.org<mailto:bug-follo...@freebsd.org>, ka...@anywi.com<mailto:ka...@anywi.com> Cc: Subject: Re: kern/152363: Apache can not serve images from TMPFS Date: Thu, 18 Nov 2010 14:59:42 +0100 Your issue is probably already fixed in STABLE - see http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/127213 Can you update your system and try to reproduce this problem? -- Mateusz Guzik ------------------------------ Message: 3 Date: Thu, 18 Nov 2010 15:46:04 GMT From: lini...@freebsd.org<mailto:lini...@freebsd.org> Subject: Re: ports/152361: [PATCH] multimedia/playd update To: lini...@freebsd.org<mailto:lini...@freebsd.org>, freebsd-bugs@FreeBSD.org<mailto:freebsd-bugs@FreeBSD.org>, freebsd-ports-b...@freebsd.org<mailto:freebsd-ports-b...@freebsd.org> Message-ID: <201011181546.oaifk4fb074...@freefall.freebsd.org<mailto:201011181546.oaifk4fb074...@freefall.freebsd.org>> Synopsis: [PATCH] multimedia/playd update Responsible-Changed-From-To: freebsd-bugs->freebsd-ports-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Thu Nov 18 15:45:38 UTC 2010 Responsible-Changed-Why: ports PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=152361 ------------------------------ Message: 4 Date: Thu, 18 Nov 2010 17:15:35 GMT From: arun...@freebsd.org<mailto:arun...@freebsd.org> Subject: Re: misc/152296: wrong message when trying to checkout using old repository path To: ken...@gmail.com<mailto:ken...@gmail.com>, arun...@freebsd.org<mailto:arun...@freebsd.org>, freebsd-bugs@FreeBSD.org<mailto:freebsd-bugs@FreeBSD.org>, freebsd-po...@freebsd.org<mailto:freebsd-po...@freebsd.org> Message-ID: <201011181715.oaihfzdk070...@freefall.freebsd.org<mailto:201011181715.oaihfzdk070...@freefall.freebsd.org>> Synopsis: wrong message when trying to checkout using old repository path State-Changed-From-To: open->suspended State-Changed-By: arundel State-Changed-When: Thu Nov 18 16:58:58 UTC 2010 State-Changed-Why: I'm very sorry for handling this PR inappropriatly. Somehow I was under the impression that we had a version of svn in the base tree. However that is not the case! I think marking this as suspended is the best option for now, since there was no patch attached to correct svn's handling of the wrong URL. Since the svn port seems to get updated very regularly we can assume that the development version of svn is still containing this issue. If somebody wants to provide a patch we could try convincing the svn developers to push it upstream in order to have it in one of the next svn releases and thus ports. A different approach would be to add a local ports patch to devel/subversion{-freebsd}/files. Responsible-Changed-From-To: freebsd-bugs->freebsd-ports Responsible-Changed-By: arundel Responsible-Changed-When: Thu Nov 18 16:58:58 UTC 2010 Responsible-Changed-Why: This is a ports related PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=152296 ------------------------------ Message: 5 Date: Thu, 18 Nov 2010 17:34:48 GMT From: lini...@freebsd.org<mailto:lini...@freebsd.org> Subject: Re: kern/152360: [dummynet] [panic] Crash related to dummynet. To: lini...@freebsd.org<mailto:lini...@freebsd.org>, freebsd-bugs@FreeBSD.org<mailto:freebsd-bugs@FreeBSD.org>, freebsd-...@freebsd.org<mailto:freebsd-...@freebsd.org> Message-ID: <201011181734.oaihymle090...@freefall.freebsd.org<mailto:201011181734.oaihymle090...@freefall.freebsd.org>> Old Synopsis: Crash related to dummynet. New Synopsis: [dummynet] [panic] Crash related to dummynet. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Nov 18 17:34:27 UTC 2010 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=152360 ------------------------------ Message: 6 Date: Thu, 18 Nov 2010 17:44:30 GMT From: j...@freebsd.org<mailto:j...@freebsd.org> Subject: Re: kern/69066: [panic] nmdm(4) page fault when slattach on a null modem device To: rwat...@freebsd.org<mailto:rwat...@freebsd.org>, j...@freebsd.org<mailto:j...@freebsd.org>, freebsd-bugs@FreeBSD.org<mailto:freebsd-bugs@FreeBSD.org> Message-ID: <201011181744.oaihiurh000...@freefall.freebsd.org<mailto:201011181744.oaihiurh000...@freefall.freebsd.org>> Synopsis: [panic] nmdm(4) page fault when slattach on a null modem device State-Changed-From-To: feedback->closed State-Changed-By: jh State-Changed-When: Thu Nov 18 17:41:42 UTC 2010 State-Changed-Why: There is no evidence that the problem still exists. SLIP has been removed from head and stable/8. http://www.freebsd.org/cgi/query-pr.cgi?pr=69066 ------------------------------ Message: 7 Date: Thu, 18 Nov 2010 20:38:48 +0300 From: Eir Nym <eir...@gmail.com<mailto:eir...@gmail.com>> Subject: Re: misc/152296: wrong message when trying to checkout using old repository path To: arun...@freebsd.org<mailto:arun...@freebsd.org> Cc: ken...@gmail.com<mailto:ken...@gmail.com>, freebsd-bugs@freebsd.org<mailto:freebsd-bugs@freebsd.org>, freebsd-po...@freebsd.org<mailto:freebsd-po...@freebsd.org>, FreeBSD Mail Lists <bug-follo...@freebsd.org<mailto:bug-follo...@freebsd.org>> Message-ID: <aanlktimt7rmky5rnec2hp1mrmaacinzfgwmha_rp2...@mail.gmail.com<mailto:aanlktimt7rmky5rnec2hp1mrmaacinzfgwmha_rp2...@mail.gmail.com>> Content-Type: text/plain; charset=UTF-8 On 18 November 2010 20:15, <arun...@freebsd.org<mailto:arun...@freebsd.org>> wrote: Synopsis: wrong message when trying to checkout using old repository path State-Changed-From-To: open->suspended State-Changed-By: arundel State-Changed-When: Thu Nov 18 16:58:58 UTC 2010 State-Changed-Why: I'm very sorry for handling this PR inappropriatly. Somehow I was under the impression that we had a version of svn in the base tree. However that is not the case! I think marking this as suspended is the best option for now, since there was no patch attached to correct svn's handling of the wrong URL. Since the svn port seems to get updated very regularly we can assume that the development version of svn is still containing this issue. If somebody wants to provide a patch we could try convincing the svn developers to push it upstream in order to have it in one of the next svn releases and thus ports. A different approach would be to add a local ports patch to devel/subversion{-freebsd}/files. Responsible-Changed-From-To: freebsd-bugs->freebsd-ports Responsible-Changed-By: arundel Responsible-Changed-When: Thu Nov 18 16:58:58 UTC 2010 Responsible-Changed-Why: This is a ports related PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=152296 _______________________________________________ freebsd-po...@freebsd.org<mailto:freebsd-po...@freebsd.org> mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org<mailto:freebsd-ports-unsubscr...@freebsd.org>" I see only two possible ways to fix this problem: If you have checkouted source tree before, you can use following command to relocate it: find /usr/src -name .svn|xargs -n 1 -J XXX sed -i '.bak' 's,http://svn.freebsd.org/viewvc/base/head/usr.bin/,http://svn.freebsd.org/base/head/usr.bin/,' XXX/entries If you can't checkout source tree with wrong url - fix your script, which check out source tree, but never svn. ------------------------------ Message: 8 Date: Thu, 18 Nov 2010 18:30:14 GMT From: Mateusz Guzik <mjgu...@gmail.com<mailto:mjgu...@gmail.com>> Subject: Re: kern/145999: [request] optional offset for `mdconfig -t vnode' To: freebsd-bugs@FreeBSD.org<mailto:freebsd-bugs@FreeBSD.org> Message-ID: <201011181830.oaiiuezb042...@freefall.freebsd.org<mailto:201011181830.oaiiuezb042...@freefall.freebsd.org>> The following reply was made to PR kern/145999; it has been noted by GNATS. From: Mateusz Guzik <mjgu...@gmail.com<mailto:mjgu...@gmail.com>> To: bug-follo...@freebsd.org<mailto:bug-follo...@freebsd.org>, m...@aldan.algebra.com<mailto:m...@aldan.algebra.com> Cc: Subject: Re: kern/145999: [request] optional offset for `mdconfig -t vnode' Date: Thu, 18 Nov 2010 19:29:05 +0100 This can be achieved with gnop(8). $ mdocnfig -t vnode <image> md0 $ gnop create -o <offset in bytes> md0 $ ls /dev/md0* /dev/md0 /dev/md0.nop /dev/md0.nops1 /dev/md0.nops1a /dev/md0.nops1b /dev/md0.nops1d Have fun. :) -- Mateusz Guzik ------------------------------ Message: 9 Date: Thu, 18 Nov 2010 20:32:32 GMT From: j...@freebsd.org<mailto:j...@freebsd.org> Subject: Re: kern/79295: umount oddity with NFS (fwe) over VIA Fire II card To: r...@schmalzbauer.de<mailto:r...@schmalzbauer.de>, j...@freebsd.org<mailto:j...@freebsd.org>, freebsd-bugs@FreeBSD.org<mailto:freebsd-bugs@FreeBSD.org> Message-ID: <201011182032.oaikwwjl076...@freefall.freebsd.org<mailto:201011182032.oaikwwjl076...@freefall.freebsd.org>> Synopsis: umount oddity with NFS (fwe) over VIA Fire II card State-Changed-From-To: open->feedback State-Changed-By: jh State-Changed-When: Thu Nov 18 20:32:32 UTC 2010 State-Changed-Why: Can you still reproduce this on recent FreeBSD versions? http://www.freebsd.org/cgi/query-pr.cgi?pr=79295 ------------------------------ Message: 10 Date: Thu, 18 Nov 2010 20:35:39 GMT From: j...@freebsd.org<mailto:j...@freebsd.org> Subject: Re: kern/85450: [ata] [panic] subdisk6 detached (appears to be a sata problem, SiI 3112) To: b.vand...@chello.nl<mailto:b.vand...@chello.nl>, j...@freebsd.org<mailto:j...@freebsd.org>, freebsd-bugs@FreeBSD.org<mailto:freebsd-bugs@FreeBSD.org> Message-ID: <201011182035.oaikzdkh078...@freefall.freebsd.org<mailto:201011182035.oaikzdkh078...@freefall.freebsd.org>> Synopsis: [ata] [panic] subdisk6 detached (appears to be a sata problem, SiI 3112) State-Changed-From-To: open->feedback State-Changed-By: jh State-Changed-When: Thu Nov 18 20:35:39 UTC 2010 State-Changed-Why: Can you still reproduce this on recent FreeBSD versions? http://www.freebsd.org/cgi/query-pr.cgi?pr=85450 ------------------------------ Message: 11 Date: Thu, 18 Nov 2010 20:55:34 GMT From: Jason Harmening <jason.harmen...@gmail.com<mailto:jason.harmen...@gmail.com>> Subject: kern/152378: [sound][patch] Update snd_envy24ht to be MPSAFE and use 32-bit DMA addresses To: freebsd-gnats-sub...@freebsd.org<mailto:freebsd-gnats-sub...@freebsd.org> Message-ID: <201011182055.oaiktye5057...@www.freebsd.org<mailto:201011182055.oaiktye5057...@www.freebsd.org>> Number: 152378 Category: kern Synopsis: [sound][patch] Update snd_envy24ht to be MPSAFE and use 32-bit DMA addresses Confidential: no Severity: non-critical Priority: medium Responsible: freebsd-bugs State: open Quarter: Keywords: Date-Required: Class: change-request Submitter-Id: current-users Arrival-Date: Thu Nov 18 21:00:18 UTC 2010 Closed-Date: Last-Modified: Originator: Jason Harmening Release: 8.1-STABLE Organization: Environment: FreeBSD riviera.austin.rr.com<http://riviera.austin.rr.com/> 8.1-STABLE FreeBSD 8.1-STABLE #0: Sun Nov 14 12:01:19 CST 2010 ja...@riviera.austin.rr.com:/usr/obj/usr/src/sys/CUSTOM amd64 Description: --Allow DMA addresses anywhere in the lower 4GB--Envy24HT has a 32-bit DMA engine, not 28-bit like Envy24 --Mark interrupt handler as MPSAFE, seems to be correctly synchronized Testing done: daily usage of envy24ht-based sound card for ~1yr on machine w/ 6GB RAM How-To-Repeat: Fix: Patch attached with submission follows: --- envy24ht.h.orig 2007-05-27 14:58:39.000000000 -0500 +++ envy24ht.h 2009-05-06 10:49:56.000000000 -0500 @@ -176,8 +176,7 @@ #define ENVY24HT_VOL_MIN 96 /* -144db(negate) */ #define ENVY24HT_VOL_MUTE 127 /* mute */ -#define BUS_SPACE_MAXADDR_ENVY24 0x0fffffff /* Address space beyond 256MB is not - supported */ +#define BUS_SPACE_MAXADDR_ENVY24 0xffffffff #define BUS_SPACE_MAXSIZE_ENVY24 0x3fffc /* 64k x 4byte(1dword) */ #define ENVY24HT_CCS_GPIO_HDATA 0x1E --- envy24ht.c 2009-05-07 09:09:31.000000000 -0500 +++ envy24ht.c 2009-05-07 09:22:38.000000000 -0500 @@ -2421,7 +2421,7 @@ sc->irq = bus_alloc_resource(sc->dev, SYS_RES_IRQ, &sc->irqid, 0, ~0, 1, RF_ACTIVE | RF_SHAREABLE); if (!sc->irq || - snd_setup_intr(sc->dev, sc->irq, 0, envy24ht_intr, sc, &sc->ih)) { + snd_setup_intr(sc->dev, sc->irq, INTR_MPSAFE, envy24ht_intr, sc, &sc->ih)) { device_printf(sc->dev, "unable to map interrupt\n"); return ENXIO; } @@ -2431,7 +2431,7 @@ /*alignment*/4, /*boundary*/0, /*lowaddr*/BUS_SPACE_MAXADDR_ENVY24, - /*highaddr*/BUS_SPACE_MAXADDR_ENVY24, + /*highaddr*/BUS_SPACE_MAXADDR, /*filter*/NULL, /*filterarg*/NULL, /*maxsize*/BUS_SPACE_MAXSIZE_ENVY24, /*nsegments*/1, /*maxsegsz*/0x3ffff, Release-Note: Audit-Trail: Unformatted: ------------------------------ Message: 12 Date: Thu, 18 Nov 2010 21:22:42 GMT From: arun...@freebsd.org<mailto:arun...@freebsd.org> Subject: Re: kern/152378: [sound][patch] Update snd_envy24ht to be MPSAFE and use 32-bit DMA addresses To: arun...@freebsd.org<mailto:arun...@freebsd.org>, freebsd-bugs@FreeBSD.org<mailto:freebsd-bugs@FreeBSD.org>, freebsd-multime...@freebsd.org<mailto:freebsd-multime...@freebsd.org> Message-ID: <201011182122.oailmgu7030...@freefall.freebsd.org<mailto:201011182122.oailmgu7030...@freefall.freebsd.org>> Synopsis: [sound][patch] Update snd_envy24ht to be MPSAFE and use 32-bit DMA addresses Responsible-Changed-From-To: freebsd-bugs->freebsd-multimedia Responsible-Changed-By: arundel Responsible-Changed-When: Thu Nov 18 21:20:59 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=152378 ------------------------------ Message: 13 Date: Thu, 18 Nov 2010 21:42:16 GMT From: Bruce Cran <br...@cran.org.uk<mailto:br...@cran.org.uk>> Subject: bin/152385: ee(1) has different keybindings in the livefs environment To: freebsd-gnats-sub...@freebsd.org<mailto:freebsd-gnats-sub...@freebsd.org> Message-ID: <201011182142.oailgger093...@www.freebsd.org<mailto:201011182142.oailgger093...@www.freebsd.org>> Number: 152385 Category: bin Synopsis: ee(1) has different keybindings in the livefs environment Confidential: no Severity: non-critical Priority: low Responsible: freebsd-bugs State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Thu Nov 18 21:50:08 UTC 2010 Closed-Date: Last-Modified: Originator: Bruce Cran Release: 9.0-CURRENT Organization: Environment: N/A Description: In the 9-CURRENT snapshot livefs environment the keybindings for ee(1) are different to those when it's used in an installed system. This makes it rather frustrating to use. How-To-Repeat: Run ee from a livefs environment. Fix: Release-Note: Audit-Trail: Unformatted: ------------------------------ Message: 14 Date: Thu, 18 Nov 2010 23:32:27 GMT From: arun...@freebsd.org<mailto:arun...@freebsd.org> Subject: Re: bin/38727: [patch] mptable(1) should complain about garbage arguments To: zait...@redhat.com<mailto:zait...@redhat.com>, arun...@freebsd.org<mailto:arun...@freebsd.org>, freebsd-bugs@FreeBSD.org<mailto:freebsd-bugs@FreeBSD.org> Message-ID: <201011182332.oainwrlh064...@freefall.freebsd.org<mailto:201011182332.oainwrlh064...@freefall.freebsd.org>> Synopsis: [patch] mptable(1) should complain about garbage arguments State-Changed-From-To: open->analyzed State-Changed-By: arundel State-Changed-When: Thu Nov 18 23:31:29 UTC 2010 State-Changed-Why: Can somebody please commit this patch? I'll send in an updated version which applies cleanly to HEAD right away. http://www.freebsd.org/cgi/query-pr.cgi?pr=38727 ------------------------------ Message: 15 Date: Fri, 19 Nov 2010 00:00:34 GMT From: Alexander Best <arun...@freebsd.org<mailto:arun...@freebsd.org>> Subject: Re: bin/38727: [patch] mptable(1) should complain about garbage arguments To: freebsd-bugs@FreeBSD.org<mailto:freebsd-bugs@FreeBSD.org> Message-ID: <201011190000.oaj00ywk084...@freefall.freebsd.org<mailto:201011190000.oaj00ywk084...@freefall.freebsd.org>> The following reply was made to PR bin/38727; it has been noted by GNATS. From: Alexander Best <arun...@freebsd.org<mailto:arun...@freebsd.org>> To: bug-follo...@freebsd.org<mailto:bug-follo...@freebsd.org> Cc: Subject: Re: bin/38727: [patch] mptable(1) should complain about garbage arguments Date: Thu, 18 Nov 2010 23:53:39 +0000 --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline here's an updated patch which applies cleanly to HEAD. cheers. alex -- a13x --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mptable.c.diff" diff --git a/usr.sbin/mptable/mptable.c b/usr.sbin/mptable/mptable.c index a16a1b9..b461e61 100644 --- a/usr.sbin/mptable/mptable.c +++ b/usr.sbin/mptable/mptable.c @@ -322,20 +322,21 @@ main( int argc, char *argv[] ) if ( strcmp( optarg, "mesg") == 0 ) dmesg = 1; else - dmesg = 0; - break; - case 'h': - if ( strcmp( optarg, "elp") == 0 ) - usage(); + usage(); break; case 'g': if ( strcmp( optarg, "rope") == 0 ) grope = 1; + else + usage(); break; case 'v': if ( strcmp( optarg, "erbose") == 0 ) verbose = 1; + else + usage(); break; + case 'h': default: usage(); } --+QahgC5+KEYLbs62-- ------------------------------ Message: 16 Date: Fri, 19 Nov 2010 00:10:12 GMT From: Garrett Cooper <gcoo...@freebsd.org<mailto:gcoo...@freebsd.org>> Subject: Re: kern/145385: [cpu] Logical processor cannot be disabled for some SMT-enabled Intel procs To: freebsd-bugs@FreeBSD.org<mailto:freebsd-bugs@FreeBSD.org> Message-ID: <201011190010.oaj0acwk095...@freefall.freebsd.org<mailto:201011190010.oaj0acwk095...@freefall.freebsd.org>> The following reply was made to PR kern/145385; it has been noted by GNATS. From: Garrett Cooper <gcoo...@freebsd.org<mailto:gcoo...@freebsd.org>> To: Andriy Gapon <a...@freebsd.org<mailto:a...@freebsd.org>> Cc: bug-follo...@freebsd.org<mailto:bug-follo...@freebsd.org> Subject: Re: kern/145385: [cpu] Logical processor cannot be disabled for some SMT-enabled Intel procs Date: Thu, 18 Nov 2010 16:09:46 -0800 On Wed, Nov 17, 2010 at 4:34 PM, Garrett Cooper <gcoo...@freebsd.org<mailto:gcoo...@freebsd.org>> wrote= : On Thu, Oct 7, 2010 at 10:03 AM, Andriy Gapon <a...@freebsd.org<mailto:a...@freebsd.org>> wrote: Here's a patch to remove halted logical processors from root cpu set (cp= uset number zero) and consequently all child sets: http://people.freebsd.org/~avg/cpu-halt.diff Please note that unhalting CPUs will add them to cpuset zero, but will n= ot (re-)add them cpusets of the running processes. =A0So additional action = will be required from system administrator if e would like existing processes to= make use of unhalted CPUs. Also, interrupts that are bound to halted CPUs are not rebound on halt, = and so will be delivered to halted CPUs. =A0This should not be a problem for ty= pical environments, but would be nice to fix anyway. =A0 =A0Sorry for taking so long to get back on this item. The patch looks ok as far as setting the CPUSET is concerned (setting machdep.hlt_logical_cpus=3D1 works on an r710 with 8 logical procs as SCHED_ULE schedules all of the tasks on the non-logical SMT cores, not the logical ones, and the patch properly detects that there aren't any logical processors on a Core2 Quad I have at home), but it's missing a key case where I go from... machdep.hlt_logical_cpus: 1 -> 0 =A0 =A0... it should reset CPUSETZERO. =A0 =A0The overall CPU topology should probably be cached and restored when reset, or at least CPUSETZERO should be reset (probably the simpler and cleaner route to go). =A0 =A0After that all that's required is work for i386 and I'd vote for a commit of the patch. Thanks for the hard work Andriy :)! Just to illustrate, here's how I reproduced the successful behavior (and the problem): 1. Execute the following script: #!/bin/sh i=3D0 ncpus=3D`sysctl -n kern.smp.cpus` while [ $i -lt $ncpus ] ; do while : ; do : ; done & : $(( i +=3D 1 )) done 2. Execute sysctl machdep.hlt_logical_cpus=3D1 . 3. Look at cpuset info; example: Before: # for i in `ps aux | grep gcooper | grep -v grep | awk '{ print $2 }'` ; do cpuset -g -p $i ; done pid 2179 mask: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 pid 2180 mask: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 After: # for i in `ps aux | grep gcooper | grep -v grep | awk '{ print $2 }'` ; do cpuset -g -p $i ; done pid 2179 mask: 0, 2, 4, 6, 8, 10, 12, 14 pid 2180 mask: 0, 2, 4, 6, 8, 10, 12, 14 # sysctl machdep.hlt_logical_cpus=3D0 machdep.hlt_logical_cpus: 1 -> 0 # for i in `ps aux | grep gcooper | grep -v grep | awk '{ print $2 }'` ; do cpuset -g -p $i ; done pid 2179 mask: 0, 2, 4, 6, 8, 10, 12, 14 pid 2180 mask: 0, 2, 4, 6, 8, 10, 12, 14 I'm taking the patch and running with it now to try and get it working 100%= . ------------------------------ Message: 17 Date: Fri, 19 Nov 2010 03:10:15 GMT From: Garrett Cooper <gcoo...@freebsd.org<mailto:gcoo...@freebsd.org>> Subject: Re: kern/145385: [cpu] Logical processor cannot be disabled for some SMT-enabled Intel procs To: freebsd-bugs@FreeBSD.org<mailto:freebsd-bugs@FreeBSD.org> Message-ID: <201011190310.oaj3afng082...@freefall.freebsd.org<mailto:201011190310.oaj3afng082...@freefall.freebsd.org>> The following reply was made to PR kern/145385; it has been noted by GNATS. From: Garrett Cooper <gcoo...@freebsd.org<mailto:gcoo...@freebsd.org>> To: Andriy Gapon <a...@freebsd.org<mailto:a...@freebsd.org>> Cc: bug-follo...@freebsd.org<mailto:bug-follo...@freebsd.org> Subject: Re: kern/145385: [cpu] Logical processor cannot be disabled for some SMT-enabled Intel procs Date: Thu, 18 Nov 2010 19:01:08 -0800 --0016e6567d28366ef604955f1e9a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Nov 18, 2010 at 4:09 PM, Garrett Cooper <gcoo...@freebsd.org<mailto:gcoo...@freebsd.org>> wrote= : On Wed, Nov 17, 2010 at 4:34 PM, Garrett Cooper <gcoo...@freebsd.org<mailto:gcoo...@freebsd.org>> wro= te: On Thu, Oct 7, 2010 at 10:03 AM, Andriy Gapon <a...@freebsd.org<mailto:a...@freebsd.org>> wrote: Here's a patch to remove halted logical processors from root cpu set (c= puset number zero) and consequently all child sets: http://people.freebsd.org/~avg/cpu-halt.diff Please note that unhalting CPUs will add them to cpuset zero, but will = not (re-)add them cpusets of the running processes. =A0So additional action= will be required from system administrator if e would like existing processes t= o make use of unhalted CPUs. Also, interrupts that are bound to halted CPUs are not rebound on halt,= and so will be delivered to halted CPUs. =A0This should not be a problem for t= ypical environments, but would be nice to fix anyway. =A0 =A0Sorry for taking so long to get back on this item. The patch look= s ok as far as setting the CPUSET is concerned (setting machdep.hlt_logical_cpus=3D1 works on an r710 with 8 logical procs as SCHED_ULE schedules all of the tasks on the non-logical SMT cores, not the logical ones, and the patch properly detects that there aren't any logical processors on a Core2 Quad I have at home), but it's missing a key case where I go from... machdep.hlt_logical_cpus: 1 -> 0 =A0 =A0... it should reset CPUSETZERO. =A0 =A0The overall CPU topology should probably be cached and restored when reset, or at least CPUSETZERO should be reset (probably the simpler and cleaner route to go). =A0 =A0After that all that's required is work for i386 and I'd vote for = a commit of the patch. Thanks for the hard work Andriy :)! Just to illustrate, here's how I reproduced the successful behavior (and the problem): 1. Execute the following script: #!/bin/sh i=3D0 ncpus=3D`sysctl -n kern.smp.cpus` while [ $i -lt $ncpus ] ; do =A0 =A0while : ; do : ; done & =A0 =A0: $(( i +=3D 1 )) done 2. Execute sysctl machdep.hlt_logical_cpus=3D1 . 3. Look at cpuset info; example: Before: # for i in `ps aux | grep gcooper | grep -v grep | awk '{ print $2 }'` ; do cpuset -g -p $i ; done pid 2179 mask: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 pid 2180 mask: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 After: # for i in `ps aux | grep gcooper | grep -v grep | awk '{ print $2 }'` ; do cpuset -g -p $i ; done pid 2179 mask: 0, 2, 4, 6, 8, 10, 12, 14 pid 2180 mask: 0, 2, 4, 6, 8, 10, 12, 14 # sysctl machdep.hlt_logical_cpus=3D0 machdep.hlt_logical_cpus: 1 -> 0 # for i in `ps aux | grep gcooper | grep -v grep | awk '{ print $2 }'` ; do cpuset -g -p $i ; done pid 2179 mask: 0, 2, 4, 6, 8, 10, 12, 14 pid 2180 mask: 0, 2, 4, 6, 8, 10, 12, 14 I'm taking the patch and running with it now to try and get it working 10= 0%. This output was from a patch in progress based on Andriy's work, that seems to get the bits in place properly: test-26# sysctl machdep.hlt_logical_cpus=3D1 sysctl_hlt_logical_cpus: mask: 43690 cpuset_zero_modify (before): cpuset_zero: 65535, mask: 21845 cpuset_update (after): set: 21845, mask: 21845 cpuset_update (after): set: 21845, mask: 21845 cpuset_zero_modify (after): cpuset_zero: 21845, mask: 21845 machdep.hlt_logical_cpus: 0 -> 1 test-26# sysctl machdep.hlt_logical_cpus=3D0 sysctl_hlt_logical_cpus: mask: 0 cpuset_zero_modify (before): cpuset_zero: 21845, mask: 65535 cpuset_update (after): set: 21845, mask: 65535 cpuset_update (after): set: 21845, mask: 21845 cpuset_zero_modify (after): cpuset_zero: 65535, mask: 65535 machdep.hlt_logical_cpus: 1 -> 0 test-26# Weird thing is that the CPU affinity isn't adjusted even though cpuset_zero appears to be modified. I think this is the problem: static int cpuset_testupdate(struct cpuset *set, cpuset_t *mask) { struct cpuset *nset; cpuset_t newmask; int error; mtx_assert(&cpuset_lock, MA_OWNED); if (set->cs_flags & CPU_SET_RDONLY) return (EPERM); if (!CPU_OVERLAP(&set->cs_mask, mask)) return (EDEADLK); CPU_COPY(&set->cs_mask, &newmask); CPU_AND(&newmask, mask); error =3D 0; LIST_FOREACH(nset, &set->cs_children, cs_siblings) if ((error =3D cpuset_testupdate(nset, &newmask)) !=3D 0) break; return (error); } ... /* * Applies the mask 'mask' without checking for empty sets or permissions. */ static void cpuset_update(struct cpuset *set, cpuset_t *mask) { struct cpuset *nset; mtx_assert(&cpuset_lock, MA_OWNED); CPU_AND(&set->cs_mask, mask); LIST_FOREACH(nset, &set->cs_children, cs_siblings) cpuset_update(nset, &set->cs_mask); return; } Note that it's doing CPU_AND, not CPU_OR, in both routines that get called from cpuset_modify. This makes sense to reject bad input (because scheduling on non-existent CPUs is a bad thing :/), but sucks in our case because it means that we can't use cpuset_modify [easily]... Thanks! -Garrett --0016e6567d28366ef604955f1e9a Content-Type: text/x-patch; charset=US-ASCII; name="kern.145385.patch" Content-Disposition: attachment; filename="kern.145385.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ggohebzt1 SW5kZXg6IHN5cy9hbWQ2NC9hbWQ2NC9tcF9tYWNoZGVwLmMKPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2Ft ZDY0L2FtZDY0L21wX21hY2hkZXAuYwkocmV2aXNpb24gMjE1NDE3KQorKysgc3lzL2FtZDY0L2Ft ZDY0L21wX21hY2hkZXAuYwkod29ya2luZyBjb3B5KQpAQCAtMzksNiArMzksNyBAQAogI2lmZGVm IEdQUk9GIAogI2luY2x1ZGUgPHN5cy9nbW9uLmg+CiAjZW5kaWYKKyNpbmNsdWRlIDxzeXMvY3B1 c2V0Lmg+CiAjaW5jbHVkZSA8c3lzL2tlcm5lbC5oPgogI2luY2x1ZGUgPHN5cy9rdHIuaD4KICNp bmNsdWRlIDxzeXMvbG9jay5oPgpAQCAtODUsNyArODYsNyBAQAogaW50CW1wX25hcHM7CQkvKiAj IG9mIEFwcGxpY2F0aW9ucyBwcm9jZXNzb3JzICovCiBpbnQJYm9vdF9jcHVfaWQgPSAtMTsJLyog ZGVzaWduYXRlZCBCU1AgKi8KIAotZXh0ZXJuICBzdHJ1Y3QgcGNwdSBfX3BjcHVbXTsKK2V4dGVy bglzdHJ1Y3QgcGNwdSBfX3BjcHVbXTsKIAogLyogQVAgdXNlcyB0aGlzIGR1cmluZyBib290c3Ry YXAuICBEbyBub3Qgc3RhdGljaXplLiAgKi8KIGNoYXIgKmJvb3RTVEs7CkBAIC0xMTQ1LDcgKzEx NDYsNyBAQAogCQkJb2xkX3BlbmRpbmcgPSBjcHVfaXBpX3BlbmRpbmdbY3B1XTsKIAkJCW5ld19w ZW5kaW5nID0gb2xkX3BlbmRpbmcgfCBiaXRtYXA7CiAJCX0gd2hpbGUgICghYXRvbWljX2NtcHNl dF9pbnQoJmNwdV9pcGlfcGVuZGluZ1tjcHVdLAotCQkgICAgb2xkX3BlbmRpbmcsIG5ld19wZW5k aW5nKSk7IAorCQkgICAgb2xkX3BlbmRpbmcsIG5ld19wZW5kaW5nKSk7CiAJCWlmIChvbGRfcGVu ZGluZykKIAkJCXJldHVybjsKIAl9CkBAIC0xMzMzLDcgKzEzMzQsNiBAQAogCSAqLwogCWlmIChp cGkgPT0gSVBJX1NUT1BfSEFSRCkKIAkJYXRvbWljX3NldF9pbnQoJmlwaV9ubWlfcGVuZGluZywg UENQVV9HRVQob3RoZXJfY3B1cykpOwotCiAJQ1RSMihLVFJfU01QLCAiJXM6IGlwaTogJXgiLCBf X2Z1bmNfXywgaXBpKTsKIAlsYXBpY19pcGlfdmVjdG9yZWQoaXBpLCBBUElDX0lQSV9ERVNUX09U SEVSUyk7CiB9CkBAIC0xMzU3LDcgKzEzNTcsNyBAQAogCWNwdXN0b3BfaGFuZGxlcigpOwogCXJl dHVybiAoMCk7CiB9Ci0gICAgIAorCiAvKgogICogSGFuZGxlIGFuIElQSV9TVE9QIGJ5IHNhdmlu ZyBvdXIgY3VycmVudCBjb250ZXh0IGFuZCBzcGlubmluZyB1bnRpbCB3ZQogICogYXJlIHJlc3Vt ZWQuCkBAIC0xNDQ3LDYgKzE0NDcsNyBAQAogc3RhdGljIGludAogc3lzY3RsX2hsdF9jcHVzKFNZ U0NUTF9IQU5ETEVSX0FSR1MpCiB7CisJY3B1c2V0X3QgbWFza19zZXQ7CiAJY3B1bWFza190IG1h c2s7CiAJaW50IGVycm9yOwogCkBAIC0xNDU1LDE4ICsxNDU2LDIwIEBACiAJaWYgKGVycm9yIHx8 ICFyZXEtPm5ld3B0cikKIAkJcmV0dXJuIChlcnJvcik7CiAKLQlpZiAobG9naWNhbF9jcHVzX21h c2sgIT0gMCAmJgotCSAgICAobWFzayAmIGxvZ2ljYWxfY3B1c19tYXNrKSA9PSBsb2dpY2FsX2Nw dXNfbWFzaykKLQkJaGx0X2xvZ2ljYWxfY3B1cyA9IDE7Ci0JZWxzZQotCQlobHRfbG9naWNhbF9j cHVzID0gMDsKLQotCWlmICghIGh5cGVydGhyZWFkaW5nX2FsbG93ZWQpCisJaWYgKGhsdF9sb2dp Y2FsX2NwdXMpCisJCW1hc2sgfD0gbG9naWNhbF9jcHVzX21hc2s7CisJaWYgKCFoeXBlcnRocmVh ZGluZ19hbGxvd2VkKQogCQltYXNrIHw9IGh5cGVydGhyZWFkaW5nX2NwdXNfbWFzazsKIAorCS8q IERvbid0IGRpc2FibGUgQlNQMCAqLwogCWlmICgobWFzayAmIGFsbF9jcHVzKSA9PSBhbGxfY3B1 cykKIAkJbWFzayAmPSB+KDE8PDApOwotCWhsdF9jcHVzX21hc2sgPSBtYXNrOworCisJQ1BVX1pF Uk8oJm1hc2tfc2V0KTsKKwlDUFVfU0VUTUFTSyh+bWFzayAmIGFsbF9jcHVzLCAmbWFza19zZXQp OworCWVycm9yID0gY3B1c2V0X3plcm9fbW9kaWZ5KCZtYXNrX3NldCk7CisJaWYgKGVycm9yID09 IDApCisJCWhsdF9jcHVzX21hc2sgPSBtYXNrOwogCXJldHVybiAoZXJyb3IpOwogfQogU1lTQ1RM X1BST0MoX21hY2hkZXAsIE9JRF9BVVRPLCBobHRfY3B1cywgQ1RMVFlQRV9JTlR8Q1RMRkxBR19S VywKQEAgLTE0NzYsNiArMTQ3OSw4IEBACiBzdGF0aWMgaW50CiBzeXNjdGxfaGx0X2xvZ2ljYWxf Y3B1cyhTWVNDVExfSEFORExFUl9BUkdTKQogeworCWNwdXNldF90IG1hc2tfc2V0OworCWNwdW1h c2tfdCBtYXNrOwogCWludCBkaXNhYmxlLCBlcnJvcjsKIAogCWRpc2FibGUgPSBobHRfbG9naWNh bF9jcHVzOwpAQCAtMTQ4MywyNCArMTQ4OCwzMSBAQAogCWlmIChlcnJvciB8fCAhcmVxLT5uZXdw dHIpCiAJCXJldHVybiAoZXJyb3IpOwogCisJbWFzayA9IGhsdF9jcHVzX21hc2s7CiAJaWYgKGRp c2FibGUpCi0JCWhsdF9jcHVzX21hc2sgfD0gbG9naWNhbF9jcHVzX21hc2s7Ci0JZWxzZQotCQlo bHRfY3B1c19tYXNrICY9IH5sb2dpY2FsX2NwdXNfbWFzazsKKwkJbWFzayB8PSBsb2dpY2FsX2Nw dXNfbWFzazsKKwlpZiAoIWh5cGVydGhyZWFkaW5nX2FsbG93ZWQpCisJCW1hc2sgfD0gaHlwZXJ0 aHJlYWRpbmdfY3B1c19tYXNrOwogCi0JaWYgKCEgaHlwZXJ0aHJlYWRpbmdfYWxsb3dlZCkKLQkJ aGx0X2NwdXNfbWFzayB8PSBoeXBlcnRocmVhZGluZ19jcHVzX21hc2s7CisJLyogRG9uJ3QgZGlz YWJsZSBCU1AwICovCisJaWYgKChtYXNrICYgYWxsX2NwdXMpID09IGFsbF9jcHVzKQorCQltYXNr ICY9IH4oMTw8MCk7CiAKLQlpZiAoKGhsdF9jcHVzX21hc2sgJiBhbGxfY3B1cykgPT0gYWxsX2Nw dXMpCi0JCWhsdF9jcHVzX21hc2sgJj0gfigxPDwwKTsKKwlwcmludGYoIiVzOiBtYXNrOiAlZFxu IiwgX19mdW5jX18sIG1hc2spOwogCi0JaGx0X2xvZ2ljYWxfY3B1cyA9IGRpc2FibGU7CisJQ1BV X1pFUk8oJm1hc2tfc2V0KTsKKwlDUFVfU0VUTUFTSyh+bWFzayAmIGFsbF9jcHVzLCAmbWFza19z ZXQpOworCWVycm9yID0gY3B1c2V0X3plcm9fbW9kaWZ5KCZtYXNrX3NldCk7CisJaWYgKGVycm9y ID09IDApIAorCQlobHRfbG9naWNhbF9jcHVzID0gZGlzYWJsZTsKIAlyZXR1cm4gKGVycm9yKTsK IH0KIAogc3RhdGljIGludAogc3lzY3RsX2h5cGVydGhyZWFkaW5nX2FsbG93ZWQoU1lTQ1RMX0hB TkRMRVJfQVJHUykKIHsKKwljcHVzZXRfdCBtYXNrX3NldDsKKwljcHVtYXNrX3QgbWFzazsKIAlp bnQgYWxsb3dlZCwgZXJyb3I7CiAKIAlhbGxvd2VkID0gaHlwZXJ0aHJlYWRpbmdfYWxsb3dlZDsK QEAgLTE1MDgsNDIgKzE1MjAsNDUgQEAKIAlpZiAoZXJyb3IgfHwgIXJlcS0+bmV3cHRyKQogCQly ZXR1cm4gKGVycm9yKTsKIAotI2lmZGVmIFNDSEVEX1VMRQotCS8qCi0JICogU0NIRURfVUxFIGRv ZXNuJ3QgYWxsb3cgZW5hYmxpbmcvZGlzYWJsaW5nIEhUIGNvcmVzIGF0Ci0JICogcnVuLXRpbWUu Ci0JICovCi0JaWYgKGFsbG93ZWQgIT0gaHlwZXJ0aHJlYWRpbmdfYWxsb3dlZCkKLQkJcmV0dXJu IChFTk9UU1VQKTsKLQlyZXR1cm4gKGVycm9yKTsKLSNlbmRpZgorCW1hc2sgPSBobHRfY3B1c19t YXNrOworCWlmIChobHRfbG9naWNhbF9jcHVzKQorCQltYXNrIHw9IGxvZ2ljYWxfY3B1c19tYXNr OworCWlmICghYWxsb3dlZCkKKwkJbWFzayB8PSBoeXBlcnRocmVhZGluZ19jcHVzX21hc2s7CiAK LQlpZiAoYWxsb3dlZCkKLQkJaGx0X2NwdXNfbWFzayAmPSB+aHlwZXJ0aHJlYWRpbmdfY3B1c19t YXNrOwotCWVsc2UKLQkJaGx0X2NwdXNfbWFzayB8PSBoeXBlcnRocmVhZGluZ19jcHVzX21hc2s7 CisJLyogRG9uJ3QgZGlzYWJsZSBCU1AwICovCisJaWYgKChtYXNrICYgYWxsX2NwdXMpID09IGFs bF9jcHVzKQorCQltYXNrICY9IH4oMTw8MCk7CiAKLQlpZiAobG9naWNhbF9jcHVzX21hc2sgIT0g MCAmJgotCSAgICAoaGx0X2NwdXNfbWFzayAmIGxvZ2ljYWxfY3B1c19tYXNrKSA9PSBsb2dpY2Fs X2NwdXNfbWFzaykKLQkJaGx0X2xvZ2ljYWxfY3B1cyA9IDE7Ci0JZWxzZQotCQlobHRfbG9naWNh bF9jcHVzID0gMDsKLQotCWlmICgoaGx0X2NwdXNfbWFzayAmIGFsbF9jcHVzKSA9PSBhbGxfY3B1 cykKLQkJaGx0X2NwdXNfbWFzayAmPSB+KDE8PDApOwotCi0JaHlwZXJ0aHJlYWRpbmdfYWxsb3dl ZCA9IGFsbG93ZWQ7CisJQ1BVX1pFUk8oJm1hc2tfc2V0KTsKKwlDUFVfU0VUTUFTSyh+bWFzayAm IGFsbF9jcHVzLCAmbWFza19zZXQpOworCWVycm9yID0gY3B1c2V0X3plcm9fbW9kaWZ5KCZtYXNr X3NldCk7CisJaWYgKGVycm9yID09IDApIAorCQloeXBlcnRocmVhZGluZ19hbGxvd2VkID0gYWxs b3dlZDsKIAlyZXR1cm4gKGVycm9yKTsKIH0KIAogc3RhdGljIHZvaWQKIGNwdV9obHRfc2V0dXAo dm9pZCAqZHVtbXkgX191bnVzZWQpCiB7CisJY3B1c2V0X3QgbWFza19zZXQ7CiAKIAlpZiAobG9n aWNhbF9jcHVzX21hc2sgIT0gMCkgewogCQlUVU5BQkxFX0lOVF9GRVRDSCgibWFjaGRlcC5obHRf bG9naWNhbF9jcHVzIiwKIAkJICAgICZobHRfbG9naWNhbF9jcHVzKTsKKwkJaWYgKGhsdF9sb2dp Y2FsX2NwdXMgIT0gMCkgeworCQkJQ1BVX1pFUk8oJm1hc2tfc2V0KTsKKwkJCUNQVV9TRVRNQVNL KH5sb2dpY2FsX2NwdXNfbWFzayAmIGFsbF9jcHVzLCAmbWFza19zZXQpOworCQkJaWYgKGNwdXNl dF96ZXJvX21vZGlmeSgmbWFza19zZXQpID09IDApCisJCQkJaGx0X2xvZ2ljYWxfY3B1cyA9IDE7 CisJCQllbHNlCisJCQkJaGx0X2xvZ2ljYWxfY3B1cyA9IDA7CisJCX0KIAkJc3lzY3RsX2N0eF9p bml0KCZsb2dpY2FsX2NwdV9jbGlzdCk7CisJCVNZU0NUTF9BRERfVUlOVCgmbG9naWNhbF9jcHVf Y2xpc3QsCisJCSAgICBTWVNDVExfU1RBVElDX0NISUxEUkVOKF9tYWNoZGVwKSwgT0lEX0FVVE8s CisJCSAgICAiYWxsX2NwdXNfbWFzayIsIENUTFRZUEVfSU5UfENUTEZMQUdfUkQsCisJCSAgICAm YWxsX2NwdXMsIDAsICIiKTsKIAkJU1lTQ1RMX0FERF9QUk9DKCZsb2dpY2FsX2NwdV9jbGlzdCwK IAkJICAgIFNZU0NUTF9TVEFUSUNfQ0hJTERSRU4oX21hY2hkZXApLCBPSURfQVVUTywKIAkJICAg ICJobHRfbG9naWNhbF9jcHVzIiwgQ1RMVFlQRV9JTlR8Q1RMRkxBR19SVywgMCwgMCwKQEAgLTE1 NTMsOSArMTU2OCw2IEBACiAJCSAgICAibG9naWNhbF9jcHVzX21hc2siLCBDVExUWVBFX0lOVHxD VExGTEFHX1JELAogCQkgICAgJmxvZ2ljYWxfY3B1c19tYXNrLCAwLCAiIik7CiAKLQkJaWYgKGhs dF9sb2dpY2FsX2NwdXMpCi0JCQlobHRfY3B1c19tYXNrIHw9IGxvZ2ljYWxfY3B1c19tYXNrOwot CiAJCS8qCiAJCSAqIElmIG5lY2Vzc2FyeSBmb3Igc2VjdXJpdHkgcHVycG9zZXMsIGZvcmNlCiAJ CSAqIGh5cGVydGhyZWFkaW5nIG9mZiwgcmVnYXJkbGVzcyBvZiB0aGUgdmFsdWUKQEAgLTE1NjYs OCArMTU3OCw2IEBACiAJCQkgICAgU1lTQ1RMX1NUQVRJQ19DSElMRFJFTihfbWFjaGRlcCksIE9J RF9BVVRPLAogCQkJICAgICJoeXBlcnRocmVhZGluZ19hbGxvd2VkIiwgQ1RMVFlQRV9JTlR8Q1RM RkxBR19SVywKIAkJCSAgICAwLCAwLCBzeXNjdGxfaHlwZXJ0aHJlYWRpbmdfYWxsb3dlZCwgIklV IiwgIiIpOwotCQkJaWYgKCEgaHlwZXJ0aHJlYWRpbmdfYWxsb3dlZCkKLQkJCQlobHRfY3B1c19t YXNrIHw9IGh5cGVydGhyZWFkaW5nX2NwdXNfbWFzazsKIAkJfQogCX0KIH0KQEAgLTE2MjcsNCAr MTYzNywzIEBACiB9CiBTWVNJTklUKG1wX2lwaV9pbnRyY250LCBTSV9TVUJfSU5UUiwgU0lfT1JE RVJfTUlERExFLCBtcF9pcGlfaW50cmNudCwgTlVMTCk7CiAjZW5kaWYKLQpJbmRleDogc3lzL2kz ODYvaTM4Ni9tcF9tYWNoZGVwLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2kzODYvaTM4Ni9tcF9tYWNo ZGVwLmMJKHJldmlzaW9uIDIxNTQxNykKKysrIHN5cy9pMzg2L2kzODYvbXBfbWFjaGRlcC5jCSh3 b3JraW5nIGNvcHkpCkBAIC01NCw2ICs1NCw3IEBACiAjaWZkZWYgR1BST0YgCiAjaW5jbHVkZSA8 c3lzL2dtb24uaD4KICNlbmRpZgorI2luY2x1ZGUgPHN5cy9jcHVzZXQuaD4KICNpbmNsdWRlIDxz eXMva2VybmVsLmg+CiAjaW5jbHVkZSA8c3lzL2t0ci5oPgogI2luY2x1ZGUgPHN5cy9sb2NrLmg+ CkBAIC0xMTk3LDcgKzExOTgsNyBAQAogCWludCBuY3B1LCBvdGhlcmNwdXM7CiAKIAlvdGhlcmNw dXMgPSBtcF9uY3B1cyAtIDE7Ci0JaWYgKG1hc2sgPT0gKHVfaW50KS0xKSB7CisJaWYgKG1hc2sg PT0gKGNwdW1hc2tfdCktMSkgewogCQluY3B1ID0gb3RoZXJjcHVzOwogCQlpZiAobmNwdSA8IDEp CiAJCQlyZXR1cm47CkBAIC0xMjIyLDcgKzEyMjMsNyBAQAogCXNtcF90bGJfYWRkcjEgPSBhZGRy MTsKIAlzbXBfdGxiX2FkZHIyID0gYWRkcjI7CiAJYXRvbWljX3N0b3JlX3JlbF9pbnQoJnNtcF90 bGJfd2FpdCwgMCk7Ci0JaWYgKG1hc2sgPT0gKHVfaW50KS0xKQorCWlmIChtYXNrID09IChjcHVt YXNrX3QpLTEpCiAJCWlwaV9hbGxfYnV0X3NlbGYodmVjdG9yKTsKIAllbHNlCiAJCWlwaV9zZWxl Y3RlZChtYXNrLCB2ZWN0b3IpOwpAQCAtMTI0OCw3ICsxMjQ5LDcgQEAKIAkJCW9sZF9wZW5kaW5n ID0gY3B1X2lwaV9wZW5kaW5nW2NwdV07CiAJCQluZXdfcGVuZGluZyA9IG9sZF9wZW5kaW5nIHwg Yml0bWFwOwogCQl9IHdoaWxlICAoIWF0b21pY19jbXBzZXRfaW50KCZjcHVfaXBpX3BlbmRpbmdb Y3B1XSwKLQkJICAgIG9sZF9wZW5kaW5nLCBuZXdfcGVuZGluZykpOwkKKwkJICAgIG9sZF9wZW5k aW5nLCBuZXdfcGVuZGluZykpOwogCQlpZiAob2xkX3BlbmRpbmcpCiAJCQlyZXR1cm47CiAJfQpA QCAtMTUxMCw2ICsxNTExLDcgQEAKIHN0YXRpYyBpbnQKIHN5c2N0bF9obHRfY3B1cyhTWVNDVExf SEFORExFUl9BUkdTKQogeworCWNwdXNldF90IG1hc2tfc2V0OwogCWNwdW1hc2tfdCBtYXNrOwog CWludCBlcnJvcjsKIApAQCAtMTUxOCwxOCArMTUyMCwyMCBAQAogCWlmIChlcnJvciB8fCAhcmVx LT5uZXdwdHIpCiAJCXJldHVybiAoZXJyb3IpOwogCi0JaWYgKGxvZ2ljYWxfY3B1c19tYXNrICE9 IDAgJiYKLQkgICAgKG1hc2sgJiBsb2dpY2FsX2NwdXNfbWFzaykgPT0gbG9naWNhbF9jcHVzX21h c2spCi0JCWhsdF9sb2dpY2FsX2NwdXMgPSAxOwotCWVsc2UKLQkJaGx0X2xvZ2ljYWxfY3B1cyA9 IDA7Ci0KLQlpZiAoISBoeXBlcnRocmVhZGluZ19hbGxvd2VkKQorCWlmIChobHRfbG9naWNhbF9j cHVzKQorCQltYXNrIHw9IGxvZ2ljYWxfY3B1c19tYXNrOworCWlmICghaHlwZXJ0aHJlYWRpbmdf YWxsb3dlZCkKIAkJbWFzayB8PSBoeXBlcnRocmVhZGluZ19jcHVzX21hc2s7CiAKKwkvKiBEb24n dCBkaXNhYmxlIEJTUDAgKi8KIAlpZiAoKG1hc2sgJiBhbGxfY3B1cykgPT0gYWxsX2NwdXMpCiAJ CW1hc2sgJj0gfigxPDwwKTsKLQlobHRfY3B1c19tYXNrID0gbWFzazsKKworCUNQVV9aRVJPKCZt YXNrX3NldCk7CisJQ1BVX1NFVE1BU0sofm1hc2sgJiBhbGxfY3B1cywgJm1hc2tfc2V0KTsKKwll cnJvciA9IGNwdXNldF96ZXJvX21vZGlmeSgmbWFza19zZXQpOworCWlmIChlcnJvciA9PSAwKQor CQlobHRfY3B1c19tYXNrID0gbWFzazsKIAlyZXR1cm4gKGVycm9yKTsKIH0KIFNZU0NUTF9QUk9D KF9tYWNoZGVwLCBPSURfQVVUTywgaGx0X2NwdXMsIENUTFRZUEVfSU5UfENUTEZMQUdfUlcsCkBA IC0xNTM5LDYgKzE1NDMsOCBAQAogc3RhdGljIGludAogc3lzY3RsX2hsdF9sb2dpY2FsX2NwdXMo U1lTQ1RMX0hBTkRMRVJfQVJHUykKIHsKKwljcHVzZXRfdCBtYXNrX3NldDsKKwljcHVtYXNrX3Qg bWFzazsKIAlpbnQgZGlzYWJsZSwgZXJyb3I7CiAKIAlkaXNhYmxlID0gaGx0X2xvZ2ljYWxfY3B1 czsKQEAgLTE1NDYsMjQgKzE1NTIsMzEgQEAKIAlpZiAoZXJyb3IgfHwgIXJlcS0+bmV3cHRyKQog CQlyZXR1cm4gKGVycm9yKTsKIAorCW1hc2sgPSBobHRfY3B1c19tYXNrOwogCWlmIChkaXNhYmxl KQotCQlobHRfY3B1c19tYXNrIHw9IGxvZ2ljYWxfY3B1c19tYXNrOwotCWVsc2UKLQkJaGx0X2Nw dXNfbWFzayAmPSB+bG9naWNhbF9jcHVzX21hc2s7CisJCW1hc2sgfD0gbG9naWNhbF9jcHVzX21h c2s7CisJaWYgKCFoeXBlcnRocmVhZGluZ19hbGxvd2VkKQorCQltYXNrIHw9IGh5cGVydGhyZWFk aW5nX2NwdXNfbWFzazsKIAotCWlmICghIGh5cGVydGhyZWFkaW5nX2FsbG93ZWQpCi0JCWhsdF9j cHVzX21hc2sgfD0gaHlwZXJ0aHJlYWRpbmdfY3B1c19tYXNrOworCS8qIERvbid0IGRpc2FibGUg QlNQMCAqLworCWlmICgobWFzayAmIGFsbF9jcHVzKSA9PSBhbGxfY3B1cykKKwkJbWFzayAmPSB+ KDE8PDApOwogCi0JaWYgKChobHRfY3B1c19tYXNrICYgYWxsX2NwdXMpID09IGFsbF9jcHVzKQot CQlobHRfY3B1c19tYXNrICY9IH4oMTw8MCk7CisJcHJpbnRmKCIlczogbWFzazogJWRcbiIsIF9f ZnVuY19fLCBtYXNrKTsKIAotCWhsdF9sb2dpY2FsX2NwdXMgPSBkaXNhYmxlOworCUNQVV9aRVJP KCZtYXNrX3NldCk7CisJQ1BVX1NFVE1BU0sofm1hc2sgJiBhbGxfY3B1cywgJm1hc2tfc2V0KTsK KwllcnJvciA9IGNwdXNldF96ZXJvX21vZGlmeSgmbWFza19zZXQpOworCWlmIChlcnJvciA9PSAw KSAKKwkJaGx0X2xvZ2ljYWxfY3B1cyA9IGRpc2FibGU7CiAJcmV0dXJuIChlcnJvcik7CiB9CiAK IHN0YXRpYyBpbnQKIHN5c2N0bF9oeXBlcnRocmVhZGluZ19hbGxvd2VkKFNZU0NUTF9IQU5ETEVS X0FSR1MpCiB7CisJY3B1c2V0X3QgbWFza19zZXQ7CisJY3B1bWFza190IG1hc2s7CiAJaW50IGFs bG93ZWQsIGVycm9yOwogCiAJYWxsb3dlZCA9IGh5cGVydGhyZWFkaW5nX2FsbG93ZWQ7CkBAIC0x NTcxLDQyICsxNTg0LDQ1IEBACiAJaWYgKGVycm9yIHx8ICFyZXEtPm5ld3B0cikKIAkJcmV0dXJu IChlcnJvcik7CiAKLSNpZmRlZiBTQ0hFRF9VTEUKLQkvKgotCSAqIFNDSEVEX1VMRSBkb2Vzbid0 IGFsbG93IGVuYWJsaW5nL2Rpc2FibGluZyBIVCBjb3JlcyBhdAotCSAqIHJ1bi10aW1lLgotCSAq LwotCWlmIChhbGxvd2VkICE9IGh5cGVydGhyZWFkaW5nX2FsbG93ZWQpCi0JCXJldHVybiAoRU5P VFNVUCk7Ci0JcmV0dXJuIChlcnJvcik7Ci0jZW5kaWYKKwltYXNrID0gaGx0X2NwdXNfbWFzazsK KwlpZiAoaGx0X2xvZ2ljYWxfY3B1cykKKwkJbWFzayB8PSBsb2dpY2FsX2NwdXNfbWFzazsKKwlp ZiAoIWFsbG93ZWQpCisJCW1hc2sgfD0gaHlwZXJ0aHJlYWRpbmdfY3B1c19tYXNrOwogCi0JaWYg KGFsbG93ZWQpCi0JCWhsdF9jcHVzX21hc2sgJj0gfmh5cGVydGhyZWFkaW5nX2NwdXNfbWFzazsK LQllbHNlCi0JCWhsdF9jcHVzX21hc2sgfD0gaHlwZXJ0aHJlYWRpbmdfY3B1c19tYXNrOworCS8q IERvbid0IGRpc2FibGUgQlNQMCAqLworCWlmICgobWFzayAmIGFsbF9jcHVzKSA9PSBhbGxfY3B1 cykKKwkJbWFzayAmPSB+KDE8PDApOwogCi0JaWYgKGxvZ2ljYWxfY3B1c19tYXNrICE9IDAgJiYK LQkgICAgKGhsdF9jcHVzX21hc2sgJiBsb2dpY2FsX2NwdXNfbWFzaykgPT0gbG9naWNhbF9jcHVz X21hc2spCi0JCWhsdF9sb2dpY2FsX2NwdXMgPSAxOwotCWVsc2UKLQkJaGx0X2xvZ2ljYWxfY3B1 cyA9IDA7Ci0KLQlpZiAoKGhsdF9jcHVzX21hc2sgJiBhbGxfY3B1cykgPT0gYWxsX2NwdXMpCi0J CWhsdF9jcHVzX21hc2sgJj0gfigxPDwwKTsKLQotCWh5cGVydGhyZWFkaW5nX2FsbG93ZWQgPSBh bGxvd2VkOworCUNQVV9aRVJPKCZtYXNrX3NldCk7CisJQ1BVX1NFVE1BU0sofm1hc2sgJiBhbGxf Y3B1cywgJm1hc2tfc2V0KTsKKwllcnJvciA9IGNwdXNldF96ZXJvX21vZGlmeSgmbWFza19zZXQp OworCWlmIChlcnJvciA9PSAwKSAKKwkJaHlwZXJ0aHJlYWRpbmdfYWxsb3dlZCA9IGFsbG93ZWQ7 CiAJcmV0dXJuIChlcnJvcik7CiB9CiAKIHN0YXRpYyB2b2lkCiBjcHVfaGx0X3NldHVwKHZvaWQg KmR1bW15IF9fdW51c2VkKQogeworCWNwdXNldF90IG1hc2tfc2V0OwogCiAJaWYgKGxvZ2ljYWxf Y3B1c19tYXNrICE9IDApIHsKIAkJVFVOQUJMRV9JTlRfRkVUQ0goIm1hY2hkZXAuaGx0X2xvZ2lj YWxfY3B1cyIsCiAJCSAgICAmaGx0X2xvZ2ljYWxfY3B1cyk7CisJCWlmIChobHRfbG9naWNhbF9j cHVzICE9IDApIHsKKwkJCUNQVV9aRVJPKCZtYXNrX3NldCk7CisJCQlDUFVfU0VUTUFTSyh+bG9n aWNhbF9jcHVzX21hc2sgJiBhbGxfY3B1cywgJm1hc2tfc2V0KTsKKwkJCWlmIChjcHVzZXRfemVy b19tb2RpZnkoJm1hc2tfc2V0KSA9PSAwKQorCQkJCWhsdF9sb2dpY2FsX2NwdXMgPSAxOworCQkJ ZWxzZQorCQkJCWhsdF9sb2dpY2FsX2NwdXMgPSAwOworCQl9CiAJCXN5c2N0bF9jdHhfaW5pdCgm bG9naWNhbF9jcHVfY2xpc3QpOworCQlTWVNDVExfQUREX1VJTlQoJmxvZ2ljYWxfY3B1X2NsaXN0 LAorCQkgICAgU1lTQ1RMX1NUQVRJQ19DSElMRFJFTihfbWFjaGRlcCksIE9JRF9BVVRPLAorCQkg ICAgImFsbF9jcHVzX21hc2siLCBDVExUWVBFX0lOVHxDVExGTEFHX1JELAorCQkgICAgJmFsbF9j cHVzLCAwLCAiIik7CiAJCVNZU0NUTF9BRERfUFJPQygmbG9naWNhbF9jcHVfY2xpc3QsCiAJCSAg ICBTWVNDVExfU1RBVElDX0NISUxEUkVOKF9tYWNoZGVwKSwgT0lEX0FVVE8sCiAJCSAgICAiaGx0 X2xvZ2ljYWxfY3B1cyIsIENUTFRZUEVfSU5UfENUTEZMQUdfUlcsIDAsIDAsCkBAIC0xNjE2LDkg KzE2MzIsNiBAQAogCQkgICAgImxvZ2ljYWxfY3B1c19tYXNrIiwgQ1RMVFlQRV9JTlR8Q1RMRkxB R19SRCwKIAkJICAgICZsb2dpY2FsX2NwdXNfbWFzaywgMCwgIiIpOwogCi0JCWlmIChobHRfbG9n aWNhbF9jcHVzKQotCQkJaGx0X2NwdXNfbWFzayB8PSBsb2dpY2FsX2NwdXNfbWFzazsKLQogCQkv KgogCQkgKiBJZiBuZWNlc3NhcnkgZm9yIHNlY3VyaXR5IHB1cnBvc2VzLCBmb3JjZQogCQkgKiBo eXBlcnRocmVhZGluZyBvZmYsIHJlZ2FyZGxlc3Mgb2YgdGhlIHZhbHVlCkBAIC0xNjI5LDggKzE2 NDIsNiBAQAogCQkJICAgIFNZU0NUTF9TVEFUSUNfQ0hJTERSRU4oX21hY2hkZXApLCBPSURfQVVU TywKIAkJCSAgICAiaHlwZXJ0aHJlYWRpbmdfYWxsb3dlZCIsIENUTFRZUEVfSU5UfENUTEZMQUdf UlcsCiAJCQkgICAgMCwgMCwgc3lzY3RsX2h5cGVydGhyZWFkaW5nX2FsbG93ZWQsICJJVSIsICIi KTsKLQkJCWlmICghIGh5cGVydGhyZWFkaW5nX2FsbG93ZWQpCi0JCQkJaGx0X2NwdXNfbWFzayB8 PSBoeXBlcnRocmVhZGluZ19jcHVzX21hc2s7CiAJCX0KIAl9CiB9CkBAIC0xNjg2LDcgKzE2OTcs NyBAQAogCQlpbnRyY250X2FkZChidWYsICZpcGlfbGF6eXBtYXBfY291bnRzW2ldKTsKIAkJc25w cmludGYoYnVmLCBzaXplb2YoYnVmKSwgImNwdSVkOmhhcmRjbG9jayIsIGkpOwogCQlpbnRyY250 X2FkZChidWYsICZpcGlfaGFyZGNsb2NrX2NvdW50c1tpXSk7Ci0JfQkJCisJfQogfQogU1lTSU5J VChtcF9pcGlfaW50cmNudCwgU0lfU1VCX0lOVFIsIFNJX09SREVSX01JRERMRSwgbXBfaXBpX2lu dHJjbnQsIE5VTEwpOwogI2VuZGlmCkluZGV4OiBzeXMva2Vybi9rZXJuX2NwdXNldC5jCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0KLS0tIHN5cy9rZXJuL2tlcm5fY3B1c2V0LmMJKHJldmlzaW9uIDIxNTQxNykKKysrIHN5 cy9rZXJuL2tlcm5fY3B1c2V0LmMJKHdvcmtpbmcgY29weSkKQEAgLTMzMiw2ICszMzIsMTAgQEAK IAogCW10eF9hc3NlcnQoJmNwdXNldF9sb2NrLCBNQV9PV05FRCk7CiAJQ1BVX0FORCgmc2V0LT5j c19tYXNrLCBtYXNrKTsKKyNpZiAxCisJcHJpbnRmKCIlcyAoYWZ0ZXIpOiBzZXQ6ICVsZCwgbWFz azogJWxkXG4iLCBfX2Z1bmNfXywKKwkgICAgc2V0LT5jc19tYXNrLl9fYml0c1swXSwgbWFzay0+ X19iaXRzWzBdKTsKKyNlbmRpZgogCUxJU1RfRk9SRUFDSChuc2V0LCAmc2V0LT5jc19jaGlsZHJl biwgY3Nfc2libGluZ3MpIAogCQljcHVzZXRfdXBkYXRlKG5zZXQsICZzZXQtPmNzX21hc2spOwog CkBAIC03NjQsOCArNzY4LDI5IEBACiAJCXBhbmljKCJDYW4ndCBzZXQgaW5pdGlhbCBjcHVzZXQg bWFzay5cbiIpOwogCWNwdXNldF96ZXJvLT5jc19mbGFncyB8PSBDUFVfU0VUX1JET05MWTsKIH0K LVNZU0lOSVQoY3B1c2V0LCBTSV9TVUJfU01QLCBTSV9PUkRFUl9BTlksIGNwdXNldF9pbml0LCBO VUxMKTsKK1NZU0lOSVQoY3B1c2V0LCBTSV9TVUJfU01QLCBTSV9PUkRFUl9NSURETEUsIGNwdXNl dF9pbml0LCBOVUxMKTsKIAoraW50CitjcHVzZXRfemVyb19tb2RpZnkoY3B1c2V0X3QgKm1hc2sp Cit7CisJaW50IGVycjsKKworCW10eF9sb2NrX3NwaW4oJmNwdXNldF9sb2NrKTsKKwljcHVzZXRf emVyby0+Y3NfZmxhZ3MgJj0gfkNQVV9TRVRfUkRPTkxZOworI2lmIDEKKwlwcmludGYoIiVzIChi ZWZvcmUpOiBjcHVzZXRfemVybzogJWxkLCBtYXNrOiAlbGRcbiIsIF9fZnVuY19fLAorCSAgICBj cHVzZXRfemVyby0+Y3NfbWFzay5fX2JpdHNbMF0sIG1hc2stPl9fYml0c1swXSk7CisjZW5kaWYK KwllcnIgPSBjcHVzZXRfbW9kaWZ5KGNwdXNldF96ZXJvLCBtYXNrKTsKKyNpZiAxCisJcHJpbnRm KCIlcyAoYWZ0ZXIpOiBjcHVzZXRfemVybzogJWxkLCBtYXNrOiAlbGRcbiIsIF9fZnVuY19fLAor CSAgICBjcHVzZXRfemVyby0+Y3NfbWFzay5fX2JpdHNbMF0sIG1hc2stPl9fYml0c1swXSk7Cisj ZW5kaWYKKwljcHVzZXRfemVyby0+Y3NfZmxhZ3MgfD0gQ1BVX1NFVF9SRE9OTFk7CisJbXR4X3Vu bG9ja19zcGluKCZjcHVzZXRfbG9jayk7CisJcmV0dXJuIChlcnIpOworfQorCiAjaWZuZGVmIF9T WVNfU1lTUFJPVE9fSF8KIHN0cnVjdCBjcHVzZXRfYXJncyB7CiAJY3B1c2V0aWRfdAkqc2V0aWQ7 CkluZGV4OiBzeXMvc3lzL2NwdXNldC5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9zeXMvY3B1c2V0LmgJ KHJldmlzaW9uIDIxNTQxNykKKysrIHN5cy9zeXMvY3B1c2V0LmgJKHdvcmtpbmcgY29weSkKQEAg LTU0LDYgKzU0LDcgQEAKICNkZWZpbmUJQ1BVX0NPUFkoZiwgdCkJKHZvaWQpKCoodCkgPSAqKGYp KQogI2RlZmluZQlDUFVfSVNTRVQobiwgcCkJKCgocCktPl9fYml0c1sobikvX05DUFVCSVRTXSAm IF9fY3B1c2V0X21hc2sobikpICE9IDApCiAjZGVmaW5lCUNQVV9TRVQobiwgcCkJKChwKS0+X19i aXRzWyhuKS9fTkNQVUJJVFNdIHw9IF9fY3B1c2V0X21hc2sobikpCisjZGVmaW5lCUNQVV9TRVRN QVNLKG1hc2ssIHApCSgocCktPl9fYml0c1swXSA9IChtYXNrKSkKICNkZWZpbmUJQ1BVX1pFUk8o cCkgZG8gewkJCQlcCiAJX19zaXplX3QgX19pOwkJCQkJXAogCWZvciAoX19pID0gMDsgX19pIDwg X05DUFVXT1JEUzsgX19pKyspCQlcCkBAIC0xNzgsNiArMTc5LDcgQEAKIHN0cnVjdCBwcmlzb247 CiBzdHJ1Y3QgcHJvYzsKIAoraW50CWNwdXNldF96ZXJvX21vZGlmeShjcHVzZXRfdCAqbWFzayk7 CiBzdHJ1Y3QgY3B1c2V0ICpjcHVzZXRfdGhyZWFkMCh2b2lkKTsKIHN0cnVjdCBjcHVzZXQgKmNw dXNldF9yZWYoc3RydWN0IGNwdXNldCAqKTsKIHZvaWQJY3B1c2V0X3JlbChzdHJ1Y3QgY3B1c2V0 ICopOwo= --0016e6567d28366ef604955f1e9a-- ------------------------------ Message: 18 Date: Fri, 19 Nov 2010 09:10:12 GMT From: Andriy Gapon <a...@freebsd.org<mailto:a...@freebsd.org>> Subject: Re: kern/145385: [cpu] Logical processor cannot be disabled for some SMT-enabled Intel procs To: freebsd-bugs@FreeBSD.org<mailto:freebsd-bugs@FreeBSD.org> Message-ID: <201011190910.oaj9ac2p091...@freefall.freebsd.org<mailto:201011190910.oaj9ac2p091...@freefall.freebsd.org>> The following reply was made to PR kern/145385; it has been noted by GNATS. From: Andriy Gapon <a...@freebsd.org<mailto:a...@freebsd.org>> To: bug-follo...@freebsd.org<mailto:bug-follo...@freebsd.org>, gcoo...@freebsd.org<mailto:gcoo...@freebsd.org> Cc: Subject: Re: kern/145385: [cpu] Logical processor cannot be disabled for some SMT-enabled Intel procs Date: Fri, 19 Nov 2010 11:08:30 +0200 I think that I have explained the behavior that you see and other problems with the patch in the email in which I submitted the patch. -- Andriy Gapon ------------------------------ _______________________________________________ freebsd-bugs@freebsd.org<mailto:freebsd-bugs@freebsd.org> mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org<mailto:freebsd-bugs-unsubscr...@freebsd.org>" End of freebsd-bugs Digest, Vol 399, Issue 9 ******************************************** _______________________________________________ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
