Re: [RFT] #2 Support for ~2144 SCSI discs, scsi_debug

Richard Gooch
2001-08-10T20:30:55Z

Douglas Gilbert writes:
> Richard Gooch wrote:
> >
> > Douglas Gilbert writes:
>
> > > $ ls -l /devfs/scsi/host46/bus0/target0/lun0/*
> > > brw------- 1 root root 114, 16 Dec 31 1969
> > > /devfs/scsi/host46/bus0/target0/lun0/disc
> > > brw------- 1 root root 114, 17 Dec 31 1969
> > > /devfs/scsi/host46/bus0/target0/lun0/part1
> > > brw------- 1 root root 114, 18 Dec 31 1969
> > > /devfs/scsi/host46/bus0/target0/lun0/part2
> > > brw------- 1 root root 114, 19 Dec 31 1969
> > > /devfs/scsi/host46/bus0/target0/lun0/part3
> > >
> > > Note the large major device number that devfs is pulling
> > > from the unused pool. Devfs makes some noise when
> > > 'rmmod scsi_debug' is executed but otherwise things looked
> > > ok.
> >
> > What was the message?
>
> After several seconds of silence, lots of these appeared:
> devfs_dealloc_unique_number(): number 128 was already free
> devfs_dealloc_unique_number(): number 128 was already free

I'm not able to debug this for the time being. Could you poke around
and figure out what's happening? The first thing to check for is to
see whether block major 128 was even allocated in the first
place. Check /proc/devices to see (make sure you don't pass devfs=only
at the boot line).

Next step is to hack in drivers/scsi/sd.c:sd_alloc_majors() and
sd_dealloc_majors() and add printk() calls. Is it possible
sd_dealloc_majors() is being called more than once?

Is 128 the only major number that it complains about? Any other
bitching and moaning?