login
Search
Hello all,
I've just installed a multiport serial card released by an outfit called
Syba. This is an 8 port serial-only card with an Octopus style breakout
cable. The main chipset on it is an ITE IT8871F.I've got two questions on this: Is there a driver I should try force
loading on it (and if so, what options to use)? and is there any useful
testing I can do to report back to the LKML on this card?Thanks for your time, diagnostic output follows.
-- ChrisThe following comes up from an "lspci -vv"
01:06.0 Serial controller: PLX Technology, Inc. Unknown device 9016 (rev
01) (prog-if 02 [16550])
Subsystem: Unknown device 544e:0008
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 16
Region 0: I/O ports at a000 [size=64]
Region 1: I/O ports at a400 [size=16]
Region 2: I/O ports at a800 [size=16]
Region 3: Memory at f5000000 (32-bit, non-prefetchable) [size=4K]
Region 4: Memory at f5001000 (32-bit, non-prefetchable) [size=4K]
Region 5: Memory at f5002000 (32-bit, non-prefetchable) [size=4K]and "lshw" outputs:
*-communication UNCLAIMED
description: Serial controller
product: PLX Technology, Inc.
vendor: PLX Technology, Inc.
physical id: 6
bus info: pci@0000:01:06.0
version: 01
width: 32 bits
clock: 33MHz
capabilities: 16550
configuration: latency=0-
Are you sure ? IIRC IT887x are PCI-ISA bridges with additional periphery
and your lspci shows PLX chip. Can you send complete lspci -vv output ?--=20
Andrey Panin | Linux and UNIX system administrator
pazke@donpac.ru | PGP key: wwwkeys.pgp.net
I'm sure that's what it says on the largest chip on the PCI card. It
could be that the other two chips are more relevant... the numbers from
them are included below.I've posted up a quick text only page with the diagnostic information
from the system (full dmesg, lspci, etc) plus links to pictures of the
board (since others might see something important that I'm not aware
of). You can access that at
http://pcburn.com/files/Syba_serial_controller/index.htmlOne chip has "ITE IT8871F 0641-AYS ZF1M04L" written on it, and the other
two have a stylized celtic knot looking "T" followed by "TG16C554CJG
FTA6M-001 0620-B".
-
--aM3YZ0Iwxop3KEKx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printableCan you try an attached patch ? I hope it should at least detect UARTs on=
=20
your board. Be ready that baudrate could be wrong, because we do not know--=20
Andrey Panin | Linux and UNIX system administrator
pazke@donpac.ru | PGP key: wwwkeys.pgp.net--aM3YZ0Iwxop3KEKx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=patch-syba
Content-Transfer-Encoding: quoted-printablediff -urdpNX /usr/share/dontdiff linux-2.6.23.vanilla/drivers/serial/8250_p=
ci.c linux-2.6.23/drivers/serial/8250_pci.c
--- linux-2.6.23.vanilla/drivers/serial/8250_pci.c 2007-10-12 14:20:44.0000=
00000 +0400
+++ linux-2.6.23/drivers/serial/8250_pci.c 2007-10-12 14:07:08.000000000 +0=
400
@@ -1036,6 +1036,7 @@ enum pci_board_num_t {
pbn_b0_2_115200,
pbn_b0_4_115200,
pbn_b0_5_115200,
+ pbn_b0_8_115200,
=20
pbn_b0_1_921600,
pbn_b0_2_921600,
@@ -1172,6 +1173,12 @@ static struct pciserial_board pci_boards
.base_baud =3D 115200,
.uart_offset =3D 8,
},
+ [pbn_b0_8_115200] =3D {
+ .flags =3D FL_BASE0,
+ .num_ports =3D 8,
+ .base_baud =3D 115200,
+ .uart_offset =3D 8,
+ },
=20
[pbn_b0_1_921600] =3D {
.flags =3D FL_BASE0,
@@ -2520,6 +2527,11 @@ static struct pci_device_id serial_pci_t
PCI_ANY_ID, PCI_ANY_ID, 0, 0,
pbn_b3_8_115200 },
=20
+ /* Syba PCI8871-PR8 8-port serial card */
+ { PCI_VENDOR_ID_PLX, 0x9016,
+ 0x544e, 0x0008, 0, 0,
+ pbn_b0_8_115200 },
+
/*
* Exar Corp. XR17C15[248] Dual/Quad/Octal UART
*/--aM3YZ0Iwxop3KEKx--
Alright,finally had another machine to try the attached patch. I get an
odd error regarding IRQ 17:"irq 17: nobody cared (try booting with the "irqpoll" option)"
along with a long error message (but the kernel continues to load).
Aside from that the ports now allow me to run a getty on them and the
DTR line lights up on my serial tester (as it does with a working port)
but the device on the other end doesn't function.I've updated the web page with lspci -vv and dmesg output. I can also
post it here if that's desirable, just figured I'd save everyone the
inbox flooding :).-- Chris
-
This message apearred after firewire driver initialization and firewire chip
Is it possible to connect two ports and run getty on one port and minicom on
--=20
Andrey Panin | Linux and UNIX system administrator
pazke@donpac.ru | PGP key: wwwkeys.pgp.net
I used the on-board serial port as a known working control (after
getting it to work with the other onboard serial port) to try and
connect over to one of the Syba card ports (using Cutecom & getty). The
lines light up, but there's nothing getting sent from the 8-port as far
as I can see. The onboard port works as I'd expect, the Syba (running
getty identically from inittab) doesn't.-- Chris
-
Oh crap... I missed this fscking "Disabling IRQ #17" line in your dmesg.
Can you try with firewire controller disabled somehow ?--=20
Andrey Panin | Linux and UNIX system administrator
pazke@donpac.ru | PGP key: wwwkeys.pgp.net
Ah, I forgot to make note of that. I did actually turn off Firewire in
the BIOS. Assuming that worked (and it looks like it did) the following
section probably contains the relevant bits. Still getting the IRQ 17
error.-- Chris
PCI: Setting latency timer of device 0000:00:05.0 to 64
NET: Registered protocol family 17
eth0: no IPv6 routers present
irq 17: nobody cared (try booting with the "irqpoll" option)
[<c0104f45>] show_trace_log_lvl+0x1a/0x2f
[<c0105939>] show_trace+0x12/0x14
[<c0105951>] dump_stack+0x16/0x18
[<c0152f90>] __report_bad_irq+0x39/0x79
[<c01531af>] note_interrupt+0x1df/0x218
[<c0153754>] handle_fasteoi_irq+0x91/0xb6
[<c0105fef>] do_IRQ+0x7c/0x95
[<c0104946>] common_interrupt+0x2e/0x34
[<c010233a>] cpu_idle+0x1c/0xc2
[<c02deed9>] rest_init+0x4d/0x4f
[<c03e7979>] start_kernel+0x32a/0x332
[<00000000>] 0x0
=======================
handlers:
[<c023ecae>] (serial8250_interrupt+0x0/0x115)
Disabling IRQ #17
hda: DMA timeout retryfull dmesg output at
http://pcburn.com/files/Syba_serial_controller/dmesg_with_1394_disabled.txt
-
xt
So the card probably generates screaming interrupt... that's bad.
I found some docs for IT887x chips, according to these docs IT887x
have simple interrupt controller inside. Further investigation is needed.Can you post output of lspci -xxx ?
--=20
Andrey Panin | Linux and UNIX system administrator
pazke@donpac.ru | PGP key: wwwkeys.pgp.net
Full output at
http://pcburn.com/files/Syba_serial_controller/lspci_xxx.out. The
relevant part for the Syba card is probably:01:08.0 Serial controller: PLX Technology, Inc. Unknown device 9016 (rev 01)
00: b5 10 16 90 07 00 80 02 01 02 00 07 00 00 00 00
10: 01 a4 00 00 01 a8 00 00 01 ac 00 00 00 00 00 f5
20: 00 10 00 f5 00 20 00 f5 00 00 00 00 4e 54 08 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 05 01 00 00
40: 3f 3f 08 00 00 8c 20 8b 45 54 55 45 00 00 10 d2
50: 01 01 71 03 01 03 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 03 00 06 f8 03 f8 02
80: 78 03 78 07 00 08 00 07 00 01 20 01 40 01 60 01
90: 00 00 00 00 00 00 00 00 00 00 00 00 70 43 25 64
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00-- Chris
-
--CE+1k2dSO48ffgeK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printableCan you test an attached patch against 2.6.24-rc1 ?
--=20
Andrey Panin | Linux and UNIX system administrator
pazke@donpac.ru | PGP key: wwwkeys.pgp.net--CE+1k2dSO48ffgeK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=patch-syba-2
Content-Transfer-Encoding: quoted-printablediff -urdpNX dontdiff linux-2.6.24.vanilla/drivers/serial/8250_pci.c linux-=
2.6.24/drivers/serial/8250_pci.c
--- linux-2.6.24.vanilla/drivers/serial/8250_pci.c 2007-10-28 13:00:14.0000=
00000 +0300
+++ linux-2.6.24/drivers/serial/8250_pci.c 2007-10-28 18:15:12.000000000 +0=
300
@@ -610,45 +610,49 @@ static int pci_netmos_init(struct pci_de
/* enable IO_Space bit */
#define ITE_887x_POSIO_ENABLE (1 << 31)
=20
-static int pci_ite887x_init(struct pci_dev *dev)
+static int pci_ite_887x_allocate_io(struct pci_dev *dev)
{
- /* inta_addr are the configuration addresses of the ITE */
- static const short inta_addr[] =3D { 0x2a0, 0x2c0, 0x220, 0x240, 0x1e0,
- 0x200, 0x280, 0 };
- int ret, i, type;
- struct resource *iobase =3D NULL;
- u32 miscr, uartbar, ioport;
+ static const short inta_addr[] =3D {
+ 0x2a0, 0x2c0, 0x220, 0x240, 0x1e0, 0x200, 0x280, 0
+ };
+ int ret, i;
=20
- /* search for the base-ioport */
- i =3D 0;
- while (inta_addr[i] && iobase =3D=3D NULL) {
- iobase =3D request_region(inta_addr[i], ITE_887x_IOSIZE,
- "ite887x");
- if (iobase !=3D NULL) {
+ for (i =3D 0; i < ARRAY_SIZE(inta_addr); i++) {
+ int iobase =3D inta_addr[i];
+
+ if (request_region(iobase, ITE_887x_IOSIZE, "ite887x")) {
/* write POSIO0R - speed | size | ioport */
pci_write_config_dword(dev, ITE_887x_POSIO0,
ITE_887x_POSIO_ENABLE | ITE_887x_POSIO_SPEED |
- ITE_887x_POSIO_IOSIZE_32 | inta_addr[i]);
+ ITE_887x_POSIO_IOSIZE_32 | iobase);
+
/* write INTCBAR - ioport */
- pci_...
Can you point me to any of those IT887x docs? I haven't been able
I tested basically the same patch against a current upstream tree,
and the syba ports don't work, even with "irqpoll". Here's the
discovery:Serial: 8250/16550 driver16 ports, IRQ sharing enabled
<FF>serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
pnp: the driver 'serial' has been registered
00:10: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial 00:10: driver attached
00:11: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
serial 00:11: driver attached
serial 0000:00:01.0: check 0x2a0
serial 0000:00:01.0: got 0x0
serial 0000:00:01.0: syba at 0x000002a0
serial 0000:00:01.0: ite887x: io base at 0x2a0
serial 0000:00:01.0: ite887x: IRR0=00 IMR0=00 IER0=00
serial 0000:00:01.0: ite887x: IRR1=00 IMR1=00 IER1=00
serial 0000:00:01.0: ite887x: IRR2=00 IMR2=00 IER2=00
0000:00:01.0: ttyS4 at I/O 0x1000 (irq = 16) is a 16550A
0000:00:01.0: ttyS5 at I/O 0x1008 (irq = 16) is a 16550A
0000:00:01.0: ttyS6 at I/O 0x1010 (irq = 16) is a 16550A
0000:00:01.0: ttyS7 at I/O 0x1018 (irq = 16) is a 16550A
0000:00:01.0: ttyS8 at I/O 0x1020 (irq = 16) is a 16550A
0000:00:01.0: ttyS9 at I/O 0x1028 (irq = 16) is a 16550A
0000:00:01.0: ttyS10 at I/O 0x1030 (irq = 16) is a 16550A
0000:00:01.0: ttyS11 at I/O 0x1038 (irq = 16) is a 16550AThe entire dmesg log is at http://helgaas.com/tmp/sybase.txt
The patch I tested is at http://helgaas.com/tmp/sybase.patchHere's the "lspci -xxx" output:
00:01.0 Serial controller: PLX Technology, Inc. Unknown device 9016 (rev 01)
00: b5 10 16 90 03 01 80 02 01 02 00 07 00 00 00 00
10: 01 10 00 00 d1 10 00 00 c1 10 00 00 00 30 24 e8
20: 00 20 24 e8 00 10 24 e8 00 00 00 00 4e 54 08 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 01 00 00
40: 3f 3f 08 00 00 8c 20 8b 45 54 55 45 00 00 10 d2
50: 01 01 71 03 01 03 00 00 00 00 00 00 00 00 00 00
60: a0 02 00 e5 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 a0 02 00 00 f8 03 f8 02
...
Here's a 2.6.27-rc3 patch that works for me.
I only have one card, so I can't test this with multiple cards.
I don't know whether there's any way the INTC_GPIO base addresses
would get programmed to non-conflicting values. My card comes
up with the INTC_GPIO area at I/O ports 0x0300-0x031f, but that
might be a default that's just hardwired into the card.It looks like we could allocate this region when we claim the
device, which should let us support multiple cards, but I haven't
tried this.If anybody tries this out, let me know how it works.
Bjorn
diff --git a/drivers/serial/8250_pci.c b/drivers/serial/8250_pci.c
index c2f2393..d442ddb 100644
--- a/drivers/serial/8250_pci.c
+++ b/drivers/serial/8250_pci.c
@@ -737,6 +737,55 @@ static void __devexit pci_ite887x_exit(struct pci_dev *dev)
release_region(ioport, ITE_887x_IOSIZE);
}+#define ITE_887x_IRR0 0
+#define ITE_887x_IRR1 1
+#define ITE_887x_IRR2 2
+#define ITE_887x_IMR0 4
+#define ITE_887x_IMR1 5
+#define ITE_887x_IMR2 6
+#define ITE_887x_IER0 8
+#define ITE_887x_IER1 9
+#define ITE_887x_IER2 10
+#define ITE_887x_ITR0 12
+#define ITE_887x_ITR1 13
+#define ITE_887x_ITR2 14
+
+static int pci_syba_ite887x_init(struct pci_dev *dev)
+{
+ u32 ddma_intc_base, intc_base;
+ struct resource *iobase;
+
+ pci_read_config_dword(dev, ITE_887x_INTCBAR, &ddma_intc_base);
+ intc_base = ddma_intc_base & 0xffff;
+
+ iobase = request_region(intc_base, ITE_887x_IOSIZE, "ite887x");
+ if (!iobase) {
+ dev_err(&dev->dev, "can't request INTC_Base at 0x%x\n",
+ intc_base);
+ return -ENODEV;
+ }
+
+ outb(0x00, intc_base + ITE_887x_IMR0); /* mask external IRQ 0-7 */
+ outb(0xff, intc_base + ITE_887x_IMR1); /* mask external IRQ 8-15 */
+ outb(0xff, intc_base + ITE_887x_IMR2); /* mask internal interrupts */
+
+ outb(0xff, intc_base + ITE_887x_IER0); /* IRQ 0-7 level-triggered */
+ outb(0x00, intc_base + ITE_887x_IER1); /* IRQ 8-15 edge (unused) */
+ outb(0x00, intc_base + ITE_887x_IER2);...
Is it possible they put a chip on to generate a PCI interrupt on perhaps
PCIB on the slot from the serial chips directly, so that they didn't
have to turn interrupts from the serial chips into a signal that forces
the parallel port to generate an interrupt? After all that would reduce
latency, and if you use PCIA for the parallel port, PCIB for the first
serial chip and PCIC for the second, you might get a much more efficient
design, although the driver would have to register all those IRQs.What IRQ is each PCI device in that system using right now? perhaps we
could figure out what irq 17 would be on that PCI slot.--
Len Sorensen
-
I dont think so. IT887x has builtin interrupt controller which multiplexes=
=20
16 external IRQ pins with IRQs from builtin devices (parallel port, UARTs
and GPIO) into single INTA# line. IT887x also contains 8-bit ISA-like bus
and 16 chip select lines and it's all you need to glue UARTs to PCI bus.I suspect that it's interrupt controller problem, probably edge/level
--=20
Andrey Panin | Linux and UNIX system administrator
pazke@donpac.ru | PGP key: wwwkeys.pgp.net
Well TG16C554 sounds awfully similar to 16550 which is a common UART
type. Perhaps 554 indicates it is 4 16550s in one chip. There are two
of those chips in one of the pictures.Here is a data sheet for it:
http://www.twistsemi.com/downloads/TG16C554V1.5.pdfIt is in fact a quad UART chip. It appears to have 4 chip select lines
to pick between the 4 UARTS, 3 address lines to access the 8 16550
registers, and 8 data lines to read and write those registers as well as
a pair of read and write enable lines. They are NOT PCI chips, so quite
likely the IT8871 is there as a PCI to parallel convertor and then the
parallel interface connects to the UARTs. No idea where the IRQ line
from the chips would connect to (one of the parallel port signals that
generates an IRQ?)The 8 small chips are probably RS232 level convertors.
The 8871 is a single PCI parallel port, so certainly somehow they are
controlling the two serial to parallel chips through that pci parallel
port.I included the diff of the files you had on your web page and the
originals founds in 2.4.20 (which is what they claim they replace).I can't really tell if there is any code there to deal with their quad
uart chip or not.--- drivers/char/serial.c 2002-11-28 18:53:12.000000000 -0500
+++ /tmp/serial_20.c 2006-11-23 03:17:24.000000000 -0500
@@ -257,6 +257,13 @@static struct timer_list serial_timer;
+//struct pci_dev *pcidev = NULL;
+// ITE8872 ITE8872
+u32 ITE8872_INTC[8];
+int ITEBOARDNUMBER=0;
+u8 ITE8872_IRQ[8];
+
+
/* serial subtype definitions */
#ifndef SERIAL_TYPE_NORMAL
#define SERIAL_TYPE_NORMAL 1
@@ -4165,6 +4172,163 @@
}
EXPORT_SYMBOL(pci_siig20x_fn);+void ite8872_requestirq(int irq,void *dev_id,struct pt_regs *regs){
+ u8 itmp;
+ int i=0;
+ /* measure which INTC went to control */
+ for(i=0;i<8;i++)
+ if(irq == ITE8872_IRQ[i])
+ {
+ /* clean ITE8872 interrupt */
+ itmp = inb(ITE8872_INTC[i]+2);
+ if(itmp & 0x0f)
+ {
+ outb(itmp,ITE8872_INTC[i]+2);
+ b...
I'll see if I can compile up the appropriate kernel and test it with
that code to see if it includes something to drive the card then, for
starters.-- Chris
-
Well 8250_pci.c mentions IT8871, so it is probably 8250 style in
How many serial ports is your kernel configured to use?
CONFIG_SERIAL_8250_NR_UARTS=16
CONFIG_SERIAL_8250_RUNTIME_UARTS=4That is from my Debian system's kernel, and it won't activate more than
4 ports automatically. It will allow up to 16 to be activated though.
I don't remember what the boot command is to override those values to
make the system look for more ports.--
Len Sorensen
-
That's what I had thought too after a quick LKML search. Doing a bit
more research (I'm starting to think the IT8871F on the chip is
misleading) it looks like that support is for a single parallel multi
The kernel I'm using has 16 for both the NR_UARTS and RUNTIME_UARTS
(these machines generally have a minimum of 4 ports). dmesg doesn't
show the kernel as recognizing the card and only ttyS0 and ttyS1 (the
two onboard ports) show up on boot.-- Chris
-
Try echo -n "10b5 9016" > /sys/bus/pci/drivers/serial/new_id and let
Russell King (rmk+serial@arm.linux.org.uk) know if it works (or if it
doesn't, for that matter).--
Nicholas Miell <nmiell@comcast.net>-
| Greg Kroah-Hartman | [PATCH 004/196] Chinese: add translation of SubmittingPatches |
| David Chinner | Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md. |
| Andrew Morton | -mm merge plans for 2.6.23 |
| Trent Piepho | Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code |
git: | |
| David Miller | Re: iptables very slow after commit784544739a25c30637397ace5489eeb6e15d7d49 |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
