From: Marek Vasut <marex@denx.de>
To: Juergen Borleis <jbe@pengutronix.de>
Cc: "Fabio Estevam" <festevam@gmail.com>,
"Shawn Guo" <shawn.guo@freescale.com>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Richard Zhu" <r65037@freescale.com>,
"David Müller (ELSOFT AG)" <d.mueller@elsoft.ch>,
"Sascha Hauer" <kernel@pengutronix.de>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"Tim Harvey" <tharvey@gateworks.com>,
"Fabio Estevam" <fabio.estevam@freescale.com>
Subject: Re: [RFC] PCI: pci-imx6: Add delay to workaround kernel hang
Date: Thu, 26 Jun 2014 11:50:01 +0200 [thread overview]
Message-ID: <201406261150.01965.marex@denx.de> (raw)
In-Reply-To: <201406261126.09235.jbe@pengutronix.de>
On Thursday, June 26, 2014 at 11:26:09 AM, Juergen Borleis wrote:
> Hi Marek,
>
> On Thursday 26 June 2014 11:17:12 Marek Vasut wrote:
> > On Thursday, June 26, 2014 at 09:32:30 AM, Juergen Borleis wrote:
> > > On Thursday 26 June 2014 05:43:19 Fabio Estevam wrote:
> > > > [...]
> > >
> > > > Below is the log with linux-next kernel and earlyprintk enabled:
> > > Does it also hang when you disable "earlyprintk"? A few weeks ago we
> > > had a similar issue with i.MX6/PCI and "earlyprintk" (at the end it
> > > was caused by a clock change for the UART when changing from the early
> > > to the regular console).
> >
> > How can the UART clock have impact on the PCIe please ?
>
> Not to the PCIe hardware, it just hanged the kernel when the PCIe driver
> came up (due to some of its messages it tries to output at this moment).
Another hint, can a blocking msleep() hang the driver ? The driver probes in
fs_initcall stage, I'm not sure if it cannot hit some kind of a problem when
using the msleep() ? It's unlikely though ...
Best regards,
Marek Vasut
WARNING: multiple messages have this Message-ID (diff)
From: marex@denx.de (Marek Vasut)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] PCI: pci-imx6: Add delay to workaround kernel hang
Date: Thu, 26 Jun 2014 11:50:01 +0200 [thread overview]
Message-ID: <201406261150.01965.marex@denx.de> (raw)
In-Reply-To: <201406261126.09235.jbe@pengutronix.de>
On Thursday, June 26, 2014 at 11:26:09 AM, Juergen Borleis wrote:
> Hi Marek,
>
> On Thursday 26 June 2014 11:17:12 Marek Vasut wrote:
> > On Thursday, June 26, 2014 at 09:32:30 AM, Juergen Borleis wrote:
> > > On Thursday 26 June 2014 05:43:19 Fabio Estevam wrote:
> > > > [...]
> > >
> > > > Below is the log with linux-next kernel and earlyprintk enabled:
> > > Does it also hang when you disable "earlyprintk"? A few weeks ago we
> > > had a similar issue with i.MX6/PCI and "earlyprintk" (at the end it
> > > was caused by a clock change for the UART when changing from the early
> > > to the regular console).
> >
> > How can the UART clock have impact on the PCIe please ?
>
> Not to the PCIe hardware, it just hanged the kernel when the PCIe driver
> came up (due to some of its messages it tries to output at this moment).
Another hint, can a blocking msleep() hang the driver ? The driver probes in
fs_initcall stage, I'm not sure if it cannot hit some kind of a problem when
using the msleep() ? It's unlikely though ...
Best regards,
Marek Vasut
next prev parent reply other threads:[~2014-06-26 9:50 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-24 19:18 [RFC] PCI: pci-imx6: Add delay to workaround kernel hang Fabio Estevam
2014-06-24 19:18 ` Fabio Estevam
2014-06-25 21:28 ` Marek Vasut
2014-06-25 21:28 ` Marek Vasut
2014-06-26 3:12 ` Shawn Guo
2014-06-26 3:12 ` Shawn Guo
2014-06-26 3:43 ` Fabio Estevam
2014-06-26 3:43 ` Fabio Estevam
2014-06-26 5:49 ` Shawn Guo
2014-06-26 5:49 ` Shawn Guo
2014-06-26 9:13 ` Marek Vasut
2014-06-26 9:13 ` Marek Vasut
2014-06-27 0:29 ` Tim Harvey
2014-06-27 0:29 ` Tim Harvey
2014-06-27 10:06 ` Hong-Xing.Zhu
2014-06-27 10:06 ` Hong-Xing.Zhu at freescale.com
2014-07-17 0:28 ` Tim Harvey
2014-07-17 0:28 ` Tim Harvey
2014-07-18 9:26 ` Lucas Stach
2014-07-18 9:26 ` Lucas Stach
2014-07-18 9:44 ` Marek Vasut
2014-07-18 9:44 ` Marek Vasut
2014-07-18 11:44 ` "David Müller (ELSOFT AG)"
2014-07-18 11:44 ` "David Müller (ELSOFT AG)"
2014-06-26 7:32 ` Juergen Borleis
2014-06-26 7:32 ` Juergen Borleis
2014-06-26 9:17 ` Marek Vasut
2014-06-26 9:17 ` Marek Vasut
2014-06-26 9:26 ` Juergen Borleis
2014-06-26 9:26 ` Juergen Borleis
2014-06-26 9:50 ` Marek Vasut [this message]
2014-06-26 9:50 ` Marek Vasut
2014-06-26 11:43 ` Fabio Estevam
2014-06-26 11:43 ` Fabio Estevam
2014-06-26 8:41 ` Lucas Stach
2014-06-26 8:41 ` Lucas Stach
2014-07-17 6:51 ` Uwe Kleine-König
2014-07-17 6:51 ` Uwe Kleine-König
2014-07-17 8:23 ` Marek Vasut
2014-07-17 8:23 ` Marek Vasut
2014-07-17 15:27 ` Shawn Guo
2014-07-17 15:27 ` Shawn Guo
2014-07-18 20:46 ` Marek Vasut
2014-07-18 20:46 ` Marek Vasut
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=201406261150.01965.marex@denx.de \
--to=marex@denx.de \
--cc=bhelgaas@google.com \
--cc=d.mueller@elsoft.ch \
--cc=fabio.estevam@freescale.com \
--cc=festevam@gmail.com \
--cc=jbe@pengutronix.de \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=r65037@freescale.com \
--cc=shawn.guo@freescale.com \
--cc=tharvey@gateworks.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 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.