Tom Oehser wrote:
>
> Bluntly, fixing it to work should not be the highest priority.
>
> Having an error message when it fails is much more important.
>
> Now, it gives no indication there is a problem. Silent failure.
>
> Is there some reason that it can't log a message? Is this in
> sr.c where it looks like it just loops up to the max number of
> seen-at-boot + SR_EXTRA_DEVS, and it needs to do more to check if it has
> more, or is it something in hosts.c or scsi.c? Can someone help point me
> in the right direction where the error message should be created?
>
> -Tom
>
> On Tue, 12 Oct 1999, Georg P. Israel wrote:
>
> > Date: Tue, 12 Oct 1999 17:14:59 +0200 (CEST)
> > From: "Georg P. Israel" <[EMAIL PROTECTED]>
> > Reply-To: "Georg P. Israel" <[EMAIL PROTECTED]>
> > To: Jakub Jelinek <[EMAIL PROTECTED]>
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: 45 missing CDROM devices
> >
> > It would be nice to have an option in the kernel config scripts,
> > that does allow us to change these hard limits.
> > That way, we don't have to care about the race conditions,
> > and users that don't need it don't have to waste there resources.
> >
> >
> > Georg
> >
> > On 12-Oct-99 Jakub Jelinek wrote:
> > >> ...
> > >
> > > Going to kdev_t being a pointer to a structure.
> > > Then all these hard limits are non-issue. This statical limit just comes
> > > from the fact that so far Linux uses static one and two dimensional arrays
> > > for block devices which have to be sized early and due to races cannot be
> > > easily resized.
> > >
> > >>
> > >
> > > Edit drivers/scsi/hosts.h and s/2/50/.
> > >
> > > Cheers,
> > > Jakub
> >
In this case one of the 4 "high" level SCSI device drivers
(i.e. sd, st, sr or sg) detects 'dev_max' being exceeded in
the appropriate *_attach() call and returns 1 to indicate
a failure (0 for ok). There are other reasons why an
*_attach() may fail but none of these 4 routines output any
explanation to the log (I just added a printk() to the sg
driver).
To catch it in one place then scsi.c scan_scsis() line 591
(in 2.3.21) looks like the place:
if (sdtpnt->attach) {
(*sdtpnt->attach) (oldSDpnt); /* line 591 */
if (oldSDpnt->attached) {
scsi_build_commandblocks(oldSDpnt);
if (0 == oldSDpnt->has_cmdblocks) {
printk("scan_scsis: DANGER, no command blocks\n");
/* What to do now ?? */
}
}
That indirect function call on line 591 should test it's
return value. If it is non-zero then it could output a
warning to the log that an attach for device host:channel:id:lun
had been rejected.
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
