RE: Intel D2500CC motherboard and strange RS232/UART behavior
Hello Lev,
to be precise, I disabled serial ports 3 and 4 and
swapped ports 1 and 2 to the back panel in the
machine's BIOS.
Then I added a test to the ioapic_config_intr function
to detect the trig == INTR_TRIGGER_EDGE and
pol == INTR_POLARITY_LOW case and to rewrite it to
INTR_TRIGGER_EDGE and INTR_TRIGGER_HIGH.
I have not tried to enable port 3 and 4 because I
cannot test them (could not find the necessary
connectors).
Regards
Juergen Weiss |Universitaet Mainz, Zentrum fuer Datenverarbeitung,
we...@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-26407
-Original Message-
From: owner-freebsd-curr...@freebsd.org
[mailto:owner-freebsd-curr...@freebsd.org] On Behalf Of Lev Serebryakov
Sent: Friday, May 24, 2013 10:12 PM
To: Weiß, Jürgen
Cc: 'freebsd-current@freebsd.org'
Subject: Re: Intel D2500CC motherboard and strange RS232/UART behavior
Hello, Jürgen.
You wrote 24 мая 2013 г., 23:15:17:
WJ According to the ACPI of the board, uart0 and uart 2
WJ use IRQ 3 and
WJ IRQ (Edge, ActiveLow, Shared, )
WJ{3}
WJ uart1 and uart3 use IRQ 4
WJ IRQ (Edge, ActiveLow, Shared, )
WJ{4}
WJ ioapic_config_intr is called with trig == INTR_TRIGGER_EDGE and
WJ pol == INTR_POLARITY_LOW.
WJ The combinatation of Edge and ActiveLow seems kind of broken.
WJ Forcing the polarity in ioapic_config_intr to INTR_POLARITY_HIGH
WJ and disabling uart 2 and uart 3 results in two working serial
WJ interfaces.
WJ So what is the correct fix to this?
I've tried to disable ACPI access to these UARTs at all, then only
two of them are detected, but they don't work either. And I cannot
disable 2 and 3, as screen I have attached to this box (old IBM-made
LCD from register/cashier machine, which works perfectly with FreeBSD
default text console on this MoBo) cannot show text (!) BIOS setup
screen to me -- it shows only blue noise and looks like compeltely
out-of-sync. I need to bring this box to some other dispaly and try
to disable these two UARTs AND disable ACPI for them with loader
tunable.
--
// Black Lion AKA Lev Serebryakov l...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
According to the ACPI of the board, uart0 and uart 2
use IRQ 3 and
IRQ (Edge, ActiveLow, Shared, )
{3}
uart1 and uart3 use IRQ 4
IRQ (Edge, ActiveLow, Shared, )
{4}
ioapic_config_intr is called with trig == INTR_TRIGGER_EDGE and
pol == INTR_POLARITY_LOW.
The combinatation of Edge and ActiveLow seems kind of broken.
Forcing the polarity in ioapic_config_intr to INTR_POLARITY_HIGH
and disabling uart 2 and uart 3 results in two working serial
interfaces.
So what is the correct fix to this?
Regards
Juergen Weiss
Juergen Weiss |Universitaet Mainz, Zentrum fuer Datenverarbeitung,
we...@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-26407
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
Hello, Jürgen.
You wrote 24 мая 2013 г., 23:15:17:
WJ According to the ACPI of the board, uart0 and uart 2
WJ use IRQ 3 and
WJ IRQ (Edge, ActiveLow, Shared, )
WJ{3}
WJ uart1 and uart3 use IRQ 4
WJ IRQ (Edge, ActiveLow, Shared, )
WJ{4}
WJ ioapic_config_intr is called with trig == INTR_TRIGGER_EDGE and
WJ pol == INTR_POLARITY_LOW.
WJ The combinatation of Edge and ActiveLow seems kind of broken.
WJ Forcing the polarity in ioapic_config_intr to INTR_POLARITY_HIGH
WJ and disabling uart 2 and uart 3 results in two working serial
WJ interfaces.
WJ So what is the correct fix to this?
I've tried to disable ACPI access to these UARTs at all, then only
two of them are detected, but they don't work either. And I cannot
disable 2 and 3, as screen I have attached to this box (old IBM-made
LCD from register/cashier machine, which works perfectly with FreeBSD
default text console on this MoBo) cannot show text (!) BIOS setup
screen to me -- it shows only blue noise and looks like compeltely
out-of-sync. I need to bring this box to some other dispaly and try
to disable these two UARTs AND disable ACPI for them with loader
tunable.
--
// Black Lion AKA Lev Serebryakov l...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
Hello, Poul-Henning. You wrote 12 апреля 2013 г., 1:37:48: 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. PHK I think you are mistaken, the 4 uarts are in the same chip and I am PHK sure they have done something sensible with the interrupts so they PHK can be shared. Maybe physically, it is one chip (I'm sure, it is), but they are detected as completely independent devices, each with its own I/O port and interrupt... Multiport cards typically group access to logic 16550 registers... -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
Hello, Poul-Henning. You wrote 12 апреля 2013 г., 1:37:48: PHK I think you are mistaken, the 4 uarts are in the same chip and I am PHK sure they have done something sensible with the interrupts so they PHK can be shared. I mean, there is no good way to distinguish between this (hardware) implementation and true 4 single UART chips, when it is identify itself as generic 16550 UART, 4 times, at 4 I/O addresses. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
In message 98147894.20130412171...@serebryakov.spb.ru, Lev Serebryakov writes : I mean, there is no good way to distinguish between this (hardware) implementation and true 4 single UART chips, when it is identify itself as generic 16550 UART, 4 times, at 4 I/O addresses. That is a kernel configuration issue entirely separate from the question about the hardware being built to allow and support interrupt sharing in the first place. Many old ISA cards also were not recognizable and required hint'ing, for the exact same reason. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
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@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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
In message 201304121214.32331@freebsd.org, John Baldwin writes: John, Quite frankly I don't think you have the age to teach me about ISA multiport serial cards :-) Multiport isa(4) cards were not as generic as PCI cards, so we have several different drivers for those (rc, digi, cy) [...] And the most important of them all: sio(4), where you could use the flags to configure the generic lets just slap 8 UARTS and an or-gate on the IRQ line on an ISA card type of multiport serial cards. The cards that needed dedicated drivers were the ones where they tried to be smarter than that. 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. You may have missed that I mentioned this: I have one of these mobos too, and from my similar experiments, I concluded that the interrupts don't arrive in the first place. But that was very fast and loose, and I didn't particular need the four serial ports, so I didn't spend more time on it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
Hello, John. You wrote 10 апреля 2013 г., 0:08:09: JB Can you assign different interrupts via the BIOS somehow? I've tried it! And! I'm SHOCKED: this MoBo try to use some strange mode in BIOS Setup, which isn't supported by screen, installed where this router installed now! It looks like text mode (I've attached it to other monitor when set it up and it was text mode for sure), but my old industrian 10 IBM-made LCD shows Unsupported mopde when I press F2 on boot! It is very strange :) -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
John Baldwin wrote this message on Wed, Apr 10, 2013 at 10:16 -0400: On Wednesday, April 10, 2013 3:04:15 am Poul-Henning Kamp wrote: In message 1424327083.20130410103...@serebryakov.spb.ru, Lev Serebryakov writ es: Hello, Poul-Henning. You wrote 10 =E0=EF=F0=E5=EB=FF 2013 =E3., 0:52:04: Problem is, that every uart device now is independent from each other in good OOP style, and it looks like interrupt sharing we need one interrupt handler per irq (not per device), which will now about several UARTs. Something like multiport device, bot not exactly. PHK That is what the puc(4) driver does... Yes, for PCI devices only :( Yes, it needs to learn to do it from hints for ISA. No, that is that not the right hammer for this. This isn't a single ISA device with two ports (which is what puc(4) is aimed at). Don't you remeber the old AST 4 port cards? Heck, even our handbook talks about how to make those cards work: https://www.freebsd.org/doc/en/books/faq/serial.html#enable-multiport-serial I have a couple of these cards around somewhere I think... Uses a DB-37 connector for the ports 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... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
On Thursday, April 11, 2013 3:01:40 am John-Mark Gurney wrote: John Baldwin wrote this message on Wed, Apr 10, 2013 at 10:16 -0400: On Wednesday, April 10, 2013 3:04:15 am Poul-Henning Kamp wrote: In message 1424327083.20130410103...@serebryakov.spb.ru, Lev Serebryakov writ es: Hello, Poul-Henning. You wrote 10 =E0=EF=F0=E5=EB=FF 2013 =E3., 0:52:04: Problem is, that every uart device now is independent from each other in good OOP style, and it looks like interrupt sharing we need one interrupt handler per irq (not per device), which will now about several UARTs. Something like multiport device, bot not exactly. PHK That is what the puc(4) driver does... Yes, for PCI devices only :( Yes, it needs to learn to do it from hints for ISA. No, that is that not the right hammer for this. This isn't a single ISA device with two ports (which is what puc(4) is aimed at). Don't you remeber the old AST 4 port cards? Heck, even our handbook talks about how to make those cards work: https://www.freebsd.org/doc/en/books/faq/serial.html#enable-multiport-serial I have a couple of these cards around somewhere I think... Uses a DB-37 connector for the ports 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. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
Hello, matt. You wrote 11 апреля 2013 г., 9:19:13: m On 04/07/13 12:43, Lev Serebryakov wrote: How could I debug this? m Does this board have any fancy BIOS - RS232 redirection? Could m something like that cause these symptoms? Nope. It is simple Desktop board (with LPT and 4xRS232, yes) from BIOS point of view (unfortunately, COM BIOS is very handy for me). -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
In message 201304111050.37055@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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
Hello, John. You wrote 10 апреля 2013 г., 0:58:22: Problem is, that every uart device now is independent from each other in good OOP style, and it looks like interrupt sharing we need one interrupt handler per irq (not per device), which will now about several UARTs. Something like multiport device, bot not exactly. JB No, the interrupt code itself will handle shared interrupts (it will JB call all handlers). I think in practice that uart is setting And what will happen, if there is two UARTs asserting interrupt in same time? First one returns FILTER_HANDLED, will second handler be called? ISA interrupt sharing IS NOT so simple. sio contains a lot of obscure code to work. JB INTR_EXCL or some such and/or uart doesn't set RF_SHAREABLE when JB allocating the IRQ. It is probably the latter. You could try just JB adding RF_SHAREABLE to the bus_alloc_resource_any() for the IRQ to JB uart and see if that fixes it. sc-sc_ires = bus_alloc_resource_any(dev, SYS_RES_IRQ, sc-sc_irid, RF_ACTIVE | RF_SHAREABLE); It is here. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
Hello, Poul-Henning. You wrote 10 апреля 2013 г., 0:52:04: Problem is, that every uart device now is independent from each other in good OOP style, and it looks like interrupt sharing we need one interrupt handler per irq (not per device), which will now about several UARTs. Something like multiport device, bot not exactly. PHK That is what the puc(4) driver does... Yes, for PCI devices only :( -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
In message 1424327083.20130410103...@serebryakov.spb.ru, Lev Serebryakov writ es: Hello, Poul-Henning. You wrote 10 =E0=EF=F0=E5=EB=FF 2013 =E3., 0:52:04: Problem is, that every uart device now is independent from each other in good OOP style, and it looks like interrupt sharing we need one interrupt handler per irq (not per device), which will now about several UARTs. Something like multiport device, bot not exactly. PHK That is what the puc(4) driver does... Yes, for PCI devices only :( Yes, it needs to learn to do it from hints for ISA. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
On 9 April 2013 23:28, Lev Serebryakov l...@freebsd.org wrote: Hello, John. You wrote 10 апреля 2013 г., 0:58:22: Problem is, that every uart device now is independent from each other in good OOP style, and it looks like interrupt sharing we need one interrupt handler per irq (not per device), which will now about several UARTs. Something like multiport device, bot not exactly. JB No, the interrupt code itself will handle shared interrupts (it will JB call all handlers). I think in practice that uart is setting And what will happen, if there is two UARTs asserting interrupt in same time? First one returns FILTER_HANDLED, will second handler be called? ISA interrupt sharing IS NOT so simple. sio contains a lot of obscure code to work. .. surely it's solvable with a bit of ugliness? Eg, looping over them until they all return not handled or you hit a limit, or something equally ew. .. assuming that it is broken in the first place, that is. Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
On Wednesday, April 10, 2013 3:04:15 am Poul-Henning Kamp wrote: In message 1424327083.20130410103...@serebryakov.spb.ru, Lev Serebryakov writ es: Hello, Poul-Henning. You wrote 10 =E0=EF=F0=E5=EB=FF 2013 =E3., 0:52:04: Problem is, that every uart device now is independent from each other in good OOP style, and it looks like interrupt sharing we need one interrupt handler per irq (not per device), which will now about several UARTs. Something like multiport device, bot not exactly. PHK That is what the puc(4) driver does... Yes, for PCI devices only :( Yes, it needs to learn to do it from hints for ISA. No, that is that not the right hammer for this. This isn't a single ISA device with two ports (which is what puc(4) is aimed at). -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
On Wednesday, April 10, 2013 2:28:38 am Lev Serebryakov wrote: Hello, John. You wrote 10 апреля 2013 г., 0:58:22: Problem is, that every uart device now is independent from each other in good OOP style, and it looks like interrupt sharing we need one interrupt handler per irq (not per device), which will now about several UARTs. Something like multiport device, bot not exactly. JB No, the interrupt code itself will handle shared interrupts (it will JB call all handlers). I think in practice that uart is setting And what will happen, if there is two UARTs asserting interrupt in same time? First one returns FILTER_HANDLED, will second handler be called? They are all called in turn. ISA interrupt sharing IS NOT so simple. sio contains a lot of obscure code to work. INTR_FAST handlers in 4.x didn't use to allow sharing. That changed in 6.x or so. JB INTR_EXCL or some such and/or uart doesn't set RF_SHAREABLE when JB allocating the IRQ. It is probably the latter. You could try just JB adding RF_SHAREABLE to the bus_alloc_resource_any() for the IRQ to JB uart and see if that fixes it. sc-sc_ires = bus_alloc_resource_any(dev, SYS_RES_IRQ, sc-sc_irid, RF_ACTIVE | RF_SHAREABLE); It is here. Ok, then you need to figure out what is actually failing to install an interrupt handler (e.g. does bus_alloc_resource or bus_setup_intr fail?) -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
Hello, John. You wrote 10 апреля 2013 г., 18:20:34: JB Ok, then you need to figure out what is actually failing to install an JB interrupt handler (e.g. does bus_alloc_resource or bus_setup_intr fail?) uart.ko could not be used, and rebuilding system for this system takes time (a lot of it). I have idea to fix uart.ko as module before to be able to load-unload it multiple time for experiments. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
On 04/07/13 12:43, Lev Serebryakov wrote: How could I debug this? Does this board have any fancy BIOS - RS232 redirection? Could something like that cause these symptoms? Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
On Sunday, April 07, 2013 5:46:34 pm Adrian Chadd wrote: On 7 April 2013 13:15, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message 1428566376.20130407234...@serebryakov.spb.ru, Lev Serebryakov writ es: It doesn't look so. And uart1 and uart3 doesn't have interrupt according to `vmstat -i' (but share irq4 according to boot messages). Ohh, there you go... Interrupt sharing on ISA requires special magic... .. did we really break shared interrupt handling on ISA? When did it ever work? God, you made me remember ISA interrupt sharing. I thought the main source of evilness is edge shared interrupts? Right, and ISA are edge and active-hi, so generally not shareable. Lev, Can you assign different interrupts via the BIOS somehow? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
Hello, John. You wrote 10 апреля 2013 г., 0:08:09: .. did we really break shared interrupt handling on ISA? JB When did it ever work? sio has special hacks to make it work, and in my experience, it worked around FreeBSD 4 (or even 3? I've started with 2.2.2, but it was later), when I had some systems with multiple internal ISA modems (does anybody remember word FIDO here?) God, you made me remember ISA interrupt sharing. I thought the main source of evilness is edge shared interrupts? JB Right, and ISA are edge and active-hi, so generally not shareable. As far as I remember, it is changeable. But I could be wrong here. JB Can you assign different interrupts via the BIOS somehow? I'll try. I could disable uart2 and 3 for sure, and then uart0 and uart1 will have unique standard (4 and 3) IRQ. I'll try it tomorrow. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
Hello, John. You wrote 10 апреля 2013 г., 0:08:09: JB When did it ever work? Problem is, that every uart device now is independent from each other in good OOP style, and it looks like interrupt sharing we need one interrupt handler per irq (not per device), which will now about several UARTs. Something like multiport device, bot not exactly. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
In message 105818341.20130410004...@serebryakov.spb.ru, Lev Serebryakov write s: JB When did it ever work? Problem is, that every uart device now is independent from each other in good OOP style, and it looks like interrupt sharing we need one interrupt handler per irq (not per device), which will now about several UARTs. Something like multiport device, bot not exactly. That is what the puc(4) driver does... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
On Tuesday, April 09, 2013 4:44:51 pm Lev Serebryakov wrote: Hello, John. You wrote 10 апреля 2013 г., 0:08:09: JB When did it ever work? Problem is, that every uart device now is independent from each other in good OOP style, and it looks like interrupt sharing we need one interrupt handler per irq (not per device), which will now about several UARTs. Something like multiport device, bot not exactly. No, the interrupt code itself will handle shared interrupts (it will call all handlers). I think in practice that uart is setting INTR_EXCL or some such and/or uart doesn't set RF_SHAREABLE when allocating the IRQ. It is probably the latter. You could try just adding RF_SHAREABLE to the bus_alloc_resource_any() for the IRQ to uart and see if that fixes it. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
Hello, Poul-Henning. You wrote 8 апреля 2013 г., 0:15:01: It doesn't look so. And uart1 and uart3 doesn't have interrupt according to `vmstat -i' (but share irq4 according to boot messages). PHK Ohh, there you go... I'll try to turn off uart2 and uart3 in BIOS and give different IRQs to uart0 and uart1. Fortunately, I don't need ALL of them. PHK Interrupt sharing on ISA requires special magic... But it will be nice to fix this, and I could provide any informaton and debugging I can, but I need to know hwere to start. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
In message 229402991.20130407172...@serebryakov.spb.ru, Lev Serebryakov write s: I've built new router based on Intel D2500CC motherboard. I have similar problems, and have not found any solution, but havn't tried particularly hard either. Try running the uarts in polled mode, to find out if it's an IRQ issue ? The VGA is also funky, you cannot do 32bit writes to display memory (I committed a fix for that already) Otherwise it's a nice mobo -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
Hello, Poul-Henning. You wrote 7 апреля 2013 г., 19:36:09: I've built new router based on Intel D2500CC motherboard. PHK I have similar problems, and have not found any solution, but havn't PHK tried particularly hard either. PHK Try running the uarts in polled mode, to find out if it's an IRQ PHK issue ? It looks like so. BIOS mentions IRQ for each UART, but vmstat -i shows only irq3 for uart0 and uart2 but no irq4 for uart1 and uart3 (dmesg and BIOS says about irq4 for them). Maybe, device.hints helps? I'll try it. It looks like uart(4) can not communicate well with ACPI. How to switch polled mode? man uart(4) doesn't mention poll at all. PHK The VGA is also funky, you cannot do 32bit writes to display PHK memory (I committed a fix for that already) Fortunately, I don't need VGA after first installation :) But serial console will be nice. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
I think if you configure no irq at all, it will automatically go to polled mode. Not sure if uart(4) can actually do that, sio(4) could. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
On 7 April 2013 10:35, Poul-Henning Kamp p...@phk.freebsd.dk wrote: I think if you configure no irq at all, it will automatically go to polled mode. Not sure if uart(4) can actually do that, sio(4) could. Yup, it does. No IRQ hint == polled mode. It'll say as much in the dmesg. Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
Hello, Adrian. You wrote 7 апреля 2013 г., 21:42:32: I think if you configure no irq at all, it will automatically go to polled mode. Not sure if uart(4) can actually do that, sio(4) could. AC Yup, it does. No IRQ hint == polled mode. It'll say as much in the dmesg. It looks like it picks up IRQ hint from ACPI, and, according to dmesg, it does so correctly, but after that it doesn't work :( -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
In message 962552272.20130407232...@serebryakov.spb.ru, Lev Serebryakov write s: It looks like it picks up IRQ hint from ACPI, and, according to dmesg, it does so correctly, but after that it doesn't work :( So does the interrupt actually arrive ? If not: Interrupt routing issue ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
Hello, Poul-Henning. You wrote 7 апреля 2013 г., 23:31:50: It looks like it picks up IRQ hint from ACPI, and, according to dmesg, it does so correctly, but after that it doesn't work :( PHK So does the interrupt actually arrive ? vmstat -i interrupt total rate irq3: uart0 uart2 1 0 It doesn't look so. And uart1 and uart3 doesn't have interrupt according to `vmstat -i' (but share irq4 according to boot messages). PHK If not: Interrupt routing issue ? How could I debug this? -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
In message 1428566376.20130407234...@serebryakov.spb.ru, Lev Serebryakov writ es: It doesn't look so. And uart1 and uart3 doesn't have interrupt according to `vmstat -i' (but share irq4 according to boot messages). Ohh, there you go... Interrupt sharing on ISA requires special magic... With sio(4) one could hardcode interrupt sharing with hints.flags, but with uart(4) I think you have to go through puc(4) to do it. Not sure how that that should work in a case like this... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel D2500CC motherboard and strange RS232/UART behavior
On 7 April 2013 13:15, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message 1428566376.20130407234...@serebryakov.spb.ru, Lev Serebryakov writ es: It doesn't look so. And uart1 and uart3 doesn't have interrupt according to `vmstat -i' (but share irq4 according to boot messages). Ohh, there you go... Interrupt sharing on ISA requires special magic... .. did we really break shared interrupt handling on ISA? With sio(4) one could hardcode interrupt sharing with hints.flags, but with uart(4) I think you have to go through puc(4) to do it. What were the hints? It's possible you can still drop the hint somewhere and it'll get picked up even if acpi is providing the io/irq resources. Not sure how that that should work in a case like this... God, you made me remember ISA interrupt sharing. I thought the main source of evilness is edge shared interrupts? (Level shared interrupts should be the same no matter what bus they're on..) Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
