|
|
| Author |
 Topic  |
|
|
Lou Erickson
Posting Mania
528 Posts |
 Posted - 05/22/2004 : 02:27:34 AM
|
So... I've got a Neuros. (Once it's back from USB 2.0 upgrade-land.)
I've also got a Linux machine. I thought it would be swell to synch from there, because it's where all my music lives.
I discovered that that machine even has a USB 2.0 port right on the front! How cool is that?
So... I fiddled my kernel to get USB support. USB works fine.
Problem: USB takes over scsi. Now my scsi controler won't auto-probe. No tape drive means no backups! This is very bad.
My backup software barfs at not having the drivers loaded, and they keep auto-unloading.
How can I get my SCSI card AND the USB card to both exist on the system at once?
I'm stumped. And it's late. And I'm going to bed.
Why are there no good docs on this! All the USB docs are lousy, all the modprobe docs are lousy... all I want to know is how to get it to notice my SCSI card. It does this if I have no USB support... but USB breaks it.
Any suggestions, or am I hosed?
|
Your quick response to this post: (0 total votes)
I agree (0%)
I disagree (0%)
|
|
|
demonbane
Posting Profoundly
164 Posts |
Posted - 05/22/2004 : 09:38:41 AM
|
The USB modules won't actually 'take over' your SCSI devices. What they MIGHT do, however, is change the ordering of your SCSI device names. I have a number of USB, Firewire, and real SCSI devices that I use and it was becoming damned near impossible to keep up with my fstab each time I plugged one in since it would probably be on a different device name. Since I upgraded to a 2.6 series kernel and started using the STUPENDOUS udev, I've had no problems.
So, for starters, I'd suggest checking some of the higher order SCSI device names for your devices. (i.e. /dev/sd[b-z] and/or /dev/scd[0-9]) It's possible that you're just not seeing the devices because they're on a higher letter than you're used to.
It would also be helpful to have some more info on your system. Which kernel are you using, which modules are loaded, what's in your fstab, etc. The output of 'cat /proc/scsi/scsi' would also be useful. |
Your quick response to this post: (0 total votes)
I agree (0%)
I disagree (0%) |
 |
|
|
Lou Erickson
Posting Mania
528 Posts |
Posted - 05/22/2004 : 12:23:19 PM
|
No, they don't take over. That was me being inaccurate and frustrated.
Before I built USB capability in to the system, when I used my SCSI devices, the module loader would realize, "Oh! They need the SCSI card!" and go fetch aic7xxx and load it.
Now that I've loaded USB, the module loader apparently thinks the SCSI modules are already loaded, and doesn't load aic7xxx. It looks on the USB chain, and doesn't find SCSI devices.
Now, if I modprobe scsi myself, the tape drive appears in the SCSI chain. It does get assigned new device ids, which causes no end of havoc to a large number of system maintenance scripts I've written.
What I would like is for aic7xxx to be loaded first, so my predictable SCSI devices would remain where they are, and to have the usb modules loaded later, on demand. In a perfect world, both of these drivers would load as needed.
I'm considering compiling aic7xxx right in to the kernel to see if that solves the autoloader and ordering issues.
I have yet to find useful documentation on what triggers the autoloader and how to make it do what I want it to do rather than the strange things it has always done for me.
|
Your quick response to this post: (0 total votes)
I agree (0%)
I disagree (0%) |
|
|
|
alecm
Posting Profoundly
117 Posts |
Posted - 05/22/2004 : 1:00:13 PM
|
quote:
Originally posted by Lou Erickson
I'm considering compiling aic7xxx right in to the kernel to see if that solves the autoloader and ordering issues.
That's probably a good idea anyway, loading it as a module doesn't really have many advantages. You might also consider loading the aic7xxx and scsi drivers during boot or better yet in an initrd (hey you may want to boot off of scsi someday). |
Your quick response to this post: (0 total votes)
I agree (0%)
I disagree (0%) |
|
|
|
demonbane
Posting Profoundly
164 Posts |
Posted - 05/22/2004 : 3:57:58 PM
|
| I'm not sure if this is distro specific or not, but on my Debian system I can list modules that I want loaded on boot in /etc/modules. Either way, what you want to do is have the necessary SCSI modules loaded ASAP. If nothing else, you can always create an rc script to load the modules for you before hotplug ever gets loaded. |
Your quick response to this post: (0 total votes)
I agree (0%)
I disagree (0%) |
|
|
|
Lou Erickson
Posting Mania
528 Posts |
Posted - 05/22/2004 : 5:31:41 PM
|
Hmmm. SuSE apparently has no /etc/modules. I have the horribly complicated modules.conf, which I thought would do that, but now I can't find how.
Even if I load the module in initrd, or in rc, it still auto-unloads after a while, and breaks the nightly tape backups and tape library control commands.
Building it directly in to the kernel may fix it. I'll try again and see.
The advantage of building it as a module are twofold: I can use the same kernel on machines that don't have this SCSI card, and the machine isn't using the memory unless there's need. The latter is less important, and I can live with the first.
Best would be to figure out how to make the darn thing autoload properly, but I have found no suggestions at all on the 'net, nor in the man pages. At this point, I don't even know who to ask. This is the best resource I could think of. (And it hasn't proven me wrong yet! Thanks guys!)
|
Your quick response to this post: (0 total votes)
I agree (0%)
I disagree (0%) |
|
|
|
alecm
Posting Profoundly
117 Posts |
Posted - 05/22/2004 : 7:43:28 PM
|
quote:
Originally posted by Lou Erickson
Even if I load the module in initrd, or in rc, it still auto-unloads after a while, and breaks the nightly tape backups and tape library control commands.
Yeah, this may be a problem no matter what method you use to load the module early. Try adding "options -k module_name module_options" in /etc/modules.conf for the relevant modules (the "module_options" are of course optional). The '-k' should disable autocleaning for those modules, though I've never had to do this myself (my scsi systems have always had scsi disks, so the modules were never unloaded (if they weren't built into the kernel)).
quote:
The advantage of building it as a module are twofold: I can use the same kernel on machines that don't have this SCSI card, and the machine isn't using the memory unless there's need. The latter is less important, and I can live with the first.
The kernel should still work without issue on other systems, even with irrelevant drivers loaded. The extra memory really doesn't matter much on modern systems (what's ~100kb RAM for a few extra modules these days), except if you are making boot floppies, but people commonly have kernels over 1.44MB these days, so even that is generally not relevant.
As an aside, there are some serious security benefits gained by disallowing module loading entirely, and having an truly monolithic kernel. Module based rootkits are not uncommon, and are generally the most dangerous and most difficult to detect. That said, I myself appreciate the flexibility afforded by modules and would only opt for a fully monolithic kernel on a security critical system. |
Your quick response to this post: (0 total votes)
I agree (0%)
I disagree (0%) |
|
|
| |
Topic |
|
|
|
| Neuros Forums |
|
|
|
|
|
Forum Locked
Topic Locked
