Bug 10735

Summary: kudzu 0.36-2 doesn't see my USR modem
Product: [Retired] Red Hat Linux Reporter: Jonathan Kamens <jik>
Component: kudzuAssignee: Bill Nottingham <notting>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.2CC: rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-02-04 22:40:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
strace output for kudzu run that doesn't detect the modem
none
strace of kudzu-0.38-1 not detectingmodem
none
hwconf
none
Hacked but functioning PnP serial.c none

Description Jonathan Kamens 2000-04-11 21:51:34 UTC
kudzu-0.27-1 detected my USR modem just fine:

class: MODEM
bus: SERIAL
detached: 1
device: ttyS1
driver: ignore
desc: "USR|0100 Courier V.Everything EXT"
pnpmfr: USR
pnpmodel: 0100
pnpcompat: PNPC107
pnpdesc: Courier V.Everything EXT

When I upgraded to kudzu-0.36-2, it first informed me that my modem was
a generic serial modem rather than the specific modem shown above, and
then when I tried to duplicate that, it didn't find the modem at all.

I will attach strace output from kudzu-0.36-2, in case that's helpful.

Comment 1 Jonathan Kamens 2000-04-11 21:52:59 UTC
Created attachment 194 [details]
strace output for kudzu run that doesn't detect the modem

Comment 2 Bill Nottingham 2000-04-12 15:36:59 UTC
It's not detecting it because the modem port is locked
from another program (the file /var/lock/LCK..modem
exists), so therefore kudzu won't probe that serial
port.

If you remove the /var/lock/LCK..modem file, does it
then detect the modem correctly?

Comment 3 Jonathan Kamens 2000-04-13 12:41:59 UTC
Created attachment 198 [details]
strace of kudzu-0.38-1 not detectingmodem

root@jik:/c/build/curl!67# ls -l /var/lock/LCK*; kudzu; rpm -q kudzu
ls: No match.
kudzu-0.38-1
root@jik:/c/build/curl!68#

I'll attach another strace.out from kudzu-0.38-1 when the lock file does not
exist.

Comment 4 Bill Nottingham 2000-04-14 21:05:59 UTC
What's the current /etc/sysconfig/hwconf when you're running this?

(unfortunately, serial probe problems are very hard to pin down
without access to the hardware in question... :( )

Comment 5 Jonathan Kamens 2000-04-16 02:45:59 UTC
Created attachment 203 [details]
hwconf

Comment 6 Bill Nottingham 2001-02-01 23:35:41 UTC
Eek, I've ignored this for *way* too long.

I'm assuming the same behavior happens with the current version
(the serial code hasn't changed...)

Comment 7 Jonathan Kamens 2002-01-23 17:10:57 UTC
I have not seen this problem in a long time.  I don't know what has changed to
make it go away.


Comment 8 DaveG 2002-04-19 03:24:02 UTC
Hi,

I was also having problems with kudzu-0.99.23 (RH7.2) and my USR modem.

I took a look under the hood and found the problems...
Older USR modems are not PnP but have ATI9 responses in the right format. The 
problem is in parse_pnp_string() - The string has <cr><lf> before the 
opening "(" and the PnP version number is in decimal rather than coded binary. 
The string also has extensions, but no checksum. The end result is that the 
valid ATI9 response gets rejected.

I have hacked around with serial.c and produced something that works. The only 
problem left is that the modem refuses to dial after being probed. The problem 
must be with the state of the serial port as resetting the modem doesn't clear 
it.

Once I work out how to post my modified serial.c, I'll pass it on. Sorry it got 
hacked around, but I needed to find out what was happening, so a diff might be 
diffucult! ('scuse the pun)

Comment 9 DaveG 2002-04-19 03:26:30 UTC
Created attachment 54524 [details]
Hacked but functioning PnP serial.c

Comment 10 Bill Nottingham 2005-02-04 22:40:49 UTC
Closing out bugs from older, no longer supported releases. Apologies for the
lack of response.