public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Jonas Petersson <zap-7RBX4Gk6oWI@public.gmane.org>
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: ASUS L5x: ACPI fan dies when PCMCIA GSM card used
Date: Tue, 13 Jan 2004 11:33:59 +0100	[thread overview]
Message-ID: <4003C997.3010400@xms.se> (raw)

[ I tried this on the acpi-support list earlier, but got no response, so
here's another try... ]

Hi list,

I've encountered a problem which I *THINK* i ACPI related, but I've not
enough ACPI experience to understand how to get around it. Any hint
appreciated.

I'll file it as a proper kernel bug if you think it more appropriate.
Here is a quick rundown of what I've found out:

* My base installation is described pretty defailed here:
http://www.xms.se/~zap/linux/asusl5800c.html
As you can see it has worked pretty well for quite some time and hence
my kernel etc is not quite bleading edge anymore (though I follow Debian
testing for everyting else).

* $ cat /proc/acpi/info
version:                 20030813
states:                  S0 S1 S3 S4 (swsusp) S5

The problem I've encountered lately is related to using a Nokia
CardPhone in my PCMCIA slot. Several other cards have work OKish - at
worst, an ethernet card wouldn't work at all (forgot the name, but it
was multifunction and was iffy anyway) and in one case a wavelan card
(orinoco) would only work in the upper slot. This is significantly worse:

Initially I just plugged it in without a SIM card and got some "Resource
unavailable" problems - fiddling with the /etc/pcmcia/config-2.4 file
appeared to help, though it was somewhat odd that specifying low IRQs
(say 4,5,6) still reported 10 or 11 in dmesg, but at least it appeared
to work.

I now also tried with a SIM card in place and noticed that the FAN would
stop a short while after inserting the card (I can hear the GSM
negotiations as noises in the speakers) when some IRQs where used
and then I had messages such as these in dmesg:


ttyS17 at port 0x0100 (irq = 11) is a 16550A
Trying to free nonexistent resource <00000100-00000107>
Trying to free nonexistent resource <00000100-00000107>
   ACPI-1121: *** Error: Method execution failed [\_TZ_.FAN0._INI]
(Node dffe9520), AE_AML_PACKAGE_LIMIT
   ACPI-1121: *** Error: Method execution failed [\_GPE._L16] (Node
dffe28a0),
AE_AML_PACKAGE_LIMIT
   ACPI-0297: *** Error: AE_AML_PACKAGE_LIMIT while evaluating method
[_L16] for GPE[ 0]
   ACPI-1121: *** Error: Method execution failed [\_TZ_.FAN0._INI]
(Node dffe9520), AE_AML_PACKAGE_LIMIT
   ACPI-1121: *** Error: Method execution failed [\_GPE._L16] (Node
dffe28a0),
AE_AML_PACKAGE_LIMIT
   ACPI-0297: *** Error: AE_AML_PACKAGE_LIMIT while evaluating method
[_L16] for GPE[ 0]
ttyS17 unloaded

Unplugging the card before the temperature gets too high seems to help
as the fan restarts typically after less than a minute.

I then tried acpidump and although I don't really understand all of it,
it sure hinted that an _INI method for FAN0 which may be called from
_L16 within the _GPE scope, but I can't really see how this should
suddenly stop working when I plug that particular card in.

Still, some combos of IRQs and port selections appeared to work at the
time and I would be able dial up using minicom and/or kppp.

At this stage I realized that debian demands that I'm part of the dip
group and for sanity reasons I decided to logout and reboot to make
sure everything was in a sane state - apparently it wasn't:

kppp will now sort of seem to work and the fan will run OK, but after a
minute or so the system will suddenly go wild:

- In one case, X died and I could only type (but got no response) in the
old X vt.
- In another case, X again died and a few messages flashed past too
quickly to read and then it was powered off.
- In a third case, a lot of info flashed past in an Oops dump (sorry,
wan't able to catch it).

To me it seems to be some kind of ACPI/PCMICA clash, but I have no clue
how to solve it. I had intended to wait for a couple of more weeks
before going 2.6.x as swsusp is somewhat critical to my daily work and
it seems not quite stable for 2.6 yet (considering even Nigel himself
runs 2.4 for development...)

Here's a bit more info:

$ cat /proc/interrupts
           CPU0
  0:     146428          XT-PIC  timer
  1:       3762          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  8:          4          XT-PIC  rtc
  9:         76          XT-PIC  acpi
 10:      42212          XT-PIC  SiS 7012, ehci_hcd, usb-ohci, usb-ohci,
PCI device 1524:1421 (ENE Technology Inc), bcmwl5driverloader
 11:      85553          XT-PIC  usb-ohci, PCI device 1524:1421 (ENE
Technology Inc), radeon-D5X1nVylZaA@public.gmane.org:1:0:0
 12:     129940          XT-PIC  PS/2 Mouse
 14:          0          XT-PIC  ide0
 15:      17397          XT-PIC  ide1
NMI:          0
LOC:     146116
ERR:          1
MIS:          0

I've not attached the dmi and acpi dumps as I suspect there is a size
limit to this list, but I'll gladly mail that (and any other
information) to anyone who is interested.

		Any hint appreciated / Jonas

-- 
Jonas Petersson  |  XMS Penvision  |  mailto:Jonas.Petersson-7RBX4Gk6oWI@public.gmane.org
Box 3294, Västgötegatan 13, S-600 03 Norrköping | http://www.xms.se/
Tel: +46 11 400 13 00 | Dir: +46 11 400 13 05 | Fax: +46 11 10 30 50



-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

             reply	other threads:[~2004-01-13 10:33 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-13 10:33 Jonas Petersson [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-01-14  1:10 ASUS L5x: ACPI fan dies when PCMCIA GSM card used Yu, Luming

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4003C997.3010400@xms.se \
    --to=zap-7rbx4gk6owi@public.gmane.org \
    --cc=acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox