Date: Thu, 08 Jan 2009 15:56:09 +0100 From: Attila Nagy <bra@fsn.hu> To: Danny Braniss <danny@cs.huji.ac.il> Cc: freebsd-current@freebsd.org, peter@wemm.org Subject: Re: pxeboot does not work on Sun X4540 Message-ID: <49661409.4090600@fsn.hu> In-Reply-To: <E1LKoYw-000A3a-7s@kabab.cs.huji.ac.il> References: <4964EB20.5070709@fsn.hu> <4964F9BB.3020407@fsn.hu> <E1LKoYw-000A3a-7s@kabab.cs.huji.ac.il>
index | next in thread | previous in thread | raw e-mail
Danny Braniss wrote: >> Attila Nagy wrote: >> >>> Hello, >>> >>> I'm trying to boot FreeBSD 8-CURRENT on a Sun X4540 (2xquad core >>> Opteron, 64 GB memory, 48 SATA disks (in fact 47, the 48th is a write >>> optimized SSD, because this box is a 7210 OpenStorage "appliance", >>> running OpenSolaris) on LSI controllers, nvidia NIC) from our boot >>> server without success. >>> >>> The PXE on the NIC downloads pxeboot with TFTP, but then gets stuck at >>> loading the kernel: >>> http://people.fsn.hu/~bra/freebsd/20090107-freebsd-x4540/Screenshot-6.png >>> >>> pxeboot is configured to load the kernel via NFS (the default) and >>> according to the tcpdump output, the client (X4540) issues an NFS >>> GETPORT call and gets the response from the NFS server and then >>> nothing else happens. >>> >>> I've tried with LOADER_TFTP_SUPPORT=YES and the result is the same, >>> the only difference is that the machine stops sending packets after >>> the first TFTP read request (for /boot/boot.4th.split), which doesn't >>> exist, so the server sends the answer and then nothing comes back from >>> the X4540 box. >>> >>> It seems that it gets to send exactly one packet, then freezes. >>> >>> What else should be done to debug this problem? >>> >>> Thanks, >>> >> BTW, the last FreeBSD 8-CURRENT snapshot from december boots fine (at >> least I can get to sysinstall, I haven't yet tried installation, because >> I wouldn't like to touch the boot drives, which house the OpenSolaris >> image -that's why I want to boot from the net). >> >> > > older pxeboot - pre interrupt handling fixes - work ok, so you can use that > instead. > I thought that I did testing with an older version, but as it turned out I was wrong. Confirmed, older versions work fine. The next problem is that a freshly compiled kernel (HEAD from today) panics with this: http://people.fsn.hu/~bra/freebsd/20090107-freebsd-x4540/Screenshot-55.png "BIOS smap did not include a basemem segment!" which is true, according to the above verbose output and taking a quick look at the code. (in the loop there is only a base=0x0 and len=0x0 entry) I'm not an expert of this topic (too), for me these numbers look pretty strange. Maybe Peter can help? Thanks,home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49661409.4090600>