Distribution:Debian unstable Hardware Environment: Machine is a PIII Mobile at 1GHz with intel chipset (i82801+i830M) 256 Megs of RAM Software Environment: XFree86 version 4.3 started using XDM Problem Description: The mouse gets crazy (if using the normal mouse driver) or looses sync (if using the synaptics driver). I have looked at the interrupts happening when one moves the mouse and the number is much higher (from 3 to 10 times) in 2.6 compared with 2.4, also when one stops moving the mouse in 2.6 the interrupts keep on happening for half a second or so, while it stops inmediately in 2.4. Steps to reproduce: In this laptop you can reproduce it just by compiling the mouse support and acpi all together and moving the mouse a while. I have tested this in 2.6.0test3 and test2 with and without the latest patch available on the acpi.sf.net site, the acpi-20030730-2.6.0-test2.diff.gz patch, I have also tested with and without APIC, having always the same result. The only way I found to get the mouse working ok was to fully remove ACPI, removing only some parts of it was of no use. If you need more info or want me to test some kind of workaround or patch just tell me.
I have tested right now 2.4.22-rc2 and as I saw ACPI changes (it has ACPI: Subsystem revision 20030619) I was fearing it would also suffer from the same problems of 2.6, but it doesn't seem to suffer that, so far the mouse is behaving ok. Hope that helps a bit.
I am having a problem much like this except that my laptop just locks up after a while in X. It only happens when I am using the mouse. I have used XFree 4.2.1 and 4.3 with the synaptics XFree86 event driver. There are some patches in the latest mm kernel that I have not tried. Maybe they would help.
I saw on acpi-devel that the 1-second of interrupts for this device is normal, so we'll ignore that part. Can you confirm that 2.4.22 is working normally, and that just 2.6.0-* is broken? Santiago, I assume that when you boot with acpi=off that it works normally? how about with pci=noacpi -- does that have an effect? I saw this in one of your notes on acpi-devel: > ACPI: No IRQ known for interrupt pin A of device 0000:00:1f.1 > - using IRQ 255 Can you append the full dmesg which shows this message and describe how the systems behaves after that boot? Also, please attach the /proc/interrupts for the failing case.
still a problem, or no? thanks, -Len
I'm sorry but I cannot test it and I don't know when I'm going to be able to test it, the computer is at AcerCare because of power problems, and they are really slow in fixing things there, I've been without it for almost two months last time I sent it. What I can tell you is that last time I tested it, it was on test5 or test6, the problem persisted. I'll try it as soon as I get my machine back and report.
Hi! I've got my Laptop back and reinstalled, I have tested now with 2.4.23rc3 and works ok, however 2.6 still has the problem, I have tested 2.6.0test9. I had missed your comment #3, sorry about that. I'll reply to that comment now. > Can you confirm that 2.4.22 is working normally, and that just 2.6.0-* is > broken? Yes, that is true, even 2.4.23-rc3 continues to work ok, and 2.6.0-test9 still doesn't work. > I assume that when you boot with acpi=off that it works normally? > how about with pci=noacpi -- does that have an effect? Yes, 2.6 with acpi=off works ok and pci=noacpi doesn't make any difference. > Can you append the full dmesg which shows this message and describe how > the systems behaves after that boot? > Also, please attach the /proc/interrupts for the failing case. Here is thee dmesg, the machine behaves well, the only problem I find is the synaptics pad one. Linux version 2.6.0-test9 (root@ace) (gcc version 3.3.2 (Debian)) #1 Sat Nov 22 18:57:32 CET 2003 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000000f7e0000 (usable) BIOS-e820: 000000000f7e0000 - 000000000f7e8000 (ACPI data) BIOS-e820: 000000000f7e8000 - 000000000f800000 (ACPI NVS) BIOS-e820: 000000000f800000 - 0000000010000000 (reserved) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) 247MB LOWMEM available. On node 0 totalpages: 63456 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 59360 pages, LIFO batch:14 HighMem zone: 0 pages, LIFO batch:1 DMI 2.3 present. ACPI: RSDP (v000 Acer ) @ 0x000fe030 ACPI: RSDT (v001 Acer FALCON3M 0x00000001 Acer 0x00000000) @ 0x0f7e0000 ACPI: FADT (v001 Acer FALCON3M 0x00000001 Acer 0x00000000) @ 0x0f7e0054 ACPI: BOOT (v001 Acer FALCON3M 0x00000001 Acer 0x00000000) @ 0x0f7e002c ACPI: DSDT (v001 Acer FALCON3M 0x00001000 MSFT 0x0100000d) @ 0x00000000 Building zonelist for node : 0 Kernel command line: BOOT_IMAGE=OLD ro root=301 Initializing CPU#0 PID hash table entries: 1024 (order 10: 8192 bytes) Detected 999.945 MHz processor. Console: colour VGA+ 80x25 Memory: 248000k/253824k available (1653k kernel code, 5096k reserved, 646k data, 112k init, 0k highmem) Calibrating delay loop... 1978.36 BogoMIPS Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: After generic identify, caps: 0383f9ff 00000000 00000000 00000000 CPU: After vendor identify, caps: 0383f9ff 00000000 00000000 00000000 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K CPU: After all inits, caps: 0383f9ff 00000000 00000000 00000040 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: Intel(R) Pentium(R) III Mobile CPU 1000MHz stepping 01 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xf0200, last bus=1 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20031002 ACPI: IRQ 9 was Edge Triggered, setting to Level Triggerd ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) Transparent bridge - 0000:00:1e.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT] ACPI: PCI Interrupt Link [PILA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [PILB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [PILC] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [PILD] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [PILE] (IRQs 3 4 5 6 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [PILF] (IRQs 3 4 5 6 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [PILG] (IRQs 3 4 5 6 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [PILH] (IRQs 3 4 5 6 7 9 10 11 12 14 15) ACPI: Embedded Controller [EC0] (gpe 29) SCSI subsystem initialized ACPI: PCI Interrupt Link [PILA] enabled at IRQ 11 ACPI: PCI Interrupt Link [PILD] enabled at IRQ 11 ACPI: No IRQ known for interrupt pin A of device 0000:00:1f.1 - using IRQ 255 ACPI: PCI Interrupt Link [PILB] enabled at IRQ 10 ACPI: PCI Interrupt Link [PILC] enabled at IRQ 11 ACPI: PCI Interrupt Link [PILF] enabled at IRQ 10 PCI: Using ACPI for IRQ routing PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off' SBF: Simple Boot Flag extension found and enabled. SBF: Setting boot flags 0x80 Initializing Cryptographic API ACPI: AC Adapter [AC] (on-line) ACPI: Battery Slot [BAT0] (battery present) ACPI: Power Button (FF) [PWRF] ACPI: Sleep Button (CM) [SLPB] ACPI: Lid Switch [LID] ACPI: Processor [CPU0] (supports C1 C2 C3) ACPI: Thermal Zone [THR1] (61 C) ACPI: Thermal Zone [THR2] (48 C) pty: 256 Unix98 ptys configured Real Time Clock Driver v1.12 Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected an Intel 830M Chipset. agpgart: Maximum main memory to use for agp memory: 196M agpgart: Detected 8060K stolen memory. agpgart: AGP aperture is 128M @ 0x98000000 Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A Using anticipatory io scheduler Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ICH3M: IDE controller at PCI slot 0000:00:1f.1 ACPI: No IRQ known for interrupt pin A of device 0000:00:1f.1 - using IRQ 255 ICH3M: chipset revision 2 ICH3M: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xb060-0xb067, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xb068-0xb06f, BIOS settings: hdc:DMA, hdd:pio hda: IC25N020ATCS04-0, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hdc: DW-28E, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 hda: max request size: 128KiB hda: 39070080 sectors (20003 MB) w/1768KiB Cache, CHS=38760/16/63, UDMA(100) hda: hda1 hda2 scsi0 : SCSI host adapter emulation for IDE ATAPI devices Vendor: TEAC Model: DW-28E Rev: E.0A Type: CD-ROM ANSI SCSI revision: 02 sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.12 Attached scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0 Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 5 mice: PS/2 mouse device common for all mice input: PC Speaker i8042.c: Detected active multiplexing controller, rev 1.1. serio: i8042 AUX0 port at 0x60,0x64 irq 12 serio: i8042 AUX1 port at 0x60,0x64 irq 12 serio: i8042 AUX2 port at 0x60,0x64 irq 12 Synaptics Touchpad, model: 1 Firmware: 4.6 180 degree mounted touchpad Sensor: 18 new absolute packet format Touchpad has extended capability bits -> four buttons -> multifinger detection -> palm detection input: SynPS/2 Synaptics TouchPad on isa0060/serio4 serio: i8042 AUX3 port at 0x60,0x64 irq 12 atkbd.c: Unknown key pressed (translated set 2, code 0x71, data 0x53, on isa0060/serio0). atkbd.c: Unknown key released (translated set 2, code 0x165, data 0xfa, on isa0060/serio0). atkbd.c: Failed to enable keyboard on isa0060/serio0 input: AT Translated Set 2 keyboard on isa0060/serio0 serio: i8042 KBD port at 0x60,0x64 irq 1 NET: Registered protocol family 2 IP: routing cache hash table of 2048 buckets, 16Kbytes TCP: Hash tables configured (established 16384 bind 32768) NET: Registered protocol family 1 NET: Registered protocol family 17 kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 112k freed Adding 257032k swap on /dev/hda2. Priority:-1 extents:1 EXT3 FS on hda1, internal journal 8139too Fast Ethernet driver 0.9.26 eth0: RealTek RTL8139 at 0xd00c2000, 00:00:e2:6d:f0:22, IRQ 11 eth0: Identified 8139 chip type 'RTL-8100' NTFS driver 2.1.4 [Flags: R/W MODULE]. eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 PCI: Setting latency timer of device 0000:00:1f.5 to 64 intel8x0: clocking to 48000 Linux Kernel Card Services options: [pci] [cardbus] [pm] Yenta: CardBus bridge found at 0000:01:09.0 [1025:1024] Yenta: ISA IRQ list 00b8, PCI irq10 Socket status: 30000007 [drm] Initialized i830 1.3.2 20021108 on minor 0 mtrr: base(0x98000000) is not aligned on a size(0x300000) boundary Synaptics driver lost sync at 1st byte Synaptics driver resynced. Synaptics driver lost sync at 1st byte Synaptics driver resynced. Synaptics driver lost sync at 1st byte Synaptics driver resynced. Synaptics driver lost sync at 1st byte Synaptics driver lost sync at 1st byte Synaptics driver lost sync at 1st byte Synaptics driver lost sync at 4th byte Synaptics driver lost sync at 1st byte Synaptics driver lost sync at 1st byte Synaptics driver lost sync at 1st byte Synaptics driver lost sync at 4th byte Synaptics driver lost sync at 1st byte Synaptics driver lost sync at 1st byte Synaptics driver lost sync at 4th byte Synaptics driver lost sync at 1st byte Synaptics driver lost sync at 1st byte Synaptics driver lost sync at 4th byte Synaptics driver lost sync at 1st byte Synaptics driver lost sync at 1st byte Synaptics driver lost sync at 1st byte Synaptics driver resynced. Synaptics driver lost sync at 1st byte Synaptics driver resynced. This is /proc/interrupts CPU0 0: 529471 XT-PIC timer 1: 2430 XT-PIC i8042 2: 0 XT-PIC cascade 8: 4 XT-PIC rtc 9: 0 XT-PIC acpi 10: 5 XT-PIC Intel 82801CA-ICH3, yenta 11: 738 XT-PIC eth0 12: 74027 XT-PIC i8042 14: 4409 XT-PIC ide0 15: 21 XT-PIC ide1 NMI: 0 ERR: 0 The device of the unknown irq is the IDE controller, IDE drives are using DMA and working ok, so I don't really know what that message means. I think I can tell you what is making this happen, I have had some luck and have came to something that will help us track this down, let me explain all the process... One thing I have discovered these days, while reinstalling the system is that the problem happened a lot when I was in icewm while it didn't happen so much when I was at the wdm or login this looked quite weird, at least to me, so I investigated it througout the weekend, this is how it went: I was reinstalling and I was testing wdm as my display manager, and I saw that the mouse was going well with this display manager, then tested xdm (the one I used to have) and behaved the same, then I logged in and I my window manager was started (I use icewm) and the mouse started to fail. After this, I tested with ratpoison as window manager and also seemed not to fail. This puzzled me a lot, so I started to test wdm, xdm and ratpoison again, and saw that the problem was also happening there, but the ocasions on which it happened were a lot fewer than when using icewm. So, when I was writing this just to tell you that it was easier to trigger this using icewm I realised that the thing could be trigered by my icewm reading /proc/acpi stuff to show me the batery status, and the others (xdm, wdm, and ratpoison) not doing this, but then, why did it also happen on them sometimes... well, I was running an script in the background that looks into the status of the battery using the acpi command and logs it, it does this once per minute, that could explain it all, and in fact it does, I have now stopped the script and disabled the battery info in icewm and the mouse is completely smooth now. So, what happens seems to be that when you read the acpi info (icewm does it in /proc, don't know about the acpi program, I suppose it also uses /proc to get it) and at the same time you are moving the mouse, the mouse looses sync. Hope this helps and we can get this fixed at last. If you want me to test anything or need any more info don't hesitate to contact me. Regards!
I have tested 2.6.0 final and also patched it with your acpi-20031203-2.6.0.diff.gz patch from bitkeeper without any changes in the behaviour, still the same mouse problems caused by the acpi code. I'm looking forward for this to get solved, so if you want me to test any experimental code just tell me. Regards!
I have just tested 2.6.5 and found that one can now work with the mouse, even though the bug is still there and one can see messages like the ones I'm pasting below, I can now work with the mose, it seems quite responsive and only does a little "jumping" from time to time. Synaptics driver lost sync at byte 4 Synaptics driver lost sync at byte 1 Synaptics driver lost sync at byte 1 Synaptics driver lost sync at byte 1 Synaptics driver resynced. Synaptics driver lost sync at byte 1 Synaptics driver lost sync at byte 1 Synaptics driver resynced. Synaptics driver lost sync at byte 1 Synaptics driver resynced. If you want any other info, just ask. Regards!
Thanks for verifying that the mouse is working on 2.6.5. Is the battery polling application present when it works? If so, can we close this ACPI bug? thanks, -Len
Sorry, I hadn't seen your comment, I'm running 2.6.8 now with the same feeling as when I tested 2.6.5, I believe that the mouse is behaving better because of the changes the guys of the Synaptics driver have made, seems to behave better when loosing bytes. I really believe that the ACPI issue is still as it was before, I mean, in 2.4 the battery status pooling didn't affect the mouse, we didn't loose the bytes of the touchpad, or at least not like this, and in 2.6 up to now, acpi is blocking us from reading these bytes :-( Well, that is just what I see from an user point of view, looking at the kernel messages and all that, not that I know what is going on really in the inside. Hope this clarifies the status of the bug. I really wonder if there is any way to use the acpi of 2.4 in 2.6 to see if things are really like I think they are. If this kind of test is posible or any other you think would clarify this a bit, just tell me how to do it and I'll test it. Regards!
if the system works better with acpi=off than it does with acpi enabled, then it is an ACPI bug -- can you make this comparison?
I had already replied to the acpi=off thing in my comment #6, but I have tested again to see how it went right now, acpi=off makes the mouse work perfectly OK, same thing happens even if you have acpi on but you don't ever read the battery status. So, the problem is clearly when you read the battery (power) status through ACPI, things seem somewhat better since 2.6.9, seems like the update of ACPI that was done at that release helped a bit, maybe lowering the times ACPI was needing to get the power status.
Could you give latest patch set at bug 3851 a try?
I have tested it by applying patches 4246 and 4247 to kernel 2.4.10-rc3 (only got a little problem with a header inclusion, but they applied cleanly for the rest of them). The result is that the bug still exists. I can however subjectively say that the mouse seems now smoother and that the problem of the lost sync in the mouse seems to happen fewer times than it did before, however this is just my opinion, doing a "while true;do acpi -V;done" still causes the mouse to output the sync error messages all the time. BTW, I saw no power off problems or anything like that.
I have a similar problem, but with opposite results: :) If I use the touchpad (it's enough to simply touch it, you do not need X for it) then the kernel will say this if I want to read battery status (eg. with powersave -b): [ACPI Debug] String: [0x09] "BST Start" evregion-0405: *** Error: Handler for [EmbeddedControl] returned AE_TIME dswexec-0438 [473] ds_exec_end_op : [Store]: Could not resolve operands, AE_TIME psparse-1138: *** Error: Method execution failed [\_SB_.PCI0.BAT0._BST] (Node c1435668), AE_TIME acpi_battery-0208 [465] acpi_battery_get_statu: Error evaluating _BST [ACPI Debug] String: [0x03] "BIf" evregion-0405: *** Error: Handler for [EmbeddedControl] returned AE_TIME dswexec-0438 [474] ds_exec_end_op : [Store]: Could not resolve operands, AE_TIME psparse-1138: *** Error: Method execution failed [\_SB_.PCI0.BAT0._BIF] (Node c14356e8), AE_TIME acpi_battery-0147 [466] acpi_battery_get_info : Error evaluating _BIF If I use an external USB mouse, then everything is fine. Distrib: SuSE Prof. 9.2 Kernel: stock 2.6.10 (but same problem with the default kernel of SuSE) HW: Fujitsu Siemens Amilo A1640 (Mobile AMD Sempron 2800+), 512MB RAM Should I open a new bug for it, or is it OK here? Greets, Gabor
To comment 15, I'd like to see a new tracker. Did you apply patchs 4246 and 4247?
I've same problem ranging from 2.6.10(time when i've bought my notebook) to 2.6.13-rc5(tried yesterday). It's impossible to use any kind of battery status monitoring software. My notebook is Asus L4000. When I try to pool battery/ac_adapter status, the system isn't responsive for a while - mouse freeze, music stops playing etc. strace -p <gkrellm_pid> -tt: ---------------------------- 23:19:14.014904 open("/proc/acpi/ac_adapter/AC/state", O_RDONLY) = 12 23:19:14.014992 fstat64(12, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 23:19:14.015056 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6cb0000 23:19:14.015101 read(12, "state: on-line"..., 1024) = 33 * here is the whole system freeze 23:19:14.031006 read(12, "", 1024) = 0 23:19:14.031063 close(12) = 0 23:19:14.031122 munmap(0xb6cb0000, 4096) = 0 I've also tried to run something like this "for i in `seq 1 100`;do cat /proc/acpi/ac_adapter/AC/state;done" in console, if this batch run its ok, system is responsive, but when this batch finish, system is really laggy and I see, that kacpid cause about 20-60% CPU load. If you need more information, no problem. I'll do my best to help.
Please reopen the bug if you still have problem with solution like bug 4665 *** This bug has been marked as a duplicate of 4665 ***