Found out why "sg" was loaded automagically. Re: devfs: "cd" device not showing up initially.
Some time ago, I posted a question concerning the device name "cd" (module sr_mod) not appearing automatically under my 2.4.x devfs/devfsd configuration. However, "generic" (module sg) does appear automagically. This confused me a bit. The subject I used back then was like "devfs: "cd" device not showing up initially. Doug Gilbert was kind enough to explain to me that the module loading needed be done explicitly for sr_mod so that "cd" entries were registered by devfs/devfsd. Then I came to wonder why "generic" registeted by the module sg showed up. I thought that I was not calling for automatic loading of "sg" myself. After a bit of exchange, Doug even went so far as to read my config files to check for obvious mistakes, and we could not find one. It took me a while to figure out why "sg" was inserted automatically. The cause had nothing to do with devfs/devfsd interaction. I found the answer today. Short answer: On my Debian GNU/Linux PC, /etc/rcS.d/S20modutils (a symlink to /etc/init.d/modutils ) calls modprobe to install modules listed in a file called /etc/modules at boot time, and "sg" was listed there. (I don't know / have forgotten why "sg" is listed there.) I didn't realize that Debian uses this /etc/modules file as part of its grand module configuration scheme. (Or I have forgotten about this completely.) --- somewhat longer description. I followed the suggestions given by various parties after my post, and when I inserted the printk() inside a few scsi-related modules as suggested by Doug Gilbert, the problem became immediately apparent. The module "sg" was inserted by "modprobe", which in turn was called from "S20modutils". (swapon had nothing to do with the "sg" loading as I recently suspected.) [I was going to insert "echo this is $0 or something to that effect in all of the init script files to see where the sg loading was taking place, but embedding the printk in a few C source files was easiter and so I tried it first.] After seeing the message in dmesg output (now I use 128KB buffer for printk to capture all the devfs/devfsd interaction debug messages), I had to read /etc/init.d/S20modutils to find out why. It turns out the Debian module init script uses /etc/modules to list kernel module names that need to be inserted at boot up time. And, for reasons unknown to me (now), the name "sg" was there (!). I should have realized that something was amiss when lsmod showed unused modules as in tmscsim29920 0 (unused) sg 25728 0 (unused) nls_cp437 4384 0 (unused) hpfs 69216 0 (unused) tmscsim is where the CD changer is located. Until I manually mount a CD in there, the module is unused. But what about other threes? Forgetting about "sg", I had a nagging suspition especially about the last two entries. Why are they loaded at all? I could not figure out why until today. These are also listed in /etc/modules, and "auto" is not given. So kerneld is not started at boot time... FYO, just to show what the lsmod output looks like after mounting a CD in nakamichi changer. >duron:/home/ishikawa# mount /dev/scsi/host1/bus0/target6/lun0/cd /mnt2 >mount: special device /dev/scsi/host1/bus0/target6/lun0/cd does not exist (* Oops I have forgotten the manual loading of sr_mod.o *) >duron:/home/ishikawa# mkdir /mnt2 >mkdir: cannot create directory `/mnt2': File exists >duron:/home/ishikawa# modprobe sr_mod >duron:/home/ishikawa# mount /dev/scsi/host1/bus0/target6/lun0/cd /mnt2 >mount: block device /dev/scsi/host1/bus0/target6/lun0/cd is write-protected, mounting >read-only >duron:/home/ishikawa# lsmod >Module Size Used by >isofs 19280 1 (autoclean) >sr_mod 13200 1 >cdrom 26912 0 [sr_mod] >tmscsim29920 1 >sg 25728 0 (unused) >nls_cp437 4384 0 (unused) >hpfs 69216 0 (unused) >duron:/home/ishikawa# ls /mnt2 >Copyright Solaris_2.7 >duron:/home/ishikawa# This final answer that I am posting today only shows that I have been using module loading under linux for quite a long time without understanding its implementation ver well. (The first time I used module loading was to re-order the scsi host scanning about three or four years ago. Using module was one of the few wasy aside from physically swaping bus slots to change the scaned order of host adaptors back then. The original kernel/distribution that I used then was the one that came Yggrdrasil 1994, but I had upgraded various pieces to use more modern kernel and tools. I switched to Debian about two or three years ago. Now I figure I must have have bumped into this module configuration issues back when I switched to Debian, but I must have taken care of them quickly and forgotten about them completely if so.) So anyway, this finally has answered my question that originated from my observation about
Found out why sg was loaded automagically. Re: devfs: cd device not showing up initially.
Some time ago, I posted a question concerning the device name "cd" (module sr_mod) not appearing automatically under my 2.4.x devfs/devfsd configuration. However, "generic" (module sg) does appear automagically. This confused me a bit. The subject I used back then was like "devfs: "cd" device not showing up initially. Doug Gilbert was kind enough to explain to me that the module loading needed be done explicitly for sr_mod so that "cd" entries were registered by devfs/devfsd. Then I came to wonder why "generic" registeted by the module sg showed up. I thought that I was not calling for automatic loading of "sg" myself. After a bit of exchange, Doug even went so far as to read my config files to check for obvious mistakes, and we could not find one. It took me a while to figure out why "sg" was inserted automatically. The cause had nothing to do with devfs/devfsd interaction. I found the answer today. Short answer: On my Debian GNU/Linux PC, /etc/rcS.d/S20modutils (a symlink to /etc/init.d/modutils ) calls modprobe to install modules listed in a file called /etc/modules at boot time, and "sg" was listed there. (I don't know / have forgotten why "sg" is listed there.) I didn't realize that Debian uses this /etc/modules file as part of its grand module configuration scheme. (Or I have forgotten about this completely.) --- somewhat longer description. I followed the suggestions given by various parties after my post, and when I inserted the printk() inside a few scsi-related modules as suggested by Doug Gilbert, the problem became immediately apparent. The module "sg" was inserted by "modprobe", which in turn was called from "S20modutils". (swapon had nothing to do with the "sg" loading as I recently suspected.) [I was going to insert "echo this is $0 or something to that effect in all of the init script files to see where the sg loading was taking place, but embedding the printk in a few C source files was easiter and so I tried it first.] After seeing the message in dmesg output (now I use 128KB buffer for printk to capture all the devfs/devfsd interaction debug messages), I had to read /etc/init.d/S20modutils to find out why. It turns out the Debian module init script uses /etc/modules to list kernel module names that need to be inserted at boot up time. And, for reasons unknown to me (now), the name "sg" was there (!). I should have realized that something was amiss when lsmod showed unused modules as in tmscsim29920 0 (unused) sg 25728 0 (unused) nls_cp437 4384 0 (unused) hpfs 69216 0 (unused) tmscsim is where the CD changer is located. Until I manually mount a CD in there, the module is unused. But what about other threes? Forgetting about "sg", I had a nagging suspition especially about the last two entries. Why are they loaded at all? I could not figure out why until today. These are also listed in /etc/modules, and "auto" is not given. So kerneld is not started at boot time... FYO, just to show what the lsmod output looks like after mounting a CD in nakamichi changer. duron:/home/ishikawa# mount /dev/scsi/host1/bus0/target6/lun0/cd /mnt2 mount: special device /dev/scsi/host1/bus0/target6/lun0/cd does not exist (* Oops I have forgotten the manual loading of sr_mod.o *) duron:/home/ishikawa# mkdir /mnt2 mkdir: cannot create directory `/mnt2': File exists duron:/home/ishikawa# modprobe sr_mod duron:/home/ishikawa# mount /dev/scsi/host1/bus0/target6/lun0/cd /mnt2 mount: block device /dev/scsi/host1/bus0/target6/lun0/cd is write-protected, mounting read-only duron:/home/ishikawa# lsmod Module Size Used by isofs 19280 1 (autoclean) sr_mod 13200 1 cdrom 26912 0 [sr_mod] tmscsim29920 1 sg 25728 0 (unused) nls_cp437 4384 0 (unused) hpfs 69216 0 (unused) duron:/home/ishikawa# ls /mnt2 Copyright Solaris_2.7 duron:/home/ishikawa# This final answer that I am posting today only shows that I have been using module loading under linux for quite a long time without understanding its implementation ver well. (The first time I used module loading was to re-order the scsi host scanning about three or four years ago. Using module was one of the few wasy aside from physically swaping bus slots to change the scaned order of host adaptors back then. The original kernel/distribution that I used then was the one that came Yggrdrasil 1994, but I had upgraded various pieces to use more modern kernel and tools. I switched to Debian about two or three years ago. Now I figure I must have have bumped into this module configuration issues back when I switched to Debian, but I must have taken care of them quickly and forgotten about them completely if so.) So anyway, this finally has answered my question that originated from my observation about device name
