[PATCH] pata_acpi: fix build breakage if !CONFIG_PM
There are configurations where CONFIG_ACPI but !CONFIG_PM. In this
case, pata_acpi can be selected but won't build. Fix it.
Reported by Avuton Olrich.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Cc: Avuton Olrich [EMAIL PROTECTED]
---
drivers/ata/pata_acpi.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/ata/pata_acpi.c b/drivers/ata/pata_acpi.c
index 5d3920f..0f6f7bc 100644
--- a/drivers/ata/pata_acpi.c
+++ b/drivers/ata/pata_acpi.c
@@ -370,8 +370,10 @@ static struct pci_driver pacpi_pci_driver = {
.id_table = pacpi_pci_tbl,
.probe = pacpi_init_one,
.remove = ata_pci_remove_one,
+#ifdef CONFIG_PM
.suspend= ata_pci_device_suspend,
.resume = ata_pci_device_resume,
+#endif
};
static int __init pacpi_init(void)
-
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]: Sata Sil3512 bug?; Promise SATA300 TX4
Hello, Wednesday, October 3, 2007, 10:31:17 AM, you wrote: Mikael Pettersson wrote: I'm thinking of replacing both 3512 controllers with a Promise SATA300 TX4. Do you know if there are problems with this device? (please don't top-post) There are no known data-corruption issues with Promise SATA cards. However, some of them, especially the 2nd generation SATA300 TX4, are known to trigger intermittent error interrupts (that are dealt with but may cause a speed reduction) in some systems. We're still scratching our heads on that issue. But see this thread: http://marc.info/?l=linux-idem=119122463403033w=2 http://www.spinics.net/lists/linux-ide/msg14868.html Personally I would not recommend Promise SATA300 TX4 at the moment. After all the problems i had with the sweex 3512 cards i returned them to the shop and decided to buy a Sata300 TX4 (because the shop nearby had one. Unfortunately the shops in the region don't have Highpoints) Things looked promising when i inserted the card in both Intel D815EEA motherboards. No problems detecting the hard drives (unlike with the 3512 cards). With the 3512 i had LOTS of error messages and corrupt data when writing to it. Using a separate videocard, instead of the onboard one, seemed to reduce the amount of errors. But after some heavy reading/writing with the promise i got 2 errors. (see log file). But i did'nt find any corrupt files. I can not reproduce the error. I'm not sure if these are the intermittent error interrupts Mikael Pettersson mentioned? ps: as you can i see i got at the boot some errors from the boot disk (hda). I not sure what is wrong with it. Sometimes it produce these errors. Used a non-destructive read-write test with badblocks but no bad sectors found. I don't know if this could influence the sata controller. Alexander Sabourenkov can you please tell me where i can find the Bug is fixed in 2.6.23.1: sata_promise: port is slow to respond, reset failed thread you mentioned? I also see that the driver is now at version 2.10. Is there something really critical changed? I've tried testing with Debian stable (2.6.18-4-686; sata_promise: 1.04) and with Debian Unstable (2.6.22-2-686; sata_promise: 2.07). 2.6.23 is not in the repositories yet. So basically the question is this. Can i trust the SATA300 TX4 or should i buy a Highpoint RocketRAID 1640/1740?. I can order such device online but i need to be sure that it works correctly :( -- Best regards, MisterEmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re-enabling Serial ATA ports possible?
Hi On my system (2.6.23-rc9) I have Serial-ATA DVD/RW drive connected to sata_sil controller. Sometimes when there is a problem with CD or DVD disk controller shutdowns drive: [53560.095573] cdrom: sr0: mrw address space DMA selected [53561.001946] ISO 9660 Extensions: Microsoft Joliet Level 3 [53561.002777] ISOFS: changing to secondary root [53621.380238] ata6.00: exception Emask 0x10 SAct 0x0 SErr 0x9 action 0x2 [53621.380249] ata6.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 [53621.380252] res 51/60:03:00:00:00/00:00:00:00:00/a0 Emask 0x10 (ATA bus error) [53621.380263] ata6: hard resetting port [53623.783961] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [53642.595278] ata6.00: qc timeout (cmd 0xa1) [53642.595285] ata6.00: failed to IDENTIFY (I/O error, err_mask=0x4) [53642.595288] ata6.00: revalidation failed (errno=-5) [53642.595292] ata6: failed to recover some devices, retrying in 5 secs [53645.092046] ata6: hard resetting port [53646.193870] ata6: SATA link down (SStatus 1 SControl 310) [53646.193881] ata6.00: limiting speed to UDMA/25:PIO3 [53646.193884] ata6: failed to recover some devices, retrying in 5 secs [53648.690501] ata6: hard resetting port [53649.792323] ata6: SATA link down (SStatus 1 SControl 310) [53649.792333] ata6.00: disabled [53650.042442] ata6: EH pending after completion, repeating EH (cnt=4) [53650.042459] ata6: EH complete [53650.042512] sr 6:0:0:0: rejecting I/O to offline device [53650.042518] sr 6:0:0:0: rejecting I/O to offline device [53650.042522] sr 6:0:0:0: rejecting I/O to offline device [53650.042536] sr 6:0:0:0: rejecting I/O to offline device [53650.042632] ata6.00: detaching (SCSI 6:0:0:0) Is there a way to re-enable ata6.00 in other way then power down/power up whole machine? Looks like reboot is not a way to get it working again. Drive is found as: [ 96.858283] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [ 97.012480] ata6.00: ATAPI: TSSTcorpCD/DVDW SH-S183A, SB02, max UDMA/33 [ 97.012482] ata6.00: applying bridge limits [ 97.169126] ata6.00: configured for UDMA/33 -- JID: hrw-jabber.org OpenEmbedded developer/consultant You can close your eyes to reality, but not to memories. - 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: Re-enabling Serial ATA ports possible?
On Wed, 17 Oct 2007 14:38:04 +0200, Marcin Juszkiewicz wrote: On my system (2.6.23-rc9) I have Serial-ATA DVD/RW drive connected to sata_sil controller. Sometimes when there is a problem with CD or DVD disk controller shutdowns drive: [53560.095573] cdrom: sr0: mrw address space DMA selected [53561.001946] ISO 9660 Extensions: Microsoft Joliet Level 3 [53561.002777] ISOFS: changing to secondary root [53621.380238] ata6.00: exception Emask 0x10 SAct 0x0 SErr 0x9 action 0x2 [53621.380249] ata6.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 [53621.380252] res 51/60:03:00:00:00/00:00:00:00:00/a0 Emask 0x10 (ATA bus error) [53621.380263] ata6: hard resetting port [53623.783961] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [53642.595278] ata6.00: qc timeout (cmd 0xa1) [53642.595285] ata6.00: failed to IDENTIFY (I/O error, err_mask=0x4) [53642.595288] ata6.00: revalidation failed (errno=-5) [53642.595292] ata6: failed to recover some devices, retrying in 5 secs [53645.092046] ata6: hard resetting port [53646.193870] ata6: SATA link down (SStatus 1 SControl 310) [53646.193881] ata6.00: limiting speed to UDMA/25:PIO3 [53646.193884] ata6: failed to recover some devices, retrying in 5 secs [53648.690501] ata6: hard resetting port [53649.792323] ata6: SATA link down (SStatus 1 SControl 310) [53649.792333] ata6.00: disabled [53650.042442] ata6: EH pending after completion, repeating EH (cnt=4) [53650.042459] ata6: EH complete [53650.042512] sr 6:0:0:0: rejecting I/O to offline device [53650.042518] sr 6:0:0:0: rejecting I/O to offline device [53650.042522] sr 6:0:0:0: rejecting I/O to offline device [53650.042536] sr 6:0:0:0: rejecting I/O to offline device [53650.042632] ata6.00: detaching (SCSI 6:0:0:0) Is there a way to re-enable ata6.00 in other way then power down/power up whole machine? Looks like reboot is not a way to get it working again. If the driver supports SATA hotplugging, then removing the cable, waiting for libata EH to complete, and then inserting it again, should do the trick. - 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
pata_via refuses to detect one drive
I tried switching one machine here from old IDE modules to a new pata subsystem today. And it failed, for the first time I ever tried this procedure. Pata_via refuses to recognize one of the drives. Here's the dmesg with via82cxxx (2.6.20): Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller at PCI slot :00:11.1 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt8233 (rev 02) IDE UDMA100 controller on pci:00:11.1 ide0: BM-DMA at 0x3c00-0x3c07, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0x3c08-0x3c0f, BIOS settings: hdc:DMA, hdd:pio Probing IDE interface ide0... hda: Hitachi HDS721680PLAT80, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... hdc: Hitachi HDS721680PLAT80, ATA DISK drive hdd: FX4830T, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 loading module ide-disk hda: max request size: 512KiB hda: 160836480 sectors (82348 MB) w/7384KiB Cache, CHS=16383/255/636hda: hw_config=600b , UDMA(100) hda: cache flushes supported hda: hda1 hda2 hda3 hda4 hda5 hda6 hda7 hdc: max request size: 512KiB hdc: 160836480 sectors (82348 MB) w/7384KiB Cache, CHS=16383/255/63, UDMA(33) hdc: cache flushes supported hdc: hdc1 hdc2 hdc3 hdc4 hdc5 hdc6 hdc7 (yes, the second IDE cable isn't UDMA one). And here's the same when booted with pata_via module. 2.6.20 and 2.6.23 behaves the same way: Oct 17 18:30:59 linux kernel: scsi0 : pata_via Oct 17 18:30:59 linux kernel: scsi1 : pata_via Oct 17 18:30:59 linux kernel: ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x00013c00 irq 14 Oct 17 18:30:59 linux kernel: ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x00013c08 irq 15 Oct 17 18:30:59 linux kernel: ata1.00: ATA-7: Hitachi HDS721680PLAT80, P21OA60A, max UDMA/133 Oct 17 18:30:59 linux kernel: ata1.00: 160836480 sectors, multi 16: LBA48 Oct 17 18:30:59 linux kernel: ata1.00: configured for UDMA/100 Oct 17 18:30:59 linux kernel: ata2: port is slow to respond, please be patient (Status 0x80) Oct 17 18:30:59 linux kernel: ata2: SRST failed (errno=-16) Oct 17 18:30:59 linux kernel: ata2.01: ATAPI: FX4830T, R02E, max UDMA/33 Oct 17 18:30:59 linux kernel: ata2.01: configured for UDMA/33 Oct 17 18:30:59 linux kernel: scsi 0:0:0:0: Direct-Access ATA Hitachi HDS72168 P21O PQ: 0 ANSI: 5 Oct 17 18:30:59 linux kernel: ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 Oct 17 18:30:59 linux kernel: ata2.01: cmd a0/00:00:00:00:20/00:00:00:00:00/b0 tag 0 cdb 0x12 data 36 in Oct 17 18:30:59 linux kernel: res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x2 (HSM violation) Oct 17 18:30:59 linux kernel: ata2: soft resetting port Oct 17 18:30:59 linux kernel: ata2.01: configured for UDMA/33 Oct 17 18:30:59 linux kernel: ata2: EH complete Oct 17 18:30:59 linux kernel: ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 Oct 17 18:30:59 linux kernel: ata2.01: cmd a0/00:00:00:00:20/00:00:00:00:00/b0 tag 0 cdb 0x12 data 36 in Oct 17 18:30:59 linux kernel: res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x2 (HSM violation) Oct 17 18:30:59 linux kernel: ata2: soft resetting port Oct 17 18:30:59 linux kernel: ata2.01: configured for UDMA/33 Oct 17 18:30:59 linux kernel: ata2: EH complete Oct 17 18:30:59 linux kernel: ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 Oct 17 18:30:59 linux kernel: ata2.01: cmd a0/00:00:00:00:20/00:00:00:00:00/b0 tag 0 cdb 0x12 data 36 in Oct 17 18:30:59 linux kernel: res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x2 (HSM violation) Oct 17 18:30:59 linux kernel: ata2: soft resetting port Oct 17 18:30:59 linux kernel: ata2.01: configured for UDMA/33 Oct 17 18:30:59 linux kernel: ata2: EH complete Oct 17 18:30:59 linux kernel: ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 Oct 17 18:30:59 linux kernel: ata2.01: cmd a0/00:00:00:00:20/00:00:00:00:00/b0 tag 0 cdb 0x12 data 36 in Oct 17 18:30:59 linux kernel: res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x2 (HSM violation) Oct 17 18:30:59 linux kernel: ata2: soft resetting port Oct 17 18:30:59 linux kernel: ata2.01: configured for UDMA/33 Oct 17 18:30:59 linux kernel: ata2: EH complete Oct 17 18:30:59 linux kernel: loading module sd_mod Oct 17 18:30:59 linux kernel: sd 0:0:0:0: [sda] 160836480 512-byte hardware sectors (82348 MB) Oct 17 18:30:59 linux kernel: sd 0:0:0:0: [sda] Write Protect is off Oct 17 18:30:59 linux kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 Oct 17 18:30:59 linux kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Oct 17 18:30:59 linux kernel: sd 0:0:0:0: [sda] 160836480 512-byte hardware sectors (82348 MB) Oct 17 18:30:59 linux kernel: sd 0:0:0:0: [sda] Write Protect is off Oct 17 18:30:59 linux kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 Oct 17 18:30:59 linux
Re[2]: Sata Sil3512 bug?; Promise SATA300 TX4
Hello Alexander,
Wednesday, October 17, 2007, 2:54:25 PM, you wrote:
Log file got lost. Please post relevant parts inline.
Sorry, i totally forgot to include them.
I can not reproduce the errors. Last times hda did not give errors. So i'm
not sure if it is related to each other. (in the thread you mentioned
that you can't explain the fixing of problem from Peter Favrholdt, so
maybe it has indeed something to do with the libata)
ct 16 14:10:59 fileserver kernel: hda: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Oct 16 14:10:59 fileserver kernel: hda: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Oct 16 14:10:59 fileserver kernel: ide: failed opcode was: unknown
Oct 16 14:12:49 fileserver kernel: kjournald starting. Commit interval 5
seconds
Oct 16 14:12:49 fileserver kernel: EXT3 FS on sda1, internal journal
Oct 16 14:12:49 fileserver kernel: EXT3-fs: mounted filesystem with ordered
data mode.
Oct 16 14:13:34 fileserver kernel: hda: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Oct 16 14:13:34 fileserver kernel: hda: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Oct 16 14:13:34 fileserver kernel: ide: failed opcode was: unknown
Oct 16 14:17:21 fileserver kernel: hda: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Oct 16 14:17:21 fileserver kernel: hda: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Oct 16 14:17:21 fileserver kernel: ide: failed opcode was: unknown
Oct 16 14:17:21 fileserver kernel: hda: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Oct 16 14:17:21 fileserver kernel: hda: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Oct 16 14:17:21 fileserver kernel: ide: failed opcode was: unknown
Oct 16 14:17:21 fileserver kernel: hda: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Oct 16 14:17:21 fileserver kernel: hda: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Oct 16 14:17:21 fileserver kernel: ide: failed opcode was: unknown
Oct 16 14:17:21 fileserver kernel: hda: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Oct 16 14:17:21 fileserver kernel: hda: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Oct 16 14:17:21 fileserver kernel: ide: failed opcode was: unknown
Oct 16 14:17:21 fileserver kernel: hda: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Oct 16 14:17:21 fileserver kernel: hda: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Oct 16 14:17:21 fileserver kernel: ide: failed opcode was: unknown
Oct 16 14:17:21 fileserver kernel: hdb: DMA disabled
Oct 16 14:17:21 fileserver kernel: ide0: reset: success
Oct 16 14:32:51 fileserver kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr
0x0 action 0x2
Oct 16 14:32:51 fileserver kernel: ata1.00: (port_status 0x2008)
Oct 16 14:32:51 fileserver kernel: ata1.00: cmd
c8/00:00:77:f6:6c/00:00:00:00:00/e4 tag 0 cdb 0x0 data 131072 in
Oct 16 14:32:51 fileserver kernel: res
50/00:00:76:f7:6c/00:00:00:00:00/e4 Emask 0x2 (HSM violation)
Oct 16 14:32:51 fileserver kernel: ata1: soft resetting port
Oct 16 14:32:51 fileserver kernel: ata1: SATA link up 3.0 Gbps (SStatus 123
SControl 300)
Oct 16 14:32:51 fileserver kernel: ata1.00: configured for UDMA/133
Oct 16 14:32:51 fileserver kernel: ata1: EH complete
Oct 16 14:32:51 fileserver kernel: sd 0:0:0:0: [sda] 976773168 512-byte
hardware sectors (500108 MB)
Oct 16 14:32:51 fileserver kernel: sd 0:0:0:0: [sda] Write Protect is off
Oct 16 14:32:51 fileserver kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Oct 16 14:32:51 fileserver kernel: sd 0:0:0:0: [sda] Write cache: enabled, read
cache: enabled, doesn't support DPO or FUA
Oct 16 14:44:09 fileserver kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Oct 16 14:48:48 fileserver kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr
0x0 action 0x2
Oct 16 14:48:48 fileserver kernel: ata1.00: (port_status 0x2008)
Oct 16 14:48:48 fileserver kernel: ata1.00: cmd
25/00:00:3f:d0:26/00:01:23:00:00/e0 tag 0 cdb 0x0 data 131072 in
Oct 16 14:48:48 fileserver kernel: res
50/00:00:3e:d1:26/00:00:23:00:00/e0 Emask 0x2 (HSM violation)
Oct 16 14:48:48 fileserver kernel: ata1: soft resetting port
Oct 16 14:48:49 fileserver kernel: ata1: SATA link up 3.0 Gbps (SStatus 123
SControl 300)
Oct 16 14:48:49 fileserver kernel: ata1.00: configured for UDMA/133
Oct 16 14:48:49 fileserver kernel: ata1: EH complete
Oct 16 14:48:49 fileserver kernel: sd 0:0:0:0: [sda] 976773168 512-byte
hardware sectors (500108 MB)
Oct 16 14:48:49 fileserver kernel: sd 0:0:0:0: [sda] Write Protect is off
Oct 16 14:48:49 fileserver kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Oct 16 14:48:49 fileserver kernel: sd 0:0:0:0: [sda] Write cache: enabled, read
cache: enabled, doesn't support DPO or FUA
Since you have the hardware, do the tests and decide for yourself.
I'd try copying one (big, preferably over 160G ) disk onto another (with
dd) for a start,
while waiting for answers on mailing lists.
I can order that 1740 online, but returning something is always more
pata_via(?): cdrom is recognized as hard drive
And one more issue with my attempt to switch
from via82cxxx to pata_via.
I noticied that on all machines I tried to convert,
CD-Rom devices are recognized as hard disks.
With via82cxxx and ide-cd, it was like
hdc: IDE cdrom model=FX4830T s/n=4JV6F7Q4 fw=8.01 udma5
But with pata_via and 2.6.23, it's handled by sd_mod:
# ls /sys/block
sda/ sdb/ sdc/ sdd/
# cat /sys/block/sdc/removable
0
# cat /sys/block/sdc/device/type
0
# echo '$(cat /sys/block/sdc/device/model)'
''
# echo '$(cat /sys/block/sdc/device/vendor)'
''
# hdparm -i /dev/sdc
/dev/sdc:
Model=FX4830T , FwRev=R02E, SerialNo=
Config={ Fixed Removeable DTR=5Mbs DTR10Mbs nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=128kB, MaxMultSect=0
(maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 *udma2
AdvancedPM=no
* signifies the current active mode
Is it how the things supposed to be, or is something wrong with
the detection? Note that this happens on several machines,
however all of them so far has via82cxxx controller:
:00:11.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
(VT8633 chipset)
(I use pata_via driver on a home machine for a long time, with another
controller (CN700/VN800/P4M800CE/Pro chipset)), and everything there
works as expected, since early pata days).
2.6.20, 2.6.22, 2.6.23 behaves the same.
Thanks.
/mjt
-
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: pata_via refuses to detect one drive
Oct 17 18:30:59 linux kernel: ata2: port is slow to respond, please be patient (Status 0x80) Oct 17 18:30:59 linux kernel: ata2: SRST failed (errno=-16) So it failed to reset and come back to sanity. Oct 17 18:30:59 linux kernel: ata2.01: ATAPI: FX4830T, R02E, max UDMA/33 Oct 17 18:30:59 linux kernel: ata2.01: configured for UDMA/33 Oct 17 18:30:59 linux kernel: scsi 0:0:0:0: Direct-Access ATA Hitachi HDS72168 P21O PQ: 0 ANSI: 5 Oct 17 18:30:59 linux kernel: ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 Oct 17 18:30:59 linux kernel: ata2.01: cmd a0/00:00:00:00:20/00:00:00:00:00/b0 tag 0 cdb 0x12 data 36 in Oct 17 18:30:59 linux kernel: res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x2 (HSM violation) This looks like both drives end up trying to be the slave ? Its certainly very vey confused at this point. Interesting it works with the BIOS doing the reset, wonder what the difference is. How are the drives jumpered and does it work with just one of the two present ? 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
Anyone else out there have an ExpressCard to try?
I have a Dell Inspiron 9400 with an external ExpressCard slot. I've also got a Bytecc 2-port eSATA ExpressCard-34 that identifies as: Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller (rev 01) To get it to work with Linux on my Dell notebook, the pcihp_force=1 parameter is necessary for the pciehp module. After that, it works great with libata and NCQ, of course, with R/W performance in the 40-60 Mbyte/sec range (depends upon the drive). Much better than with USB2 (28-30 Mbyte/sec). The problems are with PCIe hotplug. If the card is inserted prior to loading pci_hotplug + pciehp modules, then it is not detected upon modprobe of those modules. Removing and reinserting the card cures that. After a suspend/resume (RAM) cycle, card insertion/removal is no longer detected by pciehp, until doing: rmmod pciehp; modprobe pciehp Apparently many (all?) Dell notebooks have this problem, because the ACPI BIOS lacks info/whatever for the ExpressCard slot. I'm wondering if other brands (or other Dells, even) have similar issues. So.. if you have one and ExpressCard slot and an ExpressCard, could you please try testing the above scenarios, and post a reply? In the reply, describe what works, what doesn't, and whether or not the pciehp=force parameter was required. On LKML, there is a patchset to fix the above issues, and if you have those problems then please try the patches and report back on that as well. http://lkml.org/lkml/2007/10/16/465 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
FW: LIBATA issue with SATA drive
Hello Tejun, I've CC'd the mailing list, but couldn't find Torsten's e-mail. Do you have any suggestions on where I should look for this problem? Did the boot-up log suggest anything to you? - Clarence -Original Message- From: Tejun Heo [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 17, 2007 4:32 AM To: Ip, Clarence Subject: Re: LIBATA issue with SATA drive Ip, Clarence wrote: Hello Tejun, I'm using the 2.6.22 sources with a Sii3132 SATA controller and a Seagate HDD. What I've noticed is that it often fails to boot with this configuration. Warm boots appear to always fail while cold boots (power-cycles) fail maybe 20%-50% of the time. Here's a log from my last attempt: Hmmm... We had a similar report against -mm kernel but that case seemed like newly introduced with recent -mm changes. Do you mind cc'ing the other reporter and linux-ide@vger.kernel.org mailing list? 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: pata_via(?): cdrom is recognized as hard drive
On Wed, 17 Oct 2007 19:35:52 +0400 Michael Tokarev [EMAIL PROTECTED] wrote: And one more issue with my attempt to switch from via82cxxx to pata_via. I noticied that on all machines I tried to convert, CD-Rom devices are recognized as hard disks. Thats deeply weird. But with pata_via and 2.6.23, it's handled by sd_mod: CD's are handled by sr_mod. I suspect this is actually arising out of the fact both devices seem to be falling over each other after the SRST. Can you stick all this in a bugzilla and assign it to me so it doesn't get lost. 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: [PATCH 6/12] ide: add struct ide_taskfile
Bartlomiej Zolnierkiewicz wrote:
* Don't set write-only ide_task_t.hobRegister[6] and ide_task_t.hobRegister[7]
in idedisk_set_max_address_ext().
* Add struct ide_taskfile and use it in ide_task_t instead of tfRegister[]
and hobRegister[].
* Remove no longer needed IDE_CONTROL_OFFSET_HOB define.
* Add #ifndef/#endif __KERNEL__ around definitions of {task,hob}_struct_t.
While at it:
* Use ATA_LBA define for LBA bit (0x40) as suggested by Tejun Heo.
There should be no functionality changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
Nearly-acked-by: Sergei Shtylyov [EMAIL PROTECTED]
Index: b/drivers/ide/ide-disk.c
===
--- a/drivers/ide/ide-disk.c
+++ b/drivers/ide/ide-disk.c
[...]
+ if ((tf-command 0x01) == 0) {
+ u32 high, low;
Isn't newline needed after declarations?
+ high = (tf-hob_lbah 16) | (tf-hob_lbam 8) |
tf-hob_lbal;
+ low = (tf-lbah 16) | (tf-lbam 8) | tf-lbal;
addr = ((__u64)high 24) | low;
addr++; /* since the return value is (maxlba - 1), we add 1 */
}
[...]
@@ -422,33 +417,29 @@ static unsigned long idedisk_set_max_add
[...]
/* if OK, compute maximum address value */
- if ((args.tfRegister[IDE_STATUS_OFFSET] 0x01) == 0) {
- u32 high = (args.hobRegister[IDE_HCYL_OFFSET] 16) |
- (args.hobRegister[IDE_LCYL_OFFSET] 8) |
- args.hobRegister[IDE_SECTOR_OFFSET];
- u32 low = ((args.tfRegister[IDE_HCYL_OFFSET])16) |
- ((args.tfRegister[IDE_LCYL_OFFSET])8) |
- (args.tfRegister[IDE_SECTOR_OFFSET]);
+ if ((tf-command 0x01) == 0) {
+ u32 high, low;
Again missing newline...
+ high = (tf-hob_lbah 16) | (tf-hob_lbam 8) |
tf-hob_lbal;
+ low = (tf-lbah 16) | (tf-lbam 8) | tf-lbal;
addr_set = ((__u64)high 24) | low;
addr_set++;
}
@@ -582,12 +573,13 @@ static sector_t idedisk_capacity (ide_dr
static int smart_enable(ide_drive_t *drive)
{
ide_task_t args;
+ struct ide_taskfile *tf = args.tf;
memset(args, 0, sizeof(ide_task_t));
- args.tfRegister[IDE_FEATURE_OFFSET] = SMART_ENABLE;
- args.tfRegister[IDE_LCYL_OFFSET]= SMART_LCYL_PASS;
- args.tfRegister[IDE_HCYL_OFFSET]= SMART_HCYL_PASS;
- args.tfRegister[IDE_COMMAND_OFFSET] = WIN_SMART;
+ tf-feature = SMART_ENABLE;
+ tf-lbam= SMART_LCYL_PASS;
+ tf-lbah= SMART_HCYL_PASS;
+ tf-command = WIN_SMART;
args.command_type = IDE_DRIVE_TASK_NO_DATA;
args.handler= task_no_data_intr;
return ide_raw_taskfile(drive, args, NULL);
@@ -596,13 +588,14 @@ static int smart_enable(ide_drive_t *dri
static int get_smart_data(ide_drive_t *drive, u8 *buf, u8 sub_cmd)
{
ide_task_t args;
+ struct ide_taskfile *tf = args.tf;
memset(args, 0, sizeof(ide_task_t));
- args.tfRegister[IDE_FEATURE_OFFSET] = sub_cmd;
- args.tfRegister[IDE_NSECTOR_OFFSET] = 0x01;
- args.tfRegister[IDE_LCYL_OFFSET]= SMART_LCYL_PASS;
- args.tfRegister[IDE_HCYL_OFFSET]= SMART_HCYL_PASS;
- args.tfRegister[IDE_COMMAND_OFFSET] = WIN_SMART;
+ tf-feature = sub_cmd;
+ tf-nsect = 0x01;
+ tf-lbam= SMART_LCYL_PASS;
+ tf-lbah= SMART_HCYL_PASS;
+ tf-command = WIN_SMART;
I guess the code above and below were menat to have the same = indentation...
args.command_type = IDE_DRIVE_TASK_IN;
args.data_phase = TASKFILE_IN;
args.handler= task_in_intr;
@@ -808,9 +801,9 @@ static int write_cache(ide_drive_t *driv
if (ide_id_has_flush_cache(drive-id)) {
memset(args, 0, sizeof(ide_task_t));
- args.tfRegister[IDE_FEATURE_OFFSET] = (arg) ?
+ args.tf.feature = arg ?
SETFEATURES_EN_WCACHE : SETFEATURES_DIS_WCACHE;
- args.tfRegister[IDE_COMMAND_OFFSET] = WIN_SETFEATURES;
+ args.tf.command = WIN_SETFEATURES;
Same here...
args.command_type = IDE_DRIVE_TASK_NO_DATA;
args.handler= task_no_data_intr;
err = ide_raw_taskfile(drive, args, NULL);
@@ -829,9 +822,9 @@ static int do_idedisk_flushcache (ide_dr
memset(args, 0, sizeof(ide_task_t));
if (ide_id_has_flush_cache_ext(drive-id))
- args.tfRegister[IDE_COMMAND_OFFSET] = WIN_FLUSH_CACHE_EXT;
+ args.tf.command = WIN_FLUSH_CACHE_EXT;
else
-
Re: [PATCH 5/12] ide: remove task_ioreg_t typedef
Bartlomiej Zolnierkiewicz wrote:
Remove task_ioreg_t typedef from the kernel code (but leave it
in linux/hdreg.h for #ifndef/#endif __KERNEL__ case).
While at it also move sata_ioreg_t typedef under #ifndef/#endif __KERNEL__.
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
Acked-by: Sergei Shtylyov [EMAIL PROTECTED]
Index: b/include/linux/hdreg.h
===
--- a/include/linux/hdreg.h
+++ b/include/linux/hdreg.h
[...]
@@ -116,8 +116,8 @@ typedef union ide_reg_valid_s {
} ide_reg_valid_t;
typedef struct ide_task_request_s {
- task_ioreg_tio_ports[8];
- task_ioreg_thob_ports[8];
+ __u8io_ports[8];
+ __u8hob_ports[8];
ide_reg_valid_t out_flags;
ide_reg_valid_t in_flags;
int data_phase;
@@ -133,32 +133,32 @@ typedef struct ide_ioctl_request_s {
} ide_ioctl_request_t;
struct hd_drive_cmd_hdr {
- task_ioreg_t command;
- task_ioreg_t sector_number;
- task_ioreg_t feature;
- task_ioreg_t sector_count;
+ __u8 command;
+ __u8 sector_number;
+ __u8 feature;
+ __u8 sector_count;
};
typedef struct hd_drive_task_hdr {
- task_ioreg_t data;
- task_ioreg_t feature;
- task_ioreg_t sector_count;
- task_ioreg_t sector_number;
- task_ioreg_t low_cylinder;
- task_ioreg_t high_cylinder;
- task_ioreg_t device_head;
- task_ioreg_t command;
+ __u8 data;
+ __u8 feature;
+ __u8 sector_count;
+ __u8 sector_number;
+ __u8 low_cylinder;
+ __u8 high_cylinder;
+ __u8 device_head;
+ __u8 command;
} task_struct_t;
typedef struct hd_drive_hob_hdr {
- task_ioreg_t data;
- task_ioreg_t feature;
- task_ioreg_t sector_count;
- task_ioreg_t sector_number;
- task_ioreg_t low_cylinder;
- task_ioreg_t high_cylinder;
- task_ioreg_t device_head;
- task_ioreg_t control;
+ __u8 data;
+ __u8 feature;
+ __u8 sector_count;
+ __u8 sector_number;
+ __u8 low_cylinder;
+ __u8 high_cylinder;
+ __u8 device_head;
+ __u8 control;
} hob_struct_t;
Why use __u8 here, and u8 elsewhere?
#define TASKFILE_INVALID 0x7fff
Index: b/include/linux/ide.h
===
--- a/include/linux/ide.h
+++ b/include/linux/ide.h
@@ -1017,7 +1017,8 @@ int ide_end_dequeued_request(ide_drive_t
extern void ide_set_handler (ide_drive_t *drive, ide_handler_t *handler, unsigned int timeout, ide_expiry_t *expiry);
-extern void ide_execute_command(ide_drive_t *, task_ioreg_t cmd, ide_handler_t *, unsigned int, ide_expiry_t *);
+void ide_execute_command(ide_drive_t *, u8 cmd, ide_handler_t *,
+unsigned int, ide_expiry_t *);
Hm, why name only second parameter? :-|
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: pata_via refuses to detect one drive
Alan Cox wrote:
Oct 17 18:30:59 linux kernel: ata2: port is slow to respond, please be
patient (Status 0x80)
Oct 17 18:30:59 linux kernel: ata2: SRST failed (errno=-16)
So it failed to reset and come back to sanity.
Oct 17 18:30:59 linux kernel: ata2.01: ATAPI: FX4830T, R02E, max UDMA/33
Oct 17 18:30:59 linux kernel: ata2.01: configured for UDMA/33
Oct 17 18:30:59 linux kernel: scsi 0:0:0:0: Direct-Access ATA
Hitachi HDS72168 P21O PQ: 0 ANSI: 5
Oct 17 18:30:59 linux kernel: ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0
action 0x2
Oct 17 18:30:59 linux kernel: ata2.01: cmd
a0/00:00:00:00:20/00:00:00:00:00/b0 tag 0 cdb 0x12 data 36 in
Oct 17 18:30:59 linux kernel: res
00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x2 (HSM violation)
This looks like both drives end up trying to be the slave ? Its certainly
very vey confused at this point. Interesting it works with the BIOS doing
the reset, wonder what the difference is.
Not only it works with BIOS, it also works with via82cxxx just fine.
hdc: Hitachi HDS721680PLAT80, ATA DISK drive
hdc: max request size: 512KiB
hdc: 160836480 sectors (82348 MB) w/7384KiB Cache, CHS=16383/255/63, UDMA(33)
hdc: cache flushes supported
hdc: hdc1 hdc2 hdc3 hdc4 hdc5 hdc6 hdc7
hdd: FX4830T, ATAPI CD/DVD-ROM drive
hdd: ATAPI 48X CD-ROM drive, 128kB Cache, UDMA(33)
# hdparm -i /dev/hdc
/dev/hdc:
Model=Hitachi HDS721680PLAT80, FwRev=P21OA60A, SerialNo=PV2100Z106Z9EF
Config={ HardSect NotMFM HdSw15uSec Fixed DTR10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=51
BuffType=DualPortCache, BuffSize=7384kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=160836480
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 *udma2 udma3 udma4 udma5 udma3 udma4 udma5 udma6
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: ATA/ATAPI-7 T13 1532D revision 1: ATA/ATAPI-2 ATA/ATAPI-3
ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6 ATA/ATAPI-7
# hdparm -i /dev/hdd
/dev/hdd:
Model=FX4830T, FwRev=R02E, SerialNo=
Config={ Fixed Removeable DTR=5Mbs DTR10Mbs nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=128kB, MaxMultSect=0
(maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 *udma2
AdvancedPM=no
(both drives are on plain IDE cable, second IDE channel).
How are the drives jumpered and does it work with just one of the two
present ?
That's an interesting question. The machine is remote, and there's
no one on site who's able to check it. I'll try to get reach of it,
hopefully it will be soon enough. In any case, it looks like the
jumpers are OK, or else it shouldnt work with IDE module as well.
/mjt
-
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: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?
On Wednesday 17 October 2007 00:14:26 Bartlomiej Zolnierkiewicz wrote: Martin, could you run git-bisect (http://kerneltrap.org/node/11753 - sorry for not explaining the procudure myself but Linus did it really well) starting with: git bisect good 688a87d145e04f6761c63e7f2e19fd9b3e4ca060 git bisect bad 826a1b6502d0d1d67fc41043fc831e90f2ef5835 The good one is the last commit before cmd64x changes and the bad one is the first commit after them. Since there is only 5 commits in between it should be really quick find the bad one (worst-case: 3 recompiles/reboots). I'll do my best. I appear to have git 1.5.2.2 on my machine, but I've never used it. In the old days we used not to have such luxury! Give me a few days. I shall report back. cu Martin - 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 Sil3512 bug?; Promise SATA300 TX4
Hi, MisterE wrote: Tonight i will try the Asus motherboard with 1 drive and much I/O. And i will create a new array which takes 7 hours. But how often/hours do you need to try something to prove it does not fail :P On one box I had problems with the SATA300 TX4 using 2.6.21 through 2.6.22 (different versions). I have 4x500GB Seagate ES SATA drives connected. The system would run fine, but when put to a stress - i.e. loaded on all sata ports one or two ports would fail - one after the other. I have _always_ been able to make it fail doing: dd if=/dev/sda of=/dev/null bs=1M dd if=/dev/sdb of=/dev/null bs=1M dd if=/dev/sdc of=/dev/null bs=1M dd if=/dev/sdd of=/dev/null bs=1M The ports would freeze before running long - e.g. in less than an hour. This can be done without even starting the array (mdadm). Therefore no data corruption will happen. The above issue was fixed by updating to vanilla 2.6.23.1. Until then I have been running with 2.6.21-rc2 with a Mikael Petterson patch to force the SATA to 1.5Gbps (this could possibly be accomplished by jumpers on the drives as well - but I didn't try that). I have another system (Dell PE1800 = different from the above) running 24x7 using vanilla linux 2.6.19.5. This system has been running without hickups for more than a year (current uptime 135 days). Hope this helps, Best regards, Peter - 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: [git patch] libata build fix
BZ == Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] writes: BZ We probably need also this one for pata_cs5536: BZ [PATCH] pata_cs5536: MWDMA fix BZ * Fix out-of-bound array access for MWDMA modes. BZ * Bump driver version. Obviously correct. Acked-by: Martin K. Petersen [EMAIL PROTECTED] -- Martin K. Petersen Oracle Linux Engineering - 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
western digital WD1500ADFD: spurious completions during NCQ
Several threads that suggest this message is related to poor NCQ support, but I did not see any for this drive. It's a Western Digital WD1500ADFD-00NLR1. Is this the same thing, and should this drive be blacklisted? ata1.00: exception Emask 0x2 SAct 0x1f1 SErr 0x0 action 0x2 frozen ata1.00: spurious completions during NCQ issue=0x0 SAct=0x1f1 FIS=004040a1:0008 ata1.00: cmd 61/10:00:90:d3:e8/00:00:0a:00:00/40 tag 0 cdb 0x0 data 8192 out res 40/00:08:80:fc:34/00:00:04:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 61/40:20:8e:2e:b8/00:00:06:00:00/40 tag 4 cdb 0x0 data 32768 out res 40/00:08:80:fc:34/00:00:04:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 61/40:28:ce:2e:b8/00:00:06:00:00/40 tag 5 cdb 0x0 data 32768 out res 40/00:08:80:fc:34/00:00:04:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 61/40:30:0e:2f:b8/00:00:06:00:00/40 tag 6 cdb 0x0 data 32768 out res 40/00:08:80:fc:34/00:00:04:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 61/40:38:4e:2f:b8/00:00:06:00:00/40 tag 7 cdb 0x0 data 32768 out res 40/00:08:80:fc:34/00:00:04:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 61/40:40:8e:2f:b8/00:00:06:00:00/40 tag 8 cdb 0x0 data 32768 out res 40/00:08:80:fc:34/00:00:04:00:00/40 Emask 0x2 (HSM violation) ata1: soft resetting port ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: configured for UDMA/133 ata1: EH complete I've attached hdparm -I output. Thanks, Jeff Garrett /dev/sda: ATA device, with non-removable media Model Number: WDC WD1500ADFD-00NLR1 Serial Number: WD-WMAP41106896 Firmware Revision: 20.07P20 Standards: Used: ATA/ATAPI-7 published, ANSI INCITS 397-2005 Supported: 7 6 5 4 Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBAuser addressable sectors: 268435455 LBA48 user addressable sectors: 293046768 device size with M = 1024*1024: 143089 MBytes device size with M = 1000*1000: 150039 MBytes (150 GB) Capabilities: LBA, IORDY(can be disabled) Queue depth: 32 Standby timer values: spec'd by Standard, with device specific minimum R/W multiple sector transfer: Max = 16 Current = 16 Recommended acoustic management value: 128, current value: 254 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120ns Commands/features: Enabled Supported: * SMART feature set Security Mode feature set * Power Management feature set Write cache * Look-ahead * Host Protected Area feature set * WRITE_BUFFER command * READ_BUFFER command * NOP cmd * DOWNLOAD_MICROCODE Power-Up In Standby feature set * SET_FEATURES required to spinup after power up * SET_MAX security extension * Automatic Acoustic Management feature set * 48-bit Address feature set * Device Configuration Overlay feature set * Mandatory FLUSH_CACHE * FLUSH_CACHE_EXT * SMART error logging * SMART self-test * General Purpose Logging feature set * 64-bit World wide name * SATA-I signaling speed (1.5Gb/s) * Native Command Queueing (NCQ) * Phy event counters DMA Setup Auto-Activate optimization * Software settings preservation * SMART Command Transport (SCT) feature set * SCT Long Sector Access (AC1) * SCT LBA Segment Access (AC2) * SCT Error Recovery Control (AC3) * SCT Features Control (AC4) * SCT Data Tables (AC5) unknown 206[12] Security: Master password revision code = 65534 supported not enabled not locked frozen not expired: security count not supported: enhanced erase Checksum: correct
Re: pata_via refuses to detect one drive
This looks like both drives end up trying to be the slave ? Its certainly very vey confused at this point. Interesting it works with the BIOS doing the reset, wonder what the difference is. Not only it works with BIOS, it also works with via82cxxx just fine. The via82cxxx driver doesn't go off and reset everything unless it gets bad error cases. How are the drives jumpered and does it work with just one of the two present ? That's an interesting question. The machine is remote, and there's no one on site who's able to check it. I'll try to get reach of it, hopefully it will be soon enough. In any case, it looks like the jumpers are OK, or else it shouldnt work with IDE module as well. Maybe. But its useful to know and it helps narrow down the fault. I've no idea whether the problem is hardware or software. What I am sure of though is if the BIOS and old driver work we should be able to make the new one work. My first guess is still a driver bug, and second some kind of probing interaction. BIOSen usually use Hal's code so we've got a fair idea of what the BIOS will do. 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: Fwd: CMD 64x regression from 2.6.21 to 2.6.22 and 2.6.23?
Hello. Martin Rogge wrote: Martin, could you run git-bisect (http://kerneltrap.org/node/11753 - sorry for not explaining the procudure myself but Linus did it really well) starting with: git bisect good 688a87d145e04f6761c63e7f2e19fd9b3e4ca060 git bisect bad 826a1b6502d0d1d67fc41043fc831e90f2ef5835 The good one is the last commit before cmd64x changes and the bad one is the first commit after them. Since there is only 5 commits in between it should be really quick find the bad one (worst-case: 3 recompiles/reboots). I'll do my best. I appear to have git 1.5.2.2 on my machine, but I've never used it. In the old days we used not to have such luxury! Give me a few days. I shall report back. BTW, can you try adding #define DEBUG to the driver meanwhile?.. cu Martin WBR, 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
Fixed my email
Apologies to those who sent me email in the past 12 hours -- there was a mail loop apparently. Should be fixed now, but anything you sent has likely been lost. 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] ata: ahci: Enable enclosure management via LED
Enable enclosure management via LED
As described in the AHCI spec, some AHCI controllers may support
Enclosure management via a variety of protocols. This patch
adds support for the LED message type that is specified in
AHCI 1.1 and higher.
Signed-off-by: Kristen Carlson Accardi [EMAIL PROTECTED]
---
drivers/ata/ahci.c| 153 +-
drivers/ata/libata-scsi.c |5 -
include/linux/libata.h|3
3 files changed, 157 insertions(+), 4 deletions(-)
Index: 2.6-git/drivers/ata/ahci.c
===
--- 2.6-git.orig/drivers/ata/ahci.c 2007-10-16 16:31:55.0 -0700
+++ 2.6-git/drivers/ata/ahci.c 2007-10-17 18:17:28.0 -0700
@@ -43,6 +43,7 @@
#include linux/device.h
#include scsi/scsi_host.h
#include scsi/scsi_cmnd.h
+#include scsi/scsi_device.h
#include linux/libata.h
#define DRV_NAME ahci
@@ -88,6 +89,8 @@ enum {
HOST_IRQ_STAT = 0x08, /* interrupt status */
HOST_PORTS_IMPL = 0x0c, /* bitmap of implemented ports */
HOST_VERSION= 0x10, /* AHCI spec. version compliancy */
+ HOST_EM_LOC = 0x1c, /* Enclosure Management location */
+ HOST_EM_CTL = 0x20, /* Enclosure Management Control */
/* HOST_CTL bits */
HOST_RESET = (1 0), /* reset controller; self-clear */
@@ -95,6 +98,7 @@ enum {
HOST_AHCI_EN= (1 31), /* AHCI enabled */
/* HOST_CAP bits */
+ HOST_CAP_EMS= (1 6), /* Enclosure Management support */
HOST_CAP_SSC= (1 14), /* Slumber capable */
HOST_CAP_PMP= (1 17), /* Port Multiplier support */
HOST_CAP_CLO= (1 24), /* Command List Override support */
@@ -185,6 +189,10 @@ enum {
ATA_FLAG_MMIO | ATA_FLAG_PIO_DMA |
ATA_FLAG_ACPI_SATA | ATA_FLAG_AN,
AHCI_LFLAG_COMMON = ATA_LFLAG_SKIP_D2H_BSY,
+
+ /* em_ctl bits */
+ EM_CTL_RST = (1 9), /* Reset */
+ EM_CTL_TM = (1 8), /* Transmit Message */
};
struct ahci_cmd_hdr {
@@ -208,6 +216,7 @@ struct ahci_host_priv {
u32 port_map; /* port map to use */
u32 saved_cap; /* saved initial cap */
u32 saved_port_map; /* saved initial port_map */
+ u32 em_loc; /* enclosure management location */
};
struct ahci_port_priv {
@@ -223,6 +232,7 @@ struct ahci_port_priv {
unsigned intncq_saw_dmas:1;
unsigned intncq_saw_sdb:1;
u32 intr_mask; /* interrupts to enable */
+ u16 led_state; /* saved current led state */
};
static int ahci_scr_read(struct ata_port *ap, unsigned int sc_reg, u32 *val);
@@ -521,6 +531,9 @@ static struct pci_driver ahci_pci_driver
#endif
};
+static int ahci_em_messages = 1;
+module_param(ahci_em_messages, int, 0444);
+MODULE_PARM_DESC(ahci_em_messages, Set AHCI Enclosure Management Message type
(0 = disabled, 1 = LED, 2 = SAF-TE, 3 = SES-2, 4 = SGPIO));
static inline int ahci_nr_ports(u32 cap)
{
@@ -902,6 +915,120 @@ static int ahci_reset_controller(struct
return 0;
}
+/** LED Enclosure Management routines /
+static int ahci_reset_em(struct ata_host *host)
+{
+ void __iomem *mmio = host-iomap[AHCI_PCI_BAR];
+ u32 em_ctl;
+
+ em_ctl = readl(mmio + HOST_EM_CTL);
+ if ((em_ctl EM_CTL_TM) || (em_ctl EM_CTL_RST))
+ return -EINVAL;
+
+ writel(em_ctl | EM_CTL_RST, mmio + HOST_EM_CTL);
+ return 0;
+}
+
+static int ahci_transmit_led_message(struct ata_port *ap, int led_num,
+ int state)
+{
+ struct ahci_host_priv *hpriv = ap-host-private_data;
+ void __iomem *mmio = ap-host-iomap[AHCI_PCI_BAR];
+ struct ahci_port_priv *pp = ap-private_data;
+ u32 em_ctl;
+ u32 message[] = {0,0};
+
+ /*
+* if we are still busy transmitting a previous message,
+* do not allow
+*/
+ em_ctl = readl(mmio + HOST_EM_CTL);
+ if (em_ctl EM_CTL_TM)
+ return -EINVAL;
+
+ /*
+* create message header - this is all zero except for
+* the message size, which is 4 bytes.
+*/
+ message[0] |= (4 8);
+
+ pp-led_state = ~(9 (3*led_num));
+
+ /*
+* create the actual message
+* XXX will need Port Multiplier support
+*/
+ message[1] = (ap-port_no | (pp-led_state 16));
+
+ /* LED bit locations are determined by the led_num */
+ message[1] |= (state (16 + (3*led_num)));
+
+ /* write message to EM_LOC */
+ writel(message[0], mmio + hpriv-em_loc);
+
[PATCH 0/3] ide: Fix use of paired device
At least 2 drivers (siimage and cs5535) have a bug where they use the construct: ide_drive_t *pair = hwif-drives[drive-dn ^ 1]; To access the other drive in a master/slave pair. This is bogus because drive-dn is not the unit number, but the global drive number, thus can be 2 3 for ide1, 4 5 for ide2 etc... This causes the driver to access beyond the drive array into lalaland for any other interface than ide0 and in some case, actually crash :-) These 3 patches fix those by introducing a ide_get_paired_drive() helper that does the right thing and then using it. Please apply to 2.6.24 if no objection. - 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 2/3] ide: Fix siimage driver accessing beyond array boundary
The siimage use an incorrect construct to access the other drive
of a pair, causing it to access beyond an array boundary on non-0
interfaces. This fixes it by using the new ide_get_paired_drive()
hepler instead.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
drivers/ide/pci/siimage.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-work/drivers/ide/pci/siimage.c
===
--- linux-work.orig/drivers/ide/pci/siimage.c 2007-10-18 10:42:56.0
+1000
+++ linux-work/drivers/ide/pci/siimage.c2007-10-18 10:43:09.0
+1000
@@ -180,7 +180,7 @@ static void sil_set_pio_mode(ide_drive_t
const u16 data_speed[] = { 0x328a, 0x2283, 0x1104, 0x10c3, 0x10c1 };
ide_hwif_t *hwif= HWIF(drive);
- ide_drive_t *pair = hwif-drives[drive-dn ^ 1];
+ ide_drive_t *pair = ide_get_paired_drive(drive);
u32 speedt = 0;
u16 speedp = 0;
unsigned long addr = siimage_seldev(drive, 0x04);
-
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 3/3] ide: Fix cs5535 driver accessing beyond array boundary
The cs5535 use an incorrect construct to access the other drive
of a pair, causing it to access beyond an array boundary on non-0
interfaces. This fixes it by using the new ide_get_paired_drive()
hepler instead.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
drivers/ide/pci/cs5535.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-work/drivers/ide/pci/cs5535.c
===
--- linux-work.orig/drivers/ide/pci/cs5535.c2007-10-18 10:43:39.0
+1000
+++ linux-work/drivers/ide/pci/cs5535.c 2007-10-18 10:44:00.0 +1000
@@ -84,7 +84,7 @@ static void cs5535_set_speed(ide_drive_t
/* Set the PIO timings */
if ((speed XFER_MODE) == XFER_PIO) {
- ide_drive_t *pair = drive-hwif-drives[drive-dn ^ 1];
+ ide_drive_t *pair = ide_get_paired_drive(drive);
u8 cmd, pioa;
cmd = pioa = speed - XFER_PIO_0;
-
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] pata_acpi: fix build breakage if !CONFIG_PM
Tejun Heo wrote: There are configurations where CONFIG_ACPI but !CONFIG_PM. In this case, pata_acpi can be selected but won't build. Fix it. Reported by Avuton Olrich. Signed-off-by: Tejun Heo [EMAIL PROTECTED] Cc: Avuton Olrich [EMAIL PROTECTED] --- drivers/ata/pata_acpi.c |2 ++ 1 file changed, 2 insertions(+) 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
Re: [PATCH v3] drivers/ata: add support to Freescale 3.0Gbps SATA Controller
Li Yang wrote: This patch adds support for Freescale 3.0Gbps SATA Controller supporting Native Command Queueing(NCQ), device hotplug, and ATAPI. This controller can be found on MPC8315 and MPC8378. Signed-off-by: Ashish Kalra [EMAIL PROTECTED] Signed-off-by: Li Yang [EMAIL PROTECTED] --- Address comments from Arnd Bergmann. drivers/ata/Kconfig|9 + drivers/ata/Makefile |1 + drivers/ata/sata_fsl.c | 1490 3 files changed, 1500 insertions(+), 0 deletions(-) create mode 100644 drivers/ata/sata_fsl.c 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
Re: [PATCH] libata-sff: Correct use of check_status()
Alan Cox wrote:
ata_check_status() does an SFF compliant check
ata_chk_status() does a generic call to ap-ops-check_status (usually
ata_check_status)
libata-sff uses the wrong one. Hardly suprising given the naming here,
which ought to get fixed to ata_sff_check_status() perhaps ?
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --exclude-from /usr/src/exclude --new-file --recursive
linux.vanilla-2.6.23-mm1/drivers/ata/libata-sff.c
linux-2.6.23-mm1/drivers/ata/libata-sff.c
--- linux.vanilla-2.6.23-mm1/drivers/ata/libata-sff.c 2007-10-15
15:03:26.0 +0100
+++ linux-2.6.23-mm1/drivers/ata/libata-sff.c 2007-10-15 15:16:29.0
+0100
@@ -156,7 +156,7 @@
{
struct ata_ioports *ioaddr = ap-ioaddr;
- tf-command = ata_check_status(ap);
+ 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.
-
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] Update libata driver for bf548 atapi controller against the 2.6.24 tree.
Sonic Zhang wrote: Changes: 1. Remove irq_ack() and port_disable() methods 2. Acocomodate for the libata-link patches 3. Change Kconfig ATAPI mode option into a module param. 4. Add supported WMDMA mode. Signed-off-by: Sonic Zhang [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
[git patches] libata fixes
Well, the new driver is not a fix.
Anyway -- still plugging away at debugging libata. It seems some
outside changes are causing a bunch of my test boxes to crap themselves.
These need to go up in the meantime, however.
Maybe its the sg-chaining stuff, we'll see. I'm watching that thread
closely (after recovering from an email outage).
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/Kconfig | 16 +-
drivers/ata/Makefile |1 +
drivers/ata/libata-sff.c |2 +-
drivers/ata/pata_acpi.c |2 +
drivers/ata/pata_bf54x.c | 77 ++--
drivers/ata/sata_fsl.c | 1490 ++
6 files changed, 1540 insertions(+), 48 deletions(-)
create mode 100644 drivers/ata/sata_fsl.c
Alan Cox (1):
libata-sff: Correct use of check_status()
Li Yang (1):
drivers/ata: add support to Freescale 3.0Gbps SATA Controller
Sonic Zhang (1):
Update libata driver for bf548 atapi controller against the 2.6.24 tree.
Tejun Heo (1):
pata_acpi: fix build breakage if !CONFIG_PM
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 33f5eb0..ba63619 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -182,6 +182,15 @@ config PATA_ACPI
firmware in the BIOS. This driver can sometimes handle
otherwise unsupported hardware.
+config SATA_FSL
+ tristate Freescale 3.0Gbps SATA support
+ depends on PPC_MPC837x
+ help
+ This option enables support for Freescale 3.0Gbps SATA controller.
+ It can be found on MPC837x and MPC8315.
+
+ If unsure, say N.
+
config PATA_ALI
tristate ALi PATA support (Experimental)
depends on PCI EXPERIMENTAL
@@ -641,11 +650,4 @@ config PATA_BF54X
If unsure, say N.
-config PATA_BF54X_DMA
- bool DMA mode
- depends on PATA_BF54X
- default y
- help
- Enable DMA mode for Blackfin ATAPI controller.
-
endif # ATA
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index 6bdc307..b13feb2 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_SATA_ULI)+= sata_uli.o
obj-$(CONFIG_SATA_MV) += sata_mv.o
obj-$(CONFIG_SATA_INIC162X)+= sata_inic162x.o
obj-$(CONFIG_PDC_ADMA) += pdc_adma.o
+obj-$(CONFIG_SATA_FSL) += sata_fsl.o
obj-$(CONFIG_PATA_ALI) += pata_ali.o
obj-$(CONFIG_PATA_AMD) += pata_amd.o
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index 026439e..1232dcb 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -156,7 +156,7 @@ void ata_tf_read(struct ata_port *ap, struct ata_taskfile
*tf)
{
struct ata_ioports *ioaddr = ap-ioaddr;
- tf-command = ata_check_status(ap);
+ tf-command = ata_chk_status(ap);
tf-feature = ioread8(ioaddr-error_addr);
tf-nsect = ioread8(ioaddr-nsect_addr);
tf-lbal = ioread8(ioaddr-lbal_addr);
diff --git a/drivers/ata/pata_acpi.c b/drivers/ata/pata_acpi.c
index 5d3920f..0f6f7bc 100644
--- a/drivers/ata/pata_acpi.c
+++ b/drivers/ata/pata_acpi.c
@@ -370,8 +370,10 @@ static struct pci_driver pacpi_pci_driver = {
.id_table = pacpi_pci_tbl,
.probe = pacpi_init_one,
.remove = ata_pci_remove_one,
+#ifdef CONFIG_PM
.suspend= ata_pci_device_suspend,
.resume = ata_pci_device_resume,
+#endif
};
static int __init pacpi_init(void)
diff --git a/drivers/ata/pata_bf54x.c b/drivers/ata/pata_bf54x.c
index 747549e..b5e3842 100644
--- a/drivers/ata/pata_bf54x.c
+++ b/drivers/ata/pata_bf54x.c
@@ -1092,14 +1092,15 @@ static unsigned int bfin_bus_softreset(struct ata_port
*ap,
* Note: Original code is ata_std_softreset().
*/
-static int bfin_std_softreset(struct ata_port *ap, unsigned int *classes,
+static int bfin_std_softreset(struct ata_link *link, unsigned int *classes,
unsigned long deadline)
{
+ struct ata_port *ap = link-ap;
unsigned int slave_possible = ap-flags ATA_FLAG_SLAVE_POSS;
unsigned int devmask = 0, err_mask;
u8 err;
- if (ata_port_offline(ap)) {
+ if (ata_link_offline(link)) {
classes[0] = ATA_DEV_NONE;
goto out;
}
@@ -1122,9 +1123,11 @@ static int bfin_std_softreset(struct ata_port *ap,
unsigned int *classes,
}
/* determine by signature whether we have ATA or ATAPI devices */
- classes[0] = ata_dev_try_classify(ap, 0, err);
+ classes[0] = ata_dev_try_classify(ap-link.device[0],
+ devmask (1 0), err);
if (slave_possible err != 0x81)
- classes[1] = ata_dev_try_classify(ap, 1, err);
+ classes[1] = ata_dev_try_classify(ap-link.device[1],
+
Re: Inquiry data and emulated SG devices
(cc-ing linux-ide)
Mathieu Fluhr wrote:
Hello all,
First of all, let me introduce myself a little bit. I am the responsable
for the development of the Nero Linux burning application. So I have
access to all the source code of the application.
Now let's go with the story: It seems that there is a slight problem in
the libata (and also the new pata_xxx) interfaces with the data returned
by the INQUIRY cmd since every S-ATA or IDE device is assumed to be a
SCSI dev.
Normally, the IDE devices (physical type) can be differentied with the
format field of the inquiry data, i.e. the last bytes (ANSI version) are
set to 0 - This is done and works great with USB external devices for
example.
The thing is that with S-ATA/IDE devices when using the libata/pata
driver, the version field is (always?) set to 5, as any _real_ SCSI
device, and thus the physical device type cannot be checked anymore.
This doesn't seem a very reliable way to identify an IDE device, as all
that 0 means is that the device does not claim conformance to any
standard. I would think it would be legitimate for an IDE device to put
a value like 5 in there as well, if it complies with SPC-4..
In the case of libata though, that appears to be due to this code in
drivers/ata/libata-scsi.c:
/* ATAPI devices typically report zero for their SCSI version,
* and sometimes deviate from the spec WRT response data
* format. If SCSI version is reported as zero like normal,
* then we make the following fixups: 1) Fake MMC-5 version,
* to indicate to the Linux scsi midlayer this is a modern
* device. 2) Ensure response data format / ATAPI information
* are always correct.
*/
if (buf[2] == 0) {
buf[2] = 0x5;
buf[3] = 0x32;
}
This technically seems to go against what the SCSI/ATA Translation (SAT)
spec says regarding INQUIRY on ATAPI devices: the SATL shall use the
ATA PACKET Command feature set to pass all INQUIRY commands and
parameter data to the ATAPI device without altering the INQUIRY
commands or the parameter data. However, it might realistically be
needed if the SCSI layer in the kernel has problems with a device
indicating it supports no SCSI version..
I cannot go so deep in details, but our burn engine is differentiating
IDE and read-good-old-SCSI devices and handles them sometimes in a
different way, so this differenciation is really important for us.
- How can I detect the real physical device type now?
I don't have a great answer off the top of my head..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
-
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 #upstream 1/2] libata: move command post processing to __ata_qc_complete()
Tejun Heo wrote: Jeff Garzik wrote: Tejun Heo wrote: Some commands need post-processing after successful completion. This was done in ata_scsi_qc_complete() till now but command post processing doesn't belong to SAT layer. Move them to __ata_qc_complete() and, while at it, restructure a bit to ease adding post-processing for other commands. Signed-off-by: Tejun Heo [EMAIL PROTECTED] BTW, while doing the TEST UNIT READY emulation patch for ATA (recently withdrawn from libata-dev.git#upstream), I found a problem with the interface that was difficult to get around: TEST UNIT READY simulation code really wants to look at the result TF of CHECK POWER MODE, even if ATA_ERR is asserted, before determining whether or not to call that command an error. Maybe the EH scheduling could be moved until after -complete_fn, to permit -complete_fn users to manipulate qc-err_mask etc.? Yeah, right. Device error is a special case. In many cases, devices can operate without any problem after asserting error and for some commands error is used to signal certain conditions. I think the least intrusive way would be a qc flag - ATA_QCFLAG_ALLOW_DEVERR, maybe. Also, I'm not sure whether EH should kick in when passthru commands fail with a device error. Maybe libata should just report the error to the issuer and continue operation? Good point and agreed -- I definitely think passthru commands want device errors immediately. That vastly increases the utility of passthru to be used in test suites and stuff, where you know a lot of operations should fail, by design. (i.e. intentionally submitting an invalid command, to test that 'command aborted' is returned) 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: Inquiry data and emulated SG devices
Robert Hancock wrote:
This doesn't seem a very reliable way to identify an IDE device, as all
that 0 means is that the device does not claim conformance to any
standard. I would think it would be legitimate for an IDE device to put
a value like 5 in there as well, if it complies with SPC-4..
Via the this-doesnt-really-matter-but-it-should-be-noted department:
According to the latest on t10.org, MMC retroactively permitted SCSI
version to be zero, for MMC-compliant USB and ATAPI devices.
In the case of libata though, that appears to be due to this code in
drivers/ata/libata-scsi.c:
/* ATAPI devices typically report zero for their SCSI version,
* and sometimes deviate from the spec WRT response data
* format. If SCSI version is reported as zero like normal,
* then we make the following fixups: 1) Fake MMC-5 version,
* to indicate to the Linux scsi midlayer this is a modern
* device. 2) Ensure response data format / ATAPI information
* are always correct.
*/
if (buf[2] == 0) {
buf[2] = 0x5;
buf[3] = 0x32;
}
This technically seems to go against what the SCSI/ATA Translation (SAT)
spec says regarding INQUIRY on ATAPI devices: the SATL shall use the
ATA PACKET Command feature set to pass all INQUIRY commands and
parameter data to the ATAPI device without altering the INQUIRY
commands or the parameter data. However, it might realistically be
needed if the SCSI layer in the kernel has problems with a device
indicating it supports no SCSI version..
The above tweak is entirely software-software communication... as the
comment you quoted notes, it's just a signal to the SCSI midlayer.
At the moment, the SCSI midlayer assumes any device that reports scsi
version as less than 2 is forced to SCSI version 2. Ultimately that's
incorrect behavior for all ATAPI devices (and later MMC revisions).
At the time, libata simply worked around this SCSI buglet in its own
code, since that was easier than auditing all SCSI code paths to ensure
new ATAPI/USB MMC logic does not break ancient devices.
But if someone is motivated enough to revisit this...
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] sata_sis: fix SCR read breakage
SCR read for controllers which uses PCI configuration space for SCR
access got broken while adding @val argument to SCR accessors. Fix
it.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/sata_sis.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/ata/sata_sis.c b/drivers/ata/sata_sis.c
index 8d98a9f..dc8e5c0 100644
--- a/drivers/ata/sata_sis.c
+++ b/drivers/ata/sata_sis.c
@@ -166,11 +166,11 @@ static unsigned int get_scr_cfg_addr(struct ata_port *ap,
unsigned int sc_reg)
return addr;
}
-static u32 sis_scr_cfg_read (struct ata_port *ap, unsigned int sc_reg)
+static u32 sis_scr_cfg_read (struct ata_port *ap, unsigned int sc_reg, u32
*val)
{
struct pci_dev *pdev = to_pci_dev(ap-host-dev);
unsigned int cfg_addr = get_scr_cfg_addr(ap, sc_reg);
- u32 val, val2 = 0;
+ u32 val2 = 0;
u8 pmr;
if (sc_reg == SCR_ERROR) /* doesn't exist in PCI cfg space */
@@ -178,13 +178,16 @@ static u32 sis_scr_cfg_read (struct ata_port *ap,
unsigned int sc_reg)
pci_read_config_byte(pdev, SIS_PMR, pmr);
- pci_read_config_dword(pdev, cfg_addr, val);
+ pci_read_config_dword(pdev, cfg_addr, val);
if ((pdev-device == 0x0182) || (pdev-device == 0x0183) ||
(pdev-device == 0x1182) || (pmr SIS_PMR_COMBINED))
pci_read_config_dword(pdev, cfg_addr+0x10, val2);
- return (val|val2) 0xfffb; /* avoid problems with powerdowned
ports */
+ *val |= val2;
+ *val = 0xfffb; /* avoid problems with powerdowned ports */
+
+ return 0;
}
static void sis_scr_cfg_write (struct ata_port *ap, unsigned int sc_reg, u32
val)
@@ -214,7 +217,7 @@ static int sis_scr_read(struct ata_port *ap, unsigned int
sc_reg, u32 *val)
return -EINVAL;
if (ap-flags SIS_FLAG_CFGSCR)
- return sis_scr_cfg_read(ap, sc_reg);
+ return sis_scr_cfg_read(ap, sc_reg, val);
pci_read_config_byte(pdev, SIS_PMR, pmr);
-
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 Sil3512 bug?
MisterE wrote: Oct 13 13:01:26 fileserver kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x240 action 0x0 Oct 13 13:01:26 fileserver kernel: ata4.00: (BMDMA2 stat 0x650001) Oct 13 13:01:26 fileserver kernel: ata4.00: cmd ca/00:f8:47:e1:5e/00:00:00:00:00/e4 tag 0 cdb 0x0 data 126976 out Oct 13 13:01:26 fileserver kernel: res 51/04:98:a7:e1:5e/00:00:00:00:00/e4 Emask 0x1 (device error) Oct 13 13:01:26 fileserver kernel: ata4.00: configured for UDMA/100 Oct 13 13:01:26 fileserver kernel: ata4: EH complete Oct 13 13:01:26 fileserver kernel: sd 3:0:0:0: [sdd] 976773168 512-byte hardware sectors (500108 MB) Oct 13 13:01:26 fileserver kernel: sd 3:0:0:0: [sdd] Write Protect is off Oct 13 13:01:26 fileserver kernel: sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00 Oct 13 13:01:26 fileserver kernel: sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA I'm not sure if it will result in corrupt data? But i don't trust it anymore. That looks like a data transmission error. When you're transferring massive amount of data, things like that can happen and it won't cause data corruption. You people advise me to not buy the Promise SATA300 TX4 controller and this Sweex PU102 (3512) seems to have problems. Not much choices left except the really expensive solutions. Is it really so hard to build a controller without problems?!? :( It seems so. :-( -- 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: FW: LIBATA issue with SATA drive
Hello, all. Torsten, Clarence is reporting similar problem on 2.6.22. The original message follows. I'm using the 2.6.22 sources with a Sii3132 SATA controller and a Seagate HDD. What I've noticed is that it often fails to boot with this configuration. Warm boots appear to always fail while cold boots (power-cycles) fail maybe 20%-50% of the time. Here's a log from my last attempt: Loading iSCSI transport class v2.0-724. PCI: Enabling device :01:00.0 ( - 0003) scsi0 : sata_sil24 scsi1 : sata_sil24 ata1: SATA max UDMA/100 cmd 0xe1258000 ctl 0x bmdma 0x irq 0 ata2: SATA max UDMA/100 cmd 0xe125a000 ctl 0x bmdma 0x irq 0 ata1: SATA link down (SStatus 0 SControl 0) ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 0) ata2.00: qc timeout (cmd 0xec) ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4) ata2: failed to recover some devices, retrying in 5 secs ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 0) ata2.00: qc timeout (cmd 0xec) ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4) ata2: limiting SATA link speed to 1.5 Gbps ata2.00: limiting speed to UDMA7:PIO5 ata2: failed to recover some devices, retrying in 5 secs ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 10) ata2.00: qc timeout (cmd 0xec) ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4) ata2: failed to recover some devices, retrying in 5 secs ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 10) ata2: EH pending after completion, repeating EH (cnt=4) i2c /dev entries driver IBM IIC driver v2.1 If the boot succeeds, I have no further problems with HDD access. I also did not see this problem with the 2.6.17 kernel. Do you have any ideas as to what may be happening? We're running on a PPC440SPE processor. Thanks in advance, The symptom seems very similar to yours but the kernel is 2.6.22 which doesn't have the SG change which you found out to be broken. Can you update us on how the testing of patched kernel went? -- 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 #upstream 1/2] libata: move command post processing to __ata_qc_complete()
BTW, while doing the TEST UNIT READY emulation patch for ATA (recently withdrawn from libata-dev.git#upstream), I found a problem with the interface that was difficult to get around: TEST UNIT READY simulation code really wants to look at the result TF of CHECK POWER MODE, even if ATA_ERR is asserted, before determining whether or not to call that command an error. Maybe the EH scheduling could be moved until after -complete_fn, to permit -complete_fn users to manipulate qc-err_mask etc.? Yeah, right. Device error is a special case. In many cases, devices can operate without any problem after asserting error and for some commands error is used to signal certain conditions. I think the least intrusive way would be a qc flag - ATA_QCFLAG_ALLOW_DEVERR, maybe. Also, I'm not sure whether EH should kick in when passthru commands fail with a device error. Maybe libata should just report the error to the issuer and continue operation? Good point and agreed -- I definitely think passthru commands want device errors immediately. That vastly increases the utility of passthru to be used in test suites and stuff, where you know a lot of operations should fail, by design. (i.e. intentionally submitting an invalid command, to test that 'command aborted' is returned) Absolutely! Speaking as an 'application programmer', much of the utility of passthru is lost if the device errors are not immediately returned to the caller. Cheers, Bruce 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
seagate disks on sil3114 - slow?
Dear all, I just now realize that all disk i.o. on my machine is quite slow compared with the pata disks I had before. Furthermore I recognized that I only have seagates (ST3400832AS,ST3400620AS,ST3750640AS,ST3750640AS) connected to a sil3114 controller. Being on kernel 2.6.23.1 and stumbling across http://home-tj.org/wiki/index.php/Sil_m15w I am now wondering if this patch made it already in kernel (or when it will make it if it is not yet in/why never). Best, 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
