I had email communication with Tejun Heo, and here is the chain of thoughts:
>> I am looking at a launchpad bug >> >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/340014 >> >> >> >> What I am doing is: >> >> >> >> 1. suspend/resume with AC plugged in >> >> 2. suspend/resume with AC unplugged >> >> 3. suspend/resume with AC plugged in >> >> 4. suspend plugged in, remove AC power, resume >> >> 5. suspend with AC removed, plug in AC power, resume >> >> >> >> Usually after 3 (or 4) I get: >> >> >> >> ata1: link is slow to respond, please be patient (ready=0) >> >> ata1: SRST failed (errno=-16) >> >> ata1: soft resetting link >> >> >> >> ata1: reset failed, giving up >> >> ata1.00: disabled >> >> ata1: EH complete >> >> sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET >> >> driverbyte=DRIVER_OK,SUGGEST_OK >> >> end_request: I/O error, dev sda, sector 152855535 >> >> Aborting journal on device sda1. >> >> >> >> After some long hours of debugging I find that when the above happens >> >> the ata taskfile status register ap->ioaddr.status_addr is set to >> >> 0xd0. returned by function: ata_sff_check_status(), as a result, >> >> ata_eh_reset() fails. >> >> >> >> Any idea what might be going on? Any pointers to help me debug/fix >> >> this further is really appreciated. >> Looks like the device or HSM (likely the device) is locking up after some disturbance at the link. Link problem isn't too surprising after suspend/resume cycle or AC plug in/out. libata EH can handle those event just fine. The problem here seems to be... * The device needs hardreset to get back to operational state again. * Unfortunately, ICH7 currently can't access sata control registers in ata_piix mode, so it can only do softreset. From ICH8 on, hardreset works because SCRs are accessible via SIDPR. ICH7 has two mechanisms to access SCRs - via ABAR or SIRI/STRD. The former requires AHCI BAR to be mapped (which isn't true for most BIOSen) and SCRAE turned on. The SIRI/STRD pair provides windowed access into ABAR area which includes the SCRs but I've never got around to do it and I don't know how it would actually work. There's also another mechanism. Toggling port enable bits in PCS might generate hardreset. After the device is gone, if you unload and reload ata_piix, does the device come back? Thanks. manoj.i...@canonical.com wrote: >> There's also another mechanism. Toggling port enable bits in PCS >> >> might generate hardreset. >> > > > This is something I can try, can you point me in the right direction ? > Well, there's no code yet. rmmoding and insmoding is the easiest it gets at this point. >> After the device is gone, if you unload and reload ata_piix, does the >> >> device come back? >> > > > in Jaunty kernel, ata_piix is not built as a module, rather, built into > > the kernel. > Can you roll a vanilla kernel and test it? I wanna make sure that hardreset is what's required before proceeding further. ============ I installed jaunty on a USB stick, chrooted into it, and tried my exercise. Interesting observation below: 1. Boot from HDD, when I remain chrooted to the USB stick suspend/resume ( with AC plugged in/ unplugged ) no ATA errors. I tried this exercise a few times and noticed that system behaves well. I even ran suspend/resume multiple times as described in #3. 2. I boot from HDD, - chroot into USB drive, exit. suspend/resume with AC plugged in, chroot into USB drive quickly and run dmesg. OK - exit chroot, unplug AC, suspend/resume, quickly chroot into USB, run dmesg. OK - exit chroot, plug in AC, suspend/resume, quickly chroot into USB, run dmesg. ATA errors appear. I rmmod -f ata_piix, it waits for the softresets to timeout, then removed the modules. I see EXT3 errors now, then I insmod ata_piix.ko. No change, still see ATA errors, hdd does not seem to reset, cannot use the filesystem. I rmmod and insmod a few times just in case, no luck, still seeing EXT3 errors and filesystem on HDD is un-usable. 3. I boot from USB stick, mount the HDD as /jaunty, and go through my whole exercise of suspend/resume tests with AC plugged in AC unplugged, even suspend/resume for 30 sec each with 30 sec intervel in between and repeated 60 times. OK. No ATA errors, (using ata_piix as module). Now I am thoughly confused. Cheers --- manjo -- Samsung NC10 fails suspend/Resume tests https://bugs.launchpad.net/bugs/340014 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
