[hsflinux] Problem using cnxtinstall.run with Debian Linux For Conexant HSF 56K Data/Fax Modem
P. C. Chan
p_c_chan at hotmail.com
Fri Aug 12 10:30:56 EDT 2011
The laptop I am using now at work requires the alsa driver to be patched as well. I'll try the patch at home to see if it works for 3.0.1. I don't have to patch alsa on my desktop at home.
I think the kernel has changed quite a bit, more than the lock. I kept patching it on my own till somewhat 2.6.37 and gave up since the modem is something I haven't been using for years and probably something I can live without.
Date: Fri, 12 Aug 2011 10:53:12 +0100
From: chris at cvine.freeserve.co.uk
To: p_c_chan at hotmail.com
CC: jhart at customstaffing.com; hsflinux at lists.linuxant.com
Subject: Re: [hsflinux] Problem using cnxtinstall.run with Debian Linux For Conexant HSF 56K Data/Fax Modem
On Tue, 9 Aug 2011 14:53:38 -0400
"P. C. Chan" <p_c_chan at hotmail.com> wrote:
> Hi there,
> HSF support has been lacking behind quite a bit. I am currently
> running 3.0.1 kernel. The last time I was able to compile with some
> hacking was probably a year ago. :) Would there be any plan to
> catch up? If I need to use my HSF modem, I have to boot the system up
> using an older kernel, like 2.6.32 or something. Regards,P. C.Date:
> Tue, 9 Aug 2011 12:43:13 -0400 From: Jhart at customstaffing.com To:
> hsflinux at lists.linuxant.com Subject: [hsflinux] Problem using
> cnxtinstall.run with Debian Linux For Conexant HSF 56K
> Data/Fax Modem
Since no one is bothering to deal with this mailing list any more, and
the driver no longer works with the kernels of the current version of
most mainline distributions, I presume it is now effectively defunct.
It really shows the dangers of relying on proprietary code in linux
I have a patch which I use to compile the hsf driver with the latest
kernels, which I attach (I don't know if the mailing list will strip it
off, it might). I do not guarantee it, because none of us see the
proprietary code which it interfaces with. In particular, the file
osservices.c uses the global kernel lock for a purpose which is not
obvious to me. I have replaced it with a local lock which may well
either not meet the original purpose of using the global lock or may
now be completely unnecessary.
hsflinux mailing list
hsflinux at lists.linuxant.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hsflinux