~~~
09 - 10 PQP3P0P=P8P7P0QP8P>P=P=Q P5 P8 P?QP0P2P>P2Q P5 P2P>P?QP>QQ QP0P1P>QQ
Q P4P>P;P3P0PPP2P>P4P8QP5P;P8
P:P>PPQP0,
QQP:P>P2P>P4P8QP5P;P8 QP8P=P0P=QP>P2Q Q P>QP4P5P;P>P2,
QQP:P>P2P>P4P8QP5P;P8 P>QP4P5P;P>P2 P?QP>P4P0P6, Q
Dear customers,
Nowadays, PDF has become one of the most popular formats for
international document exchange. Its innovation permits users to control
sharing and distribution of PDF files better than ever before! We
understand that you need full control to view, edit, share and print PDF
files whi
Federico G. Schwindt wrote:
> On Mon, Mar 01, 2010 at 06:40:03PM +, Federico G. Schwindt wrote:
>> On Mon, Mar 01, 2010 at 07:21:06PM +0100, Peter Haag wrote:
>>> Hi list,
>>> I just noticed, that setting a socket read timeout:
>>>
>>> setsockopt(client_fd, SOL_SOCKET, SO_RCVTIMEO, (void *)&tv,
Tobias Weingartner wrote:
> So, if you think this is something that should go in, then I'd
> implore you to get more testing and test reports. I'd be wanting
> all the MB/BIOS/cpu combinations that were tested before this is
> committed.
Testing a high number of MB/BIOS/cpu requires a lot of time
On Mon, Mar 01, 2010 at 06:40:03PM +, Federico G. Schwindt wrote:
> On Mon, Mar 01, 2010 at 07:21:06PM +0100, Peter Haag wrote:
> > Hi list,
> > I just noticed, that setting a socket read timeout:
> >
> > setsockopt(client_fd, SOL_SOCKET, SO_RCVTIMEO, (void *)&tv, sizeof(struct
> > timeval))
On Mon, Mar 01, 2010 at 07:21:06PM +0100, Peter Haag wrote:
> Hi list,
> I just noticed, that setting a socket read timeout:
>
> setsockopt(client_fd, SOL_SOCKET, SO_RCVTIMEO, (void *)&tv, sizeof(struct
> timeval))
>
> does not have any effect, if the program is linked with -pthread.
> I haven't
Hi list,
I just noticed, that setting a socket read timeout:
setsockopt(client_fd, SOL_SOCKET, SO_RCVTIMEO, (void *)&tv, sizeof(struct
timeval))
does not have any effect, if the program is linked with -pthread.
I haven't found anything in a man page or FAQ. Is this a bug or is there an
explanat
On Monday, March 1, Giuseppe Magnotta wrote:
>
> My question is, if this functionality is available in the BIOS, why
> can't we use it?
The problem is having a broken BIOS out there that simply hangs
because you're calling something that it does not support. When
this stuff was written, there we
On Mon, 01 Mar 2010 18:51:31 +0100
Giuseppe Magnotta wrote:
>
> My question is, if this functionality is available in the BIOS, why
> can't we use it?
>
I'm just jumping in here, but I think the obvious answer is; if it
is not needed on any existing platform, what purpose does it serve?
Tobias Weingartner wrote:
> While I applaud your efforts to send in patches, I do have a
> small niggle. Why do you feel the need to splatter your
> authorship all over the code in comments? Why not just add
> your name to the copyright statement and be done with it?
Yes, You're right.
It may se
On Mon, Mar 01, 2010 at 10:58 -0600, Marco Peereboom wrote:
> This is fine but how will you deal with dynamic disks?
>
for now there's no code to deal with them anyway.
also there will never be as much as max_devices pieces attached,
that's just a theoretical possibility.
> That's the diff I sti
On Monday, March 1, Giuseppe Magnotta wrote:
>
> +/*
> + * Author: Giuseppe Magnotta
While I applaud your efforts to send in patches, I do have a
small niggle. Why do you feel the need to splatter your
authorship all over the code in comments? Why not just add
your name to the copyright statem
This is fine but how will you deal with dynamic disks?
That's the diff I still have in my mail from you...
On Mon, Mar 01, 2010 at 07:52:33PM +0300, Mike Belopuhov wrote:
> On Tue, Feb 09, 2010 at 19:48 +0300, Mike Belopuhov wrote:
> > On Tue, Feb 09, 2010 at 10:41 -0600, Marco Peereboom wrote:
>
On Tue, Feb 09, 2010 at 19:48 +0300, Mike Belopuhov wrote:
> On Tue, Feb 09, 2010 at 10:41 -0600, Marco Peereboom wrote:
> > I talked to Jim and he and I had exactly the same comments. We love
> > this minus the numbers you pull out of an orifice ;-)
> >
> > To be exact:
> > > - sc->sc_reply_post
Ted Unangst wrote:
> Can you explain this? I'd think A20 issues would have been sorted out
> 15 years ago.
Hi,
reading gateA20.c code, I've found that only two methods for enabling
the A20 line were used: the fast gate that use the I/O port 0x92 and the
"classic" one that use the keyboard contro
On Mon, Mar 1, 2010 at 10:15 AM, Giuseppe Magnotta
wrote:
> Sorry,
>
> it seems that the patch was not included in my last email.
>
> Here is the patch:
>
> Index: gateA20.c
Can you explain this? I'd think A20 issues would have been sorted out
15 years ago.
Sorry,
it seems that the patch was not included in my last email.
Here is the patch:
Index: gateA20.c
===
RCS file: /cvs/src/sys/arch/i386/stand/libsa/gateA20.c,v
retrieving revision 1.10
diff -u -r1.10 gateA20.c
--- gateA20.c 19
Hello,
please find attached a patch for "boot" that allows it to enable the
gate A20 directly by the BIOS if the INT 15/AX=2401h is supported for
i386 machines.
If you can please test it and tell me if it works as expected.
Regards,
Giuseppe.
[demime 1.01d removed an attachment of type text/
GARLEX | SARIMSAK OZLU SAMPUAN
^ampuanlar}n esas kullan}m amac} saglar}n temizlenmesidir. Garlex sar}msak
~ampuan} ise bu vzellipinin yan} s}ra; sag, sag kvk| ve sag derisini
derinlemesine besleyecek, sac hucrelerini guclendirecek ve yenileyecek, zengin
bitki igeripine sahiptir.
GARLEX sarimsak sa
Newsletter Information
20 matches
Mail list logo
