ide drive problem?

ide drive problem?

[Steven Joerger]

List,

When I enable support for my chipset in the kernel (via kt133) I always get 
these messages:

hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }

over and over and ....

Any clues to whats going on?

Thanks,
Steven Joerger

Re: ide drive problem?

[David Grant]

I think the standard response people would give you is that your IDE cable
is too long, of bad quality, or you are using a 40-pin cable instead of an
80-pin cable (although I'm pretty sure that should have been detected, and
DMA should automatically have not been used, but I heard at one point that
the code which detected this on motherboards using the vt82c686b chip didn't
really work in some cases).

That's the standard answer, but I used to get this messages on my machine as
well (I think it was back when I was trying to use my VIA chipset with
Redhat 7.1).  I don't seem to get them anymore though, but maybe that's just
because I'm trying to install distros newer than Redhat 7.1.  That makes me
think that I never had CRC errors, it was just some buggy VIA code.

I just get the dma timeout errors now with my VIA IDE controller.  I also
get them with the Promise controller (sigh...).

David Grant

----- Original Message -----
From: "Steven Joerger" <steven@spock.2y.net>
To: <linux-kernel@vger.kernel.org>
Sent: Thursday, September 27, 2001 9:02 PM
Subject: ide drive problem?


> List,
>
> When I enable support for my chipset in the kernel (via kt133) I always
get
> these messages:
>
> hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
>
> over and over and ....
>
> Any clues to whats going on?
>
> Thanks,
> Steven Joerger
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: ide drive problem?

[Steven Joerger]

David,

Thanks for the insight. I am using an 80 pin cable, but the length and 
quality are of course suspect. I will swap this out and see if it helps.

Thanks again,
Steven Joerger


On Friday 28 September 2001 01:44 am, David Grant wrote:
> I think the standard response people would give you is that your IDE cable
> is too long, of bad quality, or you are using a 40-pin cable instead of an
> 80-pin cable (although I'm pretty sure that should have been detected, and
> DMA should automatically have not been used, but I heard at one point that
> the code which detected this on motherboards using the vt82c686b chip
> didn't really work in some cases).
>
> That's the standard answer, but I used to get this messages on my machine
> as well (I think it was back when I was trying to use my VIA chipset with
> Redhat 7.1).  I don't seem to get them anymore though, but maybe that's
> just because I'm trying to install distros newer than Redhat 7.1.  That
> makes me think that I never had CRC errors, it was just some buggy VIA
> code.
>
> I just get the dma timeout errors now with my VIA IDE controller.  I also
> get them with the Promise controller (sigh...).
>
> David Grant
>
> ----- Original Message -----
> From: "Steven Joerger" <steven@spock.2y.net>
> To: <linux-kernel@vger.kernel.org>
> Sent: Thursday, September 27, 2001 9:02 PM
> Subject: ide drive problem?
>
> > List,
> >
> > When I enable support for my chipset in the kernel (via kt133) I always
>
> get
>
> > these messages:
> >
> > hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> > hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> >
> > over and over and ....
> >
> > Any clues to whats going on?
> >
> > Thanks,
> > Steven Joerger
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> > in the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/

Re: ide drive problem?

[clemens]

Hi David, Hi Steve

i get:

hde: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hde: dma_intr: error=0x84 { DriveStatusError BadCRC }

on:

Linux version 2.4.9-ac7 (root@ghanima) (gcc version 2.95.4 20010902 (Debian
prerelease)) #1 SMP Wed Sep 26 14:39:37 CEST 2001

HPT370: IDE controller on PCI bus 00 dev 98
PCI: Found IRQ 15 for device 00:13.0
HPT370: chipset revision 3
HPT370: not 100% native mode: will probe irqs later
    ide2: BM-DMA at 0xe800-0xe807, BIOS settings: hde:DMA, hdf:pio
    ide3: BM-DMA at 0xe808-0xe80f, BIOS settings: hdg:pio, hdh:pio
hde: ST360021A, ATA DISK drive

even thou i have VT8363/8365 (=KT133) as north bridge, and VT82C686A as
southbridge, at least the south bridge could not be blamed for that, since
a. i don't even use it, hde is my hpt370 controller, and
b. it's the A revision and not the infamous 686B revision (see
http://www.viahardware.com/686bfaq.shtm for more infos on "the" 686B bug)

what kernel, harddisc do you both have?

clemens

p.s.: i don't know if "BadCRC" has anything to do with bad blocks, but
/sbin/badblocks doesn't even show a single bad block on my brand new seagate 
disc, so i guess, that's not the source of the troubles.

On Thu, Sep 27, 2001 at 10:44:53PM -0700, David Grant wrote:
> I think the standard response people would give you is that your IDE cable
> is too long, of bad quality, or you are using a 40-pin cable instead of an
> 80-pin cable (although I'm pretty sure that should have been detected, and
> DMA should automatically have not been used, but I heard at one point that
> the code which detected this on motherboards using the vt82c686b chip didn't
> really work in some cases).
> 
> That's the standard answer, but I used to get this messages on my machine as
> well (I think it was back when I was trying to use my VIA chipset with
> Redhat 7.1).  I don't seem to get them anymore though, but maybe that's just
> because I'm trying to install distros newer than Redhat 7.1.  That makes me
> think that I never had CRC errors, it was just some buggy VIA code.
> 
> I just get the dma timeout errors now with my VIA IDE controller.  I also
> get them with the Promise controller (sigh...).
> 
> David Grant
> 
> ----- Original Message -----
> From: "Steven Joerger" <steven@spock.2y.net>
> To: <linux-kernel@vger.kernel.org>
> Sent: Thursday, September 27, 2001 9:02 PM
> Subject: ide drive problem?
> 
> 
> > List,
> >
> > When I enable support for my chipset in the kernel (via kt133) I always
> get
> > these messages:
> >
> > hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> > hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> >
> > over and over and ....
> >
> > Any clues to whats going on?
> >
> > Thanks,
> > Steven Joerger
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> >
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: ide drive problem?

[Vojtech Pavlik]

On Fri, Sep 28, 2001 at 01:52:22PM +0200, clemens wrote:
> Hi David, Hi Steve
> 
> i get:
> 
> hde: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hde: dma_intr: error=0x84 { DriveStatusError BadCRC }
> 
> on:
> 
> Linux version 2.4.9-ac7 (root@ghanima) (gcc version 2.95.4 20010902 (Debian
> prerelease)) #1 SMP Wed Sep 26 14:39:37 CEST 2001
> 
> HPT370: IDE controller on PCI bus 00 dev 98
> PCI: Found IRQ 15 for device 00:13.0
> HPT370: chipset revision 3
> HPT370: not 100% native mode: will probe irqs later
>     ide2: BM-DMA at 0xe800-0xe807, BIOS settings: hde:DMA, hdf:pio
>     ide3: BM-DMA at 0xe808-0xe80f, BIOS settings: hdg:pio, hdh:pio
> hde: ST360021A, ATA DISK drive
> 
> even thou i have VT8363/8365 (=KT133) as north bridge, and VT82C686A as
> southbridge, at least the south bridge could not be blamed for that, since
> a. i don't even use it, hde is my hpt370 controller, and
> b. it's the A revision and not the infamous 686B revision (see
> http://www.viahardware.com/686bfaq.shtm for more infos on "the" 686B bug)
> 
> what kernel, harddisc do you both have?
> 
> clemens
> 
> p.s.: i don't know if "BadCRC" has anything to do with bad blocks, but
> /sbin/badblocks doesn't even show a single bad block on my brand new seagate 
> disc, so i guess, that's not the source of the troubles.

It means that the drive detected a bad CRC on the UDMA transaction.
Unless these are frequent, they are harmless, since the transaction
will be retried..

-- 
Vojtech Pavlik
SuSE Labs

2 GB file limitation

[Bobby Hitt]

Hello,

Thanks to all that provided input for my problem. All good info. Seems that
Slackware distributions, even the latest has the latest tar and gzip
programs. I'm going to snatch them off the RedHat site and install.

Thanks again!

Bobby

Re: 2 GB file limitation

[David Lang]

?? slackware 8 has large file support (I've been useing it for a while
now)

David Lang

On Fri, 28 Sep 2001, Bobby Hitt wrote:

> Date: Fri, 28 Sep 2001 11:25:40 -0400
> From: Bobby Hitt <bobhitt@bscnet.com>
> To: linux-kernel@vger.kernel.org
> Subject: 2 GB file limitation
>
> Hello,
>
> Thanks to all that provided input for my problem. All good info. Seems that
> Slackware distributions, even the latest has the latest tar and gzip
> programs. I'm going to snatch them off the RedHat site and install.
>
> Thanks again!
>
> Bobby
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: 2 GB file limitation

[Jeff Chua]

On Fri, 28 Sep 2001, David Lang wrote:

> ?? slackware 8 has large file support (I've been useing it for a while
> now)
>

I think you can get >2GB support if you've Gcc 3.0. Even with the latest
kernel 2.4.x, you won't get >2GB with gcc 2.95.3.


Jeff.

Re: 2 GB file limitation

[Nicholas Knight]

On Friday 28 September 2001 05:18 pm, Jeff Chua wrote:
> On Fri, 28 Sep 2001, David Lang wrote:
> > ?? slackware 8 has large file support (I've been useing it for a
> > while now)
>
> I think you can get >2GB support if you've Gcc 3.0. Even with the
> latest kernel 2.4.x, you won't get >2GB with gcc 2.95.3.

Could have fooled me with my 2.95.3 and 2.95.4 systems and their 3GB+ 
files.

Re: 2 GB file limitation

[Jeff Chua]

On Sat, 29 Sep 2001, Nicholas Knight wrote:

> On Friday 28 September 2001 05:18 pm, Jeff Chua wrote:
> > On Fri, 28 Sep 2001, David Lang wrote:
> > > ?? slackware 8 has large file support (I've been useing it for a
> > > while now)
> >
> > I think you can get >2GB support if you've Gcc 3.0. Even with the
> > latest kernel 2.4.x, you won't get >2GB with gcc 2.95.3.
>
> Could have fooled me with my 2.95.3 and 2.95.4 systems and their 3GB+
> files.
> -

uh, I mistaken glib2.2 for gcc. sorry (see below from Chris).

Jeff.



On Fri, 28 Sep 2001, Christopher Zimmerman wrote:
> Actually you just need glibc2.2 and compile your apps with these
flags:
> -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DLARGE_FILES

Re: 2 GB file limitation

[Luigi Genoni]

On Sat, 29 Sep 2001, Jeff Chua wrote:

>
> On Fri, 28 Sep 2001, David Lang wrote:
>
> > ?? slackware 8 has large file support (I've been useing it for a while
> > now)
> >
>
> I think you can get >2GB support if you've Gcc 3.0. Even with the latest
> kernel 2.4.x, you won't get >2GB with gcc 2.95.3.
>
>
???
I am using it and I am using gcc 2.95.3 for normal things,
and to compiled my kernel and my libc, because gcc
3.0.1 produces slower binaries on my Athlons (yes, with athlon
optimizzations turned on), at less for my programs, and it is better to
avoid it for glibc compilation because of back compatibility issues.


bests
Luigi

Re: 2 GB file limitation

[Gábor Lénárt]

On Sat, Sep 29, 2001 at 03:51:53PM +0200, Luigi Genoni wrote:
> > > ?? slackware 8 has large file support (I've been useing it for a while
> > > now)
> > I think you can get >2GB support if you've Gcc 3.0. Even with the latest
> >
> ???
> I am using it and I am using gcc 2.95.3 for normal things,
> and to compiled my kernel and my libc, because gcc
> 3.0.1 produces slower binaries on my Athlons (yes, with athlon
> optimizzations turned on), at less for my programs, and it is better to
> avoid it for glibc compilation because of back compatibility issues.

Yes, gcc3 is (well at least NOW) a piece of shit. It produces BIGGER and
SLOWER binaries ... Checked on: Athlon, AMD K6-2.
With the same gcc command line ...

-- 
 --[ Gábor Lénárt ]---[ Vivendi Telecom Hungary ]---------[ lgb@lgb.hu ]--
 U have 8 bit comp or chip of them and it's unused or to be sold? Call me!
 -------[ +36 30 2270823 ]------> LGB <-----[ Linux/UNIX/8bit 4ever ]-----

Re: 2 GB file limitation

[safemode]

On Sunday 30 September 2001 04:23, Gábor Lénárt wrote:
> On Sat, Sep 29, 2001 at 03:51:53PM +0200, Luigi Genoni wrote:
> > > > ?? slackware 8 has large file support (I've been useing it for a
> > > > while now)
> > >
> > > I think you can get >2GB support if you've Gcc 3.0. Even with the
> > > latest

It's already been posted that the compiler used isn't the issue. You dont 
have to recompile libc with gcc 3.x to get large file support, you just 
enable the non-standard option and compile libc. 

> > ???
> > I am using it and I am using gcc 2.95.3 for normal things,
> > and to compiled my kernel and my libc, because gcc
> > 3.0.1 produces slower binaries on my Athlons (yes, with athlon
> > optimizzations turned on), at less for my programs, and it is better to
> > avoid it for glibc compilation because of back compatibility issues.
>
> Yes, gcc3 is (well at least NOW) a piece of shit. It produces BIGGER and
> SLOWER binaries ... Checked on: Athlon, AMD K6-2.
> With the same gcc command line ...

gcc 3.0.2 produces lame binaries that are 45 seconds faster encoding 
74minutes of audio than the gcc 2.95.4 binaries with the same cflags.   
gcc 2.95.4 produces a binary of 39432 bytes when gcc 3.0.2 with the same 
flags on the same source produces a binary of 37452 bytes.  I then tested it 
with lame.  gcc 2.95.4 produced a binary of 245664 bytes and 3.0.2 produced 
one of 238016 bytes.  Same exact cflags and settings. 
So basically my testing absolutely contradicts your statement.  So who is 
right? 

gcc performance all depends on the code being used, no matter what version 
and both completely on the CFLAGS being used.  Which is why compileable 
benchmarks are so unreliable etc etc.  So enough of the compiler trashing and 
just use whatever makes you happy.  Recompile the entire system with 3.x if 
you want. The backwards incompatibility is not something new to 3.x, it's 
something indicative to gcc throughout it's history.  

Re: 2 GB file limitation

[Gábor Lénárt]

On Sun, Sep 30, 2001 at 04:59:49AM -0400, safemode wrote:
> > Yes, gcc3 is (well at least NOW) a piece of shit. It produces BIGGER and
> > SLOWER binaries ... Checked on: Athlon, AMD K6-2.
> > With the same gcc command line ...
> 
> gcc 3.0.2 produces lame binaries that are 45 seconds faster encoding 
> 74minutes of audio than the gcc 2.95.4 binaries with the same cflags.   
> gcc 2.95.4 produces a binary of 39432 bytes when gcc 3.0.2 with the same 
> flags on the same source produces a binary of 37452 bytes.  I then tested it 
> with lame.  gcc 2.95.4 produced a binary of 245664 bytes and 3.0.2 produced 
> one of 238016 bytes.  Same exact cflags and settings. 
> So basically my testing absolutely contradicts your statement.  So who is 
> right? 

Well, you may be right. I got my results with the first (pre?)release
of gcc3. I'm going to try gcc 3.0.2 now ... Thanx for the correction.

-- 
 --[ Gábor Lénárt ]---[ Vivendi Telecom Hungary ]---------[ lgb@lgb.hu ]--
 U have 8 bit comp or chip of them and it's unused or to be sold? Call me!
 -------[ +36 30 2270823 ]------> LGB <-----[ Linux/UNIX/8bit 4ever ]-----

Re: 2 GB file limitation

[Luigi Genoni]

I would be interested to know on which processor your are seeing those
results.
In fact i do not have doubts that on somethuing like an alpha
gcc 3.0.2 is faster.
Maybe it could be faster also on PIV, I do not know. I never tried gcc
3.0.2, i just used gcc 3.0.1 on Athlon systems, but I am
going to gcc 3.0.2 snapshots as soon.

Luigi


On Sun, 30 Sep 2001, [iso-8859-2] Gábor Lénárt wrote:

> On Sun, Sep 30, 2001 at 04:59:49AM -0400, safemode wrote:
> > > Yes, gcc3 is (well at least NOW) a piece of shit. It produces BIGGER and
> > > SLOWER binaries ... Checked on: Athlon, AMD K6-2.
> > > With the same gcc command line ...
> >
> > gcc 3.0.2 produces lame binaries that are 45 seconds faster encoding
> > 74minutes of audio than the gcc 2.95.4 binaries with the same cflags.
> > gcc 2.95.4 produces a binary of 39432 bytes when gcc 3.0.2 with the same
> > flags on the same source produces a binary of 37452 bytes.  I then tested it
> > with lame.  gcc 2.95.4 produced a binary of 245664 bytes and 3.0.2 produced
> > one of 238016 bytes.  Same exact cflags and settings.
> > So basically my testing absolutely contradicts your statement.  So who is
> > right?
>

GCC 2.95, 2.96 and 3.0 on linear algebra (was RE: 2 GB file limitation)

[M. Edward Borasky]

I have heard from the Atlas linear algebra folks the following:

1. For compiling Atlas, both on Athlons and Pentia, GCC 2.95.x produces
*significantly* faster operation than either 3.0.x or 2.96.x
2. For IA64, the reverse is true: GCC 3.0.x produces significantly faster
code.

I can dig up the URL for the mailing list if anyone cares for the details.

--
M. Edward (Ed) Borasky, Chief Scientist, Borasky Research
http://www.borasky-research.net  http://www.aracnet.com/~znmeb
mailto:znmeb@borasky-research.net  mailto:znmeb@aracnet.com

Q: How do you tell when a pineapple is ready to eat?
A: It picks up its knife and fork.

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org
> [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Gábor Lénárt
> Sent: Sunday, September 30, 2001 1:24 AM
> To: Luigi Genoni
> Cc: Linux Kernel
> Subject: Re: 2 GB file limitation

[snip]

> > > I think you can get >2GB support if you've Gcc 3.0. Even with
> the latest
> > >
> > ???
> > I am using it and I am using gcc 2.95.3 for normal things,
> > and to compiled my kernel and my libc, because gcc
> > 3.0.1 produces slower binaries on my Athlons (yes, with athlon
> > optimizzations turned on), at less for my programs, and it is better to
> > avoid it for glibc compilation because of back compatibility issues.
>
> Yes, gcc3 is (well at least NOW) a piece of shit. It produces BIGGER and
> SLOWER binaries ... Checked on: Athlon, AMD K6-2.
> With the same gcc command line ...

Re: GCC 2.95, 2.96 and 3.0 on linear algebra (was RE: 2 GB file limitation)

[Luigi Genoni]

yes, thanx,
I am very interested in those details.

For the tests i made on sparc64 gcc 3.0.1 is really faster than previous
versions (2.95.3 and egcs 1.1.2), but on AMD Athlon is a different story.
I think I can infer that gcc speed depends a lot from CPUs, but
usually and storically gcc was heavilly x86 optimized...

Luigi

On Sun, 30 Sep 2001, M. Edward Borasky wrote:

> I have heard from the Atlas linear algebra folks the following:
>
> 1. For compiling Atlas, both on Athlons and Pentia, GCC 2.95.x produces
> *significantly* faster operation than either 3.0.x or 2.96.x
> 2. For IA64, the reverse is true: GCC 3.0.x produces significantly faster
> code.
>
> I can dig up the URL for the mailing list if anyone cares for the details.
>
> --
> M. Edward (Ed) Borasky, Chief Scientist, Borasky Research
> http://www.borasky-research.net  http://www.aracnet.com/~znmeb
> mailto:znmeb@borasky-research.net  mailto:znmeb@aracnet.com
>
> Q: How do you tell when a pineapple is ready to eat?
> A: It picks up its knife and fork.
>
> > -----Original Message-----
> > From: linux-kernel-owner@vger.kernel.org
> > [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Gábor Lénárt
> > Sent: Sunday, September 30, 2001 1:24 AM
> > To: Luigi Genoni
> > Cc: Linux Kernel
> > Subject: Re: 2 GB file limitation
>
> [snip]
>
> > > > I think you can get >2GB support if you've Gcc 3.0. Even with
> > the latest
> > > >
> > > ???
> > > I am using it and I am using gcc 2.95.3 for normal things,
> > > and to compiled my kernel and my libc, because gcc
> > > 3.0.1 produces slower binaries on my Athlons (yes, with athlon
> > > optimizzations turned on), at less for my programs, and it is better to
> > > avoid it for glibc compilation because of back compatibility issues.
> >
> > Yes, gcc3 is (well at least NOW) a piece of shit. It produces BIGGER and
> > SLOWER binaries ... Checked on: Athlon, AMD K6-2.
> > With the same gcc command line ...
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

RE: GCC 2.95, 2.96 and 3.0 on linear algebra (was RE: 2 GB file limitation)

[M. Edward Borasky]

The Atlas main page is on SourceForge at

http://math-atlas.sourceforge.net/

The Atlas performance list archive is at

http://www.geocrawler.com/lists/3/SourceForge/15666/0/

and the main Atlas developer list archive is at

http://www.geocrawler.com/lists/3/SourceForge/15667/0/

I haven't seen any Sparc data; I have an Athlon at home and Pentia and
Alphas at work, so if Sparc results went by me I ignored them.

--
M. Edward (Ed) Borasky, Chief Scientist, Borasky Research
http://www.borasky-research.net  http://www.aracnet.com/~znmeb
mailto:znmeb@borasky-research.net  mailto:znmeb@aracnet.com

Q: How do you tell when a pineapple is ready to eat?
A: It picks up its knife and fork.

> -----Original Message-----
> From: Luigi Genoni [mailto:kernel@Expansa.sns.it]
> Sent: Sunday, September 30, 2001 11:12 AM
> To: M. Edward Borasky
> Cc: Linux Kernel
> Subject: Re: GCC 2.95, 2.96 and 3.0 on linear algebra (was RE: 2 GB file
> limitation)
>
>
> yes, thanx,
> I am very interested in those details.
>
> For the tests i made on sparc64 gcc 3.0.1 is really faster than previous
> versions (2.95.3 and egcs 1.1.2), but on AMD Athlon is a different story.
> I think I can infer that gcc speed depends a lot from CPUs, but
> usually and storically gcc was heavilly x86 optimized...
>
> Luigi
>
> On Sun, 30 Sep 2001, M. Edward Borasky wrote:
>
> > I have heard from the Atlas linear algebra folks the following:
> >
> > 1. For compiling Atlas, both on Athlons and Pentia, GCC 2.95.x produces
> > *significantly* faster operation than either 3.0.x or 2.96.x
> > 2. For IA64, the reverse is true: GCC 3.0.x produces
> significantly faster
> > code.
> >
> > I can dig up the URL for the mailing list if anyone cares for
> the details.
> >
> > --
> > M. Edward (Ed) Borasky, Chief Scientist, Borasky Research
> > http://www.borasky-research.net  http://www.aracnet.com/~znmeb
> > mailto:znmeb@borasky-research.net  mailto:znmeb@aracnet.com
> >
> > Q: How do you tell when a pineapple is ready to eat?
> > A: It picks up its knife and fork.
> >
> > > -----Original Message-----
> > > From: linux-kernel-owner@vger.kernel.org
> > > [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Gábor Lénárt
> > > Sent: Sunday, September 30, 2001 1:24 AM
> > > To: Luigi Genoni
> > > Cc: Linux Kernel
> > > Subject: Re: 2 GB file limitation
> >
> > [snip]
> >
> > > > > I think you can get >2GB support if you've Gcc 3.0. Even with
> > > the latest
> > > > >
> > > > ???
> > > > I am using it and I am using gcc 2.95.3 for normal things,
> > > > and to compiled my kernel and my libc, because gcc
> > > > 3.0.1 produces slower binaries on my Athlons (yes, with athlon
> > > > optimizzations turned on), at less for my programs, and it
> is better to
> > > > avoid it for glibc compilation because of back compatibility issues.
> > >
> > > Yes, gcc3 is (well at least NOW) a piece of shit. It produces
> BIGGER and
> > > SLOWER binaries ... Checked on: Athlon, AMD K6-2.
> > > With the same gcc command line ...
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> >
>
>

Re: ide drive problem?

[Gábor Lénárt]

On Fri, Sep 28, 2001 at 01:52:22PM +0200, clemens wrote:
> Hi David, Hi Steve
> 
> i get:
> 
> hde: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hde: dma_intr: error=0x84 { DriveStatusError BadCRC }

Hmmm, I get this message as well about once a day (though it seems it
could not cause any damage ... yet ...)
But I have got non-highpoint-equipped KT133 motherboard with ATA33
disk.

Note, that this hw config DID NOT WORK with 2.2.x kernel at all (waiting
for interrupt or something similar message)

> on:
> 
> Linux version 2.4.9-ac7 (root@ghanima) (gcc version 2.95.4 20010902 (Debian
> prerelease)) #1 SMP Wed Sep 26 14:39:37 CEST 2001
> 
> HPT370: IDE controller on PCI bus 00 dev 98
> PCI: Found IRQ 15 for device 00:13.0
> HPT370: chipset revision 3
> HPT370: not 100% native mode: will probe irqs later
>     ide2: BM-DMA at 0xe800-0xe807, BIOS settings: hde:DMA, hdf:pio
>     ide3: BM-DMA at 0xe808-0xe80f, BIOS settings: hdg:pio, hdh:pio
> hde: ST360021A, ATA DISK drive
> 
> even thou i have VT8363/8365 (=KT133) as north bridge, and VT82C686A as
> southbridge, at least the south bridge could not be blamed for that, since
> a. i don't even use it, hde is my hpt370 controller, and
> b. it's the A revision and not the infamous 686B revision (see
> http://www.viahardware.com/686bfaq.shtm for more infos on "the" 686B bug)
> 
> what kernel, harddisc do you both have?
> 
> clemens
> 
> p.s.: i don't know if "BadCRC" has anything to do with bad blocks, but
> /sbin/badblocks doesn't even show a single bad block on my brand new seagate 
> disc, so i guess, that's not the source of the troubles.
> 
> On Thu, Sep 27, 2001 at 10:44:53PM -0700, David Grant wrote:
> > I think the standard response people would give you is that your IDE cable
> > is too long, of bad quality, or you are using a 40-pin cable instead of an
> > 80-pin cable (although I'm pretty sure that should have been detected, and
> > DMA should automatically have not been used, but I heard at one point that
> > the code which detected this on motherboards using the vt82c686b chip didn't
> > really work in some cases).
> > 
> > That's the standard answer, but I used to get this messages on my machine as
> > well (I think it was back when I was trying to use my VIA chipset with
> > Redhat 7.1).  I don't seem to get them anymore though, but maybe that's just
> > because I'm trying to install distros newer than Redhat 7.1.  That makes me
> > think that I never had CRC errors, it was just some buggy VIA code.
> > 
> > I just get the dma timeout errors now with my VIA IDE controller.  I also
> > get them with the Promise controller (sigh...).
> > 
> > David Grant
> > 
> > ----- Original Message -----
> > From: "Steven Joerger" <steven@spock.2y.net>
> > To: <linux-kernel@vger.kernel.org>
> > Sent: Thursday, September 27, 2001 9:02 PM
> > Subject: ide drive problem?
> > 
> > 
> > > List,
> > >
> > > When I enable support for my chipset in the kernel (via kt133) I always
> > get
> > > these messages:
> > >
> > > hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> > > hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> > >
> > > over and over and ....
> > >
> > > Any clues to whats going on?

Re: ide drive problem?

[Alan Cox]

> > hde: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> > hde: dma_intr: error=0x84 { DriveStatusError BadCRC }
> 
> Hmmm, I get this message as well about once a day (though it seems it
> could not cause any damage ... yet ...)

BadCRC is a transmission error on the IDE cable. It will be retried so
it isnt a problem. 

Re: ide drive problem? RFC

[Christian Bornträger]

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

> > > hde: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> > > hde: dma_intr: error=0x84 { DriveStatusError BadCRC }
> >
> > Hmmm, I get this message as well about once a day (though it seems it
> > could not cause any damage ... yet ...)
>
> BadCRC is a transmission error on the IDE cable. It will be retried so
> it isnt a problem.

I read this error message very often in the LKML. Why not making the error message more detailed, pointing to a FAQ entry or an help file or a hint to check the IDE cable?

As a aimple example, I made a patch against 2.4.9-ac14.


diff -ur linux/drivers/ide/ide.c linux-new/drivers/ide/ide.c
--- linux/drivers/ide/ide.c     Thu Sep 27 17:53:09 2001
+++ linux-new/drivers/ide/ide.c Fri Sep 28 17:26:16 2001
@@ -910,7 +910,8 @@
                if (drive->media == ide_disk) {
                        printk(" { ");
                        if (err & ABRT_ERR)     printk("DriveStatusError ");
-                       if (err & ICRC_ERR)     printk("%s", (err & ABRT_ERR) ? "BadCRC " : "BadSector ");
+                       if (err & ICRC_ERR)     printk("%s", (err & ABRT_ERR) ? "BadCRC.\
+Please check your IDE-cable." : "BadSector ");
                        if (err & ECC_ERR)      printk("UncorrectableError ");
                        if (err & ID_ERR)       printk("SectorIdNotFound ");
                        if (err & TRK0_ERR)     printk("TrackZeroNotFound ");







[-- Attachment #2: message.patch --]
[-- Type: text/x-diff, Size: 654 bytes --]

diff -ur linux/drivers/ide/ide.c linux-new/drivers/ide/ide.c
--- linux/drivers/ide/ide.c	Thu Sep 27 17:53:09 2001
+++ linux-new/drivers/ide/ide.c	Fri Sep 28 17:26:16 2001
@@ -910,7 +910,8 @@
 		if (drive->media == ide_disk) {
 			printk(" { ");
 			if (err & ABRT_ERR)	printk("DriveStatusError ");
-			if (err & ICRC_ERR)	printk("%s", (err & ABRT_ERR) ? "BadCRC " : "BadSector ");
+			if (err & ICRC_ERR)	printk("%s", (err & ABRT_ERR) ? "BadCRC.\
+Please check your IDE-cable." : "BadSector ");
 			if (err & ECC_ERR)	printk("UncorrectableError ");
 			if (err & ID_ERR)	printk("SectorIdNotFound ");
 			if (err & TRK0_ERR)	printk("TrackZeroNotFound ");

RFC (patch below) Re: ide drive problem?

[Christian Bornträger]

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

Hi List, Hi Andre,

as Mark Hahn made a FAQ entry for the  

hde: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hde: dma_intr: error=0x84 { DriveStatusError BadCRC }

message, I think we should point all users to this FAQ. I saw this message
and questions about it very often in this list, so we should help the users 
to find a fast solution. You know, only a few people read a manual, even in 
error case.

Now the output looks like:

hde: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hde: dma_intr: error=0x84 { DriveStatusError BadCRC }

For further Informations please check: http://www.tux.org/lkml/#s13-3



This patch applies correct for 2.4.9ac14 and 2.4.10

diff -r -u linux/drivers/ide/ide.c linux-new/drivers/ide/ide.c
--- linux/drivers/ide/ide.c     Fri Sep 28 17:36:54 2001
+++ linux-new/drivers/ide/ide.c Sat Sep 29 17:03:36 2001
@@ -935,6 +935,9 @@
                                        printk(", sector=%ld", HWGROUP(drive)->rq->sector);
                        }
                }
+               if ((stat & READY_STAT) && (stat & SEEK_STAT) && (stat & ERR_STAT)
+                && (err & ABRT_ERR) && (err & ICRC_ERR))
+                       printk("\nFor further Informations please check: http://www.tux.org/lkml/#s13-3\n");
 #endif /* FANCY_STATUS_DUMPS */
                printk("\n");
        }


greetings

Christian Bornträger

[-- Attachment #2: m.patch --]
[-- Type: text/x-diff, Size: 527 bytes --]

diff -r -u linux/drivers/ide/ide.c linux-new/drivers/ide/ide.c
--- linux/drivers/ide/ide.c	Fri Sep 28 17:36:54 2001
+++ linux-new/drivers/ide/ide.c	Sat Sep 29 17:03:36 2001
@@ -935,6 +935,9 @@
 					printk(", sector=%ld", HWGROUP(drive)->rq->sector);
 			}
 		}
+		if ((stat & READY_STAT) && (stat & SEEK_STAT) && (stat & ERR_STAT)
+		 && (err & ABRT_ERR) && (err & ICRC_ERR))
+		        printk("\nFor further Informations please check: http://www.tux.org/lkml/#s13-3\n");
 #endif	/* FANCY_STATUS_DUMPS */
 		printk("\n");
 	}

Re: RFC (patch below) Re: ide drive problem?

[Andre Hedrick]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=X-UNKNOWN, Size: 2075 bytes --]


This is an error that I am considering removing form the user's view.
For the very fact/reason you are pointing out; however, it becomse
more painful when performing error sorting.


On Sat, 29 Sep 2001, Christian [iso-8859-1] Bornträger wrote:

> Hi List, Hi Andre,
> 
> as Mark Hahn made a FAQ entry for the  
> 
> hde: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hde: dma_intr: error=0x84 { DriveStatusError BadCRC }
> 
> message, I think we should point all users to this FAQ. I saw this message
> and questions about it very often in this list, so we should help the users 
> to find a fast solution. You know, only a few people read a manual, even in 
> error case.
> 
> Now the output looks like:
> 
> hde: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hde: dma_intr: error=0x84 { DriveStatusError BadCRC }
> 
> For further Informations please check: http://www.tux.org/lkml/#s13-3
> 
> 
> 
> This patch applies correct for 2.4.9ac14 and 2.4.10
> 
> diff -r -u linux/drivers/ide/ide.c linux-new/drivers/ide/ide.c
> --- linux/drivers/ide/ide.c     Fri Sep 28 17:36:54 2001
> +++ linux-new/drivers/ide/ide.c Sat Sep 29 17:03:36 2001
> @@ -935,6 +935,9 @@
>                                         printk(", sector=%ld", HWGROUP(drive)->rq->sector);
>                         }
>                 }
> +               if ((stat & READY_STAT) && (stat & SEEK_STAT) && (stat & ERR_STAT)
> +                && (err & ABRT_ERR) && (err & ICRC_ERR))
> +                       printk("\nFor further Informations please check: http://www.tux.org/lkml/#s13-3\n");
>  #endif /* FANCY_STATUS_DUMPS */
>                 printk("\n");
>         }
> 
> 
> greetings
> 
> Christian Bornträger

I like that noise maker!

Cheers,

Andre Hedrick
CTO ASL, Inc.
Linux ATA Development
-----------------------------------------------------------------------------
ASL, Inc.                                     Tel: (510) 857-0055 x103
38875 Cherry Street                           Fax: (510) 857-0010
Newark, CA 94560                              Web: www.aslab.com

Re: RFC (patch below) Re: ide drive problem?

[Dave Jones]

On Sat, 29 Sep 2001, Andre Hedrick wrote:

> This is an error that I am considering removing form the user's view.
> For the very fact/reason you are pointing out; however, it becomse
> more painful when performing error sorting.

Another 'error' you may want to silence some time is the one
that appears when you query SMART status of a recent IBM drive.

hde: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hde: drive_cmd: error=0x04 { DriveStatusError }

This happens if the drive is SMART capable, but not SMART enabled,
and you ask it if it can do SMART.  Once you enable it, subsequent
queries work without spitting out the error.
(Unless you turn it off again)

I'm not sure if this a quirk of these drives (I've not seen it happen
on any other vendor), or the code.

regards,

Dave.

-- 
| Dave Jones.        http://www.suse.de/~davej
| SuSE Labs

Re: RFC (patch below) Re: ide drive problem?

[Andre Hedrick]

Sorry ABORTED commands are reported ad valid errors.
The case of SMART errors is that SMART may not be enabled in the device.

Cheers,

Andre Hedrick
CTO ASL, Inc.
Linux ATA Development
-----------------------------------------------------------------------------
ASL, Inc.                                    Tel: (510) 857-0055 x103
38875 Cherry Street                          Fax: (510) 857-0010
Newark, CA 94560                             Web: www.aslab.com

On Sat, 29 Sep 2001, Dave Jones wrote:

> On Sat, 29 Sep 2001, Andre Hedrick wrote:
>
> > This is an error that I am considering removing form the user's view.
> > For the very fact/reason you are pointing out; however, it becomse
> > more painful when performing error sorting.
>
> Another 'error' you may want to silence some time is the one
> that appears when you query SMART status of a recent IBM drive.
>
> hde: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
> hde: drive_cmd: error=0x04 { DriveStatusError }
>
> This happens if the drive is SMART capable, but not SMART enabled,
> and you ask it if it can do SMART.  Once you enable it, subsequent
> queries work without spitting out the error.
> (Unless you turn it off again)
>
> I'm not sure if this a quirk of these drives (I've not seen it happen
> on any other vendor), or the code.
>
> regards,
>
> Dave.
>
> --
> | Dave Jones.        http://www.suse.de/~davej
> | SuSE Labs
>

Re: RFC (patch below) Re: ide drive problem?

[Anders Eriksson]

On boot my bios reports the disks as "S.M.A.R.T. Capable but 
disabled". Any pointer to where I can read up on this? (the bios 
settings gives nothing).

/Anders


>>>>> On Sat, 29 Sep 2001, "Andre" == Andre Hedrick wrote:

  Andre> Sorry ABORTED commands are reported ad valid errors.  The
  Andre> case of SMART errors is that SMART may not be enabled in the
  Andre> device.

Re: RFC (patch below) Re: ide drive problem?

[Andre Hedrick]

cat /proc/ide/hda/smart_values
cat /proc/ide/hda/smart_thresholds

Does that work?

Andre Hedrick
CTO ASL, Inc.
Linux ATA Development
-----------------------------------------------------------------------------
ASL, Inc.                                    Tel: (510) 857-0055 x103
38875 Cherry Street                          Fax: (510) 857-0010
Newark, CA 94560                             Web: www.aslab.com

On Sat, 29 Sep 2001, Anders Eriksson wrote:

>
> On boot my bios reports the disks as "S.M.A.R.T. Capable but
> disabled". Any pointer to where I can read up on this? (the bios
> settings gives nothing).
>
> /Anders
>
>
> >>>>> On Sat, 29 Sep 2001, "Andre" == Andre Hedrick wrote:
>
>   Andre> Sorry ABORTED commands are reported ad valid errors.  The
>   Andre> case of SMART errors is that SMART may not be enabled in the
>   Andre> device.
>
>
>
>

Re: RFC (patch below) Re: ide drive problem?

[Anders Eriksson]

> 
> cat /proc/ide/hda/smart_values
> cat /proc/ide/hda/smart_thresholds
> 
> Does that work?
> 

Yes. Or at least I think so. I get get two chunks of numbers, most of which are zeros. What's their meaning?

The bios says smart is disabled yet I get these values, any correlation?

/Anders

Re: RFC (patch below) Re: ide drive problem?

[Nicholas Knight]

On Saturday 29 September 2001 01:16 pm, Andre Hedrick wrote:
> This is an error that I am considering removing form the user's view.
> For the very fact/reason you are pointing out; however, it becomse
> more painful when performing error sorting.
>

How about this: Put in a counter that displays the message proposed by 
Christian (hopefully with a quick update to the FAQ noting that if you 
see this, it might be a bad thing after 2.4.SomeRevision) every X times 
the error occurs, and that a boot parameter is added to turn this 
behavior off and return to the old behavior.

> On Sat, 29 Sep 2001, Christian [iso-8859-1] Bornträger wrote:
> > Hi List, Hi Andre,
> >
> > as Mark Hahn made a FAQ entry for the
> >
> > hde: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> > hde: dma_intr: error=0x84 { DriveStatusError BadCRC }
> >
> > message, I think we should point all users to this FAQ. I saw this
> > message and questions about it very often in this list, so we
> > should help the users to find a fast solution. You know, only a few
> > people read a manual, even in error case.
> >
> > Now the output looks like:
> >
> > hde: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> > hde: dma_intr: error=0x84 { DriveStatusError BadCRC }
> >
> > For further Informations please check:
> > http://www.tux.org/lkml/#s13-3

Re: RFC (patch below) Re: ide drive problem?

[Mark Hahn]

> This is an error that I am considering removing form the user's view.
> For the very fact/reason you are pointing out; however, it becomse
> more painful when performing error sorting.

yes, most of the time, the warning scares people unnecessarily.
but if the machine is seeing lots of CRC failures, there should 
definitely be some prominent messages.  perhaps something simple
like producing a warning if more than a few of recent IOs
have had CRC problems:

int crcState = 0;

on successful IO: 
	crcState >>= 1;

on CRC failure: 
	if (crcState)
		printk("dang, CRC failed on hda, see http://whatever");
	crcState = 1 << 10;

so if >10 IOs succeed between CRC failures, there's no warning.
(uh, I guess that would actually be 9, since presumably the retry
would succeed...)  keeping a global count of CRC failures would be
kind of nice, too.

regards, mark hahn.

Re: RFC (patch below) Re: ide drive problem?

[Andre Hedrick]

Mark, you have a valid point but if they see this level of noise the
auto-dma-downgrade feature set exclusive to Linux will ramp down the max.
performance from init to a reasonable threshold.  The object is to
stablize the transfer rates first and then maintain performance.

You know the song and dance my friend, if anyone does.  Very few could
keep me in check, but you have managed quite well and I am impressed!

Cheers,

Andre Hedrick
CTO ASL, Inc.
Linux ATA Development
-----------------------------------------------------------------------------
ASL, Inc.                                    Tel: (510) 857-0055 x103
38875 Cherry Street                          Fax: (510) 857-0010
Newark, CA 94560                             Web: www.aslab.com

On Sat, 29 Sep 2001, Mark Hahn wrote:

> > This is an error that I am considering removing form the user's view.
> > For the very fact/reason you are pointing out; however, it becomse
> > more painful when performing error sorting.
>
> yes, most of the time, the warning scares people unnecessarily.
> but if the machine is seeing lots of CRC failures, there should
> definitely be some prominent messages.  perhaps something simple
> like producing a warning if more than a few of recent IOs
> have had CRC problems:
>
> int crcState = 0;
>
> on successful IO:
> 	crcState >>= 1;
>
> on CRC failure:
> 	if (crcState)
> 		printk("dang, CRC failed on hda, see http://whatever");
> 	crcState = 1 << 10;
>
> so if >10 IOs succeed between CRC failures, there's no warning.
> (uh, I guess that would actually be 9, since presumably the retry
> would succeed...)  keeping a global count of CRC failures would be
> kind of nice, too.
>
> regards, mark hahn.
>