Simon Kirby wrote:
>
> On Thu, Sep 21, 2000 at 01:12:27PM -0400, Douglas Gilbert wrote:
>
> > Interesting. 'cat /proc/scsi/scsi' should show the same
> > devices as 'cat /proc/scsi/sg/device_strs' [and
> > 'cat /proc/scsi/sg/devices']. If not, then the SCSI
> > mid-level is not calling sg_detect() [in sg.c] for
> > all new scsi devices detected by the mid-level.
> >
> > The sg_detect() routine is silent for all devices that
> > are "owned" by other upper level drivers (i.e. disks,
> > cdroms and tapes) but outputs a line for any other
> > scsi type (e.g. scanners which are scsi type 6).
>
> I didn't fiddle with it too much, but I added a printk to sg_detect and
> verified it was not getting called at all. I notice now, however, that I
> don't even have a /proc/scsi/sg. Does that mean it's not getting
> initialized at all? CONFIG_CHR_DEV_SG=y, assuming that's what needs to
> be set (config didn't change between kernel versions).
I do nearly all of my testing with sg as a module.
So this looks like (another recent) breakage.
It is beginning to look like the sg driver is not
(properly) initialized when it is built into the
kernel. Perhaps you could put a printk in
sg_init() and sg_attach() to see if they are called.
> At one point before I followed some of the debug/logging commands listed
> at the top of sg.c and got an Oops as well...
Seems as though I've got a lot of retesting to do.
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:25 EST