[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Unidentified subject!



	Unless you have some dire need to use ttyS0 and ttyS2 I would highly
recommend not trying to. Due to the fact that chances are both serial devices
are going to need the IRQ quite often it is better to use different ports.
For instance use ttyS0 and ttyS1 and disable ttyS2 and ttyS3. The other option
if you have the spare IRQs you could change ttyS2 and ttyS3 to use alternative
IRQs and thus allowing you to use all 4 serial ports without conflicts.

	Sincerely,
	Jeremy T. Bouse
	UnderGrid Network Services, LLC

J.A.Serralheiro was said to been seen saying:
> forgive me if this message shouldnt have been sent into this list. If so,
> please reply to me a suitable list for matters to come.
> My problem is with serial ports irq sharing. I have both /dev/ttyS0 and
> ttyS2 sharing irq 4, and ttyS1 and ttyS3 sharing irq 3.
> On ttyS0 I have the mouse connected. The thing is that when I try to use
> ttyS2 for something, there are only bytes transmitted if I move the mouse.
> I think that if this was an irq sharing problem ( hardware)
> I couldnt use either /dev/ttyS0 and ttyS2 at all.( except with irq=0 that 
> instructs the driver to poll. acording to the serial howto)
> 
> The serial device supports irq sharing and im running kernel 2.4.1.
> Here are some details of my systm bootup:
> 
> , shared memory at 0xd0000-0xd3fff.
> Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ
> SERIAL_PCI enabled
> ttyS00 at 0x03f8 (irq = 4) is a 16450
> ttyS01 at 0x02f8 (irq = 3) is a 16450
> ttyS02 at 0x03e8 (irq = 4) is a 16550A
> ttyS03 at 0x02e8 (irq = 3) is a 16550A
> Real Time Clock Driver v1.10d
> ttyS: 1 input overrun(s)
> ttyS: 1 input overrun(s)
> ttyS: 1 input overrun(s)
> 
> I made some diferent tryes, placing the mouse onto /dev/ttyS2 and using
> ttyS0 to transmit bytes, and the result is exactly the same.
> Does this driver gets crazy and only acknoledges interrupts when both
> devices r requesting attention? if so, then this could be  a simptom of
> non-supported irq sharing by the hardware. But each device works fine when
> there aren't any other processes requesting the use of hardware that use
> the
> same irq
> What exactly is the problem? does someone have a clue to fix it?
> 

-- 
,-----------------------------------------------------------------------------,
|Jeremy T. Bouse, CCNA - UnderGrid Network Services, LLC -  www.UnderGrid.net |
|        Public PGP/GPG fingerprint and location in headers of message        |
|     If received unsigned (without requesting as such) DO NOT trust it!      |
| undrgrid@UnderGrid.net  -  NIC Whois: JB5713  -  Jeremy.Bouse@UnderGrid.net |
`-----------------------------------------------------------------------------'

Attachment: pgpPP5uVpoSlN.pgp
Description: PGP signature


Reply to: