Bug 55621 - Sony VAIO VPCZ23A4R: 3g modem not working until suspend/resume
Sony VAIO VPCZ23A4R: 3g modem not working until suspend/resume
Status: RESOLVED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: Platform_x86
All Linux
: P1 normal
Assigned To: drivers_platform_x86@kernel-bugs.osdl.org
:
Depends on:
Blocks: 56331
  Show dependency treegraph
 
Reported: 2013-03-22 17:01 UTC by Alexander E. Patrakov
Modified: 2013-04-09 06:23 UTC (History)
1 user (show)

See Also:
Kernel Version: 3.8.2
Tree: Mainline
Regression: No


Attachments
acpidump (from pmtools) output (231.95 KB, text/plain)
2013-03-22 17:01 UTC, Alexander E. Patrakov
Details

Description Alexander E. Patrakov 2013-03-22 17:01:34 UTC
Created attachment 96031 [details]
acpidump (from pmtools) output

# lsusb
Bus 003 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 004 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 003: ID 08ff:168f AuthenTec, Inc. AES1660 Fingerprint Sensor
Bus 003 Device 004: ID 8086:0189 Intel Corp. 
Bus 003 Device 005: ID 05c8:0318 Cheng Uei Precision Industry Co., Ltd (Foxlink) Webcam
Bus 003 Device 006: ID 1199:68a2 Sierra Wireless, Inc. 

The last line is a 3g modem, visible as /dev/ttyUSB{0,1,2} (handled by the qcserial driver). After boot, it always fails as follows:

# pppd call 3g debug nodetach
abort on (BUSY)
abort on (NO CARRIER)
abort on (VOICE)
abort on (NO DIALTONE)
abort on (NO DIAL TONE)
abort on (NO ANSWER)
abort on (DELAYED)
abort on (ERROR)
abort on (BLACKLISTED)
timeout set to 5 seconds
send (AT^M)
expect (OK)
AT^M^M
OK
 -- got it

send (ATZ^M)
expect (OK)
^M
ATZ^M^M
OK
 -- got it

send (AT+CGDCONT=1,"IP","internet.mts.ru"^M)
expect (OK)
^M
AT+CGDCONT=1,"IP","internet.mts.ru"^M^M
OK
 -- got it

send (ATD*99***1#^M)
expect (CONNECT)
^M
ATD*99***1#^M^M
NO CARRIER
 -- failed
Failed (NO CARRIER)
Script /usr/sbin/chat -sv -T internet.mts.ru -f /etc/ppp/gprs.chat finished (pid 24562), status = 0x5
Connect script failed

After a suspend-resume cycle, the modem works as it should.

Also it is interesting that, if I rfkill the modem and try to bring it back, it doesn't come back:

# rfkill list
0: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no
1: sony-wifi: Wireless LAN
	Soft blocked: no
	Hard blocked: no
2: sony-bluetooth: Bluetooth
	Soft blocked: no
	Hard blocked: no
3: sony-wwan: Wireless WAN
	Soft blocked: no
	Hard blocked: no
4: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no
# rfkill block 3
# rfkill unblock 3
# rfkill list
0: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no
1: sony-wifi: Wireless LAN
	Soft blocked: no
	Hard blocked: no
2: sony-bluetooth: Bluetooth
	Soft blocked: no
	Hard blocked: no
3: sony-wwan: Wireless WAN
	Soft blocked: no
	Hard blocked: no
4: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no
# lsusb
Bus 003 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 004 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 003: ID 08ff:168f AuthenTec, Inc. AES1660 Fingerprint Sensor
Bus 003 Device 004: ID 8086:0189 Intel Corp. 
Bus 003 Device 005: ID 05c8:0318 Cheng Uei Precision Industry Co., Ltd (Foxlink) Webcam

Suspend & resume brings the modem back.
Comment 1 Aaron Lu 2013-03-26 07:32:07 UTC
Hi Alexander,

Thanks for the report, but it feels more like a driver bug. I'll re-assign this to the driver category and see if they know what happened.
Comment 2 Alexander E. Patrakov 2013-03-26 08:45:16 UTC
Hello Aaron,

part of this can indeed be a qcserial driver bug, however the "device doesn't reattach after unrfkilling" part looks more like a sony-laptop ACPI-related bug. So at least partially this is not Greg's territory.
Comment 3 Aaron Lu 2013-03-26 09:07:14 UTC
(In reply to comment #2)
> Hello Aaron,
> 
> part of this can indeed be a qcserial driver bug, however the "device doesn't
> reattach after unrfkilling" part looks more like a sony-laptop ACPI-related
> bug. So at least partially this is not Greg's territory.

Thanks for the clarification. Do you mean the acpi driver located here: drivers/platform/x86/sony-laptop.c?
Comment 4 Alexander E. Patrakov 2013-03-26 09:08:36 UTC
Yes, I mean the driver compiled from drivers/platform/x86/sony-laptop.c into sony-laptop.ko.
Comment 5 Aaron Lu 2013-03-26 09:11:52 UTC
(In reply to comment #4)
> Yes, I mean the driver compiled from drivers/platform/x86/sony-laptop.c into
> sony-laptop.ko.

OK, thanks, that one belongs to platform/x86 driver.
Which do you think is the fundamental problem here? the rfkill part or usb part? If you want to solve the rfkill problem, I can help to re-assign to drivers/platform-x86 category, thanks.
Comment 6 Alexander E. Patrakov 2013-03-26 09:18:34 UTC
I am not convinced that a USB-related bug exists at all (but I can be wrong). Look - the modem responds to the AT commands as it should, it just looks like some evil guy has cut off the antenna. So, if this looks sensible to you, please reassign to drivers/platform-x86. We can always reassign back to USB later if platform guys say so.
Comment 7 Aaron Lu 2013-03-26 09:22:27 UTC
(In reply to comment #6)
> I am not convinced that a USB-related bug exists at all (but I can be wrong).
> Look - the modem responds to the AT commands as it should, it just looks like
> some evil guy has cut off the antenna. So, if this looks sensible to you,
> please reassign to drivers/platform-x86. We can always reassign back to USB
> later if platform guys say so.

OK, I'll re-assign to platform driver, sorry for the noise.
Comment 8 Alexander E. Patrakov 2013-03-26 09:26:49 UTC
Clarification of the report, just in case:

1. After booting with RF not killed, the modem is on the USB bus, responds to AT commands, but does not detect cellular network ("NO CARRIER") => may be USB or sony-laptop bug, my completely-unfounded gut feeling says sony-laptop.

2. After rfkilling the modem, it disappears from the USB bus => correct, same as bluetooth.

3. After unrfkilling the modem, it doesn't reappear on the USB bus => definitely sony-laptop bug.

4. After suspending and resuming the laptop, the modem appears on the bus and sees the cellular network => may be useful information, that's also why acpidump output is attached.
Comment 9 Alexander E. Patrakov 2013-04-06 13:24:14 UTC
With linux-3.9-rc5 the bug is no longer reproducible. The modem works correctly after powering the laptop off and then on, after suspending/resuming, and after rfkilling/unrfkilling.
Comment 10 Alexander E. Patrakov 2013-04-06 13:32:05 UTC
Actually this is an exact duplicate of bug #47751. Sorry!

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