Re: [PATCH] AMD SB700/SB800 SATA support 64bit DMA
On Fri, 22 Feb 2008 12:55:20 +0800 Huang, Shane [EMAIL PROTECTED] wrote: Jeff: SB700 SATA controller can support 64 bit DMA, the previous commit badc2341579511a247f5993865aa68379e283c5c was added with careless reference to SB600, which should be modified by this patch. Does the SB700 have the same limits as the SB600 on 256 sectors in one PRD entry ? If it does then this change needs to wait until the workaround for that is included. - 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: What's needed for PMP support?
Heck, if .dev_select() took a *device* instead of a *port* as it's parameter, then I could probably manage it fine in there. dev_select gets called during probing before the relevant structures are neccessarily set up. - 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: automatically use DMADIR if drive/bridge requires it
Tejun Heo wrote: Back in 2.6.17-rc2, a libata module parameter was added for atapi_dmadir. That's nice, but most SATA devices which need it will tell us about it in their IDENTIFY PACKET response, as bit-15 of word-62 of the returned data (as per ATA7, ATA8 specifications). So for those which specify it, we should automatically use the DMADIR bit. Otherwise, disc writing will fail by default on many SATA-ATAPI drives. This patch adds ATA_DFLAG_DMADIR and make ata_dev_configure() set it if atapi_dmadir is set or identify data indicates DMADIR is necessary. atapi_xlat() is converted to check ATA_DFLAG_DMADIR before setting DMADIR. Original patch is from Mark Lord. Signed-off-by: Tejun Heo [EMAIL PROTECTED] Cc: Mark Lord [EMAIL PROTECTED] --- I don't have a bridge which sets DMADIR but so only checked atapi_dmadir parameter. Thanks. The patch looks good. However, it seems there is no realworld IDE-to-SATA bridge that requires DMADIR and also mangles IDENTIFY PACKET bit-15 of word-62 to indicate its presence. From the previous test of the IDE-to-SATA bridges, only the Sil 3611 requires the host software to hint on ATAPI DMADIR. But Sil 3611 doesn't mangle IDENTIFY PACKET word-62: http://www.spinics.net/lists/linux-ide/msg01514.html Maybe we could use ata_dev_knobble() instead? i.e. If it's an ATAPI device ata_dev_knobble() then we turn on DMADIR (regardless the bridge chip used since setting DMADIR won't hurt those don't need it.) -- albert - 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] AMD SB700/SB800 SATA support 64bit DMA
Alan: SB700 SATA controller can support 64 bit DMA, the previous commit badc2341579511a247f5993865aa68379e283c5c was added with careless reference to SB600, which should be modified by this patch. Does the SB700 have the same limits as the SB600 on 256 sectors in one PRD entry ? If it does then this change needs to wait until the workaround for that is included. Thanks for the reminder, but that issue only appears on SB600, while SB700 does not have that limitation. I'll submit this SB700/800 patch again with a private mail box later. Thanks Shane - 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] AMD SB700/SB800 SATA support 64bit DMA
Jeff and Tejun:
I'm using my private mailbox to submit it before I set up
the connection to our exchange mail server under linux.
Please check whether this patch can be accepted.
Thanks
Shane
CUT HERE
SB700 SATA controller can support 64 bit DMA, the previous commit
badc2341579511a247f5993865aa68379e283c5c was added with
careless reference to SB600, which should be modified by this patch.
Signed-off-by: Shane Huang [EMAIL PROTECTED]
diff -ruN a/drivers/ata/ahci.c b/drivers/ata/ahci.c
--- a/drivers/ata/ahci.c2008-02-22 18:17:03.0 +0800
+++ b/drivers/ata/ahci.c2008-02-22 18:16:54.0 +0800
@@ -85,6 +85,7 @@
board_ahci_ign_iferr= 2,
board_ahci_sb600= 3,
board_ahci_mv = 4,
+ board_ahci_sb700= 5,
/* global controller registers */
HOST_CAP= 0x00, /* host capabilities */
@@ -442,6 +443,16 @@
.udma_mask = ATA_UDMA6,
.port_ops = ahci_ops,
},
+ /* board_ahci_sb700 */
+ {
+ AHCI_HFLAGS (AHCI_HFLAG_IGN_SERR_INTERNAL |
+AHCI_HFLAG_NO_PMP),
+ .flags = AHCI_FLAG_COMMON,
+ .link_flags = AHCI_LFLAG_COMMON,
+ .pio_mask = 0x1f, /* pio0-4 */
+ .udma_mask = ATA_UDMA6,
+ .port_ops = ahci_ops,
+ },
};
static const struct pci_device_id ahci_pci_tbl[] = {
@@ -484,12 +495,12 @@
/* ATI */
{ PCI_VDEVICE(ATI, 0x4380), board_ahci_sb600 }, /* ATI SB600 */
- { PCI_VDEVICE(ATI, 0x4390), board_ahci_sb600 }, /* ATI SB700/800 */
- { PCI_VDEVICE(ATI, 0x4391), board_ahci_sb600 }, /* ATI SB700/800 */
- { PCI_VDEVICE(ATI, 0x4392), board_ahci_sb600 }, /* ATI SB700/800 */
- { PCI_VDEVICE(ATI, 0x4393), board_ahci_sb600 }, /* ATI SB700/800 */
- { PCI_VDEVICE(ATI, 0x4394), board_ahci_sb600 }, /* ATI SB700/800 */
- { PCI_VDEVICE(ATI, 0x4395), board_ahci_sb600 }, /* ATI SB700/800 */
+ { PCI_VDEVICE(ATI, 0x4390), board_ahci_sb700 }, /* ATI SB700/800 */
+ { PCI_VDEVICE(ATI, 0x4391), board_ahci_sb700 }, /* ATI SB700/800 */
+ { PCI_VDEVICE(ATI, 0x4392), board_ahci_sb700 }, /* ATI SB700/800 */
+ { PCI_VDEVICE(ATI, 0x4393), board_ahci_sb700 }, /* ATI SB700/800 */
+ { PCI_VDEVICE(ATI, 0x4394), board_ahci_sb700 }, /* ATI SB700/800 */
+ { PCI_VDEVICE(ATI, 0x4395), board_ahci_sb700 }, /* ATI SB700/800 */
/* VIA */
{ PCI_VDEVICE(VIA, 0x3349), board_ahci_vt8251 }, /* VIA VT8251 */
-
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: automatically use DMADIR if drive/bridge requires it
Albert Lee wrote: Tejun Heo wrote: Back in 2.6.17-rc2, a libata module parameter was added for atapi_dmadir. That's nice, but most SATA devices which need it will tell us about it in their IDENTIFY PACKET response, as bit-15 of word-62 of the returned data (as per ATA7, ATA8 specifications). So for those which specify it, we should automatically use the DMADIR bit. Otherwise, disc writing will fail by default on many SATA-ATAPI drives. This patch adds ATA_DFLAG_DMADIR and make ata_dev_configure() set it if atapi_dmadir is set or identify data indicates DMADIR is necessary. atapi_xlat() is converted to check ATA_DFLAG_DMADIR before setting DMADIR. Original patch is from Mark Lord. Signed-off-by: Tejun Heo [EMAIL PROTECTED] Cc: Mark Lord [EMAIL PROTECTED] --- I don't have a bridge which sets DMADIR but so only checked atapi_dmadir parameter. Thanks. The patch looks good. However, it seems there is no realworld IDE-to-SATA bridge that requires DMADIR and also mangles IDENTIFY PACKET bit-15 of word-62 to indicate its presence. From the previous test of the IDE-to-SATA bridges, only the Sil 3611 requires the host software to hint on ATAPI DMADIR. But Sil 3611 doesn't mangle IDENTIFY PACKET word-62: http://www.spinics.net/lists/linux-ide/msg01514.html .. Ahh, great! We have history here! But there are more SATA bridges out there than the ones Alber has there (SiI 3611/3811, Marvell 88i8030/88SA8040, Acard ARC770, JMicron JM20330). There's the Marvell 88SA8050, and I have a funky looking thing here that says SataLink SPiF223A on it (). I wonder what it does? And how many other ones are there? The Word62 patch (from Tejun) is simple enough that the complexity point from before really doesn't hold water. To be ATA compliant, we really should add it in. But yes, it would also be good to see it in action. That's more likely to happen in the general user community, than in our limited circle of kernel folk with limited hardware. 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] libata: automatically use DMADIR if drive/bridge requires it
Mark Lord wrote: I have a funky looking thing here that says SataLink SPiF223A on it (). I wonder what it does? .. Well, after some experimentation, this one appears to be ATA-only, with no ATAPI support at all. 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: new ata_port_operations for .pmp_{read,write} ?
Mark Lord wrote:
Tejun,
Here's a first cut at this for discussion.
You may prefer different names for the invoking functions
inside libata-pmp.c, rather than simply pmp_read() and pmp_write(),
but I've been up too long and couldn't think of a better name.
An alternative to all this, might be to expose the select_pmp()
function shown in the sample code, and have libata-pmp.c call that,
instead of having the new new .pmp_{read,write} functions.
What do you think?
* * *
SATA host controllers which are not purely FIS-based require setup
of a special register to select the active pmp for taskfile accesses.
This can be done in the low-level driver for regular command issue
on a link. But commands directed at a port-multiplier cause problems,
because they leave the original link pmp de-selected afterwards.
To fix this in a sane fashion, without tons of code duplication
from libata into the low-level driver, it is necessary to be able
to wrap the sata_pmp_read() and sata_pmp_write() functions.
This patch provides two new struct ata_port_operations methods for this,
and modifies the code in libata-pmp to use them if provided.
...
Note that, while this does work for sata_mv, I'm still thinking about it.
I'm not totally clear yet (more reading to do) as to how/when
the ATA shadow/taskfile registers get updated to reflect those
for the currently selected pmp..
It would seem that with other parts of libata-sff directly reading
from the ctl, status, and altstatus registers during polling,
command setup, and probing, that there might (?) be a loophole
somewhere in this strategy.
Is this scenario going to be possible: somebody calls sata_pmp_read()
as part of, say, hotplug polling, and after that operation completes
we then have code that calls ata_check_status() prior to the next
tf_load / command issue ? If so, they'll see the wrong cached
shadow status register.
And for that matter, is it possible for sata_pmp_read() to be called
while the link is active with another command ? Not today, it seems,
but what about when hotplug polling gets implemented ?
Mmm.. an amazing amount of complexity there for something that
ought to be very simple.
More reading to do, but comments from Tejun/others are welcomed.
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: new ata_port_operations for .pmp_{read,write} ?
Mark Lord wrote: Note that, while this does work for sata_mv, I'm still thinking about it. I'm not totally clear yet (more reading to do) as to how/when the ATA shadow/taskfile registers get updated to reflect those for the currently selected pmp.. It would seem that with other parts of libata-sff directly reading from the ctl, status, and altstatus registers during polling, command setup, and probing, that there might (?) be a loophole somewhere in this strategy. Is this scenario going to be possible: somebody calls sata_pmp_read() as part of, say, hotplug polling, and after that operation completes we then have code that calls ata_check_status() prior to the next tf_load / command issue ? If so, they'll see the wrong cached shadow status register. .. Answering my own question here: the above scenario really doesn't matter. They'll see 0x50 in the status register, and be happy regardless. Because that's what should have been there before the command issue by sata_pmp_read() in the first place. So not-a-problem. And for that matter, is it possible for sata_pmp_read() to be called while the link is active with another command ? Not today, it seems, but what about when hotplug polling gets implemented ? .. That's the one I'm most concerned about. Should I be? -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
Re: ata-piix.c (and libata.ko) in RHEL5.1 (build 78 currently) - this kernel is 2.6.18 baqsed
On Fri, Feb 22, 2008 at 09:52:45AM -0500, Richardson, Charlotte wrote: There is a hack in its probe routine that disables this. I've disabled the hack and ran a long test of hotplugs yesterday (added and removed a DVD drive connected to the ESB2 IDE - this is Intel device 0x269E) for 26 cycles, and it all appears to function properly. There are other things that do It ought to work fine for ICH4 or so and later (older ICH you can only warm plug). Be sure to test the released RHEL as I know the dev tree has completely broken all hot plug disk support and hangs a lot if you do. Jeff I assume knows the status of fixing that. - 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: automatically use DMADIR if drive/bridge requires it
Mark Lord wrote: Albert Lee wrote: Tejun Heo wrote: Back in 2.6.17-rc2, a libata module parameter was added for atapi_dmadir. That's nice, but most SATA devices which need it will tell us about it in their IDENTIFY PACKET response, as bit-15 of word-62 of the returned data (as per ATA7, ATA8 specifications). So for those which specify it, we should automatically use the DMADIR bit. Otherwise, disc writing will fail by default on many SATA-ATAPI drives. This patch adds ATA_DFLAG_DMADIR and make ata_dev_configure() set it if atapi_dmadir is set or identify data indicates DMADIR is necessary. atapi_xlat() is converted to check ATA_DFLAG_DMADIR before setting DMADIR. Original patch is from Mark Lord. Signed-off-by: Tejun Heo [EMAIL PROTECTED] Cc: Mark Lord [EMAIL PROTECTED] --- I don't have a bridge which sets DMADIR but so only checked atapi_dmadir parameter. Thanks. The patch looks good. However, it seems there is no realworld IDE-to-SATA bridge that requires DMADIR and also mangles IDENTIFY PACKET bit-15 of word-62 to indicate its presence. From the previous test of the IDE-to-SATA bridges, only the Sil 3611 requires the host software to hint on ATAPI DMADIR. But Sil 3611 doesn't mangle IDENTIFY PACKET word-62: http://www.spinics.net/lists/linux-ide/msg01514.html .. Ahh, great! We have history here! But there are more SATA bridges out there than the ones Alber has there (SiI 3611/3811, Marvell 88i8030/88SA8040, Acard ARC770, JMicron JM20330). There's the Marvell 88SA8050, and I have a funky looking thing here that says SataLink SPiF223A on it (). I wonder what it does? And how many other ones are there? The Word62 patch (from Tejun) is simple enough that the complexity point from before really doesn't hold water. I'm going to apply Tejun's patch. It's fine (as I noted I conditionally ACK'd your original patch). My opinion, though, it that this is merely coding to the spec, rather than making a bunch of real-world hardware work. All the SATA-PATA bridges I have, that support ATAPI, do not flag DMADIR. 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-piix.c (and libata.ko) in RHEL5.1 (build 78 currently) - this kernel is 2.6.18 baqsed
Alan Cox wrote: On Fri, Feb 22, 2008 at 09:52:45AM -0500, Richardson, Charlotte wrote: There is a hack in its probe routine that disables this. I've disabled the hack and ran a long test of hotplugs yesterday (added and removed a DVD drive connected to the ESB2 IDE - this is Intel device 0x269E) for 26 cycles, and it all appears to function properly. There are other things that do It ought to work fine for ICH4 or so and later (older ICH you can only warm plug). Be sure to test the released RHEL as I know the dev tree has completely broken all hot plug disk support and hangs a lot if you do. Jeff I assume knows the status of fixing that. .. I've missed the front part of this thread, but from the above message it sounds like somebody is trying to do hotplug on ICH4/5/6/.. Correct? I have previously worked on ICH5 hotplug for a client. The pieces that were needed there were: 1) Emulate SCR_STATUS reads by reading ICH5 PCS. If it indicates drive presence, return 0x113 for SCR_STATUS, otherwise return zero. 2) PCS seems to work fine for detecting *inserted* drives, but does not find *removed* drives very well. To get it to see unplug events, We had to first clear the port bit in the PCS, wait a usec, then write 0x0003 back into PCS. Then poll PCS for drive present, typically 5-6usec, sometimes longer. If not present, we're done. Otherwise wait for drive !BUSY (~60msec). Ugly as all can be, but it worked. 3) It is critical to ensure that the ATA ctl register is never written to when no drive is attached. This means bracketing the SRST sequence to first do a PCS detection before permitting the SRST. If ctl is accessed with no drive attached, the machine locks up hard. Or at least that's what we were able to figure out in the time available. What are you guys doing? -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
Re: ata-piix.c (and libata.ko) in RHEL5.1 (build 78 currently) - this kernel is 2.6.18 baqsed
3) It is critical to ensure that the ATA ctl register is never written to when no drive is attached. This means bracketing the SRST sequence to first do a PCS detection before permitting the SRST. If ctl is accessed with no drive attached, the machine locks up hard. At least for PATA you probably need to disable IORDY handshaking before the reset and probe. 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-piix.c (and libata.ko) in RHEL5.1 (build 78 currently) - this kernel is 2.6.18 baqsed
Alan Cox wrote: 3) It is critical to ensure that the ATA ctl register is never written to when no drive is attached. This means bracketing the SRST sequence to first do a PCS detection before permitting the SRST. If ctl is accessed with no drive attached, the machine locks up hard. At least for PATA you probably need to disable IORDY handshaking before the reset and probe. .. Perhaps, but this was for SATA. I don't even own any PATA disks nowadays.. other than a couple that are buried inside USB/Firewire enclosures. My last bare PATA drive died this morning, while testing a SATA bridge on it. That drive was one of the infamous IBM DeathStar series from early in the decade. R.I.P. Or pieces, actually. The platters make great unbreakable camping mirrors. :) 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: 2.6.25-rc2 + smartd = hang
Anders Eriksson wrote: Hi, Trying out 2.6.25-rc2 smartd always causes my box to hang. I can switch vt:s and the keyboard seems to work. Using sysrq-e I noticed a callpath open - ext3 - journals - sync_buffer - io_scheduel - generic_unplig_device. I'd guess the open stems from smartd. Removing smartd from the startup, I'm now using rc2 fine... I got a nice jpg showing it as well. The sysrq-e output is probably just standard ext3 journalling unrelated to the problem... what does dmesg say? lspci? What's your hardware setup? 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: 2.6.25-rc2 + smartd = hang
[EMAIL PROTECTED] said: The sysrq-e output is probably just standard ext3 journalling unrelated to the problem... what does dmesg say? lspci? What's your hardware setup? dmesg ; smartd ; dmesg yields no new entries in dmesg. It seems on disk accesses are dead. it still routes packets fine. This is an old PII-300 with 2 IDS disks and a DVD R/W. tippex ~ # lspci -vv 00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 02) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort+ SERR- PERR- INTx- Latency: 64 Region 0: Memory at e800 (32-bit, prefetchable) [size=64M] Capabilities: [a0] AGP version 1.0 Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2 Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=none Kernel driver in use: agpgart-intel Kernel modules: intel-agp 00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 I/O behind bridge: c000-cfff Memory behind bridge: eda0-efaf Prefetchable memory behind bridge: e180-e58f Secondary status: 66MHz+ FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort+ SERR- PERR- BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- Reset- FastB2B+ PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- 00:07.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) (prog-if 80 [Master]) Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 64 Region 0: [virtual] Memory at 01f0 (32-bit, non-prefetchable) [disabled] [size=8] Region 1: [virtual] Memory at 03f0 (type 3, non-prefetchable) [disabled] [size=1] Region 2: [virtual] Memory at 0170 (32-bit, non-prefetchable) [disabled] [size=8] Region 3: [virtual] Memory at 0370 (type 3, non-prefetchable) [disabled] [size=1] Region 4: I/O ports at ffa0 [size=16] Kernel driver in use: PIIX_IDE 00:07.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01) (prog-if 00 [UHCI]) Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 64 Interrupt: pin D routed to IRQ 11 Region 4: I/O ports at 6000 [size=32] Kernel driver in use: uhci_hcd Kernel modules: uhci-hcd 00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02) Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Interrupt: pin ? routed to IRQ 9 Kernel driver in use: piix4_smbus Kernel modules: i2c-piix4 00:0a.0 Network controller: RaLink RT2500 802.11g Cardbus/mini-PCI (rev 01) Subsystem: RaLink Unknown device 2560 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 64, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 10 Region 0: Memory at efffe000 (32-bit, non-prefetchable) [size=8K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: rt2500pci Kernel modules: rt2500pci 00:0b.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 05) Subsystem: Intel Corporation 82558B PRO/100+ PCI (TP) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF-
[PATCH] hpt366: fix section mismatch warnings
hpt366: fix section mismatch warnings
Fix following warnings:
WARNING: o-sparc64/vmlinux.o(.data+0x195a38): Section mismatch in reference
from the variable hpt37x_info.0 to the variable .devinit.data:hpt370
WARNING: o-sparc64/vmlinux.o(.data+0x195a40): Section mismatch in reference
from the variable hpt37x_info.0 to the variable .devinit.data:hpt370a
WARNING: o-sparc64/vmlinux.o(.data+0x195a48): Section mismatch in reference
from the variable hpt37x_info.0 to the variable .devinit.data:hpt372
WARNING: o-sparc64/vmlinux.o(.data+0x195a50): Section mismatch in reference
from the variable hpt37x_info.0 to the variable .devinit.data:hpt372n
Replace a static array with a small switch resulting in
more readable code.
Be consistent in use of __devinitconst for const data
to avoid section type conflicts.
Mark the pci table __devinitconst.
Signed-off-by: Sam Ravnborg [EMAIL PROTECTED]
Cc: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
Cc: Sergei Shtylyov [EMAIL PROTECTED]
---
Only build tested but looks obviously correct.
I saw this doing a sparc64 build - dunno whit it did not
surface when I sweeped over an x86 64 bit allyesconfig.
Sam
diff --git a/drivers/ide/pci/hpt366.c b/drivers/ide/pci/hpt366.c
index d0f7bb8..9911584 100644
--- a/drivers/ide/pci/hpt366.c
+++ b/drivers/ide/pci/hpt366.c
@@ -513,7 +513,7 @@ static struct hpt_timings hpt37x_timings = {
}
};
-static const struct hpt_info hpt36x __devinitdata = {
+static const struct hpt_info hpt36x __devinitconst = {
.chip_name = HPT36x,
.chip_type = HPT36x,
.udma_mask = HPT366_ALLOW_ATA66_3 ? (HPT366_ALLOW_ATA66_4 ?
ATA_UDMA4 : ATA_UDMA3) : ATA_UDMA2,
@@ -521,7 +521,7 @@ static const struct hpt_info hpt36x __devinitdata = {
.timings= hpt36x_timings
};
-static const struct hpt_info hpt370 __devinitdata = {
+static const struct hpt_info hpt370 __devinitconst = {
.chip_name = HPT370,
.chip_type = HPT370,
.udma_mask = HPT370_ALLOW_ATA100_5 ? ATA_UDMA5 : ATA_UDMA4,
@@ -529,7 +529,7 @@ static const struct hpt_info hpt370 __devinitdata = {
.timings= hpt37x_timings
};
-static const struct hpt_info hpt370a __devinitdata = {
+static const struct hpt_info hpt370a __devinitconst = {
.chip_name = HPT370A,
.chip_type = HPT370A,
.udma_mask = HPT370_ALLOW_ATA100_5 ? ATA_UDMA5 : ATA_UDMA4,
@@ -537,7 +537,7 @@ static const struct hpt_info hpt370a __devinitdata = {
.timings= hpt37x_timings
};
-static const struct hpt_info hpt374 __devinitdata = {
+static const struct hpt_info hpt374 __devinitconst = {
.chip_name = HPT374,
.chip_type = HPT374,
.udma_mask = ATA_UDMA5,
@@ -545,7 +545,7 @@ static const struct hpt_info hpt374 __devinitdata = {
.timings= hpt37x_timings
};
-static const struct hpt_info hpt372 __devinitdata = {
+static const struct hpt_info hpt372 __devinitconst = {
.chip_name = HPT372,
.chip_type = HPT372,
.udma_mask = HPT372_ALLOW_ATA133_6 ? ATA_UDMA6 : ATA_UDMA5,
@@ -553,7 +553,7 @@ static const struct hpt_info hpt372 __devinitdata = {
.timings= hpt37x_timings
};
-static const struct hpt_info hpt372a __devinitdata = {
+static const struct hpt_info hpt372a __devinitconst = {
.chip_name = HPT372A,
.chip_type = HPT372A,
.udma_mask = HPT372_ALLOW_ATA133_6 ? ATA_UDMA6 : ATA_UDMA5,
@@ -561,7 +561,7 @@ static const struct hpt_info hpt372a __devinitdata = {
.timings= hpt37x_timings
};
-static const struct hpt_info hpt302 __devinitdata = {
+static const struct hpt_info hpt302 __devinitconst = {
.chip_name = HPT302,
.chip_type = HPT302,
.udma_mask = HPT302_ALLOW_ATA133_6 ? ATA_UDMA6 : ATA_UDMA5,
@@ -569,7 +569,7 @@ static const struct hpt_info hpt302 __devinitdata = {
.timings= hpt37x_timings
};
-static const struct hpt_info hpt371 __devinitdata = {
+static const struct hpt_info hpt371 __devinitconst = {
.chip_name = HPT371,
.chip_type = HPT371,
.udma_mask = HPT371_ALLOW_ATA133_6 ? ATA_UDMA6 : ATA_UDMA5,
@@ -577,7 +577,7 @@ static const struct hpt_info hpt371 __devinitdata = {
.timings= hpt37x_timings
};
-static const struct hpt_info hpt372n __devinitdata = {
+static const struct hpt_info hpt372n __devinitconst = {
.chip_name = HPT372N,
.chip_type = HPT372N,
.udma_mask = HPT372_ALLOW_ATA133_6 ? ATA_UDMA6 : ATA_UDMA5,
@@ -585,7 +585,7 @@ static const struct hpt_info hpt372n __devinitdata = {
.timings= hpt37x_timings
};
-static const struct hpt_info hpt302n __devinitdata = {
+static const struct hpt_info hpt302n __devinitconst = {
.chip_name = HPT302N,
.chip_type = HPT302N,
.udma_mask =
Re: [MCP-55] IDE problem after bios update
On Fri, 22 Feb 2008 20:57:54 +0100 Daniel Schroeder [EMAIL PROTECTED] wrote: hi there, this is an asus m2n32-sli deluxe with nvidia chipset. After updating the bios from 1503 to 1701 following in dmesg, and ide drive doesn't work. Kernel is 2.6.24.2 If it broke with the BIOS change you need to report it to the BIOS vendor Feb 21 22:37:02 isla-magica NFORCE-MCP55: IDE port disabled - 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
[MCP-55] IDE problem after bios update
hi there,
this is an asus m2n32-sli deluxe with nvidia chipset. After updating the
bios from 1503 to 1701 following in dmesg, and ide drive doesn't work.
Kernel is 2.6.24.2
dmesg
..snip...
Feb 21 22:37:02 isla-magica Uniform Multi-Platform E-IDE driver
Revision: 7.00alpha2
Feb 21 22:37:02 isla-magica ide: Assuming 33MHz system bus speed for PIO
modes; override with idebus=xx
Feb 21 22:37:02 isla-magica NFORCE-MCP55: IDE controller (0x10de:0x036e
rev 0xa1) at PCI slot :00:0c.0
Feb 21 22:37:02 isla-magica NFORCE-MCP55: not 100% native mode: will
probe irqs later
Feb 21 22:37:02 isla-magica NFORCE-MCP55: :00:0c.0 (rev a1) UDMA133
controller
Feb 21 22:37:02 isla-magica ide0: BM-DMA at 0xf400-0xf407, BIOS
settings: hda:DMA, hdb:DMA
Feb 21 22:37:02 isla-magica NFORCE-MCP55: IDE port disabled
Feb 21 22:37:02 isla-magica Probing IDE interface ide0...
Feb 21 22:37:02 isla-magica hda: PLEXTOR DVDR PX-740A, ATAPI CD/DVD-ROM
drive
Feb 21 22:37:02 isla-magica hda: host max PIO5 wanted PIO255(auto-tune)
selected PIO4
Feb 21 22:37:02 isla-magica hda: UDMA/33 mode selected
Feb 21 22:37:02 isla-magica ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Feb 21 22:37:02 isla-magica hda: lost interrupt
Feb 21 22:37:02 isla-magica hda: task_in_intr: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Feb 21 22:37:02 isla-magica hda: task_in_intr: error=0x00 { }
Feb 21 22:37:02 isla-magica ide: failed opcode was: 0xa1
Feb 21 22:37:02 isla-magica Probing IDE interface ide1...
Feb 21 22:37:02 isla-magica hda: status error: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Feb 21 22:37:02 isla-magica hda: status error: error=0x00 { }
Feb 21 22:37:02 isla-magica ide: failed opcode was: unknown
Feb 21 22:37:02 isla-magica hda: drive not ready for command
Feb 21 22:37:02 isla-magica hda: ATAPI CD-ROM drive, 0kB Cache
Feb 21 22:37:02 isla-magica Uniform CD-ROM driver Revision: 3.20
Feb 21 22:37:02 isla-magica hda: status error: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Feb 21 22:37:02 isla-magica hda: status error: error=0x00 { }
Feb 21 22:37:02 isla-magica ide: failed opcode was: unknown
Feb 21 22:37:02 isla-magica hda: drive not ready for command
Feb 21 22:37:02 isla-magica hda: status error: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Feb 21 22:37:02 isla-magica hda: status error: error=0x00 { }
Feb 21 22:37:02 isla-magica ide: failed opcode was: unknown
Feb 21 22:37:02 isla-magica hda: drive not ready for command
Feb 21 22:37:02 isla-magica hda: status error: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Feb 21 22:37:02 isla-magica hda: status error: error=0x00 { }
Feb 21 22:37:02 isla-magica ide: failed opcode was: unknown
Feb 21 22:37:02 isla-magica hda: drive not ready for command
Feb 21 22:37:02 isla-magica hda: status error: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Feb 21 22:37:02 isla-magica hda: status error: error=0x00 { }
Feb 21 22:37:02 isla-magica ide: failed opcode was: unknown
Feb 21 22:37:02 isla-magica hda: drive not ready for command
Feb 21 22:37:02 isla-magica hda: status error: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Feb 21 22:37:02 isla-magica hda: status error: error=0x00 { }
Feb 21 22:37:02 isla-magica ide: failed opcode was: unknown
Feb 21 22:37:02 isla-magica hda: drive not ready for command
Feb 21 22:37:02 isla-magica hda: status error: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Feb 21 22:37:02 isla-magica hda: status error: error=0x00 { }
Feb 21 22:37:02 isla-magica ide: failed opcode was: unknown
Feb 21 22:37:02 isla-magica hda: drive not ready for command
Feb 21 22:37:02 isla-magica hda: status error: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Feb 21 22:37:02 isla-magica hda: status error: error=0x00 { }
Feb 21 22:37:02 isla-magica ide: failed opcode was: unknown
Feb 21 22:37:02 isla-magica hda: drive not ready for command
Feb 21 22:37:02 isla-magica Driver 'sd' needs updating - please use
bus_type methods
Feb 21 22:37:02 isla-magica Driver 'sr' needs updating - please use
bus_type methods
Feb 21 22:37:02 isla-magica sata_sil24 :02:00.0: version 1.1
...snip...
/dmesg
tia
daniel
-
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] hpt366: fix section mismatch warnings
Sam Ravnborg wrote: hpt366: fix section mismatch warnings Fix following warnings: WARNING: o-sparc64/vmlinux.o(.data+0x195a38): Section mismatch in reference from the variable hpt37x_info.0 to the variable .devinit.data:hpt370 WARNING: o-sparc64/vmlinux.o(.data+0x195a40): Section mismatch in reference from the variable hpt37x_info.0 to the variable .devinit.data:hpt370a WARNING: o-sparc64/vmlinux.o(.data+0x195a48): Section mismatch in reference from the variable hpt37x_info.0 to the variable .devinit.data:hpt372 WARNING: o-sparc64/vmlinux.o(.data+0x195a50): Section mismatch in reference from the variable hpt37x_info.0 to the variable .devinit.data:hpt372n Replace a static array with a small switch resulting in more readable code. Be consistent in use of __devinitconst for const data to avoid section type conflicts. Mark the pci table __devinitconst. Signed-off-by: Sam Ravnborg [EMAIL PROTECTED] Acked-by: Sergei Shtylyov [EMAIL PROTECTED] 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: [PATCH] hpt366: fix section mismatch warnings
@@ -1570,11 +1570,13 @@ static int __devinit hpt366_init_one(struct pci_dev
*dev, const struct pci_devic
if (rev 3)
info = hpt36x;
else {
- static const struct hpt_info *hpt37x_info[] =
- { hpt370, hpt370a, hpt372, hpt372n };
-
- info = hpt37x_info[min_t(u8, rev, 6) - 3];
- idx++;
+ switch (min_t(u8, rev, 6) - 3) {
+ case 0: info = hpt370; break;
+ case 1: info = hpt370a; break;
+ case 2: info = hpt372; break;
+ case 3: info = hpt372n; break;
+ }
+ idx++;
}
I kept the calculation as it was before but the '- 3'
is not needed. So it could be fixed and the case N:
should then be updated.
[Thanks to Sergei to not this]
Another note: The warnings were seen with a
make CONFIG_DEBUG_SECTION_MISMATCH=y build so they most likely
does not show up duing a typical build due to the inlining performed
by gcc.
Sam
-
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] hpt366: fix section mismatch warnings
On Friday 22 February 2008, Sergei Shtylyov wrote: Sam Ravnborg wrote: hpt366: fix section mismatch warnings Fix following warnings: WARNING: o-sparc64/vmlinux.o(.data+0x195a38): Section mismatch in reference from the variable hpt37x_info.0 to the variable .devinit.data:hpt370 WARNING: o-sparc64/vmlinux.o(.data+0x195a40): Section mismatch in reference from the variable hpt37x_info.0 to the variable .devinit.data:hpt370a WARNING: o-sparc64/vmlinux.o(.data+0x195a48): Section mismatch in reference from the variable hpt37x_info.0 to the variable .devinit.data:hpt372 WARNING: o-sparc64/vmlinux.o(.data+0x195a50): Section mismatch in reference from the variable hpt37x_info.0 to the variable .devinit.data:hpt372n Replace a static array with a small switch resulting in more readable code. Be consistent in use of __devinitconst for const data to avoid section type conflicts. Mark the pci table __devinitconst. Signed-off-by: Sam Ravnborg [EMAIL PROTECTED] Acked-by: Sergei Shtylyov [EMAIL PROTECTED] applied - 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-core: fix kernel-doc warning
From: Randy Dunlap [EMAIL PROTECTED] Fix libata-core kernel-doc warning: Warning(linux-2.6.25-rc2-git6//drivers/ata/libata-core.c:168): No description found for parameter 'ap' Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- drivers/ata/libata-core.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-2.6.25-rc2-git6.orig/drivers/ata/libata-core.c +++ linux-2.6.25-rc2-git6/drivers/ata/libata-core.c @@ -153,7 +153,7 @@ MODULE_VERSION(DRV_VERSION); /** * ata_force_cbl - force cable type according to libata.force - * @link: ATA link of interest + * @ap: ATA port of interest * * Force cable type according to libata.force and whine about it. * The last entry which has matching port number is used, so it - 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_ram driver
I've ported the scsi_ram driver [1] to libata. It could use a lot more
work -- there's a lot of stuff in the identify page that I haven't
filled in, and there's a lot of commands it doesn't even try to execute.
For example, when you unload the driver, you get the mildly disturbing
messages:
sd 12:0:0:0: [sdb] Stopping disk
sd 12:0:0:0: [sdb] START_STOP FAILED
sd 12:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
However, it's still useful at the current stage of development, so I
thought it was worth posting to get some feedback.
[1] http://marc.info/?l=linux-scsim=120331663227540w=2
Signed-off-by: Matthew Wilcox [EMAIL PROTECTED]
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index ba8f7f4..a3dfb50 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -40,6 +40,9 @@ config ATA_ACPI
You can disable this at kernel boot time by using the
option libata.noacpi=1
+config ATA_RAM
+ tristate ATA RAM driver
+
config SATA_AHCI
tristate AHCI SATA support
depends on PCI
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index 701651e..a0a5a8c 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -77,6 +77,9 @@ obj-$(CONFIG_ATA_GENERIC) += ata_generic.o
# Should be last libata driver
obj-$(CONFIG_PATA_LEGACY) += pata_legacy.o
+# A fake ata driver. Can it be postultimate?
+obj-$(CONFIG_ATA_RAM) += ata_ram.o
+
libata-objs:= libata-core.o libata-scsi.o libata-sff.o libata-eh.o \
libata-pmp.o
libata-$(CONFIG_ATA_ACPI) += libata-acpi.o
diff --git a/drivers/ata/ata_ram.c b/drivers/ata/ata_ram.c
new file mode 100644
index 000..7935bd1
--- /dev/null
+++ b/drivers/ata/ata_ram.c
@@ -0,0 +1,674 @@
+/*
+ * ata_ram.c - A RAM-based ATA driver for Linux
+ *
+ * This driver is intended to run as fast as possible, hence the options
+ * to discard writes and reads.
+ * By default, it'll allocate half a gigabyte of RAM to use as a ramdisc;
+ * you can change this with the `capacity' module parameter.
+ *
+ * (C) Copyright 2007-2008 Intel Corporation
+ * Author: Matthew Wilcox [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2
+ * of the License.
+ */
+
+#undef DEBUG
+
+#include linux/init.h
+#include linux/kernel.h
+#include linux/kthread.h
+#include linux/libata.h
+#include linux/list.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/scatterlist.h
+#include linux/spinlock.h
+
+#include scsi/scsi.h
+#include scsi/scsi_cmnd.h
+#include scsi/scsi_device.h
+#include scsi/scsi_host.h
+#include scsi/scsi_dbg.h
+
+MODULE_LICENSE(GPL v2);
+MODULE_AUTHOR(Matthew Wilcox [EMAIL PROTECTED]);
+
+#define DRV_NAME ata_ram
+
+static unsigned int sector_size = 512;
+module_param(sector_size, uint, 0444);
+MODULE_PARM_DESC(sector_size, Size of sectors);
+
+static unsigned int capacity = 1024 * 1024;
+module_param(capacity, uint, 0444);
+MODULE_PARM_DESC(capacity, Number of logical blocks in device);
+
+static int throw_away_writes;
+module_param(throw_away_writes, int, 0644);
+MODULE_PARM_DESC(throw_away_writes, Discard all writes to the device);
+
+static int throw_away_reads;
+module_param(throw_away_reads, int, 0644);
+MODULE_PARM_DESC(throw_away_reads, Don't actually read data from the device);
+
+
+struct ata_ram_host {
+ struct ata_host *host;
+ struct ata_queued_cmd *cmds[ATA_MAX_QUEUE];
+ int first, last;
+ struct task_struct *thread;
+ struct ata_taskfile shadow_tf;
+};
+
+static void copy_buffer(struct ata_queued_cmd *qc, char *buf, int len)
+{
+ char *p;
+ struct scatterlist *sg;
+ unsigned int i;
+
+ for_each_sg(qc-sg, sg, qc-n_elem, i) {
+ int tocopy = sg-length;
+ if (tocopy len)
+ tocopy = len;
+
+ p = kmap_atomic(sg_page(sg), KM_USER0);
+ memcpy(p + sg-offset, buf, tocopy);
+ kunmap_atomic(p, KM_USER0);
+
+ len -= tocopy;
+ if (!len)
+ break;
+ buf += tocopy;
+ }
+}
+
+static void ata_ram_setup_result(struct ata_queued_cmd *qc)
+{
+ struct ata_ram_host *arhost = qc-ap-private_data;
+ arhost-shadow_tf.flags = ATA_TFLAG_LBA48 | ATA_TFLAG_LBA;
+ arhost-shadow_tf.protocol = ATA_PROT_DMA;
+ arhost-shadow_tf.ctl = 0;
+ arhost-shadow_tf.feature = 0;
+ arhost-shadow_tf.device = 0;
+ arhost-shadow_tf.command = 0;
+}
+
+static void ata_put_dword(u16 *d, u32 v)
+{
+ d[0] = cpu_to_le16(v 0x);
+ d[1] = cpu_to_le16(v 16);
+}
+
+static u32 ata_get_lba_28(struct ata_taskfile *tf)
+{
+ return tf-lbal | (tf-lbam 8) | (tf-lbah 16);
+}
+
+static u64 ata_get_lba_48(struct ata_taskfile *tf)
+{
+ return tf-lbal |
[PATCH] qd65xx: remove commented out code
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/legacy/qd65xx.c | 37 -
1 file changed, 37 deletions(-)
Index: b/drivers/ide/legacy/qd65xx.c
===
--- a/drivers/ide/legacy/qd65xx.c
+++ b/drivers/ide/legacy/qd65xx.c
@@ -334,43 +334,6 @@ static void __init qd6580_port_init_devs
hwif-drives[1].drive_data = t2;
}
-/*
- * qd_unsetup:
- *
- * called to unsetup an ata channel : back to default values, unlinks tuning
- */
-/*
-static void __exit qd_unsetup(ide_hwif_t *hwif)
-{
- u8 config = hwif-config_data;
- int base = hwif-select_data;
- void *set_pio_mode = (void *)hwif-set_pio_mode;
-
- if (hwif-chipset != ide_qd65xx)
- return;
-
- printk(KERN_NOTICE %s: back to defaults\n, hwif-name);
-
- hwif-selectproc = NULL;
- hwif-set_pio_mode = NULL;
-
- if (set_pio_mode == (void *)qd6500_set_pio_mode) {
- // will do it for both
- outb(QD6500_DEF_DATA, QD_TIMREG(hwif-drives[0]));
- } else if (set_pio_mode == (void *)qd6580_set_pio_mode) {
- if (QD_CONTROL(hwif) QD_CONTR_SEC_DISABLED) {
- outb(QD6580_DEF_DATA, QD_TIMREG(hwif-drives[0]));
- outb(QD6580_DEF_DATA2, QD_TIMREG(hwif-drives[1]));
- } else {
- outb(hwif-channel ? QD6580_DEF_DATA2 :
QD6580_DEF_DATA, QD_TIMREG(hwif-drives[0]));
- }
- } else {
- printk(KERN_WARNING Unknown qd65xx tuning fonction !\n);
- printk(KERN_WARNING keeping settings !\n);
- }
-}
-*/
-
static const struct ide_port_info qd65xx_port_info __initdata = {
.chipset= ide_qd65xx,
.host_flags = IDE_HFLAG_IO_32BIT |
-
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: remove stale comments from ide-dma.c
- ide-dma.c is not a separate module - ide-dma.c is not PCI specific anymore - DMA is enabled by default nowadays - link for Intel Zappa BIOS is dead etc. Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] --- drivers/ide/ide-dma.c | 48 1 file changed, 48 deletions(-) Index: b/drivers/ide/ide-dma.c === --- a/drivers/ide/ide-dma.c +++ b/drivers/ide/ide-dma.c @@ -11,49 +11,6 @@ */ /* - * This module provides support for the bus-master IDE DMA functions - * of various PCI chipsets, including the Intel PIIX (i82371FB for - * the 430 FX chipset), the PIIX3 (i82371SB for the 430 HX/VX and - * 440 chipsets), and the PIIX4 (i82371AB for the 430 TX chipset) - * (PIIX stands for PCI ISA IDE Xcellerator). - * - * Pretty much the same code works for other IDE PCI bus-mastering chipsets. - * - * DMA is supported for all IDE devices (disk drives, cdroms, tapes, floppies). - * - * By default, DMA support is prepared for use, but is currently enabled only - * for drives which already have DMA enabled (UltraDMA or mode 2 multi/single), - * or which are recognized as good (see table below). Drives with only mode0 - * or mode1 (multi/single) DMA should also work with this chipset/driver - * (eg. MC2112A) but are not enabled by default. - * - * Use hdparm -i to view modes supported by a given drive. - * - * The hdparm-3.5 (or later) utility can be used for manually enabling/disabling - * DMA support, but must be (re-)compiled against this kernel version or later. - * - * To enable DMA, use hdparm -d1 /dev/hd? on a per-drive basis after booting. - * If problems arise, ide.c will disable DMA operation after a few retries. - * This error recovery mechanism works and has been extremely well exercised. - * - * IDE drives, depending on their vintage, may support several different modes - * of DMA operation. The boot-time modes are indicated with a * in - * the hdparm -i listing, and can be changed with *knowledgeable* use of - * the hdparm -X feature. There is seldom a need to do this, as drives - * normally power-up with their best PIO/DMA modes enabled. - * - * Testing has been done with a rather extensive number of drives, - * with Quantum Western Digital models generally outperforming the pack, - * and Fujitsu Conner (and some Seagate which are really Conner) drives - * showing more lackluster throughput. - * - * Keep an eye on /var/adm/messages for DMA disabled messages. - * - * Some people have reported trouble with Intel Zappa motherboards. - * This can be fixed by upgrading the AMI BIOS to version 1.00.04.BS0, - * available from ftp://ftp.intel.com/pub/bios/10004bs0.exe - * (thanks to Glen Morrell [EMAIL PROTECTED] for researching this). - * * Thanks to Christopher J. Reimer [EMAIL PROTECTED] for * fixing the problem with the BIOS on some Acer motherboards. * @@ -65,11 +22,6 @@ * * Most importantly, thanks to Robert Bringman [EMAIL PROTECTED] * for supplying a Promise UDMA board WD UDMA drive for this work! - * - * And, yes, Intel Zappa boards really *do* use both PIIX IDE ports. - * - * ATA-66/100 and recovery functions, I forgot the rest.. - * */ #include linux/module.h - 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: remove ide-tape documentation from Documentation/ide.txt
More complete documentation is available in Documentation/ide/ide-tape.txt. Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] --- Documentation/ide.txt | 47 --- 1 file changed, 47 deletions(-) Index: b/Documentation/ide.txt === --- a/Documentation/ide.txt +++ b/Documentation/ide.txt @@ -279,53 +279,6 @@ You also need to use probe kernel para -IDE ATAPI streaming tape driver - -This driver is a part of the Linux ide driver and works in co-operation -with linux/drivers/block/ide.c. - -The driver, in co-operation with ide.c, basically traverses the -request-list for the block device interface. The character device -interface, on the other hand, creates new requests, adds them -to the request-list of the block device, and waits for their completion. - -Pipelined operation mode is now supported on both reads and writes. - -The block device major and minor numbers are determined from the -tape's relative position in the ide interfaces, as explained in ide.c. - -The character device interface consists of the following devices: - - ht0 major 37, minor 0 first IDE tape, rewind on close. - ht1 major 37, minor 1 second IDE tape, rewind on close. - ... - nht0 major 37, minor 128 first IDE tape, no rewind on close. - nht1 major 37, minor 129 second IDE tape, no rewind on close. - ... - -Run /dev/MAKEDEV to create the above entries. - -The general magnetic tape commands compatible interface, as defined by -include/linux/mtio.h, is accessible through the character device. - -General ide driver configuration options, such as the interrupt-unmask -flag, can be configured by issuing an ioctl to the block device interface, -as any other ide device. - -Our own ide-tape ioctl's can be issued to either the block device or -the character device interface. - -Maximal throughput with minimal bus load will usually be achieved in the -following scenario: - - 1. ide-tape is operating in the pipelined operation mode. - 2. No buffering is performed by the user backup program. - - - - - Some Terminology IDE = Integrated Drive Electronics, meaning that each drive has a built-in - 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.25-rc2 + smartd = hang
Anders Eriksson wrote: [EMAIL PROTECTED] said: The sysrq-e output is probably just standard ext3 journalling unrelated to the problem... what does dmesg say? lspci? What's your hardware setup? dmesg ; smartd ; dmesg yields no new entries in dmesg. It seems on disk accesses are dead. it still routes packets fine. This is an old PII-300 with 2 IDS disks and a DVD R/W. ... Feb 22 17:38:49 tippex Uniform Multi-Platform E-IDE driver Feb 22 17:38:49 tippex ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx Feb 22 17:38:49 tippex PIIX4: IDE controller (0x8086:0x7111 rev 0x01) at PCI slot :00:07.1 Feb 22 17:38:49 tippex PIIX4: not 100% native mode: will probe irqs later Feb 22 17:38:49 tippex ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:PIO Feb 22 17:38:49 tippex ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:PIO, hdd:PIO Feb 22 17:38:49 tippex Probing IDE interface ide0... Feb 22 17:38:49 tippex hdb: IC35L120AVV207-0, ATA DISK drive Feb 22 17:38:49 tippex hda: IBM-DTTA-371010, ATA DISK drive Feb 22 17:38:49 tippex hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4 Feb 22 17:38:49 tippex hda: UDMA/33 mode selected Feb 22 17:38:49 tippex hdb: host max PIO4 wanted PIO255(auto-tune) selected PIO4 Feb 22 17:38:49 tippex hdb: UDMA/33 mode selected Feb 22 17:38:49 tippex Probing IDE interface ide1... Feb 22 17:38:49 tippex hdd: Maxtor 6L250R0, ATA DISK drive Feb 22 17:38:49 tippex hdc: AOPEN DUW1608/ARR, ATAPI CD/DVD-ROM drive Feb 22 17:38:49 tippex hdc: host max PIO4 wanted PIO255(auto-tune) selected PIO4 Feb 22 17:38:49 tippex hdc: UDMA/33 mode selected Feb 22 17:38:49 tippex hdd: host max PIO4 wanted PIO255(auto-tune) selected PIO4 Feb 22 17:38:49 tippex hdd: UDMA/33 mode selected Feb 22 17:38:49 tippex ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Feb 22 17:38:49 tippex ide1 at 0x170-0x177,0x376 on irq 15 .. So that's using the old IDE drivers. And the network and USB are sharing IRQ#11 with each other. If you are going to be using newer kernels like this (2.6.23+), then you might consider shifting those drives over to libata drivers. This involves a little bit of work -- building a kernel with libata and ata_piix built-in instead of the old IDE drivers, and then rearranging /etc/fstab to match the new device names (eg. /dev/sda instead of /dev/hda). But at this point libata is working much better than the old IDE stuff, and it really is worth moving things over if you can. 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: 2.6.25-rc2 + smartd = hang
[EMAIL PROTECTED] said: So that's using the old IDE drivers. And the network and USB are sharing IRQ#11 with each other. If you are going to be using newer kernels like this (2.6.23+), then you might consider shifting those drives over to libata drivers. This involves a little bit of work -- building a kernel with libata and ata_piix built-in instead of the old IDE drivers, and then rearranging /etc/ fstab to match the new device names (eg. /dev/sda instead of /dev/hda). But at this point libata is working much better than the old IDE stuff, and it really is worth moving things over if you can. Ok, I'll take a stab at that tomorrow. Two things... Is smartd prepared to handle /dev/sdX style devices? If this is the prefered driver these days, maybe it shouldn't be marked experimental in the menu anymore? /A - 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.25-rc2 + smartd = hang
Anders Eriksson wrote: Is smartd prepared to handle /dev/sdX style devices? Yes. You need to pass -d ata to smartd and smartctl, if your scripts are not already doing so. If this is the prefered driver these days, maybe it shouldn't be marked experimental in the menu anymore? It's not marked experimental. 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
[PATCH] ide: remove redundant comment from ide_unregister()
Identical comment is present in ide_hwif_release_regions() documentation. Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] --- goes after hpt366: fix section mismatch warnings patch in IDE quilt tree drivers/ide/ide.c |5 - 1 file changed, 5 deletions(-) Index: b/drivers/ide/ide.c === --- a/drivers/ide/ide.c +++ b/drivers/ide/ide.c @@ -590,11 +590,6 @@ void ide_unregister(unsigned int index, hwif-extra_ports = 0; } - /* -* Note that we only release the standard ports, -* and do not even try to handle any extra ports -* allocated for weird IDE interface chipsets. -*/ ide_hwif_release_regions(hwif); /* copy original settings */ - 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: skip probing port if hdx=noprobe was used for both devices on it
* Skip probing port if hdx=noprobe parameter was used for both devices on it.
* Obsolete idex=noprobe parameter - it only works for ide_generic, cmd640
and PCI hosts in Compatibility mode (on alpha/x86/ia64/m32r/mips/ppc32).
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
goes after ide: remove redundant comment from ide_unregister() patch
in IDE quilt tree
Documentation/ide.txt|2 --
drivers/ide/ide-probe.c |3 ++-
drivers/ide/ide.c|2 +-
drivers/ide/pci/cmd640.c |3 ++-
4 files changed, 5 insertions(+), 5 deletions(-)
Index: b/Documentation/ide.txt
===
--- a/Documentation/ide.txt
+++ b/Documentation/ide.txt
@@ -258,8 +258,6 @@ Summary of ide driver parameters for ker
As for VLB, it is safest to not specify it.
Bigger values are safer than smaller ones.
- idex=noprobe: do not attempt to access/use this interface
-
idex=base : probe for an interface at the addr specified,
where base is usually 0x1f0 or 0x170
and ctl is assumed to be base+0x206
Index: b/drivers/ide/ide-probe.c
===
--- a/drivers/ide/ide-probe.c
+++ b/drivers/ide/ide-probe.c
@@ -756,7 +756,8 @@ static int ide_probe_port(ide_hwif_t *hw
BUG_ON(hwif-present);
- if (hwif-noprobe)
+ if (hwif-noprobe ||
+ (hwif-drives[0].noprobe hwif-drives[1].noprobe))
return -EACCES;
/*
Index: b/drivers/ide/ide.c
===
--- a/drivers/ide/ide.c
+++ b/drivers/ide/ide.c
@@ -1444,7 +1444,7 @@ static int __init ide_setup(char *s)
case -1: /* noprobe */
hwif-noprobe = 1;
- goto done;
+ goto obsolete_option;
case 1: /* base */
vals[1] = vals[0] + 0x206; /* default ctl */
Index: b/drivers/ide/pci/cmd640.c
===
--- a/drivers/ide/pci/cmd640.c
+++ b/drivers/ide/pci/cmd640.c
@@ -787,7 +787,8 @@ static int __init cmd640x_init(void)
/*
* Try to enable the secondary interface, if not already enabled
*/
- if (cmd_hwif1-noprobe) {
+ if (cmd_hwif1-noprobe ||
+ (cmd_hwif1-drives[0].noprobe cmd_hwif1-drives[1].noprobe)) {
port2 = not probed;
} else {
b = get_cmd640_reg(CNTRL);
-
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: remove obsoleted idex=noprobe kernel parameter
* Remove obsoleted idex=noprobe kernel parameter.
* Remove no longer needed hwif-noprobe quirk from ide_hwif_configure()
and hwif-noprobe checking from cmd640.c.
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
goes before ide: move default IDE ports setup to ide_generic host driver
patch in IDE quilt tree
drivers/ide/ide.c|6 ++
drivers/ide/pci/cmd640.c |3 +--
drivers/ide/setup-pci.c |7 ---
3 files changed, 3 insertions(+), 13 deletions(-)
Index: b/drivers/ide/ide.c
===
--- a/drivers/ide/ide.c
+++ b/drivers/ide/ide.c
@@ -1144,7 +1144,7 @@ static int __init ide_setup(char *s)
* (-8, -9, -10) are reserved to ease the hardcoding.
*/
static const char *ide_words[] = {
- noprobe, serialize, minus3, minus4,
+ minus1, serialize, minus3, minus4,
reset, minus6, ata66, minus8, minus9,
minus10, four, qd65xx, ht6560b, cmd640_vlb,
dtc2278, umc8672, ali14xx, NULL };
@@ -1236,9 +1236,7 @@ static int __init ide_setup(char *s)
hwif-serialized = hwif-mate-serialized = 1;
goto obsolete_option;
- case -1: /* noprobe */
- hwif-noprobe = 1;
- goto obsolete_option;
+ case -1:
case 0:
case 1:
case 2:
Index: b/drivers/ide/pci/cmd640.c
===
--- a/drivers/ide/pci/cmd640.c
+++ b/drivers/ide/pci/cmd640.c
@@ -789,8 +789,7 @@ static int __init cmd640x_init(void)
/*
* Try to enable the secondary interface, if not already enabled
*/
- if (cmd_hwif1-noprobe ||
- (cmd_hwif1-drives[0].noprobe cmd_hwif1-drives[1].noprobe)) {
+ if (cmd_hwif1-drives[0].noprobe cmd_hwif1-drives[1].noprobe) {
port2 = not probed;
} else {
b = get_cmd640_reg(CNTRL);
Index: b/drivers/ide/setup-pci.c
===
--- a/drivers/ide/setup-pci.c
+++ b/drivers/ide/setup-pci.c
@@ -345,7 +345,6 @@ static ide_hwif_t *ide_hwif_configure(st
unsigned long ctl = 0, base = 0;
ide_hwif_t *hwif;
u8 bootable = (d-host_flags IDE_HFLAG_BOOTABLE) ? 1 : 0;
- u8 oldnoprobe = 0;
struct hw_regs_s hw;
if ((d-host_flags IDE_HFLAG_ISA_PORTS) == 0) {
@@ -376,14 +375,8 @@ static ide_hwif_t *ide_hwif_configure(st
hw.chipset = d-chipset ? d-chipset : ide_pci;
ide_std_init_ports(hw, base, ctl | 2);
- if (hwif-io_ports[IDE_DATA_OFFSET] == base
- hwif-io_ports[IDE_CONTROL_OFFSET] == (ctl | 2))
- oldnoprobe = hwif-noprobe;
-
ide_init_port_hw(hwif, hw);
- hwif-noprobe = oldnoprobe;
-
hwif-dev = dev-dev;
hwif-cds = d;
-
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] ide: remove stale comments from ide-dma.c
On Friday 22 February 2008, Mark Lord wrote: Bartlomiej Zolnierkiewicz wrote: - ide-dma.c is not a separate module - ide-dma.c is not PCI specific anymore - DMA is enabled by default nowadays - link for Intel Zappa BIOS is dead etc. Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] --- drivers/ide/ide-dma.c | 48 1 file changed, 48 deletions(-) Index: b/drivers/ide/ide-dma.c === --- a/drivers/ide/ide-dma.c +++ b/drivers/ide/ide-dma.c @@ -11,49 +11,6 @@ */ /* - * This module provides support for the bus-master IDE DMA functions - * of various PCI chipsets, including the Intel PIIX (i82371FB for - * the 430 FX chipset), the PIIX3 (i82371SB for the 430 HX/VX and - * 440 chipsets), and the PIIX4 (i82371AB for the 430 TX chipset) - * (PIIX stands for PCI ISA IDE Xcellerator). - * - * Pretty much the same code works for other IDE PCI bus-mastering chipsets. - * - * DMA is supported for all IDE devices (disk drives, cdroms, tapes, floppies). .. Those top comments still look relevant, or at least as relevant as the rest of the file (and subsystem) itself. :) Sigh. ide-dma.c supports _much_ more than IDE PCI BM-DMA nowadays :) [ hmm, it probably makes sense to split CONFIG_BLK_DEV_IDEDMA_SFF code to a separate file (ide-dma-sff.c?) so ide-dma.c would contain only generic code ] anyway here goes take 2: [...] v2: * Some comments should be preserved. (Noticed by Mark Lord) Cc: Mark Lord [EMAIL PROTECTED] [...] interdiff: diff -u b/drivers/ide/ide-dma.c b/drivers/ide/ide-dma.c --- b/drivers/ide/ide-dma.c +++ b/drivers/ide/ide-dma.c @@ -1,9 +1,13 @@ /* + * IDE DMA support (including IDE PCI BM-DMA). + * * Copyright (C) 1995-1998 Mark Lord * Copyright (C) 1999-2000 Andre Hedrick [EMAIL PROTECTED] * Copyright (C) 2004, 2007 Bartlomiej Zolnierkiewicz * * May be copied or modified under the terms of the GNU General Public License + * + * DMA is supported for all IDE devices (disk drives, cdroms, tapes, floppies). */ /* - 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: new ata_port_operations for .pmp_{read,write} ?
Mark Lord wrote: Mark Lord wrote: ... And for that matter, is it possible for sata_pmp_read() to be called while the link is active with another command ? Not today, it seems, but what about when hotplug polling gets implemented ? .. That's the one I'm most concerned about. Should I be? ... Tejun, On a related note, I'm now looking into PMP error handling in the driver. The obvious thing I see that I want to fix, is that after a media error on any PMP attached drive, I get this: ata20.00: failed to read SCR 1 (Emask=0x40) ata20.01: failed to read SCR 1 (Emask=0x40) ata20.02: failed to read SCR 1 (Emask=0x40) ata20.03: failed to read SCR 1 (Emask=0x40) ata20.04: failed to read SCR 1 (Emask=0x40) Okay, so those are from sata_pmp_read(), which cannot even issue it's commands because the port was frozen by the EH. Is this expected? I'm not entirely clear what to do in the EH for this driver. The chipset docs say that after just about any kind of error software must do a hard reset of the channel to make it usable again. But I suspect that PIO commands may be okay before that, and sata_pmp_read() is trying to issue a PIO command. How to resolve this? - 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] AMD SB700/SB800 SATA support 64bit DMA
Shane Huang wrote: Jeff and Tejun: I'm using my private mailbox to submit it before I set up the connection to our exchange mail server under linux. Please check whether this patch can be accepted. Patch looks fine to me. -- 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: new ata_port_operations for .pmp_{read,write} ?
Hello, Mark. Mark Lord wrote: This patch provides two new struct ata_port_operations methods for this, and modifies the code in libata-pmp to use them if provided. ... Note that, while this does work for sata_mv, I'm still thinking about it. I'm not totally clear yet (more reading to do) as to how/when the ATA shadow/taskfile registers get updated to reflect those for the currently selected pmp.. It would seem that with other parts of libata-sff directly reading from the ctl, status, and altstatus registers during polling, command setup, and probing, that there might (?) be a loophole somewhere in this strategy. Yeah, this is an interesting problem. There are basically multiple sets of TF registers and the SFF way of assuming single set doesn't really work well and I don't really think adding -pmp_read/write is the correct long term solution to the problem. We need to confine direct TF register accesses to SFF layer only as controllers which don't implement SFF interface may or may not emulate TF registers and even when they do, it sometimes can't really match the SFF behavior. For command execution, TF write is already performed by qc_prep and issue and TF read back should be performed by LLD if RESULT_TF is set. For EH, the reset methods should be responsible whether or how the TF registers are accessed. Mark, for your case, I think the correct thing to do is to factor out the necessary bare-bone part from SFF implementation and use it with necessary PMP register setup once the necessary change is made to the core layer. The controller is NOT a SFF one and I don't think stretching SFF implementation to fit mv's PMP-aware emulation of it is a good idea. Maybe we can fit libata to it but it's likely we'll need to modify it again to fit different emulation from different vendor. Is this scenario going to be possible: somebody calls sata_pmp_read() as part of, say, hotplug polling, and after that operation completes we then have code that calls ata_check_status() prior to the next tf_load / command issue ? If so, they'll see the wrong cached shadow status register. I think what should happen is that any of TF registers isn't accessed behind LLD's back. Then, you don't have nothing to worry about. If the controller emulates some of SFF interface, you can always properly wrap SFF helpers with necessary setup and teardown added. Mmm.. an amazing amount of complexity there for something that ought to be very simple. I wish things are a bit clearer now. I think the problem here is that we're assuming SFF TF access on controllers which aren't really SFF. For sil24 and ahci, the driver emulates it and it isn't too difficult. The picture gets more interesting for sata_mv as its hardware interface much closer to SFF than sil24 or ahci and TF registers matter much more. For ahci and sil24, LLD can just fool libata core layer which assumes ubiquitous TF access. TF registers don't really matter to controller operation anyway and feeding bogus values work well. For sata_mv, it's different. Those registers are integral part of controller operation and sata_mv can't really tolerate core layer stepping in w/o notifying LLD. 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: new ata_port_operations for .pmp_{read,write} ?
Hello, Mark. Mark Lord wrote: And for that matter, is it possible for sata_pmp_read() to be called while the link is active with another command ? Not today, it seems, but what about when hotplug polling gets implemented ? .. That's the one I'm most concerned about. Should I be? ... Tejun, On a related note, I'm now looking into PMP error handling in the driver. The obvious thing I see that I want to fix, is that after a media error on any PMP attached drive, I get this: ata20.00: failed to read SCR 1 (Emask=0x40) ata20.01: failed to read SCR 1 (Emask=0x40) ata20.02: failed to read SCR 1 (Emask=0x40) ata20.03: failed to read SCR 1 (Emask=0x40) ata20.04: failed to read SCR 1 (Emask=0x40) Okay, so those are from sata_pmp_read(), which cannot even issue it's commands because the port was frozen by the EH. Hmm.. media error causes freeze? Anyways, yeah, those are expected if the port is frozen. Those are from link autopsy. Maybe it's better to skip SCR access on fan-out ports if host port is frozen or at least suppress the messages. Is this expected? I'm not entirely clear what to do in the EH for this driver. The chipset docs say that after just about any kind of error software must do a hard reset of the channel to make it usable again. But I suspect that PIO commands may be okay before that, and sata_pmp_read() is trying to issue a PIO command. If the controller needs to be frozen after any kind of error, I don't think there's much left to do other than suppressing those annoying messages. Hmmm.. how does the controller handle ATAPI check sense? -- 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: new ata_port_operations for .pmp_{read,write} ?
Tejun Heo wrote: Yeah, this is an interesting problem. There are basically multiple sets of TF registers and the SFF way of assuming single set doesn't really work well and I don't really think adding -pmp_read/write is the correct long term solution to the problem. We need to confine direct TF register accesses to SFF layer only as controllers which don't implement SFF interface may or may not emulate TF registers and even when they do, it sometimes can't really match the SFF behavior. Strongly agreed. I wish things are a bit clearer now. I think the problem here is that we're assuming SFF TF access on controllers which aren't really SFF. For sil24 and ahci, the driver emulates it and it isn't too difficult. The picture gets more interesting for sata_mv as its hardware interface much closer to SFF than sil24 or ahci and TF registers matter much more. For ahci and sil24, LLD can just fool libata core layer which assumes ubiquitous TF access. TF registers don't really matter to controller operation anyway and feeding bogus values work well. For sata_mv, it's different. Those registers are integral part of controller operation and sata_mv can't really tolerate core layer stepping in w/o notifying LLD. I would definitely like to move away from the model where non-SFF drivers have to emulate SFF in any way. Re-reviewing the code, I don't see a lot of TF accesses outside of SFF-specific code, so we are already in pretty good shape. I think the picture gets more complicated with sata_mv and similar drivers (soon sata_svw, too), because they use the SFF code but only for certain TF protocols. The emulation question is not as clear, with those drivers. 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: new ata_port_operations for .pmp_{read,write} ?
Mark Lord wrote:
An alternative to all this, might be to expose the select_pmp()
function shown in the sample code, and have libata-pmp.c call that,
instead of having the new new .pmp_{read,write} functions.
..
I wonder if this might be more viable than first thought.
Say the LLD, be it ata_piix or sata_mv or sata_svw, were to provide
an option ata_operations method for select_pmp_port(pmp),
which the core could invoke prior to any direct manipulation
of the shadow registers.
It would really only be needed in perhaps three or four places total
(eg. sata_pmp_read/write, and before writes to the ata ctl register).
This could be a reasonably tidy way for the core to keep the LLD
abreast of its intent when accessing things.
I really would like to keep the LLD code small, and have good solid
core routines for non-hardware specific functionality. All of this stuff
I'm beginning to do with sata_mv would be trivial if I wanted to bloat
the LLD, but really.. only a tiny bit of it need be custom to sata_mv.
The existing SFF reset/probe/pmp stuff is just about exactly what
sata_mv needs.. and I feel a strong desire to not clone/duplicate
that hard-won functionality.
Much of it I can see being shared with other half-and-half chipset drivers
as we add PMP functionality to those.
Maybe that's just the embedded side me showing through?
It is tricky to define the right interfaces, though, as each chipset
does throw its own unique curve balls at us.
I may prototype this select_pmp_port() concept in sata_mv(),
and see how it works out (or not).
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: 2.6.25-rc2 + smartd = hang
Jeff Garzik wrote: If this is the prefered driver these days, maybe it shouldn't be marked experimental in the menu anymore? It's not marked experimental. the comment on the very top of drivers/ata says: tristate Serial ATA (prod) and Parallel ATA (experimental) drivers this is a bit confusing - 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
