Hi,
during last year there was couple of complaints that pdc202xx_old
driver does not allow LBA48 on first channel, and couple of confirmations
that just removing these two lines which do:
if (hwif->pci_dev->device == PCI_DEVICE_ID_PROMISE_20265)
hwif->no_lba48 = (hwif->channel) ? 0 : 1;
fixes problem, and both channels run with lba48 drives just fine...
Yesterday I bring home two nice 160GB seagates, hooked them up to
the Promise, and booted. And to my surprise we still do not enable
lba48 on primary channel...
Is there some reason for doing that? I removed this, and I was able
to copy contents of my old 120GB disk to the 160GB one, with 40G offset
(so lba48 has to work, otherwise first 40GB holding an VFAT partition with
some gzipped test files gets corrupted). Currently these two drives
are unused (they just hold backup copy of dying 120GB wd), so I can do
any experiments you may want to confirm/decline idea that we should
remove this no_lba48 hack. Of course unless you have datasheet which says
that it cannot work. But as Promise BIOS happily says that two 149GB disks
(149 * 2^30 == 160 * 10^9) running UDMA5 are attached, I assume that it
is willing to handle LBA48 on both channels.
Thanks,
Petr Vandrovec
Hi,
There was a recent threads on this issue:
"IDE bug - was: Re: uncorrectable ext2 errors"
and "Promise IDE patches".
One of conclusions was that there is no reason not to enable LBA48
on PDC20265. I will send Jan's patches to Linus. Thanks for verifying this.
--bartlomiej
On Wednesday 03 of September 2003 14:46, Petr Vandrovec wrote:
> Hi,
> during last year there was couple of complaints that pdc202xx_old
> driver does not allow LBA48 on first channel, and couple of confirmations
> that just removing these two lines which do:
>
> if (hwif->pci_dev->device == PCI_DEVICE_ID_PROMISE_20265)
> hwif->no_lba48 = (hwif->channel) ? 0 : 1;
>
> fixes problem, and both channels run with lba48 drives just fine...
>
> Yesterday I bring home two nice 160GB seagates, hooked them up to
> the Promise, and booted. And to my surprise we still do not enable
> lba48 on primary channel...
>
> Is there some reason for doing that? I removed this, and I was able
> to copy contents of my old 120GB disk to the 160GB one, with 40G offset
> (so lba48 has to work, otherwise first 40GB holding an VFAT partition with
> some gzipped test files gets corrupted). Currently these two drives
> are unused (they just hold backup copy of dying 120GB wd), so I can do
> any experiments you may want to confirm/decline idea that we should
> remove this no_lba48 hack. Of course unless you have datasheet which says
> that it cannot work. But as Promise BIOS happily says that two 149GB disks
> (149 * 2^30 == 160 * 10^9) running UDMA5 are attached, I assume that it
> is willing to handle LBA48 on both channels.
> Thanks,
> Petr Vandrovec
On Wednesday 03 of September 2003 15:20, Bartlomiej Zolnierkiewicz wrote:
> Hi,
>
> There was a recent threads on this issue:
> "IDE bug - was: Re: uncorrectable ext2 errors"
> and "Promise IDE patches".
>
> One of conclusions was that there is no reason not to enable LBA48
> on PDC20265. I will send Jan's patches to Linus. Thanks for verifying
> this.
I've just sent patch removing these 2 lines to Linus and actually I was
thinking about Ross Biro's patch when writing this. Can you test?
ide: fix for Promise 20265/20267 PIO Lockup
Orginal patch by Ross Biro:
Newer kernels will lock up when a drive command (SMART, hdparm -I, etc.)
is issued to a drive connected to a Promise 20265 or 20267 controller
while the controller is in DMA mode. The problem appears to be that
tune_chipset incorrectly clears the high PIO bit thinking that it is a
"PIO force on" bit. The documentation I have access to does not seem to
mention a PIO force bit. Not changing that bit seems to fix the problem
with drive commands on a promise controller.
The documentation I have also says the values for the TB and TC
variables should be the same for all UDMA modes and they are not.
However the driver seems to work anyway, so I left them the way they are.
To reproduce this problem make sure your drive is set to a DMA mode, eg
hdparm -X 67 and then issue a drive command, e.g. hdparm -I.
This problem may also be present in the drivers for other Promise chips.
This change has only been minimally tested.
drivers/ide/pci/pdc202xx_old.c | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletion(-)
diff -puN drivers/ide/pci/pdc202xx_old.c~ide-pdc-old-lockup drivers/ide/pci/pdc202xx_old.c
--- linux-2.6.0-test4-bk3/drivers/ide/pci/pdc202xx_old.c~ide-pdc-old-lockup 2003-09-03 15:28:07.872200152 +0200
+++ linux-2.6.0-test4-bk3-root/drivers/ide/pci/pdc202xx_old.c 2003-09-03 15:32:46.011916488 +0200
@@ -271,7 +271,15 @@ static int pdc202xx_tune_chipset (ide_dr
if ((BP & 0xF0) && (CP & 0x0F)) {
/* clear DMA modes of upper 842 bits of B Register */
/* clear PIO forced mode upper 1 bit of B Register */
- pci_write_config_byte(dev, (drive_pci)|0x01, BP &~0xF0);
+ /*
+ * The documentation I have access to says there
+ * is no PIO forced mode bit. -- RAB 01/10/03
+ */
+ if (dev->device == PCI_DEVICE_ID_PROMISE_20265 ||
+ dev->device == PCI_DEVICE_ID_PROMISE_20267)
+ pci_write_config_byte(dev, (drive_pci)|0x01, BP &~0xE0);
+ else
+ pci_write_config_byte(dev, (drive_pci)|0x01, BP &~0xF0);
pci_read_config_byte(dev, (drive_pci)|0x01, &BP);
/* clear DMA modes of lower 8421 bits of C Register */
_
On Wed, Sep 03, 2003 at 03:49:52PM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 03 of September 2003 15:20, Bartlomiej Zolnierkiewicz wrote:
> > Hi,
> >
> > There was a recent threads on this issue:
> > "IDE bug - was: Re: uncorrectable ext2 errors"
> > and "Promise IDE patches".
> >
> > One of conclusions was that there is no reason not to enable LBA48
> > on PDC20265. I will send Jan's patches to Linus. Thanks for verifying
> > this.
>
> I've just sent patch removing these 2 lines to Linus and actually I was
> thinking about Ross Biro's patch when writing this. Can you test?
>
> Newer kernels will lock up when a drive command (SMART, hdparm -I, etc.)
> is issued to a drive connected to a Promise 20265 or 20267 controller
> while the controller is in DMA mode. The problem appears to be that
> tune_chipset incorrectly clears the high PIO bit thinking that it is a
> "PIO force on" bit. The documentation I have access to does not seem to
> mention a PIO force bit. Not changing that bit seems to fix the problem
> with drive commands on a promise controller.
>
According to my tests this bit makes no difference. For primary master
register B should be register 0x61 in PCI config space. When disk/adapter are
operating in UDMA5, values shown below are used - 0x24 in register B, and
disk accesses, and hdparm -i/-I and ide-smart -d /dev/hde works fine.
When I change this value to 0x34, I see no change in behavior, everything
still works.
000000 5a 10 30 0d 07 00 10 02 02 00 80 01 00 20 00 00
000010 01 98 00 00 01 94 00 00 01 90 00 00 01 88 00 00
000020 01 84 00 00 00 00 80 ca 00 00 00 00 5a 10 33 4d
000030 00 00 00 00 58 00 00 00 00 00 00 00 0a 01 00 00
000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000050 be 33 00 00 00 00 00 00 01 00 01 00 00 00 00 00
000060 f1 24 41 00 c4 f3 4f 00 04 f3 4f 00 31 24 41 00
000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Only problem I found is that if I do 'hdparm -p0 /dev/hde' followed by
'hdparm -d1 -X69 /dev/hde', IDE activity leds goes on, and kernel locks up.
I tried UP kernel with spinlock debugging, and I have enabled (APIC) NMI
watchdog, but it did no change - machine still locks up, and there is no
NMI watchdog message for at least one minute (NMI count in /proc/interrupts
increases, so I assume that it should work).
So I have no idea whether this Ross's patch should be applied or not. I see
no difference in behavior.
But it looks suspicious to me that PIO tuning clears lower 3 bits of
register B, but then it sets bit 3 (for PIO1/2) or bit 4 (for PIO0).
It means that if we use PIO3 after DMA mode, we use value 0x06 for TB, but if
we'll use PIO3 after PIO0 and PIO1 mode, we use value 0x1E for TB... Does
not look good to me.
I think that these masks should match, and we should use 0xF0/0x0F for register
A and 0xE0/0x1F for register B (instead of 0xF0/0x07 we use currently). Otherwise
value of bits 4 & 3 or register B is almost random, and depends on previously
used mode, and thus Ross's patch is step in good direction.
Best regards,
Petr Vandrovec