Re: 2.4.19 IDE Partition Check issue (again)

Re: 2.4.19 IDE Partition Check issue (again)

[steveb]

Sorry if this is an old issue, but I'm still seeing this problem between
ALI15x3 and Maxtor drives when DMA is enabled...

If I run 2.4.19 DMA is not autodetected. I get lousy performance. I can enable DMA (with hdparm) on all but my Maxtor drive, but if I manually enable DMA on the Maxtor drive disk access freezes (to both drives on the channel).

If I run 2.4.19-ac4 DMA is turned on automatically and the system hangs at the partition check.

on 2.4.19 I see this in dmesg:
...
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ALI15X3: IDE controller on PCI bus 00 dev 20
PCI: No IRQ known for interrupt pin A of device 00:04.0. Please try using pci=biosirq.
ALI15X3: chipset revision 196
ALI15X3: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xb400-0xb407, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0xb408-0xb40f, BIOS settings: hdc:DMA, hdd:DMA
hda: ST340016A, ATA DISK drive
hdb: Maxtor 4G120J6, ATA DISK drive
hdc: RICOH DVD/CDRW MP9120, ATAPI CD/DVD-ROM drive
hdd: IBM-DPTA-372050, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 78165360 sectors (40021 MB) w/2048KiB Cache, CHS=77545/16/63
hdb: 240121728 sectors (122942 MB) w/2048KiB Cache, CHS=14946/255/63
hdd: 40088160 sectors (20525 MB) w/1961KiB Cache, CHS=39770/16/63, UDMA(66)
ide-floppy driver 0.99.newide
Partition check:
 /dev/ide/host0/bus0/target0/lun0: p1 p2 < p5 p6 p7 >
 /dev/ide/host0/bus0/target1/lun0: p1
 /dev/ide/host0/bus1/target1/lun0: [PTBL] [2495/255/63] p1

2.4.19-ac4 (correctly) probes hda and hdb as being UDMA(100), but it looks like hdb chokes on the DMA...

Steve Bennett

Re: 2.4.19 IDE Partition Check issue (again)

[Alan Cox]

> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> ALI15X3: IDE controller on PCI bus 00 dev 20
> PCI: No IRQ known for interrupt pin A of device 00:04.0. Please try using pci=biosirq.
> ALI15X3: chipset revision 196

Perfect you have revision C4, you answered the outstanding mystery about
whether C4 is capable of LBA48 or its >C4 that is

Try this
--- drivers/ide/alim15x3.c~	2002-08-11 19:33:14.000000000 +0100
+++ drivers/ide/alim15x3.c	2002-08-11 19:33:14.000000000 +0100
@@ -810,7 +810,7 @@
 
 	/* Don't use LBA48 on ALi devices before rev 0xC4 */
 
-	if(m5229_revision < 0xC4)
+	if(m5229_revision <= 0xC4)
 		hwif->addressing = 1;
 
 }

Re: 2.4.19 IDE Partition Check issue (again)

[John Levon]

On Sun, Aug 11, 2002 at 08:53:38PM +0100, Alan Cox wrote:

> Try this
> --- drivers/ide/alim15x3.c~	2002-08-11 19:33:14.000000000 +0100
> +++ drivers/ide/alim15x3.c	2002-08-11 19:33:14.000000000 +0100
> @@ -810,7 +810,7 @@
>  
>  	/* Don't use LBA48 on ALi devices before rev 0xC4 */
>  
> -	if(m5229_revision < 0xC4)
> +	if(m5229_revision <= 0xC4)
>  		hwif->addressing = 1;

would be nice to change the comment too ;)

regards
john

-- 
"It is unbecoming for young men to utter maxims."
	- Aristotle

Re: 2.4.19 IDE Partition Check issue (again)

[steveb]

In message <1029095618.16216.21.camel@irongate.swansea.linux.org.uk> Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> Perfect you have revision C4, you answered the outstanding mystery about
> whether C4 is capable of LBA48 or its >C4 that is

Yes that did the trick.

Many thanks - hopefully the MP3s won't stutter now when I'm recompiling :-)

Steve.

Re: 2.4.19 IDE Partition Check issue (again)

[steveb]

Some more on this...
at http://www.netzerver.com/downloads/software/firmware/readme320.txt
there's a reference to an issue with Maxtor drives.

They say:
>- Maxtor ATA/66 Disk Compatibility -
>  An ATA/66 disk compatibility issue has been identified and published
>  by Maxtor, which has provided a utility to correct it. The problem
>  manifests itself in one of two ways:
>
>     The system can hang during a power up,
>                   or
>     The system can hang during the first attempt to write to the
>     Maxtor IDE disk.
>
>  According to Maxtor, the incompatibility exists with, but is not
>  limited to, the following chipsets:
>
>     Intel 440TX, 440LX, 440BX
>     VIA 586A, 586B, 596, 686
>     SiS 5598, 5591, 5600, 530, 620
>     ALi 1543C, 1533A-J, 1543A-F
>
>  The host chipset and the Maxtor drives do not negotiate to the same
>  operating mode. It is necessary to force the drive to DMA/33 or
>  DMA/66 mode if using the DMA/66 channels.

Maxtor technical note 21006 (at http://www.maxtor.com/products/diamondmax/techsupport/technicalprocedures/21006.html)
seems to refer to this. There's a tool called UDMAUPDT that (presumably)
pokes the flash on the HDD to say what flavour of UDMA to claim support for.
I guess that you're meant to try all the values until you find one that
works.
I've just all the DMA modes on my drive, the tool seems to work (the
corresponding DMA mode is reported in the boot messages), but it still
fails in the same way - as soon as you try to do anything to the drive with
DMA enabled it goes into a big sulk.

My mobo is an ASUS A7A266, with the latest BIOS (v1011).

I've rejigged my server now - I've put the two drives that work with DMA enabled on to ide0, and the Maxtor and CDROM onto ide1. I'm booting 2.4.19-ac4 with ide=nodma (so that the thing will start) and then manually enabling DMA on hda and hdb with hdparm. Manually enabling DMA on the Maxtor still makes the IDE channel freeze (as does booting without ide=nodma), but it doesn't kill the machine outright now, so it's a bit easier to play with things.

I really do want to get DMA working on this drive (without DMA the performance is ~3.5MB/s as opposed to 40MB/s on the drives with DMA working). If anyone can suggest other things to prod I'd be extremely grateful...


Steve.

Re: 2.4.19 IDE Partition Check issue (again)

[Stewart]

On Sun, 11 Aug 2002 steveb@unix.lancs.ac.uk wrote:

> Sorry if this is an old issue, but I'm still seeing this problem between
> ALI15x3 and Maxtor drives when DMA is enabled...

> If I run 2.4.19 DMA is not autodetected. I get lousy performance. I can
> enable DMA (with hdparm) on all but my Maxtor drive, but if I manually
> enable DMA on the Maxtor drive disk access freezes (to both drives on
> the channel).
> 
> If I run 2.4.19-ac4 DMA is turned on automatically and the system hangs
> at the partition check.

I'm not quite certain whether my problem is related or not, but I happened 
to see that you're running the same onboard chipset driver as I am, and 
I'm having strange large IDE disk problems lately.

I'm not sure if this is hardware or not, as this drive is an RMA 
replacement unit (bad sectors), and the text of this new message puzzles 
me.

Anyways, to the particulars.

Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with 
idebus=xx
ALI15X3: IDE controller on PCI bus 00 dev 78
PCI: No IRQ known for interrupt pin A of device 00:0f.0. Please try using 
pci=bi
ALI15X3: chipset revision 193
ALI15X3: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:pio, hdd:pio
hda: WDC WD800BB-75CAA0, ATA DISK drive
ide: Assuming 33MHz system bus speed for PIO modes; override with 
idebus=xx
hdc: MATSHITA CR-585, ATAPI CD/DVD-ROM drive
hdd: IOMEGA ZIP 100 ATAPI, ATAPI FLOPPY drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: setmax LBA 156301488, native  156250000
hda: 156250000 sectors (80000 MB) w/2048KiB Cache, CHS=9726/255/63, (U)DMA
spurious 8259A interrupt: IRQ7.
hdc: ATAPI 24X CD-ROM drive, 128kB Cache, DMA
Uniform CD-ROM driver Revision: 3.12
ide-floppy driver 0.99.newide
hdd: No disk in drive
hdd: 98304kB, 32/64/96 CHS, 4096 kBps, 512 sector size, 2941 rpm
Partition check:
 /dev/ide/host0/bus0/target0/lun0: p1 p2 p3 p4 < p5 p6 p7 p8 p9 p10 p11 >
ide-floppy driver 0.99.newide


Shortly before I got home tonight (the clock is wrong; it's supposed to 
read 1:19; it's been corrected, so ignore it. {smile} ) my system's IDE 
bus was frozen, so all daemons were dead in their tracks. IP routing was 
still functional, but none of my servers (hence my mail and web browsing) 
were cut off at the knees.

Here's what I found in /var/log/messages, right before the lockup (and 
reset; C-A-D wouldn't respond);

Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: error=0x10 { 
SectorIdNotFound }, LBAsect=156250000, sector=1527880
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: status=0x51 { DriveReady 
SeekComplete Error }
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: error=0x10 { 
SectorIdNotFound }, LBAsect=156250000, sector=1527880
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: status=0x51 { DriveReady 
SeekComplete Error }
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: error=0x10 { 
SectorIdNotFound }, LBAsect=156250000, sector=1527880
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: status=0x51 { DriveReady 
SeekComplete Error }
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr:ror }
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: error=0x10 { 
SectorIdNotFound }, LBAsect=156250685, sector=1528520
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: status=0x51 { DriveReady 
SeekComplete Error }
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: error=0x10 { 
SectorIdNotFound }, LBAsect=156250685, sector=1528520
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: status=0x51 { DriveReady 
SeekComplete Error }
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: error=0x10 { 
SectorIdNotFound }, LBAsect=156250685, sector=1528520
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: status=0x51 { DriveReady 
SeekComplete Error }
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: error=0x10 { 
SectorIdNotFound }, LBAsect=156250685, sector=1528520
Aug 10 21:09:46 zeus kernel: ide0: reset: success
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: status=0x51 { DriveReady 
SeekComplete Error }
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: error=0x10 { 
SectorIdNotFound }, LBAsect=156250685, sector=1528520
Aug 10 21:09:46 zeus kernel: end_request: I/O error, dev 03:0b (hda), 
sector 1528520
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: status=0x51 { DriveReady 
SeekComplete Error }
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: error=0x10 { 
SectorIdNotFound }, LBAsect=156250685, sector=1528528
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: status=0x51 { DriveReady 
SeekComplete Error }
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: error=0x10 { 
SectorIdNotFound }, LBAsect=156250685, sector=1528528
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: status=0x51 { DriveReady 
SeekComplete Error }
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: error=0x10 { 
SectorIdNotFound }, LBAsect=156250685, sector=1528528
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: status=0x51 { DriveReady 
SeekComplete Error }
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: error=0x10 { 
SectorIdNotFound }, LBAsect=156250685, sector=1528528
Aug 10 21:09:46 zeus kernel: ide0: reset: success
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: status=0x51 { DriveReady 
SeekComplete Error }
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: error=0x10 { 
SectorIdNotFound }, LBAsect=156250685, sector=1528528
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: status=0x51 { DriveReady 
SeekComplete Error }
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: error=0x10 { 
SectorIdNotFound }, LBAsect=156250685, sector=1528528
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: status=0x51 { DriveReady 
SeekComplete Error }
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: error=0x10 { 
SectorIdNotFound }, LBAsect=156250685, sector=1528528
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: status=0x51 { DriveReady 
SeekComplete Error }
Aug 10 21:09:46 zeus kernel: hda: multwrite_intr: error=0x10 { 
SectorIdNotFound }, LBAsect=15^G ^N^Amg^Dk<8E>^R^Q<88>^A^@^@^@H^@

After that it just got corrupted for a couple of lines.

Written on the drive itself is a sector count of 156250000, which is 
reported by the line(s) in dmesg;

hda: setmax LBA 156301488, native  156250000
hda: 156250000 sectors (80000 MB) w/2048KiB Cache, CHS=9726/255/63, (U)DMA

So, what I'm curious to know is - why was it trying to write to sectors 
156250000 and 156250685? By my count, that's the last sector and a sector 
beyond the end of the drive.

Anyways, this being a brand-new drive I'm somewhat frustrated by all of 
this, and I'd love to know whether this is possibly hardware, or software 
related.

Thank-you all in advance for any insight.

-- 
  Stewart Honsberger @ http://blackdeath.snerk.org/
  Linux zeus 2.4.19 #3 Fri Aug 2 23:28:56 EDT 2002 i586 AuthenticAMD
  1:34am  up 23 min,  2 users,  load average: 1.04, 1.11, 1.01
  Doesn't it bother you, that we have to search for intelligent life
  --- OUT THERE??