IDE from current bk tree, UDMA and two channels...

IDE from current bk tree, UDMA and two channels...

Post by Petr Vandrove » Sat, 03 Aug 2002 07:40:06




Quote:

> Would you mind sending me hdparm -i /dev/hdx and hdparm -I /dev/hdx
> for documentation purposes? The host controller chip could be the
> one to blame as well.

> I fear the need for jet another black list.

Here they are. This is with i845 (82801BA rev B5) host chip. I'll check
i440BX tomorrow and PDC20265 on sunday. I believe that PDC20265
worked because of I did not notice problem at home, only at work.
                                            Petr Vandrovec

/dev/hdc:

 Model=TOSHIBA MK6409MAV, FwRev=F1.03 A, SerialNo=58S40974
 Config={ Fixed }
 RawCHS=13424/15/63, TrkSize=0, SectSize=0, ECCbytes=36
 BuffType=unknown, BuffSize=0kB, MaxMultSect=16, MultSect=off
 CurCHS=13424/15/63, CurSects=12685680, LBA=yes, LBAsects=12685680
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4
 DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 *udma2
 AdvancedPM=no WriteCache=enabled
 Drive Supports : Reserved : ATA-1 ATA-2 ATA-3 ATA-4

/dev/hdc:

non-removable ATA device, with non-removable media
    Model Number:       TOSHIBA MK6409MAV                      
    Serial Number:      58S40974            
    Firmware Revision:  F1.03 A
Standards:
    Supported: 1 2 3 4
    Likely used: 4
Configuration:
    Logical         max     current
    cylinders       13424   13424
    heads           15      15
    sectors/track   63      63
    bytes/track:    0       (obsolete)
    bytes/sector:   0       (obsolete)
    current sector capacity: 12685680
    LBA user addressable sectors = 12685680
Capabilities:
    LBA, IORDY(can be disabled)
    ECC bytes: 36   Queue depth: 1
    Standby timer values: spec'd by Vendor, no device specific minimum
    r/w multiple sector transfer: Max = 16  Current = 16
    DMA: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 *udma2
         Cycle time: min=120ns recommended=120ns
    PIO: pio0 pio1 pio2 pio3 pio4
         Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
    Enabled Supported:
       *    NOP cmd
       *    READ BUFFER cmd
       *    WRITE BUFFER cmd
       *    Host Protected Area feature set
       *    look-ahead
       *    write cache
       *    Power Management feature set
            Security Mode feature set
       *    SMART feature set
Security:
        supported
    not enabled
    not locked
        frozen
    not expired: security count
    not supported: enhanced erase
    22min for SECURITY ERASE UNIT.

00:1f.1 IDE interface: Intel Corp. 82801BA IDE U100 (rev 05) (prog-if 80 [Master])
    Subsystem: Intel Corp.: Unknown device 5054
00:1f.1 Class 0101: 8086:244b (rev 05) (prog-if 80 [Master])
    Subsystem: 8086:5054
    Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
    Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
    Latency: 0
    Region 4: I/O ports at ffa0 [size=16]
00: 86 80 4b 24 05 00 80 02 05 80 01 01 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: a1 ff 00 00 00 00 00 00 00 00 00 00 86 80 54 50
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 47 e3 47 e3 00 00 00 00 05 00 01 02 00 00 00 00
50: 00 00 00 00 10 14 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 47 0f 00 00 00 00 00 00

pcibus = 33333
00:1f.1 vendor=8086 device=244b class=0101 irq=0 base4=ffa1
----------PIIX BusMastering IDE Configuration---------------
Driver Version:                     1.3
South Bridge:                       9291
Revision:                           IDE 0x5
Highest DMA rate:                   UDMA100
BM-DMA base:                        0xffa0
PCI clock:                          33.3MHz
-----------------------Primary IDE-------Secondary IDE------
Enabled:                      yes                 yes
Simplex only:                  no                  no
Cable Type:                   80w                 40w
-------------------drive0----drive1----drive2----drive3-----
Prefetch+Post:        yes       yes       yes       yes
Transfer Mode:       UDMA       PIO      UDMA       PIO
Address Setup:       90ns      90ns      90ns      90ns
Cmd Active:         360ns     360ns     360ns     360ns
Cmd Recovery:       540ns     540ns     540ns     540ns
Data Active:         90ns     360ns      90ns     360ns
Data Recovery:       30ns     540ns      30ns     540ns
Cycle Time:          22ns     900ns      60ns     900ns
Transfer Rate:   88.8MB/s   2.2MB/s  33.3MB/s   2.2MB/s

(whee, Intel defines UDMA(100) to 88.8MB/s?)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

IDE from current bk tree, UDMA and two channels...

Post by Alexander Vir » Sat, 03 Aug 2002 07:50:05



> > I'd like to apologize to Ingo, his changes were completely innocent.
> > Problem was triggered by Al's 'block device size cleanups' (currently
> > cset 1.403.160.5 on bkbits).

> > Before this change, my system was using 4KB block size when reading
> > from /dev/hdc1, because of blk_size[][] (which is in 1kB units) of this
> > partition was multiple of 2, and so i_size % 4096 was 0.  But after
> > Al's change partition size is read from gendisk, and not from blk_size,
> > and gendisk partition size is in 512 bytes units: and, as you can
> > probably guess, now my partition had i_size % 4096 == 512, and so only
> > 512 byte block size was choosen. And with 512 bytes block size my
> > harddisk refuses to cooperate.

Uh-oh...

Let me see if I got it straight:

a) your disk doesn't work with half-Kb requests
b) you have a partition with odd number of sectors
c) hardsect_size is set to half-Kb
d) old code worked since it rounded size to multiple of kilobyte.

Correct?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

IDE from current bk tree, UDMA and two channels...

Post by Petr Vandrove » Sat, 03 Aug 2002 07:50:06




> > > I'd like to apologize to Ingo, his changes were completely innocent.
> > > Problem was triggered by Al's 'block device size cleanups' (currently
> > > cset 1.403.160.5 on bkbits).

> > > Before this change, my system was using 4KB block size when reading
> > > from /dev/hdc1, because of blk_size[][] (which is in 1kB units) of this
> > > partition was multiple of 2, and so i_size % 4096 was 0.  But after
> > > Al's change partition size is read from gendisk, and not from blk_size,
> > > and gendisk partition size is in 512 bytes units: and, as you can
> > > probably guess, now my partition had i_size % 4096 == 512, and so only
> > > 512 byte block size was choosen. And with 512 bytes block size my
> > > harddisk refuses to cooperate.

> Uh-oh...

> Let me see if I got it straight:

> a) your disk doesn't work with half-Kb requests
> b) you have a partition with odd number of sectors
> c) hardsect_size is set to half-Kb
> d) old code worked since it rounded size to multiple of kilobyte.

> Correct?

Yes, exactly. Replacing disk is not an option...
                                            Petr Vandrovec

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

IDE from current bk tree, UDMA and two channels...

Post by Alexander Vir » Sat, 03 Aug 2002 07:50:07



> You probably saw this. Looks like blocksize has been *ed somehow.
> Apparently Petr has a 1kB blocksize optical device..

Yeah - with partition boundaries set not on a physical sector boundary ;-/

He's actually lucky that beginning of partition was not in the middle of
a physical sector...

Looks like we need
        a) accurate hardsect_size for these beasts (which is a problem
with current setup, since it's per-queue and not per-device; master and
slave can have different hardsect sizes).
        b) extra check in check_partitions() that would verify that
partition doesn't end in the middle of a sector (and round it down
if it does).

Basically, old code worked by accident on that setup - Petr had half-Kb
in the end of partition unaccessible and do_open() didn't notice that.
Now it does and tries to give such access.  Disk is not happy...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://www.veryComputer.com/
Please read the FAQ at  http://www.veryComputer.com/

 
 
 

IDE from current bk tree, UDMA and two channels...

Post by Alexander Vir » Sat, 03 Aug 2002 08:00:07



> > Uh-oh...

> > Let me see if I got it straight:

> > a) your disk doesn't work with half-Kb requests
> > b) you have a partition with odd number of sectors
> > c) hardsect_size is set to half-Kb
> > d) old code worked since it rounded size to multiple of kilobyte.

> > Correct?

> Yes, exactly. Replacing disk is not an option...

OK.  At the very least we need a way for driver to tell what the sector
size is.  And that can be a problem - AFAICS IDE shares the queue for
master and slave and sector size is queue property.

BTW, what type of partition table do you have there?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

IDE from current bk tree, UDMA and two channels...

Post by Petr Vandrove » Sat, 03 Aug 2002 08:00:11




> > You probably saw this. Looks like blocksize has been *ed somehow.
> > Apparently Petr has a 1kB blocksize optical device..

Just to correct you: it is normal magnetic disk with 512 byte sectors,
from notebook. It works with 512B UDMA requests if we talk to the drive
slowly, with pauses here and there. If we talk to it back-to-back, it
dies. Apparently it forgets that it is doing UDMA transfers and tries
to do normal PIO or MDMA or what - host terminates transfer in the middle,
and disk is signaling that it has more data to go.

Quote:> Looks like we need
>     a) accurate hardsect_size for these beasts (which is a problem
> with current setup, since it's per-queue and not per-device; master and
> slave can have different hardsect sizes).
>     b) extra check in check_partitions() that would verify that
> partition doesn't end in the middle of a sector (and round it down
> if it does).

It will not help. Device is reporting 512B sectors, and it even supports
them in PIO.
                                            Petr Vandrovec

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://www.veryComputer.com/
Please read the FAQ at  http://www.veryComputer.com/

 
 
 

IDE from current bk tree, UDMA and two channels...

Post by Petr Vandrove » Sat, 03 Aug 2002 08:10:04




> > > Uh-oh...

> > > Let me see if I got it straight:

> > > a) your disk doesn't work with half-Kb requests
> > > b) you have a partition with odd number of sectors
> > > c) hardsect_size is set to half-Kb
> > > d) old code worked since it rounded size to multiple of kilobyte.

> > > Correct?

> > Yes, exactly. Replacing disk is not an option...

> OK.  At the very least we need a way for driver to tell what the sector
> size is.  And that can be a problem - AFAICS IDE shares the queue for
> master and slave and sector size is queue property.

> BTW, what type of partition table do you have there?

Normal DOS partition, with 512 byte block size, as this is 512B block
device, at least I believed to it until now. As start=63, it apparently
also handles 1024B requests on odd address (I believe that sfdisk -d dumps
start 0-based).

# partition table of /dev/hdc
unit: sectors

/dev/hdc1 : start=       63, size=12685617, Id=83, bootable
/dev/hdc2 : start=        0, size=       0, Id= 0
/dev/hdc3 : start=        0, size=       0, Id= 0
/dev/hdc4 : start=        0, size=       0, Id= 0

                                                      Petr Vandrovec

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

IDE from current bk tree, UDMA and two channels...

Post by Alexander Vir » Sat, 03 Aug 2002 08:10:07





> > > You probably saw this. Looks like blocksize has been *ed somehow.
> > > Apparently Petr has a 1kB blocksize optical device..

> Just to correct you: it is normal magnetic disk with 512 byte sectors,
> from notebook. It works with 512B UDMA requests if we talk to the drive
> slowly, with pauses here and there. If we talk to it back-to-back, it
> dies. Apparently it forgets that it is doing UDMA transfers and tries
> to do normal PIO or MDMA or what - host terminates transfer in the middle,
> and disk is signaling that it has more data to go.

_Ouch_.  Then I have to agree with Martin - it's a blacklist time.  There's
not much partition code could do with that - you really have a partition
with a chunk that _can't_ be handled by 1Kb request.

Old code (pretty much by accident) hid it from you, so I'd suggest just
decrementing partition size - it's not that you had anything in that last
half-Kb.  At least nothing that could be accessed by old kernels.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://www.veryComputer.com/
Please read the FAQ at  http://www.veryComputer.com/

 
 
 

IDE from current bk tree, UDMA and two channels...

Post by Alexander Vir » Sat, 03 Aug 2002 08:10:08



> Normal DOS partition, with 512 byte block size, as this is 512B block
> device, at least I believed to it until now. As start=63, it apparently
> also handles 1024B requests on odd address (I believe that sfdisk -d dumps
> start 0-based).

> # partition table of /dev/hdc
> unit: sectors

> /dev/hdc1 : start=       63, size=12685617, Id=83, bootable

Blacklist time.  That, or decrementing size to 12675616, depending on whether
you want that last half-Kb or not.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

IDE from current bk tree, UDMA and two channels...

Post by Petr Vandrove » Sat, 03 Aug 2002 08:20:05




> > Normal DOS partition, with 512 byte block size, as this is 512B block
> > device, at least I believed to it until now. As start=63, it apparently
> > also handles 1024B requests on odd address (I believe that sfdisk -d dumps
> > start 0-based).

> > # partition table of /dev/hdc
> > unit: sectors

> > /dev/hdc1 : start=       63, size=12685617, Id=83, bootable

> Blacklist time.  That, or decrementing size to 12675616, depending on whether
> you want that last half-Kb or not.

Last half-KB is useless, as filesystem on it is ext2 with 4KB blocks...
Only problem is that previously stable system was now dying in e2fsck. I'll
try to invent some solution before 2.6 ;-)

Maybe fix to e2fsck would be sufficient, I always thought that it reads disk
in blocksize (4KB) chunks, so disk will not see 512B request. But
apparently it either reads partition in 512B chunks, or block layer does not
do merging correctly.
                                                Petr Vandrovec

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/