CVS status

CVS status

[Harry Kalogirou]

[-- Attachment #1: Type: text/plain, Size: 124 bytes --]

Hi all!

I tried the CVS version of elks this afternoon and it fails to load
init. Is there a known issue?

Harry



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 232 bytes --]

Re: CVS status

[Paul Nasrat]

[-- Attachment #1: Type: text/plain, Size: 509 bytes --]

On Fri, Jul 12, 2002 at 03:51:32PM +0300, Harry Kalogirou wrote:

Hi Harry

> I tried the CVS version of elks this afternoon and it fails to load
> init. Is there a known issue?

Just updated my tree and trying to build a kernel with all the defaults,
it errors with:

undefined symbol: _rs_ops 

This was defined in a #ifdef for CONFIG_CONSOLE_SERIAL and a patch is
attached which moves it outside.

I'm just trying to get bochs set up in the office so I can do more
testing in work without the laptop

Paul

[-- Attachment #2: elks-rsops.patch --]
[-- Type: text/plain, Size: 445 bytes --]

Index: serial.c
===================================================================
RCS file: /cvsroot/elks/elks/arch/i86/drivers/char/serial.c,v
retrieving revision 1.30
diff -u -r1.30 serial.c
--- serial.c	22 Jun 2002 09:28:19 -0000	1.30
+++ serial.c	12 Jul 2002 14:10:56 -0000
@@ -432,6 +432,8 @@
     /* Do something */
 }
 
+#endif
+
 struct tty_ops rs_ops = {
     rs_open,
     rs_release,
@@ -440,4 +442,3 @@
     rs_ioctl
 };
 
-#endif

Re: CVS status

[Harry Kalogirou]

[-- Attachment #1: Type: text/plain, Size: 1259 bytes --]

Την Παρ, 12-07-2002 στις 17:20, ο/η Paul Nasrat έγραψε:
> On Fri, Jul 12, 2002 at 03:51:32PM +0300, Harry Kalogirou wrote:
> 
> Hi Harry
> 
> > I tried the CVS version of elks this afternoon and it fails to load
> > init. Is there a known issue?
> 
> Just updated my tree and trying to build a kernel with all the defaults,
> it errors with:
> 
> undefined symbol: _rs_ops 
> 
> This was defined in a #ifdef for CONFIG_CONSOLE_SERIAL and a patch is
> attached which moves it outside.
> 
> I'm just trying to get bochs set up in the office so I can do more
> testing in work without the laptop
> 
> Paul
> ----
> 

> Index: serial.c
> ===================================================================
> RCS file: /cvsroot/elks/elks/arch/i86/drivers/char/serial.c,v
> retrieving revision 1.30
> diff -u -r1.30 serial.c
> --- serial.c	22 Jun 2002 09:28:19 -0000	1.30
> +++ serial.c	12 Jul 2002 14:10:56 -0000
> @@ -432,6 +432,8 @@
>      /* Do something */
>  }
>  
> +#endif
> +
>  struct tty_ops rs_ops = {
>      rs_open,
>      rs_release,
> @@ -440,4 +442,3 @@
>      rs_ioctl
>  };
>  
> -#endif

Mmmm.. this might was the problem with ktcp not working all this
time(actualy stty before ktcp)...

Harry


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 232 bytes --]

Re: CVS status

[Riley Williams]

Hi Harry.

>>> I tried the CVS version of elks this afternoon and it fails to
>>> load init. Is there a known issue?

>> Just updated my tree and trying to build a kernel with all the
>> defaults, it errors with:
>>
>> undefined symbol: _rs_ops 
>>
>> This was defined in a #ifdef for CONFIG_CONSOLE_SERIAL and a patch
>> is attached which moves it outside.
>>
>> I'm just trying to get bochs set up in the office so I can do more
>> testing in work without the laptop

> Mmmm.. this might was the problem with ktcp not working all this
> time (actualy stty before ktcp)...

I've now applied this patch and tested it, and on my 286 based laptop,
ELKS now boots and ktcp works again, so basic testing says that this
problem can now be declared to be fixed.

Harry: I've committed this to the CVS along with the CHANGELOG entry,
and relabelled it as kernel 0.1.1-pre3 so if you can do your usual and
set up a release thereof, it'd be appreciated. I've also tagged this as
elks-0_1_1-pre3 as a version marker.

We're probably close to a 0.1.1 release, but there's a few issues I want
to clear up before we do that...

Best wishes from Riley.

Re: CVS status

[Harry Kalogirou]

Την Παρ, 12-07-2002 στις 21:49, ο/η Riley Williams έγραψε:
> Hi Harry.
> 
> > Mmmm.. this might was the problem with ktcp not working all this
> > time (actualy stty before ktcp)...
> 
> I've now applied this patch and tested it, and on my 286 based laptop,
> ELKS now boots and ktcp works again, so basic testing says that this
> problem can now be declared to be fixed.
 
Ok.

> Harry: I've committed this to the CVS along with the CHANGELOG entry,
> and relabelled it as kernel 0.1.1-pre3 so if you can do your usual and
> set up a release thereof, it'd be appreciated. I've also tagged this as
> elks-0_1_1-pre3 as a version marker.

I'm not going to make a release since I can't create images normaly. 

> We're probably close to a 0.1.1 release, but there's a few issues I want
> to clear up before we do that...
> 
> Best wishes from Riley.
> 

Harry


-
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: CVS status

[Riley Williams]

Hi Harry, Paul.

>>> Mmmm.. this might was the problem with ktcp not working all this
>>> time (actualy stty before ktcp)...

>> I've now applied this patch and tested it, and on my 286 based
>> laptop, ELKS now boots and ktcp works again, so basic testing says
>> that this problem can now be declared to be fixed.

> Ok.

I'll add that this particular bug was as frustrating as they come. I'd
been going through each file one at a time and reverting the changes I'd
made to that file, then compiling the result, and nothing I did made the
slightest difference to getting it working again. I'd already reverted
serial.c without success as well !!!

I had determined that the problem was with the stty command and posted
an email to that effect to this list some time back. I managed this by
tweaking the /etc/rc.d/rc.sysinit script to deal with this case in the
same way that the Red Hat Linux scripts deal with multiple-stage items,
and the relevant patch was committed to the elkscmd tree some time ago.
It's enclosed below for your reference. The resulting display failed to
display the stty before panicking, hence my determining that there was
at least a problem at this stage...

===============8<=============== CUT ===============>8===============

Index: rootfs_template/etc/rc.d/rc.sysinit
===================================================================
RCS file: /cvsroot/elks/elkscmd/rootfs_template/etc/rc.d/rc.sysinit,v
retrieving revision 1.1
diff -u -5 -r1.1 rc.sysinit
--- rootfs_template/etc/rc.d/rc.sysinit	26 Jan 2002 11:17:43 -0000	1.1
+++ rootfs_template/etc/rc.d/rc.sysinit	15 Jul 2002 05:34:59 -0000
@@ -12,26 +12,28 @@
 sliptty=/dev/ttys0
 ttybaud=4800
 
 if test -f /bin/ktcp
 then
-	echo -n "Starting kernel network facilities: TCP/IP"
+	echo -n 'Starting kernel network facilities:'
 	stty $ttybaud < $sliptty
+	echo -n ' stty'
 	ktcp $localip $sliptty &
+	echo -n ' ktcp'
 
-	echo .
+	echo ''
 	
-	echo -n "Staring network daemons: "
+	echo -n "Starting network daemons: "
-	for daemon in httpd
+	for daemon in ftpd httpd
 	do
 		if test -f /bin/$daemon 
 		then
-			echo -n " $daemon"
 			$daemon &
+			echo -n " $daemon"
 		fi
 	done
-	echo .
+	echo ''
 
 fi
 
 # 
 # View message of day

===============8<=============== CUT ===============>8===============

In case you haven't guessed, I'm working on an ftpd daemon and have also
modified the above for when that is ready...

>> Harry: I've committed this to the CVS along with the CHANGELOG
>> entry, and relabelled it as kernel 0.1.1-pre3 so if you can do your
>> usual and set up a release thereof, it'd be appreciated. I've also
>> tagged this as elks-0_1_1-pre3 as a version marker.

> I'm not going to make a release since I can't create images normaly. 

Fair enough. The label is there anyway.

Actually, a reasonable release could be made by taking your images.zip
file, extracting each image out, mounting it and copying the revised
/etc/rc.d/rc.sysinit and the newly compiled kernel over the ones there,
then uploading the result.

>> We're probably close to a 0.1.1 release, but there's a few issues I
>> want to clear up before we do that...

With the progress that has been made over the last few days, we can
expect to be ready for 0.1.1 before the month finishes...

Best wishes from Riley.

Re: CVS status

[Paul Nasrat]

Harry

> I tried the CVS version of elks this afternoon and it fails to load
> init. Is there a known issue?

Got the cvs Image working mostly under bochs (my keyboard sometimes
doesn't work) However cvs will boot and load init on the root file
system from your site, and load the filesystem and start the EDE stuff.

So I don't see a problem with it (although I did apply my patch but that
shouldn't break anything)

Paul

Re: CVS status

[Harry Kalogirou]

Την Παρ, 12-07-2002 στις 18:48, ο/η Paul Nasrat έγραψε:
> Harry
> 
> > I tried the CVS version of elks this afternoon and it fails to load
> > init. Is there a known issue?
> 
> Got the cvs Image working mostly under bochs (my keyboard sometimes
> doesn't work) However cvs will boot and load init on the root file
> system from your site, and load the filesystem and start the EDE stuff.
> 

The problem comes from the new images produced by the elkscmd package. I
tried the old made root/boot disks from the site with the new kernel and
it works, as you state. 

A closer look shows that the new MAKEDEV script in the root_template has
some problems(Replacing the new /dev with the /dev from the site
floppies solves the problem). I don't have the time see what is wrong
right now, but I suggest more carefull and tested commits from now on.

Harry


-
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: CVS status

[Riley Williams]

Hi Harry.

>>> I tried the CVS version of elks this afternoon and it fails to
>>> load init. Is there a known issue?

>> Got the cvs Image working mostly under bochs (my keyboard sometimes
>> doesn't work) However cvs will boot and load init on the root file
>> system from your site, and load the filesystem and start the EDE
>> stuff.

> The problem comes from the new images produced by the elkscmd
> package. I tried the old made root/boot disks from the site with the
> new kernel and it works, as you state.
>
> A closer look shows that the new MAKEDEV script in the root_template
> has some problems(Replacing the new /dev with the /dev from the site
> floppies solves the problem). I don't have the time see what is
> wrong right now, but I suggest more carefull and tested commits from
> now on.

I would presume this was my fault as I tweaked the MAKEDEV script a
while back, but have to report that the resultant script worked fine on
my test system.

The only possible problem that I can see is that the MKSET definition
near the top of the file used a relative path for the MAKESET auxilliary
script, and that shouldn't be the problem as the remaining mknod lines
require that relative path to be correct. However, if the MAKESET script
is missing, that would be a problem.

I've replaced the definition with an absolute path to be safe, so if
that was it, then it isn't now. I've also included a check that the
auxilliary MAKESET script is actually present, displaying an error
message and aborting if not.

Harry: As my testing of this is obviously unreliable, can you check this
out for me please, and advise regarding the results so we can get this
problem sorted out.

Best wishes from Riley.