Re: broken suspend in .2.6.25-rc3 on T61p (was Re: new regression in 2.6.25-rc3: no keyboard/lid acpi events on thinkpad T61p)
Pavel Machek wrote: commit 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2 Author: Pavel Machek <[EMAIL PROTECTED]> Date: Thu Feb 21 13:56:55 2008 +0100 power_state: get rid of write-only variable in SATA This is pretty unlikely to be it. Can you double check that this patch really breaks something? Quote... After reverting 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2 on top of 2.6.25-rc3 the kernel again resumes from suspend to ram. Seems pretty clear to me. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Don't fail ata device revalidation for bad _GTF methods
Matthew Garrett wrote: Experience suggests that the _GTF method may be bad. We currently fail device revalidation in that case, which seems excessive. Signed-off-by: Matthew Garrett <[EMAIL PROTECTED]> applied - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libata: cdrw/dvdrom disabed after s2ram (2.6.24-rc2)
On Thu, Nov 08, 2007 at 10:13:41AM -0800, Andrew Morton wrote: > > On Thu, 8 Nov 2007 13:02:56 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: > > On Thu, Nov 08, 2007 at 09:49:58AM -0800, Andrew Morton wrote: > > > > On Thu, 08 Nov 2007 17:43:59 +0100 Roberto Oppedisano <[EMAIL > > > > PROTECTED]> wrote: > > > > Andrew Morton wrote, On 11/07/2007 09:13 PM: > > > > >> On Wed, 07 Nov 2007 15:15:07 +0100 Roberto Oppedisano <[EMAIL > > > > >> PROTECTED]> wrote: > > > > >> Hello. > > > > >> I noticed that after suspending to ram the DVD-ROM/CDRW > > > > >> drive in no more recognized on my laptop. Looking at dmesg > > > > >> after suspend i found: > > > > >> > > > > >> [5.313446] ata2.00: _GTF unexpected object type 0x1 > > > > >> [5.313453] ata2.00: ACPI on devcfg failed the second time, > > > > >> disabling > > > > >> (errno=-22) > > > > >> [5.313457] ata2.00: revalidation failed (errno=1) > > > > >> [5.313459] ata2.00: disabled > > > > >> > > > > >> > > > > >> Not sure when the bug was introduced or if it has been always been > > > > >> there > > > > >> (but I can investigate if needed). > > > > >> > > > > >> More details on request. > > > > >> > > > > >> Following dmesg pre and after suspend. > > > > > Yes, it would be useful if you could work ot whether this worked OK > > > > > in an > > > > > earlier kernel, thanks. > > > > Hello Andrew. > > > > The bug has been recently added. > > > > > > > > I did a git-bisect, but the result is probably not completely useful, > > > > because many kernel did non build with my config, and I marked them as > > > > bad. > > > > > > Those build errors are bad. Please report them. They directly prevented > > > you from finding the commit which caused this regression. > > > > > > The only way in which we'll stop people doing crap like this is to rub > > > their noses (and the person who committed its nose) in it. > > > > > > > Anyway here's the output of git-bisect: > > > > > > > > [EMAIL PROTECTED]:/usr/src/linux-2.6$ git bisect bad > > > > 99874d50481c093adfe74e796436024d88b6a48c is first bad commit > > > > commit 99874d50481c093adfe74e796436024d88b6a48c > > > > Author: Jens Axboe <[EMAIL PROTECTED]> > > > > Date: Fri Oct 12 12:50:41 2007 +0200 > > > > > > > > [BLOCK] Only include the compat ioctl code if CONFIG_BLOCK is set > > > > > > > > Add an extra CONFIG_BLOCK_COMPAT that we can use in the Makefile > > > > > > > > Signed-off-by: Jens Axboe <[EMAIL PROTECTED]> > > > > > > > > :04 04 f88b7b0e496edb8fbdd4bc74abd1a742a6a1d6d9 > > > > 32ead3bd57b52a664cc8ccb662195041868d7632 M block > > > > > > > > ... > > > > > > > > If needed I can do further investigation, changing the assumption of > > > > efefc6eb38d43b8e5daef482f575d767b002004e to good and see if the bisect > > > > points to a different commit. > > > > > > Yes, it'll be some other commit. Sorry. > > > > > > It would help you (and me) if an ata developer could pay some attention. > > > > > > Rafael, please track this as an ata regression. > > > > We unfortunately need to bounce this ACPI people. > > > > We recently turned on ACPI by default in libata, which INTRODUCES the > > ability of the BIOS to pass random, unknown-quality ATA commands to the > > device. > > > > I highly expect some breakage related to this... if ACPI folks > > determine it is not an ACPI bug, then its a firmware bug and we will > > have to avoid that firmware on that platform. > > > > Set module option "noacpi" to 1, to disable ACPI and see if that fixes > > the problem. > > > > This will be a common diagnosis and workaround, FWIW... > > > > I suspect it wold be best to disable the feature for the 2.6.24 release, > then reenable it afterwards and keep doing this until the code is > sufficiently stable. Re-read my message :) The code is stable. Behavior _by definition_ will vary by BIOS. This feature (a) enables suspend/resume, but (b) now sends random unvalidated shite to the device that we hope will work. Look at all the messages where turning on ACPI in libata _fixed_ suspend/resume (because its obviously required for many, including laptops). So it's not an easy "turn it off" answer, you break shitloads of suspend/resume that way, that we just fixed. The message "_GTF unexpected object type" indicates a broken BIOS, so IMO we should proceed in that direction, blacklisting that platform. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]libata-acpi: add ACPI _PSx method
Shaohua Li wrote: Not sure, this is just to call a BIOS routine, but a check should be safer. Thanks! ACPI spec (ver 3.0a, p289) requires IDE power on/off executes ACPI _PSx methods. As recently most PATA drivers use libata, this patch adds _PSx method support in libata. ACPI spec doesn't mention if SATA requires the same _PSx method. Signed-off-by: Shaohua Li <[EMAIL PROTECTED]> Acked-by: Len Brown <[EMAIL PROTECTED]> What is the safety factor on this patch? :) Since we are into 2.6.24-rc, my preference would be to let this get some testing in -mm, and push it upstream for 2.6.25. Comments? Jeff - To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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 5
Matthew Garrett wrote: Modern laptops with hotswap bays still tend to utilise a PATA interface on a SATA bridge, generally with the host controller in some legacy emulation mode rather than AHCI. This means that the existing hotplug code in libata is unable to work. The ACPI specification states that these devices can send notifications when hotswapped, which avoids the need to obtain notification from the controller. This patch uses the existing libata-acpi code and simply registers a notification in order to trigger a rescan whenever the firmware signals an event. Signed-off-by: Matthew Garrett <[EMAIL PROTECTED]> --- Diffed against #upstream. Fairly sure I've got it right this time... indeed you did sir :) applied, thanks - To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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 4
Matthew Garrett wrote: Fix libata-acpi.c build failure. Signed-off-by: Matthew Garrett <[EMAIL PROTECTED]> --- Sorry, I'd diffed the original against libata-dev master rather than ALL. This tidies up the changes. I had to yank the patch. For bisect-ability, we really really want to avoid pushing patches upstream that don't build; so, please resend a fixed version. BTW, you generally want to diff against libata-dev.git#upstream. 'upstream' branch is always what is queued for the next kernel release. 'ALL' is a meta-branch that includes #upstream, but also other stuff we want in -mm for testing. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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 4
Jeff Garzik wrote: Matthew Garrett wrote: Modern laptops with hotswap bays still tend to utilise a PATA interface on a SATA bridge, generally with the host controller in some legacy emulation mode rather than AHCI. This means that the existing hotplug code in libata is unable to work. The ACPI specification states that these devices can send notifications when hotswapped, which avoids the need to obtain notification from the controller. This patch uses the existing libata-acpi code and simply registers a notification in order to trigger a rescan whenever the firmware signals an event. Signed-off-by: Matthew Garrett <[EMAIL PROTECTED]> --- This incorporates Jeff's feedback. sdev is checked for NULL, and different notifications are registered for ap-level and dev-level handlers. The core code is split out into a helper function called by both of these. The other change is the removal of the extraneous newline from the end of the notification event, to match the upstream change in the bay driver. applied Come on, dude! This doesn't even build: UPD include/linux/compile.h drivers/ata/libata-acpi.c: In function ‘ata_acpi_handle_hotplug’: drivers/ata/libata-acpi.c:104: error: ‘struct ata_port’ has no member named ‘eh_info’ drivers/ata/libata-acpi.c: In function ‘ata_acpi_dev_notify’: drivers/ata/libata-acpi.c:130: error: ‘struct ata_device’ has no member named ‘ap’ drivers/ata/libata-acpi.c: In function ‘ata_acpi_associate’: drivers/ata/libata-acpi.c:178: error: implicit declaration of function ‘ata_port_max_devices’ drivers/ata/libata-acpi.c:179: error: ‘struct ata_port’ has no member named ‘device’ make[2]: *** [drivers/ata/libata-acpi.o] Error 1 - To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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 4
Matthew Garrett wrote: Modern laptops with hotswap bays still tend to utilise a PATA interface on a SATA bridge, generally with the host controller in some legacy emulation mode rather than AHCI. This means that the existing hotplug code in libata is unable to work. The ACPI specification states that these devices can send notifications when hotswapped, which avoids the need to obtain notification from the controller. This patch uses the existing libata-acpi code and simply registers a notification in order to trigger a rescan whenever the firmware signals an event. Signed-off-by: Matthew Garrett <[EMAIL PROTECTED]> --- This incorporates Jeff's feedback. sdev is checked for NULL, and different notifications are registered for ap-level and dev-level handlers. The core code is split out into a helper function called by both of these. The other change is the removal of the extraneous newline from the end of the notification event, to match the upstream change in the bay driver. applied - To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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
Matthew Garrett wrote:
Modern laptops with hotswap bays still tend to utilise a PATA interface
on a SATA bridge, generally with the host controller in some legacy
emulation mode rather than AHCI. This means that the existing hotplug
code in libata is unable to work. The ACPI specification states that
these devices can send notifications when hotswapped, which avoids the
need to obtain notification from the controller. This patch uses the
existing libata-acpi code and simply registers a notification in order
to trigger a rescan whenever the firmware signals an event.
Signed-off-by: Matthew Garrett <[EMAIL PROTECTED]>
---
This makes two changes to the previous patch:
1) It implements the locking suggested by Tejun
2) It sends a uevent on the device kobject. I've implemented this
because grabbing the notification handler means that the bay driver can
no longer do it, so it's necessary to generate compatible events. If the
event type is 3, it indicates that the user has merely requested an
eject - the drive hasn't gone at this point. Sending the notification
allows userspace to attempt to unmount the filesystems before sending a
command to initiate the eject.
I'm not especially happy about the chain used to get the scsi device
kobject. Is there a cleaner way to do that? Other than that, I've now
tested this on multiple systems (a 965-based Thinkpad, a 915-era Dell
and even an HP with no SATA whatsoever) without any obvious breakage.
diff --git a/drivers/ata/libata-acpi.c b/drivers/ata/libata-acpi.c
index c059f78..68bb7fa 100644
--- a/drivers/ata/libata-acpi.c
+++ b/drivers/ata/libata-acpi.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include "libata.h"
#include
@@ -66,6 +67,41 @@ static void ata_acpi_associate_ide_port(struct ata_port *ap)
}
}
+static void ata_acpi_notify(acpi_handle handle, u32 event, void *data)
+{
+ struct ata_port *ap = data;
+ struct ata_eh_info *ehi = &ap->eh_info;
+ char event_string[12];
+ char *envp[] = { event_string, NULL };
+ struct kobject *kobj = NULL;
+ int i;
+
+ if (ap->acpi_handle && handle == ap->acpi_handle)
+ kobj = &ap->dev->kobj;
+ else {
+ for (i = 0; i < ata_port_max_devices(ap); i++) {
+ struct ata_device *dev = &ap->device[i];
+ if (dev->acpi_handle && handle == dev->acpi_handle)
+ kobj = &dev->sdev->sdev_gendev.kobj;
+ }
+ }
+
+ if (event == 0 || event == 1) {
+ unsigned long flags;
+ spin_lock_irqsave(ap->lock, flags);
+ ata_ehi_clear_desc(ehi);
+ ata_ehi_push_desc(ehi, "ACPI event");
+ ata_ehi_hotplugged(ehi);
+ ata_port_freeze(ap);
+ spin_unlock_irqrestore(ap->lock, flags);
+ }
+
+ if (kobj) {
+ sprintf(event_string, "BAY_EVENT=%d\n", event);
+ kobject_uevent_env(kobj, KOBJ_CHANGE, envp);
+ }
+}
+
/**
* ata_acpi_associate - associate ATA host with ACPI objects
* @host: target ATA host
@@ -81,7 +117,7 @@ static void ata_acpi_associate_ide_port(struct ata_port *ap)
*/
void ata_acpi_associate(struct ata_host *host)
{
- int i;
+ int i, j;
if (!is_pci_dev(host->dev) || libata_noacpi)
return;
@@ -97,6 +133,22 @@ void ata_acpi_associate(struct ata_host *host)
ata_acpi_associate_sata_port(ap);
else
ata_acpi_associate_ide_port(ap);
+
+ if (ap->acpi_handle)
+ acpi_install_notify_handler (ap->acpi_handle,
+ACPI_SYSTEM_NOTIFY,
+ata_acpi_notify,
+ap);
+
+ for (j = 0; j < ata_port_max_devices(ap); j++) {
+ struct ata_device *dev = &ap->device[j];
+
+ if (dev->acpi_handle)
+ acpi_install_notify_handler (dev->acpi_handle,
+ACPI_SYSTEM_NOTIFY,
+ata_acpi_notify,
+ap);
Mostly OK. Notes:
1) Check dev->sdev for NULL
2) remove the unnecessary ata_device loop. If you know the ata_device
pointer, you should not throw it away and then do a search to find it again.
You need two functions, ata_acpi_ap_notify() and ata_acpi_dev_notify().
Pass 'ap' to the former, and 'dev' to the latter.
Both functions should marshal their arguments, then call a common
function (presumabl
Re: [PATCH] libata: Integrate ACPI-based PATA/SATA hotplug - version 2
Matthew Garrett wrote: Modern laptops with hotswap bays still tend to utilise a PATA interface on a SATA bridge, generally with the host controller in some legacy emulation mode rather than AHCI. This means that the existing hotplug code in libata is unable to work. The ACPI specification states that these devices can send notifications when hotswapped, which avoids the need to obtain notification from the controller. This patch uses the existing libata-acpi code and simply registers a notification in order to trigger a rescan whenever the firmware signals an event. Signed-off-by: Matthew Garrett <[EMAIL PROTECTED]> --- Testing on an HP with the hotplug device as the slave on a PATA channel flagged a bug - the notification needs to be tied to the channel handle as well as the device ones. With this version, I can happily hotswap the HP device. It ends up sitting for a few seconds while failing to revalidate, but then recovers with everything working fine. the code looks correct. I have one main reservation. how can we be sure that this is active only where other hand-programmed hotplug code is absent? ACPI doesn't inherently know which of our controllers are already set up to do hotplug, so it seems like there is a possibility of conflict if both the firmware and the controller are chirping. If we can quell my fears in that area, I'm ok with the change. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]libata-acpi: add ACPI _PSx method
Shaohua Li wrote: ACPI spec (ver 3.0a, p289) requires IDE power on/off executes ACPI _PSx methods. As recently most PATA drivers use libata, this patch adds _PSx method support in libata. ACPI spec doesn't mention if SATA requires the same _PSx method, but executing _PSx for SATA should be ok I think. Signed-off-by: Shaohua Li <[EMAIL PROTECTED]> ahci and sata_sil24 directly power off components, so it seems quite unwise for "modern" SATA controllers. ISTR Tejun, when he cleaned up libata-acpi, finally figured out a good way to distinguish ACPI's idea of "IDE" -- which sometimes includes the legacy programming mode of SATA controllers, and a controller running a modern programming mode. Your best bet is to use a similar test when deciding when to execute _PSx. Or, you could simply be conservative and only do it for PATA. outside of those issues, the rest of the patch looks ok. - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]libata-acpi: add ACPI _PSx method
Shaohua Li wrote: ACPI spec (ver 3.0a, p289) requires IDE power on/off executes ACPI _PSx methods. As recently most PATA drivers use libata, this patch adds _PSx method support in libata. ACPI spec doesn't mention if SATA requires the same _PSx method, but executing _PSx for SATA should be ok I think. Signed-off-by: Shaohua Li <[EMAIL PROTECTED]> Where/how can a need for this change be produced? Jeff - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
Linus Torvalds wrote: On Thu, 26 Jul 2007, [EMAIL PROTECTED] wrote: how about the fact that Linus found the problem becouse his system didn't work right? No, it works, it just forces me to use a configuration that I'm not personally interested in on that particular machine. I tend to like using minimal kernels. I don't use modules on most of my machines, and I actually look over my config. Maybe I'm odd. But I think it's a good thing to let people decide what they want (and what they do _not_ want) in their kernels. I think forcing people to use CPU_HOTPLUG is a mistake. There's a reason that existed as a config option. The ACPI changes basically mean that the whole CPU_HOTPLUG config option is totally pointless, because everybody is forced to have it. Indeed -- forced to have a feature that is applicable in reality to 0.0001% of the user population, I'd wager :) I read and hone my .config to utter minimalist perfection too :) So count my vote here too, for -not- wanting CPU_HOTPLUG dead code in my kernel. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pci-ids: add Lenovo PCI vendor ID
Henrique de Moraes Holschuh wrote: thinkpad-acpi wants to differentiate IBM from Lenovo ThinkPads, and the PCI IDs are the best way to go about it for quirk tables and so on. Add the missing Lenovo PCI ID to pci_ids.h. Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]> Cc: Jeff Garzik <[EMAIL PROTECTED]> --- include/linux/pci_ids.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index 5b1c999..b5f54ca 100644 --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -2067,6 +2067,8 @@ #define PCI_DEVICE_ID_ALTIMA_AC91000x03ea #define PCI_DEVICE_ID_ALTIMA_AC10030x03eb +#define PCI_VENDOR_ID_LENOVO 0x17aa + #define PCI_VENDOR_ID_ARECA0x17d3 #define PCI_DEVICE_ID_ARECA_1110 0x1110 Not sure why I'm CC'd :) But of course I have an opinion :) Usually we don't add these IDs until a driver is actually using them. Just add it in the patch that starts using it in thinkpad-acpi. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/9] libata-acpi: implement ata_acpi_associate()
Tejun Heo wrote: * Add acpi_handle to ata_host and ata_port. Rename ata_device->obj_handle to ->acpi_handle and move it above such that it doesn't get cleared on reconfiguration. * Replace ACPI node association which ata_acpi_associate() which is called once during host initialization. Unlike the previous implementation, ata_acpi_associate() uses ATA_FLAG_ACPI_SATA to choose between IDE or SATA ACPI hierarchy and uses simple child look up instead of recursive walk to match the nodes. This is way safer and simpler. Please read the following message for more info. http://article.gmane.org/gmane.linux.ide/17554 Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> --- drivers/ata/libata-acpi.c | 369 ++--- drivers/ata/libata-core.c |3 + drivers/ata/libata.h |2 + include/linux/libata.h| 13 +- 4 files changed, 63 insertions(+), 324 deletions(-) applied 4-9 to #upstream - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9] libata: separate out ata_dev_reread_id()
Tejun Heo wrote: Separate out ata_dev_reread_id() from ata_dev_revalidate(). ata_dev_reread_id() reads IDENTIFY page and determines whether the same device is still there. ata_dev_revalidate() reconfigures after reread completes. This will be used by ACPI update. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> --- drivers/ata/libata-core.c | 47 drivers/ata/libata.h |3 +- 2 files changed, 36 insertions(+), 14 deletions(-) applied 1-3 to #upstream-fixes - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/11] libata-acpi: s/CONFIG_SATA_ACPI/CONFIG_ATA_ACPI/
Tejun Heo wrote: ACPI applies to both SATA and PATA. Drop the 'S' from the config variable. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> --- drivers/ata/Kconfig| 26 +- drivers/ata/Makefile |2 +- drivers/ata/libata.h |2 +- include/linux/libata.h |2 +- 4 files changed, 16 insertions(+), 16 deletions(-) applied 3-4 the code has been stirred, so I request resend of the other patches - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/13] libata-acpi: clean up parameters and misc stuff
Tejun Heo wrote: Jeff Garzik wrote: Tejun Heo wrote: This patch cleans up libata-acpi such that it looks similar to other libata files. This patch doesn't introuce any behavior changes. * make libata-acpi functions take ata_device instead of ata_port + device index * s/atadev/adev/ * de-indent local variable declarations I prefer 'dev' over 'adev', unless that makes the code in question more ambiguous. Alan is preferring adev over dev and I thought that might be better in the spirit of 'ap'. I don't really care about the naming tho. Will convert to dev. It won't increase ambiguity. Cool. You will see 'dev' used universally in the code I wrote. It also matches well with "ata_dev_" prefixes, which are a bit better than "ata_adev_" prefix if one were to apply the alternate policy. Yes, I sometimes spend way too much time pay attention to trivialities :) Jeff - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/13] libata: reimplement ACPI invocation
patches 11-13 seem sane My general feeling is * Alan's comments to most of the patches seemed to be on target * I hate ACPI, and am terribly pleased you are working on this. Thanks. You will find you have much latitude in this area. - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/13] libata-acpi: clean up ata_acpi_exec_tfs()
Tejun Heo wrote: This patch cleans up ata_acpi_exec_tfs() and its friends. * Rename taskfile_array to ata_acpi_gtf and make it __packed as it's used as argument to ACPI method, and use pointer to ata_acpi_gtf and number of taskfiles to represent _GTF taskfiles instead of a pointer casted into unsigned long and byte count. This makes argument re-checking in do_drive_set_taskfiles() unnecessary. * Pointer in void * not in unsigned long. * Clean up do_drive_get_GTF() error handling and make do_drive_get_GTF() return number of taskfiles on success, 0 if _GTF doesn't exist or doesn't contain valid ata. -errno on other errors. * Remove superflous check for acpi->buffer.pointer. * Update taskfile_load_raw() such that printed messages look similar to the messages printed by ata_eh_report(). Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> --- drivers/ata/libata-acpi.c | 219 ++--- 1 files changed, 107 insertions(+), 112 deletions(-) ACK As an aside, I hate the "do_" prefix on functions. It is utterly redundant. - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/13] libata-acpi: miscellaneous cleanups
Tejun Heo wrote: * Add missing LOCKING: and RETURNS: to function comment. * Don't conditionalize warning messages with ata_msg_probe(). Print directly with KERN_WARNING. * Drop duplicate debug messages. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> --- drivers/ata/libata-acpi.c | 51 1 files changed, 23 insertions(+), 28 deletions(-) ACK - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/13] libata-acpi: implement ata_acpi_associate()
Tejun Heo wrote: * Add acpi_handle to ata_host and ata_port. Rename ata_device->obj_handle to ->acpi_handle and move it above such that it doesn't get cleared on reconfiguration. * Replace ACPI node association which ata_acpi_associate() which is called once during host initialization. Unlike the previous implementation, ata_acpi_associate() uses ATA_FLAG_ACPI_SATA to choose between IDE or SATA ACPI hierarchy and uses simple child look up instead of recursive walk to match the nodes. This is way safer and simpler. Please read the following message for more info. http://article.gmane.org/gmane.linux.ide/17554 Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> --- drivers/ata/libata-acpi.c | 369 ++--- drivers/ata/libata-core.c |3 + drivers/ata/libata.h |2 + include/linux/libata.h| 13 +- 4 files changed, 63 insertions(+), 324 deletions(-) largely dependent on previous patch's comments - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/13] libata-acpi: add ATA_FLAG_ACPI_SATA port flag
Tejun Heo wrote: Whether a controller needs IDE or SATA ACPI hierarchy is determined by the programming interface of the controller not by whether the controller is SATA or PATA, or it supports slave device or not. This patch adds ATA_FLAG_ACPI_SATA port flags which tells libata-acpi that the port needs SATA ACPI nodes, and sets the flag for ahci and sata_sil24. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> --- drivers/ata/ahci.c|3 ++- drivers/ata/libata-acpi.c | 10 +- drivers/ata/sata_sil24.c |3 ++- include/linux/libata.h|1 + 4 files changed, 10 insertions(+), 7 deletions(-) I don't think the situation is as static as a compiled-in driver flag implies. And I'm not really convinced a driver flag is needed, or wanted. If anything, the only flag we /may/ need could be a ATA_FLAG_NEVER_EVER_DO_ACPI_FOR_THIS_CONTROLLER. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/13] libata-acpi: clean up parameters and misc stuff
Tejun Heo wrote: This patch cleans up libata-acpi such that it looks similar to other libata files. This patch doesn't introuce any behavior changes. * make libata-acpi functions take ata_device instead of ata_port + device index * s/atadev/adev/ * de-indent local variable declarations I prefer 'dev' over 'adev', unless that makes the code in question more ambiguous. Otherwise, ACK - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/13] libata-acpi: s/CONFIG_SATA_ACPI/CONFIG_ATA_ACPI/
Tejun Heo wrote: ACPI applies to both SATA and PATA. Drop the 'S' from the config variable. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> --- drivers/ata/Kconfig| 26 +- drivers/ata/Makefile |2 +- drivers/ata/libata.h |2 +- include/linux/libata.h |2 +- 4 files changed, 16 insertions(+), 16 deletions(-) ACK patches 4-5 - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/13] libata: separate out ata_dev_reread_id()
Tejun Heo wrote: Separate out ata_dev_reread_id() from ata_dev_revalidate(). ata_dev_reread_id() reads IDENTIFY page and determines whether the same device is still there. ata_dev_revalidate() reconfigures after reread completes. This will be used by ACPI update. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> --- drivers/ata/libata-core.c | 47 drivers/ata/libata.h |3 +- 2 files changed, 36 insertions(+), 14 deletions(-) ACK, though I think you'll have to rediff due to a Mark Lord patch - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/13] ahci: consolidate common port flags
Tejun Heo wrote: Consolidate common port flags into AHCI_FLAG_COMMON. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> --- drivers/ata/ahci.c | 29 ++--- 1 files changed, 10 insertions(+), 19 deletions(-) applied patches 1-2 - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [1/2] 2.6.21-rc7: known regressions
Dave Jones wrote: On Mon, Apr 16, 2007 at 05:14:40PM -0700, Brandeburg, Jesse wrote: > Adrian Bunk wrote: > > Subject: laptops with e1000: lockups > > References : > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603 > > Submitter : Dave Jones <[EMAIL PROTECTED]> > > Handled-By : Jesse Brandeburg <[EMAIL PROTECTED]> > > Status : problem is being debugged > > this is being actively debugged, here is what we have so far: > o v2.6.20: crashes during boot, unless noacpi and nousb bootparams used > o v2.6.21-rc6: some userspace issue, crashes just after root mount > without init=/bin/bash > o v2.6.2X: serial console in docking station spews goo at all speeds > with console=ttyS0,n8 . work continues on this, as we don't know if > there are kernel panic messages during the hard lock. > o fedora 7 test kernel 2948: boots okay, have been using this as only > truly working kernel on this machine. > > one reproduction of the problem was had with scp -l 5000 > when linked at 100Mb/Full. Tried probably 20 other times same test with > no repro, ugh. > > Otherwise, slogging through continues. We are actively working on this > in case it *is* an e1000 issue. Right now the repro is so unlikely we > could hardly tell if we fixed it. FWIW, I can reproduce this pretty much ondemand, on 100M through the ethernet port on a netgear wireless AP. A number of our Fedora7 testers are also able to easily reproduce this. To isolate e1000, for tomorrows test build I've reverted e1000 to the same code that was in 2.6.20. If that works out without causing hangs, I'll try and narrow down further which of the dozen csets is responsible. Also, there are e1000 fixes in -mm. At the time (rc2? rc3?) I felt it was best to get that into -mm for testing, rather than fast-tracking it to 2.6.21. But hey, see if they help. It's the netdev-2.6.git#e1000-fixes branch, if you are git-ified. I was going to push them first thing 2.6.22. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regarding ACPI support in 2.6.21
Alan Cox wrote: I think it might be better to give up ACPI support in 2.6.21 and target 2.6.22. What do you think? I removed it from my tree already so that I can actually use libata and do real work. The "crash every non PCI controller" feature in the current ACPI hacks means PCMCIA and ISAPnP do not work any more with libata. It sounds like your tree is out-of-date. Your patch to fix that went in days ago, applied by Linus directly: commit ca4266359d0c1199af088447f209ab5bcc32a989 Author: Alan Cox <[EMAIL PROTECTED]> Date: Thu Mar 8 23:13:50 2007 + [PATCH] libata-acpi: Try and stop all the non PCI devices crashing In its current state it should be disabled, its broken, its wrong. Does the above change your opinion any? I lean towards disabling it by default in 2.6.21 anyway, but am interested in hearing an updated opinion on what's actually in the public tree. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [3/6] 2.6.21-rc2: known regressions
Adrian Bunk wrote: Subject: NCQ problem with ahci and Hitachi drive References : http://lkml.org/lkml/2007/3/4/178 Submitter : Mathieu Bérard <[EMAIL PROTECTED]> Status : unknown according to the last message in that thread, it sounds like ACPI and interrupt problems Subject: SATA_ACPI errors during kernel boot References : http://bugzilla.kernel.org/show_bug.cgi?id=8080 http://bugzilla.kernel.org/show_bug.cgi?id=8046 http://bugzilla.kernel.org/show_bug.cgi?id=8095 http://lkml.org/lkml/2007/2/22/159 Submitter : Janosch Machowinski <[EMAIL PROTECTED]> Lukas Hejtmanek <[EMAIL PROTECTED]> Meelis Roos <[EMAIL PROTECTED]> Olivier Mondoloni <[EMAIL PROTECTED]> Handled-By : Thomas Renninger <[EMAIL PROTECTED]> Tejun Heo <[EMAIL PROTECTED]> Robert Moore <[EMAIL PROTECTED]> Status : problem is being debugged Note that there WILL be an increase in ACPI diagnostic output. The key difference is whether the users are seeing scary printks, or whether the boot is actually breaking. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2/6] 2.6.21-rc2: known regressions
Adrian Bunk wrote: Subject: AT keyboard only works with pci=noacpi References : http://lkml.org/lkml/2007/3/3/68 Submitter : Ash Milsted <[EMAIL PROTECTED]> Status : unknown sounds like a BIOS bug, even though it appears to be a regression? - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 11/12] Fix up a multitude of ACPI compiler warnings on x86_64
[EMAIL PROTECTED] wrote: From: Martin Bligh <[EMAIL PROTECTED]> 32bit vs 64 bit issues. sizeof(sizeof) and sizeof(pointer) is variable, but we're trying to shove it into unsigned int or u32. Casts to unsigned long are used because type acpi_thread_id can be any one of typedef u64 acpi_native_uint; typedef u32 acpi_native_uint; typedef u16 acpi_native_uint; #define acpi_thread_id struct task_struct * Signed-off-by: Martin J. Bligh <[EMAIL PROTECTED]> Cc: "Brown, Len" <[EMAIL PROTECTED]> Cc: Jeff Garzik <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- drivers/acpi/executer/exmutex.c |6 +++--- drivers/acpi/utilities/utdebug.c |5 +++-- drivers/acpi/utilities/utmutex.c | 16 +--- 3 files changed, 15 insertions(+), 12 deletions(-) ACK - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-rc5-mm1
Jeremy Fitzhardinge wrote: Greg KH wrote: Yes, try reverting them and see if your machine works again. Reverting them makes the machine work, with basically the same effect as disabling CONFIG_PCI_MSI: no MSI interrupts appear in /proc/interrupts, and e1000 & libata are using IO-APIC-fasteoi. So, a reasonable result for now. Did you re-enable CONFIG_PCI_MSI, after reverting the patches? Jeff -- VGER BF report: H 0 - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-rc1-mm1
Alan Cox wrote: The old drivers/ide code uses much longer delays than the spec for some ATAPI commands, and it looks as if there is a good reason for doing so ... FWIW, the code that ATADRVR (http://www.ata-atapi.com/) uses to issue commands does something like write Command register to start command if (device == ATAPI)# i.e. not ATA delay(150 msec) pound Status / AltStatus, kick DMA engine, whatever else ATADRVR is open code (for an MS-DOS-level driver), and really worth a read. Between ATADRVR and drivers/ide, you get a pretty good idea about what __field experience__ has shown is needed for ATAPI devices. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/25] irq: Add a dynamic irq creation API
Benjamin Herrenschmidt wrote: I have neither b) nor c) nowadays on powerpc "linux" irq numbers are purely a virtual thing, that is an index in irq_desc array and something we give to drivers to do request_irq() from. They can map onto hw interrupts, MSI-like messages, environment interrupts, could be hypervisor messgaes, in fact, it could be anything that remotely looks like an interrupt and the concept of "hw vector" is very blurry here... every interrupt controller defines it's own hardware vector space. On pSeries, hardware vectors are fairly big numbers that can encode the geographical location of the slot where the device is connected to, on some other hypervisor, they are 64 bits "tokens" representing an hypervisor object that can send events, etc etc Indeed... The return value from return_irq() is purely a cookie, and has been for quite some time. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/25] msi: Make the msi boolean tests return either 0 or 1.
Eric W. Biederman wrote: This allows the output of the msi tests to be stored directly in a bit field. If you don't do this a value greater than one will be truncated and become 0. Changing true to false with bizare consequences. Another example of why bit fields are a pain in the butt... Jeff - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.16-rc5: known regressions
Adrian Bunk wrote: Subject: 2.6.16-rc[34]: resume-from-RAM unreliable (SATA) References : http://lkml.org/lkml/2006/2/20/159 Submitter : Mark Lord <[EMAIL PROTECTED]> Handled-By : Randy Dunlap <[EMAIL PROTECTED]> Status : one of Randy's patches seems to fix it This is not a regression, libata suspend/resume has always been crappy. It's under active development (by Randy, among others) to fix this. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 2.6.16-rc3
Andrew Morton wrote: - http://bugzilla.kernel.org/show_bug.cgi?id=5914 - a sata bug (which is quite unremarkable :(), but this one is reported to eat filesystems. Issue closed, as the bug notes... Jeff - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Re: [linux-usb-devel] Re: 2.6.15-mm3 [USB lost interrupt bug]
On the libata side of things, does this patch produce any useful results?
Jeff
diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
index 46c4cdb..4691f8d 100644
--- a/drivers/scsi/libata-core.c
+++ b/drivers/scsi/libata-core.c
@@ -4794,7 +4794,14 @@ ata_pci_init_native_mode(struct pci_dev
pci_resource_start(pdev, 1) | ATA_PCI_CTL_OFS;
probe_ent->port[p].bmdma_addr = pci_resource_start(pdev, 4);
ata_std_ports(&probe_ent->port[p]);
- p++;
+
+ if (pci_resource_start(pdev, 0) &&
+ pci_resource_len(pdev, 0) &&
+ pci_resource_start(pdev, 1) &&
+ pci_resource_len(pdev, 1) &&
+ pci_resource_start(pdev, 4) &&
+ pci_resource_len(pdev, 4))
+ p++;
}
if (ports & ATA_PORT_SECONDARY) {
@@ -4804,10 +4811,23 @@ ata_pci_init_native_mode(struct pci_dev
pci_resource_start(pdev, 3) | ATA_PCI_CTL_OFS;
probe_ent->port[p].bmdma_addr = pci_resource_start(pdev, 4) + 8;
ata_std_ports(&probe_ent->port[p]);
- p++;
+
+ if (pci_resource_start(pdev, 2) &&
+ pci_resource_len(pdev, 2) &&
+ pci_resource_start(pdev, 3) &&
+ pci_resource_len(pdev, 3) &&
+ pci_resource_start(pdev, 4) &&
+ pci_resource_len(pdev, 4) > 8)
+ p++;
}
probe_ent->n_ports = p;
+
+ if (p == 0) {
+ kfree(probe_ent);
+ probe_ent = NULL;
+ }
+
return probe_ent;
}
@@ -4815,6 +4835,10 @@ static struct ata_probe_ent *ata_pci_ini
{
struct ata_probe_ent *probe_ent;
+ if (!pci_resource_start(pdev, 4) ||
+ !pci_resource_len(pdev, 4))
+ return NULL;
+
probe_ent = ata_probe_ent_alloc(pci_dev_to_dev(pdev), port);
if (!probe_ent)
return NULL;
