linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* kernel BUG at include/linux/dcache.h:271!
@ 2003-05-21 23:11 Ivan Gyurdiev
  2003-05-22 11:57 ` Maneesh Soni
  0 siblings, 1 reply; 6+ messages in thread
From: Ivan Gyurdiev @ 2003-05-21 23:11 UTC (permalink / raw)
  To: LKML

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.




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: kernel BUG at include/linux/dcache.h:271!
  2003-05-21 23:11 kernel BUG at include/linux/dcache.h:271! Ivan Gyurdiev
@ 2003-05-22 11:57 ` Maneesh Soni
  2003-05-22 22:19   ` Andrew Morton
  0 siblings, 1 reply; 6+ messages in thread
From: Maneesh Soni @ 2003-05-22 11:57 UTC (permalink / raw)
  To: Ivan Gyurdiev; +Cc: LKML, page0588, greg, tytso

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: maneesh@in.ibm.com
http://lse.sourceforge.net/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: kernel BUG at include/linux/dcache.h:271!
  2003-05-22 11:57 ` Maneesh Soni
@ 2003-05-22 22:19   ` Andrew Morton
  2003-05-23  6:25     ` Jens Axboe
  0 siblings, 1 reply; 6+ messages in thread
From: Andrew Morton @ 2003-05-22 22:19 UTC (permalink / raw)
  To: maneesh, Jens Axboe; +Cc: ivg2, linux-kernel, page0588, greg, tytso

Maneesh Soni <maneesh@in.ibm.com> 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?



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: kernel BUG at include/linux/dcache.h:271!
  2003-05-22 22:19   ` Andrew Morton
@ 2003-05-23  6:25     ` Jens Axboe
  2003-05-23 12:43       ` Maneesh Soni
  0 siblings, 1 reply; 6+ messages in thread
From: Jens Axboe @ 2003-05-23  6:25 UTC (permalink / raw)
  To: Andrew Morton; +Cc: maneesh, ivg2, linux-kernel, page0588, greg, tytso

On Thu, May 22 2003, Andrew Morton wrote:
> Maneesh Soni <maneesh@in.ibm.com> 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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: kernel BUG at include/linux/dcache.h:271!
  2003-05-23  6:25     ` Jens Axboe
@ 2003-05-23 12:43       ` Maneesh Soni
  2003-05-23 12:55         ` Maneesh Soni
  0 siblings, 1 reply; 6+ messages in thread
From: Maneesh Soni @ 2003-05-23 12:43 UTC (permalink / raw)
  To: Jens Axboe; +Cc: Andrew Morton, ivg2, linux-kernel, greg, tytso

On Fri, May 23, 2003 at 08:25:08AM +0200, Jens Axboe wrote:
> On Thu, May 22 2003, Andrew Morton wrote:
> > Maneesh Soni <maneesh@in.ibm.com> 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: maneesh@in.ibm.com
http://lse.sourceforge.net/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: kernel BUG at include/linux/dcache.h:271!
  2003-05-23 12:43       ` Maneesh Soni
@ 2003-05-23 12:55         ` Maneesh Soni
  0 siblings, 0 replies; 6+ messages in thread
From: Maneesh Soni @ 2003-05-23 12:55 UTC (permalink / raw)
  To: Jens Axboe; +Cc: Andrew Morton, ivg2, linux-kernel, greg, tytso

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 <maneesh@in.ibm.com> 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: maneesh@in.ibm.com
http://lse.sourceforge.net/

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2003-05-23 12:40 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-21 23:11 kernel BUG at include/linux/dcache.h:271! Ivan Gyurdiev
2003-05-22 11:57 ` Maneesh Soni
2003-05-22 22:19   ` Andrew Morton
2003-05-23  6:25     ` Jens Axboe
2003-05-23 12:43       ` Maneesh Soni
2003-05-23 12:55         ` Maneesh Soni

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).