Date: Mon, 22 Aug 2005 15:18:42 -0400 From: John Baldwin <jhb@FreeBSD.org> To: freebsd-current@freebsd.org Cc: "Kenneth D. Merry" <ken@freebsd.org>, Jung-uk Kim <jkim@freebsd.org> Subject: Re: BTX problems Message-ID: <200508221518.43770.jhb@FreeBSD.org> In-Reply-To: <200508221319.31025.jkim@FreeBSD.org> References: <20050813221234.GA23162@nargothrond.kdm.org> <20050822163306.GA81213@nargothrond.kdm.org> <200508221319.31025.jkim@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 22 August 2005 01:19 pm, Jung-uk Kim wrote: > On Monday 22 August 2005 12:33 pm, Kenneth D. Merry wrote: > > On Mon, Aug 22, 2005 at 12:16:51 -0400, Jung-uk Kim wrote: > > > On Monday 22 August 2005 11:57 am, Kenneth D. Merry wrote: > > > > On Mon, Aug 22, 2005 at 11:37:25 -0400, Jung-uk Kim wrote: > > > > > On Saturday 20 August 2005 01:02 am, Kenneth D. Merry wrote: > > > > > > On Tue, Aug 16, 2005 at 13:39:48 -0400, John Baldwin wrote: > > > > > > > There haven't been a whole lot of changes. My guess > > > > > > > would be the recently added smbios support. You can > > > > > > > probably just comment out the call to smbios_detect() in > > > > > > > sys/boot/i386/loader/main.c as a simple test for that. > > > > > > > It could also possibly be the multiple console support in > > > > > > > which case it would be easiest to just step your sys/boot > > > > > > > tree back using CVS. The good news is that sys/boot is > > > > > > > largely self-contained so you can step it back while > > > > > > > keeping the rest of the tree up to date for testing > > > > > > > purposes at least. > > > > > > > > > > > > Thanks for the tips! > > > > > > > > > > > > Commenting out smbios_detect() did the trick. The loader > > > > > > works fine after that. > > > > > > > > > > > > So now what? Is there a way to fix it so it won't crash on > > > > > > my system? > > > > > > > > > > So, I guess I broke it, then. Can you install > > > > > ports/sysutils/dmidecode and send me dmidecode output? > > > > > > > > Sure, here it is. > > > > > > Okay, it looks good so far. Can you do: > > > > > > dd if=/dev/mem of=dmi.dat bs=1 count=1534 skip=984640 > > > dd if=/dev/mem of=smbios.dat bs=1 count=65536 skip=983040 > > > > > > and send me dmi.dat and smbios.dat, please? > > > > Here they are. > > It's very strange. It seems SM entry and DMI structures are all sane. > I don't understand why it happens. :-( I just wrote a qucik-and-dirty > userland wrapper for smbios.c, which is attached. > > SMBIOS entry: 0x000f00a0 > DMI structures: length = 1534, paddr = 0x000f0640, count = 49 > smbios.bios.vendor="American Megatrends Inc." > smbios.bios.version="0700xx " > smbios.bios.reldate="11/14/2001" > smbios.system.maker="Supermicro" > smbios.system.product="P3TDE6" > smbios.system.version="1234567890" > smbios.planar.maker="Supermicro" > smbios.planar.product="P3TDE6" > smbios.planar.version="1234567890" > smbios.chassis.maker="Supermicro" > smbios.chassis.version="P3TDE6" > > Is it possible that PTOV() is not working somehow??? I need help > here. Perhaps give ken@ a patch with some printf's added to figure out how far it gets into smbios_detect() before it dies? -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200508221518.43770.jhb>