From: Greg KH <greg@kroah.com>
To: Muni Sekhar <munisekharrms@gmail.com>
Cc: kernelnewbies <kernelnewbies@kernelnewbies.org>
Subject: Re: read the memory mapped address - pcie - kernel hangs
Date: Thu, 9 Jan 2020 12:37:08 +0100 [thread overview]
Message-ID: <20200109113708.GA362921@kroah.com> (raw)
In-Reply-To: <CAHhAz+jvWrcZ6STpbo0OTS-RPZccoszmQLJs_EroU-BG+rDa7Q@mail.gmail.com>
On Thu, Jan 09, 2020 at 04:44:16PM +0530, Muni Sekhar wrote:
> On Thu, Jan 9, 2020 at 1:15 AM Greg KH <greg@kroah.com> wrote:
> >
> > On Thu, Jan 09, 2020 at 12:30:20AM +0530, Muni Sekhar wrote:
> > > Hi All,
> > >
> > > I have module with Xilinx FPGA. It implements UART(s), SPI(s),
> > > parallel I/O and interfaces them to the Host CPU via PCI Express bus.
> > > I see that my system freezes without capturing the crash dump for certain tests.
> > > I debugged this issue and it was tracked down to the ‘readl()’ in
> > > interrupt handler code
> > >
> > > In ISR, first reads the Interrupt Status register using ‘readl()’ as
> > > given below.
> > > status = readl(ctrl->reg + INT_STATUS);
> > >
> > > And then clears the pending interrupts using ‘writel()’ as given blow.
> > > writel(status, ctrl->reg + INT_STATUS);
> > >
> > > I've noticed a kernel hang if INT_STATUS register read again after
> > > clearing the pending interrupts.
> >
> > Why would you read that register again after writing to it?
> >
> > And are you sure you are reading/writing the correct size of the irq
> > field? I thought it was a "word" not "long"? But that might depend on
> > your hardware, do you have a pointer to the kernel driver source you are
> > using for all of this?
> Actually no need to read that register again. But reading that
> register again should not freeze the system, right?
It might, depends on your hardware. Go talk to the hardware vendor if
you have questions about this.
> INT_STATUS register is 32-bit width, so readl() API is used(my system
> is x86_64, Intel(R) Atom(TM) CPU). Instead of readl(), do I need to
> use readw() twice? If so what is reason for this code change?
Ok, if that register is 32 bits, that's fine. It all depends on your
hardware.
> I’m trying to understand why system freezes without any crash dump
> while reading the memory mapped IO from interrupt context?
Because your hardware locked things up?
> FPGA code might be buggy, it may not send the completion for Memory
> Read request. But CPU should not get stuck at LOAD instruction level..
PCI hardware can do lots of bad things to a system, it _IS_ part of the
memory bus, right? So of course it can lock the CPU at a read.
> When it hung, it does not even respond for SYSRQ button(SYSRQ is
> enabled – in normal scenario it works), only way to recover is reboot
> the system. I enabled almost all the kernel.panic* variables. I set
> the kernel.panic to positive, so it should reboot after panic instead
> of just hang. But it’s not rebooting by itself. Even 'pstore\ramoops’
> also not helped.
> After reboot I looked at the kern.log and most of the times it has
> “^@^@^@^ ...“ line just before reboot.
>
> Okay, I will write the minimalistic code to reproduce this one and
> then share with you guys.
What's wrong with the real/full driver source?
And again, why are you trying to read the register twice?
thanks,
greg k-h
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
next prev parent reply other threads:[~2020-01-09 11:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-08 19:00 read the memory mapped address - pcie - kernel hangs Muni Sekhar
2020-01-08 19:45 ` Greg KH
2020-01-09 11:14 ` Muni Sekhar
2020-01-09 11:37 ` Greg KH [this message]
2020-01-09 12:20 ` Muni Sekhar
2020-01-09 18:12 ` Greg KH
2020-01-10 11:15 ` Primoz Beltram
2020-01-10 14:58 ` Muni Sekhar
2020-01-10 23:03 ` Onur Atilla
2020-01-11 3:13 ` Muni Sekhar
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=20200109113708.GA362921@kroah.com \
--to=greg@kroah.com \
--cc=kernelnewbies@kernelnewbies.org \
--cc=munisekharrms@gmail.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;
as well as URLs for NNTP newsgroup(s).