Re: Linux 2.6.3-rc3 - missing IDE hunk from bk4; good or bad?

Re: Linux 2.6.3-rc3 - missing IDE hunk from bk4; good or bad?

[Chip Salzenberg]

Linus writes:
>More merges, although most of them are architecture updates. IA64,
>ppc32/64, SuperH and ARM.

One non-arch difference between rc3 and bk4 seems to involve IDE DMA.
When I ran briefly ran bk4 I got a few IDE DMA errors (ThinkPad A30,
TOSHIBA MK8025GAS).  Makes one wonder.  Thus:

Is the IDE patch in bk4 (that's missing from rc3) going to be in
2.6.3?  Does it only come into play with SCSI, as it seems to, or
does it affect a non-SCSI setup?

Here's the diff between bk4 and rc3:

diff -ru2 linux-2.6.3rc2bk4/drivers/scsi/libata-core.c linux-2.6.3rc3/drivers/scsi/libata-core.c
--- linux-2.6.3rc2bk4/drivers/scsi/libata-core.c	2004-02-14 23:40:19.000000000 -0500
+++ linux-2.6.3rc3/drivers/scsi/libata-core.c	2004-02-15 01:51:34.000000000 -0500
@@ -2387,39 +2387,4 @@
 
 /**
- *	ata_chk_spurious_int - Check for spurious interrupts
- *	@ap: port to which command is being issued
- *
- *	Examines the DMA status registers and clears
- *      unexpected interrupts.  Created to work around
- *	hardware bug on Intel ICH5, but is applied to all
- *	chipsets using the standard irq handler, just for safety.
- *	If the bug is not present, this is simply a single
- *	PIO or MMIO read addition to the irq handler.
- *
- *	LOCKING:
- */
-static inline void ata_chk_spurious_int(struct ata_port *ap) {
-	int host_stat;
-	
-	if (ap->flags & ATA_FLAG_MMIO) {
-		void *mmio = (void *) ap->ioaddr.bmdma_addr;
-		host_stat = readb(mmio + ATA_DMA_STATUS);
-	} else
-		host_stat = inb(ap->ioaddr.bmdma_addr + ATA_DMA_STATUS);
-	
-	if ((host_stat & (ATA_DMA_INTR | ATA_DMA_ERR | ATA_DMA_ACTIVE)) == ATA_DMA_INTR) {
-		if (ap->flags & ATA_FLAG_MMIO) {
-			void *mmio = (void *) ap->ioaddr.bmdma_addr;
-			writeb(host_stat & ~ATA_DMA_ERR, mmio + ATA_DMA_STATUS);
-		} else
-			outb(host_stat & ~ATA_DMA_ERR, ap->ioaddr.bmdma_addr + ATA_DMA_STATUS);
-		
-		DPRINTK("ata%u: Caught spurious interrupt, status 0x%X\n", ap->id, host_stat);
-		udelay(1);
-	}
-}
-
-
-/**
  *	ata_interrupt -
  *	@irq:
@@ -2453,5 +2418,4 @@
 			if (qc && ((qc->flags & ATA_QCFLAG_POLL) == 0))
 				handled += ata_host_intr(ap, qc);
-			ata_chk_spurious_int(ap);
 		}
 	}



-- 
Chip Salzenberg               - a.k.a. -               <chip@pobox.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early."  // MST3K

Re: Linux 2.6.3-rc3 - missing IDE hunk from bk4; good or bad?

[Bartlomiej Zolnierkiewicz]

Bad.

On Sunday 15 of February 2004 16:22, Chip Salzenberg wrote:
> Linus writes:
> >More merges, although most of them are architecture updates. IA64,
> >ppc32/64, SuperH and ARM.
>
> One non-arch difference between rc3 and bk4 seems to involve IDE DMA.

There are no IDE DMA related changes (except build fix) between rc3 and bk4.

> When I ran briefly ran bk4 I got a few IDE DMA errors (ThinkPad A30,
> TOSHIBA MK8025GAS).  Makes one wonder.  Thus:

Please send dmesg command output and your config kernel config
if you want anybody to look at IDE problems...

> Is the IDE patch in bk4 (that's missing from rc3) going to be in
> 2.6.3?  Does it only come into play with SCSI, as it seems to, or
> does it affect a non-SCSI setup?

This was in SATA libata driver and was reverted because caused problems.
[ libata is independent of IDE drivers from linux/drivers/ide/ ]

If you don't use libata this chunk shouldn't affect you.

Cheers,
--bart

Re: Linux 2.6.3-rc3 - IDE DMA errors on Thinkpad A30

[Chip Salzenberg]

According to Bartlomiej Zolnierkiewicz:
> Please send dmesg command output and your config kernel config
> if you want anybody to look at IDE problems...

OK, I've entered all the info in Bugzilla:

  http://bugzilla.kernel.org/show_bug.cgi?id=2110

I've also included the SMART error dumps ("smartctl -a").  There are
no media problems, if I'm reading it right; whatever else is broken,
the IDE DMA errors seem to be unrelated to actual bad sectors.
-- 
Chip Salzenberg               - a.k.a. -               <chip@pobox.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early."  // MST3K

Re: Linux 2.6.3-rc3 - IDE DMA errors on Thinkpad A30

[Bartlomiej Zolnierkiewicz]

On Sunday 15 of February 2004 17:34, Chip Salzenberg wrote:
> According to Bartlomiej Zolnierkiewicz:
> > Please send dmesg command output and your config kernel config
> > if you want anybody to look at IDE problems...
>
> OK, I've entered all the info in Bugzilla:
>
>   http://bugzilla.kernel.org/show_bug.cgi?id=2110
>
> I've also included the SMART error dumps ("smartctl -a").  There are
> no media problems, if I'm reading it right; whatever else is broken,
> the IDE DMA errors seem to be unrelated to actual bad sectors.

There is a media error at sector 4682265. :-(

Re: Linux 2.6.3-rc3 - IDE DMA errors on Thinkpad A30

[Chip Salzenberg]

According to Bartlomiej Zolnierkiewicz:
> On Sunday 15 of February 2004 17:34, Chip Salzenberg wrote:
> > http://bugzilla.kernel.org/show_bug.cgi?id=2110
> >
> > I've also included the SMART error dumps ("smartctl -a").  There are
> > no media problems, if I'm reading it right; whatever else is broken,
> > the IDE DMA errors seem to be unrelated to actual bad sectors.
> 
> There is a media error at sector 4682265. :-(

Damn.  Is there a HOWTO on forcing the remapping of a known bad sector?
-- 
Chip Salzenberg               - a.k.a. -               <chip@pobox.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early."  // MST3K

Re: Linux 2.6.3-rc3 - IDE DMA errors on Thinkpad A30

[Jeff Garzik]

Chip Salzenberg wrote:
> According to Bartlomiej Zolnierkiewicz:
> 
>>On Sunday 15 of February 2004 17:34, Chip Salzenberg wrote:
>>
>>>http://bugzilla.kernel.org/show_bug.cgi?id=2110
>>>
>>>I've also included the SMART error dumps ("smartctl -a").  There are
>>>no media problems, if I'm reading it right; whatever else is broken,
>>>the IDE DMA errors seem to be unrelated to actual bad sectors.
>>
>>There is a media error at sector 4682265. :-(
> 
> 
> Damn.  Is there a HOWTO on forcing the remapping of a known bad sector?

Ideally the drive should do it automatically, and if it can't remap, 
it's run out of spare sectors to remap bad ones to (uh oh).

Really the best policy IMO is just to run 'e2fsck -c' every so often 
until you can get your data off this disk, and throw it in the garbage. 
  That does the "remapping" at the filesystem level, which is IMO easier 
than bothering with low-level ATA commands.

I'm a bit fuzzy on SMART and Device Configuration Overlay and need to 
review.  Those are sets of ATA commands, and they -might- allow you to 
remap at a low-level.  I know vendor-specific commands exist to do 
precisely what you want, but those are unfortunately NDA'd and I don't 
know them, just that they exist...

	Jeff

Re: Linux 2.6.3-rc3 - IDE DMA errors on Thinkpad A30

[Chip Salzenberg]

According to Jeff Garzik:
> Really the best policy IMO is just to run 'e2fsck -c' every so often 
> until you can get your data off this disk, and throw it in the garbage. 
> That does the "remapping" at the filesystem level, which is IMO easier 
> than bothering with low-level ATA commands.

Good advice, though I have to find the XFS equivalent.

Still: I wonder if the occasional bad sector is really that bad.
Shirley, at the unreal densities of today's drives, the development of
bad sectors is inevitable?  (Especially in a laptop drive that's
bounced around in normal use.)
-- 
Chip Salzenberg               - a.k.a. -               <chip@pobox.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early."  // MST3K

Re: Linux 2.6.3-rc3 - IDE DMA errors on Thinkpad A30

[Jeff Garzik]

Chip Salzenberg wrote:
> Still: I wonder if the occasional bad sector is really that bad.
> Shirley, at the unreal densities of today's drives, the development of
> bad sectors is inevitable?  (Especially in a laptop drive that's
> bounced around in normal use.)

Open argument :)

A lot of smart people will argue that a bad sector every now and again 
occurs, and "I've run my server's disks that way for years."

Other equally smart people argue that modern IDE disks reserve space for 
remapping bad sectors.  If you run out of sectors that the drive is 
willing to silently remap for you, you should toss the disk and buy a 
new one.

There is of course the caveat that it is impossible to avoid the drive 
returning "bad sector", instead of silently remapping, on reads.

Oh, and I just thought of something else.  Current Linux filesystems 
will, on a read error, usually mark it as a bad sector and move on. 
Really, they should attempt to write to the bad sector before 
considering it bad.

As a result, current kernels will AFAICT assume a sector is bad even 
when the drive politely swaps a good sector in place for you.

One for the todo list, I suppose...  a useable workaround for this is 
probably good ole 'e2fsck -c', i.e. badblocks...  That says "check again 
to see if this sector is bad", and -hopefully- will unmark bad blocks 
that were incorrectly marked bad.

	Jeff

Re: Linux 2.6.3-rc3 - IDE DMA errors on Thinkpad A30

[Valdis.Kletnieks]

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

On Sun, 15 Feb 2004 22:47:37 EST, Jeff Garzik said:
> One for the todo list, I suppose...  a useable workaround for this is 
> probably good ole 'e2fsck -c', i.e. badblocks...  That says "check again 
> to see if this sector is bad", and -hopefully- will unmark bad blocks 
> that were incorrectly marked bad.

Does e2fsck/badblocks issue the right ioctls/etc to make the disk read the
*original* block, or will the disk simply check the *redirected* block?

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

Re: Linux 2.6.3-rc3 - IDE DMA errors on Thinkpad A30

[Chip Salzenberg]

According to Jeff Garzik:
> Other equally smart people argue that modern IDE disks reserve space for 
> remapping bad sectors.  If you run out of sectors that the drive is 
> willing to silently remap for you, you should toss the disk and buy a 
> new one.

OK, I get the theory.  But AFAICT this drive hasn't remapped *any*
sectors.  Yet.  (Which would not be impossible; it's a relatively
new drive, a few months old at most.)  Quoting smartctl:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   050    Pre-fail  Always       -       0
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   100   100   000    Old_age   Always       -       3
198 Offline_Uncorrectable   0x0030   100   100   000    Old_age   Offline      -       0

This seems to suggest that there are three *candidate* sectors with
reallocation pending, none of which have actually been remapped (yet).
If so, drive replacement would perhaps be premature.

I suppose it's time to read up on the details of the SMART spec.
-- 
Chip Salzenberg               - a.k.a. -               <chip@pobox.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early."  // MST3K

Re: Linux 2.6.3-rc3 - IDE DMA errors on Thinkpad A30

[Jeff Garzik]

Valdis.Kletnieks@vt.edu wrote:
> On Sun, 15 Feb 2004 22:47:37 EST, Jeff Garzik said:
> 
>>One for the todo list, I suppose...  a useable workaround for this is 
>>probably good ole 'e2fsck -c', i.e. badblocks...  That says "check again 
>>to see if this sector is bad", and -hopefully- will unmark bad blocks 
>>that were incorrectly marked bad.
> 
> 
> Does e2fsck/badblocks issue the right ioctls/etc to make the disk read the
> *original* block, or will the disk simply check the *redirected* block?


I'm not sure your question has meaning.

Consider:  ext2 reads sector 1234.  drive returns "media error", and 
then swaps the bad sector for a good one.  Reboot and run badblocks. 
badblocks reads sector 1234, in whatever manner the drive chooses to 
present sector 1234 to the OS.

"original" versus "redirected" block is invisible to the OS.  The OS 
only knows that an event occured at a single point in time -- the media 
error.

	Jeff

Re: Linux 2.6.3-rc3 - IDE DMA errors on Thinkpad A30

[Bartlomiej Zolnierkiewicz]

On Monday 16 of February 2004 05:08, Chip Salzenberg wrote:
> According to Jeff Garzik:
> > Other equally smart people argue that modern IDE disks reserve space for
> > remapping bad sectors.  If you run out of sectors that the drive is
> > willing to silently remap for you, you should toss the disk and buy a
> > new one.
>
> OK, I get the theory.  But AFAICT this drive hasn't remapped *any*
> sectors.  Yet.  (Which would not be impossible; it's a relatively
> new drive, a few months old at most.)  Quoting smartctl:
>
> ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED 
> WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct   0x0033   100   100   050   
> Pre-fail  Always       -       0 196 Reallocated_Event_Count 0x0032   100  
> 100   000    Old_age   Always       -       0 197 Current_Pending_Sector 
> 0x0032   100   100   000    Old_age   Always       -       3 198
> Offline_Uncorrectable   0x0030   100   100   000    Old_age   Offline     
> -       0
>
> This seems to suggest that there are three *candidate* sectors with
> reallocation pending, none of which have actually been remapped (yet).

Because you hit them during READ access, you may try to WRITE them.
[ Hmm.  It reminds me quite recent thread about remapping of bad sectors. ]

> If so, drive replacement would perhaps be premature.
>
> I suppose it's time to read up on the details of the SMART spec.

Re: Linux 2.6.3-rc3 - IDE DMA errors on Thinkpad A30

[Valdis.Kletnieks]

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

On Sun, 15 Feb 2004 23:09:52 EST, Jeff Garzik said:
> Valdis.Kletnieks@vt.edu wrote:
> > On Sun, 15 Feb 2004 22:47:37 EST, Jeff Garzik said:

> >>to see if this sector is bad", and -hopefully- will unmark bad blocks 
> >>that were incorrectly marked bad.

That "hopefully" is the question here...

> Consider:  ext2 reads sector 1234.  drive returns "media error", and 
> then swaps the bad sector for a good one.  Reboot and run badblocks. 
> badblocks reads sector 1234, in whatever manner the drive chooses to 
> present sector 1234 to the OS.
> 
> "original" versus "redirected" block is invisible to the OS.  The OS 
> only knows that an event occured at a single point in time -- the media 
> error.

So it never sees the original incorrectly marked bad block, and thus can't
unmap it...  We'll never look at the original 1234 again and see that it was in
fact a good block, all we'll see is if the REPLACEMENT 1234 is good or bad.


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

Re: Linux 2.6.3-rc3 - IDE DMA errors on Thinkpad A30

[Bill Davidsen]

Jeff Garzik wrote:
> Valdis.Kletnieks@vt.edu wrote:
> 
>> On Sun, 15 Feb 2004 22:47:37 EST, Jeff Garzik said:
>>
>>> One for the todo list, I suppose...  a useable workaround for this is 
>>> probably good ole 'e2fsck -c', i.e. badblocks...  That says "check 
>>> again to see if this sector is bad", and -hopefully- will unmark bad 
>>> blocks that were incorrectly marked bad.
>>
>>
>>
>> Does e2fsck/badblocks issue the right ioctls/etc to make the disk read 
>> the
>> *original* block, or will the disk simply check the *redirected* block?
> 
> 
> 
> I'm not sure your question has meaning.
> 
> Consider:  ext2 reads sector 1234.  drive returns "media error", and 
> then swaps the bad sector for a good one.  Reboot and run badblocks. 
> badblocks reads sector 1234, in whatever manner the drive chooses to 
> present sector 1234 to the OS.

That's the point, the original 1234 may not really be bad.
> 
> "original" versus "redirected" block is invisible to the OS.  The OS 
> only knows that an event occured at a single point in time -- the media 
> error.

It's invisible unlesss the o/s chooses to see. By default there would 
never be an attempt to recheck the original sector 1234 unless the o/s 
tells the drive to do so. It may be that a write to the sector will work 
and there is nothing wrong with the sector (transient errors could be 
caused by mechanical or electrical transients, more likely in a laptop).

-- 
bill davidsen <davidsen@tmr.com>
   CTO TMR Associates, Inc
   Doing interesting things with small computers since 1979

Re: Linux 2.6.3-rc3 - IDE DMA errors on Thinkpad A30

[Eric D. Mudama]

On Sun, Feb 15 at 22:47, Jeff Garzik wrote:
>Chip Salzenberg wrote:
>>Still: I wonder if the occasional bad sector is really that bad.
>>Shirley, at the unreal densities of today's drives, the development of
>>bad sectors is inevitable?  (Especially in a laptop drive that's
>>bounced around in normal use.)
>
>Open argument :)
>
>A lot of smart people will argue that a bad sector every now and again 
>occurs, and "I've run my server's disks that way for years."
>
>Other equally smart people argue that modern IDE disks reserve space for 
>remapping bad sectors.  If you run out of sectors that the drive is 
>willing to silently remap for you, you should toss the disk and buy a 
>new one.

Yes, definitely.  There are a *lot* of spare sectors on a modern IDE
drive -- Running out of spares is an extremely rare event, and usually
indicates that the drive has been operating in severe conditions for
its lifetime.  (>55C + vibe sorts of things)

>There is of course the caveat that it is impossible to avoid the drive 
>returning "bad sector", instead of silently remapping, on reads.

Yes, because at that point, there's nothing to remap.  If the drive
couldn't read it, and knows it isn't in its 2/8MB cache, remapping is
pointless until there is known-good data to apply.  Therefore, only on
the write is there a good reason to examine and possibly remap an LBA.

>Oh, and I just thought of something else.  Current Linux filesystems 
>will, on a read error, usually mark it as a bad sector and move on. 
>Really, they should attempt to write to the bad sector before 
>considering it bad.
>
>As a result, current kernels will AFAICT assume a sector is bad even 
>when the drive politely swaps a good sector in place for you.
>
>One for the todo list, I suppose...  a useable workaround for this is 
>probably good ole 'e2fsck -c', i.e. badblocks...  That says "check again 
>to see if this sector is bad", and -hopefully- will unmark bad blocks 
>that were incorrectly marked bad.

Agreed.

In most cases, a simpe write to the supposedly-defective LBA will get
the drive to resolve whether it is a permanent media defect that needs
to be remapped, or else functional media that has gone bad for some
other reason. (of which there are several... excessive cold/heat,
vibration, poor power, etc)


-- 
Eric D. Mudama
edmudama@mail.bounceswoosh.org