Sluggish performance with Slackware 12.2 2.6.27.7-smp on Gigabyte GA-8S649MF
SlackwareThis Forum is for the discussion of Slackware 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.
Sluggish performance with Slackware 12.2 2.6.27.7-smp on Gigabyte GA-8S649MF
Ello.
I'm currently running the unmodified Slackware 12.2 2.6.27.7-smp kernel on a GA-8S649MF motherboard from an old Fujitsu Siemens Scaleo P box with an Intel Pentium 4 HT 3,2GHz CPU and it's sluggish to say the very least.
lspci
Code:
00:00.0 Host bridge: Silicon Integrated Systems [SiS] SiS649 Host (rev 10)
00:01.0 PCI bridge: Silicon Integrated Systems [SiS] PCI-to-PCI bridge
00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS965 [MuTIOL Media IO] (rev 48)
00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev 01)
00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] AC'97 Sound Controller (rev a0)
00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.1 Controller (rev 0f)
00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.1 Controller (rev 0f)
00:03.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.1 Controller (rev 0f)
00:03.3 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller
00:05.0 IDE interface: Silicon Integrated Systems [SiS] 182 SATA/RAID Controller (rev 01)
00:06.0 PCI bridge: Silicon Integrated Systems [SiS] PCI-to-PCI bridge
00:07.0 PCI bridge: Silicon Integrated Systems [SiS] PCI-to-PCI bridge
00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
00:0c.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306 Fire II IEEE 1394 OHCI Link Layer Controller (rev 80)
01:00.0 VGA compatible controller: nVidia Corporation G72 [GeForce 7300 LE] (rev a1)
dmesg | grep CPU
Code:
SMP: Allowing 2 CPUs, 0 hotplug CPUs
PERCPU: Allocating 39452 bytes of per cpu data
NR_CPUS: 32, nr_cpu_ids: 2, nr_node_ids 1
Initializing CPU#0
SLUB: Genslabs=12, HWalign=128, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 0
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (24) available
CPU0: Intel(R) Pentium(R) 4 CPU 3.20GHz stepping 01
Initializing CPU#1
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 0
Intel machine check reporting enabled on CPU#1.
CPU1: Intel P4/Xeon Extended MCE MSRs (24) available
CPU1: Intel(R) Pentium(R) 4 CPU 3.20GHz stepping 01
checking TSC synchronization [CPU#0 -> CPU#1]: passed.
Brought up 2 CPUs
DMA seems to be on but the cached read speed is too low I think. This doesn't completely explain the Flash issue however. Are you sure that the NVIDIA driver is enabled and loaded correctly?
I noticed that your drive is hda. Isn't that a SATA drive? I'd expect it to be called sda. On some systems one needs the hda=noprobe boot option to correct this. Of course if this is the case for you, you will also adjust your /etc/fstab to be able to boot. I suggest that you try booting with that option to see if it detects your HDD as sda. If so, you can boot normally, change your fstab and lilo.conf (to add the hda=noprobe option) and reboot.
Edit: I just realized that "hda" might also be your cdrom. Could you clarify what your HDD is?
Well glxgears is not supposed to be a benchmarking tool but still, on my laptop with a GeForce 6150 Go card I get 1700 FPS, I believe you should get more than 700 FPS from GeForce 7300 LE.
And yes, if a SATA is detected as hda it may run much slower, there's even a warning about this slow performance and hda=noprobe thing in the CHANGES_AND_HINTS.txt file of the installation CD. I just made a Google search about your HDD and I think it's not a SATA drive, so the detection as hda might be correct. In that case I don't know if your cached read speed is OK, but I still feel that it's slow.
Is your system sluggish from the start or does it get like that after you run certain software?
I just made a Google search about your HDD and I think it's not a SATA drive, so the detection as hda might be correct.
Believe it or not, it has to do with the kernel module. There are 2 classes of kernel modules. The old and somewhat depreciated ATA/ATAPI model, and the newer libata. Libata calls everything /dev/sd$ doesn't matter if it is plugged into the actual SATA port, or the IDE port.
If you have both models compiled in, and both can be used, the older ATA/ATAPI model usually takes over, and everything will be called /dev/hd$. You can run lscpci -vvm -k. If it list two kernel modules, well there you go It should not produce conflicting modules though. I know with nforce3, Intel ICH6,7,8,9, and 10R it does not, but the OP has a sis chipset.
For the ATA/ATAPI driver
Code:
The following chipsets are supported:
ATA16: SiS5511, SiS5513
ATA33: SiS5591, SiS5597, SiS5598, SiS5600
ATA66: SiS530, SiS540, SiS620, SiS630, SiS640
ATA100: SiS635, SiS645, SiS650, SiS730, SiS735, SiS740,
SiS745, SiS750
Notice the ata16!!! That has to be a mistake
Libata supports both the pata and sata parts of that sis chipset as SATA_SIS and PATA_SIS.
For the flash, disable hardware acceleration on the flash options. Right click on a flash applet to get to the settings.
Believe it or not, it has to do with the kernel module. There are 2 classes of kernel modules. The old and somewhat depreciated ATA/ATAPI model, and the newer libata. Libata calls everything /dev/sd$ doesn't matter if it is plugged into the actual SATA port, or the IDE port.
Umm yes I remember now, a while ago they made the new libata enabled by default and there were people complaining about changing drive letter after kernel upgrade. So, hda=modprobe will hopefully work then.
Does enabling hardware acceleration make that much of a difference with Flash? At least here on my system it doesn't seem to have much effect. I still consider 700 fps with glxgears too low (and that should be independent of Flash). That's even worse than what I get in Virtualbox with my Geforce Go 6150.
Until some time ago the b43 drivers for my wireless chip were buggy and whenever the module got loaded it was making my system become sluggish and sometimes even go as far as freezing. I am wondering whether the OP might have a similar sort of issue (but I admit I can't see anything suspicious).
kslen you may also consider trying an earlier version of the NVIDIA driver, at least in my case the 180.xx series has been a bit buggy. My card is listed as being supported by 180.xx by I can use it with 173.xx just fine.
I set append=" hda=noprobe", boot=/dev/sda and root=/dev/sda1 in lilo.conf, changed fstab accordingly and had to call lilo -b /dev/hda in order for it to write mbr on the correct drive. Is this about as retarded as it gets or am I doing it right?
Anyhoo. It confirms during boot that the drive isn't supposed to be probed when listed by the kernel for the first time, but when it starts looking for sda1 in order to mount and continue, the kernel panics and whines about not being able to access a console. The kernel informs me of possible choices which are; hda.
It just struck me that there's an USB HDD connected which lay claim to sda, but I suppose this doesn't matter as hda would be assigned sda long before the USB HDD is initiated. Correct?
The thought behind using glxgears was to see wether or not hardware acceleration was up and running or not. It being able to render 660+ frames steadily even when moving the window around with compositing enabled indicates that the acceleration is working. Perhaps not optimally, but at least sufficiently to render the 25-30 frames flash needs to run smoothly. I've already disabled hardware acceleration in the flash settings. If it's not disabled, Firefox dies when going fullscreen as disturbed1 described above.
I'll try an older driver, but the sluggish performance was an issue even when setting up the box in a fb console long before starting X. So I think this goes deeper than the GPU concidering the cycles needed by the CPU to play a flash movie.
To put it this way, my 900MHz EEE PC and my AMD XP 1,7GHz, both with hardware acceleration disabled, plays my flash content silky smooth in comparison. Something has got to be wrong.
Sorry for not pasting my configuration files, I am able to get back into the os easily, but for now they are inaccessible to me as I am nowhere near the machine. I will post them later today when I get home. Hopefully this is enough information for you guys to point out where I'm failing.
I set append=" hda=noprobe", boot=/dev/sda and root=/dev/sda1 in lilo.conf, changed fstab accordingly and had to call lilo -b /dev/hda in order for it to write mbr on the correct drive. Is this about as retarded as it gets or am I doing it right?
That looks OK.
Quote:
Anyhoo. It confirms during boot that the drive isn't supposed to be probed when listed by the kernel for the first time, but when it starts looking for sda1 in order to mount and continue, the kernel panics and whines about not being able to access a console. The kernel informs me of possible choices which are; hda.
So does it detect a sda but can't read sda1 or it doesn't see sda at all?
Quote:
It just struck me that there's an USB HDD connected which lay claim to sda, but I suppose this doesn't matter as hda would be assigned sda long before the USB HDD is initiated. Correct?
I'd expect so.
Quote:
The thought behind using glxgears was to see wether or not hardware acceleration was up and running or not. It being able to render 660+ frames steadily even when moving the window around with compositing enabled indicates that the acceleration is working. Perhaps not optimally, but at least sufficiently to render the 25-30 frames flash needs to run smoothly. I've already disabled hardware acceleration in the flash settings. If it's not disabled, Firefox dies when going fullscreen as disturbed1 described above.
Ok if composite is on it may cause glxgears to report lower numbers, maybe that's the reason here.
Quote:
I'll try an older driver, but the sluggish performance was an issue even when setting up the box in a fb console long before starting X. So I think this goes deeper than the GPU concidering the cycles needed by the CPU to play a flash movie.
Agreed. I hope it's not something like my wireless card problem. Let's see if we can make the disk faster first.
Btw, could you post your lsmod output as well? Maybe it will give us clues about what to look for.
Anyhoo. It confirms during boot that the drive isn't supposed to be probed when listed by the kernel for the first time, but when it starts looking for sda1 in order to mount and continue, the kernel panics and whines about not being able to access a console. The kernel informs me of possible choices which are; hda.
Try blacklisting the driver in /etc/modprobe.d/blacklist. It's been so long since I've ran a stock Slackware kernel, I don't recall if these drivers are compiled in or as a module.
Also, do you have any other PCI cards? The PCI bus and AGP slot can share resources with some motherboards. You might want to try changing the AGP speed as well. From 8x to 4x.
Booting without the USB drive plugged in, and leaving it unplugged - does this change anything?
And lastly could you paste your xorg.conf, the sections between Section "Device" and the Section "Screen". So we can see what options you have enabled. Nvidia has an nvagp option, which can allow you to use the nvidia agp driver, the motherboards agp driver, or an auto select. That could be an option worth changing as well.
NVIDIA 180.51
You could also try .29. .51 has shown some problem for some people. I'm using .51 with my 9400, and haven't noticed any issues besides a couple of minor VDAPU regressions. All of my other cards are using either .29 or .44 Besides the 5500 which is legacy.
I recompiled my kernel and nuked pretty much everything not relevant to the systems devices. The machine is a tad bit more responsive at regular desktop use, however the issue regarding noprobe and flash is not gone.
The strange thing is, video.google.com content now plays pretty smoothly in fullscreen, but stuff from youtube.com lags horribly. You have to repeatedly hit the "exit fullscreen" button and hope you get one in, this is not in "HQ mode".. The very same content played with mplayer consumes mere 30-38% of the CPU so I'm starting to think that the flash thing might be out of my control.
It still doesn't explain this though.
hdparm -tT /dev/hda post recompile..
Code:
Timing cached reads: 258 MB in 2.01 seconds = 128.46 MB/sec
Timing buffered disk reads: 164 MB in 3.03 seconds = 54.05 MB/sec
And here's my configuration files as requested.
Oh, and the USB HDD has been disconnected.
This one fails complaining about not being able to locate sda1, available options are hda1, etc.
Not updated or tested after recompile. Didn't bother as the other example lists the drive as hda.
Generic IDE-ATAPI support was compiled into the previous kernel, but it has been nuked. Only drivers left are relevant to the motherboard.
Poked about in the BIOS for AGP options and found none. BIOS is from 2005. Perhaps I should look for an update. I'm under the impression that the youtube web player or this board is a load of...
Tried various versions from the NVIDIA 17x and 9x drivers and none of them was able to startx in 1360x768. They all reverted to 640x480 after failing 1024x768.
180.44 and above does handle 1360x768 and I haven't tried anything lower as of yet.
When you mention it, for some reason I didn't slot in my NIC at the very bottom this time. The current order of the slots is: #1: AGP, #2: PCI, #3: PCI with NIC, #4: PCI. I'll try moving it around to see if it has any effect, the plan is to expand with another NIC in the future, which might be why I left the bottom slot free come to think of it. ^^
Let's switch those drives over to libata. Your timed cache reads are slow IMO
Leave lilo, and fstab reading /dev/hd$.
Uncheck ATA/ATAPI/MFM/RLL support under device drivers. This will rid the kernel of the older drivers.
Under Serial ATA (prod) and Parallel ATA (experimental) drivers, I have these checked -
ATA ACPI Support
SATA Port Multiplier support (maybe someday )
AHCI SATA support
ATA SFF support
You should probably check these -
SiS 964/965/966/180 SATA support
Generic ATA support
SiS PATA support
Upon reboot, hit tab at the lilo screen type in the new kernel name and root=/dev/sda1. Give the root password when prompted for system maintenance. Remount / to edit the needed files.
mount -o rw,remount /
Edit lilo and fstab to change /dev/hd$ to /dev/sd$. Don't forget to run lilo
Ctrl-D to reboot.
The strange thing is, video.google.com content now plays pretty smoothly in fullscreen, but stuff from youtube.com lags horribly. You have to repeatedly hit the "exit fullscreen" button and hope you get one in, this is not in "HQ mode".. The very same content played with mplayer consumes mere 30-38% of the CPU so I'm starting to think that the flash thing might be out of my control.
Just to rule out video driver bugs, could you try disabling the composite extension for now?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.