My problem:
I want to connect/disconnect an external scsi-device (Fujitsu MOD)
to/from my aha2940 whithout rebooting.
Therefore it's necessary to rescan the bus.
man 4 scsi
tells me something about SCIOCREPROBE but nothing about
how to use ist :(
("can be applied against any scsi device" - to dump to use this hint)
Will I have to write a C-program? I don't think so. Every external
ZIP/MO/JAZZ, ... user should have this problem and it's surely
already solved. Just tell me. PLEASE.
bye
Frank
scsi -r -f /dev/sd0
Works, for example. I think any SCSI device will do in place of
/dev/sd0, that's just what I use.
Jordan
What if you didn't have any scsi devices attached when you booted?
-- Richard
--
Because of all the junk e-mail I receive, all e-mail from .com sites is
automatically sent to a file which I only rarely check. If you want to mail
me from a .com site, please ensure my surname appears in the headers.
Here the error message:
bash# scsi -r -f /dev/od0
scsi: unable to open device /dev/od0: Device not configured
If the drive ist connected and powered while booting there's no problem.
My problem ist to get a drive connected without booting.
Once again:
in linux just say:
echo "scsi remove-single-device 0 0 3 0" > /proc/scsi/scsi
to remove 3rd device (controller 0, bus 0, LUN 0)
echo "scsi add-single-device 0 0 3 0" > /proc/scsi/scsi
to add a device
in FreeBSD just forget it???
hmmm.
bye Frank
Try it with a SCSI device you *HAVE*, OK? :-)
> in FreeBSD just forget it???
No, just use it correctly. :)
--
- Jordan Hubbard
FreeBSD core team / Walnut Creek CDROM.
In article <349910D4...@freebsd.org>,
"Jordan K. Hubbard" <j...@FreeBSD.org> writes:
: Frank Heydlauf wrote:
[.....]
>> Here the error message:
>> bash# scsi -r -f /dev/od0
>> scsi: unable to open device /dev/od0: Device not configured
:
: Try it with a SCSI device you *HAVE*, OK? :-)
:
>> in FreeBSD just forget it???
:
: No, just use it correctly. :)
Which reminds me - (maybe Joerg knows the answer) should the
ficticious ``super'' scsi device (and -p) be removed from the
man page or is it ever likely to materialize.
I recall Joerg answering this question some years ago saying
that it was ``planned'' - but I can't be sure I remember correctly.
--
Brian <br...@Awfulhak.org> <br...@FreeBSD.org> <br...@OpenBSD.org>
<http://www.Awfulhak.org>
Don't _EVER_ lose your sense of humour !
According to Joerg (via email):
: As Brian Somers wrote:
:
: > [posted to c.u.b.f.m & cc'd to Joerg]
:
: (I'm lagging somewhat behind Usenet, so just mailed to you. Feel free
: to forward it.)
:
: > Which reminds me - (maybe Joerg knows the answer) should the
: > ficticious ``super'' scsi device (and -p) be removed from the
: > man page or is it ever likely to materialize.
:
: It is available, and has been for quite some years now. It's only not
: in the default kernel (should it be?). Just include the su and ssc
: pseudo-devices, and
:
: mknod /dev/scsisuper c 49 0
:
: It's supposed to work.
:
: --
: cheers, J"org
:
: joerg_...@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
: Never trust an operating system you don't have sources for. ;-)
No, not at all :-(
I definitely don't have this device when I boot.
Why should I rescan an existing device?
(jfyi: the device works properly if connected at boot-time)
bye
Frank
Because you don't have a valid "handle" to make the reprobe request with
then. I think you're suffering from a fundamental misunderstanding as
to how this works. :-)
> (jfyi: the device works properly if connected at boot-time)
I've no doubt that this is the case.
> Frank Heydlauf wrote:
> >
> > : > : Jordan K. Hubbard (j...@time.cdrom.com) wrote:
> > ...
> > : > : : scsi -r -f /dev/sd0
> > : > : :
> > : > : : Works, for example. I think any SCSI device will do in
> place of
> > : > : : /dev/sd0, that's just what I use.
> > : > :
> > : > : TNX for answering. I'll try ASAP.
> > : > :
> > : > OK, ASAP is now and it doesn't work. :'-(
> > : > (BTW I tested this some time ago with an other order of
> parameters and
> > : > it didn't work either ;)
> > : >
> > : > Here the error message:
> > : > bash# scsi -r -f /dev/od0
> > : > scsi: unable to open device /dev/od0: Device not configured
> > :
> > : Try it with a SCSI device you *HAVE*, OK? :-)
> >
> > No, not at all :-(
> >
> > I definitely don't have this device when I boot.
> > Why should I rescan an existing device?
>
> Because you don't have a valid "handle" to make the reprobe request
> with
> then. I think you're suffering from a fundamental misunderstanding as
>
> to how this works. :-)
>
I have the same problems, a tape with a VERY loud fan which I only need
each
weekend.
Am I right that I have to power on the tape during the boot process to
get it reprobed
every time I need it?
What about harddisks I connect from time to time? Did I have to reboot?
/gT/
No, you just need to power it up before you reprobe it with the scsi(8)
command - attempting to reprobe devices which are powered off is not a
very successful enterprise. :-)
> What about harddisks I connect from time to time? Did I have to reboot?
Not unless those hard disks contain kernels or root filesystems which
you need to boot from, no.
Again, you can use the scsi(8) command to reprobe all devices on a SCSI
bus if you have at least one active device to use as your handle. I
think the "super SCSI device" works for this too, without any devices
registered on the bus at all, but I've never used it since I always have
/dev/sd0 to use as a convenient handle.
> I have the same problems, a tape with a VERY loud fan which I only
> need each weekend. Am I right that I have to power on the tape
> during the boot process to get it reprobed every time I need it?
No. All you need is just _one_ hookup point into the SCSI driver.
That can be a successfully probed disk drive, or it should be possible
to include the su/ssc pseudo-devices, and create the magical
/dev/scsisuper (or /dev/ssc or whatever you call it) device. The idea
behind the latter is to provide a generic hookup point that is
independent of other actual devices.
What people are probably miscomprehending is, "scsi -r" does always
reprobe all SCSI busses on all controllers that were present at
boot-time. The -f <device> you have to supply is only needed to
specify the first chicken to get into the SCSI subsystem of the
kernel.
> What about harddisks I connect from time to time? Did I have to
> reboot?
Maybe, i think the slice code could get confused. Just try it.
>to include the su/ssc pseudo-devices, and create the magical
>/dev/scsisuper (or /dev/ssc or whatever you call it) device. The idea
>behind the latter is to provide a generic hookup point that is
>independent of other actual devices.
As I had the same problem several times in the past, I would really
like to see some advice how to install the super device. AFAIR there
is no entry in MAKEDEV and the manual page is not understandable.
It looks as if the super device is not maintained or not even
functional at all.
--
Dipl.-Math. Wilhelm Bernhard Kloke
Institut fuer Arbeitsphysiologie an der Universitaet Dortmund
Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 montags und dienstags
Danke f"ur den Hinweis, J"org.
That's ist. OK, works fine :-))
Hey, FreeBSD-Crew!
Would you please add an entry in the scsi-man-pages?
I think about something like:
scsi -f device -r:
_device_ can be any configured (already scanned) device.
EXAMPLE
scsi -r -f /dev/sd0
will rescan the bus and find any new connected device, i.e.
external ZIP/MOD or CD-Drive (hotplug).
(use Keywords ZIP, MOD, hotplug)
Bye and thanks for help.
My next 'project' will be 'getting a filesystem on a MO'
RingTFM ... disklabel,fdisk - hmmm I'll see...
man fdisk:
BUGS
The entire program should be made more user-friendly.
I fully agree ;)
bye again,
Frank
=As I had the same problem several times in the past, I would really
=like to see some advice how to install the super device. AFAIR there
=is no entry in MAKEDEV and the manual page is not understandable.
=It looks as if the super device is not maintained or not even
=functional at all.
From the /sys/i386/conf/majors.i386
...
49 ssc SCSI super device
...
But MAKEDEV should know about it... I'm going to try this right now...
-mi
--
"Windows for dummies"
> From the /sys/i386/conf/majors.i386
> ...
> 49 ssc SCSI super device
> ...
>
> But MAKEDEV should know about it... I'm going to try this right now...
Brian Somers has fixed MAKEDEV and scsi.8 in -current (the device is
now referred to as /dev/ssc).
> Hey, FreeBSD-Crew!
> Would you please add an entry in the scsi-man-pages?
Hmm, Brian has been touching it recently... Brian, care to do this,
too? ;)
> My next 'project' will be 'getting a filesystem on a MO'
> RingTFM ... disklabel,fdisk - hmmm I'll see...
>
> man fdisk:
> BUGS
> The entire program should be made more user-friendly.
>
> I fully agree ;)
BUGS
This program is obsolete unless you want to allow for
obsolete operating systems to share your valuable disk
space with FreeBSD.
:-)
Seriously: fdisk is not strictly mandatory. disklabel is, however,
for a UFS disk.
Done. I'll bring it into 2.2 in a few days.
[.....]