this is very similar to bug 5227, but i could not find ide cdrom or related in drivers section. there was ide component in io, but i was not sure that is the correct one - so i hope somebody will change this to the correct component... if the cd is mounted during suspend, there are errors produced after resume when trying to access cdrom : Sep 14 20:10:35 is kernel: hdc: tray open Sep 14 20:10:35 is kernel: end_request: I/O error, dev hdc, sector 1148700 Sep 14 20:10:35 is kernel: Buffer I/O error on device hdc, logical block 287175 of course, tray is fully closed. sectors/blocks vary. the cd is partially readable - i can browse directory tree and access some files. some generate errors. it seems that it is enough to mount the cd just once before resuming - after resuming errors pop out even if the cd itself was unmounted during suspend.
i got this response from fujitsu-siemens (i must admit, i'm pleasantly surprised by their speed, though i have almost no technical knowledge to assess the answer ;) ) : "The operating system saves and restores any registers that are not in the AUX power well. This is defined in the Enhanced Host Controller Interface (EHCI) specification, but is not defined in the UHCI or OHCI specifications. Because of this, the operating system does not save or restore any registers for UHCI or OHCI. The following rules apply: Power management rules for USB host controllers transitioning from USB suspend to USB working. This is what is expected for: Sleep State S3 Sleep State S0 1. The controller must not reset the USB bus or cause a disconnect or power loss on any of the root USB ports. 2. The system BIOS must not enable any type of legacy USB BIOS or otherwise enable the host controller to a run state. 3. If a Peripheral Component Interconnect (PCI) reset occurs in addition to rule 1, the BIOS must restore all host registers to their state prior to entering low power. Root ports should not indicate connect or enable status changes. 4. The controller hardware must be in a functional state that is capable of driving resume and entering the run state without requiring a global hardware reset that otherwise would result in a USB bus reset driven on the root ports. " additionally, in the answer was some finnish text (that supposedly refers to ms windows xp). as i have no knowledge of finnish i have no idea what it exactly says :) : "Eli k
whoops. wrong issue. sorry about that.
Does it still happen with 2.6.15?
sorry for the delay. with 10.196.5.2 it seems that i can not reproduce errors after resuming. the only way i was able to get "input/output error" was suspending while reading - upon resume disk access failed. after resuming it, no further errors appeared. could this be connected to disc spinup timeout (that is, kernel thinks that there should be no spinup for the drive in the middle of the read operation) ?
crap. i have to take some sleep. instead of "10.196.5.2" it should, of course, have been "2.6.15.2"
I assume that the problem is fixed, can I close this bug?
probably yes, but only if it is ok that cd access fails for some time after resuming ;) maybe some workarounds can be done right after resuming to allow cd access operations to continue normally ?
Is there anybody looking into this issue? I still get the same errors trying to read a DVD after resume. The scenario is: 1. I suspend using suspend2. 2. I resume from suspend. 3. I pop in a DVD and mount it. 4. Directory listing gives partial reading and throws the errors reported earlier into dmesg. The only difference is that I am seeing this even with suspend-to-disk.
Ok, my errors are slightly different and even the scenario is slightly different: Jul 10 21:23:32 localhost end_request: I/O error, dev hdd, sector 1088 Jul 10 21:23:32 localhost ISOFS: unable to read i-node block Jul 10 21:23:54 localhost hdd: drive_cmd: status=0x51 { DriveReady SeekComplete Error } Jul 10 21:23:54 localhost hdd: drive_cmd: error=0x04 { AbortedCommand } Jul 10 21:23:54 localhost ide: failed opcode was: 0xec The same DVD disk reads fine after the reboot. I can reproduce this error on every suspend-resume cycle.
I see these errors in 2.6.17.3
Does it still happen for 2.6.18?
unfortunately motherboard died for the laptop in question during this time. unless somebody has a similar machine or one that also has such a problem, the report unfortunately will have to be closed... i could try gaining access to a similar laptop, but that is a relatively small chance.