Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#10444 - Kernel log stack trace on boot and boot very long time.
Attached to Project:
Arch Linux
Opened by Andrey Gusev (metal) - Sunday, 18 May 2008, 15:57 GMT
Last edited by Greg (dolby) - Thursday, 12 June 2008, 20:18 GMT
Opened by Andrey Gusev (metal) - Sunday, 18 May 2008, 15:57 GMT
Last edited by Greg (dolby) - Thursday, 12 June 2008, 20:18 GMT
|
DetailsDescription: Kernel log stack trace on boot and boot very long time.
Usually, I use my own kernel build of last vanilla. So, I boot arch linux kernel very rarely. Today, I booted it and it failed to boot. Booting stopped after stack trace, but it continue latter. Booting take a lot of time and some things failed. Full dmesg is in attach. Additional info: * kernel26 2.6.24.4-1 * part of dmesg: Driver 'sr' needs updating - please use bus_type methods sr0: scsi3-mmc drive: 1x/24x writer cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 sr 1:0:0:0: Attached scsi CD-ROM sr0 BUG: unable to handle kernel NULL pointer dereference at virtual address 00000200 printing eip: c02c5a31 *pde = 00000000 Oops: 0002 [#1] PREEMPT SMP Modules linked in: sr_mod cdrom generic piix ide_core ata_piix libata ext3 jbd ext2 mbcache sd_mod Pid: 980, comm: cdrom_id Not tainted (2.6.24-ARCH #1) EIP: 0060:[<c02c5a31>] EFLAGS: 00010246 CPU: 0 EIP is at scsi_normalize_sense+0x41/0x100 EAX: 00000000 EBX: f7c0dea0 ECX: 00000002 EDX: 00000060 ESI: 00000060 EDI: 00000200 EBP: 00000200 ESP: f7403c5c DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 Process cdrom_id (pid: 980, ti=f7402000 task=f7ff8ff0 task.ti=f7402000) Stack: 08000002 f7c0dea0 00000003 f7403cbe c02c976b 00000000 00000000 f7c0dea0 00002328 00000003 00000000 f7f36800 00000003 00000200 00000001 f7f36800 c02c983f 00000000 00000000 00000200 00002328 00000003 00002328 01000001 Call Trace: [<c02c976b>] scsi_execute_req+0x8b/0xf0 [<c02c983f>] scsi_test_unit_ready+0x6f/0x120 [<f8896122>] sr_media_change+0x52/0x240 [sr_mod] [<f88a208d>] media_changed+0x5d/0xa0 [cdrom] [<c01b0fdc>] check_disk_change+0x1c/0x80 [<f88a6528>] cdrom_open+0x148/0xa70 [cdrom] [<c01762e5>] __vma_link+0x45/0x80 [<c0176380>] vma_link+0x60/0x100 [<c019c113>] __d_lookup+0x143/0x160 [<c0190f1b>] do_lookup+0xeb/0x1b0 [<c019b398>] dput+0x78/0x100 [<c0192be0>] __link_path_walk+0x6b0/0xe00 [<c01a04e3>] mntput_no_expire+0x13/0x70 [<c01933ee>] link_path_walk+0xbe/0xd0 [<c03850d4>] __mutex_lock_slowpath+0x234/0x2e0 [<c01871e2>] get_unused_fd_flags+0xa2/0xe0 [<c03850d4>] __mutex_lock_slowpath+0x234/0x2e0 [<c024e4df>] kobject_get+0xf/0x20 [<f889643c>] sr_block_open+0x8c/0xa0 [sr_mod] [<c01b1927>] do_open+0x77/0x2d0 [<c01b0910>] bdev_set+0x0/0x10 [<c01b1bb0>] blkdev_open+0x30/0x70 [<c018730d>] __dentry_open+0xdd/0x220 [<c0187505>] nameidata_to_filp+0x35/0x40 [<c01b1b80>] blkdev_open+0x0/0x70 [<c0187561>] do_filp_open+0x51/0x70 [<c01871e2>] get_unused_fd_flags+0xa2/0xe0 [<c01875df>] do_sys_open+0x5f/0xf0 [<c01876ac>] sys_open+0x1c/0x20 [<c01055fa>] syscall_call+0x7/0xb [<c0380000>] wext_handle_ioctl+0xa0/0x490 ======================= Code: 89 7c 24 08 74 04 85 d2 75 18 31 c0 8b 1c 24 8b 74 24 04 8b 7c 24 08 8b 6c 24 0c 83 c4 10 c3 8d 76 00 b9 02 00 00 00 89 ef 31 c0 <f3> ab 0f b6 13 83 e2 7f 89 d0 83 e0 70 83 f8 70 88 55 00 75 ca EIP: [<c02c5a31>] scsi_normalize_sense+0x41/0x100 SS:ESP 0068:f7403c5c ---[ end trace e8fbbf1337858a9e ]--- Steps to reproduce: 1) Boot archlinux kernel on my machine. |
This task depends upon
Comment by Andrey Gusev (metal) -
Sunday, 18 May 2008, 16:01 GMT
I forgot to write. My own 2.6.25.4 boots good and I didn't have trouble with 2.6.24.*.
Comment by Jan de Groot (JGC) -
Sunday, 18 May 2008, 21:40 GMT
Could you try kernel26 from testing, which is 2.6.25.x?
Comment by Andrey Gusev (metal) -
Monday, 19 May 2008, 20:05 GMT
I can't make to boot kernel from testing. It writes that can't read depmod. I edited mkinitcpio.conf, but it doesn't help. Is the any seriously changes in this kernel?
Comment by Andrey Gusev (metal) -
Saturday, 31 May 2008, 16:27 GMT
I have booted kernel 2.6.25-ARCH. So this bug don't repeat now. But i changed configuration of /et/mkinitcpio.conf a lot. So, I wrote all necessary modules by hands. Changing name of initrd image was reason of fault booting kernel. I use lilo, because old initrd boot and there weren't modules for 2.6.25. Why it didn't wrate in news? I think, many people have problem with kernel 2.6.25 by this reason. It need to be attentional :)
Comment by Andrey Gusev (metal) -
Thursday, 12 June 2008, 19:57 GMT
I wrote int /etc/mkinitcpio.conf same modules as in bug. Reinstalled kernel. Booting is normal. So, I think this bug could be closed. udev events takes a long time (72000ms on my own kernel 2756ms), but I think is common problem and not related to this bug.