Re: CONFIG_IBM_BAY
On Sun, 18 Mar 2007, Tejun Heo wrote: Kristen Carlson Accardi wrote: 1. It will handle all device types (ATAPI, PATA, SATA, batteries); 2. It will do the right thing on plug and unplug. This means telling the rest of the kernel to disable the device in the bay, for example. Right now we shutdown one end of the PATA/SATA link on ThinkPads eletrically, and leave libata to scream blood murder until it disables its end due to too many retries, for example; :-) Yeah :) Try it with old ide, and the results are not... pretty. libata new EH *rules*. Personally - I think tighter integration to libata here would be beneficial. Once libata acpi support is straightened out, if we can store acpi handles associated with libata devices, we can perhaps have a mechanism of obtaining ata_device structs so that we can have a nice way of telling libata to delete devices etc. I am hoping libata-acpi will be straightened out for 2.6.22. I dunno what the thread is really about but can't this be dealt within acpid? Finding out the correct scsi host node can be tricky but I think It could, yes. But to me the kernel looks like the proper place for this one. Not to mention that we *really* should know the ACPI namespace - kernel device mapping in kernel, instead of doing half-assed things in userspace to call back into kernel land later... it may come in handy for other things (proper ACPI/driver exclusion of access to devices, for one), not just libata matters and dock/bay ejects. It is not like it is a policy thing. The only possible correct path to follow when doing an eject is to disable the devices and buses in the it will be powered off side of the ejection hardware. And depending on userspace for this is just (IMHO) ugly and error-prone. The kernel really should know how to do it, and doing it is *easy* as long as you know the mapping (which you should know for other reasons). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CONFIG_IBM_BAY
On Sun, 18 Mar 2007, Holger Macht wrote: those ThinkPads where it is needed. Afterwards it does the corresponding dock/undock request on ibm_acpi. And this works reliably good what I can see from the feedback I already got. But for this to work, userspace would It should work with the generic bay device too, but I have no ideas about dock. But you'll need to deal with udev with the new bay device, something I am not too happy about. These things are ACPI events, they should remain so unless all other ACPI events are going to become uevents. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CONFIG_IBM_BAY
On Sun, 18 Mar 2007, Holger Macht wrote: It doesn't work, I've already tried. The bay driver only emits an event if you really try to remove the bay, but not on docking/undocking. Ah, now I understand what you mean. Looks like we really need the dock driver to sort of like act as a bus. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CONFIG_IBM_BAY
On Mon, 19 Mar 2007, Matthew Garrett wrote: But you still have to deal with mounted filesystems, no matter if it a cardbus or a cdrom. Wouldn't we need something like 'save removal' triggered from userspace like you maybe know from 'the other' operating system? Yes, there's a need for a mechanism to deal with all of this safely, but the same is true of any storage device that can be hotplugged (USB, firewire, anything in a hotplug bay...) True. The best available procedure to do this for ACPI bay/dock currently is, AFAIK: 1. Send event when bay/dock please release button/lever is pressed. Do *nothing* else. I know bay does this right, maybe dock doesn't. 2. Wait for something to echo 1 eject or to call the appropriate routine directly, or (if this exists) for an notification from firmware that the user IS disconnecting the device for real. 3. delete the device. This means force-umount, force-close, etc. 4. Tell the hardware to eject. Note that currently (2) and (3) are swapped, as (3) is being done by userspace request, instead of by the kernel. This is something I *don't* like. IMO should do as PCMCIA and hotplug PCI does, and do that in kernel space. The time window where one can ask the user something or notify it is not a good idea to eject is between (1) and (2). If the eject command is issued, delete devices (includes sync, of course) and eject. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ibm-acpi-devel] CONFIG_IBM_BAY
On Mon, 19 Mar 2007, Shem Multinymous wrote: Userspace wants to (non-force-)-unmount by itself after (1), so it can stop the eject process if the filesystems cannot be cleanly unmounted. So the force-unmount at (3) ends up being a redundant safety measure at best. More like it is a make sure we can actually eject, as we have been told to. We might return an error instead, but if we do, we need a way to force-eject (e.g. echo 2 eject). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ibm-acpi-devel] CONFIG_IBM_BAY
On Tue, 20 Mar 2007, Shem Multinymous wrote: More like it is a make sure we can actually eject, as we have been told to. We might return an error instead, but if we do, we need a way to force-eject (e.g. echo 2 eject). Which stage are you referring to? Stage 2, of course. It is useful to have a force_eject functionality that **will** eject and not error out because of anything other than the eject command itself failing. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] sd: implement START/STOP management
On Thu, 22 Mar 2007, Vladislav Bolkhovitin wrote: Seems, there is another way of doing a bank spin up / spin down: doing it in two passes. On the first pass START_STOP will be issued with IMMED=1 on all devices, then on the second pass START_STOP will be issued with IMMED=0. So the devices will spin up / spin down in the parallel, but synchronously, hence the needed result will be achieved And maybe trip the PSU's overcurrent defenses? There is a reason to default to sequential spin-up for disks... Of course, it can be user-selectable. But should it be the default? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Loud pop coming from hard drive on reboot
On Sat, 14 Apr 2007, Pavel Machek wrote: How common are notebooks that cut power to disks during reboot? Not common at all. Given that it wears the electronics a lot, it must be either a defect (of the kinds Brazilian law forces the manufacturer to either fix or give you your money back). Assuming it also does this when running Windows, I'd report it as a grave bug to the vendor and demand it to be fixed, or the machine to be exchanged with another model that doesn't have this defect. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Pkg-sysvinit-devel] [PATCH] libata: remove libata.spindown_compat
On Sat, 19 May 2007, Tejun Heo wrote: To fix this issue, halt(8) started issueing WIN_STANDBYNOW1 (0xE0) and WIN_STANDBYNOW2 (0x94) ioctls before halt and poweroff, as that was more reliable than flush cache and the effect was the same. One culprit there is that, according to the spec, STANDBYNOW doesn't necessarily imply cache flush and AFAIK issuing STANDBYNOW to libata devices is to avoid emergency unload. Can you comment on this Henrique? Well, the reason I raised the ruckus in the first place was just the emergency unload, yes. I didn't know about any missing cache flushes (and AFAIK we never had any reported to us). We will have to fix that in halt(8) IMHO, just in case. And probably hdparm/sdparm should also know to not standby or sleep disks without a cache flush, either. I also don't know the history of halt(8), Miquel does... so I have not much else to comment. At least now it is clear what we need halt(8) to do (in Debian, anyway): 1. check if we have a responsible kernel or not through sysfs. 1a: kernel is responsible, and can spin down disks at shutdown - if given -h on command line, use sysfs to tell kernel to spin down *all* disk devices we can find in sysfs, and don't send any taskfiles or IOCTLs to the disks. 1b: kernel is missing this essential feature - keep doing what we are doing now, but issue a cache flush before we send any standby commands. 2. push that to Debian unstable, and also to stable-proposed-updates, or at the very least to backports.org. This will give maximum compatibility with the kernel, and fix the cache-not-flushed-before-spindown issue. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.22 libata spindown
On Fri, 01 Jun 2007, Jeff Garzik wrote: IIRC, Debian was the one OS that really did need a shutdown utility update, as the message says :) Actually, editing /etc/init.d/halt is enough. Find the hddown=-h and change it to hddown=. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/3] Enable Aggressive Link Power management for AHCI controllers.
On Mon, 11 Jun 2007, Kristen Carlson Accardi wrote: Setting Effect -- min_power ALPM is enabled, and link set to enter lowest power state (SLUMBER) when idle Hot plug not allowed. max_performance ALPM is disabled, Hot Plug is allowed medium_power ALPM is enabled, and link set to enter second lowest power state (PARTIAL) when idle. Hot plug not allowed. Just some food for thought: If you split it into a enable/disable (0/1) attribute, and a level attribute (some sort of integer scale, or min, medium, max if you must use strings. You could use four levels to mimic the PCI device power state, for example), it might make its usage more generic, and easier from userspace, as it decouples the need to turn it on/off from the need to know which level the user wants it set to when you turn it on. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/3] Enable Aggressive Link Power management for AHCI controllers.
On Mon, 11 Jun 2007, Jeff Garzik wrote: on/off doesn't really make sense if the question is do you favor power or do you favor performance... Actually, it does if you think of it as do you need hotplug right now or not?. How about just making it a numeric scale with 0 meaning no power saving and then some fixed number of levels (e.g 0-9)? The original proposal seems far more intuitive than these alternatives. There is nothing intuitive about the text or the levels. All cases need proper documentation. I'd never expect link powersaving to kill hotplug, unless I read the AHCI docs. And enable/disable ain't intuitive either :( But enable/disable is useful to get stuff like SATA bay hotplug, dock/undock and other stuff that needs hotplug to be working right, unless we can make that automatic so that power saving is always disabled in all situations we'd need hotplug to be working? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/3] Enable Aggressive Link Power management for AHCI controllers.
On Tue, 12 Jun 2007, Matthew Garrett wrote: On Tue, Jun 12, 2007 at 09:18:19AM -0300, Henrique de Moraes Holschuh wrote: On Tue, 12 Jun 2007, Matthew Garrett wrote: On laptops, I suspect that we'll probably get an ACPI interrupt even if the AHCI hotplug pathway can't manage. As long as we don't crash the drive or AHCI controller because we hotplugged it in a way it didn't like (like trying to hotplug a ICH5R would cause). Laptop bays are designed to deal with hotplugging PATA - I don't think this is too much of an issue :) The new SATA ones use the SATA hardware hotplug ;-) Just like the pci-e cards use usb2.0 and pci-e hotplug... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disk spin down issue on shut down/suspend to disk
On Mon, 06 Aug 2007, Tejun Heo wrote: Cc'ing Henrique. Any ideas? Check if /etc/init.d/halt is calling halt(8) with the -h flag. If it is, remove that -h flag. Usually, there is a hddown variable that holds it, you just need to get rid of it. I don't know anything about a Sidux, though. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disk spin down issue on shut down/suspend to disk
On Mon, 06 Aug 2007, Michael Sedkowski wrote: Dnia 06-08-2007, Pn o godzinie 11:23 -0300, Henrique de Moraes Holschuh napisa??(a): On Mon, 06 Aug 2007, Tejun Heo wrote: Cc'ing Henrique. Any ideas? Check if /etc/init.d/halt is calling halt(8) with the -h flag. If it is, remove that -h flag. Usually, there is a hddown variable that holds it, you just need to get rid of it. I don't know anything about a Sidux, though. Well there is an -h variable: # Don't shut down drives if we're using RAID. hddown=-h if grep -qs '^md.*active' /proc/mdstat then hddown= fi log_action_msg Will now halt halt -d -f $netdown $poweroff $hddown However removing it has no effect, the drive still spins down two times. Nothing in Debian userspace will spin down the drive if you kill that -h, at least as far as I know. Sidux is a Debian Unstable based distro with it's own set of patches including the shut down patch provided here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426224 You'll probably have to ask Sidux what changes they made that could cause the double spin down, even if halt(8) is never passed the -h flag. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disk spin down issue on shut down/suspend to disk
On Tue, 07 Aug 2007, Tejun Heo wrote: Michael Sedkowski wrote: Hmmm... If the problem only shows up on nx6325, it might be that ACPI is pulling unnecessary stunt. Please apply the attached patch and report when the disk spins down and up. Disk spins down on Pre-shutdown prepare and then goes up and down on Power down. Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether it spins down the disk correctly. Does emergency unload count increase after each power down? Also, please post the result of 'dmidecode'. You know, this actually make a lot of sense, and one can't even complain about firmware that pulls that off. Any chances of changing things so that we inspect/snoop all tasks sent to the device, and filter them out, or react to them accordingly? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disk spin down issue on shut down/suspend to disk
On Tue, 07 Aug 2007, Tejun Heo wrote: Henrique de Moraes Holschuh wrote: On Tue, 07 Aug 2007, Tejun Heo wrote: Michael Sedkowski wrote: Hmmm... If the problem only shows up on nx6325, it might be that ACPI is pulling unnecessary stunt. Please apply the attached patch and report when the disk spins down and up. Disk spins down on Pre-shutdown prepare and then goes up and down on Power down. Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether it spins down the disk correctly. Does emergency unload count increase after each power down? Also, please post the result of 'dmidecode'. You know, this actually make a lot of sense, and one can't even complain about firmware that pulls that off. Well, I'm complaining. I think the problem here is that it isn't clear which one is who's responsibility. There's a Korean saying which The BIOS *has* to do it when in DOS mode, the HD manuals are very very clear about it. Doing it through ACPI ATA objects is at least non-broken as far as these things go, as one knows when to do it directly (non-ACPI mode), and one doesn't talk to the disk directly. approximately translates into if you have too many boatmen on a ship, it goes to mountain. We also have a bunch of Toshiba laptops which Yeah, that's a problem. But we can avoid it if we start snooping what ACPI is asking us to deliver to the disks, which IMO is an extremely good idea anyway. want the ATA controller to be in enabled state when ACPI suspend is invoked because the suspend method apparently wants to execute some commands before going to sleep. That's just broken, since it is not even using a OS-backed SATA/ATA ACPI method to do it. I wish ACPI spec carries a big fat sign saying stay f*** away from anything which isn't essential to the requested operation. Shutting down disks *is* essential to the power off operation. ACPI would have to mandate who is to do it, instead (ACPI table or OSI by itself). Any chances of changing things so that we inspect/snoop all tasks sent to the device, and filter them out, or react to them accordingly? No, we can't unless we snoop ACPI method execution and detect accesses to IO ports or iomem regions. It's not going through any driver. This is a gross mess. I don't mean fixing the stuff clowns like Toshiba did. The correct fix for that is to blacklist the hell out of that crap and patch their DSDT into something remotely sane. I do mean snooping the ACPI methods that *return* a taskset to send to the driver, and we send that taskset ourselves in libata and libpata(?). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disk spin down issue on shut down/suspend to disk
On Tue, 07 Aug 2007, Tejun Heo wrote: emergency unload. Emergency unload does shorten the lifespan of the disk but you don't have to worry too much about it. Disks are designed to withstand certain number of emergency unloads. You *do* have to worry about it in any box you turn off daily. Desktop HDs will croak fast in that scenario, laptop HDs less so, but still too fast. A very good laptop HD can last about 20k emergency unloads (this is a unit that can do about 600k normal unloads in its lifetime). Desktop and server HDs don't even come close to those numbers, last time I checked. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disk spin down issue on shut down/suspend to disk
On Tue, 07 Aug 2007, Tejun Heo wrote: Henrique de Moraes Holschuh wrote: approximately translates into if you have too many boatmen on a ship, it goes to mountain. We also have a bunch of Toshiba laptops which Yeah, that's a problem. But we can avoid it if we start snooping what ACPI is asking us to deliver to the disks, which IMO is an extremely good idea anyway. If it were done that way (by asking OS driver to deliver commands TFs), I wouldn't have any problem at all. The spin down command is issued from deep down in the acpi power off method - entering S5 directly issues ATA commands bypassing the whole OS except for the ACPI interpreter. It's just like the toshiba suspend crap and there's no standard way to tell whether the acpi power off method is gonna do it or not. We'll just have to blacklist it. Urk. I see. I'd also suggest adding a FAIL to the Linux firmware toolkit to any DSDT doing this. Who should we prod to add that check? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disk spin down issue on shut down/suspend to disk
On Tue, 07 Aug 2007, Robert Hancock wrote: You *do* have to worry about it in any box you turn off daily. Desktop HDs will croak fast in that scenario, laptop HDs less so, but still too fast. A very good laptop HD can last about 20k emergency unloads (this is a unit that can do about 600k normal unloads in its lifetime). Desktop and server HDs don't even come close to those numbers, last time I checked. It only matters on hard drives which actually use load-unload heads. Lots of desktop/server drives (perhaps some laptop ones as well) still use contact start/stop, which doesn't remove the heads from the platters on I am not so sure about that. Please correct me if I am wrong, but contact stop in an emergency retract shakes the head assembly badly as well. It subjects the head assembly to higher acceleration than a normal seek, and a nasty impulse at impact with the stopper. And I very much doubt it is nice to the heads to slide into the parking zone at high speed and hit the bumper while over it. Unless I missed something, I don't why an emergency retract would not be as big a problem as an emergency unload. Maybe we should hunt down some proper datasheets for drives lacking head load/unload technology, and check what they say about emergency unloads... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] libata: Integrate ACPI-based PATA/SATA hotplug - version 3
On Thu, 27 Sep 2007, Matthew Garrett wrote: The spec seems to imply that even if the drive hotswap bay and the battery bay are physically the same, they're logically distinct. 10.2.1 That holds true for thinkpads up to the T43, at least. I don't know about the newer ones. You get bay ejects/inserts notifications from the device node corresponding to what was inserted/removed from the multi-purpose bay. I /suspect/ that _STA on the bay device won't return true if there's a battery in there, and so we aren't expected to call the _EJ0 method if Correct, on thinkpads up to the T43 at least. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Disk shock protection (revisited)
On Tue, 26 Feb 2008, Elias Oltmanns wrote: You don't want, for example, to swap out other apps, swap in the daemon, in order to handle a sudden acceleration. Quite. But with mlock this particular problem can be handled in user space just fine. The only reason I can see right now for putting this And, as long as there is a way to also invoke it from within the kernel, we can call it from inside the kernel as well when there is a reason to make that function available. Full flexibility is easily attainable here and nothing we should bother about too much. logic into the kernel as well is to keep the functionality around even Some hardware (Apple's?) has the entire APS logic in firmware (and AFAIK *also* export the accelerometer data for other uses). On those boxes, if you want to trust the firmware, you just ignore the accelerometer and hook to an interrupt. When you get the interrupt, you freeze the queue and unload heads. Adding that to work in-kernel would be trivial. Adding a suspend-time-only emergency HDAPS in-kernel monitor thread would also be doable, if we wanted to duplicate that for ThinkPads (I don't really think it is needed, but...). As long as queue freezing and the required unload immediate procedure can be called in at *any* time before the disk device, and its buses and controller are suspended, it would do to implement whatever we feel it is needed. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
