Le 01/12/2012 22:31, Philip Guenther a écrit :
> Neither. The OpenBSD developers think that that's a useless** warning
> and aren't interested in making the system header files that much
> harder to read just to make it go away.
>
> What problem are you trying to solve by using -Wredundant-decls?
Hi,
I have the file test.cpp, containingonly:
#include
int main()
{
}
Icompile it with
$ g++ -Wredundant-decls -o test test.cpp
And I get
In file included from
/usr/include/g++/amd64-unknown-openbsd5.2/bits/gthr-default.h:44,
from
/usr/include/g++/amd64-unknown
Le 24/11/2012 02:21, Nigel Taylor a écrit :
> Your audio is being picked up already as 6670, audio was added together
> with the video for a 6670 card. There maybe a range of cards that use
> the same id for audio.
>
> To recreate the includes.
> cd /usr/src/sys/dev/pci
> make
>
> Now follow inst
Le 23/11/2012 21:44, Nigel Taylor a écrit :
> On 11/23/12 16:56, rustyBSD wrote:
>> Le 23/11/2012 17:35, Nigel Taylor a écrit :
>>> That is not a REDWOOD chip, it's TURKS, and both should be supported,
>>
>> Ahh yes I didn't see this in xorg.0.log
>&
Le 23/11/2012 17:35, Nigel Taylor a écrit :
> That is not a REDWOOD chip, it's TURKS, and both should be supported,
Ahh yes I didn't see this in xorg.0.log
> the man page is wrong 6570 occurs both under REDWOOD and TURKS.
> REDWOOD are 5x50 series. Could still be in the wrong chip family.
>
> Th
Hi,
I have an ATI Radeon HD6570 card. Dmesg gives me:
vga1 at pci1 dev 0 function 0 vendor "ATI", unknown product 0x6759 rev 0x00
and the driver used seems to be VESA.
I naturally changed to:
--- src/sys/dev/pci/pcidevs 2012-11-17 16:42:29.0 +0100
+++ src/sys/dev/pci/pcidevs 2012-
Hi,
is there a wayto useauth_userokay()without setgid
to "auth" ?
When testing this code:
#include
#include
#include
#include
#include
int main()
{
printf("authentication ");
char *user = strdup("me");
char *pass = strdup("pass");
if (!auth_userokay(user, NULL, "auth-mytes
Le 30/10/2012 09:19, Remco a écrit :
> AFAICT these dmesg lines tell me the possible frequency settings of my CPU:
>
> $ dmesg |grep acpicpu
> acpicpu0 at acpi0: FVS, 2400, 1600 MHz
> acpicpu1 at acpi0: FVS, 2400, 1600 MHz
It doesn't give me the frequency.
> Is that what you're after ?
In fact, I
Hi,
that's maybe a stupid question, but how can I get the max frequency of
my cpu ?
I saw sysctl has hw.cpuspeed and hw.setperf, but can I get the maximum
frequency
without setting setperf to 100%, getting cpuspeed and then restoring
setperf to
the value it has before ?
Thanks !
Le 07/10/2012 14:58, rustyBSD a écrit :
> On 10/07/12 13:41, Theo de Raadt wrote:
>> If you type "unbound" into google, you will see that
>> this is upstream code that is incorporated into OpenBSD.
>>
>> Therefore, you should really contact that project.
> A
On 10/07/12 13:41, Theo de Raadt wrote:
> If you type "unbound" into google, you will see that
> this is upstream code that is incorporated into OpenBSD.
>
> Therefore, you should really contact that project.
Already done
Hi,
it's about src/usr.sbin/unbound/ldns/drill/work.c
at line 184:
What is the 'fp' FILE used for ? Here - if I'm not
mistaken - we fopen() filename, and that's it. We
don't use the 'fp' variable, and we never fclose()
it.
Am I wrong ?
Thanks
Le 03/09/2012 22:22, Otto Moerbeek a écrit :
> On Mon, Sep 03, 2012 at 05:19:44PM +0200, Otto Moerbeek wrote:
>
>> On Mon, Sep 03, 2012 at 04:37:42PM +0200, rustyBSD wrote:
>>
>>> /usr/src/sbin/disklabel/disklabel.c
>>> lines: 333 & 1092 & 1096
>>
Le 03/09/2012 16:46, bert a écrit :
> On Mon, Sep 03, 2012 at 04:37:42PM +0200, rustyBSD wrote:
>> /usr/src/sbin/disklabel/disklabel.c
>> lines: 333 & 1092 & 1096
>>
>> Is this me, or these strncpy() may cause off-by-one
>> overflows ?
No i'm wrong,
/usr/src/sbin/disklabel/disklabel.c
lines: 333 & 1092 & 1096
Is this me, or these strncpy() may cause off-by-one
overflows ?
In an use like this:
strncpy(a, b, sizeof(a));
the null terminator will be added beyond the end of
a if b has the same size (or a larger size).
Should use something lik
Le 02/09/2012 20:36, Otto Moerbeek a écrit :
> Confusing errno and exit code. Just use 1. Or err(1, NULL). The
> default message is clear enough.
I use errno because most of other calls to err() in this
file use errno too.
Le 02/09/2012 16:06, rustyBSD a écrit :
> [demime 1.01d removed an attachment of type text/x-patch which had a name of
> scsi.c.diff]
Mmhhh...
--- scsi.cSun Sep 2 15:47:45 2012
+++ scsi.cSun Sep 2 16:00:42 2012
@@ -223,6 +223,7 @@
case 'z':
{
Le 02/09/2012 14:57, Alexander Hall a écrit :
> Whoever it is, I'm sure he or she appreciate diffs anyway!
Ok, here is one.
[demime 1.01d removed an attachment of type text/x-patch which had a name of
scsi.c.diff]
Le 01/09/2012 19:59, Kenneth R Westerback a écrit :
> On Sat, Sep 01, 2012 at 07:19:25PM +0200, rustyBSD wrote:
>> Hi,
>> in /usr/src/sbin/scsi/scsi.c line 225, why
>> is the malloc not checked ? ... If it fails,
>> it overflows, no ?
>>
> Crufty old code. Feel
Hi,
in /usr/src/sbin/scsi/scsi.c line 225, why
is the malloc not checked ? ... If it fails,
it overflows, no ?
Le 20/07/2012 11:12, Wojciech Puchar a écrit :
> Many today SSD and some magnetic disks have AES-128/256 encryption
> builtin.
>
> If BIOS supports it, it ask for password then send it to hard disk
> after which it decodes it's AES key so it start to work.
>
> No software crypto overhead, everythin
Le 05/07/2012 17:06, Daniel Bolgheroni a écrit :
> On Thu, Jul 05, 2012 at 04:33:37PM +0200, rustyBSD wrote:
>> Fine ? How could I know ? I get "operation not supported by device" when
>> trying to read smart infos with smartctl.
>> In all cases, even if my disk
Le 05/07/2012 16:13, Daniel Bolgheroni a écrit :
> On Thu, Jul 05, 2012 at 03:28:06PM +0200, rustyBSD wrote:
>> Question: should I report a bug ?
> Are you sure your disk is fine?
>
>
Fine ? How could I know ? I get "operation not supported by device" when
trying to re
Hi,
When I download from my OpenBSD server a lot of files with sftp, it
crashes with Kernel Panic (disk error). I tested two times, and two
times it crashed. I get a message telling: "panic: kernel diagnostic
assertion "ccb->ccb_xa.state == ATA_S_ONCHIP" failed:
file "../../../../dev/pci/ahci.c", l
24 matches
Mail list logo
