Most recent kernel where this bug did not occur: Was running a modified DSDT for a long time, and I regularly noticed it there (at least since 2.6.14 but I don't remember if before that). But I recently noticed it with a vanilla DSDT. Distribution: Debian testing/unstable Hardware Environment: TP 600X, prism54 wireless PCMCIA card (Intersil2), printer is an HP PSC 2710 inkjet printer/fax/scanner. Software Environment: vanilla DSDT (BIOS 1.11), lprng 3.8.24-4, hpijs 2.1.7, gs 8.53 Problem Description: If I print (using gs+hpijs+lpr) over the wireless network when on battery power, sometimes the system beeps repeatedly while the data is being transferred (and maybe a bit longer) as if the AC power was being plugged and unplugged repeatedly. The display also dims and brightens, also as if AC power was being plugged and unplugged. It never affects the printing (i.e. the files transfer and print fine). Here is the wireless card info (prism54 module), from lspci: 0000:06:00.0 Network controller: Intersil Corporation Intersil ISL3890 [Prism GT/Prism Duette] (rev 01) I noticed the same problem a few times with USB printing, but never when printing via the parallel port. Steps to reproduce: With the vanilla DSDT I can't reliably reproduce it, but it's happened twice now, and one time I had lots of ACPI debugging turned on. I will attach those dmesgs.
Created attachment 7690 [details] dmesgs during printing beeps and display changes I've added a few comments throughout the dmesgs (marked with # at the beginning of the line). They aren't the ideal dmesgs since thermal polling is going on too, and I did a sleep-wake cycle in between. However, I haven't been able to reproduce it since, so they are all I have. Kernel command line: BOOT_IMAGE=16-rc5 ro root=305 idebus=66 apm=off acpi=force pci=noacpi console=ttyS0,115200 console=tty0 acpi_sleep=s3_bios cpufreq.debug=7 acpi_dbg_level=0x10 acpi_dbg_layer=0x10
What are the DSDT modifications exactly? Could you try to reproduce the issue by applying modified DSDT, but on the latest kernel? Also, could you send 'cat /proc/interrupts' output?
> What are the DSDT modifications exactly? It has happened also with a vanilla DSDT, using 2.6.16-rc5 but with thermal-run patches that Luming Yu and I worked out for Bug #5989 (S3 sleep hangs on 2nd attempt). Even more strange, I got it to happen with the same kernel without even printing. Just doing convert -resize 6 -rotate 180 out.pnm /tmp/scan2.pdf on battery power usually produced beeps. (I've saved out.pnm in my debug directory). I was able to reproduce that for a few weeks, but not now for some reason even though I'm back to the same kernel. Maybe an intervening reboot to a fan suspend/resume patch got rid of whatever incorrect state had accumulated. > Also, could you send 'cat /proc/interrupts' output? Do you mean now or while the beeps happen?
Created attachment 8132 [details] dmesgs w/ ACPI debugging while beeping This time it beeped and I wasn't even printing. I ran a user-level program, while a gian 'apt-get upgrade' was downloading via the wireless card, and the beeps happened. I ran: "convert -resize 6 -rotate 180 out.pnm /tmp/scan2.pdf" where I have saved the out.pnm image file (and can attach if needed). But if I switched off the networking ('ifdown eth0 ; cardctl eject') then I couldn't get the 'convert' runs to produce beeps. These dmesgs are with debug_level = 0x0000001F and debug_layer = 0xFFFF3FFF so it shows function calls as AML methods. The kernel is 2.6.16-rc5, vanilla DSDT, but with patches (see Bug #5989) to make S3 sleep/wake work. They prevent thermal methods from running while it is going to sleep, which (probalby) avoids triggering some problem with the EC global locking. I've also seen the printing beeps with generic kernels but with a hacked DSDT. So I don't think it's caused by the kernel patch or the DSDT changes (in the other tests). It's just that various modifications trigger it in different circumstances.
>> Also, could you send 'cat /proc/interrupts' output? > Do you mean now or while the beeps happen? Yes. There could be interference from another process which shares the IRQ with ACPI. In your case it should be wireless. If this is true, then the problem is not with AC or battery subsystem, and we'll need find where it is.
> dmesgs w/ ACPI debugging while beeping Could you also perform AC plugging/unplugging, battery insertion/removal with the same debug prints to see the normal behavior?
No response from bug submitter, please reopen if problem persists.