mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
To: Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua>
Cc: Sebastian Witt <se.witt@gmx.net>,
	linux-kernel@vger.kernel.org, andre@linux-ide.org,
	frankt@promise.com
Subject: Re: PROBLEM: Oops when using both channels of the PDC20262
Date: Sat, 24 Apr 2004 22:30:20 +0200	[thread overview]
Message-ID: <200404242230.20985.bzolnier@elka.pw.edu.pl> (raw)
In-Reply-To: <200404242242.36154.vda@port.imtp.ilyichevsk.odessa.ua>

On Saturday 24 of April 2004 21:42, Denis Vlasenko wrote:
> On Saturday 24 April 2004 00:30, Sebastian Witt wrote:
> > Hello,
> >
> > I'm getting some Oopses with kernel 2.6.5 when there is high load on
> > both channels of a Promise PDC20262 (Ultra66) card on a SMP machine
> > (Tyan S1834, Via Apollo Pro chipset).
>
> I recall similar report. Reporter found that there is a #define
> in the source which can be enabled to make driver serialize access
> to channels. That 'fixed' (most probably worked around, though)
> the problem.

Denis, you are talking about hpt366.c not pdc202xx_old.c. ;-)

> I can't say whether it was a hardware or driver problem,
> I didn't look into it.
>
> > There are no problems when I use 2.6.1, but I have this problem
> > since 2.6.2.
> > It only occurs when I use the PDC20262, not when using the onboard
> > IDE-controller.

There were some change in pdc202xx_old.c driver in 2.6.2.
Please revert this patch and report if it helps.

diff -Nru a/drivers/ide/pci/pdc202xx_old.c b/drivers/ide/pci/pdc202xx_old.c
--- a/drivers/ide/pci/pdc202xx_old.c	Tue Feb  3 19:45:42 2004
+++ b/drivers/ide/pci/pdc202xx_old.c	Tue Feb  3 19:45:42 2004
@@ -361,16 +361,38 @@
 	return ((u8)(CIS & mask));
 }
 
+/*
+ * Set the control register to use the 66MHz system
+ * clock for UDMA 3/4/5 mode operation when necessary.
+ *
+ * It may also be possible to leave the 66MHz clock on
+ * and readjust the timing parameters.
+ */
+static void pdc_old_enable_66MHz_clock(ide_hwif_t *hwif)
+{
+	unsigned long clock_reg = hwif->dma_master + 0x11;
+	u8 clock = hwif->INB(clock_reg);
+
+	hwif->OUTB(clock | (hwif->channel ? 0x08 : 0x02), clock_reg);
+}
+
+static void pdc_old_disable_66MHz_clock(ide_hwif_t *hwif)
+{
+	unsigned long clock_reg = hwif->dma_master + 0x11;
+	u8 clock = hwif->INB(clock_reg);
+
+	hwif->OUTB(clock & ~(hwif->channel ? 0x08 : 0x02), clock_reg);
+}
+
 static int config_chipset_for_dma (ide_drive_t *drive)
 {
 	struct hd_driveid *id	= drive->id;
 	ide_hwif_t *hwif	= HWIF(drive);
 	struct pci_dev *dev	= hwif->pci_dev;
 	u32 drive_conf		= 0;
-	u8 mask			= hwif->channel ? 0x08 : 0x02;
 	u8 drive_pci		= 0x60 + (drive->dn << 2);
 	u8 test1 = 0, test2 = 0, speed = -1;
-	u8 AP = 0, CLKSPD = 0, cable = 0;
+	u8 AP = 0, cable = 0;
 
 	u8 ultra_66		= ((id->dma_ultra & 0x0010) ||
 				   (id->dma_ultra & 0x0008)) ? 1 : 0;
@@ -394,21 +416,6 @@
 			BUG();
 	}
 
-	CLKSPD = hwif->INB(hwif->dma_master + 0x11);
-
-	/*
-	 * Set the control register to use the 66Mhz system
-	 * clock for UDMA 3/4 mode operation. If one drive on
-	 * a channel is U66 capable but the other isn't we
-	 * fall back to U33 mode. The BIOS INT 13 hooks turn
-	 * the clock on then off for each read/write issued. I don't
-	 * do that here because it would require modifying the
-	 * kernel, separating the fop routines from the kernel or
-	 * somehow hooking the fops calls. It may also be possible to
-	 * leave the 66Mhz clock on and readjust the timing
-	 * parameters.
-	 */
-
 	if ((ultra_66) && (cable)) {
 #ifdef DEBUG
 		printk(KERN_DEBUG "ULTRA 66/100/133: %s channel of Ultra 66/100/133 "
@@ -416,29 +423,12 @@
 			hwif->channel ? "Secondary" : "Primary");
 		printk(KERN_DEBUG "         Switching to Ultra33 mode.\n");
 #endif /* DEBUG */
-		/* Primary   : zero out second bit */
-		/* Secondary : zero out fourth bit */
-		hwif->OUTB(CLKSPD & ~mask, (hwif->dma_master + 0x11));
 		printk(KERN_WARNING "Warning: %s channel requires an 80-pin cable for operation.\n", hwif->channel ? "Secondary":"Primary");
 		printk(KERN_WARNING "%s reduced to Ultra33 mode.\n", drive->name);
-	} else {
-		if (ultra_66) {
-			/*
-			 * check to make sure drive on same channel
-			 * is u66 capable
-			 */
-			if (hwif->drives[!(drive->dn%2)].id) {
-				if (hwif->drives[!(drive->dn%2)].id->dma_ultra & 0x0078) {
-					hwif->OUTB(CLKSPD | mask, (hwif->dma_master + 0x11));
-				} else {
-					hwif->OUTB(CLKSPD & ~mask, (hwif->dma_master + 0x11));
-				}
-			} else { /* udma4 drive by itself */
-				hwif->OUTB(CLKSPD | mask, (hwif->dma_master + 0x11));
-			}
-		}
 	}
 
+	pdc_old_disable_66MHz_clock(drive->hwif);
+
 	drive_pci = 0x60 + (drive->dn << 2);
 	pci_read_config_dword(dev, drive_pci, &drive_conf);
 	if ((drive_conf != 0x004ff304) && (drive_conf != 0x004ff3c4))
@@ -536,6 +526,8 @@
 
 static int pdc202xx_old_ide_dma_begin(ide_drive_t *drive)
 {
+	if (drive->current_speed > XFER_UDMA_2)
+		pdc_old_enable_66MHz_clock(drive->hwif);
 	if (drive->addressing == 1) {
 		struct request *rq	= HWGROUP(drive)->rq;
 		ide_hwif_t *hwif	= HWIF(drive);
@@ -569,6 +561,8 @@
 		clock = hwif->INB(high_16 + 0x11);
 		hwif->OUTB(clock & ~(hwif->channel ? 0x08:0x02), high_16+0x11);
 	}
+	if (drive->current_speed > XFER_UDMA_2)
+		pdc_old_disable_66MHz_clock(drive->hwif);
 	return __ide_dma_end(drive);
 }
 
@@ -757,10 +751,7 @@
 
 	hwif->speedproc = &pdc202xx_tune_chipset;
 
-	if (!hwif->dma_base) {
-		hwif->drives[0].autotune = hwif->drives[1].autotune = 1;
-		return;
-	}
+	hwif->drives[0].autotune = hwif->drives[1].autotune = 1;
 
 	hwif->ultra_mask = 0x3f;
 	hwif->mwdma_mask = 0x07;


> > It is reproduceable after a few seconds when I use 'dd if=/dev/hde
> > of=/dev/hdh bs=512'.
> > Using of=/dev/null also works, but it takes longer.
> >
> > Mostly it reports smp_apic_timer_interrupt+1c/140, but the last time
> > I tried it, it also reports <__mask_IO_APIC_irq+40/e0>.
> >
> > I've attached the logs and the ksymoops trace.

Strange, it looks like IO-APIC problem.
Have you tried booting with "noapic" kernel parameter?

Regards,
Bartlomiej


  reply	other threads:[~2004-04-24 20:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-23 21:30 Sebastian Witt
2004-04-24 19:42 ` Denis Vlasenko
2004-04-24 20:30   ` Bartlomiej Zolnierkiewicz [this message]
2004-04-25  0:20     ` Sebastian Witt
2004-04-25  1:31       ` Bartlomiej Zolnierkiewicz
2004-04-25 18:02         ` Sebastian Witt
2004-04-25 19:47           ` Bartlomiej Zolnierkiewicz
2004-04-25 20:21             ` Sebastian Witt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200404242230.20985.bzolnier@elka.pw.edu.pl \
    --to=b.zolnierkiewicz@elka.pw.edu.pl \
    --cc=andre@linux-ide.org \
    --cc=frankt@promise.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=se.witt@gmx.net \
    --cc=vda@port.imtp.ilyichevsk.odessa.ua \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®