Console output corruption

DISCUSSION Hans 4 participants 6 messages Apr 18, 2010 – Apr 19, 2010 1 message not in the archive

Share & tools

Hans

author

2010-04-18 16:34 UTC #0 lore raw

----- Original Message ----- From: "Phil Goembel" <[email protected]>
To: "Dieter Kedrowitsch" <[email protected]>
Cc: <[email protected]>
Sent: Sunday, April 18, 2010 3:50 PM
Subject: Re: Console output corruption

Quoted 12 lines

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++;
   }

Quoted 7 lines

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

Phil Goembel

2010-04-18 18:40 UTC #1 lore raw

Quoted 27 lines · Hans

----- Original Message -----
From: "Phil Goembel" <[email protected]>
To: "Dieter Kedrowitsch" <[email protected]>
Cc: <[email protected]>
Sent: Sunday, April 18, 2010 3:50 PM
Subject: Re: Console output corruption
Quoted 12 lines
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++;
   }
Quoted 7 lines
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

Quoted 10 lines

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.

Mario Frasca

2010-04-18 20:04 UTC #2 lore raw

Quoted 7 lines · Phil Goembel

[...] 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!

Signature · 1 line

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

Kirn Gill

2010-04-19 01:12 UTC #4 lore raw

Quoted 20 lines · Mario Frasca

Quoted 7 lines · Phil Goembel
[...] 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!

Quoted 8 lines

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 [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Mario Frasca

2010-04-19 14:05 UTC #5 lore raw

Quoted 3 lines · Kirn Gill

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

Signature · 1 line

A: Yes.

Quoted 3 lines

Q: Are you sure?
Quoted 2 lines
A: Because it reverses the logical flow of conversation.
Quoted 1 line
Q: Why is top posting annoying in email?

Mario Frasca

2010-04-19 14:35 UTC #6 lore raw

Quoted 1 line · Mario Frasca

[...] 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).

Quoted 2 lines

[...] 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...

Signature · 5 lines

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.