RE: FreeBSD-AMD64 on Xeon MP

[Don Bowman]

From Ivan Voras
 Don Bowman wrote:
 
  I tried putting a call to uhci_dumpregs() there, it hangs as well.
So
  my assumption Is that a read to 0x3080 is hanging.
 
  Anyone have any suggestions?
 
 If the same thing that worked for me works for you (booting Linux
 before soft-rebooting into FreeBSD) than it would look like something
 isn't initialized right.

I am focusing in on SMM emulation.
http://www.ussg.indiana.edu/hypermail/linux/kernel/0407.3/0688.html
suggests something to me.

What if I am executing this on a processor other than the boot
processor,
and the SMM code doesn't expect this?

I'm not sure where I would try this patch in freebsd, but it seems
promising.

Ie I read 0xe090. This trips SMM for legacy(?). SMM is entered, does 
something, corrupts, leaves, and then a few instructions later I crash.

The suggested workaround for this (different machine and OS) is to
disable
the legacy mode. FreeBSD seems to do this already I think, calling:
pci_write_config(self, PCI_LEGSUP, PCI_LEGSUP_USBPIRQDEN, 2); in
uhci_pci_attach()


___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to [EMAIL PROTECTED]

FreeBSD-AMD64 on Xeon MP

[Don Bowman]

On Mon Aug 11 21:23:58 UTC 2008 John Baldwin wrote:
On Monday 11 August 2008 11:25:01 am Michael Fuckner wrote:
  Hi all,
  
  I try to run FreeBSD-7-AMD64 on a Quad Xeon (Xeon MP 7320) and 32GB
RAM. 
  The Board is a X7QC3 by supermicro and the installation is done on 
  another system, updated and plugged to this system. So I have a
drive 
  with 7-STABLE compiled today.
 
  The last line I see from dmesg is vga0- then the system freezes.
 
  Anyone using a similar configuration or knows what could be wrong? I

  still have some days left to play with it, before this box gets
shipped 
  to the customer.

 It is probably waiting for a config intr hook to complete.  rwatson@
recently 
 added some code to HEAD to help with debugging hangs there.  That
patch 
 probably applies directly to 7.x and would be helpful in determining
what is 
 hanging.

So I have debugged this down (same board), using 32-bit kernel.
I have found it is hanging reading from the UHCI controller (register
0x10).
I am using HEAD.

In uhci_root_ctrl_start(), in case C(UR_GET_STATUS,
UT_READ_CLASS_OTHER):, it does:
x = UREAD2(sc, port);

now, this translates into a read from 0x3090 [UHCI base address is
0x3080, offset
is 0x10 for the PORTSC0 register.

I debugged this down by putting printf() in. I can't really fathom why
that read would hang, does anyone have a suggestion on where to go next
debugging?

The chipset on this board is 631xESB/632xESB ICH.

I tried putting a call to uhci_dumpregs() there, it hangs as well. So my
assumption
Is that a read to 0x3080 is hanging.

Anyone have any suggestions?

System has 4 XEON MP processors, Intel 7300 chipset, 1GB of RAM,
motherboard is described
http://www.supermicro.com/products/motherboard/Xeon7000/7300/X7QC3.cfm
The IPMI is not installed.



___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to [EMAIL PROTECTED]