ELKS not runnable.... (once again)

Hi Riley,
after syncing with the CVS tree, I can't run the system. It fails this
way :

ELKS version 0.1.0
hd: probing disc in /dev/fd0
hd: /dev/fd0 probably has 18 sectors and 80 cylinders
VFS: Mounted root (minix filesystem).
Loading init
init panic
hd: bad partition start=57196 sect=1 nr_sects=0. BIOSHD:I/O error
dev 380, sector 122732
hd: bad partition start=57196 sect=1 nr_sects=0. BIOSHD:I/O error
dev 380, sector 122732
hd: bad partition start=57196 sect=1 nr_sects=0. BIOSHD:I/O error
dev 380, sector 122732

In the changelog you specificaly state that you checked that it runs on your laptop. Is there any chance you missed something? My changes on the tree was complitly irrelevant so I presume it is some of your changes. If you find something inform me as soon as posible, cause I'm stuck.

Harry

Can confirm here with slightly different numbers, unless my floppy is fscked. (tried on two different ones though)

hd: bad partition start=57500 sect=1 nr_sects=0.
BIOSHD:I/O error
dev 380, sector 123036
hd: bad partition start=51152 sect=1 nr_sects=0.
BIOSHD:I/O error
dev 380, sector 116688
hd: bad partition start=57500 sect=1 nr_sects=0.
BIOSHD:I/O error
dev 380, sector 123036

Just trying to compile without HD support, however get:

undefined symbol: _bioshd_getfdinfo
tools/build boot/bootsect boot/setup boot/system FLOPPY > boot/Image Root device is (0, 0)
Boot sector 512 bytes.
Setup is 1648 bytes.
Unable to open 'system'
make[1]: *** [Image] Error 1
make[1]: Leaving directory `/home/pauln/src/elks/arch/i86'
make: *** [Image] Error 2

Which needs to be fixed, biosfd depends on bioshd by the looks.

Can someone explain the difference between no h/w hd and bios hd

Paul

Την Τετ, 15-05-2002 στις 21:46, ο/η [email protected] έγραψε:

the bioshd also handles the floppy drives. If you disable bioshd you loose floppies along with the HDs. So when an error from bioshd shows up, it not always the hard drive.

Harry

-
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

When after loading the init and setting op the httpd deamon with the comb_net (0.1.0) image. I get a login prompt. When i type root followed with enter, the system loads, but doesn't show a prompt.

What can I do about this? (or is this the same bug as everybody is bugging about)

Greetings,
Stefan de Konink

Την Παρ, 17-05-2002 στις 23:15, ο/η Stefan de Konink έγραψε:

No, this is a bug I found a couple of days ago. The fix is included in the latest kernel in the CVS(but that has other problems now :( ). If you apply the attached patch to the 0.1.0 source you will be ok.

This bug affects "ash", so with an unpatched kernel you have to use "sash" by editing the /etc/passwd file.

I was going to release some new precompiled kernels with the patch(0.1.1) but this _unrunnability_ mess came up ... :(

Harry

@@ -266,16 +266,8 @@
      */
 
     ptr = ((char *) mh.dseg) + stack_top;
-    count = mh.bseg;
-    while (count) {
-	pokeb(dseg, ptr++, 0);
-	count--;
-    }
-    /* fmemset should work, but doesn't */
 
-#if 0
-    fmemset(ptr, dseg, 0, count);
-#endif
+    fmemset((char *)mh.dseg + stack_top, dseg, 0, mh.bseg);
 
     /*
      *      Copy the stack

Hi Harry.

Can I quote part of the diff between the current CVS tree and that of 'May 5 13:00:00 BST 2002' for you, as I refer to this section in my comments below...

Q> Index: arch/i86/drivers/block/doshd.c
Q> =================================================================== Q> RCS file: /cvsroot/elks/elks/arch/i86/drivers/block/doshd.c,v Q> retrieving revision 1.16
Q> retrieving revision 1.18
Q> diff -u -5 -r1.16 -r1.18
Q> --- arch/i86/drivers/block/doshd.c 26 Apr 2002 19:45:14 -0000 1.16
Q> +++ arch/i86/drivers/block/doshd.c 14 May 2002 23:15:31 -0000 1.18
Q> @@ -412,11 +414,11 @@
Q> #ifdef CONFIG_BLK_DEV_BFD
Q>
Q> int count;
Q> int i;
Q>
Q> - printk("hd: probing disc in /dev/fd%d\n", target % 2);
Q> + printk("fd: probing disc in /dev/fd%d\n", target % 2);
Q>
Q> /* The area between 32-64K is a 'scratch' area - we need a semaphore for it
Q> */
Q>
Q> while (!dma_avail)
Q> @@ -480,34 +482,48 @@
Q> /* I moved this out of for loop to prevent trashing the screen
Q> * with seducing (repeating) probe messages about disk types
Q> */
Q>
Q> if (drivep->cylinders == 0 || drivep->sectors == 0)
Q> - printk("hd: Floppy drive autoprobe failed!\n");
Q> + printk("fd: Floppy drive autoprobe failed!\n");
Q> else

 Q> -	    printk("hd: /dev/fd%d probably has %d sectors and %d cylinders\n",
 Q> +	    printk("fd: /dev/fd%d probably has %d sectors and %d cylinders\n",
 Q>  		   target % 2, drivep->sectors, drivep->cylinders);

Q>

I've extracted those two hunks out from the listing - there were several others. However, you may wish to note the changes therein...

Those last two lines don't match the current CVS so something's wrong here already. Look at the hunks quoted above to see why.

Can you check that you have indeed fully synchronised to the CVS tree, as this makes me suspect a build problem somewhere rather than a code problem.

I did indeed.

Always possible, so I'm double-checking the current CVS tree on my laptop as I speak...and I can confirm the problems you report as well.

I can confirm that your changes were completely irrelevant to my test as they only tweaked code that is #ifdef'd out by the config I use here anyway, so it's not your fault. I'm doing a full diff between the CVS tree as dated above and the current CVS tree, and wll be analysing it to see what looks suspicious...

I'm just back from Photography evening class at the local college, and I'm due in to the Dental Sedation Clinic tomorrow afternoon for some surgery, so I'm not likely to be able to do anything tomorrow. However, I'll check everything out thoroughly tonight and report what I find.

Best wishes from Riley.

Hi Harry.

I've just checked, and I now get this problem by dropping the 0.1.0 release kernel on the current floppy image, so this isn't a recent problem. I have to suspect that it's to do with other than the kernel itself, so who's been patching the elkscmd package recently? I haven't.

Best wishes from Riley.

Hi Harry.

I've just double-checked the above by doing...

	mkdir X
	cd X
	cvs get -r elks-0_1_0 elks
	cd elks
	make defconfig
	make dep
	make Image

...and then copying the resulting kernel image to a fresh copy of the floppy image you released with the 0.1.0 kernel. When I boot from the resulting floppy, I get exactly the same problem as you reported, so whatever the problem is predates the 0.1.0 release !!!

I've also downloaded the images-0.1.0.zip file after following the download link on the ELKS website, and dropped the full3 image on a floppy, and I can confirm the following:

1. The kernel image included on the floppy boots fine.

2. Replacing it with the 0.1.0 kernel image compiled using the above sequence results in a disk that fails to boot.

Basically, I have to conclude that the kernel on the 0.1.0 images is NOT the 0.1.0 kernel as labelled in the source tree, and that has me VERY worried. Can somebody please advise what is going on here?

As I stated previously, I'm in for Dental Sedation Surgery at lunchtime today, so I'm not likely to be in any condition to investigate this after that. Can somebody please look into this problem and see what they can come up with as this definitely needs sorting out.

Best wishes from Riley.

Την Πεμ, 16-05-2002 στις 12:40, ο/η Riley Williams έγραψε:

I don't see how the things you describe can happen. On my side I just downloaded the 0.1.0 version and reverted all the changes you did to the minixfs. The thing booted fine. I thing it is the changes you made to some datatypes.

Harry

-
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

Hi Harry.

I don't understand it either. All I can be sure of is that th version produced by cvs get -r elks-0_1_0 elks has exactly the same problem, but the one produced by cvs get -D 'Apr 30 12:00:00 2002' elks does not, so the problem lies somewhere between those two versions.

At the moment, I'm still drowsy from the sedation earlier today, so I'm not even attempting to sort this out until after that wears off. I'll have a thorough look into this tomorrow though, and deal with whatever I find to get it fixed.

Best wishes from Riley.

I hope everything went well, with all the problems that have been popping up recently, you better enjoy the sedation while it lasts!

Dan

Την Παρ, 17-05-2002 στις 01:42, ο/η Riley Williams έγραψε:
s.

Why should we compare 0.1.0 with an older one? Concentrate on this facts

1) The bioshd block device fails because the FS tells it to read some _wild_ sector.
2) Replacing the minix FS sources in the current source code with the ones from the 0.1.0, fixes the problem.
3) The changes in the minix FS are very dangerous and require care.

Harry

-
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

Hi Harry.

We're not - we're comparing the official 0.1.0 release (which is the version timestamped as above) with the tagged 0.1.0 release (which is the one tagged elks-0_1_0 in the CVS tree) and finding they differ.

My comment above is pointing out that the version tagged as elks-0_1_0 in the CVS tree is NOT the version that was released as 0.1.0 but a later version with some extra tweaks applied.

Agreed.

Which 0.1.0 release? As stated above, there are TWO DIFFERENT releases labelled as 0.1.0 depending on where one looks.

Agreed. That's why I'm carefully reverting them.

Best wishes from Riley.

Την Παρ, 17-05-2002 στις 20:59, ο/η Riley Williams έγραψε:

If the tag elks-0_1_0 has the timestamp you say and you checkout that timestamp and there are differences then CVS has some BUG, which I don't think so.

I checked it out with the tag elks-0_1_0.

That is good to hear...

Harry

-
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

Την Πεμ, 16-05-2002 στις 02:11, ο/η Riley Williams έγραψε:

No, this _is_ a kernel problem. You can't cause a problem like that from userspace. It is a long time since I had my root disk updated, and only the latest kernel cause the problem. If I use some older kernels I have precompiled it works fine.

Try reverting your changes one by one to find which one causes the problem.

Harry

-
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