Bug 134184

I have no idea, because hal do nothing with your mouse and I can't reproduce this here. What happens if you restart hal? Was this a update or a fresh installation? Can you reproduce this with a new clean installation (maybe a problem with update)

restarting hal makes the mousemovement jerky again.
It is not about the mouse. It is probably a global interrupt disable.

seife was here: straceed hald-add-storage, which has a 2 seconds poll-interval on /dev/hdc,
the mouse jerks are in sync with these polls. Perhaps a kernel bug?

Try to copy a big file from the cd drive. Does that cause the same issues?
Maybe it's the dma setting of the drive, you may use hdparm to look into this,
or enable dma, if it's not ...

cp /media/SUSE_LINUX_9_2_Live_Eval/cloop.img /dev/null &
does not make it any worse or better. 

hdparm /dev/hdc

/dev/hdc:
 IO_support   =  1 (32-bit)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    = 256 (on)
 HDIO_GETGEO failed: Invalid argument

@kay: I assign the bug to you, I have no ideas about the problem.

No idea, never heard of such a behavior. Is it possible for you, to exchange the drive in that box to narrow down the problem? 

I've done rmmod icd_cd, sr_mod, cdrom; no change.
So mentioning /dev/hdc was probably misleading. Sorry for that.

But there is something else, that hal does. I can reproduce the erratic mouse movements with

perl -e 'my $a; open IN, "<", "/proc/apm"; for (;;) { sysread IN, $a, 1024; printf "%d %s\n", length($a), $a; select(undef,undef,undef,0.1); }'

40 1.16ac 1.2 0x03 0x01 0xff 0x80 -1% -1 ?

0 
0 
0 
0 
....

every read (even read attempt) on /proc/apm blocks interrupts. 
hal should not to that so frequently ...

still present in 10.1 alpha3plus.
who can look into this?

Kay, can you reproduce this and look into it?

It's likely a kernel issue, but I have not such a box and worse absolutely no clue about APM.

still present in 10.0 alpha4.
Back to AJ, next try.

What machine is this? Why it uses APM at all? ACPI should be the first choice nowadays. APM calls into the BIOS and depending on the machine, it can spend a non-negligible amount of time there.

The APM driver disables interrupts on entry to the BIOS, the BIOS is responsible for re-enabling there if it intends to run for a long time or needs to receive interrupts while running. Some BIOSes don't do that (BIOS bugs, as always), and thus need

        CONFIG_APM_ALLOW_INTS

kernel option enabled. Please enable that kernel option on your machine and see if it helps. Namely IBM ThinkPads seem to need it if they are running with APM.
        

Created attachment 61439 [details]
hwinfo of the afected machine.

I have now have newly compiled kernel on that machine. oldconfig tells me, that with this kernel
I have APM_ALLOW_INTS set to 'y'. No change. The system regularly pauses.

Please try booting with "apm=off".
If this helps, we could
a) make apm=off a default commandline option in the bootloader
b) fix hal to not poll stupidly on the apm device if he detects that there is nothing to poll (e.g. no battery etc). Or at least make the polling an option.

acpi=force or apm=off helps. noapm does not help.

Secondary effect: The read on /proc/apm caused the machine to freeze, if a USB device is plugged in. So we fixed bug # 60411 by chance. Thanks!

The only options we have are described above by Stefan - either disable APM entirely, or prevent hal from polling APM when there is no info to be obtained from it (APM status isn't useful on a desktop machine, since it doesn't have a battery, and thus AC is always connected, too).

-> reassigning back to mobile.

There has been no activity for more than 3 month. I'm closing this bug as 
WONTFIX. If you feel this is inappropriate and the bug should remain open, 
or you have new information which may lead to an actual resolution, please 
reopen the bug and add the new status.