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>
next in thread | previous in thread | raw e-mail | index | archive | help
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,
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49661409.4090600>