Re: [expert] ML9.0:file system completely crashed ext3,"could not find mime type",kde3.0.3
J. Grant wrote:
> > Mandrake 9.0 uses UDMA5 automatically (without program hdparm),
> > is this configured on booting are is it written at installation of
> > ML9.0 in some configuration file?
> mdk9 does not use UDMA5 by default. Your HD/BIOS initalise themselves
> to what they consider to be the fastest stable speed and setttings etc
> less /etc/sysconfig/harddisks
> You can override what mdk9 has in that file to change stuff, default
> is often very slow.
Everything in that file is commented out, ah now I understand Todd's
reply ("Default is everything commented out, so it's whatever the kernel
natively recognizes. hdparm is only necessary if the kernel doesn't
quite recognize the ide controller chipset and you want to try to wring
every bit of performance you can out of it. Todd")
> > What program in Mandrake 9.0 is responsible for this, or is it just
> > the kernel that figures out what the highest UDMA setting is?
> man hdparm
No, hdparm is not installed in my freshly installed Mandrake 9.0 yet
dmesg shows:
"Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 89
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt8233 (rev 00) IDE UDMA100 controller on pci00:11.1
ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:DMA, hdd:pio
hda: WDC WD400BB-32CXA0, ATA DISK drive
hdc: LITE-ON LTR-24102B, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 78165360 sectors (40021 MB) w/2048KiB Cache, CHS=4865/255/63,
UDMA(100)"
for hda it reports UDMA(100), the ide controller chipset is recognized
as VIA vt8233 (rev 00) IDE UDMA100 controller.
I think it is this part of the kernel that is responsible for it:
"usr/src/linux-2.4.19-16mdk/drivers/ide/pci/via82cxxx.c"
> > I think this utility is also on the DataLifeGuard floppy disk
> > dlgudma.exe - Data Lifeguard Ultra ATA Management
> I'm not sure why are considering this program as it will never work
> on GNU/Linux or GNU/Wine.
No, it is a booting floppy disk, the utility changes the UDMA setting
on the hard disk itself.
> > Did the corruption occur with these messages in syslog:
> > "EXT3-fs error (device ide0(3,2)): ext3_new_block: Allocating block
> > in system zone - block = 294914" ? What do these messages mean?
> Did you install with a search for badblocks?
No, but on my new install of ML9.0 I did, install didn't tell if it
found any badblocks.
> e2fsck -f -c /dev/hdX can do it for you now, make sure you are in
> single user mode though and your HD is mounted ro.
I already reinstalled ML9.0, but I tried on this new install
"e2fsck -f -c /dev/hda2": and it returned a bunch of errors. And this
is after a fresh install. I'll complain about this in another thread.
vatbier
Want to buy your Pack or Services from MandrakeSoft?
Go to http://www.mandrakestore.com
Re: [expert] ML9.0:file system completely crashed ext3,"could not find mime type",kde3.0.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 J. Grant wrote on Wed, Feb 12, 2003 at 06:38:03PM + : > > mdk9 does not use UDMA5 by default. Your HD/BIOS initalise themselves > to what they consider to be the fastest stable speed and setttings etc > less /etc/sysconfig/harddisks > You can override what mdk9 has in that file to change stuff, default is > often very slow. Default is everything commented out, so it's whatever the kernel natively recognizes. hdparm is only necessary if the kernel doesn't quite recognize the ide controller chipset and you want to try to wring every bit of performance you can out of it. Blue skies... Todd - -- Never take no as an answer from someone who's not authorized to say yes. --Ben Reser on Cooker ML Mandrake Cooker Devel Version, Kernel 2.4.21pre4-5mdk -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+TWVDlp7v05cW2woRAnB1AJ9ddMvLus0DTyKfhKrqXiBr5eZOqACgqT88 PqgesfskaO+njgl4gAldQuk= =+bTO -END PGP SIGNATURE- Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] ML9.0:file system completely crashed ext3,"could not find mime type",kde3.0.3
On Wednesday 12 Feb 2003 4:11 pm, Dave Laird wrote: > There actually are several different problems I've either encountered or > read about: Thank you, David. I've never come up against these problems myself, but you never know when someone else's experience will come in handy. Your reply has been saved for future reference - just in case :) Anne -- Registered Linux User No.293302 Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] ML9.0:file system completely crashed ext3,"could not find mime type",kde3.0.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Good morning, ET... On Wednesday 12 February 2003 06:56 am, et wrote: > yep I just remeber the problems and thought they were overcome about the > same time as the 8 gig limit was overcome. That's your bogie. 8-) If you look at some of the comments made by Levitts, Gibson and others during that period, you'll also see where they *really* did most of their testing on the early Linux kernels, rather than on Windoze, because of the ability to punch the drive parameters in as conditions changed. I wish I knew where some of the written documentation from that period of time went. It was the first incidence of an open forum on drive specifications, but without it, we probably would still be using old, slow, small hard drives. Can you believe a 150 gigabyte UDMA/EIDE drive for under $300? Egods. How things change in this industry. They say Mandrake 9.1 and KDE 3.1 are both coming out the cooker soon. That, too, works for me. 8-) Dave - -- Dave Laird ([EMAIL PROTECTED]) The Used Kharma Lot / The Phoenix Project Web Page: http://www.kharma.net updated 01/20/2003 Usenet News server: news.kharma.net Musicians Calendar and Database access: http://www.kharma.net/calendar.html An automatic & random thought For the Minute: Goodbye, cool world. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+SnPEaE1ENZP1A28RAjb6AKCs9KEHyB+K2T1ZlWtIfVpO83J57wCaAjyX IlpUCV2JS3b2/T1st3QJ7HA= =Z6FE -END PGP SIGNATURE- Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] ML9.0:file system completely crashed ext3,"could not find mime type",kde3.0.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 G'morning, Anne... On Wednesday 12 February 2003 02:29 am, Anne Wilson wrote: > This is making interesting reading. Do you think the Maxtor problem is > specific to later, faster drives? I've run a Maxtor and Fujitsu in tandem > for longer than I care to think about, without problems. Mandrake > configures them correctly, too, but they are both 20GB disks, so not the > latest and fastest. There actually are several different problems I've either encountered or read about: 1. If a non-Maxtor drive is on the same EIDE channel, *some* troubles may occur, especially if the Maxtor is on a UDMA high-speed cable OR if the Maxtor drive is one of the "new breed" of high-speed drives. 2. If the Maxtor is a high-speed drive, on the primary, and the other drive on the channel is a low-speed Hitachi/Toshiba/Sanyo with the strange-looking motherboard (pre-wired instead of jumpers) it won't work at all. (Fujitsu drives seem to work, so long as they are relatively modern.) 3. There is an older (pre-1999) problem relating to Maxtor drives that Steve Gibson wrote about a few years ago, that *perhaps* describes some of the technical issues we are seeing with relationship to Mandrake. His article describes a lot of the technical issues involved in drive chain recognition, which is how the problem manifests itself. > Also, is it your experience that these problems occur only between pairs of > HDDs, or do they equally occur when the slave is a cd/dvd/cd-rw? I have seen some *really* cheap CD's that wouldn't work with Maxtor, but then they were really picky about anyone else's drives, too. Most of these types of problems occurred in the late 1990's, as I haven't seen any reoccurance of the problems since. Another choice problem that is easily recognized is an early CD (Promise?) that came with the sound card on the CD-ROM drive. They only seem to run on Windoze, and even iffy at that. So, if I were to hang my derierre *really* far out into target-space, I'd suggest the following rules: 1. Whenever possible, use the same drive speeds, especially if they are going to be attached to the same cable on the same channel. If you run into problems using a Maxtor drive and another drive manufactured by another company, put them on separate channels. 2. If you're going to use any of the new Maxtor UDMA high-speed drives and an older CD-ROM, especially an early CD-ROM R/W, make sure the CD is not on the same channel as the Maxtor. You'll get all kinds of interesting interactions if they are on the same channel, at least in my experience. 3. Again, the newest Maxtor drives don't work well, if at all, with some of the older slow Toshiba/Hitachi drives that came pre-configured (a WAG ) from the factory, didn't have any jumper slots on the motherboard, and for the most part were sold through package deals. I started to add Sanyo to this list, but I just looked at my notes and there is only one model of Sanyo drive I've seen that had this problem, and that was a *long* time ago. 4. Here's one I just saw the other day: Three hard drives, one CD-ROM on a newer motherboard-provided EIDE/UDMA channel. The only way the drives spun up properly was putting the new Maxtor high-speed on the Primary Master, the Seagate high-speed on Primary Slave, the second slower Seagate on Secondary Master, and the CD-ROM, a generic Sony look-alike on Secondary Slave. The slower Seagate would work, but the entire drive chain was *slowed* dramatically once you put the slow Seagate on the Primary channel. However, if you put it with the CD-ROM in the Slave position on the second channel, *everyone*, with the exception of the CD-ROM, ran at the enhanced speeds. The guy had 120 gigabytes of space at high speeds! I remember when 20 MEG cost a fortune. 5. Whenever possible, put the first high-speed Maxtor drives on the Primary chain as Master. They seem to like that. 8-) 6. Of course, in the same coin, some of the early Seagate EIDE slow drives refused to work with a Maxtor unless they are in the Master position. Again, there's a terribly funny piece floating around the internet about this phenomenon. And in case anyone thinks I'm bashing Maxtor drives, I'm not. I've been using Maxtor drives nearly exclusively as my personal choice for almost two decades in nearly every network machine in my office, and am *delighted* beyond words with their no-BS warrantee policies. Dave - -- Dave Laird ([EMAIL PROTECTED]) The Used Kharma Lot / The Phoenix Project Web Page: http://www.kharma.net updated 01/20/2003 Usenet News server: news.kharma.net Musicians Calendar and Database access: http://www.kharma.net/calendar.html An automatic & random thought For the Minute: "Don't discount flying pigs before you have good air defense." - -- [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+SnIeaE1ENZP1A28RAhXCAKC8I9n5XvqvweBJlfn8wXmHerz4BACgpoRz lgGwhZ6L0
Re: [expert] ML9.0:file system completely crashed ext3,"could not find mime type",kde3.0.3
On Wednesday 12 February 2003 09:31 am, Dave Laird wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > G'morning, ET... > > On Wednesday 12 February 2003 04:08 am, et wrote: > > > Without doing a *lot* of testing I'd hazard a guess that is as good a > > > generalization as you could find anywhere, and probably better than > > > some... with > > > the possible exception of Maxtor drives and most other non-Maxtor > > > drives, as noted previously. Another combination I remember vaguely > > > that ran into troubles > > > in the early testing I've done was using a Seagate EIDE slow drive on > > > the primary and a fast Seagate on the secondary, which only worked in > > > 16 bit mode, something else I never understood. 8-) > > > > was that in M$ products say before 1997? > > Yes, I believe that was the platform. There's an excellent article that > explains > some of the more technical aspects of why floating around the web written > by young Steve Gibson, I think. > > Dave > - -- > Dave Laird ([EMAIL PROTECTED]) > The Used Kharma Lot / The Phoenix Project > Web Page: http://www.kharma.net updated 01/20/2003 > Usenet News server: news.kharma.net > Musicians Calendar and Database access: http://www.kharma.net/calendar.html > > An automatic & random thought For the Minute: > Does the name Pavlov ring a bell? > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.0.7 (GNU/Linux) > > iD8DBQE+SlqvaE1ENZP1A28RAnwoAJ4o6Er6ZBmRAXoLZzIoybQCzF2xegCfVy/X > qL0n3ncFzlFsAauJgtrR5Dk= > =e5di > -END PGP SIGNATURE- yep I just remeber the problems and thought they were overcome about the same time as the 8 gig limit was overcome. Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] ML9.0:file system completely crashed ext3,"could not find mime type",kde3.0.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 G'morning, ET... On Wednesday 12 February 2003 04:08 am, et wrote: > > Without doing a *lot* of testing I'd hazard a guess that is as good a > > generalization as you could find anywhere, and probably better than > > some... with > > the possible exception of Maxtor drives and most other non-Maxtor drives, > > as noted previously. Another combination I remember vaguely that ran into > > troubles > > in the early testing I've done was using a Seagate EIDE slow drive on the > > primary and a fast Seagate on the secondary, which only worked in 16 bit > > mode, something else I never understood. 8-) > > was that in M$ products say before 1997? Yes, I believe that was the platform. There's an excellent article that explains some of the more technical aspects of why floating around the web written by young Steve Gibson, I think. Dave - -- Dave Laird ([EMAIL PROTECTED]) The Used Kharma Lot / The Phoenix Project Web Page: http://www.kharma.net updated 01/20/2003 Usenet News server: news.kharma.net Musicians Calendar and Database access: http://www.kharma.net/calendar.html An automatic & random thought For the Minute: Does the name Pavlov ring a bell? -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+SlqvaE1ENZP1A28RAnwoAJ4o6Er6ZBmRAXoLZzIoybQCzF2xegCfVy/X qL0n3ncFzlFsAauJgtrR5Dk= =e5di -END PGP SIGNATURE- Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] ML9.0:file system completely crashed ext3,"could not find mime type",kde3.0.3
civileme <[EMAIL PROTECTED]> wrote: > The X66 is safe to use as you have described it. What is dangerous is > overdriving. hdparm -k1 -d1 -X66 /dev/hda (66:UDMA2) I guess you mean if I change the hard drive setting with DataLifeGuard and then do "hdparm -d1 X69" (69:UDMA5) that this is dangerous, or if I try to set it to UDMA6 (:133Mhz)? Mandrake 9.0 uses UDMA5 automatically (without program hdparm), is this configured on booting are is it written at installation of ML9.0 in some configuration file? What program in Mandrake 9.0 is responsible for this, or is it just the kernel that figures out what the highest UDMA setting is? > Also, IIRC, DataLifeGuard phones home and gives you warning if your > drive is about to fail (and it works on non-WDs too). DataLifeGuard is just an utility on a floppy disk, or does it install a phone home program in Windows XP? > As for the variance of speed, consider this... Ok, then I'll probably set it with hdparm to UDMA2. Hm, where is the -k1 option for hdparm written to? man hdparm doesn't talk about a configuration file. > yes check out man elvtune man elvtune: I/O elevator tuner: don't know enough about it to understand this. > a secondary cosmic ray is a significant noise source. Not much charge > moves on those cables at the interface voltage in that time span. "secondary cosmic ray": didn't know it was that delicate, how are IDE-cables protected on the Space Station and what speed would they have? > You can download an ATA66 disable utility (windows compatible) for > your WD. I think this utility is also on the DataLifeGuard floppy disk dlgudma.exe - Data Lifeguard Ultra ATA Management Something else I wonder: A lot of system files (e.g. /usr/bin/play) disappeared, they were cleared because of corruption (bad mode,deleted/unused inode,illegal character device,...). Did the corruption occur with these messages in syslog: "EXT3-fs error (device ide0(3,2)): ext3_new_block: Allocating block in system zone - block = 294914" ? What do these messages mean? I have no idea how on low-level files are written to hard drives. I guess that over the IDE-cable a command must be sent (write/read) with an address (where to store/read on the hard drive) and the data that must be written ( how is this done? Do 512 bytes of data have to be written even if you only want one bit changed? I guess from Civilemes postings that sectors of data on a hard drive are 512 bytes, is this correct? Or do you have to write a full cluster (: group of sectors) even if you want one bit changed?) How could the corruption on my file system have occurred? Was a "read" command changed to a "write" command, was an address changed into another address so that an important part of the file system got overwritten that resulted in massive file corruption? In syslog there were about 22345 messages indicating inodes, files as corrupt. How many writes are needed to corrupt that many files? Did it just occur with one command or was my system producing random data corruption during several seconds? Or is it possible that the data on my hard drive was OK, but that it got corrupted when it got read by my system? Does Linux check, reread when it encounters CRC-errors? Is it possible that data corruption occurs without being noticed immediately? Is it only noticed when a damaged block is read and compared to its CRC? On another partition I have Windows XP: could corruption just as well have occurred during a Windows XP session? Would Windows XP also have noticed it at the next booting? I read that Western Digital supports only Windows and Solaris, does this mean that its drivers for these OSes protect better against CRC-errors in UDMA 3,4,5? Can Linux protect against these possible errors by rereading the hard drive after a write command and thus checking if it was written correctly? Would a double check like this seriously affect performance? Last question: what hard drives do you recommend: Maxtor, Seagate? I read through some hard drive forums, isn't clear which hard drives are the best. vatbier Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] ML9.0:file system completely crashed ext3,"could not find mime type",kde3.0.3
On Tuesday 11 February 2003 11:29 pm, Dave Laird wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Good evening, Damon... > > On Tuesday 11 February 2003 07:05 pm, Damon Lynch wrote: > > It still may matter. But I don't know - that's why I am asking :-) > > > > Supposing you have a UDMA 100 as master, and a UDMA 33 as slave. > > Conceivably they may both drop down to UDMA 33, and the master runs a > > bit faster than the slave simply because it is the master. > > Normally that is all true *EXCEPT* there is a differential factor that I > just mentioned to someone else on this list about Maxtor drives running on > the same IDE channel as a non-Maxtor drive, regardless whether they match > or not, will not "cooperate". > > > Maybe that is not what will happen. Either way, I'm curious to know > > what the experts think! I've heard conflicting stories from different > > folks (mostly off this list). > > Without doing a *lot* of testing I'd hazard a guess that is as good a > generalization as you could find anywhere, and probably better than some... > with > the possible exception of Maxtor drives and most other non-Maxtor drives, > as noted previously. Another combination I remember vaguely that ran into > troubles > in the early testing I've done was using a Seagate EIDE slow drive on the > primary and a fast Seagate on the secondary, which only worked in 16 bit > mode, something else I never understood. 8-) was that in M$ products say before 1997? Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] ML9.0:file system completely crashed ext3,"could not find mime type",kde3.0.3
On Wednesday 12 Feb 2003 4:29 am, Dave Laird wrote: > Normally that is all true *EXCEPT* there is a differential factor that I > just mentioned to someone else on this list about Maxtor drives running on > the same IDE channel as a non-Maxtor drive, regardless whether they match > or not, will not "cooperate". This is making interesting reading. Do you think the Maxtor problem is specific to later, faster drives? I've run a Maxtor and Fujitsu in tandem for longer than I care to think about, without problems. Mandrake configures them correctly, too, but they are both 20GB disks, so not the latest and fastest. Also, is it your experience that these problems occur only between pairs of HDDs, or do they equally occur when the slave is a cd/dvd/cd-rw? Anne -- Registered Linux User No.293302 Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] ML9.0:file system completely crashed ext3,"could not find mime type",kde3.0.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Good evening, Damon... On Tuesday 11 February 2003 07:05 pm, Damon Lynch wrote: > It still may matter. But I don't know - that's why I am asking :-) > > Supposing you have a UDMA 100 as master, and a UDMA 33 as slave. > Conceivably they may both drop down to UDMA 33, and the master runs a > bit faster than the slave simply because it is the master. Normally that is all true *EXCEPT* there is a differential factor that I just mentioned to someone else on this list about Maxtor drives running on the same IDE channel as a non-Maxtor drive, regardless whether they match or not, will not "cooperate". > Maybe that is not what will happen. Either way, I'm curious to know > what the experts think! I've heard conflicting stories from different > folks (mostly off this list). Without doing a *lot* of testing I'd hazard a guess that is as good a generalization as you could find anywhere, and probably better than some... with the possible exception of Maxtor drives and most other non-Maxtor drives, as noted previously. Another combination I remember vaguely that ran into troubles in the early testing I've done was using a Seagate EIDE slow drive on the primary and a fast Seagate on the secondary, which only worked in 16 bit mode, something else I never understood. 8-) Dave - -- Dave Laird ([EMAIL PROTECTED]) The Used Kharma Lot / The Phoenix Project Web Page: http://www.kharma.net updated 01/20/2003 Usenet News server: news.kharma.net Musicians Calendar and Database access: http://www.kharma.net/calendar.html An automatic & random thought For the Minute: Yes, but every time I try to see things your way, I get a headache. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+Sc23aE1ENZP1A28RAnoaAJ9LjF/wn/BwT6wYP4homb8WmDp0yACdEX/8 LfqkOxWCM91fBinEvxD0Dp8= =zB4Z -END PGP SIGNATURE- Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] ML9.0:file system completely crashed ext3,"could not find mime type",kde3.0.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Good evening, James... On Tuesday 11 February 2003 06:28 pm, James Sparenberg wrote: > I've had similar results but specifically when it's a maxtor drive and a > non maxtor in the slave position. They didn't play nice at all. Now if > I had the Maxtor paired up with another one running the same DMA > level... no problem. Yes, I recognize that tune. Try a Sanyo-Toshiba low-speed drive and any Maxtor high-speed drive on the same IDE channel. They simply won't work, even if you call Maxtor and order one of their service & support books, which they don't even sell anymore, anyway. Dave - -- Dave Laird ([EMAIL PROTECTED]) The Used Kharma Lot / The Phoenix Project Web Page: http://www.kharma.net updated 01/20/2003 Usenet News server: news.kharma.net Musicians Calendar and Database access: http://www.kharma.net/calendar.html An automatic & random thought For the Minute: Don't let people drive you crazy when you know it's in walking distance. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+SbupaE1ENZP1A28RAjg9AJ4sf3M/ToAcQgnTv5pMnyWvdHdbnQCguPxM E1MGc1zcqrcpC3IHj4uiNqs= =A/Ne -END PGP SIGNATURE- Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] ML9.0:file system completely crashed ext3,"could not find mime type",kde3.0.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Good afternoon, Anne... On Tuesday 11 February 2003 12:53 pm, Anne Wilson wrote: > There's an old saying > > The faster the master, > The slower the slave > > It wouldn't matter which way round if you were right. Actually about six months back or so I did a relative speed test using a series of different UDMA drives on an enhanced system under various O/S platforms to see if anything had changed since the last time. Under *certain* conditions, that axiom no longer applies. However, I also willingly admit, despite doing a *lot* of skull-banging, I haven't figured out why, or for that matter, what has changed in how hard drive parameters are recognized under Linux. For example, under Mandrake using a fast high-speed 40 gigabyte drive, in approximately 40% of the time it was recognized by Mandrake as a fast drive, and deployed appropriately. If the slave was *also* a UDMA drive, it, too, was configured correctly. Even a lowly Iomega Zip Drive was configured as a fast access drive. Go figure, sez I. I even tried it using several different brands of drives, since I was neither scientific nor exacting about it. When it worked it was a thing of marvel. However, just now having stuck my foot so nicely into my mouth, I couldn't then account for the other 60% of the time when one or both drives were recognized and configured as pokey slow EIDE drives. I repeated this test four or five times, and even had a fast drive be recognized two *different* ways several times. I know instinctively it is in the libraries somewhere, but I don't have a clue. FWIW, I was able to replicate the same test results using Micro$oft Windoze 98 and backwards a time or two. For the most part, Windows 98 Second Edition and upwards recognizes the drive geometry correctly every time. Can I buy an axiom now? Dave - -- Dave Laird ([EMAIL PROTECTED]) The Used Kharma Lot / The Phoenix Project Web Page: http://www.kharma.net updated 01/20/2003 Usenet News server: news.kharma.net Musicians Calendar and Database access: http://www.kharma.net/calendar.html An automatic & random thought For the Minute: Reality is for people who lack imagination. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+SWccaE1ENZP1A28RApucAKCt/8hp17uC1Z7XvEXAbOcOdG/vaQCcDXAK kRoHv4eh7qTWjLR+GL/C9Lc= =VQIe -END PGP SIGNATURE- Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] ML9.0:file system completely crashed ext3,"could not find mime type",kde3.0.3
On Tuesday 11 Feb 2003 8:36 pm, Damon Lynch wrote: > On Wed, 2003-02-12 at 07:57, civileme wrote: > > pair was a WD. (As an aside from this, if you have enough IDE channels > > to do it, put one hard drive per channel and use the other (slave) side > > for CDROM or Zip or whatever, not only to avoid crosstalk but for > > efficient operation.) > > Hi civilme, > > Is this true when the slave does not function in DMA mode, or at a much > lower DMA mode? I've heard that IDE defaults to the mode of the slowest > device on the channel. What is you experience with this? > There's an old saying The faster the master, The slower the slave It wouldn't matter which way round if you were right. Anne -- Registered Linux User No.293302 Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] ML9.0:file system completely crashed ext3,"could not find mime type",kde3.0.3
On Monday 10 February 2003 11:05 pm, vatbier wrote: > civileme <[EMAIL PROTECTED]> wrote: > > WD drives of the generation you are using do not calculate that same > > CRC for comparison--they store it in their big 600-byte sectors along > > with the 512 bytes of data. They may calculate the first in a series > > of writes, but not all. > > > >The drive is safe enough run at udma2 (33Mhz and 32 byte CRCs) or > > > > If you cannot put a better drive in that box, a 40-pin cable could > > make a big difference for the safe operation, to force 33MHz or lower > > transfer speed. > > Thanks! > I had already read that WD and UDMA5 give problems but my hard drive > WD400BB-32CXA was bought in april 2002. Were can I find the generation > info that my drive has no good CRC checking at UDMA3,4,5? I searched the > Western Digital website (wdc.com) but they don't give that kind of > information. Do the new WD400BB drives do correct CRC checking? > > You say "They may calculate the first in a series of writes, but not > all.": where can I find that kind of insight info, I searched the net > but apart from some of your postings haven't found much else. > > I don't have a 40-pin cable. If I use the hdparm command > hdparm -k1 -d1 -X66 /dev/hda (66:UDMA2), would this give the same > effect? Can changing the UDMA setting with hdparm give problems/errors? > I also downloaded from the WDC website Data Lifeguard Tools that can > change the udma setting on the hard drive itself. If I used this to > change the UDMA to 2, would my linux have no problems with this (I'm a > a little scared to use hdparm or WDC tools, in "man hdparm" they state > "Use with extreme caution! This feature includes zero protection for > the unwary, and an unsuccessful outcome may result in severe filesystem > corruption!") ? > > How can I prevent CRC errors? Can an IDE-cable suddenly become bad, or > experience interference, I read about twisted cables, ... > "The HDD should NOT be mounted near the power supply due to fan issues. > The fan in the supply causes the HDD to misinterpret CRC-checksums and > produces CRC-errors. Also, high-speed CD drives should not be near the > HDD" : fan causing CRC-errors? CD drives ? > > How much slower is UDMA2 than UDMA5? (hdparm -t), You said somewhere > that the performance does not differ much? The X66 is safe to use as you have described it. What is dangerous is overdriving. Win98 isn't going to give you more than what it has drivers for, so the DataLifeguard should not be necessary. Also, IIRC, DataLifeGuard phones home and gives you warning if your drive is about to fail (and it works on non-WDs too). Yes you are not going to find much info on the WD drive and their strategy to produce cheap drives ... These days they say they are fully compatrible with advanced UDMA, but offer no details, which is itself suspicious. The last time I exchanged emails with Andre Hedrick, we were still experiencing problems, but I have been out of the loop for some time. I wrote a program for 8.0/8.1 called drakopt which exhaustively tested options under hdparm for a given rig of drives, and set up the optimization. On some of the rigs the Crashtesters had, when the drive was set to highest rated speed and another drive was on the same channel there would be crosstalk errors. That was not supposed to happen either; only one drive on an IDE channel is supposed to be on at a time, but it was happening when one of a pair was a WD. (As an aside from this, if you have enough IDE channels to do it, put one hard drive per channel and use the other (slave) side for CDROM or Zip or whatever, not only to avoid crosstalk but for efficient operation.) As for the variance of speed, consider this... The PCI bus is 33MHz and 32 bits wide--the data transfer cable for IDE is 16 bits wide and up to 133Mhz, already twice what the PCI bus can handle, so the "speed" has to be burst mode cause there are controllers for IDE at 133MHz which plug into the PCI bus. Overwhelmingly, the consideration has to be with the disk itself, where data spins on or off of it at 1/60 the rate of the interface, approximately. Buffering helps, and lookahead helps, and elevator tuning helps (yes check out man elvtune), but the mechanical end of things is very slow compared to the rest of it. To increase disk speed, the most productive approaches are: *Increase spin rate *Software or hardware driven striping (RAID0 RAID4 RAID5) with multiple disks, especially if chunk size is controlled so that the switch to a different drive most frequently occurs when the first drive would need to step. The pinout on IDE cables is available here: http://www.howstuffworks.com/ide3.htm Of course with like 30 nanoseconds pulse width and data transfer on rising and falling edges, we are talking about something where a secondary cosmic ray is a significant noise source. Not much charge moves on those cables at the interface voltage in th
Re: [expert] ML9.0:file system completely crashed ext3,"could not find mime type",kde3.0.3
civileme <[EMAIL PROTECTED]> wrote: > > WD drives of the generation you are using do not calculate that same > CRC for comparison--they store it in their big 600-byte sectors along > with the 512 bytes of data. They may calculate the first in a series > of writes, but not all. > >The drive is safe enough run at udma2 (33Mhz and 32 byte CRCs) or > > If you cannot put a better drive in that box, a 40-pin cable could > make a big difference for the safe operation, to force 33MHz or lower > transfer speed. Thanks! I had already read that WD and UDMA5 give problems but my hard drive WD400BB-32CXA was bought in april 2002. Were can I find the generation info that my drive has no good CRC checking at UDMA3,4,5? I searched the Western Digital website (wdc.com) but they don't give that kind of information. Do the new WD400BB drives do correct CRC checking? You say "They may calculate the first in a series of writes, but not all.": where can I find that kind of insight info, I searched the net but apart from some of your postings haven't found much else. I don't have a 40-pin cable. If I use the hdparm command hdparm -k1 -d1 -X66 /dev/hda (66:UDMA2), would this give the same effect? Can changing the UDMA setting with hdparm give problems/errors? I also downloaded from the WDC website Data Lifeguard Tools that can change the udma setting on the hard drive itself. If I used this to change the UDMA to 2, would my linux have no problems with this (I'm a a little scared to use hdparm or WDC tools, in "man hdparm" they state "Use with extreme caution! This feature includes zero protection for the unwary, and an unsuccessful outcome may result in severe filesystem corruption!") ? How can I prevent CRC errors? Can an IDE-cable suddenly become bad, or experience interference, I read about twisted cables, ... "The HDD should NOT be mounted near the power supply due to fan issues. The fan in the supply causes the HDD to misinterpret CRC-checksums and produces CRC-errors. Also, high-speed CD drives should not be near the HDD" : fan causing CRC-errors? CD drives ? How much slower is UDMA2 than UDMA5? (hdparm -t), You said somewhere that the performance does not differ much? Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] ML9.0:file system completely crashed ext3,"could not find mime type",kde3.0.3
On Sunday 09 February 2003 03:54 am, vatbier wrote: > Mandrake Linux 9.0 here: > I installed alsa-utils from CD1 with MCC:Software Install: > in /var/log/syslog these error messages appeared (SEE BELOW): > > "XT3-fs error (device ide0(3,2)): ext3_new_block: Allocating block in > system zone - block = 294914" > > Then I rebooted (because I wanted to boot in runlevel 3 to see > whether I could play sound..., not relevant here). > Error bootmessages appeared (SEE BELOW FOR MORE DETAILS): > > "fsck: /dev/hda2 contains a file system with errors, check forced"... > fsck: /dev/hda2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. > failed to check filesytem. Do you want to repair the errors? Y/N > (beware, you can lose data) > > I pressed Yes: > a lot of inodes were fixed or cleared > ABOUT 22345 MESSAGES APPEARED (SEE BELOW) > "/dev/hda2: file system was modified " > > I was in runlevel 3: tried a few commands but those weren't recognized. > > Booted into KDE: > about 25 windows appeared that said: > "could not find mime type application/octet stream" > or "could not find mime type application/x-executable" > or "could not find mime type application/x-desktop" > or "could not find mime type application/x-shellscript" > Each window has to be pressed twice to get rid of. > There are some Konqueror windows open from the former session, > I can use them to browse the internet or my file system. > I can not start programs from the menu, in my file system a lot of > files have now file type mime. > FINALLY I FOUND OUT THAT A LOT OF FILES WERE GONE, FROM > DIFFERENT DIRECTORIES. > I also have a Konsole window open: except for basic commands no command > is recognized. > I searched Google, found nothing useful, search function of > [EMAIL PROTECTED] mailing list didn't work. > Is there an easy way to repair my system or do I have to reinstall > everything?? > I have a backup from 3 weeks ago, but that won't bring back the lost > files from /bin, /user/sbin,etc. > UPDATE: I searched Google for "ext3_new_block: Allocating block in > system zone": I found the ext3-user mailing-list and read and learned a bit > about file system corruption. > I tested my memory with memtest86 but no errors were detected, I read > that this is not conclusive. > I probably will reinstall Mandrake Linux 9.0. > But how can I figure out what has caused the corruption: > Memory, hard disk, IDE cable, IDE controller, UDMA, CPU, cooling,...? > And how can I best recover from this: reinstall complete distribution and > then apply backups? How can I figure out which files have been modified or > disappeared? > > I also remember that in the same session KNode newsreader crashed when I > tried to read a newsmessage after downloading the headers of > alt.os.linux.mandrake. It crashed several times. > > My system: > AMD AthlonXP 1600+ > Motherboard MSI K7T266 Pro2 (MS-6380 V2.0): VIA KT266A, VIA VT8233 > 512 MB memory (tested it with memtest86: no errrors detected) > Western Digital Caviar 40GB 7200RPM: UDMA is enabled I think (see below for > info from dmesg) > Mandrake Linux 9.0 (kernel 2.4.19-16mdk) > On this disk I also run: WinXP,Win98,Mandrake8.2(ext2) : no problem with > these OSes so far. > > Very frustrated after this happened, I thought linux file systems were > stable. UPDATE: No longer very frustrated, just a little; this is the first > time in six years I experience such a problem. > > vatbier > > ERROR MESSAGES AFTER INSTALLATION ALSA-UTILS: > LOOK AT LINES WITH * IN FRONT OF IT: > Jan 31 13:55:22 this rpmdrake[1711]: Extracting header of > xine-alsa-0.9.13-3mdk.i586 from /var/lib/urpmi/hdlist.Internationa > Jan 31 13:55:22 this rpmdrake[1711]: removed files/directories > (recursively) /root/tmp/headers/ > Jan 31 13:55:26 this rpmdrake[1711]: removed files/directories > (recursively) /root/tmp/headers/ > *Jan 31 13:55:53 this kernel: EXT3-fs error (device ide0(3,2)): > *ext3_new_block: Allocating block in system zone - block = 294914 > *Jan 31 13:55:53 this kernel: EXT3-fs error (device ide0(3,2)): > *ext3_new_block: Allocating block in system zone - block = 294915 > Jan 31 14:01:00 this CROND[1754]: (root) CMD (nice -n 19 run-parts > /etc/cron.hourly) > Jan 31 14:03:40 this rpmdrake[1711]: Installing package > removable://mnt/cdrom/Mandrake/RPMS//alsa-utils-0.9.0-0.6rc2mdk > Jan 31 14:03:46 this kernel: ISO 9660 Extensions: Microsoft Joliet > Level 3 > Jan 31 14:03:46 this kernel: ISO 9660 Extensions: RRIP_1991A > *Jan 31 14:03:49 this kernel: EXT3-fs error (device ide0(3,2)): > *ext3_new_block: Allocating block in system zone - block = 294916 > *Jan 31 14:03:49 this kernel: EXT3-fs error (device ide0(3,2)): > *ext3_new_block: Allocating block in system zone - block = 294917 > ABOUT 190 OF THESE ERROR MESSAGES APPEARED. > > BOOTING: ABOUT 22345 MESSAGES APPEARED: > Jan 31 14:29:22 this fsck: /dev/hda2 contains a file system with > errors, check forced > Jan 31 14:29:25 this /etc/hotplug/usb.agent: ... no modules for US
