snd-intel8x0m loaded for hardware it doesn't seem to support

Bug #8744 reported by Tim Hull
28
Affects Status Importance Assigned to Milestone
linux-source-2.6.15 (Ubuntu)
Invalid
Medium
Unassigned

Bug Description

I have a laptop (Thinkpad T42) w/a Conexant HSF modem. The installer configured
the snd_intel8x0m
driver on my system, which does me no good (it's only useful in conjunction
w/smartlink or other similar modems) and prevents me from installing hsfmodem
without removing this module.

Revision history for this message
Matt Zimmerman (mdz) wrote :

I have the same laptop, and it has the Intel ICH4 modem:

0000:00:1f.6 Modem: Intel Corp. 82801DB (ICH4) AC'97 Modem Controller (rev 01)

which is supposed to work with this driver. Please send lspci and lspci -n
output for your system.

Revision history for this message
Tim Hull (thully-arbornet) wrote :

Here is my lspci output:
0000:00:00.0 Host bridge: Intel Corp. 82855PM Processor to I/O Controller (rev 03)
0000:00:01.0 PCI bridge: Intel Corp. 82855PM Processor to AGP Controller (rev 03)
0000:00:1d.0 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #1 (rev 01)
0000:00:1d.1 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #2 (rev 01)
0000:00:1d.2 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #3 (rev 01)
0000:00:1d.7 USB Controller: Intel Corp. 82801DB (ICH4) USB2 EHCI Controller
(rev 01)
0000:00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 81)
0000:00:1f.0 ISA bridge: Intel Corp. 82801DBM LPC Interface Controller (rev 01)
0000:00:1f.1 IDE interface: Intel Corp. 82801DBM (ICH4) Ultra ATA Storage
Controller (rev 01)
0000:00:1f.3 SMBus: Intel Corp. 82801DB/DBM (ICH4) SMBus Controller (rev 01)
0000:00:1f.5 Multimedia audio controller: Intel Corp. 82801DB (ICH4) AC'97 Audio
Controller (rev 01)
0000:00:1f.6 Modem: Intel Corp. 82801DB (ICH4) AC'97 Modem Controller (rev 01)
0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7
LW [Radeon Mobility 7500]
0000:02:00.0 CardBus bridge: Texas Instruments PCI4520 PC card Cardbus
Controller (rev 01)
0000:02:00.1 CardBus bridge: Texas Instruments PCI4520 PC card Cardbus
Controller (rev 01)
0000:02:01.0 Ethernet controller: Intel Corp. 82540EP Gigabit Ethernet
Controller (Mobile) (rev 03)
0000:02:02.0 Network controller: Intel Corp. Intel(R) PRO/Wireless 2200BG (rev 05)
And here is my lspci -n output:
0000:00:00.0 Class 0600: 8086:3340 (rev 03)
0000:00:01.0 Class 0604: 8086:3341 (rev 03)
0000:00:1d.0 Class 0c03: 8086:24c2 (rev 01)
0000:00:1d.1 Class 0c03: 8086:24c4 (rev 01)
0000:00:1d.2 Class 0c03: 8086:24c7 (rev 01)
0000:00:1d.7 Class 0c03: 8086:24cd (rev 01)
0000:00:1e.0 Class 0604: 8086:2448 (rev 81)
0000:00:1f.0 Class 0601: 8086:24cc (rev 01)
0000:00:1f.1 Class 0101: 8086:24ca (rev 01)
0000:00:1f.3 Class 0c05: 8086:24c3 (rev 01)
0000:00:1f.5 Class 0401: 8086:24c5 (rev 01)
0000:00:1f.6 Class 0703: 8086:24c6 (rev 01)
0000:01:00.0 Class 0300: 1002:4c57
0000:02:00.0 Class 0607: 104c:ac46 (rev 01)
0000:02:00.1 Class 0607: 104c:ac46 (rev 01)
0000:02:01.0 Class 0200: 8086:101e (rev 03)
0000:02:02.0 Class 0280: 8086:4220 (rev 05)

Even though the T41's have a Smartlink modem (which is compatible with this driver)
I'm almost certain the T42 has a Conexant HSF modem (as I never did get the
SmartLink
modem drivers to work, but the Conexant HSF drivers from Linuxant work perfectly -
I've used them to get online). Unless this is a situation of a softmodem that
works w/ multiple types of drivers (and just happens to be easier to get going
with Conexant drivers than SmartLink drivers), I think this is an HSF modem that
is being detected incorrectly.

Revision history for this message
Matt Zimmerman (mdz) wrote :

The code is quite explicit about support for the ICH4; if it is not working,
then that is most likely a bug (either in the driver or supporting software),
and not a problem with the incorrect driver being loaded.

I experimented with slmodem a bit to test out the modem on my system, and it
recognises the ALSA modem device and initialises itself, but doesn't work. When
snd-intel8x0m is loaded, I get the following message:

Oct 2 19:49:01 localhost kernel: MC'97 1 converters and GPIO not ready (0xff00)

and when I try to dial the modem through slmodemd, I get:

Oct 2 19:53:06 localhost kernel: codec_semaphore: semaphore is not ready
[0x1][0x700300]
Oct 2 19:53:06 localhost kernel: codec_write 1: semaphore is not ready for
register 0x54
Oct 2 19:53:09 localhost kernel: codec_semaphore: semaphore is not ready
[0x1][0x700300]
Oct 2 19:53:09 localhost kernel: codec_write 1: semaphore is not ready for
register 0x54

I think this indicates that the driver is not working properly.

Revision history for this message
Herbert Xu (herbert-gondor) wrote :

Unfortunately the PCI IDs only refer to the codec. You can connect any modem
chip to that code. So attempting to identify the modem type by looking at the
PCI ID is pretty silly. However, I'm not aware of a good way to identify the
chip other than running through the various drivers.

Revision history for this message
Matt Zimmerman (mdz) wrote :

What would the ideal solution be? Should snd-intel8x0m have support added to it
for this device, since it is accessed through the same hardware interface? Or
do we really need to have separate drivers and find a way to switch between them?

Revision history for this message
Herbert Xu (herbert-gondor) wrote :

It depends on whether the codec support in it can be used by both modems or not.
 If it could then the ideal solution is to modify the connexant driver to use
this interface rather than its own. I'm sorry but I don't have time to look at
this right now.

Revision history for this message
Tim Hull (thully-arbornet) wrote :

The Linuxant driver is proprietary, so you probably would have to work with Linuxant
if you wanted it to use ALSA's drivers. I think I'll e-mail them about this.

Revision history for this message
Matt Zimmerman (mdz) wrote :

*** Bug 10645 has been marked as a duplicate of this bug. ***

Revision history for this message
Tim Hull (thully-arbornet) wrote :

could this just be blacklisted by default (or disabled in some way)? Conexant
drivers are proprietary, and
they didn't express much of an interest in making this change.

Revision history for this message
Matt Zimmerman (mdz) wrote :

It could be, but it's not clear to me that this would be a correct default.
Drivers should only be blacklisted if they are obsolete or broken.

Revision history for this message
Tim Hull (thully-arbornet) wrote :

I feel this should be blacklisted because 1)on its own - it does nothing - extra
software is required to use this 2)this doesn't work
with all modems utilizing this chip - and for some it blocks their use. So, in
a way this driver is broken, at least for some modems using this chip.
Probably, the best solution would be to work with Linuxant to officially support
this driver in Ubuntu, however - Ubuntu should accomodate this driver as much as
possible otherwise - as not to make it hard for novices to install it.

Revision history for this message
Matt Zimmerman (mdz) wrote :

*** Bug 11375 has been marked as a duplicate of this bug. ***

Revision history for this message
Matt Zimmerman (mdz) wrote :

*** Bug 11614 has been marked as a duplicate of this bug. ***

Revision history for this message
Tim Hull (thully-arbornet) wrote :

It seems as though this should be done (snd-intel8x0m blacklisted) because:
1) The one thing that does use this driver, slmodemd (which is non-free) will
autoload it if necessary
2) HSF modem drivers can't be installed when this is loaded - it has to be
blacklisted and the system rebooted before this will function
properly - which is a bit annoying, and impossible on the live CD (if I had to
install them from a USB key to do something in a pinch, for instance).

What are the thoughts on this?

Revision history for this message
Thomas Hood (jdthood) wrote :

I think that the package that delivers the HSF modem software should
include the hotplug and discover blacklist files that are required
for it to operate correctly.

Revision history for this message
Matt Zimmerman (mdz) wrote :

I don't think that these drivers are packaged; they certainly couldn't be part
of a free distribution at any rate, because they cost money :-/

That does seem like the correct solution, but since it can't be implemented in
Ubuntu, the request should be sent to the HSF driver maintainers instead.

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

Duplicates of this bug

Other bug subscribers

Remote bug watches

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