[PATCH] ata: sata_nv MCP61 using GENERIC instead of SWNCQ
hi, The mcp61 has bug with ncq. The patch only changes SWNCQ to GENERIC on MCP61 in nv_pci_tbl structure. 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. --- sata_nv-mcp61-generic-patch Description: sata_nv-mcp61-generic-patch
ATA tape drive STT3401A needs DRQ HSM workaround too
Hello, all. There was a bug report involving ATA tape drive STT3401A and the drive also sets DRQ with device error and works correctly if the check is ignored. I saw patch implementing needed horkage. What's the plan here? Blacklist all tape drives or individual ones as they come up? 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: ATA tape drive STT3401A needs DRQ HSM workaround too
On Mon, 22 Oct 2007 18:24:20 +0900 Tejun Heo [EMAIL PROTECTED] wrote: Hello, all. There was a bug report involving ATA tape drive STT3401A and the drive also sets DRQ with device error and works correctly if the check is ignored. I saw patch implementing needed horkage. What's the plan here? Blacklist all tape drives or individual ones as they come up? After discussion with Jeff the horkage patch is going back into the bitbucket and the state machine will be changed to consider the DRQ|ERR case simply a device error. I sent a patch for that to Andrew just before I left on holiday Alan - 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: ATA tape drive STT3401A needs DRQ HSM workaround too
Alan Cox wrote: On Mon, 22 Oct 2007 18:24:20 +0900 Tejun Heo [EMAIL PROTECTED] wrote: Hello, all. There was a bug report involving ATA tape drive STT3401A and the drive also sets DRQ with device error and works correctly if the check is ignored. I saw patch implementing needed horkage. What's the plan here? Blacklist all tape drives or individual ones as they come up? After discussion with Jeff the horkage patch is going back into the bitbucket and the state machine will be changed to consider the DRQ|ERR case simply a device error. I sent a patch for that to Andrew just before I left on holiday Alright, 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: AHCI with ATA/IDE Drives
Mark Lord wrote: Alan / Tejun, Another case of MDMA2 not working through a SATA-PATA bridge. Do we have an easy way yet, for Girish to force non-MDMA2 modes? libata.dma=1 should do the trick for 2.6.24-rcX. For 2.6.23, there isn't any. :-( -- 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: sata sil3114 vs. certain seagate drives results in filesystem corruptions
Hello, On Monday 22 October 2007 04:12:44 Tejun Heo wrote: Helo, Soeren Sonnenburg wrote: I finally managed to find a *reproducible* setup and way to trigger random corruptions using a sata sil 3114 controller connected to 4 seagate drives port 1: ST3400832AS sda port 2: ST3400620AS sdb port 3: ST3750640AS sdc port 4: ST3750640AS sdd sda sdb form md0 via a raid1 setup followed by an additional devicemapper layer ( root ). sdc and sdb are separate and also have an additional device mapper layer ( public ) and ( backups ). Now when I write large files of zeros to root(sdasdb) and read the file back in it contains a few nonzero entries: # dd if=/dev/zero of=/foo bs=1M count=2000 # hexdump /foo 000 * after 1GB random parts, within large blocks of zeroes I can reliably trigger this on the md0 / devmapper-root setup when I write about 2GB of data (note that this machine has 1.5G of memory - and still 1GB is often enough to see this problem). Here it does not matter where in the filesystem I do these writes. Thats almost the same test as I'm always doing. Only I do not write only 2GB, but as much as it fits onto the disk. On reading back this file, the filesystem will report errors somewhere between 50GB and 230GB (disk size is 250GB). Thanks. I'll try to reproduce the problem here. What's your motherboard? All tested S2882 boards here. Cheers, Bernd -- Bernd Schubert Q-Leap Networks GmbH - 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: AHCI with ATA/IDE Drives
On Sat, 20 Oct 2007 09:59:20 -0400 Mark Lord [EMAIL PROTECTED] wrote: Alan / Tejun, Another case of MDMA2 not working through a SATA-PATA bridge. Do we have an easy way yet, for Girish to force non-MDMA2 modes? I sent Jeff a patch a while back to allow libata DMA to be enabled seperately for disk, atapi and CF. So yes. - 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: AHCI with ATA/IDE Drives
On Mon, 22 Oct 2007 18:34:57 +0900 Tejun Heo [EMAIL PROTECTED] wrote: Mark Lord wrote: Alan / Tejun, Another case of MDMA2 not working through a SATA-PATA bridge. Do we have an easy way yet, for Girish to force non-MDMA2 modes? libata.dma=1 should do the trick for 2.6.24-rcX. For 2.6.23, there isn't any. :-( For CF specifying libata.dma=3 should do the trick even better as it will leave DMA enabled on disk and ATAPI - 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 sil3114 vs. certain seagate drives results in filesystem corruptions
On Mon, 2007-10-22 at 11:48 +0200, Bernd Schubert wrote: Hello, On Monday 22 October 2007 04:12:44 Tejun Heo wrote: Helo, [...] Now when I write large files of zeros to root(sdasdb) and read the file back in it contains a few nonzero entries: # dd if=/dev/zero of=/foo bs=1M count=2000 # hexdump /foo 000 * after 1GB random parts, within large blocks of zeroes I can reliably trigger this on the md0 / devmapper-root setup when I write about 2GB of data (note that this machine has 1.5G of memory - and still 1GB is often enough to see this problem). Here it does not matter where in the filesystem I do these writes. Thats almost the same test as I'm always doing. Only I do not write only 2GB, Well when I read your mail I thought that I could be seeing exactly the same bug... it still may be. However ``my'' problem does not go away with the mod15fix ... but as much as it fits onto the disk. On reading back this file, the filesystem will report errors somewhere between 50GB and 230GB (disk size is 250GB). Wow, I really see lots of corruptions (well every 1-2 GB a couple of bytes are corrupted). Are you getting similiarly many in the 50G - 230G region? Thanks. I'll try to reproduce the problem here. What's your motherboard? All tested S2882 boards here. I assume all equipped with lots of memory and mostly empty pci slots? Soeren - 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-sff: Correct use of check_status()
+ tf-command = ata_chk_status(ap); tf-feature = ioread8(ioaddr-error_addr); tf-nsect = ioread8(ioaddr-nsect_addr); tf-lbal = ioread8(ioaddr-lbal_addr); applied, with a sigh: it's in SFF, so I saw nothing wrong with ata_check_status(). I checked -- no SFF driver overrides it according to my audit, therefore the previous version was faster while still correct. I hit it with the NS87415 where ata_check_status() doesn't do the right thing. Later on it turned out that there were enough other bugs when enabling DMA that it needed its own tf read method anyway. Alternative is to go through and clear up chk_atatus v check_status (rename one sff_ to be clear), and explicitly document the assumption in tf_read. That way it'll be obvious to whoever hits it in future and they can supply their own tf_read method. Preferences ? Alan - 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 sil3114 vs. certain seagate drives results in filesystem corruptions
On Monday 22 October 2007 12:36:32 Soeren Sonnenburg wrote: On Mon, 2007-10-22 at 11:48 +0200, Bernd Schubert wrote: Hello, On Monday 22 October 2007 04:12:44 Tejun Heo wrote: Helo, [...] Now when I write large files of zeros to root(sdasdb) and read the file back in it contains a few nonzero entries: # dd if=/dev/zero of=/foo bs=1M count=2000 # hexdump /foo 000 * after 1GB random parts, within large blocks of zeroes I can reliably trigger this on the md0 / devmapper-root setup when I write about 2GB of data (note that this machine has 1.5G of memory - and still 1GB is often enough to see this problem). Here it does not matter where in the filesystem I do these writes. Thats almost the same test as I'm always doing. Only I do not write only 2GB, Well when I read your mail I thought that I could be seeing exactly the same bug... it still may be. However ``my'' problem does not go away with the mod15fix ... Yeah, pity it did not fix it :( I will try to port Tejuns patch (http://home-tj.org/wiki/index.php/Sil_m15w#Patches) to 2.6.23 today or tomorrow. If you are testing anyway, could you then also try this? but as much as it fits onto the disk. On reading back this file, the filesystem will report errors somewhere between 50GB and 230GB (disk size is 250GB). Wow, I really see lots of corruptions (well every 1-2 GB a couple of bytes are corrupted). Are you getting similiarly many in the 50G - 230G region? Thanks. I'll try to reproduce the problem here. What's your motherboard? All tested S2882 boards here. I assume all equipped with lots of memory and mostly empty pci slots? Yes, all pci-slots are free and the systems to have between 4 and 16GB memory (ecc, monitored with edac). Well, those are cluster systems (actually tyan names those B2882). Do you think the configuration is related? Here it also happens with odirect, we tested this to minimize memory effects. Cheers, Bernd -- Bernd Schubert Q-Leap Networks GmbH - 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] drivers/ide/Kconfig IDEPCI_SHARE_IRQ and IDEDISK_MULTI_MODE
Matti Linnanvuori wrote:
Correct IDEPCI_SHARE_IRQ description to keeping interrupts enabled
when calling the PCI IDE action handler.
Add IDEPCI_SHARE_IRQ and IDEDISK_MULTI_MODE help text from hdparm
manual page.
Signed-off-by: Matti Linnanvuori [EMAIL PROTECTED]
NAK.
@@ -154,6 +154,18 @@ config BLK_DEV_IDEDISK
config IDEDISK_MULTI_MODE
bool Use multi-mode by default
help
+ Multiple sector mode is a feature of most modern IDE hard
+ drives, permitting the transfer of multiple sectors per I/O
+ interrupt, rather than the usual one sector per interrupt.
+ When this feature is enabled, it typically reduces operating
+ system overhead for disk I/O by 30-50%. On many systems, it
+ also provides increased data throughput of anywhere from 5%
+ to 50%. Some drives, however (most notably the WD Caviar
+ series), seem to run slower with multiple mode enabled. Some
+ drives claim to support multiple mode, but lose data at some
+ settings. Under rare circumstances, such failures can result
The speed increase data provided here are largely useless, since multiple
mode only applies to PIO transfers. At least, the comment should make this
clear...
+ in massive filesystem corruption.
+
If you get this error, try to say Y here:
hda: set_multmode: status=0x51 { DriveReady SeekComplete Error }
@@ -367,11 +379,16 @@ config BLK_DEV_IDEPCI
bool
config IDEPCI_SHARE_IRQ
- bool Sharing PCI IDE interrupts support
+ bool Keeping interrupts enabled when calling the PCI IDE action handler
support
Keeping IRQ enabled is only a side effect of IRQ sharing...
depends on BLK_DEV_IDEPCI
help
- Some ATA/IDE chipsets have hardware support which allows for
- sharing a single IRQ with other cards. To enable support for
+ A setting of Y permits the driver to unmask other interrupts
+ during processing of a disk interrupt, which greatly improves
+ Linux's responsiveness and eliminates serial port overrun
+ errors. Use this feature with caution: some drive/controller
+ combinations do not tolerate the increased I/O latencies
+ possible when this feature is enabled, resulting in massive
+ filesystem corruption. To enable support for
this in the ATA/IDE driver, say Y here.
Comments do not really describe the IRQ sharing option anymore.
It is safe to say Y to this question, in most cases.
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
Re: ATA tape drive STT3401A needs DRQ HSM workaround too
Tejun Heo wrote: Hello, all. There was a bug report involving ATA tape drive STT3401A and the drive also sets DRQ with device error and works correctly if the check is ignored. I saw patch implementing needed horkage. What's the plan here? Blacklist all tape drives or individual ones as they come up? Speaking of which, I haven't yet tossed my ATAPI tape drive into the rubbish. Anyone want it? Free, tapes included! -ml - 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] ide: fix Kconfig IDEPCI_SHARE_IRQ and IDEDISK_MULTI_MODE
From: Matti Linnanvuori [EMAIL PROTECTED]
Correct IDEPCI_SHARE_IRQ description to keeping interrupts enabled
when calling the PCI IDE action handler. CONFIG_IDEPCI_SHARE_IRQ does not
affect the setting of IRQF_SHARED for PCI chipsets in function init_irq,
file drivers/ide/ide-probe.c but only the setting of IRQF_DISABLED.
Add IDEPCI_SHARE_IRQ and IDEDISK_MULTI_MODE help text from hdparm
manual page.
Signed-off-by: Matti Linnanvuori [EMAIL PROTECTED]
---
Changing mention of multi-mode to affecting only some systems. Improving text.
--- a/drivers/ide/Kconfig 2007-10-21 08:53:11.826349500 +0300
+++ b/drivers/ide/Kconfig 2007-10-22 18:45:58.715425500 +0300
@@ -154,7 +154,19 @@ config BLK_DEV_IDEDISK
config IDEDISK_MULTI_MODE
bool Use multi-mode by default
help
- If you get this error, try to say Y here:
+ Multiple sector mode is a feature of most modern
+ IDE drives, permitting the transfer of multiple sectors per I/O
+ interrupt, rather than the usual one sector per interrupt.
+ When this feature is enabled, it can reduce operating
+ system overhead for disk I/O by 30 - 50%. On some systems, it
+ also provides increased data throughput of anywhere from 5%
+ to 50%. Some drives, however (most notably the WD Caviar
+ series), seem to run slower with multiple mode enabled. Some
+ drives claim to support multiple mode, but lose data at some
+ settings. Under rare circumstances, such failures can result
+ in massive filesystem corruption.
+
+ If you get the following error, try to say Y here:
hda: set_multmode: status=0x51 { DriveReady SeekComplete Error }
hda: set_multmode: error=0x04 { DriveStatusError }
@@ -367,11 +379,16 @@ config BLK_DEV_IDEPCI
bool
config IDEPCI_SHARE_IRQ
- bool Sharing PCI IDE interrupts support
+ bool Keeping interrupts enabled when calling the PCI IDE action
handler
depends on BLK_DEV_IDEPCI
help
- Some ATA/IDE chipsets have hardware support which allows for
- sharing a single IRQ with other cards. To enable support for
+ A setting of Y permits the driver to enable other interrupts
+ during processing of a disk interrupt, which greatly improves
+ Linux's responsiveness and eliminates serial port overrun
+ and buffer errors. Use this feature with caution: some
+ drive/controller combinations do not tolerate the increased I/O
+ latencies possible when this feature is enabled, resulting in massive
+ filesystem corruption. To enable support for
this in the ATA/IDE driver, say Y here.
It is safe to say Y to this question, in most cases.
Machen Sie Yahoo! zu Ihrer Startseite. Los geht's:
http://de.yahoo.com/set
-
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
ata_exec_internal crash at boot in -git22
One of the systems tested in autoboot crashes at boot with with -git22. This is a AMD 2 socket Opteron NUMA system. The tester was a little flakey and happened to hit the x86-merge-broke- compilation window, so the last good data point I have is 2.6.23-rc9. -Andi megasas: 00.00.03.05 Mon Oct 02 11:21:32 PDT 2006 ACPI: PCI Interrupt :03:05.0[A] - GSI 17 (level, low) - IRQ 17 ata1: SATA max UDMA/100 cmd 0xC2006C80 ctl 0xC2006C8A bmdma 0xC2006C00 irq 17 ata2: SATA max UDMA/100 cmd 0xC2006CC0 ctl 0xC2006CCA bmdma 0xC2006C08 irq 17 ata3: SATA max UDMA/100 cmd 0xC2006E80 ctl 0xC2006E8A bmdma 0xC2006E00 irq 17 ata4: SATA max UDMA/100 cmd 0xC2006EC0 ctl 0xC2006ECA bmdma 0xC2006E08 irq 17 scsi0 : sata_sil ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) ata1.00: ATA-7, max UDMA/133, 234441648 sectors: LBA48 NCQ (depth 0/32) ata1.00: ata1: dev 0 multi count 16 Unable to handle kernel paging request at 2277 RIP: [80259b03] pfn_to_page+0x1f/0x32 PGD 0 Oops: [1] SMP CPU 2 Modules linked in: Pid: 915, comm: scsi_eh_0 Not tainted 2.6.19-git22 #24 RIP: 0010:[80259b03] [80259b03] pfn_to_page+0x1f/0x32 RSP: :810004f8 EFLAGS: 00010216 RAX: 0040 RBX: RCX: 0020 RDX: 000f RSI: 810004fbbc40 RDI: 0007f000 RBP: R08: R09: R10: 0001 R11: 80352a9b R12: 0003 R13: R14: 810004fbbc40 R15: 8100f7c2c708 FS: () GS:8101000eabc0() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 2277 CR3: 00201000 CR4: 06e0 Process scsi_eh_0 (pid: 915, threadinfo 810004fba000, task 8100f7a54870) Stack: 8043f1d1 8100f7c2c508 8100f7c2c708 8100f7c2c708 8100f7c2c508 Call Trace: [8043f1d1] ata_exec_internal+0x5a/0x96 [8043fab3] ata_set_mode+0x415/0x564 [80445b2f] ata_do_eh+0x11af/0x1493 [804464a2] ata_scsi_error+0x26f/0x509 [80403a67] scsi_error_handler+0x73/0x67b [80242f04] kthread+0xd1/0x101 [8020a318] child_rip+0xa/0x12 Code: 48 2b ba 68 22 00 00 48 6b c7 38 48 03 82 58 22 00 00 c3 48 RIP [80259b03] pfn_to_page+0x1f/0x32 RSP 810004f8 CR2: 2277 - 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: ata_exec_internal crash at boot in -git22
On Mon, Oct 22 2007, Andi Kleen wrote: One of the systems tested in autoboot crashes at boot with with -git22. This is a AMD 2 socket Opteron NUMA system. The tester was a little flakey and happened to hit the x86-merge-broke- compilation window, so the last good data point I have is 2.6.23-rc9. Andi, can you test with this patch applied? http://brick.kernel.dk/sg-git.patch -- Jens Axboe - 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-sff: Correct use of check_status()
Alan Cox wrote: + tf-command = ata_chk_status(ap); tf-feature = ioread8(ioaddr-error_addr); tf-nsect = ioread8(ioaddr-nsect_addr); tf-lbal = ioread8(ioaddr-lbal_addr); applied, with a sigh: it's in SFF, so I saw nothing wrong with ata_check_status(). I checked -- no SFF driver overrides it according to my audit, therefore the previous version was faster while still correct. I hit it with the NS87415 where ata_check_status() doesn't do the right thing. Later on it turned out that there were enough other bugs when enabling DMA that it needed its own tf read method anyway. Alternative is to go through and clear up chk_atatus v check_status (rename one sff_ to be clear), and explicitly document the assumption in tf_read. That way it'll be obvious to whoever hits it in future and they can supply their own tf_read method. Preferences ? That was my general preference -- use your own -tf_read() 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: ATA tape drive STT3401A needs DRQ HSM workaround too
Tejun Heo wrote: Hello, all. There was a bug report involving ATA tape drive STT3401A and the drive also sets DRQ with device error and works correctly if the check is ignored. I saw patch implementing needed horkage. What's the plan here? Blacklist all tape drives or individual ones as they come up? I should dig out the SATA (yes, really) tape drive somebody sent me. 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: ata_exec_internal crash at boot in -git22
On Monday 22 October 2007 20:26:45 Jens Axboe wrote: On Mon, Oct 22 2007, Andi Kleen wrote: One of the systems tested in autoboot crashes at boot with with -git22. This is a AMD 2 socket Opteron NUMA system. The tester was a little flakey and happened to hit the x86-merge-broke- compilation window, so the last good data point I have is 2.6.23-rc9. Andi, can you test with this patch applied? http://brick.kernel.dk/sg-git.patch Sorry was a mistake (cue: there is no 2.6.23-git22 yet). It turned out to be an old broken kernel. Current -git seems to boot. Sorry for the noise. -Andi - 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: ata_exec_internal crash at boot in -git22
On Mon, Oct 22 2007, Andi Kleen wrote: On Monday 22 October 2007 20:26:45 Jens Axboe wrote: On Mon, Oct 22 2007, Andi Kleen wrote: One of the systems tested in autoboot crashes at boot with with -git22. This is a AMD 2 socket Opteron NUMA system. The tester was a little flakey and happened to hit the x86-merge-broke- compilation window, so the last good data point I have is 2.6.23-rc9. Andi, can you test with this patch applied? http://brick.kernel.dk/sg-git.patch Sorry was a mistake (cue: there is no 2.6.23-git22 yet). It turned out to be an old broken kernel. Current -git seems to boot. Sorry for the noise. OK, all for the better :-) -- Jens Axboe - 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: AHCI with ATA/IDE Drives
Hello All, Thanks for your replies. If we see the dump, you will observe that the NAND flash supports the MDMA2 but the driver does not set it but goes in for PIO4. On looking at the ata_port_info structure populated in case of 3100 SATA controller chipset namely the first entry, the mwdma mask is not initialized causing the driver to skip the same and go in for PIO modes. When I did add the MDMA mask, everything fell in place and I was able to access the flash devices. Can you please let me know if there is any specific reason as to why the mdma masks are not added in the ata_port_info initialisations. Regards, Girish On 10/22/07, Alan Cox [EMAIL PROTECTED] wrote: On Mon, 22 Oct 2007 18:34:57 +0900 Tejun Heo [EMAIL PROTECTED] wrote: Mark Lord wrote: Alan / Tejun, Another case of MDMA2 not working through a SATA-PATA bridge. Do we have an easy way yet, for Girish to force non-MDMA2 modes? libata.dma=1 should do the trick for 2.6.24-rcX. For 2.6.23, there isn't any. :-( For CF specifying libata.dma=3 should do the trick even better as it will leave DMA enabled on disk and ATAPI - 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: AHCI with ATA/IDE Drives
Girish Shirasat wrote: Hello All, Thanks for your replies. If we see the dump, you will observe that the NAND flash supports the MDMA2 but the driver does not set it but goes in for PIO4. On looking at the ata_port_info structure populated in case of 3100 SATA controller chipset namely the first entry, the mwdma mask is not initialized causing the driver to skip the same and go in for PIO modes. When I did add the MDMA mask, everything fell in place and I was able to access the flash devices. Can you please let me know if there is any specific reason as to why the mdma masks are not added in the ata_port_info initialisations. We are talking about AHCI, right? Just an oversight IIRC. ISTR the original logic was somewhat of a guess, since ahci.c was originally written in the early SATA days -- and also admittedly when I understood less about SATA. I was worried about controller snooping, and also did not think it would be needed to support MWDMA, when UDMA was supported. Obviously those were flawed trains of thought, in hindsight. 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] PCI: disable MSI on more ATI NorthBridges
On Fri, 19 Oct 2007, Jeff Garzik wrote: Linas Vepstas wrote: On Fri, Oct 19, 2007 at 09:17:23PM +0800, Shane Huang wrote: Since we have little experience on PCI and MSI here, we had to try to As someone else pointed out, AMD should have *lots* of people with pci and msi experience on the payroll. (Folks here buy AMD-designed pci chips ...) ONLY comment out the pci_intx() call in drivers/ata/ahci.c My system can boot up too with MSI enabled! So does it mean that the root cause is our SB700 SATA controller has a hardware bug where setting INTX_DISABLE in the PCI COMMAND register masks MSI interrupts too? That's what it sounds like, to me. And what is the software solution or workaround? Not sure. Sounds like the device driver needs a quirk for this part. Take a look at tg3.c net driver change 2fbe43f6f631dd7ce19fb1499d6164a5bdb34568 which is a similar situation. However, it may turn out that removing the pci_intx() stuff as a general rule is easier than quirking these devices, if enough of them turn out to have this hardware bug. At a first approximation, ATI/AMD devices don't send any interrupts if intx is disabled, nVidia devices send legacy interrupts in addition to MSI ones if intx isn't disabled, and Intel devices actually work correctly. So we need at least one kind of device quirk for intx and msi. (And doing it in the drivers doesn't work, since everybody is making things driven by snd_hda_intel and would like msi, afaict) -Daniel *This .sig left intentionally blank* - 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] PCI: disable MSI on more ATI NorthBridges
Daniel Barkalow wrote: On Fri, 19 Oct 2007, Jeff Garzik wrote: Linas Vepstas wrote: On Fri, Oct 19, 2007 at 09:17:23PM +0800, Shane Huang wrote: Since we have little experience on PCI and MSI here, we had to try to As someone else pointed out, AMD should have *lots* of people with pci and msi experience on the payroll. (Folks here buy AMD-designed pci chips ...) ONLY comment out the pci_intx() call in drivers/ata/ahci.c My system can boot up too with MSI enabled! So does it mean that the root cause is our SB700 SATA controller has a hardware bug where setting INTX_DISABLE in the PCI COMMAND register masks MSI interrupts too? That's what it sounds like, to me. And what is the software solution or workaround? Not sure. Sounds like the device driver needs a quirk for this part. Take a look at tg3.c net driver change 2fbe43f6f631dd7ce19fb1499d6164a5bdb34568 which is a similar situation. However, it may turn out that removing the pci_intx() stuff as a general rule is easier than quirking these devices, if enough of them turn out to have this hardware bug. At a first approximation, ATI/AMD devices don't send any interrupts if intx is disabled, nVidia devices send legacy interrupts in addition to MSI ones if intx isn't disabled, and Intel devices actually work correctly. So we need at least one kind of device quirk for intx and msi. (And doing it in the drivers doesn't work, since everybody is making things driven by snd_hda_intel and would like msi, afaict) Note that INTX_DISABLE is a recent addition to PCI. Older PCI devices support neither MSI nor INTX-disable, so make sure such devices don't creep into your sample. In general it is documented that INTX_DISABLE should apply only to INTx# so devices that disable MSI based on that bit are out of spec. But unfortunately that is rather irrelevant, since we see these out-of-spec devices in the field today. 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] PCI: disable MSI on more ATI NorthBridges
On Mon, 22 Oct 2007, Jeff Garzik wrote: Daniel Barkalow wrote: On Fri, 19 Oct 2007, Jeff Garzik wrote: Linas Vepstas wrote: On Fri, Oct 19, 2007 at 09:17:23PM +0800, Shane Huang wrote: Since we have little experience on PCI and MSI here, we had to try to As someone else pointed out, AMD should have *lots* of people with pci and msi experience on the payroll. (Folks here buy AMD-designed pci chips ...) ONLY comment out the pci_intx() call in drivers/ata/ahci.c My system can boot up too with MSI enabled! So does it mean that the root cause is our SB700 SATA controller has a hardware bug where setting INTX_DISABLE in the PCI COMMAND register masks MSI interrupts too? That's what it sounds like, to me. And what is the software solution or workaround? Not sure. Sounds like the device driver needs a quirk for this part. Take a look at tg3.c net driver change 2fbe43f6f631dd7ce19fb1499d6164a5bdb34568 which is a similar situation. However, it may turn out that removing the pci_intx() stuff as a general rule is easier than quirking these devices, if enough of them turn out to have this hardware bug. At a first approximation, ATI/AMD devices don't send any interrupts if intx is disabled, nVidia devices send legacy interrupts in addition to MSI ones if intx isn't disabled, and Intel devices actually work correctly. So we need at least one kind of device quirk for intx and msi. (And doing it in the drivers doesn't work, since everybody is making things driven by snd_hda_intel and would like msi, afaict) Note that INTX_DISABLE is a recent addition to PCI. Older PCI devices support neither MSI nor INTX-disable, so make sure such devices don't creep into your sample. I have a device that supports MSI and INTX-disable, and, with MSI on (and delivering interrupts successfully) also sends legacy interrupts (on the IRQ that is no longer associated with the device) unless INTX is disabled. Without the intx_disable(), the kernel disables the IRQ entirely and breaks a random other device in my system. It's: 00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2) I haven't tried MSI with the other devices in the system, but I expect that this: 00:05.0 Audio device: nVidia Corporation MCP61 High Definition Audio (rev a2) will have the same issue, and use a multi-vendor driver. In general it is documented that INTX_DISABLE should apply only to INTx# so devices that disable MSI based on that bit are out of spec. But unfortunately that is rather irrelevant, since we see these out-of-spec devices in the field today. It's likewise documented (although maybe arguable in wording) that the device shouldn't send legacy interrupts if MSI is in use, regardless of INTX_DISABLE, but this also happens in the field. I think that the current Linux behavior with respect to INTX_DISABLE is simply due to which hardware bug was present in the device whose driver first got Linux support, but one or the other or both needs a quirk, since there's no behavior that works with everything. And it's still impossible to tell which bug is more common, since MSI isn't used most of the time, even if the hardware supports it, so it's pretty arbitrary which way Linux goes in the non-quirk case. -Daniel *This .sig left intentionally blank* - 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: ATA tape drive STT3401A needs DRQ HSM workaround too
Man.. somebody needs to teach hald the difference between optical drives and tape drives.. It seems to just sit in a tight loop issuing the same failed commands over and over and over to the tape unit after boot. I had to kill it off to gain control of Fedora so I could actually *do* anything on the system. Weird. Any, Albert Lee has claimed the drive. 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
Re: [patch] PCI: disable MSI on more ATI NorthBridges
Jeff Garzik [EMAIL PROTECTED] writes: Note that INTX_DISABLE is a recent addition to PCI. It's PCI 2.3. Older PCI devices support neither MSI nor INTX-disable, so make sure such devices don't creep into your sample. MSI has been introduced by PCI 2.2 (and thus PCI-X 1.0) so there may be devices with MSI but without INTx-disable bit. I guess I have some early PCI-X hardware with MSI but I don't know if they have INTx-disable bit and I can't currently test that. And it probably doesn't matter. In general it is documented that INTX_DISABLE should apply only to INTx# so devices that disable MSI based on that bit are out of spec. The wording is: 10: This bit disables the device from asserting INTx#. A value of 0 enables the assertion of its INTx# signal. A value of 1 disables the assertion of its INTx# signal. This bit's state after RST# is 0. Refer to Section 6.8.1.3 for control of MSI. So strictly speaking it mandates disabling/enabling INTx but says nothing about other things (e.g. MSI). Some common sense dictates it shouldn't disable MSI, I guess. The MSI Enable description doesn't leave any doubt: 0: MSI Enable: If 1, the function is permitted to use MSI to request service and is prohibited from using its INTx# pin [...] But unfortunately that is rather irrelevant, since we see these out-of-spec devices in the field today. Right. -- Krzysztof Halasa - 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] PCI: disable MSI on more ATI NorthBridges
Daniel Barkalow [EMAIL PROTECTED] writes: 00:05.0 Audio device: nVidia Corporation MCP61 High Definition Audio (rev a2) will have the same issue, and use a multi-vendor driver. I think MCP55 HDA did not have such problem, though I may be wrong (AFAIR it worked with shared IRQ and with MSI). -- Krzysztof Halasa - 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] PCI: disable MSI on more ATI NorthBridges
From: Krzysztof Halasa [EMAIL PROTECTED] Date: Tue, 23 Oct 2007 01:40:18 +0200 Jeff Garzik [EMAIL PROTECTED] writes: In general it is documented that INTX_DISABLE should apply only to INTx# so devices that disable MSI based on that bit are out of spec. The wording is: 10: This bit disables the device from asserting INTx#. A value of 0 enables the assertion of its INTx# signal. A value of 1 disables the assertion of its INTx# signal. This bit's state after RST# is 0. Refer to Section 6.8.1.3 for control of MSI. So strictly speaking it mandates disabling/enabling INTx but says nothing about other things (e.g. MSI). Some common sense dictates it shouldn't disable MSI, I guess. Right, and every vendor I've spoken to who had the INTX_DISABLE bug clearly acknowledged that it was a bug in their RTL design and that they considered the spec to be clear on this matter in that INTX_DISABLE should not influence MSI in any way. The MSI Enable description doesn't leave any doubt: 0: MSI Enable: If 1, the function is permitted to use MSI to request service and is prohibited from using its INTx# pin [...] Things get more complicated with PCI-Express because INTx# isn't an out-of-band pin, but rather a message sent over the bus :-) - 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] PCI: disable MSI on more ATI NorthBridges
From: Daniel Barkalow [EMAIL PROTECTED] Date: Mon, 22 Oct 2007 17:31:04 -0400 (EDT) It's likewise documented (although maybe arguable in wording) that the device shouldn't send legacy interrupts if MSI is in use, regardless of INTX_DISABLE, but this also happens in the field. I think that the current Linux behavior with respect to INTX_DISABLE is simply due to which hardware bug was present in the device whose driver first got Linux support, but one or the other or both needs a quirk, since there's no behavior that works with everything. And it's still impossible to tell which bug is more common, since MSI isn't used most of the time, even if the hardware supports it, so it's pretty arbitrary which way Linux goes in the non-quirk case. I think this pretty much sums up the situation accurately. My suggestion is: 1) Leave the pci_intx() twiddling code in drivers/pci/msi.c 2) Add quirks for INTX_DISABLE turns off MSI too, this sets a flag in the pci_dev. 3) The pci_intx() calls in drivers/pci/msi.c are skipped if this flag from #2 is set. 4) Add quirk entries for drivers/net/tg3.c chips and these SATA devices we are learning about here, as well as any others we are aware of right now. 5) Remove the pci_intx() workaround code from drivers/net/tg3.c and elsewhere. - 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: FW: LIBATA issue with SATA drive
Torsten Kaiser wrote: On 10/19/07, Tejun Heo [EMAIL PROTECTED] wrote: Torsten Kaiser wrote: Just remebered another thing about sata_sil24 that popped up with 2.6.23-mm1. With this kernel version (comparing to 2.6.23-rc8-mm1) the port probing time goes up from ~0.5 seconds per port/drive to ~2 seconds. Also the SControl changed: 2.6.23-rc8-mm1: [4.11] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) 2.6.23-mm1: [5.93] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 0) But except for increased delay during boot no errors can seen, the drives work normally. Yeah, PARTIAL / SLUMBER mode restriction is lifted. Dunno whether that's related to the increased delay tho. Will investigate. But don't invest too much time into this. That the delay is part of the broken ACPI of this board/bios seems very likely to me. (And apart from that delay there seems to be no other changes.) Alright, found it. Its because sata_sil24 now uses hardreset during probing. This behavior has changed because sil24 now supports PMP and some PMPs don't work with only SRST. HRST uses longer timing values to make sure PHY gets stable before proceeding and that's where the extra wait is coming from. 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: [patch] PCI: disable MSI on more ATI NorthBridges
On Mon, 22 Oct 2007, David Miller wrote: My suggestion is: 1) Leave the pci_intx() twiddling code in drivers/pci/msi.c 2) Add quirks for INTX_DISABLE turns off MSI too, this sets a flag in the pci_dev. 3) The pci_intx() calls in drivers/pci/msi.c are skipped if this flag from #2 is set. 4) Add quirk entries for drivers/net/tg3.c chips and these SATA devices we are learning about here, as well as any others we are aware of right now. 5) Remove the pci_intx() workaround code from drivers/net/tg3.c and elsewhere. Seems right to me, and pretty straightforward, except that I don't really understand the pm-related logic in there to know how that should work and whether intx will need to be enabled somewhere in addition to not disabling it in the msi enable code. -Daniel *This .sig left intentionally blank* - 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
