I noticed on a FreeBSD list that there is one model which cannot
use the firmware patching we do.
While at it, I noticed a few other issues with the firmware handling.
- After a suspend/resume cycle, firmware re-installation was not
being done
- If the firmware file is missing on the first init
Can I extend this panic message a bit. Just a copy of the one above.
It helped me a lot while I was debugging signed vs. unsigned issues in
AML part of the tree.
Index: kern/kern_malloc.c
===
RCS file: /cvs/src/sys/kern/kern_malloc.
After the report from a few weeks ago I went ahead and fixed most (if
not all) of the signed integer usages in the AML parser.
Please have a look at this diff, test it thoroughly and comment/okay it.
Index: dev/acpi/amltypes.h
===
RC
Very informative. Thanks.
- Original message -
From: Steffen Daode Nurpmeso
To: Yarin
Cc: tech@openbsd.org
Subject: Re: mbstowcs() null termination
Date: Fri, 30 Mar 2012 18:59:56 +0200
Hi,
Yarin wrote [2012-03-30 17:01+0200]:
> Hello,
>
> Is mbstowcs() suppose to null-terminate? I as
Hi,
Yarin wrote [2012-03-30 17:01+0200]:
> Hello,
>
> Is mbstowcs() suppose to null-terminate? I ask because, on OpenBSD 4.9
> (generic, no patches), it never null terminates.
> Even though the C90 draft seems to imply that it should when there's enough
> room.
>
> http://www.open-std.org/jtc1
Hello,
Is mbstowcs() suppose to null-terminate? I ask because, on OpenBSD 4.9
(generic, no patches), it never null terminates.
Even though the C90 draft seems to imply that it should when there's enough
room.
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n869/
I'm unsure of the expected beha
