Roberto, Have you contacted IBM for support? I know of no module counting problems in LiS proper even as far back as 2.8. There is the possibility that the driver is calling lis_inc_mod_cnt() inappropriately, which would increase the mod count on the streams.o kernel module instead of the driver kernel module.
Recent LiS 'streams.o' kernel module only increases its module count when it allocates stdata structures in lis_alloc_stdata() and only decrements when the stdata (stream head) is deallocated. There are two ways for an stdata structure to exist: 1) attached to an open file descriptor; 2) permanently linked under a multiplexing driver. If you do /usr/sbin/lsof you will get a listing of open files. You can check that list to see if there are any open devices that correspond to streams devices that a holding the use count up at 1. If there are not, then there may be a stream head I_PLINK'ed under a multiplexing driver that was then unloaded as a kernel module. Some of the LiS debug flags to the 'streams' command might help there. Aside from that, it is more likely the addon driver misbehaving (calling lis_inc_mod_cnt() in one place and MOD_DEC_USE_COUNT in another, or not at all). Without access to the source for the drivers, it is not possible to assist you in debugging them. If IBM has stated that they will support their drivers on LiS 2.16.0, perhaps you could ask them to make good on that statement and assist you with this problem. Also, their recommendations with regard to LiS version may have changed since the last information that you have. --brian On Mon, 17 May 2004, Roberto Salomon wrote: > > Brian, > We're stuck on 2.16.0 due to CS/Linux. Currently IBM only supports > their environment with this release of LiS... :( At least that's the > info they sent us. > Em Seg, 2004-05-17 �s 13:30, Brian F. G. Bidulock escreveu: > > Roberto, > > Ok. Why are you using LiS 2.16.0? Many things were fixed along the > way to 2.16.18. Try 2.16.18 and see if the problem just goes away. > > --brian > > On Mon, 17 May 2004, Roberto Salomon wrote: > > > > > Brian, > > Sorry for taking so long. Our test system was busy on other tasks... > > :) > > The output of /proc/modules when LiS refuses to unload is: > > nls_iso8859-1 3488 1 (autoclean) > > nls_cp437 5120 1 (autoclean) > > vfat 12092 1 (autoclean) > > fat 36984 0 (autoclean) [vfat] > > usb-storage 69184 1 > > usb-uhci 24676 0 (unused) > > usbcore 73792 0 [usb-storage usb-uhci] > > streams 568608 1 > > eepro100 21068 1 > > mii 3976 0 [eepro100] > > st 29680 0 (unused) > > aic7xxx 133248 5 > > sg 33892 0 (unused) > > sd_mod 12828 12 > > scsi_mod 107548 5 [usb-storage st aic7xxx sg sd_mod] > > ext3 65984 4 > > jbd 47500 4 [ext3] > > All modules that depend on streams were unloaded. > > > > > > -- > > Roberto F. Salomon > > Diretor de Tecnologia > > Techisa do Brasil Ltda. htt://[1]www.techisa.srv.br > > +55 61 340-6266 > > > > -- > Roberto F. Salomon > Diretor de Tecnologia > Techisa do Brasil Ltda. htt://www.techisa.srv.br > +55 61 340-6266 > > References > > 1. http://www.techisa.srv.br/ -- Brian F. G. Bidulock � The reasonable man adapts himself to the � [EMAIL PROTECTED] � world; the unreasonable one persists in � http://www.openss7.org/ � trying to adapt the world to himself. � � Therefore all progress depends on the � � unreasonable man. -- George Bernard Shaw � _______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
