On 28/09/06, Richard Broersma Jr <[EMAIL PROTECTED]> wrote:
> Sounds to me like the problem is on your linux box, not the windoze.
> machine.
> How did you compile your kernel? Are you sure you included cifs in it?
> If so, is it a module, and is it being loaded?
I am pretty sure my original kernel had cifs built into the kernel. I also
have samba installed
in the machine.
I thought I could give a newer kernel source a try with cifs built as a kernel
module. However,
modprobe doesn't seem to see it. Perhaps it is already loaded by default?
If "grep cifs$ /proc/filesystems" doesn't show anything then support
definitely isn't available. This means it's either not statically
built into the kernel or that it's not available as a loadable moduel
for whatever reason.
If it is something you intend to use consistently then I don't see
much point in building it as a module. Nonetheless, here are a few
tips relating to the usage of loadable kernel modules:
1) If you enable an option as a module where previously it wasn't
enabled at all then, in most cases you can get away with: make modules
&& make modules_install. The modules_install step is necesary to move
them to the correct place under /lib/modules/($uname -r).
2) There are some exceptions to the above rule. If in doubt, it's
safer to do this: make && make modules_install.
3) Make sure your bootloader is booting a kernel built from the source
tree that you're actually manipulating! This is particularly pertinent
if you have multiple source trees installed. For sanity's sake, also
make sure you have /usr/src/linux symlinked to whichever tree you want
to work from.
4) Further to the previous point, make sure that the kernel referenced
by your bootloader is the same as the one you most recently built. For
example, if your bootloader is pointing to /boot/vmlinuz and you're
using x86 arch: cmp /boot/vmlinuz /usr/src/linux/arch/i386/bzImage. If
it differs in any way whatsoever then copy bzImage over vmlinuz and
reboot immediately. Another good test is to run uname -a and check the
build time.
5) Never mix and match gcc versions when building any portion of the
kernel (be it the kernel image itself or any loadable modules). Some
people run into this issue because of the gcc-3.3->3.4 and gcc-4.1
upgrade scenarios. If you think you've been affected then back up your
/usr/src/linux/.config file and run "make mrproper". Copy the .config
file back again then build the kernel/modules all over again.
6) You can "rescan" for available modules by running:
/sbin/modules-update. Worth a shot if "modprobe -l" isn't showing the
modules that you think should be available. The list should generally
correspond with the output of: find /lib/modules/$(uname -r) -name
"*.ko".
HTH,
--Kerin
--
[email protected] mailing list
