Hi,
A few days ago I sent the enclosed bug report to the address

advertised in Documentation/rocket.txt.  Till now I got no reply.

While they think about it, I decided to air the problem here, too.
In a nutshell, the rocket module doesn't deregister its devices during

removal, they stay in /sys/class/tty causing grief on reinsert and

crippling udev.
Assuming it's an easy fix, can I plea for a patch against 2.6.23?  Or

is there a workaround like manually deregistering the devices?
Thanks,

Feri.
-------------------- Start of forwarded message --------------------

From: Ferenc Wagner <wferi@niif.hu>

To: support@comtrol.co.uk

Subject: RocketPort Linux driver errors on module reload

Date: Fri, 12 Oct 2007 00:22:17 +0200

Message-ID: <87fy0hwaue.fsf@tac.ki.iif.hu>
Hi,
I hope I send this message to the right address...
I experience the following with the 2.09 version of the driver, as

included in vanilla Linux 2.6.23.  If I insert the module, I got some

pretty normal messages, like:
RocketPort device driver module, version 2.09, 12-June-2003

ACPI: PCI Interrupt 0000:01:08.0[A] -> GSI 20 (level, low) -> IRQ 21

Comtrol PCI controller #0 ID 0x802 found in bus:slot:fn 0000:01:08.0 at address d800, 1 AIOP(s) (RocketPort UPCI 8 port w/external I/F)

Installing RocketPort UPCI 8 port w/external I/F, creating /dev/ttyR0 - 7

ACPI: PCI Interrupt 0000:02:06.0[A] -> GSI 24 (level, low) -> IRQ 22

Comtrol PCI controller #1 ID 0x802 found in bus:slot:fn 0000:02:06.0 at address c800, 1 AIOP(s) (RocketPort UPCI 8 port w/external I/F)

Installing RocketPort UPCI 8 port w/external I/F, creating /dev/ttyR8 - 15
However, if I remove the module from the kernel, and then insert it

again, lots of error messages result:
RocketPort device driver module, version 2.09, 12-June-2003

Comtrol PCI controller #0 ID 0x802 found in bus:slot:fn 0000:01:08.0 at address d800, 1 AIOP(s) (RocketPort UPCI 8 port w/external I/F)

Installing RocketPort UPCI 8 port w/external I/F, creating...
[ message continues ]

Could you try the attached patch below?
--
diff --git a/drivers/char/rocket.c b/drivers/char/rocket.c

index 56cbba7..94bb3d0 100644

--- a/drivers/char/rocket.c

+++ b/drivers/char/rocket.c

@@ -699,8 +699,8 @@ static void init_r_port(int board, int aiop, int chan, struct pci_dev *pci_dev)

 	spin_lock_init(&info->slock);

 	mutex_init(&info->write_mtx);

 	rp_table[line] = info;

-	if (pci_dev)

-		tty_register_device(rocket_driver, line, &pci_dev->dev);

+	tty_register_device(rocket_driver, line, pci_dev ? &pci_dev->dev :

+			NULL);

 }
 /*

@@ -2434,7 +2434,7 @@ static int __init rp_init(void)

 	rocket_driver->init_termios.c_ispeed = 9600;

 	rocket_driver->init_termios.c_ospeed = 9600;

 #ifdef ROCKET_SOFT_FLOW

-	rocket_driver->flags |= TTY_DRIVER_REAL_RAW | TTY_DRIVER_DYNAMIC_DEV;

+	rocket_driver->flags |= TTY_DRIVER_REAL_RAW;

 #endif

 	tty_set_operations(rocket_driver, &rocket_ops);
@@ -2491,10 +2491,14 @@ static void rp_cleanup_module(void)

 	if (retval)

 		printk(KERN_INFO "Error %d while trying to unregister "

 		       "rocketport driver\n", -retval);

-	put_tty_driver(rocket_driver);
 	for (i = 0; i < MAX_RP_PORTS; i++)

-		kfree(rp_table[i]);

+		if (rp_table[i]) {

+			tty_unregister_device(rocket_driver, i);

+			kfree(rp_table[i]);

+		}

+

+	put_tty_driver(rocket_driver);
 	for (i = 0; i < NUM_BOARDS; i++) {

 		if (rcktpt_io_addr[i] <= 0 || is_PCI[i])

-

You are the man, Jiri!  That indeed fixes the problem.

Thank you very much.  What a turnaround...
Shouldn't Documentation/rocket.txt also be changed?  I'm not sure

whether that support email is still valid.

--

Regards,

Feri.

-

And so am I. I wouldn't change it, maybe they will contact you some later ;).
Anyway the driver faces another problem with pci refcounting (it doesn't

increment the counter) and the device might be removed from it any time the pci

bus code decides. Are you willing to test to-pci-probing patches (i.e. patches

which converts the driver to the model introduced in linux 2.4)? If not, I'll

only increment the counter on modprobe and decrement it on rmmod, since it would

be a safe (in the meaning of not changing that much code) way of fixing the problem.
thanks,

--

Jiri Slaby (jirislaby@gmail.com)

Faculty of Informatics, Masaryk University

-

That doesn't sound too good...  Do you mean the module could stop
Well yes.  We've got a copule of such cards, which raises some

interest in a proper driver.  Just send the patches with some
And what are the drawbacks of this simple solution?

--

Regards,

Feri.

-

Hmm, nobody holds the reference according to the current

implementation, so the pci layer doesn't know that anybody is working
Nothing, but it's not the proper way -- just a safe fallback. But you

can still say no :).
regards,

--js

-

Sorry, I don't understand this suggestion.  I don't read LKML, please

don't suppose any prior knowledge of the jargon used here...  Do you

mean I should use the bleeding edge git source of the kernel?  Not

something I'm eager to do, but can do, actually.  And would you send
I expected an improper way to have some disadvantages at least. :)
Anyway, I can tolerate some glitches during the porting of this

module, resulting in interruptions of the serial devices, but leaving

the rest of the system mostly stable; it's a production system after

all.  If the changes are more threatening, I'll use another system for

the tests.  In short: suggest a method and let's give a chance for the

proper solution.  Just please enclose some risk assessment.

--

Regards,

Feri.

-

I meant the creating of a git repository with only the module would be the

easiest possible and most comfortable way for you :). Otherwise I can post you a
Yes, if you have pci hotpluggable motherboard :). Pci probing (the new method)

allows you adding/probing pci devices on the fly, not only when the module is
I did such switches in drivers several times yet, but I can't assure you, that I

won't make any mistake, but this driver seems not to need too many changes.

Maybe functionality regressions would occur rather than instability of system.
Anyway I would rather wait for the changes from comtrol to not break their

upcoming patches (if they post them in some short term) and then do these changes.
thanks,

--

Jiri Slaby (jirislaby@gmail.com)

Faculty of Informatics, Masaryk University

-

Thanks for the explanation.  Maybe one day the E15k-s in the basement
Ah, I didn't know you were in contact with them.  Till now I only got

a notice that my request had been forwarded to another continent with

the Linux developer. :)  Sure, let's wait for the answer.

--

Regards,

Feri.

-