Re: Intel D2500CC motherboard and strange RS232/UART behavior

On Thursday, April 11, 2013 5:37:48 pm Poul-Henning Kamp wrote:
> In message <201304111050.37055.jhb_at_freebsd.org>, John Baldwin writes:
> 
> >> Though if these ports don't have the logic that the AST cards did to
> >> share the IRQ, that'd make it hard...
> >> 
> >> The sio man page talks about this...
> >
> >These are multiport cards and something like puc or digi, etc. is fine for
> >those.  The OP's issue is that he has a board with 4 independent 16550
> >UARTs which are attempting to share IRQs.  Those are not multiport cards
> >and are thus a separate issue.
> 
> I think you are mistaken, the 4 uarts are in the same chip and I am
> sure they have done something sensible with the interrupts so they
> can be shared.

No, if they show up as 4 ACPI devices, they are four devices.  Just like how 
your AHCI and USB controllers show up as separate PCI devices even though they 
are all physically in one chip on the motherboard.  puc(4) handles the case of 
having one PCI device (function really) which has exactly one INT# interrupt 
line contain multiple serial and/or ppc ports.  (It also has a pccard 
attachment so it can handle a pccard that contains multiple ports.  Again
that would be a device that has one interrupt line to the host machine that it 
shares amongst its ports, not N ports each with their own interrupt line and 
register set.)

Multiport isa(4) cards were not as generic as PCI cards, so we have several 
different drivers for those (rc, digi, cy) and even drivers for some non-
generic PCI cards (rp).  Note that there is no ISA attachment for puc, just 
PCI and pccard.

All that aside, none of this is really relevant to the OP's issue.  The kernel 
will share interrupt handlers just fine at the generic interrupt handle level.  
Only setting INTR_EXCL when calling bus_setup_intr() or not setting 
RF_SHAREABLE when calling bus_alloc_resource() should prevent sharing.  I'm 
still waiting to see if the OP can figure out exactly which step in the 
interrupt setup stage is failing.

-- 
John Baldwin