The unexpected early appearance of TC 4.0rc1 (as I had expected a longer alpha phase as seen during the TC 3.x cycle) has prompted me today to run a number of boot sequences using the same hardware setup which contained a know "troublemaker".
This problematic device is a Toshiba XM-1902B CD-ROM which was originally part of a Dell Latitude CPx notebook (from 2000-08, with a Pentium III, 500 MHz). Until a few weeks ago this was my test system for certain scenarios involving older hardware, and I have mentioned the (boot) problems with this CD-ROM on other posts. Unfortunately it appears that this notebook has now developed a "terminal" issue as it refuses to perform even a POST. Nevertheless I managed also a few weeks ago to get my hands on an almost as old Dell Precision M50 (from 2002-11, with a Pentium 4-M, 1.8 GHz). Luckily this is a so called three-spindle notebook (possibly one of the last ones produced), which features in addition to the (fixed) hard disk and DVD (i.e. a HL-DS GCC-4240N) an additional modular bay (usually used for a floppy drive or a second battery) into which the old "troublemaker" can be inserted.
For the following comparison I've chosen three generations of TC ISO images (i.e. 2.11.6, 3.8.4, and 4.0rc1). As I had recently created a null-modem cable (as mentioned
here), I was able to capture all console output of booting each of the CD-ROMs on either of the two optical devices. The use of a serial interface was necessary as in at least one case a totally unresponsive system would not have allowed any other way of recording the evidence.
In the following table I'm trying to summarise the results combined with providing a link to the actual raw log:
I guess these results probably deserve a few comments:
- The IMHO most important finding is in case [ C2 ] (i.e. TC 4.0rc1 booting from the known "troublemaker"), as this one ends up with a successfully running system.
- The row [ 3 ] brings the addition of boot code 'ide-core.nodma=1.0' (as the CD-ROM is '/dev/hdc') into the comparison. This boot code had become since about January 2011 the "preferred option" in this forum here to attempt to address reported issues with certain storage devices. Apparently there are some earlier postings which refer to 'ide_core.nodma' (i.e. underscore instead of hyphen), which had typically (and somewhat not surprisingly) not resulted in users being able to overcome their reported problems.
- For case [ A2 ] one had to be patient and wait IIRC ca. 2 minutes for the DMA issues to "clear up". I guess this is due to some timeouts. And after those occurred the processing would continue and the device would be usable (as tested by running a 'time md5sum /dev/hdc'). OTOH even waiting much longer in case [ B2 ] did not result for the system to come out of it's "frozen" state.
- Due to diversion of all console output (plus the use of boot code 'debug') a certain element of "muddled lines" are appearing in the captured logs. This is due to the fact that kernel boot and TC startup messages are "mixed" together. This might make in some cases the reading a little bit more tricky as also the escape codes to change the colour have become part of the mix. But I wanted to capture enough detail so I reckon that is the price for that.
( ... I might add more thoughts tomorrow, but for now I'll have to press the 'Post' button ...)