Matthew Wilcox wrote:
On Tue, Oct 16, 2007 at 09:54:08PM -0400, Mark Lord wrote:
- t_slot-hpc_ops-get_adapter_status(t_slot, value); /* Check if slot
is occupied */
+ /* Check if slot is occupied */
+ t_slot-hpc_ops-get_adapter_status(t_slot, value);
if ((POWER_CTRL
Matthew Wilcox wrote:
On Wed, Oct 17, 2007 at 09:09:24AM -0400, Mark Lord wrote:
..
- temp_word = (temp_word ~intr_enable) | intr_enable;
+ temp_word = (temp_word ~intr_enable) | intr_enable;
*boggle*
Dig out your text editor, and notice the excess whitespace at the end of the
line
I have a Dell Inspiron 9400 with an external ExpressCard slot.
I've also got a Bytecc 2-port eSATA ExpressCard-34 that identifies as:
Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller (rev 01)
To get it to work with Linux on my Dell notebook,
the pcihp_force=1 parameter is necessary
Make use of the previously split out pcie_init_enable_events() function
to reinitialize the hotplug hardware on resume from suspend,
but only when pciehp_force==1. Otherwise behaviour is unmodified.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
--- old/drivers/pci/hotplug/pciehp_
Fix pciehp_probe() to deal with pre-inserted ExpressCard cards,
but only when pciehp_force==1. Otherwise behaviour is unmodified.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
--- old/drivers/pci/hotplug/pciehp_ctrl.c 2007-10-16 21:14:44.0
-0400
+++ linux/drivers/pci/h
Split out the hotplug hardware initialization code from pcie_init()
into pcie_init_enable_events(), without changing any functionality.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
--- old/drivers/pci/hotplug/pciehp_hpc.c2007-10-16 21:14:44.0
-0400
+++ linux/drive
Whitespace and other cosmetic fixes so that checkpatch.pl
is happy with the remainder of patches in this series.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
--- old/drivers/pci/hotplug/pciehp_core.c 2007-10-12 12:43:44.0
-0400
+++ linux/drivers/pci/hotplug/pciehp_
/pciehp_ctrl.c |2
drivers/pci/hotplug/pciehp_hpc.c | 194
4 files changed, 134 insertions(+), 86 deletions(-)
Cheers
--
Mark Lord <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Greg KH wrote:
On Tue, Oct 16, 2007 at 05:57:03PM -0400, Mark Lord wrote:
Fix PCIe Hotplug so that it works with ExpressCard slots on Dell notebooks
in conjunction with modparam of pciehp_force=1.
The PCIe Hotplug driver has two shortcomings when used on Dell notebooks
which lack ACPI BIOS
Kristen Carlson Accardi wrote:
On Tue, 16 Oct 2007 17:57:03 -0400
Mark Lord <[EMAIL PROTECTED]> wrote:
Fix PCIe Hotplug so that it works with ExpressCard slots on Dell notebooks
in conjunction with modparam of pciehp_force=1.
Please resubmit, breaking this patch into 3 separate pat
Mark Lord wrote:
Rafael J. Wysocki wrote:
On Sunday, 14 October 2007 22:13, Mark Lord wrote:
Since upgrading to 2.6.23.1 from 2.6.23-rc9, resume-from-RAM has been
misbehaving here.
It takes much (+5-7 seconds) longer to resume *sometimes*, but not
all/most of the time.
And sometimes I get
pciehp_core.c | 31 ++--
pciehp_ctrl.c |4 -
pciehp_hpc.c | 207 +-
4 files changed, 144 insertions(+), 101 deletions(-)
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
--- old/drivers/pci/hotplug/pciehp.h2007-10-12
Kristen Carlson Accardi wrote:
On Tue, 16 Oct 2007 14:39:33 -0400
Mark Lord <[EMAIL PROTECTED]> wrote:
Another thing: if a card is already in the slot before pciehp is loaded
(under any circumstances), then pciehp does *not* see the card until I
unplug/replug it.
You mean that the ex
Kristen Carlson Accardi wrote:
...
I tried to reproduce this on a Lenovo T61, which does have proper firmware
support for _OSC, and also has been validated, and the driver which is
in 2.6.23-git8 seems to work fine, even across suspend resume. I suspect
that your system just doesn't support
Mark Lord wrote:
Mark Lord wrote:
Kristen Carlson Accardi wrote:
On Tue, 16 Oct 2007 14:39:33 -0400
Mark Lord <[EMAIL PROTECTED]> wrote:
I also checked my modprobe.d/ options, and I am using pciehp_force=1.
Without that flag, none of this ever works.
OK - I suspected somethin
Mark Lord wrote:
Kristen Carlson Accardi wrote:
On Tue, 16 Oct 2007 14:39:33 -0400
Mark Lord <[EMAIL PROTECTED]> wrote:
I also checked my modprobe.d/ options, and I am using pciehp_force=1.
Without that flag, none of this ever works.
OK - I suspected something like this. Mos
Kristen Carlson Accardi wrote:
On Tue, 16 Oct 2007 14:39:33 -0400
Mark Lord <[EMAIL PROTECTED]> wrote:
I also checked my modprobe.d/ options, and I am using pciehp_force=1.
Without that flag, none of this ever works.
OK - I suspected something like this. Most Dell computers don't s
Mark Lord wrote:
I have a Dell notebook with an PCIe ExpressCard slot.
I also have a PCIe ExpressCard SATA controller (uses sata_sil24 driver).
I would like to be able to hot plug/unplug the controller card at will.
But alas, Linux doesn't cope with it *unless* I boot the kernel with
the card
I have a Dell notebook with an PCIe ExpressCard slot.
I also have a PCIe ExpressCard SATA controller (uses sata_sil24 driver).
I would like to be able to hot plug/unplug the controller card at will.
But alas, Linux doesn't cope with it *unless* I boot the kernel with
the card initially inserted.
I have a Dell notebook with an PCIe ExpressCard slot.
I also have a PCIe ExpressCard SATA controller (uses sata_sil24 driver).
I would like to be able to hot plug/unplug the controller card at will.
But alas, Linux doesn't cope with it *unless* I boot the kernel with
the card initially inserted.
Mark Lord wrote:
I have a Dell notebook with an PCIe ExpressCard slot.
I also have a PCIe ExpressCard SATA controller (uses sata_sil24 driver).
I would like to be able to hot plug/unplug the controller card at will.
But alas, Linux doesn't cope with it *unless* I boot the kernel with
the card
Kristen Carlson Accardi wrote:
On Tue, 16 Oct 2007 14:39:33 -0400
Mark Lord [EMAIL PROTECTED] wrote:
I also checked my modprobe.d/ options, and I am using pciehp_force=1.
Without that flag, none of this ever works.
OK - I suspected something like this. Most Dell computers don't support
Mark Lord wrote:
Kristen Carlson Accardi wrote:
On Tue, 16 Oct 2007 14:39:33 -0400
Mark Lord [EMAIL PROTECTED] wrote:
I also checked my modprobe.d/ options, and I am using pciehp_force=1.
Without that flag, none of this ever works.
OK - I suspected something like this. Most Dell computers
Mark Lord wrote:
Mark Lord wrote:
Kristen Carlson Accardi wrote:
On Tue, 16 Oct 2007 14:39:33 -0400
Mark Lord [EMAIL PROTECTED] wrote:
I also checked my modprobe.d/ options, and I am using pciehp_force=1.
Without that flag, none of this ever works.
OK - I suspected something like
Kristen Carlson Accardi wrote:
...
I tried to reproduce this on a Lenovo T61, which does have proper firmware
support for _OSC, and also has been validated, and the driver which is
in 2.6.23-git8 seems to work fine, even across suspend resume. I suspect
that your system just doesn't support
Kristen Carlson Accardi wrote:
On Tue, 16 Oct 2007 14:39:33 -0400
Mark Lord [EMAIL PROTECTED] wrote:
Another thing: if a card is already in the slot before pciehp is loaded
(under any circumstances), then pciehp does *not* see the card until I
unplug/replug it.
You mean that the existing
pciehp_core.c | 31 ++--
pciehp_ctrl.c |4 -
pciehp_hpc.c | 207 +-
4 files changed, 144 insertions(+), 101 deletions(-)
Signed-off-by: Mark Lord [EMAIL PROTECTED]
---
--- old/drivers/pci/hotplug/pciehp.h2007-10-12 12:43:44.0
Mark Lord wrote:
Rafael J. Wysocki wrote:
On Sunday, 14 October 2007 22:13, Mark Lord wrote:
Since upgrading to 2.6.23.1 from 2.6.23-rc9, resume-from-RAM has been
misbehaving here.
It takes much (+5-7 seconds) longer to resume *sometimes*, but not
all/most of the time.
And sometimes I get
Kristen Carlson Accardi wrote:
On Tue, 16 Oct 2007 17:57:03 -0400
Mark Lord [EMAIL PROTECTED] wrote:
Fix PCIe Hotplug so that it works with ExpressCard slots on Dell notebooks
in conjunction with modparam of pciehp_force=1.
Please resubmit, breaking this patch into 3 separate patches
1
Greg KH wrote:
On Tue, Oct 16, 2007 at 05:57:03PM -0400, Mark Lord wrote:
Fix PCIe Hotplug so that it works with ExpressCard slots on Dell notebooks
in conjunction with modparam of pciehp_force=1.
The PCIe Hotplug driver has two shortcomings when used on Dell notebooks
which lack ACPI BIOS
/pciehp_ctrl.c |2
drivers/pci/hotplug/pciehp_hpc.c | 194
4 files changed, 134 insertions(+), 86 deletions(-)
Cheers
--
Mark Lord [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
Whitespace and other cosmetic fixes so that checkpatch.pl
is happy with the remainder of patches in this series.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
---
--- old/drivers/pci/hotplug/pciehp_core.c 2007-10-12 12:43:44.0
-0400
+++ linux/drivers/pci/hotplug/pciehp_core.c
Fix pciehp_probe() to deal with pre-inserted ExpressCard cards,
but only when pciehp_force==1. Otherwise behaviour is unmodified.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
---
--- old/drivers/pci/hotplug/pciehp_ctrl.c 2007-10-16 21:14:44.0
-0400
+++ linux/drivers/pci/hotplug
Split out the hotplug hardware initialization code from pcie_init()
into pcie_init_enable_events(), without changing any functionality.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
---
--- old/drivers/pci/hotplug/pciehp_hpc.c2007-10-16 21:14:44.0
-0400
+++ linux/drivers/pci
Make use of the previously split out pcie_init_enable_events() function
to reinitialize the hotplug hardware on resume from suspend,
but only when pciehp_force==1. Otherwise behaviour is unmodified.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
---
--- old/drivers/pci/hotplug/pciehp_ctrl.c
1. How are you forcing the drives into standby?
2. Have you reproduced this with a stock kernel.org kernel yet?
One possibility is that these drives may be the kind that
generate a "spurious" interrupt when they spin-down via the timer,
and perhaps libata is "processing" that interrupt and
Rafael J. Wysocki wrote:
On Sunday, 14 October 2007 22:13, Mark Lord wrote:
Since upgrading to 2.6.23.1 from 2.6.23-rc9, resume-from-RAM has been
misbehaving here.
It takes much (+5-7 seconds) longer to resume *sometimes*, but not all/most of
the time.
And sometimes I get get flashing
Since upgrading to 2.6.23.1 from 2.6.23-rc9, resume-from-RAM has been
misbehaving here.
It takes much (+5-7 seconds) longer to resume *sometimes*, but not all/most of
the time.
And sometimes I get get flashing keyboard LEDs and have to hold the power button
in for a full hard reset.
With
Jan Engelhardt wrote:
On Oct 14 2007 09:27, Mark Lord wrote:
Jan-Benedict Glaw wrote:
On Sat, 2007-10-13 22:40:23 +0530, vignesh babu <[EMAIL PROTECTED]>
wrote:
I was surprised and did an ls -l on the files and guess what I found:
total 0
?- ? ? ? ?? f
vignesh babu wrote:
..
?- ? ? ? ?? fcntl.c
?- ? ? ? ?? fifo.c
?- ? ? ? ?? filesystems.c
?- ? ? ? ?? file_table.c
?- ? ? ? ?? freevxfs
So end result is that, Im not able to
Jan-Benedict Glaw wrote:
On Sat, 2007-10-13 22:40:23 +0530, vignesh babu <[EMAIL PROTECTED]> wrote:
I was surprised and did an ls -l on the files and guess what I found:
total 0
?- ? ? ? ?? fcntl.c
?- ? ? ? ?? fifo.c
?- ? ? ? ?
Jan-Benedict Glaw wrote:
On Sat, 2007-10-13 22:40:23 +0530, vignesh babu [EMAIL PROTECTED] wrote:
I was surprised and did an ls -l on the files and guess what I found:
total 0
?- ? ? ? ?? fcntl.c
?- ? ? ? ?? fifo.c
?- ? ? ? ?
vignesh babu wrote:
..
?- ? ? ? ?? fcntl.c
?- ? ? ? ?? fifo.c
?- ? ? ? ?? filesystems.c
?- ? ? ? ?? file_table.c
?- ? ? ? ?? freevxfs
So end result is that, Im not able to
Jan Engelhardt wrote:
On Oct 14 2007 09:27, Mark Lord wrote:
Jan-Benedict Glaw wrote:
On Sat, 2007-10-13 22:40:23 +0530, vignesh babu [EMAIL PROTECTED]
wrote:
I was surprised and did an ls -l on the files and guess what I found:
total 0
?- ? ? ? ?? fcntl.c
Since upgrading to 2.6.23.1 from 2.6.23-rc9, resume-from-RAM has been
misbehaving here.
It takes much (+5-7 seconds) longer to resume *sometimes*, but not all/most of
the time.
And sometimes I get get flashing keyboard LEDs and have to hold the power button
in for a full hard reset.
With
Rafael J. Wysocki wrote:
On Sunday, 14 October 2007 22:13, Mark Lord wrote:
Since upgrading to 2.6.23.1 from 2.6.23-rc9, resume-from-RAM has been
misbehaving here.
It takes much (+5-7 seconds) longer to resume *sometimes*, but not all/most of
the time.
And sometimes I get get flashing
1. How are you forcing the drives into standby?
2. Have you reproduced this with a stock kernel.org kernel yet?
One possibility is that these drives may be the kind that
generate a spurious interrupt when they spin-down via the timer,
and perhaps libata is processing that interrupt and sending
Mark Weber wrote:
Anything else you'd like me to try?
Yes: a stock kernel, please. Preferably 2.6.23.
Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Mark Weber wrote:
Anything else you'd like me to try?
Yes: a stock kernel, please. Preferably 2.6.23.
Thanks.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Mark Weber wrote:
# hdparm -S1 -C /dev/sda; sleep 6; hdparm -C /dev/sda
/dev/sda:
setting standby to 1 (5 seconds)
drive state is: active/idle
/dev/sda:
drive state is: active/idle
That's interesting.
So, either something is regularly accessing/polling the drive,
or it just doesn't
Mark Weber wrote:
# hdparm -S1 -C /dev/sda; sleep 6; hdparm -C /dev/sda
/dev/sda:
setting standby to 1 (5 seconds)
drive state is: active/idle
/dev/sda:
drive state is: active/idle
That's interesting.
So, either something is regularly accessing/polling the drive,
or it just doesn't
Mark Weber wrote:
I can't get "hdparm -S" to work at all.
Using "hdparm -S 1" should set the timeout to
5 seconds, but the drives stay active/idle all the
time. When I set to standby manually, the drives
stay on standby for days, and start up fine when
they are used. I know this because I
Mark Weber wrote:
I can't get hdparm -S to work at all.
Using hdparm -S 1 should set the timeout to
5 seconds, but the drives stay active/idle all the
time. When I set to standby manually, the drives
stay on standby for days, and start up fine when
they are used. I know this because I logged
Eric W. Biederman wrote:
Mark Lord <[EMAIL PROTECTED]> writes:
Comments? Eric?
Sorry -EBUSY.
The trylock on call_lock is a recent thing (.22), added to keep panic
from hanging. It probably makes more sense to move bust_spinlocks(0)
down a few lines in kernel/panic.c and t
(reposting this.. somehow left LKML off the TO/CC list)
Mark Lord wrote:
Eric W. Biederman wrote:
Mark Lord <[EMAIL PROTECTED]> writes:
..
The code path on i386 should be:
machine_power_off
native_machine_power_off
machine_shutdown(); (which disables the othe
Reposting this.. somehow left LKML off the TO/CC list.. (thanks Andrew!)
Eric W. Biederman wrote:
Mark Lord <[EMAIL PROTECTED]> writes:
Eric W. Biederman wrote:
Mark Lord <[EMAIL PROTECTED]> writes:
- It could be that we changed the initialization order.
- It could be tha
Reposting this.. somehow left LKML off the TO/CC list.. (thanks Andrew!)
Eric W. Biederman wrote:
Mark Lord [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Mark Lord [EMAIL PROTECTED] writes:
- It could be that we changed the initialization order.
- It could be that we changed the set
Eric W. Biederman wrote:
Mark Lord [EMAIL PROTECTED] writes:
Comments? Eric?
Sorry -EBUSY.
The trylock on call_lock is a recent thing (.22), added to keep panic
from hanging. It probably makes more sense to move bust_spinlocks(0)
down a few lines in kernel/panic.c and to test
(reposting this.. somehow left LKML off the TO/CC list)
Mark Lord wrote:
Eric W. Biederman wrote:
Mark Lord [EMAIL PROTECTED] writes:
..
The code path on i386 should be:
machine_power_off
native_machine_power_off
machine_shutdown(); (which disables the other cpus
Arjan van de Ven wrote:
On Tue, 02 Oct 2007 18:46:18 -0400
On a related note, {set/get}itimer() currently are buggy (since
2.6.11 or so), also due to this round_jiffies() thing I believe.
I very much believe that it is totally unrelated... most of all since
round_jiffies() wasn't in the
Linus Torvalds wrote:
On Tue, 2 Oct 2007, Andrew Morton wrote:
This is unexpected. High load average is due to either a task chewing a
lot of CPU time or a task stuck in uninterruptible sleep.
Not necessarily.
We saw high loadaverages with the timer bogosity with "gettimeofday()" and
Giuliano Gagliardi wrote:
On Tuesday 02 October 2007, Jan Engelhardt wrote:
On Oct 2 2007 12:56, Giuliano Gagliardi wrote:
I have a server that has to switch to different user ids, but because it
does other complex things, I would rather not have it run as root. I only
need the server to be
Giuliano Gagliardi wrote:
On Tuesday 02 October 2007, Jan Engelhardt wrote:
On Oct 2 2007 12:56, Giuliano Gagliardi wrote:
I have a server that has to switch to different user ids, but because it
does other complex things, I would rather not have it run as root. I only
need the server to be
Linus Torvalds wrote:
On Tue, 2 Oct 2007, Andrew Morton wrote:
This is unexpected. High load average is due to either a task chewing a
lot of CPU time or a task stuck in uninterruptible sleep.
Not necessarily.
We saw high loadaverages with the timer bogosity with gettimeofday() and
Arjan van de Ven wrote:
On Tue, 02 Oct 2007 18:46:18 -0400
On a related note, {set/get}itimer() currently are buggy (since
2.6.11 or so), also due to this round_jiffies() thing I believe.
I very much believe that it is totally unrelated... most of all since
round_jiffies() wasn't in the
Santiago Garcia Mantinan wrote:
So for this to work, I believe that either ACPI or APM has to have been
configured into the kernel (and the modules loaded). Your kernel .config
from earlier shows ACPI built-in to the kernel core, so it should be
present.
Yes, and it is indeed, the acpid is
Jeff Garzik wrote:
Even in libata I have to listen to consensus, having just merged the
port multiplier support.
Jeff
Thanks, Jeff!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Jeff Garzik wrote:
Even in libata I have to listen to consensus, having just merged the
port multiplier support.
Jeff
Thanks, Jeff!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Santiago Garcia Mantinan wrote:
So for this to work, I believe that either ACPI or APM has to have been
configured into the kernel (and the modules loaded). Your kernel .config
from earlier shows ACPI built-in to the kernel core, so it should be
present.
Yes, and it is indeed, the acpid is
Mark Lord wrote:
..
So next is inside the kernel itself, at linux/kernel/sys.c :: sys_reboot(),
where we see this code:
/* Instead of trying to make the power_off code look like
* halt when pm_power_off is not set do it the easy way.
*/
if ((cmd
Santiago Garcia Mantinan wrote:
I booted into single mode, then umounted all unneeded stuff and put / to ro,
stopped all unused raids, ... then did...
..
strace /bin/halt -f -p
..
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
Mark Lord wrote:
Tejun Heo wrote:
Mark Lord wrote:
Tejun Heo wrote:
Mark Lord wrote:
If there was such a bug, the aborted commands list should contain both
FPDMA commands and FLUSH commands. I don't think command filtering
itself is broken. Possibly another quirky firmware but it's strange
Tejun Heo wrote:
Mark Lord wrote:
Tejun Heo wrote:
Mark Lord wrote:
If there was such a bug, the aborted commands list should contain both
FPDMA commands and FLUSH commands. I don't think command filtering
itself is broken. Possibly another quirky firmware but it's strange
Santiago Garcia Mantinan wrote:
I'd say your problem is more of a distro issue,
in that the method you are using to shutdown
is not actually requesting "poweroff".
That last mess above ("System halted.") comes from kernel_halt(),
rather than the expected message ("Power down.") from
Tejun Heo wrote:
Mark Lord wrote:
Jeff Garzik wrote:
Paolo Ornati wrote:
I have this problem only with XFS, and even with XFS it goes away
mounting with "nobarrier"...
This last is an interesting datapoint.
I wonder if libata has a generic problem with NCQ + FLUSH CACHE.
Ye
Erez Zadok wrote:
In message <[EMAIL PROTECTED]>, Linus Torvalds writes:
On Sat, 29 Sep 2007, Erez Zadok wrote:
Would you prefer if CodingStyle was reorganized or even split into (1)
general principles and (2) details? Perhaps we need a CodingStylePrinciples
and a CodingStyleDetails?
I'm
Jeff Garzik wrote:
Paolo Ornati wrote:
On Sun, 30 Sep 2007 15:29:08 +0100
Alan Cox <[EMAIL PROTECTED]> wrote:
Seagate Barracuda ST380817AS has troubles with NCQ. For example,
unpacking a tarball on an XFS filesystem gives this:
ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x2 frozen
Santiago Garcia Mantinan wrote:
Doesn't fix for me!
I have an Athlon x2 running on a Asus A8N-E mobo which has an NForce 4
chipset, I thought this patch would fix poweroff for me too, but it doesn't.
I'm seing this on 2.6.23-rc8 with and without your patch, here is what I get
on the console:
Santiago Garcia Mantinan wrote:
Doesn't fix for me!
I have an Athlon x2 running on a Asus A8N-E mobo which has an NForce 4
chipset, I thought this patch would fix poweroff for me too, but it doesn't.
I'm seing this on 2.6.23-rc8 with and without your patch, here is what I get
on the console:
Jeff Garzik wrote:
Paolo Ornati wrote:
On Sun, 30 Sep 2007 15:29:08 +0100
Alan Cox [EMAIL PROTECTED] wrote:
Seagate Barracuda ST380817AS has troubles with NCQ. For example,
unpacking a tarball on an XFS filesystem gives this:
ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x2 frozen
Erez Zadok wrote:
In message [EMAIL PROTECTED], Linus Torvalds writes:
On Sat, 29 Sep 2007, Erez Zadok wrote:
Would you prefer if CodingStyle was reorganized or even split into (1)
general principles and (2) details? Perhaps we need a CodingStylePrinciples
and a CodingStyleDetails?
I'm
Tejun Heo wrote:
Mark Lord wrote:
Jeff Garzik wrote:
Paolo Ornati wrote:
I have this problem only with XFS, and even with XFS it goes away
mounting with nobarrier...
This last is an interesting datapoint.
I wonder if libata has a generic problem with NCQ + FLUSH CACHE.
Yeah, that's pretty
Santiago Garcia Mantinan wrote:
I'd say your problem is more of a distro issue,
in that the method you are using to shutdown
is not actually requesting poweroff.
That last mess above (System halted.) comes from kernel_halt(),
rather than the expected message (Power down.) from
Tejun Heo wrote:
Mark Lord wrote:
Tejun Heo wrote:
Mark Lord wrote:
If there was such a bug, the aborted commands list should contain both
FPDMA commands and FLUSH commands. I don't think command filtering
itself is broken. Possibly another quirky firmware but it's strange
Mark Lord wrote:
Tejun Heo wrote:
Mark Lord wrote:
Tejun Heo wrote:
Mark Lord wrote:
If there was such a bug, the aborted commands list should contain both
FPDMA commands and FLUSH commands. I don't think command filtering
itself is broken. Possibly another quirky firmware but it's strange
Santiago Garcia Mantinan wrote:
I booted into single mode, then umounted all unneeded stuff and put / to ro,
stopped all unused raids, ... then did...
..
strace /bin/halt -f -p
..
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
Mark Lord wrote:
..
So next is inside the kernel itself, at linux/kernel/sys.c :: sys_reboot(),
where we see this code:
/* Instead of trying to make the power_off code look like
* halt when pm_power_off is not set do it the easy way.
*/
if ((cmd
.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
Acked-by: Thomas Gleixner <[EMAIL PROTECTED]>
---
--- linux/kernel/sys.c.orig 2007-09-13 09:49:11.0 -0400
+++ linux/kernel/sys.c 2007-09-28 15:48:54.0 -0400
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#inclu
Alan Cox wrote:
Why 512 words ?
Though I have queued Mark's patch to be applied, my gut feeling would
lean towards a single DRQ block, rather than 512.
Why not just work from the old IDE code.
ata_altstatus(ap);
- ata_chk_status(ap);
+ ata_drain_fifo(ap, qc);
Alan Cox wrote:
Why 512 words ?
Though I have queued Mark's patch to be applied, my gut feeling would
lean towards a single DRQ block, rather than 512.
Why not just work from the old IDE code.
ata_altstatus(ap);
- ata_chk_status(ap);
+ ata_drain_fifo(ap, qc);
.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
Acked-by: Thomas Gleixner [EMAIL PROTECTED]
---
--- linux/kernel/sys.c.orig 2007-09-13 09:49:11.0 -0400
+++ linux/kernel/sys.c 2007-09-28 15:48:54.0 -0400
@@ -32,6 +32,7 @@
#include linux/getcpu.h
#include linux/task_io_accounting_ops.h
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
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
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]>
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 PROTEC
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 15:22, Mark Lord wrote:
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
(again)? It
seems we 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]>
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
Rafael J. Wysocki wrote:
On Friday, 28 September 2007 15:22, Mark Lord wrote:
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
801 - 900 of 1516 matches
Mail list logo
