irtty_sir cannot be unloaded

This is fixed in the patches I've send to Jeff :
http://marc.theaimsgroup.com/?l=linux-kernel&m=105286597418927&w=2
Just be patient ;-)

I guess that if it's the only complain, this means that the
rest of the IrDA stack works for you in 2.5.X. At least, I'm not the only one testing it...

Jean

fre, 23.05.2003 kl. 01.36 skrev Jean Tourrilhes:

Well, this got rid of the warning :) But actually when I stop irattach (using Debian's init-script (/etc/init.d/irda stop)) my computer freezes. This works (of course) fine with 2.4.21-rc2. I thought the problem was the module unloading, but it seems to be something with irattach instead. Sorry about that.

It works, but I get lots of weird/ugly/different messages. This is with a SonyEricsson P800. Except for those annoying messages in my logs, it works perfect :-)

irlap_change_speed(), setting speed to 9600 sirdev_open - done, speed = 0 sirdev_schedule_request - state=0x0700 / param=9600 sirdev_schedule_request - down
irda_config_fsm - up
irlap_change_speed(), setting speed to 115200 sirdev_schedule_request - state=0x0700 / param=115200 sirdev_schedule_request - down
irda_config_fsm - up
irlap_change_speed(), setting speed to 9600 sirdev_schedule_request - state=0x0700 / param=9600 sirdev_schedule_request - down
irda_config_fsm - up
irlap_change_speed(), setting speed to 115200 sirdev_schedule_request - state=0x0700 / param=115200 sirdev_schedule_request - down
irda_config_fsm - up
irlap_change_speed(), setting speed to 9600 sirdev_schedule_request - state=0x0700 / param=9600 sirdev_schedule_request - down
irda_config_fsm - up
irlap_change_speed(), setting speed to 115200 sirdev_schedule_request - state=0x0700 / param=115200 sirdev_schedule_request - down
irda_config_fsm - up
irlap_change_speed(), setting speed to 9600 sirdev_schedule_request - state=0x0700 / param=9600 sirdev_schedule_request - down
irda_config_fsm - up
irlap_change_speed(), setting speed to 115200 sirdev_schedule_request - state=0x0700 / param=115200 sirdev_schedule_request - down
irda_config_fsm - up
irlap_change_speed(), setting speed to 9600 sirdev_schedule_request - state=0x0700 / param=9600 sirdev_schedule_request - down
irda_config_fsm - up
irlap_change_speed(), setting speed to 115200 sirdev_schedule_request - state=0x0700 / param=115200 sirdev_schedule_request - down
irda_config_fsm - up
irlap_change_speed(), setting speed to 9600 sirdev_schedule_request - state=0x0700 / param=9600 sirdev_schedule_request - down
irda_config_fsm - up
irlap_change_speed(), setting speed to 115200 sirdev_schedule_request - state=0x0700 / param=115200 sirdev_schedule_request - down
irda_config_fsm - up
irlap_change_speed(), setting speed to 9600 sirdev_schedule_request - state=0x0700 / param=9600 sirdev_schedule_request - down
irda_config_fsm - up
Module ircomm_tty cannot be unloaded due to unsafe usage in include/linux/module.h:456 ircomm_tty_attach_cable() ircomm_tty_ias_register()
ircomm_tty_close()
ircomm_tty_close(), open count > 0 irlap_change_speed(), setting speed to 115200 sirdev_schedule_request - state=0x0700 / param=115200 sirdev_schedule_request - down
irda_config_fsm - up
irlap_change_speed(), setting speed to 9600 sirdev_schedule_request - state=0x0700 / param=9600 sirdev_schedule_request - down
irda_config_fsm - up
irlap_change_speed(), setting speed to 115200 sirdev_schedule_request - state=0x0700 / param=115200 sirdev_schedule_request - down
irda_config_fsm - up
ircomm_param_xon_xoff(), XON/XOFF = 0x11,0x13 ircomm_param_enq_ack(), ENQ/ACK = 0x00,0x00 ircomm_tty_check_modem_status()

I see I have gotten a ircomm_tty can't be unloaded as well. Hmm. Well, as I said, it works perfect, except for stopping irattach.

Thanks.

Best regards,
Stian

Disable HotPlug in your kernel and recompile. Various network
people have been notified of this bug, but this is not an easy one.

Yeah, Martin should increase the debug level.

This has been fixed in the latest BK.

	Have fun...

	Jean

fre, 23.05.2003 kl. 03.13 skrev Jean Tourrilhes:

You were right, this was the problem. Then I just have to choose what I need the most; irda or pcmcia :)

Thanks :)

Best regards,
Stian

I bet pcmcia works without hotplug ;-)

IMHO the worst thing that might happen without hotplug would be one has to modprobe some drivers for CardBus cards by hand. But maybe I'm missing something because I'm not using hotplug...

Anyway, I really hope the network-hotplug deadlock issue gets resolved before 2.6.0 or we'll see quite a number of such reports then...

Martin

fre, 23.05.2003 kl. 08.38 skrev Martin Diehl:

I might be blind or stupid (or both), but when I disable hotplug, I can't enable cardbus at all. :) But davem's patch worked just fine :) *happy*

Best regards,
Stian

Sorry for the confusion, you are right. I meant it works without userland hotplug stuff, but that's a mood point as you need to enable kernel hotplug to get the pcmcia option even presented - ENOTENOUGHCOFFEIN 8)

Yep, looks pretty good now.

Martin

Seems the thread died...

This and a few other things from the list which I've sent to you is done in my local codebase, but needs some testing over the weekend. So you'll see patches on monday. I guess I'll make them against what you've sent to Jeff despite it may need some more time until this appears in bk - Ok?

Martin

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin,

If there is any code I can help test, I'm more than willing :-)

Jan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+zcaBpuyeqyCEh60RAkesAKCHxYIw+h+ALg6gWUmwU56WdZBu6wCfexlQ 4B41KpROmIIvKsEo00epq2A=
=R1oV
-----END PGP SIGNATURE-----

Me too - but no, wrt. the rtnl-deadlock nothing that I know of. The changes I mentioned above are merely cleanups of the sir-dev and irtty-sir stuff completely unrelated to the deadlock.

I've just tried to ping the other thread but as was said, it's a network/hotplug problem and definitely not easy to resolve.

Martin