Date: Fri, 19 Nov 2010 21:09:48 -0600 From: "Criglar, Jeanette Marie" <jc044649@bcm.edu> To: "freebsd-bugs-request@freebsd.org" <freebsd-bugs-request@freebsd.org>, "freebsd-bugs-owner@freebsd.org" <freebsd-bugs-owner@freebsd.org>, "freebsd-bugs@freebsd.org" <freebsd-bugs@freebsd.org> Subject: UNSUBSCRIBE FW: freebsd-bugs Digest, Vol 399, Issue 9 Message-ID: <65FAAFC8-D3CD-4DDB-966A-125940FDC06B@bcm.edu> References: <20101119120025.390B910656D0@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Still getting this newsletter. Please UNSUBSCRIBE!
___________________________________________________________
Begin forwarded message:
From: freebsd-bugs-request@freebsd.org<mailto:freebsd-bugs-request@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-request@freebsd.org<mailto:freebsd-bugs-request@freebsd=
.org>
You can reach the person managing the list at
freebsd-bugs-owner@freebsd.org<mailto:freebsd-bugs-owner@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
(linimon@FreeBSD.org<mailto:linimon@FreeBSD.org>)
4. Re: misc/152296: wrong message when trying to checkout using
old repository path (arundel@FreeBSD.org<mailto:arundel@FreeBSD.=
org>)
5. Re: kern/152360: [dummynet] [panic] Crash related to
dummynet. (linimon@FreeBSD.org<mailto:linimon@FreeBSD.org>)
6. Re: kern/69066: [panic] nmdm(4) page fault when slattach on a
null modem device (jh@FreeBSD.org<mailto:jh@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 (jh@FreeBSD.org<mailto:jh@FreeBSD.org>)
10. Re: kern/85450: [ata] [panic] subdisk6 detached (appears to
be a sata problem, SiI 3112) (jh@FreeBSD.org<mailto:jh@FreeBSD.or=
g>)
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 (arundel@FreeBSD.org<mailto:aru=
ndel@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 (arundel@FreeBSD.org<mailto:arundel@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 <karlo@anywi.com<mailto:karlo@anywi.com>>
Subject: kern/152363: Apache can not serve images from TMPFS
To: FreeBSD-gnats-submit@FreeBSD.org<mailto:FreeBSD-gnats-submit@FreeBSD.or=
g>
Message-ID: <20101118132714.32AD229B03E@arenal.anywi.com<mailto:20101118132=
714.32AD229B03E@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 FreeB=
SD 8.1-STABLE #0: Mon Sep 13 15:48:43 CEST 2010 root@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 serv=
e images from a directory within /tmp (documentroot), images are not displa=
yed 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=3D536870912=
,mode=3D01777 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 <mjguzik@gmail.com<mailto:mjguzik@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.oAIEUEBD092754@freefall.freebsd.org<mailto:201011=
181430.oAIEUEBD092754@freefall.freebsd.org>>
The following reply was made to PR kern/152363; it has been noted by GNATS.
From: Mateusz Guzik <mjguzik@gmail.com<mailto:mjguzik@gmail.com>>
To: bug-followup@FreeBSD.org<mailto:bug-followup@FreeBSD.org>, karlo@anywi.=
com<mailto:karlo@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=3Dkern/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: linimon@FreeBSD.org<mailto:linimon@FreeBSD.org>
Subject: Re: ports/152361: [PATCH] multimedia/playd update
To: linimon@FreeBSD.org<mailto:linimon@FreeBSD.org>, freebsd-bugs@FreeBSD.o=
rg<mailto:freebsd-bugs@FreeBSD.org>,
freebsd-ports-bugs@FreeBSD.org<mailto:freebsd-ports-bugs@FreeBSD.org=
>
Message-ID: <201011181546.oAIFk4fb074556@freefall.freebsd.org<mailto:201011=
181546.oAIFk4fb074556@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=3D152361
------------------------------
Message: 4
Date: Thu, 18 Nov 2010 17:15:35 GMT
From: arundel@FreeBSD.org<mailto:arundel@FreeBSD.org>
Subject: Re: misc/152296: wrong message when trying to checkout using
old repository path
To: kenorb@gmail.com<mailto:kenorb@gmail.com>, arundel@FreeBSD.org<mailto:a=
rundel@FreeBSD.org>, freebsd-bugs@FreeBSD.org<mailto:freebsd-bugs@FreeBSD.o=
rg>,
freebsd-ports@FreeBSD.org<mailto:freebsd-ports@FreeBSD.org>
Message-ID: <201011181715.oAIHFZDk070048@freefall.freebsd.org<mailto:201011=
181715.oAIHFZDk070048@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 n=
ot
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 t=
he
development version of svn is still containing this issue. If somebody want=
s to
provide a patch we could try convincing the svn developers to push it upstr=
eam
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=3D152296
------------------------------
Message: 5
Date: Thu, 18 Nov 2010 17:34:48 GMT
From: linimon@FreeBSD.org<mailto:linimon@FreeBSD.org>
Subject: Re: kern/152360: [dummynet] [panic] Crash related to
dummynet.
To: linimon@FreeBSD.org<mailto:linimon@FreeBSD.org>, freebsd-bugs@FreeBSD.o=
rg<mailto:freebsd-bugs@FreeBSD.org>,
freebsd-net@FreeBSD.org<mailto:freebsd-net@FreeBSD.org>
Message-ID: <201011181734.oAIHYmle090487@freefall.freebsd.org<mailto:201011=
181734.oAIHYmle090487@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=3D152360
------------------------------
Message: 6
Date: Thu, 18 Nov 2010 17:44:30 GMT
From: jh@FreeBSD.org<mailto:jh@FreeBSD.org>
Subject: Re: kern/69066: [panic] nmdm(4) page fault when slattach on a
null modem device
To: rwatson@freebsd.org<mailto:rwatson@freebsd.org>, jh@FreeBSD.org<mailto:=
jh@FreeBSD.org>, freebsd-bugs@FreeBSD.org<mailto:freebsd-bugs@FreeBSD.org>
Message-ID: <201011181744.oAIHiUrH000245@freefall.freebsd.org<mailto:201011=
181744.oAIHiUrH000245@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=3D69066
------------------------------
Message: 7
Date: Thu, 18 Nov 2010 20:38:48 +0300
From: Eir Nym <eirnym@gmail.com<mailto:eirnym@gmail.com>>
Subject: Re: misc/152296: wrong message when trying to checkout using
old repository path
To: arundel@freebsd.org<mailto:arundel@freebsd.org>
Cc: kenorb@gmail.com<mailto:kenorb@gmail.com>, freebsd-bugs@freebsd.org<mai=
lto:freebsd-bugs@freebsd.org>,
freebsd-ports@freebsd.org<mailto:freebsd-ports@freebsd.org>, Fr=
eeBSD Mail Lists
<bug-followup@freebsd.org<mailto:bug-followup@freebsd.org>>
Message-ID:
<AANLkTimT7rMKy5rNec2HP1mRmaACiNZFgWmHA_RP2nMj@mail.gmail.com<mailto=
:AANLkTimT7rMKy5rNec2HP1mRmaACiNZFgWmHA_RP2nMj@mail.gmail.com>>
Content-Type: text/plain; charset=3DUTF-8
On 18 November 2010 20:15, <arundel@freebsd.org<mailto:arundel@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 n=
ot
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 t=
he
development version of svn is still containing this issue. If somebody want=
s to
provide a patch we could try convincing the svn developers to push it upstr=
eam
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=3D152296
_______________________________________________
freebsd-ports@freebsd.org<mailto:freebsd-ports@freebsd.org> mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org<mai=
lto:freebsd-ports-unsubscribe@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 <mjguzik@gmail.com<mailto:mjguzik@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.oAIIUEZb042836@freefall.freebsd.org<mailto:201011=
181830.oAIIUEZb042836@freefall.freebsd.org>>
The following reply was made to PR kern/145999; it has been noted by GNATS.
From: Mateusz Guzik <mjguzik@gmail.com<mailto:mjguzik@gmail.com>>
To: bug-followup@FreeBSD.org<mailto:bug-followup@FreeBSD.org>, mi@aldan.alg=
ebra.com<mailto:mi@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: jh@FreeBSD.org<mailto:jh@FreeBSD.org>
Subject: Re: kern/79295: umount oddity with NFS (fwe) over VIA Fire II
card
To: root@schmalzbauer.de<mailto:root@schmalzbauer.de>, jh@FreeBSD.org<mailt=
o:jh@FreeBSD.org>, freebsd-bugs@FreeBSD.org<mailto:freebsd-bugs@FreeBSD.org=
>
Message-ID: <201011182032.oAIKWWjl076700@freefall.freebsd.org<mailto:201011=
182032.oAIKWWjl076700@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=3D79295
------------------------------
Message: 10
Date: Thu, 18 Nov 2010 20:35:39 GMT
From: jh@FreeBSD.org<mailto:jh@FreeBSD.org>
Subject: Re: kern/85450: [ata] [panic] subdisk6 detached (appears to
be a sata problem, SiI 3112)
To: b.vandorp@chello.nl<mailto:b.vandorp@chello.nl>, jh@FreeBSD.org<mailto:=
jh@FreeBSD.org>, freebsd-bugs@FreeBSD.org<mailto:freebsd-bugs@FreeBSD.org>
Message-ID: <201011182035.oAIKZdKH078280@freefall.freebsd.org<mailto:201011=
182035.oAIKZdKH078280@freefall.freebsd.org>>
Synopsis: [ata] [panic] subdisk6 detached (appears to be a sata problem, Si=
I 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=3D85450
------------------------------
Message: 11
Date: Thu, 18 Nov 2010 20:55:34 GMT
From: Jason Harmening <jason.harmening@gmail.com<mailto:jason.harmening@gma=
il.com>>
Subject: kern/152378: [sound][patch] Update snd_envy24ht to be MPSAFE
and use 32-bit DMA addresses
To: freebsd-gnats-submit@FreeBSD.org<mailto:freebsd-gnats-submit@FreeBSD.or=
g>
Message-ID: <201011182055.oAIKtYe5057261@www.freebsd.org<mailto:20101118205=
5.oAIKtYe5057261@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 Fre=
eBSD 8.1-STABLE #0: Sun Nov 14 12:01:19 CST 2010 jason@riviera.austin.r=
r.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 =3D 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: arundel@FreeBSD.org<mailto:arundel@FreeBSD.org>
Subject: Re: kern/152378: [sound][patch] Update snd_envy24ht to be
MPSAFE and use 32-bit DMA addresses
To: arundel@FreeBSD.org<mailto:arundel@FreeBSD.org>, freebsd-bugs@FreeBSD.o=
rg<mailto:freebsd-bugs@FreeBSD.org>,
freebsd-multimedia@FreeBSD.org<mailto:freebsd-multimedia@FreeBSD.org=
>
Message-ID: <201011182122.oAILMgU7030092@freefall.freebsd.org<mailto:201011=
182122.oAILMgU7030092@freefall.freebsd.org>>
Synopsis: [sound][patch] Update snd_envy24ht to be MPSAFE and use 32-bit DM=
A 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=3D152378
------------------------------
Message: 13
Date: Thu, 18 Nov 2010 21:42:16 GMT
From: Bruce Cran <bruce@cran.org.uk<mailto:bruce@cran.org.uk>>
Subject: bin/152385: ee(1) has different keybindings in the livefs
environment
To: freebsd-gnats-submit@FreeBSD.org<mailto:freebsd-gnats-submit@FreeBSD.or=
g>
Message-ID: <201011182142.oAILgGEr093252@www.freebsd.org<mailto:20101118214=
2.oAILgGEr093252@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 rat=
her 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: arundel@FreeBSD.org<mailto:arundel@FreeBSD.org>
Subject: Re: bin/38727: [patch] mptable(1) should complain about
garbage arguments
To: zaitcev@redhat.com<mailto:zaitcev@redhat.com>, arundel@FreeBSD.org<mail=
to:arundel@FreeBSD.org>, freebsd-bugs@FreeBSD.org<mailto:freebsd-bugs@FreeB=
SD.org>
Message-ID: <201011182332.oAINWRLh064721@freefall.freebsd.org<mailto:201011=
182332.oAINWRLh064721@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 whic=
h
applies cleanly to HEAD right away.
http://www.freebsd.org/cgi/query-pr.cgi?pr=3D38727
------------------------------
Message: 15
Date: Fri, 19 Nov 2010 00:00:34 GMT
From: Alexander Best <arundel@freebsd.org<mailto:arundel@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.oAJ00YWK084675@freefall.freebsd.org<mailto:201011=
190000.oAJ00YWK084675@freefall.freebsd.org>>
The following reply was made to PR bin/38727; it has been noted by GNATS.
From: Alexander Best <arundel@freebsd.org<mailto:arundel@freebsd.org>>
To: bug-followup@freebsd.org<mailto:bug-followup@freebsd.org>
Cc:
Subject: Re: bin/38727: [patch] mptable(1) should complain about garbage ar=
guments
Date: Thu, 18 Nov 2010 23:53:39 +0000
--+QahgC5+KEYLbs62
Content-Type: text/plain; charset=3Dus-ascii
Content-Disposition: inline
here's an updated patch which applies cleanly to HEAD.
cheers.
alex
--
a13x
--+QahgC5+KEYLbs62
Content-Type: text/plain; charset=3Dus-ascii
Content-Disposition: attachment; filename=3D"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") =3D=3D 0 )
dmesg =3D 1;
else
- dmesg =3D 0;
- break;
- case 'h':
- if ( strcmp( optarg, "elp") =3D=3D 0 )
- usage();
+ usage();
break;
case 'g':
if ( strcmp( optarg, "rope") =3D=3D 0 )
grope =3D 1;
+ else
+ usage();
break;
case 'v':
if ( strcmp( optarg, "erbose") =3D=3D 0 )
verbose =3D 1;
+ else
+ usage();
break;
+ case 'h':
default:
usage();
}
--+QahgC5+KEYLbs62--
------------------------------
Message: 16
Date: Fri, 19 Nov 2010 00:10:12 GMT
From: Garrett Cooper <gcooper@freebsd.org<mailto:gcooper@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.oAJ0ACwk095952@freefall.freebsd.org<mailto:201011=
190010.oAJ0ACwk095952@freefall.freebsd.org>>
The following reply was made to PR kern/145385; it has been noted by GNATS.
From: Garrett Cooper <gcooper@freebsd.org<mailto:gcooper@freebsd.org>>
To: Andriy Gapon <avg@freebsd.org<mailto:avg@freebsd.org>>
Cc: bug-followup@freebsd.org<mailto:bug-followup@freebsd.org>
Subject: Re: kern/145385: [cpu] Logical processor cannot be disabled for so=
me
SMT-enabled Intel procs
Date: Thu, 18 Nov 2010 16:09:46 -0800
On Wed, Nov 17, 2010 at 4:34 PM, Garrett Cooper <gcooper@freebsd.org<mailto=
:gcooper@freebsd.org>> wrote=3D
:
On Thu, Oct 7, 2010 at 10:03 AM, Andriy Gapon <avg@freebsd.org<mailto:avg@f=
reebsd.org>> wrote:
Here's a patch to remove halted logical processors from root cpu set (cp=3D
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=3D
ot
(re-)add them cpusets of the running processes. =3DA0So additional action =
=3D
will be
required from system administrator if e would like existing processes to=3D
make use
of unhalted CPUs.
Also, interrupts that are bound to halted CPUs are not rebound on halt, =3D
and so
will be delivered to halted CPUs. =3DA0This should not be a problem for ty=
=3D
pical
environments, but would be nice to fix anyway.
=3DA0 =3DA0Sorry for taking so long to get back on this item. The patch loo=
ks
ok as far as setting the CPUSET is concerned (setting
machdep.hlt_logical_cpus=3D3D1 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
=3DA0 =3DA0... it should reset CPUSETZERO.
=3DA0 =3DA0The 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).
=3DA0 =3DA0After 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=3D3D0
ncpus=3D3D`sysctl -n kern.smp.cpus`
while [ $i -lt $ncpus ] ; do
while : ; do : ; done &
: $(( i +=3D3D 1 ))
done
2. Execute sysctl machdep.hlt_logical_cpus=3D3D1 .
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=3D3D0
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%=
=3D
.
------------------------------
Message: 17
Date: Fri, 19 Nov 2010 03:10:15 GMT
From: Garrett Cooper <gcooper@FreeBSD.org<mailto:gcooper@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.oAJ3AFng082563@freefall.freebsd.org<mailto:201011=
190310.oAJ3AFng082563@freefall.freebsd.org>>
The following reply was made to PR kern/145385; it has been noted by GNATS.
From: Garrett Cooper <gcooper@FreeBSD.org<mailto:gcooper@FreeBSD.org>>
To: Andriy Gapon <avg@freebsd.org<mailto:avg@freebsd.org>>
Cc: bug-followup@freebsd.org<mailto:bug-followup@freebsd.org>
Subject: Re: kern/145385: [cpu] Logical processor cannot be disabled for so=
me
SMT-enabled Intel procs
Date: Thu, 18 Nov 2010 19:01:08 -0800
--0016e6567d28366ef604955f1e9a
Content-Type: text/plain; charset=3DISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Thu, Nov 18, 2010 at 4:09 PM, Garrett Cooper <gcooper@freebsd.org<mailto=
:gcooper@freebsd.org>> wrote=3D
:
On Wed, Nov 17, 2010 at 4:34 PM, Garrett Cooper <gcooper@freebsd.org<mailto=
:gcooper@freebsd.org>> wro=3D
te:
On Thu, Oct 7, 2010 at 10:03 AM, Andriy Gapon <avg@freebsd.org<mailto:avg@f=
reebsd.org>> wrote:
Here's a patch to remove halted logical processors from root cpu set (c=3D
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 =3D
not
(re-)add them cpusets of the running processes. =3DA0So additional action=
=3D
will be
required from system administrator if e would like existing processes t=3D
o make use
of unhalted CPUs.
Also, interrupts that are bound to halted CPUs are not rebound on halt,=3D
and so
will be delivered to halted CPUs. =3DA0This should not be a problem for t=
=3D
ypical
environments, but would be nice to fix anyway.
=3DA0 =3DA0Sorry for taking so long to get back on this item. The patch loo=
k=3D
s
ok as far as setting the CPUSET is concerned (setting
machdep.hlt_logical_cpus=3D3D1 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
=3DA0 =3DA0... it should reset CPUSETZERO.
=3DA0 =3DA0The 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).
=3DA0 =3DA0After that all that's required is work for i386 and I'd vote for=
=3D
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=3D3D0
ncpus=3D3D`sysctl -n kern.smp.cpus`
while [ $i -lt $ncpus ] ; do
=3DA0 =3DA0while : ; do : ; done &
=3DA0 =3DA0: $(( i +=3D3D 1 ))
done
2. Execute sysctl machdep.hlt_logical_cpus=3D3D1 .
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=3D3D0
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=
=3D
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=3D3D1
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=3D3D0
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 =3D3D 0;
LIST_FOREACH(nset, &set->cs_children, cs_siblings)
if ((error =3D3D cpuset_testupdate(nset, &newmask)) !=3D3D =
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=3DUS-ASCII; name=3D"kern.145385.patch"
Content-Disposition: attachment; filename=3D"kern.145385.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_ggohebzt1
SW5kZXg6IHN5cy9hbWQ2NC9hbWQ2NC9tcF9tYWNoZGVwLmMKPT09PT09PT09PT09PT09PT09PT0=
9
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2F=
t
ZDY0L2FtZDY0L21wX21hY2hkZXAuYwkocmV2aXNpb24gMjE1NDE3KQorKysgc3lzL2FtZDY0L2F=
t
ZDY0L21wX21hY2hkZXAuYwkod29ya2luZyBjb3B5KQpAQCAtMzksNiArMzksNyBAQAogI2lmZGV=
m
IEdQUk9GIAogI2luY2x1ZGUgPHN5cy9nbW9uLmg+CiAjZW5kaWYKKyNpbmNsdWRlIDxzeXMvY3B=
1
c2V0Lmg+CiAjaW5jbHVkZSA8c3lzL2tlcm5lbC5oPgogI2luY2x1ZGUgPHN5cy9rdHIuaD4KICN=
p
bmNsdWRlIDxzeXMvbG9jay5oPgpAQCAtODUsNyArODYsNyBAQAogaW50CW1wX25hcHM7CQkvKiA=
j
IG9mIEFwcGxpY2F0aW9ucyBwcm9jZXNzb3JzICovCiBpbnQJYm9vdF9jcHVfaWQgPSAtMTsJLyo=
g
ZGVzaWduYXRlZCBCU1AgKi8KIAotZXh0ZXJuICBzdHJ1Y3QgcGNwdSBfX3BjcHVbXTsKK2V4dGV=
y
bglzdHJ1Y3QgcGNwdSBfX3BjcHVbXTsKIAogLyogQVAgdXNlcyB0aGlzIGR1cmluZyBib290c3R=
y
YXAuICBEbyBub3Qgc3RhdGljaXplLiAgKi8KIGNoYXIgKmJvb3RTVEs7CkBAIC0xMTQ1LDcgKzE=
x
NDYsNyBAQAogCQkJb2xkX3BlbmRpbmcgPSBjcHVfaXBpX3BlbmRpbmdbY3B1XTsKIAkJCW5ld19=
w
ZW5kaW5nID0gb2xkX3BlbmRpbmcgfCBiaXRtYXA7CiAJCX0gd2hpbGUgICghYXRvbWljX2NtcHN=
l
dF9pbnQoJmNwdV9pcGlfcGVuZGluZ1tjcHVdLAotCQkgICAgb2xkX3BlbmRpbmcsIG5ld19wZW5=
k
aW5nKSk7IAorCQkgICAgb2xkX3BlbmRpbmcsIG5ld19wZW5kaW5nKSk7CiAJCWlmIChvbGRfcGV=
u
ZGluZykKIAkJCXJldHVybjsKIAl9CkBAIC0xMzMzLDcgKzEzMzQsNiBAQAogCSAqLwogCWlmICh=
p
cGkgPT0gSVBJX1NUT1BfSEFSRCkKIAkJYXRvbWljX3NldF9pbnQoJmlwaV9ubWlfcGVuZGluZyw=
g
UENQVV9HRVQob3RoZXJfY3B1cykpOwotCiAJQ1RSMihLVFJfU01QLCAiJXM6IGlwaTogJXgiLCB=
f
X2Z1bmNfXywgaXBpKTsKIAlsYXBpY19pcGlfdmVjdG9yZWQoaXBpLCBBUElDX0lQSV9ERVNUX09=
U
SEVSUyk7CiB9CkBAIC0xMzU3LDcgKzEzNTcsNyBAQAogCWNwdXN0b3BfaGFuZGxlcigpOwogCXJ=
l
dHVybiAoMCk7CiB9Ci0gICAgIAorCiAvKgogICogSGFuZGxlIGFuIElQSV9TVE9QIGJ5IHNhdml=
u
ZyBvdXIgY3VycmVudCBjb250ZXh0IGFuZCBzcGlubmluZyB1bnRpbCB3ZQogICogYXJlIHJlc3V=
t
ZWQuCkBAIC0xNDQ3LDYgKzE0NDcsNyBAQAogc3RhdGljIGludAogc3lzY3RsX2hsdF9jcHVzKFN=
Z
U0NUTF9IQU5ETEVSX0FSR1MpCiB7CisJY3B1c2V0X3QgbWFza19zZXQ7CiAJY3B1bWFza190IG1=
h
c2s7CiAJaW50IGVycm9yOwogCkBAIC0xNDU1LDE4ICsxNDU2LDIwIEBACiAJaWYgKGVycm9yIHx=
8
ICFyZXEtPm5ld3B0cikKIAkJcmV0dXJuIChlcnJvcik7CiAKLQlpZiAobG9naWNhbF9jcHVzX21=
h
c2sgIT0gMCAmJgotCSAgICAobWFzayAmIGxvZ2ljYWxfY3B1c19tYXNrKSA9PSBsb2dpY2FsX2N=
w
dXNfbWFzaykKLQkJaGx0X2xvZ2ljYWxfY3B1cyA9IDE7Ci0JZWxzZQotCQlobHRfbG9naWNhbF9=
j
cHVzID0gMDsKLQotCWlmICghIGh5cGVydGhyZWFkaW5nX2FsbG93ZWQpCisJaWYgKGhsdF9sb2d=
p
Y2FsX2NwdXMpCisJCW1hc2sgfD0gbG9naWNhbF9jcHVzX21hc2s7CisJaWYgKCFoeXBlcnRocmV=
h
ZGluZ19hbGxvd2VkKQogCQltYXNrIHw9IGh5cGVydGhyZWFkaW5nX2NwdXNfbWFzazsKIAorCS8=
q
IERvbid0IGRpc2FibGUgQlNQMCAqLwogCWlmICgobWFzayAmIGFsbF9jcHVzKSA9PSBhbGxfY3B=
1
cykKIAkJbWFzayAmPSB+KDE8PDApOwotCWhsdF9jcHVzX21hc2sgPSBtYXNrOworCisJQ1BVX1p=
F
Uk8oJm1hc2tfc2V0KTsKKwlDUFVfU0VUTUFTSyh+bWFzayAmIGFsbF9jcHVzLCAmbWFza19zZXQ=
p
OworCWVycm9yID0gY3B1c2V0X3plcm9fbW9kaWZ5KCZtYXNrX3NldCk7CisJaWYgKGVycm9yID0=
9
IDApCisJCWhsdF9jcHVzX21hc2sgPSBtYXNrOwogCXJldHVybiAoZXJyb3IpOwogfQogU1lTQ1R=
M
X1BST0MoX21hY2hkZXAsIE9JRF9BVVRPLCBobHRfY3B1cywgQ1RMVFlQRV9JTlR8Q1RMRkxBR19=
S
VywKQEAgLTE0NzYsNiArMTQ3OSw4IEBACiBzdGF0aWMgaW50CiBzeXNjdGxfaGx0X2xvZ2ljYWx=
f
Y3B1cyhTWVNDVExfSEFORExFUl9BUkdTKQogeworCWNwdXNldF90IG1hc2tfc2V0OworCWNwdW1=
h
c2tfdCBtYXNrOwogCWludCBkaXNhYmxlLCBlcnJvcjsKIAogCWRpc2FibGUgPSBobHRfbG9naWN=
h
bF9jcHVzOwpAQCAtMTQ4MywyNCArMTQ4OCwzMSBAQAogCWlmIChlcnJvciB8fCAhcmVxLT5uZXd=
w
dHIpCiAJCXJldHVybiAoZXJyb3IpOwogCisJbWFzayA9IGhsdF9jcHVzX21hc2s7CiAJaWYgKGR=
p
c2FibGUpCi0JCWhsdF9jcHVzX21hc2sgfD0gbG9naWNhbF9jcHVzX21hc2s7Ci0JZWxzZQotCQl=
o
bHRfY3B1c19tYXNrICY9IH5sb2dpY2FsX2NwdXNfbWFzazsKKwkJbWFzayB8PSBsb2dpY2FsX2N=
w
dXNfbWFzazsKKwlpZiAoIWh5cGVydGhyZWFkaW5nX2FsbG93ZWQpCisJCW1hc2sgfD0gaHlwZXJ=
0
aHJlYWRpbmdfY3B1c19tYXNrOwogCi0JaWYgKCEgaHlwZXJ0aHJlYWRpbmdfYWxsb3dlZCkKLQk=
J
aGx0X2NwdXNfbWFzayB8PSBoeXBlcnRocmVhZGluZ19jcHVzX21hc2s7CisJLyogRG9uJ3QgZGl=
z
YWJsZSBCU1AwICovCisJaWYgKChtYXNrICYgYWxsX2NwdXMpID09IGFsbF9jcHVzKQorCQltYXN=
r
ICY9IH4oMTw8MCk7CiAKLQlpZiAoKGhsdF9jcHVzX21hc2sgJiBhbGxfY3B1cykgPT0gYWxsX2N=
w
dXMpCi0JCWhsdF9jcHVzX21hc2sgJj0gfigxPDwwKTsKKwlwcmludGYoIiVzOiBtYXNrOiAlZFx=
u
IiwgX19mdW5jX18sIG1hc2spOwogCi0JaGx0X2xvZ2ljYWxfY3B1cyA9IGRpc2FibGU7CisJQ1B=
V
X1pFUk8oJm1hc2tfc2V0KTsKKwlDUFVfU0VUTUFTSyh+bWFzayAmIGFsbF9jcHVzLCAmbWFza19=
z
ZXQpOworCWVycm9yID0gY3B1c2V0X3plcm9fbW9kaWZ5KCZtYXNrX3NldCk7CisJaWYgKGVycm9=
y
ID09IDApIAorCQlobHRfbG9naWNhbF9jcHVzID0gZGlzYWJsZTsKIAlyZXR1cm4gKGVycm9yKTs=
K
IH0KIAogc3RhdGljIGludAogc3lzY3RsX2h5cGVydGhyZWFkaW5nX2FsbG93ZWQoU1lTQ1RMX0h=
B
TkRMRVJfQVJHUykKIHsKKwljcHVzZXRfdCBtYXNrX3NldDsKKwljcHVtYXNrX3QgbWFzazsKIAl=
p
bnQgYWxsb3dlZCwgZXJyb3I7CiAKIAlhbGxvd2VkID0gaHlwZXJ0aHJlYWRpbmdfYWxsb3dlZDs=
K
QEAgLTE1MDgsNDIgKzE1MjAsNDUgQEAKIAlpZiAoZXJyb3IgfHwgIXJlcS0+bmV3cHRyKQogCQl=
y
ZXR1cm4gKGVycm9yKTsKIAotI2lmZGVmIFNDSEVEX1VMRQotCS8qCi0JICogU0NIRURfVUxFIGR=
v
ZXNuJ3QgYWxsb3cgZW5hYmxpbmcvZGlzYWJsaW5nIEhUIGNvcmVzIGF0Ci0JICogcnVuLXRpbWU=
u
Ci0JICovCi0JaWYgKGFsbG93ZWQgIT0gaHlwZXJ0aHJlYWRpbmdfYWxsb3dlZCkKLQkJcmV0dXJ=
u
IChFTk9UU1VQKTsKLQlyZXR1cm4gKGVycm9yKTsKLSNlbmRpZgorCW1hc2sgPSBobHRfY3B1c19=
t
YXNrOworCWlmIChobHRfbG9naWNhbF9jcHVzKQorCQltYXNrIHw9IGxvZ2ljYWxfY3B1c19tYXN=
r
OworCWlmICghYWxsb3dlZCkKKwkJbWFzayB8PSBoeXBlcnRocmVhZGluZ19jcHVzX21hc2s7CiA=
K
LQlpZiAoYWxsb3dlZCkKLQkJaGx0X2NwdXNfbWFzayAmPSB+aHlwZXJ0aHJlYWRpbmdfY3B1c19=
t
YXNrOwotCWVsc2UKLQkJaGx0X2NwdXNfbWFzayB8PSBoeXBlcnRocmVhZGluZ19jcHVzX21hc2s=
7
CisJLyogRG9uJ3QgZGlzYWJsZSBCU1AwICovCisJaWYgKChtYXNrICYgYWxsX2NwdXMpID09IGF=
s
bF9jcHVzKQorCQltYXNrICY9IH4oMTw8MCk7CiAKLQlpZiAobG9naWNhbF9jcHVzX21hc2sgIT0=
g
MCAmJgotCSAgICAoaGx0X2NwdXNfbWFzayAmIGxvZ2ljYWxfY3B1c19tYXNrKSA9PSBsb2dpY2F=
s
X2NwdXNfbWFzaykKLQkJaGx0X2xvZ2ljYWxfY3B1cyA9IDE7Ci0JZWxzZQotCQlobHRfbG9naWN=
h
bF9jcHVzID0gMDsKLQotCWlmICgoaGx0X2NwdXNfbWFzayAmIGFsbF9jcHVzKSA9PSBhbGxfY3B=
1
cykKLQkJaGx0X2NwdXNfbWFzayAmPSB+KDE8PDApOwotCi0JaHlwZXJ0aHJlYWRpbmdfYWxsb3d=
l
ZCA9IGFsbG93ZWQ7CisJQ1BVX1pFUk8oJm1hc2tfc2V0KTsKKwlDUFVfU0VUTUFTSyh+bWFzayA=
m
IGFsbF9jcHVzLCAmbWFza19zZXQpOworCWVycm9yID0gY3B1c2V0X3plcm9fbW9kaWZ5KCZtYXN=
r
X3NldCk7CisJaWYgKGVycm9yID09IDApIAorCQloeXBlcnRocmVhZGluZ19hbGxvd2VkID0gYWx=
s
b3dlZDsKIAlyZXR1cm4gKGVycm9yKTsKIH0KIAogc3RhdGljIHZvaWQKIGNwdV9obHRfc2V0dXA=
o
dm9pZCAqZHVtbXkgX191bnVzZWQpCiB7CisJY3B1c2V0X3QgbWFza19zZXQ7CiAKIAlpZiAobG9=
n
aWNhbF9jcHVzX21hc2sgIT0gMCkgewogCQlUVU5BQkxFX0lOVF9GRVRDSCgibWFjaGRlcC5obHR=
f
bG9naWNhbF9jcHVzIiwKIAkJICAgICZobHRfbG9naWNhbF9jcHVzKTsKKwkJaWYgKGhsdF9sb2d=
p
Y2FsX2NwdXMgIT0gMCkgeworCQkJQ1BVX1pFUk8oJm1hc2tfc2V0KTsKKwkJCUNQVV9TRVRNQVN=
L
KH5sb2dpY2FsX2NwdXNfbWFzayAmIGFsbF9jcHVzLCAmbWFza19zZXQpOworCQkJaWYgKGNwdXN=
l
dF96ZXJvX21vZGlmeSgmbWFza19zZXQpID09IDApCisJCQkJaGx0X2xvZ2ljYWxfY3B1cyA9IDE=
7
CisJCQllbHNlCisJCQkJaGx0X2xvZ2ljYWxfY3B1cyA9IDA7CisJCX0KIAkJc3lzY3RsX2N0eF9=
p
bml0KCZsb2dpY2FsX2NwdV9jbGlzdCk7CisJCVNZU0NUTF9BRERfVUlOVCgmbG9naWNhbF9jcHV=
f
Y2xpc3QsCisJCSAgICBTWVNDVExfU1RBVElDX0NISUxEUkVOKF9tYWNoZGVwKSwgT0lEX0FVVE8=
s
CisJCSAgICAiYWxsX2NwdXNfbWFzayIsIENUTFRZUEVfSU5UfENUTEZMQUdfUkQsCisJCSAgICA=
m
YWxsX2NwdXMsIDAsICIiKTsKIAkJU1lTQ1RMX0FERF9QUk9DKCZsb2dpY2FsX2NwdV9jbGlzdCw=
K
IAkJICAgIFNZU0NUTF9TVEFUSUNfQ0hJTERSRU4oX21hY2hkZXApLCBPSURfQVVUTywKIAkJICA=
g
ICJobHRfbG9naWNhbF9jcHVzIiwgQ1RMVFlQRV9JTlR8Q1RMRkxBR19SVywgMCwgMCwKQEAgLTE=
1
NTMsOSArMTU2OCw2IEBACiAJCSAgICAibG9naWNhbF9jcHVzX21hc2siLCBDVExUWVBFX0lOVHx=
D
VExGTEFHX1JELAogCQkgICAgJmxvZ2ljYWxfY3B1c19tYXNrLCAwLCAiIik7CiAKLQkJaWYgKGh=
s
dF9sb2dpY2FsX2NwdXMpCi0JCQlobHRfY3B1c19tYXNrIHw9IGxvZ2ljYWxfY3B1c19tYXNrOwo=
t
CiAJCS8qCiAJCSAqIElmIG5lY2Vzc2FyeSBmb3Igc2VjdXJpdHkgcHVycG9zZXMsIGZvcmNlCiA=
J
CSAqIGh5cGVydGhyZWFkaW5nIG9mZiwgcmVnYXJkbGVzcyBvZiB0aGUgdmFsdWUKQEAgLTE1NjY=
s
OCArMTU3OCw2IEBACiAJCQkgICAgU1lTQ1RMX1NUQVRJQ19DSElMRFJFTihfbWFjaGRlcCksIE9=
J
RF9BVVRPLAogCQkJICAgICJoeXBlcnRocmVhZGluZ19hbGxvd2VkIiwgQ1RMVFlQRV9JTlR8Q1R=
M
RkxBR19SVywKIAkJCSAgICAwLCAwLCBzeXNjdGxfaHlwZXJ0aHJlYWRpbmdfYWxsb3dlZCwgIkl=
V
IiwgIiIpOwotCQkJaWYgKCEgaHlwZXJ0aHJlYWRpbmdfYWxsb3dlZCkKLQkJCQlobHRfY3B1c19=
t
YXNrIHw9IGh5cGVydGhyZWFkaW5nX2NwdXNfbWFzazsKIAkJfQogCX0KIH0KQEAgLTE2MjcsNCA=
r
MTYzNywzIEBACiB9CiBTWVNJTklUKG1wX2lwaV9pbnRyY250LCBTSV9TVUJfSU5UUiwgU0lfT1J=
E
RVJfTUlERExFLCBtcF9pcGlfaW50cmNudCwgTlVMTCk7CiAjZW5kaWYKLQpJbmRleDogc3lzL2k=
z
ODYvaTM4Ni9tcF9tYWNoZGVwLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0=
9
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2kzODYvaTM4Ni9tcF9tYWN=
o
ZGVwLmMJKHJldmlzaW9uIDIxNTQxNykKKysrIHN5cy9pMzg2L2kzODYvbXBfbWFjaGRlcC5jCSh=
3
b3JraW5nIGNvcHkpCkBAIC01NCw2ICs1NCw3IEBACiAjaWZkZWYgR1BST0YgCiAjaW5jbHVkZSA=
8
c3lzL2dtb24uaD4KICNlbmRpZgorI2luY2x1ZGUgPHN5cy9jcHVzZXQuaD4KICNpbmNsdWRlIDx=
z
eXMva2VybmVsLmg+CiAjaW5jbHVkZSA8c3lzL2t0ci5oPgogI2luY2x1ZGUgPHN5cy9sb2NrLmg=
+
CkBAIC0xMTk3LDcgKzExOTgsNyBAQAogCWludCBuY3B1LCBvdGhlcmNwdXM7CiAKIAlvdGhlcmN=
w
dXMgPSBtcF9uY3B1cyAtIDE7Ci0JaWYgKG1hc2sgPT0gKHVfaW50KS0xKSB7CisJaWYgKG1hc2s=
g
PT0gKGNwdW1hc2tfdCktMSkgewogCQluY3B1ID0gb3RoZXJjcHVzOwogCQlpZiAobmNwdSA8IDE=
p
CiAJCQlyZXR1cm47CkBAIC0xMjIyLDcgKzEyMjMsNyBAQAogCXNtcF90bGJfYWRkcjEgPSBhZGR=
y
MTsKIAlzbXBfdGxiX2FkZHIyID0gYWRkcjI7CiAJYXRvbWljX3N0b3JlX3JlbF9pbnQoJnNtcF9=
0
bGJfd2FpdCwgMCk7Ci0JaWYgKG1hc2sgPT0gKHVfaW50KS0xKQorCWlmIChtYXNrID09IChjcHV=
t
YXNrX3QpLTEpCiAJCWlwaV9hbGxfYnV0X3NlbGYodmVjdG9yKTsKIAllbHNlCiAJCWlwaV9zZWx=
l
Y3RlZChtYXNrLCB2ZWN0b3IpOwpAQCAtMTI0OCw3ICsxMjQ5LDcgQEAKIAkJCW9sZF9wZW5kaW5=
n
ID0gY3B1X2lwaV9wZW5kaW5nW2NwdV07CiAJCQluZXdfcGVuZGluZyA9IG9sZF9wZW5kaW5nIHw=
g
Yml0bWFwOwogCQl9IHdoaWxlICAoIWF0b21pY19jbXBzZXRfaW50KCZjcHVfaXBpX3BlbmRpbmd=
b
Y3B1XSwKLQkJICAgIG9sZF9wZW5kaW5nLCBuZXdfcGVuZGluZykpOwkKKwkJICAgIG9sZF9wZW5=
k
aW5nLCBuZXdfcGVuZGluZykpOwogCQlpZiAob2xkX3BlbmRpbmcpCiAJCQlyZXR1cm47CiAJfQp=
A
QCAtMTUxMCw2ICsxNTExLDcgQEAKIHN0YXRpYyBpbnQKIHN5c2N0bF9obHRfY3B1cyhTWVNDVEx=
f
SEFORExFUl9BUkdTKQogeworCWNwdXNldF90IG1hc2tfc2V0OwogCWNwdW1hc2tfdCBtYXNrOwo=
g
CWludCBlcnJvcjsKIApAQCAtMTUxOCwxOCArMTUyMCwyMCBAQAogCWlmIChlcnJvciB8fCAhcmV=
x
LT5uZXdwdHIpCiAJCXJldHVybiAoZXJyb3IpOwogCi0JaWYgKGxvZ2ljYWxfY3B1c19tYXNrICE=
9
IDAgJiYKLQkgICAgKG1hc2sgJiBsb2dpY2FsX2NwdXNfbWFzaykgPT0gbG9naWNhbF9jcHVzX21=
h
c2spCi0JCWhsdF9sb2dpY2FsX2NwdXMgPSAxOwotCWVsc2UKLQkJaGx0X2xvZ2ljYWxfY3B1cyA=
9
IDA7Ci0KLQlpZiAoISBoeXBlcnRocmVhZGluZ19hbGxvd2VkKQorCWlmIChobHRfbG9naWNhbF9=
j
cHVzKQorCQltYXNrIHw9IGxvZ2ljYWxfY3B1c19tYXNrOworCWlmICghaHlwZXJ0aHJlYWRpbmd=
f
YWxsb3dlZCkKIAkJbWFzayB8PSBoeXBlcnRocmVhZGluZ19jcHVzX21hc2s7CiAKKwkvKiBEb24=
n
dCBkaXNhYmxlIEJTUDAgKi8KIAlpZiAoKG1hc2sgJiBhbGxfY3B1cykgPT0gYWxsX2NwdXMpCiA=
J
CW1hc2sgJj0gfigxPDwwKTsKLQlobHRfY3B1c19tYXNrID0gbWFzazsKKworCUNQVV9aRVJPKCZ=
t
YXNrX3NldCk7CisJQ1BVX1NFVE1BU0sofm1hc2sgJiBhbGxfY3B1cywgJm1hc2tfc2V0KTsKKwl=
l
cnJvciA9IGNwdXNldF96ZXJvX21vZGlmeSgmbWFza19zZXQpOworCWlmIChlcnJvciA9PSAwKQo=
r
CQlobHRfY3B1c19tYXNrID0gbWFzazsKIAlyZXR1cm4gKGVycm9yKTsKIH0KIFNZU0NUTF9QUk9=
D
KF9tYWNoZGVwLCBPSURfQVVUTywgaGx0X2NwdXMsIENUTFRZUEVfSU5UfENUTEZMQUdfUlcsCkB=
A
IC0xNTM5LDYgKzE1NDMsOCBAQAogc3RhdGljIGludAogc3lzY3RsX2hsdF9sb2dpY2FsX2NwdXM=
o
U1lTQ1RMX0hBTkRMRVJfQVJHUykKIHsKKwljcHVzZXRfdCBtYXNrX3NldDsKKwljcHVtYXNrX3Q=
g
bWFzazsKIAlpbnQgZGlzYWJsZSwgZXJyb3I7CiAKIAlkaXNhYmxlID0gaGx0X2xvZ2ljYWxfY3B=
1
czsKQEAgLTE1NDYsMjQgKzE1NTIsMzEgQEAKIAlpZiAoZXJyb3IgfHwgIXJlcS0+bmV3cHRyKQo=
g
CQlyZXR1cm4gKGVycm9yKTsKIAorCW1hc2sgPSBobHRfY3B1c19tYXNrOwogCWlmIChkaXNhYmx=
l
KQotCQlobHRfY3B1c19tYXNrIHw9IGxvZ2ljYWxfY3B1c19tYXNrOwotCWVsc2UKLQkJaGx0X2N=
w
dXNfbWFzayAmPSB+bG9naWNhbF9jcHVzX21hc2s7CisJCW1hc2sgfD0gbG9naWNhbF9jcHVzX21=
h
c2s7CisJaWYgKCFoeXBlcnRocmVhZGluZ19hbGxvd2VkKQorCQltYXNrIHw9IGh5cGVydGhyZWF=
k
aW5nX2NwdXNfbWFzazsKIAotCWlmICghIGh5cGVydGhyZWFkaW5nX2FsbG93ZWQpCi0JCWhsdF9=
j
cHVzX21hc2sgfD0gaHlwZXJ0aHJlYWRpbmdfY3B1c19tYXNrOworCS8qIERvbid0IGRpc2FibGU=
g
QlNQMCAqLworCWlmICgobWFzayAmIGFsbF9jcHVzKSA9PSBhbGxfY3B1cykKKwkJbWFzayAmPSB=
+
KDE8PDApOwogCi0JaWYgKChobHRfY3B1c19tYXNrICYgYWxsX2NwdXMpID09IGFsbF9jcHVzKQo=
t
CQlobHRfY3B1c19tYXNrICY9IH4oMTw8MCk7CisJcHJpbnRmKCIlczogbWFzazogJWRcbiIsIF9=
f
ZnVuY19fLCBtYXNrKTsKIAotCWhsdF9sb2dpY2FsX2NwdXMgPSBkaXNhYmxlOworCUNQVV9aRVJ=
P
KCZtYXNrX3NldCk7CisJQ1BVX1NFVE1BU0sofm1hc2sgJiBhbGxfY3B1cywgJm1hc2tfc2V0KTs=
K
KwllcnJvciA9IGNwdXNldF96ZXJvX21vZGlmeSgmbWFza19zZXQpOworCWlmIChlcnJvciA9PSA=
w
KSAKKwkJaGx0X2xvZ2ljYWxfY3B1cyA9IGRpc2FibGU7CiAJcmV0dXJuIChlcnJvcik7CiB9CiA=
K
IHN0YXRpYyBpbnQKIHN5c2N0bF9oeXBlcnRocmVhZGluZ19hbGxvd2VkKFNZU0NUTF9IQU5ETEV=
S
X0FSR1MpCiB7CisJY3B1c2V0X3QgbWFza19zZXQ7CisJY3B1bWFza190IG1hc2s7CiAJaW50IGF=
s
bG93ZWQsIGVycm9yOwogCiAJYWxsb3dlZCA9IGh5cGVydGhyZWFkaW5nX2FsbG93ZWQ7CkBAIC0=
x
NTcxLDQyICsxNTg0LDQ1IEBACiAJaWYgKGVycm9yIHx8ICFyZXEtPm5ld3B0cikKIAkJcmV0dXJ=
u
IChlcnJvcik7CiAKLSNpZmRlZiBTQ0hFRF9VTEUKLQkvKgotCSAqIFNDSEVEX1VMRSBkb2Vzbid=
0
IGFsbG93IGVuYWJsaW5nL2Rpc2FibGluZyBIVCBjb3JlcyBhdAotCSAqIHJ1bi10aW1lLgotCSA=
q
LwotCWlmIChhbGxvd2VkICE9IGh5cGVydGhyZWFkaW5nX2FsbG93ZWQpCi0JCXJldHVybiAoRU5=
P
VFNVUCk7Ci0JcmV0dXJuIChlcnJvcik7Ci0jZW5kaWYKKwltYXNrID0gaGx0X2NwdXNfbWFzazs=
K
KwlpZiAoaGx0X2xvZ2ljYWxfY3B1cykKKwkJbWFzayB8PSBsb2dpY2FsX2NwdXNfbWFzazsKKwl=
p
ZiAoIWFsbG93ZWQpCisJCW1hc2sgfD0gaHlwZXJ0aHJlYWRpbmdfY3B1c19tYXNrOwogCi0JaWY=
g
KGFsbG93ZWQpCi0JCWhsdF9jcHVzX21hc2sgJj0gfmh5cGVydGhyZWFkaW5nX2NwdXNfbWFzazs=
K
LQllbHNlCi0JCWhsdF9jcHVzX21hc2sgfD0gaHlwZXJ0aHJlYWRpbmdfY3B1c19tYXNrOworCS8=
q
IERvbid0IGRpc2FibGUgQlNQMCAqLworCWlmICgobWFzayAmIGFsbF9jcHVzKSA9PSBhbGxfY3B=
1
cykKKwkJbWFzayAmPSB+KDE8PDApOwogCi0JaWYgKGxvZ2ljYWxfY3B1c19tYXNrICE9IDAgJiY=
K
LQkgICAgKGhsdF9jcHVzX21hc2sgJiBsb2dpY2FsX2NwdXNfbWFzaykgPT0gbG9naWNhbF9jcHV=
z
X21hc2spCi0JCWhsdF9sb2dpY2FsX2NwdXMgPSAxOwotCWVsc2UKLQkJaGx0X2xvZ2ljYWxfY3B=
1
cyA9IDA7Ci0KLQlpZiAoKGhsdF9jcHVzX21hc2sgJiBhbGxfY3B1cykgPT0gYWxsX2NwdXMpCi0=
J
CWhsdF9jcHVzX21hc2sgJj0gfigxPDwwKTsKLQotCWh5cGVydGhyZWFkaW5nX2FsbG93ZWQgPSB=
h
bGxvd2VkOworCUNQVV9aRVJPKCZtYXNrX3NldCk7CisJQ1BVX1NFVE1BU0sofm1hc2sgJiBhbGx=
f
Y3B1cywgJm1hc2tfc2V0KTsKKwllcnJvciA9IGNwdXNldF96ZXJvX21vZGlmeSgmbWFza19zZXQ=
p
OworCWlmIChlcnJvciA9PSAwKSAKKwkJaHlwZXJ0aHJlYWRpbmdfYWxsb3dlZCA9IGFsbG93ZWQ=
7
CiAJcmV0dXJuIChlcnJvcik7CiB9CiAKIHN0YXRpYyB2b2lkCiBjcHVfaGx0X3NldHVwKHZvaWQ=
g
KmR1bW15IF9fdW51c2VkKQogeworCWNwdXNldF90IG1hc2tfc2V0OwogCiAJaWYgKGxvZ2ljYWx=
f
Y3B1c19tYXNrICE9IDApIHsKIAkJVFVOQUJMRV9JTlRfRkVUQ0goIm1hY2hkZXAuaGx0X2xvZ2l=
j
YWxfY3B1cyIsCiAJCSAgICAmaGx0X2xvZ2ljYWxfY3B1cyk7CisJCWlmIChobHRfbG9naWNhbF9=
j
cHVzICE9IDApIHsKKwkJCUNQVV9aRVJPKCZtYXNrX3NldCk7CisJCQlDUFVfU0VUTUFTSyh+bG9=
n
aWNhbF9jcHVzX21hc2sgJiBhbGxfY3B1cywgJm1hc2tfc2V0KTsKKwkJCWlmIChjcHVzZXRfemV=
y
b19tb2RpZnkoJm1hc2tfc2V0KSA9PSAwKQorCQkJCWhsdF9sb2dpY2FsX2NwdXMgPSAxOworCQk=
J
ZWxzZQorCQkJCWhsdF9sb2dpY2FsX2NwdXMgPSAwOworCQl9CiAJCXN5c2N0bF9jdHhfaW5pdCg=
m
bG9naWNhbF9jcHVfY2xpc3QpOworCQlTWVNDVExfQUREX1VJTlQoJmxvZ2ljYWxfY3B1X2NsaXN=
0
LAorCQkgICAgU1lTQ1RMX1NUQVRJQ19DSElMRFJFTihfbWFjaGRlcCksIE9JRF9BVVRPLAorCQk=
g
ICAgImFsbF9jcHVzX21hc2siLCBDVExUWVBFX0lOVHxDVExGTEFHX1JELAorCQkgICAgJmFsbF9=
j
cHVzLCAwLCAiIik7CiAJCVNZU0NUTF9BRERfUFJPQygmbG9naWNhbF9jcHVfY2xpc3QsCiAJCSA=
g
ICBTWVNDVExfU1RBVElDX0NISUxEUkVOKF9tYWNoZGVwKSwgT0lEX0FVVE8sCiAJCSAgICAiaGx=
0
X2xvZ2ljYWxfY3B1cyIsIENUTFRZUEVfSU5UfENUTEZMQUdfUlcsIDAsIDAsCkBAIC0xNjE2LDk=
g
KzE2MzIsNiBAQAogCQkgICAgImxvZ2ljYWxfY3B1c19tYXNrIiwgQ1RMVFlQRV9JTlR8Q1RMRkx=
B
R19SRCwKIAkJICAgICZsb2dpY2FsX2NwdXNfbWFzaywgMCwgIiIpOwogCi0JCWlmIChobHRfbG9=
n
aWNhbF9jcHVzKQotCQkJaGx0X2NwdXNfbWFzayB8PSBsb2dpY2FsX2NwdXNfbWFzazsKLQogCQk=
v
KgogCQkgKiBJZiBuZWNlc3NhcnkgZm9yIHNlY3VyaXR5IHB1cnBvc2VzLCBmb3JjZQogCQkgKiB=
o
eXBlcnRocmVhZGluZyBvZmYsIHJlZ2FyZGxlc3Mgb2YgdGhlIHZhbHVlCkBAIC0xNjI5LDggKzE=
2
NDIsNiBAQAogCQkJICAgIFNZU0NUTF9TVEFUSUNfQ0hJTERSRU4oX21hY2hkZXApLCBPSURfQVV=
U
TywKIAkJCSAgICAiaHlwZXJ0aHJlYWRpbmdfYWxsb3dlZCIsIENUTFRZUEVfSU5UfENUTEZMQUd=
f
UlcsCiAJCQkgICAgMCwgMCwgc3lzY3RsX2h5cGVydGhyZWFkaW5nX2FsbG93ZWQsICJJVSIsICI=
i
KTsKLQkJCWlmICghIGh5cGVydGhyZWFkaW5nX2FsbG93ZWQpCi0JCQkJaGx0X2NwdXNfbWFzayB=
8
PSBoeXBlcnRocmVhZGluZ19jcHVzX21hc2s7CiAJCX0KIAl9CiB9CkBAIC0xNjg2LDcgKzE2OTc=
s
NyBAQAogCQlpbnRyY250X2FkZChidWYsICZpcGlfbGF6eXBtYXBfY291bnRzW2ldKTsKIAkJc25=
w
cmludGYoYnVmLCBzaXplb2YoYnVmKSwgImNwdSVkOmhhcmRjbG9jayIsIGkpOwogCQlpbnRyY25=
0
X2FkZChidWYsICZpcGlfaGFyZGNsb2NrX2NvdW50c1tpXSk7Ci0JfQkJCisJfQogfQogU1lTSU5=
J
VChtcF9pcGlfaW50cmNudCwgU0lfU1VCX0lOVFIsIFNJX09SREVSX01JRERMRSwgbXBfaXBpX2l=
u
dHJjbnQsIE5VTEwpOwogI2VuZGlmCkluZGV4OiBzeXMva2Vybi9rZXJuX2NwdXNldC5jCj09PT0=
9
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0=
9
PT09PT0KLS0tIHN5cy9rZXJuL2tlcm5fY3B1c2V0LmMJKHJldmlzaW9uIDIxNTQxNykKKysrIHN=
5
cy9rZXJuL2tlcm5fY3B1c2V0LmMJKHdvcmtpbmcgY29weSkKQEAgLTMzMiw2ICszMzIsMTAgQEA=
K
IAogCW10eF9hc3NlcnQoJmNwdXNldF9sb2NrLCBNQV9PV05FRCk7CiAJQ1BVX0FORCgmc2V0LT5=
j
c19tYXNrLCBtYXNrKTsKKyNpZiAxCisJcHJpbnRmKCIlcyAoYWZ0ZXIpOiBzZXQ6ICVsZCwgbWF=
z
azogJWxkXG4iLCBfX2Z1bmNfXywKKwkgICAgc2V0LT5jc19tYXNrLl9fYml0c1swXSwgbWFzay0=
+
X19iaXRzWzBdKTsKKyNlbmRpZgogCUxJU1RfRk9SRUFDSChuc2V0LCAmc2V0LT5jc19jaGlsZHJ=
l
biwgY3Nfc2libGluZ3MpIAogCQljcHVzZXRfdXBkYXRlKG5zZXQsICZzZXQtPmNzX21hc2spOwo=
g
CkBAIC03NjQsOCArNzY4LDI5IEBACiAJCXBhbmljKCJDYW4ndCBzZXQgaW5pdGlhbCBjcHVzZXQ=
g
bWFzay5cbiIpOwogCWNwdXNldF96ZXJvLT5jc19mbGFncyB8PSBDUFVfU0VUX1JET05MWTsKIH0=
K
LVNZU0lOSVQoY3B1c2V0LCBTSV9TVUJfU01QLCBTSV9PUkRFUl9BTlksIGNwdXNldF9pbml0LCB=
O
VUxMKTsKK1NZU0lOSVQoY3B1c2V0LCBTSV9TVUJfU01QLCBTSV9PUkRFUl9NSURETEUsIGNwdXN=
l
dF9pbml0LCBOVUxMKTsKIAoraW50CitjcHVzZXRfemVyb19tb2RpZnkoY3B1c2V0X3QgKm1hc2s=
p
Cit7CisJaW50IGVycjsKKworCW10eF9sb2NrX3NwaW4oJmNwdXNldF9sb2NrKTsKKwljcHVzZXR=
f
emVyby0+Y3NfZmxhZ3MgJj0gfkNQVV9TRVRfUkRPTkxZOworI2lmIDEKKwlwcmludGYoIiVzICh=
i
ZWZvcmUpOiBjcHVzZXRfemVybzogJWxkLCBtYXNrOiAlbGRcbiIsIF9fZnVuY19fLAorCSAgICB=
j
cHVzZXRfemVyby0+Y3NfbWFzay5fX2JpdHNbMF0sIG1hc2stPl9fYml0c1swXSk7CisjZW5kaWY=
K
KwllcnIgPSBjcHVzZXRfbW9kaWZ5KGNwdXNldF96ZXJvLCBtYXNrKTsKKyNpZiAxCisJcHJpbnR=
m
KCIlcyAoYWZ0ZXIpOiBjcHVzZXRfemVybzogJWxkLCBtYXNrOiAlbGRcbiIsIF9fZnVuY19fLAo=
r
CSAgICBjcHVzZXRfemVyby0+Y3NfbWFzay5fX2JpdHNbMF0sIG1hc2stPl9fYml0c1swXSk7Cis=
j
ZW5kaWYKKwljcHVzZXRfemVyby0+Y3NfZmxhZ3MgfD0gQ1BVX1NFVF9SRE9OTFk7CisJbXR4X3V=
u
bG9ja19zcGluKCZjcHVzZXRfbG9jayk7CisJcmV0dXJuIChlcnIpOworfQorCiAjaWZuZGVmIF9=
T
WVNfU1lTUFJPVE9fSF8KIHN0cnVjdCBjcHVzZXRfYXJncyB7CiAJY3B1c2V0aWRfdAkqc2V0aWQ=
7
CkluZGV4OiBzeXMvc3lzL2NwdXNldC5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0=
9
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9zeXMvY3B1c2V0Lmg=
J
KHJldmlzaW9uIDIxNTQxNykKKysrIHN5cy9zeXMvY3B1c2V0LmgJKHdvcmtpbmcgY29weSkKQEA=
g
LTU0LDYgKzU0LDcgQEAKICNkZWZpbmUJQ1BVX0NPUFkoZiwgdCkJKHZvaWQpKCoodCkgPSAqKGY=
p
KQogI2RlZmluZQlDUFVfSVNTRVQobiwgcCkJKCgocCktPl9fYml0c1sobikvX05DUFVCSVRTXSA=
m
IF9fY3B1c2V0X21hc2sobikpICE9IDApCiAjZGVmaW5lCUNQVV9TRVQobiwgcCkJKChwKS0+X19=
i
aXRzWyhuKS9fTkNQVUJJVFNdIHw9IF9fY3B1c2V0X21hc2sobikpCisjZGVmaW5lCUNQVV9TRVR=
N
QVNLKG1hc2ssIHApCSgocCktPl9fYml0c1swXSA9IChtYXNrKSkKICNkZWZpbmUJQ1BVX1pFUk8=
o
cCkgZG8gewkJCQlcCiAJX19zaXplX3QgX19pOwkJCQkJXAogCWZvciAoX19pID0gMDsgX19pIDw=
g
X05DUFVXT1JEUzsgX19pKyspCQlcCkBAIC0xNzgsNiArMTc5LDcgQEAKIHN0cnVjdCBwcmlzb24=
7
CiBzdHJ1Y3QgcHJvYzsKIAoraW50CWNwdXNldF96ZXJvX21vZGlmeShjcHVzZXRfdCAqbWFzayk=
7
CiBzdHJ1Y3QgY3B1c2V0ICpjcHVzZXRfdGhyZWFkMCh2b2lkKTsKIHN0cnVjdCBjcHVzZXQgKmN=
w
dXNldF9yZWYoc3RydWN0IGNwdXNldCAqKTsKIHZvaWQJY3B1c2V0X3JlbChzdHJ1Y3QgY3B1c2V=
0
ICopOwo=3D
--0016e6567d28366ef604955f1e9a--
------------------------------
Message: 18
Date: Fri, 19 Nov 2010 09:10:12 GMT
From: Andriy Gapon <avg@freebsd.org<mailto:avg@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.oAJ9AC2P091673@freefall.freebsd.org<mailto:201011=
190910.oAJ9AC2P091673@freefall.freebsd.org>>
The following reply was made to PR kern/145385; it has been noted by GNATS.
From: Andriy Gapon <avg@freebsd.org<mailto:avg@freebsd.org>>
To: bug-followup@freebsd.org<mailto:bug-followup@freebsd.org>, gcooper@free=
bsd.org<mailto:gcooper@freebsd.org>
Cc:
Subject: Re: kern/145385: [cpu] Logical processor cannot be disabled for so=
me
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-unsubscribe@freebsd.org<mail=
to:freebsd-bugs-unsubscribe@freebsd.org>"
End of freebsd-bugs Digest, Vol 399, Issue 9
********************************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?65FAAFC8-D3CD-4DDB-966A-125940FDC06B>