Hello, ATA and ACPI crowd.
This mail tries to summarize the current state of libata ACPI support
and establish consensus how it should be improved. If you're familiar
with ACPI or the current libata-acpi implementation, please try to
answer questions in section 3.
Table of Contents
1.
This disables libata ACPI, among other things.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ahci.c | 21 +++-
drivers/ata/libata-acpi.c
Jeff Garzik wrote:
This disables libata ACPI, among other things.
If a -rc6 is possible, that would be quite nice...
Jeff
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Tue, 2007-03-27 at 01:46 +0800, Jeff Chua wrote:
On 3/27/07, Thomas Gleixner [EMAIL PROTECTED] wrote:
It's related. I tested without CONFIG_HPET_TIMER, and now my X60 can
suspend and resume from RAM (s2ram). Even better, it works
with/without CONFIG_NO_HZ.
Does the patch below
On Wed, 28 Mar 2007 01:08:52 +0100
Matthew Garrett [EMAIL PROTECTED] wrote:
On Fri, Mar 23, 2007 at 07:13:21PM +, Alan Cox wrote:
For reference this is what I am currently using with 2.6.21-rc4-mm1 and
it is working for all my test cases so far: Its basically Kyle's patch
with a libata
Hi!
So if you have reported a regression in the 2.6.21-rc
series, please check 2.6.21-rc5, and update your
report as appropriate (whether fixed or still
problems with xyzzy).
[just got back from vacation, or would have sent this
earlier]
FWIW, I'm still leaning towards disabling
Pavel Machek wrote:
Hi!
So if you have reported a regression in the 2.6.21-rc
series, please check 2.6.21-rc5, and update your
report as appropriate (whether fixed or still
problems with xyzzy).
[just got back from vacation, or would have sent this
earlier]
FWIW, I'm still leaning
Tejun Heo htejun at gmail.com writes:
Sigmund Scheinbar wrote:
Tejun Heo wrote:
Please apply the attached patch over 2.6.20.1 and report how it works.
I'm afraid that something went wrong while patching:
Sorry, it was generated against the wrong tree. Regenerated patch attached.
On Wednesday 28 March 2007 09:04:28 Thomas Gleixner wrote:
On Tue, 2007-03-27 at 01:46 +0800, Jeff Chua wrote:
On 3/27/07, Thomas Gleixner [EMAIL PROTECTED] wrote:
It's related. I tested without CONFIG_HPET_TIMER, and now my X60 can
suspend and resume from RAM (s2ram). Even better,
Get rid of the 'pio_speed' member of 'ide_drive_t' that was only used by this
driver by storing the PIO mode timings in the 'drive_data' instead -- this
allows us to greatly simplify the process of reloading of the chip's timing
register and do it right in sl82c150_dma_off_quietly() and to get
On Wed, Mar 28, 2007 at 04:30:02PM +0900, Tejun Heo wrote:
Hi Tejun,
Firstly, could I ask you to take a look at the patch in
http://permalink.gmane.org/gmane.linux.acpi.devel/22066/ ? It deals with
some of these issues.
ACPI support implementation in libata-dev supports both IDE and SATA
Hello, I wrote:
Index: linux-2.6/include/linux/ide.h
===
--- linux-2.6.orig/include/linux/ide.h
+++ linux-2.6/include/linux/ide.h
@@ -613,7 +613,6 @@ typedef struct ide_drive_s {
u8 quirk_list; /* considered quirky, set
Fold the now equivalent code in the ide_dma_check() method into a mere call to
ide_use_dma(). Make config_for_dma() return non-zero if DMA mode has been set
and call it from the ide_dma_check() method instead of ide_dma_on().
Defer writing the DMA timings to the chip registers until DMA is really
Add the speedproc() method for setting transfer modes, modify config_for_dma()
to call it and use ide_max_dma_mode() to select the best DMA mode.
Add support for the multiword DMA modes 0 and 1, using the upper half of the
'drive_data' field to store the DMA timings to program into the drive
On Sunday 25 March 2007 19:27, Rüdiger Otte wrote:
Dear Linux ATA people,
the SATA-Controller on Asus A8V-MX mainboard (VIA VT8251) doesn't
recognize an attached SATA-Harddisk (Western Digital WD3200AAKS in
my case) with kernels 2.6.19 and above. I get the error with 2.6.19,
2.6.20 and
Phillip Susi wrote:
Justin Piszcz wrote:
I would try with write-caching enabled.
Also, the RAID5/RAID10 you mention seems like each volume is on part of
the platter, a strange setup you got there :)
Shouldn't NCQ only help write performance if write caching is
_disabled_? Since write cache
Justin Piszcz wrote:
I would try with write-caching enabled.
Also, the RAID5/RAID10 you mention seems like each volume is on part of
the platter, a strange setup you got there :)
Shouldn't NCQ only help write performance if write caching is
_disabled_? Since write cache essentially is just
Le 27.03.2007 03:59, Adrian Bunk a écrit :
This email lists some known regressions in Linus' tree compared to 2.6.20.
...
Subject: libata: PATA UDMA/100 configured as UDMA/33
References : http://lkml.org/lkml/2007/2/20/294
On Wed, Mar 28, 2007 at 10:57:54AM +0100, Alan Cox wrote:
Ok thanks. This is interesting as the only thing new it is doing is
asking for the HPA size. Does I think explain the problem however: Can
you move the HPA setting call to after the mode has been set and see if
that makes the problem
Hm. I tried adding it in the eh code after ata_set_mode() in
ata_eh_recover(), which alters the problem slightly - hpa_sectors is
still 0, so the taskfile call is still failing, but now the system just
stops at around the time that anything attempts to access sda with no
errors other than
On Wed, 28 Mar 2007, Jeff Garzik wrote:
Jeff Garzik wrote:
This disables libata ACPI, among other things.
If a -rc6 is possible, that would be quite nice...
Heh. I don't think -rc6 is possible - it's inevitable. We have too
much fallout from the timer changes still outstanding. It looks
On Wed, 28 Mar 2007 13:53:10 -0700 (PDT)
Linus Torvalds [EMAIL PROTECTED] wrote:
On Wed, 28 Mar 2007, Jeff Garzik wrote:
Jeff Garzik wrote:
This disables libata ACPI, among other things.
If a -rc6 is possible, that would be quite nice...
Heh. I don't think -rc6 is possible -
On Wed, Mar 28, 2007 at 10:54:31PM +0100, Alan Cox wrote:
Hm. I tried adding it in the eh code after ata_set_mode() in
ata_eh_recover(), which alters the problem slightly - hpa_sectors is
still 0, so the taskfile call is still failing, but now the system just
stops at around the time
This patch series implements Asynchronous Notification (AN) for SATA ATAPI
devices as defined in SATA 2.5 and AHCI 1.1. Drives which support this
feature will send a notification when new media is inserted into the
drive, preventing the need for user space to poll for new media. This
support is
Allow user space to determine if an ATAPI device supports
async notification (AN) of media changes. This is done by
adding a new sysfs file async_notification to genhd.
If the file reads 1, then the device supports async
notification. If the file reads 0, it does not.
A flag is set in the
Check to see if an ATAPI device supports Asynchronous Notification.
If so, enable it.
Signed-off-by: Kristen Carlson Accardi [EMAIL PROTECTED]
Index: 2.6-mm/drivers/ata/libata-core.c
===
--- 2.6-mm.orig/drivers/ata/libata-core.c
+++
When we get an SDB FIS with the 'N' bit set, we should send
an event to user space to indicate that there has been a
media change. The ahci host controller will send the
event via KOBJ_CHANGE uevent.
Signed-off-by: Kristen Carlson Accardi [EMAIL PROTECTED]
Index: 2.6-mm/drivers/ata/ahci.c
Kristen Carlson Accardi wrote:
Allow user space to determine if an ATAPI device supports
async notification (AN) of media changes. This is done by
adding a new sysfs file async_notification to genhd.
If the file reads 1, then the device supports async
notification. If the file reads 0, it
* Maxim [EMAIL PROTECTED] wrote:
I almost sure I know why this happens,
cool! Your patch is a definite improvement on my t60 (where
suspend/resume never worked with hpet enabled). But it does not fix
everything - for example the timings are way off after resume. Thomas?
Ingo
-
To
On Wed, 28 Mar 2007, Maxim wrote:
Now I don't have a clue how to set those bits if only HPET is used as
clock source because now clocksources
don't have _any_ resume hook.
One thing that drives me wild about that clocksource resume thing is
that it seems to think that
Subject: first disk access after resume takes several minutes
('date' does not advance after resume from RAM, CONFIG_NO_HZ=n)
References : http://lkml.org/lkml/2007/3/8/117
http://lkml.org/lkml/2007/3/25/20
Submitter : Michael S. Tsirkin [EMAIL PROTECTED]
...
* Michael S. Tsirkin [EMAIL PROTECTED] wrote:
Bingo!
The patch below fixes the two problems (listed above) with resume from
RAM that I have observed on my T60 with 2.6.21-rc5: with this patch
applied, and with CONFIG_NO_HZ unset, date advances correctly, X
functions properly and there
On Wed, 28 Mar 2007 20:04:57 +0200 Michael S. Tsirkin wrote:
Subject: first disk access after resume takes several minutes
('date' does not advance after resume from RAM, CONFIG_NO_HZ=n)
References : http://lkml.org/lkml/2007/3/8/117
On Wednesday 28 March 2007 9:38 am, Linus Torvalds wrote:
It's a *device*, dammit. It should save and resume like one (probably as a
system device). The set_mode() etc stuff is at a completely different
(higher) conceptual level.
Agreed, except about probably as a system device.
Last I
On Wednesday 28 March 2007 21:38:55 David Brownell wrote:
On Wednesday 28 March 2007 9:38 am, Linus Torvalds wrote:
It's a *device*, dammit. It should save and resume like one (probably as a
system device). The set_mode() etc stuff is at a completely different
(higher) conceptual level.
On Wed, 28 Mar 2007, David Brownell wrote:
On Wednesday 28 March 2007 9:38 am, Linus Torvalds wrote:
It's a *device*, dammit. It should save and resume like one (probably as a
system device). The set_mode() etc stuff is at a completely different
(higher) conceptual level.
Agreed,
On Wednesday 28 March 2007 1:19 pm, Maxim wrote:
On Wednesday 28 March 2007 21:38:55 David Brownell wrote:
Also, making HPET use the legacy mode seems like a step backwards.
It is not 'legacy' mode,
It is a legacy replacement mode.
Typo, sorry.
It this mode HPET takes over IRQ0
On Wednesday 28 March 2007 1:42 pm, Linus Torvalds wrote:
I won't disagree - it might well be much nicer to just show it in the
real device tree. I'm not 100% sure where in the tree it would go,
though. It should probably be inside the root entry, before any of the
PCI buses.
Mixing
On Wednesday 28 March 2007 22:59:26 David Brownell wrote:
On Wednesday 28 March 2007 1:19 pm, Maxim wrote:
On Wednesday 28 March 2007 21:38:55 David Brownell wrote:
Also, making HPET use the legacy mode seems like a step backwards.
It is not 'legacy' mode,
It is a legacy
On Wednesday 28 March 2007 22:42:00 Linus Torvalds wrote:
On Wed, 28 Mar 2007, David Brownell wrote:
On Wednesday 28 March 2007 9:38 am, Linus Torvalds wrote:
It's a *device*, dammit. It should save and resume like one (probably as
a
system device). The set_mode() etc stuff is
The Asus W5F laptop uses a short cable instead of the 80-wire style, and thus
needs to be in the ich_laptop special cases for correct detection and support
of UDMA/100 for the hard drive. I noticed this because I have the W5F laptop,
and was tracing apparent slowness.
Signed-off-by: Robin H.
Hello, Matthew.
Matthew Garrett wrote:
On Wed, Mar 28, 2007 at 04:30:02PM +0900, Tejun Heo wrote:
Hi Tejun,
Firstly, could I ask you to take a look at the patch in
http://permalink.gmane.org/gmane.linux.acpi.devel/22066/ ? It deals with
some of these issues.
Yeap, I've seen the patch.
On Thu, Mar 29, 2007 at 10:42:03AM +0900, Tejun Heo wrote:
Yeap, I think it's in the right direction but we need to go further.
* I'm not sure whether the complex walk libata-acpi is doing is justifiable.
Yeah, that may well be less than ideal.
* You'll end up doing _STM/_GTM on ahci
Kristen Carlson Accardi wrote:
Check to see if an ATAPI device supports Asynchronous Notification.
If so, enable it.
As supporting AN needs host interrupt handler change. I think we need
host-supports-AN flag; otherwise, we might end up with screaming
interrupts in the worst case.
--
Tejun Heo wrote:
Kristen Carlson Accardi wrote:
Check to see if an ATAPI device supports Asynchronous Notification.
If so, enable it.
As supporting AN needs host interrupt handler change. I think we need
host-supports-AN flag; otherwise, we might end up with screaming
interrupts in the
Kristen Carlson Accardi wrote:
Allow user space to determine if an ATAPI device supports
async notification (AN) of media changes. This is done by
adding a new sysfs file async_notification to genhd.
If the file reads 1, then the device supports async
notification. If the file reads 0, it
Jeff Garzik wrote:
Kristen Carlson Accardi wrote:
Allow user space to determine if an ATAPI device supports
async notification (AN) of media changes. This is done by
adding a new sysfs file async_notification to genhd.
If the file reads 1, then the device supports async notification. If
the
Kristen Carlson Accardi wrote:
When we get an SDB FIS with the 'N' bit set, we should send
an event to user space to indicate that there has been a
media change. The ahci host controller will send the
event via KOBJ_CHANGE uevent.
Signed-off-by: Kristen Carlson Accardi [EMAIL PROTECTED]
Tejun Heo wrote:
Jeff Garzik wrote:
Kristen Carlson Accardi wrote:
Allow user space to determine if an ATAPI device supports
async notification (AN) of media changes. This is done by
adding a new sysfs file async_notification to genhd.
If the file reads 1, then the device supports async
Matthew Garrett wrote:
* You'll end up doing _STM/_GTM on ahci controller on some BIOSen - 1.
it can be dangerous 2. you might get partial or incorrect mapping -
think about ICH8-split-to-two-PCI-fn-in-piix-mode case.
So far I haven't seen any DSDTs that include _GTM and _STM methods for
On Wednesday 28 March 2007 18:38:48 Linus Torvalds wrote:
On Wed, 28 Mar 2007, Maxim wrote:
Now I don't have a clue how to set those bits if only HPET is used as
clock source because now clocksources
don't have _any_ resume hook.
One thing that drives me wild about that
On Thu, 29 Mar 2007, Maxim wrote:
I am sending here a patch that as was discussed here adds hpet to list
of system devices
and adds suspend/resume hooks this way.
I tested it and it works fine.
Ok, it certainly looks better, but it *also* looks like it just assumes
the
On Thursday 29 March 2007 07:08:58 Linus Torvalds wrote:
On Thu, 29 Mar 2007, Maxim wrote:
I am sending here a patch that as was discussed here adds hpet to list
of system devices
and adds suspend/resume hooks this way.
I tested it and it works fine.
Ok, it certainly
53 matches
Mail list logo
