New BUILDINFO variable
I have just committed some changes to allow information from the
build environment to be stored in /etc/release and in kernels.
You can store information about your build in the BUILDINFO
environment variable, to pass it to build.sh via -V
BUILDINFO=Your information here. The value may be a multi-line
string, with embedded C-style escapes, so line breaks may be
denoted by \n or by literal line breaks (or a mixture of both).
The BUILDINFO value will appear near the top of /etc/release if
you build a release, and will be stored in the kernel's buildinfo
variable if you build a kernel. The value bay be extracted from a
running kernel via sysctl kern.buildinfo.
For example, if you pass something like this to build.sh:
BUILDINFO='Built from my private git repository
branch foo, commit deadc0ffee, date 2014-08-03,
based on NetBSD-current as of 2014-08-03 10:00 UTC'
then sysctl kern.buildinfo would print that information,
and information like this would appear near the top of
${DESTDIR}/etc/release:
Build information:
Build date Sun Aug 3 22:47:03 UTC 2014
Built by user@host.domain
Built from my private git repository
branch foo, commit deadc0ffee, date 2014-08-03,
based on NetBSD-current as of 2014-08-03 10:00 UTC
--apb (Alan Barrett)
Re: Building PCC for tools is broken (missing symbol __USE)- PCC bug or NetBSD source tree error?
Once again, sorry for the delay (I need to work on this). Just as a
heads-up, prepare_import.sh appears to be broken on my (Ubuntu-Linux)
machine, so I'll go ahead and just apply the diff we discussed that add
__restrict in arrays directly. This means that my copy of pcc will be a
hybrid between the currently imported pcc tree in NetBSD and the current
master on pcc.ludd.ltu.se- not sure if that will be an issue in practice
however. I'm going to do a clean build of my 486 machine's tree beforehand
with the pcc-20140706, however, to make sure my source tree is sane (see
Missing files in DESTDIR- NetBSD version increment problem?).
Have B. Harder's (Re: pcc build error that has been outstanding for a few
days...) changes been added to the main tree yet?
Perhaps PCC will be ready by the time NetBSD 7 is released- there's still
time to make sure it works!
The following shows the error:
william@xubuntu-ltrain:~/Projects/NetBSD-CVS/src/external/bsd/pcc$
./prepare-import.sh
+ set -e
+ [ ! -d work -o ! -d work/pcc ]
+ echo Removing pcc CVS directories...
Removing pcc CVS directories...
+ find work+ -typexargs rm -Rf
d -name CVS
+ echo Fixing file and directory permissions...
Fixing file and directory permissions...
+ find work -type d -exec chmod u=rwx,go=rx {} ;
+ find work -type f -exec chmod u=rw,go=r {} ;
+ echo Fixing RCS tags...
Fixing RCS tags...
+ grep -RL \$(NetBSD|Id).*\$ work
+ sed -e /\$NetBSD\$/d -e s,\$\(NetBSD[[::]].*\)\$,\1, -e
s,\(.*\)\$\(Id[[::]].*\)\$\(.*\),\1\2\3 \
\1\$NetBSD\$\3,
sed: -e expression #2, char 29: Invalid character class name
Sadly, I do not know enough about the context of replacements you are trying
to make to feel comfortable editing this myself.
Thanks again for your prompt responses!
-Original Message-
From: Iain Hibbert
Sent: Thursday, July 31, 2014 5:20 AM
To: William D. Jones ; Anders Magnusson
Cc: current-users@netbsd.org
Subject: Re: Building PCC for tools is broken (missing symbol __USE)- PCC
bug or NetBSD source tree error?
On 31 July 2014 06:13:00 BST, William D. Jones thor0...@comcast.net
wrote:
Sorry for the delay in getting back. Iain sent me an email suggesting a
checkout like you suggested, or using prepare_import.sh in
$NETBSD_ROOT/external/bsd/pcc/. Is prepare_import.sh up to date?
it should be fine for current PCC sources
Should
I
use that script instead, or are there subtle issues to using that
script
right now as opposed to applying the diff directly (I've read that
PCC's
files are kept in multiple parts of the source tree)?
I don't think that is the case, feel free to apply the diff directly
It seems as if
prepare_import.sh implements the equivalent of git subtree (track
repository from within repositoty).
I use that script to prepare the PCC sources before import to netbsd tree..
you can use it locally and get the same result as if I had imported a new
version
if you just apply one patch at a time there is always the chance you miss
something
--
William D. Jones
Rowan University | ECE | 2012
Member IEEE
Member Tau Beta Pi
thor0...@comcast.net
Message sent using 'Windows Live Mail' client.
Re: lsi 1020/1030 problems
hello. In thinking about your issue with the LSI SCSI controller a bit, I have the following questions: 1. What drives do you have attached to the LSI controller? 2. How do the controller and drives probe under Linux which you say works fine? 3. What happens if you boot the system with no drives attached to the LSI controller? 4. How about if you plug drives in 1 by 1 and reboot each time? 5. Or, plug drives in and then run scsictl scanbus against the bus you just altered? I'm wondering if you have a particular drive that our driver doesn't like? The message youre seeing suggests the LSI controller is receiving more data than it expects from a particular SCSI target. Unfortunately, the driver isn't telling you which target it is. I'm not sure if that's because the driver doesn't have that data from the LSI controller or because we just didn't write the driver to present it. Having spent a lot of time working on this driver, however, I'm pretty sure the problem you're seeing is between a particular drive and the controller itself. If it works on Linux, it probably means we're setting up the controller differently and it's a matter of figuring out what, exactly is different. -thanks -Brian On Jul 29, 7:49am, 6b...@6bone.informatik.uni-leipzig.de wrote: } Subject: lsi 1020/1030 problems } Hello, } } I am trying to use an external scsi raid with an lsi 1020/1030 scsi } adapter. with linux (knoppix) all works well. netbsd (current-6.99.47) } reports: } } mpt1: mpt_done: IOC overrun! } probe(mpt1:0:0:0): generic HBA error } } some output from dmesg: } } mpt0 at pci4 dev 8 function 0: vendor 0x1000 product 0x0030 (rev. 0xc1) } mpt0: interrupting at ioapic0 pin 16 } scsibus0 at mpt0: 16 targets, 8 luns per target } mpt1 at pci11 dev 8 function 0: vendor 0x1000 product 0x0030 (rev. 0xc1) } mpt1: interrupting at ioapic0 pin 18 } scsibus2 at mpt1: 16 targets, 8 luns per target } mpt1: mpt_done: IOC overrun! } probe(mpt1:0:0:0): generic HBA error } } } Any Ideas what could be the problem? } } } Thank you for your efforts } } } Regards } Uwe -- End of excerpt from 6b...@6bone.informatik.uni-leipzig.de
