Re: [MFC REQUEST] Filename completion in sh(1)
>> -Brandon > > Oh, I see. The diff doesn't include the change(s) to histedit.h > I would be very interested in a diff for FreeBSD 8.1 Sam Fourman Jr. http://www.fourmannetworks.com/ ___ 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: [MFC REQUEST] Filename completion in sh(1)
On Tue, Jun 15, 2010 at 9:17 PM, Brandon Gooch wrote: > On Tue, Jun 15, 2010 at 9:08 PM, jhell wrote: >> On 06/15/2010 22:00, jhell wrote: >>> On 06/15/2010 21:14, Brandon Gooch wrote: I discovered a few moments ago that filename completion had been committed to HEAD[1]!!! >>> This is a (seemingly) small, yet VERY useful addition, and, of course I'm so grateful to Guy Yur and Jilles for getting this into the tree :) >>> I would like to make an "official" request that this feature be MFC'd to 8-STABLE as soon as reasonably possible. >>> Again, my thanks to you both for your work! >>> -Brandon >>> [1] http://svn.freebsd.org/viewvc/base?view=revision&revision=209221 >>> >>> Here is a diff from stable/8/bin/sh r209146 -> head/bin/sh. This is >>> quite a large difference among the two with the following diffstats. >>> >>> 44 files changed, 1214 insertions(+), 728 deletions(-) >>> >>> This is untested, use at your own risk. >>> >> >> Actually, I lied. I have just tested it and it does not compile for the >> following errors: >> >> /usr/src/bin/sh/histedit.c: In function 'histedit': >> /usr/src/bin/sh/histedit.c:124: error: '_el_fn_sh_complete' undeclared >> (first use in this function) >> /usr/src/bin/sh/histedit.c:124: error: (Each undeclared identifier is >> reported only once >> /usr/src/bin/sh/histedit.c:124: error: for each function it appears in.) >> >> But I do not have time to look into this further until tommorow. > > Thanks for this jhell! > > It appears that a C header file is missing from /usr/include; the > function declaration is "histedit.h". > > No problem, just `make install` in /usr/src/include and it should build. > > -Brandon Oh, I see. The diff doesn't include the change(s) to histedit.h :( oh well, thanks anyway! -Brandon ___ 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: [MFC REQUEST] Filename completion in sh(1)
On Tue, Jun 15, 2010 at 9:08 PM, jhell wrote: > On 06/15/2010 22:00, jhell wrote: >> On 06/15/2010 21:14, Brandon Gooch wrote: >>> I discovered a few moments ago that filename completion had been >>> committed to HEAD[1]!!! >> >>> This is a (seemingly) small, yet VERY useful addition, and, of course >>> I'm so grateful to Guy Yur and Jilles for getting this into the tree >>> :) >> >>> I would like to make an "official" request that this feature be MFC'd >>> to 8-STABLE as soon as reasonably possible. >> >>> Again, my thanks to you both for your work! >> >>> -Brandon >> >>> [1] http://svn.freebsd.org/viewvc/base?view=revision&revision=209221 >> >> Here is a diff from stable/8/bin/sh r209146 -> head/bin/sh. This is >> quite a large difference among the two with the following diffstats. >> >> 44 files changed, 1214 insertions(+), 728 deletions(-) >> >> This is untested, use at your own risk. >> > > Actually, I lied. I have just tested it and it does not compile for the > following errors: > > /usr/src/bin/sh/histedit.c: In function 'histedit': > /usr/src/bin/sh/histedit.c:124: error: '_el_fn_sh_complete' undeclared > (first use in this function) > /usr/src/bin/sh/histedit.c:124: error: (Each undeclared identifier is > reported only once > /usr/src/bin/sh/histedit.c:124: error: for each function it appears in.) > > But I do not have time to look into this further until tommorow. Thanks for this jhell! It appears that a C header file is missing from /usr/include; the function declaration is "histedit.h". No problem, just `make install` in /usr/src/include and it should build. -Brandon ___ 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: [MFC REQUEST] Filename completion in sh(1)
On 06/15/2010 22:00, jhell wrote: > On 06/15/2010 21:14, Brandon Gooch wrote: >> I discovered a few moments ago that filename completion had been >> committed to HEAD[1]!!! > >> This is a (seemingly) small, yet VERY useful addition, and, of course >> I'm so grateful to Guy Yur and Jilles for getting this into the tree >> :) > >> I would like to make an "official" request that this feature be MFC'd >> to 8-STABLE as soon as reasonably possible. > >> Again, my thanks to you both for your work! > >> -Brandon > >> [1] http://svn.freebsd.org/viewvc/base?view=revision&revision=209221 > > Here is a diff from stable/8/bin/sh r209146 -> head/bin/sh. This is > quite a large difference among the two with the following diffstats. > > 44 files changed, 1214 insertions(+), 728 deletions(-) > > This is untested, use at your own risk. > Actually, I lied. I have just tested it and it does not compile for the following errors: /usr/src/bin/sh/histedit.c: In function 'histedit': /usr/src/bin/sh/histedit.c:124: error: '_el_fn_sh_complete' undeclared (first use in this function) /usr/src/bin/sh/histedit.c:124: error: (Each undeclared identifier is reported only once /usr/src/bin/sh/histedit.c:124: error: for each function it appears in.) But I do not have time to look into this further until tommorow. Regards, -- jhell ___ 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"
[MFC REQUEST] Filename completion in sh(1)
I discovered a few moments ago that filename completion had been committed to HEAD[1]!!! This is a (seemingly) small, yet VERY useful addition, and, of course I'm so grateful to Guy Yur and Jilles for getting this into the tree :) I would like to make an "official" request that this feature be MFC'd to 8-STABLE as soon as reasonably possible. Again, my thanks to you both for your work! -Brandon [1] http://svn.freebsd.org/viewvc/base?view=revision&revision=209221 ___ 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: [CFT] BSDL iconv in base system
Gabor Kovesdan writes: [...] > Any comments, suggestions or bugreports are very welcome. Does it respect lib32? $ iconv -f ascii iconv: iconv_open(UTF-8, ascii): Invalid argument /usr/lib/i18n/libiconv_std.so.4: unsupported file layoutzsh: exit 1 iconv -f ascii $ file /usr/lib/i18n/libiconv_std.so.4 /usr/lib/i18n/libiconv_std.so.4: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, stripped $ uname -vm FreeBSD 9.0-CURRENT #0 r209191=1463b20-dirty: Tue Jun 15 04:59:40 UTC 2010 h...@raphael.local:/a/objdir/a/dirty_build/sys/PHOENIX 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: two buildworld problems
Alexander Best writes: > Dag-Erling Smørgrav writes: > > The problem is that "/usr/src/" is not a prefix of "/usr/src". > ah i see. would something like > > empty(.CURDIR:M/usr/src*) instead of empty(.aCURDIR:M/usr/src/*) work? I think so. My hypothesis is that CC, CXX etc. were set in the top-level Makefile and inherited by sub-makes. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: [CFT] BSDL iconv in base system
cc1: warnings being treated as errors /usr/src/lib/libiconv_modules/BIG5/../../libc/iconv/citrus_stdenc_template.h: In function '_citrus_BIG5_stdenc_cstomb': /usr/src/lib/libiconv_modules/BIG5/../../libc/iconv/citrus_stdenc_template.h:138: warning: 'ret' may be used uninitialized in this function Eeh. I'm sorry, I'll look at it tomorrow. For now you can use WERROR="" and CWARNFLAGS="" to test, actually it was what I used that's why I couldn't catch this. I had the same problem with some code that was not mine so I just set it. I don't know why I'm having that, tohugh, I also have that with a clean unpatched src tree and I'm not using any CFLAGS tweak or such. If you haven't done make clean yet, you can resume the build with: make buildworld -DNO_CLEAN WERROR="" CWARNFLAGS="" -- Gabor Kovesdan FreeBSD Volunteer EMAIL: ga...@freebsd.org .:|:. ga...@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
AK-san, PseudoCylon wrote: From: Ganbold To: PseudoCylon Cc: freebsd-current@freebsd.org; Ganbold Tsagaankhuu Sent: Thu, June 10, 2010 10:53:30 AM Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless It seems like it is running without any problem so far, no more adsl modem problem. I can see arp packets in wlan0 interface as well as in macbook. I will continue testing and let you know if there comes any problem. thanks again, Ganbold >>> Hello, >>> >>> Glad to hear. It was an encryption problem. A client was dropping packets.. >>> >>> Please let me know if you find another bug. (Hope there won't be) >>> >>> >> Well, looks like I was too fast :( >> >> It seems like client is not receiving any arp packets when rspro doesn't >> first initiate ping (maybe arp request) to client. >> If I first ping to client from rspro, later on arp packets can be seen >> on client. >> When I ping from rspro to client, response is very different: >> >> # arp -a >> ? (192.168.1.43) at 8e:fd:59:d6:3a:50 on bridge0 permanent [bridge] >> ? (192.168.1.42) at 00:22:cf:03:e0:30 on wlan0 permanent [ethernet] >> ? (192.168.1.41) at 00:15:6d:c1:c7:77 on arge0 permanent [ethernet] >> ? (192.168.1.1) at 00:30:54:62:3d:24 on arge0 expires in 1200 seconds >> [ethernet] >> ? (192.168.1.7) at 00:1c:25:9d:36:1d on arge0 expires in 824 seconds >> [ethernet] >> # ping 192.168.1.50 >> PING 192.168.1.50 (192.168.1.50): 56 data bytes >> 64 bytes from 192.168.1.50: icmp_seq=0 ttl=64 time=2.694 ms >> 64 bytes from 192.168.1.50: icmp_seq=1 ttl=64 time=302.177 ms >> 64 bytes from 192.168.1.50: icmp_seq=2 ttl=64 time=1.041 ms >> 64 bytes from 192.168.1.50: icmp_seq=4 ttl=64 time=5234.417 ms >> 64 bytes from 192.168.1.50: icmp_seq=5 ttl=64 time=4225.060 ms >> 64 bytes from 192.168.1.50: icmp_seq=6 ttl=64 time=3214.908 ms >> 64 bytes from 192.168.1.50: icmp_seq=7 ttl=64 time=2207.241 ms >> 64 bytes from 192.168.1.50: icmp_seq=8 ttl=64 time=1197.061 ms >> 64 bytes from 192.168.1.50: icmp_seq=9 ttl=64 time=186.833 ms >> ^C >> --- 192.168.1.50 ping statistics --- >> 11 packets transmitted, 9 packets received, 18.2% packet loss >> round-trip min/avg/max/stddev = 1.041/1841.270/5234.417/1870.962 ms >> # arp -a >> ? (192.168.1.43) at 8e:fd:59:d6:3a:50 on bridge0 permanent [bridge] >> ? (192.168.1.42) at 00:22:cf:03:e0:30 on wlan0 permanent [ethernet] >> ? (192.168.1.41) at 00:15:6d:c1:c7:77 on arge0 permanent [ethernet] >> ? (192.168.1.1) at 00:30:54:62:3d:24 on arge0 expires in 1183 seconds >> [ethernet] >> ? (192.168.1.7) at 00:1c:25:9d:36:1d on arge0 expires in 805 seconds >> [ethernet] >> ? (192.168.1.50) at 00:26:bb:17:f6:61 on arge0 expires in 1186 seconds >> [ethernet] >> # ping 192.168.1.50 >> PING 192.168.1.50 (192.168.1.50): 56 data bytes >> 64 bytes from 192.168.1.50: icmp_seq=2 ttl=64 time=1590.035 ms >> 64 bytes from 192.168.1.50: icmp_seq=3 ttl=64 time=580.201 ms >> 64 bytes from 192.168.1.50: icmp_seq=4 ttl=64 time=528.019 ms >> ^C >> --- 192.168.1.50 ping statistics --- >> 5 packets transmitted, 3 packets received, 40.0% packet loss >> round-trip min/avg/max/stddev = 528.019/899.418/1590.035/488.804 ms >> >> > > Well, the patch is working (sort of). Old driver wouldn't let you ping > anywhere. > > Replies are taking awfully long. One of them took 5 sec. This could be a > different issue. > > Can you try a few thing? (Unfortunately, everything is working on my side.) > * Before ping from rspro, does ping from macbook to 192.168.1.42 (wlan0) work? > Just tested again, it doesn't work from macbook. > * If you give IP address to only bridge0, does it make any difference? > It makes no difference. Ganbold > * Does it make any difference if use rspro without 192.168.1.7 (if possible)? > > wlandebug doesn't work on macbook, does it? > > Can you show me your hostapd.conf (minus password, of course). I'll try with > the same config. > > And, if you ping from macbook, would it take that long? > > > AK > > >> Any idea? >> >> thanks, >> >> Ganbold >> > > > > > -- Optimist, n.: A bagpiper with a beeper. ___ 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: two buildworld problems
2010/6/15 Dag-Erling Smørgrav : > Alexander Best writes: >> sorry. i didn't mean to affend you. doug barton already pointed out >> that what i had in my make.conf beforehand won't work unless /usr/src >> and /usr/obj are literal directories in /usr [1]. > > The problem is that "/usr/src/" is not a prefix of "/usr/src". ah i see. would something like empty(.CURDIR:M/usr/src*) instead of empty(.CURDIR:M/usr/src/*) work? alex > > DES > -- > Dag-Erling Smørgrav - d...@des.no > -- Alexander Best ___ 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: [CFT] BSDL iconv in base system
On Tue, Jun 15, 2010 at 7:56 PM, Alexander Best wrote: > On Tue, Jun 15, 2010 at 7:42 PM, Gabor Kovesdan wrote: >> >>> /usr/src/lib/libc/iconv/citrus_none.c: In function >>> '_citrus_NONE_stdenc_cstomb': >>> /usr/src/lib/libc/iconv/citrus_none.c:114: warning: unused variable 'ret' >>> *** Error code 1 >>> >> >> I'm sorry, this one slipped in. Today I've checked the sources with clang >> and fixed some minor warnings, including this one. The new patch is here: >> http://www.kovesdan.org/patches/iconv_base_integrate2.diff >> >> And a gzipped version: >> http://www.kovesdan.org/patches/iconv_base_integrate2.diff.gz > > thanks. i'll revert the previous patch and apply this new one. with the new patch: ===> lib/libiconv_modules (all) ===> lib/libiconv_modules/BIG5 (all) cc -fpic -DPIC -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native --param max-inline-insns-single=32 -I/usr/src/lib/libiconv_modules/BIG5/../../libc/iconv -g -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/lib/libiconv_modules/BIG5/citrus_big5.c -o citrus_big5.So cc1: warnings being treated as errors /usr/src/lib/libiconv_modules/BIG5/../../libc/iconv/citrus_stdenc_template.h: In function '_citrus_BIG5_stdenc_cstomb': /usr/src/lib/libiconv_modules/BIG5/../../libc/iconv/citrus_stdenc_template.h:138: warning: 'ret' may be used uninitialized in this function *** Error code 1 Stop in /usr/src/lib/libiconv_modules/BIG5. *** Error code 1 Stop in /usr/src/lib/libiconv_modules. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. > > cheers. > alex > >> >> -- >> Gabor Kovesdan >> FreeBSD Volunteer >> >> EMAIL: ga...@freebsd.org .:|:. ga...@kovesdan.org >> WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org >> >> > > > > -- > Alexander Best > -- Alexander Best ___ 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: two buildworld problems
Alexander Best writes: > sorry. i didn't mean to affend you. doug barton already pointed out > that what i had in my make.conf beforehand won't work unless /usr/src > and /usr/obj are literal directories in /usr [1]. The problem is that "/usr/src/" is not a prefix of "/usr/src". DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On 14-06-2010 23:31, Christian Zander wrote:
> On Mon, Jun 14, 2010 at 02:30:03PM -0700, Rene Ladan wrote:
> (...)
>>> I've asked the driver author if the calls to vm_page_wire() and
>>> vm_page_unwire() can simply be removed but have not heard back yet.
>>>
>>
>> Is there any news on this? I have updated to the latest current so I'm
>> running the nv driver now, but I'd like to get the nvidia driver running
>> again.
>>
>>
> Yes, the unnecessary (and now problematic) wiring and unwiring calls will
>>> be
> removed in a future release of the driver.
Excellent! Any ETA? Or are there patches against an existing version of
the driver?
>>>
>>> I would just remove the calls to vm_page_wire() and vm_page_unwire() along
>>> with the immediately adjacent calls to vm_page_{un,}lock_queues().
>>>
>> Just to confirm, like the attached patch?
>>
>
> Yes.
>
>> This is with a GeForce GT 240M, current/amd64 r209035, nvidia-driver
>> 195.36.15
>>
>> I haven't runtime-tested it yet...
>
Using the above configuration, X still locks up but now after showing
the NVIDIA splash screen. Without the patch it locks up before that
point. Pinging the computer doesn't work anymore, no panic or logs, a
hard reset is required.
Would disabling DRI and/or Accel in xorg.conf or updating the driver /
operating system somehow help?
Rene
--
http://www.rene-ladan.nl/
GPG fingerprint = ADBC ECCD EB5F A6B4 549F 600D 8C9E 647A E564 2BFC
(subkeys.pgp.net)
___
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: [bsdtar] strange compression with ^T command
On Sun, 13 Jun 2010 19:58:51 -0700 Tim Kientzle wrote: > Thanks for the report! This was caused by an > overflow in the compression calculation when the "in" > bytes was larger than the "out" bytes. > I just committed a fix as r209152. Yep, it works. Thanks for the quick fix! > Tim > Boris Samorodov wrote: > > Hi! > > > > - > > % uname -a > > FreeBSD host.ipt.ru 9.0-CURRENT FreeBSD 9.0-CURRENT #4 r208799: Fri Jun 4 > > 13:58:47 MSD 2010 b...@host.ipt.ru:/storage/obj/storage/src/sys/HOST > > i386 > > > > % make extract > > ===> Vulnerability check disabled, database not found > > ===> License check disabled, port has not defined LICENSE > > ===> Extracting for eric5-5.0.0 > > => No checksum file > > (/m/home/bsam/shared/FreeBSD/exp/eric5/devel/eric5/distinfo). > > load: 6.85 cmd: bsdtar 68052 [runnable] 131.55r 0.03u 0.30s 0% 2044k > > In: 17512980 bytes, compression 1290122025%; Out: 1502 files, 17509012 > > bytes > > Current: eric5-5.0.0-RC1/eric/icons/default/drawEraser.png (1172 bytes) > > load: 6.96 cmd: gzip 68051 [pipdwt] 150.90r 0.16u 0.00s 0% 1052k > > In: 24466168 bytes, compression -1782936608%; Out: 1821 files, 24460918 > > bytes > > Current: eric5-5.0.0-RC1/eric/E5Gui/E5SingleApplication.py (4726 bytes) > > % > > - > > > > One can get the file to experiment: > > - > > % fetch > > http://heanet.dl.sourceforge.net/project/eric-ide/eric5/stable/5.0.0-RC1/eric5-5.0.0-RC1.tar.gz > > - > > > > Extracted files seems to be OK. -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: [OpenRD Ultimate] e1000phy(88E1149/88E1121) has a initialize issue
On Sun, Jun 13, 2010 at 11:37:23PM +0900, Norikatsu Shigemura wrote:
> Hi yongari!
>
> I have a OpenRD Ultimate, which has two GbE ports - if_mge(4). But
> I couldn't use mge1 like following. So I tried to investigate.
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - -
> Jun 13 05:02:14 sidearms kernel: mge1: watchdog timeout
> Jun 13 05:02:14 sidearms kernel: mge1: Timeout on link-up
^
This part looks like a bug in mge(4). Driver does not know how long
it would take to get a valid link. Waiting for valid link in driver
initialization does not work(e.g Starting controller without UTP
cable may always fail on mge(4)). I think mge(4) should implement
correct link state change handling.
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - -
>
> I found a initialize issue in e1000phy.c.
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - -
> --- sys/dev/mii/e1000phy.c.orig 2010-05-01 10:17:15.282196000 +0900
> +++ sys/dev/mii/e1000phy.c2010-06-13 16:19:46.616650536 +0900
> @@ -278,6 +278,7 @@
> case MII_MODEL_MARVELL_E1118:
> break;
> case MII_MODEL_MARVELL_E1116:
> + case MII_MODEL_MARVELL_E1149:
> page = PHY_READ(sc, E1000_EADR);
> /* Select page 3, LED control register. */
> PHY_WRITE(sc, E1000_EADR, 3);
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - -
>
> I confirmed OK on my environment, OpenRD Ultimate has a 88E1121(I
> saw it, physically):
Once it was there but I removed it due to some other issues seen on
Yukon Ultra. That part will program LED access so I guess it
wouldn't affect normal network activity.
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - -
> Jun 13 15:20:01 sidearms kernel: miibus0: miibus_probe: ma.mii_id1 = 0x141,
> ma.mii_id2 = 0xcb3
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - -
> And I confirmed that MII chipset ID is same as 88E1249.
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - -
> mge0
> Marvell OBIO Memory:
> 4043776000-4043784191
> Marvell OBIO IRQ:
> 11
> 12
> 13
> 14
> 46
> miibus0
> e1000phy0 pnpinfo oui=0x5043 model=0xb rev=0x3 at phyno=0
> mge1
> Marvell OBIO Memory:
> 4043792384-4043800575
> Marvell OBIO IRQ:
> 15
> 16
> 17
> 18
> 47
> miibus1
> e1000phy1 pnpinfo oui=0x5043 model=0xb rev=0x3 at phyno=1
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - -
>
>
> BTW, I knew same issue on OpenRD Client, it has a 88E1116R, maybe.
> Sorry, I don't already have it. I couldn't confirm.
> So accordingly my memo:
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - -
> miibus0: ma.mii_id1 = 0x141, ma.mii_id2 = 0xe40
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - -
> I found many initialize issues on 88E1116R by not existing on
> e1000phy.c. Maybe 88E1116 = 88E1116R like following:
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - -
> switch (esc->mii_model) {
> case MII_MODEL_MARVELL_E:
> case MII_MODEL_MARVELL_E1112:
> case MII_MODEL_MARVELL_E1116:
> + case MII_MODEL_MARVELL_E1116R:
> case MII_MODEL_MARVELL_E1118:
> case MII_MODEL_MARVELL_E1149:
> case MII_MODEL_MARVELL_PHYG65G:
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - -
> But there are many points, I don't know that this modify is right.
>
88E1116R might be RGMII variant of 88E1116. Because I don't have
controller that has 88E1116R I didn't treat it as 88E1116. With
that change could you use straight cable without help of MDI/MDI-X
converter?
___
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: two buildworld problems
On Tue, Jun 15, 2010 at 7:30 PM, Doug Barton wrote: > On 06/15/10 10:24, Alexander Best wrote: >> >> `make -V .CURDIR` in /usr/src returns "/usr/src" > > Thanks. Now: > > cd /usr/obj/usr/src > make -V .CURDIR "/usr/obj/usr/src" > > > Doug > > -- > > ... and that's just a little bit of history repeating. > -- Propellerheads > > Improve the effectiveness of your Internet presence with > a domain name makeover! http://SupersetSolutions.com/ > > -- Alexander Best ___ 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: [CFT] BSDL iconv in base system
On Tue, Jun 15, 2010 at 7:42 PM, Gabor Kovesdan wrote: > >> /usr/src/lib/libc/iconv/citrus_none.c: In function >> '_citrus_NONE_stdenc_cstomb': >> /usr/src/lib/libc/iconv/citrus_none.c:114: warning: unused variable 'ret' >> *** Error code 1 >> > > I'm sorry, this one slipped in. Today I've checked the sources with clang > and fixed some minor warnings, including this one. The new patch is here: > http://www.kovesdan.org/patches/iconv_base_integrate2.diff > > And a gzipped version: > http://www.kovesdan.org/patches/iconv_base_integrate2.diff.gz thanks. i'll revert the previous patch and apply this new one. cheers. alex > > -- > Gabor Kovesdan > FreeBSD Volunteer > > EMAIL: ga...@freebsd.org .:|:. ga...@kovesdan.org > WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org > > -- Alexander Best ___ 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: Marvell 88SX7042
Thanks i managed to fix that, but sadly its still unusable. I tried to create a raidz on 4 1.5tb disks with moderate success, Im able to create the raid, but when im trying to copy files onto the raid i get immense amount of errors. Is this zfs related or the driver/controller is doing some hinky stuff? -zsozso mvsch1: Timeout on slot 0 mvsch1: iec 0200 sstat 0123 serr edma_s 0040 dma_c 16000700 dma_s 0008 rs 0001 status c0 mvsch0: Timeout on slot 0 mvsch0: iec sstat 0123 serr edma_s 0040 dma_c 16000700 dma_s 0008 rs 0001 status c0 mvsch3: Timeout on slot 0 mvsch3: iec sstat 0123 serr edma_s 001d dma_c dma_s 0008 rs 7fff status c0 mvsch3: ... waiting for slots 7ffe mvsch3: Timeout on slot 1 mvsch3: iec sstat 0123 serr edma_s 001d dma_c dma_s 0008 rs 7fff status c0 mvsch3: ... waiting for slots 7ffc mvsch3: Timeout on slot 2 mvsch3: iec sstat 0123 serr edma_s 001d dma_c dma_s 0008 rs 7fff status c0 mvsch3: ... waiting for slots 7ff8 mvsch3: Timeout on slot 3 mvsch3: iec sstat 0123 serr edma_s 001d dma_c dma_s 0008 rs 7fff status c0 mvsch3: ... waiting for slots 7ff0 mvsch3: Timeout on slot 4 mvsch3: iec sstat 0123 serr edma_s 001d dma_c dma_s 0008 rs 7fff status c0 mvsch3: ... waiting for slots 7fe0 mvsch3: Timeout on slot 5 mvsch3: iec sstat 0123 serr edma_s 001d dma_c dma_s 0008 rs 7fff status c0 mvsch3: ... waiting for slots 7fc0 mvsch3: Timeout on slot 6 mvsch3: iec sstat 0123 serr edma_s 001d dma_c dma_s 0008 rs 7fff status c0 mvsch3: ... waiting for slots 7f80 mvsch3: Timeout on slot 7 mvsch3: iec sstat 0123 serr edma_s 001d dma_c dma_s 0008 rs 7fff status c0 mvsch3: ... waiting for slots 7f00 mvsch3: Timeout on slot 8 mvsch3: iec sstat 0123 serr edma_s 001d dma_c dma_s 0008 rs 7fff status c0 mvsch3: ... waiting for slots 7e00 mvsch3: Timeout on slot 9 mvsch3: iec sstat 0123 serr edma_s 001d dma_c dma_s 0008 rs 7fff status c0 mvsch3: ... waiting for slots 7c00 mvsch3: Timeout on slot 10 mvsch3: iec sstat 0123 serr edma_s 001d dma_c dma_s 0008 rs 7fff status c0 mvsch3: ... waiting for slots 7800 mvsch3: Timeout on slot 11 mvsch3: iec sstat 0123 serr edma_s 001d dma_c dma_s 0008 rs 7fff status c0 mvsch3: ... waiting for slots 7000 mvsch3: Timeout on slot 12 mvsch3: iec sstat 0123 serr edma_s 001d dma_c dma_s 0008 rs 7fff status c0 mvsch3: ... waiting for slots 7fffe000 mvsch3: Timeout on slot 13 mvsch3: iec sstat 0123 serr edma_s 001d dma_c dma_s 0008 rs 7fff status c0 mvsch3: ... waiting for slots 7fffc000 mvsch3: Timeout on slot 14 mvsch3: iec sstat 0123 serr edma_s 001d dma_c dma_s 0008 rs 7fff status c0 mvsch3: ... waiting for slots 7fff8000 mvsch3: Timeout on slot 15 mvsch3: iec sstat 0123 serr edma_s 001d dma_c dma_s 0008 rs 7fff status c0 mvsch3: ... waiting for slots 7fff mvsch3: Timeout on slot 16 mvsch3: iec sstat 0123 serr edma_s 001d dma_c dma_s 0008 rs 7fff status c0 mvsch3: ... waiting for slots 7ffe mvsch3: Timeout on slot 17 mvsch3: iec sstat 0123 serr edma_s 001d dma_c dma_s 0008 rs 7fff status c0 mvsch3: ... waiting for slots 7ffc mvsch3: Timeout on slot 18 mvsch3: iec sstat 0123 serr edma_s 001d dma_c dma_s 0008 rs 7fff status c0 mvsch3: ... waiting for slots 7ff8 mvsch3: Timeout on slot 19 mvsch3: iec sstat 0123 serr edma_s 001d dma_c dma_s 0008 rs 7fff status c0 mvsch3: ... waiting for slots 7ff0 mvsch3: Timeout on slot 20 mvsch3: iec sstat 0123 serr edma_s 001d dma_c dma_s 0008 rs 7fff status c0 mvsch3: ... waiting for slots 7fe0 mvsch3: Timeout on slot 21 mvsch3: iec sstat 0123 serr edma_s 001d dma_c dma_s 0008 rs 7fff status c0 mvsch3: ... waiting for slots 7fc0 mvsch3: Timeout on slot 22 mvsch3: iec sstat 0123 serr edma_s 001d dma_c dma_s 0008 rs 7fff status c0 mvsch3: ... waiting for slots 7f80 mvsch3: Timeout on slot 23 mvsch3: iec sstat 0123 serr edma_s 001d dma
Re: [CFT] BSDL iconv in base system
/usr/src/lib/libc/iconv/citrus_none.c: In function '_citrus_NONE_stdenc_cstomb': /usr/src/lib/libc/iconv/citrus_none.c:114: warning: unused variable 'ret' *** Error code 1 I'm sorry, this one slipped in. Today I've checked the sources with clang and fixed some minor warnings, including this one. The new patch is here: http://www.kovesdan.org/patches/iconv_base_integrate2.diff And a gzipped version: http://www.kovesdan.org/patches/iconv_base_integrate2.diff.gz -- Gabor Kovesdan FreeBSD Volunteer EMAIL: ga...@freebsd.org .:|:. ga...@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.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: wpa_supplicant (Was: Re: wpi not working on today's current (r208626))
On Tue, Jun 15, 2010 at 10:02:44AM -0700, Doug Barton wrote: > On 06/15/10 09:32, Lars Engels wrote: > > On Tue, Jun 15, 2010 at 09:25:22AM -0700, Rui Paulo wrote: > >> > >> On 15 Jun 2010, at 09:17, Lars Engels wrote: > >> > >>> On Tue, Jun 15, 2010 at 09:00:51AM -0700, Rui Paulo wrote: > > On 15 Jun 2010, at 08:03, Lars Engels wrote: > > > > The issue is still present in r209168. > > Which driver? I works fine with my ath. > > >>> > >>> ath0: mem 0xd400-0xd400 irq 16 at device 0.0 > >>> on pci2 > >>> ath0: [ITHREAD] > >>> ath0: AR2425 mac 14.2 RF5424 phy 7.0 > >> > >> Can you identify the revision that broke it? > > > > Unfortunately not the exact revision. Doug wrote that it stopped working > > at r208626 and before it also worked for me. > > The problem I had was related to other things, not wpa_supplicant > directly. I upgraded my -current a few days ago and it's working fine > for me, both before and after Rui's latest update (using the wpi driver). Good to hear that it's working for you. In my case, it was PEBKAC. To quote Firefox: "Well, this is embarrassing." When I upgraded my machine I also removed all installed Ports and cleaned up my rc.conf. Somehow I changed ifconfig_wlan0 to fconfig_wlan0. After inserting the missing 'i' I have a working wireless connection again. Now please forget what you've just read and only remember that my problem is fixed. ;-) pgpVAl0pUgq23.pgp Description: PGP signature
Re: two buildworld problems
On 06/15/10 10:24, Alexander Best wrote: `make -V .CURDIR` in /usr/src returns "/usr/src" Thanks. Now: cd /usr/obj/usr/src make -V .CURDIR Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ 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: two buildworld problems
On Tue, Jun 15, 2010 at 7:12 PM, Doug Barton wrote: > On 06/15/10 04:11, Alexander Best wrote: >> >> 2010/6/15 Dag-Erling Smørgrav: >>> >>> Alexander Best writes: Dag-Erling Smørgrav writes: > > Alexander Best writes: >> >> .if empty(.CURDIR:M/usr/src/*)&& empty(.CURDIR:M/usr/obj/*)&& >> exists(/usr/local/bin/gcc44) >> CC = gcc44 >> CXX = g++44 >> CPP = cpp44 >> .endif > > What happens when .CURDIR = /usr/src? i'm now using [...] >>> >>> I was trying to show you why what you had didn't work... >> >> sorry. i didn't mean to affend you. doug barton already pointed out >> that what i had in my make.conf beforehand won't work unless /usr/src >> and /usr/obj are literal directories in /usr [1]. > > You're really working hard to make this more complicated than it needs to > be. Try this: > > cd /usr/src > make -V .CURDIR > > Then tell us what it says. *lol* sorry. i'm quite busy with other stuff atm so i'm not that good at reading mails very thoroughly right now. ;9 `make -V .CURDIR` in /usr/src returns "/usr/src" cheers. alex > > > Doug > > -- > > ... and that's just a little bit of history repeating. > -- Propellerheads > > Improve the effectiveness of your Internet presence with > a domain name makeover! http://SupersetSolutions.com/ > > -- Alexander Best ___ 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: two buildworld problems
On 06/15/10 04:11, Alexander Best wrote: 2010/6/15 Dag-Erling Smørgrav: Alexander Best writes: Dag-Erling Smørgrav writes: Alexander Best writes: .if empty(.CURDIR:M/usr/src/*)&& empty(.CURDIR:M/usr/obj/*)&& exists(/usr/local/bin/gcc44) CC = gcc44 CXX = g++44 CPP = cpp44 .endif What happens when .CURDIR = /usr/src? i'm now using [...] I was trying to show you why what you had didn't work... sorry. i didn't mean to affend you. doug barton already pointed out that what i had in my make.conf beforehand won't work unless /usr/src and /usr/obj are literal directories in /usr [1]. You're really working hard to make this more complicated than it needs to be. Try this: cd /usr/src make -V .CURDIR Then tell us what it says. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ 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: [CFT] BSDL iconv in base system
Are there any plans to resurrect/finish multibyte collation support GSoC'2008 project: http://wiki.freebsd.org/KonradJankowski/Collation Yes, my queue is just so long that I haven't got there yet. I'm in SoC 2010 again with a different project and there's still BSD grep from SoC 2008. I'm also fixing the last nits of that. And there are also personal things, like a one-year internship in Portugal, which is going to start in September. But I hope once I'll find time or this. And are you aware of any plans on adding utf8-aware regex? I think NetBSD has already imported one: http://blog.netbsd.org/tnf/entry/efficient_wide_character_regular_expressions Yes, again but same issues. :) Besides, we need/should add a more relaxed regex support to TRE before we can adopt it. GNU regex allows things like [a|], which is not standard, so we should support them to maintain compatibility. This will be important for ports. This is also the reason why BSD grep is linked to GNU regex instead of libc-regex. -- Gabor Kovesdan FreeBSD Volunteer EMAIL: ga...@freebsd.org .:|:. ga...@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.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: [CFT] BSDL iconv in base system
getting this error when doing 'buildworld': cc -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DSYMBOL_VERSIONING -g -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libc/iconv/citrus_none.c cc1: warnings being treated as errors /usr/src/lib/libc/iconv/citrus_none.c: In function '_citrus_NONE_stdenc_cstomb': /usr/src/lib/libc/iconv/citrus_none.c:114: warning: unused variable 'ret' *** Error code 1 Stop in /usr/src/lib/libc. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. -- Alexander Best ___ 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: wpa_supplicant (Was: Re: wpi not working on today's current (r208626))
On 06/15/10 09:32, Lars Engels wrote: On Tue, Jun 15, 2010 at 09:25:22AM -0700, Rui Paulo wrote: On 15 Jun 2010, at 09:17, Lars Engels wrote: On Tue, Jun 15, 2010 at 09:00:51AM -0700, Rui Paulo wrote: On 15 Jun 2010, at 08:03, Lars Engels wrote: The issue is still present in r209168. Which driver? I works fine with my ath. ath0: mem 0xd400-0xd400 irq 16 at device 0.0 on pci2 ath0: [ITHREAD] ath0: AR2425 mac 14.2 RF5424 phy 7.0 Can you identify the revision that broke it? Unfortunately not the exact revision. Doug wrote that it stopped working at r208626 and before it also worked for me. The problem I had was related to other things, not wpa_supplicant directly. I upgraded my -current a few days ago and it's working fine for me, both before and after Rui's latest update (using the wpi driver). hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ 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: [CFT] BSDL iconv in base system
On (15/06/2010 02:13), Gabor Kovesdan wrote: > Hello Folks, > > during the last summer, Google generously founded my Summer of Code > project, which was providing a BSD-licensed iconv implementation for > FreeBSD. I'm proud to announce that the work has been completed and a > patch is available to add it to the base system. > > The results of this work are: > - The Citrus implementation has been ported from NetBSD. > - Some utilities have been added. There is a conversion table generator, > which can compare conversion tables to reference data generated by GNU > libiconv. This helps ensuring conversion compatibility. > - UTF-16 surrogate support and some endianness issues have been fixed. > - The rather chaotic Makefiles to build metadata have been refactored > and cleaned up, now it is easy to read and it is also easier to add > support for new encodings. > - A bunch of new encodings and encoding aliases have been added. > - Support for 1->2, 1->3 and 1->4 mappings, which is needed for > transliterating with flying accents as GNU does, like "u. > - Lots of warnings have been fixed, the major part of the code is now > WARNS=6 clean. > - New section 1 and section 5 manual pages have been added. > - Some GNU-specific calls have been implemented: iconvlist(), > iconvctl(), iconv_canonicalize(), iconv_open_into() > - Support for GNU's //IGNORE suffix has been added. > - The "-" argument for stdin is now recognized in iconv(1) as per POSIX. > - The Big5 conversion module has been fixed. > - The iconv.h header files is supposed to be compatible with the GNU > version, i.e. sources should build with base iconv.h and GNU libiconv. > I've just did a very quick test and it seems ports can safely link to > GNU libiconv, there's no conflict. > - Various cleanups and style(9) fixes. > - A bachelor thesis written in Hungarian language: > http://www.kovesdan.org/files/bsc_iconv.pdf > > The rather big patch (42,5M) is available here: > http://www.kovesdan.org/patches/iconv_base_integrate.diff > > Any comments, suggestions or bugreports are very welcome. Awesome! Thanks for working on it. Are there any plans to resurrect/finish multibyte collation support GSoC'2008 project: http://wiki.freebsd.org/KonradJankowski/Collation And are you aware of any plans on adding utf8-aware regex? I think NetBSD has already imported one: http://blog.netbsd.org/tnf/entry/efficient_wide_character_regular_expressions Thanks, Gleb. > -- > Gabor Kovesdan > FreeBSD Volunteer > > EMAIL:ga...@freebsd.org .:|:.ga...@kovesdan.org > WEB:http://people.FreeBSD.org/~gabor .:|:.http://kovesdan.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" ___ 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: Marvell 88SX7042
On Sat, Jun 12, 2010 at 5:03 AM, oizs wrote: > Hello, > > I got myself a board made for google by arima and had some issues with it > booting freebsd on it, but with some help of the list i was able to make it > boot. > Now i have two problems, whenever i try to reboot i get kernel trap 12, and > the more irritating problem, is that i can't make disks on the marvell > controller show up. According to 'man ata' the 88sx7042 is supported, but > even if i compile the kernel to support mvs, or try to load it with > loader.conf it won't load the driver. If i load debian up im able to > read/write them, so its probably not a hw issue. I would welcome any ideas > since im starting to run out of them. > > pciconf -lv > > hpt...@pci0:2:0:0: class=0x01 card=0x11ab11ab chip=0x704211ab > rev=0x02 hdr=0x00 > Your 88sx7042 is claimed by hptrr, driver for highpoint rocketraid adapters. You may want to build a custom kernel by removing the line device hptrr -js. ___ 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: wpa_supplicant (Was: Re: wpi not working on today's current (r208626))
On Tue, Jun 15, 2010 at 09:25:22AM -0700, Rui Paulo wrote: > > On 15 Jun 2010, at 09:17, Lars Engels wrote: > > > On Tue, Jun 15, 2010 at 09:00:51AM -0700, Rui Paulo wrote: > >> > >> On 15 Jun 2010, at 08:03, Lars Engels wrote: > >>> > >>> The issue is still present in r209168. > >> > >> Which driver? I works fine with my ath. > >> > > > > ath0: mem 0xd400-0xd400 irq 16 at device 0.0 on > > pci2 > > ath0: [ITHREAD] > > ath0: AR2425 mac 14.2 RF5424 phy 7.0 > > Can you identify the revision that broke it? Unfortunately not the exact revision. Doug wrote that it stopped working at r208626 and before it also worked for me. pgp5qR2lCd5u8.pgp Description: PGP signature
Re: wpa_supplicant (Was: Re: wpi not working on today's current (r208626))
On 15 Jun 2010, at 09:17, Lars Engels wrote: > On Tue, Jun 15, 2010 at 09:00:51AM -0700, Rui Paulo wrote: >> >> On 15 Jun 2010, at 08:03, Lars Engels wrote: >>> >>> The issue is still present in r209168. >> >> Which driver? I works fine with my ath. >> > > ath0: mem 0xd400-0xd400 irq 16 at device 0.0 on > pci2 > ath0: [ITHREAD] > ath0: AR2425 mac 14.2 RF5424 phy 7.0 Can you identify the revision that broke it? -- Rui Paulo ___ 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: wpa_supplicant (Was: Re: wpi not working on today's current (r208626))
On Tue, Jun 15, 2010 at 09:00:51AM -0700, Rui Paulo wrote: > > On 15 Jun 2010, at 08:03, Lars Engels wrote: > > > > The issue is still present in r209168. > > Which driver? I works fine with my ath. > ath0: mem 0xd400-0xd400 irq 16 at device 0.0 on pci2 ath0: [ITHREAD] ath0: AR2425 mac 14.2 RF5424 phy 7.0 pgp3xegg3kPOL.pgp Description: PGP signature
Re: wpa_supplicant (Was: Re: wpi not working on today's current (r208626))
On 15 Jun 2010, at 08:03, Lars Engels wrote: > On Sun, May 30, 2010 at 07:48:38PM +0200, Lars Engels wrote: >> On Sat, May 29, 2010 at 11:20:18AM +0100, Rui Paulo wrote: >>> >>> On 29 May 2010, at 05:39, b. f. wrote: >>> On 5/28/10, Doug Barton wrote: > On 5/28/2010 4:50 PM, b. f. wrote: >> >> I can't see any problems when using WPA2 with AES on r208606 i386 with >> uath(4). I'm updating this machine to r208630 tonight, and if I >> encounter problems with the later revision, I'll let you know. > > Ok, thanks. > >> Are >> you saying that you experienced problems when trying to use a r207134 >> base with a r208626 kernel? If that's the case, I would recommend >> updating the base to the same revision as the kernel, and then >> retesting. > > Yes, that's what I'm doing I actually tried running the newly built > wpa_supplicant but that didn't work. I'm kind of hesitant to do the full > upgrade since I'm having kernel problems with the nvidia driver, but if > I'm sure wpa_supplicant will work then I suppose I can bite the bullet. > It appears that something is wrong. My wireless stick no longer associates with the network with r208630. I'll do some tinkering. >>> >>> That's odd. The only way for that to happen would be caused bug in the >>> taskqueue stuff that zml committed, I think, but that's a long shot. >> >> Correction: Wireless actually works if you set the channel manually and >> start wpa_supplicant afterwards. So wpa_supplicant no longer seems to be >> able to change the channel itself. > > > The issue is still present in r209168. Which driver? I works fine with my ath. -- Rui Paulo ___ 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: wpa_supplicant (Was: Re: wpi not working on today's current (r208626))
On Sun, May 30, 2010 at 07:48:38PM +0200, Lars Engels wrote: > On Sat, May 29, 2010 at 11:20:18AM +0100, Rui Paulo wrote: > > > > On 29 May 2010, at 05:39, b. f. wrote: > > > > > On 5/28/10, Doug Barton wrote: > > >> On 5/28/2010 4:50 PM, b. f. wrote: > > >>> > > >>> I can't see any problems when using WPA2 with AES on r208606 i386 with > > >>> uath(4). I'm updating this machine to r208630 tonight, and if I > > >>> encounter problems with the later revision, I'll let you know. > > >> > > >> Ok, thanks. > > >> > > >>> Are > > >>> you saying that you experienced problems when trying to use a r207134 > > >>> base with a r208626 kernel? If that's the case, I would recommend > > >>> updating the base to the same revision as the kernel, and then > > >>> retesting. > > >> > > >> Yes, that's what I'm doing I actually tried running the newly built > > >> wpa_supplicant but that didn't work. I'm kind of hesitant to do the full > > >> upgrade since I'm having kernel problems with the nvidia driver, but if > > >> I'm sure wpa_supplicant will work then I suppose I can bite the bullet. > > >> > > > > > > It appears that something is wrong. My wireless stick no longer > > > associates with the network with r208630. I'll do some tinkering. > > > > That's odd. The only way for that to happen would be caused bug in the > > taskqueue stuff that zml committed, I think, but that's a long shot. > > Correction: Wireless actually works if you set the channel manually and > start wpa_supplicant afterwards. So wpa_supplicant no longer seems to be > able to change the channel itself. The issue is still present in r209168. pgpeSZcZqNAnK.pgp Description: PGP signature
Re: RFC: etcupdate tool in base?
On Monday 14 June 2010 5:22:32 pm Garrett Cooper wrote: > On Thu, Jun 10, 2010 at 10:46 AM, John Baldwin wrote: > > I've had several folks ask me recently about importing etcupdate > > (http://www.FreeBSD.org/~jhb/etcupdate) into the base system as an alternate > > tool for updating /etc during upgrades. Do folks have any strong objections > > to doing so? More details about how it works and an HTML version of the > > manpage can be found at the URL above. > > Finally got around to looking at this. > > Some comments: > > 1. Script doesn't check to see whether or not it has write access (and > doesn't catch some errors): > > $ etcupdate > mkdir: /var/db/etcupdate: Permission denied > /usr/sbin/etcupdate: cannot create /var/db/etcupdate/log: No such file > or directory > > Eventually it stops though, so maybe it's not really a big issue... It does actually check, but it does so after it opens the log file. :-/ > 2. Some messages are a bit misleading: > > $ etcupdate > /usr/sbin/etcupdate: cannot create /var/db/etcupdate/log: Permission denied > $ ls -l /var/db/etcupdate/log > -rw-r--r-- 1 root wheel 0 Jun 14 14:06 /var/db/etcupdate/log > $ whoami > garrcoop That is the shell complaining due to this: exec 3>$LOGFILE Arguably the shell is emitting the correct message since it is attempting to recreate the file. > 3. Workflow comments. > > i. Ok... I know I'm doing a downgrade, but what now? > > $ sudo etcupdate > No previous tree to compare against, a sane comparison is not possible. > > ii. Did a bit more reading, and I think that `etcupdate build' is what > I want... but it wasn't happy when I did that: Did you read this part of the manpage: EXAMPLES If the source tree matches the currently installed world, then the fol- lowing can be used to bootstrap etcupdate so that it can be used for future upgrades: etcupdate extract To merge changes after an upgrade via the buildworld and installworld process: etcupdate To resolve any conflicts generated during a merge: etcupdate resolve Also, the README file at http://www.FreeBSD.org/~jhb/etcupdate/ may be useful. > $ sudo etcupdate build > Missing required tarball. > > usage: etcupdate [-nBF] [-d workdir] [-r | -s source | -t tarball] [-A patterns] > [-D destdir] [-I patterns] [-L logfile] [-M options] >etcupdate build [-B] [-d workdir] [-s source] [-L logfile] [-M options] > >etcupdate diff [-d workdir] [-D destdir] [-I patterns] [-L logfile] >etcupdate extract [-B] [-d workdir] [-s source | -t tarball] [-L logfile] > [-M options] >etcupdate resolve [-d workdir] [-D destdir] [-L logfile] >etcupdate status [-d workdir] > > So uh... ok? Manpage and usage were a bit confusing (but not too bad). > After I fixed my arguments, here's what I came up with: > > $ sudo etcupdate build -s /data/scratch/src/stable/8/ > /root/etcupdate-stable8.tbz > $ sudo etcupdate extract -t /root/etcupdate-stable8.tbz > $ You could just do 'etcupdate extract -s /data/scratch/src/stable/8' in this case. :) However, when you do an extract, you are doing a one-time bootstrap. This step needs to be pointed at a source tree that matches what you already have installed. You can do an 'etcupdate diff' after the extract to see what local differences you have and make sure those look sane. Once you have done this, then you can use etcupdate for future upgrades by just running 'etcupdate'. -- John Baldwin ___ 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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
AK-san, PseudoCylon wrote: From: Ganbold To: PseudoCylon Cc: freebsd-current@freebsd.org; Ganbold Tsagaankhuu Sent: Thu, June 10, 2010 10:53:30 AM Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless It seems like it is running without any problem so far, no more adsl modem problem. I can see arp packets in wlan0 interface as well as in macbook. I will continue testing and let you know if there comes any problem. thanks again, Ganbold >>> Hello, >>> >>> Glad to hear. It was an encryption problem. A client was dropping packets.. >>> >>> Please let me know if you find another bug. (Hope there won't be) >>> >>> >> Well, looks like I was too fast :( >> >> It seems like client is not receiving any arp packets when rspro doesn't >> first initiate ping (maybe arp request) to client. >> If I first ping to client from rspro, later on arp packets can be seen >> on client. >> When I ping from rspro to client, response is very different: >> >> # arp -a >> ? (192.168.1.43) at 8e:fd:59:d6:3a:50 on bridge0 permanent [bridge] >> ? (192.168.1.42) at 00:22:cf:03:e0:30 on wlan0 permanent [ethernet] >> ? (192.168.1.41) at 00:15:6d:c1:c7:77 on arge0 permanent [ethernet] >> ? (192.168.1.1) at 00:30:54:62:3d:24 on arge0 expires in 1200 seconds >> [ethernet] >> ? (192.168.1.7) at 00:1c:25:9d:36:1d on arge0 expires in 824 seconds >> [ethernet] >> # ping 192.168.1.50 >> PING 192.168.1.50 (192.168.1.50): 56 data bytes >> 64 bytes from 192.168.1.50: icmp_seq=0 ttl=64 time=2.694 ms >> 64 bytes from 192.168.1.50: icmp_seq=1 ttl=64 time=302.177 ms >> 64 bytes from 192.168.1.50: icmp_seq=2 ttl=64 time=1.041 ms >> 64 bytes from 192.168.1.50: icmp_seq=4 ttl=64 time=5234.417 ms >> 64 bytes from 192.168.1.50: icmp_seq=5 ttl=64 time=4225.060 ms >> 64 bytes from 192.168.1.50: icmp_seq=6 ttl=64 time=3214.908 ms >> 64 bytes from 192.168.1.50: icmp_seq=7 ttl=64 time=2207.241 ms >> 64 bytes from 192.168.1.50: icmp_seq=8 ttl=64 time=1197.061 ms >> 64 bytes from 192.168.1.50: icmp_seq=9 ttl=64 time=186.833 ms >> ^C >> --- 192.168.1.50 ping statistics --- >> 11 packets transmitted, 9 packets received, 18.2% packet loss >> round-trip min/avg/max/stddev = 1.041/1841.270/5234.417/1870.962 ms >> # arp -a >> ? (192.168.1.43) at 8e:fd:59:d6:3a:50 on bridge0 permanent [bridge] >> ? (192.168.1.42) at 00:22:cf:03:e0:30 on wlan0 permanent [ethernet] >> ? (192.168.1.41) at 00:15:6d:c1:c7:77 on arge0 permanent [ethernet] >> ? (192.168.1.1) at 00:30:54:62:3d:24 on arge0 expires in 1183 seconds >> [ethernet] >> ? (192.168.1.7) at 00:1c:25:9d:36:1d on arge0 expires in 805 seconds >> [ethernet] >> ? (192.168.1.50) at 00:26:bb:17:f6:61 on arge0 expires in 1186 seconds >> [ethernet] >> # ping 192.168.1.50 >> PING 192.168.1.50 (192.168.1.50): 56 data bytes >> 64 bytes from 192.168.1.50: icmp_seq=2 ttl=64 time=1590.035 ms >> 64 bytes from 192.168.1.50: icmp_seq=3 ttl=64 time=580.201 ms >> 64 bytes from 192.168.1.50: icmp_seq=4 ttl=64 time=528.019 ms >> ^C >> --- 192.168.1.50 ping statistics --- >> 5 packets transmitted, 3 packets received, 40.0% packet loss >> round-trip min/avg/max/stddev = 528.019/899.418/1590.035/488.804 ms >> >> > > Well, the patch is working (sort of). Old driver wouldn't let you ping > anywhere. > > Replies are taking awfully long. One of them took 5 sec. This could be a > different issue. > > Can you try a few thing? (Unfortunately, everything is working on my side.) > * Before ping from rspro, does ping from macbook to 192.168.1.42 (wlan0) work? > No. I will check again and let you know. > * If you give IP address to only bridge0, does it make any difference? > I will let you know after testing. > * Does it make any difference if use rspro without 192.168.1.7 (if possible)? > 192.168.1.7 is just my freebsd laptop. > wlandebug doesn't work on macbook, does it? > I don't know yet how to debug wlan in macbook, will look for it. > Can you show me your hostapd.conf (minus password, of course). I'll try with > the same config. > Ok, here it is: interface=wlan0 debug=1 logger_syslog=-1 logger_syslog_level=1 ctrl_interface=/var/run/hostapd ctrl_interface_group=wheel ssid=bsd wpa=3 wpa_passphrase=test wpa_key_mgmt=WPA-PSK wpa_pairwise=CCMP TKIP > And, if you ping from macbook, would it take that long? > After ping from rspro, from Macbook it doesn't take long, usually around 3-4ms. Ganbold > > AK > > >> Any idea? >> >> thanks, >> >> Ganbold >> > > > > > -- Experience is a good teacher, but she sends in terrific bills. -- Minna Antrim, "Naked Truth and Veiled Allusions" ___ 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: two buildworld problems
2010/6/15 Dag-Erling Smørgrav : > Alexander Best writes: >> Dag-Erling Smørgrav writes: >> > Alexander Best writes: >> > > .if empty(.CURDIR:M/usr/src/*) && empty(.CURDIR:M/usr/obj/*) && >> > > exists(/usr/local/bin/gcc44) >> > > CC = gcc44 >> > > CXX = g++44 >> > > CPP = cpp44 >> > > .endif >> > What happens when .CURDIR = /usr/src? >> i'm now using [...] > > I was trying to show you why what you had didn't work... sorry. i didn't mean to affend you. doug barton already pointed out that what i had in my make.conf beforehand won't work unless /usr/src and /usr/obj are literal directories in /usr [1]. here's the error ouput i got with .if empty(.CURDIR:M/usr/src/*) && empty(.CURDIR:M/usr/obj/*) && exists(/usr/local/bin/gcc44) CC = gcc44 CXX = g++44 CPP = cpp44 .endif in my make.conf: [2] [1] http://www.mail-archive.com/freebsd-current@freebsd.org/msg122986.html [2] http://www.mail-archive.com/freebsd-current@freebsd.org/msg122975.html cheers. alex > > DES > -- > Dag-Erling Smørgrav - d...@des.no > -- Alexander Best ___ 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: RFC: etcupdate tool in base?
Garrett Cooper writes: > 1. Script doesn't check to see whether or not it has write access (and > doesn't catch some errors): IMHO, any shell script which is intended to be used more than twice should start with "set -e". DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
>>> From: Ganbold >>> To: PseudoCylon >>> Cc: freebsd-current@freebsd.org; Ganbold Tsagaankhuu >>> Sent: Thu, June 10, 2010 10:53:30 AM >>> Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless >>> >>> It seems like it is running without any problem so far, no more adsl >>> modem problem. >>> I can see arp packets in wlan0 interface as well as in macbook. >>> I will continue testing and let you know if there comes any problem. >>> >>> thanks again, >>> >>> Ganbold >>> >> >> Hello, >> >> Glad to hear. It was an encryption problem. A client was dropping packets.. >> >> Please let me know if you find another bug. (Hope there won't be) >> > >Well, looks like I was too fast :( > >It seems like client is not receiving any arp packets when rspro doesn't >first initiate ping (maybe arp request) to client. >If I first ping to client from rspro, later on arp packets can be seen >on client. >When I ping from rspro to client, response is very different: > ># arp -a >? (192.168.1.43) at 8e:fd:59:d6:3a:50 on bridge0 permanent [bridge] >? (192.168.1.42) at 00:22:cf:03:e0:30 on wlan0 permanent [ethernet] >? (192.168.1.41) at 00:15:6d:c1:c7:77 on arge0 permanent [ethernet] >? (192.168.1.1) at 00:30:54:62:3d:24 on arge0 expires in 1200 seconds >[ethernet] >? (192.168.1.7) at 00:1c:25:9d:36:1d on arge0 expires in 824 seconds >[ethernet] ># ping 192.168.1.50 >PING 192.168.1.50 (192.168.1.50): 56 data bytes >64 bytes from 192.168.1.50: icmp_seq=0 ttl=64 time=2.694 ms >64 bytes from 192.168.1.50: icmp_seq=1 ttl=64 time=302.177 ms >64 bytes from 192.168.1.50: icmp_seq=2 ttl=64 time=1.041 ms >64 bytes from 192.168.1.50: icmp_seq=4 ttl=64 time=5234.417 ms >64 bytes from 192.168.1.50: icmp_seq=5 ttl=64 time=4225.060 ms >64 bytes from 192.168.1.50: icmp_seq=6 ttl=64 time=3214.908 ms >64 bytes from 192.168.1.50: icmp_seq=7 ttl=64 time=2207.241 ms >64 bytes from 192.168.1.50: icmp_seq=8 ttl=64 time=1197.061 ms >64 bytes from 192.168.1.50: icmp_seq=9 ttl=64 time=186.833 ms >^C >--- 192.168.1.50 ping statistics --- >11 packets transmitted, 9 packets received, 18.2% packet loss >round-trip min/avg/max/stddev = 1.041/1841.270/5234.417/1870.962 ms ># arp -a >? (192.168.1.43) at 8e:fd:59:d6:3a:50 on bridge0 permanent [bridge] >? (192.168.1.42) at 00:22:cf:03:e0:30 on wlan0 permanent [ethernet] >? (192.168.1.41) at 00:15:6d:c1:c7:77 on arge0 permanent [ethernet] >? (192.168.1.1) at 00:30:54:62:3d:24 on arge0 expires in 1183 seconds >[ethernet] >? (192.168.1.7) at 00:1c:25:9d:36:1d on arge0 expires in 805 seconds >[ethernet] >? (192.168.1.50) at 00:26:bb:17:f6:61 on arge0 expires in 1186 seconds >[ethernet] ># ping 192.168.1.50 >PING 192.168.1.50 (192.168.1.50): 56 data bytes >64 bytes from 192.168.1.50: icmp_seq=2 ttl=64 time=1590.035 ms >64 bytes from 192.168.1.50: icmp_seq=3 ttl=64 time=580.201 ms >64 bytes from 192.168.1.50: icmp_seq=4 ttl=64 time=528.019 ms >^C >--- 192.168.1.50 ping statistics --- >5 packets transmitted, 3 packets received, 40.0% packet loss >round-trip min/avg/max/stddev = 528.019/899.418/1590.035/488.804 ms > Well, the patch is working (sort of). Old driver wouldn't let you ping anywhere. Replies are taking awfully long. One of them took 5 sec. This could be a different issue. Can you try a few thing? (Unfortunately, everything is working on my side.) * Before ping from rspro, does ping from macbook to 192.168.1.42 (wlan0) work? * If you give IP address to only bridge0, does it make any difference? * Does it make any difference if use rspro without 192.168.1.7 (if possible)? wlandebug doesn't work on macbook, does it? Can you show me your hostapd.conf (minus password, of course). I'll try with the same config. And, if you ping from macbook, would it take that long? AK >Any idea? > >thanks, > >Ganbold ___ 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: two buildworld problems
Alexander Best writes: > Dag-Erling Smørgrav writes: > > Alexander Best writes: > > > .if empty(.CURDIR:M/usr/src/*) && empty(.CURDIR:M/usr/obj/*) && > > > exists(/usr/local/bin/gcc44) > > > CC = gcc44 > > > CXX = g++44 > > > CPP = cpp44 > > > .endif > > What happens when .CURDIR = /usr/src? > i'm now using [...] I was trying to show you why what you had didn't work... DES -- Dag-Erling Smørgrav - d...@des.no ___ 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] Misc warnings found by clang.
On 2010-06-15 00:08, Max Laier wrote:
> I'm not sure about the intention behind the len assignements in libugidfw -
> might be just a leftover - but if the idea is to teach a model that "we
> generally care about the return value of snprintf()", a void cast might be
> the
> more protable solution.
These specific snprintf() calls all occur just before returning an
error, so checking the return value is quite useless (unless one wanted
to output some sort of overflow warning right there).
Moreover, all calls to snprintf() in lib/libugidfw/ugidfw.c that do
check the return value are incorrect in two ways:
- The return value is stored in a size_t, while snprintf() returns an
int. Thus all the checks "ret < 0" become bogus.
- The idiom used everywhere is:
len = snprintf(cur, left, ...);
if (len < 0 || len > left)
goto truncated;
which is wrong; the second check should be "len >= left" instead.
Please review the attached patch which fixes those problems too.
Index: lib/libugidfw/ugidfw.c
===
--- lib/libugidfw/ugidfw.c (revision 209192)
+++ lib/libugidfw/ugidfw.c (working copy)
@@ -63,22 +63,22 @@
struct passwd *pwd;
struct statfs *mntbuf;
char *cur, type[sizeof(rule->mbr_object.mbo_type) * CHAR_BIT + 1];
- size_t left, len;
- int anymode, unknownmode, truncated, numfs, i, notdone;
+ size_t left;
+ int len, anymode, unknownmode, truncated, numfs, i, notdone;
cur = buf;
left = buflen;
truncated = 0;
len = snprintf(cur, left, "subject ");
- if (len < 0 || len > left)
+ if (len < 0 || len >= left)
goto truncated;
left -= len;
cur += len;
if (rule->mbr_subject.mbs_flags) {
if (rule->mbr_subject.mbs_neg == MBS_ALL_FLAGS) {
len = snprintf(cur, left, "not ");
- if (len < 0 || len > left)
+ if (len < 0 || len >= left)
goto truncated;
left -= len;
cur += len;
@@ -89,7 +89,7 @@
if (!notdone && (rule->mbr_subject.mbs_neg & MBO_UID_DEFINED)) {
len = snprintf(cur, left, "! ");
- if (len < 0 || len > left)
+ if (len < 0 || len >= left)
goto truncated;
left -= len;
cur += len;
@@ -99,14 +99,14 @@
if (pwd != NULL) {
len = snprintf(cur, left, "uid %s",
pwd->pw_name);
- if (len < 0 || len > left)
+ if (len < 0 || len >= left)
goto truncated;
left -= len;
cur += len;
} else {
len = snprintf(cur, left, "uid %u",
rule->mbr_subject.mbs_uid_min);
- if (len < 0 || len > left)
+ if (len < 0 || len >= left)
goto truncated;
left -= len;
cur += len;
@@ -117,21 +117,21 @@
if (pwd != NULL) {
len = snprintf(cur, left, ":%s ",
pwd->pw_name);
- if (len < 0 || len > left)
+ if (len < 0 || len >= left)
goto truncated;
left -= len;
cur += len;
} else {
len = snprintf(cur, left, ":%u ",
rule->mbr_subject.mbs_uid_max);
- if (len < 0 || len > left)
+ if (len < 0 || len >= left)
goto truncated;
left -= len;
cur += len;
}
} else {
len = snprintf(cur, left, " ");
- if (len < 0 || len > left)
+ if (len < 0 || len >= left)
goto truncated;
left -= len;
cur += len;
@@ -139,7 +139,7 @@
}
if (!notdone && (rule->mbr_subject.mbs_neg & MBO_GID_DEFINED)) {
len = snprintf(
