On XO-1.5 with 11.3.0/11.3.1 -- hang during shutdown?
anish at activitycentral.com
Fri Jun 15 23:24:03 EDT 2012
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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.
Dextrose Project Manager
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the Devel