Bugzilla – Bug 11784
Unreliable reading of SD cards in factory FQC test
Last modified: 2009-09-30 18:03:33 UTC
According to Chris, the path to the SD card is not consistent. Potential cause of rejects in the factory and must be fixed before MP, and having this resolved before MPQ is even better. Here's the summary from Chris: I have in front of me a fab4 that appears to be working except sometimes, after inserting an SD card, the files that are on the card are not found, and instead it reports there are several spurious files: Typing 'ls /media/mmcblk0p1/a*' gives a listing as follows: /media.mmcblk0p1/abcd.ef /media.mmcblk0p1/abcd.ef /media.mmcblk0p1/abcd.ef /media.mmcblk0p1/abcd.ef /media.mmcblk0p1/abcd.ef /media.mmcblk0p1/a.e /media.mmcblk0p1/a.e If I cd into the /media directory, I find not one but two directories there. mmcblk0p1 mmcblk2p1 The mmcblk2p1 has the files I'm looking for. If I cd into the other directory, mmcblk0p1, the directory listing is garbage, including several instances of ????.??, qrst.uv, 1234.56 and various filenames containing the extended ASCII "square" character. I removed the SD card and tried to type 'ls' in the /media directory, but the command line was now unresponsive. Characters I typed were echoed to the screen but I never got another # prompt. Some experimentation shows that this number '2' in the name of the mount point is a digit that increments with each insertion of the SD card. So, it looks like there are two instances of the SD drive, and only one is valid. On this unit, it's quite easy just by removing and re-inserting the SD card several times quickly to put it into the state I describe above where the CLI becomes unresponsive (although characters are still echoed to the screen). I don't know how or if this would manifest itself in actual usage. I guess the only usage we have implemented so far is firmware upgrades, which may not be very demanding on this part of the system. On my trusty PB2 unit which I brought along, this seemed slightly more difficult to reproduce, but within about 10 insertions and extractions, I had caused a crash which rebooted the unit. I was also able to reproduce the unresponsive state I described above.
The factory is failing units because they are having trouble reading SD cards reliably. Apparently they are pulling out SD cards from the slot and reinserting them in FQC, and then they can't be read by the FQC test. Chris thinks that the factory may call this a showstopper problem. David thinks the software is detecting the SD card reader state change too slowly, thus resulting in the OS falsely concluding there is a second phantom SD card reader connected.
Yes, the problem occurs if they screw up the test the first time and have to start over from my instructions (most factory workers are not unix-literate :), or if they fumble on inserting the SD card and do it twice. But if this doesn't otherwise need to be fixed for any other software reasons, I can re-write the test to explicitly avoid this circumstance. - - Christopher Owens QA Manager
Had another chat in today's meeting. Root issue needs to be addressed, but not immediately.
Chris, is this still an issue? It also may be fixed in the latest firmware, as the kernel includes some sd card fixes.
I will dust off my Fab4 and have a look :)
Indeed this seems to be fixed in 7790