From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1F9mIm-00074X-Lb for garchives@archives.gentoo.org; Thu, 16 Feb 2006 16:48:21 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k1GGkDXe001741; Thu, 16 Feb 2006 16:46:13 GMT Received: from pisces.voicesignal.com (mail.voicesignal.com [66.147.180.53]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id k1GGWbmN027647 for ; Thu, 16 Feb 2006 16:32:37 GMT Received: by pisces.voicesignal.com (Postfix, from userid 65534) id 35C9A5BD10; Thu, 16 Feb 2006 11:32:37 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by pisces.voicesignal.com (Postfix) with ESMTP id DBDAF5BD52 for ; Thu, 16 Feb 2006 11:32:35 -0500 (EST) Received: from [192.168.1.213] (jgrant.lan.voicesignal.com [192.168.1.213]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by pisces.voicesignal.com (Postfix) with ESMTP id 6988E5AA0F for ; Thu, 16 Feb 2006 11:32:32 -0500 (EST) Message-ID: <43F4A922.1090602@comcast.net> Date: Thu, 16 Feb 2006 11:32:34 -0500 From: Jeff User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051010 X-Accept-Language: en-us, en Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: [gentoo-user] Re: [gentoo-security] AMD64 + Hard Drive weirdness... References: <43F492F9.7030803@comcast.net> <200602160943.25294.robert@sixthings.com> In-Reply-To: <200602160943.25294.robert@sixthings.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS snapshot-20020531-rek2 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on pisces.voicesignal.com X-Spam-Level: X-Spam-Status: No, hits=-4.2 required=2.0 tests=BAYES_00,FROM_ENDS_IN_NUMS autolearn=no version=2.64 X-Archives-Salt: ad824ede-c347-41f7-aafd-5b62128df45d X-Archives-Hash: 8822ebb4d2d735856db733e51eb9356a Moving my thread over to the proper list... first... Now then - thanks to everyone on the list for your help. I've had barely any sleep lately, so I must apologize first, for putting the original thread onto the security mailing list by mistake. For anyone who's wondering - I have an AMD64 box, with a new Gentoo AMD64 install. The hard drive read times are obnoxiously slow - so, I'm going to attribute this to the wrong driver being loaded for the controller. See here: hdparm -tT /dev/hda /dev/hda: Timing cached reads: 3016 MB in 2.00 seconds = 1507.91 MB/sec Timing buffered disk reads: 4 MB in 3.68 seconds = 1.09 MB/sec Horribly slow! This machine should be blazing fast, with the 7200 rpm 200 GB hard drive, AMD64 3500+ processor, 1.5 MB RAM, and very modern motherboard to compliment. So, in the meantime, I'm trying to track down the culprit that's making my drive run so slow. Here's my lspci: 00:00.0 Host bridge: ATI Technologies Inc RS480 Host Bridge (rev 10) 00:02.0 PCI bridge: ATI Technologies Inc RS480 PCI-X Root Port 00:12.0 IDE interface: ATI Technologies Inc ATI 4379 Serial ATA Controller 00:13.0 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller 00:13.1 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller 00:13.2 USB Controller: ATI Technologies Inc IXP SB400 USB2 Host Controller 00:14.0 SMBus: ATI Technologies Inc IXP SB400 SMBus Controller (rev 11) 00:14.1 IDE interface: ATI Technologies Inc Standard Dual Channel PCI IDE Controller ATI 00:14.3 ISA bridge: ATI Technologies Inc IXP SB400 PCI-ISA Bridge 00:14.4 PCI bridge: ATI Technologies Inc IXP SB400 PCI-PCI Bridge 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:00.0 VGA compatible controller: nVidia Corporation NV41.0 (rev a2) 02:05.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) 02:09.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) 02:0a.0 Multimedia audio controller: Creative Labs SB0400 Audigy2 Value And modules: Module Size Used by nvidia 4057916 12 snd_pcm_oss 56224 0 snd_mixer_oss 19392 1 snd_pcm_oss eth1394 22608 0 snd_emu10k1 122180 1 snd_rawmidi 30112 1 snd_emu10k1 snd_seq_device 10576 2 snd_emu10k1,snd_rawmidi snd_ac97_codec 108120 1 snd_emu10k1 snd_pcm 100936 3 snd_pcm_oss,snd_emu10k1,snd_ac97_codec snd_timer 27336 2 snd_emu10k1,snd_pcm snd_ac97_bus 3392 1 snd_ac97_codec snd_page_alloc 12560 2 snd_emu10k1,snd_pcm snd_util_mem 6016 1 snd_emu10k1 snd_hwdep 11936 1 snd_emu10k1 3c59x 50420 0 mii 7040 1 3c59x ata_piix 12548 0 sata_vsc 9988 0 sata_sis 9796 0 sata_sx4 15812 0 sata_nv 11652 0 sata_via 10436 0 sata_svw 9540 0 sata_sil 11588 0 sata_promise 14148 0 libata 65296 9 ata_piix,sata_vsc,sata_sis,sata_sx4,sata_nv,sata_via,sata_svw,sata_sil,sata_promise sbp2 27076 0 ohci1394 35532 0 ieee1394 109752 3 eth1394,sbp2,ohci1394 ohci_hcd 22340 0 uhci_hcd 34848 0 usb_storage 71360 0 usbhid 41056 0 ehci_hcd 35336 0 I'll be spending the rest of the day trying to figure out what's going on here. Of course, if anyone has some insight, that would ultimately be most helpful! Off to work I go... Thanks all on the list(s). Robert Larson wrote: > Hello Jeff, > > > I've had 3 machines exhibit this kind of behaviour in the last few months. > > On the first machine, it was an intermitten IDE controller failure (probably > related to heat and expansion of motherboard compoenents). I was able to > bypass it by installing a PCI SATA controller. The way that I was able to > figure this out was by running knoppix on it (I tried windows too, just in > case). When running knoppix (and, that OTHER os), the problems still > occured. > > The second and third machines were having problems because the wrong drivers > were loaded for the motherboard IDE controller. On the first of these > machines, I ran knoppix and it correctly loaded the drivers (I used lsmod to > find them ;-). On the second of these machines, it was a production machine, > and it took a lot of time because I couldn't just bring it down. I was > getting "operation not permitted" when trying to enable DMA. Eventually, I > had performed lspci, and saw the controller, then noticed that it was > compiled into the kernel as a different controller. > > As far as it goes for your situation, I would recommend running knoppix to see > if the autodetection can resolve it. If that doesn't work, it may be that > it's simply getting confused between those two similar controllers. Does > "hdparm /dev/hda" show any useful info? How about "hdparm -i /dev/hda"? If > you try to make settings (such as set DMA "hdparm -d1 /dev/hda") does it spit > out errors? I think hdparm may tell you more in this situation because the > disc reads are insanely slow (1MB/sec should be more like 50MB/sec). It > might be worth walking through this just to see if it gives you any errors: > http://gentoo-wiki.com/HOWTO_Use_hdparm_to_improve_IDE_device_performance > > I hope this gives you enough to go on... > > > Regards, > > > Robert Larson > > > > On Thursday 16 February 2006 08:58 am, Jeff wrote: > >>Hey all. >> >>Gentoo Linux AMD64 - running pretty sweet - except, I've noticed that >>even under minimal loads, my system seems to have mini-lockups >>frequently. For instance, when downloading a mere 10 emails, my system >>seems to choke - to the point where I can't even move my mouse for a >>good 10 seconds or so. Opening a gnome-terminal is painful - sometimes, >>apps make the desktop freeze for a good 20-30 seconds. I did a large >>emerge last night using the gnome-terminal, and it rendered my Gnome >>desktop almost completely frozen. >> >>Any idea what might be causing this, and what steps I should take to >>troubleshoot this? The best I can tell, the problem seems to be hard >>drive related, as it does a lot of chewing before the app finally let's >>rip. The hard drive is an IDE, not SATA as you might expect from the >>info below. Other than these strange mini-lockups, my system is buzzing >>right along at a good clip! >> >>Thanks! >> > > [snip] -- Jabba the Hutt: This bounty hunter is my kind of scum: fearless and inventive. -- gentoo-user@gentoo.org mailing list