[lkml]   [2000]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [2.4.0-test9-pre5] SCSI still broken, trident/mixer still broken
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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.138 / U:1.956 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site