uncorrectable ext2 errors

uncorrectable ext2 errors

[Jan Niehusmann]

Hi!

A few days ago, I reported some problems with a ext2 filesystem which I
cannot repair with e2fsck. Now I got some new observations.

To summarize the problem: e2fsck reports block bitmap differences, but
telling it to repair these doesn't help, another e2fsck run reports the
same differences.

Now I took a copy of the metadata with e2image -r, and ran e2fsck on
that. Surprisingly, now e2fsck was able to repair the differences.

With this corrected filesystem, I took a look at what e2fsck did change
on the filesystem. Interestingly, the errors are very systematic. It's
mainly sequences of 4096 bytes which should be all 255, but are
3,0,0,0,300,7,0,... (rest are 0s). These blocks start at the following 
positions:

6630000001
6638000001
6640000001
6648000001
6748000001
6750000001
6758000001
6760000001
6768000001
6790000001
6798000001
67A0000001
67A8000001
67B0000001
67B8000001
67C0000001
67C8000001
67D0000001
67D8000001
67E0000001
67E8000001

To me, this looks like some strange problem in a layer below the
filesystem. So it may be LVM, ide, promise ide driver, or a hardware
fault.

Do you have any idea how to further diagnose this?

Jan

Re: uncorrectable ext2 errors

[Andreas Dilger]

On Aug 06, 2003  17:03 +0200, Jan Niehusmann wrote:
> A few days ago, I reported some problems with a ext2 filesystem which I
> cannot repair with e2fsck. Now I got some new observations.
> 
> To summarize the problem: e2fsck reports block bitmap differences, but
> telling it to repair these doesn't help, another e2fsck run reports the
> same differences.

Is this the root filesystem that is being checked?  If yes, then you
probably need to either reboot after the fsck is complete (before
mounting RW), or run the fsck from a rescue disk/CD.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: uncorrectable ext2 errors

[Jan Niehusmann]

On Wed, Aug 06, 2003 at 11:06:34AM -0600, Andreas Dilger wrote:
> Is this the root filesystem that is being checked?  If yes, then you
> probably need to either reboot after the fsck is complete (before
> mounting RW), or run the fsck from a rescue disk/CD.

No, it's not the root filesystem, but I usually check it while it's
mounted r/o, because the check takes nearly an hour and I want to give
the users at least read access to their files.

But because I assumed that this may cause problems, I did try it with a
completly unmonted filesystem once, without success.

Can you explain how a r/o mounted file system can cause problems?
Perhaps there is still some connection to my problem.

Jan

Re: uncorrectable ext2 errors

[Mike Fedyk]

On Wed, Aug 06, 2003 at 08:38:22PM +0200, Jan Niehusmann wrote:
> Can you explain how a r/o mounted file system can cause problems?
> Perhaps there is still some connection to my problem.

No it shouldn't cause problems, only that you should umount the filesystem
before you mount it read/write because the fsck might have changed
something, and the kernel will have the old information still in memory, and
might cause MORE corruption, than before.

So, just umount after fsck and you should be set (at least for that part)...

Re: uncorrectable ext2 errors

[Jan Niehusmann]

On Wed, Aug 06, 2003 at 05:03:35PM +0200, Jan Niehusmann wrote:
> 3,0,0,0,300,7,0,... (rest are 0s). These blocks start at the following 
> positions:
> 
> 6630000001
> 6638000001
[...]

Small but important correction: make all these positions
6630000000
6638000000
[...]

I was unaware that cmp -l starts counting at 1 instead of 0...

Jan

Re: uncorrectable ext2 errors

[Jan Niehusmann]

On Wed, Aug 06, 2003 at 05:03:35PM +0200, Jan Niehusmann wrote:
> To summarize the problem: e2fsck reports block bitmap differences, but
> telling it to repair these doesn't help, another e2fsck run reports the
> same differences.

Now I pvmoved one PE which contains areas of the filesystem with errors
to a different drive. Surprise: e2fsck is now able to correct these
errors. Block bitmap differences in other PEs are still not fixed.

This strengthens my assumption that this is not a e2fsck problem, but
an LVM or IDE one.

Are there any known problems with huge hard disks (250GB) on Promise
IDE?

Jan

LBA48 on Promise 20265

[Jan Niehusmann]

On Thu, Aug 07, 2003 at 01:06:41PM +0200, Jan Niehusmann wrote:
> Are there any known problems with huge hard disks (250GB) on Promise
> IDE?

Further investigating this, I found the following posting:
http://lkml.org/lkml/2002/9/6/22

And indeed, even with 2.4.21, /proc/ide/ide2/hdf/settings shows that
'address' is 0, meaning that LBA48 is turned of, if I understand this
correctly. But that would mean that a 250GB hard disk should not work as
expected, right? May that explain my disk corruption problems?

Jan

Re: uncorrectable ext2 errors

[Andries Brouwer]

On Thu, Aug 07, 2003 at 01:06:41PM +0200, Jan Niehusmann wrote:

> Are there any known problems with huge hard disks (250GB) on
> Promise IDE?

Funny. Just yesterday or so I was going through old IDE notes
and discarding all that was outdated. Quoting from memory:

Andre: PDC 20265 pukes in 48-bit DMA clean in PIO primary -
secondary is OK.

Last September or so there was a long discussion about a
filesystem that was destroyed. But what I recall is that
in the end it turned out not to be a hardware problem,
but a precedence problem - two missing parentheses in the driver.

Google will tell you all, I suppose. Search for Promise and Isely.

Re: uncorrectable ext2 errors

[Jan Niehusmann]

On Thu, Aug 07, 2003 at 11:12:36PM +0200, Andries Brouwer wrote:
> Last September or so there was a long discussion about a
> filesystem that was destroyed. But what I recall is that
> in the end it turned out not to be a hardware problem,
> but a precedence problem - two missing parentheses in the driver.
> 
> Google will tell you all, I suppose. Search for Promise and Isely.

Yes, thanks, I found these mails, and they may describe exactly the 
symptoms I saw on my server. So perhaps the fixes have not been
(correctly) applied?

I only saw the mails from Mike Isely, but no 'official' response. Do you
remember if the patches got accepted by one of the maintainers? Andre?

Jan

Re: uncorrectable ext2 errors

[Andries Brouwer]

On Sun, Aug 10, 2003 at 10:55:13PM +0200, Jan Niehusmann wrote:
> On Thu, Aug 07, 2003 at 11:12:36PM +0200, Andries Brouwer wrote:
> > Last September or so there was a long discussion about a
> > filesystem that was destroyed. But what I recall is that
> > in the end it turned out not to be a hardware problem,
> > but a precedence problem - two missing parentheses in the driver.
> > 
> > Google will tell you all, I suppose. Search for Promise and Isely.
> 
> Yes, thanks, I found these mails, and they may describe exactly the 
> symptoms I saw on my server. So perhaps the fixes have not been
> (correctly) applied?
> 
> I only saw the mails from Mike Isely, but no 'official' response. Do you
> remember if the patches got accepted by one of the maintainers? Andre?

I see no kernel version in your post, that would be the first thing
of interest. Next, look at this addressing variable via /proc.
It it is zero, then you are hit by something avoided by the patch
I sketched yesterday evening or so. Otherwise we must look further.

It looks like all your corrupted places are at a multiple of 2^27.

Also, I see that you do e2fsck on a mounted filesystem. Terrible.

Andries

Re: uncorrectable ext2 errors

[Jan Niehusmann]

On Sun, Aug 10, 2003 at 11:19:55PM +0200, Andries Brouwer wrote:
> I see no kernel version in your post, that would be the first thing
> of interest. Next, look at this addressing variable via /proc.

Sorry - I mentioned it in an earlier post with a different subject. It's
plain 2.4.21. 

> It it is zero, then you are hit by something avoided by the patch
> I sketched yesterday evening or so. Otherwise we must look further.

It is 0, yes. May it be caused by the following lines in pdc202xx_old.c?

        if (hwif->pci_dev->device == PCI_DEVICE_ID_PROMISE_20265)
                hwif->addressing = (hwif->channel) ? 0 : 1;

> Also, I see that you do e2fsck on a mounted filesystem. Terrible.

:-)
I know. But it's mounted read only, and to be sure I tried it without
mounting the file system, as well. 
But the most important prove that it's not a fs problem is that writing
to one partition changed contents of a different partition.

Jan

Re: uncorrectable ext2 errors

[Andries Brouwer]

On Sun, Aug 10, 2003 at 11:34:50PM +0200, Jan Niehusmann wrote:
> On Sun, Aug 10, 2003 at 11:19:55PM +0200, Andries Brouwer wrote:

> Sorry - I mentioned it in an earlier post with a different subject. It's
> plain 2.4.21. 
> 
> > It it is zero, then you are hit by something avoided by the patch
> > I sketched yesterday evening or so.
> 
> It is 0, yes. May it be caused by the following lines in pdc202xx_old.c?
> 
>         if (hwif->pci_dev->device == PCI_DEVICE_ID_PROMISE_20265)
>                 hwif->addressing = (hwif->channel) ? 0 : 1;

OK. So, this means that you cannot access past the 2^28 sector boundary.

So, you can address at most 137 GB of your disk.

Did you say that it was 250 GB?

Re: uncorrectable ext2 errors

[Jan Niehusmann]

On Sun, Aug 10, 2003 at 11:58:34PM +0200, Andries Brouwer wrote:
> OK. So, this means that you cannot access past the 2^28 sector boundary.
> 
> So, you can address at most 137 GB of your disk.
> 
> Did you say that it was 250 GB?

Exactly. And it's reported as 250GB, and I can access parts of the disk
behind the 137 GB limit without an error message, but it looks like
writing to these parts, it silently overwrites content at the beginning
of the drive. Like it just discards the upper bits of the address or
something like that.

Jan

IDE bug - was: Re: uncorrectable ext2 errors

[Andries Brouwer]

On Mon, Aug 11, 2003 at 12:10:20AM +0200, Jan Niehusmann wrote:
> On Sun, Aug 10, 2003 at 11:58:34PM +0200, Andries Brouwer wrote:
> > OK. So, this means that you cannot access past the 2^28 sector boundary.
> > 
> > So, you can address at most 137 GB of your disk.
> > 
> > Did you say that it was 250 GB?
> 
> Exactly. And it's reported as 250GB, and I can access parts of the disk
> behind the 137 GB limit without an error message, but it looks like
> writing to these parts, it silently overwrites content at the beginning
> of the drive. Like it just discards the upper bits of the address or
> something like that.

Yes, that it what it does.

Look at my post from yesterday or so with Subject: [PATCH sketch] More IDE stuff

ide-disk.c: __ide_do_rw_disk() issues read/write requests to the disk.
It does

        if (drive->addressing == 1)             /* 48-bit LBA */
                return lba_48_rw_disk(drive, rq, (unsigned long long) block);
        if (drive->select.b.lba)                /* 28-bit LBA */
                return lba_28_rw_disk(drive, rq, (unsigned long) block);
        return chs_rw_disk(drive, rq, (unsigned long) block);

with checking the size of block.
And init_idedisk_capacity() does not check addressing.

In my above post I gave a patch for 2.6.0-test3.
But the IDE code for 2.4 and 2.6 is very similar, so the patch, once applied
to 2.6 should also be backported to 2.4.

Andries

Re: IDE bug - was: Re: uncorrectable ext2 errors

[Alan Cox]

On Sul, 2003-08-10 at 23:33, Andries Brouwer wrote:
>         if (drive->addressing == 1)             /* 48-bit LBA */
>                 return lba_48_rw_disk(drive, rq, (unsigned long long) block);
>         if (drive->select.b.lba)                /* 28-bit LBA */
>                 return lba_28_rw_disk(drive, rq, (unsigned long) block);
>         return chs_rw_disk(drive, rq, (unsigned long) block);
> 
> with checking the size of block.
> And init_idedisk_capacity() does not check addressing.

It should also issue LBA28 if the size of th range and the end block
fall under the LBA28 limit because thst saves you valuable I/O time.

Jens had patches for that but I don't know where they went in 2.6

Re: IDE bug - was: Re: uncorrectable ext2 errors

[Bartlomiej Zolnierkiewicz]

On Tuesday 12 of August 2003 17:36, Alan Cox wrote:
> On Sul, 2003-08-10 at 23:33, Andries Brouwer wrote:
> >         if (drive->addressing == 1)             /* 48-bit LBA */
> >                 return lba_48_rw_disk(drive, rq, (unsigned long long)
> > block); if (drive->select.b.lba)                /* 28-bit LBA */ return
> > lba_28_rw_disk(drive, rq, (unsigned long) block); return
> > chs_rw_disk(drive, rq, (unsigned long) block);
> >
> > with checking the size of block.
> > And init_idedisk_capacity() does not check addressing.
>
> It should also issue LBA28 if the size of th range and the end block
> fall under the LBA28 limit because thst saves you valuable I/O time.

Yep, but its other issue.

> Jens had patches for that but I don't know where they went in 2.6

Jens and me agreed that they should be included after taskfile IO
is integrated as the only IO path.  Otherwise there are too many
corner cases to deal with.

--bartlomiej

Re: IDE bug - was: Re: uncorrectable ext2 errors

[Andries Brouwer]

On Tue, Aug 12, 2003 at 04:36:08PM +0100, Alan Cox wrote:
> On Sul, 2003-08-10 at 23:33, Andries Brouwer wrote:
> >         if (drive->addressing == 1)             /* 48-bit LBA */
> >                 return lba_48_rw_disk(drive, rq, (unsigned long long) block);
> >         if (drive->select.b.lba)                /* 28-bit LBA */
> >                 return lba_28_rw_disk(drive, rq, (unsigned long) block);
> >         return chs_rw_disk(drive, rq, (unsigned long) block);
> > 
> > with checking the size of block.
> > And init_idedisk_capacity() does not check addressing.

> It should also issue LBA28 if the size of th range and the end block
> fall under the LBA28 limit because thst saves you valuable I/O time.
> 
> Jens had patches for that but I don't know where they went in 2.6

That is something different. The patches I gave (I gave patches didnt I?)
limit the total capacity for large disks if the controller doesnt speak lba48.

That is necessary to avoid very unpleasant surprises.

But saving some time during I/O, yes, maybe I suggested Jens what to do
and he did it. Hmm. I don't see the code anymore.
Google(Jens Andries rq_lba48) gives the patch.
Ah, I see. His patch went in - I see Changeset 1.1046.31.30 if that
means anything, - and Bartlomiej asked for it to be reverted again.
So, Jens's patches are lost for the moment. Must remember to resurrect them.

Re: IDE bug - was: Re: uncorrectable ext2 errors

[Bartlomiej Zolnierkiewicz]

On Wednesday 13 of August 2003 00:50, Andries Brouwer wrote:
> On Tue, Aug 12, 2003 at 04:36:08PM +0100, Alan Cox wrote:
> > On Sul, 2003-08-10 at 23:33, Andries Brouwer wrote:
> > >         if (drive->addressing == 1)             /* 48-bit LBA */
> > >                 return lba_48_rw_disk(drive, rq, (unsigned long long)
> > > block); if (drive->select.b.lba)                /* 28-bit LBA */ return
> > > lba_28_rw_disk(drive, rq, (unsigned long) block); return
> > > chs_rw_disk(drive, rq, (unsigned long) block);
> > >
> > > with checking the size of block.
> > > And init_idedisk_capacity() does not check addressing.
> >
> > It should also issue LBA28 if the size of th range and the end block
> > fall under the LBA28 limit because thst saves you valuable I/O time.
> >
> > Jens had patches for that but I don't know where they went in 2.6
>
> That is something different. The patches I gave (I gave patches didnt I?)
> limit the total capacity for large disks if the controller doesnt speak
> lba48.

No, you didn't.  You gave some whining and patch sketch. :-)

> That is necessary to avoid very unpleasant surprises.
>
> But saving some time during I/O, yes, maybe I suggested Jens what to do
> and he did it. Hmm. I don't see the code anymore.
> Google(Jens Andries rq_lba48) gives the patch.
> Ah, I see. His patch went in - I see Changeset 1.1046.31.30 if that
> means anything, - and Bartlomiej asked for it to be reverted again.
> So, Jens's patches are lost for the moment. Must remember to resurrect
> them.

...when taskfile IO is the only IO path not earlier.

Jan, did removing offending lines from pdc202xx_old.c help?

--bartlomiej

Re: IDE bug - was: Re: uncorrectable ext2 errors

[Jan Niehusmann]

On Wed, Aug 13, 2003 at 02:21:26AM +0200, Bartlomiej Zolnierkiewicz wrote:
> Jan, did removing offending lines from pdc202xx_old.c help?

I do not want to try it on our server, but I have a similar mainboard
and just bought a 160GB harddisk to try it on another computer.

Unfortunately, it doesn't seem to work well. The hard disk only gives
20MB/s on sequential read (Seagate Baraccuda 160GB should be faster,
right?), and hdparm -I /dev/hde completely locks up the whole computer -
no console message at all, only hard reset helps. I need to get this
running before I can try kernel patches for the LBA48 stuff.

By the way: That computer reports a
00:11.0 RAID bus controller: Promise Technology, Inc. 20265 (rev 02)
while the server has a 
00:11.0 Unknown mass storage controller: Promise Technology, Inc. 20265 (rev 02)

(Numeric Class IDs are 0104 and respectively 0180, vendor and device 
codes are the same on both computers)

Do you think this will make any difference? IIRC, the FastTrack series
has some RAID features, but you can safely ignore them and use it
just as a simple ATA100 controller.

Jan

Re: IDE bug - was: Re: uncorrectable ext2 errors

[Jan Niehusmann]

On Wed, Aug 13, 2003 at 10:03:09AM +0200, Jan Niehusmann wrote:
> right?), and hdparm -I /dev/hde completely locks up the whole computer -

Looks like this problem has been described here:
http://marc.theaimsgroup.com/?l=linux-kernel&m=104250818527780&w=2

I'll try the patch this evening...

Why does promise IDE always have some strange problems?

Jan

Re: IDE bug - was: Re: uncorrectable ext2 errors

[Alan Cox]

> Unfortunately, it doesn't seem to work well. The hard disk only gives
> 20MB/s on sequential read (Seagate Baraccuda 160GB should be faster,
> right?), and hdparm -I /dev/hde completely locks up the whole computer -
> no console message at all, only hard reset helps. I need to get this
> running before I can try kernel patches for the LBA48 stuff.

That sounds about right for UDMA33, which is what you'd get without the
fix I sent Marcelo a few days ago

Re: IDE bug - was: Re: uncorrectable ext2 errors

[Jan Niehusmann]

[-- Attachment #1: Type: text/plain, Size: 578 bytes --]

On Wed, Aug 13, 2003 at 12:16:09PM +0100, Alan Cox wrote:
> That sounds about right for UDMA33, which is what you'd get without the
> fix I sent Marcelo a few days ago

But I've not yet patched the kernel, and while booting it says:

Aug 13 09:13:59 sirith kernel: hde: 312581808 sectors (160042 MB) w/8192KiB Cache, CHS=19457/255/63, UDMA(100)

hdparm -i also says:
 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 

So I think it should use UDMA(100), which should give more than 20MB/s
(Seagate says the drive does 32-58MB/s sustained transfer rate)


Jan


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: IDE bug - was: Re: uncorrectable ext2 errors

[Jan Niehusmann]

On Wed, Aug 13, 2003 at 01:20:05PM +0200, Jan Niehusmann wrote:
> On Wed, Aug 13, 2003 at 12:16:09PM +0100, Alan Cox wrote:
> > That sounds about right for UDMA33, which is what you'd get without the
> > fix I sent Marcelo a few days ago
> 
> But I've not yet patched the kernel, and while booting it says:

Ah sorry, I just had a look at the patch, and it seems like I'd get
UDMA33 even though UDMA100 is reported, without that patch. So yes, this
explains the slow speed.

Jan

Re: IDE bug - was: Re: uncorrectable ext2 errors

[Jan Niehusmann]

On Wed, Aug 13, 2003 at 12:16:09PM +0100, Alan Cox wrote:
> That sounds about right for UDMA33, which is what you'd get without the
> fix I sent Marcelo a few days ago

You meant the .id -> .present change, right? I applied this patch, and
still get only 20MB/s.

But I also have some good news: The patch by Ross Biro, available from
http://marc.theaimsgroup.com/?l=linux-kernel&m=104250818527780&w=2
actually fixed the hdparm -I crash.

Jan

Re: IDE bug - was: Re: uncorrectable ext2 errors

[Alan Cox]

On Mer, 2003-08-13 at 17:31, Jan Niehusmann wrote:
> But I also have some good news: The patch by Ross Biro, available from
> http://marc.theaimsgroup.com/?l=linux-kernel&m=104250818527780&w=2
> actually fixed the hdparm -I crash.

Thanks I'd missed that bug fix somehow

Re: IDE bug - was: Re: uncorrectable ext2 errors

[Bartlomiej Zolnierkiewicz]

On Wednesday 13 of August 2003 10:03, Jan Niehusmann wrote:
>
> By the way: That computer reports a
> 00:11.0 RAID bus controller: Promise Technology, Inc. 20265 (rev 02)
> while the server has a
> 00:11.0 Unknown mass storage controller: Promise Technology, Inc. 20265
> (rev 02)
>
> (Numeric Class IDs are 0104 and respectively 0180, vendor and device
> codes are the same on both computers)
>
> Do you think this will make any difference? IIRC, the FastTrack series
> has some RAID features, but you can safely ignore them and use it
> just as a simple ATA100 controller.

Just remember to say Y to "Special FastTrak feature".

--bartlomiej

Re: IDE bug - was: Re: uncorrectable ext2 errors

[Andries Brouwer]

On Wed, Aug 13, 2003 at 02:21:26AM +0200, Bartlomiej Zolnierkiewicz wrote:

> > That is something different. The patches I gave (I gave patches didnt I?)
> > limit the total capacity for large disks if the controller doesnt speak
> > lba48.
> 
> No, you didn't.  You gave some whining and patch sketch. :-)

Ah, yes, it was that one. Yes, my patch turned into a mess of rejects
after your layout changes of earlier patches from that series.
But that does not matter in the least. You are intelligent,
careful and precise, will not have any problem reconstructing
the correct patch from my detailed description.

Re: IDE bug - was: Re: uncorrectable ext2 errors

[Jan Niehusmann]

On Wed, Aug 13, 2003 at 03:27:33PM +0200, Andries Brouwer wrote:
> Ah, yes, it was that one. Yes, my patch turned into a mess of rejects
> after your layout changes of earlier patches from that series.

Here is the most important part (limiting the disk capacity to 137GB if
LBA48 is not available) as a patch agains 2.4.21. The goto is not nice,
but I didn't want to do a major rewrite. 

Note that the function contains a bogous if-clause:

	if (id->cfs_enable_2 & 0x0400) {
	[...]
		return;
	} 
	[...]
	if ((id->command_set_2 & 0x0400) && (id->cfs_enable_2 & 0x0400)) {
	[...]

The second if-condition can never be true. But I didn't want to touch
that stuff.

--- linux-2.4.21/drivers/ide/ide-disk.c.orig	2003-08-13 23:14:32.000000000 +0200
+++ linux-2.4.21/drivers/ide/ide-disk.c	2003-08-13 23:14:34.000000000 +0200
@@ -1196,7 +1196,7 @@
 		drive->bios_cyl		= drive->cyl;
 		drive->capacity48	= capacity_2;
 		drive->capacity		= (unsigned long) capacity_2;
-		return;
+		goto check_capacity48;
 	/* Determine capacity, and use LBA if the drive properly supports it */
 	} else if ((id->capability & 2) && lba_capacity_is_ok(id)) {
 		capacity = id->lba_capacity;
@@ -1228,6 +1228,15 @@
 		drive->sect = 63;
 		drive->cyl = (unsigned long)(drive->capacity48) / (drive->head * drive->sect);
 	}
+
+check_capacity48:
+	/* Limit disk size to 137GB if LBA48 addressing is not supported */
+	if (drive->addressing == 0 && drive->capacity48 > (1ULL)<<28) {
+		printk("%s: cannot use LBA48 - capacity reset "
+			"from %llu to %llu\n",
+			drive->name, drive->capacity48, (1ULL)<<28);
+		drive->capacity48 = (1ULL)<<28;
+	}
 }
 
 static unsigned long idedisk_capacity (ide_drive_t *drive)

Re: IDE bug - was: Re: uncorrectable ext2 errors

[Bartlomiej Zolnierkiewicz]

On Thursday 14 of August 2003 00:05, Jan Niehusmann wrote:
> On Wed, Aug 13, 2003 at 03:27:33PM +0200, Andries Brouwer wrote:
> > Ah, yes, it was that one. Yes, my patch turned into a mess of rejects
> > after your layout changes of earlier patches from that series.
>
> Here is the most important part (limiting the disk capacity to 137GB if
> LBA48 is not available) as a patch agains 2.4.21. The goto is not nice,
> but I didn't want to do a major rewrite.

Major rewrite is already present in 2.6.0-test3 and there is more to go.

> Note that the function contains a bogous if-clause:
>
> 	if (id->cfs_enable_2 & 0x0400) {
> 	[...]
> 		return;
> 	}
> 	[...]
> 	if ((id->command_set_2 & 0x0400) && (id->cfs_enable_2 & 0x0400)) {
> 	[...]
>
> The second if-condition can never be true. But I didn't want to touch
> that stuff.

Already removed from 2.6.

> --- linux-2.4.21/drivers/ide/ide-disk.c.orig	2003-08-13 23:14:32.000000000
> +0200 +++ linux-2.4.21/drivers/ide/ide-disk.c	2003-08-13 23:14:34.000000000
> +0200 @@ -1196,7 +1196,7 @@
>  		drive->bios_cyl		= drive->cyl;
>  		drive->capacity48	= capacity_2;
>  		drive->capacity		= (unsigned long) capacity_2;
> -		return;
> +		goto check_capacity48;
>  	/* Determine capacity, and use LBA if the drive properly supports it */
>  	} else if ((id->capability & 2) && lba_capacity_is_ok(id)) {
>  		capacity = id->lba_capacity;
> @@ -1228,6 +1228,15 @@
>  		drive->sect = 63;
>  		drive->cyl = (unsigned long)(drive->capacity48) / (drive->head *
> drive->sect); }
> +
> +check_capacity48:
> +	/* Limit disk size to 137GB if LBA48 addressing is not supported */
> +	if (drive->addressing == 0 && drive->capacity48 > (1ULL)<<28) {
> +		printk("%s: cannot use LBA48 - capacity reset "
> +			"from %llu to %llu\n",
> +			drive->name, drive->capacity48, (1ULL)<<28);
> +		drive->capacity48 = (1ULL)<<28;
> +	}
>  }
>
>  static unsigned long idedisk_capacity (ide_drive_t *drive)

Yep, thats basically it.

Have you already tried doing LBA-48 as previously suggested
(after applying hang-fix of course)?

--bartlomiej

Re: IDE bug - was: Re: uncorrectable ext2 errors

[Jan Niehusmann]

On Wed, Aug 13, 2003 at 02:21:26AM +0200, Bartlomiej Zolnierkiewicz wrote:
> Jan, did removing offending lines from pdc202xx_old.c help?

Ok, now I tried a kernel without the 
"hwif->addressing = (hwif->channel) ? 0 : 1"  line in pdc202xx_old.c,
and yes, now the 160GB drive works without aliasing parts above 137GB
back to the beginning of the drive.

Some simple tests (reading and writing a few 100MB of data) didn't show
any nasty side effects. If you want me to do additional tests, please
tell me. At the moment the drive doesn't contain any data, so I can even
try dangerous things.

Jan

Re: IDE bug - was: Re: uncorrectable ext2 errors

[Bartlomiej Zolnierkiewicz]

On Thursday 14 of August 2003 00:36, you wrote:
> On Wed, Aug 13, 2003 at 02:21:26AM +0200, Bartlomiej Zolnierkiewicz wrote:
> > Jan, did removing offending lines from pdc202xx_old.c help?
>
> Ok, now I tried a kernel without the
> "hwif->addressing = (hwif->channel) ? 0 : 1"  line in pdc202xx_old.c,
> and yes, now the 160GB drive works without aliasing parts above 137GB
> back to the beginning of the drive.
>
> Some simple tests (reading and writing a few 100MB of data) didn't show
> any nasty side effects. If you want me to do additional tests, please
> tell me. At the moment the drive doesn't contain any data, so I can even
> try dangerous things.

Thanks!  Can you do some more testing?
LBA-48 should be (was before 2.4.20 according to previous bugreports) working
just fine, but just to make sure.

I will remove these offending lines from 2.6.x if there are no problems.

--bartlomiej

Re: IDE bug - was: Re: uncorrectable ext2 errors

[Jan Niehusmann]

On Thu, Aug 14, 2003 at 01:14:32AM +0200, Bartlomiej Zolnierkiewicz wrote:
> Thanks!  Can you do some more testing?

Ok, after I compiled the driver with special udma feature and special
fasttrak feature, I got decent transfer rates (40-50MB/s) from the
drive.

I let a process running which continously copied a big (700MB) file,
removed the old copy, umounted an mounted the filesystem, and checked
the md5sum of the file. I didn't see a single corruption in >160 copies. 

At the same time, a second process was generating load by compiling
kernels on a different partition on the same drive. One partition was
below the 137GB boundary, one was above it.

> I will remove these offending lines from 2.6.x if there are no problems.

These tests were done with patched 2.4.21.

Jan

Re: uncorrectable ext2 errors

[Bartlomiej Zolnierkiewicz]

On Sunday 10 of August 2003 23:34, Jan Niehusmann wrote:
> On Sun, Aug 10, 2003 at 11:19:55PM +0200, Andries Brouwer wrote:
> > I see no kernel version in your post, that would be the first thing
> > of interest. Next, look at this addressing variable via /proc.
>
> Sorry - I mentioned it in an earlier post with a different subject. It's
> plain 2.4.21.
>
> > It it is zero, then you are hit by something avoided by the patch
> > I sketched yesterday evening or so. Otherwise we must look further.
>
> It is 0, yes. May it be caused by the following lines in pdc202xx_old.c?
>
>         if (hwif->pci_dev->device == PCI_DEVICE_ID_PROMISE_20265)
>                 hwif->addressing = (hwif->channel) ? 0 : 1;

Yes.  I did some googling.

http://www.ussg.iu.edu/hypermail/linux/kernel/0209.0/0000.html
and
http://www.ussg.iu.edu/hypermail/linux/kernel/0209.0/0898.html

are essential.

It looks LBA-48 was disabled on PDC20265 as a "workaround", because there
was a stupid in Promise LBA-48 support.
Bug was fixed, but "workaround" disabling LBA-48 was never removed.

You can remove these two lines and see if it helps
(but it may corrupt your fs even more if it doesn't).

Because of this bug you are hitting another bug which Andries has described
recently.

--bartlomiej