[PATCH #upstream 2/2] libata: no need to speed down if already at PIO0
After reset, transfer mode is always PIO0 regardless of
dev->xfer_mask. Check dev->pio_mode before trying to slow down after
configuration failure. This prevents bogus speed down before device
is actually configured.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: Alan Cox <[EMAIL PROTECTED]>
---
drivers/ata/libata-eh.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: work/drivers/ata/libata-eh.c
===
--- work.orig/drivers/ata/libata-eh.c
+++ work/drivers/ata/libata-eh.c
@@ -2437,7 +2437,7 @@ static int ata_eh_handle_dev_fail(struct
/* give it just one more chance */
ehc->tries[dev->devno] = min(ehc->tries[dev->devno], 1);
case -EIO:
- if (ehc->tries[dev->devno] == 1) {
+ if (ehc->tries[dev->devno] == 1 && dev->pio_mode > XFER_PIO_0) {
/* This is the last chance, better to slow
* down than lose 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
[PATCH #upstream 1/2] libata: relocate forcing PIO0 on reset
Forcing PIO0 on reset was done inside ata_bus_softreset(), which is a
bit out of place as it should be applied to all resets - hard, soft
and implementation which don't use ata_bus_softreset(). Relocate it
such that...
* For new EH, it's done in ata_eh_reset() before calling prereset.
* For old EH, it's done before calling ap->ops->phy_reset() in
ata_bus_probe().
This makes PIO0 forced after all resets. Another difference is that
reset itself is done after PIO0 is forced.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: Alan Cox <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c | 46 +++---
drivers/ata/libata-eh.c | 19 +++
2 files changed, 38 insertions(+), 27 deletions(-)
Index: work/drivers/ata/libata-core.c
===
--- work.orig/drivers/ata/libata-core.c
+++ work/drivers/ata/libata-core.c
@@ -2219,6 +2219,25 @@ int ata_bus_probe(struct ata_port *ap)
tries[dev->devno] = ATA_PROBE_MAX_TRIES;
retry:
+ ata_link_for_each_dev(dev, &ap->link) {
+ /* If we issue an SRST then an ATA drive (not ATAPI)
+* may change configuration and be in PIO0 timing. If
+* we do a hard reset (or are coming from power on)
+* this is true for ATA or ATAPI. Until we've set a
+* suitable controller mode we should not touch the
+* bus as we may be talking too fast.
+*/
+ dev->pio_mode = XFER_PIO_0;
+
+ /* If the controller has a pio mode setup function
+* then use it to set the chipset to rights. Don't
+* touch the DMA setup as that will be dealt with when
+* configuring devices.
+*/
+ if (ap->ops->set_piomode)
+ ap->ops->set_piomode(ap, dev);
+ }
+
/* reset and determine device classes */
ap->ops->phy_reset(ap);
@@ -2234,12 +2253,6 @@ int ata_bus_probe(struct ata_port *ap)
ata_port_probe(ap);
- /* after the reset the device state is PIO 0 and the controller
- state is undefined. Record the mode */
-
- ata_link_for_each_dev(dev, &ap->link)
- dev->pio_mode = XFER_PIO_0;
-
/* read IDENTIFY page and configure devices. We have to do the identify
specific sequence bass-ackwards so that PDIAG- is released by
the slave device */
@@ -3272,8 +3285,6 @@ static int ata_bus_softreset(struct ata_
unsigned long deadline)
{
struct ata_ioports *ioaddr = &ap->ioaddr;
- struct ata_device *dev;
- int i = 0;
DPRINTK("ata%u: bus reset via SRST\n", ap->print_id);
@@ -3284,25 +3295,6 @@ static int ata_bus_softreset(struct ata_
udelay(20); /* FIXME: flush */
iowrite8(ap->ctl, ioaddr->ctl_addr);
- /* If we issued an SRST then an ATA drive (not ATAPI)
-* may have changed configuration and be in PIO0 timing. If
-* we did a hard reset (or are coming from power on) this is
-* true for ATA or ATAPI. Until we've set a suitable controller
-* mode we should not touch the bus as we may be talking too fast.
-*/
-
- ata_link_for_each_dev(dev, &ap->link)
- dev->pio_mode = XFER_PIO_0;
-
- /* If the controller has a pio mode setup function then use
- it to set the chipset to rights. Don't touch the DMA setup
- as that will be dealt with when revalidating */
- if (ap->ops->set_piomode) {
- ata_link_for_each_dev(dev, &ap->link)
- if (devmask & (1 << i++))
- ap->ops->set_piomode(ap, dev);
- }
-
/* wait a while before checking status */
ata_wait_after_reset(ap, deadline);
Index: work/drivers/ata/libata-eh.c
===
--- work.orig/drivers/ata/libata-eh.c
+++ work/drivers/ata/libata-eh.c
@@ -2083,6 +2083,25 @@ int ata_eh_reset(struct ata_link *link,
ata_eh_about_to_do(link, NULL, ehc->i.action & ATA_EH_RESET_MASK);
+ ata_link_for_each_dev(dev, link) {
+ /* If we issue an SRST then an ATA drive (not ATAPI)
+* may change configuration and be in PIO0 timing. If
+* we do a hard reset (or are coming from power on)
+* this is true for ATA or ATAPI. Until we've set a
+* suitable controller mode we should not touch the
+* bus as we may be talking too fast.
+*/
+ dev->pio_mode = XFER_PIO_0;
+
+ /* If the controller has a pio mode setup function
+* then use it to set the chipset to rights. Don't
+* touch the DMA setup as that will be dealt with when
+* configuring devices.
+
Re: blacklisting ST3500630AS as not able to do NCQ
diego torres wrote: > Hi there, > > This seagate drive ST3500630AS is being recognized as NCQ capable by > hdparm, and has the default queue_depth of 31, so i think it should > work ok. But there are some problems when using smartmontools (for > example in short test mode) as seen in dmesg: > > ata2.00: exception Emask 0x2 SAct 0x9 SErr 0x0 action 0x2 frozen > ata2.00: (spurious completions during NCQ issue=0x0 SAct=0x9 > FIS=004040a1:0004) > ata2.00: cmd 61/08:00:f4:28:4e/00:00:00:00:00/40 tag 0 cdb 0x0 data 4096 out > res 40/00:00:f4:28:4e/00:00:00:00:00/40 Emask 0x2 (HSM violation) > ata2.00: cmd 61/08:18:dc:c8:d7/00:00:00:00:00/40 tag 3 cdb 0x0 data 4096 out > res 40/00:00:f4:28:4e/00:00:00:00:00/40 Emask 0x2 (HSM violation) > ata2: soft resetting port > ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > ata2.00: configured for UDMA/133 > ata2: EH complete > sd 1:0:0:0: [sdb] 976773168 512-byte hardware sectors (500108 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 > > All this problems dissapear when setting queue_depth to 1. > > After cheking the seagate website, there is no mention to NCQ in the > spec sheet of this drive, although there are models tagged as using > NCQ interface, for example ST3500620AS How reproducible is the problem? -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5]: [PCI]: Remove 3 incorrect MSI quirks.
Shane Huang wrote: >> I would like those to be removed, but to be conservative we should >> first get some testing feedback that confirms this just like those >> provided to me from the AMD folks for the RS690, RX790 and RD580 >> cases. >> >> Otherwise the risk to break people's systems is very real. > > In fact, our team only has boards with RS690+SB700 and RX790+SB700, > I don't know why the RD580 MSI is disabled too by the patch > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi > t;h=aea6a433f50cd89b9cbd10850fd0b32f961f9883 > Maybe Tejun can give us more information on this case, > I think the cause should be same as RS690 and RX790. I don't remember history of each quirk entry but they're either reported in a bug report and successfully worked around with pci=nomsi or one of AMD guys told me certain PCI IDs share the same problem. I can dig mail archive if you wanna know how it went down for RD580. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: western digital WD1500ADFD: spurious completions during NCQ
Jeff Garrett wrote: > Several threads that suggest this message is related to poor NCQ > support, but I did not see any for this drive. It's a Western Digital > WD1500ADFD-00NLR1. Is this the same thing, and should this drive be > blacklisted? How reproducible is the problem? -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 5/5]: [PCI]: Remove 3 incorrect MSI quirks.
> I would like those to be removed, but to be conservative we should > first get some testing feedback that confirms this just like those > provided to me from the AMD folks for the RS690, RX790 and RD580 > cases. > > Otherwise the risk to break people's systems is very real. In fact, our team only has boards with RS690+SB700 and RX790+SB700, I don't know why the RD580 MSI is disabled too by the patch http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi t;h=aea6a433f50cd89b9cbd10850fd0b32f961f9883 Maybe Tejun can give us more information on this case, I think the cause should be same as RS690 and RX790. If you need some small test on USB issue related with RS480 or something else, you may tell me, I can try to ask the help from our SW QA or test by myself, if we can find out such test platform. Thanks Shane - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] sata_inic162x: finally, driver for initio 162x SATA controllers
Jo Lodewyckx wrote: > Tejun Heo, > > Here's the output of lspci -nnvvv: > > 03:00.0 SATA controller [0106]: Initio Corporation Unknown device > [1101:1622] (rev 02) (prog-if 00 [Vendor specific]) >Subsystem: Initio Corporation Unknown device [1101:1626] >Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- >Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Interrupt: pin A routed to IRQ 10 >Region 0: I/O ports at 4000 [size=256] >Region 1: Memory at 4000 (32-bit, non-prefetchable) [size=4K] >[virtual] Expansion ROM at 3000 [disabled] [size=128K] >Capabilities: [dc] 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- Thanks, please also post the result of "cat /proc/ioports" and "cat /proc/iomem". -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re-enabling Serial ATA ports possible?
Marcin Juszkiewicz wrote:
> This time it worked (log below). Should I check power supply and replace
> it if needed?
>
> [ 6760.345046] ata6: exception Emask 0x10 SAct 0x0 SErr 0x9 action 0xb
> [ 6760.345053] ata6: SError: { PHYRdyChg 10B8B }
Okay, this is PHYRDY changed w/o any command pending. Things like this
happening autonomously indicates something is off with your hardware. I
can't tell which. It could be PSU, the controller or the drive itself.
The only way to find out is trying different hardware configurations
and examining how the symptom changes. ie. connecting the drive to
another port or controller, trying different power supply, etc...
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH]ata: sata_nv fix mcp51 timeout with SWNCQ
Bartlomiej Zolnierkiewicz wrote: > PS Please always at least Cc: people involved in the debugging > of the problem (crediting them in the patch description would be > even nicer :). I apology for forgetting adding all the involved people into Cc. Thank all of you for your efforts. --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc1, sata_sil: access to SH-S183A broken again?
Harri wrote:
> Hi Tejun,
>
> Is it possible that the DMA workaround for sata_sil and the
> Samsung SH-S183A DVD writer was lost for 2.6.24-rc1? I found
No, I don't think we ever had workaround for sata_sil + SH-S183A
combination. Do you have any specific patch/commit in mind?
> this in syslog:
[--snip--]
> Oct 28 11:29:26 pluto kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr
> 0x0 action 0x2 frozen
> Oct 28 11:29:26 pluto kernel: ata4.00: cmd
> a0/01:00:00:10:00/00:00:00:00:00/a0 tag 0 cdb 0xa4 data 16 in
> Oct 28 11:29:26 pluto kernel: res
> 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
> Oct 28 11:29:26 pluto kernel: ata4.00: status: { DRDY }
> Oct 28 11:29:27 pluto kernel: ata4: soft resetting link
> Oct 28 11:29:32 pluto kernel: ata4: port is slow to respond, please be
> patient (Status 0xf8)
> Oct 28 11:29:37 pluto kernel: ata4: SRST failed (errno=-16)
> Oct 28 11:29:37 pluto kernel: ata4: hard resetting link
> Oct 28 11:29:37 pluto kernel: ata4: SATA link up 1.5 Gbps (SStatus 113
> SControl 310)
> Oct 28 11:29:38 pluto kernel: ata4.00: configured for UDMA/33
> Oct 28 11:29:38 pluto kernel: ata4: EH complete
> Oct 28 11:29:38 pluto kernel: sr0: disc change detected.
>
> Its difficult to reproduce, though.
The failing command is REPORT_KEY. What were you doing when you saw
this error?
Not being reproducible indicates that it's unlikely to be a DMA issue
and more likely a temporary glitch in media recognition.
Thanks.
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5]: [PCI]: Remove 3 incorrect MSI quirks.
From: "David Gaarenstroom" <[EMAIL PROTECTED]> Date: Sun, 28 Oct 2007 21:11:13 +0100 > > I would like those to be removed, but to be conservative we should > > first get some testing feedback that confirms this just like those > > provided to me from the AMD folks for the RS690, RX790 and RD580 > > cases. > > The patch works fine for my laptop with the RS480 chipset (with a > SB400 southbridge). > But it would be nice if AMD tested it as well... So please submit "The patch" :-) - 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 3/4] scsi: expose AN support to user space
On Thu, 2007-10-25 at 03:15 -0400, Jeff Garzik wrote:
> [EMAIL PROTECTED] wrote:
> > From: Kristen Carlson Accardi <[EMAIL PROTECTED]>
> >
> > If a scsi_device supports async notification for media change, then let user
> > space know this capability exists by creating a new sysfs entry
> > "media_change_notify", which will be 1 if it is supported, and 0 if not
> > supported. Create a routine which allows scsi devices to send a uevent when
> > media change events occur.
> >
> > Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
> > Acked-by: Jeff Garzik <[EMAIL PROTECTED]>
> > Cc: Tejun Heo <[EMAIL PROTECTED]>
> > Cc: James Bottomley <[EMAIL PROTECTED]>
> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> > ---
> >
> > drivers/scsi/scsi_lib.c| 83 +++
> > drivers/scsi/scsi_scan.c |1
> > drivers/scsi/scsi_sysfs.c | 13 +
> > include/scsi/scsi_device.h | 15 +-
> > 4 files changed, 111 insertions(+), 1 deletion(-)
>
> committed to libata-dev.git#an as the attached patch
>
> I changed the interface such that it takes a mask of events. We only
> have one event right now, but it is now trivial to add more events
> within the same interface.
This is getting towards exactly where I think it needs to be. There
does still need to be a few updates to this. Firstly, I think this
bitmap might grow very big (especially if we start distinguishing the
cc/ua events, so it might be wise to have bitmap for this (it collapses
down to an architectural long anyway until we get above 32 on a 32 bit
platform).
Secondly, the way the events are exposed an manipulated needs to change.
I think the sysfs group attribute interface is almost the exactly
correct thing for this, except that not all events are supported by all
devices, so if the device doesn't support it, the corresponding event
file shouldn't appear). I think this really means extending the current
attribute group infrastructure to include the concept of a filtered
attribute group (where you can specify the group to show with a bitmap
or something). The ulterior motive for this is that not only will it
simplify requesting and showing supported events, it will also allow me
to trash a lot of the crap in all of the transport classes which do
essentially the same thing.
> plain text document attachment (patch)
> commit 4e0af19e75e40d71181c4e515009e81f19a0fc04
> Author: Jeff Garzik <[EMAIL PROTECTED]>
> Date: Thu Oct 25 03:13:46 2007 -0400
>
> [SCSI] Emit asynchronous media events
>
> Based originally on a patch by
> Kristen Carlson Accardi <[EMAIL PROTECTED]>
>
> Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
>
> drivers/scsi/scsi_lib.c| 58
> +
> drivers/scsi/scsi_sysfs.c | 13 ++
> include/scsi/scsi_device.h | 13 +-
> 3 files changed, 83 insertions(+), 1 deletion(-)
>
> 4e0af19e75e40d71181c4e515009e81f19a0fc04
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 61fdaf0..46a7f50 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -2115,6 +2115,64 @@ scsi_device_set_state(struct scsi_device *sdev, enum
> scsi_device_state state)
> EXPORT_SYMBOL(scsi_device_set_state);
>
> /**
> + * scsi_device_event_notify_thread - send a uevent for each scsi event
> + * @work: work struct for scsi_device
> + *
> + * Emit all queued media events as environment variables
> + * sent during a uevent.
> + */
> +static void scsi_event_notify_thread(struct work_struct *work)
> +{
> + struct scsi_device *sdev;
> + char *envp[3];
> + unsigned long flags, mask;
> + int i, idx;
> +
> + /* must match scsi_device_event enum in scsi_device.h */
> + static char *scsi_device_event_strings[] = {
> + [SDEV_MEDIA_CHANGE] = "SDEV_MEDIA_CHANGE=1",
> + };
> +
> + sdev = container_of(work, struct scsi_device, ew.work);
> +
> + spin_lock_irqsave(&sdev->list_lock, flags);
> + mask = sdev->event_mask;
> + sdev->event_mask = 0;
> + spin_unlock_irqrestore(&sdev->list_lock, flags);
> +
> + idx = 0;
> + for (i = 0; i < SDEV_MEDIA_LAST; i++)
> + if (mask & (1UL << i))
> + envp[idx++] = scsi_device_event_strings[i];
> + envp[idx++] = NULL;
> +
> + kobject_uevent_env(&sdev->sdev_gendev.kobj, KOBJ_CHANGE, envp);
I already changed this to a case statement in a prior patch. I know we
need this because the cc/ua events will have to carry the asc/ascq and
possibly other information in the environment, so a simple one string
identifying the event doesn't cut it.
> +}
> +
> +/**
> + * scsi_device_event_notify - store event info and send an event
> + * @sdev: scsi_device event occurred on
> + * @mask: the scsi device event mask
> + *
> + * Store the event information and then switch process context
> + * so that the event may be sent to user space.
> + * This may b
Re: [2.6.23-rc3] Regression: "spurious completions during NCQ"
On Wed, Oct 24, 2007 at 06:18:20AM -0400, Tejun Heo wrote: > Please post dmesg including full boot log and error messages and the result > of 'hdparm -I /dev/sdX' where sdX are drives which cause such errors. Attached. The other disks (sda, sdb, sdd) have the same information, but different serial numbers of course. Thanks for your time, -- Carsten Otto [EMAIL PROTECTED] www.c-otto.de Linux version 2.6.23.1 ([EMAIL PROTECTED]) (gcc version 4.2.1 (Debian 4.2.1-3)) #1 SMP Sun Oct 28 14:21:11 CET 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e4000 - 0010 (reserved) BIOS-e820: 0010 - e7f8 (usable) BIOS-e820: e7f8 - e7f8e000 (ACPI data) BIOS-e820: e7f8e000 - e7fe (ACPI NVS) BIOS-e820: e7fe - e800 (reserved) BIOS-e820: ffb0 - 0001 (reserved) 2815MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000ff780 NX (Execute Disable) protection: active Entering add_active_range(0, 0, 950144) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 229376 HighMem229376 -> 950144 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -> 950144 On node 0 totalpages: 950144 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 1760 pages used for memmap Normal zone: 223520 pages, LIFO batch:31 HighMem zone: 5631 pages used for memmap HighMem zone: 715137 pages, LIFO batch:31 Movable zone: 0 pages used for memmap DMI 2.3 present. Using APIC driver default ACPI: RSDP 000FA960, 0024 (r2 ACPIAM) ACPI: XSDT E7F80100, 0044 (r1 A M I OEMXSDT 3000620 MSFT 97) ACPI: FACP E7F80290, 00F4 (r3 A M I OEMFACP 3000620 MSFT 97) ACPI: DSDT E7F80400, 81D2 (r1 A0228 A02280000 INTL 2002026) ACPI: FACS E7F8E000, 0040 ACPI: APIC E7F80390, 0070 (r1 A M I OEMAPIC 3000620 MSFT 97) ACPI: OEMB E7F8E040, 0066 (r1 A M I AMI_OEM 3000620 MSFT 97) ACPI: MCFG E7F885E0, 003C (r1 A M I OEMMCFG 3000620 MSFT 97) ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 15:4 APIC version 20 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 15:4 APIC version 20 ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at ea00 (gap: e800:17b0) Built 1 zonelists in Zone order. Total pages: 942721 Kernel command line: root=/dev/md2 mapped APIC to b000 (fee0) mapped IOAPIC to a000 (fec0) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 4096 (order: 12, 16384 bytes) Detected 2676.295 MHz processor. Console: colour VGA+ 80x25 console [tty0] enabled Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 3762432k/3800576k available (3695k kernel code, 36968k reserved, 1723k data, 240k init, 2883072k highmem) virtual kernel memory layout: fixmap : 0xfff9a000 - 0xf000 ( 404 kB) pkmap : 0xffc0 - 0xffe0 (2048 kB) vmalloc : 0xf880 - 0xffbfe000 ( 115 MB) lowmem : 0xc000 - 0xf800 ( 896 MB) .init : 0xc0654000 - 0xc069 ( 240 kB) .data : 0xc049bd04 - 0xc064aa54 (1723 kB) .text : 0xc010 - 0xc049bd04 (3695 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 5357.76 BogoMIPS (lpj=10715521) Mount-cache hash table entries: 512 CPU: After generic identify, caps: bfebfbff 2010 651d 0001 monitor/mwait feature present. using mwait in idle threads. CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 1024K CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 CPU: After all inits, caps: bfebfbff 2010 b180 651d 0001 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU0: Intel P4/Xeon Extended MCE MSRs (24) available CPU0: Thermal monitoring enabled Compat vDSO mapped to e000. Checking 'hlt' instruction... OK. SMP altern
Re: IDE Problem with old Gateway laptop (1998 solo 2300)
On Fri, 2007-10-26 at 11:21 +0100, Declan Moriarty wrote: > > > This laptop currently has > > > hda1 - windows 2000 2 Gigs > > > hda4 - linux system 1 Gig > > > > > > The linux system uses kernel-2.6.22.6, uClibc-0.9.29 & gcc-4.1.2, and > > > was compiled on a box here with a uname hack, as the laptop has a > > > pentium-233 only. Then it was copied on with a usb stick (which the bios > > > won't boot from, of course) I do have floppy, but no networking or > > > cdrom. Booting is currently from a grub floppy. > > > > > > The kernel on hda4 boots, finds things and gets this far > > > > If hda drive is found and configured correctly this is most likely > > not an IDE problem (user-space compiled for CPU newer than i586? > > configuration problem?) but can't tell for sure. > > I did use a uname hack, so the last kernel tried was compiled for i486 > with all chipset bugfix code. > > > > > kjournald starting. Commit interval 5 seconds > > > EXT3-fs: mounted filesystem with ordered data mode > > > VFS: mounted root (ext3 filesystem) readonly > > > Freeing unused kernel memory: freed > > > > IDE kernel messages would be far more useful... > > > > PS Please cc: linux-ide@vger.kernel.org mailing list on IDE problems so > >the mail reaches more knowledgeable people who may be able to help. > > > But I never get to this > > > > > > EXT3 FS on hda4, internal journal > > > > > > which is the next line on a good boot. Instead the kernel folds it's > > > arms, the disk goes quiet, no error shows, and everything sits back. USB > > > devices will register & deregister, but booting stops and even > > > init=/bin/bash won't happen > > > > > > I have tried several kernels. The chipset, btw is the Intel 82371 > > > Southbridge and Intel 82439 Northbridge. The hard disk is 6282/16/63 or > > > 721/128/63, but if I try the old driver with lba & large disk access, it > > > also reads and boots the kernel (Up above cylinder 4000), and then > > > complains (At the same point as the others) that it can only handle 16 > > > heads, and we appear to have 128! Disable lba & large disk access for > > > the old driver, (There's real health warnings on that!) and the old > > > driver behaves in an identical fashion to the new. > > > This makes me think grub is handing over to the kernel driver, but I > > > just don't know. > > > We're on 'fast PIO 4' because any faster settings (3 weirdo dma options) > > > seem to barf > > OK, IDE messages: (transcribed) > > Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 > ide: Assuning 33Mhz system bus speed for PIO modes; override with > idebus=xx > PIIX4: IDE controller at PCU slot :00:[EMAIL PROTECTED] > PIIX4: chipset revision 1 > PIIX4: not 100% native, will probe irqs later > ide0: BM-DMA at 0xfcd0-0xfcd7, BIOS settings: hda:pio, hda:pio > ide1: BM-DMA at 0xfcd8-0xfcdf, BIOS settings: hdc:pio, hdd:pio > hda: HITATCHI_DK226A-32, ATA DISK drive > ide0; at 0x1f0-1f7 on irq 14 > hda: 6332256 sectors (3242MB) w/128KiB Cache CHS=6282/16/63 DMA > hda: hda1, hda4 Let me give you a laugh on this, and you can tell me if anyone can solve it quickly or slowly. I got fed up with this, and dumped windows. I feared that the correct cylinders value was getting through lba to nobble access above 1024 cylinders. So I repartitioned and got the entire thing below the most pessimistic 1024 cylinders; It's all below the 504MB limit. The same thing exactly happens, which would indicate that 1024 cylinder problem was not the cause. I've also lost usb access, because my shiny new system won't boot, and windows has been overwritten. That leaves me curious as hell as to what's going on. -- With Best Regards, Declan Moriarty - 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 5/5]: [PCI]: Remove 3 incorrect MSI quirks.
> I would like those to be removed, but to be conservative we should > first get some testing feedback that confirms this just like those > provided to me from the AMD folks for the RS690, RX790 and RD580 > cases. The patch works fine for my laptop with the RS480 chipset (with a SB400 southbridge). But it would be nice if AMD tested it as well... BTW, here you can see that the SB400 USB controller was the only real problem for the RS480 chipset in the first place: http://lkml.org/lkml/2006/12/21/47 - 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
Jeff Garzik wrote: > > Alan's point was that the existing code will give you up to > LIBATA_MAX_PRD entries. After the post-virtual-merge splitting code in > ata_fill_sg() executes, the worst case result is ATA_MAX_PRD entries. > > Thus, since your code has the potential to increase the number of s/g > entries above that, it can potentially corrupt memory, lock up the > machine, all the wonderful things that can happen when you run off the > end of the s/g list. > > The fix is to decrease .sg_tablesize (LIBATA_MAX_PRD - 2 perhaps?) so > that you guarantee this worst case never occurs, by guaranteeing that > the system never sends you enough s/g entries to cause your code to go > out of bounds. > Ah, now I understand. Thanks for the explanation. I take it something guarantees that s/g entry size can not exceed 128K. -- ./lxnt - 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 5/15] ide: fix registers loading order for WIN_SMART in execute_drive_cmd()
Hello. Bartlomiej Zolnierkiewicz wrote: Fix registers loading order for REQ_TYPE_ATA_CMD request with WIN_SMART command in execute_drive_cmd() (load IDE_FEATURE_REG and IDE_SECTOR_REG before loading IDE_LCYL_REG and IDE_HCYL_REG). It shouldn't affect anything (just a usual paranoia to separate changes which change the way in which hardware is accessed from code cleanups). Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]> MBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AW: Possible NCQ problem with Seagate ST3250620NS/nForce 4
Hi Kuckuck, sorry for the late reply, but I have been on the road the last few days. > Someone from the list mentioned that a bad/weak PSU may be responsible > for the trouble. It was hard for me to believe that this was the case, > since my system only uses 130W at full load and my former 350W PSU had > 170W output power. I am also using very high quality compontents. ASUS A8N-SLI Premium mainboards in both cases (see blelow), SeaSonic PSU 450 W, passively cooled low-end GPU (NVidia 8500GT), no frills, nothing to bring down either power line (5 V or 12 V) of the PSU. However, I am running into the same problems on a different machine with a SAMSUNG SP2504C SATA drive. --- snip --- [ 0.00] Linux version 2.6.22-14-generic ([EMAIL PROTECTED]) (gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)) #1 SMP Sun Oct 14 23:05:12 GMT 2007 (Ubuntu 2.6.22-14.46-generic) ... [ 4.936000] sata_nv :00:08.0: version 3.4 [ 4.936000] sata_nv :00:08.0: Using ADMA mode ... [ 800.196000] ata1: timeout waiting for ADMA IDLE, stat=0x400 [ 800.196000] ata1: timeout waiting for ADMA LEGACY, stat=0x400 [ 800.196000] ata1.00: exception Emask 0x0 SAct 0x7 SErr 0x20 action 0x2 frozen [ 800.196000] ata1.00: cmd 61/00:00:1c:03:3c/04:00:1b:00:00/40 tag 0 cdb 0x0 data 524288 out [ 800.196000] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [ 800.196000] ata1.00: cmd 61/00:08:1c:ff:3b/02:00:1b:00:00/40 tag 1 cdb 0x0 data 262144 out [ 800.196000] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [ 800.196000] ata1.00: cmd 61/00:10:1c:01:3c/02:00:1b:00:00/40 tag 2 cdb 0x0 data 262144 out ... [ 918.972000] ata1: timeout waiting for ADMA IDLE, stat=0x400 [ 918.972000] ata1: timeout waiting for ADMA LEGACY, stat=0x400 [ 918.972000] ata1.00: NCQ disabled due to excessive errors [ 918.972000] ata1.00: exception Emask 0x0 SAct 0x1f SErr 0x0 action 0x2 frozen [ 918.972000] ata1.00: cmd 60/08:00:f4:75:14/00:00:1b:00:00/40 tag 0 cdb 0x0 data 4096 in [ 918.972000] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [ 918.972000] ata1.00: cmd 61/08:08:bc:1e:fe/00:00:1a:00:00/40 tag 1 cdb 0x0 data 4096 out [ 918.972000] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [ 918.972000] ata1.00: cmd 61/40:10:ac:1d:4a/00:00:1a:00:00/40 tag 2 cdb 0x0 data 32768 out [ 918.972000] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ... [ 919.284000] ata1: soft resetting port [ 919.44] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 919.96] ata1.00: configured for UDMA/133 [ 919.96] ata1: EH complete [ 920.056000] sd 0:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB) [ 920.056000] sd 0:0:0:0: [sda] Write Protect is off [ 920.056000] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 920.056000] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA ... and the drive is working again. The common denominator here is: both machines use the NForce4 chipset, both use the sata_nv driver and both are trying to use LVM over dm-crypt. The very same hardware without LVM over dm-crypt runs like a charm. I am of course not sure, but is it possible that there might be a bug when combining sata_nv, NCQ and LVM mapped devices? Can someone else look into this issue? Thanks! Jens - 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
2.6.24-rc1, sata_sil: access to SH-S183A broken again?
Hi Tejun,
Is it possible that the DMA workaround for sata_sil and the
Samsung SH-S183A DVD writer was lost for 2.6.24-rc1? I found
this in syslog:
Oct 28 11:29:08 pluto kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0
action 0x2 frozen
Oct 28 11:29:08 pluto kernel: ata4.00: cmd a0/01:00:00:10:00/00:00:00:00:00/a0
tag 0 cdb 0xa4 data 16 in
Oct 28 11:29:08 pluto kernel: res 40/00:02:00:0c:00/00:00:00:00:00/a0
Emask 0x4 (timeout)
Oct 28 11:29:08 pluto kernel: ata4.00: status: { DRDY }
Oct 28 11:29:08 pluto kernel: ata4: soft resetting link
Oct 28 11:29:13 pluto kernel: ata4: port is slow to respond, please be patient
(Status 0xf8)
Oct 28 11:29:18 pluto kernel: ata4: SRST failed (errno=-16)
Oct 28 11:29:18 pluto kernel: ata4: hard resetting link
Oct 28 11:29:19 pluto kernel: ata4: SATA link up 1.5 Gbps (SStatus 113 SControl
310)
Oct 28 11:29:19 pluto kernel: ata4.00: configured for UDMA/33
Oct 28 11:29:19 pluto kernel: ata4: EH complete
Oct 28 11:29:26 pluto kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0
action 0x2 frozen
Oct 28 11:29:26 pluto kernel: ata4.00: cmd a0/01:00:00:10:00/00:00:00:00:00/a0
tag 0 cdb 0xa4 data 16 in
Oct 28 11:29:26 pluto kernel: res 40/00:02:00:0c:00/00:00:00:00:00/a0
Emask 0x4 (timeout)
Oct 28 11:29:26 pluto kernel: ata4.00: status: { DRDY }
Oct 28 11:29:27 pluto kernel: ata4: soft resetting link
Oct 28 11:29:32 pluto kernel: ata4: port is slow to respond, please be patient
(Status 0xf8)
Oct 28 11:29:37 pluto kernel: ata4: SRST failed (errno=-16)
Oct 28 11:29:37 pluto kernel: ata4: hard resetting link
Oct 28 11:29:37 pluto kernel: ata4: SATA link up 1.5 Gbps (SStatus 113 SControl
310)
Oct 28 11:29:38 pluto kernel: ata4.00: configured for UDMA/33
Oct 28 11:29:38 pluto kernel: ata4: EH complete
Oct 28 11:29:38 pluto kernel: sr0: disc change detected.
Its difficult to reproduce, though.
Regards
Harri
-
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 3/3] sata_inic162x: finally, driver for initio 162x SATA controllers
Tejun Heo, Here's the output of lspci -nnvvv: 03:00.0 SATA controller [0106]: Initio Corporation Unknown device [1101:1622] (rev 02) (prog-if 00 [Vendor specific]) Subsystem: Initio Corporation Unknown device [1101:1626] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Interrupt: pin A routed to IRQ 10 Region 0: I/O ports at 4000 [size=256] Region 1: Memory at 4000 (32-bit, non-prefetchable) [size=4K] [virtual] Expansion ROM at 3000 [disabled] [size=128K] Capabilities: [dc] 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- yours sincerely, Jo Lodewyckx Tejun Heo schreef: Hello, [EMAIL PROTECTED] wrote: When probing the module I did get an error and after some google fun, I stumbled upon you as being the driving force behind this driver. This is the error I'm getting: sata_inic162x :03:00.0: version 0.2 PCI: Enabling device :03:00.0 ( -> 0003) ACPI: PCI Interrupt :03:00.0[A] -> Link [C0C3] -> GSI 10 (level, low) -> IRQ 10 ACPI: PCI interrupt for device :03:00.0 disabled sata_inic162x: probe of :03:00.0 failed with error -22 Some more sysinfo: Linux sip 2.6.22-gentoo-r8 #8 SMP PREEMPT Mon Oct 22 19:49:47 CEST 2007 i686 Intel(R) Pentium(R) M processor 1500MHz GenuineIntel GNU/Linux hopefully you can help me out on this one. I would be glad to act as "alpha/beta tester" for your driver :) 1. Please cc linux-ide@vger.kernel.org and [EMAIL PROTECTED] 2. Post the result of "lspci -nnvvv". 3. Please note that sata_inic162x driver is only in half-working state and virtually useless because it doesn't support LBA48 (drives bigger than 128G). I need more info to fix this problem but the vendor isn't willing and I don't have time to find it out by trial-and-error. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-RFC] Promise TX4 implement hw-bug workaround
Alexander Sabourenkov wrote: 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). Which version is this define from? Both versions that are available now from their website define it at 41*4: Mikael Pettersson wrote: 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 was looking at pdc-ulsata2_1.00.0.15.tgz, which was the latest driver that Promise's website gave me to when I listed "SATA300 TX4" as my product. Sounds like that is outdated information, thanks for the correction! Jeff - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-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
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). > Which version is this define from? Both versions that are available now from their website define it at 41*4: /* for ASIC bug, limit the last element of SG byteCount must <= 41 Dword */ #define SG_COUNT_ASIC_BUG 41*4 //#define SG_COUNT_ASIC_BUG 32 //#define SG_COUNT_ASIC_BUG 128 -- ./lxnt - 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
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... Jeff - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-RFC] Promise SATA300 TX4
Alexander Sabourenkov wrote: Hmm. sata_promise.c says: * Maintained by: Jeff Garzik <[EMAIL PROTECTED]> That should be changed :) I wrote the code but Mikael is now the primary maintainer. Meanwhile I'll check the Promise driver(s) to see if there's something about SG table formatting restrictions there. Take a look at: cam_ata.c:6190 cam_ata.c:6259 The fix is also conditioned on sg segment length == 0, which I did not implement. Is this at all possible in libata ? The block layer should never pass us a scatterlist element of length zero. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-RFC] Promise TX4 implement hw-bug workaround
Alexander Sabourenkov wrote: Alan Cox wrote: 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). This appears to be incomplete: [...] What guarantees you have enough PRD entries to do this without changing the limit in the structures ? Otherwise looks good PRD entries count is 256 include/linux/ata.h: ATA_MAX_PRD = 256, ATA_PRD_TBL_SZ = (ATA_MAX_PRD * ATA_PRD_SZ), drivers/ata/libata-core.c: ap->prd = dmam_alloc_coherent(dev, ATA_PRD_TBL_SZ, &ap->prd_dma, sata_promise Scsi_Host declares support for half of that: include/linux/libata.h: LIBATA_MAX_PRD = ATA_MAX_PRD / 2, drivers/ata/sata_promise.c .sg_tablesize = LIBATA_MAX_PRD, Alan's point was that the existing code will give you up to LIBATA_MAX_PRD entries. After the post-virtual-merge splitting code in ata_fill_sg() executes, the worst case result is ATA_MAX_PRD entries. Thus, since your code has the potential to increase the number of s/g entries above that, it can potentially corrupt memory, lock up the machine, all the wonderful things that can happen when you run off the end of the s/g list. The fix is to decrease .sg_tablesize (LIBATA_MAX_PRD - 2 perhaps?) so that you guarantee this worst case never occurs, by guaranteeing that the system never sends you enough s/g entries to cause your code to go out of bounds. 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
