all agree the update is needed.
I think this original patch still applies cleanly on at least 2.6.23-rc7.
Drain up to 512 words from host/bridge FIFO on stuck DRQ HSM violation,
rather than just getting stuck there forever.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
---
--- old/drivers/ata/libata
We need to disable all CPUs other than the boot CPU (usually 0)
before attempting to power-off modern SMP machines.
This seems to fix the hang-on-poweroff issue
that one of my SMP boxes exhibits. More testing required.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
---
--- linux/kernel/sys.c.orig
Mark Lord wrote:
We need to disable all CPUs other than the boot CPU (usually 0)
before attempting to power-off modern SMP machines.
This seems to fix the hang-on-poweroff issue
that one of my SMP boxes exhibits. More testing required.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
---
--- linux
Rafael J. Wysocki wrote:
On Friday, 28 September 2007 06:57, Len Brown wrote:
On Thursday 27 September 2007 18:00, Rafael J. Wysocki wrote:
On Thursday, 27 September 2007 23:29, Mark Lord wrote:
Question: do we disable all CPUs except 0 when doing ACPI power off?
No, but we should.
We used
is the revised patch.
* * *
We need to disable all CPUs other than the boot CPU (usually 0)
before attempting to power-off modern SMP machines.
This fixes the hang-on-poweroff issue on my MythTV SMP box,
and also on Thomas Gleixner's new toybox.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
Acked
Linus Torvalds wrote:
On Sat, 22 Sep 2007, Thomas Gleixner wrote:
My final enlightment was, when I removed the ACPI processor module,
which controls the lower idle C-states, right before resume; this
worked fine all the time even without all the workaround hacks.
I really hope that this two
Thomas Gleixner wrote:
On Fri, 2007-09-28 at 16:27 -0400, Mark Lord wrote:
..
On a closely related note: I just now submitted a patch to fix SMP-poweroff,
by having it do disable_nonboot_cpus before doing poweroff.
Which has led me to thinking..
..are similar precautions perhaps necessary
there forever.
Signed-Off-By: Mark Lord <[EMAIL PROTECTED]>
---
--- old/drivers/ata/libata-sff.c2007-04-26 12:02:46.0 -0400
+++ linux/drivers/ata/libata-sff.c 2007-04-29 08:29:27.0 -0400
@@ -413,6 +413,24 @@
ap->ops->irq_on(ap);
}
+static void ata_drain_
Tejun Heo wrote:
Alan Cox wrote:
I think there have been enough cases where this draining was necessary.
IIRC, ata_piix was involved in those cases, right? If so, can you
please submit a patch which applies this only to affected controllers?
I don't feel too confident about applying this to
Rafael J. Wysocki wrote:
On Thursday, 27 September 2007 23:29, Mark Lord wrote:
Question: do we disable all CPUs except 0 when doing ACPI power off?
No, but we should.
Background:
I have a machine here dedicated to running MythTV.
It powers up to record, and then sets the RTC alarm
Mark Lord wrote:
Question: do we disable all CPUs except 0 when doing ACPI power off?
Background:
I have a machine here dedicated to running MythTV.
It powers up to record, and then sets the RTC alarm for next time
and powers down again in between recordings.
It has an Intel Core2duo E6300
Question: do we disable all CPUs except 0 when doing ACPI power off?
Background:
I have a machine here dedicated to running MythTV.
It powers up to record, and then sets the RTC alarm for next time
and powers down again in between recordings.
It has an Intel Core2duo E6300 CPU, currently on an
Question: do we disable all CPUs except 0 when doing ACPI power off?
Background:
I have a machine here dedicated to running MythTV.
It powers up to record, and then sets the RTC alarm for next time
and powers down again in between recordings.
It has an Intel Core2duo E6300 CPU, currently on an
Mark Lord wrote:
Question: do we disable all CPUs except 0 when doing ACPI power off?
Background:
I have a machine here dedicated to running MythTV.
It powers up to record, and then sets the RTC alarm for next time
and powers down again in between recordings.
It has an Intel Core2duo E6300
Rafael J. Wysocki wrote:
On Thursday, 27 September 2007 23:29, Mark Lord wrote:
Question: do we disable all CPUs except 0 when doing ACPI power off?
No, but we should.
Background:
I have a machine here dedicated to running MythTV.
It powers up to record, and then sets the RTC alarm
Tejun Heo wrote:
Alan Cox wrote:
I think there have been enough cases where this draining was necessary.
IIRC, ata_piix was involved in those cases, right? If so, can you
please submit a patch which applies this only to affected controllers?
I don't feel too confident about applying this to
there forever.
Signed-Off-By: Mark Lord [EMAIL PROTECTED]
---
--- old/drivers/ata/libata-sff.c2007-04-26 12:02:46.0 -0400
+++ linux/drivers/ata/libata-sff.c 2007-04-29 08:29:27.0 -0400
@@ -413,6 +413,24 @@
ap-ops-irq_on(ap);
}
+static void ata_drain_fifo (struct
Linus Torvalds wrote:
On Fri, 14 Sep 2007, Adrian Bunk wrote:
E.g. when looking at the reverse dependencies of libhal, it would not be
funny if kernel 2.6.43 required a more recent version of HAL.
Adrian, what's the point of answering your questions, WHEN YOU DON'T EVEN
READ THE ANSWERS!
Linus Torvalds wrote:
On Fri, 14 Sep 2007, Adrian Bunk wrote:
E.g. when looking at the reverse dependencies of libhal, it would not be
funny if kernel 2.6.43 required a more recent version of HAL.
Adrian, what's the point of answering your questions, WHEN YOU DON'T EVEN
READ THE ANSWERS!
Alan Stern wrote:
On Thu, 13 Sep 2007, Mark Lord wrote:
..
What happens is, there's a nice little LED on the Cruzer stick,
that is "lit" when the stick itself is not in a "power suspend" state
(or whatever you USB folks call it).
We call it "suspended". (Wasn
Alan Stern wrote:
On Wed, 12 Sep 2007, Mark Lord wrote:
Chuck Ebbert wrote:
..
Oh, nice. The usb-storage (SCSI) disk spins itself down and we can't handle
that.
Should we be disabling auto-spindown when we connect the device, or be able to
handle this by sending the start command when
Greg KH wrote:
On Wed, Sep 12, 2007 at 10:50:26PM -0400, Mark Lord wrote:
Michal Piotrowski wrote:
Hi all,
Here is a list of some known regressions in 2.6.23-rc6.
...
Missing from the list:
USB "autosuspend" feature (new in 2.6.23) breaks *lots* of devices.
Many have since been b
Greg KH wrote:
On Wed, Sep 12, 2007 at 10:50:26PM -0400, Mark Lord wrote:
Michal Piotrowski wrote:
Hi all,
Here is a list of some known regressions in 2.6.23-rc6.
...
Missing from the list:
USB autosuspend feature (new in 2.6.23) breaks *lots* of devices.
Many have since been blacklisted
Alan Stern wrote:
On Wed, 12 Sep 2007, Mark Lord wrote:
Chuck Ebbert wrote:
..
Oh, nice. The usb-storage (SCSI) disk spins itself down and we can't handle
that.
Should we be disabling auto-spindown when we connect the device, or be able to
handle this by sending the start command when
Alan Stern wrote:
On Thu, 13 Sep 2007, Mark Lord wrote:
..
What happens is, there's a nice little LED on the Cruzer stick,
that is lit when the stick itself is not in a power suspend state
(or whatever you USB folks call it).
We call it suspended. (Wasn't there an episode of Classic Trek
Michal Piotrowski wrote:
Hi all,
Here is a list of some known regressions in 2.6.23-rc6.
...
Missing from the list:
USB "autosuspend" feature (new in 2.6.23) breaks *lots* of devices.
Many have since been blacklisted in one-at-a-time discovery patches,
but that's really just the tip of the
reverting the changed
functionality, or by changing the code to default OFF.
Here's my patch for 2.6.23-rc6+ :
Fix USB Storage failures.
Signed-Off-By: Mark Lord <[EMAIL PROTECTED]>
---
--- linux/drivers/usb/storage/usb.c.orig2007-09-11 11:52:14.0
-0400
+++ linux/drive
Greg KH wrote:
On Wed, Sep 12, 2007 at 06:14:04PM -0400, Mark Lord wrote:
Oliver Neukum wrote:
Am Dienstag 14 August 2007 schrieb Paolo Ornati:
On Tue, 14 Aug 2007 17:46:16 +0200
Oliver Neukum <[EMAIL PROTECTED]> wrote:
Am Dienstag 14 August 2007 schrieb Paolo Ornati:
Hewlett-P
Mark Lord wrote:
Dan Zwell wrote:
Alan Stern wrote:
[ 126.512815] usb 1-1: usb auto-resume
[ 126.543447] uhci_hcd :00:1f.2: port 1 portsc 00a5,01
[ 126.559426] usb 1-1: finish resume
[ 126.561435] usb 1-1: gone after usb resume? status -19
[ 126.561445] usb 1-1: can't resume, status
Dan Zwell wrote:
Alan Stern wrote:
[ 126.512815] usb 1-1: usb auto-resume
[ 126.543447] uhci_hcd :00:1f.2: port 1 portsc 00a5,01
[ 126.559426] usb 1-1: finish resume
[ 126.561435] usb 1-1: gone after usb resume? status -19
[ 126.561445] usb 1-1: can't resume, status -19
[ 126.561451]
Oliver Neukum wrote:
Am Dienstag 14 August 2007 schrieb Paolo Ornati:
On Tue, 14 Aug 2007 17:46:16 +0200
Oliver Neukum <[EMAIL PROTECTED]> wrote:
Am Dienstag 14 August 2007 schrieb Paolo Ornati:
Hewlett-Packard PhotoSmart 720 / PhotoSmart 935 (storage)
Please try this patch.
Tried on -rc3
Chuck Ebbert wrote:
On 08/13/2007 10:50 AM, Niels wrote:
On Sunday 12 August 2007 11:54, Niels wrote:
On Friday 10 August 2007 14:43, Niels wrote:
On Wednesday 08 August 2007 12:57, Ismail Dönmez wrote:
On Wednesday 08 August 2007 13:48:29 you wrote:
On Tuesday 07 August 2007 23:18,
Chuck Ebbert wrote:
On 08/13/2007 10:50 AM, Niels wrote:
On Sunday 12 August 2007 11:54, Niels wrote:
On Friday 10 August 2007 14:43, Niels wrote:
On Wednesday 08 August 2007 12:57, Ismail Dönmez wrote:
On Wednesday 08 August 2007 13:48:29 you wrote:
On Tuesday 07 August 2007 23:18,
Oliver Neukum wrote:
Am Dienstag 14 August 2007 schrieb Paolo Ornati:
On Tue, 14 Aug 2007 17:46:16 +0200
Oliver Neukum [EMAIL PROTECTED] wrote:
Am Dienstag 14 August 2007 schrieb Paolo Ornati:
Hewlett-Packard PhotoSmart 720 / PhotoSmart 935 (storage)
Please try this patch.
Tried on -rc3
Dan Zwell wrote:
Alan Stern wrote:
[ 126.512815] usb 1-1: usb auto-resume
[ 126.543447] uhci_hcd :00:1f.2: port 1 portsc 00a5,01
[ 126.559426] usb 1-1: finish resume
[ 126.561435] usb 1-1: gone after usb resume? status -19
[ 126.561445] usb 1-1: can't resume, status -19
[ 126.561451]
Mark Lord wrote:
Dan Zwell wrote:
Alan Stern wrote:
[ 126.512815] usb 1-1: usb auto-resume
[ 126.543447] uhci_hcd :00:1f.2: port 1 portsc 00a5,01
[ 126.559426] usb 1-1: finish resume
[ 126.561435] usb 1-1: gone after usb resume? status -19
[ 126.561445] usb 1-1: can't resume, status
Greg KH wrote:
On Wed, Sep 12, 2007 at 06:14:04PM -0400, Mark Lord wrote:
Oliver Neukum wrote:
Am Dienstag 14 August 2007 schrieb Paolo Ornati:
On Tue, 14 Aug 2007 17:46:16 +0200
Oliver Neukum [EMAIL PROTECTED] wrote:
Am Dienstag 14 August 2007 schrieb Paolo Ornati:
Hewlett-Packard
reverting the changed
functionality, or by changing the code to default OFF.
Here's my patch for 2.6.23-rc6+ :
Fix USB Storage failures.
Signed-Off-By: Mark Lord [EMAIL PROTECTED]
---
--- linux/drivers/usb/storage/usb.c.orig2007-09-11 11:52:14.0
-0400
+++ linux/drivers/usb
Michal Piotrowski wrote:
Hi all,
Here is a list of some known regressions in 2.6.23-rc6.
...
Missing from the list:
USB autosuspend feature (new in 2.6.23) breaks *lots* of devices.
Many have since been blacklisted in one-at-a-time discovery patches,
but that's really just the tip of the
Jeff Garzik wrote:
Mark Lord wrote:
Ditto for selecting transfer modes.
Waiting on one thing AFAICS:
ability to drain/idle all ports +
issue a command on one port +
resume normal parallel port operation
SET FEATURES - XFER MODE is special in that it requires all sorts
Jeff Garzik wrote:
Mark Lord wrote:
Ditto for selecting transfer modes.
Waiting on one thing AFAICS:
ability to drain/idle all ports +
issue a command on one port +
resume normal parallel port operation
SET FEATURES - XFER MODE is special in that it requires all sorts
Tejun Heo wrote:
Hello,
Mark Lord wrote:
I reported a very similar bug back a few releases ago.
Anyone who wants to try it themselves, can do this with hdparm-7.7 (from
sourceforge):
hdparm --drq-hsm-error /dev/sda
Whether or not it hangs the machine does depend upon exactly which SATA
Tejun Heo wrote:
Hello,
Mark Lord wrote:
I reported a very similar bug back a few releases ago.
Anyone who wants to try it themselves, can do this with hdparm-7.7 (from
sourceforge):
hdparm --drq-hsm-error /dev/sda
Whether or not it hangs the machine does depend upon exactly which SATA
Alan Cox wrote:
On Tue, 4 Sep 2007 13:37:22 +0100
"Daniel J Blueman" <[EMAIL PROTECTED]> wrote:
We see that in ata_piix.c, there is a whitelist for (laptop) Intel ICH
controllers with short cables, tied to specific vendor subsystem IDs.
Since my mini-ITX Ibase MI910F has the subsystem IDs
Andrew Morton wrote:
..
Hey, we just found something which doesn't crash my Vaio!
sony:/home/akpm/hdparm-7.7> 0 ./hdparm --drq-hsm-error /dev/sda
/dev/sda:
triggering "stuck DRQ" host state machine error
do_drq_hsm_error: Success
ata status=0x58 ata error=0x00
ata3.00: exception Emask 0x0
Andrew Morton wrote:
On Mon, 03 Sep 2007 17:53:00 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote:
Michal Piotrowski wrote:
Hi,
[Adding linux-ide to CC]
On 25/08/07, Bryan Woods <[EMAIL PROTECTED]> wrote:
Hi KML
I am installing gentoo 2007.0 (kernel 2.6.19) on a dual AMD Opteron server (total of
Andrew Morton wrote:
On Mon, 03 Sep 2007 17:53:00 +0900 Tejun Heo [EMAIL PROTECTED] wrote:
Michal Piotrowski wrote:
Hi,
[Adding linux-ide to CC]
On 25/08/07, Bryan Woods [EMAIL PROTECTED] wrote:
Hi KML
I am installing gentoo 2007.0 (kernel 2.6.19) on a dual AMD Opteron server (total of 4
Andrew Morton wrote:
..
Hey, we just found something which doesn't crash my Vaio!
sony:/home/akpm/hdparm-7.7 0 ./hdparm --drq-hsm-error /dev/sda
/dev/sda:
triggering stuck DRQ host state machine error
do_drq_hsm_error: Success
ata status=0x58 ata error=0x00
ata3.00: exception Emask 0x0 SAct
Maciek Rutecki wrote:
Kernel: 2.6.23-rc2 witch patches [1], but older and stable versions also
..
Sometimes (one in ten, or rarely) I have this error while system resume
from suspend to disk:
..
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: irq_stat 0x4001
ata1.00:
Maciek Rutecki wrote:
Kernel: 2.6.23-rc2 witch patches [1], but older and stable versions also
..
Sometimes (one in ten, or rarely) I have this error while system resume
from suspend to disk:
..
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: irq_stat 0x4001
ata1.00:
Rene Herman wrote:
..
No, as far as reported into this thread, it's all been PS/2. We can
leave this thread be though. It's nothing to do with CFS and is a
non-debuggable problem sofar unfortunately. Although very present at the
start of this thread, I haven't experienced my stuck delete key
Brian J. Murrell wrote:
I am using Ubuntu Gutsy, which is the in-development branch heading for
their next stable release.
I have noticed that since some kernel release post-2.6.20 I have been
unable to mount my /boot partition:
$ sudo strace -f mount /dev/hda1 /mnt/foo
execve("/bin/mount",
Brian J. Murrell wrote:
I am using Ubuntu Gutsy, which is the in-development branch heading for
their next stable release.
I have noticed that since some kernel release post-2.6.20 I have been
unable to mount my /boot partition:
$ sudo strace -f mount /dev/hda1 /mnt/foo
execve(/bin/mount,
Rene Herman wrote:
..
No, as far as reported into this thread, it's all been PS/2. We can
leave this thread be though. It's nothing to do with CFS and is a
non-debuggable problem sofar unfortunately. Although very present at the
start of this thread, I haven't experienced my stuck delete key
Tejun Heo wrote:
Mark Lord wrote:
Further to this, if I have an active-writer running at the time of suspend,
then even my scripted "sleep 1" is not good enough, as additional writes
are still happening before/after the flush.
Now I'll reboot and try it with the "sleep 1&qu
Mark Lord wrote:
My suspend script now has this little chunk of code at the point
where it actually does the suspend-to-RAM:
sync; sync
hdparm -F /dev/sda ## flush drive write cache
sleep 1 ## allow time for the flush to complete
echo mem > /sys/power/st
Mark Lord wrote:
Tejun Heo wrote:
Mark Lord wrote:
..
FWIW, Tejun, with 2.6.22, my new Seagate 160GB SATA drive (notebook)
increments the "Power-Off_Retract_Count" on each suspend-to-RAM operation.
It does not do any double spin-up/spin-down things though.
Hmmm.. It shouldn't.
libata to ignore errors after spinup
This patch is to ignore errors from the spinup attempt if the drive is
in the "standby id" state.
Signed-off-by: Ryan Power <[EMAIL PROTECTED]>
Acked-by: Mark Lord <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Cc: Tejun
Tejun Heo wrote:
Mark Lord wrote:
> Tejun Heo wrote:
>> Michael Sedkowski wrote:
>>> Dnia 07-08-2007, Wt o godzinie 03:43 +0900, Tejun Heo napisał(a):
>>>> Does emergency unload count increase
>>>> after each power down?
>>> I think I g
Tejun Heo wrote:
Michael Sedkowski wrote:
Dnia 07-08-2007, Wt o godzinie 03:43 +0900, Tejun Heo napisał(a):
Does emergency unload count increase
after each power down?
I think I got it.
Using smartctl I've done a test and shut down, then repeted the test.
The only values that where diffrent
Tejun Heo wrote:
Michael Sedkowski wrote:
Dnia 07-08-2007, Wt o godzinie 03:43 +0900, Tejun Heo napisał(a):
Does emergency unload count increase
after each power down?
I think I got it.
Using smartctl I've done a test and shut down, then repeted the test.
The only values that where diffrent
Tejun Heo wrote:
Mark Lord wrote:
Tejun Heo wrote:
Michael Sedkowski wrote:
Dnia 07-08-2007, Wt o godzinie 03:43 +0900, Tejun Heo napisał(a):
Does emergency unload count increase
after each power down?
I think I got it.
Using smartctl I've done a test and shut down, then repeted
to ignore errors after spinup
This patch is to ignore errors from the spinup attempt if the drive is
in the standby id state.
Signed-off-by: Ryan Power [EMAIL PROTECTED]
Acked-by: Mark Lord [EMAIL PROTECTED]
Cc: Jeff Garzik [EMAIL PROTECTED]
Cc: Tejun Heo [EMAIL PROTECTED]
Signed-off-by: Andrew
Mark Lord wrote:
Tejun Heo wrote:
Mark Lord wrote:
..
FWIW, Tejun, with 2.6.22, my new Seagate 160GB SATA drive (notebook)
increments the Power-Off_Retract_Count on each suspend-to-RAM operation.
It does not do any double spin-up/spin-down things though.
Hmmm.. It shouldn't. libata now
Mark Lord wrote:
My suspend script now has this little chunk of code at the point
where it actually does the suspend-to-RAM:
sync; sync
hdparm -F /dev/sda ## flush drive write cache
sleep 1 ## allow time for the flush to complete
echo mem /sys/power/state
Tejun Heo wrote:
Mark Lord wrote:
Further to this, if I have an active-writer running at the time of suspend,
then even my scripted sleep 1 is not good enough, as additional writes
are still happening before/after the flush.
Now I'll reboot and try it with the sleep 1 hardcoded inside
Daniel J Blueman wrote:
On 02/08/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
Daniel J Blueman wrote:
I'll grab kernel logs from the legacy ATA boot; what else can help
debug this issue? No problem testing patches too.
Yeap, please post the old log.
Not much actually - perhaps I need to enable
Robert Hancock wrote:
Mark Lord wrote:
I don't believe the speed of the machine has much to do with it,
as IDE PIO is always at pretty much the same speed (or slower)
regardless of the CPU speed.
Best case is about .120 usec per 16-bit word, but that doesn't often
pan out
in practice. More
Robert Hancock wrote:
David Miller wrote:
From: Arjan van de Ven <[EMAIL PROTECTED]>
Date: Fri, 27 Jul 2007 13:11:56 -0700
On Thu, 2007-07-26 at 16:17 -0700, Linus Torvalds wrote:
On Thu, 26 Jul 2007, Linus Torvalds wrote:
(c) "one IRQF_DISABLED means that everything runs disabled". This
Maciej W. Rozycki wrote:
On Sat, 28 Jul 2007, Russell King wrote:
Essentially, any complex interrupt handler (such as an IDE interrupt
doing a multi-sector PIO transfer _in interrupt context_) can cause this
kind of starvation. That's why Linux 1.x had bottom halves - so that
the time
Jeff Garzik wrote:
This is just a refresh of the existing libata-dev.git#new-eh patches
that convert all remaining old-EH drivers to new EH, against 2.6.23-rc1.
All three conversions are completely untested. pdc_adma and sata_qstor
need reviewing by someone with docs, in addition to testing.
Jeff Garzik wrote:
This is just a refresh of the existing libata-dev.git#new-eh patches
that convert all remaining old-EH drivers to new EH, against 2.6.23-rc1.
All three conversions are completely untested. pdc_adma and sata_qstor
need reviewing by someone with docs, in addition to testing.
Maciej W. Rozycki wrote:
On Sat, 28 Jul 2007, Russell King wrote:
Essentially, any complex interrupt handler (such as an IDE interrupt
doing a multi-sector PIO transfer _in interrupt context_) can cause this
kind of starvation. That's why Linux 1.x had bottom halves - so that
the time
Robert Hancock wrote:
David Miller wrote:
From: Arjan van de Ven [EMAIL PROTECTED]
Date: Fri, 27 Jul 2007 13:11:56 -0700
On Thu, 2007-07-26 at 16:17 -0700, Linus Torvalds wrote:
On Thu, 26 Jul 2007, Linus Torvalds wrote:
(c) one IRQF_DISABLED means that everything runs disabled. This
is
Robert Hancock wrote:
Mark Lord wrote:
I don't believe the speed of the machine has much to do with it,
as IDE PIO is always at pretty much the same speed (or slower)
regardless of the CPU speed.
Best case is about .120 usec per 16-bit word, but that doesn't often
pan out
in practice. More
Daniel J Blueman wrote:
On 02/08/07, Tejun Heo [EMAIL PROTECTED] wrote:
Daniel J Blueman wrote:
I'll grab kernel logs from the legacy ATA boot; what else can help
debug this issue? No problem testing patches too.
Yeap, please post the old log.
Not much actually - perhaps I need to enable
Mark Lord wrote:
Ryan Power wrote:
From: Ryan Power <[EMAIL PROTECTED]>
Adjust libata to ignore errors after spinup
This patch is to ignore errors from the spinup attempt if the drive is
in the "standby id" state.
Jeff / Tejun: here is Ryan's patch for his WD drive
Mark Lord wrote:
Ryan Power wrote:
From: Ryan Power <[EMAIL PROTECTED]>
Adjust libata to ignore errors after spinup
This patch is to ignore errors from the spinup attempt if the drive is
in the "standby id" state.
Jeff / Tejun: here is Ryan's patch for his WD drive
s.
This copy has the pathnames and whitespace repaired.
Signed-off-by: Ryan Power <[EMAIL PROTECTED]>
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
Index: linux/drivers/ata/libata-core.c
--- old/drivers/ata/libata-core.c 2007-07-10 12:56:30.0 -0600
+++ linux/drivers/ata/libata-c
and whitespace repaired.
Signed-off-by: Ryan Power [EMAIL PROTECTED]
Signed-off-by: Mark Lord [EMAIL PROTECTED]
---
Index: linux/drivers/ata/libata-core.c
--- old/drivers/ata/libata-core.c 2007-07-10 12:56:30.0 -0600
+++ linux/drivers/ata/libata-core.c 2007-07-15 01:58:49.0
Mark Lord wrote:
Ryan Power wrote:
From: Ryan Power [EMAIL PROTECTED]
Adjust libata to ignore errors after spinup
This patch is to ignore errors from the spinup attempt if the drive is
in the standby id state.
Jeff / Tejun: here is Ryan's patch for his WD drive spinup problems.
This copy
Mark Lord wrote:
Ryan Power wrote:
From: Ryan Power [EMAIL PROTECTED]
Adjust libata to ignore errors after spinup
This patch is to ignore errors from the spinup attempt if the drive is
in the standby id state.
Jeff / Tejun: here is Ryan's patch for his WD drive spinup problems.
This copy
Mark Lord wrote:
Sergei Shtylyov wrote:
Mark Lord wrote:
..
When a drive is in standby, we don't send it anything special to wake
up.
Wait, aren't we sending IDLE on resume step 2 -- looking at
ide-io.cide_start_power_step()?
Sure, for RESUME.
But now for a drive that just happens
Sergei Shtylyov wrote:
Mark Lord wrote:
..
I would guess simply because DMA has to transfer up to 256 sectors of
data,
possibly with sector reallocations, in addition to waiting for the drive
to spin up. Other commands don't.
What?! PIO commands don't have to do this as well
Sergei Shtylyov wrote:
Mark Lord wrote:
..
When a drive is in standby, we don't send it anything special to wake up.
Wait, aren't we sending IDLE on resume step 2 -- looking at
ide-io.cide_start_power_step()?
Sure, for RESUME.
But now for a drive that just happens to have put itself
Sergei Shtylyov wrote:
Mark Lord wrote:
The original question concerned specifically the DMA command
timeout which is twice more than the usual one, WAIT_CMD (10 seconds).
..
When a drive is in standby, we don't send it anything special to wake up.
So even DMA commands have to have a long
Sergei Shtylyov wrote:
Mark Lord wrote:
O> >>BTW, why the timeout is so damn long? 2*WAIT_CMD is 20 secs,
and if DMA is not complete or interrupt pending, it may wait 10 more secs...
..
I've lost the original question from this thread, but the idea of the
The original
Alan Cox wrote:
O> >>BTW, why the timeout is so damn long? 2*WAIT_CMD is 20 secs, and if DMA is
not complete or interrupt pending, it may wait 10 more secs...
I really don't remember... :)
Maybe Mark or Alan could help with figuring this out.
They also have probably forgotten. :-)
:
Original Message
Subject: [BUG] 2.6.21: Kernel won't boot with either/both of CONFIG_NO_HZ,
CONFIG_HIGH_RES_TIMERS
Date: Mon, 30 Apr 2007 16:17:00 -0400
From: Mark Lord <[EMAIL PROTECTED]>
To: Linux Kernel , [EMAIL PROTECTED]
CC: Linus Torvalds <[EMAIL PROTECTED]>
Ingo Freund wrote:
Hi
I've got a RAID5 (driver aacraid for an ICP9047MA) with four
750GB hdds which provides a 2.25TB sized device.
None of the until now used tools will work with that device.
fdisk complains about missing cylinder count.
cfdisk misses the device size.
parted shows the right
Ingo Freund wrote:
Hi
I've got a RAID5 (driver aacraid for an ICP9047MA) with four
750GB hdds which provides a 2.25TB sized device.
None of the until now used tools will work with that device.
fdisk complains about missing cylinder count.
cfdisk misses the device size.
parted shows the right
:
Original Message
Subject: [BUG] 2.6.21: Kernel won't boot with either/both of CONFIG_NO_HZ,
CONFIG_HIGH_RES_TIMERS
Date: Mon, 30 Apr 2007 16:17:00 -0400
From: Mark Lord [EMAIL PROTECTED]
To: Linux Kernel linux-kernel@vger.kernel.org, [EMAIL PROTECTED]
CC: Linus Torvalds [EMAIL
Alan Cox wrote:
O BTW, why the timeout is so damn long? 2*WAIT_CMD is 20 secs, and if DMA is
not complete or interrupt pending, it may wait 10 more secs...
I really don't remember... :)
Maybe Mark or Alan could help with figuring this out.
They also have probably forgotten. :-)
Sergei Shtylyov wrote:
Mark Lord wrote:
O BTW, why the timeout is so damn long? 2*WAIT_CMD is 20 secs,
and if DMA is not complete or interrupt pending, it may wait 10 more secs...
..
I've lost the original question from this thread, but the idea of the
The original question
Sergei Shtylyov wrote:
Mark Lord wrote:
The original question concerned specifically the DMA command
timeout which is twice more than the usual one, WAIT_CMD (10 seconds).
..
When a drive is in standby, we don't send it anything special to wake up.
So even DMA commands have to have a long
Sergei Shtylyov wrote:
Mark Lord wrote:
..
When a drive is in standby, we don't send it anything special to wake up.
Wait, aren't we sending IDLE on resume step 2 -- looking at
ide-io.cide_start_power_step()?
Sure, for RESUME.
But now for a drive that just happens to have put itself
Sergei Shtylyov wrote:
Mark Lord wrote:
..
I would guess simply because DMA has to transfer up to 256 sectors of
data,
possibly with sector reallocations, in addition to waiting for the drive
to spin up. Other commands don't.
What?! PIO commands don't have to do this as well? :-)
Other
Mark Lord wrote:
Sergei Shtylyov wrote:
Mark Lord wrote:
..
When a drive is in standby, we don't send it anything special to wake
up.
Wait, aren't we sending IDLE on resume step 2 -- looking at
ide-io.cide_start_power_step()?
Sure, for RESUME.
But now for a drive that just happens
Jeremy Maitin-Shepard wrote:
A typical usage pattern of hibernate on a laptop is to shut the lid,
causing the system to start to hibernate, and to place the machine in
All laptops we have here, and those of all people I have seen
with laptops, do suspend-to-RAM on lid-close, not hibernate.
Mark Lord wrote:
Rafael J. Wysocki wrote:
..
How much RAM is there in your machine?
2GB, but It doesn't need to dump that much for good performance.
Hibernate here consists of:
echo "$(( 256 * 1024 * 1024 ))" > /sys/power/image_size
echo -n disk > /sys/power/stat
901 - 1000 of 1516 matches
Mail list logo
