I'm transiting myself to the 2.6 kernel base. And I have a persisting
problem with my ISA Courier modem. It is set into the PnP mode thru
its jumpers and it works just fine under 2.4 kernels. And under
2.6.8.1 it doesn't work for the set of reasons.
First. The new kernel detects it thru the startup:
isapnp: Scanning for PnP cards...
isapnp: Card 'USRobotics Courier V.Everything'
isapnp: 1 Plug & Play card detected total
But the modem isn't activated. After a boot I have:
cat /sys/devices/pnp1/01:01/01:01.00/resources
state = disabled
and /dev/tts/2 device is just died (I'm using devfs for a while).
Then I try to activate it as described in the Documentation/pnp.txt:
echo auto > /sys/devices/pnp1/01:01/01:01.00/resources
cat /sys/devices/pnp1/01:01/01:01.00/resources
state = disabled
io 0x3e8-0x3ef
irq 5
So, both the irq and io have been assigned correctly, but the card is
still disabled.
Then I try:
echo activate > /sys/devices/pnp1/01:01/01:01.00/resources
cat /sys/devices/pnp1/01:01/01:01.00/resources
state = active
io 0x3e8-0x3ef
irq 5
Ok, some result has been achieved. Then I load the serial modules:
8250 and 8250_pnp (in that order). If I load them before the
activating of the card, I have nothing (of course?). So, I load them
after that, but some interesting things happen here too: 8250 module
finds the modem, but 8250_pnp finds the other two serial ports which
are in the motherboard. I wonder: these ports are the embedded ones,
they are not PnP, so why they are detected by the pnp module? And,
from the other hand, why the PnP card is detected by the non-pnp
module?
But nevertheless, some result are already here: it seems that
/dev/tts/2 has come to life - stty -F /dev/tts/2 starts to work.
But after that nobody can conversate with the modem: mgetty, ppp's
chat, minicom - all of them have a timeouts waiting for a respond from
the modem. And what else do I have:
cat /proc/tty/driver/serial
serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:4 tx:8 rx:208 fe:4 brk:7
1: uart:16550A port:000002F8 irq:3 tx:1959289 rx:11505900 RTS|CTS|DTR|DSR|CD
2: uart:16550A port:000003E8 irq:4 tx:0 rx:0 CTS|DSR
3: uart:unknown port:000002E8 irq:3
4: uart:unknown port:00000000 irq:0
5: uart:unknown port:00000000 irq:0
6: uart:unknown port:00000000 irq:0
7: uart:unknown port:00000000 irq:0
According to this info, the ttyS2 device have an irq 4 assigned
vs. irq 5 from the /sys/.../resources. I don't know, may be it is the
problem itself. BTW, the first two serial ports work - there is a
mouse at the ttyS0 and the external modem at the ttyS1.
So, this all looks like some error in the PnP-sysfs-serial chain, but
I'm absolutely unsure. May be it is the devfs-related problem?
And all the above in short:
1) The 2.6 kernel doesn't activate the ISA PnP modem at the boot,
while the 2.4 one always does.
2) The 8250 driver finds the PnP card's port, while the 8250_pnp finds
the non-PnP ports.
3) The /proc/tty/driver/serial file contains an incorrect information
about the IRQ assigned to the PnP port.
Denis Zaitsev wrote:
> 1) The 2.6 kernel doesn't activate the ISA PnP modem at the boot,
> while the 2.4 one always does.
2.4 used to scan the ISA PnP device ID string for some common substrings
indicating a modem given a completely unknown ISA PnP device (the code
is still present -- see drivers/serial/8250_pnp.c:check_name()) while
2.6 really needs your modem's PnP ID to be listed.
> 2) The 8250 driver finds the PnP card's port, while the 8250_pnp finds
> the non-PnP ports.
8250_pnp not finding it is therefore very likely a simple matter of it
not knowing that it should be driving it. Try seeing if your modem's PnP
ID (/sys/bus/pnp/devices/?/id) is listed in drivers/serial/8250_pnp.c
and if not add it (and send as a patch to Russel King).
8250 itself finding it was no doubt due to you enabling the port
yourself so that from its standpoint, it was just another serial port
already present. With your modem's ID added, 8250_pnp should find and
activate the mdem itself without you needing to do anything other than
"modprobe 8250_pnp"
Hope that helps.
Rene.
On Sat, Oct 09, 2004 at 10:18:36PM +0200, Rene Herman wrote:
> Denis Zaitsev wrote:
>
> > 1) The 2.6 kernel doesn't activate the ISA PnP modem at the boot,
> > while the 2.4 one always does.
>
> 2.4 used to scan the ISA PnP device ID string for some common substrings
> indicating a modem given a completely unknown ISA PnP device (the code
> is still present -- see drivers/serial/8250_pnp.c:check_name()) while
> 2.6 really needs your modem's PnP ID to be listed.
>
> > 2) The 8250 driver finds the PnP card's port, while the 8250_pnp finds
> > the non-PnP ports.
>
> 8250_pnp not finding it is therefore very likely a simple matter of it
> not knowing that it should be driving it. Try seeing if your modem's PnP
> ID (/sys/bus/pnp/devices/?/id) is listed in drivers/serial/8250_pnp.c
> and if not add it (and send as a patch to Russel King).
Ok, it isn't listed (USR0009). I'll send a patch. BTW, there is some
other ID - /sys/devices/pnp1/01:01/card_id - and it contains USR0101.
What's this?
> 8250 itself finding it was no doubt due to you enabling the port
> yourself so that from its standpoint, it was just another serial port
> already present.
But why doesn't it find the two standard mb-embedded ports? And why
they are found by 8250_pnp? Is it a normal behaviour?
> With your modem's ID added, 8250_pnp should find and activate the
> mdem itself without you needing to do anything other than "modprobe
> 8250_pnp"
Ok. I' trying. The kernel is compiling...
> Hope that helps.
Thanks. But what about the incorrect info in /proc/tty/driver/serial?
Denis Zaitsev wrote:
> Ok, it isn't listed (USR0009). I'll send a patch. BTW, there is some
> other ID - /sys/devices/pnp1/01:01/card_id - and it contains USR0101.
> What's this?
The PnP card ID, with the USR0009 the PnP device ID; PnP cards can (and
often do) have more than one device. For me, they are both the same:
$ cat /sys/devices/pnp1/01\:02/{card_,01\:02.00/}id
ETT0002
ETT0002
I do believe you need the device ID in 8250_pnp, but try the card ID
when it doesn't work, I guess.
>>8250 itself finding it was no doubt due to you enabling the port
>>yourself so that from its standpoint, it was just another serial port
>>already present.
>
> But why doesn't it find the two standard mb-embedded ports? And why
> they are found by 8250_pnp? Is it a normal behaviour?
That they are found by 8250_pnp seems okay; onboard ports are normally
PnP BIOS devices -- the devices in /sys/devices/pnp0. However, normally
the BIOS will have enabled those ports itself meaning 8250 would pick
them up already, so no, that's not standard.
> Thanks. But what about the incorrect info in /proc/tty/driver/serial?
Skipping that one. Maybe that will fix itself once you have the PnP ID
listed.
Rene.
PS: CCing you, but gw.anda.ru seems to have decided I'm a spammer.
Denis Zaitsev wrote:
> With the device ID added all the things just work. Ok. Thanks. I'm
> sending the patch.
Good.
> /proc/tty/driver/serial shows the correct info for now. Does the fact
> that it used to do not means that something wrong with sysfs PnP
> activation mechanics?
That would appear to be the case yes. Adam Belay <[email protected]> is
the person to talk to concerning PnP issues, if you care to.
Rene.
On Sun, Oct 10, 2004 at 12:46:24AM +0200, Rene Herman wrote:
> Denis Zaitsev wrote:
>
> > /proc/tty/driver/serial shows the correct info for now. Does the fact
> > that it used to do not means that something wrong with sysfs PnP
> > activation mechanics?
>
> That would appear to be the case yes. Adam Belay <[email protected]> is
> the person to talk to concerning PnP issues, if you care to.
Thanks.