-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi James,
Please have a look at https://dev.laptop.org.au/issues/1033#note-64 which was the email sent some time ago internally when the workaround for this was just found. * It is currently difficult for us to follow "linux debugging" techniques as the broken laptop and good/bad microSD cards are with someone with only basic linux knowledge. (and this was a restriction during initial debug too) * We think the problem was with the SD cards (perhaps a specific batch of them), and I think our findings establish that with some confidence. * The reason why the laptop was not being shutdown was due to a race condition. The halt script was expecting the processed to get killed within a certain amount of time, which they weren't. Just delaying that expected time point (by which the processes should be killed) worked for us. * As for further debugging, I could have the SD card shipped to me, or anybody looking to spend time on it, but we must be confident enough that the problem lies there (which I think it does). On Saturday 16 June 2012 05:46 AM, James Cameron wrote: > I do not wish to constrain your investigation at all, please > continue investigating, but I do have some comments and > speculations. > > Yes, the microSD card cannot be excluded as a cause. But unless > there are other symptoms associated with the microSD card, effort > should be concentrated on finding the root cause of the hang, using > Linux debugging techniques. > > The transactions that are given to the microSD card during > shutdown should be normal block read and writes, as the filesystem > is prepared for unmounting. There's nothing unusual about these > transactions, except that some of them may be located in a > particular block range. > > So it is unlikely that this will be a cause of the hang. > > But you may want to exclude it. On the theory that these writes > may be stalling due to the block number, (and we haven't seen any > evidence yet of this), you can test for that by repeating the > writes in a controlled fashion, such as by booting from an external > SD card or USB drive, and using Linux to mount and umount the > internal microSD card partitions. If you find this unreliable, > then it is a critical finding. If you find this reliable, then you > can exclude the theory of writes stalling due to block number. > > There is a possibility that the contributed behaviour is tied to a > model of microSD card, rather than a specific microSD card. We > use multiple qualified sources in manufacturing. You might > identify the manufacturer's identity and configuration of the > microSD card. You can do this in Open Firmware using: > > ok select int ok show-cid > > There are, no doubt, ways to do this in Linux as well, but I do > not recall the details. > > I look forward to hearing what your Linux debugging techniques > uncover. Ask yourself this question; what is preventing the power > off command from being delivered to the embedded controller by the > kernel? Is it because it was not sent? If so, why? Is it because > it was sent (per serial port evidence) but not obeyed? If so, why > is it that the power button responds? Is there any serial port > evidence of the power button being detected by the kernel at the > point of the hang? And so on. > - -- Anish Mangal Dextrose Project Manager Activity Central -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP2/xTAAoJEBoxUdDHDZVp33QH/jfYUQYyQLLt6+cAH/aYAEhU yymgGEZzmCqhn+i92CuD1LoChblV+mYNVCQH0DqLe8aoDyzyqoOsdZ7lLgv+FQdv niIBQxS5q7J+sKOB4pzVgXes/2HAn3fj/VyRHUkqgLsvYyzfA2ZMm7+qYGyGZ410 QIU6oRkJqwIrGq+hAd8dyGogFtByB3xOquCWeBnIF63MZ0mr7/Agjdek8a+h+Y+q 5nGfd+HuRTnzfgQezx+kX3K7a7ozj3lOpMDD5pAbXIbLKNWeyoAoUh31suGmTJO0 bWwbzDDze+g1VqaJOF/AuAiMuQi1k9ZbUlbhhlqRwBNAPWggEtH+3Iqj3flm+VE= =ktQp -----END PGP SIGNATURE----- _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel