Re: Loading drivers via kldload
On Thu, 11 Aug 2011 17:08:30 -0700 David Somayajulu mentioned: > Hi All, > While loading PCIe based HBA drivers via kldload, does FreeBSD expect a valid > (i.e., non-zero) PCI subsystem Vendor and Device IDs? > It depends on the specific driver. FreeBSD doesn't check for the PCI ID in general. Usually, drivers contains a routine that check if this driver can be used with that hardware based on the PCI ID. -- Stanislav Sedov ST4096-RIPE () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
upgrade to 9.0-BETA1 with geom_mirror fails
Hi all, I was originally running 8.2 on my NAS at home -- later 8-STABLE for ZFS -- and decided to see how 9.0-BETA1 fairs on it due to seeing some changes coming in 9.0 that would be favorable. After installing the kernel and trying to reboot into it I discovered it doesn't like my geom_mirror that I use for / and swap. It gives this error: "geom_mirror integrity check failed" It can't mount the / device then (/dev/mirror/gm0a) so it asks me to choose a disk to boot from. When listing the disks with ? it shows all physical disks but the only geom device is gm0 -- none of the slices are listed. Any idea how to fix this? If I boot up an 8-STABLE or 8.2R kernel it has no issues with my mirror. Thanks, Mark ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RE: [patch] Problem with two NIC on same NET (in_scrubprefix: err=17, new prefix add failed)
Hi, > > I've started my work with not point-to-point interfaces and I've > found two problems. The first one - > > > When I've done more investigation, it looks similar to > http://svnweb.freebsd.org/base?view=revision&revision=201543 > So, I propose the following patch. > I agree with your fix. As you've noted, I made the r201543 patch in IPv6 almost 2 years ago. Turned out I had a note-to-self to verify if there are other similar problems at the time but busy day job took me away ... > > The second one - submitted patch and description is bellow: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=159603 > I agree with your fix. > > I have no problem with loopback routes when I work with not > point-to-point interfaces as I can NOT set same source address on > them. However, if the interface is going down and up, then loopback > route is deleted without checking IFA_RTSELF flag (it must be > consistent! especially in kernel) and re-added regardless of > "useloopback" setting. So, at least, a loopback route is installed > even if useloopback is NOT allowed! > I hope the question does not offend you, but you do know the history behind IFA_RTSELF loopback route for each interface address, right ? The interface address loopback route is used for reaching the interface address within the system after the L2/L3 separation redesign, that's why "useloopback" setting is inapplicable. The check in various code paths may have a bit of consistency issue, but "useloopback" setting does not apply here. > > After that I've continued with point-to-point interfaces on same net, > i.e. I've work with un-numbered interfaces. Firstly, I could not set > parallel links on them. The fix is following and is already > commmitted: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=159600 > I had a second look at it after some sleep, I agree with your fix. > > The bigger problem was with loopback routes on un-numbered > interfaces. In in_ifinit(), when un-numbered interface is setting > loopback route, then refcount on existing route is incremented and > IFA_RTSELF flags is set on its address. This is done if and only if > useloopback is set and interface is not IFF_LOOPBACK. It is OK. The > rest is hacked somehow and I don't know why. > The loopback route for the IFA should be installed unconditionally. So the check in in_ifinit() for "V_useloopback" needs to be removed. > > In in_ifscrubprefix() which is used either when address is being > deleted or interface is going down, I found first inconsistence. > Refcount on existing route is decremented always (in both cases), but > the route is deleted only when address is being deleted. > That's by design. > > Futhermore, > IFA_RTSELF flag is NOT cleared when refcount is decremented! The fix > and behavour is following: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=159601 > I agree with your fix. > > In the view of this inconsistence, I understand a next one in > rip_ctlinput(). When interface is going up, then loopback route is > being deleted and re-added regardless of IFA_RTSELF flag and > useloopback setting. If un-numbered interfaces are used, then it > damages refcount on existing loopback route!! > I will fix that. > > If useloopback IS NOT set and IFA_RTSELF IS set, then loopback route > is deleted, but with correct refcount game. And if useloopback is SET > and IFA_RTSELF IS NOT set and interface IS NOT IFF_LOOPBACK, then > loopback route is added, but again with correct refcount game too. It > (with previous patch) should ensure IFA_RTSELF and loopback route > consistence. > No, see above, the IFA_RTSELF route should be unconditionally. I agree with you about the consistency issue and will fix it. >> >> Unless you have a really good reason, other than code inspection, >> and have a set of test cases, please leave this code alone for now. > > I have good reason, but I can hack kernel just for me only in worse > scenario. However, I always try to minimalize the hacks count. > You can hack the kernel however you see fit, but when you are ready for a patch commit, please provide sufficient context and problem description, and test cases whenever possible to make the code review process effective. > > I understand, but I use my own DHCP client. Well, I try to look at it, > but maybe, someone else can test it. > Again, my only point is, since these areas are core to the networking kernel, please test as many scenarios as possible, more than just your specific setup. (I made this mistake myself sometimes.) In any case, thank you very much for your fixes. -- Qing ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SVN -> CVS exporter issue?
On Thu, Aug 11, 2011 at 07:26:36PM -0400, Michael Butler wrote: > I'm not seeing any of today's SVN src updates flow through to CVS/CSUP. > Is it broken? Could it be because of r224768? I vaguely recall that "svn mv" bothers whatever it is that converts from svn -> cvs. Regards, Navdeep ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Loading drivers via kldload
Hi All, While loading PCIe based HBA drivers via kldload, does FreeBSD expect a valid (i.e., non-zero) PCI subsystem Vendor and Device IDs? Thanks, David Somayajulu This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SVN -> CVS exporter issue?
I'm not seeing any of today's SVN src updates flow through to CVS/CSUP. Is it broken? imb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[bsdgrep] fgrepcomp(), ignore case and segfault with unicode locale
A quick test
$ env -i bsdgrep -Fi without_nls usr.bin/grep/grep.c
$ env -i gnugrep -Fi without_nls usr.bin/grep/grep.c
#ifndef WITHOUT_NLS
#ifndef WITHOUT_NLS
#ifndef WITHOUT_NLS
shows that bsd fgrep already fails to ignore case. And if you throw
a few more options to the mix it'd crash, e.g.
$ env -i LC_CTYPE=en_US.UTF-8 TERM=xterm bsdgrep --color -Fir without_nls
usr.bin/grep/
[...]
Program received signal SIGSEGV, Segmentation fault.
0x000801007ff2 in memchr (s=0x61167a, c=10, n=18446744073707490297) at
/usr/src/lib/libc/string/memchr.c:48
48 if (*p++ == (unsigned char)c)
(gdb) bt
#0 0x000801007ff2 in memchr (s=0x61167a, c=10, n=18446744073707490297)
at /usr/src/lib/libc/string/memchr.c:48
#1 0x000801007b03 in __sfvwrite (fp=0x801247770, uio=0x7fffd8f0) at
/usr/src/lib/libc/stdio/fvwrite.c:170
#2 0x000801007698 in fwrite (buf=0x608c03, size=18446744073709551606,
count=1, fp=0x801247770)
at /usr/src/lib/libc/stdio/fwrite.c:95
#3 0x00405498 in printline (line=0x7fffdb70, sep=58,
matches=0x7fffd990, m=9)
at /usr/src/usr.bin/grep/util.c:500
#4 0x00404f51 in procline (l=0x7fffdb70, nottext=0) at
/usr/src/usr.bin/grep/util.c:381
#5 0x0040489f in procfile (fn=0x80140b600
"usr.bin/grep/nls/es_ES.ISO8859-1.msg") at /usr/src/usr.bin/grep/util.c:239
#6 0x004044d7 in grep_tree (argv=0x7fffdd30) at
/usr/src/usr.bin/grep/util.c:163
#7 0x00403ea9 in main (argc=5, argv=0x7fffdd10) at
/usr/src/usr.bin/grep/grep.c:689
(gdb) bt f
#0 0x000801007ff2 in memchr (s=0x61167a, c=10, n=18446744073707490297)
at /usr/src/lib/libc/string/memchr.c:48
p = (const unsigned char *) 0x80
#1 0x000801007b03 in __sfvwrite (fp=0x801247770, uio=0x7fffd8f0) at
/usr/src/lib/libc/stdio/fvwrite.c:170
len = 18446744073709516159
p = 0x61167a ""
iov = (struct __siov *) 0x7fffd8f0
w = 880
s = 880
nl = 0x611679 "\n"
nlknown = 0
nldist = 0
#2 0x000801007698 in fwrite (buf=0x608c03, size=18446744073709551606,
count=1, fp=0x801247770)
at /usr/src/lib/libc/stdio/fwrite.c:95
n = 18446744073709551606
uio = {uio_iov = 0x7fffd8e0, uio_iovcnt = 1, uio_resid = -35457}
iov = {iov_base = 0x608c03, iov_len = 18446744073709551606}
#3 0x00405498 in printline (line=0x7fffdb70, sep=58,
matches=0x7fffd990, m=9)
at /usr/src/usr.bin/grep/util.c:500
a = 99
i = 9
n = 1
#4 0x00404f51 in procline (l=0x7fffdb70, nottext=0) at
/usr/src/usr.bin/grep/util.c:381
matches = {{rm_so = 0, rm_eo = 11}, {rm_so = 11, rm_eo = 22}, {rm_so
= 22, rm_eo = 33}, {rm_so = 33, rm_eo = 44}, {
rm_so = 44, rm_eo = 55}, {rm_so = 55, rm_eo = 66}, {rm_so = 66, rm_eo =
77}, {rm_so = 77, rm_eo = 88}, {rm_so = 88,
rm_eo = 99}, {rm_so = 21131328, rm_eo = 8}, {rm_so = -9696, rm_eo =
32767}, {rm_so = 16101362, rm_eo = 8}, {rm_so = 21131328,
rm_eo = 8}, {rm_so = 16103767, rm_eo = 0}, {rm_so = 37, rm_eo = 0},
{rm_so = 8, rm_eo = 0}, {rm_so = -9632, rm_eo = 32767}, {
rm_so = -8944, rm_eo = 32767}, {rm_so = -9664, rm_eo = 32767}, {rm_so =
16103767, rm_eo = 8}, {rm_so = 6327289, rm_eo = 0}, {
rm_so = 437, rm_eo = 0}, {rm_so = -9584, rm_eo = 10}, {rm_so = 6327200,
rm_eo = 0}, {rm_so = -9776, rm_eo = 0}, {
rm_so = 6327290, rm_eo = 0}, {rm_so = -9536, rm_eo = 32767}, {rm_so =
4204252, rm_eo = 0}, {rm_so = -9584, rm_eo = 32767}, {
rm_so = 6327200, rm_eo = 0}, {rm_so = -9352, rm_eo = 32767}, {rm_so =
21004392, rm_eo = 8}}
pmatch = {rm_so = 88, rm_eo = 99}
st = 99
i = 1
c = 1
m = 9
r = 0
#5 0x0040489f in procfile (fn=0x80140b600
"usr.bin/grep/nls/es_ES.ISO8859-1.msg") at /usr/src/usr.bin/grep/util.c:239
f = (struct file *) 0x801408068
sb = {st_dev = 745804815, st_ino = 171971, st_mode = 33188, st_nlink
= 1, st_uid = 1001, st_gid = 1001,
st_rdev = 4294967295, st_atim = {tv_sec = 1292381124, tv_nsec = 0}, st_mtim
= {tv_sec = 1280426577, tv_nsec = 0}, st_ctim = {
tv_sec = 1292381124, tv_nsec = 165601426}, st_size = 526, st_blocks = 2,
st_blksize = 4096, st_flags = 0, st_gen = 0,
st_lspare = 0, st_birthtim = {tv_sec = 1292381124, tv_nsec = 165601426}}
ln = {off = 0, len = 89,
dat = 0x608ba0 "$ $FreeBSD: head/usr.bin/grep/nls/es_ES.ISO8859-1.msg
210622 2010-07-29 18:02:57Z gabor $\n$\n$set 1\n$quote \"\n1 \"(entrada
estdar)\"\n2 \"no se puede leer el fichero comprimido bzip2\"\n3 \"opci
desconocid"...,
file = 0x801427040 "usr.bin/grep/nls/es_ES.ISO8859-1.msg", line_no = 1}
s = 32768
c = 0
t = 8
#6 0x004044d7 in grep_tree (argv=0x7fffdd30) at
/usr/src/usr.bin/grep/util.c:163
Re: issues with bsdgrep and lang/go
Em 2011.08.09. 13:27, Test Rat escreveu: Try below workaround. It also makes empty GREP_COLOR behave like gnugrep(1). Thanks a lot, you were so quick that I haven't had a chance to look at it yet. I'll commit the patch soon. Also, thanks to Alexander for using BSD grep and reporting bugs. Gabor Kovesdan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: issues with bsdgrep and lang/go
Em 2011.08.10. 22:09, Alexander Best escreveu: well i'd like to help the author of bsdgrep to improve it. testing it and then going back to gnu grep, because bsdgrep still has bugs isn't going to help much. by using it i'd like to trip over these kind of bugs and report them. but you're right...the author hasn't really paid a lot of attention to bsdgrep, lately.:( i guess that's a problem when you have an open os, where everybody can do as much or as little as it pleases him.;) I do! In this year's Summer of Code I'm working on the regex code. A good and efficient regex support is important for a fast and clean BSD grep. The ultimate goal is to get rid of both GNU grep and libgnuregex. I'm sorry if I temporarily neglected some bug reports. Gabor ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: issues with bsdgrep and lang/go
Em 2011.08.10. 5:02, Jason Hellenthal escreveu: So has the maintainer of bsdgrep updated it yet so these things do not happen ?, if not (and apparently not) I don't understand why you are explicitly defaulting your gnugrep to a broken bsdgrep. This was a known problem a few months back and I for one have not seen updates on that yet. I don't remember of this bug but I may have missed it. Could you tell me where did you see it? I'm very thankful to Alexander for using the "buggy BSD grep" because he helped fixing a bug. Criticizing is the easiest option but probably not the best. Gabor Kovesdan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [bsdgrep] --exclude-dir doesn't work
Em 2011.08.09. 14:43, Test Rat escreveu: It seems fnmatch(3) args were accidentally swapped. Try $ bsdgrep -Fr --exclude-dir '*.svn*' grep_ usr.bin/grep | bsdgrep -c svn 72 Thanks! I'll commit this, too. Gabor ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD-9.0-BETA1-i386-bootonly
On 08/11/11 12:28, Vans wrote: Hi. No need, I think. There is a message box: Error while fetching ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/i386/9.0-BETA1/base.txz: File unavailable (e.g., file not found, no access) The 9.0-BETA1 ISOs cannot be used for network installations pending changes to the layout of the FTP servers to accommodate architectures with multiple CPU types per machine type (e.g. powerpc64, ARM, and MIPS) that were introduced in 9.0. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD-9.0-BETA1-i386-bootonly
On Aug 11, 2011, at 10:28 AM, Vans wrote: > Hi. > > No need, I think. There is a message box: > Error while fetching > ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/i386/9.0-BETA1/base.txz: > File unavailable > (e.g., file not found, no access) > > Regards, > Vans. > > 10.08.2011, в 18:48, Chris Brennan написал(а): > >> On 8/10/2011 10:44 AM, N V wrote: >>> Hi. >>> >>> Tried to use FreeBSD-9.0-BETA1-i386-bootonly.iso in VirtualBox to test. >>> Installation stops after trying to fetch files from ftp. Attached >>> screenshot is informative, I think. Seems to use i386/ twice for some >>> reason. >>> >>> Regards, >>> Vans. >> >> Your screenshot didn't make it to the list, can you upload it and >> provide us with a link to it instead? >> >> >> mirrorselect is using both uname -m and uname -p instead of just uname -m. That's why things don't work. Thanks, -Garrett___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: can't pxeboot BETA1
Hi, These instructions are not official, but they are what I have been using to set up PXE boot using an NFS root file system: http://people.freebsd.org/~rodrigc/pxe/freebsd_pxe.txt -- Craig Rodrigues rodr...@crodrigues.org On Wed, Aug 10, 2011 at 7:13 PM, Elliot Finley wrote: > trying to pxeboot according to this page > http://www.freebsdwiki.net/index.php/Installing_FreeBSD_with_netboot, > but instead using 9.0-BETA1 doesn't work. > > can't mount root from ufs:/dev/md0 > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD-9.0-BETA1-i386-bootonly
Hi. No need, I think. There is a message box: Error while fetching ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/i386/9.0-BETA1/base.txz: File unavailable (e.g., file not found, no access) Regards, Vans. 10.08.2011, в 18:48, Chris Brennan написал(а): > On 8/10/2011 10:44 AM, N V wrote: >> Hi. >> >> Tried to use FreeBSD-9.0-BETA1-i386-bootonly.iso in VirtualBox to test. >> Installation stops after trying to fetch files from ftp. Attached screenshot >> is informative, I think. Seems to use i386/ twice for some reason. >> >> Regards, >> Vans. > > Your screenshot didn't make it to the list, can you upload it and > provide us with a link to it instead? > > > > -- >> Chris Brennan >> -- >> A: Yes. >>> Q: Are you sure? A: Because it reverses the logical flow of conversation. > Q: Why is top posting frowned upon? >> http://xkcd.com/84/ | http://xkcd.com/149/ | http://xkcd.com/549/ >> GPG: D5B20C0C (6741 8EE4 6C7D 11FB 8DA8 9E4A EECD 9A84 D5B2 0C0C) > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: awk(1) segfaults when building kernel modules
Ruslan Ermilov writes:
> On Wed, Aug 10, 2011 at 10:12:11PM +0400, Test Rat wrote:
>> `make -s buildkernel' seems to contain lots of segfaults after recent
>> update of one-true-awk in r224731. It chokes on sys/conf/kmod_syms.awk.
>> The case can be reduced to
>>
>> $ awk 'BEGIN { delete ARGV[1] } END { print ARGV[1] }' blah
>> [...]
>
> Should be fixed in r224776; please confirm.
Confirmed, it no longer crashes with either above example or when
building kernel modules.
--
FreeBSD 9.0-BETA1 r224776M amd64
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: awk(1) segfaults when building kernel modules
On Wed, Aug 10, 2011 at 10:12:11PM +0400, Test Rat wrote:
> `make -s buildkernel' seems to contain lots of segfaults after recent
> update of one-true-awk in r224731. It chokes on sys/conf/kmod_syms.awk.
> The case can be reduced to
>
> $ awk 'BEGIN { delete ARGV[1] } END { print ARGV[1] }' blah
> [...]
Should be fixed in r224776; please confirm.
Cheers,
--
Ruslan Ermilov
r...@freebsd.org
FreeBSD committer
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: resolvconf script overwrites entries in resolv.conf - RDNSS/DNSSL related
Hi,
> On Mon, 8 Aug 2011 07:55:11 -0400
> "J.R. Oldroyd" said:
> Is there any chance that you could create a patch for 8.2 based on the
> commits in HEAD?
> That would be great!
>
fbsd> Better would be to ask hrs@ to MFC his commits to 8-stable.
hrs@ posted MFC candidate patch for review. Please refer the thread
started from:
http://lists.freebsd.org/pipermail/freebsd-net/2011-June/029070.html
The patches you will find in the thread are:
http://people.freebsd.org/~hrs/rfc6106_stable8_20110612-1.diff
http://people.freebsd.org/~ume/resolvconf-releng_8.diff
You may be interested in the thread from the following as well:
http://lists.freebsd.org/pipermail/freebsd-net/2011-June/029091.html
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
u...@mahoroba.org ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
