RE: NAND erase failures on overo
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Cliff Brake Sent: Saturday, September 11, 2010 3:22 AM To: Linux OMAP Users Subject: NAND erase failures on overo With the current, linux-omap:master branch (8475b9e5077d9e9b4ba7a92afd4c5c7d65564c09), I get the following errors on a overo system when erasing flash: r...@ts3:~# flash_eraseall -j /dev/mtd4 Erasing 128 Kibyte @ 8c4 -- 56 % complete. Cleanmarker written at 8c2. flash_eraseall: /dev/mtd4: MTD Erase failure: Input/output error Erasing 128 Kibyte @ 944 -- 59 % complete. Cleanmarker written at 942. flash_eraseall: /dev/mtd4: MTD Erase failure: Input/output error Erasing 128 Kibyte @ f98 -- 100 % complete.Cleanmarker written at f96. [Ghorai] There are few bad blocks reported by NAND erase. On the omap3530 TI EVM, with the same kernel, I don't see any of these errors. I'm not sure if its related to something like this: http://lists.infradead.org/pipermail/linux-mtd/2010-August/031563.html Thanks, Cliff -- = http://bec-systems.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/10] split out emac cpdma and mdio for reuse
On Friday 10 September 2010 06:23:52 pm Caglar Akyuz wrote: On Friday 10 September 2010 12:25:40 am Michael Williamson wrote: Hi Cyril, On 09/09/2010 03:51 PM, Cyril Chemparathy wrote: Hi Mike, [...] The hang is in wait_for_user_access() in the davinci_mdio_read() call. Looks like the state machine got put back into IDLE somewhere between the MDIO probe and the EMAC probe. Seems like there should be some sort of time-out and error message in the wait_for_user_access() method (maybe even a check for IDLE??) If I add a patch to check the state machine for IDLE and then re-enable it in the davinci_mdio_read() call, it is able to press on and come up. I don't see any calls to the davinci_mdio_suspend() call, so I am wondering if the EMAC probe routine, particularly the application of the SOFTRESET, is causing the MDIO to drop back to IDLE / disabled. I can post the patch if you like, but it is a bit of a hack... An EMAC soft-reset clobbering the MDIO controller state is a possibility. I will poll TI designers to see if this could be the case. In any case, a couple of unanswered questions remain: 1. Why don't other davinci devices display similar behavior? 2. If the answer to #1 above is that the timing window is pretty slim (i.e., only if an MDIO read/write is in progress during EMAC soft-reset), why do we hit this situation consistently on mityomap? Has it been confirmed that this only happens on mityomap? Has anyone had success using a da850 evm or other da850 platform? The configuration for Same problem exists on another DA850 board, Hawkboard.(Sorry no support in mainline yet) the mityomap, wrt to the EMAC/MII/MDIO, is pretty much identical to the da850 evm using the MII interface. The only difference I am aware of is the assigned address to the PHY chip. The reference clocks and rates are identical, AFAIK, to the evm. I have put together a quick patch (tested dm365). See attached. Your patch doesn't work with my board. It does attempt to reset the bus on This patch fixes the problem here. I'm using kernel IP auto configuration and mounting fs over NFS. My system boots and I can login to my board. Regards, Caglar Unfortunately emac driver is not stable after this series. I face lock-ups time to time, followed by attached kernel trace. Regards, Caglar _ [ 1651.44] nfs: server 192.168.2.34 not responding, still trying [ 1859.01] [ cut here ] [ 1859.01] WARNING: at net/sched/sch_generic.c:258 dev_watchdog+0x184/0x294() [ 1859.02] NETDEV WATCHDOG: eth0 (davinci_emac): transmit queue 0 timed out [ 1859.02] Modules linked in: [ 1859.03] Backtrace: [ 1859.03] [c0030444] (dump_backtrace+0x0/0x10c) from [c02d9820] (dump_stack+0x18/0x1c) [ 1859.04] r7:c03b5de8 r6:c025a13c r5:c039045c r4:0102 [ 1859.04] [c02d9808] (dump_stack+0x0/0x1c) from [c0042e44] (warn_slowpath_common+0x58/0x70) [ 1859.05] [c0042dec] (warn_slowpath_common+0x0/0x70) from [c0042f00] (warn_slowpath_fmt+0x38/0x40) [ 1859.06] r8:c03b4000 r7:0030 r6:c0437564 r5:c7bbc000 r4: [ 1859.07] [c0042ec8] (warn_slowpath_fmt+0x0/0x40) from [c025a13c] (dev_watchdog+0x184/0x294) [ 1859.08] r3:c7bbc000 r2:c0390474 [ 1859.08] [c0259fb8] (dev_watchdog+0x0/0x294) from [c004e918] (run_timer_softirq+0x1c4/0x29c) [ 1859.09] [c004e754] (run_timer_softirq+0x0/0x29c) from [c0048b94] (__do_softirq+0x98/0x12c) [ 1859.10] [c0048afc] (__do_softirq+0x0/0x12c) from [c0048c70] (irq_exit+0x48/0x9c) [ 1859.11] [c0048c28] (irq_exit+0x0/0x9c) from [c002c080] (asm_do_IRQ+0x80/0xa0) [ 1859.12] [c002c000] (asm_do_IRQ+0x0/0xa0) from [c002cb2c] (__irq_svc+0x4c/0x9c) [ 1859.12] Exception stack(0xc03b5f38 to 0xc03b5f80) [ 1859.13] 5f20: 0005317f [ 1859.14] 5f40: 0005217f 6013 c03b4000 c03b8ba0 c03b89d4 c03dcc50 c0023e04 41069265 [ 1859.15] 5f60: c0023d94 c03b5f8c 60d3 c03b5f80 c002da6c c002da78 6013 [ 1859.15] r5:febfd000 r4: [ 1859.16] [c002da48] (default_idle+0x0/0x34) from [c002dff0] (cpu_idle+0x74/0xdc) [ 1859.17] [c002df7c] (cpu_idle+0x0/0xdc) from [c02d59d4] (rest_init+0xa4/0xbc) [ 1859.17] r7:c03b89c8 r6:c0026018 r5:c03dcc1c r4:0002 [ 1859.18] [c02d5930] (rest_init+0x0/0xbc) from [c0008bc4] (start_kernel+0x270/0x2d0) [ 1859.19] r4:c042d70c [ 1859.19] [c0008954] (start_kernel+0x0/0x2d0) from [c0008034] (__enable_mmu+0x0/0x2c) [ 1859.20] r6:c002641c r5:c03dcc78 r4:00053175 [ 1859.20] ---[ end trace d278f645c502dc20 ]--- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at
Re: Suspend to RAM broken on BeagleBoard ?
On Fri, 10 Sep 2010 14:54:23 -0700 Kevin Hilman khil...@deeprootsystems.com wrote: It's the CPUfreq driver that's failing to suspend. Ok. Yes, CPUfreq is not supported in l-o master or pm-core (only in the full pm branch.) If you Kconfig out CPUfreq, this failure will go away. Aah, yes, I forgot about this. I know it's temporary, but wouldn't it be good to disable CPUfreq in omap3_defconfig in this case ? BTW, I'm now seeing: [ 37.830596] Powerdomain (core_pwrdm) didn't enter target state 1 [ 37.830627] Powerdomain (dss_pwrdm) didn't enter target state 1 when the system is woken up. Concerning the USB issue, no idea ? Thanks, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] SoC Camera: add driver for OMAP1 camera interface
Saturday 11 September 2010 04:06:02 Jasmine Strong wrote: On 10 Sep 2010, at 18:21, Janusz Krzysztofik wrote: Both paths work stable for me, even under heavy load, on my OMAP1510 based Amstrad Delta videophone, that is the oldest, least powerfull OMAP1 implementation. You say that, but the ARM925 in OMAP1510 is known not to exhibit the bug Then, lucky me ;) in OMAP1610, which causes severe slowdown to DRAM writes when the first address of an STM instruction is not aligned to a d-cache line boundary. This means that at least last time I looked, the Linux ARM memcpy() implementation is often faster on 1510 than 1610. This sounds like a problem that should be solved at a machine support level rather than a camera driver. I don't follow general OMAP development closely enough to know if this bug has ever been addressed or is going to be. Unfortunatelly, I have no access to any OMAP machine other than Amstrad Delta, so I'm not able to test the driver, including its performance, on other OMAP1 implementations. Anyways, I think there is always a room for improvement, either in my omap1_camera or maybe in the omap24xxcam driver, if someone tries to add support for a camera to an OMAP1 board other than 1510, and identifies a more optimal, 1610 or higher specific way of handling the OMAP camera interface. Do you think I should rename the driver to something like omap1510cam rather than omap1_camera then? Thanks, Janusz -J. ___ e3-hacking mailing list e3-hack...@earth.li http://www.earth.li/cgi-bin/mailman/listinfo/e3-hacking -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/10] split out emac cpdma and mdio for reuse
Hi Cyril,
On 09/10/2010 06:59 PM, Cyril Chemparathy wrote:
Hi Mike,
I have merged your latest two emails and responded to both here.
[...]
One of the patches posted on my repo [1] replaces the dumb mdelay() with
a bit more logic that calculates the worst-case access time. This
mechanism may work a lot better for you. Would you mind trying it out?
You patch from [1] is working much more reliably now (well, 6 for 6 boot cycles
as well as
several ifup/ifdown cycles). I do get the resetting idled controlled console
message
every cycle, it seems that will be expected now.
[...]
Also, your while(1) loops with the continue conditions on the second
wait_for_user_access()
in the read and writes might need some consideration, i.e.:
while (1) {
ret = wait_for_user_access(data);
if (ret == -EAGAIN)
continue;
if (ret 0)
break;
__raw_writel(reg, data-regs-user[0].access);
ret = wait_for_user_access(data);
if (ret == -EAGAIN)
continue;
^ --- this will re-issue the request
what you want?
Yes, the wait_for_user_access() would have reset the controller,
throwing the current transaction out. The intent here is to restart the
current transaction with a newly initialized controller.
OK. Makes sense. Looking at it felt like there was a chance for end endless
spin, but that
seems unlikely given how that condition might fire.
[...]
Also, on the shutdown, I get a major kernel trace. Here is the dump, as
much
as I could catch of it (I need a better terminal program)
[...]
WARNING: at drivers/net/davinci_emac.c:1025 __cpdma_chan_free+0xac/0xb0()
The current code spits out a huge volume of stuff as a result of a
WARN_ON in the rx handler. The gitweb on [1] has a patch that fixes this.
Yes, these messages are no longer issued with the patches from [1]. Thanks.
[...]
The MDIO module upgrade (rev 1.4 - 1.5) could have something to do with
this behavior. Even so, I can't explain why this issue wasn't seen on
da8xx prior to this series. The original code should (at least in
theory) have sporadically locked up on emac open.
I think, if I understand it correctly, that in the previous version of
this code, the emac was reset *prior* to enabling, scanning, and assigning
the associated phy on the MDIO bus. The new implementation sets up and
scans
the MDIO bus first, then comes back around to the EMAC second... hits a
reset,
and doesn't re-ENABLE the MDIO.
AFAICS, that isn't entirely accurate. In the previous version, the mdio
bus was being brought up at probe time in davinci_emac_probe(). The
soft-reset was happening later on when the device is opened, in
emac_hw_enable().
The difference, however, is that the original code forced an
emac_mii_reset() immediately after the emac_hw_enable(). This is not
being done with the separated mdio, and that is the problem. In terms
of behavior, with the current work around, the new and old versions
should be close to identical. More below...
Also, maybe hitting the EMAC reset while the MDIO state machine is up is
*bad*, I
seem to recall some text in the user's guide about waiting for the state
machine to stop before disabling it. I wonder if that also applies to reset?
You are correct. EMAC soft-reset stops the MDIO mid-transaction, quite
unlike disabling the module via the control register. Therefore, there
is a risk that a badly designed phy could be left hanging in an
arbitrary state. However, all earlier versions of the emac code have
been exposed to this very same vulnerability (i.e. arbitrary emac
soft-reset regardless of mdio state) all along.
Thanks for straightening me out on this, Cryil. Your patch series in [1] seems
to
have resolved the issues I've been able to see on the da850 based board I'm
using
here. I appreciate your patience and quick response. I may try to beat on it
a
bit more with some network performance tests (even though it's not at all
related
to the immediate problems you've fixed) -- we've had that on our list of todos
anyway for this module.
I think it would be good to float your patches over to davinci-next, if
possible, before the
37 merge window opens... Speaking, of course, from a very partial perspective.
[1]
http://arago-project.org/git/people/?p=cyril/linux-tnetv107x.git;a=shortlog;h=refs/heads/emac-cpdma-mdio-fixes
-Mike
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
