alexander wrote:
However burncd being a C app uses fprintf. Can I replace
the functionality of fprintf under x86asm by using only syscalls?
fprintf(3) is most likely doing buffered I/O in the burncd case, which
for a tty defaults to line buffered.
Your code is doing unbuffered I/O, which might
Hi,
I've run into a brick wall on this one, so I thought perhaps someone might
point me in a new direction.
I have a mailserver that uses Maildir++, which means there's built-in
(non-system) quotas. The one problem that I'm having is that the file
that stores the current quota information (
On Sun, 2005-May-22 00:09:35 +0200, alexander wrote:
>On Sun May 22 05, Peter Jeremy wrote:
>>
>> Can you please confirm that you also see the problem when you are using
>> xterm (not Eterm). Can you also please advise what versions of FreeBSD,
>> X11 and xterm/Eterm you are using.
>
>OK. Seems l
On Sun May 22 05, Peter Jeremy wrote:
>
> Can you please confirm that you also see the problem when you are using
> xterm (not Eterm). Can you also please advise what versions of FreeBSD,
> X11 and xterm/Eterm you are using.
>
OK. Seems like you somehow knew what was going on here. The problem
On Sat, 2005-May-21 16:58:07 +0200, alexander wrote:
>On Sat May 21 05, Peter Jeremy wrote:
>>
>> I think you need to give us more details and preferably some sample code
>> to simulate the problem. What is the hardware you are running on? What
>> version of FreeBSD, X11 and xterm/Eterm.
...
>Th
John-Mark Gurney wrote:
Hans Petter Selasky wrote this message on Sat, May 21, 2005 at 15:46 +0200:
On Saturday 21 May 2005 00:49, Peter Jeremy wrote:
On Fri, 2005-May-20 21:51:34 +0200, Hans Petter Selasky wrote:
Non-blocking mode has got to be supported. Else you get a nightmare
rewritin
Hans Petter Selasky wrote this message on Sat, May 21, 2005 at 15:46 +0200:
> On Saturday 21 May 2005 00:49, Peter Jeremy wrote:
> > On Fri, 2005-May-20 21:51:34 +0200, Hans Petter Selasky wrote:
> > >Non-blocking mode has got to be supported. Else you get a nightmare
> > > rewriting the code to su
Le Vendredi 20 mai 2005 à 12:52 -0400, Larry Baird a écrit :
> Walter,
>
> > Are you sure about that?
> Yes and no. I am sure that I have working code. I just realized that
> when I ported my patch to 5.4 I missed one thing. The following patch
> should work muxh better for you. (-:
No
On May 20, 2005, at 18:31, Dag-Erling Smørgrav wrote:
>> . Anyway, I wanted to locate the problem and do something about
>> it (aka submit an useful coredump to this list :-) but unfortunately
>> neither gdb nor kgdb seem to work for me.
>>
>
> Well, thank you for trying! In the meantime, cou
On Sat May 21 05, Peter Jeremy wrote:
>
> I think you need to give us more details and preferably some sample code
> to simulate the problem. What is the hardware you are running on? What
> version of FreeBSD, X11 and xterm/Eterm.
>
> --
> Peter Jeremy
Here's the code that is using the VT100
On Saturday 21 May 2005 00:49, Peter Jeremy wrote:
> On Fri, 2005-May-20 21:51:34 +0200, Hans Petter Selasky wrote:
> >Non-blocking mode has got to be supported. Else you get a nightmare
> > rewriting the code to support blocking mode.
>
> Your code either has to block somewhere or fail. contigmal
(i already sent an email to Eric some days ago but i
didn't receive any ack so i try here...)
can anyone take a look at this?
as the comments say, agp still doesn't
work...
anything i can do to help?
Eric?
verbose boot:
FreeBSD 5.4-RELEASE #0: Sun May 8 10:21:06 UTC 2005
[EMAIL PROTECTED
Walter,
> Are you sure about that?
Yes and no. I am sure that I have working code. I just realized that
when I ported my patch to 5.4 I missed one thing. The following patch
should work muxh better for you. (-:
Larry
--- geode.c.origFri May 20 09:41:06 2005
+++ geode.c Fri May 20
Larry Baird writes:
> In article <[EMAIL PROTECTED]> you wrote:
> > Reading geode.c it appears (at least to me) that the led devices are
> > created for the WRAP.1C but not for the WRAP.1E.
> >
> > Reading the PC-Engines documentation it looks to me as WRAP.1C and
> > WRAP1.E were identical
Larry Baird writes:
> In article <[EMAIL PROTECTED]> you wrote:
> > Reading geode.c it appears (at least to me) that the led devices are
> > created for the WRAP.1C but not for the WRAP.1E.
> >
> > Reading the PC-Engines documentation it looks to me as WRAP.1C and
> > WRAP1.E were identical
In article <[EMAIL PROTECTED]> you wrote:
> Reading geode.c it appears (at least to me) that the led devices are
> created for the WRAP.1C but not for the WRAP.1E.
>
> Reading the PC-Engines documentation it looks to me as WRAP.1C and
> WRAP1.E were identical when it comes to the LEDs, thus it wou
you'll have to fiddel with src/sys/i386/i386/geode.c
look for
bios_string(0xf9000, 0xf9000, "PC Engines WRAP.1C "
and you will see why.
this patch should work:
--- 5.3/src/sys/i386/i386/geode.c Sun Nov 21 16:01:04 2004
+++ 5.4/src/sys/i386/i386/geode.c Wed Jun 16 12:47:07 2004
In order to implement a dispacthing policy I want to get the status of cpu. I
have read the code of top command and i find it get the status of cpu by the
function :
int sysctlbyname(const char *, void *, size_t *, void *, size_t);
I search the code of kernel ,then I consider that i can get
On Sat, 2005-May-21 03:51:05 +0200, alexander wrote:
>Ohh...sorry for not telling you this. Yes. The app works alright when
>executed from the console. But my problem is with xterm or Eterm. They don't
>handle VT100 very well.
By default, xterm is a VT102 superset, and the VT102 is a VT100 superse
19 matches
Mail list logo
