why disk info gets printk'ed twice?

why disk info gets printk'ed twice?

[Michael Tokarev]

Every dmesg users provide contains double info
about identification of [scsi,ata,..] disk drives
found in the system.  Here's mine:

scsi 2:0:0:0: Direct-Access     ATA      ST3808110AS      n/a  PQ: 0 ANSI: 5
loading module sd_mod
sd 2:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
sd 2:0:0:0: [sda] Write Protect is off
sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
sd 2:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
sd 2:0:0:0: [sda] Write Protect is off
sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 >
sd 2:0:0:0: [sda] Attached SCSI disk

Why the lines beginning with "sd 2:0:0:0:" gets duplicated?
Can this be fixed somehow?

All the messages are in drivers/scsi/sd_mod.c, printed out by
functions called from within sd_revalidate_disk().  This routine
gets called from two contexts:
 sd_store_cache_type(), which is a sysfs thing, it seems, and
 sd_probe(), which gets called from .probe method of scsi_driver

So it seems to me that scsi_driver.probe() method gets called
twice for some reason...

This question has been asked several times, but I don't recall
any answers to it.

Thanks.

/mjt

Re: why disk info gets printk'ed twice?

[David Miller]

From: Michael Tokarev <mjt@tls.msk.ru>
Date: Tue, 23 Oct 2007 01:37:28 +0400

> So it seems to me that scsi_driver.probe() method gets called
> twice for some reason...
> 
> This question has been asked several times, but I don't recall
> any answers to it.

I seem to remember that this happens as a side effect of
how domain-validation works and that it's not easy to get
rid of.

Re: why disk info gets printk'ed twice?

[Matthew Wilcox]

On Tue, Oct 23, 2007 at 01:37:28AM +0400, Michael Tokarev wrote:
> This question has been asked several times, but I don't recall
> any answers to it.

Your google-fu is weak, padawan.

http://www.ussg.iu.edu/hypermail/linux/kernel/0508.2/0471.html

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."