2003-11-09 01:12:43

by Konstantin Kletschke

[permalink] [raw]
Subject: Weird partititon recocnising problem in 2.6.0-testX

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 <[email protected]>, <[email protected]>
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E A080 1E69 3FDA EF62 FCEF
keulator.homelinux.org up 4:24, 1 user


2003-11-09 02:36:29

by Andries Brouwer

[permalink] [raw]
Subject: Re: Weird partititon recocnising problem in 2.6.0-testX

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)

2003-11-09 03:50:18

by Konstantin Kletschke

[permalink] [raw]
Subject: Re: Weird partititon recocnising problem in 2.6.0-testX

* Andries Brouwer <[email protected]> [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

2003-11-09 11:59:01

by Andries Brouwer

[permalink] [raw]
Subject: Re: Weird partititon recocnising problem in 2.6.0-testX

On Sun, Nov 09, 2003 at 04:49:40AM +0100, Konstantin Kletschke wrote:
> * Andries Brouwer <[email protected]> [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.]



2003-11-09 12:08:46

by Stefan Smietanowski

[permalink] [raw]
Subject: Re: Weird partititon recocnising problem in 2.6.0-testX

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

2003-11-09 22:16:00

by Konstantin Kletschke

[permalink] [raw]
Subject: Re: Weird partititon recocnising problem in 2.6.0-testX

* Stefan Smietanowski <[email protected]> [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 <[email protected]>, <[email protected]>
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E A080 1E69 3FDA EF62 FCEF
keulator.homelinux.org up 4:58, 1 user

2003-11-09 23:09:47

by Konstantin Kletschke

[permalink] [raw]
Subject: Re: Weird partititon recocnising problem in 2.6.0-testX

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 <[email protected]>, <[email protected]>
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E A080 1E69 3FDA EF62 FCEF
keulator.homelinux.org up 5:54, 1 user

2003-11-10 00:00:29

by Andries Brouwer

[permalink] [raw]
Subject: Re: Weird partititon recocnising problem in 2.6.0-testX

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

2003-11-10 01:48:10

by Shan Sinha

[permalink] [raw]
Subject: (2.4 question) open_namei hangs

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
[email protected]

------------------------------------------------------------
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);

}