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?
On Tue, 14 Jan 2003 02:47:40 MST, "Ivan G." <[email protected]> said:
> 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
> 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.
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
On Tue, 14 Jan 2003 [email protected] wrote:
> On Tue, 14 Jan 2003 02:47:40 MST, "Ivan G." <[email protected]> said:
> > 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
> > 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 =====
--- 1.36/drivers/block/elevator.c Sun Jan 12 08:10:40 2003
+++ edited/drivers/block/elevator.c Tue Jan 14 15:46:00 2003
@@ -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 = {
> Could you please try the following patch and see if it fixes the problem?
That fixes it for me.
Thanks.
On Tue, 14 Jan 2003 15:53:26 CST, Patrick Mochel said:
> 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
> ===== drivers/block/elevator.c 1.36 vs edited =====
> --- 1.36/drivers/block/elevator.c Sun Jan 12 08:10:40 2003
> +++ edited/drivers/block/elevator.c Tue Jan 14 15:46:00 2003
> @@ -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 = {
>
>
On Tue, 14 Jan 2003, Ivan G. wrote:
> 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.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.