At some PC #PF with VFS and Ram Disk File System (JM's code)

[ehenkes]

I use fs.h/c and initrd.h/c from JM's great tutorial. With the following code some PC break down with a #PF during listing the file contents:

Code: Select all

int main()
{
    init();
    //... 

    kheap = create_heap(KHEAP_START, KHEAP_START+KHEAP_INITIAL_SIZE, KHEAP_MAX, 1, 0); // SV and RW
    ULONG ramdisk_start = k_malloc(0x30000, 0, 0);
    printformat("Ram Disk at: %x\n",ramdisk_start);

    tasking_install();
    sti();
    k_memcpy((void*)ramdisk_start, &file_data_start, (ULONG)&file_data_end - (ULONG)&file_data_start); 
    fs_root = install_initrd(ramdisk_start);

    // search the content of files <- data from outside "loaded" via incbin ...
    settextcolor(15,0);
    ULONG i = 0;
    struct dirent* node = 0;
    while( (node = readdir_fs(fs_root, i)) != 0)
    {
        fs_node_t* fsnode = finddir_fs(fs_root, node->name);

        if((fsnode->flags & 0x7) == FS_DIRECTORY)
        {
            printformat("<DIR> %s\n",node->name);
        }
        else
        {
            UCHAR buf[4096];
            ULONG sz = read_fs(fsnode, 0, fsnode->length, buf);
            printformat("%d \t%s\n",sz,node->name);

            ULONG j;
            for(j=0; j<sz; ++j)
            {
                if( k_strcmp(node->name,"Test-Programm")==0 )
                {
                    address_TEST[j] = buf[j];
                }
            }
        }
        ++i;
    }

Bochs 2.4.1 runs without problems with simulated or real floppy disk.
50% of PCs run without problems, but some stop with a #PF.
Perhaps it has another reason, but the problem could be tracked down to fs.c.
But the situation is very complex, because I cannot debug with bochs, only with prints from the OS.

The problem seems to be in finddir_fs(...). Is there a problem or improvements known regarding this code of JM? Advice would be highly appreciated.

[gzaloprgm]

If it pagefaults then you are probably mapping it to a wrong area.

Are you sure you are doing this:

Code: Select all

   ASSERT(mboot_ptr->mods_count > 0);
   u32int initrd_location = *((u32int*)mboot_ptr->mods_addr);
   u32int initrd_end = *(u32int*)(mboot_ptr->mods_addr+4);
   // Don't trample our module with placement accesses, please!
   placement_address = initrd_end;

BTW; JamesMolloy's code has some errors to stop copy pasters, you should know that.

Cheers,
Gzaloprgm

[ehenkes]

JamesMolloy's code has some errors to stop copy pasters, you should know that.

Nice feature of a tutorial code.

If it pagefaults then you are probably mapping it to a wrong area.

No, the #PF is based on wrong data in the RAM disk. I analyzed that.

Are you sure you are doing this:

Code: Select all

ASSERT(mboot_ptr->mods_count > 0);
   u32int initrd_location = *((u32int*)mboot_ptr->mods_addr);
   u32int initrd_end = *(u32int*)(mboot_ptr->mods_addr+4);
   // Don't trample our module with placement accesses, please!
   placement_address = initrd_end;

No, I do not, because I use my own bootloader, not GRUB, and I install the RAM disk at the kernel heap (start of heap: 0x40000000). Memory management:

Code: Select all

ULONG ramdisk_start = k_malloc(0x30000, 0, 0);
//...
fs_root = install_initrd(ramdisk_start);

Here I log this (bochs simulation):

PrettyOS [Version 0.1.0083]

bitset: 00200000h PD: 00204000h gp_make: 00207000h gp_make: 00208000h gp_make: 00209000h clone_PD: 0020A000h heap: 0020D000h rd_start: 4008100Ch
Ram Disk at: 4008100Ch
1st_task: 400B1020h 1st_ks: 400B2000h rd_root: 400B1054h rd_dev: 400B1120h root_nodes: 400B11ECh
<DIR> dev
1110 Test-Programm
virtual address: 00400000h offset: 00000060h size: 000000CFh

clone_PD: 400B3000h cr_task: 400B12B8h cr_task_ks: 400B6000h
Test Hello User-World!

Hence, there is reserved space for the RAM disk:
0x40081000 (start of the hole at heap) + 0x30000 = 400B1000
(first task structure starts at 400B1020h)

rd_root: 400B1054h
rd_dev: 400B1120h
root_nodes: 400B11ECh

At some(!) real PCs the failure - corrupting data at ramdisk - shows up behind root_nodes AFAIR.

Is there a problem by putting the RAM disk into the heap?