Linux ATA/IDE development
 help / color / mirror / Atom feed
From: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
To: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
	Paul Osmialowski <newchief@king.net.pl>
Cc: Andrew Morton <akpm@osdl.org>, linux-ide@vger.kernel.org
Subject: Re: Fw: [Bugme-new] [Bug 1340] New: small FAT32 partitions cannot be used properly
Date: Sun, 12 Oct 2003 21:45:01 +0200	[thread overview]
Message-ID: <200310122145.02048.bzolnier@elka.pw.edu.pl> (raw)
In-Reply-To: <87zng6iass.fsf@devron.myhome.or.jp>


Hi

Can you try this patch?
It should fix problem 1.  I don't have idea about 2. yet.

The problem is that hwif->ide_dma_on() is in the wrong place in
piix_config_drive_xfer_rate() (btw. this problem is present not only in piix
driver because of sick code duplication) and will be called for devices which
don't support IORDY flow control for PIO (thus only PIO0/1/2 available).

thanks,
--bartomiej


 drivers/ide/pci/piix.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletion(-)

diff -puN drivers/ide/pci/piix.c~ide-piix-no_iordy_pio-fix drivers/ide/pci/piix.c
--- linux-2.6.0-test7/drivers/ide/pci/piix.c~ide-piix-no_iordy_pio-fix	2003-10-12 21:25:44.630823664 +0200
+++ linux-2.6.0-test7-root/drivers/ide/pci/piix.c	2003-10-12 21:28:35.084910704 +0200
@@ -588,13 +588,15 @@ try_dma_modes:
 		} else {
 			goto fast_ata_pio;
 		}
+		return hwif->ide_dma_on(drive);
 	} else if ((id->capability & 8) || (id->field_valid & 2)) {
 fast_ata_pio:
 no_dma_set:
 		hwif->tuneproc(drive, 255);
 		return hwif->ide_dma_off_quietly(drive);
 	}
-	return hwif->ide_dma_on(drive);
+	/* IORDY not supported */
+	return 0;
 }
 
 /**

_


On Sunday 12 of October 2003 20:13, OGAWA Hirofumi wrote:
> Hi,
>
> Paul, thanks a lot for test.
>
> Andrew, this looks like IDE bug with PIO-mode. So could you please
> handle the bugzilla? I don't know about bugzilla.
>
> Bartlomiej, are you interesting the following problem? Any idea?
>
> Paul Osmialowski <newchief@king.net.pl> writes:
> > Dear Ogawa!
> >   I did more test and I discovered:
> > 1. DriveReady SeekComplete Error was always present and DMA was disabled.
> > 2. Whenever I connected CF disk alone (as master or slave) I WAS ABLE
> > TO MOUNT THIS PARTITION IN READ/WRITE MODE!!! That's the solution for
> > now.
> > 3. Whenever I connected CF disk as slave with ATAPI disk as master I
> > couldn't mount this partition properly.
> > 4. I was always able to read boot sector using fdisk.
> >
> > The problem is with operating CF TrueIDE disk as a slave. I'm not sure
> > but I think I didn't try to mount this partition when I was using CF
> > disk alone (no master or slave on the same cable), so I was quite
> > surprised when I saw no dmesg error messages after such mount.
> > The problem should be fixed anyway, since it's not present on M$
> > Windows. It may be caused by some piece of code written for Compact
> > Flash volumes, since they're mentioned in dmesg as CFA DISK drive
> > while other HDD's are mentioned as ATA DISK drive.
> >   Since I'm new to bugzilla I'd like to ask you to redirect my problem
> > report to proper section of kernel developers. Two issues are
> > important:
> > 1. DriveReady SeekComplete Error message in dmesg and DMA disabled (I
> > think CFs are PIO-only anyway).
> > 2. Partitions cannot be mounted properly when CF is used as a slave
> > with other drive on the same cable (i.e. hdb with hda present).
> > Greetings,
> > Paul
> >
> > Uz.ytkownik OGAWA Hirofumi napisa?:
> > > Paul Osmialowski <newchief@king.net.pl> writes:
> > >>hdb: max request size: 128KiB
> > >>hdb: 125952 sectors (64 MB) w/1KiB Cache, CHS=246/16/32, BUG
> > >>  hdb:hdb: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> > >>hdb: dma_intr: error=0x00 { }
> > >>hdb: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> > >>hdb: dma_intr: error=0x00 { }
> > >>hdb: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> > >>hdb: dma_intr: error=0x00 { }
> > >>hdb: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> > >>hdb: dma_intr: error=0x00 { }
> > >>hda: DMA disabled
> > >>hdb: DMA disabled
> > >>ide0: reset: success
> > >
> > > Um. Looks like hdb has hardware or driver(PIO-mode) problem.
> > > Could you test with /dev/hdb1? If it has corruption problem,
> > > completely not filesystem layer bug. So it should goes to IDE
> > > maintainer.
> > > Thanks.
> >
> > From: Paul Osmialowski <newchief@king.net.pl>
> > Subject: Re: Fw: [Bugme-new] [Bug 1340] New: small FAT32 partitions
> > cannot be used properly
> > To: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
> > Date: Sun, 12 Oct 2003 13:50:35 +0200
> > User-Agent: Mozilla/5.0 (X11; U; Linux i686; PL; rv:1.4) Gecko/20030704
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >
> > Hello Ogawa!
> >   I've checked twice everything and I've noticed, that problem is
> > somewhere else. I should have done that before I've wrote anything to
> > bugzilla, it's my fault, sorry.
> >   First. Hardware background of the problem. To do the test I used my PC:
> > - popular Microstar motherboard 845PE Max2 with Pentium IV 1.7GHz
> > - 64MB CompactFlash connected as TrueIDE through CF-25 and IDE25-35
> > connectors made by Port80h (http://www.port80h.com.pl/cf25.html,
> > http://www.port80h.com.pl/ide35_hdd25.html), once as a slave
> > (/dev/hdb) with 60GB Seagate disk as a master, once alone as a master
> > (/dev/hdc). Also I was switching on/off BIOS Setup option "Use 32-bit
> > transfer mode" - it didn't make any differences. (CF-25 internally is
> > something like that: http://213.25.10.65/~newchief/2.6/IDE-CF.gif with
> > exception that it can work only in +5V mode, which is acceptable for
> > most of compactflash cards).
> >   Second. Why I assumed it's FAT module problem:
> > - fdisk on both Linux and Windows can see and create partitions properly
> > - mkdosfs can create FAT32 filesystem without any warnings (Windows
> > create only FAT16, since it has no -F parameter and consequently
> > cannot create FAT32 on partition smaller than 512MB)
> > - After creating FAT32 filesystem on Linux using mkdosfs -F32 I was
> > able to operate it without any problem on Windows98 so I assumed Linux
> > can't operate non-standard FAT partition properly. I didn't check
> > kernel code, I looked at filesystem internals and I've found only one
> > non-standard thing: one sector per cluster (while smallest standard
> > cluster is 8 sectors).
> > At that point I wrote to bugzilla.
> >   Finally. After reading your mail I've checked twice dmesg (you can
> > see it here: http://213.25.10.65/~newchief/2.6/dmesg.txt) (how could I
> > forget to do that before?) and I've found:
> >
> > hdb: max request size: 128KiB
> > hdb: 125952 sectors (64 MB) w/1KiB Cache, CHS=246/16/32, BUG
> >   hdb:hdb: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> > hdb: dma_intr: error=0x00 { }
> > hdb: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> > hdb: dma_intr: error=0x00 { }
> > hdb: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> > hdb: dma_intr: error=0x00 { }
> > hdb: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> > hdb: dma_intr: error=0x00 { }
> > hda: DMA disabled
> > hdb: DMA disabled
> > ide0: reset: success
> >
> > Gosh! It switched off DMA for both of my HDD! (hda, hdb). I suspect
> > Microstars 845PE Max2 MB has problems with DMA, sometimes music on
> > xmms (SB Live!) stops for a short while when disk I/O works heavy
> > (RedHat9, 2.4.20 kernel with lots of RedHat patches that makes it
> > closer to 2.6 line).
> > You can also read hdparm -i /dev/hdb output
> > (http://213.25.10.65/~newchief/2.6/hdparm-i.txt) and hdparm /dev/hdb
> > output (http://213.25.10.65/~newchief/2.6/hdparm.txt), both made while
> > using 2.6.0-test7-bk3.
> > Maybe TrueIDE protocol of comact flash isn't so true? Anyway, how can
> > it work properly on Windows9x then? And why boot sector is accessed
> > properly? Why BIOS Setup discovers disk right way (and says it's
> > LBA-compatible)?
> > I was also able to operate properly this 64MB card with non-PC device
> > that is able to operate FAT32 and it worked fine (I've put it in place
> > of 2.5'' 20GB HDD that was used by default, again I used CF-25 to do
> > that).


  reply	other threads:[~2003-10-12 19:41 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20031010081436.7652c427.akpm@osdl.org>
     [not found] ` <87llrrty3z.fsf@devron.myhome.or.jp>
     [not found]   ` <3F89400B.5020607@king.net.pl>
     [not found]     ` <87brsm8tg6.fsf@devron.myhome.or.jp>
     [not found]       ` <3F898EEA.6090907@king.net.pl>
2003-10-12 18:13         ` Fw: [Bugme-new] [Bug 1340] New: small FAT32 partitions cannot be used properly OGAWA Hirofumi
2003-10-12 19:45           ` Bartlomiej Zolnierkiewicz [this message]
2003-10-12 19:51           ` Andrew Morton

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=200310122145.02048.bzolnier@elka.pw.edu.pl \
    --to=b.zolnierkiewicz@elka.pw.edu.pl \
    --cc=akpm@osdl.org \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=linux-ide@vger.kernel.org \
    --cc=newchief@king.net.pl \
    /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