Date: Fri, 10 Feb 2006 11:29:02 +0100 (CET) From: Oliver Fromme <olli@lurza.secnetix.de> To: freebsd-stable@FreeBSD.ORG Subject: Re: USB Flash reader under RELENG_6: force GEOM rescan Message-ID: <200602101029.k1AAT2DA056950@lurza.secnetix.de> In-Reply-To: <20060209210748.L87003@woozle.rinet.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Dmitry Morozovsky <marck@rinet.ru> wrote: > On Thu, 9 Feb 2006, Oliver Fromme wrote: > OF> Dmitry Morozovsky <marck@rinet.ru> wrote: > OF> > I have USB multi-LUN flash reader which is identified under RELENG_6 as > OF> > umass0: GENERIC USB Storage Device, rev 2.00/1.8a, addr 2 > OF> > da0 at umass-sim0 bus 0 target 0 lun 0 > OF> > da0: <GENERIC USB Storage-CFC I19B> Removable Direct Access SCSI-0 device > OF> > da0: 40.000MB/s transfers > OF> > da0: Attempt to query device size failed: NOT READY, Medium not present > OF> > [...] > OF> > when I insert flash into one of slots, I need to rescan da* providers, as > OF> > usually there is slice1 which should be mounted. > OF> > OF> The problem is that devfs isn't "triggered", therefore it > OF> doesn't notice that a new device appeared, so no new nodes > OF> are created. > > Yes I understand this. What I currently fail to understand ;-) > is why devfs isn't triggered on read requests Because a read request cannot change the partition table, so devfs doesn't bother to look for new partitions. However, when you open the raw device for _writing_ (as the proposed dd command does), then it is possible that the partition table has changed, so devfs looks at it (actually the GEOM code, I think), detects the new partitons, and creates nodes in /dev. (That explanation is somewhat simplified, but basically that's the reason.) > OF> The following should work as well, without giving an error: > OF> > OF> dd if=/dev/null of=/dev/da0 count=0 > OF> > OF> It opens the device for writing (without actually writing > OF> anything) and immediately closes it again, which causes > OF> devfs to be "triggered". > > Aha, actually, it works. Thanks. It's also more secure. First, /dev/null immediately returns EOF, so there's no danger to overwrite anything on /dev/da0, and second, count=0 also prevents anything from being written. > OF> I don't think there's currently a real fix for the problem, > OF> I'm afraid. > > Before any kind of 'real fix' we should determine 'The Right Way[tm]' I > think... Concerning the SCSI and CAM code I'm not an expert, but I think it should be possible to nudge devfs when a rescan has detected a new device. The freebsd-scsi list might be a better place to discuss that issue. Although, maybe other subsystems (like ATA) are also affected by the problem. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200602101029.k1AAT2DA056950>