Bug 1093

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 ***