Re: FYI: DMA/33 and kernels
George Bonser wrote: On Sun, 18 Oct 1998, Philip Thiem wrote: You'd be surprises how often that can happen. I purchase from a wholesaler, and they don't check to see if the drives are good, though they have allways been good about replacing them. Many resalers are similar, though some do do some testing. Well, considering that I had exactly the same errors on two different brands of drive on two different brands of motherboard and was able to fix it in exactly the same way in both cases with the only thing common between the two systems being Linux well, you get my point. George Bonser The Linux We're never going out of business sale at an FTP site near you! And I have have had a problem with a DMA/33 harddrive. Philip Thiem -- PENQUIN-LOVER-CODER ALERT: [EMAIL PROTECTED] All windows user please exvacuate the building (So I can install a better OS on the comps) Pass on the GAS get NASM instead.
Re: FYI: DMA/33 and kernels
You'd be surprises how often that can happen. I purchase from a wholesaler, and they don't check to see if the drives are good, though they have allways been good about replacing them. Many resalers are similar, though some do do some testing. Philip Thiem Michael Stone wrote: Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): On Sat, Oct 17, 1998 at 01:11:25PM -0700, George Bonser wrote: In my case, no, it is definately a problem with the linux ide driver and how it handles UDMA drives. I have seen exactly the same problem on two different systems with two different hard drives of different manufacture with different motherboards and chipsets. Once I got enough features disabled (turning off the drive's internal readahead with hdparm -A0, turning off multiwrite with -m0, eliminating filesystem readahead with -a0) and turning off enough BIOS features, I finally have a drive that I have had two Quantum drives basically eat themselves (the sound they make is like an old window shade spring suddenly snapping back with a 'whirr' noise). They have been UDMA drives, running on an Asus MB with a K6-233, and Debian 2.0 running the default kernel. So I am very much interested in what you report! FWIW, I also had two drives go south. One was a 8G Maxtor, one was a 6G WesternDigital bought as an emergency replacement for the Maxtor. The Maxtor started losing things, and the WD had a loud clicking death. I pulled another 8G Maxtor out of a working system and put it in the linux machine and haven't had any problems since then. As unlikely as it seems, I can only conclude that I got burned with two bad drives. Mike Stone -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null -- PENQUIN-LOVER-CODER ALERT: [EMAIL PROTECTED] All windows user please exvacuate the building (So I can install a better OS on the comps) Pass on the GAS get NASM instead.
Re: FYI: DMA/33 and kernels
On Sat, Oct 17, 1998 at 01:11:25PM -0700, George Bonser wrote: In my case, no, it is definately a problem with the linux ide driver and how it handles UDMA drives. I have seen exactly the same problem on two different systems with two different hard drives of different manufacture with different motherboards and chipsets. Once I got enough features disabled (turning off the drive's internal readahead with hdparm -A0, turning off multiwrite with -m0, eliminating filesystem readahead with -a0) and turning off enough BIOS features, I finally have a drive that I have had two Quantum drives basically eat themselves (the sound they make is like an old window shade spring suddenly snapping back with a 'whirr' noise). They have been UDMA drives, running on an Asus MB with a K6-233, and Debian 2.0 running the default kernel. So I am very much interested in what you report! In addition to the hdparm params you suggest, I wonder if you would be kind enough to list some of the BIOS features that are also suspects in this UDMA conundrum? In both cases that I mentioned above I had turned off the 'auto' UDMA detect, so that the drives were being recognized as just LBA, Mode 4 (is that right?, my memory is foggy here...). Thanks a bunch, Bob Bernstein
Re: FYI: DMA/33 and kernels
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): On Sat, Oct 17, 1998 at 01:11:25PM -0700, George Bonser wrote: In my case, no, it is definately a problem with the linux ide driver and how it handles UDMA drives. I have seen exactly the same problem on two different systems with two different hard drives of different manufacture with different motherboards and chipsets. Once I got enough features disabled (turning off the drive's internal readahead with hdparm -A0, turning off multiwrite with -m0, eliminating filesystem readahead with -a0) and turning off enough BIOS features, I finally have a drive that I have had two Quantum drives basically eat themselves (the sound they make is like an old window shade spring suddenly snapping back with a 'whirr' noise). They have been UDMA drives, running on an Asus MB with a K6-233, and Debian 2.0 running the default kernel. So I am very much interested in what you report! FWIW, I also had two drives go south. One was a 8G Maxtor, one was a 6G WesternDigital bought as an emergency replacement for the Maxtor. The Maxtor started losing things, and the WD had a loud clicking death. I pulled another 8G Maxtor out of a working system and put it in the linux machine and haven't had any problems since then. As unlikely as it seems, I can only conclude that I got burned with two bad drives. Mike Stone
Re: FYI: DMA/33 and kernels
BTW, I have configured it down to one single error message that I can't
seem to shake:
hdc: write_intr: status=0xff { Busy }
ide: reset: success
This is what is leading me to believe that the driver is either attempting
a transaction before an earlier one completed ( is the drive attempting an
internal prefetch? ) or it timed out waiting for the previous command to
complete.
Something like that. I had today the same problem with Intel SE440BX
motherboard and a Fujitsu 2gig udma drive. I changed the drive to a
Quantum 3,2 gig one and it went away.
Seems to be a problem with the harddisk.
--j
Re: FYI: DMA/33 and kernels
just a few ideas. is your hd the slave or master, and if the master is there a slave connected to the same cable? Is the ide interface connected to the ISA or PCI bus? Belive it or not some pci motherboards still have the ide interface connected to the ISA side! (some have only the secondary interface connected to the ISA for use with slower CD rom drives). My pc has the TX chipset and both interfaces are pci. The hd is the only device on interface 1, interface 2 has my CD and LS120 drives. What speed is your cpu? How much cache and dram. I have 64MB dram and 512K cache with a K6-233. I would think that the ide interface has a ready/busy status and the driver would wait for the drive, but maybe the drive is giving an advanced ready signal? ---George Bonser [EMAIL PROTECTED] wrote: I have managed to significantly reduce the error rate by turning OFF everything in the bios settings that might improve the performacne of IDE. This includes read-ahead, multi, IDE-PCI bursting, etc. Then I turned the items back on in hdparms. Now down to a half-dozen errors per day with 2.0.35. I think some things were done after 2.0.32 to improve performance of the IDE but I am going to have to diff the two drivers to make sure. Something DEFINATELY changed between 2.0.32 and 2.0.33+. I suspect that a delay between operations was shortened since most of my errors appear to be that the drive is busy when a command to it is issued meaning either that the ide driver does not wait long enough for a command to complete or that it times out too quickly waiting for a command to complete. Might be time to do some hacking on ide.c On Tue, 13 Oct 1998, Kenneth Scharf wrote: I am using a maxtor udma 5.4GB drive on an intel TX (triton II) mb with a K6-233 cpu. I have run 2.0.33 and now are using 2.0.34 with no problems. Previously used a maxtor 2.0 gb udma drive, again no problems. -- I get the same exact results with my PPro system (Intel 440FX chipset) and Maxtor 7.2GB UDMA drive. This even happens under the developmental kernel 2.1.122 which I use for the better SMP handling. I've asked questions before on newsgroups and such as to what could be causing this behavior, or if anybody else had even seen this kind of behavior, but never got any response. Sean _ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com George Bonser The Linux We're never going out of business sale at an FTP site near you! _ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com
RE: FYI: DMA/33 and kernels
On Tue, 13 Oct 1998, Kenneth Scharf wrote: just a few ideas. is your hd the slave or master, and if the master is there a slave connected to the same cable? It doesn't matter. I have tried it as master, slave, master with a slave and master alone ... no change. Hi Kenneth, Many drives have three jumper settings: (1)Single, (2)Master, (3)Slave. If your drive is like this, you will probably need to set the jumper from `Master' to `Single' if you want to start your system with only that drive installed. HTH, --David
Re: FYI: DMA/33 and kernels
Sean Johnson wrote:
I get the same exact results with my PPro system (Intel 440FX chipset) and
Maxtor 7.2GB UDMA drive. This even happens under the developmental kernel
2.1.122 which I use for the better SMP handling. I've asked questions
before on newsgroups and such as to what could be causing this behavior, or
if anybody else had even seen this kind of behavior, but never got any
response.
I'm using 2.34 and have not recieved a problem yet. My machine is a
Cyrix 200MMX with a VIA VP3 chipset and a Maxtor 4.3 Gig UDMA33. I
don't have the UDMA feature of the kernel in use, I use the standard IDE
driver. Maybe this is a hardware problem, a result of too low of
bandwidth (since Win probably never tries to use the full bandwidth
capacity of these drives)?
Mark Panzer
Sean
MORE INFO
WHat I mean to say is that if you install a DMA/33 drive that claimes to
be compatable with IDE, I get a ton of errors that look like this:
hdwhatever: multwrite_intr: status=0x51 { DriveReady SeekComplete Error }
hdwhatever: multwrite_intr: error=0x04 { DriveStatusError }
hdwhatever: status timeout: status=0xd0 { Busy }
hdwhatever: no DRQ after issuing WRITE
ide1: reset: success
I get MANY fewer with 2.0.32. In fact, I get many per minute with
2.0.3(3-5) yet only a few per day with 2.0.32. This is with plain vanilla
hdparm settings (i.e. the defaults)
Also, with 2.0.35 I kept getting errors for illegal blocks, accesses
beyond the end of the device, fsck failures due to illegal blocks in
inodes requiring manual repair, etc. None of these problems with 2.0.32.
I first noticed this earlier this year when I installed an 8G drive on a
2.0.33 box. I could not keep the bux running more than a day until I
reverted to 2.0.32 and put the large disk as the slave on the primary IDE.
These are two different brands of motherboards with two different chipsets
that show the same results.
--
Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null
Re: FYI: DMA/33 and kernels
I am using a maxtor udma 5.4GB drive on an intel TX (triton II) mb with a K6-233 cpu. I have run 2.0.33 and now are using 2.0.34 with no problems. Previously used a maxtor 2.0 gb udma drive, again no problems. -- I get the same exact results with my PPro system (Intel 440FX chipset) and Maxtor 7.2GB UDMA drive. This even happens under the developmental kernel 2.1.122 which I use for the better SMP handling. I've asked questions before on newsgroups and such as to what could be causing this behavior, or if anybody else had even seen this kind of behavior, but never got any response. Sean _ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: FYI: DMA/33 and kernels
I get the same exact results with my PPro system (Intel 440FX chipset) and
Maxtor 7.2GB UDMA drive. This even happens under the developmental kernel
2.1.122 which I use for the better SMP handling. I've asked questions
before on newsgroups and such as to what could be causing this behavior, or
if anybody else had even seen this kind of behavior, but never got any
response.
Sean
MORE INFO
WHat I mean to say is that if you install a DMA/33 drive that claimes to
be compatable with IDE, I get a ton of errors that look like this:
hdwhatever: multwrite_intr: status=0x51 { DriveReady SeekComplete Error }
hdwhatever: multwrite_intr: error=0x04 { DriveStatusError }
hdwhatever: status timeout: status=0xd0 { Busy }
hdwhatever: no DRQ after issuing WRITE
ide1: reset: success
I get MANY fewer with 2.0.32. In fact, I get many per minute with
2.0.3(3-5) yet only a few per day with 2.0.32. This is with plain vanilla
hdparm settings (i.e. the defaults)
Also, with 2.0.35 I kept getting errors for illegal blocks, accesses
beyond the end of the device, fsck failures due to illegal blocks in
inodes requiring manual repair, etc. None of these problems with 2.0.32.
I first noticed this earlier this year when I installed an 8G drive on a
2.0.33 box. I could not keep the bux running more than a day until I
reverted to 2.0.32 and put the large disk as the slave on the primary IDE.
These are two different brands of motherboards with two different chipsets
that show the same results.
