powerbook hang from post-sleep cdrom access - fix

I think I have a fix to prevent a system hang when trying to access a cdrom after sleeping. I have a small util "wakebay" that simply does a CDROM_MEDIA_CHANGED ioctl on a specified device. I added a the line "wakebay /dev/hdc" to PMUD's wakeup script on my PDQ. This seems to get the desired response from the drive, in that it locks the door and spins the disk when it should, and if its not there, mounted, or otherwise, does nothing.

my code can be grabbed from http://www.execpc.com/~jpgarcia

Can this be done automatically at the kernel level?

Thanks.

--
Joseph P. Garcia [email protected] [email protected]
CS Undergraduate Student Employee - Systems Programmer
University of Wisconsin - Madison UW Lidar Group

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Thanks!

I wil put the code also in pmud itself. This should in fact be done at kernel level, so a patch will be needed for the current tree.

--
Stephan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

So would this always be done on wake to hdc and hde? I read Pismos, and maybe iBooks, have their drives at hde. I'm not sure if they are afflicted by this problem.

might also need to consider ide-floppy drives, like ls-120 and zip. I don't have one myself, so I don't know if these need it either. They dont have much for ioctls, just eject. If they have this problem, an ioctl to idefloppy_media_change may be needed.

I'm not concerned about it, but might genuine floppies have the hang problem too?

I assume a bay hard drive would error/exit without a problem because they can't change.

--
Joseph P. Garcia [email protected] [email protected]
CS Undergraduate Student Employee - Systems Programmer
University of Wisconsin - Madison UW Lidar Group

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

maybe

That's why this should be done from the kernel, I beleive. There, you can know if the controller is hosting a hard disk, a cdrom or an ATAPI floppy.

have much

Yep, probably, I'm not sure about those since I don't have one to test with. I'm also considering adding code for force a disk access (spin up) before trying to do the set features on wakeup.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

maybe

this

I have an iBook... the hard drive is /dev/hda, the CD-ROM is /dev/hdc. Same thing on the G4 at home, not that that matters right now...

Later,
Robbie

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Should be called from the IDE notify chain perhaps. See the last function in ide-pmac().

Michael

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Yep, this should be done juste before the pmac_ide_dma_onoff() call in ide-pmac.c/idepmac_notify_sleep(). It should be done regardless of the disk beeing in a bay or not since new machines will ultimately support sleep on desktop boxes too. Something like

switch(drive->media) {
case ide_disk:

    // spin up the disk
    break;
  case ide_cdrom:
    // do whatever you need here
    break;
  case ide_floppy:
    // do whatever you need here
    break;
}

Note that at his point, IDE interrupts have been re-enabled, so we should be careful about the way the IDE layer is called from here.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Aye. Can you be more specific about 'do whatever needs to be done'? Can I just send the disk a read command to wake it up? Send a reset command?? Will a reset command hurt if I always send a drive reset there?
I'll try that on my Lombard to see if I can save the nasty timeout when the drive was powered off with hdparm -Y ?? That would help fake sleep mode on the Pismo, or did you implement pmu sleep/wakeup there yet?

Michael

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

I don't know yet ;) I have to look more closely at my ATA spec. It may not be necessary to wakeup the disk in fact, the current code seems to be ok for the hard disk once the timeout has been bumped.

What bugs me is that on wakeup, the CD-ROM should automatically send a request unit attention on the first command to signal a disk change. So in theory, sending the media change command should not be necessary. Well, it can do no harm, I'll see what can be done.

Not yet, i've not yet figured out all the details, this machine seems to be more complicated to put to sleep (and to wakeup) than older ones, and, as usual, I have absolutely no docs nor specs.

Ben.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Except that when the disk has been shut down with hdparm -Y, it needs a reset and that will only come after quite some number of retries ans timeouts. Not for the faint of heart :-)

Let me know when you have some code to test. I can test with CD-ROM and Zip in the media bay as well BTW. Are your current changes in Paul's stable tree or in the bk stable only? Six rsync trees is a bit much for me to manage :-)

XFree86 related PCI resource diff follows separate.

Michael

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

My expirience is that just reading the drive causes a problem, much like userspace trying to read it. there is also the door locking feature that I suppose could be done explicitly on wakeup if mounted. I dont know what else a "media change" ctl entails, but it seems to do enough to get the cdrom back to where it left off.

My wallstreet has the same problem. it has to reset the whole ide bus to get it going again. rather, i use hdparm -y, which just puts it in standby rather than sleep. When the drive does a normal hardware-timeout sleep, it seems to do this, since it doesn't require a reset to wake up.

Last I remember, the result to when it resets the bus so it can wake up from a -Y, the flaky 8G (DYLA) drive is set in such a way that it can then wake up correctly from -Y. I recall that unmaskirq should be one way for the 8G, but upon the reset, its the other way. my current 6G (from brother's upgraded lombard) seems to always time out in my PDQ (at wakeup, using_dma varies, unmaskirq is always off). judging by message log, its another lost interrupt problem. It would make sense. 8G - reset, regains irq, wake normally. 6G - reset, still no irq when drive eventually wakes.

heres two sequential wakes from -Y sleep with the 6G in my PDQ

Jul 27 10:48:07 momiji kernel: hda: lost interrupt
Jul 27 10:48:07 momiji kernel: hda: dma_intr: status=0xd0 { Busy }
Jul 27 10:48:07 momiji kernel: ide0: reset: success
Jul 27 10:48:33 momiji kernel: hda: irq timeout: status=0xd0 { Busy }
Jul 27 10:48:33 momiji kernel: ide0: reset: success

sidenote, a powerbook hard drive compatibility grid can be found at
http://www01.u-page.so-net.ne.jp/ba2/nsxt/faq1E.html

--
Joseph P. Garcia [email protected] [email protected]
CS Undergraduate Student Employee - Systems Programmer
University of Wisconsin - Madison UW Lidar Group

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

OK, that seems to mean wherever we can safely send the drive a reset command after sleep, we should do that. Now under what conditions will a reset command mess up things beyond recovery? Is it possible to sleep the machine while the IDE drive has a request under service?

Michael

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

ide-pmac resets all non-mediabay (non-CD?) ide drives on wake. (idepmac_wake_disk)

looking at the mediabay code, the media bay (at least when containing a CD) seems to be reset. (set_media_bay is called, feature_set(reset) is called on the bay, messages confirms call to set_media_bay with a "kernel: media bay 0 contains a CD-ROM drive" on wake). are IDE-floppies handled by the mediabay's CD code as well?

By mutual exclusion, it would appear we already reset ide devices upon wake. the media change call may be what we need to get the removable media to re-init their status. I did get the following VFS message, which may cause concern.

Jul 27 12:00:01 momiji pmud[330]: system awake again
Jul 27 12:00:01 momiji pmud[330]: running /etc/power/pwrctl wakeup ac
Jul 27 12:00:01 momiji pwrctl: calling /etc/power/pwrctl-local wakeup ac
Jul 27 12:00:01 momiji kernel: VFS: busy inodes on changed media.

PMUD does a sync right before signalling to sleep, so most activity is reduced. I think the rest tends to be handled by the kernel's sleep with interrupts disabled, etc.

I noticed in browsing the kernel code, there is a file operation called revalidate, which takes the same params as check_media_change. cdrom.c does not define this. Would this be a route worth pursuing over the media change solution?

--
Joseph P. Garcia [email protected] [email protected]
CS Undergraduate Student Employee - Systems Programmer
University of Wisconsin - Madison UW Lidar Group

An error occurred while booting. Please try again.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Fine, so that shouldn't be it.

I don't think that's the IDE device reset, just a reset for the media bay controller (or the IDE controller) itself.

IDE-floppies in the media bay should be handled by that code.

That might be a problem - the mediachange call might conflict with the VFS still holding open channels to the device?

You know, I just remebered the same revalidate call. It's used for disks when the partition table was changed, and I recall it fails when there are other open channels to the disk as well. Moreover, check_media_change should _check_ for media change, not behave as if the media changed (which may be difficult to do across a sleep if the CD-ROM always reportss 'maybe the media was changed while I was asleep'. In that case, maybe reading in the superblock and comparing it with a cached copy should be done (that's so obvious, it may have been implemented ten years ago :-).

Michael

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

bay 0

There should also be a reset of the disk itself (via the reset line).

Yep. That's a "generic" problem with the current sleep code (and with media-bay removal in general). linux 2.2 is not really prepared to handle hot-swap of IDE disks.

In any way, I still have my problem of setting nIEN in the IDE control register of some powerbooks causing a hang of the entire machine (bus not ack'ing ?). Other IDE registers work fine and the IDE control register seems to work fine in normal conditions, the hang only happens when setting this inside my set_feature code. I'm wondering if it's due to a very crappy CD-ROM drive, a very-crappy Apple home-made IDE controller, or be missing something obvious...

Ben.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/