[conspire] Cabal Follow Up

Rick Moen rick at linuxmafia.com
Mon Dec 10 17:51:01 PST 2012


Quoting Howard Susman (howard at scsurplus.com):

> Rick: Apparently I did not really understand what you were telling
> me, but took your advice and read more about pnp cards.  I think
> what you were trying to tell me was exactly my situation. I now
> have a plan to check it out.  I might have it working soon. Thank
> you.
>
> You mentioned that my board might not be initialized properly by
> pnp.  I replaced the serial board to a more current board.  I seem
> to have all my serial ports working now.
> Again, thanks.

Glad to have helped.  Let me try to recap what I was saying, Saturday
night.  (The symptom you had was that most but not all recent distros
including RHEL 6.3 were not validly supporting your serial ports, though
old distrols continued to do so.)

(This will be detail-laden and go back to ancient PC days.  Don't 
worry about the details, but just follow the general gist of it.)


Way back in the bad old days, we had ISA cards with things like RS-232C 
serial ports on them.  Each such port had to be hardware-configured
(usually jumpers, though theoretically switches could be used) to
assign a unique pair of hardware resources to each serial port, a
hardware IRQ (interrupt channel) and an I/O base address.  I covered
this situation in a 1995 magazine article:

http://linuxmafia.com/faq/Hardware/chart.html

As cited in my article, conventional IRQ assignments for serial ports were:

 3   COM2 or COM4
 4   COM1 or COM3

Conventional I/0 base address assignments in 'h' = hexadecimal format:

3F8h COM1
2F8h COM2
3E8h COM3
2E8h COM4

For convenience, let's refer to IRQs and I/O base addresses collectively
as 'hardware resources'.


Right around 1995, Microsoft invented something called ISA Plug'n'Play,
an overlay specification for ISA that in theory permitted motherboards
to dynamically assign hardware resources (to boards that supported its
spec) and let the OS know.  This never worked very well, but it sort of
worked.  The _real_ fix came with the rise of PCI-connected boards as
opposed to ISA.  PCI inherently is dynamic in its management of hardware
resources.  A chip on the motherboard called the PCI controller knows
what hardware resources exist to be doled out, and notifies devices what
they can have.  (Ports on the motherboard are managed by the PCI
controller for these purposes.)  It also answers queries from the OS
about such assignments.

The main reason I suggested you open the case was to see whether the
board housing your four serial ports (the four beyond the one on the
motherboard itself) to see whether the board was ISA or PCI.

Mind you, motherboard have omitted ISA slots for quite a few years (and
good riddance, basically).  But it was a significant question for your
system:

-- If the board was PCI (but not buggy or damaged), then it should have
gotten hardware resources dynamically without any fuss -- though I
noticed at the time you had BIOS Setup item 'PCI/Plug and Play' set to
'No', which seemed like a really bad idea and probably very unhelpful.

-- If the board was ISA (and thus really ancient), then either it had
jumpers/switches to select hardware resources (was 'old school', so to
speak, ignoring Plug'n'Play instructions), _or_ it lacked such
jumpers/switches and thus was intended to be configured via ISA
Plug'n'Play.


Your account (above) doesn't really clarify what sort of board you
replaced, but very likely the new one is a functional, undamaged PCI
board.  Which is good.





More information about the conspire mailing list