[Explanation is at the end]
> >
> > Is sd_mod loaded at this point?
>
> Not after I plug the USB storage device in, no.
>
> > (Please, try with clean system or after
> > rmmod sd_mod).
>
> sd_mod was never loaded.
>
As suspected; then I know what happens :-)
> Now I did try my tests:
>
> /dev/scsi/host1/bus0/target0/lun0
this is USB?
> [root@pc root]# fdisk /tmp/sda
>
Forget mknod with devfs. It works in your particular case, but ...
> So, creating the /tmp/sda node and attempting to open it with fdisk
> seems to have loaded the sd_mod which finds the partitions and creates
> the /dev/scsi/host1/bus0/target0/lun0/{disc,part1} nodes.
>
Yes, the same would happen if you just tried fdisk /dev/sda or (for that
matter)
fdisk /dev/discs/disc1/disc
fdisk /dev/scsi/host1/bus0/target0/lun0/disc
But /dev/sda won't work (most probably, but I am going to bet) after
reboot while both others will do :-)
> [root@pc root]# rmmod sd_mod
> /dev/scsi/host1/bus0/target0/lun0
Correct
> [root@pc root]# modprobe sd_mod
> Segmentation fault
>
Kernel bug. Chmouel?
> Yummy! Kernel OOPS trying to modprobe sd_mod again after rmmoding it.
> Here is the oops from the messages file:
>
> Oct 3 10:59:44 pc kernel: Attached scsi removable disk sda at scsi1,
> channel 0, id 0, lun 0
> Oct 3 10:59:44 pc kernel: SCSI device sda: 62977 512-byte hdwr
sectors
> (32 MB)
> Oct 3 10:59:44 pc kernel: sda: Write Protect is off
> Oct 3 10:59:44 pc kernel: /dev/scsi/host1/bus0/target0/lun0:<1>Unable
to
> handle kernel paging request at virtual address 94000075
> Oct 3 10:59:44 pc kernel: printing eip:
> Oct 3 10:59:44 pc kernel: c017e11b
> Oct 3 10:59:44 pc kernel: *pde = 00000000
> Oct 3 10:59:44 pc kernel: Oops: 0000
> Oct 3 10:59:44 pc kernel: CPU: 0
> Oct 3 10:59:44 pc kernel: EIP: 0010:[account_io_start+43/96]
> Oct 3 10:59:44 pc kernel: EIP: 0010:[<c017e11b>]
> Oct 3 10:59:44 pc kernel: EFLAGS: 00010046
> Oct 3 10:59:44 pc kernel: eax: 00000000 ebx: 94000045 ecx:
00000002
> edx: 00000000
> Oct 3 10:59:44 pc kernel: esi: 00000002 edi: 00000000 ebp:
c6628f80
> esp: c5d2dca4
> Oct 3 10:59:44 pc kernel: ds: 0018 es: 0018 ss: 0018
> Oct 3 10:59:44 pc kernel: Process modprobe (pid: 3024,
stackpage=c5d2d000)
> Oct 3 10:59:44 pc kernel: Stack: c5d2de54 c014be0c d7defa20 00000002
> d7defa20 c017e1e4 94000045 d7defa20
> Oct 3 10:59:44 pc kernel: 00000000 00000002 94000045 00000000
> 00000000 00000000 00000002 c017e945
> Oct 3 10:59:44 pc kernel: d7defa20 00000000 00000002 00000003
> 08060640 00002000 d6927a48 d6927a40
> Oct 3 10:59:44 pc kernel: Call Trace: [padzero+28/32]
[req_new_io+52/96]
> [__make_request+1349/1888]
>
[af_packet:__insmod_af_packet_O/lib/modules/2.4.8-26mdk/kernel/net/pac+-
> 759689/96] [generic_make_request+346/368]
> Oct 3 10:59:44 pc kernel: Call Trace: [<c014be0c>] [<c017e1e4>]
> [<c017e945>] [<d8803877>] [<c017ecba>]
> Oct 3 10:59:44 pc kernel: [submit_bh+87/128] [ll_rw_block+583/656]
> [bread+53/112] [validate_partition_table+27/160]
> [call_console_drivers+234/240] [ldm_partition+130/480]
> Oct 3 10:59:44 pc kernel: [<c017ed27>] [<c017ef97>] [<c0134695>]
> [<c01544eb>] [<c0114e7a>] [<c01545f2>]
> Oct 3 10:59:44 pc kernel: [check_partition+222/288]
> [grok_partitions+97/160] [register_disk+43/64] [<d899ad78>]
[<d899bd88>]
> [<d899bd40>]
> Oct 3 10:59:44 pc kernel: [<c0152b6e>] [<c0152fa1>] [<c0152f2b>]
> [<d899ad78>] [<d899bd88>] [<d899bd40>]
> Oct 3 10:59:44 pc kernel:
>
[af_packet:__insmod_af_packet_O/lib/modules/2.4.8-26mdk/kernel/net/pac+-
> 335108/96] [<d899b2b6>] [<d899bd40>] [<d899bd40>]
> [sys_init_module+1335/1520] [<d899bcf4>]
> Oct 3 10:59:44 pc kernel: [<d886b2fc>] [<d899b2b6>] [<d899bd40>]
> [<d899bd40>] [<c0115c47>] [<d899bcf4>]
> Oct 3 10:59:44 pc kernel: [<d8999060>] [system_call+51/64]
> Oct 3 10:59:44 pc kernel: [<d8999060>] [<c0106ec3>]
> Oct 3 10:59:44 pc kernel:
> Oct 3 10:59:44 pc kernel: Code: 8b 43 30 01 c8 89 43 30 eb 13 85 d2
> 74 07 8b 43 38 40 89 43
>
> So why is sd_mod not loaded when the USB storage device is added?
>
O.K. here is explanation.
When you plug in your USB storage, first driver for it is loaded. This
driver acts as SCSI HA and registers as SCSI HA under scsi_mod. As part
of initializing SCSI HA driver it scans SCSI bus and for every target
tries every *registered* SCSI device driver (it is actually done in
generic routines in scsi_mod). scsi_mod *NEVER* loads any driver itself.
As long as sd_mod (SCSI HD driver) is not loaded it won't ever be tried.
The above is true devfs or no devfs and for *every* SCSI device.
What have confused you, if you do not have devfs you have device
entries. When you try to access /dev/sda, kernel asks to load driver for
block-major-8 and modutils know that it is sd_mod. So it is transparent
for you.
With devfs it works the same actually. Look into /etc/modules.devfs and
you see that when we access /dev/sd* devfsd tries to load sd_mod.
What is missing here is hotplug (in general sense, but it is pretty
sensible for hotplug package to support it) support for SCSI devices.
What should ideally happen is
- SCSI HA driver is loaded
- it scans SCSI bus for targets
- for every target it calls hotplug that loads needed device driver
In general devfs+modules sucks badly. devfs is ideal for a kernel that
has everything preloaded. devfs+modules still needs much work.
-andrej
