Re: SCHED_ASSERT_UNLOCKED is considered harmful in the _kernel_lock()
On Mon, Nov 8, 2010 at 1:01 AM, Philip Guenther guent...@gmail.com wrote:
On Sunday, November 7, 2010, Mark Kettenis mark.kette...@xs4all.nl wrote:
Date: Fri, 5 Nov 2010 17:52:23 +0100
From: Mike Belopuhov m...@crypt.org.ru
Mike, you might want to take a look at PR 6508. I think the
sched_lock panic:
ddb{0} show panic
kernel diagnostic assertion __mp_lock_held(sched_lock) == 0 failed:
is actually a side effect of trapping in the middle of a context
switch when we're doing the sched_lock/kernel_lock dance. In PR 6508
it is almost certainly a page fault that happened because we
overflowed the stack. That also might be the cause of your panic. At
least judging from the traceback, your stack is seriously hosed:
Since i386 and amd64 put the lernel stack above the PCB, stack overrun
means the PCB has already been overwritten. At that point, trying to
save the process context will probably blow up trying to follow some
pointer therein.
I had chatted some with Theo about putting a guard page below the
kernel stack to catch this sort of thing. Would want to move the PCB
to above the stack at the same time to save most of a page. Would the
result help isolate these problems enough to be worth the effort?
indeed. most of the time you don't get a nice stack trace as in the
pr 6508. most of the time these panics are not reproducible. so i
see a real value in having this sort of early detection.
Philip Guenther
Re: SCHED_ASSERT_UNLOCKED is considered harmful in the _kernel_lock()
Date: Sun, 7 Nov 2010 16:01:05 -0800
From: Philip Guenther guent...@gmail.com
On Sunday, November 7, 2010, Mark Kettenis mark.kette...@xs4all.nl wrote:
Date: Fri, 5 Nov 2010 17:52:23 +0100
From: Mike Belopuhov m...@crypt.org.ru
Mike, you might want to take a look at PR 6508. I think the
sched_lock panic:
ddb{0} show panic
kernel diagnostic assertion __mp_lock_held(sched_lock) == 0 failed:
is actually a side effect of trapping in the middle of a context
switch when we're doing the sched_lock/kernel_lock dance. In PR 6508
it is almost certainly a page fault that happened because we
overflowed the stack. That also might be the cause of your panic. At
least judging from the traceback, your stack is seriously hosed:
Since i386 and amd64 put the lernel stack above the PCB, stack overrun
means the PCB has already been overwritten. At that point, trying to
save the process context will probably blow up trying to follow some
pointer therein.
I had chatted some with Theo about putting a guard page below the
kernel stack to catch this sort of thing. Would want to move the PCB
to above the stack at the same time to save most of a page. Would the
result help isolate these problems enough to be worth the effort?
If you're considering changing the way we allocate the PCB, we should
look into moving it off the stack altogether and allocate them from a
pool. That would make life simpler on hppa, since pools are mapped
1:1 which means issues with non-equivalent aliases go away.
aesni_ctr_enc: accept a complete ICB rather than IV
hi,
i need to change aesni_ctr_enc a bit to pass an already constructed
initial counter block (ICB) rather than do it in the function itself.
this will allow me to share the code with aes-gcm.
if i won't hear any objections, i'll commit this on wednesday.
works for me without issues.
Index: aes_intel.S
===
RCS file: /home/cvs/src/sys/arch/amd64/amd64/aes_intel.S,v
retrieving revision 1.2
diff -u -p -r1.2 aes_intel.S
--- aes_intel.S 22 Jul 2010 12:47:40 - 1.2
+++ aes_intel.S 5 Nov 2010 16:04:34 -
@@ -66,13 +66,13 @@
#define BSWAP_MASK %xmm10
#define CTR%xmm11
#define INC%xmm12
-#define NONCE %xmm13
#define KEYP %rdi
#define OUTP %rsi
#define INP%rdx
#define LEN%rcx
#define IVP%r8
+#define ICBP %r8
#define KLEN %r9d
#define T1 %r10
#define TKEYP T1
@@ -772,22 +772,22 @@ ENTRY(aesni_cbc_dec)
* _aesni_inc_init:internal ABI
* setup registers used by _aesni_inc
* input:
- * IV
+ * ICB
* output:
- * CTR:== IV, in little endian
+ * CTR:== CTR, in little endian
+ * IV: == IV, in big endian
* TCTR_LOW: == lower dword of CTR
* INC:== 1, in little endian
* BSWAP_MASK == endian swapping mask
*/
_aesni_inc_init:
- movaps .Lbswap_mask, BSWAP_MASK
- movaps IV, CTR
- pslldq $4, CTR
- por NONCE, CTR
- pshufb BSWAP_MASK, CTR
- mov $1, TCTR_LOW
- movd TCTR_LOW, INC
- movd CTR, TCTR_LOW
+ movdqa CTR, IV
+ pslldq $8, IV
+ movdqa .Lbswap_mask, BSWAP_MASK
+ pshufb BSWAP_MASK, CTR
+ mov $1, TCTR_LOW
+ movdTCTR_LOW, INC
+ movdCTR, TCTR_LOW
ret
/*
@@ -819,14 +819,13 @@ _aesni_inc:
/*
* void aesni_ctr_enc(struct aesni_sess *ses, uint8_t *dst, uint8_t *src,
- * size_t len, uint8_t *iv)
+ * size_t len, uint8_t *icb)
*/
ENTRY(aesni_ctr_enc)
cmp $16, LEN
jb .Lctr_enc_just_ret
mov 480(KEYP), KLEN
- movd 484(KEYP), NONCE
- movq (IVP), IV
+ movdqu (ICBP), CTR
call _aesni_inc_init
cmp $64, LEN
jb .Lctr_enc_loop1
Index: aesni.c
===
RCS file: /home/cvs/src/sys/arch/amd64/amd64/aesni.c,v
retrieving revision 1.9
diff -u -p -r1.9 aesni.c
--- aesni.c 7 Sep 2010 15:51:00 - 1.9
+++ aesni.c 8 Nov 2010 10:13:00 -
@@ -77,7 +77,7 @@ extern void aesni_cbc_dec(struct aesni_s
/* assembler-assisted CTR mode */
extern void aesni_ctr_enc(struct aesni_sess *ses, uint8_t *dst,
- uint8_t *src, size_t len, uint8_t *iv);
+ uint8_t *src, size_t len, uint8_t *icb);
void aesni_setup(void);
intaesni_newsession(u_int32_t *, struct cryptoini *);
@@ -314,6 +314,7 @@ aesni_encdec(struct cryptop *crp, struct
struct aesni_sess *ses)
{
uint8_t iv[EALG_MAX_BLOCK_LEN];
+ uint8_t icb[EALG_MAX_BLOCK_LEN];
uint8_t *buf = aesni_sc-sc_buf;
int ivlen = 0;
int err = 0;
@@ -396,7 +397,10 @@ aesni_encdec(struct cryptop *crp, struct
else
aesni_cbc_dec(ses, buf, buf, crd-crd_len, iv);
} else if (crd-crd_alg == CRYPTO_AES_CTR) {
- aesni_ctr_enc(ses, buf, buf, crd-crd_len, iv);
+ bzero(icb, sizeof(icb));
+ bcopy(ses-ses_nonce, icb, AESCTR_NONCESIZE);
+ bcopy(iv, icb + AESCTR_NONCESIZE, AESCTR_IVSIZE);
+ aesni_ctr_enc(ses, buf, buf, crd-crd_len, icb);
}
fpu_kernel_exit();
MID_AMD64 is missing in the byte order check code in nm(1)
we didn't hit it before because it's used only in the unusual situation.
ok to commit?
Index: byte.c
===
RCS file: /home/cvs/src/usr.bin/nm/byte.c,v
retrieving revision 1.6
diff -u -p -U5 -r1.6 byte.c
--- byte.c 9 Oct 2004 20:26:57 - 1.6
+++ byte.c 8 Nov 2010 13:20:57 -
@@ -16,10 +16,11 @@
*/
static int
byte_sex(int mid)
{
switch (mid) {
+ case MID_AMD64:
case MID_I386:
case MID_VAX:
case MID_ALPHA:
case MID_PMAX:
return LITTLE_ENDIAN;
Re: MID_AMD64 is missing in the byte order check code in nm(1)
Date: Mon, 8 Nov 2010 14:57:03 +0100 From: Mike Belopuhov m...@crypt.org.ru we didn't hit it before because it's used only in the unusual situation. Which unusual situation? There really shouldn't be any a.out amd64 binaries or object modules out there.
Re: MID_AMD64 is missing in the byte order check code in nm(1)
On Mon, Nov 8, 2010 at 3:07 PM, Mark Kettenis mark.kette...@xs4all.nl wrote: Date: Mon, 8 Nov 2010 14:57:03 +0100 From: Mike Belopuhov m...@crypt.org.ru we didn't hit it before because it's used only in the unusual situation. Which unusual situation? There really shouldn't be any a.out amd64 binaries or object modules out there. that's quite unusual (: but if you say we don't need it, then i'll just throw away this M from my tree.
Add Xbox 360 Controller USB support
This is taken pretty much straight from FreeBSD ( see
http://marc.info/?l=freebsd-commits-allm=113600388101707w=2 ). It is
tested and working on my amd64 box. Some usbhidctl output:
Generic_Desktop:Game_Pad.Generic_Desktop:Pointer.Generic_Desktop:D-pad_Up=0
Generic_Desktop:Game_Pad.Generic_Desktop:Pointer.Generic_Desktop:D-pad_Down=0
Generic_Desktop:Game_Pad.Generic_Desktop:Pointer.Generic_Desktop:D-pad_Left=0
Generic_Desktop:Game_Pad.Generic_Desktop:Pointer.Generic_Desktop:D-pad_Right=0
Generic_Desktop:Game_Pad.Button:Button_8=0
Generic_Desktop:Game_Pad.Button:Button_7=0
Generic_Desktop:Game_Pad.Button:Button_9=0
Generic_Desktop:Game_Pad.Button:Button_10=0
Generic_Desktop:Game_Pad.Button:Button_5=0
Generic_Desktop:Game_Pad.Button:Button_6=0
Generic_Desktop:Game_Pad.Button:Button_11=0
Generic_Desktop:Game_Pad.Button:Button_1=1
Generic_Desktop:Game_Pad.Button:Button_2=0
Generic_Desktop:Game_Pad.Button:Button_3=0
Generic_Desktop:Game_Pad.Button:Button_4=0
Generic_Desktop:Game_Pad.Generic_Desktop:Z=0
Generic_Desktop:Game_Pad.Generic_Desktop:Rz=0
Generic_Desktop:Game_Pad.Generic_Desktop:X=-4169
Generic_Desktop:Game_Pad.Generic_Desktop:Y=-2390
Generic_Desktop:Game_Pad.Generic_Desktop:Rx=-432
Generic_Desktop:Game_Pad.Generic_Desktop:Ry=1363
Any devs interested in reviewing and hopefully committing this?
--
Joe Gidi
j...@entropicblur.com
You cannot buy skill. -- Ross Seyfried
--- uhidev.c.orig Mon Nov 8 01:57:09 2010
+++ uhidev.cMon Nov 8 01:08:30 2010
@@ -55,8 +55,9 @@
#include dev/usb/uhidev.h
-/* Report descriptor for broken Wacom Graphire */
+/* Replacement report descriptors for devices shipped with broken ones */
#include dev/usb/ugraphire_rdesc.h
+#include dev/usb/uxb360gp_rdesc.h
#ifdef UHIDEV_DEBUG
#define DPRINTF(x) do { if (uhidevdebug) printf x; } while (0)
@@ -99,8 +100,15 @@
if (uaa-iface == NULL)
return (UMATCH_NONE);
id = usbd_get_interface_descriptor(uaa-iface);
- if (id == NULL || id-bInterfaceClass != UICLASS_HID)
- return (UMATCH_NONE);
+if (id == NULL)
+return (UMATCH_NONE);
+if (id-bInterfaceClass != UICLASS_HID) {
+/* The Xbox 360 gamepad doesn't use the HID class. */
+if (id-bInterfaceClass != UICLASS_VENDOR ||
+id-bInterfaceSubClass != UISUBCLASS_XBOX360_CONTROLLER ||
+id-bInterfaceProtocol != UIPROTO_XBOX360_GAMEPAD)
+return (UMATCH_NONE);
+}
if (usbd_get_quirks(uaa-device)-uq_flags UQ_BAD_HID)
return (UMATCH_NONE);
if (uaa-matchlvl)
@@ -203,7 +211,14 @@
/* Keep descriptor */
break;
}
+ } else if (id-bInterfaceClass == UICLASS_VENDOR
+ id-bInterfaceSubClass == UISUBCLASS_XBOX360_CONTROLLER
+ id-bInterfaceProtocol == UIPROTO_XBOX360_GAMEPAD) {
+ /* The Xbox 360 gamepad has no report descriptor. */
+ size = sizeof uhid_xb360gp_report_descr;
+ descptr = uhid_xb360gp_report_descr;
}
+
if (descptr) {
desc = malloc(size, M_USBDEV, M_NOWAIT);
--- usb.h.orig Mon Nov 8 01:58:09 2010
+++ usb.h Mon Nov 8 00:42:01 2010
@@ -486,7 +486,8 @@
#define UIPROTO_IRDA 0
#define UICLASS_VENDOR 0xff
-
+#define UISUBCLASS_XBOX360_CONTROLLER 0x5d
+#define UIPROTO_XBOX360_GAMEPAD 0x01
#define USB_HUB_MAX_DEPTH 5
/*-
* Copyright (c) 2005 Ed Schouten e...@freebsd.org
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* $FreeBSD: src/sys/dev/usb/uxb360gp_rdesc.h,v 1.3 2008/05/24 18:35:55 ed Exp $
*/
/*
* The
Re: Add Xbox 360 Controller USB support
On Mon, Nov 8, 2010 at 3:38 PM, Joe Gidi j...@entropicblur.com wrote: This is taken pretty much straight from FreeBSD ( see http://marc.info/?l=freebsd-commits-allm=113600388101707w=2 ). It is tested and working on my amd64 box. Some usbhidctl output: At a minimum, should probably be inside ifdef SMALL_KERNEL or something so as to not expand ramdisks that don't need it.
waitpid not returning 0 when WNOHANG specified ?
Hi,
I must be doing something really silly but it seems waitpid ends up
returning -1 if WNOHANG is specified and there are no children to
reap.
Am I doing something wrong ?
#include sys/types.h
#include sys/wait.h
#include err.h
#include signal.h
#include stdio.h
#include stdlib.h
#include unistd.h
voidreap_children(void);
sig_atomic_t gotchild;
void
childhandler(int signo)
{
gotchild = 1;
}
void
reap_children(void)
{
pid_t pid;
int status;
while ((pid = waitpid(WAIT_ANY, status, WNOHANG)) 0) {
printf(Children %d reaped, terminated on , pid);
if (WIFEXITED(status))
printf(exit(%d), WEXITSTATUS(status));
if (WIFSIGNALED(status))
printf(signal %d, WTERMSIG(status));
printf(\n);
};
if (pid == -1)
err(1, waitpid);
gotchild = 0;
}
int
main(void)
{
pid_t pid;
signal(SIGCHLD, childhandler);
if ((pid = fork()) == -1)
err(1, fork);
if (pid == 0) /* exit child */
exit(1);
if ((pid = fork()) == -1)
err(1, fork);
if (pid == 0) /* exit child */
exit(1);
for (;;) {
if (gotchild)
reap_children();
sleep(1);
}
}
Here is the output:
Children 3318 reaped, terminated on exit(1)
Children 11320 reaped, terminated on exit(1)
waitpid: waitpid: No child processes
Re: waitpid not returning 0 when WNOHANG specified ?
On Mon, Nov 8, 2010 at 4:10 PM, Christiano F. Haesbaert haesba...@haesbaert.org wrote: I must be doing something really silly but it seems waitpid ends up returning -1 if WNOHANG is specified and there are no children to reap. Umm, that's what the standard specifies. Philip Guenther
Todo para Soldar
$498 PesosSoldadora Turbo 270 Bifasica Soldadora Electrica Turbo Ventilada 270 Amper Monosica y Trifasica / Con Protector Teacute;rmico / Amperaje regulable 50 a 260 / Con Ruedas y manija Tipo Carro / Ideal Herreros , Industria , Taller , Obra / Para electrodos de 1.6 a 4 mm. Mascara de Regalo y Cepillo y pinza maza y porta eletrodos $ 290 Pesos Mascara Fotosensible Maacute;scara para soldar termoplaacute;stica / Ventanilla moacute;vil. Vidrio de proteccioacute;n / Cumple con las normas actuales de homologacioacute;n DIN EN 379 (Directiva 89/686/EWG). Soldadora 220 Turbo Lusqtof $ 425 Delantal Descarne Con Placa de Plomo $ 50 Guante Descarne Soldador $ 25
Re: waitpid not returning 0 when WNOHANG specified ?
On 11/09/10 03:27, Philip Guenther wrote: On Mon, Nov 8, 2010 at 4:10 PM, Christiano F. Haesbaert haesba...@haesbaert.org wrote: I must be doing something really silly but it seems waitpid ends up returning -1 if WNOHANG is specified and there are no children to reap. Umm, that's what the standard specifies. waitpid(2), RETURN VALUES Otherwise, if WNOHANG is specified and there are no stopped or exited children, 0 is returned.
