video playback slowed down

[pickarooney]

In the last week I've spiced up my desktop a bit, changed KDE theme from Keramik to Baghira, changed around most of the icons and activate two graphic effects - transparent menus and kicker icons that grow on mouseover.
I'm not sure if there's a link, but any time I play back a video stream now it's quite jerky, and it's very irritating.
Can anyone confirm that the changes I made could have a possible effect on video playback speed, and if so can you explain briefly how? Aside from undoing all the lovelifying, are there ways to improve the playback smoothness?

Because my graphics card driver doesn't support TV-out, I have to use the standard vesa driver, which is obviously going to be slower, but there's nothing I can do about that. I thought about changing the screen size down to 800x600 or even lower for TV playback (I currently have two display setups, one with an ATI driver for normal PC use and one vesa setup for TV-out) but didn't manage to do it - the available options in harddake2 are all weird formats, but there's no 800x600 available. I tried changing the Modeline in XF86Config-4 but it had no effect; I think I'm doing it wrong.

Lastly, mplayer is installed via rpm. Would there be anything to gain from recompiling it from source with the --disable-runtime-cpudetection flag?

[Hayl]

is this media beng played from a hard drive or from a DVD/CD ROM?

if so, then use hdparm to unmask the irqs on the device(s).

[pickarooney]

From the hard-drive. It's even slower directly from the CD I think.

Do you mean this:

hdparm -u /dev/hdb6 ?

Can you explain briefly what it does? I've read bad stories about hdparm, so I'm just a tad cautious.



hdparm /dev/hda

/dev/hda:
multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 65535/16/63, sectors = 80043264, start = 0
[root@marklar Themes]# hdparm /dev/hdb1

/dev/hdb1:
multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 16383/255/63, sectors = 11261502, start = 63
[root@marklar Themes]# hdparm /dev/hdb6

/dev/hdb6:
multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 16383/255/63, sectors = 144536742, start = 11759643


Looks like it's already optimised :(






P.S. in case anyone happened to read my thread about the mice earlier, I deleted the whole thing by accident instead of one post. Turn out BOTH mice had myteriously broken overnight. With a third one, it works.

[mrBen]

There is a distinct possibility that more effects in KDE will slow down the machine, and you would notice it most in video playback.

Simplest thing to try is to disable them and see if it resolves it.

[pickarooney]

It's difficult to tell, as the skipping isn't always in the same place. I reckon that is the case though. I like the old effects when doing normal PC stuff, though.

I must figure out a way to switch between effects in PC mode and minimal fuss in TV mode. Something like automatically rebooting into fluxbox, disabling effects, reducing the screen resolution, that I can add to my SwitchDisplay.sh script, so when I Ctrl-Alt-Backspace it's set up in minimal FX mode and when I run the script again and Ctrl-Alt-Backspace the extra bits are back.

This can be my project for the week. All pointers welcome :)
(also, all radeon 7000/tv-out drivers welcome :D )

[Hayl]

yes, it does look like you have the irq unmasked already on everything.

the effects of unmasking the irq is covered in the man page for hdparm.

[pickarooney]

Mplayer is being stroppy and won't compile. Another solution bites the dust!

Time to roll up the sleeves and get scripting. Or treat mysefl to some hardware upgrades now that the missus has a new job :D

[cybertron]

The latest version of MPlayer doesn't compile with the Mandrake version of gcc. There's a compiler bug that gets exposed, but there is a simple fix. See my home page in my sig, it's on the first page under Recent News (although it's not actually very recent:)).

[pickarooney]

Tried that change (in yesterday's CVS version) but it bombs out straight away with error: `CONFIG_X86_L1_CACHE_SHIFT' undeclared (first use in this function)

also tried running mplayer from a minimal gui (fluxbox with nothing fancy added) but it's as bad as anything. This is really depressing, when stuff jus stops working like this. There's nothing for it but to upgrade to a supported gfx card :( Thanks for your help, everyone.

[cybertron]

CVS version usually aren't the most stable. Have you tried the regular pre5 sources?

[pickarooney]

I might do it later, but I think the problem is elsewhere. Xine is being just as jerky now. I think it's about time I bought a new video card, one with proper linux support this time.

Just as a matter of interest, how are these hdparm results?

(home partition)
/dev/hdb6:
Timing buffer-cache reads: 340 MB in 2.29 seconds = 148.30 MB/sec
Timing buffered disk reads: 44 MB in 3.02 seconds = 14.55 MB/sec

(root partition)
/dev/hdb1:
Timing buffer-cache reads: 424 MB in 2.01 seconds = 210.56 MB/sec
Timing buffered disk reads: 44 MB in 3.05 seconds = 14.40 MB/sec

Seems there might be a buffer problem, I might copy the file somewhere else and try read it from there.

[cybertron]

Whoa, what kind of hard drive is that? Even my laptop drive gets better than those numbers, especially the buffer-cache reads. I don't want to say for sure that that's where your problem lies, but I think I'd definitely look into it.

[pickarooney]

The master (hdb) is a Western Digital 80Gb@7200 rpm with 8MB cache.
The slave (hda) is a Maxtor 40Gb @5600 (I think, though it might be 7200).

All the other info I have is attached, and my system specs are below.

[mrBen]

Are you using 40- or 80-core cables for your drives? If you are using 40 you may be getting some interference between the lines, which can cause problems with reading/writing from a drive.

[pickarooney]

Not sure, I googled for images of 40 and 80 core cables, but none were IDE cables. Let's assume they are 40-core, if I remove the slave HD and re-run hdparm, and the results are the same, would that rule out that answer or might the other IDE cable (DVD-combo drive) also interfere? I can always disconnect both and try again.

If the results are a significant improvement (any idea what those results should be - double, triple?) can I just replace them with 80-core or does the mobo have to be compatible with 80-core?

[mrBen]

Ways to tell 40 from 80:

1. 40 has less cables in it ;)
2. 80 _usually_ has coloured plugs - blue for the mobo, black for master and grey for slave.

2 different cables will not interfere (ie for your 2 ide channels). But 2 drives on the same channel can do.

80 core use the same size plugs as 40, but are better for drives with DMA. Some mobos will 'downgrade' the drive speed if there is interference.

I'm afraid I've no idea exactly what the difference will be, but it's worth a try ;)

[pickarooney]

Mine are all grey. I'll try set the slave free tonight and see how the master fares out on his own.

[pickarooney]

Oh dear, turns out the small 5600 rpm drive was master and system disk.
I tried rearranging them, but got a kernel panic. I lost a jumper too, as the diagram for slave on the small drive said to connect it to only one pin.
Had a spare one, luckily.

How do I change the system disk to the faster HD? The boot sector/MBR seems to be on the big disk as it gets as far as LILO when only this disk is connected.

A lesson, kids - you should never drink and rearrange disk drives.

[cybertron]

Hmm, that's an interesting problem. I think you might be able to boot off the first or second Mandrake install CD and tell it to reinstall LILO, and if you have the correct disk as Master it should work. I think.:)

I can't say that for sure though because it might mess with the drive assignments (hda1, 2, etc) so maybe it will still install it on the wrong drive. Something to try though.

[pickarooney]

System disk error mean means LILO is on the small disk? the boot menu comes up with only the big disk though. the jumper diagram is messed up on my HD, it says to only connect it to one pin, but it falls of only one pin :confused:

[cybertron]

I think I'm confused now. If the small disk was the master, I would have thought that LILO would have been installed on that and now you would need to install it on the other drive to be able to boot. Maybe that's not how LILO works though. I'm hardly an expert;)

About the jumpers: Connecting a jumper to a single pin doesn't accomplish anything. I have no idea why the diagram would show that. The reason you use jumpers is to connect two pins so that current flows between them, so putting it on a single pin is rather pointless in my mind. Maybe for slave mode you don't need jumpers at all?

[pickarooney]

That's what I thought about jumpers, it's also a sure way of losing them!
Perhaps it doesn't need to be there at all, as it showed up on the BIOS screen as the slave drive.

I'll also see can I figure out how to fix the boot sequence so the small drive isn't needed.

I'm very confused myself, not sure where to begin with this.

[pickarooney]

OK, it seems the boot partition is on the small, slow drive. lilo.conf has this line:

boot=/dev/hda

If I move the boot partition to the bigger drive, is it likely to make a difference? Do I just need to reboot with the installation CD and go to rescue mode then create a /boot partition somehow?

[cybertron]

I don't know for sure, but I think there's some way to tell LILO to install itself on a different drive than the default one. Right off hand I don't recall how, but I'm sure it's in the man page if it's possible.

As far as whether that will make a difference, I have no idea. Even a 5600 RPM drive should be able to play videos I would think. My laptop does fine and I'm sure that's not faster than a 5600, maybe even a 4200.

[pickarooney]

Tried to reinstall the OS, without the small drive, so everythign would go on the big drive, but I got a message saying there was no valid HD to create a boot partition. What the hell is going on here? I feel like throwing the whole thing out the window, nothing makes sense any more :mad:

Thanks a million for all your help, but I'm as lost as I was at the beginning. :confused:

[glasdave]

I think you have to reformat the new drive...to add a book partion to it. It's almost like having a new drive installed.

[pickarooney]

That sounds like overkill. If that's true, then I don't know if it's worth wiping my home partition when I'm not sure it will increase the speed.

[pickarooney]

Hmm, should I be able to create a boot partition on hdb with diskdrake, and reboot without the smaller drive? I suppose I'd have to edit lilo.conf and maybe some other files?

Nope. Diskdrake doesn't allow creation of a boot partition. I think glasdave is right, short of formatting the whole thing there's no way of booting from hdb. Balls to this.

[retsaw]

First, why do you need a boot partition? I've never used one and have never had any problems.

If I understand it correctly, you want to remove your small drive which is hda (master) and just try using your other drive which is currently hdb. I would just create a boot directory on your root partition and copy the contents of your boot partition onto the new directory (you will have to mount your boot partition elsewhere to do this). Change the entries in your /etc/fstab from hdb to hda (and also removing any references to hda). Change the entries in your /etc/lilo.conf from hdb to hda. Making sure your old boot partition is not mounted at /boot, run lilo with the "-b /dev/hdb" option, this will tell lilo to install to the mbr on your hdb. Then you disconnect your small hard drive and jumper your other drive to master and it should work. If it doesn't work you may need to boot from a rescue disk/live cd and chroot into your root partition to re-run lilo and also double check for any mistakes you may have made when changing your fstab and lilo.conf.

[cybertron]

Originally posted by retsaw
...run lilo with the "-b /dev/hdb" option...
That was the option that I was thinking of earlier.

I would tend to agree that you shouldn't need a separate partition to put LILO on. I believe that the MBR is set aside and can't be partitioned, so you should be able to install LILO on it without any messing around, of that sort at least.

[pickarooney]

I'm probably using wrong terms a lot of the time.
mount doesn't show any /boot partition mounted, but I do have a directory called /boot although I can't tell which drive it's on. df -k . in /boot gives:

Filesystem 1K-blocks Used Available Use% Mounted on
/dev/ide/host0/bus0/target1/lun0/part1
5542276 3638412 1622328 70% /



dev/ide/host0/bus0/target1/lun0/part1 on / type ext3 (rw)
none on /proc type proc (rw)
none on /proc/bus/usb type usbdevfs (rw)
none on /dev type devfs (rw)
none on /sys type sysfs (rw)
none on /dev/pts type devpts (rw,mode=0620)
/dev/ide/host0/bus0/target1/lun0/part6 on /home type ext3 (rw)
none on /mnt/floppy type supermount (rw,sync,dev=/dev/fd0,fs=ext2:vfat,--,umask=0,iocharset=iso8859-15,codepage=850)
/dev/ide/host0/bus0/target0/lun0/part1 on /mnt/windows type vfat (rw,umask=0,iocharset=iso8859-15,codepage=850)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)


When I talk about a boot partion, what I mean is probably the MBR.

At what stage can I run lilo -b /dev/hdb ? In rescue mode, from a boot disk or just from a normal console?

[retsaw]

It looks like you don't have a seperate boot partition, so you don't need to worry about that.

Originally posted by pickarooney
At what stage can I run lilo -b /dev/hdb ? In rescue mode, from a boot disk or just from a normal console?

You can just run it from a normal console as root. You only need a rescue disk if you can't boot normally. Before you run it you will need to make the changes to your lilo.conf, your fstab will also need to be changed before you change your hdb to hda. If you have already removed the small drive and changed the other drive to master you won't need to use the "-b /dev/hdb" option.

[pickarooney]

Sweet. In work ATM, but I'll try it tonight.

Changes made to lilo.conf and fstab.
Simply type lilo as root
Power down, remove small drive, change big drive to master.
Power up.
Cross fingers.

If things were to go wrong and I couldn't boot, in order to change back to a bootable status, I'd need to be able to access the bigger hard drive to reedit lilo.conf and fstab. I should be able to do this with a boot floppy and the mount command. I just need to check the syntax and have it ready.

Thanks a million again.

[pickarooney]

Well, that was a complete disaster!

I edited lilo.conf and fstab then shut down, disconnected the small drive, made the big one master and started up.

Got as far as the bootup screen and the kernel panicked.
Errors as follows:

hda: status timeout: status = 0x0 {Busy}
hda: SMA disabled
hda: drive not ready for command
...
EXT3-fs: unable to read superblock
...
kernel panic: no init found. Try passing init=option to kernel.


So I tried to boot to a floppy and got another kernel panic, again telling me to try passing int =option to kernel.

I then booted with a Knoppix CD. The hard drive is unavailable.
As root, I tried mount -t exts /dev/hda1 /mnt/hd
I tried with /dev/hda, /dev/hdba, /dev/hdb, /dev/hdb1, /dev/hdb6 but each time I get the message
"/dev/hda1 is not a valid block device"

So I can't boot from the big drive, can't access it to change lilo.conf and fstab back... screwed basically. Thank heavens for Knoppix though, at least I can use internet.

[retsaw]

Are you sure you set the big drive to master, I've had the jumper setting printed upside down on one of my drives.

Have you tried fisk -l to see what that shows you?

[pickarooney]

Yeah, the master setting is with no jumper, so there's no way to read it upside-down. BIOS recognises the HD as primary master on bootup.

Did you mean fdisk -l? That returns nothing (fisk -l is not recognised).

[retsaw]

Yes, I did mean fdisk -l.

It is strange that linux can't access it at all. I can't really think what would cause this unless it is a hardware problem. You could try a different cable in case it is that, but since the hard drives were working before on the same cable I doubt it will be. The only other thing I can think of is changing it back the way it was and hope you can get it working.

[pickarooney]

I've nearly fixed it now, and it looks to be a cable problem. I rebooted with the Knoppix CD, still with just the 80GB connected, as master, and this time, although the BIOS screen displayed the hard-drive as primary master, the Knoppix boot screen repeated the message:
hda: lost interrupt
Powered down, then removed the IDE cable from the back of the (still unplugged) smaller HD and plugged it into the bigger HD. Rebooted to Knoppix again and this time, despite the message

suprious 8259A interrupt
it booted and recognised the hard drive. I could read from it and write to it. I rebooted without Knoppix and all was well, back to my old setup.
A message flashed up underneath the list of IDE devices on the BIOS screen, something to do with 80 and cable, but I didn't have time to read it. It may have been advice to use a 80-IDE cable or indicating the absence of one. I think it might be worth my while changing my 40s for 80s.

Still, hdparm results are the same as before.

[cybertron]

At last, something I recognize. Unless I'm mistaken, that hda: lost interrupt message is something you can Google and find some potential solutions as well. I've definitely heard of it before.

[pickarooney]

There's certainly a lot of varied responses to hda:lost interrupt questions.
This one sounds interesting:
I was running a 2.4 series kernel, but a "dmesg | grep hda" showed I was running a Seagate drive. Another posting also hinted at DMA problems, and I was getting a DMA timeout error message before the lost interrupts. The poster of that message suggested "hdparm -d 0 /dev/hda; while : ; do hdparm -t /dev/hda ; done" which would first disable DMA, then continually exercise the drive. That seemed to do the trick, so I've now added "hdparm -d 0 /dev/hda" to /etc/rc.local so that its always run on startup.
from here (http://www.jimohalloran.com/archives/000407.html).

Exercising the drive? Make it a hard-jog? ;)

I bought a new 80 IDE cable at lunchtime, so I'll see does that make a difference tonight.

[retsaw]

That you still had your small drive connected when it was unplugged probably caused your problem, but your new cable may help performance. Glad you`ve got it working again though.

As to that spurious interrupt message, my seach indicated it may be related to the "apic" in the kernel, so you could try passing "noapic" as a kernel parameter to see if it helps.

I also find the scroll lock key can be useful when trying to read boot messages, though it may not work on the bios screen.

[pickarooney]

Originally posted by retsaw

As to that spurious interrupt message, my seach indicated it may be related to the "apic" in the kernel, so you could try passing "noapic" as a kernel parameter to see if it helps.


Cheers :) Would this parameter be passed via lilo.conf?

[cybertron]

Yep, it goes in the append= section.