All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: linux-scsi@vger.kernel.org
Subject: [Bug 207855] arcconf host reset causes kernel panic -> driver crash?
Date: Wed, 15 Jul 2020 08:45:00 +0000	[thread overview]
Message-ID: <bug-207855-11613-8mf35y1REE@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-207855-11613@https.bugzilla.kernel.org/>

https://bugzilla.kernel.org/show_bug.cgi?id=207855

--- Comment #11 from Janpieter Sollie (janpieter.sollie@edpnet.be) ---
the issue seems to be related to:

> [59502.794967] Call Trace:
> [59502.794967]  _raw_spin_lock_irqsave+0x20/0x30
> [59502.794968]  __scsi_iterate_devices+0x22/0x80
> [59502.794968]  scsi_eh_ready_devs+0x129/0x7c0
> [59502.794968]  ? __pm_runtime_resume+0x54/0x70
> [59502.794968]  scsi_error_handler+0x394/0x3a0
> [59502.794969]  kthread+0xf3/0x130
> [59502.794969]  ? scsi_eh_get_sense+0x120/0x120
> [59502.794969]  ? kthread_park+0x80/0x80
> [59502.794970]  ret_from_fork+0x1f/0x30

As far as I see, this stack blocks the entire scsi subsystem.
I do not see why: the scsi_error_handler runs in a separate kthread, so it
*should* not block the IO subsystem ... but it definitely does: all storage
devices on all SAS/SATA controllers (even USB) become inaccessible.  I managed
to get a dmesg out of it, but "echo 1 >
/sys/class/pci_bus/0000\:04/device/reset"
never completed.  this command was issued over a running SSH session.  A new
session could not be established any longer.  But it proves the PCI subsystem
is partially intact.

is it possible the raw_spin_lock_irqsave hurts when the adapter is not ready
yet? and as such locks a device but never completes?

-- 
You are receiving this mail because:
You are the assignee for the bug.

  parent reply	other threads:[~2020-07-15  8:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-22  8:49 [Bug 207855] New: arcconf host reset causes kernel panic -> driver crash? bugzilla-daemon
2020-05-22  9:19 ` [Bug 207855] " bugzilla-daemon
2020-05-22  9:40 ` bugzilla-daemon
2020-05-23 16:29 ` bugzilla-daemon
2020-05-23 17:53 ` bugzilla-daemon
2020-05-23 18:38 ` bugzilla-daemon
2020-05-23 19:09 ` bugzilla-daemon
2020-06-06  9:01 ` bugzilla-daemon
2020-07-13 11:46 ` bugzilla-daemon
2020-07-13 11:47 ` bugzilla-daemon
2020-07-13 19:10 ` bugzilla-daemon
2020-07-15  8:45 ` bugzilla-daemon [this message]
2020-07-15  8:50 ` bugzilla-daemon
2020-07-19  6:36 ` bugzilla-daemon
2020-11-07 17:11 ` bugzilla-daemon

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=bug-207855-11613-8mf35y1REE@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=linux-scsi@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.