[PATCH] aktivate sata300 TX4 in sata_promise
Hallo,
this Patch get the Promise SATA300 TX4 card working.
Please accept. Patch is against 2.6.13-rc3-git5.
Signed-off-by: Otto Meier <[EMAIL PROTECTED]>
--- linux/drivers/scsi/sata_promise.c.orig 2005-08-01
17:09:48.474824778 +0200
+++ linux/drivers/scsi/sata_promise.c 2005-07-31 12:57:06.415979512 +0200
@@ -183,6 +183,8 @@ static struct pci_device_id pdc_ata_pci_
board_20319 },
{ PCI_VENDOR_ID_PROMISE, 0x3319, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
board_20319 },
+{ PCI_VENDOR_ID_PROMISE, 0x3d17, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+ board_20319 },
{ PCI_VENDOR_ID_PROMISE, 0x3d18, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
board_20319 },
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ahci, SActive flag, and the HD activity LED
Martin Wilck wrote: Jens Axboe wrote: If I am reading the specs correctly, that'd mean the ahci driver is wrong in setting the SActive bit. I completely agree, that was my reading of the spec as well and hence my original posts about this in the NCQ thread. Have you (or has anybody else) also seen the wrong behavior of the activity LED? I have, Asus P5LD2 i945P, ICH7R AHCI controller, Hitachi Deskstar T7K250 250GB "SATA2" drives. Kernel 2.6.12.x - 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: Lockup when using three or more TX2plus/PDC20375 cards
Welcome to the club. I actually have a PDC20579 with only two ports
and a sata_nv down, and the PDC20579 under md RAID5 stress sometimes
just stops responding entirely. I've talked with Jim Ramsay and tried
his patches, but nothing make the failure go away.
On 8/2/05, Ian Oliver <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am using Ubuntu Hoary with the standard 2.6.10 kernel.
> I have 4x Maxtor SATA cards using the PDC20375 (rebranded Promise
> TX2plus) in PCI slots. Each drive is cabled to 2 SATA HDs and these are
> used as two groups of four for software raid using mdadm. Boot drive is
> a non-raid PATA drive.
>
> When I really hammer the sw raid that's on two of the cards it will
> generate lots of these in the log -
> Jul 25 17:33:42 localhost kernel: ata7: status=0x51 { DriveReady
> SeekComplete Error }
> Jul 25 17:33:42 localhost kernel: ata7: error=0x0c { DriveStatusError }
>
> then I get the following on the console -
> ata7: command timeout
> and then the whole machine locks solid.
>
> I can do whatever I like to the raid on the 1st four cards and it seems
> rock solid.
>
> I hear talk of 3rd and subsequent cards not being initialised by the
> BIOS, and my "lspci -v" results back this up. (Please see
> http://bugzilla.ubuntu.com/show_bug.cgi?id=13046 rather than cluttering
> this list.)
>
> How can I address this problem? I have just built a 2.6.10 kernel and
> modules (very much a first for me) so I think I can apply patches and
> try things out.
>
> Note that I think Ubuntu has some patches from later kernels applied to
> their libata to add pass through, but I don't know the status of the
> sata_promise.
>
> Regards
>
> Ian
>
>
>
> -
> 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 linux-2.6.13-rc3] SATA: rewritten sil24 driver
Greetings, Edward and Jeff.
Jeff, as my previous patchset against sil24 driver hasn't been
accepted yet, and it seems that most of them can be done better with
info from Edward, please ignore the patchset. I'll post a new
patchset tomorrow (hopefully). Sorry about the hassle.
On Wed, Aug 03, 2005 at 12:09:05AM -0400, Jeff Garzik wrote:
> Edward Falk wrote:
> >Hi Tejun; I'm the guy at Google working on SATA drivers (port
> >multipliers right now).
Great.
> > As soon as I can (next week perhaps, I'll start
> >looking at the driver you wrote. From what I can see, it looks quite good.
> >
Thanks a lot. I'll try to make my driver saner by then.
> >
> >
> +
> +static u8 sil24_check_status(struct ata_port *ap)
> +{
> +return ATA_DRDY;
> +}
> +
> +static u8 sil24_check_err(struct ata_port *ap)
> +{
> +return 0;
> +}
> >>>
> >>>
> >>>For these two functions, we need to grab the values for these
> >>>registers from the D2H Register FIS. These should not be constant
> >>>values, they are used in probing.
> >>>
> >>
> >> Sadly I don't know where the values are. The original driver seems
> >>to assume that taskfile registers are overlayed with PORT_PRB, but
> >>they are not. Values are bogus there. Again, in need of hardware
> >>docs here.
> >
> >
> >The original driver is broken. Taskfile registers have to be read back
> >from the returned FIS block after a command completion.
>
> Correct.
>
Ahh.. Thanks a lot. I thought PRB was used just for command issues.
I'll fix the driver ASAP.
>
> >H, perhaps libata should provide an ata_fis_to_tf() function that
> >examines a FIS block, confirms that it's a device-to-host type FIS, and
> >read the taskfile registers back out.
>
> Such as ata_tf_from_fis() in libata-core.c? :)
>
>
> >> The original rewritten sil24 driver against NCQ helpers had simple
> >>status register emulation using normal/error completion interrupt. I
> >>don't know why I stripped that while converting the driver over
> >>vanilla libata (sorry). I'll restore it. It's not good, but it
> >>correctly indicates error on error.
> >
> >
> >It's still better than what we have.
> >
Hmmm.. Now that I know how to access the D2H FIS, I can properly
emulate status and error registers from interrupt handler. I'll
submit a patch soon.
> >
> >
> +static void sil24_phy_reset(struct ata_port *ap)
> +{
> +__sata_phy_reset(ap);
> +/*
> + * No ATAPI yet. Just unconditionally indicate ATA device.
> + * If ATAPI device is attached, it will fail ATA_CMD_ID_ATA
> + * and libata core will ignore the device.
> + */
> +if (!(ap->flags & ATA_FLAG_PORT_DISABLED))
> +ap->device[0].class = ATA_DEV_ATA;
> +}
> >>>
> >>>
> >>>We need to use the standard probing code to figure this out.
> >>>ata_dev_classify(), etc.
> >>>
> >>
> >>
> >> Again, the problem here is that I don't know how to access the
> >>signature values after reset.
> >
> >
> >Again, you would need to fetch them from the returned FIS structure.
>
> Correct.
>
Again, thanks. ;-)
>
> +static void sil24_irq_clear(struct ata_port *ap)
> +{
> +/* unused */
> +}
> >>>
> >>>
> >>>we need to fill this in.
> >
> >
> >I think this will work (adapted from sil_interrupt():
> >
> >static void sil_irq_clear(struct ata_port *ap)
> >{
> >struct sil_port_priv *pp = ap->private_data;
> >struct Port_Registers *port_base = pp->pregs;
> >unsigned long port_int;
> >
> >port_int = readl((void *)&port_base->IntStatus);
> >writel(port_int, &port_base->IntStatus);
> >}
> >
> >I'm assuming that this entry point is expected to clear all interrupts, no?
>
> Correct.
>
I'll verify with the error register clearing part of the original
driver and submit a patch.
>
> +/* Max ~100ms */
> +for (cnt = 0; cnt < 1000; cnt++) {
> +udelay(100);
> +tmp = readl(port + PORT_CTRL_STAT);
> +if (!(tmp & PORT_CS_DEV_RST))
> +break;
> +}
> >>>
> >>>
> >>>Use mdelay. We should be able to sleep here?
> >>>
> >>>Either way, we want to avoid long delays like this.
> >
> >
> >Does mdelay() sleep? I thought it just called udelay().
>
> mdelay() does not sleep.
>
>
> >At any rate, I think 100ms is only the worst-case delay.
> >
> >Is it safe to call msleep() at boot time?
>
> Yes.
>
>
> +/* GPIO off */
> +writel(0, host_base + HOST_FLASH_CMD);
> +
> +/* Mask interrupts during initialization */
> +writel(0, host_base + HOST_CTRL);
> >>>
> >>>
> >>>add a readl() to flush this write out to the PCI bus ("PCI posting")
> >>>
> >>
> >>
> >> Sure. And, out of curiosity, isn't sync unnecessary unless we're
> >>gonna perform some kind of timed waiting following it? We don't have
> >>any timing requirement after above interrupt masking, do we?
> >
> >
> >
> >I think we're ok here;
Re: ahci, SActive flag, and the HD activity LED
On Wed, 2005-08-03 at 07:17 +0200, Martin Wilck wrote: > Jens Axboe wrote: > > >>If I am reading the specs correctly, that'd mean the ahci driver is > >>wrong in setting the SActive bit. > > > > I completely agree, that was my reading of the spec as well and hence my > > original posts about this in the NCQ thread. > > Have you (or has anybody else) also seen the wrong behavior of the > activity LED? Yes, Dell Precision 380, ICH7R AHCI controller, SATA non-NCQ Western Digital drive. Adam signature.asc Description: This is a digitally signed message part
Re: ahci, SActive flag, and the HD activity LED
Martin Wilck wrote: Jens Axboe wrote: If I am reading the specs correctly, that'd mean the ahci driver is wrong in setting the SActive bit. I completely agree, that was my reading of the spec as well and hence my original posts about this in the NCQ thread. Have you (or has anybody else) also seen the wrong behavior of the activity LED? 925X-Chipset Lspci says: 8086:2652 Intel Corp. 82801FR/FRW (ICH6R/ICH6RW) SATA Controller (rev 03) HDD: Western Digital WD2000JD-00H, i believe this HDD is non-NCQ. Kernels: 2.6.10 - 2.6.12 The Activity-LED has burned like a light-bulb every since i have that computer. (Excluding the few seconds before booting Linux. :-) ) Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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.12.3] PCI/libata INTx cleanup
Simple cleanup to eliminate X copies of the same function in libata.
Moved pci_enable_intx() to pci.c, added pci_disable_intx() as well,
and use them throughout libata and msi.c.
Signed-off-by: Brett Russ <[EMAIL PROTECTED]>
Index: linux-2.6.12.3-mv/drivers/pci/msi.c
===
--- linux-2.6.12.3-mv.orig/drivers/pci/msi.c
+++ linux-2.6.12.3-mv/drivers/pci/msi.c
@@ -456,10 +456,7 @@ static void enable_msi_mode(struct pci_d
}
if (pci_find_capability(dev, PCI_CAP_ID_EXP)) {
/* PCI Express Endpoint device detected */
- u16 cmd;
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
- cmd |= PCI_COMMAND_INTX_DISABLE;
- pci_write_config_word(dev, PCI_COMMAND, cmd);
+ pci_disable_intx(dev);
}
}
@@ -478,10 +475,7 @@ static void disable_msi_mode(struct pci_
}
if (pci_find_capability(dev, PCI_CAP_ID_EXP)) {
/* PCI Express Endpoint device detected */
- u16 cmd;
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
- cmd &= ~PCI_COMMAND_INTX_DISABLE;
- pci_write_config_word(dev, PCI_COMMAND, cmd);
+ pci_enable_intx(dev);
}
}
Index: linux-2.6.12.3-mv/drivers/pci/pci.c
===
--- linux-2.6.12.3-mv.orig/drivers/pci/pci.c
+++ linux-2.6.12.3-mv/drivers/pci/pci.c
@@ -733,6 +733,43 @@ pci_clear_mwi(struct pci_dev *dev)
}
}
+
+/**
+ * pci_enable_intx - enables INTx generation in PCI cfg space cmd register
+ * @dev: the PCI device to enable
+ *
+ * Enables PCI INTx generation for device
+ */
+void
+pci_enable_intx(struct pci_dev *pdev)
+{
+u16 pci_command;
+
+pci_read_config_word(pdev, PCI_COMMAND, &pci_command);
+if (pci_command & PCI_COMMAND_INTX_DISABLE) {
+pci_command &= ~PCI_COMMAND_INTX_DISABLE;
+pci_write_config_word(pdev, PCI_COMMAND, pci_command);
+}
+}
+
+/**
+ * pci_disable_intx - disables INTx generation in PCI cfg space cmd register
+ * @dev: the PCI device to disable
+ *
+ * Disables PCI INTx generation for device
+ */
+void
+pci_disable_intx(struct pci_dev *pdev)
+{
+u16 pci_command;
+
+pci_read_config_word(pdev, PCI_COMMAND, &pci_command);
+if (!(pci_command & PCI_COMMAND_INTX_DISABLE)) {
+pci_command |= PCI_COMMAND_INTX_DISABLE;
+pci_write_config_word(pdev, PCI_COMMAND, pci_command);
+}
+}
+
#ifndef HAVE_ARCH_PCI_SET_DMA_MASK
/*
* These can be overridden by arch-specific implementations
@@ -809,6 +846,8 @@ EXPORT_SYMBOL(pci_request_region);
EXPORT_SYMBOL(pci_set_master);
EXPORT_SYMBOL(pci_set_mwi);
EXPORT_SYMBOL(pci_clear_mwi);
+EXPORT_SYMBOL(pci_enable_intx);
+EXPORT_SYMBOL(pci_disable_intx);
EXPORT_SYMBOL(pci_set_dma_mask);
EXPORT_SYMBOL(pci_set_consistent_dma_mask);
EXPORT_SYMBOL(pci_assign_resource);
Index: linux-2.6.12.3-mv/drivers/scsi/sata_sis.c
===
--- linux-2.6.12.3-mv.orig/drivers/scsi/sata_sis.c
+++ linux-2.6.12.3-mv/drivers/scsi/sata_sis.c
@@ -186,18 +186,6 @@ static void sis_scr_write (struct ata_po
outl(val, ap->ioaddr.scr_addr + (sc_reg * 4));
}
-/* move to PCI layer, integrate w/ MSI stuff */
-static void pci_enable_intx(struct pci_dev *pdev)
-{
- u16 pci_command;
-
- pci_read_config_word(pdev, PCI_COMMAND, &pci_command);
- if (pci_command & PCI_COMMAND_INTX_DISABLE) {
- pci_command &= ~PCI_COMMAND_INTX_DISABLE;
- pci_write_config_word(pdev, PCI_COMMAND, pci_command);
- }
-}
-
static int sis_init_one (struct pci_dev *pdev, const struct pci_device_id *ent)
{
struct ata_probe_ent *probe_ent = NULL;
Index: linux-2.6.12.3-mv/drivers/scsi/ahci.c
===
--- linux-2.6.12.3-mv.orig/drivers/scsi/ahci.c
+++ linux-2.6.12.3-mv/drivers/scsi/ahci.c
@@ -878,18 +878,6 @@ static int ahci_host_init(struct ata_pro
return 0;
}
-/* move to PCI layer, integrate w/ MSI stuff */
-static void pci_enable_intx(struct pci_dev *pdev)
-{
- u16 pci_command;
-
- pci_read_config_word(pdev, PCI_COMMAND, &pci_command);
- if (pci_command & PCI_COMMAND_INTX_DISABLE) {
- pci_command &= ~PCI_COMMAND_INTX_DISABLE;
- pci_write_config_word(pdev, PCI_COMMAND, pci_command);
- }
-}
-
static void ahci_print_info(struct ata_probe_ent *probe_ent)
{
struct ahci_host_priv *hpriv = probe_ent->private_data;
Index: linux-2.6.12.3-mv/drivers/scsi/ata_piix.c
===
--- linux-2.6.12.3-mv.orig/drivers/scsi/ata_piix.c
+++ linux-2.6.12.3-mv/drivers/scsi/ata_piix.c
@@ -545,18 +545,6 @@ static void piix_set_dmamode (struct ata
}
}
-
[OT] Great resources for Linux Programming?
Since I'm a frequent reader of this list, I'm going to ask you guys this question first. I started working on my masters thesis (computer science) and I need to find in depth resources about linux programming, I want to ask you guys if you know any good documentation, tutorials especially about linux threads, semaphores, events, signals. My implemtation requires me to implement those things for windows and linux, so I would need some comparison, codesamples about threads in windows and linux etc. The only good resource I found for now was a migrating tutorial from ibm. Does anyone know where I can get some additional info about that? Thanks Stefan P.S. Sorry for bugging you guys with that! ___ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] ide: fix kmalloc_node breakage in ide driver
Machines with ide-interfaces which do not have pci devices are crashing on boot
at pcibus_to_node in the ide drivers. We noticed this on a x445 running
2.6.13-rc4. Similar issue was discussed earlier, but the crash was due
to hwif being NULL.
http://marc.theaimsgroup.com/?t=11207535203&r=1&w=2
Andi and Christoph had patches, but neither went in. Here's one of those
patches with an added BUG_ON(hwif == NULL). Please include.
Thanks,
Kiran
Patch fixes oops caused by ide interfaces not on pci. pcibus_to_node causes
the kernel to crash otherwise. Patch also adds a BUG_ON to check if hwif is
NULL.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Shai Fultheim <[EMAIL PROTECTED]>
Signed-off-by: Ravikiran Thirumalai <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc1/drivers/ide/ide-probe.c
===
--- linux-2.6.13-rc1.orig/drivers/ide/ide-probe.c 2005-06-29
20:06:53.0 -0400
+++ linux-2.6.13-rc1/drivers/ide/ide-probe.c2005-08-02 10:09:20.930965408
-0400
@@ -960,6 +960,15 @@
}
#endif /* MAX_HWIFS > 1 */
+static inline int hwif_to_node(ide_hwif_t *hwif)
+{
+ if (hwif->pci_dev)
+ return pcibus_to_node(hwif->pci_dev->bus);
+ else
+ /* Add ways to determine the node of other busses here */
+ return -1;
+}
+
/*
* init request queue
*/
@@ -978,8 +987,7 @@
* do not.
*/
- q = blk_init_queue_node(do_ide_request, &ide_lock,
- pcibus_to_node(drive->hwif->pci_dev->bus));
+ q = blk_init_queue_node(do_ide_request, &ide_lock, hwif_to_node(hwif));
if (!q)
return 1;
@@ -1048,6 +1056,8 @@
BUG_ON(in_interrupt());
BUG_ON(irqs_disabled());
+ BUG_ON(hwif == NULL);
+
down(&ide_cfg_sem);
hwif->hwgroup = NULL;
#if MAX_HWIFS > 1
@@ -1097,7 +1107,7 @@
spin_unlock_irq(&ide_lock);
} else {
hwgroup = kmalloc_node(sizeof(ide_hwgroup_t), GFP_KERNEL,
- pcibus_to_node(hwif->drives[0].hwif->pci_dev->bus));
+ hwif_to_node(hwif->drives[0].hwif));
if (!hwgroup)
goto out_up;
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] ide: fix kmalloc_node breakage in ide driver
On Wed, 3 Aug 2005, Ravikiran G Thirumalai wrote: > Machines with ide-interfaces which do not have pci devices are crashing on > boot > at pcibus_to_node in the ide drivers. We noticed this on a x445 running > 2.6.13-rc4. Similar issue was discussed earlier, but the crash was due > to hwif being NULL. > http://marc.theaimsgroup.com/?t=11207535203&r=1&w=2 > Andi and Christoph had patches, but neither went in. Here's one of those > patches with an added BUG_ON(hwif == NULL). Please include. This needs to go into 2.6.13. - 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 linux-2.6.13-rc3] SATA: rewritten sil24 driver
Hello, Edward.
One more question.
> > >
> > >I think this will work (adapted from sil_interrupt():
> > >
> > >static void sil_irq_clear(struct ata_port *ap)
> > >{
> > >struct sil_port_priv *pp = ap->private_data;
> > >struct Port_Registers *port_base = pp->pregs;
> > >unsigned long port_int;
> > >
> > >port_int = readl((void *)&port_base->IntStatus);
> > >writel(port_int, &port_base->IntStatus);
> > >}
> > >
> > >I'm assuming that this entry point is expected to clear all interrupts, no?
> >
> > Correct.
> >
>
> I'll verify with the error register clearing part of the original
> driver and submit a patch.
>
Command completion interrupt is automatcally cleared by reading
PORT_SLOT_STAT register (SlotStatus in the original driver), and error
registers should be manually cleared by writing to PORT_IRQ_STAT
(IntStatus).
I agree that above code should clear both. Just wanna verify. Have
you tested it and/or do you have any information confirming this? If
we don't have any further info, I think we should read PORT_SLOT_STAT
before clearing PORT_IRQ_STAT to be on the safe side.
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
