Date: Sat, 27 Jul 1996 17:53:00 +0000 () From: James Raynard <fqueries@jraynard.demon.co.uk> To: "Keith Beattie[SFSU Student]" <beattie@george.lbl.gov> Cc: questions@freebsd.org Subject: Re: vnode_pager_input: I/O read error Message-ID: <199607271753.RAA03268@jraynard.demon.co.uk> In-Reply-To: <199607270151.SAA28291@george.lbl.gov> from "Keith Beattie[SFSU Student]" at Jul 26, 96 06:51:12 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > I just compiled a new kernel and I'm now having some serious > problems... > > vnode_pager_input: I/O read error > vm_fault: pager input (probably hardware) error, PID 243 failure > pid 243: cc1: uid 0: exited on signal 11 > sd0(aha0:0:0): ILLEGAL REQUEST asc:24,0 Invalid field in CDB > vnode_pager_input: I/O read error > vm_fault: pager input (probably hardware) error, PID 612 failure > pid 612: cc1: uid 1000: exited on signal 11 > sd0(aha0:0:0): ILLEGAL REQUEST asc:24,0 Invalid field in CDB > sd0(aha0:0:0): ILLEGAL REQUEST asc:24,0 Invalid field in CDB > vnode_pager_input: I/O read error > vm_fault: pager input (probably hardware) error, PID 638 failure > pid 638: gdb: uid 1000: exited on signal 11 > sd0(aha0:0:0): ILLEGAL REQUEST asc:24,0 Invalid field in CDB > pid 644: emacs-19.29: uid 1000: exited on signal 11 Getting signal 11's for no apparent reason is a classic sign of a hardware problem, most commonly a bad SIMM, although they can also be caused by problems with cache or the motherboard. > I have trouble believing that it was a coincedence that I just > happened to get some new hardware failure the exact moment I tried > running a new kernel. It seems that they are related somehow. I've > used this same hardware for running Linux, compiling large programs > there like emacs and new kernels and most recently installing FreeBSD > 2.1.0 running large compiles like fvwm, xemacs, and now, a new > kernel. It does seem a bit of a strange coincidence. You probably had a marginal component that happened to lose it at that moment. It's also possible that this may be the first time the bad address has been used, although there certainly seem to have been plenty of opportunities for it to be accessed. The best thing to do now is probably to try swapping around SIMMs, if you have any spare ones around.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607271753.RAA03268>