Am Freitag, 12. Dezember 2014, 15:54:15 schrieb Doug Anderson: > Hi, > > On Fri, Dec 12, 2014 at 12:22 PM, Heiko Stübner <heiko@xxxxxxxxx> wrote: > > Hi, > > > > when trying linux-next for 20141210 on my rk3288 eval board I got errors > > when ejecting sd cards. Especially a timeout for a command and following > > this an rcu stall which essentially stops everything [0]. > > > > My way to reproduce the issue is: > > - boot into an initramfs > > - insert card > > - remove card > > - boom > > > > It happens 100% of the time on the first removal of the card. > > > > > > Bisecting the issue brought me to > > > > first bad commit > > 6130e7a9c34d01afbd4e7e215846d1f2d70333bb > > mmc: dw_mmc: Remove old card detect infrastructure > > > > and indeed if I revert this one, card ejection works again - also multiple > > times in a row. Affected machine is a rk3288-evb-rk808 board which > > currently uses the internal card-detect mechanism of the dw_mmc and > > relevant git history (--oneline) is: > > > > 864de9b Revert "mmc: dw_mmc: Remove old card detect infrastructure" > > 5bd48e0 ARM: dts: Bump SD card pin drive strength up on rk3288-evb > > 12fd072 Add linux-next specific files for 20141210 > > ... > > > > > > I'll try to dig deeper, but if anybody has ideas beforehand I would also > > be very glad. > > I tried to reproduce this on the same board on 20141211. I have a > different bootloader, but I hope that doesn't matter? Doug also seems to have found the cause of the problem and in fact the bootloader did seem to make the difference. The rk3288 has a function to switch the sdmmc pins between sdmmc and jtag functions automatically depending on the card status. On Doug's board this function was deactivated by the bootloader while on my board it is default- active. Deactivating this "feature" also solves the timeout + hang issue reported above. So the commit mentioned above is in fact inocent :-) Heiko -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
