stallion driver dmesg notice

stallion driver dmesg notice

[Ingo Korb]

Hi!

The stallion driver in 2.6.21.3 put this little notice in my dmesg:

=== Cut ===
Stallion Multiport Serial Driver: version 5.6.0
stallion 0000:00:0b.0: please, report this to LKML: 100b/d001/ffffff
ACPI: PCI Interrupt 0000:00:0b.0[A] -> GSI 19 (level, low) -> IRQ 17
stallion: probe of 0000:00:0b.0 failed with error -16
=== Cut ===

The card is a EC8/32-PCI with a single connected panel. It used to work 
well with 2.4, mostly well with a patched 2.6.8.1, really bad 
(unstable, lost characters) with 2.6.11(?) and doesn't work at all with 
2.6.21.3.

Should I test it with an EC8/64-PCI? The /32 (ab)uses an IDE controller 
chip as PCI interface, the /64 uses a PLX PCI9050.

lspci -vv for the EC8/32:
=== Cut ===
00:0b.0 Class ffff: National Semiconductor Corporation 87410 IDE (rev 
ff) (prog-if ff)
	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 17
	Region 0: I/O ports at d100 [size=8]
	Region 1: I/O ports at d200 [size=4]
	Region 2: I/O ports at d300 [size=8]
	Region 3: I/O ports at d400 [size=4]
=== Cut ===


-ik

Re: stallion driver dmesg notice

[Jiri Slaby]

Ingo Korb napsal(a):
> Hi!
> 
> The stallion driver in 2.6.21.3 put this little notice in my dmesg:
> 
> === Cut ===
> Stallion Multiport Serial Driver: version 5.6.0
> stallion 0000:00:0b.0: please, report this to LKML: 100b/d001/ffffff
> ACPI: PCI Interrupt 0000:00:0b.0[A] -> GSI 19 (level, low) -> IRQ 17
> stallion: probe of 0000:00:0b.0 failed with error -16
> === Cut ===
> 
> The card is a EC8/32-PCI with a single connected panel. It used to work 
> well with 2.4, mostly well with a patched 2.6.8.1, really bad 
> (unstable, lost characters) with 2.6.11(?) and doesn't work at all with 
> 2.6.21.3.
> 
> Should I test it with an EC8/64-PCI? The /32 (ab)uses an IDE controller 
> chip as PCI interface, the /64 uses a PLX PCI9050.
> 
> lspci -vv for the EC8/32:
> === Cut ===
> 00:0b.0 Class ffff: National Semiconductor Corporation 87410 IDE (rev 
> ff) (prog-if ff)
> 	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 17
> 	Region 0: I/O ports at d100 [size=8]
> 	Region 1: I/O ports at d200 [size=4]
> 	Region 2: I/O ports at d300 [size=8]
> 	Region 3: I/O ports at d400 [size=4]
> === Cut ===

Thanks. I will look into it,
-- 
http://www.fi.muni.cz/~xslaby/            Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

[PATCH 1/1] Char: stallion, don't fail with less than max panels, Re: stallion driver dmesg notice

[Jiri Slaby]

Ingo Korb wrote:
> Stallion Multiport Serial Driver: version 5.6.0
> stallion 0000:00:0b.0: please, report this to LKML: 100b/d001/ffffff
> ACPI: PCI Interrupt 0000:00:0b.0[A] -> GSI 19 (level, low) -> IRQ 17
> stallion: probe of 0000:00:0b.0 failed with error -16
> === Cut ===
>
> The card is a EC8/32-PCI with a single connected panel. It used to work 
> well with 2.4, mostly well with a patched 2.6.8.1, really bad 
> (unstable, lost characters) with 2.6.11(?) and doesn't work at all with 
> 2.6.21.3.

Hmm, breakage in 2.6.11 is interesting, I'll try to dig through logs, what
could happen.

> Should I test it with an EC8/64-PCI? The /32 (ab)uses an IDE controller 
> chip as PCI interface, the /64 uses a PLX PCI9050.

I don't undestand this. IDE grabs the device? This is possible and if yes,
I'll fix the IDE driver.

Could you please try the patch below?

--
stallion, don't fail with less than max panels

Signed-off-by: Jiri Slaby <jirislaby@gmail.com>

---
commit a6c3fb453e98ba32291a4fc5a7d843fb27359182
tree d28d09d3fa53b7af465c7b4cc88c295459c96276
parent 8785a2ca27122a0a46119fc57e7667bf9c916df4
author Jiri Slaby <jirislaby@gmail.com> Mon, 04 Jun 2007 00:05:16 +0200
committer Jiri Slaby <jirislaby@gmail.com> Mon, 04 Jun 2007 00:07:32 +0200

 drivers/char/stallion.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/char/stallion.c b/drivers/char/stallion.c
index 05f492d..9820f49 100644
--- a/drivers/char/stallion.c
+++ b/drivers/char/stallion.c
@@ -2172,7 +2172,7 @@ static int __devinit stl_initech(struct stlbrd *brdp)
 		}
 		status = inb(ioaddr + ECH_PNLSTATUS);
 		if ((status & ECH_PNLIDMASK) != nxtid)
-			goto err_fr;
+			break;
 		panelp = kzalloc(sizeof(struct stlpanel), GFP_KERNEL);
 		if (!panelp) {
 			printk("STALLION: failed to allocate memory "

Re: stallion driver dmesg notice

[Jiri Slaby]

Ingo Korb wrote:
> > > Should I test it with an EC8/64-PCI? The /32 (ab)uses an IDE controller 
> > > chip as PCI interface, the /64 uses a PLX PCI9050.
> > 
> > I don't undestand this. IDE grabs the device? This is possible and if yes,
> > I'll fix the IDE driver.
> 
> Yes, IDE (specifically: generic IDE PCI support, generic.ko - not 
> compiled into my kernel) can grab the device. It's using an IDE 
> controller chip that reports itself as such, so that's not completely 
> unreasonable.

Good, thanks for the info.

> > Could you please try the patch below?
> 
> Oopsed:
> 
> === Cut ===
> Unloading Stallion Multiport Serial Driver: version 5.6.0
> Stallion Multiport Serial Driver: version 5.6.0
> stallion 0000:00:0b.0: please, report this to LKML: 100b/d001/ffffff
> STALLION: EC8/32-PCI found, board=0 io=d200 irq=17 nrpanels=1 nrports=8
> BUG: unable to handle kernel NULL pointer dereference at virtual address 
> 00000074

Okay, tty alloc after pci init, attached patch should fix it. Could you
retest?

> > stallion, don't fail with less than max panels
> 
> I could try with more than one panel if neccecary - I think I have four 8-
> Port-Panels, one 8-Port-XP-Panel (different UART) and one 16-Port-Panel 
> stored somewhere.

Doesn't matter, needs fix anyway.

--

stallion, alloc tty before pci devices init

this causes oops, because pci prboe function calls tty_register_device for
each device found.

Signed-off-by: Jiri Slaby <jirislaby@gmail.com>

---
commit f6d5d1877b0f7ac82f5e1fec2ead0429eeb069c8
tree 31beaaee84ef718acc5401b3cb07a7f2e340f0fe
parent a6c3fb453e98ba32291a4fc5a7d843fb27359182
author Jiri Slaby <jirislaby@gmail.com> Mon, 04 Jun 2007 10:39:41 +0200
committer Jiri Slaby <jirislaby@gmail.com> Mon, 04 Jun 2007 10:39:41 +0200

 drivers/char/stallion.c |   73 ++++++++++++++++++++++-------------------------
 1 files changed, 34 insertions(+), 39 deletions(-)

diff --git a/drivers/char/stallion.c b/drivers/char/stallion.c
index 9820f49..45bf2a2 100644
--- a/drivers/char/stallion.c
+++ b/drivers/char/stallion.c
@@ -4714,6 +4714,29 @@ static int __init stallion_module_init(void)
 	spin_lock_init(&stallion_lock);
 	spin_lock_init(&brd_lock);
 
+	stl_serial = alloc_tty_driver(STL_MAXBRDS * STL_MAXPORTS);
+	if (!stl_serial) {
+		retval = -ENOMEM;
+		goto err;
+	}
+
+	stl_serial->owner = THIS_MODULE;
+	stl_serial->driver_name = stl_drvname;
+	stl_serial->name = "ttyE";
+	stl_serial->major = STL_SERIALMAJOR;
+	stl_serial->minor_start = 0;
+	stl_serial->type = TTY_DRIVER_TYPE_SERIAL;
+	stl_serial->subtype = SERIAL_TYPE_NORMAL;
+	stl_serial->init_termios = stl_deftermios;
+	stl_serial->flags = TTY_DRIVER_REAL_RAW | TTY_DRIVER_DYNAMIC_DEV;
+	tty_set_operations(stl_serial, &stl_ops);
+
+	retval = tty_register_driver(stl_serial);
+	if (retval) {
+		printk("STALLION: failed to register serial driver\n");
+		goto err_frtty;
+	}
+
 /*
  *	Find any dynamically supported boards. That is via module load
  *	line options.
@@ -4743,13 +4766,9 @@ static int __init stallion_module_init(void)
 
 	/* this has to be _after_ isa finding because of locking */
 	retval = pci_register_driver(&stl_pcidriver);
-	if (retval && stl_nrbrds == 0)
-		goto err;
-
-	stl_serial = alloc_tty_driver(STL_MAXBRDS * STL_MAXPORTS);
-	if (!stl_serial) {
-		retval = -ENOMEM;
-		goto err_pcidr;
+	if (retval && stl_nrbrds == 0) {
+		printk(KERN_ERR "STALLION: can't register pci driver\n");
+		goto err_unrtty;
 	}
 
 /*
@@ -4760,43 +4779,18 @@ static int __init stallion_module_init(void)
 		printk("STALLION: failed to register serial board device\n");
 
 	stallion_class = class_create(THIS_MODULE, "staliomem");
-	if (IS_ERR(stallion_class)) {
-		retval = PTR_ERR(stallion_class);
-		goto err_reg;
-	}
+	if (IS_ERR(stallion_class))
+		printk("STALLION: failed to create class\n");
 	for (i = 0; i < 4; i++)
 		class_device_create(stallion_class, NULL,
 				    MKDEV(STL_SIOMEMMAJOR, i), NULL,
 				    "staliomem%d", i);
 
-	stl_serial->owner = THIS_MODULE;
-	stl_serial->driver_name = stl_drvname;
-	stl_serial->name = "ttyE";
-	stl_serial->major = STL_SERIALMAJOR;
-	stl_serial->minor_start = 0;
-	stl_serial->type = TTY_DRIVER_TYPE_SERIAL;
-	stl_serial->subtype = SERIAL_TYPE_NORMAL;
-	stl_serial->init_termios = stl_deftermios;
-	stl_serial->flags = TTY_DRIVER_REAL_RAW | TTY_DRIVER_DYNAMIC_DEV;
-	tty_set_operations(stl_serial, &stl_ops);
-
-	retval = tty_register_driver(stl_serial);
-	if (retval) {
-		printk("STALLION: failed to register serial driver\n");
-		goto err_clsdev;
-	}
-
 	return 0;
-err_clsdev:
-	for (i = 0; i < 4; i++)
-		class_device_destroy(stallion_class, MKDEV(STL_SIOMEMMAJOR, i));
-	class_destroy(stallion_class);
-err_reg:
-	unregister_chrdev(STL_SIOMEMMAJOR, "staliomem");
+err_unrtty:
+	tty_unregister_driver(stl_serial);
+err_frtty:
 	put_tty_driver(stl_serial);
-err_pcidr:
-	pci_unregister_driver(&stl_pcidriver);
-	stl_free_isabrds();
 err:
 	return retval;
 }
@@ -4825,8 +4819,6 @@ static void __exit stallion_module_exit(void)
 			tty_unregister_device(stl_serial,
 				brdp->brdnr * STL_MAXPORTS + j);
 	}
-	tty_unregister_driver(stl_serial);
-	put_tty_driver(stl_serial);
 
 	for (i = 0; i < 4; i++)
 		class_device_destroy(stallion_class, MKDEV(STL_SIOMEMMAJOR, i));
@@ -4838,6 +4830,9 @@ static void __exit stallion_module_exit(void)
 	pci_unregister_driver(&stl_pcidriver);
 
 	stl_free_isabrds();
+
+	tty_unregister_driver(stl_serial);
+	put_tty_driver(stl_serial);
 }
 
 module_init(stallion_module_init);

Re: stallion driver dmesg notice

[Ingo Korb]

Jiri Slaby <jirislaby@gmail.com> writes:

> Okay, tty alloc after pci init, attached patch should fix it. Could you
> retest?

Loads find and seems to work with basic tests (and no character loss,
yay!). I'll try 8-link bonded ppp when I've set up a second box.

-ik

Re: stallion driver dmesg notice

[Ingo Korb]

Ingo Korb <usenet@mail.snowcat.de> writes:

> Loads find and seems to work with basic tests (and no character loss,
> yay!). I'll try 8-link bonded ppp when I've set up a second box.

Update: The driver now survives 7-link[1] bonded ppp without problems
with both UART types. IIRC it previously died with CD1400 and stopped
to transmit suddenly with 26C198 ("XP" panels).

Thanks!

-ik
[1] One port didn't work, but that looks like a hardware problem on the
receiving side which isn't stallion-driven.