Console output corruption

Console output corruption

[Dieter Kedrowitsch]

Since I've made it past all the building errors I figured I'd start a
new topic for this.

I'm building elks 0.1.3 using mostly the default configuration except
for choosing PC-XT and 8088.

When I boot ELKS both in a VM and or my actual XT, every time a number
is displayed, it is displayed as a 32 digit integer with every digit
prior to the number being a zero.

So for example 3 is displayed as 00000000000000000000000000000003.

I am choosing the default of 'Direct' for the console.

Has anyone else dealt with this or could anyone offer some advice on
where to look to fix this?

Re: Console output corruption

[Hans]

----- Original Message ----- 
From: "Dieter Kedrowitsch" <dieter.kedrowitsch@gmail.com>
To: <linux-8086@vger.kernel.org>
Sent: Wednesday, March 10, 2010 2:28 PM
Subject: Console output corruption


> Since I've made it past all the building errors I figured I'd start a
> new topic for this.
>
> I'm building elks 0.1.3 using mostly the default configuration except
> for choosing PC-XT and 8088.
>
> When I boot ELKS both in a VM and or my actual XT, every time a number
> is displayed, it is displayed as a 32 digit integer with every digit
> prior to the number being a zero.
>
> So for example 3 is displayed as 00000000000000000000000000000003.
>
> I am choosing the default of 'Direct' for the console.
>
> Has anyone else dealt with this or could anyone offer some advice on
> where to look to fix this?

I guess a good place to start is cprintf.c located in the dev86\libc\conio. 
Unfortunately ELKS seems to have been abandoned by most if not all developers so 
I am afraid you will be on your own. If only I had some more spare time .......

Good luck,

Hans
www.ht-lab.com


> --
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Console output corruption

[Dieter Kedrowitsch]

Hans, thanks for the reply.

Unfortunately my C debugging skills are pretty much non-existent.
It's a shame because it seems ELKS has the potential to be rolled into
a pretty neat little 8088 Linux OS.

I will poke around a little to see if I can figure it out, but I fear
without further assistance I will be unable to get this little beast
to behave and run smoothly on my 8088.

If anyone who is still following the list has the time and ability to
help me out, please feel free to chime in!

Thanks!

On Wed, Mar 10, 2010 at 12:53 PM, Hans <hans64@ht-lab.com> wrote:

> I guess a good place to start is cprintf.c located in the dev86\libc\conio.
> Unfortunately ELKS seems to have been abandoned by most if not all
> developers so I am afraid you will be on your own. If only I had some more
> spare time .......
>
> Good luck,
>
> Hans
> www.ht-lab.com

Re: Console output corruption

[Phil Goembel]

On Wed, 2010-03-10 at 13:25 -0500, Dieter Kedrowitsch wrote:
> Hans, thanks for the reply.
<snip>
> If anyone who is still following the list has the time and ability to
> help me out, please feel free to chime in!
> 
> Thanks!

In elks/kernel/printk.c is the following code for parsing a format
string (line 139, right after detecting a '%'):

    width = zero = '0';
    if (c == '0')
        zero++;
    while (c >= '0' && c <= '9') {
        width *= 10;
        width += c - '0';
        c = *fmt++;
    }
 
Notice the width is being set to the value of an ASCII '0' character. I
think it should have been set to the integer value 0 (zero) instead.

It looks like, by default, all fields will have a width of whatever the
ASCII code for '0' (48?).

Phil

Re: Console output corruption

[Mario Frasca]

On 2010-0418 09:50:13, Phil Goembel wrote:
> On Wed, 2010-03-10 at 13:25 -0500, Dieter Kedrowitsch wrote:
> > Hans, thanks for the reply.
> <snip>
> > If anyone who is still following the list has the time and ability to
> > help me out, please feel free to chime in!
> > 
> > Thanks!
> 
> In elks/kernel/printk.c is the following code for parsing a format
> string (line 139, right after detecting a '%'):
> 
>     width = zero = '0';
> [...]

when/where did you grab that from?

in
http://elks.cvs.sourceforge.net/viewvc/elks/elks/kernel/printk.c?revision=1.20&view=markup,
committed 5 years ago, width and zero are initialized to 0, not '0'...

M

-- 
 A Smith and Wesson beats four aces.

Re: Console output corruption

[Phil Goembel]

On Sun, 2010-04-18 at 17:17 +0200, Mario Frasca wrote:
> On 2010-0418 09:50:13, Phil Goembel wrote:
<snip>
> > 
> > In elks/kernel/printk.c is the following code for parsing a format
> > string (line 139, right after detecting a '%'):
> > 
> >     width = zero = '0';
> > [...]
> 
> when/where did you grab that from?
> 
> in
> http://elks.cvs.sourceforge.net/viewvc/elks/elks/kernel/printk.c?revision=1.20&view=markup,
> committed 5 years ago, width and zero are initialized to 0, not '0'...
> 
> M
> 
I grabbed it from the newest files on sourceforge:

elks-0.1.3.tar.gz 542.7 KB 2006-05-03 3,708

via this link:

http://sourceforge.net/projects/elks/files/elks/0.1.3/elks-0.1.3.tar.gz/download

Re: Console output corruption

[Mario Frasca]

On 2010-0418 10:45:17, Phil Goembel wrote:
> I grabbed it from the newest files on sourceforge:
> 
> elks-0.1.3.tar.gz 542.7 KB 2006-05-03 3,708

we probably should make a more up to date release!

M

Re: Console output corruption

[Hans]

----- Original Message ----- 
From: "Phil Goembel" <phil-goembel@wi.rr.com>
To: "Dieter Kedrowitsch" <dieter.kedrowitsch@gmail.com>
Cc: <linux-8086@vger.kernel.org>
Sent: Sunday, April 18, 2010 3:50 PM
Subject: Re: Console output corruption
 
> In elks/kernel/printk.c is the following code for parsing a format
> string (line 139, right after detecting a '%'):
> 
>    width = zero = '0';
>    if (c == '0')
>        zero++;
>    while (c >= '0' && c <= '9') {
>        width *= 10;
>        width += c - '0';
>        c = *fmt++;
>    }
> 
> Notice the width is being set to the value of an ASCII '0' character. I
> think it should have been set to the integer value 0 (zero) instead.
> 
> It looks like, by default, all fields will have a width of whatever the
> ASCII code for '0' (48?).
> 
> Phil
 
Phil you are the man!
 
I have just done a quick test and it seems to be fixed:
 
Booting......
 
ELKS Boot........:
Console: BIOS(15x25)
PC/XT class machine, 80188 CPU
640K base RAM.
ELKS kernel (-14544 text + 7044 data + -16516 bss)
Kernel text at 1002:0000, data at 1c75:0000
471 K of memory for user processes.
Serial driver version 0.02
ttyS0 at 0x3f8 (irq = 4) is a 16450
ttyS1 at 0x2f8 (irq = 3) is a 16450
rd driver Copyright (C) 1997 Alistair Riddoch
hd Driver Copyright (C) 1994 Yggdrasil Computing, Inc.
Extended and modified for Linux 8086 by Alan Cox.
doshd: found 0 floppy drives
ELKS version 0.1.3-pre1
Release not defined
VFS: Insert root floppy and press ENTER

Many thanks,

Hans
www.ht-lab.com

Re: Console output corruption

[Phil Goembel]

On Sun, 2010-04-18 at 17:34 +0100, Hans wrote:
> ----- Original Message ----- 
> From: "Phil Goembel" <phil-goembel@wi.rr.com>
> To: "Dieter Kedrowitsch" <dieter.kedrowitsch@gmail.com>
> Cc: <linux-8086@vger.kernel.org>
> Sent: Sunday, April 18, 2010 3:50 PM
> Subject: Re: Console output corruption
>  
> > In elks/kernel/printk.c is the following code for parsing a format
> > string (line 139, right after detecting a '%'):
> > 
> >    width = zero = '0';
> >    if (c == '0')
> >        zero++;
> >    while (c >= '0' && c <= '9') {
> >        width *= 10;
> >        width += c - '0';
> >        c = *fmt++;
> >    }
> > 
> > Notice the width is being set to the value of an ASCII '0' character. I
> > think it should have been set to the integer value 0 (zero) instead.
> > 
> > It looks like, by default, all fields will have a width of whatever the
> > ASCII code for '0' (48?).
> > 
> > Phil
>  
> Phil you are the man!
>  
> I have just done a quick test and it seems to be fixed:
> 
>  Many thanks,
> 
> Hans
> www.ht-lab.com
> 
> 

You're welcome! Glad I could help.

But, as Mario pointed out, the latest printk.c in the sourceforge CVS
repository does not have this bug. You might want to update all your
sources from the sourceforge CVS repository in case there are other 
bug fixes you are missing.

Unless someone else thinks that's a bad idea. I have no idea how stable
the latest code is.

Re: Console output corruption

[Mario Frasca]

On 2010-0418 13:40:41, Phil Goembel wrote:
> [...] the latest printk.c in the sourceforge CVS
> repository does not have this bug. You might want to update all your
> sources from the sourceforge CVS repository in case there are other 
> bug fixes you are missing.
> 
> Unless someone else thinks that's a bad idea. I have no idea how stable
> the latest code is.

well, I would say it's good someone is trying to use them so we can debu
them further...  sourceforge is quite good for helping developers keep
track of bugs...  it's a "forge", after all...  elks was not born here
and I'm not sure there are any administrators around any more, we need
admin rights to release new versions...  but if they are not around,
we can ask the people at Sourceforge to make some of us admins, and
then make sure we get some work done.  it's quite a standard procedure.
I can take my PPC 640 back from the attic and hope it won't explode as
did my Sirius 1!

M

-- 
OK, so you're a Ph.D.  Just don't touch anything.

Re: Console output corruption

[Kirn Gill]

On Sun, Apr 18, 2010 at 16:04, Mario Frasca <mfrasca@zonnet.nl> wrote:
>
> On 2010-0418 13:40:41, Phil Goembel wrote:
> > [...] the latest printk.c in the sourceforge CVS
> > repository does not have this bug. You might want to update all your
> > sources from the sourceforge CVS repository in case there are other
> > bug fixes you are missing.
> >
> > Unless someone else thinks that's a bad idea. I have no idea how stable
> > the latest code is.
>
> well, I would say it's good someone is trying to use them so we can debu
> them further...  sourceforge is quite good for helping developers keep
> track of bugs...  it's a "forge", after all...  elks was not born here
> and I'm not sure there are any administrators around any more, we need
> admin rights to release new versions...  but if they are not around,
> we can ask the people at Sourceforge to make some of us admins, and
> then make sure we get some work done.  it's quite a standard procedure.
> I can take my PPC 640 back from the attic and hope it won't explode as
> did my Sirius 1!
>
> M
>
> --
> OK, so you're a Ph.D.  Just don't touch anything.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Well guys, I still have commit access on the repos, so if anyone's got
some patches... mail them to the list and I'll try to get them
committed.
--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Console output corruption

[Mario Frasca]

On 2010-0418 21:12:37, Kirn Gill wrote:
> Well guys, I still have commit access on the repos, so if anyone's got
> some patches... mail them to the list and I'll try to get them
> committed.

may I propose an alternative way?  I would suggest we use sourceforge
trackers, so we can track (that is it) the changes to the code back to
bug reports.  this works really nice, in particular if we commit code
always mentioning the tracker item we are resolving with the modification
we are committing.  also, before committing code changes, make sure there
is a tracker item to which you can refer, so really no changes are done
for no trackable reason.

in the projects to which I participate we do something similar and it's
quite reassuring, to see commits that are more than a couple of years
old and still being able to say why they were done!  this also sort of
obliges developers to "commit often, commit early".

committ access is nice, but to administer the project we need to be
able to release new versions and to grant write access to possible new
developers.  that is, we need administration rights.  if we already have
that (I don't and I would like to), no problem, otherwise I suggest we
ask the Sourceforge staff.

it looks nicer, to see that more than one person is committing new code...
now some code I wrote is not really trackable to me except than for the
signature on top of the files...

ciao,
Mario

-- 
A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

Re: Console output corruption

[Mario Frasca]

On 2010-0419 16:05:02, Mario Frasca wrote:
> [...] I would suggest we use sourceforge trackers, [...]

to do this, one might want to get a sourceforge account (otherwise are
trackers associated to unnamed users).

> [...] that is, we need administration rights.  [...]
> I [haven't] and I would like to [...]

that means, I am availabe to do some administrative work, like assigning
rights (the more we are the better we look - unknown Neapolitan) and
checking that things keep being trackable...

M

-- 
There once was a girl named Irene
Who lived on distilled kerosene
        But she started absorbin'
        A new hydrocarbon
And since then has never benzene.