Re: [RFC-UGLYPATCH] ata: small optimization in linux/libata.h
Tejun Heo writes: Harvey Harrison wrote: I know it's ugly, but I had it done anyways. The one real problem I have with it is that if link and ap-pmp_link ever get changed to different types the compiler will not even warn as we cast away to (char *). To make it a bit more robust, a BUILD_BUG_ON checking the pointer types may be a good idea. Sorry, but Nacked-by: Tejun Heo [EMAIL PROTECTED] Can't say I really blame you, other than this one error, drivers/ata builds almost sparse-clean, and I had it done anyways. I wonder if a helper similar in spirit would be any better. This doesn't have any typechecking, but perhaps that could be dealt with too. Ran into a similar problem with mmzone.h, akpm has the patch, but maybe a helper (kernel.h?) would be cleaner. Or maybe it's just better to live with the sparse warnings /* * return the offset of the ptr from the base, in bytes. */ #define PTR_OFF(base, ptr) \ ((char *)ptr - (char *)base) if (PTR_OFF(ap-pmp_link, ++link) ap-nr_pmp_links * sizeof(*link)) return link; Can you please explain why it warns against pointer substraction? Is it because it can generate division? Pointer subtraction as commonly implemented implies a signed integer division, because it may need to convert a negative byte pointer difference to a negative array index difference. Seasoned C programmers avoid it like the plague... - 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 09/13] sata_mv ncq Use DMA memory pools for hardware memory tables
Mark Lord writes: Tejun Heo wrote: .. I'm skeptical about the benefit of IRQ coalescing on storage controllers. Coalescing improves performance when there are many small requests to complete and if you put a lot of small non-consecutive requests to a disk, it gets really really really slow and IRQ coalescing just doesn't matter at all. The only way to achieve high number of completions is to issue small commands to consecutive addresses which is just silly. In storage, high volume transfer is achieved through request coalescing not completion coalescing and this is true for even SDDs. .. One cool thing with the Marvell cores, is that they actually implement transaction based IRQ coalescing, whereby a number of related I/O commands (say, all the RAID5 member commands generated by a single R/W request) can be tagged together, generating an interrupt only when they all complete (or after a timeout if something goes wrong). We don't have anything resembling an appropriate abstraction for that yet, so I doubt that we could really take advantage of it. Promise SATA controllers have this feature too, though sata_promise doesn't make use of 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
Re: Problem with ata layer in 2.6.24
Gene Heskett writes: On Tuesday 29 January 2008, Alan Cox wrote: As slight change here, I was going to use the same .config as 2.6.24-rc8, but just discovered that neither rc8 nor final is finding the drivers for my If it is not finding a driver that is nothing to do with libata. It means it's not being loaded by the distribution, or the distribution kernel is too old (2.6.22) for the hardware - in which case see the Fedora respins which are on 2.6.23.something right now. Alan Home built kernel Alan. But you are as good as anyone to tell me what I need to turn on in order for this dvdwriter to be enabled: [ 28.862478] ata2.00: ATAPI: LITE-ON DVDRW SHM-165H6S, HS06, max UDMA/66 [ 28.908647] ata2.00: limited to UDMA/33 due to 40-wire cable [ 29.081253] ata2.00: configured for UDMA/33 it has had several 80 wire cables tried, hasn't fixed this, and does not seem to effect its operation when it does work. [ 29.132405] scsi 1:0:0:0: CD-ROMLITE-ON DVDRW SHM-165H6S HS06 PQ: 0 ANSI: 5 [ 43.450795] scsi 1:0:0:0: Attached scsi generic sg1 type 5 --- No further mention of it in dmesg, and k3b cannot find the drive at any /dev/sgX address. .config attached, what else do I need to turn on? ... # CONFIG_BLK_DEV_SR is not set For starters, enable CONFIG_BLK_DEV_SR. - 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: Problem with ata layer in 2.6.24
Gene Heskett writes:
On Monday 28 January 2008, Peter Zijlstra wrote:
On Mon, 2008-01-28 at 09:17 +0100, Mikael Pettersson wrote:
1. Wrong mailing list; use linux-ide (@vger) instead.
What, and keep all us other interested people in the dark?
As a test, I tried rebooting to the latest fedora kernel and found it kills
X,
so I'm back to the second to last fedora version ATM, and the
third 'smartctl -t lng /dev/sda' in 24 hours is running now. The first two
completed with no errors.
I've added the linux-ide list to refresh those people of the problem,
the logs are being spammed by this message stanza:
Jan 28 04:46:25 coyote kernel: [26550.290016] ata1.00: exception Emask 0x0
SAct 0x0 SErr 0x0 action 0x2 frozen
Jan 28 04:46:25 coyote kernel: [26550.290028] ata1.00: cmd
35/00:58:c9:9c:0a/00:01:00:00:00/e0 tag 0 dma 176128 out
Jan 28 04:46:25 coyote kernel: [26550.290029] res
40/00:01:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
Jan 28 04:46:25 coyote kernel: [26550.290032] ata1.00: status: { DRDY }
Jan 28 04:46:25 coyote kernel: [26550.290060] ata1: soft resetting link
Jan 28 04:46:25 coyote kernel: [26550.452301] ata1.00: configured for
UDMA/100
Jan 28 04:46:25 coyote kernel: [26550.452318] ata1: EH complete
Jan 28 04:46:25 coyote kernel: [26550.455898] sd 0:0:0:0: [sda] 390721968
512-byte hardware sectors (200050 MB)
Jan 28 04:46:25 coyote kernel: [26550.456151] sd 0:0:0:0: [sda] Write
Protect is off
Jan 28 04:46:25 coyote kernel: [26550.456403] sd 0:0:0:0: [sda] Write cache:
enabled, read cache: enabled, doesn't
support DPO or FUA
It's not obvious from this incomplete dmesg log what HW or driver
is behind ata1, but if the 2.6.24-rc7 kernel matches the 2.6.24 one,
it should be pata_amd driving a WDC disk:
[ 30.702887] pata_amd :00:09.0: version 0.3.10
[ 30.703052] PCI: Setting latency timer of device :00:09.0 to 64
[ 30.703188] scsi0 : pata_amd
[ 30.709313] scsi1 : pata_amd
[ 30.710076] ata1: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xf000 irq
14
[ 30.710079] ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xf008 irq
15
[ 30.864753] ata1.00: ATA-6: WDC WD2000JB-00EVA0, 15.05R15, max UDMA/100
[ 30.864756] ata1.00: 390721968 sectors, multi 16: LBA48
[ 30.871629] ata1.00: configured for UDMA/100
Unfortunately we also see:
[ 48.285456] nvidia: module license 'NVIDIA' taints kernel.
[ 48.549725] ACPI: PCI Interrupt :02:00.0[A] - Link [APC4] - GSI 19
(level, high) - IRQ 20
[ 48.550149] NVRM: loading NVIDIA UNIX x86 Kernel Module 169.07 Thu Dec
13 18:42:56 PST 2007
We have no way of debugging that module, so please try 2.6.24 without it.
If the problems persist, please try to capture a complete log from the
failing kernel -- the interesting bits are everything from initial boot
up to and including the first few errors. You may need to increase the
kernel's log buffer size if the log gets truncated (CONFIG_LOG_BUF_SHIFT).
There are no pata_amd changes from 2.6.24-rc7 to 2.6.24 final.
-
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: Linux 2.6.24 sata_promise SATA300TX4 problems
Peter Favrholdt writes:
Hi Mikael list,
I have previously reported problems with my setup:
SATA300TX4 + 4 Seagate Barracuda ES 500GB
I just tested with 2.6.24. After copying approx 25GB of each drive using
dd if=/dev/sd[abcd] of=/dev/null bs=1M
sda failed with the following message:
[ 1060.069489] ata1: SError: { 10B8B Dispar BadCRC TrStaTrns }
[ 1060.069498] ata1.00: cmd 25/00:00:90:2c:e6/00:02:01:00:00/e0 tag 0
dma 262144 in
[ 1060.069501] res 40/00:28:00:00:00/00:00:00:00:00/40 Emask
0x4 (timeout)
I have included lspci and dmesg output below.
My system is rock solid using 2.6.21-rc2 with Mikael Pettersons 1.5Gbps
patch.
...
[ 1060.069478] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x138
action 0x2 frozen
[ 1060.069489] ata1: SError: { 10B8B Dispar BadCRC TrStaTrns }
[ 1060.069498] ata1.00: cmd 25/00:00:90:2c:e6/00:02:01:00:00/e0 tag 0
dma 262144 in
[ 1060.069501] res 40/00:28:00:00:00/00:00:00:00:00/40 Emask
0x4 (timeout)
[ 1060.069505] ata1.00: status: { DRDY }
[ 1065.437567] ata1: port is slow to respond, please be patient (Status
0xff)
[ 1070.114210] ata1: device not ready (errno=-16), forcing hardreset
[ 1070.114219] ata1: hard resetting link
[ 1076.320932] ata1: port is slow to respond, please be patient (Status
0xff)
[ 1080.158924] ata1: COMRESET failed (errno=-16)
Mysterious. What you have there is a transmission error between the
controller and the disk, which is bad in and by itself, but then there's
a sequence of COMRESETs that fail to bring the port or disk back to life.
The original error is not a driver error but something caused by your
system, be it a dodgy cable, a poorly seated cable, or electrical
interference. But the failed COMRESETs is a concern as I've seen them
in other reports as well.
Me worried ...
So going back to 2.6.21-rc2 makes the system stable again? Can you do some
more testing to see at what point the system becomes less stable? I.e.,
2.6.21-rcI, 2.6.22, 2.6.22-rcJ, 2.6.23, or 2.6.24-rcJ?
FWIW, I just completed some testing of a 300 TX4 card with kernel 2.6.24,
including dd:s, fscks, mkfs:s, and copying about 400GB of data from one drive
(Samsung) to another (Seagate 7200.10) on that card, and I cannot seem to break
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
Re: Linux 2.6.24 sata_promise SATA300TX4 problems
Peter Favrholdt writes: Hi Mikael, Thanks for your reply :-) Mikael Pettersson wrote: Mysterious. What you have there is a transmission error between the controller and the disk, which is bad in and by itself, but then there's a sequence of COMRESETs that fail to bring the port or disk back to life. The original error is not a driver error but something caused by your system, be it a dodgy cable, a poorly seated cable, or electrical interference. But the failed COMRESETs is a concern as I've seen them in other reports as well. Maybe I should try switching cables (again). Or it could be a motherboard issue (NFORCE2)? Me worried ... So going back to 2.6.21-rc2 makes the system stable again? Can you do some more testing to see at what point the system becomes less stable? I.e., 2.6.21-rcI, 2.6.22, 2.6.22-rcJ, 2.6.23, or 2.6.24-rcJ? I believe the important part is your 1.5Gbps patch which I applied to 2.6.21-rc2. Maybe the reason for being stable is that the transmission error will not show up at that speed - thus not having anything to do with the kernel version. I'm quite sure the problem is there using 2.6.21-rc2 at 3Gbps. FWIW, I just completed some testing of a 300 TX4 card with kernel 2.6.24, including dd:s, fscks, mkfs:s, and copying about 400GB of data from one drive (Samsung) to another (Seagate 7200.10) on that card, and I cannot seem to break it. I believe it only happens if I stress all four drives simultanously. So maybe the transmission error is somehow related to the overall stress of the PCI bus/card/chip/whatever? If it is not too much of a hassle, could you please make a 1.5Gbps patch for 2.6.24 for me to try out? If it solves the problem (without me ever touching the cables) we know for sure it is speed-related and not due to kernel version. No problem. I had intended to drop that patch after 2.6.24-rc8 as it ought to be obsolete, but then again it might not be. It's available here: http://user.it.uu.se/~mikpe/linux/patches/2.6/patch-sata_promise-limit-sataii-to-1.5Gbps-2.6.24 - 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: The SX4 challenge
Jeff Garzik writes: Promise just gave permission to post the docs for their PDC20621 (i.e. SX4) hardware: http://gkernel.sourceforge.net/specs/promise/pdc20621-pguide-1.2.pdf.bz2 joining the existing PDC20621 DIMM and PLL docs: http://gkernel.sourceforge.net/specs/promise/pdc20621-pguide-dimm-1.6.pdf.bz2 http://gkernel.sourceforge.net/specs/promise/pdc20621-pguide-pll-ata-timing-1.2.pdf.bz2 So, the SX4 is now open. Yay :) I am hoping to talk Mikael into becoming the sata_sx4 maintainer, and finally integrating my 'new-eh' conversion in libata-dev.git. The best solution would be if some storage driver person would take on the SX4 challenge and work towards integrating the SX4 into Linux' RAID framework. If no-one steps forward I'll take over Jeff's SX4 card and just maintain sata_sx4 as a plain non-RAID driver. Unfortunately I don't have the time needed to turn it into a decent RAID or RAID-offload driver myself. /Mikael But now is a good time to remind people how lame the sata_sx4 driver software really is -- and I should know, I wrote it. The SX4 hardware, simplified, is three pieces: XOR engine (for raid5), host-board memcpy engine, and several ATA engines (and some helpful transaction sequencing features). Data for each WRITE command is first copied to the board RAM, then the ATA engines DMA to/from the board RAM. Data for each READ command is copied to board RAM via the ATA engines, then DMA'd across PCI to your host memory. Therefore, while it is not hardware RAID, the SX4 provides all the pieces necessary to offload RAID1 and RAID5, and handle other RAID levels optimally. RAID1 and 5 copies can be offloaded (provided all copies go to SX4-attached devices of course). RAID5 XOR gen and checking can be offloaded, allowing the OS to see a single request, while the hardware processes a sequence of low-level requests sent in a batch. This hardware presents an interesting challenge: it does not really fit into software RAID (i.e. no RAID) /or/ hardware RAID categories. The sata_sx4 driver presents the no-RAID configuration, while is terribly inefficient: WRITE: submit host DMA (copy to board) host DMA completion via interrupt submit ATA command ATA command completion via interrupt READ: submit ATA command ATA command completion via interrupt submit host DMA (copy from board) host DMA completion via interrupt Thus, the SX4 challenge is a challenge to developers to figure out the most optimal configuration for this hardware, given the existing MD and DM work going on. Now, it must be noted that the SX4 is not current-gen technology. Most vendors have moved towards an IOP model, where the hw vendor puts most of their hard work into an ARM/MIPS firmware, running on an embedded chip specially tuned for storage purposes. (ref hptiop and stex drivers, very very small SCSI drivers) I know Dan Williams @ Intel is working on very similar issues on the IOP -- async memcpy, XOR offload, etc. -- and I am hoping that, due to that current work, some of the good ideas can be reused with the SX4. Anyway... it's open, it's interesting, even if it's not current-gen tech anymore. You can probably find them on Ebay or in an out-of-the-way computer shop somewhere. 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: sata_promise: Keeps saying SATA link down (SStatus 0 SControl 0)
Kurt Roeckx writes: On Tue, Jan 15, 2008 at 10:28:06AM +0100, Mikael Pettersson wrote: 00:08.0 RAID bus controller: Promise Technology, Inc. PDC20376 (FastTrak 376) (rev 02) ... 00:08.0 0104: 105a:3376 (rev 02) Let me guess, this is a Promise chip included on the mainboard as a RAID controller, and not an add-on PCI card? Yes, it's a K8V motherboard which has that onboard. If it's a mainboard chip, please enter the BIOS and see if it can be configured for non-RAID mode. If it can, please reconfigure it and boot Linux. Does it still claim to be a 20376 or is it now a 20378? I can't find an option to turn that off in the BIOS. If it did, I'd probably have turned it off already. I've also opened the case and it says PDC20376 on the chip. Ok. I haven't yet found any information about the 20376 which could explain why the 20376 fails while the 20378 works. For now, you can disable hotplugging in the driver by applying the patch below. This should at least bring back some stability to your system. Longer-term I guess I'll have to invent a blacklist mechanism to automatically prevent 20376 chips from enabling hotplugging. That is, unless someone can show me a system where a 20376 actually does work with hotplugging, in which case I'd need a module parameter (yuck) or some form of dynamic detection of this condition. /Mikael --- linux-2.6.23/drivers/ata/sata_promise.c.~1~ 2007-10-10 10:33:23.0 +0200 +++ linux-2.6.23/drivers/ata/sata_promise.c 2008-01-16 10:46:29.0 +0100 @@ -743,6 +743,7 @@ static irqreturn_t pdc_interrupt (int ir if (hotplug_status 0xff) writel(hotplug_status | 0xff, mmio_base + hotplug_offset); hotplug_status = 0xff; /* clear uninteresting bits */ + hotplug_status = 0; /* ignore hotplug status */ /* reading should also clear interrupts */ mask = readl(mmio_base + PDC_INT_SEQMASK); @@ -938,9 +939,9 @@ static void pdc_host_init(struct ata_hos tmp = readl(mmio + hotplug_offset); writel(tmp | 0xff, mmio + hotplug_offset); - /* unmask plug/unplug ints */ + /* mask plug/unplug ints */ tmp = readl(mmio + hotplug_offset); - writel(tmp ~0xff, mmio + hotplug_offset); + writel(tmp | 0xff, mmio + hotplug_offset); /* don't initialise TBG or SLEW on 2nd generation chips */ if (is_gen2) - 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_promise: Keeps saying SATA link down (SStatus 0 SControl 0)
Kurt Roeckx writes: Hi, I've just tried the 2.6.24-rc7 kernel (from Debian's experimental kernel archive), running the x86_64 kernel. I keep getting things like this in my log: Jan 13 19:21:10 intrepid kernel: ata2: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xa frozen Jan 13 19:21:10 intrepid kernel: ata2: hotplug_status 0x20 Jan 13 19:21:11 intrepid kernel: ata2: soft resetting link Jan 13 19:21:11 intrepid kernel: ata2: SATA link down (SStatus 0 SControl 0) Jan 13 19:21:11 intrepid kernel: ata2: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xb t4 Jan 13 19:21:11 intrepid kernel: ata2: hotplug_status 0x2 Jan 13 19:21:11 intrepid kernel: ata2: soft resetting link Jan 13 19:21:11 intrepid kernel: ata2: SATA link down (SStatus 100 SControl 0) Jan 13 19:21:11 intrepid kernel: ata2: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xb t3 Jan 13 19:21:11 intrepid kernel: ata2: hotplug_status 0x20 Jan 13 19:21:13 intrepid kernel: ata2: soft resetting link Jan 13 19:21:13 intrepid kernel: ata2: SATA link down (SStatus 100 SControl 0) Jan 13 19:21:13 intrepid kernel: ata2: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xb t2 Jan 13 19:21:13 intrepid kernel: ata2: hotplug_status 0x20 Jan 13 19:21:14 intrepid kernel: ata2: soft resetting link Jan 13 19:21:14 intrepid kernel: ata2: SATA link down (SStatus 0 SControl 0) Jan 13 19:21:14 intrepid kernel: ata2: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xb t1 Jan 13 19:21:14 intrepid kernel: ata2: hotplug_status 0x2 Jan 13 19:21:15 intrepid kernel: ata2: soft resetting link Jan 13 19:21:15 intrepid kernel: ata2: SATA link down (SStatus 100 SControl 0) Jan 13 19:21:15 intrepid kernel: ata2: EH pending after 5 tries, giving up Jan 13 19:21:15 intrepid kernel: ata2: EH complete Jan 13 19:21:15 intrepid kernel: ata2: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xa frozen Jan 13 19:21:15 intrepid kernel: ata2: hotplug_status 0x2 Jan 13 19:21:16 intrepid kernel: ata2: soft resetting link Jan 13 19:21:16 intrepid kernel: ata2: SATA link down (SStatus 100 SControl 0) Jan 13 19:21:16 intrepid kernel: ata2: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xb t4 Jan 13 19:21:16 intrepid kernel: ata2: hotplug_status 0x20 Jan 13 19:21:17 intrepid kernel: ata2: soft resetting link Jan 13 19:21:17 intrepid kernel: ata2: SATA link down (SStatus 0 SControl 0) Jan 13 19:21:17 intrepid kernel: ata2: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xb t3 Jan 13 19:21:17 intrepid kernel: ata2: hotplug_status 0x2 [...] ata2 is the second port of my promise controller in which nothing is plugged in. I also have an sata_via with 2 disks plugged in. All 3 disks seem to come up properly as far as I can see from the log, but I've just rebooted in an older kernel version. With my current 2.6.22 kernel I just get 1 line saying that the link is down and then it stops. I think the important part of the log I get when booting is: Jan 13 19:20:45 intrepid kernel: sata_promise :00:08.0: version 2.11 Jan 13 19:20:45 intrepid kernel: ACPI: PCI Interrupt :00:08.0[A] - GSI 18 (level, low) - IRQ 18 Jan 13 19:20:45 intrepid kernel: scsi0 : sata_promise Jan 13 19:20:45 intrepid kernel: scsi1 : sata_promise Jan 13 19:20:45 intrepid kernel: scsi2 : sata_promise Jan 13 19:20:45 intrepid kernel: ata1: SATA max UDMA/133 mmio [EMAIL PROTECTED] port 0xfdf00200 irq 18 Jan 13 19:20:45 intrepid kernel: ata2: SATA max UDMA/133 mmio [EMAIL PROTECTED] port 0xfdf00280 irq 18 Jan 13 19:20:45 intrepid kernel: ata3: PATA max UDMA/133 mmio [EMAIL PROTECTED] port 0xfdf00300 irq 18 Jan 13 19:20:45 intrepid kernel: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Jan 13 19:20:45 intrepid kernel: ata1.00: ATA-7: WDC WD5000YS-01MPB1, 09.02E09, max UDMA/133 Jan 13 19:20:45 intrepid kernel: ata1.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 0/32) Jan 13 19:20:45 intrepid kernel: ata1.00: configured for UDMA/133 Jan 13 19:20:45 intrepid kernel: ata2: SATA link down (SStatus 0 SControl 0) Jan 13 19:20:45 intrepid kernel: scsi 0:0:0:0: Direct-Access ATA WDC WD5000YS-01M 09.0 PQ: 0 ANSI: 5 Jan 13 19:20:45 intrepid kernel: sata_via :00:0f.0: version 2.3 Jan 13 19:20:45 intrepid kernel: ACPI: PCI Interrupt :00:0f.0[B] - GSI 20 (level, low) - IRQ 20 Jan 13 19:20:45 intrepid kernel: sata_via :00:0f.0: routed to hard irq line 10 Jan 13 19:20:45 intrepid kernel: scsi3 : sata_via Jan 13 19:20:45 intrepid kernel: scsi4 : sata_via Jan 13 19:20:45 intrepid kernel: ata4: SATA max UDMA/133 cmd 0xe800 ctl 0xe400 bmdma 0xd400 irq 20 Jan 13 19:20:45 intrepid kernel: ata5: SATA max UDMA/133 cmd 0xe000 ctl 0xd800 bmdma 0xd408 irq 20 Jan 13 19:20:45 intrepid kernel: Driver 'sd' needs updating - please use bus_type methods Jan 13 19:20:45 intrepid kernel: sd 0:0:0:0: [sda]
Re: SATA timeouts on two disks
Jim MacBaine writes: Hi, Recently I'm experiencing strange sata errors on my desktop system. The system was recently equipped with three 250 GB SATA drives from Clue #1: added drives three different manufacturers and I'm having an identical problem on two of them. The drives are connected to two on-board controllers on an Asus A8V board, which were both running with Linux for more than two years with older SATA disks without problems. A hardware failure seems unlikely to me as the same error occurrs on two brand new disks from two different manufacturers. I'm running a vanilla 2.6.23.12 kernel. Errror on sdc happened about 10 times tonight, each time I could hear the disk spin down and up again, while the system was frozen for several seconds: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x18 action 0x2 frozen ata2.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 res 40/00:00:00:00:40/00:00:00:00:00/00 Emask 0x4 (timeout) ata2: soft resetting port ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata2.00: configured for UDMA/133 ata2: EH complete sd 1:0:0:0: [sdb] 488397168 512-byte hardware sectors (250059 MB) sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA In the log I also found several identical errors on one other drive: ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata5.00: cmd 25/00:08:b7:f2:11/00:00:13:00:00/e0 tag 0 cdb 0x0 data 4096 in res 40/00:01:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) ata5: soft resetting port ata5.00: configured for UDMA/33 ata5: EH complete sd 4:0:0:0: [sdc] 488397168 512-byte hardware sectors (250059 MB) sd 4:0:0:0: [sdc] Write Protect is off sd 4:0:0:0: [sdc] Mode Sense: 00 3a 00 00 sd 4:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Clue #2: both ata2 and ata5 are having problems Can this be the result of a hardware failure? I've seen several drives being added to an NCQ blacklist during the last weeks. Is it possible that my drives need to be added here, too? Or have I just two failing drives? Thanks a lot for any clues, Jim System boot log extract: sata_promise :00:08.0: version 2.10 ACPI: PCI Interrupt :00:08.0[A] - GSI 18 (level, low) - IRQ 18 scsi0 : sata_promise scsi1 : sata_promise scsi2 : sata_promise ata1: SATA max UDMA/133 cmd 0xf882e200 ctl 0xf882e238 bmdma 0x irq 18 ata2: SATA max UDMA/133 cmd 0xf882e280 ctl 0xf882e2b8 bmdma 0x irq 18 ata3: PATA max UDMA/133 cmd 0xf882e300 ctl 0xf882e338 bmdma 0x irq 18 ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: ATA-8: SAMSUNG HD252KJ, CM100-12, max UDMA7 ata1.00: 488397168 sectors, multi 0: LBA48 NCQ (depth 0/32) ata1.00: configured for UDMA/133 ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata2.00: ATA-7: WDC WD2500JS-55NCB1, 10.02E01, max UDMA/133 ata2.00: 488397168 sectors, multi 0: LBA48 NCQ (depth 0/32) ata2.00: configured for UDMA/133 Clue #3: ata2 is driven by sata_promise (lspci says it's a 20378, they're good) scsi 0:0:0:0: Direct-Access ATA SAMSUNG HD252KJ CM10 PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda2 sda3 sd 0:0:0:0: [sda] Attached SCSI disk scsi 1:0:0:0: Direct-Access ATA WDC WD2500JS-55N 10.0 PQ: 0 ANSI: 5 sd 1:0:0:0: [sdb] 488397168 512-byte hardware sectors (250059 MB) sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 1:0:0:0: [sdb] 488397168 512-byte hardware sectors (250059 MB) sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb: sdb2 sdb3 sd 1:0:0:0: [sdb] Attached SCSI disk sata_via :00:0f.0: version 2.3 ACPI: PCI Interrupt :00:0f.0[B] - GSI 20 (level, low) - IRQ 17 sata_via :00:0f.0: routed to hard irq line 10 scsi3 : sata_via scsi4 : sata_via ata4: SATA max UDMA/133 cmd 0x0001d000 ctl 0x0001c802 bmdma 0x0001b800 irq 17 ata5: SATA max UDMA/133 cmd 0x0001c400 ctl 0x0001c002 bmdma 0x0001b808 irq 17 ata4: SATA link down 1.5 Gbps (SStatus 0 SControl 300) ata5: SATA link up 1.5 Gbps
Re: Re:Believed resolved: SATA kern-buffRd read slow: based on promise driver bug
Linda Walsh writes: Mikael Pettersson wrote: Linda Walsh writes: Robert Hancock wrote: Linda Walsh wrote: read rate began falling; at 128k block-reads-at-a-time or larger, it drops below 20MB/s (only on buffered SATA). But more importantly -- I notice a chronic error message associate with this drive that may be causing some or all of the problem: --- ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 ata1.00: port_status 0x2008 ata1.00: cmd c8/00:10:30:06:03/00:00:00:00:00/e0 tag 0 cdb 0x0 data 8192 in res 50/00:00:3f:06:03/00:00:00:00:00/e0 Emask 0x2 (HSM violation) ata1: limiting SATA link speed to 1.5 Gbps Looks like the Promise ASIC SG bug. Apply http://user.it.uu.se/~mikpe/linux/patches/sata_promise/patch-sata_promise-1-asic-sg-bug-fix-v3-2.6.23 and let us know if things improve. /Mikael --- Yep! Hope that's making it into a patch soon or, at least 2.6.24. Kernel buffered Good to hear that it solved this problem. The patch is in 2.6.24-rc2 and newer kernels, and will be sent to -stable for the 2.6.23 and 2.6.22 series. I seem to remember reading about some problems with Promise SATA ACPI. Does this address that or is that a separate issue? (Am using no-acpi for sata_promise does nothing ACPI-related. It doesn't need to. (Drives may be a different story.) Is the above bug mentioned/discussed in the linux-ide archives? Yes. That and I'd like to find out why TCQ/NCQ doesn't work with the Seagate drives -- The driver doesn't yet support NCQ. - 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 kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)
Linda Walsh writes: Robert Hancock wrote: Linda Walsh wrote: Alan Cox wrote: rate began falling; at 128k block-reads-at-a-time or larger, it drops below 20MB/s (only on buffered SATA). Try disabling NCQ - see if you've got a drive with the 'NCQ = no readahead' flaw. http://linux-ata.org/faq.html#ncq --- When drive initializes, dmesg says it has NCQ (depth 0/32) Reading the queue_depth under /sys, shows a queuedepth of 1. But more importantly -- I notice a chronic error message associate with this drive that may be causing some or all of the problem: --- Jan 2 20:06:10 Ishtar kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 Jan 2 20:06:10 Ishtar kernel: ata1.00: port_status 0x2008 Jan 2 20:06:10 Ishtar kernel: ata1.00: cmd c8/00:10:30:06:03/00:00:00:00:00/e0 tag 0 cdb 0x0 data 8192 in Jan 2 20:06:10 Ishtar kernel: res 50/00:00:3f:06:03/00:00:00:00:00/e0 Emask 0x2 (HSM violation) Jan 2 20:06:13 Ishtar kernel: ata1: limiting SATA link speed to 1.5 Gbps Jan 2 20:06:13 Ishtar kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 Jan 2 20:06:13 Ishtar kernel: ata1.00: port_status 0x2008 Jan 2 20:06:13 Ishtar kernel: ata1.00: cmd c8/00:10:00:8b:04/00:00:00:00:00/e0 tag 0 cdb 0x0 data 8192 in Jan 2 20:06:13 Ishtar kernel: res 50/00:00:0f:8b:04/00:00:00:00:00/e0 Emask 0x2 (HSM violation) Jan 2 20:06:14 Ishtar kernel: ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x3 Jan 2 20:06:14 Ishtar kernel: ata1: hotplug_status 0x80 Jan 2 20:06:15 Ishtar kernel: ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x3 Jan 2 20:06:15 Ishtar kernel: ata1: hotplug_status 0x80 --- What da heck? Looks like the Promise ASIC SG bug. Apply http://user.it.uu.se/~mikpe/linux/patches/sata_promise/patch-sata_promise-1-asic-sg-bug-fix-v3-2.6.23 and let us know if things improve. /Mikael - 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: PIIX driver
Kalev Toots writes: Hello For specific reason I need to install old FC4 ( kernel 2.6.11 ) to new hardware ( Intel DP35DP motherboard ). Installation failed and the reason I think is that FC4 ata-piix driver don't have ICH9 support. Is it possible to port new ata-piix driver ( from kernel 2.6.23 ) to old kernel. Sounds like you're running the chip in compatibility mode. Maybe flip BIOS settings to AHCI mode and let FC4's kernel use its ahci driver instead? Backporting the entire driver would be painful. Perhaps adding some PCI IDs suffices? (I have no idea how much ICH9 differs from whatever FC4 supports.) I don't know if you need FC4 kernel or FC4 user-space, but one option is to install on an older supported machine, move the disk to the new one, and then boot a custom kernel. Finally you can buy a PCI PATA, SATA, or SCSI controller card supported by FC4 and forget about the mainboard's ICH9. - 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: HSM violation erros on sata_promise
Theo Baumgartner writes: Hello List I'm getting these HSM violation's too on all the SATA 300 TX4 ports with Seagate ST3250824NS disks. In the files attached are informations about the system with logs included and the kernel .config. Theo This is on Promise SATA300 TX4 and sata_promise (snip) uname -rpm 2.6.23-gentoo-r3 i686 AMD Athlon(tm) XP 2200+ First, we don't support random hacked vendor kernels, so please try a vanilla kernel, preferably 2.6.24-rc2 or newer. If you must use 2.6.23, apply this patch first: http://user.it.uu.se/~mikpe/linux/patches/sata_promise/patch-sata_promise-1-asic-sg-bug-fix-v3-2.6.23 (snip) lspci 00:00.0 Host bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333] 00:01.0 PCI bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333 AGP] 00:06.0 Mass storage controller: Promise Technology, Inc. PDC40718 (SATA 300 TX4) (rev 02) 00:07.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 74) 00:08.0 RAID bus controller: Silicon Image, Inc. SiI 3124 PCI-X Serial ATA Controller (rev 01) 00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 80) 00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 80) 00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 80) 00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge 00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 MX 440] (rev a3) You have three hard drive controllers. How many disks does this old mainboard have? It's not uncommon for disks to fail under load due to overloaded power supplies. (snip) sd 1:0:0:0: [sdb] 488397168 512-byte hardware sectors (250059 MB) sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 ata4.00: port_status 0x2008 ata4.00: cmd c8/00:08:3f:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in res 50/00:00:46:00:00/00:00:00:00:00/e0 Emask 0x2 (HSM violation) This is a familiar issue, one that may be fixed or at least made less frequent in recent kernels -- see above. But your kernel log is incomplete. You have an nVidia graphics chip: if you've loaded the nvidia proprietary kernel module then all bets are off. /Mikael - 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: stable basic 4-port SATA card
Patric Karlsson writes: Mikael Pettersson wrote: On Thu, 15 Nov 2007 12:32:14 +0900, Tejun Heo wrote: * sata_promise: Generally works okay; however there are still some problems with recent 3Gbps chips. (Mikael, please pitch in) Right, 2nd-gen 3Gbps chips have had intermittent issues, which we hope are cured by the recent ASIC bug workaround, but it will take a while for that fix to propagate out. To speed up that process I'm considering backporting the fix to 2.6.23 and 2.6.22. NCQ and PMP are supported in the hardware and in the vendor's driver, but not yet in sata_promise. My intention is to add NCQ soon, but there's no time-plan yet for this. /Mikael - 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 Backporting would be nice, since we're still some ways from a stable 2.6.24, and I'm not comfortable running -rc kernels in production enviroments. Ok. For 2.6.23 there is one patch: http://user.it.uu.se/~mikpe/linux/patches/sata_promise/patch-sata_promise-1-asic-sg-bug-fix-v3-2.6.23 This is the workaround for the ASIC PRD/SG bug. For 2.6.22 there are two patches: http://user.it.uu.se/~mikpe/linux/patches/sata_promise/patch-sata_promise-1-ft_tx4200-is-gen2-2.6.22 This corrects the classification of FastTrack TX4200 cards, which in turn fixes nasty errors in how they are accessed. http://user.it.uu.se/~mikpe/linux/patches/sata_promise/patch-sata_promise-2-asic-sg-bug-fix-v3-2.6.22 This is the workaround for the ASIC PRD/SG bug. /Mikael - 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 RFC] sata_promise: make pdc_atapi_pkt() use values from qc-tf
On Mon, 03 Dec 2007 13:49:36 +0900, Tejun Heo wrote: Mikael Pettersson wrote: what was the outcome of this discussion? I haven't looked over the Promise datasheet nor checked my brain for details, hoping Mikael would do that for me ;-) I've now tested this on top of 2.6.24-rc3, with no observable regressions. Blanking, writing, and mounting/reading CD-RWs on both SATAPI and PATAPI works (tested on a 300 TX2plus card). I can't find anything in Promise's public docs or reference driver about non-standard requirements on lbam/lbah in ATAPI packets. The values set by core layer should be good enough. The only thing I'm worried about is setting transfer chunk size when protocol is DMA. As setting this value hasn't caused any problem for other controllers and it seems sata_promise doesn't seem to have problem with it either, I'm leaning toward keeping this value but if setting this value to zero is the right thing to do, we can definitely change that in the core layer. One way or the other, I'd really like to keep sata_promise's behavior in line with other libata drivers. So, Mikael, do you think it would be okay to include the patch for #upstream and see how it works in -mm? Yes /Mikael - 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 RFC] sata_promise: make pdc_atapi_pkt() use values from qc-tf
On Sat, 01 Dec 2007 18:23:44 -0500, Jeff Garzik wrote: Tejun Heo wrote: Make pdc_atapi_pkt() use values from qc-tf instead of creating its own. This is to ease future ATAPI handling changes. DONT APPLY YET --- Mikael, would this work? Values other than lbam and lbah remain the same. Does sata_promise have strict requirements for lbam and lbah? Thanks. drivers/ata/sata_promise.c | 34 +- 1 file changed, 13 insertions(+), 21 deletions(-) what was the outcome of this discussion? I haven't looked over the Promise datasheet nor checked my brain for details, hoping Mikael would do that for me ;-) I've now tested this on top of 2.6.24-rc3, with no observable regressions. Blanking, writing, and mounting/reading CD-RWs on both SATAPI and PATAPI works (tested on a 300 TX2plus card). I can't find anything in Promise's public docs or reference driver about non-standard requirements on lbam/lbah in ATAPI packets. /Mikael - 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 RFC] sata_promise: make pdc_atapi_pkt() use values from qc-tf
On Mon, 26 Nov 2007 20:34:38 +0900, Tejun Heo wrote:
Make pdc_atapi_pkt() use values from qc-tf instead of creating its
own. This is to ease future ATAPI handling changes.
DONT APPLY YET
---
Mikael, would this work? Values other than lbam and lbah remain the
same. Does sata_promise have strict requirements for lbam and lbah?
...
/* set feature and byte counter registers */
- if (qc-tf.protocol != ATA_PROT_ATAPI_DMA) {
+ if (qc-tf.protocol != ATA_PROT_ATAPI_DMA)
feature = PDC_FEATURE_ATAPI_PIO;
- /* set byte counter register to real transfer byte count */
- nbytes = qc-nbytes;
- if (nbytes 0x)
- nbytes = 0x;
- } else {
+ else
feature = PDC_FEATURE_ATAPI_DMA;
- /* set byte counter register to 0 */
- nbytes = 0;
- }
+
buf[20] = (1 5) | ATA_REG_FEATURE;
buf[21] = feature;
buf[22] = (1 5) | ATA_REG_BYTEL;
- buf[23] = nbytes 0xFF;
+ buf[23] = qc-tf.lbam;
buf[24] = (1 5) | ATA_REG_BYTEH;
- buf[25] = (nbytes 8) 0xFF;
+ buf[25] = qc-tf.lbah;
The original code matches what Promise' own driver does, including
the set byte counter register to real transfer byte count comment.
It's certainly possible that if lbah/lbam don't match -nbytes,
the HW will go nuts. Their data sheets are very quiet about ATAPI.
I can test your proposed change next weekend when I'm back to where
my sata_promise test equipment is.
/Mikael
-
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: Promise SATA TX4 300 port timeout with sata_promise in 2.6.22, kernel panic in 2.6.23
On Mon, 12 Nov 2007 13:12:19 +0900, Tejun Heo wrote: I Stratford wrote: The purpose of the mail is to document and share my experience in the hope that someone might find it useful, either for debugging their own TX4 300-centric system issues or figuring out what is up with sata_promise and the TX4 300 in 3Gbps mode. I also wish to offer my somewhat unique promise-based system as a test environment for either the timeout or kernel panic issues. I obviously have some basic need for data integrity of the RAID5, but this system is not in production and is therefore more available for testing purposes than the average machine with 22 Promise SATA ports.. :) [cc'ing Mikael Pettersson] It seems those 3Gbps promise controllers have hard time getting out of transmission errors. Is it because hardreset doesn't work? Can we fix it? Also, if 3Gbps can't be made reliable on those controllers, how about limiting it to 1.5Gbps by default with appropriate warning messages? Without PMP, it's not like we're gonna earn anything by driving the thing at 3Gbps. There are two things going on here: First, a workaround for a HW erratum affecting 2nd-generation chips like the SATA300 TX4 was included in kernel 2.6.24-rc2. Outstanding bug reports for 2nd-generation chips in older kernels are not unlikely to be related to this erratum, so we should not butcher the driver because of issues reported against old kernels. Secondly, Stratford's system is seriously overloaded: - a desktop mainboard - worked with 6 mainboard and 8 Promise 150 TX4 ports - problems began when two Promise 300 TX4 cards and more disks were added On several occasions we've traced people's problems to overtaxed system components (cooling, PSU, PCI busses). OTOH, it may be that Stratford's problem is directly related to the HW erratum, in which case 2.6.24-rc2 should solve it. /Mikael - 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: Bart's efforts?
Mikael Pettersson writes: On Sat, 3 Nov 2007 14:10:22 +, Alan Cox wrote: My question is if the drivers/ide infrastructure is slowly moving in the direction of being leverageable by libata when/if it moves out of scsi. Or does the drivers/ide code simply have the wrong kind of plumbing for libata to ever use. I don't think there is anything useful in old IDE that isn't in the new. For semi-modern machines that might be true. However: ... 2) pata_pdc202xx_old can't do UDMA on my 440BX PIII box See http://bugzilla.kernel.org/show_bug.cgi?id=9337 for details. - 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: Bart's efforts?
On Sat, 3 Nov 2007 14:10:22 +, Alan Cox wrote: My question is if the drivers/ide infrastructure is slowly moving in the direction of being leverageable by libata when/if it moves out of scsi. Or does the drivers/ide code simply have the wrong kind of plumbing for libata to ever use. I don't think there is anything useful in old IDE that isn't in the new. For semi-modern machines that might be true. However: 1) there's no libata replacement for the IDE pmac driver 2) pata_pdc202xx_old can't do UDMA on my 440BX PIII box 3) pata_legacy doesn't release io/irq combinations for failed probes, causing conflicts with drivers loaded later on (Not a complaint, just a reminder that rm -rf drivers/ide/ isn't an option yet.) - 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: Bart's efforts?
Alan Cox wrote: 2) pata_pdc202xx_old can't do UDMA on my 440BX PIII box Bug # ? No bz # yet, but you and I had a private email conversation about this on March 13 and 15 this year. There's been a couple of recent reports to linux-ide with identical (as far as I can see) issues as I get: http://marc.info/?l=linux-idem=119152811824641w=2 http://marc.info/?l=linux-idem=118890476223188w=2 http://marc.info/?l=linux-idem=118855473322630w=2 I'll add a bugzilla entry for this next week so it doesn't get lost. 3) pata_legacy doesn't release io/irq combinations for failed probes, causing conflicts with drivers loaded later on In my tree it does but I'm still testing some bits. Good news. /Mikael - 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 patches] libata fixes
On Tue, 30 Oct 2007 11:54:01 -0700 (PDT), Linus Torvalds wrote: On Tue, 30 Oct 2007, Jeff Garzik wrote: Mikael Pettersson (2): sata_promise: ASIC PRD table bug workaround, take 2 sata_promise: cleanups You and Mikael need to sort out the way you send/accept patches. Both of these commits had stuff like this: Signed-off-by: Mikael Pettersson [EMAIL PROTECTED] -- Changes since previous version: * use new PDC_MAX_PRD constant to initialise sg_tablesize drivers/ata/sata_promise.c | 87 ++--- 1 files changed, 83 insertions(+), 4 deletions(-) Signed-off-by: Jeff Garzik [EMAIL PROTECTED] which seems to be because Mikael uses two dashes instead of three to separate his real message from the stuff you have. So either you need to teach Mikael to use the proper separators That's my fault for misremembering the rule about the number of dashes before the other comments part :-( I'll remember better in the future. /Mikael - 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.6.24-rc1] sata_promise: fix endianess bug in ASIC PRD bug workaround
The original workaround for the Promise ASIC PRD bug contained an endianess bug which I failed to detect: the adjustment of the last PRD entry's length field applied host arithmetic to little-endian data, which is incorrect on big-endian machines. We have the length available in host-endian format, so do the adjustment on host-endian data and then convert and store it in the PRD entry's little-endian data field. Thanks to an anonymous reviewer for detecting this bug. Signed-off-by: Mikael Pettersson [EMAIL PROTECTED] --- Jeff: please include this fix in any backport(s) of the ASIC PRD bug workaround. drivers/ata/sata_promise.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -rupN linux-2.6.24-rc1/drivers/ata/sata_promise.c linux-2.6.24-rc1.sata_promise-endianess-fix/drivers/ata/sata_promise.c --- linux-2.6.24-rc1/drivers/ata/sata_promise.c 2007-10-31 11:47:13.0 +0100 +++ linux-2.6.24-rc1.sata_promise-endianess-fix/drivers/ata/sata_promise.c 2007-10-31 11:47:25.0 +0100 @@ -585,7 +585,7 @@ static void pdc_fill_sg(struct ata_queue VPRINTK(Splitting last PRD.\n); addr = le32_to_cpu(ap-prd[idx - 1].addr); - ap-prd[idx - 1].flags_len -= cpu_to_le32(SG_COUNT_ASIC_BUG); + ap-prd[idx - 1].flags_len = cpu_to_le32(len - SG_COUNT_ASIC_BUG); VPRINTK(PRD[%u] = (0x%X, 0x%X)\n, idx - 1, addr, SG_COUNT_ASIC_BUG); addr = addr + len - SG_COUNT_ASIC_BUG; - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.24-rc1] sata_promise: ASIC PRD table bug workaround
On Mon, 29 Oct 2007 15:07:06 -0400, Jeff Garzik wrote:
Mikael Pettersson wrote:
@@ -155,7 +155,7 @@ static struct scsi_host_template pdc_ata
.queuecommand = ata_scsi_queuecmd,
.can_queue = ATA_DEF_QUEUE,
.this_id= ATA_SHT_THIS_ID,
- .sg_tablesize = LIBATA_MAX_PRD,
+ .sg_tablesize = LIBATA_MAX_PRD-1,
.cmd_per_lun= ATA_SHT_CMD_PER_LUN,
.emulated = ATA_SHT_EMULATED,
.use_clustering = ATA_SHT_USE_CLUSTERING,
IMO, this will be difficult for human eyes to see, many months from now.
I would prefer a 'PDC_MAX_PRD' constant, defined to this value.
Agreed. I'll do this change.
@@ -530,7 +608,7 @@ static void pdc_qc_prep(struct ata_queue
switch (qc-tf.protocol) {
case ATA_PROT_DMA:
- ata_qc_prep(qc);
+ pdc_fill_sg(qc);
/* fall through */
case ATA_PROT_NODATA:
@@ -546,11 +624,11 @@ static void pdc_qc_prep(struct ata_queue
break;
case ATA_PROT_ATAPI:
- ata_qc_prep(qc);
+ pdc_fill_sg(qc);
break;
case ATA_PROT_ATAPI_DMA:
- ata_qc_prep(qc);
+ pdc_fill_sg(qc);
/*FALLTHROUGH*/
Note that this is not exactly an equivalent change -- you are removing
the test in ata_qc_prep() that occurs prior to ata_fill_sg() call.
As Alexander replied, pdc_fill_sg() does include ata_qc_prep()'s
initial test. Unfortunately the name pdc_qc_prep() is already taken
[it switches on qc-tf.protocol], so that leaves either pdc_fill_sg()
[slightly imprecise as you noted], or uglies like __pdc_qc_prep(),
pdc_qc_prep2(), or pdc_qc_prep_and_fill_sg() as names for the new
procedure. I welcome suggestions for a better name.
/Mikael
-
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.6.24-rc1 1/2] sata_promise: ASIC PRD table bug workaround, take 2
Second-generation Promise SATA controllers have an ASIC bug
which can trigger if the last PRD entry is larger than 164 bytes,
resulting in intermittent errors and possible data corruption.
Work around this by replacing calls to ata_qc_prep() with a
private version that fills the PRD, checks the size of the
last entry, and if necessary splits it to avoid the bug.
Also reduce sg_tablesize by 1 to accommodate the new entry.
Tested on the second-generation SATA300 TX4 and SATA300 TX2plus,
and the first-generation PDC20378.
Thanks to Alexander Sabourenkov for verifying the bug by
studying the vendor driver, and for writing the initial patch
upon which this one is based.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
--
Changes since previous version:
* use new PDC_MAX_PRD constant to initialise sg_tablesize
drivers/ata/sata_promise.c | 87 ++---
1 files changed, 83 insertions(+), 4 deletions(-)
diff -rupN linux-2.6.24-rc1/drivers/ata/sata_promise.c
linux-2.6.24-rc1.sata_promise-asic-sg-bug-fix-v2/drivers/ata/sata_promise.c
--- linux-2.6.24-rc1/drivers/ata/sata_promise.c 2007-10-24 23:22:55.0
+0200
+++ linux-2.6.24-rc1.sata_promise-asic-sg-bug-fix-v2/drivers/ata/sata_promise.c
2007-10-30 13:18:25.0 +0100
@@ -50,6 +50,7 @@
enum {
PDC_MAX_PORTS = 4,
PDC_MMIO_BAR= 3,
+ PDC_MAX_PRD = LIBATA_MAX_PRD - 1, /* -1 for ASIC PRD bug
workaround */
/* register offsets */
PDC_FEATURE = 0x04, /* Feature/Error reg (per port) */
@@ -155,7 +156,7 @@ static struct scsi_host_template pdc_ata
.queuecommand = ata_scsi_queuecmd,
.can_queue = ATA_DEF_QUEUE,
.this_id= ATA_SHT_THIS_ID,
- .sg_tablesize = LIBATA_MAX_PRD,
+ .sg_tablesize = PDC_MAX_PRD,
.cmd_per_lun= ATA_SHT_CMD_PER_LUN,
.emulated = ATA_SHT_EMULATED,
.use_clustering = ATA_SHT_USE_CLUSTERING,
@@ -521,6 +522,84 @@ static void pdc_atapi_pkt(struct ata_que
memcpy(buf+31, cdb, cdb_len);
}
+/**
+ * pdc_fill_sg - Fill PCI IDE PRD table
+ * @qc: Metadata associated with taskfile to be transferred
+ *
+ * Fill PCI IDE PRD (scatter-gather) table with segments
+ * associated with the current disk command.
+ * Make sure hardware does not choke on it.
+ *
+ * LOCKING:
+ * spin_lock_irqsave(host lock)
+ *
+ */
+static void pdc_fill_sg(struct ata_queued_cmd *qc)
+{
+ struct ata_port *ap = qc-ap;
+ struct scatterlist *sg;
+ unsigned int idx;
+ const u32 SG_COUNT_ASIC_BUG = 41*4;
+
+ if (!(qc-flags ATA_QCFLAG_DMAMAP))
+ return;
+
+ WARN_ON(qc-__sg == NULL);
+ WARN_ON(qc-n_elem == 0 qc-pad_len == 0);
+
+ idx = 0;
+ ata_for_each_sg(sg, qc) {
+ u32 addr, offset;
+ u32 sg_len, len;
+
+ /* determine if physical DMA addr spans 64K boundary.
+* Note h/w doesn't support 64-bit, so we unconditionally
+* truncate dma_addr_t to u32.
+*/
+ addr = (u32) sg_dma_address(sg);
+ sg_len = sg_dma_len(sg);
+
+ while (sg_len) {
+ offset = addr 0x;
+ len = sg_len;
+ if ((offset + sg_len) 0x1)
+ len = 0x1 - offset;
+
+ ap-prd[idx].addr = cpu_to_le32(addr);
+ ap-prd[idx].flags_len = cpu_to_le32(len 0x);
+ VPRINTK(PRD[%u] = (0x%X, 0x%X)\n, idx, addr, len);
+
+ idx++;
+ sg_len -= len;
+ addr += len;
+ }
+ }
+
+ if (idx) {
+ u32 len = le32_to_cpu(ap-prd[idx - 1].flags_len);
+
+ if (len SG_COUNT_ASIC_BUG) {
+ u32 addr;
+
+ VPRINTK(Splitting last PRD.\n);
+
+ addr = le32_to_cpu(ap-prd[idx - 1].addr);
+ ap-prd[idx - 1].flags_len -=
cpu_to_le32(SG_COUNT_ASIC_BUG);
+ VPRINTK(PRD[%u] = (0x%X, 0x%X)\n, idx - 1, addr,
SG_COUNT_ASIC_BUG);
+
+ addr = addr + len - SG_COUNT_ASIC_BUG;
+ len = SG_COUNT_ASIC_BUG;
+ ap-prd[idx].addr = cpu_to_le32(addr);
+ ap-prd[idx].flags_len = cpu_to_le32(len);
+ VPRINTK(PRD[%u] = (0x%X, 0x%X)\n, idx, addr, len);
+
+ idx++;
+ }
+
+ ap-prd[idx - 1].flags_len |= cpu_to_le32(ATA_PRD_EOT);
+ }
+}
+
static void pdc_qc_prep(struct ata_queued_cmd *qc)
{
struct pdc_port_priv *pp = qc-ap-private_data;
@@ -530,7 +609,7 @@ static void pdc_qc_prep(struct ata_queue
switch (qc
[PATCH 2.6.24-rc1 2/2] sata_promise: cleanups
Minor sata_promise cleanups:
- use C99 array initialisers in pdc_port_info[]
- add myself in the file head's Maintained by note,
since users don't always read the MAINTAINERS file
- SG/PRD bug workaround warrants driver version bump
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
--
drivers/ata/sata_promise.c | 17 +
1 files changed, 9 insertions(+), 8 deletions(-)
diff -rupN linux-2.6.24-rc1/drivers/ata/sata_promise.c
linux-2.6.24-rc1.sata_promise-cleanups/drivers/ata/sata_promise.c
--- linux-2.6.24-rc1/drivers/ata/sata_promise.c 2007-10-30 13:55:05.0
+0100
+++ linux-2.6.24-rc1.sata_promise-cleanups/drivers/ata/sata_promise.c
2007-10-30 13:54:56.0 +0100
@@ -2,6 +2,7 @@
* sata_promise.c - Promise SATA
*
* Maintained by: Jeff Garzik [EMAIL PROTECTED]
+ * Mikael Pettersson [EMAIL PROTECTED]
* Please ALWAYS copy linux-ide@vger.kernel.org
* on emails.
*
@@ -45,7 +46,7 @@
#include sata_promise.h
#define DRV_NAME sata_promise
-#define DRV_VERSION2.10
+#define DRV_VERSION2.11
enum {
PDC_MAX_PORTS = 4,
@@ -239,7 +240,7 @@ static const struct ata_port_operations
};
static const struct ata_port_info pdc_port_info[] = {
- /* board_2037x */
+ [board_2037x] =
{
.flags = PDC_COMMON_FLAGS | ATA_FLAG_SATA |
PDC_FLAG_SATA_PATA,
@@ -249,7 +250,7 @@ static const struct ata_port_info pdc_po
.port_ops = pdc_old_sata_ops,
},
- /* board_2037x_pata */
+ [board_2037x_pata] =
{
.flags = PDC_COMMON_FLAGS | ATA_FLAG_SLAVE_POSS,
.pio_mask = 0x1f, /* pio0-4 */
@@ -258,7 +259,7 @@ static const struct ata_port_info pdc_po
.port_ops = pdc_pata_ops,
},
- /* board_20319 */
+ [board_20319] =
{
.flags = PDC_COMMON_FLAGS | ATA_FLAG_SATA |
PDC_FLAG_4_PORTS,
@@ -268,7 +269,7 @@ static const struct ata_port_info pdc_po
.port_ops = pdc_old_sata_ops,
},
- /* board_20619 */
+ [board_20619] =
{
.flags = PDC_COMMON_FLAGS | ATA_FLAG_SLAVE_POSS |
PDC_FLAG_4_PORTS,
@@ -278,7 +279,7 @@ static const struct ata_port_info pdc_po
.port_ops = pdc_pata_ops,
},
- /* board_2057x */
+ [board_2057x] =
{
.flags = PDC_COMMON_FLAGS | ATA_FLAG_SATA |
PDC_FLAG_GEN_II | PDC_FLAG_SATA_PATA,
@@ -288,7 +289,7 @@ static const struct ata_port_info pdc_po
.port_ops = pdc_sata_ops,
},
- /* board_2057x_pata */
+ [board_2057x_pata] =
{
.flags = PDC_COMMON_FLAGS | ATA_FLAG_SLAVE_POSS |
PDC_FLAG_GEN_II,
@@ -298,7 +299,7 @@ static const struct ata_port_info pdc_po
.port_ops = pdc_pata_ops,
},
- /* board_40518 */
+ [board_40518] =
{
.flags = PDC_COMMON_FLAGS | ATA_FLAG_SATA |
PDC_FLAG_GEN_II | PDC_FLAG_4_PORTS,
-
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-RFC] Promise TX4 implement hw-bug workaround
On Sun, 28 Oct 2007 06:29:32 -0400, Jeff Garzik wrote:
BTW, looking at the Promise code I see
cam_con.h:
/* for ASIC bug, limit the last element of SG byteCount must 32 Dword */
#define SG_COUNT_ASIC_BUG 32
//#define SG_COUNT_ASIC_BUG 128
and in the code itself
/* check PRD table, last element = (32 Dword), fix ASIC bug */
(though the code obviously uses SG_COUNT_ASIC_BUG==32, as the first
paste indicates)
so it seems like Promise first used 128 (32 dwords), but then backed
down to 32 (8 dwords).
Either way, we definitely have an ASIC bug to work around, it seems...
You're looking at the old pdc-ultra2 driver. The newer unified
sataii150-300 driver (v1.01.0.23) upped the value to 41*4.
I've reviewed Alexander's patch, and I'm currently testing it
with the add-on patch below (fix sg_tablesize, code formatting
stuff, fix uninitialised 'addr' in a VPRINTK).
/Mikael
--- linux-2.6.24-rc1/drivers/ata/sata_promise.c.~1~ 2007-10-28
11:58:01.0 +0100
+++ linux-2.6.24-rc1/drivers/ata/sata_promise.c 2007-10-28 12:20:53.0
+0100
@@ -155,7 +155,7 @@ static struct scsi_host_template pdc_ata
.queuecommand = ata_scsi_queuecmd,
.can_queue = ATA_DEF_QUEUE,
.this_id= ATA_SHT_THIS_ID,
- .sg_tablesize = LIBATA_MAX_PRD,
+ .sg_tablesize = LIBATA_MAX_PRD-1,
.cmd_per_lun= ATA_SHT_CMD_PER_LUN,
.emulated = ATA_SHT_EMULATED,
.use_clustering = ATA_SHT_USE_CLUSTERING,
@@ -542,7 +542,7 @@ static void pdc_fill_sg(struct ata_queue
if (!(qc-flags ATA_QCFLAG_DMAMAP))
return;
-
+
WARN_ON(qc-__sg == NULL);
WARN_ON(qc-n_elem == 0 qc-pad_len == 0);
@@ -579,18 +579,15 @@ static void pdc_fill_sg(struct ata_queue
if (len SG_COUNT_ASIC_BUG) {
u32 addr;
- /* if len 2*SG_COUNT_ASIC_BUG then last
- segment will be larger than next-to-last.
- Somewhat ugly :(
- */
VPRINTK(Splitting last PRD.\n);
+ addr = le32_to_cpu(ap-prd[idx - 1].addr);
ap-prd[idx - 1].flags_len -=
cpu_to_le32(SG_COUNT_ASIC_BUG);
VPRINTK(PRD[%u] = (0x%X, 0x%X)\n, idx - 1, addr,
SG_COUNT_ASIC_BUG);
-
- addr = le32_to_cpu(ap-prd[idx - 1].addr) + len -
SG_COUNT_ASIC_BUG;
- len = SG_COUNT_ASIC_BUG;
+
+ addr = addr + len - SG_COUNT_ASIC_BUG;
+ len = SG_COUNT_ASIC_BUG;
ap-prd[idx].addr = cpu_to_le32(addr);
ap-prd[idx].flags_len = cpu_to_le32(len);
VPRINTK(PRD[%u] = (0x%X, 0x%X)\n, idx, addr, len);
-
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-RFC] Promise TX4 implement hw-bug workaround
On Sun, 28 Oct 2007 12:03:16 +0100 (MET), Mikael Pettersson wrote:
On Sun, 28 Oct 2007 06:29:32 -0400, Jeff Garzik wrote:
BTW, looking at the Promise code I see
cam_con.h:
/* for ASIC bug, limit the last element of SG byteCount must 32 Dword */
#define SG_COUNT_ASIC_BUG 32
//#define SG_COUNT_ASIC_BUG 128
and in the code itself
/* check PRD table, last element = (32 Dword), fix ASIC bug */
(though the code obviously uses SG_COUNT_ASIC_BUG==32, as the first
paste indicates)
so it seems like Promise first used 128 (32 dwords), but then backed
down to 32 (8 dwords).
Either way, we definitely have an ASIC bug to work around, it seems...
You're looking at the old pdc-ultra2 driver. The newer unified
sataii150-300 driver (v1.01.0.23) upped the value to 41*4.
I've reviewed Alexander's patch, and I'm currently testing it
with the add-on patch below (fix sg_tablesize, code formatting
stuff, fix uninitialised 'addr' in a VPRINTK).
FYI:
Several hours of testing on a SATA300 TX4 with two 3Gbps disks went well,
as did a quick test on a SATA300 TX2plus with one SATA and one PATA disk.
I'll test further on a 1st generation controller tomorrow.
/Mikael
--- linux-2.6.24-rc1/drivers/ata/sata_promise.c.~1~ 2007-10-28
11:58:01.0 +0100
+++ linux-2.6.24-rc1/drivers/ata/sata_promise.c 2007-10-28
12:20:53.0 +0100
@@ -155,7 +155,7 @@ static struct scsi_host_template pdc_ata
.queuecommand = ata_scsi_queuecmd,
.can_queue = ATA_DEF_QUEUE,
.this_id= ATA_SHT_THIS_ID,
- .sg_tablesize = LIBATA_MAX_PRD,
+ .sg_tablesize = LIBATA_MAX_PRD-1,
.cmd_per_lun= ATA_SHT_CMD_PER_LUN,
.emulated = ATA_SHT_EMULATED,
.use_clustering = ATA_SHT_USE_CLUSTERING,
@@ -542,7 +542,7 @@ static void pdc_fill_sg(struct ata_queue
if (!(qc-flags ATA_QCFLAG_DMAMAP))
return;
-
+
WARN_ON(qc-__sg == NULL);
WARN_ON(qc-n_elem == 0 qc-pad_len == 0);
@@ -579,18 +579,15 @@ static void pdc_fill_sg(struct ata_queue
if (len SG_COUNT_ASIC_BUG) {
u32 addr;
- /* if len 2*SG_COUNT_ASIC_BUG then last
-segment will be larger than next-to-last.
-Somewhat ugly :(
- */
VPRINTK(Splitting last PRD.\n);
+ addr = le32_to_cpu(ap-prd[idx - 1].addr);
ap-prd[idx - 1].flags_len -=
cpu_to_le32(SG_COUNT_ASIC_BUG);
VPRINTK(PRD[%u] = (0x%X, 0x%X)\n, idx - 1, addr,
SG_COUNT_ASIC_BUG);
-
- addr = le32_to_cpu(ap-prd[idx - 1].addr) + len -
SG_COUNT_ASIC_BUG;
- len = SG_COUNT_ASIC_BUG;
+
+ addr = addr + len - SG_COUNT_ASIC_BUG;
+ len = SG_COUNT_ASIC_BUG;
ap-prd[idx].addr = cpu_to_le32(addr);
ap-prd[idx].flags_len = cpu_to_le32(len);
VPRINTK(PRD[%u] = (0x%X, 0x%X)\n, idx, addr, len);
-
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
-
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-RFC] (was: Re: Sata Sil3512 bug?; Promise SATA300 TX4)
On Sat, 27 Oct 2007 17:24:32 +0400, Alexander Sabourenkov wrote: There appears to be a hardware bug in that it chokes on scatterlist if the last item is larger than 164 bytes. The patch that follows fixes my problem on 2.6.22. I can't think of a way to avoid second pass over scatterlist without duplicating code (ata_qc_prep() and ata_fill_sg() from libata-core.c). --- a/drivers/ata/sata_promise.c 2007-07-09 03:32:17.0 +0400 +++ b/drivers/ata/sata_promise.c 2007-10-27 17:20:03.0 +0400 Interesting, but can you please give more background information? I.e., how did you determine the existence of this bug? And please cc: the sata_promise maintainer on sata_promise patches. (Hint: that's me) And please choose a Subject: that makes it absolutely clear what the post is about. Sata Sil3512 bug doesn't exactly sound like something the sata_promise maintainer needs to look at. Meanwhile I'll check the Promise driver(s) to see if there's something about SG table formatting restrictions there. /Mikael - 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
2.6.24-rc1 IDE regression on PMAC?
As shown by this dmesg diff between 2.6.23 and 2.6.24-rc1, IDE's PMAC driver now decides to downgrade itself to PIO2 on this box. Is this intensional or a bug? --- dmesg-2.6.23 +++ dmesg-2.6.24-rc1 @@ -84,8 +89,9 @@ ide0: Found Apple Heathrow ATA controller, bus ID 0, irq 28 Probing IDE interface ide0... hda: MATSHITA CR-585, ATAPI CD/DVD-ROM drive +hda: applying conservative PIO downgrade +hda: host max PIO4 wanted PIO255(auto-tune) selected PIO2 hda: selected mode 0x21 -hda: Enabling MultiWord DMA 1 ide0 at 0xf1008000-0xf1008007,0xf1008160 on irq 28 ide1: Found Apple Heathrow ATA controller, bus ID 1, irq 30 Probing IDE interface ide1... /Mikael - 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
Re: Bug is fixed in 2.6.23.1: sata_promise: port is slow to respond, reset failed
On Sun, 14 Oct 2007 11:21:13 +0200, Peter Favrholdt wrote: The problem is solved in 2.6.23.1 regarding the port slow to respond issue. I'm using sata_promise on Promise Technology, Inc. PDC40718 (SATA 300 TX4) (rev 02) and 4 Seagate 500GB ES drives. Using 2.6.23.1 it is possible to run 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 And it just runs perfectly to the end with no hickups :-) That's very good to hear. However, I don't see how the sata_promise changes from 2.6.22 to 2.6.23 can explain this. The only functional changes there are a critical fix for FastTrack TX4200 (not your card), and support for SATA hotplugging (not happening here). So I'm suspecting something in libata core might have changed to fix this. Just to make sure, what's the numerical PCI IDs for your card? (No big deal, but I'd like to know what the error was.) /Mikael - 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 1/1] libata: pata_pdc2027x PLL input clock fix
On Sun, 14 Oct 2007 13:31:34 -0400, Jeff Garzik wrote: Mikael Pettersson wrote: On Thu, 16 Aug 2007 21:19:40 +0100, Alan Cox wrote: Unfortunately this breaks pata_pdc2027x on my PowerMac G3: Did this ever get resolved? All went quiet so I assume its gone away ? -ENOTIME The regression is still there in 2.6.23-rc3 (I just checked), but I haven't had time to debug it yet. I'll try to do something about it this weekend. Still broken? No, my fix was included in 2.6.23-rc4. - 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: PDC20267 (Promise FastTrak100) instabillity/resets with newer kernels.
Yanko Kaneti writes: Hi The integrated PDC20267 (FastTrak100 BIOS version 2.30.0140.13) controller in following constants hardware setup behaves differently under live-cd fedora kernels 2.6.18-1.2869 and 2.6.23-0.214.rc8.git2.fc8. - Intel S845WD1-E server motherboard with onboard PDC20267 (105a:4d30), latest bios revision P12 - two HDT722525DLAT80 Hitachi 250GB harddrives in master mode connected to the two PDC20267 channels - a cd connected to the chipset 82801EB/ER (ICH5/ICH5R) IDE Controller for the purpose of booting the live-cd The two disk are put in a md raid1 setup. The first one is online, the second is being added and the raid starts reconstructing. The reconstruction works fine with 2.6.18 with a speed of approximately 50MB/s. With 2.6.23 immediately as the reconstruction begins there is string of ATA bus errors and port resets until it settles on PIO4 transfer mode. Your 2.6.18 kernel is using the IDE pdc202xx_old driver, while your 2.6.23 kernel is using the libata pata_pdc202xx_old driver. The latter one is marked experimental and is known to not work very well yet. Just switch to the IDE pdc202xx_old driver instead. /Mikael - 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[2]: Sata Sil3512 bug?
On Tue, 2 Oct 2007 21:20:23 +0200, MisterE wrote: I build another setup with almost the same hardware. This motherboard had already the latest bios. I notice that the computer does almost never find the hard drive although the controller is found every time (with lspci). So i get no drive (sda) assigned. I don't always see the bios screen from the controller at startup. And in the past it showed the hard drive. So i could not experiment with this motherboard. After that i installed Windows XP and used the orginal (sweex) drivers with the first motherboard. This also makes the data corrupt. So it seems not to be an linux problem. So there is something wrong with the motherboard or the 3512 controller. After that i plugged both hard drives (ide with windows and sata disk) to the Asus board. No data corruption. So the hard disks are'nt the problem either. 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. /Mikael Friday, September 28, 2007, 6:55:47 PM, you wrote: Alan Cox wrote: sda1 are corrupted (2 to 4 blocks missing). Copying that data back to Windows and it give the same results in Quickpar. So reading does not have problems. The data written to hda1 is correct. We've got a whole pile of reports like this with the 3512 and almost always Nvidia chipset, plus reports of BIOS updates fixing it. That you see something similar on intel boards is a bit worrying. Multiple sil3112/3512 + nvidia chipset problem doesn't usually involve device errors or timeouts. It usually corrupts data silently. And, yeah, data corruption on intel board is really disturbing. MisterE, do you have any processor powersaving mechanism enabled? If so, can you disable all and see whether that changes anything? - 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: Problems with Promise controller or Seagate 500g ST3500630AS ?
Glen Larkins writes: Corrected. With only 1 of the 500g drives connected, I can boot fine. With all drives connected, I suddenly began getting COMRESET failed (errno=-16) and hearing physical noises from the two 80g drives connected to the motherboard sata. This has never occurred. This report, and the fact that you wrote that things worked until you added 4 drives on a second controller, makes me suspect that the PSU simply cannot cope with the load. - 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: [Bugme-new] [Bug 8976] New: Regression (ata_piix): Kernel panic during driver initialization
Andrew Morton writes: On Mon, 3 Sep 2007 13:40:10 -0700 (PDT) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8976 This one is apparantly a post-2.6.22 regression. The ata_piix oops at init bug in 2.6.23-rc5 has already been fixed. There's a link to the patch at the bugzilla entry quoted above. - 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_promise: port is slow to respond, reset failed
Peter Favrholdt writes: Hi, Below some more info on my two systems: Mikael Pettersson wrote: I assume the PE1800 has some Intel chipset? Which one? ... :00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev c2) :00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Bridge (rev 02) ICH5. Should be decent enough. And the machine that does have problems, what chipset does it have? ... 00:08.0 PCI bridge: nVidia Corporation nForce2 External PCI Bridge (rev a3) nForce2. Hmm.. cat /proc/interrupts CPU0 0: 79XT-PIC-XTtimer 1: 2XT-PIC-XTi8042 2: 0XT-PIC-XTcascade 5: 141710XT-PIC-XTsk98lin 6: 5XT-PIC-XTfloppy 7: 35XT-PIC-XTparport0 8: 1XT-PIC-XTrtc 9: 6XT-PIC-XTacpi, ehci_hcd:usb1, ohci1394 10: 0XT-PIC-XTMPU401 UART 11: 27474XT-PIC-XTlibata, libata, ohci_hcd:usb3, NVidia nForce2 12: 15057XT-PIC-XTohci_hcd:usb2 14: 23211XT-PIC-XTide0 15: 32805XT-PIC-XTide1 NMI: 3911 LOC: 917176 ERR: 0 The promise card is sharing IRQ11 with usb, the other libata device, and nForce2 (wonder what that is?) That mystery device makes me strongly suspect that you've loaded the binary-only nvidia drivers. If that's true, then the machine's problems may just as well be caused by that driver, not sata_promise. (We've seen that happen before.) I'm actually beginning to think there's some PCI compatibility breakage somewhere, as I too see sata_promise working fine in some machines but not in others. Alas, my knowledge of PCI tweakables is close to nil. I second that (although I'm really clueless about PCI). Could it be that at 3.0Gbps with 4 ports running at full speed contention on the pci bus cause this behavior? This would explain why a PCI-X port helps (or limiting to 1.5Gbps). Or maybe it is an NFORCE2 issue... Or too many IRQ-handlers on the same IRQ... I wish I could do something more to help. Unfortunately it is almost impossible for me to do tests on the Intel system (as it is a production system) - though I might be able to try some things late at night in the weekends ;-) Guess at this point it would be nice to be able to reproduce the behavior on an Intel system... I can reproduce it on an Intel 440BX chipset machine with a PIII. However, that chipset, while very good in its day, is rather old now. I'll run some more tests this weekend on less ancient hardware. /Mikael - 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_promise: port is slow to respond, reset failed
Peter Favrholdt writes: Mikael Pettersson wrote: nForce2. Hmm.. Peter Favrholdt wrote: 11: 27474XT-PIC-XTlibata, libata, ohci_hcd:usb3, NVidia nForce2 That mystery device makes me strongly suspect that you've loaded the binary-only nvidia drivers. If that's true, then the machine's problems may just as well be caused by that driver, not sata_promise. (We've seen that happen before.) I didn't load any special NVidia driver - vanilla kernel only. The graphics card is Matrox G550. The nForce2 could be the nForce2 SMBus or the nForce2 IDE. Here is the result of dmesg | grep -i nforce [ 26.379422] NFORCE2: IDE controller at PCI slot :00:09.0 [ 26.379481] NFORCE2: chipset revision 162 [ 26.379525] NFORCE2: not 100% native mode: will probe irqs later [ 26.379575] NFORCE2: BIOS didn't set cable bits correctly. Enabling workaround. [ 26.379634] NFORCE2: :00:09.0 (rev a2) UDMA133 controller [ 31.861284] i2c_adapter i2c-0: nForce2 SMBus adapter at 0x5000 [ 31.861391] i2c_adapter i2c-1: nForce2 SMBus adapter at 0x5500 OK, sorry about that. The 'NVidia nForce2' string does occur in two sound drivers, so that may be where it's coming from. I can reproduce it on an Intel 440BX chipset machine with a PIII. However, that chipset, while very good in its day, is rather old now. I believe the problem here only shows if all four sata ports are stressed simultaneously (I should test this thoroughly). The dependence on Barracuda 7200.10 could be because these disks are faster than the others tested, this needed in order for the PCI contention to arise? (I'm still wild-guessing here). On my old 440BX reading a single Barracuda (7200.10 or .9 I don't remember) or Spinpoint disk was enough to trigger the errors. /Mikael - 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_promise: port is slow to respond, reset failed
On Sun, 02 Sep 2007 13:12:42 +0200, Peter Favrholdt wrote: I'm still experiencing the same port is slow to respond problem using sata_promise in linux-2.6.22.6 with my Promise Technology, Inc. PDC40718 (SATA 300 TX4) (rev 02) and 4 Seagate 500GB ES drives: Model Number: ST3500630NS Firmware Revision: 3.AEE (with 1.5/3.0Gbps jumper removed = 3.0Gbps) After 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 it runs fine for a while, then: [ 810.545909] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x138 action 0x2 frozen [ 810.545923] ata1.00: cmd c8/00:00:00:33:e6/00:00:00:00:00/e1 tag 0 cdb 0x0 data 131072 in [ 810.545926] res 40/00:28:00:00:00/00:00:00:00:00/40 Emask 0x4 (timeout) [ 815.913113] ata1: port is slow to respond, please be patient (Status 0xff) [ 820.590706] ata1: device not ready (errno=-16), forcing hardreset [ 820.590716] ata1: hard resetting port [ 826.137780] ata1: port is slow to respond, please be patient (Status 0xff) [ 830.635488] ata1: COMRESET failed (errno=-16) [ 830.635497] ata1: hard resetting port [ 836.182563] ata1: port is slow to respond, please be patient (Status 0xff) [ 840.680236] ata1: COMRESET failed (errno=-16) [ 840.680245] ata1: hard resetting port [ 846.227361] ata1: port is slow to respond, please be patient (Status 0xff) [ 875.672028] ata1: COMRESET failed (errno=-16) [ 875.672037] ata1: limiting SATA link speed to 1.5 Gbps [ 875.672041] ata1: hard resetting port [ 880.679454] ata1: COMRESET failed (errno=-16) [ 880.679463] ata1: reset failed, giving up [ 880.679466] ata1.00: disabled [ 880.679480] ata1: EH complete [ 880.679545] sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00 [ 880.679550] end_request: I/O error, dev sda, sector 31863552 [ 880.679555] Buffer I/O error on device sda, logical block 3982944 [ 880.679561] Buffer I/O error on device sda, logical block 3982945 [ 880.679565] Buffer I/O error on device sda, logical block 3982946 [ 880.679569] Buffer I/O error on device sda, logical block 3982947 [ 880.679573] Buffer I/O error on device sda, logical block 3982948 [ 880.679578] Buffer I/O error on device sda, logical block 3982949 [ 880.679582] Buffer I/O error on device sda, logical block 3982950 [ 880.679586] Buffer I/O error on device sda, logical block 3982951 [ 880.679590] Buffer I/O error on device sda, logical block 3982952 [ 880.679594] Buffer I/O error on device sda, logical block 3982953 [ 880.680296] sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00 [ 880.680301] end_request: I/O error, dev sda, sector 31863808 [ 880.680877] sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00 [ 880.680882] end_request: I/O error, dev sda, sector 31863552 [ 880.681383] sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00 [ 880.681388] end_request: I/O error, dev sda, sector 31863552 The funny thing is that it runs fine using linux-2.6.21-rc2 with Mikael Pettersson's 1.5Gbps only patch. Hmm, obviously a fatal problem, but not one I've seen before or have an explanation for at this time. We do know however that the SATA300 chips are prone to have issues especially in 3Gbps mode. A couple of things you can do: 1. Provide a complete dmesg. 2. Force 1.5Gbps mode, using either jumpers or the driver patch (there's one for 2.6.22 in http://user.it.uu.se/~mikpe/linux/patches/2.6/). 3. Try to narrow down where the problem started, i.e., test 2.6.21 final and the 2.6.22-rc kernels. /Mikael - 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_promise: port is slow to respond, reset failed
On Sun, 2 Sep 2007 17:11:36 +0200 (MEST), Mikael Pettersson wrote: On Sun, 02 Sep 2007 13:12:42 +0200, Peter Favrholdt wrote: I'm still experiencing the same port is slow to respond problem using sata_promise in linux-2.6.22.6 with my Promise Technology, Inc. PDC40718 (SATA 300 TX4) (rev 02) and 4 Seagate 500GB ES drives: Model Number: ST3500630NS Firmware Revision: 3.AEE (with 1.5/3.0Gbps jumper removed = 3.0Gbps) After 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 it runs fine for a while, then: [ 810.545909] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x138 action 0x2 frozen [ 810.545923] ata1.00: cmd c8/00:00:00:33:e6/00:00:00:00:00/e1 tag 0 cdb 0x0 data 131072 in [ 810.545926] res 40/00:28:00:00:00/00:00:00:00:00/40 Emask 0x4 (timeout) [ 815.913113] ata1: port is slow to respond, please be patient (Status 0xff) [ 820.590706] ata1: device not ready (errno=-16), forcing hardreset [ 820.590716] ata1: hard resetting port [ 826.137780] ata1: port is slow to respond, please be patient (Status 0xff) [ 830.635488] ata1: COMRESET failed (errno=-16) [ 830.635497] ata1: hard resetting port [ 836.182563] ata1: port is slow to respond, please be patient (Status 0xff) [ 840.680236] ata1: COMRESET failed (errno=-16) [ 840.680245] ata1: hard resetting port [ 846.227361] ata1: port is slow to respond, please be patient (Status 0xff) [ 875.672028] ata1: COMRESET failed (errno=-16) [ 875.672037] ata1: limiting SATA link speed to 1.5 Gbps [ 875.672041] ata1: hard resetting port [ 880.679454] ata1: COMRESET failed (errno=-16) [ 880.679463] ata1: reset failed, giving up [ 880.679466] ata1.00: disabled [ 880.679480] ata1: EH complete [ 880.679545] sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00 [ 880.679550] end_request: I/O error, dev sda, sector 31863552 [ 880.679555] Buffer I/O error on device sda, logical block 3982944 [ 880.679561] Buffer I/O error on device sda, logical block 3982945 [ 880.679565] Buffer I/O error on device sda, logical block 3982946 [ 880.679569] Buffer I/O error on device sda, logical block 3982947 [ 880.679573] Buffer I/O error on device sda, logical block 3982948 [ 880.679578] Buffer I/O error on device sda, logical block 3982949 [ 880.679582] Buffer I/O error on device sda, logical block 3982950 [ 880.679586] Buffer I/O error on device sda, logical block 3982951 [ 880.679590] Buffer I/O error on device sda, logical block 3982952 [ 880.679594] Buffer I/O error on device sda, logical block 3982953 [ 880.680296] sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00 [ 880.680301] end_request: I/O error, dev sda, sector 31863808 [ 880.680877] sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00 [ 880.680882] end_request: I/O error, dev sda, sector 31863552 [ 880.681383] sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00 [ 880.681388] end_request: I/O error, dev sda, sector 31863552 The funny thing is that it runs fine using linux-2.6.21-rc2 with Mikael Pettersson's 1.5Gbps only patch. Hmm, obviously a fatal problem, but not one I've seen before or have an explanation for at this time. We do know however that the SATA300 chips are prone to have issues especially in 3Gbps mode. A couple of things you can do: 1. Provide a complete dmesg. 2. Force 1.5Gbps mode, using either jumpers or the driver patch (there's one for 2.6.22 in http://user.it.uu.se/~mikpe/linux/patches/2.6/). 3. Try to narrow down where the problem started, i.e., test 2.6.21 final and the 2.6.22-rc kernels. I'm easily able to reproduce this problem on my sata_promise test rig. Using 2.6.23-rc5 to dd read a single Seagate disk on a SATA300 TX4 card quickly fails as Peter described. Applying the 1.5Gbps patch to the driver appears to make things stable. Those SATAII chips really don't seem to like 3Gbps mode. Or else we're missing some critical documentation on how to make them work. /Mikael - 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.6.23-rc4] sata_promise: FastTrack TX4200 is a second-generation chip
This patch corrects sata_promise to classify FastTrack TX4200
(DID 3515/3519) as a second-generation chip. Promise's partial-
source FT TX4200 driver confirms this classification.
Treating it as a first-generation chip causes several problems:
1. Detection failures. This is a recent regression triggered by
the hotplug-enabling changes in 2.6.23-rc1.
2. Various failed to resume link for reset warnings.
This patch fixes http://bugzilla.kernel.org/show_bug.cgi?id=8936.
Thanks to Stephen Ziemba for reporting the bug and for testing the fix.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
Tested-by: Stephen Ziemba [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
This patch is identical to the one Stephen tested, I've
just updated the description.
drivers/ata/sata_promise.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff -rupN linux-2.6.23-rc4/drivers/ata/sata_promise.c
linux-2.6.23-rc4.sata_promise-ft_tx4200-is-gen2/drivers/ata/sata_promise.c
--- linux-2.6.23-rc4/drivers/ata/sata_promise.c 2007-08-28 18:15:26.0
+0200
+++ linux-2.6.23-rc4.sata_promise-ft_tx4200-is-gen2/drivers/ata/sata_promise.c
2007-08-28 20:13:42.0 +0200
@@ -45,7 +45,7 @@
#include sata_promise.h
#define DRV_NAME sata_promise
-#define DRV_VERSION2.09
+#define DRV_VERSION2.10
enum {
PDC_MAX_PORTS = 4,
@@ -328,8 +328,8 @@ static const struct pci_device_id pdc_at
{ PCI_VDEVICE(PROMISE, 0x3318), board_20319 },
{ PCI_VDEVICE(PROMISE, 0x3319), board_20319 },
- { PCI_VDEVICE(PROMISE, 0x3515), board_20319 },
- { PCI_VDEVICE(PROMISE, 0x3519), board_20319 },
+ { PCI_VDEVICE(PROMISE, 0x3515), board_40518 },
+ { PCI_VDEVICE(PROMISE, 0x3519), board_40518 },
{ PCI_VDEVICE(PROMISE, 0x3d17), board_40518 },
{ PCI_VDEVICE(PROMISE, 0x3d18), board_40518 },
-
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_via: Add Armia W730-K8 and other rebadgings
On Wed, 22 Aug 2007 22:57:48 +0100, Alan Cox wrote: More cable funnies Signed-off-by: Alan Cox [EMAIL PROTECTED] diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.23rc3-mm1/drivers/ata/pata_via.c linux-2.6.23rc3-mm1/drivers/ata/pata_via.c --- linux.vanilla-2.6.23rc3-mm1/drivers/ata/pata_via.c2007-08-22 17:23:00.0 +0100 +++ linux-2.6.23rc3-mm1/drivers/ata/pata_via.c2007-08-22 17:46:53.0 +0100 @@ -63,7 +63,7 @@ #include linux/dmi.h #define DRV_NAME pata_via -#define DRV_VERSION 0.3.1 +#define DRV_VERSION 0.3.2 /* * The following comes directly from Vojtech Pavlik's ide/pci/via82cxxx @@ -144,6 +144,9 @@ /* Systems by DMI */ if (dmi_check_system(cable_dmi_table)) return 1; + /* Armia W730-K8/Targa Visionary 811/... */ + if (pdev-subsystem_vendor == 0x161F pdev-subsystem_device == 0x2032) + return 1; return 0; } s/Armia/Arima/ Apart from that it works fine on my '811. Tested-by: Mikael Pettersson [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
[PATCH 2.6.23-rc3] pata_via cable override for Arima W730-K8
On Fri, 3 Aug 2007 23:32:17 +0100, Alan Cox wrote:
On Fri, 3 Aug 2007 20:28:39 +0200 (MEST)
Mikael Pettersson [EMAIL PROTECTED] wrote:
The machine is an Athlon64 laptop with a K8T800 chipset. With the IDE
VIA driver the disk is detected as udma/100:
Currently old IDE via driver has a hack in it which goes 'did the BIOS
set UDMA3+' then I guess the cable is 80 wire regardless. libata doesn't
do that as it breaks with hotplug, breaks with suspend/resume before the
driver is loaded and other bits.
Instead we have two things - an ACPI snoop and a table of wonky laptops
(eg those that use 40 wire ultrashort cables which are valid for UDMA133
but not detected as 80 wire). If your laptop is done that way then it
just needs adding to the magic list and/or 2.6.23-rc1-mm should spot it
by ACPI. I'd prefer the table entry anyway as I don't like relying on ACPI
so an lspci -vvxx would be appreciated
This patch updates the pata_via cable override DMI table to also
recognise my Targa Visionary 811 laptop (== Arima W730-K8).
With this patch pata_via does UDMA100 just like the old IDE driver.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
---
drivers/ata/pata_via.c |7 +++
1 files changed, 7 insertions(+)
--- linux-2.6.23-rc3/drivers/ata/pata_via.c.~1~ 2007-08-21 00:45:11.0
+0200
+++ linux-2.6.23-rc3/drivers/ata/pata_via.c 2007-08-21 01:01:27.0
+0200
@@ -136,6 +136,13 @@ static struct dmi_system_id cable_dmi_ta
DMI_MATCH(DMI_BOARD_NAME, Ferrari 3400),
},
},
+ {
+ .ident = Arima W730-K8,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, ACTEBIS),
+ DMI_MATCH(DMI_BOARD_NAME, SAM#451B),
+ },
+ },
{ }
};
-
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 2.6.23-rc3] pata_pdc2027x: PLL detection fixes
On Sun, 19 Aug 2007 20:13:46 +0400, Sergei Shtylyov wrote: Mikael Pettersson wrote: Previously I reported that the pata_pdc2027x PLL detection changes in kernel 2.6.22 broke the driver on my PowerMac: pata_pdc2027x: Invalid PLL input clock 1691742kHz, give up! This is followed by a number of errors and speed reduction steps on the affected ports. There are two bugs in pata_pdc2027x's PLL detection code: 1. The PLL counter's start value is read before the chip is put in test mode. Outside of test mode the counter is halted, and on the PowerMac the counter is zero because the chip hasn't been initialised by its BIOS. So what? a) causes an unnecessary wraparound, which in turn is one of the causes for PLL detection failures on non-x86 b) puts more work [the enter test mode stuff] in between the start and and sampling points, reducing the precision of the PLL detection; I actually observed quite noticeable differences in detected PLL frequency based on whether the start was sampled before or after the test mode enter code The fix is to move the read of the start value to after test mode is started, but before the mdelay() in test mode. This is not an issue, so no fix is needed. This also improves the precision of the PLL detection. BTW, looks like we don't even need to bother reading the darn counter beforehand: bit 1 of the indexed register 1 (the same used to enter/exit test mode by twiddling its bit 6) when being cleared should reset the counter to 0 -- I'm looking at the internal sources which were written based on the *fragment* of the PDC20270 datasheet (yeah, Promise didn't even give us the whole datasheet!) about the PLL calibration. Well, I have no data sheet and no sources except what's in the kernel and what debug info PDC_DEBUG generates. 2. The code to compute the number of PLL decrements during the mdelay() in test mode fails to consider that the PLL counter only is 30 bits wide. If there is a wraparound, it will compute an incorrect and much too large value. On the PowerMac, the start count is zero, the end count is a large 30-bit value, so wraparound occurs and an out of bounds PLL clock is detected. The fix is to mask the (start - end) computation to 30 bits. Yeah, that's what I've done for the old IDE driver... Except that due to what may be a typo pdc202xx_new masks to 26 bits, not 30. I was going to address that if/when this patch goes in. While debugging this I also noticed that pdc_read_counter() reads the two halves of the 30-bit PLL counter as 16-bit values, and then combines them as if the halves only are 15 bits wide. To avoid confusion, the halves should be read as 15-bit values. Shouldn't matter, the bit is most probably reseved and so always remains 0. Actually, those 2 counters count the data bytes transferred over PCI bus when the chip in not in the test mode. It matters when someone reads the code and wonders why two 16-bit values (readl() 0x) are combined with a 15-bit shift ((x 15) | y). This patch implements all three changes. It fixes the PLL detection failure on my PowerMac, and doesn't cause any regressions on an x86 with an identical card. Signed-off-by: Mikael Pettersson [EMAIL PROTECTED] Acked-by: Sergei Shtylyov [EMAIL PROTECTED] diff -rupN linux-2.6.23-rc3/drivers/ata/pata_pdc2027x.c linux-2.6.23-rc3.pata_pdc2027x-pll-detection-fixes/drivers/ata/pata_pdc2027x.c --- linux-2.6.23-rc3/drivers/ata/pata_pdc2027x.c2007-07-09 22:01:31.0 +0200 +++ linux-2.6.23-rc3.pata_pdc2027x-pll-detection-fixes/drivers/ata/pata_pdc2027x.c 2007-08-18 21:53:40.0 +0200 [...] @@ -719,7 +719,7 @@ static long pdc_detect_pll_input_clock(s usec_elapsed = (end_time.tv_sec - start_time.tv_sec) * 100 + (end_time.tv_usec - start_time.tv_usec); - pll_clock = (start_count - end_count) / 100 * + pll_clock = ((start_count - end_count) 0x3fff) / 100 * (1 / usec_elapsed); PDPRINTK(start[%ld] end[%ld] \n, start_count, end_count); Only this fragment really matters. Yeah, this is the key fix. But the other changes still improve things. /Mikael - 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.6.23-rc3] pata_pdc2027x: PLL detection fixes
Previously I reported that the pata_pdc2027x PLL detection changes in kernel 2.6.22 broke the driver on my PowerMac: pata_pdc2027x: Invalid PLL input clock 1691742kHz, give up! This is followed by a number of errors and speed reduction steps on the affected ports. There are two bugs in pata_pdc2027x's PLL detection code: 1. The PLL counter's start value is read before the chip is put in test mode. Outside of test mode the counter is halted, and on the PowerMac the counter is zero because the chip hasn't been initialised by its BIOS. The fix is to move the read of the start value to after test mode is started, but before the mdelay() in test mode. This also improves the precision of the PLL detection. 2. The code to compute the number of PLL decrements during the mdelay() in test mode fails to consider that the PLL counter only is 30 bits wide. If there is a wraparound, it will compute an incorrect and much too large value. On the PowerMac, the start count is zero, the end count is a large 30-bit value, so wraparound occurs and an out of bounds PLL clock is detected. The fix is to mask the (start - end) computation to 30 bits. While debugging this I also noticed that pdc_read_counter() reads the two halves of the 30-bit PLL counter as 16-bit values, and then combines them as if the halves only are 15 bits wide. To avoid confusion, the halves should be read as 15-bit values. This patch implements all three changes. It fixes the PLL detection failure on my PowerMac, and doesn't cause any regressions on an x86 with an identical card. Signed-off-by: Mikael Pettersson [EMAIL PROTECTED] --- drivers/ata/pata_pdc2027x.c | 18 +- 1 files changed, 9 insertions(+), 9 deletions(-) diff -rupN linux-2.6.23-rc3/drivers/ata/pata_pdc2027x.c linux-2.6.23-rc3.pata_pdc2027x-pll-detection-fixes/drivers/ata/pata_pdc2027x.c --- linux-2.6.23-rc3/drivers/ata/pata_pdc2027x.c2007-07-09 22:01:31.0 +0200 +++ linux-2.6.23-rc3.pata_pdc2027x-pll-detection-fixes/drivers/ata/pata_pdc2027x.c 2007-08-18 21:53:40.0 +0200 @@ -563,13 +563,13 @@ static long pdc_read_counter(struct ata_ u32 bccrl, bccrh, bccrlv, bccrhv; retry: - bccrl = readl(mmio_base + PDC_BYTE_COUNT) 0x; - bccrh = readl(mmio_base + PDC_BYTE_COUNT + 0x100) 0x; + bccrl = readl(mmio_base + PDC_BYTE_COUNT) 0x7fff; + bccrh = readl(mmio_base + PDC_BYTE_COUNT + 0x100) 0x7fff; rmb(); /* Read the counter values again for verification */ - bccrlv = readl(mmio_base + PDC_BYTE_COUNT) 0x; - bccrhv = readl(mmio_base + PDC_BYTE_COUNT + 0x100) 0x; + bccrlv = readl(mmio_base + PDC_BYTE_COUNT) 0x7fff; + bccrhv = readl(mmio_base + PDC_BYTE_COUNT + 0x100) 0x7fff; rmb(); counter = (bccrh 15) | bccrl; @@ -692,16 +692,16 @@ static long pdc_detect_pll_input_clock(s struct timeval start_time, end_time; long pll_clock, usec_elapsed; - /* Read current counter value */ - start_count = pdc_read_counter(host); - do_gettimeofday(start_time); - /* Start the test mode */ scr = readl(mmio_base + PDC_SYS_CTL); PDPRINTK(scr[%X]\n, scr); writel(scr | (0x01 14), mmio_base + PDC_SYS_CTL); readl(mmio_base + PDC_SYS_CTL); /* flush */ + /* Read current counter value */ + start_count = pdc_read_counter(host); + do_gettimeofday(start_time); + /* Let the counter run for 100 ms. */ mdelay(100); @@ -719,7 +719,7 @@ static long pdc_detect_pll_input_clock(s usec_elapsed = (end_time.tv_sec - start_time.tv_sec) * 100 + (end_time.tv_usec - start_time.tv_usec); - pll_clock = (start_count - end_count) / 100 * + pll_clock = ((start_count - end_count) 0x3fff) / 100 * (1 / usec_elapsed); PDPRINTK(start[%ld] end[%ld] \n, start_count, end_count); - 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_artop: fix UDMA5 for AEC6280[R] and UDMA6 for AEC6880[R]
On Fri, 10 Aug 2007 18:33:43 +0100, Alan Cox wrote: However, I'm gettting consistently lower read throughput with pata_artop (13-19 MB/s) than with aec62xx (22 MB/s) on an oldish WD drive, and using pata_artop triggers a WARN_ON(irqs_disabled()) in arch/arm/mm/consistent.c: It would be nice to know why - is the cable detet coming out right on this ? The box has a short 40-wire cable, so pata_artop drops to udma/33 while aec62xx does udma/100 without intervention. I added an override to artop6260_cable_detect() to make it return PATA40_SHORT on this platform, and with that it does udma/100 as expected. Read performance fluctuates quite a bit, but seems to be 1-3 MB/s slower than aec62xx on average. I compared lspci -vvxxx and the only differences are a latency setting and some ROM thingy: --- lspci-ide 2007-08-12 13:07:12.0 +0200 +++ lspci-libata2007-08-12 13:12:55.0 +0200 @@ -1,32 +1,32 @@ 00:01.0 Mass storage controller: Artop Electronic Corp ATP865 NO-ROM (rev 07) Subsystem: Artop Electronic Corp ATP865 NO-ROM Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- - Latency: 0 (2750ns min, 1000ns max), Cache Line Size 08 + Latency: 144 (2750ns min, 1000ns max), Cache Line Size 08 Interrupt: pin A routed to IRQ 28 Region 0: I/O ports at 1050 [size=8] Region 1: I/O ports at 1060 [size=4] Region 2: I/O ports at 1058 [size=8] Region 3: I/O ports at 1064 [size=4] Region 4: I/O ports at 1040 [size=16] - Expansion ROM at 4800 [disabled by cmd] [size=64K] + Expansion ROM at 4800 [disabled] [size=64K] Capabilities: [58] 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- -00: 91 11 08 00 45 01 90 02 07 00 80 01 08 00 00 00 +00: 91 11 08 00 45 01 90 02 07 00 80 01 08 90 00 00 10: 51 10 00 00 61 10 00 00 59 10 00 00 65 10 00 00 20: 41 10 00 00 00 00 00 00 00 00 00 00 91 11 08 00 -30: 01 00 00 48 58 00 00 00 00 00 00 00 1c 01 0b 04 +30: 00 00 00 48 58 00 00 00 00 00 00 00 1c 01 0b 04 40: 31 00 00 00 06 00 00 00 70 84 96 00 00 00 00 02 50: ff ff ff ff f0 ff 34 50 01 00 02 06 00 00 00 00 60: 31 00 00 00 06 00 00 00 70 84 96 00 00 00 00 02 70: 00 00 00 00 f0 ff 34 50 01 00 02 06 00 00 00 00 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff c0: 31 00 00 00 06 00 00 00 70 84 96 00 00 00 00 02 d0: 00 00 00 00 f0 ff 34 50 01 00 02 06 00 00 00 00 e0: 31 00 00 00 06 00 00 00 70 84 96 00 00 00 00 02 f0: 00 00 00 00 f0 ff 34 50 01 00 02 06 00 00 00 00 WARNING: at arch/arm/mm/consistent.c:364 dma_free_coherent() ARM has a problem with dma_free_coherent with IRQ disabled. Unfortunately under high load ARM decides to use dma_free_coherent inside dma_unmap_sg(). This as far as I can see is an ARM problem not a libata problem and one you can duplicate with other drivers under high load. Yes, I now see that happening also with the IDE aec62xx driver. It used to only be a single-line WARNING, only recently has the ARM kernel started to also do a stack dump when it triggers. /Mikael - 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_artop: fix UDMA5 for AEC6280[R] and UDMA6 for AEC6880[R]
On Fri, 10 Aug 2007 01:45:38 +0200, Bartlomiej Zolnierkiewicz wrote: On Friday 10 August 2007, Alan Cox wrote: On Thu, 9 Aug 2007 23:19:34 +0200 Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] wrote: Maximum supported UDMA mode for AEC6280[R] is UDMA5 (not UDMA4) and for AEC6880[R] it is UDMA6 (not UDMA5): * Fix the problem by adding missing struct ata_port_info to artop_init_one(). * Use the right naming (s/626/628/). * Bump driver version. Fixes IDE-libata regression, problem was never present in IDE aec62xx driver. Have you tested this ?? -ENODEV so no and testing is welcomed. However I went over both drivers to make sure that this change is safe and correct. BTW presence of the above bugs would strongly indicate that pata_artop has never been tested (properly) with AEC6x80[R], otherwise these bugs should have been noticed and fixed much earlier. Tested on ATP865 (1191:0008 rev 07) in a DS101 box (an ARM-based NAS). Seems to work fine. However, I'm gettting consistently lower read throughput with pata_artop (13-19 MB/s) than with aec62xx (22 MB/s) on an oldish WD drive, and using pata_artop triggers a WARN_ON(irqs_disabled()) in arch/arm/mm/consistent.c: WARNING: at arch/arm/mm/consistent.c:364 dma_free_coherent() [c001fe7c] (dump_stack+0x0/0x14) from [c00210ec] (dma_free_coherent+0x38/0x200) [c00210b4] (dma_free_coherent+0x0/0x200) from [c00253a8] (dma_unmap_sg+0x15c/0x198) [c002524c] (dma_unmap_sg+0x0/0x198) from [c0111984] (ata_sg_clean+0xe4/0x1dc) [c01118a0] (ata_sg_clean+0x0/0x1dc) from [c0111ac8] (__ata_qc_complete+0x4c/0xcc) r8:c02eca20 r7:0004 r6:c02ec000 r5:c02ec000 r4:c02eca20 [c0111a7c] (__ata_qc_complete+0x0/0xcc) from [c0111be8] (ata_qc_complete+0xa0/0xe4) r5:c02eca20 r4:c02eca20 [c0111b48] (ata_qc_complete+0x0/0xe4) from [c01121b8] (ata_hsm_qc_complete+0x104/0x10c) r4: [c01120b4] (ata_hsm_qc_complete+0x0/0x10c) from [c01127fc] (ata_hsm_move+0x63c/0x694) r6:c02ec000 r5:0050 r4: [c01121c0] (ata_hsm_move+0x0/0x694) from [c0116628] (ata_interrupt+0x188/0x240) [c01164a0] (ata_interrupt+0x0/0x240) from [c0051b24] (handle_IRQ_event+0x44/0x84) [c0051ae0] (handle_IRQ_event+0x0/0x84) from [c005339c] (handle_level_irq+0xb0/0x108) r7:c02250e8 r6: r5:001c r4:c020e600 [c00532ec] (handle_level_irq+0x0/0x108) from [c001b044] (__exception_text_start+0x44/0x60) r5:c020e600 r4:001c [c001b000] (__exception_text_start+0x0/0x60) from [c001ba44] (__irq_svc+0x24/0x60) Exception stack(0xc0209f64 to 0xc0209fac) 9f60: 0002 c001cfa0 c0208000 c0018de8 9f80: c02250e8 00017570 690541f1 0001746c c0209fc0 c0209fac c0209fac c001cd38 9fa0: c001cfa4 6013 r6:1000 r5:001f r4: [c001cce4] (cpu_idle+0x0/0x8c) from [c018f020] (rest_init+0x48/0x58) r5:c02174d0 r4:c021fa58 [c018efd8] (rest_init+0x0/0x58) from [c0008b7c] (start_kernel+0x238/0x294) [c0008944] (start_kernel+0x0/0x294) from [8038] (0x8038) So far I've only seen this happen when I run hdparm -Tt /dev/sda. So something's still not quite right. aec62xx is perfectly reliable on this box. /Mikael - 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_cmd64x: Set up MWDMA modes properly
On Wed, 8 Aug 2007 14:33:20 +0100, Alan Cox wrote: Set the MWDMA timing by updating the correct registers. Split the PIO path as this is mostly shared code. Wants testing. Works fine on my CMD646 SPARC Ultra5. /Mikael - 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
2.6.23-rc2 regression: check_irq_resend() warning from cmd64x
This is on a sparc64 ultra5 with a rev 3 CMD646. Starting with kernel 2.6.23-rc2, each boot triggers a WARNING from kernel/irq/resend.c: Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx CMD646: IDE controller at PCI slot :01:03.0 CMD646: chipset revision 3 CMD646: MultiWord DMA force limited CMD646: 100% native mode on irq 14 ide0: BM-DMA at 0x1fe02c00020-0x1fe02c00027, BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0x1fe02c00028-0x1fe02c0002f, BIOS settings: hdc:pio, hdd:pio Probing IDE interface ide0... hda: ST320420A, ATA DISK drive hda: selected mode 0x22 ide0 at 0x1fe02c0-0x1fe02c7,0x1fe02ca on irq 14 Probing IDE interface ide1... hdc: CRD-8483B, ATAPI CD/DVD-ROM drive WARNING: at kernel/irq/resend.c:70 check_irq_resend() Call Trace: [00475a84] enable_irq+0x9c/0xc8 [00560438] probe_hwif+0x7bc/0x934 [00560dbc] probe_hwif_init_with_fixup+0x10/0xc4 [00563454] ide_setup_pci_device+0x94/0x9c [005581f4] cmd64x_init_one+0x40/0x4c [00680670] ide_scan_pcidev+0x48/0x84 [006806e0] ide_scan_pcibus+0x34/0x100 [0068061c] ide_init+0x60/0x6c [00670200] kernel_init+0xf0/0x270 [00427344] kernel_thread+0x38/0x48 [005c5fd8] rest_init+0x18/0x5c hdc: selected mode 0x22 ide1 at 0x1fe02c00010-0x1fe02c00017,0x1fe02c0001a on irq 14 (shared with ide0) hda: max request size: 128KiB hda: 39851760 sectors (20404 MB) w/2048KiB Cache, CHS=39535/16/63, (U)DMA hda: cache flushes not supported hda: hda1 hda2 hda3 hda4 hda5 /Mikael - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23-rc1: pata_via cable detection differs from via82cxxx
On Fri, 3 Aug 2007 23:32:17 +0100, Alan Cox wrote: Mikael Pettersson [EMAIL PROTECTED] wrote: The machine is an Athlon64 laptop with a K8T800 chipset. With the IDE VIA driver the disk is detected as udma/100: Currently old IDE via driver has a hack in it which goes 'did the BIOS set UDMA3+' then I guess the cable is 80 wire regardless. libata doesn't do that as it breaks with hotplug, breaks with suspend/resume before the driver is loaded and other bits. Instead we have two things - an ACPI snoop and a table of wonky laptops (eg those that use 40 wire ultrashort cables which are valid for UDMA133 but not detected as 80 wire). If your laptop is done that way then it just needs adding to the magic list and/or 2.6.23-rc1-mm should spot it by ACPI. I'd prefer the table entry anyway as I don't like relying on ACPI so an lspci -vvxx would be appreciated Sure: 00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) Subsystem: Rioworks: Unknown device 2032 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 64 Interrupt: pin A routed to IRQ 17 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 1ce0 [size=16] Capabilities: [c0] 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- 00: 06 11 71 05 05 00 90 02 06 8a 01 01 00 40 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: e1 1c 00 00 00 00 00 00 00 00 00 00 1f 16 32 20 30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 01 00 00 The machine is an Arima W730-K8, rebadged and sold as the Targa Visionary 811. eMachines and others also had this model. /Mikael - 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
2.6.23-rc1: pata_via cable detection differs from via82cxxx
The machine is an Athlon64 laptop with a K8T800 chipset. With the IDE VIA driver the disk is detected as udma/100: VP_IDE: IDE controller at PCI slot :00:11.1 ACPI: PCI Interrupt Link [ALKA] disabled and referenced, BIOS bug ACPI: PCI Interrupt Link [ALKA] BIOS reported IRQ 0, using IRQ 23 ACPI: PCI Interrupt Link [ALKA] enabled at IRQ 23 ACPI: PCI Interrupt :00:11.1[A] - Link [ALKA] - GSI 23 (level, low) - IRQ 17 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt8235 (rev 00) IDE UDMA133 controller on pci:00:11.1 ide0: BM-DMA at 0x1ce0-0x1ce7, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0x1ce8-0x1cef, BIOS settings: hdc:DMA, hdd:pio Probing IDE interface ide0... hda: TOSHIBA MK6021GAS, ATA DISK drive hda: selected mode 0x45 ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... hdc: TOSHIBA ODD-DVD SD-R6372, ATAPI CD/DVD-ROM drive hdc: selected mode 0x42 ide1 at 0x170-0x177,0x376 on irq 15 hda: max request size: 128KiB hda: 117210240 sectors (60011 MB), CHS=65535/16/63, UDMA(100) hda: cache flushes supported hda: hda1 hda2 hda3 hda4 hda5 hda6 hda7 hda8 hda9 However, the libata pata_via driver complains about the cable and drops the disk to udma/33: pata_via :00:11.1: version 0.3.1 ACPI: PCI Interrupt Link [ALKA] disabled and referenced, BIOS bug ACPI: PCI Interrupt Link [ALKA] BIOS reported IRQ 0, using IRQ 23 ACPI: PCI Interrupt Link [ALKA] enabled at IRQ 23 ACPI: PCI Interrupt :00:11.1[A] - Link [ALKA] - GSI 23 (level, low) - IRQ 17 scsi0 : pata_via scsi1 : pata_via ata1: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x00011ce0 irq 14 ata2: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x00011ce8 irq 15 ata1.00: ATA-5: TOSHIBA MK6021GAS, GA024A, max UDMA/100 ata1.00: 117210240 sectors, multi 16: LBA ata1.00: limited to UDMA/33 due to 40-wire cable ata1.00: configured for UDMA/33 ata2.00: ATAPI: TOSHIBA ODD-DVD SD-R6372, 1030, max UDMA/33 ata2.00: configured for UDMA/33 scsi 0:0:0:0: Direct-Access ATA TOSHIBA MK6021GA GA02 PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 117210240 512-byte hardware sectors (60012 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 117210240 512-byte hardware sectors (60012 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sda9 sd 0:0:0:0: [sda] Attached SCSI disk scsi 1:0:0:0: CD-ROMTOSHIBA ODD-DVD SD-R6372 1030 PQ: 0 ANSI: 5 hdparm -i confirms this: with the IDE driver it lists udma5 as the current mode, with pata_via it lists udma2 as the current mode. /Mikael - 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-dev#upstream 2/2] libata: move EH repeat reporting into ata_eh_report()
On Tue, 31 Jul 2007 16:51:00 +0900, Tejun Heo wrote: EH is sometimes repeated without any error or action. For example, this happens when probing IDENTIFY fails because of a phantom device. In these cases, all the repeated EH does is making sure there is no unhandled error or pending action and return. This repeation is necessary to avoid losing any event which occurred while EH was in progress. Unfortunately, this dry run causes annonying EH pending after completion message. This patch moves the repeat reporting into ata_eh_report() such that it's more compact and skipped on dry runs. Signed-off-by: Tejun Heo [EMAIL PROTECTED] Cc: Mikael Pettersson [EMAIL PROTECTED] --- Mikael, please verify this removes the annonying message you're seeing. Yes, this patch eliminates the EH pending after completion message I've been getting. However, patch 1/2 in this set, don't skip EH report if action is pending, causes a bunch of new exception ... frozen messages: --- dmesg-2.6.23-rc12007-07-23 12:30:12.0 +0200 +++ - 2007-07-31 23:19:21.162137100 +0200 @@ -1,44 +1,44 @@ ... -pata_pdc2027x :04:02.0: PLL input clock 16660 kHz +pata_pdc2027x :04:02.0: PLL input clock 16651 kHz scsi0 : pata_pdc2027x scsi1 : pata_pdc2027x ata1: PATA max UDMA/133 cmd 0xf88297c0 ctl 0xf8829fda bmdma 0xf8829000 irq 18 ata2: PATA max UDMA/133 cmd 0xf88295c0 ctl 0xf8829dda bmdma 0xf8829008 irq 18 +ata1: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: ATA-7: ST3320620A, 3.AAD, max UDMA/100 ata1.00: 625142448 sectors, multi 16: LBA48 ata1.00: configured for UDMA/100 +ata2: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen scsi 0:0:0:0: Direct-Access ATA ST3320620A 3.AA PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 625142448 512-byte hardware sectors (320073 MB) sd 0:0:0:0: [sda] Write Protect is off @@ -255,10 +256,11 @@ scsi3 : ata_piix ata3: SATA max UDMA/133 cmd 0x0001ec00 ctl 0x0001e882 bmdma 0x0001e400 irq 19 ata4: SATA max UDMA/133 cmd 0x0001e800 ctl 0x0001e482 bmdma 0x0001e408 irq 19 +ata3: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen +ata4: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata4.00: ATAPI: TSSTcorpCD/DVDW SH-S183A, SB00, max UDMA/33 ata4.00: applying bridge limits ata4.00: configured for UDMA/33 -ata4: EH pending after completion, repeating EH (cnt=4) scsi 3:0:0:0: CD-ROMTSSTcorp CD/DVDW SH-S183A SB00 PQ: 0 ANSI: 5 ata_piix :00:1f.5: MAP [ P0 P2 P1 P3 ] ACPI: PCI Interrupt :00:1f.5[B] - GSI 19 (level, low) - IRQ 19 @@ -267,6 +269,8 @@ scsi5 : ata_piix ata5: SATA max UDMA/133 cmd 0x0001d400 ctl 0x0001d082 bmdma 0x0001c880 irq 19 ata6: SATA max UDMA/133 cmd 0x0001d000 ctl 0x0001cc02 bmdma 0x0001c888 irq 19 +ata5: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen +ata6: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. usbcore: registered new interface driver usbfs This is with both 1/2 and 2/2 applied, with only 2/2 applied the EH pending ... is gone and the new exception ... frozen don't appear. /Mikael - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.23-rc1] ata_piix: EH pending after completion, repeating EH (cnt=4)
On Mon, 30 Jul 2007 16:52:01 +0900, Tejun Heo wrote: Mikael Pettersson wrote: Sure, here are the boot messages with the newer debug patch: Of course I missed again. Here's yet another debug patch. Sorry about the trouble. No problem. Here's the kernel messages with the 3rd version of the patch: pata_pdc2027x :04:02.0: version 0.9 ACPI: PCI Interrupt :04:02.0[A] - GSI 23 (level, low) - IRQ 18 pata_pdc2027x :04:02.0: PLL input clock 16660 kHz scsi0 : pata_pdc2027x scsi1 : pata_pdc2027x ata1: PATA max UDMA/133 cmd 0xf88297c0 ctl 0xf8829fda bmdma 0xf8829000 irq 18 ata2: PATA max UDMA/133 cmd 0xf88295c0 ctl 0xf8829dda bmdma 0xf8829008 irq 18 EH scheduled with LOADING set [c022bd0e] ata_host_register+0x1ee/0x2c0 [c022c780] ata_interrupt+0x0/0x200 [c022be59] ata_host_activate+0x79/0x90 [c023432a] pdc2027x_init_one+0x23a/0x2d0 [c01cda96] pci_device_probe+0x56/0x80 [c020e4a8] driver_probe_device+0x88/0x190 [c02963c5] klist_next+0x55/0xb0 [c020e6fa] __driver_attach+0x7a/0x80 [c020d8ba] bus_for_each_dev+0x3a/0x60 [c020e326] driver_attach+0x16/0x20 [c020e680] __driver_attach+0x0/0x80 [c020dc7a] bus_add_driver+0x8a/0x1b0 [c01cdc46] __pci_register_driver+0x56/0x90 [c032b830] kernel_init+0x140/0x310 [c0102a12] ret_from_fork+0x6/0x1c [c032b6f0] kernel_init+0x0/0x310 [c032b6f0] kernel_init+0x0/0x310 [c0103717] kernel_thread_helper+0x7/0x10 === ata1: soft resetting port ata1.00: ATA-7: ST3320620A, 3.AAD, max UDMA/100 ata1.00: 625142448 sectors, multi 16: LBA48 ata1.00: configured for UDMA/100 ata1: EH complete EH scheduled with LOADING set [c022bd0e] ata_host_register+0x1ee/0x2c0 [c022c780] ata_interrupt+0x0/0x200 [c022be59] ata_host_activate+0x79/0x90 [c023432a] pdc2027x_init_one+0x23a/0x2d0 [c01cda96] pci_device_probe+0x56/0x80 [c020e4a8] driver_probe_device+0x88/0x190 [c02963c5] klist_next+0x55/0xb0 [c020e6fa] __driver_attach+0x7a/0x80 [c020d8ba] bus_for_each_dev+0x3a/0x60 [c020e326] driver_attach+0x16/0x20 [c020e680] __driver_attach+0x0/0x80 [c020dc7a] bus_add_driver+0x8a/0x1b0 [c01cdc46] __pci_register_driver+0x56/0x90 [c032b830] kernel_init+0x140/0x310 [c0102a12] ret_from_fork+0x6/0x1c [c032b6f0] kernel_init+0x0/0x310 [c032b6f0] kernel_init+0x0/0x310 [c0103717] kernel_thread_helper+0x7/0x10 === ata2: soft resetting port ata2: EH complete scsi 0:0:0:0: Direct-Access ATA ST3320620A 3.AA PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 625142448 512-byte hardware sectors (320073 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 625142448 512-byte hardware sectors (320073 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sda9 sda10 sd 0:0:0:0: [sda] Attached SCSI disk ... ata_piix :00:1f.2: version 2.11 ata_piix :00:1f.2: MAP [ P0 P2 P1 P3 ] ACPI: PCI Interrupt :00:1f.2[B] - GSI 19 (level, low) - IRQ 19 PCI: Setting latency timer of device :00:1f.2 to 64 scsi2 : ata_piix scsi3 : ata_piix ata3: SATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001ff90 irq 14 ata4: SATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001ff98 irq 15 EH scheduled with LOADING set [c022bd0e] ata_host_register+0x1ee/0x2c0 [c02308dd] ata_pci_init_one+0x12d/0x250 [f8822580] piix_init_one+0x1d0/0x540 [ata_piix] [c01cda96] pci_device_probe+0x56/0x80 [c020e4a8] driver_probe_device+0x88/0x190 [c02963c5] klist_next+0x55/0xb0 [c020e6fa] __driver_attach+0x7a/0x80 [c020d8ba] bus_for_each_dev+0x3a/0x60 [c020e326] driver_attach+0x16/0x20 [c020e680] __driver_attach+0x0/0x80 [c020dc7a] bus_add_driver+0x8a/0x1b0 [c01cdc46] __pci_register_driver+0x56/0x90 [f8834014] piix_init+0x14/0x26 [ata_piix] [c0139fc6] sys_init_module+0x126/0x1860 [c0113f54] do_page_fault+0x484/0x670 [c0227370] ata_port_start+0x0/0x70 [c0102b2e] syscall_call+0x7/0xb [c029] rtmsg_fib+0x40/0x180 === ata3: soft resetting port ata3: EH complete EH scheduled with LOADING set [c022bd0e] ata_host_register+0x1ee/0x2c0 [c02308dd] ata_pci_init_one+0x12d/0x250 [f8822580] piix_init_one+0x1d0/0x540 [ata_piix] [c01cda96] pci_device_probe+0x56/0x80 [c020e4a8] driver_probe_device+0x88/0x190 [c02963c5] klist_next+0x55/0xb0 [c020e6fa] __driver_attach+0x7a/0x80 [c020d8ba] bus_for_each_dev+0x3a/0x60 [c020e326] driver_attach+0x16/0x20 [c020e680] __driver_attach+0x0/0x80 [c020dc7a] bus_add_driver+0x8a/0x1b0 [c01cdc46] __pci_register_driver+0x56/0x90 [f8834014] piix_init+0x14/0x26 [ata_piix] [c0139fc6] sys_init_module+0x126/0x1860 [c0113f54] do_page_fault+0x484/0x670 [c0227370] ata_port_start+0x0/0x70 [c0102b2e] syscall_call+0x7/0xb [c029] rtmsg_fib+0x40/0x180 === ata4: soft resetting port EH
Re: [PATCH] pata_cmd64x: Correct the speed ranges
On Thu, 26 Jul 2007 18:43:01 +0100, Alan Cox wrote: I must have been half asleep when doing the original code Signed-off-by: Alan Cox [EMAIL PROTECTED] [patch to fix .udma_mask in pata_cmd64x omitted] This fix inspired me to finally try to convert my Sun Ultra5 (sparc64) with a CMD646 [1095:0646 rev 03] to libata. With pata_cmd64x the machine has so far survived a usual boot/mrproper/reconfig/make/install/reboot kernel update cycle without any issues, and performance seems to be the same as with the old IDE driver. /Mikael scsi0 : pata_cmd64x scsi1 : pata_cmd64x ata1: PATA max MWDMA2 cmd 0x01fe02c0 ctl 0x01fe02ca bmdma 0x01fe02c00020 irq 14 ata2: PATA max MWDMA2 cmd 0x01fe02c00010 ctl 0x01fe02c0001a bmdma 0x01fe02c00028 irq 14 ata1.00: ATA-4: ST320420A, 3.21, max UDMA/66 ata1.00: 39851760 sectors, multi 0: LBA pata_cmd64x: active 3 recovery 1 setup 1. ata1.00: configured for MWDMA2 ata2.00: ATAPI: CRD-8483B, 1.00, max UDMA/33 pata_cmd64x: active 3 recovery 1 setup 1. ata2.00: configured for MWDMA2 scsi 0:0:0:0: Direct-Access ATA ST320420A3.21 PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 39851760 512-byte hardware sectors (20404 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 39851760 512-byte hardware sectors (20404 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sda4 sda5 sd 0:0:0:0: [sda] Attached SCSI disk scsi 1:0:0:0: CD-ROMLG CD-ROM CRD-8483B 1.00 PQ: 0 ANSI: 5 - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.23-rc1] ata_piix: EH pending after completion, repeating EH (cnt=4)
On Thu, 26 Jul 2007 15:31:10 +0900, Tejun Heo wrote: Mikael Pettersson wrote: On Tue, 24 Jul 2007 17:32:29 +0900, Tejun Heo wrote: Mikael Pettersson wrote: This machine has a known good Samsung SATA DVD on ICH8 [8086:2820]. With kernel 2.6.23-rc1 I now get the following: ata_piix :00:1f.2: version 2.11 ata_piix :00:1f.2: MAP [ P0 P2 P1 P3 ] ACPI: PCI Interrupt :00:1f.2[B] - GSI 19 (level, low) - IRQ 19 PCI: Setting latency timer of device :00:1f.2 to 64 scsi2 : ata_piix scsi3 : ata_piix ata3: SATA max UDMA/133 cmd 0x0001ec00 ctl 0x0001e882 bmdma 0x0001e400 irq 19 ata4: SATA max UDMA/133 cmd 0x0001e800 ctl 0x0001e482 bmdma 0x0001e408 irq 19 ata4.00: ATAPI: TSSTcorpCD/DVDW SH-S183A, SB00, max UDMA/33 ata4.00: applying bridge limits ata4.00: configured for UDMA/33 ata4: EH pending after completion, repeating EH (cnt=4) scsi 3:0:0:0: CD-ROMTSSTcorp CD/DVDW SH-S183A SB00 PQ: 0 ANSI: 5 The EH pending after completion is new and did not occur with 2.6.22. Apart from that message, things seem fine. Hmmm... That means someone requested EH while EH was in progress. Weird. Can you apply the attached patch and report what the kernel says? Thanks. Here it is. As you can see from the traces, the machine also has a pdc20269 controller driven by pata_pdc2027x. Hmm... I missed one path. Can you please try the attached patch? Thanks. Sure, here are the boot messages with the newer debug patch: pata_pdc2027x :04:02.0: PLL input clock 16660 kHz scsi0 : pata_pdc2027x scsi1 : pata_pdc2027x ata1: PATA max UDMA/133 cmd 0xf88297c0 ctl 0xf8829fda bmdma 0xf8829000 irq 18 ata2: PATA max UDMA/133 cmd 0xf88295c0 ctl 0xf8829dda bmdma 0xf8829008 irq 18 EH scheduled with LOADING set [c022bd0e] ata_host_register+0x1ee/0x2c0 [c022c780] ata_interrupt+0x0/0x200 [c022be59] ata_host_activate+0x79/0x90 [c02342fa] pdc2027x_init_one+0x23a/0x2d0 [c01cda96] pci_device_probe+0x56/0x80 [c020e4a8] driver_probe_device+0x88/0x190 [c0296395] klist_next+0x55/0xb0 [c020e6fa] __driver_attach+0x7a/0x80 [c020d8ba] bus_for_each_dev+0x3a/0x60 [c020e326] driver_attach+0x16/0x20 [c020e680] __driver_attach+0x0/0x80 [c020dc7a] bus_add_driver+0x8a/0x1b0 [c01cdc46] __pci_register_driver+0x56/0x90 [c032b830] kernel_init+0x140/0x310 [c0102a12] ret_from_fork+0x6/0x1c [c032b6f0] kernel_init+0x0/0x310 [c032b6f0] kernel_init+0x0/0x310 [c0103717] kernel_thread_helper+0x7/0x10 === ata1: soft resetting port ata1.00: ATA-7: ST3320620A, 3.AAD, max UDMA/100 ata1.00: 625142448 sectors, multi 16: LBA48 ata1.00: configured for UDMA/100 ata1: EH complete EH scheduled with LOADING set [c022bd0e] ata_host_register+0x1ee/0x2c0 [c022c780] ata_interrupt+0x0/0x200 [c022be59] ata_host_activate+0x79/0x90 [c02342fa] pdc2027x_init_one+0x23a/0x2d0 [c01cda96] pci_device_probe+0x56/0x80 [c020e4a8] driver_probe_device+0x88/0x190 [c0296395] klist_next+0x55/0xb0 [c020e6fa] __driver_attach+0x7a/0x80 [c020d8ba] bus_for_each_dev+0x3a/0x60 [c020e326] driver_attach+0x16/0x20 [c020e680] __driver_attach+0x0/0x80 [c020dc7a] bus_add_driver+0x8a/0x1b0 [c01cdc46] __pci_register_driver+0x56/0x90 [c032b830] kernel_init+0x140/0x310 [c0102a12] ret_from_fork+0x6/0x1c [c032b6f0] kernel_init+0x0/0x310 [c032b6f0] kernel_init+0x0/0x310 [c0103717] kernel_thread_helper+0x7/0x10 === ata2: soft resetting port ata2: EH complete scsi 0:0:0:0: Direct-Access ATA ST3320620A 3.AA PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 625142448 512-byte hardware sectors (320073 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 625142448 512-byte hardware sectors (320073 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sda9 sda10 sd 0:0:0:0: [sda] Attached SCSI disk ... ata_piix :00:1f.2: version 2.11 ata_piix :00:1f.2: MAP [ P0 P2 P1 P3 ] ACPI: PCI Interrupt :00:1f.2[B] - GSI 19 (level, low) - IRQ 19 PCI: Setting latency timer of device :00:1f.2 to 64 scsi2 : ata_piix scsi3 : ata_piix ata3: SATA max UDMA/133 cmd 0x0001ec00 ctl 0x0001e882 bmdma 0x0001e400 irq 19 ata4: SATA max UDMA/133 cmd 0x0001e800 ctl 0x0001e482 bmdma 0x0001e408 irq 19 EH scheduled with LOADING set [c022bd0e] ata_host_register+0x1ee/0x2c0 [c02308dd] ata_pci_init_one+0x12d/0x250 [f8822580] piix_init_one+0x1d0/0x540 [ata_piix] [c01cda96] pci_device_probe+0x56/0x80 [c020e4a8] driver_probe_device+0x88/0x190 [c0296395] klist_next+0x55/0xb0 [c020e6fa] __driver_attach+0x7a/0x80 [c020d8ba] bus_for_each_dev+0x3a/0x60 [c020e326] driver_attach+0x16/0x20 [c020e680] __driver_attach+0x0/0x80 [c020dc7a] bus_add_driver+0x8a/0x1b0 [c01cdc46] __pci_register_driver+0x56
[2.6.23-rc1] ata_piix: EH pending after completion, repeating EH (cnt=4)
This machine has a known good Samsung SATA DVD on ICH8 [8086:2820]. With kernel 2.6.23-rc1 I now get the following: ata_piix :00:1f.2: version 2.11 ata_piix :00:1f.2: MAP [ P0 P2 P1 P3 ] ACPI: PCI Interrupt :00:1f.2[B] - GSI 19 (level, low) - IRQ 19 PCI: Setting latency timer of device :00:1f.2 to 64 scsi2 : ata_piix scsi3 : ata_piix ata3: SATA max UDMA/133 cmd 0x0001ec00 ctl 0x0001e882 bmdma 0x0001e400 irq 19 ata4: SATA max UDMA/133 cmd 0x0001e800 ctl 0x0001e482 bmdma 0x0001e408 irq 19 ata4.00: ATAPI: TSSTcorpCD/DVDW SH-S183A, SB00, max UDMA/33 ata4.00: applying bridge limits ata4.00: configured for UDMA/33 ata4: EH pending after completion, repeating EH (cnt=4) scsi 3:0:0:0: CD-ROMTSSTcorp CD/DVDW SH-S183A SB00 PQ: 0 ANSI: 5 The EH pending after completion is new and did not occur with 2.6.22. Apart from that message, things seem fine. /Mikael - 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 1/1] libata: pata_pdc2027x PLL input clock fix
On Tue, 10 Jul 2007 11:52:59 +0800, Albert Lee wrote: Recently the PLL input clock of pata_pdc2027x is sometimes detected higer than expected (e.g. 20.027 MHz compared to 16.714 MHz). It seems sometimes the mdelay() function is not as precise as it used to be. Per Alan's advice, HT or power management might affect the precision of mdelay(). This patch calls gettimeofday() to mesure the time elapsed and calculate the PLL input clock accordingly. Unfortunately this breaks pata_pdc2027x on my PowerMac G3: snip In fairness, this is a slightly non-standard PowerMac G3, in that it has a G4 upgrade processor. The firmware doesn't recognise the CPU and gives some CPU core frequency-related properties too low values. However, the bus frequency property _is_ correct, which is what most or all timing stuff should be based on. Looks like a platform bug. According to the document, do_gettimeofday() has microsecond resolution. Since the driver calls mdelay(100) (10 microseconds), it won't affect the PLL input clock calculation much if somehow do_gettimeofday() drifts several (say 100) microseconds. Could you please apply the attached debug patch and collect more info on the PowerMac G3. Hopefully we can have more clue. Thanks. -- albert (BTW, maybe opening a bug in bugzilla.kernel.org would help the debugging.) --- 00_libata-dev/drivers/ata/pata_pdc2027x.c 2007-07-07 09:58:55.0 +0800 +++ 01_debug/drivers/ata/pata_pdc2027x.c 2007-07-10 11:18:38.0 +0800 @@ -722,6 +722,15 @@ static long pdc_detect_pll_input_clock(s pll_clock = (start_count - end_count) / 100 * (1 / usec_elapsed); + do_gettimeofday(start_time); + mdelay(37); + do_gettimeofday(end_time); + usec_elapsed = (end_time.tv_sec - start_time.tv_sec) * 100 + + (end_time.tv_usec - start_time.tv_usec); + printk(KERN_ERR usec_elapsed for mdelay(37) [%ld]\n, usec_elapsed); + printk(KERN_ERR start time: [%ld]s [%ld]us \n, start_time.tv_sec, start_time.tv_usec); + printk(KERN_ERR end time: [%ld]s [%ld]us \n, end_time.tv_sec, end_time.tv_usec); + PDPRINTK(start[%ld] end[%ld] \n, start_count, end_count); PDPRINTK(PLL input clock[%ld]Hz\n, pll_clock); 2.6.22 + this prints the following on my G3: pata_pdc2027x :00:0e.0: version 0.9 usec_elapsed for mdelay(37) [35431] start time: [1184112028]s [775333]us end time: [1184112028]s [810764]us pata_pdc2027x :00:0e.0: PLL input clock 1691741 kHz pata_pdc2027x: Invalid PLL input clock 1691741kHz, give up! /Mikael - 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 2/7] sata_promise: pdc_freeze() semantic change
On Sat, 07 Jul 2007 15:02:49 +0800, Albert Lee wrote: After checking the current implementations of freeze()/thaw(), it seems only pdc_freeze() does more than simple irq masking. Remove the DMA stop code from pdc_freeze(). Signed-off-by: Albert Lee [EMAIL PROTECTED] --- diff -Nrup 01_remove_leftover_irqon/drivers/ata/sata_promise.c 02_sata_pdc_freeze/drivers/ata/sata_promise.c --- 01_remove_leftover_irqon/drivers/ata/sata_promise.c2007-07-07 09:58:55.0 +0800 +++ 02_sata_pdc_freeze/drivers/ata/sata_promise.c 2007-07-07 10:39:22.0 +0800 @@ -578,7 +578,6 @@ static void pdc_freeze(struct ata_port * tmp = readl(mmio + PDC_CTLSTAT); tmp |= PDC_IRQ_DISABLE; - tmp = ~PDC_DMA_ENABLE; writel(tmp, mmio + PDC_CTLSTAT); readl(mmio + PDC_CTLSTAT); /* flush */ } pdc_freeze() halts in-flight DMAs because that's what libata specifices. E.g., Documentation/DocBook/libata.tmpl writes: void (*freeze) (struct ata_port *ap); void (*thaw) (struct ata_port *ap); /programlisting para ata_port_freeze() is called when HSM violations or some other condition disrupts normal operation of the port. A frozen port is not allowed to perform any operation until the port is thawed, which usually follows a successful reset. /para para The optional -freeze() callback can be used for freezing the port hardware-wise (e.g. mask interrupt and stop DMA engine). If a port cannot be frozen hardware-wise, the interrupt handler must ack and clear interrupts unconditionally while the port is frozen. /para para The optional -thaw() callback is called to perform the opposite of -freeze(): prepare the port for normal operation once again. Unmask interrupts, start DMA engine, etc. Similar wording exists in libata-eh.c above __ata_port_freeze(). Albert's patch is OK as far as sata_promise is concerned, but I want to see an update of libata.tmpl and libata-eh.c to indicate the new, weakened, specification of freeze/thaw before I ACK this patch. /Mikael - 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: Libata PATA status
On Tue, 3 Jul 2007 23:04:26 -0400, Kyle Moffett wrote: Has anyone started a rewrite of the PPC/PowerMac IDE driver? The current one is in drivers/ide/ppc/pmac.c, and supports these chipsets: OHare ATA Heathrow ATA KeyLargo ATA-3 KeyLargo ATA-4 UniNorth ATA-6 (IE: Kauai) K2 ATA-6 Shasta ATA-6 I'd be willing to test drivers for the UniNorth ATA-6 and K2 ATA-6, as well as possibly the KeyLargo ATA-3/4, depending on what the old MDD G4 in my closet has. Sadly my libata-foo is insufficient for me to do anything useful (other than thoroughly testing my backup- restoration procedure, maybe :-D). And I'd be happy to test a libata pmac driver on Heathrow (Beige G3) and KeyLargo ATA-3/UniNorth ATA-6 (eMac G4). - 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_promise: SATA hotplug support, take 2
This patch enables hotplugging of SATA devices in the
sata_promise driver. It's been tested successfully on
both first- and second-generation Promise SATA chips:
SATA150 TX2plus, SATAII150 TX2plus, SATAII150 TX4,
SATA300 TX2plus, and SATA300 TX4.
The only quirk I've seen is that hotplugging (insertion)
on the first-generation SATA150 TX2plus requires a lengthier
EH sequence than on the second-generation chips.
On the second-generation chips a simple soft reset seems
to suffice, but on the first-generation chip there's a
port is slow to respond after the initial soft reset,
after which libata issues a hard reset, and then the
device is recognised.
The hotplug checks are high up in the interrupt handling
path, not deep down in error_intr as in ahci/sata_sil24.
That's because the chip doesn't signal hotplug status changes
in the per-port status register: instead a global register
contains hotplug control and status flags for all ports.
I considered following the ahci/sata_sil24 structure, but
that would have required non-trivial changes to the interrupt
handling path, so I chose to keep the hotplug changes simple
and unobtrusive.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
--
This patch depends on the sata_promise: cleanups patch.
Changes since the previous version (posted June 19):
- Correct pdc_interrupt() to increment 'handled' also in
the hotplug case. This prevents IRQ_NONE from being
returned when an interrupt only has hotplug events to
handle, which could confuse the kernel's IRQ machinery.
- Added testing on the SATAII150 TX4.
drivers/ata/sata_promise.c | 41 -
1 files changed, 36 insertions(+), 5 deletions(-)
--- linux-2.6.22-rc7/drivers/ata/sata_promise.c.~1~ 2007-07-02
23:31:33.0 +0200
+++ linux-2.6.22-rc7/drivers/ata/sata_promise.c 2007-07-02 23:32:15.0
+0200
@@ -45,7 +45,7 @@
#include sata_promise.h
#define DRV_NAME sata_promise
-#define DRV_VERSION2.08
+#define DRV_VERSION2.09
enum {
PDC_MAX_PORTS = 4,
@@ -716,6 +716,9 @@ static irqreturn_t pdc_interrupt (int ir
unsigned int i, tmp;
unsigned int handled = 0;
void __iomem *mmio_base;
+ unsigned int hotplug_offset, ata_no;
+ u32 hotplug_status;
+ int is_sataii_tx4;
VPRINTK(ENTER\n);
@@ -726,10 +729,20 @@ static irqreturn_t pdc_interrupt (int ir
mmio_base = host-iomap[PDC_MMIO_BAR];
+ /* read and clear hotplug flags for all ports */
+ if (host-ports[0]-flags PDC_FLAG_GEN_II)
+ hotplug_offset = PDC2_SATA_PLUG_CSR;
+ else
+ hotplug_offset = PDC_SATA_PLUG_CSR;
+ hotplug_status = readl(mmio_base + hotplug_offset);
+ if (hotplug_status 0xff)
+ writel(hotplug_status | 0xff, mmio_base + hotplug_offset);
+ hotplug_status = 0xff; /* clear uninteresting bits */
+
/* reading should also clear interrupts */
mask = readl(mmio_base + PDC_INT_SEQMASK);
- if (mask == 0x) {
+ if (mask == 0x hotplug_status == 0) {
VPRINTK(QUICK EXIT 2\n);
return IRQ_NONE;
}
@@ -737,16 +750,34 @@ static irqreturn_t pdc_interrupt (int ir
spin_lock(host-lock);
mask = 0x; /* only 16 tags possible */
- if (!mask) {
+ if (mask == 0 hotplug_status == 0) {
VPRINTK(QUICK EXIT 3\n);
goto done_irq;
}
writel(mask, mmio_base + PDC_INT_SEQMASK);
+ is_sataii_tx4 = pdc_is_sataii_tx4(host-ports[0]-flags);
+
for (i = 0; i host-n_ports; i++) {
VPRINTK(port %u\n, i);
ap = host-ports[i];
+
+ /* check for a plug or unplug event */
+ ata_no = pdc_port_no_to_ata_no(i, is_sataii_tx4);
+ tmp = hotplug_status (0x11 ata_no);
+ if (tmp ap
+ !(ap-flags ATA_FLAG_DISABLED)) {
+ struct ata_eh_info *ehi = ap-eh_info;
+ ata_ehi_clear_desc(ehi);
+ ata_ehi_hotplugged(ehi);
+ ata_ehi_push_desc(ehi, hotplug_status %#x, tmp);
+ ata_port_freeze(ap);
+ ++handled;
+ continue;
+ }
+
+ /* check for a packet interrupt */
tmp = mask (1 (i + 1));
if (tmp ap
!(ap-flags ATA_FLAG_DISABLED)) {
@@ -902,9 +933,9 @@ static void pdc_host_init(struct ata_hos
tmp = readl(mmio + hotplug_offset);
writel(tmp | 0xff, mmio + hotplug_offset);
- /* mask plug/unplug ints */
+ /* unmask plug/unplug ints */
tmp = readl(mmio + hotplug_offset);
- writel(tmp | 0xff, mmio + hotplug_offset);
+ writel(tmp ~0xff, mmio + hotplug_offset);
/* don't initialise TBG or SLEW on 2nd generation
[PATCH 2.6.22-rc7] sata_sil24: sil24_interrupt() micro-optimisation
sil24_interrupt() loads host-ports[i] into a local variable,
validates it, and then loads the value again in the call to
sil24_host_intr(). This patch replaces the second load by a
reference to the local variable.
This is safe since no side-effects have occurred since the
initial load. It also improves readability since it makes
it clear that the parameter to sil24_host_intr() is the same
value which was just validated.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
--- linux-2.6.22-rc7/drivers/ata/sata_sil24.c.~1~ 2007-07-02
21:41:37.0 +0200
+++ linux-2.6.22-rc7/drivers/ata/sata_sil24.c 2007-07-02 23:28:57.0
+0200
@@ -888,7 +888,7 @@ static irqreturn_t sil24_interrupt(int i
if (status (1 i)) {
struct ata_port *ap = host-ports[i];
if (ap !(ap-flags ATA_FLAG_DISABLED)) {
- sil24_host_intr(host-ports[i]);
+ sil24_host_intr(ap);
handled++;
} else
printk(KERN_ERR DRV_NAME
-
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 patches] libata fixes
On Wed, 27 Jun 2007 03:35:26 -0400, Jeff Garzik wrote: Tejun Heo (9): libata: kill the infamous abnormal status message libata: kill non-sense warning message libata: be less verbose about hpa libata: remove unused variable from ata_eh_reset() libata: fix ata_dev_disable() libata: fix infinite EH waiting bug libata: call ata_check_atapi_dma() with qc better prepared libata: use PIO for non-16 byte aligned ATAPI commands libata: kill ATA_HORKAGE_DMA_RW_ONLY These changes fixed the CDROM IDENTIFY failures one of my older test machines used to get with libata. I now get much nicer results on that machine: ata_piix :00:1f.1: version 2.11 PCI: Setting latency timer of device :00:1f.1 to 64 scsi0 : ata_piix scsi1 : ata_piix ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001f000 irq 14 ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001f008 irq 15 ata1.00: ATA-5: IC35L080AVVA07-0, VA4OA52A, max UDMA/100 ata1.00: 160836480 sectors, multi 16: LBA ata1.00: configured for UDMA/100 ata2.00: ATAPI: CRD-8320B, 1.12, max MWDMA2 ata2.01: ATAPI: Hewlett-Packard CD-Writer Plus 9100, 1.0c, max UDMA/33 ata2.00: configured for MWDMA2 ata2.01: configured for UDMA/33 scsi 0:0:0:0: Direct-Access ATA IC35L080AVVA07-0 VA4O PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 160836480 512-byte hardware sectors (82348 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 160836480 512-byte hardware sectors (82348 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sda4 sda5 sda6 sd 0:0:0:0: [sda] Attached SCSI disk scsi 1:0:0:0: CD-ROMGoldStar CD-ROM CRD-8320B 1.12 PQ: 0 ANSI: 5 scsi 1:0:1:0: CD-ROMHP CD-Writer+ 9100 1.0c PQ: 0 ANSI: 5 It's the CRD-8320B that used to time out and fail IDENTIFY. Tested-by: Mikael Pettersson [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: is Promise TX4302 supported?
On Wed, 27 Jun 2007 03:46:47 +0200, [EMAIL PROTECTED] wrote: I'm considering buying a four-channel SATA PCI controller marked as Promise TX-4302 (two internal SATA links, two eSATA, independent on each other). According to the product page at Promise [1], Linux is missing from the list of supported operating systems, although Google suggests that online stores include Linux in the list of supported OSes. I wasn't able to find this chip mentioned at the list of supported chipsets [2]. There's a similarly looking TX-4, but I don't like the idea of buying a nice room decoration instead of a working device. I wasn't able to find out any reference to AHCI in the specs, either. I can't find any publicly available linux driver source or technical documentation for the TX4302, so I cannot say if it will work as-is, or what the differences to the standard SATA300 TX4 might be. - 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 RAID5 speed drop of 100 MB/s
On Sun, 24 Jun 2007 10:54:56 +1000, Eyal Lebedinsky wrote: Jeff Garzik wrote: [trim] Given that some drives might be better tuned for benchmarks in non-queued mode, and that a major behavior difference is that your drives are now NCQ-enabled, the first thing I would suggest you try is disabling NCQ: http://linux-ata.org/faq.html#ncq I see in my bootup messages: ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata6.00: ATA-7: WDC WD3200YS-01PGB0, 21.00M21, max UDMA/133 ata6.00: 625142448 sectors, multi 0: LBA48 NCQ (depth 0/1) ata6.00: configured for UDMA/133 and I wonder how to interpret NCQ (depth 0/1). Does this drive support NCQ or not? Controller: Promise SATA-II-150-TX4. Kernel: 2.6.21.5, x86 Your drive does, but the driver for your controller does not (yet). /Mikael - 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_promise disk error 2.6.22-rc5 with hrt1 patch
(cc: linux-ide added) On Sun, 24 Jun 2007 20:49:05 +0200, otto Meier wrote: I got the following in my logs: Jun 24 19:06:40 gate2 kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Jun 24 19:06:40 gate2 kernel: ata4.00: (port_status 0x1000) Jun 24 19:06:40 gate2 kernel: ata4.00: cmd 35/00:00:c1:17:92/00:04:17:00:00/e0 tag 0 cdb 0x0 data 524288 out Jun 24 19:06:40 gate2 kernel: res 50/00:00:c0:1b:92/00:00:17:00:00/e0 Emask 0x20 (host bus error) Jun 24 19:06:40 gate2 kernel: ata4.00: ata_hpa_resize 1: sectors = 488397168, hpa_sectors = 488397168 Jun 24 19:06:40 gate2 kernel: ata4.00: ata_hpa_resize 1: sectors = 488397168, hpa_sectors = 488397168 Jun 24 19:06:40 gate2 kernel: ata4.00: configured for UDMA/133 Jun 24 19:06:40 gate2 kernel: ata4: EH complete Jun 24 19:06:40 gate2 kernel: sd 3:0:0:0: [sdd] 488397168 512-byte hardware sectors (250059 MB) Jun 24 19:06:40 gate2 kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Jun 24 19:06:40 gate2 kernel: ata4.00: (port_status 0x1000) Jun 24 19:06:40 gate2 kernel: ata4.00: cmd 25/00:00:c1:15:92/00:02:17:00:00/e0 tag 0 cdb 0x0 data 262144 in Jun 24 19:06:40 gate2 kernel: res 50/00:00:c0:17:92/00:00:17:00:00/e0 Emask 0x20 (host bus error) Jun 24 19:06:40 gate2 kernel: ata4.00: ata_hpa_resize 1: sectors = 488397168, hpa_sectors = 488397168 Jun 24 19:06:40 gate2 kernel: ata4.00: ata_hpa_resize 1: sectors = 488397168, hpa_sectors = 488397168 Jun 24 19:06:40 gate2 kernel: ata4.00: configured for UDMA/133 Jun 24 19:06:40 gate2 kernel: ata4: EH complete Jun 24 19:06:40 gate2 kernel: sd 3:0:0:0: [sdd] Write Protect is off Jun 24 19:06:40 gate2 kernel: sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00 Jun 24 19:06:40 gate2 kernel: sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Jun 24 19:06:40 gate2 kernel: sd 3:0:0:0: [sdd] 488397168 512-byte hardware sectors (250059 MB) Jun 24 19:06:40 gate2 kernel: sd 3:0:0:0: [sdd] Write Protect is off Jun 24 19:06:40 gate2 kernel: sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00 Jun 24 19:06:40 gate2 kernel: sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA The system continued without seeing other effects. It is runnuning a 2.6.22-rc5 kernel with hrt1 patch. The drive ist part of a raid5 with 4 identical drives lspci -vvv gives: 02:06.0 Mass storage controller: Promise Technology, Inc. PDC40718 (SATA 300 TX4) (rev 02) The 300 TX4 model is causing transient errors for several people, and we don't yet know why. In your case, port_status 0x1000 means that host bus is busy more than 256 clock cycles for every ATA I/O transfer (quoting the docs). Basically it's a timeout. As long as it's transient, don't worry. You may want to try without hrt1 to see if hrt1 is causing the issue. /Mikael - 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
2.6.22-rc5 libata/ata_piix failure with older CDROM
I tried (again) to convert an Intel i815EP-chipset machine from IDE to libata, but libata still fails to initialise the CDROM on the machine. With 2.6.22-rc5, IDE says: Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ICH2: IDE controller at PCI slot :00:1f.1 ICH2: chipset revision 5 ICH2: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA Probing IDE interface ide0... hda: IC35L080AVVA07-0, ATA DISK drive hda: selected mode 0x45 ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... hdc: CRD-8320B, ATAPI CD/DVD-ROM drive hdd: Hewlett-Packard CD-Writer Plus 9100, ATAPI CD/DVD-ROM drive hdc: selected mode 0x22 hdd: selected mode 0x42 ide1 at 0x170-0x177,0x376 on irq 15 hda: max request size: 128KiB hda: 160836480 sectors (82348 MB) w/1863KiB Cache, CHS=65535/16/63, UDMA(100) hda: cache flushes supported hda: hda1 hda2 hda3 hda4 hda5 hda6 Switching to libata (ata_piix) results in: ata_piix :00:1f.1: version 2.11 PCI: Setting latency timer of device :00:1f.1 to 64 scsi0 : ata_piix scsi1 : ata_piix ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001f000 irq 14 ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001f008 irq 15 ata1.00: ata_hpa_resize 1: sectors = 160836480, hpa_sectors = 160836480 ata1.00: ATA-5: IC35L080AVVA07-0, VA4OA52A, max UDMA/100 ata1.00: 160836480 sectors, multi 16: LBA ata1.00: ata_hpa_resize 1: sectors = 160836480, hpa_sectors = 160836480 ata1.00: configured for UDMA/100 ata2.00: ATAPI: CRD-8320B, 1.12, max MWDMA2 ata2.01: ATAPI: Hewlett-Packard CD-Writer Plus 9100, 1.0c, max UDMA/33 ata2.00: configured for MWDMA2 ata2.01: configured for UDMA/33 scsi 0:0:0:0: Direct-Access ATA IC35L080AVVA07-0 VA4O PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 160836480 512-byte hardware sectors (82348 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 160836480 512-byte hardware sectors (82348 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sda4 sda5 sda6 sd 0:0:0:0: [sda] Attached SCSI disk ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata2: port is slow to respond, please be patient (Status 0xd0) ata2: device not ready (errno=-16), forcing hardreset ata2: BUG: prereset() requested invalid reset type ata2: soft resetting port ATA: abnormal status 0x80 on port 0x00010177 ATA: abnormal status 0x80 on port 0x00010177 ATA: abnormal status 0x80 on port 0x00010177 ATA: abnormal status 0x80 on port 0x00010177 ATA: abnormal status 0x80 on port 0x00010177 ATA: abnormal status 0x80 on port 0x00010177 ATA: abnormal status 0x80 on port 0x00010177 ata2.00: failed to IDENTIFY (I/O error, err_mask=0x1) ata2.00: revalidation failed (errno=-5) ata2: failed to recover some devices, retrying in 5 secs ata2: soft resetting port ata2.00: configured for MWDMA2 ata2.01: configured for UDMA/33 ata2: EH complete ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata2: port is slow to respond, please be patient (Status 0xd0) ata2: device not ready (errno=-16), forcing hardreset ata2: BUG: prereset() requested invalid reset type ata2: soft resetting port ATA: abnormal status 0x80 on port 0x00010177 ATA: abnormal status 0x80 on port 0x00010177 ATA: abnormal status 0x80 on port 0x00010177 ATA: abnormal status 0x80 on port 0x00010177 ATA: abnormal status 0x80 on port 0x00010177 ATA: abnormal status 0x80 on port 0x00010177 ATA: abnormal status 0x80 on port 0x00010177 ata2.00: failed to IDENTIFY (I/O error, err_mask=0x1) ata2.00: revalidation failed (errno=-5) ata2: failed to recover some devices, retrying in 5 secs ata2: soft resetting port ata2.00: configured for MWDMA2 ata2.01: configured for UDMA/33 ata2: EH complete ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata2: port is slow to respond, please be patient (Status 0xd0) ata2: device not ready (errno=-16), forcing hardreset ata2: BUG: prereset() requested invalid reset type ata2: soft resetting port ATA: abnormal status 0x80 on port 0x00010177 ATA: abnormal status 0x80 on port 0x00010177 ATA: abnormal status 0x80 on port 0x00010177 ATA: abnormal status
Re: ide/dma not working from 2.6.19 to 2.6.21
On Thu, 21 Jun 2007 12:47:30 +0100, Bahadir Balban [EMAIL PROTECTED] wrote:
I have a PCI Promise TX2 Ultra133 controller with a harddisk on an ARM
platform (which is a barebone system with no BIOS). This setup used to
work with the old linux-ide drivers on 2.6.19 but it does not work
with 2.6.22-rc4, or 2.6.21. Here's the error output:
PDC20269: chipset revision 2
6PDC20269: ROM enabled at 0xa021
PDC20269: ROM enabled at 0xa021
PDC20269: PLL input clock is 37736 kHz
PDC20269: PLL input clock is 37736 kHz
6PDC20269: 100% native mode on irq 84
PDC20269: 100% native mode on irq 84
7PCI: Enabling bus mastering for device :07:01.0
6ide0: BM-DMA at 0x90050040-0x90050047ide0: BM-DMA at
0x90050040-0x90050047, BIOS settings
: hda:pio, hdb:pio, BIOS settings: hda:pio, hdb:pio
6ide1: BM-DMA at 0x90050048-0x9005004fide1: BM-DMA at
0x90050048-0x9005004f, BIOS settings
: hdc:pio, hdd:pio, BIOS settings: hdc:pio, hdd:pio
7Probing IDE interface ide0...
hda: HDS728080PLAT20, hda: HDS728080PLAT20, ATA DISK drive
ATA DISK drive
4Warning: Primary channel requires an 80-pin cable for operation.
Warning: Primary channel requires an 80-pin cable for operation.
4hda reduced to Ultra33 mode.
hda reduced to Ultra33 mode.
ide0 at 0x90050050-0x90050057,0x90050062 on irq 84ide0 at
0x90050050-0x90050057,0x90050062 on irq 84
7Probing IDE interface ide1...
7Probing IDE interface ide1...
6hda: max request size: 512KiB
hda: max request size: 512KiB
4hda: lost interrupt
hda: lost interrupt
4hda: lost interrupt
hda: lost interrupt
4hda: lost interrupt
hda: lost interrupt
6hda: 160836480 sectors (82348 MB)hda: 160836480 sectors (82348 MB)
w/1719KiB Cache w/1719KiB Cach
e, CHS=16383/255/63, CHS=16383/255/63, UDMA(33), UDMA(33)
4hda: lost interrupt
hda: lost interrupt
6hda: cache flushes supported
hda: cache flushes supported
6 hda: hda:4hda: dma_timer_expiry: dma status == 0x21
4hda: dma_timer_expiry: dma status == 0x21
4hda: DMA timeout error
hda: DMA timeout error
hda: dma timeout error: status=0x51 { hda: dma timeout error:
status=0x51 { DriveReady DriveReady Se
ekComplete SeekComplete Error Error }
}
hda: dma timeout error: error=0x84 { hda: dma timeout error:
error=0x84 { DriveStatusError DriveStat
usError BadCRC BadCRC }}
ide: failed opcode was: ide: failed opcode was: unknown
unknown
4hda: lost interrupt
hda: lost interrupt
On 2.6.21 I have been using:
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_BLK_DEV_PDC202XX_NEW=y
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_OFFBOARD=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
On 2.6.19 I have exactly the same but also:
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_IDEDMA_AUTO=y
Could this have caused a problem?
Does IDE support in linux depend on certain BIOS settings or any other
motherboard specific details? I am asking because neither the new ata
nor the old ide layer worked for the cards I tried on ARM (JMB363,
IT8212, Promise TX2 133 - worked only with 2.6.19 old ide layer).
Try kernel 2.6.21 or newer and the libata driver for this card
instead (pata_pdc2027x). I'm using that in a PowerMac whose
firmware doesn't initialise the card at boot, and it works for me.
What kind of ARM board is this?
/Mikael
-
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.6.22-rc5 1/2] sata_promise: cleanups
This patch applies some trivial cleanups to sata_promise:
- repair whitespace damage
- correct comment at board_2057x_pata definition
- pull SATAII TX4 support code out to separate functions
- rename ata_nr to ata_no for consistency with libata's port_no
- remove some init-time debug printks (requested by Jeff)
This patch should cause no behavioural changes, except for
the removed printks.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
--
drivers/ata/sata_promise.c | 56 ++---
1 files changed, 23 insertions(+), 33 deletions(-)
--- linux-2.6.22-rc5/drivers/ata/sata_promise.c.~1~ 2007-06-19
20:38:13.0 +0200
+++ linux-2.6.22-rc5/drivers/ata/sata_promise.c 2007-06-19 20:40:28.0
+0200
@@ -45,8 +45,7 @@
#include sata_promise.h
#define DRV_NAME sata_promise
-#define DRV_VERSION2.07
-
+#define DRV_VERSION2.08
enum {
PDC_MAX_PORTS = 4,
@@ -94,7 +93,7 @@ enum {
board_20319 = 2,/* FastTrak S150 TX4 */
board_20619 = 3,/* FastTrak TX4000 */
board_2057x = 4,/* SATAII150 Tx2plus */
- board_2057x_pata= 5,/* SATAII150 Tx2plus */
+ board_2057x_pata= 5,/* SATAII150 Tx2plus PATA port */
board_40518 = 6,/* SATAII150 Tx4 */
PDC_HAS_PATA= (1 1), /* PDC20375/20575 has PATA */
@@ -124,7 +123,6 @@ enum {
PDC_FLAG_4_PORTS= (1 26), /* 4 ports */
};
-
struct pdc_port_priv {
u8 *pkt;
dma_addr_t pkt_dma;
@@ -340,7 +338,6 @@ static const struct pci_device_id pdc_at
{ } /* terminate list */
};
-
static struct pci_driver pdc_ata_pci_driver = {
.name = DRV_NAME,
.id_table = pdc_ata_pci_tbl,
@@ -348,7 +345,6 @@ static struct pci_driver pdc_ata_pci_dri
.remove = ata_pci_remove_one,
};
-
static int pdc_common_port_start(struct ata_port *ap)
{
struct device *dev = ap-host-dev;
@@ -438,7 +434,6 @@ static u32 pdc_sata_scr_read (struct ata
return readl(ap-ioaddr.scr_addr + (sc_reg * 4));
}
-
static void pdc_sata_scr_write (struct ata_port *ap, unsigned int sc_reg,
u32 val)
{
@@ -657,8 +652,8 @@ static void pdc_error_intr(struct ata_po
ata_port_abort(ap);
}
-static inline unsigned int pdc_host_intr( struct ata_port *ap,
- struct ata_queued_cmd *qc)
+static inline unsigned int pdc_host_intr(struct ata_port *ap,
+struct ata_queued_cmd *qc)
{
unsigned int handled = 0;
void __iomem *port_mmio = ap-ioaddr.cmd_addr;
@@ -685,10 +680,10 @@ static inline unsigned int pdc_host_intr
handled = 1;
break;
-default:
+ default:
ap-stats.idle_irq++;
break;
-}
+ }
return handled;
}
@@ -701,6 +696,18 @@ static void pdc_irq_clear(struct ata_por
readl(mmio + PDC_INT_SEQMASK);
}
+static inline int pdc_is_sataii_tx4(unsigned long flags)
+{
+ const unsigned long mask = PDC_FLAG_GEN_II | PDC_FLAG_4_PORTS;
+ return (flags mask) == mask;
+}
+
+static inline unsigned int pdc_port_no_to_ata_no(unsigned int port_no, int
is_sataii_tx4)
+{
+ static const unsigned char sataii_tx4_port_remap[4] = { 3, 1, 0, 2};
+ return is_sataii_tx4 ? sataii_tx4_port_remap[port_no] : port_no;
+}
+
static irqreturn_t pdc_interrupt (int irq, void *dev_instance)
{
struct ata_host *host = dev_instance;
@@ -807,7 +814,6 @@ static void pdc_tf_load_mmio(struct ata_
ata_tf_load(ap, tf);
}
-
static void pdc_exec_command_mmio(struct ata_port *ap, const struct
ata_taskfile *tf)
{
WARN_ON (tf-protocol == ATA_PROT_DMA ||
@@ -867,7 +873,6 @@ static void pdc_ata_setup_port(struct at
ap-ioaddr.scr_addr = scr_addr;
}
-
static void pdc_host_init(struct ata_host *host)
{
void __iomem *mmio = host-iomap[PDC_MMIO_BAR];
@@ -955,10 +960,8 @@ static int pdc_ata_init_one (struct pci_
if (pi-flags PDC_FLAG_SATA_PATA) {
u8 tmp = readb(base + PDC_FLASH_CTL+1);
- if (!(tmp 0x80)) {
+ if (!(tmp 0x80))
ppi[n_ports++] = pi + 1;
- dev_printk(KERN_INFO, pdev-dev, PATA port found\n);
- }
}
host = ata_host_alloc_pinfo(pdev-dev, ppi, n_ports);
@@ -968,22 +971,12 @@ static int pdc_ata_init_one (struct pci_
}
host-iomap = pcim_iomap_table(pdev);
- is_sataii_tx4 = 0;
- if ((pi-flags (PDC_FLAG_GEN_II|PDC_FLAG_4_PORTS)) ==
(PDC_FLAG_GEN_II|PDC_FLAG_4_PORTS)) {
- is_sataii_tx4 = 1;
- dev_printk(KERN_INFO, pdev-dev, applying SATAII TX4 port
numbering workaround\n
[PATCH 2.6.22-rc5 2/2] sata_promise: SATA hotplug support
This patch enables hotplugging of SATA devices in the
sata_promise driver. It's been tested successfully on
both first- and second-generation Promise SATA chips:
SATA150 TX2plus, SATAII150 TX2plus, SATA300 TX2plus,
and SATA300 TX4.
The only quirk I've seen is that hotplugging (insertion)
on the first-generation SATA150 TX2plus requires a lengthier
EH sequence than on the second-generation chips.
On the second-generation chips a simple soft reset seems
to suffice, but on the first-generation chip there's a
port is slow to respond after the initial soft reset,
after which libata issues a hard reset, and then the
device is recognised.
The hotplug checks are high up in the interrupt handling
path, not deep down in error_intr as in ahci/sata_sil24.
That's because the chip doesn't signal hotplug status changes
in the per-port status register: instead a global register
contains hotplug control and status flags for all ports.
I considered following the ahci/sata_sil24 structure, but
that would have required non-trivial changes to the interrupt
handling path, so I chose to keep the hotplug changes simple
and unobtrusive.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
--
This patch depends on patch 1/2: sata_promise: cleanups.
Changes since the preliminary version:
- cleanups
- added testing on the first-generation SATA150 TX2plus
drivers/ata/sata_promise.c | 40 +++-
1 files changed, 35 insertions(+), 5 deletions(-)
--- linux-2.6.22-rc5/drivers/ata/sata_promise.c.~1~ 2007-06-19
20:40:28.0 +0200
+++ linux-2.6.22-rc5/drivers/ata/sata_promise.c 2007-06-19 20:41:36.0
+0200
@@ -45,7 +45,7 @@
#include sata_promise.h
#define DRV_NAME sata_promise
-#define DRV_VERSION2.08
+#define DRV_VERSION2.09
enum {
PDC_MAX_PORTS = 4,
@@ -716,6 +716,9 @@ static irqreturn_t pdc_interrupt (int ir
unsigned int i, tmp;
unsigned int handled = 0;
void __iomem *mmio_base;
+ unsigned int hotplug_offset, ata_no;
+ u32 hotplug_status;
+ int is_sataii_tx4;
VPRINTK(ENTER\n);
@@ -726,10 +729,20 @@ static irqreturn_t pdc_interrupt (int ir
mmio_base = host-iomap[PDC_MMIO_BAR];
+ /* read and clear hotplug flags for all ports */
+ if (host-ports[0]-flags PDC_FLAG_GEN_II)
+ hotplug_offset = PDC2_SATA_PLUG_CSR;
+ else
+ hotplug_offset = PDC_SATA_PLUG_CSR;
+ hotplug_status = readl(mmio_base + hotplug_offset);
+ if (hotplug_status 0xff)
+ writel(hotplug_status | 0xff, mmio_base + hotplug_offset);
+ hotplug_status = 0xff; /* clear uninteresting bits */
+
/* reading should also clear interrupts */
mask = readl(mmio_base + PDC_INT_SEQMASK);
- if (mask == 0x) {
+ if (mask == 0x hotplug_status == 0) {
VPRINTK(QUICK EXIT 2\n);
return IRQ_NONE;
}
@@ -737,16 +750,33 @@ static irqreturn_t pdc_interrupt (int ir
spin_lock(host-lock);
mask = 0x; /* only 16 tags possible */
- if (!mask) {
+ if (mask == 0 hotplug_status == 0) {
VPRINTK(QUICK EXIT 3\n);
goto done_irq;
}
writel(mask, mmio_base + PDC_INT_SEQMASK);
+ is_sataii_tx4 = pdc_is_sataii_tx4(host-ports[0]-flags);
+
for (i = 0; i host-n_ports; i++) {
VPRINTK(port %u\n, i);
ap = host-ports[i];
+
+ /* check for a plug or unplug event */
+ ata_no = pdc_port_no_to_ata_no(i, is_sataii_tx4);
+ tmp = hotplug_status (0x11 ata_no);
+ if (tmp ap
+ !(ap-flags ATA_FLAG_DISABLED)) {
+ struct ata_eh_info *ehi = ap-eh_info;
+ ata_ehi_clear_desc(ehi);
+ ata_ehi_hotplugged(ehi);
+ ata_ehi_push_desc(ehi, hotplug_status %#x, tmp);
+ ata_port_freeze(ap);
+ continue;
+ }
+
+ /* check for a packet interrupt */
tmp = mask (1 (i + 1));
if (tmp ap
!(ap-flags ATA_FLAG_DISABLED)) {
@@ -902,9 +932,9 @@ static void pdc_host_init(struct ata_hos
tmp = readl(mmio + hotplug_offset);
writel(tmp | 0xff, mmio + hotplug_offset);
- /* mask plug/unplug ints */
+ /* unmask plug/unplug ints */
tmp = readl(mmio + hotplug_offset);
- writel(tmp | 0xff, mmio + hotplug_offset);
+ writel(tmp ~0xff, mmio + hotplug_offset);
/* don't initialise TBG or SLEW on 2nd generation chips */
if (is_gen2)
-
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: Machine hanging on synchronize cache on shutdown 2.6.22-rc4-git[45678]
On Mon, 18 Jun 2007 16:09:49 +0900, Tejun Heo wrote: Mikael Pettersson wrote: On Sat, 16 Jun 2007 15:52:33 +0400, Brad Campbell wrote: I've got a box here based on current Debian Stable. It's got 15 Maxtor SATA drives in it on 4 Promise TX4 controllers. Using kernel 2.6.21.x it shuts down, but of course with a huge clack as 15 drives all do emergency head parks simultaneously. I thought I'd upgrade to 2.6.22-rc to get around this but the machine just hangs up hard apparently trying to sync cache on a drive. I've run this process manually, so I know it is being performed properly. Prior to shutdown, all nfsd processes are stopped, filesystems unmounted and md arrays stopped. /proc/mdstat shows [EMAIL PROTECTED]:~# cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] unused devices: none [EMAIL PROTECTED]:~# Here is the final hangup. http://www.fnarfbargle.com/CIMG1029.JPG Something sent a command to the disk on ata15 after the PHY had been offlined and the interface had been put in SLUMBER state (SStatus 614). Consequently the command timed out. Libata tried a soft reset, and then a hard reset, after which the machine hung. Hmm... weird. Maybe device initiated power saving (DIPS) is active? I don't think sata_promise is the guilty party here. Looks like some layer above sata_promise got confused about the state of the interface. But locking up hard after hardreset is a problem of sata_promise, no? Maybe, maybe not. The original report doesn't specify where/how the machine hung. Brad: can you enable sysrq and check if the kernel responds to sysrq when it appears to hang, and if so, where it's executing? sata_promise just passes sata_std_hardreset to ata_do_eh. I've certainly seen EH hardresets work before, so I'm assuming that something in this particular situation (PHY offlined, kernel close to shutting down) breaks things. FWIW, I'm seeing scsi layer accesses (cache flushes) after things like rmmod sata_promise. They error out and don't seem to cause any harm, but the fact that they occur at all makes me nervous. /Mikael - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
sata_promise: preliminary hotplug support
This crude but simple patch enables hotplugging of SATA
disks in the sata_promise driver. Tested successfully on
SATAII150 TX2plus, SATA300 TX2plus, and SATA300 TX4.
The TX4 is significant because of the port_nr-to-ata_nr
remapping that occurs for those chips, which affects
the hotplug status change check for a given port.
While this patch works for me, I consider it preliminary
because it duplicates code and open-codes stuff, so some
cleanups are certainly needed. Also I haven't been able
to test it on first-generation chips yet.
The hotplug checks are high up in the interrupt handling
path, not deep down in error_intr as in ahci/sata_sil24.
That's because the chip doesn't signal hotplug status changes
in the per-port status register: instead a global register
contains hotplug control and status flags for all ports.
I considered following the ahci/sata_sil24 structure, but
that would have required non-trivial changes to the interrupt
handling path, so I chose to keep the hotplug changes simple
and unobtrusive.
/Mikael
(not a formal patch submission, hence no signed-off line)
--- linux-2.6.22-rc5/drivers/ata/sata_promise.c.~1~ 2007-06-17
22:03:46.0 +0200
+++ linux-2.6.22-rc5/drivers/ata/sata_promise.c 2007-06-17 23:43:51.0
+0200
@@ -709,6 +709,9 @@
unsigned int i, tmp;
unsigned int handled = 0;
void __iomem *mmio_base;
+ unsigned int hotplug_offset;
+ u32 hotplug_status;
+ int is_sataii_tx4;
VPRINTK(ENTER\n);
@@ -719,10 +722,22 @@
mmio_base = host-iomap[PDC_MMIO_BAR];
+ /* read and clear hotplug flags for all ports */
+ if (host-ports[0]-flags PDC_FLAG_GEN_II)
+ hotplug_offset = PDC2_SATA_PLUG_CSR;
+ else
+ hotplug_offset = PDC_SATA_PLUG_CSR;
+ hotplug_status = readl(mmio_base + hotplug_offset);
+ if (hotplug_status 0xff) {
+ writel(hotplug_status | 0xff, mmio_base + hotplug_offset);
+ printk(%s: hotplug_status %#x\n, __FUNCTION__,
hotplug_status);
+ }
+ hotplug_status = 0xff; /* clear uninteresting bits */
+
/* reading should also clear interrupts */
mask = readl(mmio_base + PDC_INT_SEQMASK);
- if (mask == 0x) {
+ if (mask == 0x hotplug_status == 0) {
VPRINTK(QUICK EXIT 2\n);
return IRQ_NONE;
}
@@ -730,16 +745,39 @@
spin_lock(host-lock);
mask = 0x; /* only 16 tags possible */
- if (!mask) {
+ if (!mask hotplug_status == 0) {
VPRINTK(QUICK EXIT 3\n);
goto done_irq;
}
writel(mask, mmio_base + PDC_INT_SEQMASK);
+ /* XXX: ugly ugly ugly */
+ is_sataii_tx4 = 0;
+ if ((host-ports[0]-flags (PDC_FLAG_GEN_II|PDC_FLAG_4_PORTS)) ==
+ (PDC_FLAG_GEN_II|PDC_FLAG_4_PORTS))
+ is_sataii_tx4 = 1;
+
for (i = 0; i host-n_ports; i++) {
VPRINTK(port %u\n, i);
ap = host-ports[i];
+ {
+ static const unsigned char sataii_tx4_port_remap[4] = {
3, 1, 0, 2};
+ int ata_nr = i;
+
+ if (is_sataii_tx4)
+ ata_nr = sataii_tx4_port_remap[i];
+
+ if ((hotplug_status (0x11 ata_nr)) ap
+ !(ap-flags ATA_FLAG_DISABLED)) {
+ struct ata_eh_info *ehi = ap-eh_info;
+ ata_ehi_clear_desc(ehi);
+ ata_ehi_hotplugged(ehi);
+ ata_ehi_push_desc(ehi, hotplug_status %#x,
hotplug_status);
+ ata_port_freeze(ap);
+ continue;
+ }
+ }
tmp = mask (1 (i + 1));
if (tmp ap
!(ap-flags ATA_FLAG_DISABLED)) {
@@ -897,9 +935,9 @@
tmp = readl(mmio + hotplug_offset);
writel(tmp | 0xff, mmio + hotplug_offset);
- /* mask plug/unplug ints */
+ /* unmask plug/unplug ints */
tmp = readl(mmio + hotplug_offset);
- writel(tmp | 0xff, mmio + hotplug_offset);
+ writel(tmp ~0xff, mmio + hotplug_offset);
/* don't initialise TBG or SLEW on 2nd generation chips */
if (is_gen2)
-
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: Machine hanging on synchronize cache on shutdown 2.6.22-rc4-git[45678]
On Sat, 16 Jun 2007 15:52:33 +0400, Brad Campbell wrote: I've got a box here based on current Debian Stable. It's got 15 Maxtor SATA drives in it on 4 Promise TX4 controllers. Using kernel 2.6.21.x it shuts down, but of course with a huge clack as 15 drives all do emergency head parks simultaneously. I thought I'd upgrade to 2.6.22-rc to get around this but the machine just hangs up hard apparently trying to sync cache on a drive. I've run this process manually, so I know it is being performed properly. Prior to shutdown, all nfsd processes are stopped, filesystems unmounted and md arrays stopped. /proc/mdstat shows [EMAIL PROTECTED]:~# cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] unused devices: none [EMAIL PROTECTED]:~# Here is the final hangup. http://www.fnarfbargle.com/CIMG1029.JPG Something sent a command to the disk on ata15 after the PHY had been offlined and the interface had been put in SLUMBER state (SStatus 614). Consequently the command timed out. Libata tried a soft reset, and then a hard reset, after which the machine hung. I don't think sata_promise is the guilty party here. Looks like some layer above sata_promise got confused about the state of the interface. I did a quick sata_promise test here with kernel 2.6.22-rc4-git8 and FC4 userspace, and there was no problem shutting the machine down. /Mikael - 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: Promise TX4 (PDC40718) hotplug support
On Wed, 6 Jun 2007 15:51:23 +0200, Jan Kasprzak wrote: I have a Promise TX4 controller, and I have problems with hotplug. It seems the controller does not recongnize the drive being hot-removed or hot-plugged. I need either to reload the sata_promise module, or to do # echo 1 /sys/block/sdN/device/delete to remove the drive, and # echo 0 0 0 /sys/class/scs_host/hostN/scan to scan for a new drive. Another box with nVidia CK08 (sata_nv) can recognize the removal and insertion of the drive as hotplug events (so udev correctly remove and create the /dev nodes, etc.), so I thought with Promise TX4 it would be the same, especially as http://linux-ata.org/driver-status.html says about TX2/TX4 the following: Full SATA control including hotplug and PM on all. Is hotplug supported with this controller? The Promise SATA hardware supports hotplug, but the driver doesn't yet handle it. It's on my TODO list. (When I get some spare time, sigh.) /Mikael - 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 patches] libata fixes
On Fri, 25 May 2007 18:03:07 -0400, Jeff Garzik wrote:
Jeff Garzik (4):
[libata] sata_promise: fix flags typo
...
--- a/drivers/ata/sata_promise.c
+++ b/drivers/ata/sata_promise.c
@@ -297,7 +297,7 @@ static const struct ata_port_info pdc_port_info[] = {
/* board_2057x_pata */
{
- .flags = PDC_COMMON_FLAGS | ATA_FLAG_SLAVE_POSS,
+ .flags = PDC_COMMON_FLAGS | ATA_FLAG_SLAVE_POSS |
PDC_FLAG_GEN_II,
.pio_mask = 0x1f, /* pio0-4 */
.mwdma_mask = 0x07, /* mwdma0-2 */
Acked-by: Mikael Pettersson [EMAIL PROTECTED]
Good catch. This typo would have prevented pdc_host_intr()
from detecting GEN_II-specific errors on the PATA port.
-
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] sata_promise: Port enumeration order - SATA 150 TX4,
[added cc:linux-ide] Hans A Eide writes: Evan Harris wrote: I have a card that mirrors this one from your list: Retail name: SATA300 TX4 Chip label: PDC40718-GP SATAII300 Vendor-Device number: 105a:3d17 (rev 02) Through testing, I've found linux 2.6.16 and 2.6.17 find the ports in this order (the list is ordered by linux detection): 1. silkscreen port 3 2. silkscreen port 2 3. silkscreen port 4 4. silkscreen port 1 NOTE: the patch I have submitted ( http://marc.theaimsgroup.com/?l=linux- idem=114082978311290w=2 ) is a solution that doesn't know about the older Promise SATA controllers, which are not affected with the new wiring problem, so the older controllers will appear screwed if you use it. Hopefully we will collect enough info about all the SATA Promise controllers to distinguish the new and the old wiring controllers, then produce a new patch that will be a correct solution to the new wiring problem. Mikael Pettersson has been doing some excellent work recently on sata_promise. If enough data has been collected on this sata_promise port enumeration problem, maybe the data could be collated and proposed via Mikael as a patch? Jeff Sorry, any updates on this? You should have posted this to linux-ide not linux-scsi. The Promise SATAII TX4 port enumeration issue is fixed in current 2.6.22-rc kernels. A patch for 2.6.21 can be found in http://marc.info/?l=linux-idem=117728096711046w=2. /Mikael - 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_promise: which version/patch to test?
On Thu, 10 May 2007 21:41:32 +0200, Peter Favrholdt wrote: I would like to help by testing the most recent version of the sata_promise driver on my Promise Technology, Inc. PDC40718 (SATA 300 TX4) (rev 02) with 4 Seagate 500GB ES drives: Model Number: ST3500630NS Firmware Revision: 3.AEE (with 1.5/3.0Gbps jumper removed = 3.0Gbps) This setup experienced a problem a while ago which was fixed using 2.6.21-rc2 + Mikael Petterssons force 1.5Gbps patch. Could someone provide a hint on what sources/patches I should get? E.g. vanilla 2.6.21.1 + ? For a SATA 300 TX4 you should test version 2.07 of sata_promise.c. You can get it in 2.6.21-git16, or 2.6.21-mm2 plus the following two patches: http://user.it.uu.se/~mikpe/linux/patches/2.6/patch-sata_promise-1-error_intr-abort_port-2.6.21-mm2 http://user.it.uu.se/~mikpe/linux/patches/2.6/patch-sata_promise-2-sataii-tx4-port-numbering-fix-2.6.21-mm2 or 2.6.21 plus the following three patches: http://user.it.uu.se/~mikpe/linux/patches/2.6/patch-sata_promise-1-separate-sata-pata-ops-2.6.21 http://user.it.uu.se/~mikpe/linux/patches/2.6/patch-sata_promise-2-error_intr-2.6.21 http://user.it.uu.se/~mikpe/linux/patches/2.6/patch-sata_promise-3-sataii-tx4-port-numbering-fix-2.6.21 Note that this corrects the longstanding mis-enumeration of ports on SATAII TX4 cards, so you may need to adjust your /etc/fstab and boot-time root= parameter if you're using hard-coded partition names. /Mikael - 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 2.6.21-mm1 2/2] sata_promise: SATAII-150/300 TX4 port numbering fix
Jeff Garzik writes:
+ if ((pi-flags (PDC_FLAG_GEN_II|PDC_FLAG_4_PORTS)) ==
(PDC_FLAG_GEN_II|PDC_FLAG_4_PORTS)) {
+ is_sataii_tx4 = 1;
+ dev_printk(KERN_INFO, pdev-dev, applying SATAII TX4 port
numbering workaround\n);
...though I'm not sure the printk is really wanted. nonetheless, I
applied it.
Thanks.
There's also the older PATA port found\n, which is redundant
since libata will print PATA as it logs the corresponding ata dev.
I can remove both if you like.
/Mikael
-
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_promise - another sata dvd writer problem
On Sun, 06 May 2007 16:35:11 +0200, Sven Lemke wrote: I'm using kernel 2.6.21-mm1 and get strange problems when connecting my new SATA DVD writer to the TX2Plus Promise controller. It works with an slightly older kernel version though. And since I couldn't figure out who is responsible for the driver I decided to post my problem here. How much older? Does 2.6.21 vanilla work? sata_promise :00:0b.0: version 2.05 ... ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata2.00: ATAPI, max UDMA/33 ata2.00: applying bridge limits ata2.00: configured for UDMA/33 sd 0:0:0:0: [sda] Attached SCSI disk sd 0:0:0:0: Attached scsi generic sg0 type 0 scsi 1:0:0:0: CD-ROM TSSTcorp CD/DVDW SH-S183L SB01 PQ: 0 ANSI: 5 ... ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: (port_status 0x2020) ata2.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 res 40/00:02:00:60:00/00:00:00:00:00/a0 Emask 0x5 (timeout) etc Probably fallout from a mistake I made in the error decoding update. Apply the patch below, try again, and let us know if it works or not. /Mikael --- linux-2.6.21-mm1/drivers/ata/sata_promise.c.~1~ 2007-05-05 22:24:41.0 +0200 +++ linux-2.6.21-mm1/drivers/ata/sata_promise.c 2007-05-05 22:25:21.0 +0200 @@ -653,6 +653,8 @@ static void pdc_error_intr(struct ata_po qc-err_mask |= ac_err_mask; pdc_reset_port(ap); + + ata_port_abort(ap); } static inline unsigned int pdc_host_intr( struct ata_port *ap, - 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.6.21-mm1 1/2] sata_promise: fix another error decode regression
The sata_promise error decode update changed pdc_host_intr()
to return and not complete the qc after detecting an error.
Unfortunately not completing the qc:s causes them to always
time out on error, which is wrong and has nasty side-effects.
This patch updates pdc_error_intr() to call ata_port_abort(),
similar to ahci and sata_sil24. Doing this is important as it
makes EH see the original error and not a bogus timeout.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
---
Thanks to Tejun for educating me about the significance of
ata_port_abort()/ata_port_freeze() in ahci and sata_sil24's
error intr paths.
drivers/ata/sata_promise.c |4 +++-
1 files changed, 3 insertions(+), 1 deletion(-)
--- linux-2.6.21-mm1/drivers/ata/sata_promise.c.~1~ 2007-05-06
20:29:01.0 +0200
+++ linux-2.6.21-mm1/drivers/ata/sata_promise.c 2007-05-06 20:29:28.0
+0200
@@ -45,7 +45,7 @@
#include sata_promise.h
#define DRV_NAME sata_promise
-#define DRV_VERSION2.05
+#define DRV_VERSION2.06
enum {
@@ -653,6 +653,8 @@ static void pdc_error_intr(struct ata_po
qc-err_mask |= ac_err_mask;
pdc_reset_port(ap);
+
+ ata_port_abort(ap);
}
static inline unsigned int pdc_host_intr( struct ata_port *ap,
-
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.6.21-mm1 2/2] sata_promise: SATAII-150/300 TX4 port numbering fix
There is a known problem with sata_promise on SATAII-150/300 TX4
controller cards: it enumerates drives in an order that differs
from the port numbers printed on the controller cards. However,
Promise's BIOS and Linux driver both get the order right.
I investigated Promise's Linux driver (v1.01.0.23), and found
that it explicitly changes the mapping from logical port number
to ATA engine MMIO address on the SATAII TX4 cards. It does this
on all SATAII TX4 cards, without inspecting revision etc. The
SATAII TX2plus cards continue to use the same mapping that was
used for the first-generation chips.
This patch updates sata_promise to use the new port number to
ATA engine mapping on SATAII TX4 cards, which fixes the drive
enumeration order problem on those cards. Tested on several
1st and 2nd generation TX2plus and TX4 chips.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
---
Changes since previous submission: ported to libata#ALL and the
new init model, updated to apply after the fix for the 2nd error
decode regression.
drivers/ata/sata_promise.c | 22 ++
1 files changed, 18 insertions(+), 4 deletions(-)
--- linux-2.6.21-mm1/drivers/ata/sata_promise.c.~1~ 2007-05-06
20:29:28.0 +0200
+++ linux-2.6.21-mm1/drivers/ata/sata_promise.c 2007-05-06 20:30:39.0
+0200
@@ -45,7 +45,7 @@
#include sata_promise.h
#define DRV_NAME sata_promise
-#define DRV_VERSION2.06
+#define DRV_VERSION2.07
enum {
@@ -926,6 +926,7 @@ static int pdc_ata_init_one (struct pci_
struct ata_host *host;
void __iomem *base;
int n_ports, i, rc;
+ int is_sataii_tx4;
if (!printed_version++)
dev_printk(KERN_DEBUG, pdev-dev, version DRV_VERSION \n);
@@ -964,10 +965,23 @@ static int pdc_ata_init_one (struct pci_
}
host-iomap = pcim_iomap_table(pdev);
- for (i = 0; i host-n_ports; i++)
+ is_sataii_tx4 = 0;
+ if ((pi-flags (PDC_FLAG_GEN_II|PDC_FLAG_4_PORTS)) ==
(PDC_FLAG_GEN_II|PDC_FLAG_4_PORTS)) {
+ is_sataii_tx4 = 1;
+ dev_printk(KERN_INFO, pdev-dev, applying SATAII TX4 port
numbering workaround\n);
+ }
+ for (i = 0; i host-n_ports; i++) {
+ static const unsigned char sataii_tx4_port_remap[4] = { 3, 1,
0, 2};
+ int ata_nr;
+
+ ata_nr = i;
+ if (is_sataii_tx4)
+ ata_nr = sataii_tx4_port_remap[i];
+
pdc_ata_setup_port(host-ports[i],
- base + 0x200 + i * 0x80,
- base + 0x400 + i * 0x100);
+ base + 0x200 + ata_nr * 0x80,
+ base + 0x400 + ata_nr * 0x100);
+ }
/* initialize adapter */
pdc_host_init(host);
-
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.21-mm1: many processes end up in D state
On Sat, 05 May 2007 17:30:51 +0200, Tejun Heo wrote: Mikael Pettersson wrote: I.e. no freezing of ports... Your patch to delete the 'return 1;' on error is correct, and makes the code match exactly the behaviour of previous versions of sata_promise, except for the additional error decoding. ahci and sata_sil24 do the return in this situation. I don't yet understand why they can get away with it while sata_promise cannot, but for now the return should be removed. That's because sata_sil24 and ahci call either ata_port_abort() or ata_port_freeze() prior to finishing error_intr routine. Both functions abort all in-flight command and schedule EH. Ah. Thanks, that clarifies things. Jiri: please test the patch below instead. That is, revert to the original code _with_ the 'return 1;', and then add this patch to it. It should have pretty much the same effect as removing the 'return 1;', however calling ata_port_abort() is more in line with libata's new-style error handling. /Mikael --- linux-2.6.21-mm1/drivers/ata/sata_promise.c.~1~ 2007-05-05 22:24:41.0 +0200 +++ linux-2.6.21-mm1/drivers/ata/sata_promise.c 2007-05-05 22:25:21.0 +0200 @@ -653,6 +653,8 @@ static void pdc_error_intr(struct ata_po qc-err_mask |= ac_err_mask; pdc_reset_port(ap); + + ata_port_abort(ap); } static inline unsigned int pdc_host_intr( struct ata_port *ap, - 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.21-mm1: many processes end up in D state
On Fri, 04 May 2007 17:02:10 +0200, Jiri Slaby wrote:
I have a problem with higher disk loads (e.g. running git-log or yum
update).
Many processes end up in D state and system is unusable -- I'm not able to
run
anything but smooth mouse moving when this happens.
...(boring stack dumps deleted)
causes this? When I change this:
diff --git a/drivers/ata/sata_promise.c b/drivers/ata/sata_promise.c
index f56549b..a0024ae 100644
--- a/drivers/ata/sata_promise.c
+++ b/drivers/ata/sata_promise.c
@@ -668,10 +668,8 @@ static inline unsigned int pdc_host_intr( struct
ata_port *ap,
else
err_mask = ~PDC2_ERR_MASK;
port_status = readl(port_mmio + PDC_GLOBAL_CTL);
- if (unlikely(port_status err_mask)) {
+ if (unlikely(port_status err_mask))
pdc_error_intr(ap, qc, port_status, err_mask);
- return 1;
- }
switch (qc-tf.protocol) {
case ATA_PROT_DMA:
the problem disappears.
Actually changes:
ata6.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata6.00: (port_status 0x2008)
ata6.00: cmd c8/00:08:03:d3:61/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in
res 40/00:01:01:4f:c2/00:00:00:00:00/00 Emask 0x6 (timeout)
ata6: soft resetting port
ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata6.00: ata_hpa_resize 1: sectors = 156301488, hpa_sectors = 156301488
ata6.00: ata_hpa_resize 1: sectors = 156301488, hpa_sectors = 156301488
ata6.00: configured for UDMA/133
ata6: EH complete
sd 5:0:0:0: [sdc] 156301488 512-byte hardware sectors (80026 MB)
sd 5:0:0:0: [sdc] Write Protect is off
sd 5:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support
DPO
or FUA
to
ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
ata5.00: (port_status 0x2008)
ata5.00: cmd c8/00:08:bf:cd:4b/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in
res 50/00:00:c6:cd:4b/00:00:00:00:00/e0 Emask 0x2 (HSM violation)
ata5: soft resetting port
ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata5.00: ata_hpa_resize 1: sectors = 156301488, hpa_sectors = 156301488
ata5.00: ata_hpa_resize 1: sectors = 156301488, hpa_sectors = 156301488
ata5.00: configured for UDMA/133
ata5: EH complete
sd 4:0:0:0: [sdb] 156301488 512-byte hardware sectors (80026 MB)
sd 4:0:0:0: [sdb] Write Protect is off
sd 4:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 4:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support
DPO
or FUA
I.e. no freezing of ports...
Your patch to delete the 'return 1;' on error is correct,
and makes the code match exactly the behaviour of previous
versions of sata_promise, except for the additional error
decoding.
ahci and sata_sil24 do the return in this situation. I don't
yet understand why they can get away with it while sata_promise
cannot, but for now the return should be removed.
/Mikael
-
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.6.21-rc7-mm2 1/2] sata_promise: SATAII-150/300 TX4 port numbering fix
There is a known problem with sata_promise on SATAII-150/300 TX4
controller cards: it enumerates drives in an order that differs
from the port numbers printed on the controller cards. However,
Promise's BIOS and Linux driver both get the order right.
I investigated Promise's Linux driver (v1.01.0.23), and found
that it explicitly changes the mapping from logical port number
to ATA engine MMIO address on the SATAII TX4 cards. It does this
on all SATAII TX4 cards, without inspecting revision etc. The
SATAII TX2plus cards continue to use the same mapping that was
used for the first-generation chips.
This patch updates sata_promise to use the new port number to
ATA engine mapping on SATAII TX4 cards, which fixes the drive
enumeration order problem on those cards.
Tested on SATA300 TX4, SATA300 TX2plus, SATAII-150 TX2plus,
and TX4000.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
---
Patch updated to apply to current libata#upstream/#ALL.
Testing updated to include TX4000.
drivers/ata/sata_promise.c | 22 ++
1 files changed, 18 insertions(+), 4 deletions(-)
--- linux-2.6.21-rc7-mm2/drivers/ata/sata_promise.c.~1~ 2007-04-28
23:16:57.0 +0200
+++ linux-2.6.21-rc7-mm2/drivers/ata/sata_promise.c 2007-04-29
01:44:42.0 +0200
@@ -45,7 +45,7 @@
#include sata_promise.h
#define DRV_NAME sata_promise
-#define DRV_VERSION2.05
+#define DRV_VERSION2.06
enum {
@@ -924,6 +924,7 @@
struct ata_host *host;
void __iomem *base;
int n_ports, i, rc;
+ int is_sataii_tx4;
if (!printed_version++)
dev_printk(KERN_DEBUG, pdev-dev, version DRV_VERSION \n);
@@ -962,10 +963,23 @@
}
host-iomap = pcim_iomap_table(pdev);
- for (i = 0; i host-n_ports; i++)
+ is_sataii_tx4 = 0;
+ if ((pi-flags (PDC_FLAG_GEN_II|PDC_FLAG_4_PORTS)) ==
(PDC_FLAG_GEN_II|PDC_FLAG_4_PORTS)) {
+ is_sataii_tx4 = 1;
+ dev_printk(KERN_INFO, pdev-dev, applying SATAII TX4 port
numbering workaround\n);
+ }
+ for (i = 0; i host-n_ports; i++) {
+ static const unsigned char sataii_tx4_port_remap[4] = { 3, 1,
0, 2};
+ int ata_nr;
+
+ ata_nr = i;
+ if (is_sataii_tx4)
+ ata_nr = sataii_tx4_port_remap[i];
+
pdc_ata_setup_port(host-ports[i],
- base + 0x200 + i * 0x80,
- base + 0x400 + i * 0x100);
+ base + 0x200 + ata_nr * 0x80,
+ base + 0x400 + ata_nr * 0x100);
+ }
/* initialize adapter */
pdc_host_init(host);
-
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.6.21-rc7-mm2 2/2] sata_promise: move port reset from error intr to EH prereset
When sata_promise detects an error, it resets the port and
triggers EH. This is how it has always done things. New-style
EH however appears to prefer (based on ahci and sata_sil24)
error detection to just freeze the port or otherwise render
it harmless, and for the reset to be delayed until EH runs.
This patch updates sata_promise EH according to this principle.
When an error is detected in pdc_error_intr, the port is frozen
but not reset. Later in the error handler, the prereset procedure
performs the necessary Promise-specific reset of the port.
Notes:
- Since pdc_error_intr no longer resets the port, ata_do_eh()
can do its error analysis on the current register contents, so
pdc_error_intr doesn't need to copy SCR_ERROR to ehi-serror.
- The reset is done in prereset since that is the one point that
(a) comes after libata's error analysis, and (b) dominates
(in a control-flow sense) all subsequent reset parts of EH.
Tested on SATA300 TX4, SATA300 TX2plus, SATAII-150 TX2plus,
SATA150 TX2plus, and TX4000.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
---
drivers/ata/sata_promise.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
--- linux-2.6.21-rc7-mm2/drivers/ata/sata_promise.c.~1~ 2007-04-28
23:16:57.0 +0200
+++ linux-2.6.21-rc7-mm2/drivers/ata/sata_promise.c 2007-04-28
23:55:49.0 +0200
@@ -45,7 +45,7 @@
#include sata_promise.h
#define DRV_NAME sata_promise
-#define DRV_VERSION2.06
+#define DRV_VERSION2.07
enum {
@@ -598,13 +598,16 @@ static void pdc_thaw(struct ata_port *ap
readl(mmio + PDC_CTLSTAT); /* flush */
}
-static void pdc_common_error_handler(struct ata_port *ap, ata_reset_fn_t
hardreset)
+static int pdc_prereset(struct ata_port *ap, unsigned long deadline)
{
- if (!(ap-pflags ATA_PFLAG_FROZEN))
- pdc_reset_port(ap);
+ pdc_reset_port(ap);
+ return ata_std_prereset(ap, deadline);
+}
+static void pdc_common_error_handler(struct ata_port *ap, ata_reset_fn_t
hardreset)
+{
/* perform recovery */
- ata_do_eh(ap, ata_std_prereset, ata_std_softreset, hardreset,
+ ata_do_eh(ap, pdc_prereset, ata_std_softreset, hardreset,
ata_std_postreset);
}
@@ -647,12 +650,10 @@ static void pdc_error_intr(struct ata_po
| PDC_PCI_SYS_ERR | PDC1_PCI_PARITY_ERR))
ac_err_mask |= AC_ERR_HOST_BUS;
- if (sata_scr_valid(ap))
- ehi-serror |= pdc_sata_scr_read(ap, SCR_ERROR);
-
+ ehi-action |= ATA_EH_SOFTRESET;
qc-err_mask |= ac_err_mask;
- pdc_reset_port(ap);
+ ata_port_freeze(ap);
}
static inline unsigned int pdc_host_intr( struct ata_port *ap,
-
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.6.21-rc7] sata_promise: SATAII-150/300 TX4 port numbering fix
There is a known problem with sata_promise on SATAII-150/300 TX4
controller cards: it enumerates drives in an order that differs
from the port numbers printed on the controller cards. However,
Promise's BIOS and Linux driver both get the order right.
I investigated Promise's Linux driver (v1.01.0.23), and found
that it explicitly changes the mapping from logical port number
to ATA engine MMIO address on the SATAII TX4 cards. It does this
on all SATAII TX4 cards, without inspecting revision etc. The
SATAII TX2plus cards continue to use the same mapping that was
used for the first-generation chips.
This patch updates sata_promise to use the new port number to
ATA engine mapping on SATAII TX4 cards, which fixes the drive
enumeration order problem on those cards. Tested on 300 TX4,
300 TX2plus, and SATAII-150 TX2plus chips.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
---
This patch should apply to 2.6.21-rc7 and libata#upstream.
It won't apply to libata#ALL because of the massive changes
for the new init model. I will do a new and cleaner patch for
#ALL once I can get it as a patch in -mm (I don't do git).
--- linux-2.6.21-rc7/drivers/ata/sata_promise.c.~1~ 2007-04-23
00:17:35.0 +0200
+++ linux-2.6.21-rc7/drivers/ata/sata_promise.c 2007-04-23 00:18:06.0
+0200
@@ -989,7 +989,13 @@ static int pdc_ata_init_one (struct pci_
switch (board_idx) {
case board_40518:
hp-flags |= PDC_FLAG_GEN_II;
- /* Fall through */
+ printk(KERN_INFO DRV_NAME : applying SATAII-150/300 TX4 port
numbering workaround\n);
+ probe_ent-n_ports = 4;
+ pdc_ata_setup_port(probe_ent-port[2], base + 0x200, base +
0x400);
+ pdc_ata_setup_port(probe_ent-port[1], base + 0x280, base +
0x500);
+ pdc_ata_setup_port(probe_ent-port[3], base + 0x300, base +
0x600);
+ pdc_ata_setup_port(probe_ent-port[0], base + 0x380, base +
0x700);
+ break;
case board_20319:
probe_ent-n_ports = 4;
pdc_ata_setup_port(probe_ent-port[2], base + 0x300, base +
0x600);
-
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_promise ata exceptions (2.6.20.6)
On Sun, 15 Apr 2007 23:55:31 -0700, Phil Dibowitz wrote: Given that the last one was a hardware issue, I bought a new controller. Despite my bad luck, given my price-range promise still seemed to be the = one with the most good reports, so I went with that. I was going to go with a= sil, but I couldn't find one.. Anyway, things are MUCH better now... but about once a week, I get: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: (port_status 0x1000) ata2.00: cmd c8/00:80:9a:71:d0/00:00:00:00:00/ea tag 0 cdb 0x0 data 65536= in res 40/00:00:06:4f:c2/00:00:00:00:00/00 Emask 0x24 (host bus err= or) ata2: soft resetting port ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata2.00: configured for UDMA/133 ata2: EH complete SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't suppo= rt DPO or FUA It's the same port_status and Emask/SAct/SErr/action each time... only th= e cmd/res and data change (obviously those would change)... Can anyone tell me what that means? port_status 0x1000 is host bus timeout, which the manual defines as the host bus being busy for more than 256 clock cycles during an ATA I/O transfer. I have no idea what would cause this error, and I've never seen it myself. As long as libata recovers and doesn't downgrade your transfer speed it shouldn't pose too much of a problem. /Mikael - 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-2.6] cmd64x: procfs code fixes/cleanups (take 2)
On Sat, 14 Apr 2007 23:41:16 +0400, Sergei Shtylyov wrote: While at it, also perform the following cleanups: ... - correct the chipset names (from CMDxxx to PCI-xxx) Please explain why this rename is a correction. Did the company making these chips change name at some point? Or did they change the names of the chips? CMD64x is an established name, while PCI-xxx is something I've never heard of (and it sounds awfully generic). /Mikael - 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: promise ncq
On Fri, 13 Apr 2007 23:43:03 +0300, Raz Ben-Jehuda(caro) [EMAIL PROTECTED] wrote: Jeff hello I have a promise cotroller that exports its disks as logical volumes to the OS, and the OS sees them as physical drives . kernel is 2.6.17. I have set a disk manualy to support ncq using a command line tool provided by promise. I have echo 1 /sys/block//dev/rescan and the ncq bit did not show in dmesg. queue_depth is set to 32 no matter if ncq is enabled or not. I cannot echo to queue_depth , I get permision denied error ( libata faq says i can do that ). Assuming you're using libata's sata_promise driver and not Promise's driver, then the answer is that sata_promise doesn't yet support NCQ. It will display the disk's NCQ capability, but NCQ won't be activated. Implementing NCQ is on the TODO list, but I'm ignoring it as long as the problems with SATAII/3Gbps disks remain unresolved. /Mikael - 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 08/12] libata: convert drivers with combined SATA/PATA ports to new init model
On Wed, 11 Apr 2007 15:42:05 +0900, Tejun Heo wrote:
...
diff --git a/drivers/ata/sata_promise.c b/drivers/ata/sata_promise.c
index baa8368..8e8fe59 100644
--- a/drivers/ata/sata_promise.c
+++ b/drivers/ata/sata_promise.c
...
@@ -333,7 +349,7 @@ static struct pci_driver pdc_ata_pci_driver = {
};
-static int pdc_common_port_start(struct ata_port *ap)
+static int pdc_pata_port_start(struct ata_port *ap)
{
struct device *dev = ap-host-dev;
struct pdc_port_priv *pp;
@@ -358,15 +374,14 @@ static int pdc_common_port_start(struct ata_port *ap)
static int pdc_sata_port_start(struct ata_port *ap)
{
- struct pdc_host_priv *hp = ap-host-private_data;
int rc;
- rc = pdc_common_port_start(ap);
+ rc = pdc_pata_port_start(ap);
NAK this rename. It's conceptually wrong to unconditionally
invoke a PATA operation from a SATA operation. The old name
made it clear that that operation was common for all types
of ports.
The rest looks good, but I'll have to take a closer look
to verify the details.
/Mikael
-
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#upstream] sata_promise: fix error decode regression
On Mon, 09 Apr 2007 16:52:53 +0900, Tejun Heo wrote: Mikael Pettersson wrote: Promise ATA ports should always be reset by pdc_reset_port() when errors are detected, but the recent error reason decoding update to sata_promise replaced that reset with a freeze. This patch changes the error detection to do a reset again. This makes the error decoding update safer, as it now only adds error decoding without changing any other behaviour. Signed-off-by: Mikael Pettersson [EMAIL PROTECTED] Not necessarily NAK'ing but I think it's better to do things like that in EH thread not in the interrupt handler. Isn't freezing enough in the interrupt handler? You're right that the reset should be in the EH code. But it isn't right now (the resets done there are generic ones, not the Promise-specific one the HW really wants), so the error decoding change caused a regression that needs to be fixed. I intend to change the interrupt handler to just freeze and add a Promise-specific reset to EH in a separate patch. /Mikael - 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_promise ata exceptions (2.6.20.6)
On Sat, 07 Apr 2007 16:41:04 -0700, Phil Dibowitz wrote: I've recently moved to a Promise Sata controller with two SATA drives in a RAID1 mirror. But I get lots of ata exceptions and the kernel eventually slows down my drive to UDMA/33. It usually happens on ata1 (sda), but sometimes it'll kick in on ata2 (sdb). I can definitely cause this to happen more by increasing load on the disks. But even low load (checking email) causes this. Full hardware and software specs are below, but first, the errors: ata1.00: exception Emask 0x10 SAct 0x0 SErr 0x180100 action 0x2 ata1.00: cmd c8/00:d0:8a:31:ae/00:00:00:00:00/e0 tag 0 cdb 0x0 data 106496 in res 51/0c:0f:4b:32:ae/00:00:00:00:00/e0 Emask 0x10 (ATA bus error) ata1: soft resetting port ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: configured for UDMA/133 ata1: EH complete SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA ... Kernel: 2.6.20.6 (PREEMT SMP) SATA Controller: 02:04.0 RAID bus controller: Promise Technology, Inc. PDC20378 (FastTrak 378/SATA 378) (rev 02) Subsystem: ASUSTeK Computer Inc. K8V Deluxe/PC-DL Deluxe motherboard Flags: bus master, 66MHz, medium devsel, latency 96, IRQ 16 I/O ports at df00 [size=64] I/O ports at dfa0 [size=16] I/O ports at dc00 [size=128] Memory at feafe000 (32-bit, non-prefetchable) [size=4K] Memory at feac (32-bit, non-prefetchable) [size=128K] Capabilities: [60] Power Management version 2 Drives: 2 x Western Digital WD1600JS-00N I've seen reports of issues like these with second-generation Promise SATA chips and SATAII (3Gbps) drives, but this is the first time I've seen any issues with a first-generation chip. 1. Please try 2.6.21-rc6 plus the following two patches: http://user.it.uu.se/~mikpe/linux/patches/2.6/patch-sata_promise-1-separate-sata-pata-ops-2.6.21-rc6 http://user.it.uu.se/~mikpe/linux/patches/2.6/patch-sata_promise-2-error_intr-2.6.21-rc6 This probably won't eliminate the errors, but should improve the level of detail in the error messages. 2. Try with a better power supply and verify that cooling is OK. Also verify that the SATA data and power cables are firmly attached. We've seen several reports of mysterious issues that eventually were traced to insufficient power supplies or poorly seated PCI cards (but in your case the chip is integrated on the mobo). /Mikael - 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#upstream] sata_promise: fix error decode regression
Promise ATA ports should always be reset by pdc_reset_port()
when errors are detected, but the recent error reason decoding
update to sata_promise replaced that reset with a freeze.
This patch changes the error detection to do a reset again.
This makes the error decoding update safer, as it now only
adds error decoding without changing any other behaviour.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
---
drivers/ata/sata_promise.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
--- linux-2.6.21-rc6+upstream/drivers/ata/sata_promise.c.~1~2007-04-06
19:40:01.0 +0200
+++ linux-2.6.21-rc6+upstream/drivers/ata/sata_promise.c2007-04-06
19:45:33.0 +0200
@@ -45,7 +45,7 @@
#include sata_promise.h
#define DRV_NAME sata_promise
-#define DRV_VERSION2.04
+#define DRV_VERSION2.05
enum {
@@ -650,9 +650,12 @@ static void pdc_error_intr(struct ata_po
| PDC_PCI_SYS_ERR | PDC1_PCI_PARITY_ERR))
ac_err_mask |= AC_ERR_HOST_BUS;
- ehi-action |= ATA_EH_SOFTRESET;
+ if (sata_scr_valid(ap))
+ ehi-serror |= pdc_sata_scr_read(ap, SCR_ERROR);
+
qc-err_mask |= ac_err_mask;
- ata_port_freeze(ap);
+
+ pdc_reset_port(ap);
}
static inline unsigned int pdc_host_intr( struct ata_port *ap,
-
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 2.6.22] Add LED trigger to libata core
On Mon, 19 Mar 2007 12:46:16 +, Alan Cox wrote: This duplicates the IDE core LED trigger in the libata core. I plan to use this by allowing PMU LED control on G5 towers. My test platform is a PowerMac 7,3 (Dual G5 2.0GHz, June 2004) with a K2 (sata_svw) controller. I think this fits better in libata-core.c::ata_qc_issue(). Can you move it to there? Gak. I'd rather it stayed out of ata_qc_issue() which is a critical path for performance. Our command issu is already too heavy and not all controllers have queueing to absorb that. How many controllers actually need this hook and can we not have ata_qc_issue_with_led() helpers for them ? Agreed, toggling a led for each request seems excessive. At least Promise controllers tend to have a HW-driven activity led header, so wouldn't need SW-triggered activity leds except maybe if some stupid system failed to wire up the led header. /Mikael - 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#upstream 1/2] sata_promise: add missing cable_detect hooks
The recent change which moved cable detection from
pdc_pre_reset() to the new -cable_detect hook only
added the hook for SATAII chips, leaving SATAI chips
and the 20619 without the hook. Fixed by this patch.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
---
drivers/ata/sata_promise.c |4 +++-
1 files changed, 3 insertions(+), 1 deletion(-)
--- linux-2.6.21-rc3/drivers/ata/sata_promise.c.~1~ 2007-03-11
18:44:04.0 +0100
+++ linux-2.6.21-rc3/drivers/ata/sata_promise.c 2007-03-11 18:44:56.0
+0100
@@ -45,7 +45,7 @@
#include sata_promise.h
#define DRV_NAME sata_promise
-#define DRV_VERSION2.01
+#define DRV_VERSION2.02
enum {
@@ -194,6 +194,7 @@ static const struct ata_port_operations
.thaw = pdc_thaw,
.error_handler = pdc_error_handler,
.post_internal_cmd = pdc_post_internal_cmd,
+ .cable_detect = pdc_cable_detect,
.data_xfer = ata_data_xfer,
.irq_handler= pdc_interrupt,
.irq_clear = pdc_irq_clear,
@@ -220,6 +221,7 @@ static const struct ata_port_operations
.thaw = pdc_thaw,
.error_handler = pdc_error_handler,
.post_internal_cmd = pdc_post_internal_cmd,
+ .cable_detect = pdc_cable_detect,
.data_xfer = ata_data_xfer,
.irq_handler= pdc_interrupt,
.irq_clear = pdc_irq_clear,
-
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#upstream 2/2] sata_promise: separate SATA and PATA ops
This patch changes sata_promise so that the PATA ports
on TX2plus chips are bound to the pdc_pata_ops structure.
This means that operations called from the SATA ops
structures don't need any SATA-vs-PATA tests any more.
Instead, operations that depend on a port being SATA or
PATA are separated into different procedures.
* pdc_cable_type() is split into a PATA version and a
SATA version
* pdc_error_handler() is split into a PATA version and a
SATA version, that both call a common version after
setting up the `hardreset' function pointer
* pdc_old_check_atapi_dma() is now only used for SATAI
ports, so is renamed to pdc_old_sata_check_atapi_dma()
and simplified
* pdc_sata_scr_{read,write}() are now only used for SATA
ports, so their is-not-SATA tests are removed
* pdc_port_start() is split into three procedures: a wrapper
which performs the -ops adjustment on TX2plus PATA ports,
a procedure with the common code, and a procedure with
the SATA-specific code (this bit might be cleaned up by
Tejun's new init model)
Tested on 20619, 20575, and 20775 chips.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
---
drivers/ata/sata_promise.c | 107 +++--
1 files changed, 66 insertions(+), 41 deletions(-)
--- linux-2.6.21-rc3+upstream/drivers/ata/sata_promise.c.~1~2007-03-11
20:54:10.0 +0100
+++ linux-2.6.21-rc3+upstream/drivers/ata/sata_promise.c2007-03-11
20:54:27.0 +0100
@@ -45,7 +45,7 @@
#include sata_promise.h
#define DRV_NAME sata_promise
-#define DRV_VERSION2.02
+#define DRV_VERSION2.03
enum {
@@ -124,14 +124,16 @@ static void pdc_qc_prep(struct ata_queue
static void pdc_tf_load_mmio(struct ata_port *ap, const struct ata_taskfile
*tf);
static void pdc_exec_command_mmio(struct ata_port *ap, const struct
ata_taskfile *tf);
static int pdc_check_atapi_dma(struct ata_queued_cmd *qc);
-static int pdc_old_check_atapi_dma(struct ata_queued_cmd *qc);
+static int pdc_old_sata_check_atapi_dma(struct ata_queued_cmd *qc);
static void pdc_irq_clear(struct ata_port *ap);
static unsigned int pdc_qc_issue_prot(struct ata_queued_cmd *qc);
static void pdc_freeze(struct ata_port *ap);
static void pdc_thaw(struct ata_port *ap);
-static void pdc_error_handler(struct ata_port *ap);
+static void pdc_pata_error_handler(struct ata_port *ap);
+static void pdc_sata_error_handler(struct ata_port *ap);
static void pdc_post_internal_cmd(struct ata_queued_cmd *qc);
-static int pdc_cable_detect(struct ata_port *ap);
+static int pdc_pata_cable_detect(struct ata_port *ap);
+static int pdc_sata_cable_detect(struct ata_port *ap);
static struct scsi_host_template pdc_ata_sht = {
.module = THIS_MODULE,
@@ -164,9 +166,9 @@ static const struct ata_port_operations
.qc_issue = pdc_qc_issue_prot,
.freeze = pdc_freeze,
.thaw = pdc_thaw,
- .error_handler = pdc_error_handler,
+ .error_handler = pdc_sata_error_handler,
.post_internal_cmd = pdc_post_internal_cmd,
- .cable_detect = pdc_cable_detect,
+ .cable_detect = pdc_sata_cable_detect,
.data_xfer = ata_data_xfer,
.irq_handler= pdc_interrupt,
.irq_clear = pdc_irq_clear,
@@ -186,15 +188,15 @@ static const struct ata_port_operations
.check_status = ata_check_status,
.exec_command = pdc_exec_command_mmio,
.dev_select = ata_std_dev_select,
- .check_atapi_dma= pdc_old_check_atapi_dma,
+ .check_atapi_dma= pdc_old_sata_check_atapi_dma,
.qc_prep= pdc_qc_prep,
.qc_issue = pdc_qc_issue_prot,
.freeze = pdc_freeze,
.thaw = pdc_thaw,
- .error_handler = pdc_error_handler,
+ .error_handler = pdc_sata_error_handler,
.post_internal_cmd = pdc_post_internal_cmd,
- .cable_detect = pdc_cable_detect,
+ .cable_detect = pdc_sata_cable_detect,
.data_xfer = ata_data_xfer,
.irq_handler= pdc_interrupt,
.irq_clear = pdc_irq_clear,
@@ -219,9 +221,9 @@ static const struct ata_port_operations
.qc_issue = pdc_qc_issue_prot,
.freeze = pdc_freeze,
.thaw = pdc_thaw,
- .error_handler = pdc_error_handler,
+ .error_handler = pdc_pata_error_handler,
.post_internal_cmd = pdc_post_internal_cmd,
- .cable_detect = pdc_cable_detect,
+ .cable_detect = pdc_pata_cable_detect,
.data_xfer = ata_data_xfer,
.irq_handler= pdc_interrupt,
.irq_clear = pdc_irq_clear,
@@ -316,18
[BUG 2.6.21-rc3] libata PATA CDROM detection problems
I tried to convert a machine with an Intel 815EP chipset from IDE to libata. There's a single master disk on the first channel, and a single master CDROM on the second. With kernel 2.6.21-rc3 and the IDE PIIX driver things work fine: Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ICH2: IDE controller at PCI slot :00:1f.1 ICH2: chipset revision 5 ICH2: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:pio Probing IDE interface ide0... hda: IC35L080AVVA07-0, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... hdc: CRD-8320B, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 hda: max request size: 128KiB hda: 160836480 sectors (82348 MB) w/1863KiB Cache, CHS=65535/16/63, UDMA(100) hda: cache flushes supported hda: hda1 hda2 hda3 hda4 hda5 hda6 ... hdc: ATAPI 32X CD-ROM drive, 128kB Cache, DMA Uniform CD-ROM driver Revision: 3.20 But with 2.6.21-rc3 and ata_piix only the disk is detected, and there is a lot of EH activity on the second channel: libata version 2.20 loaded. ... ata_piix :00:1f.1: version 2.10 PCI: Setting latency timer of device :00:1f.1 to 64 ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001f000 irq 14 ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001f008 irq 15 scsi0 : ata_piix ata1.00: ATA-5: IC35L080AVVA07-0, VA4OA52A, max UDMA/100 ata1.00: 160836480 sectors, multi 16: LBA ata1.00: configured for UDMA/100 scsi1 : ata_piix ATA: abnormal status 0x7F on port 0x00010177 ATA: abnormal status 0x7F on port 0x00010177 ata2.00: ATAPI, max MWDMA2 ata2.00: configured for MWDMA2 scsi 0:0:0:0: Direct-Access ATA IC35L080AVVA07-0 VA4O PQ: 0 ANSI: 5 SCSI device sda: 160836480 512-byte hdwr sectors (82348 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sda: 160836480 512-byte hdwr sectors (82348 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sda4 sda5 sda6 sd 0:0:0:0: Attached scsi disk sda ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata2: port is slow to respond, please be patient (Status 0xd0) ata2: soft resetting port ATA: abnormal status 0x7F on port 0x00010177 ATA: abnormal status 0x7F on port 0x00010177 ata2.00: configured for MWDMA2 ata2: EH complete ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata2: port is slow to respond, please be patient (Status 0xd0) ata2: soft resetting port ATA: abnormal status 0x7F on port 0x00010177 ATA: abnormal status 0x7F on port 0x00010177 ata2.00: configured for MWDMA2 ata2: EH complete ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata2: port is slow to respond, please be patient (Status 0xd0) ata2: soft resetting port ATA: abnormal status 0x7F on port 0x00010177 ATA: abnormal status 0x7F on port 0x00010177 ata2.00: configured for MWDMA2 ata2: EH complete ata2.00: limiting speed to MWDMA1:PIO4 ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata2: port is slow to respond, please be patient (Status 0xd0) ata2: soft resetting port ATA: abnormal status 0x7F on port 0x00010177 ATA: abnormal status 0x7F on port 0x00010177 ata2.00: configured for MWDMA1 ata2: EH complete At this point libata gave up on the second channel. With the CDROM connected to the PATA port on a Promise TX2plus, things go a little better: sata_promise :02:02.0: version 2.00 sata_promise PATA port found ata3: SATA max UDMA/133 cmd 0xe081e200 ctl 0xe081e238 bmdma 0x irq 22 ata4: SATA max UDMA/133 cmd 0xe081e280 ctl 0xe081e2b8 bmdma 0x irq 22 ata5: PATA max UDMA/133 cmd 0xe081e300 ctl 0xe081e338 bmdma 0x irq 22 scsi2 : sata_promise ata3: SATA link down (SStatus 0 SControl 300) scsi3 : sata_promise ata4: SATA link down (SStatus 0 SControl 300) scsi4 : sata_promise ATA: abnormal status 0x58 on port 0xe081e31c ATA: abnormal status 0x58 on port 0xe081e31c ATA: abnormal status 0x58 on port 0xe081e31c ATA: abnormal status 0x58 on port 0xe081e31c ATA: abnormal status 0x58 on port 0xe081e31c ata5.00: failed
pata_pdc2027x success on a PowerMac
This is just to let folks know that the 2.6.21-rc3 kernel's pata_pdc2027x works w/o issues with a PDC20269 in an old PowerMac G3 of mine: pata_pdc2027x :00:0e.0: version 0.8 pata_pdc2027x :00:0e.0: PLL input clock 16000 kHz ata1: PATA max UDMA/133 cmd 0xf10197c0 ctl 0xf1019fda bmdma 0xf1019000 irq 24 ata2: PATA max UDMA/133 cmd 0xf10195c0 ctl 0xf1019dda bmdma 0xf1019008 irq 24 scsi1 : pata_pdc2027x ata1.00: ATA-5: IBM-DTLA-307030, TX4OA6AA, max UDMA/100 ata1.00: 60036480 sectors, multi 0: LBA ata1.00: configured for UDMA/100 scsi2 : pata_pdc2027x ATA: abnormal status 0x8 on port 0xf10195df scsi 1:0:0:0: Direct-Access ATA IBM-DTLA-307030 TX4O PQ: 0 ANSI: 5 SCSI device sdb: 60036480 512-byte hdwr sectors (30739 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdb: 60036480 512-byte hdwr sectors (30739 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb: sdb1 sdb2 sdb3 sdb4 sdb5 sdb6 sdb7 sd 1:0:0:0: Attached scsi disk sdb In particular, this confirms that Albert Lee's timing/tuning fixes, which were essential for making the IDE pdc202xx_new driver work on this machine, also work in pata_pdc2027x. /Mikael - 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: [RFT] sata_promise: decode and report error reasons
Tejun,
Tejun Heo writes:
Hello, Mikael.
Mikael Pettersson wrote:
+static void pdc_error_intr(struct ata_port *ap, struct ata_queued_cmd
*qc, u32 port_status)
+{
+ struct pdc_host_priv *hp = ap-host-private_data;
+ struct ata_eh_info *ehi = ap-eh_info;
+ unsigned int err_mask = 0, action = 0;
+ u32 serror;
+
+ ata_ehi_clear_desc(ehi);
+
+ serror = 0;
+ if (sata_scr_valid(ap)) {
+ serror = pdc_sata_scr_read(ap, SCR_ERROR);
+ if (!(hp-flags PDC_FLAG_GEN_II))
+ serror = ~PDC2_SERR_MASK;
+ }
+
+ printk(%s: port_status 0x%08x serror 0x%08x\n, __FUNCTION__,
port_status, serror);
+
+ ata_ehi_push_desc(ehi, port_status 0x%08x, port_status);
+
+ if (serror PDC_SERR_MASK) {
+ err_mask |= AC_ERR_ATA_BUS;
1. It might be that decoding PDC specific bits is unnecessary if it sets
the standard bits correctly. Also, SError bits above bit16 are
diagnostic bits and don't necessarily indicate error condition.
Which SErrror bits are standard?
It is true that some of the SError bits are diagnostic rather than
actual error indicators, as Promise's driver only checks a subset
of them. I'll fix that.
2. PDC_SERR_FIS_TYPE is more close to AC_ERR_HSM.
FIS_TYPE is described as reception of a FIS with a good CRC but
unrecognised type field. I can make it AC_ERR_HSM if that's more
appropriate.
+ ata_ehi_push_desc(ehi, , serror 0x%08x, serror);
+ }
+ if (port_status PDC_DRIVE_ERR)
+ err_mask |= AC_ERR_DEV;
+ if (port_status PDC2_HTO_ERR)
+ err_mask |= AC_ERR_TIMEOUT;
What does HTO mean? Host time out? Until now, AC_ERR_TIMEOUT has been
used to indicate that driver side timeout has expired and I'd like to
keep it that way.
Yes, HTO is host bus timeout which is described as the host bus being
busy more than 256 clock (I guess PCI) cycles for an ATA I/O transfer.
If not AC_ERR_TIMEOUT, then what? AC_ERR_HOST_BUS?
+ if (port_status (PDC_UNDERRUN_ERR | PDC_OVERRUN_ERR |
PDC2_ATA_DMA_CNT_ERR
+ | PDC2_ATA_HBA_ERR))
+ err_mask |= AC_ERR_ATA_BUS;
AC_ERR_ATA_BUS indicates transmission errors on the ATA bus. AC_ERR_HSM
(host state machine/protocol violation), AC_ERR_HOST_BUS (host/PCI BUS
error) or AC_ERR_SYSTEM (other system errors) seems more appropriate for
the above error conditions.
UNDERRUN and OVERRUN occur when DMA S/G byte count differs from what the
device accepts or delivers as checked when the device asserts INTRQ.
I can make them AC_ERR_HSM instead. (HOST_BUS or SYSTEM seem inappropriate.)
ATA_HBA_ERR is any FIS transmission error on SATA interface. AC_ERR_ATA_BUS
seems appropriate for that one.
ATA_DMA_CNT_ERR is when a DMA FIS data size differs from total DMA S/G size.
I think AC_ERR_ATA_BUS is the correct choice for this one too.
I will add more explanatory text to the error bit definitions, and
perhaps also a table-driven error logger (a bit like sata_sil24).
Thanks for the review.
/Mikael
-
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
