[Orinoco-users] acpi problems

[Thorsten Hirsch]

Hi,

my orinoco gold card has problems connecting to my ap when acpi is
turned on. In fact, it connects in about 10% directly at boot time. The
link quality is between 25 and 30 (of 92) here. After boot time I've got
no chance at all to get the link up. The percentage is much higher when
the link signal is better, but even when my laptop is placed directly
next to the ap, the link gets up in not more than 50% of my reboots and
still at 0% after boot time. With "after boot time" I mean to exec
'/etc/rc.d/network restart'.

I also tried "acpi=noirq" and "acpi=s3_bios", but the result is the same
as if acpi is turned on. The situation changes completely when
"acpi=off": everything works fine here, the link gets always up, 100%
boot time, 100% after boot time.

My distribution is archlinux with the latest stable kernel package
(2.6.19.2). Here's the output of dmesg when acpi is turned off:

====================
pccard: PCMCIA card inserted into slot 0
pccard: PCMCIA card inserted into slot 1
cs: IO port probe 0x100-0x3af: clean.
cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7
cs: IO port probe 0x820-0x8ff: clean.
cs: IO port probe 0xc00-0xcf7: clean.
cs: IO port probe 0xa00-0xaff: clean.
cs: memory probe 0xa0000000-0xa0ffffff: clean.
pcmcia: registering new device pcmcia1.0
cs: IO port probe 0x100-0x3af: clean.
cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7
cs: IO port probe 0x820-0x8ff: clean.
cs: IO port probe 0xc00-0xcf7: clean.
cs: IO port probe 0xa00-0xaff: clean.
cs: memory probe 0xa0000000-0xa0ffffff: excluding 0xa0000000-0xa00fffff
pcmcia: registering new device pcmcia0.0
IBM TrackPoint firmware: 0x0e, buttons: 3/3
input: TPPS/2 IBM TrackPoint as /class/input/input2
orinoco 0.15 (David Gibson <***@gibson.dropbear.id.au>, Pavel Roskin
<***@gnu.org>, et al)
orinoco_cs 0.15 (David Gibson <***@gibson.dropbear.id.au>, Pavel
Roskin <***@gnu.org>, et al)
eth1: Hardware identity 0001:0001:0004:0000
eth1: Station identity 001f:0001:0008:0048
eth1: Firmware determined as Lucent/Agere 8.72
eth1: Ad-hoc demo mode supported
eth1: IEEE standard IBSS ad-hoc mode supported
eth1: WEP supported, 104-bit key
eth1: MAC address 00:02:2D:1E:2E:38
eth1: Station name "HERMES I"
eth1: ready
eth1: orinoco_cs at 0.0, irq 3, io 0x0100-0x013f
Adding 544312k swap on /dev/hda3. Priority:-1 extents:1 across:544312k
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
ADDRCONF(NETDEV_UP): eth0: link is not ready
Mobile IPv6
[drm] Initialized drm 1.0.1 20051102
PCI: Found IRQ 11 for device 0000:01:00.0
PCI: Sharing IRQ 11 with 0000:00:02.0
PCI: Sharing IRQ 11 with 0000:00:05.0
[drm] Initialized savage 2.4.1 20050313 on minor 0
mtrr: base(0xf2000000) is not aligned on a size(0x5000000) boundary
agpgart: Found an AGP 1.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V2 device at 0000:00:00.0 into 1x mode
agpgart: Putting AGP V2 device at 0000:01:00.0 into 1x mode
Real Time Clock Driver v1.12ac
ADDRCONF(NETDEV_UP): eth1: link is not ready
eth1: New link status: Connected (0001)
ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
eth1: no IPv6 routers present
====================

And this is a "good" iwconfig output:
====================
$ iwconfig eth1
eth1 IEEE 802.11b ESSID:"FOO" Nickname:"JOHNDOE"
Mode:Managed Frequency:2.437 GHz Access Point: 00:12:34:56:78:90
Bit Rate:11 Mb/s Sensitivity:1/3
Retry limit:4 RTS thr:off Fragment thr:off
Power Management:off
Link Quality=24/92 Signal level=-70 dBm Noise level=-94 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:4832
Tx excessive retries:422 Invalid misc:0 Missed beacon:0
====================

The laptop is a thinkpad t21. I also played with the apic settings (the
kernel has been compiled with enabled apic settings), but they seem to
have no influence on the problem.
A few more words to acpi=on: it doesn't make a difference whether I load
the ibm_acpi module or not. When the link fails, the orinoco's leds are
always like this: the lower one turns on, the upper one is blinking 2
times, then a few seconds nothing happens and in the end the upper one
is flashing 1 time, then the lower one turns off and that's it. I get
the same led behaviour when I run "dhcpcd -t 10 eth1" - a higher timeout
doesn't solve the problem.

Any ideas?

Thorsten

[Pavel Roskin]

Post by Thorsten Hirsch
My distribution is archlinux with the latest stable kernel package

[skip]

Post by Thorsten Hirsch
Any ideas?

Maybe you could also see the dmesg output when you can reproduce the
problem? Also, it would make sense to see the iwconfig output when the
problem exists.

It would be great if you can sport some difference.

And since ACPI is involved, please check /proc/interrupts with and
without ACPI. I guess the driver is forced to share the interrupt with
some other driver that is not quite good at sharing.

[Thorsten Hirsch]

Hi Pavel,

thank you for your reply. However, I could not find much difference
concerning the interrupts:

$ cat int.without_acpi.txt
CPU0
0: 66263 XT-PIC-XT timer
1: 178 XT-PIC-XT i8042
2: 0 XT-PIC-XT cascade
3: 12352 XT-PIC-XT pcmcia0.0
8: 0 XT-PIC-XT rtc
11: 12 XT-PIC-XT CS46XX, yenta, yenta, uhci_hcd:usb1
12: 8502 XT-PIC-XT i8042
14: 11152 XT-PIC-XT ide0
15: 2126 XT-PIC-XT ide1
NMI: 0
LOC: 0
ERR: 2
MIS: 0

$ cat int.with_acpi.txt
CPU0
0: 23093 XT-PIC-XT timer
1: 159 XT-PIC-XT i8042
2: 0 XT-PIC-XT cascade
3: 4 XT-PIC-XT pcmcia0.0
7: 1 XT-PIC-XT parport0
8: 0 XT-PIC-XT rtc
9: 543 XT-PIC-XT acpi
11: 12 XT-PIC-XT CS46XX, yenta, yenta, uhci_hcd:usb1
12: 177 XT-PIC-XT i8042
14: 3185 XT-PIC-XT ide0
15: 632 XT-PIC-XT ide1
NMI: 0
LOC: 0
ERR: 1
MIS: 0

And the dmesg output is exactly the same in both cases (grepped for
orinoco):

orinoco 0.15 (David Gibson <***@gibson.dropbear.id.au>, Pavel Roskin
<***@gnu.org>, et al)
orinoco_cs 0.15 (David Gibson <***@gibson.dropbear.id.au>, Pavel
Roskin <***@gnu.org>, et al)
eth1: orinoco_cs at 0.0, irq 3, io 0x0100-0x013f

This is the iwconfig output without acpi, but iirc the output with acpi
is the same, including the link quality:

eth1 IEEE 802.11b ESSID:"FOO" Nickname:"BAR"
Mode:Managed Frequency:2.437 GHz Access Point: 00:15:0C:C4:F5:61
Bit Rate:11 Mb/s Sensitivity:1/3
Retry limit:4 RTS thr:off Fragment thr:off
Power Management:off
Link Quality=21/92 Signal level=-66 dBm Noise level=-87 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:112
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

Well, I'm going to check the iwconfig output with acpi again. If I don't
write another mail today, the output is the same.

Thorsten

[Pavel Roskin]

Post by Thorsten Hirsch
Hi Pavel,
thank you for your reply. However, I could not find much difference
$ cat int.without_acpi.txt
CPU0
0: 66263 XT-PIC-XT timer
1: 178 XT-PIC-XT i8042
2: 0 XT-PIC-XT cascade
3: 12352 XT-PIC-XT pcmcia0.0
8: 0 XT-PIC-XT rtc
11: 12 XT-PIC-XT CS46XX, yenta, yenta, uhci_hcd:usb1
12: 8502 XT-PIC-XT i8042
14: 11152 XT-PIC-XT ide0
15: 2126 XT-PIC-XT ide1
NMI: 0
LOC: 0
ERR: 2
MIS: 0
$ cat int.with_acpi.txt
CPU0
0: 23093 XT-PIC-XT timer
1: 159 XT-PIC-XT i8042
2: 0 XT-PIC-XT cascade
3: 4 XT-PIC-XT pcmcia0.0
7: 1 XT-PIC-XT parport0
8: 0 XT-PIC-XT rtc
9: 543 XT-PIC-XT acpi
11: 12 XT-PIC-XT CS46XX, yenta, yenta, uhci_hcd:usb1
12: 177 XT-PIC-XT i8042
14: 3185 XT-PIC-XT ide0
15: 632 XT-PIC-XT ide1
NMI: 0
LOC: 0
ERR: 1
MIS: 0

I see a great difference in the number of IRQ 3 hits.

Post by Thorsten Hirsch
And the dmesg output is exactly the same in both cases (grepped for
eth1: orinoco_cs at 0.0, irq 3, io 0x0100-0x013f

And that's the IRQ that is being used. Of course, it's possible that
you transferred some data over the wireless link and failed to do so
when ACPI was enabled.

Unfortunately, the card firmware decides when to associate, and the CPU
has no control over it.

You could use scanning (iwlist eth1 scan) to see the signal quality of
the AP whether the card is associated or not. This would give you an
idea whether the card sees the signal quality differently or it acts
differently for some other reason.