Date: Wed, 17 Feb 2010 22:31:37 +0100 From: Florian Kruegl <smeagle@bsdler.de> To: freebsd-mips@freebsd.org Subject: Re: rspro board and mounting root from SD Message-ID: <1266442297.2149.30.camel@brain.lan.terror.local> In-Reply-To: <20100215.234202.119882392285831214.imp@bsdimp.com> References: <d763ac661002042128g4eec226fue4011dc3195a86b@mail.gmail.com> <1265398292.2149.3.camel@brain.lan.terror.local> <d763ac661002152224i7310a0d3q52bd93b64428297a@mail.gmail.com> <20100215.234202.119882392285831214.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On Mon, 2010-02-15 at 23:42 -0700, M. Warner Losh wrote: > In message: <d763ac661002152224i7310a0d3q52bd93b64428297a@mail.gmail.com> > Adrian Chadd <adrian.chadd@gmail.com> writes: > : Thanks, I'll just (ab)use this method of delaying the root mounting > : hackery until the umass child gets a chance to finishing probing. > : it's definetly a rude hack, given the fact that there is already another hack in place doing the same make it even pointless... > > : A "better" solution (eg enumerating which USB children need to finish > : probing and adding them in with relevant notification) may take a bit > : more hackery than I was hoping for. Maybe slicing something hackish > : into CAM would be evil but more generic.. > > There is something hackish already in CAM, sadly. kern.cam.boot_delay > looks like it defaults to '0' but you could set it to 4 I think to get > the same net-net as this patch. I tried getting in deeper, but the problem seems that for a short period there is no root lock pending as usb has already finished and cam has not yet set the lock. I dislike the approach it was annoying when SCSI devices where installed, but it wanted to get it up and running as quick as possible. However there is currently not much use in booting from SD as kernel spits out masses of geom 'messages' =================================================================== g_vfs_done():da0s1a[WRITE(offset=81920, length=8192)]error = 5 g_vfs_done():da0s1a[WRITE(offset=397312000, length=8192)]error = 5 g_vfs_done():da0s1a[WRITE(offset=49152, length=8192)]error = 5 =================================================================== this has kind of shifted, 4 weeks ago there where plenty of USB errors. The sad thing is that I now seems to corrupt data. or at least reads are failing: =================================================================== Trying to mount root from ufs:/dev/da0s1a Invalid time in real time clock. Check and reset the date immediately! (da0:umass-sim0:0:0:0): AutoSense failed g_vfs_done():da0s1a[READ(offset=28352512, length=8192)]error = 5 g_vfs_done():da0s1a[READ(offset=28262400, length=90112)]error = 5 Setting hostuuid: 30cfc620-19d2-11df-9ee8-000000004661. Setting hostid: 0xfbd78019. Entropy harvesting: interrupts ethernet point_to_point(da0:umass-sim0:0:0:0): AutoSense failed g_vfs_done():da0s1a[READ(offset=24690688, length=65536)]error = 5 g_vfs_done():da0s1a[READ(offset=27156480, length=1024)]error = 5 vnode_pager_getpages: I/O read error input in flex scanner failed (da0:umass-sim0:0:0:0): AutoSense failed g_vfs_done():da0s1a[READ(offset=204086272, length=1024)]error = 5 g_vfs_done():da0s1a[READ(offset=172403712, length=4096)]error = 5 (da0:umass-sim0:0:0:0): AutoSense failed g_vfs_done():da0s1a[READ(offset=113606656, length=8192)]error = 5 kickstart. Starting file system checks: =================================================================== rc.d scripts fail with premature end of script errors and situation gets worse when FS is mounted rw. System fails o remount rw due to device busy. when requesting a sync the kernel keeps complaining about the same ranges. Will try with current version as soon as build world finishes. > > I've talked through a bunch of solutions with Scott, and I think we > concluded that the right approach was for CAM to evolve a little. > As SIMs are discovered, they are added to a list of things to probe > (if their transport is polled, rather than self-discovered). Then, > after the interrupt hooks are done, it would run through the list > polling those SIMs. Once that's done, we'd release the hounds, errr, > I mean we'd allow mount_root to proceed. i thing allowing root mount is where most problems start ;) Flo > > Warner >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1266442297.2149.30.camel>