2003-05-21 22:54:08

by Ivan Gyurdiev

[permalink] [raw]
Subject: kernel BUG at include/linux/dcache.h:271!

1) Kernel is 2.5.69 bitkeeper as of May 21.
The following occurs when removing the rd module from the kernel.
I get a segmentation fault, and lsmod freezes. Kernel log says:

agpgart: Putting AGP V2 device at 00:00.0 into 4x mode
agpgart: Putting AGP V2 device at 01:00.0 into 4x mode
ACPI: No IRQ known for interrupt pin C of device 00:11.5
PCI: Setting latency timer of device 00:11.5 to 64
devfs_mk_dir(rd): could not append to dir: dffcd8c0 ""
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
------------[ cut here ]------------
kernel BUG at include/linux/dcache.h:271!
invalid operand: 0000 [#1]
CPU: 0
EIP: 0060:[<c0186dec>] Tainted: PF
EFLAGS: 00010246
EIP is at sysfs_remove_dir+0x1c/0x152
eax: 00000000 ebx: e09e18c4 ecx: c034eba0 edx: 00000000
esi: d5acee40 edi: d58a8980 ebp: e09e1840 esp: d5a2bed8
ds: 007b es: 007b ss: 0068
Process rmmod (pid: 1302, threadinfo=d5a2a000 task=d5e30640)
Stack: 00000000 00000000 dfdf4b40 00000000 e09e18c4 00000001 d58a8980 e09e1840
c01e3a03 e09e18c4 c034eba0 e09e18c4 e09e18c4 c01e3a53 e09e18c4 d58a88c0
c022b45d e09e18c4 d58a88c0 c022f3c3 d58a88c0 d58a88c0 d58a88c0 c01858f8
Call Trace:
[<e09e18c4>] rd_queue+0x44/0x148 [rd]
[<e09e1840>] rd_bdev+0x0/0x40 [rd]
[<c01e3a03>] kobject_del+0x43/0x80
[<e09e18c4>] rd_queue+0x44/0x148 [rd]
[<e09e18c4>] rd_queue+0x44/0x148 [rd]
[<e09e18c4>] rd_queue+0x44/0x148 [rd]
[<c01e3a53>] kobject_unregister+0x13/0x30
[<e09e18c4>] rd_queue+0x44/0x148 [rd]
[<c022b45d>] elv_unregister_queue+0x1d/0x40
[<e09e18c4>] rd_queue+0x44/0x148 [rd]
[<c022f3c3>] unlink_gendisk+0x13/0x40
[<c01858f8>] del_gendisk+0x58/0xe0
[<e09e1800>] +0x0/0x40 [rd]
[<e09e063e>] +0x4e/0x88 [rd]
[<c0145370>] unmap_vma+0x40/0x80
[<e09e15c0>] +0x0/0x140 [rd]
[<c01311f9>] sys_delete_module+0x109/0x140
[<e09e15c0>] +0x0/0x140 [rd]
[<c0145854>] sys_munmap+0x44/0x70
[<c01090e5>] sysenter_past_esp+0x52/0x71

Code: 0f 0b 0f 01 7b c9 2d c0 ff 06 85 f6 0f 84 1c 01 00 00 8b 6e

2) ALSA:
(Using snd-via82xx, no oss, testing with xmms and libALSA.so)
I notice the following on 2.5 only. (I use 2.4 ALSA too and it works fine).

When playing an mp3 file and either:

- attempting to stop the music, or restart it, or play another one, or skip
in the middle causes the music to keep looping in place until killed.

Testing with mplayer:
- skipping forward works fine, pause causes loop.

Since the problem does not occur in 2.4 (2.4.21-rc2, alsa 0.9.2 from
alsa-project.org) I thought it to be a kernel bug.

3) Could someone clarify some module issues for me.
I doubt those are bugs, but I have limited understanding of modules, and I'd
appreciate some help. Perhaps email off the list?

- rmmod -a has no effect for me on either 2.4 or 2.5.
On 2.4 modules marked autoclean and unused are not removed by that command.
I need to specify the name of the module to get it removed. Why so?

- I need to manually insmod snd-via82xx for ALSA to work.
The following line is present in modules.conf/modprobe.conf:
alias snd-card-0 snd-via82xx. Why isn't the module autoloaded when I attempt
to use xmms to play audio.

- what is the significance of modules.devfs in 2.5 - is it still necessary.
Does the script generate_modprobe.conf take modules.devfs into account?
What will happen to devfs in the future?

Thank you for your help.




2003-05-22 11:41:27

by Maneesh Soni

[permalink] [raw]
Subject: Re: kernel BUG at include/linux/dcache.h:271!

On Wed, May 21, 2003 at 11:08:37PM +0000, Ivan Gyurdiev wrote:
> 1) Kernel is 2.5.69 bitkeeper as of May 21.
> The following occurs when removing the rd module from the kernel.
> I get a segmentation fault, and lsmod freezes. Kernel log says:
>
> agpgart: Putting AGP V2 device at 00:00.0 into 4x mode
> agpgart: Putting AGP V2 device at 01:00.0 into 4x mode
> ACPI: No IRQ known for interrupt pin C of device 00:11.5
> PCI: Setting latency timer of device 00:11.5 to 64
> devfs_mk_dir(rd): could not append to dir: dffcd8c0 ""
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> ------------[ cut here ]------------
> kernel BUG at include/linux/dcache.h:271!
> invalid operand: 0000 [#1]
> CPU: 0
> EIP: 0060:[<c0186dec>] Tainted: PF
> EFLAGS: 00010246
> EIP is at sysfs_remove_dir+0x1c/0x152
> eax: 00000000 ebx: e09e18c4 ecx: c034eba0 edx: 00000000
> esi: d5acee40 edi: d58a8980 ebp: e09e1840 esp: d5a2bed8
> ds: 007b es: 007b ss: 0068
> Process rmmod (pid: 1302, threadinfo=d5a2a000 task=d5e30640)
> Stack: 00000000 00000000 dfdf4b40 00000000 e09e18c4 00000001 d58a8980 e09e1840
> c01e3a03 e09e18c4 c034eba0 e09e18c4 e09e18c4 c01e3a53 e09e18c4 d58a88c0
> c022b45d e09e18c4 d58a88c0 c022f3c3 d58a88c0 d58a88c0 d58a88c0 c01858f8
> Call Trace:
> [<e09e18c4>] rd_queue+0x44/0x148 [rd]
> [<e09e1840>] rd_bdev+0x0/0x40 [rd]
> [<c01e3a03>] kobject_del+0x43/0x80
> [<e09e18c4>] rd_queue+0x44/0x148 [rd]
> [<e09e18c4>] rd_queue+0x44/0x148 [rd]
> [<e09e18c4>] rd_queue+0x44/0x148 [rd]
> [<c01e3a53>] kobject_unregister+0x13/0x30
> [<e09e18c4>] rd_queue+0x44/0x148 [rd]
> [<c022b45d>] elv_unregister_queue+0x1d/0x40
> [<e09e18c4>] rd_queue+0x44/0x148 [rd]
> [<c022f3c3>] unlink_gendisk+0x13/0x40
> [<c01858f8>] del_gendisk+0x58/0xe0

I think it is due to wrong representation of ramdisks in sysfs. Infact it is
leaking dentries. The problem is that we have multiple ramdisks but all have
common request queue and common elevator. In terms of sysfs we
have multiple kobjects for multiple ramdisks, but one single kobject for the
ramdisks' common elevator.

While initializing, different kobjects are allocated for the ramdisks but,
the common elevator uses the same kobject. In other words, every init
of a ramdisk, the common elevator.kobj->parent will be different and it will
allocate a new dentry, overwrite the elevator.kobj->dentry
and loose the earlier allocated dentries. (see: elv_register_queue())

While exiting, it ends up in removing the same dentry (allocated at the last)
again and BUGs in dget on dentry with zero ref count.

Not sure where it should be fixed
ramdisk
- should have separate queues on for each ramdisk

elevator
- should not re-register already registered queue in elv_register_queue

sysfs
- should handle kobject with multiple parent kobjects

--
Maneesh Soni
IBM Linux Technology Center,
IBM India Software Lab, Bangalore.
Phone: +91-80-5044999 email: [email protected]
http://lse.sourceforge.net/

2003-05-22 22:08:29

by Andrew Morton

[permalink] [raw]
Subject: Re: kernel BUG at include/linux/dcache.h:271!

Maneesh Soni <[email protected]> wrote:
>
> The problem is that we have multiple ramdisks but all have
> common request queue and common elevator. In terms of sysfs we
> have multiple kobjects for multiple ramdisks, but one single kobject for the
> ramdisks' common elevator.
>
> While initializing, different kobjects are allocated for the ramdisks but,
> the common elevator uses the same kobject. In other words, every init
> of a ramdisk, the common elevator.kobj->parent will be different and it will
> allocate a new dentry, overwrite the elevator.kobj->dentry
> and loose the earlier allocated dentries. (see: elv_register_queue())
>
> While exiting, it ends up in removing the same dentry (allocated at the last)
> again and BUGs in dget on dentry with zero ref count.
>
> Not sure where it should be fixed
> ramdisk
> - should have separate queues on for each ramdisk
>
> elevator
> - should not re-register already registered queue in elv_register_queue
>
> sysfs
> - should handle kobject with multiple parent kobjects

I can't think of anywhere else where we are likely to want to support
multiple devices from a single queue in this manner, so perhaps the best
solution is to remove the exceptional case: allocate a separate queue for
each ramdisk instance.

Jens, do you agree?


2003-05-23 06:12:15

by Jens Axboe

[permalink] [raw]
Subject: Re: kernel BUG at include/linux/dcache.h:271!

On Thu, May 22 2003, Andrew Morton wrote:
> Maneesh Soni <[email protected]> wrote:
> >
> > The problem is that we have multiple ramdisks but all have
> > common request queue and common elevator. In terms of sysfs we
> > have multiple kobjects for multiple ramdisks, but one single kobject for the
> > ramdisks' common elevator.
> >
> > While initializing, different kobjects are allocated for the ramdisks but,
> > the common elevator uses the same kobject. In other words, every init
> > of a ramdisk, the common elevator.kobj->parent will be different and it will
> > allocate a new dentry, overwrite the elevator.kobj->dentry
> > and loose the earlier allocated dentries. (see: elv_register_queue())
> >
> > While exiting, it ends up in removing the same dentry (allocated at the last)
> > again and BUGs in dget on dentry with zero ref count.
> >
> > Not sure where it should be fixed
> > ramdisk
> > - should have separate queues on for each ramdisk
> >
> > elevator
> > - should not re-register already registered queue in elv_register_queue
> >
> > sysfs
> > - should handle kobject with multiple parent kobjects
>
> I can't think of anywhere else where we are likely to want to support
> multiple devices from a single queue in this manner, so perhaps the best
> solution is to remove the exceptional case: allocate a separate queue for
> each ramdisk instance.
>
> Jens, do you agree?

Completely and utterly agree :)

--
Jens Axboe

2003-05-23 12:27:54

by Maneesh Soni

[permalink] [raw]
Subject: Re: kernel BUG at include/linux/dcache.h:271!

On Fri, May 23, 2003 at 08:25:08AM +0200, Jens Axboe wrote:
> On Thu, May 22 2003, Andrew Morton wrote:
> > Maneesh Soni <[email protected]> wrote:
> > >
> > > ramdisk
> > > - should have separate queues on for each ramdisk
> > >
> > > elevator
> > > - should not re-register already registered queue in elv_register_queue
> > >
> > > sysfs
> > > - should handle kobject with multiple parent kobjects
> >
> > I can't think of anywhere else where we are likely to want to support
> > multiple devices from a single queue in this manner, so perhaps the best
> > solution is to remove the exceptional case: allocate a separate queue for
> > each ramdisk instance.
> >
> > Jens, do you agree?
>
> Completely and utterly agree :)
>
> --
> Jens Axboe

Hi,

The following patch provides a separate queue for each ramdisk instance
and the BUG is not seen now.

Please check whether it is ok or not.

Thanks,
Maneesh

drivers/block/rd.c | 19 +++++++++++++------
1 files changed, 13 insertions(+), 6 deletions(-)

diff -puN drivers/block/rd.c~multiqueue_ramdisk drivers/block/rd.c
--- linux-2.5.69/drivers/block/rd.c~multiqueue_ramdisk 2003-05-23 16:04:38.000000000 +0530
+++ linux-2.5.69-maneesh/drivers/block/rd.c 2003-05-23 17:45:24.000000000 +0530
@@ -67,6 +67,7 @@

static struct gendisk *rd_disks[NUM_RAMDISKS];
static struct block_device *rd_bdev[NUM_RAMDISKS];/* Protected device data */
+static struct request_queue *rd_queue;

/*
* Parameters for the boot-loading of the RAM disk. These are set by
@@ -308,12 +309,11 @@ static void __exit rd_cleanup (void)
del_gendisk(rd_disks[i]);
put_disk(rd_disks[i]);
}
-
+ kfree(rd_queue);
devfs_remove("rd");
unregister_blkdev(RAMDISK_MAJOR, "ramdisk" );
}

-static struct request_queue rd_queue;
/* This is the registration and initialization section of the RAM disk driver */
static int __init rd_init (void)
{
@@ -333,23 +333,28 @@ static int __init rd_init (void)
goto out;
}

+ rd_queue = kmalloc(NUM_RAMDISKS * sizeof(struct request_queue),
+ GFP_KERNEL);
+ if (!rd_queue)
+ goto out;
+
if (register_blkdev(RAMDISK_MAJOR, "ramdisk")) {
err = -EIO;
- goto out;
+ goto out_queue;
}

- blk_queue_make_request(&rd_queue, &rd_make_request);
-
devfs_mk_dir("rd");

for (i = 0; i < NUM_RAMDISKS; i++) {
struct gendisk *disk = rd_disks[i];

+ blk_queue_make_request(&rd_queue[i], &rd_make_request);
+
/* rd_size is given in kB */
disk->major = RAMDISK_MAJOR;
disk->first_minor = i;
disk->fops = &rd_bd_op;
- disk->queue = &rd_queue;
+ disk->queue = &rd_queue[i];
sprintf(disk->disk_name, "ram%d", i);
sprintf(disk->devfs_name, "rd/%d", i);
set_capacity(disk, rd_size * 2);
@@ -362,6 +367,8 @@ static int __init rd_init (void)
NUM_RAMDISKS, rd_size, rd_blocksize);

return 0;
+out_queue:
+ kfree(rd_queue);
out:
while (i--)
put_disk(rd_disks[i]);

_



--
Maneesh Soni
IBM Linux Technology Center,
IBM India Software Lab, Bangalore.
Phone: +91-80-5044999 email: [email protected]
http://lse.sourceforge.net/

2003-05-23 12:40:02

by Maneesh Soni

[permalink] [raw]
Subject: Re: kernel BUG at include/linux/dcache.h:271!

On Fri, May 23, 2003 at 06:13:24PM +0530, Maneesh Soni wrote:
> On Fri, May 23, 2003 at 08:25:08AM +0200, Jens Axboe wrote:
> > On Thu, May 22 2003, Andrew Morton wrote:
> > > Maneesh Soni <[email protected]> wrote:
> > > >
> > > > ramdisk
> > > > - should have separate queues on for each ramdisk
> > > >
> > > > elevator
> > > > - should not re-register already registered queue in elv_register_queue
> > > >
> > > > sysfs
> > > > - should handle kobject with multiple parent kobjects
> > >
> > > I can't think of anywhere else where we are likely to want to support
> > > multiple devices from a single queue in this manner, so perhaps the best
> > > solution is to remove the exceptional case: allocate a separate queue for
> > > each ramdisk instance.
> > >
> > > Jens, do you agree?
> >
> > Completely and utterly agree :)
> >
> > --
> > Jens Axboe
>
> Hi,
>
> The following patch provides a separate queue for each ramdisk instance
> and the BUG is not seen now.
>
> Please check whether it is ok or not.
>
> Thanks,
> Maneesh

can't help.. I always have to send patch second time. Please see this one
instead.



- Provides a separate request queue for each ramdisk instance.


drivers/block/rd.c | 19 +++++++++++++------
1 files changed, 13 insertions(+), 6 deletions(-)

diff -puN drivers/block/rd.c~multiqueue_ramdisk drivers/block/rd.c
--- linux-2.5.69/drivers/block/rd.c~multiqueue_ramdisk 2003-05-23 16:04:38.000000000 +0530
+++ linux-2.5.69-maneesh/drivers/block/rd.c 2003-05-23 18:22:31.000000000 +0530
@@ -67,6 +67,7 @@

static struct gendisk *rd_disks[NUM_RAMDISKS];
static struct block_device *rd_bdev[NUM_RAMDISKS];/* Protected device data */
+static struct request_queue *rd_queue;

/*
* Parameters for the boot-loading of the RAM disk. These are set by
@@ -308,12 +309,11 @@ static void __exit rd_cleanup (void)
del_gendisk(rd_disks[i]);
put_disk(rd_disks[i]);
}
-
+ kfree(rd_queue);
devfs_remove("rd");
unregister_blkdev(RAMDISK_MAJOR, "ramdisk" );
}

-static struct request_queue rd_queue;
/* This is the registration and initialization section of the RAM disk driver */
static int __init rd_init (void)
{
@@ -333,23 +333,28 @@ static int __init rd_init (void)
goto out;
}

+ rd_queue = kmalloc(NUM_RAMDISKS * sizeof(struct request_queue),
+ GFP_KERNEL);
+ if (!rd_queue)
+ goto out;
+ memset(rd_queue, 0, NUM_RAMDISKS * sizeof(struct request_queue));
if (register_blkdev(RAMDISK_MAJOR, "ramdisk")) {
err = -EIO;
- goto out;
+ goto out_queue;
}

- blk_queue_make_request(&rd_queue, &rd_make_request);
-
devfs_mk_dir("rd");

for (i = 0; i < NUM_RAMDISKS; i++) {
struct gendisk *disk = rd_disks[i];

+ blk_queue_make_request(&rd_queue[i], &rd_make_request);
+
/* rd_size is given in kB */
disk->major = RAMDISK_MAJOR;
disk->first_minor = i;
disk->fops = &rd_bd_op;
- disk->queue = &rd_queue;
+ disk->queue = &rd_queue[i];
sprintf(disk->disk_name, "ram%d", i);
sprintf(disk->devfs_name, "rd/%d", i);
set_capacity(disk, rd_size * 2);
@@ -362,6 +367,8 @@ static int __init rd_init (void)
NUM_RAMDISKS, rd_size, rd_blocksize);

return 0;
+out_queue:
+ kfree(rd_queue);
out:
while (i--)
put_disk(rd_disks[i]);

_


--
Maneesh Soni
IBM Linux Technology Center,
IBM India Software Lab, Bangalore.
Phone: +91-80-5044999 email: [email protected]
http://lse.sourceforge.net/