conexant accessrunner 'cxacru' USB ADSL module not unloaded on swusp

Bug #36353 reported by Vassilis Pandis
12
Affects Status Importance Assigned to Milestone
acpi-support (Ubuntu)
Invalid
Medium
Unassigned

Bug Description

This is not a real real bug, but a configuration problem. The module cxacru is not suitable for suspend-to-disk. When I suspend to disk with the module loaded, then the keyboard begins to misbehave (I try to tttttttttttttype and get this kkkkkkkkkkkkkkkkkkind of behaviour). Furthermore, since cxacru is a driver to USB adsl modem, it makes no sense not to unload it before suspending. It should be unloaded and reloaded on resume.

This is not a specific kernel issue problem. It also happened to me back when I was using Gentoo + Suspend2 with several different kernels.

Revision history for this message
Paul Sladen (sladen) wrote : Re: accessrunner 'cxacru' USB ADSL module not unloaded on swusp

Hi pandisv, thanks for your report,

Currently we try to unload network drivers before hibernate, using the code, but it may not work if the driver name does not match the filename.

Cat you post the output of:

  $ ls -ld /sys/class/net/*/device/driver

Changed in acpi-support:
assignee: nobody → sladen
status: Unconfirmed → Needs Info
Revision history for this message
Vassilis Pandis (pandisv) wrote :

I am on Dapper Drake FL5, fairly recently updated.

pandis@maxwell:~$ sudo ls -ld /sys/class/net/*/device/drive
Password:
ls: /sys/class/net/*/device/drive: No such file or directory

pandis@maxwell:~$ uname -a
Linux maxwell 2.6.15-19-386 #1 PREEMPT Mon Mar 20 16:46:02 UTC 2006 i686 GNU/Linux

pandis@maxwell:~$ ls /sys/class/net/lo
address addr_len broadcast carrier features flags ifindex iflink mtu statistics tx_queue_len type uevent weight

Revision history for this message
Vassilis Pandis (pandisv) wrote :

(Sorry, I may have not understood the driver name issue correctly)

The driver's filename in /lib/modules/2.6.15-19-386/drivers/usb/atm/ is cxacru.ko. A glance at the source tells me that the driver's name is also "cxacru"..

Revision history for this message
Paul Sladen (sladen) wrote :

How exactly does this show up, is it not a network device?

Ah, may it is an ATM device when in PPPoA mode. Can you try:

  $ ls -ld /sys/class/atm/*/device/driver

Revision history for this message
Vassilis Pandis (pandisv) wrote :

Um....:

pandis@maxwell:/$ ls -ld /sys/class/atm/*/device/driver
ls: /sys/class/atm/*/device/driver: No such file or directory

pandis@maxwell:/proc$ sudo find / -name *cxacru*

/lib/modules/2.6.15-18-386/kernel/drivers/usb/atm/cxacru.ko
/lib/modules/2.6.15-19-386/kernel/drivers/usb/atm/cxacru.ko
/lib/firmware/cxacru-fw.bin
/proc/net/atm/cxacru:0
/sys/module/cxacru
/sys/bus/usb/drivers/cxacru

I am using PPPoATM. What exactly are we looking for?

I don't know exactly what you mean as a "network" device, but yes, I use it to connect to the Internet.

Revision history for this message
Paul Sladen (sladen) wrote :

Okay, lets try and track that back and see where it pops up, can you try the following monstor:

  $ find -H /sys/ -lname '*cxacru' | tee /dev/fd/2 | grep 'driver$' | sed -e 'sx.*/\([^/][^/]*\)/[^/]*$x*\1*x' | xargs find -H /sys/ -lname | xargs ls -l | cut -d' ' -f8-10

A network device would be anything in:

  /sys/class/net/*

which it isn't showing up under... (which is the reason that it's not automatically being uploaded).

Revision history for this message
Vassilis Pandis (pandisv) wrote :

Output of that :

/sys/bus/usb/drivers/cxacru/module

/sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/driver

/sys/bus/usb/devices/1-1:1.0 -> ../../../devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0

/sys/bus/usb/drivers/cxacru/1-1:1.0 -> ../../../../devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0

pandis@maxwell:/sys/class/net$ ls
lo ppp1 sit0

My current connection is /sys/class/net/ppp1. To be frank, I have no idea what that "sit0" thing is.

Revision history for this message
Vassilis Pandis (pandisv) wrote :

Side note: Can you imagine why this disrupts keyboard operation? The driver needs firmware to operate, and if you hibernate, the firmware is lost. On resume, the driver thinks the firmware is still there (AFAIK at least). But why should that interfere with the keyboard? (In any case, the driver should be reloaded. )

Revision history for this message
Vassilis Pandis (pandisv) wrote :

I'll be happy to provide any information neccessary to sort this out. This was still an issue with the release of Dapper, haven't tested it on Edgy.

Revision history for this message
Paul Sladen (sladen) wrote :

Can you test with Feisty please.

Changed in acpi-support:
assignee: sladen → nobody
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for acpi-support (Ubuntu) because there has been no activity for 60 days.]

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.