Weird partititon recocnising problem in 2.6.0-testX

Weird partititon recocnising problem in 2.6.0-testX

[Konstantin Kletschke]

Hi!

I have a PC here with an intel i875p chipset which seems not to recognize
logical partititions. 2.4.18 (kernel bf24 image) boots fine, but i do
not get a 2.6.0-test5 or 2.6.0-test9 to boot.

I compiled all necessary IDE drivers in, IDE, ide disk and piix and
such. All attempts yield in

Kernel Panic: VFS: Unable to mount root fs on hda5

I tried to submit root=0305 and such to pass to it. On my later
investigations I realized that the partition recocnizion seems to fail.

When booting Kernels report

hda: hda1 hda2 <hda5 hda6>

and boot, this one reports only:

hda: hda hda2

So, where are the logical ones?

In "Advanced partition selection" I switched on 
"PC BIOS (MSDOS partition tables) support" but that made no
difference...

hm. what next?

Regards, Konsti

-- 
2.6.0-test6-mm4
Konstantin Kletschke <konsti@ludenkalle.de>, <konsti@ku-gbr.de>
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF
keulator.homelinux.org up 4:24, 1 user

Re: Weird partititon recocnising problem in 2.6.0-testX

[Andries Brouwer]

On Sun, Nov 09, 2003 at 02:12:05AM +0100, Konstantin Kletschke wrote:

> I have a PC here with an intel i875p chipset which seems not to recognize
> logical partititions. 2.4.18 (kernel bf24 image) boots fine, but i do
> not get a 2.6.0-test5 or 2.6.0-test9 to boot.
> 
> When booting Kernels report
> 
> hda: hda1 hda2 <hda5 hda6>
> 
> and boot, this one reports only:
> 
> hda: hda hda2

I suppose that second hda is a typo for hda1?

What partition table? (fdisk -l /dev/hda or sfdisk -l -x -uS /dev/hda)

Re: Weird partititon recocnising problem in 2.6.0-testX

[Konstantin Kletschke]

* Andries Brouwer <aebr@win.tue.nl> [Sun, Nov 09, 2003 at 03:36:25AM +0100]:

> > hda: hda hda2
> 
> I suppose that second hda is a typo for hda1?

Yes ;)

> What partition table? (fdisk -l /dev/hda or sfdisk -l -x -uS /dev/hda)

	 Disk /dev/hda: 255 heads, 63 sectors, 1245 cylinders
Units = cylinders of 16065 * 512 bytes

   Device Boot    Start       End    Blocks   Id  System
/dev/hda1   *         1       365   2931831   83  Linux
/dev/hda2           366      1245   7068600    5  Extended
/dev/hda5           366       487    979933+  83  Linux
/dev/hda6          1185      1245    489951   82  Linux swap

Disk /dev/hdb: 255 heads, 63 sectors, 16709 cylinders
Units = cylinders of 16065 * 512 bytes

   Device Boot    Start       End    Blocks   Id  System
/dev/hdb1             1     16709 134215011   83  Linux


Thats it :) 

.config is at
http://ludenkalle.de/.config

Konsti

Re: Weird partititon recocnising problem in 2.6.0-testX

[Andries Brouwer]

On Sun, Nov 09, 2003 at 04:49:40AM +0100, Konstantin Kletschke wrote:
> * Andries Brouwer <aebr@win.tue.nl> [Sun, Nov 09, 2003 at 03:36:25AM +0100]:
> 
> > > hda: hda hda2
> > 
> > I suppose that second hda is a typo for hda1?
> 
> Yes ;)
> 
> > What partition table? (fdisk -l /dev/hda or sfdisk -l -x -uS /dev/hda)
> 
> 	 Disk /dev/hda: 255 heads, 63 sectors, 1245 cylinders
> Units = cylinders of 16065 * 512 bytes
> 
>    Device Boot    Start       End    Blocks   Id  System
> /dev/hda1   *         1       365   2931831   83  Linux
> /dev/hda2           366      1245   7068600    5  Extended
> /dev/hda5           366       487    979933+  83  Linux
> /dev/hda6          1185      1245    489951   82  Linux swap

Hmm. msdos.c has

                        put_partition(state, slot, start, size == 1 ? 1 : 2);
                        printk(" <");
                        parse_extended(state, bdev, start, size);
                        printk(" >");

The "hda2" is printed by put_partition(). But no " <" is printed.
An impossible error. Recompile your kernel.

Andries


[If a clean compile still fails, add
	printk("partition start %u size %u type %u",
		start, size, SYS_IND(p))
after the
        for (slot = 1 ; slot <= 4 ; slot++, p++) {
                u32 start = START_SECT(p)*sector_size;
                u32 size = NR_SECTS(p)*sector_size;
around line 413 in fs/partitions/msdos.c.]

Re: Weird partititon recocnising problem in 2.6.0-testX

[Stefan Smietanowski]

Hi Andries.

> Hmm. msdos.c has
> 
>                         put_partition(state, slot, start, size == 1 ? 1 : 2);
>                         printk(" <");
>                         parse_extended(state, bdev, start, size);
>                         printk(" >");
> 
> The "hda2" is printed by put_partition(). But no " <" is printed.
> An impossible error. Recompile your kernel.

I wouldn't say it's impossible. If the partition isn't recognized
as extended for some reason that code won't be called, will it?
And it'll only print "hda2" for him then.

// Stefan

Re: Weird partititon recocnising problem in 2.6.0-testX

[Konstantin Kletschke]

* Stefan Smietanowski <stesmi@stesmi.com> [Sun, Nov 09, 2003 at 01:10:41PM +0100]:
> >An impossible error. Recompile your kernel.

We recompiled it from fresh unpacked tar.bz2 same error. Instead of
gcc-2.95.4 we tried gcc-3.3.2 same errot. I got serial console running,
so a detailed log is at

http://www.ludenkalle.de/jan.log

My friend is trying to add this printk stuff (his PC) lets see...

Konsti

-- 
2.6.0-test6-mm4
Konstantin Kletschke <konsti@ludenkalle.de>, <konsti@ku-gbr.de>
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF
keulator.homelinux.org up 4:58, 1 user

Re: Weird partititon recocnising problem in 2.6.0-testX

[Konstantin Kletschke]

Hi again!

The suggested printk code is added no but I see no difference:

http://www.ludenkalle.de/printk.log


Regards, Konsti


-- 
2.6.0-test6-mm4
Konstantin Kletschke <konsti@ludenkalle.de>, <konsti@ku-gbr.de>
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF
keulator.homelinux.org up 5:54, 1 user

Re: Weird partititon recocnising problem in 2.6.0-testX

[Andries Brouwer]

On Mon, Nov 10, 2003 at 12:09:40AM +0100, Konstantin Kletschke wrote:

> The suggested printk code is added no but I see no difference:

  hda: 9766MB, CHS=1245/255/63
  hdb: 130551MB, CHS=16643/255/63
  devfs_mk_dir: invalid argument.
   hda: hda1 hda2
  devfs_mk_dir: invalid argument.
  devfs_mk_bdev: could not append to parent for /disc
   hdb: hdb1
  devfs_mk_bdev: could not append to parent for /part1
  
Aha, this "hda: 9766MB, CHS=1245/255/63" looks ancient.
You are using the old hd.c instead of the new ide stuff.

Nobody else does so, so there might easily be something wrong.
So, try to set CONFIG_BLK_DEV_IDEDISK=y but unset CONFIG_BLK_DEV_HD_IDE.

Andries

(2.4 question) open_namei hangs

[Shan Sinha]

Hi everyone-

I know everyone is probably focused on 2.6 right now, but I hope someone
will have the time to answer this question about 2.4.20! I'm extremely
confused, and am not sure what work-around I could employ.

I am trying to read the contents of a file from a kernel thread, spawned
when an LKM is insmod'ed. open_namei appears to hang.  The LKM is
something that I created.  When I call filp_open("/mydirectory",
O_RDONLY, 0), and then subsequently call vfs_readdir on the returned
file *, it traverses the files in the directory correctly.  

However, in the call back passed to vfs_readdir, if I try to do a
filp_open("/mydirectory/file1"), where "file1" is the string passed to
the call back, filp_open appears to hang somewhere inside open_namei (I
verified this by modifying filp_open).

But!  if I do "touch /mydirectory/*" in user space before I insert the
module and spawn my thread, the open and subsequent read for any files
in /mydirectory work fine.  

I suspect this is something to do with the files being loaded into the
buffer cache and my doing something incorrectly with respect to being in
a kernel thread.  Does anyone have any ideas of what may be happening?

I have included snips of the relevant code below.  I guessing my thread
is getting deadlocked somehow when the kernel has to go to disk to fetch
the file.  However, I created the code using khttpd as a sample (not
sure if this was a mistake).

Cheers-
Shan Sinha
Network and Mobile Systems
MIT CSAIL
ssinha@nms.mit.edu

------------------------------------------------------------
int my_callback(void * buf, const char * name, int namlen, loff_t
offset,
	     ino_t ino, unsigned int d_type)
{

       // for each file
  if (d_type == DT_REG) {
    struct file * f;
    read_descriptor_t read_desc;

    char * file_name = make_file_name("/mydirectory/", name, namlen);

    printk(KERN_INFO "loading file: %s\n", file_name);

    // WE HANG IN HERE (IF FILES HAVE NOT BEEN LOADED INTO BUFFER
CACHE??)!!!
    f = filp_open(file_name, O_RDONLY, 0);

    printk(KERN_INFO "opened file: %s\n", file_name);

    // Code snipped - set up code for call to do_generic_file_read
    // Code snipped - call to do_generic_file_read

    kfree(file_name);

  }

  return 0;
}

// Main daemon thread
int pm_daemon(void * data)
{

  DECLARE_WAIT_QUEUE_HEAD(WQ);

  sigset_t tmpsig;
  daemon_running = 1;
  leave_daemon_running = 1;
  sprintf(current->comm, "mythread");
  daemonize();

  /* Code snipped that blocks all signals except SIGKILL and SIGTERM */

  /* main loop */
  while (leave_daemon_running) {
    int signal_counter = 0;


    // count the number of files
    int num_files = 0;

    struct file * f = filp_open("/mydirectory/", O_RDONLY, 0);
    vfs_readdir(f, file_counter, &num_files);
 
    // loop through all files
    fput(f);
    printk(KERN_INFO "Counted files: %d\n", num_files );

    f = filp_open("/mydirectory/", O_RDONLY, 0);
    vfs_readdir(f, my_callback, NULL);

    // code snipped sleep and respond to signals
  }
  leave_daemon_running = 0;
  daemon_running = 0;

  return 0;
}



// called on module init
void pm_init(void)
{
   
  if (!daemon_running)
    kernel_thread(pm_daemon, NULL, CLONE_FS | CLONE_FILES |
CLONE_SIGHAND);

}