Re: counting scsi hosts
Jim Crilly wrote: More stuff is configurable without a recompile. If I add/change hardware I don't have to do anything unless it's something required for booting and even then updating my initrd is simple. And I have run into cases where reloading modules will fix things, Ok, that are advantages to be made use of. But when hardware is not about to be changed and it's for a server that should just run the way it is reliably, what's the advantage of using modules for things required to boot anyway? MOTT, you could not even unload those modules. GH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: counting scsi hosts
On 05/23/06 02:34:35PM +0200, H. Wilmer wrote: Jim Crilly wrote: More stuff is configurable without a recompile. If I add/change hardware I don't have to do anything unless it's something required for booting and even then updating my initrd is simple. And I have run into cases where reloading modules will fix things, Ok, that are advantages to be made use of. But when hardware is not about to be changed and it's for a server that should just run the way it is reliably, what's the advantage of using modules for things required to boot anyway? MOTT, you could not even unload those modules. Even with servers there's a good chance you'll have to replace hardware and with the way companies tend to change chipsets and revisions without changing names it's still safer to just use modules. IMO You don't gain anything by compiling them in statically. I'm looking at it from the other direction, with initrd so easy to create, what's the advantage of not using modules? Jim. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: counting scsi hosts
Jim Crilly wrote: anything by compiling them in statically. I'm looking at it from the other direction, with initrd so easy to create, what's the advantage of not using modules? Ok, maybe it's just me thinking that I gain reliability whith some things compiled in and others not, in an attempt to take advantage of both approaches :) GH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: counting scsi hosts
On 05/23/06 04:42:26PM +0200, H. Wilmer wrote: Jim Crilly wrote: anything by compiling them in statically. I'm looking at it from the other direction, with initrd so easy to create, what's the advantage of not using modules? Ok, maybe it's just me thinking that I gain reliability whith some things compiled in and others not, in an attempt to take advantage of both approaches :) GH Not in any way that I can think of, the only thing it does is simplify booting a very little bit by not requiring an initrd. Jim. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: counting scsi hosts
Jim Crilly wrote: There's no such module; I think SCSI support is compiled into the kernel. That would probably be a valid assumption. Yeah, I'd say I did that :) Well to even attempt reloading anything you need it as a module, infact I prefer to make everything possible a module and use an initrd. But in this case it wouldn't make a difference since you can't umount the filesystem to be able to reload the module anyway. True --- and then, what's the advantage of using so many modules? If something is compiled into the kernel, there cannot be any trouble with an inability to load it. So I prefer to compile in everything that is required anyway to get things running and cannot be removed. GH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: counting scsi hosts
On 05/22/06 01:51:37PM +0200, H. Wilmer wrote: Jim Crilly wrote: There's no such module; I think SCSI support is compiled into the kernel. That would probably be a valid assumption. Yeah, I'd say I did that :) Well to even attempt reloading anything you need it as a module, infact I prefer to make everything possible a module and use an initrd. But in this case it wouldn't make a difference since you can't umount the filesystem to be able to reload the module anyway. True --- and then, what's the advantage of using so many modules? If something is compiled into the kernel, there cannot be any trouble with an inability to load it. So I prefer to compile in everything that is required anyway to get things running and cannot be removed. GH More stuff is configurable without a recompile. If I add/change hardware I don't have to do anything unless it's something required for booting and even then updating my initrd is simple. And I have run into cases where reloading modules will fix things, of course it's not possible for a few things like the filesystem and store driver of the root fs, but most other things can be reloaded if you kill the processes using them. I've had a number of times where reloading a NIC driver reset the NIC and fixed a problem and I've had to switch between ALSA and OSS sound drivers more than I'd like to admit. I don't see the benefit of compiling things in statically, you're limiting yourself too much that way IMO. Jim. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: counting scsi hosts
Jim Crilly wrote: Reloading a SCSI host driver (i.e. gdth, aic7xxx, etc) will increase the counter, reloading the SCSI core itself (scsi_mod) will reset the counter back to zero. There's no such module; I think SCSI support is compiled into the kernel. I would also have compiled the gdth support in, but unfortunately it was only possible to compile it as a module. That in turn required to use an initrd.image :( Are you sure you're using gdth for your root? I thought it was just for SCSI controllers, I didn't know any SATA controllers used chipsets supported by that driver. Yes, the Vortex is an SATA RAID controller and needs the gdth module: :02:02.0 SCSI storage controller: Adaptec ASC-29320A U320 (rev 10) :03:01.0 RAID bus controller: ICP Vortex Computersysteme GmbH GDT NEWRX There are no other disks than those attached to the RAID controller in the server. The only device on the Adaptec is a tape changer. I can recommend the Vortex controller, no problems with it in about two years. It's running a RAID5, 1TB on 4 disks plus one spare. If a disk fails, it will beep, so you _will_ notice. You replace the disk and that's all. --- I've had a disk failing in another server that also has a Vortex after about 3 months. It beeped and kicked in the spare; the replaced disk is now the spare, so it gets away with only one rebuild. 3wares are a little cheaper and work also (no problems except for a disk starting to fail in about 3 years, running RAID1 with two IDE disks), but they don't have a beeper. A beeper is definitely worthwhile. GH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: counting scsi hosts
On 05/19/06 01:45:34PM +0200, H. Wilmer wrote: Jim Crilly wrote: Reloading a SCSI host driver (i.e. gdth, aic7xxx, etc) will increase the counter, reloading the SCSI core itself (scsi_mod) will reset the counter back to zero. There's no such module; I think SCSI support is compiled into the kernel. That would probably be a valid assumption. I would also have compiled the gdth support in, but unfortunately it was only possible to compile it as a module. That in turn required to use an initrd.image :( Well to even attempt reloading anything you need it as a module, infact I prefer to make everything possible a module and use an initrd. But in this case it wouldn't make a difference since you can't umount the filesystem to be able to reload the module anyway. Are you sure you're using gdth for your root? I thought it was just for SCSI controllers, I didn't know any SATA controllers used chipsets supported by that driver. Yes, the Vortex is an SATA RAID controller and needs the gdth module: :02:02.0 SCSI storage controller: Adaptec ASC-29320A U320 (rev 10) :03:01.0 RAID bus controller: ICP Vortex Computersysteme GmbH GDT NEWRX There are no other disks than those attached to the RAID controller in the server. The only device on the Adaptec is a tape changer. I can recommend the Vortex controller, no problems with it in about two years. It's running a RAID5, 1TB on 4 disks plus one spare. If a disk fails, it will beep, so you _will_ notice. You replace the disk and that's all. --- I've had a disk failing in another server that also has a Vortex after about 3 months. It beeped and kicked in the spare; the replaced disk is now the spare, so it gets away with only one rebuild. 3wares are a little cheaper and work also (no problems except for a disk starting to fail in about 3 years, running RAID1 with two IDE disks), but they don't have a beeper. A beeper is definitely worthwhile. GH I was under the false impression that the gdth driver was just for some older legacy cards, the card definitely sounds nice I'll have to consider one next time I need a RAID controller. Jim. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: counting scsi hosts
Jim Crilly wrote: It seems to be normal, but I'd probably still say it's a bug in the SCSI system. It is possible to reset the number by reloading the scsi_mod module, but you have to umount all of the SCSI filesystems to do that so it's not a great solution. Unloading the SCSI module is what I did, and the counter is increased each time I reload the module. But there's also the gdth module for the SATA RAID controller, generating SCSI devices, which cannot be unloaded unless the server could run diskless ... GH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: counting scsi hosts
On 05/18/06 02:41:31PM +0200, H. Wilmer wrote: Jim Crilly wrote: It seems to be normal, but I'd probably still say it's a bug in the SCSI system. It is possible to reset the number by reloading the scsi_mod module, but you have to umount all of the SCSI filesystems to do that so it's not a great solution. Unloading the SCSI module is what I did, and the counter is increased each time I reload the module. But there's also the gdth module for the SATA RAID controller, generating SCSI devices, which cannot be unloaded unless the server could run diskless ... GH Reloading a SCSI host driver (i.e. gdth, aic7xxx, etc) will increase the counter, reloading the SCSI core itself (scsi_mod) will reset the counter back to zero. Are you sure you're using gdth for your root? I thought it was just for SCSI controllers, I didn't know any SATA controllers used chipsets supported by that driver. Jim. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: counting scsi hosts
Goswin von Brederlow wrote: when unloading and reloading SCSI modules, the number of SCSI hosts is increased like this: Also happens on usb every time you unplug and replug a harddisk. Very anoying. Thanks! At last I'm still on the save side since it's normal. GH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: counting scsi hosts
On 05/17/06 01:04:59PM +0200, H. Wilmer wrote: Goswin von Brederlow wrote: when unloading and reloading SCSI modules, the number of SCSI hosts is increased like this: Also happens on usb every time you unplug and replug a harddisk. Very anoying. Thanks! At last I'm still on the save side since it's normal. GH It seems to be normal, but I'd probably still say it's a bug in the SCSI system. It is possible to reset the number by reloading the scsi_mod module, but you have to umount all of the SCSI filesystems to do that so it's not a great solution. Jim. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
counting scsi hosts
Hi, when unloading and reloading SCSI modules, the number of SCSI hosts is increased like this: May 16 11:52:58 prometheus kernel: st: Unloaded. May 16 11:54:56 prometheus kernel: PCI: Enabling device :02:02.0 (0016 - 0017) May 16 11:54:56 prometheus kernel: scsi3 : Adaptec AIC79XX PCI-X SCSI HBA DRIVER, Rev 1.3.11 May 16 11:54:56 prometheus kernel: Adaptec 29320A Ultra320 SCSI adapter May 16 11:54:56 prometheus kernel: aic7901: Ultra320 Wide Channel A, SCSI Id=7, PCI 33 or 66Mhz, 512 SCBs May 16 11:54:56 prometheus kernel: May 16 11:56:46 prometheus kernel: (scsi3:A:0): 80.000MB/s transfers (40.000MHz, 16bit) May 16 11:56:46 prometheus kernel: (scsi3:A:1): 80.000MB/s transfers (40.000MHz, 16bit) May 16 11:56:49 prometheus kernel: Vendor: EXABYTE Model: VXA 1x10 1U Rev: A102 May 16 11:56:49 prometheus kernel: Type: Medium Changer ANSI SCSI revision: 04 May 16 11:56:49 prometheus kernel: Vendor: EXABYTE Model: VXA-2 Rev: 100E May 16 11:56:49 prometheus kernel: Type: Sequential-Access ANSI SCSI revision: 02 May 16 11:57:49 prometheus kernel: Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0 May 16 11:57:49 prometheus kernel: Attached scsi generic sg1 at scsi3, channel 0, id 0, lun 0, type 8 May 16 11:57:49 prometheus kernel: Attached scsi generic sg2 at scsi3, channel 0, id 1, lun 0, type 1 May 16 11:57:53 prometheus kernel: st: Version 20040403, fixed bufsize 32768, s/g segs 256 May 16 11:57:53 prometheus kernel: Attached scsi tape st0 at scsi3, channel 0, id 1, lun 0 May 16 11:57:53 prometheus kernel: st0: try direct i/o: yes (alignment 512 B), max page reachable by HBA 134217727 May 16 11:59:17 prometheus kernel: st: Unloaded. May 16 11:59:33 prometheus kernel: PCI: Enabling device :02:02.0 (0016 - 0017) May 16 11:59:33 prometheus kernel: scsi4 : Adaptec AIC79XX PCI-X SCSI HBA DRIVER, Rev 1.3.11 May 16 11:59:33 prometheus kernel: Adaptec 29320A Ultra320 SCSI adapter May 16 11:59:33 prometheus kernel: aic7901: Ultra320 Wide Channel A, SCSI Id=7, PCI 33 or 66Mhz, 512 SCBs May 16 11:59:33 prometheus kernel: May 16 11:59:48 prometheus kernel: (scsi4:A:0): 80.000MB/s transfers (40.000MHz, 16bit) May 16 11:59:49 prometheus kernel: (scsi4:A:1): 80.000MB/s transfers (40.000MHz, 16bit) May 16 11:59:52 prometheus kernel: Vendor: EXABYTE Model: VXA 1x10 1U Rev: A102 May 16 11:59:52 prometheus kernel: Type: Medium Changer ANSI SCSI revision: 04 May 16 11:59:52 prometheus kernel: Vendor: EXABYTE Model: VXA-2 Rev: 100E May 16 11:59:52 prometheus kernel: Type: Sequential-Access ANSI SCSI revision: 02 May 16 12:00:01 prometheus /USR/SBIN/CRON[29646]: (root) CMD (setfacl -R -m o::rwx /share/data/archiv/Ablage_CV/ setfacl -R -m d:o::rwx /share/data/archiv/Ablage_CV/ setfacl -R -m u::rwx /share/data/archiv/Ablage_CV/) May 16 12:00:15 prometheus kernel: Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0 May 16 12:00:15 prometheus kernel: Attached scsi generic sg1 at scsi4, channel 0, id 0, lun 0, type 8 May 16 12:00:15 prometheus kernel: Attached scsi generic sg2 at scsi4, channel 0, id 1, lun 0, type 1 At some time, a limit (like 32?) might prevent me from reloading the modules and force me to reboot. Is it normal that the kernel (2.6.9 SMP) or the modules seems to think that the number of SCSI hosts is increasing though they aren't? Is there a way to reuse host numbers that have been used previously? GH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: counting scsi hosts
listrcv [EMAIL PROTECTED] writes: Hi, when unloading and reloading SCSI modules, the number of SCSI hosts is increased like this: Also happens on usb every time you unplug and replug a harddisk. Very anoying. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]