From: Sergio Callegari <sergio.callegari@unibo.it>
To: <linux-kernel@vger.kernel.org>
Subject: Re: Regression: commit 045065d breaks kernel on machine with atapi floppy: high IOWAIT, hung processes (bisected)
Date: Sun, 16 Aug 2015 17:01:07 +0200 [thread overview]
Message-ID: <55D0A5B3.202@unibo.it> (raw)
In-Reply-To: <55D09BD8.4090601@unibo.it>
Seems that the issue also affects other systems with different configs:
https://bbs.archlinux.org/viewtopic.php?id=189324
Possibly, the same bug reported in
https://bugzilla.kernel.org/show_bug.cgi?id=87581
A tentative patch was submitted on LKML
https://lkml.org/lkml/2014/11/20/581
I have not tested it yet.
Another possible solution being reported is increasing delay time in
blk_delay_queue(q, SCSI_QUEUE_DELAY)
Not tested yet either.
Threads in 189324 suggests that bug is triggered by mixing a slower
device with a faster one on the same IDE/SATA channel.
Can someone indicate:
- If one of the two patches has already been accepted in recent kernels
or is pending acceptance?
- Which one among the two approaches (extending delay time or modifying
spin locks in scsi_lib.c) is more appropriate for me to test?
Best,
Sergio
On 16/08/2015 16:19, Sergio Callegari wrote:
>
> Hi,
>
> please keep me in CC in answers.
>
> I'd like to report that after commit
>
> [045065d8a300a37218c548e9aa7becd581c6a0e8] [SCSI] fix qemu boot hang
> problem
>
> the kernel is not usable on a machine with an IOMEGA Zip 100 ATAPI drive
> as in:
>
> Model=IOMEGA ZIP 100 ATAPI Floppy, FwRev=12.A, SerialNo=
> Config={ SpinMotCtl Removeable nonMagnetic }
> RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
> BuffType=unknown, BuffSize=unknown, MaxMultSect=0 (maybe): CurCHS=0/0/0,
> CurSects=0, LBA=yes, LBAsects=0
> IORDY=on/off, tPIO={min:500,w/IORDY:180}
> PIO modes: pio0 pio1 pio2 pio3
> AdvancedPM=no
>
> Symptoms include:
>
> - Extremely high IOWAIT in absence of load
> - Kernel reporting hung processes
> - Commands like blkid hanging
> - Inability of the machine to shutdown
>
> Symptoms do not appear immediately, but after some time (anywhere
> between a few minutes and /many hours/ after boot). First symptom is
> IOWAIT suddendly jumping high.
>
> Due to the delay in which symptoms manifest, bisecting has been quite
> painful, but I am now rather sure that the first bad commit is the one
> above.
>
> Other pieces of hardware configuration include:
>
> - ASRock N68S motherboard with AMD Phenom(tm) II X4 920 Processor and
> NVIDIA MCP61 SATA/IDE Chipset
> - IDE drive connected as slave on ide interface where master is HL-DT-ST
> DVD-RAM GH22NP20 CDROM/DVD writer
>
> Issue is weird because the commit seems to merely fix a trivial error in
> logic condition
>
> - if (atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
> + if (!atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
> blk_delay_queue(q, SCSI_QUEUE_DELAY);
>
> Hence, the commit may just end up making visible some other issue.
>
> Best,
>
> Sergio
>
>
next prev parent reply other threads:[~2015-08-16 15:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-16 14:19 Regression: commit 045065d breaks kernel on machine with atapi floppy: high IOWAIT, hung processes (bisected) Sergio Callegari
2015-08-16 15:01 ` Sergio Callegari [this message]
2015-08-16 20:17 ` Regression: commit 045065d breaks kernel on machine with atapi floppy: high IOWAIT, hung processes (patch exists) Sergio Callegari
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=55D0A5B3.202@unibo.it \
--to=sergio.callegari@unibo.it \
--cc=linux-kernel@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.