On 04/20/15 07:36, [email protected] wrote:
Hi, I wonder if there is any progress on this?
Or is there a workaround?
I just installed debian jessie on a Banana Pro and hit this same problem.
Can the ap6210 driver still be used with the 3.16 kernel that comes with jessie?
Thanks!
Apart from reproducing the issue I did not have much time to spent on
the issue. I am wondering whether it could be a "card busy" issue. The
sunxi mmc driver seems to be able to detect that. If this would be the
case a request should be hold off. I will see if I can try a patch for that.
Regards,
Arend
On Wednesday, March 4, 2015 at 12:35:53 AM UTC-8, Hans de Goede wrote:
Hi,
On 03-03-15 20:12, Arend van Spriel wrote:
On 03/03/15 14:33, Hans de Goede wrote:
Hi,
On 03-03-15 14:01, [email protected] wrote:
Hello everyone
I try to compile with the newest kernel from the website at
https://github.com/linux-sunxi/linux-sunxi/tree/sunxi-next . and the
kernel can work normally on the BananaPro board.
Meanwhile, I use the brcmfmac to driver the ap6181(wifi module as same
as ap6210) in the linux-3.19, and the WiFi can work normally, but
there is something wrong when i use the scp to copy.
The error message as follows:
[ 108.934478] sunxi-mmc 1c12000.mmc: smc 1 err, cmd 53, RD SBE !!
[ 108.940736] sunxi-mmc 1c12000.mmc: data error, sending stop command
[ 108.947833] brcmfmac: brcmf_sdio_readframes: RXHEADER FAILED: -110
[ 108.954330] brcmfmac: brcmf_sdio_rxfail: abort command, terminate
frame, send NAK
[ 108.966952] brcmfmac: brcmf_sdiod_regrw_helper: failed to write data
F1@0x0a040, err: -5
[ 108.975499] brcmfmac: brcmf_sdio_hdparse: seq 79: sequence number
error, expect 80
[ 109.336188] sunxi-mmc 1c12000.mmc: smc 1 err, cmd 53, RD DTO !!
[ 109.342442] sunxi-mmc 1c12000.mmc: data error, sending stop command
[ 109.703557] sunxi-mmc 1c12000.mmc: smc 1 err, cmd 53, RD DTO !!
[ 109.709843] sunxi-mmc 1c12000.mmc: data error, sending stop command
[ 110.070986] sunxi-mmc 1c12000.mmc: smc 1 err, cmd 53, RD DTO !!
[ 110.077273] sunxi-mmc 1c12000.mmc: data error, sending stop command
[ 110.083928] brcmfmac: brcmf_sdiod_regrw_helper: failed to read data
F1@0x0a020, err: -110
It seems like there is a problem with the brcmfmac or sdio driver in
the linux-3.19.
Looking forward to you reply.
Yes this is a known problem with broadcom sdio wifi on sunxi devices and
upstream kernels. Arend van Spriel from broadcom is looking into this.
Arend, any luck in reproducing this on your cubietruck?
Whether it be coincidence or devils' play, but today I got the cubietruck up
and running with fc21 3.18.7 kernel. I tried installing a kernel from our
internal tree (3.19-rc?) but did not get it working.
So I got back to 3.18.7 fc21 kernel and build our latest brcmfmac against it
using a backports package. I started a ping when I left the office and had
another look at home seeing the same RD DTO messages. So yes I have reproduced
it, but did not capture a log.
Good (that you've reproduced it) note that it is much easier to reproduce
by scp-ing a bunch of large(ish) files, then it usually triggers within
a minute.
And any luck in
finding a
fix for it ?
We recently did have an issue where the device indicates busy using data lines
and host ignored that and started next cmd53 causing the device to end in a bad
state. Not sure if sunxi-mmc has similar issue. Will need to investigate that
further.
This might very well be a sunxi-mmc bug, but on my cubioetruck if I first
boot into the linux which is on the onboard flash, and then insert a sdcard
with upstream kernel and reboot so that it boots from the sdcard the
problem is gone. And I've done a regdump comparing all settings on the
mmc controller side, I might have missed something but atm my first hunch
is that the kernel in the nand sets some bits in the wifi module which
stick over reboot and fix this. Could actually still be the same thing
you're talking about but that the wifi moudle behavior is somehow
changed to avoid that.
Also note that the very first error is not a cmd 53 error, there first
is a single different command which fails (forgot which one sorry) and
then from there on a lot of cmd53 errors. The first failing command
also does not fail with a response time out, but with a start bit error.
Regards,
Hans
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.