stallion driver dmesg notice
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
Ingo Korb napsal(a):
Quoted 27 lines
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-
Quoted 6 lines
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,
Signature · 4 lines
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
In reply to Ingo KorbQuoted 10 lines · Ingo Korb
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.
Quoted 2 lines
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
---
commit a6c3fb453e98ba32291a4fc5a7d843fb27359182
tree d28d09d3fa53b7af465c7b4cc88c295459c96276
parent 8785a2ca27122a0a46119fc57e7667bf9c916df4
author Jiri Slaby <[email protected]> Mon, 04 Jun 2007 00:05:16 +0200 committer Jiri Slaby <[email protected]> Mon, 04 Jun 2007 00:07:32 +0200
drivers/char/stallion.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
drivers/char/stallion.c +1 -1
@@ -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 "
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 10 lines · Ingo Korb
Quoted 5 lines
Quoted 2 lines
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.
Quoted 11 lines
Quoted 1 line
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=8BUG: unable to handle kernel NULL pointer dereference at virtual address00000074
Okay, tty alloc after pci init, attached patch should fix it. Could you retest?
Quoted 5 lines
Quoted 1 line
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.
---
commit f6d5d1877b0f7ac82f5e1fec2ead0429eeb069c8
tree 31beaaee84ef718acc5401b3cb07a7f2e340f0fe
parent a6c3fb453e98ba32291a4fc5a7d843fb27359182
author Jiri Slaby <[email protected]> Mon, 04 Jun 2007 10:39:41 +0200 committer Jiri Slaby <[email protected]> Mon, 04 Jun 2007 10:39:41 +0200
drivers/char/stallion.c | 73 ++++++++++++++++++++++------------------------- 1 files changed, 34 insertions(+), 39 deletions(-)
drivers/char/stallion.c +34 -39
@@ -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);
Quoted 2 lines · Jiri Slaby
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
Quoted 2 lines · Ingo Korb
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.