From: "Michal Šmucr" <msmucr@gmail.com>
To: linux-rt-users@vger.kernel.org
Subject: Kenrel panic with 3.18.7-rt2 - rootfs at MMC
Date: Tue, 24 Feb 2015 10:46:39 +0100 [thread overview]
Message-ID: <54EC487F.8020109@gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 550 bytes --]
Hello to all,
I'm getting kernel panics, when I'm using kernel 3.18.7 with recently
released rt1 and rt2 patches. Platform is x86_64.
It happens only when root filesystem is at SDHC card.
At 3.14.31-rt28 or recent plain vanilla kernels I haven't spotted this
issue.
Boot panic is possible to workaround by adding kernel parameter:
"scsi_mod.scan=sync", but it still happens during initrd rebuild using
update-initramfs at Debian Jessie.
Log from panic is attached.
Thanks for any comment regarding issue or better way for bug-report,
Michal
[-- Attachment #2: panic-mmc-3.18.7-rt2.log --]
[-- Type: text/plain, Size: 3591 bytes --]
[ 3.184053] task: ffff880036e17170 ti: ffff880036f4c000 task.ti: ffff880036f4c000
[ 3.184076] RIP: 0010:[<ffffffff816d2168>] [<ffffffff816d2168>] rt_spin_lock_slowlock+0x238/0x250
[ 3.184082] RSP: 0018:ffff880079403dc8 EFLAGS: 00010046
[ 3.184086] RAX: ffff880036e17170 RBX: ffff880075394790 RCX: 0000000000000001
[ 3.184090] RDX: 0000000000000000 RSI: ffff880036e17170 RDI: ffff880075394790
[ 3.184095] RBP: ffff880079403de0 R08: ffff880036e17170 R09: ffff8800753947a8
[ 3.184099] R10: ffff880036e17171 R11: 0000000000000000 R12: ffff880036e17170
[ 3.184103] R13: 0000000000000000 R14: ffff88007a9a2e00 R15: ffff880075394600
[ 3.184110] FS: 0000000000000000(0000) GS:ffff880079400000(0000) knlGS:0000000000000000
[ 3.184115] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 3.184119] CR2: 00007f2224bd7000 CR3: 0000000036da1000 CR4: 00000000001007f0
[ 3.184121] Stack:
[ 3.184132] ffff8800751ce720 ffffffff81c575c0 ffffffff81d13480 ffff880079403de0
[ 3.184140] 0000000000000000 0000000000000086 ffff880079403df8 ffff88007940dac0
[ 3.184148] ffffffff81c575c0 0000000000000000 0000000000000086 0000000000000001
[ 3.184150] Call Trace:
[ 3.184160] <IRQ>
[ 3.184172] [<ffffffff8158e79f>] ? sdhci_irq+0x2f/0x930
[ 3.184186] [<ffffffff810a7d1f>] ? dequeue_rt_stack+0x4f/0x230
[ 3.184198] [<ffffffff810c13ad>] ? handle_irq_event_percpu+0x4d/0x200
[ 3.184207] [<ffffffff816d075d>] ? preempt_schedule_irq+0x3d/0x70
[ 3.184217] [<ffffffff810c15b4>] ? handle_irq_event+0x54/0x80
[ 3.184227] [<ffffffff810c45f7>] ? handle_fasteoi_irq+0xd7/0x1a0
[ 3.184240] [<ffffffff810176cd>] ? handle_irq+0x1d/0x30
[ 3.184250] [<ffffffff816d6bc4>] ? do_IRQ+0x54/0xf0
[ 3.184260] [<ffffffff816d4a6d>] ? common_interrupt+0x6d/0x6d
[ 3.184265] <EOI>
[ 3.184278] [<ffffffff812f4fe9>] ? check_preemption_disabled+0xa9/0x160
[ 3.184288] [<ffffffff816d075d>] ? preempt_schedule_irq+0x3d/0x70
[ 3.184299] [<ffffffff816d4c50>] ? retint_kernel+0x20/0x30
[ 3.184313] [<ffffffff8158d138>] ? sdhci_send_command+0x348/0xd10
[ 3.184324] [<ffffffff8158e098>] ? sdhci_request+0xc8/0x1f0
[ 3.184337] [<ffffffff8157be85>] ? mmc_start_req+0x305/0x400
[ 3.184353] [<ffffffffa001d9a6>] ? mmc_blk_rw_rq_prep+0x1f6/0x4a0 [mmc_block]
[ 3.184366] [<ffffffffa001fca0>] ? mmc_blk_issue_rw_rq+0xe0/0xb80 [mmc_block]
[ 3.184379] [<ffffffff81099400>] ? wake_up_state+0x20/0x20
[ 3.184392] [<ffffffffa002094c>] ? mmc_blk_issue_rq+0x20c/0x550 [mmc_block]
[ 3.184404] [<ffffffff8106d792>] ? unpin_current_cpu+0x12/0x70
[ 3.184416] [<ffffffffa0020d70>] ? mmc_queue_thread+0xe0/0x1f0 [mmc_block]
[ 3.184429] [<ffffffffa0020c90>] ? mmc_blk_issue_rq+0x550/0x550 [mmc_block]
[ 3.184439] [<ffffffff8108c165>] ? kthread+0xc5/0xe0
[ 3.184449] [<ffffffff8108c0a0>] ? kthread_worker_fn+0x1d0/0x1d0
[ 3.184459] [<ffffffff816d3d7c>] ? ret_from_fork+0x7c/0xb0
[ 3.184469] [<ffffffff8108c0a0>] ? kthread_worker_fn+0x1d0/0x1d0
[ 3.184558] Code: 00 00 00 e8 db 63 9f ff e9 b3 fe ff ff 66 0f 1f 44 00 00 48 8b 43 10 48 3b 58 38 75 21 48 39 e8 75 a7 0f 0b 0f 1f 80 00 00 00 00 <0f> 0b 66 0f 1f 44 00 00 0f 0b 0f 0b e8 b9 67 c1 ff eb ac e8 10
[ 3.184567] RIP [<ffffffff816d2168>] rt_spin_lock_slowlock+0x238/0x250
[ 3.184570] RSP <ffff880079403dc8>
[ 3.559610] ---[ end trace 0000000000000002 ]---
[ 3.559615] Kernel panic - not syncing: Fatal exception in interrupt
[ 3.559936] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)
next reply other threads:[~2015-02-24 9:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-24 9:46 Michal Šmucr [this message]
2015-02-26 11:29 ` [RT PATCH] mmc: sdhci: don't provide hard irq handler Sebastian Andrzej Siewior
2015-02-27 9:33 ` Michal Šmucr
2015-03-02 1:25 ` Kenrel panic with 3.18.7-rt2 - rootfs at MMC Paul Gortmaker
2015-03-02 1:31 ` Paul Gortmaker
2015-03-02 11:43 ` Michal Šmucr
2015-03-02 3:34 ` Ralf Mardorf
2015-03-06 12:24 ` Sebastian Andrzej Siewior
-- strict thread matches above, loose matches on Subject: below --
2015-03-06 16:43 Ralf Mardorf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54EC487F.8020109@gmail.com \
--to=msmucr@gmail.com \
--cc=linux-rt-users@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.