Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Originally posted by Aussie Check the IDE cable, I used to get errors like this and it was a bad cable.
Thanks, i'll give that a shot. It is a really old IDE cable, i'm taking the HDD back as well just because I bought it 2 days ago and they won't have any problems taking it back and swapping it out. I've sense ran a fsck -v -c on it and it comes up with more bad blocks every day. It's up to 817 bad blocks now, and comes up with short reads when I try to access certain files. I've tried other cables that are udma that are even older and they give same errors in same spots, and seem to work fine with other drives from my other computer. Hopefully it's not the the HDD controler on the motherboard
Ok, from a quick search of the LKML it seems that support for the kt400 is in the 2.5.xx kernel and a patch for 2.4.xx is in the works. You best bet is to upgrade as soon as support arives, probably in 2.4.21pre*.
Yeah, I've been waiting for support for this chipset before I upgrade my 1g tbird and kt7a, built it in jan 00 and it was a killer then....bit old now, but it still works well.
Mid 80's....I was living down near Byron Bay untill 87, then at New Farm for a few years.
I reluctantly upgraded a 1000 Tbird (running 1450) and EPoX 8KTA3/PC150 rig last week... I was burned with KT133a problems and just expected the KT400 to be an improvement. In reality, it look slike the VT8235 SouthBridge is the issue here. I have looked at ide-via.c and notice "future" support for the 8235 chip in the chipset table structure, but cant find the where the conditional test would be defined (so I asume its not). I dont feel like "breaking" my filesystems one more time this week, so I will leave DMA off and wait patiently for a new kernel...
Originally posted by dnar I have the same problem, Maxtor 40GB on a Gigabyte GA-7VAXP (KT400 & 8235 chipset). If I turn off DMA, the problem goes away...
Still looking around, it appears to be a problem with VIA & the kernel...
I tried turing off DMA but it was after fsck already marked 800 bad blocks on the disk... so the data kept giving "short reads". I went ahead and toook the whole thing back because it did it when I slapped it into my other machine (diff cbls and chipset). It's not a fast computer or antyhing, old sis chipset with ulta66 and a celeron 500 CPU /w 128mb pc100 sdram (doest go 133... just 100). I think it was the HDD, i got a 60gb 7200rpm maxtor because the 30gb we're not on sale ($54 @ frys... 60gb was $89).
One more thing about the prob, when i ran fsck -c -y it would go through but ask if it wanted ot "ignore" a short read or error and fix some of them that were bad blocks etc... then reboot and find "inconsistancies" and force fsck again and reboot etc... was that just because the filesystem got corrupted or because the HDD was bad and kept giving different responses?
I got anyone quick question while I got someone on the line. When I try hdparm -t /dev/hda or -T it never seems to get 66mb/s which I thought ulta66 would do correct? Even playing with the params I can only get up to 5Megs a second, and it's about 4-5 with default settings... am I missing something or is this a readout different from something? I did buy a new ultraDMA cbl just in case that was it... seems like 5mb instead of 66 (and the drive is Ultra133) is a LOT slower.
If you get "short reads" while doing an "e2fsck" - I can guarrantee that the errors reported will be bogus and the fixups will not be right. Instead, abort out and do "e2fsck -c" to find and mark bad blocks.
I hand patched the via82cxxx.c from version 3.34 (2.4.19 kernel) to 3.35 - this adds support for the VIA VT8235 Southbridge. This appears to have solved the problem, but I will not be 100% confident until I it's run for a few days. I am watching the kernel logs like a hawk.
BTW, the RedHat 8.0 kernel (2.4.18-14) appears to be patched already. The reason I updated to 2.4.19 was that I run Win4Lin and require a patched kernel, and patches for RedHat 8 kernel where not initially available, yet patches for the plain 2.4.19 where. So, if your running the RedHat 8 kernel, you should be ok.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.