Linux-kernel mailing list archive 1999-23,: Re: Hard coding default COM3/4 IRQ.

# Re: Hard coding default COM3/4 IRQ.

Riley Williams (rhw@MemAlpha.CX)
Sun, 6 Jun 1999 00:23:19 +0100 (GMT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Ralf Baechle: "Re: zero-copy TCP fileserving"
- Previous message: ron flory: "Re: 2.2.x instabilities"

Hi Mike.

>>> There is a CONFIG option for doing autodetection of the IRQ,
>>> CONFIG_SERIAL_SHARE_IRQ; you need to answer yes to
>>> CONFIG_SERIAL_EXTENDED to see the extra serial config options.
>>> The problem is that it doesn't always work.

>>> I suspect that Linux folk very often have a lot more random
>>> hardware attached to their machines than Windows folks, and
>>> these random ISA bus cards can confuse an autodetection
>>> algorithm.

>> Does this also mean that auto IRQ detection using setserial is
>> not reliable?

>> BTW: what sort of confusion do you mean?

> Yes. When I do auto IRQ with setserial, it returns something
> like: IRQ -1023128419585

> Since I only have 15 IRQ's on my machine, and since some of them
> are taken, and none negative - I'd say that setserial
> autodetection doesn't work right. My modem is on IRQ, which
> nothing else is conflicting with. Windows 95 gets the IRQ right
> without asking, it is not a winmodem.

> I haven't tried the kernel level autoirq yet... I will though
> soon...

I checked out the kernel autoirq for COM3 and COM4 on standard IO
addresses a while back, when 2.0.35 was current, and even on systems
where the hardware was set to irq's that conflicted with other
hardware in the system, it ALWAYS got the IRQ correct, and NEVER
locked one of those systems up.

Because of this, I proposed a patch that enabled the autoirq feature
for these two ports. It was rejected by the maintainer, Ted Ts'o, on
the grounds that enabling autoirq for HUB6 and the AST FourPort cards
(neither of which were affected by my patch) could result in the
kernel locking the system up.

I tried to point out to Ted that my patch did not touch support for
any of the cards he claimed to be worried about, but found Ted less
than interested in that fact. As a result, I will be rather surprised
to hear that any such patch has been accepted, unless it was submitted
by Linus himself.

Since the serial probing is done differently in the 2.2.x kernels, I'm
not planning on resubmitting my patch, and I'm also not planning on
wasting my time developing an equivalent patch for the 2.2.x kernels.

Best wishes from Riley.

+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Ralf Baechle: "Re: zero-copy TCP fileserving"
- Previous message: ron flory: "Re: 2.2.x instabilities"