Re: [git patches] IDE updates for 2.6.20

2007-02-08 Thread Len Brown
On Wednesday 07 February 2007 13:23, Sergei Shtylyov wrote:
> Hello.
> 
> Alan wrote:
> > On Wed, 07 Feb 2007 19:08:14 +0100
> > Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
> > 
> >>- ACPI support for IDE (has been in SuSE kernels for months)
> >>  (Hannes Reinecke <[EMAIL PROTECTED]>)
> 
> > I can find no public copy of this or discussion of it, please post a
> 
> http://marc.theaimsgroup.com/?l=linux-ide&m=116916643921306
> 
> > reference to the previous discussion or put the ACPI patch somewhere for
> > review first.
> 
> http://kernel.org/pub/linux/kernel/people/bart/pata-2.6/patches/ide-acpi-support.patch

So it looks like...
if (CONFIG_BLK_DEV_IDEACPI=y)
suspend uses _GTM
resume uses _STM

But it looks like _GTF and using the task file is disabled by default,
and needs to be enabled by invoking "ide=acpigtf".  Why is that?

Also, what's the story on ide=acpionboot -- when/why is that expected
to be invoked, and why is it not the default?

thanks,
-Len
-
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: libata-acpi: allow _GTF on SATA, but disable on PATA for now

2007-03-10 Thread Len Brown
On Saturday 10 March 2007 06:30, Jeff Garzik wrote:
> Linux Kernel Mailing List wrote:
> > Gitweb: 
> > http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=df33c77e3981e71afc8727ee5c432ba1a1bba68c
> > Commit: df33c77e3981e71afc8727ee5c432ba1a1bba68c
> > Parent: 908e0a8a265fe8057604a9a30aec3f0be7bb5ebb
> > Author: Kristen Accardi <[EMAIL PROTECTED]>
> > AuthorDate: Fri Mar 9 18:15:33 2007 -0500
> > Committer:  Len Brown <[EMAIL PROTECTED]>
> > CommitDate: Fri Mar 9 18:15:33 2007 -0500
> > 
> > libata-acpi: allow _GTF on SATA, but disable on PATA for now
> > 
> > The ACPI specification states, and BIOS implementations depend on,
> > _STM being called before _GTF.
> > 
> > SATA does this, but PATA does not.  So for now, simply
> > prevent execution of _GTF on PATA devices.  Longer term we
> > should implement ACPI support for PATA devices in libata.
> > 
> > Signed-off-by: Kristen Accardi <[EMAIL PROTECTED]>
> > Signed-off-by: Len Brown <[EMAIL PROTECTED]>
> > ---
> >  drivers/ata/libata-acpi.c |7 +++
> >  1 files changed, 7 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/ata/libata-acpi.c b/drivers/ata/libata-acpi.c
> > index d14a48e..89aaf74 100644
> > --- a/drivers/ata/libata-acpi.c
> > +++ b/drivers/ata/libata-acpi.c
> > @@ -561,6 +561,13 @@ int ata_acpi_exec_tfs(struct ata_port *ap)
> >  
> > if (noacpi)
> > return 0;
> > +   /*
> > +* TBD - implement PATA support.  For now,
> > +* we should not run GTF on PATA devices since some
> > +* PATA require execution of GTM/STM before GTF.
> > +*/
> > +   if (!(ap->cbl == ATA_CBL_SATA))
> > +   return 0;
> >  
> > for (ix = 0; ix < ATA_MAX_DEVICES; ix++) {
> > if (!ata_dev_enabled(&ap->device[ix]))
> 
> Grumble!
> 
> This /really/ should have gone through me and linux-ide first.

Back at you Jeff,
This feature /really/ should have never gone upstream in the first place,
as this failure was reported and isolated to git-libata-all.patch
back in 2.6.20-rc6-mm3:

http://bugzilla.kernel.org/show_bug.cgi?id=7907

It then went on to become the most widely reported "ACPI related"
regression in the 2.6.21-rc series -- for which ACPI gets smeared.
Thank you ATA...

> Alan has been actively working on PATA ACPI, and we have been debugging 
> ACPI issues as well.  PLEASE coordinate with the maintainer, when 
> touching code outside of drivers/acpi!

And PLEASE coordinate with the maintainer when invoking methods
that provoke errors in other sub-systems!

Re: "debugging ACPI issues as well"

What issues?
Why haven't I see any mention of them on linux-acpi?
Coordination and communication is a two-way street, Jeff.

> AFAICS this patch went in with zero appearance on LKML or another 
> related list, until submission.  This is /not/ how we do Linux development.

I proudly take credit+blame for shipping Kristen's patch with no delay.
It did appear on linux-acpi, as do all the patches I ship -- though
I admit it was the same day it went upstream.
I'm sorry I didn't CC linux-ide -- I'll get that part right next time.

However, I believe that late -rc3 is _well_ past the time to be developing
new code real-time in the upstream tree; and is instead time to
shut the damn thing off and set sights on the next release.

If you disagree with me, I'm not going to object
when you send a better fix to Linus for 2.6.21-rc4.

However, I do request that you first either start responding
to bugzilla traffic, or delete your account from bugzilla
so that people don't get the false impression that you're
paying attention.

thanks,
-Len
-
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: Regression between 2.6.20 and 2.6.21-rc1: NCQ problem with ahci and Hitachi drive

2007-03-13 Thread Len Brown

> Yes It works with acpi=off (2.6.21-rc1):
> Please notice that IRQ is changed from 19 with ACPI to 11 without.

Please verify the problem still exists in the latest 2.6.21 git.

If yes, please file a bug here:
http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI

For 2.6.20.stable, please attach
the complete output from dmesg -s64000
output from acpidump
output from lspci -vv
and paste a copy of /proc/interrupts

For 2.6.21.broken, please attach as much
of the dmesg as you can capture, and the /proc/interrupts
if you can get that far.

thanks,
-Len
-
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: Time Problems with 2.6.23-rc1-gf695baf2

2007-07-25 Thread Len Brown
On Wednesday 25 July 2007 07:33, Eric Sesterhenn / Snakebyte wrote:
> * Michal Piotrowski ([EMAIL PROTECTED]) wrote:
> >  On 24/07/07, Eric Sesterhenn / Snakebyte <[EMAIL PROTECTED]> wrote:
> > > see second 13 to 510, after pressing it about ten
> > > times, it continues booting.
> > 
> >  Probing IDE interface...
> > 
> >  [   13.867939] VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on
> >  pci:00:04.1
> >  [   13.868062] ide0: BM-DMA at 0xd800-0xd807, BIOS settings:
> >  hda:DMA, hdb:pio
> >  [   13.868268] ide1: BM-DMA at 0xd808-0xd80f, BIOS settings:
> >  hdc:DMA, hdd:DMA
> >  [   13.868574] Probing IDE interface ide0...
> >  [  387.279576] Clocksource tsc unstable (delta = 370195339890 ns)
> >  [  496.200082] hda: ST340823A, ATA DISK drive
> >  [  510.264511] hda: selected mode 0x44
> >  [  510.264826] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> > 
> >  Could you please try to revert these commits
> > 
> >  commit 4099d14322149c7a467e4997b87be4ba8eb78697
> >  commit 6a824c92db4d606c324272c4eed366fb71672440
> >  commit a5d8c5c834d3cabf4b7b477c3f6ee923c25026fc
> 
> reverting these commits didnt change anything at all,
> booting with acpi=off resolved the issue, so i guess it is
> an acpi problem after all.

Maybe yes, maybe no.

> > > > [   13.506890] ACPI Exception (processor_throttling-0084): 
> > > > AE_NOT_FOUND, Evaluating _PTC [20070126]
> > > > [   13.507101] ACPI Exception (processor_throttling-0147): 
> > > > AE_NOT_FOUND, Evaluating _TSS [20070126]

Note that these are just noise -- new code being verbose when looking for an 
optional feature.

The fact that hitting the power button a bunch of times
to make the system move along suggests some sort of missing interrupt problem --
most likely the timer itself.

[   13.868574] Probing IDE interface ide0...
[  387.279576] Clocksource tsc unstable (delta = 370195339890 ns)

5-minutes -- a long probe:-)

> CONFIG_NO_HZ=y

does CONFIG_NO_HZ=n make a difference?

> CONFIG_HIGH_RES_TIMERS=y

does CONFIG_HIGH_RES_TIMERS=n make a difference?

does "irqpoll" make any difference?
does "notsc" make any difference?
does "idle=poll" make any difference?

cheers,
-Len
-
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] hook ACPI _PSx method to IDE power on/off

2007-08-22 Thread Len Brown
On Saturday 04 August 2007 15:55, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 02 August 2007, Shaohua Li wrote:
> > ACPI spec defines the sequence of IDE power on/off:
> > Powering down:
> > Call _GTM.
> > Power down drive (calls _PS3 method and turns off power planes).
> > Powering up:
> > Power up drive (calls _PS0 method if present and turns on power planes).
> > Call _STM passing info from _GTM (possibly modified), with ID data from
> > each drive.
> > Initialize the channel.
> > May modify the results of _GTF.
> > For each drive:
> > Call _GTF.
> > Execute task file (possibly modified).
> > This patch adds the missed _PS0/_PS3 methods call.
> > 
> > Signed-off-by: Shaohua Li <[EMAIL PROTECTED]>
> 
> applied, thanks
> 
> Len, are you OK with the ACPI part of the patch (below)?

yes.
Acked-by: Len Brown <[EMAIL PROTECTED]>

thanks,
-Len

> > Index: linux/drivers/acpi/bus.c
> > ===
> > --- linux.orig/drivers/acpi/bus.c   2007-08-02 13:35:06.0 +0800
> > +++ linux/drivers/acpi/bus.c2007-08-02 13:56:56.0 +0800
> > @@ -262,10 +262,12 @@ int acpi_bus_set_power(acpi_handle handl
> > printk(KERN_WARNING PREFIX
> >   "Transitioning device [%s] to D%d\n",
> >   device->pnp.bus_id, state);
> > -   else
> > +   else {
> > +   device->power.state = state;
> > ACPI_DEBUG_PRINT((ACPI_DB_INFO,
> >   "Device [%s] transitioned to D%d\n",
> >   device->pnp.bus_id, state));
> > +   }
> >  
> > return result;
> >  }
> -
> 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
> 
-
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: [1/2] 2.6.23-rc3: known regressions with patches

2007-08-31 Thread Len Brown
On Wednesday 29 August 2007 11:28, Michal Piotrowski wrote:

> ACPI
> 
> Subject : the fan doesn't work any more
> References  : http://lkml.org/lkml/2007/8/28/359
> Last known good : ?
> Submitter   : Daniel Ritz <[EMAIL PROTECTED]>
> Caused-By   : Alexey Starikovskiy <[EMAIL PROTECTED]>
>   commit cd8c93a4e04dce8f00d1ef3a476aac8bd65ae40b
> Handled-By  : Alexey Starikovskiy <[EMAIL PROTECTED]>
> Patch   : http://lkml.org/lkml/2007/8/29/15
> Status  : patch was suggested

I believe that this is gone as of 2.6.23-rc4-git3

http://bugzilla.kernel.org/show_bug.cgi?id=8958

thanks,
-Len
-
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: Invalid PnP ACPI reserved MMIO areas on Supermicro boards

2007-10-09 Thread Len Brown
On Tuesday 09 October 2007 20:01, Robert Hancock wrote:
> Some people with certain Supermicro boards (at least the H8DCE, it 
> seems) have reported that the sata_nv driver fails to attach to some of 
> the controllers due to resource conflicts:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=280641
> https://bugzilla.redhat.com/show_bug.cgi?id=313491
> 
> Essentially since about 2.6.22 or so (before which we apparently didn't 
> handle PnpACPI reserved MMIO regions?) we get:

So if you boot with "pnpacpi=off" then the board is happy?

-Len

> pnp: 00:09: iomem range 0xdfefd000-0xdfefd3ff has been reserved
> pnp: 00:09: iomem range 0xdfefe000-0xdfefe3ff has been reserved
> 
> when the CK804 SATA controllers have as their BIOS-assigned resources:
> 
> 80:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller 
> (rev f3) (prog-if 85 [Master SecO PriO])
>   Subsystem: Super Micro Computer Inc Unknown device 1011
>   Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B-
>   Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-  SERR-Interrupt: pin A routed to IRQ 46
>   Region 0: I/O ports at e400 [size=8]
>   Region 1: I/O ports at e000 [size=4]
>   Region 2: I/O ports at dc00 [size=8]
>   Region 3: I/O ports at d800 [size=4]
>   Region 4: I/O ports at d400 [size=16]
>   Region 5: Memory at dfefd000 (32-bit, non-prefetchable)
> 
> and
> 
> 80:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller 
> (rev f3) (prog-if 85 [Master SecO PriO])
>   Subsystem: Super Micro Computer Inc Unknown device 1011
>   Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B-
>   Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-  SERR-Interrupt: pin A routed to IRQ 45
>   Region 0: I/O ports at f800 [size=8]
>   Region 1: I/O ports at f400 [size=4]
>   Region 2: I/O ports at f000 [size=8]
>   Region 3: I/O ports at ec00 [size=4]
>   Region 4: I/O ports at e800 [size=16]
>   Region 5: Memory at dfefe000 (32-bit, non-prefetchable) [size=4K]
> 
> And so of course we get:
> 
> sata_nv :80:07.0: Using ADMA mode
> PCI: Unable to reserve mem region #6:[EMAIL PROTECTED] for device :80:07.0
> ACPI: PCI interrupt for device :80:07.0 disabled
> sata_nv: probe of :80:07.0 failed with error -16
> ACPI: PCI Interrupt Link [LT2E] enabled at IRQ 45
> ACPI: PCI Interrupt :80:08.0[A] -> Link [LT2E] -> GSI 45 (level, 
> low) -> IRQ 45
> sata_nv :80:08.0: Using ADMA mode
> PCI: Unable to reserve mem region #6:[EMAIL PROTECTED] for device :80:08.0
> ACPI: PCI interrupt for device :80:08.0 disabled
> sata_nv: probe of :80:08.0 failed with error -16
> 
> So essentially the BIOS has erroneously reserved the SATA controller's 
> BARs in the ACPI motherboard resources, preventing the driver from 
> attaching to the device.
> 
> Any ideas on what we can do about this?
> 
> -Get Supermicro to fix the BIOS - already tried, it seems
> -System-specific quirk to ignore these resource reservations?
> -Try to move the PCI resources if they conflict with the ACPI resource 
> reservations?
> 
> I wonder how Windows deals with this, if it even does on these boards?
> 
-
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-acpi: add ACPI _PSx method

2007-10-30 Thread Len Brown
It would be interseting if any of the folks having power consumption
problems when suspended see an improvement with this patch.

Are there plans to refresh this patch and get it upstream?

Acked-by: Len Brown <[EMAIL PROTECTED]>

thanks,
-Len

On Thursday 20 September 2007 22:17, Shaohua Li wrote:
> On Fri, 2007-09-21 at 11:20 +0900, Tejun Heo wrote:
> > Hello,
> > 
> > Shaohua Li wrote:
> > > + /* channel first and then drives for power on and verse versa for power 
> > > off */
> > > + if (state.event == PM_EVENT_ON)
> > > + acpi_bus_set_power(ap->acpi_handle, ACPI_STATE_D0);
> > > +
> > > + if (ap->flags & ATA_FLAG_SLAVE_POSS)
> > > + max_devices++;
> > 
> > ata_port_max_devices()?
> ok, fixed.
> > 
> > > Index: linux/drivers/ata/libata-eh.c
> > > ===
> > > --- linux.orig/drivers/ata/libata-eh.c2007-09-14 10:28:25.0 
> > > +0800
> > > +++ linux/drivers/ata/libata-eh.c 2007-09-21 08:56:40.0 +0800
> > > @@ -2349,6 +2349,7 @@ static void ata_eh_handle_port_suspend(s
> > >   if (ap->ops->port_suspend)
> > >   rc = ap->ops->port_suspend(ap, ap->pm_mesg);
> > >  
> > > + ata_acpi_set_state(ap, PMSG_SUSPEND);
> > >   out:
> > >   /* report result */
> > >   spin_lock_irqsave(ap->lock, flags);
> > > @@ -2394,6 +2395,8 @@ static void ata_eh_handle_port_resume(st
> > >  
> > >   WARN_ON(!(ap->pflags & ATA_PFLAG_SUSPENDED));
> > >  
> > > + ata_acpi_set_state(ap, PMSG_ON);
> > > +
> > >   if (ap->ops->port_resume)
> > >   rc = ap->ops->port_resume(ap);
> > 
> > Can these be moved into ata_acpi_on_suspend() and ata_acpi_on_resume()?
> >  Or do they have to be placed on the other side of ->port_suspend/resume
> > callbacks?
> I suppose _PSx will shutdown ports. So I want to do PS3 as later as
> possible in suspend, and vice versa in resume.
> 
> Thanks,
> Shaohua
> 
> 
> ---
>  drivers/ata/libata-acpi.c |   34 ++
>  drivers/ata/libata-eh.c   |3 +++
>  drivers/ata/libata.h  |2 ++
>  3 files changed, 39 insertions(+)
> 
> Index: linux/drivers/ata/libata-acpi.c
> ===
> --- linux.orig/drivers/ata/libata-acpi.c  2007-09-21 09:23:13.0 
> +0800
> +++ linux/drivers/ata/libata-acpi.c   2007-09-21 10:13:32.0 +0800
> @@ -523,6 +523,39 @@ void ata_acpi_on_resume(struct ata_port 
>  }
>  
>  /**
> + * ata_acpi_set_state - set the port power state
> + * @ap: target ATA port
> + * @state: state, on/off
> + *
> + * This function executes the _PS0/_PS3 ACPI method to set the power state.
> + * ACPI spec requires _PS0 when IDE power on and _PS3 when power off
> + */
> +void ata_acpi_set_state(struct ata_port *ap, pm_message_t state)
> +{
> + int max_devices, i;
> +
> + if (!ap->acpi_handle || (ap->flags & ATA_FLAG_ACPI_SATA))
> + return;
> +
> + /* channel first and then drives for power on and verse versa for power 
> off */
> + if (state.event == PM_EVENT_ON)
> + acpi_bus_set_power(ap->acpi_handle, ACPI_STATE_D0);
> +
> + max_devices = ata_port_max_devices(ap);
> +
> + for (i = 0; i < max_devices; ++i) {
> + struct ata_device *dev = &ap->device[i];
> +
> + if (dev->acpi_handle)
> + acpi_bus_set_power(dev->acpi_handle,
> + state.event == PM_EVENT_ON ?
> + ACPI_STATE_D0: ACPI_STATE_D3);
> + }
> + if (state.event != PM_EVENT_ON)
> + acpi_bus_set_power(ap->acpi_handle, ACPI_STATE_D3);
> +}
> +
> +/**
>   * ata_acpi_on_devcfg - ATA ACPI hook called on device donfiguration
>   * @dev: target ATA device
>   *
> Index: linux/drivers/ata/libata-eh.c
> ===
> --- linux.orig/drivers/ata/libata-eh.c2007-09-21 09:23:13.0 
> +0800
> +++ linux/drivers/ata/libata-eh.c 2007-09-21 10:09:10.0 +0800
> @@ -2349,6 +2349,7 @@ static void ata_eh_handle_port_suspend(s
>   if (ap->ops->port_suspend)
>   rc = ap->ops->port_suspend(ap, ap->pm_mesg);
>  
> + ata_acpi_set_state(ap, PMSG_SUSPEND);
>   out:
>   /* report result */
>   spin_lock_irqsave(ap->lock, flags);
> @@ -2394,6 +2395,8 @@ static vo

Re: [Patch]: ACPI : Not register gsi for PCI IDE controller in legacy mode

2008-01-10 Thread Len Brown
Applied to acpi test tree for .25.
Do you think this is .24 and a 23.stable candidate?

thanks,
-Len


On Monday 17 December 2007 02:13, Zhao Yakui wrote:
> Subject: ACPI : Not register gsi for PCI IDE controller in legacy mode
> >From : Alan Cox <[EMAIL PROTECTED]>
> 
> When PCI IDE controller works in legacy mode and no PRT entry is found 
> in ACPI PRT table, OSPM will neither read the irq number from the IDE
> PCI configuration space nor call the function of acpi_register_gsi to
> register gsi.
> 
> http://bugzilla.kernel.org/show_bug.cgi?id=5637
> 
> Signed-off-by: Zhao Yakui <[EMAIL PROTECTED]>
> Signed-off-by: Zhang Rui <[EMAIL PROTECTED]>
> Signed-off-by: Alan Cox  <[EMAIL PROTECTED]>
> 
> ---
>  drivers/acpi/pci_irq.c |9 +
>  1 file changed, 9 insertions(+)
> 
> Index: linux-2.6.24-rc5/drivers/acpi/pci_irq.c
> ===
> --- linux-2.6.24-rc5.orig/drivers/acpi/pci_irq.c
> +++ linux-2.6.24-rc5/drivers/acpi/pci_irq.c
> @@ -429,6 +429,15 @@ int acpi_pci_irq_enable(struct pci_dev *
> &polarity, &link,
> acpi_pci_allocate_irq);
>  
> + if (irq < 0) {
> + /*
> +  * IDE legacy mode controller IRQs are magic. Why do compat
> +  * extensions always make such a nasty mess.
> +  */
> + if (dev->class >> 8 == PCI_CLASS_STORAGE_IDE &&
> + (dev->class & 0x05) == 0)
> + return 0;
> + }
>   /*
>* No IRQ known to the ACPI subsystem - maybe the BIOS / 
>* driver reported one, then use it. Exit in any case.
> 
> 
-
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