From: Jens Axboe <axboe@suse.de>
To: Rachita Kothiyal <rachita@in.ibm.com>
Cc: linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: [RFC] Patch to fix cdrom being confused on using kdump
Date: Tue, 11 Apr 2006 19:03:57 +0200 [thread overview]
Message-ID: <20060411170357.GR4791@suse.de> (raw)
In-Reply-To: <20060411153114.GA5255@in.ibm.com>
On Tue, Apr 11 2006, Rachita Kothiyal wrote:
> On Sun, Apr 09, 2006 at 12:29:42PM +0200, Jens Axboe wrote:
> > On Fri, Apr 07 2006, Rachita Kothiyal wrote:
> >
> > if (stat & DRQ_STAT)
> >
> > checking for DRQ_STAT again doesn't make sense, how can it ever be
> > anything but DRQ_STAT if DRQ_STAT is set?
>
> Hi Jens,
>
> Yes, you are right. The condition itself is redundant there as
> DRQ will always be set there. I will remove it.
Good so far.
> >
> > > + /* DRQ is set. Interrupt not welcome now. Ignore */
> > > + HWIF(drive)->OUTB((stat & 0xEF), IDE_STATUS_REG);
> > > + return ide_stopped;
> >
> > And this looks very wrong, you can't write to the status register. Well
> > you can, but then it's the command register! Writing stat & 0xef to the
> > command register is an odd thing to do. I think you just want to clear
> > the DRQ bit, which should be fine after it was read initially. How about
> >
> >
> > if (stat & DRQ_STAT)
> > return ide_stopped;
> >
> > Can you test that?
>
> I tested this, but I see it fail a couple of times...sometimes it hung
> while booting up the second kernel and sometimes the kernel paniced
> while shutting it down.(attached partial log for panic)
>
> I see your point that writing to the status register is not a good idea.
> I think what we want to do is just ignore this particular interrupt and
> let it continue.
> Am not sure if clearing DRQ bit will achieve this. Please correct me if
> I am wrong, but to clear the DRQ bit also we will have to write to the
> status register.
No, there is not writable status register - that is called the command
register. Just reading the status register is enough to clear the irq,
so if you just want to ignore the interrupt that'll work.
What happens if you rearm the interrupt handler instead of returning
ide_stopped?
--
Jens Axboe
next prev parent reply other threads:[~2006-04-11 17:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-07 13:57 [RFC] Patch to fix cdrom being confused on using kdump Rachita Kothiyal
2006-04-07 15:07 ` Dave Hansen
2006-04-09 10:29 ` Jens Axboe
2006-04-11 15:31 ` Rachita Kothiyal
2006-04-11 17:03 ` Jens Axboe [this message]
2006-04-12 11:29 ` Rachita Kothiyal
2006-04-19 13:29 ` Rachita Kothiyal
2006-04-19 13:52 ` Jens Axboe
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=20060411170357.GR4791@suse.de \
--to=axboe@suse.de \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rachita@in.ibm.com \
/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