On Mon, Oct 23, 2017 at 10:55:57AM -0500, Matt DeVillier wrote:
On Mon, Oct 23, 2017 at 10:50 AM, Kevin O'Connor kevin@koconnor.net wrote:
On Mon, Oct 23, 2017 at 10:39:03AM -0400, Kevin O'Connor wrote:
Hi Matt,
Can you gzip and attach the full log? (At a minimum, we need to see the log extracts around the failure.)
Ah, nevermind - I see the timeout is generated in the wait for the card to be in a non-busy state.
Unfortunately, I can't see anything wrong in the log - the card isn't coming out of its initialization phase. I can't see any reason why that would be. Has the user verified the card works under Linux?
card is detected/usable under Linux, no problem there
Can you grab the syslog/dmesg output from Linux as it detects and initializes the card?
The failure is pretty early in the card detection process and the card isn't responding with a particular failure - it's just not going into a ready state.
-Kevin
On Mon, Oct 23, 2017 at 11:34 AM, Kevin O'Connor kevin@koconnor.net wrote:
On Mon, Oct 23, 2017 at 10:55:57AM -0500, Matt DeVillier wrote:
On Mon, Oct 23, 2017 at 10:50 AM, Kevin O'Connor kevin@koconnor.net
wrote:
On Mon, Oct 23, 2017 at 10:39:03AM -0400, Kevin O'Connor wrote:
Hi Matt,
Can you gzip and attach the full log? (At a minimum, we need to see the log extracts around the failure.)
Ah, nevermind - I see the timeout is generated in the wait for the card to be in a non-busy state.
Unfortunately, I can't see anything wrong in the log - the card isn't coming out of its initialization phase. I can't see any reason why that would be. Has the user verified the card works under Linux?
card is detected/usable under Linux, no problem there
Can you grab the syslog/dmesg output from Linux as it detects and initializes the card?
sure, any special kernel params for debugging?
The failure is pretty early in the card detection process and the card isn't responding with a particular failure - it's just not going into a ready state.
-Kevin
-
Kevin O'Connor -
Matt DeVillier