From: Chunyan Zhang
commit 0b884fe71f9ee6a5df35e677154256ea2099ebb8 upstream.
If the i2c device SCL bus being pulled up due to some exception before
message transfer done, the system cannot receive the completing interrupt
signal any more, it would not exit waiting loop until MAX_SCHEDULE_TIMEOU
From: Chunyan Zhang
commit 0b884fe71f9ee6a5df35e677154256ea2099ebb8 upstream.
If the i2c device SCL bus being pulled up due to some exception before
message transfer done, the system cannot receive the completing interrupt
signal any more, it would not exit waiting loop until MAX_SCHEDULE_TIMEOU
From: Chunyan Zhang
commit 0b884fe71f9ee6a5df35e677154256ea2099ebb8 upstream.
If the i2c device SCL bus being pulled up due to some exception before
message transfer done, the system cannot receive the completing interrupt
signal any more, it would not exit waiting loop until MAX_SCHEDULE_TIMEOU
From: Chunyan Zhang
commit 0b884fe71f9ee6a5df35e677154256ea2099ebb8 upstream.
If the i2c device SCL bus being pulled up due to some exception before
message transfer done, the system cannot receive the completing interrupt
signal any more, it would not exit waiting loop until MAX_SCHEDULE_TIMEOU
On Tue, 5 Jan 2021 at 02:24, Wolfram Sang wrote:
>
> On Mon, Dec 14, 2020 at 12:58:50PM +0800, Chunyan Zhang wrote:
> > From: Chunyan Zhang
> >
> > If the i2c device SCL bus being pulled up due to some exception before
> > message transfer done, the system cannot receive the completing interrupt
On Mon, Dec 14, 2020 at 12:58:50PM +0800, Chunyan Zhang wrote:
> From: Chunyan Zhang
>
> If the i2c device SCL bus being pulled up due to some exception before
> message transfer done, the system cannot receive the completing interrupt
> signal any more, it would not exit waiting loop until MAX_S
From: Chunyan Zhang
If the i2c device SCL bus being pulled up due to some exception before
message transfer done, the system cannot receive the completing interrupt
signal any more, it would not exit waiting loop until MAX_SCHEDULE_TIMEOUT
jiffies eclipse, that would make the system seemed hang u
umented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Chunyan-Zhang/i2c-sprd-use-a-specific-timeout-to-avoid-system-hang-up-issue/20201211-182817
base: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git
i2c/for-next
config: arm-randc
umented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Chunyan-Zhang/i2c-sprd-use-a-specific-timeout-to-avoid-system-hang-up-issue/20201211-182817
base: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git
i2c/for-next
config: mips-randc
Hi,
thanks for your patch!
> If the i2c device SCL bus being pulled up due to some exception before
> message transfer done, the system cannot receive the completing interrupt
> signal any more, it would not exit waiting loop until MAX_SCHEDULE_TIMEOUT
> jiffies eclipse, that would make the syste
From: Chunyan Zhang
If the i2c device SCL bus being pulled up due to some exception before
message transfer done, the system cannot receive the completing interrupt
signal any more, it would not exit waiting loop until MAX_SCHEDULE_TIMEOUT
jiffies eclipse, that would make the system seemed hang u
rking as RFC, it never went anywhere:
>
> https://patchwork.kernel.org/patch/9657277/
> [RFC] Revert "mwifiex: fix system hang problem after resume"
>
> Cc: Amitkumar Karwar
> Signed-off-by: Brian Norris
> Reviewed-by: Dmitry Torokhov
> Acked-by: Amitkumar Karw
(and in fact, I'm fielding reports of Chromebooks that can't
recover after the aforementioned commit).
Note that this was proposed in 2017 and Ack'ed then, but due to my
marking as RFC, it never went anywhere:
https://patchwork.kernel.org/patch/9657277/
[RFC] Revert "mwifie
Brian Norris writes:
>> Changing the patchwork state to RFC means that it's dropped and out of
>> my radar. Also, if I see "RFC" in the subject I assume that's a patch
>> which I should not apply by default.
>
> Ack. Well, there were some "RFCs" I sent recently that you *did*
> apply, so I didn't
On Fri, Aug 2, 2019 at 6:55 PM Kalle Valo wrote:
>
> Brian Norris writes:
>
> > + Doug, Matthias, who are seeing problems (or, failure to try to
> > recover, as predicted below)
> > + Amit's new email
> > + new maintainers
> >
> > Perhaps it's my fault for marking this RFC. But I changed the stat
Brian Norris writes:
> + Doug, Matthias, who are seeing problems (or, failure to try to
> recover, as predicted below)
> + Amit's new email
> + new maintainers
>
> Perhaps it's my fault for marking this RFC. But I changed the status
> back to "New" in Patchwork, in case that helps:
But I still s
+ Doug, Matthias, who are seeing problems (or, failure to try to
recover, as predicted below)
+ Amit's new email
+ new maintainers
Perhaps it's my fault for marking this RFC. But I changed the status
back to "New" in Patchwork, in case that helps:
On Fri, Mar 31, 2017 at 01:21:36PM -0700, Brian N
4.19-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 3c4b1419c33c2417836a63f8126834ee36968321 ]
Driver doesn't release rtnl lock if registration with
L2 driver (bnxt_re_register_netdev) fais and this causes
hang while requesting for th
From: Selvin Xavier
[ Upstream commit 3c4b1419c33c2417836a63f8126834ee36968321 ]
Driver doesn't release rtnl lock if registration with
L2 driver (bnxt_re_register_netdev) fais and this causes
hang while requesting for the next lock.
[ 371.635416] "echo 0 > /proc/sys/kernel/hung_task_timeout_se
On Tue, 2018-09-11 at 13:58 -0700, Michael Chan wrote:
> On Tue, Sep 11, 2018 at 1:14 PM, Ben Hutchings
> wrote:
> > On Thu, 2018-08-23 at 09:53 +0200, Greg Kroah-Hartman wrote:
> > > 4.4-stable review patch. If anyone has any objections, please
> > > let me know.
> > >
> > > --
On Tue, Sep 11, 2018 at 1:14 PM, Ben Hutchings
wrote:
> On Thu, 2018-08-23 at 09:53 +0200, Greg Kroah-Hartman wrote:
>> 4.4-stable review patch. If anyone has any objections, please let me know.
>>
>> --
>>
>> From: Vikas Gupta
>>
>> [ Upstream commit c58387ab1614f6d7fb9e244f214b
On Thu, 2018-08-23 at 09:53 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Vikas Gupta
>
> [ Upstream commit c58387ab1614f6d7fb9e244f214b61e7631421fc ]
>
> Fix bug in the error code path when bnxt_
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Vikas Gupta
[ Upstream commit c58387ab1614f6d7fb9e244f214b61e7631421fc ]
Fix bug in the error code path when bnxt_request_irq() returns failure.
bnxt_disable_napi() should not be called in this
4.17-stable review patch. If anyone has any objections, please let me know.
--
From: Vikas Gupta
[ Upstream commit c58387ab1614f6d7fb9e244f214b61e7631421fc ]
Fix bug in the error code path when bnxt_request_irq() returns failure.
bnxt_disable_napi() should not be called in thi
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Vikas Gupta
[ Upstream commit c58387ab1614f6d7fb9e244f214b61e7631421fc ]
Fix bug in the error code path when bnxt_request_irq() returns failure.
bnxt_disable_napi() should not be called in thi
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Vikas Gupta
[ Upstream commit c58387ab1614f6d7fb9e244f214b61e7631421fc ]
Fix bug in the error code path when bnxt_request_irq() returns failure.
bnxt_disable_napi() should not be called in this
Dear Bart,
On 04/25/18 14:26, Bart Van Assche wrote:
On Wed, 2018-04-25 at 07:37 +0200, Paul Menzel wrote:
Am 24.04.2018 um 23:17 schrieb Bart Van Assche:
On Tue, 2018-04-24 at 23:04 +0200, Paul Menzel wrote:
I applied your change, and rebuilt the Linux kernel. Unfortunately, it
looks like,
On Wed, 2018-04-25 at 07:37 +0200, Paul Menzel wrote:
> Am 24.04.2018 um 23:17 schrieb Bart Van Assche:
> > On Tue, 2018-04-24 at 23:04 +0200, Paul Menzel wrote:
> > > I applied your change, and rebuilt the Linux kernel. Unfortunately, it
> > > looks like, it didn’t make a difference.
> >
> > In t
Dear Bart,
Am 24.04.2018 um 23:17 schrieb Bart Van Assche:
On Tue, 2018-04-24 at 23:04 +0200, Paul Menzel wrote:
I applied your change, and rebuilt the Linux kernel. Unfortunately, it
looks like, it didn’t make a difference.
In that case I don't know what is causing the failure. Can you run
On Tue, 2018-04-24 at 23:04 +0200, Paul Menzel wrote:
> I applied your change, and rebuilt the Linux kernel. Unfortunately, it
> looks like, it didn’t make a difference.
In that case I don't know what is causing the failure. Can you run a bisect
to determine which commit introduced this regressio
On Tue, 2018-04-24 at 19:37 +0200, Paul Menzel wrote:
> On 04/24/18 19:31, Bart Van Assche wrote:
> Here it is, pasted as citation, as otherwise Thunderbird would wrap the
> line.
>
> > (gdb) disas blk_set_runtime_active
> > Dump of assembler code for function blk_set_runtime_active:
> >0xc15
Dear Bart,
On 04/24/18 19:31, Bart Van Assche wrote:
On Tue, 2018-04-24 at 19:10 +0200, Paul Menzel wrote:
Please find the configuration file attached. The log only has
`initcall_debug no_console_suspend` added.
What I was looking for in the .config is the following:
CONFIG_SCSI_MQ_DEFAULT=y
On Tue, 2018-04-24 at 19:10 +0200, Paul Menzel wrote:
> Please find the configuration file attached. The log only has
> `initcall_debug no_console_suspend` added.
What I was looking for in the .config is the following:
CONFIG_SCSI_MQ_DEFAULT=y
Can you also provide the disassembly output for blk_
On Tue, 2018-04-24 at 18:14 +0200, Paul Menzel wrote:
> Since Linux 4.17-rc1, resume from ACPI on the Lenovo X60 fails because
> of a NULL pointer dereference. As the drive doesn’t come back, messages
> can be seen on the display, but the system cannot be controlled anymore,
> and has to be forc
On Mon, Nov 27, 2017 at 01:10:31PM +, Will Deacon wrote:
> break_lock should be annotated (at least) with READ_ONCE/WRITE_ONCE, which
> should prevent that from happening.
This code long predates all that new fangled stuff ;-)
On Mon, Nov 27, 2017 at 02:00:28PM +0100, Martin Schwidefsky wrote:
> I would opt for removing it entirely.
Like said; I'm not opposed to that. I was just explaining where it came
from (before my time might I add) and how its supposed to 'work' :-)
On Mon, Nov 27, 2017 at 02:00:28PM +0100, Martin Schwidefsky wrote:
> On Mon, 27 Nov 2017 12:54:56 +
> Will Deacon wrote:
> > On Mon, Nov 27, 2017 at 01:49:18PM +0100, Martin Schwidefsky wrote:
> > > On Mon, 27 Nov 2017 11:49:48 +
> > > Will Deacon wrote:
> > > > On Wed, Nov 22, 2017 at
On Mon, 27 Nov 2017, Will Deacon wrote:
> Sebastian: could you try the diff below, please? If that fixes s390, then
> we can debate the merits of GENERIC_LOCKBREAK independently of fixing this
> issue.
>
> Thanks,
>
> Will
>
> --->8
>
> diff --git a/kernel/locking/spinlock.c b/kernel/locking/sp
On Mon, 27 Nov 2017 12:54:56 +
Will Deacon wrote:
> Hi Martin,
>
> On Mon, Nov 27, 2017 at 01:49:18PM +0100, Martin Schwidefsky wrote:
> > On Mon, 27 Nov 2017 11:49:48 +
> > Will Deacon wrote:
> > > On Wed, Nov 22, 2017 at 09:22:17PM +0100, Peter Zijlstra wrote:
> > > > On Wed, Nov
Hi Martin,
On Mon, Nov 27, 2017 at 01:49:18PM +0100, Martin Schwidefsky wrote:
> On Mon, 27 Nov 2017 11:49:48 +
> Will Deacon wrote:
> > On Wed, Nov 22, 2017 at 09:22:17PM +0100, Peter Zijlstra wrote:
> > > On Wed, Nov 22, 2017 at 06:26:59PM +, Will Deacon wrote:
> > >
> > > > Now, I c
On Mon, 27 Nov 2017 11:49:48 +
Will Deacon wrote:
> Hi Peter,
>
> On Wed, Nov 22, 2017 at 09:22:17PM +0100, Peter Zijlstra wrote:
> > On Wed, Nov 22, 2017 at 06:26:59PM +, Will Deacon wrote:
> >
> > > Now, I can't see what the break_lock is doing here other than causing
> > > problems
Me again...
On Mon, Nov 27, 2017 at 11:49:47AM +, Will Deacon wrote:
> On Wed, Nov 22, 2017 at 09:22:17PM +0100, Peter Zijlstra wrote:
> > On Wed, Nov 22, 2017 at 06:26:59PM +, Will Deacon wrote:
> >
> > > Now, I can't see what the break_lock is doing here other than causing
> > > problem
Hi Peter,
On Wed, Nov 22, 2017 at 09:22:17PM +0100, Peter Zijlstra wrote:
> On Wed, Nov 22, 2017 at 06:26:59PM +, Will Deacon wrote:
>
> > Now, I can't see what the break_lock is doing here other than causing
> > problems. Is there a good reason for it, or can you just try removing it
> > alt
On Wed, Nov 22, 2017 at 06:26:59PM +, Will Deacon wrote:
> Now, I can't see what the break_lock is doing here other than causing
> problems. Is there a good reason for it, or can you just try removing it
> altogether? Patch below.
The main use is spin_is_contended(), which in turn ends up use
Hi Sebastian,
On Wed, Nov 22, 2017 at 07:54:54PM +0100, Sebastian Ott wrote:
> On Wed, 22 Nov 2017, Will Deacon wrote:
> > Now, I can't see what the break_lock is doing here other than causing
> > problems. Is there a good reason for it, or can you just try removing it
> > altogether? Patch below.
Hello Will,
On Wed, 22 Nov 2017, Will Deacon wrote:
> Now, I can't see what the break_lock is doing here other than causing
> problems. Is there a good reason for it, or can you just try removing it
> altogether? Patch below.
With your patch applied the system is able to boot again.
I did some qu
Hi Sebastian,
Thanks for the report.
On Wed, Nov 22, 2017 at 06:46:01PM +0100, Sebastian Ott wrote:
> One of my test systems (s390) hangs after boot. One of the cpus is idle
> the other is in arch_spin_relax. Bisect pointed to this one:
>
> a8a217c22116eff6c120d753c9934089fb229af0 is the first b
Hi,
One of my test systems (s390) hangs after boot. One of the cpus is idle
the other is in arch_spin_relax. Bisect pointed to this one:
a8a217c22116eff6c120d753c9934089fb229af0 is the first bad commit
commit a8a217c22116eff6c120d753c9934089fb229af0
Author: Will Deacon
Date: Tue Oct 3 19:25:27
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: "sudarsana.kall...@cavium.com"
[ Upstream commit 62289ba27558553871fd047baadaaeda886c6a63 ]
qed_dcbnl_get_dcbx() API uses kmalloc in GFT_KERNEL mode. The API gets
invoked in the interrupt cont
From: "sudarsana.kall...@cavium.com"
[ Upstream commit 62289ba27558553871fd047baadaaeda886c6a63 ]
qed_dcbnl_get_dcbx() API uses kmalloc in GFT_KERNEL mode. The API gets
invoked in the interrupt context by qed_dcbnl_getdcbx callback. Need
to invoke this kmalloc in atomic mode.
Signed-off-by: Sud
Hi Heiko
On 2017/8/10 17:27, Heiko Stuebner wrote:
Hi Shawn,
Am Donnerstag, 10. August 2017, 16:21:13 CEST schrieb Shawn Lin:
With CONFIG_DEBUG_SHIRQ enabled, the irq tear down routine
would still access the irq handler registed as a shard irq.
Per the comment within the function of __free_irq
Hi Heiko,
On 08/10/2017 05:27 PM, Heiko Stuebner wrote:
Hi Shawn,
Am Donnerstag, 10. August 2017, 16:21:13 CEST schrieb Shawn Lin:
>With CONFIG_DEBUG_SHIRQ enabled, the irq tear down routine
>would still access the irq handler registed as a shard irq.
>Per the comment within the function of __
Hi Shawn,
Am Donnerstag, 10. August 2017, 16:21:13 CEST schrieb Shawn Lin:
> With CONFIG_DEBUG_SHIRQ enabled, the irq tear down routine
> would still access the irq handler registed as a shard irq.
> Per the comment within the function of __free_irq, it says
> "It's a shared IRQ -- the driver ough
Hi shawn,
On 08/10/2017 05:14 PM, Shawn Lin wrote:
Hi Jeffy
On 2017/8/10 16:39, jeffy wrote:
Hi shawn,
On 08/10/2017 04:21 PM, Shawn Lin wrote:
With CONFIG_DEBUG_SHIRQ enabled, the irq tear down routine
would still access the irq handler registed as a shard irq.
Per the comment within the fu
Hi Jeffy
On 2017/8/10 16:39, jeffy wrote:
Hi shawn,
On 08/10/2017 04:21 PM, Shawn Lin wrote:
With CONFIG_DEBUG_SHIRQ enabled, the irq tear down routine
would still access the irq handler registed as a shard irq.
Per the comment within the function of __free_irq, it says
"It's a shared IRQ -- t
Hi shawn,
On 08/10/2017 04:21 PM, Shawn Lin wrote:
With CONFIG_DEBUG_SHIRQ enabled, the irq tear down routine
would still access the irq handler registed as a shard irq.
Per the comment within the function of __free_irq, it says
"It's a shared IRQ -- the driver ought to be prepared for
an IRQ ev
With CONFIG_DEBUG_SHIRQ enabled, the irq tear down routine
would still access the irq handler registed as a shard irq.
Per the comment within the function of __free_irq, it says
"It's a shared IRQ -- the driver ought to be prepared for
an IRQ event to happen even now it's being freed". However
when
From: Geoff Levand
commit 6dff5b67054e17c91bd630bcdda17cfca5aa4215 upstream.
GCC 5 generates different code for this bootwrapper null check that
causes the PS3 to hang very early in its bootup. This check is of
limited value, so just get rid of it.
Signed-off-by: Geoff Levand
Signed-off-by: Mi
On Sat, Apr 1, 2017 at 1:51 AM, Brian Norris wrote:
> This reverts commit 437322ea2a36d112e20aa7282c869bf924b3a836.
>
> This above-mentioned "fix" does not actually do anything to prevent a
> race condition. It simply papers over it so that the issue doesn't
> appear.
>
> If this is a real problem
On Fri, Mar 31, 2017 at 01:21:36PM -0700, Brian Norris wrote:
> This reverts commit 437322ea2a36d112e20aa7282c869bf924b3a836.
>
> This above-mentioned "fix" does not actually do anything to prevent a
> race condition. It simply papers over it so that the issue doesn't
> appear.
>
> If this is a r
This reverts commit 437322ea2a36d112e20aa7282c869bf924b3a836.
This above-mentioned "fix" does not actually do anything to prevent a
race condition. It simply papers over it so that the issue doesn't
appear.
If this is a real problem, it should be explained better than the above
commit does, and a
3.16.42-rc1 review patch. If anyone has any objections, please let me know.
--
From: Geoff Levand
commit 6dff5b67054e17c91bd630bcdda17cfca5aa4215 upstream.
GCC 5 generates different code for this bootwrapper null check that
causes the PS3 to hang very early in its bootup. This
3.2.87-rc1 review patch. If anyone has any objections, please let me know.
--
From: Geoff Levand
commit 6dff5b67054e17c91bd630bcdda17cfca5aa4215 upstream.
GCC 5 generates different code for this bootwrapper null check that
causes the PS3 to hang very early in its bootup. This
From: Geoff Levand
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 6dff5b67054e17c91bd630bcdda17cfca5aa4215 upstream.
GCC 5 generates different code for this bootwrapper null check that
causes the PS3 to hang very early in its bootup. This ch
4.8-stable review patch. If anyone has any objections, please let me know.
--
From: Geoff Levand
commit 6dff5b67054e17c91bd630bcdda17cfca5aa4215 upstream.
GCC 5 generates different code for this bootwrapper null check that
causes the PS3 to hang very early in its bootup. This
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Geoff Levand
commit 6dff5b67054e17c91bd630bcdda17cfca5aa4215 upstream.
GCC 5 generates different code for this bootwrapper null check that
causes the PS3 to hang very early in its bootup. This
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Geoff Levand
commit 6dff5b67054e17c91bd630bcdda17cfca5aa4215 upstream.
GCC 5 generates different code for this bootwrapper null check that
causes the PS3 to hang very early in its bootup. This
From: Chunhao Lin
Date: Mon, 1 Aug 2016 13:45:30 +0800
> If tx timeout event occur, kernel will call rtl8139_tx_timeout_task() to reset
> hardware. But in this function, driver does not stop tx and rx function before
> reset hardware, that will cause system hang.
>
> In this pat
If tx timeout event occur, kernel will call rtl8139_tx_timeout_task() to reset
hardware. But in this function, driver does not stop tx and rx function before
reset hardware, that will cause system hang.
In this patch, add stop tx and rx function before reset hardware.
Signed-off-by: Chunhao Lin
From: Chunhao Lin
Date: Thu, 28 Jul 2016 02:39:57 +0800
> If tx timeout event occur, kernel will call rtl8139_tx_timeout_task() to reset
> hardware. But in this function, driver does not stop tx and rx function before
> reset hardware, that will cause system hang.
>
> In this pat
If tx timeout event occur, kernel will call rtl8139_tx_timeout_task() to reset
hardware. But in this function, driver does not stop tx and rx function before
reset hardware, that will cause system hang.
In this patch, add stop tx and rx function before reset hardware.
Signed-off-by: Chunhao Lin
On 11/17, Alexandre Belloni wrote:
> Commit dca1a4b5ff6e ("clk: at91: keep slow clk enabled to prevent system
> hang") added a workaround for the slow clock as it is not properly handled
> by its users.
>
> Now that the slow clock is taken properly by the drivers,
Commit dca1a4b5ff6e ("clk: at91: keep slow clk enabled to prevent system
hang") added a workaround for the slow clock as it is not properly handled
by its users.
Now that the slow clock is taken properly by the drivers, this workaround
is not necessary anymore, revert it.
Sig
Disregard the previous patch. This version has been tested and is correct.
Previous fix was:
If another debugger or int1 handler is registered, and triggers an int
1 exception, the current code fails to properly detect that an execute
breakpoint has occurred, and does not set the resume flag, ca
If another debugger or int1 handler is registered, and triggers an int
1 exception, the current code fails to properly detect that an execute
breakpoint has occurred, and does not set the resume flag, causing the
system to hang with a recursive int exception for any breakpoint not
defined by an end
Quoting Alexandre Belloni (2015-07-29 17:22:06)
> Commit dca1a4b5ff6e ("clk: at91: keep slow clk enabled to prevent system
> hang") added a workaround for the slow clock as it is not properly handled
> by its users.
>
> Now that the slow clock is taken properly by the
On 31/07/2015 at 14:34:25 -0700, Stephen Boyd wrote :
> Ok that's fine. I added clk.h into this file when I removed clk.h from
> clk-provider.h so that it keeps compiling. Please remind us to pick this up
> when you think it's ready.
>
Ah right, then I'll try to remember to remove it before resen
On 07/31/2015 02:27 PM, Alexandre Belloni wrote:
On 31/07/2015 at 14:11:27 -0700, Stephen Boyd wrote :
On 07/31/2015 02:09 PM, Alexandre Belloni wrote:
On 31/07/2015 at 12:00:28 -0700, Stephen Boyd wrote :
On 07/31/2015 02:39 AM, Alexandre Belloni wrote:
- clk_prepare_enable(slow_clk);
On 31/07/2015 at 14:11:27 -0700, Stephen Boyd wrote :
> On 07/31/2015 02:09 PM, Alexandre Belloni wrote:
> >On 31/07/2015 at 12:00:28 -0700, Stephen Boyd wrote :
> >>On 07/31/2015 02:39 AM, Alexandre Belloni wrote:
> >>>- clk_prepare_enable(slow_clk);
> >>>-
> >>>- return 0;
> >>>-}
> >>>-arch_in
On 07/31/2015 02:09 PM, Alexandre Belloni wrote:
On 31/07/2015 at 12:00:28 -0700, Stephen Boyd wrote :
On 07/31/2015 02:39 AM, Alexandre Belloni wrote:
- clk_prepare_enable(slow_clk);
-
- return 0;
-}
-arch_initcall(of_at91_clk_slow_retain);
Can you drop the include of clk.h in thi
On 31/07/2015 at 12:00:28 -0700, Stephen Boyd wrote :
> On 07/31/2015 02:39 AM, Alexandre Belloni wrote:
> >-clk_prepare_enable(slow_clk);
> >-
> >-return 0;
> >-}
> >-arch_initcall(of_at91_clk_slow_retain);
>
> Can you drop the include of clk.h in this file too?
>
Sure! I will do that i
On 07/31/2015 02:39 AM, Alexandre Belloni wrote:
- clk_prepare_enable(slow_clk);
-
- return 0;
-}
-arch_initcall(of_at91_clk_slow_retain);
Can you drop the include of clk.h in this file too?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Co
Commit dca1a4b5ff6e ("clk: at91: keep slow clk enabled to prevent system
hang") added a workaround for the slow clock as it is not properly handled
by its users.
Now that the slow clock is taken properly by the drivers, this workaround
is not necessary anymore, revert it.
Sig
Commit dca1a4b5ff6e ("clk: at91: keep slow clk enabled to prevent system
hang") added a workaround for the slow clock as it is not properly handled
by its users.
Now that the slow clock is taken properly by the drivers, this workaround
is not necessary anymore, revert it.
Sig
Hi,
On ASUS EeePC 1015PE with kernel 3.18 - 4.1, there is a problem very
similar to the one fixed for Lenovo by the following commit in the
mainline kernel:
commit ab3be73fa7b43f4c3648ce29b5fd649ea54d3adb
drm/i915: gen4: work around hang during hibernation
When I try to put the system
3.16.7-ckt5 -stable review patch. If anyone has any objections, please let me
know.
--
From: Boris Brezillon
commit dca1a4b5ff6e2c25adeff366eb06270dadeab3db upstream.
All slow clk users are not properly claiming it (get + prepare + enable)
before using it.
If all users proper
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Boris Brezillon
commit dca1a4b5ff6e2c25adeff366eb06270dadeab3db upstream.
All slow clk users are not properly claiming it (get + prepare + enable)
before using it.
If all users properly claimi
Quoting Boris Brezillon (2015-01-13 06:44:06)
> All slow clk users are not properly claiming it (get + prepare + enable)
> before using it.
> If all users properly claiming this clock release it, the clock is
> disabled, but faulty users still depends on it, and the system hangs.
>
> This fix prev
All slow clk users are not properly claiming it (get + prepare + enable)
before using it.
If all users properly claiming this clock release it, the clock is
disabled, but faulty users still depends on it, and the system hangs.
This fix prevents the slow clock from being disabled, and should solve
On Mon, 12 Jan 2015 15:44:24 -0800
Mike Turquette wrote:
> Quoting Boris Brezillon (2015-01-12 07:12:50)
> > All slow clk users are not properly requesting it (get + prepare + enable)
> > before using it.
> > If all users properly requesting this clock decide that they don't need it
> > anymore (
All slow clk users are not properly requesting it (get + prepare + enable)
before using it.
If all users properly requesting this clock decide that they don't need it
anymore (or are removed), this lead to this clock being disabled while
faulty users are still requiring it, which in turn hangs the
On Sun, 2014-10-19 at 20:40 +0100, Mark Rutland wrote:
> Hi Mark,
>
> On Sun, Oct 19, 2014 at 04:22:44PM +0100, Mark Salter wrote:
> > Arm allows for two possible architectural clock sources. One memory mapped
> > and the other coprocessor based. If both timers exist, then the driver waits
> > for
Hi Mark,
On Sun, Oct 19, 2014 at 04:22:44PM +0100, Mark Salter wrote:
> Arm allows for two possible architectural clock sources. One memory mapped
> and the other coprocessor based. If both timers exist, then the driver waits
> for both to be probed before registering a clocksource.
>
> Commit c3
Arm allows for two possible architectural clock sources. One memory mapped
and the other coprocessor based. If both timers exist, then the driver waits
for both to be probed before registering a clocksource.
Commit c387f07e6205 ("clocksource: arm_arch_timer: Discard unavailable timers
correctly")
On Thu, Apr 10, 2014 at 07:59:38AM +, Narasimharao Bolisetti wrote:
>
> Hi,
>
> I have checked the same in the recent kernel versions also. Issue is still
> remain.
What versions have you tried, and what are the logs from those versions?
> ::DISCLAIMER::
> -
;
de...@linuxdriverproject.org; linux-ser...@vger.kernel.org;
linux-hotp...@vger.kernel.org; g...@kroah.com; Narasimharao Bolisetti;
nrbolise...@gmail.com; sta...@vger.kernel.org; linux-...@vger.kernel.org;
linux-...@vger.kernel.org
Subject: Re: system hang
On Thu, Apr 10, 2014 at 12:05:52AM
On Thu, Apr 10, 2014 at 12:05:52AM -0700, narasimharo bolisetti wrote:
> My kernel version is:
> 2.6.35.6-45.fc14.i686
Maintenance for this kernel has been dropped years ago, so it very
likely contains many bugs that were fixed in more recent ones. You
should definitely upgrade.
Hoping this he
Hi Greg/All,
This is Narasimharao working for a s/wcompany HCLT..
I am working a issue and
the description is below:
system stops booting and
needs a series of console inputs (space bar or return) to
continue booting. Each input advances the process a little
bit.
Actuall
3.6.11.6 stable review patch.
If anyone has any objections, please let me know.
--
From: =?UTF-8?q?Adis=20Hamzi=C4=87?=
[ Upstream commit e49f3959a96dc279860af7e86e6dbcfda50580a5 ]
The current radeon driver initialization routines, when using KMS, are written
so that the IRQ in
3.5.7.15 -stable review patch. If anyone has any objections, please let me
know.
--
From: =?UTF-8?q?Adis=20Hamzi=C4=87?=
commit e49f3959a96dc279860af7e86e6dbcfda50580a5 upstream.
The current radeon driver initialization routines, when using KMS, are written
so that the IRQ in
1 - 100 of 186 matches
Mail list logo
