Bug 6293 - wireless printing produces multiple beeps and display flickers
Summary: wireless printing produces multiple beeps and display flickers
Status: CLOSED CODE_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Battery (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Vladimir Lebedev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-27 13:18 UTC by Sanjoy Mahajan
Modified: 2006-07-07 07:12 UTC (History)
0 users

See Also:
Kernel Version: 2.6.16-rc5
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
dmesgs during printing beeps and display changes (34.41 KB, application/octet-stream)
2006-03-27 13:25 UTC, Sanjoy Mahajan
Details
dmesgs w/ ACPI debugging while beeping (24.31 KB, application/octet-stream)
2006-05-17 20:24 UTC, Sanjoy Mahajan
Details

Description Sanjoy Mahajan 2006-03-27 13:18:47 UTC
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.
Comment 1 Sanjoy Mahajan 2006-03-27 13:25:41 UTC
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
Comment 2 Konstantin Karasyov 2006-05-17 09:08:28 UTC
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?
Comment 3 Sanjoy Mahajan 2006-05-17 10:33:02 UTC
> 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?

Comment 4 Sanjoy Mahajan 2006-05-17 20:24:01 UTC
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.
Comment 5 Konstantin Karasyov 2006-05-19 07:07:06 UTC
>> 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.  
 
Comment 6 Konstantin Karasyov 2006-05-22 08:25:17 UTC
> 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?

Comment 7 Vladimir Lebedev 2006-07-07 07:06:38 UTC
No response from bug submitter, please reopen if problem persists. 

Note You need to log in before you can comment on or make changes to this bug.