linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thanos Kyritsis <djart@linux.gr>
To: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Cc: Mark Lord <liml@rtr.ca>, linux-ide@vger.kernel.org
Subject: Re: [PROBLEM]: hdparm strange behaviour for 2.6.21 and later
Date: Sun, 24 Jun 2007 20:47:13 +0300	[thread overview]
Message-ID: <200706242047.13466.djart@linux.gr> (raw)
In-Reply-To: <200706232028.58193.bzolnier@gmail.com>

On Saturday 23 June 2007, Bartlomiej Zolnierkiewicz wrote:
> Hi,

Hello, thanks for answering :-D


> Also could you try running UP kernel without PREEMPT and see
> if it makes difference?

Yes, it did make a difference. I've just tried both UP and SMP kernels 
(22-rc5) *without* PREEMPT. Neither of these locked!

I also tried UP with PREEMPT and it locks.

> Adding a couple of printk-s to ide.c::set_using_dma() and
> ide.c::ide_spin_wait_hwgroup() will for sure help in debugging
> it further.

I just tried that as well. I placed printk-s when entering and exiting 
these 2 functions and when they use spin_lock_irq() and 
spin_unlock_irq(), and then watched the output:

I didn't see something odd. For every hdparm execution, set_using_dma() 
is called, it successfully calls ide_spin_wait_hwgroup(), then 
set_using_dma() finishes.
After set_using_dma() finishes, one more ide_spin_wait_hwgroup() 
is called and finishes.

This pattern happens always, no matter if the kernel will eventually 
lock (preempt) or not lock (no preempt), with absolutely no 
differences. 

entering ide.c::set_using_dma()
|
  entering ide.c::ide_spin_wait_hwgroup()
    ide.c::ide_spin_wait_hwgroup: LOCK
  exiting ide.c::ide_spin_wait_hwgroup()
|
ide.c::set_using_dma: set ->busy flag, unlock and let it ride
ide.c::set_using_dma: UNLOCK
ide.c::set_using_dma: lock, clear ->busy flag and unlock before leaving
ide.c::set_using_dma: LOCK
ide.c::set_using_dma: UNLOCK
|
exiting ide.c::set_using_dma()

entering ide.c::ide_spin_wait_hwgroup()
ide.c::ide_spin_wait_hwgroup: LOCK
exiting ide.c::ide_spin_wait_hwgroup()

The above gets printed twice (one for the hda hdparm and one for hdb).

But I noticed something extra. 

Sometimes, the ide_spin_wait_hwgroup() that runs either before the 1st 
set_using_dma() or between the 1st and the 2nd (1st for hda, 2nd for 
hdb) (*but never the one called last*) is waiting A LOT inside the busy 
loop (while (hwgroup->busy)).

I think PREEMPT kernels always produce a lot of this while loop output, 
and then print the above pattern, then lock.

Non-PREEMPT kernels don't always produce the huge while loop output, 
only sometimes, but they never have locking problem.
I don't know if this is at all relevant to the problem. Perhaps it's 
normal that during some of the bootups the IDE device group is busy 
while during other bootups it's not busy, right ?


However, since all functions exit properly, should I try to place 
printk-s in other functions as well ? 

(I kind of need and appreciate guideance in order to help you, because 
I've never been in the kernel hacking business before :) )

> Thanks,
> Bart


-- 
Thanos Kyritsis <djart at linux.gr>

- What's your ONE purpose in life ?
- To explode, of course! ;-)

  reply	other threads:[~2007-06-24 17:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-16 16:58 [PROBLEM]: hdparm strange behaviour for 2.6.21 and later Thanos Kyritsis
2007-06-18 20:01 ` Mark Lord
2007-06-20 15:07   ` Thanos Kyritsis
2007-06-23 18:28     ` Bartlomiej Zolnierkiewicz
2007-06-24 17:47       ` Thanos Kyritsis [this message]
2007-06-27 19:46         ` PREEMPT bug? (was: Re: [PROBLEM]: hdparm strange behaviour for 2.6.21 and later) Bartlomiej Zolnierkiewicz

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=200706242047.13466.djart@linux.gr \
    --to=djart@linux.gr \
    --cc=bzolnier@gmail.com \
    --cc=liml@rtr.ca \
    --cc=linux-ide@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).