On XO-1.5 with 11.3.0/11.3.1 -- hang during shutdown?

[Anish Mangal]

-----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-----