Re: 2.6.23-rc7 - _random_ IRQ23 : nobody cared
Hi Tejun,
On Thu, 27 Sep 2007 09:55:22 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
Paul Rolland wrote:
Hi David,
On Mon, 24 Sep 2007 23:56:59 +0930
David Newall [EMAIL PROTECTED] wrote:
Paul Rolland (???) wrote:
Hell, IRQ 23 is shared between libata and my modem !!!
Tried using the modem?
Can you change driver load order such that the driver for the modem is
loaded first?
As I said, it's not possible, because :
- the modem driver is an out-kernel one, so I have to wait the end of the
boot process so that it can be loaded,
- libata on IRQ23 is the one taking care of my disks, and I suspect it
quite hard to install a modem driver before having the disk driver
installed.
I was thinking of delaying the disabling of the IRQ, which is basically the
other part of the problem (the first part being that spurious IRQ from the
modem). If it is possible to do that long enough for the modem driver to be
loaded, then the IRQ xx : nobody cared becomes an informational message
during the boot process, and then it vanishes, leaving a perfectly working
machine.
I suspect something in note_interrupt that would do (totally
untested, just thinking loudly) :
/* Allow some delay to complete boot process before
* killing an IRQ. This allow some modules to be
* loaded before we decide the IRQ will not be handled.
*/
if (jiffies 120*HZ) {
/*
* Now kill the IRQ
*/
printk(KERN_EMERG Disabling IRQ #%d\n, irq);
desc-status |= IRQ_DISABLED;
desc-depth = 1;
desc-chip-disable(irq);
}
I'll try that this week-end, but if someone has an opinion about it, I'll
be glad to know :)
Regards,
Paul
-
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 05/25] ata: add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61
hi,
i saw the below changes from
http://git.kernel.org/?p=linux/kernel/git/jgarzik/libata-dev.git;a=commi
tdiff;h=5a5a9e1890b8260686218a68862d880daee1a817
[libata] sata_nv: Clean up ATA_FLAG_NCQ usage; bit test micro-opt
@@ -622,7 +622,9 @@ static const struct ata_port_info nv_port_info[] =
{
/* SWNCQ */
{
.sht= nv_swncq_sht,
- .flags = ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY,
+ .flags = ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
+ ATA_FLAG_NCQ,
+ .link_flags = ATA_LFLAG_HRST_TO_RESUME,
.pio_mask = NV_PIO_MASK,
.mwdma_mask = NV_MWDMA_MASK,
.udma_mask = NV_UDMA_MASK,
If swncq_enabled is set zero by user, nv_swncq_host_init would not be
called .
Then ncq should be disabled and the libata shouldn't send ncq cmd.
I am not sure whether the ATA_FLAG_NCQ flag which is in default set
makes libata send ncq cmd even when swncq_enable is 0?
nv_init_one
} else if (type == SWNCQ swncq_enabled) {
dev_printk(KERN_NOTICE, pdev-dev, Using SWNCQ
mode\n);
nv_swncq_host_init(host);
}
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---
-
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 05/25] ata: add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61
Kuan Luo wrote:
hi,
i saw the below changes from
http://git.kernel.org/?p=linux/kernel/git/jgarzik/libata-dev.git;a=commi
tdiff;h=5a5a9e1890b8260686218a68862d880daee1a817
[libata] sata_nv: Clean up ATA_FLAG_NCQ usage; bit test micro-opt
@@ -622,7 +622,9 @@ static const struct ata_port_info nv_port_info[] =
{
/* SWNCQ */
{
.sht= nv_swncq_sht,
- .flags = ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY,
+ .flags = ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
+ ATA_FLAG_NCQ,
+ .link_flags = ATA_LFLAG_HRST_TO_RESUME,
.pio_mask = NV_PIO_MASK,
.mwdma_mask = NV_MWDMA_MASK,
.udma_mask = NV_UDMA_MASK,
If swncq_enabled is set zero by user, nv_swncq_host_init would not be
called .
Then ncq should be disabled and the libata shouldn't send ncq cmd.
I am not sure whether the ATA_FLAG_NCQ flag which is in default set
makes libata send ncq cmd even when swncq_enable is 0?
nv_init_one
} else if (type == SWNCQ swncq_enabled) {
dev_printk(KERN_NOTICE, pdev-dev, Using SWNCQ
mode\n);
nv_swncq_host_init(host);
Thanks for watching! Yes, that looks like a problem.
I still feel the flags usage I removed was problematic. A better
solution, I think, would be to do follow the ADMA example of switching
the port_info type during early initialization:
if (type = CK804 adma_enabled) {
type = ADMA;
which in our case would result in
if (type == SWNCQ !swncq_enabled)
type = GENERIC;
Or, if you prefer, we could take the opposite route, _not_ set SWNCQ in
the pci_device_id table, and instead do something like
if (type = MCP65 swncq_enabled)
type = SWNCQ;
(MCP65 is just a pulled-out-of-thin-air example)
Regards,
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 http://vger.kernel.org/majordomo-info.html
RE: [patch 05/25] ata: add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61
Jeff Garzik wrote:
Kuan Luo wrote:
hi,
i saw the below changes from
http://git.kernel.org/?p=linux/kernel/git/jgarzik/libata-dev.g
it;a=commi
tdiff;h=5a5a9e1890b8260686218a68862d880daee1a817
[libata] sata_nv: Clean up ATA_FLAG_NCQ usage; bit test micro-opt
@@ -622,7 +622,9 @@ static const struct ata_port_info
nv_port_info[] =
{
/* SWNCQ */
{
.sht= nv_swncq_sht,
- .flags = ATA_FLAG_SATA |
ATA_FLAG_NO_LEGACY,
+ .flags = ATA_FLAG_SATA |
ATA_FLAG_NO_LEGACY |
+ ATA_FLAG_NCQ,
+ .link_flags = ATA_LFLAG_HRST_TO_RESUME,
.pio_mask = NV_PIO_MASK,
.mwdma_mask = NV_MWDMA_MASK,
.udma_mask = NV_UDMA_MASK,
If swncq_enabled is set zero by user, nv_swncq_host_init
would not be
called .
Then ncq should be disabled and the libata shouldn't send ncq cmd.
I am not sure whether the ATA_FLAG_NCQ flag which is in
default set
makes libata send ncq cmd even when swncq_enable is 0?
nv_init_one
} else if (type == SWNCQ swncq_enabled) {
dev_printk(KERN_NOTICE, pdev-dev, Using SWNCQ
mode\n);
nv_swncq_host_init(host);
Thanks for watching! Yes, that looks like a problem.
I still feel the flags usage I removed was problematic. A better
solution, I think, would be to do follow the ADMA example of
switching
the port_info type during early initialization:
if (type = CK804 adma_enabled) {
type = ADMA;
which in our case would result in
if (type == SWNCQ !swncq_enabled)
type = GENERIC;
Or, if you prefer, we could take the opposite route, _not_
set SWNCQ in
the pci_device_id table, and instead do something like
if (type = MCP65 swncq_enabled)
type = SWNCQ;
(MCP65 is just a pulled-out-of-thin-air example)
Regards,
Jeff
1.The former method type =GENERIC cann't support hotplug in
mcp51-55-61.
2.As to the latter mehthod, do you mean we may set MCP65 in
pci_device_id table and add the extra variable
static const struct ata_port_operations nv_MCP65_ops ={...}.
If setting GENERIC in pci_device_id table, It also doen't support
hotplug.
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---
-
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 05/25] ata: add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61
Kuan Luo wrote:
Jeff Garzik wrote:
Kuan Luo wrote:
hi,
i saw the below changes from
http://git.kernel.org/?p=linux/kernel/git/jgarzik/libata-dev.g
it;a=commi
tdiff;h=5a5a9e1890b8260686218a68862d880daee1a817
[libata] sata_nv: Clean up ATA_FLAG_NCQ usage; bit test micro-opt
@@ -622,7 +622,9 @@ static const struct ata_port_info
nv_port_info[] =
{
/* SWNCQ */
{
.sht= nv_swncq_sht,
- .flags = ATA_FLAG_SATA |
ATA_FLAG_NO_LEGACY,
+ .flags = ATA_FLAG_SATA |
ATA_FLAG_NO_LEGACY |
+ ATA_FLAG_NCQ,
+ .link_flags = ATA_LFLAG_HRST_TO_RESUME,
.pio_mask = NV_PIO_MASK,
.mwdma_mask = NV_MWDMA_MASK,
.udma_mask = NV_UDMA_MASK,
If swncq_enabled is set zero by user, nv_swncq_host_init
would not be
called .
Then ncq should be disabled and the libata shouldn't send ncq cmd.
I am not sure whether the ATA_FLAG_NCQ flag which is in
default set
makes libata send ncq cmd even when swncq_enable is 0?
nv_init_one
} else if (type == SWNCQ swncq_enabled) {
dev_printk(KERN_NOTICE, pdev-dev, Using SWNCQ
mode\n);
nv_swncq_host_init(host);
Thanks for watching! Yes, that looks like a problem.
I still feel the flags usage I removed was problematic. A better
solution, I think, would be to do follow the ADMA example of
switching
the port_info type during early initialization:
if (type = CK804 adma_enabled) {
type = ADMA;
which in our case would result in
if (type == SWNCQ !swncq_enabled)
type = GENERIC;
Or, if you prefer, we could take the opposite route, _not_
set SWNCQ in
the pci_device_id table, and instead do something like
if (type = MCP65 swncq_enabled)
type = SWNCQ;
(MCP65 is just a pulled-out-of-thin-air example)
Regards,
Jeff
1.The former method type =GENERIC cann't support hotplug in
mcp51-55-61.
'GENERIC' just an example; my apologies for the confusion.
2.As to the latter mehthod, do you mean we may set MCP65 in
pci_device_id table and add the extra variable
static const struct ata_port_operations nv_MCP65_ops ={...}.
Correct.
The main point was to fall back from SWNCQ to something else, if
!swncq_enabled, to avoid changing the ap-flags value after the port has
been allocated and initialized internally. And that switch must occur
prior to ata_pci_prepare_sff_host() call in nv_init_one().
Regards,
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 http://vger.kernel.org/majordomo-info.html
T61 SATA error in log
Saw that popping up in my log today on a brand new T61 thinkpad: [ 427.712000] ata1.00: exception Emask 0x2 SAct 0x18 SErr 0x0 action 0x2 frozen [ 427.712000] ata1.00: (spurious completions during NCQ issue=0x0 SAct=0x18 FIS=004040a1:0024) [ 427.712000] ata1.00: cmd 61/08:18:f4:74:54/00:00:04:00:00/40 tag 3 cdb 0x0 data 4096 out [ 427.712000] res 40/00:28:64:e4:51/00:00:04:00:00/40 Emask 0x2 (HSM violation) [ 427.712000] ata1.00: cmd 61/08:20:84:10:81/00:00:04:00:00/40 tag 4 cdb 0x0 data 4096 out [ 427.712000] res 40/00:28:64:e4:51/00:00:04:00:00/40 Emask 0x2 (HSM violation) [ 428.024000] ata1: soft resetting port [ 428.196000] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 428.204000] ata1.00: configured for UDMA/100 [ 428.204000] ata1: EH complete [ 428.204000] sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors (120034 MB) [ 428.204000] sd 0:0:0:0: [sda] Write Protect is off [ 428.204000] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 428.204000] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Kernel recovered just fine and things seem smooth so far. Is that something I need to worry about ? Kernel is ubuntu gutsy's 2.6.22 and controller is: Cheers,00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03) (prog-if 01 [AHCI 1.0]) Subsystem: Lenovo Unknown device 20a7 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Interrupt: pin B routed to IRQ 218 Region 0: I/O ports at 1c50 [size=8] Region 1: I/O ports at 1c44 [size=4] Region 2: I/O ports at 1c48 [size=8] Region 3: I/O ports at 1c40 [size=4] Region 4: I/O ports at 1c20 [size=32] Region 5: Memory at fe226000 (32-bit, non-prefetchable) [size=2K] Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/2 Enable+ Address: fee0300c Data: 4152 Capabilities: [70] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [a8] #12 [0010] Cheers, Ben. - 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 05/25] ata: add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61
Jeff Garzik wrote:
Kuan Luo wrote:
Jeff Garzik wrote:
Kuan Luo wrote:
hi,
i saw the below changes from
http://git.kernel.org/?p=linux/kernel/git/jgarzik/libata-dev.g
it;a=commi
tdiff;h=5a5a9e1890b8260686218a68862d880daee1a817
[libata] sata_nv: Clean up ATA_FLAG_NCQ usage; bit test micro-opt
@@ -622,7 +622,9 @@ static const struct ata_port_info
nv_port_info[] =
{
/* SWNCQ */
{
.sht= nv_swncq_sht,
- .flags = ATA_FLAG_SATA |
ATA_FLAG_NO_LEGACY,
+ .flags = ATA_FLAG_SATA |
ATA_FLAG_NO_LEGACY |
+ ATA_FLAG_NCQ,
+ .link_flags = ATA_LFLAG_HRST_TO_RESUME,
.pio_mask = NV_PIO_MASK,
.mwdma_mask = NV_MWDMA_MASK,
.udma_mask = NV_UDMA_MASK,
If swncq_enabled is set zero by user, nv_swncq_host_init
would not be
called .
Then ncq should be disabled and the libata shouldn't
send ncq cmd.
I am not sure whether the ATA_FLAG_NCQ flag which is in
default set
makes libata send ncq cmd even when swncq_enable is 0?
nv_init_one
} else if (type == SWNCQ swncq_enabled) {
dev_printk(KERN_NOTICE, pdev-dev, Using SWNCQ
mode\n);
nv_swncq_host_init(host);
Thanks for watching! Yes, that looks like a problem.
I still feel the flags usage I removed was problematic. A better
solution, I think, would be to do follow the ADMA example of
switching
the port_info type during early initialization:
if (type = CK804 adma_enabled) {
type = ADMA;
which in our case would result in
if (type == SWNCQ !swncq_enabled)
type = GENERIC;
Or, if you prefer, we could take the opposite route, _not_
set SWNCQ in
the pci_device_id table, and instead do something like
if (type = MCP65 swncq_enabled)
type = SWNCQ;
(MCP65 is just a pulled-out-of-thin-air example)
Regards,
Jeff
1.The former method type =GENERIC cann't support hotplug in
mcp51-55-61.
'GENERIC' just an example; my apologies for the confusion.
2.As to the latter mehthod, do you mean we may set MCP65 in
pci_device_id table and add the extra variable
static const struct ata_port_operations nv_MCP65_ops ={...}.
Correct.
The main point was to fall back from SWNCQ to something else, if
!swncq_enabled, to avoid changing the ap-flags value after
the port has
been allocated and initialized internally. And that switch
must occur
prior to ata_pci_prepare_sff_host() call in nv_init_one().
Regards,
Jeff
I see. Both your methods are perfect.
Because the nv_swncq_ops and nv_swncq_interrupt can be also used when
sending non ncq cmd,
It seems like:
/* MCP65 */
{
.sht= nv_sht,
.flags = ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY
.link_flags = ATA_LFLAG_HRST_TO_RESUME,
.pio_mask = NV_PIO_MASK,
.mwdma_mask = NV_MWDMA_MASK,
.udma_mask = NV_UDMA_MASK,
.port_ops = nv_swncq_ops,
.irq_handler= nv_swncq_interrupt,
},
Is it right?
Best regards,
Kuan Luo
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---
-
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 05/25] ata: add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61
Jeff Garzik wrote:
Kuan Luo wrote:
Jeff Garzik wrote:
Kuan Luo wrote:
hi,
i saw the below changes from
http://git.kernel.org/?p=linux/kernel/git/jgarzik/libata-dev.g
it;a=commi
tdiff;h=5a5a9e1890b8260686218a68862d880daee1a817
[libata] sata_nv: Clean up ATA_FLAG_NCQ usage; bit test micro-opt
@@ -622,7 +622,9 @@ static const struct ata_port_info
nv_port_info[] =
{
/* SWNCQ */
{
.sht= nv_swncq_sht,
- .flags = ATA_FLAG_SATA |
ATA_FLAG_NO_LEGACY,
+ .flags = ATA_FLAG_SATA |
ATA_FLAG_NO_LEGACY |
+ ATA_FLAG_NCQ,
+ .link_flags = ATA_LFLAG_HRST_TO_RESUME,
.pio_mask = NV_PIO_MASK,
.mwdma_mask = NV_MWDMA_MASK,
.udma_mask = NV_UDMA_MASK,
If swncq_enabled is set zero by user, nv_swncq_host_init
would not be
called .
Then ncq should be disabled and the libata shouldn't
send ncq cmd.
I am not sure whether the ATA_FLAG_NCQ flag which is in
default set
makes libata send ncq cmd even when swncq_enable is 0?
nv_init_one
} else if (type == SWNCQ swncq_enabled) {
dev_printk(KERN_NOTICE, pdev-dev, Using SWNCQ
mode\n);
nv_swncq_host_init(host);
Thanks for watching! Yes, that looks like a problem.
I still feel the flags usage I removed was problematic. A better
solution, I think, would be to do follow the ADMA example of
switching
the port_info type during early initialization:
if (type = CK804 adma_enabled) {
type = ADMA;
which in our case would result in
if (type == SWNCQ !swncq_enabled)
type = GENERIC;
Or, if you prefer, we could take the opposite route, _not_
set SWNCQ in
the pci_device_id table, and instead do something like
if (type = MCP65 swncq_enabled)
type = SWNCQ;
(MCP65 is just a pulled-out-of-thin-air example)
Regards,
Jeff
1.The former method type =GENERIC cann't support hotplug in
mcp51-55-61.
'GENERIC' just an example; my apologies for the confusion.
2.As to the latter mehthod, do you mean we may set MCP65 in
pci_device_id table and add the extra variable
static const struct ata_port_operations nv_MCP65_ops ={...}.
Correct.
The main point was to fall back from SWNCQ to something else, if
!swncq_enabled, to avoid changing the ap-flags value after
the port has
been allocated and initialized internally. And that switch
must occur
prior to ata_pci_prepare_sff_host() call in nv_init_one().
Regards,
Jeff
One idea, only simply adding
if (!swncq_enabled)
nv_port_info[SWNCQ].flags = ~ATA_FLAG_NCQ;
ppi[0] = nv_port_info[type];
rc = ata_pci_prepare_sff_host(pdev, ppi, host);
I don't know if this is appropriate
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---
-
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: Improper disk shutdown with 2.6.22.6?
On Thu, Sep 27, 2007 at 09:39:54AM +0900, Tejun Heo wrote: [cc'ing Henrique and Jeff] Robert wrote: Hello, When shutting down this system running Linux 2.6.22.6, I get a warning about the possibility that the disks are not properly shut down. When the power is turned off, it sounds like the disks aren't spun down (but I may be mistaken on that point). http://linux-ata.org/shutdown.html claims that kernels newer than 2.6.21 will always spin down the disks, but is this really the case? The manage_start_stop files exist. Tell me if you'd like more detailed information about configuration and hardware. You're on debian, right? You need to update your shutdown utilities. Thanks for your help. I'm on Debian, yes, and now I applied the change to /etc/init.d/halt in http://lists.alioth.debian.org/pipermail/pkg-sysvinit-commits/2007-June.txt and I'm using HDDOWN=NEVER in /etc/default/halt, which seems to work. Robert Henrique, what information should we put into the faq page to properly direct debian users to needed updates? Thanks. -- tejun - 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: 2.6.23-rc7 - _random_ IRQ23 : nobody cared
Let me guess... this is a T61 or X61 ? There's a problem with these that we don't fully understand yet, we're getting those stale interrupts all over the range. I wonder if it could be a bug with the ICH8 chipset... If yours is one of these, it's being dealt with (or attempted to deal with) at http://bugzilla.kernel.org/show_bug.cgi?id=8853 Ben. - 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
[patch] SB700 contains more than one IDE channel
From: [EMAIL PROTECTED]
SB700 supports one physical IDE channel, but SB700 SATA controller
supports combined mode. When the SATA combined mode is enabled,
two SATA ports(port4 and port5) share one IDE channel from IDE
controller, and PATA will share the other IDE channel.
Our previous patch adding SB700 IDE device ID only support one
IDE channel, which contains bug. The attached patch fix the bug.
Signed-off-by: [EMAIL PROTECTED]
--
diff -ruN linux-2.6.23-rc5_orig/drivers/ide/pci/atiixp.c
linux-2.6.23-rc5/drivers/ide/pci/atiixp.c
--- linux-2.6.23-rc5_orig/drivers/ide/pci/atiixp.c 2007-09-01
14:08:24.0 +0800
+++ linux-2.6.23-rc5/drivers/ide/pci/atiixp.c 2007-09-28
00:35:55.0 +0800
@@ -325,7 +325,7 @@
{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP300_IDE, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 0},
{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP400_IDE, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 0},
{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP600_IDE, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 1},
- { PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP700_IDE, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 1},
+ { PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP700_IDE, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 0},
{ 0, },
};
MODULE_DEVICE_TABLE(pci, atiixp_pci_tbl);
SB700_2_IDE_Channels.patch
Description: SB700_2_IDE_Channels.patch
Re: 2.6.23-rc7 - _random_ IRQ23 : nobody cared
Hello, On Thu, 27 Sep 2007 19:04:11 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: Let me guess... this is a T61 or X61 ? Bad luck ;) This is an Asus P5W-DH Deluxe motherboard, with a Core2 6400 CPU, a bunch of disk (2 IDE, 3 SATA, 1 CDRW and 1 DVDRW-DL), and a damned Olitec PCI V92 V2 modem. Paul - 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] SB700 contains more than one IDE channel
Hello.
Shane Huang wrote:
SB700 supports one physical IDE channel, but SB700 SATA controller
supports combined mode. When the SATA combined mode is enabled,
two SATA ports(port4 and port5) share one IDE channel from IDE
controller, and PATA will share the other IDE channel.
Our previous patch adding SB700 IDE device ID only support one
IDE channel, which contains bug. The attached patch fix the bug.
Signed-off-by: [EMAIL PROTECTED]
Acked-by: Sergei Shtylyov [EMAIL PROTECTED]
--
diff -ruN linux-2.6.23-rc5_orig/drivers/ide/pci/atiixp.c
linux-2.6.23-rc5/drivers/ide/pci/atiixp.c
--- linux-2.6.23-rc5_orig/drivers/ide/pci/atiixp.c 2007-09-01
14:08:24.0 +0800
+++ linux-2.6.23-rc5/drivers/ide/pci/atiixp.c 2007-09-28
00:35:55.0 +0800
@@ -325,7 +325,7 @@
{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP300_IDE, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 0},
{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP400_IDE, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 0},
{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP600_IDE, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 1},
- { PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP700_IDE, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 1},
+ { PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP700_IDE, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 0},
{ 0, },
};
MODULE_DEVICE_TABLE(pci, atiixp_pci_tbl);
The inlined patch has suffered from word wrapping, and the attached one
luckily didn't; yet the attachment has a wrong MIME type -- patches should be
text/plain.
MBR, Sergei
-
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
Sata Sil3512 bug?
Hello, First off, i'm quite new to linux. I don't know the official way's to report bugs. I'm not even sure that the bug is sata driver related. I hope you can do some suggestions. I recently bought 2 Sweex Sata controllers (without raid). This device contains the Sil3512 chip. I connected it to my D815EEA motherboard with a samsung hard drive. When i mounted it and connected to it with WinScp or samba i got hangs; a couple of seconds the filetransfer stopped. The logs in var and the screen are spooled with errors like in samsung error.txt. I now have bought some Western Digitals drives. I get similar problems (wd error.txt), but nog hangs. I've tried the controller in another motherboard, the ASUS CUSL2 (with similar specs) and i don't have any problems. Can you help? I've included some logs with may be of use. btw: i use Debian unstable. I use the same hd with the OS (IDE drive) on both systems, so we can exclude a faulty OS. -- Best regards, MisterE mailto:[EMAIL PROTECTED]Sep 24 17:42:43 fileserver kernel: NTFS driver 2.1.28 [Flags: R/W MODULE]. Sep 24 17:42:43 fileserver kernel: NTFS volume version 3.1. Sep 24 17:44:05 fileserver kernel: NTFS volume version 3.1. Sep 24 17:44:36 fileserver kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Sep 24 17:44:36 fileserver kernel: ata2.00: (BMDMA2 stat 0x6c0009) Sep 24 17:44:36 fileserver kernel: ata2.00: cmd c8/00:0c:a8:01:bd/00:00:00:00:00/e1 tag 0 cdb 0x0 data 6144 in Sep 24 17:44:36 fileserver kernel: res 51/04:00:b3:01:bd/00:00:00:00:00/e1 Emask 0x1 (device error) Sep 24 17:44:36 fileserver kernel: ata2.00: configured for UDMA/100 Sep 24 17:44:36 fileserver kernel: ata2: EH complete Sep 24 17:44:36 fileserver kernel: sd 1:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB) Sep 24 17:44:36 fileserver kernel: sd 1:0:0:0: [sda] Write Protect is off Sep 24 17:44:36 fileserver kernel: sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00 Sep 24 17:44:36 fileserver kernel: sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Sep 24 17:44:36 fileserver kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Sep 24 17:44:36 fileserver kernel: ata2.00: (BMDMA2 stat 0x6d0009) Sep 24 17:44:36 fileserver kernel: ata2.00: cmd c8/00:07:38:19:bd/00:00:00:00:00/e1 tag 0 cdb 0x0 data 3584 in Sep 24 17:44:36 fileserver kernel: res 51/04:00:3e:19:bd/00:00:00:00:00/e1 Emask 0x1 (device error) Sep 24 17:44:36 fileserver kernel: ata2.00: configured for UDMA/100 Sep 24 17:44:36 fileserver kernel: ata2: EH complete Sep 24 17:44:36 fileserver kernel: sd 1:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB) Sep 24 17:44:36 fileserver kernel: sd 1:0:0:0: [sda] Write Protect is off Sep 24 17:44:36 fileserver kernel: sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00 Sep 24 17:44:36 fileserver kernel: sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Sep 24 17:45:06 fileserver kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Sep 24 17:45:06 fileserver kernel: ata2.00: cmd c8/00:80:3f:21:bd/00:00:00:00:00/e1 tag 0 cdb 0x0 data 65536 in Sep 24 17:45:06 fileserver kernel: res 40/00:00:3e:19:bd/00:00:00:00:00/e1 Emask 0x4 (timeout) Sep 24 17:45:07 fileserver kernel: ata2: soft resetting port Sep 24 17:45:07 fileserver kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Sep 24 17:45:07 fileserver kernel: ata2.00: configured for UDMA/100 Sep 24 17:45:07 fileserver kernel: ata2: EH complete Sep 24 17:45:07 fileserver kernel: sd 1:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB) Sep 24 17:45:07 fileserver kernel: sd 1:0:0:0: [sda] Write Protect is off Sep 24 17:45:07 fileserver kernel: sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00 Sep 24 17:45:07 fileserver kernel: sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Sep 24 17:45:37 fileserver kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Sep 24 17:45:37 fileserver kernel: ata2.00: cmd c8/00:80:3f:24:bd/00:00:00:00:00/e1 tag 0 cdb 0x0 data 65536 in Sep 24 17:45:37 fileserver kernel: res 40/00:00:3e:19:bd/00:00:00:00:00/e1 Emask 0x4 (timeout) Sep 24 17:45:37 fileserver kernel: ata2: soft resetting port Sep 24 17:45:37 fileserver kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Sep 24 17:45:37 fileserver kernel: ata2.00: configured for UDMA/100 Sep 24 17:45:37 fileserver kernel: ata2: EH complete Sep 24 17:45:37 fileserver kernel: sd 1:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB) Sep 24 17:45:37 fileserver kernel: sd 1:0:0:0: [sda] Write Protect is off Sep 24 17:45:37 fileserver kernel: sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00 Sep 24 17:45:37 fileserver kernel: sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUASep 25 14:09:57 fileserver kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x240 action 0x0 Sep 25
correct kernel parameter in documentation.
'noacpi' isn't a standalone parameter, give it its prefix. Signed-off-by: Dave Jones [EMAIL PROTECTED] diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 4d175c7..a87bc58 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -863,6 +863,10 @@ and is between 256 and 4096 characters. It is defined in the file lasi= [HW,SCSI] PARISC LASI driver for the 53c700 chip Format: addr:io,irq:irq + libata.noacpi [LIBATA] Disables use of ACPI in libata suspend/resume + when set. + Format: int + load_ramdisk= [RAM] List of ramdisks to load from floppy See Documentation/ramdisk.txt. @@ -1079,10 +1083,6 @@ and is between 256 and 4096 characters. It is defined in the file emulation library even if a 387 maths coprocessor is present. - noacpi [LIBATA] Disables use of ACPI in libata suspend/resume - when set. - Format: int - noaliencache[MM, NUMA, SLAB] Disables the allocation of alien caches in the slab allocator. Saves per-node memory, but will impact performance. -- http://www.codemonkey.org.uk - 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: correct kernel parameter in documentation.
On Thu, 27 Sep 2007, Dave Jones wrote: 'noacpi' isn't a standalone parameter, give it its prefix. Signed-off-by: Dave Jones [EMAIL PROTECTED] diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 4d175c7..a87bc58 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -863,6 +863,10 @@ and is between 256 and 4096 characters. It is defined in the file lasi= [HW,SCSI] PARISC LASI driver for the 53c700 chip Format: addr:io,irq:irq + libata.noacpi [LIBATA] Disables use of ACPI in libata suspend/resume + when set. + Format: int + if you're going to add that libata-related parm to the kernel parms file, wouldn't it make sense for consistency to add the other available boot-time parms from libata-core.c as well? it seems counter-productive to document only a subset of them from the same source file. rday p.s. as i think i've mentioned before, i'd prefer to see that entire kernel-parameters.txt file reorganized, where the basic boot time parms are at the top, followed by module specific parameters *after* that, in alphabetical order by module name. i think that would make far more sense. -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca - 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: correct kernel parameter in documentation.
if you're going to add that libata-related parm to the kernel parms file, wouldn't it make sense for consistency to add the other available boot-time parms from libata-core.c as well? it seems counter-productive to document only a subset of them from the same source file. He's not adding it - he's correcting a bug - 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: Integrate ACPI-based PATA/SATA hotplug - version 3
On Tue, 25 Sep 2007 00:14:36 +0100
Matthew Garrett [EMAIL PROTECTED] 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.
Hi Matthew,
While I love the idea of integrating the Bay support with libata, and
I think this is a good patch, I have 2 concerns which don't seem to be
addressed here.
1. How does it handle things when you have a bay that is located behind
a dock and the dock ejects? In the acpi bay driver, I use the mechanism
that the dock driver exports to get undock notifications so that the bay
can eject as well.
2. What if someone wants to use their bay to charge their battery? While
I never bothered to implement this in acpi/bay.c, nothing ever prevented
anyone from adding that support to the driver, where now it is prevented
since this driver and another cannot coexist.
The basic problem is that there's no way to have multiple drivers register
a notifier for the same ACPI event on the same object. So, my solution
to this in my acpi drivers was to export ways to share from the driver.
Thanks,
Kristen
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 linux/acpi.h
#include linux/libata.h
#include linux/pci.h
+#include scsi/scsi_device.h
#include libata.h
#include acpi/acpi_bus.h
@@ -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,
+
Re: [PATCH] libata: Integrate ACPI-based PATA/SATA hotplug - version 3
On Thu, Sep 27, 2007 at 10:26:59AM -0700, Kristen Carlson Accardi wrote: 1. How does it handle things when you have a bay that is located behind a dock and the dock ejects? In the acpi bay driver, I use the mechanism that the dock driver exports to get undock notifications so that the bay can eject as well. Hm. I'd been working on the assumption that ejecting the doc would trigger the bay notifications as well, but I've got no hardware here with those capabilities so it's kind of hard to check... 2. What if someone wants to use their bay to charge their battery? While I never bothered to implement this in acpi/bay.c, nothing ever prevented anyone from adding that support to the driver, where now it is prevented since this driver and another cannot coexist. The spec seems to imply that even if the drive hotswap bay and the battery bay are physically the same, they're logically distinct. 10.2.1 specifies that the battery bay should always be considered present, and that any insertion notification will be generated from the battery bay rather than the drive bay (so Notify (BAT1, 0x81) rather than Notify (_SB.MISC.OTHR.BONG.PRIM.SLAV, 0x81)). My code will only grab the latter notification, not the former. I /suspect/ that _STA on the bay device won't return true if there's a battery in there, and so we aren't expected to call the _EJ0 method if the user wants to remove a battery. But I'm also lacking hardware to test this one, so it's possible that I'm utterly wrong :) -- Matthew Garrett | [EMAIL PROTECTED] - 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: Maxtor 6L200M0 sata irq timeouts
Michal Suchanek wrote: Hello (please CC me when replying) On 11/09/2007, Tejun Heo [EMAIL PROTECTED] wrote: Michal Suchanek wrote: What does 'smartctl -a /dev/sda' say? Attaching output. Hmmm... How often does the condition occur? smartlog records only two occasions. Every few minutes when the system is under load, less often when not. I think the logged drive errors are unrelated, the drive delivers the interrupt, just a bit later than Linux expects. At least that is my impression after looking at the these logs and the logs from the old system (I am not sure I could still find the saved logs but with some combination of irq related kernel options I got spurious interrupt instead of timeout, and the drive got disabled). Can you please test the latest rc kernel and see whether this problem is still there? Thanks. -- tejun - 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: 2.6.22.6 sata_sil device errors timeouts
Bruce Allen wrote: Andrew: thanks for isolating this problem. Tejun: any thoughts? The STRANGE_BUFFER_LENGTH problem is fixed in the code that Andrew is running. The problem is provoked with '-o on' which goes via a TASKFILE ioctl. I suppose you mean HDIO_DRIVE_TASK, right? libata doesn't implement HDIO_DRIVE_TASKFILE and it probably never will. I'll test it next week when I get back. Thanks. -- tejun - 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: Stardom SATA HSM violation
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 all SFF controllers. Old IDE does it on all controllers bar a couple. So we have a very good knowledge of what does/doesn't work. The one that needs care in old ide is an ordering issue where a state machine reset done first causes the drain of the I/O to hang. - 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: sata_sil24 with port multiplier
After applying the patches you sent, I had not received any additional errors until today. Below is an output from dmesg. Thanks for your help, Jon ata1.15: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen ata1.15: irq_stat 0x00020002, PMP DMA CS errata ata1.00: exception Emask 0x100 SAct 0x18084200 SErr 0x0 action 0x6 frozen ata1.00: cmd 60/00:48:3f:8f:fa/01:00:0a:00:00/40 tag 9 cdb 0x0 data 131072 in res 50/00:3c:3f:ff:67/00:00:00:00:00/40 Emask 0x100 (unknown error) ata1.00: cmd 60/00:70:3f:90:fa/01:00:0a:00:00/40 tag 14 cdb 0x0 data 131072 in res 50/00:3c:3f:ff:67/00:00:00:00:00/40 Emask 0x100 (unknown error) ata1.00: cmd 60/98:98:3f:91:fa/00:00:0a:00:00/40 tag 19 cdb 0x0 data 77824 in res 50/00:3c:3f:ff:67/00:00:00:00:00/40 Emask 0x100 (unknown error) ata1.00: cmd 60/a8:d8:97:8e:fa/00:00:0a:00:00/40 tag 27 cdb 0x0 data 86016 in res 50/00:3c:3f:ff:67/00:00:00:00:00/40 Emask 0x100 (unknown error) ata1.00: cmd 60/68:e0:d7:91:fa/00:00:0a:00:00/40 tag 28 cdb 0x0 data 53248 in res 50/00:3c:3f:ff:67/00:00:00:00:00/40 Emask 0x100 (unknown error) ata1.01: exception Emask 0x100 SAct 0x26108402 SErr 0x0 action 0x6 frozen ata1.01: cmd 60/a0:08:9f:8e:fa/00:00:0a:00:00/40 tag 1 cdb 0x0 data 81920 in res 50/00:3c:3f:ff:67/00:00:00:00:00/40 Emask 0x100 (unknown error) ata1.01: cmd 60/00:50:3f:8f:fa/01:00:0a:00:00/40 tag 10 cdb 0x0 data 131072 in res 50/00:3c:3f:ff:67/00:00:00:00:00/40 Emask 0x100 (unknown error) ata1.01: cmd 60/00:78:3f:90:fa/01:00:0a:00:00/40 tag 15 cdb 0x0 data 131072 in res 50/00:3c:3f:ff:67/00:00:00:00:00/40 Emask 0x100 (unknown error) ata1.01: cmd 60/68:a0:d7:8d:fa/00:00:0a:00:00/40 tag 20 cdb 0x0 data 53248 in res 50/00:3c:3f:ff:67/00:00:00:00:00/40 Emask 0x100 (unknown error) ata1.01: cmd 60/18:c8:87:8e:fa/00:00:0a:00:00/40 tag 25 cdb 0x0 data 12288 in res 50/00:3c:3f:ff:67/00:00:00:00:00/40 Emask 0x100 (unknown error) ata1.01: cmd 60/48:d0:3f:8e:fa/00:00:0a:00:00/40 tag 26 cdb 0x0 data 36864 in res 50/00:3c:3f:ff:67/00:00:00:00:00/40 Emask 0x100 (unknown error) ata1.01: cmd 60/00:e8:3f:91:fa/01:00:0a:00:00/40 tag 29 cdb 0x0 data 131072 in res 50/00:3c:3f:ff:67/00:00:00:00:00/40 Emask 0x100 (unknown error) ata1.02: exception Emask 0x10 SAct 0x40600989 SErr 0x0 action 0x6 frozen ata1.02: irq_stat 0x00020002, failed to transmit command FIS ata1.02: cmd 60/10:00:8f:8e:fa/00:00:0a:00:00/40 tag 0 cdb 0x0 data 8192 in res 50/00:3c:3f:ff:67/00:00:00:00:00/40 Emask 0x10 (ATA bus error) ata1.02: cmd 60/f8:18:3f:91:fa/00:00:0a:00:00/40 tag 3 cdb 0x0 data 126976 in res 50/00:3c:3f:ff:67/00:00:00:00:00/40 Emask 0x10 (ATA bus error) ata1.02: cmd 60/a0:38:9f:8e:fa/00:00:0a:00:00/40 tag 7 cdb 0x0 data 81920 in res 50/00:3c:3f:ff:67/00:00:00:00:00/40 Emask 0x10 (ATA bus error) ata1.02: cmd 60/08:40:37:92:fa/00:00:0a:00:00/40 tag 8 cdb 0x0 data 4096 in res 50/00:3c:3f:ff:67/00:00:00:00:00/40 Emask 0x10 (ATA bus error) ata1.02: cmd 60/00:58:3f:8f:fa/01:00:0a:00:00/40 tag 11 cdb 0x0 data 131072 in res 50/00:3c:3f:ff:67/00:00:00:00:00/40 Emask 0x10 (ATA bus error) ata1.02: cmd 60/68:a8:d7:8d:fa/00:00:0a:00:00/40 tag 21 cdb 0x0 data 53248 in res 50/00:3c:3f:ff:67/00:00:00:00:00/40 Emask 0x10 (ATA bus error) ata1.02: cmd 60/00:b0:3f:90:fa/01:00:0a:00:00/40 tag 22 cdb 0x0 data 131072 in res 50/00:3c:3f:ff:67/00:00:00:00:00/40 Emask 0x10 (ATA bus error) ata1.02: cmd 60/50:f0:3f:8e:fa/00:00:0a:00:00/40 tag 30 cdb 0x0 data 40960 in res 50/00:3c:3f:ff:67/00:00:00:00:00/40 Emask 0x10 (ATA bus error) ata1.03: exception Emask 0x0 SAct 0x3064 SErr 0x0 action 0x2 frozen ata1.04: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen ata1.05: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen ata1.15: hard resetting link ata1: controller in dubious state, performing PORT_RST ata1.15: SATA link up 3.0 Gbps (SStatus 123 SControl 0) ata1.00: hard resetting link ata1.00: softreset failed (SRST command error) ata1.00: reset failed (errno=-5), retrying in 10 secs ata1.00: hard resetting link ata1.00: hardreset failed (port not ready) ata1.00: reset failed (errno=-5), retrying in 10 secs ata1.00: hard resetting link ata1.00: hardreset failed (port not ready) ata1.00: reset failed (errno=-5), retrying in 35 secs ata1.00: limiting SATA link speed to 1.5 Gbps ata1.00: hard resetting link ata1.00: hardreset failed (port not ready) ata1.00: reset failed, giving up ata1.15: hard resetting link ata1: controller in dubious state, performing PORT_RST ata1.15: SATA link up 3.0 Gbps (SStatus 123 SControl 0) ata1.00: hard resetting link ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl 310) ata1.01: hard resetting link ata1.01: SATA link up 3.0 Gbps (SStatus 123 SControl 0) ata1.02: hard resetting link ata1.02: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata1.03: hard resetting link ata1.03: SATA link up 3.0 Gbps (SStatus 123 SControl
Re: [PATCH] libata: Integrate ACPI-based PATA/SATA hotplug - version 3
On Thu, 27 Sep 2007, Matthew Garrett wrote: The spec seems to imply that even if the drive hotswap bay and the battery bay are physically the same, they're logically distinct. 10.2.1 That holds true for thinkpads up to the T43, at least. I don't know about the newer ones. You get bay ejects/inserts notifications from the device node corresponding to what was inserted/removed from the multi-purpose bay. I /suspect/ that _STA on the bay device won't return true if there's a battery in there, and so we aren't expected to call the _EJ0 method if Correct, on thinkpads up to the T43 at least. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - 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: 2.6.23-rc7 - _random_ IRQ23 : nobody cared
On Thu, 2007-09-27 at 10:05 +, Paul Rolland wrote: Hello, On Thu, 27 Sep 2007 19:04:11 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: Let me guess... this is a T61 or X61 ? Bad luck ;) This is an Asus P5W-DH Deluxe motherboard, with a Core2 6400 CPU, a bunch of disk (2 IDE, 3 SATA, 1 CDRW and 1 DVDRW-DL), and a damned Olitec PCI V92 V2 modem. What chipset ? 965gm ? Ben. - 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: T61 SATA error in log
Benjamin Herrenschmidt wrote: Saw that popping up in my log today on a brand new T61 thinkpad: [ 427.712000] ata1.00: exception Emask 0x2 SAct 0x18 SErr 0x0 action 0x2 frozen [ 427.712000] ata1.00: (spurious completions during NCQ issue=0x0 SAct=0x18 FIS=004040a1:0024) [ 427.712000] ata1.00: cmd 61/08:18:f4:74:54/00:00:04:00:00/40 tag 3 cdb 0x0 data 4096 out [ 427.712000] res 40/00:28:64:e4:51/00:00:04:00:00/40 Emask 0x2 (HSM violation) [ 427.712000] ata1.00: cmd 61/08:20:84:10:81/00:00:04:00:00/40 tag 4 cdb 0x0 data 4096 out [ 427.712000] res 40/00:28:64:e4:51/00:00:04:00:00/40 Emask 0x2 (HSM violation) [ 428.024000] ata1: soft resetting port [ 428.196000] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 428.204000] ata1.00: configured for UDMA/100 [ 428.204000] ata1: EH complete [ 428.204000] sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors (120034 MB) [ 428.204000] sd 0:0:0:0: [sda] Write Protect is off [ 428.204000] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 428.204000] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Kernel recovered just fine and things seem smooth so far. Is that something I need to worry about ? Please post the result of 'hdparm -I /dev/sda' and you don't need to worry about it too much. -- tejun - 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: Stardom SATA HSM violation
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 all SFF controllers. Old IDE does it on all controllers bar a couple. So we have a very good knowledge of what does/doesn't work. The one that needs care in old ide is an ordering issue where a state machine reset done first causes the drain of the I/O to hang. Hmmm... So, do we apply draining to all PATA? Or is ata_piix SATA affected too? -- tejun - 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: T61 SATA error in log
On Thu, 2007-09-27 at 13:35 -0700, Tejun Heo wrote: Benjamin Herrenschmidt wrote: Saw that popping up in my log today on a brand new T61 thinkpad: [ 427.712000] ata1.00: exception Emask 0x2 SAct 0x18 SErr 0x0 action 0x2 frozen [ 427.712000] ata1.00: (spurious completions during NCQ issue=0x0 SAct=0x18 FIS=004040a1:0024) [ 427.712000] ata1.00: cmd 61/08:18:f4:74:54/00:00:04:00:00/40 tag 3 cdb 0x0 data 4096 out [ 427.712000] res 40/00:28:64:e4:51/00:00:04:00:00/40 Emask 0x2 (HSM violation) [ 427.712000] ata1.00: cmd 61/08:20:84:10:81/00:00:04:00:00/40 tag 4 cdb 0x0 data 4096 out [ 427.712000] res 40/00:28:64:e4:51/00:00:04:00:00/40 Emask 0x2 (HSM violation) [ 428.024000] ata1: soft resetting port [ 428.196000] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 428.204000] ata1.00: configured for UDMA/100 [ 428.204000] ata1: EH complete [ 428.204000] sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors (120034 MB) [ 428.204000] sd 0:0:0:0: [sda] Write Protect is off [ 428.204000] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 428.204000] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Kernel recovered just fine and things seem smooth so far. Is that something I need to worry about ? Please post the result of 'hdparm -I /dev/sda' and you don't need to worry about it too much. Allright. What is happening exactly ? A fluke on the link ? [EMAIL PROTECTED]:~/kernels/linux-2.6$ sudo hdparm -I /dev/sda /dev/sda: ATA device, with non-removable media Model Number: ST9120822AS Serial Number: 5LZ50702 Firmware Revision: 3.CLF Standards: Supported: 7 6 5 4 Likely used: 7 Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBAuser addressable sectors: 234441648 LBA48 user addressable sectors: 234441648 device size with M = 1024*1024: 114473 MBytes device size with M = 1000*1000: 120034 MBytes (120 GB) Capabilities: LBA, IORDY(can be disabled) Queue depth: 32 Standby timer values: spec'd by Standard, no device specific minimum R/W multiple sector transfer: Max = 16 Current = ? Advanced power management level: unknown setting (0x8080) Recommended acoustic management value: 254, current value: 0 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=240ns IORDY flow control=120ns Commands/features: Enabled Supported: *SMART feature set Security Mode feature set *Power Management feature set *Write cache *Look-ahead *Host Protected Area feature set *WRITE_BUFFER command *READ_BUFFER command *DOWNLOAD_MICROCODE *Advanced Power Management feature set SET_MAX security extension *48-bit Address feature set *Device Configuration Overlay feature set *Mandatory FLUSH_CACHE *FLUSH_CACHE_EXT *SMART error logging *SMART self-test *General Purpose Logging feature set *IDLE_IMMEDIATE with UNLOAD *SATA-I signaling speed (1.5Gb/s) *Native Command Queueing (NCQ) *Phy event counters *Device-initiated interface power management *Software settings preservation *SMART Command Transport (SCT) feature set Security: Master password revision code = 65534 supported not enabled not locked frozen not expired: security count supported: enhanced erase 66min for SECURITY ERASE UNIT. 66min for ENHANCED SECURITY ERASE UNIT. Checksum: correct - 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: Stardom SATA HSM violation
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 all SFF controllers. Old IDE does it on all controllers bar a couple. So we have a very good knowledge of what does/doesn't work. The one that needs care in old ide is an ordering issue where a state machine reset done first causes the drain of the I/O to hang. Hmmm... So, do we apply draining to all PATA? Or is ata_piix SATA affected too? I would think all SFF controllers, since a lot of first gen SATA are really bridged solutions. If they are flagging DRQ, I say oblige them :) 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 http://vger.kernel.org/majordomo-info.html
Re: T61 SATA error in log
Benjamin Herrenschmidt wrote: Allright. What is happening exactly ? A fluke on the link ? The drive is sending spurious completions of NCQ commands (ie. it's sending completions for commands which are not pending). We believe this happens due to firmware bugs and it matched the reality pretty well (drives with spurious completions usually had other NCQ related problems) but recently too many new drives are causing this problem. I have no idea what's going on. I guess it's about time to contact harddrive vendors. [EMAIL PROTECTED]:~/kernels/linux-2.6$ sudo hdparm -I /dev/sda /dev/sda: ATA device, with non-removable media Model Number: ST9120822AS Serial Number: 5LZ50702 Firmware Revision: 3.CLF Will add to blacklist. Thanks. -- tejun - 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
[PATCH] libata drain fifo on stuck DRQ HSM violation
Tejun Heo wrote:
Jeff Garzik wrote:
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 all SFF controllers.
Old IDE does it on all controllers bar a couple. So we have a very good
knowledge of what does/doesn't work. The one that needs care in old ide
is an ordering issue where a state machine reset done first causes the
drain of the I/O to hang.
Hmmm... So, do we apply draining to all PATA? Or is ata_piix SATA
affected too?
I would think all SFF controllers, since a lot of first gen SATA are
really bridged solutions. If they are flagging DRQ, I say oblige them :)
Alright, then the posted patch should be good enough. Mark, can you be
bothered to regenerate the patch and post it one more time (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]
---
--- 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 ata_port *ap, struct ata_queued_cmd *qc)
+{
+ u8 stat = ata_chk_status(ap);
+ /*
+* Try to clear stuck DRQ if necessary.
+*/
+ if ((stat ATA_DRQ) (!qc || qc-dma_dir != DMA_TO_DEVICE)) {
+ unsigned int i, limit = 512;
+ printk(Draining up to %u words from data FIFO.\n, limit);
+ for (i = 0; i limit ; ++i) {
+ ioread16(ap-ioaddr.data_addr);
+ if (!(ata_chk_status(ap) ATA_DRQ))
+ break;
+ }
+ printk(Drained %u/%u words.\n, i, limit);
+ }
+}
+
/**
* ata_bmdma_drive_eh - Perform EH with given methods for BMDMA controller
* @ap: port to handle error for
@@ -469,7 +487,7 @@
}
ata_altstatus(ap);
- ata_chk_status(ap);
+ ata_drain_fifo(ap, qc);
ap-ops-irq_clear(ap);
spin_unlock_irqrestore(ap-lock, flags);
-
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] SB700 contains more than one IDE channel
Hi Sergei:
Thanks for your reply.
The inlined patch has suffered from word wrapping,
OK, I think the cause is my mail client MS outlook's setting.
I try to change my outlook settings and attach the patch again at the
end of this mail. Please check it again.
and the attached one
luckily didn't; yet the attachment has a wrong MIME type -- patches
should be
text/plain.
As to this case, I don't know why. The patch was generated with diff on
linux,
and copied to my windows mail machine to be sent. All my previous
patches
with the same method do NOT meet such problem.
So if the patch in this mail does not work either, would you please help
to
change and apply it for me? So that we can save some time, otherwise
I'll
have to try to use gmail to send it at home.
Thanks
Best Regards
Shane
Signed-off-by: [EMAIL PROTECTED]
--
diff -ruN linux-2.6.23-rc5_orig/drivers/ide/pci/atiixp.c
linux-2.6.23-rc5/drivers/ide/pci/atiixp.c
--- linux-2.6.23-rc5_orig/drivers/ide/pci/atiixp.c 2007-09-01
14:08:24.0 +0800
+++ linux-2.6.23-rc5/drivers/ide/pci/atiixp.c 2007-09-28
00:35:55.0 +0800
@@ -325,7 +325,7 @@
{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP300_IDE, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 0},
{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP400_IDE, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 0},
{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP600_IDE, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 1},
- { PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP700_IDE, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 1},
+ { PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP700_IDE, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 0},
{ 0, },
};
MODULE_DEVICE_TABLE(pci, atiixp_pci_tbl);
-
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: 2.6.22.6 sata_sil device errors timeouts
Hi Tejun, Thanks! Yes I meant HDIO_DRIVE_TASK. Please let me know what your tests reveal. Cheers, Bruce On Thu, 27 Sep 2007, Tejun Heo wrote: Bruce Allen wrote: Andrew: thanks for isolating this problem. Tejun: any thoughts? The STRANGE_BUFFER_LENGTH problem is fixed in the code that Andrew is running. The problem is provoked with '-o on' which goes via a TASKFILE ioctl. I suppose you mean HDIO_DRIVE_TASK, right? libata doesn't implement HDIO_DRIVE_TASKFILE and it probably never will. I'll test it next week when I get back. Thanks. - 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: Stardom SATA HSM violation
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 all SFF controllers. Old IDE does it on all controllers bar a couple. So we have a very good knowledge of what does/doesn't work. The one that needs care in old ide is an ordering issue where a state machine reset done first causes the drain of the I/O to hang. Hmmm... So, do we apply draining to all PATA? Or is ata_piix SATA affected too? ata_piix SATA is definitely affected when a PATA_drive to SATA_host bridge is present. Possibly other times. Cheers - 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
