Skip to contentSkip to conversation

2.5.58 Oops when booting from initrd - kobject_del

DISCUSSION Ivan G. 4 participants 6 messages Jan 14, 2003 – Jan 16, 2003 Block layer

lore
Share & tools
lore

Ivan G.

author
#0 lore raw

Kernel: 2.5.58 (everything but the tag changeset)

My attempt to boot an initrd resulted in the following oops:
(scribbled down important parts)
=======================================================
unable to handle kernel NULL pointer at virtual address 00000064
...
EIP at sysfs_remove_dir + 0xb/0x140
...
Process swapper (pid:1, threadinfo=c3fca000 ...
...

Call Trace:
==========
kobject_del+0x13/0x30
kobject_unregister+0x13/0x30
elv_unregister_queue+0x1c/0x30
unlink_gendisk+0x13/0x40
del_gendisk+0x80/0x140
initrd_release+0x4e/0x90
__fput+0xf1/0x100
filp_close+0x74/0xa0
sys_close+0x62/0xa0
syscall_call+0x7/0xb
prepare_namespace+0x13a/0x1b0
init+0x3a/0x160
init+0x0/0x160
kernel_thread_helper+0x5/0x18
...
Code: 8b 70 28 85 f6 0f 84 1e 01 00 00 8b 06 85 c0 75 08 0f 0b 02
=========================================================

Last I checked initrd worked fine in 2.5.56
============================================================

Another two minor questions for whoever might read this.

- Would it be possible to make Kconfig remember the location from which the config file was last loaded? It would be more convenient that way.

- Is Jaroslav Kysela, <[email protected]> the current ALSA maintainer as listed in MAINTAINERS for 2.5.58?

#1 lore raw
Quoted 17 lines · Ivan G.

Kernel: 2.5.58 (everything but the tag changeset)

My attempt to boot an initrd resulted in the following oops:
(scribbled down important parts)
=======================================================
unable to handle kernel NULL pointer at virtual address 00000064

Call Trace:
==========
kobject_del+0x13/0x30
kobject_unregister+0x13/0x30
elv_unregister_queue+0x1c/0x30
unlink_gendisk+0x13/0x40
del_gendisk+0x80/0x140
initrd_release+0x4e/0x90
__fput+0xf1/0x100
filp_close+0x74/0xa0
Quoted 8 lines
sys_close+0x62/0xa0
syscall_call+0x7/0xb
prepare_namespace+0x13a/0x1b0
init+0x3a/0x160
init+0x0/0x160
kernel_thread_helper+0x5/0x18
...
Code: 8b 70 28 85 f6 0f 84 1e 01 00 00 8b 06 85 c0 75 08 0f 0b 02

I got bit by this one too. Just for grins, I did a 'make clean' and then rebuilt - same compiler and config - and the bzImage ended up one byte shorter.

A diff of the System.map files is interesting:

diff -c /boot/System.map-2.5.58 System.map
*** /boot/System.map-2.5.58 2003-01-14 01:47:27.000000000 -0500
--- System.map 2003-01-14 12:57:30.000000000 -0500
***************
*** 1,5 ****
0000002a A snd_minor_info_done
! 00000080 A _binary_usr_initramfs_data_cpio_gz_size
000000dd A snd_card_info_done
000000fc A snd_memory_info_done
0000011b A snd_info_done
--- 1,5 ----
0000002a A snd_minor_info_done
! 0000007f A _binary_usr_initramfs_data_cpio_gz_size
000000dd A snd_card_info_done
000000fc A snd_memory_info_done
0000011b A snd_info_done
***************
*** 21863,21872 ****
c044d940 A __initcall_end
c044e000 A __initramfs_start
c044e000 T _binary_usr_initramfs_data_cpio_gz_start
! c044e080 A __initramfs_end
c044e080 A __per_cpu_end
c044e080 A __per_cpu_start
- c044e080 T _binary_usr_initramfs_data_cpio_gz_end c044f000 A __bss_start
c044f000 A __init_end
c044f000 B rows
--- 21863,21872 ----
c044d940 A __initcall_end
c044e000 A __initramfs_start
c044e000 T _binary_usr_initramfs_data_cpio_gz_start
! c044e07f A __initramfs_end
! c044e07f T _binary_usr_initramfs_data_cpio_gz_end
c044e080 A __per_cpu_end
c044e080 A __per_cpu_start
c044f000 A __bss_start
c044f000 A __init_end
c044f000 B rows

After a 'make clean', the size dropped from 0x80 to 0x7f - this cleaned up the one-byte overlap between per_cpu_start and cpio_gz_end, which looks suspicious to me. I'll try booting the new kernel when I get a chance.

Signature · 3 lines
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech
#2 lore raw
Quoted 18 lines · On Tue, 14 Jan 2003 [email protected] wrote:
Quoted 17 lines · Ivan G.

Kernel: 2.5.58 (everything but the tag changeset)

My attempt to boot an initrd resulted in the following oops:
(scribbled down important parts)
=======================================================
unable to handle kernel NULL pointer at virtual address 00000064

Call Trace:
==========
kobject_del+0x13/0x30
kobject_unregister+0x13/0x30
elv_unregister_queue+0x1c/0x30
unlink_gendisk+0x13/0x40
del_gendisk+0x80/0x140
initrd_release+0x4e/0x90
__fput+0xf1/0x100
filp_close+0x74/0xa0
Quoted 8 lines
Quoted 8 lines
sys_close+0x62/0xa0
syscall_call+0x7/0xb
prepare_namespace+0x13a/0x1b0
init+0x3a/0x160
init+0x0/0x160
kernel_thread_helper+0x5/0x18
...
Code: 8b 70 28 85 f6 0f 84 1e 01 00 00 8b 06 85 c0 75 08 0f 0b 02

Could you please try the following patch and see if it fixes the problem?

Thanks,

-pat

===== drivers/block/elevator.c 1.36 vs edited =====

drivers/block/elevator.c +6 -3
@@ -431,10 +431,13 @@
 void elv_unregister_queue(struct gendisk *disk)
 {
 	request_queue_t *q = disk->queue;
-	elevator_t *e = &q->elevator;
+	elevator_t *e;
 
-	kobject_unregister(&e->kobj);
-	kobject_put(&disk->kobj);
+	if (q) {
+		e = &q->elevator;
+		kobject_unregister(&e->kobj);
+		kobject_put(&disk->kobj);
+	}
 }
 
 elevator_t elevator_noop = {
author
#3 lore raw
Quoted 2 lines

Could you please try the following patch and see if it fixes the problem?

That fixes it for me.
Thanks.

#4 lore raw
In reply to Patrick Mochel
Quoted 1 line · Patrick Mochel

Could you please try the following patch and see if it fixes the problem?

This fix worked for me.. am on 2.5.58 right now.... Many thanks..

/Valdis

Quoted 22 lines

===== drivers/block/elevator.c 1.36 vs edited =====

drivers/block/elevator.c +6 -3
@@ -431,10 +431,13 @@
 void elv_unregister_queue(struct gendisk *disk)
 {
 	request_queue_t *q = disk->queue;
-	elevator_t *e = &q->elevator;
+	elevator_t *e;
 
-	kobject_unregister(&e->kobj);
-	kobject_put(&disk->kobj);
+	if (q) {
+		e = &q->elevator;
+		kobject_unregister(&e->kobj);
+		kobject_put(&disk->kobj);
+	}
 }
 
 elevator_t elevator_noop = {
#5 lore raw
In reply to Ivan G.
Quoted 4 lines · Ivan G.

Kernel: 2.5.58 (everything but the tag changeset)

My attempt to boot an initrd resulted in the following oops:
(scribbled down important parts)

I have been asking the same question for some weeks, mkinitrd doesn't seem to create a proper file (at least the RH 8.0) and building by hand doesn't load the driver for the root f/s. I asked for doc on what's needed for 2.5 initrd (my hand build 2.4 works) without answers. I assume everyone is just too busy to respond.

Signature · 3 lines
bill davidsen <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.