On Tuesday 09 August 2005 12:01 am, Randall R Schulz wrote: <moderate snippage>
Aside from personal experience from years of hardware/software compatibility testing?
Yes, aside from that. Because this sounds an awful lot like superstition, so I'm looking for some hard facts and documented empirical data, not just assumptions and anecdotes. Absent such facts, I'm rather doubtful that this effect is real.
Hi Randall, I thought this would be an interesting exercise... how to prove this effect to Randall so he'll stop calling it "superstition?" Well, Google is one obvious route. Here's a brief sampling of hits for your personal edification. Some of these links actually point to fun, albeit esoteric, technical reading. Watch for word-wrap breaks! - Carl ... http://www.astro.caltech.edu/palomar/200inch/lfc/lfctech_main.html Start Exposure Commands * clear <[num]> Clear (wipe) the CCDs. This flushes any charge existing in the CCDs. The chips are good about not retaining residual images, but you can give clear an argument if you want to wipe it several times. Some of the CCDs may require several wipes to clear bled charge from near the bottom of the chip if the CCD is saturated. We've seen the need for a clear 5 once or twice after a very bright (3 mv) star. If you receive a "camera not responding" or a similar warning when trying to take an exposure, you will need to start a Cold Boot sequence. ... http://www.scyld.com/pipermail/eepro100/2001-July/001769.html For testing purposes, I am running a stock 2.4.6 kernel on a Sony VAIO Z600 NE notebook (Sony Z505 JS in the US). On a cold boot, I get this information in dmesg:
eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin
and others PCI: Found IRQ 9 for device 00:0b.0 eth0: OEM i82557/i82558 10/100 Ethernet, 08:00:46:07:49:99, IRQ 9. Receiver lock-up bug exists -- enabling work-around. Board assembly 100001-001, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0x04f4518b). Receiver lock-up workaround activated.
With the exact same kernel, after a warm boot ('reboot'), the picture changes to
eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin
and others PCI: Found IRQ 9 for device 00:0b.0 eth0: Invalid EEPROM checksum 0xff00, check settings before activating this device! eth0: OEM i82557/i82558 10/100 Ethernet, FF:FF:FF:FF:FF:FF, IRQ 9. Board assembly ffffff-255, Physical connectors present: RJ45 BNC AUI MII Primary interface chip unknown-15 PHY #31. Secondary interface chip i82555. Self test failed, status ffffffff: Failure to initialize the i82557. Verify that the card is a bus-master capable slot.
Result: The network essentially is dead; I cannot make HTTP requests to a server on the LAN, for instance. Shut down the system and go through a cold boot ('halt -p'), and all is well. Cold booting into 2.4.6 and then warm booting into a stock 2.2.19 kernel (on a different partition) shows the same effect on the 2.2.19 side in dmesg plus a couple of lines eepro100: cmd_wait for(0xffffffff) timedout with(0xffffffff)! The very same hardware configuration works perfectly with the 2.2.19 kernel across warm boots. ... http://lists.freebsd.org/pipermail/freebsd-current/2004-February/020678.html I am running a 5.2-CURRENT with a fresh kernel and world (cvsupped ~2 hours ago) on a Toshiba Satellite 5200-903. To install and run FreeBSD on that machine I use the known workaround hw.pci.enable_io_modes=0 in /boot/device.hints. Otherwise it hangs when probing agp0. After a cold boot the notebook works fine. But on a warm boot (e.g. shutdown -r now) the kernel hangs after ata0: [...] atapci0: <Intel ICH3 UDMA100 controller> ... ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] The error is reproducable... ... http://www.911cd.net/forums/index.php?showtopic=11213&st=20 1) If you switch it on with the USB key in it, it won't boot from it 2) If you reset it, (warm boot) it will 3) Sometimes the key must be removed AFTER the Ctrl+Alt+Del and BEFORE BIOS starts detecting hardware 4) Once every 10 times it won't boot, and after a Ctrl+Alt+Del it will ... And I know you'll *really* appreciate this one! (he says ducking...) http://support.microsoft.com/default.aspx?scid=kb;en-us;Q102228 SUMMARY When troubleshooting hardware issues, using the power on/off switch yields the most consistent testing procedure. If you suspect a hardware problem, particularly an adapter card problem, using the power switch, rather than the CTRL+ALT+DEL key combination or the Reset button, is recommended. MORE INFORMATION A warm boot, accomplished by pressing the CTRL+ALT+DEL key combination, restarts the computer through the INT19h ROM BIOS routine. This warm-boot procedure usually does not go through the complete boot process; generally, it skips the power-on self test (POST) to save time. In addition, a warm boot frequently fails to reset all adapters in the computer's adapter slots. If you use the Reset button to cold boot the computer, it generally restarts the boot process, including the POST. However, this procedure does not necessarily discontinue power to the motherboard. If the power is not interrupted, the cold boot may fail to reset all adapters in the computer's adapter slots. To ensure that all adapters are properly reset, you should use the power switch to turn the computer off. Leaving the power off for ten seconds ensures that all the capacitors on the motherboard have time to discharge and should also give the hard disk drive a chance to stop spinning. NOTE: Using other reboot methods, such as CTRL+ALT+DEL or the Reset button, is acceptable when a hardware problem is not suspected. ... http://64.233.161.104/search?q=cache:rzSTjKU7jvMJ:www.nps.gov/gis/gps/gps4gi.... +cold-boot&hl=en ->Trimble Navigation GeoExplorer Techical Information Page, Title "Warm Boot or Cold Boot a Data Collector Summary "This TIP presents a table of warm and cold boot procedures for seven Trimble mapping and GIS data collectors, followed by comments on when to use each procedure. ... http://ironbark.bendigo.latrobe.edu.au/subjects/CT/2005/L17/lecture.html Warm Boot vs Cold Boot The boot sequence used when a PC is first powered on (after being completely powered off) is known as a cold boot. This causes all system checks to be performed. When a machine is rebooted, either by pressing the reset switch, telling the operating system to reboot the machine or by pressing CTRL+ALT+DEL a warm boot is performed. In this case less time is spent testing system components as it is assumed that the system has already been running, the full POST has previously been performed and the hardware is already functional. ... https://www.redhat.com/archives/redhat-list/2004-February/msg00736.html I'm really still of the view that the card is left in an unstable command state upon re-booting the server. A cold boot will reset the PCI bus, hence the cards, whereas a warm boot does not. I really feel this is the problem.