Hi,
the c04e6e9 patch
gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading
broke display connected to a TQMa53 i.MX53 board. The lines
imx-drm display-subsystem: bound imx-ipuv3-crtc.0 (ops ipu_crtc_ops)
imx-drm display-subsystem: bound imx-ipuv3-crtc.1 (ops ipu_crtc_ops)
are not present anymore
3 and i.MX28")
Tested-by: Stefan Wahren
Signed-off-by: Stanislav Meduna
---
drivers/nvmem/mxs-ocotp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/nvmem/mxs-ocotp.c b/drivers/nvmem/mxs-ocotp.c
index 8ba19bb..2bb3c57 100644
--- a/drivers/nvmem/mxs-ocotp.c
+++
This patch fixes the issue where the mxs_ocotp_read is reading
the ocotp in reg_size steps but decrements the remaining size
by 1. The number of iterations is thus four times higher,
overwriting the area behind the output buffer.
Fixes: c01e9a11ab6f ("nvmem: add driver for ocotp in i.MX23 and i.MX
On 17.02.2015 15:01, Sebastian Andrzej Siewior wrote:
Hi,
>> something between 3.12.19(-rt30) and 3.12.31(-rt45) broke
>> hrtimers on (at least) i.MX28 for CONFIG_HZ_PERIODIC.
>> Switching to CONFIG_NO_HZ_IDLE restores them.
>>
>> Is this the expected behaviour or a regression?
> No, I don't thi
Hi,
something between 3.12.19(-rt30) and 3.12.31(-rt45) broke
hrtimers on (at least) i.MX28 for CONFIG_HZ_PERIODIC.
Switching to CONFIG_NO_HZ_IDLE restores them.
Is this the expected behaviour or a regression?
The difference in the /proc/timer_list is the
Tick Device: mode: 0 (new) or 1 (ol
On 26.05.2014 11:26, Arnd Bergmann wrote:
> It seems like the right thing to do, I just don't understand
> why nobody hit this before.
Looks like this is what I did hit a month ago and
was not able to find the culprit:
http://www.spinics.net/lists/linux-rt-users/msg11656.html
> How exactly do yo
Hi,
this is on a i.MX28 running a 3.12.19-rt30
[27284.008123] BUG: sleeping function called from invalid context at
/home/nxtdev/Kernels/linux-stable-rt/kernel/rtmutex.c:673
[27284.008143] in_atomic(): 0, irqs_disabled(): 128, pid: 1335, name: nxt
[27284.008170] CPU: 0 PID: 1335 Comm: nxt Not ta
Hi,
is there any particular reason why the FEC_QUIRK_HAS_VLAN
is only set for imx6q-fec ?
According to the reference manual the VLAN support is also
present in i.MX28 and the DMA descriptors look the same
in this regard, but this is from eyeballing only, I did not
try to play with it yet.
The re
On 18.04.2014 15:05, Fabio Estevam wrote:
>> Could you try the latest Russell's FEC patches available at?
>> http://ftp.arm.linux.org.uk/cgit/linux-arm.git/log/?h=fec-testing
>
> In particular this one could help with your "MDIO timeout" issue:
> http://ftp.arm.linux.org.uk/cgit/linux-arm.git/com
On 18.04.2014 01:10, jordan wrote:
Hi Jordan,
many thanks for the tests. I probably botched something during
the reverting - I now tried some more experiments and the system
now runs without BUGs and without kernel leak - of course
it needs some more uptime to be really sure.
My combined revert
Hi,
I am experiencing a problem with the ethernet controller on an
i.MX28 SoC. When doing
/etc/init.d/networking restart
sometimes I get "MDIO read timeout" and the controller does not
recover. The problem is more prominent if the interface is communicating
when the restart is performed.
I have
On 17.04.2014 18:29, Stanislav Meduna wrote:
> Note: the bug goes away reverting the very same patches that are
> helping the Jordan's problms. I did follow
>
> http://www.spinics.net/lists/linux-rt-users/msg11639.html
>
> and no BUG while booting anymore. I'll t
On 16.04.2014 00:08, Stanislav Meduna wrote:
>>> BUG: spinlock trylock failure on UP on CPU#0, ksoftirqd/0/3
>
> I am now getting this quite reproducibly a few seconds into
> the boot and the path is always similar. Depending on what modules
> I am loading the source chan
On 16.04.2014 21:21, Paul Gortmaker wrote:
> static void w1_write_bit(struct w1_master *dev, int bit)
> {
> unsigned long flags = 0;
>
> if(w1_disable_irqs) local_irq_save(flags);
Well, it is actually the w1_read_bit that does the writing
static u8 w1_read_bit(struct w1_mast
On April 16, 2014 9:21:23 PM CEST, Paul Gortmaker
wrote:
> static int w1_disable_irqs = 0;
> module_param_named(disable_irqs, w1_disable_irqs, int, 0);
...
>I've no idea why that module parameter exists. Why do you set it?
Hm... I do not, at least not knowingly. I'll try to trace what exactl
Hi,
trying 1-wire with rt-patched Linux 3.12.15-rt25+ and lock debugging:
[ 12.00] BUG: sleeping function called from invalid context at
/home/stano/Kernels/linux-3.12-rt/kernel/rtmutex.c:673
[ 12.055573] in_atomic(): 0, irqs_disabled(): 128, pid: 92, name:
w1_bus_master1
[ 12.055588]
On 15.04.2014 01:45, Stanislav Meduna wrote:
>> BUG: spinlock trylock failure on UP on CPU#0, ksoftirqd/0/3
I am now getting this quite reproducibly a few seconds into
the boot and the path is always similar. Depending on what modules
I am loading the source changes, but it is nearly al
On 14.04.2014 21:24, Stanislav Meduna wrote:
> hunting another problem with AUART acting weirdly I got
okay, the AUART thing was some device tree snafu, but I have seen
the BUG a few times (but not readily reproducible). This thread
looks remotely similar https://lkml.org/lkml/2013/9/27/
On 21.03.2014 02:39, Peter Hurley wrote:
> Does disabling the fifo on shutdown clear the fifo?
I did not try this, but if my theory is correct, it would
not help, as all this does is reducing the FIFO length
to one character. So you'd still get up to two characters:
one in the "FIFO" - it could g
Hi,
following scenario:
- a Freescale i.MX28 machine
- RS232 AUART looped back Rx - Tx or two different ports cross-connected
- a test program sending data in one thread and receiving in the other:
thread A periodically sends "Quick brown fox jumps over the lazy dog",
thread B receives
- stop
On 09.03.2014 23:53, David Miller wrote:
> To me it means "I've got nothing to do if other tasks want to run right
> now" Yes, I even see it having this meaning when an RT task executes
> it.
http://www.kernel.org/doc/htmldocs/device-drivers/API-yield.html
lists this exact "while (!event) yield;
On 07.03.2014 09:46, Marc Kleine-Budde wrote:
> Adding the linux-can mailinglist to Cc.
I am not subscribed so maybe that's why the original mail
did not get through - I did Cc: linux-...@vger.kernel.org
> Your kernel is missing the patch:
>
> e358784 can: flexcan: fix mx28 detection by rearang
Hi,
I am using a FlexCAN CAN controller on a Freescale i.MX28 platform [1].
If a packet is being sent when the bus is disconnected, I am getting
an interrupt flooed that basically kills the machine.
This is _not_ the same problem as [2] - my kernel already has
the fix.
The first interrupt comes
On 17.02.2014 19:18, Greg KH wrote:
> The uio_dmem_genirq.c driver showed up in 3.8, so it might be good for
> you to update your kernel if you want to do DMA memory with a UIO
> driver, as lots of other things in this area was fixed to accomplish
> this.
Ah, OK, I will look into this.
I am stuc
Hi,
what is the correct way for a UIO driver to pass a memory allocated
using dma_alloc_coherent to userspace? I have googled for examples
but I was not able to find a definitive answer.
My device needs two 128 kB chunks of DMA-able memory. First I tried
pdev->tx_vaddr = dma_zalloc_coherent(&d
On 19.06.2013 10:06, Peter Zijlstra wrote:
>> On 19.06.2013 07:20, Linus Torvalds wrote:
>>> There's the fast_tlb race that Peter fixed in commit 29eb77825cc7
>>> ("arch, mm: Remove tlb_fast_mode()"). I'm not seeing how it would
>>> cause infinite TLB faults, but it definitely causes potentially
>
On 19.06.2013 07:20, Linus Torvalds wrote:
>> No crash in 2 days running with preempt none...
>
> Is this UP?
Yes it is.
> There's the fast_tlb race that Peter fixed in commit 29eb77825cc7
> ("arch, mm: Remove tlb_fast_mode()"). I'm not seeing how it would
> cause infinite TLB faults, but it de
On 16.06.2013 23:34, Stanislav Meduna wrote:
> Right now a test with the same kernel with preempt none
> is running to see whether the problem also happens with this
> application there (due to the timing sensitivity only a positive
> result has a significance).
No crash in 2 days
Hi all,
I was able to reproduce the page fault problem with
a relatively simple application, for now on the
Geode platform. It can be downloaded at
http://www.meduna.org/tmp/PageFault.tar.gz
Basically the test application does:
- 4 threads that do nothing but periodically sleep
- 1 thread loo
On 24.05.2013 15:55, Stanislav Meduna wrote:
>> Just to rule something out, are you using
>> transparent huge pages on those systems?
>
> On my present test system they are configured in, but I am
> not using them.
Ah, _transparent_ huge pages. No
On 24.05.2013 15:06, Rik van Riel wrote:
> Just to rule something out, are you using
> transparent huge pages on those systems?
On my present test system they are configured in, but I am
not using them.
# cat /proc/meminfo | grep Huge
HugePages_Total: 0
HugePages_Free:0
HugePages_R
On 24.05.2013 10:29, Stanislav Meduna wrote:
>>>> static inline void __native_flush_tlb_single(unsigned long addr)
>>>> {
>>>> __flush_tlb();
>>>> }
>>
>>> I will give it some more testing time.
>>
>> That is
On 23.05.2013 14:19, Rik van Riel wrote:
>>> static inline void __native_flush_tlb_single(unsigned long addr)
>>> {
>>> __flush_tlb();
>>> }
>
>> I will give it some more testing time.
>
> That is a good idea.
Still no crash, so this one indeed seems to change things.
If I understand
On 23.05.2013 16:50, Linus Torvalds wrote:
> Another question: I'm assuming this is all 32-bit, is it with PAE
> enabled? That changes some of the TLB flushing, and we had one bug
> related to that, maybe there are others..
32 bit, no PAE.
--
Stano
--
On 22.05.2013 20:43, Rik van Riel wrote:
>> Some CPUs have had errata when it comes to flushing large pages that
>> have been split into small pages by hardware, e.g. due to MTRR
>> conflicts. In that case, fragments of the large page may have been left
>> in the TLB.
Can I somehow find if this
On 22.05.2013 20:35, Rik van Riel wrote:
> I'm stumped.
>
> If the Geode knows how to flush single TLB entries, it
> should do that when flush_tlb_page is called.
>
> If it does not know, it should throw an invalid instruction
> exception, and not quietly complete the instruction without
> doing
On 22.05.2013 20:11, Steven Rostedt wrote:
> Did you apply both patches? Without the first one, this one is
> meaningless.
Sure.
BTW, back when I tried to pinpoint it I also tried adding
flush_tlb_page(vma, address)
at the beginning of handle_pte_fault, which as I read should
be basically the
On 22.05.2013 19:41, Rik van Riel wrote:
>> I think you should also remove the
>>
>> if (flags & FAULT_FLAG_WRITE)
Done
>>> Can you test the attached patch?
Nope. Fails with the same symptoms, min_flt skyrockets,
the throttler activates and after 2 seconds all is well
again.
This is on
On 22.05.2013 02:39, Steven Rostedt wrote:
> The threads do a mlockall too right? I'm not sure mlock will lock memory
> for a new thread's stack.
They don't. However,
https://rt.wiki.kernel.org/index.php/Threaded_RT-application_with_memory_locking_and_stack_handling_example
claims
"Threads sta
Hi all,
I don't know whether this is linux-rt specific or applies to
the mainline too, so I'll repeat some things the linux-rt
readers already know.
Environment:
- Geode LX or Celeron M
- _not_ CONFIG_SMP
- linux 3.4 with realtime patches and full preempt configured
- an application consisting o
On 12.02.2013 08:06, Mike Galbraith wrote:
>> In this case pick_next_task takes idle tasks and idle wastes cpu
>> time.
> That's not a waste of CPU time, that's utilization enforcement the thing
> it is designed to do.
Well this is a philosophical question and the opinions will IMHO
vary strongl
On 31.10.2012 22:41, Stanislav Meduna wrote:
> on an embedded platform using a Freescale i.MX28 ARM processor
> I am experiencing a strange phenomenon - the latencies reported
> are dependent of HZ
OK, the problem is that the MXS platform does not setup
the scheduler clock so the sched
Hello,
it is impossible to load a ntfs module in 2.4.0-test{11,12} -
the symbol ntdebug is not defined. The symbol is only defined
when building with DEBUG, but it is always declared as module
parameter. Following trivial patch fixes it.
Sorry if this was already posted - I don't read the whole
Hello,
just installed 2.4.0-test10 on a SMP Intel machine and got
following:
NMI Watchdog detected LOCKUP on CPU1, registers:
CPU:1
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 0086
eax: 0307 ebx: 0206 ecx: 0007 edx: 003f03af
esi: 0307
> > > - If I'm correct that pipes have a 4K kernel buffer, then writing 1
> > > byte shouldn't cause this situation, as the buffer is well more than
> > > half empty. Is this still a bug?
> >
> > The pipe code uses totally full/empty. Im not sure why that was chosen
>
> Just a quick guess: m
Hello,
what is the status of IrDA in the 2.4.0-test* kernels?
I am asking this because I am able to get reproducible hard
lockups with IrCOMM using vanilla 2.4.0-test8. However,
if I apply the patch-2.4-test6-irda3 from Dag Brattli's
site, all works fine (well, at least what I have tested),
so t
46 matches
Mail list logo
